idnits 2.17.1 draft-ietf-paws-problem-stmt-usecases-rqmts-03.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 (February 29, 2012) is 4440 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'PAWS-PS' is defined on line 1770, but no explicit reference was found in the text == Unused Reference: 'RFC5222' is defined on line 1808, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 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 Nokia 5 Expires: September 1, 2012 February 29, 2012 7 Protocol to Access White Space database: PS, use cases and rqmts 8 draft-ietf-paws-problem-stmt-usecases-rqmts-03 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 the concept of TV White Spaces. It also 23 describes the problems that need to be addressed to enable white 24 space spectrum for additional uses, without causing interference to 25 currently assigned use, by querying a database which stores 26 information about the channel availability at any given location and 27 time. A number of possible use cases of white space spectrum and 28 technology as well as a set of requirements for the database query 29 protocol are also described. 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 September 1, 2012. 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 . . . . . 8 75 3.3. Background information on white space in the UK . . . . . 9 76 3.4. Air Interfaces . . . . . . . . . . . . . . . . . . . . . . 9 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. White space serving as backhaul . . . . . . . . . . . 18 85 4.2.4. Rapid deployed network for emergency scenario . . . . 19 86 4.2.5. Mobility . . . . . . . . . . . . . . . . . . . . . . . 20 87 4.2.6. Indoor Networking . . . . . . . . . . . . . . . . . . 23 88 4.2.7. Machine to Machine (M2M) . . . . . . . . . . . . . . . 24 89 5. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 26 90 5.1. Global applicability . . . . . . . . . . . . . . . . . . . 27 91 5.2. Database discovery . . . . . . . . . . . . . . . . . . . . 28 92 5.3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 29 93 5.4. Data model definition . . . . . . . . . . . . . . . . . . 29 94 6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 29 95 6.1. Normative Requirements . . . . . . . . . . . . . . . . . . 29 96 6.2. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . 35 97 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 98 8. Security Considerations . . . . . . . . . . . . . . . . . . . 35 99 9. Summary and Conclusion . . . . . . . . . . . . . . . . . . . . 38 100 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 39 101 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39 102 11.1. Normative References . . . . . . . . . . . . . . . . . . . 39 103 11.2. Informative References . . . . . . . . . . . . . . . . . . 40 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41 106 1. Introduction 108 1.1. Introduction to white space 110 Wireless spectrum is a commodity that is regulated by governments. 111 The spectrum is used for various purposes, which include but are not 112 limited to entertainment (e.g. radio and television), communication 113 (telephony and Internet access), military (radars etc.) and, 114 navigation (satellite communication, GPS). Portions of the radio 115 spectrum that are assigned to a licensed user but are unused or 116 unoccupied at specific locations and times are defined as "white 117 space". The concept of allowing additional transmissions (which may 118 or may not be licensed) in white space is a technique to "unlock" 119 existing spectrum for new use. An obvious requirement is that these 120 additional transmissions do not interfere with the assigned use of 121 the spectrum. One interesting observation is that often, in a given 122 physical location, the assigned user(s) may not be using the entire 123 band assigned to them. The available spectrum for additional 124 transmissions would then depend on the location of the additional 125 user. The fundamental issue is how to determine for a specific 126 location and specific time, if any of the assigned spectrum is 127 available for additional use. Academia and Industry have studied 128 multiple cognitive radio mechanisms for use in such a scenario. One 129 simple mechanism is to use a geospatial database that records the 130 assigned users occupation, and require the additional users to check 131 the database prior to selecting what part of the spectrum they use. 132 Such databases could be available on the Internet for query by 133 additional users. 135 Spectrum useable for data communications, especially wireless 136 Internet communications, is scarce. One area which has received much 137 attention globally is the TV white space: portions of the TV band 138 that are not used by broadcasters in a given area. In 2008 the 139 United States regulator (the FCC) took initial steps when they 140 published their first ruling on the use of TV white space, and then 141 followed it up with a final ruling in 2010 [FCC Ruling]. Finland 142 passed an Act in 2009 enabling testing of cognitive radio systems in 143 the TV white space. The ECC has completed Report 159 [ECC Report 144 159] containing requirements for operation of cognitive radio systems 145 in the TV white space. Ofcom published in 2004 their Spectrum 146 Framework Review [Spectrum Framework Review] and their Digital 147 Dividend Review [DDR] in 2005, with proposals from 2009 onwards to 148 access TV white space, culminating in the 2011 Ofcom Statement 149 Implementing Geolocation [Ofcom Implementing]. More countries are 150 expected to provide access to their TV spectrum in similar ways. Any 151 entity that is assigned spectrum that is not densely used may be 152 asked to give it up in one way or another for more intensive use. 153 Providing a mechanism by which additional users share the spectrum 154 with the assigned user is attractive in many bands in many countries. 156 Television transmission until now has primarily been analog. The 157 switch to digital transmission has begun. As a result the spectrum 158 assigned for television transmission can now be more effectively 159 used. Unused channels and bands between channels can be used by 160 additional users as long as they do not interfere with the service 161 for which that channel is assigned. While urban areas tend to have 162 dense usage of spectrum and a number of TV channels, the same is not 163 true in semi-rural, rural and remote areas. There can be a number of 164 unused TV channels in such areas that can be used for other services. 165 Figure 1 shows TV white space within the lower UHF band: 167 Avg | 168 usage| |-------------- White Space 169 | | | | | | 170 0.6| || || V V || 171 | || ||| | || 172 0.4| || |||| | || 173 | || |||| | ||<----TV transmission 174 0.2| || |||| | || 175 |---------------------------------------- 176 400 500 600 700 800 177 Frequency in MHz -> 179 Figure 1: High level view of TV White Space 181 The fundamental issue is how to determine for a specific location and 182 specific time if any of the spectrum is available for additional use. 183 There are two dimensions of use that may be interesting: space (the 184 area in which an additional user would not interfere with the 185 assigned use), and time: when the additional transmission would not 186 interfere with the assigned use. In this discussion, we consider the 187 time element to be relatively long term (hours in a day) rather than 188 short term (fractions of a second). Location in this discussion is 189 geolocation: where the transmitters (and sometimes receivers) are 190 located relative to one another. In operation, the database records 191 the assigned user's transmitter (and some times receiver) locations 192 along with basic transmission characteristics such as antenna height, 193 and sometimes power. Using rules established by the local regulator, 194 the database calculates an exclusion zone for each assigned user, and 195 attaches a time schedule to that use. The additional user queries 196 the database with its location. The database intersects the 197 exclusion zones with the queried location, and returns the portion of 198 the spectrum not in any exclusion zone. Such methods of geospatial 199 database query to avoid interference have been shown to achieve 200 favorable results, and are thus the basis for rulings by the FCC and 201 reports from ECC and Ofcom. In any country, the rules for which 202 assigned entities are entitled to protection, how the exclusion zones 203 are calculated, and what the limits of use are by additional users 204 may vary. However, the fundamental notion of recording assigned 205 users, calculating exclusion zones, querying by location and 206 returning available spectrum (and the schedule for that spectrum) are 207 common. 209 This document includes the problem statement, use cases and 210 requirements associated with the use of white space spectrum by 211 secondary users via a database query protocol. 213 1.2. Scope 215 1.2.1. In Scope 217 This document applies only to communications required for basic 218 service in TV white space. The protocol will enable a white space 219 radio device to complete the following tasks: 221 1. Determine the relevant white space database to query. 223 2. Connect to the database using a well-defined access method. 225 3. Register with the database using a well-defined protocol. 227 4. Provide its geolocation and perhaps other data to the database 228 using a well-defined format for querying the database. 230 5. Receive in response to the query a list of currently available 231 white space channels or frequencies using a well-defined format 232 for the information. 234 As a result, some of the scenarios described in the following section 235 are out of scope for this specification (although they might be 236 addressed by future specifications). 238 1.2.2. Out of Scope 240 The following topics are out of scope for this specification: 242 Co-existence and interference avoidance of white space devices 243 within the same spectrum 245 Provisioning (releasing new spectrum for white space use) 247 2. Conventions and Terminology 249 2.1. Conventions Used in This Document 251 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 252 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 253 document are to be interpreted as described in RFC 2119 [RFC2119]. 255 2.2. Terminology 257 Database 259 In the context of white space and cognitive radio technologies, 260 the database is an entity which contains, but is not limited to, 261 current information about available spectrum at any given location 262 and other types of related (to the white space spectrum) or 263 relevant information. 265 Device ID 267 A unique number for each master device and slave device that 268 identifies the manufacturer, model number and serial number. 270 Location Based Service 272 An application or device which provides data, information or 273 service to a user based on their location. 275 Master Device 277 A device which queries the WS Database to find out the available 278 operating channels. 280 Protected Entity 282 An assigned user of white space spectrum which is afforded 283 protection against interference by additional users (white space 284 devices) for its use in a given area and time. 286 Protected Contour 288 The exclusion area for a Protected Entity, held in the database 289 and expressed as a polygon with geospatial points as the vertices. 291 Slave Device 293 A device which uses the spectrum made available by a master 294 device. 296 TV White Space 298 TV white space refers specifically to radio spectrum which has 299 been allocated for TV broadcast, but is not occupied by a TV 300 broadcast, or other assigned user (such as a wireless microphone), 301 at a specific location and time. 303 TV White Space Device (TVWSD) 305 A White Space Device that operates in the TV bands. 307 White Space (WS) 309 Radio spectrum which is not fully occupied at a specific location 310 and time. 312 White Space Device (WSD) 314 A device which opportunistically uses some part of white space 315 spectrum. A white space device can be an access point, base 316 station, a portable device or similar. A white space device may 317 be required by local regulations to query a database with its 318 location to obtain information about available spectrum. 320 3. Prior Work 322 3.1. The concept of Cognitive Radio 324 A cognitive radio uses knowledge of the local radio environment to 325 dynamically adapt its own configuration and function properly in a 326 changing radio environment. Knowledge of the local radio environment 327 can come from various technology mechanisms including sensing 328 (attempting to ascertain primary users by listening for them within 329 the spectrum), location determination and Internet connectivity to a 330 database to learn the details of the local radio environment. White 331 Space is one implementation of cognitive radio. Because a cognitive 332 radio adapts itself to the available spectrum in a manner that 333 prevents the creation of harmful interference, the spectrum can be 334 shared among different radio users. 336 3.2. Background information on white space in the US 338 Television transmission in the United States has moved to the use of 339 digital signals as of June 12, 2009. Since June 13, 2009, all full- 340 power U.S. television stations have broadcast over-the-air signals in 341 digital only. An important benefit of the switch to all-digital 342 broadcasting is that it freed up parts of the valuable broadcast 343 spectrum. More information about the switch to digital transmission 344 is at : [DTV]. 346 Besides the switch to digital transmission for TV, the guard bands 347 that exist to protect the signals between stations can be used for 348 other purposes. The FCC has made this spectrum available for 349 unlicensed use and this is generally referred to as white space. 350 Please see the details of the FCC ruling and regulations in [FCC 351 Ruling]. The spectrum can be used to provide wireless broadband as 352 an example. 354 3.3. Background information on white space in the UK 356 Background information on white space in UK Since its launch in 2005, 357 Ofcom's Digital Dividend Review [DDR] has considered how to make the 358 spectrum freed up by digital switchover available for new uses, 359 including the capacity available within the spectrum that is retained 360 to carry the digital terrestrial television service. Similarly to 361 the US, this interleaved or guard spectrum occurs because not all the 362 spectrum in any particular location will be used for terrestrial 363 television and so is available for other services, as long as they 364 can interleave their usage around the existing users. 366 In its September 2011 Statement [Ofcom Implementing] Ofcom says that 367 a key element in enabling white space usage in the TV bands is the 368 definition and provision of a database which, given a device's 369 location, can tell the device which frequency channels and power 370 levels it is able to use without causing harmful interference to 371 other licensed users in the vicinity. Ofcom will specify 372 requirements to be met by such geolocation databases. It also says 373 that the technology has the possibility of being usefully applied 374 elsewhere in the radio spectrum to ensure it is used to maximum 375 benefit. For example, it may have potential in making spectrum 376 available for new uses following any switch to digital radio 377 services. Alternatively it may be helpful in exploiting some of the 378 public sector spectrum holdings. Ofcom will continue to consider 379 other areas of the radio spectrum where white space usage may be of 380 benefit. 382 3.4. Air Interfaces 384 Efforts are ongoing to specify air-interfaces for use in white space 385 spectrum. IEEE 802.11af, IEEE 802.15.4m and IEEE 802.22 are all 386 examples. Other air interfaces could be specified in the future such 387 as LTE. 389 4. Use cases and protocol services 391 There are many potential use cases that could be considered for the 392 TV white space spectrum. Providing broadband Internet access in 393 hotspots, rural and underserved areas are examples. Available 394 channels may also be used to provide Internet 'backhaul' for 395 traditional Wi-Fi hotspots, or by towns and cities to monitor/control 396 traffic lights or read utility meters. Still other use cases include 397 the ability to offload data traffic from another Internet access 398 network (e.g. 3G cellular network) or to deliver location based 399 services. Some of these use cases are described in the following 400 sections. 402 4.1. Protocol services 404 A complete protocol solution must provide all services that are 405 essential to enable the white space paradigm. Before a white space 406 device can request service from a white space database, such as a 407 query for a list of available channels, the white space device must 408 first locate or "discover" a suitable database. Additionally, some 409 regulatory authorities require the white space device to register 410 with the database as a first step. This section describes the 411 services required from the protocol. 413 4.1.1. White space database discovery 415 White space database discovery is preliminary to creating a radio 416 network using white space; it is a prerequisite to the use cases 417 below. The radio network is created by a master device. Before the 418 master device can transmit in white space spectrum, it must contact a 419 trusted database where the device can learn if any channels are 420 available for it to use. The master device will need to discover a 421 trusted database in the relevant regulatory domain, using the 422 following steps: 424 1. The master device is connected to the Internet by any means other 425 than using the white space radio. A local regulator may identify 426 exception cases where a master may initialize over white space 427 (e.g. the FCC allows a master to initialize over the TV white 428 space in certain conditions). 430 2. The master device constructs and sends a service request over the 431 Internet to discover availability of trusted databases in the 432 local regulatory domain and waits for responses. 434 3. If no acceptable response is received within a pre-configured 435 time limit, the master device concludes that no trusted database 436 is available. If at least one response is received, the master 437 device evaluates the response(s) to determine if a trusted 438 database can be identified where the master device is able to 439 receive service from the database. 441 Optionally the radio device is pre-programmed with the Internet 442 address of at least one trusted database. The device can establish 443 contact with a trusted database using one of the pre-programmed 444 Internet addresses and establish a white space network (as described 445 in one of the following use cases). 447 Optionally the initial query will be made to a listing approved by 448 the national regulator for the domain of operation (e.g. a website 449 either hosted by or under control of the national regulator) which 450 maintains a list of WS databases and their Internet addresses. The 451 query results in the list of databases and their Internet addresses 452 being sent to the master, which then evaluates the response to 453 determine if a trusted database can be identified where the master 454 device is able to register and receive service from the database. 456 4.1.2. Device registration with trusted Database 458 Registration may be preliminary to creating a radio network using 459 white space; in some regulatory domains, for some device types, it is 460 a prerequisite to the use cases below. The radio network is created 461 by a master device. Before the master device can transmit in white 462 space spectrum, it must contact a trusted database where the device 463 can learn if any channels are available for it to use. Before the 464 database will provide information on available radio channels, the 465 master device must register with the trusted database. Specific 466 requirements for registration come from individual regulatory domains 467 and may be different. 469 Figure 2 shows an example deployment of this scenario. 471 \|/ ---------- 472 | |Database| 473 | .---. /--------- 474 |-|---------| ( ) / 475 \|/ | Master | / \ 476 | / | |========( Internet ) 477 | / |-----------| \ / 478 +-|----+ (TDD AirIF) ( ) 479 |Master| / (----) 480 | | / 481 +------+ 483 Figure 2: Example illustration of registration requirement in white 484 space use-case 486 A simplified operational scenario showing registration consists of 487 the following steps: 489 1. The master device must register with its most current and up-to- 490 date information. Typically the master device will register 491 prior to operating in white space for the first time after power 492 up, after changing location by a predetermined distance, and 493 after regular time intervals. 495 2. The master device shall provide to the database during 496 registration all information required according to local 497 regulatory requirements. This information may include, but is 498 not limited to, the Device ID, serial number assigned by the 499 manufacturer the device's location, device antenna height above 500 ground, name of the individual or business that owns the device, 501 name of a contact person responsible for the device's operation 502 address for the contact person, email address for the contact 503 person and phone number of the contact person. 505 3. The database shall respond to the registration request with an 506 acknowledgement code to indicate the success or failure of the 507 registration request. Additional information may be provided 508 according to local regulator requirements. 510 4.2. Use cases 512 4.2.1. Hotspot: urban Internet connectivity service 514 In this use case Internet connectivity service is provided in a 515 "hotspot" to local users. Typical deployment scenarios include urban 516 areas where Internet connectivity is provided to local businesses and 517 residents, and campus environments where Internet connectivity is 518 provided to local buildings and relatively small outdoor areas. This 519 deployment scenario is typically characterized by multiple masters 520 (APs or hotspots) in close proximity, with low antenna height, cells 521 with relatively small radius (a few kilometers or less), and limited 522 numbers of available radio channels. Many of the masters/APs are 523 assumed to be individually deployed and operated, i.e. there is no 524 coordination between many of the masters/APs. The masters/APs in 525 this scenario use a TDD radio technology. Each master/AP has a 526 connection to the Internet and may provide Internet connectivity to 527 other master and slave devices. 529 Figure 3 shows an example deployment of this scenario. 531 -------- 532 |Device|\ \|/ ---------- 533 | 1 | (TDD AirIF)\ | |Database| 534 -------- \ | (----) /--------- 535 | \ |-|---------| ( ) / 536 | \| Master | / \ 537 -------- /| |========( Internet ) 538 |Device| /(TDD AirIF)/ |-----------| \ / 539 | 2 | / / ( ) 540 ------- / (----) 541 o | / 542 o | (TDD AirIF) 543 o | / 544 --------/ 545 |Device| 546 | n | 547 -------- 549 Figure 3: Hotspot service using TV white space spectrum 551 Once a master/AP has been correctly installed and configured, a 552 simplified power up and operation scenario utilizing TV White Space 553 to provide Internet connectivity service to slave devices, including 554 the ability to clear WSDs from select channels, is described. This 555 scenario consists of the following steps: 557 1. The master/AP powers up; however its WS radio and all other WS 558 capable devices will power up in idle/listen only mode (no 559 active transmissions on the WS frequency band). A local 560 regulator may identify exception cases where a master may 561 initialize over white space (e.g. the FCC allows a master to 562 initialize over TV white space in certain conditions). 564 2. The master/AP has Internet connectivity, determines its location 565 (either from location determination capability or from saved 566 value that was set during installation), and establishes a 567 connection to a trusted white space database (see 568 Section 4.1.1). 570 3. The master/AP registers with the trusted database according to 571 regulatory domain requirements (see Section 4.1.2). 573 4. Following the successful registration process (if registration 574 is required), the master/AP will send a query to the trusted 575 database requesting a list of available WS channels based upon 576 its geolocation. The complete set of parameters to be provided 577 from the master to the database is specified by the local 578 regulator. Parameters may include WSD location, accuracy of 579 that location, device antenna height, device identifier of a 580 slave device requesting channel information. 582 5. If the master/AP has met all regulatory domain requirements 583 (e.g. been previously authenticated, etc), the database responds 584 with a list of available white space channels that the master 585 may use, and optionally a duration of time for their use, 586 associated maximum power levels or a notification of any 587 additional requirements for sensing. 589 6. Once the master/AP has met all regulatory domain requirements 590 (e.g. authenticated the WS channel list response message from 591 the database, etc), the AP selects one or more available WS 592 channels from the list. 594 7. The slave or user device scans the TV bands to locate a 595 master/AP transmission, and associates with the AP. 597 8. The slave/user device queries the master for a channel list. In 598 the query the slave/user device provides attributes that are 599 defined by local regulations. These may include the slaves' 600 Device ID and its geolocation. 602 9. Once the master/AP has met all regulatory domain requirements 603 (e.g. validating the Device ID with the trusted database, etc) 604 the master provides the list of channels locally available to 605 the slave/user device. 607 10. The master sends an enabling signal to establish that the slave/ 608 user device is still within reception range of the master. This 609 signal shall be encoded to ensure that the signal originates 610 from the master that provided the available list of channels. 612 11. Periodically, at an interval established by the local regulator, 613 the slave/user device must receive an enabling signal from the 614 master that provided the available list of channels or contact a 615 master to re-verify or re-establish the list of available 616 channels. 618 12. The master/AP must periodically repeat the process to request a 619 channel list from the database, steps 4 through 6 above. The 620 frequency to repeat the process is determined by the local 621 regulator. If the response from the database indicates a 622 channel being used by the master/AP is not available, the 623 master/AP must stop transmitting on that channel immediately. 624 In addition or optionally, the database may send a message to 625 the master/AP to rescind the availability of one or more 626 channels. The master/AP must stop transmitting on that channel 627 immediately. 629 13. The slave or user device must periodically repeat the process to 630 request a channel list from the master/AP, steps 8 and 9 above. 631 The frequency to repeat the process is determined by the local 632 regulator. If the response from the master/AP indicates that a 633 channel being used by the slave or user device is not available, 634 the slave or user device must stop transmitting on that channel 635 immediately. In addition or optionally, the database may send a 636 message to the master/AP to rescind the availability of one or 637 more channels. The master/AP must then notify the slave or user 638 device of the rescinded channels. The slave or user device must 639 stop transmitting on that channel immediately. 641 4.2.2. Wide-Area or Rural Internet broadband access 643 In this use case, Internet broadband access is provided as a Wide- 644 Area Network (WAN) or Wireless Regional Area Network (WRAN). A 645 typical deployment scenario is a wide area or rural area, where 646 Internet broadband access is provided to local businesses and 647 residents from a master (i.e., BS) connected to the Internet. This 648 deployment scenario is typically characterized by one or more fixed 649 master(s)/BS(s), cells with relatively large radius (tens of 650 kilometers, up to 100 km), and a number of available radio channels. 651 Some of the masters/BSs may be deployed and operated by a single 652 entity, i.e., there can be centralized coordination between these 653 masters/BSs, whereas other masters/BSs may be deployed and operated 654 by operators competing for the radio channels where decentralized 655 coordination using the air-interface would be required. The BS in 656 this scenario uses a TDD radio technology and transmits at or below a 657 transmit power (EIRP) limit established by the local regulator. Each 658 base station has a connection to the Internet and may provide 659 Internet connectivity to multiple slaves/user devices. End-user 660 terminals or devices may be fixed or portable. 662 Figure 4 shows an example deployment of this scenario. 664 ------- 665 |Slave|\ \|/ ---------- 666 |Dev 1| (TDD AirIF) | |Database| 667 ------- \ | .---. /---------- 668 o \ |-|---------| ( ) / 669 o | Master | / \ 670 o / | (BS) |========( Internet ) 671 o / |-----------| \ / 672 ------- (TDD AirIF) ( ) 673 |Slave| / (----) 674 |Dev n| 675 ------- 677 Figure 4: Rural Internet broadband access using TV white space 678 spectrum 680 Once the master/BS has been professionally installed and configured, 681 a simplified power up and operation scenario utilizing TV White Space 682 to provide rural Internet broadband access consists of the following 683 steps: 685 1. The master/BS powers up; however its WS radio and all other WS 686 capable devices will power up in idle/listen-only mode (no 687 active transmissions on the WS frequency band). 689 2. The master/BS has Internet connectivity, determines its location 690 (either from location determination capability or from a saved 691 value that was set during installation), and establishes a 692 connection to a trusted white space database (see 693 Section 4.1.1). 695 3. The master/BS registers with the trusted database service (see 696 Section 4.1.2). Meanwhile the DB administrator may be required 697 to store and forward the registration information to the 698 regulatory authority. If a trusted white space database service 699 is not discovered, further operation of the WRAN may be allowed 700 according to local regulator policy (in this case operation of 701 the WRAN is outside the scope of the PAWS protocol). 703 4. Following the successful registration process (if registration 704 is required), the master/BS will send a query to the trusted 705 database requesting a list of available WS channels based upon 706 its geolocation. The complete set of parameters to be provided 707 from the master to the database is specified by the local 708 regulator. Parameters may include WSD identifier, location, 709 accuracy of that location, device antenna height, etc... 711 5. If the master/BS has been previously authenticated, the database 712 responds with a list of available white space channels that may 713 be used by the master/BS and optionally a maximum transmit power 714 (EIRP) for each channel, a duration of time the channel may be 715 used or a notification of any additional requirement for 716 sensing. 718 6. Once the master/BS authenticates the WS channel list response 719 message from the database, the master/BS selects an available WS 720 channel(s) from the list. Such selection may be improved based 721 on a set of queries to the DB involving a number of hypothetical 722 slave or user devices located at various locations over the 723 expected service area so that the final intersection of these 724 resulting WS channel lists allows the selection of a channel 725 that is likely available over the entire service area to avoid 726 potential interference at the time of slave/user terminal 727 association. The operator may also disallow some channels from 728 the list to suit local needs if required. 730 7. The slave or user device scans the TV bands to locate a WRAN 731 transmission, and associates with the master/BS. 733 8. The slave/user device provides its geolocation to the BS which, 734 in turn, queries the database for a list of channels available 735 at the slave's geolocation. 737 9. Once this list of available channels is received from the 738 database by the master, the latter will decide, based on this 739 list of available channels and on the lists for all its other 740 associated slaves/user devices whether it should: a) continue 741 operation on its current channel if this channel is available to 742 all slaves/user devices, b) continue operation on its current 743 channel and not allow association with the new slave/user device 744 in case this channel is not available at its location or c) 745 change channel to accommodate the new slave. In the latter 746 case, the master will notify all its associated slaves/user 747 devices of the new channel to which they have to move. 749 10. The master/BS must periodically repeat the process to request a 750 list of available channels from the database for itself and for 751 all its associated slaves/user devices. If the response from 752 the database indicates that the channel being used by the 753 master/BS is no longer available for its use, the master/BS must 754 indicate the new operating channel to all its slave/user 755 terminals, stop transmitting on the current channel and move to 756 the new operating channel immediately. If the channel that a 757 slave/user terminal is currently using is not longer included in 758 the list of locally available channels, the master may either 759 drop its association with the slave/user device so that this 760 device ceases all operation on its current channel or the master 761 may decide to move the entire cell to another channel to 762 accommodate the slave/user terminal and indicate the new 763 operating channel to all its slave/user devices before dropping 764 the link. The slave/user devices may then move to the 765 identified new operating channel or scan for another WRAN 766 transmission on a different channel. The frequency to repeat 767 the process is determined by the local regulator. 769 11. The slave/user device must transmit its new geographic location 770 every time it changes so that the repeated process described 771 under item 10 can rely on the most up-to-date geolocation of the 772 slave/user device. 774 4.2.3. White space serving as backhaul 776 In this use case Internet connectivity service is provided to users 777 over a more common wireless standard such as Wi-Fi with white space 778 entities providing backhaul connectivity to the Internet. In a 779 typical deployment scenario an end user has a device with a radio 780 such as Wi-Fi. An Internet service provider or a small business 781 owner wants to provide Wi-Fi Internet connectivity service to their 782 customers. The location where Internet connectivity service via 783 Wi-Fi is to be provided is within the coverage area of a white space 784 master (e.g. Hotspot or Wide-Area/Rural network). The service 785 provider installs a white space slave device and connects it to the 786 Wi-Fi access point(s). Wi-Fi access points with an integrated white 787 space slave component may also be used. This deployment scenario is 788 typically characterized by a WS master/AP/BS providing local 789 coverage. The master/AP has a connection to the Internet and 790 provides Internet connectivity to slave devices that are within its 791 coverage area. The WS slave device is 'bridged' to a Wi-Fi network 792 thereby enabling Internet connectivity service to Wi-Fi devices. The 793 WS Master/AP/BS which has some form of Internet connectivity (wired 794 or wireless) queries the database and obtains available channel 795 information. It then provides service using those channels to slave 796 devices which are within its coverage area. 798 Figure 5 shows an example deployment of this scenario. 800 \|/ white \|/ \|/ Wi-Fi \|/ 801 | space | | | 802 | | | |-|----| 803 |--------| |-|---------| |-|------|-| | Wi-Fi| 804 | | | Master | | Slave | | Dev | 805 |Internet|------| (AP/BS) | | Bridge | |------| 806 | | | | | to Wi-Fi | 807 |--------| |-----------| |----------| \|/ 808 | 809 |-|----| 810 | Wi-Fi| 811 | Dev | 812 |------| 814 Figure 5: WS for backhaul 816 Once the bridged device (WS + Wi-Fi) is connected to a master and WS 817 network, a simplified operation scenario of backhaul for Wi-Fi 818 consists of the following steps: 820 1. A bridged device (WS + Wi-Fi) is connected to a master device 821 operating in the WS spectrum. The bridged device operates as a 822 slave device in either Hotspot or Wide-Area/Rural Internet use 823 cases described above. 825 2. Once the slave device is connected to the master, the Wi-Fi 826 access point has Internet connectivity as well. 828 3. End users attach to the Wi-Fi network via their Wi-Fi enabled 829 devices and receive Internet connectivity. 831 4.2.4. Rapid deployed network for emergency scenario 833 Organizations involved in handling emergency operations often have a 834 fully owned and controlled infrastructure, with dedicated spectrum, 835 for day to day operation. However, lessons learned from recent 836 disasters show such infrastructures are often highly affected by the 837 disaster itself. To set up a replacement quickly, there is a need 838 for fast reallocation of spectrum, where in certain cases spectrum 839 can be cleared for disaster relief. To utilize unused or cleared 840 spectrum quickly and reliably, automation of allocation, assignment 841 and configuration is needed. A preferred option is to make use of a 842 robust protocol, already adopted by radio manufacturers. This 843 approach does in no way imply such organizations for disaster relief 844 must compete on spectrum allocation with other white spaces users, 845 but they can. A typical network topology would include wireless 846 access links to the public Internet or private network, wireless ad 847 hoc network radios working independent of a fixed infrastructure and 848 satellite links for backup where lack of coverage, overload or outage 849 of wireless access links occur. 851 Figure 6 shows an example deployment of this scenario. 853 \|/ 854 | ad hoc 855 | 856 |-|-------------| 857 | Master node | |------------| 858 \|/ | with | | Whitespace | 859 | ad hoc /| backhaul link | | Database | 860 | /------/ |---------------| |------------| 861 ---|------------/ | \ / 862 | Master node | | | (--/--) 863 | without | | ------( ) 864 | backhaul link | | Wireless / Private \ 865 ----------------\ | Access ( net or ) 866 \ | \ Internet ) 867 \ \|/ | -------( /\ 868 \ | ad hoc | | (------) \--------- 869 \ | | / | Other | 870 \--|------------- /Satellite | nodes | 871 | Master node | / Link ---------- 872 | with |/ 873 | backhaul link | 874 ----------------- 876 Figure 6: Rapid deployed network with partly connected nodes 878 In the ad hoc network, all nodes are master nodes in a way that they 879 allocate RF channels from the white space database. However, the 880 backhaul link may not be available to all nodes, such as depicted for 881 the left node in Figure 6. To handle RF channel allocation for such 882 nodes, a master node with a backhaul link relays or proxies the 883 database query for them. So master nodes without a backhaul link 884 follow the procedure as defined for clients. The ad hoc network 885 radios utilize the provided RF channels. Details on forming and 886 maintenance of the ad hoc network, including repair of segmented 887 networks caused by segments operating on different RF channels, is 888 out of scope of spectrum allocation. 890 4.2.5. Mobility 892 In this use case, the user has a non-fixed (portable or mobile) 893 device and is riding in a vehicle. The user wants to have 894 connectivity to another device which is also moving. Typical 895 deployment scenarios include urban areas and rural areas where the 896 user may connect to other users while moving. This deployment 897 scenario is typically characterized by a master device with low 898 antenna height, Internet connectivity by some connection that does 899 not utilize TV white space, and some means to predict its path of 900 mobility. This knowledge of mobility could be simple (GPS plus 901 accelerometer), sophisticated (GPS plus routing and mapping function) 902 or completely specified by the user via user-interface. 904 Figure 7 shows an example deployment of this scenario. 906 \|/ \|/ 907 | TDD Air Interface | 908 | | 909 +-|---------+ +-|---------+ 910 | TVWS | | TVWS | 911 |Master Dev | |Master Dev | 912 +-----------+ +-----------+ 913 \ (----) / 914 \ ( ) / 915 \ / \ / 916 ( Internet ) 917 \ / 918 ( )\----------+ 919 (----) | Database | 920 +----------+ 922 Figure 7: Example illustration of mobility in TV white space use-case 924 A simplified operational scenario utilizing TV whitespace to provide 925 connectivity service in a mobility environment consists of the 926 following steps: 928 1. The mobile master device powers up with its WS radio in idle or 929 listen mode only (no active transmission on the WS frequency 930 band). 932 2. The mobile master has Internet connectivity, determines its 933 location, and establishes a connection to a trusted white space 934 database (see Section 4.1.1). 936 3. The mobile master registers with the trusted database according 937 to regulatory domain requirements (see Section 4.1.2). 939 4. Following the successful registration process (if registration 940 is required), the mobile master will send a query to the trusted 941 database requesting a list of available WS channels based upon 942 its current location, other parameters required by the local 943 regulator (see Section 4.2.1, step 4) and a prediction of its 944 future location. The current location is specified in latitude 945 and longitude. The method to specify the future location is 946 TBD, potential methods include movement vector (direction and 947 velocity), a set of latitude/longitude points which specify a 948 closed polygon where the future location is within the polygon, 949 or similar. 951 5. If the mobile master has met all regulatory domain requirements 952 (e.g. been previously authenticated, etc), the database responds 953 with a list of available white space channels that the mobile 954 master may use, and optional information which may include (1) a 955 duration of time for the use of each channel (2) a maximum 956 transmit power for each channel and (3) notification of any 957 additional requirement for sensing. 959 6. Once the mobile master has met all regulatory domain 960 requirements (e.g. authenticated the WS channel list response 961 message from the database, etc), the master selects one or more 962 available WS channel(s) from the list for use. 964 7. The slave/user device scans to locate a mobile master 965 transmission, and associates with the mobile master. 967 8. The slave/user device queries the master for a channel list, 968 providing to the master the slave's device identification, and 969 optionally its geolocation and a prediction of its future 970 location. 972 9. Once the mobile master has met all regulatory domain 973 requirements (e.g. the slave's device identification is verified 974 by the database), the mobile master provides the list of 975 channels locally available to the slave/user device. 977 10. If the mobile master moves outside the predicted range of future 978 positions in step 4, it must repeat the process to request a 979 channel list from the database, steps 4 through 6 above. If the 980 response from the database indicates a channel being used by the 981 mobile master is not available, the master/AP must stop 982 transmitting on that channel immediately. 984 11. The slave or user device must periodically repeat the process to 985 request a channel list from the master/AP, steps 8 and 9 above. 986 The frequency to repeat the process is determined by the local 987 regulator. If the response from the master/AP indicates that a 988 channel being used by the slave or user device is not available, 989 the slave or user device must stop transmitting on that channel 990 immediately. In addition or optionally, the database may send a 991 message to the master/AP to rescind the availability of one or 992 more channels. The master/AP must then notify the slave or user 993 device of the rescinded channels. The slave or user device must 994 stop transmitting on that channel immediately. 996 4.2.6. Indoor Networking 998 In this use case, the users are inside a house or office. The users 999 want to have connectivity to the Internet or to equipment in the same 1000 or other houses / offices. This deployment scenario is typically 1001 characterized by master devices within buildings, that are connected 1002 to the Internet using a method that does not utilize whitespace. The 1003 master devices can establish whitespace links between themselves, or 1004 between themselves and one or more user devices. 1006 Figure 8 shows an example deployment of this scenario. 1008 \|/ 1009 | 1010 +-------+ | 1011 |TVWS |\ +-|---------+ 1012 |Usr Dev| WS AirIF \ | TVWS |\ 1013 +-------+ X|Master Dev | \ 1014 / +-----------+ \ 1015 +-------+ WS AirIF | \ +----------+ 1016 |TVWS |/ | \ (----) | Database | 1017 |Usr Dev| | \ ( ) /----------+ 1018 +-------+ WS AirIF \ / \ 1019 | X( Internet ) 1020 | / \ / 1021 +-------+ \|/ | / ( ) 1022 |TVWS |\ | | / (----) 1023 |Usr Dev| WS AirIF | | / 1024 +-------+ \ +-|---------+ / 1025 \ | TVWS | / 1026 |Master Dev |/ 1027 +-----------+ 1029 Figure 8: Example illustration of indoor TV white space use-case 1031 A simplified operational scenario utilizing TV whitespace to provide 1032 indoor networking consists of the following steps: 1034 1. The master device powers up with its whitespace radio in idle or 1035 listen mode only (no active transmission on the whitespace 1036 frequency band). 1038 2. The master device has Internet connectivity, determines its 1039 location (either from location determination capability or from a 1040 saved value that was set during installation), and establishes a 1041 connection to a trusted white space database (see Section 4.1.1). 1043 3. The master device registers with the trusted database according 1044 to regulatory domain requirements (see Section 4.1.2). 1046 4. Following the successful registration process (if registration is 1047 required), the master device sends a query to the trusted 1048 database requesting a list of available WS channels based upon 1049 its geolocation. The complete set of parameters to be provided 1050 from the master to the database is specified by the local 1051 regulator. Parameters may include WSD location, accuracy of that 1052 location, device antenna height, device identifier of a slave 1053 device requesting channel information. 1055 5. If the master has met all regulatory requirements, the database 1056 responds with a list of available white space channels that the 1057 master device may use, and optional information which may include 1058 inter alia (1) a duration of time for the use of each channel 1059 (channel validity time) (2) a maximum radiated power for each 1060 channel, and (3) directivity and other antenna information. 1062 6. Once the master device authenticates the whitespace channel list 1063 response message from the database, the master device selects one 1064 or more available whitespace channels from the list. 1066 7. The user device(s) scan(s) the white space bands to locate the 1067 master device transmissions, and associates with the master. 1069 4.2.7. Machine to Machine (M2M) 1071 In this use case, each "machine" includes a white space slave device 1072 and can be located anywhere, fixed or on the move. Each machine 1073 needs to have connectivity to the Internet and or to other machines 1074 in the vicinity. Machine communication over a TVWS channel, whether 1075 to a master device or to another machine (slave device), is under the 1076 control of a master device. This deployment scenario is typically 1077 characterized by a master device with Internet connectivity by some 1078 connection that does not utilize TV white space. 1080 Figure 9 shows an example deployment of this scenario. 1082 \|/ 1083 | 1084 | 1085 +-|---------+ 1086 | TVWS |\ 1087 /|Master Dev | \ 1088 / +-----------+ \ 1089 WS AirIF \ +----------+ 1090 +-------+ / \ (----) | Database | 1091 |Machine| \ ( ) /----------+ 1092 +-------+ \ / \ 1093 | X( Internet ) 1094 WS AirIF \ / 1095 | ( ) 1096 +-------+ (----) 1097 |Machine| 1098 +-------+ \ +-------+ 1099 WS AirIF-- |Machine| 1100 +-------+ 1102 Figure 9: Example illustration of M2M TV white space use-case 1104 A simplified operational scenario utilizing TV whitespace to provide 1105 machine to machine connectivity consists of the following steps: 1107 1. The master device powers up with its whitespace radio in idle or 1108 listen mode only (no active transmission on the whitespace 1109 frequency band). 1111 2. The master device has Internet connectivity, determines its 1112 location (either from location determination capability or from 1113 saved value that was set during installation), and establishes a 1114 connection to a trusted white space database (see Section 4.1.1). 1116 3. The master/AP registers with the trusted database according to 1117 regulatory domain requirements (see Section 4.1.2). 1119 4. Following successful registration (if registration is required), 1120 the master device sends its geolocation and location uncertainty 1121 information, and optionally additional information which may 1122 include (1) device ID and (2) antenna characteristics, to a 1123 trusted database, requesting a list of available whitespace 1124 channels based upon this information. 1126 5. If the master has met all regulatory domain requirements, the 1127 database responds with a list of available white space channels 1128 that the master device may use, and optional information which 1129 may include inter alia (1) a duration of time for the use of each 1130 channel (channel validity time) (2) a maximum radiated power for 1131 each channel or a notification of any additional requirements for 1132 sensing. 1134 6. Once the master device authenticates the whitespace channel list 1135 response message from the database, the master device selects one 1136 or more available whitespace channels from the list. 1138 7. The slave devices fitted to the machines scan the TV bands to 1139 locate the master transmissions, and associate with the master 1140 device. 1142 8. Further signaling can take place outside scope of PAWS to 1143 establish direct links among those slave devices that have 1144 associated with the same master device. At all times these 1145 direct links are under the control of the master device. For 1146 example, common to all use cases, there may be a regulatory 1147 requirement for transmissions from slave to master to cease 1148 immediately if so requested by the master, or if connection to 1149 the master is lost for more than a specified period of time. 1150 When one of these conditions occurs, transmissions from slave to 1151 slave would also cease. Various mechanisms could be used to 1152 detect loss of signal from the master, for example by requiring 1153 masters to transmit regular beacons if they allow slave to slave 1154 communications. Direct slave to slave transmissions could only 1155 restart if each slave subsequently restores its connection to the 1156 same master, or each slave joins the network of another master. 1158 5. Problem Statement 1160 The use of white space spectrum is enabled via the capability of a 1161 device to query a database and obtain information about the 1162 availability of spectrum for use at a given location. The databases 1163 are reachable via the Internet and the devices querying these 1164 databases are expected to have some form of Internet connectivity, 1165 directly or indirectly. The databases may be country specific since 1166 the available spectrum and regulations may vary, but the fundamental 1167 operation of the protocol should be country independent. 1169 An example high-level architecture of the devices and white space 1170 databases is shown in Figure 10: 1172 ----------- 1173 |WS Device| ------------ 1174 |Lat: X |\ .---. /--------|Database X| 1175 |Long: Y | \ ( ) / ------------ 1176 ----------- \-------/ \/ o 1177 ( Internet ) o 1178 ----------- /------( )\ o 1179 |WS Device| / (_____) \ ------------ 1180 |Lat: X |/ \--------|Database Y| 1181 |Long: Y | ------------ 1182 ----------- 1184 Figure 10: High level view of the White space database architecture 1186 In Figure 10, note that there could be multiple databases serving 1187 white space devices. The databases are country specific since the 1188 regulations and available spectrum may vary. In some countries, for 1189 example, the U.S., the regulator has determined that multiple, 1190 competing databases may provide service to White Space Devices. 1192 A messaging interface between the white space devices and the 1193 database is required for operating a network using the white space 1194 spectrum. The following sections discuss various aspects of such an 1195 interface and the need for a standard. Other aspects of a solution 1196 including provisioning the database, and calculating protected 1197 contours are considered out of scope of the initial effort, as there 1198 are significant differences between countries and spectrum bands. 1200 5.1. Global applicability 1202 The use of TV white space spectrum is currently approved by the FCC 1203 in the United States. However regulatory bodies in other countries 1204 are also considering similar use of available spectrum. The 1205 principles of cognitive radio usage for such spectrum is generally 1206 the same. Some of the regulatory details may vary on a country 1207 specific basis. However the need for devices that intend to use the 1208 spectrum to communicate with a database remains a common feature. 1209 The database provides a known, specifiable Protection Contour for the 1210 primary user, not dependent on the characteristics of the White Space 1211 Device or its ability to sense the primary use. It also provides a 1212 way to specify a schedule of use, because some primary users (for 1213 example, wireless microphones) only operate in limited time slots. 1215 Devices need to be able to query a database, directly or indirectly 1216 over the public Internet and/or private IP networks prior to 1217 operating in available spectrum. Information about available 1218 spectrum, schedule, power, etc. are provided by the database as a 1219 response to the query from a device. The messaging interface needs 1220 to be: 1222 1. Radio/air interface agnostic - The radio/air interface technology 1223 used by the white space device in available spectrum can be IEEE 1224 802.11af, IEEE 802.15.4m, IEEE 802.16, IEEE 802.22, LTE etc. 1225 However the messaging interface between the white space device 1226 and the database should be agnostic to the air interface while 1227 being cognizant of the characteristics of various air-interface 1228 technologies and the need to include relevant attributes in the 1229 query to the database. 1231 2. Spectrum agnostic - the spectrum used by primary and secondary 1232 users varies by country. Some spectrum has an explicit notion of 1233 a "channel" a defined swath of spectrum within a band that has 1234 some assigned identifier. Other spectrum bands may be subject to 1235 white space sharing, but only have actual frequency low/high 1236 parameters to define protected entity use. The protocol should 1237 be able to be used in any spectrum band where white space sharing 1238 is permitted. 1240 3. Globally applicable - A common messaging interface between white 1241 space devices and databases will enable the use of such spectrum 1242 for various purposes on a global basis. Devices can operate in 1243 any country where such spectrum is available and a common 1244 interface ensures uniformity in implementations and deployment. 1245 Since the White Space Device must know its geospatial location to 1246 do a query, it is possible to determine which database, and which 1247 rules, are applicable, even though they are country specific. 1249 4. Address regulatory requirements - Each country will likely have 1250 regulations that are unique to that country. The messaging 1251 interface needs to be flexible to accommodate the specific needs 1252 of a regulatory body in the country where the white space device 1253 is operating and connecting to the relevant database. 1255 5.2. Database discovery 1257 Another aspect of the problem space is the need to discover the 1258 database. A white space device needs to find the relevant database 1259 to query, based on its current location or for another location. 1260 Since the spectrum and databases are country specific, the device 1261 will need to discover the relevant database. The device needs to 1262 obtain the IP address of the specific database to which it can send 1263 queries in addition to registering itself for operation and using the 1264 available spectrum. 1266 5.3. Protocol 1268 A protocol that enables a white space device to query a database to 1269 obtain information about available channels is needed. A device may 1270 be required to register with the database with some credentials prior 1271 to being allowed to query. The requirements for such a protocol are 1272 specified in this document. 1274 5.4. Data model definition 1276 The contents of the queries and response need to be specified. A 1277 data model is required which enables the white space device to query 1278 the database while including all the relevant information such as 1279 geolocation, radio technology, power characteristics, etc. which may 1280 be country and spectrum and regulatory dependent. All databases are 1281 able to interpret the data model and respond to the queries using the 1282 same data model that is understood by all devices. 1284 Use of XML for specifying a data model is an attractive option. The 1285 intent is to evaluate the best option that meets the need for use 1286 between white space devices and databases. 1288 6. Requirements 1290 6.1. Normative Requirements 1292 D. Data Model Requirements: 1294 D.1: The Data Model MUST support specifying the location of the 1295 WSD, the uncertainty in meters, the height & its 1296 uncertainty, and confidence in percentage for the location 1297 determination. The Data Model MUST support both North 1298 American Datum of 1983 and WGS84. 1300 D.2: The Data Model MUST support specifying the URI address of a 1301 white space database. 1303 D.3: The Data Model MUST support specifying the URI address of a 1304 national listing service. 1306 D.4: The Data Model MUST support specifying the regulatory 1307 domain and its corresponding data requirements. 1309 D.5: The Data Model MUST support specifying an ID of the 1310 transmitter device. This ID would contain the ID of the 1311 transmitter device that has been certified by a regulatory 1312 body for its regulatory domain. The Data Model MUST 1313 support a device class. 1315 D.6: The Data Model MUST support specifying a manufacturer's 1316 serial number for a master device. 1318 D.7: The Data Model MUST support specifying the antenna and 1319 radiation related parameters of the subject, such as: 1321 antenna height 1323 antenna gain 1325 maximum output power, EIRP (dBm) 1327 antenna radiation pattern (directional dependence of the 1328 strength of the radio signal from the antenna) 1330 spectrum mask with lowest and highest possible frequency 1332 spectrum mask in dBr from peak transmit power in EIRP, 1333 with specific power limit at any frequency linearly 1334 interpolated between adjacent points of the spectrum 1335 mask 1337 measurement resolution bandwidth for EIRP measurements 1339 D.8: The Data Model MUST support specifying owner and operator 1340 contact information for a transmitter. This includes the 1341 name of the transmitter owner, name of transmitter 1342 operator, postal address, email address and phone number of 1343 the transmitter operator. 1345 D.9: The Data Model MUST support specifying a list of available 1346 channels. The Data Model MUST support specification of 1347 this information by channel numbers and by start and stop 1348 frequencies. The Data Model MUST support a channel 1349 availability schedule and maximum power level for each 1350 channel in the list. 1352 D.10: The Data Model MUST support specifying channel availability 1353 information for a single location and an area (e.g. a 1354 polygon defined by multiple location points or a geometric 1355 shape such as a circle). 1357 P. Protocol Requirements: 1359 P.1: The protocol MUST provide a message sequence for the master 1360 device to discover a white space database that provides 1361 service at its current location. 1363 P.2: The protocol MUST support access of a database directly. 1364 The protocol MUST support access of a database using a 1365 listing approved by a national regulator. 1367 P.3: The protocol MUST support determination of regulatory 1368 domain governing its current location. 1370 P.4: The protocol MUST provide the ability for the database to 1371 authenticate the master device. 1373 P.5: The protocol MUST provide the ability for the master device 1374 to verify the authenticity of the database with which it is 1375 interacting. 1377 P.6: The messages sent by the master device to the database MUST 1378 be integrity protected. 1380 P.7: The messages sent by the database to the master device MUST 1381 be integrity protected. 1383 P.8: The protocol MUST provide the capability for messages sent 1384 by the master device and database to be encrypted. 1386 P.9: The protocol MUST support the master device registering 1387 with the database. 1389 P.10: The protocol MUST support a registration acknowledgement 1390 including appropriate result codes. 1392 P.11: The protocol MUST support a channel query request from the 1393 master device to the database. The channel query request 1394 message MUST include parameters as required by local 1395 regulatory requirement. These parameters MAY include 1396 device location, device ID, manufacturer's serial number, 1397 and antenna characteristic information. 1399 P.12: The protocol MUST support a channel query response from the 1400 database to the master device. The channel query response 1401 message MUST include parameters as required by local 1402 regulatory requirement. These parameters MAY include 1403 available channels, duration of time for their use, 1404 associated maximum power levels, any additional sensing 1405 requirements. 1407 P.13: The protocol MUST support a channel query request from the 1408 slave device to the master device. The channel query 1409 request message MUST include parameters as required by 1410 local regulatory requirement. These parameters MAY include 1411 device ID and slave device location. 1413 P.14: The protocol MUST support a validation request from the 1414 master to the database to validate a slave device. The 1415 validation request MUST include the slave device ID. 1417 P.15: The protocol MUST support a validation response from the 1418 database to the master. The validation response MUST 1419 include a response code. 1421 P.16: The protocol MUST support a channel query response from the 1422 master device to the slave device. The channel query 1423 response message MUST include parameters as required by 1424 local regulatory requirement, including a response code and 1425 sufficient information to decode an enabling signal. 1427 P.17: The protocol MUST support an enabling signal sent from the 1428 master to the slave. This signal MUST allow the slave 1429 device to validate that a previously received available 1430 channel list is still valid or not. This signal MUST be 1431 encoded to allow the slave device to determine the identity 1432 if the sending master device. 1434 P.18: The protocol between the master device and the database 1435 MUST support the capability to change channel availability 1436 lists on short notice. 1438 P.19: The protocol between the master device and the database 1439 MUST support a channel availability request which specifies 1440 a geographic location as an area as well as a point. 1442 O. Operational Requirements: 1444 O.1: The database and the master device MUST be connected to the 1445 Internet. 1447 O.2: A master device MUST be able to determine its location 1448 including uncertainty and confidence level. A fixed master 1449 device MAY use a location programmed at installation or 1450 have the capability determine its location to the required 1451 accuracy. A mobile master device MUST have the capability 1452 to determine its location to the required accuracy. 1454 O.3: The master device MUST identify a database for use. The 1455 master device MAY select a database for service by 1456 discovery at runtime or the master device MAY select a 1457 database for service by means of a pre-programmed URI 1458 address. 1460 O.4: The master device MUST implement at least one connection 1461 method to access the database. The master device MAY 1462 contact a database directly for service (e.g. as defined by 1463 FCC) or the master device MAY contact a listing server 1464 first followed by contact to a database (e.g. as defined by 1465 Ofcom). 1467 O.5: The master device MUST obtain an indication the regulatory 1468 domain governing operation at its current location, i.e. 1469 the master device MUST know if it operates under 1470 regulations from FCC, Ofcom, etc... 1472 O.6: The master device MAY register with the database according 1473 to local regulatory policy. Not all master devices will be 1474 required to register. Specific events will initiate 1475 registration, these events are determined by regulator 1476 policy (e.g. at power up, after movement, etc...). 1478 O.7: The master device MUST register with its most current and 1479 up-to-date information, and MUST include all variables 1480 mandated by local regulator policy. 1482 O.8: A master device MUST query the database for the available 1483 channels based on its current location before starting 1484 radio transmission in white space. Parameters provided to 1485 the database MAY include device location, accuracy of the 1486 location, antenna characteristic information, device 1487 identifier of any slave device requesting channel 1488 information. 1490 O.9: The database MUST respond to an available channel list 1491 request from an authenticated and authorized device and MAY 1492 also provide time constraints, maximum output power, start 1493 and stop frequencies for each channel in the list and any 1494 additional requirements for sensing. 1496 O.10: After connecting to a master device's radio network a slave 1497 device MUST query the master device for a list of available 1498 channels. The slave MUST include parameters required by 1499 local regulatory policy, e.g. device ID, device location. 1501 O.11: According to local regulatory policy, the master device MAY 1502 query the database with parameters received from the slave 1503 device. 1505 O.12: The database MUST respond to a query from the master device 1506 containing parameters from a slave device. 1508 O.13: After the master device has received a response from the 1509 database, the master device MUST respond to the slave 1510 device. If all regulatory requirements are met the 1511 response will contain an available channel list. If 1512 regulatory requirements are not met, the response MUST 1513 contain at least a response code. 1515 O.14: If a master device has provided an available channel list 1516 to a slave device the master device MAY send a periodic 1517 enabling signal to allow the slave device to confirm it is 1518 still within reception range of the master device. 1520 O.15: The enabling signal MUST be encoded so that the receiving 1521 slave can determine the identity of the sending master. 1523 O.16: Periodically, at an interval according to local 1524 regulations, the slave device MUST either receive and 1525 enabling signal or MUST successfully repeat the channel 1526 request process or MUST cease transmission on the channel. 1528 O.17: A master device MUST repeat the query to the database for 1529 the available channels as often as required by the 1530 regulation (e.g., FCC requires once per day) to verify that 1531 the operating channels continue to remain available. 1533 O.18: A master device which changes its location more than a 1534 threshold distance (specified by local regulatory policy) 1535 during its operation, MUST query the database for available 1536 operating channels each time it moves more than the 1537 threshold distance (e.g., FCC specifies 100m) from the 1538 location it previously made the query. 1540 O.19: If slave devices change their location during operation by 1541 more than a limit specified by the local regulator, the 1542 slave device MUST query the master device for available 1543 operating channels. 1545 O.20: According to local regulator policy, a master device may 1546 contact a database via proxy service of another master 1547 device. 1549 O.21: A master device MUST be able to query the whitespace 1550 database for channel availability information for a 1551 specific expected coverage area around its current 1552 location. 1554 O.22: A Master device MUST include its identity in messages sent 1555 to the database. 1557 6.2. Guidelines 1559 The current scope of the working group is limited and is reflected in 1560 the requirements captured in Section 6.1. However white space 1561 technology itself is expected to evolve and address other aspects 1562 such as co-existence and interference avoidance, spectrum brokering, 1563 alternative spectrum bands, etc. The design of the data model and 1564 protocol should be cognizant of the evolving nature of white space 1565 technology and consider the following set of guidelines in the 1566 development of the data model and protocol: 1568 1. The data model SHOULD provide a modular design separating out 1569 messaging specific, administrative specific, and spectrum 1570 specific parts into separate modules. 1572 2. The protocol SHOULD support determination of which administrative 1573 specific and spectrum specific modules are used. 1575 7. IANA Considerations 1577 This document has no requests to IANA. 1579 8. Security Considerations 1581 Threat model for the PAWS protocol 1583 Assumptions: 1585 It is assumed that an attacker has full access to the network medium 1586 between the master device and the white space database. The attacker 1587 may be able to eavesdrop on any communications between these 1588 entities. The link between the master device and the white space 1589 database can be wired or wireless and provides IP connectivity. 1591 It is assumed that both the master device and the white space 1592 database have NOT been compromised from a security standpoint. 1594 Threat 1: User modifies a device to masquerade as another valid 1595 certified device 1597 Regulatory environments require that devices be certified and 1598 register in ways that accurately reflect their certification. 1599 Without suitable protection mechanisms, devices could simply 1600 listen to registration exchanges, and later registering claiming 1601 to be those other devices. Such replays would allow false 1602 registration, violating regulatory regimes. A white space 1603 database may be operated by a commercial entity which restricts 1604 access to authorized users. A master device MAY need to identify 1605 itself to the database and be authorized to obtain information 1606 about available channels. 1608 Threat 2: Spoofed white space database 1610 A master device discovers a white space database(s) thru which it 1611 can query for channel information. The master device needs to 1612 ensure that the white space database with which it communicates 1613 with is an authentic entity. The white space database needs to 1614 provide its identity to the master device which can confirm the 1615 validity/authenticity of the database. An attacker may attempt to 1616 spoof a white space database and provide responses to a master 1617 device which are malicious and result in the master device causing 1618 interference to the primary user of the spectrum. 1620 Threat 3: Modifying a query request 1622 An attacker may modify the query request sent by a master device 1623 to a white space database. The attacker may change the location 1624 of the device or the capabilities in terms of its transmit power 1625 or antenna height etc. which could result in the database 1626 responding with incorrect information about available channels or 1627 max transmit power allowed. The result of such an attack is that 1628 the master device would cause interference to the primary user of 1629 the spectrum. It could also result in a denial of service to the 1630 master device by indicating that no channels are available. 1632 Threat 4: Modifying a query response 1634 An attacker could modify the query response sent by the white 1635 space database to a master device. The channel information or 1636 transmit power allowed type of parameters carried in the response 1637 could be modified by the attacker resulting in the master device 1638 using channels that are not available at a location or 1639 transmitting at a greater power level than allowed resulting in 1640 interference to the primary user of that spectrum. Alternatively 1641 the attacker may indicate no channel availability at a location 1642 resulting in a denial of service to the master device. 1644 Threat 5: Unauthorized use of channels by an uncertified device 1646 An attacker may be a master device which is not certified for use 1647 by the relevant regulatory body. The attacker may listen to the 1648 communication between a valid master device and white space 1649 database and utilize the information about available channels in 1650 the response message by utilizing those channels. The result of 1651 such an attack is unauthorized use of channels by a master device 1652 which is not certified to operate. The master device querying the 1653 white space database may be operated by a law-enforcement agency 1654 and the communications between the device and the database are 1655 intended to be kept private. A malicious device should not be 1656 able to eavesdrop on such communications. 1658 Threat 6: Third party tracking of white space device location and 1659 identity 1661 A white space database in a regulatory domain may require a master 1662 device to provide its identity in addition to its location in the 1663 query request. Such location/identity information can be gleaned 1664 by an eavesdropper and used for tracking purposes. A master 1665 device may prefer to keep the location/identity information hidden 1666 from eavesdroppers, hence the protocol should provide a means to 1667 protect the location and identity information of the master device 1668 and prevent tracking of locations associated with a white space 1669 database query. When the master device sends both its identity 1670 and location to the DB, the DB is able to track it. If a 1671 regulatory domain does not require the master device to provide 1672 its identity to the white space database, the master device may 1673 decide not to send its identity, to prevent being tracked by the 1674 DB. 1676 Threat 7: Malicious individual acts as a PAWS entity (spoofing DB or 1677 as MiM) to terminate or unfairly limit spectrum access of devices for 1678 reasons other than incumbent protection 1680 A white space database MAY include a mechanism by which service 1681 and channels allocated to a master device can be revoked by 1682 sending an unsolicited message. A malicious node can pretend to 1683 be the white space database with which a master device has 1684 registered or obtained channel information from and send a revoke 1685 message to that device. This results in denial of service to the 1686 master device. 1688 Threat 8: Natural disaster resulting in inability to obtain 1689 authorization for white space spectrum use by emergency responders 1691 In the case of a sizable natural disaster a lot of Internet 1692 infrastructure ceases to function. Emergency services users need 1693 to reconstitute quickly and will rely on establishing radio WANs. 1694 The potential for lot of radio WAN gear that has been unused 1695 suddenly needs to be pressed into action. And the radio WANs need 1696 frequency authorizations to function. Regulatory entities may 1697 also authorize usage of additional spectrum in the affected areas. 1698 The white space radio entities may need to establish communication 1699 with a database and obtain authorizations. In cases where 1700 communication with the white space database fails, the white space 1701 devices cannot utilize white space spectrum. Emergency services, 1702 which require more spectrum precisely at locations where network 1703 infrastructure is malfunctioning or overloaded, backup 1704 communication channels and distributed white space databases are 1705 needed to overcome such circumstances. Alternatively there may be 1706 other mechanisms which allow the use of spectrum by emergency 1707 service equipment without strict authorization or with liberal 1708 interpretation of the regulatory policy for white space usage. 1710 The security requirements arising from the above threats are captured 1711 in the requirements of section 6.1. 1713 9. Summary and Conclusion 1715 Wireless spectrum is a scarce resource. As the demand for spectrum 1716 grows, there is a need to more efficiently utilize the available and 1717 allocated spectrum. Cognitive radio technologies enable the 1718 efficient usage of spectrum via means such as sensing or by querying 1719 a database to determine available spectrum at a given location for 1720 opportunistic use. White space is the general term used to refer to 1721 the bands within the spectrum which is available for secondary use at 1722 a given location. In order to use this spectrum a device needs to 1723 query a database which maintains information about the available 1724 channels within a band. A protocol is necessary for communication 1725 between the devices and databases which would be globally applicable. 1727 The document describes some examples of the role of the white space 1728 database in the operation of a radio network and also shows examples 1729 of services provided to the user of a TVWS device. From these use 1730 cases, requirements are determined. These requirements are to be 1731 used as input to the definition of a Protocol to Access White Space 1732 database (PAWS). 1734 10. Acknowledgements 1736 The authors acknowledge Gabor Bajko, Teco Boot, Nancy Bravin, Rex 1737 Buddenberg, Gerald Chouinard, Stephen Farrell, Michael Fitch, Joel M. 1738 Halpern, Jussi Kahtava, Paul Lambert, Brian Rosen, Andy Sago, Peter 1739 Stanforth, John Stine and, Juan Carlos Zuniga for their contributions 1740 to this document. 1742 11. References 1744 11.1. Normative References 1746 [802.11p] IEEE, "IEEE Standard for Information technology - 1747 Telecommunications and information exchange between 1748 systems - Local and metropolitan area networks - Specific 1749 requirements; Part 11: Wireless LAN Medium Access Control 1750 (MAC) and Physical Layer (PHY) Specifications; Amendment 1751 6: Wireless Access in Vehicular Environments; http:// 1752 standards.ieee.org/getieee802/download/802.11p-2010.pdf", 1753 July 2010. 1755 [802.22] IEEE, "IEEE Standard for Information technology - 1756 Telecommunications and information exchange between 1757 systems - Wireless Regional Area Networks (WRAN) - 1758 Specific requirements; Part 22: Cognitive Wireless RAN 1759 Medium Access Control (MAC) and Physical Layer (PHY) 1760 Specifications: Policies and Procedures for Operation in 1761 the TV bands", July 2011. 1763 [FCC47CFR90.210] 1764 FCC, "Title 47 Telecommunication CFR Chapter I - Federal 1765 Communication Commission Part 90 - Private Land Mobile 1766 Radio Services - Section 210 Emission masks; http:// 1767 edocket.access.gpo.gov/cfr_2010/octqtr/pdf/ 1768 47cfr90.210.pdf", October 2010. 1770 [PAWS-PS] IETF, "Protocol to Access White Space database: Problem 1771 statement; https://datatracker.ietf.org/doc/ 1772 draft-patil-paws-problem-stmt/", July 2011. 1774 [RFC2119] IETF, "Key words for use in RFCs to Indicate Requirement 1775 Levels; 1776 http://www.rfc-editor.org/rfc/pdfrfc/rfc2119.txt.pdf", 1777 March 1997. 1779 11.2. Informative References 1781 [DDR] Ofcom - Independent regulator and competition authority 1782 for the UK communications industries, "Digital Dividend 1783 Review; http://stakeholders.ofcom.org.uk/spectrum/ 1784 project-pages/ddr/". 1786 [DTV] "Digital TV Transition; http://www.dtv.gov". 1788 [ECC Report 159] 1789 Electronic Communications Committee (ECC) within the 1790 European Conference of Postal and Telecommunications 1791 Administrations (CEPT), "TECHNICAL AND OPERATIONAL 1792 REQUIREMENTS FOR THE POSSIBLE OPERATION OF COGNITIVE RADIO 1793 SYSTEMS IN THE 'WHITE SPACES' OF THE FREQUENCY BAND 470- 1794 590 MHZ; http://www.erodocdb.dk/Docs/doc98/official/pdf/ 1795 ECCREP159.PDF", January 2011. 1797 [FCC Ruling] 1798 FCC, "Federal Communications Commission, "Unlicensed 1799 Operation in the TV Broadcast Bands; 1800 http://edocket.access.gpo.gov/2010/pdf/2010-30184.pdf"", 1801 December 2010. 1803 [Ofcom Implementing] 1804 Ofcom, "Ofcom, "Implementing Geolocation; http:// 1805 stakeholders.ofcom.org.uk/consultations/geolocation/ 1806 statement/"", September 2011. 1808 [RFC5222] IETF, Hardie, T., Netwon, A., Schulzrinne, H., and H. 1809 Tschofenig, "LoST: A Location-to-Service Translation Proto 1810 col;http://www.rfc-editor.org/rfc/pdfrfc/rfc5222.txt.pdf", 1811 August 2008. 1813 [Spectrum Framework Review] 1814 Ofcom - Independent regulator and competition authority 1815 for the UK communications industries, "Spectrum Framework 1816 Review; 1817 http://stakeholders.ofcom.org.uk/consultations/sfr/", 1818 February 2005. 1820 [TV Whitespace Tutorial Intro] 1821 IEEE 802 Executive Committee Study Group on TV White 1822 Spaces, "TV Whitespace Tutorial Intro; http:// 1823 grouper.ieee.org/groups/802/802_tutorials/2009-03/ 1824 2009-03-10%20TV%20Whitespace%20Tutorial%20r0.pdf", 1825 March 2009. 1827 Authors' Addresses 1829 Scott Probasco (editor) 1830 Nokia 1831 6021 Connection drive 1832 Irving, TX 75039 1833 USA 1835 Email: scott.probasco@nokia.com 1837 Basavaraj Patil 1838 Nokia 1839 6021 Connection drive 1840 Irving, TX 75039 1841 USA 1843 Email: basavaraj.patil@nokia.com