doc.: IEEE 802.15-<doc#> <month year> Project: IEEE P802.15 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 239-0847, Japan] Voice1:[+81-46-847-5074] , FAX1: [+81-46-847-5440] E-Mail[lan@nict.go.jp] Re: [In response to TG3c comments resolution (IEEE P802.15-08-0255-03-003c)] Abstract: [Comment resolutions for MAC] Purpose: [To be considered in TG3C baseline document.] Notice: This document has been prepared to assist the IEEE P802.15. 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 P802.15. <author>, <company>

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”

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 802.15.3b 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 8.8.4 retransmission (802.15.3b) During CTAs within the CTAP when an Imm-ACK or Dly-ACK or Blk-ACK is expected...……

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 802.15.3 can be used to address this issue. Refer to 802.15.3 section 8.8.4