doc.: IEEE 802.15-<doc#> <month year> doc.: IEEE 802.15-<doc#> Project: IEEE P802.15 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: [] E-Mail:[kuor-hsin.chang@us.elster.com, robert.t.mason@us.elster.com, larry.taylor@discretetime.com, cseibert@silverspringnet.com, jramasas@silverspringnet.com, Hartman.VanWyk@itron.com, Roberto.Aiello@itron.com, John.Buffington@itron.com, Daniel.Popa@itron.com] Re: [Comment Resolution for TG4g draft] Abstract: The presentation provides resolution for some Generic PHY related comments Purpose: Presented to the 802.15.4g SUN Task Group for consideration and discussion 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 contributor acknowledges and accepts that this contribution becomes the property of IEEE and may be made publicly available by P802.15. <author>, <company>

doc.: IEEE 802.15-<doc .....> <May,2009> doc.: IEEE 802.15-<doc .....> Outline Comments to be resolved: CID# 592, 593, 596, 603, 611, 613, 918, 924, 1197, 1208 Recommend Resolution Resolution Detail <author>, <company>

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

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

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 15-10-0331-07. 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

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 15-10-0733-00. How the phyModeSwitchParameterEntries array is communicated between two devices is resolved by comment 592. Slide 6

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 15-10-0331-07. CID# 1208: Comment: Change "Type" from Enumeration" to "Float" Specify "Range" to be "0.3-1.0“. Change "Description" to be "The bandwidth time product (BT) for GFSK" Slide 7

Questions?