Re: stds-80220-requirements: comments on rev5 - Channel bandwidth resolution
I very much support David Trinkwon, Jerry Upton et-al and not let this
standard get killed by other more advanced standards before it gets out of
the gate. I see no serious down side for including 10 and 20MHz channels
in the Requirements at this stage of the game. We must make sure 802.20 is
significantly better than others.
Chris Bussey
BCSI
----- Original Message -----
From: "Jim O'Connor" <joconnor@ipwireless.com>
To: <stds-80220-requirements@ieee.org>
Sent: Friday, August 29, 2003 12:22 PM
Subject: Re: stds-80220-requirements: comments on rev5 - Channel bandwidth
resolution
>
> Stewart,
>
> Lets see some more data points before we come to any conclusions on this
> point. The 3 countries that I mentioned, Canada, Mexico and the US all
have
> bands below 3.5 GHz with fixed/portable/mobile spectrum supporting very
wide
> channel and deployment bandwidths. Systems capable of mobile operation
with
> channel bandwidths > 5 Mhz have been deployed in Mexico and the US
already.
> These allocations may or may not be reflected in ITU allocations, I'm not
> sure the ITU is driving the shift in usage of the 2.5 GHz band from video
to
> fixed/portable/mobile data, these seem to be market-driven in the
individual
> countries mentioned.
>
> Best Regards,
> Jim O'Connor
> IPWireless, Inc.
>
> ----- Original Message -----
> From: "Wallace, Stewart J" <Stewart.J.Wallace@team.telstra.com>
> To: "Jim O'Connor" <joconnor@ipwireless.com>;
> <stds-80220-requirements@ieee.org>
> Sent: Thursday, August 28, 2003 11:58 PM
> Subject: RE: stds-80220-requirements: comments on rev5 - Channel bandwidth
> resolution
>
>
> Folks,
>
> Might I suggest that we try to keep a global perspective on the matter of
> channel bandwidth, and remember that we need to accommodate current radio
> spectrum structures established by many other national administrations -
> focusing, naturally, on the bands allocated by ITU-R to the Mobile Service
> below 3.5GHz.
>
> As I have highlighted before, national administrations are typically loath
> to restructure current band plans unless they have a VERY strong national
> imperative, since it is a complex regulatory matter involving
consideration
> of transitional arrangements for incumbent users amongst other
> considerations.
>
> Therefore, I see no "realistic" alternative for 802.20 at this stage but
to
> adopt a minimum bandwidth requirement of 1.25MHz and 5 MHz - with the
wider
> bandwidths to be noted as future desirable options subject to the
> availability of suitably accommodating band plans. Otherwise, you will
find
> yourselves specifiying something that can only be deployed in a very very
> limited number of countries and few circumstances - and that will surely
> nobble the whole idea, giving competitive technologies plenty of time to
> overtake.
>
> regards
>
> Stewart J Wallace
> Technical Regulatory Manager
> Radiocommunications & Wireless Networks
> Telstra Regulatory Directorate
> Tel: (+61 3) 8627 8053
> Fax: (+61 3) 9614 0670
>
>
> -----Original Message-----
> From: Jim O'Connor [mailto:joconnor@ipwireless.com]
> Sent: Friday, 29 August 2003 4:58 PM
> 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
> > > > >
> > > > >
> > >
> >
>