| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
-----Original Message-----
From: Jim O'Connor [mailto:joconnor@ipwireless.com]
Sent:
Friday, August 29, 2003 12:23 PM
To:
stds-80220-requirements@ieee.org
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
> > >
>
> > > >
> >
>