1 / 45

Proposed MAC Comment Resolutions for WPANs

This document proposes resolutions for MAC comments related to subclauses 6 and 7 of the TG6 draft D01 in the IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs).

rtarrant
Download Presentation

Proposed MAC Comment Resolutions for 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, 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. 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, 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. 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  40. Proposed Resolution • Accept comment S7-451 • Proposed resolution incorporated in co-pending resolution proposal DCN 15-10-0656-00-0006 D.Davenport, GE Global Research

  41. 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 7.12.2, line 19) • ProposedChange: Add sentence to beginning of subclause 7.12.2 stating the applicability of channel hopping to narrowband physical layer only. • Proposed Resolution: Accept comment S7-253 D.Davenport, GE Global Research

  42. 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 7.12.4, line 4) • ProposedChange: 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

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

  44. D0 Comment S7-267 • Comment: There is no table of PHY-dependent MAC sublayer parameters pertainint to HBC/EFC physical layer. (page 117, subclause 7.13.4, line 1) • ProposedChange: 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

  45. D0 Comment S7-61 • Comment: What does Table 17 have to do with the Frame Acknowledgement? (page 72, subclause 7.2.7, line 11) • ProposedChange: Delete cross reference to Table 17 • Proposed Resolution: Accept comment S7-61 D.Davenport, GE Global Research

More Related