| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi Mariana, Thanks for your contribution of
information for inclusion of the CXCBP feature to the 802.19 simulation
parameters document. Due to the volume of material over a
number of email threads I feel the best way to proceed is for you to prepare a
contribution for the next 802.19 conference call (8a PT 6 September). In this
way everyone will have an opportunity to review the material, understand the
content, ensure a correct interpretation of the material for inclusion, and see
where your proposed text is to be added to the current document structure. Many thanks, Paul. From: Mariana
Goldhamer [mailto:marianna.goldhammer@alvarion.com] Hi Paul, The implementation of the synchronization
is a product issue and it is not related to MAC and PHY, so I do not expect it
in 802.11y. I've found a way to live with the existing 1.024ms time base for
the 802.11 inter-beacon interval – see below. If the "quiet
elements" are supported we should be ok. 802.15
has already considered the synchronized separation in its 802.11-802.15
recommended practice document Part 15.2: Coexistence of Wireless
Personal Area Networks with Other Wireless Devices Operating in Unlicensed
Frequency Bands They
have a similar recommendation there - see clause 5. Alternating wireless medium
access. Assuming
the AP product implements the synchronization and keeps sending the beacons at
the start of the CXCBI, here down is a list of possible 802.11y settings such
to use the CX-CBP (I've noted in 11.9.2 of the 802.11 standard: "Multiple
independent quiet intervals may be scheduled, to ensure that not all quiet
intervals have the same timing relationship to TBTT, by including multiple
Quiet elements in Beacon frames or Probe Response frames".) : List of recommended
802.11y parameters and product implementation
4. Quiet elements (see 11.9.2 Quieting channels for testing
and 7.3.2.23 Quiet element), to schedule the quiet interval such to overlap
with the CXSBI intervals
i.
Quiet element no. 1 1.
Quiet count =1 (start during next
beacon) 2.
Quiet period =1 (in every beacon
interval) 3.
Quiet offset = 9 (9*1.024=
9.216ms) 4.
Quiet duration = 11 (11*1024 =
11.26ms)
ii.
Quiet element no. 2 1.
Quiet count =1 2.
Quiet period =1 (in every beacon
interval) 3.
Quiet offset = 29 (29*1.024=
29.7ms) 4.
Quiet duration = 10 (10*1.024 =
10.24ms)
iii.
Quiet element no. 3 1.
Quiet count =1 2.
Quiet period =1 (in every beacon
interval) 3.
Quiet offset = 48 (48*1.024=
49.152ms) 4.
Quiet duration = 11 (11*1.024 =
11.26ms)
iv.
Quiet element no. 4 1.
Quiet count =1 2.
Quiet period =1 (in every beacon
interval) 3.
Quiet offset = 68 (68*1.024=
69.63ms) 4.
Quiet duration = 10 (10*1.024 =
10.26ms)
v.
Quiet element no. 5 1.
Quiet count =1 2.
Quiet period =1 (in every beacon
interval) 3.
Quiet offset = 87 (87*1024=
89.08ms) 4.
Quiet duration = 11 (11*1.024 =
11.26ms)
vi.
Quiet element no. 6 1.
Quiet count =1 2.
Quiet period =1 (in every beacon
interval) 3.
Quiet offset = 107 (107*1024=
109.57ms) 4.
Quiet duration = 10 (10*1.024 =
10.26ms). We should be open to
improvements resulting from simulations or better 802.11 knowledge. Regards, Mariana From: Hi Steve, I can make this change - however I have a
question related to this following on from last Thursday’s call. LE TG Contribution 070, the Coordinated
CBP, expects 802.11 to respect the 802.16 frame structure. Mariana mentioned on the call that all the
802.11 features required to support this were in place. Mariana pointed to an
earlier contribution from the last 16h/11y joint meeting in Many thanks, Paul. From: Shellhammer, Steve
[mailto:sshellha@qualcomm.com] Mariana,
Thanks.
Paul, please update your document with text and reference for both the material
from Eldad and Marianna. That way it is all located on one place. Steve From: Mariana
Goldhamer [mailto:marianna.goldhammer@alvarion.com] Hi Eldad, Thanks for this information. The Coordinated CBP is described in draft
802.16h – D2c starting at page 122 (accessible with the 802.11 and 802.19
password at http://www.ieee802.org/16/pubs/80216h.html
) and it is also contained in my July contribution http://www.ieee802.org/16/le/contrib/C80216h-07_070.pdf. Regards, Mariana From: Perahia, Eldad
[mailto:eldad.perahia@intel.com] Regarding discussion of the Coordinated
Contention Based Protocol: In 11yD4.0 (http://grouper.ieee.org/groups/802/11/private/Draft_Standards/11y/Draft%20P802.11y_D4.0.pdf)
subclause J.2 states “All stations shall use Multi-Domain capability
(dot11MultiDomainCapabilityEnabled true), Spectrum
Management capability (dot11SpectrumManagementRequired true), Regulatory
Classes (dot11RegulatoryClassesRequired true), Supported Regulatory Classes and
Extended Channel Switch Announcement (dot11ExtendedChannelSwitchImplemented
true), and shall not use Channel Switch Announcement. dot11SpectrumManagementRequired true makes
mandatory in IEEE 802.11-2007 the functions in subclause 11.8 TPC and 11.9
DFS. 11.9.2 Quieting channels for testing – describes the mechanism
in which an AP may schedule quiet intervals. The Quiet element is defined
in subclause 7.3.2.23. Within the Quiet element is the Quiet Duration
which is a two octet field, expressed in TUs. In 802.11, a TU is defined
as time unit and is equal to 1024 usec. Regards, Eldad From: Shellhammer,
Steve [mailto:sshellha@qualcomm.com] All,
We will be having a conference call on Coexistence
in the 3650 MHz Frequency Band on Thursday at 11 AM Eastern Time (8
AM Pacific Time). If anyone has any additional items for the agenda
please notify me. Agenda
TO ATTEND THE AUDIO
CONFERENCE: 1. Call +1 858-845-5000 2. After the greeting press 1 to
attend meeting. 3. Enter Meeting ID 80219 4. Enter Meeting Password 80219 followed by the # sign. 5. Follow the remaining prompts for
recording the callers name and joining the meeting. For assistance, dial #0 at any time. Steve ************************************************************************************ This footnote confirms that this email message has been scanned by PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses(190). ************************************************************************************ ************************************************************************************ This footnote confirms that this email message has been scanned by PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses(43). ************************************************************************************ ************************************************************************************ This footnote confirms that this email message has been scanned by PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses(43). ************************************************************************************ ************************************************************************************ This footnote confirms that this email message has been scanned by PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses(190). ************************************************************************************ ************************************************************************************ This footnote confirms that this email message has been scanned by PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses(42). ************************************************************************************ ************************************************************************************ This footnote confirms that this email message has been scanned by PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses(42). ************************************************************************************ |
image001.gif