1. July 2010
doc.: IEEE
July 2010
Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs)
Submission Title: Proposal for TG6 Clause 9 Comment Resolution
Date Submitted: 13 July, 2010
Source: Anuj Batra, Texas Instruments and Mark Dawkins, Toumaz Technology
Re: Response to IEEE Letter Ballot comments
Abstract: This document proposes several resolutions for Letter Ballot 55, specifically for the Narrowband PHY section.
Purpose: For discussion by IEEE TG6
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
Anuj Batra and Mark Dawkins, TI and Toumaz
Anuj Batra and Mark Dawkins, TI and Toumaz

2. Header Check Sequence Comment(s): S9-1, S9-26 Proposed Resolution:
July 2010
Header Check Sequence
Comment(s): S9-1, S9-26
“The order of transmission of HCS seems to be MSB to LSB and is not consistent with LSB to MSB transmission chosen for the rest of the document”
Proposed Resolution:
Change MSB to HCS0 and LSB to HCS3 in Figure 109, or
Replace Figure 109 with the following
Discussion:
Changing the labels on the shift registers will any eliminate confusion
Anuj Batra and Mark Dawkins, TI and Toumaz

3. Transmit Order (1) Comment(s): S9-2, S9-27 Proposed Resolution:
July 2010
Transmit Order (1)
Comment(s): S9-2, S9-27
“first bit of the message – first bit of the message to be transmitted?”
Proposed Resolution:
Add text into line 17 of :
“…m50 is the first bit of the message to be transmitted and m0 is the last bit …”
Discussion:
This addition clarifies the meaning of m50, since by previous definition the first bit transmitted is always the least significant bit.
Anuj Batra and Mark Dawkins, TI and Toumaz

4. Transmit Order (2) Comment(s): S9-80, S9-92 Proposed Resolution:
July 2010
Transmit Order (2)
Comment(s): S9-80, S9-92
“first bit of the message – first bit of the message to be transmitted?”
Proposed Resolution:
Replace 9.4 (b) step (1) with the following text:
“Divided into blocks of messages starting with the LSB of the least significant octet of the PSDU and continuing to the MSB of the most significant octet of the PSDU”
Replace 9.4 (b) step (2) with the following text:
“Shortening bits may then be appended to the messages, which are then encoded into codewords using a BCH (63, 51) encoder to achieve the desired code rate, according to
Discussion:
Above text addresses how the PSDU into broken into messages
Anuj Batra and Mark Dawkins, TI and Toumaz

5. Bit Interleaver Comment(s): S9-4, S9-29 Proposed Resolution:
July 2010
Bit Interleaver
Comment(s): S9-4, S9-29
“The bit interleaver is used only for the spread case. This is ambiguous in the document”
Proposed Resolution:
Add the following text to the start of line 9 in Section 9.4.4:
“In the case that spreading factor is equal to 2 or 4, the output …”
Discussion:
Adding this text clarifies that the bit interleaver is only used when the spreading factor is 2 or 4.
Anuj Batra and Mark Dawkins, TI and Toumaz

6. Reference Phase Comment(s): S9-6, S9-7, S9-31, S9-32, S9-57, S9-116
July 2010
Reference Phase
Comment(s): S9-6, S9-7, S9-31, S9-32, S9-57, S9-116
“what is S(0)? Is this the first symbol to be transmitted of the PLCP preamble?”
Proposed Resolution:
Replace line 11 in Section with the following text:
“where S(-1) = exp(jp/2) is the reference for the first symbol of the preamble and ..”
Change the range in line 10 (equation 65) to start at k=0
Discussion:
These change remove any ambiguity for the reference phase
Anuj Batra and Mark Dawkins, TI and Toumaz

7. Constellation Mapping
July 2010
Constellation Mapping
Comment(s): S9-8, S9-33
“what is the bit stream – is this the concatenated bit stream?”
Proposed Resolution:
Bring Section Constellation Mapping one level higher, thereby making it into its own section
Insert the following text under the title heading Constellation Mapping:
“The constellation mapper operates on the binary bit stream b(n), which is the concatentation of the PLCP preamble, the PLCP header and the PSDU.”
Change the first sentence of Section to the following:
“For the GMSK constellation, b(n), n = 0, 1, …, N-1 shall be mapped onto …”
Change the first sentence of Section to the following:
“For the D-PSK constellations, b(n), n = 0, 1, …, N-1 shall be mapped onto …”
Discussion:
These changes clarify the definition of the binary bit stream
Anuj Batra and Mark Dawkins, TI and Toumaz

8. Scrambler (1) Comment(s): S9-5, S9-30 Proposed Resolution: Discussion:
July 2010
Scrambler (1)
Comment(s): S9-5, S9-30
“The first bits coming out of the scrambler to scramble data after initialization is ambiguous”
Proposed Resolution:
Add the following text to section on line 9:
“For example, when the Scrambler Seed is set to 0, the first 20 bits out of the scrambler are: ”
Discussion:
Enumerating the first 20 bits of the scrambler for a given scrambler seed will eliminate any confusion
Anuj Batra and Mark Dawkins, TI and Toumaz

9. Scrambler (2) Comment(s): S9-18 Proposed Resolution: Discussion:
July 2010
Scrambler (2)
Comment(s): S9-18
“No mention of how many bits are needed to flush the scrambler”
Proposed Resolution:
Reject comment
Discussion:
The narrowband PHY uses a side-stream scrambler, therefore the scrambler does not need to be flushed since the data bits are not fed into the scrambler
Anuj Batra and Mark Dawkins, TI and Toumaz

10. Scrambler Seed Comment(s): S9-53 Proposed Resolution: Discussion:
July 2010
Scrambler Seed
Comment(s): S9-53
“On one hand, it is said that scrambler seed depends on even number of channels. Then, why do require the scrambler seed bit”
Proposed Resolution:
Reject comment
Discussion:
PLCP header uses a scrambler seed based on channel number, while PSDU's scrambler seed is specified by the MAC
Anuj Batra and Mark Dawkins, TI and Toumaz

11. Sensitivity Comment(s): S9-12, S9-37, S9-48 Proposed Resolution:
July 2010
Sensitivity
Comment(s): S9-12, S9-37, S9-48
“The minimum sensitivity numbers can be lower than the numbers listed in Table 49.”
Proposed Resolution:
Change text in line 19 Section to
“For a packet error rate (PER) of less than or equal to 10% with a PSDU of 255 octets in AWGN, a compliant device shall achieve receiver sensitivities listed in Table 49, or better”
Change heading for column 3 in Table 49 to “Maximum Input Level at Sensitivity (dBm)
Discussion:
Clarifies that the sensitivity can be lower than the number listed in Table 49
Anuj Batra and Mark Dawkins, TI and Toumaz

12. Sensitivity Numbers Comment(s): S9-69 Proposed Resolution: Discussion:
July 2010
Sensitivity Numbers
Comment(s): S9-69
“The minimum receiver sensitivity is very strict for BAN (more tight than Zigbee and much more tight than Bluetooth LE), which could prevent low power designs. Better to define to a more relaxed sensitivity a) –76 dBm for IEEE b 11 Mb/s CCK b) –70 dBm for IEEE Std c) –75 dBm for IEEE Mb/s DQPSK d) –85 dBm for IEEE Std ”
Proposed Resolution:
Reject comment
Discussion:
Sensitivity numbers are already quite loose with a 10 dB noise figure and 6 dB implementation margin
Anuj Batra and Mark Dawkins, TI and Toumaz

13. ED Threshold (1) Comment(s): S9-13, S9-22, S9-38, S9-49, S9-65
July 2010
ED Threshold (1)
Comment(s): S9-13, S9-22, S9-38, S9-49, S9-65
“ED Threshold should be defined as 10 dB above the minimum receiver sensitity, which corresponds to the lowest data rate”
Suggestion:
Modify first bullet to say “10 dB above the minimum specified receiver sensitivity (see 9.8.1) OR”
Counter-proposal Resolution:
Modify first bullet to say "10 dB above the receiver sensitivity as defined in Table 49 for the lowest data rate within a given band (see 9.8.1) OR"
Discussion:
Counter-proposal eliminates any confusion over what is the minimum specified receiver sensitibity
Anuj Batra and Mark Dawkins, TI and Toumaz

14. ED Threshold (2) Comment(s): S9-43 Proposed Resolution: Discussion:
July 2010
ED Threshold (2)
Comment(s): S9-43
“Specifying details for "ED Threshold" is key to ensuring interoperabililty with existing MICS systems compliant with standards such as EN V1.3.1.”
Proposed Resolution:
Replace the text in the second bullet, section with the following:
“that which is prescribed by local regulatory requirements, or applicable standards, whichever is lower.”
Discussion:
It is dangerous to reference any specific documents, because if the documents change, then the standard also needs to be unnecessarily updated
Anuj Batra and Mark Dawkins, TI and Toumaz

15. ED Threshold (3) Comment(s): S9-45 Proposed Resolution: Discussion:
July 2010
ED Threshold (3)
Comment(s): S9-45
“Specifying details for ‘ED Measurement Time’ is key to ensuring interoperabililty with existing MICS systems compliant with standards such as EN V1.3.1.”
Proposed Resolution:
Replace the text in the second bullet, section with the following:
“that which is prescribed by local regulatory requirements, or applicable standards, whichever is longer in duration.”
Discussion:
It is dangerous to reference any specific documents, because if the documents change, then the standard also needs to be unnecessarily updated
Anuj Batra and Mark Dawkins, TI and Toumaz

16. pMIFS Comment(s): S9-20, S9-63 Proposed Resolution: Discussion:
July 2010
pMIFS
Comment(s): S9-20, S9-63
“The way this statement is written, it gives no tolerance to the transmitter or receiver requirements”
Proposed Resolution:
Change the first sentence in Section to the following:
“For burst mode transmissions, the inter-frame spacing between uninterrupted successive transmissions by a device shall be fixed to exactly pMIFS  1 symbol.”
Discussion:
The text above adds of a tolerance of  1 symbol.
Anuj Batra and Mark Dawkins, TI and Toumaz

17. Shortened Bits Comment(s): S9-54, S9-76 Proposed Resolution:
July 2010
Shortened Bits
Comment(s): S9-54, S9-76
“Shortened bits are removed prior to transmission”
Proposed Resolution:
Reject comment
Discussion:
The description is clear enough
Anuj Batra and Mark Dawkins, TI and Toumaz

18. Pad Bits Comment(s): S9-55, S9-77 Proposed Resolution: Discussion:
July 2010
Pad Bits
Comment(s): S9-55, S9-77
“Pad bits should be appended after BCH encoder”
Proposed Resolution:
Reject comment
Discussion:
In Section lines 1-2, it is stated that the pad bits are appended to the PSDU and are all set to zero
Anuj Batra and Mark Dawkins, TI and Toumaz

19. Frequency Deviation Comment(s): S9-56 Proposed Resolution: Discussion:
July 2010
Frequency Deviation
Comment(s): S9-56
“frequency deviation is mapped into deltaF”
Proposed Resolution:
Reject comment
Discussion:
Parameters listed in draft are sufficient to generate GMSK
Anuj Batra and Mark Dawkins, TI and Toumaz

20. Higher Data Rates in 2.4 GHz
July 2010
Higher Data Rates in 2.4 GHz
Comment(s): S9-59
“For various applications such as endoscope capsule, high data rates can be supported in standard.”
Proposed Resolution:
Reject comment
Discussion:
We want to make the radio simple in the 2.4 GHz band, therefore, we don’t want to add a constellation higher than D-QPSK
Anuj Batra and Mark Dawkins, TI and Toumaz

21. MICS Modulation Schemes
July 2010
MICS Modulation Schemes
Comment(s): S9-60
“GFSK and GMSK modulation scheme are very well proved solution for in-body applications at MICS band such as pacemaker and implantable cardioverter. IEEE standard does not consider GFSK modulation in MICS band”
Proposed Resolution:
Reject comment
Discussion:
Providing experimental results is not a requirement for standardization. GFSK/GMSK were consider for the MICS band but not selected by group because it has higher SNR requirements for the same data rates as is required for D-PSK
Anuj Batra and Mark Dawkins, TI and Toumaz

22. Roll-Off Factor for SRRC
July 2010
Roll-Off Factor for SRRC
Comment(s): S9-71, S9-100
“Roll-off factor of the square root raised cosine filter shall be specified”
Proposed Resolution:
Reject comment
Discussion:
Roll-off factor is left to implementor to allow designers to trade-off spectrum bandwidth and peak-to-average ratio (PAR)
Anuj Batra and Mark Dawkins, TI and Toumaz

23. Operating Frequency Bands
July 2010
Operating Frequency Bands
Comment(s): S9-72
“Operating frequency bands are already specified in the preceding text, and is unnecessary to be specified here”
Proposed Resolution:
Reject comment
Discussion:
There is no harm in repeating the information, and it improves readability for this section
Anuj Batra and Mark Dawkins, TI and Toumaz

24. PHY Header Comment(s): S9-75 Proposed Resolution: Discussion:
July 2010
PHY Header
Comment(s): S9-75
“the PHY header shall be protected”
Proposed Resolution:
Reject comment
Discussion:
Current text is sufficiently clear
Anuj Batra and Mark Dawkins, TI and Toumaz

25. Figure Bypass Comment(s): S9-81, S9-93 Proposed Resolution:
July 2010
Figure Bypass
Comment(s): S9-81, S9-93
“Bypass should be indicated in case of no spreading for the spreader and bit interleaver.”
Proposed Resolution:
Reject comment
Discussion:
Figure and text make it sufficiently clear that spreading block and interleaver block are bypassed when spreading factor = 1
Anuj Batra and Mark Dawkins, TI and Toumaz

26. pCCATime Comment(s): S9-82, S9-94, S9-119, S9-138 Proposed Resolution:
July 2010
pCCATime
Comment(s): S9-82, S9-94, S9-119, S9-138
“change to pCCATime shall be the lower of those specified in Table 44 or by local regulatory authorities”
“text should read ‘whichever is lower’”
Proposed Resolution:
In Section 9.6 line 13, change “which” to “whichever”
Discussion:
Text already states that the pCCATime is the lower of values in Table 44 or the values specified by the local regulatory authorities
Anuj Batra and Mark Dawkins, TI and Toumaz

27. Optional PHY Comment(s): S9-83 Proposed Resolution: Discussion:
July 2010
Optional PHY
Comment(s): S9-83
“Why is this document defining optional physical layer for , when this is to be ?”
Proposed Resolution:
Reject comment
Discussion:
It is not an optional PHY, but rather one of the possible PHY options, you could implement a UWB-only PHY and still be compliant to (see original standard for similar situation)
Anuj Batra and Mark Dawkins, TI and Toumaz

28. Missing Period Comment(s): S9-87 Suggested resolution:
July 2010
Missing Period
Comment(s): S9-87
“Extra period”
Suggested resolution:
remove character " . "
Counter-proposal Resolution:
Add a period to the end of the sentence on line 15
Discussion:
Need to end sentence with a period
Anuj Batra and Mark Dawkins, TI and Toumaz

29. SRRC Equation July 2010 Comment(s): S9-95 Proposed Resolution:
“The standard does not define a Square Root Raised Cosine (SRRC) filter for the transmitter”
Proposed Resolution:
Insert a new section 9.x, entitled “SRRC Pulse Shape”, to follow the section “Constellation Mapping”
Insert the following the text into this new section: “The square-root raised cosine (SRRC) pulse shape with roll-off factor b and symbol period Ts described in Equation (x) shall be used to filter the symbols and shape the spectrum.
(x)
The exact value for the roll-off factor b and the duration of the SRRC pulse shape is implementation dependent.”
In Tables 26-32, replace “Symbol Rate (ksps)” with “Symbol Rate = 1/Ts (ksps)”
Discussion:
This new section defines the time-domain impulse response for an SRRC pulse shape
Anuj Batra and Mark Dawkins, TI and Toumaz

30. Support for Frequency Bands
July 2010
Support for Frequency Bands
Comment(s): S9-96
“A compliant device with narrow band PHY shall be able to support transmission and reception in at least one of the following frequency 4 bands”
Proposed Resolution:
Reject comment
Discussion:
Section 9 already states that a compliant device shall be able to support transmission and reception in one of the following frequency 4 bands: 402 – 405 MHz, 420 – 450 MHz, 863 – 870 MHz, 902 – 928 MHz, 950 – 956 MHz, 2360 – MHz and 2400 – MHz.
Anuj Batra and Mark Dawkins, TI and Toumaz

31. D-8PSK Comment(s): S9-97 Proposed Resolution: Discussion:
July 2010
D-8PSK
Comment(s): S9-97
“making D8PSK optional will only make a overhead of negotiation.Since we only need to implement demodulator extra, it could be made mandatory too”
Proposed Resolution:
Reject comment
Discussion:
Radio requirements for D-8PSK are more difficult than for D-BPSK and D-QPSK. The intent is to keep the radio simple for the mandatory modes
Anuj Batra and Mark Dawkins, TI and Toumaz

32. Two Preambles Comment(s): S9-98, S9-101 Proposed Resolution:
July 2010
Two Preambles
Comment(s): S9-98, S9-101
“Two preamble sequences specified in the tables don’t have good cross correlation properties. The cross correlation goes as big as 1/4 of the maximum value of autocorrelation of sequences”
Proposed Resolution:
Reject comment
Discussion:
Since the preambles are used on adjacent channels (not the same channel), the cross correlation properties do not need as low as is required by UWB
The two preamble were designed to have excellent auto-correlation properties and it is difficult to find preambles that have both excellent auto- and cross-correlation properties simultaneously.
Anuj Batra and Mark Dawkins, TI and Toumaz

33. Spreading/Repetition Code
July 2010
Spreading/Repetition Code
Comment(s): S9-99
“The operation shown in section is same as repetition code”
Proposed Resolution:
Reject comment
Discussion:
This is just a change in semantics
The terminology of spreading is also valid since the trivial spreading code is the all-ones code
Anuj Batra and Mark Dawkins, TI and Toumaz

34. CRC-4 Comment(s): S9-102 Proposed Resolution: Discussion:
July 2010
CRC-4
Comment(s): S9-102
“The (63,51) BCH code has a generator polynomial of degree 12, implying that the error detection capabilities are already better than the CRC-4 code. An incorrectable codeword can be detected by syndrome computation usually applied during bounded minimum distance decoding with hard decisions on the code bits. It appears to be useless to embed the crc-4 based HCS”
Proposed Resolution:
Reject comment
Discussion:
Simulation results have shown that the BCH code + CRC-4 HCS has adequate performance and will not be limiting factor in packet error rate
CRC-4 provides a simple, low-complexity mechanism for determining if the header is in error
Anuj Batra and Mark Dawkins, TI and Toumaz

35. FCS Comment(s): S9-126 Proposed Resolution: Discussion:
July 2010
FCS
Comment(s): S9-126
“Document does not specify the generator polynomial for FCS generation”
Proposed Resolution:
Reject comment
Discussion:
FCS is generated in MAC (see section 6.2.3), not PHY
Anuj Batra and Mark Dawkins, TI and Toumaz

36. Reserved Bits in PHY Header
July 2010
Reserved Bits in PHY Header
Comment(s): S9-128
“When amending communication standards one of the issues often encountered is the lack of unassigned fields for future use.”
Proposed Resolution:
Reject comment
Discussion:
PHY Header already has two reserved bits
Anuj Batra and Mark Dawkins, TI and Toumaz

37. Accepted Comments (1) Comment(s): S9-3, S9-28, S9-46
July 2010
Accepted Comments (1)
Comment(s):
S9-3, S9-28, S9-46
S9-9, S9-10, S9-34, S9-35, S9-58, S9-78, S9-79, S9-121,
S9-11, S9-36
S9-14, S9-24, S9-39
S9-15, S9-16, S9-25, S9-40
S9-17
S9-42, S9-44
S9-47
S9-50
S9-51
S9-68
S9-73
Anuj Batra and Mark Dawkins, TI and Toumaz

38. Accepted Comments (2) Comment(s): S9-84, S9-106, S9-134 S9-85 S9-86
July 2010
Accepted Comments (2)
Comment(s):
S9-84, S9-106, S9-134
S9-85
S9-86
S9-88, S9-89, S9-90
S9-91
S9-103
S9-104, S9-128
S9-105, accept in principle – replace “any” with “one”
S9-107, S9-108, S9-109, S9-110, S9-111, S9-112, S9-113
S9-114, S9-115, S9-117
S9-118, accept in principle to only swap columns
S9-120
Anuj Batra and Mark Dawkins, TI and Toumaz

39. Accepted Comments (3) Comment(s): S9-123, S9-131
July 2010
Accepted Comments (3)
Comment(s):
S9-123, S9-131
S9-125, S9-133, S9-136
S9-127 – Update Figure 105 to follow bit order defined in Figure 108
Anuj Batra and Mark Dawkins, TI and Toumaz

40. Reject Comments Comment(s):
July 2010
Reject Comments
Comment(s):
S9-124, S9-132, S9-135, S9-137 – grammar is correct
Anuj Batra and Mark Dawkins, TI and Toumaz

41. Deferred Comments Comment(s): S9-19, S9-23, S9-62 S9-21, S9-41, S9-64
July 2010
Deferred Comments
Comment(s):
S9-19, S9-23, S9-62
S9-21, S9-41, S9-64
S9-52
S9-61, S9-74
S9-66, S9-67, S9-139, S9-140
S9-70
S9-122, S9-130
S9-12, S9-37, S9-48
Anuj Batra and Mark Dawkins, TI and Toumaz