1. Modified FCS/ARQ Behavior
Month Year
doc.: IEEE yy/xxxxr0
November, 2007
Modified FCS/ARQ Behavior
Date:
Authors:
Todor Cooklev, Hitachi America Ltd.
John Doe, Some Company

2. Objectives Summarize the work of the VTS SG
Month Year
doc.: IEEE yy/xxxxr0
November, 2007
Objectives
Summarize the work of the VTS SG
Produce a PAR and 5C document that is approved by the VTS SG and (perhaps today)
Eventually develop a standard that improves the performance of video over and the user experience
Todor Cooklev, Hitachi America Ltd.
John Doe, Some Company

3. Outline Characteristics of video signals High-layer FEC MAC-level FEC
Month Year
doc.: IEEE yy/xxxxr0
November, 2007
Outline
Characteristics of video signals
Very low BER
Retransmission is not an option
What can be done without retransmission?
High-layer FEC
MAC-level FEC
Is this supported by higher layers?
Conclusions
Slide 3
Todor Cooklev, Hitachi America Ltd.
John Doe, Some Company

4. Characteristics of video
Month Year
Month Year
doc.: IEEE yy/xxxxr0
doc.: IEEE yy/xxxxr0
November, 2007
Characteristics of video
Compressed to Mb/s
Generally, very, very low BER is required, say 1e-11
The DVB specification EN defines "Quasi-Error-Free" (QEF) operation as less than one error per hour.
For 3600 seconds/hour this translates to:     Error rate < 1/3600 ~ 2.8 e-4 errors/sec.
At a rate of Mbps for digital terrestrial television broadcast in the USA (ATSC A/53, part 2), this becomes:     BER < 1/3600/ ~ 1.4 e-11.
However, not all video bits are equally important for QoS
How is the Bit Error Rate of 10E-11 derived?
Slide 4
Todor Cooklev, Hitachi America Ltd.
Page 4
John Doe, Some Company
John Doe, Some Company

5. What if a whole MSDU is lost?
Month Year
doc.: IEEE yy/xxxxr0
November, 2007
What if a whole MSDU is lost?
A video MSDU contains 7 x 188 video octets, or 10,528 bits.
Ex. 1, TV (PAL) 720 x 480 = 345,600 pixels, Frame rate of 30 fps
TV = M Pixels/sec
SDTV at 8Mbps, then 1 bit = /8 = pixels
One lost packet is pixels = 13644/720 = 19 lines LOST
Ex. 2, HDTV 1920 x 1080 = 2,073,600 pixels
HD = 62.2M Pixels/sec, compressed to 20Mbps,
1 lost packet is 57 lines lost
Losing a minimum of 19 lines will definitely cause an observable video error!!
Todor Cooklev, Hitachi America Ltd.
John Doe, Some Company

6. Packet Loss of 0.1% gives 44 Errors per minute
Month Year
doc.: IEEE yy/xxxxr0
November, 2007
Effect of PER
Packet Loss of 0.1% gives 44 Errors per minute
Todor Cooklev, Hitachi America Ltd.
John Doe, Some Company

7. Packets lost per hour vs. number of retries without and with FEC
Month Year
Month Year
doc.: IEEE yy/xxxxr0
doc.: IEEE yy/xxxxr0
November, 2007
Packets lost per hour vs. number of retries without and with FEC
Slide 7
Todor Cooklev, Hitachi America Ltd.
Page 7
John Doe, Some Company
John Doe, Some Company

8. 802.11n Video Transmission Parameters
Month Year
doc.: IEEE yy/xxxxr0
November, 2007
802.11n Video Transmission Parameters
Video Rate, Mbps
Required PER(1)
Raw BER(2)
Raw PER
Maximum Number of re-transmissions(3)
Number of Aggregated MPDUs
Max Delay variation, ms 20
3e-7
1e-6
0.076 5 9
10.5(4) 8
7e-7 4 6
10.3
9.0
1.2
5e-6 3 2
10.1
Notes:
(1) PER (after retransmissions) needed for 30min error-free video
(2) This raw BER (before retransmissions) is a target BER of Rate Adaptation algorithm
(3) Number of retransmissions necessary to reach required PER
(4) See next slide for example calculation
Slide 8
Todor Cooklev, Hitachi America Ltd.
John Doe, Some Company

9. Bit Errors in a Video MSDU
Month Year
Month Year
doc.: IEEE yy/xxxxr0
doc.: IEEE yy/xxxxr0
November, 2007
Bit Errors in a Video MSDU
Video MSDU: 7*188 = bits
34 octets for the MAC header (draft p802.11n-D3.0 Cl )
8 octets for the LLC + SNAP header (RFC 1042)
20 octets for the IP header (RFC 791)
8 octets for the UDP header (RFC 768)
12 octets for the RTP header (RFC 1889)
Total header bits are 82 * 8 = 656 bits
4 octets for the FCS appended to the end of packet ( , Cl )
If there is an error, it is likely in the payload (~95% probability)
If the bit error is in the video payload and the application can cope with the bit error, why discard the packet?
Slide 9
Todor Cooklev, Hitachi America Ltd.
Page 9
John Doe, Some Company
John Doe, Some Company

10. Retransmissions are not really an option Example: IPTV
Month Year
doc.: IEEE yy/xxxxr0
November, 2007
Retransmissions are not really an option Example: IPTV
There must be end-to-end QoS.
VOD Servers
Retransmissions outside the home disabled, to avoid overloading the network.
DSLAM
Core Network
DSL Modem
Todor Cooklev, Hitachi America Ltd.
John Doe, Some Company

11. What can be done about errors in a video signal?
Month Year
doc.: IEEE yy/xxxxr0
November, 2007
What can be done about errors in a video signal?
Retransmissions – the current
Works from point A to point B in a BSS
Disadvantages of retransmissions:
Does not work for multicast
For unicast retransmission requires additional buffering of packets
Conclusion: Retransmitting video is not an option
If retransmission is not an option, then what?
The MAC delivers frames with payload bit errors and FEC at a higher layer
FEC at a MAC layer
Todor Cooklev, Hitachi America Ltd.
John Doe, Some Company

12. Month Year
doc.: IEEE yy/xxxxr0
November, 2007
FEC Techniques
FEC in PHY layers allows to correct bit errors in one packet.
This type of FEC does not help if the whole packet is gone
Examples: convolutional coding, RS, LDPC
There is a different type of FEC, called packet-based FEC. If one or more packets are missing, they can be recovered from other packets.
Slide 12
Todor Cooklev, Hitachi America Ltd.
John Doe, Some Company

13. Packet-based FEC idea Given k data packets Generate n-k parity packets
Month Year
doc.: IEEE yy/xxxxr0
November, 2007
Packet-based FEC idea
Given k data packets
Generate n-k parity packets
Transmit n packets
Any subset of k correctly received packets suffices to reconstruct the data. (The exact position of missing packets is unknown.)
Very efficient for multicast! Different receivers can use different subsets of k correctly received packets to recover all packets.
Slide 13
Todor Cooklev, Hitachi America Ltd.
John Doe, Some Company

14. FEC at a Higher Layer: Basic Methodology
Month Year
Month Year
doc.: IEEE yy/xxxxr0
doc.: IEEE yy/xxxxr0
November, 2007
FEC at a Higher Layer: Basic Methodology
Introduce another FEC layer after encryption – this guarantees packet level bit error correction at the receiver.
How easy it is to enable the hardware crypto engine to also perform a packet level FEC?
Slide 14
Todor Cooklev, Hitachi America Ltd.
Page 14
John Doe, Some Company
John Doe, Some Company

15. Header FCS and Payload FCS Idea
Month Year
Month Year
doc.: IEEE yy/xxxxr0
doc.: IEEE yy/xxxxr0
November, 2007
Header FCS and Payload FCS Idea
Octets: 2        2            6        6       6          2         6         2                          0-2324 
Frame Control
Duration/ID
Add-1
Add-2
Add-3
Sequence Control
Add-4
QoS Control
Frame Body
FCS
Payload Start
Headers
Application Payload
Header FCS
|< Header FCS range (Protected field) >|
Slide 15
Todor Cooklev, Hitachi America Ltd.
Page 15
John Doe, Some Company
John Doe, Some Company

16. Month Year
doc.: IEEE yy/xxxxr0
November, 2007
Higher-Layer FEC
Requires Header FCS and Payload FCS for backwards compatibility
Indication that Stream is using FEC
What about encryption?
Slide 16
Todor Cooklev, Hitachi America Ltd.
John Doe, Some Company

17. FEC at the MAC Layer November, 2007 Month Year
doc.: IEEE yy/xxxxr0
November, 2007
FEC at the MAC Layer
Todor Cooklev, Hitachi America Ltd.
John Doe, Some Company

18. Is Allowing Payload Bit Errors Based on Sound Technical Principles?
Month Year
doc.: IEEE yy/xxxxr0
November, 2007
Is Allowing Payload Bit Errors Based on Sound Technical Principles?
RFC 3828 – “First, there is a class of applications that benefit from having damaged data delivered rather than discarded by the network. A number of codecs for voice and video fall into this class”
“ … Lightweight User Datagram Protocol (UDP- Lite), can serve applications in error-prone network environments that prefer to have partially damaged payloads delivered rather than discarded. If this feature is not used, UDP-Lite is semantically identical to UDP. “
Todor Cooklev, Hitachi America Ltd.
John Doe, Some Company

19. Month Year
doc.: IEEE yy/xxxxr0
November, 2007
UDP Lite (RFC 3828)
“The error- detection mechanism of the transport layer must be able to protect vital information such as headers, but also to optionally ignore errors best dealt with by the application.”
“When using this option, a packet is divided into a sensitive part (covered by the checksum) and an insensitive part (not covered by the checksum).“
“Since UDP-Lite can deliver packets with damaged payloads to an application that wishes to receive them, frames carrying UDP-Lite packets need not be discarded by lower layer protocols when there are errors only in the insensitive part.”
Todor Cooklev, Hitachi America Ltd.
John Doe, Some Company

20. Month Year
doc.: IEEE yy/xxxxr0
November, 2007
What About Security?
“If a few bits of an encrypted packet are damaged, the decryption transform will typically spread errors so that the packet becomes too damaged to be of use. Many encryption transforms today exhibit this behavior.” (RFC 3828)
However, there are encryption methods which do not cause error propagation (e.g. aes-ofm, )
802.11i provides a framework for allowing additional ciphers in the future
“Unless authentication mechanisms that operate only on the sensitive part of packets are developed and used, authentication will always fail.” (RFC 3828)
Todor Cooklev, Hitachi America Ltd.
John Doe, Some Company

21. Month Year
doc.: IEEE yy/xxxxr0
November, 2007
Conclusions
Video streaming requires very, very low packet loss and controlled latency
Delivery of packets with payload bit errors makes sense
Some higher-layer standards expect this capability from lower layers
Additional FEC reduces the need for retransmission and can make the system much more robust
Todor Cooklev, Hitachi America Ltd.
John Doe, Some Company

22. Month Year
doc.: IEEE yy/xxxxr0
November, 2007
Straw Poll
This technique is useful and should be included in the VTS SG PAR
This technique is not useful and needs to be removed from the VTS SG PAR
This technique is useful, but the VTS SG needs to study it further and bring a more complete proposal
Slide 22
Todor Cooklev, Hitachi America Ltd.
John Doe, Some Company

23. Thank You November, 2007 Month Year doc.: IEEE 802.11-yy/xxxxr0
Todor Cooklev, Hitachi America Ltd.
John Doe, Some Company