Sept 2010 Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: Proposed MAC Comment Resolutions Date Submitted:

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, S6-403, S6-404, S6-405, S6-406, S6-407, S6-471, 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, S , S7-267, S7-61, S7-529. 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

David M. Davenport GE Global Research
Sept 2010 Proposed Resolution of D0 Comments S6-367, S6-400, S6-403, S6-404, S6-405, S6-406, S6-407, S6-471, 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, S7-529 David M. Davenport GE Global Research D.Davenport, GE Global Research

Changes in Version 01 of this Document
<month year> doc.: IEEE <doc#> Sept 2010 Changes in Version 01 of this Document Changed proposed resolution for S6-400 based upon feedback from the commenter Included resolution of comment S7-529 based upon feedback from commenter Included feedback from commenter for S7-399 supporting recommendation Included new proposed resolution for S6-403, S6-404, S6-405, S6-406 and S6-471 D.Davenport, GE Global Research <author>, <company>

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>

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>

doc.: IEEE 802.15-<doc#>
<month year> doc.: IEEE <doc#> Sept 2010 D0 Comment S6-400 Comment: [a] 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? [b] Similarly the Group Connection IE in a Request is not covered by the Connection Change Indicator. [c] 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>

doc.: IEEE 802.15-<doc#>
<month year> doc.: IEEE <doc#> Sept 2010 Discussion This comment consists of three parts: 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? Commenter is correct with this observation. Connection Change Indicator represents a superset Similarly the Group Connection IE in a Request is not covered by the Connection Change Indicator. Commenter is correct with this observation Connection Change Indicator should include this Group Connection IE to accurately reflect the superset of IE’s in both messages Also there are >8 optional IE's in an Assignment frame. Commenter is incorrect with this observation There are exactly 8 optional IE’s in Connection Assignment Frame Payload (Fig 25) There are 7 optional IE’s in the Node Connection Assignment IE which contains its own Connection Change Indictor. This Node Connection Assignment IE (Fig 49) is optionally contained in the Multinode Connection Assignment frame. D.Davenport, GE Global Research <author>, <company>

doc.: IEEE 802.15-<doc#>
<month year> doc.: IEEE <doc#> Sept 2010 Proposed Resolution Accept comment S6-400 in principle. Connection Change Indicator (CCI) should serve as a bitmap flag affording rapid assessment as to the presence and changes in the optional IE’s found in a Connection Request or Connection Assignment message Remove Wakeup Phase and Wakeup Period from CCI as these fields are always present in Connection Request and Assignment frames Add Slotted Superframe IE to CCI Add Group Connect IE to CCI Add Channel Hopping IE to CCI Add clarifying text to the CCI definition such that bits are set to zero when IE’s are not present in the message (thus, ignored). D.Davenport, GE Global Research <author>, <company>

doc.: IEEE 802.15-<doc#>
<month year> doc.: IEEE <doc#> Sept 2010 D0 Comment S6-403 Comment: Clarify whether or not block transfers can span more than 1 superframe when the block does not fit the allocation interval? (page 50, subclause 6.4.2) Proposed Change: <none> Must be Satisfied: No D.Davenport, GE Global Research <author>, <company>

doc.: IEEE 802.15-<doc#>
<month year> doc.: IEEE <doc#> Sept 2010 Proposed Resolution Accept comment S6-403 in principle Comment seeks clarification Transmissions from node or hub must respect allocation interval boundaries. Figure 55 shows that B-ACK can apply to frames sent in preceding allocation interval (that indicated L-ACK policy). No explicit text in draft addressing continuation across superframe boundaries. Add clarifying text in B-ACK section indicating that block transfers cannot span a superframe when beacon mode is enabled. Hubs supporting beacon mode superframe operation will have numerous management tasks such that avoiding B-ACK carry-over is a beneficial simplification. D.Davenport, GE Global Research <author>, <company>

doc.: IEEE 802.15-<doc#>
<month year> doc.: IEEE <doc#> Sept 2010 D0 Comment S6-404 Comment: Text refers to it holding received signal strength – suggest the name should be changed as it suggests LQI as per of (and would that be more appropriate to use here?). Also, would it better to send a rolling average of the signal strength to a prospective node rather than an instantaneous value as implied here? (page 52, subclause ) Proposed Change: Change name Relay Link Quality to Relay Signal Strength Must be Satisfied: No D.Davenport, GE Global Research <author>, <company>

doc.: IEEE 802.15-<doc#>
<month year> doc.: IEEE <doc#> Sept 2010 Proposed Resolution Accept comment S6-404 Relayed node benefits from knowledge of the Relaying node to hub link signal strength See proposed in DCN Information being provided by field defined in T-Poll payload is signal strength. Change name Relay Link Quality to Relay Signal Strength in text and figures of subclause 6.4.6 Add text referencing Relay Signal Strength in proposed from DCN Two-Hop Star Extension D.Davenport, GE Global Research <author>, <company>

doc.: IEEE 802.15-<doc#>
<month year> doc.: IEEE <doc#> Sept 2010 D0 Comment S6-405 Comment: B2 is a legacy name from an earlier proposal where there was a B1. (page 52, subclause 6.4.8). Proposed Change: Rename B2 frame to indicate its purpose e.g. Contention Beacon Must be satisfied: No Proposed Resolution: Reject comment S “B2” name is appropriate and helpful in conveying the beacon like nature of this frame. D.Davenport, GE Global Research <author>, <company>

doc.: IEEE 802.15-<doc#>
<month year> doc.: IEEE <doc#> Sept 2010 D0 Comment S6-406 Comment: Piconet priority unclear as piconet is defined in the document's definitions or in earlier sections. Also, the function of piconet priority is not stated, i.e. its use in deciding allocations in the CAP when multiple BAN's (piconets) exist. Similarly piconet interaction support is not referenced or defined elsewhere (page 54, subclause ) Proposed Change: Piconet needs to be defined – from later it can be seen to refer to a particular BAN (nodes connected to a hub) in the case of co-existing BAN's/hubs. D.Davenport, GE Global Research <author>, <company>

doc.: IEEE 802.15-<doc#>
<month year> doc.: IEEE <doc#> Sept 2010 Proposed Resolution Accept comment S6-406 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>

doc.: IEEE 802.15-<doc#>
<month year> doc.: IEEE <doc#> Sept 2010 D0 Comment S6-407 Comment: Current MAC Capability field is limited and cannot provide for future commands (except in rsvd bits) as it is only 2 octets. (page 55, subclause 6.6.1) Proposed Change: Rather than include the specific Battery Level Indication command, MAC Capability should not include commands at all or it should list all the supported Command ID's. It would be preferable to use a new Commands Capability IE for this in specified frames such as Connection Request/Assignment and remove the commands supported from the 2 octet MAC Capability Must be satisfied: No D.Davenport, GE Global Research <author>, <company>

doc.: IEEE 802.15-<doc#>
<month year> doc.: IEEE <doc#> Sept 2010 Proposed Resolution Reject comment S6-407 MAC capability field provides for future expansion with 2 reserved bits. Additional future expansion capability could be implemented in various ways, including that proposed by the commenter, using IE for reflecting Commands supported by MAC in the Connection Request/Assignment frames D.Davenport, GE Global Research <author>, <company>

doc.: IEEE 802.15-<doc#>
<month year> doc.: IEEE <doc#> Sept 2010 D0 Comment S6-471 Comment: Inconsistency in fields from NID onwards in fig 25 and in fig 49 for Multinode Connection Assignment (page 42, subclause , Figure 25). Via , commenter added “slotted superframe IE is in fig 25. But not in figure 49”. Proposed Change: Add a separate diagram for the connection related information elements for use in single Node and multinode Connection IE's in fig 25 and 49 in order to ensure their fields remain consistent Proposed Resolution: Accept Comment S6-471 in Principle. Add Slotted Superframe IE to figure 49. Refer to updated version of figure 49 found in DCN D.Davenport, GE Global Research <author>, <company>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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 from D. Tracey of 06Sep10: “text in 0666 used to propose rejecting this would be useful to include in the draft” D.Davenport, GE Global Research <author>, <company>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

doc.: IEEE 802.15-<doc#>
<month year> doc.: IEEE <doc#> Sept 2010 D0 Comment S7-529 Comment: pCSMASlotLength = pCCATime + 20 us must be double checked by CSEM (page 118, subclause 7X table). Proposed Change: <none> Must be satisfied: Yes Proposed Resolution: Reject comment S7-529 based upon from M. Hernandez received via 29Jul10 stating “please reject it… Equation is ok”. D.Davenport, GE Global Research <author>, <company>

Sept 2010 Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: Proposed MAC Comment Resolutions Date Submitted:

Similar presentations

Presentation on theme: "Sept 2010 Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: Proposed MAC Comment Resolutions Date Submitted:"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Sept 2010 Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: Proposed MAC Comment Resolutions Date Submitted:

Similar presentations

Presentation on theme: "Sept 2010 Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: Proposed MAC Comment Resolutions Date Submitted:"— Presentation transcript:

Similar presentations

About project

Feedback