Internet DRAFT - draft-zuniga-paws-uk-use-cases-and-requirements
draft-zuniga-paws-uk-use-cases-and-requirements
PAWS Working Group JC. Zuniga
Internet-Draft InterDigital Communications, LLC
Intended status: Informational A. Sago
Expires: April 18, 2012 M. Fitch
BT
October 16, 2011
UK Use Cases and Requirements
draft-zuniga-paws-uk-use-cases-and-requirements-00
Abstract
This document proposes a simplification of the PAWS database
discovery use case, two new use cases for indoor networking and
machine to machine communications, and a set of requirements that
drop out of all the use cases included so far in the working
document. These use cases and requirements especially address the TV
White Spaces needs in the United Kingdom, as currently known.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 18, 2012.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Zuniga, et al. Expires April 18, 2012 [Page 1]
Internet-Draft UK Use Cases and Requirements October 2011
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Terminology . . . . . . . . . . . . . . . . . . 3
2.1. Conventions Used in This Document . . . . . . . . . . . . . 3
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Use-Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. TVWS Database Discovery (proposed modifications to WG
document) . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.2. Indoor Networking . . . . . . . . . . . . . . . . . . . . . 4
3.3. Machine to Machine (M2M) . . . . . . . . . . . . . . . . . 5
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Master . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Database . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.3. Security . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
8. Informative References . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Zuniga, et al. Expires April 18, 2012 [Page 2]
Internet-Draft UK Use Cases and Requirements October 2011
1. Introduction
This docuement proposes some modifications to the TV White Spaces use
cases and requirements described in
[I-D.ietf-paws-problem-stmt-usecases-rqmts]. Similarly, some
additional ones are presented. These use cases and requirements are
meant to address especifically the regulatory needs of the UK, as
currently known.
2. Conventions and Terminology
2.1. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
2.2. Terminology
Model ID
A unique number for each master device and slave device that
identifies the manufacturer, model number and serial number.
3. Use-Cases
3.1. TVWS Database Discovery (proposed modifications to WG document)
This use case is preliminary to creating a radio network using TV
white space; it is a prerequisite to other use cases. The radio
network is created by a master device. Before the master device can
transmit in TV white space spectrum, it must contact a trusted
database where the device can learn which channels are available for
it to use. The master device will need to discover a trusted
database in the relevant regulatory environment, using the following
steps:
1. The master device is connected to the internet by any means other
than using the TV white space radio.
2. The master device constructs and sends a service request over the
Internet to discover availability of trusted databases in the
local domain and waits for responses.
3. If no acceptable response is received within a pre-configured
time limit, the master device concludes that no trusted database
is available. If at least one response is received, the master
device evaluates the response(s) to determine if a trusted
database can be identified where the device is able to register
and receive service from the database.
Zuniga, et al. Expires April 18, 2012 [Page 3]
Internet-Draft UK Use Cases and Requirements October 2011
Optionally the initial query will be made to a listing approved by
the national regulator for the domain of operation (e.g. a website
either hosted by or under control of the national regulator) which
maintains a list of TVWS databases and their internet addresses. The
query results in the list of databases and their internet addresses
being sent to the master, which then evaluates the response to
determine if a trusted database can be identified where the master
device is able to register and receive service from the database.
3.2. Indoor Networking
In this use case, the users are inside a house or office. The users
want to have connectivity to the internet or to equipment in the same
or other houses / offices. This deployment scenario is typically
characterized by master devices within buildings, that are connected
to the Internet using a method that does not utilise TV whitespace.
The master devices can establish TV whitespace links between
themselves, or between themselves and one or more user devices.
Figure 1 is an illustration of the arrangement.
\|/
|
+-------+ |
|TVWS |\ +-|---------+
|Usr Dev| WS AirIF \ | TVWS |\
+-------+ X|Master Dev | \
/ +-----------+ \
+-------+ WS AirIF | \ +----------+
|TVWS |/ | \ (----) | Database |
|Usr Dev| | \ ( ) /----------+
+-------+ WS AirIF \ / \
| X( Internet )
| / \ /
+-------+ \|/ | / ( )
|TVWS |\ | | / (----)
|Usr Dev| WS AirIF | | /
+-------+ \ +-|---------+ /
\ | TVWS | /
|Master Dev |/
+-----------+
Figure 1: Example illustration of indoor TV Whitespace use-case
A simplified operational scenario utilizing TV whitespace to provide
indoor networking consists of the following steps:
Zuniga, et al. Expires April 18, 2012 [Page 4]
Internet-Draft UK Use Cases and Requirements October 2011
1. The master device powers up with its whitespace radio in idle or
listen mode only (no active transmission on the whitespace
frequency band).
2. The master device has internet connectivity and establishes a
connection to a trusted white space database (see Section 3.1
above).
3. The master device sends its geolocation and location uncertainty
information, and optionally additional information which may
include (1) device ID and (2) antenna characteristics, to a
trusted database, requesting a list of available whitespace
channels based upon this information.
4. The database responds with a list of available white space
channels that the master device may use, and optional information
which may include inter alia (1) a duration of time for the use
of each channel (channel validity time) (2) a maximum radiated
power for each channel, (3) an indication of the quality of the
spectrum for each channel and (4) directivity and other antenna
information.
5. Once the master device authenticates the whitespace channel list
response message from the database, the master device selects one
or more available whitespace channels from the list.
6. The user device(s) scan(s) the TV white space bands to locate the
master device transmissions, and associates with the master.
7. The master device acknowledges to the database which of the
available whitespace channels it has selected for its operation,
and optionally other information, such as maximum transmit power
and antenna characteristics. The database is updated with the
information provided by the master device, in order to inform the
channel quality information provided to other masters in
subsequent requests.
3.3. Machine to Machine (M2M)
In this use case, machines include a whitespace device and can be
located anywhere, fixed or on the move. The machines want to have
connectivity to the internet or to other machines in the vicinity.
All machines are slave devices, and machine communication over a TVWS
channel, whether to a master device or to another machine, is under
the control of the master device. This deployment scenario is
typically characterized by a master device with internet connectivity
by some connection that does not utilize TV white space. Figure 2 is
an illustration of the arrangement.
Zuniga, et al. Expires April 18, 2012 [Page 5]
Internet-Draft UK Use Cases and Requirements October 2011
\|/
|
|
+-|---------+
| TVWS |\
/|Master Dev | \
/ +-----------+ \
WS AirIF \ +----------+
+-------+ / \ (----) | Database |
|Machine| \ ( ) /----------+
+-------+ \ / \
| X( Internet )
WS AirIF \ /
| ( )
+-------+ (----)
|Machine|
+-------+ \ +-------+
WS AirIF-- |Machine|
+-------+
Figure 2: Example illustration of M2M TV Whitespace use-case
A simplified operational scenario utilizing TV white space to provide
indoor networking consists of the following steps:
1. The master device powers up with its whitespace radio in idle or
listen mode only (no active transmission on the whitespace
frequency band).
2. The master device has internet connectivity and establishes a
connection to a trusted white space database (see Section 3.1
above).
3. The master device sends its geolocation and location uncertainty
information, and optionally additional information which may
include (1) device ID and (2) antenna characteristics, to a
trusted database, requesting a list of available whitespace
channels based upon this information.
4. The database responds with a list of available white space
channels that the master device may use, and optional information
which may include inter alia (1) a duration of time for the use
of each channel (channel validity time) (2) a maximum radiated
power for each channel, (3) an indication of the quality of the
spectrum for each channel and (4) directivity and other antenna
information.
5. Once the master device authenticates the whitespace channel list
response message from the database, the master device selects one
or more available whitespace channels from the list.
Zuniga, et al. Expires April 18, 2012 [Page 6]
Internet-Draft UK Use Cases and Requirements October 2011
6. The devices fitted to the machines scan the TV bands to locate
the master transmissions, and associate with the master device.
Further signalling can then take place to establish direct links
among those machines that have associated with the master device.
7. The master device acknowledges to the database which of the
available whitespace channels it has selected for its operation,
and optionally other information, such as channel resource
information (e.g. duty cycle), maximum radiated power and antenna
characteristics. The database is updated with the information
provided by the master device, in order to inform the channel
quality information provided to other masters in subsequent
requests.
4. Requirements
4.1. Master
1. A master device MUST include a mechanism to locate a trusted
whitespace database.
2. A master device MAY register with a trusted white space
database.
3. A master device MUST be able to determine its location using
latitude-longitude coordinates.
4. A master device MUST determine its location with at least +/- x
meters accuracy, where the value of x is defined by the
regulator for each regulatory domain and is well known.
5. A master device MUST place its location into the query it makes
to the whitespace database.
6. A master device MUST be able to query the whitespace database
for channel availability information for a specific expected
coverage area around its current location.
7. A master device MUST be able to pass the accuracy of its
determined location in the query it makes to the whitespace
database.
8. A master device MAY send additional information in the query it
makes to the database such as antenna height above ground level,
device ID or antenna characteristics.
9. A master device MUST make a fresh query of the whitespace
database for the available channels within a particular time
interval, using a parameter sent by the database in response to
the previous query. On expiry of the time interval then a
master device MUST cease transmission in the TVWS band if no
successful query attempt has been made or a query has been made
but the database has not responded.
10. If slave devices change their location during operation, the
master device MUST query the whitespace database for available
operating channels each time a slave device moves outside the
Zuniga, et al. Expires April 18, 2012 [Page 7]
Internet-Draft UK Use Cases and Requirements October 2011
reported coverage location area.
11. Before transmitting in the TVWS band, a master device MAY send
back to the whitespace database the start and stop frequencies
it has chosen for operation and MAY send back additional
optional information such as actual radiated power, antenna
characteristics or channel resource information.
12. A master device MAY be able to indicate to slave devices the
start and stop frequencies it has available for operation and
the maximum permitted powers for the slave devices, and MAY be
able to send additional optional information.
4.2. Database
1. The whitespace database MUST provide the available channel list
on receipt of a query from a master device as start and stop
frequencies for each channel.
2. The whitespace database MAY also provide allowable power limits
for each channel.
3. The whitespace database MAY also provide time validity
constraints for each channel.
4. The whitespace database MAY also provide other parameters to the
master device.
5. The whitespace database MAY be able to accept optional messaging
sent back from master devices indicating the start and stop
frequencies the master device has chosen for operation and MAY be
able to accept additional information such as actual radiated
power, antenna characteristics or channel resource information.
4.3. Security
1. The protocol between the master device and the WS Database MUST
support mutual authentication and authorization.
2. The protocol between the master device and the WS Database MUST
support integrity and confidentiality protection.
3. The WS Database MUST support both username/password and digital
certificates based authentication of the master device.
4. A master device MUST be capable of validating the digital
certificate of the WS Database.
5. A master device MUST be capable of checking the validity of the
WS Database certificate and whether it has been revoked or not.
5. Security Considerations
The messaging interface between the white space device and the
database needs to be secured. Security requirements are listed in
Section 4.3.
Zuniga, et al. Expires April 18, 2012 [Page 8]
Internet-Draft UK Use Cases and Requirements October 2011
6. IANA Considerations
This document has no requests to IANA.
7. Acknowledgements
The authors would like to acknowledge Martino Freda for all the
fruitful discussions on this topic.
8. Informative References
[I-D.ietf-paws-problem-stmt-usecases-rqmts]
Probasco, S., Bajko, G., Patil, B., and B. Rosen,
"Protocol to Access White Space database: PS, use cases
and rqmts", draft-ietf-paws-problem-stmt-usecases-rqmts-00
(work in progress), September 2011.
Authors' Addresses
Juan Carlos Zuniga
InterDigital Communications, LLC
Montreal, Quebec
Canada
Email: juancarlos.zuniga@interdigital.com
Andy Sago
BT
Martlesham Heath, Suffolk
United Kingdom
Email: andy.sago@bt.com
Michael Fitch
BT
Martlesham Heath, Suffolk
United Kingdom
Email: michael.fitch@bt.com
Zuniga, et al. Expires April 18, 2012 [Page 9]
