RE: stds-80220-requirements: comments on rev5 - Channel bandwidth resolution

["Joanne Wilson" <joanne@arraycomm.com>]

All,

II support Mark Klerer's recent email and particularly his proposal 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".

I'd also like to note that the debate between higher versus lower bandwidth standards is not new.  It had previously
been argued that WCDMA (a.k.a. CDMA-Direct Spread w/ a 5 MHz bandwidth) would out perform cdma2000 (a.k.a. CDMA-Multi Carrier w/ three 1.25 MHz Carriers) because it was obviously more efficient to use the full 5 MHz channel than to divide it into 3 carriers.  Today, I believe most people accept that WCDMA and cdma2000  (using 3 carriers) have comparable performance levels.  Unless WCDMA is capable of dedicating >1.25 MHz of the channel capacity to a single user, it is not likely that the end customer will see any difference between the two standards. However, with comparable performance and multiple 1.25 carriers, a cdma2000 vendor has been able to apply cdma2000 into the NMT band at 450 MHz that has only 4.5 MHz bandwidth.  WCDMA simply can't fit into that allocation.  With 1.25 MHz carriers, it is also easier for existing operators to transition into cdma2000 because they need to clear a smaller fraction of their existing specturm to deploy a single cdma2000 carrier and add more carriers over time as their customer base transitions to the new technology.  Additionally, to address coexistence problems, operators often have to back away from the band edge to meet OOBE requirements, in effect creating internal guardbands.  If the system fully occupies a 5 MHz bandwidth, 6 to 8 MHz licenses may be needed for its deployment in certain markets.  At the end of the day, the flexibility that the lower bandwidth granularity provides has some obvious and not so obvious advantages over the larger bandwidth systems.  Hence my support for Mark's proposal that we commence with developing standards for the lower (1.25 and 5 MHz) options and further study the requirements for the higher bandwidth cases.

Additionally, it's  not clear to me if the proponents of a set of channel bandwidths (up to 100 MHz) are talking about a single system that is scalable to each of these bandwidths or are they talking about multiple standards?  It's hard to envision a PHY design that remains efficient and appropriate as the occupied bandwidth is "scaled" from 1.25 MHz to 20 or up to 100 MHz. It is also difficult to envision a single MAC that would be optimum for such a wide variety of PHYs. With all this, isn't interoperability sacrificed for the sake of all these choices?  And, surely, we wouldn't attempt to
compare proposals with differing channel bandwidths, as there is such a fundamental difference between them?  How would 802.20 go about addressing so many bandwidth options?

Finally, and maybe this is an obvious observation, assuming that we develop the smaller bandwidth options (e.g. 1.25 and 5 MHz channel bandwidths) that could be deployed  in the largest number of bands, wouldn't the benefits of interoperability and economies of scale favor its deployment even in larger bandwidth licenses? In my view, at best the higher bandwidth proposals are short on important details.  For the reasons expressed above and more elequently in Mark Klerer and Stewart Wallace's previous emails, I am of the view that n*1.25 MHz granularity is the optimum choice for 802.20. We could, in a future 802.20x standard address higher bandwidths for spectrum above 3.5 GHz where there is greater availability of spectrum to support the deployment of such a system.

Best regards,

Joanne

-----Original Message-----
From: owner-stds-80220-requirements@majordomo.ieee.org [mailto:owner-stds-80220-requirements@majordomo.ieee.org]On Behalf Of Steve Crowley
Sent: Thursday, August 28, 2003 9:34 AM
To: David Trinkwon; Klerer Mark; stds-80220-requirements@ieee.org
Subject: RE: stds-80220-requirements: comments on rev5 - Channel bandwidth resolution

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