doc.: IEEE 802.22

November 2006
doc.: IEEE 802.22-06/0236r0
IEEE P802.22
Wireless RANs
Draft Minutes of the 802.22.1 Conference Call Held on November
7, 2006 at 10:00 PM EST
Date: 2006-11-07
William Rose
WJR Consulting Inc.
3 Tunxis Road, West Hartford
CT 06107
860 313-8098
Draft Minutes of the 802.22.1 Conference Call Held on November 7, 2006 at 10:00 PM EST.
Notice: This document has been prepared to assist IEEE 802.22. 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 grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution,
and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE
Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit
others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and
accepts that this contribution may be made public by IEEE 802.22.
Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures
<>, including the statement "IEEE standards may include the known
use of patent(s), including patent applications, provided the IEEE receives assurance from the patent holder or applicant with
respect to patents essential for compliance with both mandatory and optional portions of the standard." Early disclosure to the
Working Group of patent information that might be relevant to the standard is essential to reduce the possibility for delays in
the development process and increase the likelihood that the draft publication will be approved for publication. Please notify
the Chair <Carl R. Stevenson> as early as possible, in written or electronic form, if patented technology (or technology under
patent application) might be incorporated into a draft standard being developed within the IEEE 802.22 Working Group. If you
have questions, contact the IEEE Patent Committee Administrator at <>.
page 1
William Rose, WJR Consulting Inc.
November 2006
doc.: IEEE 802.22-06/0236r0
Approve Agenda
Review and Approve Minutes
There are no minutes to approve at this time.
Create agenda for Dallas meetings
Discussions on Open Item/Action Item List
Prioritized List:
1) We need a defined quiet period from 802.22 for sensing period.
Any further design of the burst length, parsing of data sent, etc. is dependant upon knowing this
2) Security needs to be addressed in more detail.
This defines the data, which needs to be sent as well as the overall operation of the beacon.
3) The Samsung proposals must be considered. The increased data capacity from complex
modulation has many supporters.
There are also additional proposals from Samsung, and new proposals from others, which we
must consider on a priority basis – this work must be completed so that the rest of the open items
can be properly addressed. There are recently additional proposals that must also be
considered. The final modulation method (complex modulation, data organization, data rate,
spreading) must be defined to continue defining data fields, etc.
4) Is TG1 required to include a source and MAC address in its payload under IEEE 802? Is TG1
required to be a 2-way network under IEEE 802?
I suggest that we move away from a callsign approach, which uses 8 octets to send the
information, to use of a 48 bit unique MAC address which can be tied / associated to a callsign or
entity. This also removed the problem that video production studios do not have callsigns, per se,
yet get protection. This saves 2 octets; defines the necessary data field so that other reduction of
data / organization of data can take place.
5) Determine if the payload can be shortened, or if this is needed, for VoIP reasons.
This is in process; need to finalize data set.
6) If the WRAN is able to capture one “blip” and then schedules future windows, perhaps the
10mSec could be met – needs further discussion.
It seems that less than 10mSec is not feasible simply from the authentication requirement. I
believe the question we need to ask is how long can this period be (15, 20mS?) before it affects
what should be termed as “acceptable” performance vs. “perfect” performance. Once that is
decided, any fracturing of the dataset can be considered.
7) We have defined sub-bands as a grouping of UHF TV channels, such as 14 – 20, 21 – 28, 29 –
36, etc. that may reduce the payload and make beacon manufacture easier. We also determined
the sub-bands should be a percentage of overall bandwidth, not a linear grouping.
8) We have defined sub-channels as increments, such as 200kHz, within a TV channel. Raster to be
9) We need to have further consideration of how many beacons should continue to operate long term
at a given location. Sub-bands may affect this; it has been suggested that one may be too few, but
one on every channel is too much.
10) Begin work on recommended practice document.
This will lead to resolving the remaining issues to date:
a. Should issues that fall outside of the phy/mac be referred to a recommended practice or to an
page 2
William Rose, WJR Consulting Inc.
November 2006
doc.: IEEE 802.22-06/0236r0
b. Tradeoff between operating a beacon in close proximity to microphone receiver versus the
number of beacons operating on distinct channels and the possiblity of the beacon using the lower
edge of the channel to take advantage of a WRAN sensing scheme that uses the edge carriers of
the channel to sense.
c. Recommended minimum distance between the beacon and the microphone receiver (annex?)
d. There may be a reason to have separate WRAN and Interbeacon payloads sent by a beacon. The
WRAN only needs channel information whereas other beacons may need subchannel
Other Business
Note: The dial-information has changed. Please see dial-in information attached to the email along
with this agenda.
Next Meeting: The next meeting will be held in Dallas TX, at the IEEE Plenary meetings. 802.22.1
will be meeting from Monday – Thursday 11/13-16 in the PM2 time slot, and in the evening on
Thursday 11/16.
Bill Rose (Chair)
Monique Brown
Gerald Chouinard
Chris Clanton
Steve Kufner
Jerry Kalke
David Mazzarese
Chris Babarskas
The agenda was approved without change.
There were no minutes to approve.
Create Agenda for Dallas Plenary Meetings
Following a discussion, the following agenda was developed:
Approve Agenda
Approve minutes of the Oct 31st and November 7th conference calls.
Presentation on changes to current draft – Greg Buchwald or designee
Presentation and discussion on proposed revisions (30 minutes maximum for each
NOTE: Any presentations representing a proposed major revision and requiring separate
consideration shall be made available by 5:00 PM EST Friday 10th. Such presentations
may be revised at any time up to 12:00 noon on Monday 11/13/06.
NOTE: The only presentations that have been submitted or that TG1 has been made
aware of at this time are from Samsung and Huawei. If there are others, please let TG1 or
page 3
William Rose, WJR Consulting Inc.
November 2006
doc.: IEEE 802.22-06/0236r0
the chair know as soon as possible so it can be scheduled. Also note the deadline for
submitting initial presentations (see note above).
NOTE: TG1 members have discussed that having simulations available for review (for
those proposed revisions that may benefit from simulations) is important to enable a
decision to be made. Simulations need to be made available before agenda item 7 –
“Accept or reject proposed revisions”.
Discussion on Open Items/Action Items (Prioritized List)
First item to discuss: Discuss tradeoffs on the length of the quiet period and report to
Open Discussion: Accept or reject proposed revisions
Review Resulting draft document
Schedule/Next Steps
Schedule conference calls
Other business
Discussions on Open Item/Action Item List
The prioritized list of items was discussed. There were no actions taken on the first 4 items other than
to agree (previously discussed and generally agreed to) that the MAC address would be used (item 4).
Item 5 was discussed at length.
Determine if the payload can be shortened, or if this is needed, for VoIP and quiet period reasons.
This is in process; need to finalize data set.
Discussion: If the quiet period exceeds a single frame period (10 msec), the complexity will increase.
The following action item for the 802.22 WG was generated (Bill Rose):
Action Item: What is the 802.16 specification for VoIP latency?
Adjourn: The conference call was abruptly ended at 11:15 PM EST, by the loss of the conference call
leader on the call.
page 4
William Rose, WJR Consulting Inc.