draft-ietf-paws-problem-stmt-usecases-rqmts-01.txt   draft-ietf-paws-problem-stmt-usecases-rqmts-02.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: May 3, 2012 October 31, 2011 Expires: July 30, 2012 January 27, 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-01 draft-ietf-paws-problem-stmt-usecases-rqmts-02
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 46 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 May 3, 2012. This Internet-Draft will expire on July 30, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 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
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
skipping to change at page 3, line 40 skipping to change at page 3, line 40
5. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 24 5. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 24
5.1. Global applicability . . . . . . . . . . . . . . . . . . . 25 5.1. Global applicability . . . . . . . . . . . . . . . . . . . 25
5.2. Database discovery . . . . . . . . . . . . . . . . . . . . 26 5.2. Database discovery . . . . . . . . . . . . . . . . . . . . 26
5.3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 27 5.3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.4. Data model definition . . . . . . . . . . . . . . . . . . 27 5.4. Data model definition . . . . . . . . . . . . . . . . . . 27
6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 27 6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 27
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
8. Security Considerations . . . . . . . . . . . . . . . . . . . 30 8. Security Considerations . . . . . . . . . . . . . . . . . . . 30
9. Summary and Conclusion . . . . . . . . . . . . . . . . . . . . 31 9. Summary and Conclusion . . . . . . . . . . . . . . . . . . . . 31
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
11.1. Normative References . . . . . . . . . . . . . . . . . . . 31 11.1. Normative References . . . . . . . . . . . . . . . . . . . 32
11.2. Informative References . . . . . . . . . . . . . . . . . . 32 11.2. Informative References . . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33
1. Introduction 1. Introduction
1.1. Introduction to TV white space 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
skipping to change at page 27, line 34 skipping to change at page 27, line 34
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. Data Model Requirements:
D.1: The Data Model MUST support specifying the antenna height D.1: The Data Model MUST support specifying the antenna and
parameter of the subject. radiation related parameters of the subject, such as:
D.2: The Data Model MUST support specifying an ID of the subject. antenna height
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 antenna gain
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 maximum output power, EIRP (dBm)
subject and accuracy of location determination.
D.5: The Data Model MUST support specifying a list of available antenna radiation pattern (directional dependence of the
channel list and time constrains for the channel list strength of the radio signal from the antenna
availability.
D.6: The Data Model MUST support specifying the maximum output spectrum mask with lowest and highest possible frequency
power of the subject.
D.7: The Data Model MUST support specifying channel availability spectrum mask in dBr from peak transmit power in EIRP,
information for multiple locations. with specific power limit at any frequency linearly
interpolated between adjacent points of the spectrum mask
measurement resolution bandwidth for EIRP measurements
D.8: The Data Model MUST support specifying channel availability D.2: The Data Model MUST support specifying an ID of the
information for an area around a specified location. transmitter subject. This ID would contain the ID of the
transmitter device that has been certified by a regulatory
body for its regulatory domain.
D.9: The Data Model MUST support specifying multiple spectrum D.3: The Data Model MUST support specifying a contact or a list
masks, each containing (1) the lowest applicable frequency of contacts of this transmitter. For example, facility or
in MHz, (2) the highest possible frequency in MHz, (3) the on-site technical manager, administrator, any operational
maximum total EIRP over the frequency range defined by the contacts may be specified.
spectrum mask, (4) the general spectrum mask in dBr from
peak transmit power in EIRP, with specific power limit at D.4: The Data Model MUST support specifying the location of the
any frequency linearly interpolated between adjacent points WSD, the uncertainty in meters and confidence in percentage
of the spectrum mask expressed as in [80211P] or for the location determination.
[FCC47CFR90.210], and (5) measurement resolution bandwidth
for EIRP measurements. D.5: The Data Model MUST support specifying a list of available
channels and time constrains for the channel list
availability. Each channel in the list shall specify the
lower and upper frequency values for the channel and the
time intervals the channel is available.
D.6: The Data Model MUST support specifying channel availability
information for a single location and for multiple
locations. In the case of multiple locations, the database
shall provide a channel list for each of the multiple
location.
P. Protocol Requirements: P. Protocol Requirements:
P.1: The protocol MUST provide a mechanism for the subject to P.1: The protocol MUST provide a mechanism for the subject to
discover the WS Database it has to use at a given location. discover the WS Database it has to use at a given location.
P.2: The protocol MUST support regulatory domain discovery. P.2: The protocol MUST support regulatory domain discovery.
P.3: The protocol between the master device and the WS Database P.3: The protocol between the master device and the WS Database
MUST support pushing updates in channel availability MUST support pushing updates in channel availability
skipping to change at page 29, line 13 skipping to change at page 29, line 22
makes to the whitespace database. makes to the whitespace database.
P.9: A master device MUST be able to query the whitespace P.9: A master device MUST be able to query the whitespace
database for channel availability information for a database for channel availability information for a
specific expected coverage area around its current specific expected coverage area around its current
location. location.
P.10: A master device MUST send Device ID, searial number and P.10: A master device MUST send Device ID, searial number and
device location in the query it makes to the database. device location in the query it makes to the database.
P.11: A master device MAY send additional information in the P.11: A master device MAY send additional antenna characteristic
query it makes to the database such as antenna height above information in the query it makes to the database.
ground level or antenna characteristics.
P.12: A master device MUST be capable of validating the digital P.12: A master device MUST be capable of validating the digital
certificate of the WS Database. certificate of the WS Database.
P.13: A master device MUST be capable of checking the validity of P.13: A master device MUST be capable of checking the validity of
the WS Database certificate and whether it has been revoked the WS Database certificate and whether it has been revoked
or not. or not.
O. Operational Requirements: O. Operational Requirements:
O.1: A master device MUST query the WS Database for the O.1: A master device MUST query the WS Database for the
available channels as often as required by the regulation available channels as often as required by the regulation
(eg, FCC requires once per day) to verify that the (eg, FCC requires once per day) to verify that the
operating channels continue to remain available. operating channels continue to remain available.
O.2: A master device MUST determine its location with the O.2: A master device MUST determine its location along with its
accuracy required by the regulation (eg, FCC requires +/- uncertainty (e.g., FCC requires +/-50m) and confidence
100m) before placing a query to the DB. level (e.g., 95%) and send it to the database so that the
proper WSD position and buffer distance around the device
can be added to make sure that the worst case situation
required by regulations is considered in the distance
calculations taking place at the database.
O.3: A master device which changes its location during its O.3: A master device which changes its location during its
operation, MUST query the WS Database for available operation, MUST query the WS Database for available
operating channels each time it moves more than the operating channels each time it moves more than the
distance specified by the regulation (eg FCC specifies distance specified by the regulation (e.g., FCC specifies
100m) from the location it previously made the query from. 100m) from the location it previously made the query.
O.4: The WS Database MUST provide the available channel list O.4: The WS Database MUST provide the available channel list
when requested from an authenticated and authorized device when requested from an authenticated and authorized device
and MAY also provide time constraints for the channel list, and MAY also provide time constraints, maximum output power
maximum output power and start and stop frequencies for and start and stop frequencies for each channel in the
each channel to the master device. list.
O.5: A master device MUST query the WS Database and include the 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 FCC ID of the slave device in the query before allowing the
slave device to use the available channel. slave device to use the available channel.
O.6: A master device MUST be capable to validate the digital O.6: A master device MUST be capable of validating the digital
certificate of the WS Database. certificate of the WS Database and whether it has been
revoked or not.
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 O.7: A master device MUST be able to determine its location
using latitude-longitude coordinates. using latitude-longitude coordinates.
O.9: A master device MUST make a fresh query of the whitespace O.8: A master device MUST make a fresh query of the whitespace
database for the available channels within a particular database for the available channels within a particular
time interval, using a parameter sent by the database in time interval, using a parameter sent by the database in
response to the previous query. On expiry of the time response to the previous query. On expiry of the time
interval then a master device MUST cease transmission in interval then a master device MUST cease transmission in
the TVWS band if no successful query attempt has been made the TVWS band if no successful query attempt has been made
or a query has been made but the database has not or a query has been made but the database has not
responded. responded.
O.10: If slave devices change their location during operation, O.9: If slave devices change their location during operation,
the master device MUST query the whitespace database for the master device MUST query the whitespace database for
available operating channels each time a slave device moves available operating channels each time a slave device moves
outside the reported coverage location area. outside the reported coverage location area.
O.11: A master device MAY be able to indicate to slave devices O.10: A master device MAY be able to indicate to slave devices
the start and stop frequencies it has available for the start and stop frequencies it has available for
operation and the maximum permitted powers for the slave operation and the maximum permitted powers for the slave
devices, and MAY be able to send additional optional devices, and MAY be able to send additional optional
information. 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
 End of changes. 23 change blocks. 
56 lines changed or deleted 63 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/