RE: stds-80220-requirements: comments on rev5 - Channel bandwidth resolution
Jim,
We're not disagreeing on the facts. Yes, existing MMDS operators have sets
of channels that are not contiguous. The WCA Plan would both change the
rules and
redistribute the licenses so that operators would end up with contiguous
blocks of
channels, each of which is 5.5 MHz bandwidth. The WCA is looking for the
same basic rules in the UBS/LBS segment as in the PCS band, which is part
of the Commercial Mobile Radio Service (CMRS). As I said, the operators
typically have the right to aggregate/disaggregate their spectrum. Why
would anyone do that? What if, the value of the spectrum was such that
they could make a huge profit by selling it. Frankly, with the same rules
as the PCS band, I wouldn't be surprised if the 2.5 GHz spectrum become much
more valuable than they had been previously. Look at how much the Nextwave
licenses were reauctioned for before the courts made the FCC give them back.
If
an operator could meet their market needs with less spectrum and sell off
their remainder for a huge profit, why wouldn't they do it? Under your
proposal, they be less able to do so.
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 2:58 AM
To: stds-80220-requirements@ieee.org
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
> > > >
> > > >
> >
>