March 2007 doc IEEE 802 22 070116 r

March 2007 doc. : IEEE 802. 22 -07/0116 r 0 Service allocation for 802. 22 IEEE P 802. 22 Wireless RANs Date: 2007 -03 -12 Authors: Notice: This document has been prepared to assist IEEE 802. 22. It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein. Release: The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE 802. 22. Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures http: //standards. ieee. org/guides/bylaws/sb-bylaws. pdf including the statement "IEEE standards may include the known use of patent(s), including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents essential for compliance with both mandatory and optional portions of the standard. " Early disclosure to the Working Group of patent information that might be relevant to the standard is essential to reduce the possibility for delays in the development process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair Carl R. Stevenson as early as possible, in written or electronic form, if patented technology (or technology under patent application) might be incorporated into a draft standard being developed within the IEEE 802. 22 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at patcom@iee. org. > Submission 1 Carlos de Segovia, France Telecom

March 2007 doc. : IEEE 802. 22 -07/0116 r 0 Abstract This document intends to propose a mechanism for the allocation of the services to the sub-channels for the WRAN system. It relies on the current status of the OFDMA parameters and the modifications proposed in doc 802. 22 -07 xxxx The service allocation is proposed for the uplink and the downlink directions. Submission 2 Carlos de Segovia, France Telecom

March 2007 doc. : IEEE 802. 22 -07/0116 r 0 Content • • OFDMA parameters Bursts Downstream service allocation Upstream service allocation Submission 3 Carlos de Segovia, France Telecom

March 2007 doc. : IEEE 802. 22 -07/0116 r 0 OFDMA parameters 1680 used sub-carriers (1 DC in the middle) Downlink Uplink (modified) Useful symbols 19 5 (or multiple of 5) Symbols for pilot spreading 7 5 Pilot carriers per symbol 240 288 Data carriers per symbol 1440 1392 Number of sub-channel 30 84 Number of carriers/sub-channel 56 20 Number of data carriers/ subchannel 48 16 Number of pilot carriers/ subchannel 8 4 Submission 4 Carlos de Segovia, France Telecom

March 2007 doc. : IEEE 802. 22 -07/0116 r 0 Downstream Burst • A burst is a set of sub-carriers that occupies a "rectangle" in the time/frequency domain defined as k sub-channels on a duration of j OFDMA symbols. burst j symbols t f Smallest burst k sub-channels • The smallest burst has 1 subchannel on 1 symbol per frame. – 96 bits/frame in QPSK, 192 bits in 16 QAM, 288 bits in 64 QAM • Not necessary for DS burst to have at least 7 symbols (= 1/Pilot Density) – The CPE can make use of all the pilot carriers to estimate the channel and interpolate missing pilots. Submission 5 Carlos de Segovia, France Telecom

March 2007 doc. : IEEE 802. 22 -07/0116 r 0 Upstream Burst • An upstream burst is a "rectangle" in the time/frequency domain defined as k sub-channels on a minimum duration of 5 OFDMA symbols. k sub-channels 5 symbols Burst Smallest burst • The smallest burst has 1 subchannel on 5 symbols per frame – 160 bits/frame in QPSK, 360 bits in 16 QAM, 480 bits in 64 QAM • US burst must have a minimum of 5 symbols (=1/Pilot density). – The BS needs to estimate each sub-carrier in the uplink from each CPE Submission 6 Carlos de Segovia, France Telecom

March 2007 doc. : IEEE 802. 22 -07/0116 r 0 Downstream data flow and allocation The downstream data flow is illustrated below: Service component Uncoded block Channel encoder FEC block Bit interleaver FEC Block interleaved Burst 1 Burst 2 OR Burst 3 3 examples of burst illustrated (not exclusive): – Burst type 1: block allocated to several sub-channels in 1 OFDM symbol. – Burst type 2: block allocated to several sub-channels in several OFDM symbols. – Burst type 3: block allocated to sub-channels in several OFDM symbols. Submission 7 Carlos de Segovia, France Telecom

March 2007 doc. : IEEE 802. 22 -07/0116 r 0 Upstream Data flow The upstream data flow is illustrated below: Service component Uncoded block Channel encoder FEC block Bit interleaver FEC Block interleaved Burst 1 Burst 2 OR Burst 3 Submission 8 Carlos de Segovia, France Telecom

March 2007 doc. : IEEE 802. 22 -07/0116 r 0 Upstream service allocation • Same process as downstream. • Bursts size is a minimum of 5 OFDM symbols. • The lowest granularity is 160 bits (a bit expensive for a "mouse click"). • Granularity can be reduced by: – Reducing the number of sub-carriers in a subchannel • The minimum is 5 sub-carriers – Reducing the pilot spreading. • The counterpart is a reduction of the efficiency. • For example, if the pilot density is 1/3 and the number of sub-carriers per sub-channel is 3, the lowest granularity becomes 18 bits. Submission 9 Carlos de Segovia, France Telecom

March 2007 doc. : IEEE 802. 22 -07/0116 r 0 Conclusions • The allocation of the data of a service component has been proposed. • The allocation is possible on different types of bursts. • The type of burst should be adapted to the Qo. S requirements of the service component. Submission 10 Carlos de Segovia, France Telecom