Institutionen för datavetenskap
Department of Computer and Information Science
Final thesis
Signal-Aware Route Planning
by
Tim Hultman
LIU-IDA/LITH-EX-G--16/005--SE
2016-05-17
Linköping University
Department of Computer and Information Science
Final Thesis
Signal-Aware Route Planning
by
Tim Hultman
LIU-IDA/LITH-EX-G--16/005-SE
2016-05-17
Supervisor: Abdeldjalil Boudjadar Examiner: Mikael Asplund
På svenska
Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare –
under en längre tid från publiceringsdatum under förutsättning att inga
extra-ordinära omständigheter uppstår.
Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner,
skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat för
ickekommersiell forskning och för undervisning. Överföring av upphovsrätten
vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av
dokumentet kräver upphovsmannens medgivande. För att garantera äktheten,
säkerheten och tillgängligheten finns det lösningar av teknisk och administrativ
art.
Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i
den omfattning som god sed kräver vid användning av dokumentet på ovan
beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan
form eller i sådant sammanhang som är kränkande för upphovsmannens litterära
eller konstnärliga anseende eller egenart.
För ytterligare information om Linköping University Electronic Press se
förlagets hemsida
http://www.ep.liu.se/In English
The publishers will keep this document online on the Internet - or its possible
replacement - for a considerable time from the date of publication barring
exceptional circumstances.
The online availability of the document implies a permanent permission for
anyone to read, to download, to print out single copies for your own use and to
use it unchanged for any non-commercial research and educational purpose.
Subsequent transfers of copyright cannot revoke this permission. All other uses
of the document are conditional on the consent of the copyright owner. The
publisher has taken technical and administrative measures to assure authenticity,
security and accessibility.
According to intellectual property law the author has the right to be
mentioned when his/her work is accessed as described above and to be protected
against infringement.
For additional information about the Linköping University Electronic Press
and its procedures for publication and for assurance of document integrity,
please refer to its WWW home page:
http://www.ep.liu.se/Abstract
Modern vehicles have an increasing number of advanced features requiring network coverage in order to function properly. In order to facilitate the requirements of such features and allow more advanced applications, we con-sider the possibility of planning routes that take signal strength into consid-eration. Previous work have shown the relationship between TCP through-put/goodput and signal strength. In this thesis signal-aware route planning is presented, implemented, and validated. Crowd-sourced map and signal data (3G) from two sources is used for building a signal coverage map. The signal and map data is validated in a field experiment, where routes were travelled while measuring the signal strength. The field experiment showed gains in signal characteristics when deviating from the shortest possible path. The average signal strength increased by 11 dBm between algorithms and the shortest possible path. Lastly, routes were planned for all possible sources and destinations in a given urban area. The results of this calculation con-firms the patterns found in the field experiment.
Acknowledgements
I would like to thank my examiner Mikael Asplund for the thesis topic and invaluable insights along the way, as well as the assistance with the related paper, and company at PerCom 2016. I also would like to thank my super-visor Abdeldjalil Boudjadar for providing great feedback and keeping me on track with my thesis work, and also for the assistance with the related paper. And thanks for the cake!
I want to thank all the members at RTSLAB for listening to my CASPer presentation and giving their feedback, which was much appreciated. Thanks to Ekhiotz Vergara for the help with the testing and general insights into the subject. Thanks to CENIIT project 14.04 for supporting the related paper. I also want to extend my thanks to the team behind OpenSignal for giving me increased access to their data, without which this thesis would have had to be much smaller in scale. Lastly, I want to thank my family for their support and my brother for putting up with me.
Contents
1 Introduction 2 1.1 Motivation . . . 2 1.2 Problem Definition . . . 3 1.3 Goals . . . 3 1.4 Limitations . . . 4 1.5 Methodology . . . 4 2 Background 6 2.1 Related Works . . . 62.2 Obtaining Map Data . . . 7
2.2.1 OpenStreetMap . . . 7
2.2.2 XML Layout for Map Features . . . 7
2.3 Obtaining Signal Data . . . 10
2.3.1 OpenSignal . . . 10
2.3.2 NetworkStats API . . . 10
2.3.3 Signal Data Response Details . . . 11
2.4 Graphs and Shortest-path Algorithms . . . 11
2.4.1 Graph properties . . . 11
2.4.2 Dijkstra’s algorithm for finding shortest paths . . . 12
2.4.3 Applied Optimization Techniques . . . 13
3 Graph and Signal Map 15 3.1 Building a Graph from Map Data . . . 15
3.1.1 Parsing XML . . . 16
3.1.2 Detecting Intersections . . . 16
3.1.3 Creating Vertices . . . 17
3.1.4 Creating Edges . . . 18
3.1.5 Physical Properties of Edges . . . 19
3.1.6 Summary . . . 19
3.2.1 Calculating Box Sizes . . . 21
3.3 Sample Size Values . . . 24
3.3.1 Calculating Center Points . . . 26
3.3.2 Requesting Bounding Boxes . . . 27
3.3.3 Summary . . . 28
4 Signal-aware Shortest-path Algorithms 29 4.1 Threshold Shortest-path . . . 29 4.2 Bounded Shortest-path . . . 31 4.2.1 Implementation . . . 32 4.2.2 Forbidden Subpaths . . . 32 4.2.3 Exception Avoidance . . . 33 5 Evaluation 36 5.1 Choosing Metrics . . . 36
5.1.1 Minimum RSSI Averaged . . . 37
5.1.2 Maximum Bad Distance . . . 37
5.2 Field Test . . . 37
5.2.1 Field Test Results . . . 38
5.3 Mass Evaluation . . . 39
5.3.1 Selecting The Result Set . . . 39
5.3.2 Results . . . 40
6 Conclusions 43 6.1 Improvements . . . 44
Appendices 46
A Signal Box Size Considerations 47
Chapter 1
Introduction
As application features in modern vehicles are becoming increasingly depen-dent on network coverage it may become useful to plan routes that accounts for connectivity. This facilitates future development for vehicular applica-tions with increasing network coverage requirements. The purpose of this bachelor thesis is to investigate how this can be achieved, and what tools are needed in order to accomplish this task.
1.1
Motivation
What we today consider smart cities may soon extend their infrastructure to include real-time maps of network coverage in order to facilitate network dependent features in vehicles. While it is difficult to predict exactly what the future holds for vehicular applications, it is an interesting and active research area. Some applications may have requirements on reliability while they move, to such an extent the signal coverage is an important factor that needs to be included in the route planning process. In such a scenario, the best possible route may not end up being the shortest possible.
Cases also exist where the differences in distance between routes is negligible. Assume for example that two planned routes, A and B, have a negligible physical distance difference but route B is better in terms of signal strength. This should lead to the choice of picking B. Such a scenario can be found in grid-like patterns commonly found in inner-city locations. It is often possible to move across a grid in multiple ways without any major increase in distance. The basic idea is that it can be possible to improve the overall value of the
route for a low cost, but it is only possible to find these alternate routes if they are actively searched for.
With the existence of alternative routes to the shortest-path but with im-proved signal characteristics the question becomes what the actual cost is, and what can be gained from picking an alternate route.
1.2
Problem Definition
In Chapter 1.1 we presented an example where there is a negligible distance increase for a possible signal increase (grid patterns commonly found in inner-city locations). We also need to look at what happens when we move away from the grid pattern and look at a larger urban area that include not only the typical grid pattern, but also winding roads to varying degrees. This leads to a few questions that we will attempt to find answers to.
• What fundamental tools are needed in order to develop and evaluate signal-aware route planning strategies?
• What route planning strategies do we need and how to validate them? • How can a signal map be built in order to facilitate the use of
signal-aware shortest-path algorithms?
• What sources of data can be used for the signal map and how to validate the data?
• What kind of tradeoff can be made and for what gain in signal strength when routes are planned?
These questions serve as a problem definition and will be answered in the coming chapters.
1.3
Goals
With a definition of the problem in Chapter 1.2 we have identified a few goals in order to further stress the motivation and problem definition behind the subject of this bachelor thesis. These goals serve the purpose of briefly describing what the reader can expect this thesis to contain, as well as an
insight on what the author has attempted to achieve. The goals are as
• Develop an example application that plans routes using varying strate-gies for cost evaluation. The application is written in C++, and uses the Qt framework.
• Obtain graph representation of real-world map data for the example application in order to have an environment suitable for developing and testing signal-aware route planning algorithms outside of simulators. • Obtain signal data, and find methods for combining it with the physical
representation from the previous goal.
• Develop and quantify algorithms that uses signal data when evaluating the cost during route planning.
1.4
Limitations
In order to limit the scope of the project and fit it in the given timeframe, as well as the limitations on what data is available today, the following lim-itations have been imposed.
• The map in which we plan routes is limited to a map of Link¨oping, approximately 4 kilometers long and 3 kilometers wide.
• Not all speedup techniques for performing route planning are imple-mented (e.g. hierarchical structures, bi-directional, edge contraction). Special focus has been put on optimizations until runtimes were deemed acceptable.
• Signal data is not real-time, but a collection of data from the past 6 months. This is the best alternative for real data in lieu of an in-frastructure akin to a distributed sensor network, or other pervasive methods of collecting sensor data.
1.5
Methodology
Vehicular application features may have requirements for network coverage in order to function properly. This leads to a need to perform route planning that is aware of signal coverage. As requirements may vary greatly, different strategies for planning routes need to be developed and tested.
The goal is to use real map and signal strength data in order to be able to evaluate these strategies outside of simulators. Evaluations are two-fold: test the signal strength while travelling certain planned routes, and calculate all possible paths in an urban area and analyze the result of all these paths. First a map has to be obtained in a form that is fitting for route planning algorithms. If a real-world map can be obtained as a graph it provides an environment suitable for developing signal-aware route planning algorithms. Map data can be obtained via open databases, and by parsing and pro-cessing the map data a graph can be built. For this thesis we are using OpenStreetMap. [8]
Secondly, signal data for particular areas are required. This can also be ob-tained by using an open database. For this thesis we are using OpenSignal. [7] By combining the road network map with the signal data, roads can be des-ignated signal strength values. This leads to algorithms that calculate the cost for a route to have access to signal data, as well as regular physical properties such as distance.
When a combination of map data and signal data is available, strategies for signal-aware route planning can be developed and tested in real-world scenarios. To evaluate the strategies, routes given by the different strategies are travelled while measuring signal strength data, and compared to routes that only take physical distance into account, as well as routes given by common proprietary route planning websites. Furthermore, a calculation of all unique paths in the given map is performed, and data analysis carried out on the result set.
Chapter 2
Background
In this chapter we discuss previous related work and give an introduction to the two sources of data (map and signal). Format of data and features are introduced and explained. Note that not all features of each source of data are included, only those that are relevant for this application and purpose is discussed.
2.1
Related Works
One of the fundamental concepts behind this thesis is the relationship be-tween signal strength and the resulting data rates. In [11][13] the impact of signal strength on TCP data rates have been studied, showing a relatively stable level of data rates until approximately -80 dBm, after which the data rates start to plummet.
Building signal coverage maps has been discussed previously in the literature, however the format of the signal data impacts the suitability for what imple-mentation is practical. In [3] extents are built for edges in order to associate and cluster measurements of signal strength. Another problem to tackle is how to keep signal maps updated. Several studies have looked at variations in signal strength with changing weather variables. In [6] temperature is listed as the major factor, with an inverse relationship (lower temperature increases the signal strength).
Performing route planning with extra parameters to maximize on top of time or distance is not a new concept. In [2] route planning is performed in respect to user preferences, such that a user’s preferred path is included
in the planned route. Other methods indirectly modify distance/time costs, such as in traffic-aware route planning methods [15].
While exploring poor signal areas the bounded algorithm encounters a short-est path problem in graphs generally called forbidden subpaths. This problem has been discussed in a similar manner previously. In [14] the problem is dis-cussed with the assumption that all forbidden subpaths are known and held in a set X prior to exploration. In [1] there is no a priori knowledge of the set of forbidden subpaths X. Instead an oracle-like object must be polled to confirm the validity of the chosen path after the shortest path has been found. The bounded algorithm encounters forbidden subpaths while explor-ing, which is a third variation of the forbidden subpath problem.
2.2
Obtaining Map Data
In this chapter we describe how the database OpenStreetMap [8] provides users with access to maps and the data used to build them. In particular we focus on the data layout as presented by the Overpass API [9], which is an option for exporting a map from OpenStreetMap.
2.2.1
OpenStreetMap
OpenStreetMap [8] is an online service that provides interactive maps directly in the browser, much like Google Maps and similar proprietary applications. It allows zooming in on any region, displaying different hierarchies of roads (bicycle, roads, etc.). The data used to build the map is however not from any third party API, but collected by private individuals using smartphone applications. It is then made publically available through several different options for exporting the data. Because map data is user-provided it may not always be complete for all regions, or accurate.
2.2.2
XML Layout for Map Features
One of the options for exporting data for any given map from OpenStreetMap is through the Overpass API [9]. This API provides general purpose infor-mation for the given map and is well documented. In this section we will look closer into the three main portions of a map file from OpenStreetMap
via Overpass API, formatted with XML. These three portions are meta data, nodes, and ways.
Meta Data and Bounds
Below is a small excerpt from an example map. It shows some meta data including download date and the bounding box coordinates that identifies the map for which data was requested.
<?xml version="1.0" encoding="UTF-8"?>
<osm version="0.6" generator="Overpass API"> <note>The data included in this document is from www.openstreetmap.org. The data is made available under ODbL.</note>
<meta osm_base="2015-10-21T22:23:02Z"/> <bounds minlat="58.3968" minlon="15.6365"
maxlat="58.3997" maxlon="15.6446"/>
Nodes
The first portion of map data consists entirely of nodes. These can be consid-ered building blocks for any map feature (roads, buildings, suburbs, forests, etc.). Each node has a unique identifier, latitute and longitude coordinates, and meta data (when it was collected, by whom, etc.).
<node id="81103" lat="58.4030369" lon="15.6333433" version="7"
timestamp="2013-04-14T19:36:17Z" changeset="15729210"
uid="365781" user="PawelJ"/>
Ways
Despite the name, ways can be any map feature. After every node of the chosen map has been listed, all ways are listed. Ways describe shapes by referencing nodes. The shapes are then formed by drawing a line segment between two following nodes. By connecting several nodes, structures, roads, or any other map feature can be drawn. We can find what map feature the way is describing by looking at its ending tags. If ’highway’ is found, some sort of road is described.
Below is a way that describes a road. The way has a unique identifier and some meta data. It then references the nodes the way consists of. Lastly, the tags identify what type of object the way is describing. For this way we find the highway tag, which means it is a road.
<way id="27431780" version="2" timestamp="2015-01-10T16:19:09Z"
changeset="28043676" uid="83501" user="riiga"> <nd ref="301156415"/> <nd ref="301166550"/> <nd ref="301166556"/> <nd ref="301166557"/> <nd ref="301166568"/> <nd ref="301166575"/>
<tag k="highway" v="residential"/> <tag k="maxspeed" v="30"/>
<tag k="name" v="Eklundsgatan"/> </way>
2.3
Obtaining Signal Data
In this chapter a description of OpenSignal [7] and the signal data that can be obtained via its NetworkStats API is given. This data will later be combined with a graph representation of a real-world map created from OpenStreetMap data [8].
2.3.1
OpenSignal
OpenSignal is an online service that provides signal strength information and cell tower locations. Behind OpenSignal is a database of cell phone towers, cell phone signal strength readings, and Wi-Fi access points. The front end then visualizes this information in an interactive map. For example, a heat map of signal strength for 2G, 3G, and 4G cell coverage can be drawn on top of a regular map. Each generation can be disabled in the map to filter for example 4G signal strength. Other options include showing cell phone tower locations, differentiating them between the companies that own them (e.g. Telia and Telenor in Sweden). The data is collected by private individuals using an application provided by OpenSignal. Each month the collected data from the previous 6 months is used to update the database. The signal map is therefore not continously updated, but rather a snapshot of the readings from the last 6 months at the end of each month.
2.3.2
NetworkStats API
OpenSignal provides the user-submitted signal strength data to anyone who requests it via its NetworkStats API. This requires an API key and one can be obtained by signing up to the developer portal for OpenSignal. T here are also two data rate limits that must be observed in order to receive any data; one limit per minute, and one limit per month. For this thesis, these two rates have been greatly increased.
The required fields when forming a request for the NetworkStats API are a latitudinal and longitudinal position, distance, and API key. The distance is given as kilometers and is used to create a bounding box with the latitudinal and longitudinal position as its center point. That is, if we request data for a specific point and include a distance of 1 (km), we will receive the result for an area equal to a square with 1x1 km sides around the center point.
OpenSignal also provide a different API for cell phone tower locations called Tower Info API, but that API is outside the scope of this thesis.
2.3.3
Signal Data Response Details
The response for a successful request to the NetworkStats API will include some meta data; API version, the latitudinal and longitudinal position for the request, the bounding box limit (given as distance), whether or not we filtered the network types based on generation, rate limits, and the current amount of requests that has been performed for both of these limits.
If there were readings for the requested area, these are then listed for each available generation. The data for each generation include some additional metadata. Owner of the network is listed if available, network generation type, and network identifier. After this the signal data is listed. RSSI (Received Signal Strength Identifier) and RSRP (Reference Signal Received Power) is returned as an average of a specified sample size.
For some areas there is also additional signal data. This data include down-load speed, updown-load speed, ping time, and reliability (measured as the pro-portion of time a data connection is possible). However, for the particular area around Link¨oping these additional parameters are not as common as the signal strength readings.
2.4
Graphs and Shortest-path Algorithms
In order to understand signal-aware algorithms an introduction to classical shortest-path algorithms is given. This introduction explains a shortest-path algorithm commonly named Dijkstra’s algorithm [4]. We will also briefly discuss the properties of the graph we are using, and the applied optimization techniques.
2.4.1
Graph properties
Road networks are directed weighted graphs. A directed graph is a graph in which edges between two vertices have an associated direction, or where one direction between two vertices is not defined because the edge does not exist. Consider a graph G(E, V), where E is the set of edges and V is the set of
vertices. Further, vertices u and w are connected with an edge e(u, w). This edge e has a direction, and as far as we know it is only possible to go from u to w, not necessarily in the other direction (from w to u). A real-world example of this is one-way streets; it may be legal to use a vehicle travelling one way but not the other.
Another graph property is whether or not edges have weights. Weights de-scribe the cost or length of an edge. If edges do not have weights, it can be assumed that all edges have the same weight in order to allow weighted graph shortest-path algorithms to work. A weight can have a negative value, and while it may seem unintuitive at first it is simple to explain. Imagine a graph that describes a road network, and the weight (or cost) for an edge describes the fuel usage for a vehicle. A negative cost for an edge may then appear if an edge (road) goes past a fuel station or some other resource-replenishing construct.
The graph as built by the application can be explained by noting that every edge holds two weights (costs). These weights are the physical distance (length of the edge), and the distance that is below a given signal threshold. Every edge also holds a binary value (true or false) whether the edge is ’acceptable’. For now it suffices to state that the graph is a directed weighted graph with bi-directional edges without any negative weights.
2.4.2
Dijkstra’s algorithm for finding shortest paths
A common ancestor for many modern shortest-path algorithms for graphs was first publically published by Dijkstra [4]. Dijkstra’s algorithm requires that all edges have non-negative edge weights. If such a graph is provided, then Dijkstra’s algorithm finds the shortest path between a source vertex and target vertex by always selecting the closest (to the source) and not yet explored vertex. The algorithm terminates when the currently ’selected’ vertex is equal to the target vertex, or if it runs out of vertices to visit. Dijkstra’s algorithm consists of three steps (in order): (1) an initialization of the graph, (2) selection of the closest vertex, and (3) relaxation of vertex neighbour costs.
2.4.3
Applied Optimization Techniques
Optimizing for speed was deemed to be necessary once a desire arose to perform a mass evaluation of the route planning algorithms. The intent is to be able to take a graph with thousands of vertices and calculate the shortest path for every possible unique pair of source and destination. Because of the size of the graph and the non-optimized implementation that was originally in place, this evaluation would have taken roughly 180 days to complete. At that point it became apparent some optimization techniques were needed. Note that this is not an exhaustive list of possible optimizations, only applied optimizations are discussed.
Previously a very brief introduction to Dijkstra’s algorithm was given. While it is simple to implement a basic version there are several possible improve-ments to be made. Many of these improveimprove-ments relate to performing prepro-cessing; compute some set of data in advance in order to speed up subsequent queries. This is useful for applications with memory to spare while having requirements on query times. Another improvement removes inherent search times by changing the underlying data structure. Finding the closest un-visited vertex when selecting what vertex to visit next is a search that this change in structure helps alleviate.
• All searches for vertices and edges removed, references to each con-necting edge and vertex is instead saved in every vertex. Since road networks are relatively sparse, this is a small memory increase (vertices do not have to store many extra bytes since only a few neighbours are common).
• The unvisited list was replaced with a min-heap instead of a copy of the original graph. Only evaluated neighbours are pushed into the min-heap.
• Instead of resetting the graph between every path, simply copy the original graph and never modify it. Use the copy for any modifications made.
• A* was implemented instead of the original Dijkstra implementation for the shortest physical path and for the threshold algorithm. Bounded currently has no heuristic.
With these optimizations applied, the algorithms were pushed into runtimes around 10−3 seconds instead of the 100 seconds as in the original implemen-tation. This is far from the possible speeds using modern techniques [10].
However, at this point it was deemed that the fastest way to obtain the result set was to simply start running the application rather than continue optimizing. Application runtime was expected to be around 16 hrs for each policy, and implementing more optimizations would likely have taken longer than that.
Chapter 3
Graph and Signal Map
This chapter describes how the underlying structure for the example appli-cation is built. It consists of two parts: building a graph from map data, and combining this graph with signal data. This allows shortest path algorithms for graphs to also have access to signal strength.
The graph is built by parsing map data in order to find intersections. Vertices are constructed for each intersection, as well as at the ends of any road (cul-de-sacs, etc.). Edges are then constructed as separate objects and connected to relevant vertices.
The signal map is built by placing centerpoints for squares in such a way that a grid is obtained. Each of these squares are then populated with data by sequentially requesting data from OpenSignal for each centerpoint. Once the graph has been built and the signal grid has been populated with data, every vertex and edge is matched to a centerpoint in order to assign some signal data. With this achieved, any shortest path algorithm now has access to signal data.
3.1
Building a Graph from Map Data
In this section we describe how a graph representation can be built from real-world map data provided by OpenStreetMap [8] (OSM) via Overpass API [9]. It is achieved by parsing map data and finding multiple occurrences where different ways reference the same node multiple times. Every time a node is referenced more than once by different ways, an intersection has
been found. For every intersection and at the ends of any road, vertices are built. Edges are then built from the remaining OpenStreetMap nodes between vertices.
3.1.1
Parsing XML
The first step is to obtain the boundaries for the specific map. As was shown in the example on page 8, <bounds> are located directly after the meta data and are thus found early in the map file. The attributes (coordinates) are extracted and used to set boundaries in order to determine valid nodes (inside the map area).
The second step is to store all the <node>s with the relevant information. In this case it is the unique identifier, and latitude/longitude coordinates. The third step is to store all the <way>s with the highway tag. This tag means that the way is describing a road. Malformed ways (for example only consisting of a single valid node) are ignored.
3.1.2
Detecting Intersections
After the parsing of the XML has been completed we currently possess a list of nodes and a list of ways. For each way we maintain a list of valid nodes that it consists of. An intersection can be detected by finding shared nodes. That is, two or more ways reference the same node. Algorithm 1 finds intersections, but is a quite expensive operation.
Algorithm 1 Find shared nodes in a list of ways
Input: Set of ways.
Output: Set of shared nodes in each way.
1: foreach way ∈ ways[] do
2: foreach node ∈ way.nodes[] do
3: foreach otherway ∈ ways[] do
4: if way 6= otherway then
5: foreach node ∈ otherway.nodes[] do
6: if way.node = otherway.node then
7: way.sharednodes[] ← node 8: end if 9: end for 10: end if 11: end for 12: end for 13: end for
The number of iterations needed is numberof ways2∗ avgnodes2, where
avgn-odes is equal to the average amount of navgn-odes per <way> element. Thank-fully, a <way> describing a road in an urban area typically consists of 5-20 nodes, although more or less than that is not uncommon. For the chosen map (about 3.8 kilometers long and 2.6 kilometers wide) this turns out to lead to approximately 1.6 ∗ 109 iterations. Using this particular map, this
step takes roughly 20-30 seconds to complete on a modern computer. Faster alternatives are possible, e.g. by increasing the memory usage and use hash tables (hash every node reference and upon collision an intersection has been detected).
3.1.3
Creating Vertices
Once we have detected intersections (i.e. found all shared nodes) we can start creating vertices. Algorithm 2 describes vertex creation.
We have three conditions for which we will create a vertex. If the node is shared (i.e. is an intersection), or if the node is at either end of the road.
Algorithm 2 Find vertices to create
Input: Set of ways.
Output: Set of vertices.
1: foreach way ∈ ways[] do
2: foreach node ∈ way.nodes[] do
3: if isShared(node) or isStart(node) or isEnd(node) then
4: CreateV ertex(node)
5: end if
6: end for
7: end for
3.1.4
Creating Edges
So far we have created vertices, which is a necessity for graphs. We will also construct edges as separate objects, as it becomes useful to model roads with more properties than physical distance, since these properties may even shift from the beginning of the road until the end. For example, a very long road will have shifting signal strength across its length. Algorithm 3 describes how edges are created.
Algorithm 3 Find edges to create
Input: Set of ways.
Output: Set of edges.
1: foreach way ∈ ways[] do
2: endpoint ← way.start
3: index ← 0
4: while endpoint 6= way.end do
5: startpoint ← nextSharedOrStartOrEnd(index)
6: index ← indexF or(startpoint)
7: endpoint ← nextSharedOrStartOrEnd(index)
8: index ← indexF or(endpoint)
9: CreateEdge(startpoint, endpoint)
10: end while
11: end for
The index in Algorithm 3 refers to a location in the array holding nodes in each way (in other algorithms it is referred to as way.nodes[]). Malformed ways (only consisting of a single node) were never included into the set of ways. If single-node ways were included we would not create edges for them, as it would be a loop (start is pointing to itself). For this thesis, edge loops
are avoided as they are formed out of map inconsistencies.
3.1.5
Physical Properties of Edges
As noted in Section 2.2.2 (page 8) <way> elements consist of many <nd> references. The edges created by Algorithm 3 have broken up these references to various edges, but many edges may still consist of several references. At this point we know that between the start and end point for every edge there is a piece of road that does not intersect. We can contract the road in the sense that for each of these non-intersecting nodes, calculate the distance from it to the next, until we reach the end. This can be considered as a part of preprocessing, as it removes the need to do it later when we want to get the physical length of an edge. Algorithm 4 describes how this step is performed.
Algorithm 4 Calculate individual edge distance
Input: Set of edges.
Output: Physical length for each edge.
1: foreach edge ∈ edges[] do
2: dist ← 0
3: f irst ← 0
4: next ← 1
5: while f irst 6= edge.end do
6: dist ← dist + distance(edge.nd[f irst], edge.nd[next])
7: f irst ← f irst + 1
8: next ← next + 1
9: end while
10: end for
The distance() formula may be any geodesic formula for calculating dis-tances on the surface of Earth. For this application the haversine formula [12] is used. Since we work with relatively small maps to the size of a few kilometers wide and long, the error introduced by haversine is small.
3.1.6
Summary
At this point we have a list of vertices with unique identifiers, a known loca-tion, and a list of the edges that is connected to it. We also have a list of edges with a known physical distance, and what vertices it is connected to. The
edges and vertices also hold currently empty variables for network statistics, such as ping time, reliability percentage, RSSI, and a few others. The goal of this chapter was to describe how we can generate a graph representation from map data. The next step is to combine this graph representation with signal data.
3.2
Combining Signal Data with Map Data
In this section I will describe how the graph built in Chapter 3.1 can be combined with signal data from OpenSignal [7]. This creates a structure in which each edge (road) can be assigned a real-world network signal strength. Such a map is useful when performing route planning algorithms that takes signal strength into account.
The structure of the signal coverage map is in some way dictated by the format of the signal data. With OpenSignal the signal data is given as the overall value for a square. This naturally leads to building a grid of squares, as shown in Figure 3.1. Other possible formats could be single data points (measurements) that need clustering.
Figure 3.1: Grid of bounding boxes populated with signal data. In this thesis we perform this combination by calculating a certain amount of bounding boxes and its center points, and then requesting these from OpenSignal. Once we have requested all the bounding boxes we can match roads and their nodes to these boxes of known signal strength, effectively assigning signal strength to each road.
This chapter will also include a discussion regarding what size to choose to request from OpenSignal, as there are conflicting goals that need to be maximized.
3.2.1
Calculating Box Sizes
As described in Section 2.3.2, by using the OpenSignal API we can request signal data. Before requesting any data we need to choose the size of the bounding box and where the center point for this box should be.
The goal is to have very small boxes, and have each of these boxes contain actual readings rather than merged or inferred data (data from adjacent, or nearby readings). In the ideal case we could imagine an infinite amount of boxes and real-time readings available for each box, as it would approach a perfect representation of the actual signal strength for any given position. However, geometry rules dictate that the smaller the box, the more of them are needed to fill an area.
There are several practical limitations that force us to increase the box size. The signal data is restricted to request rates and we are not allowed to cache any data. Using a low box size and constantly restarting the application, as is common during development, therefore potentially leads to running out of the allowed monthly requests. Another consideration is development time spent on waiting for the application to populate the signal map. Using the map of Link¨oping requires a 25 minute setup with a box size of 100m for example.
Another limitation is reduced usability. As we decrease the box size we in-crease the chances to not have any data returned. OpenSignal seems to only return data if there has been a certain number of readings within the requested box (or nearby), and as the area decreases the amount of read-ings per box should decrease as well. The following figures show the signal strength added on an overlay of the graph representation (screencap of ex-ample application). The signal ranges are given in the figure descriptions. In order to understand the color differences, red approaches -50 dBm (stronger signal), and blue approaches -100 dBm (weaker signal). Purple indicates that no signal data was returned. Values are given in dBm, and LTE networks are being measured.
Figure 3.2: Box side of 400m, minimum RSSI (dBm) -81.3, maximum RSSI (dBm) -55.3. Red approaches -50 dBm, blue approaches -100 dBm.
Figure 3.3: Box side of 300m, minimum RSSI (dBm) -76.2, maximum RSSI (dBm) -53.5. Red approaches -50 dBm, blue approaches -100 dBm.
Figure 3.4: Box side of 200m, minimum RSSI (dBm) -83.8, maximum RSSI (dBm) -52.1. Red approaches -50 dBm, blue approaches -100 dBm.
Figure 3.5: Box side of 100m, minimum RSSI (dBm) -86.3, maximum RSSI (dBm) -52.8. Red approaches -50 dBm, blue approaches -100 dBm.
As we can observe from the figures above, the maximum RSSI seem to in-crease as the box side dein-creases. This could be explained by the inin-creased resolution pinpointing strong signal spots as the box area decreases. One ex-ception is the slight reduction in maxima going from Figure 3.4 to Figure 3.5. This could potentially be explained by the increase of boxes returning no value, some of the boxes removed should have had a good signal strength according to previous figures (e.g. compare the orange-red area in the south in Figure 3.2 with Figure 3.5).
Another observation is the dramatic increase of boxes returning no values in Figure 3.5. This greatly reduces the usefulness of the map. While we have increased the resolution of the map, we are quickly approaching the practical limits of the data as provided by OpenSignal. Many boxes seem to have data that is inferred from adjacent ones, as upon closer inspection several boxes contain identical values for signal strength. A visual clue is that many adjacent boxes seem to have matching colors leading to streaks, rather than more naturally flowing colors.
3.3
Sample Size Values
If we look at the total sample size in Figure 3.6, we see that as the box size decreases the amount of samples increases. It should be noted that we are not increasing the area coverage, we are looking at the same map for all the box sizes. This means that samples may be counted multiple times, possibly due to some boxes inferring data from adjacent readings. The average sample size per box in Figure 3.7 does fluctuate, but not as much. One explanation for this variation is that the percentage of boxes containing no data is changing with box size. This is another clue that at least some data is inferred, since
100 150 200 250 300 350 400 200,000 400,000 600,000 Box Side m Sample Size
RSSI Sample Sizes
Figure 3.6: Total amount of sample sizes.
100 150 200 250 300 350 400 1,150 1,200 1,250 Box Side m Sample Size
RSSI Average Sample Size
we would expect to see a reduction in local sample size as the box area decreases, while the total sample size stays (somewhat) equal.
It should be noted that NetworkStats was likely not designed for this partic-ular purpose (mass pin-pointing of bounding boxes), and we are using it as a real alternative to something akin to an imagined distributed sensor network providing real-time signal strength data.
3.3.1
Calculating Center Points
As described in Section 2.2.2, one of the first elements we encounter when parsing map data are the boundaries for the map. With these boundaries and a given value for the box size we can calculate the location of each center point. Algorithm 5 describes how this is achieved.
Algorithm 5 Calculate Center Points
Input: Set of center points without location, and map boundaries. Output: Set of center points with determined location.
1: xstart ← bounds.minlon
2: ystart ← bounds.minlat
3: xboxes ← round(map.xdistanceboxsize )
4: yboxes ← round(map.ydistanceboxsize )
5: ∆lat ← bounds.maxlat − bounds.minlat
6: ∆lon ← bounds.maxlon − bounds.minlon
7: ∆lat ← yboxes∆lat
8: ∆lon ← xboxes∆lon
9: for i := 0 < yboxes do
10: for j := 0 < xboxes do
11: point.lat ← ∆lat2 + ∆lat ∗ i + ystart
12: point.lon ← ∆lon2 + ∆lon ∗ j + xstart
13: centerpoints[] ← point
14: end for
Algorithm 5 iterates horizontally starting from the bottom row. It places center points halfway of the chosen box side. Once it has finished one row, the outer for loop finishes one iteration, causing the next inner for loop to iterate through the row above.
Since we use actual distance when requesting bounding boxes, and the Earth being a spheroid, the responses will in fact cover areas slightly outside of the map close to the top if the map bounds are described using the lower coor-dinates. For the inverse (map bounds described using higher coordinates), some area coverage is lost at the bottom of the map. This effect is negligible for areas of the size described in this thesis.
3.3.2
Requesting Bounding Boxes
At this point we have prepared an array of center points and we have de-termined the box size. These are all the required fields (excluding the API key) we need in order to start requesting signal data from OpenSignal. The response is parsed, saving all the signal strength values for that center point, as well as what network generations are available.
Algorithm 6 Find Closest Center Point
Input: Set of center points with determined location, set of edges with undetermined center points.
Output: Set of edges with determined center points.
1: foreach edge ∈ edges[] do
2: foreach edge.ref erence ∈ edge.ref erences[] do
3: index ← 0
4: closestindex ← ∞
5: closestdistance ← ∞
6: foreach centerpoint ∈ centerpoints[] do
7: distance ← Distance(edge.ref erence, centerpoint)
8: if distance<closestdistance then 9: closestdistance ← distance 10: closestindex ← index 11: end if 12: index ← index + 1 13: end for 14: edge.closestcenterpoints[] ← closestindex 15: end for 16: end for
Because the center point holds an actual latitudinal/longitudinal position, any reference in an edge can check its own distance to any given center point in order to find the closest one by using an appropriate geodesic formula (this application uses haversine [12]). After having requested all the bounding boxes, this calculation can be performed on all nodes in order to preprocess the map. For sufficiently large maps and small routes, an option is to instead perform this calculation as needed. Note in Algorithm 6 that since we process each reference individually we also handle the case where a road has segments inside various different boxes. Each reference can find the closest center point of known signal strength rather than attempting to assign a single center point and therefore a single set of signal strength values to an entire edge.
3.3.3
Summary
In this chapter we discussed the request box size and how it affects the usability of the map for the purpose of route planning. We also described how we can create a grid of center points for which data can be requested from OpenSignal once an API key has been obtained and a box size has
been determined. As we populate this grid with data, we can then use
our graph implementation from Chapter 3.1 and match each of the node references that every vertex and edge consists of to one of these center points by calculating the distance between them. When each node reference has found its closest center point we can look up the signal strength for that center point whenever we are performing route planning, which allows us to base our decisions when planning routes not only on the physical distance, but also on signal strength.
Chapter 4
Signal-aware Shortest-path
Algorithms
In this chapter the different implementations of signal-aware shortest-path algorithms are detailed. First we discuss the threshold algorithm and its implementation, and its proof of correctness. We then discuss the bounded algorithm and its implementation, forbidden subpaths, and exception avoid-ance.
4.1
Threshold Shortest-path
The simplest variation of signal-aware route planning only allows routes that maintain a given threshold for signal strength. As implemented in the exam-ple application, this route planning policy cannot find a route if the destina-tion or source is below the given threshold, or if the signal areas are located such that the destination is unreachable without crossing some area that is below the threshold.
The only part of the threshold algorithm that sets it apart from other shortest-path problem-solving (SPP) algorithms is a graph transformation. Thus if the graph transformation is omitted, the function of the algorithm is equal to that of any SPP-solving algorithm.
The transformation can be described as follows: if we assume a graph G(V, E) where V is a set of vertices and E is a set of edges connecting these ver-tices (with a known signal strength), then we construct a graph G0(V, E) ← G(V, E). If we remove all edges below the threshold in G0 we form G0(V, E0).
s a b c d t 1 2 1 2
Figure 4.1: A regular shortest-path algorithm will find SP = {s, a, b, d, t}. The red edge marks an edge below the given signal threshold, which leads to the threshold algorithm disregarding it. Instead a more expensive path is found {s, a, c, d, t}.
This remaining graph is G0(V, E0) ⊆ G(V, E) and more importantly still has (mostly) the same properties as G(V, E) (e.g. completeness in G0is no longer guaranteed if G was complete). The most important property that does not change is whether edges have non-negative costs. Since unaffected edges have not had any costs modified, this property remains intact regardless of the graph reduction. This means that any algorithm that is known to be optimal for G is also optimal for G0.
In other words, if the graph is reconstructed to perform the step of removing all unusable edges based on the current threshold value, then the threshold algorithm may be replaced with any classical shortest-path algorithm. The algorithm therefore can be considered the transformation of the graph rather than a shortest-path algorithm. However, reconstructing the graph back and forth between algorithms, or maintaining several copies has an associated cost. The alternative, as implemented in the example application and shown in Algorithm 7, is to simply assert that edges connecting to neighbours are above the given threshold. If the edge passes the assertion, the neighbouring vertex may be visited.
In Figure 4.1 an example scenario is shown where a graph has an edge below the signal threshold. This edge must be ignored even if it would normally be included in the shortest possible path.
Algorithm 7 Threshold algorithm based on a given threshold value for a graph G(E, V )
Input: Graph consisting of set of vertices and edges. Output: Shortest path above signal threshold.
1: unvisited[] ← G(V )
2: v.cost ∈ unvisited[] ← ∞
3: v ← source
4: v.cost ← 0
5: while v 6= target and unvisited[] 6= ∅ do
6: for nbr ∈ v.nbrs and nbrinunvisited[] do
7: newcost ← v.cost + CalculateCost(v, nbr)
8: if newcost < nbr.cost and EdgeAboveT hreshold(v, nbr) then
9: nbr.cost ← newcost
10: nbr.head ← v
11: end if
12: end for
13: DeleteV ertex(v, unvisited)
14: v ← LowestCost(unvisited)
15: end while
4.2
Bounded Shortest-path
In order to increase flexibility in the way exploration of poor signal areas is performed in the threshold algorithm, an alternative is presented. Assume a sensitive application losing connectivity. One way to increase the robustness of such an application is to build up a backlog in the case of transmitting, or a buffer in the case of receiving. With this comes the expectation that if connectivity is lost, it will be regained shortly. With such an application in mind, imagine a signal-aware route planning algorithm that accepts losing connectivity as long as the loss is temporary in order to shorten the path. While there is a loss of connectivity, the application is either building up a backlog or using its buffer and as long as this ’blackout’ is short enough, the application can provide a satisfactory quality of service.
The benefit of such an algorithm is it may find shortcuts in comparison to the threshold algorithm, which on average reduces the length of the paths. By trading the temporary reduction of signal strength some of the distance that is traded for the signal strength is regained. Another benefit is that the bounded algorithm reduces the potential snake-like paths found by the threshold algorithms, as it does not have to always completely avoid poor
s a b c d t 1 2 1 2
Figure 4.2: Red edges marks unacceptable signal values.
signal areas.
For this thesis, the bound set by this algorithm is considered as a distance rather than as a time variable. Therefore, the allowed exploration is in meters rather than in seconds. It is also assumed that clearing the potential backlog or filling up the buffer is instantaneous.
4.2.1
Implementation
The difference between the bounded algorithm implementation to the base-line Dijkstra implementation is that two costs are being tracked. Usually only the distance is accumulated, however if an edge is below the signal threshold, a second form of distance called bad distance starts to accumu-late. First when this bad distance exceeds a given bound does edges become unusable. This allows certain edges to be below the signal threshold while still being usable. The bad distance cost is reset whenever an edge is above the threshold.
Consider Figure 4.2. It contains the same graph as in Figure 4.1, where red edges marks unacceptable signal values. If we assume a bound of bad distance = 1.5, it finds E(a, b) usable even though it is below the signal threshold since its cost of 1 is lower than the bound of 1.5. In this scenario the bounded algorithm succeeds in finding the same path as a regular SPP algorithm (SP = {s, a, b, d, t}). If the bound <1, it would not be able to consider E(a, b), leading to SP = {s, a, c, d, t}.
4.2.2
Forbidden Subpaths
Consider Figure 4.3. Using the bounded algorithm with a bound = 1.5 and red edges marking unacceptable signal values, we find E(a, b) usable since its cost of 1 is lower than the bound of 1.5. However, we have accumulated bad
s a b c d t 1 2 1 2
Figure 4.3: Red edges marks unacceptable signal values.
distance of 1. When we are evaluating the neighbours of b we find E(b, d) to be deemed unusable since going there would increase the bad distance to 2, which is greater than the bound of 1.5. We have detected a forbidden subpath F P = {a, b, d} and any eventual path is guaranteed to not include this subpath.
This detection of forbidden subpaths are called exceptions, and exception avoidance must be performed in order to resume. In Algorithm 8 this de-tection is performed by the AccumulatedBadDistance() function. In the sce-nario described previously the bounded algorithm will avoid combining the two edges E(a, b) and E(b, d) leading to SP = {s, a, c, d, t}.
4.2.3
Exception Avoidance
As discussed in Chapter 4.2.2, we encounter an exception whenever the bad distance variable exceeds the given bound. In the following paragraphs we will discuss how the example application has implemented the bounded al-gorithm. It should be noted that from this point it does not solve exception avoidance optimally and we will discuss improvements.
Consider Figure 4.4 with a bound = 3.5 and red edges marking unacceptable signal values. The evaluation order of vertices will be s, a, b, c, d, e. Upon reaching V (e) however, a forbidden subpath F P = {a, b, d, e, t} is detected (4 >3.5). The only path that meets the constraints has to go through V (c). However, we have already evaluated V (c) before we reached V (e), and if we only allow forward-iteration, this shortest path cannot be found using this bound.
We apply exception avoidance if all the unvisited neighbours are evaluated as exceeding the bounds. The possible correction to this path that can be made is by using undiscovered paths from other directions. In such a case that all unvisited neighbours are unreachable due to the accumulated bad distance, the current vertex may not be removed entirely from the unvisited
s a b c d e t 1 2 1 2 1 1
Figure 4.4: Red edges marks unacceptable signal values.
set. The reason for this is that we have only detected unreachable neighbours using this particular subpath, if another subpath (or in other words, another direction) is tried, a suitable path may be found. We may therefore consider the inclusion of a temporary set that holds these visited vertices that are not yet completely safe to disregard from any shortest path.
This solution is suboptimal because only undiscovered paths can repair the path and thus avoid the exception. While it is a fast solution, since it only allows constant forward-iteration of vertices, an optimal solution requires checking already discovered paths to find an option. That is, a certain degree of backtracking must be performed in order to find out whether any of the worse discovered paths are acceptable. An example of the weakness of only using forward-iteration is demonstrated in Figure 4.4, where a path may not be found at all, even if a suitable path exists. In this case, the path could have been repaired by backtracking and finding the second best path. In an optimal case, this backtracking includes finding the second path and assess its suitability. If it is not suitable, the third path is found, and so on. If all paths are exhausted and none found suitable, only undiscovered paths can avoid the exception and forward-iteration continues. If a suitable path is found, the exception is avoided but may return the very next iteration if the exploration of the poor signal area is delving deeper. For non-trivial graphs, exception repairs becomes expensive.
In Algorithm 8 the exception avoidance is performed by the variable nbr.isbadend. Upon closer scrutiny we can see that we allow updating the new path in two cases: if we have found a shorter path, or if the current path is a forbid-den subpath. In both of these cases the alternative path is a suitable path, as it must pass all previous bad distance checks. This means any suitable path may overwrite the current (forbidden) path, thus avoiding the excep-tion.
Algorithm 8 Bounded shortest-path based on a given threshold and bound value for a graph G(E, V ).
Input: Graph consisting of set of vertices and edges initialized to infinite costs.
Output: Approximate shortest path with a guaranteed bound of bad
dis-tance.
1: unvisited[] ← G(V )
2: temporary[] ← ∅
3: v ← source
4: v.cost ← 0
5: while v 6= target and (unvisited[] 6= ∅ or temporary[] 6= ∅) do
6: v.isbadend ← true # Assume vertex is a bad end.
7: for all nbrs in unvisited[] or in temporary[] do
8: if AccumulatedBadDistance(v, nbr) > BOUND then
9: continue
10: end if
11: newcost ← v.cost + CalculateCost(v, nbr)
12: if newcost < nbr.cost or nbr.isbadend is true then
13: U pdateN br(newcost, v, AccumulatedBadDistance)
14: v.isbadend ← f alse # Vertex not bad end.
15: end if
16: end for
17: if v.isbadend is true then
18: temporary[] ← v # Vertex may be revisited.
19: end if
20: DeleteV ertex(v, unvisited, temporary)
21: v ← LowestCost(unvisited, temporary)
Chapter 5
Evaluation
In this chapter we discuss what metrics to use when evaluating signal-aware route planning strategies. We also discuss the methodology and result of a field test. After the field test another form of evaluation was performed, wherein paths between all unique pairs of sources and destinations were cal-culated and stored. The preparations and results for this mass evaluation are presented.
5.1
Choosing Metrics
It is important to understand why many different metrics are useful to eval-uate the tradeoff when picking paths other than the shortest physical path. While simple to understand, we should not only look at average RSSI for each policy. Average RSSI in itself describes an overall quality of signal strength, and with its connection to data rates we can imagine average RSSI as describing the amount of data that is possible to transfer using that path. Average RSSI is a useful metric in the general sense, however there are two factors that reduce its impact as a metric.
• Applications may not require a very high cap to send data in order to have a certain quality of service. Instead, e.g. avoiding poor signal areas may fit a given application’s mitigation techniques better. • The evaluated route planning policies are not trying to maximize
av-erage RSSI, the increased avav-erage RSSI is a typical side benefit. In the following an introduction to the different metrics that are being used
is given.
5.1.1
Minimum RSSI Averaged
By looking at the minimum reported RSSI, we may get an idea of the max-imum drop in service. This minmax-imum RSSI for a given path may then be averaged among many paths in order to show an average improvement in worst-case signal strength. This leads to a metric named average minimum RSSI, but may equally be thought of as the average worst-case RSSI. How-ever, looking at worst cases typically has the inherent risks of inflating num-bers and may misrepresent the actual application quality of service (a brief drop in signal strength may not be noticable).
5.1.2
Maximum Bad Distance
This metric describes the longest continued distance below the signal thresh-old. Note that it does not describe the total distance below a signal threshold for any given path. The total bad distance may be significantly higher than the maximum bad distance, and may be a useful metric to include for future work. For this thesis however, we have stated the assumption that buffers are instantaneous to fill, and as such only the maximum bad distance is of interest.
5.2
Field Test
In order to validate the route planning algorithms, a small-scale field test was devised and carried out. By picking a source and destination that produced varying paths according to the policies, we should expect to see improvements in signal characteristics accordingly. By using a fork of networkmonitor [5], a data collection tool, these paths were then travelled while measuring the signal strength. We used a Google Nexus smartphone for the measurements. The phone was kept unobstructed (handheld) the entire time as we received reports of major accuracy loss in the GPS measurements whenever smart-phones are covered (e.g. kept in a pocket).
The collected data points are plotted into the example application, and shown in Figure 5.1. The chosen signal strength threshold was -69 dBm, and the bound was set at 300m.
Figure 5.1: Blue arrow points to source, green to destination. Numbers 1 through 3 marks Shortest-path, Bounded, and Threshold route planning policies.
Another source of data in need of validation is the map data. This validation was performed by comparing the predicted path length and the measured path length for the chosen paths.
5.2.1
Field Test Results
In Figure 5.2 the average RSSI of each path planned according to the different signal-aware strategies is shown. We show both the actual measurements and the predicted result according to the data provided via OpenSignal. There is a significant difference in the prediction and measurement, which can be explained by the difference in the signal data provided by OpenSignal and the performed measurements. In general the data provided by OpenSignal appears to be inefficient in pointing out local minima and maxima, which causes poor signal areas to not show up as clearly. When measuring ex-act locations we can capture poor signal areas more accurately essentially by pinpointing, whereas this effect is reduced when requesting data from OpenSignal as it covers a much larger area. The conclusion here is that the measurements themselves were positive even if they are dissimilar to the pre-dictions, as we gained a significant increase in average RSSI when deviating from the shortest possible path.
In Figure 5.3 the result of the validation of the map data is presented. The predicted path length is very close to the measured path lengths. It would thus seem that the map data and the graph prediction is accurate. The dif-ference between the prediction and measurement is likely covered by the error margins produced by the accuracy error in the location measurement.
Shortest Bounded Threshold −90 −80 −70 −60 −50 RSSI (dB m )
Average RSSI difference (dBm)
Prediction Measurement
Figure 5.2: Predicted and measured average RSSI.
5.3
Mass Evaluation
This evaluation consists of calculating all unique pairs of sources and desti-nations in the Link¨oping map and saving the results. The size of the graph leads to around 8 million unique pairs, which needs to be repeated for each policy. In order to achieve this calculation some optimization techniques need to be applied to the original trivial implementation of Dijkstra’s algorithm. In Chapter 2.4.3 the applied optimizations are discussed. A discussion on how to select the result set can be found in Chapter 5.3.1. The results of the mass evaluation is shown in Chapter 5.3.2.
5.3.1
Selecting The Result Set
At this point shortest paths for all unique pairs of sources and destinations have been calculated and stored in database files. The next step of the evaluation is the selection of the result set. The simple way is to include every single result, however details are lost whenever paths are equal since equal paths will flatten every metric. Instead the result set was built based on paths where different decisions had been made. The size of this result set also gives us a percentage of paths that are different than the shortest path when compared to the total amount of paths. It is these sets of different paths that data in Figure 5.4-5.7 are derived from.
Shortest Bounded Threshold 0 500 1,000 1,500 2,000 Distance (m ) Route length (m) Prediction Measurement
Figure 5.3: Differences in distance between measurements and prediction range from 0.01% to 1.05%.
5.3.2
Results
In this section the results of the mass evaluation are presented.
We see that the average cost in path lengths in Figure 5.4) is an 8.4% increase for the threshold algorithm, and 3.2% for the bounded algorithm. For the threshold algorithm, this 8.4% increase in path length yields a 100% reduction of bad distance, 1.3 dBm increase in the average RSSI, and a worst-case RSSI increase of 5.5 dBm. For the bounded algorithm, this 3.2% increase in path length yields a 59.3% reduction of bad distance, and a 1.1 dBm increase in both average RSSI and worst-case RSSI.
Threshold Bounded 0.6 0.8 1 1.2 1.4 1.08 1.03 Average Path Length Ratio
Figure 5.4: The ratio increase in average path lengths compared to the short-est physical path.
Threshold Bounded 0 20 40 60 80 100 100 59.26 Bad Distance Reduction
Figure 5.5: Percentage reduction in maximum bad distance compared to the shortest physical path.
Shortest(Thresh) Threshold Shortest(Bound) Bounded −80 −70 −60 −50 −63.4 −62.1 −64.2 −63.1 Average RSSI (dBm)
Figure 5.6: Average RSSI.
Shortest(Thresh) Threshold Shortest(Bound) Bounded
−80 −70 −60 −50 −71.6 −66.1 −72.3 −71.1
Average Worst Case RSSI (dBm)
Chapter 6
Conclusions
In this chapter conclusions from the results in Chapter 5 are drawn. Potential improvements to the bounded algorithm are also discussed.
For the particular signal threshold used in the field test and mass evaluation, it is possible to plan routes that improves the signal characteristic of the path. The signal data used in the mass evaluation is solely the OpenSignal data. In the field test it appears that while the data may be accurate over larger areas, it lacks precision for local maxima and minima. This means that the results may be slightly skewed in favor of the shortest physical path, as the shortest path is not penalized as heavily in signal loss as it would be in reality. This penalty is shown in the field test (p. 39), where the average strength is overall much lower in the actual measurements than in the predictions. In the real world, it is difficult to ever be able to guarantee a -70 dBm threshold in an urban area even if signal data indicates that areas are above this threshold. In other words, the 100% reduction in bad distance that the threshold supposedly gives, is likely not possible in many paths. Even in the measurements in the field test, a few data points were indeed below the threshold for a total distance of around 30m. This is because signal strength may vary rapidly from point to point, and many measurements seem to be needed in order to accurately model an area’s signal strength.
We have discussed in Chapter 3.2 (p. 21) the usability of the signal map, and by necessity it is constrained to 300m squares in a grid pattern. As this signal data is improved the route planning possibilities are as well, as the choices they are providing are based on fuzzy data. Reducing the fuzziness reduces the uncertainty in the predicted signal strength. If measurements are provided from some source, a signal map could be built by using existing
