Pres_Video_wireless.ppt
Upcoming SlideShare
Loading in...5
×
 

Pres_Video_wireless.ppt

on

  • 796 views

 

Statistics

Views

Total Views
796
Views on SlideShare
796
Embed Views
0

Actions

Likes
0
Downloads
2
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • The title of this presentation is “……”, and the people involved in this work are
  • There is an increasing demand of multimedia servicies over wireless, such as mobile banking or web browsing on cellular phones. This new applications require new functionalitites in the networks. The wireless link posses some challenges for sending video streams. The reasons are the well known constrains of low bit rate and high error rate. In this project we develop a wireless network infrastructure to overcome this wireless channels constraints to deliver high data rates with low distortion and low latency. We provide link layer/transport alternatives to support error resilient video codecs. We also provide diagnostic tools to study the performance of our proposed wireless network solution.
  • We use the following testbed, protocols and tools: Our testbed consits of a mobile host communicating to an stationary host through the circuit-sw GSM network. At the application layer we were interested in an video codec that provided low bit rate and error resilient functionalities, so we chose H.263+ for this purpose. H.263+ is an error-resilient video codec for “very low” (< 64 kb/s) bit rates , the images are QCIF (176x144 pixels), and the frame rate is 10 to 15 frames per sec. At the transport layer we implemeted RTP, to provide information to the application layer, such as seq-num and timestamp. At the transport layer, we have the choices of selecting between UDP and UDP-Lite. UDP drops any received corrupted packets, on the contrary UDP-Lite allows corruption of non-sensitive data to be tranfer to the application layer. At the link layer, end-to-end we have ppp, the point to point protocol. PPP will also drop packets if corrupted, so Keith Sklower modified PPP to PPP-Lite, to work together with UDP-Lite allowing corruption in the non-sensitive part non-sensitive part of the frames. At the radio link layer , we have the choices of running the radio link in no-transparent or transparent mode, where the non-transparent mode uses an reliable ARQ prototcol, RLP. And the transparent mode sends raw data through the radio interface w/out any error-control scheme. We instrumented our socket interface to collect statistics at the RTP layer, and we also log information at the radio link layer. We collect 3 log files per connection, this files are process by our “MultiTracer program”, which allows the plottting of traffic at both transport and link layer, and also prepares the data in a way that can be easily analyses by MATLAB, or any other statistics tools.
  • UDP Lite is a version of UDP created by … that allows the len field is replaced by the coverage filed which specifies how many bytes of the packet have been checksum, in our study we only protect the header, allowing any corrupting in the data being transmitted. Lars and Mikael provide us with an UDP-Lite implementation for FreBSDi, and Keith transport this implementation to BSDi3.0, he also include an PPP-Lite implementation.
  • The data rate of the radio link in GSM is 9.6kbps, and has two modes of operation: transparent and non-transparent mode. The trans. mode can be run with or without error control V.42, with or without data compression V.42.bis, and syncho. or asynchronous. Afetr performing a set of ping measurements with the different configuration and collected RTT and packet loss statistics. We chose to run transparent mode with no error-control or compression, and in asynchronous mode. This configuration introduces min delay at the cost of corruption. The non- transparent mode, uses RLP for reliability. SREJ, is initiated by the receiver whenever it receives a frame out of order, when the receiver notice a frame out of sequence it sends a SREJ with the missing frame, then the receives the SREJ and retransmit the missed frame, and continues sending where it was before receiving the SREJ. The second error recovery mechanism is Chek., Chek. Is initiated by the sender whenever a frame timer expires. It could be that either the frame or the ack from the receiver got lost, so the timer for this frame times out. At this point the sender starts checkpointing by sending a control frame with a special bit, called the Poll bit set to 1, asking the receiver to report to the sender the latest status. When the receiver gets this control frame it will send a frame with the fr # which is expecting next, then the sender will do GoBack N transmitting from that point on. To understand the tradeoffs between RLP and non-RLP
  • Besides, building a network architecture, we created a channel simulator, Wsim. By using the network infrastructure, it is sometimes difficult to isolate specific problems. For example, to test the error resilience functionalities of a codec, or to study the performance of UDP-Lite for a specific bit error rate in the wireless channel, it would be very time-consuming to take measurements until we find the specific error rate. On the other hand, using this simulator, we input a wireless error trace with specific wanted characteristics, and study the effect that this error rate has on the video quality. We have several hours of collected wireless traces from previos work. A wireless trace consist of a binary sequence where each element represent the state of a radio block. Wsim takes as input on of this error traces and an input video stream, and it will corrupt the video stream according to where the error occur in the error trace. The output video stream is the input video stream but with corruption according to the wireless error trace. Last two bullets.
  • Udp,rlp => wants to demostrate that rlp introduces delay ….
  • this plot has been generated by multitracer and it shows the traffic at two layers, in the top plot we show the seq-num and timestamp of received packets, the lower plot shows retransmission of radio blocks.
  • Sender buffer overflow sender send a packet every 100 ms application data rate much faster than RLP data rate increasing buffer size introduces jitter decreasing appl. data rate introduces end-to-end delay Packet loss rate < 1% because RLP guarantees correct delivery and video streams sent were not larger than 12,309 bytes to avoid buffer overflow
  • Sender buffer overflow sender send a packet every 100 ms application data rate much faster than RLP data rate increasing buffer size introduces jitter decreasing appl. data rate introduces end-to-end delay Packet loss rate < 1% because RLP guarantees correct delivery and video streams sent were not larger than 12,309 bytes to avoid buffer overflow

Pres_Video_wireless.ppt Pres_Video_wireless.ppt Presentation Transcript

  • UDP Lite for Wireless Video Streaming Amoolya Singh, Almudena Konrad, and Anthony Joseph University of California, Berkeley Jun 19, 2000
  • Idea
    • Problem
    • Current Internet doesn’t support bit error resilient codecs
    • Goal
    • Support real-time streaming applications over noisy channels, such as wireless
    • Proposed Solution
    • Provide link/transport layer alternatives to support error resilient video codecs
  • Testbed, Protocols, Tools MultiTracer SocketDUMP RLPDUMP Plotting & Analysis (MATLAB) UDP / UDP Lite Socket Interface H.263+ Encoder RTP IP PPP Packetization RTP UDP / UDP Lite IP PPP De-packetization H.263+ Decoder Socket Interface Fixed Host Unix BSDi 3.0 GSM Base Station GSM Network PSTN Mobile Host Unix BSDi 3.0 SocketDUMP RLP / non RLP RLP / non RLP
    • Flexible checksumming scheme allows corrupted data to be transmitted to the application
    • “ length” field in UDP header replaced by “coverage” field
    • Specifies how many bytes of payload to checksum
    • Implemented in BSDi 3.0 kernel (Keith Slower)
    UDP Lite (Larzon, Degemark, and Pink) source port # dest port # length / coverage checksum 0 7 8 15
    • Transparent Mode
    • no error control mechanism
    • Non-Transparent Mode
    • Uses RLP (Radio Link Protocol), a semi-reliable ARQ protocol
      • Link resets after N=7 number of re-transmissions
    • Fixed frame size of 30 bytes (6 bytes header)
      • Reliability at the cost of additional end-to-end delay
    • Window size of 62 frames
    • Error recovery mechanisms
      • Select - Reject (initiated by receiver)
      • Checkpointing (initiated by sender)
    Physical / Radio Link Layer (GSM 9.6 kb/s)
  • Channel Simulator: WSim WSim Wireless Error Trace Input Video Stream Output Video Stream
    • Allows “easy” performance study of UDP-Lite, and error resilience functionalities
    • Simulates two protocol configurations:
      • UDP, non-RLP and UDP Lite, non-RLP
    • Uses 215 min of GSM wireless error traces collected in a poor channel environment
    • Experiment
    • Collect 4480 min of wireless video traces, (~4 min per video)
      • Bad channel conditions (signal strength ~2-3)
    • Three different network configurations
      • UDP, RLP
      • UDP, non-RLP
      • UDP-Lite, non-RLP
    • For each trace, we calculated metrics
      • end-to-end, inter-arrival time ,loss rate and throughput
    • For each metric, we calculated statistics
      • mean & std dev
    • Simulation
    • Run Wsim on “mom” video stream using a wireless error trace of 1.5% BLER
    Performance Analysis
  • Experimental Results
  • End to End Delay
  • Inter-Arrival Time
  • Packet Loss
  • Video Screenshots UDP UDP Lite Experiment Simulation UDP UDP Lite
  • Discussion & Conclusions
    • Reliability at link layer causes delay
    • Strict checksumming of UDP causes poor “error resilience” at application
    • UDP Lite (with GSM in transparent mode) provides
      • less end to end delay
      • constant jitter
      • higher throughput
      • lower packet loss
      • … than UDP
    • In general, can choose protocol combination appropriate for application
    Batch: email, ftp UDP Lite /non-RLP Adaptive real-time: vic, vat UDP / RLP Hard real-time: wb, v-conf tolerant & daptive * UDP / RLP Interactive: telnet, web TCP / RLP Protocol Choice Type of Application Example intolerant & rigid *
    • Provide real-time feedback on channel conditions
    • Provide rate control
    • Incorporate unequal error protection for MPEG4
    Future Work