RE: stds-80220-requirements: comments on rev5 - Channel bandwidth resolution
Jim,
You've made a fundamental assertion that I question. It is
that 802.20 has to move to higher channel bandwidths in order to achieve
better performance that the evolving 3G standards that occupy 1.25 and
5 MHz channel bandwidths. Since the 3G standards must maintain backward
compatibility with their current implementations, their future evolution
is more constrained than a new 802.20 standard. So, even if they
are improving (which I hope they would) I don't see that fact as forcing us
to higher channel bandwidths. Secondly, none of the proponents of the
higher channel bandwidth systems have addressed the fact that there are
far fewer opportunities for deploying such systems in mobile spectrum below
3.5 GHz? The market for 20 MHz systems below 3.5 GHz is far smaller than
the market for systems with 1.25 MHz bandwidth. Finally, and this is a
point
that was made on today's conference call, a 20 MHz system does not
necessarily
provide higher data rates on a per user basis than systems with narrower
bandwidth. A good example of this is WCDMA (occupying 5 MHz bandwidth)
versus
cdma2000 (with 3 x 1.25 MHz carriers). I believe (someone can correct me if
I'm
wrong) that the industry has accepted that these two standards offer
equivalent
performance from the end users' perspective. Frankly, I don't find the
"we need higher bandwidths to compete with evolving 3G systems" to be a very
compelling argument. I would like to hear what are the specific market
requirements that you believe necessarily drive us to the higher bandwidths.
Best regards,
Joanne
-----Original Message-----
From: owner-stds-80220-requirements@majordomo.ieee.org
[mailto:owner-stds-80220-requirements@majordomo.ieee.org]On Behalf Of
Jim O'Connor
Sent: Thursday, August 28, 2003 7:37 PM
To: stds-80220-requirements@ieee.org
Subject: Re: stds-80220-requirements: comments on rev5 - Channel
bandwidth resolution
Generally I favor including the wider bandwidths mentioned (10 MHz, 20 MHz),
in order to allow 802.20 to be differentiated against the current
"narrowband" 3G solutions which address only 1.25 Mhz or 5 MHz per
transceiver. As was pointed out earlier today by Steve Crowley, the
current 3G solutions are not standing still and are in fact improving with
new features and capabilities on a regular basis, so if 802.20 is to compete
effectively with the established systems, especially in their state of
development 2 years from now when .20 product presumably hits the street, it
would seem that .20 needs to offer something novel which is not
contemplated by the enhancements to the existing standards. By addressing
larger bandwidths than the current systems do, thereby enabling better
operator economics (more MHz addressed per transceiver), 802.20 would offer
a compelling alternative for the operators to consider.
Regards,
Jim O'Connor
IPWireless, Inc.
----- Original Message -----
From: <Jerry1upton@aol.com>
To: <scrowley@attglobal.net>; <trinkwon@compuserve.com>;
<M.Klerer@flarion.com>; <stds-80220-requirements@ieee.org>
Sent: Thursday, August 28, 2003 11:36 AM
Subject: Re: stds-80220-requirements: comments on rev5 - Channel bandwidth
resolution
>
> I fully support the proposals from Steve Crowley, David Trinkwon, Mark
Cudak, Fujio Watanabe, and Daichi Imamura. We should include 10 and 20MHz
channels in the Requirements and use for evaluation purposes.
> Regards,
> Jerry Upton
>
> In a message dated 8/28/2003 9:33:49 AM Eastern Daylight Time,
scrowley@attglobal.net writes:
>
> > I agree with David for the reasons he states. I support the proposals
for channel bandwidths from 1.25 Mz to 20 MHz in the requirements.
> >
> > Regarding concatenation of smaller-bandwidth channels, I note that an
operator might not want to be required to implement "wider channel bandwidth
. . . supported by deploying (N) x (Basic Bandwidth)", due to reduced
capacity caused by (depending on the technology used) guard bands between
the concatenated channels, and redundant common channel structures in each
of the smaller channels, such as for pilot signals. Deploying 10 MHz and 20
MHz bandwidths conguously allows reduction of both inefficiencies, resulting
in more data available to the user.
> >
> > I would also like to add that 3G technologies in 3GPP and 3GPP2 continue
to evolve and may soon exceed the assumed 1.25 MHz performance
characteristics for the MBWA system that were used for the PAR and Five
Criteria. This could result in the MBWA system specification failing to meet
the tests of Broad Market Potential and of Economic Feasibility in the Five
Criteria, resulting in lack of approval by RevCom. Thus, I believe we need
to look at the performance improvements that can be had through the use of
wider bandwidths.
> > As an example, consider 3GPP2's 1xEV-DO (also known as HRPD, HDR,
IS-856, and C.S0024). The next revision of that system, Revision A, is now
under development in 3GPP2 and is scheduled for completion in December 2003.
There are several proposals to improve that 1.25 MHz system which include
the following specifications:
> > Peak downlink data rates to 3.072 Mbps
> > Peak uplink data rates to 4 Mbps
> > Uplink capacity comparable to downlink capacity resulting in a symetric
system
> > Latencies on the order of 10 ms
> >
> > (See, e.g., 3GPP2 contributions C30-20030414-067 (QUALCOMM MAC
proposal), C30-20030414-068 (QUALCOMM Forward-link proposal), and
C30-DOAH-20030428-015 (Lucent reverse-link proposal).)
> >
> > After Revision A is completed, one can expect consideration to begin of
the next version of 1xEV-DO (Release B), with further improvements.
> >
> > Best regards,
> >
> > Steve Crowley
> > DoCoMo USA Labs
> >
> > -------
> > 1201 Pennsylvania Ave., N.W. Suite 300
> > Washington, D.C. 20004
> >
> > Tel. +1-202-544-5400
> > Fax +1-202-478-1763
> >
> > E-mail scrowley@attglobal.net
> >
> > -----Original Message-----
> > From: owner-stds-80220-requirements@majordomo.ieee.org
[mailto:owner-stds-80220-requirements@majordomo.ieee.org]On Behalf Of David
Trinkwon
> > Sent: Thursday, August 28, 2003 4:04 AM
> > To: Klerer Mark; stds-80220-requirements@ieee.org
> > Subject: RE: stds-80220-requirements: comments on rev5 - Channel
bandwidth resolution
> >
> >
> > With respect, Mark, the MMDS band is already available (for mobile) in
the US and gross bandwidths of several contiguous 6MHz "channels" are
already in the hands of potential operators (although there is still a lot
of commercial and regulatory uncertainty about the actual band plan and
service rules pending FCC resolution of the WCAI restructuring proposals).
Certainly (multiples of) 2 x 10MHz blocks" are available and probably 2 x
20MHz per operator in most markets. To deny these capabilities is imposing
an unfair restriction on would-be competitors to the established mobile
operators in the PCS and cellular bands.
> >
> > Regarding 802.16e, the main distinguishing factors were the targeted
mobility speeds (250km/h for 802.20) and the dependence on an 802.16 MAC and
existing PHYs (802.16e is intended to be incremental on 802.16a whereas
802.20 is a clean sheet - as you rightly insisted many times). If the
(current) membership of 802.20 believes that 10 and 20MHz channels should be
allowed for then that is their prerogative.
> >
> > The discussion on multi-channel did not (mean to ) say 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." The word COULD
rather than SHOULD is applicable, and there are as many technological /
economic arguments for it as against it, especially when combined with
adaptive beamforming and other space / time / frequency diversity
techniques. It should not be precluded form appropriate evaluation if
someone submits such a PHY proposal in due course.
> >
> > I propose that the 1.25, 5, 10 and 20MHz proposals should stand.
> >
> >
> > 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 Klerer
Mark
> > Sent: 28 August 2003 03:48
> > To: 'stds-80220-requirements@ieee.org'
> > 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:
> >
> > a. 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.
> > b. 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
> >
> >