1887

Abstract

Smartphones are nowadays widely available and popular in first, second and third world countries. Nevertheless, their connectivity is limited to GPRS/UMTS/LTE connections with small monthly data plans even if the devices are nearby. Local communication options such as Bluetooth or NFC on the other hand only provide very poor data rates. Future applications envision smartphones and tablets as main working and leisure devices. Envisioning the upcoming trends on multimedia and working documents, file sizes are expected to grow further. In strong contrast to this, smartphone users are faced with very small data plans per month that they can use to communicate over the Internet. In maximum a few GB are available per month, while regularly 1 GB or much less mobile data traffic is available to smartphone users worldwide. Thus, the future data exchange between smartphones and tablets is very much limited through the current technology and business models. Even if the business models on wireless Internet plans would allow unlimited data exchange, still most regions of the world would be limited in connectivity and data exchange options. This striking limitation in the connectivity of the future's main communication devices, namely smartphones and tablets, is striking as with current solutions the data exchange between these devices is strongly handicapped. Taking into account that data exchange and synchronization often takes place to geographically close areas, to closeby friends or nearby colleagues, it is very strange that the local data exchange is so strongly limited due to missing or traffic-limited connectivity to the Internet.

In this presentation, we present a novel approach to enhance high speed data transfers between smartphones and/or tablets in local environments. In specific, we enable with our approach high transmission speeds of up to empirically tested 60 Mbit/s between nearby nodes in any environment. Our approach does not require any contract with Mobile Internet Providers and is not limited to any data plan restriction. We introduce a novel IEEE 802.11 Infrastructure Mode based mesh networking approach, which allows Android phones to create multihop mesh networks, despite the limitation of the WiFi standard. With this approach, wireless multihop networks can be built and are evaluated in empirical measurements, allowing the automatic synchronization and data exchange between smartphones and tablets in the near of up to 100 meters for a single hop and several wireless hops distance. The use cases are considering colleagues working in the same building that would like to exchange data on their smartphones and tablets. The data requests and offerings are thereby signaled in the multihop environment and dedicated wireless high-speed connections are established to transfer the data. Another use case is the local communication with mails, images and chat messages with friends nearby. As the communication approach also supports multicasting, several users can be addressed with single messages. Another use case is a wireless file sharing or data exchange service which allows users to specify their interest such as in action movies at a campus or information on sale promotions in a mall. While the user walks along, his smartphone picks up relevant data without user interaction. One relevant use case for Qatar is the area of smart cities, smart devices would also be able to pick up sensor data from buildings, local transport vehicles or citizens in a delay-tolerant fashion and thus using the GPS functionality of Android to deliver accurate sensor information tagged with the location and time of the sensor snapshot. Finally, this local, high-speed wireless data synchronization approach allows to implement a data-synchronization approach such as Dropbox, Box or PowerFolder between Smartphones and tablets, a novel feature on the market. To implement this idea, we are collaborating with PowerFolder, Germany's market leader in the field of data synchronization at universities and in academia. From the technology side, we observe that Android has a market share of around 80% worldwide as operating system of smartphones. While Android supports very well the connection to the Internet and cloud-based services, it only offers Bluetooth and NFC for local connectivity, both technologies only provide very low data rates. Wifi-Direct is also supported but requires similarly to Bluetooth lots of user interaction and thus does not scale to many contact partners. The IEEE 802.11 standard supports an ad hoc mode for local, high-speed wireless communication. Unfortunately, Android does not support the IEEE 802.11 ad hoc mode which would allow local high speed connections of up to 11 Mbit/s. Instead, we use the Infrastructure Mode of IEEE 802.11 to create ad hoc wireless mesh networks which support much higher data rates, of up to 54 Mbit/s and even more. Please note that WiFi Direct also claims to allow similar performance, but it heavily requires user interaction and failed in our empirical studies to connected more than 3–4 nodes reliably, we are aiming for hundreds of nodes interaction in a delay-tolerant manner without user interaction. Our aim is to 1. use only unrooted Android functionality, 2. to allow nodes to find themselves through the wireless medium, 3. to automatically connect and exchange signaling information without user interaction, 4. to decide on messages to exchange in a delay-tolerant manner supporting opportunistic networking, 5. to coordinate the transmission between various nodes in case that more than one node is in proximity, 6. allow single hop data transfers based on the signaled have and need information,7. allow multihop node discovery and thus 8. multihop routing of data packets. We reach our aim through using the unrooted Android API that allows apps to open a WiFi hotspot for Internet tethering. While we do not want to use the Internet, the service also allows clients to connect to the hotspot and to exchange messages with the hotspot. Using this approach, i.e. when an Android phone or tablet opens a hotspot, other Android devices running the App can join in without user interaction. For that the App on the joining node creates a list of known WiFi networks, which are consistently named: “P2P-Hotspot-[PublicKeyOfHotspotNode]”. The public key of the hotspot node is used as unique identifier of the node and as option to asymmetrically encrypt the communication to that node. With this Android API functionalities we are able to dynamically connect unrooted, casual Android devices that run our App. The IEEE 802.11 Infrastructure Mode that we are using brings the characteristics that the access point, in our case the hotspot, is engaged in any communication with attached clients. Clients can only communicate to each other through the hotspot. The clients all share the available bandwidth of the WiFi cell to communicate to the hotspot. Thus for a set of nodes, it is more advisable to have dedicated 1-to-1 connections with one node being the hotspot and the other one the client for fast high-speed transmission rather than having all nodes connected over the hotspot and sharing their bandwidth. In order to to support this, we differentiate between a dedicated signaling phase and a dedicated data transfer phase. Nodes are scanning the available WiFi networks and look for specific SSIDs, namely “P2P-Hotspot-[PublicKeyOfHotspotNode]”, these are available hotspots. As the App considers these networks as known and the access key is hardcoded, a direct connection can be established without user interaction. These steps fulfill requirements 1. and 2. Next, the node is signaling the data it contains for the various destination nodes also addressed to nodes with specific public keys as node identifiers. The nodes can also signal data that they generally share based on a keyword basis. The hotspot gathers these signaling information from its clients and creates an index on which node has what (have list) and wants what (want list). Based on this, the potential matches can be calculated and are communicated to the clients. In order to have direct high speed connections, these node release their connection to the hotspot and establish a new connection between each other: one as a hotspot and one as connected client. This step is very dynamic and allows closely located nodes to connect and exchange data based on their signaling to the previous hotspot. The freshly connected nodes also signal again their offerings and interest, to confirm the match. The following high speed 1-to-1 data transfer can reach up to 60 Mbit/s, which is much more than the 11 Mbit/s of the traditional IEEE 802.11 ad hoc mode. Once they are done with the transfer, they release their link and listen again on the presence of coordinating hotspots. If no hotspot is available, based on random timeouts, they themselves offer this role and create a hotspot. Hotspots are only actively waiting for clients for a short time and then trying to join in a hotspot themselves. The roles fluctuate constantly. Thus the network is constantly providing connection options to nearby nodes through dynamic hotspotting. Hotspots index the content of connected clients and coordinate ideally matching 1-to-1 pairs for high speed transfers. Thus, requirements 2.-6. are resolved. Finally, to implement requirements 7. and 8., the nodes also maintain the information on the hotspots they met and the nodes they exchanged data with, thus creating a time depending local view on the network. In addition to the signaling of the data files they offer, the nodes also signal to hotspots they meet their connectivity history. Hotspots on the other side share this information with newly joining clients, thus creating a virtual view on the topology of the network. Using this information, nodes can decide in which direction, i.e. over which nodes, to route a message, multihop routing is supported. Step-by-step and in a delay tolerant manner, data packets can be passed on until they reach the destination. This approach for opportunistic, multihop routing is fulfilling requirement 6 and 7. In close cooperation with PowerFolder, we implemented this approach and evaluated the feasibility and performance of the approach. PowerFolder is the leading data synchronization solution in the German market and allows to synchronize data between desktop PCs. With our extension, it is also possible to synchronize data across smartphone and tablets directly, thus saving mobile data traffic available in the data plan and on the other side supporting a fast and one of its class transmission speeds. We implemented our approach in an Android app and performed various tests on the connectivity speed, the transmission times and the reliability of the solution. Our measurements show that transmission speeds of up to 60 Mbit/s are reached in the closest proximity and even around 10 Mbit/s are obtainable in 100 meters distance. The multihop functionality is working reliably with a decrease in the transmission speed related to the distance and the number of hops. We also experimented with direct hop-wise and end-to-end transmission encryption and the resulting security gain. The encryption speed is reasonable for small files. Please note that using the public key infrastructure which we established, it is both possible to encrypt data hop-by-hop but as well end-to-end. Our approach presents a novel networking approach for the future connected usage of smartphones and tables in the information-based society. Addressing one of the grand challenges of Qatar, we are optimistic that the approach is also very suitable in Qatar to support the societies' shift towards better usability and more secure and higher bandwidth data exchange.

Loading

Article metrics loading...

/content/papers/10.5339/qfarc.2016.ICTPP2257
2016-03-21
2019-11-19
Loading full text...

Full text loading...

http://instance.metastore.ingenta.com/content/papers/10.5339/qfarc.2016.ICTPP2257
Loading
This is a required field
Please enter a valid email address
Approval was a Success
Invalid data
An Error Occurred
Approval was partially successful, following selected items could not be processed due to error