Applications Area Working Group John P Malyar Internet-Draft Dan Harasty Intended status:Standards Track Subir Das Expires: May 14, 2012 Telcordia Technologies Inc November 14, 2011 Device to Database Protocol for White Space 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), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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". The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 12, 2012. Copyright and License 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. Abstract This version of the document describes a protocol design framework for Whitespace Devices to access Whitespace Database. Das et al. Expires May 14, 2012 [Page 1] Internet-Draft WS Protocol November 2011 Table of Contents 1. Convention used in this document . . . . . . . . . . . . . . . . 2 2. Terminology and abbreviations used in this document . . . . . . . 2 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Protocol layering . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Protocol Features/Functionalities . . . . . . . . . . . . . . . . 6 5.1. Device Bootstrapping . . . . . . . . . . . . . . . . . . . . . 6 5.2. Device Registration . . . . . . . . . . . . . . . . . . . . . . 8 5.3. Querying the Database . . . . . . . . . . . . . . . . . . . . . 10 5.4. Device Validation . . . . . . . . . . . . . . . . . . . . . . . 13 6. Encoding Considerations . . . . . . . . . . . . . . . . . . . . . 15 7. Security Consideration . . . . . . . . . . . . . . . . . . . . . 15 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 16 9.1. Normative References . . . . . . . . . . . . . . . . . . . . . 16 9.2. Informative References . . . . . . . . . . . . . . . . . . . . 16 10. Authors` Address . . . . . . . . . . . . . . . . . . . . . . . 16 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 [RFC-2119]. White Space (WS) and TV White Space (TVWS) are often used interchangeably in this document. 2. Terminology and abbreviations used in this document Following definitions are copied from [[I-D.ietf-paws-problem-stmt-usecases-rqmts] 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 licensed user (such as a wireless microphone), at a specific location and time. White Space Radio spectrum which has been allocated for some primary use, but is not fully occupied by that primary use at a specific location and time. White Space Device A device which is a secondary user of some part of white space spectrum. A white space device can be an access point, base station, a portable device or similar. In this context, a white space device is required to query a database with its location to obtain information about available spectrum Das et al. Expires May 14, 2012 [Page 2] Internet-Draft WS Protocol November 2011 Database In the context of white space and cognitive radio technologies, the database is an entity which contains current information about available spectrum at any given location and other types of information. Master Device A device which queries the WS Database to find out the available operating channels. Following definitions are copied from [FCC]. 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 the TV Whitespaces initiative will require a variety of devices and services each acting in accord with rules provided by the regulatory bodies and industries. In this document, we focus on one aspect of that overall system: the interface between a `Device` and `WS Database`. The `Device` type definition may differ from one regulatory authority to another. For example, by United States (US) FCC rules, `Device` is referred to a `Fixed` and `Personal/Portable device` (e.g. `Mode II personal/portable device` [FCC]). The Fixed and personal/portable TVWS devices may additionally support other Whitespace devices (e.g. Mode I personal/portable device per US FCC rules [FCC]) to establish wireless broadband services. Several use cases and requirements for use of White Space spectrum are described in draft document [I-D.ietf-paws-problem-stmt-usecases-rqmts]. Das et al. Expires May 14, 2012 [Page 3] Internet-Draft WS Protocol November 2011 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]: - 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. - Along with the list of frequencies/channels, the database should also return maximum permissible power levels that could be used by the TVWS devices. - Fixed and Mode II devices are required to access TVWS database every 24 hours to get a list of available TV bands. - The Mode II device must additionally do the same upon power-up, and whenever they change their position by 50 meters or more. - 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 ensure that the specified Mode I devices are valid devices at the given location. On the other hand, there may be different rules and requirements Specified by 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. Protocol Layering Figure 1 provides a high level overview of the protocol layers. The Whitespace application protocol should use existing Internet protocols to provide security and reliable transport. For example, the protocol proposed here could be supported over HTTPS, TCP, and IP. +-+-+-+-+-+-+-+-+-+-+-+-+ | WS Appl. Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+ | HTTPS | +-+-+-+-+-+-+-+-+-+-+-+-+ | Reliable Transport | +-+-+-+-+-+-+-+-+-+-+-+-+ | IP | +-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Example Protocol Layers The details of adapting the White space application protocol to this or other supporting protocol stacks is not addressed at this time. 5. Protocol Features/Functionalities WS protocol must support several regulatory requirements and include features that are essential between the `Device` and the `WS database`. Das et al. Expires May 14, 2012 [Page 4] Internet-Draft WS Protocol November 2011 `Device` refers to an entity that queries the WS Database to find out the available operating channels. This is same as `Master Device` as defined in [I-D.ietf-paws-problem-stmt-usecases-rqmts]. In this document, we list some of the protocol functionalities that we believe are required. These features are by no means required to be performed in a sequential manner. It is important to note that there may be additional features that need to be supported by the interface. 5.1. Device Bootstrapping Device bootstrapping is the process whereby device establishes an Initial connection to the database. For example, each time the 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 security parameters so that the subsequent messages can be authenticated and integrity protected. We propose to perform the authentication at the application layer, so as to allow a greater range of deployment scenarios. However, one can argue that the device authentication and message integrity can be provided by lower protocol layers. INIT-REQ and INT-RESP are proposed for bootstrapping the device with the database. Figure 2 depicts the message flow and example message parameters are then discussed. Device WS Database | | | INT-REQ | |---------------------->| | INT-RESP | |<----------------------| | | | | Figure 2: Device Bootstrapping Message Flow INIT-REQ: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ver | Authority | Device Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Device Identity (e.g., Regulatory ID, Serial Number..) | . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Ver - Protocol version Das et al. Expires May 14, 2012 [Page 5] Internet-Draft WS Protocol November 2011 Authority - Indicates the regulatory rules that need to be applied to the device Device Type - Type of devices , for example, in US FCC rules this is called Fixed or Mode II device Device Identity - Information that identifies the class of device (e.g., FCC ID in case of US, Manufacturer Serial number, and so on) INIT-RESP: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ver | Authority | Result Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Security Information (e.g., authentication parameters ) | . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Ver - Protocol version Authority - Indicates the regulatory rules that need to be applied to the device Result Code - Indicates success or failure Security Information - Information required to initiate the authentication process or perform the capability negotiation 5.2. Device Registration Device 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 owner and/or operator contact information. `Fixed Devices` may also register their fixed location and antenna height parameters so as to obviate sending that information in other messages that would otherwise require them. Registration thus should not, therefore, be performed upon each power-up; rather, only once upon initial contact with the database, and thereafter, only 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. Das et al. Expires May 14, 2012 [Page 6] Internet-Draft WS Protocol November 2011 REG-REQ and REG-RESP messages are used for device registration with the database. Figure 3 depicts the message flow and example message parameters are then discussed: Device WS Database | | | REG-REQ | |---------------------->| | REG-RESP | |<----------------------| | | | | Figure 3: Device Registration Message Flow REG-REQ: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ver | Authority | Device Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Device Identity (e.g.,Regulatory ID, Device serial number,) | . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Device Location Information(e.g., Geo-location (latitude, | | longitude, Antenna Height, and so on)) | . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Device Owner | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Authentication Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Ver - Protocol version Authority - Indicates the regulatory rules that need to be applied to the device Device Type - Type of devices , for example, in US FCC rules this is referred to as Fixed or Mode II device Device Identity - Information that identifies the class of device (e.g., FCC ID in case of US, Manufacturer Serial number, and so on) Device Location - Location information of the device, for example, Geo-location, information about lat, long, antenna Das et al. Expires May 14, 2012 [Page 7] Internet-Draft WS Protocol November 2011 height and so on (location encoding of location is TBD) Device Owner - Owner of the device Message Authentication Code - Code that authenticates the ownership Of the message REG_RESP: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ver | Authority | Sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Result Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Authentication Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Ver - Protocol version Authority - Indicates the regulatory rules that need to be applied to the device Operator Sequence no - Represents the message sequence Result Code - Success or failure of device registration Message Authentication Code - Code that authenticates the ownership of the message 5.3. Querying the Database In order to obtain the available channel and other associated parameters, the device needs to query the database. In certain regulatory environments, it may be required to be authenticated and registered before a device can query the database. In other domains, requirements may be vary. When the `Device` sends a query to the `WS Database`, it sends its location (e.g., Geo-location) along with other parameters. `WS 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 available channel in a given location. Figure 4 depicts Das et al. Expires May 14, 2012 [Page 8] Internet-Draft WS Protocol November 2011 the query message flow and example message parameters are then discussed: Device WS Database | | | AVAIL-CHAN-REQ | |---------------------->| | AVAIL-CHAN-RESP | |<----------------------| | | | | Figure 4: Query Message Flow AVAIL-CHAN-REQ: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ver | Authority | Device Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Device Identity (e.g.,Regulatory ID, Device serial number,) | . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Device Location (e.g., Geo-location (latitude, longitude, | | Antenna Height, and so on) | . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Authentication Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Ver - Protocol version Authority - Indicates the regulatory rules that need to be applied to the device Device Type - Type of devices , for example, in US FCC rules this is referred to as Fixed or Mode II device Device Identity - Information that identifies the class of device (e.g., FCC ID in case of US, Manufacturer Serial number, and so on) Device Location - Location information of the device for example, Geo-location, information about lat, long, antenna height and so on (location encoding of location is TBD) Message Authentication Code - Code that authenticates the owner of the Message Das et al. Expires may 14, 2012 [Page 9] Internet-Draft WS Protocol November 2011 AVAIL-CHAN-RESP: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ver | Authority | Result Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence number| Available Channel(s)(e.g., List[Channel | | Frequency Range, Availability, Scope, | | Max power and so on]) | . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Authentication Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Ver - Protocol version Authority - Indicates the regulatory rules that need to be applied to the device Result Code - Success or failure of device registration Sequence number - Represents the message sequence Available Channel(s) - An array or set of channels within the scope Of the request and regulatory authority where the returned elements contain for example, the channel frequency range, availability indicator, operating power, event , and so on. Message Authentication Code - Code that authenticates the ownership of the message 5.4. Device Validation Device validation is the process by which devices 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, the WS server needs to support `Device Validation` capability. DEV-VALID-REQ and DEV-VALID-RESP messages are used for device Validation with the database. Figure 5 depicts the message flow of the Device validation and example message parameters are then discussed: Das et al. Expires May 12, 2012 [Page 10] Internet-Draft WS Protocol November 2011 Device WS Database | | | DEV-VALID-REQ | |---------------------->| | DEV-VALID-RESP | |<----------------------| | | Figure 5: Device validation Message Flow DEV-VALID-REQ: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ver | Authority | Device Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Device Identity(e.g.,Regulatory ID, Device serial number,..) | . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Device Location (e.g., Geo-location (latitude, longitude, | | Antenna Height, and so on) | . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Device List (e.g., ID, Serial number..) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Authentication Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Ver - Protocol version Authority - Indicates the regulatory rules that need to be applied to the device Device Type - Type of devices , for example, in US FCC rules this is referred to as Fixed and Mode II device Device Identity - Information that identifies the class of device (e.g., FCC ID in case of US, Manufacturer Serial number, and so on) Device Location - Location information of the device for example, Geo-location, information about lat, long, antenna height and so on (location encoding of location is TBD) Device List - List of one or more devices that needs the validation with ID, manufacturer serial number and so on.. Das et al. Expires May 14, 2012 [Page 11] Internet-Draft WS Protocol November 2011 Message Authentication Code - Code that authenticates the ownership of the message DEV-VALID-RESP: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ver | Authority | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Device List (List/Array [result code]) | . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Authentication Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Ver - Protocol version Authority - Indicates the regulatory rules that need to be applied to the device Sequence number - Represents the message sequence Device list - List/Array of devices with success or failure Message Authentication Code - Code that authenticates the ownership of the message 6. Encoding Considerations The examples above suggest the message structure will have bit-oriented fields, similar to the definition of TCP headers. However, such should be taken as an illustrative example only. Other encodings (message marshalling techniques) which convey the same semantic information can and should be considered. For example, using XML or JSON to encode the same fields discussed above should be an acceptable way forward. This may in fact provide development and operational benefits. 7. Security Consideration Following security requirements should be satisfied: - Mutual Authentication - Message Integrity Das et al. Expires May 14, 2012 [Page 12] Internet-Draft WS Protocol November 2011 - Confidentiality (optional) - Replay protection Others are TBD. The requirement for the protocol to meet these may be considered in conjunction with the underlying services and transports. For example, the above protocol framework provides device authentication, replay- protection, and message integrity at the application level. However, the confidentiality is assumed to be provided by the underlying transport protocol. 8. Acknowledgements 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 9.2. Informative References [FCC] Second Memorandum Opinion and Order, FCC 10-174, September, 2010 [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- rqmts01(work in progress), November 2011 10. Authors` Address John P. Malyar Telcordia Technologies Inc One Telcordia Drive Piscataway, NJ, 08854 Email: jmalyar at Telcordia dot com Dan Harasty Telcordia Technologies Inc 331 Newman Springs Road Room NVC 2Z-447 Red Bank, NJ 07701 Email: dharasty at Telcordia dot com Das et al. Expires May 14, 2012 [Page 13] Internet-Draft WS Protocol November 2011 Subir Das Telcordia Technologies Inc One Telcordia Drive Piscataway, NJ, 08854 Email: subir at research dot Telcordia dot com Das et al. Expires May 14, 2012 [Page 14]