draft-ietf-paws-problem-stmt-usecases-rqmts-05.txt   draft-ietf-paws-problem-stmt-usecases-rqmts-06.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: December 23, 2012 June 21, 2012 Expires: January 3, 2013 July 2, 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-05 draft-ietf-paws-problem-stmt-usecases-rqmts-06
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 December 23, 2012. This Internet-Draft will expire on January 3, 2013.
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 23, line 16 skipping to change at page 23, line 16
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 8 shows an example deployment of this scenario. Figure 8 shows an example deployment of this scenario.
\|/ \|/ \|/ \|/
| TDD Air Interface | | |
| | | |
+-|---------+ +-|---------+ +-|---------+ +-|---------+
| TVWS | | TVWS | | TVWS | | TVWS |
|Master Dev | |Master Dev | |Master Dev | |Master Dev |
+-----------+ +-----------+ +-----------+ +-----------+
\ (----) / \ \ (----) / \
\ ( ) / \ \|/ \ ( ) / \ \|/
\ / \ / \ | \ / \ / WS AirIF |
( Internet ) \ | ( Internet ) \ |
\ / \+-|--------+ \ / \+-|--------+
( )\----------+ | TVWS | ( )\----------+ | TVWS |
(----) | Database | |Slave Dev | (----) | Database | |Slave Dev |
+----------+ +----------+ +----------+ +----------+
Figure 8: 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
skipping to change at page 34, line 43 skipping to change at page 34, line 43
6.2. Non-normative requirements 6.2. Non-normative requirements
O. Operational Requirements: O. Operational Requirements:
O.1: The database and the master device MUST be connected to the O.1: The database and the master device MUST be connected to the
Internet. Internet.
O.2: A master device MUST be able to determine its location O.2: A master device MUST be able to determine its location
including uncertainty and confidence level. A fixed master including uncertainty and confidence level. A fixed master
device MAY use a location programmed at installation or have device MAY use a location programmed at installation or have
the capability determine its location to the required the capability to determine its location to the required
accuracy. A mobile master device MUST have the capability to accuracy. A mobile master device MUST have the capability to
determine its location to the required accuracy. determine its location to the required accuracy.
O.3: The master device MUST identify a database to which it will O.3: The master device MUST identify a database to which it will
register, make channel requests, etc... The master device MAY register, make channel requests, etc... The master device MAY
select a database for service by discovery at runtime or the select a database for service by discovery at runtime or the
master device MAY select a database for service by means of a master device MAY select a database for service by means of a
pre-programmed URI address. pre-programmed URI address.
O.4: The master device MUST implement at least one connection O.4: The master device MUST implement at least one connection
skipping to change at page 35, line 41 skipping to change at page 35, line 41
identifier of any slave device requesting channel information, identifier of any slave device requesting channel information,
etc... etc...
O.8: The database MUST respond to an available channel list request O.8: The database MUST respond to an available channel list request
from an authenticated and authorized device and MAY also from an authenticated and authorized device and MAY also
provide time constraints, maximum output power, start and stop provide time constraints, maximum output power, start and stop
frequencies for each channel in the list and any additional frequencies for each channel in the list and any additional
requirements for sensing. requirements for sensing.
O.9: According to local regulator policy, a master device MAY O.9: According to local regulator policy, a master device MAY
inform the database of the actual frequecy usage of the master inform the database of the actual frequency usage of the
and its slaves. The master MUST include parameters required master and its slaves. The master MUST include parameters
by local regulatory policy, e.g. device ID, manufacturer's required by local regulatory policy, e.g. device ID,
serial number, channel usage and power level information of manufacturer's serial number, channel usage and power level
the master and its slaves. information of the master and its slaves.
O.10: After connecting to a master device's radio network a slave O.10: After connecting to a master device's radio network a slave
device MUST query the master device for a list of available device MUST query the master device for a list of available
channels. The slave MUST include parameters required by local channels. The slave MUST include parameters required by local
regulatory policy, e.g. device ID, device location. regulatory policy, e.g. device ID, device location.
O.11: According to local regulatory policy, the master device MAY O.11: According to local regulatory policy, the master device MAY
query the database with parameters received from the slave query the database with parameters received from the slave
device. device.
 End of changes. 7 change blocks. 
11 lines changed or deleted 11 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/