idnits 2.17.00 (12 Aug 2021) /tmp/idnits57035/draft-probasco-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 (August 22, 2011) is 3918 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'PAWS-PS' is defined on line 939, but no explicit reference was found in the text == Unused Reference: 'RFC5222' is defined on line 972, 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: February 23, 2012 Nokia 6 B. Rosen 7 Neustar 8 August 22, 2011 10 Protocol to Access White Space database: PS, use cases and rqmts 11 draft-probasco-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 February 23, 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. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 7 76 4.1. Global applicability . . . . . . . . . . . . . . . . . . . 8 77 4.2. Database discovery . . . . . . . . . . . . . . . . . . . . 9 78 4.3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 10 79 4.4. Data model definition . . . . . . . . . . . . . . . . . . 10 80 5. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 10 81 5.1. TVWS database discovery . . . . . . . . . . . . . . . . . 10 82 5.2. Hotspot: urban internet connectivity service . . . . . . . 11 83 5.3. Wide-Area or Rural internet broadband access . . . . . . . 13 84 5.4. Offloading: moving traffic to a white space network . . . 15 85 5.5. TVWS for backhaul . . . . . . . . . . . . . . . . . . . . 17 86 5.6. Location based service usage scenario . . . . . . . . . . 18 87 6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 20 88 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 89 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 90 9. Summary and Conclusion . . . . . . . . . . . . . . . . . . . . 20 91 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 92 10.1. Normative References . . . . . . . . . . . . . . . . . . . 21 93 10.2. Informative References . . . . . . . . . . . . . . . . . . 21 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 96 1. Introduction 98 Wireless spectrum is a commodity that is regulated by governments. 99 The spectrum is used for various purposes, which include 100 entertainment (e.g. radio and television), communication (telephony 101 and Internet access), military (radars etc.) and, navigation 102 (satellite communication, GPS). Portions of the radio spectrum that 103 are allocated to a licensed, primary user but are unused or 104 unoccupied at specific locations and times are defined as "white 105 space". The concept of allowing secondary transmissions (licensed or 106 unlicensed) in white space is a technique to "unlock" existing 107 spectrum for new use. An obvious requirement is that these secondary 108 transmissions do not interfere with the primary use of the spectrum. 109 One interesting observation is that often, in a given physical 110 location, the primary user(s) may not be using the entire band 111 allocated to them. The available spectrum for a secondary use would 112 then depend on the location of the secondary user. The fundamental 113 issue is how to determine for a specific location and specific time, 114 if any of the primary spectrum is available for secondary use. 115 Academia and Industry have studied multiple cognitive radio 116 mechanisms for use in such a scenario. One simple mechanism is to 117 use a geospatial database that records the primary users occupation, 118 and require the secondary users to check the database prior to 119 selecting what part of the spectrum they use. Such databases could 120 be available on the Internet for query by secondary users. 122 Spectrum useable for data communications, especially wireless 123 Internet communications, is scarce. One area which has received much 124 attention globally is the TV white space: portions of the TV band 125 that are not used by broadcasters in a given area. In 2008 the 126 United States regulator (the FCC) took initial steps when they 127 published their first ruling on the use of TV white space, and then 128 followed it up with a final ruling in 2010[FCC Ruling]. Finland 129 passed an Act in 2009 enabling testing of cognitive radio systems in 130 the TV white space. The ECC has completed Report 159 [ECC Report 131 159] containing requirements for operation of cognitive radio systems 132 in the TV white space. Ofcom published in 2004 their Spectrum 133 Framework Review [Spectrum Framework Review] and their Digital 134 Dividend Review [DDR] in 2005, and have followed up with a proposal 135 to access TV white space. More countries are expected to provide 136 access to their TV spectrum in similar ways. Any entity holding 137 spectrum that is not densely used may be asked to give it up in one 138 way or another for more intensive use. Providing a mechanism by 139 which secondary users share the spectrum with the primary user is 140 attractive in many bands in many countries. 142 Television transmission until now has primarily been analog. The 143 switch to digital transmission has begun. As a result the spectrum 144 allocated for television transmission can now be more effectively 145 used. Unused channels and bands between channels can be used as long 146 as they do not interfere with the primary service for which that 147 channel is allocated. While urban areas tend to have dense usage of 148 spectrum and a number of TV channels, the same is not true in rural 149 and semi- urban areas. There can be a number of unused TV channels 150 in such areas that can be used for other services. The figure below 151 shows TV white space within the lower UHF band: 153 Avg | 154 usage| |-------------- White Space 155 | | | | | | 156 0.6| || || V V || 157 | || ||| | || 158 0.4| || |||| | || 159 | || |||| | ||<----TV transmission 160 0.2| || |||| | || 161 |---------------------------------------- 162 400 500 600 700 800 163 Frequency in MHz -> 165 Figure 1: High level view of TV White Space 167 The fundamental issue is how to determine for a specific location and 168 specific time if any of the spectrum is available for secondary use. 169 There are two dimensions of use that may be interesting: space (the 170 area in which a secondary user would not interfere with a primary 171 user, and time: when the secondary use would not interfere with the 172 primary use. In this discussion, we consider the time element to be 173 relatively long term (hours in a day) rather than short term 174 (fractions of a second). Location in this discussion is geolocation: 175 where the transmitters (and sometimes receivers) are located relative 176 to one another. In operation, the database records the existing 177 user's transmitter (and some times receiver) locations along with 178 basic transmission characteristics such as antenna height, and 179 sometimes power. Using rules established by the regulator, the 180 database calculates an exclusion zone for each authorized primary 181 user, and attaches a time schedule to that use. The secondary user 182 queries the database with it location. The database intersects the 183 exclusion zones with the queried location, and returns the portion of 184 the spectrum not in any exclusion zone. Such methods of geospatial 185 database query to avoid interference have been shown to achieve 186 favorable results, and are thus the basis for rulings by the FCC and 187 reports from ECC and Ofcom. In any country, the rules for which 188 primary entities are entitled to protection, how the exclusion zones 189 are calculated, and what the limits of use by secondary entities are 190 may vary. However, the fundamental notion of recording primary 191 users, calculating exclusion zones, querying by location and 192 returning available spectrum (and the schedule for that spectrum) are 193 common 195 This document includes the problem statement, use cases and 196 requirements associated with the use of white space spectrum by 197 secondary users via a database query protocol. 199 2. Conventions and Terminology 201 2.1. Conventions Used in This Document 203 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 204 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 205 document are to be interpreted as described in RFC 2119 [RFC2119]. 207 2.2. Terminology 209 Database 211 In the context of white space and cognitive radio technologies, 212 the database is an entity which contains current information about 213 available spectrum at any given location and other types of 214 information. 216 Location Based Service 218 An application or device which provides data, information or 219 service to a user based on their location. 221 Master Device 223 A device which queries the WS Database to find out the available 224 operating channels. 226 Protected Entity 228 A primary user of white space spectrum which is afforded 229 protection against interference by secondary users (white space 230 devices) for its use in a given area and time. 232 Protected Contour 234 The exclusion area for a Protected Entity, held in the database 235 and expressed as a polygon with geospatial points as the vertices. 237 Slave Device 239 A device which uses the spectrum made available by a master 240 device. 242 TV White Space 244 TV white space refers specifically to radio spectrum which has 245 been allocated for TV broadcast, but is not occupied by a TV 246 broadcast, or other licensed user (such as a wireless microphone), 247 at a specific location and time. 249 White Space 251 Radio spectrum which has been allocated for some primary use, but 252 is not fully occupied by that primary use at a specific location 253 and time. 255 White Space Device 257 A device which is a secondary user of some part of white space 258 spectrum. A white space device can be an access point, base 259 station, a portable device or similar. In this context, a white 260 space device is required to query a database with its location to 261 obtain information about available spectrum. 263 3. Prior Work 265 3.1. The concept of Cognitive Radio 267 A cognitive radio uses knowledge of the local radio environment to 268 dynamically adapt its own configuration and function properly in a 269 changing radio environment. Knowledge of the local radio environment 270 can come from various technology mechanisms including sensing 271 (attempting to ascertain primary users by listening for them within 272 the spectrum), location determination and internet connectivity to a 273 database to learn the details of the local radio environment. TV 274 White Space is one implementation of cognitive radio. Because a 275 cognitive radio adapts itself to the available spectrum in a manner 276 that prevents the creation of harmful interference, the spectrum can 277 be shared among different radio users. 279 3.2. Background information on white space in US 281 Television transmission in the United States has moved to the use of 282 digital signals as of June 12, 2009. Since June 13, 2009, all full- 283 power U.S. television stations have broadcast over-the-air signals in 284 digital only. An important benefit of the switch to all-digital 285 broadcasting is that it freed up parts of the valuable broadcast 286 spectrum. More information about the switch to digital transmission 287 is at : [DTV]. 289 With the switch to digital transmission for TV, the guard bands that 290 existed to protect the signals between stations can now be used for 291 other purposes. The FCC has made this spectrum available for 292 unlicensed use and this is generally referred to as white space. 293 Please see the details of the FCC ruling and regulations in [FCC 294 Ruling]. The spectrum can be used to provide wireless broadband as 295 an example. The term "Super-Wifi" is also used to describe this 296 spectrum and potential for providing wifi type of service. 298 3.3. Air Interfaces 300 Efforts are ongoing to specify air-interfaces for use in white space 301 spectrum. IEEEs 802.11af task group is currently working on one such 302 specification. IEEE 802.22 is another example. Other air interfaces 303 could be specified in the future such as LTE. 305 4. Problem Statement 307 The use of white space spectrum is enabled via the capability of a 308 device to query a database and obtain information about the 309 availability of spectrum for use at a given location. The databases 310 are reachable via the Internet and the devices querying these 311 databases are expected to have some form of Internet connectivity, 312 directly or indirectly. The databases may be country specific since 313 the available spectrum and regulations may vary, but the fundamental 314 operation of the protocol should be country independent. 316 An example high-level architecture of the devices and white space 317 databases is shown in the figure below: 319 ----------- 320 |WS Device| ------------ 321 |Lat: X |\ .---. /--------|Database X| 322 |Long: Y | \ ( ) / ------------ 323 ----------- \-------/ \/ o 324 ( Internet ) o 325 ----------- /------( )\ o 326 |WS Device| / (_____) \ ------------ 327 |Lat: X |/ \--------|Database Y| 328 |Long: Y | ------------ 329 ----------- 331 Figure 2: High level view of the White space database architecture 333 In the figure above, note that there could be multiple databases 334 serving white space devices. The databases are country specific 335 since the regulations and available spectrum may vary. In some 336 countries, for example, the U.S., the regulator has determined that 337 multiple, competing databases may provide service to White Space 338 Devices. 340 A messaging interface between the white space devices and the 341 database is required for operating a network using the white space 342 spectrum. The following sections discuss various aspects of such an 343 interface and the need for a standard. Other aspects of a solution 344 including provisioning the database, and calculating protected 345 contours are considered out of scope of the initial effort, as there 346 are significant differences between countries and spectrum bands. 348 4.1. Global applicability 350 The use of TV white space spectrum is currently approved by the FCC 351 in the United States. However regulatory bodies in other countries 352 are also considering similar use of available spectrum. The 353 principles of cognitive radio usage for such spectrum is generally 354 the same. Some of the regulatory details may vary on a country 355 specific basis. However the need for devices that intend to use the 356 spectrum to communicate with a database remains a common feature. 357 The database provides a known, specifiable Protection Contour for the 358 primary user, not dependent on the characteristics of the White Space 359 Device or it's ability to sense the primary use. It also provides a 360 way to specify a schedule of use, because some primary users (for 361 example, wireless microphones) only operate in limited time slots. 363 Devices need to be able to query a database, directly or indirectly 364 over the public Internet and/or private IP networks prior to 365 operating in available spectrum. Information about available 366 spectrum, schedule, power, etc. are provided by the database as a 367 response to the query from a device. The messaging interface needs 368 to be: 370 1. Radio/air interface agnostic - The radio/air interface technology 371 used by the white space device in available spectrum can be 372 802.11af, 802.16, 802.22, LTE etc. However the messaging 373 interface between the white space device and the database should 374 be agnostic to the air interface while being cognizant of the 375 characteristics of various air-interface technologies and the 376 need to include relevant attributes in the query to the database. 378 2. Spectrum agnostic - the spectrum used by primary and secondary 379 users varies by country. Some spectrum has an explicit notion of 380 a "channel" a defined swath of spectrum within a band that has 381 some assigned identifier. Other spectrum bands may be subject to 382 white space sharing, but only have actual frequency low/high 383 parameters to define protected entity use. The protocol should 384 be able to be used in any spectrum band where white space sharing 385 is permitted. 387 3. Globally applicable - A common messaging interface between white 388 space devices and databases will enable the use of such spectrum 389 for various purposes on a global basis. Devices can operate in 390 any country where such spectrum is available and a common 391 interface ensures uniformity in implementations and deployment. 392 Since the White Space device must know it's geospatial location 393 to do a query, it is possible to determine which database, and 394 which rules, are applicable, even though they are country 395 specific. 397 4. Address regulatory requirements - Each country will likely have 398 regulations that are unique to that country. The messaging 399 interface needs to be flexible to accommodate the specific needs 400 of a regulatory body in the country where the white space device 401 is operating and connecting to the relevant database. 403 4.2. Database discovery 405 Another aspect of the problem space is the need to discover the 406 database. A white space device needs to find the relevant database 407 to query based on its current location or for another location. 408 Since the spectrum and databases are country specific, the device 409 will need to discover the relevant database. The device needs to 410 obtain the IP address of the specific database to which it can send 411 queries in addition to registering itself for operation and using the 412 available spectrum. 414 4.3. Protocol 416 A protocol that enables a white space device to query a database to 417 obtain information about available channels is needed. A device may 418 be required to register with the database with some credentials prior 419 to being allowed to query. The requirements for such a protocol are 420 specified in this document. 422 4.4. Data model definition 424 The contents of the queries and response need to be specified. A 425 data model is required which enables the white space device to query 426 the database while including all the relevant information such as 427 geolocation, radio technology, power characteristics, etc. which may 428 be country and spectrum and regulatory dependent. All databases are 429 able to interpret the data model and respond to the queries using the 430 same data model that is understood by all devices. 432 Use of XML for specifying a data model is an attractive option. The 433 intent is to evaluate the best option that meets the need for use 434 between white space devices and databases. 436 5. Use cases 438 There are many potential use cases that could be considered for the 439 TV white space spectrum. Providing broadband internet access in 440 hotspots, rural and underserved areas are examples. Available 441 channels may also be used to provide internet 'backhaul' for 442 traditional Wi-Fi hotspots, or by towns and cities to monitor/control 443 traffic lights or read utility meters. Still other use cases include 444 the ability to offload data traffic from another internet access 445 network (e.g. 3G cellular network) or to deliver location based 446 services. Some of these use cases are described in the following 447 sections. 449 5.1. TVWS database discovery 451 This use case is preliminary to creating a radio network using TV 452 white space; it is a prerequisite to other use cases. The radio 453 network is created by a master device which can be an access point 454 that establishes Hotspot coverage, a base station that establish 455 cellular coverage, or a device that establishes a peer-to-peer or ad- 456 hoc network. Before the master device can transmit in TV white space 457 spectrum, it must contact a trusted database where the device can 458 learn if any channels are available for it to use. 460 In the simplest case the radio device is pre-programmed with the 461 internet address of at least one trusted database. The device can 462 establish contact with a trusted database using one of the pre- 463 programmed internet addresses and establish a TV white space network 464 (as described in one of the following use cases). 466 If the radio device (master) does not have a pre-programmed address 467 for a trusted white space database, or if the trusted database at the 468 pre-programmed address is not responsive, or perhaps the trusted 469 database does not provide service for the radio device's current 470 location, or at the user's choice, the device may attempt to 471 "discover" a trusted database which provides service at the current 472 location. 474 1. The master is connected to the internet by any means other than 475 using the TV white space radio. 477 2. The master constructs and broadcasts a query message over the 478 internet and waits for responses. 480 3. If no acceptable response is received within a pre-configured 481 time limit, the device concludes that no trusted database is 482 available. If one or more response is received, the device 483 evaluates the response to determine if a trusted database can be 484 identified where the device is able to register and receive 485 service from the database. 487 5.2. Hotspot: urban internet connectivity service 489 In this use case internet connectivity service is provided in a 490 "hotspot" to local users. Typical deployment scenarios include urban 491 areas where internet connectivity is provided to local businesses and 492 residents, and campus environments where internet connectivity is 493 provided to local buildings and relatively small outdoor areas. This 494 deployment scenario is typically characterized by multiple masters 495 (APs or hotspots) in close proximity, with low antenna height, cells 496 with relatively small radius (a few kilometers or less), and limited 497 numbers of available radio channels. Many of the masters/APs are 498 assumed to be individually deployed and operated, i.e. there is no 499 coordination between many of the masters/APs. The masters/APs in 500 this scenario use a TDD radio technology and transmit at or below a 501 relatively low transmit power threshold. Each master/AP has a 502 connection to the internet and provides internet connectivity to 503 multiple end user or slave devices. 505 The figure below shows an example deployment of this scenario. 507 ------- 508 |Slave|\ \|/ ---------- 509 |Dev 1| (TDD AirIF) | |Database| 510 ------- \ | .---. /--------- 511 o \ |-|---------| ( ) / 512 o | Master | / \ 513 o / | |========( Internet ) 514 o / |-----------| \ / 515 ------- (TDD AirIF) ( ) 516 |Slave| / (----) 517 |Dev n| 518 ------- 520 Figure 3: Hotspot service using TV white space spectrum 522 Once a master/AP has been correctly installed and configured, a 523 simplified power up and operation scenario utilizing TV White Space 524 to provide Internet connectivity service consists of the following 525 steps: 527 1. The master/AP powers up; however its WS radio and all other WS 528 capable devices will power up in idle/listen only mode (no active 529 transmissions on the WS frequency band). 531 2. The master/AP has Internet connectivity and establishes a 532 connection to a trusted white space database (see use case "TVWS 533 database discovery" above). 535 3. The master/AP registers its geolocation, address, contact 536 information, etc. associated with the owner/operator of the 537 master/AP with the trusted database administrator (if not 538 currently registered). Depending upon local regulator policy, 539 the DB administrator may be required to store and forward the 540 registration information to the regulatory authority. 542 4. Following the registration process, the master/AP will send a 543 query to the trusted database requesting a list of available WS 544 channels based upon its geolocation. 546 5. If the master/AP has been previously authenticated, the database 547 responds with a list of available white space channels that the 548 master may use, and optionally a duration of time for their use. 550 6. Once the master/AP authenticates the WS channel list response 551 message from the database, the AP selects an available WS 552 channel(s) from the list. 554 7. The master/AP acknowledges to the database which of the available 555 WS channels it has selected for its operation. The database is 556 updated with the information provided by the master/AP. 558 8. The slave or user device scans the TV bands to locate a master/AP 559 transmission, and associates with the AP. The slave/user device 560 queries the master for a channel list, based on the slaves' 561 geolocation. 563 9. The master provides the list of channels locally available to the 564 slave/user device. If the channel that the user terminal is 565 currently using is not included in the list of locally available 566 channels, the slave/user device ceases all operation on its 567 current channel. The slave/user device may scan for another AP 568 transmission on a different channel. 570 5.3. Wide-Area or Rural internet broadband access 572 In this use case internet broadband access is provided as a Wide-Area 573 Network (WAN) or Wireless Regional Area Network (WRAN). A typical 574 deployment scenario is a wide area or rural area, where internet 575 broadband access is provided to local businesses and residents from a 576 master (i.e. BS) connected to the internet. This deployment 577 scenario is typically characterized by one or more fixed master(s)/ 578 BS(s), cells with relatively large radius (tens kilometers up to 100 579 km), and many available radio channels. Many of the masters/BSs are 580 assumed to be deployed and operated by a single entity, i.e. there is 581 coordination between many of the masters/BSs. The BS in this 582 scenario use a TDD radio technology and transmit at or below a 583 transmit power threshold established by the local regulator. Each 584 base station has a connection to the internet and provides internet 585 connectivity to multiple slave/end-user devices. End user terminals 586 or devices may be fixed or portable. 588 The figure below shows an example deployment of this scenario. 590 ------- 591 |Slave|\ \|/ ---------- 592 |Dev 1| (TDD AirIF) | |Database| 593 ------- \ | .---. /---------- 594 o \ |-|---------| ( ) / 595 o | Master | / \ 596 o / | (BS) |========( Internet ) 597 o / |-----------| \ / 598 ------- (TDD AirIF) ( ) 599 |Slave| / (----) 600 |Dev n| 601 ------- 603 Figure 4: Rural internet broadband access using TV white space 604 spectrum 606 Once the master/BS has been professionally installed and configured, 607 a simplified power up and operation scenario utilizing TV White Space 608 to provide rural internet broadband access consists of the following 609 steps: 611 1. The master/BS powers up; however its WS radio and all other WS 612 capable devices will power up in idle/listen only mode (No active 613 transmissions on the WS frequency band) 615 2. The master/BS has internet connectivity and establishes a 616 connection to a trusted white space database (see use case "TVWS 617 database discovery" above). 619 3. The master/BS registers its geolocation, address, contact 620 information, etc. associated with the owner/operator of the 621 master/BS with the trusted database service (if not currently 622 registered). Meanwhile the DB administrator may be required to 623 store and forward the registration information to the regulatory 624 authority. If a trusted white space database administrator is 625 not discovered, further operation of the WRAN may be allowed 626 according to local regulator policy (in this case operation of 627 the WRAN is outside the scope of the PAWS protocol). 629 4. Following the registration process, the master/BS will send a 630 query to the trusted database requesting a list of available WS 631 channels based upon its geolocation. 633 5. If the master/BS has been previously authenticated, the database 634 responds with a list of available white space channels that may 635 be used and optionally a maximum transmit power (EIRP) for each 636 channel and a duration of time the channel may be used. 638 6. Once the master/BS authenticates the WS channel list response 639 message from the database, the master/BS selects an available WS 640 channel(s) from the list. The operator may disallow some 641 channels from the list to suit local needs if required. 643 7. The master/BS acknowledges to the database which of the available 644 WS channels the BS has selected for its operation. The database 645 is updated with the information provided by the BS. 647 8. The slave or user device scans the TV bands to locate a WRAN 648 transmission, and associates with the master/BS. The slave/user 649 device queries the master for a channel list, based on the 650 slaves' geolocation. 652 9. The master provides the list of channels locally available to the 653 slave/user device. If the channel that the user terminal is 654 currently using is not included in the list of locally available 655 channels, the slave/user device ceases all operation on its 656 current channel. The slave/user device may scan for another WRAN 657 transmission on a different channel. 659 5.4. Offloading: moving traffic to a white space network 661 In this use case internet connectivity service is provided over TV 662 white space as a supplemental or alternative datapath to a 3G or 663 other internet connection. In a typical deployment scenario an end 664 user has a primary internet connection such as a 3G cellular packet 665 data subscription. The user wants to use a widget or application to 666 stream video from an online service (e.g. youtube) to their device. 667 Before the widget starts the streaming connection it checks 668 connectivity options available at the current time and location. 669 Both 3G cellular data is available as well as TVWS connectivity (the 670 user is within coverage of a TVWS master -- hotspot, WAN, WRAN or 671 similar). The user may decide for many and various reasons such as 672 cost, RF coverage, data caps, etc. to prefer the TVWS connection over 673 the 3G cellular data connection. Either by user selection, 674 preconfigured preferences, or other algorithm, the streaming session 675 is started over the TVWS internet connection instead of the 3G 676 cellular connection. This deployment scenario is typically 677 characterized by a TVWS master/AP providing local coverage in the 678 same geographical area as a 3G cellular system. The master/AP is 679 assumed to be individually deployed and operated, i.e. the master/AP 680 is deployed and operated by the user at his home or perhaps by a 681 small business such as a coffee shop. The master/AP has a connection 682 to the internet and provides internet connectivity to the slave/ 683 end-user's device. 685 The figure below shows an example deployment of this scenario. 687 \|/ 688 | 689 | 690 |-|---------| 691 | Master/AP |\ 692 /| Router | \ 693 Streaming/ |-----------| \ 694 -------- / \ ----------- 695 |Slave/| / \ (----) | Database | 696 |WS Dev| \ ( ) /---------- 697 ------- \ \ / \ 698 \ X( Internet ) 699 \ / \ / 700 Signaling \|/ / ( )\ 701 \ | / (----) \---------- 702 \ | / | YouTube | 703 \|-|---------| / ---------- 704 | Master / | / 705 | 3G BTS |/ 706 |-----------| 708 Figure 5: Offloading: moving traffic to a white space network 710 Once a dual or multi mode device (3G + TVWS) is connected to a 3G 711 network, a simplified operation scenario of offloading selected 712 content such as video stream from the 3G connection to the TWVS 713 connection consists of the following steps: 715 1. The dual mode (or multi mode) device (3G + TVWS) is connected to 716 a 3G network. The device has contacted a trusted database to 717 discover the list of available TV channels at is current 718 location. The device has located a TVWS master/AP operating on 719 an available channel and has associated or connected with the 720 TVWS master/AP. 722 2. The user activates a widget or application that streams video 723 from YouTube. The widget connects to YouTube over 3G cellular 724 data. The user browses content and searches for video 725 selections. 727 3. The user selects a video for streaming using the widget's 728 controls. Before the widget initiates a streaming session, the 729 widget checks the available connections in the dual mode device 730 and finds a TVWS master/AP is connected. 732 4. Using either input from the user or pre-defined profile 733 preferences, the widget selects the TVWS master/AP as the 734 connection to stream the video. 736 5.5. TVWS for backhaul 738 In this use case internet connectivity service is provided to users 739 over a traditional wireless protocol, one common example is Wi-Fi. 740 The TV white space network provides the "backhaul" or connection from 741 the Wi-Fi to the internet. In a typical deployment scenario an end 742 user has a device with a radio such as Wi-Fi. A service provider or 743 shop owner wants to provide Wi-Fi internet service for their 744 customers. The location where the service provider wants to provide 745 Wi-Fi is within range of a TVWS master (e.g. Hotspot or Wide-Area/ 746 Rural network). The service provider installs a TVWS slave device 747 and connect this slave to a Wi-Fi access point. This deployment 748 scenario is typically characterized by a TVWS master/AP/BS providing 749 local coverage. The master/AP has a connection to the internet and 750 provides internet connectivity to the slave device. The slave device 751 is then 'bridged' to a Wi-Fi network 753 The figure below shows an example deployment of this scenario. 755 \|/ white \|/ \|/ WiFi \|/ 756 | space | | | 757 | | | |-|----| 758 |--------| |-|---------| |-|------|-| | WiFi | 759 | | | Master | | Slave | | Dev | 760 |internet|------| (AP/BS) | | Bridge | |------| 761 | | | | | to WiFi | 762 |--------| |-----------| |----------| \|/ 763 | 764 |-|----| 765 | WiFi | 766 | Dev | 767 |------| 769 Figure 6: TVWS for backhaul 771 Once the bridged device (TVWS+WiFi) is connected to a master and TVWS 772 network, a simplified operation scenario of backhaul for WiFi 773 consists of the following steps: 775 1. A bridged device (TVWS+WiFi) is connected to a master device 776 operating in the TVWS. The bridged device operates as a slave 777 device in either Hotspot or Wide-Area/Rural internet use cases 778 described above. 780 2. Once the slave device is connected to the master, the Wi-Fi 781 access point configures its internet settings automatically based 782 on the backhaul connection (i.e. it uses DHCP). 784 3. End users connect their WiFi device to the bridged device and 785 receive internet connectivity. 787 5.6. Location based service usage scenario 789 The owner of a shopping mall wants to provide internet access to 790 customers when they are at the shopping mall. His internet service 791 provider (ISP) recommends using master/AP devices in the TV white 792 space frequency band since these radios will have good propagation 793 characteristics, and thus will require fewer devices, and also 794 because the frequency band used by traditional Wi-Fi is crowded with 795 users such as individual stores operating their own Wi-Fi network and 796 also Bluetooth devices. The ISP installs APs in each large store in 797 the mall, and several other APs throughout the mall building. For 798 each AP, the professional installer programs the location (latitude 799 and longitude) of the device. Special tools are required to 800 determine the location, since typical GPS receivers do not function 801 indoors. When each AP is powered on, the radio does not transmit 802 initially. The AP contacts a white space database, using its wired 803 internet connection, via a URL and provides its programmed location 804 coordinates plus other information required by the database. A reply 805 is received by the AP from the database containing a list of 806 available channels where the AP can operate its transmitter. The AP 807 selects a channel for operation and notifies the database, which 808 records information about the AP including the identity of the AP and 809 its location coordinates. The AP activates its radio and begins to 810 function as a typical wireless AP, providing internet access to 811 connected devices. 813 A user has a slave device that is capable of operating in the TV 814 white spaces frequency band. A typical device would be a smartphone 815 with multiple radios, including a cellular radio, a Wi-Fi radio, and 816 TV white space radio. The user arrives at the shopping mall and 817 enters the building. The white space radio in the smartphone is on, 818 and is scanning for a master/AP. As the user gets near the entrance 819 to the shopping mall, the smartphone locates one of the APs in the 820 building and connects to it. The smartphone begins to use this TVWS 821 radio for internet access. This internet access does not count 822 against the users cellular data cap (the mall owner is providing the 823 internet access) and also the data rates are better than cellular 824 data. As the user walks throughout the mall the smartphone moves 825 between coverage of different APs, and the smartphone connects to a 826 new AP when the user and smartphone move near it. 828 In order to encourage customers to come to the shopping mall, the 829 mall owner has a loyalty program where members register, build 830 points, and receive coupons and other notices from the shops in the 831 mall. Before installing the internet service in the mall, all 832 loyalty program information was mailed to the user, at an address 833 which was provided by the user when joining the loyalty program. 835 The ISP provider describes to the mall owner how the loyalty program 836 can be improved using the internet service provided by the APs in the 837 TV white space. A new app is developed for this loyalty program, and 838 promoted to users, asking them to install the app on their 839 smartphone. The app is provisioned with the user's loyalty program 840 information. When the user comes to the shopping mall, the 841 smartphone locates the master/AP providing internet service and 842 connects to the AP. The app in the smartphone sees that a radio 843 connection to an AP in the TV white space frequency band is now 844 active. The app registers the identity of the AP and forwards this 845 to the home server for the loyalty program, using the internet 846 connection provided by the AP in the TV white space band. The 847 loyalty program server registers the identity of the user from the 848 loyalty program credentials and also the identity of the AP. Next 849 the loyalty program server contacts the TV white space database and 850 requests the location of the master/AP having the identity forwarded 851 by the app and smartphone. When the TV white space database replies 852 with the location coordinates of the AP, the loyalty program server 853 knows the approximate location of the user and smartphone. With this 854 location information, the loyalty program server can now forward 855 loyalty program information to the user. As the user moves through 856 the mall, the smartphone connects to different APs. The process is 857 repeated, allowing the loyalty program to delivery current location 858 based information to the user. 860 1. The master create a TVWS network as described in use case 861 "Hotspot: urban internet connectivity service." 863 2. An application running on the user's slave device (e.g. 864 smartphone) determines that a network connection exists in the 865 TVWS band. The identify of the master/AP is recorded by the 866 application and forwarded to a server in the internet cloud. 868 3. The server queries the trusted white space database with the 869 master identity provided by the application in the user's 870 smartphone. 872 4. The trusted white space database replies to the server with the 873 location of the master device. 875 5. The server uses the location of the master/AP to determine the 876 approximate location of the user's smartphone. The server 877 provides location-specific service to the user via the 878 application running in the smartphone. 880 6. Requirements 882 This section is the placeholder for the requirements derived from the 883 use cases. 885 7. IANA Considerations 887 This document has no requests to IANA. 889 8. Security Considerations 891 The messaging interface between the white space device and the 892 database needs to be secured. Both the queries and the responses 893 need to be delivered securely. The device must be certain it is 894 talking to a bona fide database authoritative for the location and 895 spectrum band the device operates on. The database may need to 896 restrict interactions to devices that it has some prior relationship 897 with, or may be restricted from providing service to devices that are 898 not authorized in some manner. 900 As the device will query with it's location, the location must be 901 protected against eavesdropping. Some regulations include personally 902 identifiable information as required elements of registration and/or 903 query and must similarly be protected. 905 All communications between the device and the database will require 906 integrity protection. 908 Man-in-the-middle attacks could modify the content of a response 909 which can cause problems for other networks or devices operating at a 910 given location. Interference as well as total loss of service could 911 result from malicious information being delivered to a white space 912 device. 914 9. Summary and Conclusion 916 Wireless spectrum is a scarce resource. As the demand for spectrum 917 grows, there is a need to more efficiently utilize the available and 918 allocated spectrum. Cognitive radio technologies enable the 919 efficient usage of spectrum via means such as sensing or by querying 920 a database to determine available spectrum at a given location for 921 secondary use. White space is the general term used to refer to the 922 bands within the spectrum which is available for secondary use at a 923 given location. In order to use this spectrum a device needs to 924 query a database which maintains information about the available 925 channels within a band. A protocol is necessary for communication 926 between the devices and databases which would be globally applicable. 928 The document describes some examples of the role of the white space 929 database in the operation of a radio network and also shows an 930 examples of a services provided to the user of a TVWS device. From 931 these use cases requirements are determined. These requirements are 932 to be used as input to the definition of a Protocol to Access White 933 Space database (PAWS). 935 10. References 937 10.1. Normative References 939 [PAWS-PS] IETF, "Protocol to Access White Space database: Problem 940 statement; https://datatracker.ietf.org/doc/ 941 draft-patil-paws-problem-stmt/", July 2011. 943 [RFC2119] IETF, "Key words for use in RFCs to Indicate Requirement 944 Levels; 945 http://www.rfc-editor.org/rfc/pdfrfc/rfc2119.txt.pdf", 946 March 1997. 948 10.2. Informative References 950 [DDR] Ofcom - Independent regulator and competition authority 951 for the UK communications industries, "Digital Dividend 952 Review; http://stakeholders.ofcom.org.uk/spectrum/ 953 project-pages/ddr/". 955 [DTV] "Digital TV Transition; http://www.dtv.gov". 957 [ECC Report 159] 958 Electronic Communications Committee (ECC) within the 959 European Conference of Postal and Telecommunications 960 Administrations (CEPT), "TECHNICAL AND OPERATIONAL 961 REQUIREMENTS FOR THE POSSIBLE OPERATION OF COGNITIVE RADIO 962 SYSTEMS IN THE 'WHITE SPACES' OF THE FREQUENCY BAND 470- 963 590 MHZ; http://www.erodocdb.dk/Docs/doc98/official/pdf/ 964 ECCREP159.PDF", January 2011. 966 [FCC Ruling] 967 FCC, "Federal Communications Commission, "Unlicensed 968 Operation in the TV Broadcast Bands; 969 http://edocket.access.gpo.gov/2010/pdf/2010-30184.pdf"", 970 December 2010. 972 [RFC5222] IETF, Hardie, T., Netwon, A., Schulzrinne, H., and H. 973 Tschofenig, "LoST: A Location-to-Service Translation Proto 974 col;http://www.rfc-editor.org/rfc/pdfrfc/rfc5222.txt.pdf", 975 August 2008. 977 [Spectrum Framework Review] 978 Ofcom - Independent regulator and competition authority 979 for the UK communications industries, "Spectrum Framework 980 Review; 981 http://stakeholders.ofcom.org.uk/consultations/sfr/", 982 February 2005. 984 [TV Whitespace Tutorial Intro] 985 IEEE 802 Executive Committee Study Group on TV White 986 Spaces, "TV Whitespace Tutorial Intro; http:// 987 grouper.ieee.org/groups/802/802_tutorials/2009-03/ 988 2009-03-10%20TV%20Whitespace%20Tutorial%20r0.pdf", 989 March 2009. 991 Authors' Addresses 993 Scott Probasco (editor) 994 Nokia 995 6021 Connection drive 996 Irving, TX 75039 997 USA 999 Email: scott.probasco@nokia.com 1001 Gabor Bajko 1002 Nokia 1003 200 South Mathilda Ave 1004 Sunnyvale, CA 94086 1005 USA 1007 Email: gabor.bajko@nokia.com 1008 Basavaraj Patil 1009 Nokia 1010 6021 Connection drive 1011 Irving, TX 75039 1012 USA 1014 Email: basavaraj.patil@nokia.com 1016 Brian Rosen 1017 Neustar 1018 470 Conrad Dr 1019 Mars, PA 16046 1020 USA 1022 Email: brian.rosen@neustar.biz