1. doc.: IEEE /XXXr0
Sep 19, 2007
July 2010
Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs)‏
Submission Title: [Proposed Resolution for Comments Related to Multi-PHY-Mode Management Scheme Employing Common Signaling Mode – First Attempt]
Date Submitted: [July 2010]
Source: [Chin-Sean Sum, Hiroshi Harada, Fumihide Kojima]
Company [NICT]
Address [3-4, Hikarino-oka, Yokosuka, , Japan]
Voice: [ ], FAX: [ ],
Re: []
Abstract: [This document provides resolutions to comments for MPM and CSM]
Purpose: [This document provides resolutions to comments of LB51]
Notice: This document has been prepared to assist the IEEE P It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein.
Release: The contributor acknowledges and accepts that this contribution becomes the property of IEEE and may be made publicly available by P
C.S. Sum
Name - WirelessHD

2. July 2010
Summary
This document addresses various comments for the Multi- PHY-mode Management scheme for the purpose of inter- PHY coexistence
For each comment, the following is addressed:
The overall response to the comment
The corresponding resolutions
The exact change in the draft
Comments belonging to the same topic are grouped together and resolved collectively
C.S. Sum

3. CID 695 Comment: Specify the value of phyMRFSKSFD for CSM
July 2010
CID 695
Comment: Specify the value of phyMRFSKSFD for CSM
Response: Accept in principle. The additional specification will be added in subclause 6.1a.
Resolution 1: Add in subclause 6.1a, as the last paragraph, the following blue text:
“The attribute phyMRFSKSFD shall be set to 0 in the MHz band, 0 otherwise”
C.S. Sum

4. July 2010
CID 125, 689, 1569, 1643, 1705, 1731
Comment: The MPM (CSM) should be for PAN coordinators, not all coordinators
Response: Accept in principle. In a regulatory domain with multiple PHYs, at least the PAN coordinators shall be able to facilitate inter-PHY coexistence. The support for CSM is made optional for coordinators
Resolution 1: Replace the first paragraph of subclause 7.5.8c
“In order to effectively manage multiple SUNs utilizing different PHY modes in the same location, the MPM management scheme specifies that all coordinators shall be able to transmit and receive CSM index 0, as given in Table 6a (see 6.1a). A coex-beacon shall be sent in the CSM index 0. ”
with the blue text below:
“In order to effectively manage multiple SUNs utilizing different PHY modes in the same location, the MPM management scheme specifies that all PAN coordinators shall be able to transmit and receive CSM index 0, as given in Table 6a (see 6.1a). A coex-beacon shall be sent in the CSM index 0. To further enhance the level of coexistence among PHY modes, besides PAN coordinators, coordinators should also support CSM index 0.”
Resolution 2: Replace all terms “coordinator” in subclause 7.5.8c with “PAN coordinator”.
C.S. Sum

5. July 2010
CID 1650, 1714, 1730 (1/6)
Comment: Clarify the transmission of coex-beacon in CAP
Response: In the current frame format specification, two subfields are used to determine the position of the coex-beacon in the superframe: “Coex-beacon Order” and “Offset Time Order”. In the CAP, if the transmission of a coex-beacon is delayed due to backoff in the slotted CSMA/CA, the backoff timing should be given. A new subfield is added into the frame format: “CAP Backoff Offset”. The CAP Backoff Offset subfield specifies the actual slot the coex-beacon was transmitted due to backoff.
Resolution 1: Change to Coex Specification field from 32 bits to 40 bits in the first paragraph of subclause a.2
C.S. Sum

6. July 2010
CID 1650, 1714, 1730 (2/6)
Resolution 2: Add in a.2, a new paragraph after the paragraph “The Offset Time…” as the blue text below:
“The CAP Backoff Offset subfield is 4 bits in length and specifies the actual slot position the coex-beacon is transmitted due to backoff procedure in CAP”
Resolution 3: Add the new 4-bit subfield “CAP Backoff Offset” in figure 92b corresponding to Resolution 2.
C.S. Sum

7. July 2010
CID 1650, 1714, 1730 (3/6)
Resolution 4: Replace the fifth paragraph in subclause a.2
“The Offset Time Order subfield is 4 bits in length and shall specify the interval between the coex-beacon and the following beacon. See a for more explanation.”
With the blue text below
“The Offset Time Slot subfield is 4 bits in length and shall specify the interval between the coex-beacon and the preceding periodic beacon. See a for more explanation.”
Resolution 5: Change figure 92b reflecting Resolution 4
C.S. Sum

8. July 2010
CID 1650, 1714, 1730 (4/6)
Resolution 6: Replace figure 105a with below
C.S. Sum

9. July 2010
CID 1650, 1714, 1730 (5/6)
Resolution 7: Replace the third paragraph in subclause a
The interval between a coex-beacon and the subsequent periodic beacon is described by the Offset Time Order (OTO). The MAC PIB attribute for OTO is macOffsetTimeOrder. The values of OTO and offset time duration (OTD) are related as follows:
OTD = aBaseSuperframeDuration * 2OTO symbols.
with the following blue text
“The interval between a coex-beacon and the preceding periodic beacon is described by the Offset Time Slot (OTS). The MAC PIB attribute for OTS is macOffsetTimeSlot. The values of OTS and offset time duration (OTD) are related as follows:
OTD = aBaseSuperframeDuration * OTS symbols.”
C.S. Sum

10. July 2010
CID 1650, 1714, 1730 (6/6)
Resolution 8: Replace attribute macOffsetTimeOrder with in Table 127 the following:
Attribute
Identifier
Type
Range
Description
Default
macOffsetTimeSlot
Integer
0-15
Specification of the duration between the coex-beacon and the preceding periodic beacon. OTS=0 is invalid. 15
C.S. Sum

11. July 2010
CID , 1754, 1755 (1/2)
Comment: The information on symbol time of should be clarified
Resolution 1: Add in subclause a, before the last paragraph, the following blue text:
“The symbol time in (3) and (4) shall be based on the CSM as specified in Table 6a.”
Resolution 2: Accept in principle. Replace the 7th paragraph in subclause a.2 :
“The PHY Mode Control subfield is 4 bits in length and shall specify the PHY mode of the source PAN. The values for the PHY modes shall be specified in Table 121a.”
with the blue text below:
“The PHY Mode Control subfield is 6 bits [b0 b1 b2 b3 b4 b5] in length, where [b0 b1] specify the PHY type of the source PAN and [b2 b3 b4 b5] specify the symbol rate of respective PHYs as given in Table 1. The values of the PHY Mode Control subfield shall be specified in Table 121a.”
C.S. Sum

12. Confirm values CID 1651-1657, 1754, 1755 (2/2)
July 2010
CID , 1754, 1755 (2/2)
Resolution 2: Update figure 92b accordingly to Resolution 3
Resolution 3: Modify Table 121a as below
Bits [b0 b1]
PHY Type
Bits [b2 b3 b4 b5]
Symbol Rate 00
MR-FSK
0000 50 01
OFDM
0001
100 10
O-QPSK
0010
150 11
Reserved
0011
200
0100
125
0101
1000
0110
2000
Confirm values
C.S. Sum

13. July 2010
CID 1757, 1758 (1/2)
Comment: Revise MAC PIB attribute for coex-beacon payload “macBeaconPayloadLength” and “macBeaconPayload”
Resolution 1: Accept in principle. Replace first paragraph of subclause a.3
“ The Coex-beacon Payload field is an optional sequence of up to macBeaconPayloadLength octets specified to be transmitted in the coex-beacon frame by the next higher later. The set of octets contained in macBeaconPayload shall be copied to this field.”
with the blue text below
“ The Coex-beacon Payload field is an optional sequence of up to macCoexBeaconPayloadLength octets specified to be transmitted in the coex- beacon frame by the next higher later. The set of octets contained in macCoexBeaconPayload shall be copied to this field.”
C.S. Sum

14. July 2010
CID 1757, 1758 (2/2)
Resolution 2: Add the below MAC PIB attributes into Table 127
Attribute
Identifier
Type
Range
Description
Default
macCoexBeaconPayload
Set of octets --
The contents of the coex-beacon payload.
NULL
macCoexBeaconPayloadLength
Integer
0 - aMaxBeaconPayloadLength
The length, in octets, of the coex-beacon payload.
C.S. Sum

15. CID 1727 (1/2) Comment: Maximum coex-beacon interval is too long.
July 2010
CID 1727 (1/2)
Comment: Maximum coex-beacon interval is too long.
Response: Shorten the maximum coex-beacon interval. Now since only PAN coordinators (as compared to all coordinators previously) are required to support the CSM, these PAN coordinators may be handling specific tasks such as inter-PHY coexistence. These coexistence coordinators may be connected to power source and therefore, may perform more frequent coex-beacon transmission and scanning.
Resolution 1: Replace the 5th paragraph in subclause a.2
“The Coex-beacon Order subfield is 5 bits in length and shall specify the transmission interval of the coex- beacon frames. See a for an explanation of the relationship between coex-beacon order and coex-beacon interval.”
with the blue text below:
“The Coex-beacon Order subfield is 4 bits in length and shall specify the transmission interval of the coex- beacon frames. See a for the explanation of the relationship between coex-beacon order and coex-beacon interval.”
Resolution 2: Update figure 92b according to Resolution 1.
C.S. Sum

16. July 2010
CID 1727 (2/2)
Resolution 3: Replace MAC PIB attribute “macCoexBeaconOrder” in Table 127 as below:
Attribute
Identifier
Type
Range
Description
Default
macCoexBeaconOrder
Integer
0-15
Specification of how often the coordinator transmits its coex-beacon. If CBO = 15, this attribute is ignored.
C.S. Sum

17. July 2010
CID 1575, 1639, , 1660, (1/4)
Comment: Add and clarify transmission of coex-beacon in non- beacon-enabled PAN (NBPAN)
Response: The two main missing parts for coex-beacon in the NBPAN are the procedure description and timing information. In the following resolutions, the relevant explanations are added and the interval between two transmissions of coex-beacon in the NBPAN is specified.
Resolution 1: Add two new subfields into the coex-beacon frame, “NBPAN Control” and “NBPAN Coex-beacon Interval”
C.S. Sum

18. July 2010
CID 1575, 1639, , 1660, (2/4)
Resolution 2: Add a paragraph into subclause a.2, as the blue text below:
“The NBPAN Control subfield is 1 bit in length and shall specify whether the source PAN is operating in non-beacon-enabled mode, where 1 representing the source PAN operating in the non-beacon-enabled mode and 0 representing the beacon-enabled mode. If NBPAN control is set to 1, subfields such as Superframe Order, Final CAP Slot, Coex-beacon Order, Offset Time Order shall be ignored.”
Resolution 3: Add a paragraph into subclause a.2, as the blue text below:
“The NBPAN Coex-beacon Interval is 16 bits in length and shall specify the maximum duration of the interval between consecutive coex-beacons in the non- beacon-enabled mode.”
Resolution 4: Update figure 92a according to Resolution 2 and 3
C.S. Sum

19. July 2010
CID 1575, 1639, , 1660, (3/4)
Resolution 5: Replace the last paragraph in subclause a in the following:
“In a non-beacon-enabled PAN, the only related timing information is macCoexBeaconOrder, and it is used to described the interval between two consecutive coex-beacon frames.”
With the following blue text
“In a non-beacon-enabled PAN, the interval between two coex-beacon frames is described in the NBPAN Control subfield and NBPAN Coex-beacon Interval subfield in a.2. The resolution of the time shall be aMinNBPANTimeUnit.”
Resolution 6: Add the following MAC sublayer constant in Table 85
Constant
Description
Value
aMinNBPANTimeUnit
The minimum time unit in milli-seconds in the non-beacon-enabled mode 1
C.S. Sum

20. July 2010
CID 1575, 1639, , 1660, (4/4)
Resolution 7: Replace the last paragraph in subclause c in the following:
“In a non-beacon-enabled PAN, an existing coordinator shall transmit a coex-beacon periodically by using the CSM index 0. The rest of the procedure is similar to that in the beacon-enabled PAN. The illustration of the procedure is given in figure 112c.”
with the following blue text
“In a non-beacon-enabled PAN, an existing coordinator shall transmit a coex-beacon periodically by using the CSM index 0. Any incoming potential coordinator shall first scan for the coex-beacon for twice the duration of the maximum interval as described in a.2. The illustration of the procedure is given in figure 112c.”
C.S. Sum

21. CID 1724, 1727 Comment: Change the scan time to maximum possible
July 2010
CID 1724, 1727
Comment: Change the scan time to maximum possible
Resolution: Accept in principle. Change the second paragraph in subclause 7.5.8c in the following:
“In a beacon enabled-PAN, an existing coordinator shall transmit a coex-beacon at fixed interval by using CSM index 0. The coex-beacon may be transmitted in any part of the superframe. Any incoming potential coordinator shall first scan for the coex-beacon for at least the duration of the CBI before starting its own network. If an incoming…”
with the blue text below:
“In a beacon enabled-PAN, an existing coordinator shall transmit a coex-beacon at fixed interval by using CSM index 0. The coex-beacon may be transmitted in any part of the superframe. Any incoming potential coordinator shall first scan for the coex-beacon for the maximum duration of the CBI before starting its own network. If an incoming…”
C.S. Sum

22. Collaborate with FH group
July 2010
CID for all FH
Comment: Clarify the operation of MPM employing CSM in the frequency hopping (FH) mode
Response: The basic idea of facilitating coexistence between FH devices and non-FH devices belonging to different PHYs is, to specify a common channel for the coex-beacon transmission and coex-beacon scan
Resolution 1: Add a new subclause “6.1b Common control channel (CCC)” with contents as the blue text below:
“The ”
Collaborate with FH group
C.S. Sum