Further Discussion on “Lost Ack” During Unscheduled Service Period Month 2000 doc.: IEEE 802.11-00/xxx November, 2003 Further Discussion on “Lost Ack” During Unscheduled Service Period Authors: Stephen Wang, Floyd Simpson Motorola GTSS Steve Emeott, Ye Chen Motorola Labs Date: November 10, 2003 John Doe, His Company

November, 2003 The Lost Ack Problem During an “Unscheduled Service Period”, QAP signals QSTA in PS-mode to return to sleep by setting the “More Data” bit to 0 (or ESOP bit to 1, or Queue Size to 0) in the last DL data frame. If the last DL data frame is received, QSTA enters sleep mode after sending an ACK. If the QAP does not receive an ACK to the last DL data frame, it is ambiguous to the QAP whether: The command itself never reached the QSTA The ACK sent by the QSTA to the QAP was lost or corrupted If the QAP does not receive an ACK, it must retransmit If the QSTA received the DL data frame and subsequently went to sleep, the QAP could end up retransmitting the DL data frame while the QSTA is asleep.

The Legacy Solution to “Lost Ack” November, 2003 The Legacy Solution to “Lost Ack” “… If the AP responds to a PS-Poll by transmitting an ACK frame, the responsibility for the data frame delivery error recovery shifts to the AP because the data is transferred in a subsequent frame exchange sequence, which is initiated by the AP. The AP shall attempt to deliver one MSDU to the STA that transmitted the PS-Poll, using any frame exchange sequence valid for a directed MSDU. If the power save STA that transmitted the PS-Poll returns to Doze state after transmitting the ACK frame in response to successful receipt of this MSDU, but the AP fails to receive this ACK frame, the AP will retry transmission of this MSDU until the relevant retry limit is reached.” - Clause 9.2.5.3, ANSI/IEEE Std 802.11, 1999 Edition

Probabilities of “Lost Ack” November, 2003 Probabilities of “Lost Ack” Three scenarios could happen after QAP sends the DL data frame in an unscheduled SP: Scenario 1: DL data is received by QSTA and UL Ack is received by QAP Scenario 2: DL data is lost Scenario 3: DL data is received by QSTA but UL Ack is lost Under GOOD channel conditions, Scenario 1 is the most likely outcome. Under POOR channel conditions, Scenario 2 is more likely to happen than Scenario 3 because size of the DL data frame is much larger than the UL Ack frame. Neither Scenario 1 nor Scenario 2 would result in the “lost Ack” problem.

Requirement for “Lost Ack” Solution November, 2003 Requirement for “Lost Ack” Solution Any potential “lost Ack” solution must be unambiguously more efficient than the legacy solution under all scenarios. Because of relatively small probability of the “lost Ack” problem, any potential solution must not impose penalty (increased power consumption, decreased efficiency, etc.) on normal operations.

November, 2003 Straw Poll We believe the legacy solution is efficient and sufficient. Does the task group feel another solution is warranted? (Yes, No, Abstain)?