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.