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: [September 3, 2010]
Source: [Kuor Hsin Chang1, Bob Mason1, J.L.Taylor2, Cristina Seibert3, Jay Ramasastry3, Hartman Van Wyk4, Roberto Aiello4, John Buffington4, Daniel Popa4]
Company: [Elster Solutions1, DTC (UK)2, Silver Spring Networks3, Itron4]
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, 598, 600, 601, 603, 610, 611, 613, 614, 615, 616, 617, 618, 671, 1101, 1121, 1123, 1124, 1132, 1135, 1173, 1174, 1179, 1180, 1181, 1182, 1183, 1184, 1186, 1187, 1188, 1189, 1194, 1195, 1196, 1197, 1199, 1207, 1208, 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: Part of the resolution is the same as CID# 606 (Generic PHY will only be defined for FSK in the next draft). Also, change text
Resolution detail: Partly resolved by CR 606. Change text as follows:
“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 defined PHY Modes, the MR-FSK PHY may support a Generic PHY mechanism which enables the use of a broader set of data rates and PHY parameters. A SUN device may operate in a PHY mode either defined in this specification or via the Generic PHY. A Generic PHY example is given in 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
The generic PHY mechanism provides means to describe additional PHY modes in a standardized format. For SUN devices capable of supporting the generic PHY mechanism, this enables:
the flexibility to interface with devices that are previously deployed in a standard method.
taking advantage of technology advances or regulatory changes without requiring work to amend or create a new 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
Resolution detail: Resolution same as CID# 420
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 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: Accept in principle
Resolution detail: Resolution same as comment 592
CID# 594:
Comment: Add text introducing the PIB attributes phyGenericPHYDescriptors and phyNumGenericPHYDescriptors.
Resolution: Withdraw by the commenter
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: Accept in principle
Resolution detail: Resolution same as comment 592
CID# 598:
Comment: By defining bits as "reserved" you are specifying that they shall be ignored by a receiving device (that's the defined behavior in P for "reserved"). That doesn't really make sense in this context.
Resolution detail: Change “reserved” to “not used”.
Slide 10

11. Comments & Recommend Resolution (Cont’d)
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 11

12. 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: Add “step size = 0.05” into the range of FSKModulationIndex.
CID# 611, 1197, 1208 are related to the usage of BT and will be resolved by doc.# 0331 once it is approved by the group.
Slide 12

13. 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:
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 13

14. 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: Part of the resolution is the same as comment 613. 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.
Slide 14

15. Comments & Recommend Resolution (Cont’d)
CID# 671:
Comment: Table 4. Assumes somebody assigend a number (0-20) to some "standard options" and some "generic PHY options" but it does not identify who and how.
Recommend Resolution: Accept in principle
Resolution detail: PHY modes for channel page 7 are defined by the standard. PHY modes for Generic PHY are defined by the implementers according to the Generic PHY descriptor structure. No changes needed.
CID# 1101:
Comment: Attribute phyGenericPHYDescriptors should be read only as it describes features of a specific implementation.
Recommend Resolution: Reject
Resolution detail: Since it may be useful to allow these attributes to be writeable, e.g. to facilitate the use of consistent Generic PHY mode indexes among devices.
Slide 15

16. Comments & Recommend Resolution (Cont’d)
CID# 1121:
Comment: phyNumGenericPHYDescriptors should be read only (describes what is supported by the implementation).
Recommend Resolution: Reject
Resolution detail: Resolution same as CID #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.
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.
Slide 16

17. Comments & Recommend Resolution (Cont’d)
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: Resolution same as CID #1101
CID# 1135:
Comment: phySUNPageEntriesSupported must be read only ("supported" describes what the implementation supports).
CID# 1146, 1147, 1148:
Comment: The generic PHY descriptor includes a "modulation scheme" field. When ModulationScheme = 1, OFDM active tones should be defined
Recommend Resolution: Accept in principle
Resolution detail: Resolution same as comment 606 (doc. 0609/r1 which was approved on July 15)
Slide 17

18. 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 BW is a function of data rate and modulation index and is not necessarily derived from the channel spacing.
CID# 1179:
Comment: Not sure 1Hz channel spacing is all that useful (would data rate then be specified in bits per fortnight?)
Resolution detail: 1 Hz of resolution doesn’t prevent an implementer to have a bigger step of resolution. No change is needed.
Slide 18

19. 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: It is beneficial to have the range of channel spacing to be able to support the range of data rate specified in the PAR. Suggest a channel spacing range of up to 4 MHz to match the range of data rate to be up to 1 Mbps in the PAR.
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
Resolution detail: Part of the resolution is the same as CID #1179. Also, the resolution of the parameters do not dictate radio spec tolerances. No change is needed.
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.
Recommend Resolution: Reject
Resolution detail: Resolution same as CID #1184.
Slide 19

20. 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
Recommend Resolution: Reject
Resolution detail: The PAR of g specifies the data rate to be between 40kbps and 1Mbps.
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 20

21. 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: Yes, it is sufficient since Generic PHY is for FSK only.
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 21

22. 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: Resolution same as CID# 610.
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 22

23. 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 23

24. Questions?