“The most profound technologies arethose that disappear” - Mark Weiser
Outline Goal Motivation Challenges of video streaming overBluetooth PAN Our approach Evaluation of approach Implemen...
Goal• Tie up three promising technologies – Video  On Demand, Bluetooth, P2P• To provide video on demand services in  Blue...
Motivation• Increased usage of Bluetooth devices• Promises of Bluetooth 3.0 – data rates up to  480Mbps, energy efficient ...
Challenges• Low end devices ; Devices can barely handle  video processing• Limitations of current Bluetooth technology  (d...
Solution Sketch• One video session per request will overload  the server , which is also a low end device• Simple 1 to N b...
Logical Topology of the System
Benefits of introducing Head Node• A client can have only a single video session. A  server can support multiple server se...
The Notion of Generations
Join Algorithm
Catalog Maintenance• Build a global catalog using periodic exchange of  control information (Send only updates, not the  e...
Fault Tolerance• Failure of Head Node   – Replicate the Head Node   – Promote a child as head node when the server cannot ...
Load balancing• Head node can become too overloaded for  large G. [Large G offers higher fault tolerance].• Hence, head no...
Metrics• Service Acceptance ratio : Given the  parameters that model the system, what  percentage of nodes can successfull...
SAR [Theoretical]
Average Jitter [Theoretical]
Workload distribution [Simulated]
Bluetube Implementation
Bluetube: Key points• Currently supports MPEG-1 videos (good  starting point)• Video splitting  – Videos are split into ch...
Server properties• Selectively publishes videos• Listens for client requests• Upon receiving video request, sends “chunks”...
Client properties• Performs a devices search followed by services  search• Published videos get displayed on client  scree...
Development Environment• Sun Java Wireless Toolkit 2.5.2 for CLDC  – Formerly known as J2ME Wireless Toolkit• Key features...
Demo
What about a real device??
Concluding remarks• A first-of-its kind effort• Establishes that reality is not far• Future focus on using Gossip based pr...
We had a dream…   Thank you
Bluetube
Upcoming SlideShare
Loading in...5
×

Bluetube

239

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
239
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
1
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Bluetube

  1. 1. “The most profound technologies arethose that disappear” - Mark Weiser
  2. 2. Outline Goal Motivation Challenges of video streaming overBluetooth PAN Our approach Evaluation of approach Implementation Demo Conclusion The University of Texas at Austin 2
  3. 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. 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. 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. 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. 7. Logical Topology of the System
  8. 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. 9. The Notion of Generations
  10. 10. Join Algorithm
  11. 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. 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. 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. 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. 15. SAR [Theoretical]
  16. 16. Average Jitter [Theoretical]
  17. 17. Workload distribution [Simulated]
  18. 18. Bluetube Implementation
  19. 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. 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. 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. 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. 23. Demo
  24. 24. What about a real device??
  25. 25. 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
  26. 26. We had a dream… Thank you
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×