|
Benjamin, you make an interesting point.. I would
like to add a little twist to it.
If your HVAC system uses a 802.15.4 stops
working because you just turned on a new 11n system, well, yes you will
not appreciate and will probably return it. That' self coexistence... the owner
with himself, the easy part.
However, if you are gone for a week and your
neighbor gets a new 11n device... I'm not sure how you'll appreciate
your frozen pipes and the water damage when you come back... and how you'll
appreciate your HVAC technician bill when he tells you there is nothing wrong
with your HVAC system, that you just have to replace its control elements and
start pulling wiring to replace the wireless controls you paid a premium for...
because "someone" in the area just fired up an 11n system and either
doesn't know or worse, doesn't care because "he's" not affected...
That was the nice case. Now I'm not sure how you'll
like the repeated service calls (and service charges and loss of trust in the
system reliability) to the HVAC tech if the 11n device is in a portable device
and appears as an intermittent failure source for your HVAC system, driving
you HVAC tech crazy ... when he's there, no 11n device in the area... nothing
wrong with the system... from time to time, when he's gone, the HVAC system
fails due to the sproadic presence of the 11n system.
I think we have to consider the hardship X10 lived
through because of sporadic house lights turning on in the middle of the night,
etc... if 802.11n units start causing things like that to 802.15.4 devices...
its very possible that the public's perception of the overall
environment may damage the "trust" the public and the regulators have in
the 802 "brand" name on many products.
----- Original Message -----
Sent: Tuesday, May 27, 2008 12:15
PM
Subject: Re: [802.15_GENERAL] [802.19]
[802.15_GENERAL] TGn Letter Ballot Support
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
|