Device localisation through wireless mesh networks: A performance analysis

(1)

Bachelor Informatica

Device localisation through

wire-less mesh networks: A

perfor-mance analysis

Jason Kerssens

June 17, 2019

Supervisor(s): dr. R. G. Belleman; R. de Graaf

Inf

orma

tica

—

Universiteit

v

an

Ams

terd

am

(2)

(3)

Abstract

A wireless mesh network (WMN) is a type of wireless ad hoc network. It is an easily deployable, self-configuring network which does not make use of any preexisting infrastruc-ture. In this paper an implementation for a WMN making use of the Better Approach To Ad-hoc Networking advanced (batman-adv) routing protocol is described. An application to send GPS data over this network is described as well. A performance analysis is carried out to observe the impact that the number of hops and the signal strength have on metrics such as throughput, jitter, packet loss and round-trip time. We observe that the network’s performance is impacted significantly by higher hop counts and lower signal strengths.

(4)

(5)

Introduction

Oftentimes mobile phones are able to communicate with other devices by connecting to the In-ternet through a Wi-Fi access point or through cellular service. Wi-Fi access points are not always available, however, and cellular service may in some cases be unavailable or unreliable. For the average user, not having access to the Internet may be an inconvenience. In other cases, such as in regards to public safety, communication is paramount. In these cases, an alternative approach should be taken if communication over the Internet is not possible. One approach is to set up a local area network (LAN) such that devices can still communicate with other lo-cal devices. If this approach is taken, it is desirable to be able to easily and quickly set up a LAN. With the increasing number of mobile phones equipped with wireless data communication technologies, such as Bluetooth and Wi-Fi, wireless networking has become ever more impor-tant. An advantage of a wireless network over a wired network is that it does have to rely on any preexisting (wired) infrastructure. Instead, it is possible to establish direct connections between devices, called ad hoc connections. By having multiple ad hoc connections, a network can be created, called an ad hoc network.

One type of ad hoc network is a Wireless Mesh Network (WMN). WMNs are easily deployable because they are self-configuring and make no use of preexisting infrastructures, making them ideal in situations where local communication is needed. WMNs have been used for public safety applications, being deployed as an Incident Area Network (IAN) which is a temporary network specifically created for incidents [1]. In such cases, knowing the location of all social workers within the area could improve their work efficiency. A way to localise the devices connected to the network may be desired in such cases.

1.1 Research question

This research aims to implement a stand-alone wireless mesh network for local communication and to explore the possibilities of localisation of connected devices through such a network, using GPS. The aim of this network is for it to be implemented in crowded areas, such as at festivals, where Internet connections may be unreliable. The GPS data can be used to track the festival’s crew members. The network’s performance will be evaluated on various aspects. The research questions we will answer are:

How can a wireless mesh network be implemented such that the devices connected to it can be localised?

(8)

1.2 Structure

The following chapters are organized as follows. In chapter 2 the theoretical background is dis-cussed. Chapter 3 discusses the design of the network. In chapter 4 the implementation of the design choices from chapter 3 are discussed. Chapter 5 discusses the experiments done to analyse the network’s performance and in chapter 6 the results of these experiments are shown. Finally chapter 7 and 8 are the discussion and conclusion respectively.

(9)

CHAPTER 2

Theoretical background

2.1 Wireless Mesh Network

A wireless mesh network (WMN) is defined as “a two-tier architecture based on wireless multi-hop transmission” [2]. Generally speaking, a WMN consists of mesh clients and mesh routers. These are the two tiers of the architecture. The mesh routers form the backbone of the WMN and create the infrastructure of the network. These routers have minimal mobility and perform routing and configuration [3]. A mesh client can connect to a WMN by establishing a connection to any of the mesh routers. The mesh client can move freely between mesh routers without losing connection. A WMN can either serve as an extension to an already existing network, which may be connected to the Internet, or it can be a stand-alone network [2].

In [3] three types of WMNs are defined:

• Infrastructure/Backbone WMN: A WMN consisting of mesh routers forming a self-configuring and self-healing infrastructure of the network to which clients can connect to. Routing and configuration is performed by the mesh routers.

• Client WMN: Clients connect to each other forming a network. They also perform routing and configuration themselves. This is essentially a regular mobile ad hoc network (MANET).

• Hybrid WMN: A combination of the above WMNs where both routers and clients per-form routing and configuration. Clients can be connected to each other in ad hoc fashion, extending the range of the mesh network.

From this point onward, when we speak of a WMN we refer to an infrastructure/backbone WMN. Traditional wireless local area networks (WLANs) consist of access points which are con-nected via a wired link to a network switch, which in turn may serve as a gateway to the Internet. A WMN differs from a traditional WLAN in the sense that it is a wireless, self-healing, self-configuring network with multi-hopping capabilities. The differences between the two types of networks can be seen in figure 2.1

While traditional WLANs rely on wired connections and preexisting (wired) network infras-tructures, WMNs do not. Instead, in the case of WMNs, wireless ad hoc connections between mesh routers are established. When a link between two mesh routers is severed or a mesh router disconnects from the network, an alternative route can often be taken to a destination. In the case of a traditional WLAN, when a link is severed, there is no alternative path that can be taken. This makes WMNs more robust and this also means that there is no single point of failure in a WMN. In the case of WMNs, when a mesh router has to send packets to another mesh router which is not its direct neighbour, it can still reach it by means of multi-hopping. This is when

(10)

Figure 2.1: Traditional WLAN (a) versus Wireless Mesh Network (b) [2]

data is relayed from one mesh router to the next until the destination is reached. This is not the case for traditional WLANs. Here the packets are sent directly to the switch over a wired link [2]. A mesh network can be either fully connected, meaning each node is connected to all other nodes in the network, or it is partially connected, meaning that each node only connects to one or a few nodes. The advantage of a fully connected network is that it is more robust, as there are more paths towards any destination. In a fully connected network there would also be no need for multi-hopping, as there is a direct connection between every node. However, considering that the signal range of mesh routers is limited in practice, implementing a fully connected mesh network is not realistic.

2.2 Localisation

There are many different approaches to determining the location of devices within a network. One such method is by calculating the distance between a device and an access point. This can be achieved through the Subtle Partial Range Aware (SPRA) method. The position of the device can then be found by looking at overlapping ranges of devices using the Ring Overlapping based Localisation (ROL) algorithm [4]. Other methods include Wi-Fi positioning systems (WPS) which make use of Wi-Fi signals to determine the position of a device. They may, for example, make use of the received signal strength indicator (RSSI) between devices and access points to determine the position. Fingerprinting is one of such WPS techniques. With this technique the RSSI from nearby access points at various positions is recorded and the combinations of RSSIs and the corresponding positions, called fingerprints, are stored in a database. The acquisition of data is done in advance, before the network is used for localisation. Once sufficient data is acquired, the position of a device can be determined by comparing its RSSI values with the stored fingerprints and matching it with the position of the fingerprint which is most similar. Another WPS technique is to calculate the distance between the access point and device through Time of Flight (ToF) or Angle of Arrival (AoA) [5].

A downside to the aforementioned methods is that they rely on the location of the access point being known or, in the case of fingerprinting, data has to be collected in advance for localisation to be possible. This impairs the ease of deployment of a network which uses one of these methods, because whenever a network is deployed or a new mesh router is added to the network, new data has to be collected. This is not ideal for implementing a temporary, and easily deployable WMN. This is the reason why these methods are primarily used in indoor scenarios where the access points are statically placed. As the network in this paper will be used in scenarios where there

(11)

is no access to the Internet, which will mainly be the case in outdoor scenarios, we will make use of GPS. GPS was designed to work outdoors and can be used to accurately locate devices within a 4.9m radius [6]. GPS signals may be unreliable in indoor scenarios, however. Assisted GPS (A-GPS) may be used to improve the precision, start up performance, and quality in cases where there is access to an Internet connection or a connection to an Internet Service Provider (ISP). But as this is not the case for a standalone WMN, it cannot benefit from A-GPS.

2.3 Routing protocol

For this network the Better Approach To Mobile ad hoc Networking (B.A.T.M.A.N.) routing protocol is used. More specifically the OSI Layer 2 variant, batman advanced (batman-adv), is used. Layer 2 implies that it operates in the data link layer and is thus transparent to higher level layer protocols such as IPv4, ICMP, TCP or UDP. To the higher level protocols it looks as if there is a direct connection between nodes, even though it might be the case that there are multiple hops between them [7]. B.A.T.M.A.N. is a proactive routing protocol which means that each node holds routing information for all other nodes in the network. This information is updated regularly. This is in contrast to a reactive routing protocol where the routes between nodes are only created when data needs to be sent [8].

The B.A.T.M.A.N. routing protocol differs from most other ad hoc routing protocols in that it is not required that the full route between two nodes is known by a single node. Instead, only the direct neighbour to which packets have to be sent next, i.e. the next hop, is known for each node. This means that none of the nodes know the full routes between nodes and the routing information is decentralised [9].

The B.A.T.M.A.N. protocol works as follows. First the nodes in the network have to be discovered. This is done by broadcasting messages. Each B.A.T.M.A.N. node in the network broadcasts originator messages (OGM) to its direct neighbours. This way, its neighbours are informed of the node’s existence. The neighbours which received this OGM will in turn broadcast it to their direct neighbours. This is done by each node which receives an OGM, thus propagating the message throughout the entire network. Each node in the network keeps track of the number of OGMs it has received from each node. The OGM message format can be seen in table 2.1. A node periodically broadcasts OGMs, incrementing the sequence number by 1 each time. The GW and HNA fields are only used when there is a gateway present in the network, which is not the case for the network in this paper. The routing of packets is determined by the sequence number and TQ fields of the OGM.

bytes 00 01 02 03 00-03 Version Flags TTL GW Flags 04-07 Sequence Number GW Port 08-11 Originator Address

11-15 Previous Sender Address 16-19 TQ HNA Length ...

Table 2.1: OGM format [10]

In order to determine the link over which packets should be sent, the Transmit Quality (TQ) is calculated. This is the probability of a successful transmission towards a neighbouring node. To calculate this, the Receive Quality (RQ) and Echo Quality (EQ) have to be known. What these qualities entail can be seen in figures 2.2, 2.3, and 2.4. The TQ is not equal to the RQ because, when it comes to wireless links, incoming and outgoing links are asymmetric and are not necessarily of the same quality. It could even be that a link is unidirectional, where it is only possible to either receive from or transmit to a node, but not both.

(12)

The RQ is determined by the number of OGMs received from a direct neighbour. The EQ is determined by the number of OGMs received which the node itself has sent and were sent back to it. Counting OGMs is done by means of a sliding window. OGMs with a sequence number which fall within the sliding window range are counted towards the link quality. When an OGM with a sequence number that lies outside the sliding window is received, the sliding window is slid to this new number. The old OGMs with a sequence number that now fall outside the sliding window are no longer counted towards the link quality. As can be seen from table 2.1, the sequence number is 16 bits long. This means that the range of possible sequence numbers lies between 0 and 216_{. The default size of the sliding window is 8 [11]. By counting with a sliding}

window the link quality is updated constantly, not relying too heavily on past results.

Figure 2.2: Receive Quality (RQ) from A

to B [10] Figure 2.3: Echo Quality (EQ) from A to B [10]

Figure 2.4: Transmit Quality (TQ) from A to B [10]

When the RQ and EQ are known, the TQ can be calculated using the following formula: T Q = EQ

RQ

This is the TQ of a single hop, i.e. the TQ towards a direct neighbour, called the local TQ. To calculate the TQ towards a node which is further than a single hop away, called the global TQ, the TQ field in the OGM message is used. Initially, a node will broadcast its OGM with the TQ field set to the maximum value. A node which receives this OGM will first calculate its local TQ towards the node it received the OGM from, as previously described. It will then calculate the global TQ, making use of the local TQ and the TQ received from the OGM field, using the following formula:

T Qglobal= T Qlocal∗ T Qpacket

(13)

Figure 2.5: Calculation of the global TQ towards a node which is further than a single hop away [10]

The TQ calculation is done for all links over which an OGM was received. Packets are routed over the link with the highest TQ.

It can occur that the TQ of routes which have the same destination are equal. In this case the route with the lowest number of hops is chosen. The OGMs do not have a field to determine the number of hops. Instead, a hop penalty is applied to the TQ. The TQ is lowered by a fixed amount at every node it passes through. As a result, the route with the lowest number of hops will have a higher TQ, even though the link quality is the same [10].

2.4 Related work

Various studies have been conducted, analysing the performance of WMNs. In [12] the perfor-mance of a WMN using the B.A.T.M.A.N. protocol was analysed for various hops. Throughput was measured for TCP transmission showing a significant drop at higher hop counts. Jitter and packet loss were measured for UDP transmission. It showed a significant increase in packet loss at 3 hops as well as an increase in jitter. It is explained that this is not a limitation for commu-nication in cases where the bandwidth requirement is lower, packet loss is allowed and delay is tolerated. In [13] the same metrics were tested for UDP, also showing that the performance is impacted significantly at higher hop counts.

Comparisons of different routing protocols have also been made for WMNs. The B.A.T.M.A.N., Optimised Link State Routing (OLSR), and BABEL routing protocols were compared using a real-world testbed in [14], which found that B.A.T.M.A.N. and BABEL both outperform OLSR. They report that B.A.T.M.A.N. is the most stable and has the highest packet delivery, while BABEL has the fastest route recovery time and the highest multi-hop bandwidth.

(14)

(15)

CHAPTER 3

Design

3.1 Network design

The network is designed as follows. In order to create the backbone of the network, ad hoc connections have to be made between the mesh routers. Besides this, mesh clients should be able to connect to the network by connecting to one of the mesh routers. To achieve this, the mesh routers will set up an access point (AP) with which the mesh clients can establish a con-nection. In the general case, an AP is not needed per se, as mesh clients could also connect to a mesh router directly through ad hoc connections. In this case however, we assume that the mesh clients will be mobile phones running on the Android OS. Wi-Fi ad hoc connections are not supported for these devices [15], which is why an AP is needed. All APs have the same Service Set Identifier (SSID) and password to make roaming between APs easier.

Each device in the network has to have a unique IP address such that Wi-Fi connections can be established and packets can be sent to it. The mesh routers should have two unique IP addresses, one used in the ad hoc communication between mesh routers and the other used for the AP. For this reason the mesh router should have two separate wireless network interfaces (WNICs). Both addresses are statically assigned before the network is set up. The IP addresses are as follows. For the WNIC which is used to communicate with other mesh routers, the IP address is set to 172.17.0.x with a netmask of 255.255.255.0, i.e. the x value ranges from 1 to 254. The IP address for the WNIC which establishes the AP, is set to 172.17.x.254. The x ranges from 1 to 254, here as well.

Finally, mesh clients should also have an IP address assigned to them. Because mesh clients will be roaming through the network, they should have a dynamic IP address assigned to them. Each mesh router runs a dynamic host configuration protocol (DHCP) server to assign unique IP addresses to each mesh client that connects to its AP. The mesh clients are assigned an IP address in the range of 172.17.x.y, where x depends on the AP which they are connected to and y ranges from 1 to 254. Thus each mesh router can have at most 254 mesh clients connected to it. The reason that each mesh router runs its own DHCP server, as opposed to there being one DHCP server in the entire network, is that if there would be only one DHCP server, it would be a single point of failure in the network.

An overview of a possible network setup, alongside the devices’ IP addresses, can be seen in figure 3.1.

(16)

Figure 3.1: An overview of a possible WMN showing the IP addresses of the various devices. Red are connections to an AP, blue are ad hoc connections

3.2 Network hardware

The WMN implemented for this research will be created using multiple Raspberry Pi 3s, which are small singleboard computers (see figure 3.2). These will play the role of mesh routers and will form the backbone of the network. One of the reasons the Raspberry Pi 3 was chosen for this, is that it is easily adaptable and configurable. External Wi-Fi adapters can be added via its USB ports. By running the device in a headless state it can run without the need for any manual input. Another advantage is that the device is small and thus portable and easily deployable. Furthermore, while regular routers only forward packets, a Raspberry Pi 3 is able to save the contents of these packets, create and send its own packets, or act like a server. Lastly, it is cost-effective compared to other devices with the same functionalities. A disadvantage of this device is that it has to have access to a power outlet, or should be connected to a power bank in order to function, which may not always be available.

In order to set up a Raspberry Pi 3 as a mesh router, it should be able to connect to other mesh routers within the network, as well as create an AP for mesh clients to connect to the WMN. To achieve this, two wireless network interface controllers (WNICs) are needed. One for communication between the mesh routers and another one for setting up an AP. The Raspberry Pi 3 comes with a built-in Wi-Fi transceiver (transmitter and receiver) which will be used to set up an AP. An external Wi-Fi adapter (see figure 3.3) is added to the device, which is used to establish ad hoc connections between mesh routers, forming the backbone of the WMN.

(17)

Figure 3.2: Raspberry pi 3 _{Figure 3.3: Wi-Fi adapter}

Other devices can connect to the network by connecting to an AP set up by one of the mesh routers. Any device with a Wi-Fi interface is able to connect to this AP but for this implementation we will assume that the mesh clients are mobile phones. The mobile phone should be equipped with a Wi-Fi transceiver (WNIC) to connect to the AP. It should also be equipped with GPS, to be able to track and share its coordinates over the network. It is required that the mobile phone runs on the Android OS, as the application which was made to send location data over the network is not supported for iOS.

3.3 Wireless communication protocol

In order to communicate between the devices which make up the network, a suitable wireless data communication protocol should be selected. Ideally the protocol should have a large signal range, such that the localisation of devices is possible over a large area while minimising the amount of hardware needed. This way, the network implementation can remain fiscally feasible. Furthermore, it should allow for many connections to be established at the same time, enabling a scalable network. Additionally, a high signal rate is desired to ensure that large amounts of data can be sent over the network in a short amount of time.

There are many wireless data communication protocols. Wi-Fi, Bluetooth, Zigbee, and UWB are some examples of technologies with which data can be communicated wirelessly. Out of these, Zigbee was created with mesh networking in mind, allowing for many connections to be made at once and having a larger signal range than Bluetooth or UWB, for example [16]. While some mobile phones have built-in Zigbee transceivers, most do not. Virtually all mobile phones have built-in Bluetooth and Wi-Fi transceivers however, making these two technologies suitable for this network.

While Bluetooth has a lower power consumption than Wi-Fi, Wi-Fi significantly outperforms Bluetooth when it comes to signal rate, signal range and the maximum number of connections which can be made, as can be seen in table 3.1 [16]. The low signal range of Bluetooth would mean that the number of mesh routers needed to cover the same area would be far larger com-pared to Wi-Fi. This would in turn increase the cost of the network and the number of hops needed to reach a device in the network significantly. Furthermore, the low power consumption of Bluetooth does not have a high priority, as the battery life of most mobile phones is sufficient and could be extended, if necessary, by making use of power banks, for example. Considering this, we will make use of Wi-Fi as the wireless data communication protocol for this network.

(18)

Bluetooth Wi-Fi Signal rate 1 Mb/s 54 Mb/s Signal range 10 m 100 m Maximum number of connections 8 2007

Table 3.1: Signal rate, signal range and maximum number of connections for Bluetooth and Wi-Fi [16]

There are many Wi-Fi standards. The ones supported by the built-in WNIC of the Rasp-berry Pi 3 used in this research are the IEE 802.11a/b/g/ad standards [17]. IEEE 802.11b and 802.11g both operate in the 2.4GHz frequency band, IEEE 802.11a operates in the 5GHz fre-quency band, and IEE 802.11ad operates in the 60GHz frefre-quency band. The 2.4GHz frefre-quency band is shared with other communication protocols such as Bluetooth and is used often for Wi-Fi communication. Because this frequency band is used often, communications could suffer from interference which could in turn lead to packet loss. Nonetheless, we have still chosen for IEEE 802.11g, operating in the 2.4GHz frequency band, because a lower frequency allows for a larger signal range. Having a large signal range is paramount for the implementation of this network, as previously mentioned. This also makes it more efficient, were the network implemented in indoor scenarios, as lower frequencies move through objects more easily [18]. Lastly, IEEE 802.11g was chosen because it is backwards compatible with the IEEE 802.11b standard.

The 2.4GHz frequency band is further divided into fourteen channels. The channels alongside their frequencies can be seen in table 3.2. A channel occupies a bandwidth of about 20MHz. It is recommended to choose non-overlapping channels to decrease the likelihood of interference [19]. For this reason, the APs operate in channel 7 and ad hoc connections between mesh routers operate in channel 1. Channel Frequency (MHz) 1 2412 2 2417 3 2422 4 2427 5 2432 6 2437 7 2442 8 2447 9 2452 10 2457 11 2462 12 2467 13 2472 14 2484

Table 3.2: The channels of the 2.4GHz frequency band [20]

3.4 Routing protocol

To efficiently send packets over the network, a routing protocol is needed. For this, the Better Approach To Mobile ad hoc Networking advanced (batman-adv) protocol was chosen. This protocol is described in section 2.3. The reason for choosing this protocol over others is that it is reliable and stable according to [14]. More so than other protocols such as OLSR and Babel. Besides this, it is easy to implement in Debian-based operating systems.

(19)

CHAPTER 4

Implementation

4.1 Setting up the network

When a mesh routers boots up, it first starts a server socket on port 1234 to listen for incoming TCP connection requests from other newly joined mesh routers. It also starts a separate server socket on port 2345 to listen for incoming TCP connection requests from mesh clients. Next, it pings all IP addresses in the mesh router domain, i.e. all IP addresses from 172.17.0.1 to 172.17.0.254, to search for other mesh routers which have already been set up. If other mesh routers were found, it tries to establish a TCP connection with them. After this, the mesh router is set up and ready to accept any incoming TCP connections.

Every mesh router keeps track of the following:

• Mesh routers: a list of all other mesh routers connected to this mesh router. Their IP address is saved alongside their socket.

• Local clients: a list of all mesh clients which are connected directly to this mesh router. Their MAC address and their socket are saved here.

• Non-local clients: a list of all mesh clients which are not connected directly to this mesh router. The MAC address of the mesh client is saved alongside the socket of the mesh router to which that client is connected.

Mesh clients only keep track of all other mesh clients in the network.

A mesh router establishes a TCP connection with all other mesh routers in the network. A mesh client only has a TCP connection with the mesh router it is connected to. Because the IP address of a mesh client changes whenever it roams between APs,

Mesh clients are identified by their media access controls (MAC) address. A MAC address is a unique identifier of a network interface controller. Mobile phones running on the Android OS have no way of knowing their own MAC address, as this functionality was removed from the Wi-Fi and Bluetooth APIs in Android 6.0 [21]. To circumvent this, a mesh clients which joins the network requests its own MAC address to the mesh router it connects to. By pinging the mesh client and looking into the ARP cache, the mesh router finds the MAC address of the mesh client and sends it back.

4.2 Messages

To differentiate between messages, each message contains a type field. The types of messages which can be sent are: initial messages, new client messages, broadcast message, unicast

(20)

mes-sages, and disconnect messages. All message types, except for initial mesmes-sages, contain a times-tamp. When a mesh router receives a message other than an initial message or a disconnect message, it first checks if it is more recent than its previously received message from that client before sending it to any other device in the network. Each message also contains a sender field which specifies the mesh client which originally sent the message identified by their MAC address. Initial messages are sent by mesh clients to request their MAC address. When a mesh router receives this message it will ping the IP address from which it received it form. By doing this, the IP address will be registered in its ARP cache from which it can retrieve the MAC address. The MAC address will then be sent back to the requester.

New client messages are sent whenever a client connects to a mesh router. This message is sent to all devices within the network. When such a message is received, the receiving device will add the client to its set of known clients. The mesh router will add it to its set of local clients or non-local clients depending on if the message was received directly from the client itself or from another mesh router.

Broadcast messages are sent to all other devices in the network. These messages contain the GPS data in the form of longitude and latitude of the device which sent it. A mesh router will save the most recent broadcast message of each device. This is done such that, when a new mesh clients connects to a mesh router, the mesh router can send all known positions of all known mesh clients directly to the newly connected mesh client.

Unicast message are sent to only a single mesh client in the network. For this reason, the message contains a receiver. This type of message contains the GPS data of the original sender, just like broadcast messages.

Disconnect messages are sent when a mesh client disconnects from a mesh router. The mesh router will send a disconnect message to all other mesh routers in the network, to inform them that the mesh client has disconnected. The mesh routers which receive this disconnect message remove the mesh client from their known non-local clients list and relay the message to their local clients.

The messages are sent as JSON strings. An advantage of JSON strings is that they are easily generated and parsed in many different programming languages. Thus, by using JSON strings, data can be sent and received regardless of the programming language being used. The JSON strings are encoded in utf-8, meaning that each character is 1 byte long.

As an example, a broadcast message looks as follows:

{"lat":52.2434574,"lon":4.7085544,"mac":"00:ae:fa:e2:9b:11","time":1559880461150,"type":"1"}

It has 92 characters and is therefore 92 bytes long.

4.3 Application

An Android app is created for mobile phones to display the location of other devices in the network on a map. When the app is started, a scan for nearby Wi-Fi networks will be started. As all APs in the network have the same SSID and password, a mesh client can scan for nearby networks to find the WMN. Once an AP with the correct SSID and password is found, it will try to connect to it. When the connection is successful, a TCP connection is set up with the mesh router. After the TCP connection has been established, a mesh client can send messages to the mesh router.

(21)

By implementing a location listener, the mobile phone will listen for changes in its GPS data. The GPS data will update when the device has moved at least 7 meters and at least 1 second has elapsed. Once it finds that its location has changed, it creates a broadcast message containing its GPS information that it will send to the mesh router it is connected to. The mesh router will in turn propagate this message to the rest of the network. When roaming from one AP to another, a new TCP connection is established automatically with the new mesh router. All communication is done over TCP. This is to ensure that data will arrive at its destination. This is especially important in the case of new client messages and disconnect message. If these types of messages were lost, it could lead to devices not knowing that other devices have disconnected or joined the network. Another reason why TCP is used over a different protocol, such as UDP, is that UDP communication is most often used for real-time systems, such as Voice over IP (VoIP) or video streaming, where some packet loss is permitted. For such applications, multiple packets are sent every second. As GPS information will not change this rapidly, it is not needed to send as many packets. It is more important that the information will be communicated reliably.

(22)

(23)

CHAPTER 5

Experiments

To test the performance of the WMN, it is tested for round-trip time (RTT), throughput, packet loss, and jitter. Testing for throughput, packet loss and jitter is done using the iperf3 tool. This tool makes it possible to test various performance metrics for both UDP and TCP transmissions. A server can be started on the receiving node and a client can be started on the sending node. The client will generate packets to send to the server while various metrics are monitored. RTT is measured by using the ping command.

The experiments are carried out for various numbers of hop counts. The metrics are either measured for a single hop from a mesh client towards a mesh router, denoted as AP hop (figure 5.1), or from a mesh router to another mesh router (figure 5.2). We will look at the effect the number of hops has on the various tested metrics. It is expected that, when the number of hops increases, the network’s performance decreases. With a larger number of hops there are more mesh routers active, which could lead to interference and thus higher packet loss. Furthermore, bandwidth degradation occurs at higher hop counts with a degradation of _n1 in the best case scenario and ₂n−11 in the worst case scenario [22]. Lastly, as packets have to travel further, and

have to be processed by each mesh router they pass through, the RTT is also expected to increase.

Figure 5.1: A hop from a mesh client to the

AP of a mesh router Figure 5.2: Multi-hop from mesh router to mesh router

Although the implementation described in chapter 4 makes use of TCP, it is also interesting to look at the performance of the network when other protocols are used, such as UDP. This way, we can also determine if the network is viable if it were used for other applications. This is why we also conduct experiments for transmissions over UDP.

The experiments were conducted in an indoor setting at the Amsterdam Science Park building of the University of Amsterdam. The set up of the network can be seen in figure 5.3. The network was set up in an outdoor setting as well. This was done at the Amsterdam Open Air festival. The network setup for the outdoor setting can be seen in figure 5.4. The signal strengths of each link can be seen in these figures, expressed in dBm. The higher the dBm, the better the signal strength. As wireless communication links are asymmetrical, the dBm of both directions is shown.

(24)

Figure 5.3: The indoor network set up on which the experiments were carried out

Figure 5.4: The outdoor network set up on which the experiments were carried out The reason the network was implemented at the Amsterdam Open Air festival, was to analyse its performance in crowded areas. That is, in areas where a large number of devices (mobile phones) are active. It is important to test this because in these situations, the large number of device will cause cellular service to not function properly, which in turn creates the need for a local network. It is thus important that in these situations, the WMN is still able to function properly, i.e. there has to be no significant detriment to the network’s throughput, round trip time, packet loss, jitter or signal strength. The connections should also remain stable.

5.1 Round trip time

Round trip time (RTT) is the time it takes for a packet to be sent to a destination node and from the destination back to the source. The RTT can be measured by pinging the destination device. The ping command sends an Internet Control Message Protocol (ICMP) packet of 64 bytes to the destination. Once it arrives at the destination it will be sent back to the source and the RTT can be calculated. To measure the RTT, 10000 ping operations were performed. The average RTT of all pings was taken.

5.2 Throughput

Throughput is defined as “the maximum rate at which none of the offered frames are dropped by the device.” by RFC 1242 [23]. The throughput is measured using the iperf3 tool. To measure the throughput, packets with a size of 131072 bytes are sent over the network for 30 minutes. The server at which these packets arrive will calculate the throughput in bytes per second.

5.3 Packet loss

Packet loss is the percentage of packets which has been lost of the total number of packets sent. Packet loss can occur due to network congestion or radio frequency interference, among other things. TCP guarantees that all packets will arrive at their destination. If a packet is lost, it will retransmit the packet until it successfully arrives at the destination. Retransmission will take up bandwidth, which is undesirable. With other protocols, such as UDP and ICMP, lost packets

(25)

will not be retransmitted.

Packet loss is measured for UDP by sending 10000 packets with a size of 1500 bytes and calculating the percentage of lost packets. This is repeated ten times. A size of 1500 bytes is chosen as this is the maximum payload size of an ethernet frame.

5.4 Jitter

Jitter is defined as the variation in packet delay. This metric is especially important in real time applications such as VoIP or video streaming. When there is a large variation in packet delay, it can cause these services to not function properly, affecting the quality of the service.

Jitter will be measured in the same way as packet loss. It will be measured for UDP by sending 10000 packets with a size of 1500 bytes. This is repeated ten times.

5.5 Signal strength

The quality of a link is also important to take into consideration when analysing the performance of a network. To determine the effect the signal strength has on the performance of the network, the aforementioned experiments are carried out for a single hop link with a signal strength of -85 dBm. The signal strength is lowered by placing the mesh routers farther from each other. The results are then compared with the results from the first mesh router to the second mesh router in figure 5.3. This is a single hop link with a signal strength of -47 dBm. A higher dBm, i.e. a dBm closer to 0, implies a better signal strength.

A higher signal strength implies a higher signal-to-noise ratio (SNR). According to [24], a higher SNR corresponds to a lower percentage of packet loss and a smaller delay (and thus a faster RTT). According to the ShannonHartley theorem, a higher SNR also indicates a higher theoretical maximum data rate. Because of this we expect the link with a higher signal strength to perform better for the monitored metrics.

(26)

(27)

CHAPTER 6

Results

In this chapter the results of the experiments of chapter 5 are shown.

6.1 Round trip time

The results of the RTT experiments are shown here. The average RTT in milliseconds was taken over 10000 ICMP pings. The standard deviation is shown in red.

Figure 6.1: The results of the round trip time experiment as described in section 5.1 for the indoor scenario (figure 5.3)

6.2 Throughput

The results of the throughput experiments are shown here. The average throughput in Mbits/sec is shown for sending packets of a size of 131072 bytes over a period of 30 minutes. The standard deviation is shown in red.

(28)

Figure 6.2: The results of the throughput experiment as described in section 5.2 for the indoor scenario (figure 5.3)

6.3 Packet loss

The results of the packet loss experiments are shown here. The packet loss in percentage of the total packets sent is taken for sending 10000 packets of a size of 1500 bytes. This process was repeated ten times and the average packet loss was calculated. The standard deviation is shown in red.

Figure 6.3: The results of the packet loss experiment as described in section 5.3 for the indoor scenario (figure 5.3)

(29)

6.4 Jitter

The results of the packet loss experiments are shown here. The average jitter in miliseconds is taken for sending 10000 packets of a size of 1500 bytes. This process was repeated ten times and the average jitter was calculated. The standard deviation is shown in red.

Figure 6.4: The results of the jitter experiment as described in section 5.4 for the indoor scenario (figure 5.3)

(30)

6.5 Signal strength

The average RTT, throughput, packet loss and jitter were all calculated for a single hop link with a signal strength of -47 dBm, as well as for a single hop link with a signal strength of -85 dBm. A higher dBm, i.e. a dBm closer to 0, implies a better signal strength. Each metric was calculated in the same way as the previous four experiments. The results can be seen in the following four graphs. The standard deviation is shown in red.

Figure 6.5: Comparison of the performance for a single hop with a signal strength of -47 dBm versus -85 dBm

(31)

CHAPTER 7

Discussion

As can be seen from the results from the experiments done in the indoor setting, the performance of the network is significantly impacted by the number of hops. The throughput is roughly halved by each hop as can be seen in figure 6.2. This is as expected when we assume the worst case scenario of a bandwidth degradation of ₂n−11 as mentioned in [22].

There is also a significant increase in packet loss, at four hops there is an average packet loss of nearly 50% (see figure 6.3).

The RTT also increases with each hop as can be seen in figure 6.1. It increases by roughly 1 ms per hop. The RTT is still well below the maximum one way transmission delay of 400 ms recommended in [25].

Finally, the jitter increases at each hop as well, as can be seen in figure 6.4. At the last hop the jitter stays almost equal, however.

In figure 6.5, the difference in the various performance metrics can be seen. It compares the metrics for a single hop with a signal strength of -47 dBm to a single hop with a signal strength of -85 dBm. As can be seen from the figure, the signal strength does affect the performance metrics. The single hop with the worse signal strength performs significantly worse for all tested metrics. This is as expected as described in section 5.5.

In the case of the experiments in the outdoor setting, the connections became more unstable as the area in which the network was deployed became more crowded, i.e. more devices were active. One reason for this might be because of devices scanning for nearby Wi-Fi networks. A scan can be performed passively, by listening for beacon frames. These are frames transmitted by APs to announce their presence. A scan can also be performed actively. This is done by sending a probe request to nearby APs, which will in turn send a probe response containing information about the AP to be able to connect to it. These probe requests are sent over the 2.4GHz fre-quency band. According to [18] a mobile device sends, on average, 55 probe requests per hour. When there are many mobile devices in the same area, the overhead of the probe requests can lead to network degradation. Another reason for the unstable connections might be that there are more obstacles, i.e. people, which the signals have to move through. This could prevent the signals from reaching other mesh routers. The experiments for testing the throughput, packet loss, RTT and jitter could not be carried out because of the unstable connections.

The significant decrease in throughput at higher hop counts, as well as at lower signal strength links, shows that this type of network is not ideal for communication over a large area. This is because, when a large area has to be covered, there should either be more mesh routers, causing the number of hops to increase, or the mesh routers should be placed farther from each other, causing the signal strength of the links between the mesh routers to decrease.

In the current implementation a broadcast message containing the GPS data of the device is sent when the device moves at least 7 meters and at least 1 second has elapsed, as explained in

(32)

chapter 4. As these broadcast messages are only 92 bytes long, the throughput seen in figure 6.2 for a hop count of 3 and 4 (roughly 1 Mbit/sec), is still sufficient to send these messages over the network.

The large packet loss and jitter at higher hop counts makes it unlikely that this type of network could be implemented for other UDP applications such as video streaming or VoIP. The maximum acceptable jitter for VoIP is 30 ms and the maximum acceptable packet loss is 1 percent according to Cisco [26]. From the results in figure 6.3 it is apparent that the minimum packet loss requirement is not met at hop counts higher than 2. In figure 6.5 it can be seen that the minimum jitter requirement is also not met when a link has a low signal strength. In this case the jitter is more than 100 ms, while the maximum acceptable jitter is 30 ms.

(33)

CHAPTER 8

Conclusion

A WMN was implemented to locally communicate GPS data over TCP to other devices within the network. Experiments were performed to determine the throughput, jitter, packet loss and round-trip time for multiple hop counts. From the test results we have seen that the design of the network is not suitable for a large scale implementation. The results show that at higher hop counts and at low signal strengths, i.e. larger distances between mesh routers, the throughput, jitter, and packet loss are all significantly impacted.

It was also found that the connectivity of the network degrades significantly in heavily crowded areas. That is, in areas where a large number of devices is active. So much so that the connec-tions become unstable and are lost altogether. This is most likely due to the overhead of probe requests sent by actively scanning mobile devices, which are looking for nearby Wi-Fi networks. This means that the network is also not suitable to be implemented in crowded areas.

Considering the high packet loss at higher hop counts and the high jitter for low signal strength links, this type of network is also not suitable for other applications which make use of UDP, such as VoIP or video streaming.

Ultimately, the WMN described in this study is only suited to be implemented as a smaller scale network, considering the significant performance decrease at higher hop counts.

8.1 Future research

As discussed, there is a trade off between the network performance and the number of hops. There is also a trade off between the network performance and the signal strength. An evalu-ation could be made as to what combinevalu-ation of hops and signal strength is optimal. That is, when implementing a large network, evaluating if it is more favorable to have multiple hops each with a high signal strength, or if it more favorable to have fewer hops with a lower signal strength. A different design approach could also be taken. The WMN could be implemented with a routing protocol other than batman-adv. A comparison could then be made between the perfor-mance of the different routing protocols which were tested.

(34)

(35)

Bibliography

[1] Marius Portmann. “Wireless mesh networks for public safety and disaster recovery appli-cations”. In: WIRELESS MESH NETWORKING (2006), p. 545 (cit. on p. 7).

[2] Hassnaa Moustafa et al. “A panorama on wireless mesh networks: Architectures, appli-cations and technical challenges”. In: International Workshop on Wireless Mesh: Moving towards Applications, WiMeshNets. 2006 (cit. on pp. 9, 10).

[3] Ian F Akyildiz and Xudong Wang. “A survey on wireless mesh networks”. In: IEEE Com-munications magazine 43.9 (2005), S23–S30 (cit. on p. 9).

[4] Jingxuan Wang et al. “A gps-free wireless mesh network localization approach”. In: 2009 WRI International Conference on Communications and Mobile Computing. Vol. 2. IEEE. 2009, pp. 444–453 (cit. on p. 10).

[5] Chouchang Yang and Huai-Rong Shao. “WiFi-based indoor positioning”. In: IEEE Com-munications Magazine 53.3 (2015), pp. 150–157 (cit. on p. 10).

[6] GPS Accuracy How accurate is GPS? https://www.gps.gov/systems/gps/performance/ accuracy/. Accessed: 2019-05-20 (cit. on p. 11).

[7] Open-Mesh B.A.T.M.A.N. advanced. https://www.open-mesh.org/projects/batman-adv/wiki/Wiki. Accessed: 2019-05-22 (cit. on p. 11).

[8] Surendra H Raut and Hemant P Ambulgekar. “Proactive and reactive routing protocols in multihop mobile ad hoc network”. In: International Journal of Advanced Research in Computer Science and Software Engineering 3.4 (2013) (cit. on p. 11).

[9] OpenMesh B.A.T.M.A.N. concept. https : / / www . open mesh . org / projects / open -mesh/wiki/BATMANConcept. Accessed: 2019-05-22 (cit. on p. 11).

[10] Open-Mesh B.A.T.M.A.N. IV. https://www.openmesh.org/projects/batman- adv/ wiki/BATMAN_IV. Accessed: 2019-05-22 (cit. on pp. 11–13).

[11] Better Approach To Mobile Ad-hoc Networking (B.A.T.M.A.N.) draftwunderlichopenmeshmanetrouting00. https : / / tools . ietf . org / html / draft wunderlich openmesh -manet-routing-00#section-4.2. Accessed: 2019-05-22 (cit. on p. 12).

[12] Luca Davoli et al. “Design and experimental performance analysis of a BATMAN-based double Wi-Fi interface mesh network”. In: Future Generation Computer Systems 92 (2019), pp. 593–603 (cit. on p. 13).

[13] Edmundo Chissungo, Edwin Blake, and Hanh Le. “Investigation into Batman-adv protocol performance in an indoor mesh potato testbed”. In: 2011 Third International Conference on Intelligent Networking and Collaborative Systems. IEEE. 2011, pp. 8–13 (cit. on p. 13). [14] Mehran Abolhasan, Brett Hagelstein, and JC-P Wang. “Real-world performance of current proactive multi-hop mesh protocols”. In: 2009 15th Asia-Pacific Conference on Communi-cations. IEEE. 2009, pp. 44–47 (cit. on pp. 13, 18).

[15] Android Developers, Create P2P connections with Wi-Fi. https://developer.android. com/training/connect-devices-wirelessly/wifi-direct. Accessed: 2019-06-01 (cit. on p. 15).

(36)

[16] Jin-Shyan Lee, Yu-Wei Su, Chung-Chou Shen, et al. “A comparative study of wireless protocols: Bluetooth, UWB, ZigBee, and Wi-Fi”. In: Industrial electronics society 5 (2007), pp. 46–51 (cit. on pp. 17, 18).

[17] Setting up a Raspberry Pi as an access point in a standalone network (NAT). https : //www.raspberrypi.org/documentation/configuration/wireless/access-point.md. Accessed: 2019-05-23 (cit. on p. 18).

[18] Julien Freudiger. “How talkative is your mobile device?: an experimental study of Wi-Fi probe requests”. In: Proceedings of the 8th ACM Conference on Security & Privacy in Wireless and Mobile Networks. ACM. 2015, p. 8 (cit. on pp. 18, 31).

[19] Eduard Garcia Villegas et al. “Effect of adjacent-channel interference in IEEE 802.11 WLANs”. In: 2007 2nd international conference on cognitive radio oriented wireless net-works and communications. IEEE. 2007, pp. 118–125 (cit. on p. 18).

[20] IEEE Standard for Information technology Telecommunications and information exchange between systems Local and metropolitan area networks Specific requirements Part 11: Wire-less LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications. IEEE standards document. IEEE Computer Society (cit. on p. 18).

[21] Android 6.0 changes Access to Hardware Identifier. https://developer.android.com/ about/versions/marshmallow/android- 6.0- changes.html#behavior- hardware- id. Accessed: 2019-05-25 (cit. on p. 19).

[22] Hassan Hadi Latheeth AL-Maksousy. “Performance Analysis of Multi-hop Wireless Net-works”. PhD thesis. Kent State University, 2012 (cit. on pp. 23, 31).

[23] RFC 1242 Benchmarking Terminology for Network Interconnection Devices. https : / / tools.ietf.org/html/rfc1242. Accessed: 2019-05-25 (cit. on p. 24).

[24] Tomas Zelinka et al. “Adaptive multi-path Telecommunications Solutions for ITS”. In: Journal of Systemics, Cybernetics and Informatics 9.1 (2011), pp. 14–20 (cit. on p. 25). [25] ITU-T SERIES G: TRANSMISSION SYSTEMS AND MEDIA, DIGITAL SYSTEMS

AND NETWORKS International telephone connections and circuits General Recommen-dations on the transmission quality for an entire international telephone connection. https: //www.itu.int/rec/T-REC-G.114/en. Accessed: 2019-06-07 (cit. on p. 31).

[26] Cisco: Quality of Service Design Overview. http : / / www . ciscopress . com / articles / article.asp?p=357102. Accessed: 2019-06-10 (cit. on p. 32).

Device localisation through wireless mesh networks: A performance analysis

Bachelor Informatica