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. 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 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 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: 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 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. 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. 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, 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. 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. 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. 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. 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 Expires June 12, 2014 [Page 13]