idnits 2.17.1 draft-wei-paws-framework-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 == Line 982 has weird spacing: '...t power dbm...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (July 9, 2012) is 4281 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-15) exists of draft-ietf-paws-problem-stmt-usecases-rqmts-06 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force X. Wei 3 Internet-Draft L. Zhu 4 Intended status: Standards Track P. McCann 5 Expires: January 10, 2013 Huawei 6 July 9, 2012 8 PAWS Framework 9 draft-wei-paws-framework-00 11 Abstract 13 Portions of the radio spectrum that are allocated to a licensed, 14 primary use but are unused or unoccupied at specific locations and 15 times are defined as "white space". White space devices can make use 16 of this spectrum; however, they must first determine which spectrum 17 is unused or unoccupied by a primary user at their current location. 18 A white space database can be consulted that holds information about 19 primary users of the spectrum and that returns information about 20 white space. In this document we introduce a Protocol for Access to 21 WhiteSpace database (PAWS) which is for use between a white space 22 device and a white space database. We give a framework for PAWS, a 23 protocol stack that defines the interface between the white space 24 device and the white space database, the parameters of the protocol, 25 an XML schema that can encode the parameters, and example messages. 26 The realization of the database and the calculation of protected 27 contour are not considered in this framework draft. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on January 10, 2013. 46 Copyright Notice 48 Copyright (c) 2012 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Terminology and Abbreviation . . . . . . . . . . . . . . . . . 5 65 2.1. Conventions Used in This Document . . . . . . . . . . . . 5 66 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 67 3. Overview of PAWS . . . . . . . . . . . . . . . . . . . . . . . 6 68 4. Protocol Stack . . . . . . . . . . . . . . . . . . . . . . . . 9 69 5. Protocol Framework and Interface of PAWS . . . . . . . . . . . 10 70 5.1. Database Discovery . . . . . . . . . . . . . . . . . . . . 11 71 5.2. Device Registration with Trusted Database . . . . . . . . 11 72 5.3. White Space Channel Query . . . . . . . . . . . . . . . . 14 73 5.4. Validation Procedure . . . . . . . . . . . . . . . . . . . 18 74 5.5. White Space Channel Update . . . . . . . . . . . . . . . . 20 75 5.6. Result Codes . . . . . . . . . . . . . . . . . . . . . . . 20 76 6. Message Encoding . . . . . . . . . . . . . . . . . . . . . . . 22 77 6.1. XML Schema Definition . . . . . . . . . . . . . . . . . . 22 78 6.2. HTTP Encoding . . . . . . . . . . . . . . . . . . . . . . 27 79 7. Security Considerations . . . . . . . . . . . . . . . . . . . 33 80 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 81 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35 82 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 83 10.1. Normative References . . . . . . . . . . . . . . . . . . . 36 84 10.2. Informative References . . . . . . . . . . . . . . . . . . 36 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37 87 1. Introduction 89 "White Space" means the radio spectrum that has been allocated for 90 some primary use, but is not fully occupied by that primary use at a 91 specific location and time. Currently the white space in television 92 bands (which is called TV white space (TVWS)) is widely discussed; 93 TVWS has some good characteristics such as propagation 94 characteristics and low power consumption. The regulatory bodies in 95 some countries have created rules allowing secondary white space 96 access; the secondary user must ensure it does not interfere with the 97 primary user when using white space. The purpose of white space 98 study is to design a mechanism that enables the secondary user to use 99 the white space resource without interfering with the primary user. 100 The widely accepted scheme of utilizing white space is by querying a 101 database. This document defines a protocol over which such a 102 database may be queried, called the "Protocol to Access White Space 103 database (PAWS)". The use cases and requirements of PAWS have been 104 discussed in another document [2]. 106 The master devices may be produced by different manufacturers and 107 there may be multiple databases serving a geographic area 108 administered by different administrators. To ensure interoperability 109 between these devices and databases, a standard interface needs to be 110 defined. This document defines that interface. 112 Spectrum management rules of different spectrum regulatory bodies are 113 different, so the white space spectrum databases may be designed to 114 implement different spectrum policies in different regulatory 115 domains. In order to satisfy the needs of these disparate regulatory 116 domains, the database query protocol MUST be independent of different 117 spectrum management rules. PAWS is a protocol between a master 118 device and a database that carries information about white space 119 spectrum from the database to a master device. The master device 120 could act as a WiFi AP or a cellular base station (e.g. 3GPP LTE 121 eNodeB) in the whitespace spectrum; the PAWS protocol is agnostic to 122 the technology used by the master device. A slave device is the 123 device which uses the spectrum made available by a master device. 124 After the master device has obtained information about white space 125 spectrum from the database and formed a wireless access network, the 126 slave device can access it. 128 In this document we introduce a framework for the PAWS protocol, a 129 protocol stack defining an interface between a master device and a 130 whitespace database, a set of messages and their associated 131 parameters, and an XML schema encoding the messages and parameters. 132 Co-existence of multiple whitespace devices in the same geographic 133 area and interference avoidance between white space devices within 134 the same spectrum are out of scope of the current protocol. 136 Provisioning and how databases store the white space information are 137 also out of scope of the protocol. 139 There is much sensitive information, such as location and identity, 140 which MAY be transmitted between the master device and the database 141 when PAWS is used. Attackers may attempt to obtain such information 142 during the operation of the protocol. Therefore, the messaging 143 interface between the master device and the database needs to be 144 secured. Meanwhile, the two entities SHALL be the authorized and 145 mutually authenticated. This document assumes that PAWS can be run 146 over an HTTPS connection, but details of how security credentials are 147 issued, managed, and validated among the various entities (databases, 148 master devices and slave devices) are out of scope of the basic 149 protocol and should be specified in a different document. 151 Given that multiple databases may serve a given region, and that a 152 master device may move from region to region, a mechanism to discover 153 the proper database to query must be provided in the master device. 154 This document provides an overview of possible mechanisms that can be 155 used for this purpose, but does not define any new protocols in this 156 area. 158 2. Terminology and Abbreviation 160 2.1. Conventions Used in This Document 162 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 163 NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 164 thisdocument are to be interpreted as described in [1]. 166 2.2. Terminology 168 The Terminology Section of the latest version of the PAWS Problem 169 Statement and Use Cases draft [2] shall be included by reference. 171 WS Interface 173 The interface between master device and whitespace database, 174 including the data model and protocol messages defined in this 175 document. 177 RAT 179 Radio Access Technology. 181 3. Overview of PAWS 183 We first define the entities of Master Device and Database, and the 184 common interface between these two entities. 186 Figure 1 shows a common system model consisting of Master Device and 187 Database. The Master Device connects to the database directly using 188 the WS interface. 190 This document defines the data model and protocol messaging 191 procedures of the WS interface. The messages of WS are encoded in 192 XML, with security provided by HTTPS, and reliable in-order delivery 193 provided by TCP. More details about the protocol of WS see section 194 "protocol stack". 196 +-------+ +--------+ 197 |Master | WS Interface | | 198 |Device +--------------+Database| 199 | | | | 200 +-------+ +--------+ 202 Figure 1: System Model of PAWS 204 The master device in Figure 1 queries for a list of available 205 channels from the database so it can provide radio access for user 206 equipments. It can be a WiFi access point, a base station of 3GPP 207 WCDMA or 3GPP LTE, or some other RAT. The master device can send its 208 own information (such as device ID, geo-location etc.) to the 209 database to query white space spectrum for itself, or it can send the 210 information from other devices to the database to query white space 211 spectrum for other devices. 213 The database in Figure 1 is in charge of storing and maintaining 214 white space channel information for certain area(s). There may be 215 one or more databases providing white space information for a given 216 area. The main function of the database is to provide suitable white 217 space spectrum information to master devices. The databases are 218 assumed to be on the Internet and can be accessed by the master 219 devices via any Internet connection. When the database receives a 220 request for white space spectrum from the master device, it will 221 respond with a list of available white space channels to the master 222 device if there are available channels. How the database stores the 223 white space spectrum information and the policies for which white 224 space spectrum can be returned to a master device is outside the 225 scope of this document. 227 As shown in Figure 2 in order to provide wireless access based on 228 white space, there are several procedures involved. These include 229 database discovery, secure connection establishment, device 230 registration, and white space channel query. 232 +-----------------------------+ 233 | Master device decide to use | 234 | white space to provide | 235 | wireless access | 236 +-----------------------------+ 237 | 238 V 239 +--------------------+ 240 | Database discovery | 241 +--------------------+ 242 | 243 V 244 +-----------------------------+ 245 | Master device decide which | 246 | database to connect to and | 247 | then establishes a security | 248 | connection with the database| 249 +-----------------------------+ 250 | 251 V 252 +---------------------+ 253 | Device registration | 254 +---------------------+ 255 | 256 V 257 +---------------------------+ 258 | White space channel query | 259 +---------------------------+ 260 | 261 V 262 +------------------------------+ 263 | Master device gets available | 264 | white space channel list and | 265 | provides wireless access | 266 +------------------------------+ 268 Figure 2: The procedure for getting white space channel for master 269 device 271 When the master device is to provide radio access service, it is 272 required to execute the following steps: 274 1. Database discovery. When the master device needs to connect to 275 database, it must know the Internet address of the database and 276 it has to decide to which database to connect when there is more 277 than one database. A database discovery mechanism is needed. 278 There may be several mechanism for database discovery, for 279 example, DNS. 281 2. Registration. Registration is an optional procedure of PAWS. In 282 particular, requirements for registration come from individual 283 regulatory domains and can be different depending on the 284 regulator's individual requirements. When registration is used, 285 before the database provides information on available radio 286 channels, the master device MUST register with the trusted 287 database. In the registration procedure, the information may 288 include but is not limited to device ID, device owner's name, 289 device owner's email address, device owner's phone number etc. 291 3. White space channel query. The white space channel query 292 procedure from master device to database is based on a client- 293 server model. When a master device is to create a radio network 294 using white space, it queries available white space channel 295 information from the database by sending a query message and 296 receiving a response containing available whitespace channel(s). 298 4. White space channel update. The white space channel returned to 299 master device is available for a limited duration of time, which 300 means that when this time expires the channel can not be used by 301 the master device any more, and then the master device must 302 obtain updated white space channel information from the database. 303 There are also some requirements from regulatory bodies that the 304 white space channel information MUST be updated periodically. 305 The update mechanism is necessary and is needed to avoid 306 interfering with the primary user or other secondary user. A 307 mechanism to update the whitespace information is provided in 308 this draft. 310 Considering the security aspects, there is a trust relationship 311 between the database and master devices. There SHOULD be 312 corresponding authentication, integrity protection, and 313 confidentiality protection mechanisms between the master device. 314 Security considerations are given in Section 7; details of the 315 security procedure at the beginning of an HTTPS connection is not 316 included in this document. 318 4. Protocol Stack 320 The protocol specified here is an application protocol that depends 321 on a lower-layer transport protocol, which must provide the necessary 322 features and security properties for use as the building blocks for 323 communication between location-aware devices and white space 324 databases. The service model between master device and database is 325 client-server using request/response messages. 327 A protocol stack model is proposed here, shown in Figure 3. The 328 transport layer is TCP and the application runs over HTTPS. 330 +------------+ +------------+ 331 | WS.App +-------------+ WS.App | 332 +------------+ +------------+ 333 | HTTPS +-------------+ HTTPS | 334 +------------+ +------------+ 335 | TCP +-------------+ TCP | 336 +------------+ +------------+ 337 | IP +-------------+ IP | 338 +------------+ +------------+ 339 Master Device Database 341 Figure 3: Protocol Stack of PAWS 343 WS.App is the white space spectrum application protocol. The 344 messages of WS are encoded in XML, packaged in HTTP requests and 345 responses, encrypted by TLS, and transported by TCP. The element 346 types used in the XML encoding of messages are defined in Section 6. 348 5. Protocol Framework and Interface of PAWS 350 The use of white space spectrum is enabled after a white space device 351 queries a database and obtains information about the availability of 352 spectrum for use at a given location. The databases are reachable 353 via the Internet and the devices querying these databases are 354 expected to have some form of Internet connectivity. There could be 355 multiple databases serving white space devices and a master device 356 can select one of them for use. The architecture is shown in 357 Figure 4. 359 ----------- 360 |WS Device| ------------ 361 |Lat: X |\ .---. /------|Database X| 362 |Long: Y | \ ( ) / ------------ 363 ----------- \----( )/ o 364 ( ) 365 ( Internet ) o 366 ( ) 367 ----------- /----(_ )\ o 368 |WS Device| / (___) \ ------------ 369 |Lat: X |/ \------|Database Y| 370 |Long: Y | ------------ 371 ----------- 373 Figure 4: High Level View of the White Space Database Architecture 375 A messaging interface between the white space devices and the 376 database is required for operating a network using the white space 377 spectrum. The following sections discuss various aspects of such an 378 interface. Other aspects of a solution including provisioning the 379 database and calculating protected contours are considered out of 380 scope of this document. 382 In order to query white space channel(s) from a database, a master 383 device must provide its geo-location information to the database. 384 There are several different methods for a master device to get its 385 geo-location information; for example, using GPS technology, using 386 street number or building location information etc. 388 The protocol message interface defines the message contents and 389 message format of WS. The message interface should satisfy the 390 following requirements: 392 1. The message sent in the message interface should be independent 393 of the specific radio interface technologies (e.g. 802.11af, IEEE 394 802.16, IEEE 802.22, LTE); 396 2. The message interface should be spectrum agnostic. The message 397 interface should not only be used for TV white space but also be 398 used for other spectrum; 400 3. The message interface should satisfy different scenarios for 401 using white space. In different scenarios the white space 402 device's coverage area and the bandwidth may be different; 404 4. The message should address different regulations by different 405 regulatory bodies; 407 5. Security requirements, such as ciphering and integrity protection 408 must be met. 410 5.1. Database Discovery 412 Before the white space device can transmit in white space spectrum, 413 it MUST contact a trusted database where the device can learn if any 414 channels are available for it to use. In order to connect to the 415 trusted database the master device MUST get the IP address of the 416 database. 418 The master device MAY be pre-programmed with the Internet IP address 419 of trusted database manually. The master device can establish 420 contact with a trusted database using one of the pre-provisioned IP 421 addresses. We call this method "static database discovery". 423 Alternatively, the master device may discover the IP address of the 424 database dynamically through the use of a DNS query. It may be 425 configured with the DNS name of a database that is valid for its 426 current location or may discover the name of an appropriate database 427 through means outside the scope of this specification. 429 5.2. Device Registration with Trusted Database 431 A registration procedure is used to register the master device's 432 information in the database. Some databases may refuse to respond to 433 queries from unauthorized or uncertified devices. The registration 434 procedure is optional; master devices may not be required to 435 register, depending on the regulator's requirements. When 436 registration is used, before the database will provide information on 437 available radio channels, the master device must register with the 438 trusted database. In the registration procedure, the information may 439 include but is not limited to, device ID, device owner's name, device 440 owner's email address, device owner's phone number etc. 442 Specific events will initiate registration; these events are 443 determined by regulator policy, for examples: 445 1. The master device will operate in white space for the first time 446 after power up. 448 2. The location of master device changes by a predetermined 449 distance. 451 3. After a certain regular time interval. 453 4. When the registered information changed, and the master device 454 need update its registration information. 456 The device registration procedure consists of two messages: 458 1. Registration request message. This message is from master device 459 to database. The master device shall provide to the database 460 during registration all information required according to local 461 regulatory requirements. 463 2. Registration response message. This message is from database to 464 master device. The database responds to the registration request 465 with an acknowledgement code to indicate the success or failure 466 of the registration request. Additional information may be 467 provided according to local regulator requirements. 469 One of two possible results shall be returned by the database: 471 1. Successful Registration. 473 2. Failed Registration. The master device is not recognized or 474 authorized by the database. 476 A successful registration will overwrite any previous registration 477 information for the same master device, as identified by device ID 478 and manufacturer's serial number. 480 The device registration procedure is depicted in Figure 5. 481 REGISTRATION_REQ is the registration request message; 482 REGISTRATION_RESP is the registration response message. 484 +---------------+ +---------------+ 485 | Master Device | | Database | 486 +---------------+ +---------------+ 487 | | 488 | REGISTRATION_REQ | 489 |--------------------------------->| 490 | | 491 | | 492 | REGISTRATION_RESP | 493 |<---------------------------------| 494 | | 495 | | 497 Figure 5: Device Registration with Database Procedure 499 The registration procedure consists the following steps: 501 1. The master device sends registration request message to the 502 trusted database. In this message the parameters to be 503 registered are included. 505 2. The database sends the registration response message to the 506 master device indicating whether the registration is successful 507 or not, Additional information may be provided according to local 508 regulator requirements. 510 The parameters included in REGISTRATION_REQ are as follows: 512 +----------------+--------------------------------------------------+ 513 | Parameter | Description | 514 +----------------+--------------------------------------------------+ 515 | device id | Device id of master device. | 516 | | | 517 | device type | Device type defined by Regional Regulators, | 518 | | including fixed, mobile, portable, etc. | 519 | | | 520 | manufacturer's | The manufacturer's serial number of device. | 521 | serial number | | 522 | | | 523 | device owner's | Includes: name of the individual or business | 524 | information | that owns the device, name of a contact person | 525 | | responsible for the device's operation, address | 526 | | for the contact person, and email address for | 527 | | the contact person and phone number of the | 528 | | contact person. | 529 +----------------+--------------------------------------------------+ 531 Table 1: Parameters of the REGISTRATION_REQ Message 533 The parameters included in the REGISTRATION_RESP are as follows: 535 +-----------+-------------------------------------------------------+ 536 | Parameter | Description | 537 +-----------+-------------------------------------------------------+ 538 | result | Consists of a code number with related description in | 539 | code | text which indicates whether the registration request | 540 | | is successful or failed; if it failed the result code | 541 | | will indicate the reason of failure. | 542 +-----------+-------------------------------------------------------+ 544 Table 2: Parameters of the REGISTRATION_RESP Message 546 5.3. White Space Channel Query 548 When master device is to create a radio network using white space, it 549 queries for available white space channels from the database. The 550 master device sends a white space channel query message to the 551 database and fetches white space channel(s) from the database. 553 The channel query procedure consists of four messages: 555 1. Channel query request message. This message is from the master 556 device to the database. The channel query request message takes 557 parameters as required by local regulatory requirements to the 558 database; these parameters will be used by the database to decide 559 the available white space channel(s) for the master device; 561 2. Channel query response message. This message is from the 562 database to the master device. The channl query response message 563 takes parameters as required by local regulatory requirements to 564 the master device; the white space query result code of success 565 or fail will be included in this message. If there are available 566 white space channel(s) for the master device, the result code of 567 success will be returned to the master device and the 568 availability white space channel(s) with related information will 569 be returned to the master device; otherwise, if there is no 570 available white space channel for the master device, the result 571 code of failure with the failure reason will be returned to the 572 master device; 574 3. Channel usage report message. This message is from the master 575 device to the database. When the master device receives the 576 white space channel(s) returned from the database, it uses this 577 message to inform the database of the anticipated channel usage. 578 Because not all of the regulatory rules require the reporting 579 back of usage, some databases may not support this message, so it 580 is optional. 582 4. Channel usage acknowledge message. This message is from the 583 database to the master device. This message is an 584 acknowledgement of the channel usage report message. This 585 message will be sent only when the channel usage report message 586 is used. 588 The white space channel query procedure is depicted in Figure 6. 589 AVAIL_WS_REQ is the available white space query request message; 590 AVAIL_WS_RESP is the available white space query response message; 591 CHANNEL_USAGE_REPORT is the channel usage report message; 592 CHANNEL_USAGE_ACK is the channel usage acknowledge message. 594 +---------------+ +---------------+ 595 | Master Device | | Database | 596 +---------------+ +---------------+ 597 | | 598 | AVAIL_WS_REQ | 599 |--------------------------------->| 600 | | 601 | | 602 | AVAIL_WS_RESP | 603 |<---------------------------------| 604 | | 605 | | 606 | CHANNEL_USAGE_REPORT | 607 |--------------------------------->| 608 | | 609 | | 610 | CHANNEL_USAGE_ACK | 611 |<---------------------------------| 612 | | 613 | | 615 Figure 6: The Available Channel Query Procedure 617 The query procedure using the following steps: 619 1. The master device sends the white space query request message to 620 database and waits a limited period of time for white space query 621 response message from the database. When the time expires and no 622 query response message is returned from the database, the query 623 procedure will be failed. 625 2. On receiving the white space query request message, database will 626 find out the available white space channels and send the 627 available white space channel list to the white space device. 628 The result code in the query response message (AVAIL_WS_RESP 629 message) will indicate whether the channel usage report message 630 is needed to be sent. 632 3. If the channel usage message is needed, the master device will 633 send the channel usage message to the database after receiving 634 the query response message. If there is no available channel or 635 no acceptable response is received within the limited time, the 636 master device concludes that no channel is available. 638 4. When the database receives channel usage report message, it will 639 acknowledge the master device of receiving the message by channel 640 usage acknowledge message. 642 The parameters included in AVAIL_WS_REQ are as follows: 644 +-----------------+-------------------------------------------------+ 645 | Parameter | Description | 646 +-----------------+-------------------------------------------------+ 647 | device id | Device id of master device that sends the query | 648 | | message. | 649 | | | 650 | device type | Device type defined by Regional Regulators, | 651 | | including fixed, mobile, portable, etc. | 652 | | | 653 | List of | A list of coverage area(s) where white space | 654 | coverage | access service will be provided. This field | 655 | area(s) | includes: geo-location (latitude, longitude) of | 656 | information | the master device, uncertainty of geo-location | 657 | | (in meters), and confidence (in percentage) for | 658 | | the location determination, coverage range. | 659 | | | 660 | antenna | Antenna characteristics of the master device | 661 | characteristics | that will use the white space. This field | 662 | | includes: antenna height above the ground, | 663 | | antenna direction, antenna radiation pattern, | 664 | | antenna gain, maximum output power, spectrum | 665 | | mask. | 666 | | | 667 | RAT type | Specifies information about the type of RAT of | 668 | | the master device. | 669 | | | 670 | bandwidth | Bandwidth that the master device needs to form | 671 | | the wirelss network. | 672 +-----------------+-------------------------------------------------+ 674 Table 3: Parameters of the AVAIL_WS_REQ Message 676 The parameters included in AVAIL_WS_RESP are as follows: 678 +-----------+-------------------------------------------------------+ 679 | Parameter | Description | 680 +-----------+-------------------------------------------------------+ 681 | device id | Device id of master device, the value of this field | 682 | | is the same as the device id in AVAIL_WS_REQ message. | 683 | | | 684 | device | Device type defined by Regional Regulators, including | 685 | type | fixed, mobile, portable, etc. The value of this | 686 | | field is the same as the device type in AVAIL_WS_REQ | 687 | | message. | 688 | | | 689 | result | Consists of a code number with related description in | 690 | code | text which indicates whether the available white | 691 | | space request is successful or failed; if it has | 692 | | failed the result code will indicate the reason of | 693 | | failure. | 694 | | | 695 | white | This field includes: frequency information, available | 696 | space | bandwidth, available time duration, coverage area, | 697 | channel | maximum transmission power. | 698 | list | | 699 +-----------+-------------------------------------------------------+ 701 Table 4: Parameters of the AVAIL_WS_RESP Message 703 The parameters included in CHANNEL_USAGE_REPORT are as follows: 705 +------------+------------------------------------------------------+ 706 | Parameter | Description | 707 +------------+------------------------------------------------------+ 708 | device id | Device id of master device that sends the query | 709 | | message. | 710 | | | 711 | white | This field includes: frequency information, | 712 | space | available bandwidth, available time duration, | 713 | channel | coverage area, maximum transmission power. | 714 | list | | 715 +------------+------------------------------------------------------+ 717 Table 5: Parameters of the CHANNEL_USAGE_REPORT Message 719 The parameters included in CHANNEL_USAGE_ACK are as follows: 721 +-----------+-------------------------------------------------------+ 722 | Parameter | Description | 723 +-----------+-------------------------------------------------------+ 724 | result | Consists of a code number with related description in | 725 | code | text which indicates whether the CHANNEL_USAGE_REPORT | 726 | | message is received by the database. | 727 +-----------+-------------------------------------------------------+ 729 Table 6: Parameters of the CHANNEL_USAGE_ACK Message 731 5.4. Validation Procedure 733 The validation procedure is used for the database to validate the 734 slave device. When the slave device connects to the master device, 735 the master device MAY start the validation procedure to validate the 736 slave device. 738 The validation procedure consists of two messages: 740 1. Validation request message. This message is from master device 741 to database. After the slave device connects to the master 742 device, the master device can send the slave's validation 743 information such as slave device ID, slave device's manufacturer 744 serial number etc to the database in validation request message. 746 2. Validation response message. This message is from the database 747 to the master device. This message is used to indicate if the 748 slave device is validated by the database. 750 The validation procedure is depicted in Figure 7. VALIDATION_REQ is 751 the validation request message; VALIDATION_RESP is the validation 752 response message. 754 +---------------+ +---------------+ 755 | Master Device | | Database | 756 +---------------+ +---------------+ 757 | | 758 | VALIDATION_REQ | 759 |--------------------------------->| 760 | | 761 | | 762 | VALIDATION_RESP | 763 |<---------------------------------| 764 | | 765 | | 767 Figure 7: Slave Device Validation with Database Procedure 769 The validation procedure using the following steps: 771 1. After the slave device has connected to the master device and 772 sent its slave device id and slave device type to the master 773 device, the master device will send slave device id included in 774 VALIDATION_REQ message to the database. 776 2. The database validates the slave device and returns the result 777 code to the master device. The result code indicates whether the 778 slave device is validated or not, and if the slave device is not 779 validated the result code will indicate the reason of not 780 validated. 782 3. If the the slave device is validated by the database, the white 783 space device will provide service to the slave device, otherwise 784 the master device will deny the slave device's access. 786 The parameters included in VALIDATION_REQ are as follows: 788 +----------------+--------------------------------------------------+ 789 | Parameter | Description | 790 +----------------+--------------------------------------------------+ 791 | device id | Slave device id. | 792 | | | 793 | device type | Slave's device type defined by Regional | 794 | | Regulators, including fixed, mobile, portable, | 795 | | etc. | 796 | | | 797 | device owner's | Identification of the individual or business | 798 | information | that owns the device. | 799 +----------------+--------------------------------------------------+ 801 Table 7: Parameters of the VALIDATION_REQ Message 803 The parameters included in VALIDATION_RESP are as follows: 805 +-----------+-------------------------------------------------------+ 806 | Parameter | Description | 807 +-----------+-------------------------------------------------------+ 808 | result | Consists of a code number with related description in | 809 | code | text which indicates whether thelave device is | 810 | | validated or not; if it's failed the result code will | 811 | | indicate the reason for failure. | 812 +-----------+-------------------------------------------------------+ 814 Table 8: Parameters of the VALIDATION_RESP Message 816 5.5. White Space Channel Update 818 The availability of a white space channel may be changed, because a 819 primary user may obtain the channel. 821 In order to avoid interfering with the primary user or other 822 secondary user, the white space updating mechanism is provided in 823 this document. 825 The white space channel update procedure is used for master device to 826 update the white space channel from the database. The update 827 procedure SHOULD be implemented when one of the followings occurs: 829 1. Periodically implemented as required by the regulation to verify 830 that the operating channels continue to remain available. 832 2. When master device changes its location more than a threshold 833 distance. 835 The white space device MUST access the database to obtain and update 836 the list of available channels that could be utilized by the device 837 to verify that the operating channels continue to remain available. 838 According to some regulatory rules the white space device SHOULD 839 update the white space channel periodically, and the period may be 840 different due to different regulatory rules. 842 The white space channel update mechanism is based on the white space 843 channel query procedure. After the master device gets a white space 844 channel from the database, a white space channel update timer is set 845 to a certain value, which is determined by local regulatory body, 846 when the timer expires the master device will start white space 847 channel query procedure to query white space channels from the 848 database. 850 When the master device changes its location more than a threshold 851 distance it SHOULD query the database for available operating 852 channels, the value of threshold is specified by local regulatory 853 policy. 855 5.6. Result Codes 857 The following result codes are provided by the database on responses 858 to the master device to communicate the status of requests made by 859 the master device; all of the result codes used in this document is 860 defined here. 862 +------+--------------------------------+---------------------------+ 863 | Code | Description | Returned Text | 864 +------+--------------------------------+---------------------------+ 865 | 0 | successful | "successful" | 866 | | | | 867 | 1 | successful with no channel | "no channel available" | 868 | | available | | 869 | | | | 870 | 2 | Successful and | "CHANNEL_USAGE_REPORT | 871 | | CHANNEL_USAGE_REPORT message | message needs to be sent" | 872 | | needs to be sent. | | 873 | | | | 874 | 3 | Successful and | "CHANNEL_USAGE_REPORT | 875 | | CHANNEL_USAGE_REPORT message | message needs not to be | 876 | | needs not to be sent. | sent" | 877 | | | | 878 | 4 | device id is invalid | "device id is invalid" | 879 | | | | 880 | 5 | device type is invalid | "device type is invalid" | 881 | | | | 882 | 6 | device type is not supported | "device type is not | 883 | | | supported" | 884 | | | | 885 | 7 | Device has not registered | "Device has not | 886 | | | registered" | 887 +------+--------------------------------+---------------------------+ 889 Table 9: Result Codes 891 6. Message Encoding 893 6.1. XML Schema Definition 895 896 899 901 902 903 904 906 907 908 909 910 911 913 914 915 916 918 919 920 921 922 923 925 926 927 928 929 930 931 933 934 936 937 938 939 940 941 942 944 945 946 947 948 949 951 952 953 954 955 956 957 958 959 960 961 962 963 965 966 968 969 970 971 972 973 974 976 985 986 987 988 989 990 991 992 994 998 999 1000 1002 1006 1007 1008 1009 1010 1011 1013 1014 1015 1016 1018 1020 1021 1022 1024 1026 1027 1029 1034 1035 1036 1038 1039 1040 1041 1042 1043 1044 1045 1046 1048 1050 1051 1052 1053 1054 1055 1056 1057 1058 1059 1060 1061 1063 1064 1065 1066 1067 1068 1069 1070 1071 1073 1074 1075 1076 1077 1079 1080 1081 1082 1083 1084 1085 1086 1087 1089 1090 1091 1092 1093 1094 1095 1096 1097 1098 1099 1100 1101 1103 1104 1105 1106 1107 1108 1109 1110 1111 1112 1113 1115 1116 1117 1118 1119 1120 1121 1122 1123 1124 1125 1126 1127 1128 1129 1130 1131 1132 1133 1134 1135 1137 1138 1139 1140 1141 1142 1143 1144 1145 1146 1148 6.2. HTTP Encoding 1150 This section will describe how to encode the PAWS protocol message of 1151 XML format in HTTP protocol. The PAWS protocol messages of XML 1152 format are carried as an entity of HTTP message. 1154 Here are some examples of how to encode PAWS messages of XML format 1155 in HTTP protocol. 1157 1. Registration Request message. 1159 PUT {URL} HTTP/1.1 1161 Accept: */* 1162 Proxy-Connection: Keep-Alive 1163 Host: {host name} 1164 Content-Type: text/xml 1166 1167 < REGISTRATION_REQ_MSG xmlns="http://tools.ietf.org/wg/paws/"> 1168 < version>{_version} 1169 < deviceID >{_deviceID} 1170 < device >{_ device } 1171 < manufactureSeqNum >{_ manufactureSeqNum } 1172 < deviceOwnerInfo >{_ deviceOwnerInfo } 1173 1174 where 1176 {URL} is the URL of the database. 1178 {host name} is the host name of the database. 1180 {_version}, {_deviceID}, {_device}, {_manufactureSeqNum }, 1181 {_antennaCharacter }, {_deviceOwnerInfo } are the elements 1182 defined in the XML schema. 1184 2. Registration Response message. 1186 HTTP/1.1 200 OK 1188 Cache-Control: private 1189 Content-Length: {LENGTH} 1190 Content-Type: application/xml; charset=utf-8\r\n 1192 1193 < REGISTRATION_RESP_MSG xmlns="http://tools.ietf.org/wg/paws/"> 1194 {_version} 1195 < result >{_result} 1196 1197 REGISTRATION_RESP_MSG 1199 where 1201 {LENGTH} is the length of the XML body. 1203 {_version}, {_result} are the elements defined in the XML 1204 schema. 1206 3. Available white space channel query request message. 1208 GET {URL} HTTP/1.1 1210 Accept: */* 1211 Proxy-Connection: Keep-Alive 1212 Host: {host name} 1213 Content-Type: text/xml 1215 1216 < AVAIL_WS_REQ_MSG xmlns="http://tools.ietf.org/wg/paws/"> 1217 {_version} 1218 < deviceID >{_deviceID} 1219 < device >{_ device } 1220 < coverageAreaList >{_ coverageAreaList } 1221 < antennaCharacter >{_ antennaCharacter } 1222 {_rat} 1223 < bandwidth >{_ bandwidth } 1225 1227 where 1229 {URL} is the URL of the database. 1231 {host name} is the host name of the database. 1233 {_version}, {_deviceID}, {_device}, {_coverageAreaList }, 1234 {_antennaCharacter }, {_rat}, {_bandwidth } are the elements 1235 defined in the XML schema. 1237 4. Available white space channel query response message. 1239 HTTP/1.1 200 OK 1241 Cache-Control: private 1242 Content-Length: {LENGTH} 1243 Content-Type: application/xml; charset=utf-8\r\n 1245 1246 < AVAIL_WS_RESP_MSG xmlns="http://tools.ietf.org/wg/paws/"> 1247 {_version} 1248 < deviceID >{_deviceID} 1249 < device >{_device } 1250 < result >{_result } 1251 < channelList>{_channelList} 1252 1254 where 1255 {LENGTH} is the length of the XML body. 1257 {_version}, {_deviceID}, {_device }, {_result} are the 1258 elements defined in the XML schema. 1260 5. Channel usage report message. 1262 PUT {URL} HTTP/1.1 1264 Accept: */* 1265 Proxy-Connection: Keep-Alive 1266 Host: {host name} 1267 Content-Type: text/xml 1269 1270 < CHANNEL_USAGE_REPORT xmlns="http://tools.ietf.org/wg/paws/"> 1271 {_version} 1272 < deviceID >{_deviceID} 1273 < channelList>{_ channelList} 1274 1276 where 1278 {URL} is the URL of the database. 1280 {host name} is the host name of the database. 1282 {_version}, {_deviceID}, {_channelList} are the elements 1283 defined in the XML schema. 1285 6. Channel usage report acknowledge message. 1287 HTTP/1.1 200 OK 1289 Cache-Control: private 1290 Content-Length: {LENGTH} 1291 Content-Type: application/xml; charset=utf-8\r\n 1293 1294 < CHANNEL_USAGE_ACK xmlns="http://tools.ietf.org/wg/paws/"> 1295 {_version} 1296 < result >{_ result } 1297 1299 where 1301 {LENGTH} is the length of the XML body. 1303 {_version}, {_ result} are the elements defined in the XML 1304 schema. 1306 7. Validation request message. 1308 PUT {URL} HTTP/1.1 1310 Accept: */* 1311 Proxy-Connection: Keep-Alive 1312 Host: {host name} 1313 Content-Type: text/xml 1315 1316 < VALIDATION_REQ xmlns="http://tools.ietf.org/wg/paws/"> 1317 {_version} 1318 < deviceID >{_deviceID} 1319 {_ device } 1320 < deviceOwnerInfo >{_ deviceOwnerInfo } 1321 1323 where 1325 {URL} is the URL of the database. 1327 {host name} is the host name of the database. 1329 {_version}, {_deviceID}, {_ device }, {_ deviceOwnerInfo }are 1330 the elements defined in the XML schema. 1332 8. Validation response message. 1334 HTTP/1.1 200 OK 1336 Cache-Control: private 1337 Content-Length: {LENGTH} 1338 Content-Type: application/xml; charset=utf-8\r\n 1340 1341 < VALIDATION_RESP xmlns="http://tools.ietf.org/wg/paws/"> 1342 {_version} 1343 < result >{_ result } 1344 1346 where 1348 {LENGTH} is the length of the XML body. 1350 {_version}, {_ result} are the elements defined in the XML 1351 schema. 1353 7. Security Considerations 1355 There is much sensitive information, such as location and identity, 1356 which may be transmitted between the master device and the database 1357 when PAWS is used. According to the security requirements given in 1358 the problem statement draft [2] attackers may have full access to the 1359 network medium between the master device and the white space database 1360 and many types of attack may be carried out by the attackers if there 1361 is a lack of security in PAWS. Therefore, to guarantee the security 1362 considerations of the communication between the master device and the 1363 white space database, the following security features should be 1364 considered: 1366 1. The identity of the master device and the white space database 1367 must be authenticated, namely the mutual authentication must be 1368 implemented and an authorization check shall be carried out by 1369 both of them. 1371 2. The connection between the master device and white space database 1372 must be private; that means the messages transmitted on the 1373 connection between the master device and the white space database 1374 are confidentiality protected. 1376 3. The connection between the master device and white space database 1377 is reliable; that means that the message transport must support 1378 including a message integrity check. 1380 4. The negotiation of a shared key is secure: the negotiated secrets 1381 which are used for confidentiality protection and Integrity 1382 protection are unrevealed to eavesdroppers. 1384 5. The negotiation is confidential: attacker must be not able to 1385 modify the content of negotiation process without being detected 1386 by the endpoints during the communication. 1388 The security threats, security features and security countermeasures 1389 associated with the use of white space spectrum by secondary usages 1390 via PAWS are not discussed in details in this document. 1392 8. IANA Considerations 1394 There have been no IANA considerations so far in this document. 1396 9. Acknowledgements 1398 Thanks to my colleagues for their sincerely help and comments when 1399 drafting this document. 1401 10. References 1403 10.1. Normative References 1405 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1406 Levels", BCP 14, RFC 2119, March 1997. 1408 10.2. Informative References 1410 [2] Probasco, S. and B. Patil, "Protocol to Access White Space 1411 database: PS, use cases and rqmts", 1412 draft-ietf-paws-problem-stmt-usecases-rqmts-06 (work in 1413 progress), July 2012. 1415 Authors' Addresses 1417 Xinpeng Wei 1418 Huawei 1420 Phone: +86 13436822355 1421 Email: weixinpeng@huawei.com 1423 Zhu Lei 1424 Huawei 1426 Phone: +86 13910157020 1427 Email: lei.zhu@huawei.com 1429 Peter J. McCann 1430 Huawei 1431 400 Crossing Blvd, 2nd Floor 1432 Bridgewater, NJ 08807 1433 USA 1435 Phone: +1 908 541 3563 1436 Email: peter.mccann@huawei.com