IEEE P802.22 Wireless Rans s3

September 2008 doc.: IEEE 802.22-08/0274r0

IEEE P802.22 Wireless RANs

TG2 Meeting Minutes, September Interim, 2008

Date: 2008-09-10

Author(s): Name Company Address Phone email Christopher 5800 West Touhy Avenue Shure Inc. 847-600-8990 Clanton_christopher Clanton Niles, IL 60714 @shure.com Winston 10201 W. Pico Blvd. Fox 310-369-4367 Winston.caldwell@fo Caldwell Los Angeles, CA 90035 x.com

Abstract Minutes of the 802.22 TG2 meetings that occurred during the September 2008 802 Interim session in Kona, Hawaii.

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

Submission page 1 Christopher Clanton, Shure Inc September 2008 doc.: IEEE 802.22-08/0274r0

September 10, 2008 10:30 – 12:30 PM Meeting Minutes

The agenda is provided in document 22-08-0262-00-0002-tg2-agenda-sep-08.doc: 1. Review and approve the agenda. 2. Review and approve the minutes from the teleconference calls (IEEE 802.22-08/232r5). 3. Assure that the participants are aware of the IEEE patent policy located at: http://standards.ieee.org/board/pat/pat-slideset.pdf 4. Review the current draft of the RP IEEE 802.22-06/242r14.

Attendance: WinstonC, ChrisC, KellyW, TomG, Tony, StephenK, JerryK, SteveS, MoniqueB, OffCom Rep

 The agenda, document 08/262, was approved unanimously.  The minutes from conference calls, document 08/232r5, were approved unanimously.  The chair acknowledged the IEEE patent policy (already reviewed in 802 and 802.22 opening plenary meetings).  We moved to review of the latest RP draft, document 06/242r15 was reviewed during this meeting o Skipped section 1, which describes the 802.22 reference model. o Winston has moved summary/specification of the database service to section 2.0, as it is essential to 802.22 operation. . Winston created a new figure for the start of the session that conceptualizes the communication (I/O) between the database service and 802.22. . There was a comment that it would be useful for more info to be passed between .22 and the database service. There could be more detail on what kind of signal is actually on a particular channel. E.g., the communication would also indicate channels that are not available, and if they are occupied by ATSC, NTSC, or other signal types. This kind of info would be optional, as far as whether the 802.22 system uses it. But it could be somehow useful. . The section 2.1 needs to be updated to include the “pushing” concept. That idea was presented by Samsung and the concept has been agreed, but the RP needs an update. The concept is particularly useful for updating info related to time-scheduled wireless microphone use of TV channel. . Winston has added a first draft figure (flow diagram) to describe the internal operation of the database service. Suggested improvements to the flow diagram included:  Changing “contours” to “compute contours”; but what this box does depends on what is coming from the database, which depends on the  Changing “channels” to say “channels and EIRP profile”  There are currently 4 proposals that have been presented (from Charles Cooper, Winston, Gerald, and Ivan) for how the database entity could work. The thinking now is that we’d summarize all of these in an annex. The idea here is to show what is the “primary/generic database service” that is applicable regardless of the database proposal. There was some discussion whether such a service could be defined such that it would “fit” regardless of the approach. These should all produce an output with channel and EIRP info. There was discussion that maybe these all produce a different output, someone will have to decide which approach is acceptable in a given regulatory domain (like the FCC in the USA). We discussed briefly how the Motorola WSD prototype database service works (Stephen gave a short overview of what it does). . It was asked if TG2 is going to standardize exactly how the calculations in the database are going to be done (e.g. FCC contours, Longley-Rice, TIREM, or ITU-based models)? Or are we going to define the steps without specifics of the calculations (“you need to compute the contour”)? The steps are already described in section 9 of the 802.22 draft (to some extent), but with no specifics/details. OET Bulletin 69 captures how the FCC does related calculations.

. It was asked if the info on location of incumbents is already available and who is going own/manage it. This info is present in an FCC database, but there isn’t full confidence that it is accurate (although it is supposed to be updated every night). 1700+ full power TV broadcasts and 7000+ LPTV stations, this data probably will be carefully checked as we approach official switch-over to DTV. The database service we are talking about could be based on an updated version of the existing FCC database. . There was a suggestion to use SQL for the database queries. This was added as an example of a Standardized Format (in section 2.1.1.3). Note that these queries are within the database service itself. . Question was asked whether the FCC would be involved in developing a database of WRAN Base Stations. It is not clear who would manage this database (not a given the FCC would do it) . Comment was made that there should be in a reference in section 2.2 that describes how the contour could be calculated (just one example, as there are many ways) . Winston has added sections 2.4 & 2.5 to describe database inputs and outputs. Noted that there is a difference between the database service input (NMEA strings in ASCII format) and the format of the data within the database service (SQL or whatever we like). . Recessed at 12:32 PM

September 11, 2008 10:30 – 12:00 PM Meeting Minutes Attendance: WinstonC, ChrisC, TomG, JerryK, KellyW

 We continued (from Sept 10th) the review of the latest RP draft, document 06/242r15 o We picked up with section 2.5.2 on EIRP Profile . Noted that we still need to talk about analog, since LPTV will still be there and need protection. . Discussed the results that indicate 14 dB of isolation can be expected. Comments were made that it is not clear that this isolation can be maintained at distances other than 10 m (which is was the assumption behind the 14 dB value). It is not clear whether to adopt the text in r15 (from Gerald), Gerald was not in attendance (he was probably needed in the other con-current meeting). A good portion of the 2.5.2 text is from Gerald and David (France Telecom) and there are questions from people in attendance. . Discussion about Table 1 “Maximum CPE Transmit EIRP (dBW) When a CPE Is Located 10 m from a DTV Receiver”.  There were questions about the N+/-5 and N+/-6 max transmit EIRPs (CPE operation limits on 2nd adjacent channel), which are ~ 11/9.9 dBW (around 10 watts, well above 4 Watt limit in the USA).  Comment was made that it could be worthwhile to include a footnote on the table that the EIPR must meet regulatory limits. . There is also concern about installation, and whether it would be such that you get the 14 dB cross polarization isolation. Can we know for sure that the separation will be 10 m? . The names of some of the subsections were changed/rearranged for clarity (for both the BS and CPE EIRP profile description sections). The goal was to indicate the separate EIRP profile considerations for cases where  CPE and/or BS is operating inside the protected contour - understanding is that this is not allowed co or adjacent channel, and that EIPR profile is channel location dependent for channels N+/-2 and beyond.  CPE and/or BS is operating outside the protected contour - understanding is they can operate at regulatory max power levels, except when operating co or adjacent channel. o Winston has added a sections called “Interference” and “CoExistence” that TG2 should review at some point.

o Comment was made that perhaps the “Deployment” section should be moved up to an earlier section in the document. o We adjourned at 12:00 PM.

References:

Submission page 5 Christopher Clanton, Shure Inc