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
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 …
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
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
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