|
Hi All,
I am not able to post to the 802.11n but I hope one
of you that can will ensure this thread gets circulated there so that TG members
not on our dot 15 reflector get in on it.
Ivan makes the good point that the non-802.11
device is not able to signal it's inability to tolerate something using 802.11
protocols. I've been looking at what I think are the relevant sections of the
draft:
11.14.11 Signaling 40 MHz intolerance, 11.14.12 Switching between 40 MHz and 20
MHz
11.14.12 answers how a non-N legacy 802.11 device
may "signal" if I read it right: the reception of a legacy beacon (TE-A) shall
cause "re-evaluation". You might note that in draft 5 the reference given
here for how "re-evaluation" is done points to a subclause number which
does not appear to exist ("shall
re-evaluate the value of the local variable 20/40 Operation Permitted (see
11.9.8.3)")
I've not been able to find on the document
server any presentations on coexistence with non-802.11 spectrum users in a
quick search. What would help tremendously is if
someone could post specific references to he coexistence analysis, simulation
results, and (most helpful) field measurement results of existing "almost N"
devices. From my limited knowledge of 802.11n see a very significant potential
for problems. I'm sure I'm missing key points as to how this mechanism is
intended to work, so any explanation of why this is not a severe coexistence
problem would be greatly appreciated. As I read it, there is no
coexistence consideration at all for non-802.11 systems.
What concerns me most about this discussion is that
it seems to illustrate that some in dot-11 are working with a very narrow
view of coexistence. I've only been able to briefly look through draft
5, and I see a good amount
of verbiage about coexistence with participating 802.11 systems, and
interoperability with legacy 802.11 systems. Representing a consensus of one, I
can assure you that is not nearly broad enough to ensure success in the ever
more crowded space of 2.GHz (that is my opinion which plus $3US will get you a
cup of coffee). I'm not suggesting that there are not good,
reassuring arguments an analysis which may attenuate these concerns, just that
if there are, I've not seen them yet.
To Matthew's second point, I have to agree in
principle (enthusiastically) that standards are better than non-standards, and
we must remember that 802 in the world: we are not a regulator. Providing a
standard-defined behavior is better than a plethora of non-standard wireless
systems competing, and as Ivan points out, one can define an ISM device which is
very unfriendly under the current rules. Keep in mind that if this becomes
a problem as perceived by our esteemed regulators, then rules changes will be
made (and odds are non of us will like the result all that much).
Also keep in mind if users find 802.11n use annihilates their
Bluetooth, shuts down their HVAC system, or otherwise fails to get
along in the spectrum with all the other stuff they've got, They'll abandon
those 802.11n devices the entire effort of TGn and the vendors building to
it will be for naught. Vendors may go ahead and produce non-standard
products, but if they are not spectrum friendly, they'll find it an unsatisfying
endeavor.
-B
================================
Benjamin A.
Rolfe
408.395.7207 Office
408.332.0725 Mobile
Skype:
benjamin.rolfe
==========================================================================================
Disclaimer: the contents of this email represent
the views of the author and do not necessarily reflect the views of any other
person, organization, corporation, or other entity. Read at your own
risk.
==========================================================================================
----- Original Message -----
Sent: Monday, May 26, 2008 9:50 AM
Subject: Re: [802.15_GENERAL] [802.19]
[802.15_GENERAL] TGn Letter Ballot Suppo
more on coexistence.
At 08:20
AM 5/26/2008 -0400, Ivan Reede wrote:
My
question on this is simple....
How does a device, which does not have a clue of the
802.11 modulation and MAC mechanisms form a message that will "set" the
magic bit?
The next obvious question follows: How does a low power device, with
a shorter range and lower transmitting power than an 802.11 device, signal
anything to a 802.11 device that prevents it from operating if the 802.11
device is bewyond the low power, short range device. How doe a 10 meter
range device tell an problematic 802.11 device at 30 meters to switch to the
20 MHz mode?
The next one is, how does one protect 802.11 devices which claim to
have a higher transmission speed to be attacked by another device that
simply signals it to reduce its speed. To me, this sounds pretty bad... the
comnsumer buys a device that claims to go faster, puts it in a "normal"
urban setting (where meny devices go) where alot of legacy devices are
present and ends up wirth a device that will not perform at the higher
speeds.
Next, how does an older device perform when a new device comes
along... if it does not know how to signal the "magic" bit to tell the new
device to slow down... we have millions of 02.11 devices deployed at 2.4
GHz. Are they going to be negatively impacted. Is that in agreement with the
5 criteria we all work so hard on when we create a PAR?
A question for the EC
and the IEEE SA, sonsors of 802 projects. Once a project has been approved,
is the body authorised to override the PAR's scope and most importantly, is
the body authorised to override the 5 criteria that were required to approve
the PAR, even if the limitations imposed by any of these 5 criteria is not
explicitly set out in the scope. I am seriously concerned by this last
question. My feeling for having participated in many groups is that I have
the growing perception whereby there appears to be a forming mindset that a
PAR is simply something to make the EC happy and that once the prject has
been authorised, any thing goes, the project body has ultimate power. I
think the body has been delegated a limited power by the EC to create a
standard wtihin the bounds of the project's scope and the 5 criteria upon
which it was authorized and that this ought to be well communicated to the
working group members.
As far as people making things that are beyond the
standard, I have to fully agree, its about time we set limits to proprietary
things that can be "added" to comlpiant devices and still claim compliance
to a standard. What would happen for example, if a manufacturer decided one
day to make an 802.11 complaint device have a special mode that could be set
by the user, whereby it would transmit a carrier whenever it wants, under
user control. That device could pass all 802.11 compliance tests with that
mode off, yet, when another of his devices happens be be in vicinity, he
could recognise it and both could agree to "pre-emt" all neighbouring
devices by killing them via the carrier sense mode. That would give the 2
devices an unfair advantage over other devices that respect the "carrier
sense" by shutting them off... but would that be a compliant device? Yes, I
do support prduct vendor can make additions to devices that give them an
edge in so much as they respect the spit of the standard and in general,
improve the orverall system performance and I would not like to curtail
that, yet, I think there are limits to these if they break some of our basic
principles, like network access fairness and I am not sure how we could make
those "implementations" non-compliant.
As you can see, I have
many questions which beg for hard answers. This is food for thought. How
does 802 make sure that compliance promotes coexistence between vendors and
all 802.xx compliant wireless products in general?
Ivan Reede
- ----- Original Message -----
- From: Shellhammer,
Steve
- To: paul.nikolich@att.net ; bkraemer@marvell.com ; carl.stevenson@ieee.org ; david.cypher@nist.gov ; eldad.perahia@intel.com ; I_reede@amerisys.com ; john.barr@motorola.com ; Joseph.Levy@InterDigital.com
; Mark.austin@ofcom.org.uk ;
mjlynch@nortel.com ; nada.golmie@nist.gov ; ppiggin@nextwave.com ; bheile@ieee.org ; Shellhammer, Steve ; sli@sibeam.com ; swhitesell@vtech.ca ; vivek.g.gupta@intel.com
- Cc: bill.shvodian@ieee.org
- Sent: Sunday, May 25, 2008 11:16 PM
- Subject: RE: [802.19] [802.15_GENERAL] TGn Letter Ballot
Support
- I wanted to forward this onto
those who are not on the 802.19 reflector
- Steve
- From: Bill Shvodian [mailto:bill.shvodian@gmail.com] On Behalf Of Bill
Shvodian
- Sent: Sunday, May 25, 2008 7:16 PM
- To: Shellhammer, Steve
- Subject: RE: [802.19] [802.15_GENERAL] TGn Letter Ballot
Support
- Steve, I am not an 802.19
member, but I monitor the reflector so I am not doing a reply-all. I
think that 40 MHz operation should be banned by the FCC and other
regulatory agencies. I think .19 and .18 should be active on
this. There are 2 billion Bluetooth/802.15.1 devices deployed that
will be adversely impacted by 40 MHz 802.11n devices. You and others
did a lot of good work to help 802.11 and 802.15.1 devices coexist and
this definitely will not help. The 40 MHz intolerant bits seems
nearly useless to me.
- Bill Shvodian
- Director of
Standards
- NII Holdings
- From: Shellhammer, Steve [mailto:sshellha@QUALCOMM.COM]
- Sent: Sunday, May 25, 2008 2:38 PM
- To: STDS-802-19@LISTSERV.IEEE.ORG
- Subject: Re: [802.19] [802.15_GENERAL] TGn Letter Ballot
Support
- IEEE 802.19 TAG,
-
Paul Nikolich would like the opinion of the 802.19 members on the 40 MHz
802.11n discussion.
-
If you have an opinion to share please “reply-all” so that everyone can
hear your opinion.
- Regards,
- Steve
- From: Paul Nikolich [mailto:paul.nikolich@att.net]
- Sent: Saturday, May 24, 2008 7:06 AM
- To: Shellhammer, Steve
- Subject: Fw: [802.15_GENERAL] TGn Letter Ballot
Support
- Steve,
- What is dot19's opinion on the below
debate?
- --Paul
- ----- Original Message -----
- From: Matthew Fischer
- To: STDS-802-WPAN@LISTSERV.IEEE.ORG
- Sent: Friday, May 23, 2008 10:29
PM
- Subject: Re: [802.15_GENERAL] TGn Letter
Ballot Support
- 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
- 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)
No virus found in this
incoming message.
Checked by AVG.
Version: 7.5.524 / Virus Database:
269.24.1/1464 - Release Date: 5/24/2008 8:56 AM
Bob Heile, Ph.D
Chairman, ZigBee Alliance
Chair,
IEEE 802.15 Working Group on Wireless Personal Area Networks
11 Robert
Toner Blvd
Suite 5-301
North Attleboro, MA 02763
USA
Mobile: +1-781-929-4832
email:
bheile@ieee.org
|