1. doc.: IEEE 802.15-08-0125-01-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-01-003c Submission March, 2008 Inha Univ.Slide 2 Overview Review of ACK Policies Combination of Imm-ACK and Imp-ACK Suggestions concerned with UEP and aggregation

3. doc.: IEEE 802.15-08-0125-01-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 standard Blk-ACK –Added in IEEE 802.15.3c draft (DFx)

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

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

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

7. doc.: IEEE 802.15-08-0125-01-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-01-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-01-003c Submission March, 2008 Inha Univ.Slide 9 Block ACK

10. doc.: IEEE 802.15-08-0125-01-003c Submission March, 2008 Inha Univ.Slide 10 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?

11. doc.: IEEE 802.15-08-0125-01-003c Submission March, 2008 Inha Univ.Slide 11 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 and Blk-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.

12. doc.: IEEE 802.15-08-0125-01-003c Submission March, 2008 Inha Univ.Slide 12 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.

13. doc.: IEEE 802.15-08-0125-01-003c Submission March, 2008 Inha Univ.Slide 13 Suggestions concerned with UEP If UEP is applied, two FCS fields shall be generated for MSB part and LSB part respectively. –Length of MSB/LSB FCS: 4 octets? Generation method: 7.2.7.6 FCS –Description of 12.2.5 Frame payload shall be revised correspondingly. a) compute the MSB FCS (4 octets) and LSB FCS (4 octets) over frame payload respectively, b) append the MSB FCS and LSB FCS to the frame payload, –To be consistent with Figure 155Parallel encoders for UEP, each octet in FCS field shall be rearranged, i.e., the MSB bits come from MSB FCS and the LSB bits come from LSB FCS. –If each MSB/LSB FCS has 4 octets, the number of octets in FCS field as shown in figures of 7.2 General frame format shall be changed as 0 or 4 or 8

14. doc.: IEEE 802.15-08-0125-01-003c Submission March, 2008 Inha Univ.Slide 14 Suggestions concerned with UEP MSB/LSB Retransmission bits should be added in Imm/Imp-ACK and Dly-ACK frames too. –Imm/Imp-ACK frame: MAC header –> Frame Control The previously added ACK/NACK bit could also be used as MSB Retransmission; Add one new LSB Retransmission bit. –Dly-ACK frame: MAC header –> Frame Control The above MSB Retransmission and LSB Retransmission bits can be used to indicate the existence of MSB/LSB Retransmission bitmaps that are defined as below. l = upper integer ( number of MPDU ACKed / 8 ) 4ll2…211110 FCSLSB ReTX bitmap MSB ReTX bitmap MPDU ID block n …MPDU ID block 1 MPDU ACKed Max frames Max burst MAC header

15. doc.: IEEE 802.15-08-0125-01-003c Submission March, 2008 Inha Univ.Slide 15 Suggestions concerned with Aggregation Blk-ACK can be replaced by Dly-ACK. –Refer to 15-08-0126-01-003c Why is fragmentation still useful when aggregation is applied? –DEV likes small frames – pPreferredFragmentSize. –Reduce unnecessary retransmissions Small frame size means small frame error rate, if bit error rate is given. Only erroneous parts (frames) are retransmitted. Possibly reduce the overall transmission delay. What is used by MAC peers to identify if a frame is exactly the same frame they both are referring to? –MSDU number + fragment number (protocol consistence) Convenient to use existing Dly-ACK Burst size n can be an integral multiple of number of aggregated frames –Subframe ID only has the local meaning and uses a new counter. More complex The value range of Subframe ID implicitly restrains number of frames that can be sent continuously before a ACK request must be sent or a ACK response must be received.

16. doc.: IEEE 802.15-08-0125-01-003c Submission March, 2008 Inha Univ.Slide 16 Suggestions concerned with Aggregation Negative Acknowledgement can be more efficient under some conditions. –Reason The frame error rate at the working point shall be low. Subheaders have the optional HCS. –Method (Burst size n = number of aggregated frames): Receiver responses with an Imm-ACK frame and sets ACK/NACK bit as 0 if all aggregated frames are correctly received. Receiver responses with an Imm-ACK frame and sets ACK/NACK bit as 1 if the optional HCS checking fails. Receiver responses with an Dly-ACK frame if some frames are erroneous, and sets corresponding MPDU ID blocks and MSB/LSB Retransmission bitmap.

17. doc.: IEEE 802.15-08-0125-01-003c Submission March, 2008 Inha Univ.Slide 17 Suggestions concerned with Aggregation Applicable to bi-directional communication. –Communication peer: Side 1 and Side 2 –Both sides have the same number (m) of aggregated frames. –Detailed Implied ACK procedure: 1. Side 1 sends m frames in one PHY frame. 2.After reception and error detection, Side 2 sends m frames, with their ACK/NACK bits or MSB/LSB Retransmission bits being set accordingly, that is, the implied ACK sequence is the same as frame reception sequence. If there is not enough time for Side 2 to send all m (data) frames in the current CTA, it just sends as many frames as allowed, e.g. d, and then sends (m – d) Imm-ACK frames in the rest time period. 3. Side 1 deals with TX/ReTX according to the implied ACKs from Side 2, sends m frames and sets implied ACKs in the same way. 4.If any condition of implied ACK is not satisfied, a Dly-ACK with burst size equal to m is sent instead.

18. doc.: IEEE 802.15-08-0125-01-003c Submission March, 2008 Inha Univ.Slide 18 Suggestions concerned with Aggregation Shrink the Fragmentation Control field in MAC header. –Purpose: Direct MSDU Aggregation (DMA) –If we set pPreferredFragmentSize to a large value so that the length of MSDU can not exceed it in all cases. As a result, MSDU will not be fragmented. –The Fragment number and Last fragment number will always be 0, and thus can be removed. Save 14 bits! –Add a new Fragmentation bit in Frame Control of MAC header, which indicates the existence of Fragment number and Last fragment number, in other words, they become optional. –Correspondingly, this Fragmentation bit can also indicate the existence of Fragment number in MPDU ID block of Dly-ACK frame. Save 7 * n bits!

19. doc.: IEEE 802.15-08-0125-01-003c Submission March, 2008 Inha Univ.Slide 19 Suggestions concerned with Aggregation Whether or not can ACK frame be aggregated with data frame in one PHY frame? –Yes. This situation is not prohibited, because aggregation is intended to be transparent to MAC layer. –However, it is not suggested to aggregate ACK frame with data frame, because ACK frame would be delayed and could result in low performance. –If aggregation is used in bi-directional communication, Imm-ACK frames could be aggregated under some special condition.

20. doc.: IEEE 802.15-08-0125-01-003c Submission March, 2008 Inha Univ.Slide 20 Conclusions Fully utilize existing ACK policies Easy to revise and implement Less compatibility problems with previous standards