May 2001 doc IEEE 802 11 01278 r

  • Slides: 12
Download presentation
May 2001 doc. : IEEE 802. 11 -01/278 r 0 Protocol Stack Options for

May 2001 doc. : IEEE 802. 11 -01/278 r 0 Protocol Stack Options for AV over 11 e Toru Ueda Sharp Corp. ueda@slab. tnr. sharp. co. jp Submission 1 Toru Ueda, Sharp Corp.

May 2001 doc. : IEEE 802. 11 -01/278 r 0 Issues for AV transmission

May 2001 doc. : IEEE 802. 11 -01/278 r 0 Issues for AV transmission • Current draft is a collection of optional functions. – Parameterized Qo. S/Prioritized Qo. S – FEC/No FEC – Delayed ACK/One way – …. • A set of options should be defined as a recommended practice and AV application should follow this for interoperability. Submission 2 Toru Ueda, Sharp Corp.

May 2001 doc. : IEEE 802. 11 -01/278 r 0 More issues • AV

May 2001 doc. : IEEE 802. 11 -01/278 r 0 More issues • AV over 11 e may, for best user acceptance, require a new SAP. – AV over 11 e may not be best served with an IP protocol stack. • How to exchange frames with IEEE 1394 should be discussed. Submission 3 Toru Ueda, Sharp Corp.

May 2001 doc. : IEEE 802. 11 -01/278 r 0 Discussion items in current

May 2001 doc. : IEEE 802. 11 -01/278 r 0 Discussion items in current Spec(Example) The following items should be discussed / defined to support AV Stream application over 802. 11 ( Item 1 ) Protocol stack for AV Stream application ( Item 2 ) Interface from/to IEEE 1394 or AV Stream ( Item 3 ) Mechanism to realize robust/effective AV Stream transmission ( Item 4 ) Mechanism to support multicast AV Stream ( Item 5 ) Reasonable implementation guideline for AV Stream application ( Item 6 ) Relationship of HC and AP: Can we have an HC without an AP? Submission 4 Toru Ueda, Sharp Corp.

May 2001 doc. : IEEE 802. 11 -01/278 r 0 ( Item 1 )

May 2001 doc. : IEEE 802. 11 -01/278 r 0 ( Item 1 ) Protocol stack for AV Stream application Candidates for protocol stack / Interface to identify AV application 1 2 TCP IP TCP AV Stream Application IP IEEE 802. 2 LLC IEEE 802. 11 MAC IEEE 802. 11 PHY - Use same LLC SAP - ID is needed in LLC level Submission AV Stream Application - Use special MAC SAP - ID is needed in MAC level 5 Toru Ueda, Sharp Corp.

May 2001 doc. : IEEE 802. 11 -01/278 r 0 ( Item 2 )

May 2001 doc. : IEEE 802. 11 -01/278 r 0 ( Item 2 ) Interface from/to IEEE 1394 or AV Stream Candidate Interface specification between AV Transport Layer / IEEE 802. 11 MAC Layer 1 2 3 Transport Layer IEC 61883 IEEE 1394 LINK Layer IEEE 1394 PHY Layer 1394 over 802. 11 IEEE 802. 11 MAC Layer IEEE 802. 11 PHY Layer - Not all AV devices will need/require 1394 topology management functions. Submission Transport Layer IEC 61883 Transform IEEE 1394 LINK Layer IEEE 802. 11 MAC Layer IEEE 1394 PHY Layer IEEE 802. 11 PHY Layer - Use Same CIP Header as 1394 6 - Use new header ? Toru Ueda, Sharp Corp.

May 2001 doc. : IEEE 802. 11 -01/278 r 0 ( Item 3 )

May 2001 doc. : IEEE 802. 11 -01/278 r 0 ( Item 3 ) Mechanism to realize robust/effective AV Stream transmission The following mechanisms should be studied and compared in performance (1) Without RS code (use only CRC check and retry) (2) With RS code, without retransmission (3) With RS code, with packet-based retransmission (4) With RS code, with RS block-based retransmission Bandwidth is limited. Transmission technologies that maximize channel efficiency, and maintain small latency and jitter, even if some complexity is added should be considered. Submission 7 Toru Ueda, Sharp Corp.

May 2001 doc. : IEEE 802. 11 -01/278 r 0 Performance Comparison RS Block

May 2001 doc. : IEEE 802. 11 -01/278 r 0 Performance Comparison RS Block loss Rate (1) Without RS code (2) With RS code, no retransmission (4) With RS code, RS block-base retransmission (3) With RS code, packet-base retransmission Bit Error Rate Submission 8 Toru Ueda, Sharp Corp.

May 2001 doc. : IEEE 802. 11 -01/278 r 0 ( Item 4 )

May 2001 doc. : IEEE 802. 11 -01/278 r 0 ( Item 4 ) Mechanism to support multicast AV Stream WSTA EAP ( HC ) WSTA What kind of mechanisms are required/defined to realize multicast AV Stream ? Submission 9 Toru Ueda, Sharp Corp.

May 2001 doc. : IEEE 802. 11 -01/278 r 0 ( Item 5 )

May 2001 doc. : IEEE 802. 11 -01/278 r 0 ( Item 5 ) Reasonable implementation guideline for AV Stream application - How many burst length is required typically within how long cycle period ? - How many retransmission chances are required ? - How large should be the buffer size ? ( What amount should be the delay time? ) for each AV application ( HDTV, SDTV, DVC … ) - Can HC successfully continue to schedule TXOP without any interruption from other stations ? Can performance “gracefully degrade” with load, interference? ( MAX. 10 RS Blocks ) S S S P R C S Qo. S #1 S Qo. S #2 DIFS Qo. S #N S LAN DIFS A DIFS D A Burst length ( N ) cycle period Submission 10 Toru Ueda, Sharp Corp.

May 2001 doc. : IEEE 802. 11 -01/278 r 0 ( Item 6 )

May 2001 doc. : IEEE 802. 11 -01/278 r 0 ( Item 6 ) Relationship of HC and AP Can HC exist in IBSS? Can only one HC be selected from multiple HCs environment ? If HC disappears during ESTA to ESTA Qo. S transmission, what should we do? IBSS HC ( not AP ) STA Submission 11 Toru Ueda, Sharp Corp.

May 2001 doc. : IEEE 802. 11 -01/278 r 0 Conclusion • Even when

May 2001 doc. : IEEE 802. 11 -01/278 r 0 Conclusion • Even when 11 e is fixed, we need to select options and define a set of protocol stack services and features for AV transmission. • To do this, we need to consider the current 11 e draft from AV application point of view and – drive the standard to feasibly support this market – develop the recommended practice. Submission 12 Toru Ueda, Sharp Corp.