formalisation, modelling, analysis...
TRANSCRIPT
FORMALISATION, MODELLING, ANALYSIS ANDVERIFICATION OF A NETWORK ROUTING
PROTOCOL:BETTER APPROACH TO MOBILE AD HOC
NETWORKING (B.A.T.M.A.N.)
by
Vinay Prakash Mehta
A thesis submitted in fulfillment of the requirements for the degree of
Master of Science
Copyright c©Vinay Prakash Mehta, 2019
School of Computing, Information & Mathematical Sciences
Faculty of Science, Technology & Environmental Science
The University of the South Pacific
September, 2019
AbstractThis thesis deals with routing protocols for wireless ad-hoc networks. In this thesis
model checking is used to verify and validate such protocols. Model checking is a
formal verification technique which is automated and checks for the existence of errors.
This allows assessing the functional properties as claimed of a system and for any
system a model is required. The model would represent the system and the properties
are verified. Similarly, a number of models are created during this research using a
tool, (Statistical Model Checking) SMC UPPAAL.
A major concern is the performance and reliability of wireless network protocols
that depend on the network and its environment. This issue was considered during the
initial stages of the thesis. In wireless networks, node mobility can affect the overall
performance up to a point where, for example, route discovery and route establishment
fail. As a consequence, any formal technique for performance analysis of wireless
network protocols should take node mobility into account. Therefore, a proposal is
made for a topology-based mobility model that abstracts from physical behaviour and
models mobility as probabilistic changes in the topology. It is demonstrated how this
model can be instantiated to cover the main aspects of the random walk and the ran-
dom waypoint mobility model. The model is not a stand-alone, but intended to be used
in combination with protocol models. This has been illustrated using two case stud-
ies: first a brief analysis of the Ad-hoc On demand Distance Vector (AODV) routing
protocol is shown, and second the mobility model is combined with the Lightweight
Medium Access Control (LMAC).
This thesis focusses on a number of protocols but the core work done is on a
network routing protocol known as Better Approach to Mobile Ad hoc Networks
(B.A.T.M.A.N.). The overall objective of B.A.T.M.A.N. protocol is to find the best
route for data packets to reach its destination based on routing tables present at each
node. This is achieved by a node sending a broadcast to the network to identify itself
by flooding it with originator messages. Each node updates its routing table by taking
note of the sender and originator ID with its relative sequence number. When a node
receives a new packet, it updates the routing information, and decides whether to dis-
card or forward the packet. Based on the stored routing information, B.A.T.M.A.N.
makes a decision on the best next hop towards the destination.
This thesis presents a normalization of the B.A.T.M.A.N. protocol using UPPAAL
SMC. The exercise revealed several ambiguities and inconsistencies in the internet
ii
draft. There were two models developed. The first one is implemented from a literal
reading of the internet draft, while the second tries to be closer to the underlying con-
cepts. The alternative model in some places is less restrictive, and rebroadcasts more
often to help route discovery, and will on the other hand drop more messages that might
interfere with the process.
A basic untimed model is verified for both interpretations to ensure loop-freedom,
bidirectional link discovery and route discovery. Simulation of a timed model is done
to compare the performance and it is found that both models are comparable when
it comes to time and the number of messages needed for discovering routes. How-
ever, the alternative model identifies significantly lower number suboptimal routes,
and thus improves on the literal interpretation of the internet draft and recovers better
from routing errors that are introduced by mobility. Overall, a contribution is made
in demonstrating the applicability of formal methods to verify and analyse network
routing protocols.
iii
AcknowledgementsI would like to take this opportunity to thank my principal supervisor, Professor Ans-
gar Fehnker from Programming Education at the Faculty of Electrical Engineering,
Mathematics, and Computer Science, at the University of Twente, Enschede, Nether-
lands. I am greatly indebted to him for the several discussions that kept me focus to
the aim and objectives and also carrying a sense of humor when I had lost mine.
The end result of this thesis and successful submission of papers is a true reflection of
my supervisors patience in me that Formal Methods is a worthwhile field to invest in.
Completing this work would have been all more difficult were it not for the support and
goodwill of my colleague and co-supervisor, Mr. Kaylash Chaudhary of the School of
Computing, Information and Mathematical Sciences at the University of the South
Pacific. I deeply express my sincere appreciation for his prolific and valuable sugges-
tions, motivation and counselling in every phase of the arduous but meritorious task.
My sincere thanks goes to my internal supervisor Dr. Robin Havea for his guidance
and stimulating discussions in editing my thesis and enlightening me on the first glance
of research.
I would also like to thank the experts who were involved in the validation survey for
this research project. Without their passionate participation and input, the validation
survey could not have been successfully conducted.
My sincere gratitude goes to the University of the South Pacific, Faculty of Science,
Technology and Environment (FSTE), School of Computing, Information and Mathe-
matical Sciences (SCIMS), and Research Department for providing financial support
towards my studies and giving me the opportunity to attend conferences and meet in-
teresting people within the field of Formal Methods.
Finally, am greatly indebted to my family, especially to my parents, my wife, and
son for their patience and motivation. All things considered, without their persistent
support this thesis would never have been finished.
iv
Contents
Abstract ii
Acknowledgements iv
1 Introduction 1
1.1 General Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Proposed Methodology . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4 Research Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.5 Research Contribution . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.6 Thesis Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2 Background and Literature Work 6
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2 Wireless Mesh Networks . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3 Mobile Ad hoc Networks . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4 Routing Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4.1 Optimised Link State Routing Protocol . . . . . . . . . . . . 10
2.4.2 Ad hoc Distance Vector Routing Protocol . . . . . . . . . . . 11
2.5 Formal Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.6 Automata Theory . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.7 Temporal Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.8 Model Checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.9 Probabilistic Model Checking . . . . . . . . . . . . . . . . . . . . . 15
2.10 The UPPAAL Model Checker . . . . . . . . . . . . . . . . . . . . . 16
2.11 Formal Methods in Routing Protocols . . . . . . . . . . . . . . . . . 19
2.12 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3 Topology Based Mobility Models for Wireless Systems 22
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.2 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.3 Topology-Based Mobility Model . . . . . . . . . . . . . . . . . . . . 25
v
3.4 Random Walk and Random Waypoint . . . . . . . . . . . . . . . . . 28
3.5 Simulations of Two Mobility Models . . . . . . . . . . . . . . . . . . 28
3.5.1 Simulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.5.2 Simulation Results . . . . . . . . . . . . . . . . . . . . . . . 31
3.6 UPPAAL Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.7 Case Studies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.7.1 AODV Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.7.2 The Lightweight Medium Access Control (LMAC) Protocol . 39
3.8 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4 Modelling, Verification, and Comparative Performance Analysis of the
B.A.T.M.A.N. Protocol 42
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.2 The B.A.T.M.A.N. Protocol . . . . . . . . . . . . . . . . . . . . . . 44
4.3 Data Structures and Constants . . . . . . . . . . . . . . . . . . . . . 46
4.4 Handling of Originator Messages . . . . . . . . . . . . . . . . . . . . 47
4.5 Processing of Originator Messages . . . . . . . . . . . . . . . . . . . 50
4.6 Untimed Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.7 Timed Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.8 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5 An Even Better Approach – Improving the B.A.T.M.A.N. Protocol Through
Formal Modelling and Analysis 59
5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.2 The B.A.T.M.A.N. Protocol . . . . . . . . . . . . . . . . . . . . . . 60
5.2.1 Literal Model . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.2.2 Alternative Model . . . . . . . . . . . . . . . . . . . . . . . 65
5.3 UPPAAL Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.4 Simulation Results . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
6 Conclusion 76
List of Publications 87
vi
A 88
A.1 Chapter 3 - Topology-based Mobility Models for Wireless Networks . 88
A.2 UPPAAL Model - Random Walk Model . . . . . . . . . . . . . . . . 89
A.3 UPPAAL Model - Random Waypoint Model . . . . . . . . . . . . . . 90
A.4 C++ Code for a Mobile Node travelling amongst Static Nodes . . . . 90
B 91
B.1 Chapter 4 - Modelling and Verification of the
B.A.T.M.A.N. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 91
C 92
C.1 Chapter 5 - An Even Better Approach
- Improving the B.A.T.M.A.N. Protocol Through
Formal Modelling and Analysis . . . . . . . . . . . . . . . . . . . . 92
vii
List of Figures
2.1 Infrastructure based wireless networks . . . . . . . . . . . . . . . . . 7
2.2 Infrastructureless or Ad Hoc Wireless Networks. . . . . . . . . . . . 8
2.3 Future operators in temporal logic. . . . . . . . . . . . . . . . . . . . 14
3.1 Transmission ranges 1,√
52
≈ 1.12, 56
√2 ≈ 1.18, 1.25 and
√2 ≈ 1.41
[31]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2 Three different regions and their corresponding set of neighbours for
range R = 1.25 [31]. . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.3 Possible transitions within a single grid cell for R=1.25. . . . . . . . 27
3.4 shows an example of a node movement in Random Walk Model. . . . 29
3.5 shows an example of a node movement in Random Waypoint Model. 29
3.6 shows how a waypoint is reflected when using random walk model. . 31
3.7 Selected simulation results of the random walk and the random way-
point model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.8 UPPAAL template for the mobility model. . . . . . . . . . . . . . . 36
3.9 AODV: probability of packet delivery within a certain time. . . . . . 38
3.10 LMAC: number of collisions within 2000 time units. . . . . . . . . . 40
4.1 Routing table for A before and after processing two OGMs from orig-
inators B and C. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.2 Timed model for simulation. . . . . . . . . . . . . . . . . . . . . . . 53
4.3 Simulation results. The results are averages over 100 runs, except for
the maximum buffer size, which is the maximum over 100 runs. . . . 56
5.1 Sliding window for Node A in the literal model, before and after an
update. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
5.2 Sliding window for Node A in the alternative model, before and after
an update. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.3 Timed model for simulation. . . . . . . . . . . . . . . . . . . . . . . 68
5.4 Results on route discovery and route mistakes for static topology. Av-
erages over 100 runs. . . . . . . . . . . . . . . . . . . . . . . . . . . 70
5.5 Results on route mistakes and route error for dynamic topology. Aver-
ages over 100 runs. . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
viii
5.6 Recovery after link deletion or addition. Values are averages. . . . . 73
5.7 Classification of received OGMs. Averages over 100 runs. . . . . . . 74
5.8 Classification of OGMs generated in literal model by alternative model
rules (left), and vice versa (right). . . . . . . . . . . . . . . . . . . . 74
ix
List of Tables
2.1 Input, output and states of an automaton . . . . . . . . . . . . . . . . 12
3.1 Transmission Range: Number of possible topologies, in relation to the
range and the grid size. Results for the point intervals containing√
52
and 56
√2 are omitted. . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.1 Comparison of literal and alternative B.A.T.M.A.N. models. . . . . . 62
x
List of AbbreviationsThe table below describes the various abbreviations and their meanings used through-
out the thesis.
Abbreviation Meaning
AODV Ad hoc Distance Vector
B.A.T.M.A.N. Better Approach to Mobile Ad hoc Networks
IAB Internet Architecture Board
IETF Internet Engineering Task Force
IRTF Internet Research Task Force
LMAC Lightweight Medium Access Control
MANETs Mobile Ad hoc Networks
OGMs Originator Messages
OLSR Optimised Link State Routing Protocol
OSI Open System Interconnect
RFC Request For Comments
SMC UPPAAL Statistical Model Checker UPPAAL
TTL Time to live
WMN Wireless Mesh Networks
xi
Chapter 1
Introduction
1.1 General Introduction
Communication in networks is essential everyday and there are many components that
contribute towards its efficiency. Network routing protocols play a vital role in making
this possible. When two nodes communicate, the router chooses the route or path in the
network. The router has no a priori knowledge of the nodes connected to the computer
network. The routing protocol dictates how a router exchanges information with each
other.
There are many routing protocols and they all function differently but have the
same objective, that is to make communication and delivery of packets successful from
source to destination by finding the most optimal route. When a node joins a network,
it needs to get itself identified. With the networking mechanisms available in place,
information of its existence is shared with its immediate neighbours and then dissemi-
nated with the whole network. This way the routers are aware of the devices within the
topology by exchanging routing messages, such as originator or HELLO messages.
In general, desirable routing protocol objectives are: route discovery, route main-
tenance and loop freedom. These three cover the main aspects of a successful network
routing algorithm.
Route discovery is finding the best available route to the destination when sending
a message. Route maintenance is basically how route problems are reported and re-
covered. It simply means that when a node joins a wireless mesh network (WMN), the
network information needs to be updated and other nodes are to be informed. Similarly,
a node leaving the network has to have other nodes update their routing information.
Loop are a common problem in a computer network. This causes an infinite loop and
packets transit in orbit.
Traditionally, Formal Methods have been used for verifying the properties of net-
work routing protocols. Verification process proves the validity of a given property
that can be analyzed for performance and correctness.
1
In this thesis, an existing network routing protocol is studied which has also been
analysed by external research groups. The routing protocol of interest that will be
formalised, modelled and analysed is B.A.T.M.A.N..
The reason for choosing B.A.T.M.A.N. was that it was a fairly new network routing
protocol, research was still undergoing [8, 56, 67], and to test the properties that the
protocol claimed. There are some papers that have been looked at AODV and OLSR
routing protocols [68, 32, 51, 52]. Recently, the predecessor of B.A.T.M.A.N., Opti-
mised Link State Routing (OLSR), has also been investigated and its properties have
been validated and verified [51]. To date, B.A.T.M.A.N. is still in the internet draft
format and some updates can be found on [69].
Before a protocol is standardised, they are initially in the internet draft format. An
internet draft is a technical document produced by four streams: Internet Engineering
Task Force (IETF), the Internet Research Task Force (IRTF), the Internet Architecture
Board (IAB), and Independent Submissions.
The internet draft [69] will be used to understand how the protocol operates and
behaves. Using Formal model, certain properties will be verified. SMC UPPAAL is
used to analyse the protocol. It provides an input language and a formal specification
language to formalise the requirements.
This thesis will present formal models and will outline the potential problems of
the routing protocol, as well as capabilities and limitations of the analysis.
1.2 Motivation
Computer networking has grown tremendously with new routing protocols taking care
of the complexity. The improved version of routing protocols has benefited in terms
of performance and delivery of packets. There exists a number of routing protocols
in wired and wireless networks. This includes LUNAR, DYMO, OSPF, DSDV, IS-IS,
BGP and IGRP/EIGRP.
The recent routing protocol in ad hoc networks is B.A.T.M.A.N. and its prede-
cessors are OLSR and AODV. For searching routes, nodes have to flood packets in
AODV protocol [47]. In case of OLSR, the size of the routing table grows nonlin-
eraly which can cause the blocking of the actual data packets [47]. However, the
B.A.T.M.A.N. protocol overcomes these limitations as claimed in the internet draft
[69]. B.A.T.M.A.N. instead populates its routing table and makes decisions for the
next best next hop unlike other routing protocols that keep information for the entire
2
topology.
1.3 Proposed Methodology
One of the key objectives of this thesis is to do performance analysis of B.A.T.M.A.N.
routing protocol. The following steps are used to model and analyse the B.A.T.M.A.N.
routing protocol:
1. A detailed survey of methods that can be used for the modelling and analysis of
routing protocols.
2. For any model checking tool, the following needs to be developed:
(a) A model of the system needs to be developed using the model description
language of the model checker at hand.
(b) Simulate the model to confirm the behaviour of the protocol.
(c) Properties of the routing protocol need to be formalised using the property
specification language.
3. Evaluate the B.A.T.M.A.N. routing protocol using a model checker. Determine
whether the formalised properties are satisfied or violated.
4. If any property is violated then the following should be followed to ensure that
indeed a model does not have this property:
(a) Refine the model, design or property
(b) Repeat the entire procedure.
1.4 Research Objectives
The principal objective of this thesis is to formalise B.A.T.M.A.N. routing protocol
and to find alternatives for any property not performing according to the internet draft
[69].
The objective can be divided into the following specific aims:
• Evaluate the capabilities of SMC UPPAAL that are available for formal verifi-
cation and determine the technique which could be used to verify B.A.T.M.A.N.
protocol.
3
• Develop a formal model of B.A.T.M.A.N. Protocol.
• Assess the B.A.T.M.A.N. protocol properties against the criterion gathered from
the internet draft [69].
• Explore design alternatives of B.A.T.M.A.N. Protocol and suggest possible al-
ternatives in the design.
1.5 Research Contribution
The major contribution of this thesis could be summarised as follows:
• Proposed a topology-based mobility model, that abstracts from physical be-
haviour, and models mobility as probabilistic changes in the topology. It is
demonstrated how this model can be instantiated to cover the main aspects of
the random walk and the random waypoint mobility model. The model is not a
stand-alone model, but intended to be used in combination with protocol models.
This is illustrated with a brief analysis of Ad-hoc On demand Distance Vector
(AODV) routing protocol, and second it is combined with the mobility model
with the Lightweight Medium Access Control (LMAC).
• Two models are developed for B.A.T.M.A.N. using SMC UPPAAL model checker.
The first is a literal model as stipulated in the internet draft [69]. The second is
an alternate model that overcomes the errors in the literal model.
• For both models, loop-freedom, bidirectional link discovery, and route-discovery
properties have been verified. The simulation of a timed model was used to
compare the performance and found that both models are comparable when it
comes to the time and number of messages needed for discovering routes.
• The performance is compared using simulations in SMC UPPAAL, for static
and dynamic topologies. As a result, the alternative model reduces the number
of suboptimal routes significantly, and recovers better from routing errors that
are introduced by mobility.
1.6 Thesis Outline
The structure of the thesis is as follows:
4
• Chapter 2 provides the background and literature work. It incorporates the vari-
ous strategies and related work that has been done to the model and verify routing
protocols using Formal Methods.
• Chapter 3 looks at how node mobility can affect the overall performance where
route discovery and route establishment fail. Using formal techniques, it pro-
poses a prototype and provides an analysis of how it works with other mobility
and protocol models.
• Chapter 4 introduces Better Approach to Mobile ad hoc Networks (B.A.T.M.A.N.),
a literal version as described in the internet draft. Some of its properties are
described with relevant examples that exist in making decisions for the next
best hop. B.A.T.M.A.N. routing protocol is formalised using Statistical Model
Checker (SMC) and aims to prove two important properties: discovery of all
bidirectional links and identification of the best-next-hop when a packet is sent
from source to destination.
• Chapter 5 is a formalism of B.A.T.M.A.N. and provides an alternate version
comparing performance with the literal version as modelled in chapter 4 and
analysing using simulations in SMC UPPAAL for static and dynamic topologies.
• Chapter 6 presents a general discussion about modelling and verification of
routing protocols, describes the contributions of this research and provides an
outline of future work.
5
Chapter 2
Background and Literature Work
2.1 Introduction
Wireless mesh networks and its infrastructure have been a major concern in network-
ing today. This is because of mobility of nodes and having connectivity at the same
time. Another interesting attribute that has contributed to that is how network traffic is
directed efficiently. This means that when a message is sent from source to destination,
there are many different routes it can take for successful transmission. This is decided
by the routing algorithm and technically it chooses the best path to take.
Newer algorithms are tested in the internet draft state before it is declared as a
standard after several test runs and corrections. It is critical to verify these algorithms
in the early phases of its development.
Early error finding could lead to more stable and trustable algorithms [66]. This is
when model checking is done. The model is a representation of the system automati-
cally to see if it meets the given specification.
Models have been made using tools that are available to verify and validate network
routing protocols. These models are known as abstractions that represent the protocol.
The verification process could lead to identify the errors and prove its correctness. This
could lead to improving the network routing protocol and notify future enthusiasts in
the field of formal methods.
Section 2.2 introduces the different types of wireless networks and Section 2.3
the use of devices in a mobile environment. Different types of routing protocols is
presented in Section 2.4. Formal Methods is presented in Section 2.5, followed by
Section 2.8 describing the Model Checking process. Section 2.9 discusses Probabilistic
Model Checking and the theory behind it. Section 2.10 looks at Statistical Model
Checker UPPAAL and its attributes. Section 2.11 gives a review of routing protocols
which have been verified and their contribution to Formal Methods.
6
Hand-over
Figure 2.1: Infrastructure based wireless networks
2.2 Wireless Mesh Networks
In a wireless mesh network (WMN), nodes are connected via wireless links and have
the freedom of movement within a certain transmission range [24]. Nodes are able to
join and leave the network in an ad hoc manner. WMNs cannot be used with power
constrained devices because of continuous transmission or search for network connec-
tivity [4].
There are two types of wireless network.
1. Wireless Mesh Networks (WMNs)
2. Mobile ad hoc Networks (MANETs)
Since they both complement each other in the environment they function in, the
illustration in Figure 2.1 gives a better explanation. The figure shows that there are
base stations and as the mobile node goes out of range, it gets into range of another
transmitting node [45]. Mobile node in an infrastructure wireless network is able to
communicate out of range but connectivity is maintained with the help of other nodes
within the topology.
On the other hand, in an infrastructureless or ad hoc wireless network, there are no
fixed stations and all the nodes in the network act as routers. The individual nodes that
are also mobile in the ad hoc environment, self configures itself and enables routing
7
Figure 2.2: Infrastructureless or Ad Hoc Wireless Networks.
among themselves forming their own network [70]. This is illustrated in Figure 2.2
[45].
2.3 Mobile Ad hoc Networks
Mobile ad hoc networks (MANETs) is defined as the ability of mobile devices to form a
self-creating, self-organizing, and self-administering wireless network [1, 75]. Nodes
in a MANET are able to act as a router to locate the most reliable path in order to
forward a packet. The network topology is dynamic due to the incoming and outgo-
ing movement of mobile nodes [2]. For continuous connectivity and communication,
nodes work collaboratively to handle network system capacities. One of the most vi-
tal things for a MANET is to keep up with the impromptu network system and its
maintenance.
Freedom of movement for such devices is possible. The devices are able to join or
leave the network resulting in rapid and volatile topological changes. It is self-healing
i.e. in case a node loses connectivity; the network automatically finds the fastest and
most reliable paths to send data. Nodes are able to be added and removed, making the
network adaptable, scalable, cheap, quick, reliable and useful for non-line of sight.
The question that arises in WMNs and MANETs is routing. Packets can be routed
using different routes of which one will be optimal. Optimality does not only look
at routing hops but other routing metrics are also involved to determine an optimal
routing path such as bandwidth, delay and reliability.
B.A.T.M.A.N. uses reliability as a routing metric to measure its success of packets
8
reaching its destination. The conventional way of counting the number of hops and
keeping a track of packet count has been decisive in choosing the correct path but it
has been problematic to some extent.
2.4 Routing Protocols
Transportation of packets from source to destination is known as routing [11]. A rout-
ing protocol uses algorithm to determine the best network path (route) to transfer data
between nodes. It facilitates router communication and overall network topology un-
derstanding.
There has been many routing algorithms proposed and these have been in existence
since WMNs and MANETs. Wired networks are considered to be static therefore
the protocols used in that cannot adapt well to WMN. Nodes leaving and joining the
network in MANETs topology is the major concern.
Individual routing protocols are used in different scenarios [4] and these protocols
have certain algorithmic processes that execute differently. The obvious reasons are
performance optimality and route discovery. There are three categories of network
routing protocols [2].
• Proactive: these routing protocols are table driven which means having infor-
mation about the topology and its nodes even before it is needed. Every node
consists of a table and information in them needs to be maintained. The in-
formation in the table is passed on from node to node within the topology and
this update happens at a certain time interval whenever there is a change [40].
This creates freshness in the routing information so that nodes knows which is
the best next hop [74]. Major advantage of this is that, it reduces the latency
of exchanging and updating information periodically which in fact expends the
bandwidth.
• Reactive: these routing protocols have individual tables constructed on nodes
on-demand because nodes are not aware of the network topology [3]. They
activate when a node initiates a route discovery throughout the network when it
wants to send packets from source to destination. It’s basically source-initiated
[2]. Source to destination pathway is decided by the information updated on the
routing tables of each node. The tables are updated when the node that wants to
send a packet. This is only for active routes.
9
• Hybrid: is a combination of distance vector and link state routing protocols.
They work according to the networking environment where the purpose and sit-
uation based target applications exist [60]. By accumulating the best components
of proactive and reactive systems, hybrid protocol allows sending of information
occasionally, and reacting to sudden changes in attribute values [44].
Below is a list of desirable and basic properties of network routing protocols in a
wireless network [59].
• A distributed operation that makes sure communication of packets to and from
is going on amongst nodes.
• There is loop-freedom where packets are not orbiting aimlessly around the net-
work for arbitrary time period.
• Having a demand-based operation where the routing algorithm adapts to the traf-
fic pattern on a demand or need basis, and not assuming a uniform distribution
at all times.
• The ability of nodes to have bi-directional links. Bi-directional links is when a
node A is connected to B via A to B and B to A via some path.
• An effective and efficient data routing.
2.4.1 Optimised Link State Routing Protocol
Optimised Link State Routing protocol (OLSR), is a proactive routing protocol, which
has been favorable and best known for large and dense MANETs. For each device
in this environment, the algorithm allows participating nodes to store the routes to all
destinations in a tabular form for optimization purpose. This way there is no centralised
distribution of information and a periodic broadcast of messages are sent as a technique
to flood the network to identify and update tables on individual nodes. In this way, the
tables maintain and update a fresh list of nodes [74].
The size of information sent or broadcasted is compact and OLSR reduces the
number of retransmissions when flooding the network. Having the entire map of the
network stored in individual tables on each node is one of the major characteristics
of OLSR that enables each node to easily determine the optimal route to every other
node.
10
2.4.2 Ad hoc Distance Vector Routing Protocol
Ad hoc Distance Vector (AODV) routing protocol, is reactive and table driven [32].
Individual nodes have tables that are updated constantly and this is done when infor-
mation amongst nodes is shared [25].
This protocol uses algorithm that belongs to a class of distance vectors and the
individual nodes according to the information on its table knows the cost of reaching
its neighbours.
This protocol is claimed to be loop-free and scales to a large number of mobile
nodes.
2.5 Formal Methods
Trying to identify error(s) within a system is difficult and such mistakes can lead to
critical damage or information loss in a network. Successful transfer of data in a net-
work system is an important goal in network engineering [41]. Looking at the history
of software engineering, there have been huge and notorious bugs that have caused
financial losses, deaths and many other defects that have been reported [37, 55, 85].
There are systems that have used Formal Methods, such as medical [48], telephony
[62, 88, 89], security [14, 28], transportation [19, 43, 54] and many more.
Formal Methods uses tools and techniques to specify, verify, and validate systems
with its requirements. The main focus of Formal Methods is rigor design and devel-
opment of systems. In this approach, a formal specification is created by applying
syntax and semantics, which is defined mathematically in a language [22]. This leads
to building a model that is an abstraction of the system. Detection of errors in the early
design phase of a system can be corrected prior to implementation, thus the system can
be verified and this is compared by testing with the real system [7].
The verification stage in formal methods is to prove if the properties in the model
is correct. This is called model checking. The model (abstraction) which represents
the real system is tested to see if all possible behaviour is present in it [7]. During
the verification process, system properties, its functional behaviour, performance char-
acteristics are verified based on the formal specification [22]. In this way it is vital
that the model accurately speaks of the genuine framework. Smaller systems can be
verified manually but it can be prone to errors. Theorem proving is another computer
aided verification technique but is implemented with the guidance of humans whereas
11
AUTOMATON
Input:
set I {x1, x,2, x3... xk}where k, is the number of inputs
Output:
set Z {y1, y2, y3 ... ym}where m is the number of outputs
States:
finite set Q
whose definition depends on the type of automaton
Table 2.1: Input, output and states of an automaton
model checking is fully automatic. In this thesis, model checking will be studied.
2.6 Automata Theory
Automata theory helps to solve computational problems using automata and abstract
machines. It examines the dynamic behaviour of systems and analyzes transitions on
certain intervals. The models created is an abstraction of the real world system.
Symbols are used as an input to an automaton and these form a finite sequence
called words. Each input is taken at every step in an automaton known as alphabets.
The automaton is made up of: finite set of states, an alphabet, a transition function,
the start and accept states. An automaton initially, can be in any given state. Upon
reading a symbol, an automaton transits from one state to another. This is known as a
transition. The automaton will stop when it reaches the final state.
Table 2.1 describes the attributes of an automaton that include input, output and
states.
Deterministic and Non-Deterministic are two types of finite automata. In deter-
ministic automata, every time a symbol is input, it leads to a unique state regardless of
the automaton being in any current state whereas for a non-deterministic automata, the
automaton could jump to any possible state.
Definition 2.6.1. For a deterministic finite automata, every automaton can be defined
as tuple.
12
The following are the attributes of tuple T:
T = (S, X, S init, F n, Y )
• S is a finite set of state.
• X is a finite set of symbol.
• Sinit is a set of initial states and a subset of S.
• F n : S × X → S is a transition function.
• Y is a set of accepted states and a subset of S.
When executed, a deterministic finite automaton over a word is: ω = a1, a2, ...., an
where an ε X, that has a sequence of states s0, s1, s2, ..., sn where sn ε S where:
• s0 is the start state (initial state) and
• si = F n(si−1, ai), 0 ≤ i ≤ n if and only if when sn+1 ε Y
Definition 2.6.2. For a non-deterministic finite automaton, every automaton can be
defined as tuple.
The following are the attributes of tuple T:
T = (S, X, S init, F n, Y )
• S is a finite set of state.
• X is a finite set of symbol.
• Sinit is a set of initial states and a subset of S.
• F n : S × X × S is a transition function.
• Y is a set of accepted states and a subset of S.
When executed, a non-deterministic finite automaton over a word is: ω = a1, a2, ...., an
where an ε X, that has a sequence of states s0, s1, s2, ..., sn where sn ε S where:
• s0 is the start state (initial state) and
• (si, ai, si + 1) ε R, 0 ≤ i ≤ nif and only if when sn+1 ε Y
13
Figure 2.3: Future operators in temporal logic.
2.7 Temporal Logic
Rules and symbolisms are used to represent time dependent systems in Temporal Logic
[82]. The formula in temporal logic can be true for some states and false for others.
Expressions in Temporal Logic varies with respect to time and can be expressed as:
• I am always hungry
• I will eventually be hungry
• I will be hungry until I eat something
The expression is either true or false. Temporal logic consists of two types of
operators: logical and temporal. Logic uses truth functional operators (¬,∨,∧,−→)
and temporal uses future operators (o, ♦, �,⋃
, R or [64]. Figure 2.3 explains these
future temporal logic operators.
2.8 Model Checking
Model checking has been in existence since the 1980’s [29, 49]. It is a computer aided
verification technique used to model and verify properties of finite state concurrent
systems [22]. A model can be designed for any given system. The model is a rep-
resentation of how the system behaves and is designed using a model checker. The
requirements are embedded into the system that formalise the properties. The proper-
ties are tested against the system’s model using a model checker. The model checking
process will output whether the properties are violated or satisfied. A violated prop-
erty will have a counter example generated to testify if the error can be located. This
14
counter example allows to see where the error lies and its cause. During this process,
the flaws of the system can be identified.
There are two phases in model checking. Modelling is the first phase where the
system is expressed as an automata which consists of a finite set of states and transi-
tions. States refer to the values of the variables used in the model and the execution
segment that led to the current state. During this phase the property to be checked
needs to be described using a property specification language such as temporal logic.
Different types of properties can be checked using model checkers; reachability, live-
ness, safety, fairness and functional correctness [7]. The functional correctness and
reachability properties will be studied. The former checks whether the system does
what its suppose to do. The latter sees if a given state is reachable from some state.
The model can be validated using a simulator. Most model checkers comes with a
simulator that helps model checkers to remove model errors which could interact with
the results of verification.
The second phase is verification and analysis. The model checker is run to verify
the properties based on the model from the modelling phase. A property can either
be satisfied or violated. A problem during the verification phase is when the model
checker runs out of memory and will not give any result. This is known as state space
explosion. This does not mean that a violated property has a design flaw. It could be
a model error. For this, the model needs to be corrected and the concerned property to
be executed again. A thorough check of the results is needed.
A major problem of model checking is state explosion. The computers memory is
not large enough to cater for the states of the system modeled. There are some ways
to tackle this problem like abstraction, partial order reduction etc. Other limitations
of model checking can be found in [5]. Despite the limitation, model checking is still
considered as an effective technique for hard- and software verification [7].
2.9 Probabilistic Model Checking
Model checking focuses on the complete guarantee of whether a system is correct or
not. Making a definite statement as such or even a notion is difficult to assure. There-
fore, there is a certain area of study or proving that requires some form of uncertainty
such as, automated verification of probabilistic systems which include randomised al-
gorithms, modelling systems to study their behaviour, and evaluating system mod-
els for their performance [7]. Some examples of randomised algorithms are, Monte
15
Carlo algorithm, Quick-sort, Las Vegas algorithm. These algorithms are tested to see
whether the processes eventually reach with a probability of 1. Those models which
are designed to represent a system, their behaviour is verified during the progression
of the design phase to see its level of correctness and compute probabilities of reach-
able properties [30]. An example for evaluating system performance is when a system
needs to be verified to see if there is a delay of packets reaching from source to its
destination, orbits in a loop or if failure exists.
An automaton can have a probabilistic approach for a particular transition over the
next set of states [77].
Definition 2.9.1. A probabilistic automaton can be defined as a tuple:
Ap = (S, Sinit, A,R, F )
• S is a set of states.
• Sinit is a set of initial states and a subset of S.
• A sets of actions A consisting of internal and external actions.
• A transition relation R ⊂ S × A × Distr(S)
• F is a set of accepted states and a subset of S.
This verification technique analyses the system with probabilistic behaviour.
2.10 The UPPAAL Model Checker
Real time systems can be verified using UPPAAL model checker. The UPPAAL model
checker has been developed jointly by Uppsala and Alborg Universities [26]. UPPAAL
model checker has a graphical user interface that allows a user to construct, simulate
and verify a model of a system. Systems are designed in UPPAAL and are called
timed automata. These are known as finite state machines that consists of a clock.
Each automata can have clock variables defined in them to measure time progress.
Clocks play a vital role in the verification of real-time systems. Timed automaton are
represented as graphs that is made of locations and edges. Locations connected to each
other are done via edges. An edge has a guard (condition), selection, synchronisation,
and update. These components are called labels.
The following features used in UPPAAL are:
16
• Templates: an automata is defined as a template. A template also has provisions
for parameters which can be of type int, chan, etc. A system is composed of
processes; each process is an instantiated template. A template can be used by
one or many processes. The parameter will be replaced with value when the
processes are defined in the systems declaration.
• Bounded Integer Variables: integer variable can be declared with bounds. For
example, int [MIN,MAX] x; , where x is an integer variable which can store
values ranging from MIN to MAX. An unbounded integer variable can also be
declared. The range for that integer variable will be -32676 to 32676.
• Constants: variables whose value will not change during execution. For exam-
ple, const int MAX = 10;, where MAX is a constant variable with a value of 10.
This variable cannot be used by the program to assign any values.
• Channels: processes communicate using channels. Channels make processes
take transition at the same time. There are three different types of channels:
– Regular Channel - this channel is used for binary synchronisation. The
keyword, chan, is used to declare regular channel. For example, chan c,
where c is a regular channel. Two processes can be synchronised using this
channel. One process will have c! on a transition while another will have
c?. The transitions can be made if both are enabled. If there are update
expression on these transitions then the update on c! transition will happen
before c? transition.
– Broadcast Channel - this channel is used to synchronise two or more pro-
cesses. It is declared as broadcast chan c, where c is a broadcast channel.
One process will have c! on a transition while one or more processes will
have c?. Transition with c! will be taken even if there is no transition with
c? enabled.
– Urgent Channel - no time is allowed to pass at source state in this chan-
nel. This also means that clock guards are not allowed. Urgent channel is
declared using keyword, urgent. For example, urgent chan c.
• Locations -These are nodes on a graph and there are four types:
– Initial Location - Every automaton has a specific initial location and must
be properly initialised. It is illustrated with double circles.
17
– Urgent Location - An urgent location is represented with a "U". At this
location, time is not allowed to pass. A process at urgent location have
to leave before time could pass. Other transitions may happen before, as
long as they do not require time to pass and clock will not increase as long
as in urgent location.
– Committed Location - Like urgent locations, these also are not allowed
to pass when a process is in one of them. These are illustrated with a
"C" inside the circle. If several processes are in a committed location at
the same time, then they will interleave and these committed locations are
useful for creating atomic sequences.
– Normal Location - A circle denotes a normal location and there are no
restrictions.
• Arrays - clocks, channels and integer variables can be declared as arrays. For
example, int[0,2] x[3], where x is any array of size 3. It can store integer
values ranging from 0 to 2.
• Structs - record types just like C language, are special type of classes. The key
word struct is used to group of members, for example:
typedef struct {
bool entries[WINDOW_SIZE];
} SlidingWindow;
• Typedef - user defined types similar to C language. For example, typedef
int[1,N] id t; , where id t is of type integer and has the range from 1 to N.
Type id t can be used to declare variables.
• Functions or Methods - these are user defined and can be either in the template
or global declaration.
UPPAAL has following labels for expressions:
• Select - provides a non-deterministic choice based on values. For example,
add:int[1,10], where add can have any value from 1 to 10.
• Guard - is a condition expressed in terms of variables and clocks which indicates
when the transition can be taken.
18
• Synchronisation - this is achieved using channels.
• Update - an update changes the state of the system by updating variables. This
is executed as soon as a transition is taken.
• Invariants - are conditions on initial and normal location only. An automaton
can stay at a location until the invariant holds and then leave the location.
When the model has been done, the simulator can be used to ensure that the model
behaves as the system is supposed to according to the requirement specification. This
is to detect errors and can be done by verifying the properties.
There are certain properties that can be expressed in the UPPAAL query language.
These properties are tested for certain conditions in a particular scenario of the model’s
potential behaviour. There are four different types of properties in UPPAAL:
• Reachability Properties - a condition holds in some state of an execution path.
– E <> P - in some path, some state P will eventually hold.
– E [] P - there exists a path in which P holds for every state in that path.
– A [] P - P holds for all states in all paths.
– A <> P - P holds for for at least one state in all paths.
– Q − > P - in a path, if there comes a state in which Q holds then there will
be a state in which P will hold.
• Deadlock Properties - checks for a deadlock in the model using the property
A[] not deadlock.
2.11 Formal Methods in Routing Protocols
Routing protocols have been modelled and verified for some years now but verification
of it in a WMN environment has been quite a challenge. Formal methods have been
used in a number of real world case study applications [12, 57]. Research is evident
and recommendations regarding formal strategies have huge potential for enhancing
clarity in proving properties and finding unobtrusive blunders [17, 27].
A number of routing protocols such as OLSR, AODV, LMAC and B.A.T.M.A.N.
have had their evaluation done and is still on going [74, 2, 3, 32, 52]. Comparisons have
been made in terms of performance that have been proposed for MANETs. As Liu and
19
Kaiser suggests that there is no "one-for-all" scheme that works in scenarios
with different network sizes and node mobility patterns [58]. They also state that it
is not clear that any particular algorithm is best suited for all scenario but instead for
certain situations.
Protocols are based on different design philosophies and have specific requirements
from different application domains. Thus, the performance of a mobile ad hoc routing
protocol may vary dramatically with the variations of network status and traffic over-
head. The performance variations of mobile ad hoc network routing protocols make it
a difficult task to give a comprehensive performance comparison for a large number of
routing protocols. It relies on the size of the network and pattern in which the mobile
nodes move. A generic conclusion was reached that the size of the network topology,
mobility of nodes and traffic pattern also has an effect on how the routing protocol will
perform.
Hofner et al. presents a formalism of AODV routing protocol with its specifica-
tion done specifically tailored for MANETs and WMNs using SMC UPPAAL in [46].
Properties of AODV such as route discovery, route maintenance, error handling and
loop freedom was investigated [46]. Using model checking a generic conclusion was
made for any possible network scenario in terms of network topology, node mobility
and traffic pattern [72, 76].
Similarly, Fehnker et al. presents an automated and formalised analysis of AODV
[32] and SMC UPPAAL model checker was used. It is derived from a process-algebraic
model which reflects precisely the intention of AODV and accurately captures the pro-
tocol specification [32]. Experiments are carried out to explore AODV’s behaviour
and as a consequence undesirable behaviour results. Protocol limitations are discov-
ered and suggestions for improved invariants are made.
LMAC, is used in wireless sensor networks which was modelled by Fehnker et
al. SMC UPPAAL model checker was to detect and resolve collisions in the protocol.
Even with approximately 8000 model checking runs, increasing the number of nodes
in the topology did not lead to state space explosion. Nevertheless, less number of
nodes gave positive results. The only drawback was that it did not detect collisions
[34].
On the other hand, OLSR has been in the limelight when B.A.T.M.A.N. took over
due to an increase in network size [65]. There have been a number of comparisons
regarding performance, done between the two that can be seen in [8],[56], [67]. John-
son et al. has analysed the experiments and executed a custom based 7 × 7 grid of
20
closely spaced WiFi nodes [50]. As a outcome, B.A.T.M.A.N outperformed OLSR
resulting in better throughput, less delay, lower CPU load and lower routing overhead.
One of the disadvantages of OLSR were tables being unnecessary flushed and having
out-of-sync routing tables which caused routing loops. To cater for a larger network,
B.A.T.M.A.N. project by the Freinfunk community in Berlin was initiated.
It is clearly evident that network routing protocols have been formalised and formal
methods has had a greater impact on its improvements with the development of models
and verification of properties.
2.12 Summary
This chapter presented the characteristics of WMNs and MANETs and described how
they manage itself and the mobility of nodes in its topology. The different categories
of routing protocols are discussed and the work done. It also discusses the various
strategies in the development of the system and models used in Formal Methods.
Formal Methods and its reason for existence is justified and how it has an impact in
today’s networking era dealing with routing protocols in MANETs. SMC UPPAAL
model checker was introduced with its features that have been used in this thesis.
OLSR, AODV, LMAC and B.A.T.M.A.N. are rigorously been evaluated for their per-
formance in Formal Methods.
For verification of B.A.T.M.A.N. routing protocol, formal methods will be used.
Model checking approach will be implemented for the protocol and verification of
properties. A description of probabilistic model checking is given as quantitative anal-
ysis will be carried out.
A literature review has been carried out to see network routing protocols being
verified using Formal Method techniques and model checking. The review is evident
that mostly model checking was used to formalise , model and verify network routing
protocols.
21
Chapter 3
Topology Based Mobility Models for
Wireless Systems
3.1 Introduction
The connectivity of nodes in MANET has no centralised infrastructure. In such a sce-
nario the routing protocol finds the path between the sender and the receiver. If nodes
are in direct range of each other, then they can directly connect and communicate with
each other, but if in case nodes are not in direct range then they need some interme-
diate nodes to transfer their data packet [53]. One of problems in MANETs is finding
a multi-hop route between its origin to its destination. It is evident that intermediate
nodes are mobile thus movement does get affected by mobility.
The chapter is organised as follows: after a short overview of related work (Section
3.2), a topology-based mobility model is developed in Section 3.3. In Section 3.4
a simulator that is used to compute the transition probabilities is presented for two
common mobility models. In Section 3.5, the distilled probabilities is combined with
the topology-based model to create an UPPAAL model. Section 3.6, illustrates how
the model can be used in conjunction with protocol models. More precisely a short
analysis is presented with AODV and LMAC.
The performance and reliability of wireless network protocols heavily depend on
the network and its environment. In wireless networks node mobility can affect the
overall performance up to a point where, for example, route discovery and route es-
tablishment fail. As a consequence any formal technique for performance analysis of
wireless network protocols should take node mobility into account [31].
Traditional network simulators and test-bed approaches usually use a detailed de-
scription of the physical behaviour of a node: models include e.g. the location, the
velocity and the direction of the mobile nodes. In particular changes in one of these
variables are mimicked by the mobility model. It is common for network simulators
to use synthetic models for protocol analysis [73]. In this class of models, a mobile
22
node randomly chooses a direction and speed to travel from its current location to a
new location. As soon as the node reaches the new location, it randomly chooses the
next direction. Although these models abstract from certain characteristics such as
acceleration, they still cover most of the physical attributes of the mobile node. Two
well-known synthetic mobility models are the random walk [9] and the random way-
point model [10].
However, a physical mobility model is often incompatible with models of proto-
cols, in particular protocols in the data link and network layers, due to limitations of
the used modelling language and analysis tools. Even if it could be included, it would
add a high complexity and make automatic analysis infeasible. From the point of view
of the protocol it is often sufficient to model changes on the topology (connectivity
matrix) rather than all physical behaviour.
This chapter also proposes a topology-based mobility model that abstracts from
physical behaviour, and models mobility as probabilistic changes in the topology. The
main idea is to identify the position of a node with its current set of neighbours and
determine changes in the connectivity matrix by adding or deleting nodes probabilis-
tically to this set. The probabilities are distilled from the random walk or the random
waypoint model. The resulting model is not meant to be a stand-alone, but to be used in
combination with protocol models. For this, an UPPAAL template is provided for the
model, which can easily be added to existing protocol models. This chapter illustrates
the flexibility of the model by two application examples: the first analyses quantitative
aspects of the Ad hoc On-Demand Distance Vector (AODV) protocol [71], a widely
used routing protocol, particularly tailored for wireless networks; the second example
presents an analysis of the Lightweight Media Access Control (LMAC)[81], a protocol
designed for sensor networks to schedule communication, and targeted for distributed
self-configuration, collision avoidance and energy efficiency.
3.2 Related Work
Mobility models are part of most network simulators such as ns-2. In contrast to this,
formal models used for verification or performance analysis usually assume a static
topology, or consider a few scenarios with changing topology only. For the purpose
of this section, two research areas were distinguished: mobility models for network
simulators and models for formal verification methods. Mobility models for network
simulators either replay traces obtained from real world, or they use synthetic models,
23
which abstract from some details and generate mobility scenarios. There are roughly
two dozen different synthetic models (see [73, 18] for an overview), starting from
well-known models such as the random walk model (example [9] and the random
way point model (example [10]), via (partially) deterministic models and Manhattan
models to Gauss-Markov and gravity mobility models. All these models are based on
the physical behaviour of mobile nodes, i.e. each node has a physical location (in 2D
or 3D1), a current speed and a direction it is heading to. 3D is required when nodes
model aerospace vehicles, such as UAVs. As these models cover most of the physical
behaviour, they are most often very complex (e.g.[39, 63] and include for example
mathematics for Brownian motion. Due to this complexity these models cannot be
incorporated directly into formal models for model-checking. This chapter describes
how two of these models, the random waypoint, and the random walk model, can
be used to distill transition probabilities for a mobility model, which can easily be
combined with formal protocol models.
Including mobility into a model for formal verification is not as common as it is for
network simulators. If they are included, then typically in the protocol specification
and therefore can rarely be reused for the analysis of different protocols. Moreover,
formal verification often abstracts entirely from the underlying mobility model and al-
lows arbitrary topology changes [38, 33, 36]. Other approaches allow only random, but
very limited changes in the topology, often in the form of a scenario that involves dele-
tion or creation of links [32, 84, 78]. Song and Godskesen propose in [38] a framework
for modelling mobility; it models connectivity by distributions and propose a proba-
bilistic mobility function to model mobility, without any specifics. This chapter takes
a similar approach, but adjacency matrices to model connectivity, and works out and
analyses the transition probabilities obtained for two mobility models.
In this chapter, these are the following contributions: the idea that the position of a
mobile node can be characterised by a set of neighbours was taken, then the mobility
as transitions between these sets defined. Next, the geometry of the mobile nodes in a
grid were analysed and parameters determined which actually influenced the transition
probabilities. In fact it was established, that some parameters, such as the step size
of the random walk model had no influence on the transition probabilities. Based
on this observation a topology-based mobility model was built which could easily be
combined with protocol models.
24
3.3 Topology-Based Mobility Model
The model takes up the position of the protocol: for a protocol it only matters whether
data packets can be sent to a node, i.e. whether the node is within transmission range.
The speed, the direction and other physical attributes are unimportant and irrelevant for
the protocol. Hence the topology-based mobility model we introduce abstracts from
all physical description of a node, and also largely abstracts from time. It models the
node as a set of one-hop neighbours, i.e. nodes that are within transmission range of
the node. Movement is modelled as a transition from one set of neighbours to another.
It is assumed that the node to be modelled moves within a quadratic N × N grid
of stationary nodes. The model is a replacement of synthetic models. For simplicity it
is assumed that nodes in the grid have a distance of 1, and that both the stationary and
the mobile node have the same transmission range R. Obviously, the model depends
on the grid size and the transmission range. It is further assumed that the transmission
range R is larger than 1 and strictly smaller than√
2. If it were smaller than 1, nodes
in the grid would be outside of the range of all neighbours, if it were larger than√
2
nodes could communicate diagonally in the grid.
The network topology of all nodes, including the mobile node, can be represented
by an adjacency or connectivity matrix A with
Ai,j =
⎧⎨⎩
1 if D(i, j) ≤ R
0 otherwise,
where D(i, j) is the distance between the nodes i and j using some kind of metric,
such as the Euclidean distance.
Figure 3.1: Transmission ranges 1,√
52
≈ 1.12, 56
√2 ≈ 1.18, 1.25 and
√2 ≈ 1.41 [31].
While the connectivity matrix has theoretically 2N2possible configurations, with N
the number of nodes, a network with one mobile node will only reach a small fraction
of those. First, the matrix is symmetric. Second, all nodes, except for one, are assumed
25
static, and the connectivity Ai,j between two static nodes i and j will be constant.
Third, due to the geometry of the plane, even the mobile node can only have a limited
number of configurations. For example, neither a completely connected node, nor a
completely disconnected node is possible given the transmission range.
The possible topologies depend on the transmission range: the larger the range the
larger the number of possible nodes that can be connected to the mobile node. Within
the right-open interval [1,√
2], the set of possible topologies changes at values√
52
,56
√2
and 1.25. These values can be computed with basic trigonometry. Figure 3.1 illustrates
which topologies become possible at those transmission ranges.
By considering the transmission range of the stationary nodes, one can partition the
plane into regions in which mobile nodes will have the same set of neighbours. The
boundaries of these regions are defined by circles with radius R around the stationary
nodes. Figure 3.2 depicts three possible regions and a transmission range R = 1.25;
stationary nodes that are connected to the mobile node (located somewhere in the
coloured area) are highlighted.
Figure 3.2: Three different regions and their corresponding set of neighbours for range
R = 1.25 [31].
As convention the nodes will be numbered from the top left corner, starting with
node 0. This partitioning abstracts from the exact location of the mobile node. Mobility
can now be expressed as a change from one region to the next. The topology-based
model will capture the changing topology as a Markovian transition function, that
assigns to a pair of topologies a transition probability.
The number of possible transitions is also limited by the partition, as every region
is bounded by a small number of arcs. If a mobile node transits an arc, a static node
has to be added to or deleted from its set of neighbours. Consider, for example, the
region that corresponds to set {1,2,6,7,12} in Figure 3.2(a). If the mobile node crosses
26
Figure 3.3: Possible transitions within a single grid cell for R=1.25.
the arc to the bottom left, node 11 will be added Fig. 3.2(b). The other two arcs of
{1,2,6,7,12} define the only two other transitions that are possible from this set. This is
called a mobility model locally defined if congruent regions yield the same transition
probabilities. Regions are congruent if they can be transformed into each other by
rotation, reflection and translation. By extension we call transitions that correspond to
congruent arcs in such regions also congruent. The movement of a node in a locally
defined mobility model is independent from its exact position in the grid. The changes
that can occur depend only on the topology of the current neighbours. For example,
the congruent sets {1,2,6,7,12} and {0,1,5,6,7} in Figure 3.2(a) and (c), would have
the same transition probabilities.
In some cases this principle will uniquely determine the transition probability: the
set {1,2,6,7,12} in Figure 3.2(b) is bounded by 4 identical arcs. This means that all of
them should correspond to a probability of 14. For other regions the partition implies a
relation/equation between some probabilities, but does not determine them completely.
Considering only transition in a single cell of the grid yields just a few and very sym-
metric transitions between possible topologies. Fig.3.3 depicts the transitions between
topologies.
One way to assign probabilities is to require that they are proportional to the length
of the arc. Alternatively, probabilities may be estimated by simulations of a moving
node in the plane. Note that the resulting probabilistic transition system will be mem-
oryless, i.e. the probability of the next transition depends only on the current region
27
(set of neighbours). In the next section, we will see that the common random waypoint
model is not locally defined, i.e. the local topology is not sufficient to determine the
transition probabilities.
3.4 Random Walk and Random Waypoint
The random walk and random waypoint mobility models are prevalent in mobile ad
hoc networks. Random Walk is performed when a node with a constant time and
distance travelled for a period then new speed and direction are chosen [18]. Each
mobile nodes start at a random location and then move to a new location by randomly
choosing a direction and speed. The mobile nodes move randomly and freely without
restrictions [13]. For example, when nodes bounce off the boundaries as billiard balls
on the surface of a pool table.
Random walk model is a memory less mobility process where the information
about the previous status is not used for the future decision and due to this simplicity
of implementation and analysis they are accepted widely [13]. It is observed that with
a small input parameter it produces Brownian motion and therefore basically evaluates
a static network. Brownian movement is a physical phenomena where some quantity
is constantly undergoing small, random fluctuations.
In random walk mobility model nodes move independently to a randomly chosen
directions with randomly selected velocities as shown in Figure 3.4.
Random waypoint is most commonly used in mobile ad hoc networks simulations
is random waypoint and simple for its widespread use in simulations [15]. Nodes
using this mobility model move freely and choose destination and speed arbitrarily.
Each mobile node starts at a random location and stay there for a certain period of time
(pause time) and at the end of the pause time, the node selects a random destination
and moves to the selected destination at a random speed. Figure 3.5 shows an example
of a random waypoint model that starts at (x0, y0) and follows through (x8, y8) and so
on.
3.5 Simulations of Two Mobility Models
In the previous section we proposed a topology-based mobility model, based on tran-
sition probabilities; the exact values for the probabilities, however, were not specified.
28
Figure 3.4: shows an example of a node movement in Random Walk Model.
Figure 3.5: shows an example of a node movement in Random Waypoint Model.
In this section we use a simulator to compute it for two common mobility models, a
random walk model, and a random waypoint model.
The algorithm of the simulator can be found in the Appendix A.1 and A.2.
29
3.5.1 Simulator
The simulator considers a single mobile node in an N × N grid of stationary nodes.
As before, it was assumed a distance of 1 between the nodes on the grid. The initial
position (x0, y0) of the mobile node is determined by a uniform distribution over [0, N
- 1] × [0, N - 1], i.e. x0 ∼⋃
and y0 ∼⋃
[0, N - 1]. Depending on the mobility model
chosen, the simulator then selects a finite number of waypoints (x1, y1) , ..., (xn, yn) ,
and moves along a straight line from waypoint (xi, yi) to the next (xi+1, yi+1).
The random waypoint model uses a uniform distribution over the grid to select the
next waypoint, i.e. for all (xi, yi), xi ∼⋃
[0, N - 1] and yi ∼⋃
[0, N - 1]. The choice
of the next waypoint is independent of the previous waypoint. This model is the most
common model of mobility for network simulators, even if it merits and limitations
have been debated [86]. A consequence of the waypoint selection is that the direction
of movement is not uniformly distributed; nodes tend to move more towards the centre
of the square interval.
As an alternative we are using a simple random walk model. Given waypoint
(xi, yi) the next waypoint is computed as (xi, yi) + (x�, y�), where both xΔ and yΔ are
drawn from a normal distribution N(0, σ). This also means that the Euclidean distance
between waypoints ‖(xΔ,yΔ)‖ has an expected value of σ; σ defines the average step
size in the random walk model. By this definition, the model is unbounded, i.e. the
next waypoint may lie outside of the grid. If this happens the simulator computes the
intersection of the line segment with the grid’s boundary and reflects the waypoint at
that boundary. In the model, the mobile node moves from the first waypoint to the
boundary, and from there to the reflected waypoint. For the purposes of this chapter
the intersections with the boundary do not count as waypoints.
Since the topology-based mobility model introduced in Sect. 4.3 abstracts from
acceleration and speed, these aspects are not included in the simulation either. The
simulator solves algebraically for every line segment from (xi, yi) to (xi+1, yi+1) if it
intersects with a node’s transmission range R (given by a circle with radius R and the
node in its centre). The simulator sorts all the events of nodes entering and leaving
the transmission range, and computes a sequence of sets of neighbours. This sequence
is then used to count occurrences of transitions between these sets that are used to
compute relative transition probabilities.
30
Figure 3.6: shows how a waypoint is reflected when using random walk model.
3.5.2 Simulation Results
The simulator is implemented in C++, and used to generate transition probabilities for
the topology-based mobility model of Section 3.3. The simulator allows also a more
detailed analysis of these two mobility models, in particular how the choice of parame-
ters (grid size, transmission range, and standard deviation of the normal distribution σ)
31
affects the transition probabilities. In this section we discuss some results for scenarios
with a single mobile node on a 5 × 5 grid. For each scenario we considered 1000000
waypoints, which were selected according to the particular model and parameters.
The simulation of the random walk model demonstrate a few important invariants.
One observation is that the transition probabilities do not depend on the size of σ. This
fact is illustrated by Figure 3.6a. The top part of this figure shows the probabilities that
certain nodes are added or deleted from the set {0, 1, 5, 6, 7}. While σ ranges from 18
to 8 the probabilities remain constant.
The bottom part of the figure depicts the frequency with which the set occurs. Here
there is a linear relation between σ and the total number of times that the set is visited.
This is explained by the fact that σ is also the average step size, and doubling it means
that twice as many transitions should be taken along the path.
Another linear relation exists between the total number of transitions along a path
and the transmission range (cf. Figure 3.6b). This relation is explained by the fact
that the length of the boundary of each transmission area is linear to the range. For
σ = 1, and R = 1, approximately 5 transitions will occur between any two waypoints.
The ratio transition/range is constant for an increasing range. Note that this number is
independent of the grid size, and grows linearly with σ.
These invariants do not hold for the random waypoint model. The ratio of transition
to range is not constant, as illustrated in Fig.3.6(b). It is also dependent on the size of
the grid. In a larger grid the distance between waypoints will be larger, and more
transitions occur per waypoint.
For the random walk model we found that the step size σ has no effect on the
actual transition probabilities. The effect of the transmission range on the transition
probabilities is less trivial. Fig. 3.7 shows a few illustrative examples. Similar results
were obtained for all possible sets of neighbours.
Figure 3.7(a) depicts the results for {1, 2, 6, 7, 11, 12}, a set of six nodes that form a
rectangle. This set cannot occur if transmission ranges are smaller than√
52
(cf. Section
3.3). For transmission ranges R ∈[√
52
, 1.25]
the only possible transitions are to delete
one of the four vertices located at the corners of the rectangle. In the random walk
model the probability for these four transitions is 14. Figure 3.7(a) also illustrates that
for transmission ranges R ≥ 1.25, it is possible to add one additional node (either 5 or
8), reaching a set with 7 one-hop neighbours. As the range increases, the probability
of this happening increases. At the same time the probability of deleting a vertex
decreases.
32
Figure 3.7: Selected simulation results of the random walk and the random waypoint
model.
Figure 3.7(b) considers the same set of neighbours as Figure 3.7(a), but under the
random waypoint model. It demonstrates that this model is not locally defined, as
congruent transitions, for example deleting vertices do not have the same probability.
33
The probability also depends of the distance of a node to the centre of the grid.
Figure 3.7(c-f) show the transition probabilities for sets of neighbours that occur
only if R ∈ [1, 1.25]: if R <1, the transmission range is too small to cover the sets
{2, 6, 7, 12} and {1, 5, 6, 7}, respectively; if R >1.25 the transmission range of the
mobile would not consists of more than four nodes only. The observation is that as
the transmission range increases, the probability of deleting a node decreases, while
the probability of adding nodes increases. The sets {2, 6, 7, 12} and {1, 5, 6, 7} have
the same basic ”ᵀ” shape; one is congruent to the other. Hence, for the random walk
model both sets have essentially the same transition probability; but also the frequency
with which the sets occur is the same. This confirms that the position or orientation in
the grid does not matter.
For the random waypoint model this no longer holds. The transition probabilities of
similarly shaped neighbourhoods are not similar, but also determined by the position
relative to the centre: the closer the set is to the centre, the often it occurs in paths.
Note, Figure 3.7(d) and (f) use different scales for the frequency.
To conclude this section, we summarise our findings:
Random Walk Model
• The transition probabilities are independent of σ and the grid size;
• The number of transitions per waypoint path grows linear with the range;
• The transition probabilities of congruent transitions are the same;
• The probabilities depend only locally on the set of nodes within range.
Random Waypoint Model:
None of the above observations hold.
3.6 UPPAAL Model
This section describes an UPPAAL model that implements the topology-based mobil-
ity model described in Section 3.3, and uses the transition probabilities obtained in
34
Gri
dS
ize
[1,1] (1,1.12) (1.12,1.18) (1.18,1.25) (1.25,1.25) (1.25,1.41)
2 x 2 9 9 5 5 5 5
3 x 3 32 41 49 49 37 41
4 x 4 69 97 133 133 101 117
5 x 5 120 177 257 257 197 233
6 x 6 185 281 421 421 325 389
7 x 7 264 409 625 625 485 585
8 x 8 357 561 869 869 677 821
9 x 9 464 737 1153 1153 901 1097
10 x 10 585 937 1477 1477 1157 1413
Table 3.1: Transmission Range: Number of possible topologies, in relation to the range
and the grid size. Results for the point intervals containing√
52
and 56
√2 are omitted.
Section 3.5. The model is not meant to be stand-alone, but meant to be used within
other protocol models. It assumes that an adjacency matrix bool topology [N][N] is
used. The constant N is the size of the grid plus the mobile node. Depending on
whether the random walk or random waypoint model is used, the model makes use of
the grid size and on the transmission range.
The template provides a list of all possible sets of neighbours. Table 3.1 shows the
numbers of possible sets depending on the size of the grid and the transmission range.
The results show that even for relatively large grids the number of possible sets of
neighbours of the mobile node is limited. They will increase the potential state space
only by three order of magnitude. The reachable space may increase by more when
a template for mobility is added, because the protocol might reach more states than it
did for static topologies.
The UPPAAL template of Figure 3.8 implements a lookup table of transition prob-
abilities. After initialisation the template loops through a transition that changes the
topology probabilistically. It contains a clock t, a guard t ≥ minframe and an invari-
ant t ≤ maxframe to ensure that the change happens once in the interval [minframe,
maxframe]. The values of minframe and maxframe determine the frequency of topol-
ogy changes, and hence simulate the speed of a node.
The lookup is implemented by functions updatemapindex, changeprob and changen-
ode. After every topology change, the function updatemapindex maintains the index
(mapindex); this index into the list of possible sets is used to look up transition proba-
35
Figure 3.8: UPPAAL template for the mobility model.
bilities for a smaller set of representative sets of neighbours. Every set of neighbours is
congruent to one of these representative sets. This information is used by changeprob
to look up for a given node i the probability that it will be added or deleted from the
current set of neighbours. Function changenode implements that change.
3.7 Case Studies
In this section we illustrate how the topology-based model can be used in combination
with protocol models: first a brief presentation analysis of AODV routing protocol is
shown, and second a combination of the mobility model with the Lightweight Medium
Control (LMAC). A detailed study of these protocols is out of the scope of this chapter;
we only want to show the applicability and power of the introduced mobility model.
Since we are interested in quantitative properties of the protocols, we are not using
”classical” UPPAAL, but SMC-UPPAAL, the statistical extension of UPPAAL [16].
Statistical Model Checking (SMC) [87] combines ideas of model checking and sim-
ulation with the aim of supporting quantitative analysis as well as addressing the size
barrier that currently prevents useful analysis of large models. SMC trades certainty for
approximation, using Monte Carlo style sampling, and hypothesis testing to interpret
the results. Parameters setting thresholds on the probability of false negatives and on
probabilistic uncertainty can be used to specify the statistical confidence on the result.
For this chapter, we choose a confidence level of 95%.
36
3.7.1 AODV Protocol
AODV routes are only established on demand. If a node S needs to send a data packet
to node D, but currently does not know a route, it buffers the packet and initiates a
route discovery process by broadcasting a route request message in the network. An
intermediate node A that receives this message stores a route to S, and re-broadcasts
the request. This is repeated until the message reaches D, or alternatively a node with
a route to D. In both cases, the node replies to the route request by unicasting a route
reply to the source S, via the previously established route.
An UPPAAL model of AODV is proposed in [32]. The analysis performed on
this model was done for static topologies and for topologies with very few changes.
This limits the scope of the performance analysis. Here, the mobility automaton is
added to the model of AODV. Since the mobility automaton is an almost independent
component, it can be easily integrated into any UPPAAL model.
Our experiments consider scenarios with a single mobile node moving within a
4 × 4 grid. A data packet destined for a randomly chosen stationary node is injected
at a different stationary node. During route discovery the mobile node will receive and
forward route requests and replies, as any other node will do.
The experiment determines the probability that the originator of the route request
learns a route to the destination within 2000 time units. This time bound is chosen as
a conservative upper bound to ensure that the analyser explores paths to a depth where
the protocol is guaranteed to have terminated. In (SMC)-UPPAAL syntax this property
can be expressed as:
Pr[<=2000](<>node(OIP).rt[DIP.nhop!=0])
The variable node(OIP).rt denotes the routing table of the originator OIP, and
the field node(OIP).rt[DIP].nhop represents the next hop on the stored route to the
destination DIP. In case it is not 0, a route to DIP was successfully established. The
property was analysed for the random walk and the random waypoint model with three
different transmission ranges R: 1.1, 1.2, and 1.3. SMC-UPPAAL returns a probability
interval for the property (1), as well as a histogram of the probabilities of the runtime
needed until the property is satisfied.
The results are presented in Figure 3.9. The legend continues, besides the name of
the model, the probability interval. For example, the random walk model with R = 1.1
satisfies property (1) with a probability P ∈ [0.84, 0.94]. In contrast to that the prob-
ability of route establishment in a scenario without a mobile node is [0.95, 1], which
37
Figure 3.9: AODV: probability of packet delivery within a certain time.
indicates that the property is always satisfied. The probability intervals show that all
scenarios with a mobile node have a lower probability for route discovery, some dra-
matically so. The random waypoint model with R = 1.2 has a probability interval of
[0038, 0.48], which means that more than half of all route discovery processes fail. It
is also notable that the random walk models have better results than the corresponding
38
random waypoint models. Finally, the mobility models with R = 1.1 have a signifi-
cantly higher probability to succeed than the other four models with R = 1.2 and R =
1.3.
The histograms show another interesting finding. The time it takes for a route
reply to be delivered, if it is delivered, can be shorter for the models with the mobile
node. Apparently, the mobile node can function as a messenger between originator and
destination; not just by forwarding messages, but also by physically creating shortcuts.
For further discussion of when and why AODV route discovery can fail see [32, 46].
3.7.2 The Lightweight Medium Access Control (LMAC) Protocol
LMAC [80] is a lightweight time division medium access protocol designed for sensor
networks to schedule communication, and targeted for distributed self configuration,
collision avoidance and energy efficiency. It assumes that time is divided into frames
with a fixed number of time slots. The purpose of LMAC is to assign to every node a
time slot different from its one-and two-hop neighbours. If it fails to do so, collisions
may occur, i.e., a node receives messages from two neighbours at the same time. How-
ever, LMAC contains a mechanism to detect collisions and reports them to the nodes
involved, such that they choose (probabilistically) a new time slot.
A (non-probabilistic) UPPAAL model for LMAC was developed in [34], where it
was also used to study static topologies. Based on this model a probabilistic model
was developed [80]. This model was then used to study the performance of LMAC
for heuristically generated topologies with 10 nodes [16]. The model we use differs
in one aspect from [16]: it uses a smaller frame, with only six time slots, rather than
20. The purpose of LMAC is to assign time slots such that collisions are avoided or
resolved, even if the number of time slots is restricted. For a 3 × 3 grid, it is possible
to find a suitable assignment with only five time slots; six time slots should therefore
be sufficient to cover a network with 10 node (one mobile node), although it might be
challenging.
We check the following two properties:
Pr[<=2000](<> forall (i: int[0,9]slot\_no[i]>=0) (2)
Pr[collisions <= 2000](<> time>=2000) (3)
The first property holds if, at some time point (before time 2000), all nodes are able
to select a time slot. While this does not guarantee the absence of collisions, it does
39
Figure 3.10: LMAC: number of collisions within 2000 time units.
guarantee that all nodes have been able to participate in the protocol. The second
property checks whether it is possible to reach 2000 time units, with less than 2000
collisions. This property is true for all runs. It is used merely to obtain a histogram of
the number of collisions.
The results are illustrated in the histogram of Figure 3.10 for all models with a
mobile node, the property (2) is satisfied (the probability interval is [0.95,1], by a
confidence level of 95%). The detailed results show that all runs reach a state in which
all nodes have chosen a time slot. For the model without a mobile node, the probability
interval is [0.80,0.90]. This means that in at least 10% of all cases LMAC is not able to
assign a time slot to all nodes; the histogram shows runs with 80-90, 160-170, and 240-
250 collisions. These are runs in which one, or more nodes are engaged in a perpetual
collision. Interestingly, this type of perpetual collisions do not occur in models with
a mobile node. The mobile node functions as an arbiter, which, as it moves around,
detects and reports collisions that static nodes could not resolve.
The histograms reveal a few other interesting findings. In the model without mo-
bility about 40% of the runs have no collisions. For both mobility models with trans-
40
mission range R=1.1 this drops to about 30%. For larger transmission ranges this drops
even further to close to 0%, which means that almost all runs have at least some col-
lisions. The differences between range R=1.1, R=1.2 and R=1.3 is explained by the
fact that the mobile node for R=1.1 will have at most 5 neighbours, while for R=1.3 it
may be 7 neighbours. A larger neighbourhood makes choosing a good time slot more
difficult. This is confirmed by another observation, namely that for R=1.1 only a few
runs have more than 20 collisions (approximately 12% of the runs, both random walk
and random waypoint), while for a range of 1.2 and 1.3 it is in the range from 25% to
45%.
Both case studies show that introducing mobility can change the behaviour of net-
work protocols significantly. As mentioned above, the purpose of these case studies
was not to analyse these protocols in detail, but to show that the topology-based mobil-
ity models can be used to improve the scope of performance analyses of such protocols.
3.8 Summary
In this chapter, we have proposed an abstract, reusable, topology-based mobility model
for wireless networks. The model abstracts from all physical aspects of a node as well
as from time, and hence results in a simple probabilistic model. To choose a right
level of abstraction, we have studied possible transitions and configurations of network
topologies.
To determine realistic transition probabilities regarding existing mobility models,
we have performed simulation-based experiments. In particular, we have distilled
probabilities for the random walk and the random waypoint model (using different
transition ranges). We have then combined the topology-based model with the dis-
tilled probabilities and have created a (SMC-)UPPAAL model. The generated model
is small and can easily be combined with other UPPAAL models specifying arbitrary
protocols. To illustrate this claim we have combined our model with a model of AODV
and LMAC, respectively. By this we were able to demonstrate that topology-based
mobility models can be used to improve the scope of performance analysis of such
protocols.
41
Chapter 4
Modelling, Verification, and
Comparative Performance Analysis of
the B.A.T.M.A.N. Protocol
4.1 Introduction
This chapter considers on a network routing protocol known as Better Approach to
Mobile Ad hoc Networks (B.A.T.M.A.N.). The protocol serves two aims: first, to
discover all bidirectional links, and second, to identify the best-next-hop for every
other node in the network. A key element is that each node will flood the network at
regular intervals with so-called originator messages.
A full description and formalisation of the B.A.T.M.A.N. protocol is given. This
exercise revealed several ambiguities and inconsistencies in the internet draft. We de-
veloped two models. The first implements, if possible, a literal reading of the internet
draft, while the second model tries to be closer to the underlying concepts. The alterna-
tive model is in some places less restrictive, and rebroadcasts more often when it helps
route discovery, and will on the other hand drop more messages that might interfere
with the process.
We verify for a basic untimed model that both interpretations ensure loop-freedom,
bidirectional link discovery, and route-discovery. We use simulation of a timed model
to compare the performance and found that both models are comparable when it comes
to the time and number of messages needed for discovering routes. However, the
alternative model identifies a significantly lower number of suboptimal routes, and
thus improves on the literal interpretation of the internet draft.
Since the introduction of wireless mobile ad hoc networks, many protocols have
been used for making communication efficient and by finding the best possible routes
from source to destination. The German Freifunk community developed the network
routing protocol known as Better Approach to Mobile Adhoc Network B.A.T.M.A.N.
42
as an alternative to OLSR. B.A.T.M.A.N. is a proactive protocol, for detecting all bidi-
rectional links and identifying the best-next-hop for all other nodes. The protocol is
table driven and maintains route information and updates by keeping information on
received originator messages in a so-called sliding window. A node records how many
messages from another node with a sequence number in a given range of recent se-
quence numbers were received via which neighbour.
This chapter describes a model based on the internet draft [69]. During the im-
plementation of the protocol as an UPPAAL model it turned out that a number of
conditions were not unambiguously defined in the context of looping sequence num-
ber and a limited local view of a node. The formalisation will define those terms. The
internet draft also contained a few conditions that were inconsistent. To address this we
developed two models: The literal interpretation of the internet draft implements the
protocol with a reading that is as close as possible to the text of the internet draft. The
alternative interpretation resolves inconsistencies in light of the underlying concepts
of B.A.T.M.A.N.. For example, a literal reading of the description will exclude certain
messages from being recorded in the sliding window, while the general description of
the sliding window suggests that those messages should be recorded.
For both interpretations we verify a few basic properties for an untimed model and
a small four node topology. This is mostly meant to help with debugging the models,
and ensure e.g. that the bidirectional link check works as expected. This analysis show
that both, the literal and alternative model, meet this minimum standard. We then use a
timed model in a 17 node network to analyse the performance, in particular the quality
of the chosen best-next-hops. These are sometimes suboptimal and actually not the
best next hop. This analysis shows that the alternative model reduces the occurrences
of suboptimal best-next-hops.
The performance of B.A.T.M.A.N. in comparison to OLSR has been analysed in
a real environment in [56, 83]. A simulation of a real environment has been used to
analyse B.A.T.M.A.N. in [42, 6]. Furlan simulated the performance of B.A.T.M.A.N.
for a selected type of network topologies [35]. These studies consider a particular
implementation with specific hardware in a specific environment and do not analyse
the routing algorithm in isolation. A formal analysis of B.A.T.M.A.N. was conducted
by Cigno and Furlan in [21]. This analysis discovered that routing loops are possible,
and proposed improvements that ensure loop freedom. This work was complemented
by simulation studies and real measurements. While this work does not use model
checking per se, it presents a formal model to study routing loops. In comparison,
43
this chapter presents a formal UPPAAL model, and uses verification and simulation to
study the quality of route discovery. UPPAAL has been used perviously to study other
protocols, such as LUNAR, OLSR, AODV, DYMO, and LMAC [16, 31, 32, 51, 84]
The next section describes the B.A.T.M.A.N. routing protocol and in particular the
sliding window. Section 4.3 introduces the common data structures, Section 4.4 and
4.5, the handling and processing of OGMs. These section give rise to the two alterative
models. Section 4.6 and 4.7 describe the templates and the verification and simulation
results, respectively.
4.2 The B.A.T.M.A.N. Protocol
The major objective of a network routing protocol is to discover routes available in
a network. An active user group known as the German Freifunk community has
been involved in the development of a network routing protocol known as Better Ap-
proach to Mobile Adhoc Network [69]. The internet draft abbreviates the protocol as
B.A.T.M.A.N., including the dots. The protocol is meant as an alternative to OLSR
(Optimised Link State Routing Protocol), a proactive wireless routing protocol widely
used in mobile ad hoc networks [23]. Instead of having each node compute routing ta-
bles that capture the complete network topology as OLSR does, B.A.T.M.A.N. nodes
maintain only information on the neighbouring nodes. This information is used to
identify the best-next-hop [47]. It is then a desired property of B.A.T.M.A.N. that the
best-next-hop will indeed realise the best route.
To maintain a fresh list of available neighbours, and to deal with changing topolo-
gies, a B.A.T.M.A.N. node will send an originator message (OGM) at regular inter-
vals. The OGMs are forwarded under certain circumstances to neighbouring nodes, in
an effort to correctly identify all available bi-directional links. Once they have been
established a node selects a neighbour as next-best-hop to a destination, based on the
number of OGMs from that destination that have passed through that neighbour within
a given time frame, called the sliding window. Since the protocol drives on OGM
flooding the network, it is phrased in term of the origin of the OGMs. Once routes
have established along bi-directional links, these originators will be the destination for
packets to be send.
The phases of finding bidirectional links and finding the best-next-hop are however
not clear divided. They may overlap for different nodes, and nodes will iterate through
these phases continually, as the sliding window moves, and bidirectional links expire.
44
Figure 4.1: Routing table for A before and after processing two OGMs from originators
B and C.
Example Figure 4.1 gives an example of routing table for node A in for a small
network with four nodes. The bidirectional sequence number for originator B is in this
example is 14, and the last TTL is 8. The sliding window for originator B encompasses
sequence numbers 13 to 1. Within the window, A received an OGM from originator B,
three times from Node B, twice from Node C and twice from Node D. This means that
Node B is currently the best-next-hop for Node B.
Similarly we have for originator C – according to this example – that both Node
B and Node C have rebroadcasted three times an OGM from C within the window, and
Node D only once. This means that both B and C are considered to be the best-next-hop
for originator C.
Suppose that Node A will receive an OGM rebroadcasted by Node B, with OID A,
sequence number 2, and the direct-link-flag set to true. In this case the OGM
is a echo of an OGM node A sent itself. From this follows that there exists a bidirectional
link. The bidirectional link sequence number (BD SQN) for OID B will be changed
45
to 2.
Suppose further that A receives an OGM, rebroadcasted by Node D, with OID C,
and sequence number 12. The range of the sliding window for C was sequence number
6 to 10. After reception, the range of the sliding window will be 8 to 12. Data of
sequence numbers 6 and 7 will be dropped, and D will be recorded as having sent an
OGM with sequence number 12. After this update node B will have rebroadcasted 3 out
the last 5 OGMs, Node C one, and Node D two. Node B will be the presumed best-next-
hop for originator C. See Figure 4.1 for the new routing table after these updates.
4.3 Data Structures and Constants
This section describes the common data structures and variables used by of the differ-
ent UPPAAL model. The subsequent section will describe the processes and conditions
for handling OGMs.
Constant are the number of nodes N, the maximum sequence number MAX SQN,
the initial TTL TTL MAX, and the size of the sliding window WINDOW SIZE. We
considered models with up to 25 nodes, a maximum sequence number of 15, an initial
TTL of up to 10, and a window size between 2 and 8. The maximum sequence number
of 15 is a lot smaller than the recommended value of 216 − 1(= 65535). The reason is
that we want to analyse the behaviour of the sliding window, including the behaviour
when sequence number loops.
Datatypes have been defined for sequence numbers, node IDs, TTLs, and in-
dices into arrays of the sliding window. Node IDs take values from 0 to N − 1, and
we reserve the node ID −1 for an invalid ID; it is used as padding where we had to use
fixed sized arrays to implement variable sized buffers.
The datatype OGM in Table 1 is used for the OGMs. Nodes communicate by writing
an OGM to a shared global variable ogmglobal, and synchronizing on a channel
from broadcast chan SendOGM[N]. Each node maintains a buffer of received,
but not yet processed OGMs, ogmlocal, which is implemented as a fixed array of
type OGM. The next OGM to be processed is ogmlocal[0]. The size of this buffer
is chosen such to avoid buffer overflow – we use values up to 64. A node increment
counter buffererror if a buffer overflow occurs.
Each node maintains an array table of size N of type OriginatorInfo. Each
entry contains the bidirectional sequence number biDirectionalSqn, i.e. the
last sequence number received from the originator sqn, the time-to-live ttl, and
46
Table 1 Datatype definitions for OGMs and routing table entries.
typedef struct {
anyIdT oid;
anyIdT sid;
ttlT ttl;
sqnT sqn;
bool isDirect;
bool isUnidirectional;
} OGM;
typedef struct {
bool entries[WINDOW_SIZE];
} SlidingWindow;
typedef struct {
sqnT biDirectionalSqn;
sqnT sqn;
ttlT ttl;
SlidingWindow window[N];
} OriginatorInfo;
the sliding window window. The latter is an array with an boolean array of size
WINDOW SIZE for each node in the network. The last element in this array, refers to
sequence number sqn, the second last element to sqn-1, etc. The model includes a
number of functions to update the window for a given oid consistently, for example
to move the entries, when the sequence increases. Of course this takes into account
that the sequence number may loop.
4.4 Handling of Originator Messages
This subsection gives a detailed account of how the model relates to the B.A.T.M.A.N.
internet draft. A key to model the B.A.T.M.A.N. protocol, is to faithfully represent
Section 5.2 of the internet draft. It describes how to classify different types of OGMs.
This chapter uses the numbering scheme from the internet draft to refer to these rules.
Rule 5.2.1 This rule states to drop OGMs sent with a different version of the protocol.
It is not included in the model, since we assume that all nodes run the same version.
Rule 5.2.2 This rule states to drop OGMs a node receives from its own transmitter.
Since the automaton modelling a node cannot synchronise with itself, this scenario is
excluded by the semantics of synchronisation in UPPAAL. Note, this rule has nothing
to do with dropping messages that are a rebroadcast of a message that has been sent
earlier by this node. That is dealt with elsewhere.
47
Rule 5.2.3 This rule deals with nodes that have multiple transmission interfaces. It is
not included, since the model only considers nodes with a single interface.
Rule 5.2.4 This rule deals with the bidirectional-link check. It is modeled by boolean
function bool meetsRule5 2 4(OGM ogm). It returns true if the OGM.oid is
equals to the nodes own ID. In this case the bidirectional link information may have to
be updated, as described in the next section.
Rule 5.2.5 This rule deals also with the bidirectional-link check. The OGM is dropped
if the unidirectional-link flag ogm.isUnidirectional is set. This rule is mod-
elled by boolean function boolmeetsRule5 2 5(OGM ogm).
Rule 5.2.6 This rule determines which OGMs should be used to update the sliding
window. This update is referred to as Process 5.4, and will be explained later. Rule
5.2.6 states to invoke Process 5.4 if the OGM is received via a bidirectional link and
contains, as the internet draft state a ”New Sequence Number (is NOT a duplicate)”.
This apparently simple statement requires some interpretation, since the internet
draft does not define how to determine whether a sequence number is new. The model
has to assume a local view on the network, and cannot refer to a global notion of
duplicate or new. We also have to take into account that sequence numbers may loop,
and that OGMs may not arrive in the order they have been created.
Given an OGM from originator ogm.oid and sequence number ogm.sqn, and
the most recently recorded sequence number table[oid].sqn. We modeled ”new
sequence number” to mean that the value of ogm.sqn is between the:
table[ogm.oid].sqn and table[ogm.oid].sqn plus half of the range of
the sequence numbers, modulo the range.
The comment ”NOT a duplicate” in brackets, might seem like a clarification, but
complicates things further. Being not a duplicate is not necessarily the same as having
a new sequence number. Within the context of the sliding window, a message with a
sequence number in the range of the sliding window is not a duplicate, if for the same
ogm.oid no OGM from the same sender ogm.sid with same sequence number
ogm.sqn was received. These OGMs are not duplicates, but also not newer.
Recall that this rule is the precondition for Process 5.4. This process however
48
clearly states that it should only use OGMs with a newer sequence number. It does not
mention duplicates.
We decided to create two different model that explore the different alternatives.
The first model applies a literal interpretation, i.e. Rule 5.2.6 only applies if an OGM
has a newer sequence number. This model implements the condition that was explicitly
stated in the description of Process 5.4.
This interpretation, however seems to undermine the purpose of the sliding win-
dow, namely to collect information on OGMs with sequence numbers in the range of
the sliding window. The alternative interpretation of Rules 5.2.6 is to consider OGMs
with a newer sequence number, or OGMs that are in range but not duplicates.
This rule is modelled by boolean function bool meetsRule5 2 5(OGM ogm).
Rule 5.2.7 This rule deals with which OGMs will be rebroadcasted. Before rebroadcast
it has to execute Process 5.5 which will be described later. The first set of OGMs that
have to be rebroadcasted, are those that have been received from a single hop neigh-
bour, i.e. for which ogm.oid equals ogm.sid. This includes, but not exclusively,
the OGMs that take part in the bidirectional link check.
In addition OGMs that satisfy the following will be rebroadcasted according to the
internet draft:
The OGM was received via a Bidirectional link AND via the Best Link
AND is either not a duplicate or has the same TTL as the last packet which
was not a duplicate (last TTL).
The ”bidirectional link” is the link between the receiving node and the sender of
the OGM, ogm.sid. The specific condition for whether a node considers a link to be
bidirectional will be discussed later.
To be the ”Best Link” means that the sender ogm.sid is a best-next-hop for orig-
inator ogm.oid. This decision is based on the sliding window. We will discuss later
how to determine whether a node is a best-next-hop.
To determine whether an OGM is a duplicate we use the same interpretation as for
Rule 5.2.6. The sequence number is newer, or in range, and no OGM with the same
ogm.sid, ogm.oid, and ogm.sqn has been received previously.
The last TTL is the value of table[oid].ttl. The short summary here does
not quite align with the description later in the internet draft that describes Process 5.5.
We will discuss this in the next section. Also, while it is not explicitly mentioned in the
49
internet draft, the condition on the TTL can only be reasonably applied if the sequence
number of OGM is in range. OGMs that are neither newer, nor in range should be
dropped regardless of the TTL.
Note furthermore that this only tests for equality of the TTL of the OGM, with the
last TTL. It disregards OGMs with an improved TTL, i.e. OGMs that arrived via a
shorter route. This seems to contradict the purpose of the sliding window, namely to
collect information to determine the best hops, and thus the best route. In contrast, the
condition that the OGM should not be a duplicate does not consider the TTL at all. It
means that OGMs will be rebroadcasted that are not a duplicates but have lower TTLs,
i.e. OGMs that arrived via longer route.
Also here we decided to consider the alternatives. Both interpretations require that
the link to the sender is bidirectional and received via a best-next-hop. The literal
interpretation will require in addition that the sequence number is newer, or the OGM is
in range but not a duplicate, or in range and that its TTL equals the last TTL.
The alternative interpretation requires that the OGM is newer, or that the OGM is in
range, not a duplicate and also has TTL that is equal or better than the last TTL.
Finally, recall that Rule 5.2.7 is a precondition for Process 5.5. The description of
this process requires explicitly that the TTL is at least 2. If the TTL is otherwise 1 the
OGM should be dropped instead of being rebroadcasted. We include this in Rule 5.2.7.
This complete rule is modelled by boolean function bool meetsRule5 2 7(OGM
ogm).
It should be noted that these rules, in particular Rule 5.2.6 and Rule 5.2.7, are not
mutually exclusive. Either of those rules may apply to an OGM or both. The internet
draft does not specify explicitly what to if the latter is the case. To ensure correct
computation of the best-next-hop it is necessary that OGMs that satisfy both rules, are
used to update the sliding window, and are rebroadcasted.
It should also be noted that these rules are not complete; there can be OGMs to
which none of these rules apply. The internet draft does not mention explicitly what to
do; it appears that these OGMs have to be silently dropped.
4.5 Processing of Originator Messages
The internet draft describes three procedures to process OGMs, one for the bidirectional-
link-check, one to update the neighbour ranking, and the last one to update an OGM
before rebroadcast.
50
Process 5.3: Bidirectional Link Check This process checks if an OGM is a recent
self-originating message, i.e. if ogm.oid is its own ID, the ogm.isDirect flag
set, and the sequence number ogm.sqn equal to its current number sqnNode. If so
it stores ogm.sqn in table[oid].biDirectionalSqn.
The description of Process 5.3 also defines when a link is considered bidirectional: if
the difference between the current sequence number sqnNode and the stored
table[oid].biDirectionalSqn is less than some threshold
BI LINK TIMEOUT. Unfortunately, the internet draft does not specify values for
BI LINK TIMEOUT; for the model we use values between 2 and 10 (half the size
of the sliding window, and up to twice its size).
Process 5.4: Neighbour Ranking This process updates the sliding window. The
update adds a new entry for sequence number ogm.sqn and originator ogm.oid.
If the sequence number ogm.sqn is newer than the last recorded sequence num-
ber table[oid].sqn, the sliding window will be shifted before that update. This
means that the oldest entries will be deleted and new entries up to sequence number
ogm.sqn added.
Note, that this process also defines a condition for updating the sliding window,
even though Rule 5.2.6 serves the same purpose. However, these rules are not the same.
Here the precondition is that an OGM has a newer sequence number. As mentioned
before, the literal model uses this condition as Rule 5.2.6. The alternative model relies
on the alternative interpretation of Rule 5.2.6.
Note further, that the internet draft mentions that the packet count must be updated.
However, a packet count has not been introduced nor used elsewhere in the internet
draft. We assume that it is used as synonym for the neighbour ranking based on the
sliding window.
Finally, the internet draft states that each node has to nominate one node from the
set of nodes with the most OGMs in range to be the unique best-next-hop. This is
how we implemented it for the literal model. In the alternative, we leave this choice
open; if two or more nodes happen to have the same ranking, they all be considered a
next-best-hop.
Process 5.5: Rebroadcasting An OGM has to be rebroadcasted when it satisfies Rule
5.2.7. Before rebroadcast the following fields of the OGM will be changed:
• The TTL ogm.ttl has to be decremented by one.
51
• If the sender is equal to the originator, i.e. if ogm.sid equals ogm.oid, then
the isDirect flag will be set to true. This allows the originator - a direct
neighbour - to distinguish between OGMs that were received directly from that
neighbour, or via a detour. Note, that the internet draft also mentions as require-
ment that the OGM will sent the OGM back to the sender/originator. Since our
model uses a only broadcast, this is satisfied by default.
• The isUniDirectional flag has to be set to true, if the link to the sender
ogm.sid does not satisfy the bidirectional-link requirement.
Note furthermore, that the internet draft mentions that OGMs with a TTL of 1 (or
0 after decrementing) have to be dropped. In the model we incorporated this in Rule
5.2.7, which effectively drops the message.
4.6 Untimed Model
The untimed model serves to assure that the bidirectional link check works, and that
routes are discovered, and whether routes are loop-free for a static topology. It uses a
same template for each node id.
The template has only two control locations. The first, is a committed initial lo-
cation, the second, labelled Processing, models normal processing of OGMs. The
edge from the initial location to location processing initialises the sliding windows
and other local variables.
From location Processing there are 8 self loops. They model sending and re-
ceiving of OGMs, and the processing of the OGMs:
• An edge that synchronises on channel SendOGM[oid]!. This transaction cre-
ates an OGM, and copies it to the shared global variable ogmGlobal.
• An edge that synchronises on channel SendOGM[sid]?, where sid is a valid
sender ID. The guard topology[sid] ensures that sender and receiver are
connected. This transaction calls a function receiveOGM(), which copies
the OGM from global variable ogmGlobal, and appends it to the local buffer
ogmLocal unless it satisfies Rule 5.2.5.
• Five edges that model the processing of OGMs in the buffer. One for when Rule
5.2.4 applies, one for when Rule 5.2.6 applies but not Rule 5.2.7, one for when
Rule 5.2.7 applies but not Rule 5.2.6, one for when both apply, and one for when
52
Figure 4.2: Timed model for simulation.
the buffer is not empty, and neither rule applies. If Rule 5.2.7 applies, the edge
will synchronise on channel SendOGM[oid]!, i.e. it forwards an OGM. All
others are labelled with broadcast channel tau[id]. These edges model a local
update of the routing information. The label allows us to give those transition
a higher priority – to reduce the number of states – while it will not affect the
routes that will be discovered.
The model contains a few auxiliary functions to add and remove OGMs to the
buffer, to manage the sliding window, and to process the OGMs. It also includes a num-
ber of function that are used to specify properties, e.g. bool hasLoop() which is
used to check for loop freedom, or function int countBidirectionalMisses()
which counts how many bidirectional links still need to be discovered.
53
Verification Results For the verification we limit ourself to a model with four nodes
in a ring. Each node sends one OGM, and node 0 a second one. For this we check the
following:
• A[] !hasloop(). Whether the routes have loops.
• A[] (forall(id:validIdT) Node(id).OGMremain==0 &&
sumBuffer() ==0 )
imply countBidirectionalMisses() == 0
This checks that once all OGMs have been sent and processed each node other
than 0 have discovered a route all bidirectional links have been discovered (no
misses).
• A[] ((forall(id:validIdT) Node(id).OGMremain==0&&
sumBuffer() ==0 )
imply(forall(id:validIdT)(id==0 || Node(id).table[0]
.bestNext>-1))
This checks that once all OGMs have been sent and processed, each node other
than 0 have discovered a route to node 0.
The model satisfies all of these. It should be noted that we show absence of loops
for a small static network with only 4 nodes. In general, sequence number based
protocols have been shown to not to be loop free [79], and [21] presents a specific
scenario for B.A.T.M.A.N. with a changing topology.
The literal and alternative models behave are except for the implementation of the
functions implementing Rule 5.2.4 to Rule 5.2.7 and Processes 5.3 to Process 5.5, as
discussed previously. There is only one notable difference in the data structure for
the routing table. The literal model also includes a field table[oid].nextBest,
since the literal interpretation requires a unique best-next hop for each originator.
Verification was performed on an Intel i5-5200 CPU 2.2Ghz processor with 8 GB
RAM running UPPAAL 4.1.19. Verification of these properties took 19 seconds for
either model. Verifying these same properties for a 5 node network, with one extra
central node, runs out of memory after about 600 seconds.
4.7 Timed Models
The timed model is used to use simulation to analyse and compare the performance of
the two versions of the protocol; in particular how quickly the bi-directional link check
54
occurs, how quickly routes are discovered, and the quality of the routes.
The timed models uses the same data-structures and functions as the untimed
model, but they attach time bounds on when events can occur. The model uses clock
ogmTime to ensure that any node sends an OGM once between MIN OGMTIME and
MAX OGMTIME. The transition that model creation and sending of new OGMs includes
guard:
ogmTime>=MIN OGMTIME, and all control location invariant
ogmTime<=MAX OGMTIME.
The model uses clock responseTime to ensure that a node rebroadcasts within
MAX RESPONSE time units, while there is an OGM in the buffer. The model in-
cludes two control locations, Empty for when the buffer is empty, Processing for
when the node processes OGMs. In the latter location there is the additional invariant
responseTime <=MAX RESPONSE.
All other transitions model internal updates and are labelled with urgent broadcast
channel tau[id]!. This means these transition are taken as soon as they are enabled.
See Figure 5.3 for a depiction of node template.
The model also includes a number of auxiliary functions to support analysis of
the performance by simulation, such as function countRouteMismatch() which
counts how many ”best-next-hops” are actually suboptimal.
Simulation Results For the simulation we consider a 4× 4 grid, plus one additional
node in the center. The one additional node is connected to the four central nodes of
the grid. The purpose of the central node is to introduce some irregularity. In a grid the
difference between an optimal and a suboptimal route is at least two hops. With the
central node added the difference will be only one hop for at least some connections.
This will increase the chances that suboptimal routes will be observed.
The model furthermore assumes that processing of OGMs takes at most 1 time
unit. New OGMs are created once between 19 and 20 time units. The buffer for each
node has maximum size 64. For these setting we ran a simulation of 100 runs up to
time 255, which means it considers 12 rounds of OGMs being sent and processed. The
results are depicted in Figure 4.3. Simulation of one run takes about 320 seconds for
the literal model, and 330 second for the alternative model. The presented results are
for 100 simulations each.
The number of undetected bidirectional links drops to zero after the first round
of OGMs have been sent. There is no significant difference between the literal and
55
Figure 4.3: Simulation results. The results are averages over 100 runs, except for the
maximum buffer size, which is the maximum over 100 runs.
alternative model, as the changes do not affect the bidirectional link check.
The results for the number of routes for which no ”Best-next-hop” declines within
6 rounds to zero. This corresponds to the 6 hops of longest route in a 4 × 4 grid; from
the one corner to the diagonally opposite corner. There is no significant difference
between the two models in this respect.
There is a noticeable change with respect to the number of potential best-next-hops.
The literal model selects a designated best-next-hop. This has consequences further on,
since a node only forwards OGMs that were received via a best-next-hop. The literal
model will rebroadcast only OGM received via the designated best-next-hop. The
alternative will rebroadcast OGMs received by any best-next-hop.
This has further consequences when we consider the number of route errors. These
are nodes that have been identified as best-next-hop, while they are not. In the literal
model the number of routing errors at time 250, when the 12th round of OGMs has
been processed, is 2.5. In the alternative model this value is only 0.22. It appears
85% of all simulations of the literal model have at least one routing error at time 250,
while this is true for only 17% of all runs in the alternative model. Since the alterna-
tive message rebroadcasts more OGMs from more best-next-hops, the chances that a
suboptimal route wins the neighbour ranking is greatly diminished.
56
It should also be seen in light that a suboptimal ”best-next-hop” in the literal model
is the designated ”best-next-hop”. If it is suboptimal all routes will be suboptimal.
In the alternative model, all potential best-next-hops are identified. Even if some are
suboptimal, there will be optimal alternatives that have been identified as well.
The number of 2.5 route errors seems small, but for many routes there is no sub-
optimal ”best-next-hop”. For example, any route from the top left node to any node in
the bottom right half of the grid, will pass through either of the two neighbours of the
top left node. Both neighbours are optimal choices.
The changes in the alternative model suggest that there may be some overhead since
it sends more OGMs from more best-next-hops. On the other hand, the alternative
model will only rebroadcast duplicates if they improve on the TTL, unlike the literal
model. We see that the maximum over 100 runs, rises for both models up to 45 OGMs
in the buffer. Over all 255 time units the average number of OGMs in the buffer of a
node in the literal model is 1.7, while it is 2.0 for the alternative model. It appears that
the alternative model introduces a noticeable, but small overhead.
4.8 Summary
This chapter modelled on a network routing protocol known as Better Approach to
Mobile Ad hoc Networks (B.A.T.M.A.N.). The formalisation of the protocol revealed
several ambiguities and inconsistencies in the internet draft. We developed two models,
one implementing a literal reading of the internet draft, the second model closer to
the underlying concepts. The literal model for example implemented the requirement
that there can only be one best-next-hop, whereas the alternative model relaxed the
condition to include all nodes with the same ranking. On the other hand, the alternative
model does rebroadcast fewer OGMs with a suboptimal TTL, i.e. OGMs that arrived
via suboptimal routes.
For a basic model we showed that both interpretations ensure loop-freedom, bidi-
rectional link discovery, and route-discovery. This served mostly to debug the model.
We then use simulation of a timed model to compare the performance of the literal
and alternative model, and found that the alternative model identifies a significantly
lower number of suboptimal routes, and thus improves on the literal interpretation of
the internet draft.
Future work should consider mobility in networks and check whether we can ob-
serve route discovery failures as has been predicted by Cigno and Furlan. It would be
57
interesting to see how the proposed alternative could be combined by suggestion for
improvements made by these authors and others.
In general, the process of formalisation has shown that it is important for an internet
draft to define all concept, even those that seem obvious, such as ”newer sequence
number”. It also shows that the internet draft should clearly distinguish between the
preconditions – Rule 5.4 to Rule 5.7 in this chapter – and the processes itself. If a
process formulates those conditions again, even if it is only meant as a clarification, it
can be a source of inconsistencies and ambiguities.
58
Chapter 5
An Even Better Approach – Improving
the B.A.T.M.A.N. Protocol Through
Formal Modelling and Analysis
5.1 Introduction
Previous work formalised the B.A.T.M.A.N. protocol in UPPAAL and found several
ambiguities and inconsistencies [20]. More importantly, specific choices in the inter-
net draft had, unfortunately, a negative impact on route discovery, as well as a few
explicit choices that had a negative impact on the route discovery process. In Chapter
4, a literal model based on the internet draft was compared with an incremental im-
provement. Performance is compared using simulations in UPPAAL, for static as well
as dynamic topologies. The analysis shows that the new implementation reduces the
number of suboptimal routes significantly, and recovers better from routing errors that
are introduced by mobility.
As stated in Chapter 4, The German ”Freifunk” community developed B.A.T.M.A.N.
as an alternative to OLSR. B.A.T.M.A.N. is a proactive protocol for detecting bidirec-
tional links and identifying the best-next-hop to all other nodes. Each node floods the
network at regular intervals with so-called originator messages and records informa-
tion on received originator messages in a so-called sliding window.
Previous work done in Chapter 4 revealed that the internet draft [69] contained sev-
eral ambiguities and inconsistencies, as well as a few explicit choices that had a nega-
tive impact on the route discovery process. The analysis in [20] used model checking
and simulation of a static network to investigate occurrence of suboptimal routes.
This chapter goes one step further and proposes an alternative that departs from the
internet draft. It proposes a new sliding window that stores the time-to-live values of
received messages. This information is then used to identify the best-next-hop. The
alternative model (1) redefines the ”best-next-hop” to also include alternative routes,
59
(2) update the sliding window if it finds a better routes, (3) forwards only messages that
are evidence of improved routes, and (4) only compares the time-to-live of messages
that have the same sequence number. The model in [20] only addressed the first point
fully, the next two partially, and the last one not at all. The analysis in [20] considered
only static topologies, while this chapter also analyses the performance in the presence
of a mobile node.
The performance of B.A.T.M.A.N. has been analysed in a real environment in [56]
and [83]. A simulation of a real environment has been used to analyse B.A.T.M.A.N.
in [42] and [61]. Furlan simulated the performance of B.A.T.M.A.N. for a selected
type of network topologies [35]. These studies have in common that they consider a
particular implementation with specific hardware in a specific environment and do not
analyse the routing algorithm in isolation. This chapter instead uses a formal timed
automaton model of the protocol and its proposed alternative. This allows to study
the protocol in isolation, including non-deterministic timing, interleaving of message
processing in concurrent nodes, and a probabilistic model of mobility.
A formal analysis of B.A.T.M.A.N. was conducted by Cigno and Furlan in [21].
This analysis discovered that routing loops are possible, and proposed improvements
that ensure loop freedom. This work was complemented by simulation studies and
real measurements. While this work does not use model checking per se, it presents
a formal model to study routing loops. In comparison, this chapter presents a formal
UPPAAL model, and uses verification and simulation to study the quality of route dis-
covery. UPPAAL has been used previously to study other protocols, such as LUNAR,
OLSR, DYMO, AODV, and LMAC[16, 52, 84, 32, 31].
The next section 5.2 describes B.A.T.M.A.N. routing protocol. Section 5.2.1 and
5.2.2 provide a literal and an alternative description of the two different models. Sec-
tion 5.3 describes the UPPAAL Model, and Section 5.4 the results of the performance
analysis. Section 5.5 concludes the chapter.
5.2 The B.A.T.M.A.N. Protocol
The ”German Freifunk” community has developed the network routing protocol known
as Better Approach to Mobile Adhoc Network [69] as an alternative to OLSR (Opti-
mised Link State Routing Protocol) [23]. Instead of having each node compute routing
tables that capture the complete network topology as OLSR does, B.A.T.M.A.N. nodes
maintain only information on neighbouring nodes. This information is used to identify
60
the best-next-hop [47].
Each node broadcasts at regular intervals originator messages (OGMs). These
are forwarded to neighbouring nodes, if they meet certain conditions, which will be
discussed later. Each node keeps a record of received OGMs, first to correctly identify
all available bidirectional links, and then to find the best-next-hop to a destination. The
protocol is phrased in terms of the origin of the OGMs; once routes have established
these originators will be the destination for packets. It is a desired property that the so-
called best-next-hops will indeed realise the best route, and that the protocol recovers
quickly from topology changes.
Formalisation of the internet draft in [20] as an UPPAAL model revealed a number
of ambiguities, for example the distinction between a new OGM and an OGM that is
not a duplicate. To resolve these ambiguities, this chapter used a model for a small
network and verified a few basic properties, such as successful route discovery. None
of the choices that had to be made to resolve those ambiguities was surprising, and any
implementation of B.A.T.M.A.N. will likely resolve these in a similar way.
However, the formalisation also revealed that the internet draft also contained few
explicit choices that arguably undermine the route discovery process. This means the
internet draft explicitly defines a rule or process that is arguably counterproductive. To
investigate the effect of those choices, this chapter will present a Literal Model that
adheres to the internet draft, and an Alternative Model that strives to improve on the
route discovery process. Both models will be presented alongside each other.
The internet draft defines the message format of OGMs, a sliding window to record
OGMs, rules for processing of OGMs, and the processes to update the sliding window,
ranking the neighbours, and for assembling OGMs that need to be forwarded. Table
5.1 summarises these rules and processes for both the Literal Model and Alternative
Model.
5.2.1 Literal Model
An OGM contains an originator ID (OID), a sender ID (SID), a sequence number,
a time-to-live (TTL), and two flags: the uni-directional link flag, and the direct-link-
flag. The TTL is used as a measure for the distance travelled. The last two flags are
used for the bidirectional-link check. We omit further discussion of the bidirectional-
link check and assume that it works as desired. It is mentioned here, since the internet
61
Literal Model Alternative Model
Generate OGM Increment the sequence number modulo upper
bound, set sender ID and OID to own ID, TTL to
maximum, and the other flags to false.
Sli
din
gW
indow Record A mapping for each sender from
in-window sequence numbers to
a Boolean
A mapping for each sender from in-
window sequence numbers to TTL
Ranking Rank by most in-window se-
quence numbers.
Rank by most best TTL per in-
window sequence number.
Best-next-
hop
Designate one best-next hop.
Change only when required.
Treat all currently top ranked nodes
as best-next-hop.
Updat
e
Condition Link to sender is bidirectional
and the sequence number is
newer.
Link to sender is bidirectional, and
OGM has a newer sequence num-
ber, or, the sequence number is in-
window and the TTL is better than
or equal to the best TTL for that se-
quence number.
Process Shift the window if the sequence
number is newer. Record the in-
window sequence number, and
update the last TTL.
Shift the window if the sequence
number is newer. Record the TTL
for in-window sequence number.
Forw
ardin
g
Condition Link to sender is bidirectional,
and sender is the best-next-hop,
and the TTL is larger than 2, and
either the OGM is not a dupli-
cate or has same TTL as the last
recorded TTL.
Link to sender is bidirectional, and
sender is the best-next-hop, and the
TTL is larger than 2, and sequence
number is in-window, and the TTL
is strictly better than the best TTL
for that sequence number.
Process Set sender ID to own ID, decrement TTL, set isDirect to true if pre-
vious sender is equal to originator, set isUniDirectional to true if the
link to sender is unidirectional.
Table 5.1: Comparison of literal and alternative B.A.T.M.A.N. models.
62
draft intertwines it with route discovery. For more details see [20].
Each node maintains a sliding window to record OGMs. It specifies for each origina-
tor a range of recent sequence numbers. The window is used to record for each sender
if it has sent a qualifying OGM with an in-window sequence number. If an OGM with
a newer sequence number is processed, the range will move accordingly. In addition,
each node keeps for each originator the last TTL as a measure of the distance to the
originator, which will be updated each time an OGM is recorded.
The internet draft defines the best-next-hop as the sender with the most recorded
OGMs within the sliding window. It specifies explicitly that at any time there is only
one designated best-neighbour, even if multiple nodes have the same ranking. This
designation will only change if another node surpasses the ranking of currently desig-
nated best-next-hop.
The condition for forwarding an OGM in the literal model (Table 5.1 is meant to
ensure that only OGMs that arrive via a best route are rebroadcasted, and that they are
also neither a duplicate, nor have been forwarded before. If a neighbour rebroadcasts
an OGM that the node has sent previously, it will have a different (lower) TTL than the
original.
Note, that the rules for the updating the sliding window and for forwarding OGMs
are not mutually exclusive; some OGMs may be only used for the update, some may
only be forwarded, and others both. If none of these rules apply, and none of the
bidirectional link rules, the OGM will be silently dropped.
Example Figure 5.1 gives an example of a sliding window for a node A in a network
with four nodes. For each originator, nodes B to D, it records which node forwarded an
OGM of that originator. For example, the sliding window (before the update) recorded
that node C forwarded an OGM from node Bwith sequence number 13 to node A. For
originator B we have that 3 out of 5 OGMs in the sliding window were submitted by B
- more than from any other node, hence it is considered to be the best-next-hop. For
originator C, nodes B and D have sent 2 in-window OGMs. The protocols designates
one of them as best-next-hop and only changes it if another node actually surpassed
the ranking of the currently designated best-next-hop.
If an OGM with a newer sequence number is processed, the range will move ac-
cordingly. For example, if node A receives from node D an OGM with OID C, TTL
7, and sequence number 11, it will move the window from sequence number 6 to 10, to
sequence numbers 7 to 11. All entries will be shifted, and D will be recorded as having
sent an OGM, and the lastTTL will be set to 7 (Fig 5.1 after). If it receives another
63
Figure 5.1: Sliding window for Node A in the literal model, before and after an update.
OGM with OID C and sequence number 11, but from node B, it will not be recorded
since it is a duplicate.
The decision whether to forward an OGM also takes into account whether the best-
next-hop sent it. An OGM will only be forwarded if it was sent by the designated
64
best-next-hop. For example, assume that node B is the current best-next-hop for OID
C, for Figure 5.1 before the update. If node A receives from node D an OGM with OID
C, TTL 7, and sequence number 11, it will update the window as explained in the
previous paragraph. However it will not forward it, since it was sent by node D, which
is not the designated best-next-hop. The intention is to not forward OGMs that were
received via sub-optimal routes, in this case however it drops an OGM reveived from
a node that has the same ranking as the designated best-next-hop.
The decision whether to forward an OGM also takes into account the TTL. An OGM
with a TTL of value 2 will be dropped. The purpose of this rules is to limit the number
of hops an OGM travels. The TTL is however also used to compare an OGM, with the
last TTL. Suppose, we continue the above scenario, and node B sends an OGM to node
A with OID C, sequence number 11 and TTL 8. It was sent from the best-next-hop,
however, the OGM is a duplicate and the TTL is different from the last TTL. Hence it
will not be forwarded. This even though the TTL is higher than the last TTL, i.e. the
OGM actually travelled a shorter distance than the last recorded OGM.
5.2.2 Alternative Model
The alternative model retains the basic structure, but redefines the rules to improve the
route discovery process. The essential difference is that this model records the TTL of
each in-window OGM, not just of the last. Figure 5.2 gives an example of routing
information maintained by the alternative model. Table 5.1 gives a summary of the
important changes.
The alternative model ranks the senders by how many OGMs had a maximal TTL
for any given in-window sequence number. All nodes that lead the ranking are
considered a best-next-hop. Furthermore, the alternative model extends the condition
for updating. It also records an OGM if it has a TTL that is better or equal to the
currently best TTL for that sequence number. This means it also records OGMs that
arrive via alternative routes that are as good or better.
Furthermore, the alternative model redefines the condition for forwarding. It will
only rebroadcast an OGM if it has a better (thus different) TTL than previously re-
ceived OGMs with that sequence number. Unlike the literal model it will not forward
OGMs that have the same TTL. However, unlike that model, it will forward only those
with a strictly better TTL.
Note also, that the literal model compares any TTL with the last TTL, regardless of
65
Figure 5.2: Sliding window for Node A in the alternative model, before and after an
update.
sequence number. This can be problematic if messages do not arrive in order, and the
66
best TTL may have changed in the meanwhile. The alternative model only compares
TTL from OGMs with the same sequence number. It is still possible that messages
do not arrive in order, but the effect of topology changes are confined to one sequence
number.
To summarise: The alternative model (1) redefines the ”best-next-hop” to also in-
clude alternative routes, (2) updates the sliding window if it finds better routes, (3)
forwards only messages that are evidence of improved routes, and (4) only compares
the time-to-live of messages that have the same sequence number.
Example Figure 5.2 gives an example of a sliding window for node A. Before the
update, both nodes B and D are considered best-next-hops for OID C, since they both
have the highest TTL for 3 out of the last 5 sequence numbers.
Suppose node A receives an OGM from node D with OID C, TTL 7, and sequence
number 11. The sliding-window will move, the sequence number 7 will be recorded.
The OGM will also be forwarded, since it is a new OGM, and node D is a best-next-
hops. Suppose further that node B forwards another OGM to node A, with OID C and
sequence number 11, now with TTL 8. This OGM will also be recorded and forwarded,
since it improves on the previous OGM with sequence number 11. Node B will now be
the next-best-hop; it has three times the best TTL, node D only twice, and node C only
once.
The next section analyses the effect of these changes on the performance, in par-
ticular on the number of suboptimal routes and on the recovery from route errors due
to mobility.
5.3 UPPAAL Model
For the performance analysis we use a timed (and probabilistic) UPPAAL model. It
uses a single template for all nodes in the network, and the entire network is a compo-
sition of N nodes.
The node template has four control locations. The first is a committed initial lo-
cation, the second, labelled Empty, models a node that has no OGM in its message
buffer, the third, labelled Processing, models a node that has OGMs in its buffer,
and, finally, another committed location. The latter is entered after processing of an
OGM, and is used to check if the buffer is empty or not. The edge from the initial
location to location empty initialises the sliding windows and other local variables.
From location Processing there are 7 outgoing edges. They model sending and
67
Figure 5.3: Timed model for simulation.
receiving of OGMs, and the processing of the OGMs:
• An edge that synchronises on channel SendOGM[oid]!. This transaction cre-
ates an OGM, and copies it to the shared global variable ogmGlobal.
• An edge that synchronises on channel SendOGM[sid]?, where sid is a valid
sender ID. The guard topology[sid] ensures that sender and receiver are
connected. This transaction calls a function receiveOGM(), which copies
the OGM from global variable ogmGlobal, and appends it to the local buffer
ogmLocal.
• Five edges that model the processing of OGMs in the buffer. The different rules
and processes refer to section in the internet draft.
– Rule 5.2.4 and Process 5.3 relate to the bidirectional-link check.
– Rule 5.2.6 and Process 5.4 relate to updating the sliding window.
68
– Rule 5.2.7 and Process 5.5 relate to forwarding OGMs.
If Rule 5.2.7 applies, the edge will synchronise on channel SendOGM[oid]!,
i.e. it forwards an OGM. All others are labelled with broadcast channel tau[id].
These edges model a local update of the routing information. The label allows
us to give those transition a higher priority – to reduce the number of states –
while it will not affect the routes that will be discovered.
The model uses clock ogmTime to ensure that any node sends an OGM once be-
tween MIN OGMTIME and MAX OGMTIME. The transition that models creation and
sending of new OGMs includes guard ogmTime>=MIN OGMTIME, and all noncom-
mitted control locations invariant ogmTime<=MAX OGMTIME.
The model uses clock responseTime to ensure that a node rebroadcasts within
MAX RES
PONSE time units, while there is an OGM in the buffer. The model includes two con-
trol locations, Empty for when the buffer is empty, Processing for when the node
processes OGMs. In the latter location there is the additional invariant responseTime
<=MAX RESPONSE, which enforces a timely response.
The model also includes a number of auxiliary functions to support analysis of
the performance by simulation, such as function countRouteMismatch() which
counts how many “best-next-hops” are actually suboptimal.
The model for a network in a dynamic topology includes one more template that
modifies the topology at random, based on an underlying a random walk model, as
described in [31].
This basic structure is the same for the literal and the alternative model. The differ-
ences given in Table 5.1 are implemented by different implementations of the functions
that check conditions and perform updates.
5.4 Simulation Results
This section compares the two models using simulation with UPPAAL. This com-
parison considers first a static topology to evaluate the speed of route discovery and
incidences of suboptimal routes. It then considers a dynamic topology with one mov-
ing node for comparing the performance when links are deleted or added.
69
The simulations use a 4×4 grid plus one additional central
node, as depicted to the right. Unlike a linear topology or
a fully connected graph, this setup has many potential sub-
optimal routes.
Processing of OGMs takes at most 1 time unit, new OGMs
are created once between 19 and 20 time units, and each sim-
ulation stops after 1000 time units. The size of the sliding
window is 5. We use an Intel i5-5200 CPU 2.2Ghz processor
with 8 GB RAM running UPPAAL 4.1.19. A single simu-
lation of the model with dynamic topology takes about 1200
seconds. All results are for 100 runs.
Figure 5.4: Results on route discovery and route mistakes for static topology. Averages
over 100 runs.
70
Route Discovery
Figure 5.4 depicts the results route discovery for a static topology. It shows for how
many node/originator pairs no route, i.e no best-next hop has been identified, and also
for how many pairs a potential best-next-hop is missing. The latter applies if more than
one optimal route to the originator exists.
Both versions discover within 120 time units at least one route for each node/ orig-
inator pair. It takes 6 rounds of OGMs, which corresponds to the network diameter 6.
The literal model converges to 164 missing routes. It finds no additional routes, since,
by design, only one best-next-hop is designated. In the alternative this number will
decline to almost zero, except for the disturbance introduced by new OGMs every 20
time units.
More telling are the route mistakes, i.e. the number of suboptimal routes. The
literal model number converges to an average of 1.5 suboptimal routes at time 1000,
while the alternative model converges to none. Note, the literal model chooses only
one best-next-hop; if that hop is suboptimal it has no optimal alternative.
Error Recovery
Figure 5.5 shows results for a dynamic topology. The central node is mobile, which
means moves freely in the entire 4-by-4 grid, adding and deleting links with a prob-
ability that depends on the current topology. The underlying model for mobility is a
random walk, as described in [31]. There will be one change to the topology every 100
time units. Figure 5.5 gives the number of suboptimal routes and the number of route
errors. The latter are best-next-hops that are actually not even directly connected to the
node. Route errors happen when a link is deleted due to mobility. The results show
that the alternative model will recover faster from suboptimal routes and route errors.
Figure 5.5 combines adding and deleting nodes in one graph. Over the 100 runs a
link was added 411 times and deleted 489 times, but in Figure 5.5 they are aggregated
the same way. The difference between the route errors in the interval 100 to 200
compared to the interval 200 to 300 is explained by the fact that due to the geometry
of the topology the mobile node will more often delete a link at time 100, and more
often add a link at time 200.
To isolate the effects of link addition and deletion, we looked at whether at a be-
ginning of a 100 times unit interval a link was added or deleted, and aggregated those
results separately. Figure 5.6 separates the results for adding and deleting links, for a
71
Figure 5.5: Results on route mistakes and route error for dynamic topology. Averages
over 100 runs.
clearer picture. The results show that the alternative model has higher initial values for
suboptimal routes and route errors This is because of multiple best-next-hops in the
alternative model. It identifies on average 60% more. If a link changes, it affects more
best-next-hops. On the other hand it also offers more alternatives, which allows it to
recover faster.
Figure 5.6 shows that the alternative model recovers faster from route errors when
a link is deleted, and converges faster to fewer suboptimal routes when a link is added.
The small number of route errors for an added link is noise remaining from earlier
deletions. Adding a link may introduce suboptimal routes, but not route errors.
OGM Classification
The previous results compare the performance of both models in terms of route mis-
takes and errors. Another measure is to see how many OGMs are created, forwarded
72
Figure 5.6: Recovery after link deletion or addition. Values are averages.
and recorded. Figure 5.7 compares how received OGM were classified; whether to
perform a bidirectional link check (BLC), update the sliding window (UPD), forward
the OGM (FWD), update and forward (UPD+FWD), or drop it. The result for the static
and dynamic topology are very similar. The alternative model drops fewer OGMs (-
10%), updates the sliding window more often (+15%), and forwards about he same
percentage (28%). However, the alternative model nodes processes overall 10% more
OGMs.
A cursory reading of these results suggest that the OGMs that are forwarded, or
forwarded and updated by the literal model are the same type of messages that are
forwarded and updated by the alternative model. After all, the share of forwarded
messages (FWD) and of the forward and updated messages (UPD+FWD) in the literal
model adds up to the same share of messages that are forwarded in the alternative
model. The following analysis, however, shows that this cursory comparison of how
the two models classify OGMs is incorrect.
For a more detailed look how the changes in the alternative model change the way
OGMs are classified and processed, we ran the literal model in parallel with the classi-
fication of the alternative model. The literal model determines which OGMs to forward
according to its rules, while the alternative classification logs whether it would have
forwarded or dropped the OGM. And vice versa, i.e. the alternative model was run,
with the literal model in parallel for logging. Figure 5.8 compares how OGMs are
classified for the dynamic topology.
The analysis shows that the alternative model would use many OGMs that are
73
Figure 5.7: Classification of received OGMs. Averages over 100 runs.
Figure 5.8: Classification of OGMs generated in literal model by alternative model
rules (left), and vice versa (right).
dropped in the literal model for an update. Furthermore, it would not forward any of
the OGMs that the literal model forwards without update. This includes OGMs with
an TTL equal to the last TTL. Conversely, the literal model would drop many OGMs
that the alternative model uses for an update, and it would not forward most OGMs
that the alternative model forwards. This includes the OGMs with a better TTL, and
thus a better distance. This cross comparison of the classification of OGMs confirms
that the literal and alternative version do forward very different sets of OGMs.
5.5 Summary
Formalisation of the B.A.T.M.A.N. protocol revealed several explicit choices that have
a negative impact on the route discovery process [20]. This chapter proposes an al-
74
ternative model that departs from the internet draft. It includes a sliding window that
records the TTL of in-window OGMs. The alternative model then (1) redefines the
”best-next-hop” to also include alternative routes, (2) updates the sliding window if
better routes are found, (3) forwards only messages that are evidence of improved
routes, and (4) compares the time-to-live only of messages that have the same sequence
number.
These changes allow to reformulate the rules and updates in terms of the TTL of an
OGM, i.e. in terms of the distance travelled. The chapter presented simulation results
for UPPAAL models that demonstrate that these changes lead to better route discovery
and improved error recovery. This comes at an expense of some additional overhead.
The alternative model processes in our simulation experiment about 10% more OGMs.
Future work should investigate how the proposed alternative by Furlan [35] could
be combined with our alternative model, and how to add these to the latest implementa-
tions of B.A.T.M.A.N.. This would enable simulation on a classical network simulator
and, of course, on a real test bed.
75
Chapter 6
Conclusion
Network routing protocols play a vital role in communications network. This thesis
discussed how nodes communicate, in particular how the router exchanges information
with each other.
The protocol studied in this thesis is Better Approach To Mobile Ad hoc Networks
(B.A.T.M.A.N.), a network routing protocol that is proactive and divides the informa-
tion about the end-to-end path of the entire topology amongst the nodes. Unlike other
routing protocols, B.A.T.M.A.N. nodes become aware of their neighbouring imme-
diate peers, and are only interested about the next best hop towards all other nodes.
Therefore, it is not necessary to store the entire topology in the routing table of each
node.
Chapter 3 proposed an abstract, reusable, topology-based mobility model for wire-
less networks. This model abstracts from most physical aspects and captures mobility
as a simple probabilistic automaton. Possible models of mobility are studied in dif-
ferent network topologies. To determine realistic transition probabilities regarding ex-
isting mobility models, simulation-based experiments were performed. Random walk
and random waypoint models were simulated studying the probabilities using different
transition ranges. Combining the topology based mobility model distilled with prob-
abilities, a SMC UPPAAL model was created. This model was used in Chapter 5, to
evaluate the performance of B.A.T.M.A.N. when a node is mobile.
Chapter 4 formalised B.A.T.M.A.N and the internet draft [69] was used to develop
a model in SMC UPPAAL.
The basic model of B.A.T.M.A.N. showed that it ensures loop-freedom, bi-directional
link discovery, and route discovery. Then a full model was developed that addressed
numerous ambiguities and inefficiencies in the internet draft. This was used for per-
formance evaluation.
In Chapter 5, the formalisation of B.A.T.M.A.N. addressed several ambiguities
and inconsistencies and this had a negative impact in decision making during route
discovery. This chapter proposed an alternative model, that redefined ”best-next-hop”,
updated the sliding window if better routes are found, forwarded only messages that
76
were evident of improved routes and compared time-to-live only of messages that had
the same sequence number. As a result this led to better route discovery and improved
error recovery. There were some additional overhead such as processing 10% more
OGMs.
In this thesis there were a number of lessons learnt. The first was that formalising,
modelling, analysing, verifying and validating routing protocols is a difficult process.
This in part because internet draft are written in normal English, contain ambigui-
ties, and leave out important details. SMC UPPAAL is a good tool for performance
analysis. UPPAAL language is adequate to model such protocols that deal with time,
probability, data structures, broadcast, unicast and synchronisation.
This thesis creates a few openings for future work. There is every possibility to
combine the existing topology based on mobility model in Chapter 3 model with a
variety of protocols. The alternative model developed in Chapter 5 can be implemented
in a simulation environment such as OMNET++, and be tested in a real test bed. The
B.A.T.M.A.N. internet draft has not been updated since 2008, even though there have
been many changes to the implementations. B.A.T.M.A.N. is currently in version 4.0
and there should be a new internet draft. It should be less ambiguous and complete
with all details highlighted in an orderly manner.
77
Bibliography
[1] M. Abolhasan, T. Wysocki, and E. Dutkiewicz. A review of routing protocols for
mobile ad hoc networks. Ad Hoc Networks, 2(1):1–22, 2004.
[2] P. Aggarwal and H. Aggarwal. Article: Comparative analysis of routing pro-
tocols in mobile ad-hoc networks (manets). International Journal of Computer
Applications, 95(4):38–42, June 2014. Full text available.
[3] A.O. Ajayi, A.A. Adigun, and W.O. Ismaila. A review of routing protocols for
practical rural wireless mesh networks (wmns). International Journal of Com-
puter Applications, 114(16), 2015.
[4] I.F. Akyildiz, X. Wang, and W. Wang. Wireless mesh networks: A survey. Com-
puter Networks, 47(4):445–487, 2005.
[5] K.R. Apt and D.C. Kozen. Limits for automatic verification of finite-state con-
current systems. Inf. Process. Lett., 22(6):307–309, May 1986.
[6] S.M. Artelaris. Performance evaluation of routing protocols for wireless mesh
networks.
[7] C. Baier and J.P. Katoen. Principles of Model Checking. MIT Press, 2008.
[8] L. Barolli, M. Ikeda, G. De Marco, A. Durresi, and F. Xhafa. Performance analy-
sis of olsr and batman protocols considering link quality parameter. In Advanced
Information Networking and Applications, 2009. AINA’09. International Confer-
ence on, pages 307–314. IEEE, 2009.
[9] P. Basu, J. Redi, and V. Shurbanov. Coordinated flocking of uavs for improved
connectivity of mobile ground nodes. In Military Communications Conference,
2004. MILCOM 2004. 2004 IEEE, volume 3, pages 1628–1634. IEEE, 2004.
[10] C. Bettstetter, H. Hartenstein, and X. Prez-Costa. Stochastic properties of the
random waypoint mobility model. Wireless Networks, 10(5):555–567, 2004.
78
[11] B. Bhargav and G. Richard. Topology Broadcast based on Reverse-Path Forward-
ing, RFC 3684. www.networksorcery.com/enp/protocol/tbrpf.htm. Accessed:
2015-06-08.
[12] B.W. Boehm. Software Engineering Economics. Prentice Hall PTR, Upper Sad-
dle River, NJ, USA, 1st edition, 1981.
[13] A.M. Borah and B. Sharma. A survey of random walk mobility model for conges-
tion control in manet’s. International Journal of Computer Applications, 111(7),
2015.
[14] A. Boswell. Specification and validation of a security policy model. IEEE Trans-
actions on Software Engineering, 21(2):63–68, 1995.
[15] J. Broch, D.A. Maltz, D.B. Johnson, Y.C. Hu, and J. Jetcheva. A performance
comparison of multi-hop wireless ad hoc network routing protocols. In Proceed-
ings of the 4th Annual ACM/IEEE International Conference on Mobile Comput-
ing and Networking, MobiCom ’98, pages 85–97, New York, NY, USA, 1998.
ACM.
[16] P. Bulychev, A. David, K.G. Larsen, M. Mikucionis, D.B. Poulsen, A. Legay, and
Z. Wang. UPPAAL-SMC: statistical model checking for priced timed automata.
In Proceedings 10th Workshop on Quantitative Aspects of Programming Lan-
guages and Systems, QAPL 2012, Tallinn, Estonia, 31 March and 1 April 2012.,
pages 1–16, 2012.
[17] J.L. Caldwell. Formal methods technology transfer: A view from nasa. Formal
Methods in System Design, 12(2):125–137, 1998.
[18] T. Camp, J. Boleng, and V. Davies. A survey of mobility models for ad hoc
network research. Wireless Communications and Mobile Computing (WCMC):
Special Issue on Mobile ad hoc Networking Research: Trends and Applications,
2:483–502, 2002.
[19] M. Carnot, C. DaSilva, B. Dehbonei, and F. Mejia. Error-free software develop-
ment for critical systems using the b-methodology. In Software Reliability Engi-
neering, 1992. Proceedings., Third International Symposium on, pages 274–281.
IEEE, 1992.
79
[20] K. Chaudhary, A. Fehnker, and V. Mehta. Modelling, verification, and
comparative performance analysis of the batman protocol. arXiv preprint
arXiv:1703.06570, 2017.
[21] R. Cigno and D. Furlan. Improving BATMAN Routing Stability and Performance.
PhD thesis, PhD thesis, University of Trento, 2011. 2, 6, 7, 8, 9, 10, 11, 12, 13,
18, 19, 26, 35, 2011.
[22] E. M. Clarke, Wing, and M. Jeannette. Formal methods: State of the art and
future directions. ACM Comput. Surv., 28(4):626–643, December 1996.
[23] T. Clausen and Jacquet P. Optimised Link State Routing Protocol
(OLSR),Network Working Group. Accessed:2016-29-12.
[24] S. Corson and J. Macker. Mobile ad hoc networking (manet): Routing protocol
performance issues and evaluation considerations, 1999.
[25] S.R. Das, C.E. Perkins, and E.M. Belding-Royer. Ad hoc On-Demand Distance
Vector (AODV) Routing. RFC 3561, July 2003.
[26] A. David, K.G. Larsen, A. Legay, M. Mikucionis, and D.B. Poulsen. Uppaal
smc tutorial. International Journal on Software Tools for Technology Transfer,
17(4):397–415, 2015.
[27] B.L. Di Vito. FME’96: Industrial Benefit and Advances in Formal Methods:
Third International Symposium of Formal Methods Europe Co-Sponsored by
IFIP WG 14.3 Oxford, UK, March 18–22, 1996 Proceedings, chapter Formal-
izing new navigation requirements for NASA’s Space Shuttle, pages 160–178.
Springer Berlin Heidelberg, Berlin, Heidelberg, 1996.
[28] G.W. Dinolt, P.C. Baker, R.B. Neely, and J. Freeman. Multinet gateway–towards
a1 certification. In Security and Privacy, 1984 IEEE Symposium on, pages 226–
226. IEEE, 1984.
[29] E. A. Emerson and C. Edmund. Using branching time temporal logic to synthe-
sise synchronization skeletons. Science of Computer Programming, 2(3):241 –
266, 1982.
[30] J. Esparza, O. Grumberg, and S. Sickert, editors. Dependable Software Systems
Engineering, volume 45 of NATO Science for Peace and Security Series - D:
Information and Communication Security. IOS Press, 2016.
80
[31] A. Fehnker, P. Hofner, M. Kamali, and V. Mehta. Topology-based mobility mod-
els for wireless networks. In Proceedings of the 10th International Conference
on Quantitative Evaluation of Systems, QEST’13, pages 389–404, Berlin, Hei-
delberg, 2013. Springer-Verlag.
[32] A. Fehnker, R. Van Glabbeek, P. Hofner, A. McIver, M. Portmann, and W.L.
Tan. Automated analysis of AODV using UPPAAL. In Cormac Flanagan and
Barbara Knig, editor, 18th International Conference on Tools and Algorithms for
the Construction and Analysis of Systems (TACAS 2012), pages 173–187, Tallinn,
Estonia, mar 2012. Springer.
[33] A. Fehnker, R. Van Glabbeek, P. Hofner, A. McIver, M. Portmann, and W.L. Tan.
A process algebra for wireless mesh networks used for modelling, verifying and
analysing AODV. CoRR, abs/1312.7645, 2013.
[34] A. Fehnker, L. Van Hoesel, and A. Mader. Modelling and verification of the lmac
protocol for wireless sensor networks. In Proceedings of the 6th International
Conference on Integrated Formal Methods, IFM’07, pages 253–272, Berlin, Hei-
delberg, 2007. Springer-Verlag.
[35] D. Furlan. Analysis of the overhead of batman routing protocol in regular torus
topologies. University of Trento, Italy, Tech. Rep, 2011.
[36] F. Ghassemi, S. Ahmadi, W. Fokkink, and A. Movaghar. Model checking manets
with arbitrary mobility. In Fundamentals of Software Engineering - 5th Interna-
tional Conference, FSEN 2013, Tehran, Iran, April 24-26, 2013, Revised Selected
Papers, pages 217–232, 2013.
[37] G. Gigante and D. Pascarella. Formal methods in avionic software certification:
The do-178c perspective. In Proceedings of the 5th International Conference on
Leveraging Applications of Formal Methods, Verification and Validation: Appli-
cations and Case Studies - Volume Part II, ISoLA’12, pages 205–215, Berlin,
Heidelberg, 2012. Springer-Verlag.
[38] J.C. Godskesen. Coordination Models and Languages: 9th International Con-
ference, COORDINATION 2007, Paphos, Cyprus, June 6-8, 2007. Proceedings,
chapter A Calculus for Mobile Ad Hoc Networks, pages 132–150. Springer
Berlin Heidelberg, Berlin, Heidelberg, 2007.
81
[39] R. Groenevelt, E. Altman, and P. Nain. Relaying in mobile ad hoc networks: The
brownian motion mobility model. Wireless Networks, 12(5):561–571, 2006.
[40] D. Grover and G. Singh. Review of routing protocols in manet. International
Journal of Computer Application, 5(2):42–50, 2012. Full text available.
[41] A. Hall. Seven myths of formal methods. IEEE Software, 7(5):11–19, Sept 1990.
[42] T. Hardes. Performance Analysis and Simulation of a Freifunk Mesh Network in
Paderborn using B.A.T.M.A.N Advanced. Master’s thesis, University of Pader-
born, October 2015.
[43] D. Harel. Biting the silver bullet: Toward a brighter future for system develop-
ment. Computer, 25(1):8–20, 1992.
[44] W.R. Heinzelman, A. Chandrakasan, and H. Balakrishnan. Energy-efficient com-
munication protocol for wireless microsensor networks. In Proceedings of the
33rd Hawaii International Conference on System Sciences-Volume 8 - Volume 8,
HICSS ’00, pages 8020–, Washington, DC, USA, 2000. IEEE Computer Society.
[45] D. Helen and D. Arivazhagan. Applications, advantages and challenges of ad hoc
networks. JAIR, 2(8):453–7, 2014.
[46] P. Hofner, R.J. van Glabbeek, W.L. Tan, M. Portmann, A. McIver, and
A. Fehnker. A rigorous analysis of aodv and its variants. In Proceedings of
the 15th ACM international conference on Modelling, analysis and simulation of
wireless and mobile systems, pages 203–212. ACM, 2012.
[47] A. Huhtonen. Comparing aodv and olsr routing protocols. Telecommunications
Software and Multimedia, pages 1–9, 2004.
[48] J. Jacky. Specifying a safety-critical control system in z. In FME’93: Industrial-
Strength Formal Methods, pages 388–402. Springer, 1993.
[49] Q. Jean-Pierre and S. Joseph. Specification and verification of concurrent systems
in cesar. In Proceedings of the 5th Colloquium on International Symposium on
Programming, pages 337–351, London, UK, UK, 1982. Springer-Verlag.
[50] D. Johnson, N. Ntlatlapa, and C. Aichele. Simple pragmatic approach to mesh
routing using batman. 2008.
82
[51] M. Kamali. Modelling and verifying the olsr protocol using uppaal. Master’s
thesis, Universitetet i Agder; University of Agder, 2014.
[52] M. Kamali, P. Hofner, M. Kamali, and L. Petre. Formal analysis of proactive,
distributed routing. In Software Engineering and Formal Methods, pages 175–
189. Springer, 2015.
[53] P. Kaur. Article: An overview on manet- advantages, characteristics and security
attacks. IJCA Proceedings on International Conference on Advances in Emerging
Technology, ICAET 2016(1):6–9, September 2016. Full text available.
[54] T. King. Formalising british rail’s signalling rules. In FME’94: Industrial Benefit
of Formal Methods, pages 45–54. Springer, 1994.
[55] J.C. Knight. Safety critical systems: Challenges and directions. In Proceedings
of the 24th International Conference on Software Engineering, ICSE ’02, pages
547–550, New York, NY, USA, 2002. ACM.
[56] E. Kulla, M. Hiyama, M. Ikeda, and L. Barolli. Performance comparison of olsr
and batman routing protocols by a manet testbed in stairs environment. Comput.
Math. Appl., 63(2):339–349, January 2012.
[57] N.G. Levenson. Safeware: System Safety and Computers. ACM, New York, NY,
USA, 1995.
[58] C. Liu and J. Kaiser. Survey of mobile ad hoc network routing protocols. 2005.
[59] J. Macker. Mobile ad hoc networking (manet): Routing protocol performance
issues and evaluation considerations. 1999.
[60] A. Manjeshwar and D.P. Agrawal. Apteen: A hybrid protocol for efficient routing
and comprehensive information retrieval in wireless sensor networks. In Parallel
and Distributed Processing Symposium, Proceedings International, pages 195–
202, 2002.
[61] A.S. Marinis. Performance evaluation of routing protocols for wireless mesh
networks, 2016.
[62] P. Mataga and P. Zave. Multiparadigm specification of an at&t switching system.
Applications of formal methods, pages 375–398, 1995.
83
[63] M. McGuire. Stationary distributions of random walk mobility models for wire-
less ad hoc networks. In Proceedings of the 6th ACM international symposium
on Mobile ad hoc networking and computing, pages 90–98. ACM, 2005.
[64] H. Michael and R. Mark. Logic in Computer Science: Modelling and Reasoning
About Systems. Cambridge University Press, New York, NY, USA, 2004.
[65] B. Milic and M. Malek. Analyzing large scale real-world wireless multihop net-
work. IEEE Communications Letters, 11(7), 2007.
[66] S. Misra and I. Zhang. Guide to wireless Ad Hoc networks. Springer Science &
Business Media, 2009.
[67] D. Murray, M. Dixon, and T. Koziniec. An experimental comparison of routing
protocols in multi hop ad hoc networks. In Telecommunication Networks and Ap-
plications Conference (ATNAC), 2010 Australasian, pages 159–164. IEEE, 2010.
[68] H. Naanani, H. Mounsif, and R. Mustap. Study of the performance and limita-
tions of a reactive ad hoc protocol (aodv). 2013.
[69] A. Neumann, C. Aichele, M. Lindner, and S. Wunderlich. Better approach to
mobile ad-hoc networking (b.a.t.m.a.n.). urlhttp://www.tools.ietf.org/html/draft-
wunderlich-openmesh-manet-routing-00. Accessed: 2015-06-08.
[70] R.S. Patel, R. Anjuman, and S. Patel. A survey paper on aodv routing protocol
for manet. pages 141–145, 2014.
[71] C. Perkins, E. Belding-Royer, and S. Das. Ad hoc on-demand distance vector
(aodv) routing. Technical report, 2003.
[72] H. Pucha, S.M. Das, and Y.C. Hu. The performance impact of traffic patterns on
routing protocols in mobile ad hoc networks. Computer Networks, 51(12):3595–
3616, 2007.
[73] R.R. Roy. Handbook of mobile ad hoc networks for mobility models. Springer
Science & Business Media, 2010.
[74] A. Sharma and N. Rajagopalan. A Comparative Study of B.A.T.M.A.N. and
OLSR Routing Protocols for MANETs. International Journal of Advanced
Trends in Computer Science and Engineering, 2(5):13–17, 2013.
84
[75] P.T. Singh, R.K. Singh, and J. Vats. Article: Routing protocols in ad hoc net-
works: A review. International Journal of Computer Applications, 25(4):30–35,
July 2011. Full text available.
[76] V. Singla and Y.K. Sharma. Impact of network load and node mobility on the
performance of proactive, reactive and hybrid routing protocols of manet. Inter-
national Journal of Advanced Research in Computer Science, 8(3), 2017.
[77] M. Stoelinga. An introduction to probabilistic automata. Bulletin of the European
Association for Theoretical Computer Science, pages 176–198, 2002.
[78] S. Tschirner, L. Xuedong, and W. Yi. Model-based validation of qos properties
of biomedical sensor networks. In Proceedings of the 8th ACM international
conference on Embedded software, pages 69–78. ACM, 2008.
[79] R. Van Glabbeek, P. Hofner, W.L. Tan, and M. Portmann. Sequence numbers do
not guarantee loop freedom: Aodv can yield routing loops. In Proceedings of
the 16th ACM international conference on Modelling, analysis & simulation of
wireless and mobile systems, pages 91–100. ACM, 2013.
[80] L.F. Van Hoesel and P.J. Havinga. A lightweight medium access protocol (lmac)
for wireless sensor networks: Reducing preamble transmissions and transceiver
state switches. In 1st International Workshop on Networked Sensing Systems,
INSS 2004, pages 205–208, Tokio, Japan, 2004. Society of Instrument and Con-
trol Engineers (SICE).
[81] L.F.W. van Hoesel. Sensors on speaking terms : schedule-based medium ac-
cess control protocols for wireless sensor networks. PhD thesis, Enschede, the
Netherlands, June 2007.
[82] Y. Venema. Temporal logic. Institute for Logic, Language and Computation
(ILLC), University of Amsterdam, 1998.
[83] J.C.P. Wang, B. Hagelstein, and M. Abolhasan. Experimental evaluation of ieee
802.11s path selection protocols in a mesh testbed. In 2010 4th International
Conference on Signal Processing and Communication Systems, pages 1–3, Dec
2010.
[84] O. Wibling, J. Parrow, and A. Pears. Formal Techniques for Networked and Dis-
tributed Systems – FORTE 2004: 24th IFIP WG 6.1 International Conference,
85
Madrid Spain, September 27-30, 2004. Proceedings, chapter Automatised Verifi-
cation of Ad Hoc Routing Protocols, pages 343–358. Springer Berlin Heidelberg,
Berlin, Heidelberg, 2004.
[85] J. Woodcock, P.G. Larsen, J. Bicarregui, and J. Fitzgerald. Formal methods:
Practice and experience. ACM Comput. Surv., 41(4):19:1–19:36, October 2009.
[86] J. Yoon, M. Liu, and B. Noble. Random waypoint considered harmful, 2003.
[87] H.L. Younes. Planning and verification for stochastic processes with asyn-
chronous events. In Proceedings of the Nineteenth National Conference on Ar-
tificial Intelligence, Sixteenth Conference on Innovative Applications of Artifi-
cial Intelligence, July 25-29, 2004, San Jose, California, USA, pages 1001–1002,
2004.
[88] P. Zave. Secrets of call forwarding: A specification case study. In Formal De-
scription Techniques VIII, pages 169–184. Springer, 1995.
[89] P. Zave and M. Jackson. Where do operations come from? a multiparadigm
specification technique. IEEE transactions on software engineering, 22(7):508–
528, 1996.
86
List of Publications
The following papers have been published from this research thesis:
1. Fehnker, A., Hofner, P., Kamali, M. and Mehta, V. Topology-Based Mobility
Models for Wireless Networks. In QEST 2013, Proceedings of the 10th Interna-
tional Conference on Quantitative Evaluation of Systems, 10, 2013.
2. Chaudhary, K., Fehnker, A. and Mehta, V. Modelling, Verification, and Compar-
ative Performance Analysis of the BATMAN Protocol In MARS 2017, EPTCS
244, 2017.
3. Fehnker, A., Chaudhary, K. and Mehta, V. An Even Better ApproachImproving
the BATMAN Protocol Through Formal Modelling and Analysis. In In NASA
Formal Methods Symposium (pp. 164-178). Springer 2018.
87
Appendix AThe appendix is organised as follows and includes links to files used for simulations
with models in the repository.
A.1 Chapter 3 - Topology-based Mobility Models for
Wireless Networks
The mobile node is represented by a list of nodes within transmission range and the
simulator computes the transition probabilities from one set to the next. The list of
nodes which forms the source set does the following:
• The transition either adds to or removes from the source set.
• A list of neighbours which may be added or removed (the change set).
• How often this transition occurred (frequency).
• How often this source set of the transition occurred (total).
• The probability of a transition (for each node in the change set).
The results factor out the 8 possible symmetries of a square grid. This means up to
8 different sets will be mapped to one representative base set. If a change set contains
more than one node, it means that these nodes are symmetric in this sense.
It is assumed for the boundary:
• The moving node making its way in the inner square.
• This is to ensure that even if it is at the boundary it can have a full set of neigh-
bours.
• Ensures comparability of results close to boundary and in center.
If a waypoint is outside of the boundary, it is assumed how it will be reflected and
this of course only applies to the random walk model. If a waypoint is way outside
of the boundary it might be reflected several times. The standard deviation determines
the expected distance between waypoints.
To improve the results and reduce the number of data to be stored, the model factors
out symmetries.
88
A.2 UPPAAL Model - Random Walk Model
Given below is the description of the UPPAAL code for the Random Walk Model.
• listofhoods is the list of all neighbourhoods that were encountered during
simulation. One row is one topology, i.e. one set of nodes connected to the
mobile node. Index -1 is used as padding.
• shortlist is a shorter list of representative topologies. Different topologies
that are the same under mirroring or rotation of grid onto itself are mapped to
the same representative.
• list2index tells which permutation was used to obtain the representative.
Used to translate indices/node ids from one representation to the other.
• list2map tells which row in shortlist is the representative.
• shortmap gives transition probabilities. A row gives for each representative
topology the probability that the node will be added or deleted from the that
topology. Probabilities are normalized to values out of 1000.
• arrayindex are the 8 different possible permutations of indices used to find a
representative topology
• maxframe and minframe and clock t are used to determine how often the
topology can change. If you want to change the frequency of topology changes,
change those values.
• neighbourhood[N] is an arrray of booleans. Element i is true if i is a node
in the current topology.
• mapindex point to which topolgy in listofhoods is the current topology.
• neighbours is an array with the nodes that are in the current topology.
This model was generated. This models a mobile node in a grid. In the simulator
of UPPAAL, also transitions with probability 0 are enabled. This means you might
reach topologies that are actually not reachable. Or reachable with probability 0, if
you will. In this case you will note that the mapindex is negative, which means that
this it not a topology that can be reached given the range of the mobile node. The
guard mapindex>=0 ensures that the model deadlocks in this improbable case. The
89
verifier does not consider transitions with probability 0. It will (correctly) disregard
them. The two properties provided in the verifier validate this as well.
A.3 UPPAAL Model - Random Waypoint Model
There is a very slight difference between the code of the two models therefore, rep-
etition is omitted. This section provides the local declarations and functions for the
Random Waypoint Model. The methods and system declarations are the same as in
Random Walk.
The link given http : //repository.usp.ac.fj/id/eprint/10891 provides the files
used for models and simulation.
A.4 C++ Code for a Mobile Node travelling amongst
Static Nodes
This code has been used for the simulation where there are static nodes in a N x N grid
and a single mobile node travels with a certain speed and direction to determine the
transmission range as it falls into. rs);
90
Appendix B
B.1 Chapter 4 - Modelling and Verification of the
B.A.T.M.A.N. Protocol
There were two models created:
• one implementing a literal reading of the internet draft [69].
• and the Alternative Model, with minor changes to see if there are more than one
next-best-hop determined.
Furthermore, a literal timed and untimed model were done and the same for alter-
native i.e. a timed and an untimed model.
The Literal model (as in internet draft [69]) provides the code for the models that
were used for Modelling, Verification, and Comparative Performance Analysis of the
B.A.T.M.A.N. Protocol.
The link given http : //repository.usp.ac.fj/id/eprint/10896 provides the files
used for models and simulation.
91
Appendix C
C.1 Chapter 5 - An Even Better Approach
- Improving the B.A.T.M.A.N. Protocol Through
Formal Modelling and Analysis
.
This alternate model departs from the internet draft. It tries to improve the route
discovery process. It has the inclusion of the sliding window that helps in better de-
cision making that redefines the next best hop, updates the sliding window if better
routes are found, forwards messages that are for improved routes and compares the
TTL that have the same sequence number.
The link given http : //repository.usp.ac.fj/id/eprint/10897 provides the files
used for models and simulation.
92