1. Sept 2010
Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs)
Submission Title: Proposed MAC Comment Resolutions
Date Submitted: September 6, 2010
Source: David M. Davenport, Company: GE Global Research
Address: 1 Research Circle, Niskayuna, NY USA, Voice: ,
Re: Proposed Resolution of D0 Comments for MAC Subclauses 6 and 7
Abstract: Proposed resolution for comments: S6-367, S6-400, S7-461, S7-462, S7-260, S7-250, S7-248, S7-76, S7-81, S7-77, S7-417, S7-440, S7-75, S7-70, S7-71, S7-64, S7-257, S7-255, S7-258, S7-259, S , S7-86, S7-249, S7-436, S7-451, S7-253, S7-264, S7-262, S7-267, S7-61.
Purpose: This document is for the MAC comment resolution discussion for TG6 draft D01.
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
D.Davenport, GE Global Research

2. David M. Davenport GE Global Research
Sept 2010
Proposed Resolution of D0 Comments S6-367, S6-400, S7-461, S7-462, S7-260, S7-250, S7-248, S7-76, S7-81, S7-77, S7-417, S7-440, S7-75, S7-70, S7-71, S7-64, S7-257, S7-255, S7-258, S7-259, S7-399, S7-86, S7-249, S7-436, S7-451, S7-253, S7-264, S7-262, S7-267, S7-61.
David M. Davenport
GE Global Research
D.Davenport, GE Global Research

3. doc.: IEEE 802.15-<doc#>
<month year>
doc.: IEEE <doc#>
Sept 2010
D0 Comment S6-367
Comment: Would the interval be more precisely stated as [0, 2^128). That is, a semi closed interval. (page 36, subclause , line 18)
Proposed Change: Change to [0, 2^128). Same on page 37 line 29.
D.Davenport, GE Global Research
<author>, <company>

4. doc.: IEEE 802.15-<doc#>
<month year>
doc.: IEEE <doc#>
Sept 2010
Proposed Resolution
Reject comment S Text is written as intended with the open interval (0, 2^128)
The zero value could lead to a degenerate result and is intentionally excluded.
Value 2^128 is not to be included as another octet would be required for implementation of the field with insignificant benefit.
D.Davenport, GE Global Research
<author>, <company>

5. doc.: IEEE 802.15-<doc#>
<month year>
doc.: IEEE <doc#>
Sept 2010
D0 Comment S6-400
Comment: Channel Order IE is shown in the Connection Change Indicator, but Channel Order IE is shown only in a Connection Assignment and not in the Connection Request? Similarly the Group Connection IE in a Request is not covered by the Connection Change Indicator. Also there are >8 optional IE's in an Assignment frame. (page 40, subclause , Figure 24).
Proposed Change:The use of Connection Change Indicator to refer to IE's in the Connection Request and Assignment frames needs to be made consistent
D.Davenport, GE Global Research
<author>, <company>

6. Alternative Resolutions
<month year>
doc.: IEEE <doc#>
Sept 2010
Alternative Resolutions
The commenter is correct that Channel Order IE are (optionally) present in Connection Assignment frames and not in Connection Request frames.
Channel Order IE is not necessary for Connection Request frames, sent from a node.
Channel Order IE is sent from hub to node via Connection Assignment frame transfer
The Connection Change Indicator field was created for use with both Connection Request and Connection Assignment frames for simplicity.
A node may seek to change its connection characteristics
A hub may seek to change a node’s connection assignment
Alternatives include:
Adding clarifying text to the Connection Request frame description that the bit for Channel Order IE is to be ignored;
Change the name of the field and create specific fields, unique to the Connection Request and Connection Assignment frames
D.Davenport, GE Global Research
<author>, <company>

7. doc.: IEEE 802.15-<doc#>
<month year>
doc.: IEEE <doc#>
Sept 2010
Proposed Resolution
Accept comment S6-400 in principle.
Adding clarifying text to the Connection Request frame description that the bit for Channel Order IE is to be ignored when processing a Connection Request frame.
The Connection Request will not contain a Channel Order IE, so it cannot be changed and, therefore, will not be indicated as changed in the Connection Change Indicator
D.Davenport, GE Global Research
<author>, <company>

8. doc.: IEEE 802.15-<doc#>
<month year>
doc.: IEEE <doc#>
Sept 2010
D0 Comment S7-461
Comment: "10-50 MHz HBC/EFC[a]" is undefined at this time, so you cannot put it in the table. (page 108, subclause 7.12, line 1)
Proposed Change: Delete the column for "10-50 MHz HBC/EFC[a]"
D.Davenport, GE Global Research
<author>, <company>

9. doc.: IEEE 802.15-<doc#>
<month year>
doc.: IEEE <doc#>
Sept 2010
Proposed Resolution
Accept comment S7-461 in principle
The HBC/EFC physical layer is defined in subclause 11.
The second row of table 21 refers to specific coexistence mechanisms found in regulatory rules.
Retain 10-50MHz HBC/EFC column.
Change second row to read “None if low power, non spread spectrum power levels”
D.Davenport, GE Global Research
<author>, <company>

10. doc.: IEEE 802.15-<doc#>
<month year>
doc.: IEEE <doc#>
Sept 2010
D0 Comment S7-462
Comment: "2.36 GHz MBANS Band" is pending, hence it must be deleted. (page 108, subclause 7.12, line 1)
Proposed Change: Delete the column for "2.36 GHz MBANS Band“
Proposed Resolution: Accept comment S7-462
D.Davenport, GE Global Research
<author>, <company>

11. doc.: IEEE 802.15-<doc#>
<month year>
doc.: IEEE <doc#>
Sept 2010
D0 Comment S7-260
Comment: "shall" should be a "may" as operation in Time Sharing Mode is an optional functionality (page 112, subclause , line 39)
Proposed Change: Change "shall" to "may“
Proposed Resolution: Accept comment S7-260
Subclause 7.4 BAN creation and connection setup includes the basic, prerequisite “A hub shall choose an operating channel to start a body area network (BAN), taking into account policy regulations, channel conditions, application requirements, coexistence considerations, etc…
D.Davenport, GE Global Research
<author>, <company>

12. doc.: IEEE 802.15-<doc#>
<month year>
doc.: IEEE <doc#>
Sept 2010
D0 Comment S7-250
Comment: A node must not be able to join a BAN by connecting through a relay. This would introduce risks with respect to security and lead to condition where relay is used by the new nodes as the nominal route to hub, rather than the exception. (page 99, subclause 7.9.2, line 13)
Proposed Change: Clarify this subclause to ensure that connection to a BAN cannot occur via a Relay Node
D.Davenport, GE Global Research
<author>, <company>

13. doc.: IEEE 802.15-<doc#>
<month year>
doc.: IEEE <doc#>
Sept 2010
Proposed Resolution
Accept comment S7-250 in principle
Clarify this subclause to ensure that connection to a BAN cannot occur via a Relay Node
Consider proposed resolution by Hind Munzer-Chebbo submitted as DCN
D.Davenport, GE Global Research
<author>, <company>

14. doc.: IEEE 802.15-<doc#>
<month year>
doc.: IEEE <doc#>
Sept 2010
D0 Comment S7-248
Comment: A sensor node seeking to establish RTT functionality sends a connection request to a relay node. However, there is no defined mechanism for the potential relay node to monitor and look for such messages. In addition, this description does not afford the sensor node information as to whether the node it overhears and considers an RN candidate actually supports RTT capability. The result is inefficient spectrum usage as messages are exchanged without the possibility of success. (page 98, subclause 7.9.1, line 24)
Proposed Change: This subclause should be deleted and the second option for relay discovery (7.9.2) retained. The hub needs to be in control of this functionality and provide confirmation to a node upon its connection (or subsequent connection update messages) that an RN exists in its BAN.
D.Davenport, GE Global Research
<author>, <company>

15. doc.: IEEE 802.15-<doc#>
<month year>
doc.: IEEE <doc#>
Sept 2010
Proposed Resolution
Accept comment S7-248 in principle
Consider proposed resolution by Hind Munzer-Chebbo submitted as DCN
D.Davenport, GE Global Research
<author>, <company>

16. doc.: IEEE 802.15-<doc#>
<month year>
doc.: IEEE <doc#>
Sept 2010
D0 Comment S7-76
Comment: Change below to in the following sub clauses (page 72, subclause 7.2.7, line 14)
Proposed Change: Change below to in the following sub clauses
Proposed Resolution: Accept comment S7-76
D.Davenport, GE Global Research
<author>, <company>

17. doc.: IEEE 802.15-<doc#>
<month year>
doc.: IEEE <doc#>
Sept 2010
D0 Comment S7-81
Comment: Delete "as described below“ (page 94, subclause , line 25)
Proposed Change: Delete "as described below“
Proposed Resolution: Accept comment S7-81
D.Davenport, GE Global Research
<author>, <company>

18. doc.: IEEE 802.15-<doc#>
<month year>
doc.: IEEE <doc#>
Sept 2010
D0 Comment S7-77
Comment: Delete "as described below" and insert a comma (page 76, subclause 7.3.1, line 29)
Proposed Change: Resulting in "… access phase, but not both.“
Proposed Resolution: Accept comment S7-77
D.Davenport, GE Global Research
<author>, <company>

19. doc.: IEEE 802.15-<doc#>
<month year>
doc.: IEEE <doc#>
Sept 2010
D0 Comment S7-417
Comment: Delete "described below“ (page 92, subclause 7.8, line 32)
Proposed Change: Delete "described below“
Proposed Resolution: Accept comment S7-417
D.Davenport, GE Global Research
<author>, <company>

20. doc.: IEEE 802.15-<doc#>
<month year>
doc.: IEEE <doc#>
Sept 2010
D0 Comment S7-440
Comment: Description of unconnected node should include possibility of a node seeks to use only RAP/CAP contention based access but has yet to exchange connection request and assignment frames with the hub. (page 78, subclause 7.4, line 27)
Proposed Change: Expand the definition of unconnected nodes in this paragraph to account for nodes which may connect and use only contention based access.
D.Davenport, GE Global Research
<author>, <company>

21. doc.: IEEE 802.15-<doc#>
<month year>
doc.: IEEE <doc#>
Sept 2010
Proposed Resolution
Reject comment S7-440
The definition requested by the comment can be found on page 79, line
D.Davenport, GE Global Research
<author>, <company>

22. doc.: IEEE 802.15-<doc#>
<month year>
doc.: IEEE <doc#>
Sept 2010
D0 Comment S7-75
Comment: Entire and subclauses and : What is a coordinator? There is no such term in this document (page 111, subclause , line 16)
Proposed Change: Replace coordinator with hub
Proposed Resolution: Accept comment S7-75
D.Davenport, GE Global Research
<author>, <company>

23. doc.: IEEE 802.15-<doc#>
<month year>
doc.: IEEE <doc#>
Sept 2010
D0 Comment S7-70
Comment: Figure 75 Terms coordinator and device need to be replaced by hub and node (four occurrences), (page 95, subclause , line 18)
Proposed Change: Terms coordinator and device need to be replaced by hub and node
Proposed Resolution: Accept comment S7-70
Changes to be made in Figure 75 content as well as caption
D.Davenport, GE Global Research
<author>, <company>

24. doc.: IEEE 802.15-<doc#>
<month year>
doc.: IEEE <doc#>
Sept 2010
D0 Comment S7-71
Comment: Figure 77 Terms coordinator and device need to be replaced by hub and node (four occurrences), (page 97, subclause , line 3)
Proposed Change: Terms coordinator and device need to be replaced by hub and node
Proposed Resolution: Accept comment S7-71
D.Davenport, GE Global Research
<author>, <company>

25. doc.: IEEE 802.15-<doc#>
<month year>
doc.: IEEE <doc#>
Sept 2010
D0 Comment S7-64
Comment: If mG-AckDataSubtype is a valid subtype, then add it to table 3 (page 73, subclause , line 8)
Proposed Change: Fix inconsistency
D.Davenport, GE Global Research
<author>, <company>

26. doc.: IEEE 802.15-<doc#>
<month year>
doc.: IEEE <doc#>
Sept 2010
Proposed Resolution
Accept comment S7-64 in principle
Despite mG-AckDataSubtype being defined in subclauses and , frame subtype mG-AckDataSubtype is not included in Table 3
Add new row to Table 3, using one of the reserved subtype values for Data frame types
D.Davenport, GE Global Research
<author>, <company>

27. doc.: IEEE 802.15-<doc#>
<month year>
doc.: IEEE <doc#>
Sept 2010
D0 Comments S7-255, S7-257, S7-258, S7-259
Comment: MAC sublayer parameters mEDScanDuration, mActiveScanDuration, mNetworkActivityDuration and mPassiveScanDuration shown in text are not defined or present in Table 23. (page 112, subclause 7.2.3)
Proposed Change: Define mEDScanDuration, mActiveScanDuration, mNetworkActivityDuration and mPassiveScanDuration as a MAC sublayer parameter in Table 23
D.Davenport, GE Global Research
<author>, <company>

28. Alternative Resolutions
<month year>
doc.: IEEE <doc#>
Sept 2010
Alternative Resolutions
Define these parameters as higher layer parameters and define a new table (proposed resolution of )
Define these parameters as MAC sublayer parameters in Table 23
D.Davenport, GE Global Research
<author>, <company>

29. doc.: IEEE 802.15-<doc#>
<month year>
doc.: IEEE <doc#>
Sept 2010
Proposed Resolution
Accept comments S7-255, S7-257, S7-258, and S7-259.
These parameters directly impact operation of the MAC and should be defined in Table 23
D.Davenport, GE Global Research
<author>, <company>

30. doc.: IEEE 802.15-<doc#>
<month year>
doc.: IEEE <doc#>
Sept 2010
D0 Comment S7-399
Comment: mGT_nominal is defined as Allocation Slot Length/10. What is the basis used for setting the denominator to 10? (page 116, subclause )
Proposed Change: <none>
Must be satisfied: “No”
D.Davenport, GE Global Research
<author>, <company>

31. doc.: IEEE 802.15-<doc#>
<month year>
doc.: IEEE <doc#>
Sept 2010
Discussion
Need subscript, GT0
D0 page 104
mTxResolution in Table 23 but pSIFS and pSynchResolution are in PHY-dependent MAC sublayer parameter tables
D.Davenport, GE Global Research
<author>, <company>

32. doc.: IEEE 802.15-<doc#>
<month year>
doc.: IEEE <doc#>
Sept 2010
Proposed Resolution
Reject comment S7-399
Comment asks for clarification without proposing a change
mGT_Nominal is defined as a fraction of the Allocation Slot Length to enable necessary guard time.
Value of 10 selected as trade-off considering power consumption, spectrum efficiency and complexity
Value > 10 would result in longer guard times spent idle, reducing spectrum efficiency and increasing time spent in receive mode
Value < 10 would require finer timing resolution
D.Davenport, GE Global Research
<author>, <company>

33. doc.: IEEE 802.15-<doc#>
<month year>
doc.: IEEE <doc#>
Sept 2010
D0 Comment S7-86
Comment: Piconet is discussed in general terms wrt a BAN. but not defined. Pioconet should be defined early on in the draft as part of the Network Topology (page 113, subclause , line 113)
Proposed Change: Provide a description of a Piconet in the Clause 3.0 Definitions. Add text and illustration to support how Piconets are part of the BAN Network Topology, in Clause 5.2 Network topology page 13.
D.Davenport, GE Global Research
<author>, <company>

34. doc.: IEEE 802.15-<doc#>
<month year>
doc.: IEEE <doc#>
Sept 2010
Proposed Resolution
Accept comment S7-86 in principle
Body Area Network is the term used by the draft standard to refer to a logical set of organized nodes and hubs
The draft standard does not use Piconet as part of its nomenclature for Body Area Network topology (See subclause 5.2)
Replace “piconet” with “body area network” or “BAN” throughout the entire document including subclause as identified by this comment
D.Davenport, GE Global Research
<author>, <company>

35. doc.: IEEE 802.15-<doc#>
<month year>
doc.: IEEE <doc#>
Sept 2010
D0 Comment S7-249
Comment: Reference is made to the reception of an "emergency data frame". Is this a specific frame type? If so, it has not been defined. Is this a data frame with user priority set to medical emergency as in Table 17? (page 100, subclause 7.9.2, line 21)
Proposed Change: Clarify the definition of emergency frame as used in this context.
D.Davenport, GE Global Research
<author>, <company>

36. doc.: IEEE 802.15-<doc#>
<month year>
doc.: IEEE <doc#>
Sept 2010
Proposed Resolution
Accept comment S7-249 in principle
Ambiguous reference to emergency frame can be resolved by changing text to reflect “data frame type with emergency subtype”
This definition is consistent with Table 3
D.Davenport, GE Global Research
<author>, <company>

37. doc.: IEEE 802.15-<doc#>
<month year>
doc.: IEEE <doc#>
Sept 2010
D0 Comment S7-436
Comment: Table 21 includes the phrase "Limited / No applicability given LBT restrictions" for "Beacon Shifting" and MICS band communication. (page 108, subclause 7.12, line 1)
Proposed Change: Change to "No applicability given LBT restrictions“
D.Davenport, GE Global Research
<author>, <company>

38. doc.: IEEE 802.15-<doc#>
<month year>
doc.: IEEE <doc#>
Sept 2010
Proposed Resolution
Accept comment S7-436 in principle
Change to “Not applicable given LBT restrictions”
Proposed resolution incorporated in co-pending resolution proposal DCN
D.Davenport, GE Global Research
<author>, <company>

39. doc.: IEEE 802.15-<doc#>
<month year>
doc.: IEEE <doc#>
Sept 2010
D0 Comment S7-451
Comment: Table 21 shows channel hopping as applicable to UWB band PHY. Channel Hopping applicable to NB PHY only. (page 108, subclause 7.12, line 1)
Proposed Change: Change cells for UWB Band such that Channel Hopping is shown as "not applicable"
D.Davenport, GE Global Research
<author>, <company>

40. doc.: IEEE 802.15-<doc#>
<month year>
doc.: IEEE <doc#>
Sept 2010
Proposed Resolution
Accept comment S7-451
Proposed resolution incorporated in co-pending resolution proposal DCN
D.Davenport, GE Global Research
<author>, <company>

41. doc.: IEEE 802.15-<doc#>
<month year>
doc.: IEEE <doc#>
Sept 2010
D0 Comment S7-253
Comment: Text cites Table 24 for Nch = pChannelsTotal. This value is defined only for NB PHY table. Text here should state that channel hopping for NB physical layer only. (page 110, subclause , line 19)
Proposed Change: Add sentence to beginning of subclause stating the applicability of channel hopping to narrowband physical layer only.
Proposed Resolution: Accept comment S7-253
D.Davenport, GE Global Research
<author>, <company>

42. doc.: IEEE 802.15-<doc#>
<month year>
doc.: IEEE <doc#>
Sept 2010
D0 Comment S7-264
Comment: The first paragraph is overly complex and the optional nature of the load control mechanism clearly conveyed by rewriting the sentence. (page 114, subclause , line 4)
Proposed Change: Replace this sentence with: "A hub may use load control for short-term coexistence along with any other coexistence mechanism.“
Proposed Resolution: Accept Comment S7-264
D.Davenport, GE Global Research
<author>, <company>

43. doc.: IEEE 802.15-<doc#>
<month year>
doc.: IEEE <doc#>
Sept 2010
D0 Comment S7-262
Comment: The time sharing and load reduction mechanisms for coexistence are optional rather than mandatory. The text should explicitly state this fact. (page 111, subclause 7.2.3, line 16)
Proposed Change: Include the sentence: "The time sharing and load reduction coexistence mechanisms defined in this subclause are optional for a MAC implementation.“
Proposed Resolution: Accept Comment S7-262
D.Davenport, GE Global Research
<author>, <company>

44. doc.: IEEE 802.15-<doc#>
<month year>
doc.: IEEE <doc#>
Sept 2010
D0 Comment S7-267
Comment: There is no table of PHY-dependent MAC sublayer parameters pertainint to HBC/EFC physical layer. (page 117, subclause , line 1)
Proposed Change: Define necessary PHY-dependent MAC sublayer parameters for HBC/EFC physical layer and insert as new table to enable the MAC to work with this physical layer.
Proposed Resolution: Defer to HBC/EFC physical layer team
D.Davenport, GE Global Research
<author>, <company>

45. doc.: IEEE 802.15-<doc#>
<month year>
doc.: IEEE <doc#>
Sept 2010
D0 Comment S7-61
Comment: What does Table 17 have to do with the Frame Acknowledgement? (page 72, subclause 7.2.7, line 11)
Proposed Change: Delete cross reference to Table 17
Proposed Resolution: Accept comment S7-61
D.Davenport, GE Global Research
<author>, <company>