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)