Re: stds-80220-requirements: comments on rev5 - Channel bandwidth resolution
Group,
excuse my mistake below, replace 15.5 MHz with 16.5 MHz.
Regards,
Jim O'Connor
----- Original Message -----
From: "Jim O'Connor" <joconnor@ipwireless.com>
To: <stds-80220-requirements@ieee.org>
Sent: Friday, August 29, 2003 12:58 AM
Subject: Re: stds-80220-requirements: comments on rev5 - Channel bandwidth
resolution
> Joanne,
>
> With all due respect I could not disagree with you more on everything you
> said below. I was intimately involved with the creation of the White
> Paper band plan submitted by the WCA/NIA/CTN coalition which led to the
> recent MMDS NPRM. Per the plan, each existing 24 MHz channel block ( 4 X
6
> MHz, interleaved i.e. not contiguous, except for the H group which is only
3
> X 6 MHz) would map to a contiguous 15.5 MHz block in either the LBS or the
> UBS, as well as mapping to a 6 MHz channel in the HPO midband segment, and
> 750 KHz of spectrum in each of the transition bands surrounding the HPO.
> The 4-channel block is the base allocation for licensing purposes, so
there
> is no mapping of existing licenses to only a 5.5 MHz channel as you
suggest.
> The White Paper proposal is all about changing the regulations so that
> 2-way deployments can go forward, not taking spectrum from the current
> licensees.
>
> I fail to see why an operator would willingly "disaggregate" their
spectrum
> and facillitate competition for themselves, please elaborate on this
point.
> This is the first time I have heard that it is a disadvantage to control
> more spectrum as opposed to less.
>
> 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 10:29 PM
> Subject: RE: stds-80220-requirements: comments on rev5 - Channel bandwidth
> resolution
>
>
> > Jim,
> >
> > Please take another look at the WCA proposal for a new 2.5 GHz band
plan.
> > The bandwidth proposed for the flexible use Lower Band Segment (LBS) and
> > Upper
> > Band Segment (UBS) that would be for mobile use are 5.5MHz. Yes,
> different
> > operators may have purchased or leased multiple licenses and aggregated
> the
> > spectrum,
> > but from a regulatory perspective, each license would be 5.5 MHz. Given
> > that operators
> > have the right to disaggregate their spectrum, larger bandwidth systems
of
> > greater than 5 MHz are likely to be less attractive than those with
> smaller
> > bandwidths because they
> > limit the operators flexibility to obtain/use only the amount of
spectrum
> > they need
> > on a per market basis.
> >
> > 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: 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
> > > > >
> > > > >
> > >
> >
>