Internet DRAFT - draft-zhang-paws-spectrum-map
draft-zhang-paws-spectrum-map
PAWS Neng Zhang
Internet Engineering Task Force Jianfeng Guan
Internet-Draft Changqiao Xu
Mingchuan Zhang
Intended status: Informational Hongke Zhang
BUPT
Expires: June 12,2014 December 12,2013
PAWS Database Spectrum Map
draft-zhang-paws-spectrum-map-00
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on June 12, 2014.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
<Zhang, et al.> Expires June 12, 2014 [Page 1]
Internet-Draft Spectrum Map for PAWS December 2013
Abstract
White space allocation and reutilization has attracted increasing
attention since they allow a more efficient way to gather spectrum
usage information and keep assigning a proper spectrum to a
secondary user. This document provides an extended protocol to
construct a specific white space usage map with better interaction
between devices and spectrum database. By this mechanism, the Master
device or Slave Device sends the environmental spectrum to the
Database and obtains more frequency points to select the most
appropriate white space spectrum it could use in the local
regulatory domain. With regard to White Space Database, more white
space information can be recorded for devices to choose. The
mechanism is an extension of protocol to access spectrum database.
We develop extended protocol data models under different scenarios
to enhance interaction of these networks.
Table of Contents
1. Introduction.................................................2
2. Conventions used in this document............................3
3. Protocol Overview............................................4
3.1. Problem description.....................................4
3.2. Parameter definition....................................5
3.3. Map data model..........................................6
3.4. General process.........................................6
4. Scenario Application.........................................7
4.1. Passive mode............................................7
4.1.1. Master-slave scenario..............................8
4.1.2. Mixed scenario.....................................9
4.2. Proactive mode.........................................10
5. Security Considerations.....................................11
6. IANA Considerations.........................................11
7. Conclusions.................................................11
8. References..................................................12
8.1. Normative References...................................12
8.2. Informative References.................................12
9. Acknowledgments.............................................12
Authors?Addresses..............................................13
1. Introduction
By virtue of dynamic spectrum access technologies, PAWS protocol and
technology have developed into a standardized process and the
related industrial solutions have been gradually implemented. In
theory, the Database manages and distributes the available spectrum
in a regulatory domain to the Master Device, but in reality, these
<Zhang> Expires June 12, 2014 [Page 2]
Internet-Draft Spectrum Map for PAWS December 2013
available spectra that could cover this whole area are much scarcer.
According to the white space access experiments such as Google, when
the white space device (WSD) queries a trusted white space database
(WSDB) for a list of white space spectrum or channels, the database
responsible for this area often provide some spectra sensed which
can be covered through the whole area. Consequently, too many
requests will lead available spectrum congestion, which violates the
white space spirit, while more local white spaces with small limited
coverage are neglected. This is because the spectrum information is
often collected by database direct sensing, which is insufficient
and inefficient. Actually the available spectrum in a certain area
is more than that WSDB can provide. This low spectrum accuracy
problem might lead to a great waste for available spectrum in a
local area. Unfortunately, little work has been done for this.
With respect to such spectrum measurement and management issues, the
European scholars are endeavoring to construct Radio Environmental
Maps (REMs) via FARAMIR project, to obtain reliable spatial spectrum
measurements. Some prototype and exploratory experiments such as
spectrum use in London are deployed and finished. But this topic is
mainly focused on spectrum sensing and cooperating use of sensing
devices such as USRP2s, WARP, SunSPOTs and etc. Challenges remain
that how to enhance spectrum information exchange via ground data
with the operation entities.
To solve this problem, we propose a spectrum map method and a
protocol to handle the accuracy issue and provide more spectra to
WSD. When a WSD is requesting the white space spectrum from database,
they locally send available spectrum information to the WSDB to
piece them together and form a specific spectrum map at a given time
and location. A primary goal is to improve the available spectrum
accuracy. Correspondingly, more spectra can be allocated to the WSD
to improve the white space usage ratio and scalability. Our protocol
is an expansion of the existing PAWS protocol. By virtue of existing
parameters definition, the proposed function is easy to implement
since no extra parameters would be introduced.
2. 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 RFC-2119 [RFC2119].
The terminology from PAWS: problem statement, use cases and
requirements PAWS RQMTS [PAWS RQMTS] is applicable to this document.
White Space Spectrum Map
<Zhang> Expires June 12, 2014 [Page 3]
Internet-Draft Spectrum Map for PAWS December 2013
This is an advanced function of WSDB with a more specific
description for spectrum usage situation. Through the interaction
between WSD and WSDB instead of arbitrary assignment by WSDB to a
WSD, more spectrum usage information can be exchanged to improve the
spectrum resource efficiency.
This function can be integrated into a normal WSDB or an advanced
server administrator with other auxiliary functions such as spectrum
discovering or identifying. It depends on the regulatory domain
scope and performance requirement.
This draft is in scope for the reason that it could provide more
spectrum information to solve the database sensing accuracy problem.
Moreover, the white space device could receive a list of available
white space spectra fully qualified via a specified user activity
condition with a reasonable efficiency boosting.
3. Protocol Overview
In this section we will introduce an improved general protocol
process of spectrum query based on the collected spectrum
information, which is noted as the spectrum usage map, to provide
more available spectra. Our method can enhance the database spectrum
accuracy, further solving the efficiency and scalability problems.
3.1. Problem description
PAWS is proposed to achieve interoperability among multiple devices
and databases to maximize overall unused spectrum utilization. In
general operation of spectrum request, the Master Device discovers
the Database in this regulatory domain and sends a spectrum request.
Then the Database responses a schedule of spectrum from the spectrum
list, so that WSD could select the appropriate spectrum to use.
In this process, an available spectrum is locally sensed by Database
in a specific area. In another word, the spectrum is available if
this spectrum can be used within this whole regulatory domain range.
For example, at Haidian District in Beijing, a few of largely
sensible spectra can be used in this local area at a certain time
interval. But for a more specific spot, in addition to the largely
sensed spectra, more tiny and dense white spaces are free to occupy.
So these white space detection and utilization can immensely relieve
the pressure of largely sensible spectrum access.
Motivated by these observations, our goal is to acquire more locally
available spectra to improve the spectrum accuracy. The interaction
between WSD and Database could be divided into the following steps:
<Zhang> Expires June 12, 2014 [Page 4]
Internet-Draft Spectrum Map for PAWS December 2013
local spectrum join, map construction, spectrum response and
spectrum reallocation. Databases would be responsible of recording
and analyzing the information to build the map and provide more
spectra to WSD. Meanwhile, if a new WSD with similar activity
requests a spectrum, the Database can provide a similar available
spectrum list in this area. This mechanism can greatly increase the
resources availability.
3.2. Parameter definition
Obviously we need a parameter to describe such a spectrum join
request. According to a series of parameter definitions in the
latest PAWS protocol draft version 6, the GeoSpectrumSchedule
parameter format is originally used in AVAIL_SPECTRUM_BATCH_RESP
request, to return a schedule of available spectrum at a location.
Here in order to extend the protocol with compatibility and
continuity, this format can be used in AVAIL_SPECTRUM_BATCH_REQ, to
directly provide a schedule of locally available spectrum at current
location and time. Hence the existing data structure can be
exploited immediately without new data structure modification. As
shown in the table 1:
+-------------------------------+------------------------------+
|AVAIL_SPECTRUM_BATCH_REQ | |
+-------------------------------+------------------------------+
|deviceDesc:DeviceDescriptor | required |
|locations:list | required |
|antenna:AntennaCharacteristics | depends on regulatory domain |
|owner:DeviceOwner | depends on regulatory domain |
|capabilities:DeviceCapabilities| optional |
|geoSpectrumSchedules:list | required |
+-------------------------------+------------------------------+
Table 1 A developed AVAIL_SPECTRUM_BATCH_REQ format
The starttime and stoptime in GeoSpectrumSchedule can be extracted
either or quantized to a time interval later.
On the other hand, we can combine location and SpectrumSchedule
parameters to provide such a Spectrum Join Request with temperal-
spatial spectrum information instead of the GeoSpectrumSchedule
parameter ahead. As shown in the table 2:
+-------------------------------+------------------------------+
|AVAIL_SPECTRUM_BATCH_REQ | |
+-------------------------------+------------------------------+
|deviceDesc:DeviceDescriptor | required |
|locations:list | required |
|antenna:AntennaCharacteristics | depends on regulatory domain |
|owner:DeviceOwner | depends on regulatory domain |
|capabilities:DeviceCapabilities| optional |
|spectrumSchedule:list | required |
+-------------------------------+------------------------------+
Table 2 An alternative AVAIL_SPECTRUM_BATCH_REQ format
<Zhang> Expires June 12, 2014 [Page 5]
Internet-Draft Spectrum Map for PAWS December 2013
3.3. Map data model
The temperal-spatial spectrum information will be stored in map
model in the form of multi-dimensional distribution. How to build a
data structure in database to analyze the data is a critical issue.
Such historic observations processed by related big data technology
support and dynamic database solutions will be discussed in future.
As well as the detailed map formulation, for the sake of monitor the
realtime incoming data, user interface display will benefit to
visualize a description to the spectrum occupancy activity.
3.4. General process
1 Spectrum Join Request
A WSD keeps detecting available white spectrum in a sensible range.
When idle spectra detected, The WSD sends a spectrum request with
white space information to the database. White space information
mainly includes WSD geographical location, the detection time, a
list of available spectrum and etc.
2 Spectrum Map Construction
WSDB gathers the received information to construct spectrum activity
map. This is a dynamic process of data processing via interaction
with WSD. The database could update spectrum information
periodically and rank them with usage priority.
3 Spectrum Response
Within the spectrum response message, WSDB chooses available
spectrum information according to the updated spectrum map, assigns
it to WSD. This spectrum list could be shortlisted but actually more
reasonable information is contained than before.
<Zhang> Expires June 12, 2014 [Page 6]
Internet-Draft Spectrum Map for PAWS December 2013
4 Spectrum Reallocation
Furthermore, when a new request from this WSD or another WSD with
similar activity arriving, the database can quickly provide it with
the same expanded spectrum information. In addition, WSD could claim
the spectrum usage request to database for a permission of spectrum
occupancy.
4. Scenario Application
In this section we will elaborate the implementation process of two
basic message exchange mechanisms under real scenarios. According to
the spectrum query manner, we classify the protocol form as passive
mode and proactive mode. The passive mode is thought to build Map
and assign spectrum to WSD by database. The proactive mode is
thought to launch Map construction spectrum request by WSD.
According to the relationship between devices, we classify the
scenarios as master-slave type and mixed type scenarios.
Generally speaking, the spectrum coverage of macrocell or microcell
could be divided into several blocks by power strength and
transmitter location. In our protocol, the database can be deployed
in view of WSD activity as well as signal sensing and practical
network scale consideration. In this regard, our proposed scheme can
reduce the number of required spectrum-sensing databases while
offering more locally adapted spectrum information to improve
equipment utilization.
4.1. Passive mode
In most cases, a master device is in charge of a group of Slave
Devices physically located to it and distributes them a spectrum
uniformly. Here we suppose this case as master-slave scenario. In
mixed scenario, Slave Devices will be treated as a standalone entity
with master device, together regarding as WSD or secondary users, to
exploit tiny spectrum opportunity flexibly. Our protocol can be
shown as follows.
<Zhang> Expires June 12, 2014 [Page 7]
Internet-Draft Spectrum Map for PAWS December 2013
4.1.1. Master-slave scenario
+------------+ +-------------+ +----------+
|Slave Device| |Master Device| | WSDB |
+------------+ +-------------+ +----------+
| | |
| AVAIL_SPEC_BATCH_REQ with | |
| Spectrum Join Request | |
|(GeoSpectrumSchedule format)| |
|--------------------------->| |
| | AVAIL_SPECTRUM_BATCH_REQ|
| |------------------------>|
| | Map Construction |
| |-------------------------|
| | Spectra Ranking |
| |-------------------------|
| |AVAIL_SPECTRUM_BATCH_RESP|
| |<------------------------|
| AVAIL_SPEC_BATCH RESP with | |
|expanded spectra information| |
|<---------------------------| |
| /--------------------------|-----------------------\ |
|/ SD1&2 Request |AVAIL_SPECTRUM_RESP with\|
|\ SD1&2 Response | expanded spectra lists /|
| \--------------------------|-----------------------/ |
Figure 1 An overview of procedures of spectrum query in passive mode
(1) Spectrum Join Request procedure
The first two messages are used to send available spectrum
information to WSDB by Master Device collected by a Slave Device. It
conveys the available spectrum list at the WSD's given location at
that time interval. The data structure is in line with
GeoSpectrumSchedule format aforementioned. Other types of related
information will TBD.
(2) Spectrum Map Construction Procedure
These two steps of database are used to gather available spectrum
information to construct map by WSDB. It conveys the available
spectrum list at a certain location of Slave Device at that time. In
this process, time quantization and spectrum sorting are necessary
to simplify the big data produced by numerous Slave Devices along
the time distribution. This kind of good spectrum with high
priority would be qualified as QoS criteria such as less handoff,
<Zhang> Expires June 12, 2014 [Page 8]
Internet-Draft Spectrum Map for PAWS December 2013
strong signal strength and etc. The specific process methods will
depend on actual conditions.
(3) Spectrum Response procedure
The second two messages are used to return available spectrum
information to a Slave Device by WSDB. This procedure conveys a
listing of one or more proper spectra to Master Device. Since
locally sensed and user detected spectra are both taken into account
by the database, this available spectrum list is more practical and
effective than that in original protocol.
After WSDB returning the spectrum information, the master device can
straightly select a best one from the list and assign it to that
Slave Device or a group of Slave Devices. The subsequent interaction
of spectrum acknowledgement follows the original protocol.
(4) Spectrum reallocation procedure
In next spectrum request initiated by a same Slave Device or a new
Slave Device with similar activity, that is, in neighborhood at a
time very close to it, they can quickly receive a shortlisted
spectrum response.
For the original Slave Device, it could quickly apply available
white space spectrum from the WSDB with such historical information
stored in spectrum Map. For a new WSD, it could enjoy more spectra
to choose and apply a proper spectrum from the WSDB with such
historical information. This will facilitate and accelerate the
white space negotiation process.
We can further generalize the master device and Slave Device as
white space device. Such a WSD can communicate with Database
directly without delivered by Master Device.
4.1.2. Mixed scenario
We can further generalize the master device and Slave Device as a
WSD. This could be deemed as a mixed user case where single white
space user is involved as main device, same as base station acted as
the Master Device. Such a WSD can straightly communicate with
Database to apply a spectrum independently without delivered by
Master Device.
<Zhang> Expires June 12, 2014 [Page 9]
Internet-Draft Spectrum Map for PAWS December 2013
4.2. Proactive mode
Other than the mechanisms that the WSD awaits the database to
analyze data and send a response, we have an alternative solution to
supplement the passive mode aforementioned. The WSD will query the
database if it could arbitrarily occupy a detected spectrum. The
message exchange process is shown as follows.
+------------+ +-------------+
| WSD | | WSDB |
+------------+ +-------------+
| AVAIL_SPEC_BATCH_REQ with |
| Spectrum Usage Request |
| (GeoSpectrumSchedule format) |
|----------------------------->|
| |
| spectrum inspection with map |
|------------------------------|
| |
| SPECTRUM_USE_RESP |
|(or AVAIL_SPEC_BATCH RESP with|
| expanded spectra information)|
|<-----------------------------|
| |
| SPECTRUM_USE_NOTIFY |
|----------------------------->|
| |
| SPECTRUM_USE_RESP |
|<-----------------------------|
Figure 2 An overview of procedures of spectrum query in proactive mode
(1) Spectrum Usage Request procedure
The WSD locally selects a proper spectrum and send a request with a
spectrum Usage Request. This request also takes a
GeoSpectrumSchedule format and usually carried one or more pieces of
wanted spectrum information. Thus a boolean flag may be required to
denote the message as a usage request rather than a join request.
(2) Spectrum Usage Response procedure
The WSDB would check the historical spectrum information with the
map to judge if this spectrum has been assigned. If the spectrum is
either available or never recorded before, the database will
directly return a SPECTRUM_USE_RESP message. Correspondingly, the
spectrum information will be added into the map.
<Zhang> Expires June 12, 2014 [Page 10]
Internet-Draft Spectrum Map for PAWS December 2013
Or else, if the spectrum is unsuitable for use like assigned or
blacklisted, the database will straightly return a spectrum response
with a refuse acknowledgement. Since now spectrum access is not
authorized at the WSD physical location, the database will
response an AVAIL_SPEC_BATCH RESP message contained an error code
and selected spectra information list for use. Error code can be
defined to label the reject type. Then the WSD makes a spectrum
decision and send SPECTRUM_USE_NOTIFY message to confirm the
spectrum usage in accordance with the original protocol. The
database simply acknowledges the notification.
5. Security Considerations
By using the aforementioned protocol, the Master Device and the
Database expose themselves to the following risks:
Accuracy: A Master Device may receive inaccurate spectrum
availability information, such as incorrect or outdated spectrum.
DDos attack: a database may receive false information by a WSD.
But do not worry. This protocol exploits inherent protection from
these risks depending on the following reasons.
When such risks occur, if a database keeps receiving false or
malicious information by a WSD, the database and other users could
not be affected. With regard to the WSD itself, the false spectrum
list will be returned to this WSD for self-use. For other WSDs, such
false information can be treated as isolated point in big data
gathered from numerous users and the influence is tiny. Besides,
some other illegal use of spectrum threats and relevant terrorist
model would be discussed in future.
6. IANA Considerations
This document makes no request of IANA.
7. Conclusions
This memo discusses the accuracy problems arise from the white space
database access, and describes some solutions.
<Zhang> Expires June 12, 2014 [Page 11]
Internet-Draft Spectrum Map for PAWS December 2013
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the
Internet: Timestamps", RFC 3339, July 2002.
[I-D.ietf-paws-protocol] Chen, V., Das, S., Zhu, L., Malyar, J., and
P. McCann,"Protocol to Access Spectrum Database",Draft-
ietf-paws-protocol-06(work in progress),June 2013.
[I-D.das-paws-protocol] Das, S., Malyar, J., and D. Joslyn, "Device
to Database Protocol for White Space", draft-das-paws-
protocol-02(work in progress), July 2012.
[I-D.ietf-paws-problem-stmt-usecases-rqmts] Mancuso, A. and B. Patil,
"Protocol to Access White Space (PAWS) Database: Use Cases
and Requirements", draft-ietf-paws-problem-stmt-usecases-
rqmts-15 (work in progress), January 2013.
[I-D.wei-paws-framework] Wei, X., Zhu, L., and P. McCann, "PAWS
Framework", draft-wei-paws-framework-00 (work in progress),
July 2012.
8.2. Informative References
[1] EC FP7 project FARAMIR, Information available at:
http://www.ictfaramir.eu/.
9. Acknowledgments
Thanks to my colleagues for their sincerely contributions and
comments when drafting this document.
<Zhang> Expires June 12, 2014 [Page 12]
Internet-Draft Spectrum Map for PAWS December 2013
Authors' Addresses
Neng Zhang
State Key Laboratory of Networking and Switching Technology
Beijing University of Posts and Telecommunications,
Beijing, 100876, P.R.China
EMail: zn@bupt.edu.cn
Jianfeng Guan
State Key Laboratory of Networking and Switching Technology
Beijing University of Posts and Telecommunications,
Beijing, 100876, P.R.China
EMail: jfguan@bupt.edu.cn
Mingchuan Zhang
State Key Laboratory of Networking and Switching Technology
Beijing University of Posts and Telecommunications,
Beijing, 100876, P.R.China
EMail: zmc@bupt.edu.cn
Changqiao Xu
State Key Laboratory of Networking and Switching Technology
Beijing University of Posts and Telecommunications,
Beijing, 100876, P.R.China
EMail: cqxu@bupt.edu.cn
Hongke Zhang
State Key Laboratory of Networking and Switching Technology
Beijing University of Posts and Telecommunications,
Beijing, 100876, P.R.China
EMail: hkzhang@bupt.edu.cn
<Zhang> Expires June 12, 2014 [Page 13]
