RE: stds-80220-requirements: FW: 802.20 Requirements - Repeaters
Robert,
Can we try to have the proposed meeting on Monday night?
alan
-----Original Message-----
From: Robert D. Love [mailto:rdlove@nc.rr.com]
Sent: Thursday, October 23, 2003 8:57 PM
To: Migaldi Scott-W10265; stds-80220-requirements@ieee.org; Chickinsky,
Alan
Cc: Li Junyi
Subject: Re: stds-80220-requirements: FW: 802.20 Requirements -
Repeaters
Migaldi, perhaps I am misinterpreting what you are saying. However, in case
I am not, let me make a general statement that applies to repeaters and
other "required" components. It is important to understand the difference
between mandating the use of repeaters, and mandating that the system design
shall be capable of accommodating repeaters if they are a component that is
wanted in the system. My assumption is that our requirements document may
specify
that the system be designed to be able to accommodate certain components
(perhaps repeaters will be one of those). Such a requirement would not
necessitate the use of repeaters, nor preclude alternate designs, but would
set system parameters to be sure the use of repeaters would not be excluded
from an implementation that wanted to use them. It would be wholly
inappropriate for the requirements document to mandate the use of repeaters.
However, by setting a requirement such as "the system design will tolerate
the inclusion of repeaters", we have a real requirement that will impact the
setting of system parameters.
That said, I am taking no position now on whether we need to mandate the
ability to use repeaters. If there is disagreement, then we should be
looking at the alternative ways of achieving the coverage areas we require
to understand the impact and constraints that each of these methods would
impose.
Li, per your inquiry, if there are other ways of achieving the goal, we need
to understand what set of system constraints will allow us to implement the
fullest range of desirable solutions.
Based on the number of emails that have been posted on this subject, my
recommendation is that a small group of interested participants meet,
(perhaps Monday morning) and try to hammer out wording that everyone can
accept.
Alan, I don't know what your travel plans are for Albuquerque, but as the
editor of the requirements document, would you like to issue a call for
interest to meet Monday morning to try to resolve this issue?
Mark, Jerry, I hope I am not stepping on toes here to suggest a meeting. I
have a strong desire to see progress made on as many fronts as possible.
This is one area that I think may be ripe for resolution, or at least
substantial progress.
Best regards,
Robert D. Love
President, LAN Connect Consultants
7105 Leveret Circle Raleigh, NC 27615
Phone: 919 848-6773 Mobile: 919 810-7816
email: rdlove@ieee.org Fax: 208 978-1187
----- Original Message -----
From: "Migaldi Scott-W10265" <W10265@motorola.com>
To: <stds-80220-requirements@ieee.org>
Sent: Thursday, October 23, 2003 5:40 PM
Subject: RE: stds-80220-requirements: FW: 802.20 Requirements - Repeaters
>
> Junyi has a very good point here.
>
> The goal is low cost coverage and the use of repeaters are one type of
implementation to achieve this goal. There are other ways and I am sure that
there will be new ways to achieve this goal as well. To mandate repeaters as
part of the system deployment seems beyond the scope of a requirements
document, as much as mandating the use of alternate back up power support
for base stations.
>
> These are system design questions and are not part of the basic air
interface support. I think to say that the 'AI should support the addition
of coverage enhancing technology' is all that we could do at this stage 1
level. Then we can address the details of what that means latter on as the
protocol and interface are developed.
>
> Scott
>
> -----Original Message-----
> From: Li Junyi [mailto:Junyi_Li@flarion.com]
> Sent: Tuesday, October 21, 2003 20:11
> To: 'Joseph Cleveland '; Li Junyi; ''Humbert, John J [NTWK SVCS]' ';
> "<stds-80220-requirements@ieee.org>"@az33exr01.mot.com
> Subject: RE: stds-80220-requirements: FW: 802.20 Requirements -
> Repeaters
>
>
>
> Hi, Joseph,
>
> Another way is to think about this issue at an even higher level: using a
repeater by itself is not the goal; the goal is to provide decent coverage
at low cost. If there are alternative solutions to achieve the same goal,
why does the requirement care whether a repeater is used or not?
>
> Junyi
>
> -----Original Message-----
> From: Joseph Cleveland
> To: 'Li Junyi'; 'Humbert, John J [NTWK SVCS]';
'stds-80220-requirements@ieee.org'
> Sent: 10/21/2003 3:43 PM
> Subject: RE: stds-80220-requirements: FW: 802.20 Requirements - Repeaters
>
> Hi Li,
>
> Perhaps the requirement wording needs to indicate that the capability to
> support a repeater is mandatory, not that repeaters are mandatory.
>
> Joseph Cleveland
>
> -----Original Message-----
> From: Li Junyi [mailto:Junyi_Li@flarion.com]
> Sent: Tuesday, October 21, 2003 2:12 PM
> To: 'Humbert, John J [NTWK SVCS]'; stds-80220-requirements@ieee.org
> Subject: RE: stds-80220-requirements: FW: 802.20 Requirements -
> Repeaters
>
>
>
> Hi, everyone,
>
>
>
> Below are my two-cents on the issue of the repeaters.
>
>
>
> 1. The use of repeaters is a performance enhancement issue. In some
> situations, repeaters make sense. While in others, there are alternative
> ways as well. A mandatory requirement seems too strong.
>
> 2. The impact on the AI is subject to investigation. It may be a
> little too early to conclude that the system has to support huge delay
> or delay spread.
>
>
>
> Best,
>
>
>
> Junyi Li
>
>
>
> -----Original Message-----
> From: Humbert, John J [NTWK SVCS] [mailto:JHumbe01@sprintspectrum.com]
> Sent: Tuesday, October 21, 2003 2:11 PM
> To: stds-80220-requirements@ieee.org
> Subject: RE: stds-80220-requirements: FW: 802.20 Requirements -
> Repeaters
>
>
>
> Joanne et al.,
>
>
>
> Support for the use of repeaters needs to be a mandatory requirement
> because operators need to have this tool in their tool box to
> economically provide in-building coverage and in lightly populated
> areas. If you recall from the presentation in Singapore that KTF uses
> allot more repeaters than base stations in their network. The same trend
> is also occurring in the US.
>
>
>
> The impact on the AI is that the system has to support larger delay's
> and delay spreads.
>
>
>
> John J. Humbert
> 6220 Sprint Parkway
> Mailstop KSOPHD0504 - 5D276
> Overland Park, KS 66251-6118
> PCS (816) 210-9611
>
> -----Original Message-----
> From: Joanne Wilson [mailto:joanne@arraycomm.com]
> Sent: Friday, October 17, 2003 11:10 PM
> To: Humbert, John J [NTWK SVCS]; stds-80220-requirements@ieee.org
> Subject: RE: stds-80220-requirements: FW: 802.20 Requirements -
> Repeaters
>
>
>
> John,
>
>
>
> It's not clear to me the AI design implications of the changes you have
> made. However,."should support" implies that
>
> support for repeaters is optional. Changing to "must not preclude"
> makes it a mandatory requirement. This change,
>
> at least to me, doesn't clarify the rationale so much as changes
> requirement itself. I support maintaining the previous wording of the
> requirement until we have a better understanding of the implications of
> the change and the rationale for such.
>
>
>
> Best regards,
>
>
>
> Joanne
>
>
>
>
>
>
> -----Original Message-----
> From: owner-stds-80220-requirements@majordomo.ieee.org
> [mailto:owner-stds-80220-requirements@majordomo.ieee.org]On Behalf Of
> Humbert, John J [NTWK SVCS]
> Sent: Thursday, October 16, 2003 1:28 AM
> To: stds-80220-requirements@ieee.org
> Subject: stds-80220-requirements: FW: 802.20 Requirements - Repeaters
>
>
>
> Current Text
>
> Support for the use of Repeaters (Open)
>
> The system should support the use of repeaters
>
> Proposed Text
>
> The AI must not preclude the use of repeaters or reflectors to bypass
> obstructions and extend cell coverage.
>
>
>
> Rational
>
> 1) This text clarifies the rational given at the meeting in Singapore
>
> John J. Humbert
>
> 6220 Sprint Parkway
>
> Mailstop KSOPHD0504 - 5D276
>
> Overland Park, KS 66251-6118
>
> PCS (816) 210-9611
>