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 and Mode Switch]
Date Submitted: [September 15, 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# 592, 593, 596, 603, 611, 613, 918, 924, 1197, 1208
Recommend Resolution
Resolution Detail
<author>, <company>

3. Comments & Recommend Resolution
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 is defined in doc. 316.
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.
Resolution detail: Resolution same as comment 592

4. Comments & Recommend Resolution
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# 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.
Resolution detail: Part of the resolution is the same as comment 592. The editors will correct text inconsistencies.
Slide 4

5. Comments & Recommend Resolution
CID# 611:
Comment: Should state that BT=0 indicates no Gaussian Filtering used and for any other value it defines the Gaussian filter BW.
Recommend Resolution: Accept in principle
Resolution detail: Resolved by the BT definition in doc
CID# 613:
Comment: No explicit statement for what values each of the parameters may take.
Resolution detail: The value of Generic parameters is implementation specific.
Slide 5

6. Comments & Recommend Resolution
CID# 918:
Comment: There are a variety or problems with this field. First, there is no description of its use in the MAC section. What happens if the mode switch packet packet is lost but the following packet isn't? Is the mode switch only for the packet that follows immediately or may more than one mode switched packet be sent? No where is it specified that the mode switch packet is not ACKed. How are the phyModeSwitchParameterEntries array communicated between devices? The PIB is a local storage and is not the same on both devices. While channel page 7 fields for Modulation and Mode are defined and therefore are known at both devices, for channel page 8, none of the parameters are defined. How is support of mode switching and the supported modes and data rates communicated among devices?
Recommend Resolution: Accept in principle
Resolution Detail: If a mode switch packet is lost, this is no different from a packet lose in the normal packet transmission. The mode switching takes place only for the packet that follows immediately after the mode switch packet and no ACK is needed for the mode switch packet. These are addressed in the proposed text change in doc How the phyModeSwitchParameterEntries array is communicated between two devices is resolved by comment 592.
Slide 6

7. Comments & Recommend Resolution
CID# 924:
Comment: The Mode Switch Parameter Entry sub-field is carried over the air but the description does not identify whether the sub-field indexes the local (transmitter) array or the remote (receiver) array. In either case no reference is given to how the content of each (transmitter & receiver) array is exchanged to make the sub-field meaningful in any given device pair.
Recommend Resolution: Accept in principle
Resolution Detail: How the phyModeSwitchParameterEntries array is communicated between two devices is resolved by comment 592.
CID# 1197:
Comment: Correct it. Use 0 (zero) to mean FSK w/no Filter and any other number to mean Gaussian Filtered with that BT product.
Resolution detail: Resolved by the BT definition in doc
CID# 1208:
Comment: Change "Type" from Enumeration" to "Float" Specify "Range" to be " “. Change "Description" to be "The bandwidth time product (BT) for GFSK"
Slide 7

8. Questions?