Re: stds-80220-requirements: comments on rev5 - Channel bandwidth resolution

["Lynne A. Dorward" <ladcomm@rogers.com>]

I also concur with Jerry

Lynne Dorward

LADCOMM
----- Original Message ----- 
From: "Chris Bussey" <chris286@swbell.net>
To: <Jerry1upton@aol.com>; <joanne@arraycomm.com>; <M.Klerer@flarion.com>;
<stds-80220-requirements@ieee.org>
Cc: <joconnor@ipwireless.com>; <JClevela@sta.samsung.com>;
<scrowley@attglobal.net>; <Mark.Cudak@motorola.com>;
<imamura.daichi@jp.panasonic.com>; <Trinkwon@compuserve.com>;
<fwatanabe@ieee.org>
Sent: Thursday, September 11, 2003 4:26 PM
Subject: Re: stds-80220-requirements: comments on rev5 - Channel bandwidth
resolution


>
> Jerry,    I think your proposal is a good one and it will certainly make
the
> document easier to be understood.
>
> Count me as a supporter
>
> Rgds
>
> Chris Bussey
> BCSI
> ----- Original Message ----- 
> From: <Jerry1upton@aol.com>
> To: <joanne@arraycomm.com>; <M.Klerer@flarion.com>;
> <stds-80220-requirements@ieee.org>
> Cc: <joconnor@ipwireless.com>; <JClevela@sta.samsung.com>;
> <scrowley@attglobal.net>; <Mark.Cudak@motorola.com>;
> <imamura.daichi@jp.panasonic.com>; <Trinkwon@compuserve.com>;
> <fwatanabe@ieee.org>
> Sent: Thursday, September 11, 2003 12:24 PM
> Subject: Re: stds-80220-requirements: comments on rev5 - Channel bandwidth
> resolution
>
>
> >
> > Joanne,
> > Your proposal does add clarity to the discussion.
> >
> > However, it is not clear that we have consensus support. Though silence
> maybe consensus, it is useful to hear from the earlier proponents of wider
> channel bandwidths. I have copied a number of individuals who I believe
were
> proponents. I ask them to give us some direct feedback. If I have missed
> proponents or have missed stated their positions, I apologize in advance.
> >
> > I do propose a change in your proposed in "Action 2" 4.1.4.
> >
> > You proposed:
> > "Additionally, requirements for 802.20 systems targeted for the larger
> allocation bandwidths (i.e. 2x10 or 2x20 MHz FDD allocations, and 20 MHz
or
> 40 MHz TDD allocations) are presented in [Section][Addendum] XX of this
> document.1.4."
> >
> > My proposal:
> > "Requirements for 802.20 systems applicable only to specific channel
> bandwidths are highlighted and noted in each section of this document.
> Unless highlighted and noted the requirements stated in each section shall
> be applicable to all channel bandwidths and allocations listed above."
> >
> > Rationale:
> > Many of requirements should be applicable to all channel bandwidths. If
> there are requirements specific to the channel bandwidth, the proponent(s)
> should highlight them. These could be for wider or narrower channel
> bandwidths. It is much easier for the reader of the requirements document
to
> understand the differences versus referring back to an addendum. This will
> also reduce any ambiguity between common requirements and specific
> requirements.
> >
> > Regards,
> > Jerry Upton
> >
> >
> > In a message dated 9/10/2003 5:20:35 PM Eastern Daylight Time,
> joanne@arraycomm.com writes:
> >
> > > Folks,
> > > It appears that there is consensus support for Mark Klerer's proposal
in
> his September 2nd
> > > email. To capture that in the Requirements Document, I propose the
> following:
> > >
> > > Proposal:
> > > Section 4.1.4 Channel Bandwidth
> > >
> > > Current Text:
> > > The AI shall support bandwidths in multiples of 5 MHz in downlink and
> uplink.
> > >
> > > Action 1:
> > > Change the title of section heading to:
> > >
> > >             4.1.4.  Support for different allocation bandwidths
> > >
> > > Rationale:
> > >
> > > This seems to be more in keeping with this basic requirement which is
to
> support deployment
> > > of 802.20 systems in different allocation bandwidths.
> > >
> > > Action 2:
> > >
> > > Replace the current text in 4.1.4. with the following:
> > >
> > >
> > > The AI shall support deployment of 802.20 systems in the following
> allocation
> > > bandwidths:
> > > +---------------------------------------------- -+
> > > |                                     |
> |
> > > | FDD Allocations           |       2 x 1.25 MHz       |
> > > |                                     |       2 x 5 MHz            |
> > > |                                     |       2 x 10 MHz          |
> > > |                                     |       2 x 20 MHz          |
> > > +-----------------------+-----------------------+
> > > |                                     |
> |
> > > | TDD Allocations          |     2.5 MHz                  |
> > > |                                     |       5 MHz                  |
> > > |                                     |     10 MHz                  |
> > > |                                     |     20 MHz                  |
> > > |                                     |     40 MHz                  |
> > > +-----------------------+-----------------------+
> > > The individual 802.20 AI proposals may optimize their MAC and PHY
> designs for
> > > specific bandwidth and duplexing schemes. Additionally, requirements
for
> 802.20
> > > systems targeted for the larger allocation bandwidthss (i.e. 2x10 or
> 2x20 MHz
> > > FDD allocations, and 20 MHz or 40 MHz TDD allocations) are presented
in
> [Section][Addendum]
> > > XX of this document.
> > >
> > > Rationale:
> > > This text captures the proposal put forth by Mark Klerer on September
2
> addressing the
> > > interests of the various parties in the discussion about allocation
> bandwidths.  To remove ambiguity
> > > about the specific allocations for FDD and TDD systems, they are
listed
> in a table so the reader
> > > doesn't have to know that 2 x N MHz (FDD) is equivalent to. 2N MHz
(TDD)
> allocations.
> > >
> > > NOTE:  I am also proposing to add 5MHz to the list for TDD allocations
> since it is not
> > > unusual to see allocations of this size for TDD systems. Also, the
text
> of the section
> > > or addendum related to systems for higher allocation bandwidths should
> be proposed
> > > by the proponents of those options.
> > > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> > >
> > > I hope this proposed text is acceptable to everyone.
> > >
> > > Best regards,
> > > Joanne
> > > -----Original Message-----
> > > From: owner-stds-80220-requirements@majordomo.ieee.org
> [mailto:owner-stds-80220-requirements@majordomo.ieee.org]On Behalf Of
Klerer
> Mark
> > > Sent: Tuesday, September 02, 2003 10:18 AM
> > > To: stds-80220-requirements@ieee.org
> > > Subject: RE: stds-80220-requirements: comments on rev5 - Channel
> bandwidth resolution
> > >
> > >
> > > Proposal for a Way Forward:
> > >
> > > It is becoming obvious that there are constituencies for both the
1.25 -
> 5 MHz channel bandwidth range and for the channel bandwidth range of 10-20
> MHz. I would, therefore, like to propose that we accommodate both ranges
> (see below).
> > >
> > > I would, first like to point out that when we were speaking about 1.25
> and 5 MHz that is for paired FDD spectrum, i.e. the total bandwidth a
> service provider will need is 2 x 1.25 and 2 x 5 MHz (I.E. 2.5 and 10MHz
> allocations). For TDD systems that translate to 2.5 and 10 MHz unpaired
> spectrum, respectively. (This is made clear in a footnote to the Table in
> item 18 of the PAR { 802.20 - PD-02 } for the 1.25 MHz system - the PAR
> table does not show the 5 MHz parameters). I propose we stick with this
> convention of referring to bandwidth of the channel in this way. This will
> imply that when we speak about 10 MHz and 20 MHz channel bandwidth we are
> speaking about allocations of 20 and 40 MHz, respectively (with TDD free
to
> split this bandwidth asymmetrically).
> > >
> > > I would like to propose that we agree to the following:
> > > 1.    Accommodate channel bandwidths of 1.25, 5, 10 and 20 MHz (i.e.
> systems requiring allocation of 2.5, 5, 20 and 40 MHz).
> > > 2.    The individual systems are allowed to optimize their PHY and MAC
> designs for bandwidth and duplexing scheme.
> > > 3.    The Requirements document either includes a separate section or
we
> create an Addendum that addresses requirements for the 10 and 20 MHz
> systems. [I propose that we need to get some closure on the issues raised
on
> the conference call and prior e-mails as to, e.g. whether we envision this
> to be used only for capacity increase (and CAPEX reduction - as noted by
> Jim) or whether we (also) envision the introduction of new services that
> require more bandwidth (as indicated by David McGinnis) so that there is
> some guidance for the design of these systems].
> > >
> > > I believe the above would allow us to move forward on a common basis
> creating a specification (or specifications) that will satisfy the various
> international needs for now and the foreseeable future.
> > >
> > > With the understanding that the 20MHz design will require an
allocation
> of 40 MHz I would be interested in opinions
> > > whether we already need to address this at this time.
> > >
> > > Regards,
> > >
> > > Mark Klerer
> >
>
>
>