Keywords

1 Introduction

In recent years, our daily use of electronic devices and the Internet changed dramatically. The massive increase in smartphone usage and the ever increasing coverage with high-speed Internet services have affected the way we work and live. The vision of all devices around us connected and cooperating with each other for the sake of our comfort or a more sustainable lifestyle is getting closer.

Almost all of nowadays communication-based services require a network connection and a central processing point and thus infrastructure. However, there are several scenarios which have to work without a connection. Either, the infrastructure is not available due to missing coverage, overload or a disaster or the user is not willing to use it. As a result, research emerged on infrastructure-less communication mainly referred to as Opportunistic Networks (OppNets) or opportunistic services. Much effort has been invested by researchers in understanding how data dissemination works in these environments and how to ensure certain quality of service. These services are also highly interesting for the Internet of Things (IoT), as they offer interoperability among various manufacturers and systems. All they need is a common format for exchanging data and a common communication interface. The biggest advantage is that they offer a direct and geographically localized interface between the "things" such as sensors or actuators and the end users. Thus, opportunistic services could become one of the driving factors of the IoT. However, data dissemination and quality of service are still under research, which needs active cooperation from real users. Motivating users is probably the main non-technical challenge in this area.

Developing real world OppNets is not trivial, though. Since there is no standard or semi-standard communication technology, especially designed for OppNets, developers have started using existing technologies in non-usual ways or are extending them. However, our own experience [2] have taught us that most of the solutions are not optimal and trade-offs are the rule.

This paper compares all broadly available communication technologies for OppNets. We explicitly focus on two of their properties: user friendliness and energy consumption. More concretely, we offer:

  1. 1.

    A concise survey of existing technologies and their uses for implementing opportunistic services for end-user devices (smartphones) in Sect. 2

  2. 2.

    A qualitative comparison of their properties and technical details in Sect. 3

  3. 3.

    An experimental comparison of their energy consumption in Sect. 4

2 Background and Related Works

The most widespread end-user device is nowadays the smartphone. Other IoT devices, are left out of the scope, since they usually provide researchers with more flexibility for implementation than end-user devices. Thus, in this study, we explore the usage of a smartphone for testing and evaluating OppNets.

Mainly two technologies are used for implementing OppNets: WiFi and Bluetooth and their variants. They are both available on most smartphone platforms.

WiFi or IEEE 802.11 is being used in three different variants: traditional WiFi, WiFi direct and WiFi ad hoc. The ad hoc mode is deprecated and not available on Android and iOS, unless the phones are rooted or jailbroken. In WiFi direct, one phone acts as an access point (AP), the other as a client. Several technologies like service discovery are used to ease the usage. The traditional WiFi consists of APs and clients whereas nowadays smartphones can act as both. The authors in [10] use WiFi APs to transmit data in an opportunistic way between the nodes. They use static APs as well as mobile phones acting so. The authors in [13] suggest an ad hoc networking model designed for Bluetooth Low Energy (BLE), WiFi and classic Bluetooth. An implementation using WiFi SSIDs is provided. The opportunistic short message service introduced in [12] is also based on a WiFi SSIDs for transmitting the data and has been evaluated with 20 smartphones.

Bluetooth or IEEE 802.15.1 exists in two different variants: traditional Bluetooth (before 4.0) and Bluetooth Low Energy (BLE, 4.0 and up). BLE has been designed for low power consumption and is currently available on most modern smartphones and on some IoT platforms. A device discovery protocol for Bluetooth 2.1 was introduced in [5]. In there, the authors also measure the energy consumption of their approach and compare WiFi to Bluetooth on Nokia N900 Smartphones. bCards@PerCom—2012 Footnote 1 is an Android app for exchanging business cards during conferences. It uses Bluetooth to detect proximity but the contact details are exchanged using a central server. A wireless mesh protocol for IPv6 is introduced in [7] where the authors use the Generic Access Profile (GAP) (BLE advertisements) which was introduced in Bluetooth 4.0.

Hybrid approaches combine WiFi and Bluetooth for communication. The authors in [8] use WiFi and Bluetooth to detect proximity and use this data to determine whether opportunistic communication is feasible. In [11], the authors compare the energy consumption of their OppNet application with WiFi and BLE. In some way, this resembles the work presented by us here. However, we offer an application-agnostic detailed comparison of all available technologies.

Using OppNets to offload data from 3G mobile networks is suggested in [4]. Valuable work on the energy consumption of the different technologies was provided, but unfortunately the explored technologies are deprecated.

There are also frameworks for opportunistic communications, such as Google’s NearbyFootnote 2 and Apple’s Multipeer Connectivity Framework Footnote 3. However, Nearby requires Internet connection and internally uses a central server to establish the connection. Thus, it cannot be used for truly OppNets. Apple’s Multipeer framework as introduced in iOS 7 allows to connect two devices without an Internet connection. To achieve this, it uses a combination of WiFi and BLE. Unfortunately, it is proprietary and only available on iOS.

To the best of our knowledge, FireChat [9] is the only application which supports real infrastructureless communication. They use Apple’s Multipeer framework for inter iOS communication and a combination of WiFi and BLE for the communication between Android phones and Android and iOS phones.

As already mentioned above, the main goal of most of the above publications is the research on OppNets, not their implementation. However, the concrete implementation has a great impact on the achieved results (e.g. user motivation to use the service, number of users targeted, etc.). For example, some of the implementations impact the normal usage of WiFi networks, which is uncomfortable for the users. Others severely impact the power consumption of the smartphones and leaves the user without power in the middle of a busy day. In the next section, we will compare these technologies and their variants in terms of their technical details, properties and usability.

3 Comparison of the Technologies

Table 1 gives an overview of the considered technologies and their variants, as identified in the previous section. It summarizes their options, effects and their support in the main operating systems (Android and iOS).

WiFi Direct. WiFi direct is mainly used by Android based phones and is not supported by iOS. It is meant for transmitting data with high data rates and does not allow the parallel usage of the WiFi interface for other purposes (e.g. browsing the web). The absolute energy consumption is high (see Sect. 4 for details). Due to security reasons, it requires user authentication for each connection, e.g. by entering a PIN, scanning a QR-code, etc.

WiFi SSID or Tethering. Almost all current smartphones can act as an access point (AP) (tether) and the broadcasted SSID can be used as information carrier. As a phone cannot act as an AP and scan for available APs at the same time, it has to switch between both modes to send/receive data. Meanwhile no Internet connection via WiFi is possible. According to [6], the maximum size of the SSID is 32 bytes which corresponds to the maximum amount of data transmitted and thus limits the data rate. Providing an AP and actively scanning for nearby APs requires a high amount of energy. As the data is broadcasted using the SSID, no pairing or user interaction is required.

WiFi Ad Hoc. Similarly to WiFi Direct, WiFi ad hoc supports high packet sizes and high data rates. The energy consumption is high and no parallel usage is possible (as for all WiFi based approaches). The ad hoc mode is only supported by certain rooted Android phones and not available for iOS unless they are jailbroken. As the phone has to be rooted anyway, the pairing could be adapted according to the requirements. The rooting is also the major drawback of the solution: It is not feasible for the majority of the non-technical users.

Table 1. Qualitative comparison of technologies for OppNets
Full size table

Classic Bluetooth. The classic Bluetooth starting at version 2.0 with Enhanced Data Rate (EDR) supports unlimited data sizes and a data rate of 2.1 MBit/s. The energy consumption is low compared to WiFi and pairing is required for normal operation. However, several implementations of OppNets managed to overcome the pairing using different approaches. The main trick is to allow smartphones to communicate to each other, if they are registered on the same server. This requires an Internet connection and is thus not suitable for real opportunistic communication. It is possible to use several Bluetooth connections at the same time and the standard is supported by all smartphones.

Bluetooth Low Energy. BLE is an energy optimized Bluetooth standard available since version 4.2 [1]. It is designed for energy constrained devices like smart watches and sensors. The standard offers the Generic Attribute Prole (GATT) for transmitting small amounts of data and GAP (advertisements) for broadcasts which was originally developed for location based services (beacons) on dedicated hardware. Recent iOS and Android phones support transmitting BLE beacons (Android since 5.0, iOS since iOS 7). Especially the BLE beacons seem to be ideal for OppNets as no pairing is required and the user can use other Bluetooth devices in parallel. Additionally, the energy consumption is very low. Unfortunately, the size of one frame is quite low with a maximum of 31 bytes using raw frames and 20 bytes sticking to the beacon standard.

In the next section, the energy consumption of the variants of WiFi and Bluetooth are measured and compared.

4 Measurement of Selected Energy Consumption Profiles

In this section, the energy consumption of different technologies is monitored and compared in an application-agnostic way.

Measurement Setup. For the energy measurements an Android reference platform is used: Google’s Nexus 6P [3]. It supports all required technologies, runs on Android 6 and has a 3450 mAh battery. We use a brand new phone (factory defaults). The phone has no SIM card and the cellular connection and GPS are disabled. The only installed Apps (besides Android’s standard Apps) are EnergyMonitor Footnote 4 and Locate Beacon Footnote 5. Locate Beacon is an example App for transmitting BLE beacons in Android. EnergyMonitor logs the battery level as percentage, the time and the charging status to an internal database.

For each experiment, the phone is fully charged, switched to the mode for the corresponding experiment and left untouched till the battery is completely drained. The side effects of charging and discharging the battery are neglected. Using this general setup, the following measurements were performed:

  • Flight mode: The phone is switched to flight mode and no App or communication technology is used. This results in the maximum achievable battery lifetime and serves as a reference for all other measurements.

  • BLE beacons: Only Bluetooth is enable. The App Locate Beacon is enabled and set to transmit beacons with the maximum transmit power and the maximum transmit interval of 10 beacons per second. This corresponds to an opportunistic communication app using BLE beacons.

  • WiFi not connected: Only WiFi is enabled and no WiFi AP is in range. This causes the phone to scan continuously for WiFi networks.

  • WiFi connected: This demonstrates how Android behaves if an AP is in range, as compared to no AP in range. The real energy consumption of an OppNet application would then lie somewhere between these two profiles.

  • Tethering/AP: In this measurement, the phone acts as an AP. It transmits a WiFi SSID and offers a connection. This corresponds to the worst case energy consumption for WiFi direct and apps using SSIDs for information dissemination.

  • FireChat: FireChat (version 7.9.9) is a well known Apps running on Android and iOS for OppNets with a notable number of users. We use it as an example app to set the other results into the context to a real world implementation.

Fig. 1.
figure 1

Energy consumption of different communication technologies (WiFi, Bluetooth)

Full size image

Measurement Results. Fig. 1 depicts the energy consumption of the different technologies. It can be seen that switching on the tethering mode on a Smartphone (i.e. turning it to an AP) increases the energy consumption significantly compared to all other applications. Acting as a WiFi client is optimized on Android and thus results into an acceptable battery lifetime. Here, a difference can be seen between the results with and without a paired AP in range: If an AP is in range, the battery lifetime is increased by 19% (496.6 h instead of 417.2 h). If no AP is in range, Android performs more WiFi scans to find a suitable network. This increases the energy consumption. Transmitting BLE beacons is highly optimized. Although we set the phone to the most energy consuming BLE mode, i.e. high transmit power, 10 beacons per second, the battery lifetime is still high and still 86% of the time achieved in flight mode.

FireChat is the only opportunistic communication app with a notable number of users. Comparing the energy consumption with the other results shows, that developers seem to use mainly WiFi to transmit data: The battery lifetime is even lower then the lifetime achieved by acting as an AP.

The graphs in Fig. 1 are almost perfectly linear besides humps at the battery level below 11% caused by the internal battery behaviour and circuits.

Discussion. Current implementations and test setups for OppNets focus on data dissemination and quality of service. The user experience is neglected by most of them. The comparison from Sect. 3 and the measurements from Sect. 4 show that the primary everyday usage is significantly effected by an opportunistic app. It acts like a secondary phone user and decreases the battery lifetime or occupies fully some services, like the WiFi connection. To achieve a meaningful spreading of these applications and to foster research on them, the negative side-effects have to be reduced to a minimum. From our results, using state-of-the-art BLE technologies, including the upcoming Bluetooth 5 seems to be suitable and the number of BLE enabled phones is constantly increasing.

Another solution might be WiFi, but security and energy issues are not to be easily resolved. We believe that WiFi based OppNets on phones will disappear.

Security is a very major challenge in OppNets. Bluetooth and especially the new Bluetooth 5 is expected to handle well security. For WiFi, this issue is not solved very well and either requires the user to authorize every single transmission or is simply disabled. This is another reason to focus on Bluetooth.

Another candidate for OppNets is IEEE 802.15.4 (ZigBee). It is widely available for IoT devices, but for almost no end-user device.

5 Conclusion and Future Work

In this paper, we performed a detailed analysis of available communication technologies for implementing OppNets. We explored their properties and user friendliness and experimentally compared their energy consumption. We came to the conclusion that state-of-the-art Bluetooth technologies are best suited for truly opportunistic services, which affect only minimally the comfort of the users.

Next we will explore the upcoming Bluetooth 5 standard. Furthermore, we will explore interoperability between smartphones and IoT devices in OppNets.