draft-ietf-paws-problem-stmt-usecases-rqmts-03.txt   draft-ietf-paws-problem-stmt-usecases-rqmts-04.txt 
Working Group Draft S. Probasco, Ed. Working Group Draft S. Probasco, Ed.
Internet-Draft B. Patil Internet-Draft B. Patil
Intended status: Informational Nokia Intended status: Informational Nokia
Expires: September 1, 2012 February 29, 2012 Expires: November 12, 2012 May 11, 2012
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-03 draft-ietf-paws-problem-stmt-usecases-rqmts-04
Abstract Abstract
Portions of the radio spectrum that are assigned to a particular use Portions of the radio spectrum that are assigned to a particular use
but are unused or unoccupied at specific locations and times are but are unused or unoccupied at specific locations and times are
defined as "white space". The concept of allowing additional defined as "white space". The concept of allowing additional
transmissions (which may or may not be licensed) in white space is a transmissions (which may or may not be licensed) 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 additional transmissions do not interfere requirement is that these additional transmissions do not interfere
with the assigned use of the spectrum. One approach to using the with the assigned use of the spectrum. One approach to using the
skipping to change at page 1, line 47 skipping to change at page 1, line 47
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 September 1, 2012. This Internet-Draft will expire on November 12, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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
skipping to change at page 3, line 17 skipping to change at page 3, line 17
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Introduction to white space . . . . . . . . . . . . . . . 4 1.1. Introduction to white space . . . . . . . . . . . . . . . 4
1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2.1. In Scope . . . . . . . . . . . . . . . . . . . . . . . 6 1.2.1. In Scope . . . . . . . . . . . . . . . . . . . . . . . 6
1.2.2. Out of Scope . . . . . . . . . . . . . . . . . . . . . 6 1.2.2. Out of Scope . . . . . . . . . . . . . . . . . . . . . 6
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 7 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 7
2.1. Conventions Used in This Document . . . . . . . . . . . . 7 2.1. Conventions Used in This Document . . . . . . . . . . . . 7
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7
3. Prior Work . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3. Prior Work . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1. The concept of Cognitive Radio . . . . . . . . . . . . . . 8 3.1. The concept of Cognitive Radio . . . . . . . . . . . . . . 8
3.2. Background information on white space in the US . . . . . 8 3.2. Background information on white space in the US . . . . . 9
3.3. Background information on white space in the UK . . . . . 9 3.3. Background information on white space in the UK . . . . . 9
3.4. Air Interfaces . . . . . . . . . . . . . . . . . . . . . . 9 3.4. Air Interfaces . . . . . . . . . . . . . . . . . . . . . . 10
4. Use cases and protocol services . . . . . . . . . . . . . . . 10 4. Use cases and protocol services . . . . . . . . . . . . . . . 10
4.1. Protocol services . . . . . . . . . . . . . . . . . . . . 10 4.1. Protocol services . . . . . . . . . . . . . . . . . . . . 10
4.1.1. White space database discovery . . . . . . . . . . . . 10 4.1.1. White space database discovery . . . . . . . . . . . . 10
4.1.2. Device registration with trusted Database . . . . . . 11 4.1.2. Device registration with trusted Database . . . . . . 11
4.2. Use cases . . . . . . . . . . . . . . . . . . . . . . . . 12 4.2. Use cases . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2.1. Hotspot: urban Internet connectivity service . . . . . 12 4.2.1. Hotspot: urban Internet connectivity service . . . . . 12
4.2.2. Wide-Area or Rural Internet broadband access . . . . . 15 4.2.2. Wide-Area or Rural Internet broadband access . . . . . 15
4.2.3. White space serving as backhaul . . . . . . . . . . . 18 4.2.3. Offloading: moving traffic to a white space network . 18
4.2.4. Rapid deployed network for emergency scenario . . . . 19 4.2.4. White space serving as backhaul . . . . . . . . . . . 20
4.2.5. Mobility . . . . . . . . . . . . . . . . . . . . . . . 20 4.2.5. Rapid deployed network for emergency scenario . . . . 21
4.2.6. Indoor Networking . . . . . . . . . . . . . . . . . . 23 4.2.6. Mobility . . . . . . . . . . . . . . . . . . . . . . . 22
4.2.7. Machine to Machine (M2M) . . . . . . . . . . . . . . . 24 4.2.7. Indoor Networking . . . . . . . . . . . . . . . . . . 25
5. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 26 4.2.8. Machine to Machine (M2M) . . . . . . . . . . . . . . . 26
5.1. Global applicability . . . . . . . . . . . . . . . . . . . 27 5. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 28
5.2. Database discovery . . . . . . . . . . . . . . . . . . . . 28 5.1. Global applicability . . . . . . . . . . . . . . . . . . . 29
5.3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 29 5.2. Database discovery . . . . . . . . . . . . . . . . . . . . 30
5.4. Data model definition . . . . . . . . . . . . . . . . . . 29 5.3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 31
6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 29 5.4. Data model definition . . . . . . . . . . . . . . . . . . 31
6.1. Normative Requirements . . . . . . . . . . . . . . . . . . 29 6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 31
6.2. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . 35 6.1. Normative Requirements . . . . . . . . . . . . . . . . . . 31
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 6.2. Non-normative requirements . . . . . . . . . . . . . . . . 34
8. Security Considerations . . . . . . . . . . . . . . . . . . . 35 6.3. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . 36
9. Summary and Conclusion . . . . . . . . . . . . . . . . . . . . 38 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 39 8. Security Considerations . . . . . . . . . . . . . . . . . . . 37
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39 9. Summary and Conclusion . . . . . . . . . . . . . . . . . . . . 40
11.1. Normative References . . . . . . . . . . . . . . . . . . . 39 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 40
11.2. Informative References . . . . . . . . . . . . . . . . . . 40 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41 11.1. Normative References . . . . . . . . . . . . . . . . . . . 40
11.2. Informative References . . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42
1. Introduction 1. Introduction
1.1. Introduction to white space 1.1. Introduction to 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 but are not The spectrum is used for various purposes, which include but are not
limited to entertainment (e.g. radio and television), communication limited to entertainment (e.g. radio and television), communication
(telephony and Internet access), military (radars etc.) and, (telephony and Internet access), military (radars etc.) and,
navigation (satellite communication, GPS). Portions of the radio navigation (satellite communication, GPS). Portions of the radio
skipping to change at page 6, line 39 skipping to change at page 6, line 39
3. Register with the database using a well-defined protocol. 3. Register with the database using a well-defined protocol.
4. Provide its geolocation and perhaps other data to the database 4. Provide its geolocation and perhaps other data to the database
using a well-defined format for querying the database. using a well-defined format for querying the database.
5. Receive in response to the query a list of currently available 5. Receive in response to the query a list of currently available
white space channels or frequencies using a well-defined format white space channels or frequencies using a well-defined format
for the information. for the information.
6. Send an acknowledgment to the database with information
containing channels selected for use by the device.
As a result, some of the scenarios described in the following section As a result, some of the scenarios described in the following section
are out of scope for this specification (although they might be are out of scope for this specification (although they might be
addressed by future specifications). addressed by future specifications).
1.2.2. Out of Scope 1.2.2. Out of Scope
The following topics are out of scope for this specification: The following topics are out of scope for this specification:
Co-existence and interference avoidance of white space devices Co-existence and interference avoidance of white space devices
within the same spectrum within the same spectrum
skipping to change at page 7, line 23 skipping to change at page 7, line 24
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, but is not limited to, the database is an entity which contains, but is not limited to,
current information about available spectrum at any given location current information about available spectrum at any given location
and other types of related (to the white space spectrum) or and other types of related (to the white space spectrum) or
relevant information. relevant information.
Device Class
Identifies classes of devices defined by Regional Regulators,
including fixed, mobile, portable, etc... May also indicate if
the device is indoor or outdoor.
Device ID Device ID
A unique number for each master device and slave device that A unique number for each master device and slave device that
identifies the manufacturer, model number and serial number. 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.
skipping to change at page 10, line 9 skipping to change at page 10, line 16
Efforts are ongoing to specify air-interfaces for use in white space Efforts are ongoing to specify air-interfaces for use in white space
spectrum. IEEE 802.11af, IEEE 802.15.4m and IEEE 802.22 are all spectrum. IEEE 802.11af, IEEE 802.15.4m and IEEE 802.22 are all
examples. Other air interfaces could be specified in the future such examples. Other air interfaces could be specified in the future such
as LTE. as LTE.
4. Use cases and protocol services 4. Use cases and protocol services
There are many potential use cases that could be considered for the There are many potential use cases that could be considered for the
TV white space spectrum. Providing broadband Internet access in TV white space spectrum. Providing broadband Internet access in
hotspots, rural and underserved areas are examples. Available urban and densely populated hotspots, rural and underserved areas are
channels may also be used to provide Internet 'backhaul' for examples. Available channels may also be used to provide Internet
traditional Wi-Fi hotspots, or by towns and cities to monitor/control 'backhaul' for traditional Wi-Fi hotspots, or by towns and cities to
traffic lights or read utility meters. Still other use cases include monitor/control traffic lights or read utility meters. Still other
the ability to offload data traffic from another Internet access use cases include the ability to offload data traffic from another
network (e.g. 3G cellular network) or to deliver location based Internet access network (e.g. 3G cellular network) or to deliver
services. Some of these use cases are described in the following location based services. Some of these use cases are described in
sections. the following sections.
4.1. Protocol services 4.1. Protocol services
A complete protocol solution must provide all services that are A complete protocol solution must provide all services that are
essential to enable the white space paradigm. Before a white space essential to enable the white space paradigm. Before a white space
device can request service from a white space database, such as a device can begin operating it needs to know what channels are
query for a list of available channels, the white space device must available by sending a query to a white space database for a list of
first locate or "discover" a suitable database. Additionally, some available channels, the white space device must first locate or
regulatory authorities require the white space device to register "discover" a suitable database. Additionally, some regulatory
with the database as a first step. This section describes the authorities require the white space device to register with the
services required from the protocol. database as a first step. This section describes the features
required from the protocol.
4.1.1. White space database discovery 4.1.1. White space database discovery
White space database discovery is preliminary to creating a radio White space database discovery is preliminary to creating a radio
network using white space; it is a prerequisite to the use cases network using white space; it is a prerequisite to the use cases
below. The radio network is created by a master device. Before the below. The radio network is created by a master device. Before the
master device can transmit in white space spectrum, it must contact a master device can transmit in white space spectrum, it must contact a
trusted database where the device can learn if any channels are trusted database where the device can learn if any channels are
available for it to use. The master device will need to discover a available for it to use. The master device will need to discover a
trusted database in the relevant regulatory domain, using the trusted database in the relevant regulatory domain, using the
skipping to change at page 14, line 18 skipping to change at page 14, line 33
5. If the master/AP has met all regulatory domain requirements 5. If the master/AP has met all regulatory domain requirements
(e.g. been previously authenticated, etc), the database responds (e.g. been previously authenticated, etc), the database responds
with a list of available white space channels that the master with a list of available white space channels that the master
may use, and optionally a duration of time for their use, may use, and optionally a duration of time for their use,
associated maximum power levels or a notification of any associated maximum power levels or a notification of any
additional requirements for sensing. additional requirements for sensing.
6. Once the master/AP has met all regulatory domain requirements 6. Once the master/AP has met all regulatory domain requirements
(e.g. authenticated the WS channel list response message from (e.g. authenticated the WS channel list response message from
the database, etc), the AP selects one or more available WS the database, etc), the AP selects one or more available WS
channels from the list. channels from the list. Prior to initiating transmission, if
required by local regulation, the master/AP informs the database
of the frequencies and power level it has chosen. This
reporting of the frequencies and power levels to the database is
repeated for each slave that associated with the master.
7. The slave or user device scans the TV bands to locate a 7. The slave or user device scans the TV bands to locate a
master/AP transmission, and associates with the AP. master/AP transmission, and associates with the AP.
8. The slave/user device queries the master for a channel list. In 8. The slave/user device queries the master for a channel list. In
the query the slave/user device provides attributes that are the query the slave/user device provides attributes that are
defined by local regulations. These may include the slaves' defined by local regulations. These may include the slaves'
Device ID and its geolocation. Device ID and its geolocation.
9. Once the master/AP has met all regulatory domain requirements 9. Once the master/AP has met all regulatory domain requirements
(e.g. validating the Device ID with the trusted database, etc) (e.g. validating the Device ID with the trusted database, etc)
the master provides the list of channels locally available to the master provides the list of channels locally available to
the slave/user device. the slave/user device. Prior to initiating transmission, if
required by local regulation, the slave informs the master/AP of
the frequencies and power level it has chosen, and the master/AP
relays this information to the database.
10. The master sends an enabling signal to establish that the slave/ 10. The master sends an enabling signal to establish that the slave/
user device is still within reception range of the master. This user device is still within reception range of the master. This
signal shall be encoded to ensure that the signal originates signal shall be encoded to ensure that the signal originates
from the master that provided the available list of channels. from the master that provided the available list of channels.
11. Periodically, at an interval established by the local regulator, 11. Periodically, at an interval established by the local regulator,
the slave/user device must receive an enabling signal from the the slave/user device must receive an enabling signal from the
master that provided the available list of channels or contact a master that provided the available list of channels or contact a
master to re-verify or re-establish the list of available master to re-verify or re-establish the list of available
skipping to change at page 17, line 27 skipping to change at page 17, line 39
expected service area so that the final intersection of these expected service area so that the final intersection of these
resulting WS channel lists allows the selection of a channel resulting WS channel lists allows the selection of a channel
that is likely available over the entire service area to avoid that is likely available over the entire service area to avoid
potential interference at the time of slave/user terminal potential interference at the time of slave/user terminal
association. The operator may also disallow some channels from association. The operator may also disallow some channels from
the list to suit local needs if required. the list to suit local needs if required.
7. The slave or user device scans the TV bands to locate a WRAN 7. The slave or user device scans the TV bands to locate a WRAN
transmission, and associates with the master/BS. transmission, and associates with the master/BS.
8. The slave/user device provides its geolocation to the BS which, 8. In some regulatory domains, before a master device sends a
in turn, queries the database for a list of channels available channel list, the slave/user device provides its geolocation to
at the slave's geolocation. the BS which, in turn, queries the database for a list of
channels available at the slave's geolocation.
9. Once this list of available channels is received from the 9. Once this list of available channels is received from the
database by the master, the latter will decide, based on this database by the master, the latter will decide, based on this
list of available channels and on the lists for all its other list of available channels and on the lists for all its other
associated slaves/user devices whether it should: a) continue associated slaves/user devices whether it should: a) continue
operation on its current channel if this channel is available to operation on its current channel if this channel is available to
all slaves/user devices, b) continue operation on its current all slaves/user devices, b) continue operation on its current
channel and not allow association with the new slave/user device channel and not allow association with the new slave/user device
in case this channel is not available at its location or c) in case this channel is not available at its location or c)
change channel to accommodate the new slave. In the latter change channel to accommodate the new slave. In the latter
skipping to change at page 18, line 19 skipping to change at page 18, line 33
the link. The slave/user devices may then move to the the link. The slave/user devices may then move to the
identified new operating channel or scan for another WRAN identified new operating channel or scan for another WRAN
transmission on a different channel. The frequency to repeat transmission on a different channel. The frequency to repeat
the process is determined by the local regulator. the process is determined by the local regulator.
11. The slave/user device must transmit its new geographic location 11. The slave/user device must transmit its new geographic location
every time it changes so that the repeated process described every time it changes so that the repeated process described
under item 10 can rely on the most up-to-date geolocation of the under item 10 can rely on the most up-to-date geolocation of the
slave/user device. slave/user device.
4.2.3. White space serving as backhaul 4.2.3. Offloading: moving traffic to a white space network
In this use case internet connectivity service is provided over TV
white space as a supplemental or alternative datapath to a 3G or
other internet connection. In a typical deployment scenario an end
user has a primary internet connection such as a 3G cellular packet
data subscription. The user wants to use a widget or application to
stream video from an online service (e.g. youtube) to their device.
Before the widget starts the streaming connection it checks
connectivity options available at the current time and location.
Both 3G cellular data is available as well as TVWS connectivity (the
user is within coverage of a TVWS master -- hotspot, WAN, WRAN or
similar). The user may decide for many and various reasons such as
cost, RF coverage, data caps, etc. to prefer the TVWS connection over
the 3G cellular data connection. Either by user selection,
preconfigured preferences, or other algorithm, the streaming session
is started over the TVWS internet connection instead of the 3G
cellular connection. This deployment scenario is typically
characterized by a TVWS master/AP providing local coverage in the
same geographical area as a 3G cellular system. The master/AP is
assumed to be individually deployed and operated, i.e. the master/AP
is deployed and operated by the user at his home or perhaps by a
small business such as a coffee shop. The master/AP has a connection
to the internet and provides internet connectivity to the slave/
end-user's device.
The figure below shows an example deployment of this scenario.
\|/
|
|
|-|---------|
| Master/AP |\
/| Router | \
Streaming/ |-----------| \
-------- / \ -----------
|Slave/| / \ (----) | Database |
|WS Dev| \ ( ) /----------
------- \ \ / \
\ X( Internet )
\ / \ /
Signaling \|/ / ( )\
\ | / (----) \----------
\ | / | YouTube |
\|-|---------| / ----------
| | /
| 3G BTS |/
|-----------|
Figure 5: Offloading: moving traffic to a white space network
Once a dual or multi mode device (3G + TVWS) is connected to a 3G
network, a simplified operation scenario of offloading selected
content such as video stream from the 3G connection to the TWVS
connection consists of the following steps:
1. The dual mode (or multi mode) device (3G + TVWS) is connected to
a 3G network. The device has contacted a trusted database to
discover the list of available TV channels at its current
location. The device has located a TVWS master/AP operating on
an available channel and has associated or connected with the
TVWS master/AP.
2. The user activates a widget or application that streams video
from YouTube. The widget connects to YouTube over 3G cellular
data. The user browses content and searches for video
selections.
3. The user selects a video for streaming using the widget's
controls. Before the widget initiates a streaming session, the
widget checks the available connections in the dual mode device
and finds a TVWS master/AP is connected.
4. Using either input from the user or pre-defined profile
preferences, the widget selects the TVWS master/AP as the
connection to stream the video.
4.2.4. White space serving as 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 more common wireless standard such as Wi-Fi with white space over a more common wireless standard such as Wi-Fi with white space
entities providing backhaul connectivity to the Internet. In a entities providing backhaul connectivity to the Internet. In a
typical deployment scenario an end user has a device with a radio typical deployment scenario an end user has a device with a radio
such as Wi-Fi. An Internet service provider or a small business such as Wi-Fi. An Internet service provider or a small business
owner wants to provide Wi-Fi Internet connectivity service to their owner wants to provide Wi-Fi Internet connectivity service to their
customers. The location where Internet connectivity service via customers. The location where Internet connectivity service via
Wi-Fi is to be provided is within the coverage area of a white space Wi-Fi is to be provided is within the coverage area of a white space
master (e.g. Hotspot or Wide-Area/Rural network). The service master (e.g. Hotspot or Wide-Area/Rural network). The service
skipping to change at page 18, line 43 skipping to change at page 20, line 40
typically characterized by a WS master/AP/BS providing local typically characterized by a WS master/AP/BS providing local
coverage. The master/AP has a connection to the Internet and coverage. The master/AP has a connection to the Internet and
provides Internet connectivity to slave devices that are within its provides Internet connectivity to slave devices that are within its
coverage area. The WS slave device is 'bridged' to a Wi-Fi network coverage area. The WS slave device is 'bridged' to a Wi-Fi network
thereby enabling Internet connectivity service to Wi-Fi devices. The thereby enabling Internet connectivity service to Wi-Fi devices. The
WS Master/AP/BS which has some form of Internet connectivity (wired WS Master/AP/BS which has some form of Internet connectivity (wired
or wireless) queries the database and obtains available channel or wireless) queries the database and obtains available channel
information. It then provides service using those channels to slave information. It then provides service using those channels to slave
devices which are within its coverage area. devices which are within its coverage area.
Figure 5 shows an example deployment of this scenario. Figure 6 shows an example deployment of this scenario.
\|/ white \|/ \|/ Wi-Fi \|/ \|/ white \|/ \|/ Wi-Fi \|/
| space | | | | space | | |
| | | |-|----| | | | |-|----|
|--------| |-|---------| |-|------|-| | Wi-Fi| |--------| |-|---------| |-|------|-| | Wi-Fi|
| | | Master | | Slave | | Dev | | | | Master | | Slave | | Dev |
|Internet|------| (AP/BS) | | Bridge | |------| |Internet|------| (AP/BS) | | Bridge | |------|
| | | | | to Wi-Fi | | | | | | to Wi-Fi |
|--------| |-----------| |----------| \|/ |--------| |-----------| |----------| \|/
| |
|-|----| |-|----|
| Wi-Fi| | Wi-Fi|
| Dev | | Dev |
|------| |------|
Figure 5: WS for backhaul Figure 6: WS for backhaul
Once the bridged device (WS + Wi-Fi) is connected to a master and WS Once the bridged device (WS + Wi-Fi) is connected to a master and WS
network, a simplified operation scenario of backhaul for Wi-Fi network, a simplified operation scenario of backhaul for Wi-Fi
consists of the following steps: consists of the following steps:
1. A bridged device (WS + Wi-Fi) is connected to a master device 1. A bridged device (WS + Wi-Fi) is connected to a master device
operating in the WS spectrum. The bridged device operates as a operating in the WS spectrum. The bridged device operates as a
slave device in either Hotspot or Wide-Area/Rural Internet use slave device in either Hotspot or Wide-Area/Rural Internet use
cases described above. cases 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 has Internet connectivity as well. access point has Internet connectivity as well.
3. End users attach to the Wi-Fi network via their Wi-Fi enabled 3. End users attach to the Wi-Fi network via their Wi-Fi enabled
devices and receive Internet connectivity. devices and receive Internet connectivity.
4.2.4. Rapid deployed network for emergency scenario 4.2.5. 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 cleared for disaster relief. To utilize unused or cleared can be cleared for disaster relief. To utilize unused or cleared
spectrum quickly and reliably, automation of allocation, assignment spectrum quickly and reliably, automation of allocation, assignment
and configuration is needed. A preferred option is to make use of a and configuration is needed. A preferred option is to make use of a
robust protocol, already adopted by radio manufacturers. This robust protocol, already adopted by radio manufacturers. This
approach does in no way imply such organizations for disaster relief approach does in no way imply such organizations for disaster relief
must compete on spectrum allocation with other white spaces users, must compete on spectrum allocation with other white spaces users,
but they can. A typical network topology would include wireless but they can. A typical network topology would include wireless
access links to the public Internet or private network, wireless ad access links to the public Internet or private network, wireless ad
hoc network radios working independent of a fixed infrastructure and hoc network radios working independent of a fixed infrastructure and
satellite links for backup where lack of coverage, overload or outage satellite links for backup where lack of coverage, overload or outage
of wireless access links occur. of wireless access links occur.
Figure 6 shows an example deployment of this scenario. Figure 7 shows an example deployment of this scenario.
\|/ \|/
| ad hoc | ad hoc
| |
|-|-------------| |-|-------------|
| Master node | |------------| | Master node | |------------|
\|/ | with | | Whitespace | \|/ | with | | Whitespace |
| ad hoc /| backhaul link | | Database | | ad hoc /| backhaul link | | Database |
| /------/ |---------------| |------------| | /------/ |---------------| |------------|
---|------------/ | \ / ---|------------/ | \ /
skipping to change at page 20, line 32 skipping to change at page 22, line 32
\ | \ 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 Figure 6. To handle RF channel allocation for such the left node in Figure 7. To handle RF channel allocation for such
nodes, a master node with a backhaul link relays or proxies the 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 utilize the provided RF channels. Details on forming and radios utilize 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.2.5. Mobility 4.2.6. Mobility
In this use case, the user has a non-fixed (portable or mobile) 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 device and is riding in a vehicle. The user wants to have
connectivity to another device which is also moving. Typical connectivity to another device which is also moving. Typical
deployment scenarios include urban areas and rural areas where the deployment scenarios include urban areas and rural areas where the
user may connect to other users while moving. This deployment user may connect to other users while moving. This deployment
scenario is typically characterized by a master device with low scenario is typically characterized by a master device with low
antenna height, Internet connectivity by some connection that does antenna height, Internet connectivity by some connection that does
not utilize TV white space, and some means to predict its path of not utilize TV white space, and some means to predict its path of
mobility. This knowledge of mobility could be simple (GPS plus mobility. This knowledge of mobility could be simple (GPS plus
accelerometer), sophisticated (GPS plus routing and mapping function) accelerometer), sophisticated (GPS plus routing and mapping function)
or completely specified by the user via user-interface. or completely specified by the user via user-interface.
Figure 7 shows an example deployment of this scenario. Figure 8 shows an example deployment of this scenario.
\|/ \|/ \|/ \|/
| TDD Air Interface | | TDD Air Interface |
| | | |
+-|---------+ +-|---------+ +-|---------+ +-|---------+
| TVWS | | TVWS | | TVWS | | TVWS |
|Master Dev | |Master Dev | |Master Dev | |Master Dev |
+-----------+ +-----------+ +-----------+ +-----------+
\ (----) / \ (----) /
\ ( ) / \ ( ) /
\ / \ / \ / \ /
( Internet ) ( Internet )
\ / \ /
( )\----------+ ( )\----------+
(----) | Database | (----) | Database |
+----------+ +----------+
Figure 7: Example illustration of mobility in TV white space use-case Figure 8: Example illustration of mobility in TV white space use-case
A simplified operational scenario utilizing TV whitespace to provide A simplified operational scenario utilizing TV whitespace to provide
connectivity service in a mobility environment consists of the connectivity service in a mobility environment consists of the
following steps: following steps:
1. The mobile master device powers up with its WS radio in idle or 1. The mobile master device powers up with its WS radio in idle or
listen mode only (no active transmission on the WS frequency listen mode only (no active transmission on the WS frequency
band). band).
2. The mobile master has Internet connectivity, determines its 2. The mobile master has Internet connectivity, determines its
skipping to change at page 23, line 10 skipping to change at page 25, line 10
The frequency to repeat the process is determined by the local The frequency to repeat the process is determined by the local
regulator. If the response from the master/AP indicates that a regulator. If the response from the master/AP indicates that a
channel being used by the slave or user device is not available, channel being used by the slave or user device is not available,
the slave or user device must stop transmitting on that channel the slave or user device must stop transmitting on that channel
immediately. In addition or optionally, the database may send a immediately. In addition or optionally, the database may send a
message to the master/AP to rescind the availability of one or message to the master/AP to rescind the availability of one or
more channels. The master/AP must then notify the slave or user more channels. The master/AP must then notify the slave or user
device of the rescinded channels. The slave or user device must device of the rescinded channels. The slave or user device must
stop transmitting on that channel immediately. stop transmitting on that channel immediately.
4.2.6. Indoor Networking 4.2.7. Indoor Networking
In this use case, the users are inside a house or office. The users 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 want to have connectivity to the Internet or to equipment in the same
or other houses / offices. This deployment scenario is typically or other houses / offices. This deployment scenario is typically
characterized by master devices within buildings, that are connected characterized by master devices within buildings, that are connected
to the Internet using a method that does not utilize whitespace. The to the Internet using a method that does not utilize whitespace. The
master devices can establish whitespace links between themselves, or master devices can establish whitespace links between themselves, or
between themselves and one or more user devices. between themselves and one or more user devices.
Figure 8 shows an example deployment of this scenario. Figure 9 shows an example deployment of this scenario.
\|/ \|/
| |
+-------+ | +-------+ |
|TVWS |\ +-|---------+ |TVWS |\ +-|---------+
|Usr Dev| WS AirIF \ | TVWS |\ |Usr Dev| WS AirIF \ | TVWS |\
+-------+ X|Master Dev | \ +-------+ X|Master Dev | \
/ +-----------+ \ / +-----------+ \
+-------+ WS AirIF | \ +----------+ +-------+ WS AirIF | \ +----------+
|TVWS |/ | \ (----) | Database | |TVWS |/ | \ (----) | Database |
skipping to change at page 23, line 43 skipping to change at page 25, line 43
| X( Internet ) | X( Internet )
| / \ / | / \ /
+-------+ \|/ | / ( ) +-------+ \|/ | / ( )
|TVWS |\ | | / (----) |TVWS |\ | | / (----)
|Usr Dev| WS AirIF | | / |Usr Dev| WS AirIF | | /
+-------+ \ +-|---------+ / +-------+ \ +-|---------+ /
\ | TVWS | / \ | TVWS | /
|Master Dev |/ |Master Dev |/
+-----------+ +-----------+
Figure 8: Example illustration of indoor TV white space use-case Figure 9: Example illustration of indoor TV white space use-case
A simplified operational scenario utilizing TV whitespace to provide A simplified operational scenario utilizing TV whitespace to provide
indoor networking consists of the following steps: indoor networking consists of the following steps:
1. The master device powers up with its whitespace radio in idle or 1. The master device powers up with its whitespace radio in idle or
listen mode only (no active transmission on the whitespace listen mode only (no active transmission on the whitespace
frequency band). frequency band).
2. The master device has Internet connectivity, determines its 2. The master device has Internet connectivity, determines its
location (either from location determination capability or from a location (either from location determination capability or from a
skipping to change at page 24, line 36 skipping to change at page 26, line 36
(channel validity time) (2) a maximum radiated power for each (channel validity time) (2) a maximum radiated power for each
channel, and (3) directivity and other antenna information. channel, and (3) directivity and other antenna information.
6. Once the master device authenticates the whitespace channel list 6. Once the master device authenticates the whitespace channel list
response message from the database, the master device selects one response message from the database, the master device selects one
or more available whitespace channels from the list. or more available whitespace channels from the list.
7. The user device(s) scan(s) the white space bands to locate the 7. The user device(s) scan(s) the white space bands to locate the
master device transmissions, and associates with the master. master device transmissions, and associates with the master.
4.2.7. Machine to Machine (M2M) 4.2.8. Machine to Machine (M2M)
In this use case, each "machine" includes a white space slave device In this use case, each "machine" includes a white space slave device
and can be located anywhere, fixed or on the move. Each machine and can be located anywhere, fixed or on the move. Each machine
needs to have connectivity to the Internet and or to other machines needs to have connectivity to the Internet and or to other machines
in the vicinity. Machine communication over a TVWS channel, whether in the vicinity. Machine communication over a TVWS channel, whether
to a master device or to another machine (slave device), is under the to a master device or to another machine (slave device), is under the
control of a master device. This deployment scenario is typically control of a master device. This deployment scenario is typically
characterized by a master device with Internet connectivity by some characterized by a master device with Internet connectivity by some
connection that does not utilize TV white space. connection that does not utilize TV white space.
Figure 9 shows an example deployment of this scenario. Figure 10 shows an example deployment of this scenario.
\|/ \|/
| |
| |
+-|---------+ +-|---------+
| TVWS |\ | TVWS |\
/|Master Dev | \ /|Master Dev | \
/ +-----------+ \ / +-----------+ \
WS AirIF \ +----------+ WS AirIF \ +----------+
+-------+ / \ (----) | Database | +-------+ / \ (----) | Database |
skipping to change at page 25, line 25 skipping to change at page 27, line 25
+-------+ \ / \ +-------+ \ / \
| X( Internet ) | X( Internet )
WS AirIF \ / WS AirIF \ /
| ( ) | ( )
+-------+ (----) +-------+ (----)
|Machine| |Machine|
+-------+ \ +-------+ +-------+ \ +-------+
WS AirIF-- |Machine| WS AirIF-- |Machine|
+-------+ +-------+
Figure 9: Example illustration of M2M TV white space use-case Figure 10: Example illustration of M2M TV white space use-case
A simplified operational scenario utilizing TV whitespace to provide A simplified operational scenario utilizing TV whitespace to provide
machine to machine connectivity consists of the following steps: machine to machine connectivity consists of the following steps:
1. The master device powers up with its whitespace radio in idle or 1. The master device powers up with its whitespace radio in idle or
listen mode only (no active transmission on the whitespace listen mode only (no active transmission on the whitespace
frequency band). frequency band).
2. The master device has Internet connectivity, determines its 2. The master device has Internet connectivity, determines its
location (either from location determination capability or from location (either from location determination capability or from
skipping to change at page 26, line 44 skipping to change at page 28, line 44
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.
An example high-level architecture of the devices and white space An example high-level architecture of the devices and white space
databases is shown in Figure 10: databases is shown in Figure 11:
----------- -----------
|WS Device| ------------ |WS Device| ------------
|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 10: High level view of the White space database architecture Figure 11: High level view of the White space database architecture
In Figure 10, note that there could be multiple databases serving In Figure 11, note that there could be multiple databases serving
white space devices. The databases are country specific since the white space devices. The databases are country specific since the
regulations and available spectrum may vary. In some countries, for regulations and available spectrum may vary. In some countries, for
example, the U.S., the regulator has determined that multiple, example, the U.S., the regulator has determined that multiple,
competing databases may provide service to White Space Devices. competing databases may provide service to White Space 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
spectrum. The following sections discuss various aspects of such an spectrum. The following sections discuss various aspects of such an
interface and the need for a standard. Other aspects of a solution interface and the need for a standard. Other aspects of a solution
including provisioning the database, and calculating protected including provisioning the database, and calculating protected
skipping to change at page 29, line 33 skipping to change at page 31, line 33
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
6.1. Normative Requirements 6.1. Normative Requirements
D. Data Model Requirements: D. Data Model Requirements:
D.1: The Data Model MUST support specifying the location of the D.1: The Data Model MUST support specifying the location of the
WSD, the uncertainty in meters, the height & its WSD, the uncertainty in meters, the height & its
uncertainty, and confidence in percentage for the location uncertainty, and confidence in percentage of the location
determination. The Data Model MUST support both North determination. The Data Model MUST support both North
American Datum of 1983 and WGS84. American Datum of 1983 and WGS84.
D.2: The Data Model MUST support specifying the URI address of a
white space database.
D.3: The Data Model MUST support specifying the URI address of a D.2: The Data Model MAY support specifying the regulatory domain
national listing service. and its corresponding data requirements.
D.4: The Data Model MUST support specifying the regulatory D.3: The Data Model MUST support specifying an ID of the
domain and its corresponding data requirements. transmitter device. This ID would contain the ID of the
transmitter device that has been certified by a regulatory
body for its regulatory domain. The Data Model MUST support
a device class. The Data Model MUST support specifying
information about the type of RAT of the transmitter device.
D.5: The Data Model MUST support specifying an ID of the D.4: The Data Model MUST support specifying a manufacturer's
transmitter device. This ID would contain the ID of the serial number for a master device.
transmitter device that has been certified by a regulatory
body for its regulatory domain. The Data Model MUST
support a device class.
D.6: The Data Model MUST support specifying a manufacturer's D.5: The Data Model MUST support specifying the antenna and
serial number for a master device. radiation related parameters of the subject, such as:
D.7: The Data Model MUST support specifying the antenna and antenna height
radiation related parameters of the subject, such as:
antenna height antenna gain
antenna gain maximum output power, EIRP (dBm)
maximum output power, EIRP (dBm) antenna radiation pattern (directional dependence of the
strength of the radio signal from the antenna)
antenna radiation pattern (directional dependence of the spectrum mask with lowest and highest possible frequency
strength of the radio signal from the antenna)
spectrum mask with lowest and highest possible frequency 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
spectrum mask in dBr from peak transmit power in EIRP, measurement resolution bandwidth for EIRP measurements
with specific power limit at any frequency linearly
interpolated between adjacent points of the spectrum
mask
measurement resolution bandwidth for EIRP measurements D.6: The Data Model MUST support specifying owner and operator
contact information for a transmitter. This includes the
name of the transmitter owner, name of transmitter operator,
postal address, email address and phone number of the
transmitter operator.
D.8: The Data Model MUST support specifying owner and operator D.7: The Data Model MUST support specifying a list of available
contact information for a transmitter. This includes the channels. The Data Model MUST support specification of this
name of the transmitter owner, name of transmitter information by channel numbers and by start and stop
operator, postal address, email address and phone number of frequencies. The Data Model MUST support a channel
the transmitter operator. availability schedule and maximum power level for each
channel in the list.
D.9: The Data Model MUST support specifying a list of available D.8: The Data Model MUST support specifying channel availability
channels. The Data Model MUST support specification of information for a single location and an area (e.g. a
this information by channel numbers and by start and stop polygon defined by multiple location points or a geometric
frequencies. The Data Model MUST support a channel shape such as a circle).
availability schedule and maximum power level for each
channel in the list.
D.10: The Data Model MUST support specifying channel availability D.9: The Data Model MUST support specifying the frequencies and
information for a single location and an area (e.g. a power levels selected for use by a device in the
polygon defined by multiple location points or a geometric acknowledgement message.
shape such as a circle).
P. Protocol Requirements: P. Protocol Requirements:
P.1: The protocol MUST provide a message sequence for the master P.1: The protocol MUST provide a mechanism to enable WSD
device to discover a white space database that provides discovery. In some environments, a listing of the approved
service at its current location. white space databases is maintained by the national
regulator. The protocol MUST support discovery of a
P.2: The protocol MUST support access of a database directly. database using a listing approved by a national regulator.
The protocol MUST support access of a database using a
listing approved by a national regulator.
P.3: The protocol MUST support determination of regulatory P.2: The protocol MUST support determination of regulatory
domain governing its current location. domain governing its current location.
P.4: The protocol MUST provide the ability for the database to P.3: The protocol MUST provide the ability for the database to
authenticate the master device. authenticate the master device.
P.5: The protocol MUST provide the ability for the master device P.4: The protocol MUST provide the ability for the master device
to verify the authenticity of the database with which it is to verify the authenticity of the database with which it is
interacting. interacting.
P.6: The messages sent by the master device to the database MUST P.5: The messages sent by the master device to the database MUST
be integrity protected. support integrity protection.
P.7: The messages sent by the database to the master device MUST P.6: The messages sent by the database to the master device MUST
be integrity protected. support integrity protection.
P.8: The protocol MUST provide the capability for messages sent P.7: The protocol MUST provide the capability for messages sent
by the master device and database to be encrypted. by the master device and database to be encrypted.
P.9: The protocol MUST support the master device registering P.8: The protocol MUST support the master device registering
with the database. with the database.
P.10: The protocol MUST support a registration acknowledgement P.9: The protocol MUST support a registration acknowledgement
including appropriate result codes. including appropriate result codes.
P.11: The protocol MUST support a channel query request from the P.10: The protocol MUST support a channel query request from the
master device to the database. The channel query request master device to the database. The channel query request
message MUST include parameters as required by local message MUST include parameters as required by local
regulatory requirement. These parameters MAY include regulatory requirement. These parameters MAY include any
device location, device ID, manufacturer's serial number, of the parameters and attributes required to be supported
and antenna characteristic information. in the Data Model Requirements.
P.12: The protocol MUST support a channel query response from the P.11: The protocol MUST support a channel query response from the
database to the master device. The channel query response database to the master device. The channel query response
message MUST include parameters as required by local message MUST include parameters as required by local
regulatory requirement. These parameters MAY include regulatory requirement. These parameters MAY include any
available channels, duration of time for their use, of the parameters and attributes required to be supported
associated maximum power levels, any additional sensing in the Data Model Requirements.
requirements.
P.13: The protocol MUST support a channel query request from the P.12: The protocol MUST support a channel usage message from the
slave device to the master device. The channel query master device to the database. The channel usage message
request message MUST include parameters as required by MUST include parameters as required by local regulatory
local regulatory requirement. These parameters MAY include requirement for the master and its associated slaves.
device ID and slave device location. These parameters MAY include any of the parameters and
attributes required to be supported in the Data Model
Requirements.
P.13: The protocol MUST support a channel usage message
acknowledgement.
P.14: The protocol MUST support a validation request from the P.14: The protocol MUST support a validation request from the
master to the database to validate a slave device. The master to the database to validate a slave device. The
validation request MUST include the slave device ID. validation request MUST include the slave device ID.
P.15: The protocol MUST support a validation response from the P.15: The protocol MUST support a validation response from the
database to the master. The validation response MUST database to the master to indicate if the slave device is
validated by the WSDB. The validation response MUST
include a response code. include a response code.
P.16: The protocol MUST support a channel query response from the P.16: The protocol between the master device and the database
master device to the slave device. The channel query
response message MUST include parameters as required by
local regulatory requirement, including a response code and
sufficient information to decode an enabling signal.
P.17: The protocol MUST support an enabling signal sent from the
master to the slave. This signal MUST allow the slave
device to validate that a previously received available
channel list is still valid or not. This signal MUST be
encoded to allow the slave device to determine the identity
if the sending master device.
P.18: The protocol between the master device and the database
MUST support the capability to change channel availability MUST support the capability to change channel availability
lists on short notice. information on short notice.
P.19: The protocol between the master device and the database P.17: The protocol between the master device and the database
MUST support a channel availability request which specifies MUST support a channel availability request which specifies
a geographic location as an area as well as a point. a geographic location as an area as well as a point.
O. Operational Requirements: 6.2. Non-normative requirements
O.1: The database and the master device MUST be connected to the
Internet.
O.2: A master device MUST be able to determine its location
including uncertainty and confidence level. A fixed master
device MAY use a location programmed at installation or
have the capability determine its location to the required
accuracy. A mobile master device MUST have the capability
to determine its location to the required accuracy.
O.3: The master device MUST identify a database for use. The
master device MAY select a database for service by
discovery at runtime or the master device MAY select a
database for service by means of a pre-programmed URI
address.
O.4: The master device MUST implement at least one connection O. Operational Requirements:
method to access the database. The master device MAY
contact a database directly for service (e.g. as defined by
FCC) or the master device MAY contact a listing server
first followed by contact to a database (e.g. as defined by
Ofcom).
O.5: The master device MUST obtain an indication the regulatory O.1: The database and the master device MUST be connected to the
domain governing operation at its current location, i.e. Internet.
the master device MUST know if it operates under
regulations from FCC, Ofcom, etc...
O.6: The master device MAY register with the database according O.2: A master device MUST be able to determine its location
to local regulatory policy. Not all master devices will be including uncertainty and confidence level. A fixed master
required to register. Specific events will initiate device MAY use a location programmed at installation or have
registration, these events are determined by regulator the capability determine its location to the required
policy (e.g. at power up, after movement, etc...). accuracy. A mobile master device MUST have the capability to
determine its location to the required accuracy.
O.7: The master device MUST register with its most current and O.3: The master device MUST identify a database to which it will
up-to-date information, and MUST include all variables register, make channel requests, etc... The master device MAY
mandated by local regulator policy. select a database for service by discovery at runtime or the
master device MAY select a database for service by means of a
pre-programmed URI address.
O.8: A master device MUST query the database for the available O.4: The master device MUST implement at least one connection
channels based on its current location before starting method to access the database. The master device MAY contact
radio transmission in white space. Parameters provided to a database directly for service (e.g. as defined by FCC) or
the database MAY include device location, accuracy of the the master device MAY contact a listing server first followed
location, antenna characteristic information, device by contact to a database (e.g. as defined by Ofcom).
identifier of any slave device requesting channel
information.
O.9: The database MUST respond to an available channel list O.5: The master device MUST obtain an indication the regulatory
request from an authenticated and authorized device and MAY domain governing operation at its current location, i.e. the
also provide time constraints, maximum output power, start master device MUST know if it operates under regulations from
and stop frequencies for each channel in the list and any FCC, Ofcom, etc...
additional requirements for sensing.
O.10: After connecting to a master device's radio network a slave O.6: The master device MAY register with the database according to
device MUST query the master device for a list of available local regulatory policy. Not all master devices will be
channels. The slave MUST include parameters required by required to register. Specific events will initiate
local regulatory policy, e.g. device ID, device location. registration, these events are determined by regulator policy
(e.g. at power up, after movement, etc...).
O.11: According to local regulatory policy, the master device MAY O.7: When local regulatory policy requires registration, the master
query the database with parameters received from the slave device MUST register with its most current and up-to-date
device. information, and MUST include all variables mandated by local
regulator policy.
O.12: The database MUST respond to a query from the master device O.8: A master device MUST query the database for the available
containing parameters from a slave device. channels based on its current location before starting radio
transmission in white space. Parameters provided to the
database MAY include device location, accuracy of the
location, antenna characteristic information, device
identifier of any slave device requesting channel information,
etc...
O.13: After the master device has received a response from the O.9: The database MUST respond to an available channel list request
database, the master device MUST respond to the slave from an authenticated and authorized device and MAY also
device. If all regulatory requirements are met the provide time constraints, maximum output power, start and stop
response will contain an available channel list. If frequencies for each channel in the list and any additional
regulatory requirements are not met, the response MUST requirements for sensing.
contain at least a response code.
O.14: If a master device has provided an available channel list O.10: According to local regulator policy, a master device MAY
to a slave device the master device MAY send a periodic inform the database of the actual frequecy usage of the master
enabling signal to allow the slave device to confirm it is and its slaves. The master MUST include parameters required
still within reception range of the master device. by local regulatory policy, e.g. device ID, manufacturer's
serial number, channel usage and power level information of
the master and its slaves.
O.15: The enabling signal MUST be encoded so that the receiving O.11: After connecting to a master device's radio network a slave
slave can determine the identity of the sending master. device MUST query the master device for a list of available
channels. The slave MUST include parameters required by local
regulatory policy, e.g. device ID, device location.
O.16: Periodically, at an interval according to local O.12: According to local regulatory policy, the master device MAY
regulations, the slave device MUST either receive and query the database with parameters received from the slave
enabling signal or MUST successfully repeat the channel device.
request process or MUST cease transmission on the channel.
O.17: A master device MUST repeat the query to the database for O.13: The database MUST respond to a query from the master device
the available channels as often as required by the containing parameters from a slave device.
regulation (e.g., FCC requires once per day) to verify that
the operating channels continue to remain available.
O.18: A master device which changes its location more than a O.14: A master device MUST repeat the query to the database for the
threshold distance (specified by local regulatory policy) available channels as often as required by the regulation
during its operation, MUST query the database for available (e.g., FCC requires once per day) to verify that the operating
operating channels each time it moves more than the channels continue to remain available.
threshold distance (e.g., FCC specifies 100m) from the
location it previously made the query.
O.19: If slave devices change their location during operation by O.15: A master device which changes its location more than a
more than a limit specified by the local regulator, the threshold distance (specified by local regulatory policy)
slave device MUST query the master device for available during its operation, MUST query the database for available
operating channels. operating channels each time it moves more than the threshold
distance (e.g., FCC specifies 100m) from the location it
previously made the query.
O.20: According to local regulator policy, a master device may O.16: According to local regulator policy, a master device may
contact a database via proxy service of another master contact a database via proxy service of another master device.
device.
O.21: A master device MUST be able to query the whitespace O.17: A master device MUST be able to query the whitespace database
database for channel availability information for a for channel availability information for a specific expected
specific expected coverage area around its current coverage area around its current location.
location.
O.22: A Master device MUST include its identity in messages sent O.18: A Master device MUST include its unique identity in all
to the database. message exchanges with the database.
6.2. Guidelines 6.3. Guidelines
The current scope of the working group is limited and is reflected in The current scope of the working group is limited and is reflected in
the requirements captured in Section 6.1. However white space the requirements captured in Section 6.1. However white space
technology itself is expected to evolve and address other aspects technology itself is expected to evolve and address other aspects
such as co-existence and interference avoidance, spectrum brokering, such as co-existence and interference avoidance, spectrum brokering,
alternative spectrum bands, etc. The design of the data model and alternative spectrum bands, etc. The design of the data model and
protocol should be cognizant of the evolving nature of white space protocol should be cognizant of the evolving nature of white space
technology and consider the following set of guidelines in the technology and consider the following set of guidelines in the
development of the data model and protocol: development of the data model and protocol:
 End of changes. 87 change blocks. 
255 lines changed or deleted 322 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/