Re: stds-80220-requirements: comments on rev5 - Channel bandwidth resolution
Reza,
Actually I don't have any trouble with these distinctions, but if reading my
email left you with that impression I apologize, I shall try to be more
clear in future emails.
Regards,
Jim O'Connor
IPWireless, Inc.
----- Original Message -----
From: "Reza Arefi" <reza.arefi@ieee.org>
To: "'Jim O'Connor'" <joconnor@ipwireless.com>;
<stds-80220-requirements@ieee.org>
Sent: Thursday, August 28, 2003 10:17 PM
Subject: RE: stds-80220-requirements: comments on rev5 - Channel bandwidth
resolution
> I see that there is still confusion about the "deployment bandwidth"
versus
> "carrier bandwidth".
>
> Deployment bandwidth, or the amount of spectrum used at a sector (or cell,
> if omni), in form of an integer multiple of carrier bandwidth, is
determined
> by the demand in that sector and is limited by the amount of spectrum the
> operator is licensed to use in that geographical area. Clearly, deployment
> bandwidth is an operator/regulatory issue, not an standard issue. Carrier
> bandwidth, however, is a technology issue and varies from technology to
> technology. Examples are 1.25 MHz for cdma2000 and 5 MHz for WCDMA. Given
a
> certain mobile channel, some technologies perform better with wider
> channels, some with narrower channels. We don't know what technology, or
> technologies, 802.20 will be based on. So, it would be unwise to impose a
> certain carrier bandwidth onto the future standard at this point in time.
>
> I support Dan's position of sticking to the PAR language. The only numbers
> mentioned in the PAR (1.25 and 5 MHz) are said as examples (so other
> bandwidths are not excluded) and they fit to most existing band
allocations
> below 3.5 GHz.
> Regards,
> Reza
>
> -----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: Friday, August 29, 2003 1:14 AM
> To: stds-80220-requirements@ieee.org
> Subject: 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
> > > >
> > > >
> >
>