1 / 22

Streaming video over wireless link

Streaming video over wireless link. Agenda. Main issues with streaming over wireless link Link layer approach Transport protocol approach (to be added) Conclusions and future work. Video over wireless link. Typical scenario: video transmission from set-top box to the (mutiple) screens.

elvinm
Download Presentation

Streaming video over wireless link

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Streaming video over wireless link Sergei N. Kozlov, s.n.kozlov@tue.nl TU/e Informatica, System Architecture and Networking

  2. Agenda • Main issues with streaming over wireless link • Link layer approach • Transport protocol approach (to be added) • Conclusions and future work Sergei N. Kozlov, s.n.kozlov@tue.nl TU/e Informatica, System Architecture and Networking

  3. Video over wireless link • Typical scenario: video transmission from set-top box to the (mutiple) screens wireless Sergei N. Kozlov, s.n.kozlov@tue.nl TU/e Informatica, System Architecture and Networking

  4. Video over wireless link (II) • Wireless link properties: • High losses • Low troughput • High jitter • Typical perceived quality issues: • Artefacts • “Hick-ups” Sergei N. Kozlov, s.n.kozlov@tue.nl TU/e Informatica, System Architecture and Networking

  5. Techniques we look at OSI stack: application layer MPEG en-/decoder MPEG-packetizer transport layer TCP, UDP/RTP network layer IP (Internet Protocol) packet scheduler 802.11 driver link layer physical layer 802.11 WLAN Sergei N. Kozlov, s.n.kozlov@tue.nl TU/e Informatica, System Architecture and Networking

  6. Simplified sender/receiver communication video source video sink sender buffer receiver buffer wireless interface (sender) wireless inerface (receiver) Sergei N. Kozlov, s.n.kozlov@tue.nl TU/e Informatica, System Architecture and Networking

  7. Link layer approach Sender Application/ encoder MAC-level retries video stream driver/scheduler buffer IP packets TCP/IP stack Sergei N. Kozlov, s.n.kozlov@tue.nl TU/e Informatica, System Architecture and Networking

  8. I BBPBBPBB(I) MPEG encoding • GOP (group-of-pictures): • Frame types: I, P, B • Typical GOP structure and dependances: • Importance of a frame decreases in following order: I, P, B Sergei N. Kozlov, s.n.kozlov@tue.nl TU/e Informatica, System Architecture and Networking

  9. application layer MPEG en-/decoder MPEG-packetizer transport layer TCP, UDP/RTP network layer IP (Internet Protocol) packet scheduler 802.11 driver link layer 802.11 WLAN physical layer Scheduling of frames (I) • Packetizing • Assign prioritites to packets according to frame types: P(B) = 1 P(P) = 2 P(I) = 3 • Scheduling • Packets with higher priorities should get a better chance to be sent Involved layers Sergei N. Kozlov, s.n.kozlov@tue.nl TU/e Informatica, System Architecture and Networking

  10. Scheduling of frames (II) • Scheduling algorithm (level of frames) buffered frame sent frame incoming frame Fi Fb Fs if P(Fi) >= P(Fb) Fb := Fi else Fi := 0 (discard Fi) Sergei N. Kozlov, s.n.kozlov@tue.nl TU/e Informatica, System Architecture and Networking

  11. Advantages of link layer approach • We only need to modify the sending part • it will work with any terminals supporting RTP reception • it is an alternative to layered scalable video • it is very reactive against fast network fluctuations Sergei N. Kozlov, s.n.kozlov@tue.nl TU/e Informatica, System Architecture and Networking

  12. Transport layer approach • If... • we don’t have direct access to the wireless interface • we don’t want to modify it • we want more reliability, than UDP/RTP does • ... then we would like to look at the tranport layer Sergei N. Kozlov, s.n.kozlov@tue.nl TU/e Informatica, System Architecture and Networking

  13. TCP-RTM*: “semi-reliable” protocol • Combines retransmission abilities of TCP and non-blocking behavior of RTP • Retransmission mechanisms reused from TCP • Packets that cannot be delivered in timely fashion are being skipped • Application techniques resemble those for RTP (surveyed later) • Requires minimum of TCP-code modifications, can be implemented as another TCP-option * Sam Liang, David Cheriton, “TCP-RTM: Using TCP for Real Time Applications,” Submitted to IEEE ICNP ’02, 2002 Sergei N. Kozlov, s.n.kozlov@tue.nl TU/e Informatica, System Architecture and Networking

  14. Receiving application snd_cwnd step1 ? re-request on dup-acks Receiving application step2 ! Too late to resend - acknowledge Receiving application step3 segment received but not yet consumed by application empty buffer segment consumed by application skipped segment TCP-RTM receiver – “read-over-hole” technique Sergei N. Kozlov, s.n.kozlov@tue.nl TU/e Informatica, System Architecture and Networking

  15. TCP-RTM – application techniques • Receiver application doesn’t read from the buffer until the data is needed for timely playback • this provides fixed play-back delay • timestamps are needed for this • TCP-RTM supports application-level framing (ALF) • one application frame per TCP-segment – hence, always integral application frames are lost • every application write/read operation deals with 1 application level frame • ALF helps effective recovery from the losses Sergei N. Kozlov, s.n.kozlov@tue.nl TU/e Informatica, System Architecture and Networking

  16. Receiving application snd_cwnd step1 ? ? ? Receiving application step2 ? ? ? Receiving application re-send on rto step3 out-of-date received out-of-date segments empty buffer segments received but not yet consumed by application segments consumed by application TCP-RTM and burst losses Sergei N. Kozlov, s.n.kozlov@tue.nl TU/e Informatica, System Architecture and Networking

  17. Recovery price • rto is doubled with every packet loss buf_size = 64K, frame_size=1K, frames sent every period=20mS Near-exponential dependency – congestion window doesn’t grow large enough to trigger the dup-ack retransmission * - TCP-buffer gets full Sergei N. Kozlov, s.n.kozlov@tue.nl TU/e Informatica, System Architecture and Networking

  18. TCP-FCW vs TCP-RTM • TCP-RTM wasn’t meant to be used on burst losses networks • Losses of more than one segment in a row are not expected to happen • To be used on the real Internet • Be TCP friendly (use congestion avoidance) • TCP-FCW meets different assumptions • To be used on the QoS enabled networks with bandwidth reservations • “Send as fast as you can, but not faster than requested by the application” • Thus, we can control the bit-rate of the transmission on the application level • Provide “immediate recovery” – no slow start • It’s not meant to be used on the current Internet Sergei N. Kozlov, s.n.kozlov@tue.nl TU/e Informatica, System Architecture and Networking

  19. Receiving application step1 ? ? ? Receiving application re-request – on dup-acks again step2 ! Receiving application resent step3 packet received but not consumed by application empty buffer skipped packet recovered packet packet consumed by application TCP-FCW: “free-congestion-window” Sergei N. Kozlov, s.n.kozlov@tue.nl TU/e Informatica, System Architecture and Networking

  20. Evaluation • Result: exponential growth of latency in case of TCP-RTM vs linear growth in case of TCP-FCW Sergei N. Kozlov, s.n.kozlov@tue.nl TU/e Informatica, System Architecture and Networking

  21. Further work • Link-layer • creating math. model • evaluation • Protocol-layer • combination TCP sender + TCP-RTM receiver • much higher bit-rates should become possible • the behavior of sliding window should be investigated • packetizing should be provided on the application level (i.e. by means of delimiters) • creating math. model • evaluation Sergei N. Kozlov, s.n.kozlov@tue.nl TU/e Informatica, System Architecture and Networking

  22. Questions? Sergei N. Kozlov, s.n.kozlov@tue.nl TU/e Informatica, System Architecture and Networking

More Related