PAWS J. Caufield
Internet-Draft Key Bridge
Intended status: Experimental Protocol October 31, 2011
Expires: May 03, 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 03, 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 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

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 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:



	                   -------------
	    		   |WS Protocol|
			   -------------
				 |
				 |
		 -------------------------------------
	    	 |                                   |
	    ---------                            ------------
	    |wsQuery|  				 |wsResponse|
	    --------- 				 ------------
		|      	       	       	       	       |
	    ----------				  ----------
	    |Element1| ...5, 6, 7                 |Elementx| ... y,z
	    ----------	  .  . 	.	       	  ----------	 . .
	       	|	  .  .	.      	       	       |       	 . .
       	    ------------  .  .	.      	       	  ------------	 . .
	    |Attributes| o o o o o     	       	  |Attributes| o o o
	    ------------	  		  ------------

           

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

<xs:complexType name="whitespaceQuery">
		<xs:all>
			<xs:element name="station" 	type="station"/>
			<xs:element name="schedule" 	type="schedule" minOccurs="0"/>
			<xs:element name="extension" 	type="xs:string" minOccurs="0"/>
		</xs:all>
		<xs:attribute name="uuid" 		type="xs:string" use="required"/>
		<xs:attribute name="protocolVersion" 	type="xs:float" use="required"/>
		<xs:attribute name="messageType" 	type="xs:string" use="required"/>
</xs:complexType>

               

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


<xs:complexType name="whitespaceResponse">
		<xs:sequence>
			<xs:element name="station" 	type="station"/>
			<xs:element name="whitespaceFrequencyList" type="whitespaceFrequency" 
				    nillable="true" minOccurs="1" maxOccurs="unbounded"/>
			<xs:element name="extension" 	type="xs:string" minOccurs="0"/>
		</xs:sequence>
		<xs:attribute name="uuid" 	type="xs:string" use="required"/>
		<xs:attribute name="effectiveDate" 	type="xs:dateTime" use="required"/>
		<xs:attribute name="expirationDate" 	type="xs:dateTime" use="required"/>
		<xs:attribute name="messageType" 	type="xs:string" use="required"/>
		<xs:attribute name="protocolVersion" 	type="xs:float" use="required"/>
		<xs:attribute name="statusIndicator" 	type="xs:int" use="required"/>
		<xs:attribute name="timeStamp" 	type="xs:dateTime" use="required"/>
</xs:complexType>

       

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.


<xs:complexType name="station">
		<xs:sequence>
			<xs:element name="channelList"	type="channel" maxOccurs="unbounded"/>
			<xs:element name="contactList"	type="contact" maxOccurs="unbounded"/>
			<xs:element name="location"	type="location"/>
			<xs:element name="antenna"	type="antenna" minOccurs="0"/>
			<xs:element name="schedule"	type="schedule" minOccurs="0"/>
			<xs:element name="stationRxList"	
				    type="station" minOccurs="0" maxOccurs="unbounded"/>
			<xs:element name="transmitterList"	
				    type="transmitter" minOccurs="0" maxOccurs="unbounded"/>
			<xs:element name="extension"	
				    type="xs:string" minOccurs="0"/>
			<xs:element name="x-licenseInformationList"
			
				    type="licenseInformation" 
				    minOccurs="0" maxOccurs="unbounded"/>
		</xs:sequence>
		<xs:attribute name="uuid"	type="xs:string" use="required"/>
		<xs:attribute name="name"	type="xs:string" use="required"/>
		<xs:attribute name="stationClass"	type="xs:string" use="required"/>
		<xs:attribute name="description"	type="xs:string"/>
		<xs:attribute name="stationType"	type="xs:string"/>
	</xs:complexType>
       

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 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.

<xs:complexType name="location">
		<xs:all>
			<xs:element name="address" 	type="address" minOccurs="0"/>
			<xs:element name="coordinate" 	type="coordinate" minOccurs="0"/>
		</xs:all>
		<xs:attribute name="uuid" 	type="xs:string" use="required"/>
		<xs:attribute name="name" 	type="xs:string" use="required"/>
		<xs:attribute name="locationType" 	type="xs:string"/>
		<xs:attribute name="x-geocode" 	type="xs:string"/>
		<xs:attribute name="x-haat" 	type="xs:float"/>
		<xs:attribute name="x-timeZone" 	type="xs:string"/>
</xs:complexType>
       

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.

<xs:complexType name="antenna">
		<xs:sequence>
			<xs:element name="radiationPattern" 	type="radiationPattern"/>
		</xs:sequence>
		<xs:attribute name="directional" 		type="xs:boolean" use="required"/>
		<xs:attribute name="rotation" 			type="xs:float" use="required"/>
		<xs:attribute name="heightAboveGround" 		type="xs:float" use="required"/>
		<xs:attribute name="manufacturer" 		type="xs:string"/>
		<xs:attribute name="model" 			type="xs:string"/>
		<xs:attribute name="x-elevationModel" 		type="xs:string"/>
		<xs:attribute name="x-govtAntennaId" 		type="xs:int"/>
		<xs:attribute name="x-haat" 			type="xs:float"/>
		<xs:attribute name="x-rcAmsl" 			type="xs:float"/>
	</xs:complexType>
       

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 stationís 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 stationís 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].

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).

<xs:complexType name="radiationPattern">
		<xs:sequence>
			<xs:element name="radiationPattern" 	type="xs:string"/>
		</xs:sequence>
		<xs:attribute name="source" 			type="xs:string" use="required"/>
		<xs:attribute name="description" 		type="xs:string"/>
		<xs:attribute name="x-interpolated" 		type="xs:boolean"/>
	</xs:complexType>
       

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.

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 deviceís 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

<xs:complexType name="whitespaceFrequency">
		<xs:all>
			<xs:element name="channel" 	type="channel"/>
			<xs:element name="location" 	type="location"/>
			<xs:element name="schedule" 	type="schedule"/>
			<xs:element name="extension" 	type="xs:string" minOccurs="0"/>
		</xs:all>
		<xs:attribute name="uuid" 	type="xs:string" use="required"/>
		<xs:attribute name="maxEirp" 	type="xs:float" use="required"/>
</xs:complexType>

       

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 channelís frequency range.

<xs:complexType name="channel">
		<xs:attribute name="allocation" 	type="xs:string" use="required"/>
		<xs:attribute name="channel" 	type="xs:float" use="required"/>
		<xs:attribute name="minFreq" 	type="xs:double" use="required"/>
		<xs:attribute name="maxFreq" 	type="xs:double" use="required"/>
</xs:complexType>

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.

<xs:complexType name="transmitter">
		<xs:sequence>
			<xs:element name="channel"	type="channel" minOccurs="0"/>
			<xs:element name="extension"	type="xs:string" minOccurs="0"/>
		</xs:sequence>
		<xs:attribute name="frequency"	type="xs:double"/>
		<xs:attribute name="deviceId"	type="xs:string"/>
		<xs:attribute name="deviceSn"	type="xs:string"/>
		<xs:attribute name="description"	type="xs:string"/>
		<xs:attribute name="ea"	type="xs:string"/>
		<xs:attribute name="erp"	type="xs:float"/>
		<xs:attribute name="isDigital"	type="xs:boolean"/>
		<xs:attribute name="manufacturer"	type="xs:string"/>
		<xs:attribute name="model"	type="xs:string"/>
		<xs:attribute name="name"	type="xs:string"/>
		<xs:attribute name="x-digitalModRate"	type="xs:double"/>
		<xs:attribute name="x-digitalModType"	type="xs:string"/>
		<xs:attribute name="x-emissionCode"	type="xs:string"/>
		<xs:attribute name="x-equipmentClass"	type="xs:string"/>
		<xs:attribute name="x-equipmentRuleNum"	type="xs:string"/>
		<xs:attribute name="x-maxErp"	type="xs:float"/>
		<xs:attribute name="x-txWidth"	type="xs:float"/>
	</xs:complexType>
       

6.4. Attributes definition

This section defines the attributes which are included in the various elements of the whitespacequery or whitespaceresponse objects.

channel attribute

effectiveDate attribute

expirationDate attribute

locationType attribute

maxEIRP attribute

maxFreq attribute

messageType attribute

minFreq attribute

name attribute

protocolVersion attribute

stationClass attribute

stationType attribute

statusIndicator attribute

timeStamp attribute

uuid attribute

x-geocode attribute

x-haat attribute

x-timeZone attribute

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.
[RFC5545] Desruisseaux, B., "Internet Calendaring and Scheduling Core Object Specification (iCalendar)", RFC 5545, September 2009.
[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.
[RFC2426] Dawson, F. and T. Howes, "vCard MIME Directory Profile", RFC 2426, September 1998.

10.2. Informative References

[I-D.ietf-paws-problem-stmt-usecases-rqmts] Probasco, S and B Patil, "Protocol to Access White Space database: PS, use cases and rqmts", Internet-Draft draft-ietf-paws-problem-stmt-usecases-rqmts-01, October 2011.

Author's Address

Jesse Caufield Key Bridge 1600 Tysons Blvd, Suite 450 McLean, VA 22102 USA EMail: jesse.caulfield@keybridgeglobal.com