Nov 2008 doc IEEE 802 15 08 0760

Nov, 2008 doc. : IEEE 802. 15 -08 -0760 -00 -003 c Project: IEEE P 802. 15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Resolution to comment #110, 111] Date Submitted: [Nov-10 -2008] 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. 3 c standard] Notice: This document has been prepared to assist the IEEE P 802. 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 P 802. 15. Submission Slide 1 Qualcomm

Nov, 2008 doc. : IEEE 802. 15 -08 -0760 -00 -003 c Comment #110 • sync frame is only mandated for PNC which is not providing a good enough solution for hidden nodes problem. • Commenter suggested Resolution: – add sync frame as optional for dev to allow for faster scan of PNC candidate and better interference mitigation between neighboring piconets. Submission Slide 2 Qualcomm

Nov, 2008 doc. : IEEE 802. 15 -08 -0760 -00 -003 c Current Common Mode Sync Frame Rules • In order to promote coexistence among DEVs using different PHYs, the following MAC rules have defined. – An AV PNC-capable DEV, when operating as a PNC, shall transmit an AV beacon and a CMS sync frame in every superframe. – An HSI PNC-capable DEV, when operating as a PNC, shall transmit either an HSI beacon and a CMS sync frame in every superframe. – An AV PNC-capable DEV shall be able to receive the CMS sync frame and command frames. – An HSI PNC-capable DEV shall be able to receive the CMS sync frame and command frames. • The current 802. 15. 3 c procedure does not provide adequate answer to the hidden node problem and to maintaining lasting synchronization and avoiding interference between independent networks. Submission Slide 3 Qualcomm

Nov, 2008 doc. : IEEE 802. 15 -08 -0760 -00 -003 c Hidden node Interference Illustration • There is not enough link margin for the PNC 1 to PNC 2 link for common mode. No LOS link because of metal object blocking • When DEV 1 is transmitting, the interference at DEV 2 limits the SNR to 2 d. B, much lower than the required 10 d. B. • The PNC 2 -DEV 2 link has additional 13 d. B link margin for ~3 Gbps data rate. PNC 2 is unaware of DEV 1 interference, except for throughput drop due to interference. • There is over 26 d. B link margin for the PNC 1 to PNC 2 link for common mode. Submission Slide 4

Nov, 2008 doc. : IEEE 802. 15 -08 -0760 -00 -003 c Hidden node Interference Suggested Resolution • In the case of 802. 15. 3 c device, each device capable of sending sync frames is required to send a synchronization packet at the first time its get allocation to transmit in a superfarame, every pre-defined number of superframes for pre-define directions. Submission Slide 5 Qualcomm

Nov, 2008 doc. : IEEE 802. 15 -08 -0760 -00 -003 c Virtually Dependent Piconets • • The drawing illustrates “virtually dependent piconets”, which are synchronized. By maintaining synchronization between neighbouring piconets, interference remains constant in the time domain and can be masked. Even though PNC 2 is not seeing PNC 1 sync frame, so it can not create a dependent piconet, it is using DEV 1 C and DEV 2 C synchronization packets to synchronize to PNC 1 timing and forming a virtually dependent piconet. PNC 2 schedules data transfers for devices members in its on piconet and avoid interference between the two piconets. Submission Slide 6 Qualcomm

Nov, 2008 doc. : IEEE 802. 15 -08 -0760 -00 -003 c Conclusion • DEV Sync frames increase the chance for overcoming hidden node problem. – Make sync frame optional for DEV • Device publishes sync frame transmit capability • PNC controls the sync frame distribution by setting the number of superframes between sync. Frames and defining directions, if that DEV is capable of sync frame transmission • Virtually dependent piconents enables masking of interference time allocation by neighboring piconet devices and avoiding throughput hit. Submission 7 Qualcomm

Nov, 2008 doc. : IEEE 802. 15 -08 -0760 -00 -003 c Comment #111 • Sync frame is not defined for DEV. • Commenter suggested Resolution: – add sync frame as optional for dev and define rules for new Sync_frame_capability_IE and for Sync_frame_control IE. Submission Slide 8 Qualcomm

Nov, 2008 doc. : IEEE 802. 15 -08 -0760 -00 -003 c Suggested optional Sync. Frame Transmission function • Sync frame Support: – DEV reports sync frame transmit capability during association – PNC controls the sync frame distribution by setting the number of superframes between sync. frames and defining directions using Sync_frame_frequency IE in a Announce command, if that DEV is capable of sync frame transmission • Sync frame scheduling: – If requested by the PNC, a DEV sends a sync frame at the first time its get CTA to transmit in a superframe, every pre-defined number of superframes for pre-define directions as indicated in Sync_frame_frequency IE Submission Slide 9 Qualcomm

Nov, 2008 doc. : IEEE 802. 15 -08 -0760 -00 -003 c Suggested Changes to D 02 • Capability_IE (Section 7. 4. 11) – Add a new bit assignment in DEV capabilities field • Bit 36: Sync_frame_capable • Sync_frame_frequency_IE – Add Section 7. 4. 36 “Sync Frame Frequency IE” Octets: 1 Reserved (2 bits) Sync frame direction Sync frame frequency (5 bits) 1 1 Length Element ID – Sync frame frequency field indicates the number of superframes between two Sync frame transmission requested by PNC – Sync frame direction bit indicates if the Sync frame transmission is omni or directional • If directional, sync frame direction is round robin of DEV available directions Submission Slide 10 Qualcomm

Nov, 2008 doc. : IEEE 802. 15 -08 -0760 -00 -003 c Suggested Changes to D 02 (cont. ) • Add new subclause 8. 17 “Sync. Frame Transmission and Virtually Dependent Piconets” – “Sync. Frame Transmission is an optional function that mitigates co-channel interference due to hidden PNC node. It also provides a method to obtain synchronization among independent piconets. To use Sync. Frame Transmission, a DEV needs to report sync frame transmit capability to PNC during association procedure. – PNC controls the sync frame distribution of a DEV by setting the number of superframes between sync. frames using Sync_frame_frequency IE, as defined in 7. 4. 36, in a Announce command, if that DEV is capable of sync frame transmission. – Requested by the PNC, a DEV sends a sync frame at the first time its get CTA to transmit in a superframe, every pre-defined number of superframes for pre-define directions as indicated in Sync_frame_frequency IE. – The sync frame shall be transmitted using CMR – Device can use either data or Imp-ACK allocations for Sync. frame transmission – A scanning DEV, upon receiving a Sync. Frame, may utilize the embedded information to obtain network synchronization and mitigate interference. – Even though one PNC is not seeing the other PNC sync frame, it can use the Sync. Frames it receives from devices members of this other PNC, to synchronize to PNC timing and forming a “virtually dependent piconet”. This “virtually dependent PNC” may then schedule data transfers for devices members in its own piconet and avoid interference between the two piconets. ” Submission Slide 11 Qualcomm

Nov, 2008 doc. : IEEE 802. 15 -08 -0760 -00 -003 c Suggested Changes to D 02 (cont. ) • Add text to 12. 1. 8 Requirements for mm. Wave PNCs: – Submission All DEV capable of sync frame transmission shall transmit a sync frame at the first time its get CTA to transmit in a superframe, every pre-defined number of superframes for pre -define directions as indicated in Sync_frame_frequency IE 12

Nov, 2008 doc. : IEEE 802. 15 -08 -0760 -00 -003 c Backup Submission 13

Nov, 2008 doc. : IEEE 802. 15 -08 -0760 -00 -003 c Annex 1: example of Sync Frame exchange procedure Beacon DEV 1 A to DEV 1 C CTA for DEV 1 A to DEV 1 C CAP Sync Frame SIFS DEV 1 C to DEV 1 A ACK policy set to Imp-ACK • • • Submission CTA for PNC 1 to DEV 1 C CTA for DEV 1 A to DEV 1 B Normal data Sync Frame Normal data SIFS When the first time the CTA for DEV 1 A to transmit to DEV 1 C arrives, DEV 1 A sends a Sync Frame with ACK policy set to Imp-ACK DEV 1 C, upon receiving the Sync Frame, waits for SIFS and replies back Sync Frame to extend the possible coverage range of Sync Frame After the Sync frame exchange, normal frame transmission carries on Slide 14 14 Qualcomm