Presentation to accompany IEEE 802.11-08/0233r2

1. Presentation to accompany IEEE 802.11-08/0233r2 Authors: Date: 2008-05-12 Jon Rosdahl, CSR

2. Abstract This presentation was prepared to accompany IEEE 802.11-08/0233r2. This presentation looks at the following questions: 1. What is transmit inhibition interference? 2. What can be done with knowledge of transmit inhibition interference? 3. What is the cost of the proposed changes? The proposed text is then described. After the initial Presentation, a set of questions were asked, and a tutorial and response was added. Jon Rosdahl, CSR

3. What is transmit inhibition interference? • In our context this occurs when an IEEE 802.11 STA is required to be silent to protect a high priority reception at a co-located receiver. • It is often enforced by coexistence signalling between the co-located and (possibly mutually) interfering transceivers. • In some cases transmit inhibition of 802.11 may also be necessary to protect the (remote) reception of a transmission made by the co-located transceiver. Jon Rosdahl, CSR

4. What is transmit inhibition interference? (cont) • Transmit inhibition interference is a relaxed case of interference in comparison to receive de-sense interference • In the 802.11 protocol, receive interference at a STA precludes any communication initiated by a peer STA. • In contrast, a transceiver subject to only transmit inhibition interference is still able to receive. • If the initiator does not require a response then the communication will be successful. • Though STAs can choose to schedule transmissions to be made through the DCF or EDCF, such flexibility is not afforded for control responses, e.g. • Basic automatic control responses such as ACK or CTS. • Block acknowledgements where an immediate block acknowledgement policy is in use. Jon Rosdahl, CSR

5. Some examples of relevant use cases:IEEE 802.11 co-located with… • IEEE 802.16(e) – WiMAX, Mobile WiMAX or WiBro • Operation in licensed (i.e. paid-for) spectrum means unlicensed technologies must defer • FCH, DL-MAP, UL-MAP are important WiMAX downlink messages and can occur with periodicity 5 ms and instance duration on the order of 1 ms. • Bulk data downlink activity may have periodicity 5 ms and instance duration of up to 3 ms. • VoIP activity may cause two patterns of transmit inhibition interference, each with period 20 ms and instance duration 1-3 ms. These two patterns have phase offset of 5 ms. • Bluetooth (or 802.15.1) • Common use case sees Synchronous Connection-Oriented (SCO) transport carrying voice with little FEC and no retransmission • Any packet loss results in immediate user impact (audio distortion) thus SCO is given very high priority • This would cause transmit inhibition interference with period 3.75 ms and instance duration on the order of 0.4 ms. • Ultra-Wide Band (UWB) • A UWB receiver will likely be blocked by a collocated with IEEE 802.11 transmitter operating near 5 GHz (either through direct interference or through inter-modulation distortion) • UWB beacon period must be protected. This will have periodicity of 65 ms and instance duration on the order of 0.5-1 ms. Jon Rosdahl, CSR

6. What can be done with knowledge of transmit inhibition interference? • Some frames do not require an immediate response from the recipient • Multicast and broadcast frames from a STA in an IBSS or an AP • Unicast frames with a QoSNoAck policy • Unicast frames with a delayed block acknowledgement policy • All but the final unicast frame in a block-acknowledged sequence • A STA in an IBSS or an AP may schedule frames which do not require a response if the peer STA(s) is(are) known to be subject only to transmit inhibition interference. • For longer frames, a STA in an IBSS or an AP may be able to commence transmission of a frame that does require a response if it determines that the instance of transmit inhibition interference will have ended by the time that response is required. Jon Rosdahl, CSR

7. What does it cost? • Note that all statements in the previous slide are MAYs – not SHALLs. • No requirements are placed on an implementation. • A single bit in the Co-located Interference Response frame is needed to indicate transmit inhibition interference • For STAs choosing not to use such functionality this bit is treated as reserved. • We propose this bit be inserted in the Interference Level Accuracy/Interference Index field. Jon Rosdahl, CSR

8. Specifically… • Modify Figure v93 as shown: Figure v93 – Interference Level Accuracy/Interference Index field format Jon Rosdahl, CSR

9. Specifically – part 2 • Insert the following text in the draft amendment in Section 7.4.11.15 following the paragraph describing the Expected Accuracy field: The Interference Type bit indicates the nature of co-located interference. If set, the bit indicates that the interference causes transmit inhibition only, meaning that the transmitting STA can be addressed while subject to the interference, but will be unable to respond. Jon Rosdahl, CSR

10. Conclusion • The situations this mechanism proposes to address exist and are relevant. • The proposal places no requirement on anyone implementing the specification. • The proposal provides an avenue for product differentiation. • The proposed specification changes are minor. • In coexistence scenarios such performance gains can add up to make a major difference. Jon Rosdahl, CSR

11. Follow-up for Questions Follow the current definition in the TGv Amendment and explain what is currently defined. Jon Rosdahl, CSR

12. Definition –page 3 line 40 • Co-located Interference Reporting: Co-located Interference reporting enables a STA to receive information about co-located interference being experienced by another STA. Co-located interference may be due to an interaction between radios when a reporting non-AP STA is co-located with another radio device. Co-located Interference information can be used to manage communication to the STA such that the detrimental effect of the interference may be reduced. Jon Rosdahl, CSR

13. Definition of Co-located interferencepage 4 line 11 • 3.22a co-located interference: Interference that is caused by another radio or STA emitting radio energy located in the same physical device as the 802.11 STA, where the characteristics of the interference are known a priori without interference detection and characterization by the 802.11 STA. Jon Rosdahl, CSR

14. Overview of Wireless LAN Network Management • 5.2.11.1 Overview • WLAN Network Management enables STAs to exchange information for the purpose of improving the overall performance of the wireless network. STAs use Wireless Network Management protocols to exchange operational data so that each STA is aware of the network conditions, allowing STAs to be more cognizant of the topology of the network. Wireless Network Management protocols provide a means for STAs to be aware of the presence of co-located interference, and allow STAs to manage RF parameters based on network conditions. • (highlights added) Jon Rosdahl, CSR

15. General Description of Co-Located Interferencepage 5 line 1 • 5.2.11.3 Co-Located Interference Reporting • Co-located interference reporting allows the requesting STA to receive information on interference as detected by the reporting STA. The requesting STA can use that information to schedule transmissions to minimize the effects of the interference. Jon Rosdahl, CSR

16. Co-located Interference reporting • To support co-located interference reporting, the amendment defines two new Management Action frames. The first of these (logically) is the Co-located Interference Request frame. This frame "is transmittedby a STA to request Co-located Interference Response frames". Jon Rosdahl, CSR

17. Co-Located Interference Request Frame • The Co-located Interference Request frame contains only a single octet(aside from Category and Action codes and a Dialog Token) named Request Info. This octet consists of two fields: the Automatic Response Enabled field is a single bit (the most significant of the octet), and the Report Timeout fills the remaining seven bits. Jon Rosdahl, CSR

18. The Automatic Response Enabled • The Automatic Response Enabled field allows the requesting STA to specify that the reporting STA "send the Co-located Interference Response frames automatically". Jon Rosdahl, CSR

19. The Report Timeout Field • The Report Timeout field allows the requesting STA to place a limit on the rate at which the reporting STA will send it Co-located Interference Response frames. The value in this field has units of 100 TU. Jon Rosdahl, CSR

20. Interference Response Frame • The second new frame defined by the 802.11v draft amendment to support co-located interference reporting is the Co-located Interference Response frame. A Co-located Interference Response frame may contain "up to 16 separate Response Info fields" which contain information on the interference that the reporting STA has determined (a priori) that it is subject to. Jon Rosdahl, CSR

21. Response Info Field • Within the Response Info field there are several sub-fields. These sub-fields are (in an order favorable to my explanation rather than in the order that they appear): Report Period, Interference Index, Interference Level, Interference Level Accuracy, Interference Center Frequency, Interference Bandwidth, Interference Start Time, Interference Interval, and Interference Burst Length. Jon Rosdahl, CSR

22. First we'll get the report management-oriented fields out of the way: Jon Rosdahl, CSR

23. Report Period •  Report Period is a seven-bit field which "indicates how often the STA automatically reports the co-located interference" with "units of 100 TUs". Jon Rosdahl, CSR

24. Interference Index •  Interference Index provides an identifier that is "unique for each type of interference source". • This field is four bits in size, and with the all-zero value meaning that "no co-located interference is present", • This field allows the STA to report on up to 15 interference sources. Jon Rosdahl, CSR

25. Frequency domain • The remaining fields describe the interference to which the reporting STA is subject. • The first of them describe frequency-domain characteristics of the interferer: - Interference Level provides an indication of the power level of the interferer in units of dBm.  - Interference Level Accuracy provides some indication of the expected accuracy of the reported interference level. - Interference Center Frequency is relatively self-explanatory with units of MHz. - Interference Bandwidth is also pretty easy to comprehend,  specifying the -3 dB bandwidth of the interferer with units of kHz. Jon Rosdahl, CSR

26. Time Domain Fields • The remaining fields describe time-domain characteristics of the interferer: - For interference that is periodic the Interference Start Time may either specify "the least significant 4 octets (i.e. B0-B31) of the TSF timer at the start of the next interference burst", or the average duty cycle of the interference. • The latter is assumed when "either the Interference Interval or the Interference Burst Length fields are set to 65535" which indicates that the corresponding parameter is variable. • For interference that is non-periodic the Interference Start Time is set to 0. Jon Rosdahl, CSR

27. Interference Interval Field •  - The Interference Interval field "indicates the interval between two successive periods of interference in microseconds". • If this is variable then the field is set to 65535. •  - "The Interference Burst Length field indicates the duration of each period of interference in microseconds." • If this is variable then the field is set to 65535. Jon Rosdahl, CSR

28. Please Note: • To reinforce a point: the STA transmitting a Co-located Interference Request (which may be an AP or another STA in an IBSS) is requesting Co-located Interference Responses from a peer STA (which may be an AP or another STA in an IBSS) so that the requesting STA may "use that information to schedule transmissions to minimize the effects of the interference". Jon Rosdahl, CSR

29. I want to make it clear that in the slides just reviewed I have mentioned *nothing* but facility that *already exists in the 802.11v draft amendment*. Jon Rosdahl, CSR

30. Now on to the specific questions Jon Rosdahl, CSR

31. 1- you need time info to be sent- can be derived by type but this group will oppose type. If you send actual time info that is better. • This comment has no specific relevance to the 233r2 proposal.I will note that accurate time information on interference must beprovided by a reporting STA if a peer is to schedule its activity inorder to "minimize the effects of the interference". This facility isalready provided by the Interference Start Time, InterferenceInterval, and Interference Burst Length fields in the Response Infofield carried within a Co-located Interference Report frame. Jon Rosdahl, CSR

32. How does the timing of the transmission of the bit tie up with the isolated nature of the transmission of the co-located transmitter?For example, say the STA wants to use the other transmitter, how quick can it set the bit and transmit it?  Hence, does this only work if the interruption is relatively long. This comment has no specific relevance to the 233r2 proposal. If sucha problem were real it would equally affect the existing co-locatedinterference reporting mechanisms.The co-located interference reporting mechanisms as already defined inthe 802.11v draft amendment are intended for situations where the"characteristics of the interference are known a priori" by the 802.11STA. The mechanisms are most useful in (and appear designed for)situations where the interference is periodic. In such cases (theexamples I have previously given are WiMAX frames, UWB beacons,Bluetooth synchronous connections) the interference is predictable andby communicating the phase, period and burst duration (through thepreviously mentioned variables in the Response Info field) a peer (APor non-AP) STA *may* schedule its activity to avoid the interference.None of the above is changed by the 233r2 proposal. Jon Rosdahl, CSR

33. In the case of a 2.4GHz BlueTooth, then the RX will probably be blocked as well, so the ability to respond ACKs etc is not true. • If the transceiver co-located with the 802.11 STA is indeed Bluetooth, and if it is transmitting and there is insufficient isolation between it and the 802.11 receiver then the 802.11 receiver may be blocked and thus unable to receive anything. This is the type of interference that the existing support in 802.11v aims to cater for.If, on the other hand, the co-located Bluetooth transceiver isreceiving then it is quite possible (even likely) that the 802.11 STAcan receive. If the Bluetooth reception is expected to be of quitehigh priority (say a voice packet on a link that uses no errorrecovery) then it may be preferable to keep the 802.11 STA silent so that it doesn't interfere with the Bluetooth reception.It is this case that the 233r2 proposal aims to cater for. Jon Rosdahl, CSR

34. I would like to see examples, with timing, that show how this is more efficient than not having it.  Also look to see if there are examples where it causes less efficiency - the point being that we send a Transmission to indicate we cannot transmit, and then need to transmit again to cancel it?  Perhaps I do not understand when this transmission is sent. • As clarified and explained in this presentation – the issue is that the questioner does notunderstand "when this transmission is sent". Jon Rosdahl, CSR

35. Is this for a Non-AP STA or an AP? Is it for a STA? • The 233r2 proposal is a minor modification to the co-locatedinterference reporting support already defined in the 802.11vdraft. It does not change the situations in which that support isallowed to be used. As such it may be used in all situations in whichthe existing mechanism may be used.Note that the (normative?) text in the overview (quoted at the startof my 'tutorial') is the only text that goes anywhere near restrictinguse of the co-located interference reporting mechanism to non-AP STAs.In general (again, not 233r2-specific) it seems more likely thatnon-AP STAs will be subject to co-located interference. APs tend notto contain other interfering transceivers. However, the mechanismsthat already exist in 802.11v for co-located interference reportingdo not seem to preclude reporting from AP to STA. Jon Rosdahl, CSR

36. The name of the bit is not clear....it may be better to call it the Transmit Inhibit bit rather than Interference type. • Call it what you like. • Bad naming shouldn't be an argument for leaving it out. Jon Rosdahl, CSR

37. Summary • The only real cost of our proposal is restriction of the Interference Index field to 3 bits meaning that only 7 unique interference sources of a given type (transmit inhibition or receive desense) can be supported simultaneously. • There is no realistic usage scenario in which this would be a limitation. Jon Rosdahl, CSR

38. Benefits • To understand the benefit of our modification you need to be able to recognize three things: - that transmit inhibition interference occurs in realistic use cases - that not all communication with a STA subject to transmit   inhibition interference is precluded - that with knowledge at a peer STA that the interference is transmit inhibition interference (as opposed to receive desense interference) that peer STA *may* choose to schedule those communications that will succeed in presence of transmit inhibition interference Jon Rosdahl, CSR

39. Final Comment • In consideration of the third point it is important to remember that the existing draft provides mechanisms for communicating presence of an interferer. • The only change we propose is to allow the case of transmit inhibition interference to be distinguished through a single flag. Jon Rosdahl, CSR