1. doc.: IEEE 802.15-<doc#>
<month year>
Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs)
Submission Title: [Comment resolutions for retransmission]
Date Submitted: [May 13, 2008]
Source: [Zhou Lan, Chang woo Pyo, Fumihide Kojima, Chin-Sean Sum, Tuncer Baykas, Junyi Wang, Hiroyuki Nakase, Ruhei Funada, Hiroshi Harada, Shuzo Kato]
Company [National Institute of Information and Communications Technology (NICT)]
Address1[3-4 Hikari-no-oka, Yokosuka-shi, Kanagawa , Japan]
Voice1:[ ] , FAX1: [ ]
Re: [In response to TG3c comments resolution (IEEE P c)]
Abstract: [Comment resolutions for MAC]
Purpose: [To be considered in TG3C baseline document.]
Notice: This document has been prepared to assist the IEEE P It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein.
Release: The contributors acknowledge and accept that this contribution becomes the property of IEEE and may be made publicly available by P
<author>, <company>

2. Comment #93 Comment Resolution
It is not clear whether the requirement is that retransmitted frames be sent in the next frame AND at the head of the frame or whether the requirement is that IF the retransmitted frames are sent in the next frame that they be placed at the head of the frame.
Resolution
Suggested modification from RJS
Clarify the requirement. I suspect the intent was to require immediate retransmission.
Suggested modification from NICT
YES, The intention is to complete the retransmission as soon as possible, but the retransmitted frames don’t have to be put first in the new frame
Modify the related sentence like this
“In the next frame sent by the source, the retransmitted subframes shall be put first in the original order followed by the new frames”

3. Comment #94 Comment Resolution Suggested modification from RJS
There are no in-order delivery requirements in the described block ack mechanism other than "The destination transfers consecutive valid subframes to the FCSL." which from the context applies to a single aggregate frame only.
Resolution
Suggested modification from RJS
Clarify in-order delivery requirements. Address buffering requirements in receiver, retention of later (higher sequence number) frames until retransmission of earlier (lower sequence number) frames completes successfully, timeouts or other mechanisms to handle cases where retransmission frails
Suggested modification from NICT
In-order delivery. is required for both video application and PCI-express application
To address the buffer requirement, detailed resolution will be provided by Gal (wilocity) by the end this week
To address the retransmission failure, the timer (RIFS) defined in b can be reused, because of the similarity between Imm-ACK and Blk-ACK
To drop the higher sequence number frame of lower sequence number frame during retransmission is a implementation dependent issue
Suggest to modify section retransmission ( b)
During CTAs within the CTAP when an Imm-ACK or Dly-ACK or Blk-ACK is expected...……

4. Comment #95 Comment Resolution Suggested modification from RJS
The in-order delivery requirements for low latency aggregation do not address retransmission failure.
Resolution
Suggested modification from RJS
Define behavior for the case where retransmission fails (maximum retransmits exceeded) for a particular MSDU
Suggested modification from NICT
The retransmission procedure in current DF3 doesn’t rely on in-order delivery
The existing definition of can be used to address this issue.
Refer to section 8.8.4