<January 2002> doc.: IEEE 802.15-<02/139r0> July, 2008 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. Slide 1 Qualcomm Chuck Brabenac, Intel Labs

July, 2008 Comment #585, OTHERS ..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 Slide 2 Qualcomm

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

Hidden node Interference Problem July, 2008 Hidden node Interference Problem 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 Slide 4 Qualcomm

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

Hidden node Interference Resolution (1) July, 2008 Hidden node Interference Resolution (1) 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. Slide 6 Qualcomm

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, every pre-defined number of superframes as indicated in Sync_frame_frequency IE The sync frame shall be transmitted using CMR Qualcomm

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

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

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 Octets:1 1 Sync frame frequency Length Element ID Qualcomm

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, every pre-defined number of superframes 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

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

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

Backup

Annex 1: example of Sync Frame exchange procedure July, 2008 Annex 1: example of Sync Frame exchange procedure Beacon CAP CTA for DEV1A to DEV1C CTA for PNC1 to DEV1C CTA for DEV 1A to DEV1B DEV1A to DEV1C Sync Frame M Normal data SIFS Normal data SIFS Sync Frame M I-ACK SIFS DEV1C to DEV1A 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 Slide 15 Qualcomm

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