1 / 7

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: [Preamble comment resolution ] Date Submitted: [July 14, 2010]

Télécharger la présentation

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: [Preamble comment resolution] Date Submitted: [July 14, 2010] Source: [Hiroshi Harada1, Fumihide Kojima1, Ryuhei Funada1, Sum Chin Sean1, Takaaki Hatauchi2, Kazuo Kubo3, Tomonori Sato4, Kentaro Sakamoto5, Aiichiro Kashiwagi6, Takahiro Banno7, Hirohito Nishiyama8] Company [1NICT, 2Fuji Electric, 3Panasonic, 4Toshiba Toko Meter Systems, 5Tokyo Gas, 6Osaka Gas, 7Toho Gas, 8Mitsubishi Electric Corp.] Address [13-4, Hikari-no-oka,Yokosuka-shi, Kanagawa 239-0847, Japan] Voice:[1+81-46-847-5074] FAX: [1+81-46-847-5440] E-Mail:[f-kojima@nict.go.jp, harada@nict.go.jp ] Re: [TG4g comment resolution] Abstract: [Preamble comment resolutions] 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. Summary This document describes the proposed resolution on the comments related to preamble. The following comments are addressed; CID#818, #826, #1003, #1004, #1150, #1155 and #1534.

  3. CID 818 Comment: Signaling speed for FSK preamble is not mentioned here. Response: Accept Proposed Resolution:Add following sentence at the 6.12a.1.1.“All fields in PPDU use the same symbol rate and modulation order, unless specified otherwise elsewhere in this standard."

  4. Preamble length comments CID 826: Specifying 4 - 1000 octets for the preamble length is not useful. It results in a huge verification space. A preamble length of 4 octets is too short in order to benefit from the coding gain introduced by FEC. CID 1150: The range of PIB attribute phyPreambleRepetitions is debatable. A preamble length of 1000 octets is unnecessary. It complicates time out logic and, if used, can add significant on-air overhead. A short preamble can lead to increased cost, thus, the minimum length should also be increased. CID 1534: Some of the PHY synchronization preambles seem to be unnecessary large. For devices that are reasonably well-aligned (e.g., only 100ns out of synch), such as may be the case with back-to-back communications, one should be able to cut-down on the synchronization preamble, thereby saving on time latency, communication energy, and the-like. An example hereof would be ACK frames (roughly 50% of traffic), which are almost in synch with the frame they respond to. Suggested remedy: introduce low-overhead PHY headers for almost-in-synch communication pairs, such as ACKs.

  5. Preamble length comments - Response Response: Reject (for all preamble length related comments) Increasing minimum lengthNo need to increase minimum length as it works without any problem under existing standard (15.4d) and could unnecessarily increase energy consumption, which must be avoided, especially for battery operated devices. Decreasing maximum lengthMaximum length has been chosen so as to satisfy broader range of application areas, and is required for very low duty-cycled devices.

  6. CID 1003 & 1004 Comment: while FSK support variable preamble length from 4 to 1000 octets, it's better to define a mandatory length. Response: Reject (for both comments)There are no reasons nor use cases to define a mandatory length, as a receiver does not have to receive all preambles and devices may operate under various duty cycles, synchronization methods.

  7. CID 1155 Comment: phyPreambleRepetitions description: the value is not "in octets" it is the number of times the octet long preamble pattern is repeated. Response: Accept Proposed Resolution: Change to “number of times the 1-octet preamble pattern (6.3.1) is repeated.”

More Related