doc.: ieee 802.15-08-0125-00-003c submission march, 2008 inha univ.slide 1 project: ieee p802.15...
TRANSCRIPT
March, 2008
Inha Univ.Slide 1
doc.: IEEE 802.15-08-0125-00-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-00-003c
Submission
Overview
• Review of ACK Policies
• Combination of Imm-ACK and Imp-ACK
March, 2008
Inha Univ.Slide 3
doc.: IEEE 802.15-08-0125-00-003c
Submission
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
March, 2008
Inha Univ.Slide 4
doc.: IEEE 802.15-08-0125-00-003c
Submission
Current DF1
March, 2008
Inha Univ.Slide 5
doc.: IEEE 802.15-08-0125-00-003c
Submission
Current DF1
March, 2008
Inha Univ.Slide 6
doc.: IEEE 802.15-08-0125-00-003c
Submission
Immediate ACK
March, 2008
Inha Univ.Slide 7
doc.: IEEE 802.15-08-0125-00-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-00-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-00-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 10
doc.: IEEE 802.15-08-0125-00-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.
• “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 11
doc.: IEEE 802.15-08-0125-00-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.