1. doc.: IEEE 802.11-07/2714r0 Submission Modified FCS/ARQ behaviour Allow the delivery of frames: with configurable retransmission policies, and in certain well defined instances, appropriately tagged frames with payload bit errors November 2007 John Doe, Some CompanySlide 1

2. doc.: IEEE 802.11-07/2714r0 Submission Contributors/Authors November 2007 John Doe, Some CompanySlide 2

3. doc.: IEEE 802.11-07/2714r0 Submission Outline I.Background II.Data from a 802.11n network III.Motivation IV.Issues V.Benefit/Complexity Trade-off VI.Conclusions November 2007 John Doe, Some CompanySlide 3

4. doc.: IEEE 802.11-07/2714r0 Submission November 2007 John Doe, Some CompanySlide 4 Background Digital video compression techniques reduce the amount of data by –Removing redundancy –Discarding the least perceptible aspects of the image These techniques tend to increase the likelihood of noticeable artifacts when compressed data is lost –The more you compress, the more important each bit becomes For an enjoyable and compelling user experience, transmission system for compressed video needs a low error rate –E.g 1x10 -11 BER

5. doc.: IEEE 802.11-07/2714r0 Submission November 2007 John Doe, Some CompanySlide 5 Background Video packets with a few bit errors in the payload are still usable If the video decoder can conceal errors If error correction coding has been applied It’s better than losing the whole if it cannot be retransmitted Discarding the video packet with bit errors would cause one or more retransmits (define a mechanism to inform the transmitter of this?) The decoder may not be able to use the retransmitted packet (it’s arrived too late) Retransmission may introduce unacceptable delay (video artifacts) Retransmission of the current packet may introduce additional delay in the transmission of future packets Multicast traffic A lost packet will not be retransmitted Can we pass more packets with bit errors in the video payload to layers above the MAC?

6. doc.: IEEE 802.11-07/2714r0 Submission Data from a 802.11n network To Be Filled … November 2007 John Doe, Some CompanySlide 6

7. doc.: IEEE 802.11-07/2714r0 Submission November 2007 John Doe, Some CompanySlide 7 Video – Effect of Lost Packet Effect of Packet Loss on Video A video MSDU contains 7 x 188 video octets, or 10,528 ‘video’ bits. One packet is lost, then 10,528 bits are lost. Examples: TV (PAL) 750 x 560 = 420,000 pixels, Frame rate of 30 fps TV = 12.6M Pixels/sec SDTV at 8Mbps, then 1 bit = 12.6/8 = 1.6 pixels Hence, if one packet is lost 10528 bits = 16582 pixels = 16582/750 = 22 lines LOST HD 1920 x 1080 = 2,073,600 pixels HD = 62.2M Pixels/sec HDTV at 20Mbps, 1 lost packet is a minimum of 19 lines lost Losing a minimum of 19-22 lines will definitely cause an observable video error!! Packet Loss possible because of limit on # of re-tries.

8. doc.: IEEE 802.11-07/2714r0 Submission November 2007 John Doe, Some CompanySlide 8 Video Errors Packet Loss 0.1% gives 44 Errors per minute

9. doc.: IEEE 802.11-07/2714r0 Submission Bit Errors in a Video MSDU Video MSDU: 7*188 = 10528 bits –34 octets for the MAC header (802.11b) –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 unprotected header bits are 74 * 8 = 592 bits  Probability of bit error in video payload ~95% If the bit error is in the video payload and the application can cope with the bit error, why discard the packet? November 2007 John Doe, Some CompanySlide 9

10. doc.: IEEE 802.11-07/2714r0 Submission November 2007 John Doe, Some CompanySlide 10 Concatenated Coding for Video Higher Layer Solution Basic Methodology To allow video coding, MAC changes required Might allow low packet loss over PHY c.f. zero Brian Hart’s Comment: If error on FCS, do not ACK send packet up [sounds like a layer violation? MAC reTX dependent on IP checksums?]

11. doc.: IEEE 802.11-07/2714r0 Submission November 2007 John Doe, Some CompanySlide 11 R-S Concatenated Coding Packet Loss is the concern. Improved with retries

12. doc.: IEEE 802.11-07/2714r0 Submission November 2007 John Doe, Some CompanySlide 12 RS Coding Theoretical Improvement 2.5 errors per hour cf 44 errors per minute FEC at Application Layer potentially offers significant improvement

13. doc.: IEEE 802.11-07/2714r0 Submission November 2007 John Doe, Some CompanySlide 13 FEC Coding at Application Layer Looks attractive, other technologies do it. Task is to see what changes are necessary to allow it. Headers Encryption Retry Mechanism Indication that Stream is using FEC Note: FEC in the PHY layer 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

14. doc.: IEEE 802.11-07/2714r0 Submission November 2007 John Doe, Some CompanySlide 14 FEC at Application Layer Headers –Transport Layer LLC Header, 8 Bytes, no checksum (CRC on complete frame) Need to add a checksum? UDP Header, 8 Bytes including checksum for complete frame “UDP Lite” has been proposed that has checksum on Header only –Network Layer IP Header, 20 Bytes with Header Checksum RTP Header, 12 Bytes no checksum (included in UDP checksum) Need to introduce RTP Header Checksum? Is this out-of-scope? Must be implemented.

15. doc.: IEEE 802.11-07/2714r0 Submission November 2007 John Doe, Some CompanySlide 15 FEC at Application Layer Encryption –Decryption will add more errors to the data, if errors in data –Video data could/should be encrypted at the Application Layer for DRM purposes(?) –Reasonable case to send video without encryption on 802.11 –Need to ‘flag’ the video data in order to allow this in a network that is using encryption. –Allowing different encryption for different transmissions needs to be solved.

16. doc.: IEEE 802.11-07/2714r0 Submission November 2007 John Doe, Some CompanySlide 16 FEC at Application Layer Retry Mechanism –If FCS error, no immediate ACK is sent –Transmitter sends an immediate “Retry” –If “Headers” check out, then ACK is sent to stop more Retries If a retry is received with no FCS error, then this should replace previous Otherwise proceed with first (or subsequent) and present data to Application Layer –If “Headers” do not check out, then, Dump data and look at subsequent retries

17. doc.: IEEE 802.11-07/2714r0 Submission November 2007 John Doe, Some CompanySlide 17 FEC at Application Layer Need to indicate to receiver (and AP if it is transferring the stream) that “FEC Stream” is in use –Video streams should be using EDCA Admission Control or HCCA and hence should be setting up a TSPEC. –TSPEC could be used to Request ability to send “FEC Video” Send without encryption –IE required to indicate ability of an AP or STA to support “FEC Video”

18. doc.: IEEE 802.11-07/2714r0 Submission Header FCS and Payload FCS? November 2007 John Doe, Some CompanySlide 18 Frame Control Duration/IDAdd- 1 Add- 2 Add- 3 Sequence Control Add- 4 QoS Control Frame Body MAC Header + Headers FCS Payload Start HeadersApplication Payload Payload FCS | | Octets: 2 2 6 6 6 2 6 2 0-2324 4 Potential Issues: How would intermediate nodes treat these packets? Deep packet inspection? Video Payload, Intermediate Layer Header Interleaving? Tunnelling Protocols?

19. doc.: IEEE 802.11-07/2714r0 Submission What Happens When Security is ON Bit errors in encrypted data confuses the decryption engine – decrypted data is unusable –true for all ciphers Encrypting the packet as two sub-packets – headers and payload separately – –subject to ‘cut-n-paste’ attack –This is true even if video payload is in the clear 802.11i architecture does not allow different traffic streams within the same link to be encrypted differently November 2007 John Doe, Some CompanySlide 19

20. doc.: IEEE 802.11-07/2714r0 Submission November 2007 John Doe, Some CompanySlide 20 802.11n Features How would.11n aggregation be affected by this approach? [Likely need to keep the “more reliable TC” in separate aggregates] How would.11n Block ACK be affected? [Is Block ACK your friend, so you can code across multiple packets?]

21. doc.: IEEE 802.11-07/2714r0 Submission How would this work in a 802.11s network? To be filled … November 2007 John Doe, Some CompanySlide 21

22. doc.: IEEE 802.11-07/2714r0 Submission November 2007 John Doe, Some CompanySlide 22 Effect on.11e protocol If packets with error are acknowledged, how would it affect ‘back off ‘ strategies that mitigate collision errors? –Already an issue for multicast and block-ACK –[Use block ack to your advantage?] Is there a new version of ACK that says ‘the packet was received with errors and used, so do not re-transmit’?

23. doc.: IEEE 802.11-07/2714r0 Submission November 2007 John Doe, Some CompanySlide 23 Benefit/Complexity Analysis How complex is this strategy? How well does it work? In all cases? In some cases (what percentage)? [Great questions – write a PAR so this is optional work; the determination can wait for detailed study in TG] What is the benefit? –Bounded delay, less retransmissions, reduced network load [One system that should be used as a point of comparison: –FCS on MAC header & scrambler seed (or on both MAC & PHY headers)] –Mandate the use of retries as a simple repetition code. If the PHY & MAC headers have good FCSs, store the bit LLRs. Next time a packet is received with the same good MAC header, combine the bit LLRs, store them, form hard decisions on the LLRs and test the payload FCS. If good, ACK; if not good, keep waiting for more retries. Discard the stored LLRs when all hope is lost (mechanism TBD)]

24. doc.: IEEE 802.11-07/2714r0 Submission November 2007 John Doe, Some CompanySlide 24 Other Technologies exploiting this characteristic Digital Television delivered over satellite, cable or terrestrial [vertical app over licensed band so simple error model] Professional video distribution systems [vertical app over licensed band? so simple error model] Some IPTV systems Cellular? [vertical app over licensed band so simple error model] [802.11 is unlicensed & collisions are routine. 802.11 exists in the flexible 802 arch inside a layered system. There may be multiple unreliable links in a a row. Be careful of over-simplifying the comparison]

25. doc.: IEEE 802.11-07/2714r0 Submission Conclusions November 2007 John Doe, Some CompanySlide 25

26. doc.: IEEE 802.11-07/2714r0 Submission Straw Poll This technique is useful, addresses all concerns and should be included in the VTS SG PAR This technique is useful, but has a lot of open issues that need to be fully understood. VTS SG needs to study this further and bring a more complete proposal This technique is not useful and needs to be removed from the VTS SG PAR November 2007 John Doe, Some CompanySlide 26

27. doc.: IEEE 802.11-07/2714r0 Submission FEC Techniques November 2007 John Doe, Some CompanySlide 27

28. doc.: IEEE 802.11-07/2714r0 Submission November 2007 John Doe, Some CompanySlide 28 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.

29. doc.: IEEE 802.11-07/2714r0 Submission November 2007 John Doe, Some CompanySlide 29 Packet-based FEC 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.

30. doc.: IEEE 802.11-07/2714r0 Submission November 2007 John Doe, Some CompanySlide 30 Relevant prior work RTP: Transport protocol for real-time applications: IETF RFC 1889 –Source identification –Packet loss detection –Inter-media synchronization –Intra-media synchronization RTCP: RTP plus periodic retransmission of control packets IETF RFC 2733: An RTP Payload Format for Generic Forward Error Correction

31. doc.: IEEE 802.11-07/2714r0 Submission November 2007 John Doe, Some CompanySlide 31 Priority Encoding Transmission Specify different priorities for different data segments According to assigned priority use different FEC Early detection of packet loss is the key