Augmenting Mobile 3G Using WiFi Aruna Balasubramanian Ratul Mahajan Arun Venkataramani

advertisement

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 Networking

Demand for mobile access growing

www.totaltele.com

http://www.readwriteweb.com

900 million mobile broadband subscriptions today….

www.3gamericas.org

2

Mobile demand is projected to far exceed capacity www.nytimes.com

Current spectrum www.rysavy.com

409.5 MHz

230 MHz Unallocated spectrum

(including whitespaces)

Projected demand by

2016

800 MHz –

1000 MHz www.nytimes.com

“In light of the limited natural resource of spectrum, we have to look at the ways of conserving spectrum” -- Mark Siegel (AT&T)

Reducing cellular spectrum utilization is key!

3

Demand projected to outstrip capacity http://www.nytimes.com

4

How can we reduce spectrum usage?

blogs.chron.com

1. Behavioral www.usatoday.com

2. Economic

3. Technical

5

Augmenting Mobile 3G using WiFi

Offload data to WiFi when possible

Focus on vehicular mobility

6

Offloading 3G data to WiFi

7

Related work on multiple interfaces

 Improving performance using handoffs based on current conditions

 Reducing power consumption by switching across multiple interfaces

This work:

1.How much 3G data can be offloaded to WiFi?

2.How to offload without hurting applications?

8

Contributions

 Measurement: Joint study of 3G and WiFi connectivity

Across three cities: Amherst, Seattle, SFO

 System: Wiffler, to offload 3G data to WiFi while respecting application constraints

Deployed on 20 vehicles

9

Measurement setup

 Testbed: Vehicles with 3G and WiFi (802.11b) radios

Amherst: 20 buses + 1 car, Seattle: 1 car, SFO: 1 car

 Software: Simultaneously probes 3G and WiFi for

Availability, loss rate, throughput

 Duration: 3000+ hours of data over 12+ days

10

Open WiFi availability low, but useful

Availability = fraction of 1-second intervals when at least one packet received

86%

Availability

(%)

3G+WiFi combination better than sum pf parts

11%

7%

11

WiFi loss rate is higher

Loss rate = Fraction of packets lost at 10 probes/sec

Cumulative fraction

28%

8% 3G

WiFi

Wi-Fi loses are bursty.

12

WiFi (802.11b) throughput is lower

Throughput = Total data received per second

Cumulative fraction

3G

0.35 0.72

WiFi

Upstream

Cumulative fraction

3G

WiFi

Downstream

13

Interesting observations…

 Availability of 3G in Peak hours is less compared to its availability in non-peak hours.

 Availability of Wi-Fi in Peak hours is more compared to its availability in off-Peak hours.

 Unavailability of 3G is 11% but when combined with Wi-Fi, total unavailability reduced to 5%.

14

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, equal or more data sent over Wi-Fi compared 3G. So in these location entire traffic could be offloaded to Wi-Fi.

15

Implications of measurement study

 Strawman augmentation: Use Wi-Fi when available

Can offload only ~11% of the time

Can 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.

16

Key ideas in Wiffler

Leveraging Delay Tolerance:

Increase savings for delaytolerant applications

 Problem: Using WiFi only when available saves little 3G usage

 Solution: Exploit delaytolerance to wait to offload to WiFi when availability predicted

Fast Switching to 3G:

Reduce damage for delaysensitive applications

 Problem: Using WiFi whenever available can hurt application quality

 Solution: Fast switch to

3G when WiFi delays exceed threshold

17

Prediction-based offloading

D = Delay-tolerance threshold (seconds)

S = Data remaining to be sent (bytes)

Each second,

1.

If (WiFi available), send data on WiFi

2.

Else if (W(D) < S), send data on 3G

3.

Else wait for Wi-Fi.

Predicted WiFi transfer size in next D seconds

Choosing a delay threshold involves a trade off between better application performance and 3G load.

18

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 T secs 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)

Negligible benefits with more sophisticated prediction, eg future location prediction + AP location database

19

Error in predicting # of APs

Relative error

N=1

N=4

N=8

20

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.

21

Fast switching to 3G

 Problem:

WiFi losses bursty => high retransmission delay

 Approach:

If no WiFi link-layer ACK within 50ms, switch to 3G

Else, 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.

22

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 predictionbased 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.

23

Wiffler implementation

Wiffler proxy

 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.

24

Wiffler implementation

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).

25

Evaluation Roadmap

 Prediction-based offloading

Deployment on 20 DieselNet buses in 150 sq. mi region around Amherst

Trace-driven evaluation using throughput data

 Fast switching

Deployment on 1 car in Amherst town center

Trace-driven evaluation using measured loss/delay trace using VoIP-like probe traffic

26

Deployment results

Wiffler’s prediction-based offloading

Data offloaded to WiFi

30%

WiFi when available 12%

File transfer size: 5MB; Delay tolerance: 60 secs;

Data generation gap: random with mean 100 secs

Wiffler’s fast switching

WiFi when available (no switching)

% time good voice quality

68%

42%

VoIP-like traffic: 20-byte packet every 20 ms

27

Trace-driven evaluation

 Parameters varied

Workload, AP density, delay-tolerance, switching threshold

 Strategies compared to prediction-based offloading:

WiFi when available

Adapted-Breadcrumbs: Future location prediction + AP location database

Oracle (Impractical): Perfect prediction w/ future knowledge

28

Wiffler increases data offloaded to WiFi

Workload: Web traces obtained from commuters

42%

14%

Wiffler close to

Oracle

Sophisticated prediction yields negligible benefit available yields little savings

Wiffler increases delay by 10 seconds over Oracle.

29

Completion Time

Even more savings in urban centers

30

Fast switching improves quality of delay-sensitive applications

73%

58%

40%

30% data offloaded to WiFi with 40ms switching threshold

31

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 usage

32

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 applications

33

Questions?

Download