Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

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



Mark et.al,
 
Reiterating my view and position on the issue of IEEE 802.20 carrier channel bandwidths - my view very much matches Mark Klerer's proposal - and suggesting an agreement as follows:
 
1.  The 802.20 PAR's channel BW definitions ("e.g., 1.25 MHz, 5 MHz") along with the supporting presentations that formed the basis for the approval of the project by the IEEE 802 Executive Committee are binding and have to be reflected in the System Requirements document.
 
2.  The IEEE 802 Executive Committee should issue a statement, clarifying whether the 802.20 may address channel bandwidths larger than 5 MHz. "Address" means: study, specify, standardize (in that order). Again, to avoid any misunderstanding, a "channel bandwidth" means the bandwidth occupied by a single carrier or multi-carrier air interface, including guard-bands if applicable. Filling a block of licensed spectrum with several individual channels is NOT to be confused with the concept of a multi-carrier channel (such as cdma2000).
 
3.   Channel "granularity", in 802.20 context, should be associated with channel center-frequency mapping onto a channelization grid that may be defined for a particular spectrum block. The channelization specification (commonly found in wireless standards and regulations) normally defines channel numbers along with channel center-frequencies. Such a grid may or may not be defined in regulatory and/or voluntary standards, in legacy or green-field spectrum allocations. The IEEE 802.20 standard may provide this information, if we so decide, or if mandated by certain international regulatory bodies. This issue must be properly addressed by the group. 
 
4.  The addressable licensed spectrum (i.e., the use of which requires a license) in bands below 3.5 GHz is that spectrum that is, or will be, allocated for Mobile Communication service (both public and private).  
 
 
Note: I believe that the term "Fat Pipe" in Mark's rationale is meant to be understood (by Mark) as a block (or sub-block) of licensed spectrum in which an operator may deploy one or more individual channels. In popular usage the term may often refer to ONE channel. I therefore recommend to refrain from using it. 
 
 
I hope we can converge on these points and agree to include them in the System Requirements document.
 
 
Regards,
 
Dan
-----Original Message-----
From: Klerer Mark [mailto:M.Klerer@flarion.com]
Sent: Thursday, August 28, 2003 12:16 AM
To: 'stds-80220-requirements@ieee.org'
Subject: FW: stds-80220-requirements: comments on rev5 - Channel bandwidth resolution

I am forwarding this message since it encountered a length restriction problem on the reflector

 

From: Wallace, Stewart J [mailto:Stewart.J.Wallace@team.telstra.com]
Sent
:
Wednesday, August 27, 2003 11:30 PM
To:
Klerer Mark; Fujio Watanabe; David Trinkwon; Mark Cudak; stds-80220-requirements@ieee.org
Cc:
Gal, Dan (Dan); Joanne Wilson; Fan John
Subject: RE: stds-80220-requirements: comments on rev5 - Channel bandwidth resolution

 

Mark,

 

Very clear & logical position, based on sound principles.  I strongly support your proposal.

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: Klerer Mark [mailto:M.Klerer@flarion.com]
Sent:
Thursday, 28 August 2003 12:44 PM
To: 'Fujio Watanabe'; David Trinkwon; Mark Cudak; stds-80220-requirements@ieee.org
Cc: Gal, Dan (Dan); 'Joanne Wilson'; Wallace, Stewart J; Fan John
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:

 

1.    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.

2.    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