doc.: IEEE /0047r0 Submission July 2009 Minnie Ingersoll, Google, Inc.Slide 1 White Spaces Database Notice: This document has been prepared to assist IEEE 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. Date:

doc.: IEEE /0047r0 Submission July 2009 Minnie Ingersoll, Google, Inc.Slide 2 Abstract Brief background on Google’s interest in spectrum and our involvement in TV White Spaces. TV White Spaces Database requirements, Group formation, membership, and Google’s view of work being done in the WSDB Group. This presentation will briefly cover the ongoing work to define White Space database security, interfaces, and specifications for data integrity.

doc.: IEEE /0047r0 Submission July 2009 Minnie Ingersoll, Google, Inc.Slide 3 Google’s Alternative Access Team Mission: –The What: To bring the openness ethos of the wireline world to the wireless industry –The How: Create/encourage new wireless platforms to enable user choice and unfettered access to Google Other initiatives: –Muni Wi-Fi, 700 MHz auction, Ubiquisys (femtocells), Clearwire White Spaces: –Huge opportunity for wireless broadband (Wi-Fi 2.0); ~100MHz/market in US on average –Storing data and serving queries fits within Google expertise –Database can provide necessary protection of incumbents

doc.: IEEE /0047r0 Submission July 2009 Minnie Ingersoll, Google, Inc.Slide 4 Role of the WSDB The White Spaces Database (WSDB) is intended to provide a more reliable way of providing channel availability than could be done with sensing-only The WSDB serves the following functions: [15.713] 1.Channel query responses 2.Device registration 3.Register protected entity data not already in FCC DB

doc.: IEEE /0047r0 Submission July 2009 Minnie Ingersoll, Google, Inc.Slide 5 Database Data Data that is required to be stored and maintained in the TV bands database: [15.713(h)(4)] 1.Facilities already recorded in FCC databases: DTV, BAS, CMRS/PLMR in the 13 Metro Areas (incl. waivered base station operations), Offshore Radiotelephone Service 2.Facilities not recorded in FCC databases: Cable headends, television translators, wireless mics 3.Registered White Spaces Device (WSD) info 4.Other data: Canada and Mexico borders, Radio Astronomy

doc.: IEEE /0047r0 Submission July 2009 Minnie Ingersoll, Google, Inc.Slide 6 Database operations requirements Establish a process for acquiring and storing the necessary and appropriate information from the FCC’s databases and synchronizing the database with the current FCC databases at least once a week to include newly licensed facilities or any changes to licensed facilities. [15.715(b)] Respond in a timely manner to verify, correct and/or remove data in the event that the FCC or a party brings claim of inaccuracies in the database to its attention. [15.715(h)] The database must have functionality such that upon request from the Commission it can indicate that no channels are available when queried by a specific WSD or model of WSD. [15.715(j)] If more than one database is developed, cooperate to develop a standardized process for providing on a daily basis or more often as appropriate, the database data [15.715(k)]

doc.: IEEE /0047r0 Submission July 2009 Minnie Ingersoll, Google, Inc.Slide 7 Database Load Fixed WSDs shall access the database at their geographic coordinates as follows: –Prior to their initial service transmission at a given location. –At least once a day to verify that the operating channels continue to remain available. [15.711(b)(3)(i)] Mode II personal/portable WSDs must access the database at their geographic coordinates as follows: –Prior to their initial service transmission at a given location. –Each time it is activated from a power-off condition. –If it changes location during operation. –Daily if it has been in a powered state to verify that the operating channel(s) continue to be available. [15.711(b)(3)(ii)]

doc.: IEEE /0047r0 Submission July 2009 Minnie Ingersoll, Google, Inc.Slide 8 White Spaces DB Group Membership WSDB Group initially formed to facilitate communication; spent first few weeks just developing a lexicon Formed Feb 2009 with 7 founding members: –Google, Microsoft, Motorola, Comsearch, Neustar, HP, Dell New members Feb 2009 – July 2009 –Broadcasters (including MSTV) –Cable (including NCTA) –Many other industry leaders and public interest community

doc.: IEEE /0047r0 Submission July 2009 Minnie Ingersoll, Google, Inc.Slide 9 White Spaces DB Principles The Group's key objective is to enable the timely creation and operation of an FCC approved TV White Spaces geo-location database. The Group will promote the development of interfaces and operational specifications to facilitate the adoption and usage of White Spaces Devices (WSDs) The Group will establish data formats and protocols that are open and non-proprietary. The database administration should be open and non-exclusive. The Group’s near-term focus will be a US database. Ultimately, the architecture should be flexible to support international requirements

doc.: IEEE /0047r0 Submission July 2009 Minnie Ingersoll, Google, Inc.Slide 10 Preliminary functional architecture (filed with FCC April 2009)

doc.: IEEE /0047r0 Submission July 2009 Minnie Ingersoll, Google, Inc.Slide 11 WSDB Architecture Definitions White Spaces Device (WSD) – Refers to unlicensed devices that will use the White Spaces. This includes Fixed devices and personal/portable devices, both Mode I and Mode II, as defined in the FCC Order. [15.703(o)] Protected Entity – Refers to locations and services entitled to protection [15.712] Registrant – The Registrant is an entity that registers data (Protected Entity and registered WSDs) with the Registrar (defined below). Data Repository – A repository of data that contains ALL the Protected Entity information and all the registered WSD information. [15.713]

doc.: IEEE /0047r0 Submission July 2009 Minnie Ingersoll, Google, Inc.Slide 12 WSDB Architecture Definitions (cont) Registrar – The Registrar receives WSD and/or Protected Entity registrations and provisions those registrations into a Data Repository. A Registrar does not have to provide registration to all devices. Registrars may specialize in registering certain types of devices. For example, there could be a Registrar that just specializes in protected entities. Repository Service – Manages a Data Repository and communicates information with other services but not necessarily end users –Maintains a Data Repository –Gets data from FCC databases and synchronizes with those databases [15.715(b)] –Provides interface for FCC enforcement of repository information. –Accepts registration information from Registrars –Disseminates required repository information to Query Service providers –Exchanges registration information with other Repository Services Repository Administrator – Is the legal entity that is responsible and accountable to the FCC for administering a Repository Service.

doc.: IEEE /0047r0 Submission July 2009 Minnie Ingersoll, Google, Inc.Slide 13 WSDB Architecture Definitions (cont) Query Service – The Query Service returns available channels by combining the lat/lon sent by the device with channel availability information received from the Data Repository. The Query Service has no autonomy about the calculation since all the data is coming from the Repository. The Repository Service, Registrar Service and Query Service can be independent services. However, they may in practice be combined. This section defines some terms for combined services. –Integrated White Spaces Information Service – Repository Service, Registrar Service, and Query Service functions are combined into one entity. –White Spaces Service Provider (WSSP) – Registrar for WSD and Query Service functions are combined into one entity.

doc.: IEEE /0047r0 Submission July 2009 Minnie Ingersoll, Google, Inc.Slide 14 Fig 2: WS Reference Architecture Combined WSD Registrar and Query Service

doc.: IEEE /0047r0 Submission July 2009 Minnie Ingersoll, Google, Inc.Slide 15 Fig 3: WS Reference Architecture Combined WSD Registrar, Repository and Query Service

doc.: IEEE /0047r0 Submission July 2009 Minnie Ingersoll, Google, Inc.Slide 16 Fig 4: Multiple Service Providers

doc.: IEEE /0047r0 Submission July 2009 Minnie Ingersoll, Google, Inc.Slide 17 Ongoing work The White Spaces Database Group has been meeting regularly to devise and propose certain structural components of the White Spaces Database. Informal full Group calls once/week Four subcommittees: –Security –Interfaces definition –Computational Practices –Governance

doc.: IEEE /0047r0 Submission July 2009 Minnie Ingersoll, Google, Inc.Slide 18 Current progress on security Google’s recent work has been focused on security-related issues, with good progress thus far. The primary task of the security design is to ensure that the WSD is getting accurate channel information from an authorized source and is not able to be spoofed or receive invalid, unauthorized or altered channel information. Google proposes employing digital certificates to authenticate the WSSPs –The Repository acts as a root certificate authority in a centralized public-key infrastructure (PKI). –The Repository issues certificates to WSSPs, and authorizes them to receive signed blocks from the Database –The WSD has the root certificate of the Repository in order to validate the certificate of the WSSP –We propose using standard X.509 certificates TLS (SSL) can be used to provide transport-layer security between the WSD and WSSP as well as the WSSP and the Repository.

doc.: IEEE /0047r0 Submission July 2009 Minnie Ingersoll, Google, Inc.Slide 19 Ongoing work—Security The Order indicates that the FCC is responsible for determining which devices are causing interference, and subsequently contacting WSD users that are causing interference. (par. 212) Failing to resolve the interference issue, upon request from the FCC, the Repository must have the functionality to indicate “no channels available” based on the serial # or FCC ID of the WSD. –Google believes this could be accomplished by creating a blacklist of serial # and FCC IDs that are provided by the FCC. –The contents of all blacklists will be managed by the Repository, disseminated to the WSSP, and digitally signed with the root certificate of the Repository.

doc.: IEEE /0047r0 Submission July 2009 Minnie Ingersoll, Google, Inc.Slide 20 Ongoing work—Data calculation The FCC outlines in section the details for how to calculate what channels are protected based on geographic information supplied by the WSDs –The channel availability data must also take into account the type of WSD (Fixed, Portable) –Adjacent channel power limitations (still pending rule-making) –Protection of analog and digital TV is generally based on the protected service contours (Grade B contour or NLC) of TV transmitters. To help ensure calculation consistency and prevent the threat of a bad acting WSSP, all channel calculations could be performed by the Repository. –For each lat/long, the Repository will pre-compute what channels are available at that location –This approach has the advantages of ensuring consistent computations/channel availability data among different WSSPs, as well as providing a simpler means for modifying/updating the requirements of the WSDB system. –After channel availability is pre-computed by the Repository Service, it would be distributed to the various WSSPs, who would in turn directly interface with WSDs in the field. –It is envisioned that WSSPs would typically locally cache channel availability results generated by the Repository Service on a daily basis –If the WSSP is not trusted to handle channel data, then individual query responses could be signed by the Repository and passed through the Service Provider to the WSD as-is (with the WSSP acting as a dumb cache only)

doc.: IEEE /0047r0 Submission July 2009 Minnie Ingersoll, Google, Inc.Slide 21 Ongoing work—Protected entities Repository Registered Protected Entity (RRPE) must be validated in order to register operational information with the Repository. Google proposes that validation and registration for RRPEs be a two- step process. –The first step is a one-time user validation, which consists of creating an account with the Repository Administrator (RA). PEs and third-party entities would be required to provide the identification information for follow-up direct contact validation by the RA. Once validated, the RA will send login credentials –The second step consists of registering the operation of the PE’s facility. PEs log in to the system, select the type of facility they want to register, then enter the required data on their systems

doc.: IEEE /0047r0 Submission July 2009 Minnie Ingersoll, Google, Inc.Slide 22 Next Steps Public Notice on WS DB expected (August timeframe?) WSDB Group focused on getting a database online and for devices to begin using asap. Not inviting new members until we have formalized membership rules and governance issues Making database extensible enough to allow further expansion; possible harmonization with other bands and International WS use

doc.: IEEE /0047r0 Submission July 2009 Minnie Ingersoll, Google, Inc.Slide 23 References