FW: stds-80220-requirements: comments on rev5 - Channel bandwidth resolution
This message is forwarded on behalf of what was a non-subscriber. Aditya is now subscribed to the list.
----- Original Message -----
From: "Aditya Agrawal" <aagrawal@fma.fujitsu.com>
To: <stds-80220-requirements@ieee.org>
Cc: <fwatanabe@ieee.org>; <trinkwon@compuserve.com>;
<Mark.Cudak@motorola.com>
Sent: Monday, August 25, 2003 4:08 PM
Subject: Re: stds-80220-requirements: comments on rev5 - Channel bandwidth
resolution
> I support Fujio Watanabe's comments. It makes sense to define 10MHz and
> 20MHz
> channels for evaluation purposes in addition to 5MHz channels since
broader
> channels is what will add value.
>
> Best Regards,
>
> Aditya Agrawal
> Fujitsu Microelectronics America
>
> ----- Original Message -----
> From: "Fujio Watanabe" <fwatanabe@ieee.org>
> To: "David Trinkwon" <trinkwon@compuserve.com>; "Mark Cudak"
> <Mark.Cudak@motorola.com>; <stds-80220-requirements@ieee.org>
> Cc: "Gal, Dan (Dan)" <dgal@lucent.com>; "'Joanne Wilson'"
> <joanne@arraycomm.com>; "Wallace, Stewart J"
> <Stewart.J.Wallace@team.telstra.com>; <J.Fan@flarion.com>
> Sent: Sunday, August 24, 2003 4:01 PM
> Subject: Re: stds-80220-requirements: comments on rev5 - Channel bandwidth
> resolution
>
>
> > I support Mark Cudak and David Trinkwon's comments.
> >
> > Since a broad bandwidth is the current trend of mobile communications,
> > a broad channel with a bandwidth as that of used in 802.11, i.e.,
> > 20MHz
> should
> > be one of the concrete value. The 100MHz channel is too broad to
> > discuss
> at
> > the moment. Accordingly, I would like to work on the solutions of the
> 802.11
> > bandwidth.
> >
> > Now, let's review the comments on "available" bandwidth segmentation
> > of licensed bands below 3.5GHz that has been discussed earlier. People
> > from different countries mentioned the specific frequency allocation
> > based on that country's regulations. As we all know, most countries
> > have different frequency allocations for mobile communications before
> > the universal frequency band was allocated to IMT-2000 systems.
> > However, since the
> 802.20
> > is going to develop an international standard, I don't think it is
> rationale
> > to create a standard that will only meet one specific country's
> regulation.
> > For example N * 1KHz may cover regulations of all countries, however,
> > this will be meaningless and out of our interest.
> >
> > Accordingly, as I proposed in my earlier comments, we need to come up
> > with concrete values that are independent of any country regulations.
> > The
> values
> > should then be used for an evaluation purpose. If we like to apply the
> > standard to one or more specific countries to meet their regulation
> > requirements, we might need to establish special Task Groups like TGh
> > and TGj in the IEEE802.11 in the future.
> >
> > Based on the above, I support Mark's proposal to define 1.25 MHz,
> > 2.5MHz, 5MHz, 10MHz, and 20MHz bandwidth for the evaluation purpose.
> >
> > Best Regards,
> >
> > Fujio Watanabe
> > DoCoMo USA Labs
> >
> > ----- Original Message -----
> > From: "David Trinkwon" <trinkwon@compuserve.com>
> > To: "Mark Cudak" <Mark.Cudak@motorola.com>;
> > <stds-80220-requirements@ieee.org>
> > Cc: "Gal, Dan (Dan)" <dgal@lucent.com>; "'Joanne Wilson'"
> > <joanne@arraycomm.com>; "Wallace, Stewart J"
> > <Stewart.J.Wallace@team.telstra.com>; <J.Fan@flarion.com>;
> > <fwatanabe@ieee.org>
> > Sent: Saturday, August 23, 2003 11:58 PM
> > Subject: RE: stds-80220-requirements: comments on rev5 - Channel
> > bandwidth resolution
> >
> >
> > > I agree with Mark's comments and proposal. These can be stated as
> > "examples"
> > > or "targets".
> > >
> > > -----Original Message-----
> > > From: owner-stds-80220-requirements@majordomo.ieee.org
> > > [mailto:owner-stds-80220-requirements@majordomo.ieee.org]On Behalf
> > > Of Mark Cudak
> > > Sent: 22 August 2003 22:32
> > > To: stds-80220-requirements@ieee.org
> > > Cc: Gal, Dan (Dan); 'Joanne Wilson'; Wallace, Stewart J;
> > > J.Fan@flarion.com; fwatanabe@ieee.org
> > > Subject: Re: stds-80220-requirements: comments on rev5 - Channel
> > > bandwidth resolution
> > >
> > >
> > >
> > >
> > > All:
> > >
> > > After listening to the various arguments put forward regarding the
> > > channel bandwidth requirements, I would like to express support for
> > > Fujio Watanabe's original position that we consider broader
> > > bandwidths of 5 MHz and beyond.
> > >
> > > Although the 1.25 MHz may be appropriate for some existing spectrum
> > > allocations, I do not favor concatenating multiple 1.25 MHz
> > > solutions to form wider bandwidth solutions (especially for
> > > bandwidths above 5 MHz, where an air-interface designed to occupy
> > > the whole bandwidth may be more efficient).
> > >
> > > At this point, I don't want to close the door on 20 MHz solutions.
> > > Nor do I want to relegate them to be multiple carrier versions of a
> > > 1st generation 1.25 MHz 802.20 standard. I fear that expressing the
> > > bandwidth as a multiple of 1.25 or 2.5 MHz will later be interpreted
> > > as a consensus on the concept of concatenating multiple 1.25 MHz
> > > carriers. Alternatively, this expression may be falsely
> > > interpreted to imply that all proposals should scale in
> > > bandwidth having operating modes which support Nx1.25 MHz
> > > bandwidths. As a result, I would much prefer that we
> > > explicitly state the bandwidths we are considering in the
> > > requirements as being 1.25 MHz, 2.5 MHz, 5 MHz, 10 MHz, 20
> > > MHz etc. I believe that in this way we will not restrict
> > > the ultimate solution and avoid misunderstandings in the
> > > future.
> > >
> > > Best Regards
> > >
> > > Mark Cudak
> > > Motorola
> > >
> > >
> > > Gal, Dan (Dan) said the following on 8/21/2003 4:10 PM:
> > >
> > > > Joanne and Stewart,
> > > >
> > > > Thank you both for your scholarly comments. May I also suggest
> > > > that these comments be reflected in all the appropriate places in
> > > > the System Requirements document, particularly sections 4.1.4 and
> > > > 4.3 which are quite critical for the subsequent 802.20 standard
> > > > development work.
> > > >
> > > > Dan
> > > >
> > > >
> > > > -----Original Message-----
> > > > *From:* Joanne Wilson [mailto:joanne@arraycomm.com]
> > > > *Sent:* Wednesday, August 20, 2003 8:40 PM
> > > > *To:* Wallace, Stewart J; Gal, Dan (Dan)
> > > > *Cc:* stds-80220-requirements@ieee.org
> > > > *Subject:* RE: stds-80220-requirements: comments on rev5 - Channel
> > > > bandwidth resolution
> > > >
> > > > Stewart,
> > > >
> > > > I am in 100% agreement with all of your comments!
> > > >
> > > > Best regards,
> > > >
> > > > Joanne
> > > >
> > > > -----Original Message-----
> > > > *From:* Wallace, Stewart J
> > > > [mailto:Stewart.J.Wallace@team.telstra.com]
> > > > *Sent:* Wednesday, August 20, 2003 8:08 PM
> > > > *To:* Joanne Wilson; Gal, Dan (Dan)
> > > > *Cc:* stds-80220-requirements@ieee.org
> > > > *Subject:* RE: stds-80220-requirements: comments on rev5 -
> > > > Channel bandwidth resolution
> > > >
> > > > Joanne,
> > > >
> > > > Yes - that's quite a good summary of the situation - I am
> > > > directly involved in the ongoing ITU-R study groups, and
also
> > > > participate as a part of the Australian Delegation to the
> > > > WRC's (incl the WRC-03 just finished). Services (capital
'S')
> > > > refers to ITU-R allocations - but, beneath that global
> > > > structure, national administrations can make sub-allocations
> > > > to "applications" (eg.within the MS we have: GSM, IS-95
CDMA,
> > > > UMTS, cdma2000, etc.). Furthermore, national
administrations
> > > > make "assignments" to specific operators/users (or classes
of
> > > > users) evidenced by the issue of "licences" to those
> > > > operators/users.
> > > >
> > > > Minor note - in Australia, we refer to the "unlicensed"
> > > > applications as operating under a "Class Licence" which
> > > > specifies generic technical characteristics, limits, etc.
for
> > > > operation in the relevant 'public park' spectrum
allocations -
> > > > eg. RLANs, cordless phones, garage door openers, model
> > > > airplanes, ISM applications, etc.. Other spectrum bands are
> > > > subject to explicit licensing of devices and/or operators.
> > > >
> > > > Moving away from the detailed terminology, my original
> > > > comments were simply aimed at ensuring that 802.20 did not
> > > > unduly constrain itself as an emerging commercial technology
> > > > by somewhat hastily mandating a 'wide' spectral occupancy
> > > > granularity (> 1.25MHz) that had the effect of excluding it
> > > > from many of the current national band structures. As I
> > > > mentioned in an earlier e-mail, national regulators are
> > > > typically reticent (or at least extremely cautious) to
> > > > redesign band plans, unless there is overwhelming need,
since
> > > > it is a complex regulatory task and it needs to be done
> > > > carefully while bearing in mind lingering incumbent users
who
> > > > often cannot be readily displaced due to possible negative
> > > > community impact. See my earlier e-mail response to Dan Gal
&
> > > > the group.
> > > >
> > > > One further point, while I made reference to the Australian
> > > > 3.4 GHz band, this was only because someone earlier
(~Mar'03?)
> > > > suggested that it was a candidate band for 802.20 and I felt
> > > > it useful to remind ourselves of the implications on
spectral
> > > > granularity of such a vision. However, it seems to me that
> > > > 802.20 is primarily a mobile application, and therefore more
> > > > likely to be deployed in the MS allocations: eg. 800, 900,
> > > > 1400/1500, 1700/1800/1900, 2100, 2500 MHz bands.
> > > > But, significantly, most of them are based on structures
much
> > > > more amenable to a 1.25MHz granularity, rather than a wider
> > > > raster. Thus, I strongly support a minimum granularity of
> > > > 1.25MHz (but not larger) for 802.20.
> > > >
> > > > In regard to the 3.4 GHz band, in actuality it may be that
> > > > 802.16 is a stronger candidate for that particular band
since
> > > > it is based on a 3.5MHz channel plan - and the 3.4 GHz band
is
> > > > currently designated for Fixed Services (only - as opposed
to
> > > > MS) in Region 3, so we may confront certain global
regulatory
> > > > difficulties for 802.20 in this band, especially as it is
also
> > > > variously designated for Fixed Satellite Services.
> > > >
> > > > In summary, I am suggesting that 802.20 be based on a
minimum
> > > > spectral granularity of 1.25MHz - and, yes, that may lead to
> > > > some extra 'guard band', but at least we foster greater
> > > > commercial deployment with minimal constraints. Then, we
> > > > leave it up to national administrations to decide if they
wish
> > > > to undertake band structure redesigns to squeeze a bit more
> > > > utility out of particular domestic plans, by minimising
> > > > unnecessary guard bands.
> > > >
> > > > I hope this assists in moving toward consensus.
> > > >
> > > > 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:* Joanne Wilson [mailto:joanne@arraycomm.com]
> > > > *Sent:* Thursday, 21 August 2003 7:31 AM
> > > > *To:* Gal, Dan (Dan); David Trinkwon; 'Michael
Youssefmir'
> > > > *Cc:* 'Fujio Watanabe'; Klerer Mark; Wallace, Stewart J;
> > > > stds-80220-requirements@ieee.org; Bharatula, Ganesh
> > > > *Subject:* RE: stds-80220-requirements: comments on
rev5 -
> > > > Channel bandwidth resolution
> > > >
> > > > Dan,
> > > >
> > > > It would be helpful if we were somewhat strict in our
> > > > terminology. At the international (i.e. ITU, WRC)
level,
> > > > bands are allocated to different Services
(capitalization
> > > > here is important). Those Services include the MOBILE
> > > > Service (MS), MOBILE SATELLITE Service (MSS), FIXED
> > > > Service (FS), BROADCAST Service (BS), BROADCAST
> > > > SATELLITE Service (BSS), and others. They are
allocated
> > > > on a PRIMARY or Secondary basis. (Again, capitalization
> > > > here is important.) None of this has anything to do
with
> > > > licenses. This is specifically related to the
allocations
> > > > within the International Radio Regulations and such
> > > > decisions are made at World Radiocommunications
> Conferences.
> > > >
> > > > Administrations make national allocations within the
> > > > context of the International Radio Regulations. They
can
> > > > choose
> > > > to allocate (within their jurisdiction) MS spectrum for
> > > > particular uses (i.e. services with a small "s"),
> > > > including Public Safety, Commercial Mobile Radio, etc.,
> > > > and determine (authorize) who gets to use that spectrum
or
> > > > how the spectrum is to be used . Spectrum allocated
> > > > (nationally) for exclusive use of a single party
> > > > (operator) is LICENSED (capitalize here for emphasis
> > > > only). Those licenses are assigned by some mechanism --
> > > > the US uses auctions, other administrations use
> > > > that or other techniques. Or, as in the RLAN situation,
> > > > they will allow equipment that meets a certain set of
> > > > technical rules to share the band with no authorization
> > > > (licensing) of the user required. In the US this is
> > > > referred to as an Unlicensed service and it is called
> > > > License-Exempt in other markets.
> > > >
> > > > I went through that primer to make the following point.
> > > > 1) The PAR said "licensed" to mean systems that are
> > > > operate in the band exclusively, not shared with other
> > systems
> > > > as in the RLAN case. This was to distinguish
> > > > 802.20 systems from RLANS and other systems that are
> > > > Unlicensed
> > > > and operate in a band on a shared basis.
> > > > 2) The PAR didn't address whether the entity with
the
> > > > license to operate the 802.20 system was an "existing"
or
> > > > "new" operator. Frankly, in the context of
> > > > standards development, that's totally irrelevant.
> > > > 3) The PAR said allocated to the Mobile Service
> > > > because MBWA systems would meet the definition of a
Mobile
> > > > system and, from a regulatory perspective, and
> > > > could only be operated within those allocations.
> > > > Identifying the MS
> > > > allows one to identify blocks of spectrum
where
> > > > MBWA systems could be authorized to operate. Specific
> > > > bands are
> > > > an issue for national regulators, not the ITU.
> > > > 4) The PAR did not take a position on whether the
> > > > spectrum had previously been allocated to the MS or not,
> > > > because
> > > > again that is irrelevant.
> > > >
> > > > It's an interesting and, frankly, unconventional
> > > > explanation of "existing" as meaning "allocated and
> > > > available". However,
> > > > under that definition, I don't know what you mean by
when
> > > > you say, "1.25 MHz and 5 MHz channels exist". Did you
> > > > mean that in some countries there is MS spectrum that
> > > > is "allocated and available" for deploying a system with
> > > > 1.25 MHz or 5 MHz channel bandwidth? If that's what you
> > > > meant, then I guess I would agree although I'm not sure
> > > > what you mean by "available". Regarding the problem of
> > > > wasting .5 MHz of spectrum on internal guardbands,
that's
> > > > not at all unusual and is often required for two systems
> > > > to operate effectively in adjacent bands -- even if they
> > > > are both FDD systems. I note that with 1.25
MHz/carrier,
> > > > cdma2000 operators typically deploy only 3 carriers, not
> > > > 4, within a 5 MHz allocation. They are in fact choosing
> > > > to have 625kHz guardbands on each side of their band.
So,
> > > > using 2.5 MHz of spectrum for an MBWA system within a
3.5
> > > > MHz license and "wasting" 1 MHz of spectrum on internal
> > > > guardbands fits with standard industry practice.
> > > >
> > > > Best regards,
> > > >
> > > > Joanne
> > > >
> > > >
> > > > -----Original Message-----
> > > > *From:* Gal, Dan (Dan) [mailto:dgal@lucent.com]
> > > > *Sent:* Wednesday, August 20, 2003 2:39 PM
> > > > *To:* 'Joanne Wilson'; David Trinkwon; Gal, Dan (Dan);
> > > > 'Michael Youssefmir'
> > > > *Cc:* 'Fujio Watanabe'; Klerer Mark; 'Wallace, Stewart
J';
> > > > stds-80220-requirements@ieee.org; Bharatula, Ganesh
> > > > *Subject:* RE: stds-80220-requirements: comments on
rev5 -
> > > > Channel bandwidth resolution
> > > >
> > > > Joanne & All,
> > > >
> > > > Just to clarify:
> > > > In my previous message I wrote: "...the declared
> > > > objectives of the PAR are also to deploy in existing
> > > > licensed bands and to reuse existing infrastructure.
"
> > > > The PAR does not say "existing" (vis-a-vis "Licensed
> > > > spectrum"). I added this word to emphasize
> > > > my interpretation of the PAR; that the IEEE 802.20
> > > > standard project would develop an air interface that
> > > > is deployable in Licensed bands (i.e., bands
allocated
> > > > by regulatory bodies for Land Mobile communications
> > > > service), not in some obscure future spectrum
> > > > allocation. The word "existing" is not absolute - it
> > > > is concurrent to the time the 802.20 standard is
> > > > invoked. Thus, spectrum that does not "exist" today
> > > > may very well "exist" (i.e., be "allocated and
> > > > available") next year or ten years from today. The
> > > > 1.25 MHz and 5 MHz channels exist today and are
likely
> > > > to exist in the next twenty years and beyond. Even
if
> > > > larger spectrum BLOCKS (e.g., 20 MHz, 25 MHz, or
even
> > > > 100 MHz) are allocated in the future for 3G/4G
mobile
> > > > communication service, a multi-carrier 802.20
solution
> > > > could be deployed in such ultra wide frequency
blocks.
> > > > Thus, a choice of 1.25 MHz and 5 MHz channels is a
> > > > future-proof.
> > > >
> > > > In an earlier message, Stewart mentioned that in
> > > > Australia, the 100 MHz block (3.425 GHz ~ 3.575 GHz)
> > > > is divided into 3.5 MHz "units" (i.e., licenses) -
> > > > for a TDD scheme I presume - and therefore he would
> > > > like to see an 802.20 standard that specifies a
> > > > channel (or channels) that would "fit" into one 3.5
> > > > MHz licensed spectrum. Obviously, a 5 MHz channel
> > > > would not be suitable, but, is a 1.25 MHz
> > > > channel acceptable? - after all, you would need to
> > > > deploy a two-carrier solution (2x1.25 MHz, or one
2.5
> > > > MHz TDD channel) and waste the remaining 1 MHz on
two
> > > > 0.5 MHz guard bands. Is my understanding correct?
> > > >
> > > >
> > > > Dan
> > > >
> > > >
> > > >
> > > >
> > > > Thus, -----Original Message-----
> > > > *From:* Joanne Wilson [mailto:joanne@arraycomm.com]
> > > > *Sent:* Wednesday, August 20, 2003 9:57 AM
> > > > *To:* David Trinkwon; Gal, Dan (Dan); 'Michael
> > Youssefmir'
> > > > *Cc:* 'Fujio Watanabe'; Klerer Mark; 'Wallace,
Stewart
> > > > J'; stds-80220-requirements@ieee.org; Bharatula,
> Ganesh
> > > > *Subject:* RE: stds-80220-requirements: comments on
> > > > rev5 - Channel bandwidth resolution
> > > >
> > > > All,
> > > >
> > > > I agree with David that "existing bands" can
> > > > include those he mentions below. This argues
> > > > for
> > the
> > > > kind of 1.25 MHz granularity that had been
> > > > proposed by Mike and others. Of course, 802.20
> > > > systems
> > > > would be deployable whereever a service provider
> > > > has sufficient spectrum and the regulatory
> authority
> > > > permits its deployment -- whether the service
> > > > provider, the bands, and/or the infrastructure
is
> > > > "new" or "existing".
> > > > A key point raised in this discussion is how to
> > > > strike the balance in granularity between
> > > > providing enough
> > > > flexibility to allow 802.20 to be deployable in
a
> > > > variety of channel bandwidths while not
dictating
> > > > apriori a
> > > > particular technology or sub-channel
> > > > structure.
> > > >
> > > > Best regards,
> > > >
> > > > Joanne
> > > > -----Original Message-----
> > > > *From:* David Trinkwon
> > > > [mailto:trinkwon@compuserve.com]
> > > > *Sent:* Wednesday, August 20, 2003 3:31 AM
> > > > *To:* Gal, Dan (Dan); 'Michael Youssefmir'
> > > > *Cc:* 'Fujio Watanabe'; Joanne Wilson; Klerer
> > > > Mark; 'Wallace, Stewart J';
> > > > stds-80220-requirements@ieee.org; Bharatula,
> Ganesh
> > > > *Subject:* RE: stds-80220-requirements: comments
> > > > on rev5 - Channel bandwidth resolution
> > > >
> > > > "Existing Bands" does include MMDS in the US
> > > > (and elsewhere) which are on a n x 6 MHz
> > > > basis, and the 3.4 - 3.6 MHz bands in
certain
> > > > countries (various block / channelization
> > > > schemes) - at least for "Portability" or
> > > > "Nomadic" purposes if not full mobility.
> > > > "Existing Infrastructure" obviously means
> > > > "where applicable" and does not always imply
> > > > "Existing Service Provider" especially when
/
> > > > where spectrum trading is introduced.
> > > >
> > > > A major objective of 802.20 is to move the
BWA
> > > > industry forward beyond 3G, not just get
stuck
> > > > in the same ruts.
> > > >
> > > >
> > > > *
> > > > *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
> > > > Gal, Dan (Dan)
> > > > Sent: 19 August 2003 21:06
> > > > To: 'Michael Youssefmir'; Gal, Dan (Dan)
> > > > Cc: 'Fujio Watanabe'; Joanne Wilson; Klerer
> > > > Mark; 'Wallace, Stewart J';
> > > > stds-80220-requirements@ieee.org; Bharatula,
> > > > Ganesh
> > > > Subject: RE: stds-80220-requirements:
comments
> > > > on rev5 - Channel
> > > > bandwidth resolution
> > > >
> > > >
> > > >
> > > >
> > > > Mike,
> > > >
> > > > Well, yes. I recognize that the authors of
the
> > > > PAR did not want to commit the MBWA standard
> > > > to 1.25 MHz and 5 MHz channels only (hence
its
> > > > language; "e.g., 1.25 MHz, 5 MHz"), yet, the
> > > > declared objectives of the PAR are also to
> > > > deploy in existing licensed bands and to
reuse
> > > > existing infrastructure. The above channels
> > > > meet those criteria. There is little
practical
> > > > benefit in defining other ("future")
> > > > channel-BWs in 802.20 unless such channels
can
> > > > be made available for deployment. Perhaps
> > > > it would be best if we leave this issue for
> > > > work on future releases of IEEE 802.20?
> > > >
> > > > Dan
> > > >
> > > > -----Original Message-----
> > > > From: Michael Youssefmir
> > > > [mailto:mike@arraycomm.com]
> > > > Sent: Saturday, August 16, 2003 12:02 PM
> > > > To: Gal, Dan (Dan)
> > > > Cc: 'Fujio Watanabe'; Joanne Wilson; Klerer
> > > > Mark; 'Wallace, Stewart J';
> > > > stds-80220-requirements@ieee.org; Bharatula,
> > > > Ganesh
> > > > Subject: Re: stds-80220-requirements:
comments
> > > > on rev5 - Channel
> > > > bandwidth resolution
> > > >
> > > >
> > > >
> > > > Dan,
> > > >
> > > > Just to be clear, I think the PAR only talks
> > > > about 1.25MHz and 5MHz
> > > > as examples and not as mandates.
> > > >
> > > > Mike
> > > >
> > > >
> > > > On Fri, Aug 15, 2003 at 03:47:38PM -0400,
Gal,
> > > > Dan (Dan) wrote:
> > > > >
> > > > > All,
> > > > >
> > > > > My view is that we should stick to the PAR
> > > > definitions: 1.25 MHz and 5 MHz
> > > > channel-bandwidths for FDD, and, if I
> > > > understand correctly, 2.50 MHz and 10 MHz
> > > > channels BWs for TDD. In future releases of
> > > > IEEE 802.20, we may evaluate and adopt
broader
> > > > channels, as the evolving mobile wireless
> > > > market may require.
> > > > >
> > > > > Dan
> > > > >
> > > > > -----Original Message-----
> > > > > From: Fujio Watanabe
> > [mailto:fwatanabe@ieee.org]
> > > > > Sent: Friday, August 15, 2003 3:09 PM
> > > > > To: Joanne Wilson; Klerer Mark; 'Wallace,
> > > > Stewart J';
> > > > > stds-80220-requirements@ieee.org
> > > > > Cc: Bharatula, Ganesh
> > > > > Subject: Re: stds-80220-requirements:
> > > > comments on rev5 - Channel
> > > > > bandwidth resolution
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > It is not practical to have one AI to fit
a
> > > > number of different bandwidths,
> > > > > although one may argue that SDR will
enable
> > > > it in the future. Since the
> > > > > technologies for an AI corresponding to a
> > > > specified bandwidth (e.g., narrow
> > > > > band) are most likely different from those
> > > > for another AI corresponding to
> > > > > another bandwidth (e.g., broadband), a
> > > > system cannot be specified without a
> > > > > concrete value of bandwidth. For example,
> > > > even if we tune some parameters of
> > > > > AI's in a PCS band, I don't think this AI
> > > > can work in a broad bandwidth
> > > > > case, such as 100MHz required for the
> > > > systems beyond IMT-2000 according to
> > > > > WRC'2003. Therefore, I would like to see
> > > > several typical bandwidths
> > > > > specified for the MBWA.
> > > > >
> > > > > By the way, if 1.25MHz is called
> > > > "broadband", what will we call 100MHz?
> > > > > -- super broadband :)
> > > > >
> > > > > Fujio
> > > > >
> > > > >
> > > > > ----- Original Message -----
> > > > > From: "Joanne Wilson"
<joanne@arraycomm.com>
> > > > > To: "Klerer Mark" <M.Klerer@flarion.com>;
> > > > "'Wallace, Stewart J'"
> > > > > <Stewart.J.Wallace@team.telstra.com>;
> > > > <stds-80220-requirements@ieee.org>
> > > > > Cc: "Bharatula, Ganesh"
> > > > <Ganesh.Bharatula@team.telstra.com>
> > > > > Sent: Friday, August 15, 2003 11:42 AM
> > > > > Subject: RE: stds-80220-requirements:
> > > > comments on rev5 - Channel bandwidth
> > > > > resolution
> > > > >
> > > > >
> > > > > >
> > > > > > I agree with Mark, Stewart, Arif and
Mike
> > > > on this point. If we adopt
> > > > > > a plan for only 5, 10, 15,... MHz
channel
> > > > bandwidths we will limiting the
> > > > > > market opportunity for 802.20 systems
> > > > unnecessarily. From an economies
> > > > > > of scale perspective, I don't see how
that
> > > > would be in any of our
> > > > > interests.
> > > > > >
> > > > > > Best regards,
> > > > > >
> > > > > > Joanne
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From:
> > > >
> owner-stds-80220-requirements@majordomo.ieee.org
> > > > > >
> > > >
> > > [mailto:owner-stds-80220-requirements@majordomo.ieee.org]On
> > > > Behalf Of
> > > > > > Klerer Mark
> > > > > > Sent: Friday, August 15, 2003 10:00 AM
> > > > > > To: 'Wallace, Stewart J';
> > > > stds-80220-requirements@ieee.org
> > > > > > Cc: Bharatula, Ganesh
> > > > > > Subject: RE: stds-80220-requirements:
> > > > comments on rev5 - Channel
> > > > > > bandwidth resolution
> > > > > >
> > > > > >
> > > > > >
> > > > > > I agree with Stewart and Arif. I believe
> > > > we are trying to spec a system
> > > > > that
> > > > > > is deployable in the identified spectrum
> > > > space and is scalable with
> > > > > existing
> > > > > > market demands and constraints.
> > > > > >
> > > > > > Mark Klerer
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: Wallace, Stewart J
> > > > [mailto:Stewart.J.Wallace@team.telstra.com]
> > > > > > Sent: Thursday, August 14, 2003 10:59 PM
> > > > > > To: stds-80220-requirements@ieee.org
> > > > > > Cc: Bharatula, Ganesh
> > > > > > Subject: RE: stds-80220-requirements:
> > > > comments on rev5 - Channel bandwidth
> > > > > > resolution
> > > > > >
> > > > > >
> > > > > > section 4.1.4
> > > > > >
> > > > > > In the case of Australia, I would just
> > > > like to highlight that the 3.4GHz
> > > > > > band (covering 3.425 GHz ~ 3.575 GHz)
has
> > > > already been licenced under a
> > > > > > 15-year assured tenure regime, based on
a
> > > > lot size granularity of 3.5 MHz.
> > > > > > This approach was taken by our regulator
> > > > in view of current FWA
> > > > > technologies
> > > > > > as the primary usage at that time. I
> > > > understand that there are several
> > > > > > other countries with similar band
> > > > structures (although not necessarily
> > > > > with
> > > > > > the same tenure regime). Thus, a 5MHz
> > > > minimum channelisation restriction
> > > > > > would seem to potentially exclude
> > > > Australia (at least) from the MBWA
> > > > > market
> > > > > > for the next 15+ years.
> > > > > >
> > > > > > In that context, I would suggest that a
> > > > more flexible approach as
> > > > > suggested
> > > > > > by Arif would seem to be more prudent.
> > > > > >
> > > > > > 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: Ansari, Arif
> > > > [mailto:Arif.Ansari@Nextel.com]
> > > > > > Sent: Friday, 15 August 2003 8:33 AM
> > > > > > To: Sheikh, Khurram P [GMG]; Fujio
> Watanabe;
> > > > > > stds-80220-requirements@ieee.org
> > > > > > Cc: Dennett, Steve
> > > > > > Subject: RE: stds-80220-requirements:
> > > > comments on rev5
> > > > > >
> > > > > >
> > > > > >
> > > > > > A 1.25 Mhz channel bandwidth is
consistent
> > > > with the preferred North
> > > > > American
> > > > > > granularity and is the motivation for
such
> > > > a channel bandwidth in 3GPP2.
> > > > > > The original text included 1.25 and 5
MHz
> > > > as examples, again consistent
> > > > > with
> > > > > > other standardization efforts to not
make
> > > > the channel bandwidth a
> > > > > > requirement. This adequately covers the
> > > > mobile licensed band worldwide,
> > > > > and
> > > > > > the follow-on text also included the
> > > > possbility of wider channels. At the
> > > > > > minimum, I would suggest that 1.25 MHz
not
> > > > be excluded, while 5 MHz and
> > > > > > multiples thereof can also be included.
> > > > Ideally I would like to see all
> > > > > > these channel bandwidths as no more than
> > > > examples.
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: Sheikh, Khurram P [GMG]
> > > > [mailto:khurram.p.sheikh@mail.sprint.com]
> > > > > > Sent: Thursday, August 14, 2003 4:19 PM
> > > > > > To: Fujio Watanabe;
> > > > stds-80220-requirements@ieee.org
> > > > > > Subject: RE: stds-80220-requirements:
> > > > comments on rev5
> > > > > >
> > > > > >
> > > > > >
> > > > > > I would like to add to Fujio's comments
> > > > and my earlier contribution.
> > > > > > Multiples of 5 MHz is critical for both
a
> > > > technical performance as well
> > > > > > economic viability (capital efficiency)
> > > > given other performance
> > > > > > parameters (system throughput, number of
> > > > users, broadband data models
> > > > > > etc.)
> > > > > >
> > > > > > Thanks and look forward to any
rationales
> > > > why less than 5 MHz could be
> > > > > > an option for the MBWA system tied to
our
> > > > current performance
> > > > > > requirements.
> > > > > >
> > > > > >
> > > > > >
> > > > > > Khurram P. Sheikh
> > > > > > Chief Technology Advisor
> > > > > > Sprint- Broadband Wireless
> > > > > > Tel (SM): 650-513-2056
> > > > > > Tel(KC): 913-762-1645
> > > > > > Mobile: 650-906-8989
> > > > > > khurram.p.sheikh@mail.sprint.com
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: Fujio Watanabe
> > > > [mailto:fwatanabe@ieee.org]
> > > > > > Sent: Wednesday, August 13, 2003 8:57 PM
> > > > > > To: stds-80220-requirements@ieee.org
> > > > > > Subject: RE: stds-80220-requirements:
> > > > comments on rev5
> > > > > >
> > > > > >
> > > > > >
> > > > > > I would like to make a comment on John's
> > > > email of July 23rd on section
> > > > > > 4.1.4
> > > > > > as follows.
> > > > > >
> > > > > > I don't agree to eliminate this section
> > > > (John said "stricken") because
> > > > > > the
> > > > > > bandwidth is one of important basic
system
> > > > requirements. A system
> > > > > > cannot be
> > > > > > specified without concrete values of
> > > > bandwidth.
> > > > > > A broader bandwidth is a current trend
of
> > > > wireless communications, e.g.,
> > > > > > WLAN (e.g., 20MHz), UWB (e.g., >300MHz),
> > > > possible systems beyond
> > > > > > IMT-2000
> > > > > > (e.g., 100MHz) as well as a general
> > > > requirement for Mobile "Broadband"
> > > > > > Wireless Access.
> > > > > >
> > > > > > I also understand John's rationale to
not
> > > > limit the lower bound of the
> > > > > > bandwidth.
> > > > > >
> > > > > > Therefore, how about to have several
> > > > typical numbers for the bandwidth
> > > > > > as
> > > > > > options in this section?
> > > > > >
> > > > > > Best Regards,
> > > > > >
> > > > > > Fujio
> > > > > >
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Fan John
> [mailto:J.Fan@flarion.com]
> > > > > > > Sent: Wednesday, July 23, 2003 6:15 PM
> > > > > > > To: 'stds-80220-requirements@ieee.org'
> > > > > > > Subject: stds-80220-requirements:
> > > > comments on rev5
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Hi all,
> > > > > > >
> > > > > > > These are comments on rev5 of the
> > > > document from Marc
> > > > > > > Goldberg, Michael Youssefmir, Samir
> > > > Kapoor, Joanne Wilson,
> > > > > > > Arif Ansari and John Fan.
> > > > > > >
> > > > > > > --John
> > > > > >
> > > > > > > 4.1.4. Channel Bandwidth
> > > > > > >
> > > > > > > Action: This section should be
stricken.
> > > > > > >
> > > > > > > Rationale: The current text requires
> > > > "multiples of 5 MHz" for
> > > > > > > deployment. No rationale for 5Mhz has
> > > > been given on the
> > > > > > > reflector. Beyond that, a 5 MHz
minimum
> > > > bandwidth would
> > > > > > > limit the applicability of the MBWA AI
> > > > in many of the
> > > > > > > available licensed bands below 3.5
GHz.
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > >
> > >
> > > --
> > >
.......................................................................
> > > Mark Cudak Email:
Mark.Cudak@motorola.com
> > > Communication Research Labs Maildrop: IL02-2928
> > > Motorola Labs Phone: (847) 576-2573
> > > 1301 E. Algonquin Rd. Fax: (847) 576-8378
> > > Schaumburg, IL 60196
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
>