Disconnected islands in a sea of
connectivity
Ciaran Fisher 1st Year PhD
University of Sussex
Dan Chalmers Ian Wakeman Steve Naicken Jon Rimmer
Overview
• Digital Stadium Project
• EPSRC
• Produce a working DTN useable in the real world
• Engage with the public to make the DTN something they want to use
• Stadium scenario chosen
The Solution
• Pocket Switched Network – Subset of Delay Tolerant Networks
– Phones network with phones sharing data producing a distributed cache of common content
– Previous attempts have relied on tethering
– Overlay network
• Based on Android
• Other solutions targeted just one android version or required root
Our Solution
The Solution
• Operating System based on the Linux kernel by Google
• Programmed in Java
– Every app runs in its own VM
– Strict permissions model
– Easy App sideloading
What is Android?
The Solution Android Fragmentation
Data collected during a 14-day period ending on June 3, 2013. Source: http://developer.android.com/about/dashboards/index.html
The Solution Android Fragmentation
Gingerbread
Ice Cream Sandwich
Jelly Bean
1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35
Count
Andro
id V
ers
ion
SDK: 2.3.3 2.3.4 2.3.5 2.3.6 4.0.3 4.0.4 4.1.1 4.1.2 4.2.2
The Solution
• Bluetooth
– Poor manufacture implementations
• Wi-Fi via tethering
– Unrestricted internet access for all
• Ad Hoc Wi-Fi
– Not part of standard API – requires root
• Wi-Fi Direct + Legacy Mode
– The solution!
Connectivity
The Solution
• API added in Ice Cream Sandwich – Oct 2011
• Allows Ad Hoc Phone to Phone Connection
• Unfortunately requires user input
Wifi Direct
The Solution
• Creates a “normal” access point visible to all wifi devices
• DHCP
• No internet connection - Advantage
• Random SSID and password
• Major differences between ICS, JB 4.1 and JB 4.2 implementation
Wifi Direct Legacy Mode
The Solution Bootstrapping
Phone becomes Access point
The Solution Bootstrapping
Sends data to rendezvous server
Web Service
The Solution Bootstrapping
Client Phone downloads the AP details from rendezvous server
Web Service
AP Client
The Solution Bootstrapping
Client connects to AP with no external prompts needed using a “normal” Wi-Fi connection
Web Service
AP Client
The Solution Bootstrapping
Phones Exchange cache information
Web Service
AP Client
AP receives client requests and delivers responses
System Architecture
User Interface
Background Services
Asynchronous Data Request
Response
System Architecture
• Background Services: – LRU Cache of JSON containing http pages
– Asset Request list
– Network Service
– AP Service • Brings up the Access point for clients to connect to
• Switches to client mode after 6 minutes
– Client Service • Switches to AP mode (if supported) if it has no
connection within 1 minute
System Architecture
Example Request:
{url: “…/latestscores”, modified: 1370553092000}
Example Response:
{url: “…/latestscores”, modified: 1370553092000, content:”<html></html>”}
UI Update
User enters view in app, E.g. Twitter
UI Update
Asynchronous message sent to backend service with last updated time.
LRU Cache
Asset Request
UI Update
• Cache Hit - Data is broadcast • Received by listener in the UI • Data is type is checked to see if matches current
view • If it matches UI is updated
LRU Cache
Asset Response
UI Update
Cache Hit but stale data Data is broadcast and received by listener in the UI Asset request also generated
LRU Cache Asset
Request List
Asset Request
Asset Response
The Solution Supporting GET
Web Service
AP
Request: scores newer than x
Client Requests scores
The Solution Supporting GET
Web Service
AP
AP checks cache, distributes request
Request
Request
Request
Request
The Solution Supporting GET
Web Service
AP
AP resolves the request Marks request resolved
Request
Request
Request
Request
Response
The Solution Supporting GET
Web Service
AP
AP distributes response
Request
Request
Request
Response
Response
Response
Response
The Solution Supporting GET
Web Service
AP
Marks Requests as resolved
Request
Request
Request
Response
Response
Response
Response
The Solution Supporting GET
Web Service
AP
UI update broadcast
Response
Response
Response
Response
The Solution Supporting POST
Web Service
AP
User posts Tweet
The Solution Supporting POST
Web Service
AP
AP floods POST to other nodes ensuring delivery
The Solution Supporting POST
Web Service
AP
AP delivers post Unique message ID is logged by server
The Solution Supporting POST
Web Service
AP
Subsequent posts with the same unique ID are ignored
The Solution Supporting POST
Web Service
AP
AP distributes message telling any node that connected that the post was successful, removing it from connected nodes
The Solution Data Dissemination
• Epidemic routing tried to ensure requests are spread far through the network to increase the likelihood of a node getting a connection
• DTN client nodes connect to different AP’s helping to disseminate data
Additional University benefits
• Successful deployment at the BHAFC vs Wolves
• Over the DTN: 40MB between 67 participants
Results
Additional University benefits
Results Views Page
1524 LiveScores608 Twitter
362 LeagueTable156 Status
81 CurrentMatch38 Placeholder31 Preferences
25 Trains22 About17 Results13 Traffic8 Bus
6 News6 Fixtures4 Feedback1 Store
30
40
50
60
70
11:00 12:00 13:00 14:00
Time (GMT)
Battery
Level
0.00
0.25
0.50
0.75
1.00
103
105
107
Time (ms)
P(X≤x) Network
dtn
mob
Cumulative Distribution Function of RTTs
Additional University benefits
• Drop support for older phones enabling the rendezvous server to be removed as users upgrade
• Work on routing requests to nodes likely to have a connection – My PhD
• Work on making AP more intelligent – Don’t be an AP if many are nearby
• Further research latest API changes allowing fixed access point names and passwords
Future Work
Questions?