idnits 2.17.1 draft-ietf-paws-problem-stmt-usecases-rqmts-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 30, 2012) is 4247 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Working Group Draft S. Probasco, Ed. 3 Internet-Draft B. Patil 4 Intended status: Informational August 30, 2012 5 Expires: March 3, 2013 7 Protocol to Access White Space database: PS, use cases and rqmts 8 draft-ietf-paws-problem-stmt-usecases-rqmts-08 10 Abstract 12 Portions of the radio spectrum that are assigned to a particular use 13 but are unused or unoccupied at specific locations and times are 14 defined as "white space". The concept of allowing additional 15 transmissions (which may or may not be licensed) in white space is a 16 technique to "unlock" existing spectrum for new use. An obvious 17 requirement is that these additional transmissions do not interfere 18 with the assigned use of the spectrum. One approach to using the 19 white space spectrum at a given time and location is to verify with a 20 database for available channels. 22 This document describes a number of possible use cases of white space 23 spectrum and technology as well as a set of requirements for the 24 database query protocol. The concept of TV white spaces is described 25 including the problems that need to be addressed to enable white 26 space spectrum for additional uses without causing interference to 27 currently assigned use. Use of white space is enabled by querying a 28 database which stores information about the channel availability at 29 any given location and time. 31 Status of this Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on March 3, 2013. 48 Copyright Notice 49 Copyright (c) 2012 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 1.1. Introduction to white space . . . . . . . . . . . . . . . 4 66 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 1.2.1. In Scope . . . . . . . . . . . . . . . . . . . . . . . 6 68 1.2.2. Out of Scope . . . . . . . . . . . . . . . . . . . . . 6 69 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 7 70 2.1. Conventions Used in This Document . . . . . . . . . . . . 7 71 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 72 3. Prior Work . . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 3.1. The concept of Cognitive Radio . . . . . . . . . . . . . . 8 74 3.2. Background information on white space in the US . . . . . 9 75 3.3. Background information on white space in the UK . . . . . 9 76 3.4. Air Interfaces . . . . . . . . . . . . . . . . . . . . . . 10 77 4. Use cases and protocol services . . . . . . . . . . . . . . . 10 78 4.1. Protocol services . . . . . . . . . . . . . . . . . . . . 10 79 4.1.1. White space database discovery . . . . . . . . . . . . 10 80 4.1.2. Device registration with trusted Database . . . . . . 11 81 4.2. Use cases . . . . . . . . . . . . . . . . . . . . . . . . 12 82 4.2.1. Hotspot: urban Internet connectivity service . . . . . 12 83 4.2.2. Wide-Area or Rural Internet broadband access . . . . . 15 84 4.2.3. Offloading: moving traffic to a white space network . 18 85 4.2.4. White space serving as backhaul . . . . . . . . . . . 20 86 4.2.5. Rapid deployed network for emergency scenario . . . . 21 87 4.2.6. Mobility . . . . . . . . . . . . . . . . . . . . . . . 22 88 4.2.7. Indoor Networking . . . . . . . . . . . . . . . . . . 25 89 4.2.8. Machine to Machine (M2M) . . . . . . . . . . . . . . . 26 90 5. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 28 91 5.1. Global applicability . . . . . . . . . . . . . . . . . . . 29 92 5.2. Database discovery . . . . . . . . . . . . . . . . . . . . 30 93 5.3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 31 94 5.4. Data model definition . . . . . . . . . . . . . . . . . . 31 95 6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 31 96 6.1. Normative Requirements . . . . . . . . . . . . . . . . . . 31 97 6.2. Non-normative requirements . . . . . . . . . . . . . . . . 34 98 6.3. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . 36 99 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 100 8. Security Considerations . . . . . . . . . . . . . . . . . . . 37 101 9. Summary and Conclusion . . . . . . . . . . . . . . . . . . . . 40 102 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 40 103 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40 104 11.1. Normative References . . . . . . . . . . . . . . . . . . . 40 105 11.2. Informative References . . . . . . . . . . . . . . . . . . 41 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42 108 1. Introduction 110 1.1. Introduction to white space 112 Wireless spectrum is a commodity that is regulated by governments. 113 The spectrum is used for various purposes, which include but are not 114 limited to entertainment (e.g. radio and television), communication 115 (e.g. telephony and Internet access), military (e.g. radars etc.) 116 and, navigation (e.g. satellite communication, GPS). Portions of the 117 radio spectrum that are assigned to a licensed user but are unused or 118 unoccupied at specific locations and times are defined as "white 119 space". The concept of allowing additional transmissions (which may 120 or may not be licensed) in white space is a technique to "unlock" 121 existing spectrum for new use. An obvious requirement is that these 122 additional transmissions do not interfere with the assigned use of 123 the spectrum. One interesting observation is that often, in a given 124 physical location, the assigned user(s) may not be using the entire 125 band assigned to them. The available spectrum for additional 126 transmissions would then depend on the location of the additional 127 user. The fundamental issue is how to determine for a specific 128 location and specific time, if any of the assigned spectrum is 129 available for additional use. Academia and Industry have studied 130 multiple cognitive radio mechanisms for use in such a scenario. One 131 simple mechanism is to use a geospatial database that records the 132 assigned users occupation, and require the additional users to check 133 the database prior to selecting what part of the spectrum they use. 134 Such databases could be available on the Internet for query by 135 additional users. 137 Spectrum useable for data communications, especially wireless 138 Internet communications, is scarce. One area which has received much 139 attention globally is the TV white space: portions of the TV band 140 that are not used by broadcasters in a given area. In 2008 the 141 United States regulator (the FCC) took initial steps when they 142 published their first ruling on the use of TV white space, and then 143 followed it up with a ruling in 2010 [FCC Ruling] that established 144 the basic foundation for TV white space service in the US. In May 145 2012 the FCC issued minor updates further refining the previous 146 ruling [3MOO]. Finland passed an Act in 2009 enabling testing of 147 cognitive radio systems in the TV white space. The ECC has completed 148 Report 159 [ECC Report 159] containing requirements for operation of 149 cognitive radio systems in the TV white space. Ofcom published in 150 2004 their Spectrum Framework Review [Spectrum Framework Review] and 151 their Digital Dividend Review [DDR] in 2005, with proposals from 2009 152 onwards to access TV white space, leading to the 2011 Ofcom Statement 153 Implementing Geolocation [Ofcom Implementing] which has been followed 154 by draft requirements for TV white space devices [Ofcom 155 Requirements]. More countries are expected to provide access to 156 their TV spectrum in similar ways. Any entity that is assigned 157 spectrum that is not densely used may be asked to give it up in one 158 way or another for more intensive use. Providing a mechanism by 159 which additional users share the spectrum with the assigned user is 160 attractive in many bands in many countries. 162 Television transmission until now has primarily been analog. The 163 switch to digital transmission has begun. As a result the spectrum 164 assigned for television transmission can now be more effectively 165 used. Unused channels and bands between channels can be used by 166 additional users as long as they do not interfere with the service 167 for which that channel is assigned. While urban areas tend to have 168 dense usage of spectrum and a number of TV channels, the same is not 169 true in semi-rural, rural and remote areas. There can be a number of 170 unused TV channels in such areas that can be used for other services. 171 Figure 1 shows TV white space within the lower UHF band: 173 Avg | 174 usage| |-------------- White Space 175 | | | | | | 176 0.6| || || V V || 177 | || ||| | || 178 0.4| || |||| | || 179 | || |||| | ||<----TV transmission 180 0.2| || |||| | || 181 |---------------------------------------- 182 400 500 600 700 800 183 Frequency in MHz -> 185 Figure 1: High level view of TV White Space 187 The fundamental issue is how to determine for a specific location and 188 specific time if any of the spectrum is available for additional use. 189 There are two dimensions of use that may be interesting: space (the 190 area in which an additional user would not interfere with the 191 assigned use), and time: when the additional transmission would not 192 interfere with the assigned use. In this discussion, we consider the 193 time element to be relatively long term (e.g. hours in a day) rather 194 than short term (e.g. fractions of a second). Location in this 195 discussion is geolocation: where the transmitters (and sometimes 196 receivers) are located relative to one another. In operation, the 197 database records the assigned user's transmitter (and some times 198 receiver) locations along with basic transmission characteristics 199 such as antenna height, and power. Using rules established by the 200 local regulator, the database calculates an exclusion zone for each 201 assigned user, and attaches a time schedule to that use. The 202 additional user queries the database with its location. The database 203 intersects the exclusion zones with the queried location, and returns 204 the portion of the spectrum not in any exclusion zone. Such methods 205 of geospatial database query to avoid interference have been shown to 206 achieve favorable results, and are thus the basis for rulings by the 207 FCC and reports from ECC and Ofcom. In any country, the rules for 208 which assigned entities are entitled to protection, how the exclusion 209 zones are calculated, and what the limits of use are by additional 210 users may vary. However, the fundamental notion of recording 211 assigned users, calculating exclusion zones, querying by location and 212 returning available spectrum (and the schedule for that spectrum) are 213 common. 215 This document includes the problem statement, use cases and 216 requirements associated with the use of white space spectrum by 217 secondary users via a database query protocol. 219 1.2. Scope 221 1.2.1. In Scope 223 This document applies only to communications required for basic 224 service in TV white spaces. The protocol will enable a white space 225 radio device to complete the following tasks: 227 1. Determine the relevant white space database to query. 229 2. Connect to the database using a well-defined access method. 231 3. Register with the database using a well-defined protocol. 233 4. Provide its geolocation and perhaps other data to the database 234 using a well-defined format for querying the database. 236 5. Receive in response to the query a list of currently available 237 white space channels or frequencies using a well-defined format 238 for the information. 240 6. Send an acknowledgment to the database with information 241 containing channels selected for use by the device. 243 1.2.2. Out of Scope 245 The following topics are out of scope for this specification: 247 Co-existence and interference avoidance of white space devices 248 within the same spectrum 249 Provisioning (releasing new spectrum for white space use) 251 2. Conventions and Terminology 253 2.1. Conventions Used in This Document 255 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 256 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 257 document are to be interpreted as described in RFC 2119 [RFC2119]. 259 2.2. Terminology 261 Database 263 In the context of white space and cognitive radio technologies, 264 the database is an entity which contains, but is not limited to, 265 current information as required by by the regulatory policies 266 about available spectrum at any given location and time, and other 267 types of related (to the white space spectrum) or relevant 268 information. 270 Device Class 272 Identifies classes of devices defined by Regional Regulators, 273 including fixed, mobile, portable, etc... May also indicate if 274 the device is indoor or outdoor. 276 Device ID 278 A unique number for each master device and slave device that 279 identifies the manufacturer, model number and serial number. 281 Location Based Service 283 An application or device which provides data, information or 284 service to a user based on their location. 286 Master Device 288 A device which queries the WS Database to find out the available 289 operating channels. 291 Protected Entity 293 An assigned user of white space spectrum which is afforded 294 protection against interference by additional users (white space 295 devices) for its use in a given area and time. 297 Protected Contour 299 The exclusion area for a Protected Entity, held in the database 300 and expressed as a polygon with geospatial points as the vertices. 302 Slave Device 304 A device which uses the spectrum made available by a master 305 device, and cannot query the database directly. 307 TV White Space 309 TV white space refers specifically to radio spectrum which has 310 been allocated for TV broadcast, but is not occupied by a TV 311 broadcast, or other assigned user (such as a wireless microphone), 312 at a specific location and time. 314 TV White Space Device (TVWSD) 316 A White Space Device that operates in the TV bands. 318 White Space (WS) 320 Radio spectrum which is not fully occupied at a specific location 321 and time. 323 White Space Device (WSD) 325 A device which opportunistically uses some part of white space 326 spectrum. A white space device can be an access point, base 327 station, a portable device or similar. A white space device may 328 be required by local regulations to query a database with its 329 location to obtain information about available spectrum. 331 3. Prior Work 333 3.1. The concept of Cognitive Radio 335 A cognitive radio uses knowledge of the local radio environment to 336 dynamically adapt its own configuration and function properly in a 337 changing radio environment. Knowledge of the local radio environment 338 can come from various technology mechanisms including sensing 339 (attempting to ascertain primary users by listening for them within 340 the spectrum), location determination and Internet connectivity to a 341 database to learn the details of the local radio environment. White 342 Space is one implementation of cognitive radio. Because a cognitive 343 radio adapts itself to the available spectrum in a manner that 344 prevents the creation of harmful interference, the spectrum can be 345 shared among different radio users. 347 3.2. Background information on white space in the US 349 Television transmission in the United States has moved to the use of 350 digital signals as of June 12, 2009. Since June 13, 2009, all full- 351 power U.S. television stations have broadcast over-the-air signals in 352 digital only. An important benefit of the switch to all-digital 353 broadcasting is that it freed up parts of the valuable broadcast 354 spectrum. More information about the switch to digital transmission 355 is at [DTV]. 357 Besides the switch to digital transmission for TV, the guard bands 358 that exist to protect the signals between stations can be used for 359 other purposes. The FCC has made this spectrum available for 360 unlicensed use and this is generally referred to as white space. 361 Please see the details of the FCC ruling and regulations in [FCC 362 Ruling]. The spectrum can be used to provide wireless broadband as 363 an example. 365 3.3. Background information on white space in the UK 367 Background information on white space in UK Since its launch in 2005, 368 Ofcom's Digital Dividend Review [DDR] has considered how to make the 369 spectrum freed up by digital switchover available for new uses, 370 including the capacity available within the spectrum that is retained 371 to carry the digital terrestrial television service. Similarly to 372 the US, this interleaved or guard spectrum occurs because not all the 373 spectrum in any particular location will be used for terrestrial 374 television and so is available for other services, as long as they 375 can interleave their usage around the existing users. 377 In its September 2011 Statement [Ofcom Implementing] Ofcom says that 378 a key element in enabling white space usage in the TV bands is the 379 definition and provision of a database which, given a device's 380 location, can tell the device which frequency channels and power 381 levels it is able to use without causing harmful interference to 382 other licensed users in the vicinity. Ofcom will specify 383 requirements to be met by such geolocation databases. It also says 384 that the technology has the possibility of being usefully applied 385 elsewhere in the radio spectrum to ensure it is used to maximum 386 benefit. For example, it may have potential in making spectrum 387 available for new uses following any switch to digital radio 388 services. Alternatively it may be helpful in exploiting some of the 389 public sector spectrum holdings. Ofcom will continue to consider 390 other areas of the radio spectrum where white space usage may be of 391 benefit. 393 3.4. Air Interfaces 395 Efforts are ongoing to specify air-interfaces for use in white space 396 spectrum. IEEE 802.11af, IEEE 802.15.4m and IEEE 802.22 are all 397 examples. Other air interfaces could be specified in the future such 398 as LTE. 400 4. Use cases and protocol services 402 There are many potential use cases that could be considered for the 403 TV white space spectrum. Providing broadband Internet access in 404 urban and densely populated hotspots, rural and underserved areas are 405 examples. Available channels may also be used to provide Internet 406 'backhaul' for traditional Wi-Fi hotspots, or by towns and cities to 407 monitor/control traffic lights or read utility meters. Still other 408 use cases include the ability to offload data traffic from another 409 Internet access network (e.g. 3G cellular network) or to deliver 410 location based services. Some of these use cases are described in 411 the following sections. 413 4.1. Protocol services 415 A complete protocol solution must provide all services that are 416 essential to enable the white space paradigm. Before a white space 417 device can begin operating it needs to know what channels are 418 available by sending a query to a white space database for a list of 419 available channels, the white space device must have the capability 420 to first locate or "discover" a suitable database. Additionally, 421 some regulatory authorities require the white space device to 422 register with the database as a first step. This section describes 423 the features required from the protocol. 425 4.1.1. White space database discovery 427 White space database discovery is preliminary to creating a radio 428 network using white space; it is a prerequisite to the use cases 429 below. The radio network is created by a master device. Before the 430 master device can transmit in white space spectrum, it must contact a 431 trusted database where the device can learn if any channels are 432 available for it to use. The master device will need to discover a 433 trusted database in the relevant regulatory domain, using the 434 following steps: 436 1. The master device is connected to the Internet by any means other 437 than using the white space radio. A local regulator may identify 438 exception cases where a master may initialize over white space 439 (e.g. the FCC allows a master to initialize over the TV white 440 space in certain conditions). 442 2. The master device constructs and sends a service request over the 443 Internet to discover availability of trusted databases in the 444 local regulatory domain and waits for responses. 446 3. If no acceptable response is received within a pre-configured 447 time limit, the master device concludes that no trusted database 448 is available. If at least one response is received, the master 449 device evaluates the response(s) to determine if a trusted 450 database can be identified where the master device is able to 451 receive service from the database. 453 Optionally the radio device is pre-programmed with the Internet 454 address of at least one trusted database. The device can establish 455 contact with a trusted database using one of the pre-programmed 456 Internet addresses and establish a white space network (as described 457 in one of the following use cases). 459 Optionally the initial query will be made to a listing approved by 460 the national regulator for the domain of operation (e.g. a website 461 either hosted by or under control of the national regulator) which 462 maintains a list of WS databases and their Internet addresses. The 463 query results in the list of databases and their Internet addresses 464 being sent to the master, which then evaluates the response to 465 determine if a trusted database can be identified where the master 466 device is able to register and receive service from the database. 468 4.1.2. Device registration with trusted Database 470 Registration may be preliminary to creating a radio network using 471 white space; in some regulatory domains, for some device types, it is 472 a prerequisite to the use cases below. The radio network is created 473 by a master device. Before the master device can transmit in white 474 space spectrum, it must contact a trusted database where the device 475 can learn if any channels are available for it to use. Before the 476 database will provide information on available radio channels, the 477 master device must register with the trusted database. Specific 478 requirements for registration come from individual regulatory domains 479 and may be different. 481 Figure 2 shows an example deployment of this scenario. 483 \|/ ---------- 484 | |Database| 485 | .---. /--------- 486 |-|---------| ( ) / 487 \|/ | Master | / \ 488 | / | |========( Internet ) 489 | / |-----------| \ / 490 +-|----+ (AirIF) ( ) 491 |Master| / (----) 492 | | / 493 +------+ 495 Figure 2: Example illustration of registration requirement in white 496 space use-case 498 A simplified operational scenario showing registration consists of 499 the following steps: 501 1. The master device must register with its most current and up-to- 502 date information. Typically the master device will register 503 prior to operating in white space for the first time after power 504 up, after changing location by a predetermined distance, and 505 after regular time intervals. 507 2. The master device shall provide to the database during 508 registration all information required according to local 509 regulatory requirements. This information may include, but is 510 not limited to, the Device ID, serial number assigned by the 511 manufacturer the device's location, device antenna height above 512 ground, name of the individual or business that owns the device, 513 name of a contact person responsible for the device's operation 514 address for the contact person, email address for the contact 515 person and phone number of the contact person. 517 3. The database shall respond to the registration request with an 518 acknowledgement code to indicate the success or failure of the 519 registration request. Additional information may be provided 520 according to local regulator requirements. 522 4.2. Use cases 524 4.2.1. Hotspot: urban Internet connectivity service 526 In this use case Internet connectivity service is provided in a 527 "hotspot" to local users. Typical deployment scenarios include urban 528 areas where Internet connectivity is provided to local businesses and 529 residents, and campus environments where Internet connectivity is 530 provided to local buildings and relatively small outdoor areas. This 531 deployment scenario is typically characterized by multiple masters 532 (APs or hotspots) in close proximity, with low antenna height, cells 533 with relatively small radius (a few kilometers or less), and limited 534 numbers of available radio channels. Many of the masters/APs are 535 assumed to be individually deployed and operated, i.e. there is no 536 coordination between many of the masters/APs. The masters/APs in 537 this scenario use a TDD radio technology. Each master/AP has a 538 connection to the Internet and may provide Internet connectivity to 539 other master and slave devices. 541 Figure 3 shows an example deployment of this scenario. 543 -------- 544 |Device|\ \|/ ---------- 545 | 1 | (TDD AirIF)\ | |Database| 546 -------- \ | (----) /--------- 547 | \ |-|---------| ( ) / 548 | \| Master | / \ 549 -------- /| |========( Internet ) 550 |Device| /(TDD AirIF)/ |-----------| \ / 551 | 2 | / / ( ) 552 ------- / (----) 553 o | / 554 o | (TDD AirIF) 555 o | / 556 --------/ 557 |Device| 558 | n | 559 -------- 561 Figure 3: Hotspot service using TV white space spectrum 563 Once a master/AP has been correctly installed and configured, a 564 simplified power up and operation scenario utilizing TV White Space 565 to provide Internet connectivity service to slave devices, including 566 the ability to clear WSDs from select channels, is described. This 567 scenario consists of the following steps: 569 1. The master/AP powers up; however its WS radio and all other WS 570 capable devices will power up in idle/listen only mode (no 571 active transmissions on the WS frequency band). A local 572 regulator may identify exception cases where a master may 573 initialize over white space (e.g. the FCC allows a master to 574 initialize over TV white space in certain conditions). 576 2. The master/AP has Internet connectivity, determines its location 577 (either from location determination capability or from saved 578 value that was set during installation), and establishes a 579 connection to a trusted white space database (see 580 Section 4.1.1). 582 3. The master/AP registers with the trusted database according to 583 regulatory domain requirements (see Section 4.1.2). 585 4. Following the successful registration process (if registration 586 is required), the master/AP will send a query to the trusted 587 database requesting a list of available WS channels based upon 588 its geolocation. The complete set of parameters to be provided 589 from the master to the database is specified by the local 590 regulator. Parameters may include WSD location, accuracy of 591 that location, device antenna height, device identifier of a 592 slave device requesting channel information. 594 5. If the master/AP has met all regulatory domain requirements 595 (e.g. been previously authenticated, etc), the database responds 596 with a list of available white space channels that the master 597 may use, and optionally a duration of time for their use, 598 associated maximum power levels or a notification of any 599 additional requirements for sensing. 601 6. Once the master/AP has met all regulatory domain requirements 602 (e.g. authenticated the WS channel list response message from 603 the database, etc), the AP selects one or more available WS 604 channels from the list. Prior to initiating transmission, if 605 required by local regulation, the master/AP informs the database 606 of the frequencies and power level it has chosen. This 607 reporting of the frequencies and power levels to the database is 608 repeated for each slave device that associated with the master. 610 7. The slave or user device scans the TV bands to locate a 611 master/AP transmission, and associates with the AP. 613 8. The slave/user device queries the master for a channel list. In 614 the query the slave/user device provides attributes that are 615 defined by local regulations. These may include the slaves' 616 Device ID and its geolocation. 618 9. Once the master/AP has met all regulatory domain requirements 619 (e.g. validating the Device ID with the trusted database, etc) 620 the master provides the list of channels locally available to 621 the slave/user device. Prior to initiating transmission, if 622 required by local regulation, the slave device informs the 623 master/AP of the frequencies and power level it has chosen, and 624 the master/AP relays this information to the database. 626 10. The master sends an enabling signal to establish that the slave/ 627 user device is still within reception range of the master. This 628 signal shall be encoded to ensure that the signal originates 629 from the master that provided the available list of channels. 631 11. Periodically, at an interval established by the local regulator, 632 the slave/user device must receive an enabling signal from the 633 master that provided the available list of channels or contact a 634 master to re-verify or re-establish the list of available 635 channels. 637 12. The master/AP must periodically repeat the process to request a 638 channel list from the database, steps 4 through 6 above. The 639 frequency to repeat the process is determined by the local 640 regulator. If the response from the database indicates a 641 channel being used by the master/AP is not available, the 642 master/AP must stop transmitting on that channel immediately. 643 In addition or optionally, the database may send a message to 644 the master/AP to rescind the availability of one or more 645 channels. The master/AP must stop transmitting on that channel 646 immediately. 648 13. The slave or user device must periodically repeat the process to 649 request a channel list from the master/AP, steps 8 and 9 above. 650 The frequency to repeat the process is determined by the local 651 regulator. If the response from the master/AP indicates that a 652 channel being used by the slave or user device is not available, 653 the slave or user device must stop transmitting on that channel 654 immediately. In addition or optionally, the database may send a 655 message to the master/AP to rescind the availability of one or 656 more channels. The master/AP must then notify the slave or user 657 device of the rescinded channels. The slave or user device must 658 stop transmitting on that channel immediately. 660 4.2.2. Wide-Area or Rural Internet broadband access 662 In this use case, Internet broadband access is provided as a Wide- 663 Area Network (WAN) or Wireless Regional Area Network (WRAN). A 664 typical deployment scenario is a wide area or rural area, where 665 Internet broadband access is provided to local businesses and 666 residents from a master (i.e., BS) connected to the Internet. This 667 deployment scenario is typically characterized by one or more fixed 668 master(s)/BS(s), cells with relatively large radius (tens of 669 kilometers, up to 100 km), and a number of available radio channels. 670 Some of the masters/BSs may be deployed and operated by a single 671 entity, i.e., there can be centralized coordination between these 672 masters/BSs, whereas other masters/BSs may be deployed and operated 673 by operators competing for the radio channels where decentralized 674 coordination using the air-interface would be required. The BS in 675 this scenario uses a TDD radio technology and transmits at or below a 676 transmit power (EIRP) limit established by the local regulator. Each 677 base station has a connection to the Internet and may provide 678 Internet connectivity to multiple slaves/user devices. End-user 679 terminals or devices may be fixed or portable. 681 Figure 4 shows an example deployment of this scenario. 683 ------- 684 |Slave|\ \|/ ---------- 685 |Dev 1| (TDD AirIF) | |Database| 686 ------- \ | .---. /---------- 687 o \ |-|---------| ( ) / 688 o | Master | / \ 689 o / | (BS) |========( Internet ) 690 o / |-----------| \ / 691 ------- (TDD AirIF) ( ) 692 |Slave| / (----) 693 |Dev n| 694 ------- 696 Figure 4: Rural Internet broadband access using TV white space 697 spectrum 699 Once the master/BS has been professionally installed and configured, 700 a simplified power up and operation scenario utilizing TV White Space 701 to provide rural Internet broadband access consists of the following 702 steps: 704 1. The master/BS powers up; however its WS radio and all other WS 705 capable devices will power up in idle/listen-only mode (no 706 active transmissions on the WS frequency band). 708 2. The master/BS has Internet connectivity, determines its location 709 (either from location determination capability or from a saved 710 value that was set during installation), and establishes a 711 connection to a trusted white space database (see 712 Section 4.1.1). 714 3. The master/BS registers with the trusted database service (see 715 Section 4.1.2). Meanwhile the DB administrator may be required 716 to store and forward the registration information to the 717 regulatory authority. If a trusted white space database service 718 is not discovered, further operation of the WRAN may be allowed 719 according to local regulator policy (in this case operation of 720 the WRAN is outside the scope of the PAWS protocol). 722 4. Following the successful registration process (if registration 723 is required), the master/BS will send a query to the trusted 724 database requesting a list of available WS channels based upon 725 its geolocation. The complete set of parameters to be provided 726 from the master to the database is specified by the local 727 regulator. Parameters may include WSD identifier, location, 728 accuracy of that location, device antenna height, etc... 730 5. If the master/BS has been previously authenticated, the database 731 responds with a list of available white space channels that may 732 be used by the master/BS and optionally a maximum transmit power 733 (EIRP) for each channel, a duration of time the channel may be 734 used or a notification of any additional requirement for 735 sensing. 737 6. Once the master/BS authenticates the WS channel list response 738 message from the database, the master/BS selects an available WS 739 channel(s) from the list. Such selection may be improved based 740 on a set of queries to the DB involving a number of hypothetical 741 slave or user devices located at various locations over the 742 expected service area so that the final intersection of these 743 resulting WS channel lists allows the selection of a channel 744 that is likely available over the entire service area to avoid 745 potential interference at the time of slave/user terminal 746 association. The operator may also disallow some channels from 747 the list to suit local needs if required. 749 7. The slave or user device scans the TV bands to locate a WRAN 750 transmission, and associates with the master/BS. 752 8. In some regulatory domains, before a master device sends a 753 channel list, the slave/user device provides its geolocation to 754 the BS which, in turn, queries the database for a list of 755 channels available at the slave's geolocation. 757 9. Once this list of available channels is received from the 758 database by the master, the latter will decide, based on this 759 list of available channels and on the lists for all its other 760 associated slaves/user devices whether it should: a) continue 761 operation on its current channel if this channel is available to 762 all slaves/user devices, b) continue operation on its current 763 channel and not allow association with the new slave/user device 764 in case this channel is not available at its location or c) 765 change channel to accommodate the new slave. In the latter 766 case, the master will notify all its associated slaves/user 767 devices of the new channel to which they have to move. 769 10. The master/BS must periodically repeat the process to request a 770 list of available channels from the database for itself and for 771 all its associated slaves/user devices. If the response from 772 the database indicates that the channel being used by the 773 master/BS is no longer available for its use, the master/BS must 774 indicate the new operating channel to all its slave/user 775 terminals, stop transmitting on the current channel and move to 776 the new operating channel immediately. If the channel that a 777 slave/user terminal is currently using is no longer included in 778 the list of locally available channels, the master may either 779 drop its association with the slave/user device so that this 780 device ceases all operation on its current channel or the master 781 may decide to move the entire cell to another channel to 782 accommodate the slave/user terminal and indicate the new 783 operating channel to all its slave/user devices before dropping 784 the link. The slave/user devices may then move to the 785 identified new operating channel or scan for another WRAN 786 transmission on a different channel. The frequency to repeat 787 the process is determined by the local regulator. 789 11. The slave/user device must transmit its new geographic location 790 every time it changes so that the repeated process described 791 under item 10 can rely on the most up-to-date geolocation of the 792 slave/user device. 794 4.2.3. Offloading: moving traffic to a white space network 796 In this use case internet connectivity service is provided over TV 797 white space as a supplemental or alternative datapath to a 3G or 798 other internet connection. In a typical deployment scenario an end 799 user has a primary internet connection such as a 3G cellular packet 800 data subscription. The user wants to use a widget or application to 801 stream video from an online service (e.g. youtube) to their device. 802 Before the widget starts the streaming connection it checks 803 connectivity options available at the current time and location. 804 Both 3G cellular data is available as well as TVWS connectivity (the 805 user is within coverage of a TVWS master -- hotspot, WAN, WRAN or 806 similar). The user may decide for many and various reasons such as 807 cost, RF coverage, data caps, etc. to prefer the TVWS connection over 808 the 3G cellular data connection. Either by user selection, 809 preconfigured preferences, or other algorithm, the streaming session 810 is started over the TVWS internet connection instead of the 3G 811 cellular connection. This deployment scenario is typically 812 characterized by a TVWS master/AP providing local coverage in the 813 same geographical area as a 3G cellular system. The master/AP is 814 assumed to be individually deployed and operated, i.e. the master/AP 815 is deployed and operated by the user at his home or perhaps by a 816 small business such as a coffee shop. The master/AP has a connection 817 to the internet and provides internet connectivity to the slave/ 818 end-user's device. 820 The figure below shows an example deployment of this scenario. 822 \|/ 823 | 824 | 825 |-|---------| 826 | Master/AP |\ 827 /| Router | \ 828 Streaming/ |-----------| \ 829 -------- / \ ----------- 830 |Slave/| / \ (----) | Database| 831 |WS Dev| \ ( ) /---------- 832 ------- \ \ / \ 833 \ X( Internet ) 834 \ / \ / 835 Signaling \|/ / ( )\ 836 \ | / (----) \---------- 837 \ | / | YouTube| 838 \|-|---------| / ---------- 839 | | / 840 | 3G BTS |/ 841 |-----------| 843 Figure 5: Offloading: moving traffic to a white space network 845 Once a dual or multi mode device (3G + TVWS) is connected to a 3G 846 network, a simplified operation scenario of offloading selected 847 content such as video stream from the 3G connection to the TWVS 848 connection consists of the following steps: 850 1. The dual mode (or multi mode) device (3G + TVWS) is connected to 851 a 3G network. The device has located a TVWS master/AP operating 852 on an available channel and has associated or connected with the 853 TVWS master/AP. 855 2. The user activates a widget or application that streams video 856 from YouTube. The widget connects to YouTube over 3G cellular 857 data. The user browses content and searches for video 858 selections. 860 3. The user selects a video for streaming using the widget's 861 controls. Before the widget initiates a streaming session, the 862 widget checks the available connections in the dual mode device 863 and finds a TVWS master/AP is connected. 865 4. Using either input from the user or pre-defined profile 866 preferences, the widget selects the TVWS master/AP as the 867 connection to stream the video. 869 4.2.4. White space serving as backhaul 871 In this use case Internet connectivity service is provided to users 872 over a more common wireless standard such as Wi-Fi with white space 873 entities providing backhaul connectivity to the Internet. In a 874 typical deployment scenario an end user has a device with a radio 875 such as Wi-Fi. An Internet service provider or a small business 876 owner wants to provide Wi-Fi Internet connectivity service to their 877 customers. The location where Internet connectivity service via 878 Wi-Fi is to be provided is within the coverage area of a white space 879 master (e.g. Hotspot or Wide-Area/Rural network). The service 880 provider installs a white space slave device and connects it to the 881 Wi-Fi access point(s). Wi-Fi access points with an integrated white 882 space slave component may also be used. This deployment scenario is 883 typically characterized by a WS master/AP/BS providing local 884 coverage. The master/AP has a connection to the Internet and 885 provides Internet connectivity to slave devices that are within its 886 coverage area. The WS slave device is 'bridged' to a Wi-Fi network 887 thereby enabling Internet connectivity service to Wi-Fi devices. The 888 WS Master/AP/BS which has some form of Internet connectivity (wired 889 or wireless) queries the database and obtains available channel 890 information. It then provides service using those channels to slave 891 devices which are within its coverage area. 893 Figure 6 shows an example deployment of this scenario. 895 \|/ white \|/ \|/ Wi-Fi \|/ 896 | space | | | 897 | | | |-|----| 898 |--------| |-|---------| |-|------|-| | Wi-Fi| 899 | | | Master | | Slave | | Dev | 900 |Internet|------| (AP/BS) | | Bridge | |------| 901 | | | | | to Wi-Fi | 902 |--------| |-----------| |----------| \|/ 903 | 904 |-|----| 905 | Wi-Fi| 906 | Dev | 907 |------| 909 Figure 6: WS for backhaul 911 Once the bridged device (WS + Wi-Fi) is connected to a master and WS 912 network, a simplified operation scenario of backhaul for Wi-Fi 913 consists of the following steps: 915 1. A bridged device (WS + Wi-Fi) is connected to a master device 916 operating in the WS spectrum. The bridged device operates as a 917 slave device in either Hotspot or Wide-Area/Rural Internet use 918 cases described above. 920 2. Once the slave device is connected to the master, the Wi-Fi 921 access point has Internet connectivity as well. 923 3. End users attach to the Wi-Fi network via their Wi-Fi enabled 924 devices and receive Internet connectivity. 926 4.2.5. Rapid deployed network for emergency scenario 928 Organizations involved in handling emergency operations often have a 929 fully owned and controlled infrastructure, with dedicated spectrum, 930 for day to day operation. However, lessons learned from recent 931 disasters show such infrastructures are often highly affected by the 932 disaster itself. To set up a replacement quickly, there is a need 933 for fast reallocation of spectrum, where in certain cases spectrum 934 can be cleared for disaster relief. To utilize unused or cleared 935 spectrum quickly and reliably, automation of allocation, assignment 936 and configuration is needed. A preferred option is to make use of a 937 robust protocol, already adopted by radio manufacturers. This 938 approach does in no way imply such organizations for disaster relief 939 must compete on spectrum allocation with other white spaces users, 940 but they can. A typical network topology would include wireless 941 access links to the public Internet or private network, wireless ad 942 hoc network radios working independent of a fixed infrastructure and 943 satellite links for backup where lack of coverage, overload or outage 944 of wireless access links occur. 946 Figure 7 shows an example deployment of this scenario. 948 \|/ 949 | ad hoc 950 | 951 |-|-------------| 952 | Master node | |------------| 953 \|/ | with | | Whitespace | 954 | ad hoc /| backhaul link | | Database | 955 | /------/ |---------------| |------------| 956 ---|------------/ | \ / 957 | Master node | | | (--/--) 958 | without | | ------( ) 959 | backhaul link | | Wireless / Private \ 960 ----------------\ | Access ( net or ) 961 \ | \ Internet ) 962 \ \|/ | -------( /\ 963 \ | ad hoc | | (------) \--------- 964 \ | | / | Other | 965 \--|------------- /Satellite | nodes | 966 | Master node | / Link ---------- 967 | with |/ 968 | backhaul link | 969 ----------------- 971 Figure 7: Rapid deployed network with partly connected nodes 973 In the ad hoc network, all nodes are master nodes in a way that they 974 allocate RF channels from the white space database. However, the 975 backhaul link may not be available to all nodes, such as depicted for 976 the left node in Figure 7. To handle RF channel allocation for such 977 nodes, a master node with a backhaul link relays or proxies the 978 database query for them. So master nodes without a backhaul link 979 follow the procedure as defined for clients. The ad hoc network 980 radios utilize the provided RF channels. Details on forming and 981 maintenance of the ad hoc network, including repair of segmented 982 networks caused by segments operating on different RF channels, is 983 out of scope of spectrum allocation. 985 4.2.6. Mobility 987 In this use case, the user has a non-fixed (portable or mobile) 988 device and is riding in a vehicle. The user wants to have 989 connectivity to another device which is also moving. Typical 990 deployment scenarios include urban areas and rural areas where the 991 user may connect to other users while moving. This deployment 992 scenario is typically characterized by a master device with low 993 antenna height, Internet connectivity by some connection that does 994 not utilize TV white space, and some means to predict its path of 995 mobility. This knowledge of mobility could be simple (GPS plus 996 accelerometer), sophisticated (GPS plus routing and mapping function) 997 or completely specified by the user via user-interface. 999 Figure 8 shows an example deployment of this scenario. 1001 \|/ \|/ 1002 | | 1003 | | 1004 +-|---------+ +-|---------+ 1005 | TVWS | | TVWS | 1006 |Master Dev | |Master Dev | 1007 +-----------+ +-----------+ 1008 \ (----) / \ 1009 \ ( ) / \ \|/ 1010 \ / \ / WS AirIF | 1011 ( Internet ) \ | 1012 \ / \+-|--------+ 1013 ( )\----------+ | TVWS | 1014 (----) | Database | |Slave Dev | 1015 +----------+ +----------+ 1017 Figure 8: Example illustration of mobility in TV white space use-case 1019 A simplified operational scenario utilizing TV whitespace to provide 1020 connectivity service in a mobility environment consists of the 1021 following steps: 1023 1. The mobile master device powers up with its WS radio in idle or 1024 listen mode only (no active transmission on the WS frequency 1025 band). 1027 2. The mobile master has Internet connectivity, determines its 1028 location, and establishes a connection to a trusted white space 1029 database (see Section 4.1.1). 1031 3. The mobile master registers with the trusted database according 1032 to regulatory domain requirements (see Section 4.1.2). 1034 4. Following the successful registration process (if registration 1035 is required), the mobile master will send a query to the trusted 1036 database requesting a list of available WS channels based upon 1037 its current location, other parameters required by the local 1038 regulator (see Section 4.2.1, step 4) and a prediction of its 1039 future location. The current location is specified in latitude 1040 and longitude. The method to specify the future location is 1041 TBD, potential methods include movement vector (direction and 1042 velocity), a set of latitude/longitude points which specify a 1043 closed polygon where the future location is within the polygon, 1044 or similar. 1046 5. If the mobile master has met all regulatory domain requirements 1047 (e.g. been previously authenticated, etc), the database responds 1048 with a list of available white space channels that the mobile 1049 master may use, and optional information which may include (1) a 1050 duration of time for the use of each channel (2) a maximum 1051 transmit power for each channel and (3) notification of any 1052 additional requirement for sensing. 1054 6. Once the mobile master has met all regulatory domain 1055 requirements (e.g. authenticated the WS channel list response 1056 message from the database, etc), the master selects one or more 1057 available WS channel(s) from the list for use. At this point 1058 the mobile master may begin direct communication with another 1059 mobile master using methods outside the scope of PAWS. 1061 7. The slave/user device scans to locate a mobile master 1062 transmission, and associates with the mobile master. 1064 8. The slave/user device queries the master for a channel list, 1065 providing to the master the slave's device identification, and 1066 optionally its geolocation and a prediction of its future 1067 location. 1069 9. Once the mobile master has met all regulatory domain 1070 requirements (e.g. the slave's device identification is verified 1071 by the database), the mobile master provides the list of 1072 channels locally available to the slave/user device. 1074 10. If the mobile master moves outside the predicted range of future 1075 positions in step 4, it must repeat the process to request a 1076 channel list from the database, steps 4 through 6 above. If the 1077 response from the database indicates a channel being used by the 1078 mobile master is not available, the master/AP must stop 1079 transmitting on that channel immediately. 1081 11. The slave or user device must periodically repeat the process to 1082 request a channel list from the master/AP, steps 8 and 9 above. 1083 The frequency to repeat the process is determined by the local 1084 regulator. If the response from the master/AP indicates that a 1085 channel being used by the slave or user device is not available, 1086 the slave or user device must stop transmitting on that channel 1087 immediately. In addition or optionally, the database may send a 1088 message to the master/AP to rescind the availability of one or 1089 more channels. The master/AP must then notify the slave or user 1090 device of the rescinded channels. The slave or user device must 1091 stop transmitting on that channel immediately. 1093 4.2.7. Indoor Networking 1095 In this use case, the users are inside a house or office. The users 1096 want to have connectivity to the Internet or to equipment in the same 1097 or other houses / offices. This deployment scenario is typically 1098 characterized by master devices within buildings, that are connected 1099 to the Internet using a method that does not utilize whitespace. The 1100 master devices can establish whitespace links between themselves, or 1101 between themselves and one or more user devices. 1103 Figure 9 shows an example deployment of this scenario. 1105 \|/ 1106 | 1107 +-------+ | 1108 |TVWS |\ +-|---------+ 1109 |Usr Dev| WS AirIF \ | TVWS |\ 1110 +-------+ X|Master Dev | \ 1111 / +-----------+ \ 1112 +-------+ WS AirIF | \ +----------+ 1113 |TVWS |/ | \ (----) | Database | 1114 |Usr Dev| | \ ( ) /----------+ 1115 +-------+ WS AirIF \ / \ 1116 | X( Internet ) 1117 | / \ / 1118 +-------+ \|/ | / ( ) 1119 |TVWS |\ | | / (----) 1120 |Usr Dev| WS AirIF | | / 1121 +-------+ \ +-|---------+ / 1122 \ | TVWS | / 1123 |Master Dev |/ 1124 +-----------+ 1126 Figure 9: Example illustration of indoor TV white space use-case 1128 A simplified operational scenario utilizing TV whitespace to provide 1129 indoor networking consists of the following steps: 1131 1. The master device powers up with its whitespace radio in idle or 1132 listen mode only (no active transmission on the whitespace 1133 frequency band). 1135 2. The master device has Internet connectivity, determines its 1136 location (either from location determination capability or from a 1137 saved value that was set during installation), and establishes a 1138 connection to a trusted white space database (see Section 4.1.1). 1140 3. The master device registers with the trusted database according 1141 to regulatory domain requirements (see Section 4.1.2). 1143 4. Following the successful registration process (if registration is 1144 required), the master device sends a query to the trusted 1145 database requesting a list of available WS channels based upon 1146 its geolocation. The complete set of parameters to be provided 1147 from the master to the database is specified by the local 1148 regulator. Parameters may include WSD location, accuracy of that 1149 location, device antenna height, device identifier of a slave 1150 device requesting channel information. 1152 5. If the master has met all regulatory requirements, the database 1153 responds with a list of available white space channels that the 1154 master device may use, and optional information which may include 1155 inter alia (1) a duration of time for the use of each channel 1156 (channel validity time) (2) a maximum radiated power for each 1157 channel, and (3) directivity and other antenna information. 1159 6. Once the master device authenticates the whitespace channel list 1160 response message from the database, the master device selects one 1161 or more available whitespace channels from the list. At this 1162 point the mobile master may begin direct communication with 1163 another mobile master using methods outside the scope of PAWS. 1165 7. The user device(s) scan(s) the white space bands to locate the 1166 master device transmissions, and associates with the master. 1168 4.2.8. Machine to Machine (M2M) 1170 In this use case, each "machine" includes a white space slave device 1171 and can be located anywhere, fixed or on the move. Each machine 1172 needs to have connectivity to the Internet and or to other machines 1173 in the vicinity. Machine communication over a TVWS channel, whether 1174 to a master device or to another machine (slave device), is under the 1175 control of a master device. This deployment scenario is typically 1176 characterized by a master device with Internet connectivity by some 1177 connection that does not utilize TV white space. 1179 Figure 10 shows an example deployment of this scenario. 1181 \|/ 1182 | 1183 | 1184 +-|---------+ 1185 | TVWS |\ 1186 /|Master Dev | \ 1187 / +-----------+ \ 1188 WS AirIF \ +----------+ 1189 +-------+ / \ (----) | Database | 1190 |Machine| \ ( ) /----------+ 1191 +-------+ \ / \ 1192 | X( Internet ) 1193 WS AirIF \ / 1194 | ( ) 1195 +-------+ (----) 1196 |Machine| 1197 +-------+ \ +-------+ 1198 WS AirIF-- |Machine| 1199 +-------+ 1201 Figure 10: Example illustration of M2M TV white space use-case 1203 A simplified operational scenario utilizing TV whitespace to provide 1204 machine to machine connectivity consists of the following steps: 1206 1. The master device powers up with its whitespace radio in idle or 1207 listen mode only (no active transmission on the whitespace 1208 frequency band). 1210 2. The master device has Internet connectivity, determines its 1211 location (either from location determination capability or from 1212 saved value that was set during installation), and establishes a 1213 connection to a trusted white space database (see Section 4.1.1). 1215 3. The master/AP registers with the trusted database according to 1216 regulatory domain requirements (see Section 4.1.2). 1218 4. Following successful registration (if registration is required), 1219 the master device sends its geolocation and location uncertainty 1220 information, and optionally additional information which may 1221 include (1) device ID and (2) antenna characteristics, to a 1222 trusted database, requesting a list of available whitespace 1223 channels based upon this information. 1225 5. If the master has met all regulatory domain requirements, the 1226 database responds with a list of available white space channels 1227 that the master device may use, and optional information which 1228 may include inter alia (1) a duration of time for the use of each 1229 channel (channel validity time) (2) a maximum radiated power for 1230 each channel or a notification of any additional requirements for 1231 sensing. 1233 6. Once the master device authenticates the whitespace channel list 1234 response message from the database, the master device selects one 1235 or more available whitespace channels from the list. 1237 7. The slave devices fitted to the machines scan the TV bands to 1238 locate the master transmissions, and associate with the master 1239 device. 1241 8. Further signaling can take place outside scope of PAWS to 1242 establish direct links among those slave devices that have 1243 associated with the same master device. At all times these 1244 direct links are under the control of the master device. For 1245 example, common to all use cases, there may be a regulatory 1246 requirement for transmissions from slave to master to cease 1247 immediately if so requested by the master, or if connection to 1248 the master is lost for more than a specified period of time. 1249 When one of these conditions occurs, transmissions from slave to 1250 slave would also cease. Various mechanisms could be used to 1251 detect loss of signal from the master, for example by requiring 1252 masters to transmit regular beacons if they allow slave to slave 1253 communications. Direct slave to slave transmissions could only 1254 restart if each slave subsequently restores its connection to the 1255 same master, or each slave joins the network of another master. 1257 5. Problem Statement 1259 The use of white space spectrum is enabled via the capability of a 1260 device to query a database and obtain information about the 1261 availability of spectrum for use at a given location. The databases 1262 are reachable via the Internet and the devices querying these 1263 databases are expected to have some form of Internet connectivity, 1264 directly or indirectly. The databases may be country specific since 1265 the available spectrum and regulations may vary, but the fundamental 1266 operation of the protocol should be country independent. 1268 An example high-level architecture of the devices and white space 1269 databases is shown in Figure 11: 1271 ----------- 1272 | Master | 1273 |WS Device| ------------ 1274 |Lat: X |\ .---. /--------|Database X| 1275 |Long: Y | \ ( ) / ------------ 1276 ----------- \-------/ \/ o 1277 ( Internet ) o 1278 ----------- /------( )\ o 1279 | Master | / ( ) \ 1280 |WS Device|/ (_____) \ ------------ 1281 |Lat: X | \--------|Database Y| 1282 |Long: Y | ------------ 1283 ----------- 1285 Figure 11: High level view of the White space database architecture 1287 In Figure 11, note that there could be multiple databases serving 1288 white space devices. The databases are country specific since the 1289 regulations and available spectrum may vary. In some countries, for 1290 example, the U.S., the regulator has determined that multiple, 1291 competing databases may provide service to White Space Devices. 1293 A messaging interface between the white space devices and the 1294 database is required for operating a network using the white space 1295 spectrum. The following sections discuss various aspects of such an 1296 interface and the need for a standard. Other aspects of a solution 1297 including provisioning the database, and calculating protected 1298 contours are considered out of scope of the initial effort, as there 1299 are significant differences between countries and spectrum bands. 1301 5.1. Global applicability 1303 The use of TV white space spectrum is currently approved by the FCC 1304 in the United States. However regulatory bodies in other countries 1305 are also considering similar use of available spectrum. The 1306 principles of cognitive radio usage for such spectrum is generally 1307 the same. Some of the regulatory details may vary on a country 1308 specific basis. However the need for devices that intend to use the 1309 spectrum to communicate with a database remains a common feature. 1310 The database provides a known, specifiable Protection Contour for the 1311 primary user, not dependent on the characteristics of the White Space 1312 Device or its ability to sense the primary use. It also provides a 1313 way to specify a schedule of use, because some primary users (for 1314 example, wireless microphones) only operate in limited time slots. 1316 Devices need to be able to query a database, directly or indirectly 1317 over the public Internet and/or private IP networks prior to 1318 operating in available spectrum. Information about available 1319 spectrum, schedule, power, etc. are provided by the database as a 1320 response to the query from a device. The messaging interface needs 1321 to be: 1323 1. Radio/air interface agnostic - The radio/air interface technology 1324 used by the white space device in available spectrum can be IEEE 1325 802.11af, IEEE 802.15.4m, IEEE 802.16, IEEE 802.22, LTE etc. 1326 However the messaging interface between the white space device 1327 and the database should be agnostic to the air interface while 1328 being cognizant of the characteristics of various air-interface 1329 technologies and the need to include relevant attributes in the 1330 query to the database. 1332 2. Spectrum agnostic - the spectrum used by primary and secondary 1333 users varies by country. Some spectrum has an explicit notion of 1334 a "channel" a defined swath of spectrum within a band that has 1335 some assigned identifier. Other spectrum bands may be subject to 1336 white space sharing, but only have actual frequency low/high 1337 parameters to define protected entity use. The protocol should 1338 be able to be used in any spectrum band where white space sharing 1339 is permitted. 1341 3. Globally applicable - A common messaging interface between white 1342 space devices and databases will enable the use of such spectrum 1343 for various purposes on a global basis. Devices can operate in 1344 any country where such spectrum is available and a common 1345 interface ensures uniformity in implementations and deployment. 1346 Since the White Space Device must know its geospatial location to 1347 do a query, it is possible to determine which database, and which 1348 rules, are applicable, even though they are country specific. 1350 4. Address regulatory requirements - Each country is likely to have 1351 regulations that are unique to that country. The messaging 1352 interface needs to be flexible to accommodate the specific needs 1353 of a regulatory body in the country where the white space device 1354 is operating and connecting to the relevant database. 1356 5.2. Database discovery 1358 Another aspect of the problem space is the need to discover the 1359 database. A white space device needs to find the relevant database 1360 to query, based on its current location or for another location. 1361 Since the spectrum and databases are country specific, the device 1362 will need to discover the relevant database. The device needs to 1363 obtain the IP address of the specific database to which it can send 1364 queries in addition to registering itself for operation and using the 1365 available spectrum. 1367 5.3. Protocol 1369 A protocol that enables a white space device to query a database to 1370 obtain information about available channels is needed. A device may 1371 be required to register with the database with some credentials prior 1372 to being allowed to query. The requirements for such a protocol are 1373 specified in this document. 1375 5.4. Data model definition 1377 The contents of the queries and response need to be specified. A 1378 data model is required which enables the white space device to query 1379 the database while including all the relevant information such as 1380 geolocation, radio technology, power characteristics, etc. which may 1381 be country and spectrum and regulatory dependent. All databases are 1382 able to interpret the data model and respond to the queries using the 1383 same data model that is understood by all devices. 1385 Use of XML for specifying a data model is an attractive option. The 1386 intent is to evaluate the best option that meets the need for use 1387 between white space devices and databases. 1389 6. Requirements 1391 6.1. Normative Requirements 1393 D. Data Model Requirements: 1395 D.1: The Data Model MUST support specifying the location of the 1396 WSD, the uncertainty in meters, the height & its 1397 uncertainty, and confidence in percentage of the location 1398 determination. The Data Model MUST support both North 1399 American Datum of 1983 and WGS84. 1401 D.2: The Data Model MUST support specifying the regulatory domain 1402 and its corresponding data requirements. 1404 D.3: The Data Model MUST support specifying an ID of the 1405 transmitter device. This ID would contain the ID of the 1406 transmitter device that has been certified by a regulatory 1407 body for its regulatory domain. The Data Model MUST support 1408 a device class. The Data Model MUST support specifying 1409 information about the type of RAT of the transmitter device. 1411 D.4: The Data Model MUST support specifying a manufacturer's 1412 serial number for a white space device. 1414 D.5: The Data Model MUST support specifying the antenna and 1415 radiation related parameters of the subject, such as: 1417 antenna height 1419 antenna gain 1421 maximum output power, EIRP (dBm) 1423 antenna radiation pattern (directional dependence of the 1424 strength of the radio signal from the antenna) 1426 spectrum mask with lowest and highest possible frequency 1428 spectrum mask in dBr from peak transmit power in EIRP, 1429 with specific power limit at any frequency linearly 1430 interpolated between adjacent points of the spectrum mask 1432 measurement resolution bandwidth for EIRP measurements 1434 D.6: The Data Model MUST support specifying owner and operator 1435 contact information for a transmitter. This includes the 1436 name of the transmitter owner, name of transmitter operator, 1437 postal address, email address and phone number of the 1438 transmitter operator. 1440 D.7: The Data Model MUST support specifying spectrum 1441 availability. Spectrum units are specified by low and high 1442 frequencies and may have an optional channel identifier. 1443 The Data Model MUST support a schedule including start time 1444 and stop time for spectrum unit availability. The Data 1445 Model MUST support maximum power level for each spectrum 1446 unit. 1448 D.8: The Data Model MUST support specifying channel availability 1449 information for a single location and an area (e.g. a 1450 polygon defined by multiple location points or a geometric 1451 shape such as a circle). 1453 D.9: The Data Model MUST support specifying the frequencies and 1454 power levels selected for use by a device in the 1455 acknowledgement message. 1457 P. Protocol Requirements: 1459 P.1: The protocol MUST provide a mechanism to enable WSD 1460 discovery. In some environments, a listing of the approved 1461 white space databases is maintained by the national 1462 regulator. The protocol MUST support discovery of a 1463 database using a listing approved by a national regulator. 1465 P.2: The address of a database (e.g. in form of a URI) can be 1466 preconfigured in a master device. The master device MUST 1467 be able to contact a database using a pre-configured 1468 database address. 1470 P.3: The protocol MUST support determination of regulatory 1471 domain governing its current location. 1473 P.4: The protocol MUST provide the ability for the database to 1474 authenticate the master device. 1476 P.5: The protocol MUST provide the ability for the master device 1477 to verify the authenticity of the database with which it is 1478 interacting. 1480 P.6: The messages sent by the master device to the database and 1481 the messages sent by the database to the master device MUST 1482 support integrity protection. 1484 P.7: The protocol MUST provide the capability for messages sent 1485 by the master device and database to be encrypted. 1487 P.8: The protocol MUST support the master device registering 1488 with the database. 1490 P.9: The protocol MUST support a registration acknowledgement 1491 including appropriate result codes. 1493 P.10: The protocol MUST support a channel query request from the 1494 master device to the database. The channel query request 1495 message MUST include parameters as required by local 1496 regulatory requirement. These parameters MAY include any 1497 of the parameters and attributes required to be supported 1498 in the Data Model Requirements. 1500 P.11: The protocol MUST support a channel query response from the 1501 database to the master device. The channel query response 1502 message MUST include parameters as required by local 1503 regulatory requirement. These parameters MAY include any 1504 of the parameters and attributes required to be supported 1505 in the Data Model Requirements. 1507 P.12: The protocol MUST support a channel usage message from the 1508 master device to the database. The channel usage message 1509 MUST include parameters as required by local regulatory 1510 requirement for the master and its associated slaves. 1511 These parameters MAY include any of the parameters and 1512 attributes required to be supported in the Data Model 1513 Requirements. 1515 P.13: The protocol MUST support a channel usage message 1516 acknowledgement. 1518 P.14: The protocol MUST support a validation request from the 1519 master to the database to validate a slave device. The 1520 validation request MUST include the slave device ID. 1522 P.15: The protocol MUST support a validation response from the 1523 database to the master to indicate if the slave device is 1524 validated by the WSDB. The validation response MUST 1525 include a response code. 1527 P.16: The protocol between the master device and the database 1528 MUST support the capability to change channel availability 1529 information on short notice. 1531 P.17: The protocol between the master device and the database 1532 MUST support a channel availability request which specifies 1533 a geographic location as an area as well as a point. 1535 6.2. Non-normative requirements 1537 O. Operational Requirements: 1539 O.1: The database and the master device MUST be connected to the 1540 Internet. 1542 O.2: A master device MUST be able to determine its location 1543 including uncertainty and confidence level. A fixed master 1544 device MAY use a location programmed at installation or have 1545 the capability to determine its location to the required 1546 accuracy. A mobile master device MUST have the capability to 1547 determine its location to the required accuracy. 1549 O.3: The master device MUST identify a database to which it will 1550 register, make channel requests, etc... The master device MAY 1551 select a database for service by discovery at runtime or the 1552 master device MAY select a database for service by means of a 1553 pre-programmed URI address. 1555 O.4: The master device MUST implement at least one connection 1556 method to access the database. The master device MAY contact 1557 a database directly for service (e.g. as defined by FCC) or 1558 the master device MAY contact a listing server first followed 1559 by contact to a database (e.g. as defined by Ofcom). 1561 O.5: The master device MUST obtain an indication about the 1562 regulatory domain governing operation at its current location, 1563 i.e. the master device MUST know if it operates under 1564 regulations from FCC, Ofcom, etc... 1566 O.6: The master device MAY register with the database according to 1567 local regulatory policy. Not all master devices will be 1568 required to register. Specific events will initiate 1569 registration, these events are determined by regulator policy 1570 (e.g. at power up, after movement, etc...). When local 1571 regulatory policy requires registration, the master device 1572 MUST register with its most current and up-to-date 1573 information, and MUST include all variables mandated by local 1574 regulator policy. 1576 O.7: A master device MUST query the database for the available 1577 channels based on its current location before starting radio 1578 transmission in white space. Parameters provided to the 1579 database MAY include device location, accuracy of the 1580 location, antenna characteristic information, device 1581 identifier of any slave device requesting channel information, 1582 etc... 1584 O.8: The database MUST respond to an available channel list request 1585 from an authenticated and authorized device and MAY also 1586 provide time constraints, maximum output power, start and stop 1587 frequencies for each channel in the list and any additional 1588 requirements for sensing. 1590 O.9: According to local regulator policy, a master device MAY 1591 inform the database of the actual frequency usage of the 1592 master and its slaves. The master MUST include parameters 1593 required by local regulatory policy, e.g. device ID, 1594 manufacturer's serial number, channel usage and power level 1595 information of the master and its slaves. 1597 O.10: After connecting to a master device's radio network a slave 1598 device MUST query the master device for a list of available 1599 channels. The slave MUST include parameters required by local 1600 regulatory policy, e.g. device ID, device location. 1602 O.11: According to local regulatory policy, the master device MAY 1603 query the database with parameters received from the slave 1604 device. 1606 O.12: The database MUST respond to a query from the master device 1607 containing parameters from a slave device. 1609 O.13: A master device MUST repeat the query to the database for the 1610 available channels as often as required by the regulation 1611 (e.g., FCC requires once per day) to verify that the operating 1612 channels continue to remain available. 1614 O.14: A master device which changes its location more than a 1615 threshold distance (specified by local regulatory policy) 1616 during its operation, MUST query the database for available 1617 operating channels each time it moves more than the threshold 1618 distance (e.g., FCC specifies 100m) from the location it 1619 previously made the query. 1621 O.15: According to local regulator policy, a master device may 1622 contact a database via proxy service of another master device. 1624 O.16: A master device MUST be able to query the whitespace database 1625 for channel availability information for a specific expected 1626 coverage area around its current location. 1628 O.17: A Master device MUST include its unique identity in all 1629 message exchanges with the database. 1631 6.3. Guidelines 1633 The current scope of the working group is limited and is reflected in 1634 the requirements captured in Section 6.1. However white space 1635 technology itself is expected to evolve and address other aspects 1636 such as co-existence and interference avoidance, spectrum brokering, 1637 alternative spectrum bands, etc. The design of the data model and 1638 protocol should be cognizant of the evolving nature of white space 1639 technology and consider the following set of guidelines in the 1640 development of the data model and protocol: 1642 1. The data model SHOULD provide a modular design separating out 1643 messaging specific, administrative specific, and spectrum 1644 specific parts into separate modules. 1646 2. The protocol SHOULD support determination of which administrative 1647 specific and spectrum specific modules are used. 1649 7. IANA Considerations 1651 This document has no requests to IANA. 1653 8. Security Considerations 1655 Threat model for the PAWS protocol 1657 Assumptions: 1659 It is assumed that an attacker has full access to the network medium 1660 between the master device and the white space database. The attacker 1661 may be able to eavesdrop on any communications between these 1662 entities. The link between the master device and the white space 1663 database can be wired or wireless and provides IP connectivity. 1665 It is assumed that both the master device and the white space 1666 database have NOT been compromised from a security standpoint. 1668 Threat 1: User modifies a device to masquerade as another valid 1669 certified device 1671 Regulatory environments require that devices be certified and 1672 register in ways that accurately reflect their certification. 1673 Without suitable protection mechanisms, devices could simply 1674 listen to registration exchanges, and later registering claiming 1675 to be those other devices. Such replays would allow false 1676 registration, violating regulatory regimes. A white space 1677 database may be operated by a commercial entity which restricts 1678 access only to authorized users. A master device MAY need to 1679 identify itself to the database and be authorized to obtain 1680 information about available channels. 1682 Threat 2: Spoofed white space database 1684 A master device discovers a white space database(s) through which 1685 it can query for channel information. The master device needs to 1686 ensure that the white space database with which it communicates 1687 with is an authentic entity. The white space database needs to 1688 provide its identity to the master device which can confirm the 1689 validity/authenticity of the database. An attacker may attempt to 1690 spoof a white space database and provide responses to a master 1691 device which are malicious and result in the master device causing 1692 interference to the primary user of the spectrum. 1694 Threat 3: Modifying a query request 1696 An attacker may modify the query request sent by a master device 1697 to a white space database. The attacker may change the location 1698 of the device or the capabilities in terms of its transmit power 1699 or antenna height etc. which could result in the database 1700 responding with incorrect information about available channels or 1701 max transmit power allowed. The result of such an attack is that 1702 the master device would cause interference to the primary user of 1703 the spectrum. It could also result in a denial of service to the 1704 master device by indicating that no channels are available. 1706 Threat 4: Modifying a query response 1708 An attacker could modify the query response sent by the white 1709 space database to a master device. The channel information or 1710 transmit power allowed type of parameters carried in the response 1711 could be modified by the attacker resulting in the master device 1712 using channels that are not available at a location or 1713 transmitting at a greater power level than allowed resulting in 1714 interference to the primary user of that spectrum. Alternatively 1715 the attacker may indicate no channel availability at a location 1716 resulting in a denial of service to the master device. 1718 Threat 5: Unauthorized use of channels by an uncertified device 1720 An attacker may be a master device which is not certified for use 1721 by the relevant regulatory body. The attacker may listen to the 1722 communication between a valid master device and white space 1723 database and utilize the information about available channels in 1724 the response message by utilizing those channels. The result of 1725 such an attack is unauthorized use of channels by a master device 1726 which is not certified to operate. The master device querying the 1727 white space database may be operated by a law-enforcement agency 1728 and the communications between the device and the database are 1729 intended to be kept private. A malicious device should not be 1730 able to eavesdrop on such communications. 1732 Threat 6: Third party tracking of white space device location and 1733 identity 1735 A white space database in a regulatory domain may require a master 1736 device to provide its identity in addition to its location in the 1737 query request. Such location/identity information can be gleaned 1738 by an eavesdropper and used for tracking purposes. A master 1739 device may prefer to keep the location/identity information hidden 1740 from eavesdroppers, hence the protocol should provide a means to 1741 protect the location and identity information of the master device 1742 and prevent tracking of locations associated with a white space 1743 database query. When the master device sends both its identity 1744 and location to the DB, the DB is able to track it. If a 1745 regulatory domain does not require the master device to provide 1746 its identity to the white space database, the master device may 1747 decide not to send its identity, to prevent being tracked by the 1748 DB. 1750 Threat 7: Malicious individual acts as a PAWS entity (spoofing DB or 1751 as MiM) to terminate or unfairly limit spectrum access of devices for 1752 reasons other than incumbent protection 1754 A white space database MAY include a mechanism by which service 1755 and channels allocated to a master device can be revoked by 1756 sending an unsolicited message. A malicious node can pretend to 1757 be the white space database with which a master device has 1758 registered or obtained channel information from and send a revoke 1759 message to that device. This results in denial of service to the 1760 master device. 1762 Threat 8: Natural disaster resulting in inability to obtain 1763 authorization for white space spectrum use by emergency responders 1765 In the case of a sizable natural disaster a lot of Internet 1766 infrastructure ceases to function. Emergency services users need 1767 to reconstitute quickly and will rely on establishing radio WANs. 1768 The potential for lot of radio WAN gear that has been unused 1769 suddenly needs to be pressed into action. And the radio WANs need 1770 frequency authorizations to function. Regulatory entities may 1771 also authorize usage of additional spectrum in the affected areas. 1772 The white space radio entities may need to establish communication 1773 with a database and obtain authorizations. In cases where 1774 communication with the white space database fails, the white space 1775 devices cannot utilize white space spectrum. Emergency services, 1776 which require more spectrum precisely at locations where network 1777 infrastructure is malfunctioning or overloaded, backup 1778 communication channels and distributed white space databases are 1779 needed to overcome such circumstances. Alternatively there may be 1780 other mechanisms which allow the use of spectrum by emergency 1781 service equipment without strict authorization or with liberal 1782 interpretation of the regulatory policy for white space usage. 1784 The security requirements arising from the above threats are captured 1785 in the requirements of section 6.1. 1787 9. Summary and Conclusion 1789 Wireless spectrum is a scarce resource. As the demand for spectrum 1790 grows, there is a need to more efficiently utilize the available and 1791 allocated spectrum. Cognitive radio technologies enable the 1792 efficient usage of spectrum via means such as sensing or by querying 1793 a database to determine available spectrum at a given location for 1794 opportunistic use. White space is the general term used to refer to 1795 the bands within the spectrum which is available for secondary use at 1796 a given location. In order to use this spectrum a device needs to 1797 query a database which maintains information about the available 1798 channels within a band. A protocol is necessary for communication 1799 between the devices and databases which would be globally applicable. 1801 The document describes some examples of the role of the white space 1802 database in the operation of a radio network and also shows examples 1803 of services provided to the user of a TVWS device. From these use 1804 cases, requirements are determined. These requirements are to be 1805 used as input to the definition of a Protocol to Access White Space 1806 database (PAWS). 1808 10. Acknowledgements 1810 The authors acknowledge Gabor Bajko, Teco Boot, Nancy Bravin, Rex 1811 Buddenberg, Gerald Chouinard, Stephen Farrell, Michael Fitch, Joel M. 1812 Halpern, Jussi Kahtava, Paul Lambert, Brian Rosen, Andy Sago, Peter 1813 Stanforth, John Stine and, Juan Carlos Zuniga for their contributions 1814 to this document. 1816 11. References 1818 11.1. Normative References 1820 [802.11p] IEEE, "IEEE Standard for Information technology - 1821 Telecommunications and information exchange between 1822 systems - Local and metropolitan area networks - Specific 1823 requirements; Part 11: Wireless LAN Medium Access Control 1824 (MAC) and Physical Layer (PHY) Specifications; Amendment 1825 6: Wireless Access in Vehicular Environments; http:// 1826 standards.ieee.org/getieee802/download/802.11p-2010.pdf", 1827 July 2010. 1829 [802.22] IEEE, "IEEE Standard for Information technology - 1830 Telecommunications and information exchange between 1831 systems - Wireless Regional Area Networks (WRAN) - 1832 Specific requirements; Part 22: Cognitive Wireless RAN 1833 Medium Access Control (MAC) and Physical Layer (PHY) 1834 Specifications: Policies and Procedures for Operation in 1835 the TV bands", July 2011. 1837 [FCC47CFR90.210] 1838 FCC, "Title 47 Telecommunication CFR Chapter I - Federal 1839 Communication Commission Part 90 - Private Land Mobile 1840 Radio Services - Section 210 Emission masks; http:// 1841 edocket.access.gpo.gov/cfr_2010/octqtr/pdf/ 1842 47cfr90.210.pdf", October 2010. 1844 [RFC2119] IETF, "Key words for use in RFCs to Indicate Requirement 1845 Levels; 1846 http://www.rfc-editor.org/rfc/pdfrfc/rfc2119.txt.pdf", 1847 March 1997. 1849 11.2. Informative References 1851 [3MOO] FCC, "Federal Communications Commission, Third Memorandum 1852 Opinion and Order", April 2012. 1854 [DDR] Ofcom - Independent regulator and competition authority 1855 for the UK communications industries, "Digital Dividend 1856 Review; http://stakeholders.ofcom.org.uk/spectrum/ 1857 project-pages/ddr/". 1859 [DTV] "Digital TV Transition; http://www.dtv.gov". 1861 [ECC Report 159] 1862 Electronic Communications Committee (ECC) within the 1863 European Conference of Postal and Telecommunications 1864 Administrations (CEPT), "TECHNICAL AND OPERATIONAL 1865 REQUIREMENTS FOR THE POSSIBLE OPERATION OF COGNITIVE RADIO 1866 SYSTEMS IN THE 'WHITE SPACES' OF THE FREQUENCY BAND 470- 1867 590 MHZ; http://www.erodocdb.dk/Docs/doc98/official/pdf/ 1868 ECCREP159.PDF", January 2011. 1870 [FCC Ruling] 1871 FCC, "Federal Communications Commission, "Unlicensed 1872 Operation in the TV Broadcast Bands; 1873 http://edocket.access.gpo.gov/2010/pdf/2010-30184.pdf"", 1874 December 2010. 1876 [Ofcom Implementing] 1877 Ofcom, "Ofcom, "Implementing Geolocation; http:// 1878 stakeholders.ofcom.org.uk/consultations/geolocation/ 1879 statement/"", September 2011. 1881 [Ofcom Requirements] 1882 Ofcom, "Ofcom, Regulatory requirements for white space 1883 devices in the UHF TV band; http://www.cept.org/Documents/ 1884 se-43/6161/ 1885 SE43(12)Info11_Ofcom-regulatory-requirements-for-WSDs-in- 1886 the-UHF-TV-band", July 2012. 1888 [Spectrum Framework Review] 1889 Ofcom - Independent regulator and competition authority 1890 for the UK communications industries, "Spectrum Framework 1891 Review; 1892 http://stakeholders.ofcom.org.uk/consultations/sfr/", 1893 February 2005. 1895 [TV Whitespace Tutorial Intro] 1896 IEEE 802 Executive Committee Study Group on TV White 1897 Spaces, "TV Whitespace Tutorial Intro; http:// 1898 grouper.ieee.org/groups/802/802_tutorials/2009-03/ 1899 2009-03-10%20TV%20Whitespace%20Tutorial%20r0.pdf", 1900 March 2009. 1902 Authors' Addresses 1904 Scott Probasco (editor) 1906 Email: scott@probasco.me 1908 Basavaraj Patil 1910 Email: bpatil@ovi.com