1 / 5

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: [Low latency aggregation comment resolutions] Date Submitted: [Nov-12-2008]

yoshe
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. Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Low latency aggregation comment resolutions] Date Submitted: [Nov-12-2008] Source: [Gal Basson 3, Chang woo Pyo1, Zhou Lan1, Fumihide Kojima1, Hiroyuki Nakase1, Hirosh Harada1, Shuzo Kato1 ,Su-Khiong Yong1, Pengfei Xia2, Huai-Rong Shao2, Chiu Ngo2, Jisung Oh2, Edwin Kwon2, Seongsoo Kim2 ] Company: [NICT 1, Samsung2 , Wilocity 3] Address: [] Voice: [], FAX: [], E-Mail:[] Re: [] Abstract: [Low latency aggregation comment resolutions] 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. Comment resolution for Aggregation- low latency - • IDLE-MPDU Comments • Comment #37: Figure 10m shows the format of MSDU sub-header of an IDLE-MPDU, However the definition of IDLE-MPDU and its format is missing • Comment #177: Figure 10m only defines the MSDU sub-header of IDLE-MPDU. No definition of the format of IDLE-MPDU. Does IDLE-MPDU have multiple MSDUs or only one MSDU? Doe s it has MAC sub-header too? Does it has sub-frame payload? • Comment #186: It is not clear how to aggregate IDLE MPDUs • Comment #178:Can MSDUs and IDLE-MPDUs are mixed together since they are processed at different layers? • Comment #179:MPDU HCSn field set to inverted MSDU sub-header HCS to ensure the MSDU HCS check fails." is not a good solution since it requests the receiver to continuously searching and calculate HCS when it meets IDLE-MPDUs. It is not power efficient. • Suggested resolution for the comment above: • Accept in principal, as described at document 806

  3. Suggested resolution outline • IDLE-MPDU – the name Idle-MPDU is misleading. • Define Zero length MSDU instead of IDLE-MPDU with an inverted HCS • Clarify when Zero Length MSDU is transmitted • 2 Cases • Packet transmission have already started, and there is no MSDU at the FCSL • No transmission over the air-no need to transmit Zero Length MSDU • Allow the transmission of Zero length PPDU for the purpose of maintaining the wireless link alive • PHY preamble + Header only

  4. Suggested Resolution: • Remove this text from page 21: • The MSDU subheader for an IDLE-MPDU, as described in 8.7a.2, shall be formatted as illustrated in Figure 10m. • The MPDU HCSn field is set to the inverted MSDU subheader HCS value, as defined in 12.2.4.2.4, to ensure the MSDU HCS check fails. The next valid MSDU following any number of IDLE-MPDUs will be matched by its valid MSDU header HCS. • Remove also Figure 10m from page 21 • On page 19, line 36 add the following sentence • The length field can be set to 0 to allow idle transmission of data if data is not present at the FCSL, the HCS field shall be inverted in the case of zero length MSDU to ensure that the MSDU HCS check fails. • On page 52 change the following paragraph • In low latency aggregation mode, the source receives MSDUs from the FCSL, and aggregates them into the MAC frame body. Each MSDU is formatted as described in 7.2.8.2. The source shall aggregate IDLE Zero length MPSDUs if there is notan MSDU available from the FCSL until an MSDU is available, or until the BCRD timeout has expired. If the source has not received any MSDU from the FCSL until the beginning of the next BCRD period, the source may transmit a zero length frame with the ACK Policy set to no-ACK, the aggregation bit set to "0" and the low-latency mode bit set to "1" in the PHY header (for the purpose of maintaining the link alive).Each MSDU transmitted is assigned an MSDU number on its first transmission which is used to identify it uniquely in the MSDU sequence delivered to the destination FCSL. Zero Length MSDU Sequence number is assigned the most recent sequence number transmitted by the source. No retransmission is required for Zero Length MSDU.

  5. Comment #44: "order offset" is not clear Withdraw

More Related