doc.: ieee 802.11-07/0398r2 submission may 2007 jari jokela, yossi tsfati, artu zaksslide 1...
Post on 16-Dec-2015
215 Views
Preview:
TRANSCRIPT
May 2007
Jari Jokela, Yossi Tsfati, Artu Zaks
Slide 1
doc.: IEEE 802.11-07/0398r2
Submission
Dedicated Protection
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@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>.
Date: 2007-05-16
Name Company Address Phone email Jari Jokela Nokia Visiokatu 3,
Tampere, Finland +358504860445
Jari.jokela@nokia.com
Yossi Tsfati Texas Instruments
26 Zarchin St, Raanana, Israel
+972-97476927
Yossit@ti.com
Artur Zaks Texas Instruments
26 Zarchin St, Raanana, Israel
+972- 9 7476853
Arturz@ti.com
Authors:
May 2007
Jari Jokela, Yossi Tsfati, Artu Zaks
Slide 2
doc.: IEEE 802.11-07/0398r2
Submission
Scope
• Coexistence use cases
• Coexistence challenges using existing 802.11 mechanisms
• Proposal to improve coexistence
• Address concerns raised in TGv at March 2007 meeting
May 2007
Jari Jokela, Yossi Tsfati, Artu Zaks
Slide 3
doc.: IEEE 802.11-07/0398r2
Submission
Mobile Radio technology Spectrum
1 2 3 4 5 6
802.11bg & BT
UWB-Band1
802.11a
GHZ
WiMax
DTV
GPS
Cellular
• 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
May 2007
Jari Jokela, Yossi Tsfati, Artu Zaks
Slide 4
doc.: IEEE 802.11-07/0398r2
Submission
Coexistence in Handset
• Handset can combine multiple access technologies that operate simultaneously:– Have a call coming though WiFi to BT Headset
– Access Internet through WiMAX/WiFi with cellular call terminating on BT Headset
– Play music to the BT Stereo headset from another Handset connected in WiFi adHoc, while accessing Internet through WiMAX
– And other examples can be listed easily
May 2007
Jari Jokela, Yossi Tsfati, Artu Zaks
Slide 5
doc.: IEEE 802.11-07/0398r2
Submission
Wireless Connectivity technologies access principles
Example• 802.11
– Access: CSMA ( infrastructure, AdHoc 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
May 2007
Jari Jokela, Yossi Tsfati, Artu Zaks
Slide 6
doc.: IEEE 802.11-07/0398r2
Submission
Antenna configurations• Separate antenna per connectivity technology
– BT –single antenna– WLAN – one or two (MIMO) antennas– WiMAX – two antennas– Pro: simpler solution– Con: footprint on handset, cost
• Shared antennas– BT-WLAN - single antenna– WLAN/WiMAX - 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
May 2007
Jari Jokela, Yossi Tsfati, Artu Zaks
Slide 7
doc.: IEEE 802.11-07/0398r2
Submission
Coexistence solution using separate antennas
• Filter out intrusive signals: decouple BT and WLAN; WiMAX and WLAN– Pro: simple system solution– Con: not always possible due to design constraints: filtering 20+
dB• 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 (18dBm) and typ antenna
isolation of 10dB, the BT receiver is compressed and looses sensitivity by about 40dB which makes it impractical to maintain a BT link
• When BT transmit with high power (4dBm at handset) and typ antenna isolation of 10dB, the WLAN receiver is compressed and looses sensitivity by about 40dB
May 2007
Jari Jokela, Yossi Tsfati, Artu Zaks
Slide 8
doc.: IEEE 802.11-07/0398r2
Submission
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
May 2007
Jari Jokela, Yossi Tsfati, Artu Zaks
Slide 9
doc.: IEEE 802.11-07/0398r2
Submission
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.5msec) – There is a chance of AP responded packets to be overlapping with the BT Voice Tx/Rx
– 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 VoIP packet length of 244 Bytes (G711 and additional headers)
Network Type 802.11b 802.11g only 802.11g mixed
Rate 1 2 5.5 11 6 12 24 6 12 24
Exchange Length (usec) 2458 1416 794.9 617.5 404 248 168 660 496 416
Fail Rate 98.3 56.6 31.8 24.7 16.2 9.9 6.7 26.4 19.8 16.6
• Once the AP starts reducing the rate it would continue to do so until reaching 1Mbps since the probability of packet loss is increasing as the rate is reduced
• An AP reaching 1Mbps transmission rate may eventually disconnect the STA since it would not be able to transfer hardly any packet to it
May 2007
Jari Jokela, Yossi Tsfati, Artu Zaks
Slide 10
doc.: IEEE 802.11-07/0398r2
Submission
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 rate-fallback
• What are the limitations of the existing mechanisms?– Diminished channel capacity
– Service Disruption to other network users due to traffic patterns
May 2007
Jari Jokela, Yossi Tsfati, Artu Zaks
Slide 11
doc.: IEEE 802.11-07/0398r2
Submission
CTS-to-self frame for channel protection
CTS-TO-SELF
ACK
PS-POLL
T1 (3.75mSec for HV3)
T3
T2BT Inactivity period (2.5mSec for HV3)
T4
STA
BT_HP
AP
T5 (NAV)Covers for predicted BT’s Tx/Rx activity AP which comes sooner than AP response time
MSDU
ACK
T6 (AP DL Response Time)
• Using PS-Poll PowerSave 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
May 2007
Jari Jokela, Yossi Tsfati, Artu Zaks
Slide 12
doc.: IEEE 802.11-07/0398r2
Submission
Using ‘802.11.b' 11Mbps only, 1500 Byte packets, Assuming BT-HP to CTS-to-self =1000uSec
Expected performances for the extremely severe scenario:• 1 or 2 stations having HV3 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)
Analysis of BSS Throughput UsingCTS-to-self frames
# STA in BSS with Time Scheduling Coexistence Scheme 1 2
WLAN Fairness Factor: Number of BT slots that WLAN waits before pulling MSDU - [expressed in BT
slots] 0 6 12 18 0 6 12 18Used WLAN BW [%] 67 33 22 17 69 42 30 24
Max downlink throughput [Mbps] 3.2 1.6 1.07 0.8 2.16 1.25 0.9 0.7
May 2007
Jari Jokela, Yossi Tsfati, Artu Zaks
Slide 13
doc.: IEEE 802.11-07/0398r2
Submission
Proposal for possible solutions to improve coexistence/ shared antenna operation
• Dedicated protection– Data/Null-data or Management/Control frame discussion– Immediate protection, delayed protection
• Schedule adaptation based on STA synchronization requests– When operating in S-APSD, PSMP modes
• Downlink rate limiting– 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
May 2007
Jari Jokela, Yossi Tsfati, Artu Zaks
Slide 14
doc.: IEEE 802.11-07/0398r2
Submission
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.
May 2007
Jari Jokela, Yossi Tsfati, Artu Zaks
Slide 15
doc.: IEEE 802.11-07/0398r2
Submission
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
Frame Control
Duration/ID Address 1 Address 2 Address 3Sequence
ControlAddress 4
QoS Control
HT ControlDedicated Protection
Octets: 2 2 6 6 6 2 6 2 4 4
• 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 uSec) after the above start
time
May 2007
Jari Jokela, Yossi Tsfati, Artu Zaks
Slide 16
doc.: IEEE 802.11-07/0398r2
Submission
Dedicated Protection use case: defer AP downlink transmission to STA1 when STA1 has High
Priority BT traffic
ACK
3.75 mS Bluetooth HV3 Period
BT Inactivity period (2.5mSec for HV3)
STA2
BT_HP
APMSDU to STA1
ACK
MSDU to AP +
Dedicated Prot Req from t1 for P1
STA1ACK
AP defers transmission to STA1 but can transmit to STA2
MSDU to STA2
t1
P1
Time
May 2007
Jari Jokela, Yossi Tsfati, Artu Zaks
Slide 17
doc.: IEEE 802.11-07/0398r2
Submission
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 Bit4=1: indicate request for dedicated downlink protection by setting QueueSize 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
May 2007
Jari Jokela, Yossi Tsfati, Artu Zaks
Slide 18
doc.: IEEE 802.11-07/0398r2
Submission
Definition – Option AnalysisOption1:Define Explicitly Using Existing Header Fields (QOSControl)
Option2: Implicit association
Option3: new Ethertype Option4: 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 low-level MAC at AP.
Easy, SW implementation in low-level MAC.
Easy, SW implementation in low-level MAC.
Medium, HW implementation to handle frame exchange sequence.
Effectiveness Fast AP Response time ~100uS can be achieved
Fast AP Response time ~100uS can be achieved
AP Response time ~1mS can be achieved due to need to decrypt SNAP header
AP Response time of sub-100uS is possible
Preference for definition (1-4), High to Low
1 3 2 4
May 2007
Jari Jokela, Yossi Tsfati, Artu Zaks
Slide 19
doc.: IEEE 802.11-07/0398r2
Submission
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 (dot11DedicatedProtectionAdvertizePeriod. )
• 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
May 2007
Jari Jokela, Yossi Tsfati, Artu Zaks
Slide 20
doc.: IEEE 802.11-07/0398r2
Submission
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
May 2007
Jari Jokela, Yossi Tsfati, Artu Zaks
Slide 21
doc.: IEEE 802.11-07/0398r2
Submission
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
Category ActionWireless Network Management
Capabilities IE
1 1
Dialog Token
n
May 2007
Jari Jokela, Yossi Tsfati, Artu Zaks
Slide 22
doc.: IEEE 802.11-07/0398r2
Submission
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
May 2007
Jari Jokela, Yossi Tsfati, Artu Zaks
Slide 23
doc.: IEEE 802.11-07/0398r2
Submission
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
May 2007
Jari Jokela, Yossi Tsfati, Artu Zaks
Slide 24
doc.: IEEE 802.11-07/0398r2
Submission
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
May 2007
Jari Jokela, Yossi Tsfati, Artu Zaks
Slide 25
doc.: IEEE 802.11-07/0398r2
Submission
Addressing specific concerns raised in March meeting (cont)
• Is this having impact to basic fairness (i.e. QoS)?– 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
May 2007
Jari Jokela, Yossi Tsfati, Artu Zaks
Slide 26
doc.: IEEE 802.11-07/0398r2
Submission
Backup Slides
The Original Presentation from March on Dedicated Protection
May 2007
Jari Jokela, Yossi Tsfati, Artu Zaks
Slide 27
doc.: IEEE 802.11-07/0398r2
Submission
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
May 2007
Jari Jokela, Yossi Tsfati, Artu Zaks
Slide 28
doc.: IEEE 802.11-07/0398r2
Submission
Introduction
• Multiradio challenges in terminals were already discussed in 06/0647r7– Key issue is to control WLAN DL transmissions– Normative text in 06/0645r3 (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
May 2007
Jari Jokela, Yossi Tsfati, Artu Zaks
Slide 29
doc.: IEEE 802.11-07/0398r2
Submission
Multiradio problem in more details
• 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.• Key issue is how to control WLAN DL transmissions so that the collisions does not occur
20ms =32 BT slots
Tx Rx Tx Rx Tx Rx Tx Rx Tx Rx Tx RxBT
WLANRx/Tx Rx/TxTx/Rx
May 2007
Jari Jokela, Yossi Tsfati, Artu Zaks
Slide 30
doc.: IEEE 802.11-07/0398r2
Submission
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
May 2007
Jari Jokela, Yossi Tsfati, Artu Zaks
Slide 31
doc.: IEEE 802.11-07/0398r2
Submission
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.
May 2007
Jari Jokela, Yossi Tsfati, Artu Zaks
Slide 32
doc.: IEEE 802.11-07/0398r2
Submission
Extended protection frame types
• Data frame– New field added to the MAC Header (HT MAC Header assumed)
Frame Control
Duration/ID Address 1 Address 2 Address 3Sequence
ControlAddress 4
QoS Control
HT ControlDedicated Protection
Octets: 2 2 6 6 6 2 6 2 4 2
• New control frame – Dedicated Protection Request
Frame Control
Duration/ID RA TADedicated Protection
Octets: 2 2 6 6 2 4
FCS
• Dedicated protection field indicates the requested protection time in microseconds. Dedicated protection time is indicated as on top of normal NAV protection.
May 2007
Jari Jokela, Yossi Tsfati, Artu Zaks
Slide 33
doc.: IEEE 802.11-07/0398r2
Submission
Protect by Dedicated protection element
Examples
Dedicated protection with data frame– Non-AP STA is having UL data
Non-AP STA APData frame with dedicated protection element
ACKProtect by NAV
Dedicated protection with Dedicated Protection Request– Non-AP STA is not having UL data
Non-AP STA APDedicated Protection Request
ACKProtect by NAV
Protect by Dedicated protection element
May 2007
Jari Jokela, Yossi Tsfati, Artu Zaks
Slide 34
doc.: IEEE 802.11-07/0398r2
Submission
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
May 2007
Jari Jokela, Yossi Tsfati, Artu Zaks
Slide 35
doc.: IEEE 802.11-07/0398r2
Submission
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
top related