Re: [STDS-802-11-TGAC] IEEE 802.11ac telecon
Some comments on 1021r5:
- I basically like it
- I still don't see the point of "there is no more than one immediate
response required for an A-MPDU, and further indicate" and think it
should be deleted
- I still think "STA transmitting the MU PPDU" should be "AP"
- I still think the "No BlockAckRequest frame should be sent to a STA
in the case where the A-MPDU to that STA contained no MPDUs requiring
acknowledgement." needs a NOTE to explain why it's a "should" and not
a "shall"
- What's the "+mu-ppdu" attribute?
- Why is txop-part-requiring-ack being modified rather than
ht-txop-sequence or one of its children (or even adding a
vht-txop-sequence)?
- The addition of the [1{}] in "[1{RTS CTS}]" appears to be something
new and not something required for resolution of this comment per se.
What is the justification for this change?
- "An ACK frame can be sent in response to an MPDU within an MU PPDU
if the ack policy requires it." I realise I supported this previously,
but when can this happen, in fact? I can see nothing in Table 8-284
"A-MPDU contents in the data enabled immediate response context"
which could result in such an outcome (all the possible MPDUs in
such an A-MPDU either need no immediate acknowledgement or need a
BlockAck as immediate acknowledgement)
Mark
--
Mark RISON, Systems Architect, Wi-Fi English/Esperanto/Francais
CSR, Cambridge Business Park Tel: +44 1223 692000
Cowley Road, Cambridge CB4 0WZ Fax: +44 1223 692001
ROYAUME UNI WWW: http://www.csr.com
> -----Original Message-----
> From: *** 802.11 TGac - VHT below 6GHz*** [mailto:STDS-802-11-TGAC@xxxxxxxx] On Behalf Of Merlin,
> Simone
> Sent: 31 August 2012 00:19
> To: STDS-802-11-TGAC@xxxxxxxxxxxxxxxxx
> Subject: Re: [STDS-802-11-TGAC] IEEE 802.11ac telecon
>
> Hi Matt,
>
> My opinion is that there is no need to add so much new text/figure to describe the MU BA procedure. In
> fact the text you propose is essentially reiterating on mechanisms described somewhere else, so it is
> not adding much new information.
>
> The figure referred by the comment was there to illustrate the TXOP sharing concept, not the BA
> procedure; why not remove the BAs from that figure instead?
>
> Regarding the text you propose:
>
> These two paragraphs could be OK as a clarification note placed somewhere
>
> "The acknowledgement procedure performed by a STA that receives MPDUs that were transmitted
> within an MU PPDU is the same as the acknowledgement procedure for MPDUs that were not
> transmitted within an MU PPDU.
> NOTE - All MPDUs transmitted within an MU PPDU are contained within A-MPDUs and the rules
> specified in 8.6.3 (A-MPDU contents) ensure that there is no more than one immediate response
> required for an A-MPDU, and further indicate that there can only be one immediate response to an MU
> PPDU."
>
>
> But this one does not tell much, and may generate further comments (e.g. the ones from Mark, below...)
>
> "Responses to A-MPDUs within an MU PPDU that are not immediate responses to the MU PPDU are
> transmitted in response to explicit BlockAckRequest frames by the STA transmitting the MU PPDU.
> --> no new info. how else could it happen? Also, does response indicate immediate response?
> What about delayed BA?
>
> "An MU PPDU frame exchange sequence is shown in Figure 9-9a (The MU PPDU acknowledgement
> procedure)"
> --> I foresee additional comments regarding this figure in later drafts
>
> Recovery within the TXOP can be performed according to the rules of 9.19.2.4 (Multiple
> frame transmission in an EDCA TXOP). BlockAckRequest frames can be transmitted in a TXOP separate from
> the one that contained the MU PPDU.
> --> no new info
>
> Simone
>
> -----Original Message-----
> From: *** 802.11 TGac - VHT below 6GHz*** [mailto:STDS-802-11-TGAC@xxxxxxxx] On Behalf Of Mark Rison
> Sent: Wednesday, August 29, 2012 10:27 AM
> To: STDS-802-11-TGAC@xxxxxxxxxxxxxxxxx
> Subject: Re: [STDS-802-11-TGAC] IEEE 802.11ac telecon
>
> I will not be able to attend, but assuming 1021r3 will be presented, I have the following comments
> thereon:
>
> - I think "ensure that there is no more than one immediate response
> required for an A-MPDU" in the first NOTE is a statement of the
> blindingly obvious, and should be deleted. I also think "indicate"
> should be changed to "ensure". The NOTE should read simply "NOTE---
> All MPDUs transmitted within an MU PPDU are contained within A-MPDUs
> and the rules specified in 8.6.3 (A-MPDU contents) ensure that there
> can only be one immediate response to an MU PPDU."
>
> - The figure should show BA/ACK rather than just BA in the green boxes
> (for the reasons given in NOTE 1). The last of the three figures
> shown (page 5) is correct.
>
> - The NOTE 1 should just be a NOTE (since there's only one of them).
>
> - "BAR frames" should be "BlockAckReq frames" (twice).
>
> - "STA transmitting the MU PPDU" should be changed to "AP" (to match
> the figure).
>
> - "HT-delayed BlockAck" should be "HT-delayed Block Ack" (it's not the
> frame, it's the behaviour).
>
> - I think the baseline mostly calls for a "frame" after "A BlockAck or
> an ACK" and "No BlockAckRequest".
>
> - The case where none of the A-MPDUs in the MU PPDU requires immediate
> acknowledgement is not covered. What happens in this case? Does a
> BAR follow the MU PPDU after SIFS?
>
> - I'm guessing the "should" in the "No BlockAckRequest should be sent
> to a STA in the case where the A-MPDU to that STA contained no MPDUs
> requiring acknowledgement." is to cover the case where although the
> A-MPDU did not have any MPDUs requiring ack, the AP wants to get a
> BA for some MPDUs sent earlier which do require ack. But this is
> not clear and should be spelt out (perhaps another NOTE?).
>
> Mark, who hadn't realised MU ack was such a can of worms!
>
> --
> Mark RISON, Systems Architect, Wi-Fi English/Esperanto/Francais
> CSR, Cambridge Business Park Tel: +44 1223 692000
> Cowley Road, Cambridge CB4 0WZ Fax: +44 1223 692001
> ROYAUME UNI WWW: http://www.csr.com
>
> > -----Original Message-----
> > From: *** 802.11 TGac - VHT below 6GHz***
> > [mailto:STDS-802-11-TGAC@xxxxxxxx] On Behalf Of Osama AboulMagd
> > Sent: 28 August 2012 13:04
> > To: STDS-802-11-TGAC@xxxxxxxxxxxxxxxxx
> > Subject: Re: [STDS-802-11-TGAC] IEEE 802.11ac telecon
> >
> > Hello All,
> >
> > There is a TGac conference call scheduled for Thursday, August 30 at
> > 20:00 ET. Please let me know if you plan a presentation.
> >
> > Dial in information is available below.
> >
> > The latest revision of LB188 Comment spread sheet is available at:
> > https://mentor.ieee.org/802.11/dcn/12/11-12-0752-08-00ac-lb188-comment
> > s-tgac-d3-0.xls
> > <https://mentor.ieee.org/802.11/dcn/12/11-12-0752-08-00ac-lb188-commen
> > ts-tgac-d3-0.xls>
> >
> > Teleconferences are bound by the conditions stipulated by the
> > documentation below. Please review them and bring up any questions/concerns you may have before
> proceeding with the teleconference.
> >
> >
> > *
> > http://standards.ieee.org/resources/anthttp://www.ieee.org/web/members
> > hip/ethics/code_ethics.html
> > <http://standards.ieee.org/resources/anthttp://www.ieee.org/web/membership/ethics/code_ethics.html>
> > * http://standards.ieee.org/faqs/affiliationFAQ.htmlitrust-guidelines.pdf
> > <http://standards.ieee.org/faqs/affiliationFAQ.htmlitrust-guidelines.pdf>
> > * http://standards.ieee.org/board/pat/loa.pdf <http://standards.ieee.org/board/pat/loa.pdf>
> > * http://standards.ieee.org/board/pat/index.html
> <http://standards.ieee.org/board/pat/index.html>
> > * http://standards.ieee.org/board/pat/pat-slideset.ppt
> <http://standards.ieee.org/board/pat/pat-
> > slideset.ppt>
> > * http://standards.ieee.org/board/pat/faq.pdf <http://standards.ieee.org/board/pat/faq.pdf>
> > * http://www.ieee802.org/policies-and-procedures.pdf <http://www.ieee802.org/policies-and-
> > procedures.pdf>
> > * http://www.ieee802.org/PNP/2008-11/LMSC_OM_approved_081114.pdf
> > <http://www.ieee802.org/PNP/2008-11/LMSC_OM_approved_081114.pdf>
> >
> >
> > Regards;
> > Osama.
> >
> >
> >
> > -----Original Appointment-----
> > From: Brian Hart (brianh) [mailto:brianh@xxxxxxxxx]
> > Sent: Monday, July 23, 2012 12:15 PM
> > To: Brian Hart (brianh); Reza Hedayat (rehedaya); Perahia, Eldad;
> > Osama AboulMagd; Stephens, Adrian P
> > Cc: Luoyi (Roy); auyehara@xxxxxxxxxxx; Daniel Camps Mur;
> > mesem@xxxxxxxxxxxx
> > Subject: IEEE 802.11ac telecon
> > When: Thursday, August 30, 2012 8:00 PM-10:00 PM (UTC-05:00) Eastern Time (US & Canada).
> > Where: Webex
> >
> >
> >
> > Approved times
> > 10:00 - 12:00 ET: July 26, August 9, August 23, Sept 6, Sept 27, Oct 11
> > 20:00 - 22:00 ET: August 2, August 16, August 30, Sept 13, Oct. 4
> >
> > Cautions
> >
> > * Help: http://www.webex.com/lp/keyfeatures/index.php
> > <http://www.webex.com/lp/keyfeatures/index.php>
> > * [Recommended] To join the teleconference and see shared documents, click on the first link below
> > ("To start this meeting"), go through the various screens until your
> > inside Webex, then Webex will prompt you so it can call your phone
> > * [If in the car, etc] Otherwise, to join the teleconference only
> > * You must dial (408) 525-6800 when calling from a US 408 number (the 866 number is blocked)
> > * You must dial (919) 392-3330 when calling from a US 919 number (the 866 number is blocked)
> > * Otherwise dial (866) 432-9903 from the USA or see the second link below for dial-in numbers for
> > other locations
> > * The meeting number is 204 708 684 #
> > * To mute, use *6 (and also to unmute) or right click on your name in the Participants window and
> > hit Mute
> > * Please use these methods preferentially since your local mute mechanism may introduce echo
> > * If you have an incoming call, don't answer it! (Everyone else hears on-hold music)
> > * To share a document, I'll hand you the ball in the "Participants" window, you'll see "You are
> > now the Presenter" on your screen, then in the menu hit "Share |
> > Application | select your open document window". You can share multiple windows at once.
> >
> >
> >
> >
> > Brian Hart invites you to an online meeting using WebEx.
> >
> > Meeting Number: 204 708 684
> > Meeting Password: 11ac
> >
> > -------------------------------------------------------
> > To join this meeting (Now from mobile devices!)
> > -------------------------------------------------------
> > 1. Go to
> > https://cisco.webex.com/cisco/j.php?J=204708684&PW=NNDI3MmY2Nzg4
> > <https://cisco.webex.com/cisco/j.php?J=204708684&PW=NNDI3MmY2Nzg4>
> > 2. Enter the meeting password: 11ac
> > 3. Click "Join Now".
> > 4. Follow the instructions that appear on your screen.
> >
> >
> > ----------------------------------------------------------------
> > ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes
> > ----------------------------------------------------------------
> >
> > The affected toll free numbers are: (866) 432-9903 for the San
> > Jose/Milpitas area and (866) 349-3520 for the RTP area.
> >
> > Please dial the local access number for your area from the list below:
> > - San Jose/Milpitas (408) area: 525-6800
> > - RTP (919) area: 392-3330
> >
> > -------------------------------------------------------
> > To join the teleconference only
> > -------------------------------------------------------
> > 1. Dial into Cisco WebEx (view all Global Access Numbers at
> > http://cisco.com/en/US/about/doing_business/conferencing/index.html
> > <http://cisco.com/en/US/about/doing_business/conferencing/index.html>
> > 2. Follow the prompts to enter the Meeting Number (listed above) or Access Code followed by the #
> sign.
> >
> > San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330
> >
> > US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117
> >
> > India: +91.80.4350.1111 Germany: +49.619.6773.9002
> >
> > Japan: +81.3.5763.9394 China: +86.10.8515.5666
> >
> > http://www.webex.com <http://www.webex.com>
> >
> > CCP:+14085256800x204708684#
> >
> > IMPORTANT NOTICE: This WebEx service includes a feature that allows
> > audio and any documents and other materials exchanged or viewed during
> > the session to be recorded. By joining this session, you automatically
> > consent to such recordings. If you do not consent to the recording,
> > discuss your concerns with the meeting host prior to the start of the recording or do not join the
> session. Please note that any such recordings may be subject to discovery in the event of litigation.
> >
> >
> >
> >
> > To report this email as spam click here
> > <https://www.mailcontrol.com/sr/wQw0zmjPoHdJTZGyOCrrhg==
> > 7EAwh6aunJTqVygQ==> .
>
>
>
> Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number
> 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ,
> United Kingdom More information can be found at www.csr.com. Follow CSR on Twitter at
> http://twitter.com/CSR_PLC and read our blog at www.csr.com/blog