1. doc.: IEEE 802.15-<doc#>
<month year>
doc.: IEEE <doc#>
Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs)
Submission Title: [Resolution for Generic PHY comments]
Date Submitted: [July 27, 2010]
Source: [Kuor Hsin Chang1, Bob Mason1, J.L.Taylor2]
Company: [Elster Solutions1, DTC (UK)2]
Address: []
Voice: []
Re: [Comment Resolution for TG4g draft]
Abstract: The presentation provides resolution for some Generic PHY related comments
Purpose: Presented to the g SUN Task Group for consideration and discussion
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
<author>, <company>

2. doc.: IEEE 802.15-<doc .....>
<May,2009>
doc.: IEEE <doc .....>
Outline
Comments to be resolved:
CID# 420, 421, 423, 424, 425, 426, 427, 449, 592, 593, 594, 596, 600, 601, 603, 610, 611, 613, 614, 615, 616, 617, 618, 1101, 1121, 1123, 1124, 1132, 1173, 1174, 1179, 1180, 1181, 1182, 1183, 1184, 1186, 1187, 1188, 1189, 1194, 1195, 1196, 1199, 1207, 1798
Recommend Resolution
Resolution Detail
<author>, <company>

3. Comments & Recommend Resolution
CID# 420:
Comment: Generic PHY mechanism applies to any kind of PHY, not just MR-FSK. This paragraph ties it to MR-FSK; The paragraph is confusing and not needed. It doesn't actually explain what the generic PHY is, mixes it with mandatory modes which are mandatory only if the MR-FSK PHY is implemented, and "the device may alternatively operate at a different data rate with associated parameter values, provided the alternative mode is compliant with the generic PHY mechanism" doesn't make any sense as "compliant with the generic PHY" is not defined nor verifiable.
Recommend Resolution: Accept in principle
Resolution detail: Change text
“In addition to the modes in Table 1a and Table 1b, the MR-FSK PHY may support a generic PHY mechanism to enable the derivation of a broader set of data rates and parameters; the specifications of the mandatory and optional modes just described are consistent with the generic PHY mechanism. Therefore, while a compliant device shall be capable of operating in the mandatory mode(s), the device may alternatively operate at a different data rate with associated parameter values, provided the alternative mode is compliant with the generic PHY mechanism. For an example of the use of the generic PHY mechanism, see Annex M.” to
“In addition to the modes in Table 1a and Table 1b, the MR-FSK PHY may support a generic PHY mechanism to enable the derivation of a broader set of data rates and parameters. For an example of the use of the generic PHY mechanism, see Annex M.”

4. Comments & Recommend Resolution (Cont’d)
CID# 421:
Comment: "Generic PHY". I can't think of something that is more the antithesis of a standard than this. The whole point of a standard is to limit choices, expand them.
Recommend Resolution: Accept in principle.
Resolution detail:
Insert new subclause 5.2c
5.2c Generic PHY Mechanism
A Generic PHY Mechanism is introduced to describe additional PHY modes.
The Generic PHY provides means to describe:
previously deployed systems in a standardized format such that a standard compliant device can be deployed in an previously deployed system and be compatible with the previously deployed devices.
previously deployed SUN systems in a standardized format to promote implementations from multiple vendors.
future systems that take advantage of technology advances to offer new PHY modes and define these modes in a standardized way without requiring work to amend or create a standard.
Slide 4

5. Comments & Recommend Resolution (Cont’d)
CID# 423:
Comment: The statement, "Therefore while a compliant device shall be capable of operating in the mandatory mode(s)" is vague - does this mean all or any one? For example, must it support OFDM, DSSS, and FSK for all regions or any one?
Recommend Resolution: Accept in principle
Resolution detail: Resolution same as CID# 420
CID# 424:
Comment: The first paragraph of page 15 makes several statements of compliance with the generic PHY mechanism. Since no coding is defined for the generic PHY mechanism no statement about compliance is valid
Slide 5

6. Comments & Recommend Resolution (Cont’d)
CID# 425:
Comment: Get rid of the terms "mandatory" and "optional" throughout the data rate text.
Recommend Resolution: Accept in principle
Resolution detail: Resolution same as CID# 420. The editors will deal with these terms throughout the document.
CID# 426:
Comment: "Therefore, while a compliant device shall be capable of operating in the mandatory mode(s), the device may alternatively operate at a different data rate with associated parameter values, provided the alternative mode is compliant with the generic PHY mechanism." Get rid of the word "mandatory.“
Resolution detail: Resolution same as CID# 420
CID# 427:
Comment: "mandatory mode" and "alternatively operate at a different …" are at odds
Slide 6

7. Comments & Recommend Resolution (Cont’d)
CID# 449:
Comment: The section on Channel numbering for SUN PHYs appears to repeat information unnecessarily. For example, the same PHY Mode definitions occur in multiple frequency bands. The disadvantage of redundant representation is that it readily leads to misinterpretation and potentially to conflicting specification. An example of such conflict is the erroneous use of the phySUNPageEntriesSupported index in the Mode Switch PPDU definition. The use of of such a redundant representation requires further justification over a simpler, non-redundant enumeration of the Frequency Bands, Modulation Schemes and PHY Modes
Recommend Resolution: Accept in principle
Resolution detail: The commenter has good point. phySUNPageEntriesSupported index is not used in the Mode Switch PPDU, instead PHY mode inside channel page structure is used in Mode Switch PPDU. This will be clarified in the updated Mode Switch text.
Slide 7

8. Comments & Recommend Resolution (Cont’d)
CID# 592:
Comment: This subclause is very rough. It is not technically complete as it lacks a means to describe other than FSK PHYs. The concept of using the PIB to define implementation information to the upper layer is mixed up with the concept of controlling active modes and exchanging mode information, neither of which is accomplished via the PIB. As written it is unlikely that different implementers will reach the same understanding, and thus interoperable implementations.
Recommend Resolution: Accept in principle
Resolution detail: A mechanism to exchange PIB information will be proposed by Larry/James.
Slide 8

9. Comments & Recommend Resolution (Cont’d)
CID# 593:
Comment: This subclause should be replaced with a cross reference. There is no useful information in it that is not more fully described in Annex M. In any event, the idea of a "Generic PHY" is silly enough on its own. But the basic idea is that it is proprietary, not standardized and so coming up with a "standardized" method for describing the channels seems a bit silly.
Recommend Resolution: Reject
Resolution detail: Resolution same as comment 592
CID# 594:
Comment: Add text introducing the PIB attributes phyGenericPHYDescriptors and phyNumGenericPHYDescriptors.
Recommend Resolution: Accept in principle
Resolution detail: Replace the first paragraph on page 22 with the following text – For Channel Page 8, the lower 16 bits define valid Generic PHY IDs. The position index of each bit which is set to 1 in bits corresponds to the Generic PHY Id of an element of phyGenericPHYDescriptors. phyNumGenericPHYDescriptors is set to the number of bits set to 1.
Slide 9

10. Comments & Recommend Resolution (Cont’d)
CID# 596:
Comment: What is the point of the lower 16 bits mapping to "available Generic PHY descriptors"? By definition these are not standard and so Ids will not mean the same thing in different implementations. The upper layer must examine all implemented descriptors to know what modes are implemented. This is not useful and very confusing.
Recommend Resolution: Reject
Resolution detail: Resolution same as comment 592
CID# 600: Fig 22m: this is clearly specific to an FSK PHY, and does not accommodate other modulation types.
Recommend Resolution: Accept in principle
Resolution detail: Resolution same as comment 606
CID# 601:
Comment: "data rate" is am ambiguous way to specify a PHY mode characteristic, as there are numerous (infinite?) ways to achieve a given data rate with different symbol rates, symbol to bit mappings, etc.
Resolution detail: Change “Data Rate” to “Symbol Rate”.
Slide 10

11. Comments & Recommend Resolution (Cont’d)
CID# 603:
Comment: The Generic PHY 'mechanism' requires furhter clarification. For example, there is no definition of Generic PHY Channel Descriptor, the Generic PHY Descriptor does not define the 'channels available', nor do the descriptor fields allow the 'channels available' to be determined. In addition, the relationship between the Generic PHY IDs which may be referenced (for example in the Mode Switch PPDU) by multiple devices is not defined.
Recommend Resolution: Accept in principle
Resolution detail: Part of the resolution is the same as comment 592. The editors will correct text inconsistencies.
CID# 610:
Comment: The granularity of the modulation index is not specified - is it 0.1?
Resolution detail: As defined in Table 31a, the “type” of the modulation index is float. Thus, the granularity is implementation specific. No action is needed.
CID# 611:
Comment: Use of BT not clear.
Resolution detail: Resolved by doc.# 0331/r3 (doc is pending for approval by the group).
Slide 11

12. Comments & Recommend Resolution (Cont’d)
CID# 613:
Comment: No explicit statement for what values each of the parameters may take.
Recommend Resolution: Accept in principle
Resolution detail: The value of Generic parameters is implementation specific. Larry/Kuor Hsin will investigate reasonable ranges.
CID# 614:
Comment: "raw over the air bit rate" caused considerable confusion during pre-ballot comment resolution and has become no less ambiguous since. Discussing data rate is inherently ambiguous. The only way to remove ambiguity is describe the modulation parameters explicitly that define data rate such as modulation rate, modulation order, coding rate, etc.
Resolution detail: Replace Line of Page 22 with the following text:
Generic PHY Symbol Rate
The symbol rate is the number of symbols per second transmitted over the air. The data rate can be derived from modulation order and symbol rate. Where the bit to symbol mapping follows SUN PHY convention.
CID# 615:
Comment: The term ”raw over-the-air bit rate” is not a well defined term
Resolution detail: Resolution same as comment 614.
Slide 12

13. Comments & Recommend Resolution (Cont’d)
CID# 616:
Comment: No indication of the units / tolerance of the "Data Rate" field.
Recommend Resolution: Accept in principle
Resolution detail: The description of data rate is in Table 31a. Also, the representation of PIB Attributes is a local device implementation issue. No action is needed.
CID# 617:
Comment: There are no units on the data rate - kbps?
Resolution detail: Resolution same as comment 616.
CID# 618:
Comment: The Parametric PHY Descriptors for FSK are not complete. As it is, Parameteric PHY Descriptors for FSK does not facilitate interoperability between multi-provider implementation.
Resolution detail: The modulation polarity follows MR-FSK PHY convention (see Clause 6.12a.1.2). The tolerance for the key FSK parameters (frequency stability, modulation index , symbol/data rate and time stability) are defined in FSK radio specification. Part of the resolution is the same as comment 613.
Slide 13

14. Comments & Recommend Resolution (Cont’d)
CID# 1101:
Comment: Attribute phyGenericPHYDescriptors should be read only as it describes features of a specific implementation.
Recommend Resolution: Reject
Resolution Detail: Write permission is necessary to permit negotiation of Generic PHY descriptors.
CID# 1121:
Comment: phyNumGenericPHYDescriptors should be read only (describes what is supported by the implementation).
Resolution Detail: Resolution same as comment 1101.
CID# 1123:
Comment: phyNumSUNPageEntries-Supported shoudl be read only, as it describes a specific implementation and is not set by NHL. This is true for all the attributes that describe a particular implementation including phyMaxSUNChannelSupported, phyGenericPHYDescriptors, phyNumGenericPHYDescriptors, etc.
Slide 14

15. Comments & Recommend Resolution (Cont’d)
CID# 1124:
Comment: It would be helpful to say what an "entry" is.
Recommend Resolution: Accept in principle
Resolution detail: Change “The number of SUN page entries supported.” to “The number of SUN channel page entries supported.” The term entry should be well known.
CID# 1132:
Comment: Table 31: phySUNPageEntriesSupported should be read only as it describes the specific features of an implementation and can not be set by a higher layer.
Recommend Resolution: Reject
Resolution Detail: Duplicate as comment 1123.
CID# 1146, 1147, 1148:
Comment: The generic PHY descriptor includes a "modulation scheme" field. When ModulationScheme = 1, OFDM active tones should be defined
Resolution detail: Resolution same as comment 606 (doc. 0609/r1 which was approved on July 15)
Slide 15

16. Comments & Recommend Resolution (Cont’d)
CID# 1173:
Comment: Table 31a applies only to g-compliant devices
Recommend Resolution: Accept in principle
Resolution detail: Since Generic PHY is for SUN device only, no change is needed.
CID# 1174:
Comment: In Table 31a, it is implicitly assumed that the channel BW is identical to Channel Spacing. However, it is not the case where channels are allocated in an overlapping manner, like 950MHz band in Japan.
Recommend Resolution: Reject
Resolution detail: The channel numbering and the occupied bandwidth are not related.
CID# 1179:
Comment: Not sure 1Hz channel spacing is all that useful (would data rate then be specified in bits per fortnight?)
Resolution detail: Resolution same as comment 1175 (doc. 0538/r1)
Slide 16

17. Comments & Recommend Resolution (Cont’d)
CID# 1180:
Comment: channel spacing range of 1,200,000 is excessive, given that the maximum channel bandwitdh is around 400KHz
Recommend Resolution: Accept in principle
Resolution detail: Resolution same as comment 1175 (doc. 0538/r1).
CID# 1181:
Comment: The Generic PHY parameters, including ChannelSpacing, FirstChannelFrequency and DataRate have resolutions that are too fine and are not consistent with the radio specification parameters
CID# 1182:
Comment: Document/Table says in the range column of DataRate : "1–1,000,000" If this mechanism is going to be used to describe generic implementaions it should not be limited to 1Mbps but much more.
Slide 17

18. Comments & Recommend Resolution (Cont’d)
CID# 1183:
Comment: Remove DataRate and replace with Symbol rate.
Recommend Resolution: Accept in principle
Resolution detail: Resolution same as CID# 601
CID# 1184:
Comment: data rate range of 1,000,000 is excessive
Resolution detail: Resolution same as comment 1175 (doc. 0538/r1).
CID# 1186, 1187, 1188:
Comment: A generic PHY is not needed for OFDM
Recommend Resolution: Accept
Resolution detail: Resolution same as comment 606 (doc. 0609/r1 which was approved on July 15).
Slide 18

19. Comments & Recommend Resolution (Cont’d)
CID# 1189:
Comment: Is two bits for modulation scheme representation sufficient - there is only one reserved option for an additional modulation scheme - what about PSK and ASK which are supported by ? BPSK is called out in Table 1.
Recommend Resolution: Reject
Resolution detail: The representation of PIB attributes is a local implementation issue.
CID# 1194:
Comment: The modulation is restricted to 2 or 4 level FSK in the Generic PHY? How is this generic?
Recommend Resolution: Accept in principle.
Resolution detail: Only 2 & 4 level enumeration values are defined - other values could be added as needed.
CID# 1195:
Comment: Name is "FSK Modulation Order"
Recommend Resolution: Accept in principle
Resolution detail: Resolution same as comment 606 (doc. 0609/r1 which was approved on July 15). No change is needed.
Slide 19

20. Comments & Recommend Resolution (Cont’d)
CID# 1196:
Comment: Float is defined as type for "FSK modulation index" - how is this implemented?
Recommend Resolution: Accept in principle
Resolution detail: Representation of PIB attributes is an implementation issue. No action is needed.
CID# 1199:
Comment: Table 31b applies only to g-compliant devices.
Resolution detail: Resolution same as comment 1173.
CID# 1207:
Comment: Since Generic PHY parameters for OFDM and O-QPSK are not defined, in the Range field, mark values 1-3 as reserved for ModulationScheme and delete "NOTE — if specific parameters are not defined for the other modulation schemes, values 1–3 will be left as reserved."
Recommend Resolution: Accept
Resolution detail: Resolution same as comment 1203 (doc. 0609/r1 which was approved on July 15).
Slide 20

21. Comments & Recommend Resolution (Cont’d)
CID# 1798:
Comment: This comment applies to the generic PHY mechanism which is described variously in sections 6.1.1, a, a.2, a.3, , 6.3.3a, 6.4.2, 6.12a.1 and Annex M. The generic PHY mechanism does not seem to fulfill the requirements of a standard at all, and looks more like an API for proprietary modes of operation. Although an optional mode, the generic PHY mechanism does not specify any of the important parameters for an air interface protocol. Rather it serves as a mechanism for defining new protocols within a formal framework. In this way it is not possible for one vendor to read the standard and know for certain what another vendor might implement. The purpose of a standard is to prevent this by defining mandatory modes, which a vendor can rely on being present in all devices, and optional modes, which are fully specified modes which may or may not be present in some devices. A standard is not a framework for defining new modes which are not publicly accessible to all vendors of equipment.
Recommend Resolution: Reject
Resolution detail: The purpose of Generic PHY is explained in the resolution detail of CID# 421.
Slide 21

22. Questions?