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

1. Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Resolutions for HSI PHY Comments] Date Submitted: [May 14, 2008] Source: [Tuncer Baykas, M. Azizur Rahman, Ruhei Funada, Chang woo Pyo, Zhou Lan, Fumihide Kojima, Chin-Sean Sum, Junyi Wang, Hiroshi Harada, Shuzo Kato (1), Ismail Lakkis (3)] Company [(1)National Institute of Information and Communications Technology (NICT), (3)Tensorcom] Address1[3-4 Hikari-no-oka, Yokosuka-shi, Kanagawa 239-0847, Japan] Voice1:[+81-46-847-5074] , FAX1: [+81-46-847-5440] E-Mail[] Re: [In response to TG3c Call for Proposals (IEEE P802.15-07-0586-02-003c)] Abstract: [Resolutions for HSI PHY Comments] Purpose:[To be considered in TG3C baseline document.] 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 contributors acknowledge and accept that this contribution becomes the property of IEEE and may be made publicly available by P802.15.

2. Comment 6 HSI-OFDM: Can SC and HIS PHY use single preamble format? Resolution: The comment is correct. We want to keep it open.

3. Comment 17 HSI-OFDM: There are too many reserved bits in the PHY header Resolution: The comment is correct. We want to keep it open.

4. Comment 18 HSI-OFDM: Is it possible to combine the base and optional headers to fit in one OFDM symbol at the highest rate? Resolution: The comment is correct. We want to keep it open.

5. Comment 22 HSI-OFDM: The spreader buy 4 and 28 are messed up by the tone interleaver. Resolution: The comment is correct. We want to keep it open.

6. Comment 111 Freame format is different than one from SC - there is no need for that, unify format and header fields - introducing some mininla redundancy Resolution: The comment is correct. We want to keep it open.

7. Arrived Late Comment 16 The given q sequence is of length 11, rather than 12 Resolution: Accept comment. Add -1 to right of the sequence.

8. Arrived Late Comment 17 The HSI outer interleaver is not specified Resolution: Accept comment. The outer interleaver is a block interleaver of depth seven, i.e. over seven read Solomon block codes. The outer interleaving is performed by first grouping the Reed Solomon coded octets into blocks of 1764 octets and then using a block interleaver of size 7 by 252 to permute the coded octets. Let k and i denote the index of the octets before and after interleaving respectively. The outer interleaver can be defined by the rule: The floor function returns the largest integer value less than or equal to its argument value, and is the modulus operator, which returns the non-negative integer remainder when a is divided by b.

9. Arrived Late Comment 18 Bit interleaver is OPTIONAL, but how to signal it in header? Also, is bit interleaver mandatory or optional or forbidden in header? If bit interleaver is optional in header, how to signal it in preamble? Resolution: Comment accepted. Interleaving is forbidden in the header. We should add 1 bit in the Phy header to indicate interleaving for the data portion of the frame.

10. Arrived Late Comment 19 In table 146, 2nd row and 3rd column, the upper limit tone index for null subcarriers is 255 rather than 256 Resolution: Comment accepted. Upper limit of tone index for null subcarriers shall be 255.

11. Arrived Late Comment 20 In table 132, 3rd row and 3rd column, Should be 216 rather than 236, for RS(232,216)? In page 80 line 22, the spec says RS(232,216). Which RS coding rate is defined here? Resolution: Correct code is RS(252,236). 236 is correct.

12. Arrived Late Comment 21 RS(232,216) rahter than "RS(253,236)"? In page 80 line 22, the spec says RS(232,216). Which RS coding rate is defined here? Resolution: Defined code is RS(252,236)

13. Arrived Late Comment 22 In table 130, last row and last column, number of padding bits for the case SF=1 in header is not correct.] Resolution: The comment is correct but optional header has changed. (Comment 19). New values should be added by editor.

14. Arrived Late Comment 23 Table 138 is not consistent with table 137, the conditions should be defined by combining CES length and Header rate . Resolution: Comment accepted. It was decided during last Orlando meeting that table 138 should be removed.

15. Arrived Late Comment 24 Where is the filter g defined in DF3? If it is the same as that in DF1, then the index of g filter should be -12:12, rather than "-13:13" as in DF1. But in general, g filter is NOT necessary in the preamble. It is just a matter of power scaling issue, which can be done using simple baseband scaling factor, and should be completely an implementation issue. The mandatory g filter in the standard will only increase the receiver channel estimation complexity, and gives no performance improvement. Resolution:Comment accepted. It was decided during last Orlando meeting that filter g left to implementer.