idnits 2.17.1 draft-probasco-paws-overview-usecases-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 (July 12, 2011) is 4670 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Individual Submission S. Probasco, Ed. 3 Internet-Draft G. Bajko 4 Intended status: Informational B. Patil 5 Expires: January 13, 2012 Nokia 6 July 12, 2011 8 Protocol to Access White Space database: Use cases and requirements 9 draft-probasco-paws-overview-usecases-01 11 Abstract 13 Wireless spectrum is a commodity that is regulated by governments. 14 The spectrum is used for various purposes which include entertainment 15 (eg. radio and television), communication (telephony and Internet 16 access), military (radars etc.) and, navigation (satellite 17 communication, GPS). Portions of the radio spectrum that are unused 18 or unoccupied at specific locations and times are defined as "white 19 space". TV White space refers to those unused channels, within the 20 range allocated for TV transmission, that can be used without 21 interfering with the primary purpose for which it is allocated. 23 This document describes examples of how a radio system might operate 24 using TV white space spectrum and associated requirements. Not only 25 does it describe the operation of a radio system, but also how the 26 radio system including a white space database enables additional 27 services. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on January 13, 2012. 46 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 65 2.1. Conventions Used in This Document . . . . . . . . . . . . 4 66 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 67 3. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 3.1. TVWS database discovery . . . . . . . . . . . . . . . . . 5 69 3.2. Hot-Spot: urban internet connectivity service . . . . . . 5 70 3.3. Wide-Area or Rural internet broadband access . . . . . . . 7 71 3.4. Offloading: moving traffic to a white space network . . . 9 72 3.5. TVWS for backhaul . . . . . . . . . . . . . . . . . . . . 11 73 3.6. Location based service usage scenario . . . . . . . . . . 12 74 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 14 75 4.1. Master . . . . . . . . . . . . . . . . . . . . . . . . . . 14 76 4.2. Database . . . . . . . . . . . . . . . . . . . . . . . . . 14 77 4.3. Security . . . . . . . . . . . . . . . . . . . . . . . . . 15 78 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 79 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 80 7. Summary and Conclusion . . . . . . . . . . . . . . . . . . . . 15 81 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 82 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 83 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 84 9.2. Informative References . . . . . . . . . . . . . . . . . . 16 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 87 1. Introduction 89 Wireless spectrum is a commodity that is regulated by governments. 90 The spectrum is used for various purposes which include entertainment 91 (eg. radio and television), communication (telephony and Internet 92 access), military (radars etc.) and, navigation (satellite 93 communication, GPS). Additionally spectrum is allocated for use 94 either on a license basis or for unlicensed use. Television 95 transmission until now has primarily been analog. The switch to 96 digital transmission has begun. As a result the spectrum allocated 97 for television transmission can now be more effectively used. Unused 98 channels and bands between channels can be used as long as they do 99 not interfere with the primary service for which that channel is 100 allocated. While urban areas tend to have dense usage of spectrum 101 and a number of TV channels, the same is not true in rural and semi- 102 urban areas. There can be a number of unused TV channels in such 103 areas that can be used for other services. The figure below shows TV 104 white space within the lower UHF band: 106 Avg | 107 usage| |-------------- White Space 108 | | | | | | 109 0.6| || || V V || 110 | || ||| | || 111 0.4| || |||| | || 112 | || |||| | ||<----TV transmission 113 0.2| || |||| | || 114 |---------------------------------------- 115 400 500 600 700 800 116 Frequency in MHz -> 118 Figure 1: High level view of TV White Space 120 Regulatory entities in several countries including the US, Canada, 121 UK, Finland to name a few are specifying the regulations for the use 122 of TV white space. The availability of TV white space opens up the 123 potential for its use for various purposes. Regulation may mandate 124 its use for certain specific applications or services. 126 This document describes an example of how a radio system might 127 operate using TV white space spectrum. Not only does it describe the 128 operation of a radio system for providing Internet access at a hot 129 spot or in a rural area, but also how the radio system including a 130 white space database enables location based services. The 131 description is high level and generic, it is not meant to be specific 132 to any particular radio technology. 134 2. Conventions and Terminology 136 2.1. Conventions Used in This Document 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 140 document are to be interpreted as described in RFC 2119 [RFC2119]. 142 2.2. Terminology 144 The Terminology Section of the latest version of 145 draft-patil-paws-problem-stmt [PAWS-PS] shall be included by 146 reference. 148 Location Based Service 150 An application or device which provides data, information or 151 service to a user based on their location. 153 Master Device 155 A device which queries the WS Database to find out the available 156 operating channels. 158 Slave Device 160 A device which uses the spectrum made available by a master 161 device. 163 3. Use cases 165 There are many potential use cases that could be considered for the 166 TV white space spectrum. Providing broadband internet access in hot 167 spots, rural and underserved areas are examples. Available channels 168 may also be used to provide internet 'backhaul' for traditional Wi-Fi 169 hot spots, or by towns and cities to monitor/control traffic lights 170 or read utility meters. Still other use cases include the ability to 171 offload data traffic from another internet access network (e.g. 3G 172 cellular network) or to deliver location based services. Some of 173 these use cases are described in the following sections. 175 3.1. TVWS database discovery 177 This use case is preliminary to creating a radio network using TV 178 white space; it is a prerequisite to other use cases. The radio 179 network is created by a master device which can be an access point 180 that establishes Hot Spot coverage, a base station that establish 181 cellular coverage, or a device that establishes a peer-to-peer or ad- 182 hoc network. Before the master device can trasmit in TV white space 183 spectrum, it must contact a trusted database where the device can 184 learn if any channels are available for it to use. 186 In the simplest case the radio device is pre-programmed with the 187 internet address of at least one trusted database. The device can 188 establish contact with a trusted database using one of the pre- 189 programmed internet addresses and establish a TV white space network 190 (as described in one of the following use cases). 192 If the radio device (master) does not have a pre-programmed address 193 for a trusted white space database, or if the trusted database at the 194 pre-programmed address is not responsive, or perhaps the trusted 195 database does not provide service for the radio device's current 196 location, or at the user's choice, the device may attempt to 197 "discover" a trusted database which provides service at the current 198 location. 200 1. The master is connected to the internet by any means other than 201 using the TV white space radio. 203 2. The master constructs and broadcasts a query message over the 204 internet and waits for responses. 206 3. If no acceptable response is received within a pre-configured 207 time limit, the device concludes that no trusted database is 208 available. If one or more response is received, the device 209 evaluates the response to determine if a trusted database can be 210 identified where the device is able to register and receive 211 service from the database. 213 3.2. Hot-Spot: urban internet connectivity service 215 In this use case internet connectivity service is provided in a "hot 216 spot" to local users. Typical deployment scenarios include urban 217 areas where internet connectivity is provided to local businesses and 218 residents, and campus environments where internet connectivity is 219 provided to local buildings and relatively small outdoor areas. This 220 deployment scenario is typically characterized by multiple masters 221 (APs or hot spots) in close proximity, with low antenna height, cells 222 with relatively small radius (a few kilometers or less), and limited 223 numbers of available radio channels. Many of the masters/APs are 224 assumed to be individually deployed and operated, i.e. there is no 225 coordination between many of the masters/APs. The masters/APs in 226 this scenario use a TDD radio technology and transmit at or below a 227 relatively low transmit power threshold. Each master/AP has a 228 connection to the internet and provides internet connectivity to 229 multiple end user or slave devices. 231 The figure below shows an example deployment of this scenario. 233 ------- 234 |Slave|\ \|/ ---------- 235 |Dev 1| (TDD AirIF) | |Database| 236 ------- \ | .---. /--------- 237 o \ |-|---------| ( ) / 238 o | Master | / \ 239 o / | |========( Internet ) 240 o / |-----------| \ / 241 ------- (TDD AirIF) ( ) 242 |Slave| / (----) 243 |Dev n| 244 ------- 246 Figure 2: Hot-spot service using TV white space spectrum 248 Once a master/AP has been correctly installed and configured, a 249 simplified power up and operation scenario utilizing TV White Space 250 to provide Internet connectivity service consists of the following 251 steps: 253 1. The master/AP powers up; however its WS radio and all other WS 254 capable devices will power up in idle/listen only mode (no active 255 transmissions on the WS frequency band). 257 2. The master/AP has Internet connectivity and establishes a 258 connection to a trusted white space database (see use case "TVWS 259 database discovery" above). 261 3. The master/AP registers its geolocation, address, contact 262 information, etc. associated with the owner/operator of the 263 master/AP with the trusted database administrator (if not 264 currently registered). Depending upon local regulator policy, 265 the DB administrator may be required to store and forward the 266 registration information to the regulatory authority. 268 4. Following the registration process, the master/AP will send a 269 query to the trusted database requesting a list of available WS 270 channels based upon its geolocation. 272 5. If the master/AP has been previously authenticated, the database 273 responds with a list of available white space channels that the 274 master may use, and optionally a duration of time for their use. 276 6. Once the master/AP authenticates the WS channel list response 277 message from the database, the AP selects an available WS 278 channel(s) from the list. 280 7. The master/AP acknowledges to the database which of the available 281 WS channels it has selected for its operation. The database is 282 updated with the information provided by the master/AP. 284 8. The slave or user device scans the TV bands to locate a master/AP 285 transmission, and associates with the AP. The slave/user device 286 queries the master for a channel list, based on the slaves' 287 geolocation. 289 9. The master provides the list of channels locally available to the 290 slave/user device. If the channel that the user terminal is 291 currently using is not included in the list of locally available 292 channels, the slave/user device ceases all operation on its 293 current channel. The slave/user device may scan for another AP 294 transmission on a different channel. 296 3.3. Wide-Area or Rural internet broadband access 298 In this use case internet broadband access is provided as a Wide-Area 299 Network (WAN) or Wireless Regional Area Netwowk (WRAN). A typical 300 deployment scenario is a wide area or rural area, where internet 301 broadband access is provided to local businesses and residents from a 302 master (i.e. BS) connected to the internet. This deployment 303 scenario is typically characterized by one or more fixed master(s)/ 304 BS(s), cells with relatively large radius (tens kilometers up to 100 305 km), and many available radio channels. Many of the masters/BSs are 306 assumed to be deployed and operated by a single entity, i.e. there is 307 coordination between many of the masters/BSs. The BS in this 308 scenario use a TDD radio technology and transmit at or below a 309 transmit power threshold established by the local regulator. Each 310 base station has a connection to the internet and provides internet 311 connectivity to multiple slave/end-user devices. End user terminals 312 or devices may be fixed or portable. 314 The figure below shows an example deployment of this scenario. 316 ------- 317 |Slave|\ \|/ ---------- 318 |Dev 1| (TDD AirIF) | |Database| 319 ------- \ | .---. /---------- 320 o \ |-|---------| ( ) / 321 o | Master | / \ 322 o / | (BS) |========( Internet ) 323 o / |-----------| \ / 324 ------- (TDD AirIF) ( ) 325 |Slave| / (----) 326 |Dev n| 327 ------- 329 Figure 3: Rural internet broadband access using TV white space 330 spectrum 332 Once the master/BS has been professionally installed and configured, 333 a simplified power up and operation scenario utilizing TV White Space 334 to provide rural internet broadband access consists of the following 335 steps: 337 1. The master/BS powers up; however its WS radio and all other WS 338 capable devices will power up in idle/listen only mode (No active 339 transmissions on the WS frequency band) 341 2. The master/BS has internet connectivity and establishes a 342 connection to a trusted white space database (see use case "TVWS 343 database discovery" above). 345 3. The master/BS registers its geolocation, address, contact 346 information, etc. associated with the owner/operator of the 347 master/BS with the trusted database service (if not currently 348 registered). Meanwhile the DB administrator may be required to 349 store and forward the registration information to the regulatory 350 authority. If a trusted white space database administrator is 351 not discovered, further operation of the WRAN may be allowed 352 according to local regulator policy (in this case operation of 353 the WRAN is outside the scope of the PAWS protocol). 355 4. Following the registration process, the master/BS will send a 356 query to the trusted database requesting a list of available WS 357 channels based upon its geolocation. 359 5. If the master/BS has been previously authenticated, the database 360 responds with a list of available white space channels that may 361 be used and optionally a maximum transmit power (EIRP) for each 362 channel and a duration of time the channel may be used. 364 6. Once the master/BS authenticates the WS channel list response 365 message from the database, the master/BS selects an available WS 366 channel(s) from the list. The operator may disallow some 367 channels from the list to suit local needs if required. 369 7. The master/BS acknowledges to the database which of the available 370 WS channels the BS has selected for its operation. The database 371 is updated with the information provided by the BS. 373 8. The slave or user device scans the TV bands to locate a WRAN 374 transmission, and associates with the master/BS. The slave/user 375 device queries the master for a channel list, based on the 376 slaves' geolocation. 378 9. The master provides the list of channels locally availabe to the 379 slave/user device. If the channel that the user terminal is 380 currently using is not included in the list of locally available 381 channels, the slave/user device ceases all operation on its 382 current channel. The slave/user device may scan for another WRAN 383 transmission on a different channel. 385 3.4. Offloading: moving traffic to a white space network 387 In this use case internet connectivity service is provided over TV 388 white space as a supplemental or alternative datapath to a 3G or 389 other internet connection. In a typical deployment scenario an end 390 user has a primary internet connection such as a 3G cellular packet 391 data subscription. The user wants to use a widget or application to 392 stream video from an online service (e.g. youtube) to their device. 393 Before the widget starts the streaming connection it checks 394 connectivity options available at the current time and location. 395 Both 3G cellular data is available as well as TVWS connectivity (the 396 user is within coverage of a TVWS master -- hot spot, WAN, WRAN or 397 similar). The user may decide for many and various reasons such as 398 cost, RF coverage, data caps, etc... to prefer the TVWS connection 399 over the 3G cellular data connection. Either by user selection, 400 preconfigured preferences, or other algorithm, the streaming session 401 is started over the TVWS internet connection instead of the 3G 402 cellular connection. This deployment scenario is typically 403 characterized by a TVWS master/AP providing local coverage in the 404 same geographical area as a 3G cellular system. The master/AP is 405 assumed to be individually deployed and operated, i.e. the master/AP 406 is deployed and operated by the user at his home or perhaps by a 407 small business such as a coffee shop. The master/AP has a connection 408 to the internet and provides internet connectivity to the slave/ 409 end-user's device. 411 The figure below shows an example deployment of this scenario. 413 \|/ 414 | 415 | 416 |-|---------| 417 | Master/AP |\ 418 /| Router | \ 419 Streaming/ |-----------| \ 420 -------- / \ ----------- 421 |Slave/| / \ (----) | Database | 422 |WS Dev| \ ( ) /---------- 423 ------- \ \ / \ 424 \ X( Internet ) 425 \ / \ / 426 Signaling \|/ / ( )\ 427 \ | / (----) \---------- 428 \ | / | YouTube | 429 \|-|---------| / ---------- 430 | Master / | / 431 | 3G BTS |/ 432 |-----------| 434 Figure 4: Offloading: moving traffic to a white space network 436 Once a dual or multi mode device (3G + TVWS) is connected to a 3G 437 network, a simplified operation scenario of offloading selected 438 content such as video stream from the 3G connection to the TWVS 439 connection consists of the following steps: 441 1. The dual mode (or multi mode) device (3G + TVWS) is connected to 442 a 3G network. The device has contacted a trusted database to 443 discover the list of available TV channels at is current 444 location. The device has located a TVWS master/AP operating on 445 an available channel and has associated or connected with the 446 TVWS master/AP. 448 2. The user activates a widget or application that streams video 449 from YouTube. The widget connects to YouTube over 3G cellular 450 data. The user browses content and searches for video 451 selections. 453 3. The user selects a video for streaming using the widget's 454 controls. Before the widget initiates a streaming session, the 455 widget checks the available connections in the dual mode device 456 and finds a TVWS master/AP is connected. 458 4. Using either input from the user or pre-defined profile 459 preferences, the widget selects the TVWS master/AP as the 460 connection to stream the video. 462 3.5. TVWS for backhaul 464 In this use case internet connectivity service is provided to users 465 over a traditional wireless protocol, one common example is Wi-Fi. 466 The TV white space network provides the "backhaul" or connection from 467 the Wi-Fi to the internet. In a typical deployment scenario an end 468 user has a device with a radio such as Wi-Fi. A service provider or 469 shop owner wants to provide Wi-Fi internet service for their 470 customers. The location where the service provider wants to provide 471 Wi-Fi is within range of a TVWS master (e.g. Hot-Spot or Wide-Area/ 472 Rural network). The service provider installs a TVWS slave device 473 and connect this slave to a Wi-Fi access point. This deployment 474 scenario is typically characterized by a TVWS master/AP/BS providing 475 local coverage. The master/AP has a connection to the internet and 476 provides internet connectivity to the slave device. The slave device 477 is then 'bridged' to a Wi-Fi network 479 The figure below shows an example deployment of this scenario. 481 \|/ white \|/ \|/ WiFi \|/ 482 | space | | | 483 | | | |-|----| 484 |--------| |-|---------| |-|------|-| | WiFi | 485 | | | Master | | Slave | | Dev | 486 |internet|------| (AP/BS) | | Bridge | |------| 487 | | | | | to WiFi | 488 |--------| |-----------| |----------| \|/ 489 | 490 |-|----| 491 | WiFi | 492 | Dev | 493 |------| 495 Figure 5: TVWS for backhaul 497 Once the bridged device (TVWS+WiFi) is connected to a master and TVWS 498 network, a simplified operation scenario of backhaul for WiFi 499 consists of the following steps: 501 1. A bridged device (TVWS+WiFi) is connected to a master device 502 operating in the TVWS. The bridged device operates as a slave 503 device in either Hot-Spot or Wide-Area/Rural internet use cases 504 described above. 506 2. Once the slave device is connected to the master, the Wi-Fi 507 access point configures its internet settings automatically based 508 on the backhaul connection (i.e. it uses DHCP). 510 3. End users connect their WiFi device to the bridged device and 511 receive internet connectivity. 513 3.6. Location based service usage scenario 515 The owner of a shopping mall wants to provide internet access to 516 customers when they are at the shopping mall. His internet service 517 provider (ISP) recommends using master/AP devices in the TV white 518 space frequency band since these radios will have good propagation 519 characteristics, and thus will require fewer devices, and also 520 because the frequency band used by traditional Wi-Fi is crowded with 521 users such as individual stores operating their own Wi-Fi network and 522 also Bluetooth devices. The ISP installs APs in each large store in 523 the mall, and several other APs throughout the mall building. For 524 each AP, the professional installer programs the location (latitude 525 and longitude) of the device. Special tools are required to 526 determine the location, since typical GPS receivers do not function 527 indoors. When each AP is powered on, the radio does not transmit 528 initially. The AP contacts a white space database, using its wired 529 internet connection, via a URL and provides its programmed location 530 coordinates plus other information required by the database. A reply 531 is received by the AP from the database containing a list of 532 available channels where the AP can operate its transmitter. The AP 533 selects a channel for operation and notifies the database, which 534 records information about the AP including the identity of the AP and 535 its location coordinates. The AP activates its radio and begins to 536 function as a typical wireless AP, providing internet access to 537 connected devices. 539 A user has a slave device that is capable of operating in the TV 540 white spaces frequency band. A typical device would be a smartphone 541 with multiple radios, including a cellular radio, a Wi-Fi radio, and 542 TV white space radio. The user arrives at the shopping mall and 543 enters the building. The white space radio in the smartphone is on, 544 and is scanning for a master/AP. As the user gets near the entrance 545 to the shopping mall, the smartphone locates one of the APs in the 546 building and connects to it. The smartphone begins to use this TVWS 547 radio for internet access. This internet access does not count 548 against the users cellular data cap (the mall owner is providing the 549 internet access) and also the data rates are better than cellular 550 data. As the user walks throughout the mall the smartphone moves 551 between coverage of different APs, and the smartphone connects to a 552 new AP when the user and smartphone move near it. 554 In order to encourage customers to come to the shopping mall, the 555 mall owner has a loyalty program where members register, build 556 points, and receive coupons and other notices from the shops in the 557 mall. Before installing the internet service in the mall, all 558 loyalty program information was mailed to the user, at an address 559 which was provided by the user when joining the loyalty program. 561 The ISP provider describes to the mall owner how the loyalty program 562 can be improved using the internet service provided by the APs in the 563 TV white space. A new app is developed for this loyalty program, and 564 promoted to users, asking them to install the app on their 565 smartphone. The app is provisioned with the user's loyalty program 566 information. When the user comes to the shopping mall, the 567 smartphone locates the master/AP providing internet service and 568 connects to the AP. The app in the smartphone sees that a radio 569 connection to an AP in the TV white space frequency band is now 570 active. The app registers the identity of the AP and forwards this 571 to the home server for the loyalty program, using the internet 572 connection provided by the AP in the TV white space band. The 573 loyalty program server registers the identity of the user from the 574 loyalty program credentials and also the identity of the AP. Next 575 the loyalty program server contacts the TV white space database and 576 requests the location of the master/AP having the identity forwarded 577 by the app and smartphone. When the TV white space database replies 578 with the location coordinates of the AP, the loyalty program server 579 knows the approximate location of the user and smartphone. With this 580 location information, the loyalty program server can now forward 581 loyalty program information to the user. As the user moves through 582 the mall, the smartphone connects to different APs. The process is 583 repeated, allowing the loyalty program to delivery current location 584 based information to the user. 586 1. The master create a TVWS network as described in use case "Hot- 587 Spot: urband internet connectivity service." 589 2. An application running on the user's slave device (e.g. 590 smartphone) determines that a network connection exists in the 591 TVWS band. The identify of the master/AP is recorded by the 592 application and forwarded to a server in the internet cloud. 594 3. The server queries the trusted white space database with the 595 master identity provided by the application in the user's 596 smartphone. 598 4. The trusted white space database replies to the server with the 599 location of the master device. 601 5. The server uses the location of the master/AP to determine the 602 approximate location of the user's smartphone. The server 603 provides location-specific service to the user via the 604 application running in the smartphone. 606 4. Requirements 608 4.1. Master 610 1. A master device MUST include, directly or indirectly, its antenna 611 height in the query to the WS Database. 613 2. A master device MUST query the WS Database for the available 614 channels at least once a day to verify that the operating 615 channels continue to remain available. 617 3. A master device MUST determine its location with at least =/-50 618 meters accuracy and MUST place that location into the query it 619 makes to the WS Database. 621 4. A master device MAY indicate the accuracy by which it determined 622 its location in the query to the WS Database. 624 5. A master device which changes its location during operation MUST 625 query the WS Database for available operating channels each time 626 it moves more than 100 meters from the location it previously 627 made the query. 629 6. A master device MUST be able to receive channel availability 630 updates from a WS Database. 632 7. A master device MUST be able to query the WS Database for channel 633 availability information for multiple locations. 635 8. A master device MUST be able to query the WS Database for channel 636 availability information for a specific area around its current 637 location. 639 9. A master device MUST query the WS Database and include the FCC ID 640 of the slave device in the query before allowing the slave device 641 to use the available channel. 643 4.2. Database 645 1. The WS Database MUST provide the available channel list when 646 requested and MAY also provide time constraints for the channel 647 list and maximum output power to the master device. 649 4.3. Security 651 1. The protocol between the master device and the WS Database MUST 652 support mutual authentication and authorization. 654 2. The protocol between the master device and the WS Database MUST 655 support integrity and confidentiality protection. 657 3. The WS Database MUST support both username/password and digital 658 certificates based authentication of the master device. 660 4. A master device MUST be capable to validate the digital 661 certificate of the WS Database. 663 5. A master device MUST be capable to check the validity of the WS 664 Database certificate and whether it has been revoked or not. 666 5. IANA Considerations 668 This document has no requests to IANA. 670 6. Security Considerations 672 The messaging interface between the master and the database must be 673 secure to ensure confidentiality, authenticity and integrity of the 674 data exchanged between devices. A master queries a database with 675 information which identifies owner/operator of the device and also 676 the location of the device. Such information can reasonably 677 considered to be sensitive information which must remain 678 confidential. A well-functioning white space network relies upon 679 trusted devices exchanging trusted information, thus each participant 680 in the protocol exchange must be authenticated. A white space 681 network must ensure the protection of the primary user of the radio 682 spectrum, therefore the integrity of the message exchange must be 683 ensured. 685 7. Summary and Conclusion 687 The document describes some examples of the role of the white space 688 database in the operation of a radio network and also shows an 689 examples of a services provided to the user of a TVWS device. From 690 these use cases requirements are determined. These requirements are 691 to be used as input to the definition of a Protocol to Access White 692 Space database (PAWS). 694 8. Acknowledgements 696 The authors acknowledge Tom Derryberry as contributor to version 00 697 of this document. 699 9. References 701 9.1. Normative References 703 [PAWS-PS] IETF, "Protocol to Access White Space database: Problem 704 statement; https://datatracker.ietf.org/doc/ 705 draft-patil-paws-problem-stmt/", July 2011. 707 [RFC2119] IETF, "Key words for use in RFCs to Indicate Requirement 708 Levels; 709 http://www.rfc-editor.org/rfc/pdfrfc/rfc2119.txt.pdf", 710 March 1997. 712 9.2. Informative References 714 [FCC Ruling] 715 FCC, "Federal Communications Commission, "Unlicensed 716 Operation in the TV Broadcast Bands; 717 http://edocket.access.gpo.gov/2010/pdf/2010-30184.pdf", 718 December 2010. 720 [TV Whitespace Tutorial Intro] 721 IEEE 802 Executive Committee Study Group on TV White 722 Spaces, "TV Whitespace Tutorial Intro; http:// 723 grouper.ieee.org/groups/802/802_tutorials/2009-03/ 724 2009-03-10%20TV%20Whitespace%20Tutorial%20r0.pdf", 725 March 2009. 727 Authors' Addresses 729 Scott Probasco (editor) 730 Nokia 731 6021 Connection drive 732 Irving, TX 75039 733 USA 735 Email: scott.probasco@nokia.com 736 Gabor Bajko 737 Nokia 738 200 South Mathilda Ave 739 Sunnyvale, CA 94086 740 USA 742 Email: gabor.bajko@nokia.com 744 Basavaraj Patil 745 Nokia 746 6021 Connection drive 747 Irving, TX 75039 748 USA 750 Email: basavaraj.patil@nokia.com