1. ARQ protocol in m
IEEE Presentation Submission Template (Rev. 9)
Document Number:
IEEE C802.16m-09/0188
Date Submitted:
Source:
Roberto Albanese, Andrea Bacioccola
Nokia
Shashikant Maheshwari, Yousuf Saifullah
Nokia Siemens Networks
Venue:
IEEE m Session #59, San Diego, US.
Re:
IEEE m-08/052 –Call for Comments on Project m System Description Document (SDD) on Section “10.4 ARQ”.
Base Contribution:
This is the base contribution.
Purpose:
To be discussed and adopted by TGm for the m SDD
Notice:
This document does not represent the agreed views of the IEEE Working Group or any of its subgroups. It represents only the views of the participants listed in the “Source(s)” field above. It is offered as a basis for discussion. It is not binding on the contributor(s), who reserve(s) the right to add, amend or withdraw material contained herein.
Release:
The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE
Patent Policy:
The contributor is familiar with the IEEE-SA Patent Policy and Procedures:
< and <
Further information is located at < and < >.

2. Background HARQ is mandatory in 802.16m.
ARQ is a mechanism primarily for recovering from HARQ residual error (10e-3), so that TCP operations can be properly achieved with the required performance (10e-6 PER).
There’s a general agreement in supporting Local NACK in the transmitter site, since it helps to improve the TCP performance when high data rate is supported.

3. ARQ protocol - motivation
In the current SDD, HARQ has been agreed as a mandatory feature
this allows the design of an ARQ protocol simpler than the one in 16e
Using only the Local NACK, the ARQ transmitter may not have a up-to-date status of the ARQ receiver window
A simple and reliable method can be achieved using a polling based feedback

4. ARQ protocol - overview
The transmitter may poll the receiver to send a feedback on the status of the ARQ receiver window.
Different types of feedbacks may be requested from the transmitter (e.g. cumulative ACK, bitmap ACK, etc.).
To reduce the ARQ signaling feedback overhead only polling mechanism is allowed.

5. Proposed SDD text
[Add the following text in section 10.4 ARQ]
The ARQ transmitter may poll the receiver to send a ARQ feedback on the status of the receiver window. The ARQ receiver transmits ARQ feedback only when requested by the transmitter through a polling message. If ARQ transmitter is ABS, then ABS along with polling message may also provide the resource for ARQ receiver to transmit the ARQ feedback. Types of ARQ feedback are FFS.