doc.: ieee 802.11-13/1434r0 submission november 2013 slide 1 cid 1376: ndp blockack bitmap...

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

[email protected]

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


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


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


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


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


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


• 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


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


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


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


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


• 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


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


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


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


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


doc.: ieee 802.11-13/1434r0 submission november 2013 slide 1 cid 1376: ndp blockack bitmap...

Documents