1 / 57

Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)

Project: IEEE P802.15 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

cade
Download Presentation

Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Project: IEEE P802.15 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: +1 518-387-5041, E-Mail:davenport@ge.com 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, S7-262, 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 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. D.Davenport, GE Global Research

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

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

  4. 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 6.3.3.2.1, line 18) • ProposedChange: Change to [0, 2^128). Same on page 37 line 29. D.Davenport, GE Global Research

  5. Proposed Resolution • Reject comment S6-367. 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

  6. 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 6.3.6.6, Figure 24). • ProposedChange: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

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

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

  9. 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) • ProposedChange: <none> • Must be Satisfied: No D.Davenport, GE Global Research

  10. 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 7.2.7.4 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

  11. 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 6.9.8 of 802.15.4 (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 6.4.6.4) • ProposedChange: Change name Relay Link Quality to Relay Signal Strength • Must be Satisfied: No D.Davenport, GE Global Research

  12. Proposed Resolution • Accept comment S6-404 • Relayed node benefits from knowledge of the Relaying node to hub link signal strength • See proposed 7.9.2 in DCN 15-10-0544-02-0006 • 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 7.9.2 from DCN 15-10-0544-02-0006 Two-Hop Star Extension D.Davenport, GE Global Research

  13. 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). • ProposedChange: Rename B2 frame to indicate its purpose e.g. Contention Beacon • Must be satisfied: No • Proposed Resolution: Reject comment S6-405. “B2” name is appropriate and helpful in conveying the beacon like nature of this frame. D.Davenport, GE Global Research

  14. 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 6.4.8.6) • ProposedChange: Piconet needs to be defined – from later 7.12.3 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

  15. 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 6.4.8.6 as identified by this comment D.Davenport, GE Global Research

  16. 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) • ProposedChange: 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

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

  18. 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 6.3.7.0, Figure 25). • Via email, commenter added “slotted superframe IE is in fig 25. But not in figure 49”. • ProposedChange: 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 15-10-0677-00-0006. D.Davenport, GE Global Research

  19. 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) • ProposedChange: Delete the column for "10-50 MHz HBC/EFC[a]" D.Davenport, GE Global Research

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

  21. D0 Comment S7-462 • Comment: "2.36 GHz MBANS Band" is pending, hence it must be deleted. (page 108, subclause 7.12, line 1) • ProposedChange: Delete the column for "2.36 GHz MBANS Band“ • Proposed Resolution: Accept comment S7-462 D.Davenport, GE Global Research

  22. D0 Comment S7-260 • Comment: "shall" should be a "may" as operation in Time Sharing Mode is an optional functionality (page 112, subclause7.2.3.1, line 39) • ProposedChange: Change "shall" to "may“ • ProposedResolution: 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

  23. 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) • ProposedChange: Clarify this subclause to ensure that connection to a BAN cannot occur via a Relay Node D.Davenport, GE Global Research

  24. 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 15-10-0544-02-0006. D.Davenport, GE Global Research

  25. 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) • ProposedChange: 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

  26. Proposed Resolution • Accept comment S7-248 in principle • Consider proposed resolution by Hind Munzer-Chebbo submitted as DCN 15-10-0544-02-0006. D.Davenport, GE Global Research

  27. D0 Comment S7-76 • Comment: Change below to in the following sub clauses (page 72, subclause 7.2.7, line 14) • ProposedChange: Change below to in the following sub clauses • Proposed Resolution:Accept comment S7-76 D.Davenport, GE Global Research

  28. D0 Comment S7-81 • Comment: Delete "as described below“ (page 94, subclause 7.8.2.1.2, line 25) • ProposedChange: Delete "as described below“ • Proposed Resolution: Accept comment S7-81 D.Davenport, GE Global Research

  29. D0 Comment S7-77 • Comment: Delete "as described below" and insert a comma (page 76, subclause 7.3.1, line 29) • ProposedChange: Resulting in "… access phase, but not both.“ • Proposed Resolution: Accept comment S7-77 D.Davenport, GE Global Research

  30. D0 Comment S7-417 • Comment: Delete "described below“ (page 92, subclause 7.8, line 32) • ProposedChange: Delete "described below“ • Proposed Resolution: Accept comment S7-417 D.Davenport, GE Global Research

  31. 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) • ProposedChange: 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

  32. Proposed Resolution • Reject comment S7-440 • The definition requested by the comment can be found on page 79, line 17-18. D.Davenport, GE Global Research

  33. D0 Comment S7-75 • Comment: Entire 7.12.3 and subclauses and 7.12.4: What is a coordinator? There is no such term in this document (page 111, subclause 7.12.3, line 16) • ProposedChange: Replace coordinator with hub • Proposed Resolution: Accept comment S7-75 D.Davenport, GE Global Research

  34. D0 Comment S7-70 • Comment: Figure 75 Terms coordinator and device need to be replaced by hub and node (four occurrences), (page 95, subclause 7.8.2.1.2, line 18) • ProposedChange: 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

  35. D0 Comment S7-71 • Comment: Figure 77 Terms coordinator and device need to be replaced by hub and node (four occurrences), (page 97, subclause 7.8.2.1.4, line 3) • ProposedChange: Terms coordinator and device need to be replaced by hub and node • Proposed Resolution: Accept comment S7-71 D.Davenport, GE Global Research

  36. D0 Comment S7-64 • Comment: If mG-AckDataSubtype is a valid subtype, then add it to table 3 (page 73, subclause 7.2.7.2, line 8) • ProposedChange: Fix inconsistency D.Davenport, GE Global Research

  37. Proposed Resolution • Accept comment S7-64 in principle • Despite mG-AckDataSubtype being defined in subclauses 6.2.1.1.2 and 7.2.7.2, 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

  38. D0 CommentsS7-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) • ProposedChange: Define mEDScanDuration, mActiveScanDuration, mNetworkActivityDuration and mPassiveScanDuration as a MAC sublayer parameter in Table 23 D.Davenport, GE Global Research

  39. Alternative Resolutions • Define these parameters as higher layer parameters and define a new table (proposed resolution of 15-10-0648-01-0006) • Define these parameters as MAC sublayer parameters in Table 23 D.Davenport, GE Global Research

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

  41. 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 7.13.2) • ProposedChange: <none> • Must be satisfied: “No” D.Davenport, GE Global Research

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

  43. 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 • Email 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

  44. 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 7.12.3.3, line 113) • ProposedChange: 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

  45. 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 7.12.3.3 as identified by this comment D.Davenport, GE Global Research

  46. 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) • ProposedChange: Clarify the definition of emergency frame as used in this context. D.Davenport, GE Global Research

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

  48. 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) • ProposedChange: Change to "No applicability given LBT restrictions“ D.Davenport, GE Global Research

  49. Proposed Resolution • Accept comment S7-436 in principle • Change to “Not applicable given LBT restrictions” • Proposed resolution incorporated in co-pending resolution proposal DCN 15-10-0656-00-0006 D.Davenport, GE Global Research

  50. 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) • ProposedChange: Change cells for UWB Band such that Channel Hopping is shown as "not applicable" D.Davenport, GE Global Research

More Related