HEAVEN for Android. An Heterogeneous Ad Hoc Network for Emergency Response
PAUL THOMAS
Département de génie informatique et génie logiciel
Mémoire présenté en vue de l’obtention du diplôme de Maîtrise ès sciences appliquées Génie informatique
Août 2019
c
Ce mémoire intitulé :
HEAVEN for Android. An Heterogeneous Ad Hoc Network for Emergency Response
présenté par Paul THOMAS
en vue de l’obtention du diplôme de Maîtrise ès sciences appliquées a été dûment accepté par le jury d’examen constitué de :
Bram ADAMS, président
Gabriela NICOLESCU, membre et directrice de recherche Sébastien LE BEUX, membre
ACKNOWLEDGEMENTS
I would like to thanks my research director, Prof. NICOLESCU Gabriela, but also Dr. SABAH Abdo and Ph.D. GIANOLI Luca from Humanitas, for allowing me to work on this project and for their help and support in this whole experience.
I also thanks my colleagues from both Polytechnique and Humanitas, for their help and for providing the fresh air I needed.
Finally, I would like to acknowledge MITACS and CRIAQ for their financial support on this project.
RÉSUMÉ
À ce jour, il est possible d’utiliser les téléphones intelligents comme des relais afin de créer des réseaux sans infrastructure. Humanitas, notre partenaire industriel spécialisé dans la concep-tion de soluconcep-tions sur les technologies de l’informaconcep-tions et de la communicaconcep-tion (TIC), propose de s’en servir pour rétablir les communications dans des zones sinistrées où les moyens de communication seraient coupés. Leur objectif est de permettre la création de ce type de réseau en utilisant des micro-ordinateurs installés sur des drones, ainsi que des téléphones personnels roulant sous iOS ou Android.
S’il est aujourd’hui possible de recréer ce type de réseau entre ordinateurs et iPhone du fait de la disponibilité de technologies faites pour sur ces plateformes, Android ne bénéficie pas du même traitement. L’état de l’art montre que les moyens présents sur Android permettent effectivement de lier les téléphones entre eux, mais de nombreux problèmes restent encore à résoudre. Il faut permettre une automatisation complète du processus, prendre en compte des limites des technologies utilisées ou bien offrir une compatibilité avec les téléphones intel-ligents iPhone, systèmes n’ayant que très peu de technologies compatibles avec les téléphones Android.
Nous proposons dans ce mémoire, plusieurs méthodes afin de répondre à ces problématiques pour obtenir une solution de création et jonction automatique d’un réseau sans infrastructure à environnement hétérogène pour téléphones Android.
Nous présenterons également des expériences sur les technologies de communications sans fil employées, de façon isolée ainsi qu’ en concurrence. Ceci nous permettra de connaitre les interférences qu’elles induisent, leurs performances de communication, ainsi que l’impact énergétique sur la batterie de nos téléphones. Nous évaluerons également les algorithmes mis en place pour la gestion du réseau, cela afin de valider leur comportement et de quantifier les performances de notre solution.
ABSTRACT
Using smartphones as relays could be a solution to create ad hoc networks and temporarily replace out of order traditional telecommunications infrastructure.
Humanitas, our industrial partner specialized in ICT solutions for humanitarian operations, develops a software to recreate networks in disastrous areas by leveraging low-cost computers like Raspberry pi or mobile devices, on either iOS or Android.
While it is possible to establish ad hoc networks with computers or iOS devices, thanks to their made-for technologies, Google public API greatly restrict capabilities of devices to create such network with Android devices. Most of literature implementations rely on uncon-ventional usage of the API. While they manage to reach their objective, the result is not as flexible or efficient, compatibility with other environments are eluded, and device limitations are not considered.
In this thesis, we propose a solution to create or join an ad hoc network on the model of Hu-manitas software Heterogeneous Embedded Ad hoc Virtual Emergency Network (HEAVEN), by ensuring the compatibility with iOS devices, and by managing the capabilities of our de-vices.
We discuss also multiple experiments designed to evaluate the performances and power usage of the wireless technologies we used, on both, stand-alone and mixed usage. This allow to know what their capabilities are and their influence. We test and validate our solution and conclude on its global performances.
TABLE OF CONTENTS ACKNOWLEDGEMENTS . . . iii RÉSUMÉ . . . iv ABSTRACT . . . v TABLE OF CONTENTS . . . vi LIST OF TABLES . . . ix LIST OF FIGURES . . . x
LIST OF SYMBOLS AND ACRONYMS . . . xi
LIST OF APPENDICES . . . xii
CHAPTER 1 INTRODUCTION . . . 1
1.1 Context . . . 1
1.2 Research Question, Objective and contributions . . . 2
1.2.1 Research Question . . . 3
1.2.2 Main Objective . . . 3
1.2.3 Specific Objectives . . . 3
1.2.4 Contributions . . . 3
CHAPTER 2 LITERATURE REVIEW . . . 4
2.1 Methodology . . . 4
2.2 Android and iOS Wireless Capabilities . . . 5
2.3 Type of Networks . . . 5
2.4 Methods for Smartphone Ad Hoc Networking . . . 8
2.4.1 Connection-less Broadcasting . . . 8
2.4.2 Wi-Fi IBSS . . . 9
2.4.3 Scatternet . . . 10
2.4.4 Wi-Fi Direct . . . 11
2.4.5 Peer Switching . . . 11
2.5 Solutions for Heterogeneous Ad Hoc Networks . . . 13
2.5.2 Industry Solutions . . . 14 2.5.3 Wi-Fi Aware . . . 15 2.5.4 Power Usage . . . 15 2.5.5 Review Summary . . . 16 2.6 Proposed Solution . . . 16 2.7 Conclusion . . . 18
CHAPTER 3 MIDDLEWARE ARCHITECTURE FOR INTEGRATING ANDROID IN HETEROGENOUS AD HOC NETWORK . . . 19
3.1 HEAVEN and Application Examples . . . 19
3.2 Proposed Architecture . . . 21
3.3 Bluetooth Low Energy Layer . . . 22
3.3.1 BLE Notions . . . 22
3.3.2 Neighborhood Awareness . . . 25
3.3.3 Message Passing . . . 27
3.3.4 Validation for BLE Compatibility between Android and iOS . . . 30
3.3.5 Summary . . . 30
3.4 Wi-Fi Layer . . . 30
3.4.1 Connection Management . . . 31
3.4.2 Peers Management . . . 31
3.4.3 Controlled Client Population . . . 33
3.4.4 Communication Management . . . 33
3.4.5 Summary . . . 34
3.5 Link Layer . . . 35
3.5.1 Bridge between HEAVEN and Communication Layers . . . 35
3.5.2 Network Management . . . 35
3.5.3 Summary of the Link Layer . . . 43
3.6 Conclusion . . . 46
CHAPTER 4 RESULTS . . . 47
4.1 Methodology and Test Conditions . . . 47
4.2 BLE Discovery . . . 48
4.3 Throughput . . . 50
4.3.1 BLE . . . 50
4.3.2 Wi-Fi . . . 53
4.4 Devices Limitations . . . 56
4.4.2 BLE Clients Limitation . . . 56
4.4.3 Master to Master Communication . . . 57
4.5 Network Maintenance . . . 58 4.6 Power Usage . . . 64 4.7 Discussion . . . 67 CHAPTER 5 CONCLUSIONS . . . 68 5.1 Summary of Contributions . . . 68 5.2 Limitations . . . 68 5.3 Future Research . . . 69 REFERENCES . . . 70 APPENDICES . . . 74
LIST OF TABLES
Table 2.1 Keywords used for MANET literature review . . . 4
Table 2.2 Wireless Ad Hoc Network Scientific Articles . . . 6
Table 2.3 Network Industry Solution . . . 7
Table 2.4 Scientific Articles on Power Usage . . . 7
Table 2.5 Android wireless technologies . . . 7
Table 2.6 iOS wireless capabilities and Android compatibility . . . 8
Table 2.7 Wireless Technology Comparison . . . 17
Table 2.8 Ad Hoc network communication methods summary . . . 17
Table 3.1 BLE Device Capabilities . . . 23
Table 3.2 Wi-Fi Communication Capabilities . . . 33
Table 3.3 Netpower messages . . . 38
Table 4.1 BLE Discovery range (yards) . . . 49
Table 4.2 WiFi throughput in kb/s using Iperf3 . . . 55
Table 4.3 Maximum simultaneous connected client to a WFD Group Owner . . 56
Table 4.4 Maximum BLE Connections . . . 57
Table 4.5 Wi-Fi bridges communication capabilities over role . . . 58
Table 4.6 Average network topology with controlled network density and relay recommended value . . . 63
LIST OF FIGURES
Figure 1.1 Humanitas Ecosystem With Off-the-Grid Network Illustration . . . . 2
Figure 3.1 Application examples . . . 20
Figure 3.2 HEAVEN Middleware architectures . . . 21
Figure 3.3 Bluetooth channels . . . 24
Figure 3.4 GATT Server Example . . . 24
Figure 3.5 BLE advertisement messages . . . 26
Figure 3.6 BLE peers management example . . . 28
Figure 3.7 BLE messages buffer . . . 28
Figure 3.8 Wi-Fi roles . . . 32
Figure 3.9 Wi-Fi communication capabilities experiments . . . 34
Figure 3.10 One-hop propagation . . . 37
Figure 3.11 Netpower Example . . . 37
Figure 3.12 IV propagation example . . . 42
Figure 3.13 Mutation sort example for device C in network with A as root master 45 Figure 3.14 Mutation Sequence . . . 45
Figure 4.1 BLE Discovery Refresh Rate . . . 49
Figure 4.2 BLE throughput on controlled MTU . . . 51
Figure 4.3 BLE Throughput on Controlled Range . . . 51
Figure 4.4 BLE Throughput on Controlled Devices Wi-Fi State . . . 52
Figure 4.5 BLE Sending Method Comparison . . . 52
Figure 4.6 Wi-Fi throughput on controlled range . . . 54
Figure 4.7 Wi-Fi throughput on controlled device BLE state . . . 54
Figure 4.8 Wi-Fi throughput over multi-hop . . . 55
Figure 4.9 Network creation cases . . . 59
Figure 4.10 Network mutation cases . . . 60
Figure 4.11 Time to reach a stable network depending on the number of new devices 62 Figure 4.12 Average time required for network operation . . . 62
Figure 4.13 Application Power Usage per Use Case . . . 66
Figure A.1 Network equivalence . . . 74
LIST OF SYMBOLS AND ACRONYMS
AP Wi-Fi Access Point
API Application Programming Interface ARP Address Resolution Protocol
BLE Bluetooth Low Energy BR Bluetooth Basic Rate
DHCP Dynamic Host Configuration Protocol DTN Delay Tolerant Network
GATT Generic ATTribute
HEAVEN Heterogeneous Embedded Ad-hoc Virtual Emergency Network IBSS Independent Basic Service Set
IoT Internet of Things IP Internet Protocol IV Intent Value LOS Line Of Sight
MAC Media Access Control MANET Mobile Ad-hoc Network MTU Maximum Transmission Unit OSI Open Systems Interconnection P2P Peer-To-Peer
SPAN SmartPhone Ad-Hoc SSID Service Set Identifier STA Wi-Fi Station
TCP Transmission Control Protocol UDP User Datagram Protocol UI User Interface
UUID Universally Unique Identifier VPN Virtual Private Network WFD Wi-Fi Direct
LIST OF APPENDICES
CHAPTER 1 INTRODUCTION
This chapter presents the context, the objectives and the contributions of the research project.
1.1 Context
When a disaster occurs, somewhere in the world, it is possible for telecommunication infras-tructure to be destroyed or damaged, leading to a communication blackout. This situation makes the catastrophe harder to bear both for the citizen and for the troop deployed by humanitarian organizations.
Without the ability to exchange data over distance, it becomes difficult, or worse even impos-sible, to communicate, organize, report a situation, request for resources or any other critical operation. While it could be possible to repair the current infrastructure or to establish a temporary network, both solutions are costly. They require time, knowledge, equipment, and sometimes, it is not enough or even possible to set them on time.
Humanitas, our industrial partner, proposes a set of solutions to help the population and rescue teams during such situations. Figure 1.1 depicts some of these with the inclusion of the off-the-grid network called HEAVEN for Heterogeneous Embedded Ad Hoc Virtual Network. It allows mobile devices as iOS smartphones or drones with Raspberry Pi on board, to communicate together. Android devices are not yet made compatible with HEAVEN.
In an Ad Hoc network, devices have the same capability to connect each other without requiring to be connected to a middle device like a server or a modem. The main challenge is then to establish a routing protocol. Devices must know what are the available peers in the whole network, and which path a packet must follow for reaching a distant target. This type of protocol is already provided in HEAVEN.
HEAVEN provides also heterogeneity. It allows using multiple kinds of devices, iOS smart-phones or micro-computers inside of drone. The hardware will then be different and not all technologies will be available or compatible. Consequently, one of our challenges will be to find a new approach allowing communications between Android and other equipment, espe-cially iOS devices. We will use Bluetooth Low Energy and Wi-Fi communications, as they are the only compatible technologies we have with iOS devices.
Finally, allowing ad hoc communications between Android smartphones will also be a chal-lenge as they are not equipped with a technology designed for this specific type of communi-cation. This problematic has led the academic community to propose multiple contributions
Figure 1.1 Humanitas Ecosystem With Off-the-Grid Network Illustration
but to this date, and to our knowledge, none of them fits keys requirements for an efficient heterogenous ad hoc network dedicated to our situation:
- No modifications of the devices must be done, as it would require specific knowledge to the user,
- For the same reason, the solution must be fully autonomous, no user interaction must be requested,
- Other HEAVEN devices must be able to communicate with Android devices directly, including iOS devices,
- The power usage of the solution must be known and be reduced as much as possible,
- Wi-Fi high-speed communication must be possible.
1.2 Research Question, Objective and contributions
Given the presented context, we are now able to formulate the research questions and the objectives of our contribution.
1.2.1 Research Question
Our thesis answer the following research question:
How to allow Android mobile devices to automatically create and join a heterogeneous ad hoc network?
1.2.2 Main Objective
The main objective of this thesis is to develop methods allowing Android mobile devices to create or join a mobile ad hoc network. This enables the establishment of a heterogenous network based on Wi-Fi communication between Android, iOS and Humanitas IoT computer environment. The objective is also to define a solution fully autonomous, while conserving Android mobile devices from any modifications.
1.2.3 Specific Objectives
The specific objectives defined for this project are:
- Provide HEAVEN for Android mobile devices and allow them to be compatible with the telecommunication ad hoc network as clients,
- Address the challenge of the heterogenous communication network between iOS and Android device.
1.2.4 Contributions
The proposed contributions are:
- Definition and implementation of a middleware architecture integrating Android in heterogeneous ad hoc networks,
- Adaptation of HEAVEN to enable Android device to create and manage their telecom-munication ad hoc network
CHAPTER 2 LITERATURE REVIEW
In this chapter, we review the state of the art on the creation of mobile ad hoc networks (MANET) with handheld devices. We discuss then these solutions and possible improvements before proposing our own implementation.
In the first section we present the methodology followed to select the related works. In the second section we present the iOS and Android wireless compatibility. In the third section, we give the types of ad hoc networks. In section 4, we address the methods for ad hoc networking. In section five, we discuss the existing solutions, then in section 6, we announce our solutions. Finally, in section 7, we give the conclusion of the chapter.
2.1 Methodology
In order to find relevant articles related to our subject, we choose to look for papers based on mobile devices based wireless networks. We also explored papers for computer-based MANET, but the challenges for Android and computer implementations are different. Com-puter solutions heavily focus on routing while Android solutions are challenged on establishing device to device connections. Since our industrial partner provides us a routing algorithm, HEAVEN, we will focus on articles that address wireless communication with handled devices in MANETs.
We did our first research on Compendex, which provides us with a large database as IEEE explore, ACM or Elsevier, and we used the keywords as in Table 2.1.
We also looked for articles on wireless technologies power usage for reference.
Finally, we searched for industry solutions which would provide use real-world situation. All listed solutions were already cited by other articles or provided by Humanitas from their market study.
Theses searches resulted with 25 relevant scientific articles and 5 industry solutions on the
Table 2.1 Keywords used for MANET literature review
Theme Phones Network Wireless
Keywords Android Ad Hoc Wireless
iOS MANET Wi-Fi
Cellphone* SPAN Bluetooth Smartphone*
creation of ad hoc networks for Android. We also gathered two additional articles for power usage. And we include information from Android source code, documentation and technology standards. Table 2.2 lists the selected scientific articles on the creation of MANET and Table 2.3 lists industrial solutions. Table 2.4 gives the additional scientific articles on power usage, which is a metric considered in our evaluations.
2.2 Android and iOS Wireless Capabilities
Android implements various technologies for wireless communications that are summarized in Table 2.5. All technologies are compatible with computers, with the exception of the Wi-Fi Aware1.
iOS also implements various technologies for wireless communication and we listed a few of them in Table 2.6.
It is not possible for iOS to connect to an Android device using Bluetooth Basic Rate (BR). This is induced by an Apple restriction to which iOS device can only connect to device complying with the "Made For iPhone" (MFi) certification [1].
The multipeer connectivity is a technology that allows the creation of mobile ad hoc networks. It is unknown what technologies are actually used for it since Apple advertises it as being a mix between peer-to-peer Wi-Fi, infrastructure Wi-Fi and Bluetooth personal area network. We assume that the existence of such technology is the reason why, aside from Humanitas technology, we dit not find other iOS mobile ad hoc network implementations in scientific papers.
2.3 Type of Networks
Since our solution is oriented for mobile devices, it is expected for devices to appear or disappear frequently. To manage this, previous authors used different approaches that we choose to classify according to the strategy used by a device to manage its connections with other peers.
- Fixed network. We expect devices to create and keep links alive as long as possible. These solutions will have a higher throughput and will benefit from wireless technology power management, while inducing a network management cost.
- Opportunistic network. Without a specific role in this network, connections, if they happen, are ephemeral. This kind of network benefit from a higher flexibility but will
Table 2.2 Wireless Ad Hoc Network Scientific Articles
Author Year Network type Technology kind Require root
Yang 2017 Opportunist AP Switching No
Trifunovic 2015 Opportunist AP Switching No Sikora 2018 Opportunist Broadcasting No Bhojan 2015 Opportunist Broadcasting No
Mao 2014 Opportunist Broadcasting No
Engelhart 2017 Opportunist Broadcasting No
Kumar 2018 Opportunist Broadcasting No
Liu 2016 Opportunist Direct Switching No
Soares 2017 Fixed Wi-Fi IBSS Yes
Zhuang 2013 Fixed Wi-Fi IBSS Yes
Glenstrup 2009 Fixed Scatternet No
Gohs 2011 Fixed Scatternet No
Fujimoto 2016 Fixed Scatternet No
Wong 2014 Fixed Wi-Fi Direct No
Zhang 2014 Fixed Wi-Fi Direct No
Aloi 2017 Fixed Wi-Fi Hybrid or Direct Switching No
Funai 2017 Fixed Wi-Fi Hybrid Yes
Casetti 2014 Fixed Wi-Fi Hybrid No
Oide 2018 Fixed Wi-Fi Hybrid No
Wang 2015 Fixed Wi-Fi Hybrid No
Baresi 2017 Fixed Wi-Fi Hybrid No
Lombera 2013 DTN Wi-Fi IBSS Yes
Lu 2017 DTN Cellular, Wi-Fi IBSS Yes
Takasuka 2018 DTN Google Connection No
Nishiyama 2015 DTN Wi-Fi Direct No
AP: Access Point
IBSS: Independent Basic Service Set DTN: Delay Tolerant Network
Table 2.3 Network Industry Solution
Solution Year Technologies Require iOS
root compatible
Firechat 2014 Cellular No Yes
Wi-Fi STA / AP Scatternet
Open Garden 2011 Cellular No Yes
Wi-Fi STA / AP Scatternet
Thali Project 2015 Scatternet No Yes Right Mesh 2017 Wi-Fi STA / AP Unknown No
Wi-Fi Direct Scatternet
Google Connection API 2017 Wi-Fi STA / AP No No Wi-Fi Direct
Scatternet
Table 2.4 Scientific Articles on Power Usage
Author Year Technologies
Balani 2007 BR, Wi-Fi, Cellular Tosi 2017 BLE
Table 2.5 Android wireless technologies
Technology Android Max LOS iOS Discovery
Version Bit Rate Range Compatible
BLE 4.4 1 mbps 100 m Yes Yes
BR 2.0 3 mbps 100 m Discovery only Yes
Wi-Fi STA 1.0 6930 mbps 200 m Yes Yes
Wi-Fi Direct 4.0 600 mbps 200 m As LC only Yes
Wi-Fi Aware 8.0 6930 mbps 200 m No Yes
Wi-Fi AP 8.0* 6930 mbps 200 m Yes No
Wi-Fi Ad Hoc n/a 6930 mbps 200 m No No
Range is outdoor with a line of sight Bluetooth Standard: 4.0
Wi-Fi standard: IEEE 802.11 ac Wi-Fi Direct standard: IEEE 802.11n Wi-Fi AP available prior Android 8.0 through Java reflection (unofficial)
Table 2.6 iOS wireless capabilities and Android compatibility
Technology Based on Android Compatible
Wi-Fi STA Wi-Fi STA Yes
Wi-Fi AP Wi-Fi AP Yes
BR BR Discovery only
BLE BLE Yes
Multipeer BR or BLE No
connectivity Wi-Fi IBSS or Direct
often have a lower throughput and a higher power usage than persistent connection network using the same technology.
- Delay Tolerant Network (DTN). Similar to opportunistic networks, but devices are expected to hold information and spread it once another group is reached. This kind of network is more suited for data dissemination rather than one-to-one communication.
2.4 Methods for Smartphone Ad Hoc Networking 2.4.1 Connection-less Broadcasting
Some technologies like BR, BLE and Wi-Fi Direct allow to broadcast small amount of data without requiring a connection.
Name Broadcasting
When a device broadcasts its presence, it can include its name. By changing it, it is possible to share data to other devices without requiring a connection. BeaconNet [2] and PASA [3] used this method on multiple technologies, including the usage of Wi-Fi Direct advertising, which is not available on iOS. Experiments show that while it is possible to share data this way, throughput is very low. BeaconNet report a maximum of tens of bytes when sending, and hundreds of bytes when receiving. These values drop when multiple devices try to scan at the same time, leading to network congestion. PASA implementation solves this congestion by analyzing the density and changing the scanning window accordingly. Results show that the network performances stay the same even if the number of devices increases. On the other hand, it takes between 500 and 600 seconds for 5 to 50 devices to share 10 messages of 256 bytes.
Service Broadcasting
Bonjour [4] is a protocol developed by Apple that allows to advertise services which can contain a txtRecord that can technically store up to 255 bytes. Its typical application is for discovering nearby device capabilities like printers or Wireless Speakers. It can be used on a local network, and also over the air. The protocol is also available on Android with the Near Service Discovery (NSD), which requires Wi-Fi Direct.
Mumble [5] is a single hop proposition which gives us the limitation of the Android imple-mentation. Android services can hold up to 85 bytes and there can be up to 13 services for a total of 1105 bytes. They do not provide information on how the services can be refreshed. AssistDirect [6] implemented a routing protocol on top of mumble, allowing multi-hop com-munication. Since Android implementation of Bonjour allows fewer services and less data per service, we can safely assume that this network performance will provide less than 10 kbps.
BLE Broadcasting
Unlike BR, discovery and advertising can be done separately with BLE. With Bluetooth 4.0, when advertising, a BLE device can broadcast up to 37 bytes on one of the three available channels. Version 5.0 added 37 secondary channels on which it is possible to store up to 255 bytes per channel.
Sikora [7] used this method in various terrains and visibility. Experiments show a high rate of missed messages, especially when discovery happens less frequently. No experiment on throughput is given, but we extrapolate a maximum of 930 bps. BLE advertising can refresh every 10 milliseconds at most and allows up to 3 advertising messages of 31 bytes. If the advertising messages change after each refresh, we could obtain a throughput of 930 bps but when we apply the maximum 15% hit measured from article, this throughput drop to 140 bps.
Their experiments also give us data on Bluetooth, BR and BLE, range. When having a line of sight, they manage to reach a range of up to 90 m, and 40 m in heavy foliage jungle.
2.4.2 Wi-Fi IBSS
Like most computer solutions, it is possible with Android to enable the Independent Basic Service Set (IBSS), or Ad Hoc mode, of a device. Ad hoc mode always requires to root the device in order to unlock the ability to configure the network interface. Zhuang [8] developed a framework that does not require kernel modification. However the cost is that all packets
have to be rerouted from the application layer, decreasing the bandwidth.
Soares [9] provided an experimentation to evaluate the capabilities of ad hoc on Android, by changing the kernel. It shows similar performances of a regular STA/AP connection, both on throughput and battery consumption on multi-hop communications and an increased throughput for an increased battery consumption on single hop.
Lu [10] proposes to use IBSS as a fallback for cellular networks. Once leaving the cellular network, the device will communicate using IBSS and store every data it receives. When joining again the cellular network, it spreads the data gathered from the blackout area.
2.4.3 Scatternet
To establish communication between two Bluetooth devices, one of them must be master and the other devices must be slaves. When connected, this network is called a piconet. With BR, and BLE starting version 4.1, a device can assume both roles at the same time, allowing to link piconets together, creating a Scatternet. One point to take into account is that Android devices can have up to 7 active connections as it can be read in the Android source code [11].
For BR, Scatternet implementation has been done with BEDnet [12] for java on computer using JSR-83 Bluetooth API. Authors manage to reach a maximum throughput of 160 kbps in single hop, which is 15% if the maximum throughput BR 2.0 can provide. This throughput is reached when the master device has only one slave. If we add more slaves, the throughput is evenly decreased even if there is no communication with other slaves. This throughput degradation is also present for a slave that is connected to multiple masters, but not as much as in the previous case. Another point is that BR cannot discover devices when exchanging data to others, but it can listen for discovery messages. In order to stay visible to other devices, they alternate between data transfer and advertising.
Beddernet [13] is a port of BEDnet. It uses Android Bluetooth API Instead of the JSR-83 Bluetooth API in BEDnet. The solution manages to reach 700 kbps in a single hop communication but they discover that this throughput level drops depending on the single hop topology. A device with a connection link to multiple devices will have a lower throughput than a device with a single connection link. This decrease of throughput also depends on the role of the device. A master will have its throughput equally divided among its clients. This division does not occur with client devices, but they will still receive a throughput reduction for having multiple masters. Authors assume that it is linked with the sniffing of its master, reducing the communication windows and thus, reducing the throughput.
device, which is required to forms scatternet. Fujimoto [14] proposes a framework that deals with this limitation by prioritizing the device with peripheral capabilities. Their experiments also show the maximum device restriction. When reaching the 7 devices limit, connections between masters and slaves become unstable.
2.4.4 Wi-Fi Direct
Wi-Fi Direct (WFD) is a technology that allows to create star-based networks, like piconet. When triggered between two devices, it will automatically choose which device is the best suited to become the AP. The protocol does not take into account, the rest of the possible devices that will join the network.
Zhang [8] proposes a protocol in order to manage the network creation instead of using the default one. Their results show a 45% throughput improvement and a formation time re-duced by 250%.
Also, when using default connection protocol, Android will require both master and slave device owners, to confirm the connection with a user prompt. This action makes the pure Wi-Fi direct connection impossible to automate by using Android API.
Wong [15] proposes to connect clients as legacy clients. When a device becomes a Wi-Fi Direct hotspot, it actually creates a hotspot with a specific SSID and Passkey. By broad-casting it through Service discovery, it is possible for other devices to connect to this hotspot without any user prompt.
But using only Wi-Fi Direct does not allow to make inter-group connections without discon-necting a device. In order to permit multi-group communications, device will have to switch from group to group which will lead to bandwidth degradation but could also increase power consumption and perturbate routing.
2.4.5 Peer Switching
We call peer switching, methods where a peer will connect to only one peer at a time, and then switch to another in order to establish a multi-hop communication.
BLE Switching
With BLE, devices can operate in two modes: (1) central, which allows to scan for other devices and (2) peripheral, which allows to advertise its presence to others. With Android 4.0, it is not possible to be both a central and a peripheral at the same time. Thus, usage of scatternet is not possible.
To avoid that, Yang [16] proposes a peer switching application based on BLE, called BlueNet. Even if it is possible to have up to 7 active connections with BLE, only one is allowed to be actually connected and transmitting. Thus, a device trying to connect to an already transmitting device will be blocked leading to connection failure and thus decreasing the throughput. To solve this issue, the authors propose four communication modes:
- Aggressive, where all devices try to transmit without supervision,
- Windowed transmission, where a device will not be allowed to communicate with a peer before a set of time when it has disconnected,
- Priority, where devices will prioritize connections to peers they have not been connected to for a while,
- Priority-Windowed based mode mixing both previous modes.
Priority mode show best result for a network with fewer than 50 devices while priority windowed is more suited for networks with more devices.
Wi-Fi AP Switching
With Android 8.0, it is officially possible to create a local hotspot on which an STA device can connect. With prior version, developers had to use Java Reflection for invoking hidden function from the Android Source code.
While it provides a higher throughput than BR and BLE, it is not possible for an Android STA to be connected to two different APs.
In order to create a multi-hop communication, Trifunovic [17] propose their solution, WLAN-opp. Devices without AP on sight will themselves become an AP and then shut down after a time, based on the presence or absence of clients on this AP, but also on the time without having clients. This method allows to avoid draining only one device battery, since being an AP drains more power than an STA.
The author claims that this method allows to reduce by 90% of the energy Wi-Fi ad hoc use.
Wi-Fi Direct Switching
In order to create a multi-hop implementation, Nishiyama [18] proposes a DTN implementa-tion that monitors group activity. When the network activity goes below a threshold, groups disband and restart their network creation. With the movement, the chance that devices reach a group with new devices is high, allowing the data to spread.
Lombera [19] proposes to share metadata telling what data a device hold to a set of peers on reach. Once a device requires this data, it will randomly ask the location of the data, spreading the research to others until it finds the final location and directly connect to it. Another implementation by Aloi [20] proposes to switch between group like the AP switching methods. But this method shows high latency because Android mobile devices take at least 5 seconds to connect to an AP, and 5 more when reconnecting to the previous one.
Liu [21] proposes to make every device a hotspot. When one requires to exchange data, it will then switch off its hotspot and connect to the desired peer until data are transmitted.
Hybrid Wi-Fi Direct
To enable direct communication between Wi-Fi Direct groups, Wang [22] proposes to use both Wi-Fi Direct and Bluetooth. They remark that, since both Wi-Fi Direct and Bluetooth operate in the same frequency, additional interferences are introduced.
Another solution is to use both Wi-Fi Direct and Wi-Fi STA at the same time since they are two different interfaces. This way, it is possible to have a full Wi-Fi speed between groups. Unfortunately, this method has various issues. As explained by Baresi [23], All Wi-Fi Direct Hotspot has a hard-coded IP which makes TCP communication impossible between the hotspot and its clients if they also are a hotspot or they are connected to another hotspot. Also, every unicast packet is redirected to the Wi-Fi interface, which means Wi-Fi direct client cannot use unicast communications with their master. Finally, since the clients IP attribution is automatic and cannot be changed, it is possible to have clients with the same IP in different neighboring groups.
In order to overcome these issues, Funai [24] experiments various connections combination and finally decided to rewrite the Android code in order to allow broadcast communication from clients to master, allowing a role switch.
Baresi [23], Casetti [25] chose to keep one Wi-Fi Direct client as a retransmission unit between Group Owners. The former proposes to use clients as bridges between groups, and the latter connect groups by having clients having their own group.
Oide [26] proposes to automate Casetti implementation by sending hotspot credentials over P2P connections and making the clients reconnect as a Wi-Fi legacy clients.
2.5 Solutions for Heterogeneous Ad Hoc Networks
In this section, we discuss the solutions for heterogeneous ad hoc networks. We will present shortly the industry solutions are and what issues they encountered. We will discuss Wi-Fi
Aware, a new technology that has the potential to make mobile ad hoc networks more viable.
2.5.1 Delay Tolerant Network
In [18] and [10], the authors proposed solutions using both Delay Tolerant Networks (DTN) and Mobile Ad hoc Networks (MANET) to increase the reach of the network. While we also believe this kind of association would provide good results, we choose not to implement DTN in our solution.
Current HEAVEN implementation only permit communication with peers existing in the current network. To parry this situation, Humanitas developed a shared database solution to be added to HEAVEN which will allows to retain information and propage it when peer migrate from network to others, effectively creating a DTN.
2.5.2 Industry Solutions
Thali project [27], sponsored by Microsoft, is a single hop content sharing implementation compatible with Android and iOS. It uses Bluetooth and BLE for Android, and Multipeer Connectivity for iOS. The authors attempted to use Wi-Fi Direct for Android discovery, but they encountered multiple issues with it. It was randomly turning off and not working with devices from different manufacturers. They also propose to use Wi-Fi Direct as hotspots and send SSID and passkey over Bluetooth; however they did not use the Wi-Fi Direct technology due to the unreliability of the discovery and advertising. They choose to only use the BLE approach. The application is available for both Android and iOS. The solution allows a throughput of up to 8 kB/s
Firechat [28], is a messaging app that relies on mesh networks and delay tolerant networks. It can use Bluetooth, Wi-Fi, and internet connections if available, to send messages to its peers. It has been used in 2014 for both manifestations in Iraq and Hong Kong to protest against their government.
Right Mesh [29] application claims to allow the creation of a mesh network with Android, iOS and computer devices. This project uses multiple of previously shown protocols: Bluetooth, Wi-Fi Direct hotspot and Wi-Fi hotspot. Their main feature is a fast switching client that claims to be able to switch between two Wi-Fi networks in less than 200 milliseconds instead of the regular 10 seconds. We assume that solution requires a rooted device in order to achieve this feature.
Nearby [30] and its Connection API allow to create point-to-point, star and mesh networks. Point-to-point and star networks will use both Wi-Fi Direct and Bluetooth Low Energy to
establish a network, but mesh networks will be restricted to Bluetooth low energy. The API is only available for Android devices. Takasuka [31] tested the protocol by doing message and file passing, considering different distances and hops counts. Their tests will show that establishing a connection with other devices takes between 150 and 500 seconds depending on the hop count and the distance. These slow results are explained by the fact that in order to connect to a peer, the API requires devices to see each other, but the discovery can be triggered only once every 30 seconds. Throughput tests show a bitrate depending on the kind of data being sent. When sending a 1 MB packet, they achieve a maximum throughput of 13.1 KB/s (105Kb/s) when sending over 1 hop, for a distance of 25 m. But sending a 55 bytes string for the same configuration take 33 seconds (13b/s).
2.5.3 Wi-Fi Aware
Wi-Fi Aware [32] is a Neighbor Awareness Networking (NAN) protocol. It allows to make the discovery and connection between multiple devices by using both, Wi-Fi and BLE for a battery optimized use cases. Hence, Wi-Fi aware is another solution for creating a MANET, as Multipeer connectivity is.
Unfortunately, this solution has two major issues:
1. Unlike Wi-Fi Direct, which was retro-compatible with existing chips, Wi-Fi Aware requires specific hardware. To this date, there are only few compatible smartphones [33], the Google Pixel 3 (G013A), Google Pixel 3 XL (G013C) and very recently, ten undisclosed Samsung devices.
2. As for Wi-Fi Direct, no iOS device is compatible with this standard and we cannot expect Apple to allow iOS and Android environments to merge.
2.5.4 Power Usage
In [34], [35], [36] and [17], the authors analyzed the power usage of different wireless technolo-gies. From their papers, we conclude that communications with Bluetooth require less energy than with Wi-Fi. Also, using a device as an access point will drain more power than when setting it as a client. For Wi-Fi, an AP or IBSS will have a power consumption 4 times higher than an STA. Scanning and broadcasting avoid triggering technology idle modes, leading to higher consumption as well. Finally, it is more power efficient to send large amounts of data. From this information, we conclude that we can save power by using BLE for discovery and small data exchange, Wi-Fi for large data transmissions.
2.5.5 Review Summary
In our review, we firstly presented the wireless technologies that are available with Android, their theoretical performances are as well as their compatibility with iOS devices. Table 2.7 gives an overview comparing the discussed technologies. We can see that only BLE, Wi-Fi STA Wi-Fi AP and Wi-Fi direct as AP are the only compatible mode with iOS.
We also presented the solutions for ad hoc networking with Android and iOS devices and we found several approaches listed in Table 2.8. From these solutions, we can see a trade-off between connection time and throughput. Broadcasting methods provide no connection time for a very low throughput, scatternet allows a low connection time for a low throughput and Wi-Fi Direct hybrid provides a high connection time for a high throughput. The only exception is the ad hoc method which allows low connection time for high to very high throughput; however it requires to root the device. Only a few solutions are compatible with iOS devices. We can only use BLE or Wi-Fi as STA or AP, including Wi-Fi Direct AP.
2.6 Proposed Solution
Our goal is to develop a solution that allows to create and join ad hoc network with Android, iOS and IoT computers. We also aim for high throughput communications. Only the Wi-Fi Direct Hybridation approaches these criteria, but no contribution allows compatibility with iOS devices as they only use Wi-Fi Direct advertising.
Our approach is then to use both Wi-Fi Hybridation and BLE for a full iOS compatibility. BLE will provide us a low power means of communication while Wi-Fi Hybridation will allow high-speed communications.
We also propose a network management with AP capability considerations. Our review shows that there is no solutions dealing with the limitations of the mobile devices used in the network. For instance, we cannot expect a device to host an unlimited number of clients. We address this aspect in our research project.
Finally, we propose a benchmark for our wireless technologies. Some previous works already considered the usage of BLE with Wi-Fi Hybridation, but none actually did used them together. Their reason was that BLE and Wi-Fi are usually on the same chip and use the same frequency, thus using them together could create interference however, there is no evidence of their claims. We finally propose a full report on various device performances and limitations.
Table 2.7 Wireless Technology Comparison
Technology Root UP SD&C Range iOS C TMDR
BR No Yes Yes 100 m No 3 mbps
BLE No No Yes 100 m Yes 1 mbps
Wi-Fi Ad Hoc Yes No Yes 200 m No 6930 mbps Wi-Fi STA No No No 200 m Yes 6930 mbps Wi-Fi AP No No No 200 m Yes 6930 mbps Wi-Fi Direct No Yes Yes 200 m As AP 600 mbps Wi-Fi Aware No No Yes 200 m No 6930 mbps UP: User Prompt TMDR: Theoretical Max Data Rate
iOS C: iOS Compatible SD&C Simultaneous Discovery and Connection Bluetooth Standard: 4.0 Range when outdoor with a line of sight
Wi-Fi standard: IEEE 802.11 ac Wi-Fi Direct standard: IEEE 802.11n
Table 2.8 Ad Hoc network communication methods summary
Method Technologies Range Throughput Connection
Time
Scatternet BR Small Low Low
Scatternet BLE Small Low Low
BLE Broadcasting BLE Small Very Low None
Name Broadcasting BLE Small Very Low None Name Broadcasting Wi-Fi Direct High Very low None Service Broadcasting Wi-Fi Direct High Low None
Ad Hoc Wi-Fi IBSS High Very High Low
AP Switching Wi-Fi AP/STA High Medium High Wi-Fi Direct Switch Wi-Fi Direct High Medium High Wi-Fi Direct Hybrid Wi-Fi Direct/STA High High High
Method Technologies Power iOS Root
Usage Compatible Required
Scatternet BR Medium No No
Scatternet BLE Low Yes No
BLE Broadcasting BLE Medium Yes No
Name Broadcasting BLE Medium Yes No
Name Broadcasting Wi-Fi Direct High No No Service Broadcasting Wi-Fi Direct High No No
Ad Hoc Wi-Fi IBSS High No Yes
AP Switching Wi-Fi AP/STA High Yes No
Wi-Fi Direct Switch Wi-Fi Direct High No No Wi-Fi Hybridation Wi-Fi Direct/STA High Depend Depend
2.7 Conclusion
In this chapter, we reviewed the state of the art in the domain of ad hoc networking for smartphones, wireless technologies available with Android and iOS devices and their capa-bilities.
We discussed the existing academic and industry solutions. We decided to propose a solution with two communications means, BLE and Wi-Fi Hybridation, allowing high flexibility and power efficiency. We propose also a network management mechanism with device capabilities awareness.
CHAPTER 3 MIDDLEWARE ARCHITECTURE FOR INTEGRATING ANDROID IN HETEROGENOUS AD HOC NETWORK
In this chapter, we present our middleware for Android. Its role is to allow multiple Android devices to be able to connect and exchange with other devices compatible with HEAVEN, the Humanitas mobile ad hoc network software. The middleware must enable a seamless network management, leading to no degradation of the user experience.
3.1 HEAVEN and Application Examples
HEAVEN allows users to join a network to communicate with other devices with multi-hop capabilities.
Devices in HEAVEN networks are identified by a unique four characters address. They can communicate with all the peers in their network, regardless of the number of hops. HEAVEN proposes 4 protocols: TCP, TCP Socket, UDP and UDP Socket. TCP and UDP protocol allows to exchange messages over Bluetooth, Wi-Fi, Li-Fi or any another kind of interface. The drawback is that packet has to go up to the user space before being redirected, which induces major degradation of the bandwidth. On the other hand, TCP socket and UDP socket allow to use regular communications sockets and allow to reach the maximum speed that can be expected over a Wi-Fi connection. The latter require devices to be in the same IP network, which will not be the case for Android devices using the Wi-Fi hybridization methods.
The proposed middleware can be added to any kind of application to send command and get response through the HEAVEN middleware. Figure 3.1 provides two simple examples of application that we run on top of our middleware:
• Figure 3.1.a) shows a command-line application for HEAVEN. The user can input the command to send the HEAVEN server and receive its replies.
• Figure 3.1.b) is a messaging application with a user-friendly interface. The user selects the peer they want to communicate with and sends their messages seamlessly.
(a) (b)
3.2 Proposed Architecture
HEAVEN middleware follows a layered architecture which is depicted in Figure 3.2. Figure 3.2.a) shows the basic architecture of HEAVEN. This version is used by Humanitas IoT computers. It can be used as is by Android devices when connected to one of Humanitas IoT computers.
In order to enable ad hoc network between Android devices, we proposed the architecture seen in Figure 3.2.b). We modified the Link Layer and added our own communications layers, one for the BLE and one for the Wi-Fi which handle both Wi-Fi and Wi-Fi direct (WFD) interfaces.
a) Original Architecture b) Proposed Architecture
Figure 3.2 HEAVEN Middleware architectures
Application Layer
The Application Layer can be any kind of software that requires the communication with other devices. It is able to send commands to, or receive replies from, the HEAVEN layers. For example, this layer could be a messaging client or a remote controller for drones.
HEAVEN Layers
HEAVEN software is developed by our industrial partner, Humanitas. It manages the Trans-port and Routing layers. It will allow devices to send messages over multi-hop.
Link Layer
The Link Layer hold multiple roles in the middleware. The first one is to handle the network management algorithms that will allow the connection between devices. Once devices are connected, its second role is to allow the HEAVEN layers to use the communications layers of Android. Our proposed implementation only allows the usage of the Wi-Fi Layer for HEAVEN communications, but future iteration could use the BLE Layer as well.
BLE Layer
The BLE Layer allows to use the device BLE features. Its role is to allow both emission and reception of messages over BLE, as well to advertise and scan for other devices.
Wi-Fi Layer
Like the BLE Layer, the Wi-Fi Layer allows the control of the device Wi-Fi features. It allows the emission and reception of messages over Wi-Fi, to connect to an AP or become one.
3.3 Bluetooth Low Energy Layer
Bluetooth Low Energy (BLE) is a wireless technology introduced in the 4.0 version of Blue-tooth standard. It is specialized for power efficiency by sending messages through short intermittent bursts rather that stream as with Bluetooth sockets.
This BLE Layer manages the technology-related features: emission, reception, advertising and scanning. For our middleware, the BLE Layer will be essential for neighborhood aware-ness and message passing for network management.
In this section, we will start by providing basic information on how BLE works. Then, we will explain how we perform our neighborhood awareness and what benefits it provides. Next, we present our message passing methods. Finally, we validate the compatibility between Android and iOS devices over BLE.
3.3.1 BLE Notions
This section will present the basic concepts of BLEs. the information are from the Bluetooth standards [37] [38] [39] [40] and Android documentation and guides for BLE [41]. The concepts that are needed to be understood are how BLE devices connect to each other, and how messages can be exchanged.
Advertising and Discovery
BLE devices can operate in central or peripheral mode. A device in central mode can discover and connect to devices operating in peripheral mode. A device in peripheral mode advertises its presence. Central mode is available since Android 4.3 (2012) and Peripheral mode starting with Android 5 (2014). Devices with Bluetooth 4.0 cannot be both, central and peripheral at the same time. It means that once connected, a device will not be able to advertise itself, and thus be connected to, until it disconnects. It was then made possible with Bluetooth 4.1 and later versions. Peripheral support is optional. Table 3.1 shows the capabilities of all the devices we could use during our project. We can see that the nVidia and Dell devices, even though fitting the Android version requirements, are not capable of becoming peripheral.
When a device must be seen by other devices, it must broadcast an advertising packet. A BLE advertising packet is 37 bytes long, with 6 bytes of MAC address and up to 31 bytes of user defined data. These packets are advertised over channels 37, 38 and 39 as depicted in Figure 3.3. It is worth pointing out that these advertising channels are designed not to be in the frequency range of usual Wi-Fi 2.4 GHz channels: 1, 6 and 11. Bluetooth 5.0 allows to use data channels as secondary advertising channels that allow packets to hold up to 255 bytes, each. By using multiple advertising, a BLE device can broadcast up to 9.3 KB. Since both, Bluetooth 5.0 and multiple advertising are only available on higher-end smartphones, we will not use them.
Table 3.1 BLE Device Capabilities
Model Manufacturer Android Bluetooth Central Peripheral Released
Nexus 6 Motorola 7.1 4.1 Yes Yes 2014
Zenfone 2 Asus 6.0 4.0 Yes Yes 2015
Phab2 pro Lenovo 6.0 4.0 Yes Yes 2016
Fire 7 Amazon 5.1 4.0 Yes Yes 2015
Fire 10 Amazon 7.1 4.0 Yes Yes 2015
Galaxy s4 Mini Samsung 4.4 4.0 Yes No 2013
Venue 8 7000 Dell 5.0 4.0 Yes No 2015
Shield (Tablet) Nvidia 7.0 4.0 Yes No 2015
Galaxy Note 8 Samsung 9.0 5.0 Yes Yes 2017
Figure 3.3 Bluetooth channels
GATT Server
In order to exchange data between devices, one device must host a GATT1 server that hold:
service, characteristic and descriptor. All of these elements are defined by a unique identifier called Universal Unique Identifier (UUID).
A service is a container of data for a specific use, such as temperature monitoring.
Characteristics are the data related to this service. For example, for the temperature moni-toring, there would be only one characteristic, the temperature value.
Descriptors provide more information on its attached characteristic. With our temperature example, a descriptor could hold the unit used, Celsius, Fahrenheit or Kelvin.
Figure 3.4 provides another example of a GATT server.
1GATT: Generic Attribute Profile
Connections
Android source code specifies in [11] that a device can have up to 7 active connections at the same time. Our tests show that further connection attempt will fail after a few seconds. Establishing a connection with a peer will trigger a callback related to the device role. For devices with BLE 4.0 chips, both callbacks will be triggered. The same goes for the discon-nection, but only the central will receive the callback immediately. The peripheral will be informed of the client disconnection only after the connection timer run out. This mean it is impossible to accurately know how many devices are connected to a peripheral.
3.3.2 Neighborhood Awareness
One major aspect of our middleware is to make devices able to know what their neighbors are. This step is required to perform our network management and we call it the neighborhood awareness. For these purposes, devices use the BLE advertising and discovery features. This requires to set up the advertising packet, and to handle the peers discovered.
Advertisement Packet
Each device must to be identifiable. Since Android 6.0, the advertising MAC address of a device is periodically randomized, making it impossible to recognize devices from it. Thus, devices will include their HEAVEN address in their advertisement. Devices must also notify that they have a connectable GATT server for message passing. The discovery mechanism must be able to look for HEAVEN devices only. Finally, devices must include their trans-mission power, as it has been requested by Humanitas for future localization purposes.
A BLE advertising packet is split in multiple fields, each of them includes one byte for the field length, another for the field type and a various sized field by the data it carries.
Figure 3.5 shows our advertisement messages. The first field is the connectable flag, which tells if devices can connect to this GATT server. The second field is the TX Power flag which will be used by Humanitas for their own uses. The third field is a Service UUID that will be used for discovery filtering, allowing devices to only detect HEAVEN devices. The final field will allow to get HEAVEN address. The message in Figure 3.5.a) hold a Service Data field and the message in Figure 3.5.b) has a Device name field.
We would prefer to use a Service Data field instead of a Device name field to carry the HEAVEN address. As it requires not to change the Bluetooth name of a device, which would confuse a user. Unfortunately, we do not have enough space to include it. Both, Connectable and TX Power Flag fields use 3 bytes, Service UUID field uses 18 bytes which leaves only
7 remaining bytes. A Service Data field requires 2 flag bytes, UUID requires 2 bytes and the HEAVEN Address requires 4 bytes, for a total of 8 bytes. It gives a final advertising packet of a length of 32 bytes, which is one byte too long. By using device name instead, we can shorten the field by 2 bytes which make it short enough for advertising at the cost of decreased user experience as it changes its device Bluetooth name.
Discovery and Peer Management
Android Bluetooth discovery is made periodically once triggered. Four parameters are used to set this period:
- SCAN_MODE_LOW_LATENCY,
- SCAN_MODE_BALANCED,
- SCAN_MODE_LOW_POWER,
- SCAN_MODE_OPPORTUNISTIC.
In the Opportunistic mode, the Bluetooth controller does not request for a scan for this application but instead is waiting for other applications to do so. Then, it gets the results of their scans. Low Latency is the mode with the highest refresh rate, Low Power the smallest and Balance is a trade-off between the last two. In [7], the author reported that scanning frequency has a notable impact on the battery. Since devices will have to scan permanently, we choose the Low Power mode.
Every time the Bluetooth controller triggers a discovery, it reports each sensed device. In order to avoid spamming the Link Layer by discovery reports, we implemented a simple peer
management that will only notify new and lost peers. Peer names are stored in a list with the timestamp of when they were last seen. When a device is seen and is not in the peer list, it is reported as a new peer. When a device has not been seen for 2 minutes, we remove it from the peer list and report it as lost peers. To detect which device cannot be seen anymore, we perform a presence check every 15 seconds that will compare the last seen timestamp of peers with the current time. Figure 3.6 provides an example of the management.
Figure 3.6.a) shows a scan update with a device that is already in the peer list, then only its timestamp value is updated.
Figure 3.6.b) shows a scan update with a device that was not previously saved in the peer list, a callback is then called notifying that a new peer has been spotted.
Figure 3.6.c) shows a presence check where all devices have been seen in the last ten minutes, thus no device is removed from the peer list.
Figure 3.6.d) shows a presence check where one device has not been seen in the last ten minutes. It then gets removed from the peer list and is reported as lost.
3.3.3 Message Passing
Devices communicate over BLE by updating the GATT server characteristic of the peer they are connected to. Each device has its own GATT server with one characteristic only. When a device must send a message to a peer, it will connect to it and update that characteristic to pass its message. In order to avoid reaching the 7 simultaneous connection restrictions, devices immediately disconnect once they have passed their messages. But this connection operation has a cost. We measured that the average time to establish a connection were between 0.5 and 2 seconds. The worst connection time was around 10 seconds.
To reduce this connection cost, devices buffer the sending of their messages. Figure 3.7 shows the proposed buffer queues. The blue queue represents the list of peers with the stored messages that must be sent to them. Messages are shown in the green queues. The current target value represents the peer that this device is trying to exchange with.
Message Insertion
When a new message has to be inserted in the sending queue, we check the target and the message type. If the message is meant for a target that is currently not in the target queue, a new entry is created. The current target is not considered as being in the target queue. Thus, it is not possible to add new messages to the message queue of the current target, it will instead be added to the sending queue. Message type allows to avoid duplicate messages in a queue. It is mostly used for network maintenance messages where information needs to be
Figure 3.6 BLE peers management example
updated frequently. New messages and new targets are added at the end of their respective queue. If a message is typed and there is already another message with the same type in the message queue, the new message will overwrite the old one.
Message Sending
Algorithm 1 shows how the sending protocol works. Each time a new message is inserted, it triggers a sending request. The request is granted if the device is not currently sending or if it was forced. If granted, all remaining messages of the current target are stored back in the buffer following the message insertion protocol. The first inserted target of the target queue become then the new current target and a connection attempt are initiated to it. Once the connection has succeeded, the first message of the message queue is sent to the target and removed from the queue. This operation repeats until all the messages have been sent. A send operation allows up to three send attempts, otherwise the message is considered as dropped, an error is thrown and a forced send request is issued. This can happen when a device is no longer visible and the disconnection event has not yet been triggered by the Bluetooth controller. Target can also disconnect during the sending. The current implementation does not ensure the good transmission of messages. Even when Android triggers a send success event, the recipient device might have not received the full message. The current sending rate is an issue with some devices, with a sending success rate being lower than 25%. Improving this issue is a high-priority requirement for future works.
Algorithm 1: BLE Sending Protocol
1 insert message in the buffer queue;
2 if Ble is not sending or sending is forced then 3 while has next peer do
4 store remaining current peer message at the back of the buffer queue; 5 store next peer in current peers;
6 connect to current peers;
7 while have next message and no error occurred do
8 send;
9 end
10 disconnect.;
11 end
3.3.4 Validation for BLE Compatibility between Android and iOS
In order to confirm that Android and iOS can communicate using BLE, we chose to manually perform the operation of a message sending by using the application nRF Connect created by the Bluetooth chip manufacturer, Nordic Semiconductor2.
With this application, it was possible to perform the following actions:
• Set iOS device advertisement packet. One difference is that we could not set a custom UUID for the service and we do not know if changing the name of an iPhone require a user interaction,
• Scan for devices with the same service filter as Android,
• Make the iOS device connect to the Android device and update the value of its char-acteristic,
• Make the Android device connect to the iOS device and update the value of its char-acteristic.
This experiment shows that iOS devices are able to perform every action with Android devices that we need for our middleware.
3.3.5 Summary
In this section, we presented our BLE Layer which allows the usage of BLE features. This layer enable devices to discover each other and communicate without authentification. This layer will be used by the Link Layer for the Network Management.
3.4 Wi-Fi Layer
The Wi-Fi Layer allows High-Speed communications between devices. It will be used to convey messages for the HEAVEN upper layers with other devices. This layer is inspired by the Wi-Fi Hybridation methods used in [24] [23] [25] [15], which use both WFD and Wi-Fi, allowing devices to establish multiple Wi-Fi connections simultaneously.
We will begin by explaining how connections between devices are managed. Then, we will explain how devices keep track of their active connections within our peer management mod-ule. Next, we will present how we handle AP limitations with the client control management. Finally, we explain how we decided to allow communication between peers.
3.4.1 Connection Management
Wi-Fi requires devices to connect to each other before they can communicate together. Si-multaneous connection capability is required for all devices in order to be able to create a multiple-group network. Also, the connection must require no user interactions.
To qualify to these requirements, we use the Wi-Fi hybridization methods. The WFD inter-face is used as AP and the Wi-Fi interinter-face as STA. Depending on the connection state, the capabilities of devices change. We use the adjectives: Master, Client and Bridge to classify device connection states. In Figure 3.8, the device AAAA is a master because its WFD interface is set as an AP, device CCCC is a client because its Wi-Fi interface is set as a STA and device BBBB is a bridge because the two types of interfaces, Wi-Fi and WFD are used. To allow a device to connect automatically to an AP, it programmatically adds the AP net-work name (SSID) and security key (Passkey) to its netnet-works configuration. When running Link Layer network management, the SSID and Passkey will be shared over BLE.
Finally, when a client connects to a master, the master internal DHCP server, a system that manages the assignment of IP address in a network, will provide an IP address to the client but will not report it to the master. Thus, once a client connect, it must send its IP and HEAVEN address to its master who will recognize it as a client. We noticed that the first exchange between two devices must always be an unicast message. All broadcasts are dis-carded before that first unicast exchange. Due to this, master will not be able to join other AP. Once connected, master role evolves to bridge, and we will see that bridges cannot send unicast messages to their master.
3.4.2 Peers Management
Once the connection succeeds, and the IP message has been shared, a device has to manage this new peer. As with the BLE Layer, the Wi-Fi Layer must track to what peers are connected. We classify peers as:
• Master, the AP a device is connected to,
• Clients, the STA that are connected to this device AP,
• Neighbors, the STA connected to the same master as this device.
Figure 3.8 provide an example from device BBBB perspective. Different methods are required in order to track each kind of peer.
Master presence can be tracked from the device Wi-Fi connection status. After sending the IP message of the connection management, the master responds to that message to confirm
Figure 3.8 Wi-Fi roles
its presence. The peer is thus added to the peer list as a master.
When the Wi-Fi disconnects, it means that the master is no longer reachable and it is then removed from the list.
A device cannot natively track the presence of its client with Android API. WFD API allows to track WFD clients but not WFD Legacy clients. WFD clients connect using the WFD interface while Legacy clients use their Wi-Fi interface. Then, a master can detect the presence of a new client with its IP message from the connection management and then add it to the peer list.
To detect client disconnections, we propose a heartbeat protocol close to the BLE peers tracking method. Clients have to periodically, every 15 seconds, send an empty heartbeat message to their master who will, on reception, save the current time as a last-seen value. Masters then periodically check the last-seen value of each of their clients. If a device has not been seen in the last 45 seconds, it is removed from the client list.
Our initial approach of neighbor tracking was to broadcast each client list update of the mas-ter to its clients. We finally chose to forbid communications between neighbors, which made the tracking pointless. Each AP and their clients have the same network, 192.168.49.0/24. From this, a bridge will have its client in a network that is different from its neighbors but both networks have the same IP range. It is then possible to have an IP conflicts between theses two networks. Thus we choose to forbid direct communications with neighbors for the current version of the project. It will still be possible to communicate with them when using HEAVEN multi-hop capabilities.
3.4.3 Controlled Client Population
Google support page specifies that a hotspot can host up to 10 clients simultaneously [42]. To avoid reaching the limit, we propose a crowd control protocol. Each connection has to be requested. The AP will provide a response that depends on the number of clients it already has.
Each master can have up to 10 clients, but we reduced the number of recommended clients to 5. A client sending a request to a master that has fewer than 5 clients will always be approved. If there are between 5 and 9 clients, the request will only be accepted if it was marked as a forced request by the sender. If a master has 10 clients, it will always be rejected. We choose to set this recommended size value to reduce the strain on master nodes, both for energy and bandwidth usage. We also suspect that not all devices will be able to hold the same number of clients. Thus we decided to allow the customization of both the maximum and the recommended number of clients. Hence, our related protocol messages will hold each device-specific value.
We allow to exceed the number of recommended clients in case a device has no other choice but to connect to a specific master that is or will be overcrowded once connected. When this situation happens, it will trigger a network mutation protocol that will issue a solution to modify the network topology, and reach a state where the considered master is no longer overcrowded.
3.4.4 Communication Management
With the Wi-Fi Hybridation method, the type of communication mean will depend on the device roles. Android allows TCP communication with its Socket class, and UDP with DatagramSocket. In [23] [24] and [25], a master (or bridges) cannot communicate with a client having a bridge role. Authors explain that the implementation of Android induced this limitation.
In order to confirm their result, we did a set of experiments reported in Figure 3.9, while
Table 3.2 Wi-Fi Communication Capabilities
Master to Client Client to Master Master Client TCP U UDP U UDP B TCP U UDP U UDP B
Master Client Yes Yes No Yes Yes Yes
Bridge Client Yes Yes No Yes Yes Yes
Master Bridge No Yes No No No Yes
