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

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




 
Joanne, All,

I just requested a clarification regarding the minimum and max. channel
width, to be supported in proposals:

min. 400kHz (for 3 frequencies systems)

max. 40MHz, (for 1 frequency systems).

And of course, I asked myself, how many PHYs should one propose to support
this range.

Marianna



-----Original Message-----
From: Joanne Wilson
To: Marianna Goldhammer; Klerer Mark; stds-80220-requirements@ieee.org
Sent: 9/12/2003 9:18 AM
Subject: RE: stds-80220-requirements: comments on rev5 - Channel bandwidth
resolution

Marianna,
 
I don't understand your proposal.  Also, I believe we are to look to the
Evaluation CG to determine
how to evaluate the various proposals as they relate to the requirements
coming out of the
Requirements CG.  Agree?
 
Best regards,
 
Joanne
-----Original Message-----
From: Marianna Goldhammer [mailto:marianna.goldhammer@alvarion.com]
Sent: Thursday, September 11, 2003 5:39 AM
To: Joanne Wilson; Klerer Mark; stds-80220-requirements@ieee.org
Subject: RE: stds-80220-requirements: comments on rev5 - Channel
bandwidth resolution


So, Mark, Johanne,
 
When doing simulations for PHY proposal evaluations, people should
address, for "one frequency system", channel width from 1.25MHz up to
40MHz; for 3 frequencies systems, channel width of 4ookHz, 1.67MHz,
3.33MHz, up to 13.3MHz. 
 
 
Right? 
 
Marianna
 
 
-----Original Message-----
From: Joanne Wilson [mailto:joanne@arraycomm.com]
Sent: Wednesday, September 10, 2003 11:21 PM
To: Klerer Mark; stds-80220-requirements@ieee.org
Subject: RE: stds-80220-requirements: comments on rev5 - Channel
bandwidth resolution


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
<http://ieee802.org/20/P_Docs/IEEE%20802.20%20PD-02.pdf>  } 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



This mail passed through mail.alvarion.com

************************************************************************
************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals &
computer viruses.
************************************************************************
************

This mail was sent via mail.alvarion.com

************************************************************************
************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals &
computer viruses.
************************************************************************
************



This mail passed through mail.alvarion.com

************************************************************************
************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals &
computer viruses.
************************************************************************
************

This mail was sent via mail.alvarion.com
 
************************************************************************************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses.
************************************************************************************