Subject: [paws] UC&R I-D: Requirements

From: <[email-masked]>
Date: Tue, 21 Feb 2012 23:53:56 +0000

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

---

From: ZhuLei <[email-masked]>
Date: Wed, 22 Feb 2012 06:40:43 +0000

I had a comment on framework of it and probably discuss it before touching timeline. 

It is a easy to think about the distributed or hierarchical implementation of paws for some reasons. One is that the database dominated by a regulator which may distribute responsibilities of different areas or regions to branches of her. This need allows subset of database working by maintaining available channel lists database in particular area or for some purposes. 

As discussed in this mail list, database is in charge of storing and maintaining white space channel information for a large area (e.g. a country) and it may be operated by regulatory body, in the current system architecture all the master devices query white space directly from database, but in if an entity is added between master device and database, and this entity is in charge of allocating white space for master devices, the application of white space will be more flexible. For example, a white space user owns a lot of master devices and it wants to establish wireless network using these master device, it can set a coordinating database which gets white space in its area from database and all of its master devices query white space from the coordinating database, because the master devices don’t query white space from database so the burden of database will be reduced, and because the white space user owns the coordinating database so it can implement its policy of using spectrum.

Master device can get white space from the coordinating database just like getting white space from database; the coordinating database can be maintained and operated by regulatory body (e.g. FCC).

So, here, an optional system framework is proposed, compared with the commonly discussed one a named coordinating database is added.
                          +-------------+
    +-------------+       |Coordinatin  |        +-----------+
    |Master Device+--+----+Database     +----+---+Database   |
    +-------------+ WS    +-------------+   WS   +-----------+

Figure 1 An additional architecture of white space database querying system

             +----------------------------+
             |                +-------+   |
             | +--------+     |Master |   |
             | |Database|     |Devices|   |
             | +--------+     +-------+   |
             |Coordinating Database       |
             +----------------------------+
Figure 2 Logical Function of Coordinating Database

Best regards,
Zhu Lei
HUAWEI TECHNOLOGIES CO.,LTD. 

Address: Huawei Building, No3 Xinxi Road
ShangDi Information Indurstry Base, Haidian District
Beijing 100085, China
Tel: +86-10-82836301
Fax: +86-10-82836920
Mobile: +86-13910157020
E-mail: [email-masked]
www.huawei.com
-------------------------------------------------------------------------------------------------------------------------------------
This e-mail and its attachments contain confidential information from HUAWEI, which 
is intended only for the person or entity whose address is listed above. Any use of the 
information contained herein in any way (including, but not limited to, total or partial 
disclosure, reproduction, or dissemination) by persons other than the intended 
recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by 
phone or email immediately and delete it!

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表 [email-masked]
发送时间: 2012年2月22日 7:54
收件人: [email-masked]
主题: [paws] UC&R I-D: Requirements

Hello All,

Kind Regards,

Raj & Scott

 

   - antenna height
 
   - antenna gain

 

 

 

 

 

 

 

 

 

_______________________________________________
paws mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/paws

---

From: Teco Boot <[email-masked]>
Date: Wed, 22 Feb 2012 08:34:38 +0100

Scott, Ray,

The P.* are mostly MUST requirements for the protocol. That's fine.
Except P.10, this is a MAY operational requirement. The protocol 
MUST support it.

I'm fine with the rest of it.

Is noted somewhere that we (IETF) do our best to support as many 
regulator rules as possible, and leave setting up requirements for 
actual deployment up to the mandated authorities? This makes the 
O.* requirements informational.

Thanks, Teco

---

From: <[email-masked]>
Date: Fri, 24 Feb 2012 18:49:12 +0000

Hello Lei,

I do support the concept you describe below, where a device may function
to coordinate the operation of multiple masters. Thinking strictly about
the connections required to implement this service, I believe requirement
O.20 may support the concept you describe.

Reviewing the operational system framework you describe below, this seems
to me to be very similar to previous discussions in this work group which
were determined to be out of scope. Before considering if additional use
cases or requirements are appropriate, I propose to ask the working group
leaders to comment on the scope of this framework.

Kind Regards,
Scott

On 2/22/12 12:40 AM, "ext ZhuLei" <[email-masked]> wrote:

>It is a easy to think about the distributed or hierarchical
>implementation of paws for some reasons. One is that the database
>dominated by a regulator which may distribute responsibilities of
>different areas or regions to branches of her. This need allows subset of
>database working by maintaining available channel lists database in
>particular area or for some purposes.
>
>As discussed in this mail list, database is in charge of storing and
>maintaining white space channel information for a large area (e.g. a
>country) and it may be operated by regulatory body, in the current system
>architecture all the master devices query white space directly from
>database, but in if an entity is added between master device and
>database, and this entity is in charge of allocating white space for
>master devices, the application of white space will be more flexible. For
>example, a white space user owns a lot of master devices and it wants to
>establish wireless network using these master device, it can set a
>coordinating database which gets white space in its area from database
>and all of its master devices query white space from the coordinating
>database, because the master devices don’t query white space from
>database so the burden of database will be reduced, and because the white
>space user owns the coordinating database so it can implement its policy
>of using spectrum.
>
>Master device can get white space from the coordinating database just
>like getting white space from database; the coordinating database can be
>maintained and operated by regulatory body (e.g. FCC).
>
>So, here, an optional system framework is proposed, compared with the
>commonly discussed one a named coordinating database is added.
>                          +-------------+
>--------------------------------------------------------------------------
>-----------------------------------------------------------

---

From: <[email-masked]>
Date: Fri, 24 Feb 2012 18:58:38 +0000

Hello Teco,

Since PAWS is a global standard, registration for all regulatory domains
must be supported. While the FCC does require all of the variables listed
in P.10, other regulatory domains may not require each of those variables.
So for requirements on the protocol, using MAY enables the FCC to require
these variables while allowing other regulators to select a subset, or
even different, variables.

With this explanation, are you okay with MAY in P.10?

Kind Regards,
Scott

On 2/22/12 1:34 AM, "ext Teco Boot" <[email-masked]> wrote:

>Op 22 feb. 2012, om 00:53 heeft <[email-masked]>
><[email-masked]> het volgende geschreven:
>
>> Hello All,
>>

---

From: Teco Boot <[email-masked]>
Date: Sun, 26 Feb 2012 22:41:09 +0100

Hi Scott,

I still think it is a MUST for the protocol, and a MAY for usage.

Thanks, Teco

---

From: <[email-masked]>
Date: Mon, 27 Feb 2012 13:32:22 +0000

Hi Teco,

If we look at P.9 and P.10 together, P.9 says that registration is a MUST
-- the protocol supports registration without question. P.10 says the
signaling for registration MAY contain any of several variables (also
allows more variables to be included if required by local regulations).
The list currently identifies all variables required for registration in
the US. Now if we look at the Data Model requirements, each variable
identified that the registration service MAY contain (these are in D.5,
D.6, D.1, D.7 and D.8) MUST be included in the Data Model. The protocol
MUST support registration, and the Data Model in the protocol MUST support
the variables identified for registration service.

The current use of MUST in P.9 and MAY in P.10 has the effect that WSDs in
the US are allowed to register (because the protocol supports
registration) and are allowed to use the variables defined by the FCC
(because the registration signaling MAY include those variables). This
also has the effect that WSDs in the UK (or elsewhere in the world) are
allowed to register if this is a local requirement (because the protocol
supports registration) and are allowed to use (or not use) the variables
defined by the FCC (because the registration signaling MAY include those
variables). Nothing to prevent adding more variables if needed by Ofcom,
IDA, etc...

Another possibility is to change the wording of P.10 to read
P.10: The registration signaling MUST include the following optional
variables: 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.

What do you think?

Kind Regards,
Scott

On 2/26/12 3:41 PM, "ext Teco Boot" <[email-masked]> wrote:

>Op 24 feb. 2012, om 19:58 heeft <[email-masked]>
>>>> The requirements are ordered "top down" to follow the previous
>>>>sections
>>>> of
>>>> P.1: The protocol MUST provide a message sequence for the master
>>>>device
>>>> to
>>>> P.16: The protocol MUST support a validation response from the
>>>>database
>>>> to
>>>> P.18: The protocol MUST support an enabling signal sent from the
>>>>master
>>>> to
>>>> a channel availability request which specifies a geographic location
>>>>as
>>>> an
>>>> area as well as a point.
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> listing server first followed by contact to a database (e.g. As
>>>>defined
>>>> by
>>>> Ofcom).
>>>> 
>>>> 
>>>> Specific events will initiate registration, these events are
>>>>determined
>>>> by

---

From: Teco Boot <[email-masked]>
Date: Mon, 27 Feb 2012 21:25:15 +0100

Hello Scott,

I understand your point. But I want to keep things simple. The 
P.* requirements are for the protocol, it MUST support optional
variables.
The O.* requirements explain how these are used. This is the MAY, 
right? 

Having performed some tests today with an emergency responders 
network, I saw some high traffic load. Something like this:
     <self_explaining_variable_name>
         1
     <\self_explaining_variable_name>
I could think of an efficiency requirement, for the rapid deployed 
network use case.

Thanks, Teco

---

From: <[email-masked]>
Date: Mon, 27 Feb 2012 20:46:43 +0000

Hi Teco,

We could change O.7 to something like:

O.7: The master device MUST register with its most current and up-to-date
information, and MUST include all variables mandated by local regulator
policy.

Would this work?

Kind Regards,
Scott

On 2/27/12 2:25 PM, "ext Teco Boot" <[email-masked]> wrote:

>Op 27 feb. 2012, om 14:32 heeft <[email-masked]>
>>>>>> Please review the proposed text, we hope to have your comments by
>>>>>>Feb
>>>>>> 28th.
>>>>>> 
>>>>>> Kind Regards,
>>>>>> 
>>>>>> Raj & Scott
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> channel availability schedule and maximum power level for each
>>>>>>channel
>>>>>> in
>>>>>> the list.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> information for a single location and an area (e.g. a polygon
>>>>>>defined
>>>>>> by
>>>>>> MAY include device location, device ID, manufacturer¹s serial
>>>>>>number,
>>>>>> and
>>>>>> device MAY select a database for service by means of a
>>>>>>pre-programmed
>>>>>> URI
>>>>>> address.
>>>>>> 
>>>>>> 
>>>>>> access the database. The master device MAY contact a database
>>>>>>directly
>>>>>> for
>>>>>> device the master device MAY send a periodic enabling signal to
>>>>>>allow
>>>>>> the
>>>>>> O.15: The enabling signal MUST be encoded so that the receiving
>>>>>>slave
>>>>>> can
>>>>>> channels as often as required by the regulation (eg, FCC requires
>>>>>>once
>>>>>> per
>>>>>> 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

---

From: Teco Boot <[email-masked]>
Date: Mon, 27 Feb 2012 22:23:08 +0100

Hi Scott,

> information, and MUST include all variables mandated by local regulator
Yes, this is fine.
And remove P.10?

Thanks, Teco

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 27 Feb 2012 16:38:52 -0500

<as individual>
I have a small issue here.

Device characteristics don't typically change, so having them in some form of registration transaction makes sense in an engineering sense.  However, some regulators don't seem to understand that, and there are circumstances where you have to send some of the device information with the spectrum query.  We should be flexible enough to handle that.

Brian

---

From: Don Joslyn <[email-masked]>
Date: Mon, 27 Feb 2012 16:40:19 -0500

Spectrum Bridge offers the following feedback to the latest PAWS Requirements posted by Scott Probasco on 2/21/12, UC&R I-D Requirements - Section 6 revisions of the I-D which describes the Data Model, Protocol and Operational Requirements:

We reviewed the latest PAWS requirements, comparing them to the published FCC requirements that established the requirements used by Spectrum Bridge to implement its certified TVWS database. We believe that the currently written PAWS Data Model, Protocol and Operational requirements align well with our current FCC certified implementation (see attached spreadsheet), and thus we support the PAWS requirements as written in the 2/21/22 from Scott Probasco, with a single exception, O.22. We do not agree with O.22 because we believe that a device should ALWAYS include its unique identity in messages sent to the database.

Regards,

Don Joslyn
Spectrum Bridge, Inc.

---

From: <[email-masked]>
Date: Mon, 27 Feb 2012 22:06:47 +0000

Hi Teco,

OK, change O.7 as indicated and remove P.10. I believe this works.

Kind Regards,
Scott

On 2/27/12 3:23 PM, "ext Teco Boot" <[email-masked]> wrote:

>Hi Scott,
>
>Op 27 feb. 2012, om 21:46 heeft <[email-masked]>
>>>> The current use of MUST in P.9 and MAY in P.10 has the effect that
>>>>WSDs
>>>> in
>>>>>>>> D.1: The Data Model MUST support specifying the location of the
>>>>>>>>WSD,
>>>>>>>> the
>>>>>>>> uncertainty in meters, the height & its uncertainty, and
>>>>>>>>confidence
>>>>>>>> in
>>>>>>>> device. This ID would contain the ID of the transmitter device
>>>>>>>>that
>>>>>>>> has
>>>>>>>> D.6: The Data Model MUST support specifying a manufacturer¹s
>>>>>>>>serial
>>>>>>>> number
>>>>>>>> for a master device.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> P.5: The protocol MUST provide the ability for the master device
>>>>>>>>to
>>>>>>>> verify
>>>>>>>> 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.15: The protocol MUST support a validation request from the
>>>>>>>>master
>>>>>>>> to
>>>>>>>> the slave. This signal MUST allow the slave device to validate
>>>>>>>>that
>>>>>>>> a
>>>>>>>> O.3: The master device MUST identify a database for use. The
>>>>>>>>master
>>>>>>>> device
>>>>>>>> O.4: The master device MUST implement at least one connection
>>>>>>>>method
>>>>>>>> to
>>>>>>>> governing operation at its current location, i.e. the master
>>>>>>>>device
>>>>>>>> MUST
>>>>>>>> based on its current location before starting radio transmission
>>>>>>>>in
>>>>>>>> white
>>>>>>>> O.9: The database MUST respond to an available channel list
>>>>>>>>request
>>>>>>>> from
>>>>>>>> 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
>>>>>>>> distance specified by local regulatory policy during its
>>>>>>>>operation,
>>>>>>>> MUST
>>>>>>>> O.21: A master device MUST be able to query the whitespace
>>>>>>>>database
>>>>>>>> for

---

From: <[email-masked]>
Date: Mon, 27 Feb 2012 22:08:38 +0000

Hi Brian,

I agree we should be flexible enough to send device information with the
spectrum query when requested by the local regulator. Does P.12 address
this accurately?

Kind Regards,
Scott

On 2/27/12 3:38 PM, "ext Rosen, Brian" <[email-masked]> wrote:

>Device characteristics don't typically change, so having them in some
>form of registration transaction makes sense in an engineering sense.
>However, some regulators don't seem to understand that, and there are
>circumstances where you have to send some of the device information with
>the spectrum query.  We should be flexible enough to handle that.
>
>Brian
>

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 27 Feb 2012 17:14:06 -0500

Guilty of not reading the doc carefully enough.  Why yes it does.

Brian

---

From: <[email-masked]>
Date: Tue, 28 Feb 2012 14:13:06 +0000

Hello Don,

Thank you for providing this analysis. It is very good to know that our
progress thus far is well aligned with a working and certified database.

I propose that we change O.22 as follows:

O.22: A Master device MUST include its identity in messages sent to the
database.

Kind Regards,
Scott

On 2/27/12 3:40 PM, "ext Don Joslyn" <[email-masked]> wrote:

>Spectrum Bridge offers the following feedback to the latest PAWS
>Requirements posted by Scott Probasco on 2/21/12, UC&R I-D Requirements -
>Section 6 revisions of the I-D which describes the Data Model, Protocol
>and Operational Requirements:
>
>We reviewed the latest PAWS requirements, comparing them to the published
>FCC requirements that established the requirements used by Spectrum
>Bridge to implement its certified TVWS database. We believe that the
>currently written PAWS Data Model, Protocol and Operational requirements
>align well with our current FCC certified implementation (see attached
>spreadsheet), and thus we support the PAWS requirements as written in the
>2/21/22 from Scott Probasco, with a single exception, O.22. We do not
>agree with O.22 because we believe that a device should ALWAYS include
>its unique identity in messages sent to the database.
>
>Regards,
>
>Don Joslyn
>Spectrum Bridge, Inc.

---

From: Don Joslyn <[email-masked]>
Date: Tue, 28 Feb 2012 10:12:18 -0500

Thank you, Scott.

Regards,
Don

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, February 28, 2012 9:13 AM
To: Don Joslyn; [email-masked]
Cc: Peter Stanforth
Subject: Re: UC&R I-D: Requirements

Hello Don,

Kind Regards,
Scott