Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03: protocol details

From: "Horn, Gavin" <[email-masked]>
Date: Thu, 8 Mar 2012 00:12:38 +0000

Hi all,

Some comments on the requirements with respect to the scope of the document

The following requirements seem unrelated to the master and database interface and can probably be deleted

-          P.13:  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.16:  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.17:  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.

-          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.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.

P.14 already covers the forwarding of information received in P.13 from the slave, so it is not clear why P.13 is needed.

The concept of an enabling signal in P.16, P.17, O.14, O.15 and O.16 is air interface specific between the master and slave. Similarly O.13 contains details of masters response to the slave. For O.19, the requirement is subject to local regulation but is also probably not needed for the PAWS work either since it is related to the master and slave only.

P.11 and P.19 are very similar and should probably be merged

Regards
Gavin

From: [email-masked] [mailto:[email-masked]] On Behalf Of Don Joslyn
Sent: Wednesday, March 07, 2012 1:41 PM
To: Zuniga, Juan Carlos; [email-masked]; [email-masked]
Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03: protocol details

Re:

-          P.14/P.15 state that the protocol must support a "validation request from the master to the database to validate a slave device". Is this a master relaying a request to the WSDB on behalf of a slave? It is not clear what validation means. It would be good to provide some more explanatory text.

In the context of FCC certified databases and devices, Fixed or Mode II TVBD (master devices) must verify that the FCC identifier (FCC ID) of the Mode I device (slave) is valid before sending a channel list to the slave.

In other words, before a master device sends a channel list to a slave device, the master device must send a verification request message to the database to validate the slave's reported FCC ID. The master may only send a channel list to the slave device after the database has validated the FCC ID by sending a success in the reply to a verification request message.

Don

From: [email-masked] [mailto:[email-masked]] On Behalf Of Zuniga, Juan Carlos
Sent: Tuesday, March 06, 2012 6:18 PM
To: [email-masked]; [email-masked]
Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03: protocol details

Hi all,

I have taken a look at the Ofcom requirements reference on the CEPT site and besides the points raised by Andy I believe the following protocol requirements should also be addressed in the PAWS requirements doc:

-          Ofcom 3.11 A master WSD must communicate its technology identifier to a WSDB - This is needed to identify the type of RAT being used, beyond the antenna, power and channel characteristics. Having said that, we had some issues in IEEE 802.21 where we were playing a horse race with the constantly evolving 802.11, 3GPP, etc PHY technologies, so perhaps another approach could be to specify directly the modulation, medium access method, etc. instead of the actual RAT ID. We don't need to define the actual solution now, as long as the requirement allows it in the future. Suggested text:

o   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. <Insert> The Data Model MUST support specifying information about the type of RAT of the transmitter device.</Insert>

-          Ofcom 3.15    A master WSD must communicate to a WSDB whether it, and its associated slave WSDs, are fixed devices or portable/mobile devices - Not sure if this is covered by "device class" in D.5. Since Device Class is not defined in the document, I would suggest either defining it as including fixed vs. mobile/portable characteristics, or adding a sentence at the end of D.5 such as "The Data Model MUST support specifying whether the transmitter device is fixed or mobile/portable."

-          Ofcom 3.16    A fixed master WSD may communicate to a WSDB whether it, and its associated fixed slave WSDs, are indoor devices or outdoor devices - Similar to the previous 3.15 requirement. I would suggest either adding a definition for Device Class including indoor or outdoor characteristics, or adding a sentence in D.5 like "The Data Model MAY support specifying whether the transmitter is an outdoor or indoor device."

Also, I believe we need to add some clarification on the following:

-          P.14/P.15 state that the protocol must support a "validation request from the master to the database to validate a slave device". Is this a master relaying a request to the WSDB on behalf of a slave? It is not clear what validation means. It would be good to provide some more explanatory text.

-          Now that the CEPT version of the Ofcom requirements is publicly available we should add a reference to the document in Section 3.3 "Background information on white space in the UK."

Regards,

Juan Carlos

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Monday, March 05, 2012 2:46 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03

The authors of the use cases and requirements draft have just posted a new version of the draft and indicated that there are no unresolved comments/issues they are aware of.

Therefore, I'd like to initiate a WG Last Call for comments on http://www.ietf.org/internet-drafts/draft-ietf-paws-problem-stmt-usecases-rqmts-03.txt

Please review the draft and send your comments to the list by March 20th, 2012.

If you review the draft and have no comments, send a note to the list that the draft is good as it is, we need these notes as much as we need the actual comments.

Thanks, Gabor

---

From: Gerald Chouinard <[email-masked]>
Date: Thu, 8 Mar 2012 09:40:59 -0500

All,

I support Horn's proposal. I don't think that the PAWS needs to get involved
into the air interface between the master device and its slaves.  This is to
be covered by the technology standards and many implementations may exist.
As long as the information that the master device needs to provide to the
database is present at the master and that the master has a way to make the
slave device follow the instructions sent back from the base station (and
'possibly' that the master device has the information regarding the spectrum
used by its associated slave devices, all this information can be exchanged
between the master device and the database using this PAWS protocol.  The
way this information is obtained by the master from its associated slave
devices is, in my view, outside the scope of PAWS.

One thing has to be clarified, however. There is not direct relationship
between what is a 'slave device' and a 'Mode I' device as defined in the FCC
R&O. A slave device is a device that has its RF parameters (e.g., frequency,
EIRP) controlled by a master device. This slave device could be portable,
fixed, etc. It is assumed that the master device is responsible for the
spectrum footprint used by the slave device and act on its behalf in
contacting the database.

Gerald

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Horn, Gavin
Sent: Wednesday, 07 March, 2012 19:13
To: Don Joslyn; Zuniga, Juan Carlos; [email-masked]; [email-masked]
Subject: Re: [paws] WGLC fordraft-ietf-paws-problem-stmt-usecases-rqmts-03:
protocol details

Hi all,

The following requirements seem unrelated to the master and database
interface and can probably be deleted

-          P.13:  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.16:  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.17:  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.

-                 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.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.

P.14 already covers the forwarding of information received in P.13 from the
slave, so it is not clear why P.13 is needed.

The concept of an enabling signal in P.16, P.17, O.14, O.15 and O.16 is air
interface specific between the master and slave. Similarly O.13 contains
details of masters response to the slave. For O.19, the requirement is
subject to local regulation but is also probably not needed for the PAWS
work either since it is related to the master and slave only.

Regards

Gavin

From: [email-masked] [mailto:[email-masked]] On Behalf Of Don
Joslyn
Sent: Wednesday, March 07, 2012 1:41 PM
To: Zuniga, Juan Carlos; [email-masked]; [email-masked]
Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03:
protocol details

Re: 

-          P.14/P.15 state that the protocol must support a "validation
request from the master to the database to validate a slave device". Is this
a master relaying a request to the WSDB on behalf of a slave? It is not
clear what validation means. It would be good to provide some more
explanatory text.

In the context of FCC certified databases and devices, Fixed or Mode II TVBD
(master devices) must verify that the FCC identifier (FCC ID) of the Mode I
device (slave) is valid before sending a channel list to the slave.

In other words, before a master device sends a channel list to a slave
device, the master device must send a verification request message to the
database to validate the slave's reported FCC ID. The master may only send a
channel list to the slave device after the database has validated the FCC ID
by sending a success in the reply to a verification request message.

Don

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Zuniga, Juan Carlos
Sent: Tuesday, March 06, 2012 6:18 PM
To: [email-masked]; [email-masked]
Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03:
protocol details

Hi all,

I have taken a look at the Ofcom requirements reference on the CEPT site and
besides the points raised by Andy I believe the following protocol
requirements should also be addressed in the PAWS requirements doc:

-          Ofcom 3.11 A master WSD must communicate its technology
identifier to a WSDB - This is needed to identify the type of RAT being
used, beyond the antenna, power and channel characteristics. Having said
that, we had some issues in IEEE 802.21 where we were playing a horse race
with the constantly evolving 802.11, 3GPP, etc PHY technologies, so perhaps
another approach could be to specify directly the modulation, medium access
method, etc. instead of the actual RAT ID. We don't need to define the
actual solution now, as long as the requirement allows it in the future.
Suggested text:

o        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. <Insert> The Data Model MUST support
specifying information about the type of RAT of the transmitter
device.</Insert>

-          Ofcom 3.15    A master WSD must communicate to a WSDB whether it,
and its associated slave WSDs, are fixed devices or portable/mobile devices
- Not sure if this is covered by "device class" in D.5. Since Device Class
is not defined in the document, I would suggest either defining it as
including fixed vs. mobile/portable characteristics, or adding a sentence at
the end of D.5 such as "The Data Model MUST support specifying whether the
transmitter device is fixed or mobile/portable."

-          Ofcom 3.16    A fixed master WSD may communicate to a WSDB
whether it, and its associated fixed slave WSDs, are indoor devices or
outdoor devices - Similar to the previous 3.15 requirement. I would suggest
either adding a definition for Device Class including indoor or outdoor
characteristics, or adding a sentence in D.5 like "The Data Model MAY
support specifying whether the transmitter is an outdoor or indoor device."

-          P.14/P.15 state that the protocol must support a "validation
request from the master to the database to validate a slave device". Is this
a master relaying a request to the WSDB on behalf of a slave? It is not
clear what validation means. It would be good to provide some more
explanatory text.

-          Now that the CEPT version of the Ofcom requirements is publicly
available we should add a reference to the document in Section 3.3
"Background information on white space in the UK."

Regards,

Juan Carlos 

From: [email-masked] [mailto:[email-masked]]
<mailto:%5bmailto:[email-masked]%5d>  On Behalf Of
[email-masked]
Sent: Monday, March 05, 2012 2:46 PM
To: [email-masked]
Subject: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03

The authors of the use cases and requirements draft have just posted a new
version of the draft and indicated that there are no unresolved
comments/issues they are aware of.

Therefore, I'd like to initiate a WG Last Call for comments on
http://www.ietf.org/internet-drafts/draft-ietf-paws-problem-stmt-usecases-rq
mts-03.txt 

Please review the draft and send your comments to the list by March 20th,
2012.

If you review the draft and have no comments, send a note to the list that
the draft is good as it is, we need these notes as much as we need the
actual comments.

Thanks, Gabor