<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY RFC4861 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4861.xml'>
<!ENTITY RFC5222 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5222.xml'>
]>

<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc tocappendix="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="info"
     docName="draft-patil-paws-problem-stmt-02"
     ipr="trust200902"
>
  <front>
    <title abbrev="PAWS: Problem Statement">Protocol to Access White Space
    database: Problem statement</title>


      <author role="editor" initials="B" surname="Patil"
      fullname="Basavaraj Patil">
         <organization>Nokia</organization>
      <organization>Nokia</organization>
      <address>
         <postal>
            <street>6021 Connection drive</street>
            <city>Irving</city>
            <region>TX</region>
            <code>75039</code>
            <country>USA</country>
         </postal>
         <email>basavaraj.patil@nokia.com</email>
      </address>
      </author>

    <author fullname="Scott Probasco" initials="S" surname="Probasco">
      <organization>Nokia</organization>
      <address>
         <postal>
            <street>6021 Connection drive</street>
            <city>Irving</city>
            <region>TX</region>
            <code>75039</code>
            <country>USA</country>
         </postal>
         <email>scott.probasco@nokia.com</email>
      </address>
      </author>

      <author initials="G" surname="Bajko" fullname="Gabor Bajko">
         <organization>Nokia</organization>
         <address>
            <postal>
               <street>323 Fairchild drive 6</street>
	    <city>Mountain view</city>
	    <region>CA</region>
               <code>94043</code>
               <country>USA</country>
            </postal>
            <email>gabor.bajko@nokia.com</email>
         </address>
      </author>

      <author initials="B" surname="Rosen" fullname="Brian Rosen">
         <organization>Neustar</organization>
         <address>
            <postal>
               <street>470 Conrad Dr</street>
	    <city>Mars</city>
	    <region>PA</region>
               <code>16046</code>
               <country>USA</country>
            </postal>
            <email>brian.rosen@neustar.biz</email>
         </address>
      </author>




    <date year="2011" />

    <area>Operations and Management</area>

    <workgroup>Individual Submission</workgroup>
    <keyword>HTTP</keyword>
    <keyword>White Space</keyword>
    <keyword>Security</keyword>
    <keyword>TLS</keyword>
    <keyword>Protocol</keyword>

    <abstract>
     <t>
       Governments around the world continue to search for new bands
       of radio spectrum which can be used by the expanding wireless
       communications industry to provide more services in the usable spectrum. 
       The concept of allowing secondary 
       transmissions (licensed or unlicensed) in frequencies occupied by a primary 
       user is a technique to "unlock" existing spectrum for new
       use. An obvious requirement is that these secondary
       transmissions do not interfere with the primary use of the
       spectrum. One interesting observation is that often, in a given
       physical location, the primary user(s) may not be using the
       entire band allocated to them.  The available spectrum for a
       secondary use would then depend on the location of the
       secondary user.  The fundamental issue is how to 
       determine for a specific location and specific time, if any of
       the primary spectrum is available for secondary use. Academia
       and Industry have studied multiple cognitive radio mechanisms
       for use in such a scenario. One simple mechanism is to use a
       geospatial database that records the primary users occupation,
       and require the secondary users to check the database prior to
       selecting what part of the spectrum they use.  Such databases
       could be available on the Internet for query by secondary
       users. This document discusses the problems that need to be
       addressed for enabling the use of white space spectrum by
       obtaining information from such a database. 
        </t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>
	Spectrum useable for data communications, especially wireless
	Internet communications, is scarce. One area which has
	received much attention globally is the TV white space:
	portions of the TV band that are not used 
	by broadcasters in a given area. In 2008 the United States
	regulator (the FCC) took initial steps when 
	they published their first ruling on the use of TV white space,
	and then followed it up with a final ruling in
	2010<xref target="FCC ruling"/>. Finland
	passed an Act in 2009 enabling testing of cognitive radio
	systems in the TV white space. The ECC has completed Report
	159 <xref target="ECC Report 159"/>
	containing requirements for operation of cognitive radio systems
	in the TV white space.  Ofcom published in 2004 their Spectrum
	Framework Review <xref target="Spectrum Framework Review" />
	and their Digital Dividend Review <xref target="DDR"/> in 2005, 
	and have followed up with a proposal to access TV white
	space.  More countries are expected to provide access to their
	TV spectrum in similar ways.  Any entity holding spectrum that
	is not densely used may be asked to give it up in one way or
	another for more intensive use.  Providing a mechanism by
	which secondary users share the spectrum with the primary user
	is attractive in many bands in many countries.  
	</t>
      <t>
	The concept of allowing secondary transmissions
	in frequencies occupied by a primary user is a
	technique to "unlock" existing spectrum for new use. An
	obvious requirement is that these secondary 
	transmissions do not interfere with the primary 
	use of the spectrum. The fundamental issue is how to determine
	for a specific location and specific time if any of the spectrum
	is available for secondary use. There are two dimensions of
	use that may be interesting: space (the area in which a
	secondary user would not interfere with a primary user, and
	time: when the secondary use would not interfere with the
	primary use. In this discussion, we consider the time element
	to be relatively long term (hours in a day) rather than short
	term (fractions of a second).  Location in this discussion is
	geolocation: where the transmitters (and sometimes receivers)
	are located relative to one another.  In operation, the
	database records the existing user's transmitter (and some
	times receiver) locations along with basic transmission
	characteristics such as antenna height, and sometimes power.
	Using rules established by the regulator, the database
	calculates an exclusion zone for each authorized primary user,
	and attaches a time schedule to that use.  The secondary user
	queries the database with it location.  The database
	intersects the exclusion zones with the querier location, and
	returns the portion of the spectrum not in any exclusion zone.
	Such methods of geospatial database query to avoid
	interference have been shown to achieve favorable results, and
	are thus the basis for rulings by the FCC and reports from ECC
	and Ofcom. In any country, the rules for which primary
	entities are entitled to protection, how the exclusion zones
	are calculated, and what the limits of use by secondary
	entities are may vary.  However, the fundamental notion of
	recording primary users, calculating exclusion zones, querying
	by location and returning available spectrum (and the schedule
	for that spectrum) are common. 
	</t>
      <t>
	In a typical implementation of geolocation and database to
	access TV white space, a radio is configured with its
	location in latitude and longitude. There are multiple ways to
	configure this location information, e.g. programmed at
	installation (e.g. for a fixed device) or determined by GPS
	(e.g. for a or mobile device). At power-on, before the device
	can transmit in TV white space frequencies, the device must
	contact a database, provide its geolocation and receive in
	return a list of unoccupied or "white space" spectrum (for
	example, in a TV White space implementation, the list of
	available channels at that location). The 
	device can then select one of the channels from the list (note
	that it is possible they list is empty; there are no
	unoccupied channels at the location of the device) and then
	begins to transmit and receive on the selected channel. The
	device must query the database again for a list of unoccupied
	channels based on certain conditions, e.g. a fixed amount of
	time has passed, the device has changed location beyond a
	specified threshold. The basic scenario is that before
	transmitting in TV white space, the device must get permission
	from the database.
      </t>
      <t>This arrangement assumes that the device querying can
      complete a query before it transmits, or some other entity is
      able to query the database.  A common arrangement for this kind
      of service is a fixed tower with a wired infrastructure that
      provides Internet service to a network of client devices.  In
      this scenario, the tower has Internet access from its upstream
      service, and can query the database for channels within the
      tower service area.  It can then provide beacon service to its
      clients, and assign them channels within the list of channels
      that the tower gets from the database.</t> 
      <t>Another arrangement might be an ad-hoc mobile network where
      one or more members of the ad hoc network have an independent
      radio IP connection (perhaps a commercial cellular wireless data
      network) which can be used to query the database over the
      Internet.</t> 
      <t>A third possibility is a mechanism where the database is accessed
  on a private IP network.</t>  
      <t>
	The low frequencies of the TV bands (470-790 MHz) have good propagation
	characteristics. At these low frequencies, a radio signal will
	travel ~3 times further than traditional WLAN at 2.5 GHz,
	assuming the same transmit power. Because of these
	characteristics and new cognitive radio techniques, when TV
	white space becomes available, this will enable new use cases
	and new business opportunities. Not only is the capacity of
	new spectrum needed, but this propagation trait by itself
	makes TV white space attractive for providing broadband wireless access in rural,
	sparsely populated areas, as well as for extended range home
	hot-spot coverage (similar to WLAN today, but with improved
	coverage). In addition to propagation characteristics, the
	geolocation database may provide new capabilities for devices
	that use TV white space. When a device using TV white space
	registers its location in the database, this simple act makes
	the location of the device available for location based
	services.
      </t>
      <t>
	Other spectrum that might also be available for sharing using
	white space techniques exist in every country.  A great many
	primary users were allocated space a time when there were many
	fewer potential users of the space, and the primary users are
	not making efficient (in geospatial and time aspects) use of
	the space.  In the past, relocating existing primary users was
	the only feasible alternative.  Using white space techniques
	to share spectrum without imposing burdens on the primary
	users is more attractive.</t> 
      <t>
	This document discusses the problem statement related to
	enabling the "secondary" use of spectrum owned by a primary
	user without causing interference to the primary user(s). One
	approach to avoiding interference is to verify with a database
	about the available channels and spectrum at a given
	location. This document also identifies various issues that
	need to be addressed by the protocol between a white space
	device and such a database.
      </t>

    </section>

    <section title="Terminology">
      <t>
      <list style="hanging">
   <t hangText="White Space">
        <vspace blankLines="1"/>
	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. 
      </t>
      <t hangText="TV White Space">
        <vspace blankLines="1"/>
	TV white space refers specifically to radio spectrum which has
	been allocated for over the air television broadcast, but is not occupied by a TV
	broadcast, or other licensed user (such as a wireless
	microphone), at a specific location and time. 
      </t>
      <t hangText="White Space Device">
        <vspace blankLines="1"/>
        A device which is a secondary user of some part of white space spectrum.
        A white space device can be an access point, base station, a
        portable device or similar. In this context, a white space device 
        is required to query
        a database with its location to obtain information about available spectrum.
      </t>
   <t hangText="TV White Space">
        <vspace blankLines="1"/>
	TV white space refers specifically to radio spectrum which has
	been allocated for TV broadcast, but is not occupied by a TV
	broadcast, or other licensed user (such as a wireless
	microphone), at a specific location and time. 
      </t>
     <t hangText="Database">
        <vspace blankLines="1"/>
        In the context of white space and cognitive radio
        technologies, the database is an entity which contains
        current information about available spectrum at any given
        location and other types of information.
      </t>
    <t hangText="Protected Entity">
        <vspace blankLines="1"/>
	A primary user of white space spectrum which is afforded protection against interference by secondary users (white space devices( for its use in a given area and time. 
      </t>
      <t hangText="Protected Contour">
        <vspace blankLines="1"/>
	The exclusion area for a Protected Entity, held in the database and expressed as a polygon with geospatial points as the vertices. 
      </t>

      </list>
      </t>
      </section>

      <section title="Prior Work">
      <section title="The concept of Cognitive Radio">
	<t>
	  A cognitive radio uses knowledge of the local radio
	  environment to dynamically adapt its own configuration and
	  function properly in a changing radio environment. Knowledge
	  of the local radio environment can come from various
	  technology mechanisms including sensing (attempting to ascertain primary users by listening for them within the spectrum), location determination and
	  internet connectivity to a database to learn the details of
	  the local radio environment.  TV White Space is one implementation of cognitive
	  radio. Because a cognitive radio adapts itself to the
	  available spectrum in a manner that prevents the creation of
	  harmful interference, the spectrum can be shared among
	  different radio users. 
	</t>
      </section>

    <section title="Background information on white space in US">
     <t>
       Television transmission in the United States has moved to the
       use of digital signals as of June 12, 2009. Since June 13,
       2009, all full-power U.S. television stations have broadcast
       over-the-air signals in digital only. An important benefit of
       the switch to all-digital broadcasting is that it freed up
       parts of the valuable broadcast spectrum. More information
       about the switch to digital transmission is at :
       <xref target="DTV" />.
       </t>
     <t>
       With the switch to digital transmission for TV, the guard bands
       that existed to protect the signals between stations can now be
       used for other purposes. The FCC has made this spectrum
       available for unlicensed use and this is generally referred to
       as white space. Please see the details of the FCC ruling and
       regulations in <xref target="FCC ruling" />. The spectrum can
       be used to provide wireless broadband as an example. The term
       "Super-Wifi" is also used to describe this spectrum and
       potential for providing wifi type of service. 
     </t>
     </section>
     <section title = "Air Interfaces">
       <t>Efforts are ongoing to specify air-interfaces for use in white
       space spectrum. IEEEs 802.11af task group is currently working
       on one such specification. IEEE 802.22 is another
       example. Other air interfaces could be specified in the future
       such as LTE. 
       </t>

    </section>
    </section>
    <section title="Problem Statement">
	<t>
	  The use of white space spectrum is enabled via the
	  capability of a device to query a database and obtain
	  information about the availability of spectrum for
	  use at a given location. The databases are reachable via the
	  Internet and the devices querying these databases are expected
	  to have some form of Internet connectivity, directly or indirectly. The databases
	  may be country specific since the available spectrum and
	  regulations may vary, but the fundamental operation of the protocol should be country independent.
	  </t>
	  <t>
	    An example high-level architecture of the devices and
	    white space databases is shown in the figure below:

	    <figure title="High level view of the White space database
	    architecture"
                anchor="fig:architecture">
        <artwork><![CDATA[


	-----------
	|WS Device|				 ------------
       	|Lat: X	  |\   	       .---.	/--------|Database X|
        |Long: Y  | \  	      (	    )  /	 ------------
	-----------  \-------/	     \/	       	      o
			   ( Internet )		      o
	-----------  /------(  	     )\	       	      o
	|WS Device| /  	      (_____)  \       	 ------------
       	|Lat: X	  |/ 	       		\--------|Database Y|
        |Long: Y  |				 ------------
	-----------

      ]]></artwork></figure>						      
      </t>								      

	  <t>
	    In the figure above, note that there could be multiple
	    databases serving white space devices. The databases are
	    country specific since the regulations and available
	    spectrum may vary. In some countries, for example, the U.S., the regulator has determined that multiple, competing databases may provide service to White Space Devices.
	    </t>
	  <t>
	    A messaging interface between the white space devices and
	    the database is required for operating a network using the
	    white space spectrum. The following sections discuss
	    various aspects of such an interface and the need for a
	    standard. Other aspects of a solution including
	    provisioning the database, and calculating protected
	    contours are considered out of scope of the initial
	    effort, as there are significant differences between
	    countries and spectrum bands. 
	  </t>

	  <section title="Global applicability">
	    <t>
	      The use of TV white space spectrum is currently approved
	      by the FCC in the United States. However 
	      regulatory bodies in other countries are also
	      considering similar use of available spectrum. The
	      principles of cognitive radio usage for such spectrum is
	      generally the same. Some of the regulatory details 
	      may vary on a country specific basis. However the need for
	      devices that intend to use the spectrum to communicate
	      with a database remains a common feature.  The database
	      provides a known, specifiable Protection Contour for the
	      primary user, not dependent on the characteristics of
	      the White Space Device or it's ability to sense the
	      primary use.  It also provides a way to specify a
	      schedule of use, because some primary users (for
	      example, wireless microphones) only operate in limited
	      time slots. 
	    </t>
	    <t>
	      Devices need to be able to query a database, directly or
	      indirectly over the public Internet and/or private IP
	      networks prior to operating in 
	      available spectrum. Information about available
	      spectrum, schedule, power, etc. are provided by the
	      database as a response to the query from a device. 
	      The messaging interface needs to be:
	    </t>
	    <t>
	    <list style="numbers">
	      <t>Radio/air interface agnostic - The radio/air
	      interface technology used by the white space device in
	      available spectrum can be 802.11af, 802.16, 802.22, LTE
	      etc. However the messaging interface between the white
	      space device and the database should be agnostic to the
	      air interface while being cognizant of the
	      characteristics of various air-interface technologies
	      and the need to include relevant attributes in the query
	      to the database.
	      </t>
              <t>Spectrum agnostic - the spectrum used by primary and
              secondary users varies by country.  Some spectrum has an
              explicit notion of a "channel" a defined swath of
              spectrum within a band that has some assigned
              identifier.  Other spectrum bands may be subject to
              white space sharing, but only have actual frequency
              low/high parameters to define protected entity use.  The
              protocol should be able to be used in any spectrum band
              where white space sharing is permitted.</t> 
	      <t>Globally applicable - A common messaging interface
	      between white space devices and databases will enable
	      the use of such spectrum for various purposes on a
	      global basis. Devices can operate in any country where
	      such spectrum is available and a common interface
	      ensures uniformity in implementations and deployment.
	      Since the White Space device must know it's geospatial
	      location to do a query, it is possible to determine
	      which database, and which rules, are applicable, even
	      though they are country specific. 
	      </t>
	      <t>Address regulatory requirements - Each country will
	      likely have regulations that are unique to that
	      country. The messaging interface needs to be flexible to
	      accommodate the specific needs of a regulatory body in
	      the country where the white space device is operating
	      and connecting to the relevant database.
	      </t>
	    </list>
	    </t>
	  </section>

	  <section title="Database discovery">
	    <t>
	      Another aspect of the problem space is the need to
	      discover the database. A white space device needs to
	      find the relevant database to query based on its current
	      location or for another location. Since the spectrum and
	      databases are country specific, the device will need to
	      discover the relevant database. The device needs to
	      obtain the IP address of the specific database to which
	      it can send queries in addition to registering itself
	      for operation and using the available spectrum.  
	    </t>
	    <t>
	      A database discovery mechanism needs to be
	      specified. Reuse of existing mechanisms is an option and
	      could be adapted for meeting the specific needs of
	      cognitive radio technology. 
	    </t>
	  </section>

	  <section title="Data model definition">
	    <t>
	      The contents of the queries and response need to be
	      specified. A data model is required which enables the
	      white space device to query the database while including
	      all the relevant information such as geolocation, radio
	      technology, power characteristics, etc which may be country and spectrum dependent. All databases
	      are able to interpret the data model and respond to the
	      queries using the same data model that is understood by
	      all devices. 
	    </t>
	    <t>
	      Use of XML for specifying a data model is an attractive
	      option. The intent is to evaluate the best option that
	      meets the need for use between white space devices and databases.
	    </t>
	    
	  </section>
          <section title="Protocol">
    <t>
     The protocol requirements are simple: registration and query
     transactions are needed.   In some circumstances, a registration
     transaction is required prior to being able to query.  The device
     provides some identifying information, and the database responds
     with an acknowledgement or error.  The query protocol is a simple
     query/response action (primarily location in, available spectrum
     out), with some error conditions.</t> 
<t>It may be possible to use existing protocols (e.g. LoST
  <xref target="RFC5222"/>) or it may be more appropriate to define a
  new protocol for this purpose.  HTTP transport is probably
  appropriate.</t> 
       </section>
    </section>
    <section anchor="IANA" title="IANA Considerations">
      <t>This document has no requests to IANA.
      </t>
    </section>

    <section anchor="Security" title="Security Considerations">
	    <t>
	      The messaging interface between the white space device
	      and the database needs to be secured. Both the queries
	      and the responses need to be delivered securely. The
	      device must be certain it is talking to a bona fide
	      database authoritative for the location and spectrum
	      band the device operates on.  The database may need to
	      restrict interactions to devices that it has some prior
	      relationship with, or may be restricted from providing
	      service to devices that are not authorized in some
	      manner.</t> 
	    <t>As the device will query with it's location, the
	    location must be protected against eavesdropping.  Some
	    regulations include personally identifiable information as
	    required elements of registration and/or query and must
	    similarly be protected.</t> 
	    <t>All communications between the device and the database
	    will require integrity protection. 
	    </t>
	    <t>
	      Man-in-the-middle attacks could modify the content of a
	      response which can cause problems for other networks or
	      devices operating at a given location. Interference as
	      well as total loss of service could result from
	      malicious information being delivered to a white space
	      device. 
	    </t><t>
	      This
         document describes the problems
         that need to be addressed for a messaging interface between
         white space devices and databases and does not by itself
         raise any security concerns.
      </t>
    </section>

<section title="Summary">
  <t>
    Wireless spectrum is a scarce resource. As the demand for spectrum
    grows, there is a need to more efficiently utilize the available
    and allocated spectrum. Cognitive radio technologies enable the
    efficient usage of spectrum via means such as sensing or by
    querying a database to determine available spectrum at a given
    locaion for secondary use. White space is the general term used to
    refer to the bands within the spectrum which is available for
    secondary use at a given location. In order to use this spectrum a
    device needs to query a database which maintains information about
    the available channels within a band. A protocol is necessary for
    communication between the devices and databases which would be
    globally applicable.
  </t>
</section>

<section title="Acknowledgments">
  <t>
    Thanks to ABC, PQR and XYZ for their comments and input which have
    helped in improving this document.
  </t>
</section>

  </middle>




  <back>
    <references title="Informative References">

      <reference anchor='FCC ruling'>
	<front>
	  <title>Unlicensed Operation in the TV Broadcast
	  Bands;
	  http://edocket.access.gpo.gov/2010/pdf/2010-30184.pdf </title>
	  <author><organization>Federal Communications
	  Commission</organization></author> 
	  <date day='6' month='December' year='2010' />
	  </front>
	    
	<format type='PDF'
		target='http://edocket.access.gpo.gov/2010/pdf/2010-30184.pdf' />
	</reference>

      <reference anchor='ECC Report 159'>
	<front>
	  <title>TECHNICAL AND OPERATIONAL REQUIREMENTS FOR THE
	  POSSIBLE OPERATION OF COGNITIVE RADIO SYSTEMS IN THE 'WHITE
	  SPACES' OF THE FREQUENCY BAND 470-590 MHZ; http://www.erodocdb.dk/Docs/doc98/official/pdf/ECCREP159.PDF  </title>

	  <author><organization>Electronic Communications Committee (ECC)
within the European Conference of Postal and Telecommunications
	      Administrations (CEPT)</organization> </author>
	  <date month='January' year='2011' />
	  </front>
	  <format type='PDF'
		  target='http://www.erodocdb.dk/Docs/doc98/official/pdf/ECCREP159.PDF'  
		  />
	  </reference>

      <reference anchor='Spectrum Framework Review'>
	<front>
	  <title>Spectrum Framework Review;
	  http://stakeholders.ofcom.org.uk/consultations/sfr/ </title>
	  <author><organization>Ofcom - Independent regulator and
	  competition authority for the UK communications
	  industries</organization></author> 
	  <date day='15' month='February' year='2005' />
	  </front>
	<format type='HTML'
		target='http://stakeholders.ofcom.org.uk/consultations/sfr/'
		/>
	</reference>

      <reference anchor='DDR'>
	<front>
	  <title>Digital Dividend Review; http://stakeholders.ofcom.org.uk/spectrum/project-pages/ddr/ </title>
	  <author><organization>Ofcom - Independent regulator and
	  competition authority for the UK communications
	  industries</organization></author> 
	</front>
	<format type='HTML'
		      target='http://stakeholders.ofcom.org.uk/spectrum/project-pages/ddr/'
		      />
		      </reference>
      <reference anchor='DTV'>
	<front>
	<title>Digital TV Transition; http://www.dtv.gov</title>
	</front>
	<format type='HTML'
		target='http://www.dtv.gov' />
	</reference>
     &RFC5222;
    </references>
  </back>
</rfc>
