-----Original Message-----
From: Klerer Mark
[mailto:M.Klerer@flarion.com]
Sent: Thursday, 28 August 2003 12:44 PM
To: 'Fujio Watanabe'; David
Trinkwon; Mark Cudak; stds-80220-requirements@ieee.org
Cc: Gal, Dan (Dan); 'Joanne Wilson';
Wallace, Stewart J; Fan John
Subject: RE:
stds-80220-requirements: comments on rev5 - Channel bandwidth resolution
With respect to the channel bandwidth issue I would like to review some
of the history in definition of the charter of the 802.20 project and why the
bandwidth "examples" were chosen, address some of the concerns about
future bandwidth extensions that I believe are based on misunderstandings and propose a way
forward.
1. Project History and Reasons for Channel Bandwidth Selection
a. Timeliness: The project and its timeline were defined to allow for
early deployment of real world systems in licensed spectrum below 3.5 GHz and
available for mobile services, rather then as a long term study item. This
requires that the specification address channel bandwidth that are currently
available. This was discussed extensively and the conclusion that waiting for
spectrum reallocation was not consistent with these goals. Future work could
address broader channels when these become available.
b. Economic Viability: The economic viability of the project, for both
service providers and equipment vendors, was predicated on it being deployable
in the near term in existing spectrum allocation and with channel bandwidth
that service providers would be willing to allocate to data services. This
would be feasible if the new system is co-deployable with existing cellular
mobile systems. This was documented in http://ieee802.org/20/SG_Docs/802m_ecsg-02-08.pdf.
which was included as an attachment to the PAR submission to the 802 Executive
Committee (see excerpt below).
Spectrum:
The AI should be designed for deployment within existing and
future licensed spectrum below 3.5 GHz. The MBWA system frequency plan should
include both paired and unpaired channel plans with multiple bandwidths, e.g.,
1.25 or 5 MHz, to allow co-deployment with existing cellular systems. Receiver
sensitivity, blocking and selectivity specifications should be consistent with
best commercial practice for mobile wide-area terminals.
c. Differentiation from 802.16e: In order to get the executive
committee and NesCom to approve both P802.16e and P802.20 extensive discussions
were held and agreed too. Differences between the two projects and their
approach to the market were identified and documented 802.16sgm-02/16.
One of the differences was the 802.16e would concentrate on channels with a
bandwidth greater than 5MHz, reflecting its legacy of evolving off Fixed BWA;
and that 802.20 would concentrate (at least initially) on bandwidth
below ~5MHz reflecting the goals stated above including the capability
to coexist in existing cellular deployments. Actually this is also consistent
with the approach in ITU-R for systems beyond IMT-2000, where the higher
channel bandwidth first appear for technologies supporting lower degrees of
mobility.
2. Support of Multiple Channel Bandwidth: As a result of the
granularity discussion it seems the impression has been created that wider
channel bandwidth would be supported by deploying (N) x (Basic Bandwidth) in
order to fill the total channel BW of the wider channel. I agree with Mark
Cudak that that is not desirable (I actually believe that most people that
discussed this did not have that intention). Instead the 802.20 (family of)
standard(s) should support that wider channel BW as a single fat pipe. I see
the advantage of these "fat-pipes" being multiples of some basic
bandwidth in facilitating deployment by displacing an integral number of these
"skinnier-pipes".
3. A Proposed Way Forward:
I would like to propose that 802.20 start the first set of requirements
with bandwidth of 1.25 and 5 MHz, and then developing requirements for greater
than 5 MHz, e.g. 20MHz. This rollout of successive requirements need not be
"calendar based" but can be done as soon as the technological and
business needs are understood - with some more precission then just "wider
is better".
The rationale for the proposal is:
1. This
allows a first standard to go out that accommodates existing well defined and
understood markets; i.e. markets based on the needs filled in the wired world
by DSL and cable modem services.
2. In
order to develop the wider channel bandwidth systems I think we need additional
requirements work to determine whether the wider channels are required to
increase the number of users that can be supported in a cell or whether these
are required to accommodate new services that require more bandwidth per user.
I believe that such concerns would have significant impact on how these wider
channel systems are designed. To my knowledge there is no good existing base at
this time on which to base such requirements. Experience of individualized wired
wide-area wide-band services (beyond DSL/Cable rates) (such as video on demand
as compared to pay-per-view) have all indicated that commercially these
services have not been viable.
The above discussion should also make it clear that we will need to
keep an open mind on how the PHY and MAC for the wider channel systems would be
optimized for best performance.
Finally, in the debate of whether 1.25 Mhz channels with 3-4 Mbps peak
are considered broadband, I would like to point out that in the real wireless
world at least one prominent international cellular service provider defines
384Kbps DL and 64Kbps UL as broadband capability.
Mark Klerer