Re: stds-80220-requirements: comments on rev5 - Channel bandwidth resolution
Joanne,
I think you misinterpreted my comments. Sure, 802.20 could probably squeeze
some extra performance out of 1.25 or 5 MHz (I'll defer to PHY/MAC experts
on this, I'm sure someone will disagree) vis a vis an existing standard
because as you say you are starting with a clean slate and would expect to
optimize some aspects of the PHY/MAC which may not be available to the
existing standards due to backwards compatibility issues, but the same laws
of physics apply to everyone and 802.20 does not have an exclusive franchise
on smart antennas, packet data, MIMO or other enhancements. So I'm not
sure that aspect (newness) alone automatically ensures 802.20 is a more
compelling solution, especially as the existing standards have other
advantages such as economies of scale, excellent support for voice,
backwards compatibility to existing networks, etc.. My point is that with
802.20 there is an opportunity to address a market need that is not
currently addressed by the existing standards and that is to offer higher
aggregate data rates per unit of capex (transceiver/antenna/site/etc) with
greater bandwidth devices, all else being more or less equal (antenna
schemes, modulation, power levels, power control, etc) in apples to apples
comparisons.
Regarding the spectrum issue, I believe a review of the spectrum ownership
of the 2.5 GHz band in the US, Canada, Mexico and other countries will show
that operators tend to hold extremely large allocations, up to 186 MHz in
the US, in Canada 96 MHz if my memory is correct. The smallest allocation
block in the US is 24 Mhz, and an operator can control all of the blocks in
a market. To efficiently put that much spectrum to work, as an operator I'd
rather be deploying 10 or 20 MHz per sector as opposed to 1.25 MHz.
Best Regards,
Jim O'Connor
IPWireless, Inc.
----- Original Message -----
From: "Joanne Wilson" <joanne@arraycomm.com>
To: "Jim O'Connor" <joconnor@ipwireless.com>;
<stds-80220-requirements@ieee.org>
Sent: Thursday, August 28, 2003 7:56 PM
Subject: 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
> > >
> > >
>