by Aruna Balasubramanian Ratul Mahajan Arun Venkataramani University of Massachusetts Microsoft Research Presented by Ashok Kumar J CS 752852 Wireless and Mobile Networking ID: 217751
Download Presentation The PPT/PDF document "Augmenting Mobile 3G Using WiFi" is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
Slide1
Augmenting Mobile 3G Using WiFi
by
Aruna
Balasubramanian
Ratul
Mahajan
Arun
Venkataramani
University of Massachusetts
Microsoft Research
Presented
by
Ashok Kumar
J
CS 752/852 - Wireless and Mobile NetworkingSlide2
Demand for mobile access growing
www.totaltele.com
2
http://www.readwriteweb.com
900 million mobile broadband subscriptions today….
www.3gamericas.orgSlide3
Mobile demand is projected to far exceed capacity
“In light of the limited natural resource of spectrum, we have to look at the ways of conserving spectrum” -- Mark Siegel (AT&T)
3
Current spectrum
409.5 MHz
Unallocated spectrum (including whitespaces)
230 MHz
Projected demand by 2016
800 MHz – 1000 MHz
www.nytimes.com
www.nytimes.com
Reducing cellular spectrum utilization is key!
www.rysavy.comSlide4
Demand projected to outstrip capacity
4
http://www.nytimes.comSlide5
How can we reduce spectrum usage?
1. Behavioral
2. Economic
3. Technical
blogs.chron.com
5
www.usatoday.comSlide6
Augmenting Mobile 3G using WiFi
Offload data to WiFi when possible
Focus on vehicular mobility
6Slide7
Offloading 3G data to WiFi
7Slide8
8
This work:
How much 3G data can be offloaded to WiFi?
How to offload without hurting applications?
Related work on multiple interfaces
Improving performance using handoffs based on current conditions
Reducing power consumption by switching across multiple interfaces Slide9
9
Contributions
Measurement
: Joint study of 3G and WiFi connectivity
Across three cities: Amherst, Seattle, SFOSystem: Wiffler, to offload 3G data to WiFi while respecting application constraints Deployed on 20 vehiclesSlide10
10
Measurement setup
Testbed
: Vehicles with 3G and WiFi (802.11b) radios
Amherst: 20 buses + 1 car, Seattle: 1 car, SFO: 1 carSoftware: Simultaneously probes 3G and WiFi for Availability, loss rate, throughputDuration: 3000+ hours of data over 12+ daysSlide11
Open WiFi availability low, but useful
11
Availability
(%)
86%
11%
Availability = fraction of 1-second intervals when at least one packet received
7%
3G+WiFi combination better than sum pf partsSlide12
WiFi
loss rate is higher
12
Cumulative fraction
WiFi
3G
28%
8%
Loss rate = Fraction of packets lost at 10 probes/sec
Wi-Fi loses are
bursty
.Slide13
WiFi (802.11b) throughput is lower
13
Cumulative fraction
Cumulative fraction
WiFi
3G
WiFi
3G
Upstream
Downstream
0.35
0.72
Throughput = Total data received per secondSlide14
Interesting observations…
Availability of 3G in Peak hours is less compared to its availability in non-peak hours.
Availability of
Wi-Fi
in Peakhours is more comparedto its availability in off-Peakhours.Unavailability of 3G is 11% but when combined with Wi-Fi, total unavailability reduced to 5%.
14Slide15
Interesting observations…
In 47% of the Locations, Data sent over Wi-Fi is insignificant compared to 3G.
In remaining 53% of locations,
at least 20% of the 3G data
could be shifted to Wi-Fi.In 9% of the locations, equalor more data sent over Wi-Ficompared 3G. So in these location entire traffic could be offloaded to Wi-Fi.
15Slide16
16
Implications of measurement study
Strawman
augmentation: Use
Wi-Fi when availableCan offload only ~11% of the timeCan hurt applications performance because of Wi-Fi's higher loss rate and lower throughput
Example: Applications sensitive to losses like VoIP and Video Conferencing will face degraded application quality while transmitting over Wi-Fi but Application like Email, sending a file wouldn’t.Slide17
17
Key ideas in Wiffler
Leveraging Delay Tolerance:
Increase
savings for delay-tolerant applicationsProblem: Using
WiFi only when available saves little 3G usageSolution: Exploit delay-tolerance to wait to offload to
WiFi when availability predicted
Fast Switching to 3G:Reduce damage for delay-sensitive applications
Problem: Using
WiFi whenever available can hurt application qualitySolution: Fast switch to 3G when WiFi delays exceed thresholdSlide18
Prediction-based offloading
D = Delay-tolerance threshold (seconds)
S = Data remaining to be sent (bytes)
Each second,
If (WiFi available), send data on WiFi
Else if (W(D) < S), send data on 3GElse wait for Wi-Fi.
Choosing a delay threshold involves a trade off between better application performance and 3G load.
18
Predicted WiFi transfer size in next D seconds Slide19
19
Negligible benefits with more sophisticated prediction,
eg
future location prediction + AP location database
Predicting
WiFi capacity
History-based prediction of # of Aps encounter until a future time
using average inter-meeting time of the past encounters. (T/I encounter in next Tsecs where I is avg)Similarly average throughput is estimated based on the throughput observed by each vehicle at each AP encounter.
WiFi
capacity = (expected #APs) x (capacity per AP)Slide20
Error in predicting # of APs
20
Relative error
N=1
N=4
N=8Slide21
21
Predicting
WiFi
capacity
Accuracy is Low when predicting with only one previous encounter.Predicting error is close to 20% even for predicting Ap encounter untill small future time interval of 20 secs.
When prediction is based on the previous 4 or 8 AP encounters, the predictions error is less than 5% up to a future prediction time-interval of 50 seconds.The prediction error increases to 20% for prediction time interval of 100sec.Slide22
22
Fast switching to 3G
Problem:
WiFi
losses bursty => high retransmission delayApproach:If no WiFi link-layer ACK within 50ms, switch to 3GElse, continue sending on
WiFi
Wi-Fi NIC frequently takes a long time to complete retransmission attempts. Madwifi which used in test beds retries packets 11 times, which even if we ignore medium access delays takes more than 120 milliseconds with default 802.11b specification.
So fast switching mechanism send the packet on 3G if the Wi-Fi link-layer fails to deliver the packet within a delay threshold.Slide23
23
Adopting
Wiffler
Wiffler
needs to know the delay tolerance threshold and the QoS requirements of each application that uses the network.Wiffler requires proxy support, both to impliment fast switching and the prediction-based offloading. Proxy will
fecilitate packet reception from multiple IP address (ie from the 3G and the Wifi
interfaces) and allow switching between interfaces.Experiments are based open WiFi APs, Wiffler
can be deployed used with other APs as well.Slide24
Wiffler implementation
24
Destination server also acts as proxy to manage data coming from different IP address that the client acquires as it moves.
Prediction-based
offloading upstream +
downstream
Delay threshold to 50
ms.
Wiffler
proxySlide25
Wiffler implementation
25
Wiffler
proxy
Added a signal mechanism in the mobile node’s driver that signals the application when the wireless card receives a link layer acknowledgement.
Fast
switching only upstream
Fast switching in downstream direction is challenging because it needs either support from the APs or detailed information at the proxy on current Wi-Fi conditions(conveying the same is time consuming).Slide26
26
Evaluation Roadmap
Prediction-based offloading
Deployment on 20 DieselNet buses in 150 sq. mi region around Amherst
Trace-driven evaluation using throughput dataFast switchingDeployment on 1 car in Amherst town centerTrace-driven evaluation using measured loss/delay trace using VoIP-like probe trafficSlide27
Deployment results
Data offloaded to WiFi
Wiffler’s
prediction-based offloading
30%
WiFi when available
12%
27
% time good voice quality
Wiffler’s fast switching
68%
WiFi when available (no switching)
42%
File transfer size: 5MB; Delay tolerance: 60
secs
;
Data generation
gap: random with mean 100
secs
VoIP-like traffic: 20-byte packet every 20 ms Slide28
28
Trace-driven evaluation
Parameters varied
Workload, AP density, delay-tolerance, switching threshold
Strategies compared to prediction-based offloading:WiFi when availableAdapted-Breadcrumbs: Future location prediction + AP location databaseOracle (Impractical): Perfect prediction w/ future knowledgeSlide29
Wiffler increases data offloaded to WiFi
29
Workload: Web traces obtained from commuters
Wiffler increases delay by 10 seconds over Oracle.
42%
14%
Wiffler close to Oracle
Sophisticated prediction yields negligible benefit
WiFi when available yields little savingsSlide30
Completion Time
30
Even more savings in urban centersSlide31
Fast switching improves quality of delay-sensitive applications
31
40%
58%
73%
30% data offloaded to WiFi with 40ms switching thresholdSlide32
32
Future work
Reduce energy to search for usable WiFi
Improve performance/usage by predicting user accesses to prefetch over WiFi
Incorporate evolving metrics of cost for 3G and WiFi usageSlide33
33
Summary
Augmenting 3G with WiFi can reduce pressure on cellular spectrum
Measurement in 3 cities confirms WiFi availability and performance poorer, but potentially useful
Wiffler: Prediction-based offloading and fast switching to offload without hurting applicationsSlide34
Questions?