idnits 2.17.1 draft-lei-paws-framework-datamodel-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 809 has weird spacing: '... | send chann...' == Line 838 has weird spacing: '...r other of th...' == Line 842 has weird spacing: '...address of da...' == Line 1089 has weird spacing: '...t power dbm...' == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 5, 2012) is 4432 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: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-paws-problem-stmt-usecases-rqmts' is defined on line 1425, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-paws-problem-stmt-usecases-rqmts-03 Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PAWS Lei. Zhu 3 Internet-Draft Huawei Technologies 4 Intended status: Informational March 5, 2012 5 Expires: September 6, 2012 7 Protocol to Access White Space database: PAWS framework data model 8 draft-lei-paws-framework-datamodel-00.txt 10 Abstract 12 Portions of the radio spectrum that are allocated to a licensed, 13 primary use but are unused or unoccupied at specific locations and 14 times are defined as "white space". In this document the framework 15 of PAWS is introduced, which includes framework of PAWS, protocol 16 stack, definition of interface, parameters and schema running over 17 interface, and security considerations. The realization of database 18 and the calculation of protected contour are not considered in this 19 framework draft. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on September 6, 2012. 38 Copyright Notice 40 Copyright (c) 2012 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 This document may contain material from IETF Documents or IETF 54 Contributions published or made publicly available before November 55 10, 2008. The person(s) controlling the copyright in some of this 56 material may not have granted the IETF Trust the right to allow 57 modifications of such material outside the IETF Standards Process. 58 Without obtaining an adequate license from the person(s) controlling 59 the copyright in such materials, this document may not be modified 60 outside the IETF Standards Process, and derivative works of it may 61 not be created outside the IETF Standards Process, except to format 62 it for publication as an RFC or to translate it into languages other 63 than English. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Terminology and Abbreviation . . . . . . . . . . . . . . . . . 4 69 2.1. Conventions Used in This Document . . . . . . . . . . . . 4 70 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 71 3. Framework of PAWS . . . . . . . . . . . . . . . . . . . . . . 4 72 4. Protocol Stack . . . . . . . . . . . . . . . . . . . . . . . . 8 73 5. Protocl framework and interface of PAWS . . . . . . . . . . . 9 74 5.1. Database Discovery . . . . . . . . . . . . . . . . . . . . 9 75 5.2. Device Registration with Trusted Database . . . . . . . . 12 76 5.3. White Space Channel Query . . . . . . . . . . . . . . . . 15 77 5.4. White Space Channel Update . . . . . . . . . . . . . . . . 18 78 6. Message Encoding . . . . . . . . . . . . . . . . . . . . . . . 20 79 7. Security Considerations . . . . . . . . . . . . . . . . . . . 33 80 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 81 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33 82 10. Normative Reference . . . . . . . . . . . . . . . . . . . . . 33 83 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 33 85 1. Introduction 87 "White Space" means the radio spectrum which has been allocated for 88 some primary use, but is not fully occupied by that primary use at a 89 specific location and time. Currently the white space in TV bands 90 which is called TV white space (TVWS) is widely discussed, TVWS has 91 some good characteristics such as propagation ability and low power 92 consumption. The regulatory bodies in some countries have carried 93 out the rules allowing secondary white space access, the secondary 94 user must make sure of not interfering with the primary user when 95 using white space. The purpose of white space study is to design a 96 mechanism that the secondary user can use the white space resource 97 without interfering with the primary user. The widely accepted 98 scheme of utilizing white space is by querying the database and the 99 related protocol "Protocol to Access White Space database (PAWS)" is 100 proposed, the use cases and requirements of PAWS have been discussed 101 in document "draft-ietf-paws-problem-stmt-usecases-rqmts". 103 Spectrum management rules of different spectrum regulatory bodies are 104 different, so the white space spectrum database may be designed to 105 implement different spectrum policies in different countries. In 106 order to satisfy the need of globally applicable feature, the 107 database query protocol MUST be independent of different spectrum 108 management rules. PAWS is a protocol between the Master device and 109 the Database. The Master device could act as a WiFi AP, a cellular 110 base station (e.g.,3GPP LTE eNodeB) in the whitespace spectrum; the 111 PAWS protocol is agnostic to the technology used by the Master 112 device. 114 In this document the framework of PAWS is introduced, which includes 115 framework of PAWS, protocol stack, definition of interface, 116 parameters and schema running over interface, and security 117 considerations. 119 Based on the possible implementations, the common framework 120 fulfilling requirements and major scenarios is introduced with some 121 kind of extensible designs. White space Database (WSDB) is entity 122 operated by government regulatory body which dominates wireless 123 spectrum resource of a large country with different areas which owns 124 sub branches of spectrum management authorizations. Responsibility 125 for a WSDB for a large area with also quite number of population is a 126 burden and likely devided into sub Database of branch spectrum 127 management authorizations. This scenario obviously impacts on 128 Database discovery process and some minor implantations of framework 129 of PAWS. This document is to satisfy this situation with minimum 130 influence. 132 2. Terminology and Abbreviation 134 2.1. Conventions Used in This Document 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 138 document are to be interpreted as described in [RFC2119]. 140 2.2. Terminology 142 The Terminology Section of the latest version of [I-D.ietf-paws- 143 problem-stmt-usecases-rqmts] shall be included by reference. 145 Coordinating Database 147 Coordinating Database is an entity implemented between Master Device 148 and Database in framework, having function to retrieve available 149 channel list from Database on behaviors of Master device (fulfilled 150 by function of white space device) and can response proper available 151 channel list when receiving query request from Master Device. The 152 concepts in PAWS framework is described in section 3. 154 WS interface 156 The interface between white space device and Database specifies data 157 model and process of PAWS in this document. 159 AddrDatabase 161 A kind of database that provides the Internet addresses of regulatory 162 authorized Database in the relevant regulatory domain to the white 163 space device, the AddrDatabase is provisioned to Master device and 164 used in the Database discovery procedure. The AddrDatabase is either 165 hosted by or under control of the national regulator. 167 3. Framework of PAWS 169 The first stage of PAWS would have defined entities of Master Device 170 and Database, and common interface between these two entities. In 171 this section, author(s) specified an extendable framework of PAWS 172 which would support fulfill early stage protocol perspective purpose 173 and be extensible to satisfy more requirement if it is utilized in 174 further stages. 176 Figure 1 shows a common system model consisting of Master Device and 177 Database merely. The Master Device connects to the database directly 178 using WS interface. 180 WS interface is the interface between white space device and database 181 which specifies data model and process of PAWS in this document. The 182 messages of WS are encoded in XML, considering of transportation 183 reliable and security the TCP and HTTPS are used to load the message. 184 More details about the protocol of WS see section "protocol stack". 186 +-------+ +--------+ 187 |Master +-------------+Database| 188 |Device | +--------+ 189 +-------+ 191 Figure 1: Frame of PAWS 193 Master device in Figure 1 is a kind of white space device which 194 querying available channel list from database providing radio access 195 to user equipments. Due to PAWS principle of access technology 196 agnostic, it can be access point of WiFi, NodeB of 3GPP WCDMA or 197 eNodeB of 3GPP LTE etc. 199 Database in Figure 1 is in charge of storing and maintaining white 200 space channel information for certain area(s), it may be operated by 201 regulatory. When the database receives request of white space 202 spectrum querying from the master device, it will respond a list of 203 available white space channel list to the master device if there are 204 available spectrums. 206 The master device can connect to the database by any means other than 207 using the white space radio. 209 There is an optional system model can be implemented based on common 210 PAWS framework, shown in Figure 2, an entity named Coordinating 211 Database is implemented between master device and database. 213 Coordinating Database is logical function which is a combination of 214 master device and Database (which stores a part or all of the white 215 space spectrum information in certain area), the Coordinating 216 Database gets white space spectrum from database acting as Master 217 Device, the logical function of Coordinating Database is depicted in 218 Figure 3. 220 Master device can get white space from the Coordinating Database just 221 like getting white space from database; the Coordinating Database can 222 be maintained and operated by organizations and / or regulatory body 223 (e.g. FCC). 225 +-------------+ 226 +-------------+ |Coordinating | +-----------+ 227 |Master Device+--+----+Database +----+---+Database | 228 +-------------+ WS +-------------+ WS +-----------+ 230 Figure 2: Alternative implementation framework of PAWS 232 The concept of database in this document is the same as the one in 233 "I-D.ietf-paws-problem-stmt-usecases-rqmts", which contains current 234 information about available spectrum at any given location and other 235 types of information. 237 Database is in charge of storing and providing white space channels 238 of a large area, for example there are only several databases 239 operated by different operators in America. Here the coordinating 240 database is defined to provide white space channels information for a 241 relatively smaller area (e.g. a state, a region or even campus and a 242 building which contains a huge number users). 244 The coordinating database can get white space channels from database, 245 receive the white space querying message from master device and 246 provide the available white space channels for master devices with 247 some degree decision making process. These decision making process 248 might provide functionality of white space access protocol power to 249 response available channels according to received device parameters 250 (e.g. power, RF parameter), location information(e.g. altitude, 251 position and direction of antenna ) and some particular white space 252 spectrum decision making policies. 254 The coordinating database gets available white space channel list 255 from WS database acting as master device and provides white space 256 channels to the master device that connects to it. Master device can 257 get white space from the Coordinating Database just like getting 258 white space from database. When provides white space channels to the 259 master device, the coordinating database may be used to implements 260 private spectrum using policies. 262 The coordinating database can updates white space channels from 263 database. 265 The function diagram of coordinating database is shown in Figure 3. 267 Coordinating database includes three main functions: 269 (1) The function of master device. It can retrieve available channel 270 list from Database on behaviors of master device (fulfilled by 271 function of white space device). 273 (2) The function of database. To master device the coordinating 274 database acts just like a database, it can receive the registration 275 information from master device, response with proper available 276 channel list when receiving query request from master device etc. 278 (3) The function of implementing spectrum management policies. For 279 example, the white space coordination control between different 280 master devices. 282 Some deployment scenarios based on coordinating database are 283 introduced below: 285 (1) In a private network, master devices are deployed to provide 286 wireless access, but the master device cannot connect to Internet 287 directly, the Coordinating database run by private network's manager 288 can be added between Master devices and WS database, so the master 289 devices can get white space channels from coordinating database. 291 (2) A private network or ISP which serves a lot of master devices and 292 it establishes wireless network using these master device, it can set 293 a Coordinating database which gets white space in its area from WS 294 database and all of its master devices query available white space 295 channels from the Coordinating database, because private network 296 owner who dominates the Coordinating database so it can implement its 297 policy of spectrum utilizing. It makes the implementation of private 298 white space utilizing policy possible. 300 +-----------------------------------------------------------+ 301 | | 302 | | 303 | +--------------------+ +-------------------------+ | 304 | |Function of database| |Function of master device| | 305 | +--------------------+ +-------------------------+ | 306 | | 307 | +-------------------------+ | 308 | |Function of implementing | | 309 | |spectrum management | | 310 | |policy | | 311 | | | | 312 | +-------------------------+ | 313 | | 314 | | 315 | Coordinating Database | 316 | | 317 +-----------------------------------------------------------+ 319 Figure 3: Logical Function of Coordinating Database 321 By adding the Coordinating database the burden of database will be 322 reduced, when the master device is connected to Coordinating 323 database, it will query available white space channels from 324 Coordinating database instead of WS database. 326 The interface between master device and Coordinating Database is WS, 327 the interface between Coordinating Database and database is WS. 329 In order to provide database discover mechanism another local entity 330 called AddrDatabase is added to the system, the AddrDatabase MAY be 331 independent or be integrated in other entity (such as database), 332 Shown in Figure 4. 334 The function of AddrDatabase is to provide the Internet addresses of 335 trusted database in the relevant regulatory domain to the master 336 device. The AddrDatabase is either hosted by or under control of the 337 national regulator. 339 +-------+ +------------+ 340 |Master +-------------+AddrDatabase| 341 |Device | +------------+ 342 +-------+ 344 Figure 4: Framework of PAWS database discovery 346 When the master device is going to provide radio access service, it 347 MUST discover one database that can provide white space spectrum 348 information for it, and it needs to register some necessary 349 information to the database, and then the master device can query 350 white space channel from the database. 352 There SHOULD be some authentication procedures and some security 353 related procedures between database and master device. 355 4. Protocol Stack 357 The database querying message should be sent on reliable transport 358 protocol, and the database querying procedure is of request/response 359 model, besides the message MUST be transported securely. In order to 360 utilize the existing Internet protocol, a protocol stack model is 361 proposed here, shown in Figure 5, the transport layer is TCP and the 362 application layer is HTTPS. There may be some other protocol models, 363 for example using the Diameter as the application layer protocol. 365 +------------+ +------------+ 366 |WS.App +-------------+ WS.App | 367 +------------+ +------------+ 368 |HTTPS +-------------+HTTPS | 369 +------------+ +------------+ 370 |TCP +-------------+TCP | 371 +------------+ +------------+ 372 |IP +-------------+IP | 373 +------------+ +------------+ 374 Master Device Database 376 Figure 5: Protocol stack of PAWS protocol 378 WS.App is the white space spectrum application protocol. This 379 protocol stack is used by WS interface. 381 5. Protocl framework and interface of PAWS 383 The protocol message interface defines the message contents and 384 message format of WS and WS'. The message interface should satisfy 385 the following requirements: 387 1. The message sent in the message interface should be independent 388 of the specific radio interface technology( e.g. 802.11af, IEEE 389 802.16, IEEE 802.22, LTE ); 391 2. The message interface should be spectrum agnostic. The message 392 interface should not only be used for TV white space but also be used 393 for other spectrum; 395 3. The message interface should be satisfied to different scenarios 396 using white space. In different scenarios the white space device's 397 coverage area and the bandwidth may be different; 399 4. The message should address different regulations by different 400 regulatory bodies; 402 5. Security requirement, such as ciphering and integrity protection. 404 5.1. Database Discovery 406 The database discovery procedure is the process for white space 407 device to find the database from which it can query white space. In 408 this sub-clause the term database means the database entity from 409 which the white space device can query white space channel. 411 Database discovery is the prerequisite of the other procedures, 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. 416 The white space device gets the list of databases providing white 417 space spectrum querying service in the relevant regulatory domain, 418 and then the device will select one of the databases to connecting 419 to. 421 Optionally the white space device MAY be pre-programmed with the 422 Internet address of at least one trusted database manually. The 423 device can establish contact with a trusted database using one of the 424 pre-provisioned IP addresses. 426 Optionally the white space device can discover a list of databases 427 from AddrDatabase on the Internet which maintains a list of TVWS 428 databases and their Internet addresses. The procedure is shown in 429 Figure 6. 431 +------------------+ +------------+ 432 |white space device| |AddrDatabase| 433 +------------------+ +------------+ 434 | | 435 | | 436 | | 437 | | 438 | DISCOVERY REQ | 439 |----------------------------------------->| 440 | | 441 | | 442 | DISCOVERY RESP | 443 |< ----------------------------------------| 444 | | 445 | | 447 Figure 6: Discovery procedure 449 The discovery procedures shown in Figure 6 are as follows: 451 (1)The white space device is connected to the Internet by any means 452 other than using the white space radio. 454 (2)The white space device sends Database Discover request message to 455 AddrDatabase, when AddrDatabase receives the request message, it 456 finds out whether there are available trusted database for the device 457 to access to. 459 (3)The white space device waits a limited time for Database Discover 460 response message, If there is no available database or no acceptable 461 response is received within the limited time, the white space device 462 concludes that no trusted database is available, otherwise the device 463 will select a trusted database to connect to. 465 DISCOVERY_REQ is Database Discover request message and DISCOVERY_RESP 466 is Database Discover response message. DISCOVERY_REQ: 468 White space device sends its geo-location and coverage area 469 information to AddrDatabase, depending on the information the 470 AddrDatabase finds out databases which the white space device can 471 access to. 473 Parameters included in DISCOVERY_REQ message: 475 |------------------------------------------------------------------| 476 | parameters | comments | 477 |------------------------------------------------------------------| 478 | version | version of the protocol | 479 |------------------------------------------------------------------| 480 | message type | indicates the type of this message | 481 | | DISCOVERY_REQ here. | 482 |------------------------------------------------------------------| 483 | device id | device id of white space device | 484 |------------------------------------------------------------------| 485 | manufacture Series | the Series number of manufacture | 486 | number | of device | 487 |------------------------------------------------------------------| 488 | geo-location | geo-location of the white space device| 489 | | in the form of (latitude,longitude) | 490 |------------------------------------------------------------------| 491 | coverage range |coverage range of the white space device| 492 | | unit: m. | 493 |------------------------------------------------------------------| 495 DISCOVERY_RESP: 497 AddrDatabase sends the list of databases' information to white space 498 device by this message. The parameter "result" indicates whether 499 there are available databases or not. 501 Parameters included in DISCOVERY_ RESP message: 503 |------------------------------------------------------------------| 504 | parameters | comments | 505 |------------------------------------------------------------------| 506 | version | version of the protocol | 507 |------------------------------------------------------------------| 508 | message type | indicates the type of this message | 509 | | DISCOVERY_RESP here. | 510 |------------------------------------------------------------------| 511 | result | Indicating whether there are | 512 | | available databases or not. | 513 |------------------------------------------------------------------| 514 | list of databases | A list of available databases to | 515 | | which the white space device can | 516 | | access to. | 517 |------------------------------------------------------------------| 519 5.2. Device Registration with Trusted Database 521 The registration procedure is used to register the information that 522 will not change very frequently to the trusted database which the 523 white space device will connects to, before the device can transmit 524 in white space, it must contact a trusted database where the device 525 can learn if any channels are available for it to use. 527 The registration procedure occurs when one of these conditions 528 happens : 530 (1) The master device will operate in white space for the first time 531 after power up. 533 (2) The location of master device changes by a predetermined 534 distance. 536 (3) After a certain regular time interval. 538 (4) When the registered information before changed, and the master 539 device need update its registration information. 541 In this sub-clause the term database means the database entity from 542 which the white space device can query white space channel. 544 The registration procedure also includes the authentication procedure 545 and the establishment of security-related information which may be 546 used in subsequent messages. 548 The registration procedure is shown in Figure 7. 550 +------------------+ +------------+ 551 |white space device| | Database| 552 +------------------+ +------------+ 553 | | 554 | | 555 | | 556 | | 557 | REGISTRATION_REQ | 558 |----------------------------------------->| 559 | | 560 | | 561 | REGISTRATION_RESP | 562 |< ----------------------------------------| 563 | | 564 | | 566 Figure 7: The registration procedure 568 The registration procedure using the following steps: 570 (1)The white space device connects to the selected trusted database. 572 (2)The white space device sends registration request message to the 573 trusted database. In this message the parameters to be registered 574 and the security-related information are included. 576 (3)The database sends the registration response message to the white 577 space device indicating whether the registration is success or not, 578 the database also sends security-related information, that will be 579 used in the subsequent procedures. 581 REGISTRATION_REQ is the registration request message and 582 REGISTRATION_RESP is the registration response message. 584 REGISTRATION_REQ: 586 |------------------------------------------------------------------| 587 | parameters | comments | 588 |------------------------------------------------------------------| 589 | version | version of the protocol | 590 |------------------------------------------------------------------| 591 | message type | indicates the type of this message | 592 | | REGISTRATION_REQ here. | 593 |------------------------------------------------------------------| 594 | device id | device id of white space device | 595 |------------------------------------------------------------------| 596 | device type | the device type of the | 597 | | white space device| | 598 |------------------------------------------------------------------| 599 | manufacture Series | the Series number of manufacture | 600 | number | of device | 601 |------------------------------------------------------------------| 602 | | Antenna characteristic of the white | 603 | | space device.Includes:Antenna height | 604 | antenna characteristic |above the ground, direction, gain, | 605 | | maximum output power, spectrum mask | 606 | | | 607 |------------------------------------------------------------------| 608 | |includes:name of the individual or | 609 | |business that owns the device, name of a| 610 | |contact person responsible for the | 611 | Device owner's | device's operation, address for the | 612 | information | contact person, email address for the | 613 | | contact person and phone number of the| 614 | | contact person | 615 |------------------------------------------------------------------| 616 |authentication |the information for authentication | 617 | information |between white space device and database | 618 |------------------------------------------------------------------| 620 REGISTRATION_RESP: 622 |------------------------------------------------------------------| 623 | parameters | comments | 624 |------------------------------------------------------------------| 625 | version | version of the protocol | 626 |------------------------------------------------------------------| 627 | message type | indicates the type of this message | 628 | | REGISTRATION_RESP here. | 629 |------------------------------------------------------------------| 630 | result | indicates whether the connection | 631 | |establishment is success or fail | 632 |------------------------------------------------------------------| 633 | | the identification that the database | 634 | entity id | assigns for white space device. the | 635 | | Entity ID is unique in the scope of | 636 | | the database | 637 |------------------------------------------------------------------| 638 | authentication |the information for authentication | 639 | information |between white space device and database | 640 |------------------------------------------------------------------| 642 5.3. White Space Channel Query 644 In this sub-clause the term database means the database entity from 645 which the white space device can query white space spectrum. 647 The query procedure is used for white space device to query the white 648 space channel from database, the procedure is depicted in Figure 8. 650 +------------------+ +------------+ 651 |white space device| | Database| 652 +------------------+ +------------+ 653 | | 654 | | 655 | | 656 | | 657 | AVAIL_WS_REQ | 658 |----------------------------------------->| 659 | | 660 | | 661 | AVAIL_WS_RESP | 662 |< ----------------------------------------| 663 | | 664 | | 665 | | 667 Figure 8: The available channel query procedure 669 The query procedure using the following steps: 671 (1) The white space device sends the white space query request 672 message to database and waits a limited period of time for white 673 space query response message from database. 675 (2) On receiving the white space query request message, database will 676 find out the available white space channels and send the available 677 white space channel list to the white space device. 679 (3) If there is no available channel or no acceptable response is 680 received within the limited time, the white space device concludes 681 that no channel is available. 683 AVAIL_WS_REQ is the available white space query request message; 684 AVAIL_WS_RESP is the available white space query response message. 686 AVAIL_WS_REQ: 688 |------------------------------------------------------------------| 689 | parameters | comments | 690 |------------------------------------------------------------------| 691 | version | version of the protocol | 692 |------------------------------------------------------------------| 693 | message type | indicates the type of this message | 694 | | AVAIL_WS_REQ here. | 695 |------------------------------------------------------------------| 696 | device id | device id of white space device | 697 |------------------------------------------------------------------| 698 | device type | the device type of the | 699 | | white space device | 700 |------------------------------------------------------------------| 701 | List of coverage area(s)| a list of coverage area(s) where the | 702 | information | master device may provide white space | 703 | | access service.incudes:geo-location ( | 704 | | latitude ,longitude), uncertainty of | 705 | | geo-location(in meters),and confidence(| 706 | | in percentage ) for the location | 707 | | determination,coverage range. | 708 |------------------------------------------------------------------| 709 | | Antenna characteristic of the white | 710 | | space device.Includes:Antenna height | 711 | antenna characteristic |above the ground, direction, gain, | 712 | | maximum output power, spectrum mask | 713 | |( optional in this message) | 714 |------------------------------------------------------------------| 715 | |The bandwidth the device needs to form | 716 | Bandwidth |the wireless network. | 717 | | | 718 |------------------------------------------------------------------| 719 | Entity ID |the identification that the database | 720 | |assigns for device. the Entity ID | 721 | | is unique in the scope of database | 722 |------------------------------------------------------------------| 724 AVAIL_WS_RESP: 726 |------------------------------------------------------------------| 727 | parameters | comments | 728 |------------------------------------------------------------------| 729 | version | version of the protocol | 730 |------------------------------------------------------------------| 731 | message type | indicates the type of this message | 732 | | AVAIL_WS_RESP here. | 733 |------------------------------------------------------------------| 734 | device id | device id of white space device | 735 |------------------------------------------------------------------| 736 | device type | the device type of the | 737 | | white space device| | 738 |------------------------------------------------------------------| 739 | result | indicates whether the query procedure | 740 | | is success or fail | 741 |------------------------------------------------------------------| 742 | |includes:frequency information,available| 743 | | bandwidth, available time duration, | 744 | White Space channel |coverage area, maximum transmission | 745 | lists | power | 746 | | | 747 |------------------------------------------------------------------| 748 | Entity ID |the identification that the database | 749 | |assigns for device. the Entity ID | 750 | | is unique in the scope of database | 751 |------------------------------------------------------------------| 753 5.4. White Space Channel Update 755 In order to avoid interfering with the primary user or other 756 secondary user, the white space updating mechanism is provided in 757 this draft. There are two methods for white space updating: 759 Method 1: The white space device MUST access the database to obtain 760 and update the list of available channels that could be utilized by 761 the device. According to some regulatory rules the white space 762 device SHOULD update the white space channel periodically, and the 763 period may be different due to different regulatory rules. 765 Method 2: Database push updates in channel availability changes to 766 the master device, when the availability of channel changes database 767 SHOULD inform the master device and after receiving the notification 768 the master device SHOULD begin the white space channel query 769 procedure to get the updated white space channel. 771 The update procedure of method 1 is shown in Figure 9. 773 +------------------+ +------------+ 774 |white space device| | Database| 775 +------------------+ +------------+ 776 | | 777 +--------------------+ | 778 |Update timer expires| | 779 +--------------------+ | 780 | | 781 | | 782 | | 783 | | 784 | white space channel query procedure | 785 |< --------------------------------------->| 786 | | 787 | | 789 Figure 9: White space channel update procedure for method 1 791 In white space channel update procedure of method 1, an update timer 792 is set, after the white space device query the database for first 793 time, the timer start to run, when the timer expires the device will 794 implement the white space channel query procedure and update the 795 channel list, and then clear the update timer. 797 The update procedure of method 2 is shown in Figure 10. 799 +------------------+ +-------------+ 800 |Database | |Master device| 801 +------------------+ +-------------+ 802 | | 803 +-------------------------+ | 804 |The availability of some | | 805 | channel changes | | 806 +-------------------------+ | 807 | | 808 | | 809 | send channel updates message | 810 |----------------------------------------->| 811 | | 812 | | 813 | white space channel query procedure | 814 |< --------------------------------------->| 815 | | 816 | | 818 Figure 10: White space channel update procedure for method 2 820 As shown in Figure 10, when the availability of some white space 821 channels change, database will send channel updates message to the 822 white space device, and after receiving the message white space 823 device MUST start white space channel query procedure, discussed in 824 section 5.3. Here the white space device can be a coordinating 825 database as well as a master device. The parameters included in this 826 channel updates message are shown below: 828 CHANNEL_UPDATE_NOTIFICATION: 830 |------------------------------------------------------------------| 831 | parameters | comments | 832 |------------------------------------------------------------------| 833 | version | version of the protocol | 834 |------------------------------------------------------------------| 835 | message type | indicates the type of this message | 836 | | CHANNEL_UPDATE_NOTIFICATION here. | 837 |------------------------------------------------------------------| 838 | |Includes owner's name, or other of the | 839 |Owner information of the |information for identify the owner | 840 | database | database | 841 |------------------------------------------------------------------| 842 | Address information | URL or IP address of database | 843 |------------------------------------------------------------------| 845 6. Message Encoding 847 In this framework XML is used to encode the message. HTTPS is used 848 to carry the XML, there is an example of how XML formatted message is 849 embedded in HTTP: 851 (1) For the request message: 853 GET destination_url HTTP/1.0 855 Accept: */* 856 Proxy-Connection: Keep-Alive 857 User-Agent: Mozilla/4.0 858 Host: host name 859 Content-Type: text/xml 861 863 xml message. 865 (2) For the response message: 867 HTTP/1.1 200 OK 869 Proxy-Connection: Keep-Alive 870 Connection: Keep-Alive 871 Content-Length: 59042 872 Date: Thu, 09 Sep 2010 03:31:54 GMT 873 Content-Type: text/xml 874 Server: server name 875 Cache-Control: max-age=7200 877 879 xml message. 881 The details of XML schema is shown below, the details of parameters 882 in the message are included in the XML schema: 884 885 888 890 891 893 895 897 916 918 920 922 924 926 928 930 932 934 936 938 940 942 944 946 948 950 952 954 955 957 959 961 963 965 967 969 971 973 975 977 979 981 983 985 987 989 991 993 995 997 998 1000 1002 1004 1006 1008 1010 1012 1014 1016 1018 1020 1022 1024 1026 1028 1030 1032 1034 1036 1038 1040 1042 1044 1046 1048 1050 1052 1054 1056 1058 1060 1062 1064 1066 1068 1070 1072 1074 1076 1078 1093 1095 1097 1099 1101 1103 1105 1107 1109 1114 1116 1118 1120 1122 1124 1126 1128 1137 1139 1141 1143 1152 1154 1156 1158 1160 1162 1164 1166 1168 1170 1172 1174 1176 1177 1185 1187 1189 1191 1193 1195 1197 1199 1201 1203 1205 1207 1209 1211 1213 1215 1217 1219 1220 1222 1224 1226 1228 1230 1232 1234 1236 1238 1240 1242 1244 1246 1248 1250 1252 1254 1256 1258 1260 1262 1264 1265 1267 1269 1271 1273 1275 1277 1279 1281 1283 1285 1287 1289 1291 1293 1295 1297 1299 1301 1303 1305 1307 1309 1311 1312 1314 1316 1318 1320 1322 1324 1326 1328 1330 1332 1334 1336 1338 1340 1342 1344 1346 1348 1350 1352 1354 1356 1357 1359 1361 1363 1365 1367 1369 1371 1373 1375 1377 1379 1381 1383 1385 1387 1389 1391 1393 1395 1397 1399 7. Security Considerations 1401 There are some security consideration about PAWS: 1403 o Mutual authentication between master device and database, master 1404 device and coordination database, coordination database and 1405 database is needed. 1407 o In order to protect the message from being changed by attacker, 1408 all the messages need integrity protection. 1410 o Because there are some private information included in the 1411 messages, so a ciphering mechanism SHOULD be used to encrypt the 1412 messages. 1414 8. IANA Considerations 1416 There have been no IANA considerations so far in this document. 1418 9. Acknowledgments 1420 Thanks to my colleagues for their sincerely help and comments when 1421 drafting this document. 1423 10. Normative Reference 1425 [I-D.ietf-paws-problem-stmt-usecases-rqmts] 1426 Probasco, S. and B. Patil, "Protocol to Access White Space 1427 database: PS, use cases and rqmts", 1428 draft-ietf-paws-problem-stmt-usecases-rqmts-03 (work in 1429 progress), February 2012. 1431 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1432 Requirement Levels", BCP 14, RFC 2119, March 1997. 1434 Author's Address 1436 Lei Zhu 1437 Huawei Technologies 1438 Huawei Building, Q20 No.156 Beiqing Rd.Z-park 1439 Haidian District, Beijing 100095 1440 P. R. China 1442 Phone: +86-10-60612078 1443 Email: lei.zhu@huawei.com