What Goes Around Comes Around
Mobile Bandwidth Sharing and
Aggregation
Karim Habak☨, Khaled A. Harras☥, and Moustafa Youssef⚕
☨Georgia Institute of Technology
☥Carnegie Mellon University in Qatar
⚕Egypt-Japan University of Sci. and Tech. (EJUST)
IEEE MASS 2015
Motivation
Motivation
◆
Mobile data demands
Motivation
◆
Mobile data demands
Motivation
◆
Mobile data demands
◆
Data roaming charges
Motivation
◆
Mobile data demands
◆
Data roaming charges
◆
Multi-homed or multi-interface
enabled devices
SocketAPI
Motivation
◆
Mobile data demands
◆
Data roaming charges
◆
Multi-homed or multi-interface
enabled devices
◆
Current OSs use only one interface
even if more than one is connected to
the Internet
SocketAPI
Motivation
◆
Mobile data demands
◆
Data roaming charges
◆
Multi-homed or multi-interface
enabled devices
◆
Current OSs use only one interface
even if more than one is connected to
the Internet
◆
Users density
SocketAPI
Motivation
◆
Mobile data demands
◆
Data roaming charges
◆
Multi-homed or multi-interface
Bandwidth
Aggregation
?
enabled devices
◆
User Collaboration ?
Current OSs use only one interface
even if more than one is connected to
SocketAPI
the Internet
◆
Users density
Motivation
◆
Current approaches overlooks
Motivation
◆
Current approaches overlooks
➢
Ease of deployment (updating applications, servers,
infrastructure and clients operating system)
Motivation
◆
Current approaches overlooks
➢
Ease of deployment (updating applications, servers,
infrastructure and clients operating system)
➢
Energy efficiency
Motivation
◆
Current approaches overlooks
➢
Ease of deployment (updating applications, servers,
infrastructure and clients operating system)
➢
Energy efficiency
➢
Cost efficiency
Motivation
◆
Current approaches overlooks
➢
Ease of deployment (updating applications, servers,
infrastructure and clients operating system)
➢
Energy efficiency
➢
Cost efficiency
➢
User incentives
Motivation
◆
Current approaches overlooks
➢
Ease of deployment (updating applications, servers,
infrastructure and clients operating system)
➢
Energy efficiency
➢
Cost efficiency
➢
User incentives
What about FON ?
Agenda
✓
◆
Motivation
Scenario and Solution Overview
◆
OSCAR Architecture
◆
OSCAR Scheduler
◆
OSCAR Communication Protocol
◆
Evaluation
◆
Conclusion and Future Work
Scenario and Solution Overview
Virtual Bank
Alice
Virtual
Balance
John
Alice
Mark
Connection-Oriented
OSCAR
WiFi
Bluetooth
Bluetooth
The Internet
3G
Packet-Oriented OSCAR
Resume
Supporting
Legacy
Server
John
WiFi
Mark
WiFi
Legacy Server
3G
OSCAR-Enabled Server
Connection #1 Packets
Connection #2 Packets
Connection #3 Packets
John’s Incentives Packets
Mark’s Incentives Packets
Alice’s Incentives Packets
Scenario and Solution Overview
Virtual Bank
Alice
Virtual
Balance
Connection-Oriented
OSCAR
WiFi
Bluetooth
The Internet
3G
Legacy Server
Packet-Oriented OSCAR
Resume
Supporting
Legacy
Server
John
Mark
WiFi
John
Alice
Mark
3G
OSCAR-Enabled Server
Connection #1 Packets
Connection #2 Packets
Connection #3 Packets
John’s Incentives Packets
Mark’s Incentives Packets
Alice’s Incentives Packets
Scenario and Solution Overview
Virtual Bank
Alice
Virtual
Balance
Connection-Oriented
OSCAR
WiFi
Bluetooth
The Internet
3G
Legacy Server
Packet-Oriented OSCAR
Resume
Supporting
Legacy
Server
John
Mark
WiFi
John
Alice
Mark
3G
OSCAR-Enabled Server
Connection #1 Packets
Connection #2 Packets
Connection #3 Packets
John’s Incentives Packets
Mark’s Incentives Packets
Alice’s Incentives Packets
Scenario and Solution Overview
Virtual Bank
Alice
Virtual
Balance
Connection-Oriented
OSCAR
WiFi
Bluetooth
The Internet
3G
Legacy Server
Packet-Oriented OSCAR
Resume
Supporting
Legacy
Server
John
Mark
WiFi
John
Alice
Mark
3G
OSCAR-Enabled Server
Connection #1 Packets
Connection #2 Packets
Connection #3 Packets
John’s Incentives Packets
Mark’s Incentives Packets
Alice’s Incentives Packets
Scenario and Solution Overview
Virtual Bank
Alice
Virtual
Balance
Connection-Oriented
OSCAR
WiFi
Bluetooth
The Internet
3G
Legacy Server
Packet-Oriented OSCAR
Resume
Supporting
Legacy
Server
John
Mark
WiFi
John
Alice
Mark
3G
OSCAR-Enabled Server
Connection #1 Packets
Connection #2 Packets
Connection #3 Packets
John’s Incentives Packets
Mark’s Incentives Packets
Alice’s Incentives Packets
Scenario and Solution Overview
Virtual Bank
Alice
Virtual
Balance
Connection-Oriented
OSCAR
WiFi
Bluetooth
The Internet
3G
Legacy Server
Packet-Oriented OSCAR
Resume
Supporting
Legacy
Server
John
Mark
WiFi
John
Alice
Mark
3G
OSCAR-Enabled Server
Connection #1 Packets
Connection #2 Packets
Connection #3 Packets
John’s Incentives Packets
Mark’s Incentives Packets
Alice’s Incentives Packets
Agenda
✓
Motivation
✓
Scenario and Solution
◆
OSCAR Architecture
◆
OSCAR Scheduler
◆
OSCAR Communication Protocol
◆
Evaluation
◆
Conclusion and Future Work
OSCAR Architecture
OSCAR Architecture
◆
Context awareness manager
➢
User interface module
➢
Application traffic char. estimator
➢
Neighbor discovery module
➢
Network interfaces char. estimator
➢
Battery sensor
OSCAR Architecture
◆
Incentive Manager
➢
Tendering price determiner
➢
Tenders collection and filtering
module
➢
Contracts assessment module
➢
Balance handler
➢
Reservation manager
OSCAR Architecture
◆
Packet-oriented scheduling
manager
➢
Mode detection module
➢
Resume module
OSCAR Architecture
◆
Backward compatibility manager
➢
Packet reordering module
➢
Network address translation
module
➢
Connection redirection module
OSCAR Architecture
◆
Scheduler
➢
Schedules the packets and/or the
connections on the different
network interfaces/neighbors
Agenda
✓
Motivation
✓
Scenario and Solution
✓
OSCAR Architecture
◆
OSCAR Scheduler
◆
OSCAR Communication Protocol
◆
Evaluation
◆
Conclusion and Future Work
System Model
◆
A mobile device has m different paths to connect to the internet
◆
Each paths has its own characteristics in terms of cost, energy
consumption and available bandwidth
◆
The device running a set of applications sharing these paths
◆
OSCAR’s goal is to distribute the connections and/or the packets on
the available paths such that it maximizes the overall system
throughput while maintaining the cost and energy consumption below
user defined thresholds
Objective Function
◆
Maximize the overall system throughput by minimizing the time
needed for each path to finish its connection oriented and packet
oriented loads
Objective Function
◆
Maximize the overall system throughput by minimizing the time
needed for each path to finish its connection oriented and packet
oriented loads
Packet oriented load
Objective Function
◆
Maximize the overall system throughput by minimizing the time
needed for each path to finish its connection oriented and packet
oriented loads
Packet oriented load
Connection oriented load
Objective Function
◆
Maximize the overall system throughput by minimizing the time
needed for each path to finish its connection oriented and packet
oriented loads
Packet oriented load
Available bandwidth
Connection oriented load
Objective Function
◆
Maximize the overall system throughput by minimizing the time
needed for each path to finish its connection oriented and packet
oriented loads
Packet oriented load
Path index
Available bandwidth
Connection oriented load
Constraints
◆
The average cost per unit data should not exceed certain threshold
◆
The average cost per unit data does not exceed certain threshold
◆
If the new stream is in connection oriented mode, it should be
assigned to only one path
◆
For packet oriented streams, their total load should be distributed
over all the available paths
Agenda
✓
Motivation
✓
Scenario and Solution
✓
OSCAR Architecture
✓
OSCAR Scheduler
◆
OSCAR Communication Protocol
◆
Evaluation
◆
Conclusion and Future Work
OSCAR Communication Protocol
While Requesting Bandwidth
While Offering Bandwidth
Start
R
Te ecv
nd
ers
Snd
q.
GRe
Snd
Tend
ers
Wait for
Tenders
v
Rec .
c
SRe
sac
Tra
n
.
Snd
SRe
c.
Wait for
Bank
Confirm.
Wait for
Res.
or R
NAC
K
Recv
RRe
q.
firm
on
cv
RAC
K
nC
Re
Asked for
Tenders
ec.
dR
Sn
tio
sac
Payment
Approval
n
Tra
nC
on
firm
.
Snd
cv
Payment
Rec
GR v
eq.
Re
Wait for
Confirm.
v
Rec .
s
ARe
Auth.
Ended
Snd
s.
DRe
Collaborative
Mode
CK
A
N
or R
K
C
RA
Recv
c.
e
vR
c
Re
Snd
AReq.
Wait for
Res.
Normal
Operations
tio
t; .
u
o
GT Req
R
Snd
Rec
v
ARe
s.
Known Snder
F
nI
Auth.
Started
Wait for
Res.
DR
na
nts
Snd
ARe
q.
Auth.
Started
Non-collaborative
Mode
l-K DT
no ou
wn t w
Re ith
DTout with
sp
on
Unknown Respondents
de
eo
im
.T
ov
Tendering
Normal
Operations
eq
.
Al
Unk
no
Snd wn
er
Discov.
Requsted
Re
cv
Wait for
Res.
Discov.
Started
User Needs
Snd
q.
DRe
sc
Di
Discovery and Authentication
Recv DRes.
Payment
Forwading
ard
Forw c.
SRe
Wait for
Bank
Confirm.
OSCAR Communication Protocol
While Requesting Bandwidth
While Offering Bandwidth
Start
R
Te ecv
nd
ers
Snd
q.
GRe
Snd
Tend
ers
Wait for
Tenders
v
Rec .
c
SRe
sac
Tra
n
.
Snd
SRe
c.
Wait for
Bank
Confirm.
Wait for
Res.
or R
NAC
K
Recv
RRe
q.
firm
on
cv
RAC
K
nC
Re
Asked for
Tenders
ec.
dR
Sn
tio
sac
Payment
Approval
n
Tra
nC
on
firm
.
Snd
cv
Payment
Rec
GR v
eq.
Re
Wait for
Confirm.
v
Rec .
s
ARe
Auth.
Ended
Snd
s.
DRe
Collaborative
Mode
CK
A
N
or R
K
C
RA
Recv
c.
e
vR
c
Re
Snd
AReq.
Wait for
Res.
Normal
Operations
tio
t; .
u
o
GT Req
R
Snd
Rec
v
ARe
s.
Known Snder
F
nI
Auth.
Started
Wait for
Res.
DR
na
nts
Snd
ARe
q.
Auth.
Started
Non-collaborative
Mode
l-K DT
no ou
wn t w
Re ith
DTout with
sp
on
Unknown Respondents
de
eo
im
.T
ov
Tendering
Normal
Operations
eq
.
Al
Unk
no
Snd wn
er
Discov.
Requsted
Re
cv
Wait for
Res.
Discov.
Started
User Needs
Snd
q.
DRe
sc
Di
Discovery and Authentication
Recv DRes.
Payment
Forwading
ard
Forw c.
SRe
Wait for
Bank
Confirm.
OSCAR Communication Protocol
While Requesting Bandwidth
While Offering Bandwidth
Start
R
Te ecv
nd
ers
Snd
q.
GRe
Snd
Tend
ers
Wait for
Tenders
v
Rec .
c
SRe
sac
Tra
n
.
Snd
SRe
c.
Wait for
Bank
Confirm.
Wait for
Res.
or R
NAC
K
Recv
RRe
q.
firm
on
cv
RAC
K
nC
Re
Asked for
Tenders
ec.
dR
Sn
tio
sac
Payment
Approval
n
Tra
nC
on
firm
.
Snd
cv
Payment
Rec
GR v
eq.
Re
Wait for
Confirm.
v
Rec .
s
ARe
Auth.
Ended
Snd
s.
DRe
Collaborative
Mode
CK
A
N
or R
K
C
RA
Recv
c.
e
vR
c
Re
Snd
AReq.
Wait for
Res.
Normal
Operations
tio
t; .
u
o
GT Req
R
Snd
Rec
v
ARe
s.
Known Snder
F
nI
Auth.
Started
Wait for
Res.
DR
na
nts
Snd
ARe
q.
Auth.
Started
Non-collaborative
Mode
l-K DT
no ou
wn t w
Re ith
DTout with
sp
on
Unknown Respondents
de
eo
im
.T
ov
Tendering
Normal
Operations
eq
.
Al
Unk
no
Snd wn
er
Discov.
Requsted
Re
cv
Wait for
Res.
Discov.
Started
User Needs
Snd
q.
DRe
sc
Di
Discovery and Authentication
Recv DRes.
Payment
Forwading
ard
Forw c.
SRe
Wait for
Bank
Confirm.
OSCAR Communication Protocol
While Requesting Bandwidth
While Offering Bandwidth
Start
R
Te ecv
nd
ers
Snd
q.
GRe
Snd
Tend
ers
Wait for
Tenders
v
Rec .
c
SRe
sac
Tra
n
.
Snd
SRe
c.
Wait for
Bank
Confirm.
Wait for
Res.
or R
NAC
K
Recv
RRe
q.
firm
on
cv
RAC
K
nC
Re
Asked for
Tenders
ec.
dR
Sn
tio
sac
Payment
Approval
n
Tra
nC
on
firm
.
Snd
cv
Payment
Rec
GR v
eq.
Re
Wait for
Confirm.
v
Rec .
s
ARe
Auth.
Ended
Snd
s.
DRe
Collaborative
Mode
CK
A
N
or R
K
C
RA
Recv
c.
e
vR
c
Re
Snd
AReq.
Wait for
Res.
Normal
Operations
tio
t; .
u
o
GT Req
R
Snd
Rec
v
ARe
s.
Known Snder
F
nI
Auth.
Started
Wait for
Res.
DR
na
nts
Snd
ARe
q.
Auth.
Started
Non-collaborative
Mode
l-K DT
no ou
wn t w
Re ith
DTout with
sp
on
Unknown Respondents
de
eo
im
.T
ov
Tendering
Normal
Operations
eq
.
Al
Unk
no
Snd wn
er
Discov.
Requsted
Re
cv
Wait for
Res.
Discov.
Started
User Needs
Snd
q.
DRe
sc
Di
Discovery and Authentication
Recv DRes.
Payment
Forwading
ard
Forw c.
SRe
Wait for
Bank
Confirm.
Agenda
✓
Motivation
✓
Scenario and Solution
✓
OSCAR Architecture
✓
OSCAR Scheduler
✓
OSCAR Communication Protocol
◆
◆
Evaluation
Conclusion and Future Work
Implementation
◆
◆
OSCAR Network Layer Middleware
➢
Implemented using Click Modular Router Framework
➢
Responsible for the core OSCAR functionalities (i.e. Scheduling, parameter estimation, … etc)
Application Layer Resume Service
➢
◆
Reflects the resume module that enables packet-oriented scheduling while communicating with
resume enabled servers
Monitoring Application
➢
Represent the user interface module which captures the user requirements and interface usage
policies
Environment
Environment
Parameters and Metrics
◆
Parameters
➢
Application characteristics (small load 22.38KB and large load 285KB)
➢
Connective heterogeneity (13 small connection/sec and 1 large connection/sec)
➢
The ratio of OSCAR enabled servers (gamma)
➢
The ratio of resume enabled servers (alpha)
➢
Network interface characteristic
➢
Cost and energy constraints
Parameters and Metrics
◆
Metrics
➢
Throughput
➢
Average energy consumption per unit data
➢
Average cost per unit data
Results
With as few as 30% of the servers become OSCAR enabled, OSCAR reaches the highest
performance. The increase of the availability of resume supporting servers minimize the need for
updating the servers
Results
Incremental Deployability
With as few as 30% of the servers become OSCAR enabled, OSCAR reaches the highest
performance. The increase of the availability of resume supporting servers minimize the need for
updating the servers
Agenda
✓
Motivation
✓
Scenario and Solution
✓
OSCAR Architecture
✓
OSCAR Scheduler
✓
OSCAR Communication Protocol
✓
Evaluation
◆
Conclusion and Future Work
Conclusion and Future Work
◆
OSCAR is deployable, energy and cost efficient, as well as being equipped with
efficient incentive system
◆
OSCAR achieves high performance gains
➢
150% enhancement in throughput, in the throughput maximization mode, with
neither changes to the servers nor resume-support
➢
Reaches the optimal performance when we have 30% of the servers are OSCARenabled or 35 of the servers support resume functionality (Typical for our current
Internet)
Thank You!