idnits 2.17.1 draft-ietf-paws-problem-stmt-usecases-rqmts-01.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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 31, 2011) is 4554 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'PAWS-PS' is defined on line 1391, but no explicit reference was found in the text == Unused Reference: 'RFC5222' is defined on line 1431, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Working Group Draft S. Probasco, Ed. 3 Internet-Draft B. Patil 4 Intended status: Informational Nokia 5 Expires: May 3, 2012 October 31, 2011 7 Protocol to Access White Space database: PS, use cases and rqmts 8 draft-ietf-paws-problem-stmt-usecases-rqmts-01 10 Abstract 12 Portions of the radio spectrum that are allocated to a licensed, 13 primary user but are unused or unoccupied at specific locations and 14 times are defined as "white space". The concept of allowing 15 secondary transmissions (licensed or unlicensed) in white space is a 16 technique to "unlock" existing spectrum for new use. An obvious 17 requirement is that these secondary transmissions do not interfere 18 with the primary use of the spectrum. One approach to using the 19 white space spectrum at a given time and location is to verify with a 20 database available channels. 22 This document describes the concept of TV White Spaces. It also 23 describes the problems that need to be addressed for enabling the use 24 of the primary user owned white space spectrum for secondary users, 25 without causing interference, by querying a database which knows the 26 channel availability at any given location and time. A number of 27 possible use cases of this spectrum and derived requirements are also 28 described. 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 May 3, 2012. 47 Copyright Notice 48 Copyright (c) 2011 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 1.1. Introduction to TV white space . . . . . . . . . . . . . . 4 65 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 1.2.1. In Scope . . . . . . . . . . . . . . . . . . . . . . . 6 67 1.2.2. Out of Scope . . . . . . . . . . . . . . . . . . . . . 6 68 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 6 69 2.1. Conventions Used in This Document . . . . . . . . . . . . 7 70 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 71 3. Prior Work . . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 3.1. The concept of Cognitive Radio . . . . . . . . . . . . . . 8 73 3.2. Background information on white space in US . . . . . . . 8 74 3.3. Air Interfaces . . . . . . . . . . . . . . . . . . . . . . 9 75 4. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 9 76 4.1. TVWS database discovery . . . . . . . . . . . . . . . . . 9 77 4.2. Device registration with trusted Database . . . . . . . . 10 78 4.3. Hotspot: urban internet connectivity service . . . . . . . 11 79 4.4. Wide-Area or Rural internet broadband access . . . . . . . 13 80 4.5. Offloading: moving traffic to a white space network . . . 15 81 4.6. TVWS for backhaul . . . . . . . . . . . . . . . . . . . . 17 82 4.7. Rapid deployed network for emergency scenario . . . . . . 18 83 4.8. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . 19 84 4.9. Indoor Networking . . . . . . . . . . . . . . . . . . . . 21 85 4.10. Machine to Machine (M2M) . . . . . . . . . . . . . . . . . 23 86 5. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 24 87 5.1. Global applicability . . . . . . . . . . . . . . . . . . . 25 88 5.2. Database discovery . . . . . . . . . . . . . . . . . . . . 26 89 5.3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 27 90 5.4. Data model definition . . . . . . . . . . . . . . . . . . 27 91 6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 27 92 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 93 8. Security Considerations . . . . . . . . . . . . . . . . . . . 30 94 9. Summary and Conclusion . . . . . . . . . . . . . . . . . . . . 31 95 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31 96 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 97 11.1. Normative References . . . . . . . . . . . . . . . . . . . 31 98 11.2. Informative References . . . . . . . . . . . . . . . . . . 32 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 101 1. Introduction 103 1.1. Introduction to TV white space 105 Wireless spectrum is a commodity that is regulated by governments. 106 The spectrum is used for various purposes, which include 107 entertainment (e.g. radio and television), communication (telephony 108 and Internet access), military (radars etc.) and, navigation 109 (satellite communication, GPS). Portions of the radio spectrum that 110 are allocated to a licensed, primary user but are unused or 111 unoccupied at specific locations and times are defined as "white 112 space". The concept of allowing secondary transmissions (licensed or 113 unlicensed) in white space is a technique to "unlock" existing 114 spectrum for new use. An obvious requirement is that these secondary 115 transmissions do not interfere with the primary use of the spectrum. 116 One interesting observation is that often, in a given physical 117 location, the primary user(s) may not be using the entire band 118 allocated to them. The available spectrum for a secondary use would 119 then depend on the location of the secondary user. The fundamental 120 issue is how to determine for a specific location and specific time, 121 if any of the primary spectrum is available for secondary use. 122 Academia and Industry have studied multiple cognitive radio 123 mechanisms for use in such a scenario. One simple mechanism is to 124 use a geospatial database that records the primary users occupation, 125 and require the secondary users to check the database prior to 126 selecting what part of the spectrum they use. Such databases could 127 be available on the Internet for query by secondary users. 129 Spectrum useable for data communications, especially wireless 130 Internet communications, is scarce. One area which has received much 131 attention globally is the TV white space: portions of the TV band 132 that are not used by broadcasters in a given area. In 2008 the 133 United States regulator (the FCC) took initial steps when they 134 published their first ruling on the use of TV white space, and then 135 followed it up with a final ruling in 2010 [FCC Ruling]. Finland 136 passed an Act in 2009 enabling testing of cognitive radio systems in 137 the TV white space. The ECC has completed Report 159 [ECC Report 138 159] containing requirements for operation of cognitive radio systems 139 in the TV white space. Ofcom published in 2004 their Spectrum 140 Framework Review [Spectrum Framework Review] and their Digital 141 Dividend Review [DDR] in 2005, and have followed up with a proposal 142 to access TV white space. More countries are expected to provide 143 access to their TV spectrum in similar ways. Any entity holding 144 spectrum that is not densely used may be asked to give it up in one 145 way or another for more intensive use. Providing a mechanism by 146 which secondary users share the spectrum with the primary user is 147 attractive in many bands in many countries. 149 Television transmission until now has primarily been analog. The 150 switch to digital transmission has begun. As a result the spectrum 151 allocated for television transmission can now be more effectively 152 used. Unused channels and bands between channels can be used as long 153 as they do not interfere with the primary service for which that 154 channel is allocated. While urban areas tend to have dense usage of 155 spectrum and a number of TV channels, the same is not true in rural 156 and semi-urban areas. There can be a number of unused TV channels in 157 such areas that can be used for other services. The figure below 158 shows TV white space within the lower UHF band: 160 Avg | 161 usage| |-------------- White Space 162 | | | | | | 163 0.6| || || V V || 164 | || ||| | || 165 0.4| || |||| | || 166 | || |||| | ||<----TV transmission 167 0.2| || |||| | || 168 |---------------------------------------- 169 400 500 600 700 800 170 Frequency in MHz -> 172 Figure 1: High level view of TV White Space 174 The fundamental issue is how to determine for a specific location and 175 specific time if any of the spectrum is available for secondary use. 176 There are two dimensions of use that may be interesting: space (the 177 area in which a secondary user would not interfere with a primary 178 user, and time: when the secondary use would not interfere with the 179 primary use. In this discussion, we consider the time element to be 180 relatively long term (hours in a day) rather than short term 181 (fractions of a second). Location in this discussion is geolocation: 182 where the transmitters (and sometimes receivers) are located relative 183 to one another. In operation, the database records the existing 184 user's transmitter (and some times receiver) locations along with 185 basic transmission characteristics such as antenna height, and 186 sometimes power. Using rules established by the regulator, the 187 database calculates an exclusion zone for each authorized primary 188 user, and attaches a time schedule to that use. The secondary user 189 queries the database with its location. The database intersects the 190 exclusion zones with the queried location, and returns the portion of 191 the spectrum not in any exclusion zone. Such methods of geospatial 192 database query to avoid interference have been shown to achieve 193 favorable results, and are thus the basis for rulings by the FCC and 194 reports from ECC and Ofcom. In any country, the rules for which 195 primary entities are entitled to protection, how the exclusion zones 196 are calculated, and what the limits of use by secondary entities are 197 may vary. However, the fundamental notion of recording primary 198 users, calculating exclusion zones, querying by location and 199 returning available spectrum (and the schedule for that spectrum) are 200 common 202 This document includes the problem statement, use cases and 203 requirements associated with the use of white space spectrum by 204 secondary users via a database query protocol. 206 1.2. Scope 208 1.2.1. In Scope 210 This document applies only to communications required for basic 211 service in TV white space. The protocol will enable a white space 212 radio device to complete the following tasks: 214 1. Determine the relevant white space database to query. 216 2. Connect to the database using a well-defined access method. 218 3. Register with the database using a well-defined protocol. 220 4. Provide its geolocation and perhaps other data to the database 221 using a well-defined format for querying the database. 223 5. Receive in return a list of currently available white space using 224 a well-defined format for returning information. 226 As a result, some of the scenarios described in the following section 227 are out of scope for this specification (although they might be 228 addressed by future specifications). 230 1.2.2. Out of Scope 232 The following topics are out of scope for this specification: 234 TBD 236 2. Conventions and Terminology 237 2.1. Conventions Used in This Document 239 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 240 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 241 document are to be interpreted as described in RFC 2119 [RFC2119]. 243 2.2. Terminology 245 Database 247 In the context of white space and cognitive radio technologies, 248 the database is an entity which contains current information about 249 available spectrum at any given location and other types of 250 information. 252 Device ID 254 A unique number for each master device and slave device that 255 identifies the manufacturer, model number and serial number. 257 Location Based Service 259 An application or device which provides data, information or 260 service to a user based on their location. 262 Master Device 264 A device which queries the WS Database to find out the available 265 operating channels. 267 Protected Entity 269 A primary user of white space spectrum which is afforded 270 protection against interference by secondary users (white space 271 devices) for its use in a given area and time. 273 Protected Contour 275 The exclusion area for a Protected Entity, held in the database 276 and expressed as a polygon with geospatial points as the vertices. 278 Slave Device 280 A device which uses the spectrum made available by a master 281 device. 283 TV White Space 285 TV white space refers specifically to radio spectrum which has 286 been allocated for TV broadcast, but is not occupied by a TV 287 broadcast, or other licensed user (such as a wireless microphone), 288 at a specific location and time. 290 White Space 292 Radio spectrum which has been allocated for some primary use, but 293 is not fully occupied by that primary use at a specific location 294 and time. 296 White Space Device (WSD) 298 A device which is a secondary user of some part of white space 299 spectrum. A white space device can be an access point, base 300 station, a portable device or similar. In this context, a white 301 space device is required to query a database with its location to 302 obtain information about available spectrum. 304 3. Prior Work 306 3.1. The concept of Cognitive Radio 308 A cognitive radio uses knowledge of the local radio environment to 309 dynamically adapt its own configuration and function properly in a 310 changing radio environment. Knowledge of the local radio environment 311 can come from various technology mechanisms including sensing 312 (attempting to ascertain primary users by listening for them within 313 the spectrum), location determination and internet connectivity to a 314 database to learn the details of the local radio environment. TV 315 White Space is one implementation of cognitive radio. Because a 316 cognitive radio adapts itself to the available spectrum in a manner 317 that prevents the creation of harmful interference, the spectrum can 318 be shared among different radio users. 320 3.2. Background information on white space in US 322 Television transmission in the United States has moved to the use of 323 digital signals as of June 12, 2009. Since June 13, 2009, all full- 324 power U.S. television stations have broadcast over-the-air signals in 325 digital only. An important benefit of the switch to all-digital 326 broadcasting is that it freed up parts of the valuable broadcast 327 spectrum. More information about the switch to digital transmission 328 is at : [DTV]. 330 With the switch to digital transmission for TV, the guard bands that 331 existed to protect the signals between stations can now be used for 332 other purposes. The FCC has made this spectrum available for 333 unlicensed use and this is generally referred to as white space. 334 Please see the details of the FCC ruling and regulations in [FCC 335 Ruling]. The spectrum can be used to provide wireless broadband as 336 an example. The term "Super-Wifi" is also used to describe this 337 spectrum and potential for providing wifi type of service. 339 3.3. Air Interfaces 341 Efforts are ongoing to specify air-interfaces for use in white space 342 spectrum. IEEEs 802.11af task group is currently working on one such 343 specification. IEEE 802.22 is another example. Other air interfaces 344 could be specified in the future such as LTE. 346 4. Use cases 348 There are many potential use cases that could be considered for the 349 TV white space spectrum. Providing broadband internet access in 350 hotspots, rural and underserved areas are examples. Available 351 channels may also be used to provide internet 'backhaul' for 352 traditional Wi-Fi hotspots, or by towns and cities to monitor/control 353 traffic lights or read utility meters. Still other use cases include 354 the ability to offload data traffic from another internet access 355 network (e.g. 3G cellular network) or to deliver location based 356 services. Some of these use cases are described in the following 357 sections. 359 4.1. TVWS database discovery 361 This use case is preliminary to creating a radio network using TV 362 white space; it is a prerequisite to other use cases. The radio 363 network is created by a master device. Before the master device can 364 transmit in TV white space spectrum, it must contact a trusted 365 database where the device can learn if any channels are available for 366 it to use. The master device will need to discover a trusted 367 database in the relvant regulatory domain, using the following steps: 369 1. The master device is connected to the internet by any means other 370 than using the TV white space radio. 372 2. The master device constructs and sends a service request over the 373 Internet to discover availability of trusted databases in the 374 local domain and waits for responses. 376 3. If no acceptable response is received within a pre-configured 377 time limit, the master device concludes that no trusted database 378 is available. If at least one response is received, the master 379 device evaluates the response(s) to determine if a trusted 380 database can be identified where the master device is able to 381 register and receive service from the database. 383 Optionally the radio device is pre-programmed with the internet 384 address of at least one trusted database. The device can establish 385 contact with a trusted database using one of the pre-programmed 386 internet addresses and establish a TV white space network (as 387 described in one of the following use cases). 389 Optionally the initial query will be made to a listing approved by 390 the national regulator for the domain of operation (e.g. a website 391 either hosted by or under control of the national regulator) which 392 maintains a list of TVWS databases and their internet addresses. The 393 query results in the list of databases and their internet addresses 394 being sent to the master, which then evaluates the repsonse to 395 determine if a trusted database can be identified where the master 396 device is able to register and receive service from the database. 398 4.2. Device registration with trusted Database 400 This use case is preliminary to creating a radio network using TV 401 white space; it is a prerequisite to other use cases. The radio 402 network is created by a master device. Before the master device can 403 transmit in TV white space spectrum, it must contact a trusted 404 database where the device can learn if any channels are available for 405 it to use. Before the database will provide information on available 406 TV channels, the master device must register with the trusted 407 database. Specific requirements for registration come from 408 individual regulatory domains and may be different. 410 The figure below shows an example deployment of this scenario. 412 \|/ ---------- 413 | |Database| 414 | .---. /--------- 415 |-|---------| ( ) / 416 \|/ | Master | / \ 417 | / | |========( Internet ) 418 | / |-----------| \ / 419 +-|----+ (TDD AirIF) ( ) 420 |Master| / (----) 421 | | / 422 +------+ 424 Figure 2: Example illustration of registration requirement in TV 425 white space use-case 427 A simplified operational scenario showing registration consists of 428 the following steps: 430 1. The master device must register with the most current and up-to- 431 date information. Typically the master device will register 432 prior to operating in TV white space for the first time after 433 power up, after changing location by a predetermined distance, 434 and after regular time intervals. 436 2. The master device shall provide to the database during 437 registration a minimum of the Device ID, serial number assigned 438 by the manufacturer and the device's location. 440 3. Depending upon regulatory domain requirements, the device may 441 also provide device antenna height above ground, name of the 442 individual or business that owns the device, name of a contact 443 person responsible for the device's operation, address for the 444 contact person, email address for the contact person and phone 445 number of the contact person to the database during registration. 447 4.3. Hotspot: urban internet connectivity service 449 In this use case internet connectivity service is provided in a 450 "hotspot" to local users. Typical deployment scenarios include urban 451 areas where internet connectivity is provided to local businesses and 452 residents, and campus environments where internet connectivity is 453 provided to local buildings and relatively small outdoor areas. This 454 deployment scenario is typically characterized by multiple masters 455 (APs or hotspots) in close proximity, with low antenna height, cells 456 with relatively small radius (a few kilometers or less), and limited 457 numbers of available radio channels. Many of the masters/APs are 458 assumed to be individually deployed and operated, i.e. there is no 459 coordination between many of the masters/APs. The masters/APs in 460 this scenario use a TDD radio technology and transmit at or below a 461 relatively low transmit power threshold. Each master/AP has a 462 connection to the internet and provides internet connectivity to 463 multiple master and or slave devices. 465 The figure below shows an example deployment of this scenario. 467 -------- 468 |Device|\ \|/ ---------- 469 | 1 | (TDD AirIF) | |Database| 470 -------- \ | .---. /--------- 471 o \ |-|---------| ( ) / 472 o | Master | / \ 473 o / | |========( Internet ) 474 o / |-----------| \ / 475 -------- (TDD AirIF) ( ) 476 |Device| / (----) 477 | n | 478 -------- 480 Figure 3: Hotspot service using TV white space spectrum 482 Once a master/AP has been correctly installed and configured, a 483 simplified power up and operation scenario utilizing TV White Space 484 to provide Internet connectivity service consists of the following 485 steps: 487 1. The master/AP powers up; however its WS radio and all other WS 488 capable devices will power up in idle/listen only mode (no active 489 transmissions on the WS frequency band). 491 2. The master/AP has Internet connectivity and establishes a 492 connection to a trusted white space database (see Section 4.1). 494 3. The master/AP registers with the trusted database according to 495 regulatory domain requirements (see Section 4.2). 497 4. Following the registration process, the master/AP will send a 498 query to the trusted database requesting a list of available WS 499 channels based upon its geolocation. 501 5. If the master/AP has met all regulatory domain requirements (e.g. 502 been previously authenticated, etc), the database responds with a 503 list of available white space channels that the master may use, 504 and optionally a duration of time for their use. 506 6. Once the master/AP has met all regulatory domain requirements 507 (e.g. authenticated the WS channel list response message from the 508 database, etc), the AP selects an available WS channel(s) from 509 the list. 511 7. The slave or user device scans the TV bands to locate a master/AP 512 transmission, and associates with the AP. The slave/user device 513 queries the master for a channel list, providing to the master 514 the slaves' Device ID and geolocation. 516 8. Once the master/AP has met all regulatory domain requirements 517 (e.g. validating the Device ID with the trusted database, etc) 518 the master provides the list of channels locally available to the 519 slave/user device. If the channel that the user terminal is 520 currently using is not included in the list of locally available 521 channels, the slave/user device ceases all operation on its 522 current channel. The slave/user device may scan for another AP 523 transmission on a different channel. 525 4.4. Wide-Area or Rural internet broadband access 527 In this use case, internet broadband access is provided as a Wide- 528 Area Network (WAN) or Wireless Regional Area Network (WRAN). A 529 typical deployment scenario is a wide area or rural area, where 530 internet broadband access is provided to local businesses and 531 residents from a master (i.e. BS) connected to the internet. This 532 deployment scenario is typically characterized by one or more fixed 533 master(s)/BS(s), cells with relatively large radius (tens of 534 kilometers, up to 100 km), and a number of available radio channels. 535 Some of the masters/BSs may be deployed and operated by a single 536 entity, i.e. there can be centralized coordination between these 537 masters/BSs, whereas other masters/BSs may be deployed and operated 538 by operators competing for the radio channels in a license-exempt 539 TVWS environment where decentralized coordination using the air- 540 interface would be required. The BS in this scenario use a TDD radio 541 technology and transmit at or below a transmit power limit 542 established by the local regulator. Each base station has a 543 connection to the internet and provides internet connectivity to 544 multiple slave/end-user devices. End user terminals or devices may 545 be fixed or portable. 547 The figure below shows an example deployment of this scenario. 549 ------- 550 |Slave|\ \|/ ---------- 551 |Dev 1| (TDD AirIF) | |Database| 552 ------- \ | .---. /---------- 553 o \ |-|---------| ( ) / 554 o | Master | / \ 555 o / | (BS) |========( Internet ) 556 o / |-----------| \ / 557 ------- (TDD AirIF) ( ) 558 |Slave| / (----) 559 |Dev n| 560 ------- 562 Figure 4: Rural internet broadband access using TV white space 563 spectrum 565 Once the master/BS has been professionally installed and configured, 566 a simplified power up and operation scenario utilizing TV White Space 567 to provide rural internet broadband access consists of the following 568 steps: 570 1. The master/BS powers up; however its WS radio and all other WS 571 capable devices will power up in idle/listen only mode (No active 572 transmissions on the WS frequency band) 574 2. The master/BS has internet connectivity and establishes a 575 connection to a trusted white space database (see use case "TVWS 576 database discovery" above). 578 3. The master/BS registers its geolocation, address, contact 579 information, etc. associated with the owner/operator of the 580 master/BS with the trusted database service (if not currently 581 registered, see Section 4.2). Meanwhile the DB administrator may 582 be required to store and forward the registration information to 583 the regulatory authority. If a trusted white space database 584 administrator is not discovered, further operation of the WRAN 585 may be allowed according to local regulator policy (in this case 586 operation of the WRAN is outside the scope of the PAWS protocol). 588 4. Following the registration process, the master/BS will send a 589 query to the trusted database requesting a list of available WS 590 channels based upon its geolocation. 592 5. If the master/BS has been previously authenticated, the database 593 responds with a list of available white space channels that may 594 be used and optionally a maximum transmit power (EIRP) for each 595 channel and a duration of time the channel may be used. 597 6. Once the master/BS authenticates the WS channel list response 598 message from the database, the master/BS selects an available WS 599 channel(s) from the list. The operator may disallow some 600 channels from the list to suit local needs if required. 602 7. The slave or user device scans the TV bands to locate a WRAN 603 transmission, and associates with the master/BS. The slave/user 604 device provides its geolocation to the BS which, in turn, queries 605 the database for a list of channels available at the slaves' 606 geolocation. 608 8. Once this list of available channels is received from the 609 database by the master, the latter will decide, based on the list 610 of available channels for all its other associated slaves whether 611 it should continue operation on its current channel or change 612 channel to accommodate the new slave in case this channel is not 613 available at its location. The master will notify all its 614 associated slaves/user devices of the new channel to move to if 615 operation needs to change channel. If the channel that the user 616 terminal is currently using is not included in the list of 617 locally available channels, the master will drop its association 618 with the slave/user device so that it ceases all operation on its 619 current channel and indicate the new operating channel before 620 dropping the link if a change has been decided. The slave/user 621 device may move to the indicated new channel if so indicated or 622 scan for another WRAN transmission on a different channel. 624 4.5. Offloading: moving traffic to a white space network 626 In this use case internet connectivity service is provided over TV 627 white space as a supplemental or alternative datapath to a 3G or 628 other internet connection. In a typical deployment scenario an end 629 user has a primary internet connection such as a 3G cellular packet 630 data subscription. The user wants to use a widget or application to 631 stream video from an online service (e.g. youtube) to their device. 632 Before the widget starts the streaming connection it checks 633 connectivity options available at the current time and location. 634 Both 3G cellular data is available as well as TVWS connectivity (the 635 user is within coverage of a TVWS master -- hotspot, WAN, WRAN or 636 similar). The user may decide for many and various reasons such as 637 cost, RF coverage, data caps, etc. to prefer the TVWS connection over 638 the 3G cellular data connection. Either by user selection, 639 preconfigured preferences, or other algorithm, the streaming session 640 is started over the TVWS internet connection instead of the 3G 641 cellular connection. This deployment scenario is typically 642 characterized by a TVWS master/AP providing local coverage in the 643 same geographical area as a 3G cellular system. The master/AP is 644 assumed to be individually deployed and operated, i.e. the master/AP 645 is deployed and operated by the user at his home or perhaps by a 646 small business such as a coffee shop. The master/AP has a connection 647 to the internet and provides internet connectivity to the slave/ 648 end-user's device. 650 The figure below shows an example deployment of this scenario. 652 \|/ 653 | 654 | 655 |-|---------| 656 | Master/AP |\ 657 /| Router | \ 658 Streaming/ |-----------| \ 659 -------- / \ ----------- 660 |Slave/| / \ (----) | Database | 661 |WS Dev| \ ( ) /---------- 662 ------- \ \ / \ 663 \ X( Internet ) 664 \ / \ / 665 Signaling \|/ / ( )\ 666 \ | / (----) \---------- 667 \ | / | YouTube | 668 \|-|---------| / ---------- 669 | | / 670 | 3G BTS |/ 671 |-----------| 673 Figure 5: Offloading: moving traffic to a white space network 675 Once a dual or multi mode device (3G + TVWS) is connected to a 3G 676 network, a simplified operation scenario of offloading selected 677 content such as video stream from the 3G connection to the TWVS 678 connection consists of the following steps: 680 1. The dual mode (or multi mode) device (3G + TVWS) is connected to 681 a 3G network. The device has contacted a trusted database to 682 discover the list of available TV channels at its current 683 location. The device has located a TVWS master/AP operating on 684 an available channel and has associated or connected with the 685 TVWS master/AP. 687 2. The user activates a widget or application that streams video 688 from YouTube. The widget connects to YouTube over 3G cellular 689 data. The user browses content and searches for video 690 selections. 692 3. The user selects a video for streaming using the widget's 693 controls. Before the widget initiates a streaming session, the 694 widget checks the available connections in the dual mode device 695 and finds a TVWS master/AP is connected. 697 4. Using either input from the user or pre-defined profile 698 preferences, the widget selects the TVWS master/AP as the 699 connection to stream the video. 701 4.6. TVWS for backhaul 703 In this use case internet connectivity service is provided to users 704 over a traditional wireless protocol, one common example is Wi-Fi. 705 The TV white space network provides the "backhaul" or connection from 706 the Wi-Fi to the internet. In a typical deployment scenario an end 707 user has a device with a radio such as Wi-Fi. A service provider or 708 shop owner wants to provide Wi-Fi internet service for their 709 customers. The location where the service provider wants to provide 710 Wi-Fi is within range of a TVWS master (e.g. Hotspot or Wide-Area/ 711 Rural network). The service provider installs a TVWS slave device 712 and connects this slave to a Wi-Fi access point. This deployment 713 scenario is typically characterized by a TVWS master/AP/BS providing 714 local coverage. The master/AP has a connection to the internet and 715 provides internet connectivity to the slave device. The slave device 716 is then 'bridged' to a Wi-Fi network 718 The figure below shows an example deployment of this scenario. 720 \|/ white \|/ \|/ WiFi \|/ 721 | space | | | 722 | | | |-|----| 723 |--------| |-|---------| |-|------|-| | WiFi | 724 | | | Master | | Slave | | Dev | 725 |internet|------| (AP/BS) | | Bridge | |------| 726 | | | | | to WiFi | 727 |--------| |-----------| |----------| \|/ 728 | 729 |-|----| 730 | WiFi | 731 | Dev | 732 |------| 734 Figure 6: TVWS for backhaul 736 Once the bridged device (TVWS+WiFi) is connected to a master and TVWS 737 network, a simplified operation scenario of backhaul for WiFi 738 consists of the following steps: 740 1. A bridged device (TVWS+WiFi) is connected to a master device 741 operating in the TVWS. The bridged device operates as a slave 742 device in either Hotspot or Wide-Area/Rural internet use cases 743 described above. 745 2. Once the slave device is connected to the master, the Wi-Fi 746 access point configures its internet settings automatically based 747 on the backhaul connection (i.e. it uses DHCP). 749 3. End users connect their WiFi device to the bridged device and 750 receive internet connectivity. 752 4.7. Rapid deployed network for emergency scenario 754 Organizations involved in handling emergency operations often have a 755 fully owned and controlled infrastructure, with dedicated spectrum, 756 for day to day operation. However, lessons learned from recent 757 disasters show such infrastructures are often highly affected by the 758 disaster itself. To set up a replacement quickly, there is a need 759 for fast reallocation of spectrum, where in certain cases spectrum 760 can be freed for disaster relief. To utilize free or freed spectrum 761 quickly and reliable, automation of allocation, assignment and 762 configuration is needed. A preferred option is make use of a robust 763 protocol, already adopted by radio manufacturers. This approach does 764 in no way imply such organizations for disaster relief must compete 765 on spectrum allocation with other white spaces users, but they can. 766 A typical network topology would include wireless access links to the 767 public Internet or private network, wireless ad hoc network radios 768 working independent of a fixed infrastructure and satellite links for 769 backup where lack of coverage, overload or outage of wireless access 770 links occur. 772 The figure below shows an example deployment of this scenario. 774 \|/ 775 | ad hoc 776 | 777 |-|-------------| 778 | Master node | |------------| 779 \|/ | with | | Whitespace | 780 | ad hoc /| backhaul link | | Database | 781 | /------/ |---------------| |------------| 782 ---|------------/ | \ / 783 | Master node | | | (--/--) 784 | without | | ------( ) 785 | backhaul link | | Wireless / Private \ 786 ----------------\ | Access ( net or ) 787 \ | \ Internet ) 788 \ \|/ | -------( /\ 789 \ | ad hoc | | (------) \--------- 790 \ | | / | Other | 791 \--|------------- /Satellite | nodes | 792 | Master node | / Link ---------- 793 | with |/ 794 | backhaul link | 795 ----------------- 797 Figure 7: Rapid deployed network with partly connected nodes 799 In the ad hoc network, all nodes are master nodes in a way that they 800 allocate RF channels from the white space database. However, the 801 backhaul link may not be available to all nodes, such as depicted for 802 the left node in the figure. To handle RF channel allocation for 803 such nodes, a master node with a backhaul link relays or proxies the 804 database query for them. So master nodes without a backhaul link 805 follow the procedure as defined for clients. The ad hoc network 806 radios utilise the provided RF channels. Details on forming and 807 maintenance of the ad hoc network, including repair of segmented 808 networks caused by segments operating on different RF channels, is 809 out of scope of spectrum allocation. 811 4.8. Mobility 813 In this use case, the user has a non-fixed (portable or mobile) 814 device and is riding in a vehicle. The user wants to have 815 connectivity to another device which is also moving. Typical 816 deployment scenarios include urban areas and rural areas where the 817 user may connect to other users in peer-to-peer or ad-hoc networks. 818 This deployment scenario is typically characterized by a master 819 device with low antenna height, internet connectivity by some 820 connection that does not utilize TV white space, and some means to 821 predict its path of mobility. This knowledge of mobility could be 822 simple (GPS plus accelerometer), sophisticated (GPS plus routing and 823 mapping function) or completely specified by the user via user- 824 interface. 826 The figure below shows an example deployment of this scenario. 828 \|/ \|/ 829 | TDD Air Interface | 830 | | 831 +-|---------+ +-|---------+ 832 | TVWS | | TVWS | 833 |Master Dev | |Master Dev | 834 +-----------+ +-----------+ 835 \ (----) / 836 \ ( ) / 837 \ / \ / 838 ( Internet ) 839 \ / 840 ( )\----------+ 841 (----) | Database | 842 +----------+ 844 Figure 8: Example illustration of mobility in TV white space use-case 846 A simplified operational scenario utilizing TV whitespace to provide 847 peer-to-peer connectivity service in a mobility environment consists 848 of the following steps: 850 1. The mobile master device powers up with its WS radio in idle or 851 listen mode only (no active transmission on the WS frequency 852 band). 854 2. The mobile master has internet connectivity and establishes a 855 connection to a trusted white space database (see Section 4.1). 857 3. The mobile master registers with the trusted database according 858 to regulatory domain requirements (see Section 4.2). 860 4. Following the registration process, the mobile master will send a 861 query to the trusted database requesting a list of available WS 862 channels based upon its current location and a prediction of its 863 future location, extrapolated from the motion or mobility of the 864 device. The current location is specified in latitude and 865 longitude. The method to specify the future location is TBD, 866 potential methods include movement vector (direction and 867 velocity), a set of latitude/longitude points which specify a 868 closed polygon where the future location is within the polygon, 869 or similar. 871 5. If the mobile master has met all regulatory domain requirements 872 (e.g. been previously authenticated, etc), the database responds 873 with a list of available white space channels that the mobile 874 master may use, and optional information which may include (1) a 875 duration of time for the use of each channel (2) a maximum 876 transmit power for each channel. 878 6. Once the mobile master has met all regulatory domain requirements 879 (e.g. authenticated the WS channel list response message from the 880 database, etc), the master selects an available WS channel(s) 881 from the list for use. 883 7. The other user device in the peer-to-peer connection scans the TV 884 bands to locate a mobile master transmission, and associates with 885 the mobile master. The slave/user device queries the master for 886 a channel list, based on the slave's device identification, 887 geolocation and optionally a prediction of its future location. 889 8. If required by local regulation, the master device verifies the 890 slave's device identification with the database. 892 9. If allowed by local regulation (e.g. the slave's device 893 identification is verified by the database), the mobile master 894 provides the list of channels locally available to the slave/user 895 device. If the channel that the slave/user terminal is currently 896 using is not included in the list of locally available channels, 897 the slave/user device ceases all operation on its current 898 channel. The slave/user device may scan for another Master's 899 transmission on a different channel. 901 4.9. Indoor Networking 903 In this use case, the users are inside a house or office. The users 904 want to have connectivity to the internet or to equipment in the same 905 or other houses / offices. This deployment scenario is typically 906 characterized by master devices within buildings, that are connected 907 to the Internet using a method that does not utilise TV whitespace. 908 The master devices can establish TV whitespace links between 909 themselves, or between themselves and one or more user devices. 911 The figure below shows an example deployment of this scenario. 913 \|/ 914 | 915 +-------+ | 916 |TVWS |\ +-|---------+ 917 |Usr Dev| WS AirIF \ | TVWS |\ 918 +-------+ X|Master Dev | \ 919 / +-----------+ \ 920 +-------+ WS AirIF | \ +----------+ 921 |TVWS |/ | \ (----) | Database | 922 |Usr Dev| | \ ( ) /----------+ 923 +-------+ WS AirIF \ / \ 924 | X( Internet ) 925 | / \ / 926 +-------+ \|/ | / ( ) 927 |TVWS |\ | | / (----) 928 |Usr Dev| WS AirIF | | / 929 +-------+ \ +-|---------+ / 930 \ | TVWS | / 931 |Master Dev |/ 932 +-----------+ 934 Figure 9: Example illustration of indoor TV white space use-case 936 A simplified operational scenario utilizing TV whitespace to provide 937 indoor networking consists of the following steps: 939 1. The master device powers up with its whitespace radio in idle or 940 listen mode only (no active transmission on the whitespace 941 frequency band). 943 2. The master device has internet connectivity and establishes a 944 connection to a trusted white space database (see Section 3.1 945 above). 947 3. The master device sends its geolocation and location uncertainty 948 information, and optionally additional information which may 949 include (1) device ID and (2) antenna characteristics, to a 950 trusted database, requesting a list of available whitespace 951 channels based upon this information. 953 4. The database responds with a list of available white space 954 channels that the master device may use, and optional information 955 which may include inter alia (1) a duration of time for the use 956 of each channel (channel validity time) (2) a maximum radiated 957 power for each channel, (3) an indication of the quality of the 958 spectrum for each channel and (4) directivity and other antenna 959 information. 961 5. Once the master device authenticates the whitespace channel list 962 response message from the database, the master device selects one 963 or more available whitespace channels from the list. 965 6. The user device(s) scan(s) the TV white space bands to locate the 966 master device transmissions, and associates with the master. 968 4.10. Machine to Machine (M2M) 970 In this use case, each "machine" includes a white space slave device 971 and can be located anywhere, fixed or on the move. Each machine 972 needs to have connectivity to the internet and or to other machines 973 in the vicinity. Machine communication over a TVWS channel, whether 974 to a master device or to another machine (slave device), is under the 975 control of a master device. This deployment scenario is typically 976 characterized by a master device with internet connectivity by some 977 connection that does not utilize TV white space. 979 The figure below shows an example deployment of this scenario. 981 \|/ 982 | 983 | 984 +-|---------+ 985 | TVWS |\ 986 /|Master Dev | \ 987 / +-----------+ \ 988 WS AirIF \ +----------+ 989 +-------+ / \ (----) | Database | 990 |Machine| \ ( ) /----------+ 991 +-------+ \ / \ 992 | X( Internet ) 993 WS AirIF \ / 994 | ( ) 995 +-------+ (----) 996 |Machine| 997 +-------+ \ +-------+ 998 WS AirIF-- |Machine| 999 +-------+ 1001 Figure 10: Example illustration of M2M TV white space use-case 1003 A simplified operational scenario utilizing TV whitespace to provide 1004 machine to machine connectivity consists of the following steps: 1006 1. The master device powers up with its whitespace radio in idle or 1007 listen mode only (no active transmission on the whitespace 1008 frequency band). 1010 2. The master device has internet connectivity and establishes a 1011 connection to a trusted white space database (see Section 3.1 1012 above). 1014 3. The master device sends its geolocation and location uncertainty 1015 information, and optionally additional information which may 1016 include (1) device ID and (2) antenna characteristics, to a 1017 trusted database, requesting a list of available whitespace 1018 channels based upon this information. 1020 4. The database responds with a list of available white space 1021 channels that the master device may use, and optional information 1022 which may include inter alia (1) a duration of time for the use 1023 of each channel (channel validity time) (2) a maximum radiated 1024 power for each channel, (3) an indication of the quality of the 1025 spectrum for each channel and (4) directivity and other antenna 1026 information. 1028 5. Once the master device authenticates the whitespace channel list 1029 response message from the database, the master device selects one 1030 or more available whitespace channels from the list. 1032 6. The slave devices fitted to the machines scan the TV bands to 1033 locate the master transmissions, and associate with the master 1034 device. Further signaling can take place outside scope of PAWS 1035 to establish direct links among those slave devices that have 1036 associated with the master device. 1038 5. Problem Statement 1040 The use of white space spectrum is enabled via the capability of a 1041 device to query a database and obtain information about the 1042 availability of spectrum for use at a given location. The databases 1043 are reachable via the Internet and the devices querying these 1044 databases are expected to have some form of Internet connectivity, 1045 directly or indirectly. The databases may be country specific since 1046 the available spectrum and regulations may vary, but the fundamental 1047 operation of the protocol should be country independent. 1049 An example high-level architecture of the devices and white space 1050 databases is shown in the figure below: 1052 ----------- 1053 |WS Device| ------------ 1054 |Lat: X |\ .---. /--------|Database X| 1055 |Long: Y | \ ( ) / ------------ 1056 ----------- \-------/ \/ o 1057 ( Internet ) o 1058 ----------- /------( )\ o 1059 |WS Device| / (_____) \ ------------ 1060 |Lat: X |/ \--------|Database Y| 1061 |Long: Y | ------------ 1062 ----------- 1064 Figure 11: High level view of the White space database architecture 1066 In the figure above, note that there could be multiple databases 1067 serving white space devices. The databases are country specific 1068 since the regulations and available spectrum may vary. In some 1069 countries, for example, the U.S., the regulator has determined that 1070 multiple, competing databases may provide service to White Space 1071 Devices. 1073 A messaging interface between the white space devices and the 1074 database is required for operating a network using the white space 1075 spectrum. The following sections discuss various aspects of such an 1076 interface and the need for a standard. Other aspects of a solution 1077 including provisioning the database, and calculating protected 1078 contours are considered out of scope of the initial effort, as there 1079 are significant differences between countries and spectrum bands. 1081 5.1. Global applicability 1083 The use of TV white space spectrum is currently approved by the FCC 1084 in the United States. However regulatory bodies in other countries 1085 are also considering similar use of available spectrum. The 1086 principles of cognitive radio usage for such spectrum is generally 1087 the same. Some of the regulatory details may vary on a country 1088 specific basis. However the need for devices that intend to use the 1089 spectrum to communicate with a database remains a common feature. 1090 The database provides a known, specifiable Protection Contour for the 1091 primary user, not dependent on the characteristics of the White Space 1092 Device or it's ability to sense the primary use. It also provides a 1093 way to specify a schedule of use, because some primary users (for 1094 example, wireless microphones) only operate in limited time slots. 1096 Devices need to be able to query a database, directly or indirectly 1097 over the public Internet and/or private IP networks prior to 1098 operating in available spectrum. Information about available 1099 spectrum, schedule, power, etc. are provided by the database as a 1100 response to the query from a device. The messaging interface needs 1101 to be: 1103 1. Radio/air interface agnostic - The radio/air interface technology 1104 used by the white space device in available spectrum can be 1105 802.11af, 802.16, 802.22, LTE etc. However the messaging 1106 interface between the white space device and the database should 1107 be agnostic to the air interface while being cognizant of the 1108 characteristics of various air-interface technologies and the 1109 need to include relevant attributes in the query to the database. 1111 2. Spectrum agnostic - the spectrum used by primary and secondary 1112 users varies by country. Some spectrum has an explicit notion of 1113 a "channel" a defined swath of spectrum within a band that has 1114 some assigned identifier. Other spectrum bands may be subject to 1115 white space sharing, but only have actual frequency low/high 1116 parameters to define protected entity use. The protocol should 1117 be able to be used in any spectrum band where white space sharing 1118 is permitted. 1120 3. Globally applicable - A common messaging interface between white 1121 space devices and databases will enable the use of such spectrum 1122 for various purposes on a global basis. Devices can operate in 1123 any country where such spectrum is available and a common 1124 interface ensures uniformity in implementations and deployment. 1125 Since the White Space device must know it's geospatial location 1126 to do a query, it is possible to determine which database, and 1127 which rules, are applicable, even though they are country 1128 specific. 1130 4. Address regulatory requirements - Each country will likely have 1131 regulations that are unique to that country. The messaging 1132 interface needs to be flexible to accommodate the specific needs 1133 of a regulatory body in the country where the white space device 1134 is operating and connecting to the relevant database. 1136 5.2. Database discovery 1138 Another aspect of the problem space is the need to discover the 1139 database. A white space device needs to find the relevant database 1140 to query based on its current location or for another location. 1141 Since the spectrum and databases are country specific, the device 1142 will need to discover the relevant database. The device needs to 1143 obtain the IP address of the specific database to which it can send 1144 queries in addition to registering itself for operation and using the 1145 available spectrum. 1147 5.3. Protocol 1149 A protocol that enables a white space device to query a database to 1150 obtain information about available channels is needed. A device may 1151 be required to register with the database with some credentials prior 1152 to being allowed to query. The requirements for such a protocol are 1153 specified in this document. 1155 5.4. Data model definition 1157 The contents of the queries and response need to be specified. A 1158 data model is required which enables the white space device to query 1159 the database while including all the relevant information such as 1160 geolocation, radio technology, power characteristics, etc. which may 1161 be country and spectrum and regulatory dependent. All databases are 1162 able to interpret the data model and respond to the queries using the 1163 same data model that is understood by all devices. 1165 Use of XML for specifying a data model is an attractive option. The 1166 intent is to evaluate the best option that meets the need for use 1167 between white space devices and databases. 1169 6. Requirements 1171 This section is the placeholder for the requirements derived from the 1172 use cases. 1174 D. Data Model Requirements: 1176 D.1: The Data Model MUST support specifying the antenna height 1177 parameter of the subject. 1179 D.2: The Data Model MUST support specifying an ID of the subject. 1180 This ID would be the ID of the device used to be certified 1181 by a regulatory body for a regulatory domain. 1183 D.3: The Data Model MUST support specifying the location of the 1184 subject and the uncertainty by which the location was 1185 determined, when confidence level is considered 95%. 1187 D.4: The Data Model MUST support specifying the location of the 1188 subject and accuracy of location determination. 1190 D.5: The Data Model MUST support specifying a list of available 1191 channel list and time constrains for the channel list 1192 availability. 1194 D.6: The Data Model MUST support specifying the maximum output 1195 power of the subject. 1197 D.7: The Data Model MUST support specifying channel availability 1198 information for multiple locations. 1200 D.8: The Data Model MUST support specifying channel availability 1201 information for an area around a specified location. 1203 D.9: The Data Model MUST support specifying multiple spectrum 1204 masks, each containing (1) the lowest applicable frequency 1205 in MHz, (2) the highest possible frequency in MHz, (3) the 1206 maximum total EIRP over the frequency range defined by the 1207 spectrum mask, (4) the general spectrum mask in dBr from 1208 peak transmit power in EIRP, with specific power limit at 1209 any frequency linearly interpolated between adjacent points 1210 of the spectrum mask expressed as in [80211P] or 1211 [FCC47CFR90.210], and (5) measurement resolution bandwidth 1212 for EIRP measurements. 1214 P. Protocol Requirements: 1216 P.1: The protocol MUST provide a mechanism for the subject to 1217 discover the WS Database it has to use at a given location. 1219 P.2: The protocol MUST support regulatory domain discovery. 1221 P.3: The protocol between the master device and the WS Database 1222 MUST support pushing updates in channel availability 1223 changes to subjects. 1225 P.4: The protocol between the master device and the WS Database 1226 MUST support mutual authentication and authorization. 1228 P.5: The protocol between the master device and the WS Database 1229 MUST support integrity and confidentiality protection. 1231 P.6: The protocol MUST support both username/password and 1232 digital certificates based authentication. 1234 P.7: A master device MAY register with a trusted white space 1235 database. 1237 P.8: A master device MUST place its location into the query it 1238 makes to the whitespace database. 1240 P.9: A master device MUST be able to query the whitespace 1241 database for channel availability information for a 1242 specific expected coverage area around its current 1243 location. 1245 P.10: A master device MUST send Device ID, searial number and 1246 device location in the query it makes to the database. 1248 P.11: A master device MAY send additional information in the 1249 query it makes to the database such as antenna height above 1250 ground level or antenna characteristics. 1252 P.12: A master device MUST be capable of validating the digital 1253 certificate of the WS Database. 1255 P.13: A master device MUST be capable of checking the validity of 1256 the WS Database certificate and whether it has been revoked 1257 or not. 1259 O. Operational Requirements: 1261 O.1: A master device MUST query the WS Database for the 1262 available channels as often as required by the regulation 1263 (eg, FCC requires once per day) to verify that the 1264 operating channels continue to remain available. 1266 O.2: A master device MUST determine its location with the 1267 accuracy required by the regulation (eg, FCC requires +/- 1268 100m) before placing a query to the DB. 1270 O.3: A master device which changes its location during its 1271 operation, MUST query the WS Database for available 1272 operating channels each time it moves more than the 1273 distance specified by the regulation (eg FCC specifies 1274 100m) from the location it previously made the query from. 1276 O.4: The WS Database MUST provide the available channel list 1277 when requested from an authenticated and authorized device 1278 and MAY also provide time constraints for the channel list, 1279 maximum output power and start and stop frequencies for 1280 each channel to the master device. 1282 O.5: A master device MUST query the WS Database and include the 1283 FCC ID of the slave device in the query before allowing the 1284 slave device to use the available channel. 1286 O.6: A master device MUST be capable to validate the digital 1287 certificate of the WS Database. 1289 O.7: A master device MUST be capable to check the validity of 1290 the WS Database certificate and whether it has been revoked 1291 or not. 1293 O.8: A master device MUST be able to determine its location 1294 using latitude-longitude coordinates. 1296 O.9: A master device MUST make a fresh query of the whitespace 1297 database for the available channels within a particular 1298 time interval, using a parameter sent by the database in 1299 response to the previous query. On expiry of the time 1300 interval then a master device MUST cease transmission in 1301 the TVWS band if no successful query attempt has been made 1302 or a query has been made but the database has not 1303 responded. 1305 O.10: If slave devices change their location during operation, 1306 the master device MUST query the whitespace database for 1307 available operating channels each time a slave device moves 1308 outside the reported coverage location area. 1310 O.11: A master device MAY be able to indicate to slave devices 1311 the start and stop frequencies it has available for 1312 operation and the maximum permitted powers for the slave 1313 devices, and MAY be able to send additional optional 1314 information. 1316 7. IANA Considerations 1318 This document has no requests to IANA. 1320 8. Security Considerations 1322 The messaging interface between the white space device and the 1323 database needs to be secured. Both the queries and the responses 1324 need to be delivered securely. The device must be certain it is 1325 talking to a bona fide database authoritative for the location and 1326 spectrum band the device operates on. The database may need to 1327 restrict interactions to devices that it has some prior relationship 1328 with, or may be restricted from providing service to devices that are 1329 not authorized in some manner. 1331 As the device will query with it's location, the location must be 1332 protected against eavesdropping. Some regulations include personally 1333 identifiable information as required elements of registration and/or 1334 query and must similarly be protected. 1336 All communications between the device and the database will require 1337 integrity protection. 1339 Man-in-the-middle attacks could modify the content of a response 1340 which can cause problems for other networks or devices operating at a 1341 given location. Interference as well as total loss of service could 1342 result from malicious information being delivered to a white space 1343 device. 1345 9. Summary and Conclusion 1347 Wireless spectrum is a scarce resource. As the demand for spectrum 1348 grows, there is a need to more efficiently utilize the available and 1349 allocated spectrum. Cognitive radio technologies enable the 1350 efficient usage of spectrum via means such as sensing or by querying 1351 a database to determine available spectrum at a given location for 1352 secondary use. White space is the general term used to refer to the 1353 bands within the spectrum which is available for secondary use at a 1354 given location. In order to use this spectrum a device needs to 1355 query a database which maintains information about the available 1356 channels within a band. A protocol is necessary for communication 1357 between the devices and databases which would be globally applicable. 1359 The document describes some examples of the role of the white space 1360 database in the operation of a radio network and also shows an 1361 examples of a services provided to the user of a TVWS device. From 1362 these use cases requirements are determined. These requirements are 1363 to be used as input to the definition of a Protocol to Access White 1364 Space database (PAWS). 1366 10. Acknowledgements 1368 The authors acknowledge Gerald Chouinard and Teco Boot as 1369 contributors to this document. 1371 11. References 1373 11.1. Normative References 1375 [80211P] IEEE, "IEEE Standard for Information technology - 1376 Telecommunications and information exchange between 1377 systems - Local and metropolitan area networks - Specific 1378 requirements; Part 11: Wireless LAN Medium Access Control 1379 (MAC) and Physical Layer (PHY) Specifications; Amendment 1380 6: Wireless Access in Vehicular Environments; http:// 1381 standards.ieee.org/getieee802/download/802.11p-2010.pdf", 1382 July 2010. 1384 [FCC47CFR90.210] 1385 FCC, "Title 47 Telecommunication CFR Chapter I - Federal 1386 Communication Commission Part 90 - Private Land Mobile 1387 Radio Services - Section 210 Emission masks; http:// 1388 edocket.access.gpo.gov/cfr_2010/octqtr/pdf/ 1389 47cfr90.210.pdf", October 2010. 1391 [PAWS-PS] IETF, "Protocol to Access White Space database: Problem 1392 statement; https://datatracker.ietf.org/doc/ 1393 draft-patil-paws-problem-stmt/", July 2011. 1395 [RFC2119] IETF, "Key words for use in RFCs to Indicate Requirement 1396 Levels; 1397 http://www.rfc-editor.org/rfc/pdfrfc/rfc2119.txt.pdf", 1398 March 1997. 1400 11.2. Informative References 1402 [DDR] Ofcom - Independent regulator and competition authority 1403 for the UK communications industries, "Digital Dividend 1404 Review; http://stakeholders.ofcom.org.uk/spectrum/ 1405 project-pages/ddr/". 1407 [DTV] "Digital TV Transition; http://www.dtv.gov". 1409 [ECC Report 159] 1410 Electronic Communications Committee (ECC) within the 1411 European Conference of Postal and Telecommunications 1412 Administrations (CEPT), "TECHNICAL AND OPERATIONAL 1413 REQUIREMENTS FOR THE POSSIBLE OPERATION OF COGNITIVE RADIO 1414 SYSTEMS IN THE 'WHITE SPACES' OF THE FREQUENCY BAND 470- 1415 590 MHZ; http://www.erodocdb.dk/Docs/doc98/official/pdf/ 1416 ECCREP159.PDF", January 2011. 1418 [FCC Ruling] 1419 FCC, "Federal Communications Commission, "Unlicensed 1420 Operation in the TV Broadcast Bands; 1421 http://edocket.access.gpo.gov/2010/pdf/2010-30184.pdf"", 1422 December 2010. 1424 [Ofcom Implementing] 1425 Ofcom, "Ofcom, "Implementing Geolocation; http:// 1426 stakeholders.ofcom.org.uk/consultations/geolocation/ 1427 statement/ 1428 ?utm_source=updates&utm_medium=email& 1429 utm_campaign=geolocation-statement"", September 2011. 1431 [RFC5222] IETF, Hardie, T., Netwon, A., Schulzrinne, H., and H. 1432 Tschofenig, "LoST: A Location-to-Service Translation Proto 1433 col;http://www.rfc-editor.org/rfc/pdfrfc/rfc5222.txt.pdf", 1434 August 2008. 1436 [Spectrum Framework Review] 1437 Ofcom - Independent regulator and competition authority 1438 for the UK communications industries, "Spectrum Framework 1439 Review; 1440 http://stakeholders.ofcom.org.uk/consultations/sfr/", 1441 February 2005. 1443 [TV Whitespace Tutorial Intro] 1444 IEEE 802 Executive Committee Study Group on TV White 1445 Spaces, "TV Whitespace Tutorial Intro; http:// 1446 grouper.ieee.org/groups/802/802_tutorials/2009-03/ 1447 2009-03-10%20TV%20Whitespace%20Tutorial%20r0.pdf", 1448 March 2009. 1450 Authors' Addresses 1452 Scott Probasco (editor) 1453 Nokia 1454 6021 Connection drive 1455 Irving, TX 75039 1456 USA 1458 Email: scott.probasco@nokia.com 1460 Basavaraj Patil 1461 Nokia 1462 6021 Connection drive 1463 Irving, TX 75039 1464 USA 1466 Email: basavaraj.patil@nokia.com