Device to Database Protocol for White Space
draft-das-paws-protocol-01
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Subir Das , John P. Malyar , Dan Harasty | ||
| Last updated | 2012-03-12 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-das-paws-protocol-01
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]