Internet DRAFT - draft-wei-paws-framework
draft-wei-paws-framework
Internet Engineering Task Force X. Wei
Internet-Draft L. Zhu
Intended status: Standards Track P. McCann
Expires: January 10, 2013 Huawei
July 9, 2012
PAWS Framework
draft-wei-paws-framework-00
Abstract
Portions of the radio spectrum that are allocated to a licensed,
primary use but are unused or unoccupied at specific locations and
times are defined as "white space". White space devices can make use
of this spectrum; however, they must first determine which spectrum
is unused or unoccupied by a primary user at their current location.
A white space database can be consulted that holds information about
primary users of the spectrum and that returns information about
white space. In this document we introduce a Protocol for Access to
WhiteSpace database (PAWS) which is for use between a white space
device and a white space database. We give a framework for PAWS, a
protocol stack that defines the interface between the white space
device and the white space database, the parameters of the protocol,
an XML schema that can encode the parameters, and example messages.
The realization of the database and the calculation of protected
contour are not considered in this framework draft.
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 January 10, 2013.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
Wei, et al. Expires January 10, 2013 [Page 1]
Internet-Draft PAWS Framework July 2012
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Abbreviation . . . . . . . . . . . . . . . . . 5
2.1. Conventions Used in This Document . . . . . . . . . . . . 5
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
3. Overview of PAWS . . . . . . . . . . . . . . . . . . . . . . . 6
4. Protocol Stack . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Protocol Framework and Interface of PAWS . . . . . . . . . . . 10
5.1. Database Discovery . . . . . . . . . . . . . . . . . . . . 11
5.2. Device Registration with Trusted Database . . . . . . . . 11
5.3. White Space Channel Query . . . . . . . . . . . . . . . . 14
5.4. Validation Procedure . . . . . . . . . . . . . . . . . . . 18
5.5. White Space Channel Update . . . . . . . . . . . . . . . . 20
5.6. Result Codes . . . . . . . . . . . . . . . . . . . . . . . 20
6. Message Encoding . . . . . . . . . . . . . . . . . . . . . . . 22
6.1. XML Schema Definition . . . . . . . . . . . . . . . . . . 22
6.2. HTTP Encoding . . . . . . . . . . . . . . . . . . . . . . 27
7. Security Considerations . . . . . . . . . . . . . . . . . . . 33
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36
10.1. Normative References . . . . . . . . . . . . . . . . . . . 36
10.2. Informative References . . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37
Wei, et al. Expires January 10, 2013 [Page 2]
Internet-Draft PAWS Framework July 2012
1. Introduction
"White Space" means the radio spectrum that has been allocated for
some primary use, but is not fully occupied by that primary use at a
specific location and time. Currently the white space in television
bands (which is called TV white space (TVWS)) is widely discussed;
TVWS has some good characteristics such as propagation
characteristics and low power consumption. The regulatory bodies in
some countries have created rules allowing secondary white space
access; the secondary user must ensure it does not interfere with the
primary user when using white space. The purpose of white space
study is to design a mechanism that enables the secondary user to use
the white space resource without interfering with the primary user.
The widely accepted scheme of utilizing white space is by querying a
database. This document defines a protocol over which such a
database may be queried, called the "Protocol to Access White Space
database (PAWS)". The use cases and requirements of PAWS have been
discussed in another document [2].
The master devices may be produced by different manufacturers and
there may be multiple databases serving a geographic area
administered by different administrators. To ensure interoperability
between these devices and databases, a standard interface needs to be
defined. This document defines that interface.
Spectrum management rules of different spectrum regulatory bodies are
different, so the white space spectrum databases may be designed to
implement different spectrum policies in different regulatory
domains. In order to satisfy the needs of these disparate regulatory
domains, the database query protocol MUST be independent of different
spectrum management rules. PAWS is a protocol between a master
device and a database that carries information about white space
spectrum from the database to a master device. The master device
could act as a WiFi AP or a cellular base station (e.g. 3GPP LTE
eNodeB) in the whitespace spectrum; the PAWS protocol is agnostic to
the technology used by the master device. A slave device is the
device which uses the spectrum made available by a master device.
After the master device has obtained information about white space
spectrum from the database and formed a wireless access network, the
slave device can access it.
In this document we introduce a framework for the PAWS protocol, a
protocol stack defining an interface between a master device and a
whitespace database, a set of messages and their associated
parameters, and an XML schema encoding the messages and parameters.
Co-existence of multiple whitespace devices in the same geographic
area and interference avoidance between white space devices within
the same spectrum are out of scope of the current protocol.
Wei, et al. Expires January 10, 2013 [Page 3]
Internet-Draft PAWS Framework July 2012
Provisioning and how databases store the white space information are
also out of scope of the protocol.
There is much sensitive information, such as location and identity,
which MAY be transmitted between the master device and the database
when PAWS is used. Attackers may attempt to obtain such information
during the operation of the protocol. Therefore, the messaging
interface between the master device and the database needs to be
secured. Meanwhile, the two entities SHALL be the authorized and
mutually authenticated. This document assumes that PAWS can be run
over an HTTPS connection, but details of how security credentials are
issued, managed, and validated among the various entities (databases,
master devices and slave devices) are out of scope of the basic
protocol and should be specified in a different document.
Given that multiple databases may serve a given region, and that a
master device may move from region to region, a mechanism to discover
the proper database to query must be provided in the master device.
This document provides an overview of possible mechanisms that can be
used for this purpose, but does not define any new protocols in this
area.
Wei, et al. Expires January 10, 2013 [Page 4]
Internet-Draft PAWS Framework July 2012
2. Terminology and Abbreviation
2.1. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
thisdocument are to be interpreted as described in [1].
2.2. Terminology
The Terminology Section of the latest version of the PAWS Problem
Statement and Use Cases draft [2] shall be included by reference.
WS Interface
The interface between master device and whitespace database,
including the data model and protocol messages defined in this
document.
RAT
Radio Access Technology.
Wei, et al. Expires January 10, 2013 [Page 5]
Internet-Draft PAWS Framework July 2012
3. Overview of PAWS
We first define the entities of Master Device and Database, and the
common interface between these two entities.
Figure 1 shows a common system model consisting of Master Device and
Database. The Master Device connects to the database directly using
the WS interface.
This document defines the data model and protocol messaging
procedures of the WS interface. The messages of WS are encoded in
XML, with security provided by HTTPS, and reliable in-order delivery
provided by TCP. More details about the protocol of WS see section
"protocol stack".
+-------+ +--------+
|Master | WS Interface | |
|Device +--------------+Database|
| | | |
+-------+ +--------+
Figure 1: System Model of PAWS
The master device in Figure 1 queries for a list of available
channels from the database so it can provide radio access for user
equipments. It can be a WiFi access point, a base station of 3GPP
WCDMA or 3GPP LTE, or some other RAT. The master device can send its
own information (such as device ID, geo-location etc.) to the
database to query white space spectrum for itself, or it can send the
information from other devices to the database to query white space
spectrum for other devices.
The database in Figure 1 is in charge of storing and maintaining
white space channel information for certain area(s). There may be
one or more databases providing white space information for a given
area. The main function of the database is to provide suitable white
space spectrum information to master devices. The databases are
assumed to be on the Internet and can be accessed by the master
devices via any Internet connection. When the database receives a
request for white space spectrum from the master device, it will
respond with a list of available white space channels to the master
device if there are available channels. How the database stores the
white space spectrum information and the policies for which white
space spectrum can be returned to a master device is outside the
scope of this document.
As shown in Figure 2 in order to provide wireless access based on
white space, there are several procedures involved. These include
Wei, et al. Expires January 10, 2013 [Page 6]
Internet-Draft PAWS Framework July 2012
database discovery, secure connection establishment, device
registration, and white space channel query.
+-----------------------------+
| Master device decide to use |
| white space to provide |
| wireless access |
+-----------------------------+
|
V
+--------------------+
| Database discovery |
+--------------------+
|
V
+-----------------------------+
| Master device decide which |
| database to connect to and |
| then establishes a security |
| connection with the database|
+-----------------------------+
|
V
+---------------------+
| Device registration |
+---------------------+
|
V
+---------------------------+
| White space channel query |
+---------------------------+
|
V
+------------------------------+
| Master device gets available |
| white space channel list and |
| provides wireless access |
+------------------------------+
Figure 2: The procedure for getting white space channel for master
device
When the master device is to provide radio access service, it is
required to execute the following steps:
1. Database discovery. When the master device needs to connect to
database, it must know the Internet address of the database and
it has to decide to which database to connect when there is more
Wei, et al. Expires January 10, 2013 [Page 7]
Internet-Draft PAWS Framework July 2012
than one database. A database discovery mechanism is needed.
There may be several mechanism for database discovery, for
example, DNS.
2. Registration. Registration is an optional procedure of PAWS. In
particular, requirements for registration come from individual
regulatory domains and can be different depending on the
regulator's individual requirements. When registration is used,
before the database provides information on available radio
channels, the master device MUST register with the trusted
database. In the registration procedure, the information may
include but is not limited to device ID, device owner's name,
device owner's email address, device owner's phone number etc.
3. White space channel query. The white space channel query
procedure from master device to database is based on a client-
server model. When a master device is to create a radio network
using white space, it queries available white space channel
information from the database by sending a query message and
receiving a response containing available whitespace channel(s).
4. White space channel update. The white space channel returned to
master device is available for a limited duration of time, which
means that when this time expires the channel can not be used by
the master device any more, and then the master device must
obtain updated white space channel information from the database.
There are also some requirements from regulatory bodies that the
white space channel information MUST be updated periodically.
The update mechanism is necessary and is needed to avoid
interfering with the primary user or other secondary user. A
mechanism to update the whitespace information is provided in
this draft.
Considering the security aspects, there is a trust relationship
between the database and master devices. There SHOULD be
corresponding authentication, integrity protection, and
confidentiality protection mechanisms between the master device.
Security considerations are given in Section 7; details of the
security procedure at the beginning of an HTTPS connection is not
included in this document.
Wei, et al. Expires January 10, 2013 [Page 8]
Internet-Draft PAWS Framework July 2012
4. Protocol Stack
The protocol specified here is an application protocol that depends
on a lower-layer transport protocol, which must provide the necessary
features and security properties for use as the building blocks for
communication between location-aware devices and white space
databases. The service model between master device and database is
client-server using request/response messages.
A protocol stack model is proposed here, shown in Figure 3. The
transport layer is TCP and the application runs over HTTPS.
+------------+ +------------+
| WS.App +-------------+ WS.App |
+------------+ +------------+
| HTTPS +-------------+ HTTPS |
+------------+ +------------+
| TCP +-------------+ TCP |
+------------+ +------------+
| IP +-------------+ IP |
+------------+ +------------+
Master Device Database
Figure 3: Protocol Stack of PAWS
WS.App is the white space spectrum application protocol. The
messages of WS are encoded in XML, packaged in HTTP requests and
responses, encrypted by TLS, and transported by TCP. The element
types used in the XML encoding of messages are defined in Section 6.
Wei, et al. Expires January 10, 2013 [Page 9]
Internet-Draft PAWS Framework July 2012
5. Protocol Framework and Interface of PAWS
The use of white space spectrum is enabled after a white space device
queries a database and obtains information about the availability of
spectrum for use at a given location. The databases are reachable
via the Internet and the devices querying these databases are
expected to have some form of Internet connectivity. There could be
multiple databases serving white space devices and a master device
can select one of them for use. The architecture is shown in
Figure 4.
-----------
|WS Device| ------------
|Lat: X |\ .---. /------|Database X|
|Long: Y | \ ( ) / ------------
----------- \----( )/ o
( )
( Internet ) o
( )
----------- /----(_ )\ o
|WS Device| / (___) \ ------------
|Lat: X |/ \------|Database Y|
|Long: Y | ------------
-----------
Figure 4: High Level View of the White Space Database Architecture
A messaging interface between the white space devices and the
database is required for operating a network using the white space
spectrum. The following sections discuss various aspects of such an
interface. Other aspects of a solution including provisioning the
database and calculating protected contours are considered out of
scope of this document.
In order to query white space channel(s) from a database, a master
device must provide its geo-location information to the database.
There are several different methods for a master device to get its
geo-location information; for example, using GPS technology, using
street number or building location information etc.
The protocol message interface defines the message contents and
message format of WS. The message interface should satisfy the
following requirements:
1. The message sent in the message interface should be independent
of the specific radio interface technologies (e.g. 802.11af, IEEE
802.16, IEEE 802.22, LTE);
Wei, et al. Expires January 10, 2013 [Page 10]
Internet-Draft PAWS Framework July 2012
2. The message interface should be spectrum agnostic. The message
interface should not only be used for TV white space but also be
used for other spectrum;
3. The message interface should satisfy different scenarios for
using white space. In different scenarios the white space
device's coverage area and the bandwidth may be different;
4. The message should address different regulations by different
regulatory bodies;
5. Security requirements, such as ciphering and integrity protection
must be met.
5.1. Database Discovery
Before the white space device can transmit in white space spectrum,
it MUST contact a trusted database where the device can learn if any
channels are available for it to use. In order to connect to the
trusted database the master device MUST get the IP address of the
database.
The master device MAY be pre-programmed with the Internet IP address
of trusted database manually. The master device can establish
contact with a trusted database using one of the pre-provisioned IP
addresses. We call this method "static database discovery".
Alternatively, the master device may discover the IP address of the
database dynamically through the use of a DNS query. It may be
configured with the DNS name of a database that is valid for its
current location or may discover the name of an appropriate database
through means outside the scope of this specification.
5.2. Device Registration with Trusted Database
A registration procedure is used to register the master device's
information in the database. Some databases may refuse to respond to
queries from unauthorized or uncertified devices. The registration
procedure is optional; master devices may not be required to
register, depending on the regulator's requirements. When
registration is used, before the database will provide information on
available radio channels, the master device must register with the
trusted database. In the registration procedure, the information may
include but is not limited to, device ID, device owner's name, device
owner's email address, device owner's phone number etc.
Specific events will initiate registration; these events are
determined by regulator policy, for examples:
Wei, et al. Expires January 10, 2013 [Page 11]
Internet-Draft PAWS Framework July 2012
1. The master device will operate in white space for the first time
after power up.
2. The location of master device changes by a predetermined
distance.
3. After a certain regular time interval.
4. When the registered information changed, and the master device
need update its registration information.
The device registration procedure consists of two messages:
1. Registration request message. This message is from master device
to database. The master device shall provide to the database
during registration all information required according to local
regulatory requirements.
2. Registration response message. This message is from database to
master device. The database responds to the registration request
with an acknowledgement code to indicate the success or failure
of the registration request. Additional information may be
provided according to local regulator requirements.
One of two possible results shall be returned by the database:
1. Successful Registration.
2. Failed Registration. The master device is not recognized or
authorized by the database.
A successful registration will overwrite any previous registration
information for the same master device, as identified by device ID
and manufacturer's serial number.
The device registration procedure is depicted in Figure 5.
REGISTRATION_REQ is the registration request message;
REGISTRATION_RESP is the registration response message.
Wei, et al. Expires January 10, 2013 [Page 12]
Internet-Draft PAWS Framework July 2012
+---------------+ +---------------+
| Master Device | | Database |
+---------------+ +---------------+
| |
| REGISTRATION_REQ |
|--------------------------------->|
| |
| |
| REGISTRATION_RESP |
|<---------------------------------|
| |
| |
Figure 5: Device Registration with Database Procedure
The registration procedure consists the following steps:
1. The master device sends registration request message to the
trusted database. In this message the parameters to be
registered are included.
2. The database sends the registration response message to the
master device indicating whether the registration is successful
or not, Additional information may be provided according to local
regulator requirements.
The parameters included in REGISTRATION_REQ are as follows:
+----------------+--------------------------------------------------+
| Parameter | Description |
+----------------+--------------------------------------------------+
| device id | Device id of master device. |
| | |
| device type | Device type defined by Regional Regulators, |
| | including fixed, mobile, portable, etc. |
| | |
| manufacturer's | The manufacturer's serial number of device. |
| serial number | |
| | |
| device owner's | Includes: name of the individual or business |
| information | that owns the device, name of a contact person |
| | responsible for the device's operation, address |
| | for the contact person, and email address for |
| | the contact person and phone number of the |
| | contact person. |
+----------------+--------------------------------------------------+
Table 1: Parameters of the REGISTRATION_REQ Message
Wei, et al. Expires January 10, 2013 [Page 13]
Internet-Draft PAWS Framework July 2012
The parameters included in the REGISTRATION_RESP are as follows:
+-----------+-------------------------------------------------------+
| Parameter | Description |
+-----------+-------------------------------------------------------+
| result | Consists of a code number with related description in |
| code | text which indicates whether the registration request |
| | is successful or failed; if it failed the result code |
| | will indicate the reason of failure. |
+-----------+-------------------------------------------------------+
Table 2: Parameters of the REGISTRATION_RESP Message
5.3. White Space Channel Query
When master device is to create a radio network using white space, it
queries for available white space channels from the database. The
master device sends a white space channel query message to the
database and fetches white space channel(s) from the database.
The channel query procedure consists of four messages:
1. Channel query request message. This message is from the master
device to the database. The channel query request message takes
parameters as required by local regulatory requirements to the
database; these parameters will be used by the database to decide
the available white space channel(s) for the master device;
2. Channel query response message. This message is from the
database to the master device. The channl query response message
takes parameters as required by local regulatory requirements to
the master device; the white space query result code of success
or fail will be included in this message. If there are available
white space channel(s) for the master device, the result code of
success will be returned to the master device and the
availability white space channel(s) with related information will
be returned to the master device; otherwise, if there is no
available white space channel for the master device, the result
code of failure with the failure reason will be returned to the
master device;
3. Channel usage report message. This message is from the master
device to the database. When the master device receives the
white space channel(s) returned from the database, it uses this
message to inform the database of the anticipated channel usage.
Because not all of the regulatory rules require the reporting
back of usage, some databases may not support this message, so it
is optional.
Wei, et al. Expires January 10, 2013 [Page 14]
Internet-Draft PAWS Framework July 2012
4. Channel usage acknowledge message. This message is from the
database to the master device. This message is an
acknowledgement of the channel usage report message. This
message will be sent only when the channel usage report message
is used.
The white space channel query procedure is depicted in Figure 6.
AVAIL_WS_REQ is the available white space query request message;
AVAIL_WS_RESP is the available white space query response message;
CHANNEL_USAGE_REPORT is the channel usage report message;
CHANNEL_USAGE_ACK is the channel usage acknowledge message.
+---------------+ +---------------+
| Master Device | | Database |
+---------------+ +---------------+
| |
| AVAIL_WS_REQ |
|--------------------------------->|
| |
| |
| AVAIL_WS_RESP |
|<---------------------------------|
| |
| |
| CHANNEL_USAGE_REPORT |
|--------------------------------->|
| |
| |
| CHANNEL_USAGE_ACK |
|<---------------------------------|
| |
| |
Figure 6: The Available Channel Query Procedure
The query procedure using the following steps:
1. The master device sends the white space query request message to
database and waits a limited period of time for white space query
response message from the database. When the time expires and no
query response message is returned from the database, the query
procedure will be failed.
2. On receiving the white space query request message, database will
find out the available white space channels and send the
available white space channel list to the white space device.
The result code in the query response message (AVAIL_WS_RESP
message) will indicate whether the channel usage report message
Wei, et al. Expires January 10, 2013 [Page 15]
Internet-Draft PAWS Framework July 2012
is needed to be sent.
3. If the channel usage message is needed, the master device will
send the channel usage message to the database after receiving
the query response message. If there is no available channel or
no acceptable response is received within the limited time, the
master device concludes that no channel is available.
4. When the database receives channel usage report message, it will
acknowledge the master device of receiving the message by channel
usage acknowledge message.
The parameters included in AVAIL_WS_REQ are as follows:
+-----------------+-------------------------------------------------+
| Parameter | Description |
+-----------------+-------------------------------------------------+
| device id | Device id of master device that sends the query |
| | message. |
| | |
| device type | Device type defined by Regional Regulators, |
| | including fixed, mobile, portable, etc. |
| | |
| List of | A list of coverage area(s) where white space |
| coverage | access service will be provided. This field |
| area(s) | includes: geo-location (latitude, longitude) of |
| information | the master device, uncertainty of geo-location |
| | (in meters), and confidence (in percentage) for |
| | the location determination, coverage range. |
| | |
| antenna | Antenna characteristics of the master device |
| characteristics | that will use the white space. This field |
| | includes: antenna height above the ground, |
| | antenna direction, antenna radiation pattern, |
| | antenna gain, maximum output power, spectrum |
| | mask. |
| | |
| RAT type | Specifies information about the type of RAT of |
| | the master device. |
| | |
| bandwidth | Bandwidth that the master device needs to form |
| | the wirelss network. |
+-----------------+-------------------------------------------------+
Table 3: Parameters of the AVAIL_WS_REQ Message
The parameters included in AVAIL_WS_RESP are as follows:
Wei, et al. Expires January 10, 2013 [Page 16]
Internet-Draft PAWS Framework July 2012
+-----------+-------------------------------------------------------+
| Parameter | Description |
+-----------+-------------------------------------------------------+
| device id | Device id of master device, the value of this field |
| | is the same as the device id in AVAIL_WS_REQ message. |
| | |
| device | Device type defined by Regional Regulators, including |
| type | fixed, mobile, portable, etc. The value of this |
| | field is the same as the device type in AVAIL_WS_REQ |
| | message. |
| | |
| result | Consists of a code number with related description in |
| code | text which indicates whether the available white |
| | space request is successful or failed; if it has |
| | failed the result code will indicate the reason of |
| | failure. |
| | |
| white | This field includes: frequency information, available |
| space | bandwidth, available time duration, coverage area, |
| channel | maximum transmission power. |
| list | |
+-----------+-------------------------------------------------------+
Table 4: Parameters of the AVAIL_WS_RESP Message
The parameters included in CHANNEL_USAGE_REPORT are as follows:
+------------+------------------------------------------------------+
| Parameter | Description |
+------------+------------------------------------------------------+
| device id | Device id of master device that sends the query |
| | message. |
| | |
| white | This field includes: frequency information, |
| space | available bandwidth, available time duration, |
| channel | coverage area, maximum transmission power. |
| list | |
+------------+------------------------------------------------------+
Table 5: Parameters of the CHANNEL_USAGE_REPORT Message
The parameters included in CHANNEL_USAGE_ACK are as follows:
Wei, et al. Expires January 10, 2013 [Page 17]
Internet-Draft PAWS Framework July 2012
+-----------+-------------------------------------------------------+
| Parameter | Description |
+-----------+-------------------------------------------------------+
| result | Consists of a code number with related description in |
| code | text which indicates whether the CHANNEL_USAGE_REPORT |
| | message is received by the database. |
+-----------+-------------------------------------------------------+
Table 6: Parameters of the CHANNEL_USAGE_ACK Message
5.4. Validation Procedure
The validation procedure is used for the database to validate the
slave device. When the slave device connects to the master device,
the master device MAY start the validation procedure to validate the
slave device.
The validation procedure consists of two messages:
1. Validation request message. This message is from master device
to database. After the slave device connects to the master
device, the master device can send the slave's validation
information such as slave device ID, slave device's manufacturer
serial number etc to the database in validation request message.
2. Validation response message. This message is from the database
to the master device. This message is used to indicate if the
slave device is validated by the database.
The validation procedure is depicted in Figure 7. VALIDATION_REQ is
the validation request message; VALIDATION_RESP is the validation
response message.
+---------------+ +---------------+
| Master Device | | Database |
+---------------+ +---------------+
| |
| VALIDATION_REQ |
|--------------------------------->|
| |
| |
| VALIDATION_RESP |
|<---------------------------------|
| |
| |
Figure 7: Slave Device Validation with Database Procedure
Wei, et al. Expires January 10, 2013 [Page 18]
Internet-Draft PAWS Framework July 2012
The validation procedure using the following steps:
1. After the slave device has connected to the master device and
sent its slave device id and slave device type to the master
device, the master device will send slave device id included in
VALIDATION_REQ message to the database.
2. The database validates the slave device and returns the result
code to the master device. The result code indicates whether the
slave device is validated or not, and if the slave device is not
validated the result code will indicate the reason of not
validated.
3. If the the slave device is validated by the database, the white
space device will provide service to the slave device, otherwise
the master device will deny the slave device's access.
The parameters included in VALIDATION_REQ are as follows:
+----------------+--------------------------------------------------+
| Parameter | Description |
+----------------+--------------------------------------------------+
| device id | Slave device id. |
| | |
| device type | Slave's device type defined by Regional |
| | Regulators, including fixed, mobile, portable, |
| | etc. |
| | |
| device owner's | Identification of the individual or business |
| information | that owns the device. |
+----------------+--------------------------------------------------+
Table 7: Parameters of the VALIDATION_REQ Message
The parameters included in VALIDATION_RESP are as follows:
+-----------+-------------------------------------------------------+
| Parameter | Description |
+-----------+-------------------------------------------------------+
| result | Consists of a code number with related description in |
| code | text which indicates whether thelave device is |
| | validated or not; if it's failed the result code will |
| | indicate the reason for failure. |
+-----------+-------------------------------------------------------+
Table 8: Parameters of the VALIDATION_RESP Message
Wei, et al. Expires January 10, 2013 [Page 19]
Internet-Draft PAWS Framework July 2012
5.5. White Space Channel Update
The availability of a white space channel may be changed, because a
primary user may obtain the channel.
In order to avoid interfering with the primary user or other
secondary user, the white space updating mechanism is provided in
this document.
The white space channel update procedure is used for master device to
update the white space channel from the database. The update
procedure SHOULD be implemented when one of the followings occurs:
1. Periodically implemented as required by the regulation to verify
that the operating channels continue to remain available.
2. When master device changes its location more than a threshold
distance.
The white space device MUST access the database to obtain and update
the list of available channels that could be utilized by the device
to verify that the operating channels continue to remain available.
According to some regulatory rules the white space device SHOULD
update the white space channel periodically, and the period may be
different due to different regulatory rules.
The white space channel update mechanism is based on the white space
channel query procedure. After the master device gets a white space
channel from the database, a white space channel update timer is set
to a certain value, which is determined by local regulatory body,
when the timer expires the master device will start white space
channel query procedure to query white space channels from the
database.
When the master device changes its location more than a threshold
distance it SHOULD query the database for available operating
channels, the value of threshold is specified by local regulatory
policy.
5.6. Result Codes
The following result codes are provided by the database on responses
to the master device to communicate the status of requests made by
the master device; all of the result codes used in this document is
defined here.
Wei, et al. Expires January 10, 2013 [Page 20]
Internet-Draft PAWS Framework July 2012
+------+--------------------------------+---------------------------+
| Code | Description | Returned Text |
+------+--------------------------------+---------------------------+
| 0 | successful | "successful" |
| | | |
| 1 | successful with no channel | "no channel available" |
| | available | |
| | | |
| 2 | Successful and | "CHANNEL_USAGE_REPORT |
| | CHANNEL_USAGE_REPORT message | message needs to be sent" |
| | needs to be sent. | |
| | | |
| 3 | Successful and | "CHANNEL_USAGE_REPORT |
| | CHANNEL_USAGE_REPORT message | message needs not to be |
| | needs not to be sent. | sent" |
| | | |
| 4 | device id is invalid | "device id is invalid" |
| | | |
| 5 | device type is invalid | "device type is invalid" |
| | | |
| 6 | device type is not supported | "device type is not |
| | | supported" |
| | | |
| 7 | Device has not registered | "Device has not |
| | | registered" |
+------+--------------------------------+---------------------------+
Table 9: Result Codes
Wei, et al. Expires January 10, 2013 [Page 21]
Internet-Draft PAWS Framework July 2012
6. Message Encoding
6.1. XML Schema Definition
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xlmns:xs="http://tools.ietf.org/wg/paws/"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<!-- Definition of element Types-->
<!--definition of the element type of protocol version-->
<xs:simpleType name="versionType">
<xs:restriction base="xs:byte"/>
</xs:simpleType>
<!--definition of the element type of device's ID-->
<xs:simpleType name="deviceIDType">
<xs:restriction base="xs:string">
<xs:length value="20"/>
</xs:restriction>
</xs:simpleType>
<!--definition of the element type of device -->
<xs:simpleType name="deviceType">
<xs:restriction base="xs:integer"/>
</xs:simpleType>
<!--definition of the element type of manufacture series number-->
<xs:simpleType name="manufactureSeqNumType">
<xs:restriction base="xs:string"/>
<xs:length value="32"/>
</xs:restriction>
</xs:simpleType>
<!definition of the element type of WS device information-->
<xs:complexType name="deviceOwnerInfoType">
<xs:sequence>
<xs:element name="nameOfOwner" type="xs:string"/>
<xs:element name="nameOfOperator" type="xs:string"/>
<xs:element name="addressOfOperator" type="xs:string"/>
<xs:element name="phoneNumberOfOperator"
type="xs:string"/>
</xs:sequence>
</xs:complexType>
<!--definition of element type of geo-location-->
<xs:complexType name="geoLocationType">
Wei, et al. Expires January 10, 2013 [Page 22]
Internet-Draft PAWS Framework July 2012
<xs:sequence>
<xs:element name="latitude" type="xs:string"/>
<xs:element name="longitude" type="xs:string"/>
</xs:sequence>
</xs:complexType>
<!--definition of element type of coverage range-->
<xs:simpleType name="coverageRangeType">
<xs:restriction base="xs:float">
<xs:minInclusive value="0"/>
</xs:restriction>
</xs:simpleType>
<!--definition of element type of coverage area-->
<xs:complexType name="coverageAreaType">
<xs:sequence>
<xs:element name="geoLocation" type="geolocationType"/>
<xs:element name="uncertaintyOfGeoLocation" type="xs:float"/>
<xs:element name="confidence" type="xs:float"/>
<xs:element name="coverageRange" type="coverageRange"/>
</xs:sequence>
</xs:complexType>
<!--definition of element type of list of coverage area-->
<xs:complexType name="coverageAreaListType">
<xs:sequence minOccurs="0" maxOccurs="unbounded">
<xs:element name="coverageArea"
type="coverageAreaType"/>
</xs:sequence>
</xs:complexType>
<!--definition of element type of result code-->
<xs:complexType name="resultType">
<xs:sequence>
<xs:element name="code" type="xs:byte"/>
<xs:element name="discription" type="xs:string"/>
</xs:sequence>
</xs:simpleType>
<!--definition of element type of antenna characteristics
Unit:
antenna gain db
antenna height m
antenna direction rad
maximum output power dbm
-->
<xs:complexType name="antennaCharacterType">
Wei, et al. Expires January 10, 2013 [Page 23]
Internet-Draft PAWS Framework July 2012
<xs:sequence>
<xs:element name="antennaHeight" type="xs:float"/>
<xs:element name="antennaGain" type="xs:float"/>
<xs:element name="antennaDirection" type="xs:float"/>
<xs:element name="maxOutputPower" type="xs:float"/>
</xs:sequence>
</xs:complexType>
<!--definition of element type of bandwidth
uint:
bandwidth kHz
-->
<xs:simpleType name="bandwidthType">
<xs:restriction base="xs:float"/>
</xs:simpleType>
<!--definition of element type of white space channel
unit:
frequency kHz
-->
<xs:complexType name="channelType">
<xs:sequence>
<xs:element name="frequency" type="xs:float"/>
<xs:element name="bandwidth" type="bandwidthType"/>
</xs:sequence>
</xs:complexType>
<!--definition of element type of RAT-->
<xs:simpleType name="RATType">
<element name="rat" type="xs:string"/>
</xs:simpleType>
<!--definition of element type of available duration time
of channel-->
<xs:complexType name="timeDurationType">
<xs:restriction base="xs:dateTime">
<xs:element name="beginTime"
type="timeDurationType"/>
<xs:element name="endTime"
type="timeDurationType"/>
</xs:restriction>
</xs:simpelType>
<!--definition of element type of maximum transmit power
unit:
Wei, et al. Expires January 10, 2013 [Page 24]
Internet-Draft PAWS Framework July 2012
maximum transmit power dbm
-->
<xs:simpleType name="maxTransmitPowerType">
<xs:restriction base="xs:float"/>
</xs:simpleType>
<!--definition of element type of list of channel-->
<xs:complexType name="channelListType">
<xs:sequence minOccurs="0" maxOccurs="unbounded">
<xs:element name="channel" type="channelType"/>
<xs:element name="timeDuration" type="timeDurationType"/>
<xs:element name="maxTransmitPowerType"/>
<xs:element name="coverageArea" type="coverageAreaType"/>
</xs:sequence>
</xs:complexType>
<!-- Definition Of Messages-->
<!--definition of registration request message-->
<xs:element name="REGISTRATION_REQ_MSG">
<xs:complexType>
<xs:sequence>
<xs:element name="version" type="versionType"/>
<xs:element name="deviceID" type="deviceIDType"/>
<xs:element name="device" type="deviceType"/>
<xs:element name="manufactureSeqNum" type="manufactureSeqNumType"/>
<xs:element name="deviceOwnerInfo" type="deviceOwnerInfoType"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<!--definition of registration response message-->
<xs:element name="REGISTRATION_RESP_MSG">
<xs:complexType>
<xs:sequence>
<xs:element name="version" type="versionType"/>
<xs:element name="result" type="resultType"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<!--definition of availabel ws query request message-->
<xs:element name="AVAIL_WS_REQ_MSG">
<xs:complexType>
<xs:sequence>
<xs:element name="version" type="versionType"/>
Wei, et al. Expires January 10, 2013 [Page 25]
Internet-Draft PAWS Framework July 2012
<xs:element name="device" type="deviceType"/>
<xs:element name="deviceID" type="deviceIDType"/>
<xs:element name="coverageAreaList" type="coverageAreaListType"/>
<xs:element name="antennaCharacter" type="antennaCharacterType"/>
<xs:element name= "rat" type="RATType"/ >
<xs:element name="bandwidth" type="bandwidthType"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<!--definition of availabel ws query response message-->
<xs:element name="AVAIL_WS_RESP_MSG">
<xs:complexType>
<xs:sequence>
<xs:element name="version" type="versionType"/>
<xs:element name="deviceID" type="deviceIDType"/>
<xs:element name="device" type="deviceType"/>
<xs:element name="result" type="resultType"/>
<xs:element name="channelList" type="channleListType"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
<!--definition of channel usage report message-->
<xs:element name=" CHANNEL_USAGE_REPORT ">
<xs:complexType>
<xs:sequence>
<xs:element name="version" type="versionType"/>
<xs:element name="deviceID" type="deviceIDType"/>
<xs:element name="channelList" type="channleListType"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
<!--definition of channel usage report acknowledge message-->
<xs:element name=" CHANNEL_USAGE_ACK ">
<xs:complexType>
<xs:sequence>
<xs:element name="version" type="versionType"/>
<xs:element name="result" type="resultType"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
<!--definition of validation request message-->
<xs:element name=" VALIDATION_REQ">
Wei, et al. Expires January 10, 2013 [Page 26]
Internet-Draft PAWS Framework July 2012
<xs:complexType>
<xs:sequence>
<xs:element name="version" type="versionType"/>
<xs:element name="deviceID" type="deviceIDType"/>
<xs:element name="device" type="deviceType"/>
<xs:element name="deviceOwnerInfo" type="deviceOwnerInfoType"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<!--definition of validation response message-->
<xs:element name=" VALIDATION_RESP ">
<xs:complexType>
<xs:sequence>
<xs:element name="version" type="versionType"/>
<xs:element name="result" type="resultType"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
6.2. HTTP Encoding
This section will describe how to encode the PAWS protocol message of
XML format in HTTP protocol. The PAWS protocol messages of XML
format are carried as an entity of HTTP message.
Here are some examples of how to encode PAWS messages of XML format
in HTTP protocol.
1. Registration Request message.
PUT {URL} HTTP/1.1
Accept: */*
Proxy-Connection: Keep-Alive
Host: {host name}
Content-Type: text/xml
<?xml version="1.0" encoding="UTF-8"?>
< REGISTRATION_REQ_MSG xmlns="http://tools.ietf.org/wg/paws/">
< version>{_version}</version>
< deviceID >{_deviceID}</deviceID>
< device >{_ device }</ device >
< manufactureSeqNum >{_ manufactureSeqNum }</ manufactureSeqNum >
< deviceOwnerInfo >{_ deviceOwnerInfo }</ deviceOwnerInfo >
</ REGISTRATION_REQ_MSG >
Wei, et al. Expires January 10, 2013 [Page 27]
Internet-Draft PAWS Framework July 2012
where
{URL} is the URL of the database.
{host name} is the host name of the database.
{_version}, {_deviceID}, {_device}, {_manufactureSeqNum },
{_antennaCharacter }, {_deviceOwnerInfo } are the elements
defined in the XML schema.
2. Registration Response message.
HTTP/1.1 200 OK
Cache-Control: private
Content-Length: {LENGTH}
Content-Type: application/xml; charset=utf-8\r\n
<?xml version="1.0" encoding="UTF-8"?>
< REGISTRATION_RESP_MSG xmlns="http://tools.ietf.org/wg/paws/">
<version>{_version}</version>
< result >{_result}</ result >
</ REGISTRATION_RESP_MSG >
REGISTRATION_RESP_MSG
where
{LENGTH} is the length of the XML body.
{_version}, {_result} are the elements defined in the XML
schema.
3. Available white space channel query request message.
Wei, et al. Expires January 10, 2013 [Page 28]
Internet-Draft PAWS Framework July 2012
GET {URL} HTTP/1.1
Accept: */*
Proxy-Connection: Keep-Alive
Host: {host name}
Content-Type: text/xml
<?xml version="1.0" encoding="UTF-8"?>
< AVAIL_WS_REQ_MSG xmlns="http://tools.ietf.org/wg/paws/">
<version>{_version}</version>
< deviceID >{_deviceID}</deviceID>
< device >{_ device }</ device >
< coverageAreaList >{_ coverageAreaList }</ coverageAreaList >
< antennaCharacter >{_ antennaCharacter }</ antennaCharacter >
<rat>{_rat}</rat>
< bandwidth >{_ bandwidth }</ bandwidth >
</ AVAIL_WS_REQ_MSG >
where
{URL} is the URL of the database.
{host name} is the host name of the database.
{_version}, {_deviceID}, {_device}, {_coverageAreaList },
{_antennaCharacter }, {_rat}, {_bandwidth } are the elements
defined in the XML schema.
4. Available white space channel query response message.
HTTP/1.1 200 OK
Cache-Control: private
Content-Length: {LENGTH}
Content-Type: application/xml; charset=utf-8\r\n
<?xml version="1.0" encoding="UTF-8"?>
< AVAIL_WS_RESP_MSG xmlns="http://tools.ietf.org/wg/paws/">
<version>{_version}</version>
< deviceID >{_deviceID}</deviceID>
< device >{_device }</ device >
< result >{_result }</ result >
< channelList>{_channelList}</ channelList>
</ AVAIL_WS_RESP_MSG >
where
Wei, et al. Expires January 10, 2013 [Page 29]
Internet-Draft PAWS Framework July 2012
{LENGTH} is the length of the XML body.
{_version}, {_deviceID}, {_device }, {_result} are the
elements defined in the XML schema.
5. Channel usage report message.
PUT {URL} HTTP/1.1
Accept: */*
Proxy-Connection: Keep-Alive
Host: {host name}
Content-Type: text/xml
<?xml version="1.0" encoding="UTF-8"?>
< CHANNEL_USAGE_REPORT xmlns="http://tools.ietf.org/wg/paws/">
<version>{_version}</version>
< deviceID >{_deviceID}</deviceID>
< channelList>{_ channelList}</ channelList>
</ CHANNEL_USAGE_REPORT >
where
{URL} is the URL of the database.
{host name} is the host name of the database.
{_version}, {_deviceID}, {_channelList} are the elements
defined in the XML schema.
6. Channel usage report acknowledge message.
HTTP/1.1 200 OK
Cache-Control: private
Content-Length: {LENGTH}
Content-Type: application/xml; charset=utf-8\r\n
<?xml version="1.0" encoding="UTF-8"?>
< CHANNEL_USAGE_ACK xmlns="http://tools.ietf.org/wg/paws/">
<version>{_version}</version>
< result >{_ result }</ result >
</ CHANNEL_USAGE_ACK >
where
{LENGTH} is the length of the XML body.
Wei, et al. Expires January 10, 2013 [Page 30]
Internet-Draft PAWS Framework July 2012
{_version}, {_ result} are the elements defined in the XML
schema.
7. Validation request message.
PUT {URL} HTTP/1.1
Accept: */*
Proxy-Connection: Keep-Alive
Host: {host name}
Content-Type: text/xml
<?xml version="1.0" encoding="UTF-8"?>
< VALIDATION_REQ xmlns="http://tools.ietf.org/wg/paws/">
<version>{_version}</version>
< deviceID >{_deviceID}</deviceID>
<device>{_ device }</ device >
< deviceOwnerInfo >{_ deviceOwnerInfo }</ deviceOwnerInfo >
</ VALIDATION_REQ >
where
{URL} is the URL of the database.
{host name} is the host name of the database.
{_version}, {_deviceID}, {_ device }, {_ deviceOwnerInfo }are
the elements defined in the XML schema.
8. Validation response message.
HTTP/1.1 200 OK
Cache-Control: private
Content-Length: {LENGTH}
Content-Type: application/xml; charset=utf-8\r\n
<?xml version="1.0" encoding="UTF-8"?>
< VALIDATION_RESP xmlns="http://tools.ietf.org/wg/paws/">
<version>{_version}</version>
< result >{_ result }</ result >
</ VALIDATION_RESP >
where
{LENGTH} is the length of the XML body.
Wei, et al. Expires January 10, 2013 [Page 31]
Internet-Draft PAWS Framework July 2012
{_version}, {_ result} are the elements defined in the XML
schema.
Wei, et al. Expires January 10, 2013 [Page 32]
Internet-Draft PAWS Framework July 2012
7. Security Considerations
There is much sensitive information, such as location and identity,
which may be transmitted between the master device and the database
when PAWS is used. According to the security requirements given in
the problem statement draft [2] attackers may have full access to the
network medium between the master device and the white space database
and many types of attack may be carried out by the attackers if there
is a lack of security in PAWS. Therefore, to guarantee the security
considerations of the communication between the master device and the
white space database, the following security features should be
considered:
1. The identity of the master device and the white space database
must be authenticated, namely the mutual authentication must be
implemented and an authorization check shall be carried out by
both of them.
2. The connection between the master device and white space database
must be private; that means the messages transmitted on the
connection between the master device and the white space database
are confidentiality protected.
3. The connection between the master device and white space database
is reliable; that means that the message transport must support
including a message integrity check.
4. The negotiation of a shared key is secure: the negotiated secrets
which are used for confidentiality protection and Integrity
protection are unrevealed to eavesdroppers.
5. The negotiation is confidential: attacker must be not able to
modify the content of negotiation process without being detected
by the endpoints during the communication.
The security threats, security features and security countermeasures
associated with the use of white space spectrum by secondary usages
via PAWS are not discussed in details in this document.
Wei, et al. Expires January 10, 2013 [Page 33]
Internet-Draft PAWS Framework July 2012
8. IANA Considerations
There have been no IANA considerations so far in this document.
Wei, et al. Expires January 10, 2013 [Page 34]
Internet-Draft PAWS Framework July 2012
9. Acknowledgements
Thanks to my colleagues for their sincerely help and comments when
drafting this document.
Wei, et al. Expires January 10, 2013 [Page 35]
Internet-Draft PAWS Framework July 2012
10. References
10.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
10.2. Informative References
[2] Probasco, S. and B. Patil, "Protocol to Access White Space
database: PS, use cases and rqmts",
draft-ietf-paws-problem-stmt-usecases-rqmts-06 (work in
progress), July 2012.
Wei, et al. Expires January 10, 2013 [Page 36]
Internet-Draft PAWS Framework July 2012
Authors' Addresses
Xinpeng Wei
Huawei
Phone: +86 13436822355
Email: weixinpeng@huawei.com
Zhu Lei
Huawei
Phone: +86 13910157020
Email: lei.zhu@huawei.com
Peter J. McCann
Huawei
400 Crossing Blvd, 2nd Floor
Bridgewater, NJ 08807
USA
Phone: +1 908 541 3563
Email: peter.mccann@huawei.com
Wei, et al. Expires January 10, 2013 [Page 37]
