doc.: IEEE g TG4g Presentation July 2010 C.S. SumSlide 1 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs)‏ Submission Title: [Proposed Resolution for Comments Related to Multi-PHY 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

doc.: IEEE g TG4g Presentation Summary July 2010 C.S. SumSlide 2 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

doc.: IEEE g TG4g Presentation CID 695 July 2010 C.S. SumSlide 3 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 value of the SFD field as given in shall be associated with a value of zero for the attribute phyMRFSKSFD as described in Table 31.”

doc.: IEEE g TG4g Presentation CID 125, 689, 1569, 1643, 1705, 1729, 1731 (1/2) July 2010 C.S. SumSlide 4 Comment: The MPM (CSM) should be for PAN coordinators, not all coordinators. Response: Accept in principle. In a regulatory domain with multiple PHYs, all coordinators shall have the capability to facilitate inter-PHY coexistence. Therefore, all coordinators shall be capable of transmitting and receiving the coex-beacon through CSM, while the decision to actually transmit one is the decision of the NHL. 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 PHYs in the same location, the MPM management scheme specifies that all coordinators operating at duty ratio (cycle) of more than 1%, shall be able to transmit and receive CSM, as given in Table 6a (see 6.1a). In the MPM management scheme, a coex-beacon shall be sent in the CSM.”

doc.: IEEE g TG4g Presentation CID 125, 689, 1569, 1643, 1705, 1729, 1731 (2/2) July 2010 C.S. SumSlide 5 Resolution 2: A set of primitives are specified in 7.1 MAC sublayer service specification, including the coex-beacon notification primitive, the coex-beacon scan primitives and the coex-beacon start primitives. Refer to doc 10/593r0:

doc.: IEEE g TG4g Presentation CID 1650, 1714, 1730 (1/7) July 2010 C.S. SumSlide 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”. Basically, it is recommended that the coex-beacon is sent in the CFP CAP. In case the CFP is not present, coex-beacon may also be sent in the CAP. 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. Mechanism is specified to ensure that the coex-beacon can be sent out in the CAP within the same superframe.

doc.: IEEE g TG4g Presentation CID 1650, 1714, 1730 (2/7) July 2010 C.S. SumSlide 7 Resolution 1: Change to Coex Specification field from 32 bits to 40 bits in the first paragraph of subclause a.2 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.

doc.: IEEE g TG4g Presentation CID 1650, 1714, 1730 (3/7) July 2010 C.S. SumSlide 8 Response: The following resolutions are handling the timing information between the periodic beacon and the coex-beacon 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

doc.: IEEE g TG4g Presentation CID 1650, 1714, 1730 (4/7) July 2010 C.S. SumSlide 9 Resolution 5a: Add in 7.5.8c, a new paragraph after the second paragraph “In a beacon-enabled…” as the following text: “The coex-beacon may be is sent in the CAP or the CFP. In the CAP case where the CFP is not present, the MAC sublayer shall ensure that, after the random backoff, the remaining CSMA/CA operations can be undertaken and the entire transaction can be transmitted before the end of the CAP. If the number of backoff periods is less than or equal to the remaining number of backoff periods in the CAP, the MAC sublayer shall apply its backoff delay and then evaluate whether it can proceed. The MAC shall proceed if the remaining CSMA/CA algorithm steps and the coex- beacon transmission can be completed before the end of the CAP. If the number of backoff periods is greater than the remaining number of backoff periods in the CAP, the MAC sublayer shall randomly select one remaining backoff period and perform coex- beacon transmission.”

doc.: IEEE g TG4g Presentation CID 1650, 1714, 1730 (5/7) July 2010 C.S. SumSlide 10 Resolution 6: Replace figure 105a with below

doc.: IEEE g TG4g Presentation CID 1650, 1714, 1730 (6/7) July 2010 C.S. SumSlide 11 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 * 2 OTO 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 = aBaseSlotDuration * OTS symbols.”

doc.: IEEE g TG4g Presentation CID 1650, 1714, 1730 (7/7) July 2010 C.S. SumSlide 12 Resolution 8: Replace attribute macOffsetTimeOrder with in Table 127 the following: AttributeIdentifierTypeRangeDescriptionDefault macOffsetTimeSlotInteger1-15Specification of the duration between the coex-beacon and the preceding periodic beacon. 15

doc.: IEEE g TG4g Presentation CID , 1754, 1755 (1/2) July 2010 C.S. SumSlide 13 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 7 th 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 [b 5 b 4 b 3 b 2 b 1 b 0 ] in length, where [b 5 b 4 ] specify the PHY type of the source PAN and [b 3 b 2 b 1 b 0 ] 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.”

doc.: IEEE g TG4g Presentation CID , 1754, 1755 (2/2) July 2010 C.S. SumSlide 14 Bits [b 5 b 4 ]PHY TypeBits [b 3 b 2 b 1 b 0 ]Symbol Rate 00MR-FSK OFDM O-QPSK Reserved Reserved Resolution 2: Update figure 92b accordingly to Resolution 3 Resolution 3: Modify Table 121a as below

doc.: IEEE g TG4g Presentation 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 layer. The set of octets contained in macCoexBeaconPayload shall be copied to this field.” July 2010 C.S. SumSlide 15

doc.: IEEE g TG4g Presentation CID 1757, 1758 (2/2) AttributeIdentifierTypeRangeDescriptionDefault macCoexBeaconPayloadSet of octets --The contents of the coex-beacon payload. NULL macCoexBeaconPayloadLengthInteger0 - aMaxBeaconPayloa dLength The length, in octets, of the coex-beacon payload. 0 July 2010 C.S. SumSlide 16 Resolution 2: Add the below MAC PIB attributes into Table 127

doc.: IEEE g TG4g Presentation CID 1727, 1640 (1/2) Comment: Maximum coex-beacon interval is too long. Response: Shorten the maximum coex-beacon interval. Resolution 1: Replace the 5 th 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. July 2010 C.S. SumSlide 17

doc.: IEEE g TG4g Presentation CID 1727, 1640 (2/2) Resolution 3: Replace MAC PIB attribute “macCoexBeaconOrder” in Table 127 as below: July 2010 C.S. SumSlide 18 AttributeIdentifierTypeRangeDescriptionDefault macCoexBeaconOrderInteger0-15Specification of how often the coordinator transmits its coex-beacon. If macCoexBeaconOrder=15, no coex-beacon will be transmitted. 0

doc.: IEEE g TG4g Presentation CID 1575, 1639, , 1660, (1/5) 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 a new subfield into the coex-beacon frame: “NBPAN Coex-beacon Order” July 2010 C.S. SumSlide 19

doc.: IEEE g TG4g Presentation CID 1575, 1639, , 1660, (2/5) Resolution 2: Add a paragraph into subclause a.2, as the blue text below: –“If Beacon Order is set to 15, the Superframe Order, Final CAP Slot, Offset Time Order subfields shall be ignored.” Resolution 3: Add a paragraph into subclause a.2, as the blue text below: –“The NBPAN Coex-beacon Order 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 July 2010 C.S. SumSlide 20

doc.: IEEE g TG4g Presentation CID 1575, 1639, , 1660, (3/5) 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 by the NBPAN Coex-beacon Order, macNBPANCoexBeaconOrder (CBO NBPAN ). The resolution of time shall be aNBPANSlotDuration. The values of CBO NBPAN and NBPAN coex- beacon interval (CBI NBPAN ) are related as follows: CBI NBPAN = aNBPANSlotDuration * CBO NBPAN symbols.” July 2010 C.S. SumSlide 21

doc.: IEEE g TG4g Presentation CID 1575, 1639, , 1660, (4/5) Resolution 6: Replace MAC PIB attribute “macCoexBeaconOrderNBPAN” in Table 127 as below: Resolution 7: Add the following MAC sublayer constant in Table 85 July 2010 C.S. SumSlide 22 ConstantDescriptionValue aNBPANSlotDurationThe number of symbols forming a the minimum time resolution in a non-beacon-enabled PAN aBaseSlotDuration AttributeIdentifierTypeRangeDescriptionDefault macNBPANCoexBeaconOrderInteger0-255Specification of how often the coordinator transmits its coex- beacon in a non- beacon-enabled PAN (i.e. BeaconOrder=15). 255

doc.: IEEE g TG4g Presentation CID 1575, 1639, , 1660, (5/5) Resolution 8: Replace the last paragraph in subclause 7.5.8c 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. Any incoming potential coordinator shall first scan for the coex-beacon for twice the duration of the maximum interval of the CBI NBPAN or until one is detected, which ever is longer in time. The illustration of the procedure is given in figure 112c.” July 2010 C.S. SumSlide 23

doc.: IEEE g TG4g Presentation 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. Any incoming potential coordinator shall first scan for the coex-beacon for the maximum duration of the CBI or until one is detected, which ever is longer in time. If an incoming…” July 2010 C.S. SumSlide 24