1. Non contiguous 40+40 additional bandwidth mode
Month Year
doc.: IEEE yy/xxxxr0
Non contiguous additional bandwidth mode
Date:
John Doe, Some Company

2. Content The following modes have already been accepted by 11ac
20MHz, 40MHz, 80MHz (mandatory)
160MHz (optional)
Optional 40+40MHz non contiguous transmission mode should be added to the spec framework
it enables to exploit the part of the band left aside by the current contiguous 80MHz frequency planning
it increases the probability to transmit at 80MHz (the target of 11ac) in presence of neighbors or radars..
its complexity of integration is identical to the 80+80MHz mode already accepted by TGac

3. 80MHz Channel planning in 5GHz band
Weather radars
5170
MHz
5330
MHz
5490
MHz
5710
MHz
5735
MHz
5835
MHz 36 40 44 48 52 56 60 64
100
104
108
112
116
120
124
128
132
136
140
149
153
157
161
165
IEEE channel #
20 MHz
40 MHz
80 MHz
only in US
Only 4 channels for 80MHz in Europe, only 2 at 30dBm
With one channel (in red) which can strongly be affected by weather radars (see map next slide)
In many cases, contiguous only BSS will not be able to transmit at 80MHz without overlapping
Non contiguous 2x40MHz mode is the solution in this part of the band
each 40MHz segment is allocated in the band according to 40MHz channel planning
Slide 3

4. 80MHz Channel planning in 5GHz band
Map of weather radars occupying 5GHz spectrum in France
On most of these regions, only 3 80MHz channels will be available

5. Example of the use of 40+40MHz mode
Weather radar
5170
MHz
5330
MHz
5490
MHz
5710
MHz 36 40 44 48 52 56 60 64
100
104
108
112
116
120
124
128
132
136
140
IEEE channel #
Interferers
11ac
neighbor
11n
neighbor
Interferer
New BSS with contiguous 80 MHz
New BSS with non contiguous MHz
Limited access to channel
Full access to channel
Non contiguous 2x40MHz mode enables full 80MHz transmission
Contiguous 80MHz mode is forced to share channel access
Slide 5

6. 40+40MHz mode
40+40MHz mode leads to lower maximum throughput than contiguous 80MHz.
However, we have demonstrated in [1] and [2] that 40+40MHz mode is way more resistant to neighbors traffic than 80MHz mode. The environment doesn’t need to be very dense to see the gains provided by 40+40MHz mode.
For China where the number of channels are even more limited, the efficiency of this mode compared to contiguous 80MHz will be even more significant.
It’s very likely that some products in the market already implement this technology.
We should define this mode and let the market decide.

7. Transmit flow for 40+40MHz mode
Transmit flow for non-contiguous 40+40MHz transmissions:
Perform channel coding
Parse the encoder output bits into stream(s)
For each stream, the stream parser output bits are allocated to two 40 MHz segments in an alternating fashion
Even bits to the 40 MHz segment lower in frequency and odd bits to 40 MHz segment higher in frequency, where the first bit from the stream parser output in each symbol is an even bit
If BCC is used, interleave per 40 MHz segment, with each segment using interleaver defined for 40 MHz transmission

8. Conclusion
40+40MHz non contiguous transmission mode should be added to the spec framework as an optional feature
it enables to exploit the part of the band left aside by the current contiguous 80MHz frequency planning
it increases the probability to transmit at 80MHz (the target of 11ac) in presence of neighbors or radars..
its complexity of integration is identical to the 80+80MHz mode already accepted by TGac

9. Strawpoll
Do you support adding the following section and item into the specification framework document, 11-09/0992?
Section Non contiguous MHz PHY Transmission
R3.1.2.A: The draft specification shall include support for optional non contiguous 40+40MHz PHY transmission, whose frequency spectrum consists of two segments, each transmitted using two 40 MHz channels, non-adjacent in frequency.
Yes:
No:
Abstain:

10. References
[1] Cariou, L. and Christin, P., 80MHz and 160MHz channel access modes, IEEE /0385r1, Mar. 2010
[2] Cariou, L. and Benko, J., Gains provided by multichannel transmissions, IEEE /0103r1, Jan. 2010