1. <January 2002>
doc.: IEEE <02/139r0>
July, 2008
Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs)
Submission Title: [Resolution to comment #585]
Date Submitted: [Sep ]
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 , Japan*
10875 Rancho Bernardo Rd, #108, San Diego, CA ;]
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. 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

3. Current Common Mode Beacons Rules
The c 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 c 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
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

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 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 (including allocation for ACK packet) in a superfarame, every pre-defined number of superframes.
Qualcomm

6. 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

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

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 , 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

12. Suggested Changes to D00 (cont.)
Change text to 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
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

16. 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