March, 2008 Inha Univ. Slide 1 doc.: IEEE 802.15-08-0125- 01-003c Submiss ion Project: IEEE P802.15 Working Group for Wireless Personal Area Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) 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: [[email protected], [email protected], [email protected]] 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
Transcript
March, 2008
Inha Univ.Slide 1
doc.: IEEE 802.15-08-0125-01-003c
Submission
Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)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: [[email protected], [email protected], [email protected]] 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.
March, 2008
Inha Univ.Slide 2
doc.: IEEE 802.15-08-0125-01-003c
Submission
Overview
• Review of ACK Policies
• Combination of Imm-ACK and Imp-ACK
• Suggestions concerned with UEP and aggregation
March, 2008
Inha Univ.Slide 3
doc.: IEEE 802.15-08-0125-01-003c
Submission
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)
March, 2008
Inha Univ.Slide 4
doc.: IEEE 802.15-08-0125-01-003c
Submission
Current DF
March, 2008
Inha Univ.Slide 5
doc.: IEEE 802.15-08-0125-01-003c
Submission
Current DF
March, 2008
Inha Univ.Slide 6
doc.: IEEE 802.15-08-0125-01-003c
Submission
Immediate ACK
March, 2008
Inha Univ.Slide 7
doc.: IEEE 802.15-08-0125-01-003c
Submission
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.
March, 2008
Inha Univ.Slide 8
doc.: IEEE 802.15-08-0125-01-003c
Submission
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.
March, 2008
Inha Univ.Slide 9
doc.: IEEE 802.15-08-0125-01-003c
Submission
Block ACK
March, 2008
Inha Univ.Slide 10
doc.: IEEE 802.15-08-0125-01-003c
Submission
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”?
March, 2008
Inha Univ.Slide 11
doc.: IEEE 802.15-08-0125-01-003c
Submission
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.
March, 2008
Inha Univ.Slide 12
doc.: IEEE 802.15-08-0125-01-003c
Submission
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.
March, 2008
Inha Univ.Slide 13
doc.: IEEE 802.15-08-0125-01-003c
Submission
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 155—Parallel 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”
March, 2008
Inha Univ.Slide 14
doc.: IEEE 802.15-08-0125-01-003c
Submission
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 )
4 l l 2 … 2 1 1 1 10
FCS LSB ReTX bitmap
MSB ReTX bitmap
MPDU ID block n
… MPDU ID block 1
MPDU ACKed
Max frames
Max burst
MAC header
March, 2008
Inha Univ.Slide 15
doc.: IEEE 802.15-08-0125-01-003c
Submission
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.
March, 2008
Inha Univ.Slide 16
doc.: IEEE 802.15-08-0125-01-003c
Submission
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”.
March, 2008
Inha Univ.Slide 17
doc.: IEEE 802.15-08-0125-01-003c
Submission
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.
March, 2008
Inha Univ.Slide 18
doc.: IEEE 802.15-08-0125-01-003c
Submission
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!
March, 2008
Inha Univ.Slide 19
doc.: IEEE 802.15-08-0125-01-003c
Submission
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.
March, 2008
Inha Univ.Slide 20
doc.: IEEE 802.15-08-0125-01-003c
Submission
Conclusions
• Fully utilize existing ACK policies
• Easy to revise and implement
• Less compatibility problems with previous standards
