Zone Routing Protocol

1
3
Energy efcient zone based routing protocol for MANETs
4
5
6 Shadi S. Basurra Q1
a,
, Marina De Vos
a
, Julian Padget
a
, Yusheng Ji
b
, Tim Lewis
c
, Simon Armour
d
7
a
Dept. of Computer Science, University of Bath, UK
8
b
Information Systems Architecture Science Research Division, National Institute of Informatics, Tokyo, Japan
9
c
Toshiba Research Europe Ltd, Bristol, UK
10
d
Dept. of Electrical and Electronic Engineering, Bristol University, UK
11
1 3
a r t i c l e i n f o
14 Article history:
15 Received 6 July 2014
16 Accepted 12 September 2014
17 Available online xxxx
18 Key Q4 words:
19 Mobile ad hoc networks
20 MANET
21 AODV
22 DSR
23 ZCG
24 Zone based routing
25
2 6
a b s t r a c t
27 Mobile Ad Hoc Networks (MANET) are self-conguring infrastructureless networks of
28 mobile devices connected via wireless links. Each device can send and receive data, but
29 it should also forward trafc unrelated to its own use. All need to maintain their autonomy,
30 and effectively preserve their resources (e.g. battery power). Moreover, they can leave the
31 network at any time. Their intrinsic dynamicity and fault tolerance makes them suitable for
32 applications, such as emergency response and disaster relief, when infrastructure is nonex-
33 istent or damaged due to natural disasters, such as earthquakes and ooding, as well as
34 more mundane, day-to-day, uses where their exibility would be advantageous.
35 Routing is the fundamental research issue for such networks and refers to nding and
36 maintaining routes between nodes. Moreover, it involves selecting the best route where
37 many may be available. However, due to the freedom of movement of nodes, new routes
38 need to be constantly recalculated. Most routing protocols use pure broadcasting to
39 discover new routes, which takes up a substantial amount of bandwidth. Intelligent
40 rebroadcasting reduces these overheads by calculating the usefulness of a rebroadcast,
41 and the likelihood of message collisions. Unfortunately, this introduces latency and parts
42 of the network may become unreachable. This paper discusses the Zone based Routing
43 with Parallel Collision Guided Broadcasting Protocol (ZCG) that uses parallel and distrib-
44 uted broadcasting technique (Basurra et al., 2010) [8] to Q3 reduce redundant broadcasting
45 and to accelerate the path discovery process, while maintaining a high reachability ratio
46 as well as keeping node energy consumption low.
47 ZCG uses a one hop clustering algorithm that splits the network into zones led by reliable
48 leaders that are mostly static and have plentiful battery resources. The performance char-
49 acteristics of the ZCG protocol are established through simulations by comparing it to other
50 well-known routing protocols, namely the: AODV and DSR. It emerges that ZCG performs
51 well under many circumstances.
52 2014 Elsevier B.V. All rights reserved.
53
54
55
56 1. Introduction
57 Routing protocols for a MANET can be categorised into
58 three groups: reactive, proactive and hybrid [40]. In reac-
59 tive routing, nodes have no prior location knowledge of
60 the destination nodes and routes are determined on
61 request, typically by ooding, such as in the Ad-hoc
62 On-Demand Distance Vector (AODV) protocol [38]. The
http://dx.doi.org/10.1016/j.adhoc.2014.09.010
1570-8705/ 2014 Elsevier B.V. All rights reserved.
Corresponding Q2 author.
E-mail addresses: shadi.basurra@bath.edu (S.S. Basurra Q1 ), mdv@cs.bath.
ac.uk (M. De Vos), jap@cs.bath.ac.uk (J. Padget), kei@nii.ac.jp (Y. Ji),
Tim.Lewis@toshiba-trel.com (T. Lewis), Simon.Armour@bristol.ac.uk
(S. Armour).
Ad Hoc Networks xxx (2014) xxxxxx
Contents lists available at ScienceDirect
Ad Hoc Networks
j our nal homepage: www. el sevi er . com/ l ocat e/ adhoc
ADHOC 1119 No. of Pages 22, Model 3G
8 October 2014
Please cite this article in press as: S.S. Basurra Q1 et al., Energy efcient zone based routing protocol for MANETs, Ad Hoc Netw. (2014), http://
dx.doi.org/10.1016/j.adhoc.2014.09.010
63 drawbacks of reactive protocols are the high cost of
64 broadcast to establish routes and the latency inherent in
65 the process of nding a route to the destination. In
66 proactive routing, each node in the network continuously
67 checks and evaluates paths to every node in the network
68 to establish a complete or partial view of the network, such
69 as in the destination-sequenced distance-vector (DSDV)
70 routing protocol [39]. Consequently, routing latency is
71 low, because paths to destinations can be calculated locally
72 and quickly. The costs in a proactive approach are the high
73 channel usage overheads for route update control mes-
74 sages and the time to convergence of the network path
75 data. Thus, hybrid techniques have been conceived, using
76 zone and cluster-based routing, that aim to exploit the
77 strengths and minimise the weaknesses of reactive and
78 proactive approaches [2,24,44].
79 In a MANET, many routing protocols, such as the Ad hoc
80 on-demand Distance Vector (AODV) [38], Dynamic Source
81 Routing (DSR) [27], Zone Routing Protocols (ZRP) [23,24],
82 Location Aided Routing (LAR) [29] and Geographical
83 Routing Protocol (GRP) use broadcasting to establish
84 routes. Pure ooding guarantees high reachability and
85 good routing time latency in low density networks. How-
86 ever, pure broadcasting uses a lot of network capacity
87 and is prone to broadcast storms in dense networks, thus
88 increasing routing delay. One solution to the storm
89 problem is to send fewer redundant rebroadcasts by
90 selecting a small set of forwarding nodes while ensuring
91 broadcast coverage, but this may cause the rebroadcast
92 chain to break and critical intermediate nodes not to
93 receive rebroadcasts, resulting in reduced reachability
94 [2]. Smart rebroadcast algorithms aim to reduce overheads
95 by computing the usefulness of rebroadcasting and the
96 likelihood of packet collisions, such as in counter/location
97 based schemes[42,31].
98 Many broadcasting approaches have been proposed to
99 allow mobile nodes to estimate neighbourhood density
100 and trade off low broadcast redundancy with reachability,
101 which in turn leads to the best possible network through-
102 put, reachability level and low broadcast latency. However,
103 most of the existing routing protocols in a MANET see
104 lowering broadcasting latency in terms of efcient broad-
105 casting [42] and not as a protocol design objective. The
106 view here is that both can be reduced by addressing them
107 in the protocol design phase.
108 The objective of this paper is to evaluate the efciency
109 of the ZCG routing protocol when being implemented in
110 ad hoc wireless networks that consist of highly mobile
111 nodes where the communications between them are short
112 and frequently repeated. Such network trafc behaviour
113 can be found in many ad hoc applications, such as mobile
114 le/data sharing and Push to Talk (PTT), also known as
115 Press-to-Transmit. Such applications, in contrast to Voice
116 over IP (VoIP) and gaming, do not require users to use all
117 their communication links all the time. That is, they may
118 not send any trafc on a particular path for long periods
119 during an active communication session. During a long
120 silence, the communication channel can be kept active by
121 sending small control packets to the destination node to
122 remind the intermediate nodes along the path that the
123 route is still in use. This will keep the forwarding route
124 available whenever required to relay actual data, but it
125 does consume network resources, i.e. network bandwidth
126 and node power. However, if these control packets are
127 not sent frequently enough they can cause the routing
128 table entries at intermediate nodes along the path to
129 expire, which will require route discovery procedures to
130 be activated that use high amounts of pure broadcasting
131 (also known as blind ooding). This can lead to a broadcast
132 storm problem, which also wastes large network through-
133 put and causes high power consumption in network nodes.
134 This paper describes the design of the ZCG protocol and
135 provides a summary of some of our current simulation
136 results for ZCG performance when compared against other
137 standard routing protocols namely AODV and DSR.
138 We selected the aforementioned protocols to compare
139 their performance against ZCG, for the reasons outlined
140 below: (i) they are the most popular protocols used in
141 mobile ad hoc networks. These protocols are standardised
142 by the Internet Engineering Task Force (IETF), and are the
143 most surveyed protocols in the literature; (ii) they are
144 widely used and well tested for real world applications.
145 For example, Microsoft mesh networks use dynamic source
146 routing (DSR) [28]. Also, AODV routing protocol is already
147 available for the Linux and Microsoft Windows operating
148 systems [12].
149 This paper begins with a brief introduction about the
150 ZCG protocol in Section 2. Then, there is more detailed
151 explanation of the phases of the its zone construction pro-
152 tocol in Section 2.1. This covers the methods used to iden-
153 tify zone leaders, and how nodes calculate and distribute
154 their Fitness Factor (FF) as described in SubSection 2.3.
155 Subsequently, in Section 4 the experimental plan which
156 includes a description of the three main scenarios used to
157 test the protocols performance is explained and justied.
158 These scenarios description and the obtained results from
159 simulating each scenario are discussed in Sections 6.1 and
160 6.2. These results provide various aspects of protocol per-
161 formance, which are: the total routing trafc received,
162 route discovery delay, network delay and routing broad-
163 cast retransmission. Section 7 includes the conclusion,
164 and a brief summary of the research and description of
165 the way forward are provided in Section 10.
166 2. The ZCG protocol
167 ZCG protocol relies on the decomposition of the net-
168 work into contiguous zones, with one node being selected
169 from a group of nodes to be the zone leader, denoted ZL(X),
170 which is selected based on tness criteria similar to those
171 used in [35], such as high battery power and zero/low
172 mobility. The ZLs eventually establish connectivity
173 amongst themselves directly or via reliable intermediate
174 nodes, that is, nodes in the overlap of two or more zone
175 coverage areas and therefore, these connectivity links are
176 not necessarily the shortest available routes (see Fig. 1).
177 Nodes in the ZCG have one of three roles: Zone Leader
178 (ZL), member or idle. By default, idle nodes can only hold
2 S.S. Basurra Q1 et al. / Ad Hoc Networks xxx (2014) xxxxxx
8 October 2014
dx.doi.org/10.1016/j.adhoc.2014.09.010
179 a single role at a time. Moreover, they are isolated mobile
180 stations, which constantly broadcast Hello messages
181 within a one hop count range in the network and therefore,
182 these are not rebroadcast after being received by the rst
183 neighbour. Hello messages are used to sense the existence
184 of neighbours, and determine the link status between
185 them. The Hello Interval and Allowed Hello Loss are
186 parameters that control the Hello transmission rate, with
187 the former setting the time interval between sending each
188 Hello and the latter determining the maximum waiting
189 time before assuming link failure to a neighbour. As rec-
190 ommended by [38,11], the values for the Hello Interval
191 are one second and two seconds for the Allowed Hello Loss
192 parameter.
193 In the ZCG, Hello messages are similar to those of the
194 AODV [38], but Hello headers in the former have additional
195 elds, such as the ZL_IP eld, which is used to publish the
196 senders current role (for further details, see Packet Format
197 1 on page 3 and Table 1 on page 3). The ZL_IP stores the
198 ZLs IP address and if ZL_IP carries a null value then this
199 indicates that the source of this Hello message is an idle
200 node. On the other hand, if the ZL_IP equals the senders
201 IP address it means the sender is a ZL, otherwise, the
202 source of the Hello is already member of an existing ZL
203 with IP address equal to ZL_IP. Publishing a nodes status
204 via a Hello triggers all the consequent actions to form
205 network zones.
206 During the initial phase when formatting the network
207 backbone, all nodes will exist with an idle role and they
208 will exchange Hello messages among themselves. Conse-
209 quently, two or more nodes will realise their existence
210 within their limited wireless range and that their roles
211 are equal to idle. At this point, they automatically decide
212 to perform the zone construction protocol in order to
213 decide fairly on the most reliable node to become the ZL
214 of this zone. Once selected, the remaining participants of
215 the zone construction process that are located within a
216 one hop count of the newly selected ZL, may change their
217 status to member nodes and start publishing their ZLs IP
218 via the Hello messages header in the ZL_IP eld. In the
219 following subsection the zone construction operation will
220 be explained in further detail.
Fig. 1. The ZCG when implemented in a MANET. Here S and D began the parallel path discovery procedure with the assistance of ZLs C and F. The grey
dotted rings around the ZLs indicate their approximate wireless range.
Table 1
Shows the descriptions for the packet header elds.
Field name Description
Type 2 (for HELLO)
R Repair ag
A Acknowledgment required
Reserved Sent as 0; ignored on reception
O Zone construction organizer (ZCO) ag
P Zone construction participant (ZCP) ag
Prex Size If nonzero, the 5-bit Prex Size species that the indicated next hop may be
used for any nodes with the same routing prex (as dened by the Prex Size) as the requested destination
Hop Count 0 or 3
Destination sequence number The destination sequence number associated to the route
Originator IP address The IP address of the node which originated the HELLO for which the route is supplied
Lifetime ALLOWED_HELLO_LOSS * HELLO_INTERVAL
S.S. Basurra Q1 et al. / Ad Hoc Networks xxx (2014) xxxxxx 3
8 October 2014
dx.doi.org/10.1016/j.adhoc.2014.09.010
221 2.1. Identifying zone leaders
Packet Format 1 Shows the format of the HELLO message.
2 1 0 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |R|A|O|P| Reserved |Prefix Sz|Hop Count (TTL)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ZL IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
224 224
225
226 The zone construction protocol is used to identify a
227 zone leader so that nodes with the most desirable
228 attributes, such as plentiful battery power, high connectiv-
229 ity degree and minimum mobility, are preferred for the ZL
230 role.
231 When an idle node rst receives a Hello, it sets a count-
232 down timer to a predetermined value. It then calculates
233 the number of active links to its direct neighbours that
234 are not already ZLs or members of a nearby zone and this
235 is used to regulate the speed of the countdown timer.
236 The node with the highest degree of connectivity is most
237 likely to become the Zone Construction Organiser (ZCO).
238 The reason for this is to involve as many as possible idle
239 nodes participating in the zone construction process, hence
240 decreasing the number of clusters in the network. The ZCO
241 immediately broadcasts a zone construction call and a
242 zone construction end time with a determined TTL, so
243 the call does not propagate the entire network. A moderate
244 TTL value is used of 34. An idle node that receives the call
245 cancels the timer countdown process to become the ZCO,
246 only if the process has been initiated, and sets its state to
247 Zone Construction Participant(ZCP) and its timer to the
248 received zone construction end time. The ZCO also changes
249 its status to ZCP. Other nearby nodes that also receive the
250 zone construction call, such as ZLs, member nodes and
251 ZCPs that are part of a different zone construction process,
252 will broadcast SORRY, explaining the reasons. This is done
253 by declaring the nodes current status or identifying the its
254 ZL if one exists. This is to prevent settled nodes that are ZL,
255 already members of zones or already part of another zone
256 construction process to change their status as this can
257 unnecessary increase their communication overheads and
258 can result into uncontrollable series of state oscillations
259 i.e. when a node frequently change its state. To allow suf-
260 cient time for all neighbouring nodes to receive the zone
261 construction call and to become a ZCP and prepare for the
262 next step, the announced zone construction end time is
263 calculated in a similar way to the NET_TRAVERSAL_TIME
264 parameter calculated in the AODV protocol [38]. This rep-
265 resents the maximum time in seconds a source node needs
266 to wait after sending a route request broadcast for the
267 reception of a route reply unicast. If the route reply is not
268 received within this NET_TRAVERSAL_TIME the source
269 node sends a new request for a broadcast. The
270 NODE_TRAVERSAL_TIME is a traditional way to calculate
271 the average one hop traversal time for packets and should
272 include queuing delays, interrupt processing times and
273 transfer times and NET_DIAMETER, which calculates the
274 estimate maximum number of hops between two nodes
275 in the network. In this research, The ZONE_CONSTRUC-
276 TION_ TIME is calculated dynamically and used to give just
277 enough time for all ZCPs to send/receive all necessary mes-
278 sages to accomplish the zone construction procedure.
279 2.2. Role assignment
280 When the zone construction time ends, the ZCPs sort
281 the received FFs and the rst occurrence of the best FF
282 identies the ZL. Consequently, each ZCP should, indepen-
283 dently, identify the same ZL (on the assumption that the
284 nodes are truthful and cooperative). ZCPs with a one hop
285 count become member nodes and put the ZLs IP in their
286 Hello headers, thus forming the zone. Any remaining ZCPs
287 located within a >1 hop count from the newly selected ZL
288 become idle nodes and subsequently, they may become
289 members of close by ZLs, otherwise they initiate a new
290 zone construction process. This process is repeated until
291 every node belongs to a zone and has its own ZL or is
292 one (see Fig. 2). The ZCG senses and discovers neighbours
293 via Hello messages and zones are limited by diameter R,
294 which is the number of hops from the ZL to its member
295 nodes (i.e. peripheral nodes). Limiting the R to a one hop
296 count has the following reasons and advantages.
297 (i) If large hop count values are allowed for the diame-
298 ter R, then the result will be a greater number of inter-
299 mediate nodes between the ZL and the peripheral nodes
300 that will responsible for relaying routing information
301 updates between the two. This would also require
302 maintaining a routing table map of which nodes could
303 be reached locally as well as involving designing a
304 mechanism similar to the (IARP [25] in the ZRP [26])
305 that facilitates local route optimisation inside the zone
306 by continuously discovering short routes between
307 member nodes and removing redundant and failed
308 links.
309 (ii) When a member node roams through new and large
310 zones, updates of such change will take a longer time to
311 reach the ZLs. This is because change notications will
312 need to be forwarded to the member nodes at the rst
313 level (two hop count), if it exists, which in turn will be
314 passed to the member nodes at a one hop count and
315 then to the ZL. However, with the one hop member
316 nodes of the ZL zones in this system, notications can
317 be given directly to the ZL nodes.
318 (iiii) Reducing the hop count to one allows for more ZLs
319 in a network and therefore, reduces the time and infor-
320 mation needed to recover a ZL node failure.
321 (iv) Allowing for a reasonable number of ZLs to exist in
322 the network reduces the burden of this role to those
323 nodes undertaking it, since they have to deal with fewer
324 member nodes, which will mean fewer updates in oper-
325 ations and the data size of the member nodes stored by
326 the ZL nodes becomes smaller.
8 October 2014
dx.doi.org/10.1016/j.adhoc.2014.09.010
327
328 2.3. Calculating the Fitness Factor (FF)
329 The zone construction protocol is used to identify a zone
330 leader, whereby nodes with the most desirable attributes,
331 such as: minimum mobility, a high degree of connectivity
332 and plentiful battery power, are preferred for the ZL role.
333 A similar approach to the Weighted Clustering Algorithm
334 (WCA) algorithm [13,14] is adopted in the ZCG to calculate
335 the FF of the nodes forming the zones. WCA is a distributed
336 approach that considers various network factors, such as
337 transmission power, the degree of connectivity, mobility
338 and the available battery power when selecting cluster
339 heads in ad hoc wireless networks. One main advantage of
340 this algorithm is that these factors are given different
341 weights to form clusters that suit various scenarios and
342 applications. For example, if the WCA is implemented in
343 sensor networks, which consist of nodes with limited
344 energy storage capability, the battery power weight is set
345 to become the highest to select a cluster head with the high-
346 est battery power, hence prolonging the overall energy life-
347 time of the sensor network. In the ZCG, the WCAweights are
348 recongured in order to split the network into stable clus-
349 ters. This is implemented by selecting ZLs that are less
350 mobile and that exhibit a similar mobility pattern (in terms
351 of speed, direction and manoeuvrability) with other
352 members in the zone. Also, ZLs need to show reasonably
353 high battery power to deserve this role. In the following,
354 the main features of the FF algorithm are briey discussed.
Fig. 2. The owchart shows the rst phase of the proposed protocol for identifying zone leaders.
8 October 2014
dx.doi.org/10.1016/j.adhoc.2014.09.010
355 (i) The ZLs selection mechanism does not take a long
356 time and it is not performed proactively/periodically,
357 only being performed on demand. Moreover, they are
358 selected based on reliability factors so as to prolong
359 the life time of the zone they lead, which reduces the
360 overheads associated with the ZCP and hence the
361 computation cost.
362 (ii) In contrast to WCA algorithms [13,14], the FF algo-
363 rithm aims to reduce the number of clusters in the net-
364 work by not limiting the number of nodes in the cluster.
365 That is, the former supports a predened threshold of
366 nodes in each cluster for efcient medium access con-
367 trol (MAC) so as to avoid channel access delays. This
368 is because the cluster heads in this protocol are
369 designed to relay all inter communications between
370 clusters/zones, whereas the ZCGs ZLs are only responsi-
371 ble for initiating the route discovery process and this
372 leads to at multi-hop routing rather than a hierarchi-
373 cal form.
374 (iii) Mobility is a fundamental factor when selecting a
375 ZL. In this regard, a ZL that moves randomly and quickly
376 relative to its neighbours causes frequent and dramatic
377 changes to the zones structure in the network. Mobility
378 of the nodes in a MANET is inevitable and this is why
379 the ZL selection mechanism aims to reduce their num-
380 ber in the network as well as choosing those with less
381 mobility to take on the role. Hence, the majority of
382 nodes that tend to move with high velocity and an
383 unpredictable mobility pattern should become member
384 or isolated nodes. The mobility of these nodes will
385 result in minor updates whenever they leave or join
386 another zone.
387 (iv) Another fundamental factor that is considered
388 when selecting ZLs is battery power. Although the ZL
389 is not responsible for the inter routing between the
390 zones as is the case for cluster heads in other protocols,
391 such as the: CGSR [15], HC [37], MOBIC [7] and the WCA
392 [13,14], it still consumes more battery power than other
393 nodes in the ZCG protocol due to its associated high
394 computation costs.
395
396 Calculating the FF is performed using a weighted mean,
397 which uses similar parameters to those used in the WCA
398 [13,14]. However, the WCA assumes the availability of
399 the exact coordinates of the nodes locations, possibly by
400 using a GPS system and the signal strength detection
401 mechanism. Such technologies add complexity and cost
402 to a mobile device and consume high energy. Additionally,
403 these technologies can cause PHY/MAC/NETWORK layers
404 compatibility issues. Instead, the propagation delay of
405 WLAN packets using Hello messages is adopted in order
406 to determine the relative distance between two wireless
407 nodes. This approach has been studied in [22], which used
408 the IEEE 802.11 data/acknowledgement sequence to calcu-
409 late the averaged round trip delay. They showed through
410 experimental study that the distance and the measured
411 propagation delay correlate closely, only having a small
412 error rate of a few metres. This is a feasible approach since
413 messages are already being utilised in the WCA and ZCG
414 and most clustering algorithms to sense neighbours in
415 wireless ad hoc networks. Moreover, in the ZCG, knowing
416 the exact physical distance between any two nodes is not
417 necessary, for only an estimated measurement of the dis-
418 tance to know how far/close the nodes are located from
419 each other during a time interval is required. This also
420 helps the ZCG calculating the rate of change of the nodes
421 movement and possibly their mobility direction, which
422 are the main factors that decide on how stable a node is
423 relative to its surrounding neighbours. Moreover, only
424 during the zone construction time will each Hello message
425 require an acknowledgement from its receiver and this is
426 unicast back to the Hello generator node.
427 Each ZCP needs to calculate the distance to its one hop
428 neighbours using the time stamps from Hello/Acknowl-
429 edgement packets received from all of them. Each node
430 will store the distance and the delay times in a list in an
431 entry in the neighbour routing table and each entry is
432 uniquely identied by the neighbours addresses (ID).
433 Moreover, the packet propagation time used to compute
434 the nodes distances excludes the MAC processing time
435 and queuing delays, the latter being one factor that shows
436 the contention level between the nodes over the channel
437 and therefore, is the node density within the wireless
438 range. In addition, it is important that the nodes local
439 clocks are assumed to be synchronised. The following Eq.
440 1 is used to calculate the distance between nodes in metres
441 [22]. During phase 1, each node that accepts the zone
442 construction call sent by the ZCO, becomes a ZCP and forms
443 a temporary cluster with all one hop neighbours during the
444 zone construction mechanism (see Fig. 3). Suppose there
445 are T clusters # C
1
; . . . ; C
T
f g, and that C
T
N
i1
; . . . ; f
446 N
im
g, which means each cluster has a set of m nodes where
447 for each N
ij
2 C
i
. In phase 2, during the zone construction
448 time, each node N
ij
calculates its tness factor F
ij
relevant
449 to all its neighbours N
im
in the cluster C
i
.
450
d
ct
remote
t
local
2
1
452 452
453 where d is the distance and c is the speed of light
454 c 3 10
8
m/s. t
remote
denotes the time duration between
455 starting the transmission of a Hello packet and receiving
456 the corresponding acknowledgement. t
local
represents the
457 time duration of receiving one Hello packet and sending
458 out an acknowledgement. By subtracting the t
local
from
459 the t
remote
the outcome result represents the approximate
460 propagation time. To increase the accuracy of the distance
461 estimation, the ZCG uses multiple delay observations. The
462 sum of the distances to all its neighbours N
il
is calculated
463
so that j
ij

P
m
l1;ij
d
avg
N
ij
; N
il
. Subsequently, n Hello
464 messages are sent in order to get the average distance
465 within the time duration t, where d
avg
N
ij
; N
ik

466
P
n
D1
d
D
N
ij
;N
ik
n
, where d
D
is d in the above Eq. 1. The FF helps
467 to distinguish reliable ZLs, so that the zones they are lead-
468 ing are stabilised for the longest possible time duration.
469 In addition, an important element of reliability in ad
470 hoc communication is links stability, which can be mea-
471 sured by the link expiration time that is the maximum
472 time of connectivity between any two neighbouring
473 nodes [34]. The ZCG calculates the distances between
474 neighbour nodes from the Hello messages received during
475 the ZONE_CONSTRUCTION_TIME. Moreover, under this
8 October 2014
dx.doi.org/10.1016/j.adhoc.2014.09.010
476 protocol it is possible to predict the rate of growth/decay
477 of the distance between any adjacent nodes and calibrate
478 their direction. For example, using the k
ij
in 2, if the out-
479 put value is positive, this means there is an increase of
480 distance over time, which clearly indicates that the two
481 nodes in question are moving apart, and therefore, the
482 link will not be stable. This is because when the distance
483 between two nodes becomes larger than the transmission
484 range the nodes are likely to be disconnected [34]. On the
485 other hand, if the value is negative, then this can be
486 understood as a sign of the node movement being
487 towards each other.
488
k
l
ij
N
ij
; N
t
1
il
; N
tn
il

d
D
N
ij
; N
t
1
il

d
D
N
ij
; N
tn
il

!1
n
1 2
490 490
491 Let N
t
1
ij
be the position of node N
ij
at time t
1
. For every
492
node N
ij
there is a set of m values of k
l
ij
. That is,
493
k
ij
k
1
ij
; . . . ; k
m1
ij
n o
. Then, the degree-difference of the
494 node N
ij
mobility relative to all neighbours inside the clus-
495 ter C
t
needs to be computed. The n in
1
n
represents the num-
496 ber of Hello message received during a dened time
497 interval. The collective local mobility of a node N
ij
can be
498 found by computing the standard variation a
ij
of the entire
499
set of the neighbours relative mobility values k
l
ij
as shown
500 in the following 3. To form a reliable cluster in term of
501 motion stability, each node is required to compute the
502 relative mobility of all direct neighbours. This performed
503 by measuring the variance of relative mobility for every
504 neighbour, which allows the cluster nodes to select the
505 node with the least mobility ratio with respect to all
506 members and that with the lowest a
ij
is elected to be their
507 head for better cluster stability. A large a
ij
value indicates
508
that the set of k
l
ij
values, which shows average change rate
509 in distance with N
tn
il
over a particular time period, are
510 highly spread out. This is an indication of the instability
511 of node N
ij
in relation to all neighbours N
im
inside cluster
Fig. 3. The owchart shows the second phase of the proposed protocol for identifying zone leaders.
8 October 2014
dx.doi.org/10.1016/j.adhoc.2014.09.010
512 C
T
. That is, this node due to its group mobility and large
513 distances within the group is likely to part company with
514 them fairly soon.
515
a
ij

1
m1
X
m
l1
k
ij
k
2
r
3
517 517
518 where k
P
m
l1
k
c
ij
m
. ZCPs use the weighted mean formula of
519 Eq. 4 to calculate their tness value using local data, where
520 b
ij
determines how much battery power has been
521 consumed.
522
F
ij
x
1
:a
ij
x
2
:j
ij
x
3
:b
ij
4 524 524
525 The values of a
ij
here in m/s and j
ij
are obviously highly
526 correlated. For example, when a ZCP moves at a high rate
527 in comparison to its neighbour, as indicated by a high a
ij
528 value, the larger the j
ij
value, the larger the negative effect
529 it introduces into the FF. This is because a distant node
530 while moving at a higher speed is more likely to go quickly
531 outside its neighbour coverage area. On the other hand, a
532 node moving closer with a lower speed or the same is
533 likely to stay longer within the neighbour coverage area
534 than in the former case. The weights x
1
; x
2
and x
3
are
535 normalised such that they sum up to 1, i.e.
P
3
i1
x
i
1.
536 The weights considered for the FF calculation are
537 x
1
0:5, x
2
0:3, x
3
0:2 for stable zones. That is,
538 higher weights are given to a
ij
and j
ij
than to b
ij
in order
539 to maximise the connectivity time between ZLs and their
540 member nodes, hence, maximising the network zones life-
541 time and the backbone channel through which ZLs com-
542 municate and exchange essential updates related to the
543 network member nodes. Moreover, similar weight distri-
544 bution was used in the studies [13,14]. a
ij
represents the
545 rate of change in term of mobility and direction of move-
546 ment in relation to the nodes neighbours. As mentioned
547 earlier, for high zone stability a
ij
was given the highest
548 weight so that the link between two nodes stays for the
549 longest possible time due to the lack of relative motion
550 between them. In fact, there are other factors than node
551 mobility that can also cause link failures between nodes,
552 such as multiple-user interference and packet collisions.
553 However, the link failures caused by these factors are nor-
554 mally less severe and last for a shorter time interval before
555 the link gets recovered so long as the neighbour to which
556 the connectivity was lost physically still exists inside the
557 wireless range of the node.
558 Less weights were given to the value j
ij
between the
559 nodes. Higher or similar weights to a
ij
could have been
560 given here, especially if the generally accepted assumption
561 was used that nodes located far away are likely to quickly
562 move outside the wireless range of each other either due
563 to mobility or channel quality [34]. However, this is not
564 necessary true in all cases. For example, there would be
565 some cases when a node is far a way, but moves towards
566 another at a slow speed, as well as those nodes located
567 far apart, but are moving in parallel and in the same direc-
568 tion with each other. In the former case, the node will stay
569 inside the node coverage area for a longer time, because it
570 will move inside the full radius of node xs wireless range.
571 whereas in the latter case, the node will stay in the cover-
572 age area of node x for a long time, given that both nodes are
573 moving at a similar speed then the variance of the nodes
574 mobility represented as a
ij
is equal to a small value, or even
575 to zero in extreme cases if both nodes are moving at the
576 exact same speed. The least weight was given to battery
577 power, for although this is important, one of the ZCGs nov-
578 elties is that the ZLs do not act as gateways to pass data
579 between and inside the network zones. Instead, they only
580 coordinate the routing process between the network mem-
581 ber nodes and this will be elaborated further in the follow-
582 ing text. Eventually, the node having the smallest FF is
583 selected as the ZL and its one hop neighbours automati-
584 cally become member nodes of the zone (see Fig. 3).
585 2.4. Network routing protocol
586 When a node becomes a ZL, it starts announcing its role
587 through Hello messages. Any idle node that exists in the
588 wireless range of the ZL and receives these Hellos can reg-
589 ister itself as a member node to it so as to construct a zone.
590 Member nodes of adjacent zones can distinguish
591 themselves by broadcasting their ZLs ID addresses in their
592 periodic Hello messages.
593 If an idle node is located in the wireless range of two or
594 more ZLs, then it becomes a member node to the nearest ZL
595 by calculating the ETE delay
1
of all Hello messages received
596 from them. The node broadcasts a SORRY message that
597 includes the reason that inuenced this selection, i.e. the
598 ETE delay to the newly selected ZL node and given that this
599 message is a broadcast all ZLs including the recently chosen
600 one will hear this. Moreover, all ZLs can calculate the ETE
601 delay of the SORRY to verify the integrity of the decision.
602 The ZL proactively multi-casts ID lists to all ZLs in the
603 network to maintain a global view of all existing ZLs and
604 their linked members in the network, which is necessary
605 so that they can assist in the path discovery process
606 (explained in the following subsection). This proactive data
607 exchange is event based, whereby when a node joins/
608 leaves a zone, its ZL will notify other ZLs of the event and
609 provide the ID of the responsible node. A multi-cast of
610 complete ID lists is only performed following new zone
611 formation. The data exchanged between the ZLs is extre-
612 mely lightweight (just ID addresses) and infrequently
613 updated in comparison to topological data, which is large
614 and frequently changing.
615 2.4.1. Zone failure
616 To address the case of a single point of failure, it is noted
617 that the new ZL can be the member node of the second
618 highest tness value found during the zone construction
619 protocol. However, after investigating various scenarios it
620 was decided to allow the nodes to become idle again and
621 perform a new zone construction process or simply join
622 nearby zones as member nodes, if at least one ZL existed
623 within their wireless range. This decision was made for
624 the following reasons: the FFs of nodes can change quickly
625 in a MANET; it is likely that nodes that join zones after the
1
End-to-end delay refers to the total time it takes for a packet to be
transmitted across a network from a source to a destination. This includes
the transmission delay, propagation delay, processing delay and queuing
delay that the packet may experiences on each hop along the path.
8 October 2014
dx.doi.org/10.1016/j.adhoc.2014.09.010
626 construction process has taken place have lower FFs than
627 all the zones member nodes and the node with the second
628 lowest FF may not be located in a central location with all
629 member nodes of the previous ZL. This will make a new
630 zone construction process inevitable, being performed by
631 the members of the old ZL whose locations are two hops
632 away from the node with the second lowest FF. As the
633 zones in the ZCG are highly distributed, i.e. only one hop
634 count diameter from the ZLs, then ZL failures should not
635 have any disastrous consequences for the network and
636 their recovery should be manageable within a reasonable
637 time scale. Basically, the zone exists in the network for as
638 long as its ZL remains. If the ZL disappears for various
639 reasons, such as motion or runs out of battery power, then
640 the ZL entries stored at the zone members will expire as
641 they are not being refreshed by Hello messages sent by
642 the ZL. When these entries expire, all zone members will
643 become idle nodes, and some/all can both join nearby
644 zones and become zone members, or they can repeat the
645 zone construction process to select a new ZL. The newly
646 selected ZL immediately broadcasts a RREQ message to
647 announce its existence to the networks ZLs, and constructs
648 its view of the existing backbone channel.
649 2.4.2. Path discovery (parallel collision guided broadcasting in
650 the ZCG)
651 Consider a node S in zone C that wants to connect node
652 D in zone F (see Fig. 1). Node S will place the request with
653 its local ZL(C) node and the latter should know that the
654 former exists in zone ZL(F) due to the proactive data
655 exchange among the network ZLs. ZL(C) will calculate a
656 time estimate that allows parallel broadcasting from both
657 S and D during the routing phase. The outcome will help
658 ZL(C) to decide on the timing and order when forwarding
659 two Path Discovery Commands (PDC) message to ensure
660 that they reach D via ZL(F) and S at the same time. Fig. 4
661 illustrates ZL(C)s operations. The PDCs contain the target
662 ID address which each end S and D need to target during
663 their broadcast, the ZTL value(explained later), the broad-
664 cast ID, and the broadcast initiation time.
665 When S and D receive the PDC message, they broadcast
666 route request messages (RREQs) in order to nd one
667 another and rebroadcasting continues at intermediate
668 nodes until a positive RREQ-collision occurs. That is, when
669 an intermediate node receives RREQs generated from both
670 ends with identical broadcasting IDs and the source ID
671 address of one RREQ is the same as the destination ID of
672 the other and vice versa. If a bidirectional route is required,
673 two route reply messages (RREPs) will be generated and
674 forwarded to S and D by the node at which the RREQ-col-
675 lision has taken place. On the other hand, if a unidirectional
676 route is required, only one RREP is generated, which tra-
677 verses back via intermediate nodes to S to set half of the
678 newly discovered forwarding path to D, while the forward-
679 ing path constructed by the nodes to D is set by RREQs
680 generated from D.
681 In order to increase the likelihood of RREQ-collision at
682 intermediatenodes, uponthe arrival of a ZCGparallel broad-
Fig. 4. Basic owchart for the initiation of the parallel collision guided broadcasting at the ZL of the source node S to discover node D.
8 October 2014
dx.doi.org/10.1016/j.adhoc.2014.09.010
683 casting packet RREQ at the intermediate nodes along the
684 requested path, they immediately store any route request
685 information in a temporary request table. Before the packet
686 gets retransmitted the node checks its temporary request
687 table for any broadcasting request that may have been
688 received before or after the arrival of the other end request
689 packet and a RREQ-collision would indicate the discovery
690 of a new path between the source and destination pair.
691 The wait betweenthe request packet arrival andretransmis-
692 sion, if necessary, varies depending on: the network load,
693 broadcast jitter, the channel quality and the effect of the
694 presence of other competitive nodes in the MANET. Inter-
695 mediate nodes may also performsome checks in their cache
696 for any known path for the same destinations.
697 Searching routing tables at intermediate nodes is per-
698 formed with hash tables to save routing entries, which take
699 up a constant search time. That is, taking into consideration
700 the nodes low processing capability and capacity and the
701 constantly changing routing data due to their mobility, small
702 hash tables are used to speed up the access to data. This is
703 because the cost of an efcient hash function can be more
704 expensive in terms of a nodes power consumption and
705 capacity than if a search loop algorithm is used in a sequen-
706 tial list [19]. Moreover, many routing protocols use hash
707 tables to implement caches, and the hash keys used in these
708 cases are the nodes MAC/IDaddresses. For these reasons and
709 because multiple requests for a particular destinationmay be
710 initiated by different nodes at the same time, frequent hash
711 collisions may occur, which leads to different keys mapping
712 to the same hash value. In the ZCG, hash collisions can be
713 handled by removing one of the two colliding entries by
714 overwriting the old entry with the new item, so every entry
715 in the table is up-to-date and has a unique hash value.
716 2.4.3. Reduction of redundant re-broadcasts(ZCG member
717 nodes role)
718 Routing between distant nodes of two different zones is
719 done by a similar strategy to the TTL in the AODV [38], but
720 instead of hop numbers Zone to Live (ZTL) is used. This is
721 the number of zones a RREQ needs to cross before it gets
722 discarded, that is, when the ZTL value is zero. Member
723 nodes act as defence walls to protect their zones from
724 rebroadcasting unnecessarily. The ZTL value is maintained
725 during the proactive data exchange between ZL nodes as
726 these can readily identify the number of zones between
727 themselves in the network.
728 2.4.4. Route maintenance
729 The ZCG supports link failure maintenance similar to
730 that used in the AODV routing protocol [38]. That is, its
731 nodes use periodic Hello messages or any packet such as
732 RREQ and RREP to sense link status of their neighbours that
733 are part of active routes, so when a link failure is perceived
734 by one or more nodes, a Route Error Packet (RERR) message
735 will be sent to announce a list of all unreachable destina-
736 tions caused by this link failure to interested neighbours,
737 known as the precursor list,
2
which are likely to use this
738 node as the next hop to reach these destinations. The pro-
739 cess of repairing a broken link requires the following (i)
740 invalidate existing routes; (ii) grouping affected destina-
741 tions; (iii) selecting the direct neighbours that are affected
742 by the link breakage; (iv) sending a Route Error Packet
743 (RERR) message to these neighbours. A Route Error Packet
744 (RERR) can be broadcast if there are multiple precursors or
745 unicast if only one precursor exists. Moreover, a node that
746 detects a link breakage in an active route, and that exists
747 upstream of the broken link has the option to repair locally
748 the broken link, if it exists within a specic number of hops
749 to the destination. To do so, it needs to increment the desti-
750 nations sequence number and broadcast a RREQ for that
751 destination. This message is sent with a determined TTL in
752 order to control the broadcasts and prevent them from
753 reaching unnecessary network branches. That is, utilising
754 local repair reduces the amount of rebroadcasts required, if
755 the route repair process is initiated by the source node. Also,
756 the local repair mechanism reduces the time latency
757 required to repair broken links in long paths. This is because
758 a source node needs a longer time to realise a broken link
759 located far away as this involves sending an (RERR) from
760 the node detecting the link breakage as well as the source
761 node needing to perform a pure ooding to establish new
762 routes to the disconnected destination.
763 3. Energy consumption model
764 At each network node, the energy cost of each packet
765 was computed as the total of incremental cost m relative
766 to the packet size and b is a xed energy cost associated
767 with channel acquisition.
768
Cost
watts
m size b 5 770 770
771 In [20], the experimental results conrmed the accuracy
772 of the linear model and were used to determine values for
773 the linear coefcients m and b for various operations. The
774 power consumption values for transmit and receive pack-
775 ets as measured in Feenys experimental results [20] was
776 used. Subsequently, the model was employed to compare
777 the energy consumption in non-ideal simulation condi-
778 tions to calculate the inuence of interference and packet
779 collision on energy consumption. By so doing, the precise
780 measurements of energy consumption in the network
781 nodes while forwarding routing/data trafc ow were
782 determined. Table 2 on page 8 illustrates the energy con-
783 sumption results, specifying the linear coefcients for each
784 packet-associated operation.
Table 2
Power consumption measurements for LUCENT IEEE 802.11 11 Mbps card
[20].
Packet operations
uW s=byte
8
size uW s
Point-to-point send 0:48 size 431
Broadcast send 2:1 size 272
Point-to-point receive 0:12 size 316
Broadcast receive 0:26 size 50
Promiscuous recv 0:39 size 140
Discard 0:11 size 66
2
At intermediate nodes, each routing entry of valid and active routes
stored at the nodes routing table consists of a list of precursor nodes that
have been forwarding packets on this route.
8 October 2014
dx.doi.org/10.1016/j.adhoc.2014.09.010
785 By implementing Eq. 5 above, the total cost of the
786 energy consumption associated with a packet was the
787 sum of the energy acquired by the transmitting node/s
788 and all the receiver nodes. Possible receiver nodes of the
789 packet included the destination node, all the nodes that
790 were in the wireless ranges of the source node and all
791 those located inside the wireless range of the destination
792 node. This energy model has been experimentally proven
793 and is widely used as well as being accepted in many stud-
794 ies as forming a sound basis for the design and assessment
795 of energy-aware/energy efcient routing protocols that use
796 the IEEE 802.11 wireless technologies e.g. [3,20]. In our
797 study, it was assumed that the energy used by the node
798 while being idle was null, because all the tested routing
799 protocols shared the same energy consumption during
800 the time when the node was in a idle state.
801 4. Experimental plan
802 OPNET [36], a discrete event simulation tool, was used
803 to simulate the ZCG, AODV and DSR routing protocols for
804 MANETs in order to test and compare their routing perfor-
805 mance and efciency. All the protocols were simulated on
806 a 1 km
2
grid with 100 nodes and for statistical reliability
807 2000 simulation runs with random seeds were performed.
808 Most runs lasted 3600 s to allow sufcient time for the
809 network to complete the set-up process [4], and to perform
810 a reasonable number of attempts to establish routes (if
811 they did not already exist) to all pre-specied mobile des-
812 tinations. That is, in all scenarios a source node generated 5
813 unicast trafc packets (1024 bits/s) to ve dened destina-
814 tion nodes, with User Datagram Protocol (UDP) protocol in
815 a constant packet inter-arrival time of 200 s. Note that all
816 trafc sessions to the destinations were established inde-
817 pendently in parallel while varying the time interval
818 between each transmission to avoid channel contention
819 and delays caused by a large number of queued packets.
820 This light weight trafc was used because the aim was to
821 test the fundamental routing discovery and maintenance
822 procedures of the routing algorithms rather than the data
823 packets order and their bit-error rate. Moreover, each pro-
824 tocol was tested with the same initial conditions and seeds.
825 All wireless node models are associated with 802.11
826 interfaces with 11 Mbps date rate. The nodes wireless inter-
827 face was congured to cover an average area of approxi-
828 mately 250 m
2
when no interference and physical
829 obstacle was present. Also, all queued packets in/out packet
830 streams were cleared out to emulate a realistic node failure.
831 The standard random waypoint mobility model was
832 employed to produce the nodes motion, with uniform dis-
833 tribution to generate speed values between 0 and 15m/s.
834 That is, at the beginning of each simulation run, each node
835 was given a random speed value covering: static, moving
836 at an average human walking/running speed of 1.22.0 m/
837 s, or as a vehicle at 215 m/s (455 km/h).
838 In order to test the various aspects of the protocol ef-
839 ciency, three different scenarios were set up which are
840 described as follows.
841 (a) In Section 6.1 all nodes were allowed to move freely
842 using the aforementioned random waypoint model, while
843 assigning different mobility speed and battery power to
844 the nodes. This was performed to test all possible cases,
845 and to check the protocols performance and ability to
846 adjust during uncontrolled network behaviour, structure
847 and mobility speeds. (b) In Section 6.2 some nodes tness
848 factors and mobility parameters were controlled. That is,
849 these nodes were given the highest tness factor status,
850 no mobility and distributed randomly in the network in
851 order to become ZLs. This was carried out to control for
852 the number of zones during all the simulation runs and
853 helped in the understanding of the effect of the ZTL param-
854 eter (when controlled) and the stochastic broadcasting
855 control due to the parallel collision guided.
856 5. Performance parameters
857 In order to analyse the performance of the routing
858 protocols, various quantitative metrics were used for com-
859 parisons of those selected and the parameters chosen
860 were: total routing trafc received (bits/s), reachability
861 ratio, route discovery delay (s), network delay (s), total
862 broadcast retransmission (packets). In other words, in
863 order to test the routing protocols effectiveness in discov-
864 ering new routes to relay data in an ad hoc manner, it was
865 deemed necessary to investigate each of these in turn as
866 below.
867 Routing trafc received: this represents the amount of
868 routing trafc received in bits/s in the entire network.
869 This trafc includes all the protocols control overheads,
870 such as: Hello messages, route request/reply packets,
871 route errors and maintenance packets, routing updates
872 and acknowledgements. Routing trafc has a high
873 impact on the network throughput, which is the aver-
874 age rate of successful message delivery over a commu-
875 nication channel. Usually, the larger the routing trafc
876 used by a routing protocol, the less throughput is avail-
877 able for actual data trafc goodput. Goodput is the
878 application layer throughput, which is the number of
879 applicable information bits received from the network
880 at particular destination nodes per second. All lower
881 layer protocols overheads and retransmitted data pack-
882 ets were kept out during the calculation of goodput.
883 Reachability: is dened as the fraction of possible
884 reachable routes to all possible routes between some/
885 all different sources to some/all different destinations
886 [30]. This statistic was collected in order to measure
887 the percentage of the successful routing discovery
888 attempts that managed to discover at least a single
889 route to every requested destination using the various
890 discovery mechanisms out of the total number of rout-
891 ing discovery attempts during a simulation run.
892 Route discovery delay: this represents the time delay
893 needed to discover a route to particular destination
894 nodes. This can be calculated from the moment when
895 a route request is sent out by a source node to discover
896 a route to a desired destination, until the time a route
897 reply is received at the source node with a route to that
898 destination.
899 Broadcast retransmission: which is the average number
900 of times each node in the network is required to
8 October 2014
dx.doi.org/10.1016/j.adhoc.2014.09.010
901 rebroadcast packets to its neighbours whenever they
902 receive packets in a single broadcasting session. Each
903 broadcasting session is labelled by a unique identier
904 and broadcasting in routing protocols is normally used
905 in order to discover new routes to one or more destina-
906 tion nodes. They may also be used to x/refresh the
907 routing tables of already existing routes.
908
909 6. Results
910 6.1. Varying nodes speed
911 In this experiment all nodes were allowed to move
912 freely using the aforementioned random waypoint model,
913 with all being randomly associated with different mobility
914 speed and power levels. This experiment was performed to
915 examine all possible cases, and to check the protocols
916 performance and ability to adjust in uncontrolled network
917 behaviour, structure and the various mobility speeds of the
918 network nodes.
919 6.1.1. Total routing trafc received (bits/s) (Fig. 5)
920 Fig. 5 represents the total routing trafc received (in
921 bits/s). Any data trafc that is relayed by a node in wireless
922 ad hoc networks may be counted multiple numbers of
923 times for this statistic (once at the source node and once
924 at the receiver nodes), since both the source and destina-
925 tion nodes have to compete for their transmissions via a
926 shared physical medium. This trafc includes routing traf-
927 c, routing maintenance/repair or actual trafc data. Such
928 trafc is generated in various frequencies and its volume,
929 as mentioned earlier, depends on the routing protocol
930 type: reactive, proactive or hybrid. Moreover, all routing
931 protocols use pure broadcasting at some stage during the
932 route discovery phase. In addition to this, some unicast
933 and multicast operations could occur for reasons such as
934 sending path discovery acknowledgements and route
935 maintenance. Each protocol acts differently to reduce
936 redundant broadcasts from spreading thorough the net-
937 work branches further than necessary before/after nding
938 a route to the requested destination node. Fig. 5 displays
939 trafc in bits/s. It is clear that the AODV produces the
940 highest number of routing overheads, which is due to the
941 pure broadcasting and the proactive use of Hello messages.
942 Although the ZCG generates slightly fewer broadcast mes-
943 sages, the Hello messages and broadcasting (i.e. parallel
944 and distributed broadcasts) are also used to nd the
945 desired destination. This nding, while preliminary,
946 suggests that the ZTL technique and the stochastic broad-
947 cast control (caused by the parallel collision guided broad-
948 casting) of the ZCG protocol manages to reduce redundant
949 rebroadcasting somewhat.
950 The ZCG offers a further small reduction in the over-
951 heads generated by route replies prior to the occurrence
952 of RREQ-collision. In the AODV when broadcasting is initi-
953 ated and reaches the required destination, the route reply
954 packet (RREP) generated in response by the destination
955 node performs backward propagation through the entire
956 newly discovered route to reach the source. On the other
957 hand, when a RREQ-collision occurs due to the parallel
958 broadcasting in the ZCG the RREP will be generated by
959 the node at which the RREQ-collision has taken place,
960 which is usually closer to the source node than the destina-
961 tion. This RREP traverses back via intermediate nodes to
962 the source to set half of the newly discovered forwarding
963 path to the destination node, while the forwarding path
964 on the nodes to the destination node is set by broadcast
965 packets from the other end.
966 From Fig. 5 it can be seen that the DSR seems to work
967 incredibly well in comparison to the former protocols.
968 However, it would be misleading to interpret this as a sign
969 of its superior strength without looking at its reachability
970 ratio 6. This is because unlike AODV and ZCG, DSR is bea-
971 con-less and hence does not require periodic Hello mes-
972 sage transmissions, which are used by a node to inform
973 its neighbours of its presence. These Hello messages con-
974 tribute hugely to the total number of overheads received
975 by the network which is the case ZCG and AODV. However,
976 these Hello messages have much less of an impact on the
977 network in comparison to broadcast messages as they are
978 transmitted to recipients that are only located within the
979 senders transmission range. These packets are ignored
980 upon reception and do not get retransmitted. Moreover,
981 in a MANET, there are other uncontrollable factors that
982 can discard redundant/necessary packets during the path
983 discovery process, such as: packet collisions, channel inter-
984 ference, temporary links dis-connectivity/network parti-
985 tions and routing tables update failures and all of these
986 may impact greatly on reachability.
987 6.1.2. Reachability ratio (number of successful attempts over
988 all path discovery attempts Fig. 6)
989 Fig. 6 shows the reachability ratio, which is the ratio of
990 successful route discovery attempts to the total number of
991 the protocol attempts to discover route/s to specic
992 destination/s. An attempt was considered successful, if
993 the source node got an acknowledgement in response to
994 a route request packet. It is highly probable that multiple
995 acknowledgements were received as a consequence of
996 multiple paths being discovered to a single destination,
997 or that further retransmission attempts were performed Fig. 5. Routing trafc received (bits/s).
8 October 2014
dx.doi.org/10.1016/j.adhoc.2014.09.010
998 at intermediate nodes during a distinct path discovery
999 session, due to channel interference or physical channel
1000 disconnection. However, all these cases were treated as a
1001 single successful attempt and in order to facilitate this,
1002 each path discovery attempt/broadcasting session was
1003 uniquely identied by an ID number.
1004 According to the experimental plan, each protocol was
1005 set to attempt to establish routes after a 200 s time interval
1006 to a number of predened destinations during each simu-
1007 lation run. It is important to mention that it was expected
1008 that in various scenarios, not all the tested routing
1009 attempts would be successful. This is not due to the proto-
1010 col design efciency or performance, but rather because
1011 uncontrolled edge cases, such as source/destination nodes,
1012 were out of network range. To overcome this, the same
1013 random seed sets were used while testing the protocol
1014 models and the simulation run-time was extended to
1015 3600 s.
1016 In Fig. 6 it can be observed that the DSR exhibits the
1017 worst performance of the protocols. However, although
1018 its reachability ratio is almost 50% less than that of the
1019 ZCG, it manages to stabilise in networks that consist of
1020 nodes with high velocity ranges. Fig. 6 also indicates that
1021 the ZCG protocol has done well and its reachability ratio
1022 decreases gradually with nodes with higher speed. More-
1023 over, the AODV shows almost a similar reachability ratio
1024 when the nodes velocity is slow, its performance degrades
1025 slightly when the nodes velocity range is increased from 2
1026 to 13 m/s. Furthermore, the ZCGs large condence
1027 intervals indicate high variation in the results obtained.
1028 In general, a high reachability ratio is a sign of the protocol
1029 efcient broadcasting technique, but this does not neces-
1030 sary imply there is a lesser amount of rebroadcasting
1031 performed by the network nodes. One obvious reason for
1032 the ZCGs high reachability ratio is its parallel collision
1033 guided broadcasting. Also, the ZLs proactive nature
1034 requires them to maintain proactively a backbone channel
1035 for their intercommunications and this allows for indirect
1036 regular updating to active links that pass through this
1037 channel as well as maintenance of the routing cache stored
1038 at nodes that exist in the wireless range of those that are
1039 part of the same channel.
1040 6.1.3. Route discovery delay (s) (Fig. 7)
1041 Fig. 7 shows the average routing delay that required the
1042 protocols to discover new paths to particular destination
1043 nodes. It is clear from Fig. 7 that the DSR exhibits the larg-
1044 est delay during the path set up phase.
1045 A possible explanation for this might be that its over-
1046 heads are potentially larger during the path set up phase
1047 and during forwarding trafc in general. For instance, its
1048 packet headers may carry full routing information,
1049 whereas the routing information in the AODV and the
1050 ZCG packets mainly comprise the source and destination
1051 addresses plus some lightweight information. Moreover,
1052 the broadcast packets of these two protocols are of a xed
1053 size, whilst the DSRs is directly proportional to the path
1054 length. Likewise, all unicast data packets (including route
1055 replies) in the DSR are also large since they carry a full list
1056 of the node addresses located along the newly discovered
1057 routes.
1058 The AODV path discovery mechanism has the second
1059 longest time delay, which is attributed to one side
1060 broadcasting, and packet collisions caused by blind packet
1061 ooding. By contrast, the ZCG had the fastest path set up
1062 mechanism amongst the protocols tested, which is due to
1063 its parallel collision guided broadcasting technique.
1064 Another reason that allowed the faster route set up in
1065 the ZCG and the AODV, with the former being the faster,
1066 is the proactive broadcasting of the one hop Hello packets,
1067 although this is one of the main causes of the increase in
1068 both algorithms overheads as depicted Fig. 5.
1069 6.1.4. Routing broadcast retransmission (Fig. 8)
1070 Fig. 8 shows the average number of broadcast retrans-
1071 missions during each path discovery session. Theoretically,
1072 N 2 forwarded broadcasts should be obtained, where N is
1073 the total number of nodes in the network, which is 100
1074 excluding the sender and receiver nodes. However, this is
Fig. 7. Route discovery delay (s). Fig. 6. Reachability Q7 ratio.
8 October 2014
dx.doi.org/10.1016/j.adhoc.2014.09.010
1075 an average number of broadcast retransmissions of ve
1076 broadcasting sessions performed sequentially and run in
1077 parallel to discover routes to ve distinct destinations
1078 during a dened time interval. Moreover, factors such as
1079 link disconnection, packet collisions, queue overow and
1080 temporary loops could have been caused by possible
1081 broadcast storms. All these reasons could have made the
1082 number of rebroadcasts exceed N. This statistic is a good
1083 measure to evaluate protocol performance in terms of
1084 detecting and discarding redundant packets from being
1085 rebroadcast during broadcast sessions.
1086 In this experiment, the ZCG showed the highest reach-
1087 ability ratio, while it produced a reasonably low number
1088 of redundant rebroadcasts as illustrated in Fig. 8. On the
1089 other hand, the DSR and AODV, higher to lower, produced
1090 extremely high numbers of redundant rebroadcasts, while
1091 their reachability ratio degraded when the networks were
1092 tested with high ranges of node velocities. This is due to
1093 the problem of broadcast storm, which causes packet colli-
1094 sions and possible loops. Although the DSR uses the high-
1095 est number of rebroadcast messages, it has the lowest
1096 reachability ratio. Considering the DSR routing overheads
1097 shown in Fig. 5, most of these can be condently attributed
1098 to the illustrated high broadcast redundancy shown in
1099 Fig. 8 and this is because the model limits the number of
1100 routing overheads by piggybacking the routing informa-
1101 tion in the packet header, which causes broadcast packets
1102 to be larger in size than number. In fact, it also uses blind
1103 broadcasting to x broken links stored at intermediate
1104 node caches.
1105 The number of tags shown in the Fig. 8 indicates the
1106 average number broadcasts performed by each node in
1107 the network during the simulation. This of course excludes
1108 the source and destination nodes.
1109 6.1.5. Energy consumption
1110 The simulation results in Fig. 9 illustrate the energy
1111 consumed (in watts/s) by the routing protocols, being from
1112 left to right the: AODV, ZCG and the DSR.
1113 The results represent the estimated total energy
1114 consumption required by the network in watts/s, while
1115 clearly identifying the energy required for each trafc type,
1116 such as transmitting data using the unicast/broadcast
1117 mechanism, receiving packets and discarding packets due
1118 to packet collisions and redundancy based on various rout-
1119 ing related mechanisms. These results include energy for
1120 total network trafc, such as routing and data trafc, and
1121 the DSR in this case is receiving data in promiscuous mode.
1122 As was observed above, the DSR exhibited the best per-
1123 formance with regards to the network bandwidth usage,
1124 but here it can be seen that it has high energy consump-
1125 tion. For example, in Fig. 9 it clearly be seen that this
1126 protocol uses noticeably more energy for sending and
1127 receiving broadcast packets. Additionally, it has dramati-
1128 cally higher power consumption for dropping and
1129 broadcasting control packets, which is due to its use of pro-
1130 miscuous mode as discussed above. Nevertheless, despite
1131 the partial proactive behaviour for maintaining the ZLs
1132 backbone, the ZCG shows a reasonable power consumption
1133 when node velocity is lowest at 02 m/s, and the it contin-
1134 ues to perform as the second best energy efcient protocol
1135 when compared to the AODV. Notably, the AODV and ZCG
1136 consume relatively similar energy levels for sending and
1137 receiving unicast packets and discarding, however, the
1138 ZCG outperforms the AODV in respect of the energy
1139 required to send and receive broadcast messages.
1140 6.2. Varying the ratio of reliable nodes (ZLs in ZCG)
1141 For this experiment, the number of reliable nodes in the
1142 network was increased by setting their tness factors
1143 higher and hence, those nodes exhibited low speed or no
1144 mobility at all. They were also set to have innite battery
1145 resources in order to become ZLs. ZLs nodes were ran-
1146 domly uniformly positioned at the beginning of each sim-
1147 ulation run. In addition, the zone construction protocol
1148 was disabled in order to control the number of ZLs during
1149 the tested scenarios and thus, a large amount of the trafc
Fig. 9. MANET power consumption varying speed stacked.
Fig. 8. Number of broadcast retransmission.
8 October 2014
dx.doi.org/10.1016/j.adhoc.2014.09.010
1150 associated with the ZL selection mechanism was excluded
1151 from these experiments. However, this trafc was not
1152 signicant since most of this mechanism was included in
1153 the Hello messages used to sense the existence of
1154 neighbouring nodes within the ZLs wireless coverage area.
1155 Disabling the ZL selection mechanism allowed for the
1156 quantication of the effect of the number of ZLs in the
1157 network in terms of the protocols scalability factor and
1158 the different dependency levels of the member nodes by
1159 varying the number ZLs in the network. Moreover, it pro-
1160 vided information that could be use to assess the correla-
1161 tion between the protocols overheads and ZLs. The
1162 random waypoint mobility model was used to simulate
1163 the nodes mobility pattern and their mobility speeds were
1164 uniformally distributed in the range 015 m/s. These
1165 experiments were performed by testing a network that
1166 consisted of 100 nodes, while increasing the number of
1167 ZLs in the network from 20%, 35%, and 50%. The last is
1168 the extreme case and refers to when the protocol assigned
1169 one ZL for each member node in the network, which meant
1170 that at least half of the network nodes were static with
1171 high power resources. In order to maintain fairness when
1172 testing the other protocols that do not exercise the concept
1173 of clustering and ZLs, the tests were congured to the
1174 extent that the selected nodes, which were chosen to take
1175 the ZL role in the ZCG scenarios, also had: the same initial
1176 position, the same mobility pattern/speed and resources.
1177 6.2.1. Total routing trafc received (bits/s) (Fig. 10)
1178 Fig. 10 illustrates the routing trafc received in the
1179 network and it can be seen that the ZCG produces less
1180 overheads than the AODV with 20% and 35% ZLs. Notably,
1181 the formers overheads increase with 50% ZLs, whereas
1182 the latters continued to decline gradually with more reli-
1183 able nodes, i.e. nodes with low/no mobility and innite
1184 power resources.
1185 This contradicts the zone construction protocol design
1186 concept, which aims to minimise the number of ZLs in
1187 the network and results in frequent and large multicast
1188 updates between ZLs since the network backbone consists
1189 of large numbers of them. These results show clearly that
1190 even though ZLs help to reduce the network overheads
1191 through the ZTL mechanism of the ZCG protocol, they
1192 should be kept to a minimum. Otherwise, they would be
1193 likely to undermine the system and exhibit the reverse
1194 effect. Note that the DSR starts with the lowest overheads
1195 and they continue to slightly decrease, the more reliable
1196 nodes there are in the network.
1197 6.2.2. Reachability ratio (Fig. 11)
1198 Fig. 11 presents the results for the reachability ratio,
1199 which is the ratio of successful route discovery attempts
1200 to the total number of route discovery attempts to nd
1201 and set a path to a particular destination node/s in the net-
1202 work. First of all, it is observed that this ratio for all three
1203 protocols is quite low in comparison to the values obtained
1204 from the other experiments and shown in Fig. 6. From
1205 Fig. 11 it can also be seen that the ZCG has the highest
1206 reachability ratio with all proportions of ZLs. Notably, all
1207 the protocols start with a low reachability ratio at 20%,
1208 then have a high level at 35%, especially the ZCG. However,
1209 all their reachability ratios degraded again at 50% to a
1210 slightly lower score than that shown with 35% ZLs. There
1211 are two explanations for this result. First, because the
1212 nodes were placed uniformly at random positions inside
1213 the domain, some of these (including the source and desti-
1214 nation) were likely to be positioned at disconnected/iso-
1215 lated locations and this situation was exacerbated by
1216 these nodes lack of mobility, which means their isolation
1217 persisted throughout the simulation and hence the low
1218 reachability score. The rest of the networks mobile nodes
1219 provided temporary wireless coverage, depending on their
1220 mobility pattern and speed, by linking those nodes with
1221 the network temporarily, which is why the experiment
1222 produced this result. The second explanation is that the
1223 random positioning of the static nodes created continuous
1224 dense regions, i.e. during the entire simulation run, which
1225 provided high levels of interference and high packet colli-
1226 sions as a result of the competition between the nodes
1227 for transmissions over a shared channel. Fig. 10. Total routing trafc received (bits/s).
Fig. 11. Reachability ratio.
8 October 2014
dx.doi.org/10.1016/j.adhoc.2014.09.010
1228 6.2.3. Route discovery delay (s) (Fig. 12)
1229 Fig. 12 shows the time latency of the route discovery
1230 process, while increasing the number of ZLs in the net-
1231 work. In Fig. 12 it is seen that the ZCG is doing quite well
1232 with larger number of ZLs in the network. In most cases
1233 the DSR takes 813 s to nd routes to a destination, while
1234 this time decreases with a higher ratio of reliable nodes.
1235 This is because this protocol was designed to work well
1236 with networks with a large proportion of static nodes. By
1237 contrast, the AODV takes a range of 45.5 s to nd a route
1238 to the destinations, and its route discovery latency
1239 decreases with a higher ratio of reliable nodes. Notably,
1240 some correlation between these Results 12 and those of
1241 Fig. 13 that present the protocols average broadcast
1242 retransmissions is observed. For example, the ZCGs route
1243 discovery latency is quite high with fewer ZLs, which could
1244 be the result of a large volume of blind broadcasting
1245 performed by the member nodes. This is corroborated by
1246 looking at the route discovery time reduction of the ZCG
1247 with 50% ZLs. Moreover, from Figs. 12 and 13 it emerges
1248 that both broadcasting overheads and route discovery time
1249 latency decrease with large numbers of ZLs, which is due to
1250 the large size of the ZL backbone covering large parts of the
1251 network. This increases the probability of having large
1252 chunks of the routes between nodes going over the back-
1253 bone. This leads to the routing entries being maintained
1254 for longer owing to the ZLs frequent multicast updates
1255 and their reliability Q5 characteristics (see Fig. 14).
1256 6.2.4. Routing broadcast retransmission (Fig. 13)
1257 Fig. 13 indicates the average number of forwarded route
1258 rebroadcasts during the path discovery process. The gure
1259 also indicates the average number of packets each node in
1260 the network has rebroadcast during the simulation, which
1261 can be seen in the top label of each bar in the gure. From
1262 the results in Fig. 13 it can also be seen that the number of
1263 broadcast retransmissions in the ZCG and DSR is quite
1264 high. In fact, these two protocols exhibit broadly similar
1265 results when the presence of ZLs in the network is around
1266 20%. Referring back to the results regarding the total rout-
1267 ing trafc received (Fig. 10) and those shown here (Fig. 13),
1268 it is observed that the parallel and distributed broadcast in
1269 the ZCG is not the main cause of route overheads, for large
1270 chunks of its routing trafc come from: the multicast
1271 between ZLs, Hello packets and route maintenance.
1272 It can also be seen that the rebroadcasting in the ZCG
1273 decreases, the more ZLs there are in the network. This
1274 could be due to the ZTL technique that stops redundant
1275 messages from being ooded to unnecessary network
1276 branches. In addition, the existence of a backbone that con-
1277 sists of a large number of ZLs, makes it more likely to have
1278 large chunks of the routes between the nodes over this
1279 backbone, which means fresh entries for these routes will
1280 be kept for longer by getting their timers frequently reset
1281 by the multicast between the ZLs as well as there being
1282 fewer route failures due to the ZLs reliability features.
Fig. 12. Route discovery delay (s).
Fig. 13. Number of broadcast retransmissions.
Fig. 14. MANET power consumption varying zones stacked.
8 October 2014
dx.doi.org/10.1016/j.adhoc.2014.09.010
1283 Notably, the AODV has the fewest rebroadcast over-
1284 heads, which can be attributed to the cached replies. For
1285 example, when a node receives a route request and is not
1286 its target, it looks up its routing table to decide whether
1287 it has any route to the target of the request. If so, the node
1288 sends back a cached route reply and does not
1289 rebroadcast the request packet. This is conrmed by the
1290 AODV reachability ratio shown in Fig. 11.
1291 6.2.5. Energy consumption
1292 Here, the effects of varying the number of zone leaders
1293 ZL/stationary nodes are explored over various random
1294 scenarios.
1295 Looking at Fig. 6.2.5 Q6 , the stacked bars illustrate the
1296 power consumption associated with the various types of
1297 messages. For example, the AODV has the highest power
1298 consumption for receiving broadcast messages, although
1299 its consumption for sending these broadcasts is not very
1300 large. The ZCG on the other hand, uses the least energy
1301 for receiving and sending broadcast messages, but uses a
1302 lot of that nodes energy for receiving unicast messages. It
1303 also has the highest energy consumption for dropping data,
1304 which can be as result of packet collisions, long in/out
1305 stream queues or redundant packets. However, although
1306 these are negative attributes they all contribute to the over-
1307 all overhead efciency of the ZCG when there is an ade-
1308 quate number of ZLs in the network, as demonstrated
1309 earlier in 9. In addition, the energy used to transmit and
1310 receive broadcast packets decreases the more ZLs are added
1311 to the network, because the ZTL technique also becomes
1312 more efcient as the number of ZLs increases, and also
1313 because of the positive RREQ-collision of the parallel
1314 guided broadcasting techniques. On the other hand under
1315 these circumstances, the energy used in the ZCG to send
1316 and receive unicast routing packets increases steadily,
1317 due to the proactive edge node related updates being for-
1318 warded between more ZLs. In this case the protocol perfor-
1319 mances come second best to the DSR. It is noteworthy that
1320 the DSR and AODVs power consumption falls the greater
1321 the number of ZLs/static nodes in the network. Overall,
1322 the ZCG performance in terms of energy consumption is
1323 shown to be reasonably good when a moderate number
1324 of ZLs are allowed to function in a MANET network.
1325 7. Conclusion
1326 It is concluded from the above results that the ZCG gen-
1327 erally performs well in terms of reachability and time dis-
1328 covery delay, in most cases, in comparison to the AODV
1329 and DSR. However, it has also emerged that the ZCG pro-
1330 duces noticeably higher routing overheads than the rest
1331 of the protocols, which is contradictory to one of the ZCGs
1332 design objectives. However, the trafc size, load and fre-
1333 quency of the ZCG overheads are produced in a distributed
1334 fashion, which causes less impact on the protocol perfor-
1335 mance than if the same trafc is generated from typical
1336 one-sided broadcasting, which often leads to broadcasting
1337 storms.
1338 The results indicate that the DSR has the least over-
1339 heads during the path set up phase. However, because of
1340 its purely reactive behaviour, its path set up phase is the
1341 longest and its routing cache at intermediate nodes is
1342 highly likely to be inconsistent, due to link failures in
1343 highly dynamic networks. On the other hand, it has out-
1344 standing performance in comparison to the AODV and
1345 ZCG in terms of overheads and reachability in static
1346 networks.
1347 One of the drawbacks of the ZCG that was not consid-
1348 ered during the protocol design phase, is that although
1349 endeavour was made to ensure the establishment of the
1350 network backbone using slow moving nodes and reliable
1351 links, all the nodes at each zone compete to use the
1352 physical medium for sending all their messages regardless
1353 of whether these are sent over the backbone links or not.
1354 This can cause delay which impacts on the parallelism of
1355 the collision guided broadcasting technique.
1356 A signicant problem with the ZCG is the number of
1357 multicast updates required between ZLs as a result of mem-
1358 ber nodes change of location/status. That is, there are
1359 repeated cases of unnecessary trafc volume exchanged
1360 between the Zls that contain no member nodes, or inactive
1361 member nodes (i.e. member nodes that show minimal
1362 communicative demands). In the rst case, most of the ZL
1363 multicast trafc received by isolated ZLs is likely to be
1364 unnecessary and a waste of bandwidth, although ZLs are
1365 assumed to act like normal nodes, i.e. are not conned to
1366 relay data and initiating the ZCG parallel collision guided
1367 process.
1368 The ZCGs logical clustering procedure and zone
1369 selection mechanism may constrain its scalability in highly
1370 dynamic ad hoc networks. Although it piggybacks the clus-
1371 tering information and necessary data for the ZL selection
1372 mechanism in periodic Hello messages, dynamic networks
1373 cause the selection mechanism to be frequently triggered,
1374 because of the change of the nodes geographical locations
1375 due to their highly dynamic mobility nature. This will
1376 cause large and frequent updates to be multicast to the
1377 network for the purpose of notifying the ZLs about the
1378 newly selected ones and their members, which form the
1379 new zones.
1380 8. Evaluation
1381 Reducing the time required for routing is an obvious
1382 benet of the ZCG protocol for two reasons: (i) the parallel
1383 broadcasting from source and destination nodes and (ii)
1384 searching routing tables for requested destinations at
1385 intermediate nodes is fast, as the table entries are indexed
1386 by creation time and the ZCG searching algorithm only
1387 checks recently created entries.
1388 The parallel broadcasting from the source and destina-
1389 tion nodes utilises the fact that jitter delay is higher in
1390 broadcast than it is in unicast packets. Jitter
3
(standardised
1391 by the Internet Engineering Task Force (IETF) in RFC 5148
1392 [16].) at the network layer was designed to work alongside
1393 the Multiple Access with Collision Avoidance for Wireless
1394 (MACAW) [9] or the IEEE 802.11 RTS/CTS [43] at the lower
3
The term Jitter/jittering in this context means positive random delay
added to the packet transmission time by the wireless nodes.
8 October 2014
dx.doi.org/10.1016/j.adhoc.2014.09.010
1395 MAC layer to avoid the packet collision problem and its
1396 related issues caused by simultaneous packet transmission
1397 of neighbouring nodes in wireless mobile ad hoc networks.
1398 Using the parallel collision guided broadcasting allows the
1399 ZCG to reduce the number of slow broadcasts by increasing
1400 the unicasts that in general are faster and hence use less
1401 energy, i.e. trade-off the number of unicasts against the
1402 number broadcast during a single path discovery session.
1403 Hence, reducing total broadcast jitter, which is the main
1404 factor that inuences the total average route discovery and
1405 network delays. Additionally, the distribution of broadcasts,
1406 i.e. the simultaneous broadcast initiations from the two ends
1407 of a route, leads to their fast spreading to cover the whole
1408 network.
1409 In the ZCG, a positive RREQ-collision, which indicates a
1410 path discovery, only occurs based on up to date informa-
1411 tion. A similar approach is used in the AODV, through the
1412 route request sequence number. For example, when a
1413 route to a new destination is required, the node broadcasts
1414 a RREQ to discover a route to the desired destination. A
1415 route can be found if the RREQ arrives at either the desti-
1416 nation itself, or an intermediate node with knowledge of
1417 a fresh route to the destination. A fresh route is a valid
1418 route entry for the destination whose associated sequence
1419 number value is equal or higher that contained in the
1420 RREQ.
1421 However, such knowledge can be inconsistent/outdated
1422 in a highly dynamic network and one solution to this
1423 problem was discussed is dynamic nix-vector routing
1424 [32]. Under this approach, for example, while searching
1425 for a destination node by ooding the network with path
1426 discovery packets (RREQ), when already stored routing
1427 information that leads to the required destination node D
1428 is found in intermediate node X, information will not be
1429 used immediately. Instead, node X needs to evaluate the
1430 freshness of the information by unicasting a discovery
1431 packet from the current node to destination node D. If node
1432 D receives the packet, which establishes the consistency of
1433 the data found, the destination node will unicast an
1434 acknowledgement back to the search generator through
1435 X, otherwise no acknowledgement is received within a
1436 predetermined time and broadcasting path discovery
1437 packets will continue from that point (i.e. from node X)
1438 onwards. Perhaps the most serious disadvantage of this
1439 method is the waiting time required to verify the freshness
1440 and the consistency of the cached routes at the intermedi-
1441 ate nodes.
1442 Many routing protocols try to reduce the number of
1443 broadcast messages using time to live value (TTL) inserted
1444 in the header of the packet, which gets decremented by 1
1445 at each hop on the route to destination. When the TTL
1446 value reaches zero, the packet will be discarded. However,
1447 this technique is efcient only if the TTL value to reach the
1448 destination is known already (possibly in static networks)
1449 or can be estimated from the nodes message exchange or
1450 signal strength. That is, if the TTL value is slightly shorter
1451 than that required, rebroadcasting will be performed again
1452 with a higher TTL value in order to reach the destination,
1453 which can be more expensive than ooding route discov-
1454 ery packets to the whole network in the rst place. The
1455 ZCG is very efcient, in the sense that if both ends succeed
1456 in initiating the broadcast of RREQs simultaneously, RREQ-
1457 collision between the two is very likely to occur at the rst
1458 attempt. In addition to this, there is some probability that
1459 RREQ-collision can stop further redundant ooding of
1460 RREQs in parts of network branches, i.e. regions. The ZCG
1461 collision guided technique can be viewed as a new
1462 stochastic approach to control broadcasting. In Fig. 1 the
1463 RREQ-collision stops redundant rebroadcasts from
1464 reaching the network branches A, B, G, H, K and part of
1465 zone D.
1466 In most zone routing protocols [6,44], all nodes belong-
1467 ing to a zone need proactively to maintain partial network
1468 topology data. However, in the ZCG only lists of ID
1469 addresses plus other small amounts of data are (infre-
1470 quently) exchanged between ZLs as compared with topo-
1471 logical data that are large and need frequent updating.
1472 In the ZCG, the zones are formed by one ZL with links to
1473 nodes of one hop diameter from the ZL radio range and if
1474 the zones ZL disappears owing to movement or interfer-
1475 ence, reconstructing a new zone, if necessary, can be done
1476 quickly with insignicant control overheads.
1477 Moreover, a single path discovery search operation in
1478 the ZCG is likely to cause multiple RREQ-collisions and
1479 extra routes to a single destination can always be used as
1480 a backup in cases of link failure. It is important to clarify
1481 that the ZCG is not only a routing protocol, but also a rout-
1482 ing technique that might be used with other existing rout-
1483 ing protocols. For example, when a route discovery packet
1484 needs to create and carry a list of all previously visited
1485 nodes, which can subsequently be used for route forma-
1486 tion, such as in swarm intelligent routing [10,17] and the
1487 DSR [27]. The ZCGs parallel collision guided technique
1488 can be used in the DSR to le multiple route requests from
1489 both ends S and D to carry less than the entire list size,
1490 while traversing different regions of the network simulta-
1491 neously and therefore, exploiting different parts of the net-
1492 work and balancing the load.
1493 As in many protocols which try to establish underlying
1494 infrastructure, such as zones and clusters, the time needed
1495 for the nodes implementing the ZCG to converge at the
1496 network initial phase is long. Another downside of this
1497 protocol is the waiting time needed for synchronising
1498 broadcasting of RREQs at both ends. In the worst case
1499 scenario, when a Path Discovery Commands(PDC) packet
1500 traversing to one end gets lost, the other end still performs
1501 a broadcast and hence the waiting time for parallel broad-
1502 casting will increase the broadcast time latency. Neverthe-
1503 less, the benet from using the ZTL remains.
1504 As withthe TTL, the ZTL technique is more efcient when
1505 used with moderate values, i.e. when ZTL 6
1
2
network
1506 diameter or even smaller. That is, a large ZTL value can make
1507 this useless since the packets will propagate the entire net-
1508 work before it reaches zero. However, large ZTL values can
1509 still benet the system by breaking innite routing loops
1510 if they occur during broadcasting control messages.
1511 ZCG synchronisation cannot be constantly precise
1512 because: (i) local clocks of mobile nodes drift at different
1513 rates and (ii) delay is introduced by congestion in interme-
1514 diate nodes queues.
8 October 2014
dx.doi.org/10.1016/j.adhoc.2014.09.010
1515 Finally the protocol performance degradation, due to
1516 control overheads exchanged between ZLs through the
1517 backbone to maintain the zone infrastructure, is relatively
1518 minor. Although such overheads are small when compared
1519 to the topological information exchanged in purely
1520 proactive routing protocols, it still burdens the ZCGs per-
1521 formance, especially in highly dynamic mobile networks.
1522 9. Discussion
1523 A similar technique to parallel collision guided (ZCG)
1524 has been published, namely, the Destination-assisted
1525 Routing Enhancement Protocol (DARE) [1], which is
1526 conceptually similar, but differs in implementation and
1527 execution. In DARE, the destination node participates in
1528 routing by assisting the source node in nding itself. This
1529 is accomplished by the destination generating beacon
1530 packets independently and randomly at a low rate and
1531 with a low TTL value, for low overheads. The beacon ran-
1532 domly traverses via intermediate nodes to refresh their
1533 cache entries, which route to the destination and a beacon
1534 packet gets discarded at intermediate nodes when it
1535 exceeds its associated TTL value. The objective of these
1536 beacons is not to discover the source node, but to
1537 announce the existence of a destination node to other close
1538 by nodes. Conversely, the ZCG technique is performed on-
1539 demand and both the destination and the source, equally
1540 and concurrently, participate in routing.
1541 By allowing the destination to send random beacons,
1542 DARE may seem to outperform ZCGs overheads from the
1543 ZLs proactive connectivity used for the backbone channel
1544 maintenance. However, the former assumes that there is
1545 a single destination in the network, which is not realistic
1546 in a MANET, where all nodes are potential destinations.
1547 Therefore, this concludes that DARE has high overheads
1548 and will behave like other zone and cluster-based proto-
1549 cols [2], where nodes proactively keep routing data about
1550 neighbours with a dened hop count.
1551 Some may argue that instead of initiating a new route
1552 discovery process to nd/establish a route to a destination
1553 node, the underlying ZLs backbone channel should be
1554 used. This is because this connects all ZLs, and they have
1555 links to most member nodes in the network. Moreover,
1556 because of the ZLs reliability features and the proactive
1557 multicast between them over the backbone for synchroni-
1558 sation and selective routing purposes, the backbone
1559 channel will always exist. This stance is addressed briey
1560 as follows:
1561 1. The infrastructure link may not be the shortest
1562 between the nodes, since ZL zones establish connec-
1563 tivity among themselves based on reliability criteria.
1564 2. It would not be wise to use those links repetitively
1565 to accommodate all connectivity sessions amongst
1566 all nodes in the network, since these links will
1567 quickly be overloaded. The original purpose of the
1568 backbone is to establish a reliable, long-lasting link
1569 between ZLs to exchange lists of lightweight ID
1570 addresses and some information for synchronisa-
1571 tion purposes.
1572 3. The ZCG uses ZLs only during the route establish-
1573 ment phase, but they are not used as gateways to
1574 forward the nodes data that can cause unbalanced
1575 node trafc as well as making routing sensitive to
1576 gateway node failures [21]. The ZLs in this protocol
1577 are also considered normal nodes, i.e. self-interested
1578 nodes that can initiate private communication
1579 sessions with any other node in the network.
1580
1581 10. Summary and future work
1582 A zone-based routing protocol with parallel collision
1583 guided broadcasting (ZCG) has been put forward in this
1584 paper and tested along with two other protocols, the DSR
1585 and the AODV, in order to assess the foremosts effective-
1586 ness. It was found that the ZCG can speed up the routing
1587 process in a MANET through its on-demand parallel colli-
1588 sion guided broadcasting, which is because it reduces
1589 redundant rebroadcasts via: (i) RREQ-collisions occurring
1590 through the parallel broadcast from the source and desti-
1591 nation nodes; (ii) the zone to live (ZTL) technique, which
1592 is the number of zones a broadcast needs to propagate
1593 through before it gets discarded by member nodes. Under
1594 this procedure, member nodes act as a defence wall to pro-
1595 tect their zones from receiving needless broadcasts. In
1596 sum, the simulation results indicate that the ZCG meets
1597 its design objectives and in fact is better than the AODV
1598 protocol.
1599 One future aim is to increase fairness among nodes by,
1600 for example, protecting zone members from possible self-
1601 ish behaviours
4
associated with the ZLs dominant role in
1602 the ZCG, respectively, as they are responsible for initiating
1603 the fast and efcient parallel collision guided broadcasting.
1604 In the protocols developed for this research, this issue was
1605 resolved by allowing the zone members to continue their
1606 route discovery process as a pure broadcast without the des-
1607 tination assistant (i.e. sending the simultaneous collision
1608 guided broadcasting), which can lead to a broadcast storm
1609 problem that wastes large network bandwidth and causes
1610 high power consumption as well as network latency.
1611 One possible extension to the issue of fairness would be
1612 to adopt a similar approach to that found in [41], which
1613 involved using collaborative and energy efcient routing
1614 for a WSN through the use of game theory. This approach
1615 allows for the network nodes in such a network to act as
1616 players competing over the resources comprising the
1617 nodes energy and data. Given the nature of a WSN, the
1618 nodes understand that their actions and choices have a
1619 great impact on those located upstream, however, they
1620 are also conscious of the fact that they have no choice
1621 but to use these nodes to relay their data along the
1622 multi-hop path to the sink. Similar circumstances exist in
1623 the nodes implementing the ZCG protocols, in that zone
4
Non-cooperative actions of misbehaviour are usually termed as
selshness, which is notably different from malicious behaviour. Selsh
nodes use the network for their own communication, but simply refuse to
cooperate in forwarding packets for other nodes in order to save battery
power. A selsh node would thus utilize the benets provided by the
resources of other nodes, but will not make available its own resources to
help others. They have no intention of damaging the network.[5].
8 October 2014
dx.doi.org/10.1016/j.adhoc.2014.09.010
1624 members know that in order to initiate faster, with high
1625 reachability and to have an efcient route discovery
1626 mechanism, their route requests have to be processed
1627 and handled by their zone leaders. However, they also
1628 understand that they are responsible for operating the
1629 ZTL in MANET, which pertain to the number of zones a
1630 broadcast needs to cross through before it gets discarded
1631 by zone members. Hence, these nodes act as defence walls
1632 to protect the zones and their leaders from receiving and
1633 reforwarding unwanted broadcasts from outside, thereby
1634 saving their: power resources, channel capacity and pre-
1635 venting contention.
1636 Another game theory based approach can be used to
1637 solve issues such as selecting the most reliable nodes in
1638 the zones and to limit the chances that dishonest nodes
1639 deceive others about their actual capabilities. Such an
1640 approach can force the ZL role to be assigned to the node
1641 with the most resources, and prevent unreliable nodes
1642 owing to their mobility, poor security and/or weak battery
1643 resources, from taking such role. For example, the current
1644 implementation of the ZCG protocol assumes all the net-
1645 work nodes as honest and cooperative. Therefore, addi-
1646 tional rules would need to be introduced in the system
1647 so that violators receive just punishment, and those who
1648 comply and cooperate sincerely are rewarded. Such an
1649 extension could be adopted with the current design of
1650 the ZCG for a MANET, because it already uses SORRY mes-
1651 sages to exclude nodes that are already part of other zones
1652 from participating in a new zone construction protocol, as
1653 well as using them to verify whether or not such a decision
1654 is accurate, by calculating the propagation time and cur-
1655 rent role of the node.
1656 It is put forward that WMNs [18] and VANETs [33] are
1657 an ideal setting for the ZCG protocol and closely related
1658 alternatives, as ZLs are special nodes that can maintain
1659 remote-to-remote trafc via one or more hops, while pre-
1660 serving the wireless connectivity via mobility constraints.
1661 Further, these networks have more planned conguration,
1662 and can be deployed to provide dynamic and cost effective
1663 connectivity over a specied geographic area. Moreover, in
1664 such networks the ZL nodes can become special nodes with
1665 no mobility and may only move according to network
1666 demands to provide wireless coverage to an unconnected
1667 group of nodes in case of network split. In addition, ZLs
1668 would become unlimited in terms of resources compared
1669 to other nodes, thus they can be highly utilised to perform
1670 functions that demand high network resources. The back-
1671 bone channel that interconnects ZLs could be maintained
1672 via a second radio channel, e.g. using WLAN IEEE 802.11
1673 3-channel system. Consequently, the ZCG would require
1674 fewer multicasts since the ZL selection mechanism would
1675 be performed infrequently or even eliminated due to the
1676 hardware features of the ZLs, such as: unlimited power
1677 resources, static motion and multi-radio access technolo-
1678 gies for high network capacity. Moreover, the ZCGs syn-
1679 chronised arrangement for initiating parallel CG
1680 broadcasting would become more accurate and faster,
1681 resulting in greater efciency.
1682 Acknowledgements
1683 This work is partially supported by Toshiba Research
1684 Europe Ltd, the Yemen Ministry of Higher Education and
1685 Scientic Research (MoHESR), Great Western Research
1686 (UK) and the National Institute of Informatics (NII) Japan.
1687 References
1688
[1] Yousef M. Abdelmalek, Tarek N. Saadawi, Destination-assisted
1689
routing enhancement (DARE) protocol for ad-hoc mobile networks,
1690
in: SARNOFF: Proceedings of the 32nd International Conference on
1691
Sarnoff Symposium, IEEE Press, USA, 2009, pp. 386391.
1692
[2] Mehran Abolhasan, Tadeusz Wysocki, Eryk Dutkiewicz, A review of
1693
routing protocols for mobile ad hoc networks, Ad Hoc Netw. 2 (1)
1694
(2004) 122.
1695
[3] Graud Allard, Pascale Minet, Dang-Quan Nguyen, Nirisha Shrestha,
1696
Evaluation of the energy consumption in MANET, in: Proceedings of
1697
the 5th International Conference on Ad-Hoc, Mobile, and Wireless
1698
Networks, ADHOC-NOW, Springer-Verlag, Berlin, Heidelberg, 2006,
1699
pp. 170183.
1700
[4] D. Arora, E. Millman, S.W. Neville, On the statistical behaviors of
1701
network-level features within MANETs, in: 2011 IEEE 22nd
1702
International Symposium on Personal Indoor and Mobile Radio
1703
Communications (PIMRC), September 2011, pp. 11451150.
1704
[5] K. Balakrishnan, Jing Deng, V.K. Varshney, TWOACK: preventing
1705
selshness in mobile ad hoc networks, Wireless Communications
1706
and Networking Conference, 2005, vol. 4, IEEE, 2005, pp. 21372142.
1707
[6] Leonard Barolli, Yoshitaka Honma, Akio Koyama, Arjan Durresi,
1708
Junpei Arai, A selective border-casting zone routing protocol for ad-
1709
hoc networks, in: DEXA: 15th International Workshop Proceedings
1710
of the Database and Expert Systems Applications, IEEE Computer
1711
Society, Washington, DC, USA, 2004, pp. 326330.
1712
[7] P. Basu, N. Khan, T.D.C. Little, A mobility based metric for clustering
1713
in mobile ad hoc networks, in: 2001 International Conference on
1714
Distributed Computing Systems Workshop, April 2001, pp. 413418.
1715
[8] S.S. Basurra, M. De Vos, J. Padget, T. Lewis, S. Armour, ZCG: a zone-
1716
based routing protocol with parallel collision guidance broadcasting
1717
for MANET, in: 2010 12th IEEE International Conference on
1718
Communication Technology (ICCT), November 2010, pp. 11881191.
1719
[9] Vaduvur Bharghavan, Alan Demers, Scott Shenker, Lixia Zhang,
1720
MACAW: a media access protocol for wireless LANs, SIGCOMM
1721
Comput. Commun. Rev. 24 (4) (1994) 212225.
1722
[10] Gianni Di Caro, Frederick Ducatelle, Luca Maria Gambardella,
1723
AntHocNet: an adaptive nature-inspired algorithm for routing in
1724
mobileadhoc networks, Eur. Trans. Telecommun. 16(2005) 443455.
1725
[11] I.D. Chakeres, E.M. Belding-Royer, The utility of hello messages for
1726
determining link connectivity, in: The 5th International Symposium
1727
on Wireless Personal Multimedia Communications, 2002, vol. 2,
1728
October 2002, pp. 504508.
1729
[12] Perkins annd Elizabeth Belding-Royer Charles, Samir Das, Ian
1730
Chakeres, Aodv@ietf Project @ONLINE, 2012.
1731
[13] Mainak Chatterjee, Sajal K. Das, Damla Turgut, A weight based
1732
distributed clustering algorithm for mobile ad hoc networks, in:
1733
Proceedings of the 7th International Conference on High
1734
Performance Computing, HiPC, Springer-Verlag, London, UK, UK,
1735
2000, pp. 511521.
1736
[14] Mainak Chatterjee, Sajal K. Das, Damla Turgut, WCA a weighted
1737
clustering algorithm for mobile ad hoc networks, J. Cluster Comput.
1738
(Spec. Issue Mobile Ad hoc Netw. 5 (2001) 193204.
1739
[15] Ching chuan Chiang, Hsiao-Kuang Wu, Winston Liu, Mario Gerla,
1740
Routing in clustered multihop mobile wireless networks with fading
1741
channel, in: Proc. IEEE SICON, April 1997, pp. 197211.
1742
[16] T. Clausen, C. Dearlove, B. Adamson, Jitter Considerations in Mobile
1743
Ad Hoc Networks (MANETs, RFC 5148 (Informational), February
1744
2008.
1745
[17] G. Di Caro, F. Ducatelle, L.M. Gambardella, Swarm intelligence for
1746
routing in mobile ad hoc networks, in: Swarm Intelligence
1747
Symposium, 2005, SIS 2005, Proceedings 2005, IEEE, June 2005, pp.
1748
7683.
1749
[18] Richard Draves, Jitendra Padhye, Brian Zill, Routing in multi-radio,
1750
multi-hop wireless mesh networks, in: ACM MobiCom, ACM Press,
1751
2004, pp. 114128.
8 October 2014
dx.doi.org/10.1016/j.adhoc.2014.09.010
1752
[19] SparkNotes Editors, Hash Tables in C language, SparkNotes LLC,
1753
SparkNotes.com, July 2012.
1754
[20] L.M. Feeney, M. Nilsson, Investigating the energy consumption of a
1755
wireless network interface in an ad hoc networking environment,
1756
INFOCOM 2001, Twentieth Annual Joint Conference of the IEEE
1757
Computer and Communications Societies, Proceedings, vol. 3, IEEE,
1758
2001, pp. 15481557.
1759
[21] Stefan Funke, Leonidas Guibas, An Nguyen, Yusu Wang, Distance-
1760
sensitive information brokerage in sensor networks, in: Phillip B.
1761
Gibbons, Tarek F. Abdelzaher, James Aspnes, Ramesh Rao (Eds.),
1762
Distributed Computing in Sensor Systems, Second IEEE International
1763
Conference, DCOSS 2006, Lecture Notes in Computer Science, vol.
1764
4026, Springer, IEEE, San Francisco, USA, 2006, pp. 234251.
1765
[22] Andr Gnther, Christian Hoene, Measuring round trip times to
1766
determine the distance between WLAN nodes, in: Proceedings of the
1767
4th IFIP-TC6 International Conference on Networking Technologies,
1768
Services, and Protocols; Performance of Computer and
1769
Communication Networks; Mobile and Wireless Communication
1770
Systems, NETWORKING, Springer-Verlag, Berlin, Heidelberg, 2005,
1771
pp. 768779.
1772
[23] Z.J. Haas, A new routing protocol for the recongurable wireless
1773
networks, in: 1997 IEEE 6th International Conference on Universal
1774
Personal Communications Record, 1997, Conference Record, vol. 2,
1775
October 1997, pp. 562566.
1776
[24] Zygmunt J. Haas, Marc R. Pearlman, The performance of query
1777
control schemes for the zone routing protocol, IEEE/ACM Trans.
1778
Netw. 9 (4) (2001) 427438.
1779
[25] Zygmunt J. Haas, Marc R. Pearlman, Prince Samar, Intrazone Routing
1780
Protocol (IARP), Internet Draft draft-ietf-manet-iarp-02.txt, IETF, July
1781
2002.
1782
[26] Zygmunt J. Haas, Marc R. Pearlman, Prince Samar, The Zone Routing
1783
Protocol (ZRP) for Ad Hoc Networks, Internet Draft draft-ietf-manet-
1784
zone-zrp-04.txt, IETF, July 2002.
1785
[27] David B. Johnson, David A. Maltz, Dynamic source routing in ad hoc
1786
wireless networks, IEEE Trans. Mobile Comput. (1996).
1787
[28] David B. Johnson, David A. Maltz, Josh Broch, DSR: the dynamic
1788
source routing protocol for multi-hop wireless ad hoc networks, in:
1789
Charles E. Perkins (Ed.), In Ad Hoc Networking, Addison-Wesley,
1790
2001, pp. 139172 (Chapter 5).
1791
[29] Young-Bae Ko, Nitin H. Vaidya, Location-aided routing (LAR) in
1792
mobile ad hoc networks, Wirel. Netw. 6 (2000) 307321.
1793
[30] Chander Kumar, Shailender Gupta, Bharat Bhushan, Impact of
1794
various factors on probability of reachability in MANET: a survey,
1795
Int. J. Appl. Graph Theory Wirel. Ad Hoc Netw. Sens. Netw. 3 (3)
1796
(2011) 1324. ISSN: 0975 - 7023[Online]..
1797
[31] Seungjoon Lee, Bobby Bhattacharjee, Suman Banerjee, Efcient
1798
geographic routing in multihop wireless networks, in: MobiHoc:
1799
Proceedings of the 6th ACM International Symposium on Mobile Ad
1800
Hoc Networking and Computing, ACM, USA, 2005, pp. 230241.
1801
[32] Y.J. Lee, G.F. Riley, Dynamic nix-vector routing for mobile ad hoc
1802
networks, Wireless Communications and Networking Conference,
1803
2005, vol. 4, IEEE, 2005, pp. 19952001.
1804
[33] Fan Li, Yu Wang, Routing in vehicular ad hoc networks: a survey,
1805
Veh. Technol. Mag., IEEE 2 (2) (2007) 1222.
1806
[34] Md. Mamun-Or-Rashid, Choong Seon Hong, LSLP: link stability and
1807
lifetime prediction based QoS aware routing for MANET, in: Proc.
1808
Joint Conference on Communications and Information (JCCI),
1809
Phoenix Park, Korea, May 2007.
1810
[35] S.S. Manvi, M.S. Kakkasageri, Multicast routing in mobile ad hoc
1811
networks by using a multiagent system, Inform. Sci. 178 (6) (2008)
1812
16111628.
1813
[36] OPNET Modeler Documentation, 2011. <www.opnet.com>.
1814
[37] Abhay K. Parekh, Selecting routers in ad hoc wireless network, in:
1815
Proceedings of the SBT/IEEE International Telecommunication
1816
Symposium, ITS, August 1994.
1817
[38] C.E. Perkins, E.M. Royer, Ad-hoc on-demand distance vector routing,
1818
in: Second IEEE Workshop on Mobile Computing Systems and
1819
Applications, 1999, Proceedings, WMCSA, 1999.
1820
[39] Charles E. Perkins, Highly dynamic destination-sequenced distance-
1821
vector routing (DSDV) for mobile computers, in: In Proceedings of
1822
ACM SIGCOMM Conference, 1994, pp. 234244.
1823
[40] E. Royer, Chai-Keong Toh, A review of current routing protocols for
1824
ad hoc mobile wireless networks, Person. Commun., IEEE 6 (2)
1825
(1999) 4655 (see also IEEE Wireless Communications).
1826
[41] Alexandros Schillings, Kun Yang, VGTR: a collaborative, energy and
1827
information aware routing algorithm for wireless sensor networks
1828
through the use of game theory, in: Niki Trigoni, Andrew Markham,
1829
Sarfraz Nawaz (Eds.), GeoSensor Networks, Lecture Notes in
1830
Computer Science, vol. 5659, Springer, Berlin/Heidelberg, 2009, pp.
1831
5162.
1832
[42] Brad Williams, Tracy Camp, Comparison of broadcasting techniques
1833
for mobile ad hoc networks, in: MobiHoc, ACM, New York, NY, USA,
1834
2002, pp. 194205.
1835
[43] KaixinXu, M. Gerla, SangBae, Howeffectiveis theIEEE802.11RTS/CTS
1836
handshake in ad hoc networks, in: Global Telecommunications
1837
Conference, 2002, GLOBECOM, vol. 1, IEEE, November 2002, pp. 7276.
1838
[44] Chun-Chuan Yang, Li-Pin Tseng, Fisheye zone routing protocol: a
1839
multi-level zone routing protocol for mobile ad hoc networks,
1840
Comput. Commun. 30 (2) (2007) 261268.
1841
1843 1843
1844 Shadi Saleh Basurra is a research fellow at
1845 Birmingham City University. He received his
1846 Bsc degree in Computer Science from Exeter
1847 University 2007 and MSc in Distributed Sys-
1848 tems and Networks from Kent University at
1849 Canterbury 2008. He obtained his Ph.D. in
1850 2013 from the University of Bath in collabo-
1851 ration with Bristol University. His research
1852 interests include simulation and emulation of
1853 networks (vehicular, mesh and sensor ad hoc
1854 network), game theory, multi-agent systems
1855 and dynamic simulation of zero carbon design
1856 and retrot of buildings.
1857
1858
1860 1860
1861 Marina de Vos is a senior lecturer in the
1862 Computer Science department at the Univer-
1863 sity of Bath. She completed her Doctor of
1864 Science degree in 2002 at the Vrije Universi-
1865 teit Brussel, Belgium. Marina research activi-
1866 ties involve knowledge representation,
1867 answer set programming and its applications,
1868 game theory and its applications, multi-agent
1869 systems, articial intelligence, theoretical
1870 computer science, the use of logic in computer
1871 science.
1872
1873
1875 1875
1876 Julian Padget is a senior lecturer in the
1877 Computer Science department at the Univer-
1878 sity of Bath. The central theme of his research
1879 is formal and computational models of nor-
1880 mative systems and their interaction with
1881 intelligent agents and mixed human-agent
1882 societies. Application domains include dis-
1883 tributed articial intelligence, sensors net-
1884 works, policy modelling, security, virtual
1885 environments, legal reasoning, energy and
1886 social simulation. He received his PhD from
1887 the University of Bath in 1984 and his BSc
1888 from the University of Leeds in 1981.
1889
1890
1892 1892
1893 Yusheng Ji is a professor of Information Sys-
1894 tems Architecture Research at the National
1895 Institute of Informatics (NII), Japan. She is also
1896 a visiting Professor at the University of Sci-
1897 ence and Technology of China. She received
1898 her Doctorate of Engineering from the Uni-
1899 versity of Tokyo in 1989. She is editor and a
1900 member of many prestigious academic jour-
1901 nals, and published over a hundred of publi-
1902 cations that focus on various aspects of
1903 networking including the future architecture
1904 of networks, resource management and
1905 scheduling schemes in wireless networks, Communication Protocols in
1906 Wireless Sensor and Ad Hoc Networks.
1907
8 October 2014
dx.doi.org/10.1016/j.adhoc.2014.09.010
1909 1909
1910 Tim Lewis is a research fellow at Toshiba
1911 Research Europe Ltd, UK. He received his
1912 Ph.D. in Computer Science from the Univer-
1913 sity of Edinburgh 2001, Msc in Computer
1914 Since from Edinburgh 2001, and MA Hons in
1915 Mathematics from the University of Cam-
1916 bridge in 1991. His research focus on various
1917 aspects of networking including the quality
1918 of services, resource allocations and man-
1919 agement and routing algorithms in Ad Hoc
1920 Networks.
1921
1923 1923
1924 SimonArmour has been an academic at Bristol
1925 since 2001 and has held the post of Senior
1926 Lecturer since 2007. He obtained his BEng
1927 degree from the University of Bath in 1996 and
1928 his PhD from the University of Bristol in 2001.
1929 His research interests cover a variety of wire-
1930 less communications techniques. Having orig-
1931 inally specialised in Physical Layer work and
1932 OFDM in particular, he has in recent years
1933 expanded his interest to cover more MAC and
1934 RRM aspects of wireless and has embraced a
1935 cross layer approach to wireless systemdesign.
1936
8 October 2014
dx.doi.org/10.1016/j.adhoc.2014.09.010

Zone Routing Protocol

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Zone Routing Protocol

Uploaded by

Copyright:

Available Formats

1

You might also like