Re: stds-80220-requirements: comments on rev5 - Channel bandwidth resolution
- To: "Fujio Watanabe" <fwatanabe@ieee.org>, "David Trinkwon" <trinkwon@compuserve.com>, "Mark Cudak" <Mark.Cudak@motorola.com>, stds-80220-requirements@ieee.org, "Gal, Dan (Dan)" <dgal@lucent.com>, "'Joanne Wilson'" <joanne@arraycomm.com>, "Wallace, Stewart J" <Stewart.J.Wallace@team.telstra.com>, J.Fan@flarion.com
- Subject: Re: stds-80220-requirements: comments on rev5 - Channel bandwidth resolution
- From: Daichi IMAMURA <imamura.daichi@jp.panasonic.com>
- Date: Tue, 26 Aug 2003 21:47:48 +0900
- In-Reply-To: <004701c36a93$995076f0$5e6015ac@dclfujioibm>
- References: <MCBBIPNFLKMFDOLDKENEIEPPCIAA.trinkwon@compuserve.com> <004701c36a93$995076f0$5e6015ac@dclfujioibm>
- Sender: owner-stds-80220-requirements@majordomo.ieee.org
Hi all,
I agree with Mark Cudak, David Trinkwon and Fujio Watanabe's
comments throught the various discussion about channel bandwidth
requirement.
Fortunately 802.20 don't have any restriction of backward compatibility
because of new WG. I think we should turn our eyes not only to "existing
band" (i.e. 1.25MHz, 2.5MHz, 5MHz, N*1.25MHz ) but also "wider future
band" (i.e. 10MHz, 20MHz,. ,100MHz,..). 100MHz too early?
Although "existing band" is also one of the applicable band,
I think that we should not limit channel bandwidth to a multiple of
1.25M/2.5M as requirements, as I'm afraid some excellent solutions for
achieving attractive MBWA systems will be eliminated.
Therefore I'd like to define 1.25 MHz, 2.5 MHz, 5 MHz, 10 MHz, 20MHz etc
bandwidth without restriction of a multiple of xxxMHz and "granularity"
word.
I believe that 802.20 will be an exellent system optimized for IP packet
communication on full mobility envirionment.
Best Regards
Daichi Imamura
Panasonic
On Sun, 24 Aug 2003 16:01:04 -0700
"Fujio Watanabe" <fwatanabe@ieee.org> wrote:
>
> 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-à-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
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
!!!!! Please change my e-mail address in your e-mail software !!!!!!!
---------------------------------------------------------------
Daichi IMAMURA
R&D Center, Panasonic Mobile Commuinications, Co., Ltd.
5-3 Hikarinooka, Yokosuka, 239-0847, JAPAN
TEL: +81.46.840.5631 (dial in) FAX: +81.46.840.5222
E-mail: imamura.daichi@jp.panasonic.com
----------
Intra-office Post#: 350-152
Extention number: 7-350-5631
---------------------------------------------------------------