Towards Automatic Phone-to-Phone Communication for Vehicular - - PowerPoint PPT Presentation

Towards Automatic Phone-to-Phone Communication for Vehicular Networking Applications

Shaohan Hu, Hengchang Liu, Lu Su, Hongyan Wang,Tarek Abdelzaher, Pan Hui, Wei Zheng, Zhiheng Xie, John Stankovic

Motivation

Motivation

richer traffic info higher road awareness … and more!

Gas Coupon!

infotainment

• pportunities

Goal

WiFi AP WiFi AP

Internet

Build a Phone-to-Phone communication system for the tens of millions of vehicles on the roads today

Goal

WiFi AP WiFi AP

Internet

Key requirements No change to the existing infrastructure / protocols Transparent to the end-users (e.g., no rooting / jailbreaking) Build a Phone-to-Phone communication system for the tens of millions of vehicles on the roads today

System Model

System Model

Vehicle-resident phones toggle between hotspot and client modes

Hotspot Mode Client Mode Infrastructure (WiFi AP)

System Model

Vehicle-resident phones toggle between hotspot and client modes Only considering pairwise communication: T-Drive dataset => ~80% encounters are pairwise (T-Drive: ~10k taxicabs’ 1-week traces in Beijing, collected by MSRA)

Hotspot Mode Client Mode Infrastructure (WiFi AP)

Problem Statement

How to design the toggling scheme for

• ptimal System Efficiency?

Problem Statement

How to design the toggling scheme for

• ptimal System Efficiency?

Tdata transfer can take place Tphones in range with each other (or AP)

Problem Statement

When to toggle modes?

How often do Phone-Phone (or Phone-AP) meet? For how long do Phone-Phone (or Phone-AP) meet?

How to design the toggling scheme for

• ptimal System Efficiency?

Tdata transfer can take place Tphones in range with each other (or AP)

Analytical Formulation

Analytical Formulation

hr∗, s∗i = arg max

r,s EM1,M2 [E(β)T1 + E(γ)T2]

Analytical Formulation

: Phone-Phone (or Phone-AP) meeting duration : Phone-Phone (or Phone-AP) expected transmission duration : Phone-Phone (or Phone-AP) meeting rate

hr∗, s∗i = arg max

r,s EM1,M2 [E(β)T1 + E(γ)T2]

M1 (or M2) T1 (or T2) β (or γ)

Solution Sketch

(meeting times and rates): estimated from empirical data (expected transmission times): derived analytically (optimal mode-toggling policy): solved using off-the-shelf non-linear

• ptimization solver

M1, M2, β, γ T1, T2 hr∗, s∗i

?

Expected Transmission Time

Phone-to-Phone

Expected Transmission Time

Phone-to-Phone

f(t) =        0, 0 ≤ t ≤ t0 1, t0 < t ≤ t0 + r 0, t0 + r < t ≤ 2t0 + r −1, 2t0 + r < t ≤ 2t0 + r + s

Define a periodic function

f = 2t0 + r + s

with period .

=> during mode switching => during mode switching => in hotspot mode => in client mode

Expected Transmission Time

Phone-to-Phone

f(t) =        0, 0 ≤ t ≤ t0 1, t0 < t ≤ t0 + r 0, t0 + r < t ≤ 2t0 + r −1, 2t0 + r < t ≤ 2t0 + r + s

Define a periodic function

f = 2t0 + r + s

with period .

=> during mode switching => during mode switching => in hotspot mode => in client mode

t∗ = min

t {t : f1(t)f2(t) < 0}

Then, the time since meeting when two phones establish connection is

Expected Transmission Time

Phone-to-Phone

f(t) =        0, 0 ≤ t ≤ t0 1, t0 < t ≤ t0 + r 0, t0 + r < t ≤ 2t0 + r −1, 2t0 + r < t ≤ 2t0 + r + s

Define a periodic function

f = 2t0 + r + s

with period .

=> during mode switching => during mode switching => in hotspot mode => in client mode

t∗ = min

t {t : f1(t)f2(t) < 0}

Then, the time since meeting when two phones establish connection is

T1 = Et1,t2[M1 − t∗] = 1 f 2 Z

t1

Z

t2

(M1 − t∗)dt2dt1

Therefore, the expected phone-to-phone transmission time is

Expected Transmission Time

Phone-to-Phone

t1 t2 t∗ M1 E(M1 − t∗) [0, t0) [0, t0) ∞ ∼ [0, t0) [t0, t0 + r) M1 ≥ t0 + r

1 2f2

⇥ (M1 − t0)2 − 1

3 (M1 − r)3 + 1 3(M1 − t0 − r)3⇤

• r

2t0 + r − t2 r ≤ M1 < t0 + r

1 2f2

⇥ (M1 − t0)2t0 − 1

3(M1 − r)3⇤

[t0, t0 + r) [0, t0) t0 ≤ M1 < r

t0 2f2 (M1 − t0)2

[0, t0) [t0 + r, 2t0 + r) max(t0 − t1, 2t0 + r − t2) M1 ≥ t0

2 f2

⇣

M1 2 t2 0 − 1 3 t3

⌘ M1 < t0

1 3f2 M3 1

[0, t0) [2t0 + r, f) t0 − t1 M1 ≥ t0

1 f2

⇥ 1

3 t3 0 − 1 2(M1 + s)t2 0 + M1st0

⇤ M1 < t0

1 f2

1

2 sM2 1 − 1 6 M3 1

• [t0, t0 + r)

[t0, t0 + r) 2t0 + r − max(t1, t2) M1 ≥ r

2 f2

h

r−t0 2

(M1 − t0)2 − 1

6(M1 − t0)3 + 1 6 (M1 − r)3i

t0 ≤ M1 < r

1 f2

⇥ (r − t0)(M1 − t0)2 − 1

3(M1 − t0)3⇤

[t0, t0 + r) [t0 + r, 2t0 + r) 2t0 + r − t2 M1 ≥ t0

1 f2

h

r 2 M2 1 − r−t0 2

(M1 − t0)2 − 1

6 M3 1 + 1 6 (M1 − t0)3i

M1 < t0

1 f2

r

2 M2 1 − 1 6 M3 1

• [t0, t0 + r)

[2t0 + r, f) ∼

M1rs f2

Case analysis for expected transmission time

Expected Transmission Time

Phone-to-Phone

T1 = 2rs f 2 M1 + I(M1<t0)f1(r, s, M1) + I(M1≥t0)f2(r, s, M1) + I(t0≤M1<r+t0)f3(r, s, M1) +I(M1≥r+t0)f4(r, s, M1) + I(t0≤M1<s+t0)f5(r, s, M1) + I(M1≥s+t0)f6(r, s, M1),

f1(r, s, M1) = s + r f 2 M 2

1

f2(r, s, M1) = 1 f 2 2 3M 3

1 − 2

3(M1 − t0)3 − 2t0(M1 − t0)2 + 2M1t0(r + s) + 4 3t3

0 − (2M1 + r + s)t2

• f3(r, s, M1)

= 1 f 2  r(M1 − t0)2 − 1 3(M1 − t0)3

• f4(r, s, M1)

= 1 f 2  r(M1 − t0)2 + 1 3(M1 − t0 − r)3 − 1 3(M1 − t0)3

• f5(r, s, M1)

= 1 f 2  s(M1 − t0)2 − 1 3(M1 − t0)3

• f6(r, s, M1)

= 1 f 2  s(M1 − t0)2 + 1 3(M1 − t0 − s)3 − 1 3(M1 − t0)3

• .

where the I’s are indicator functions, and f ’s are Collecting the cases:

Expected Transmission Time

Phone-to-AP

Taking a similar approach (see AP’s as nodes stuck in hotspot mode)

T2 = M2r f + I(M2≥0) 1 2f ⇥ M 2

2 − (M2 − t0)2⇤

+ I(t0≤M2<f−r) 1 2f (M2 − t0)2 +I(M−2≥f−r) 1 2f ⇥ (M2 − t0)2 − (M2 − f + r)2⇤ + I(M2<t0) M 2

2

2f

Expected Transmission Time

Phone-to-AP

Taking a similar approach (see AP’s as nodes stuck in hotspot mode)

T2 = M2r f + I(M2≥0) 1 2f ⇥ M 2

2 − (M2 − t0)2⇤

+ I(t0≤M2<f−r) 1 2f (M2 − t0)2 +I(M−2≥f−r) 1 2f ⇥ (M2 − t0)2 − (M2 − f + r)2⇤ + I(M2<t0) M 2

2

2f 2, β, γ

T1, T2 hr∗, s∗i Finally, given , schedule is solved for using off-the-shelf solver. the optimal mode toggling

Implementation

On Android Galaxy Nexus and Nexus S phones Using Java Reflection, no rooting is required Driving data: GPS trajectories & car OBD-II readings Measured mode switching

• verhead and communication

range, and tested functional system in practice

Large-Scale Simulation

Large-Scale Simulation

MSRA T-Drive taxicab dataset Central Beijing (50 km x 50 km) Feb 2~8, 2008 9211 taxicabs Assumed 10% WiFi coverage

Large-Scale Simulation

MSRA T-Drive taxicab dataset Central Beijing (50 km x 50 km) Feb 2~8, 2008 9211 taxicabs Assumed 10% WiFi coverage Scenario G.N (Galaxy Nexus) and N.S (Nexus S) phones Cars collect driving data, share with each other Cars offload data to backend server when encountering APs

Large-Scale Simulation

MSRA T-Drive taxicab dataset Central Beijing (50 km x 50 km) Feb 2~8, 2008 9211 taxicabs Assumed 10% WiFi coverage Scenario G.N (Galaxy Nexus) and N.S (Nexus S) phones Cars collect driving data, share with each other Cars offload data to backend server when encountering APs Schemes Baseline: no phone-to-phone communication Adaptive: system parameters are updated every hour using historical data Static: system parameters are computed using the first hour of data only

How does the mode switching overhead affect optimal system efficiency?

Simulation Results

Simulation Results

How does time-of-day affect the optimal system efficiency?

Improvement on transmission delay (mean and median) w/ phone-to-phone communication enabled v.s. w/o

Simulation Results

Conclusion

Our system enables vehicle-vehicle communications using off-the-shelf smartphones No change to existing infrastructure Transparent to end users Analytical formulation and results for optimal system efficiency Experiments show Over 80% system efficiency Significantly reduces data transfer delay time

Thanks