1. doc.: IEEE 802.15-08-0125-00-003c Submission March, 2008 Inha Univ.Slide 1 Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [A Method of Combing Imp-ACK with Imm-ACK] Date Submitted: [March 16, 2008] Source: [Kyungsup Kwak, Seokho Kim, Xizhi An] Company: [Inha University] Address: [6-141B, Inha University, 253 Yonghyun-dong, Nam-gu, Incheon, 402-751, Republic of Korea] Voice: [], FAX: [], E-Mail: [kskwak@inha.ac.kr, sylvstar@inhaian.net, anxizhi@inhaian.net] Re: [] Abstract: [This document at first reviews current ACK policies in the standard. Then, the common background of different ACK policies is discussed. Based on the facts that Imp-ACK is similar to Imm- ACK, and Imp-ACK can be implemented implicitly, a new method of combing Imp-ACK with Imm- ACK is proposed.] Purpose: [To be considered in IEEE 802.15.3c standard] 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 contributor acknowledges and accepts that this contribution becomes the property of IEEE and may be made publicly available by P802.15.

2. doc.: IEEE 802.15-08-0125-00-003c Submission March, 2008 Inha Univ.Slide 2 Overview Review of ACK Policies Combination of Imm-ACK and Imp-ACK

3. doc.: IEEE 802.15-08-0125-00-003c Submission March, 2008 Inha Univ.Slide 3 Current ACK Policies No ACK Imm-ACK Dly-ACK Imp-ACK –Added in IEEE 802.15.3b Blk-ACK –It is to be removed from the current draft (DF1): P802-15-3c-DF1_Draft_Ammendment.pdf

4. doc.: IEEE 802.15-08-0125-00-003c Submission March, 2008 Inha Univ.Slide 4 Current DF1

5. doc.: IEEE 802.15-08-0125-00-003c Submission March, 2008 Inha Univ.Slide 5 Current DF1

6. doc.: IEEE 802.15-08-0125-00-003c Submission March, 2008 Inha Univ.Slide 6 Immediate ACK

7. doc.: IEEE 802.15-08-0125-00-003c Submission March, 2008 Inha Univ.Slide 7 Delayed ACK Fields –The Max Burst field indicates the number of frames of pMaxFrameBodySize that may be sent in one burst. –The Max Frames field indicates the maximum number of frames, regardless of size, that may be sent before requesting a Dly-ACK from the DEV receiving the frames. –The MPDUs ACKed field shall contain the number of MPDUs that are being ACKed with this frame. This field shall be greater than or equal to 1. –The MPDU ID block shall be formatted as illustrated in Figure 18. Burst –A burst is the collection of the frames that are pending acknowledgement via a Dly-ACK frame. –Any burst shall meet the restrictions of both the Max Frames field and the Max Burst field. –Burst size n is the number of MPDUs that are transmitted in a burst. use n-Dly-ACK to represent the Dly-ACK scheme with burst-size of n.

8. doc.: IEEE 802.15-08-0125-00-003c Submission March, 2008 Inha Univ.Slide 8 Implied ACK 8.8.3a Implied acknowledgment (Imp-ACK) –A DEV should not initiate an Imp-ACK procedure unless it has determined that the receiving DEV supports Imp-ACK by checking the DEV Capabilities field in the Capability IE.

9. doc.: IEEE 802.15-08-0125-00-003c Submission March, 2008 Inha Univ.Slide 9 Common background of ACK Policies Dly-ACK can be regarded as an universal ACK scheme. Burst size n –n = 1 : Imm-ACK –n >1 : Dly-ACK –n = : No ACK Could we make some change in 3c?

10. doc.: IEEE 802.15-08-0125-00-003c Submission March, 2008 Inha Univ.Slide 10 Combine Imp-ACK with Imm-ACK Motivation –Redundant field –Complexity Even though DEV can set Imp-ACK policy, it will become Imm- ACK if some conditions are not satisfied. Proposed simplification Remove Imp-ACK request bit. Imm-ACK can be enhanced to realize Imp-ACK. –Imp-ACK can be implemented IMPLICITLY. –The 3c DEV can implement this enhanced Imm-ACK by default. Imp-ACK NACK can be renamed as ACK/NACK to support negative ACK in Imm-ACK frame.

11. doc.: IEEE 802.15-08-0125-00-003c Submission March, 2008 Inha Univ.Slide 11 Modification of Imm-ACK Generally, the addressed recipient returns an Imm-ACK frame after successful reception. –If the target DEV successfully receives a MAC header for a frame but does not successfully receive the frame body, i.e., the FCS check fails, it may still send an ACK in response, with the ACK/NACK field being set. The acknowledge could be implicitly performed, that is, the DEV can respond with a command or data frame and set the ACK/NACK bit correspondingly, if following conditions are all satisfied at the same time. –Both the originating DEV and target DEV have their Imp-ACK Capability bit enabled. –Bi-directional communication is going on in the current CTA. –The target DEV knows the end time of the current CTA. –The target DEV has data frame or command frame to be sent. –There is sufficient time in the CTA for the response frame and any required acknowledgments before the end of the CTA. –Note: Imp-ACK shall not be used for broadcast or multicast frames. Imp-ACK shall not be used in the CAP or a contention CTA.