BWMesh: a multi-hop connectivity framework on Android for proximity ...

BWMesh: a multi-hop connectivity framework on Android for proximity service Yufeng Wang

Jing Tang

Nanjing University of Posts and Telecomm., China

Nanjing University of Posts and Telecomm., China

Qun Jin Waseda University, Japan Abstract—Considering the inherent properties of privacy protection and battery efficiency, Device-to-Device (D2D) based proximity service (ProSe) has recently witnessed great development, which enable user to continuously and passively search for and utilize relevant value in one's physical proximity, and is capable to create numerous new mobile service opportunities. However, most of existing ProSe enabled frameworks and applications only provide single-hop Peer-toPeer connection, lack of easily supporting simultaneous and multi-hop connection on commercially available smartphones to broaden ProSe coverage in static scenario. To solve this issue, this paper proposes a multi-hop connectivity framework BWMesh, through combining Bluetooth and WiFi Direct technologies. BWMesh possesses two special features: exploit users' heterogeneous network and enable smooth interaction among devices with different wireless technologies; provide an easy-todeploy multi-hop networking framework on currently commercial available smartphones. Specifically, we identify several key issues in multi-hop connectivity framework, design and implement corresponding components to deal with those issues. Then, a prototype MultiChat, is developed based on BWMesh framework, which enables real-time chat among users in proximity, in multi-hop way, without accessing to Internet. Keywords—Proximiy Serivce; Heterogenous networks; WiFi Direct; Bluetooth

I.

INTRODUCTION

Recently, with rich connectivities and features, smartphones today are capable of extending our presence virtually. Thus, proximity service (ProSe) has become a promising mobile industry that is capable to create new mobile service opportunities and offload traffic. The purpose of ProSe applications is to discover instances of the applications running on devices within proximity of each other, and ultimately exchange application-related contents [1]. With ProSe, people's virtual interactions become more location-centric and tied to their current physical neighborhood. This is different from the rather static "friend lists" in typical online social interactions. Generally, ProSe can be composed of two main groups of use cases: public safety communications and discovery mode (commercial applications). On one hand, the ability to support direct Ad-hoc communication is a core requirement for public safety use cases, when the devices are in proximity, and the network is down or when the device is out of coverage (e.g., in the situations of disaster rescue), as it may take too much time to install new communication equipments and restore damaged infrastructure. On the other hand, much more than just a "friend finder", commercial discovery mode could establish a paradigm shift from the Personal Computer (PC) "search-to-

Jianhua Ma Hosei University, Japan discover" mindset, to always-on discovery services that are fundamental to defining the next generation of mobile service. Especially, mobile social networking and application in proximity (e.g., chat, gaming, etc) is a typical application field of discovery mode [2]. Basically, existing technologies used to serve the proximity awareness can be broadly divided into two categories: overthe-top (OTT), and Device-to-Device (D2D) solutions. In the OTT model, the centralized server (usually located in the cloud) receives periodic location updates from user mobile devices (e.g., using GPS, etc). The server then determines proximity based on location updates and interests. The constant location updates not only result in significant battery impact because of GPS power consumption and the periodic establishment of cellular connections, but also cause the serious privacy problem. Moreover, OTT approaches may incur undesired network overheads and latency for discovery and communication. D2D allows two devices to communicate directly, i.e., without the data path being routed via the network infrastructure. The proximity range depends on the strength of the radio signal and other radio conditions such as interference. The actual range varies depending on the power level used for transmitting the radio signal. D2D based ProSe schemes forego centralized processing in identifying relevancy matches, and instead autonomously determine the relevance at the device level by transmitting and monitoring for relevant attributes. This approach offers crucial privacy benefits. In addition, keeping discovery on the device rather than in the cloud, allows for user-level's controls over what is shared. Typical D2D enabled communications technologies include Bluetooth, and Wi-Fi Direct, etc. As the popularity of D2D based ProSe, there have been many proximity solutions or applications presented. However, most of ProSe enabled frameworks and applications only provide single-hop networking on commercially available smartphones, and, through exploiting users' mobility, adopt the so-called store-carry-forward (SCF) paradigm to disseminate contents. That is, when two devices encounter, they exchange the information they are carrying, store the information and forward it to next encountered devices, thus increasing the reach of shared information to distant users or large group of users. However, static scenarios (e.g., public transports, campus, bars, concert, etc.) are also popular in ProSe applications. Furthermore, most traces have highlighted that individuals are stationary for a large portion of time interrupted by mobility events. However, in research and application literatures, there are lack of easy-to-deploy schemes to support multi-hop

connectivity (fulfilling the so-called wireless mesh networking (WMN)) on commercially available smartphones. Most existing WMN enabled ProSe frameworks and applications are confined to research labs and small scale testbeds. There are several reasons for this: Ad-hoc mode and WiFi virtualization mode are not directly supported by off-the-shelf mobile terminals (need mobiles to be rooted), and mobile AP (Access Point) mode and WLAN connection can't be used simultaneously. The goal of this paper is to alleviate the limitations described above by providing applications with support for heterogeneous networks to increase inter-connectivity potential. Heterogeneous networks means that a class of networks in which different elements may be connected to each other using different communication methods [3]. Specifically, we propose BWMesh, an alternative framework to enable simultaneous and multi-hop networking, through integrating WiFi Direct and Bluetooth technologies that are widely available in smartphones. BWMesh has the following two special features: exploit the users' heterogeneous networks, and enable the smooth interaction among devices with different wireless technologies; provide an easy-to-deploy multi-hop networking framework on currently commercial available smartphones. The remainder of the paper is organized as follows. In section II, we briefly summarize the existing multi-hop connectivity solutions, and their disadvantages. The proposed multi-hop connectivity framework, BWMesh is presented in Section III, including the key issues and the corresponding components. In Section IV, a BWMesh based prototype called MultiChat, is developed on Android phones, to illustrate the applicability of BWMesh framework. Finally, we briefly conclude the paper and point out future work. II.

RELATED WORK

The increasing penetration of smartphones with extended communication capabilities (3G/LTE, Wi-Fi, Bluetooth) opens new networking possibilities. D2D based ProSe is one promising dimension which would bring networks back to the users and may instill the excitement of the Internet debut again. Traditionally, D2D networking mainly consists of local, opportunistic, and single-hop communication (e.g. WiFi Direct, WiFi mobile AP and Bluetooth, etc), whereas multi-hop networking and forwarding schemes are typically needed to extend the coverage of ProSe applications. Basically, D2D based ProSe forwarding schemes can be divided into the following two categories. • Store-carry-forward multi-hop schemes (or asynchronous schemes), in which, single-hop direct networking technologies are intrinsically utilized. That is, users in single-hop contact area exchange and store data; and through users' mobility, the data could be propagated. Those schemes are actually based on single-hop direct networking (not mesh networking). • Wireless mesh schemes (or synchronous schemes), in which, each mobile terminal simultaneously connects to more than one other terminals, and relays to widen the communications range in synchronous way. Through exploiting users' mobility and utilizing store-carryforward pattern, single-hop networking based ProSe can

disseminate contents in local area, however, static scenarios (e.g., public transports, campus, bars, concert, etc.) are also popular in ProSe applications. Besides, most traces have highlighted that individuals are mostly stationary for a large portion of time interrupted by mobility events. In this case, mobile ad-hoc networks (MANETs) are needed. Generally, WiFi can be configured in one of two modes, infrastructure mode and ad-hoc mode. Nearly all WiFi setups use infrastructure mode, where client devices within range all connect to and communicate through a central wireless access point. While, it seems that the ad-hoc mode appears especially suited to set up MANET between a wide range of heterogeneous devices. However, software restrictions on modern mobile operation systems (e.g., Android and iOS, etc.), actually prevents mobile devices from actively participating in ad-hoc networks without circumventing vendor barriers (i.e., acquiring root access). Probably, WiFi Ad-Hoc based ProSe applications could be not full-fledged on most popular phones in the near future, if ever, due to poor support by operating systems, inability to use it in parallel with infrastructure mode, lack of support for address allocation, lack of security, and relatively low speed, etc. In contrast, full support for 802.11 infrastructure mode networks is a commodity even on closed platforms and embedded WiFi systems. However, traditional WiFi infrastructure mode is not suited for ad-hoc establishment of multi-hop networks, primarily since its software part is unable to provide the necessary flexibility in topology. MA-WiFi [4] presented an approach for 802.11 infrastructure mode ad-hoc networks in which mobile devices simultaneously function as an access point and as a station to mesh with other mobile devices that assume both roles, thereby establishing multi-hop communication networks in WiFi infrastructure mode. WiFi-Opp [5] also leverages the mobile WiFi AP feature (also known as tethering) as well as stationary open APs to support opportunistic communications between classical WiFi client. It proposes that some mobile devices themselves switch spontaneously to mobile APs. This can be achieved by putting the mobile device in the so called tethering or mobile AP mode. While this mode is initially meant to share one's 3G Internet access to clients, it can be used for client-toclient communications and even mobile AP-to-client communications thus enabling opportunistic communications. However, in practice, implementation of multi-hop networking based on the role switching is challenging: Can't deployed easily on commercial off-the-shelf devices, for it is not inherently supported by currently popular mobile operating systems, and customerized codes should be installed to enable the special functionality (may require to change the hardware drivers in smartphones). Furthermore, another weakpoint of the randomized switching lies in that: WiFi Network Interface Card have to dis-associate and re-associate with a network whenever a switching is required, leading to significant downtime and packet loss. Recently, LTE Direct is a newly emerging and innovative D2D technology that enables discovering thousands of devices and their services in the proximity of ~500m, in a privacy sensitive and battery efficient way [6]. it allows the discovery to be "Always ON" and autonomous. LET Direct works in licensed spectrum, and is under control by mobile operators.

However, unfortunately, given the many technical challenges and disjoint opinions of 3GPP (the 3rd Generation Partnership Project) member companies, "product" is not expected for several years, thus the immediate attention of industrial players is on D2D in the unlicensed bands, including WiFi and Bluetooth. The most related technique is The Multipeer Connectivity Framework, introduced in iOS 7 (and later version), which provides support for discovering services existing in nearby iOS devices, and subsequently interacts with those services by sending message-based data, streaming data, and resources (such as files) [7]. The typical application developed based on "Multi-peer connectivity Framework" API, is FireChat on iOS platforms, which enables users chat with nearby people, even if there is no phone coverage or Internet connection. However, for Android devices, a proprietary mesh networking technology is designed to support direct FireChat messaging among nearby users [8]. III.

•

ARCHITECTURE OF BWMESH

As described above, despite the increasing penetration of smartphones, easy-to-deploy D2D based ProSe networking framework is not feasible with most popular mobile devices. This paper designs and implements a multi-hop connectivity framework BWMesh on Android, to present an alternative approach to the above issue. BWMesh can discover and connect users in proximity smoothly through integrating the technologies of Bluetooth and WiFi Direct, transmit messages, and provide network status to applications developed on it.

•

•

Fig. 1.

Illustration of multi-hop networking in BWMesh framework.

As depicted in Fig 1, image that device C has its WiFi Direct radio enabled, but not its Bluetooth radio. The device A has its Bluetooth radio enabled, but not its Wi-Fi Direct radio. The device B has both its Bluetooth and Wi-Fi Direct radios enabled. The device B can communicate with the device C using WiFi, and communicate with the device B using Bluetooth. Then, the device C can also communicate with the device A because the device B is acting as a bridge. All of this connectivity is taken care by the BWMesh Framework. Ideally, the following key issues should be considered in BWMesh framework: peer discovery, peer connectivity, naming and addressing, and message forwarding, etc. • Peer discovery. It denotes the process of discovering peers in physical proximity and retrieving the content/service preference metadata from the peer. The

result of peer discovery may be processed further by system or users to determine whether the peer is worth connect to. During peer discovery, a discovering device will periodically broadcasts proximity beacons to announce its existence, while other devices periodically scan and each may respond to this message once it receives the beacon. Besides the peer discovery, it is imperative to conduct service discovery, prior to the establishment of connection: Peers could exchange queries to discover the set of available services and, based on this, decide whether to continue to interact or not. Peer connectivity. ProSe must ensure with high probability that nearby users remain connected, which means a mechanism is needed to guarantee the connectivity among different communication services. For example, when the Bluetooth radio is out of range, the WiFi Direct radio could be switched on. The connectivity of networks rely on the support of system architecture. Naming and addressing. Different connectivity situations and different applications require different address types, for example, the use of local connectivity to share data with neighbor might use a Bluetooth or a 802.11 MAC address as a address. Note that different nodes might regard different types of name as "addressable" because of their different capabilities—to a node with geographic information and forwarding capabilities, a geographic coordinate is an addressable name, while to another node, a semantic name may need to be mapped onto another address type before forwarding can occur. It is imperative to investigate how to translate the high-level names into lower-level addresses used for networking functionality and data transmission. Message forwarding. A network abstraction is needed to enable the routing/message forwarding among users in proximity with different communications technologies (i.e., Bluetooth and WiFi Direct). Generally, D2D link is single-hop, whereas multi-hop forwarding schemes are typically needed to extend the coverage, through which devices communicate directly with their neighbors, and messages from one node to another are forwarded through the mesh via intermediate nodes. Forwarding policy in proximity service varies from epidemic replication of all the messages to every node, through to multi-copy and single-copy forwarding. Flooding-based protocols with unlimited replicas of messages cause high demand on network resources, such as storage and bandwidth and cause congestion. However, multi-copy protocols typically aim to limit the number of replicas of the message in order to leverage a tradeoff between resource usage and probability of message delivery. Single-copy strategies require routing algorithms to implement a next-best-hop heuristic that forwards the messages to those nodes with a highest probability to deliver the message to its destination. Preliminarily, we just fulfill the simple flooding-based forwarding, and will implement other strategies in future work.

communications range, and displays the found peers on user's smartphone. The peer monitor module is responsible for monitoring network connections. For example, when the connection requests come in, proper reactions should be taken. The peer connection module can complete single-hop P2P connection and message transmission, which can happen between two Bluetooth terminals or WiFi Direct terminals. Connectivity objects in BWMesh must support a well-defined interface including functionality for opening/using/closing communications channels. The message forwarding module in a relaying node forwards messages received from one wireless network interface (e.g., Bluetooth) to another network interface (e.g., WiFi Direct) to expand communications range for proximity service. Fig. 2.

Framework of BWMesh.

Fig. 2 illustrates the logical architecture of BWMesh framework for ProSe, including three layers: networking (technology) layer, middle (function) layer and typical application layer. The networking technology layer is composed of wireless networking technologies that are used for building physical communities, WiFi Direct and Bluetooth. WiFi Direct builds upon the 802.11 infrastructure mode and lets devices negotiate who will take over the soft AP-like functionalities. Legacy WiFi devices may seamlessly connect to WiFi Direct devices. By making this decision, WiFi Direct immediately inherits all the enhanced QoS, power saving, and security mechanisms [9]. Thus, given the wide base of devices with WiFi capabilities, and the fact that it can be entirely implemented in software over traditional WiFi radios, WiFi Direct technology is expected to have a significant impact on ProSe. Bluetooth is also one of the most well-known and widely used short-range communication technologies. The middle layer includes functionalities that are necessary for BWMesh framework to function properly. This layer contains four modules: naming and addressing, peer discovery and monitoring, peer connection, and message forwarding, which work together to preliminarily deal with the key issues mentioned above. Naming and addressing module. In BWMesh, two heterogeneous wireless networking technologies are adopted, and each mobile device possesses two physical addresses: Bluetooth related and WiFi related. Instead of using those physical addresses, we utilize the intrinsic device serial number (unique to each device) as the device's addresses, to forward messages in routing level. Furthermore, each use can arbitrarily set her device's name readable to human beings. To guarantee the unique of those identities, BWMesh integrates the userdefined semantic name with the intrinsic device serial number to uniquely identify an individual at the application level. Peer discovery and monitoring. Peer discovery module is responsible for discovering nearby users through both Bluetooth and WiFi Direct. Considering that BWMesh simultaneously embraces two heterogeneous networking technologies, it is therefore appropriate for different connectivity interfaces to be used. Specifically, this module searches Bluetooth and WiFi Direct devices available in

Fig. 3.

Message format in BWMesh.

Especially, Fig. 3 shows the message format designed for multi-hop forwarding, which is composed of four parts (each part can be parsed through corresponding prefix). Specifically, the prefix HOP_NUM denotes the number of experienced hops transferred from the message source; "USER_NAME" is the user-defined name by source; "DEVICE_TAG" is the unique device serial number; "PAYLOAD_TXT" includes the payload transmitted by source node. Note that, the key words of HOP_NUM, USER_NAME, DEVICE_TAG, and PAYLOAD_TXT are reserved in BWMesh, and should not be used in BWMesh and applications built on it. When any node (including edge node and relaying node) received the formatted message, she can parse each part, and extract the payload. A relaying node can check if the "DEVICE_TAG" in the message is identical to her device serial number, if same (it implies that it is the message that has been sent by herself before), she just abandons this message; otherwise, she adds one to the field of "HOP_NUM" in the message, and broadcasts this message in another wireless interface. Note that the middle function layer provides two fundamental services to applications developed on it: data sending/receiving and network status update. The application layer includes a wide variety of services that can be developed on top of the middle function layer, including public safety communications (disaster rescue, dissemination of emergency data, etc.), and commercial applications (interactive chat, multiplayer games, etc.). IV.

BWMESH BASED PROTOTYPE: MULTICHAT

In this section, we designed and implemented a BWMesh based prototype, MultiChat, which enables users chat with nearby people in multi-hop way, when they are beyond one single-hop WiFi Direct coverage or without Internet connection. The forwarding node can re-share chat messages using different communication method when receives chat messages through Bluetooth or Wi-Fi Direct. Fig.4 illustrates a typical application scenario of MultiChat, in which there exist four mobile devices A, B, C, D. User A and User D have their Bluetooth radio enabled but not their Wi-Fi Direct radio. User B and User C have both their Bluetooth and Wi-Fi Direct radios enabled. Link AB is a

Bluetooth connection, link BC is a Wi-Fi Direct connection, and link CD is a Bluetooth connection. MultiChat can enable A to chat with D through the intervention in B and C to save and re-share chat messages using a different communication method.

Fig. 4.

Fig.5(a), Fig.5(b), Fig. 5(c), and Fig. 5(d) respectively illustrate the screenshots of User A, B, C and D sending and receiving text messages. For those figures, the message sent by the very user of herself (prefixed with the symbol "me") is located in a read ellipse, and messages received from other user (prefixed with the user's nickname) is located in a green ellipse. From those figures, we can easily observe that the message "Alice" sent by user A can be successfully received by all other Users B, C and D.

Typical scenario of Multichat based on BWMesh framework.

In the scenario shown as Fig. 4, User A and User D first search nearby Bluetooth devices. User B searches nearby WiFi Direct devices. After successfully searching nearby devices, User A requests a Bluetooth connection to User B. User B requests a WiFi Direct connection to User C. User D requests a Bluetooth connection to User C. After those connections have been established, they can send and receive text messages with each other in multi-hop way. Note that, in the following screenshots, the nicknames of users A, B, C and D are respectively set as Alice, Bob, Cindy, and Dog.

(a) User A

(a) User A

(b) User B

(c) User C Fig. 6.

(c) User C Fig. 5.

(b) User B

(d) User D

Screenshots of Users A, B, C and D sending and receiving text messages with MultiChat.

(d) User D

Screenshots of the corresponding users and the number of hops from other Users.

Fig. 6(a), Fig. 6(b), Fig. 6(c), and Fig.6 (d) illustrate the connected users and their hops from users A, B, C and D respectively. For example, from Fig.6 (d), we can clearly observe that the users connected (in multi-hop) to user D are

users A, B and C (associated with each user's nickname and device serial number). Moreover, the corresponding hops of those users from the user D are also given. V.

CONCLUSION AND FUTURE WORK

Recently, D2D based ProSe is an exciting and innovative feature for mobile industry. It can facilitate the interoperability between critical public safety networks and ubiquitous commercial networks. In this paper, we presented a multi-peer connectivity framework on Android platform, BWMesh, by which users can establish multi-hop connection with nearby users in static and infrastructure-free environments, through integrating two typical direct D2D technologies, WiFi Direct and Bluetooth. To illustrate the applicability of BWMesh, a prototype MultiChat, is developed on this framework, which enables users to have real-time chat among nearby users in multi-hop way. However, the framework BWMesh is preliminary, and can be significantly improved from the following aspects. • From application viewpoint, WiFi Direct and Bluetooth require mandatory user-assisted device paring, and when configuring the network, the devices acting as group owners in WiFi direct and masters in Bluetooth have to be launched first to wait for connection requests from the devices being the role of clients. This process will make the user quite cumbersome. Probably, it is feasible to utilize the "Insecure Bluetooth" to connect two Bluetooth devices without manually pairing the devices. For WiFi Direct pairing, there are workarounds to avoid the need for user interaction via hidden API, which might be officially provided in near future [10]. • From networking viewpoint, the future work should incorporate a more complex and realistic topology settings with existence of different multi-hop routes among devices (in comparison with the simple scenario shown in Fig. 4). Also, the impact of identical messages arriving from different routes due to broadcasting should be evaluated. Furthermore, proper routing mechanisms should be implemented in BWMesh framework, instead of the simple flooding scheme implemented in this paper. • From the viewpoint of wireless communications, since Bluetooth and 802.11b/g WiFi systems both operate in the 2.4 GHz band, interference occurs when a Bluetooth and a WLAN device are in close proximity and attempt to transmit and receive wireless signals at the same time, it would be interesting to add experimental evaluation for BWMesh and its upper applications, such as energy consumption, etc. ACKKNOWLEDGMENT This work was supported by the National Natural Science Foundation of China under Grant 61171092, and the JiangSu Educational Bureau Project under Grant 14KJA510004, the JiangSu 973 Program under Grant BK2011027 and Prospective Research Project on Future Networks (JiangSu Future Networks Innovation Institute). REFERENCES

[1]

Chieh-Jan Mike Liang, Haozhun Jin, Yang Yang, Li Zhang, and Feng Zhao, "Crossroads: A Framework for Developing Proximity-based Social Interactions," In Proc. of the Mobiquitous, 2013. [2] Yufeng Wang, Athanasios V. Vasilakos, Qun Jin, and Jianhua Ma. "Survey on mobile social networking in proximity (MSNP): approaches, challenges and architecture," ACM/Springer, Wireless Networks (WINET), Volume 20, Issue 6, 2014, Page 1295-1311. [3] Daniel J. Dubois, et al., "Supporting heterogeneous networks and pervasive storage in mobile content-sharing middleware," In Proc. IEEE CCNC, 2015. [4] H. Wirtz, et al., "Establishing mobile ad-hoc networks in 802.11 infrastructure mode," In Proc. of the 6th ACM workshop on Challenged networks. 2011. [5] S. Trifunovic, et al., "WiFi-Opp: ad-hoc-less opportunistic networking," In Proc. of the 6th ACM workshop on Challenged networks. 2011. [6] Xingqin Lin, Jeffrey G. Andrews, Amitabha Ghosh, and Rapeepat Ratasuk, "An Overview of 3GPP Device-to-Device proximity services," IEEE Communications Magazine, Volume 5, Issue 4, April 2014. [7] About Multipeer Connectivity. Available at: https://developer.apple.com/library/prerelease/ios/documentation/Multip eerConnectivity/Reference/MultipeerConnectivityFramework/index.htm l [8] Firechat, Available at: https://opengarden.com/firechat. [9] D. Camps-Mur, A. Garcia-Saavedra, and P. Serrano, "Device to device communications with wifi direct: overview and experimentation," IEEE Wireless Communications Magazine, Vol. 20, No. 3, 2013. [10] Wi-Fi Direct API for connection acceptance. Available at: https://code.google.com/p/android/issues/detail?id=30880