RE: stds-80220-requirements: comments on rev5 - Channel bandwidth resolution
In response to Gerry's request, and being one of the original instigators of
>5MHz channels, I'll comment as follows :
a) This is becoming too much of a "big deal" and does not warrant separate
sections or requirements. My original intent was to remove the apparent
"restriction" of 1.25 and 5MHz (only) because of the availability of wider
spectrum allocations in the US (and similar) MMDS bands plus the permitted
use of "portability" in 3.5GHz bands (and the possible future sanction of
"Nomadic" and "Mobile" applications in these bands in some countries).
b) Although not directly linked to spectrum allocation, it is generally
cheaper to deploy as wide a channel bandwidth as possible / technically
feasible for the targeted services since this minimizes the number of radios
/ channels / antenna etc needed for a given capacity. The only reason to use
narrower channels is to satisfy frequency reuse / sectorization constraints,
technical (esp. PHY) constraints and equipment / design / filtering
constraints. History shows that over time these constraints become less
onerous and therefore the feasible channel bandwidths will increase over
time. The standard should anticipate this.
c) Although "conventional" technology and practice is centered around
1.25MHz channels (in GSM and PCS bands) and sees extension to 5MHz as
"aggressive", those of us moving into mobility from the fixed environment
(and competing with 802.11 bandwidths and services) are not so constrained,
and see 10MHz or 20MHZ channels as being the least sizes needed to support
urban, suburban and rural deployments, based on coverage, capacity and
economic criteria. The mandatory sections of the air interface should be
applicable to any desired channel bandwidth that makes sense within the
allocated spectrum. Vendors can choose whether or not to build / offer any
particular channel size, and what optional features of the AI to support in
particular configurations. This is really a matter for system profiles and
conformance testing etc once the standard is finalized.
d) It shouldn't matter what 802.10 decides v/v 802.16. 802.10's task is to
come up with the best standard for the declared objectives (which includes
full mobility up to 250km/h). 802.16's task is specify (incremental)
revisions to the 802.16 MAC and PHYs to meet a much lower mobility target.
The market will decide which (and whether any) of the resultant standards
meets the commercial test of deployability and viability, as it did with
Ethernet versus Token Ring etc.
Regards
David Trinkwon
Email : Trinkwon@compuserve.com
USA Tel : 650 245 5650 Fax : 650 649 2728
UK Tel : +44 (0)7802 538315 Fax : +44 (0)20 7504 3586
-----Original Message-----
From: owner-stds-80220-requirements@majordomo.ieee.org
[mailto:owner-stds-80220-requirements@majordomo.ieee.org]On Behalf Of
Jerry1upton@aol.com
Sent: 11 September 2003 18:25
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
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