Re: [802.15_GENERAL] TGn Letter Ballot Support
Title: Re: [802.15_GENERAL] TGn Letter Ballot Support
Matthew,
Thanks for the explanation. I was wondering what would trigger prevention of 40 MHz in entire 2.4 GHz band. Only devices that conform to new 802.11n standard will be able to prevent use of 40 MHz channels in entire 2.4 GHz band. Will 802.11n systems detect 40 MHz Intolerant bit included in a properly formatted beacon including the 20/40 coexistence element from a legacy (e.g., 802.11g) device? This isn’t good coexistence strategy, but at least it gives some relief to devices that need to protect the spectrum from a channel hog.
Regards, John
On 5/27/08 5:25 PM, "Matthew Fischer" <mfischer@BROADCOM.COM> wrote:
Ben
There are two items that are getting intertwined here:
1) legacy system coexistence
2) 802.15 system coexistence
The email that you are responding to was adressing the second item.
But your statements are addressing the first item.
Regarding item 1)
Legacy systems do NOT have to make any changes in order to prevent a TGn system from sending 40 MHz transmissions. The protection that is afforded by the mere presence of the legacy system applies to any of the channels that is overlapped by the 40 MHz "channel."
Regarding item 2)
Use of the new 40 MHz Intolerant bit in the new element will prevent ALL use of 40 MHz transmissions within the ENTIRE 2.4 GHz band.
That is really the only difference between the two cases.
Matthew Fischer
Nice Guy
408 543 3370 office
650 796 9206 mobile
mfischer@broadcom.com
From: Benjamin A. Rolfe [mailto:ben@blindcreek.com]
Sent: Tuesday, May 27, 2008 3:00 PM
To: Matthew Fischer; STDS-802-WPAN@LISTSERV.IEEE.ORG
Subject: Re: [802.15_GENERAL] TGn Letter Ballot Support
Oh boy, where do I start...I suppose by getting out the BIG spoon to stir the pot...
I've gone from confused to really confused. As I read the draft (11.14.11 and 11.14.12), there is a means to detect a device which is not capable of any of this by examining it's capabilities IE (TE-A). Perhaps I misread that, thinking what I did because, well, it made a lot of sense. As I read the draft I wasn't sure because the broken cross reference pointing at where the procedure for "re-evaluation" is defined. This would be a suitable mechanism for both coexisting with other 802.11 networks and enabling interoperability with those networks. Just makes sense.
Your explanation below leads me to believe I was wrong, and not in a good way (I am often wrong in good ways ;0). There is a fundamental problem with depending on legacy devices to do something new in order to signal that they are legacy devices, and that sounds like what you are explaining. For an already deployed device we can not count on being able to update it in any way. That would be true for many of the millions of 802.11 products in the field today. So counting on them transmitting an IE defined in 802.11n is just not going to work. That little voice in my head (the good one) says we've gone astray in this discussion and I'm not understanding your point. A lot of incumbent users in 2.4 are 802.11b and g and so I can't believe the 802.11 WG would have been OK with something harmful to those legacy b and g devices. I'm sure I am misunderstanding your explanation, and as daft as I can be, I'm equally sure I'm not the only one. All that leads me from concerned to really concerned.
All of this goes a bit sideways of the original point raised, which was concern that 802.11n was harmful to other existing systems in 2.4GHz. Your response definitely gives the impression your saying "not my problem". That would push some people "really concerned" to, well, someplace not at all good. Again, I'm thinking that was not what you meant.
Coexistence with existing spectrum users is no longer something we can ignore in any 802 context. We have mechanisms most standards to look for non-cooperating systems in our spectrum and work around them. I dimly recall similar mechanisms in 802.11. Some of the requirements are driven by regulators (protecting those incumbents) and are quite onerous to implement. There is precious little spectrum below 10GHz (and rising) where coexistence is not a critical consideration. Incumbents include all the stuff we can talk to and all the stuff we can't (whomever "we" happen to be today).
There are three things that can happen if we have a coexistence disaster, and only one can end well:
a) 802 groups can jump up and say "Whoa Nelly" and we have the kind of discussions we're having now and find solid solutions;
b) we toss out a standard that which if built two causes huge problems and people stop using it and/or
c) regulators see a problem (real or perceived, doesn't matter) make new rules that make the standard less useful (and usually cause lots of other problems).
The logical consequence of (b) is consumers don't buy the cool new stuff, which would be bad. The consequence of (c) is most likely power restrictions you can't live with (how well will your OFDM work at a -41.3dBm?), which would be even worse. The consequence of (a) is we thrash it about until we all understand it and figure out how to make it all work. I vote for (a) then.
To that end, I have to believe that there are analysis, simulation, and empirical results that have been done which can help in the coexistence analysis. I'd like to see some real data, if possible. I'm sure a lot of this has been considered already, so capture that in a coexistence document (or point us at the one already done). There is an established method which is a great starting point. If we have 802 members still not comfortable (as we have had in past 802.15 standards), we go as far as need be to show why their concerns can be mitigated. If we can't address a legitimate concern (and a situation that looks like "no one can operate but me" is a legitimate concern), then we don't have a workable standard (see (b) and (c) above). Perhaps someone can speak up and tell us why we shouldn't even worry about this, 802.11n is going to be nice and friendly?
Just a few thoughts....
-Ben
================================
Benjamin A. Rolfe
408.395.7207 Office
408.332.0725 Mobile
Skype: benjamin.rolfe
==============================================================================
The views expressed in this email reflect only those of the author and are not representative of the official
position of any other entity. Read at your own risk.
==============================================================================
----- Original Message -----
From: Matthew Fischer <mailto:mfischer@BROADCOM.COM>
To: STDS-802-WPAN@LISTSERV.IEEE.ORG
Sent: Tuesday, May 27, 2008 12:22 PM
Subject: Re: [802.15_GENERAL] TGn Letter Ballot Support
John,
If the lack of ability of one technology deployed in the 2.4 GHz band to directly communicate with a different technology also deployed in the 2.4 GHz band is a definition of a broken standard, then TGn is not the only broken standard.
It is clear that an 802.15 device cannot transmit an 802.11 frame, just as an 802.11 device cannot transmit an 802.15 frame. Each of these devices must do what it can on its own to share spectrum. 802.15 includes the concept of AFS as a means to attempt to better coexist with 802.11 devices. AFS relies on the ability of an 802.15 device to make its own determination as to when to restrict its spectrum usage. 802.11 devices cannot send a message to the 802.15 requesting them to use AFS.
Similarly, 802.11 TGn devices are being provided with a mechanism that they can employ to facilitate spectrum sharing. The 802.11 mechanism allows any device that is capable of transmitting an 802.11 formatted and modulated frame to specifically prohibit the use of 40 MHz transmissions. Many 802.15 devices are being shipped to today with a co-located 802.11 device, and the expectation is that many more such products will be shipped in the future. Such devices can easily be programmed to prohibit all 40 MHz transmissions within range of the 802.11 transceiver. Other 802.11-transceiver-equipped devices that are aware of non-co-located 802.15 devices can also send such a frame.
The information that you received from an Atheros person regarding the ability of a current 802.11 device to signal to TGn devices to NOT use 40 MHz is INCORRECT. A legacy device can include the new 20/40 BSS Coexistence element in Beacons and/or Probe Request and Probe Response frames. It is this new element that contains the 40 MHz Intolerant bit. There is no restriction as to which options need to be implemented in determining if a STA or AP may send this element. Existing devices are allowed to send this element and certainly, to set the 40 MHz Intolerant bit to prohibit 40 MHz transmissions. See the changes in the TGn draft to the Beacon and other frame formats. Here is an example:
7.2.3.1 Beacon frame format
Table 7-8
20/40 BSS Coexistence The 20/40 BSS Coexistence element may appear in this frame.
Note that lack of qualifiers regarding the inclusion of the element in this frame.
There is also a management action frame that can be used to send this information.
It can be broadcast and it can be sent with a specific unicast MAC address to allow for explicit acknowledgement of receipt. It can be sent from a device that is not a member of the BSS and still must be obeyed.
Matthew Fischer
Nice Guy
408 543 3370 office
650 796 9206 mobile
mfischer@broadcom.com
From: John Barr [mailto:john.barr@MOTOROLA.COM]
Sent: Tuesday, May 27, 2008 6:22 AM
To: STDS-802-WPAN@LISTSERV.IEEE.ORG
Subject: Re: [802.15_GENERAL] TGn Letter Ballot Support
Matthew,
Thanks for your opinion.
Can you explain exactly how an 802.15 device can “signal the 40 MHz TGn devices”? I have gone through the current draft and don’t really see where this is clearly defined. I also asked someone from Atheros about how a current 802.11 device can signal the 40 MHz TGn devices and his response was that they can’t but 40 MHz devices who see non-TGn beacons should note this and prevent use of 40 MHz channels, but I can’t find that either.
Allowing 40 MHz operation with a broken coexistence mechanism seems to be worse than specifically not allowing 40 MHz operation with a shall in the standard. If someone decides to use 40 MHz channels, those that are affected may be able to withdraw their rights to any IP because the LOA only says you need to provide RAND licensing when the implementation conforms to the standard. Conforming with a broken coexistence mechanism seems to be a worse situation.
Regards, John
On 5/23/08 9:29 PM, "Matthew Fischer" <mfischer@broadcom.com> wrote:
I will be voting YES on TGn LB129, and I would urge others who are interested in defending 802.15.x devices' access to the ISMii band to vote YES as well.
The current draft of the 802.11 TGn amendment contains normative language describing a mechanism (i.e. the 40 MHz Intolerant bit) that allows non-related devices to signal to the 40 MHz TGn devices that they cannot send 40 MHz transmissions, effectively allowing other users of the ISMii band to restrict the use of 40 MHz transmissions by TGn devices. 40 MHz 802.11 TGn devices are required to obey this signaling whenever it occurs.
If 40 MHz operation is forbidden in ISMii by 802.11 TGn, then 40 MHz operation will be implemented as a set of vendor-specific non-standardized modes with variable degrees of good citizenship regarding spectrum sharing and with little or no opportunity for such devices to be controled by other users of the ISMii band.
For these reasons, it is in the best interest of 802.15.x technology providers and other users of the ISMii band to vote YES on the TGn-standardized mode of 40 MHz operation that includes specific requirements to force TGn devices to cease 40 MHz operation when requested.
Matthew Fischer
Nice Guy
+1 408 543 3370 office
+1 650 796 9206 mobile
mfischer@broadcom.com <mailto:mfischer@broadcom.com>
From: John Barr [mailto:john.barr@MOTOROLA.COM]
Sent: Friday, May 23, 2008 8:36 AM
To: STDS-802-WPAN@LISTSERV.IEEE.ORG
Subject: [802.15_GENERAL] TGn Letter Ballot Support
As mentioned in Jacksonville, the current draft of TGn includes use of 40 MHz channels in 2.4 GHz spectrum. This will significantly impair ability of other IEEE standards using 2.4 GHz spectrum to coexist with TGn devices running at 40 MHz. Even though the rejection of my comment number 6069 states that there is provision for coexistence with other radio systems using 2.4 GHz spectrum, the actual text for this is informative and does not actually include tests for IEEE 802.15.1 nor IEEE 802.15.4 devices. See attached note to TGn I sent during the Jacksonville meeting. At the one session where there was any discussion on my comment, I spoke against the resolution and no one spoke for the resolution rejecting my suggested change (not to allow any use of 40 MHz channels in 2.4 GHz spectrum). (See attached)
As it current stands there is no clear method to prevent use of 40 MHz channels in 2.4 GHz when IEEE 802.15.1 and 802.15.4 devices are operating in the same spectrum.
You can vote against the current TGn letter ballot by referencing my comment (6069) that is unresolved (not accepted by the submitter) and requesting the same resolution: In 20.3.15 change "When using 40 MHz channels, it can operate in the channels defined in 20.3.15.1 and 20.3.15.2." to "When using 40 MHz channels, it can only operate in the channels defined in 20.3.15.2."
James Gilb may be able to clarify just how to vote on this. Voters who previously approved the original LB can change their vote to disapprove based on this comment.
Thank you for your support.
Regards, John
--
John R. Barr (John.Barr@Motorola.com)
Director, Standards Realization - <http://www.motorola.com>
Vice Chairman of the Board, Bluetooth SIG - <http://www.bluetooth.org>
(847) 576-8706 (office) +1-847-962-5407 (mobile) (847) 576-6758 (FAX)
--
John R. Barr (John.Barr@Motorola.com)
Director, Standards Realization - <http://www.motorola.com>
Vice Chairman of the Board, Bluetooth SIG - <http://www.bluetooth.org>
(847) 576-8706 (office) +1-847-962-5407 (mobile) (847) 576-6758 (FAX)
--
John R. Barr (John.Barr@Motorola.com)
Director, Standards Realization - <http://www.motorola.com>
Vice Chairman of the Board, Bluetooth SIG - <http://www.bluetooth.org>
(847) 576-8706 (office) +1-847-962-5407 (mobile) (847) 576-6758 (FAX)