Application Area Working Group S. Das, ed. Internet-Draft ACS Intended status: Standards Track J. Malyar Expires: September 13, 2012 Telcordia D. Harasty ACS March 12, 2012 Device to Database Protocol for White Space draft-das-paws-protocol-01 Abstract This document describes the `White Space Device` to `Database` interface protocol features and functionalities and shows in Appendix A how they are consistent with the protocol requirements specified in [I-D.ietf-paws-problem-stmt-usecases-rqmts]. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 13, 2012. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Das, ed., et al. Expires September 13, 2012 [Page 1] Internet-Draft Device to Database Protocol March 2012 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Convention used in this document . . . . . . . . . . . . . . . 3 2. Terminology and abbreviations used in this document . . . . . 3 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Interface Protocol Framework . . . . . . . . . . . . . . . . . 6 5. Protocol Features/Functionalities . . . . . . . . . . . . . . 7 5.1. WSD Bootstrapping/Initialization . . . . . . . . . . . . . 7 5.2. WSD Registration . . . . . . . . . . . . . . . . . . . . . 9 5.3. Database Query . . . . . . . . . . . . . . . . . . . . . . 12 5.4. WSD Validation . . . . . . . . . . . . . . . . . . . . . . 17 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 21 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 9.1. Normative References . . . . . . . . . . . . . . . . . . . 21 9.2. Informative References . . . . . . . . . . . . . . . . . . 21 Appendix A. Protocol Functionalities and Requirements Mapping . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 Das, ed., et al. Expires September 13, 2012 [Page 2] Internet-Draft Device to Database Protocol March 2012 1. Convention used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Terminology and abbreviations used in this document Following definitions are copied from [I-D.ietf-paws-problem-stmt-usecases-rqmts] Radio spectrum which is not fully occupied at a specific location and time. TV White Space TV white space refers specifically to radio spectrum which has been allocated for TV broadcast, but is not occupied by a TV broadcast, or other assigned user (such as a wireless microphone), at a specific location and time. White Space Device (WSD) A device which opportunistically uses some part of white space spectrum. A white space device can be an access point, base station, a portable device or similar. A white space device may be required by local regulations to query a database with its location to obtain information about available spectrum. TV White Space Device (TVWSD) A White Space Device that operates in the TV bands. Database In the context of white space and cognitive radio technologies, the database is an entity which contains, but is not limited to, current information about available spectrum at any given location and other types of related (to the white space spectrum) or relevant information. Master Device A device which queries the WS Database to find out the available operating channels. Following definitions are copied from FCC 10-174, September, 2010 [FCC] Das, ed., et al. Expires September 13, 2012 [Page 3] Internet-Draft Device to Database Protocol March 2012 TV Bands Database (TVBD) A database system that maintains records of all authorized services in the TV frequency bands, is capable of determining the available channels as a specific geographic location. Fixed Device A TVBD that transmits and/or receives radio communication signals at a specified fixed location. Mode I personal/portable device A personal/portable TVBD that does not use an internal geolocation capability and access to a TV bands database to obtain a list of available channels. Mode II personal/portable device A personal/portable TVBD that uses an internal geo-location capability and access to a TV bands database, either through a direct connection to the Internet or through an indirect connection to the Internet by way of fixed TVBD or another `Mode II` TVBD, to obtain a list of available channels. 3. Introduction Services offered via TV Whitespaces initiative will require a variety of devices and services each acting in accord with rules provided by the regulatory bodies and industries. Along with other things, the service architecture requires the `Master Devices` to access the `Database`(e.g. TV Whitespace database) to obtain the necessary information that could be utilized at their location to provide the service. In this document, we focus on this aspect of the overall system: the interface between `Master Device` and `Database`. Figure 1 depicts the device-to-database interface architecture and highlights the scope of this document. This document provides a starting point for a protocol specification for the PAWS working group. The `White Space Device (WSD)` is a fixed or portable device and the definition of WSD may differ from one regulatory authority to another. For example, by United States (US) FCC rules, WSD is referred to `Fixed` and `Personal/Portable device` (e.g. `Mode II` personal/portable device`) [FCC]. The `Fixed and personal/portable TVWSD devices` may additionally support other TVWSDs (e.g. `Mode I` personal/portable device per US FCC rules [FCC]) to establish wireless broadband services. `Mode I` TVWSDs may also access the database to obtain the relevant information at their location. Das, ed., et al. Expires September 13, 2012 [Page 4] Internet-Draft Device to Database Protocol March 2012 \|/ | | |-|---------| | Fixed/ | .-------. | Mode II | / \ | WSD | / \ |----------| | |========( Internet )========| Database | |-----------| \ / |(e.g.TVWS)| | \ / |----------| \|/ | \.-----./ | | | | |-|---------| | Mode I | | WSD | |-----------| < --Device-to-Database Interface- > Figure 1: Device-to-Database Interface Architecture Several use cases and requirements for use of White Space spectrum is described in draft document [I-D.ietf-paws-problem-stmt-usecases-rqmts]. `Master Device` to `Database` interface must satisfy the requirements that are specified by the regulatory authorities. As an example, here we list some US specific TV Whitespace requirements as specified by Federal Communications Commission Whitespace protocol must satisfy the requirements that are specified by the regulatory authorities. As an example, here we list some US specific requirements as specified by Federal Communications Commission [FCC]: o The TVWS devices are required to periodically access the TV Whitespace Database to obtain the list of available TV frequencies (channels) that could be utilized at their location. o Along with the list of bands, the database should also return maximum permissible power levels that could be used by the TVWS devices. o `Fixed and Mode II` devices are required to access TVWS database every 24 hours to get a list of available TV bands. Das, ed., et al. Expires September 13, 2012 [Page 5] Internet-Draft Device to Database Protocol March 2012 o The `Mode II` must additionally do the same upon power-up, and whenever they change their position by 50 meters. o When a `Fixed or Mode II` device will serve as an access point for `Mode I` devices, the serving `Fixed or Mode II` must check with the TVWS database to sure that the specified `Mode I` devices are valid devices at the given location. On the other hand, there may be different rules and requirements from other regulatory bodies (e.g., ofcom) and countries. The protocol design should be flexible enough to not only address these requirements but also future requirements. 4. Interface Protocol Framework Figure 2 provides a high level overview of the interface protocol framework in terms of layering. The interface protocol is as an application protocol that can be carried over secure HTTP which provides reliable transport, an important aspect of the protocol requirement. +-+-+-+-+-+-+-+-+-+-+-+-+ | WS Appl. Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+ | HTTPS | +-+-+-+-+-+-+-+-+-+-+-+-+ | Reliable Transport | +-+-+-+-+-+-+-+-+-+-+-+-+ | IP | +-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Example Protocol Layer While the details of adapting the White space application protocol to the above protocol stack may vary, following protocol operation steps are assumed in this document. o The device will request service from the White Space (WS) database by sending a message something the messaging in the HTTPS requests that can be XML and/or JSON encoded to a known URL in the body of an HTTP request. The database will then respond with the message in the body (with the same encoding) of the HTTP reply. Das, ed., et al. Expires September 13, 2012 [Page 6] Internet-Draft Device to Database Protocol March 2012 o A TLS with TCP or DTLS over reliable UDP connection is used for underlying transport each time WSD contacts with the database. With the use of server-only certificate, WSD authenticates the database. It is important to note that it is not required to exchange all messages and perform all protocol operations via a single TLS/DTLS connection. o The database authenticates the WSD based on the authentication information that WSD obtains from the database during initialization and which it includes in subsequent 'Request' messages. The device identity can be cryptographically verified by a shared secret that a device manufacturer establishes with the database provider during manufacturing time. This shared secret is per device and can be associated with each device's serial number. Provisioning such parameters is done prior to the protocol message exchange and is out of scope of this document. 5. Protocol Features/Functionalities WS application protocol must support several regulatory requirements and include features that are essential between the `Master Device` and the `Database` to operate and in accord with the rules and regulations provided by the regulatory authorities. Following are the list of protocol features and functionalities that are required to support the Whitespace services. 5.1. WSD Bootstrapping/Initialization WSD bootstrapping/initialization is the process of a device establishing initial connection to the database. For example, each time the `Master Device` powers up or opens up a communication with the database; it requires exchanging some messages. These messages for example, will help the device to obtain the required security parameters so that the subsequent messages can be authenticated and integrity protected. The authentication (e.g. device and service) can be performed at the WS application layer, as opposed to lower layers since the database and the master device must be connected to the Internet before initiating the bootstrapping process [I-D.ietf-paws-problem-stmt-usecases-rqmts]. `INIT-REQ` and `INT-RESP` messages are used to perform the `Master Device` bootstrapping/initialization with the database. Figure 3 depicts the bootstrapping/initialization message flow: Das, ed., et al. Expires September 13, 2012 [Page 7] Internet-Draft Device to Database Protocol March 2012 WSD Database | | | INT-REQ | |---------------------->| | INT-RESP | |<----------------------| | | | | Figure 3: WSD Bootstrapping/Initialization Message Flow Following are the example message parameters and corresponding data types that can be exchanged in `INIT-REQ` and `INIT-RESP` messages. Additional parameters are TBD. INIT-REQ +----------------+--------------+-----------+-----------------------+ | Field | Identifier | Type | Description | +----------------+--------------+-----------+-----------------------+ |Protocol Version| ver | String |`1.0` for this version | +----------------+--------------+-----------+-----------------------+ | Message Type | msg | String | INT-REQ | +----------------+--------------+-----------+-----------------------+ | Authority | au | String |'US'- USA FCC rules | | | | | to be applied | | | | |'UK' - UK OfCom rules | | | | | to be applied | | | | | `others` - TBD | | | | |The starting list could| | | | |be the ISO 3166 country| | | | |list. | +----------------+--------------+-----------+-----------------------+ | Device Type | dev type | String | 'F' - Fixed Device | | | | | 'M2'- Mode II Device | | | | | 'M1'- Mode I Device | +----------------+--------------+-----------+-----------------------+ |Device Identity | devid | String | `FCC ID`- For US | | | | | `Device Serial no` | | | | | specified by the | | | | | manufacturer | +----------------+--------------+-----------+-----------------------+ Das, ed., et al. Expires September 13, 2012 [Page 8] Internet-Draft Device to Database Protocol March 2012 Note: The type 'String' can be expanded by such as 'String containing UTF8 characters, with a length limit (TBD). INIT-RESP +----------------+--------------+-----------+-----------------------+ | Field | Identifier | Type | Description | +----------------+--------------+-----------+-----------------------+ |Protocol Version| ver | String |`1.0` for this version | +----------------+--------------+-----------+-----------------------+ | Message Type | msg | String | INT-RESP | +----------------+--------------+-----------+-----------------------+ | Authority | au | String |'US'- USA FCC rules | | | | | to be applied | | | | |'UK' - UK OfCom rules | | | | | to be applied | | | | | `others` - TBD | | | | |The starting list could| | | | |be the ISO 3166 country| | | | |list. | +----------------+--------------+-----------+-----------------------+ | Result Code | result | String | 'OK' - Success | | | | | 'Fail' - Failure | | | | | | +----------------+--------------+-----------+-----------------------+ |Authentication | authinfo | String | Information that is | |Information | | | used to initiate the | | | | | authentication process| | | | | or perform the | | | | |capability negotiation | +----------------+--------------+-----------+-----------------------+ 5.2. WSD Registration WSD registration is the process of a device establishing certain operational parameters with the database, as required by the spectrum management authority. FCC rules require, for example, that `Fixed Devices` register as owner and/or operator contact info. `Fixed Devices` may also register their fixed location and antenna height parameters with the database. Registration is required upon its Das, ed., et al. Expires September 13, 2012 [Page 9] Internet-Draft Device to Database Protocol March 2012 initial contact with the database, or when its registered parameters change (e.g., a Fixed device is redeployed at a new location, or its antenna height is adjusted,) or registration life time expires. It is to be noted that this functionality may be optional in certain regulatory domains. `REG-REQ` and `REG-RESP` messages are used to perform the `Master Device` registration with the database. Figure 4 depicts the registration message flow: WSD Database | | | REG-REQ | |---------------------->| | REG-RESP | |<----------------------| | | | | Figure 4: WSD Registration Message Flow Following are the example message parameters and corresponding data types that can be exchanged in `REG-REQ` and `REG-RESP` messages. Additional parameters are TBD. REG-REQ +----------------+--------------+-----------+-----------------------+ | Field | Identifier | Type | Description | +----------------+--------------+-----------+-----------------------+ |Protocol Version| ver | String |`1.0` for this version | +----------------+--------------+-----------+-----------------------+ | Message Type | msg | String | REG-REQ | +----------------+--------------+-----------+-----------------------+ | Authority | au | String |'US'- USA FCC rules | | | | | to be applied | | | | |'UK' - UK OfCom rules | | | | | to be applied | | | | | `others` - TBD | | | | |The starting list could| | | | |be the ISO 3166 country| Das, ed., et al. Expires September 13, 2012 [Page 10] Internet-Draft Device to Database Protocol March 2012 | | | |list. | +----------------+--------------+-----------+-----------------------+ |Device Identity | devid | String | `FCC ID`- For US | | | | | `Device Serial no` | | | | | specified by the | | | | |manufacturer | +----------------+--------------+-----------+-----------------------+ | Device Type | dev | String | `F` - Fixed Device | | | | | `M2`- Mode II Device | | | | | `M1'- Mode I Device | +----------------+--------------+-----------+-----------------------+ |Device Location | lat, long, | Sequence | | | |Hagl,ant_type | (lat,long,| | | | |uncertainty| Latitude, | | | |value, hagl|Longitude of the | | | |, ant_type |device with uncertainty| | | | ..) | value, Antenna height | | | | | above ground level, | | | | | type of antenna | | | | |characteristics and | | | | | so on. The location | | | | | address elements | | | | |and resolution as | | | | | described in RFC 4119 | | | | |and RFC 3825 can be | | | | | used for encoding | +----------------+--------------+-----------+-----------------------+ | Device Owner | Devinfo |Sequence( | Device owner and | | | |ownerinfo | device operator | | | |(name,addr | information, and | | | | phone, | address. The address | | | |email) | includes civic | | | |operator | address, phone number| | | |info (name,| email, and other | | | |addr,phone,| relevant information | | | |email, ..) | | +----------------+--------------+-----------+-----------------------+ |Authentication | authcode | String | Information that | | Code | | | authenticates the | | | | | ownership and | | | | |integrity of the | | | | | message | +----------------+--------------+-----------+-----------------------+ Das, ed., et al. Expires September 13, 2012 [Page 11] Internet-Draft Device to Database Protocol March 2012 REG-RESP +----------------+--------------+-----------+-----------------------+ | Field | Identifier | Type | Description | +----------------+--------------+-----------+-----------------------+ |Protocol Version| ver | String |`1.0` for this version | +----------------+--------------+-----------+-----------------------+ | Message Type | msg | String | REG-RESP | +----------------+--------------+-----------+-----------------------+ | Authority | au | String |'US'- USA FCC rules | | | | | to be applied | | | | |'UK' - UK OfCom rules | | | | | to be applied | | | | | `others` - TBD | | | | |The starting list could| | | | |be the ISO 3166 country| | | | |list. | +----------------+--------------+-----------+-----------------------+ | Sequence number| seqno | Number | Represents the message| | | | | sequence number | +----------------+--------------+-----------+-----------------------+ | Result Code | result | String | `OK` - Success | | | | | `Fail` - Failure | | | | | | +----------------+--------------+-----------+-----------------------+ |Authentication | authcode | String | Information that | | Code | | | authenticates the | | | | | ownership and | | | | |integrity of the | | | | | message | +----------------+--------------+-----------+-----------------------+ 5.3. Database Query In order of obtain the available channel and other information `Master Device` needs to query the `Database`. In certain regulatory environment, it may be required to be authenticated and registered before a `Master Device` can query the database and in other domains, requirements may vary. `Master device` will perform `Bootstrapping/Initialization` and `Registration` procedures as and when required before querying the database. Das, ed., et al. Expires September 13, 2012 [Page 12] Internet-Draft Device to Database Protocol March 2012 When the `Master Device` sends a query to the `Database`, it sends its location (e.g., Geo-location) along with other parameters. `Database` returns an array/set of channels within the scope of the request (e.g. VHF/UHF) and regulatory authority where the returned elements contain the channel frequency range, availability indicator, operating power, event management (indicator when channel is scheduled is or is not available), and so on. It may also include other parameters depending upon the regulatory requirements. `AVAIL-CHAN-REQ` and `AVAIL-CHAN-RESP` messages are used by devices for querying the database in a given location. Optionally 'USE-CHAN- NOTIFY' message is used by the device to notify the database which channel is being used in that location. Figure 5 depicts the query message flow: Master Device Database | AVAIL-CHAN-REQ | |---------------------->| | AVAIL-CHAN-RESP | |<----------------------| | NOTIFY-CHAN-USE | | (optional) | |---------------------->| | | Figure 5: Query Message Flow Following are the example message parameters and corresponding data types that can be exchanged in `AVAIL-CHAN-REQ` `AVAIL-CHAN-RESP` and 'NOTIFY-CHAN-USE' messages. Additional parameters are TBD. AVAIL-CHAN-REQ Das, ed., et al. Expires September 13, 2012 [Page 13] Internet-Draft Device to Database Protocol March 2012 +---------------+--------------+-----------+-----------------------+ | Field | Identifier | Type | Description | +----------------+--------------+-----------+-----------------------+ |Protocol Version| ver | String |`1.0` for this version | +----------------+--------------+-----------+-----------------------+ | Message Type | msg | String | AVAIL-CHAN-REQ | +----------------+--------------+-----------+-----------------------+ | Authority | au | String |'US'- USA FCC rules | | | | | to be applied | | | | |'UK' - UK OfCom rules | | | | | to be applied | | | | | `others` - TBD | | | | |The starting list could| | | | |be the ISO 3166 country| | | | |list. | +----------------+--------------+-----------+-----------------------+ | Device Type | dev | String | `F` - Fixed Device | | | | | `M2`- Mode II Device | | | | | `M1'- Mode I Device | +----------------+--------------+-----------+-----------------------+ |Device Identity | devid | String | `FCC ID`- For US | | | | | `Device Serial no` | | | | | specified by the | | | | |manufacturer | +----------------+--------------+-----------+-----------------------+ |Device Location | lat, long, | Sequence | | | |Hagl,ant_type | (lat,long,| | | | |uncertainty| Latitude, | | | |value, hagl|Longitude of the | | | |, ant_type |device with uncertainty| | | | ..) | value, Antenna height | | | | | above ground level, | | | | | type of antenna | | | | |characteristics and | | | | | so on. The location | | | | | address elements | | | | |and resolution as | | | | | described in RFC 4119 | | | | |and RFC 3825 can be | | | | | used for encoding | +----------------+--------------+-----------+-----------------------+ |Authentication | authcode | String | Information that | | Code | | | authenticates the | | | | | ownership and | | | | |integrity of the | | | | | message | +----------------+--------------+-----------+-----------------------+ Das, ed., et al. Expires September 13, 2012 [Page 14] Internet-Draft Device to Database Protocol March 2012 AVAIL-CHAN-RESP +----------------+--------------+-----------+-----------------------+ | Field | Identifier | Type | Description | +----------------+--------------+-----------+-----------------------+ |Protocol Version| ver | String |`1.0` for this version | +----------------+--------------+-----------+-----------------------+ | Message Type | msg | String | AVAIL-CHAN-RESP | +----------------+--------------+-----------+-----------------------+ | Authority | au | String |'US'- USA FCC rules | | | | | to be applied | | | | |'UK' - UK OfCom rules | | | | | to be applied | | | | | `others` - TBD | | | | |The starting list could| | | | |be the ISO 3166 country| | | | |list. | +----------------+--------------+-----------+-----------------------+ | Sequence number| seqno | Number | Represents the message| | | | | sequence number | +----------------+--------------+-----------+-----------------------+ | Result Code | result | String | `OK` - Success | | | | | `Fail` - Failure | | | | | | +----------------+--------------+-----------+-----------------------+ | Available | Channel |Sequence[ | | | | |List(Chan- |Channel information | | Channel | |no,boolean)|with availability(true,| | | |,max-power, |false), max power | | | |freq range,|limit, frequency range,| | | |available_ |and the time until the | | | |until)] |channel is available | | | | | | +----------------+--------------+-----------+-----------------------+ |Authentication | authcode | String | Information that | | Code | | | authenticates the | | | | | ownership and | | | | |integrity of the | | | | | message | +----------------+--------------+-----------+-----------------------+ Das, ed., et al. Expires September 13, 2012 [Page 15] Internet-Draft Device to Database Protocol March 2012 USE-CHAN-NOTIFY +----------------+--------------+-----------+-----------------------+ | Field | Identifier | Type | Description | +----------------+--------------+-----------+-----------------------+ |Protocol Version| ver | String |`1.0` for this version | +----------------+--------------+-----------+-----------------------+ | Message Type | msg | String | NOTIFY-CHAN-USE | +----------------+--------------+-----------+-----------------------+ | Authority | au | String |'US'- USA FCC rules | | | | | to be applied | | | | |'UK' - UK OfCom rules | | | | | to be applied | | | | | `others` - TBD | | | | |The starting list could| | | | |be the ISO 3166 country| | | | |list. | +----------------+--------------+-----------+-----------------------+ | Sequence number| seqno | Number | Represents the message| | | | | sequence number | +----------------+--------------+-----------+-----------------------+ |Device Identity | devid | String | `FCC ID`- For US | | | | | `Device Serial no` | | | | | specified by the | | | | |manufacturer | +----------------+--------------+-----------+-----------------------+ |Device Location | lat, long, | Sequence | | | |Hagl,ant_type | (lat,long,| | | | |uncertainty| Latitude, | | | |value, hagl|Longitude of the | | | |, ant_type |device with uncertainty| | | | ..) | value, Antenna height | | | | | above ground level, | | | | | type of antenna | | | | |characteristics and | | | | | so on. The location | | | | | address elements | | | | |and resolution as | | | | | described in RFC 4119 | | | | |and RFC 3825 can be | | | | | used for encoding | +----------------+--------------+-----------+-----------------------+ | Selected | Channel |List(Chan- |Information on the | | Channel | |no, |channels selected for | | | | max-power |operation by the | Das, ed., et al. Expires September 13, 2012 [Page 16] Internet-Draft Device to Database Protocol March 2012 | | |freq, ..) |Device: channel number,| | | | |max-power limit, | | | | |frequency, and | | | | |so on | +----------------+--------------+-----------+-----------------------+ |Authentication | authcode | String | Information that | | Code | | | authenticates the | | | | | ownership and | | | | |integrity of the | | | | | message | +----------------+--------------+-----------+-----------------------+ Information on the channels selected for operation by the device. Channel number; Max-Power Limit; Frequency; etc 5.4. WSD Validation WSD validation is the process by which WSDs can be validated by the database. For example, by US FCC rule, the `TVWS Fixed or Mode II` device provides service to a Mode I device only after the Mode I is validated by the TVWS database. To facilitate this validation, `Database` needs to support `WSD Validation` capability. `DEV-VALID-REQ` and `DEV-VALID-RESP` messages are used by `Master Device` for WSD validation with the database. Figure 6 depicts the message flow: Master device Database | | | DEV-VALID-REQ | |---------------------->| | DEV-VALID-RESP | |<----------------------| | | Figure 6: WSD Validation Message Flow Following are the example message parameters and corresponding data types that can be exchanged in `DEV-VALID-REQ` and `DEV-VALID-RESP` messages. Additional parameters are TBD. Das, ed., et al. Expires September 13, 2012 [Page 17] Internet-Draft Device to Database Protocol March 2012 Dev-VALID-REQ +----------------+--------------+-----------+-----------------------+ | Field | Identifier | Type | Description | +----------------+--------------+-----------+-----------------------+ |Protocol Version| ver | String |`1.0` for this version | +----------------+--------------+-----------+-----------------------+ | Message Type | msg | String | DEV-VALID-REQ | +----------------+--------------+-----------+-----------------------+ | Authority | au | String |'US'- USA FCC rules | | | | | to be applied | | | | |'UK' - UK OfCom rules | | | | | to be applied | | | | | `others` - TBD | | | | |The starting list could| | | | |be the ISO 3166 country| | | | |list. | +----------------+--------------+-----------+-----------------------+ | Device Type | dev | String | `F` - Fixed Device | | | | | `M2`- Mode II Device | | | | | `M1'- Mode I Device | +----------------+--------------+-----------+-----------------------+ |Device Identity | devid | String | `FCC ID`- For US | | | | | `Device Serial no` | | | | | specified by the | | | | |manufacturer | +----------------+--------------+-----------+-----------------------+ |Device Location | lat, long, | Sequence | | | |Hagl,ant_type | (lat,long,| | | | |uncertainty| Latitude, | | | |value, hagl|Longitude of the | | | |, ant_type |device with uncertainty| | | | ..) | value, Antenna height | | | | | above ground level, | | | | | type of antenna | | | | |characteristics and | | | | | so on. The location | | | | | address elements | | | | |and resolution as | | | | | described in RFC 4119 | | | | |and RFC 3825 can be | | | | | used for encoding | +----------------+--------------+-----------+-----------------------+ |Device List | devlist |List(dev, | List of devices that | | | |devid, | require validation | Das, ed., et al. Expires September 13, 2012 [Page 18] Internet-Draft Device to Database Protocol March 2012 | | |serial no, | with device type, | | | |..) | device identity | | | | |(e.g., FCC ID), | | | | |manufacturer serial no | +----------------+--------------+-----------+-----------------------+ |Authentication | authcode | String | Information that | | Code | | | authenticates the | | | | | ownership and | | | | |integrity of the | | | | | message | +----------------+--------------+-----------+-----------------------+ DEV-VALID-RESP Das, ed., et al. Expires September 13, 2012 [Page 19] Internet-Draft Device to Database Protocol March 2012 +----------------+--------------+-----------+-----------------------+ | Field | Identifier | Type | Description | +----------------+--------------+-----------+-----------------------+ |Protocol Version| ver | String |`1.0` for this version | +----------------+--------------+-----------+-----------------------+ | Message Type | msg | String | DEV-VALID-RESP | +----------------+--------------+-----------+-----------------------+ | Authority | au | String |'US'- USA FCC rules | | | | | to be applied | | | | |'UK' - UK OfCom rules | | | | | to be applied | | | | | `others` - TBD | | | | |The starting list could| | | | |be the ISO 3166 country| | | | |list. | +----------------+--------------+-----------+-----------------------+ | Sequence number| seqno | Number | Represents the message| | | | | sequence number | +----------------+--------------+-----------+-----------------------+ | Result Code | result | String | `OK` - Success | | | | | `Fail` - Failure | | | | | | +----------------+--------------+-----------+-----------------------+ | Device List | devlist |Sequence | List of valid devices | | | |List(dev, | with device type, | | | |devid, | device identity, | | | |serial no.)| manufacturer serial | | | | Boolean) | number and so on | +----------------+--------------+-----------+-----------------------+ |Authentication | authcode | String | Information that | | Code | | | authenticates the | | | | | ownership and | | | | |integrity of the | | | | | message | +----------------+--------------+-----------+-----------------------+ 6. Security Considerations The requirement for the protocol to meet the security requirements outlined in draft [I-D.ietf-paws-problem-stmt-usecases-rqmts] should be satisfied in conjunction with the underlying transports. For example, the protocol framework assumes the WS protocol runs over HTTPS which can satisfy confidentiality and server authentication. Some security requirements, such as, client authentication, message authentication, integrity and replay protections can be provided at Das, ed., et al. Expires September 13, 2012 [Page 20] Internet-Draft Device to Database Protocol March 2012 the WS application protocol layer. 7. IANA Considerations TBD 8. Acknowledgement TBD 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [I-D.ietf-paws-problem-stmt-usecases-rqmts] Probasco, S. and B. Patil, "Protocol to Access White Space database: PS, use cases and rqmts", draft-ietf-paws-problem-stmt-usecases-rqmts-03 (work in progress), February 2012. 9.2. Informative References [FCC] FCC, "Second Memorandum Opinion and Order", FCC 10-174, 2010. Appendix A. Protocol Functionalities and Requirements Mapping Following table shows how the above protocol functionalities and features map to the working group draft on use cases and requirements [I-D.ietf-paws-problem-stmt-usecases-rqmts]. +--------------------------------------+------------------+----------+ | Protocol Requirements | Corresponding | Comment | | | Protocol Features| | | | /Functionalities | | +--------------------------------------+------------------+----------+ |P.1 The protocol MUST provide a | Currently assumed| Static | |message sequence for the master device| that the server |discovery | |to discover a white space database | address is | is | Das, ed., et al. Expires September 13, 2012 [Page 21] Internet-Draft Device to Database Protocol March 2012 |that provides service at its current | pre-configured |supported | |location. | | | +--------------------------------------+------------------+----------+ |P.2 The protocol MUST support |The architecture | No Proxy | |access of a database directly. The |in figure 1 |model is | |protocol MUST support access of a | assumes a direct |assumed | |database using a listing approved by |access to database| | |a national regulator. | | | +--------------------------------------+------------------+----------| |P.3 The protocol MUST support | Included in all |Supported | |determination of regulatory domain | protocol |as a | |governing its current location. | functionalities |parameter | +--------------------------------------+------------------+----------+ |P.4 The protocol MUST provide the | Registration |Choice of | |ability for the database to | supports mutual | HTTPS | |authenticate the master device. | authentication | support | +--------------------------------------+------------------+----------+ |P.5 The protocol MUST provide the |Registration |Choice of | |ability for the master device to |supports mutual | HTTPS | |verify the authenticity of the | authentication | support | |database with which it is interacting.| | | +--------------------------------------+------------------+----------+ |P.6 The messages sent by the master | Supported in each|Choice of | |device to the database MUST be | functionalities | HTTPS | |integrity protected. | | support | +--------------------------------------+------------------+----------+ |P.7 The messages sent by the database | | Same | | to the master device MUST be | same as Above |as above | |integrity protected. | | | +--------------------------------------+------------------+----------+ |P.8 The protocol MUST provide the |Protocol framework| Same as | |capability for messages sent by the |supports this | above | |master device and database to be | | | |encrypted. | | | +--------------------------------------+------------------+----------+ |P.9 The protocol MUST support the | Registration is |Device ID | |master device registering with the | supported |included | |database. | | | +--------------------------------------+------------------+----------+ |P.10 The protocol MUST support a | Supported in | Result | |registration acknowledgement including| Registration | Code is | |appropriate result codes. | | included | +--------------------------------------+------------------+----------+ |P.11 The protocol MUST support a | | | |channel query request from the master | Channel query | Relevant | |device to the database. The channel | function is |parameters| |query request message MUST include | included | are | |parameters as required by local | | included | Das, ed., et al. Expires September 13, 2012 [Page 22] Internet-Draft Device to Database Protocol March 2012 |regulatory requirement. These | | in | |parameters MAY include device location| | Request | |device ID, manufacturer's serial | | message | |number, and antenna characteristic | | | |information | | | +--------------------------------------+------------------+----------+ |P.12 The protocol MUST support a | | | |channel query response from the | |Para- | |database to the master device. The | Same as above |meters | |channel query response message MUST | |are | |include parameters as required by | |included | |local regulatory requirement. These | |in | |parameters MAY include available | |Response | |channels, duration of time for their | | message | |use, associated maximum power levels,| | | |any additional sensing requirements. | | | +--------------------------------------+------------------+----------+ |P.13 The protocol MUST support a | | | |channel query request from the slave | Currently | | |device to the master device. The | supported | Air | |channel query request message MUST | via air |interface | |include parameters as required by | interface |dependent | |local regulatory requirement. These | mechanism | | |parameters MAY include device ID and | | | |slave device location. | | | +--------------------------------------+------------------+----------+ |P.14 The protocol MUST support a |Device validation |Parameters| |validation request from the master to | function is |are | |the database to validate a slave | supported |included | |device. The validation request MUST | |in Request| |include the slave device ID. | |message | +--------------------------------------+------------------+----------+ |P.15 The protocol MUST support a | Same as above | Included | |validation response from the database | | in | |to the master. The validation | | Response | |response MUST include a response code.| | message | +--------------------------------------+------------------+----------+ |P.16 The protocol MUST support a | | | |channel query response from the master| Currently | Air | |device to the slave device. The | supported via |interface | |channel query response message MUST | air interface |dependent | |include parameters as required by | mechanism | | |local regulatory requirement, | | | |including a response code and | | | |sufficient information to decode an | | | |enabling signal. | | | +--------------------------------------+------------------+----------+ |P.17 The protocol MUST support an | | | Das, ed., et al. Expires September 13, 2012 [Page 23] Internet-Draft Device to Database Protocol March 2012 |enabling signal sent from the master | Same as above | Same as | |to the slave. This signal MUST allow | |above | |the slave device to validate that a | | | |previously received available channel | | | |list is still valid or not. This | | | |MUST be encoded to allow the slave | | | |device to determine the identity if | | | |the sending master device. | | | +--------------------------------------+------------------+----------+ |P.18 The protocol between the master| |Parameters| | device and the database MUST support | Capabilities are | are | |the capability to change channel | included in | included | |availability lists on short notice. | query function | | | | | | +--------------------------------------+------------------+----------+ |P.19 The protocol between the master | |Parameters| |device and the database MUST support |Capabilities are | are | |a channel availability request which | included in | included | |specifies a geographic location as an | query function | | |area as well as a point | | | +--------------------------------------+------------------+----------+ Authors' Addresses Subir Das, ed. Applied Communication Sciences 1 Telcordia Drive Piscataway, NJ 08854 U.S.A. Email: sdas@appcomsci.com John Malyar Telcordia Technologies Inc. 1 Telcordia Drive Piscataway, NJ 08854 U.S.A. Email: jmalyar@telcordia.com Das, ed., et al. Expires September 13, 2012 [Page 24] Internet-Draft Device to Database Protocol March 2012 Dan Harasty Applied Communication Sciences 331 Newman Springs Road Red Bank, NJ 07701 U.S.A. Email: dharasty@appcomsci.com Das, ed., et al. Expires September 13, 2012 [Page 25]