Slide 1

1. Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Resolution to comment #585] Date Submitted: [Sep-11-2008] Source: [Vered Bar, Zhou Lan*, Fumihide Kojima*, Chang woo Pyo*,Hiroshi Harada*, Shuzo Kato*, Ismail Lakkis+, ] Company: [Qualcomm,NICT*, Tensorcom+] Address: [QUALCOMM, Incorporated, 5775 Morehouse Drive, San Diego, CA 92121 3-4 Hikari-no-oka, Yokosuka-shi, Kanagawa 239-0847, Japan* 10875 Rancho Bernardo Rd, #108, San Diego, CA 92127+;] Voice: [], FAX: [], E-Mail:[vbar@qualcomm.com, lan@nict.go.jp*] 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. ..There is no requirement that ALL non-SC DEVs be able to receive a beacon sent using the common rate and derive super-frame timing from it. So, it is unclear that the MMC PNC really "mitigates potential interference among DEVs operating in different PHY modes". • Commenter suggested Resolution: • Require that all DEVs be able to receive common-rate beacons and derive super-frame timing. Require that all PNCs be able to transmit common-rate beacons. • Other relating comments on common RX/TX usage and piconet synchronization Comment #585, OTHERS Qualcomm Slide 2

3. Current Common Mode Beacons Rules The 802.15.3c DF00 draft amendment defines some MAC rules in order to promote coexistence among DEVs using different PHYs: All PNC capable device, when operating as PNC shall transmit common rate beacon in every superframe. All PNC capable DEVs shall be able to receive the common rate beacon and command frames. The current 802.15.3c procedure does not provide adequate answer to the hidden node problem and to maintaining lasting synchronization and avoiding interference between independent networks. Qualcomm

4. Hidden node Interference Problem July, 2008 The drawing illustrates interference caused by independent piconets which are not synchronized. Interference is due to PNC2 not seeing PNC1 beacons, and forming an independent piconet. DEV 1C and DEV 1D are members of piconet1 and are not members of piconet2, but they are in range of piconet2 transmission. DEV 1C and DEV1D cause and experience interference with piconet2 members, including PNC2, since the two piconets transmissions are not synchronized Qualcomm Slide 4

5. Hidden node Interference Suggested Resolution Using unified synchronization frames sent periodically by each node (i.e, PNC / DEV) of each network. Each node is required to periodically scan and detect the synchronization frames. Each synchronization packet also includes time stamp for allowing timing synchronization and handling hidden nodes. This frame could be part of a beacon or data frame. In the case of 802.15.3c device, each device capable of sending sync frames is required to send a synchronization packet at the first time its get allocation to transmit (including allocation for ACK packet) in a superfarame, every pre-defined number of superframes. Qualcomm

6. Hidden node Interference Resolution (1) July, 2008 The drawing illustrates “virtually dependent piconets”, which are synchronized. Even though PNC2 is not seeing PNC1 beacons, it is using DEV 1C and DEV 2C synchronization packets to synchronize to PNC1 timing and forming a virtually dependent piconet. PNC2 schedules data transfers for devices members in its on piconet and avoid interference between the two piconets. Qualcomm Slide 6

7. 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 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, everypre-defined number ofsuperframes as indicated in Sync_frame_frequency IE The sync frame shall be transmitted using CMR Qualcomm

8. Suggested optional Sync. Frame Transmission function (cont.) Sync frame format: This synchronization frame has the same size and very similar format to the 802.15.3c CMS(Common Mode Signaling) beacon frame. Since CMR beacon is always transmitted by the PNC on t=0 of the superframe, and the synchronization frame timing is not fixed, a new field is introduced in the synchronization parameters. This field provides the time stamp for the synchronization frame and marks the synchronization frame preamble start time. Qualcomm

9. Sync Frame Suggested Format CR Synchronization Frame format (new frame type: 0b110) Synchronization Frame Body format Synchronization parameters field format Difference from beacon Qualcomm

10. Suggested Changes to D00 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” Sync frame frequency field indicates the number of superframes between two Sync frame transmission requested by PNC Qualcomm

11. Suggested Changes to D00 (cont.) Add new subclause 8.18 “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, everypre-defined number ofsuperframes as indicated in Sync_frame_frequency IE. The sync frame shall be transmitted using CMR Device can use either data or 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 beacons, 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. ” Qualcomm

12. Suggested Changes to D00 (cont.) Change text to 8.16.2.2 Additional PNC rules:

13. Conclusion Virtually dependent piconents enables avoiding interference caused by hidden PNC nodes. Sync frames increase the chance for network synchronization. Make sync frame optional Device publishes sync frame transmit capability PNC controls the sync frame distribution by setting the number of superframes between sync. frames Qualcomm

14. Backup

15. Annex 1: example of Sync Frame exchange procedure July, 2008 When the first time the CTA for DEV1A to transmit to DEV1C arrives, DEV1A sends a Sync Frame before sending data frames destination DEV1C DEV1C, upon receiving the data frame, waits for SIFS and then sends a Sync Frame to extend the possible coverage range of Sync Frame before sending ACK packets destination DEV1A After the Sync frame exchange, normal frame transmission carries on CTA for DEV1A to DEV1C CTA for PNC1 to DEV1C CTA for DEV 1A to DEV1B CAP Beacon SIFS Normal data Normal data DEV1A to DEV1C Sync Frame M SIFS SIFS I-ACK Sync Frame M DEV1C to DEV1A Qualcomm Slide 15

16. Annex 2: example of Sync Frame exchange procedure July, 2008 When the first time the CTA for DEV1A to transmit to DEV1C arrives, DEV1A sends a Sync Frame with ACK policy set to Imp-ACK DEV1C, 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 CTA for DEV1A to DEV1C CTA for PNC1 to DEV1C CTA for DEV 1A to DEV1B CAP Beacon DEV1A to DEV1C Sync Frame SIFS Normal data Normal data Sync Frame SIFS DEV1C to DEV1A ACK policy set to Imp-ACK Qualcomm Slide 16