doc.: IEEE 802.11-10/1244r1 Submission Nov.2010 Sun Bo, ZTE Corp Slide 1 Authors: Transmission Mechanism in MU- MIMO Date: 2010-11-10 N am e A ffiliations A ddress Phone Em ail Sun Bo ZTE Corporation N o.10 Sth Tangyan Rd. X i’an, China 86 29 88723975 Sun.Bo1@ zte.com .cn Tian K aibo ZTE Corporation N o.10 Sth Tangyan Rd. X i’an, China 86 29 88723973 [email protected]Lv K aiying ZTE Corporation N o.10 Sth Tangyan Rd. X i’an, China 86 29 88724130 [email protected]Zhendong Luo China A cadem y of Telecom munication Research (CA TR) N o.52 H uayuan BeiRd. Beijing, China 86 10 62300171 luozhendong@ catr.cn Siyang Liu China A cadem y of Telecom munication Research (CA TR) N o.52 H uayuan BeiRd. Beijing, China 86 10 62300175 [email protected]Liang Peng China Telecom No. 118, Xizhim engnei St.,Beijing, China 86 10 58552342 [email protected]
Transcript
doc.: IEEE 802.11-10/1244r1
Submission
Nov.2010
Sun Bo, ZTE CorpSlide 1
Authors:
Transmission Mechanism in MU-MIMO
Date: 2010-11-10
Name Affiliations Address Phone Email
Sun Bo ZTE Corporation No.10 Sth Tangyan Rd. Xi’an, China
A detailed transmission mechanism for MU-MIMO are proposed in this contribution, including protective mechanism with CTS-to-Self and scheduled multiple RTS/CTS frame changes, MU-MIMO data transmission, scheduled ACK and exception handling.
doc.: IEEE 802.11-10/1244r1
Submission
Nov.2010
Sun Bo, ZTE CorpSlide 3
Background
• Current data transmission mechanism was designed for SU-MIMO only– Tx STA sends RTS addressing one Rx STA with one RA field.
– Rx STA addressed by the RA field responds with CTS.
– Not all recipients’ neighbors can be protected.
• Challenges to MU-MIMO data transmission:– Define multiple recipients RTS/CTS protective mechanism.
– Define MU-MIMO data selection method.
– Define multiple recipients ACK scheduling.
– Define retransmission rules.
– Be compatible with legacy devices.
doc.: IEEE 802.11-10/1244r1
Submission
Nov.2010
Sun Bo, ZTE CorpSlide 4
MU-MIMO Transmission Mechanism
• A short PPDU, e.g. CTS-to-Self is used to start MU-MIMO transmission and reserve the MAX transmission duration, including all RTS/CTSs, MU-MIMO data frames, scheduled ACKs and all xIFSs.
• Multiple RTS/CTS frame exchanges are used to reserve bandwidth for multiple recipients
• The RTS/CTSs for primary STAs will be arranged first.
• If no CTS is correctly received from any primary STA, the current MU-MIMO transmission is failed. If the remaining time within the TXOP duration is sufficient to complete an MU-MIMO transmission, AP may initiate a new transmission or retry the previous MU-MIMO transmission. AP may terminate the TXOP with a CF-END.
• Otherwise, if a CTS is not correctly received, AP should issue the next RTS, until RTS/CTS exchanges for all rest scheduled recipients are issued.
doc.: IEEE 802.11-10/1244r1
Submission
Nov.2010
Sun Bo, ZTE CorpSlide 5
MU-MIMO Transmission Mechanism (cont.)
• MU-MIMO data streams are carried in a MU-MIMO data frame based on above reservation.
• Only data with successfully received CTS will be carried in the MU-MIMO data frame;
• Planned data without a successfully received CTS will be removed from the MU-MIMO data frame.
• Scheduled ACKs are used for each recipient to acknowledge the receiving of data carried in MU-MIMO data frame.
• A CF-END may be used to terminate a MU-MIMO transmission if the transmission is terminated before the duration reserved by CTS-to-Self.
doc.: IEEE 802.11-10/1244r1
Submission
Nov.2010
Sun Bo, ZTE CorpSlide 6
MU-MIMO Transmission Mechanism Analysis
AP
STA1
STA2
STA3
STA4
CTS-to-Self RTS
CTS
RTS
CTS
RTS
CTS
RTS
CTS
Multi-use-dataSIFS
SIFS
xIFS
xIFS
SIFS
xIFS
SIFS
SIFS
xIFS
• A CTS-to-Self is used to reserve a long duration allowing MU-MIMO transmission through “duration” field
• AP checks scheduled recipient one by one by RTS/CTS exchanges
• The RTS(s) for primary STA(s) should be arranged firstly.
doc.: IEEE 802.11-10/1244r1
Submission
Nov.2010
Sun Bo, ZTE CorpSlide 7
MU-MIMO Transmission Mechanism Analysis (cont.)
• If AP does not detect a valid CTS frame within one SIFS period plus a delta time (TBD) following the RTS transmission, AP shall initiate the next RTS/CTS frame exchange, or start MU-MIMO data frame transmission.
• The data for a scheduled recipient with unsuccessful RTS/CTS frame exchange will be removed from the transmitted MU-MIMO data frame.
AP
STA1
STA2
STA3
STA4
CTS-to-Self RTSRTS
CTS
RTS
CTS
RTS
CTS
MU-MIMO dataSIFS
SIFS
SIFS
xIFS
SIFS
SIFS
xIFS
xIFS
CTS is missed
delta
doc.: IEEE 802.11-10/1244r1
Submission
Nov.2010
Sun Bo, ZTE CorpSlide 8
AP
STA1
STA2
STA3
STA4
ACK
ACK
ACK
ACK
SIFS
SIFS
SIFS
SIFS
MU-MIMO data
• The ACK(s) is (are) scheduled based on the stream information indicated in the Nsts field of MU-MIMO data frame.
MU-MIMO Transmission Mechanism Analysis (cont.)
doc.: IEEE 802.11-10/1244r1
Submission
Nov.2010
Sun Bo, ZTE CorpSlide 9
• If one ACK is missed, the other STA(s) will send ACK at the scheduled time shown as below.
AP
STA1
STA2
STA3
STA4
ACK
ACK
SIFS
SIFS
SIFS
SIFS
MU-MMO data
ACK is missed
SIFS
retransmission
ACK
MU-MIMO Transmission Mechanism Analysis (cont.)
doc.: IEEE 802.11-10/1244r1
Submission
Nov.2010
Sun Bo, ZTE CorpSlide 10
MU-MIMO Transmission Mechanism Analysis (cont.)
• Only when any primary STA failed to receive MU-MIMO data, the AP will initiate retransmission.
• The retransmission could be:
• retransmitted MU-MIMO data frame which includes at least the data for a primary STA failed in previous MU-MIMO transmission, and the data for other STA(s) failed in previous MU-MIMO transmission, or
• retransmitted SU-MIMO data frame which includes the data for a primary STA failed in previous MU-MIMO transmission, or
• retransmitted MU-MIMO data frame which includes at least the data for a primary STA failed in previous MU-MIMO transmission, and the data for other STA(s) failed in previous MU-MIMO transmission, and new data for other STA(s) succeeded in previous MU-MIMO transmission
doc.: IEEE 802.11-10/1244r1
Submission
Nov.2010
Summary
• The proposed MU-MIMO transmission mechanism provides following advantages:
– Avoiding hidden node problems in BSS and OBSS
– Compatibility with legacy devices
– Reuse of legacy RTS/CTS frame exchanges
– Avoiding unexpected confliction during the gap when a CTS is missed
