Subject: [paws] Requirements

From: <[email-masked]>
Date: Fri, 9 Sep 2011 19:55:11 +0000

Folks,

If you'll read this draft, you'll notice that section 6, the requirements section, is empty. During the Quebec meeting we agreed that these requirements will be reformulated and discussed on the list before including them onto the draft. I made a first attempt to reformulate the requirements and I'd like to post them to the list to start a discussion on them. There are lots of requirements still missing, so I'd welcome proposals for additional requirements, as well as comments to these requirements:

=====================================
Requirements

D. Data Model Requirements:

D.1: The Data Model MUST support specifying the antenna height parameter of the subject

D.2: The data model MUST support specifying an ID of the subject. This ID would be the ID of the device used to be certified by a regulatory body for a regulatory domain

D.3: The Data Model MUST support specifying the location of the subject and accuracy of location determination

D.4: The Data Model MUST support specifying a list of available channel list and time constrains for the channel list availability.

D.5: The Data Model MUST support specifying the maximum output power of the subject.

D.6: The Data Model MUST support specifying channel availability information for multiple locations.

D.7: The Data Model MUST support specifying channel availability information for an area around a specified location.

P. Protocol Requirements:

P.1: The protocol MUST provide a mechanism for the subject to discover the WS Database it has to use at a given location.

P.2: The protocol MUST support regulatory domain discovery.

P.3: The protocol between the master device and the WS Database MUST support pushing updates in channel availability changes to subjects 

P.4: The protocol between the master device and the WS Database MUST support mutual authentication and authorization.

P.5: The protocol between the master device and the WS Database MUST support integrity and confidentiality protection.

P.6: The protocol MUST support both username/password and digital certificates based authentication.

O. Operational Requirements:

O.1: A master device MUST query the WS Database for the available channels as often as required by the regulation (eg, FCC requires once per day) to verify that the operating 

channels continue to remain available.

O.2: A master device MUST determine its location with the accuracy required by the regulation (eg, FCC requires +/- 100m) before placing a query to the DB

O.3: A master device which changes its location during its operation, MUST query the WS Database for available operating channels each time it moves more than the distance 

specified by the regulation (eg FCC specifies 100m) from the location it previously made the query from.

O.4: The WS Database MUST provide the available channel list when requested and MAY also provide time constraints for the channel list and maximum output power to the master 

device.

O.5: A master device MUST query the WS Database and include the FCC ID of the slave device in the query before allowing the slave device to use the available channel.

O.6: A master device MUST be capable to validate the digital certificate of the WS Database.

O.7: A master device MUST be capable to check the validity of the WS Database certificate and whether it has been revoked or not.

==========================================================
-Gabor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext [email-masked]
Sent: Friday, September 09, 2011 10:08 AM
To: [email-masked]
Cc: [email-masked]
Subject: [paws] I-D Action: draft-ietf-paws-problem-stmt-usecases-rqmts-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Protocol to Access WS database Working Group of the IETF.

	Title           : Protocol to Access White Space database: PS, use cases and rqmts
	Author(s)       : Scott Probasco
                          Gabor Bajko
                          Basavaraj Patil
                          Brian Rosen
	Filename        : draft-ietf-paws-problem-stmt-usecases-rqmts-00.txt
	Pages           : 25
	Date            : 2011-09-09

   Portions of the radio spectrum that are allocated to a licensed,
   primary user but are unused or unoccupied at specific locations and
   times are defined as &quot;white space&quot;.  The concept of allowing
   secondary transmissions (licensed or unlicensed) in white space is a
   technique to &quot;unlock&quot; existing spectrum for new use.  An obvious
   requirement is that these secondary transmissions do not interfere
   with the primary use of the spectrum.  One approach to using the
   white space spectrum at a given time and location is to verify with a
   database available channels.

   This document describes the concept of TV White Spaces.  It also
   describes the problems that need to be addressed for enabling the use
   of the primary user owned white space spectrum for secondary users,
   without causing interference, by querying a database which knows the
   channel availability at any given location and time.  A number of
   possible use cases of this spectrum and derived requirements are also
   described.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-paws-problem-stmt-usecases-rqmts-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-paws-problem-stmt-usecases-rqmts-00.txt
_______________________________________________
paws mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/paws