idnits 2.17.1 draft-vchen-paws-protocol-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 3, 2012) is 4222 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO3166-1' ** Obsolete normative reference: RFC 5077 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) == Outdated reference: A later version (-15) exists of draft-ietf-paws-problem-stmt-usecases-rqmts-08 -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PAWS V. Chen, Ed. 3 Internet-Draft Google 4 Intended status: Standards Track S. Das 5 Expires: April 6, 2013 Applied Communication Sciences 6 Z. Lei 7 Huawei 8 J. Malyar 9 Telcordia Technologies Inc. 10 P. McCann 11 Huawei 12 October 3, 2012 14 Protocol to Access Spectrum Database 15 draft-vchen-paws-protocol-00 17 Abstract 19 Portions of the radio spectrum that are allocated to licensees are 20 available for non-interfering use. This available spectrum is called 21 "White Space." Allowing secondary users access to available spectrum 22 "unlocks" existing spectrum to maximize its utilization and to 23 provide opportunities for innovation, resulting in greater overall 24 spectrum utilization. 26 One approach to manage spectrum sharing uses databases to report 27 spectrum availability to devices. To achieve interoperability among 28 multiple devices and databases, a standardized protocol must be 29 defined and implemented. This document defines such a protocol, the 30 "Protocol to Access White Space database" (PAWS). 32 Status of this Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on April 6, 2013. 49 Copyright Notice 51 Copyright (c) 2012 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 68 2.1. Conventions Used in This Document . . . . . . . . . . . . 4 69 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 70 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5 71 4. Protocol Functionalities . . . . . . . . . . . . . . . . . . . 6 72 4.1. Indicating Errors . . . . . . . . . . . . . . . . . . . . 6 73 4.2. Database Discovery . . . . . . . . . . . . . . . . . . . . 6 74 4.3. Initialization . . . . . . . . . . . . . . . . . . . . . . 7 75 4.3.1. INIT_REQ . . . . . . . . . . . . . . . . . . . . . . . 7 76 4.3.2. INIT_RESP . . . . . . . . . . . . . . . . . . . . . . 8 77 4.4. Device Registration . . . . . . . . . . . . . . . . . . . 9 78 4.4.1. REGISTRATION_REQ . . . . . . . . . . . . . . . . . . . 9 79 4.4.2. REGISTRATION_RESP . . . . . . . . . . . . . . . . . . 10 80 4.5. Available Spectrum Query . . . . . . . . . . . . . . . . . 10 81 4.5.1. AVAIL_SPECTRUM_REQ . . . . . . . . . . . . . . . . . . 13 82 4.5.2. AVAIL_SPECTRUM_RESP . . . . . . . . . . . . . . . . . 14 83 4.5.3. AVAIL_SPECTRUM_BATCH_REQ . . . . . . . . . . . . . . . 15 84 4.5.4. AVAIL_SPECTRUM_BATCH_RESP . . . . . . . . . . . . . . 16 85 4.5.5. SPECTRUM_USE_NOTIFY . . . . . . . . . . . . . . . . . 18 86 4.5.6. SPECTRUM_USE_RESP . . . . . . . . . . . . . . . . . . 19 87 4.6. Device Validation . . . . . . . . . . . . . . . . . . . . 19 88 4.6.1. DEV_VALID_REQ . . . . . . . . . . . . . . . . . . . . 21 89 4.6.2. DEV_VALID_RESP . . . . . . . . . . . . . . . . . . . . 21 90 5. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 22 91 5.1. ProtocolInfo . . . . . . . . . . . . . . . . . . . . . . . 22 92 5.2. ResponseInfo . . . . . . . . . . . . . . . . . . . . . . . 22 93 5.3. GeoLocation . . . . . . . . . . . . . . . . . . . . . . . 23 94 5.3.1. Regulatory Specifics . . . . . . . . . . . . . . . . . 23 95 5.4. DeviceIdentifier . . . . . . . . . . . . . . . . . . . . . 24 96 5.4.1. Regulatory Specifics . . . . . . . . . . . . . . . . . 24 97 5.5. AntennaCharacteristics . . . . . . . . . . . . . . . . . . 25 98 5.5.1. Regulatory Specifics . . . . . . . . . . . . . . . . . 25 99 5.6. DeviceCapabilities . . . . . . . . . . . . . . . . . . . . 25 100 5.7. DeviceOwner . . . . . . . . . . . . . . . . . . . . . . . 26 101 5.8. RulesetInfo . . . . . . . . . . . . . . . . . . . . . . . 27 102 5.8.1. RegulatorySpecifics . . . . . . . . . . . . . . . . . 27 103 5.9. Spectrum . . . . . . . . . . . . . . . . . . . . . . . . . 28 104 5.10. FrequencyRange . . . . . . . . . . . . . . . . . . . . . . 28 105 5.11. EventTime . . . . . . . . . . . . . . . . . . . . . . . . 29 106 5.12. SpectrumSchedule . . . . . . . . . . . . . . . . . . . . . 29 107 5.13. GeoSpectrumSchedule . . . . . . . . . . . . . . . . . . . 30 108 5.14. DeviceValidity . . . . . . . . . . . . . . . . . . . . . . 30 109 5.15. Response Codes . . . . . . . . . . . . . . . . . . . . . . 31 110 6. Message Encoding . . . . . . . . . . . . . . . . . . . . . . . 31 111 7. HTTPS Binding . . . . . . . . . . . . . . . . . . . . . . . . 31 112 8. Example Messages . . . . . . . . . . . . . . . . . . . . . . . 32 113 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 114 10. Security Considerations . . . . . . . . . . . . . . . . . . . 32 115 10.1. Assurance of Proper Database . . . . . . . . . . . . . . . 33 116 10.2. Protection Against Modification . . . . . . . . . . . . . 33 117 10.3. Protection Against Eavesdropping . . . . . . . . . . . . . 33 118 10.4. Client Authentication Considerations . . . . . . . . . . . 33 119 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 34 120 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34 121 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 122 13.1. Normative References . . . . . . . . . . . . . . . . . . . 35 123 13.2. Informative References . . . . . . . . . . . . . . . . . . 35 124 Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . . 35 125 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 127 1. Introduction 129 This section provides some high level introductory material. Readers 130 are strongly encouraged to read 131 [I-D.ietf-paws-problem-stmt-usecases-rqmts] for use cases, 132 requirements, and additional background. 134 A geospatial database can track available spectrum (in accordance 135 with the rules of one or more regulatory domains) and make this 136 information available to devices. This approach shifts the 137 complexity of spectrum-policy conformance out of the device and into 138 the Database. This approach also simplifies adoption of policy 139 changes, limiting updates to a handful of databases, rather than 140 numerous devices. It opens the door for innovations in spectrum 141 management that can incorporate a variety of parameters, including 142 user location and time. In the future, it can include other 143 parameters, such as user priority, time, signal type and power, 144 spectrum supply and demand, payment or micro-auction bidding, and 145 more. 147 In providing this service, a database records and updates information 148 necessary to protect primary users -- for example, this information 149 may include parameters such as a fixed transmitter's call sign, its 150 geo-location, antenna height, power, and periods of operation. The 151 rules that the Database must follow, including its schedule for 152 obtaining and updating protection information, protection rules, and 153 information reported to devices, vary according to regulatory domain. 154 Such variations, however, should be handled by each database, and 155 exposure to the variations by devices should be minimized. 157 This specification defines an extensible protocol to obtain available 158 spectrum from a geospatial database by a device with geo-location 159 capability. It enables a device to operate in any regulatory domain 160 that implements the same protocol and in which the device is 161 authorized to operate. The document describes the use of HTTP/TLS as 162 transport for the protocol. 164 2. Conventions and Terminology 166 2.1. Conventions Used in This Document 168 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 169 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 170 document are to be interpreted as described in [RFC2119]. 172 2.2. Terminology 174 Database or Spectrum Database: A database that provides spectrum 175 availability information to devices. 176 Master Device: A device with geo-location capability that queries a 177 database to find available spectrum. 178 Slave Device: A device without geo-location capability that uses the 179 spectrum made available by a Master Device. It does not query the 180 Database directly. 181 RAT: Radio Access Technology 183 3. Protocol Overview 185 A Master Device uses the PAWS protocol to obtain a schedule of 186 available spectrum at its location. The security necessary to ensure 187 the accuracy, privacy, and confidentiality of the Device's location 188 is described in the Security Considerations (Section 10). This 189 document assumes that the Master Device and the Database are 190 connected to the Internet. 192 A typical sequence of PAWS operations is outlined as follows. See 193 Protocol Functionalities (Section 4) and Protocol Parameters 194 (Section 5) for details: 196 1. The Master Device locates or discovers the regulatory domain for 197 its location and the URI for the Database to send subsequent 198 PAWS messages. [Editor's Note: It is an open item whether 199 database discovery should be a separate document.] 200 2. The Master Device establishes an HTTPS session with database. 201 3. The Master Device optionally sends an initialization message to 202 the Database to exchange capabilities. 203 4. If the Database receives an initialization message, it responds 204 with a message in the body of the HTTP response. 205 5. If required by regulatory domain, the Database registers the 206 Master Device. 207 6. The Master Device sends an available-spectrum request message to 208 the Database. 209 7. If the Master Device is obtaining the schedule on behalf of a 210 Slave Device, if required by the regulatory domain, the Database 211 validates the Slave Device. 212 8. The database responds with an available-spectrum response 213 message in the body of the HTTP response. 214 9. Depending on regulatory domain requirements and database 215 implementation, the Master Device sends a spectrum-usage 216 notification message to the Database. 218 10. If the Database receives a spectrum-usage notification message, 219 it responds by sending the Master Device a spectrum-usage 220 acknowledgement message. 222 4. Protocol Functionalities 224 The PAWS protocol consists of several components: 226 o Database Discovery (Section 4.2) MUST be supported by Master 227 Device 228 o Initialization (Section 4.3) MAY be used by the Master Device and 229 MUST be implemented by the Database. 230 o Device Registration (Section 4.4) MAY be used by the Master Device 231 and MAY be implemented by the Database. 232 o Available Spectrum Query (Section 4.5) MUST be supported by Master 233 Device and the Database. 234 o Device Validation (Section 4.6) MAY be used by the Master Device 235 and MUST be implemented by the Database if the regulatory domain 236 requires device validation. 238 This section describes the protocol components and their messages. 239 Section 5 contains a more thorough discussion of the parameters that 240 comprise the PAWS request and response messages. Section 6 provides 241 details of the message encodings. Section 7 describes the use of 242 HTTPS [RFC2818] for transporting PAWS messages and optional device 243 authentication. 245 4.1. Indicating Errors 247 Each PAWS response messages contains a "responseInfo" parameter (see 248 Section 5.2). When the Database encounters an error, it MUST report 249 the error code using the "responseInfo" parameter and SHOULD include 250 an optional error message. The message MAY be in any language. When 251 the Database reports an error, it MAY omit otherwise required 252 portions of the response message. 254 Note that all PAWS-level errors are reported within a successful 255 transport-level response, e.g., 200 OK HTTPS response. Valid error 256 codes are listed in Section 5.15. 258 4.2. Database Discovery 260 A device MUST determine the URI for the Database and applicable 261 regulatory domain before it can send PAWS messages. The URI for the 262 Database SHOULD be obtained from an authorized and authenticated 263 entity, but it MAY be statically configured into the device. 264 [Editor's Note: It is an open item whether database discovery should 265 be a separate document.] 267 4.3. Initialization 269 A Master Device SHOULD use the initialization procedure to exchange 270 capability information with the Database whenever the Master Device 271 powers up or initiates communication with the Database. The 272 initialization response informs the Master Device of specific 273 regulatory-dependent parameterized-rule values, such as threshold 274 distances and time periods beyond which the device must update its 275 available-spectrum data (see Section 5.8). The Master Device MAY 276 manually configure these parameterized-rule values. The 277 initialization messages also represents extension points for database 278 implementations or regulatory domains that require the extra 279 handshake. 281 The Initialization request procedure is depicted in Figure 1. 282 o INIT_REQ (Section 4.3.1) is the initialization request message 283 o INIT_RESP (Section 4.3.2) is the initialization response message 285 +---------------+ +-------------------+ 286 | Master Device | | Spectrum Database | 287 +---------------+ +-------------------+ 288 | | 289 | INIT_REQ | 290 |-------------------->| 291 | | 292 | INIT_RESP | 293 |<--------------------| 294 | | 296 Figure 1 298 4.3.1. INIT_REQ 300 The initialization request message allows a device to initiate 301 exchange of capabilities with a database. 303 +-------------------------------------+ 304 |INIT_REQ | 305 +--------------------------+----------| 306 |protocolInfo:ProtocolInfo | required | 307 |deviceId:DeviceIdentifier | required | 308 |location:GeoLocation | required | 309 |.....................................| 310 |*other:any | depends | 311 +--------------------------+----------+ 312 Parameters: 314 protocolInfo: The protocol info (Section 5.1) for this message is 315 REQUIRED. The "messageType" parameter MUST be "INIT_REQ". 316 deviceId: The device identifier (Section 5.4) for the device is 317 REQUIRED. If the Database does not support the regulatory domain 318 specified by the "authority" parameter, it MUST return an error 319 code (TBD value) in the response. 320 location: The geo-location (Section 5.3) for the device is REQUIRED. 321 other: Depending on the regulatory domain or database 322 implementation, the Master Device MAY specify additional handshake 323 parameters in the INIT_REQ message. A database MUST ignore all 324 parameters it does not understand. 326 4.3.2. INIT_RESP 328 The initialization response message communicates database parameters 329 to the requesting device. 331 +-------------------------------------+ 332 |INIT_RESP | 333 +--------------------------+----------+ 334 |protocolInfo:ProtocolInfo | required | 335 |responseInfo:ResponseInfo | required | 336 |rulesetInfo:RulesetInfo | required*| 337 |.....................................| 338 |*other:any | depends | 339 +--------------------------+----------+ 341 Parameters: 343 protocolInfo: The protocol info (Section 5.1) for this message is 344 REQUIRED. The messageType parameter MUST be "INIT_RESP". 345 responseInfo: The response info (Section 5.2) is REQUIRED and 346 contains the response code, timestamp, etc. 347 rulesetInfo: This ruleset info (Section 5.8) parameter MUST be 348 included in the response if "responseInfo" does not contain an 349 error code. If there is an error, "rulesetInfo" MUST NOT be 350 included in the response message. This parameter specifies the 351 regulatory domain and parameters applicable for that domain. The 352 database MUST specify the same "authority" as that specified in 353 the "deviceId" parameter of the INIT_REQ message. 354 other: Depending on the regulatory domain or database 355 implementation, the Database MAY include additional handshake 356 parameters in the INIT_RESP message. The Master Device MUST 357 ignore all parameters it does not understand. 359 4.4. Device Registration 361 When a regulatory domain requires registration of a Master Device, 362 the device MUST send its registration information to the Database to 363 establish certain operational parameters. FCC rules, for example, 364 require that a 'Fixed Device' MUST register its owner and operator 365 contact information, its device identifier, its location, and its 366 antenna height. 368 The database MAY support device registration as a separate Device 369 Registration component, or as part of the Spectrum Availability 370 component. If a database does not support a separate Device 371 Registration request, it MUST return an error in the registration 372 response message. 374 The Device Registration request procedure is depicted in Figure 2. 375 o REGISTRATION_REQ (Section 4.4.1) is the device-registration 376 request message 377 o REGISTRATION_RESP (Section 4.4.2) is the device-registration 378 response message 380 +---------------+ +-------------------+ 381 | Master Device | | Spectrum Database | 382 +---------------+ +-------------------+ 383 | | 384 | REGISTRATION_REQ | 385 |------------------------>| 386 | | 387 | REGISTRATION_RESP | 388 |<------------------------| 389 | | 391 Figure 2 393 4.4.1. REGISTRATION_REQ 395 The registration request message contains the required registration 396 parameters. 398 +-------------------------------------+ 399 |REGISTRATION_REQ | 400 +--------------------------+----------+ 401 |protocolInfo:ProtocolInfo | required | 402 |deviceId:DeviceIdentifier | required | 403 |location:GeoLocation | required | 404 |deviceOwner:DeviceOwner | required | 405 |.....................................| 406 |*other:any | depends | 407 +--------------------------+----------+ 409 Parameters: 411 protocolInfo: The protocol info (Section 5.1) for this message is 412 REQUIRED. The "messageType" parameter MUST be "REGISTRATION_REQ". 413 deviceId: The device identifier (Section 5.4) for the device is 414 REQUIRED. 415 location: The geo-location (Section 5.3) for the device is REQUIRED. 416 deviceOwner: The device-owner (Section 5.7) information is REQUIRED. 417 other: Regulatory domains MAY require additional registration 418 parameters. To simplify its registration logic, a device MAY send 419 a union of the registration information required by all supported 420 regulatory domains. A database MUST ignore all parameters it does 421 not understand. 423 4.4.2. REGISTRATION_RESP 425 The registration response message simply acknowledges receipt of the 426 request. 428 +-------------------------------------+ 429 |REGISTRATION_RESP | 430 +--------------------------+----------+ 431 |protocolInfo:ProtocolInfo | required | 432 |responseInfo:ResponseInfo | required | 433 +--------------------------+----------+ 435 Parameters: 437 protocolInfo: The protocol info (Section 5.1) for this message is 438 REQUIRED. The "messageType" parameter MUST be 439 "REGISTRATION_RESP". 440 responseInfo: The response info (Section 5.2) is REQUIRED and 441 contains the response code, timestamp, etc. 443 4.5. Available Spectrum Query 445 To obtain the available spectrum from a database, a Master Device 446 sends a request that contains its geo-location and any parameters 447 required by the regulatory rules (such as device identifier, 448 capabilities, and characteristics). The database returns a response 449 that describes what frequencies are available, at what permissible 450 operating power levels, and a schedule of when they are available. 452 The Available Spectrum Query procedure is depicted in Figure 3. 454 o AVAIL_SPECTRUM_REQ (Section 4.5.1) is the available-spectrum 455 request message 456 o AVAIL_SPECTRUM_RESP (Section 4.5.2) is the available-spectrum 457 response message 458 o AVAIL_SPECTRUM_BATCH_REQ (Section 4.5.3) is an OPTIONAL batch 459 version of the available-spectrum request message that allows 460 multiple locations to be specified in the request 461 o AVAIL_SPECTRUM_BATCH_RESP (Section 4.5.4) is the response message 462 for the batch version of the available-spectrum request that 463 contains available spectrum for each location 464 o SPECTRUM_USE_NOTIFY (Section 4.5.5) is the spectrum-usage 465 notification message 466 o SPECTRUM_USE_RESP (Section 4.5.6) is the spectrum-usage 467 acknowledgment message 469 +---------------+ +-------------------+ 470 | Master Device | | Spectrum Database | 471 +---------------+ +-------------------+ 472 | | 473 | AVAIL_SPECTRUM_REQ | 474 | (AVAIL_SPECTRUM_BATCH_REQ) | 475 |--------------------------->| 476 | | 477 | AVAIL_SPECTRUM_RESP | 478 | (AVAIL_SPECTRUM_BATCH_RESP)| 479 |<---------------------------| 480 | | 481 | (SPECTRUM_USE_NOTIFY) | 482 |--------------------------->| 483 | | 484 | (SPECTRUM_USE_RESP) | 485 |<---------------------------| 486 | | 488 Figure 3 490 1. First, the Master Device sends an available-spectrum request 491 message to a database. 492 2. The database it MUST respond with an error message (error code 493 TBD) if: 494 * registration information is required, and 495 * the request does not include registration information, and 496 * the device has not previously registered 497 3. If the location specified in the request is outside the 498 regulatory domain, the Database MUST respond with an error 499 message (error code TBD). 501 4. The database MAY perform other validation of the request, (e.g., 502 checking for missing required parameters, authorizations). It 503 MUST return an error message with appropriate error code, if 504 validation fails. 505 5. If the request is valid, the Database responds with an available- 506 spectrum response message. If the regulatory domain requires 507 that devices must report anticipated spectrum usage, the Database 508 MUST indicate so in the response message. 509 6. If the available-spectrum response indicates that the Master 510 Device must send a spectrum-usage notification message, the 511 Master Device MUST send the notification message to the Database 512 . 513 7. If the Database receives a spectrum-usage notification message, 514 it MUST send a spectrum-usage acknowledgment message to the 515 Master Device. 517 The procedure for asking for available spectrum on behalf of a slave 518 device is similar, except that the process is initiated by the slave 519 device. Also, the device identifier, capabilities, and 520 characteristics communicated in the AVAIL_SPECTRUM_REQ message SHALL 521 be those of the slave device. Although the communication and 522 protocol between the slave device and Master Device is outside the 523 scope of this document, the expected message sequence is shown in 524 Figure 4. 526 +------------+ +---------------+ +-------------------+ 527 |Slave Device| | Master Device | | Spectrum Database | 528 +------------+ +---------------+ +-------------------+ 529 | | | 530 | AVAIL_SPEC_REQ | | 531 |................>| | 532 | | | 533 | | AVAIL_SPECTRUM_REQ | 534 | |-------------------------->| 535 | | | 536 | | AVAIL_SPECTRUM_RESP | 537 | |<--------------------------| 538 | | | 539 | AVAIL_SPEC_RESP | (SPECTRUM_USE_NOTIFY) | 540 |<................|-------------------------->| 541 | | | 542 | | (SPECTRUM_USE_RESP) | 543 | |<--------------------------| 544 | | | 546 Figure 4 548 4.5.1. AVAIL_SPECTRUM_REQ 550 The request message for the Available Spectrum Query protocol MUST 551 include the device's geo-location. 553 +--------------------------------------------------------------+ 554 |AVAIL_SPECTRUM_REQ | 555 +-------------------------------+------------------------------+ 556 |protocolInfo:ProtocolInfo | required | 557 |deviceId:DeviceIdentifier | required | 558 |location:GeoLocation | required | 559 |antenna:AntennaCharacteristics | depends on regulatory domain | 560 |owner:DeviceOwner | depends on regulatory domain | 561 |capabilities:DeviceCapabilities| optional | 562 +-------------------------------+------------------------------+ 564 Parameters: 566 protocolInfo: The protocol info (Section 5.1) for this message is 567 REQUIRED. The "messageType" parameter MUST be 568 "AVAIL_SPECTRUM_REQ". 569 deviceId: The device identifier (Section 5.4) for the device is 570 REQUIRED. 571 location: The geo-location (Section 5.3) for the device is REQUIRED. 572 The location SHOULD be the current location of the device. 573 Depending on the regulatory domain, the location MAY be an 574 anticipated position of the device. 575 antenna: Depending on the device type and regulatory domain, the 576 antenna characteristics (Section 5.5) MAY be required. 577 owner: Depending on the device type and regulatory domain, the 578 device owner (Section 5.7) information MAY be included to register 579 the device with the Database. This enables a device to register 580 and get spectrum-availability information in a single request. 581 capabilities: The Master Device MAY include its device capabilities 582 (Section 5.6) to limit the available-spectrum response to the 583 spectrum that is compatible with its capabilities. The database 584 SHOULD NOT return spectrum that is not compatible with the 585 specified capabilities. 587 4.5.1.1. Regulatory Specifics 589 For the US / FCC TV-Band devices: 591 o The "antenna" parameter is REQUIRED for FIXED device types. It 592 MUST specify the antenna height the and height type. 593 o The "owner" parameter is REQUIRED for FIXED device types and if 594 the device has not been registered yet with the Database or if the 595 Database does not implement a separate device registration 596 request. 598 4.5.2. AVAIL_SPECTRUM_RESP 600 The response message for the Available Spectrum Query contains a 601 schedule of available spectrum for the device. 603 +-------------------------------------+ 604 |AVAIL_SPECTRUM_RESP | 605 +--------------------------+----------+ 606 |protocolInfo:ProtocolInfo | required | 607 |responseInfo:ResponseInfo | required | 608 |deviceId:DeviceIdentifier | required | 609 |spectrumSchedule:list | required |-------+ 610 |needsSpectrumReport:bool | optional | | 611 |..........................|..........| | 612 |location:GeoLocation | optional | | 613 +--------------------------+----------+ | 1..* 614 V 615 +-----------------------------+ 616 |SpectrumSchedule | 617 +------------------+----------+ 618 |time:EventTime | required | 619 |spectrum:Spectrum | required | 620 +------------------+----------+ 622 Parameters: 624 protocolInfo: The protocol info (Section 5.1) for this message is 625 REQUIRED. The "messageType" parameter MUST be 626 "AVAIL_SPECTRUM_RESP" 627 responseInfo: The response info (Section 5.2) is REQUIRED and 628 contains the response code, timestamp, etc. 629 deviceId: The database MUST include the device identifier 630 (Section 5.4) specified in the AVAIL_SPECTRUM_REQ message 631 spectrumSchedule: The schedule (Section 5.12) of available spectrum. 632 The Database MAY return more than one schedule to represent future 633 changes to the available spectrum. How far in advance a schedule 634 may be provided depends on the regulatory domain. 635 needsSpectrumReport: For regulatory domains that require a spectrum- 636 usage report from devices, the Database MUST return true for this 637 parameter. The default value is false. 638 location: The database MAY copy other elements from the request, 639 such as the geo-location (Section 5.3) of the device. The device 640 MUST ignore any parameters it does not understand. 642 When the stop time specified in the schedule has been reached, a 643 device: 645 o MUST obtain a new spectrum-availability schedule, either by using 646 the next one in the list (if provided) or making another Available 647 Spectrum Query (Section 4.5) 648 o If the new schedule indicates the in-use spectrum is no longer 649 available, the device MUST stop operation immediately. 650 o If the device is unable to contact the Database to obtain a new 651 schedule, depending on the regulatory domain, the device MAY 652 continue to operate for a period of time, as indicated by 653 parameters returned in the INIT_RESP (Section 4.3.2) message. 655 When the device moves beyond a threshold distance (established by 656 regulatory rules) away from the actual location and all anticipated 657 location(s) it reported in previous AVAIL_SPECTRUM_REQ or 658 AVAIL_SPECTRUM_BATCH_REQ requests (see "maxLocationChange" in 659 Section 5.8), it: 660 o MUST obtain a new spectrum-availability schedule by making another 661 Available Spectrum Query (Section 4.5). 662 o If the new response indicates the in-use spectrum is no longer 663 available, the device MUST stop operation immediately. 664 o If the device is unable to contact the Database to obtain a new 665 schedule, depending on the regulatory domain, the device MUST stop 666 operation immediately. 668 4.5.3. AVAIL_SPECTRUM_BATCH_REQ 670 The Database MAY support the batch request that allows multiple 671 locations to be specified. This allows a portable Master Device to 672 get available spectrum for a sequence of anticipated locations using 673 a single request. Each location is treated independently such that a 674 single batch request is equivalent to multiple AVAIL_SPECTRUM_REQ 675 (Section 4.5.1) requests. The request message for the batch 676 Available Spectrum Query protocol MUST include at least one geo- 677 location. If the Database does not support batch requests, it MUST 678 return a NOT_SUPPORTED error. 680 +--------------------------------------------------------------+ 681 |AVAIL_SPECTRUM_BATCH_REQ | 682 +-------------------------------+------------------------------+ 683 |protocolInfo:ProtocolInfo | required | 684 |deviceId:DeviceIdentifier | required | 685 |locations:list | required |--+ 686 |antenna:AntennaCharacteristics | depends on regulatory domain | | 687 |owner:DeviceOwner | depends on regulatory domain | | 688 |capabilities:DeviceCapabilities| optional | | 1..* 689 +-------------------------------+------------------------------+ V 690 +-------------+ 691 | GeoLocation | 692 +-------------+ 694 Parameters: 696 protocolInfo: The protocol info (Section 5.1) for this message is 697 REQUIRED. The "messageType" parameter MUST be 698 "AVAIL_SPECTRUM_BATCH_REQ". 699 deviceId: The device identifier (Section 5.4) for the device is 700 REQUIRED. 701 locations: The list of geo-locations (Section 5.3) for the device is 702 REQUIRED. This allows a device to specify its actual location 703 plus additional anticipated locations, when allowed by the 704 regulatory domain. At least one location MUST be included. This 705 specification places no upper limit on the number of locations, 706 but the Database MAY restrict the number of locations it supports 707 by returning a response with fewer locations than specified in the 708 request. 709 antenna: Depending on the device type and regulatory domain, the 710 antenna characteristics (Section 5.5) MAY be required. 711 owner: Depending on the device type and regulatory domain, the 712 device owner (Section 5.7) information MAY be included to register 713 the device with the Database. This enables a device to register 714 and get spectrum-availability information in a single request. 715 capabilities: The Master Device MAY include its device capabilities 716 (Section 5.6) to limit the available-spectrum response to the 717 spectrum that is compatible with its capabilities. The database 718 SHOULD NOT return spectrum that is not compatible with the 719 specified capabilities. 721 4.5.3.1. Regulatory Specifics 723 For the US / FCC TV-Band devices: 725 o The "antenna" parameter is REQUIRED for FIXED device types. It 726 MUST specify the antenna height the and height type. 727 o The "owner" parameter is REQUIRED for FIXED device types and if 728 the device has not been registered yet with the Database or if the 729 Database does not implement a separate device registration 730 request. 732 4.5.4. AVAIL_SPECTRUM_BATCH_RESP 734 The response message for the batch Available Spectrum Query contains 735 a schedule of available spectrum for the device at multiple 736 locations. 738 +-------------------------------------+ 739 |AVAIL_SPECTRUM_BATCH_RESP | 740 +--------------------------+----------+ 741 |protocolInfo:ProtocolInfo | required | 742 |responseInfo:ResponseInfo | required | 743 |deviceId:DeviceIdentifier | required | 744 |geoSpectrumSchedules:list | required |-------+ 745 |needsSpectrumReport:bool | optional | | 746 +--------------------------+----------+ | 1..* 747 V 748 +---------------------------------+ 749 |GeoSpectrumSchedule | 750 +----------------------+----------+ 751 |location:GeoLocation | required | 752 |spectrumSchedule:list | required | 753 +----------------------+----------+ 755 Parameters: 757 protocolInfo: The protocol info (Section 5.1) for this message is 758 REQUIRED. The "messageType" parameter MUST be 759 "AVAIL_SPECTRUM_BATCH_RESP" 760 responseInfo: The response info (Section 5.2) is REQUIRED and 761 contains the response code, timestamp, etc. 762 deviceId: The database MUST include the device identifier 763 (Section 5.4) specified in the AVAIL_SPECTRUM_REQ message 764 geoSpectrumSchedules: The list of spectrum-availability schedules 765 for a location (Section 5.13) is REQUIRED. For each location, the 766 Database MAY return more than one schedule to represent future 767 changes to the available spectrum. How far in advance a schedule 768 may be provided depends on the regulatory domain. The Database 769 MAY return available spectrum for fewer locations than requested. 770 The Device MUST NOT make any assumptions on the order of the 771 entries in the list and MUST use the location value in each 772 GeoSpectrumSchedule entry to match available spectrum to a 773 location. 774 needsSpectrumReport: For regulatory domains that require a spectrum- 775 usage report from devices, the Database MUST return true for this 776 parameter. The default value is false. 778 When the stop time specified in the schedule has been reached, a 779 device: 781 o MUST obtain a new spectrum-availability schedule, either by using 782 the next one in the list (if provided) or making another Available 783 Spectrum Query (Section 4.5) 785 o If the new schedule indicates the in-use spectrum is no longer 786 available, the device MUST stop operation immediately. 787 o If the device is unable to contact the Database to obtain a new 788 schedule, depending on the regulatory domain, the device MAY 789 continue to operate for a period of time, as indicated by 790 parameters returned in the INIT_RESP (Section 4.3.2) message. 792 When the device moves beyond a threshold distance (established by 793 regulatory rules) away from all actual or anticipated location(s) it 794 reported in the AVAIL_SPECTRUM_BATCH_REQ message (see 795 "maxLocationChange" in Section 5.8), it: 796 o MUST obtain a new spectrum-availability schedule by making another 797 Available Spectrum Query (Section 4.5). 798 o If the new schedule indicates the in-use spectrum is no longer 799 available, the device MUST stop operation immediately. 800 o If the device is unable to contact the Database to obtain a new 801 schedule, depending on the regulatory domain, the device MUST stop 802 operation immediately. 804 4.5.5. SPECTRUM_USE_NOTIFY 806 The spectrum-use notification message MUST contain the geo-location 807 of the device and parameters required by the regulatory domain. 809 +-------------------------------------+ 810 |SPECTRUM_USE_NOTIFY | 811 +--------------------------+----------+ 812 |protocolInfo:ProtocolInfo | required | 813 |deviceId:DeviceIdentifier | required | 814 |location:GeoLocation | required | 815 |spectrum:list | required |-------+ 816 |.....................................| | 817 |*other:any | depends | | 818 +--------------------------+----------+ | 0..* 819 V 820 +--------------------------------+ 821 |Spectrum | 822 +---------------------+----------+ 823 |bandwidth:float | required | 824 |frequencyRanges:list | required | 825 +---------------------+----------+ 827 Parameters: 829 protocolInfo: The protocol info (Section 5.1) for this message is 830 REQUIRED. The "messageType" parameter MUST be 831 "SPECTRUM_USE_NOTIFY". 832 deviceId: The device identifier (Section 5.4) for the device is 833 REQUIRED. 834 location: The geo-location (Section 5.3) for the device is REQUIRED. 835 spectrum: The spectrum (Section 5.9) is REQUIRED and specifies the 836 spectrum anticipated to be used by the device, which includes 837 frequency ranges and maximum power levels. For consistency, the 838 "bandwidth" value SHOULD match that from one of the Spectrum 839 elements in the corresponding AVAIL_SPECTRUM_RESP message, and the 840 maximum power levels in the Spectrum element MUST be expressed as 841 total power (EIRP) computed over the specified "bandwidth" value. 842 The actual bandwidth to be used (as computed from the start and 843 stop frequencies) MAY be different from the "bandwidth" value. As 844 an example, when regulatory rules express maximum power spectral 845 density in terms of maximum power over any 100 kHz band, then the 846 "bandwidth" value should be set to 100 kHz, even though the actual 847 bandwidth used is 20 kHz. 848 other: Depending on the regulatory domain, other parameters MAY be 849 required. To simplify its logic, the device MAY include the union 850 of all parameters required by all supported regulatory domains. 851 The database MUST ignore all parameters it does not understand. 853 4.5.6. SPECTRUM_USE_RESP 855 The spectrum-use response message simply acknowledges receipt of the 856 notification. 858 +-------------------------------------+ 859 |SPECTRUM_USE_RESP | 860 +--------------------------+----------+ 861 |protocolInfo:ProtocolInfo | required | 862 |responseInfo:ResponseInfo | required | 863 +--------------------------+----------+ 865 Parameters: 867 protocolInfo: The protocol info (Section 5.1) for this message is 868 REQUIRED. The "messageType" parameter MUST be "SPECTRUM_USE_RESP" 869 responseInfo: The response info (Section 5.2) is REQUIRED and 870 contains the response code, timestamp, etc. 872 4.6. Device Validation 874 Typically, a slave device needs a Master Device to ask the Database 875 on its behalf for available spectrum. Depending on the regulatory 876 domain, the Master Device also must validate with the Database that 877 the slave device is permitted to operate. When regulatory rules 878 allow a Master Device to "cache" the available spectrum for a period 879 of time, the Master Device MAY use the simpler Device Validation 880 component, instead of the full Available Spectrum Query component, to 881 validate a slave device. 883 When validating one or more slave devices, the Master Device sends 884 the Database a request that includes the device identifier -- and any 885 other parameters required by the regulatory rules -- for each slave 886 device. The database returns a response that indicates whether each 887 device is permitted to use the spectrum. 889 A typical sequence for using the Device Validation request is 890 illustrated in Figure 5, where the Master Device already has a valid 891 set of available spectrum for slave devices. Note that the 892 communication and protocol between the slave device and Master Device 893 is outside the scope of this document. 894 o DEV_VALID_REQ (Section 4.6.1) is the device-validation request 895 message 896 o DEV_VALID_RESP (Section 4.6.2) is the device-validation response 897 message 899 +------------+ +---------------+ +-------------------+ 900 |Slave Device| | Master Device | | Spectrum Database | 901 +------------+ +---------------+ +-------------------+ 902 | | | 903 | AVAIL_SPEC_REQ | | 904 |................>| | 905 | | | 906 | | DEV_VALID_REQ | 907 | |-------------------------->| 908 | | | 909 | | DEV_VALID_RESP | 910 | |<--------------------------| 911 | AVAIL_SPEC_RESP | | 912 |<................| 913 | | 915 Figure 5 917 4.6.1. DEV_VALID_REQ 919 +-------------------------------------+ 920 |DEV_VALID_REQ | 921 +--------------------------+----------+ 922 |protocolInfo:ProtocolInfo | required | 923 |deviceIds:list | required |---- 924 +--------------------------+----------+ | 925 V 1..* 926 +----------------------+ 927 |DeviceIdentifier | 928 +----------------------+ 930 Parameters: 932 protocolInfo: The protocol info (Section 5.1) for this message is 933 REQUIRED. The "messageType" parameter MUST be "DEV_VALID_REQ". 934 deviceIds: A list of device identifiers Section 5.4 is REQUIRED to 935 specify the list of slave devices that must be validated. 937 4.6.2. DEV_VALID_RESP 939 +-------------------------------------+ 940 |DEV_VALID_RESP | 941 +--------------------------+----------+ 942 |protocolInfo:ProtocolInfo | required | 943 |deviceValidity:list | required |---- 944 +--------------------------+----------+ | 945 V 1..* 946 +-------------------------------------+ 947 |DeviceValidity | 948 +--------------------------+----------+ 949 |deviceId:DeviceIdentifier | required | 950 |isValid:boolean | required | 951 +--------------------------+----------+ 953 Parameters: 954 protocolInfo: The protocol info (Section 5.1) for this message is 955 REQUIRED. The "messageType" parameter MUST be "DEV_VALID_RESP". 956 deviceValidity: A list of device validity elements Section 5.14 is 957 REQUIRED to report the list of slave devices and corresponding 958 code of whether the device is valid. The number of entries MUST 959 match the number of device IDs specified in the DEV_VALID_REQ 960 message. 962 5. Protocol Parameters 964 This section presents the more details of parameters that make up the 965 PAWS request and response messages. It also includes a sub-section 966 defining response codes. 968 5.1. ProtocolInfo 970 All PAWS request and response messages MUST include the ProtocolInfo 971 parameter: 973 +-------------------------------+ 974 |ProtocolInfo | 975 +--------------------+----------+ 976 |version:string | required | 977 |messageType:string | required | 978 +--------------------+----------+ 980 Parameters: 982 version: Version of the PAWS protocol is REQUIRED. It MUST be the 983 string, "1.0". If the data receives a request message containing 984 a version it does not support, it MUST respond with an error 985 message. 986 messageType: Name of the message type is REQUIRED. It specifies the 987 name of its containing message. 989 5.2. ResponseInfo 991 All PAWS response messages MUST include the ResponseInfo parameter: 993 +-----------------------------+ 994 |ResponseInfo | 995 +------------------+----------+ 996 |code:string | required | 997 |message:string | optional | 998 |timestamp:string | optional | 999 |responseId:string | optional | 1000 |.............................| 1001 |*other:any | optional | 1002 +------------------+----------+ 1004 Parameters: 1006 code: The result code is REQUIRED. If the Database needs to respond 1007 with an error, it MUST set this to a defined error code. Valid 1008 values for result and error codes are TBD. 1009 message: The message is OPTIONAL. When the result code is an error 1010 code, the Database SHOULD include a message that provides more 1011 details. The message MAY be in any language. 1012 timestamp: The database MAY include the timestamp of the response. 1013 When provided, it MUST be in the form, YYYY-MM-DDThh:mm:ssZ, as 1014 defined by [RFC3339]. It MUST be expressed in UTC. 1015 responseId: The database MAY include a unique ID for the response. 1016 other: The database MAY include additional error details. The 1017 device MUST ignore any parameters it does not understand. 1019 NOTE: When there is an error, the Database MUST include ResponseInfo 1020 in the response message, but MAY omit otherwise required portions of 1021 the response message. 1023 5.3. GeoLocation 1025 This parameter is used to specify the geo-location of the device. 1027 +---------------------------------------------------+ 1028 |GeoLocation | 1029 +--------------------+------------------------------+ 1030 |latitude:float | required | 1031 |longitude:float | required | 1032 |uncertainty:float | depends on regulatory domain | 1033 |confidence:int | depends on regulatory domain | 1034 +--------------------+------------------------------+ 1036 Parameters: 1038 latitude, longitude: Floating-point numbers that express the 1039 latitude and longitude in degrees using the WGS84 datum. 1040 REQUIRED. 1041 uncertainty: The uncertainty of the location in meters MAY be 1042 required, depending on the regulatory domain. When this parameter 1043 is optional, its default value is 0. 1044 confidence: The location confidence level as an integer percentage 1045 MAY be required, depending on the regulatory domain. When the 1046 parameter is optional, its default value is 100. 1048 5.3.1. Regulatory Specifics 1050 For UK / Ofcom UHF TV-band devices: 1051 o The "uncertainty" parameter is REQUIRED if the uncertainty is 1052 greater than 50 meters. 1054 5.4. DeviceIdentifier 1056 The device identifier contains parameters that identify the specific 1057 device, such as its manufacturer serial number, and regulatory- 1058 specific ID (e.g., FCC ID), and any other regulatory-specific 1059 information, such as device-type classification. 1061 +----------------------------------------------------+ 1062 |DeviceIdentifier | 1063 +--------------------+-------------------------------+ 1064 |authority:string | required | 1065 |serialNumber:string | required | 1066 |identity:string | required | 1067 |....................|...............................| 1068 |*deviceType:string | depends on regulatory domain | 1069 |*RAT:string | depends on regulatory domain | 1070 |*other:any | | 1071 +--------------------+-------------------------------+ 1073 Parameters: 1075 authority: A string that indicates the regulatory domain to which 1076 the device identifier applies is REQUIRED. It MUST use the 1077 2-letter country codes defined by [ISO3166-1]. 1078 serialNumber: The manufacturer's device serial number is REQUIRED. 1079 identity: The device's regulatory domain ID is REQUIRED. 1081 Additional parameters in the DeviceIdentifer depend on each 1082 regulatory domain, and must be defined on a per-domain basis. 1084 5.4.1. Regulatory Specifics 1086 For the US / FCC TV-Band devices: 1087 o The authority value MUST be "US" 1088 o The identity value is the device's FCC ID 1089 o The "deviceType" parameter is REQUIRED to indicate the device 1090 type. Valid values are FIXED, MODE_1, MODE_2 1092 For UK / Ofcom TV-Band devices: 1093 o The authority value MUST be "UK" 1094 o The "RAT" parameter is required to specify the Radio Access 1095 Technology. Valid values are TBD. 1096 o A "deviceClass" parameter is required to identify, among other 1097 things, the emission mask of the device. Valid values are TBD. 1099 5.5. AntennaCharacteristics 1101 Antenna characteristics provide additional information, such as the 1102 antenna height, antenna type, etc. Whether antenna characteristics 1103 must be provided in a request depends on the device type and 1104 regulatory domain. 1106 +--------------------------------------------------------+ 1107 |AntennaCharacteristics | 1108 +-------------------------+------------------------------+ 1109 |height:float | depends on regulatory domain | 1110 |heightType:enum | optional | 1111 |heightUncertainty:float | depends on regulatory domain | 1112 |.........................|..............................| 1113 |*characteristics: | depends on regulatory domain | 1114 | various | | 1115 +-------------------------+------------------------------+ 1117 Parameters: 1119 height: The antenna height in meters. Whether the antenna height is 1120 required depends on the device type and the regulatory domain. 1121 heightType: If the height is required, then heightType is also 1122 REQUIRED. Valid values are: 1123 AGL Above ground level (default) 1124 AMSL Above mean sea level 1125 heightUncertainty: The height uncertainty in meters. Whether this 1126 is required depends on the regulatory domain. 1128 Depending on the regulatory authority, additional antenna 1129 characteristics may be required, such as: 1130 o antenna direction 1131 o antenna radiation pattern 1132 o antenna gain 1133 o antenna polarization 1135 5.5.1. Regulatory Specifics 1137 For the US / FCC TV-Band devices: 1138 o The height and heightType parameters are REQUIRED for FIXED device 1139 types. 1141 5.6. DeviceCapabilities 1143 Device capabilities provide additional information that MAY be used 1144 by the device provide additional information to the Database they may 1145 help it to determine available spectrum. If a database does not 1146 support device capabilities it MUST ignore the parameter altogether. 1148 +----------------------------------------------------+ 1149 |DeviceCapabilities | 1150 +---------------------+------------------------------+ 1151 |frequencyRange:list | optional | 1152 +---------------------+------------------------------+ 1154 Parameters: 1156 frequencyRange: Optional list of frequency ranges (Section 5.10)--- 1157 start and stop frequencies --- in which the device can operate. 1158 When specified, the Database SHOULD NOT return available spectrum 1159 that falls outside these ranges. 1161 5.7. DeviceOwner 1163 This parameter contains device-owner information required as part of 1164 device registration. Regulatory domains MAY require additional 1165 parameters. The minimum set of parameters are described below. 1167 +-----------------------------+ 1168 |DeviceOwner | 1169 +------------------+----------+ 1170 |owner:string | required | 1171 |operator:string | required | 1172 |address:string | required | 1173 |email:string | required | 1174 |phone:string | required | 1175 +------------------+----------+ 1177 Parameters: 1179 owner: Name of the individual or business that owns the device is 1180 REQUIRED. 1181 operator: Name of the device operator is REQUIRED. 1182 address: Civic address of the device owner or operator of the device 1183 is REQUIRED. 1184 email: Email address of the device owner or operator of the device 1185 is REQUIRED. 1186 phone: Phone number of the device owner or operator of the device is 1187 REQUIRED. 1189 NOTE: Whether the contact information must be that of the device 1190 owner or operator depends on the regulatory domain. Depending on the 1191 regulatory domain, the Database MAY be required to validate the 1192 device-owner information. In these cases, the Database MUST respond 1193 with an error message if validation fails. 1195 5.8. RulesetInfo 1197 This contains parameters for the rule set of a regulatory domain that 1198 is communicated using the Initialization component (Section 4.3). 1200 +-----------------------------------+ 1201 |RulesetInfo | 1202 +-----------------------------------+ 1203 |authority:string | required | 1204 |maxLocationChange:float | required | 1205 |maxPollingSecs:int | required | 1206 |maxValiditySecs:int | required | 1207 |...................................| 1208 |*other:any | depends | 1209 +------------------------+----------+ 1211 Parameters: 1212 authority: A string that indicates the regulatory domain to which 1213 the ruleset applies is REQUIRED. It MUST use the 2-letter country 1214 codes defined by [ISO3166-1]. 1215 maxLocationChange: The maximum location change in meters is 1216 REQUIRED. When a device changes location by more than this 1217 specified distance, it MUST contact the Database to get the 1218 available spectrum for the new location. If the device is using 1219 spectrum that is no longer available, it MUST stop operation in 1220 those frequencies immediately. 1221 maxPollingSecs: The maximum duration, in seconds, between requests 1222 for available spectrum is REQUIRED. The device MUST contact the 1223 Database to get available spectrum no less frequently than this 1224 duration. If the new spectrum information indicates that the 1225 device is using spectrum that is no longer available, it MUST stop 1226 operation in those frequencies immediately. 1227 maxValiditySecs: The maximum duration that the available-spectrum 1228 information may be considered valid is REQUIRED. When a device is 1229 unable to contact the Database, it MAY continue to use the latest 1230 available- spectrum information at its location until its validity 1231 expires. The expiration is determined by adding maxValiditySecs 1232 to the timestamp of the AVAIL_SPECTRUM_RESP that provided the 1233 latest available-spectrum information. 1234 other: This message is intended to be extensible with other 1235 regulatory-specific parameters. Devices MUST ignore all 1236 parameters in the message it does not understand. 1238 5.8.1. RegulatorySpecifics 1240 For the US / FCC TV-band rules: 1242 o "authority" MUST be the string, "US" 1243 o "maxLocationChange" MUST be 50 meters 1244 o "maxPollingSecs" MUST be 86400 seconds, corresponding to 24 hours 1245 o "maxValiditySecs" MUST be 172800 seconds, corresponding to 48 1246 hours 1248 5.9. Spectrum 1250 Available spectrum can logically be characterized by a list of 1251 frequency ranges and permissible power levels for each range. 1253 +-------------------------------+ 1254 |Spectrum | 1255 +---------------------+---------+ 1256 |bandwidth:float |required | +---------------------------+ 1257 |frequencyRanges:list |required |------>|FrequencyRange | 1258 +---------------------+---------+ 1..* +-----------------+---------+ 1259 |startHz:float |required | 1260 |stopHz:float |required | 1261 |maxPowerDBm:float|optional | 1262 |channelId:string |optional | 1263 +-----------------+---------+ 1265 Parameters: 1267 bandwidth: This parameter is REQUIRED to define the operating 1268 bandwidth for which permissible power levels is to be specified. 1269 For example, FCC regulation would require only one spectrum 1270 specification at 6MHz bandwidth, but Ofcom regulation would 1271 require 2 specifications, at 0.1MHz and 8MHz. 1272 frequencyRanges: A list of FrequencyRange (Section 5.10) objects is 1273 REQUIRED to specify frequency ranges and permissible power levels. 1275 5.10. FrequencyRange 1277 The FrequencyRange parameter specifies the maximum permissible power 1278 levels within a frequency range. 1279 startHz: The inclusive start of the frequency range is REQUIRED 1280 stopHz: The exclusive end of the frequency range is REQUIRED 1281 maxPowerDBm: The maximum total power level (EIRP) -- computed over 1282 the corresponding operating bandwidth -- that is permitted within 1283 the frequency range. Depending on the context in which the 1284 FrequencyRange element appears, maxPowerDBm may be REQUIRED. For 1285 example, it is REQUIRED in the AVAIL_SPECTRUM_RESP (Section 4.5.2) 1286 and SPECTRUM_USE_NOTIFY (Section 4.5.5) messages, but it would not 1287 be used to describe Device Capabilities (Section 5.6). 1289 channelId: The server MAY include a channel identifier, when 1290 applicable. When it is included, the Master Device SHOULD treat 1291 it as informative. 1293 NOTE: (maxPowerDBm / bandwidth) defines the maximum permitted EIRP 1294 spectral density. 1296 5.11. EventTime 1298 The EventTime element specifies the start and stop times of an 1299 "event". This is used to indicate the time period for which a 1300 Spectrum (Section 5.9) is valid. 1302 +---------------------------+ 1303 |EventTime | 1304 +-----------------+---------+ 1305 |startTime:string |required | 1306 |stopTime:string |required | 1307 +-----------------+---------+ 1309 Parameters: 1311 startTime: The inclusive start of the event is REQUIRED. 1312 stopTime: The exclusive end of the event is REQUIRED. 1314 Both times are expressed using the format, YYYY-MM-DDThh:mm:ssZ, as 1315 defined by [[RFC3339]]. The times MUST be expressed using UTC. 1317 5.12. SpectrumSchedule 1319 The SpectrumSchedule element combines EventTime with Spectrum to 1320 define a time period in which the spectrum is valid. 1322 +-------------------------------+ 1323 |SpectrumSchedule | 1324 +--------------------+----------+ 1325 |eventTime:EventTime | required | +-------------------+ 1326 |spectrum:list | required |------->|Spectrum | 1327 +--------------------+----------+ 1..* +-------------------+ 1328 |bandwidth:float | 1329 |frequencyRange:list| 1330 +-------------------+ 1332 Parameters: 1334 eventTime: The time period (Section 5.11) is REQUIRED to express 1335 "when" this specification is valid. 1336 spectrum: List of Spectrum (Section 5.9) elements is REQUIRED to 1337 specify the available spectrum and permissible power levels, one 1338 per bandwidth. 1340 5.13. GeoSpectrumSchedule 1342 The GeoSpectrumSchedule element encapsulates the schedule of 1343 available spectrum at a location. 1344 +----------------------------------+ 1345 |GeoSpectrumSchedule | 1346 +-----------------------+----------+ 1347 |location:GeoLocation | required | 1348 |spectrumSchedule:list | required |----------+ 1349 +-----------------------+----------+ | 1350 | 1..* 1351 V 1352 +-----------------------------+ 1353 |SpectrumSchedule | 1354 +------------------+----------+ 1355 |time:EventTime | required | 1356 |spectrum:Spectrum | required | 1357 +------------------+----------+ 1359 Parameters: 1361 location: The location (Section 5.3) is REQUIRED to identify the 1362 location at which the spectrum schedule applies 1363 location: The list of spectrum schedules (Section 5.12) is REQUIRED. 1364 At least one schedule MUST be included. More than one schedule 1365 MAY be included to represent future changes to the available 1366 spectrum. 1368 5.14. DeviceValidity 1370 The DeviceValidity element is used to indicate whether a device is 1371 valid. See Section 4.6.2. 1372 +-------------------------------------+ 1373 |DeviceValidity | 1374 +--------------------------+----------+ 1375 |deviceId:DeviceIdentifier | required | 1376 |isValid:boolean | required | 1377 |reason:string | optional | 1378 +--------------------------+----------+ 1380 Parameters: 1382 deviceId: The device identifier (Section 5.4) that was used to check 1383 for validity. This is REQUIRED. 1384 isValid: A REQUIRED boolean value that indicates whether the device 1385 is valid. 1386 reason: If the device identifier is not valid, the Database MAY 1387 include a reason. The reason MAY be in any language. 1389 5.15. Response Codes 1391 TBD 1393 6. Message Encoding 1395 TBD 1397 7. HTTPS Binding 1399 This section describes the use of HTTP over TLS (HTTPS) [RFC2818] as 1400 the transport mechanism for the PAWS protocol. TLS provides message 1401 integrity and confidentiality between the Master Device and the 1402 Database. The Master Device MUST implement server authentication, as 1403 described in Section 3.1 of [RFC2818]. The device uses the URI 1404 determined (either statically configured or dynamically discovered) 1405 to authenticate the server. The device SHOULD fail a request if 1406 server authentication fails. 1408 Depending on prior relationship between a database and device, the 1409 server MAY require client authentication, as described in The TLS 1410 Protocol [RFC5246], to authenticate the device. 1412 To enable databases to handle large numbers of requests from large 1413 numbers of devices, the Database MAY support and devices SHOULD 1414 support Stateless TLS Session Resumption [RFC5077]. 1416 A PAWS request message is carried in the body of an HTTP POST 1417 request. A PAWS response message is carried in the body of an HTTP 1418 response. A PAWS response SHOULD include a Content-Length header. 1420 The POST method is the only method REQUIRED for PAWS. If a database 1421 chooses to support GET, it MUST be an escaped URL, but the encoding 1422 of the URL is outside the scope of this document. The database MAY 1423 refuse to support the GET request by returning an HTTP error code, 1424 such as 404 (not found). 1426 The Database MAY redirect a PAWS request. The Master Device MUST 1427 handle redirects by using the Location header provided by the server 1428 in a 3xx response. When redirecting, the Master Device MUST observe 1429 the delay indicated by the Retry-After header. The Master Device 1430 MUST authenticate the Database that returns the redirect response 1431 before following the redirect. The Master Device MUST authenticate 1432 the Database indicated in the redirect. 1434 8. Example Messages 1436 TBD 1438 9. IANA Considerations 1440 TBD 1442 10. Security Considerations 1444 PAWS is a protocol whereby a Master Device requests a schedule of 1445 available spectrum at its location (or location of its slave devices) 1446 before it (they) can operate using those frequencies. Whereas the 1447 information provided by the Database must be accurate and conform to 1448 applicable regulatory rules, the Database cannot enforce, through the 1449 protocol, that a client device uses only the spectrum it provided. 1450 Specific requirements and security considerations for the PAWS 1451 protocol are described in 1452 [I-D.ietf-paws-problem-stmt-usecases-rqmts]. 1454 By using the PAWS protocol, the Master Device and the Database expose 1455 themselves to the following risks: 1456 o Accuracy: The Master Device receives incorrect spectrum- 1457 availability information. 1458 o Privacy: An unauthorized entity intercepts identifying data for 1459 the Master Device, such as serial number and location. 1461 Protection from these risks depends on the success of the following 1462 steps: 1464 1. The Master Device must determine a proper database. 1465 2. The Master Device must connect to the proper database. 1466 3. The database must determine or compute accurate spectrum- 1467 availability information. 1468 4. PAWS messages must be transmitted unmodified between the Database 1469 and the Master Device. 1470 5. PAWS messages must be encrypted to between the Database and the 1471 Master Device to prevent exposing private information. 1473 6. For a slave device, the spectrum-availability information also 1474 must be transmitted unmodified and secure between the Master 1475 Device and the slave device, but that is outside the scope of the 1476 PAWS protocol. 1477 Of these, only steps 2, 4, and 5 are within the scope of this 1478 document. [Editor's note: It is still open whether Step 1 is within 1479 the scope of this document]. Step 3 dependent on specific database 1480 implementations and regulatory rules and is outside the scope of this 1481 document. Step 6 requires a protocol between master and slave 1482 devices and is thus outside the scope of this document. 1484 10.1. Assurance of Proper Database 1486 This document assumes that the Database is contacted using a domain 1487 name or an IP address. Using HTTP over TLS [RFC2818], the Database 1488 authenticates its identity, either as a domain name or IP address, to 1489 the Master Device by presenting a certificate containing that 1490 identifier as a "subjectAltName" (i.e., as a dNSName or IP address). 1491 If the Master Device has external information as to the expected 1492 identity or credentials of the proper database (e.g., a certificate 1493 fingerprint), these checks MAY be omitted. Note that in order for 1494 the presented certificate to be valid at the client, the client must 1495 be able to validate the certificate. In particular, the validation 1496 path of the certificate must end in one of the client's trust 1497 anchors, even if that trust anchor is the Database certificate 1498 itself. [Editor's note: certificates can change certificate 1499 authorities (CAs) over time. Should there be a recommendation about 1500 not relying on a single, statically configured CA certificate in the 1501 Master Device?] 1503 10.2. Protection Against Modification 1505 To prevent a PAWS response message from being modified en route, 1506 messages must be transmitted over an integrity-protected channel. 1507 Using HTTP over TLS, the channel will be protected by appropriate 1508 cyphersuites. 1510 10.3. Protection Against Eavesdropping 1512 Using HTTP over TLS, messages protected by appropriate cyphersuites 1513 are also protected from eavesdropping or otherwise access by 1514 unauthorized parties en route 1516 10.4. Client Authentication Considerations 1518 Although the Database can inform a device of available spectrum it 1519 can use, the Database cannot enforce that the device uses any/only 1520 those frequencies. Indeed, a malicious device can operate without 1521 ever contacting a database. Consequently, client authentication is 1522 not required for the PAWS protocol. Depending on prior relationship 1523 between a database and device, the Database may require client 1524 authentication. TLS provides client authentication, but there are 1525 some considerations: 1527 o As indicated in Section 3.2 of [RFC2818], the TLS client 1528 authentication procedure only determines that the device has a 1529 certificate chain rooted in an appropriate CA. The database would 1530 not know what the client identity ought to be, unless it has some 1531 external source of information. Distribution and management of 1532 such information, including revocation lists, are outside the 1533 scope of this document. 1534 o Authentication schemes are secure only to the extent that secrets 1535 or certificates are kept secure. When there are a vast number of 1536 devices in the world using PAWS, the possibility that device keys 1537 will not leak becomes small. Implementations should consider how 1538 to manage the system in the eventuality that there is a leak. 1540 11. Contributors 1542 This document draws heavily from the following Internet Draft 1543 documents, [I-D.das-paws-protocol] and [I-D.wei-paws-framework]. The 1544 editor would like to specifically call out and thank the contributing 1545 authors of these two documents. 1547 Donald Joslyn 1548 Spectrum Bridge Inc. 1549 1064 Greenwood Blvd. 1550 Lake Mary, FL 32746 1551 U.S.A. 1552 Email: d.joslyn at spectrumbridge dot com 1554 Xinpeng Wei 1555 Huawei 1556 Phone: +86 13436822355 1557 Email: weixinpeng@huawei.com 1559 12. Acknowledgments 1561 The authors gratefully acknowledge the contributions of: Gabor Bajko, 1562 Teco Boot, Nancy Bravin, Rex Buddenberg, Gerald Chouinard, Stephen 1563 Farrell, Michael Fitch, Joel M. Halpern, Donald Joslyn, Jussi 1564 Kahtava, Warren Kumari, Paul Lambert, Andy Lee, Anthony Mancuso, 1565 Peter McCann, Basavaraj Patil, Scott Probasco, Brian Rosen, Andy 1566 Sago, Peter Stanforth, John Stine, and Juan Carlos Zuniga. 1568 13. References 1570 13.1. Normative References 1572 [ISO3166-1] 1573 "Country Codes", 1574 . 1576 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1577 Requirement Levels", BCP 14, RFC 2119, March 1997. 1579 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the 1580 Internet: Timestamps", RFC 3339, July 2002. 1582 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 1583 "Transport Layer Security (TLS) Session Resumption without 1584 Server-Side State", RFC 5077, January 2008. 1586 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1587 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1589 13.2. Informative References 1591 [I-D.das-paws-protocol] 1592 Das, S., Malyar, J., and D. Joslyn, "Device to Database 1593 Protocol for White Space", draft-das-paws-protocol-02 1594 (work in progress), July 2012. 1596 [I-D.ietf-paws-problem-stmt-usecases-rqmts] 1597 Probasco, S. and B. Patil, "Protocol to Access White Space 1598 database: PS, use cases and rqmts", 1599 draft-ietf-paws-problem-stmt-usecases-rqmts-08 (work in 1600 progress), August 2012. 1602 [I-D.wei-paws-framework] 1603 Wei, X., Zhu, L., and P. McCann, "PAWS Framework", 1604 draft-wei-paws-framework-00 (work in progress), July 2012. 1606 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 1608 Appendix A. Changes / Author Notes. 1610 Notes: 1612 o For date-time format this is referencing RFC3339, instead of 1613 ISO8601 as discussed on the list, since it is more precise in its 1614 definition and is a real RFC. Is that acceptable? 1615 o Change needed: maxValidityTime in RulesetInfo doesn't work for US/ 1616 FCC, since the rule indicates 11:59 of following day (no timezone 1617 specified), which cannot be expressed as a duration 1619 Authors' Addresses 1621 Vincent Chen (editor) 1622 Google 1623 1600 Amphitheatre Parkway 1624 Mountain View, CA 94043 1625 US 1627 Email: vchen@google.com 1629 Subir Das 1630 Applied Communication Sciences 1631 444 Hoes Lane 1632 Piscataway, NJ 08854 1633 U.S.A. 1635 Phone: 1636 Fax: 1637 Email: sdas at appcomsci dot com 1638 URI: 1640 Zhu Lei 1641 Huawei 1643 Phone: +86 13910157020 1644 Fax: 1645 Email: lei.zhu@huawei.com 1646 URI: 1648 John Malyar 1649 Telcordia Technologies Inc. 1650 1 Ericsson Drive 1651 Piscataway, NJ 08854 1652 U.S.A. 1654 Phone: 1655 Fax: 1656 Email: jmalyar at telcordia dot com 1657 URI: 1659 Peter J. McCann 1660 Huawei 1661 400 Crossing Blvd, 2nd Floor 1662 Bridgewater, NJ 08807 1663 USA 1665 Phone: +1 908 541 3563 1666 Fax: 1667 Email: peter.mccann@huawei.com 1668 URI: