Hello All,
I have revised Section 6 of the I-D which describes the Data Model
Requirements, Protocol Requirements and Operational Requirements. This
includes the requirements from the threat model
(http://www.ietf.org/mail-archive/web/paws/current/msg00771.html).
The requirements are ordered "top down" to follow the previous sections of
the document: requirements derived from discovery are followed by
requirements derived from registration are followed by requirements
derived from hotspot, etc...
Please review the proposed text, we hope to have your comments by Feb 28th.
Kind Regards,
Raj & Scott
D. Data Model Requirements:
<Ed. Note>requirements related to discovery function</Ed. Note>
D.1: The Data Model MUST support specifying the location of the WSD, the
uncertainty in meters, the height & its uncertainty, and confidence in
percentage for the location determination. The Data Model MUST support
both North 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 national
listing service.
D.4: The Data Model MUST support specifying regulatory domain and its
corresponding data requirements.
<Ed. Note>requirements related to registration function</Ed. Note>
D.5: The Data Model MUST support specifying an ID of the 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.
D.6: The Data Model MUST support specifying a manufacturer¹s serial number
for a master device.
D.7: The Data Model MUST support specifying the antenna and radiation
related parameters of the device, such as:
- antenna height
- antenna gain
- maximum output power, EIRP (dBm)
- antenna radiation pattern (directional dependence
of the 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
measurement resolution bandwidth for EIRP measurements.
D.8: 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.
<Ed. Note>requirements related to hotspot use case</Ed. Note>
D.9: The Data Model MUST support specifying a list of available channels.
The Data Model MUST support specification of this information by channel
numbers and by start and stop frequencies. The Data Model MUST support a
channel availability schedule and maximum power level for each channel in
the list.
<Ed. Note>requirements related to mobility use case</Ed. Note>
D.10: The Data Model MUST support specifying channel availability
information for a single location and an area (e.g. a polygon defined by
multiple location points or a geometric shape such as a circle).
P. Protocol Requirements:
<Ed. Note>requirements related to discovery function</Ed. Note>
P.1: The protocol MUST provide a message sequence for the master device to
discover a white space database that provides service at its current
location.
P.2: The protocol MUST support access of a database directly. 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 domain
governing its current location.
<Ed. Note>requirements related to threat model</Ed. Note>
P.4: The protocol MUST provide the ability for the database to
authenticate the master device.
P.5: The protocol MUST provide the ability for the master device to verify
the authenticity of the database with which it is interacting.
P.6: The messages sent by the master device to the database MUST be
integrity protected.
P.7: The messages sent by the database to the master device MUST be
integrity protected.
P.8: The protocol MUST provide the capability for messages sent by the
master device and database to be encrypted.
<Ed. Note>requirements related to registration function</Ed. Note>
P.9: The protocol MUST support the master device registering with the
database.
P.10: The registration signaling MAY include the Device ID, manufacturer¹s
serial number, device location, device antenna characteristic information,
name of individual or business that owns the device, name, address, email
address and phone number of a contact person who is responsible for device
operation.
P.11: The protocol MUST support a registration acknowledgement including
appropriate result codes.
<Ed. Note>requirements related to hotspot use case</Ed. Note>
P.12: The protocol MUST support a channel query request from the master
device to the database. The channel query request message MUST include
parameters as required by local regulatory requirement. These parameters
MAY include device location, device ID, manufacturer¹s serial number, and
antenna characteristic information.
P.13: The protocol MUST support a channel query response from the database
to the master device. The channel query response message MUST include
parameters as required by local regulatory requirement. These parameters
MAY include available channels, duration of time for their use, associated
maximum power levels, any additional sensing requirements.
P.14: The protocol MUST support a channel query request from the slave
device to the master device. The channel query request message MUST
include parameters as required by local regulatory requirement. These
parameters MAY include device ID and slave device location.
P.15: The protocol MUST support a validation request from the master to
the database to validate a slave device. The validation request MUST
include the slave device ID.
P.16: The protocol MUST support a validation response from the database to
the master. The validation response MUST include a response code.
P.17: The protocol MUST support a channel query response from the 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.18: 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.19: The protocol between the master device and the database MUST support
the capability to change channel availability lists on short notice.
<Ed. Note>requirements related to mobility use case</Ed. Note>
P.20: The protocol between the master device and the database MUST support
a channel availability request which specifies a geographic location as an
area as well as a point.
O. Operational Requirements:
<Ed. Note>requirements related to discovery function</Ed. Note>
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 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 domain
governing operation at its current location, i.e. the master device MUST
know if it operates under regulations from FCC, Ofcom, etcŠ
<Ed. Note>requirements related to registration function</Ed. Note>
O.6: The master device MAY register with the database according to local
regulatory policy. Not all master devices will be required to register.
Specific events will initiate registration, these events are determined by
regulator policy (e.g. at power up, after movement, etcŠ).
O.7: The master device MUST register with its most current and up-to-date
information.
<Ed. Note>requirements related to hotspot use case</Ed. Note>
O.8: A master device MUST query the database for the available 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.
O.9: The database MUST respond to an available channel list request from
an authenticated and authorized device and MAY also provide time
constraints, maximum output power, start and stop frequencies for each
channel in the list and any additional requirements for sensing.
O.10: After connecting to a master device¹s radio network a slave 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.11: According to local regulatory policy, the master device MAY query
the database with parameters received from the slave device.
O.12: The database MUST respond to a query from the master device
containing parameters from a slave device.
O.13: After the master device has received a response from the database,
the master device MUST respond to the slave device. If all regulatory
requirements are met the response will contain an available channel list.
If regulatory requirements are not met, the response MUST contain at least
a response code.
O.14: If a master device has provided an available channel list to a slave
device the master device MAY send a periodic enabling signal to allow the
slave device to confirm it is still within reception range of the master
device.
O.15: The enabling signal MUST be encoded so that the receiving slave can
determine the identity of the sending master.
O.16: Periodically, at an interval according to local regulations, the
slave device MUST either receive and enabling signal or MUST successfully
repeat the channel request process or MUST cease transmission on the
channel.
O.17: A master device MUST repeat the query the 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.18: A master device which changes its location more than a threshold
distance specified by local regulatory policy during its operation, MUST
query the database for available operating channels each time it moves
more than the threshold distance (e.g., FCC specifies 100m) from the
location it previously made the query.
<Ed. Note>requirements related to wran use case</Ed. Note>
O.19: If slave devices change their location during operation by more than
a limit specified by the local regulator, the slave device MUST query the
master device for available operating channels.
<Ed. Note>requirements related to rapid deployed network use case</Ed.
Note>
O.20: According to local regulator policy, a master device may contact a
database via proxy service of another master device.
<Ed. Note>requirements related to mobility use case</Ed. Note>
O.21: 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.
<Ed. Note>requirements related to threat model</Ed. Note>
O.22: A Master device MAY not include its identity in
messages sent to the database when not required by the regulatory
_______________________________________________
paws mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/paws
