Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [802SEC] +++EC Email Ballot+++Urgent motion to approve 802.18 doc+++



Carl,

Whereas I whole heartedly agree with Pat's editorial comments, and wish
that they are included.

I have watched the conversations on the 802 ExCom and the 802.11
reflectors and have had similar concerns on the Wireless Microphones that
I expressed at the Closing ExCom meeting in San Antonio. I still feel that
we are missing something in regards to the 802.11 standard, and I am
hopeful of which will be resolved by the FCC during the NPRM process.

My other area was that this could have been a true 802.18 position and not
a blanket 802 position. That not withstanding, and especially as members
of my 802.11 WG did in fact take the time to attend your 802.18 group, to
help in crafting this work effort compromise. I now feel that I am in a
position to cast my 802 ExCom vote.

My vote therefore is APPROVE with Pat's editorials,

Stuart


_______________________________



Stuart J. Kerry

Chair, IEEE 802.11 WLANs WG



Philips Semiconductors, Inc.

1109 McKay Drive, M/S 48A SJ,

San Jose, CA 95131-1706,

United States of America.



Ph : +1 (408) 474-7356

Fax: +1 (408) 474-5343

Cell: +1 (408) 348-3171

eMail: stuart.kerry@philips.com

_______________________________



-----Original Message-----
From: owner-stds-802-sec@listserv.ieee.org
[mailto:owner-stds-802-sec@listserv.ieee.org] On Behalf Of
ajayrajkumar@LUCENT.COM
Sent: Wednesday, November 24, 2004 8:52 AM
To: STDS-802-SEC@listserv.ieee.org
Subject: Re: [802SEC] +++EC Email Ballot+++Urgent motion to approve 802.18
doc+++

Mike,

I agree with you. That is exactly what I was pointing out since Carl had
responded to Steve that he cannot make substantive changes.

-ajay

On 11/24/2004 11:47 AM, Mike Takefman wrote:
> If it is an 802.18 response then this ballot is not required as
> the EC just needs to be informed of the decision.
>
> Therefore, I assume that Carl and dot18 want it to be an 802
> position and it would make sense to change the wording to remove
> the .18 in the footnote because I would like to believe this
> would carry more weight.
>
> Also, the EC always has the right to make whatever changes we
> think is correct, although we tend not to make major technical
> changes, but generally editorial ones.
>
> cheers,
>
> mike
>
> Ajay Rajkumar wrote:
>
>>I Approve.
>>
>>However, the following comments are to make the response consistent.
>>
>>During the closing EC meeting discussions last Friday, I understood that
this
>>document would be sent as if coming from the whole of 802, whereas,
footnote 2
>>clearly indicates that these are the views of 802.18 TAG. Is it the
former or
>>the latter? This should be made consistent.
>>
>>Also, Carl mentions that he (or the 802.18 TAG Chair) is not empowered
to make
>>substantive changes but again is it an 802 response or the TAG response?
>>
>>-ajay
>>
>>On 11/24/2004 9:49 AM, Carl R. Stevenson wrote:
>>
>>
>>>Steve, and EC colleagues,
>>>
>>>Again, comments in context below with a .pdf for those whose mail
>>>clients may not handle HTML.
>>>
>>>
>>>
------------------------------------------------------------------------
>>>   From: Shellhammer, Stephen J
[mailto:stephen.j.shellhammer@intel.com]
>>>   Sent: Tuesday, November 23, 2004 9:14 PM
>>>   To: wk3c@wk3c.com; paul.nikolich@att.net;
STDS-802-SEC@listserv.ieee.org
>>>   Subject: RE: [802SEC] +++EC Email Ballot+++Urgent motion to approve
>>>   802.18 doc+++
>>>
>>>   Carl,
>>>
>>>
>>>
>>>               Thank you for your detailed response. Let me try to
>>>   summarize my concerns in this response. They relate to wireless
>>>   microphones and professional installation.
>>>
>>>
>>>
>>>   Wireless Microphones
>>>
>>>               I am not trying to question the accuracy of the
>>>   technical work within 802.18.  My concern is that the IEEE is
>>>   recommending to the FCC that they regulate how industry ensures that
>>>   Part 15 devices do not interfere with Part 74 devices. Typically the
>>>   FCC limits power and power spectral density (PSD) of Part 15 devices
>>>   but does not specify rules for spectrum sharing. They typically
>>>   leave any spectrum sharing designs to the industry.
>>>
>>>
>>>
>>>   That has been their practice in unlicensed vs. unlicensed sharing
>>>   situations (the ISM bands), but again, unlicensed under licensed is
>>>   a very different situation, as you note before.
>>>
>>>
>>>
>>>               You mention my position as chair of 802.19 Coexistence
>>>   TAG which is a very good point.  By analogy, 802.19 did not regulate
>>>   in the recent rules change how the wireless working groups should
>>>   ensure coexistence, we just are requiring that they do coexist,
>>>   using any design they like, and then show that the new standard
>>>   coexists with current standards.  So 802.19 did not tell the
>>>   wireless working group how to do their job, just that they need to
>>>   show that they did do there job.
>>>
>>>
>>>
>>>   That is an internal 802 matter, not a question of what regulation
>>>   may be necessary to assure protection of licensed services. (The
>>>   latter is the domain/responsibility of the FCC, and we have simply
>>>   tried to recommend the minimum regulation that our studies and
>>>   discussions with the incumbent licensees indicate to be
appropriate.)
>>>
>>>
>>>
>>>               However, I do understand that this band is different
>>>   than the ISM bands so I appreciate that it may be necessary for the
>>>   FCC to set additional regulation on industry.
>>>
>>>
>>>
>>>               So I will accept your response on the Part 74 devices
>>>   and will withdraw my recommendation to remove those paragraphs.
>>>
>>>
>>>
>>>   Thank you.
>>>
>>>
>>>
>>>   Professional Installation
>>>
>>>               I do not accept that argument that GPS systems and
>>>   database systems are always unreliable, and hence the only valid
>>>   method of installation is a professional. I believe that in many
>>>   cases GPS and a database can be made reliable and can be used for
>>>   installation.  In the case that they do not work professional
>>>   installation is also available.  So I believe that both methods of
>>>   installation should be allowed by the FCC.
>>>
>>>
>>>
>>>   The issue is not that "GPS and database systems are *always*
>>>   unreliable."  The issue is that GPS can be unreliable in some
>>>   situations *and* that the FCC database of information on licensed
>>>   facilities (TV stations) contains many omissions and
>>>   inaccuracies and isn't maintained in a timely fashion due to a lack
>>>   of resources and other factors.  The combination of these
>>>   factors results in the conclusion that relying on "GPS and database"
>>>   as a sole means of determining channel availability at any given
>>>   location/time would be unreliable often enough to present
>>>   significant interference potential.  Since we will have an
>>>   obligation not to cause interference, we believe that relying on
>>>   "GPS and database" as a sole means is inappropriate and would result
>>>   in interference that could/should be avoided (at least at this time,
>>>   under the current circumstances).
>>>
>>>
>>>
>>>   Note that the professional installation recommendation applies
>>>   *only* to the base station in fixed access networks, not to the CPE
>>>   (user terminals), nor to "personal portable" devices.  What this
>>>   means is that a WISP, for example, will have to have someone capable
>>>   of doing "due diligence" in terms of locating the base station,
>>>   predicting its coverage, looking at what channel(s) can be used from
>>>   that site with the intended technical parameters and coverage, and
>>>   making initial channel selections that assure that the coverage
>>>   (interference range) of the base station does not overlap into the
>>>   "Grade B protected contour" of surrounding TV stations at levels
>>>   that would violate the required D/U (desired/undesired signal)
>>>   ratios. (after turn-on, the base station and its associated CPEs
>>>   would use the sensing mode to verify channel availability and to
>>>   respond to changes in the RF environment as TV facilities and
>>>   channel assignments change with time).
>>>
>>>
>>>
>>>   Perhaps with time, if the FCC database were to become more accurate
>>>   and were updated in a very timely manner, the problems associated
>>>   with the reliability of the "GPS and database" technique will be
>>>   resolved to the point where sufficient reliability could be
>>>   obtained.  At that time, I am confident that the FCC would entertain
>>>   a request for a rules change, but at the moment, we believe that we
>>>   cannot, in good professional conscience, endorse this technique as a
>>>   sole, "stand-alone" means of determining channel availability and
>>>   ensuring that interference to the incumbent licensed services does
>>>   not occur.
>>>
>>>
>>>
>>>   Finally, personal portable devices (obviously) cannot be
>>>   "professionally installed," and there is no suggestion that they
>>>   should be, as, by definition they are easily moved about/relocated.
>>>   Clearly, such devices will have to operate autonomously to prevent
>>>   interference.  I would also point out that relatively short-range,
>>>   relatively low power systems like 802.11x are not treated as fixed
>>>   systems precisely because of the ease with which they can be
>>>   relocated.  (Note that, under the changes made to the ITU Radio
>>>   Regulations at WRC-03, the new global, primary allocation to
>>>   "Wireless Access Systems, including RLANs" (which includes 802.11)
>>>   was made to the MOBILE service, not to the FIXED service.)
>>>
>>>
>>>
>>>               I maintain my recommendation to add text to the document
>>>   allowing for either professional or GPS/Database types of
installation.
>>>
>>>
>>>
>>>   In the event that my further explanation on this topic has not
>>>   changed your view, I can only say that I am not empowered to make
>>>   such substantive changes to the document.  I would also refer you to
>>>   the following text from the 802.11 technical reflector, submitted by
>>>   Bob O'Hara in response to some supportive comments there:
>>>
>>>
>>>
>>>   --- This message came from the IEEE 802.11 Technical Reflector ---
>>>
>>>   I would like to echo the position expressed here, this response
>>>   needs to be filed in a timely fashion and with out any substantive
>>>   changes.
>>>
>>>   There has been significant cooperation between the incumbent license
>>>   holders and the members of the 802 wireless working groups.
>>>
>>>   Since this NPRM addresses operation in a band relatively far removed
>>>   from any where existing 802 operate, any devices ultimately designed
>>>   to operate here will be based on new silicon and new PHY
specifications.
>>>
>>>   There are no existing 802 device manufacturers to protect. Therefore
>>>   I think that there is little danger to the extra protection that
>>>   some see in the response. If this is helpful to getting consensus
>>>   from all the parties involved in the NPRM, I think that it is not
>>>   too high a price to pay.
>>>
>>>   -Bob
>>>
>>>   Regards,
>>>
>>>   Carl R. Stevenson
>>>
>>>   President and Chief Technology Officer
>>>
>>>   WK3C Wireless LLC
>>>
>>>   Where wireless is a passion, as well as a profession. SM
>>>
>>>   ???????????????????????????????????
>>>
>>>   Wireless Standards, Regulatory & Design Consulting Services
>>>
>>>   4991 Shimerville Road
>>>
>>>   Emmaus, PA 18049-4955 USA
>>>
>>>   phone:  +1 610 965 8799
>>>
>>>   cellular: +1 610 841 6180
>>>
>>>   e-mail:  wk3c@wk3c.com <mailto:wk3c@wk3c.com>
>>>
>>>   web: http://www.wk3c.com <http://www.wk3c.com/>
>>>
>>>---------- This email is sent from the 802 Executive Committee email
>>>reflector. This list is maintained by Listserv.
>>
>>
>>----------
>>This email is sent from the 802 Executive Committee email reflector.
This list is maintained by Listserv.
>
>
>

----------
This email is sent from the 802 Executive Committee email reflector.  This
list is maintained by Listserv.

----------
This email is sent from the 802 Executive Committee email reflector.  This list is maintained by Listserv.