draft-ietf-paws-problem-stmt-usecases-rqmts-00.txt   draft-ietf-paws-problem-stmt-usecases-rqmts-01.txt 
Working Group Draft S. Probasco, Ed. Working Group Draft S. Probasco, Ed.
Internet-Draft G. Bajko Internet-Draft B. Patil
Intended status: Informational B. Patil Intended status: Informational Nokia
Expires: March 12, 2012 Nokia Expires: May 3, 2012 October 31, 2011
B. Rosen
Neustar
September 9, 2011
Protocol to Access White Space database: PS, use cases and rqmts Protocol to Access White Space database: PS, use cases and rqmts
draft-ietf-paws-problem-stmt-usecases-rqmts-00 draft-ietf-paws-problem-stmt-usecases-rqmts-01
Abstract Abstract
Portions of the radio spectrum that are allocated to a licensed, Portions of the radio spectrum that are allocated to a licensed,
primary user but are unused or unoccupied at specific locations and primary user but are unused or unoccupied at specific locations and
times are defined as "white space". The concept of allowing times are defined as "white space". The concept of allowing
secondary transmissions (licensed or unlicensed) in white space is a secondary transmissions (licensed or unlicensed) in white space is a
technique to "unlock" existing spectrum for new use. An obvious technique to "unlock" existing spectrum for new use. An obvious
requirement is that these secondary transmissions do not interfere requirement is that these secondary transmissions do not interfere
with the primary use of the spectrum. One approach to using the with the primary use of the spectrum. One approach to using the
skipping to change at page 1, line 49 skipping to change at page 1, line 46
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 12, 2012. This Internet-Draft will expire on May 3, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
skipping to change at page 2, line 22 skipping to change at page 3, line 7
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 5 1.1. Introduction to TV white space . . . . . . . . . . . . . . 4
2.1. Conventions Used in This Document . . . . . . . . . . . . 5 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 1.2.1. In Scope . . . . . . . . . . . . . . . . . . . . . . . 6
3. Prior Work . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.2.2. Out of Scope . . . . . . . . . . . . . . . . . . . . . 6
3.1. The concept of Cognitive Radio . . . . . . . . . . . . . . 6 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 6
3.2. Background information on white space in US . . . . . . . 6 2.1. Conventions Used in This Document . . . . . . . . . . . . 7
3.3. Air Interfaces . . . . . . . . . . . . . . . . . . . . . . 7 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7
4. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Prior Work . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. TVWS database discovery . . . . . . . . . . . . . . . . . 7 3.1. The concept of Cognitive Radio . . . . . . . . . . . . . . 8
4.2. Hotspot: urban internet connectivity service . . . . . . . 8 3.2. Background information on white space in US . . . . . . . 8
4.3. Wide-Area or Rural internet broadband access . . . . . . . 10 3.3. Air Interfaces . . . . . . . . . . . . . . . . . . . . . . 9
4.4. Offloading: moving traffic to a white space network . . . 12 4. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.5. TVWS for backhaul . . . . . . . . . . . . . . . . . . . . 14 4.1. TVWS database discovery . . . . . . . . . . . . . . . . . 9
4.6. Location based service usage scenario . . . . . . . . . . 15 4.2. Device registration with trusted Database . . . . . . . . 10
4.7. Rapid deployed network for emergency scenario . . . . . . 17 4.3. Hotspot: urban internet connectivity service . . . . . . . 11
5. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 18 4.4. Wide-Area or Rural internet broadband access . . . . . . . 13
5.1. Global applicability . . . . . . . . . . . . . . . . . . . 19 4.5. Offloading: moving traffic to a white space network . . . 15
5.2. Database discovery . . . . . . . . . . . . . . . . . . . . 21 4.6. TVWS for backhaul . . . . . . . . . . . . . . . . . . . . 17
5.3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 21 4.7. Rapid deployed network for emergency scenario . . . . . . 18
5.4. Data model definition . . . . . . . . . . . . . . . . . . 21 4.8. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . 19
6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 21 4.9. Indoor Networking . . . . . . . . . . . . . . . . . . . . 21
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 4.10. Machine to Machine (M2M) . . . . . . . . . . . . . . . . . 23
8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 5. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 24
9. Summary and Conclusion . . . . . . . . . . . . . . . . . . . . 22 5.1. Global applicability . . . . . . . . . . . . . . . . . . . 25
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 5.2. Database discovery . . . . . . . . . . . . . . . . . . . . 26
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 5.3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 27
11.1. Normative References . . . . . . . . . . . . . . . . . . . 23 5.4. Data model definition . . . . . . . . . . . . . . . . . . 27
11.2. Informative References . . . . . . . . . . . . . . . . . . 23 6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
8. Security Considerations . . . . . . . . . . . . . . . . . . . 30
9. Summary and Conclusion . . . . . . . . . . . . . . . . . . . . 31
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
11.1. Normative References . . . . . . . . . . . . . . . . . . . 31
11.2. Informative References . . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33
1. Introduction 1. Introduction
1.1. Introduction to TV white space
Wireless spectrum is a commodity that is regulated by governments. Wireless spectrum is a commodity that is regulated by governments.
The spectrum is used for various purposes, which include The spectrum is used for various purposes, which include
entertainment (e.g. radio and television), communication (telephony entertainment (e.g. radio and television), communication (telephony
and Internet access), military (radars etc.) and, navigation and Internet access), military (radars etc.) and, navigation
(satellite communication, GPS). Portions of the radio spectrum that (satellite communication, GPS). Portions of the radio spectrum that
are allocated to a licensed, primary user but are unused or are allocated to a licensed, primary user but are unused or
unoccupied at specific locations and times are defined as "white unoccupied at specific locations and times are defined as "white
space". The concept of allowing secondary transmissions (licensed or space". The concept of allowing secondary transmissions (licensed or
unlicensed) in white space is a technique to "unlock" existing unlicensed) in white space is a technique to "unlock" existing
spectrum for new use. An obvious requirement is that these secondary spectrum for new use. An obvious requirement is that these secondary
skipping to change at page 5, line 14 skipping to change at page 6, line 16
are calculated, and what the limits of use by secondary entities are are calculated, and what the limits of use by secondary entities are
may vary. However, the fundamental notion of recording primary may vary. However, the fundamental notion of recording primary
users, calculating exclusion zones, querying by location and users, calculating exclusion zones, querying by location and
returning available spectrum (and the schedule for that spectrum) are returning available spectrum (and the schedule for that spectrum) are
common common
This document includes the problem statement, use cases and This document includes the problem statement, use cases and
requirements associated with the use of white space spectrum by requirements associated with the use of white space spectrum by
secondary users via a database query protocol. secondary users via a database query protocol.
2. Conventions and Terminology 1.2. Scope
1.2.1. In Scope
This document applies only to communications required for basic
service in TV white space. The protocol will enable a white space
radio device to complete the following tasks:
1. Determine the relevant white space database to query.
2. Connect to the database using a well-defined access method.
3. Register with the database using a well-defined protocol.
4. Provide its geolocation and perhaps other data to the database
using a well-defined format for querying the database.
5. Receive in return a list of currently available white space using
a well-defined format for returning information.
As a result, some of the scenarios described in the following section
are out of scope for this specification (although they might be
addressed by future specifications).
1.2.2. Out of Scope
The following topics are out of scope for this specification:
TBD
2. Conventions and Terminology
2.1. Conventions Used in This Document 2.1. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2.2. Terminology 2.2. Terminology
Database Database
In the context of white space and cognitive radio technologies, In the context of white space and cognitive radio technologies,
the database is an entity which contains current information about the database is an entity which contains current information about
available spectrum at any given location and other types of available spectrum at any given location and other types of
information. information.
Device ID
A unique number for each master device and slave device that
identifies the manufacturer, model number and serial number.
Location Based Service Location Based Service
An application or device which provides data, information or An application or device which provides data, information or
service to a user based on their location. service to a user based on their location.
Master Device Master Device
A device which queries the WS Database to find out the available A device which queries the WS Database to find out the available
operating channels. operating channels.
skipping to change at page 6, line 23 skipping to change at page 8, line 18
been allocated for TV broadcast, but is not occupied by a TV been allocated for TV broadcast, but is not occupied by a TV
broadcast, or other licensed user (such as a wireless microphone), broadcast, or other licensed user (such as a wireless microphone),
at a specific location and time. at a specific location and time.
White Space White Space
Radio spectrum which has been allocated for some primary use, but Radio spectrum which has been allocated for some primary use, but
is not fully occupied by that primary use at a specific location is not fully occupied by that primary use at a specific location
and time. and time.
White Space Device White Space Device (WSD)
A device which is a secondary user of some part of white space A device which is a secondary user of some part of white space
spectrum. A white space device can be an access point, base spectrum. A white space device can be an access point, base
station, a portable device or similar. In this context, a white station, a portable device or similar. In this context, a white
space device is required to query a database with its location to space device is required to query a database with its location to
obtain information about available spectrum. obtain information about available spectrum.
3. Prior Work 3. Prior Work
3.1. The concept of Cognitive Radio 3.1. The concept of Cognitive Radio
skipping to change at page 7, line 42 skipping to change at page 9, line 38
traffic lights or read utility meters. Still other use cases include traffic lights or read utility meters. Still other use cases include
the ability to offload data traffic from another internet access the ability to offload data traffic from another internet access
network (e.g. 3G cellular network) or to deliver location based network (e.g. 3G cellular network) or to deliver location based
services. Some of these use cases are described in the following services. Some of these use cases are described in the following
sections. sections.
4.1. TVWS database discovery 4.1. TVWS database discovery
This use case is preliminary to creating a radio network using TV This use case is preliminary to creating a radio network using TV
white space; it is a prerequisite to other use cases. The radio white space; it is a prerequisite to other use cases. The radio
network is created by a master device which can be an access point network is created by a master device. Before the master device can
that establishes Hotspot coverage, a base station that establish transmit in TV white space spectrum, it must contact a trusted
cellular coverage, or a device that establishes a peer-to-peer or ad- database where the device can learn if any channels are available for
hoc network. Before the master device can transmit in TV white space it to use. The master device will need to discover a trusted
spectrum, it must contact a trusted database where the device can database in the relvant regulatory domain, using the following steps:
learn if any channels are available for it to use.
In the simplest case the radio device is pre-programmed with the 1. The master device is connected to the internet by any means other
internet address of at least one trusted database. The device can than using the TV white space radio.
establish contact with a trusted database using one of the pre-
programmed internet addresses and establish a TV white space network
(as described in one of the following use cases).
If the radio device (master) does not have a pre-programmed address 2. The master device constructs and sends a service request over the
for a trusted white space database, or if the trusted database at the Internet to discover availability of trusted databases in the
pre-programmed address is not responsive, or perhaps the trusted local domain and waits for responses.
database does not provide service for the radio device's current
location, or at the user's choice, the device may attempt to
"discover" a trusted database which provides service at the current
location.
1. The master is connected to the internet by any means other than 3. If no acceptable response is received within a pre-configured
using the TV white space radio. time limit, the master device concludes that no trusted database
is available. If at least one response is received, the master
device evaluates the response(s) to determine if a trusted
database can be identified where the master device is able to
register and receive service from the database.
2. The master constructs and broadcasts a query message over the Optionally the radio device is pre-programmed with the internet
internet and waits for responses. address of at least one trusted database. The device can establish
contact with a trusted database using one of the pre-programmed
internet addresses and establish a TV white space network (as
described in one of the following use cases).
3. If no acceptable response is received within a pre-configured Optionally the initial query will be made to a listing approved by
time limit, the device concludes that no trusted database is the national regulator for the domain of operation (e.g. a website
available. If one or more response is received, the device either hosted by or under control of the national regulator) which
evaluates the response to determine if a trusted database can be maintains a list of TVWS databases and their internet addresses. The
identified where the device is able to register and receive query results in the list of databases and their internet addresses
service from the database. being sent to the master, which then evaluates the repsonse to
determine if a trusted database can be identified where the master
device is able to register and receive service from the database.
4.2. Hotspot: urban internet connectivity service 4.2. Device registration with trusted Database
This use case is preliminary to creating a radio network using TV
white space; it is a prerequisite to other use cases. The radio
network is created by a master device. Before the master device can
transmit in TV white space spectrum, it must contact a trusted
database where the device can learn if any channels are available for
it to use. Before the database will provide information on available
TV channels, the master device must register with the trusted
database. Specific requirements for registration come from
individual regulatory domains and may be different.
The figure below shows an example deployment of this scenario.
\|/ ----------
| |Database|
| .---. /---------
|-|---------| ( ) /
\|/ | Master | / \
| / | |========( Internet )
| / |-----------| \ /
+-|----+ (TDD AirIF) ( )
|Master| / (----)
| | /
+------+
Figure 2: Example illustration of registration requirement in TV
white space use-case
A simplified operational scenario showing registration consists of
the following steps:
1. The master device must register with the most current and up-to-
date information. Typically the master device will register
prior to operating in TV white space for the first time after
power up, after changing location by a predetermined distance,
and after regular time intervals.
2. The master device shall provide to the database during
registration a minimum of the Device ID, serial number assigned
by the manufacturer and the device's location.
3. Depending upon regulatory domain requirements, the device may
also provide device antenna height above ground, name of the
individual or business that owns the device, name of a contact
person responsible for the device's operation, address for the
contact person, email address for the contact person and phone
number of the contact person to the database during registration.
4.3. Hotspot: urban internet connectivity service
In this use case internet connectivity service is provided in a In this use case internet connectivity service is provided in a
"hotspot" to local users. Typical deployment scenarios include urban "hotspot" to local users. Typical deployment scenarios include urban
areas where internet connectivity is provided to local businesses and areas where internet connectivity is provided to local businesses and
residents, and campus environments where internet connectivity is residents, and campus environments where internet connectivity is
provided to local buildings and relatively small outdoor areas. This provided to local buildings and relatively small outdoor areas. This
deployment scenario is typically characterized by multiple masters deployment scenario is typically characterized by multiple masters
(APs or hotspots) in close proximity, with low antenna height, cells (APs or hotspots) in close proximity, with low antenna height, cells
with relatively small radius (a few kilometers or less), and limited with relatively small radius (a few kilometers or less), and limited
numbers of available radio channels. Many of the masters/APs are numbers of available radio channels. Many of the masters/APs are
assumed to be individually deployed and operated, i.e. there is no assumed to be individually deployed and operated, i.e. there is no
coordination between many of the masters/APs. The masters/APs in coordination between many of the masters/APs. The masters/APs in
this scenario use a TDD radio technology and transmit at or below a this scenario use a TDD radio technology and transmit at or below a
relatively low transmit power threshold. Each master/AP has a relatively low transmit power threshold. Each master/AP has a
connection to the internet and provides internet connectivity to connection to the internet and provides internet connectivity to
multiple end user or slave devices. multiple master and or slave devices.
The figure below shows an example deployment of this scenario. The figure below shows an example deployment of this scenario.
------- --------
|Slave|\ \|/ ---------- |Device|\ \|/ ----------
|Dev 1| (TDD AirIF) | |Database| | 1 | (TDD AirIF) | |Database|
------- \ | .---. /--------- -------- \ | .---. /---------
o \ |-|---------| ( ) / o \ |-|---------| ( ) /
o | Master | / \ o | Master | / \
o / | |========( Internet ) o / | |========( Internet )
o / |-----------| \ / o / |-----------| \ /
------- (TDD AirIF) ( ) -------- (TDD AirIF) ( )
|Slave| / (----) |Device| / (----)
|Dev n| | n |
------- --------
Figure 2: Hotspot service using TV white space spectrum Figure 3: Hotspot service using TV white space spectrum
Once a master/AP has been correctly installed and configured, a Once a master/AP has been correctly installed and configured, a
simplified power up and operation scenario utilizing TV White Space simplified power up and operation scenario utilizing TV White Space
to provide Internet connectivity service consists of the following to provide Internet connectivity service consists of the following
steps: steps:
1. The master/AP powers up; however its WS radio and all other WS 1. The master/AP powers up; however its WS radio and all other WS
capable devices will power up in idle/listen only mode (no active capable devices will power up in idle/listen only mode (no active
transmissions on the WS frequency band). transmissions on the WS frequency band).
2. The master/AP has Internet connectivity and establishes a 2. The master/AP has Internet connectivity and establishes a
connection to a trusted white space database (see use case "TVWS connection to a trusted white space database (see Section 4.1).
database discovery" above).
3. The master/AP registers its geolocation, address, contact 3. The master/AP registers with the trusted database according to
information, etc. associated with the owner/operator of the regulatory domain requirements (see Section 4.2).
master/AP with the trusted database administrator (if not
currently registered). Depending upon local regulator policy,
the DB administrator may be required to store and forward the
registration information to the regulatory authority.
4. Following the registration process, the master/AP will send a 4. Following the registration process, the master/AP will send a
query to the trusted database requesting a list of available WS query to the trusted database requesting a list of available WS
channels based upon its geolocation. channels based upon its geolocation.
5. If the master/AP has been previously authenticated, the database 5. If the master/AP has met all regulatory domain requirements (e.g.
responds with a list of available white space channels that the been previously authenticated, etc), the database responds with a
master may use, and optionally a duration of time for their use. list of available white space channels that the master may use,
and optionally a duration of time for their use.
6. Once the master/AP authenticates the WS channel list response
message from the database, the AP selects an available WS
channel(s) from the list.
7. The master/AP acknowledges to the database which of the available 6. Once the master/AP has met all regulatory domain requirements
WS channels it has selected for its operation. The database is (e.g. authenticated the WS channel list response message from the
updated with the information provided by the master/AP. database, etc), the AP selects an available WS channel(s) from
the list.
8. The slave or user device scans the TV bands to locate a master/AP 7. The slave or user device scans the TV bands to locate a master/AP
transmission, and associates with the AP. The slave/user device transmission, and associates with the AP. The slave/user device
queries the master for a channel list, based on the slaves' queries the master for a channel list, providing to the master
geolocation. the slaves' Device ID and geolocation.
9. The master provides the list of channels locally available to the 8. Once the master/AP has met all regulatory domain requirements
(e.g. validating the Device ID with the trusted database, etc)
the master provides the list of channels locally available to the
slave/user device. If the channel that the user terminal is slave/user device. If the channel that the user terminal is
currently using is not included in the list of locally available currently using is not included in the list of locally available
channels, the slave/user device ceases all operation on its channels, the slave/user device ceases all operation on its
current channel. The slave/user device may scan for another AP current channel. The slave/user device may scan for another AP
transmission on a different channel. transmission on a different channel.
4.3. Wide-Area or Rural internet broadband access 4.4. Wide-Area or Rural internet broadband access
In this use case, internet broadband access is provided as a Wide- In this use case, internet broadband access is provided as a Wide-
Area Network (WAN) or Wireless Regional Area Network (WRAN). A Area Network (WAN) or Wireless Regional Area Network (WRAN). A
typical deployment scenario is a wide area or rural area, where typical deployment scenario is a wide area or rural area, where
internet broadband access is provided to local businesses and internet broadband access is provided to local businesses and
residents from a master (i.e. BS) connected to the internet. This residents from a master (i.e. BS) connected to the internet. This
deployment scenario is typically characterized by one or more fixed deployment scenario is typically characterized by one or more fixed
master(s)/BS(s), cells with relatively large radius (tens of master(s)/BS(s), cells with relatively large radius (tens of
kilometers, up to 100 km), and a number of available radio channels. kilometers, up to 100 km), and a number of available radio channels.
Some of the masters/BSs may be deployed and operated by a single Some of the masters/BSs may be deployed and operated by a single
skipping to change at page 11, line 18 skipping to change at page 14, line 18
------- \ | .---. /---------- ------- \ | .---. /----------
o \ |-|---------| ( ) / o \ |-|---------| ( ) /
o | Master | / \ o | Master | / \
o / | (BS) |========( Internet ) o / | (BS) |========( Internet )
o / |-----------| \ / o / |-----------| \ /
------- (TDD AirIF) ( ) ------- (TDD AirIF) ( )
|Slave| / (----) |Slave| / (----)
|Dev n| |Dev n|
------- -------
Figure 3: Rural internet broadband access using TV white space Figure 4: Rural internet broadband access using TV white space
spectrum spectrum
Once the master/BS has been professionally installed and configured, Once the master/BS has been professionally installed and configured,
a simplified power up and operation scenario utilizing TV White Space a simplified power up and operation scenario utilizing TV White Space
to provide rural internet broadband access consists of the following to provide rural internet broadband access consists of the following
steps: steps:
1. The master/BS powers up; however its WS radio and all other WS 1. The master/BS powers up; however its WS radio and all other WS
capable devices will power up in idle/listen only mode (No active capable devices will power up in idle/listen only mode (No active
transmissions on the WS frequency band) transmissions on the WS frequency band)
2. The master/BS has internet connectivity and establishes a 2. The master/BS has internet connectivity and establishes a
connection to a trusted white space database (see use case "TVWS connection to a trusted white space database (see use case "TVWS
database discovery" above). database discovery" above).
3. The master/BS registers its geolocation, address, contact 3. The master/BS registers its geolocation, address, contact
information, etc. associated with the owner/operator of the information, etc. associated with the owner/operator of the
master/BS with the trusted database service (if not currently master/BS with the trusted database service (if not currently
registered). Meanwhile the DB administrator may be required to registered, see Section 4.2). Meanwhile the DB administrator may
store and forward the registration information to the regulatory be required to store and forward the registration information to
authority. If a trusted white space database administrator is the regulatory authority. If a trusted white space database
not discovered, further operation of the WRAN may be allowed administrator is not discovered, further operation of the WRAN
according to local regulator policy (in this case operation of may be allowed according to local regulator policy (in this case
the WRAN is outside the scope of the PAWS protocol). operation of the WRAN is outside the scope of the PAWS protocol).
4. Following the registration process, the master/BS will send a 4. Following the registration process, the master/BS will send a
query to the trusted database requesting a list of available WS query to the trusted database requesting a list of available WS
channels based upon its geolocation. channels based upon its geolocation.
5. If the master/BS has been previously authenticated, the database 5. If the master/BS has been previously authenticated, the database
responds with a list of available white space channels that may responds with a list of available white space channels that may
be used and optionally a maximum transmit power (EIRP) for each be used and optionally a maximum transmit power (EIRP) for each
channel and a duration of time the channel may be used. channel and a duration of time the channel may be used.
6. Once the master/BS authenticates the WS channel list response 6. Once the master/BS authenticates the WS channel list response
message from the database, the master/BS selects an available WS message from the database, the master/BS selects an available WS
channel(s) from the list. The operator may disallow some channel(s) from the list. The operator may disallow some
channels from the list to suit local needs if required. channels from the list to suit local needs if required.
7. The master/BS acknowledges to the database which of the available 7. The slave or user device scans the TV bands to locate a WRAN
WS channels the BS has selected for its operation. The database
is updated with the information provided by the BS.
8. The slave or user device scans the TV bands to locate a WRAN
transmission, and associates with the master/BS. The slave/user transmission, and associates with the master/BS. The slave/user
device provides its geolocation to the BS which, in turn, queries device provides its geolocation to the BS which, in turn, queries
the database for a list of channels available at the slaves' the database for a list of channels available at the slaves'
geolocation. geolocation.
9. Once this list of available channels is received from the 8. Once this list of available channels is received from the
database by the master, the latter will decide, based on the list database by the master, the latter will decide, based on the list
of available channels for all its other associated slaves whether of available channels for all its other associated slaves whether
it should continue operation on its current channel or change it should continue operation on its current channel or change
channel to accommodate the new slave in case this channel is not channel to accommodate the new slave in case this channel is not
available at its location. The master will notify all its available at its location. The master will notify all its
associated slaves/user devices of the new channel to move to if associated slaves/user devices of the new channel to move to if
operation needs to change channel. If the channel that the user operation needs to change channel. If the channel that the user
terminal is currently using is not included in the list of terminal is currently using is not included in the list of
locally available channels, the master will drop its association locally available channels, the master will drop its association
with the slave/user device so that it ceases all operation on its with the slave/user device so that it ceases all operation on its
current channel and indicate the new operating channel before current channel and indicate the new operating channel before
dropping the link if a change has been decided. The slave/user dropping the link if a change has been decided. The slave/user
device may move to the indicated new channel if so indicated or device may move to the indicated new channel if so indicated or
scan for another WRAN transmission on a different channel. scan for another WRAN transmission on a different channel.
4.4. Offloading: moving traffic to a white space network 4.5. Offloading: moving traffic to a white space network
In this use case internet connectivity service is provided over TV In this use case internet connectivity service is provided over TV
white space as a supplemental or alternative datapath to a 3G or white space as a supplemental or alternative datapath to a 3G or
other internet connection. In a typical deployment scenario an end other internet connection. In a typical deployment scenario an end
user has a primary internet connection such as a 3G cellular packet user has a primary internet connection such as a 3G cellular packet
data subscription. The user wants to use a widget or application to data subscription. The user wants to use a widget or application to
stream video from an online service (e.g. youtube) to their device. stream video from an online service (e.g. youtube) to their device.
Before the widget starts the streaming connection it checks Before the widget starts the streaming connection it checks
connectivity options available at the current time and location. connectivity options available at the current time and location.
Both 3G cellular data is available as well as TVWS connectivity (the Both 3G cellular data is available as well as TVWS connectivity (the
skipping to change at page 13, line 32 skipping to change at page 16, line 28
-------- / \ ----------- -------- / \ -----------
|Slave/| / \ (----) | Database | |Slave/| / \ (----) | Database |
|WS Dev| \ ( ) /---------- |WS Dev| \ ( ) /----------
------- \ \ / \ ------- \ \ / \
\ X( Internet ) \ X( Internet )
\ / \ / \ / \ /
Signaling \|/ / ( )\ Signaling \|/ / ( )\
\ | / (----) \---------- \ | / (----) \----------
\ | / | YouTube | \ | / | YouTube |
\|-|---------| / ---------- \|-|---------| / ----------
| Master / | / | | /
| 3G BTS |/ | 3G BTS |/
|-----------| |-----------|
Figure 4: Offloading: moving traffic to a white space network Figure 5: Offloading: moving traffic to a white space network
Once a dual or multi mode device (3G + TVWS) is connected to a 3G Once a dual or multi mode device (3G + TVWS) is connected to a 3G
network, a simplified operation scenario of offloading selected network, a simplified operation scenario of offloading selected
content such as video stream from the 3G connection to the TWVS content such as video stream from the 3G connection to the TWVS
connection consists of the following steps: connection consists of the following steps:
1. The dual mode (or multi mode) device (3G + TVWS) is connected to 1. The dual mode (or multi mode) device (3G + TVWS) is connected to
a 3G network. The device has contacted a trusted database to a 3G network. The device has contacted a trusted database to
discover the list of available TV channels at its current discover the list of available TV channels at its current
location. The device has located a TVWS master/AP operating on location. The device has located a TVWS master/AP operating on
skipping to change at page 14, line 19 skipping to change at page 17, line 14
3. The user selects a video for streaming using the widget's 3. The user selects a video for streaming using the widget's
controls. Before the widget initiates a streaming session, the controls. Before the widget initiates a streaming session, the
widget checks the available connections in the dual mode device widget checks the available connections in the dual mode device
and finds a TVWS master/AP is connected. and finds a TVWS master/AP is connected.
4. Using either input from the user or pre-defined profile 4. Using either input from the user or pre-defined profile
preferences, the widget selects the TVWS master/AP as the preferences, the widget selects the TVWS master/AP as the
connection to stream the video. connection to stream the video.
4.5. TVWS for backhaul 4.6. TVWS for backhaul
In this use case internet connectivity service is provided to users In this use case internet connectivity service is provided to users
over a traditional wireless protocol, one common example is Wi-Fi. over a traditional wireless protocol, one common example is Wi-Fi.
The TV white space network provides the "backhaul" or connection from The TV white space network provides the "backhaul" or connection from
the Wi-Fi to the internet. In a typical deployment scenario an end the Wi-Fi to the internet. In a typical deployment scenario an end
user has a device with a radio such as Wi-Fi. A service provider or user has a device with a radio such as Wi-Fi. A service provider or
shop owner wants to provide Wi-Fi internet service for their shop owner wants to provide Wi-Fi internet service for their
customers. The location where the service provider wants to provide customers. The location where the service provider wants to provide
Wi-Fi is within range of a TVWS master (e.g. Hotspot or Wide-Area/ Wi-Fi is within range of a TVWS master (e.g. Hotspot or Wide-Area/
Rural network). The service provider installs a TVWS slave device Rural network). The service provider installs a TVWS slave device
skipping to change at page 15, line 5 skipping to change at page 17, line 47
| | | Master | | Slave | | Dev | | | | Master | | Slave | | Dev |
|internet|------| (AP/BS) | | Bridge | |------| |internet|------| (AP/BS) | | Bridge | |------|
| | | | | to WiFi | | | | | | to WiFi |
|--------| |-----------| |----------| \|/ |--------| |-----------| |----------| \|/
| |
|-|----| |-|----|
| WiFi | | WiFi |
| Dev | | Dev |
|------| |------|
Figure 5: TVWS for backhaul Figure 6: TVWS for backhaul
Once the bridged device (TVWS+WiFi) is connected to a master and TVWS Once the bridged device (TVWS+WiFi) is connected to a master and TVWS
network, a simplified operation scenario of backhaul for WiFi network, a simplified operation scenario of backhaul for WiFi
consists of the following steps: consists of the following steps:
1. A bridged device (TVWS+WiFi) is connected to a master device 1. A bridged device (TVWS+WiFi) is connected to a master device
operating in the TVWS. The bridged device operates as a slave operating in the TVWS. The bridged device operates as a slave
device in either Hotspot or Wide-Area/Rural internet use cases device in either Hotspot or Wide-Area/Rural internet use cases
described above. described above.
2. Once the slave device is connected to the master, the Wi-Fi 2. Once the slave device is connected to the master, the Wi-Fi
access point configures its internet settings automatically based access point configures its internet settings automatically based
on the backhaul connection (i.e. it uses DHCP). on the backhaul connection (i.e. it uses DHCP).
3. End users connect their WiFi device to the bridged device and 3. End users connect their WiFi device to the bridged device and
receive internet connectivity. receive internet connectivity.
4.6. Location based service usage scenario
The owner of a shopping mall wants to provide internet access to
customers when they are at the shopping mall. His internet service
provider (ISP) recommends using master/AP devices in the TV white
space frequency band since these radios will have good propagation
characteristics, and thus will require fewer devices, and also
because the frequency band used by traditional Wi-Fi is crowded with
users such as individual stores operating their own Wi-Fi network and
also Bluetooth devices. The ISP installs APs in each large store in
the mall, and several other APs throughout the mall building. For
each AP, the professional installer programs the location (latitude
and longitude) of the device. Special tools are required to
determine the location, since typical GPS receivers do not function
indoors. When each AP is powered on, the radio does not transmit
initially. The AP contacts a white space database, using its wired
internet connection, and provides its programmed location coordinates
plus other information required by the database. A reply is received
by the AP from the database containing a list of available channels
where the AP can operate its transmitter. The AP selects a channel
for operation and notifies the database, which records information
about the AP including the identity of the AP and its location
coordinates. The AP activates its radio and begins to function as a
typical wireless AP, providing internet access to connected devices.
A user has a slave device that is capable of operating in the TV
white spaces frequency band. A typical device would be a smartphone
with multiple radios, including a cellular radio, a Wi-Fi radio, and
TV white space radio. The user arrives at the shopping mall and
enters the building. The white space radio in the smartphone is on,
and is scanning for a master/AP. As the user gets near the entrance
to the shopping mall, the smartphone locates one of the APs in the
building and connects to it. The smartphone begins to use this TVWS
radio for internet access. This internet access does not count
against the users cellular data cap (the mall owner is providing the
internet access) and also the data rates are better than cellular
data. As the user walks throughout the mall the smartphone moves
between coverage of different APs, and the smartphone connects to a
new AP when the user and smartphone move near it.
In order to encourage customers to come to the shopping mall, the
mall owner has a loyalty program where members register, build
points, and receive coupons and other notices from the shops in the
mall. Before installing the internet service in the mall, all
loyalty program information was mailed to the user, at an address
which was provided by the user when joining the loyalty program.
The ISP provider describes to the mall owner how the loyalty program
can be improved using the internet service provided by the APs in the
TV white space. A new app is developed for this loyalty program, and
promoted to users, asking them to install the app on their
smartphone. The app is provisioned with the user's loyalty program
information. When the user comes to the shopping mall, the
smartphone locates the master/AP providing internet service and
connects to the AP. The app in the smartphone sees that a radio
connection to an AP in the TV white space frequency band is now
active. The app registers the identity of the AP and forwards this
to the home server for the loyalty program, using the internet
connection provided by the AP in the TV white space band. The
loyalty program server registers the identity of the user from the
loyalty program credentials and also the identity of the AP. Next
the loyalty program server contacts the TV white space database and
requests the location of the master/AP having the identity forwarded
by the app and smartphone. When the TV white space database replies
with the location coordinates of the AP, the loyalty program server
knows the approximate location of the user and smartphone. With this
location information, the loyalty program server can now forward
loyalty program information to the user. As the user moves through
the mall, the smartphone connects to different APs. The process is
repeated, allowing the loyalty program to delivery current location
based information to the user.
1. The master create a TVWS network as described in use case
"Hotspot: urban internet connectivity service."
2. An application running on the user's slave device (e.g.
smartphone) determines that a network connection exists in the
TVWS band. The identify of the master/AP is recorded by the
application and forwarded to a server in the internet cloud.
3. The server queries the trusted white space database with the
master identity provided by the application in the user's
smartphone.
4. The trusted white space database replies to the server with the
location of the master device.
5. The server uses the location of the master/AP to determine the
approximate location of the user's smartphone. The server
provides location-specific service to the user via the
application running in the smartphone.
4.7. Rapid deployed network for emergency scenario 4.7. Rapid deployed network for emergency scenario
Organizations involved in handling emergency operations often have a Organizations involved in handling emergency operations often have a
fully owned and controlled infrastructure, with dedicated spectrum, fully owned and controlled infrastructure, with dedicated spectrum,
for day to day operation. However, lessons learned from recent for day to day operation. However, lessons learned from recent
disasters show such infrastructures are often highly affected by the disasters show such infrastructures are often highly affected by the
disaster itself. To set up a replacement quickly, there is a need disaster itself. To set up a replacement quickly, there is a need
for fast reallocation of spectrum, where in certain cases spectrum for fast reallocation of spectrum, where in certain cases spectrum
can be freed for disaster relief. To utilize free or freed spectrum can be freed for disaster relief. To utilize free or freed spectrum
quickly and reliable, automation of allocation, assignment and quickly and reliable, automation of allocation, assignment and
skipping to change at page 18, line 28 skipping to change at page 19, line 28
\ | \ Internet ) \ | \ Internet )
\ \|/ | -------( /\ \ \|/ | -------( /\
\ | ad hoc | | (------) \--------- \ | ad hoc | | (------) \---------
\ | | / | Other | \ | | / | Other |
\--|------------- /Satellite | nodes | \--|------------- /Satellite | nodes |
| Master node | / Link ---------- | Master node | / Link ----------
| with |/ | with |/
| backhaul link | | backhaul link |
----------------- -----------------
Figure 6: Rapid deployed network with partly connected nodes Figure 7: Rapid deployed network with partly connected nodes
In the ad hoc network, all nodes are master nodes in a way that they In the ad hoc network, all nodes are master nodes in a way that they
allocate RF channels from the white space database. However, the allocate RF channels from the white space database. However, the
backhaul link may not be available to all nodes, such as depicted for backhaul link may not be available to all nodes, such as depicted for
the left node in the figure. To handle RF channel allocation for the left node in the figure. To handle RF channel allocation for
such nodes, a master node with a backhaul link relays or proxies the such nodes, a master node with a backhaul link relays or proxies the
database query for them. So master nodes without a backhaul link database query for them. So master nodes without a backhaul link
follow the procedure as defined for clients. The ad hoc network follow the procedure as defined for clients. The ad hoc network
radios utilise the provided RF channels. Details on forming and radios utilise the provided RF channels. Details on forming and
maintenance of the ad hoc network, including repair of segmented maintenance of the ad hoc network, including repair of segmented
networks caused by segments operating on different RF channels, is networks caused by segments operating on different RF channels, is
out of scope of spectrum allocation. out of scope of spectrum allocation.
4.8. Mobility
In this use case, the user has a non-fixed (portable or mobile)
device and is riding in a vehicle. The user wants to have
connectivity to another device which is also moving. Typical
deployment scenarios include urban areas and rural areas where the
user may connect to other users in peer-to-peer or ad-hoc networks.
This deployment scenario is typically characterized by a master
device with low antenna height, internet connectivity by some
connection that does not utilize TV white space, and some means to
predict its path of mobility. This knowledge of mobility could be
simple (GPS plus accelerometer), sophisticated (GPS plus routing and
mapping function) or completely specified by the user via user-
interface.
The figure below shows an example deployment of this scenario.
\|/ \|/
| TDD Air Interface |
| |
+-|---------+ +-|---------+
| TVWS | | TVWS |
|Master Dev | |Master Dev |
+-----------+ +-----------+
\ (----) /
\ ( ) /
\ / \ /
( Internet )
\ /
( )\----------+
(----) | Database |
+----------+
Figure 8: Example illustration of mobility in TV white space use-case
A simplified operational scenario utilizing TV whitespace to provide
peer-to-peer connectivity service in a mobility environment consists
of the following steps:
1. The mobile master device powers up with its WS radio in idle or
listen mode only (no active transmission on the WS frequency
band).
2. The mobile master has internet connectivity and establishes a
connection to a trusted white space database (see Section 4.1).
3. The mobile master registers with the trusted database according
to regulatory domain requirements (see Section 4.2).
4. Following the registration process, the mobile master will send a
query to the trusted database requesting a list of available WS
channels based upon its current location and a prediction of its
future location, extrapolated from the motion or mobility of the
device. The current location is specified in latitude and
longitude. The method to specify the future location is TBD,
potential methods include movement vector (direction and
velocity), a set of latitude/longitude points which specify a
closed polygon where the future location is within the polygon,
or similar.
5. If the mobile master has met all regulatory domain requirements
(e.g. been previously authenticated, etc), the database responds
with a list of available white space channels that the mobile
master may use, and optional information which may include (1) a
duration of time for the use of each channel (2) a maximum
transmit power for each channel.
6. Once the mobile master has met all regulatory domain requirements
(e.g. authenticated the WS channel list response message from the
database, etc), the master selects an available WS channel(s)
from the list for use.
7. The other user device in the peer-to-peer connection scans the TV
bands to locate a mobile master transmission, and associates with
the mobile master. The slave/user device queries the master for
a channel list, based on the slave's device identification,
geolocation and optionally a prediction of its future location.
8. If required by local regulation, the master device verifies the
slave's device identification with the database.
9. If allowed by local regulation (e.g. the slave's device
identification is verified by the database), the mobile master
provides the list of channels locally available to the slave/user
device. If the channel that the slave/user terminal is currently
using is not included in the list of locally available channels,
the slave/user device ceases all operation on its current
channel. The slave/user device may scan for another Master's
transmission on a different channel.
4.9. Indoor Networking
In this use case, the users are inside a house or office. The users
want to have connectivity to the internet or to equipment in the same
or other houses / offices. This deployment scenario is typically
characterized by master devices within buildings, that are connected
to the Internet using a method that does not utilise TV whitespace.
The master devices can establish TV whitespace links between
themselves, or between themselves and one or more user devices.
The figure below shows an example deployment of this scenario.
\|/
|
+-------+ |
|TVWS |\ +-|---------+
|Usr Dev| WS AirIF \ | TVWS |\
+-------+ X|Master Dev | \
/ +-----------+ \
+-------+ WS AirIF | \ +----------+
|TVWS |/ | \ (----) | Database |
|Usr Dev| | \ ( ) /----------+
+-------+ WS AirIF \ / \
| X( Internet )
| / \ /
+-------+ \|/ | / ( )
|TVWS |\ | | / (----)
|Usr Dev| WS AirIF | | /
+-------+ \ +-|---------+ /
\ | TVWS | /
|Master Dev |/
+-----------+
Figure 9: Example illustration of indoor TV white space use-case
A simplified operational scenario utilizing TV whitespace to provide
indoor networking consists of the following steps:
1. The master device powers up with its whitespace radio in idle or
listen mode only (no active transmission on the whitespace
frequency band).
2. The master device has internet connectivity and establishes a
connection to a trusted white space database (see Section 3.1
above).
3. The master device sends its geolocation and location uncertainty
information, and optionally additional information which may
include (1) device ID and (2) antenna characteristics, to a
trusted database, requesting a list of available whitespace
channels based upon this information.
4. The database responds with a list of available white space
channels that the master device may use, and optional information
which may include inter alia (1) a duration of time for the use
of each channel (channel validity time) (2) a maximum radiated
power for each channel, (3) an indication of the quality of the
spectrum for each channel and (4) directivity and other antenna
information.
5. Once the master device authenticates the whitespace channel list
response message from the database, the master device selects one
or more available whitespace channels from the list.
6. The user device(s) scan(s) the TV white space bands to locate the
master device transmissions, and associates with the master.
4.10. Machine to Machine (M2M)
In this use case, each "machine" includes a white space slave device
and can be located anywhere, fixed or on the move. Each machine
needs to have connectivity to the internet and or to other machines
in the vicinity. Machine communication over a TVWS channel, whether
to a master device or to another machine (slave device), is under the
control of a master device. This deployment scenario is typically
characterized by a master device with internet connectivity by some
connection that does not utilize TV white space.
The figure below shows an example deployment of this scenario.
\|/
|
|
+-|---------+
| TVWS |\
/|Master Dev | \
/ +-----------+ \
WS AirIF \ +----------+
+-------+ / \ (----) | Database |
|Machine| \ ( ) /----------+
+-------+ \ / \
| X( Internet )
WS AirIF \ /
| ( )
+-------+ (----)
|Machine|
+-------+ \ +-------+
WS AirIF-- |Machine|
+-------+
Figure 10: Example illustration of M2M TV white space use-case
A simplified operational scenario utilizing TV whitespace to provide
machine to machine connectivity consists of the following steps:
1. The master device powers up with its whitespace radio in idle or
listen mode only (no active transmission on the whitespace
frequency band).
2. The master device has internet connectivity and establishes a
connection to a trusted white space database (see Section 3.1
above).
3. The master device sends its geolocation and location uncertainty
information, and optionally additional information which may
include (1) device ID and (2) antenna characteristics, to a
trusted database, requesting a list of available whitespace
channels based upon this information.
4. The database responds with a list of available white space
channels that the master device may use, and optional information
which may include inter alia (1) a duration of time for the use
of each channel (channel validity time) (2) a maximum radiated
power for each channel, (3) an indication of the quality of the
spectrum for each channel and (4) directivity and other antenna
information.
5. Once the master device authenticates the whitespace channel list
response message from the database, the master device selects one
or more available whitespace channels from the list.
6. The slave devices fitted to the machines scan the TV bands to
locate the master transmissions, and associate with the master
device. Further signaling can take place outside scope of PAWS
to establish direct links among those slave devices that have
associated with the master device.
5. Problem Statement 5. Problem Statement
The use of white space spectrum is enabled via the capability of a The use of white space spectrum is enabled via the capability of a
device to query a database and obtain information about the device to query a database and obtain information about the
availability of spectrum for use at a given location. The databases availability of spectrum for use at a given location. The databases
are reachable via the Internet and the devices querying these are reachable via the Internet and the devices querying these
databases are expected to have some form of Internet connectivity, databases are expected to have some form of Internet connectivity,
directly or indirectly. The databases may be country specific since directly or indirectly. The databases may be country specific since
the available spectrum and regulations may vary, but the fundamental the available spectrum and regulations may vary, but the fundamental
operation of the protocol should be country independent. operation of the protocol should be country independent.
skipping to change at page 19, line 21 skipping to change at page 25, line 17
|Lat: X |\ .---. /--------|Database X| |Lat: X |\ .---. /--------|Database X|
|Long: Y | \ ( ) / ------------ |Long: Y | \ ( ) / ------------
----------- \-------/ \/ o ----------- \-------/ \/ o
( Internet ) o ( Internet ) o
----------- /------( )\ o ----------- /------( )\ o
|WS Device| / (_____) \ ------------ |WS Device| / (_____) \ ------------
|Lat: X |/ \--------|Database Y| |Lat: X |/ \--------|Database Y|
|Long: Y | ------------ |Long: Y | ------------
----------- -----------
Figure 7: High level view of the White space database architecture Figure 11: High level view of the White space database architecture
In the figure above, note that there could be multiple databases In the figure above, note that there could be multiple databases
serving white space devices. The databases are country specific serving white space devices. The databases are country specific
since the regulations and available spectrum may vary. In some since the regulations and available spectrum may vary. In some
countries, for example, the U.S., the regulator has determined that countries, for example, the U.S., the regulator has determined that
multiple, competing databases may provide service to White Space multiple, competing databases may provide service to White Space
Devices. Devices.
A messaging interface between the white space devices and the A messaging interface between the white space devices and the
database is required for operating a network using the white space database is required for operating a network using the white space
skipping to change at page 21, line 43 skipping to change at page 27, line 32
Use of XML for specifying a data model is an attractive option. The 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 intent is to evaluate the best option that meets the need for use
between white space devices and databases. between white space devices and databases.
6. Requirements 6. Requirements
This section is the placeholder for the requirements derived from the This section is the placeholder for the requirements derived from the
use cases. use cases.
D. Data Model Requirements:
D.1: The Data Model MUST support specifying the antenna height
parameter of the subject.
D.2: The Data Model MUST support specifying an ID of the subject.
This ID would be the ID of the device used to be certified
by a regulatory body for a regulatory domain.
D.3: The Data Model MUST support specifying the location of the
subject and the uncertainty by which the location was
determined, when confidence level is considered 95%.
D.4: The Data Model MUST support specifying the location of the
subject and accuracy of location determination.
D.5: The Data Model MUST support specifying a list of available
channel list and time constrains for the channel list
availability.
D.6: The Data Model MUST support specifying the maximum output
power of the subject.
D.7: The Data Model MUST support specifying channel availability
information for multiple locations.
D.8: The Data Model MUST support specifying channel availability
information for an area around a specified location.
D.9: The Data Model MUST support specifying multiple spectrum
masks, each containing (1) the lowest applicable frequency
in MHz, (2) the highest possible frequency in MHz, (3) the
maximum total EIRP over the frequency range defined by the
spectrum mask, (4) the general spectrum mask in dBr from
peak transmit power in EIRP, with specific power limit at
any frequency linearly interpolated between adjacent points
of the spectrum mask expressed as in [80211P] or
[FCC47CFR90.210], and (5) measurement resolution bandwidth
for EIRP measurements.
P. Protocol Requirements:
P.1: The protocol MUST provide a mechanism for the subject to
discover the WS Database it has to use at a given location.
P.2: The protocol MUST support regulatory domain discovery.
P.3: The protocol between the master device and the WS Database
MUST support pushing updates in channel availability
changes to subjects.
P.4: The protocol between the master device and the WS Database
MUST support mutual authentication and authorization.
P.5: The protocol between the master device and the WS Database
MUST support integrity and confidentiality protection.
P.6: The protocol MUST support both username/password and
digital certificates based authentication.
P.7: A master device MAY register with a trusted white space
database.
P.8: A master device MUST place its location into the query it
makes to the whitespace database.
P.9: A master device MUST be able to query the whitespace
database for channel availability information for a
specific expected coverage area around its current
location.
P.10: A master device MUST send Device ID, searial number and
device location in the query it makes to the database.
P.11: A master device MAY send additional information in the
query it makes to the database such as antenna height above
ground level or antenna characteristics.
P.12: A master device MUST be capable of validating the digital
certificate of the WS Database.
P.13: A master device MUST be capable of checking the validity of
the WS Database certificate and whether it has been revoked
or not.
O. Operational Requirements:
O.1: A master device MUST query the WS Database for the
available channels as often as required by the regulation
(eg, FCC requires once per day) to verify that the
operating channels continue to remain available.
O.2: A master device MUST determine its location with the
accuracy required by the regulation (eg, FCC requires +/-
100m) before placing a query to the DB.
O.3: A master device which changes its location during its
operation, MUST query the WS Database for available
operating channels each time it moves more than the
distance specified by the regulation (eg FCC specifies
100m) from the location it previously made the query from.
O.4: The WS Database MUST provide the available channel list
when requested from an authenticated and authorized device
and MAY also provide time constraints for the channel list,
maximum output power and start and stop frequencies for
each channel to the master device.
O.5: A master device MUST query the WS Database and include the
FCC ID of the slave device in the query before allowing the
slave device to use the available channel.
O.6: A master device MUST be capable to validate the digital
certificate of the WS Database.
O.7: A master device MUST be capable to check the validity of
the WS Database certificate and whether it has been revoked
or not.
O.8: A master device MUST be able to determine its location
using latitude-longitude coordinates.
O.9: A master device MUST make a fresh query of the whitespace
database for the available channels within a particular
time interval, using a parameter sent by the database in
response to the previous query. On expiry of the time
interval then a master device MUST cease transmission in
the TVWS band if no successful query attempt has been made
or a query has been made but the database has not
responded.
O.10: If slave devices change their location during operation,
the master device MUST query the whitespace database for
available operating channels each time a slave device moves
outside the reported coverage location area.
O.11: A master device MAY be able to indicate to slave devices
the start and stop frequencies it has available for
operation and the maximum permitted powers for the slave
devices, and MAY be able to send additional optional
information.
7. IANA Considerations 7. IANA Considerations
This document has no requests to IANA. This document has no requests to IANA.
8. Security Considerations 8. Security Considerations
The messaging interface between the white space device and the The messaging interface between the white space device and the
database needs to be secured. Both the queries and the responses database needs to be secured. Both the queries and the responses
need to be delivered securely. The device must be certain it is need to be delivered securely. The device must be certain it is
talking to a bona fide database authoritative for the location and talking to a bona fide database authoritative for the location and
skipping to change at page 23, line 10 skipping to change at page 31, line 47
10. Acknowledgements 10. Acknowledgements
The authors acknowledge Gerald Chouinard and Teco Boot as The authors acknowledge Gerald Chouinard and Teco Boot as
contributors to this document. contributors to this document.
11. References 11. References
11.1. Normative References 11.1. Normative References
[80211P] IEEE, "IEEE Standard for Information technology -
Telecommunications and information exchange between
systems - Local and metropolitan area networks - Specific
requirements; Part 11: Wireless LAN Medium Access Control
(MAC) and Physical Layer (PHY) Specifications; Amendment
6: Wireless Access in Vehicular Environments; http://
standards.ieee.org/getieee802/download/802.11p-2010.pdf",
July 2010.
[FCC47CFR90.210]
FCC, "Title 47 Telecommunication CFR Chapter I - Federal
Communication Commission Part 90 - Private Land Mobile
Radio Services - Section 210 Emission masks; http://
edocket.access.gpo.gov/cfr_2010/octqtr/pdf/
47cfr90.210.pdf", October 2010.
[PAWS-PS] IETF, "Protocol to Access White Space database: Problem [PAWS-PS] IETF, "Protocol to Access White Space database: Problem
statement; https://datatracker.ietf.org/doc/ statement; https://datatracker.ietf.org/doc/
draft-patil-paws-problem-stmt/", July 2011. draft-patil-paws-problem-stmt/", July 2011.
[RFC2119] IETF, "Key words for use in RFCs to Indicate Requirement [RFC2119] IETF, "Key words for use in RFCs to Indicate Requirement
Levels; Levels;
http://www.rfc-editor.org/rfc/pdfrfc/rfc2119.txt.pdf", http://www.rfc-editor.org/rfc/pdfrfc/rfc2119.txt.pdf",
March 1997. March 1997.
11.2. Informative References 11.2. Informative References
skipping to change at page 23, line 43 skipping to change at page 32, line 51
SYSTEMS IN THE 'WHITE SPACES' OF THE FREQUENCY BAND 470- SYSTEMS IN THE 'WHITE SPACES' OF THE FREQUENCY BAND 470-
590 MHZ; http://www.erodocdb.dk/Docs/doc98/official/pdf/ 590 MHZ; http://www.erodocdb.dk/Docs/doc98/official/pdf/
ECCREP159.PDF", January 2011. ECCREP159.PDF", January 2011.
[FCC Ruling] [FCC Ruling]
FCC, "Federal Communications Commission, "Unlicensed FCC, "Federal Communications Commission, "Unlicensed
Operation in the TV Broadcast Bands; Operation in the TV Broadcast Bands;
http://edocket.access.gpo.gov/2010/pdf/2010-30184.pdf"", http://edocket.access.gpo.gov/2010/pdf/2010-30184.pdf"",
December 2010. December 2010.
[Ofcom Implementing]
Ofcom, "Ofcom, "Implementing Geolocation; http://
stakeholders.ofcom.org.uk/consultations/geolocation/
statement/
?utm_source=updates&utm_medium=email&
utm_campaign=geolocation-statement"", September 2011.
[RFC5222] IETF, Hardie, T., Netwon, A., Schulzrinne, H., and H. [RFC5222] IETF, Hardie, T., Netwon, A., Schulzrinne, H., and H.
Tschofenig, "LoST: A Location-to-Service Translation Proto Tschofenig, "LoST: A Location-to-Service Translation Proto
col;http://www.rfc-editor.org/rfc/pdfrfc/rfc5222.txt.pdf", col;http://www.rfc-editor.org/rfc/pdfrfc/rfc5222.txt.pdf",
August 2008. August 2008.
[Spectrum Framework Review] [Spectrum Framework Review]
Ofcom - Independent regulator and competition authority Ofcom - Independent regulator and competition authority
for the UK communications industries, "Spectrum Framework for the UK communications industries, "Spectrum Framework
Review; Review;
http://stakeholders.ofcom.org.uk/consultations/sfr/", http://stakeholders.ofcom.org.uk/consultations/sfr/",
skipping to change at page 24, line 25 skipping to change at page 33, line 39
Authors' Addresses Authors' Addresses
Scott Probasco (editor) Scott Probasco (editor)
Nokia Nokia
6021 Connection drive 6021 Connection drive
Irving, TX 75039 Irving, TX 75039
USA USA
Email: scott.probasco@nokia.com Email: scott.probasco@nokia.com
Gabor Bajko
Nokia
200 South Mathilda Ave
Sunnyvale, CA 94086
USA
Email: gabor.bajko@nokia.com
Basavaraj Patil Basavaraj Patil
Nokia Nokia
6021 Connection drive 6021 Connection drive
Irving, TX 75039 Irving, TX 75039
USA USA
Email: basavaraj.patil@nokia.com Email: basavaraj.patil@nokia.com
Brian Rosen
Neustar
470 Conrad Dr
Mars, PA 16046
USA
Email: brian.rosen@neustar.biz
 End of changes. 47 change blocks. 
223 lines changed or deleted 595 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/