Re: [STDS-802-11-TGAC] IEEE 802.11ac telecon
> -----Original Message-----
> From: *** 802.11 TGac - VHT below 6GHz*** [mailto:STDS-802-11-
> TGAC@xxxxxxxx] On Behalf Of Mark Rison
> Sent: Friday, August 31, 2012 4:02 AM
> To: STDS-802-11-TGAC@xxxxxxxxxxxxxxxxx
> Subject: 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
[MFischer]
It is the sort of note for which the commenter is asking: i.e. it clarifies just exactly how the MU PPDU exchange is supposed to work. The first question that most reader have when seeing the MU PPDU is - how do you keep the responders from colliding with each other? And the text above provides an explicit answer to that, rather than the inferred one that is the result of a dozen sleepless nights reading and re-reading all parts of the spec and then assembling the different parts in different orders in your head to finally connect the dots and come to the conclusion that is presented in the sentences above.
> - I still think "STA transmitting the MU PPDU" should be "AP"
[MFischer]
I do not know of any place in the spec that restricts MU PPDU transmission to an AP (even though I believe that most people believe that such a restriction exists)
And for the typical case, an AP is a STA, so there is nothing technically incorrect here
Maybe the group wants such a restriction and maybe it is there and I just cannot find it.
> - 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"
[MFischer]
Basically, nearly any sequence of frames is allowed and a STA could transmit an MU PPDU followed by BAR or followed by some non-MU PPDUs. A STA could transmit an MU PPDU and immediately follow it with BAR frames to unrelated STAs or for unrelated BA agreements, even if the MU PPDU contained no frames for acking.
A very large number of sequences is allowed and possible.
Thinking of it this way, maybe that sentence should simply be removed.
> - What's the "+mu-ppdu" attribute?
[MFischer]
It is a new attribute that is modeled on the +a-mpdu attribute
See annex G, compare to +a-mpdu
> - 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)?
[MFischer]
It is very difficult to figure out just exactly what the allowable frame exchange sequences are from reading annex G, even though it is written with a "rigid" logical syntax - during the conference call, Simone Merlin suggested that rather than create a new exchange which again, seems too limited in its choices of what can really be done within a TXOP, what should really be allowed in the case of MU PPDU is that anywhere in Annex G that a "data-bearing or management bearing frame" exists in the entire set of allowable frame exchanges, the option for inserting +mu-ppdu should be added and I think that he is correct.
And it seems that if annex G has been correctly created, then somewhere in annex G, there should be ONE place that describes that fundamental thing embedded in a fundamental sequence that is a TXOP, with phrasing that logically says that anything that is a "blah-unit" can appear here, where "here" is that fundamental TXOP exchange to which can be added other things optional in front, such as preceding RTS/CTS or CTS2SELF, etc. and optional things behind, such as BAR+BA, ACK, more MPDUs, etc. and I think that txop-part-requiring-ack is pretty close to being the "blah-unit" and the cited exchange looks pretty close to being that fundamental txop exchange but maybe I've not read it correctly.
There should be a similar "blah-unit" for the no-ack case but I cannot find it. Once both of those are found, then they can be modified to allow +mu+ppdu, and then any fancy combination of frames that makes a single TXOP will allow the insertion of an MU PPDU and I hope that no other places would need the addition of +mu-ppdu.
But the more I look at annex G, the more I think it is a heaping plate of indigestible spaghetti and as anyone else tries to join the search and repair mission, I think that they will agree with my opinion and the more that annex G is examined in an open forum, the more likely someone is to stand up and move to make the entire annex informative again. I believe that everyone just allowed someone to write that text because they volunteered to do it and no one really looked at it too hard when it was done and I believe that it is probably missing a lot of things and duplicating a lot of things and I believe that no one really cares and I know that I do not really care, but I spent my personally created and imposed and policed two hour limit of honest effort looking into it and so I will not spend any more time on annex G, other than to present the couple of choices that I have created in the F2F in September, even though I believe that none of my choices is convincingly correc!
t in my mind and if anyone else wants to try to figure it out, they are welcomed to do so - I gave it a shot.
As for allowable frame exchanges, I just figure that as long as a STA keeps using SIFS and the same AC, then it can continue to send DATA and control frames and management frames up to the limit of TXOPLimit and everything should be fine - and it can use PIFS too in the case of recovery - i.e. in my heart, I know which frame exchanges are right, because they feel right, morally.
Annex G is to me, an apocryphal addendum to the otherwise 802.11 holy writings and somewhere in a desert there must be a small radical gathering of adherents to a sect of the 802.11 religion of which I am not a member who believe that annex G is a part of the true writings of 802.11. At this point, I would prefer to let them reconcile their ancient document with the latest 802.11 advances.
> - 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?
[MFischer]
On the call, Liwen mentioned that somehow, somewhere, there had been discussion and agreement and maybe even that draft text was written and exists somewhere that allows the sending of multiple RTS-CTS exchanges preceding an MU PPDU transmission and this should also appear in annex G. I think that he is right but I cannot cite any text.
> - "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)
[MFischer]
See 8.6.3, the new 11ac Table 8-288-A-MPDU contents in the VHT single MPDU context and then go look up the rules on acknowledgement for VHT single MPDU.
>
> 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/ethic
> s/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