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 Author(s): Name William Rose Company WJR Consulting Inc. Address 3 Tunxis Road, West Hartford CT 06107 Phone 860 313-8098 email brose@wjrconsultingi nc.com Abstract 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 <http://standards.ieee.org/guides/bylaws/sb-bylaws.pdf>, 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 <firstname.lastname@example.org>. Submission page 1 William Rose, WJR Consulting Inc. November 2006 doc.: IEEE 802.22-06/0236r0 Agenda 1. Attendance 2. Approve Agenda 3. Review and Approve Minutes There are no minutes to approve at this time. 4. Create agenda for Dallas meetings 5. 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 specification. 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 determined. 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 annex? Submission 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 information. 6. Other Business 7. Note: The dial-information has changed. Please see dial-in information attached to the email along with this agenda. 8. 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. 9. Adjourn Minutes: 1. Attendance Bill Rose (Chair) Monique Brown Gerald Chouinard Chris Clanton Steve Kufner Jerry Kalke David Mazzarese Chris Babarskas 2. The agenda was approved without change. 3. There were no minutes to approve. 4. Create Agenda for Dallas Plenary Meetings Following a discussion, the following agenda was developed: 1. Attendance 2. Approve Agenda 3. Approve minutes of the Oct 31st and November 7th conference calls. 4. Presentation on changes to current draft – Greg Buchwald or designee Presentation and discussion on proposed revisions (30 minutes maximum for each presentation) 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 Submission 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”. 5. 6. 7. 8. 9. 10. 11. 5. Discussion on Open Items/Action Items (Prioritized List) First item to discuss: Discuss tradeoffs on the length of the quiet period and report to 802.22 Open Discussion: Accept or reject proposed revisions Review Resulting draft document Schedule/Next Steps Schedule conference calls Other business Adjourn 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? 6. Adjourn: The conference call was abruptly ended at 11:15 PM EST, by the loss of the conference call leader on the call. Submission page 4 William Rose, WJR Consulting Inc.