PAWS J. Caufield
Internet-Draft Key Bridge
Intended status: Experimental October 31, 2011
Expires: May 3, 2012
Protocol to query a White Space Database
draft-caufield-paws-protocol-for-tvws-01.txt
Abstract
Regulatory entities in many countries are making spectrum previously
used by television stations available for secondary use as a result
of the switch from analog to digital. The spectrum in such cases is
still owned by the primary user to whom it is licensed. However
parts of the spectrum may be unused at a given location or time and
hence can be made available for secondary use. In order to use such
spectrum a device has to query a database in order to obtain a list
of available channels or spectrum at a given location and time. This
document specifies protocol elements that can be used to query a
white space database and obtain a response by a device.
Status of this Memo
This Internet-Draft is submitted 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 May 3, 2012.
Copyright Notice
Copyright (c) 2011 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
Caufield Expires May 3, 2012 [Page 1]
Internet-Draft Protocol to query WS DB October 2011
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
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3
3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
5. Protocol approach . . . . . . . . . . . . . . . . . . . . . . 4
6. Data Model details . . . . . . . . . . . . . . . . . . . . . . 5
6.1. White Space Query Object . . . . . . . . . . . . . . . . . 5
6.1.1. Query object definition . . . . . . . . . . . . . . . 5
6.2. White Space Response Object . . . . . . . . . . . . . . . 6
6.2.1. Response Object Definition . . . . . . . . . . . . . . 6
6.3. Elements of the Query and Response objects . . . . . . . . 7
6.3.1. Station element . . . . . . . . . . . . . . . . . . . 7
6.3.2. Schedule element . . . . . . . . . . . . . . . . . . . 7
6.3.3. ChannelList element . . . . . . . . . . . . . . . . . 8
6.3.4. ContactList element . . . . . . . . . . . . . . . . . 8
6.3.5. Location element . . . . . . . . . . . . . . . . . . . 8
6.3.6. Antenna element . . . . . . . . . . . . . . . . . . . 8
6.3.7. StationRxList element . . . . . . . . . . . . . . . . 9
6.3.8. TransmitterList element . . . . . . . . . . . . . . . 9
6.3.9. Address element . . . . . . . . . . . . . . . . . . . 9
6.3.10. Coordinate element . . . . . . . . . . . . . . . . . . 10
6.3.11. RadiationPattern element . . . . . . . . . . . . . . . 10
6.3.12. Contact Element . . . . . . . . . . . . . . . . . . . 10
6.3.13. Extension element . . . . . . . . . . . . . . . . . . 10
6.3.14. WhiteSpaceFrequencyList element . . . . . . . . . . . 11
6.3.15. WhiteSpaceFrequency element . . . . . . . . . . . . . 11
6.3.16. Channel Element . . . . . . . . . . . . . . . . . . . 11
6.3.17. Transmitter Element . . . . . . . . . . . . . . . . . 12
6.4. Attributes definition . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
8. Security Considerations . . . . . . . . . . . . . . . . . . . 19
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
10.1. Normative References . . . . . . . . . . . . . . . . . . . 19
10.2. Informative References . . . . . . . . . . . . . . . . . . 20
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20
Caufield Expires May 3, 2012 [Page 2]
Internet-Draft Protocol to query WS DB October 2011
1. Introduction
Regulatory entities in many countries are making spectrum previously
used by television stations available for secondary use as a result
of the switch from analog to digital. The spectrum in such cases is
still owned by the primary user to whom it is licensed. However
parts of the spectrum may be unused at a given location or time and
hence can be made available for secondary use. In order to use such
spectrum a device has to query a database in order to obtain a list
of available channels or spectrum at a given location and time. This
document specifies protocol elements that can be used to query a
white space database and obtain a response by a device.
The problem statement, use cases and requirements for the use of
white space spectrum and the associated protocol is captured in the
document: [I-D.ietf-paws-problem-stmt-usecases-rqmts].
2. Terminology and Abbreviations
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].
This document relies on the terminology specified in
[I-D.ietf-paws-problem-stmt-usecases-rqmts].
3. Background
Spectrum is a scarce resource and hence it is essential that
technology provide a means to use this resource in an optimal manner.
Spectrum has been generally licensed or granted or reserved for
specific use by regulatory bodies and governments. Some spectrum
such as the ISM band has been made publicly available for use without
any licenses but still with a set of regulations. In many cases
spectrum that has been licensed to an entity or reserved is either
not utilized or under utilized. As the demand for services over
wireless medium continues to grow the need for additional spectrum is
increasing. Cognitive radio and white space technology is a solution
that allows the use of spectrum by a secondary user at a given
location if the primary user is either not using the spectrum at a
given time and without causing interference to the primary user.
Regualtions to this effect have been specified by the FCC in the US
and other regulatory bodies in many other countries are also studying
similar approaches for parts of the spectrum.
One of the approaches to determining if spectrum is available at a
Caufield Expires May 3, 2012 [Page 3]
Internet-Draft Protocol to query WS DB October 2011
given location and time is to query a centralized database and obtain
information about what channels or spectrum can be used. There may
exist multiple databases from which such information can be obtained.
A standardized query/response mechanism is in the scope of the PAWS
working group. This document proposes a data format for the query
and response aspects of the protocol.
4. Problem Statement
The query/response protocol to obtain information about available
channels or spectrum can be specified using various means. LDAP is
an example of a protocol that can be used for this purpose. However
one of the objectives of this protocol is to ensure that it is
globally applicable and can be adapted for use in various regulatory
environments. The elements of the query and response can vary
depending on the country or region where a device is making a query
to a database. As a result of this objective, flexibility of the
protocol in terms of the attributes and parameters carried in the
query and response are quite important.
5. Protocol approach
This document does not specify the complete protocol itself. The
protocol can be split into three parts:
1. The data model
2. The transport protocol
3. The security solution
A data model for the query/response protocol is proposed in this
document. A hierarchical object model approach is used for defining
the query/response and its attributes. The figure below is a high-
level view of how the data model is structured:
Caufield Expires May 3, 2012 [Page 4]
Internet-Draft Protocol to query WS DB October 2011
-------------
|WS Protocol|
-------------
|
|
-------------------------------------
| |
--------- ------------
|wsQuery| |wsResponse|
--------- ------------
| |
---------- ----------
|Element1| ...5, 6, 7 |Elementx| ... y,z
---------- . . . ---------- . .
| . . . | . .
------------ . . . ------------ . .
|Attributes| o o o o o |Attributes| o o o
------------ ------------
Figure 1: Data Model
6. Data Model details
The data model includes two main objects, the wsQuery and wsResponse
objects. Each of these objects contain a list of elements. The
elements are further comprised of attributes. The wsQuery object is
sent by a WS Master device to a database and the database responds
with a wsResponse object. The actual message and header in which
this object is carried is not specified here and is expected to be
specified elsewhere. Neither does this document specify how the
device discovers the database or how the object is transported or
secured.
6.1. White Space Query Object
The whitespaceQuery object is a data object carried in a request
message that any white space client (e.g. a white space device,
software application, coexistence manager, etc.) may use to request
information from a white space database, as part of a Rules-compliant
data transaction.
6.1.1. Query object definition
Caufield Expires May 3, 2012 [Page 5]
Internet-Draft Protocol to query WS DB October 2011
whitespaceQuery Object
6.2. White Space Response Object
A whitespaceResponse object is a generalized message response
structure that any white space administrator (e.g. a white space
database implementation) may use to communicate white space
information in a Rules-compliant data transaction.
The whitespaceResponse object structure is intended to accommodate
various responses to information queries from different white space
client such as, for example, white space devices (for transmission),
management systems (not for transmission) and consumers (not for
transmission).
6.2.1. Response Object Definition
Caufield Expires May 3, 2012 [Page 6]
Internet-Draft Protocol to query WS DB October 2011
whitespaceResponse Object
6.3. Elements of the Query and Response objects
The whitespaceQuery and whitespaceResponse objects include multiple
elements. Some of the elements are common across the query and
response objects. The following sections define these elements.
6.3.1. Station element
A WSIF station object contains information about the inquiring
station including antenna, location, transmitter details, etc.
Station Element
6.3.2. Schedule element
Type: Schedule
A schedule object is used by white space devices to request temporary
spectrum access (i.e. less than 24 hours). The schedule element is
Caufield Expires May 3, 2012 [Page 7]
Internet-Draft Protocol to query WS DB October 2011
intended to enable the recording, persistence and distribution of
standardized iCalendar-compatible messages. The format of the
Schedule object is defined in [RFC5545].
6.3.3. ChannelList element
Type: Channel
A list of channels (i.e. frequency ranges) that are occupied by the
transmitter(s) at this station.
6.3.4. ContactList element
Type: Contact
A list of contacts associated with this station. For example, a
facility or on-site technical manager, administrator, and operational
contacts may be identified.
6.3.5. Location element
This element describes the station's physical and geographic
location.
Location Element
6.3.6. Antenna element
A description of this station's (transmit or receive) antenna,
including the required antenna parameters like pointing and elevation
information plus the radiation pattern.
Caufield Expires May 3, 2012 [Page 8]
Internet-Draft Protocol to query WS DB October 2011
Antenna Element
6.3.7. StationRxList element
Type: Station
For wireless services that include multiple stations, and especially
for wireless services with multiple TXRX stations, each receiving
station may indicate its respective upstream transmitting stations by
adding that transmitting station to this receiving stationis
rxStationList element. Example uses of this element include
Television translator stations, MVPD receive sites, etc.
6.3.8. TransmitterList element
Type: Transmitter
A station may support multiple transmitters operating within the same
geographic area and on the same schedule. For example, several
wireless microphones may operate simultaneously within the geographic
contour defined within this stationis location element. If the
stationType attribute indicates this station is receive-only then
this element SHOULD be null.
6.3.9. Address element
Type: Address
This element specifies the civic location of the station. The
structure of this element is described in [RFC5139].
Caufield Expires May 3, 2012 [Page 9]
Internet-Draft Protocol to query WS DB October 2011
6.3.10. Coordinate element
Type: Coordinate
this element specifies the geolocation of the station. The structure
of this element is described in [RFC5491].
6.3.11. RadiationPattern element
Type: RadiationPattern
A radiation pattern representing the directional (azimuth) dependence
of the strength of the radio signal from the antenna. The
radiationPattern represents the directional (azimuth) dependence of
the strength of the radio signal from the antenna.
A WKT MULTIPOINT SFA Geometry implementation. The azimuthal field
values are encoded as a well known text (WKT) MULTIPOINT object with
[azimuth, radial value] pairs encoded according to the format
POINT(x,y) = POINT(azimuth, field_value).
RadiationPattern Element
6.3.12. Contact Element
The contact represents a generalized container for individual
(person) and company (organization) contact information. The
structure of this element is defined in [RFC2426].
6.3.13. Extension element
Type: xs:string
A URL-ENCODED string containing key/value pairs that requesting
devices may implement and administrators may support at their
discretion to provide supplementary information or to otherwise
extend this object.
Caufield Expires May 3, 2012 [Page 10]
Internet-Draft Protocol to query WS DB October 2011
6.3.14. WhiteSpaceFrequencyList element
Contains a complete and canonical list of available and valid white
space frequencies that is appropriate for the inquiring message's
criterion. For white space devices, the whitespaceFrequencyList
element represents all channels available for unlicensed operation at
the inquiring deviceis location or indicated geographic area and
according to the schedule in this element.Contains one or more
occurencies of WhiteSpaceFrequency elements.
6.3.15. WhiteSpaceFrequency element
WhiteSpaceFrequency Element
6.3.16. Channel Element
A channel describes a fully qualified and canonical frequency range.
Channel object definitions support positive definitions of colloquial
channel identifiers (e.g. TV channel 24) through identification of
the authorizing regulatory definition and the TV channelis frequency
range.
Channel Element
Caufield Expires May 3, 2012 [Page 11]
Internet-Draft Protocol to query WS DB October 2011
6.3.17. Transmitter Element
The transmitter object provides an extensible software template to
contain and exchange required and optional but otherwise useful
transmitter information.
A transmitter provides an object template for common device-related
attributes and may be optionally used directly or, more likely, may
be extended by other, more specific transmitter descriptions that
fully describe a certain type wireless device. For this reason all
transmitter attributes and elements are defined as optional by
default. Attribute and element validity is expected to be defined in
transmitter-derived objects. The transmitter is designed to support,
through extension, the communication of required and optional but
otherwise useful information about licensed and unlicensed wireless
devices including transmitters, receivers and transceivers.
Transmitter Element
Caufield Expires May 3, 2012 [Page 12]
Internet-Draft Protocol to query WS DB October 2011
6.4. Attributes definition
This section defines the attributes which are included in the various
elements of the whitespacequery or whitespaceresponse objects.
Channel attribute
Type: xs: boolean
Description: An indicator for whether the radiationPattern element
of this object contains interpolated values.
Source attribute
Type: xs:string
Description: The originating source of the data represented in the
radiationPattern element. An example value for this attribute is
ius.fcc.cdbsi.
Directional attribute
Type: xs:boolean
Descrition: Indicates whether the antenna is directional (true) or
non-directional (false).
Rotation attribute
Type: xs:float
Description: Indicates the offset in degrees azimuth [0, 360] from
true North that the antenna radiation pattern should be rotated.
HeightAboveGround attribute
Type: xs:float
Description: The antenna radiation center height above ground
level.
Manufacturer attribute
Type: xs:string
Description: The antenna manufacturer
x-elevantModel attribute
Type: xs:string
Description: The digital elevation model used to calculate this
antenna objectis HAAT (x-haat) and rcAMSL (x-rcAmsl) values.
x-govtAntennaId attribute
Type: xs:int
Description: A reference to the antenna ID record within FCC CDBS
x-haat attribute
Type: xs:float
Caufield Expires May 3, 2012 [Page 13]
Internet-Draft Protocol to query WS DB October 2011
Description: The antenna height above average terrain
x-rcAmsl attribute
Type: xs:float
Description: The antenna radiation center above mean sea level
Frequency attribute
Type: xs:double
Description: If a specific frequency has been assigned to this
transmitter that information may be recorded here in MHz. If only
the channel is provided then the assignedFrequency value is set to
the center frequency of this transmitteris channel.
deviceID attribute
Type: xs:string
Description: The transmitter device's Government provided
identifier.
deviceSn attribute
Type: xs:string
Description: the transmitting device's manufacturer-provided
serial number.
ea attribute
Type: xs:string
Description: The Government equipment authorization agency from
which this device is authorized to operate and which issued the
device ID.
erp attribute
Type: xs: float
Description: The transmitting deviceis current effective radiated
power (ERP), measured in dBw.
isDigital attribute
Type: xs:boolean
Description: Indicates whether this transmitter is sending a
digital (TRUE) or analog (FALSE) carrier.
manufacturer attribute
Type: xs:string
Description: the device manufacturer company name
Model attribute
Type: xs:string
Description: the antenna product model
Caufield Expires May 3, 2012 [Page 14]
Internet-Draft Protocol to query WS DB October 2011
allocation attribute
Type: xs:string
Description:A dot-delimited reverse domain encoded description of
the frequency allocation defined according the following strategy:
[country].[regulator].[allocation].[band range]
For example, the UHF-high block allocation of TV channels 38 to 51
within the United States is identified as "us.fcc.broadcast.614-
698".
channel attribute
Type: xs:float
Description: The colloquial channel number
Note: A FLOAT number type is used to accommodate future sub-
channelization. For the avoidance of doubt channel numbers ending
in zero shall be interpreted to represent a whole channel. i.e.
float value channel 38.0 is equivalent to integer-value channel
38.
effectiveDate attribute
Type: xs:dateTime
Description: The date and time when this white space information
should be considered effective. The value may be set in the
future to accommodate frequencies that may become available at a
later date or time.
expirationDate attribute
Type: xs:dateTime
Description: The date and time when this white space information
expires.
locationType attribute
Type: xs:string
Description: A descriptor string used to classify and organize
locations. If the location is derived from another database
source, this attribute is a dot-delimited string used to identify
this location type and its source. An example value for this
attribute is "us.fcc.cdbs.stationClass.CDT".
Caufield Expires May 3, 2012 [Page 15]
Internet-Draft Protocol to query WS DB October 2011
maxEIRP attribute
Type: xs:float
Description: The maximum allowable equivalent isotripically
radiated power (EIRP) that a white space device may transmit on
the indicated channel. Provided in dBW.
maxFreq attribute
Type: xs:double
Description: The maximum (or end) frequency of the indicated
channel in MHz.
messageType attribute
Type: xs:string
Description: An enumerated message type. Allowed message types
are:
Message code: ws.messageType.TVBD.QUERY
Description: The message is a certified client-initiated query for
white space frequency information for the purposes of
transmission. Examples of certified clients include FCC-certified
white space devices and other devices authorized to operate within
the band (e.g. wireless microphones, medical telemetry, PLMRS
systems, etc.)
Message code: ws.messageType.TVBD.RESPONSE
Description: The message is a response to a TVBD.QUERY request for
information.
Message code: ws.messageType.INFORMATION.QUERY
Description: The message is a non-certified client-initiated query
for general (possibly white-space) frequency information NOT for
the purposes of transmission. Examples of non-certified clients
include network management and planning systems, client software
applications, etc.
Message code: ws.messageType.INFORMATION.RESPONSE
Description: The message is a response to an INFORMATION.QUERY
request for information.
minFreq attribute
Type: xs:double
Description: The minimum (or start) frequency of the indicated
channel in MHz.
name attribute
Caufield Expires May 3, 2012 [Page 16]
Internet-Draft Protocol to query WS DB October 2011
Type: xs:string
Description: A human readable name or label that may be used to
identify a location or station. A useful hint is to use a
memorable place name as might be represented on a map (e.g.
"Empire State Building"). For licensed wireless services it is
recommended to use the facility call sign. For unlicensed
wireless services it is recommended to use the venue name.
protocolVersion attribute
Type: xs:float
Description: The message protocol version.
stationClass attribute
Type: xs:string
Description: Indicates the station classification. Classification
may be used to determine whether and how many elements of this
station are required for validation. Allowed values are:
TX. This is a transmitting station and a transmitter is required
in the transmitterList element
RX. This is a receive-only station and a transmitter element is
NOT required
TXRX. This station is able to both transmit and receive and a
transmitter is required in the transmitterList element.
stationType attribute
Type: xs:string
Description: A description of this station's operation.
statusIndicator attribute
Type: xs:int
Description: The number of available white space channels included
in the message. A negative value indicates that an error
condition has occured.
timeStamp attribute
Type: xs:dateTime
Description: When the message was created.
uuid attribute
Type: xs:string
Caufield Expires May 3, 2012 [Page 17]
Internet-Draft Protocol to query WS DB October 2011
Description (for use in Location):A universally unique identifier
(UUID) associated with and permanently assigned to this location.
Description (for use in Station):A universally unique identifier
(UUID) associated with and permanently assigned to this station.
Description (for use in whitespaceFrequency): A universally unique
idenfifier (UUID) assigned by an Administrator that is associated
with this freuquency
Description (for use in whitespaceQuery): A universally unique
identifier (UUID) created by the inquiring agent (i.e. a TV band
device, user software, etc.) and associated with this whitespace
query message. This uuid may be used to correlate a
whitespaceResponse message with this whitespaceQuery and to
simplify logging and archival.
Description (for use in whitespaceResponse): A universally unique
identifier (UUID), set to match the client's whitespaceQuery.uuid
attribute and to simplify logging and arhival.
x-geocode attribute
Type: xs:string
Description: An enumerated value indicating whether any one of
this location object's components have been calculated according
to another of this location object's set parameters.
Allowed values are:
NO (xs:string) (DEFAULT). The coordinate, address and geometry
elements of this location are not correlated.
GC (xs:string). The coordinate.[longitude, latitude] and
geometry.point values have been calculated and set according to a
Geo-coding algorithm from the address.
RG (xs:string). The address has been calculated and set according
to a Reverse Geo-coding algorithm from the coordinate.[longitude,
latitude] value.
x-haat attribute
Type: xs:float
Description: The ground height above average terrain value at this
location's coordinates, calculated according to the methodology
described in 47 CFR 73.684(d). The elevation model used in the
calculation of this location attribute is recorded in the
coordinate.x-elevationModel attribute. This value is used to
support TVBD transmit antenna compliance with 15.709(b)(2), which
states that the ground level HAAT must be below 76 meters.
x-timeZone attribute
Caufield Expires May 3, 2012 [Page 18]
Internet-Draft Protocol to query WS DB October 2011
Type: xs:string
Description: The local time zone at this location. Two
interchangeable formats are supported, with the zoneinfo format
preferred:
The zoneinfo database format (e.g. "America/New_York")
An offset to Coordinated Universal Time (e.g. "UTC-05:00" or
"UTC-5"
Note: Three-character notation (e.g. "EDT") is not supported.
7. IANA Considerations
This document will require actions on the part of IANA to assign
values for the new messages and attributes.
8. Security Considerations
This document defines the data model for the database query and
response protocol to be used between white space devices and a
database. The actual security for the messages that transport these
objects needs to be specified in the relevant document.
9. Acknowledgements
This document has been made possible as a result of the efforts of
Basavaraj Patil and Scott Probasco.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2426] Dawson, F. and T. Howes, "vCard MIME Directory Profile",
RFC 2426, September 1998.
[RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location
Format for Presence Information Data Format Location
Object (PIDF-LO)", RFC 5139, February 2008.
[RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
Presence Information Data Format Location Object (PIDF-LO)
Usage Clarification, Considerations, and Recommendations",
RFC 5491, March 2009.
Caufield Expires May 3, 2012 [Page 19]
Internet-Draft Protocol to query WS DB October 2011
[RFC5545] Desruisseaux, B., "Internet Calendaring and Scheduling
Core Object Specification (iCalendar)", RFC 5545,
September 2009.
10.2. Informative References
[I-D.ietf-paws-problem-stmt-usecases-rqmts]
Probasco, S., Bajko, G., Patil, B., and B. Rosen,
"Protocol to Access White Space database: PS, use cases
and rqmts", draft-ietf-paws-problem-stmt-usecases-rqmts-00
(work in progress), September 2011.
Author's Address
Jesse Caufield
Key Bridge
1600 Tysons Blvd, Suite 450
McLean VA 22102
USA
Email: jesse.caulfield@keybridgeglobal.com
Caufield Expires May 3, 2012 [Page 20]