idnits 2.17.1 draft-ietf-paws-problem-stmt-usecases-rqmts-11.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 25, 2013) is 4109 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PAWS Mancuso, Ed. 3 Internet-Draft Probasco 4 Intended status: Informational Patil 5 Expires: July 29, 2013 January 25, 2013 7 Protocol to Access White Space (PAWS) Database: Use Cases and 8 Requirements 9 draft-ietf-paws-problem-stmt-usecases-rqmts-11 11 Abstract 13 Portions of the radio spectrum that are assigned to a particular use 14 but are unused or unoccupied at specific locations and times are 15 defined as "white space." The concept of allowing additional 16 transmissions (which may or may not be licensed) in white space is a 17 technique to "unlock" existing spectrum for new use. An obvious 18 requirement is that these additional transmissions do not interfere 19 with the assigned use of the spectrum. One approach to using white 20 space spectrum at a given time and location is to verify spectrum 21 availability with a database that manages spectrum sharing and 22 provides spectrum-availability information. The IETF has undertaken 23 to develop a Protocol to Access Spectrum Database [1] for such a 24 management database. 26 This document describes a number of possible use cases of white space 27 spectrum and technology as well as a set of requirements for the 28 database query protocol. The concept of white spaces is described 29 along with the problems that need to be addressed to enable white 30 space spectrum for additional uses without causing interference to 31 currently assigned use. Use of white space is enabled by querying a 32 database that stores information about spectrum availability at any 33 given location and time. 35 Requirements Language 37 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 38 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 39 document are to be interpreted as described in RFC 2119 [RFC2119]. 41 Status of this Memo 43 This Internet-Draft is submitted in full conformance with the 44 provisions of BCP 78 and BCP 79. 46 Internet-Drafts are working documents of the Internet Engineering 47 Task Force (IETF). Note that other groups may also distribute 48 working documents as Internet-Drafts. The list of current Internet- 49 Drafts is at http://datatracker.ietf.org/drafts/current/. 51 Internet-Drafts are draft documents valid for a maximum of six months 52 and may be updated, replaced, or obsoleted by other documents at any 53 time. It is inappropriate to use Internet-Drafts as reference 54 material or to cite them other than as "work in progress." 56 This Internet-Draft will expire on July 29, 2013. 58 Copyright Notice 60 Copyright (c) 2013 IETF Trust and the persons identified as the 61 document authors. All rights reserved. 63 This document is subject to BCP 78 and the IETF Trust's Legal 64 Provisions Relating to IETF Documents 65 (http://trustee.ietf.org/license-info) in effect on the date of 66 publication of this document. Please review these documents 67 carefully, as they describe your rights and restrictions with respect 68 to this document. Code Components extracted from this document must 69 include Simplified BSD License text as described in Section 4.e of 70 the Trust Legal Provisions and are provided without warranty as 71 described in the Simplified BSD License. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 1.1. Introduction to white space . . . . . . . . . . . . . . . 4 77 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 78 1.2.1. In Scope . . . . . . . . . . . . . . . . . . . . . . . 4 79 1.2.2. Out of Scope . . . . . . . . . . . . . . . . . . . . . 5 80 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 5 81 2.1. Conventions Used in This Document . . . . . . . . . . . . 5 82 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 83 3. Protocol Services . . . . . . . . . . . . . . . . . . . . . . 6 84 3.1. Protocol services . . . . . . . . . . . . . . . . . . . . 6 85 3.1.1. White space database discovery . . . . . . . . . . . . 6 86 3.1.2. Device registration with trusted database . . . . . . 7 87 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 8 88 4.1. Use cases . . . . . . . . . . . . . . . . . . . . . . . . 8 89 4.1.1. Master-slave white space networks . . . . . . . . . . 8 90 4.1.2. Offloading: moving traffic to a white space network . 10 91 4.1.3. White space serving as backhaul . . . . . . . . . . . 11 92 4.1.4. Rapid network deployment during emergency scenario . . 12 93 4.1.5. White space used for local TV broadcaster . . . . . . 13 94 5. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 14 95 5.1. Global applicability . . . . . . . . . . . . . . . . . . . 15 96 5.2. Database discovery . . . . . . . . . . . . . . . . . . . . 17 97 5.3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 17 98 5.4. Data model definition . . . . . . . . . . . . . . . . . . 17 99 6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 17 100 6.1. Data Model Requirements . . . . . . . . . . . . . . . . . 17 101 6.2. Protocol Requirements . . . . . . . . . . . . . . . . . . 19 102 6.3. Operational Requirements . . . . . . . . . . . . . . . . . 20 103 6.4. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . 22 104 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 105 8. Security Considerations . . . . . . . . . . . . . . . . . . . 23 106 9. Summary and Conclusion . . . . . . . . . . . . . . . . . . . . 25 107 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26 108 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 109 11.1. Normative References . . . . . . . . . . . . . . . . . . . 26 110 11.2. Informational References . . . . . . . . . . . . . . . . . 26 111 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 113 1. Introduction 115 1.1. Introduction to white space 117 Wireless spectrum is a commodity that is regulated by governments. 118 The spectrum is used for various purposes, which include, but are not 119 limited to, entertainment (e.g., radio and television), communication 120 (e.g., telephony and Internet access), military (e.g., radars etc.), 121 and navigation (e.g., satellite communication, GPS). Portions of the 122 radio spectrum that are assigned to a licensed (primary) user but are 123 unused or unoccupied at specific locations and times are defined as 124 "white space." The concept of allowing additional (secondary) 125 transmissions (which may or may not be licensed) in white space is a 126 technique to "unlock" existing spectrum for new use. An obvious 127 requirement is that these secondary transmissions do not interfere 128 with the assigned use of the spectrum. One interesting observation 129 is that often, in a given physical location, the primary user(s) may 130 not be using the entire band assigned to them. The available 131 spectrum for secondary transmissions would then depend on the 132 location of the secondary user. The fundamental issue is how to 133 determine, for a specific location and specific time, if any of the 134 assigned spectrum is available for secondary use. Academia and 135 Industry have studied multiple cognitive radio [2] mechanisms for use 136 in such a scenario. One simple mechanism is to use a geospatial 137 database that contains the spatial and temporal profile of all 138 primary licensees' spectrum usage, and require secondary users to 139 query the database for available spectrum that they can use at their 140 location. Such databases can be accessible and queryable by 141 secondary users on the Internet . 143 Any entity that is assigned spectrum that is not densely used may be 144 asked by a governmental regulatory agency to share it to allow for 145 more intensive use of the spectrum. Providing a mechanism by which 146 secondary users share the spectrum with the primary user is 147 attractive in many bands in many countries. 149 This document includes the problem statement followed by use cases 150 and requirements associated with the use of white space spectrum by 151 secondary users via a database query protocol. 153 1.2. Scope 155 1.2.1. In Scope 157 This document covers the requirements for a protocol to allow a 158 device to access a database to obtain spectrum availability 159 information. Such a protocol should allow a device to perform the 160 following actions: 162 1. Determine the relevant white space database to query. 164 2. Connect to and optionally register with the database using a 165 well-defined protocol. 167 3. Provide its geolocation and perhaps other data to the database 168 using a well-defined format for querying the database. 170 4. Receive in response to the query a list of available white space 171 frequencies using a well-defined format for the information. 173 5. Send an acknowledgment to the database with information 174 containing channels selected for use by the device. 176 1.2.2. Out of Scope 178 The following topics are out of scope for this specification: 180 1. Co-existence and interference avoidance of white space devices 181 within the same spectrum. 183 2. Provisioning (releasing new spectrum for white space use). 185 2. Conventions and Terminology 187 2.1. Conventions Used in This Document 189 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 190 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 191 document are to be interpreted as described in RFC 2119 [RFC2119]. 193 2.2. Terminology 195 Database A database is an entity that contains current information 196 about available spectrum at a given location and time as well as 197 other types of information related to spectrum availability and 198 usage. 200 Device Class Identifies classes of devices including fixed, mobile, 201 portable, etc... May also indicate if the device is indoor or 202 outdoor. 204 Device ID A unique number for each master device. 206 Master Device A device that queries the database, on its own behalf 207 and/or on behalf of a slave device, to obtain available spectrum 208 information. 210 Slave Device A device that queries the database through a Master 211 Device. 213 White Space (WS) Radio spectrum that is available for secondary use 214 at a specific location and time. 216 White Space Device (WSD) A device that uses white space spectrum as 217 a secondary user. A white space device can be a fixed or portable 218 device such as an access point, base station, or cell phone. 220 3. Protocol Services 222 3.1. Protocol services 224 A complete protocol solution must enable many different potential 225 white space services. This section describes the features required 226 of the protocol. 228 3.1.1. White space database discovery 230 White space database discovery is preliminary to creating a radio 231 network using white space; it is a prerequisite to the use cases 232 below. The radio network is created by a master device. Before the 233 master device can transmit in white space spectrum, it must contact a 234 trusted database where the device can learn if any spectrum is 235 available for its use. The master device will need to discover a 236 trusted database, using the following steps: 238 1. The master device is connected to the Internet. 240 2. The master device constructs and sends a service request over the 241 Internet. 243 3. If no acceptable response is received within a pre-configured 244 time limit, the master device concludes that no trusted database 245 is available. If at least one response is received, the master 246 device evaluates the response(s) to determine if a trusted 247 database can be identified where the master device is able to 248 receive service from the database. 250 Optionally the radio device is pre-programmed with the Internet 251 address of at least one trusted database. The device can establish 252 contact with a trusted database using one of the pre-programmed 253 Internet addresses and establish a white space network (as described 254 in one of the following use cases). 256 3.1.2. Device registration with trusted database 258 In some regulatory domains, the master device must register with the 259 trusted database before it queries the database for available 260 spectrum. Different regulatory domains may have different device 261 registration requirements. 263 Figure 1 (Figure 1) shows an example deployment of this scenario. 265 ---------- 266 \|/ |Database| 267 | .---. / --------- 268 |--|--------| ( ) / 269 | Master | / \ 270 | |========( Internet) 271 |-----------| \ / 272 ( ) 273 (---) 275 Figure 1: Example illustration of registration requirement in white 276 space use-case 278 A simplified operational scenario showing registration consists of 279 the following steps: 281 1. If required by the regulatory domain, the master device registers 282 with its most current and up-to-date information. If subject to 283 registration, typically the master device will register after 284 power up, after changing location by a predetermined distance, 285 and after prescribed time intervals. 287 2. To register with the database, the master device sends 288 registration information to the database. This information may 289 include the Device ID, serial number assigned by the 290 manufacturer, device location, device antenna height above 291 ground, name of the individual or business that owns the device, 292 and the name, street and email address, and telephone number of a 293 contact person responsible for the device's operation. 295 3. The database responds to the registration request with an 296 acknowledgement to indicate the success of the registration 297 request or with an error if the registration was unsuccessful. 298 Additional information may be provided by the database in its 299 response according to regulatory requirements. 301 4. Use Cases 303 There are many potential use cases for white space spectrum - for 304 example, providing broadband Internet access in urban and densely- 305 populated hotspots as well as rural and remote, underserved areas. 306 Available white space spectrum may also be used to provide Internet 307 'backhaul' for traditional Wi-Fi hotspots or for use by towns and 308 cities to monitor/control traffic lights, read utility meters, and 309 the like. Still other use cases include the ability to offload data 310 traffic from another Internet access network (e.g., 3G cellular 311 network) or to deliver data, information, or a service to a user 312 based on the user's location. Some of these use cases are described 313 in the following sections. 315 4.1. Use cases 317 4.1.1. Master-slave white space networks 319 There are a number of common scenarios in which a master white space 320 device will act as proxy or mediator for one or more slave devices 321 using its connection to the Internet to query the database for 322 available spectrum for itself and for one or more slave devices. 323 These slave devices may be fixed or mobile, in close proximity with 324 each other (indoor network or urban hotspot), or at a distance (rural 325 or remote WAN). Once slave devices switch to white space spectrum 326 for their communications, they may connect through the master to the 327 Internet or use white space spectrum for intra-network communications 328 only. The master device can continue to arbitrate and control white 329 space communications by slave devices, and may notify them when they 330 are required to change white space frequencies or cease white space 331 communications. 333 Figure 2 (Figure 2) depicts the general architecture such a simple 334 master-slave network, in which the master device communicates on its 335 own behalf and on behalf of slave devices with a white space 336 database. 338 -------- 339 |Slave | 340 |Device| \ \|/ ---------- 341 | 1 | (Air) | |Database| 342 -------- \ | (----) /|--------| 343 | \ ------|------ ( ) / 344 | \| Master | / \ 345 -------- /| |======= ( Internet ) 346 |Slave | / | Device | \ / 347 |Device| (Air) | | ( ) 348 | 2 | / |-----------| (----) 349 |------- / 350 o | / 351 o | (Air) 352 o | / 353 -------- / 354 |Slave | / 355 |Device| / 356 | n | 357 -------- 359 Figure 2: Master-Slave White Space Network 361 The protocol requirements for these master-slave device and other 362 similar scenarios is essentially the same: the protocol must support 363 the ability of a master device to make available-spectrum query 364 requests on behalf of slave devices, passing device identification, 365 geolocation, and other slave device parameters to the database as 366 required to obtain a list of white space spectrum available for use 367 by one or more slave devices. Of course, different use cases will 368 use this spectrum information in different ways, and the details of 369 master/slave communications may be different for different use cases. 371 Common steps may occur in master-slave networks include the 372 following: 374 1. The master device powers up. 376 2. Slave devices power up and associate with the master device via 377 Wi-Fi or some other over-the-air non-white space spectrum. Until 378 the slave device is allocated white space spectrum, any master- 379 slave or slave-slave communications occurs over such non-white 380 space spectrum. 382 3. The master has Internet connectivity, determines (or knows) its 383 location, and establishes a connection to a trusted white space 384 database (see Section 4.1.1). 386 4. The master optionally registers with the trusted database (see 387 Section 4.1.2). 389 5. The master sends a query to the trusted database requesting a 390 list of available WS channels based upon its geolocation. Query 391 parameters may include the master's location, device identifier, 392 and antenna height. 394 6. The database responds to the master's query with a list of 395 available white space spectrum, associated maximum power levels, 396 and a duration of time for its use. 398 7. The slave devices may query the master for a channel list. The 399 master may relay available-spectrum requests to the database on 400 behalf of slave devices, then transmit the obtained available- 401 spectrum lists to the slaves (or the master may allocate spectrum 402 to slaves from the obtained spectrum lists). 404 8. Once a slave device has been allocated available white space 405 spectrum frequencies for communication over the network, it may 406 inform the master of the frequencies and power level it has 407 chosen, and the master may, in turn, relay such usage to the 408 database. 410 9. Further communication among masters and slaves over the network 411 occurs via the selected/allocated white space spectrum 412 frequencies. 414 4.1.2. Offloading: moving traffic to a white space network 416 This scenario is a variant of the master-slave network described in 417 the previous use case. In this scenario, an Internet connectivity 418 service is provided over white space as a supplemental or alternative 419 datapath to a more costly Internet connection (metered wire service, 420 metered wireless service, metered satellite service). In a typical 421 deployment scenario, an end user has a primary Internet connection, 422 but may prefer to use a connection to the Internet provided by a 423 local white space master device that is connected to the Internet. 425 Figure 3 (Figure 3) shows an example deployment of this scenario. 427 \|/ 428 | 429 | 430 |------------| 431 /| Master | \ 432 (Air)-/ |------------| \ 433 --------- / \ ----------- 434 |Slave |/ \ (----) | Database| 435 |Device | \ ( ) /---------- 436 |-------|\ \ / \ 437 \ X( Internet ) 438 \ / \ / 439 (Air) / ( ) 440 \ / (----) 441 \ / 442 \|---------------|/ 443 | Metered | 444 | Service | 445 |---------------| 447 Figure 3: Offloading Traffic to a White Space Network 449 A simplified operation scenario of offloading content, such as video 450 stream, from the a metered Internet connection to the a WS connection 451 consists of the following steps: 453 1. The slave device connects to a metered Internet service, and 454 selects a video for streaming. 456 2. The slave device switches mode and associates with a master white 457 space device.* 459 3. The master queries the database for available white space 460 spectrum and relays it to the slave device as described in 461 Section 4.1.1.* 463 4. The slave uses available white space spectrum to communicate with 464 the master and connect to the Internet to stream the selected 465 video. 467 * Note that the slave device may query the database directly for 468 available white space spectrum through its metered connection to the 469 Internet, thus eliminating steps 2 and 3. 471 4.1.3. White space serving as backhaul 473 In this use case, an Internet connectivity service is provided to 474 users over a common wireless standard, such as Wi-Fi, with a white 475 space master/slave network providing backhaul connectivity to the 476 Internet. Note that Wi-Fi is referenced in Figure 4 (Figure 4) and 477 the following discussion, but any other technology can be substituted 478 in its place. 480 Figure 4 (Figure 4) shows an example deployment of this scenario. 481 \|/ White \|/ \|/ Wi-Fi \|/ 482 | Space | | | 483 | | | |-|----| 484 (----) |-|----| |-|------|-| | Wi-Fi| 485 ( ) |Master| | Slave |--(Air)--| Dev | 486 / \ | |--(Air)--| Bridge | |------| 487 ( Internet )---| | | to Wi-Fi | 488 \ / |------| |----------| \|/ 489 ( ) \ | 490 (----) \(Air) |-|----| 491 \--| Wi-Fi| 492 | Dev | 493 |------| 495 Figure 4: White Space Network Used for Backhaul 497 Once the bridged device (WS + Wi-Fi) is connected to a master and WS 498 network, a simplified operation scenario of backhaul for Wi-Fi 499 consists of the following steps: 501 1. A bridged slave device (WS + Wi-Fi) is connected to a master 502 device operating in the WS spectrum (the master obtains available 503 white space spectrum as described in Section 4.1.1). 505 2. Once the slave device is connected to the master, the Wi-Fi 506 access point has Internet connectivity as well. 508 3. End users attach to the Wi-Fi network via their Wi-Fi enabled 509 devices and receive Internet connectivity. 511 4.1.4. Rapid network deployment during emergency scenario 513 Organizations involved in handling emergency operations maintain an 514 infrastructure that relies on dedicated spectrum for their 515 operations. However, such infrastructures are often affected by the 516 disasters they handle. To set up a replacement network, spectrum 517 needs to be quickly cleared and reallocated to the crisis response 518 organization. Automation of the this allocation and assignment is 519 often the best solution. A preferred option is to make use of a 520 robust protocol that has been adopted and implemented by radio 521 manufacturers. A typical network topology solution might include 522 wireless access links to the public Internet or private network, 523 wireless ad-hoc network radios working independent of a fixed 524 infrastructure, and satellite links for backup where lack of 525 coverage, overload, or outage of wireless access links can occur. 527 Figure 5 (Figure 5) shows an example deployment of this scenario. 528 \|/ 529 | ad hoc 530 | 531 |-|-------------| 532 | Master node | |------------| 533 \|/ | with | | Whitespace | 534 | ad hoc /| backhaul link | | Database | 535 | /---/ |---------------| |------------| 536 ---|------------/ | \ / 537 | Master node | | | (--/--) 538 | without | | -----( ) 539 | backhaul link | | Wireless / Private \ 540 ----------------\ | Access ( net or ) 541 \ | \ Internet ) 542 \ \|/ | ------( / 543 \ | ad hoc | | (------) 544 \ | | / \ 545 \--|------------- /Satellite ---------- 546 | Master node | / Link | Other | 547 | with |/ | nodes | 548 | backhaul link | ---------- 549 ----------------- 551 Figure 5: Rapid-deployed Network with Partly-connected Nodes 553 In the ad-hoc network, all nodes are master nodes that allocate RF 554 channels from the white space database (as described in 555 Section 4.1.1). However, the backhaul link may not be available to 556 all nodes, such as depicted for the left node in the above figure. 557 To handle RF channel allocation for such nodes, a master node with a 558 backhaul link relays or proxies the database query for them. So 559 master nodes without a backhaul link follow the procedure as defined 560 for clients. The ad-hoc network radios utilize the provided RF 561 channels. Details on forming and maintenance of the ad-hoc network, 562 including repair of segmented networks caused by segments operating 563 on different RF channels, is out of scope of spectrum allocation. 565 4.1.5. White space used for local TV broadcaster 567 Available white space spectrum can be deployed in novel ways to 568 leverage the public use of hand-held and portable devices. One such 569 use is white space spectrum used for local TV transmission of audio- 570 video content to portable devices used by individuals in attendance 571 at an event. In this use case, audience members at a seminar, 572 entertainment event, or other venue plug a miniature TV receiver fob 573 into their laptop, computer tablet, cell phone, or other portable 574 device. A master device obtains a list of available white space 575 spectrum (as described in , (Section 4.1.1), then broadcasts audio- 576 video content locally to the audience over one of the available 577 frequencies. Audience members receive the content through their 578 miniature TV receivers tuned to the appropriate white space band for 579 display on their portable device monitors. 581 Figure 6 (Figure 6) shows an example deployment of this scenario. 583 \|/ |------------| 584 | |White Space | 585 | Database | 586 | .---. / |------------| 587 |-----------| ( ) / 588 | Master | / \ 589 | |========( Internet) 590 |-----------| \ / 591 | ( ) 592 /|\ (---) 594 (White Space 595 Broadcast) 597 \|/ \|/ \|/ \|/ \|/ \|/ \|/ 598 | | | | | | | ................. 599 ----- ----- ----- ----- ----- ----- ----- 600 | | | | | | | | | | | | | | 601 | | | | | | | | | | | | | | 602 ----- ----- ----- ----- ----- ----- ----- 603 USB TV receivers connected to laptops, cellphone, tablets .... 605 Figure 6: White Space Used for Local TV Broadcast 607 5. Problem Statement 609 The use of white space spectrum is enabled via the capability of a 610 device to query a database and obtain information about the 611 availability of spectrum for use at a given location. The databases 612 are reachable via the Internet and the devices querying these 613 databases are expected to have some form of Internet connectivity, 614 directly or indirectly. The databases may be regulatory specific 615 since the available spectrum and regulations may vary, but the 616 fundamental operation of the protocol should be regulatory 617 independent. 619 An example high-level architecture of the devices and white space 620 databases is shown in Figure 7 (Figure 7). 621 ----------- 622 | Master | 623 |WS Device| ------------ 624 |Lat: X |\ .---. /--------|Database X| 625 |Long: Y | \ ( ) / ------------ 626 ----------- \-------/ \/ o 627 ( Internet) o 628 ----------- /------( )\ o 629 | Master | / ( ) \ 630 |WS Device|/ (_____) \ ------------ 631 |Lat: X | \--------|Database Y| 632 |Long: Y | ------------ 633 ----------- 635 Figure 7: High-level View of White Space Database Architecture 637 In Figure 11, note that there could be multiple databases serving 638 white space devices. The databases are locale specific since the 639 regulations and available spectrum may vary. In some countries, for 640 example, the U.S., the regulator has determined that multiple 641 databases may provide service to White Space Devices. 643 A messaging interface between the white space devices and the 644 database is required for operating a network using the white space 645 spectrum. The following sections discuss various aspects of such an 646 interface and the need for a standard. 648 5.1. Global applicability 650 The use of white space spectrum is currently approved or being 651 considered in multiple regulatory domains, whose rules may differ. 652 However, the need for devices that intend to use the spectrum to 653 communicate with a database remains a common feature. The database 654 implements rules that protect all primary users, independent of the 655 characteristics of the white space devices. It also provides a way 656 to specify a schedule of use, since some primary users (for example, 657 wireless microphones) only operate in limited time slots. 659 Devices need to be able to query a database, directly or indirectly, 660 over the public Internet and/or private IP networks prior to 661 operating in available spectrum. Information about available 662 spectrum, schedule, power, etc., are provided by the database as a 663 response to the query from a device. The messaging interface needs 664 to be: 666 1. Radio/air interface agnostic - The radio/air interface technology 667 used by the white space device in available spectrum can be IEEE 668 802.11af, IEEE 802.15.4m, IEEE 802.16, IEEE 802.22, LTE etc. 669 However the messaging interface between the white space device 670 and the database should be agnostic to the air interface while 671 being cognizant of the characteristics of various air-interface 672 technologies and the need to include relevant attributes in the 673 query to the database. 675 2. Spectrum agnostic - the spectrum used by primary and secondary 676 users varies by country. Some spectrum has an explicit notion of 677 a "channel": a defined swath of spectrum within a band that has 678 some assigned identifier. Other spectrum bands may be subject to 679 white space sharing, but only have actual frequency low/high 680 parameters to define primary and secondary use. The protocol 681 should be able to be used in any spectrum band where white space 682 sharing is permitted. 684 3. Globally applicable - A common messaging interface between white 685 space devices and databases will enable the use of such spectrum 686 for various purposes on a global basis. Devices can operate in 687 any locale where such spectrum is available and a common 688 interface ensures uniformity in implementations and deployment. 689 Since the White Space Device must know its geospatial location to 690 do a query, it is possible to determine which database, and which 691 rules, are applicable, even though they are locale specific. 692 Note that although a device may know its geolocation, it may not 693 know the country or regulatory domain that it is in. Further, 694 even if the device knows this information, it may not be 695 sufficient for the device to know its expected behaviour in its 696 domain of operation since one domain may adopt a rule set for 697 white space device operation from another regulatory domain 698 (Brazil may adopt the "FccWhitespace2010" US rule set). To allow 699 the global use of white space devices in different countries 700 (whatever the regulatory domain), the protocol should support the 701 Database communicating applicable rule set information to the 702 white space device. 704 4. Flexible and extensible data structures - Different databases are 705 likely to have different requirements for the kinds of data 706 required for registration (different rule sets that apply to the 707 registration of devices) and other messages sent by the device to 708 the database. For instance, different regulators might require 709 different device-characteristic information to be passed to the 710 database. 712 5.2. Database discovery 714 Another aspect of the problem space is the need to discover the 715 database. A white space device needs to find the relevant database 716 to query, based on its current location or for another location. 717 Since the spectrum and databases are domain specific, the device will 718 need to discover the relevant database. The device needs to 719 determine the location of the specific database to which it can send 720 queries in addition to registering itself for operation and using the 721 available spectrum. 723 5.3. Protocol 725 A protocol that enables a white space device to query a database to 726 obtain information about available spectrum is needed. A device may 727 be required to register with the database with some credentials prior 728 to being allowed to query. The requirements for such a protocol are 729 specified in this document. 731 5.4. Data model definition 733 The contents of the queries and response need to be specified. A 734 data model is required which enables the white space device to query 735 the database while including all the relevant information such as 736 geolocation, radio technology, power characteristics, etc., which may 737 be country and spectrum and regulatory dependent. All databases are 738 able to interpret the data model and respond to the queries using the 739 same data model that is understood by all devices. 741 6. Requirements 743 6.1. Data Model Requirements 745 D.1 The Data Model MUST support specifying the geolocation of the 746 WSD, the uncertainty in meters, the height & its uncertainty, 747 and confidence in percentage of the location determination. 748 The Data Model MUST support WGS84 (see NGA: DoD World Geodetic 749 System 1984 [3]). 751 D.2 The Data Model MUST support specifying the data and other 752 applicable requirements of the rule set that applies to the 753 white space device at its current location. 755 D.3 The Data Model MUST support device description data that 756 identifies a device (serial number, certification IDs, etc.) 757 and describes device characteristics, such as or device class 758 (fixed, mobile, portable, indoor, outdoor, etc.), Radio Access 759 Technology (RAT), etc. 761 D.4 The Data Model MUST support specifying a manufacturer's 762 serial number for a white space device. 764 D.5 The Data Model MUST support specifying the antenna and 765 radiation related parameters of the subject, such as: 767 antenna height 769 antenna gain 771 maximum output power, EIRP (dBm) 773 antenna radiation pattern (directional dependence of the 774 strength of the radio signal from the antenna) 776 spectrum mask with lowest and highest possible frequency 778 spectrum mask in dBr from peak transmit power in EIRP, with 779 specific power limit at any frequency linearly interpolated 780 between adjacent points of the spectrum mask 782 measurement resolution bandwidth for EIRP measurements 784 D.6 The Data Model MUST support specifying owner and operator 785 contact information for a transmitter. This includes the name 786 of the transmitter owner, name of transmitter operator, postal 787 address, email address and phone number of the transmitter 788 operator. 790 D.7 The Data Model MUST support specifying spectrum availability. 791 Spectrum units are specified by low and high frequencies and 792 may have an optional channel identifier. The Data Model MUST 793 support a schedule including start time and stop time for 794 spectrum unit availability. The Data Model MUST support 795 maximum power level for each spectrum unit. 797 D.8 The Data Model MUST support specifying spectrum availability 798 information for a single location and an area (e.g., a polygon 799 defined by multiple location points or a geometric shape such 800 as a circle). 802 D.9 The Data Model MUST support specifying the frequencies and 803 power levels selected for use by a device in the 804 acknowledgement message. 806 6.2. Protocol Requirements 808 P.1 The address of a database (e.g., in form of a URI) can be 809 preconfigured in a master device. The master device MUST be able 810 to contact a database using a pre-configured database address. 811 The master device may validate the database against a list of 812 approved databases maintained by a regulatory body. 814 P.2 The protocol must support the database informing the master of 815 the regulatory rules (rule set) that applies to the master device 816 (or any slave devices on whose behalf the master is contacting the 817 database) at the current location or the master (or slave) 818 device(s). 820 P.3 The protocol MUST provide the ability for the database to 821 authenticate the master device. 823 P.4 The protocol MUST provide the ability for the master device to 824 verify the authenticity of the database with which it is 825 interacting. 827 P.5 The messages sent by the master device to the database and the 828 messages sent by the database to the master device MUST support 829 integrity protection. 831 P.6 The protocol MUST provide the capability for messages sent by 832 the master device and database to be encrypted. 834 P.7 The protocol MUST support the master device registering with the 835 database (see Device Registration (Section 3.1.2)). 837 P.8 The protocol MUST support a registration acknowledgement 838 including appropriate result codes. 840 P.9 The protocol MUST support an available spectrum request from the 841 master device to the database. These parameters MAY include any 842 of the parameters and attributes required to be supported in the 843 Data Model Requirements. 845 P.10 The protocol MUST support an available spectrum response from 846 the database to the master device. These parameters MAY include 847 any of the parameters and attributes required to be supported in 848 the Data Model Requirements. 850 P.11 The protocol MUST support a spectrum usage message from the 851 master device to the database. These parameters MAY include any 852 of the parameters and attributes required to be supported in the 853 Data Model Requirements. 855 P.12 The protocol MUST support a spectrum usage message 856 acknowledgement. 858 P.13 The protocol MUST support a validation request from the master 859 to the database to validate a slave device. The validation 860 request MUST include the slave device ID. 862 P.14 The protocol MUST support a validation response from the 863 database to the master to indicate if the slave device is 864 validated by the WSDB. The validation response MUST include a 865 response code. 867 P.15 The protocol between the master device and the database MUST 868 support the capability to change spectrum availability information 869 on short notice. 871 P.16 The protocol between the master device and the database MUST 872 support a spectrum availability request which specifies a 873 geographic location as an area as well as a point 875 6.3. Operational Requirements 877 This section contains operational requirements of a white space 878 database-device system, independent of the requirements of the 879 protocol for communication between the white space database and 880 devices. 882 O.1 The database and the master device MUST be connected to the 883 Internet. 885 O.2 A master device MUST be able to determine its location including 886 uncertainty and confidence level. A fixed master device MAY use a 887 location programmed at installation or have the capability to 888 determine its location to the required accuracy. A mobile master 889 device MUST have the capability to determine its location to the 890 required accuracy. 892 O.3 The master device MUST identify a database to which it will 893 register, make spectrum availability requests, etc... The master 894 device MAY select a database for service by discovery at runtime 895 or the master device MAY select a database for service by means of 896 a pre-programmed URI address. 898 O.4 The master device MUST implement at least one connection method 899 to access the database. The master device MAY contact a database 900 directly for service or the master device MAY contact a database 901 listing server first followed by contact to a database. 903 O.5 The master device MUST obtain an information on the rule set of 904 the regulatory body that applies to the master device at its 905 current location (and/or the location of any slave devices on 906 whose behalf the master device is operating). 908 O.6 The master device MAY register with the database according to 909 local regulatory policy. Not all master devices will be required 910 to register. Specific events will initiate registration, these 911 events are determined by regulator policy (e.g., at power up, 912 after movement, etc...). When local regulatory policy requires 913 registration, the master device MUST register with its most 914 current and up-to-date information, and MUST include all variables 915 mandated by local regulator policy. 917 O.7 A master device MUST query the database for the available 918 spectrum based on its current location before starting radio 919 transmission in white space. Parameters provided to the database 920 MAY include device location, accuracy of the location, antenna 921 characteristic information, device identifier of any slave device 922 requesting spectrum information, etc. 924 O.8 The database MUST respond to an available spectrum list request 925 from an authenticated and authorized device and MAY also provide 926 time constraints, maximum output power, start and stop frequencies 927 for each band in the list and any additional requirements for 928 sensing. 930 O.9 According to local regulator policy, a master device MAY inform 931 the database of the actual frequency usage of the master and its 932 slaves. The master MUST include parameters required by local 933 regulatory policy, e.g., device ID, manufacturer's serial number, 934 spectrum usage and power level information of the master and its 935 slaves. 937 O.10 After connecting to a master device's radio network a slave 938 device MUST query the master device for a list of available 939 spectrum. The slave MUST include parameters required by local 940 regulatory policy, e.g., device ID, device location. 942 O.11 According to local regulatory policy, the master device MAY 943 query the database with parameters received from the slave device. 945 O.12 The database MUST respond to a query from the master device 946 containing parameters from a slave device. 948 O.13 A master device MUST repeat the query to the database for the 949 available spectrum as often as required by the regulation (e.g., 950 FCC requires once per day) to verify that the operating channels 951 continue to remain available. 953 O.14 A master device which changes its location more than a 954 threshold distance (specified by local regulatory policy) during 955 its operation, MUST query the database for available operating 956 spectrum each time it moves more than the threshold distance 957 (e.g., FCC specifies 100m) from the location it previously made 958 the query. 960 O.15 According to local regulator policy, a master device may 961 contact a database via proxy service of another master device. 963 O.16 A master device MUST be able to query the whitespace database 964 for spectrum availability information for a specific expected 965 coverage area around its current location. 967 O.17 A Master device MUST include its unique identity in all message 968 exchanges with the database. 970 6.4. Guidelines 972 The current scope of the working group is limited and is reflected in 973 the requirements captured in Section 6.1. However white space 974 technology itself is expected to evolve and address other aspects 975 such as co-existence and interference avoidance, spectrum brokering, 976 alternative spectrum bands, etc. The design of the data model and 977 protocol should be cognizant of the evolving nature of white space 978 technology and consider the following set of guidelines in the 979 development of the data model and protocol: 981 1. The data model SHOULD provide a modular design separating out 982 messaging specific, administrative specific, and spectrum 983 specific parts into separate modules. 985 2. The protocol SHOULD support determination of which administrative 986 specific and spectrum specific modules are used. 988 7. IANA Considerations 990 This document makes no request of IANA. 992 8. Security Considerations 994 PAWS is a protocol whereby a Master Device requests a schedule of 995 available spectrum at its location (or location of its Slave Devices) 996 before it (they) can operate using those frequencies. Whereas the 997 information provided by the Database must be accurate and conform to 998 applicable regulatory rules, the Database cannot enforce, through the 999 protocol, that a client device uses only the spectrum it provided. 1000 In other words, devices can put energy in the air and cause 1001 interference without asking the Database. Hence, PAWS security 1002 considerations do not include protection against malicious use of the 1003 White Space spectrum. 1005 Threat model for the PAWS protocol: 1007 Assumptions: 1009 It is assumed that an attacker has full access to the network 1010 medium between the master device and the white space database. 1011 The attacker may be able to eavesdrop on any communications 1012 between these entities. The link between the master device and 1013 the white space database can be wired or wireless and provides 1014 IP connectivity. 1016 It is assumed that both the master device and the white space 1017 database have NOT been compromised from a security standpoint. 1019 Threat 1: User modifies a device to masquerade as another valid 1020 certified device 1022 Regulatory environments require that devices be certified and 1023 register in ways that accurately reflect their certification. 1024 Without suitable protection mechanisms, devices could simply 1025 listen to registration exchanges, and later registering 1026 claiming to be those other devices. Such replays would allow 1027 false registration, violating regulatory regimes. A white 1028 space database may be operated by a commercial entity which 1029 restricts access only to authorized users. A master device MAY 1030 need to identify itself to the database and be authorized to 1031 obtain information about available spectrum. 1033 Threat 2: Spoofed white space database 1035 A master device discovers a white space database(s) through 1036 which it can query for available spectrum information. The 1037 master device needs to ensure that the white space database 1038 with which it communicates with is an authentic entity. The 1039 white space database needs to provide its identity to the 1040 master device which can confirm the validity/authenticity of 1041 the database. An attacker may attempt to spoof a white space 1042 database and provide responses to a master device which are 1043 malicious and result in the master device causing interference 1044 to the primary user of the spectrum. 1046 Threat 3: Modifying a query request 1048 An attacker may modify the query request sent by a master 1049 device to a white space database. The attacker may change the 1050 location of the device or the capabilities in terms of its 1051 transmit power or antenna height etc., which could result in 1052 the database responding with incorrect information about 1053 available spectrum or max transmit power allowed. The result 1054 of such an attack is that the master device would cause 1055 interference to the primary user of the spectrum. It could 1056 also result in a denial of service to the master device by 1057 indicating that no channels are available. 1059 Threat 4: Modifying a query response 1061 An attacker could modify the query response sent by the white 1062 space database to a master device. The available spectrum 1063 information or transmit power allowed type of parameters 1064 carried in the response could be modified by the attacker 1065 resulting in the master device using spectrum that is not 1066 available at a location or transmitting at a greater power 1067 level than allowed resulting in interference to the primary 1068 user of that spectrum. Alternatively the attacker may indicate 1069 no spectrum availability at a location resulting in a denial of 1070 service to the master device. 1072 Threat 5: Third party tracking of white space device location and 1073 identity 1075 A white space database in a regulatory domain may require a 1076 master device to provide its identity in addition to its 1077 location in the query request. Such location/identity 1078 information can be gleaned by an eavesdropper and used for 1079 tracking purposes. A master device may prefer to keep the 1080 location/identity information hidden from eavesdroppers, hence 1081 the protocol should provide a means to protect the location and 1082 identity information of the master device and prevent tracking 1083 of locations associated with a white space database query. 1084 When the master device sends both its identity and location to 1085 the DB, the DB is able to track it. If a regulatory domain 1086 does not require the master device to provide its identity to 1087 the white space database, the master device may decide not to 1088 send its identity, to prevent being tracked by the DB. 1090 Threat 6: Malicious individual acts as a PAWS entity (spoofing DB 1091 or as MiM) to terminate or unfairly limit spectrum access of 1092 devices for reasons other than incumbent protection 1094 A white space database MAY include a mechanism by which service 1095 and spectrum allocated to a master device can be revoked by 1096 sending an unsolicited message. A malicious node can pretend 1097 to be the white space database with which a master device has 1098 registered or obtained spectrum information from and send a 1099 revoke message to that device. This results in denial of 1100 service to the master device. 1102 Threat 7: Natural disaster resulting in inability to obtain 1103 authorization for white space spectrum use by emergency responders 1105 In the case of a sizable natural disaster a lot of Internet 1106 infrastructure ceases to function, emergency services users 1107 need to reconstitute quickly and will rely on establishing 1108 radio WANs. In such cases, radio WAN gear that has been unused 1109 suddenly needs to be pressed into action. And the radio WANs 1110 need frequency authorizations to function. Regulatory entities 1111 may also authorize usage of additional spectrum in the affected 1112 areas. The white space radio entities may need to establish 1113 communication with a database and obtain authorizations. In 1114 cases where communication with the white space database fails, 1115 the white space devices cannot utilize white space spectrum. 1116 Emergency services, which require more spectrum precisely at 1117 locations where network infrastructure is malfunctioning or 1118 overloaded, backup communication spectrum and distributed white 1119 space databases are needed to overcome such circumstances. 1120 Alternatively there may be other mechanisms which allow the use 1121 of spectrum by emergency service equipment without strict 1122 authorization or with liberal interpretation of the regulatory 1123 policy for white space usage. 1125 The security requirements arising from the above threats are captured 1126 in the requirements of Section 6.1 (Section 6.1). 1128 9. Summary and Conclusion 1130 Wireless spectrum is a scarce resource. As the demand for spectrum 1131 grows, there is a need to more efficiently utilize the available and 1132 allocated spectrum. Cognitive radio technologies enable the 1133 efficient usage of spectrum via means such as sensing or by querying 1134 a database to determine available spectrum at a given location for 1135 opportunistic use. "White space" is the general term used to refer 1136 to the bands within the spectrum which are available for secondary 1137 use at a given location. In order to use this spectrum, a device 1138 needs to query a database that maintains information about the 1139 available spectrum within a band. A protocol is necessary for 1140 communication between the devices and databases that is globally 1141 applicable. 1143 The document describes some examples of the role of the white space 1144 database in the operation of a radio network, and also provides 1145 examples of services provided to the user of a white space device. 1146 From these use cases, requirements are determined. These 1147 requirements are to be used as input for the development of a 1148 Protocol to Access White Space database (PAWS). 1150 10. Acknowledgements 1152 The authors acknowledge Gabor Bajko, Teco Boot, Nancy Bravin, Rex 1153 Buddenberg, Vincent Chen, Gerald Chouinard, Stephen Farrell, Michael 1154 Fitch, Joel M. Halpern, Jussi Kahtava, Paul Lambert, Pete Resnick, 1155 Brian Rosen, Andy Sago, Peter Stanforth, John Stine and, Juan Carlos 1156 Zuniga for their contributions to this document. 1158 11. References 1160 11.1. Normative References 1162 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1163 Requirement Levels", BCP 14, RFC 2119, March 1997. 1165 11.2. Informational References 1167 URIs 1169 [1] 1171 [2] 1173 [3] 1176 Authors' Addresses 1178 Anthony Mancuso (editor) 1180 Scott Probasco 1182 Phone: 1183 Fax: 1184 Email: scott@probasco.me 1185 URI: 1187 Basavaraj Patil 1189 Phone: 1190 Fax: 1191 Email: bpatil@ovi.com 1192 URI: