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+++



The intent/goal has always been an 802 filing (yes, 802.18 needs to be
replaced with 802, the footnotes need to be revised, etc. because of the
fact that the document was developed in a .18 template, but we have done
that with every document that .18 has prepared that has been approved by the
EC as an 802 filing).

I have received comments of an editorial, non-substantive nature, and plan
to incorporate those changes as a part of the final
editorial/spell_check/format_clean-up process, as has been done before.

Regards,
Carl


> -----Original Message-----
> From: owner-stds-802-sec@listserv.ieee.org
> [mailto:owner-stds-802-sec@listserv.ieee.org] On Behalf Of
> Mike Takefman
> Sent: Wednesday, November 24, 2004 11:48 AM
> To: STDS-802-SEC@listserv.ieee.org
> Subject: Re: [802SEC] +++EC Email Ballot+++Urgent motion to
> approve 802.18 doc+++
>
> 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.
>
>
> --
> Michael Takefman              tak@cisco.com
> Distinguished Engineer,       Cisco Systems
> Chair IEEE 802.17 Stds WG
> 3000 Innovation Dr, Ottawa, Canada, K2K 3E8
> voice: 613-254-3399       cell:613-220-6991
>
> ----------
> 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.