-----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