Upload
daisy-mosley
View
216
Download
0
Embed Size (px)
Citation preview
doc.: IEEE 802.11-13/1434r0
Submission
November 2013
Slide 1
CID 1376: NDP BlockAck Bitmap ProtectionDate: 2013-11-11
Authors:
Alfred Asterjadhi, et. al. (Qualcomm Inc.)
Name Affiliations Address Phone email Simone Merlin Qualcomm 5775 Morehouse Dr,
San Diego, CA 8588451243 [email protected]
Amin Jafarian Qualcomm
Bin Tian Qualcomm
Santosh Abraham Qualcomm
Alfred Asterjadhi Qualcomm
Menzo Wentink Qualcomm
Hemanth Sampath Qualcomm
VK Jones Qualcomm
Sun, Bo ZTE [email protected]
Lv, Kaiying ZTE [email protected]
Huai-Rong Shao Samsung [email protected]
Chiu Ngo Samsung [email protected]
Minho Cheong ETRI 138 Gajeongno, Yuseong-gu, Dajeon, Korea
+82 42 860 5635
Jae Seung Lee ETRI [email protected]
Hyoungjin Kwon ETRI [email protected]
Jaewoo Park ETRI [email protected] Sok-kyu Lee ETRI [email protected]
Sayantan Choudhury Nokia 2075 Allston Way, Suite 200, Berkeley, CA 94704
+1 510 599 9268 [email protected]
Klaus Doppler Nokia
Chittabrata Ghosh Nokia
Esa Tuomaala Nokia
doc.: IEEE 802.11-13/1434r0
Submission Slide 2
November 2013
Alfred Asterjadhi, et. al. (Qualcomm Inc.)
Name Affiliations Address Phone email Minyoung Park Intel Corp. [email protected]
Tom Tetzlaff Intel Corp. [email protected]
Emily Qi Intel Corp. [email protected]
Liwen Chu Marvell [email protected]
Jinjing Jiang Marvell [email protected]
Hongyuan Zhang Marvell [email protected]
Hui-Ling Lou Marvell [email protected]
Yongho Seok LG Electronics LG R&D Complex Anyang-Shi, Kyungki-Do, Korea
+82-31-450-1947 [email protected]
Jinsoo Choi LG Electronics
Jeongki Kim LG Electronics
Jin Sam Kwak LG Electronics
Matthew Fischer Broadcom 190 Mathilda Place, Sunnyvale, CA
+1 408 543 3370 [email protected]
Eric Wong Broadcom [email protected]
Rojan Chitrakar Panasonic [email protected]
Ken Mori Panasonic [email protected]
doc.: IEEE 802.11-13/1434r0
Submission Slide 3
November 2013
Alfred Asterjadhi, et. al. (Qualcomm Inc.)
Name Affiliations Address Phone email Shoukang Zheng I2R 1 Fusionopolis Way, #21-01
Connexis Tower, Singapore 138632
+65-6408 2000 [email protected]
Haiguang Wang I2R [email protected] Wai Leong Yeow I2R [email protected] Zander Lei I2R [email protected] Jaya Shankar I2R [email protected] Anh Tuan Hoang I2R [email protected] Joseph Teo Chee Ming I2R [email protected] George Calcev Huawei Rolling Meadows,
IL USA [email protected]
Osama Aboul Magd Huawei [email protected]
Young Hoon Kwon Huawei [email protected]
Betty Zhao Huawei [email protected]
David Yangxun Huawei [email protected]
Bin Zhen Huawei [email protected]
ChaoChun Wang MediaTek [email protected]
James Wang MediaTek [email protected]
Jianhan Liu MediaTek [email protected]
Vish Ponnampalam MediaTek [email protected]
James Yee MediaTek [email protected]
Thomas Pare MediaTek [email protected]
Kiran Uln MediaTek [email protected]
Anna Pantelidou Renesas Mobile
Juho Pirskanen Renesas Mobile
Timo Koskela Renesas Mobile
George Vlantis STMicroelectronics
doc.: IEEE 802.11-13/1434r0
Submission
BlockAck Bitmap Protection
• In 11ah, 4-bit CRC is used to protect the SIG field– Results in [2] show that the achievable false positive probability is low enough
compared to the SIG Error Rate• From a PHY point of view this proves to be enough
– However, it is not enough for NDP BlockAck which requires high reliability• Because of IEEE requirements at MAC layer (see next slide)
– @10% SIG Error Rate the BA Bitmap error rate is high
Slide 4
November 2013
Alfred Asterjadhi, et. al. (Qualcomm Inc.)
0.1 0.2 0.3 0.4 0.5 0.6
10-5
10-4
10-3
SIG Error Rate
Fal
se A
ck R
ate
No Extra Protection
doc.: IEEE 802.11-13/1434r0
Submission
IEEE Error Requirements
• Definition for medium access control (MAC) service data unit (MSDU):– Information that is delivered as a unit between MAC service access points (SAPs).
• Error performance of IEEE 802 LANs and MANs is required to be such as follows:• a) For wired or optical fiber physical media: Within a single access domain, the probability that a transmitted
MAC frame (excluding any preamble) is not reported correctly at the Physical Service interface of an intended receiving peer MAC entity, due only to operation of the Physical layer, shall be less than 8 × 10 -8 per octet of MAC frame length.
• b) For wireless physical media: Within a single access domain, the probability that a MAC Service Data Unit (MSDU) is not delivered correctly at an MSAP of an intended receiving MAC service user, due to the operation of the Physical layer and the MAC protocol, shall be less than 8 × 10-8 per octet of MSDU length.
“NOTE—The performance measure stated in (a) defines a highly desirable characteristic of LAN performance, as it has a bearing on other aspects of the delivered service, such as frame loss and transmission delays caused by the need to retransmit. However, this measure is not realistic for all physical media; for example, wireless media may be unable to meet this level of physical layer performance due to the inherent transmission characteristics of the medium . In such cases, the operation of the MAC protocol must employ additional mechanisms, for example, error detection and correction mechanisms, in order to enable the MAC service provider to meet the performance levels implied by this condition in the service offered at the MAC service boundary.”
– XOR protection for NDP BlockAck falls in this category
Slide 5
November 2013
Alfred Asterjadhi, et. al. (Qualcomm Inc.)
doc.: IEEE 802.11-13/1434r0
Submission
Example of False Positive Event
1. Transmitter sends MPDUs from 1 to 5 and requests for an NDP BlockAck– All MPDUs but MPDU with SN 2 are successfully delivered
2. Receiver responds with an NDP BA indicating that all but MPDU 2 were RXed correctly– Received NDP BlockAck at the transmitter passes CRC but there is an error in the Bitmap (MPDU 2 is OK)
3. Transmitter moves its BlockAck window to SN 6 and starts transmitting other MPDUs– MPDU 2 here is discarded because the transmitter believes the MPDU was delivered correctly
4. Receiver starts receiving MPDUs with SN starting from 6– It believes that the transmitter decided not to transmit MPDU with SN 2
• The MSDU contained in MPDU 2 was not delivered correctly at the MSAP of the receiver– This must happen with a probability that is less than 8x10-8
Slide 6
November 2013
Alfred Asterjadhi, et. al. (Qualcomm Inc.)
MAC layer
PHY Layer
MAC SAP
PHY SAP
MAC layer
PHY Layer
MAC SAP
PHY SAPPPDUs
MPDU 2 gets lost
Received MSDU delivered at the MSAP1 2 3 5 1 34 54
doc.: IEEE 802.11-13/1434r0
Submission
Current NDP BA Bitmap Reliability
Error performance requirements of IEEE 802 LANs:
- “the probability that a MSDU is not delivered correctly at the MSAP of an intended receiving MAC service user, due to the operation of the Physical layer and the MAC protocol, shall be less than 8x10-8 per octet of MSDU…”
This requirement is not fulfilled in many cases
- E.g., Sending 1MHz NDP BAs@10% SIG Error Rate it can be fulfilled only if the MSDU payload is > 800B
- Not fulfilled at all if SIG Error Rate is greater
Slide 7
November 2013
Alfred Asterjadhi, et. al. (Qualcomm Inc.)
• We propose a mechanism to fulfill this requirement without reducing BA Bitmap size– Which is based on XOR Protection
doc.: IEEE 802.11-13/1434r0
Submission
Option 1: Simple XOR Protection
• TXer sends XOR(BA Id., BA Bitmap) instead of BA Id. and Bitmap– RXer retrieves BA Id. by XORing the received BA Id. with the received Bitmap
• With XOR protection an error in the Bitmap is undetected– If there is also one error in the BA Id.– And it must be at the same location as the erred bitmap bit
• undetected by bitwise XOR
Slide 8
November 2013
Alfred Asterjadhi, et. al. (Qualcomm Inc.)
2 (6) 12 8 (16)
BlockAck ID Starting Sequence Control BlockAck Bitmap
BA Identifier
0 1 1 0 0 0 1 0 1 0 1 1 1 0 0 0BA Identifier
1 0 1 1 1 0 0 0BA Bitmap
XOR Operation
doc.: IEEE 802.11-13/1434r0
Submission
Option 2: 3-XOR Protection
• XORing can be applied recursively bit-shifting the BA Identifier bits XORed with the Bitmap– Further increase protection of the BlockAck Bitmap – E.g., with 2-XOR, an error in the bitmap is undetected if there are two errors in the received BA ID as well
• And these errors must be at the same location where 2 bit-shifted XORing of the erred bitmap bit was performed
• In the next slides we show results for 3-XOR which significantly enhances Bitmap protection– With 3-XOR the transmitter recursively applies bit-wise XORing three times and sends out the XORed version
of the BA ID along with the BA Bitmap• The receiver performs the spectral operation to the received BA ID by XORing it with the received Bitmap
– If the obtained BA ID (after 3-XORing) equals the expected BA ID the NDP BA is assumed to be correct
Slide 9
November 2013
Alfred Asterjadhi, et. al. (Qualcomm Inc.)
0 1 1 0 0 0 1 0 1 0 1 1 1 0 0 0BA Identifier
1 0 1 1 1 0 0 0
Recursively perform: 1-XOR Operation 2-XOR Operation 3-XOR Operation BA Bitmap
doc.: IEEE 802.11-13/1434r0
Submission
Performance Comparison• Simulation Setup:
– Assume perfect synchronization and detection of NDP BA (STF and LTF fields received intact)– AWGN channel for SIG field, 10^7 NDP BlockAck packets– NDP BlockAck frame:
• Predefined value for NDP Type• Randomly generated sequences
– BlockAck ID, Starting Sequence Control and BA Bitmap
• Two Protection mechanisms:– 1-XOR protection – Transmit XOR of BA Identifier with BA Bitmap– 3-XOR protection – Transmit 3-bit shifted XOR of BA Identifier with BA Bitmap
• Evaluation metrics:– False Positive Rate – False Acknowledgement Rate due to an error in the BA bitmap
Slide 10
November 2013
Alfred Asterjadhi, et. al. (Qualcomm Inc.)
4 2(6) 12 8(16) 4 6
Type BlockAck ID SSC Bitmap CRC Tail
doc.: IEEE 802.11-13/1434r0
Submission
NDP BlockAck (1MHz)
• BA Bitmap Protection– X-axis: SIG Error Rate– Y-axis: False Ack Rate
• Curves:– No Extra Protection
• NDP BA with no other protection
– 1-XOR Protection• XORing of Bitmap with BA ID
– 3-XOR Protection• 3-bit shift XORing of Bitmap with BA ID
Slide 11
November 2013
Alfred Asterjadhi, et. al. (Qualcomm Inc.)
0 0.1 0.2 0.3 0.4 0.5 0.6 0.710
-8
10-7
10-6
10-5
10-4
10-3
SIG Error Rate
Fal
se A
ck R
ate
No Extra Protection
XOR Protection
3-XOR Protection
• At 10% SIG Error, False Ack Rate drops from – ~8*10-5 with no protection to
• ~5*10-7 with 1-XOR protection
• 3-XOR Protection ensures lowest False Ack Rate– Not sufficient trials to have smooth curves
• Overall there were only 18 bitmaps in error throughout all simulation campaign
doc.: IEEE 802.11-13/1434r0
Submission
NDP BlockAck (>=2MHz)
• BA Bitmap Protection– X-axis: SIG Error Rate– Y-axis: False Ack Rate
• Curves:– No Extra Protection
• NDP BA with no other protection
– 1-XOR Protection• XORing Bitmap with BA ID
– 3-XOR Protection• 3-bit shift XORing of Bitmap with BA ID
Slide 12
November 2013
Alfred Asterjadhi, et. al. (Qualcomm Inc.)
• At 10% SIG Error, False Ack Rate drops from– ~2*10-4 with no protection to
• ~4*10-8 with 1-XOR protection
• 3-XOR Protection ensures lowest False Ack Rate– Not sufficient trials to have smooth curves
• Overall there were only 8 bitmaps in error throughout all simulation campaign
0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.910
-9
10-8
10-7
10-6
10-5
10-4
10-3
SIG Error Rate
Fal
se A
ck R
ate
No Extra Protection
XOR Protection
3-XOR Protection
doc.: IEEE 802.11-13/1434r0
Submission
Conclusion
• In practical cases, simple XORing provides enough protection – Even at severe interference and channel conditions (@50% SIG Error & >~20Bytes payloads)
• 3-XOR Protection fulfills the IEEE requirement in all extreme cases– And gives a safety guard of at least one order of magnitude
Slide 13
November 2013
Alfred Asterjadhi, et. al. (Qualcomm Inc.)
0 200 400 600 800 1000 1200 1400 1600 1800 200010
-8
10-7
10-6
10-5
10-4
10-3
Payload [Bytes]
Fal
se A
ck P
roba
bilit
y
IEEE802 Error Req.1MHz, No Extra Protection
1MHz, 1-XOR Protection
1MHz, 3-XOR Protection
2MHz, No Extra Protection
2MHz, 1-XOR Protection2MHz, 3-XOR Protection
doc.: IEEE 802.11-13/1434r0
Submission
Proposed Spec text
Slide 14
November 2013
Alfred Asterjadhi, et. al. (Qualcomm Inc.)
Instruction to TGah Editor: Add new subclause immediately after 9.52 as follows:
9.52a Bitmap Protection for NDP BlockAck frames
The originator of a NDP BlockAck (1 (or ≥ 2) MHz) frame (see 8.3.5.1.5 (NDP BlockAck)) shall protect the BlockAck Bitmap of the NDP BlockAck frame (shown in Figure 9.21.7.9x) by using the encoding procedure defined in this subclause.
B0 B2 B3 …. …. …. B24(36)
NDP MAC
Type BlockAck ID
Starting Sequence Control
BlockAck Bitmap
Bits 3 2 (6) 12 8 (16)
Figure 9.21.7.9x –NDP BlockAck (1 ( or ≥ 2) MHz) frame structure
Initially the bit sequences [B3: B10] for NDP BlockAck (1 MHz) and [B3:B18] for NDP BlockAck (≥ 2 MHz) frames are set as described in 9.21.7.5(Generation and transmission of BlockAck by an HT STA) or 9.3.2.9a(Fragment BA procedure).
doc.: IEEE 802.11-13/1434r0
Submission
Proposed Spec text (cont.)
Slide 15
November 2013
Alfred Asterjadhi, et. al. (Qualcomm Inc.)
Encoding Procedure:
For an NDP BlockAck (1 MHz) frame: [B3: B10] = XOR([B3: B10], [B17: B24]);
For an NDP BlockAck (≥ 2MHz) frame [B3: B18] = XOR([B3: B18], [B21: B36]);
Where XOR() indicates bitwise exclusive OR operation. The intended recipient shall perform the same procedure to decode the bit sequences [B3: B10] for NDP BlockAck (1 MHz) and [B3:B18] for NDP BlockAck (≥ 2MHz) frames.
doc.: IEEE 802.11-13/1434r0
Submission
Strawpoll 1
• Do you support the proposed spec text for NDP Block Ack Protection as described in slides 14 to 15 ?
Slide 16
November 2013
Alfred Asterjadhi, et. al. (Qualcomm Inc.)
doc.: IEEE 802.11-13/1434r0
Submission
References
• [1] http://ieee802.org/secmail/pdfocSP2xXA6d.pdf• [2] 11-12-0596-01-00ah-sig-field-4-bit-crc
Slide 17
November 2013
Alfred Asterjadhi, et. al. (Qualcomm Inc.)