idnits 2.17.1 draft-ietf-paws-problem-stmt-usecases-rqmts-00.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (September 9, 2011) is 4603 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'PAWS-PS' is defined on line 1018, but no explicit reference was found in the text == Unused Reference: 'RFC5222' is defined on line 1051, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 4 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 G. Bajko 4 Intended status: Informational B. Patil 5 Expires: March 12, 2012 Nokia 6 B. Rosen 7 Neustar 8 September 9, 2011 10 Protocol to Access White Space database: PS, use cases and rqmts 11 draft-ietf-paws-problem-stmt-usecases-rqmts-00 13 Abstract 15 Portions of the radio spectrum that are allocated to a licensed, 16 primary user but are unused or unoccupied at specific locations and 17 times are defined as "white space". The concept of allowing 18 secondary transmissions (licensed or unlicensed) in white space is a 19 technique to "unlock" existing spectrum for new use. An obvious 20 requirement is that these secondary transmissions do not interfere 21 with the primary use of the spectrum. One approach to using the 22 white space spectrum at a given time and location is to verify with a 23 database available channels. 25 This document describes the concept of TV White Spaces. It also 26 describes the problems that need to be addressed for enabling the use 27 of the primary user owned white space spectrum for secondary users, 28 without causing interference, by querying a database which knows the 29 channel availability at any given location and time. A number of 30 possible use cases of this spectrum and derived requirements are also 31 described. 33 Status of this Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on March 12, 2012. 50 Copyright Notice 52 Copyright (c) 2011 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 5 69 2.1. Conventions Used in This Document . . . . . . . . . . . . 5 70 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 71 3. Prior Work . . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 3.1. The concept of Cognitive Radio . . . . . . . . . . . . . . 6 73 3.2. Background information on white space in US . . . . . . . 6 74 3.3. Air Interfaces . . . . . . . . . . . . . . . . . . . . . . 7 75 4. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 7 76 4.1. TVWS database discovery . . . . . . . . . . . . . . . . . 7 77 4.2. Hotspot: urban internet connectivity service . . . . . . . 8 78 4.3. Wide-Area or Rural internet broadband access . . . . . . . 10 79 4.4. Offloading: moving traffic to a white space network . . . 12 80 4.5. TVWS for backhaul . . . . . . . . . . . . . . . . . . . . 14 81 4.6. Location based service usage scenario . . . . . . . . . . 15 82 4.7. Rapid deployed network for emergency scenario . . . . . . 17 83 5. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 18 84 5.1. Global applicability . . . . . . . . . . . . . . . . . . . 19 85 5.2. Database discovery . . . . . . . . . . . . . . . . . . . . 21 86 5.3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 21 87 5.4. Data model definition . . . . . . . . . . . . . . . . . . 21 88 6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 21 89 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 90 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 91 9. Summary and Conclusion . . . . . . . . . . . . . . . . . . . . 22 92 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 93 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 94 11.1. Normative References . . . . . . . . . . . . . . . . . . . 23 95 11.2. Informative References . . . . . . . . . . . . . . . . . . 23 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 98 1. Introduction 100 Wireless spectrum is a commodity that is regulated by governments. 101 The spectrum is used for various purposes, which include 102 entertainment (e.g. radio and television), communication (telephony 103 and Internet access), military (radars etc.) and, navigation 104 (satellite communication, GPS). Portions of the radio spectrum that 105 are allocated to a licensed, primary user but are unused or 106 unoccupied at specific locations and times are defined as "white 107 space". The concept of allowing secondary transmissions (licensed or 108 unlicensed) in white space is a technique to "unlock" existing 109 spectrum for new use. An obvious requirement is that these secondary 110 transmissions do not interfere with the primary use of the spectrum. 111 One interesting observation is that often, in a given physical 112 location, the primary user(s) may not be using the entire band 113 allocated to them. The available spectrum for a secondary use would 114 then depend on the location of the secondary user. The fundamental 115 issue is how to determine for a specific location and specific time, 116 if any of the primary spectrum is available for secondary use. 117 Academia and Industry have studied multiple cognitive radio 118 mechanisms for use in such a scenario. One simple mechanism is to 119 use a geospatial database that records the primary users occupation, 120 and require the secondary users to check the database prior to 121 selecting what part of the spectrum they use. Such databases could 122 be available on the Internet for query by secondary users. 124 Spectrum useable for data communications, especially wireless 125 Internet communications, is scarce. One area which has received much 126 attention globally is the TV white space: portions of the TV band 127 that are not used by broadcasters in a given area. In 2008 the 128 United States regulator (the FCC) took initial steps when they 129 published their first ruling on the use of TV white space, and then 130 followed it up with a final ruling in 2010 [FCC Ruling]. Finland 131 passed an Act in 2009 enabling testing of cognitive radio systems in 132 the TV white space. The ECC has completed Report 159 [ECC Report 133 159] containing requirements for operation of cognitive radio systems 134 in the TV white space. Ofcom published in 2004 their Spectrum 135 Framework Review [Spectrum Framework Review] and their Digital 136 Dividend Review [DDR] in 2005, and have followed up with a proposal 137 to access TV white space. More countries are expected to provide 138 access to their TV spectrum in similar ways. Any entity holding 139 spectrum that is not densely used may be asked to give it up in one 140 way or another for more intensive use. Providing a mechanism by 141 which secondary users share the spectrum with the primary user is 142 attractive in many bands in many countries. 144 Television transmission until now has primarily been analog. The 145 switch to digital transmission has begun. As a result the spectrum 146 allocated for television transmission can now be more effectively 147 used. Unused channels and bands between channels can be used as long 148 as they do not interfere with the primary service for which that 149 channel is allocated. While urban areas tend to have dense usage of 150 spectrum and a number of TV channels, the same is not true in rural 151 and semi-urban areas. There can be a number of unused TV channels in 152 such areas that can be used for other services. The figure below 153 shows TV white space within the lower UHF band: 155 Avg | 156 usage| |-------------- White Space 157 | | | | | | 158 0.6| || || V V || 159 | || ||| | || 160 0.4| || |||| | || 161 | || |||| | ||<----TV transmission 162 0.2| || |||| | || 163 |---------------------------------------- 164 400 500 600 700 800 165 Frequency in MHz -> 167 Figure 1: High level view of TV White Space 169 The fundamental issue is how to determine for a specific location and 170 specific time if any of the spectrum is available for secondary use. 171 There are two dimensions of use that may be interesting: space (the 172 area in which a secondary user would not interfere with a primary 173 user, and time: when the secondary use would not interfere with the 174 primary use. In this discussion, we consider the time element to be 175 relatively long term (hours in a day) rather than short term 176 (fractions of a second). Location in this discussion is geolocation: 177 where the transmitters (and sometimes receivers) are located relative 178 to one another. In operation, the database records the existing 179 user's transmitter (and some times receiver) locations along with 180 basic transmission characteristics such as antenna height, and 181 sometimes power. Using rules established by the regulator, the 182 database calculates an exclusion zone for each authorized primary 183 user, and attaches a time schedule to that use. The secondary user 184 queries the database with its location. The database intersects the 185 exclusion zones with the queried location, and returns the portion of 186 the spectrum not in any exclusion zone. Such methods of geospatial 187 database query to avoid interference have been shown to achieve 188 favorable results, and are thus the basis for rulings by the FCC and 189 reports from ECC and Ofcom. In any country, the rules for which 190 primary entities are entitled to protection, how the exclusion zones 191 are calculated, and what the limits of use by secondary entities are 192 may vary. However, the fundamental notion of recording primary 193 users, calculating exclusion zones, querying by location and 194 returning available spectrum (and the schedule for that spectrum) are 195 common 197 This document includes the problem statement, use cases and 198 requirements associated with the use of white space spectrum by 199 secondary users via a database query protocol. 201 2. Conventions and Terminology 203 2.1. Conventions Used in This Document 205 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 206 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 207 document are to be interpreted as described in RFC 2119 [RFC2119]. 209 2.2. Terminology 211 Database 213 In the context of white space and cognitive radio technologies, 214 the database is an entity which contains current information about 215 available spectrum at any given location and other types of 216 information. 218 Location Based Service 220 An application or device which provides data, information or 221 service to a user based on their location. 223 Master Device 225 A device which queries the WS Database to find out the available 226 operating channels. 228 Protected Entity 230 A primary user of white space spectrum which is afforded 231 protection against interference by secondary users (white space 232 devices) for its use in a given area and time. 234 Protected Contour 236 The exclusion area for a Protected Entity, held in the database 237 and expressed as a polygon with geospatial points as the vertices. 239 Slave Device 241 A device which uses the spectrum made available by a master 242 device. 244 TV White Space 246 TV white space refers specifically to radio spectrum which has 247 been allocated for TV broadcast, but is not occupied by a TV 248 broadcast, or other licensed user (such as a wireless microphone), 249 at a specific location and time. 251 White Space 253 Radio spectrum which has been allocated for some primary use, but 254 is not fully occupied by that primary use at a specific location 255 and time. 257 White Space Device 259 A device which is a secondary user of some part of white space 260 spectrum. A white space device can be an access point, base 261 station, a portable device or similar. In this context, a white 262 space device is required to query a database with its location to 263 obtain information about available spectrum. 265 3. Prior Work 267 3.1. The concept of Cognitive Radio 269 A cognitive radio uses knowledge of the local radio environment to 270 dynamically adapt its own configuration and function properly in a 271 changing radio environment. Knowledge of the local radio environment 272 can come from various technology mechanisms including sensing 273 (attempting to ascertain primary users by listening for them within 274 the spectrum), location determination and internet connectivity to a 275 database to learn the details of the local radio environment. TV 276 White Space is one implementation of cognitive radio. Because a 277 cognitive radio adapts itself to the available spectrum in a manner 278 that prevents the creation of harmful interference, the spectrum can 279 be shared among different radio users. 281 3.2. Background information on white space in US 283 Television transmission in the United States has moved to the use of 284 digital signals as of June 12, 2009. Since June 13, 2009, all full- 285 power U.S. television stations have broadcast over-the-air signals in 286 digital only. An important benefit of the switch to all-digital 287 broadcasting is that it freed up parts of the valuable broadcast 288 spectrum. More information about the switch to digital transmission 289 is at : [DTV]. 291 With the switch to digital transmission for TV, the guard bands that 292 existed to protect the signals between stations can now be used for 293 other purposes. The FCC has made this spectrum available for 294 unlicensed use and this is generally referred to as white space. 295 Please see the details of the FCC ruling and regulations in [FCC 296 Ruling]. The spectrum can be used to provide wireless broadband as 297 an example. The term "Super-Wifi" is also used to describe this 298 spectrum and potential for providing wifi type of service. 300 3.3. Air Interfaces 302 Efforts are ongoing to specify air-interfaces for use in white space 303 spectrum. IEEEs 802.11af task group is currently working on one such 304 specification. IEEE 802.22 is another example. Other air interfaces 305 could be specified in the future such as LTE. 307 4. Use cases 309 There are many potential use cases that could be considered for the 310 TV white space spectrum. Providing broadband internet access in 311 hotspots, rural and underserved areas are examples. Available 312 channels may also be used to provide internet 'backhaul' for 313 traditional Wi-Fi hotspots, or by towns and cities to monitor/control 314 traffic lights or read utility meters. Still other use cases include 315 the ability to offload data traffic from another internet access 316 network (e.g. 3G cellular network) or to deliver location based 317 services. Some of these use cases are described in the following 318 sections. 320 4.1. TVWS database discovery 322 This use case is preliminary to creating a radio network using TV 323 white space; it is a prerequisite to other use cases. The radio 324 network is created by a master device which can be an access point 325 that establishes Hotspot coverage, a base station that establish 326 cellular coverage, or a device that establishes a peer-to-peer or ad- 327 hoc network. Before the master device can transmit in TV white space 328 spectrum, it must contact a trusted database where the device can 329 learn if any channels are available for it to use. 331 In the simplest case the radio device is pre-programmed with the 332 internet address of at least one trusted database. The device can 333 establish contact with a trusted database using one of the pre- 334 programmed internet addresses and establish a TV white space network 335 (as described in one of the following use cases). 337 If the radio device (master) does not have a pre-programmed address 338 for a trusted white space database, or if the trusted database at the 339 pre-programmed address is not responsive, or perhaps the trusted 340 database does not provide service for the radio device's current 341 location, or at the user's choice, the device may attempt to 342 "discover" a trusted database which provides service at the current 343 location. 345 1. The master is connected to the internet by any means other than 346 using the TV white space radio. 348 2. The master constructs and broadcasts a query message over the 349 internet and waits for responses. 351 3. If no acceptable response is received within a pre-configured 352 time limit, the device concludes that no trusted database is 353 available. If one or more response is received, the device 354 evaluates the response to determine if a trusted database can be 355 identified where the device is able to register and receive 356 service from the database. 358 4.2. Hotspot: urban internet connectivity service 360 In this use case internet connectivity service is provided in a 361 "hotspot" to local users. Typical deployment scenarios include urban 362 areas where internet connectivity is provided to local businesses and 363 residents, and campus environments where internet connectivity is 364 provided to local buildings and relatively small outdoor areas. This 365 deployment scenario is typically characterized by multiple masters 366 (APs or hotspots) in close proximity, with low antenna height, cells 367 with relatively small radius (a few kilometers or less), and limited 368 numbers of available radio channels. Many of the masters/APs are 369 assumed to be individually deployed and operated, i.e. there is no 370 coordination between many of the masters/APs. The masters/APs in 371 this scenario use a TDD radio technology and transmit at or below a 372 relatively low transmit power threshold. Each master/AP has a 373 connection to the internet and provides internet connectivity to 374 multiple end user or slave devices. 376 The figure below shows an example deployment of this scenario. 378 ------- 379 |Slave|\ \|/ ---------- 380 |Dev 1| (TDD AirIF) | |Database| 381 ------- \ | .---. /--------- 382 o \ |-|---------| ( ) / 383 o | Master | / \ 384 o / | |========( Internet ) 385 o / |-----------| \ / 386 ------- (TDD AirIF) ( ) 387 |Slave| / (----) 388 |Dev n| 389 ------- 391 Figure 2: Hotspot service using TV white space spectrum 393 Once a master/AP has been correctly installed and configured, a 394 simplified power up and operation scenario utilizing TV White Space 395 to provide Internet connectivity service consists of the following 396 steps: 398 1. The master/AP powers up; however its WS radio and all other WS 399 capable devices will power up in idle/listen only mode (no active 400 transmissions on the WS frequency band). 402 2. The master/AP has Internet connectivity and establishes a 403 connection to a trusted white space database (see use case "TVWS 404 database discovery" above). 406 3. The master/AP registers its geolocation, address, contact 407 information, etc. associated with the owner/operator of the 408 master/AP with the trusted database administrator (if not 409 currently registered). Depending upon local regulator policy, 410 the DB administrator may be required to store and forward the 411 registration information to the regulatory authority. 413 4. Following the registration process, the master/AP will send a 414 query to the trusted database requesting a list of available WS 415 channels based upon its geolocation. 417 5. If the master/AP has been previously authenticated, the database 418 responds with a list of available white space channels that the 419 master may use, and optionally a duration of time for their use. 421 6. Once the master/AP authenticates the WS channel list response 422 message from the database, the AP selects an available WS 423 channel(s) from the list. 425 7. The master/AP acknowledges to the database which of the available 426 WS channels it has selected for its operation. The database is 427 updated with the information provided by the master/AP. 429 8. The slave or user device scans the TV bands to locate a master/AP 430 transmission, and associates with the AP. The slave/user device 431 queries the master for a channel list, based on the slaves' 432 geolocation. 434 9. The master provides the list of channels locally available to the 435 slave/user device. If the channel that the user terminal is 436 currently using is not included in the list of locally available 437 channels, the slave/user device ceases all operation on its 438 current channel. The slave/user device may scan for another AP 439 transmission on a different channel. 441 4.3. Wide-Area or Rural internet broadband access 443 In this use case, internet broadband access is provided as a Wide- 444 Area Network (WAN) or Wireless Regional Area Network (WRAN). A 445 typical deployment scenario is a wide area or rural area, where 446 internet broadband access is provided to local businesses and 447 residents from a master (i.e. BS) connected to the internet. This 448 deployment scenario is typically characterized by one or more fixed 449 master(s)/BS(s), cells with relatively large radius (tens of 450 kilometers, up to 100 km), and a number of available radio channels. 451 Some of the masters/BSs may be deployed and operated by a single 452 entity, i.e. there can be centralized coordination between these 453 masters/BSs, whereas other masters/BSs may be deployed and operated 454 by operators competing for the radio channels in a license-exempt 455 TVWS environment where decentralized coordination using the air- 456 interface would be required. The BS in this scenario use a TDD radio 457 technology and transmit at or below a transmit power limit 458 established by the local regulator. Each base station has a 459 connection to the internet and provides internet connectivity to 460 multiple slave/end-user devices. End user terminals or devices may 461 be fixed or portable. 463 The figure below shows an example deployment of this scenario. 465 ------- 466 |Slave|\ \|/ ---------- 467 |Dev 1| (TDD AirIF) | |Database| 468 ------- \ | .---. /---------- 469 o \ |-|---------| ( ) / 470 o | Master | / \ 471 o / | (BS) |========( Internet ) 472 o / |-----------| \ / 473 ------- (TDD AirIF) ( ) 474 |Slave| / (----) 475 |Dev n| 476 ------- 478 Figure 3: Rural internet broadband access using TV white space 479 spectrum 481 Once the master/BS has been professionally installed and configured, 482 a simplified power up and operation scenario utilizing TV White Space 483 to provide rural internet broadband access consists of the following 484 steps: 486 1. The master/BS powers up; however its WS radio and all other WS 487 capable devices will power up in idle/listen only mode (No active 488 transmissions on the WS frequency band) 490 2. The master/BS has internet connectivity and establishes a 491 connection to a trusted white space database (see use case "TVWS 492 database discovery" above). 494 3. The master/BS registers its geolocation, address, contact 495 information, etc. associated with the owner/operator of the 496 master/BS with the trusted database service (if not currently 497 registered). Meanwhile the DB administrator may be required to 498 store and forward the registration information to the regulatory 499 authority. If a trusted white space database administrator is 500 not discovered, further operation of the WRAN may be allowed 501 according to local regulator policy (in this case operation of 502 the WRAN is outside the scope of the PAWS protocol). 504 4. Following the registration process, the master/BS will send a 505 query to the trusted database requesting a list of available WS 506 channels based upon its geolocation. 508 5. If the master/BS has been previously authenticated, the database 509 responds with a list of available white space channels that may 510 be used and optionally a maximum transmit power (EIRP) for each 511 channel and a duration of time the channel may be used. 513 6. Once the master/BS authenticates the WS channel list response 514 message from the database, the master/BS selects an available WS 515 channel(s) from the list. The operator may disallow some 516 channels from the list to suit local needs if required. 518 7. The master/BS acknowledges to the database which of the available 519 WS channels the BS has selected for its operation. The database 520 is updated with the information provided by the BS. 522 8. The slave or user device scans the TV bands to locate a WRAN 523 transmission, and associates with the master/BS. The slave/user 524 device provides its geolocation to the BS which, in turn, queries 525 the database for a list of channels available at the slaves' 526 geolocation. 528 9. Once this list of available channels is received from the 529 database by the master, the latter will decide, based on the list 530 of available channels for all its other associated slaves whether 531 it should continue operation on its current channel or change 532 channel to accommodate the new slave in case this channel is not 533 available at its location. The master will notify all its 534 associated slaves/user devices of the new channel to move to if 535 operation needs to change channel. If the channel that the user 536 terminal is currently using is not included in the list of 537 locally available channels, the master will drop its association 538 with the slave/user device so that it ceases all operation on its 539 current channel and indicate the new operating channel before 540 dropping the link if a change has been decided. The slave/user 541 device may move to the indicated new channel if so indicated or 542 scan for another WRAN transmission on a different channel. 544 4.4. Offloading: moving traffic to a white space network 546 In this use case internet connectivity service is provided over TV 547 white space as a supplemental or alternative datapath to a 3G or 548 other internet connection. In a typical deployment scenario an end 549 user has a primary internet connection such as a 3G cellular packet 550 data subscription. The user wants to use a widget or application to 551 stream video from an online service (e.g. youtube) to their device. 552 Before the widget starts the streaming connection it checks 553 connectivity options available at the current time and location. 554 Both 3G cellular data is available as well as TVWS connectivity (the 555 user is within coverage of a TVWS master -- hotspot, WAN, WRAN or 556 similar). The user may decide for many and various reasons such as 557 cost, RF coverage, data caps, etc. to prefer the TVWS connection over 558 the 3G cellular data connection. Either by user selection, 559 preconfigured preferences, or other algorithm, the streaming session 560 is started over the TVWS internet connection instead of the 3G 561 cellular connection. This deployment scenario is typically 562 characterized by a TVWS master/AP providing local coverage in the 563 same geographical area as a 3G cellular system. The master/AP is 564 assumed to be individually deployed and operated, i.e. the master/AP 565 is deployed and operated by the user at his home or perhaps by a 566 small business such as a coffee shop. The master/AP has a connection 567 to the internet and provides internet connectivity to the slave/ 568 end-user's device. 570 The figure below shows an example deployment of this scenario. 572 \|/ 573 | 574 | 575 |-|---------| 576 | Master/AP |\ 577 /| Router | \ 578 Streaming/ |-----------| \ 579 -------- / \ ----------- 580 |Slave/| / \ (----) | Database | 581 |WS Dev| \ ( ) /---------- 582 ------- \ \ / \ 583 \ X( Internet ) 584 \ / \ / 585 Signaling \|/ / ( )\ 586 \ | / (----) \---------- 587 \ | / | YouTube | 588 \|-|---------| / ---------- 589 | Master / | / 590 | 3G BTS |/ 591 |-----------| 593 Figure 4: Offloading: moving traffic to a white space network 595 Once a dual or multi mode device (3G + TVWS) is connected to a 3G 596 network, a simplified operation scenario of offloading selected 597 content such as video stream from the 3G connection to the TWVS 598 connection consists of the following steps: 600 1. The dual mode (or multi mode) device (3G + TVWS) is connected to 601 a 3G network. The device has contacted a trusted database to 602 discover the list of available TV channels at its current 603 location. The device has located a TVWS master/AP operating on 604 an available channel and has associated or connected with the 605 TVWS master/AP. 607 2. The user activates a widget or application that streams video 608 from YouTube. The widget connects to YouTube over 3G cellular 609 data. The user browses content and searches for video 610 selections. 612 3. The user selects a video for streaming using the widget's 613 controls. Before the widget initiates a streaming session, the 614 widget checks the available connections in the dual mode device 615 and finds a TVWS master/AP is connected. 617 4. Using either input from the user or pre-defined profile 618 preferences, the widget selects the TVWS master/AP as the 619 connection to stream the video. 621 4.5. TVWS for backhaul 623 In this use case internet connectivity service is provided to users 624 over a traditional wireless protocol, one common example is Wi-Fi. 625 The TV white space network provides the "backhaul" or connection from 626 the Wi-Fi to the internet. In a typical deployment scenario an end 627 user has a device with a radio such as Wi-Fi. A service provider or 628 shop owner wants to provide Wi-Fi internet service for their 629 customers. The location where the service provider wants to provide 630 Wi-Fi is within range of a TVWS master (e.g. Hotspot or Wide-Area/ 631 Rural network). The service provider installs a TVWS slave device 632 and connects this slave to a Wi-Fi access point. This deployment 633 scenario is typically characterized by a TVWS master/AP/BS providing 634 local coverage. The master/AP has a connection to the internet and 635 provides internet connectivity to the slave device. The slave device 636 is then 'bridged' to a Wi-Fi network 638 The figure below shows an example deployment of this scenario. 640 \|/ white \|/ \|/ WiFi \|/ 641 | space | | | 642 | | | |-|----| 643 |--------| |-|---------| |-|------|-| | WiFi | 644 | | | Master | | Slave | | Dev | 645 |internet|------| (AP/BS) | | Bridge | |------| 646 | | | | | to WiFi | 647 |--------| |-----------| |----------| \|/ 648 | 649 |-|----| 650 | WiFi | 651 | Dev | 652 |------| 654 Figure 5: TVWS for backhaul 656 Once the bridged device (TVWS+WiFi) is connected to a master and TVWS 657 network, a simplified operation scenario of backhaul for WiFi 658 consists of the following steps: 660 1. A bridged device (TVWS+WiFi) is connected to a master device 661 operating in the TVWS. The bridged device operates as a slave 662 device in either Hotspot or Wide-Area/Rural internet use cases 663 described above. 665 2. Once the slave device is connected to the master, the Wi-Fi 666 access point configures its internet settings automatically based 667 on the backhaul connection (i.e. it uses DHCP). 669 3. End users connect their WiFi device to the bridged device and 670 receive internet connectivity. 672 4.6. Location based service usage scenario 674 The owner of a shopping mall wants to provide internet access to 675 customers when they are at the shopping mall. His internet service 676 provider (ISP) recommends using master/AP devices in the TV white 677 space frequency band since these radios will have good propagation 678 characteristics, and thus will require fewer devices, and also 679 because the frequency band used by traditional Wi-Fi is crowded with 680 users such as individual stores operating their own Wi-Fi network and 681 also Bluetooth devices. The ISP installs APs in each large store in 682 the mall, and several other APs throughout the mall building. For 683 each AP, the professional installer programs the location (latitude 684 and longitude) of the device. Special tools are required to 685 determine the location, since typical GPS receivers do not function 686 indoors. When each AP is powered on, the radio does not transmit 687 initially. The AP contacts a white space database, using its wired 688 internet connection, and provides its programmed location coordinates 689 plus other information required by the database. A reply is received 690 by the AP from the database containing a list of available channels 691 where the AP can operate its transmitter. The AP selects a channel 692 for operation and notifies the database, which records information 693 about the AP including the identity of the AP and its location 694 coordinates. The AP activates its radio and begins to function as a 695 typical wireless AP, providing internet access to connected devices. 697 A user has a slave device that is capable of operating in the TV 698 white spaces frequency band. A typical device would be a smartphone 699 with multiple radios, including a cellular radio, a Wi-Fi radio, and 700 TV white space radio. The user arrives at the shopping mall and 701 enters the building. The white space radio in the smartphone is on, 702 and is scanning for a master/AP. As the user gets near the entrance 703 to the shopping mall, the smartphone locates one of the APs in the 704 building and connects to it. The smartphone begins to use this TVWS 705 radio for internet access. This internet access does not count 706 against the users cellular data cap (the mall owner is providing the 707 internet access) and also the data rates are better than cellular 708 data. As the user walks throughout the mall the smartphone moves 709 between coverage of different APs, and the smartphone connects to a 710 new AP when the user and smartphone move near it. 712 In order to encourage customers to come to the shopping mall, the 713 mall owner has a loyalty program where members register, build 714 points, and receive coupons and other notices from the shops in the 715 mall. Before installing the internet service in the mall, all 716 loyalty program information was mailed to the user, at an address 717 which was provided by the user when joining the loyalty program. 719 The ISP provider describes to the mall owner how the loyalty program 720 can be improved using the internet service provided by the APs in the 721 TV white space. A new app is developed for this loyalty program, and 722 promoted to users, asking them to install the app on their 723 smartphone. The app is provisioned with the user's loyalty program 724 information. When the user comes to the shopping mall, the 725 smartphone locates the master/AP providing internet service and 726 connects to the AP. The app in the smartphone sees that a radio 727 connection to an AP in the TV white space frequency band is now 728 active. The app registers the identity of the AP and forwards this 729 to the home server for the loyalty program, using the internet 730 connection provided by the AP in the TV white space band. The 731 loyalty program server registers the identity of the user from the 732 loyalty program credentials and also the identity of the AP. Next 733 the loyalty program server contacts the TV white space database and 734 requests the location of the master/AP having the identity forwarded 735 by the app and smartphone. When the TV white space database replies 736 with the location coordinates of the AP, the loyalty program server 737 knows the approximate location of the user and smartphone. With this 738 location information, the loyalty program server can now forward 739 loyalty program information to the user. As the user moves through 740 the mall, the smartphone connects to different APs. The process is 741 repeated, allowing the loyalty program to delivery current location 742 based information to the user. 744 1. The master create a TVWS network as described in use case 745 "Hotspot: urban internet connectivity service." 747 2. An application running on the user's slave device (e.g. 748 smartphone) determines that a network connection exists in the 749 TVWS band. The identify of the master/AP is recorded by the 750 application and forwarded to a server in the internet cloud. 752 3. The server queries the trusted white space database with the 753 master identity provided by the application in the user's 754 smartphone. 756 4. The trusted white space database replies to the server with the 757 location of the master device. 759 5. The server uses the location of the master/AP to determine the 760 approximate location of the user's smartphone. The server 761 provides location-specific service to the user via the 762 application running in the smartphone. 764 4.7. Rapid deployed network for emergency scenario 766 Organizations involved in handling emergency operations often have a 767 fully owned and controlled infrastructure, with dedicated spectrum, 768 for day to day operation. However, lessons learned from recent 769 disasters show such infrastructures are often highly affected by the 770 disaster itself. To set up a replacement quickly, there is a need 771 for fast reallocation of spectrum, where in certain cases spectrum 772 can be freed for disaster relief. To utilize free or freed spectrum 773 quickly and reliable, automation of allocation, assignment and 774 configuration is needed. A preferred option is make use of a robust 775 protocol, already adopted by radio manufacturers. This approach does 776 in no way imply such organizations for disaster relief must compete 777 on spectrum allocation with other white spaces users, but they can. 778 A typical network topology would include wireless access links to the 779 public Internet or private network, wireless ad hoc network radios 780 working independent of a fixed infrastructure and satellite links for 781 backup where lack of coverage, overload or outage of wireless access 782 links occur. 784 The figure below shows an example deployment of this scenario. 786 \|/ 787 | ad hoc 788 | 789 |-|-------------| 790 | Master node | |------------| 791 \|/ | with | | Whitespace | 792 | ad hoc /| backhaul link | | Database | 793 | /------/ |---------------| |------------| 794 ---|------------/ | \ / 795 | Master node | | | (--/--) 796 | without | | ------( ) 797 | backhaul link | | Wireless / Private \ 798 ----------------\ | Access ( net or ) 799 \ | \ Internet ) 800 \ \|/ | -------( /\ 801 \ | ad hoc | | (------) \--------- 802 \ | | / | Other | 803 \--|------------- /Satellite | nodes | 804 | Master node | / Link ---------- 805 | with |/ 806 | backhaul link | 807 ----------------- 809 Figure 6: Rapid deployed network with partly connected nodes 811 In the ad hoc network, all nodes are master nodes in a way that they 812 allocate RF channels from the white space database. However, the 813 backhaul link may not be available to all nodes, such as depicted for 814 the left node in the figure. To handle RF channel allocation for 815 such nodes, a master node with a backhaul link relays or proxies the 816 database query for them. So master nodes without a backhaul link 817 follow the procedure as defined for clients. The ad hoc network 818 radios utilise the provided RF channels. Details on forming and 819 maintenance of the ad hoc network, including repair of segmented 820 networks caused by segments operating on different RF channels, is 821 out of scope of spectrum allocation. 823 5. Problem Statement 825 The use of white space spectrum is enabled via the capability of a 826 device to query a database and obtain information about the 827 availability of spectrum for use at a given location. The databases 828 are reachable via the Internet and the devices querying these 829 databases are expected to have some form of Internet connectivity, 830 directly or indirectly. The databases may be country specific since 831 the available spectrum and regulations may vary, but the fundamental 832 operation of the protocol should be country independent. 834 An example high-level architecture of the devices and white space 835 databases is shown in the figure below: 837 ----------- 838 |WS Device| ------------ 839 |Lat: X |\ .---. /--------|Database X| 840 |Long: Y | \ ( ) / ------------ 841 ----------- \-------/ \/ o 842 ( Internet ) o 843 ----------- /------( )\ o 844 |WS Device| / (_____) \ ------------ 845 |Lat: X |/ \--------|Database Y| 846 |Long: Y | ------------ 847 ----------- 849 Figure 7: High level view of the White space database architecture 851 In the figure above, note that there could be multiple databases 852 serving white space devices. The databases are country specific 853 since the regulations and available spectrum may vary. In some 854 countries, for example, the U.S., the regulator has determined that 855 multiple, competing databases may provide service to White Space 856 Devices. 858 A messaging interface between the white space devices and the 859 database is required for operating a network using the white space 860 spectrum. The following sections discuss various aspects of such an 861 interface and the need for a standard. Other aspects of a solution 862 including provisioning the database, and calculating protected 863 contours are considered out of scope of the initial effort, as there 864 are significant differences between countries and spectrum bands. 866 5.1. Global applicability 868 The use of TV white space spectrum is currently approved by the FCC 869 in the United States. However regulatory bodies in other countries 870 are also considering similar use of available spectrum. The 871 principles of cognitive radio usage for such spectrum is generally 872 the same. Some of the regulatory details may vary on a country 873 specific basis. However the need for devices that intend to use the 874 spectrum to communicate with a database remains a common feature. 875 The database provides a known, specifiable Protection Contour for the 876 primary user, not dependent on the characteristics of the White Space 877 Device or it's ability to sense the primary use. It also provides a 878 way to specify a schedule of use, because some primary users (for 879 example, wireless microphones) only operate in limited time slots. 881 Devices need to be able to query a database, directly or indirectly 882 over the public Internet and/or private IP networks prior to 883 operating in available spectrum. Information about available 884 spectrum, schedule, power, etc. are provided by the database as a 885 response to the query from a device. The messaging interface needs 886 to be: 888 1. Radio/air interface agnostic - The radio/air interface technology 889 used by the white space device in available spectrum can be 890 802.11af, 802.16, 802.22, LTE etc. However the messaging 891 interface between the white space device and the database should 892 be agnostic to the air interface while being cognizant of the 893 characteristics of various air-interface technologies and the 894 need to include relevant attributes in the query to the database. 896 2. Spectrum agnostic - the spectrum used by primary and secondary 897 users varies by country. Some spectrum has an explicit notion of 898 a "channel" a defined swath of spectrum within a band that has 899 some assigned identifier. Other spectrum bands may be subject to 900 white space sharing, but only have actual frequency low/high 901 parameters to define protected entity use. The protocol should 902 be able to be used in any spectrum band where white space sharing 903 is permitted. 905 3. Globally applicable - A common messaging interface between white 906 space devices and databases will enable the use of such spectrum 907 for various purposes on a global basis. Devices can operate in 908 any country where such spectrum is available and a common 909 interface ensures uniformity in implementations and deployment. 910 Since the White Space device must know it's geospatial location 911 to do a query, it is possible to determine which database, and 912 which rules, are applicable, even though they are country 913 specific. 915 4. Address regulatory requirements - Each country will likely have 916 regulations that are unique to that country. The messaging 917 interface needs to be flexible to accommodate the specific needs 918 of a regulatory body in the country where the white space device 919 is operating and connecting to the relevant database. 921 5.2. Database discovery 923 Another aspect of the problem space is the need to discover the 924 database. A white space device needs to find the relevant database 925 to query based on its current location or for another location. 926 Since the spectrum and databases are country specific, the device 927 will need to discover the relevant database. The device needs to 928 obtain the IP address of the specific database to which it can send 929 queries in addition to registering itself for operation and using the 930 available spectrum. 932 5.3. Protocol 934 A protocol that enables a white space device to query a database to 935 obtain information about available channels is needed. A device may 936 be required to register with the database with some credentials prior 937 to being allowed to query. The requirements for such a protocol are 938 specified in this document. 940 5.4. Data model definition 942 The contents of the queries and response need to be specified. A 943 data model is required which enables the white space device to query 944 the database while including all the relevant information such as 945 geolocation, radio technology, power characteristics, etc. which may 946 be country and spectrum and regulatory dependent. All databases are 947 able to interpret the data model and respond to the queries using the 948 same data model that is understood by all devices. 950 Use of XML for specifying a data model is an attractive option. The 951 intent is to evaluate the best option that meets the need for use 952 between white space devices and databases. 954 6. Requirements 956 This section is the placeholder for the requirements derived from the 957 use cases. 959 7. IANA Considerations 961 This document has no requests to IANA. 963 8. Security Considerations 965 The messaging interface between the white space device and the 966 database needs to be secured. Both the queries and the responses 967 need to be delivered securely. The device must be certain it is 968 talking to a bona fide database authoritative for the location and 969 spectrum band the device operates on. The database may need to 970 restrict interactions to devices that it has some prior relationship 971 with, or may be restricted from providing service to devices that are 972 not authorized in some manner. 974 As the device will query with it's location, the location must be 975 protected against eavesdropping. Some regulations include personally 976 identifiable information as required elements of registration and/or 977 query and must similarly be protected. 979 All communications between the device and the database will require 980 integrity protection. 982 Man-in-the-middle attacks could modify the content of a response 983 which can cause problems for other networks or devices operating at a 984 given location. Interference as well as total loss of service could 985 result from malicious information being delivered to a white space 986 device. 988 9. Summary and Conclusion 990 Wireless spectrum is a scarce resource. As the demand for spectrum 991 grows, there is a need to more efficiently utilize the available and 992 allocated spectrum. Cognitive radio technologies enable the 993 efficient usage of spectrum via means such as sensing or by querying 994 a database to determine available spectrum at a given location for 995 secondary use. White space is the general term used to refer to the 996 bands within the spectrum which is available for secondary use at a 997 given location. In order to use this spectrum a device needs to 998 query a database which maintains information about the available 999 channels within a band. A protocol is necessary for communication 1000 between the devices and databases which would be globally applicable. 1002 The document describes some examples of the role of the white space 1003 database in the operation of a radio network and also shows an 1004 examples of a services provided to the user of a TVWS device. From 1005 these use cases requirements are determined. These requirements are 1006 to be used as input to the definition of a Protocol to Access White 1007 Space database (PAWS). 1009 10. Acknowledgements 1011 The authors acknowledge Gerald Chouinard and Teco Boot as 1012 contributors to this document. 1014 11. References 1016 11.1. Normative References 1018 [PAWS-PS] IETF, "Protocol to Access White Space database: Problem 1019 statement; https://datatracker.ietf.org/doc/ 1020 draft-patil-paws-problem-stmt/", July 2011. 1022 [RFC2119] IETF, "Key words for use in RFCs to Indicate Requirement 1023 Levels; 1024 http://www.rfc-editor.org/rfc/pdfrfc/rfc2119.txt.pdf", 1025 March 1997. 1027 11.2. Informative References 1029 [DDR] Ofcom - Independent regulator and competition authority 1030 for the UK communications industries, "Digital Dividend 1031 Review; http://stakeholders.ofcom.org.uk/spectrum/ 1032 project-pages/ddr/". 1034 [DTV] "Digital TV Transition; http://www.dtv.gov". 1036 [ECC Report 159] 1037 Electronic Communications Committee (ECC) within the 1038 European Conference of Postal and Telecommunications 1039 Administrations (CEPT), "TECHNICAL AND OPERATIONAL 1040 REQUIREMENTS FOR THE POSSIBLE OPERATION OF COGNITIVE RADIO 1041 SYSTEMS IN THE 'WHITE SPACES' OF THE FREQUENCY BAND 470- 1042 590 MHZ; http://www.erodocdb.dk/Docs/doc98/official/pdf/ 1043 ECCREP159.PDF", January 2011. 1045 [FCC Ruling] 1046 FCC, "Federal Communications Commission, "Unlicensed 1047 Operation in the TV Broadcast Bands; 1048 http://edocket.access.gpo.gov/2010/pdf/2010-30184.pdf"", 1049 December 2010. 1051 [RFC5222] IETF, Hardie, T., Netwon, A., Schulzrinne, H., and H. 1052 Tschofenig, "LoST: A Location-to-Service Translation Proto 1053 col;http://www.rfc-editor.org/rfc/pdfrfc/rfc5222.txt.pdf", 1054 August 2008. 1056 [Spectrum Framework Review] 1057 Ofcom - Independent regulator and competition authority 1058 for the UK communications industries, "Spectrum Framework 1059 Review; 1060 http://stakeholders.ofcom.org.uk/consultations/sfr/", 1061 February 2005. 1063 [TV Whitespace Tutorial Intro] 1064 IEEE 802 Executive Committee Study Group on TV White 1065 Spaces, "TV Whitespace Tutorial Intro; http:// 1066 grouper.ieee.org/groups/802/802_tutorials/2009-03/ 1067 2009-03-10%20TV%20Whitespace%20Tutorial%20r0.pdf", 1068 March 2009. 1070 Authors' Addresses 1072 Scott Probasco (editor) 1073 Nokia 1074 6021 Connection drive 1075 Irving, TX 75039 1076 USA 1078 Email: scott.probasco@nokia.com 1080 Gabor Bajko 1081 Nokia 1082 200 South Mathilda Ave 1083 Sunnyvale, CA 94086 1084 USA 1086 Email: gabor.bajko@nokia.com 1088 Basavaraj Patil 1089 Nokia 1090 6021 Connection drive 1091 Irving, TX 75039 1092 USA 1094 Email: basavaraj.patil@nokia.com 1095 Brian Rosen 1096 Neustar 1097 470 Conrad Dr 1098 Mars, PA 16046 1099 USA 1101 Email: brian.rosen@neustar.biz