1 / 10

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: [Resolutions to Comments on Aggregation] Date Submitted: [11 August 2008]

raimundo-gonzales
Download Presentation

Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) ‏

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Zhou Lan Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)‏ Submission Title: [Resolutions to Comments on Aggregation] Date Submitted: [11 August 2008] Source: [Z. Lan, C.W Pyo, F. Kojima,H. Nakase, C.S Sum, T. Baykas, J. Wang, R. Funada, M.A Rahman, H. Harada, S. Kato, Gal Basson (2), Tal Azogui (2) ] Company [NICT, Wilocity (2)] Address [3-4, Hikarino-oka, Yokosuka, 239-0847, Japan] Voice: [+81-46-847-5092], FAX: [+81-46-847-5440], E-Mail: [lan@nict.go.jp] Re: [] Abstract: [Resolutions to Comments on Aggregation and ACK/NACK Raised in Denver] Purpose: [This document provides a list of the editing staff that will be working on 802.15.3c.] 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. Resolution to Comments on Aggregation Wilocity & NICT Rev.1

  3. High Level Summary • This document proposes the resolutions for the comments on Aggregation • There are total of 11 comments on Aggregation • 5 for aggregation procedure and related frame format • 6 specifically for ACK/NACK field • The text (to appear in the draft document) based on the resolution given in this document can be found in “Aggregation_SubClause.doc(566/r0)”

  4. Summary of Received Comments • # 310,293,296,297,356 • Comments to add new function or modify existing function on aggregation for bug fix or performance improvement • # 561,562,565,566,567,568 • Clarify usage and naming for ACK/NACK field defined in MAC subheader

  5. Resolution of Aggregation Procedure and Frame Format Comments (1/4) • Comment #310: The usage of Blk-ACK is similar to that of Imm-ACK.Blk-ACK does not support capability negotiation like RX- TX flow control. For example: Max Burst field used for Dly-ACK • Resolution: • Add a RX buffer size field (1 octet) in MAC subheader for standard aggregation to allow targeting DEV inform originating DEV available buffer size • At pg. 17 line 23, add paragraph as “The RX buffer size field indicates the free buffer space at the target DEV in the number of pMaxFrameBodySize” • At pg. 49 line 34, add paragraph as “The target DEV shall inform the originating DEV the available receiving buffer size using RX buffer size field as defined in 7.2.9. The originating DEV adjusts the maximum number of MSDUs to send in the next frame to avoid buffer overflow”

  6. Resolution of Aggregation Procedure and Frame Format Comments (2/4) Comment # 297: inefficient retransmission of MSDUs upon reception of a corrupted MSDU Base is critical to low-latency performance. add MAC Subheader BA-Base-NAK to allow destination DEV signal the source-DEV it received a corrupted MSDU Base field to avoid retransmission of all MSDUs of previous frame Resolution: Add another field to the MAC sub header, overall to have 2 fields (4 octets) for the Base Address as follows: MSDU Base- Request field: Sent by the transmitter of the MSDUs to indicate the most recent MSDU sequence number acknowledged at the transmitter MSDU Base-Reply field: Sent by the receiver of the MSDUs (Originator of the BA) to indicate the first MSDU sequence number of the transmitted Blk-ACK bitmap-field. The MSDU Base-Reply field is used to generate the offset for the Blk-ACK bitmap field. In this case when the BA request base is corrupted, the receiver should use the old one and set the MSDU Base -Reply to the last valid MSDU Base- Request Refer to Aggregation_SubClause.doc for exact text change Refer to Annex for the illustration of the usage of these two fields 6

  7. Resolution of Aggregation Procedure and Frame Format Comments (3/4) Comment #296: The description of the Block Ack low latency is incoherent and does not describe the Base MSDU field utilization in the Block Ack mechanism Resolution: Split Base MSDU field to MSDU Base-Request and MSDU Base-Reply fields At pg.19, add paragraph as “The MSDU Base-Request field indicates the most recent MSDU sequence number acknowledged at the transmitter. The MSDU Base-Reply field indicates the first MSDU sequence number of the transmitted Blk-ACK bitmap-field. The MSDU Base-Reply field is used to generate the offset for the Blk-ACK bitmap field. The MSDU Base-Reply field shall be a copy from the received MSDU Base-Request, upon reception of a valid MAC Subheader.” At pg.52, add paragraph at line 19 as “originating DEV may abort retransmissions of a specific MSDU by advancing the MSDU Base-Request number, as defined in 7.2.9, beyond the specific MSDU sequence number. When the MSDU Base-Request is advanced beyond a missing MSDU sequence number – the receiver updates its MSDU Base-Reply accordingly and assumes the skipped MSDU sequence number is discarded.” 7

  8. Resolution of Aggregation Procedure and Frame Format Comments (4/4) Comment # 293: the description in the paragraph for the low latency aggregation BA relates to the order-offset, without relating to the MSDU Base Field in the MAC Subheader Resolution: At pg.51, change the paragraph starting from line 4 to “The destination target DEV sets the corresponding bit in the next transmitted BA Bitmap field according to its order offset taking the value of MSDU Base-Reply field in MAC subheader as reference in the frame. The MSDU Base-Reply field is updated upon reception of a valid MAC subheader, from the MSDU Base-Request. ” Comment # 356:How does the TX know the RX Buffer size? Resolution: At pg. 51, add paragraph at line 10 as “The target DEV shall inform the originating DEV the available receiving buffer size using RX buffer size field as defined in 7.2.9. The originating DEV adjusts the maximum number of MSDUs to send in the next frame to avoid buffer overflow.” 8

  9. Resolution of ACK/NACK bit Comment #561: What is the "ACK/NACK" indication? Are NACKs allowed? Resolution: ACK/NACK is a binary indication of whether the corresponding subframe is correctly received or not. NACK is not defined D00. The name of the field should be changed from “ACK/NACK” to “ACK”. Refer to Aggregation_SubClause.doc for exact text change Comment # 562: An "ACK/NACK or msb ACK" and an "ACK/NACK or lsb ACK" field are referenced. Are NACKs defined somewhere? Resolution: Same as #562. NACKs are not defined in D00. Change the field name from “ACK/NACK or msb ACK” to “ACK or msb ACK”, from “ACK/NACK or lsb ACK” to “ACK or lsb ACK”. Refer to Aggregation_SubClause.doc for exact text change Comment # 565, 566,567,568:What are the "ACK/NACK" fields in figure 10g? Is a NACK allowed and how is it to be used? Resolution: Same as that of #561, 562. Refer to Aggregation_SubClause.doc for exact text change 9

  10. Annex: Usage of MSDU Base-Request/Base-Reply field 10

More Related