BlueStreaming:
Towards Power-Efficient Internet P2P
Streaming to Mobile Devices
Yao Liu @ George Mason University
Fei Li @ George Mason University
Lei Guo @ Microsoft
Yang Guo @ Bell Labs
Songqing Chen @ George Mason University
Internet streaming
• Internet video streaming is gaining increased
popularity in practice
– 90% of Internet traffic will be video by 2014
• Internet peer-to-peer (P2P) streaming is also
popular
– P2P TV has generated 6% of total Internet traffic
today
Internet streaming to mobile devices
• Mobile devices are pervasively used today to
access streaming services
More than 66% of
mobile network traffic
will be video by 2015
Streaming to mobile devices is challenging
• Heterogeneity among devices
– Software: different mobile operating systems, supported
audio/video codecs…
– Hardware: different screen sizes…
– Connection: 3G, WiFi, WiMAX, …
• Less reliable wireless connections
toCPUs
save the power consumed by Wireless
• How
Slower
Network Interface?
• …
• Limited battery power supply
• Major power drainage sources:
– CPU
– Display
– Wireless network interface card (WNIC)
30% ~ 40%
Power saving for P2P streaming to mobile
devices is even more challenging
• In addition to downloading, a peer is expected to
upload an equivalent amount to other peers in
order to get service
– Tit-for-tat
• In order to upload and download, a peer has to
frequently exchange control packets with
neighbors
– Buffermaps
– Fine-grained data requests
• Streaming data is downloaded from multiple and
dynamically changing neighbors
Our contribution
• Through Internet measurements, we confirm the
uploading traffic, control traffic significantly
prevent the WiFi interface from switching to
sleep mode
• We propose to leverage Bluetooth to transmit
highly frequent and low throughput control
traffic in P2P streaming for mobile devices
• We design and implement BlueStreaming, which
trades Bluetooth’s power consumption for
greater power saving from WiFi via intelligent
traffic shaping
Outline
•
•
•
•
•
Introduction
Internet Measurement
Design of BlueStreaming
Evaluation
Conclusion
P2P streaming consumes more energy than
C/S based streaming on iTouch
• Experiments on iPod Touch
– Use Pwr Mgt flag to determine the sleep time
Architecture
TVUPlayer
P2P
Encoding
Rate (Kbps)
281
Justin.tv
C/S
281
iPod Touch
Sleep Time
(%)
26
83
P2P streaming consumes more energy than
C/S based streaming on laptop
• Experiments on Laptop running Windows 7:
– With maximum WiFi Power Saving Enabled
Architecture
Encoding
Rate (Kbps)
PPTV
P2P
400
4.42
12
PPS
SopCast
QQLive
P2P
P2P
P2P
396
530
500
0.09
0.99
7.12
20
3
4
Justin.tv
C/S
433
21.44
n/a
Laptop
Windows 7
Sleep Time
(%)
Avg. # of
Neighbors
60-75% total transmitted packets are
Smaller than
control
packets
streaming data
1
0.8
packets
0.6
0.4
0.2
0
Cumulative Fraction
Cumulative Fraction
1
100 300 500 700 900 1100 1300 1500
IP Packet Size (bytes)
0.8
0.6
0.4
0.2
0
IP Packet Size (bytes)
PPS (396 Kbps)
PPTV (400 Kbps)
1
Cumulative Fraction
Cumulative Fraction
1
0.8
0.6
0.4
0.2
0
100
Up to 2 times more than
streaming data traffic
300 500 700 900 1100 1300 1500
100 300 500 700 900 1100 1300 1500
IP Packet Size (bytes)
SopCast (530 Kbps)
Significantly reduces
inter-packet delay
0.8
0.6
Results in less sleep time,
and more power
consumption
0.4
0.2
0
100 300 500 700 900 1100 1300 1500
IP Packet Size (bytes)
QQLive (500 Kbps)
180
150
120
90
60
30
0
0
10
20
Time (minute)
30
Control Traffic Throughput (Kbps)
Control Traffic Throughput (Kbps)
Control traffic throughput is low
180
150
90
60
30
0
0
150
120
90
60
30
SopCast (530 Kbps)
30
Control Traffic Throughput (Kbps)
Control Traffic Throughput (Kbps)
180
10
20
Time (minute)
10
20
Time (minute)
30
PPS (396 Kbps)
PPTV (400 Kbps)
0
0
Throughput is generally
less than 100 Kbps
120
180
150
120
90
60
30
0
0
10
20
Time (minute)
QQLive (500 Kbps)
30
Smaller compared to the
streaming rate of
400 - 530 Kbps
Uploading traffic varies
1600
Upload Throughput (Kbps)
Upload Throughput (Kbps)
1600
1200
MAX
MIN
4.42%
0.08%
800
400
PPTV
0
0
10
20
Time (minute)
30
800
400
0
0
PPS
0.09%
PPTV (400 Kbps)
SopCast
0.99%
1600
Upload Throughput (Kbps)
Upload Throughput (Kbps)
1600
1200
800
QQLive
0
0
1200
7.12%
400
10
20
Time (minute)
SopCast (530 Kbps)
30
Throughput of uploading
traffic varies between
10 Kbps to 1.5 Mbps
1200
800
10
20
Time (minute)
0.00%
30
PPS (396 Kbps)
0.22%
4.33%
400
0
0
10
20
Time (minute)
QQLive (500 Kbps)
30
Summary
• Control packets are delay-sensitive, highly
frequent, but their throughput is low
• Uploading traffic changes dynamically, and
could reach a very high throughput
• # of neighbors directly affect the control traffic
and uploading traffic amount, the response time
variance further shortens inter-packet delay
Outline
•
•
•
•
•
Problem Statement and Proposal
Internet Measurement
Design of BlueStreaming
Evaluation
Conclusion
Traffic shaping
• Let the media traffic arrive in a predicable
pattern:
– Periodic bursts
– WiFi can work / sleep correspondingly
– Allows the WiFi interface to exploit more sleep
opportunities
Time
Time
Sleeping
How about direct traffic shaping?
• With traffic shaping:
– Control packets, streaming data packets, and
Control
traffic ispackets are scheduled together
uploading
delay-sensitive!!
periodically
– Delayed control packets caused:
Re-requests
• Playback freezing, distortion
• 10% more streaming packets are received
QQLive
500 Kbps
Total # of
Streaming Packets
WiFi
Sleep Time (%)
Distortion/Freeze
Time (%)
Adaptive PSM
109,800
5.24
0
WiFi with traffic shaping
121,598
26.89
38
How about using Bluetooth directly?
• Using Bluetooth to access P2P streaming:
– Bluetooth also has lower data rate, and cannot
afford the streaming rate
– Only 34% streaming data packets were received
QQLive
500 Kbps
Total # of
Streaming Packets
WiFi
Sleep Time (%)
Distortion/Freeze
Time (%)
Adaptive PSM
109,800
5.24
0
WiFi with traffic shaping
121,598
26.89
38
37,228
n/a
96
Bluetooth only
BlueStreaming overview
• Traffic Classifier at AP and client:
– Decouples control traffic from streaming data
traffic, and uses Bluetooth to transmit
• Traffic Shaper at the client:
– Intelligently shapes streaming data downloading
traffic, and allows WiFi to save more power
• Uploading Scheduler at the client:
– Handles the uploading traffic with minimized extra
power consumption
Traffic classifier:
diverting control traffic to Bluetooth
• Decouple control traffic from uploading traffic
and streaming data traffic
WiFi
Time
• How can control traffic be decoupled from
streaming data traffic transparently?
Traffic classifier:
diverting control traffic to Bluetooth
• Control packets are identified empirically
based on packet sizes
• Bluetooth is always on to transmit delaysensitive control packets
WiFi
Bluetooth
Time
Traffic shaper: shaping ingress streaming
traffic intelligently
• Buffers streaming data packets at Access Point
• Applies client-centric traffic shaping, and
schedules transmission in a burst periodically
• How should the burst interval be set?
WiFi

??

Bluetooth


Sleeping


Sleeping
Time
Traffic shaper: shaping ingress streaming
traffic intelligently
• How should the burst interval be set?
– P2P streaming applications have a re-request
timer to determine if a chunk should be rerequested.
• Application-specific
– Packets should be transmitted before rerequest timer times out:
Uploading scheduler:
scheduling uploading wisely
• How can a client perform uploading with
minimized battery power consumption?
• Priority-based Bluetooth Uploading
WiFi

Bluetooth


Sleeping

Sleeping
Time
Uploading scheduler:
scheduling uploading wisely
• How can a client perform uploading with
minimized battery power consumption?
• Opportunistic WiFi Uploading:
– Allows WiFi to upload with a minimum consumption
of extra battery power
– Works seamlessly with the PSM mechanism
WiFi

Bluetooth

Sleeping


Sleeping
Time
Deployment issue
Infrastructure Mode
• A dedicated AP with both
WiFi and Bluetooth
• A BlueStreaming client
connects to the AP directly
Hybrid Mode
• WiFi AP does not need to
support Bluetooth
• An intermediate node relays
the control traffic to WiFi AP
Outline
•
•
•
•
•
Problem Statement and Proposal
Internet Measurement
Design of BlueStreaming
Evaluation
Conclusion
Implementation of BlueStreaming
• Prototype systems on Windows and Mac
• Why laptop instead of mobile devices?
– Desktop OS has more complete Bluetooth profiles
including Personal Area Network (PAN)
– More P2P streaming applications are available on
Windows
Experimental setup
• Use our Windows prototype running on one
laptop as BlueStreaming client to access:
– PPTV, PPS, SopCast, QQLive
• Use one MacBook with Bluetooth and WiFi
(802.11n at 2.4GHz) as the BlueStreaming
Access Point
• In hybrid mode:
– Another laptop is used to relay the control traffic
between BlueStreaming client and access point
Infrastructure mode: PPTV results
0.8
Total Traffic (MB)
Total Traffic (MB)
0.8
0.6
0.4
0.2
0
1200
1202
1204 1206
Time (second)
1208
PSM-A
0.6
0.4
0.2
0
1210 1200
1202
1204 1206
Time (second)
1210
Classifier only
Sleep Time (%)
PSM-A
Classifier only
1208
Consumed Energy
(J)
0.56
2005
25.82
1745
Infrastructure mode: PPTV results
0.6
0.4
0.2
0
1200
1202
1204 1206
Time (second)
1208
PSM-A
0.8
Total Traffic (MB)
0.8
Total Traffic (MB)
Total Traffic (MB)
0.8
0.6
0.4
0.2
0
1210 1200
1202
1204 1206
Time (second)
1208
Classifier only
1210
0.6
0.4
0.2
0
1200
1202
1204 1206
Time (second)
1208
BlueStreaming
Sleep Time (%)
PSM-A
Classifier only
Consumed Energy
(J)
0.56
2005
25.82
1745
BlueStreaming
60.50
1090
1210
Energy consumption comparisons
PPS has very small
re-request timeout
BlueStreaming
effectively saves energy
consumption for PPTV,
SopCast, QQLive
Conclusion
• A mobile client in P2P streaming consumes
excessive power because of
– extra control traffic
– extra uploading traffic
– dynamics of neighboring peers.
• BlueStreaming trades Bluetooth’s power
consumption for greater power saving on WiFi
interface via intelligent traffic shaping
– Saves up to 46% battery power consumption
Thank you!