Slide 1

1. Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Resolution to comment #] Date Submitted: [May-10-2009] Source: [Vered Bar] Company: [Qualcomm] Address: [QUALCOMM, Incorporated, 5775 Morehouse Drive, San Diego, CA 92121] Voice: [], FAX: [], E-Mail:[vbar@qualcomm.com] Re: [] Abstract: [Comment resolutions.] Purpose: [To be considered in IEEE 802.15.3c standard] 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. Qualcomm Slide 1

2. 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. • Suggested Resolution • 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 Comment #76, 113 Qualcomm Slide 2

3. 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. • Suggested Resolution • Need improvement. • Use directional RTS/CTS fro DEV to Dev communication Comment #75, 112 Qualcomm Slide 3

4. 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. Updated Rules for Device-to-device communication in the Regular-CAP Qualcomm Slide 4

5. Updated Rules for mmWave PHY • DEV trying to access the medium in CAP, shallalways 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

6. Drawings Directional transmission w/o training Qualcomm

7. 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. Empty CMS Frame Format Qualcomm

8. 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 Comment #77 Qualcomm

9. 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 Comment #78 Qualcomm Slide 9

10. 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 Using fragmentation Control for Medium Busy Duration Indication Fragmentation field for empty CMS frame Qualcomm

11. Another possible mechanism to introduce power save mechanism in the 802.15.3c 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. Using (new) Duration IE for Medium Busy Duration Indication Duration IE format Qualcomm

12. Drawings Directional transmission w/ Duration Qualcomm

13. 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 Comment #79 Qualcomm Slide 13

14. 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. Using CMS for CCA Qualcomm