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)

Slides:



Advertisements
Similar presentations
Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Implicit RIT Enhancement to RIT] Date.
Advertisements

Doc.: IEEE k Submission Matt Johnson, ItronSlide 1 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs)
Doc.: IEEE c Submission March, 2008 Inha Univ.Slide 1 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs)
Doc.: IEEE c Submission March, 2008 Inha Univ.Slide 1 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs)
Doc.: IEEE /081r0 Submission January 2001 Shoemake, Texas InstrumentsSlide 1 Project: IEEE P Working Group for Wireless Personal Area Networks.
Doc.: IEEE xxxxx Submission doc. : IEEE wng0 Slide 1 Project: IEEE P Working Group for Wireless Personal Area Networks.
Doc: IEEE k TG4k Submission Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title:[Sliding.
Doc.: IEEE Submission August 18, 2004 Bill Shvodian, Freescale SemiconductorSlide 1 Project: IEEE P Working Group for Wireless Personal Area.
Doc.: IEEE c Submission March, 2008 ETRISlide 1 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission.
Doc.: IEEE /xxxr0 Submission Phil Jamieson November 2002 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission.
Doc.: IEEE c SubmissionSlide 1 Qualcomm 2/29/2016 Slide 1 Project: IEEE P Working Group for Wireless Personal Area Networks.
Doc.: IEEE c Submission Slide 1 July, 2008 Chang woo Pyo, NICT Project: IEEE P Working Group for Wireless Personal Area Networks.
Doc.: IEEE c Submission January 2008 ETRISlide 1 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission.
Doc.: IEEE /250r0 Submission, Slide 1 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: IEEE :
Doc.: IEEE Submission ETRI May 2015 Slide 1 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission.
2018/4/ /4/18 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: Overview of Date Submitted:
Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [ MAC Addresses] Date Submitted:
Project: IEEE Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Proposals for adding a version number and for the treatment.
Project: IEEE Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Proposals for adding a frame version number and for the.
Submission Title: [Resolution on comment #20,22 and 30]
doc.: IEEE <doc#>
May 2018 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Discussion on Suitable Parameters for SCHC]
doc.: IEEE <02/139r0> <January 2002> May, 2009
May 2018 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Considerations on general MAC frame] Date Submitted:
<January 2002> doc.: IEEE <02/139r0> May, 2008
doc.: IEEE <doc#>
NOV 01 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Application Specific Information Element] Date.
Submission Title: [Comment Resolutions for #309, #310, and #314]
doc.: IEEE <doc#>
doc.: IEEE <doc#>
Name - WirelessHD August 2008
<January 2002> doc.: IEEE <02/139r0> 12/8/2018
doc.: IEEE <doc#>
Submission Title: [ c comment resolution on #7]
doc.: IEEE <doc#>
November 2007 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Issues on Superframe Size for Uncompressed.
Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Improved Delayed ACK response Frame for.
doc.: IEEE <doc#>
< November, 2011 > Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [More Low Energy Mechanism Details]
Jan Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: Reliable data transmission Date Submitted:
Doc.: IEEE /XXXr0 10 May 2011 Sep 19, 2007 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs)‏ Submission Title:
May 2018 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Discussion on Suitable Parameters for SCHC]
doc.: IEEE <doc#>
doc.: IEEE <doc#>
doc.: IEEE <doc#>
Submission Title: [Resolution on comment #20,22 and 30]
January 2010 doc.: IEEE /0825r2 January 2010
Submission Title: [Comment Resolutions for #309, #310, and #314]
November 2009 doc.: IEEE /0825r0 November 2009
<author>, <company>
<January 2002> doc.: IEEE <02/139r0> March, 2008
<month year> <doc.: IEEE doc> September 2010
<author>, <company>
Sept Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Add the Authentication to Enhance the Security.
doc.: IEEE <doc#>
May 2018 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Considerations on general MAC frame] Date Submitted:
May 2004 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Delayed Negative Acknowledgement (Dly-NACK)]
doc.: IEEE <doc#>
<author>, <company>
July 2004 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Modified Delayed (Dly) Acknowledgement for.
<author>, <company>
<January 2002> doc.: IEEE <02/139r0> March, 2008
<January 2002> doc.: IEEE <02/139r0> March, 2008
doc.: IEEE <doc#>
Submission Title: [JPKG comment suggestions]
doc.: IEEE <doc#1>
doc.: IEEE <doc#1>
Name - WirelessHD August 2008
August 2019 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: Still More LB156 Comment Resolutions Date.
August 2019 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: Still More LB156 Comment Resolutions Date.
Presentation transcript:

doc.: IEEE c Submission March, 2008 Inha Univ.Slide 1 Project: IEEE P 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, , Republic of Korea] Voice: [], FAX: [], 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 c standard] Notice: This document has been prepared to assist the IEEE P 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

doc.: IEEE c 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

doc.: IEEE c Submission March, 2008 Inha Univ.Slide 3 Current ACK Policies No ACK Imm-ACK Dly-ACK Imp-ACK –Added in IEEE b standard Blk-ACK –Added in IEEE c draft (DFx)

doc.: IEEE c Submission March, 2008 Inha Univ.Slide 4 Current DF

doc.: IEEE c Submission March, 2008 Inha Univ.Slide 5 Current DF

doc.: IEEE c Submission March, 2008 Inha Univ.Slide 6 Immediate ACK

doc.: IEEE c 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.

doc.: IEEE c 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.

doc.: IEEE c Submission March, 2008 Inha Univ.Slide 9 Block ACK

doc.: IEEE c 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?

doc.: IEEE c 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.

doc.: IEEE c 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.

doc.: IEEE c 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: FCS –Description of 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

doc.: IEEE c 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… FCSLSB ReTX bitmap MSB ReTX bitmap MPDU ID block n …MPDU ID block 1 MPDU ACKed Max frames Max burst MAC header

doc.: IEEE c Submission March, 2008 Inha Univ.Slide 15 Suggestions concerned with Aggregation Blk-ACK can be replaced by Dly-ACK. –Refer to c 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.

doc.: IEEE c 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.

doc.: IEEE c 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.

doc.: IEEE c 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!

doc.: IEEE c 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.

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