month year doc IEEE 802 15 doc Project

<month year> doc. : IEEE 802. 15 -<doc#> Project: IEEE P 802. 15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Improved Delayed ACK response Frame for 802. 15. 3 b] Date Submitted: [17 Aug, 2004] Source: [William M. Shvodian] Company [Freescale Semiconductor] Address [8133 Leesburg Pike, Suite 700, Vienna, VA, 22182, USA] Voice: [703 -269 -3047], FAX: [703 -269 -3092], E-Mail: [bill. shvodian @ freescale. com] Re: [ 802. 15. 3 b call for proposals ] Abstract: [This document provides an improvement to the 802. 15. 3 protocol by greatly reducing the required processing for Delayed ACK so that the responding Device can meet the required turn around time] Purpose: [The author would like 802. 15. 3 b to consider incorporating this change into the IEEE 802. 15. 3 b standard. ] Notice: This document has been prepared to assist the IEEE P 802. 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 contributor acknowledges and accepts that this contribution becomes the property of IEEE and may be made publicly available by P 802. 15. Submission 1 <author>, <company>

<month year> doc. : IEEE 802. 15 -<doc#> The problem • In 802. 15. 3 Delayed ACK has the same turn around requirements as Immediate ACK • When a DEV receives a frame with delayed ACK policy and Delayed ACK request set, the receiver needs to check the Header and HCS and the FCS, then insert the MPDU ID block (MSDU number and fragment number) for that frame into the delayed ACK response frame and transmit the delayed ACK response in a SIFS duration from the end of the transmission of the last received frame. • SIFS is not enough time to modify the Delayed ACK response frame and begin transmission without either an unreasonably fast processor or a hardware implementation Submission 2 <author>, <company>

<month year> doc. : IEEE 802. 15 -<doc#> Delayed ACK request MSC (copied from 802. 15. 3 -2003) Submission 3 <author>, <company>

<month year> doc. : IEEE 802. 15 -<doc#> Complete Delayed ACK MSC (Does not appear in 802. 15. 3 -2003) Submission 4 <author>, <company>

<month year> doc. : IEEE 802. 15 -<doc#> Proposed Solution • The MPDU ID from the last transmitted MPDU is not needed, because the transmitting DEV knows which MPDU it sent last. It would not get the Delayed ACK response frame if the last transmitted MPDU was not received properly. • The receiver sends the delayed ACK response when requested, without the last MPDU ID • This allows the Delayed ACK response frame to be created in advance (upon receipt of the MPDU prior to the MPDU with the delayed ACK request sent). • Early creation of the Delayed ACK response Frame enables the responding DEV to meet the quick turn around required for the receiving device when Delayed ACK is used in 802. 15. 3 Submission 5 <author>, <company>

<month year> doc. : IEEE 802. 15 -<doc#> Proposed Modified Delayed ACK Submission 6 <author>, <company>

<month year> doc. : IEEE 802. 15 -<doc#> Additional Details • Change the MPDUs ACKed field in the Delayed ACK Response frame to “MPDU ID blocks present” because the Delayed ACK Response is actually ACKing one more frame than there are MPDU ID blocks in the frame. Submission 7 <author>, <company>