Doc.: IEEE 802.15- Submission 09/2010 Hui-Hsia Sung, NICTSlide 1 Project: IEEE P802.15 Working Group...

doc.: IEEE 802.15-<doc#>

Submission

09/2010

Hui-Hsia Sung, NICTSlide 1

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/2010Source: Hui-Hsia Sung , Company: NICTAddress Yokosuka, JapanVoice: +46-81-46-857-5094, FAX: +46-81-46-857-5431, E-Mail: [email protected]

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.

doc.: IEEE 802.15-10-0663-00-0006


Submission

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

doc.: IEEE 802.15-10-0663-00-0006


Submission

09/2010


D0 Comment S6-427S6-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.

doc.: IEEE 802.15-10-0663-00-0006


Submission

09/2010


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.

doc.: IEEE 802.15-10-0663-00-0006


Submission

09/2010


D0 Comment S7-62S7-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

doc.: IEEE 802.15-10-0663-00-0006


Submission

09/2010


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.

doc.: IEEE 802.15-10-0663-00-0006


Submission

09/2010


D0 Comment S7-412S7-412 (7.4, pg.79, line 19)• Original comment: There is no Multinode Assignment frame• Proposed change: Insert Connection to use a defined frame

doc.: IEEE 802.15-10-0663-00-0006


Submission

09/2010


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.

doc.: IEEE 802.15-10-0663-00-0006


Submission

09/2010


D0 Comments S7-508, S7-368, S7-14S7-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.

doc.: IEEE 802.15-10-0663-00-0006


Submission

09/2010


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.

doc.: IEEE 802.15-10-0663-00-0006


Submission

09/2010


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

doc.: IEEE 802.15-10-0663-00-0006


Submission

09/2010


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.

doc.: IEEE 802.15-10-0663-00-0006


Submission

09/2010


D0 Comments S7-268, 269S7-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.

doc.: IEEE 802.15-10-0663-00-0006


Submission

09/2010


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.

doc.: IEEE 802.15-10-0663-00-0006


Submission

09/2010


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

doc.: IEEE 802.15-10-0663-00-0006


Submission

09/2010


D0 Comments S7-371, S7-244, S7-245S7-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.

doc.: IEEE 802.15-10-0663-00-0006


Submission

09/2010


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.

doc.: IEEE 802.15-10-0663-00-0006


Submission

09/2010


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

doc.: IEEE 802.15-10-0663-00-0006


Submission

09/2010


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

doc.: IEEE 802.15-10-0663-00-0006


Submission

09/2010


D0 Comment S7-531S7-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)

doc.: IEEE 802.15-10-0663-00-0006


Submission

09/2010


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.

doc.: IEEE 802.15-10-0663-00-0006


Submission

09/2010


D0 Comment S7-374S7-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.

doc.: IEEE 802.15-10-0663-00-0006


Submission

09/2010


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.

doc.: IEEE 802.15-10-0663-00-0006


Submission

09/2010


D0 Comment S7-375S7-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.

doc.: IEEE 802.15-10-0663-00-0006


Submission

09/2010


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.

doc.: IEEE 802.15-10-0663-00-0006


Submission

09/2010


D0 Comment S7-376S7-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.

doc.: IEEE 802.15-10-0663-00-0006


Submission

09/2010


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.

doc.: IEEE 802.15-10-0663-00-0006


Submission

09/2010


D0 Comment S7-378S7-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)

doc.: IEEE 802.15-10-0663-00-0006


Submission

09/2010


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.

doc.: IEEE 802.15-10-0663-00-0006


Submission

09/2010


D0 Comments S7-381, S7-47, S7-356, S7-382S7-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 subclause desribing 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.

doc.: IEEE 802.15-10-0663-00-0006


Submission

09/2010


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.

doc.: IEEE 802.15-10-0663-00-0006


Submission

09/2010


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

doc.: IEEE 802.15-10-0663-00-0006


Submission

09/2010


Proposed Resolution

S7-356 (7.13.2 , pg.115, line 6)• Original comment: The description on hybird 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 subclause desribing 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.

doc.: IEEE 802.15-10-0663-00-0006


Submission

09/2010


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.

doc.: IEEE 802.15-10-0663-00-0006


Submission

09/2010


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.

doc.: IEEE 802.15-10-0663-00-0006


Submission

09/2010


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.

doc.: IEEE 802.15-10-0663-00-0006


Submission

09/2010


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.

doc.: IEEE 802.15-10-0663-00-0006


Submission

09/2010


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.

doc.: IEEE 802.15-10-0663-00-0006

Date post:	02-Jan-2016
Category:	Documents
Upload:	grace-french
View:	219 times
Download:	2 times

Doc.: IEEE 802.15- Submission 09/2010 Hui-Hsia Sung, NICTSlide 1 Project: IEEE P802.15 Working Group...

Documents