1 / 23

White Spaces Database

White Spaces Database. Date: 2009-07-16.

benita
Download Presentation

White Spaces Database

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. White Spaces Database Date: 2009-07-16 Notice:This document has been prepared to assist IEEE 802.19. 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. Minnie Ingersoll, Google, Inc.

  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. Minnie Ingersoll, Google, Inc.

  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 Minnie Ingersoll, Google, Inc.

  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] • Channel query responses • Device registration • Register protected entity data not already in FCC DB Minnie Ingersoll, Google, Inc.

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

  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)] Minnie Ingersoll, Google, Inc.

  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)] Minnie Ingersoll, Google, Inc.

  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 Minnie Ingersoll, Google, Inc.

  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 Minnie Ingersoll, Google, Inc.

  10. Preliminary functional architecture(filed with FCC April 2009) Minnie Ingersoll, Google, Inc.

  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] Minnie Ingersoll, Google, Inc.

  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. Minnie Ingersoll, Google, Inc.

  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. Minnie Ingersoll, Google, Inc.

  14. Fig 2: WS Reference Architecture Combined WSD Registrar and Query Service Minnie Ingersoll, Google, Inc.

  15. Fig 3: WS Reference Architecture Combined WSD Registrar, Repository and Query Service Minnie Ingersoll, Google, Inc.

  16. Fig 4: Multiple Service Providers Minnie Ingersoll, Google, Inc.

  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 Minnie Ingersoll, Google, Inc.

  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. Minnie Ingersoll, Google, Inc.

  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. Minnie Ingersoll, Google, Inc.

  20. Ongoing work—Data calculation • The FCC outlines in section 15.712 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) Minnie Ingersoll, Google, Inc.

  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 Minnie Ingersoll, Google, Inc.

  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 Minnie Ingersoll, Google, Inc.

  23. References Minnie Ingersoll, Google, Inc.

More Related