Internet DRAFT - draft-lei-paws-framework-datamodel
draft-lei-paws-framework-datamodel
PAWS Lei. Zhu
Internet-Draft Huawei Technologies
Intended status: Informational March 5, 2012
Expires: September 6, 2012
Protocol to Access White Space database: PAWS framework data model
draft-lei-paws-framework-datamodel-00.txt
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". In this document the framework
of PAWS is introduced, which includes framework of PAWS, protocol
stack, definition of interface, parameters and schema running over
interface, and security considerations. The realization of 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 September 6, 2012.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Zhu Expires September 6, 2012 [Page 1]
Internet-Draft PAWS framework data model March 2012
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.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Abbreviation . . . . . . . . . . . . . . . . . 4
2.1. Conventions Used in This Document . . . . . . . . . . . . 4
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
3. Framework of PAWS . . . . . . . . . . . . . . . . . . . . . . 4
4. Protocol Stack . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Protocl framework and interface of PAWS . . . . . . . . . . . 9
5.1. Database Discovery . . . . . . . . . . . . . . . . . . . . 9
5.2. Device Registration with Trusted Database . . . . . . . . 12
5.3. White Space Channel Query . . . . . . . . . . . . . . . . 15
5.4. White Space Channel Update . . . . . . . . . . . . . . . . 18
6. Message Encoding . . . . . . . . . . . . . . . . . . . . . . . 20
7. Security Considerations . . . . . . . . . . . . . . . . . . . 33
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33
10. Normative Reference . . . . . . . . . . . . . . . . . . . . . 33
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 33
Zhu Expires September 6, 2012 [Page 2]
Internet-Draft PAWS framework data model March 2012
1. Introduction
"White Space" means the 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. Currently the white space in TV bands
which is called TV white space (TVWS) is widely discussed, TVWS has
some good characteristics such as propagation ability and low power
consumption. The regulatory bodies in some countries have carried
out the rules allowing secondary white space access, the secondary
user must make sure of not interfering with the primary user when
using white space. The purpose of white space study is to design a
mechanism that the secondary user can use the white space resource
without interfering with the primary user. The widely accepted
scheme of utilizing white space is by querying the database and the
related protocol "Protocol to Access White Space database (PAWS)" is
proposed, the use cases and requirements of PAWS have been discussed
in document "draft-ietf-paws-problem-stmt-usecases-rqmts".
Spectrum management rules of different spectrum regulatory bodies are
different, so the white space spectrum database may be designed to
implement different spectrum policies in different countries. In
order to satisfy the need of globally applicable feature, the
database query protocol MUST be independent of different spectrum
management rules. PAWS is a protocol between the Master device and
the Database. The Master device could act as a WiFi AP, 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.
In this document the framework of PAWS is introduced, which includes
framework of PAWS, protocol stack, definition of interface,
parameters and schema running over interface, and security
considerations.
Based on the possible implementations, the common framework
fulfilling requirements and major scenarios is introduced with some
kind of extensible designs. White space Database (WSDB) is entity
operated by government regulatory body which dominates wireless
spectrum resource of a large country with different areas which owns
sub branches of spectrum management authorizations. Responsibility
for a WSDB for a large area with also quite number of population is a
burden and likely devided into sub Database of branch spectrum
management authorizations. This scenario obviously impacts on
Database discovery process and some minor implantations of framework
of PAWS. This document is to satisfy this situation with minimum
influence.
Zhu Expires September 6, 2012 [Page 3]
Internet-Draft PAWS framework data model March 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 this
document are to be interpreted as described in [RFC2119].
2.2. Terminology
The Terminology Section of the latest version of [I-D.ietf-paws-
problem-stmt-usecases-rqmts] shall be included by reference.
Coordinating Database
Coordinating Database is an entity implemented between Master Device
and Database in framework, having function to retrieve available
channel list from Database on behaviors of Master device (fulfilled
by function of white space device) and can response proper available
channel list when receiving query request from Master Device. The
concepts in PAWS framework is described in section 3.
WS interface
The interface between white space device and Database specifies data
model and process of PAWS in this document.
AddrDatabase
A kind of database that provides the Internet addresses of regulatory
authorized Database in the relevant regulatory domain to the white
space device, the AddrDatabase is provisioned to Master device and
used in the Database discovery procedure. The AddrDatabase is either
hosted by or under control of the national regulator.
3. Framework of PAWS
The first stage of PAWS would have defined entities of Master Device
and Database, and common interface between these two entities. In
this section, author(s) specified an extendable framework of PAWS
which would support fulfill early stage protocol perspective purpose
and be extensible to satisfy more requirement if it is utilized in
further stages.
Figure 1 shows a common system model consisting of Master Device and
Database merely. The Master Device connects to the database directly
using WS interface.
Zhu Expires September 6, 2012 [Page 4]
Internet-Draft PAWS framework data model March 2012
WS interface is the interface between white space device and database
which specifies data model and process of PAWS in this document. The
messages of WS are encoded in XML, considering of transportation
reliable and security the TCP and HTTPS are used to load the message.
More details about the protocol of WS see section "protocol stack".
+-------+ +--------+
|Master +-------------+Database|
|Device | +--------+
+-------+
Figure 1: Frame of PAWS
Master device in Figure 1 is a kind of white space device which
querying available channel list from database providing radio access
to user equipments. Due to PAWS principle of access technology
agnostic, it can be access point of WiFi, NodeB of 3GPP WCDMA or
eNodeB of 3GPP LTE etc.
Database in Figure 1 is in charge of storing and maintaining white
space channel information for certain area(s), it may be operated by
regulatory. When the database receives request of white space
spectrum querying from the master device, it will respond a list of
available white space channel list to the master device if there are
available spectrums.
The master device can connect to the database by any means other than
using the white space radio.
There is an optional system model can be implemented based on common
PAWS framework, shown in Figure 2, an entity named Coordinating
Database is implemented between master device and database.
Coordinating Database is logical function which is a combination of
master device and Database (which stores a part or all of the white
space spectrum information in certain area), the Coordinating
Database gets white space spectrum from database acting as Master
Device, the logical function of Coordinating Database is depicted in
Figure 3.
Master device can get white space from the Coordinating Database just
like getting white space from database; the Coordinating Database can
be maintained and operated by organizations and / or regulatory body
(e.g. FCC).
Zhu Expires September 6, 2012 [Page 5]
Internet-Draft PAWS framework data model March 2012
+-------------+
+-------------+ |Coordinating | +-----------+
|Master Device+--+----+Database +----+---+Database |
+-------------+ WS +-------------+ WS +-----------+
Figure 2: Alternative implementation framework of PAWS
The concept of database in this document is the same as the one in
"I-D.ietf-paws-problem-stmt-usecases-rqmts", which contains current
information about available spectrum at any given location and other
types of information.
Database is in charge of storing and providing white space channels
of a large area, for example there are only several databases
operated by different operators in America. Here the coordinating
database is defined to provide white space channels information for a
relatively smaller area (e.g. a state, a region or even campus and a
building which contains a huge number users).
The coordinating database can get white space channels from database,
receive the white space querying message from master device and
provide the available white space channels for master devices with
some degree decision making process. These decision making process
might provide functionality of white space access protocol power to
response available channels according to received device parameters
(e.g. power, RF parameter), location information(e.g. altitude,
position and direction of antenna ) and some particular white space
spectrum decision making policies.
The coordinating database gets available white space channel list
from WS database acting as master device and provides white space
channels to the master device that connects to it. Master device can
get white space from the Coordinating Database just like getting
white space from database. When provides white space channels to the
master device, the coordinating database may be used to implements
private spectrum using policies.
The coordinating database can updates white space channels from
database.
The function diagram of coordinating database is shown in Figure 3.
Coordinating database includes three main functions:
(1) The function of master device. It can retrieve available channel
list from Database on behaviors of master device (fulfilled by
function of white space device).
Zhu Expires September 6, 2012 [Page 6]
Internet-Draft PAWS framework data model March 2012
(2) The function of database. To master device the coordinating
database acts just like a database, it can receive the registration
information from master device, response with proper available
channel list when receiving query request from master device etc.
(3) The function of implementing spectrum management policies. For
example, the white space coordination control between different
master devices.
Some deployment scenarios based on coordinating database are
introduced below:
(1) In a private network, master devices are deployed to provide
wireless access, but the master device cannot connect to Internet
directly, the Coordinating database run by private network's manager
can be added between Master devices and WS database, so the master
devices can get white space channels from coordinating database.
(2) A private network or ISP which serves a lot of master devices and
it establishes wireless network using these master device, it can set
a Coordinating database which gets white space in its area from WS
database and all of its master devices query available white space
channels from the Coordinating database, because private network
owner who dominates the Coordinating database so it can implement its
policy of spectrum utilizing. It makes the implementation of private
white space utilizing policy possible.
+-----------------------------------------------------------+
| |
| |
| +--------------------+ +-------------------------+ |
| |Function of database| |Function of master device| |
| +--------------------+ +-------------------------+ |
| |
| +-------------------------+ |
| |Function of implementing | |
| |spectrum management | |
| |policy | |
| | | |
| +-------------------------+ |
| |
| |
| Coordinating Database |
| |
+-----------------------------------------------------------+
Figure 3: Logical Function of Coordinating Database
Zhu Expires September 6, 2012 [Page 7]
Internet-Draft PAWS framework data model March 2012
By adding the Coordinating database the burden of database will be
reduced, when the master device is connected to Coordinating
database, it will query available white space channels from
Coordinating database instead of WS database.
The interface between master device and Coordinating Database is WS,
the interface between Coordinating Database and database is WS.
In order to provide database discover mechanism another local entity
called AddrDatabase is added to the system, the AddrDatabase MAY be
independent or be integrated in other entity (such as database),
Shown in Figure 4.
The function of AddrDatabase is to provide the Internet addresses of
trusted database in the relevant regulatory domain to the master
device. The AddrDatabase is either hosted by or under control of the
national regulator.
+-------+ +------------+
|Master +-------------+AddrDatabase|
|Device | +------------+
+-------+
Figure 4: Framework of PAWS database discovery
When the master device is going to provide radio access service, it
MUST discover one database that can provide white space spectrum
information for it, and it needs to register some necessary
information to the database, and then the master device can query
white space channel from the database.
There SHOULD be some authentication procedures and some security
related procedures between database and master device.
4. Protocol Stack
The database querying message should be sent on reliable transport
protocol, and the database querying procedure is of request/response
model, besides the message MUST be transported securely. In order to
utilize the existing Internet protocol, a protocol stack model is
proposed here, shown in Figure 5, the transport layer is TCP and the
application layer is HTTPS. There may be some other protocol models,
for example using the Diameter as the application layer protocol.
Zhu Expires September 6, 2012 [Page 8]
Internet-Draft PAWS framework data model March 2012
+------------+ +------------+
|WS.App +-------------+ WS.App |
+------------+ +------------+
|HTTPS +-------------+HTTPS |
+------------+ +------------+
|TCP +-------------+TCP |
+------------+ +------------+
|IP +-------------+IP |
+------------+ +------------+
Master Device Database
Figure 5: Protocol stack of PAWS protocol
WS.App is the white space spectrum application protocol. This
protocol stack is used by WS interface.
5. Protocl framework and interface of PAWS
The protocol message interface defines the message contents and
message format of WS and 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 technology( e.g. 802.11af, IEEE
802.16, IEEE 802.22, LTE );
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 be satisfied to different scenarios
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 requirement, such as ciphering and integrity protection.
5.1. Database Discovery
The database discovery procedure is the process for white space
device to find the database from which it can query white space. In
this sub-clause the term database means the database entity from
which the white space device can query white space channel.
Database discovery is the prerequisite of the other procedures,
Zhu Expires September 6, 2012 [Page 9]
Internet-Draft PAWS framework data model March 2012
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.
The white space device gets the list of databases providing white
space spectrum querying service in the relevant regulatory domain,
and then the device will select one of the databases to connecting
to.
Optionally the white space device MAY be pre-programmed with the
Internet address of at least one trusted database manually. The
device can establish contact with a trusted database using one of the
pre-provisioned IP addresses.
Optionally the white space device can discover a list of databases
from AddrDatabase on the Internet which maintains a list of TVWS
databases and their Internet addresses. The procedure is shown in
Figure 6.
+------------------+ +------------+
|white space device| |AddrDatabase|
+------------------+ +------------+
| |
| |
| |
| |
| DISCOVERY REQ |
|----------------------------------------->|
| |
| |
| DISCOVERY RESP |
|< ----------------------------------------|
| |
| |
Figure 6: Discovery procedure
The discovery procedures shown in Figure 6 are as follows:
(1)The white space device is connected to the Internet by any means
other than using the white space radio.
(2)The white space device sends Database Discover request message to
AddrDatabase, when AddrDatabase receives the request message, it
finds out whether there are available trusted database for the device
to access to.
(3)The white space device waits a limited time for Database Discover
Zhu Expires September 6, 2012 [Page 10]
Internet-Draft PAWS framework data model March 2012
response message, If there is no available database or no acceptable
response is received within the limited time, the white space device
concludes that no trusted database is available, otherwise the device
will select a trusted database to connect to.
DISCOVERY_REQ is Database Discover request message and DISCOVERY_RESP
is Database Discover response message. DISCOVERY_REQ:
White space device sends its geo-location and coverage area
information to AddrDatabase, depending on the information the
AddrDatabase finds out databases which the white space device can
access to.
Parameters included in DISCOVERY_REQ message:
|------------------------------------------------------------------|
| parameters | comments |
|------------------------------------------------------------------|
| version | version of the protocol |
|------------------------------------------------------------------|
| message type | indicates the type of this message |
| | DISCOVERY_REQ here. |
|------------------------------------------------------------------|
| device id | device id of white space device |
|------------------------------------------------------------------|
| manufacture Series | the Series number of manufacture |
| number | of device |
|------------------------------------------------------------------|
| geo-location | geo-location of the white space device|
| | in the form of (latitude,longitude) |
|------------------------------------------------------------------|
| coverage range |coverage range of the white space device|
| | unit: m. |
|------------------------------------------------------------------|
DISCOVERY_RESP:
AddrDatabase sends the list of databases' information to white space
device by this message. The parameter "result" indicates whether
there are available databases or not.
Parameters included in DISCOVERY_ RESP message:
Zhu Expires September 6, 2012 [Page 11]
Internet-Draft PAWS framework data model March 2012
|------------------------------------------------------------------|
| parameters | comments |
|------------------------------------------------------------------|
| version | version of the protocol |
|------------------------------------------------------------------|
| message type | indicates the type of this message |
| | DISCOVERY_RESP here. |
|------------------------------------------------------------------|
| result | Indicating whether there are |
| | available databases or not. |
|------------------------------------------------------------------|
| list of databases | A list of available databases to |
| | which the white space device can |
| | access to. |
|------------------------------------------------------------------|
5.2. Device Registration with Trusted Database
The registration procedure is used to register the information that
will not change very frequently to the trusted database which the
white space device will connects to, before the device can transmit
in white space, it must contact a trusted database where the device
can learn if any channels are available for it to use.
The registration procedure occurs when one of these conditions
happens :
(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 before changed, and the master
device need update its registration information.
In this sub-clause the term database means the database entity from
which the white space device can query white space channel.
The registration procedure also includes the authentication procedure
and the establishment of security-related information which may be
used in subsequent messages.
The registration procedure is shown in Figure 7.
Zhu Expires September 6, 2012 [Page 12]
Internet-Draft PAWS framework data model March 2012
+------------------+ +------------+
|white space device| | Database|
+------------------+ +------------+
| |
| |
| |
| |
| REGISTRATION_REQ |
|----------------------------------------->|
| |
| |
| REGISTRATION_RESP |
|< ----------------------------------------|
| |
| |
Figure 7: The registration procedure
The registration procedure using the following steps:
(1)The white space device connects to the selected trusted database.
(2)The white space device sends registration request message to the
trusted database. In this message the parameters to be registered
and the security-related information are included.
(3)The database sends the registration response message to the white
space device indicating whether the registration is success or not,
the database also sends security-related information, that will be
used in the subsequent procedures.
REGISTRATION_REQ is the registration request message and
REGISTRATION_RESP is the registration response message.
REGISTRATION_REQ:
Zhu Expires September 6, 2012 [Page 13]
Internet-Draft PAWS framework data model March 2012
|------------------------------------------------------------------|
| parameters | comments |
|------------------------------------------------------------------|
| version | version of the protocol |
|------------------------------------------------------------------|
| message type | indicates the type of this message |
| | REGISTRATION_REQ here. |
|------------------------------------------------------------------|
| device id | device id of white space device |
|------------------------------------------------------------------|
| device type | the device type of the |
| | white space device| |
|------------------------------------------------------------------|
| manufacture Series | the Series number of manufacture |
| number | of device |
|------------------------------------------------------------------|
| | Antenna characteristic of the white |
| | space device.Includes:Antenna height |
| antenna characteristic |above the ground, direction, gain, |
| | maximum output power, spectrum mask |
| | |
|------------------------------------------------------------------|
| |includes:name of the individual or |
| |business that owns the device, name of a|
| |contact person responsible for the |
| Device owner's | device's operation, address for the |
| information | contact person, email address for the |
| | contact person and phone number of the|
| | contact person |
|------------------------------------------------------------------|
|authentication |the information for authentication |
| information |between white space device and database |
|------------------------------------------------------------------|
REGISTRATION_RESP:
Zhu Expires September 6, 2012 [Page 14]
Internet-Draft PAWS framework data model March 2012
|------------------------------------------------------------------|
| parameters | comments |
|------------------------------------------------------------------|
| version | version of the protocol |
|------------------------------------------------------------------|
| message type | indicates the type of this message |
| | REGISTRATION_RESP here. |
|------------------------------------------------------------------|
| result | indicates whether the connection |
| |establishment is success or fail |
|------------------------------------------------------------------|
| | the identification that the database |
| entity id | assigns for white space device. the |
| | Entity ID is unique in the scope of |
| | the database |
|------------------------------------------------------------------|
| authentication |the information for authentication |
| information |between white space device and database |
|------------------------------------------------------------------|
5.3. White Space Channel Query
In this sub-clause the term database means the database entity from
which the white space device can query white space spectrum.
The query procedure is used for white space device to query the white
space channel from database, the procedure is depicted in Figure 8.
+------------------+ +------------+
|white space device| | Database|
+------------------+ +------------+
| |
| |
| |
| |
| AVAIL_WS_REQ |
|----------------------------------------->|
| |
| |
| AVAIL_WS_RESP |
|< ----------------------------------------|
| |
| |
| |
Figure 8: The available channel query procedure
The query procedure using the following steps:
Zhu Expires September 6, 2012 [Page 15]
Internet-Draft PAWS framework data model March 2012
(1) The white space device sends the white space query request
message to database and waits a limited period of time for white
space query response message from database.
(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.
(3) If there is no available channel or no acceptable response is
received within the limited time, the white space device concludes
that no channel is available.
AVAIL_WS_REQ is the available white space query request message;
AVAIL_WS_RESP is the available white space query response message.
AVAIL_WS_REQ:
Zhu Expires September 6, 2012 [Page 16]
Internet-Draft PAWS framework data model March 2012
|------------------------------------------------------------------|
| parameters | comments |
|------------------------------------------------------------------|
| version | version of the protocol |
|------------------------------------------------------------------|
| message type | indicates the type of this message |
| | AVAIL_WS_REQ here. |
|------------------------------------------------------------------|
| device id | device id of white space device |
|------------------------------------------------------------------|
| device type | the device type of the |
| | white space device |
|------------------------------------------------------------------|
| List of coverage area(s)| a list of coverage area(s) where the |
| information | master device may provide white space |
| | access service.incudes:geo-location ( |
| | latitude ,longitude), uncertainty of |
| | geo-location(in meters),and confidence(|
| | in percentage ) for the location |
| | determination,coverage range. |
|------------------------------------------------------------------|
| | Antenna characteristic of the white |
| | space device.Includes:Antenna height |
| antenna characteristic |above the ground, direction, gain, |
| | maximum output power, spectrum mask |
| |( optional in this message) |
|------------------------------------------------------------------|
| |The bandwidth the device needs to form |
| Bandwidth |the wireless network. |
| | |
|------------------------------------------------------------------|
| Entity ID |the identification that the database |
| |assigns for device. the Entity ID |
| | is unique in the scope of database |
|------------------------------------------------------------------|
AVAIL_WS_RESP:
Zhu Expires September 6, 2012 [Page 17]
Internet-Draft PAWS framework data model March 2012
|------------------------------------------------------------------|
| parameters | comments |
|------------------------------------------------------------------|
| version | version of the protocol |
|------------------------------------------------------------------|
| message type | indicates the type of this message |
| | AVAIL_WS_RESP here. |
|------------------------------------------------------------------|
| device id | device id of white space device |
|------------------------------------------------------------------|
| device type | the device type of the |
| | white space device| |
|------------------------------------------------------------------|
| result | indicates whether the query procedure |
| | is success or fail |
|------------------------------------------------------------------|
| |includes:frequency information,available|
| | bandwidth, available time duration, |
| White Space channel |coverage area, maximum transmission |
| lists | power |
| | |
|------------------------------------------------------------------|
| Entity ID |the identification that the database |
| |assigns for device. the Entity ID |
| | is unique in the scope of database |
|------------------------------------------------------------------|
5.4. White Space Channel Update
In order to avoid interfering with the primary user or other
secondary user, the white space updating mechanism is provided in
this draft. There are two methods for white space updating:
Method 1: The white space device MUST access the database to obtain
and update the list of available channels that could be utilized by
the device. 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.
Method 2: Database push updates in channel availability changes to
the master device, when the availability of channel changes database
SHOULD inform the master device and after receiving the notification
the master device SHOULD begin the white space channel query
procedure to get the updated white space channel.
The update procedure of method 1 is shown in Figure 9.
Zhu Expires September 6, 2012 [Page 18]
Internet-Draft PAWS framework data model March 2012
+------------------+ +------------+
|white space device| | Database|
+------------------+ +------------+
| |
+--------------------+ |
|Update timer expires| |
+--------------------+ |
| |
| |
| |
| |
| white space channel query procedure |
|< --------------------------------------->|
| |
| |
Figure 9: White space channel update procedure for method 1
In white space channel update procedure of method 1, an update timer
is set, after the white space device query the database for first
time, the timer start to run, when the timer expires the device will
implement the white space channel query procedure and update the
channel list, and then clear the update timer.
The update procedure of method 2 is shown in Figure 10.
+------------------+ +-------------+
|Database | |Master device|
+------------------+ +-------------+
| |
+-------------------------+ |
|The availability of some | |
| channel changes | |
+-------------------------+ |
| |
| |
| send channel updates message |
|----------------------------------------->|
| |
| |
| white space channel query procedure |
|< --------------------------------------->|
| |
| |
Figure 10: White space channel update procedure for method 2
As shown in Figure 10, when the availability of some white space
Zhu Expires September 6, 2012 [Page 19]
Internet-Draft PAWS framework data model March 2012
channels change, database will send channel updates message to the
white space device, and after receiving the message white space
device MUST start white space channel query procedure, discussed in
section 5.3. Here the white space device can be a coordinating
database as well as a master device. The parameters included in this
channel updates message are shown below:
CHANNEL_UPDATE_NOTIFICATION:
|------------------------------------------------------------------|
| parameters | comments |
|------------------------------------------------------------------|
| version | version of the protocol |
|------------------------------------------------------------------|
| message type | indicates the type of this message |
| | CHANNEL_UPDATE_NOTIFICATION here. |
|------------------------------------------------------------------|
| |Includes owner's name, or other of the |
|Owner information of the |information for identify the owner |
| database | database |
|------------------------------------------------------------------|
| Address information | URL or IP address of database |
|------------------------------------------------------------------|
6. Message Encoding
In this framework XML is used to encode the message. HTTPS is used
to carry the XML, there is an example of how XML formatted message is
embedded in HTTP:
(1) For the request message:
GET destination_url HTTP/1.0
Accept: */*
Proxy-Connection: Keep-Alive
User-Agent: Mozilla/4.0
Host: host name
Content-Type: text/xml
<?xml version="1.0" encoding="UTF-8"?>
xml message.
(2) For the response message:
Zhu Expires September 6, 2012 [Page 20]
Internet-Draft PAWS framework data model March 2012
HTTP/1.1 200 OK
Proxy-Connection: Keep-Alive
Connection: Keep-Alive
Content-Length: 59042
Date: Thu, 09 Sep 2010 03:31:54 GMT
Content-Type: text/xml
Server: server name
Cache-Control: max-age=7200
<?xml version="1.0" encoding="UTF-8"?>
xml message.
The details of XML schema is shown below, the details of parameters
in the message are included in the XML schema:
<?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 message type, different message
is assigned a integer number to distinguish from each other,
Shown as below:
#define DISCOVERY_REQ_MSG 1
#define DISCOVERY_RESP_MSG 2
#define REGISTRATION_REQ_MSG 3
#define REGISTRATION_RESP_MSG 4
#define AVAIL_WS_REQ_MSG 5
#define AVAIL_WS_RESP_MSG 6
Zhu Expires September 6, 2012 [Page 21]
Internet-Draft PAWS framework data model March 2012
#define CHANNEL_UPDATE_NOTIFICATION 7
-->
<xs:simpleType name="messageType">
<xs:restriction base="xs:integer">
<xs:enumeration value="DISCOVERY_REQ_MSG"/>
<xs:enumeration value="DISCOVERY_RESP_MSG"/>
<xs:enumeration value="REGISTRATION_REQ_MSG"/>
<xs:enumeration value="REGISTRATION_RESP_MSG"/>
<xs:enumeration value="AVAIL_WS_REQ_MSG"/>
<xs:enumeration value="AVAIL_WS_RESP_MSG"/>
<xs:enumeration value="CHANNEL_UPDATE_NOTIFICATION"/>
</xs:restriction>
</xs:simpleType>
<!--definition of the element type of device's ID-->
<xs:simpleType name="deviceIDType">
<xs:restriction base="xs:string"/>
</xs:simpleType>
<!--definition of the element type of device -->
<xs:simpleType name="deviceType">
<xs:restriction base="xs:string"/>
</xs:simpleType>
<!--definition of the element type of manufacture series number-->
Zhu Expires September 6, 2012 [Page 22]
Internet-Draft PAWS framework data model March 2012
<xs:simpleType name="manufactureSeqNumType">
<xs:restriction base="xs:string"/>
</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">
<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">
Zhu Expires September 6, 2012 [Page 23]
Internet-Draft PAWS framework data model March 2012
<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-->
<xs:simpleType name="resultType">
<xs:restriction base=xs:boolean>
<xs:enumeration value="true"/>
<xs:enumeration value="false"/>
Zhu Expires September 6, 2012 [Page 24]
Internet-Draft PAWS framework data model March 2012
</xs:restriction>
</xs:simpleType>
<!--definition of element type of database information-->
<xs:complexType name="databaseInfoType">
<xs:element name="databaseID" type="xs:string"/>
<xs:element name="databaseOwner" type="xs:string"/>
<xs:choice>
<xs:element name="ipAddress" type="xs:string"/>
<xs:element name="URL" type="xs:string"/>
</xs:choice>
</xs:complexType>
<!--definition of element type of list of database-->
<xs:complexType name="databaseListType">
<xs:sequence minOccurs="0" maxOccurs="unbounded">
<xs:element name="databaseInfo" type="databaseInfoType"/>
</xs:sequence>
</xs:complexType>
<!--
definition of element type of antenna characteristics
Unit:
antenna gain db
antenna height m
antenna direction rad
Zhu Expires September 6, 2012 [Page 25]
Internet-Draft PAWS framework data model March 2012
maximum output power dbm
-->
<xs:complexType name="antennaCharacterType">
<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
entity(includes database, coordination database, whitespace
device etc.) id -->
<xs:simpleType name="entityIDType">
<xs:restriction base="xs:string"/>
</xs:simpleType>
<!--definition of element type of security information-->
<xs:simpleType name="securityInfoType">
<xs:restriction base="xs:string"/>
</xs:simpleType>
<!--
definition of element type of bandwidth
uint:
Zhu Expires September 6, 2012 [Page 26]
Internet-Draft PAWS framework data model March 2012
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 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>
Zhu Expires September 6, 2012 [Page 27]
Internet-Draft PAWS framework data model March 2012
<!--
definition of element type of maximum transmit power
unit:
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 element type of authentication information-->
<xs:simpleType name="authenticationInfoType">
<xs:restriction base="xs:string"/>
</xs:simpleType>
<!-- Definition Of Messages-->
<!--definition of discovery request message-->
Zhu Expires September 6, 2012 [Page 28]
Internet-Draft PAWS framework data model March 2012
<xs:element name="DISCOVERY_REQ_MSG">
<xs:complexType>
<xs:sequence>
<xs:element name="version" type="versionType"/>
<xs:element name="message" type="messageType"/>
<xs:element name="deviceID" type="deviceIDType"/>
<xs:element name="manufactureSeqNum" type="manufactureSeqNumType"/>
<xs:element name="geoLoaction" type="geoLocationType"/>
<xs:element name="coverageRange" type="coverageRangeType"/>
</xs:sequence>
</xs:complex>
</xs:element>
<!--definition of discovery response message-->
<xs:element name="DISCOVERY_RESP_MSG">
<xs:complexType>
<xs:sequence>
<xs:element name="version" type="versionType"/>
<xs:element name="message" type="messageType"/>
<xs:element name="result" type="resultType"/>
<xs:element name="databaseList" type="databaseListType"/>
</xs:sequence>
</xs:complexType>
</xs:element>
Zhu Expires September 6, 2012 [Page 29]
Internet-Draft PAWS framework data model March 2012
<!--definition of registration request message-->
<xs:element name="REGISTRATION_REQ_MSG">
<xs:complexType>
<xs:sequence>
<xs:element name="version" type="versionType"/>
<xs:element name="message" type="messageType"/>
<xs:element name="deviceID" type="deviceIDType"/>
<xs:element name="device" type="deviceType"/>
<xs:element name="manufactureSeqNum" type="manufactureSeqNumType"/>
<xs:element name="antennaCharacter" type="antennaCharacterType"/>
<xs:element name="deviceOwnerInfo" type="deviceOwnerInfoType"/>
<xs:element name="securityInfo" type="securityInfoType"/>
<xs:element name="authenticationInfo" type="authenticationInfoType"/>
</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="message" type="messageType"/>
<xs:element name="result" type="resultType"/>
<xs:element name="entityID" type="entityIDType"/>
Zhu Expires September 6, 2012 [Page 30]
Internet-Draft PAWS framework data model March 2012
<xs:element name="authenticationInfo" type="authenticationInfoType"/>
</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"/>
<xs:element name="message" type="messageType"/>
<xs:element name="device" type="deviceType"/>
<xs:element name="deviceID" type="deviceIDType"/>
<xs:element name="coverageAreaList" type="coverageAreaListType"/>
<xs:element name="bandwidth" type="bandwidthType"/>
<xs:element name="entityID" type="entityIDType"/>
</xs:sequence>
<xs:all>
<xs:element name="antennaCharacter" type="antennaCharacterType"/>
</xs:all>
</xs:complexType>
</xs:element>
<!--definition of availabel ws query response message-->
<xs:element name="AVAIL_WS_RESP_MSG">
Zhu Expires September 6, 2012 [Page 31]
Internet-Draft PAWS framework data model March 2012
<xs:complexType>
<xs:sequence>
<xs:element name="version" type="versionType"/>
<xs:element name="message" type="messageType"/>
<xs:element name="device" type="deviceType"/>
<xs:element name="deviceID" type="deviceIDType"/>
<xs:element name="result" type="resultType"/>
<xs:element name="entityID" type="entityIDType"/>
<xs:element name="channelList" type="channleListType"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<!--definition of channel update notification message-->
<xs:element name="CHANNEL_UPDATE_NOTIFICATION">
<xs:complexType>
<xs:element name="version" type="versionType"/>
<xs:element name="message" type="messageType"/>
<xs:element name="databaseInfo" type="databaseInfoType">
</xs:complexType>
</xs:element>
</xs:schema>
Zhu Expires September 6, 2012 [Page 32]
Internet-Draft PAWS framework data model March 2012
7. Security Considerations
There are some security consideration about PAWS:
o Mutual authentication between master device and database, master
device and coordination database, coordination database and
database is needed.
o In order to protect the message from being changed by attacker,
all the messages need integrity protection.
o Because there are some private information included in the
messages, so a ciphering mechanism SHOULD be used to encrypt the
messages.
8. IANA Considerations
There have been no IANA considerations so far in this document.
9. Acknowledgments
Thanks to my colleagues for their sincerely help and comments when
drafting this document.
10. Normative Reference
[I-D.ietf-paws-problem-stmt-usecases-rqmts]
Probasco, S. and B. Patil, "Protocol to Access White Space
database: PS, use cases and rqmts",
draft-ietf-paws-problem-stmt-usecases-rqmts-03 (work in
progress), February 2012.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Zhu Expires September 6, 2012 [Page 33]
Internet-Draft PAWS framework data model March 2012
Author's Address
Lei Zhu
Huawei Technologies
Huawei Building, Q20 No.156 Beiqing Rd.Z-park
Haidian District, Beijing 100095
P. R. China
Phone: +86-10-60612078
Email: lei.zhu@huawei.com
Zhu Expires September 6, 2012 [Page 34]
