This document outlines a proposal for video streaming over Bluetooth using a peer-to-peer approach. It discusses the goals, challenges, proposed solution, and implementation of Bluetube. The key aspects are using a content distribution tree to distribute video chunks amongst clients, with early clients serving late clients. An evaluation of the theoretical service acceptance ratio, jitter, and workload distribution is provided. The document concludes with details about the Bluetube proof-of-concept implementation developed in Java for emulation.

1. “The most profound technologies are
those that disappear” - Mark Weiser

2. Outline
 Goal
 Motivation
 Challenges of video streaming over
Bluetooth PAN
 Our approach
 Evaluation of approach
 Implementation
 Demo
 Conclusion
The University of Texas at Austin 2

3. Goal
• Tie up three promising technologies – Video
On Demand, Bluetooth, P2P
• To provide video on demand services in
Bluetooth , using pure P2P approach
• A Pure P2P approach has a broader range of
applicability, as one need not rely on server
infrastructure anywhere . [as needed for a
Hybrid P2P approach]

4. Motivation
• Increased usage of Bluetooth devices
• Promises of Bluetooth 3.0 – data rates up to
480Mbps, energy efficient – making them a
very attractive platform for development of
‘Smart Applications’
• Video-On-Demand is one of the most popular
applications of the past decade
• P2P applications call the shots, in today’s
Internet. Eg: Skype, Yahoo Messenger,
Gnutella

5. Challenges
• Low end devices ; Devices can barely handle
video processing
• Limitations of current Bluetooth technology
(data rates only upto 2.0Mbps)
• A single sender – N recipients problem that
can cause a bottleneck at the sender
• Fault tolerance is difficult to achieve in a
dynamic environment
• Load balancing issues need to be addressed
• Support multiple sessions at the same server

6. Solution Sketch
• One video session per request will overload
the server , which is also a low end device
• Simple 1 to N broadcast of video chunks from
the Server will not work
• Server directly serves only some clients.
• A content distribution tree is formed amongst
the clients
• Early client serve late coming clients

7. Logical Topology of the System

8. Benefits of introducing Head Node
• A client can have only a single video session. A
server can support multiple server sessions.
• Out bound bandwidth is limited (about 200
kilobytes per second only)
• An attempt to achieve optimal load balancing
throughout the entire network
• Server serves only one node per session
• Seems a good idea. But …

9. The Notion of Generations

10. Join Algorithm

11. Catalog Maintenance
• Build a global catalog using periodic exchange of
control information (Send only updates, not the
entire data) and query it locally
• Provides fast search times
• Use soft state with ER
• Some information that this catalog could store
are video lists at other nodes, current buffer
usages, message processing backlogs, processor
utilization and number of active server sessions
• Optimize by writing expired state to disk and
garbage collect later

12. Fault Tolerance
• Failure of Head Node
– Replicate the Head Node
– Promote a child as head node when the server cannot
support head node replication
• Failure of Server
– Can do something about the intermittent failures of
the servers by buffering future chunks at other nodes
– Bandwidth is free. No issues
• Failure of Client nodes
– Handled as in P2VOD

13. Load balancing
• Head node can become too overloaded for
large G. [Large G offers higher fault tolerance].
• Hence, head node can be replicated to
overcome this bottleneck
• A dynamic load balancing algorithm that can
adapt the amount of replication and G, based
on current load

14. Metrics
• Service Acceptance ratio : Given the
parameters that model the system, what
percentage of nodes can successfully join the
system and receive the services
• Workload : The amount of work that is
pending at each node at any particular time.
• Jitter : The amount of time a node waits for
services during a given finite duration run of
the protocol

15. SAR [Theoretical]

16. Average Jitter [Theoretical]

17. Workload distribution [Simulated]

18. Bluetube Implementation

19. Bluetube: Key points
• Currently supports MPEG-1 videos (good
starting point)
• Video splitting
– Videos are split into chunks (beforehand) and
stored
• Application launched as server or client at any
given instant
• Supports late coming peers
• RFCOMM

20. Server properties
• Selectively publishes videos
• Listens for client requests
• Upon receiving video request, sends “chunks”
of the video to client
• Can handle multiple client requests (upto a
maximum of 6)

21. Client properties
• Performs a devices search followed by services
search
• Published videos get displayed on client
screen
• Client selects a video to play
• Receives video chunks from server
• Chunk player plays chunks while buffering
remaining chunks

22. Development Environment
• Sun Java Wireless Toolkit 2.5.2 for CLDC
– Formerly known as J2ME Wireless Toolkit
• Key features:
– Emulation environment designed to run
applications on cell phones
– Performance optimization and tuning

23. Demo

25. What about a real device??

26. Concluding remarks
• A first-of-its kind effort
• Establishes that reality is not far
• Future focus on using Gossip based protocols
for improving performance
• Further analysis on intermittent server failure
handling
• Better load balancing scheme

27. We had a dream…
Thank you