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