1. Further Discussion on “Lost Ack” During Unscheduled Service Period
Month 2000
doc.: IEEE /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

2. November, 2003
Addresses Comments
Lost Ack Issue

3. 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.

4. 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 , ANSI/IEEE Std , 1999 Edition

5. 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.

6. 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.

7. 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)?