1 / 38

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

doc.: IEEE 802. 15-10-0663-00-0006. Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: Proposed resolution for some comments in clause 7, 802.15.6 D01 Date Submitted: 09/2010 Source : Hui -Hsia Sung , Company: NICT Address Yokosuka, Japan

caesar
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. doc.: IEEE 802.15-10-0663-00-0006 Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title:Proposed resolution for some comments in clause 7, 802.15.6 D01 Date Submitted: 09/2010 Source:Hui-Hsia Sung , Company: NICT Address Yokosuka, Japan Voice: +46-81-46-857-5094, FAX: +46-81-46-857-5431, E-Mail: grace.sung@nict.go.jp Re:Proposed Resolutions of D01 Comments Abstract: Proposed resolutions for comments S6-427, S7-62, S7-412, S7-508, S7-368, S7-14, S7-268, S7-269, S7-371, S7-244, S7-245, S7-531, S7-374, S7-375, S7-376, S7-378, S7-381, S7-47, S7-356, S7-382, S7-532, S7-534, S7-384, S7-238 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. Hui-Hsia Sung, NICT

  2. doc.: IEEE 802.15-10-0663-00-0006 Proposed Resolutions of D0 Comments S6-427, S7-62, S7-412, S7-508, S7-368, S7-14, S7-268, S7-269, S7-371, S7-244, S7-245, S7-531, S7-374, S7-375, S7-376, S7-378, S7-381, S7-47, S7-356, S7-382, S7-532, S7-534, S7-384, S7-238

  3. doc.: IEEE 802.15-10-0663-00-0006 D0 Comment S6-427 S6-427 (6.7, pg.58) • Original comment: Table 15 Missing "Capability Element" that defines how many PHYs are supported by the "node". • Proposed change: Add Capability Element that defines the number of PHYs supported by the Node. It is possible for a mfg to develop and offer a multi-mode product. Hui-Hsia Sung, NICT

  4. doc.: IEEE 802.15-10-0663-00-0006 Proposed Resolution S6-427 (6.7, pg.58) • Original comment: Table 15 Missing "Capability Element" that defines how many PHYs are supported by the "node". • Proposed change: Add Capability Element that defines the number of PHYs supported by the Node. It is possible for a mfg to develop and offer a multi-mode product. • Proposed resolution: Deferred till joint MAC-PHY discussion. Hui-Hsia Sung, NICT

  5. doc.: IEEE 802.15-10-0663-00-0006 D0 Comment S7-62 S7-62 (7.2.7.2, pg.73, line 5) • Original comment: There is no mG-AckDataSubtype in table 3. mG-AckDataSubtype is a MAC sublayer parameter, not a subframe type. Its value of 15 is a user defined subtype in table 3. • Proposed change: Fix inconsistency Hui-Hsia Sung, NICT

  6. doc.: IEEE 802.15-10-0663-00-0006 Proposed Resolution S7-62 (7.2.7.2, pg.73, line 5) • Original comment: There is no mG-AckDataSubtype in table 3. mG-AckDataSubtype is a MAC sublayer parameter, not a subframe type. Its value of 15 is a user defined subtype in table 3. • Proposed change: Fix inconsistency • Proposed resolution: Accept . Rewrite pg.73 line 5. Change “The frame is a data type frame of mG-AckDataSubtype” to “The frame is a data type frame with the frame subtype set to mG-AckDataSubtype”. Also change “15” to “1111 (binary)” in Table 23 for the value of mG-AckDataSubtype. Hui-Hsia Sung, NICT

  7. doc.: IEEE 802.15-10-0663-00-0006 D0 Comment S7-412 S7-412 (7.4, pg.79, line 19) • Original comment: There is no Multinode Assignment frame • Proposed change: Insert Connection to use a defined frame Hui-Hsia Sung, NICT

  8. doc.: IEEE 802.15-10-0663-00-0006 Proposed Resolution S7-412 (7.4, pg.79, line 19) • Original comment: There is no Multinode Assignment frame • Proposed change: Insert Connection to use a defined frame • Proposed resolution:Accept the comment in principle . On pg.79, line 19, change “locally broadcast a Multinode Assignment frame….” to “locally broadcast a Multinode Connection Assignment frame….”. The Multinode Connect Assignment is already defined in 6.3.8, Fig.26. Hui-Hsia Sung, NICT

  9. doc.: IEEE 802.15-10-0663-00-0006 D0 Comments S7-508, S7-368, S7-14 S7-508 (7.8.2.1, pg.94, line 1~4) • Original comment: "As illustrated in Figure 73, prior to more frame exchanges with a connected node, the hub shall transmit a group of up to pMICSPolls Poll frames separated by pMICSPollSeparation, each addressed to the node and providing an immediate polled allocation" The above paragraph describes poll allocation and it does not suit with the title of the section." • Proposed change: Rewrite the paragraph. S7-368 (7.8.2.1.1, pg.94, line 22) • Original comment: " (1) Frame format should not be defined in clause 7. (2) Duplicate (and inconsistent) frame format between Fig.74 and Fig.34. (3) Fig.74 is in what units? Octets? (4) Fields in Fig.74 such as 'Session Start Time Offset' and 'session Length' are not defined in the text. " • Proposed change: Remove Fig.74, and review 7.8.2.1.1 and 7.8.2.1.2 to clean up some duplicated functions/frame fields that are already defined in 7.8.2.1 and 6.2.1.1.11 S7-14 (7.8.2.1.1, pg.94) • Original comment: This subclause (i.e. 7.8.2.1.1) makes no sense and should not have appeared here. • Proposed change: Remove it. Hui-Hsia Sung, NICT

  10. doc.: IEEE 802.15-10-0663-00-0006 Proposed Resolution S7-508 (7.8.2.1, pg.94, line 1~4) • Original comment: "As illustrated in Figure 73, prior to more frame exchanges with a connected node, the hub shall transmit a group of up to pMICSPolls Poll frames separated by pMICSPollSeparation, each addressed to the node and providing an immediate polled allocation" The above paragraph describes poll allocation and it does not suit with the title of the section." • Proposed change: Rewrite the paragraph. • Proposed resolution: Reject the proposed change. The title says “unicast poll aided discovery” which is substantiated by polls and polled allocations in the text and Figure 73 that follow. The issue raised in the comment appears unfounded.   Hui-Hsia Sung, NICT

  11. doc.: IEEE 802.15-10-0663-00-0006 Proposed Resolution S7-368 (7.8.2.1.1, pg.94, line 22) • Original comment: " (1) Frame format should not be defined in clause 7. (2) Duplicate (and inconsistent) frame format between Fig.74 and Fig.34. (3) Fig.74 is in what units? Octets? (4) Fields in Fig.74 such as 'Session Start Time Offset' and 'session Length' are not defined in the text. " • Proposed change: Remove Fig.74, and review 7.8.2.1.1 and 7.8.2.1.2 to clean up some duplicated functions/frame fields that are already defined in 7.8.2.1 and 6.2.1.1.11 • Proposed resolution: Remove 7.8.2.1.1 and 7.8.2.1.2 (including Fig. 74 and75) . May also need to clean up some Wakeup related text in clause 6. Detailed discussions: The so-called Wakeup frame defined in 7.8.2.1.1 is for the unicast (or the multicast) Wakeup mechanism described in 7.8.2.1.2 (and 7.8.2.1.4). However, how can a node receive such a Wakeup frame without being awake already in the first place? The name and functionality of the mechanism proposed here are misleading. In addition, such a unicast Wakeup mechanism is intended for the unconnected node also; but how can an unconnected node use the “session start time offset” & “session length” that announced in the Wakeup frame without being connected (and knowing the time reference) first? There seems to have no additional benefits (other than to confuse and complicate the implementation) in defining this Wakeup frame/mechanism compare to using the already defined poll frame and the unicast poll aided discovery described in 7.8.2.1. Moreover, most fields in the Wakeup frame remind undefined up to the preparation of this document. Hui-Hsia Sung, NICT

  12. doc.: IEEE 802.15-10-0663-00-0006 Proposed Resolution S7-14 (7.8.2.1.1, pg.94) • Original comment: This subclause (i.e. 7.8.2.1.1) makes no sense and should not have appeared here. • Proposed change: Remove it. • Proposed resolution: Accept. Hui-Hsia Sung, NICT

  13. doc.: IEEE 802.15-10-0663-00-0006 D0 Comments S7-268, 269 S7-268 (7.8.2.1.3, pg.95) • Original comment: Multicast lockup aided discovery. The concept described in the paragraph is not multiple node discovery. It is more like multiple node wakeup mechanism. • Proposed change: BLANK S7-269 (7.8.2.1.4, pg.96) • Original comment: Multicast wakeup mechanism. This section clearly describes the multi-node wakeup mechanism. The section naming is appropriate as well. The Multicast lockup aided discovery section is confusing and not required. • Proposed change: Remove the Multicast lockup aided discovery section. Hui-Hsia Sung, NICT

  14. doc.: IEEE 802.15-10-0663-00-0006 Proposed Resolution S7-268 (7.8.2.1.3, pg.95) • Original comment: Multicast lockup aided discovery. The concept described in the paragraph is not multiple node discovery. It is more like multiple node wakeup mechanism. • Proposed change: BLANK • Proposed resolution: Accept the comment in principle. Since (as suggested in the comment) the “multicast lockup aided discovery” already covers the “multiple node wakeup mechanism”, 7.8.2.1.4 seems redundant. Therefore, 7.8.2.1.4 should be further removed, especially these multicast lockup/wakeup mechanisms do not make any power saving sense.   Hui-Hsia Sung, NICT

  15. doc.: IEEE 802.15-10-0663-00-0006 Proposed Resolution S7-269 (7.8.2.1.4, pg.96) • Original comment: Multicast wakeup mechanism. This section clearly describes the multi-node wakeup mechanism. The section naming is appropriate as well. The Multicast lockup aided discovery section is confusing and not required. • Proposed change: Remove the Multicast lockup aided discovery section. • Proposed resolution: Rejected. Remove 7.8.2.1.4 and retain the current 7.8.2.1.3, but change “7.8.2.1.3” to “7.8.2.2” & “lockup” to “poll” in its heading so that it reads in parallel with 7.8.2.1 and better reflects its description text and figure. Detailed discussions: As explained in proposed resolution for comments S7-368, and S7-268, it seems unnecessary (and having no benefit ) to define this additional Wakeup mechanism rather than using the already defined poll frame and the multicast poll aided discovery currently described in 7.8.2.1.3. Hui-Hsia Sung, NICT

  16. doc.: IEEE 802.15-10-0663-00-0006 D0 Comments S7-371, S7-244, S7-245 S7-371 (7.8.2.1.4, pg.97, line 3) • Original comment:(1) Unclear what is Channel i, Channel i-1, Channel i-2 and Channel i-3 in Fig.77. (2) Unclear why/how nodes go to off-states during the confirm phase in Fig.77. • Proposed change: (1) Have Fig.77 in the same format as Fig.72 to Fig.76. (2) Explain how nodes knows when to sleep and when to wakeup in both the Lockup Phase and the Confirm Phase. S7-244 (7.8.2.1.2, pg.95, lines 16~17) • Original comment: Figure 75 and associated text lacks sufficient timing details. • Proposed change: Provide packet timing and duration for Wakeup, sniffing (i.e., Device listening interval), Ack, and duration of sniffing after session expires. S7-245 (7.8.2.1.3, pg.96, line 4) • Original comment: Figure 76 and associated text lacks sufficient timing details. • Proposed change: Provide specific timing for Poll, Ack and their durations. Hui-Hsia Sung, NICT

  17. doc.: IEEE 802.15-10-0663-00-0006 Proposed Resolution S7-371 (7.8.2.1.4, pg.97, line 3) • Original comment:(1) Unclear what is Channel i, Channel i-1, Channel i-2 and Channel i-3 in Fig.77. (2) Unclear why/how nodes go to off-states during the confirm phase in Fig.77. • Proposed change: (1) Have Fig.77 in the same format as Fig.72 to Fig.76. (2) Explain how nodes knows when to sleep and when to wakeup in both the Lockup Phase and the Confirm Phase. • Proposed resolution: Reject the comment . As a consequence of the proposed resolution for comments S7-268 and S7-269, 7.8.2.1.4 (including Fig 77) seems to be redundant to what already described in 7.8.2.1.3 and is proposed to be removed. With Fig.77 being removed, issues raised in this comment should have already been taken care in Fig.76. Hui-Hsia Sung, NICT

  18. doc.: IEEE 802.15-10-0663-00-0006 Proposed Resolution S7-244 (7.8.2.1.2, pg.95, lines 16~17) • Original comment: Figure 75 and associated text lacks sufficient timing details. • Proposed change: Provide packet timing and duration for Wakeup, sniffing (i.e., Device listening interval), Ack, and duration of sniffing after session expires. • Proposed resolution: Reject the comment. As a consequence of the proposed resolution for comment S7-368, 7.8.2.1.2 (including Fig 75) seems to be redundant to what already described in 7.8.2.1.1 and is proposed to be removed. With Fig.75 being removed, issues raised in this comment should have already been taken care in Fig.74. Hui-Hsia Sung, NICT

  19. doc.: IEEE 802.15-10-0663-00-0006 Proposed Resolution S7-245 (7.8.2.1.3, pg.96, line 4) • Original comment: Figure 76 and associated text lacks sufficient timing details. • Proposed change: Provide specific timing for Poll, Ack and their durations. • Proposed resolution:Reject the comment. Figure 76 is already packed with lots of timing information. Other timing information is specified in the text already when appropriate; such as “announcing a future poll starting at the intended beginning of the first individual communication session with a node of the group” (lines 23~25, pg.95) and “The hub shall transmit a poll addressed to a node of the group at the indicated future poll time and providing an immediate polled allocation” (lines 26~27, pg. 95). Hui-Hsia Sung, NICT

  20. doc.: IEEE 802.15-10-0663-00-0006 D0 Comment S7-531 S7-531 (7.12.1, pg.109, Figure 88) • Original comment: In Fig. 88 (b), It is not given which lengths are L_1 or L_2. • Proposed change: Add L_1 or L_2 In Fig. 88 (b) Hui-Hsia Sung, NICT

  21. doc.: IEEE 802.15-10-0663-00-0006 Proposed Resolution S7-531 (7.12.1, pg.109, Figure 88) • Original comment: In Fig. 88 (b), It is not given which lengths are L_1 or L_2. • Proposed change: Add L_1 or L_2 In Fig. 88 (b) • Proposed resolution:Accept the comment in principle. Remove the figure legend “L=L_1+L_2” in Fig. 88(b). Detailed discussions: L_1 and L_2 will occur only if the scheduled allocation interval has been splitted into two portions (as a result of beacon shifting), as illustrated in the beacon period n+1 in Fig.88 (a). The main purpose of Fig. 88(b) here is to illustrate the m-periodic allocation scenario, as oppose to the 1-periodic allocation shown in Fig. 88(a). In Fig.88(b), the case of the scheduled allocation interval splitted into two portions is not shown. Therefore, the allocation interval length is simply labeled as ‘L’ (which is also equal to L_1 + L_2, if it was splitted into two portions). Since L_1 and L_2 are not used in Fig. 88(b), removing them from the figure (b) legend may help to avoid introducing some confusions. Hui-Hsia Sung, NICT

  22. doc.: IEEE 802.15-10-0663-00-0006 D0 Comment S7-374 S7-374 (7.12.3, pg.112, line 3) • Original comment: Energy detection (ED) has not be included in the abbreviations list. • Proposed change: Include ED in the abbreviation list on pg.10. Hui-Hsia Sung, NICT

  23. doc.: IEEE 802.15-10-0663-00-0006 Proposed Resolution S7-374 (7.12.3, pg.112, line 3) • Original comment: Energy detection (ED) has not be included in the abbreviations list. • Proposed change: Include ED in the abbreviation list on pg.10. • Proposed resolution: This is an editorial issue relating to other technical comments made. Accept or reject this comment depending on the decision of comments S7-213 , S7-32 and S7-214, S7-33. If the lines 1~10 and 11~25 in pg.112 are removed, there is no need to address this comment. Hui-Hsia Sung, NICT

  24. doc.: IEEE 802.15-10-0663-00-0006 D0 Comment S7-375 S7-375 (7.12.3, pg.112, line 4) • Original comment: Values of MAC sublayer parameters introduced in this sub-clause (such as mEDScanDuration) are not provided in Table 23. • Proposed change: Review those MAC sublayer parameters. Hui-Hsia Sung, NICT

  25. doc.: IEEE 802.15-10-0663-00-0006 Proposed Resolution S7-375 (7.12.3, pg.112, line 4) • Original comment: Values of MAC sublayer parameters introduced in this sub-clause (such as mEDScanDuration) are not provided in Table 23. • Proposed change: Review those MAC sublayer parameters. • Proposed resolution: This is an editorial issue relating to other technical comments made. Accept or reject this comment depending on the decision of comments S7-213 , S7-32 and S7-214, S7-33. If the lines 1~10 and 11~25 are removed, there is no need to address this comment; otherwise, define mEDScanDuration as a MAC sublayer parameter in Table 23. Note that similar comments are also made in S7-255~259. Hui-Hsia Sung, NICT

  26. doc.: IEEE 802.15-10-0663-00-0006 D0 Comment S7-376 S7-376 (7.12.3, pg.112, lines 11) • Original comment: BAN enquiry frame is undefined • Proposed change: Define the BAN enquiry/request frames, or remove it. Hui-Hsia Sung, NICT

  27. doc.: IEEE 802.15-10-0663-00-0006 Proposed Resolution S7-376 (7.12.3, pg.112, lines 11) • Original comment: BAN enquiry frame is undefined • Proposed change: Define the BAN enquiry/request frames, or remove it. • Proposed resolution: Accept the proposal to remove it, especially if the BAN enquiry frame still remains undefined at the time when this slide is discussed. In addition, please consider the decision made regarding comments S7-214, S7-33, which have also suggested to remove the BAN enquiry/request frames. Hui-Hsia Sung, NICT

  28. doc.: IEEE 802.15-10-0663-00-0006 D0 Comment S7-378 S7-378(7.12.3, pg.112, line 19) • Original comment: What does "BAN descriptor" mean? • Proposed change: When the term firstly used in the text, should clearly specify what fields in B2 and Beacon messages the BAN descriptor is referring to. (i.e. in Beacon messages, it refers to the Inactive Duration) Hui-Hsia Sung, NICT

  29. doc.: IEEE 802.15-10-0663-00-0006 Proposed Resolution S7-378(7.12.3, pg.112, line 19) • Original comment: What does "BAN descriptor" mean? • Proposed change: When the term firstly used in the text, should clearly specify what fields in B2 and Beacon messages the BAN descriptor is referring to. (i.e. in Beacon messages, it refers to the Inactive Duration) • Proposed resolution: This relating to other technical comments made. Accept or reject this comment depending on the decision of comments S7-213 , S7-32, S7-214, S7-33 and S7-215,S7-34 . If the lines 1~10 and 11~25 in pg.112 are removed, there is no need to address this comment; otherwise, clearly specify what fields in the B2 and the Beacon messages the BAN descriptor is referring to. Hui-Hsia Sung, NICT

  30. doc.: IEEE 802.15-10-0663-00-0006 D0 Comments S7-381, S7-47, S7-356, S7-382 S7-381 (7.13.2, pg.115) • Original comment: (1) This sub-clause seems have been modified without informing the MAC subgroup members. (2) Contradictions between lines 17-19 & lines 24-27; both are for 'upon failing to receive an expected I-Ack', but have different flags set in the PHY header. How? (3) Line 24-27, what is the benefit of retransmitting the retained information bit, which has been retained already? • Proposed change: (1) Revise the content. (2) Suggestion: remove lines 24-27, and combine lines 28-32 with lines 14-16. S7-47 (7.13.2, pg.115, lines 6-39) • Original comment: This subclause was modified, incorrectly or inaccurately, in this draft without a discussion at the MAC subgroup. • Proposed change: Restore the text that existed prior to D0. If they are not correct or complete, please work with the MAC subgroup. S7-356 (7.13.2 , pg.115, line 6) • Original comment: The description on hybri ARQ is still unclear. There are many duplicated descriptions, but the subclause does not contain the rationale on Phy layer operation. Especially, it is very vague and unclear what is meant by "the recipient shall retain at its PHY layer the MAC frame". line 16, page 115. More precise information (or pointer to the subclausedesribing hybrid ARQ PHY operation) is needed. • Proposed change: As in comment. Provide more detailed description on hybrid ARQ. Also, timer based operation for erroneous state recovery should be needed. S7-382 (7.13.2 , pg.115, line 33) • Original comment: How to decide the maximum number of retransmission? • Proposed change: Allow the process to be repeated until receiving a different frame with H0 set back to 0, provided transmissions will be complicated with its allocation interval. Hui-Hsia Sung, NICT

  31. doc.: IEEE 802.15-10-0663-00-0006 Proposed Resolution S7-381 (7.13.2, pg.115) • Original comment: (1) This sub-clause seems have been modified without informing the MAC subgroup members. (2) Contradictions between lines 17-19 & lines 24-27; both are for 'upon failing to receive an expected I-Ack', but have different flags set in the PHY header. How? (3) Line 24-27, what is the benefit of retransmitting the retained information bit, which has been retained already? • Proposed change: (1) Revise the content. (2) Suggestion: remove lines 24-27, and combine lines 28-32 with lines 14-16. • Proposed resolution:Defer till the joint MAC-PHY discussion. Hui-Hsia Sung, NICT

  32. doc.: IEEE 802.15-10-0663-00-0006 Proposed Resolution S7-47 (7.13.2, pg.115, lines 6-39) • Original comment: This subclause was modified, incorrectly or inaccurately, in this draft without a discussion at the MAC subgroup. • Proposed change: Restore the text that existed prior to D0. If they are not correct or complete, please work with the MAC subgroup. • Proposed resolution:Defer till the joint MAC-PHY discussion. Hui-Hsia Sung, NICT

  33. doc.: IEEE 802.15-10-0663-00-0006 Proposed Resolution S7-356 (7.13.2 , pg.115, line 6) • Original comment: The description on hybirdARQ is still unclear. There are many duplicated descriptions, but the subclause does not contain the rationale on Phy layer operation. Especially, it is very vague and unclear what is meant by "the recipient shall retain at its PHY layer the MAC frame". line 16, page 115. More precise information (or pointer to the subclausedesribing hybrid ARQ PHY operation) is needed. • Proposed change: As in comment. Provide more detailed description on hybrid ARQ. Also, timer based operation for erroneous state recovery should be needed. • Proposed resolution: Defer till the joint MAC-PHY discussion . Should consider the comment to reference subclause 10.16 here in 7.13.2. More detailed Hybird ARQ description and the rationale on PHY layer should be provided in subclause10.16. Hui-Hsia Sung, NICT

  34. doc.: IEEE 802.15-10-0663-00-0006 Proposed Resolution S7-382 (7.13.2 , pg.115, line 33) • Original comment: How to decide the maximum number of retransmission? • Proposed change: Allow the process to be repeated until receiving a different frame with H0 set back to 0, provided transmissions will be completed with its allocation interval. • Proposed resolution: Defer till the joint MAC-PHY discussion. Hui-Hsia Sung, NICT

  35. doc.: IEEE 802.15-10-0663-00-0006 D0 Comments S7-532,S7-534,S7-384,S7-56/238/179 S7-532 (7.13.4, pg.117, Table 24) • Original comment: UWB needs both slotted ALOHA and CSMA • Proposed change: Add CSMA for UWB S7-534 (7.13.4, pg.117 &118, Table 24 &25) • Original comment: UWB needs CSMA/CA as well as slotted ALOHA. • Proposed change: CSMA/CA should be added for UWB. S7-384 (7.13.4 , pg.118, Table 25) • Original comment: Parameters in Table 25 should be further discussed • Proposed change: To be discussed and agreed within the MAC subgroup S7-56/238/179 (7.13.4 , pg.118, Table 25) • Original comment: (1) The value for pAllohaSlotLength should be first given by an equation containing the underlying parameters. (2) This value should be equal to the transmit time of a PHY frame with a MAC frame of "typical" length transmitted at the lowest mandatory data rate for the UWB PHY, plus pSIFS, plus the transmit time of a PHY frame with a MAC frame of 7+2 octets transmitted at the lowest mandatory data rate for the UWB PHY, plus mGT_Nominal. • Proposed change: Revise the entry as noted in the comment. Hui-Hsia Sung, NICT

  36. doc.: IEEE 802.15-10-0663-00-0006 Proposed Resolution S7-532 (7.13.4, pg.117, Table 24) • Original comment: UWB needs both slotted ALOHA and CSMA • Proposed change: Add CSMA for UWB • Proposed resolution: Accept. In Table 24, delete everything after CSMA/CA from the value entry for pRandomAccess. S7-534 (7.13.4, pg.117 &118, Table 24 &25) • Original comment: UWB needs CSMA/CA as well as slotted ALOHA. • Proposed change: CSMA/CA should be added for UWB. • Proposed resolution: Accept. In Table 25, add “CSMA/CA or” before “Slotted Aloha” in the value entry for pRandomAccess.  Hui-Hsia Sung, NICT

  37. doc.: IEEE 802.15-10-0663-00-0006 Proposed Resolution S7-384 (7.13.4 , pg.118, Table 25) • Original comment: Parameters in Table 25 should be further discussed • Proposed change: To be discussed and agreed within the MAC subgroup • Proposed resolution:Defer till the joint MAC-PHY discussion. Hui-Hsia Sung, NICT

  38. doc.: IEEE 802.15-10-0663-00-0006 Proposed Resolution S7-56/238/179 (7.13.4 , pg.118, Table 25) • Original comment: (1) The value for pAllohaSlotLength should be first given by an equation containing the underlying parameters. (2) This value should be equal to the transmit time of a PHY frame with a MAC frame of "typical" length transmitted at the lowest mandatory data rate for the UWB PHY, plus pSIFS, plus the transmit time of a PHY frame with a MAC frame of 7+2 octets transmitted at the lowest mandatory data rate for the UWB PHY, plus mGT_Nominal. • Proposed change: Revise the entry as noted in the comment. • Proposed resolution: Accept. Changes the value for pAllohaSlotLength accordingly. Hui-Hsia Sung, NICT

More Related