idnits 2.17.1 draft-ietf-paws-problem-stmt-usecases-rqmts-13.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 14, 2013) is 4089 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-20) exists of draft-ietf-paws-protocol-03 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PAWS Mancuso, Ed. 2 Internet-Draft Google 3 Intended status: Informational Probasco 4 Expires: August 18, 2013 Patil 5 February 14, 2013 7 Protocol to Access White Space (PAWS) Database: Use Cases and 8 Requirements 9 draft-ietf-paws-problem-stmt-usecases-rqmts-13 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. This document 18 includes the problem statement for the development of a protocol to 19 access a database of whitespace information followed by use cases and 20 requirements for that protocol. Finally, requirements associated 21 with the protocol are presented. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 27 document are to be interpreted as described in RFC 2119 [RFC2119]. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on August 18, 2013. 46 Copyright Notice 47 Copyright (c) 2013 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Introduction to White Space . . . . . . . . . . . . . . . 3 64 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 1.2.1. In Scope . . . . . . . . . . . . . . . . . . . . . . . 4 66 1.2.2. Out of Scope . . . . . . . . . . . . . . . . . . . . . 4 67 2. Terminology Used in this Document . . . . . . . . . . . . . . 4 68 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 69 3.1. Global Applicability . . . . . . . . . . . . . . . . . . . 6 70 3.2. Database Discovery . . . . . . . . . . . . . . . . . . . . 7 71 3.3. Device Registration . . . . . . . . . . . . . . . . . . . 8 72 3.4. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 3.5. Data Model Definition . . . . . . . . . . . . . . . . . . 8 74 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 4.1. Master-slave White Space Networks . . . . . . . . . . . . 9 76 4.2. Offloading: Moving Traffic to a White Space Network . . . 11 77 4.3. White Space Serving as Backhaul . . . . . . . . . . . . . 13 78 4.4. Rapid Network Deployment During Emergencies . . . . . . . 14 79 4.5. White Space Used for Local TV Broadcaster . . . . . . . . 15 80 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 16 81 5.1. Data Model Requirements . . . . . . . . . . . . . . . . . 16 82 5.2. Protocol Requirements . . . . . . . . . . . . . . . . . . 17 83 5.3. Operational Requirements . . . . . . . . . . . . . . . . . 18 84 5.4. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . 19 85 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 86 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 87 8. Acknowledegements . . . . . . . . . . . . . . . . . . . . . . 21 88 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 89 9.1. Normative References . . . . . . . . . . . . . . . . . . . 22 90 9.2. Informational References . . . . . . . . . . . . . . . . . 22 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 93 1. Introduction 95 1.1. Introduction to White Space 97 Wireless spectrum is a commodity that is regulated by governments. 98 The spectrum is used for various purposes, which include, but are not 99 limited to, entertainment (e.g., radio and television), communication 100 (e.g., telephony and Internet access), military (e.g., radars etc.), 101 and navigation (e.g., satellite communication, GPS). Portions of the 102 radio spectrum that are assigned to a licensed (primary) user but are 103 unused or unoccupied at specific locations and times are defined as 104 "white space." The concept of allowing additional (secondary) 105 transmissions (which may or may not be licensed) in white space is a 106 technique to "unlock" existing spectrum for new use. 108 An obvious requirement is that these secondary transmissions do not 109 interfere with the assigned use of the spectrum. One interesting 110 observation is that often, in a given physical location, the primary 111 user(s) may not be using the entire band assigned to them. The 112 available spectrum for secondary transmissions would then depend on 113 the location of the secondary user. The fundamental issue is how to 114 determine, for a specific location and specific time, if any of the 115 assigned spectrum is available for secondary use. 117 Academia and Industry have studied multiple cognitive radio [1] 118 mechanisms for use in such a scenario. One simple mechanism is to 119 use a geospatial database that contains the spatial and temporal 120 profile of all primary licensees' spectrum usage, and require 121 secondary users to query the database for available spectrum that 122 they can use at their location. Such databases can be accessible and 123 queryable by secondary users on the Internet. 125 Any entity that is assigned spectrum that is not densely used may be 126 asked by a governmental regulatory agency to share it to allow for 127 more intensive use of the spectrum. Providing a mechanism by which 128 secondary users share the spectrum with the primary user is 129 attractive in many bands in many countries. 131 This document includes the problem statement followed by use cases 132 and requirements associated with the use of white-space spectrum by 133 secondary users via a database query protocol. The final sections 134 include the requirements associated with such a protocol. Note that 135 the IETF has undertaken to develop a white-space database query 136 protocol (see [I-D.ietf-paws-protocol]). 138 1.2. Scope 140 1.2.1. In Scope 142 This document covers the requirements for a protocol to allow a 143 device to access a database to obtain spectrum availability 144 information. Such a protocol should allow a device to perform the 145 following actions: 147 1. Determine the relevant white-space database to query. 149 2. Connect to and optionally register with the database using a 150 well-defined protocol. 152 3. Provide its geolocation and perhaps other data to the database 153 using a well-defined format for querying the database. 155 4. Receive in response to the query a list of available white-space 156 frequencies using a well-defined format for the information. 158 5. Send an acknowledgment to the database with information 159 containing channels selected for use by the device and other 160 device operation parameters. 162 Note. The above protocol actions should explicitly or implicitly 163 support the ability of devices to re-register and/or re-query the 164 database when it changes it location or operating parameters, to 165 receive permission to operate in its new location and/or with its new 166 operating parameters, and send an acknowledgment to the database that 167 includes information on its new operating parameters. 169 1.2.2. Out of Scope 171 The following topics are out of scope for this specification: 173 1. Co-existence and interference avoidance of white space devices 174 within the same spectrum. 176 2. Provisioning (releasing new spectrum for white space use). 178 2. Terminology Used in this Document 180 Database A database is an entity that contains current information 181 about available spectrum at a given location and time as well as 182 other types of information related to spectrum availability and 183 usage. 185 Device Class Identifies classes of devices including fixed, mobile, 186 portable, etc... May also indicate if the device is indoor or 187 outdoor. 189 Device ID An identifier for each master device. 191 Master Device A device that queries the database, on its own behalf 192 and/or on behalf of a slave device, to obtain available spectrum 193 information. 195 Slave Device A device that queries the database through a master 196 device. 198 White Space (WS) Radio spectrum that is available for secondary use 199 at a specific location and time. 201 White Space Device (WSD) A device that uses white-space spectrum as 202 a secondary user. A white space device can be a fixed or portable 203 device such as an access point, base station, or cell phone. 205 3. Problem Statement 207 The use of white-space spectrum is enabled via the capability of a 208 device to query a database and obtain information about the 209 availability of spectrum for use at a given location. The databases 210 are reachable via the Internet and the devices querying these 211 databases are expected to have some form of Internet connectivity, 212 directly or indirectly. While databases are expected to support the 213 rule set(s) of one or more regulatory domains, and the regulations 214 and available spectrum associated with each rule set may vary, the 215 fundamental operation of the protocol should be regulatory 216 independent. 218 An example high-level architecture of the devices and white-space 219 databases is shown in Figure 1. 221 ----------- 222 | Master | 223 |WS Device| ------------ 224 |Lat: X |\ .---. /--------|Database X| 225 |Long: Y | \ ( ) / ------------ 226 ----------- \-------/ \/ o 227 ( Internet) o 228 ----------- /------( )\ o 229 | Master | / ( ) \ 230 |WS Device|/ (_____) \ ------------ 231 |Lat: X | \--------|Database Y| 232 |Long: Y | ------------ 233 ----------- 235 Figure 1: High-level View of White Space Database Architecture 237 Note that there could be multiple databases serving white space 238 devices. In some countries, such as the U.S., the regulator has 239 determined that multiple databases may provide service to White Space 240 Devices. 242 A messaging interface between the white space devices and the 243 database is required for operating a network using the white-space 244 spectrum. The following sections discuss various aspects of such an 245 interface and the need for a standard. 247 3.1. Global Applicability 249 The use of white-space spectrum is currently approved or being 250 considered in multiple regulatory domains, whose rules may differ. 251 However, the need for devices that intend to use the spectrum to 252 communicate with a database remains a common feature. The database 253 implements rules that protect all primary users, independent of the 254 characteristics of the white space devices. It also provides a way 255 to specify a schedule of use, since some primary users (for example, 256 wireless microphones) only operate in limited time slots. 258 Devices need to be able to query a database, directly or indirectly, 259 over the public Internet and/or private IP networks prior to 260 operating in available spectrum. Information about available 261 spectrum, schedule, power, etc., are provided by the database as a 262 response to the query from a device. The messaging interface needs 263 to be: 265 1. Interface agnostic - An interface between a master white space 266 device and database can be wired or unwired (e.g., a radio/air 267 interface technology such as IEEE 802.11af, IEEE 802.15.4m, IEEE 268 802.16, IEEE 802.22, LTE etc.) However, the messaging interface 269 between a master white space device and the database should be 270 agnostic to the interface used for such messaging while being 271 cognizant of the characteristics of the interface technology and 272 the need to include any relevant attributes in the query to the 273 database. 275 2. Spectrum agnostic - the spectrum used by primary and secondary 276 users varies by country. Some spectrum has an explicit notion of 277 a "channel": a defined swath of spectrum within a band that has 278 some assigned identifier. Other spectrum bands may be subject to 279 white space sharing, but only have actual frequency low/high 280 parameters to define primary and secondary use. The protocol 281 should be able to be used in any spectrum band where white space 282 sharing is permitted. 284 3. Globally applicable - A common messaging interface between white 285 space devices and databases will enable the use of such spectrum 286 for various purposes on a global basis. Devices can operate in 287 any location where such spectrum is available and a common 288 interface ensures uniformity in implementations and deployment. 289 To allow the global use of white space devices in different 290 countries (whatever the regulatory domain), the protocol should 291 support the database communicating applicable regulatory rule set 292 information to the white space device. 294 4. Flexible and extensible data structures - Different databases are 295 likely to have different requirements for the kinds of data 296 required for registration (different regulatory rule sets that 297 apply to the registration of devices) and other messages sent by 298 the device to the database. For instance, different regulators 299 might require different device-characteristic information to be 300 passed to the database. 302 3.2. Database Discovery 304 The master device must obtain the address of a trusted white-space 305 database, which it will query for available white-space spectrum. If 306 the master device uses a discovery service to locate a trusted white- 307 space database, it performs the following steps: 309 1. The master device constructs and sends a request (e.g., over the 310 Internet) to a trusted discovery service. 312 2. If no acceptable response is received within a pre-configured 313 time limit, the master device concludes that no trusted database 314 is available. If at least one response is received, the master 315 device evaluates the response(s) to determine if a trusted 316 database can be identified where the master device is able to 317 receive service from the database. If so, it establishes contact 318 with the trusted database. 320 3. The master device establishes a white space network as described 321 in Section 4. 323 Optionally, and in place of steps 1 - 3 above, the master device can 324 be pre-programmed with the location (e.g., Internet address) of one 325 or more one trusted databases. The master device can establish 326 contact with one of these trusted databases. 328 3.3. Device Registration 330 The master device may register with the database before it queries 331 the database for available spectrum. A registration process may 332 consist of the following steps: 334 1. The master device sends registration information to the database. 335 This information may include the Device ID, serial number 336 assigned by the manufacturer, device location, device antenna 337 height above ground, name of the individual or business that owns 338 the device, and the name, street and email address, and telephone 339 number of a contact person responsible for the device's 340 operation. 342 2. The database responds to the registration request with an 343 acknowledgement to indicate the success of the registration 344 request or with an error if the registration was unsuccessful. 345 Additional information may be provided by the database in its 346 response to the master device. 348 3.4. Protocol 350 A protocol that enables a white space device to query a database to 351 obtain information about available spectrum is needed. A device may 352 be required to register with the database with some credentials prior 353 to being allowed to query. The requirements for such a protocol are 354 specified in this document. 356 3.5. Data Model Definition 358 The contents of the queries and response need to be specified. A 359 data model is required which enables the white space device to query 360 the database while including all the relevant information such as 361 geolocation, radio technology, power characteristics, etc., which may 362 be country and spectrum and regulatory dependent. All databases are 363 able to interpret the data model and respond to the queries using the 364 same data model that is understood by all devices. 366 4. Use Cases 368 There are many potential use cases for white-space spectrum - for 369 example, providing broadband Internet access in urban and densely- 370 populated hotspots as well as rural and remote, underserved areas. 371 Available white-space spectrum may also be used to provide Internet 372 'backhaul' for traditional Wi-Fi hotspots or for use by towns and 373 cities to monitor/control traffic lights, read utility meters, and 374 the like. Still other use cases include the ability to offload data 375 traffic from another Internet access network (e.g., 3G cellular 376 network) or to deliver data, information, or a service to a user 377 based on the user's location. Some of these use cases are described 378 in the following sections. 380 4.1. Master-slave White Space Networks 382 There are a number of common scenarios in which a master white space 383 device will act as proxy or mediator for one or more slave devices 384 using its connection to the Internet to query the database for 385 available spectrum for itself and for one or more slave devices. 386 These slave devices may be fixed or mobile, in close proximity with 387 each other (indoor network or urban hotspot), or at a distance (rural 388 or remote WAN). Once slave devices switch to white-space spectrum 389 for their communications, they may connect through the master to the 390 Internet or use white-space spectrum for intra-network communications 391 only. The master device can continue to arbitrate and control white 392 space communications by slave devices, and may notify them when they 393 are required to change white-space frequencies or cease white space 394 communications. 396 Figure 2 depicts the general architecture of such a simple master- 397 slave network, in which the master device communicates on its own 398 behalf and on behalf of slave devices with a white-space database. 400 -------- 401 |Slave | 402 |Device| \ \|/ ---------- 403 | 1 | (Air) | |Database| 404 -------- \ | (----) /|--------| 405 | \ ------|------ ( ) / 406 | \| Master | / \ 407 -------- /| |======= ( Internet ) 408 |Slave | / | Device | \ / 409 |Device| (Air) | | ( ) 410 | 2 | / |-----------| (----) 411 |------- / 412 o | / 413 o | (Air) 414 o | / 415 -------- / 416 |Slave | / 417 |Device| / 418 | n | 419 -------- 421 Figure 2: Master-Slave White Space Network 423 The protocol requirements for these master-slave device and other 424 similar scenarios is essentially the same: the protocol must support 425 the ability of a master device to make available-spectrum query 426 requests on behalf of slave devices, passing device identification, 427 geolocation, and other slave device parameters to the database as 428 required to obtain a list of white-space spectrum available for use 429 by one or more slave devices. Of course, different use cases will 430 use this spectrum information in different ways, and the details of 431 master/slave communications may be different for different use cases. 433 Common steps may occur in master-slave networks include the 434 following: 436 1. The master device powers up. 438 2. Slave devices power up and associate with the master device via 439 Wi-Fi or some other over-the-air non-white-space spectrum. Until 440 the slave device is allocated white-space spectrum, any master- 441 slave or slave-slave communications occurs over such non-white- 442 space spectrum. 444 3. The master has Internet connectivity, determines (or knows) its 445 location, and establishes a connection to a trusted white-space 446 database (see Section 3.2). 448 4. The master may register with the trusted database (see 449 Section 3.3). 451 5. The master sends a query to the trusted database requesting a 452 list of available white-space spectrum based upon its 453 geolocation. Query parameters may include the master's location, 454 device identifier, and antenna height. The master may send 455 available-spectrum requests to the database on behalf of slave 456 devices. 458 6. The database responds to the master's query with a list of 459 available white-space spectrum, associated maximum power levels, 460 and a durations of time for spectrum use. If the master made 461 requests on behalf of slave devices, the master may transmit the 462 obtained available-spectrum lists to the slaves (or the master 463 may allocate spectrum to slaves from the obtained spectrum 464 lists). 466 7. The master may inform the database of the spectrum and power 467 level it selects from the available spectrum list. If a slave 468 device has been allocated available white-space spectrum, the 469 slave may inform the master of the spectrum and power level it 470 has chosen, and the master may, in turn, relay such slave device 471 usage to the database. 473 8. Further communication among masters and slaves over the white 474 space network may occur via the selected/allocated white-space 475 spectrum frequencies. 477 Note: Steps 5 through 7 may be repeated by the master device when it 478 (or a slave device that uses the master as a proxy to communicate 479 with the database) changes its location or operating parameters -- 480 for example, after a master changes location, it may query the 481 database for available spectrum at its new location, then acknowledge 482 the subsequent response received from the database with information 483 on the spectrum and power levels it is using at the new location. 485 4.2. Offloading: Moving Traffic to a White Space Network 487 This scenario is a variant of the master-slave network described in 488 the previous use case. In this scenario, an access point (AP) offers 489 a white space service that offloads Internet traffic as an 490 alternative datapath to a more congested or costly Internet wire, 491 wireless, or satellite service. 493 Figure 3 shows an example deployment of this scenario. 495 \|/ 496 | 497 |--|----------| 498 \|/ /|Access Point |\ 499 | (Air)--/ |-------------| \ 500 --|------ / \ ----------- 501 |Portable|/ \ (----) | Database| 502 | Device | \ ( ) /---------- 503 |--------|\ \ / \ 504 \ X( Internet ) 505 \ / \ / 506 (Air) / ( ) 507 \ / (----) 508 \ / 509 \|---------------|/ 510 | Metered | 511 | Service | 512 |---------------| 514 Figure 3: Offloading Traffic to a White Space Network 516 A simplified operation scenario of offloading content, such as video 517 stream, from the a congested or costly Internet connection to a white 518 space service provided by an AP consists of the following steps: 520 1. The AP contacts the database to determine channels it can use. 522 2. The portable device connects to a paid Internet service and 523 selects a video for streaming. 525 3. The portable device determines if it can offload to a white space 526 access point: 528 A. If the portable device knows its location, it 530 1. asks the database (using the paid service) for available 531 white-space spectrum; 533 2. listens for and connects to the AP over the permitted 534 white-space spectrum. 536 B. If the portable device does not have GPS or other means to 537 determine its position, it 539 1. uses non-white-space spectrum to listen for and connect 540 to the AP; 542 2. asks the AP to query the database for permitted white- 543 space spectrum on its behalf; 545 3. uses the permitted white-space spectrum to connect to the 546 AP. 548 4. The portable device accesses the Internet through the AP to 549 stream the selected video. 551 4.3. White Space Serving as Backhaul 553 In this use case, an Internet connectivity service is provided to 554 users over a common wireless standard, such as Wi-Fi, with a white 555 space master/slave network providing backhaul connectivity to the 556 Internet. Note that Wi-Fi is referenced in Figure 4 and the 557 following discussion, but any other technology can be substituted in 558 its place. 560 Figure 4 shows an example deployment of this scenario. 561 \|/ White \|/ \|/ Wi-Fi \|/ 562 | Space | | | 563 | | | |-|----| 564 (----) |-|----| |-|------|-| | Wi-Fi| 565 ( ) |Master| | Slave |--(Air)--| Dev | 566 / \ | |--(Air)--| Bridge | |------| 567 ( Internet )---| | | to Wi-Fi | 568 \ / |------| |----------| \|/ 569 ( ) \ | 570 (----) \(Air) |-|----| 571 \--| Wi-Fi| 572 | Dev | 573 |------| 575 Figure 4: White Space Network Used for Backhaul 577 Once the bridged device (WS + Wi-Fi) is connected to a master and WS 578 network, a simplified operation scenario of backhaul for Wi-Fi 579 consists of the following steps: 581 1. A bridged slave device (WS + Wi-Fi) is connected to a master 582 device operating in the WS spectrum (the master obtains available 583 white-space spectrum as described in Section 4.1). 585 2. Once the slave device is connected to the master, the Wi-Fi 586 access point has Internet connectivity as well. 588 3. End users attach to the Wi-Fi network via their Wi-Fi enabled 589 devices and receive Internet connectivity. 591 4.4. Rapid Network Deployment During Emergencies 593 Organizations involved in handling emergency operations maintain an 594 infrastructure that relies on dedicated spectrum for their 595 operations. However, such infrastructures are often affected by the 596 disasters they handle. To set up a replacement network, spectrum 597 needs to be quickly cleared and reallocated to the crisis response 598 organization. Automation of the this allocation and assignment is 599 often the best solution. A preferred option is to make use of a 600 robust protocol that has been adopted and implemented by radio 601 manufacturers. A typical network topology solution might include 602 wireless access links to the public Internet or private network, 603 wireless ad-hoc network radios working independent of a fixed 604 infrastructure, and satellite links for backup where lack of 605 coverage, overload, or outage of wireless access links can occur. 607 Figure 5 shows an example deployment of this scenario. 608 \|/ 609 | ad hoc 610 | 611 |-|-------------| 612 | Master node | |------------| 613 \|/ | with | | Whitespace | 614 | ad hoc /| backhaul link | | Database | 615 | /---/ |---------------| |------------| 616 ---|------------/ | \ / 617 | Master node | | | (--/--) 618 | without | | -----( ) 619 | backhaul link | | Wireless / Private \ 620 ----------------\ | Access ( net or ) 621 \ | \ Internet ) 622 \ \|/ | ------( / 623 \ | ad hoc | | (------) 624 \ | | / \ 625 \--|------------- /Satellite ---------- 626 | Master node | / Link | Other | 627 | with |/ | nodes | 628 | backhaul link | ---------- 629 ----------------- 631 Figure 5: Rapid-deployed Network with Partly-connected Nodes 633 In the ad-hoc network, all nodes are master nodes that allocate RF 634 channels from the white-space database (as described in Section 4.1). 635 However, the backhaul link may not be available to all nodes, such as 636 depicted for the left node in the above figure. To handle RF channel 637 allocation for such nodes, a master node with a backhaul link relays 638 or proxies the database query for them. So master nodes without a 639 backhaul link follow the procedure as defined for clients. The ad- 640 hoc network radios utilize the provided RF channels. Details on 641 forming and maintenance of the ad-hoc network, including repair of 642 segmented networks caused by segments operating on different RF 643 channels, is out of scope of spectrum allocation. 645 4.5. White Space Used for Local TV Broadcaster 647 Available white-space spectrum can be deployed in novel ways to 648 leverage the public use of hand-held and portable devices. One such 649 use is white-space spectrum used for local TV transmission of audio- 650 video content to portable devices used by individuals in attendance 651 at an event. In this use case, audience members at a seminar, 652 entertainment event, or other venue plug a miniature TV receiver fob 653 into their laptop, computer tablet, cell phone, or other portable 654 device. A master device obtains a list of available white-space 655 spectrum (as described in , (Section 4.1), then broadcasts audio- 656 video content locally to the audience over one of the available 657 frequencies. Audience members receive the content through their 658 miniature TV receivers tuned to the appropriate white space band for 659 display on their portable device monitors. 661 Figure 6 shows an example deployment of this scenario. 663 |------------| 664 |White Space | 665 | Database | 666 .---. / |------------| 667 |-----------| ( ) / 668 | Master | / \ 669 | |========( Internet) 670 |-----------| \ / 671 | ( ) 672 /|\ (---) 674 (White Space 675 Broadcast) 677 \|/ \|/ \|/ \|/ \|/ \|/ \|/ 678 | | | | | | | ................. 679 ----- ----- ----- ----- ----- ----- ----- 680 | | | | | | | | | | | | | | 681 | | | | | | | | | | | | | | 682 ----- ----- ----- ----- ----- ----- ----- 683 USB TV receivers connected to laptops, cellphone, tablets .... 685 Figure 6: White Space Used for Local TV Broadcast 687 5. Requirements 689 5.1. Data Model Requirements 691 D.1 The Data Model MUST support specifying the geolocation of the 692 white-space device, the uncertainty in meters, the height & its 693 uncertainty, and confidence in percentage of the location 694 determination. The Data Model MUST support [WGS84]. 696 D.2 The Data Model MUST support specifying the data and other 697 applicable requirements of the rule set that applies to the 698 white space device at its current location. 700 D.3 The Data Model MUST support device description data that 701 identifies a white-space device (serial number, certification 702 IDs, etc.) and describes device characteristics, such as device 703 class (fixed, mobile, portable, indoor, outdoor, etc.), Radio 704 Access Technology (RAT), etc. 706 D.4 The Data Model MUST support specifying a manufacturer's 707 serial number for a white-space device. 709 D.5 The Data Model MUST support specifying the antenna and 710 radiation related parameters of the white-space device, such 711 as: 713 antenna height 715 antenna gain 717 maximum output power, EIRP (dBm) 719 antenna radiation pattern (directional dependence of the 720 strength of the radio signal from the antenna) 722 spectrum mask with lowest and highest possible frequency 724 spectrum mask in dBr from peak transmit power in EIRP, with 725 specific power limit at any frequency linearly interpolated 726 between adjacent points of the spectrum mask 728 measurement resolution bandwidth for EIRP measurements 730 D.6 The Data Model MUST support specifying owner and operator 731 contact information for a transmitter. This includes the name 732 of the transmitter owner, name of transmitter operator, postal 733 address, email address and phone number of the transmitter 734 operator. 736 D.7 The Data Model MUST support specifying spectrum availability. 737 Spectrum units are specified by low and high frequencies and 738 may have an optional channel identifier. The Data Model MUST 739 support a schedule including start time and stop time for 740 spectrum unit availability. The Data Model MUST support 741 maximum power level for each spectrum unit. 743 D.8 The Data Model MUST support specifying spectrum availability 744 information for a single location and an area (e.g., a polygon 745 defined by multiple location points or a geometric shape such 746 as a circle). 748 D.9 The Data Model MUST support specifying the frequencies and 749 power levels selected for use by a white-space device in the 750 acknowledgement message. 752 5.2. Protocol Requirements 754 P.1 The master device identifies a database to which it can 755 register, make spectrum availability requests, etc. The protocol 756 must support the discovery of an appropriate database given a 757 location provided by the master device. The master device may 758 select a database by discovery at run time or by means of a pre- 759 programmed URI address. The master device may validate discovered 760 or configured database addresses against a list of known databases 761 (e.g., a list of databases approved by a regulatory body). 763 P.2 The protocol must support the database informing the master of 764 the regulatory rules (rule set) that applies to the master device 765 (or any slave devices on whose behalf the master is contacting the 766 database) at the current location or the master (or slave) 767 device(s). 769 P.3 The protocol MUST provide the ability for the database to 770 authenticate the master device. 772 P.4 The protocol MUST provide the ability for the master device to 773 verify the authenticity of the database with which it is 774 interacting. 776 P.5 The messages sent by the master device to the database and the 777 messages sent by the database to the master device MUST support 778 integrity protection. 780 P.6 The protocol MUST provide the capability for messages sent by 781 the master device and database to be encrypted. 783 P.7 The protocol MUST support the master device registering with the 784 database (see Device Registration (Section 3.3)). 786 P.8 The protocol MUST support a registration acknowledgement 787 indicating the success or failure of the master device 788 registration. 790 P.9 The protocol MUST support an available spectrum request from the 791 master device to the database, which may include one or more of 792 the data items listed in Data Model Requirements (Section 5.1). 794 P.10 The protocol MUST support an available spectrum response from 795 the database to the master device, which may include one or more 796 of the data items listed in Data Model Requirements (Section 5.1). 798 P.11 The protocol MUST support a spectrum usage message from the 799 master device to the database, which may include one or more of 800 the data items listed in Data Model Requirements (Section 5.1). 802 P.12 The protocol MUST support a spectrum usage message 803 acknowledgement. 805 P.13 The protocol MUST support a validation request from the master 806 to the database to validate a slave device. The validation 807 request MUST include the slave device ID. 809 P.14 The protocol MUST support a validation response from the 810 database to the master to indicate if the slave device is 811 validated by the database. The validation response MUST indicate 812 the success or failure of the validation request. 814 P.15 The protocol MUST support the capability for the database to 815 inform master devices of changes to spectrum availability 816 information in a timely manner. 818 5.3. Operational Requirements 820 This section contains operational requirements of a white-space 821 database-device system, independent of the requirements of the 822 protocol for communication between the white-space database and 823 devices. 825 O.1 The database and the master device MUST be connected (e.g., 826 through the Internet). 828 O.2 A master device MUST be able to determine its location including 829 uncertainty and confidence level. A fixed master device may use a 830 location programmed at installation. 832 O.3 The master device MUST be configured to understand and comply 833 with the requirements of the rule set of the regulatory body that 834 apply to its operation at its location. 836 O.4 A master device MUST query the database for the available 837 spectrum based on its current location before starting radio 838 transmission in white space. 840 O.5 The database MUST respond to an available spectrum list request. 842 O.6 After connecting to a master device, a slave device MUST query 843 the master device for a list of available spectrum. The master 844 device then queries the database on behalf of the slave device for 845 an available spectrum list, using parameters received from the 846 slave device. After the master device receives a response to its 847 request for an available spectrum list on behalf of a slave 848 device, the master device MUST relay the response to the slave 849 device. 851 5.4. Guidelines 853 White space technology itself is expected to evolve and include 854 attributes such as co-existence and interference avoidance, spectrum 855 brokering, alternative spectrum bands, etc. The design of the data 856 model and protocol should be cognizant of the evolving nature of 857 white space technology and consider the following set of guidelines 858 in the development of the data model and protocol: 860 1. The data model SHOULD provide a modular design separating out 861 messaging specific, administrative specific, and spectrum 862 specific parts into separate modules. 864 2. The protocol SHOULD support determination of which administrative 865 specific and spectrum specific modules are used. 867 6. IANA Considerations 869 This document makes no request of IANA. 871 7. Security Considerations 873 PAWS is a protocol whereby a Master Device requests a schedule of 874 available spectrum at its location (or location of its Slave Devices) 875 before it (they) can operate using those frequencies. Whereas the 876 information provided by the Database must be accurate and conform to 877 applicable regulatory rules, the Database cannot enforce, through the 878 protocol, that a client device uses only the spectrum it provided. 879 In other words, devices can put energy in the air and cause 880 interference without asking the Database. Hence, PAWS security 881 considerations do not include protection against malicious use of the 882 white-space spectrum. 884 Threat model for the PAWS protocol: 886 Assumptions: 888 The link between the master device and the white-space database 889 can be wired or wireless and provides IP connectivity. It is 890 assumed that an attacker has full access to the network medium 891 between the master device and the white-space database. The 892 attacker may be able to eavesdrop on any communications between 893 these entities. 895 Threat 1: User modifies a device to masquerade as another valid 896 certified device 898 A master device identifies itself to the database in order to 899 obtain information about available spectrum. Without suitable 900 protection mechanisms, devices can listen to registration 901 exchanges, and later register with the database by claiming the 902 identity of another device. 904 Threat 2: Spoofed white-space database 906 A master device attempts to discovers a white-space database(s) 907 that it can query for available spectrum information. An 908 attacker may attempt to spoof a white-space database and 909 provide responses to a master device that are malicious and 910 result in the master device causing interference to the primary 911 user of the spectrum. 913 Threat 3: Modifying a query request 915 An attacker may modify the query request sent by a master 916 device to a white-space database. The attacker may change the 917 location of the device or its capabilities (transmit power, 918 antenna height etc.), and, as a result, the database responds 919 with incorrect information about available spectrum or maximum 920 transmit power allowed. The result of such an attack is that 921 the master device can cause interference to the primary user of 922 the spectrum. It may also result in a denial of service to the 923 master device if the modified database response indicates that 924 no channels are available to the master device. 926 Threat 4: Modifying a query response 928 An attacker may modify the query response sent by the white- 929 space database to a master device. For example, an attacker 930 may modify the available spectrum or power level information 931 carried in the database response. As a result, a master device 932 may use spectrum that is not available at a location or may 933 transmit at a greater power level than allowed. Such 934 unauthorized use can result in interference to the primary user 935 of that spectrum. Alternatively, an attacker may modify a 936 database response to indicate that no spectrum is available at 937 a location, resulting in a denial of service to the master 938 device. 940 Threat 5: Third party tracking of white space device location and 941 identity 943 A master device may provide its identity in addition to its 944 location in the query request. Such location/identity 945 information can be gleaned by an eavesdropper and used for 946 unauthorized tracking purposes. 948 Threat 6: Malicious individual acts as a white space database to 949 terminate or unfairly limit spectrum access of devices 951 A white-space database may include a mechanism by which service 952 and spectrum allocated to a master device can be revoked by 953 sending a revoke message to a master device. A malicious user 954 can pretend to be a white-space database and send a revoke 955 message to that device. This results in denial of service to 956 the master device. 958 The security requirements arising from the above threats are captured 959 in the requirements of Section 5.2. 961 8. Acknowledegements 963 The authors acknowledge Gabor Bajko, Teco Boot, Nancy Bravin, Rex 964 Buddenberg, Vincent Chen, Gerald Chouinard, Stephen Farrell, Michael 965 Fitch, Joel M. Halpern, Jussi Kahtava, Paul Lambert, Barry Leiba, 966 Subramanian Moonesamy, Pete Resnick, Brian Rosen, Andy Sago, Peter 967 Stanforth, John Stine, and Juan Carlos Zuniga for their contributions 968 to this document. 970 9. References 972 9.1. Normative References 974 [I-D.ietf-paws-protocol] 975 Chen, V., Das, S., Zhu, L., Malyar, J., and P. McCann, 976 "Protocol to Access Spectrum Database", 977 draft-ietf-paws-protocol-03 (work in progress), 978 February 2013. 980 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 981 Requirement Levels", BCP 14, RFC 2119, March 1997. 983 [WGS84] National Imagery and Mapping Agency, "Department of 984 Defense World Geodetic System 1984, Its Definition and 985 Relationships with Local Geodetic Systems, NIMA TR8350.2 986 Third Edition Amendment 1", January 2000, . 990 9.2. Informational References 992 URIs 994 [1] 996 Authors' Addresses 998 Anthony Mancuso (editor) 999 Google 1000 1600 Amphitheatre Parkway 1001 Mountain View, CA 94043 1002 US 1004 Phone: 1005 Fax: 1006 Email: amancuso@google.com 1007 URI: 1009 Scott Probasco 1011 Phone: 1012 Fax: 1013 Email: scott@probasco.me 1014 URI: 1016 Basavaraj Patil 1018 Phone: 1019 Fax: 1020 Email: bpatil@ovi.com 1021 URI: