1. <January 2002>
doc.: IEEE <02/139r0>
9/12/2018
Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs)
Submission Title: [Resolution to comment #]
Date Submitted: [May ]
Source: [Vered Bar]
Company: [Qualcomm]
Address: [QUALCOMM, Incorporated, 5775 Morehouse Drive, San Diego, CA 92121]
Voice: [], FAX: [],
Re: []
Abstract: [Comment resolutions.]
Purpose: [To be considered in IEEE c standard]
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
Slide 1
Qualcomm
Chuck Brabenac, Intel Labs

2. Comment #76, 113 Comment 76: Suggested Resolution Comment 113:
9/12/2018
Comment #76, 113
Comment 76: 
It would be desirable to define an ad-hoc communication using Regular -CAP while ensuring that antenna directions point to each other. If only allow device‐to‐device communication by reserving a CTA or directional CAP, the MAC efficiency could be very low particularly for data applications with very random and bursty traffic.
Suggested Resolution
define mechanism to ad-hoc  communication using  Regular -CAP while ensuring that antenna directions point to each other
Comment 113: 
The regular CAP as described supports slotted-aloha, directional CAP via division into multiple periods and CSMA/CA. There are too many incompatible modes.
Make the regular CAP a single period and a set of rules on how to use it.
It is recommended that devices should perform some level of beamforming before using the CAP.
Limit maximum size of packets in the CAP to say 2K octets (for example)
slotted operation
CSMA/CA as a best effort
with or without RTS/CTS
Slide 2
Qualcomm

3. Comment #75, 112 Comment 75: Suggested Resolution Comment 112:
9/12/2018
Comment #75, 112
Comment  75: 
S-CAP partitioning in directional peer communication in the regular CAP is ambiguous
Suggested Resolution
It should be clear if by allocating the regular CAP for peer to peer communication, the S-CAP division is no longer valid or suggest new mechanism for peer to peer communication over CAP
Comment 112:
DEV to DEV directional transmission in directional CAP is not well supported.
Need improvement.
Use directional RTS/CTS fro DEV to Dev communication
Slide 3
Qualcomm

4. Updated Rules for Device-to-device communication in the Regular-CAP
9/12/2018
Updated Rules for Device-to-device communication in the Regular-CAP
Basic Rules (8.4.2)
The basic medium access mechanism during the CAP is carrier sense multiple access with collision avoidance (CSMA/CA).
To minimize collisions, a transmitting DEV is required to first sense that the medium is idle for a random length of time.
The MAC shall use the CCA capabilities of the PHY to detect whether the channel is busy or idle
If there is insufficient time remaining in the CAP for the entire frame exchange sequence, then the DEV or the PNC shall not commence transmission of the frame
During the CAP a DEV is allowed to transmit one frame at a time with backoff being applied to every frame attempted during the CAP, except for the Imm-ACK frame.
Slide 4
Qualcomm

5. Updated Rules for mmWave PHY
<January 2002>
doc.: IEEE c
9/12/2018
Updated Rules for mmWave PHY
DEV trying to access the medium in CAP, shall always send (quasi) omni CMS frame first
DEV which obtain the medium for transmitting data in Phy mode other than CMS, shall transmit an empty (quasi) omni CMS frame before this data frame
Following the empty CMS frame, and optional training sequence, DEV is allowed to send data frame in any MCS supported by the CAP Phy mode.
Assuming that the best transmit pattern is known as a result of the beamforming, DEV (say DEV-1) shall use the best transmit pattern (sector or beam) toward the other DEV (say DEV-2)
If DEV-1 failed to obtain best transmit pattern, DEV-1 shall not commence transmission and apply backoff before attempting to re-gain medium.
Qualcomm
Chuck Brabenac, Intel Labs

6. Directional transmission w/o training
<January 2002>
doc.: IEEE c
9/12/2018
Drawings
Directional transmission w/o training
Qualcomm
Chuck Brabenac, Intel Labs

7. <January 2002>
doc.: IEEE c
9/12/2018
Empty CMS Frame Format
Device (say DEV-2) listening to the medium can obtain peer information (source ID, destination ID and stream index) from MAC header and decide if to keep it receiver open for the optional training sequence, and/or following data frame or to go back to listen mode, since the transmitting device is not any of it’s peers and/or DEV-2 is not the transmission destination.
Qualcomm
Chuck Brabenac, Intel Labs

8. Comment #77 Comment: Suggested Resolution
<January 2002>
doc.: IEEE c
9/12/2018
Comment #77
Comment: 
To allow for better efficiency in CAP, and since backoff is being applied to every frame attempted during the CAP, it would be desirable to allow for unidirectional standard aggregation data frames in CAP.
Suggested Resolution
Remove restriction of ACK policy to Imm-ACK and No-ACK and allow for Blk-ACK
Qualcomm
Chuck Brabenac, Intel Labs

9. Comment #78 Comment : Suggested Resolution
9/12/2018
Comment #78
Comment : 
There is no mechanism to indicate transmission duration in CAP, which leads to considerable power waste and poor co-existence.
Suggested Resolution
add duration indication to CAP transmission
Slide 9
Qualcomm

10. Using fragmentation Control for Medium Busy Duration Indication
<January 2002>
doc.: IEEE c
9/12/2018
Using fragmentation Control for Medium Busy Duration Indication
The 15.3 standard does not include power save mechanism, such as Network Allocation Vector (NAV) for informing listening devices of medium busy duration.
A possible improvement to this procedure is to reallocating the Fragmentation control field in the empty CMS frame to indicate duration information
DI bit is set to ‘1’ to indicate that bits 0-12 contain duration information
The Duration field contains the time in microseconds for which the medium is busy.
Maximum duration allocated is 8 mS, allowing for aggregated data frame of 256KB, while still maintaining a 8% FER in highest MCS
Fragmentation field for empty CMS frame
Qualcomm
Chuck Brabenac, Intel Labs

11. Using (new) Duration IE for Medium Busy Duration Indication
<January 2002>
doc.: IEEE c
9/12/2018
Using (new) Duration IE for Medium Busy Duration Indication
Another possible mechanism to introduce power save mechanism in the c CAP is to require that a DEV which obtain the medium for transmitting data in Phy mode other than CMS, shall transmit (quasi) omni command CMS frame before this data frame. 
This command frame shall include a new information element (DurationIE) in frame payload.
The Duration field contains the time in microseconds for which the medium is busy.
Maximum duration allocated is 8 mS, allowing for aggregated data frame of 256KB, while still maintaining a 8% FER in highest MCS.
Duration IE format
Qualcomm
Chuck Brabenac, Intel Labs

12. Directional transmission w/ Duration
<January 2002>
doc.: IEEE c
9/12/2018
Drawings
Directional transmission w/ Duration
Qualcomm
Chuck Brabenac, Intel Labs

13. Comment #79 Comment : Suggested Resolution
9/12/2018
Comment #79
Comment : 
CCA mechanism in CAP is not robust enough to support directional transmission, which leads to considerable power waste and poor co-existence.
Suggested Resolution
change CCA to support directional transmission in CAP
Slide 13
Qualcomm

14. <January 2002>
doc.: IEEE c
9/12/2018
Using CMS for CCA
The start of a valid CMS preamble sequence at a receive level equal to or greater than the minimum sensitivity for the CMS shall indicate medium busy with a probability of > 90% within 5 s.
The receiver CCA function shall in all circumstances report medium busy with any signal 20 dB above the minimum sensitivity for the CMS.
If a DEV ( say DEV-1) wishing to initiate transfer detects a CMS preamble during it’s listen-before-talk (backoff interframe space) period it refrains from transmitting and suspends it’s backoff counter according to the backoff algorithm. This device may also remain in receive mode during the CMS frame, to obtain peer information from MAC header and decide if to keep its receiver open for the optional training sequence, and/or following data frame or to go to listen mode, if the transmitting device is not any of it’s peers and/or DEV-1 is not the transmission destination.
The listening device may also decide to decode the optional training sequence and the Phy header of the following data frame, even if it is not the transmission destination to obtain frame duration. The listening device may then operate sleep mode for the duration of the frame (+ACK) transmission, to save power consumption.
Qualcomm
Chuck Brabenac, Intel Labs