Co-located Interference diagnostics September 2006 doc.: IEEE 802.11-06/0646r6 September 2006 Co-located Interference diagnostics Date: 2006-09-18 Authors: Notice: This document has been prepared to assist IEEE 802.11. 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.11. Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures <http:// ieee802.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 <stuart.kerry@philips.com> 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.11 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at <patcom@ieee.org>. Jari Jokela et al, Nokia, Conexant, InterDigital Jari Jokela, Nokia

September 2006 doc.: IEEE 802.11-06/0646r6 September 2006 Abstract This presentation gives overview of proposed interference detection and diagnostic mechanism. The mechanism is specifically intended to be used in terminals having multiple radios (or other interference sources). Related to Req2071: Contention TGv shall provide a mechanism for notification of performance degradation due to contention issues in multi-radio devices. Normative text: 06/0645r2 Jari Jokela et al, Nokia, Conexant, InterDigital Jari Jokela, Nokia

Multiradio challenges September 2006 Multiradio challenges In multiradio devices it is possible that activity of other radio causes degradation in devices WLAN receiver performance GSM and WLAN simultaneous operation WLAN - BT may collide Other radios may cause similar effects Typically these are not continuous degradations and typically they have certain characteristics For example, GSM/GPRS and BT have certain slot structures and degraded performance is experienced periodically. Jari Jokela et al, Nokia, Conexant, InterDigital

September 2006 Multiradio Use Cases Internet access (web browsing, email, …) with WLAN and simultaneous voice call with cellular Local content access via WLAN and cellular for corporate/other access During IEEE meeting WLAN access to meeting documents and simultaneously GPRS connection (with VPN) to corporate emails Content down/upload to/from handheld terminal using WLAN and simultaneous voice call with cellular Images & video clips, Audio (mp3) Storage capacity in new handheld terminals is measured in Gbytes Jari Jokela et al, Nokia, Conexant, InterDigital

Multiradio Use Cases WLAN VoIP using BT headset September 2006 VoIP traffic BT Headset Jari Jokela et al, Nokia, Conexant, InterDigital

Example: WLAN - BT September 2006 20ms =32 BT slots BT WLAN Tx/Rx Rx/Tx Simultaneous WLAN and BT (e.g. WLAN VoIP with BT headset) usage is causing problems. WLAN and BT TX/RX slots will overlap periodically Up to 13% packet loss in BT and up to 30% packet loss in WLAN! 802.15.2 is not solving the problem Can control STA side but cannot control AP side, i.e., cannot control WLAN DL transmissions => collisions occurs. If WLAN AP rate adaptation algorithm just decides to go to more robust mode the collisions are just increasing and whole BSS capacity is decreasing. Jari Jokela et al, Nokia, Conexant, InterDigital

Co-located Interference information September 2006 Co-located Interference information A mechanism that enables STA to indicate its current interference situation could be useful. Can indicate ‘interference slots’ Co-located radio(s) case May be used to finetune APs rate adaptation/scheduling algorithms Jari Jokela et al, Nokia, Conexant, InterDigital

Proposal: Co-located Interference Reporting September 2006 Proposal: Co-located Interference Reporting Co-located Interference Request/Response procedure AP can enable automatic reporting STA reports if co-located interference level is significantly changing: Co-located interference starts Level of co-located interference significantly changes Time characteristics of interference changes Co-located interference stops Examples - see slide 14 Jari Jokela et al, Nokia, Conexant, InterDigital

Interference Request September 2006 Jari Jokela et al, Nokia, Conexant, InterDigital

Interference Response September 2006 Interference Response The Interference Level field is a signed integer indicating the level of the expected self-interference in units of dBm. The Interference Interval field indicates the interval between two successive periods of interference in microseconds. The Interference Burst Length field indicates the duration of each period of interference in microseconds. The Interference Start Time field contains the least significant 4 bytes of the TSF timer at the start of the next interference burst. Alternatively it can indicate the average duty cycle of interference. The Interference Signature field indicates the type of the system causing the reported interference. Jari Jokela et al, Nokia, Conexant, InterDigital

Interference Signature September 2006 Interference Signature Used to indicate the type of interference Value Interference Type Bluetooth 1 GSM 2 WCDMA 3 Other 4 – 255 Reserved Jari Jokela et al, Nokia, Conexant, InterDigital

Examples September 2006 b) a) c) TSF = n k i i d Report: - Interference Level = i Interference Interval = 0 Interference Burst Length = 0 Interference Start Time = 0 Report: - Interference Level = 0 - Interference Interval = 0 - Interference Burst Length = 0 - Interference Start Time = 0 Report: - Interference Level = i - Interference Interval = d - Interference Burst Length = k - Interference Start Time = n Report: - Interference Level = 0 - Interference Interval = 0 - Interference Burst Length = 0 - Interference Start Time = 0 c) i2 i1 Report: - Interference Level = i1 Interference Interval = 0 Interference Burst Length = 0 Interference Start Time = 0 Report: - Interference Level = i2 Interference Interval = 0 Interference Burst Length = 0 Interference Start Time = 0 Report: - Interference Level = i1 Interference Interval = 0 Interference Burst Length = 0 Interference Start Time = 0 Report: - Interference Level = 0 Interference Interval = 0 Interference Burst Length = 0 Interference Start Time = 0 Jari Jokela et al, Nokia, Conexant, InterDigital

Usage of Co-located Interference information September 2006 Usage of Co-located Interference information AP can request the information or setup automatic reporting If STA reports interference, AP may use this information for rate adaptation and/or scheduling purposes Rate adaptation: Pure SNR/RCPI/RSSI and/or retransmission rate based rate adaptation logic may not work well in case of STA is having co-located radio interference Often going to more robust PHY rate just makes the situation worse Scheduling: AP may try to avoid interference slots especially if the interference level indicates high interference No impact to other STAs operation Jari Jokela et al, Nokia, Conexant, InterDigital

September 2006 Other solutions Use power save mode and use PS POLL or trigger frames to control AP DL transmissions Even if the STA can control when it sends the PS POLL or trigger frame the DL transmissions are not deterministic => not possible to avoid interference burst Use CTS-to-self to protect interference burst Considered to be too radical => will have impact to the whole BSS operation due to local interference issue => all the STAs are impacted due to interference in single STA Jari Jokela et al, Nokia, Conexant, InterDigital

September 2006 Conclusion Mechanism to allow the STA to indicate its co-located interference situation seem to be useful feature In some usage co-located interference scenarios significant frame losses can be realized if the AP does not take into account STA’s (co-located) interference situation Managing the co-located interference is not only single STA management but the whole BSS performance management Proposed mechanism is simple way to exchange information between the STAs and the AP AP can fully control when to enable reports from the STAs AP can use the information as it wants (rate adaptation, scheduling,…) Jari Jokela et al, Nokia, Conexant, InterDigital

September 2006 doc.: IEEE 802.11-06/0646r6 September 2006 Motion Move to include normative text in document 11-06-0645-02-000v-interference-diagnostic into the TGv draft. Mover: Seconder: Results: Jari Jokela et al, Nokia, Conexant, InterDigital Jari Jokela, Nokia