|
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 -----
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
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)
|