Re: [STDS-802-11-TGAC] IEEE 802.11ac telecon
> > - 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
> 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,
No, no, no. The text above provides an answer to the question
"How do you keep an *A-MPDU* responder from sending more than one
immediate response?" which no-one has asked nor is likely to,
since it's not new to 11ac. The next bit of text, namely "[ensure]
that there can only be one immediate response to an MU PPDU"
provides an answer to the question which people have asked,
namely "How do you keep *MU PPDU* responders from sending more
than one immediate response?".
> > - I still think "STA transmitting the MU PPDU" should be "AP"
> 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)
How about 3.1:
downlink multi-user multiple input, multiple output (DL-MU-MIMO): A technique by which an access
point (AP) with more than one antenna simultaneously transmits a physical layer convergence procedure
(PLCP) protocol data unit (PPDU) to multiple receiving non-AP stations (STAs) over the same radio frequencies.
NOTE-802.11 supports only downlink (DL) MU-MIMO. See DL-MU-MIMO.
[Hm, I'm sure I had a comment saying the note was wrong, in that
802.11 also supports fragmentation and aggregation, for example.
But I can't find it now. One for D4.0, I guess.]
> And for the typical case, an AP is a STA, so there is nothing
> technically incorrect here
Actually, an AP is always a STA, in IEEE 802.11, except when it
"contains" a STA, of course (one for TGmc). The Figure shows
an AP, not a STA (that's the change you made in r1).
> > - 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"
> 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.
Good, so let's have all this as a NOTE (except the bit about "to
unrelated STAs", since this is specifically about the case where
an A-MPDU to a given STA does not require immediate ack).
> A very large number of sequences is allowed and possible.
> Thinking of it this way, maybe that sentence should simply be removed.
I think it's important to point out that you might not get exactly one
BAR per non-AP STA minus one.
> > - What's the "+mu-ppdu" attribute?
> It is a new attribute that is modeled on the +a-mpdu attribute
> See annex G, compare to +a-mpdu
Can't see this in either D3.1 or your doc.
> > - 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)?
> 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.
I share your pain, but, if we're not going to make sure Annex G
is fixed for 11ac, we need to add something like:
This annex is obsolete as regards VHT. Consequently this annex may be removed in a future revision of this standard. This
clause is no longer maintained and may not be compatible with or describe all features of this standard.
> > - 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?
> 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.
Well, if he is right, I think this important change should be addressed
explicitly via a relevant comment resolution, not buried in a comment
resolution about a different topic (MU PPDU acknowledgement).
> > - "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)
> 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.
Duh, of course! I retract my retraction, and instead suggest the wording
be modified to:
An ACK frame can be sent in response to an MU PPDU
in the case where it contains a 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 Matthew Fischer
> Sent: 31 August 2012 18:50
> To: STDS-802-11-TGAC@xxxxxxxxxxxxxxxxx
> Subject: 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/we
> b/membership/ethic
> > s/code_ethics.html>
> > > > *
> http://standards.ieee.org/faqs/affiliationFAQ.htmlitrust-guide
> lines.pdf
> > > >
> <http://standards.ieee.org/faqs/affiliationFAQ.htmlitrust-guid
> elines.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
>