Transcript No Slide Title

UDP Lite for
Wireless Video Streaming
Almudena Konrad, Amoolya Singh,
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
H.263+ Encoder
H.263+ Decoder
Packetization
De-packetization
RTP
RTP
Socket Interface
Socket Interface
UDP / UDP Lite
UDP / UDP Lite
IP
IP
PPP
PPP
transparent /
non transparent
transparent /
non transparent
GSM Network
Mobile Host
Unix BSDi 3.0
PSTN
Fixed Host
Unix BSDi 3.0
GSM
Base Station
SocketDUMP
SocketDUMP
MultiTracer
RLPDUMP
Plotting &
Analysis
(MATLAB)
UDP Lite
(Larzon, Degemark, and Pink)
• 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)
0
7 8
source port #
length / coverage
15
dest port #
checksum
Physical / Radio Link Layer
(GSM 9.6 kb/s)
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)
Channel Simulator: WSim
Wireless Error Trace
Input Video Stream
WSim
Output Video Stream
• Allows “easy” performance study of UDP-Lite, and
error resilience functionalities
• Simulates two protocol configurations:
– UDP, non-transparent and UDP Lite, transparent
• Uses 215 min of GSM wireless error traces collected in
a poor channel environment
Performance Analysis
Experiment
• Collect 4480 min of wireless video traces, (~4 min per video)
– Bad channel conditions (signal strength ~2-3)
• Three different network configurations
– UDP, non-transparent
– UDP, transparent
– UDP-Lite, transparent
• 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
Experimental Results
End to End Delay
2.5
Mean & Std Dev
End-to-End Delay (s)
2.0
1.726
1.5
1.0
0.511
0.5
0.377
0.0
UDP, non-transparent
UDP, transparent
UDP Lite, transparent
Inter-Arrival Time
0.70
Inter-arrival Time (s)
Mean & Std Dev
0.65
0.60
0.601
0.594
0.597
0.55
0.50
UDP, non-transparent
UDP, transparent
UDP Lite, transparent
Packet Loss
Mean & Std Dev
Packet Loss (%)
3%
2.09%
2%
1.05%
1%
0.00%
0%
UDP, non-transparent
UDP, transparent
UDP Lite, transparent
Video Screenshots
Experiment
UDP
Simulation
UDP
UDP Lite
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 (with GSM in non-transparent mode)
• In general, can choose protocol combination appropriate for
application
Type of Application
intolerant &
rigid*
tolerant &
daptive*
Example
Protocol Choice
Batch: email, ftp
TCP / RLP
Interactive: telnet, web
UDP / RLP
Hard real-time: wb, v-conf
UDP / RLP
Adaptive real-time: vic, vat UDP Lite /transparent
Future Work
• Provide real-time feedback on channel
conditions
• Provide rate control
• Incorporate unequal error protection for
MPEG4