May 2007 doc IEEE 802 11 070398 r

May 2007 doc. : IEEE 802. 11 -07/0398 r 2 Dedicated Protection Authors: Date: 2007 -05 -16 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: // ieee 802. 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@ok -brit. 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>. Submission 1 Jari Jokela, Yossi Tsfati, Artu Zaks

May 2007 doc. : IEEE 802. 11 -07/0398 r 2 Scope • Coexistence use cases • Coexistence challenges using existing 802. 11 mechanisms • Proposal to improve coexistence • Address concerns raised in TGv at March 2007 meeting Submission 2 Jari Jokela, Yossi Tsfati, Artu Zaks

May 2007 doc. : IEEE 802. 11 -07/0398 r 2 Mobile Radio technology Spectrum Cellular DTV 802. 11 bg & BT GPS Wi. Max 802. 11 a UWB-Band 1 1 • • • 2 3 4 5 6 GHZ Some of the bands are overlapping (BT & WLAN) Some bands are extremely close making analog filtering almost impractical (BT/ WLAN & Wimax) Lo harmonics overlap with other technologies Submission 3 Jari Jokela, Yossi Tsfati, Artu Zaks

May 2007 doc. : IEEE 802. 11 -07/0398 r 2 Coexistence in Handset • Handset can combine multiple access technologies that operate simultaneously: – Have a call coming though Wi. Fi to BT Headset – Access Internet through Wi. MAX/Wi. Fi with cellular call terminating on BT Headset – Play music to the BT Stereo headset from another Handset connected in Wi. Fi ad. Hoc, while accessing Internet through Wi. MAX – And other examples can be listed easily Submission 4 Jari Jokela, Yossi Tsfati, Artu Zaks

May 2007 doc. : IEEE 802. 11 -07/0398 r 2 Wireless Connectivity technologies access principles Example • 802. 11 – Access: CSMA ( infrastructure, Ad. Hoc connection), Scheduled (HCCA, PSMP) – Handset role: Master (adhoc, EDCA), Slave (HCCA, PSMP) • 802. 16 – Access: scheduled TDMA – Handset role: slave • Bluetooth – Access: scheduled TDMA – Handset role: master, slave Submission 5 Jari Jokela, Yossi Tsfati, Artu Zaks

May 2007 doc. : IEEE 802. 11 -07/0398 r 2 Antenna configurations • Separate antenna per connectivity technology – – – BT –single antenna WLAN – one or two (MIMO) antennas Wi. MAX – two antennas Pro: simpler solution Con: footprint on handset, cost • Shared antennas – – BT-WLAN - single antenna WLAN/Wi. MAX - two antennas Pro: footprint, cost Con: system solution is needed to schedule antenna to be used by specific access • In practice, in Handset due to cost and physical limitations, shared antenna approach is more popular that using separate antennas Submission 6 Jari Jokela, Yossi Tsfati, Artu Zaks

May 2007 doc. : IEEE 802. 11 -07/0398 r 2 Coexistence solution using separate antennas • Filter out intrusive signals: decouple BT and WLAN; Wi. MAX and WLAN – Pro: simple system solution – Con: not always possible due to design constraints: filtering 20+ d. B • Enable BT Automatic Frequency Hopping (AFH) to decouple from WLAN – Pro: simple system solution, simultaneous reception of BT and WLAN is possible – Con: Simultaneous Reception and Transmission of the two technologies may not be possible due to limited antenna isolation • When WLAN transmit with high power (18 d. Bm) and typ antenna isolation of 10 d. B, the BT receiver is compressed and looses sensitivity by about 40 d. B which makes it impractical to maintain a BT link • When BT transmit with high power (4 d. Bm at handset) and typ antenna isolation of 10 d. B, the WLAN receiver is compressed and looses sensitivity by about 40 d. B Submission 7 Jari Jokela, Yossi Tsfati, Artu Zaks

May 2007 doc. : IEEE 802. 11 -07/0398 r 2 Challenges using shared antennas • Generally in master/slave configurations the slave has minimal opportunities to schedule its own receptions/transmission as it likes • In CSMA operation, the STA can schedule its own transmission, but no guarantee that AP will deliver downlink traffic in time when antenna is connected to WLAN radio • Since downlink traffic is not synchronized to antenna availability at WLAN packet loss is experienced – Unnecessary retransmissions and reduction of whole BSS capacity – Rate fallback at AP causing disconnection Submission 8 Jari Jokela, Yossi Tsfati, Artu Zaks

May 2007 • • Rate Fallback causing the “Avalanche” Effect All APs use rate adaptation techniques to determine the optimal rate for transmission All APs are using high PER as the main criteria for rate fall back – • PER of over 30% (or even lower) usually causes rate reduction Since the AP response time to U-APSD trigger frames is non deterministic and spreads over period of times that are of the order of the BT inactivity period (2. 5 msec) – There is a chance of AP responded packets to be overlapping with the BT Voice Tx/Rx – • doc. : IEEE 802. 11 -07/0398 r 2 In a co-located radios operation this would cause packet loss and retransmission The probability of losing a packet increases as the rate of transmission decreases (as depicted below for Vo. IP packet length of 244 Bytes (G 711 and additional headers) Network Type Rate 802. 11 b 1 802. 11 g only 802. 11 g mixed 2 5. 5 11 6 12 24 Exchange Length (usec) 2458 1416 794. 9 617. 5 404 248 168 660 496 416 Fail Rate 98. 3 31. 8 24. 7 16. 2 9. 9 6. 7 26. 4 19. 8 16. 6 • • 56. 6 Once the AP starts reducing the rate it would continue to do so until reaching 1 Mbps since the probability of packet loss is increasing as the rate is reduced An AP reaching 1 Mbps transmission rate may eventually disconnect the STA since it would not be able to transfer hardly any packet to it Submission 9 Jari Jokela, Yossi Tsfati, Artu Zaks

May 2007 doc. : IEEE 802. 11 -07/0398 r 2 Solutions using existing mechanisms and their limitations • Synchronizing downlink traffic using channel protection with CTS-to-self control frame • Re-association to bring the rates up and overcome ratefallback • What are the limitations of the existing mechanisms? – Diminished channel capacity – Service Disruption to other network users due to traffic patterns Submission 10 Jari Jokela, Yossi Tsfati, Artu Zaks

May 2007 doc. : IEEE 802. 11 -07/0398 r 2 CTS-to-self frame for channel protection • Using PS-Poll Power. Save Mode • CTS-to-self is used as Channel Protection • NAV contained in the message is suitable to cover for the BT activity which comes sooner than the AP response time • During the NAV duration the entire BSS transport is blocked • The frequency of the CTS-to-self used for channel protection depends on the BT traffic load and effects the BSS throughput Submission 11 Jari Jokela, Yossi Tsfati, Artu Zaks

May 2007 doc. : IEEE 802. 11 -07/0398 r 2 Analysis of BSS Throughput Using CTS-to-self frames Expected performances for the extremely severe scenario: • 1 or 2 stations having HV 3 with CTS-to-self protection • 1 or 2 stations having high downlink throughput • No other stations in the BSS (max theoretical abuse) • Assumes that the WLAN STA has a fairness rule to limit airtime This fairness rule is expressed as the number of BT HP slots that the WLAN needs to wait from the end of the WLAN transaction to the next data pulling (e. g. : next PS-POLL) Using ‘ 802. 11. b' 11 Mbps only, 1500 Byte packets, Assuming BT-HP to CTS-to-self =1000 u. Sec Submission 12 Jari Jokela, Yossi Tsfati, Artu Zaks

May 2007 doc. : IEEE 802. 11 -07/0398 r 2 Proposal for possible solutions to improve coexistence/ shared antenna operation • Dedicated protection – – • Schedule adaptation based on STA synchronization requests – • When operating in S-APSD, PSMP modes Downlink rate limiting – • Data/Null-data or Management/Control frame discussion Immediate protection, delayed protection Management to request AP to limit the rates (so rate fallback will stop at higher rate) Co-located interference reporting – Can be used scheduling&rate adaptation purposes This proposal outlines “dedicated protection” mechanism Submission 13 Jari Jokela, Yossi Tsfati, Artu Zaks

May 2007 doc. : IEEE 802. 11 -07/0398 r 2 Dedicated Protection: Non-AP STA and AP operation • When non-AP STA realizes that it needs to protect other radio operation it sends dedicated protection information to the AP • When the AP receives the dedicated protection information from the non-AP STA it shall not send any unicast frames to the non-AP STA during the protection period. • Other non-AP STAs can ignore the dedicated protection field. Submission 14 Jari Jokela, Yossi Tsfati, Artu Zaks

May 2007 doc. : IEEE 802. 11 -07/0398 r 2 Dedicated Protection – Extended protection frame • Using Data Frame with extended field to the MAC Header as “Piggyback” – New field added to the MAC Header (HT MAC Header assumed) – NULL data frame is sent in case of there is no data required to be sent Octets: 2 Frame Control 2 6 6 6 2 Sequence Duration/ID Address 1 Address 2 Address 3 Control 6 Address 4 2 Qo. S Control 4 4 Dedicated HT Control Protection • Dedicated protection field is a 4 octets including two sub fields (each with size of 2 octets): – Start Time – the two least significant bytes of TSF timer to indicate start time – Protection Duration – the duration (in u. Sec) after the above start time Submission 15 Jari Jokela, Yossi Tsfati, Artu Zaks

May 2007 doc. : IEEE 802. 11 -07/0398 r 2 Dedicated Protection use case: defer AP downlink transmission to STA 1 when STA 1 has High Priority BT traffic Submission 16 Jari Jokela, Yossi Tsfati, Artu Zaks

May 2007 doc. : IEEE 802. 11 -07/0398 r 2 Explicit Dedicated protection Definition using Existing Header Fields (Queue Size = 255) • • • Reuse of Queue Size field = 255 ( Unspecified Queue size). Spec definition, from 7. 1. 3. 5. 5 Queue Size subfield: “A queue size value of 255 is used to indicate an unspecified or unknown size. ” Propose to change the definition of the QOS Control field in QOS Data/QOS Null frames sent by STA with Bit 4=1: indicate request for dedicated downlink protection by setting Queue. Size to value 255 Dedicated DL Protection field will follow QOSControl or HT Control The new field is not encrypted and muted for MIC AAD construction Submission 17 Jari Jokela, Yossi Tsfati, Artu Zaks

May 2007 doc. : IEEE 802. 11 -07/0398 r 2 Definition – Option Analysis Option 1: Define Explicitly Using Existing Header Fields (QOSControl) Option 2: Implicit association Option 3: new Ethertype Option 4: New data type Ease of definition/ Impact on spec Easy: change meaning of the “unspecified queue size” to “dedicated DL protection”. Impact: Small, easier to get agreement as HCCA is not implemented widely, the value of 255 is off the bounds. Medium: need to define procedures on AP & STA. Impact: hard to get agreement, as there is no precedent in 802. 11 to handle the header extension in such way Medium: need to define procedures on AP & STA. Impact: hard to get agreement, though there are examples in 802. 11 ( EAPOL, EAPOL-over -DS) Complex: define new datatypes and frame exchange sequences Impact: very hard to get agreement, as TGv perception is no change to HW, defining new datatype and frame exchange sequences means HW change. Ease of implementation Easy, SW implementation in lowlevel MAC at AP. Easy, SW implementation in lowlevel MAC. Medium, HW implementation to handle frame exchange sequence. Effectiveness Fast AP Response time ~100 u. S can be achieved AP Response time ~1 m. S can be achieved due to need to decrypt SNAP header AP Response time of sub-100 u. S is possible Preference for definition (1 -4), High to Low 1 3 2 4 Submission 18 Jari Jokela, Yossi Tsfati, Artu Zaks

May 2007 doc. : IEEE 802. 11 -07/0398 r 2 Support of Dedicated Protection in IBSS • STA with Dedicated Protection capability joining IBSS sends Broadcast Action Frame with Wireless Network Management Capabilities – All STAs that receive this frame can use Dedicated Protection mechanism with this STA – Broadcast Action frame with Wireless Network Management Capabilities is sent periodically, with period of defined in MIB (dot 11 Dedicated. Protection. Advertize. Period. ) • IBSS STAs maintain the list of the STAs supporting Dedicated Protection, after receiving the Action frame. • STAs may use Dedicated Protection with the STAs that are in the list • After some time the entry is deleted from the list, if Broadcast Action frame is not received from it Submission 19 Jari Jokela, Yossi Tsfati, Artu Zaks

May 2007 doc. : IEEE 802. 11 -07/0398 r 2 Support of Dedicated Protection in Mesh. Network • MP with Dedicated Protection capability joins MESH, it sends Broadcast Action Frame with Wireless Network Management Capabilities – All MPs that receive this frame can use Dedicated Protection mechanism with this STA – Broadcast Action frame with Wireless Network Management Capabilities is set periodically, with period defined in MIB • MESH MPs maintain the list of the MPs supporting Dedicated Protection, after receiving the Action frame • MPs may use Dedicated Protection with the MPs that are in the list. • After some time the entry is deleted from the list, if Broadcast Action frame is not received from it Submission 20 Jari Jokela, Yossi Tsfati, Artu Zaks

May 2007 doc. : IEEE 802. 11 -07/0398 r 2 Broadcast Action Frame used in IBSS/MESH to advertise Dedicated Protection capability • Define new Action: Capability Advertisement – Category = Wireless Network Management – Action = Capability Advertisement (15) – Action body: Wireless Network Management Capability IE • Changed Reserved Bit (#7) in the Wireless Network Management Capabilities IE to indicate Dedicated Protection Capability – Set the capability to ‘ 1’ if Dedicated Protection is supported and Enabled – Set the capability to ‘ 0’ otherwise Submission 21 Jari Jokela, Yossi Tsfati, Artu Zaks

May 2007 doc. : IEEE 802. 11 -07/0398 r 2 Addressing specific concerns raised in March meeting • How to handle DL broadcast/multicast transmissions, i. e. should the protection concern only unicast frames or should BC/MC frames also considered? – Problem: when using Protection, Broadcast traffic can be missed – Recommendation: • Dedicated Protection is not used for BC/MC traffic, i. e. the AP can send BC/MC frames despite of the Dedicated Protection requests • Work in PS mode when Protection is needed – to concentrate BC traffic at a single time location and thus limit occasion of traffic loss • Relay on application level protocols to retransmit BC messages (e. g. : missed ARP messages) • Throttle antenna switch to allow occasional BC traffic delivery over WLAN, while affecting service shortly on BT • Do not use Multicast downlink streaming if terminals with coexistence are present in the BSS Submission 22 Jari Jokela, Yossi Tsfati, Artu Zaks

May 2007 doc. : IEEE 802. 11 -07/0398 r 2 Addressing specific concerns raised in March meeting (cont) • How the terminal can control when it is sending the protection frame (channel access times can be different when the load is different)? – Having start time&duration in the Dedicated Protection field makes it easier to control dedicated protection periods => it is not crucial when the Dedicated Protection time is exactly sent given that it is before the targeted protection period – Use protected frame when other solutions are not possible: AP has slow delivery time, cannot request DL schedule change Submission 23 Jari Jokela, Yossi Tsfati, Artu Zaks

May 2007 doc. : IEEE 802. 11 -07/0398 r 2 Addressing specific concerns raised in March meeting (cont) • Should we use control or management frame for extended protection? – Data frame is preferable • • “Piggyback” protection indication to limit overhead Simpler solution: limited to a lower layers of the implementation Easy to deploy Con: need to find a spare bit in the header to distinguish the additional protection field – Management frame • • Easy to add to the protocol – another Action frame Use for rate limiting, to set schedule May effect BSS capacity since additional messages are sent More complex to deploy – New Control frame – not preferable solution • Backward compatibility • Requires HW implementation Submission 24 Jari Jokela, Yossi Tsfati, Artu Zaks

May 2007 doc. : IEEE 802. 11 -07/0398 r 2 Addressing specific concerns raised in March meeting (cont) • Is this having impact to basic fairness (i. e. Qo. S)? – When protection is used, single STA is affected – no influence on other STAs • So actually this can be seen as a positive enhancement from both the requesting STA and all the other STAs point of view – Only Downlink is affected – Implementation in STA has to find balance to meet QOS needed by applications: limit latency, jitter Submission 25 Jari Jokela, Yossi Tsfati, Artu Zaks

May 2007 doc. : IEEE 802. 11 -07/0398 r 2 Backup Slides The Original Presentation from March on Dedicated Protection Submission 26 Jari Jokela, Yossi Tsfati, Artu Zaks

May 2007 doc. : IEEE 802. 11 -07/0398 r 2 Abstract This presentation introduces a mechanism that enables coordination of DL transmissions in case of multiradio terminals are present in the BSS Proposed mechanism is related to req. #2071 Submission 27 Jari Jokela, Yossi Tsfati, Artu Zaks

May 2007 doc. : IEEE 802. 11 -07/0398 r 2 Introduction • Multiradio challenges in terminals were already discussed in 06/0647 r 7 – Key issue is to control WLAN DL transmissions – Normative text in 06/0645 r 3 (adopted and included in current TGv draft) contains mechanism where the terminal can report it is realizing performance degradation caused by other co-located system • The performance of the adopted scheme is dependent on the AP implementation – How good and robust AP’s rate adaptation algorithm and/or scheduling algorithms are – In best case provides very good performance but assumes some increased complexity in the AP side • In this presentation simpler, complementary, scheme is presented Submission 28 Jari Jokela, Yossi Tsfati, Artu Zaks

May 2007 doc. : IEEE 802. 11 -07/0398 r 2 Multiradio problem in more details BT WLAN Rx/Tx Tx/Rx Rx/Tx 20 ms =32 BT slots • Simultaneous WLAN and BT (e. g. WLAN Vo. IP with BT headset) usage is causing problems. – – • 802. 15. 2 is not solving the problem – – • WLAN and BT TX/RX slots will overlap periodically Up to 13% packet loss in BT and up to 30% packet loss in WLAN! 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. Key issue is how to control WLAN DL transmissions so that the collisions does not occur Submission 29 Jari Jokela, Yossi Tsfati, Artu Zaks

May 2007 doc. : IEEE 802. 11 -07/0398 r 2 Proposed scheme – Dedicated protection • Mechanism to enable a non-AP STA to indicate when it is not able to receive any WLAN transmissions without having any substantial impact to the other non-AP STAs => dedicated protection information. • Dedicated protection information – Used by the non-AP STA to protect certain amount of time • During this time the AP shall not send anything to the STA • During this period the AP and the other non-AP STAs can freely transmit frames (of course subject to the normal channel access procedures) • Typically protected time is short, from hundreds of microseconds to ~ millisecond • Dedicated protection information is carried – In data frames MAC Header – In new control frame – Dedicated Protection Request Submission 30 Jari Jokela, Yossi Tsfati, Artu Zaks

May 2007 doc. : IEEE 802. 11 -07/0398 r 2 Non-AP STA and AP operation • When non-AP STA realizes that it needs to protect other radio operation it sends dedicated protection information to the AP • When the AP receives the dedicated protection information from the non-AP STA it shall not send any frames (including bc/mc frames) to the non-AP STA during the protection period. • Other non-AP STAs can ignore the dedicated protection field. Submission 31 Jari Jokela, Yossi Tsfati, Artu Zaks

May 2007 doc. : IEEE 802. 11 -07/0398 r 2 Extended protection frame types • Data frame – New field added to the MAC Header (HT MAC Header assumed) Octets: 2 Frame Control 2 6 6 6 2 Sequence Duration/ID Address 1 Address 2 Address 3 Control 6 Address 4 2 Qo. S Control 4 2 Dedicated HT Control Protection • New control frame – Dedicated Protection Request Octets: 2 Frame Control 2 6 6 Duration/ID RA TA 2 Dedicated Protection 4 FCS • Dedicated protection field indicates the requested protection time in microseconds. Dedicated protection time is indicated as on top of normal NAV protection. Submission 32 Jari Jokela, Yossi Tsfati, Artu Zaks

May 2007 doc. : IEEE 802. 11 -07/0398 r 2 Examples Dedicated protection with data frame – Non-AP STA is having UL data Non-AP STA AP Data frame with dedicated protection element Protect by NAV ACK Protect by Dedicated protection element Dedicated protection with Dedicated Protection Request – Non-AP STA is not having UL data Non-AP STA AP Dedicated Protection Request Protect by NAV ACK Protect by Dedicated protection element Submission 33 Jari Jokela, Yossi Tsfati, Artu Zaks

May 2007 doc. : IEEE 802. 11 -07/0398 r 2 Other solutions • Use power save modes – Not really attractive solution as PS switching is done very often – Terminal may want to use this mechanism while continuosly in PS mode • Use CTS-to-self to protect other radio activity – Works but not scalable to enterprise/operator deployments where the number of associated STAs and load are high Submission 34 Jari Jokela, Yossi Tsfati, Artu Zaks

May 2007 doc. : IEEE 802. 11 -07/0398 r 2 Conclusions • Dedicated protection mechanism provides simple means to control co-located interference • Target is not to replace co-located interference mechanism but have simple complementary mechanism – Can be used if performance issues with co-located interference reporting scheme – Can be used if the AP has disabled co-located interference scheme • No impact to other STAs operation => scalable to enterprise and operator networks Submission 35 Jari Jokela, Yossi Tsfati, Artu Zaks

May 2007 doc. : IEEE 802. 11 -07/0398 r 2 Straw poll Is Task Group V supportive of 11 -07/0398 r 1 and interested in having author draft normative text for inclusion into TGv draft? Submission 36 Jari Jokela, Yossi Tsfati, Artu Zaks