Published on

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide


  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