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

Objectives Summarize the work of the VTS SG Month Year doc.: IEEE 802.11-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 802.1 (perhaps today) Eventually develop a standard that improves the performance of video over 802.11 and the user experience Todor Cooklev, Hitachi America Ltd. John Doe, Some Company

Outline Characteristics of video signals High-layer FEC MAC-level FEC Month Year doc.: IEEE 802.11-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

Characteristics of video Month Year Month Year doc.: IEEE 802.11-yy/xxxxr0 doc.: IEEE 802.11-yy/xxxxr0 November, 2007 Characteristics of video Compressed to 10-25 Mb/s Generally, very, very low BER is required, say 1e-11 The DVB specification EN301201 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 19.39 Mbps for digital terrestrial television broadcast in the USA (ATSC A/53, part 2), this becomes:     BER < 1/3600/19390000 ~ 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

What if a whole MSDU is lost? Month Year doc.: IEEE 802.11-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 = 10.368M Pixels/sec SDTV at 8Mbps, then 1 bit = 10.368/8 = 1.296 pixels One lost packet is 13644 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

Packet Loss of 0.1% gives 44 Errors per minute Month Year doc.: IEEE 802.11-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

Packets lost per hour vs. number of retries without and with FEC Month Year Month Year doc.: IEEE 802.11-yy/xxxxr0 doc.: IEEE 802.11-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

802.11n Video Transmission Parameters Month Year doc.: IEEE 802.11-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

Bit Errors in a Video MSDU Month Year Month Year doc.: IEEE 802.11-yy/xxxxr0 doc.: IEEE 802.11-yy/xxxxr0 November, 2007 Bit Errors in a Video MSDU Video MSDU: 7*188 = 10528 bits 34 octets for the MAC header (draft p802.11n-D3.0 Cl. 7.1.2) 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 (802.11-2007, Cl. 7.1.2) 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

Retransmissions are not really an option Example: IPTV Month Year doc.: IEEE 802.11-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

What can be done about errors in a video signal? Month Year doc.: IEEE 802.11-yy/xxxxr0 November, 2007 What can be done about errors in a video signal? Retransmissions – the current 802.11 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

Month Year doc.: IEEE 802.11-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

Packet-based FEC idea Given k data packets Generate n-k parity packets Month Year doc.: IEEE 802.11-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

FEC at a Higher Layer: Basic Methodology Month Year Month Year doc.: IEEE 802.11-yy/xxxxr0 doc.: IEEE 802.11-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

Header FCS and Payload FCS Idea   Month Year Month Year doc.: IEEE 802.11-yy/xxxxr0 doc.: IEEE 802.11-yy/xxxxr0 November, 2007 Header FCS and Payload FCS Idea Octets: 2        2            6        6       6          2         6         2                          0-2324  4 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

Month Year doc.: IEEE 802.11-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

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

Is Allowing Payload Bit Errors Based on Sound Technical Principles? Month Year doc.: IEEE 802.11-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

Month Year doc.: IEEE 802.11-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

Month Year doc.: IEEE 802.11-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, 15-07-0919) 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

Month Year doc.: IEEE 802.11-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

Month Year doc.: IEEE 802.11-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

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