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

From: <[email-masked]>
Date: Tue, 6 Mar 2012 15:42:25 +0000

All

Comparing the draft with the Ofcom requirements at http://www.cept.org/Documents/se-43/4161/SE43(12)Info03_Draft-UK-regulatory-requirements-for-white-space-devices-in-the-UHF-TV-band, I believe the WG draft is deficient in the area of reporting frequencies and powers actually used by masters and slaves (Ofcom requirements 3.18 and 3.19.8). Ofcom intends to collect this data to assesses the impact of aggregate interference into other services. It would also provide usage information (frequency in use) that would inform the operation of a kill switch capability. I suggest this deficiency can be remedied with the following changes:

New P requirements (probably best placed following P.12):

P.12bis: The protocol MUST support a channel usage message from the slave device to the master device.  The channel usage message MUST include parameters as required by local regulatory requirement.  These parameters MAY include device ID, manufacturer's serial number, channel usage and power level information.

P.12ter: The protocol MUST support a channel usage message from the master device to the database.  The channel usage message MUST include parameters as required by local regulatory requirement for the master and its associated slaves.  These parameters MAY include device ID, manufacturer's serial number, channel usage and power level information.

P.12qua: The protocol MUST support a channel usage message acknowledgement.

New O requirements (probably best placed following O13):

O.13bis:  According to local regulatory policy, after connecting to a master device's radio network a slave device MAY inform the master device of the actual channel usage. The slave MUST include parameters required by local regulatory policy, e.g. device ID, manufacturer's serial number, channel usage and power level information.

O.13ter:  According to local regulatory policy, a master device MAY inform the database of the actual channel usage of the master and its slaves. The master MUST include parameters required by local regulatory policy, e.g. device ID, manufacturer's serial number, channel usage and power level information of the master and its slaves.

New steps could be introduced into one or more use cases to cover these Ofcom requirements, e.g. new steps 6bis and 9bis in the hotspot use case at 4.2.1:

6bis. Prior to initiating transmission, if required by local regulation, the master/AP informs the database of the channel and power level it has chosen. This is repeated for each slave that associated with the master.

9bis. Prior to initiating transmission, if required by local regulation, the slave informs the master/AP of the channel and power level it has chosen, and the master/AP relays this information to the database.

- end of new text -

For information, for those not accessing the url in the first paragraph of this email, the full Ofcom requirements leading to this new PAWS text are as follows:

3.18 After receiving instructions from a WSDB in relation to the maximum permitted EIRPs over the DTT channels, and prior to initiating transmissions within the UHF TV band, a master WSD must communicate to the WSDB the following information:
3.18.1 The lower and upper frequency boundaries13 of the in-block emissions of the master WSD, and those of the in-block emissions of its associated slaves. A lower frequency will be specified as (470 + 8k + 0.2n) MHz, with the corresponding upper frequency specified as (470 + 8k + 0.2m) MHz, where 0 ≤ k ≤ 39, 0 ≤ n ≤ 39, 1 ≤ m ≤ 40, and n < m.
3.18.2 The maximum in-block EIRP spectral densities (in dBm/(0.2 MHz)) that the master WSD, and its associated slaves, actually radiate between each reported lower frequency boundary and its corresponding upper frequency boundary.

Footnote 13 states:
The use of upper and lower frequency boundaries (defined over a 200 kHz raster) allows a WSDB to collect more granular information with regards to the usage of the frequency resource by narrowband WSD technologies. The upper and lower frequencies of a boundary pair do not straddle a DTT channel boundary. Note that a WSD may transmit over multiple, non-contiguous, whole DTT channels or fractions of DTT channels.

3.19 A master WSD must be able to receive the following information14 from a WSDB:
<snip>
3.19.8     [An acknowledgement from the WSDB, in the context of 3.18, that the reported information on the DTT channels and EIRP spectral densities actually used by the master and slave WSDs were received successfully by the WSDB18].

Footnote 14 states:
14 While the communication of some of this information from a WSDB to a master WSD is optional, master WSDs must be able to receive and interpret these.

Footnote 18 states:
18 This forms part of a handshake protocol and may be an area where industry could harmonise without the need for an explicit requirement in the regulations.

Regards

Andy

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 05 March 2012 19:46
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-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: "Joel M. Halpern" <[email-masked]>
Date: Tue, 06 Mar 2012 10:53:08 -0500

As I understand, the information you are asking for is explicitly out of 
scope for the working group.
Yours,
Joel

On 3/6/2012 10:42 AM, [email-masked] wrote:
> All
>
> Comparing the draft with the Ofcom requirements at
> http://www.cept.org/Documents/se-43/4161/SE43(12)Info03_Draft-UK-regulatory-requirements-for-white-space-devices-in-the-UHF-TV-band,
> I believe the WG draft is deficient in the area of reporting frequencies
> and powers actually used by masters and slaves (Ofcom requirements 3.18
> and 3.19.8). Ofcom intends to collect this data to assesses the impact
> of aggregate interference into other services. It would also provide
> usage information (frequency in use) that would inform the operation of
> a kill switch capability. I suggest this deficiency can be remedied with
> the following changes:
>
> P.12bis: The protocol MUST support a channel usage message from the
> slave device to the master device.  The channel usage message MUST
> include parameters as required by local regulatory requirement.  These
> parameters MAY include device ID, manufacturer's serial number, channel
> usage and power level information.
>
> P.12ter: The protocol MUST support a channel usage message from the
> master device to the database.  The channel usage message MUST include
> parameters as required by local regulatory requirement for the master
> and its associated slaves.  These parameters MAY include device ID,
> manufacturer's serial number, channel usage and power level information.
>
> O.13bis:  According to local regulatory policy, after connecting to a
> master device's radio network a slave device MAY inform the master
> device of the actual channel usage. The slave MUST include parameters
> required by local regulatory policy, e.g. device ID, manufacturer's
> serial number, channel usage and power level information.
>
> O.13ter:  According to local regulatory policy, a master device MAY
> inform the database of the actual channel usage of the master and its
> slaves. The master MUST include parameters required by local regulatory
> policy, e.g. device ID, manufacturer's serial number, channel usage and
> power level information of the master and its slaves.
>
> New steps could be introduced into one or more use cases to cover these
> Ofcom requirements, e.g. new steps 6bis and 9bis in the hotspot use case
> at 4.2.1:
>
> 6bis. Prior to initiating transmission, if required by local regulation,
> the master/AP informs the database of the channel and power level it has
> chosen. This is repeated for each slave that associated with the master.
>
> 9bis. Prior to initiating transmission, if required by local regulation,
> the slave informs the master/AP of the channel and power level it has
> chosen, and the master/AP relays this information to the database.
>
> - end of new text -
>
> For information, for those not accessing the url in the first paragraph
> of this email, the full Ofcom requirements leading to this new PAWS text
> are as follows:
>
> 3.18 After receiving instructions from a WSDB in relation to the maximum
> permitted EIRPs over the DTT channels, and prior to initiating
> transmissions within the UHF TV band, a master WSD must communicate to
> the WSDB the following information:
>
> 3.18.1 The lower and upper frequency boundaries^13 of the in-block
> emissions of the master WSD, and those of the in-block emissions of its
> associated slaves. A lower frequency will be specified as (470 + 8k +
> 0.2n) MHz, with the corresponding upper frequency specified as (470 + 8k
> + 0.2m) MHz, where 0 ≤ k ≤ 39, 0 ≤ n ≤ 39, 1 ≤ m ≤ 40, and n < m.
>
> 3.18.2 The maximum in-block EIRP spectral densities (in dBm/(0.2 MHz))
> that the master WSD, and its associated slaves, actually radiate between
> each reported lower frequency boundary and its corresponding upper
> frequency boundary.
>
> Footnote 13 states:
>
> The use of upper and lower frequency boundaries (defined over a 200 kHz
> raster) allows a WSDB to collect more granular information with regards
> to the usage of the frequency resource by narrowband WSD technologies.
> The upper and lower frequencies of a boundary pair do not straddle a DTT
> channel boundary. Note that a WSD may transmit over multiple,
> non-contiguous, whole DTT channels or fractions of DTT channels.
>
> 3.19 A master WSD must be able to receive the following information^14
> from a WSDB:
>
> <snip>
>
> 3.19.8     [An acknowledgement from the WSDB, in the context of 3.18,
> that the reported information on the DTT channels and EIRP spectral
> densities actually used by the master and slave WSDs were received
> successfully by the WSDB^18 ].
>
> Footnote 14 states:
>
> 14 While the communication of some of this information from a WSDB to a
> master WSD is optional, master WSDs must be able to receive and
> interpret these.
>
> Footnote 18 states:
>
> 18 This forms part of a handshake protocol and may be an area where
> industry could harmonise without the need for an explicit requirement in
> the regulations.
>
> Regards
>
> Andy
>
> *From:[email-masked] [mailto:[email-masked]] *On Behalf
> Of [email-masked]
> *Sent:* 05 March 2012 19:46
> *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-rqmts-03.txt
>
>
> 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
>
>
>
> _______________________________________________
> paws mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/paws

---

From: <[email-masked]>
Date: Tue, 6 Mar 2012 16:03:00 +0000

Hi Joel

There's no language I can find in the charter that explicitly puts this out of scope. On the other hand, the charter says that the group will "consider input  from regulatory entities", and this is one of the requirements from Ofcom that they have just published. The protocol will be worthless for the UK if it omits some requirements.

Regards

Andy

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: 06 March 2012 15:53
To: Sago,AJ,Andy,COD R
Cc: [email-masked]; [email-masked]
Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting

As I understand, the information you are asking for is explicitly out of scope for the working group.
Yours,
Joel

On 3/6/2012 10:42 AM, [email-masked] wrote:
> http://www.cept.org/Documents/se-43/4161/SE43(12)Info03_Draft-UK-regul
> atory-requirements-for-white-space-devices-in-the-UHF-TV-band,
> I believe the WG draft is deficient in the area of reporting 
> frequencies and powers actually used by masters and slaves (Ofcom 
> requirements 3.18 and 3.19.8). Ofcom intends to collect this data to 
> assesses the impact of aggregate interference into other services. It 
> would also provide usage information (frequency in use) that would 
> inform the operation of a kill switch capability. I suggest this 
> deficiency can be remedied with the following changes:
>
> parameters MAY include device ID, manufacturer's serial number, 
> channel usage and power level information.
>
> slaves. The master MUST include parameters required by local 
> regulatory policy, e.g. device ID, manufacturer's serial number, 
> channel usage and power level information of the master and its slaves.
>
> New steps could be introduced into one or more use cases to cover 
> these Ofcom requirements, e.g. new steps 6bis and 9bis in the hotspot 
> use case at 4.2.1:
>
> 6bis. Prior to initiating transmission, if required by local 
> regulation, the master/AP informs the database of the channel and 
> power level it has chosen. This is repeated for each slave that associated with the master.
>
> 9bis. Prior to initiating transmission, if required by local 
> regulation, the slave informs the master/AP of the channel and power 
> level it has chosen, and the master/AP relays this information to the database.
>
> - end of new text -
>
> For information, for those not accessing the url in the first 
> paragraph of this email, the full Ofcom requirements leading to this 
> new PAWS text are as follows:
>
> 3.18 After receiving instructions from a WSDB in relation to the 
> maximum permitted EIRPs over the DTT channels, and prior to initiating 
> emissions of the master WSD, and those of the in-block emissions of 
> its associated slaves. A lower frequency will be specified as (470 + 
> 8k +
> that the master WSD, and its associated slaves, actually radiate 
> between each reported lower frequency boundary and its corresponding 
> upper frequency boundary.
>
> Footnote 13 states:
>
> raster) allows a WSDB to collect more granular information with 
> regards to the usage of the frequency resource by narrowband WSD technologies.
> The upper and lower frequencies of a boundary pair do not straddle a 
> DTT channel boundary. Note that a WSD may transmit over multiple, 
> 14 While the communication of some of this information from a WSDB to 
> a master WSD is optional, master WSDs must be able to receive and 
> interpret these.
>
> Footnote 18 states:
>
> industry could harmonise without the need for an explicit requirement 
> in the regulations.
>
> Regards
>
> Andy
>
> *Subject:* [paws] WGLC for 
> draft-ietf-paws-problem-stmt-usecases-rqmts-03
>
> that the draft is good as it is, we need these notes as much as we 
> need the actual comments.
>
> Thanks, Gabor
>
>
>

---

From: <[email-masked]>
Date: Tue, 6 Mar 2012 16:22:13 +0000

The ofcom requirements are very much relevant to the scope of the PAWS WG.
The only other regulatory requirements that we have today is the FCC.
Ofcom requirements are a good addition to the set.

-Raj

On 3/6/12 10:03 AM, "ext [email-masked]" <[email-masked]> wrote:

>Hi Joel
>
>There's no language I can find in the charter that explicitly puts this
>out of scope. On the other hand, the charter says that the group will
>"consider input  from regulatory entities", and this is one of the
>requirements from Ofcom that they have just published. The protocol will
>be worthless for the UK if it omits some requirements.
>
>Regards
>
>Andy
>
>Subject: Re: [paws] WGLC for
>draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting
>
>> + 0.2m) MHz, where 0 ¾ k ¾ 39, 0 ¾ n ¾ 39, 1 ¾ m ¾ 40, and n < m.
>>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 06 Mar 2012 11:30:15 -0500

I would draw a distinction.  Ofcom regulations about whitespace requests 
are very much relevant.
Ofcom regulations about notification of dynamic behavior (which spectrum 
is being used) are not in scope as I understand the earlier discussions, 
particularly the chartering discussions.

Yours,
Joel

On 3/6/2012 11:22 AM, [email-masked] wrote:
> On 3/6/12 10:03 AM, "ext [email-masked]"<[email-masked]>  wrote:
>
>> Hi Joel
>>
>>> + 0.2m) MHz, where 0 ¾ k ¾ 39, 0 ¾ n ¾ 39, 1 ¾ m ¾ 40, and n<  m.
>>>

---

From: <[email-masked]>
Date: Tue, 6 Mar 2012 16:38:46 +0000

I think it is worthwhile having a discussion about the requirement (which
spectrum is being used) from Ofcom rather than ruling it out of scope. If
the outcome of the PAWS WG is to be relevant across different
regions/domains, then we should consider it even if it means revising the
charter and expanding the scope.

-Raj

On 3/6/12 10:30 AM, "ext Joel M. Halpern" <[email-masked]> wrote:

>>>> + 0.2m) MHz, where 0 3Ž4 k 3Ž4 39, 0 3Ž4 n 3Ž4 39, 1 3Ž4 m 3Ž4 40, and n<  m.
>>>>

---

From: Gerald Chouinard <[email-masked]>
Date: Tue, 6 Mar 2012 11:44:07 -0500

Andy,

Looking at your suggestions below, it seems that there is a need to define
more precisely what a "slave" device is relative to its "master".

In my view, a slave can only use the same transmission channel as that used
by the master to which it is associated (otherwise, master and slaves would
not be able to talk to each other). As a consequence, the slave does not
have to indicate to the master the channel on which it is operating since
the master knows it and can provided it to the database e.

Similarly, modern bidirectional communication systems between a master and a
slave device assumes that there will be a transmit power control (TPC) loop
between the two devices to minimize the required transmit power in various
propagation environments. The driving device in this closed-loop process
will be the master and as a result, the EIRP transmitted by the slave device
will be known to the master as long as there is a known factor linking the
power specification sent by the master to the slave and the actual EIRP
transmitted by the slave.  Such factor which is a constant for each device
can be provided from the slave to the master once at association.  As a
result, the slave does not need to inform the master of its current (and
provably continuously varying) EIRP since the master will have this
information from its TPC process and can provide it to the database on
behalf of the slave device.

Gerald

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Tuesday, 06 March, 2012 10:42
To: [email-masked]; [email-masked]
Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03:
channel reporting

All

Comparing the draft with the Ofcom requirements at
http://www.cept.org/Documents/se-43/4161/SE43(12)Info03_Draft-UK-regulatory-
requirements-for-white-space-devices-in-the-UHF-TV-band, I believe the WG
draft is deficient in the area of reporting frequencies and powers actually
used by masters and slaves (Ofcom requirements 3.18 and 3.19.8). Ofcom
intends to collect this data to assesses the impact of aggregate
interference into other services. It would also provide usage information
(frequency in use) that would inform the operation of a kill switch
capability. I suggest this deficiency can be remedied with the following
changes:

P.12bis: The protocol MUST support a channel usage message from the slave
device to the master device.  The channel usage message MUST include
parameters as required by local regulatory requirement.  These parameters
MAY include device ID, manufacturer's serial number, channel usage and power
level information.

P.12ter: The protocol MUST support a channel usage message from the master
device to the database.  The channel usage message MUST include parameters
as required by local regulatory requirement for the master and its
associated slaves.  These parameters MAY include device ID, manufacturer's
serial number, channel usage and power level information.

O.13bis:  According to local regulatory policy, after connecting to a master
device's radio network a slave device MAY inform the master device of the
actual channel usage. The slave MUST include parameters required by local
regulatory policy, e.g. device ID, manufacturer's serial number, channel
usage and power level information.

O.13ter:  According to local regulatory policy, a master device MAY inform
the database of the actual channel usage of the master and its slaves. The
master MUST include parameters required by local regulatory policy, e.g.
device ID, manufacturer's serial number, channel usage and power level
information of the master and its slaves.

New steps could be introduced into one or more use cases to cover these
Ofcom requirements, e.g. new steps 6bis and 9bis in the hotspot use case at
4.2.1:

6bis. Prior to initiating transmission, if required by local regulation, the
master/AP informs the database of the channel and power level it has chosen.
This is repeated for each slave that associated with the master.

9bis. Prior to initiating transmission, if required by local regulation, the
slave informs the master/AP of the channel and power level it has chosen,
and the master/AP relays this information to the database. 

- end of new text -

For information, for those not accessing the url in the first paragraph of
this email, the full Ofcom requirements leading to this new PAWS text are as
follows:

3.18 After receiving instructions from a WSDB in relation to the maximum
permitted EIRPs over the DTT channels, and prior to initiating transmissions
within the UHF TV band, a master WSD must communicate to the WSDB the
following information:

3.18.1 The lower and upper frequency boundaries13 of the in-block emissions
of the master WSD, and those of the in-block emissions of its associated
slaves. A lower frequency will be specified as (470 + 8k + 0.2n) MHz, with
the corresponding upper frequency specified as (470 + 8k + 0.2m) MHz, where
0 ? k ? 39, 0 ? n ? 39, 1 ? m ? 40, and n < m.

3.18.2 The maximum in-block EIRP spectral densities (in dBm/(0.2 MHz)) that
the master WSD, and its associated slaves, actually radiate between each
reported lower frequency boundary and its corresponding upper frequency
boundary.

Footnote 13 states:

The use of upper and lower frequency boundaries (defined over a 200 kHz
raster) allows a WSDB to collect more granular information with regards to
the usage of the frequency resource by narrowband WSD technologies. The
upper and lower frequencies of a boundary pair do not straddle a DTT channel
boundary. Note that a WSD may transmit over multiple, non-contiguous, whole
DTT channels or fractions of DTT channels.

3.19 A master WSD must be able to receive the following information14 from a
WSDB:

<snip>

3.19.8     [An acknowledgement from the WSDB, in the context of 3.18, that
the reported information on the DTT channels and EIRP spectral densities
actually used by the master and slave WSDs were received successfully by the
WSDB18].

Footnote 14 states:

14 While the communication of some of this information from a WSDB to a
master WSD is optional, master WSDs must be able to receive and interpret
these.

Footnote 18 states:

18 This forms part of a handshake protocol and may be an area where industry
could harmonise without the need for an explicit requirement in the
regulations.

Regards

Andy

From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: 05 March 2012 19:46
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

---

From: <[email-masked]>
Date: Tue, 6 Mar 2012 16:48:07 +0000

Hi,

There is a similarity here with device ID. In context of PAWS we are not
concerned with why a device ID is required by a regulator, we accept it is
a requirement from a regulator and include it to the protocol. Ofcom
identifies in 3.18 & 3.19 that channel usage information is required and
thus we need to include this information. Since the master must provide
this information prior to transmitting, PAWS will not function in the UK
without this information and thus I believe channel usage information is
integral to the channel request & response messaging.

Kind Regards,
Scott

---

From: <[email-masked]>
Date: Tue, 6 Mar 2012 16:59:34 +0000

Hi Gerald,

At least according to the FCC, a slave (Mode I) device may utilize channels that the master (fixed device) cannot use, see §15.707 and 15.712. Thus there are potential situations where the master cannot be assumed to know what channel the slave is using. Although this is a bit esoteric as the FCC is silent about what the slave might do on those channels, it is nonetheless included in the FCC regulations.

So I suggest we have no reason to overrule Ofcom requirements for channel usage information. Also Andy's choice of words does ensure that this information is not required to be used in every operational scenario.

Kind Regards,
Scott

From: ext Chouinard <[email-masked]<mailto:[email-masked]>>
Date: Tue, 6 Mar 2012 11:44:07 -0500
To: ext com <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting

Andy,

Looking at your suggestions below, it seems that there is a need to define more precisely what a “slave” device is relative to its “master”.

In my view, a slave can only use the same transmission channel as that used by the master to which it is associated (otherwise, master and slaves would not be able to talk to each other). As a consequence, the slave does not have to indicate to the master the channel on which it is operating since the master knows it and can provided it to the database e.

Similarly, modern bidirectional communication systems between a master and a slave device assumes that there will be a transmit power control (TPC) loop between the two devices to minimize the required transmit power in various propagation environments. The driving device in this closed-loop process will be the master and as a result, the EIRP transmitted by the slave device will be known to the master as long as there is a known factor linking the power specification sent by the master to the slave and the actual EIRP transmitted by the slave.  Such factor which is a constant for each device can be provided from the slave to the master once at association.  As a result, the slave does not need to inform the master of its current (and provably continuously varying) EIRP since the master will havethis information from its TPC process and can provide it to the database onbehalf of the slave device.

Gerald

________________________________
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Tuesday, 06 March, 2012 10:42
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting

All

O.13bis:  According to local regulatory policy, after connecting to a master device'sradio network a slave device MAY inform the master device of the actual channel usage. The slave MUST include parameters required by local regulatory policy, e.g. device ID, manufacturer's serial number, channel usage and power levelinformation.

9bis. Prior to initiating transmission, if required by local regulation, the slave informs the master/AP of the channel and power level it has chosen, and themaster/AP relays this information to the database.

- end of new text -

3.18 After receiving instructions from a WSDB in relation to the maximum permitted EIRPs over the DTT channels, and prior to initiating transmissions within the UHF TV band, a master WSD mustcommunicate to the WSDB the following information:
3.18.1 The lower and upper frequency boundaries13 of the in-block emissions of the master WSD, and those of the in-block emissions of its associated slaves. A lower frequency will be specified as (470 + 8k + 0.2n) MHz, with the corresponding upper frequency specified as (470 + 8k + 0.2m) MHz, where 0 ≤ k ≤ 39, 0 ≤ n ≤ 39, 1 ≤ m ≤ 40, and n < m.
3.18.2 The maximum in-block EIRP spectral densities (in dBm/(0.2 MHz)) that the masterWSD, and its associated slaves, actually radiate between each reported lower frequency boundary and its corresponding upper frequency boundary.

Footnote 13 states:
The use of upper and lower frequency boundaries (defined over a 200 kHz raster) allows a WSDB to collect more granular information with regards to the usage of the frequency resource bynarrowband WSD technologies. The upper and lower frequencies of a boundary pair do not straddle a DTT channel boundary. Note that a WSD may transmit over multiple, non-contiguous, whole DTT channels or fractions of DTT channels.

Footnote 14 states:

Footnote 18 states:

Regards

Andy

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

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

Thanks, Gabor

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 06 Mar 2012 12:04:40 -0500

Ahh.  I think I see where the request and my understanding divurge.
If the idea here is that the master must provide, in the request, an 
indication of what channels it expects to use, I can at least understand 
that.  I will return to technical concerns in a moment.

However, when you say "provide channel usage information, in order to 
evaluate interference", what that says to me is providing, during 
operation, information as to what channels are being used, and at what 
power levels.  That is what would be needed to analyze actual 
interference effects.
And that is out of scope as I understand our scope.

I do see a technical difficulty with having the master provide, as part 
of either registering or requesting spectrum information, what channels 
it intends to use.  It doesn;t know what channels it intends to use.  It 
intends to use some number of available channels.  It will figure out 
which ones when it is told what is available.  How can it send that 
information in the request?

Yours,
Joel

On 3/6/2012 11:48 AM, [email-masked] wrote:
> identifies in 3.18&  3.19 that channel usage information is required and
> integral to the channel request&  response messaging.
>
> Kind Regards,
> Scott
>
>
> On 3/6/12 10:30 AM, "ext Joel M. Halpern"<[email-masked]>  wrote:
>

---

From: <[email-masked]>
Date: Tue, 6 Mar 2012 17:10:02 +0000

Thanks Scott and Gerald

I agree with Gerald that I can think of technologies where the master will have an excellent view of the slave frequencies and power levels, and can indicate frequencies and (perhaps max) power levels back to the database, without the need for the slaves to send a message from slave to master. In those networks, the proposed P12.bis would not be required.  But I wouldn’t like to anticipate what technologies will be used in TVWS, so I included this message. It will have very similar structure to the master-to-database message so will cause little overhead in protocol development.

Regards

Andy

From: [email-masked] [mailto:[email-masked]]
Sent: 06 March 2012 17:00
To: [email-masked]; Sago,AJ,Andy,COD R
Cc: [email-masked]
Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting

Hi Gerald,

Kind Regards,
Scott

Andy,

Gerald

All

- end of new text -

Footnote 13 states:

Footnote 14 states:

Footnote 18 states:

Regards

Andy

Thanks, Gabor

---

From: Gerald Chouinard <[email-masked]>
Date: Tue, 6 Mar 2012 12:13:05 -0500

Scott,

I am fine with your approach as long as the text says something as follows:
“the operating channel of the slave needs to be provided to the database”
rather than: “the slave needs to provide the database with its operating
channel”.  This way, this information can be provided by either the slave
or the master, not making it mandatory that the “slave” has to do it if
the master knows the information.

The text proposed by Andy: “The protocol MUST support a channel usage
message from the slave device to the master device.” Implies that the
protocol to be developed needs to apply on the connection between the slave
and the master. Such connection should be implementation dependant.  What is
required is that the information be available to the master for it to
transmit it to the database, never mind the format that is used between the
slave and the master to carry this information.

Gerald

  _____  

From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, 06 March, 2012 12:00
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03:
channel reporting

Hi Gerald,

At least according to the FCC, a slave (Mode I) device may utilize channels
that the master (fixed device) cannot use, see §15.707 and 15.712. Thus
there are potential situations where the master cannot be assumed to know
what channel the slave is using. Although this is a bit esoteric as the FCC
is silent about what the slave might do on those channels, it is nonetheless
included in the FCC regulations.

So I suggest we have no reason to overrule Ofcom requirements for channel
usage information. Also Andy's choice of words does ensure that this
information is not required to be used in every operational scenario.

Kind Regards,

Scott

From: ext Chouinard <[email-masked]>
Date: Tue, 6 Mar 2012 11:44:07 -0500
To: ext com <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03:
channel reporting

Andy,

Looking at your suggestions below, it seems that there is a need to define
more precisely what a “slave” device is relative to its “master”.

provably continuously varying) EIRP since the master will havethis
information from its TPC process and can provide it to the database onbehalf
of the slave device.

Gerald

  _____  

All

O.13bis:  According to local regulatory policy, after connecting to a master
device'sradio network a slave device MAY inform the master device of the
actual channel usage. The slave MUST include parameters required by local
regulatory policy, e.g. device ID, manufacturer's serial number, channel
usage and power levelinformation.

9bis. Prior to initiating transmission, if required by local regulation, the
slave informs the master/AP of the channel and power level it has chosen,
and themaster/AP relays this information to the database. 

- end of new text -

3.18 After receiving instructions from a WSDB in relation to the maximum
permitted EIRPs over the DTT channels, and prior to initiating transmissions
within the UHF TV band, a master WSD mustcommunicate to the WSDB the
following information:

0 ≤ k ≤ 39, 0 ≤ n ≤ 39, 1 ≤ m ≤ 40, and n < m.

3.18.2 The maximum in-block EIRP spectral densities (in dBm/(0.2 MHz)) that
the masterWSD, and its associated slaves, actually radiate between each
reported lower frequency boundary and its corresponding upper frequency
boundary.

Footnote 13 states:

The use of upper and lower frequency boundaries (defined over a 200 kHz
raster) allows a WSDB to collect more granular information with regards to
the usage of the frequency resource bynarrowband WSD technologies. The upper
and lower frequencies of a boundary pair do not straddle a DTT channel
boundary. Note that a WSD may transmit over multiple, non-contiguous, whole
DTT channels or fractions of DTT channels.

<snip>

Footnote 14 states:

Footnote 18 states:

Regards

Andy

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

Thanks, Gabor

_______________________________________________ paws mailing list paws@ietf.
org https://www.ietf.org/mailman/listinfo/paws

---

From: <[email-masked]>
Date: Tue, 6 Mar 2012 17:28:59 +0000

Joel

Indeed, the regulator has not described the process or provided a flow diagram, so there may be some wrinkles, but we need to provide for their intent. To answer your question, the channels that the master will use are sent in a separate message (described in P.12 ter), that occurs after the master receives the response to its channel request, but before the master can transmit. At this point, it knows what channels are available, and which one it will use. As far as the slaves are concerned, as they associate, the master will need to gather their details and send further channel usage messages to the database on their behalf. 

Regards

Andy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: 06 March 2012 17:05
To: [email-masked]
Cc: [email-masked]; Cheeseman,CJ,Chris,COD R; Dixon,JS,Johnny,COD R
Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting

Ahh.  I think I see where the request and my understanding divurge.
If the idea here is that the master must provide, in the request, an indication of what channels it expects to use, I can at least understand that.  I will return to technical concerns in a moment.

However, when you say "provide channel usage information, in order to evaluate interference", what that says to me is providing, during operation, information as to what channels are being used, and at what power levels.  That is what would be needed to analyze actual interference effects.
And that is out of scope as I understand our scope.

I do see a technical difficulty with having the master provide, as part of either registering or requesting spectrum information, what channels it intends to use.  It doesn;t know what channels it intends to use.  It intends to use some number of available channels.  It will figure out which ones when it is told what is available.  How can it send that information in the request?

Yours,
Joel

On 3/6/2012 11:48 AM, [email-masked] wrote:
> Hi,
>
> There is a similarity here with device ID. In context of PAWS we are 
> not concerned with why a device ID is required by a regulator, we 
> accept it is a requirement from a regulator and include it to the 
> protocol. Ofcom identifies in 3.18&  3.19 that channel usage 
> information is required and thus we need to include this information. 
> Since the master must provide this information prior to transmitting, 
> PAWS will not function in the UK without this information and thus I 
> believe channel usage information is integral to the channel request&  response messaging.
>
> Kind Regards,
> Scott
>
>
>> I would draw a distinction.  Ofcom regulations about whitespace 
>> requests are very much relevant.
>> Ofcom regulations about notification of dynamic behavior (which 
>> spectrum is being used) are not in scope as I understand the earlier 
>> discussions, particularly the chartering discussions.
>>
>> Yours,
>> Joel
>>
>>>> There's no language I can find in the charter that explicitly puts 
>>>> this out of scope. On the other hand, the charter says that the 
>>>> group will "consider input  from regulatory entities", and this is 
>>>> one of the requirements from Ofcom that they have just published. 
>>>> The protocol will be worthless for the UK if it omits some 
>>>> requirements.
>>>>
>>>> Regards
>>>>
>>>> Andy
>>>>
>>>>> requirements 3.18 and 3.19.8). Ofcom intends to collect this data 
>>>>> to assesses the impact of aggregate interference into other 
>>>>> services. It would also provide usage information (frequency in 
>>>>> use) that would inform the operation of a kill switch capability. 
>>>>> I suggest this deficiency can be remedied with the following changes:
>>>>>
>>>>> P.12bis: The protocol MUST support a channel usage message from 
>>>>> the slave device to the master device.  The channel usage message 
>>>>> MUST include parameters as required by local regulatory 
>>>>> requirement.  These parameters MAY include device ID, 
>>>>> P.12ter: The protocol MUST support a channel usage message from 
>>>>> the master device to the database.  The channel usage message MUST 
>>>>> include parameters as required by local regulatory requirement for 
>>>>> the master and its associated slaves.  These parameters MAY 
>>>>> include device ID, manufacturer's serial number, channel usage and 
>>>>> power level information.
>>>>>
>>>>> O.13bis:  According to local regulatory policy, after connecting 
>>>>> to a master device's radio network a slave device MAY inform the 
>>>>> master device of the actual channel usage. The slave MUST include 
>>>>> parameters required by local regulatory policy, e.g. device ID, 
>>>>> O.13ter:  According to local regulatory policy, a master device 
>>>>> MAY inform the database of the actual channel usage of the master 
>>>>> and its slaves. The master MUST include parameters required by 
>>>>> local regulatory policy, e.g. device ID, manufacturer's serial 
>>>>> number, channel usage and power level information of the master 
>>>>> and its slaves.
>>>>>
>>>>> these Ofcom requirements, e.g. new steps 6bis and 9bis in the 
>>>>> hotspot use case at 4.2.1:
>>>>>
>>>>> regulation, the slave informs the master/AP of the channel and 
>>>>> power level it has chosen, and the master/AP relays this 
>>>>> information to the database.
>>>>>
>>>>> - end of new text -
>>>>>
>>>>> paragraph of this email, the full Ofcom requirements leading to 
>>>>> this new PAWS text are as follows:
>>>>>
>>>>> maximum permitted EIRPs over the DTT channels, and prior to 
>>>>> initiating transmissions within the UHF TV band, a master WSD must 
>>>>> communicate to the WSDB the following information:
>>>>>
>>>>> emissions of the master WSD, and those of the in-block emissions 
>>>>> of its associated slaves. A lower frequency will be specified as 
>>>>> (470 + 8k +
>>>>> 3.18.2 The maximum in-block EIRP spectral densities (in dBm/(0.2 
>>>>> MHz)) that the master WSD, and its associated slaves, actually 
>>>>> radiate between each reported lower frequency boundary and its 
>>>>> corresponding upper frequency boundary.
>>>>>
>>>>> Footnote 13 states:
>>>>>
>>>>> The upper and lower frequencies of a boundary pair do not straddle 
>>>>> a DTT channel boundary. Note that a WSD may transmit over 
>>>>> multiple, non-contiguous, whole DTT channels or fractions of DTT channels.
>>>>>
>>>>> 3.19 A master WSD must be able to receive the following 
>>>>> information^14 from a WSDB:
>>>>>
>>>>> <snip>
>>>>>
>>>>> that the reported information on the DTT channels and EIRP 
>>>>> spectral densities actually used by the master and slave WSDs were 
>>>>> received successfully by the WSDB^18 ].
>>>>>
>>>>> Footnote 14 states:
>>>>>
>>>>> 14 While the communication of some of this information from a WSDB 
>>>>> to a master WSD is optional, master WSDs must be able to receive 
>>>>> and interpret these.
>>>>>
>>>>> Footnote 18 states:
>>>>>
>>>>> 18 This forms part of a handshake protocol and may be an area 
>>>>> where industry could harmonise without the need for an explicit 
>>>>> requirement in the regulations.
>>>>>
>>>>> Regards
>>>>>
>>>>> Andy
>>>>>
>>>>> *From:[email-masked] [mailto:[email-masked]] *On 
>>>>> Behalf Of [email-masked]
>>>>> 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.
>>>>>
>>>>> http://www.ietf.org/internet-drafts/draft-ietf-paws-problem-stmt-u
>>>>> seca
>>>>> ses-rqmts-03.txt
>>>>>
>>>>>
>>>>> 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: <[email-masked]>
Date: Tue, 6 Mar 2012 17:32:22 +0000

Hi Gerald,

I believe Andy's proposal agrees with your suggestion below. Looking at O.13bis, the slave MAY send the channel usage information and if it does so, it MUST include the following variables. I think P.12bis is appropriate since the message MUST be defined by the protocol in order to have the OPTION of sending it. When these two requirements are considered jointly does this provide the implementation flexibility you are thinking of?

Kind Regards,
Scott

From: ext Chouinard <[email-masked]<mailto:[email-masked]>>
Date: Tue, 6 Mar 2012 12:13:05 -0500
To: Scott Probasco <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting

Scott,

I am fine with your approach as long as the text says something as follows: “the operating channel of the slave needs to be provided to the database” rather than: “the slave needs to provide the database with its operating channel”.  This way, this information can be provided by either the slave or the master, not making it mandatory that the “slave” has to do it if the master knows the information.

The text proposed by Andy: “The protocol MUST support a channel usage message from the slave device to the master device.” Implies that the protocol to be developed needs to apply on the connection between the slave and the master. Such connection should be implementation dependant.  What is required is that the information be available to the master for it to transmit it to the database, never mind the format that isused between the slave and the master to carry this information.

Gerald

________________________________
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Tuesday, 06 March, 2012 12:00
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting

Hi Gerald,

Kind Regards,
Scott

Andy,

Gerald

All

- end of new text -

Footnote 13 states:

Footnote 14 states:

Footnote 18 states:

Regards

Andy

Thanks, Gabor

---

From: Gerald Chouinard <[email-masked]>
Date: Tue, 6 Mar 2012 12:44:09 -0500

Scott,

I am fine with your second sentence.  However, I have some difficulty with
your third sentence since this would mean that the IETF-PAWS would get into
defining the signaling details between the slave and the master devices. I
believe this should be left to the wireless standard.  Obviously, having
this information available at the master would become a requirement that the
wireless standard would have to meet to be able to operate in white space.
The way it would be done would be internal to the wireless standard.  PAWS
would take it from the master to the database.

Gerald

  _____  

From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, 06 March, 2012 12:32
To: [email-masked]
Cc: [email-masked]
Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03:
channel reporting

Hi Gerald,

I believe Andy's proposal agrees with your suggestion below. Looking at
O.13bis, the slave MAY send the channel usage information and if it does so,
it MUST include the following variables. I think P.12bis is appropriate
since the message MUST be defined by the protocol in order to have the
OPTION of sending it. When these two requirements are considered jointly
does this provide the implementation flexibility you are thinking of?

Kind Regards,

Scott

From: ext Chouinard <[email-masked]>
Date: Tue, 6 Mar 2012 12:13:05 -0500
To: Scott Probasco <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03:
channel reporting

Scott,

transmit it to the database, never mind the format that isused between the

Gerald

  _____  

Hi Gerald,

Kind Regards,

Scott

Andy,

Gerald

  _____  

All

- end of new text -

Footnote 13 states:

<snip>

Footnote 14 states:

Footnote 18 states:

Regards

Andy

Thanks, Gabor

---

From: <[email-masked]>
Date: Tue, 6 Mar 2012 18:05:17 +0000

Hi Gerald,

I agree with you that some wireless standards will include signaling that supports database access. But PAWS is not specific to any particular radio technology, we cannot expect that all radio technologies will include some components of the signaling for database access. PAWS should include all necessary messages for contact between the device and the database, without presumption of the underlying radio technology.

Kind Regards,
Scott

Date: Tue, 6 Mar 2012 12:44:09 -0500

Scott,

I am fine with your second sentence.  However, I have some difficulty with your third sentence since this would mean that the IETF-PAWS would get into defining the signaling details between the slave and the master devices. I believe this should be left to the wireless standard.  Obviously, having this information available at the master would become a requirement that the wireless standard would have to meet to be able to operate in white space. The way it would be done would be internal to the wireless standard.  PAWS would take it from the master to the database.

Gerald

________________________________
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Tuesday, 06 March, 2012 12:32
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting

Hi Gerald,

I believe Andy's proposal agrees with your suggestion below. Looking at O.13bis, the slave MAY send the channel usage information and if it does so, it MUST include the following variables. I think P.12bis is appropriate since the message MUST be defined by the protocol inorder to have the OPTION of sending it. When these two requirements are considered jointly does this provide the implementation flexibility you arethinking of?

Kind Regards,
Scott

Scott,

The text proposed by Andy: “The protocol MUST support a channel usage message from the slave device to the master device.” Implies that the protocol to be developed needs to apply on the connection between the slave and the master. Such connection should be implementation dependant.  What is required is that the information beavailable to the master for it to transmit it to the database, never mind the format that isused between the slave and the master to carry this information.

Gerald

Hi Gerald,

Kind Regards,
Scott

Andy,

Gerald

All

- end of new text -

Footnote 13 states:
The use of upper and lower frequency boundaries (defined over a 200 kHz raster) allows a WSDB to collect more granular information with regards to the usage of the frequency resource bynarrowband WSD technologies. The upper and lower frequencies of a boundary pair do notstraddle a DTT channel boundary. Note that a WSD may transmit over multiple, non-contiguous, whole DTT channels or fractions of DTT channels.

Footnote 14 states:

Footnote 18 states:

Regards

Andy

Thanks, Gabor

---

From: Gerald Chouinard <[email-masked]>
Date: Tue, 6 Mar 2012 13:18:25 -0500

Scott,

I believe that this could be kept simple by assuming that if a device needs
to directly communicate its information to the database, it can be
considered for the purpose of PAWS as a “master” device. If this can be
done through a proxy device in between, then the device needs to be slaved
to this device in between which will then be considered as the “master”.
In such case, the wireless standard used between these devices needs to have
all the necessary means to transmit the necessary information from the
“slave” to its “master” to meet the requirements of white space
operation.  The way it is done can vary from one technology to another. This
was, the scope of PAWS is limited to the link between the master and the
database and not between the slave and the master.

Gerald

  _____  

From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, 06 March, 2012 13:05
To: [email-masked]
Cc: [email-masked]
Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03:
channel reporting

Hi Gerald,

I agree with you that some wireless standards will include signaling that
supports database access. But PAWS is not specific to any particular radio
technology, we cannot expect that all radio technologies will include some
components of the signaling for database access. PAWS should include all
necessary messages for contact between the device and the database, without
presumption of the underlying radio technology.

Kind Regards,

Scott

Scott,

Gerald

  _____  

Hi Gerald,

I believe Andy's proposal agrees with your suggestion below. Looking at
O.13bis, the slave MAY send the channel usage information and if it does so,
it MUST include the following variables. I think P.12bis is appropriate
since the message MUST be defined by the protocol inorder to have the OPTION
of sending it. When these two requirements are considered jointly does this
provide the implementation flexibility you arethinking of?

Kind Regards,

Scott

Scott,

required is that the information beavailable to the master for it to

Gerald

  _____  

Hi Gerald,

Kind Regards,

Scott

Andy,

Gerald

  _____  

All

- end of new text -

Footnote 13 states:

and lower frequencies of a boundary pair do notstraddle a DTT channel

<snip>

Footnote 14 states:

Footnote 18 states:

Regards

Andy

Thanks, Gabor

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 7 Mar 2012 11:40:59 -0500

<as individual, at least for now>
I'd also suggest that our charter limitation is really support for sharing of whitespace by whitespace devices.  Reporting what you use is not sharing, it's just data gathering.

The point of excluding sharing was to eliminate the complexities of what constituted fairness, and what kinds of communication might be needed between databases, where more than one could supply available whitespace in a band.  This doesn't have any of those issues,
As long as it's just sending information, I don't have a problem.  Once the database is supposed to do anything with it that involves changing what spectrum it reports, then I think we cross the line.

Brian

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 07 Mar 2012 17:41:47 -0700

<hat type='AD'/>

As your responsible Area Director (until March 28, when Pete Resnick
will take over from me), I have reviewed this thread.

In my opinion (I am happy to be proven wrong), this new requirement goes
beyond what the charter defined as the scope of this working group,
which was to enable a device to discover the white space available to it
in its current location. Reporting usage back to the database is simply
not mentioned in the charter.

Earlier in this thread, Andy Sago wrote:

   this out of scope.

An IETF charter defines what the working group shall work on. Many
interesting features could be developed here. However, it is not the job
of the charter to mention explicitly that each of those interesting
features is out of scope.

The charter does say:

  Once the device learns of the available white space (e.g., in a TV
  white space implementation, the list of available channels at that
  location), it can then select one of the bands from the list and
  begin to transmit and receive on the selected band.

This text might have assumed that no further communication or
authorization was required in order to select one of the bands from the
list and then transmit/receive. Perhaps that assumption was mistaken. If
so, it would be good to have a discussion about that, so we can
determine if we need to revisit the assumptions we made early on. If in
fact we made some faulty or limited assumptions, then let's get that out
in the open.

Peter

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 7 Mar 2012 19:57:59 -0500

<as individual>
I think that this requirement easily fits in:

In addition, the particular
data exchanged between a device and a database might depend on the
ranges of radio spectrum that are to be used, the REQUIREMENTS OF the
database operators and their GOVERNING REGULATIONS, and other factors.

emphasis added.

It is data exchanged between the device and the database and It doesn't significantly alter the design of the protocol, and specifically doesn't tread into areas of concern when the charter was written.  We didn't have the benefit of the OFCOM rules at the time, or we could have explicitly included it.

Again, if the whitespace returned somehow depended on this information, then I think we would be out of scope.

I defer to your decision, of course.

Brian

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 07 Mar 2012 18:25:02 -0700

<hat type='AD'/>

On 3/7/12 5:57 PM, Rosen, Brian wrote:
> <as individual> I think that this requirement easily fits in:
> 
> In addition, the particular data exchanged between a device and a
> database might depend on the ranges of radio spectrum that are to be
> used, the REQUIREMENTS OF the database operators and their GOVERNING
> REGULATIONS, and other factors.
> 
> emphasis added.

As I understood it, the device would query the database for available
white space, and the database would reply. We thought that the query
would contain at least the device's location:

  3. Provide its geolocation and perhaps other data to the database
     using a well-defined format for querying the database.

We also envisioned that extension points would be provided in the
protocol so that the "other data" could be provided; the two sentences
in the charter right after the one you just quoted are:

  Therefore, the database access method and the query/response data
  formats that are exchanged using that method need to be designed for
  extensibility rather than being tied to any specific spectrum,
  country, or phy/mac/air interface.  For example, the working group
  should define extension points for the database access method and the
  query/response formats, so that use cases other than those currently
  envisioned can be addressed in the future if a community of interest
  wishes to do so.

Correct me if I'm wrong, but what we're discussing here is not a new
field in the database query -- it is a reporting mechanism. I would be
more comfortable if we said something like "to meet Ofcom requirements,
the database query needs to include [FieldX]".

The charter does say:

  Once the device learns of the available white space (e.g., in a TV
  white space implementation, the list of available channels at that
  location), it can then select one of the bands from the list and
  begin to transmit and receive on the selected band.  If the device's
  parameters have changed (e.g., if some amount of time has passed or if
  the device has changed location beyond a specified threshold), it
  might need to query the database again to determine what white space
  is still available.

I suppose one could envision the following flow:

1. Device queries database.

2. Database responds with list of available channels.

3. Device queries database again, providing a new parameter: the actual
channel it wants to use (which it can't know until it receives the
original list of channels or tries to do something with the original
list of channels, such as transmit/receive).

4. Database responds with updated list of available channels (where the
updated list is based on information the device provided in step 3).

That's a bit of a strange way to look at it, though.

> It is data exchanged between the device and the database and It
> doesn't significantly alter the design of the protocol, and
> specifically doesn't tread into areas of concern when the charter was
> written.  We didn't have the benefit of the OFCOM rules at the time,
> or we could have explicitly included it.
> 
> Again, if the whitespace returned somehow depended on this
> information, then I think we would be out of scope.

But doesn't it? Or is this reporting purely informational?

> I defer to your decision, of course.

I am not a special person to whom one must defer. I'm just a member of
the community who happens to be serving in the AD role for a few years.

Peter

--
Peter Saint-Andre
https://stpeter.im/

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 7 Mar 2012 20:33:55 -0500

I guess I think we would extend the query to:
Request (with device parameters)
Response (with available spectrum)
Acknowledge (with chosen spectrum)

It then completely fits in the definition.  I don't think the extra message is anything particularly special, and a 3 way is a common transaction sequence.

As I understand the Ofcom rules, it's purely informational.  Someone can correct me if I am wrong.  They want to monitor what is being used.

Brian

---

From: Nancy Bravin <[email-masked]>
Date: Wed, 7 Mar 2012 19:17:43 -0800

Peter and all, 

I agree that it is important to revisit now, so that in the future, it will be easy to align things in their proper place. Every country may have different regulations, spectrum, policy
and what responsibility is in the domain of the system, and what comes under the PAWS charter is important.  Maybe some separation might
be possible, and dividing and clarifying issues now will help in the future.  Certainly it seems that the FCC may change some rules, and we
know that Ofcom is not yet finished with their regulations. Canada has their own, and other countries are working on this as well.
Just a thought…Sharing is a realistic goal…as is off loading...
Or you slim line and every 6 months decide what to incorporate in the protocol based on new information, new ideas, new innovation new regulations and maybe spend more
time than you could if addressed now. 

That way you leave the door open and outside of referencing what is known today, by referencing regulations i.e. Ofcom, FCC, Industry Canada etc as of XX-XX-XXXX date.
Out of scope not something we know enough about to say at this point, In my opinion.

My 2 cents..  

Sincerely, Nancy

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 08 Mar 2012 09:58:58 -0700

Hi Nancy,

You are absolutely right that different locales will have different
rules and requirements. We need to understand those, and work to address
them if possible (although we don't necessarily need to address them all
at the same time). I see several kinds of requirements:

1. Some requirements might lead to features beyond the query/response
protocol we've envisioned so far. One example might be real-time
reporting about the channels that a device is actually using. In my
opinion, it would be best to handle those in the next phase of work,
because as far as I can see they are outside the scope of our charter.

2. Some requirements might be handled through by defining additional
fields that can be included in the query or response. We definitely
planned for that when working on the charter with the IESG:

  In addition, the particular
  data exchanged between a device and a database might depend on the
  ranges of radio spectrum that are to be used, the requirements of the
  database operators and their governing regulations, and other factors.
  Therefore, the database access method and the query/response data
  formats that are exchanged using that method need to be designed for
  extensibility rather than being tied to any specific spectrum,
  country, or phy/mac/air interface.

It's unclear to me right now if the Ofcom requirement fits into #1 or
#2, which is why we're having this discussion. :)

Peter

On 3/7/12 8:17 PM, Nancy Bravin wrote:
> Peter and all,
> 
> I agree that it is important to revisit now, so that in the future,
> it will be easy to align things in their proper place. Every country
> may have different regulations, spectrum, policy and what
> responsibility is in the domain of the system, and what comes under
> the PAWS charter is important.  Maybe some separation might be
> possible, and dividing and clarifying issues now will help in the
> future.  Certainly it seems that the FCC may change some rules, and
> we know that Ofcom is not yet finished with their regulations. Canada
> has their own, and other countries are working on this as well. Just
> a thought…Sharing is a realistic goal…as is off loading... Or you
> slim line and every 6 months decide what to incorporate in the
> protocol based on new information, new ideas, new innovation new
> regulations and maybe spend more time than you could if addressed
> now.
> 
> That way you leave the door open and outside of referencing what is
> known today, by referencing regulations i.e. Ofcom, FCC, Industry
> Canada etc as of XX-XX-XXXX date. Out of scope not something we know
> enough about to say at this point, In my opinion.
> 
> My 2 cents..
> 
> Sincerely, Nancy
> 
>> As your responsible Area Director (until March 28, when Pete
>> Resnick will take over from me), I have reviewed this thread.
>> 
>> In my opinion (I am happy to be proven wrong), this new requirement
>> goes beyond what the charter defined as the scope of this working
>> group, which was to enable a device to discover the white space
>> available to it in its current location. Reporting usage back to
>> the database is simply not mentioned in the charter.
>> 
>> interesting features could be developed here. However, it is not
>> the job of the charter to mention explicitly that each of those
>> interesting features is out of scope.
>> 
>> The charter does say:
>> 
>> authorization was required in order to select one of the bands from
>> the list and then transmit/receive. Perhaps that assumption was
>> mistaken. If so, it would be good to have a discussion about that,
>> so we can determine if we need to revisit the assumptions we made
>> early on. If in fact we made some faulty or limited assumptions,
>> then let's get that out in the open.
>> 
>> Peter
>> 
>>> <as individual, at least for now> I'd also suggest that our
>>> charter limitation is really support for sharing of whitespace by
>>> whitespace devices.  Reporting what you use is not sharing, it's
>>> just data gathering.
>>> 
>>> The point of excluding sharing was to eliminate the complexities
>>> of what constituted fairness, and what kinds of communication
>>> might be needed between databases, where more than one could
>>> supply available whitespace in a band.  This doesn't have any of
>>> those issues, As long as it's just sending information, I don't
>>> have a problem.  Once the database is supposed to do anything
>>> with it that involves changing what spectrum it reports, then I
>>> think we cross the line.
>>> 
>>> Brian
>>> 
>>>> Indeed, the regulator has not described the process or provided
>>>> a flow diagram, so there may be some wrinkles, but we need to
>>>> provide for their intent. To answer your question, the channels
>>>> that the master will use are sent in a separate message
>>>> (described in P.12 ter), that occurs after the master receives
>>>> the response to its channel request, but before the master can
>>>> transmit. At this point, it knows what channels are available,
>>>> and which one it will use. As far as the slaves are concerned,
>>>> as they associate, the master will need to gather their details
>>>> and send further channel usage messages to the database on
>>>> their behalf.
>>>> 
>>>> Regards
>>>> 
>>>> Andy
>>>> 
>>>> -----Original Message----- From: [email-masked]
>>>> [mailto:[email-masked]] On Behalf Of Joel M. Halpern 
>>>> Sent: 06 March 2012 17:05 To: [email-masked] Cc:
>>>> [email-masked]; Cheeseman,CJ,Chris,COD R; Dixon,JS,Johnny,COD R 
>>>> Ahh.  I think I see where the request and my understanding
>>>> divurge. If the idea here is that the master must provide, in
>>>> the request, an indication of what channels it expects to use,
>>>> I can at least understand that.  I will return to technical
>>>> concerns in a moment.
>>>> 
>>>> However, when you say "provide channel usage information, in
>>>> order to evaluate interference", what that says to me is
>>>> providing, during operation, information as to what channels
>>>> are being used, and at what power levels.  That is what would
>>>> be needed to analyze actual interference effects. And that is
>>>> out of scope as I understand our scope.
>>>> 
>>>> I do see a technical difficulty with having the master provide,
>>>> as part of either registering or requesting spectrum
>>>> information, what channels it intends to use.  It doesn;t know
>>>> what channels it intends to use.  It intends to use some number
>>>> of available channels.  It will figure out which ones when it
>>>> is told what is available.  How can it send that information in
>>>> the request?
>>>> 
>>>> Yours, Joel
>>>> 
>>>>> There is a similarity here with device ID. In context of PAWS
>>>>> we are not concerned with why a device ID is required by a
>>>>> regulator, we accept it is a requirement from a regulator and
>>>>> include it to the protocol. Ofcom identifies in 3.18&  3.19
>>>>> that channel usage information is required and thus we need
>>>>> to include this information. Since the master must provide
>>>>> this information prior to transmitting, PAWS will not
>>>>> function in the UK without this information and thus I 
>>>>> Kind Regards, Scott
>>>>>> I would draw a distinction.  Ofcom regulations about
>>>>>> whitespace requests are very much relevant. Ofcom
>>>>>> regulations about notification of dynamic behavior (which 
>>>>>> spectrum is being used) are not in scope as I understand
>>>>>> the earlier discussions, particularly the chartering
>>>>>> discussions.
>>>>>> 
>>>>>> Yours, Joel
>>>>>> 
>>>>>>> The ofcom requirements are very much relevant to the
>>>>>>> scope of the PAWS WG. The only other regulatory
>>>>>>> requirements that we have today is the FCC. Ofcom
>>>>>>> requirements are a good addition to the set.
>>>>>>> 
>>>>>>> -Raj
>>>>>>> 
>>>>>>> On 3/6/12 10:03 AM, "ext
>>>>>>> [email-masked]"<[email-masked]>   wrote:
>>>>>>> 
>>>>>>>> Hi Joel
>>>>>>>> 
>>>>>>>> There's no language I can find in the charter that
>>>>>>>> explicitly puts this out of scope. On the other hand,
>>>>>>>> the charter says that the group will "consider input
>>>>>>>> from regulatory entities", and this is one of the
>>>>>>>> requirements from Ofcom that they have just published. 
>>>>>>>> The protocol will be worthless for the UK if it omits
>>>>>>>> some requirements.
>>>>>>>> 
>>>>>>>> Regards
>>>>>>>> 
>>>>>>>> Andy
>>>>>>>> 
>>>>>>>> -----Original Message----- From: Joel M. Halpern
>>>>>>>> [mailto:[email-masked]] Sent: 06 March 2012 15:53 
>>>>>>>> To: Sago,AJ,Andy,COD R Cc: [email-masked];
>>>>>>>> [email-masked] Subject: Re: [paws] WGLC for 
>>>>>>>> As I understand, the information you are asking for is
>>>>>>>> explicitly out of scope for the working group. Yours, 
>>>>>>>> Joel
>>>>>>>> 
>>>>>>>>> http://www.cept.org/Documents/se-43/4161/SE43(12)Info03_Draft-UK-r
>>>>>>>>>
>>>>>>>>> 
egul
>>>>>>>>> frequencies and powers actually used by masters and
>>>>>>>>> slaves (Ofcom requirements 3.18 and 3.19.8). Ofcom
>>>>>>>>> intends to collect this data to assesses the impact
>>>>>>>>> of aggregate interference into other services. It
>>>>>>>>> would also provide usage information (frequency in 
>>>>>>>>> use) that would inform the operation of a kill switch
>>>>>>>>> capability. I suggest this deficiency can be remedied
>>>>>>>>> with the following changes:
>>>>>>>>> 
>>>>>>>>> P.12bis: The protocol MUST support a channel usage
>>>>>>>>> message from the slave device to the master device.
>>>>>>>>> The channel usage message MUST include parameters as
>>>>>>>>> required by local regulatory requirement.  These
>>>>>>>>> parameters MAY include device ID, manufacturer's
>>>>>>>>> P.12ter: The protocol MUST support a channel usage
>>>>>>>>> message from the master device to the database.  The
>>>>>>>>> channel usage message MUST include parameters as
>>>>>>>>> required by local regulatory requirement for the
>>>>>>>>> master and its associated slaves.  These parameters
>>>>>>>>> MAY include device ID, manufacturer's serial number,
>>>>>>>>> O.13bis:  According to local regulatory policy, after
>>>>>>>>> connecting to a master device's radio network a slave
>>>>>>>>> device MAY inform the master device of the actual
>>>>>>>>> channel usage. The slave MUST include parameters
>>>>>>>>> required by local regulatory policy, e.g. device ID, 
>>>>>>>>> O.13ter:  According to local regulatory policy, a
>>>>>>>>> master device MAY inform the database of the actual
>>>>>>>>> channel usage of the master and its slaves. The
>>>>>>>>> master MUST include parameters required by local
>>>>>>>>> regulatory policy, e.g. device ID, manufacturer's
>>>>>>>>> serial number, channel usage and power level
>>>>>>>>> New steps could be introduced into one or more use
>>>>>>>>> cases to cover these Ofcom requirements, e.g. new
>>>>>>>>> steps 6bis and 9bis in the hotspot use case at
>>>>>>>>> 4.2.1:
>>>>>>>>> 
>>>>>>>>> 6bis. Prior to initiating transmission, if required
>>>>>>>>> by local regulation, the master/AP informs the
>>>>>>>>> database of the channel and power level it has
>>>>>>>>> 9bis. Prior to initiating transmission, if required
>>>>>>>>> by local regulation, the slave informs the master/AP
>>>>>>>>> of the channel and power level it has chosen, and the
>>>>>>>>> master/AP relays this information to the database.
>>>>>>>>> 
>>>>>>>>> - end of new text -
>>>>>>>>> 
>>>>>>>>> For information, for those not accessing the url in
>>>>>>>>> the first paragraph of this email, the full Ofcom
>>>>>>>>> requirements leading to this new PAWS text are as
>>>>>>>>> follows:
>>>>>>>>> 
>>>>>>>>> 3.18 After receiving instructions from a WSDB in
>>>>>>>>> relation to the maximum permitted EIRPs over the DTT
>>>>>>>>> channels, and prior to initiating transmissions
>>>>>>>>> within the UHF TV band, a master WSD must communicate
>>>>>>>>> to the WSDB the following information:
>>>>>>>>> 
>>>>>>>>> 3.18.1 The lower and upper frequency boundaries^13 of
>>>>>>>>> the in-block emissions of the master WSD, and those
>>>>>>>>> of the in-block emissions of its associated slaves. A
>>>>>>>>> lower frequency will be specified as (470 + 8k + 
>>>>>>>>> 0.2n) MHz, with the corresponding upper frequency
>>>>>>>>> specified as (470 + 8k + 0.2m) MHz, where 0 3Ž4 k 3Ž4
>>>>>>>>> 39, 0 3Ž4 n 3Ž4 39, 1 3Ž4 m 3Ž4 40, and n<   m.
>>>>>>>>> 
>>>>>>>>> 3.18.2 The maximum in-block EIRP spectral densities
>>>>>>>>> (in dBm/(0.2 MHz)) that the master WSD, and its
>>>>>>>>> associated slaves, actually radiate between each
>>>>>>>>> reported lower frequency boundary and its 
>>>>>>>>> The use of upper and lower frequency boundaries
>>>>>>>>> (defined over a 200 kHz raster) allows a WSDB to
>>>>>>>>> collect more granular information with regards to the
>>>>>>>>> usage of the frequency resource by narrowband WSD 
>>>>>>>>> technologies. The upper and lower frequencies of a
>>>>>>>>> boundary pair do not straddle a DTT channel boundary.
>>>>>>>>> Note that a WSD may transmit over multiple,
>>>>>>>>> 3.19 A master WSD must be able to receive the
>>>>>>>>> following information^14 from a WSDB:
>>>>>>>>> 
>>>>>>>>> <snip>
>>>>>>>>> 
>>>>>>>>> 3.19.8     [An acknowledgement from the WSDB, in the
>>>>>>>>> context of 3.18, that the reported information on the
>>>>>>>>> DTT channels and EIRP spectral densities actually
>>>>>>>>> used by the master and slave WSDs were received
>>>>>>>>> 14 While the communication of some of this
>>>>>>>>> information from a WSDB to a master WSD is optional,
>>>>>>>>> master WSDs must be able to receive and interpret
>>>>>>>>> these.
>>>>>>>>> 
>>>>>>>>> Footnote 18 states:
>>>>>>>>> 
>>>>>>>>> 18 This forms part of a handshake protocol and may be
>>>>>>>>> an area where industry could harmonise without the
>>>>>>>>> need for an explicit requirement in the regulations.
>>>>>>>>> 
>>>>>>>>> Regards
>>>>>>>>> 
>>>>>>>>> Andy
>>>>>>>>> 
>>>>>>>>> *From:[email-masked]
>>>>>>>>> [mailto:[email-masked]] *On Behalf Of
>>>>>>>>> [email-masked] *Sent:* 05 March 2012 19:46 
>>>>>>>>> *To:* [email-masked] *Subject:* [paws] WGLC for 
>>>>>>>>> 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
seca
>>>>>>>>> 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: "Joel M. Halpern" <[email-masked]>
Date: Thu, 08 Mar 2012 12:07:12 -0500

Unfortunately, given the statements that
a) This information is provided in additional messages after the master 
receives the whitespace data;
b) That the master has to update this information if the usage changes;

both of which were stated to be part of the meaning of the requirements,
it follows that we are in category #1 below.

Yours,
Joel

On 3/8/2012 11:58 AM, Peter Saint-Andre wrote:
>>>> On Mar 6, 2012, at 12:28 PM,<[email-masked]>
>>>> <[email-masked]>  wrote:
>>>>
>>>>> Joel
>>>>>
>>>>>>>>>> information.

---

From: "Zuniga, Juan Carlos" <[email-masked]>
Date: Thu, 8 Mar 2012 12:11:23 -0500

Peter, Nancy,

I agree should design a protocol with the best of our current knowledge, and that should be accounting for all the known regulations at present time. We should not limit the scope with the purpose of designing a protocol 'faster'. Our goal is not only to design a WSDB protocol. Our goal is to design a WSDB protocol that is USEFUL to the community.

The charter does state that 

"...the group should also reach out to other potential
"customers" for a white space database access method and consider input
from regulatory entities that are involved in the specification of the
rules for secondary use of spectrum in specific radio bands. "

I think that is exactly what we are doing now.

Regarding whether the types of requirements belong to #1 or #2, I believe it is more of #1 type, as the information to be exchanged would be known after the initial query/response. 

If we know it today, I see no reason why we should not work on it in the first phase of the work.

Regards,

Juan Carlos

> Sent: Thursday, March 08, 2012 11:59 AM
> To: Nancy Bravin
> Cc: [email-masked]; [email-masked]; [email-masked]; Pete
> Resnick

---

From: <[email-masked]>
Date: Thu, 8 Mar 2012 17:17:59 +0000

Hi,

The point from Brian is very relevant:

Channel request
Channel response
Channel acknowledgement

What Ofcom does with the information in the acknowledgement does not
matter. As the regulator in UK, they write rules that must be followed in
order to operate a whitespace radio in the UK. I believe the scope of the
WG must be focused on a working solution. If this is simple channel
request & response in one regulator's domain, PAWS can support this. If it
means a channel request, response and acknowledgement in another
regulator's domain, PAWS can support this. As a participating member of
the work group, I believe the  scope should be basic working solution, not
limited to a specific number of messages.

Kind Regards,
Scott

On 3/8/12 11:11 AM, "ext Zuniga, Juan Carlos"
<[email-masked]> wrote:

>Peter, Nancy,
>
>I agree should design a protocol with the best of our current knowledge,
>and that should be accounting for all the known regulations at present
>time. We should not limit the scope with the purpose of designing a
>protocol 'faster'. Our goal is not only to design a WSDB protocol. Our
>goal is to design a WSDB protocol that is USEFUL to the community.
>
>Regarding whether the types of requirements belong to #1 or #2, I believe
>it is more of #1 type, as the information to be exchanged would be known
>after the initial query/response.
>
>> > a thought...Sharing is a realistic goal...as is off loading... Or you

---

From: <[email-masked]>
Date: Thu, 8 Mar 2012 17:19:54 +0000

Hi Gerald,

I agree that some wireless standards will elect to implement signaling related to database access, e.g. signaling between the slave the and the master. But PAWS is independent of the radio and therefore cannot expect that portions of the necessary signaling will be implemented elsewhere. In the scope of the WG we don't differentiate between a master or slave, we simply address providing channel lists to ensure proper operation of a white space radio network.

Perhaps the chairs could allocate some time on the agenda in the coming meeting to discuss this topic.

Kind Regards,
Scott

Date: Tue, 6 Mar 2012 13:18:25 -0500

Scott,

I believe that this could be kept simple by assuming that if a device needs to directly communicate its information to the database, it can be considered for the purpose of PAWS as a “master” device. If this can be done through a proxy device in between, then the device needs to be slaved to this device in between which will then be considered as the “master”. In such case, the wireless standard used between these devices needs to have all the necessary means to transmit the necessary information from the “slave” to its “master” to meet the requirements of white space operation.  The way it is done can vary from one technology to another. This was, the scope of PAWS is limited to the link between the master and the database and not between the slave and the master.

Gerald

Hi Gerald,

Kind Regards,
Scott

Scott,

Gerald

Hi Gerald,

Kind Regards,
Scott

Scott,

Gerald

Hi Gerald,

Kind Regards,
Scott

Andy,

Gerald

All

- end of new text -

Footnote 13 states:

Footnote 14 states:

Footnote 18 states:

Regards

Andy

Thanks, Gabor

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 08 Mar 2012 10:39:10 -0700

Hi Scott, I have two clarifying questions:

1. Does the device know, when it receives the channel response, which
channel it will actually use?

2. If the device then uses another channel or a different channel, does
it need to report that change to the database?

Thanks!

Peter

---

From: <[email-masked]>
Date: Thu, 8 Mar 2012 18:09:57 +0000

Hi Peter,

Answers below.

Kind Regards,
Scott

>channel it will actually use?
Scott->This is all new and I am not aware of any existing implementations.
I would argue that the device must decide what channel(s) it will use when
it receives the channel response.
>it need to report that change to the database?
Scott->My interpretation of section 3.18 is that the device can only
transmit within the upper & lower frequencies returned in the
acknowledgment. I do not (quickly) find any reference in the requirements
to changing channels. Thus operationally it could be that the channel
request process must be repeated before the device can use a different
channel (frequencies).
>>> If we know it today, I see no reason why we should not work on it in
>>>the
>>> first phase of the work.
>>>
>>> Regards,
>>>
>>> Juan Carlos
>>>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 08 Mar 2012 13:16:43 -0500

So why won't the device simply say "I will use all of this?"
After all, that way it needs to do less work with the database.  And it 
can change frequencies when it wants.
Given that the stated goal of the Ofcom requriement was to be able to 
analyze interference effects, it seems that this will not actually lead 
to them getting what they want, even if it does comply with the regulations.

Yours,
joel

On 3/8/2012 1:09 PM, [email-masked] wrote:
> Hi Peter,
>
> Answers below.
>
> Kind Regards,
> Scott
>
> On 3/8/12 11:39 AM, "ext Peter Saint-Andre"<[email-masked]>  wrote:
>
> transmit within the upper&  lower frequencies returned in the
>>> request&  response in one regulator's domain, PAWS can support this. If
>>> it

---

From: <[email-masked]>
Date: Thu, 8 Mar 2012 18:25:33 +0000

Hi Joel,

A device could give that answer. But I expect the local regulator would
not allow this, perhaps proactively by refusing local certification of the
device or perhaps retroactively by disabling the device type(s) that try
to claim all available spectrum.

Both the described action and response are speculation.

Kind Regards,
Scott

---

From: Rex Buddenberg <[email-masked]>
Date: Thu, 8 Mar 2012 10:39:35 -0800

Joel, while this sounds on the surface like simply greedy, there's a
scalability rationale too.

Radio-WAN capacity is about four orders of magnitude less than
terrestrial-WAN capacity.  Worse, the diff is likely to widen as the
limitations on terrestrial-WAN backbones are engineering while the
radio-WAN is approaching physics limitations.  

What you may get is indeed: 
> device simply say "I will use all of this
and the device indeed might use all -- in an inverse multiplex
fashion.  

In keeping with the intent of PAWS we should not impose a value judgment
-- the greed may be good or bad.  

(I'm not sure what the WG should be doing about this; simply an
observation at this point).

---

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

Joel, Scott,

Interesting discussion! See my comments in line below.

Gerald

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Joel
M. Halpern
Sent: Thursday, 08 March, 2012 13:17
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03:
channel reporting

So why won't the device simply say "I will use all of this?"
[GC] This would defeat the purpose of the acknowledgement message.
After all, that way it needs to do less work with the database.  And it 
can change frequencies when it wants.
Given that the stated goal of the Ofcom requriement was to be able to 
analyze interference effects, it seems that this will not actually lead 
to them getting what they want, even if it does comply with the regulations.
[GC] You got it.  This would be useless for spectrum regulators. One should
realize that, from the spectrum regulator's point of view, the second and
third messages could be iterated upon to optimize the spectrum use.  Knowing
what channels the systems in an area are using, the spectrum regulators
and/or other entities such as those taking care of coexistence could use the
database in near-real-time to iterate on the two last messages to reduce the
range of channels that some systems may use once they know precisely what
channels are being used in the area. The PAWS protocol would carry the
information back and forth but would not be involved in such spectrum use
optimization.

Yours,
joel

> it receives the channel response.
[GC] Agree with Scott but this is only a portion of the considerations. If a
device was to operate on its own, this would be true but a communication
device usually implies at least 2 devices to communicate. Hence, the choice
of the channel to be used will need to be negotiated between the two devices
before a choice can be made.  The chosen channel will belong to the set of
available channels that is common to both devices. Remember that some
channels may be available at one device and not at the other because of
their geolocation or other reason. Extending this concept to a star network
topology, the channel that will be selected by this network will have to
belong to the set of channels that are available to all devices. Each device
will not be able to decide by itself which channel it wants to use.

This is why in such a star topology, it makes sense that the slave devices
to a base station or access point be represented by the base station acting
as the master on their behalf to query the database and receive the list of
available channels (and/or maximum EIRP per channel). It is then the
responsibility of the base station to identify the set of available channels
that is common for itself and all its slaves to decide on the channel that
the network will use. As you can see, in this case, there is no need for
each slave to receive its list of available channels. On its own, it would
not know what to do with it. The only thing that needs to be sent from the
master device to its slaves is the resulting operating channel.

I a more sophisticated operation, the master device may add one or a few
backup channels extracted from the common set of available channel to the
message going to its slave so that if a change in channel availability
occurs, an instantaneous switch to the next backup channel can be made
without any further signaling, thus providing for a channel switch that is
transparent to the user. It is the scheme that has been included in the IEEE
802.22-2011 Standard. This is why I don't believe that PAWS should get
involved in defining this signaling between the base station and its slaves
devices.
> request process must be repeated before the device can use a different
[GC] If the process involves 2 messages, then, the device and its associated
devices could change channels at will as long as all these channels belong
to the set of available channel. However, if the third message is added, it
would make sense that the master device reports to the database any channel
change that would occur to the database, otherwise, the status of the
spectrum occupation would be wrong at any moment and would be useless for
the purpose of any spectrum usage optimization such as coexistence.

---

From: Gerald Chouinard <[email-masked]>
Date: Thu, 8 Mar 2012 14:10:21 -0500

Scott,

I agree with you that, as far as the database is concerned, all devices
should look the same and the assumption should be that each of these devices
would contact the database to receive its list of available channel.
However, if a network operation is such that queries for some of the devices
are made through a ‘proxy’ such as a base station representing its
associated slaves, it should be transparent to the database (except for the
IP address where the information is sent to). That the ‘proxy’ sends this
list of available channels to the represented slave or its ‘proxy’ should
not matter to the database.  As far at it is concerned, it did its job. It
should not get involved with the communication on the other side of the
‘proxy’.

As you can see in the other email thread that I have just responded to, the
information going from the base station to its associated slaves could be
very different than the list of available channels for these individual
devices. The choice of the operating channel involves an intersection of all
available channel lists and not each the individual list.

Gerald 

  _____  

From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, 08 March, 2012 12:20
To: [email-masked]
Cc: [email-masked]
Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03:
channel reporting

Hi Gerald,

I agree that some wireless standards will elect to implement signaling
related to database access, e.g. signaling between the slave the and the
master. But PAWS is independent of the radio and therefore cannot expect
that portions of the necessary signaling will be implemented elsewhere. In
the scope of the WG we don't differentiate between a master or slave, we
simply address providing channel lists to ensure proper operation of a white
space radio network.

Perhaps the chairs could allocate some time on the agenda in the coming
meeting to discuss this topic.

Kind Regards,

Scott

Scott,

Gerald

  _____  

Hi Gerald,

Kind Regards,

Scott

Scott,

Gerald

  _____  

Hi Gerald,

Kind Regards,

Scott

Scott,

Gerald

  _____  

Hi Gerald,

Kind Regards,

Scott

Andy,

Gerald

  _____  

All

- end of new text -

Footnote 13 states:

<snip>

Footnote 14 states:

Footnote 18 states:

Regards

Andy

Thanks, Gabor

---

From: "Zuniga, Juan Carlos" <[email-masked]>
Date: Thu, 8 Mar 2012 15:25:58 -0500

So, from Gerald and Andy's comments, it seems like from the point of view of (at least) two regulatory entities it is important for the protocol to allow communicating back to the WSDB/coexistence manager the actual channel usage after the first query is made.

This is to me a very clear requirement. 

The actual messages/IEs that would carry this information should be discussed as part of the solution document, and not the requirements.

JC

> Gerald Chouinard
> Sent: Thursday, March 08, 2012 1:59 PM
> To: 'Joel M. Halpern'; [email-masked]
> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-
> rqmts-03:channel reporting
> 
> Joel, Scott,
> 
> >>> matter. As the regulator in UK, they write rules that must be
> followed
> >>> in
> >>> order to operate a whitespace radio in the UK. I believe the scope
> of
> >>> the
> >>> the work group, I believe the  scope should be basic working
> solution,
> >>> not
> >>>>> From: [email-masked] [mailto:[email-masked]] On
> Behalf
> >>>>> Of
> >>>>> Peter Saint-Andre
> >>>>> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-
> usecases-
> >>>>> rqmts-03: channel reporting
> >>>>>
> >>>>> Hi Nancy,
> >>>>>
> >>>>> them if possible (although we don't necessarily need to address
> them
> >>>>> all
> >>>>>    ranges of radio spectrum that are to be used, the requirements
> of
> >>>>> the
> >>>>>    formats that are exchanged using that method need to be
> designed
> for
> >>>>>>>>>>>>>> atory-requirements-for-white-space-devices-in-the-UHF-
> TV-
> >>>>> band,
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> http://www.ietf.org/internet-drafts/draft-ietf-paws-
> problem-
> >>>>> stmt-u
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>> seca
> >>>>>>>>>>>>>> ses-rqmts-03.txt
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>

---

From: <[email-masked]>
Date: Thu, 8 Mar 2012 20:32:38 +0000

Hi JC,

Where/why did the coexistence manager come into the picture? Your comment
about "communicating back to the WSDB/coexistence manager" may result in
further misunderstanding. If we simply stick to to WSDB I think we are
okay.

-Raj

On 3/8/12 2:25 PM, "ext Zuniga, Juan Carlos"
<[email-masked]> wrote:

>So, from Gerald and Andy's comments, it seems like from the point of view
>of (at least) two regulatory entities it is important for the protocol to
>allow communicating back to the WSDB/coexistence manager the actual
>channel usage after the first query is made.
>
>The actual messages/IEs that would carry this information should be
>discussed as part of the solution document, and not the requirements.
>
>JC
>

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 08 Mar 2012 13:40:39 -0700

A rose by any other name is still a rose. :)

It might be true that some folks have a very clear requirement for
adding coexistence managers to the architecture, but those are not
necessarily the same things as white space databases.

---

From: "Zuniga, Juan Carlos" <[email-masked]>
Date: Thu, 8 Mar 2012 15:41:31 -0500

Hi Raj,

I was reusing the language used from Gerald (which I know is familiar to people working on IEEE 802 WS groups):

>> [GC] You got it.  This would be useless for spectrum regulators. One 
>> should realize that, from the spectrum regulator's point of view, the 
>> second and third messages could be iterated upon to optimize the 
>> spectrum use.
>> Knowing
>> what channels the systems in an area are using, the spectrum 
>> regulators and/or other entities such as those taking care of 
>> coexistence could use the database in near-real-time to iterate on 
>> the two last messages to reduce the range of channels that some 
>> systems may use once they know precisely what channels are being used 
>> in the area. The PAWS protocol would carry the information back and 
>> forth but would not be involved in such spectrum use optimization.

Having said that, I have no issue sticking to the WSDB terminology. I like keeping things simple :)

JC

> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, March 08, 2012 3:33 PM
> To: Zuniga, Juan Carlos; [email-masked];
> [email-masked]; [email-masked]
> >> realize that, from the spectrum regulator's point of view, the
> second
> >> and
> >> information back and forth but would not be involved in such
> spectrum
> >> use
> >> optimization.
> >>
> >> Yours,
> >> joel
> >>
> >> > I would argue that the device must decide what channel(s) it will
> use
> >> when
> >> [GC] Agree with Scott but this is only a portion of the
> considerations.
> >> If a
> >> before a choice can be made.  The chosen channel will belong to the
> set
> >> of
> >> topology, the channel that will be selected by this network will
> have
> >> to
> >> belong to the set of channels that are available to all devices.
> Each
> >> device
> >> that is common for itself and all its slaves to decide on the
> channel
> >> that
> >> not know what to do with it. The only thing that needs to be sent
> from
> >> the
> >> backup channels extracted from the common set of available channel
> to
> >> the
> >> without any further signaling, thus providing for a channel switch
> that
> >> is
> >> transparent to the user. It is the scheme that has been included in
> the
> >> IEEE
> >> >> 2. If the device then uses another channel or a different
> channel,
> >> does
> >> spectrum occupation would be wrong at any moment and would be
> useless
> >> for
> >> >>>> time. We should not limit the scope with the purpose of
> designing
> >> a
> >> >>>> protocol 'faster'. Our goal is not only to design a WSDB
> protocol.
> >> Our
> >> >>>> "customers" for a white space database access method and
> consider
> >> input
> >> >>> >from regulatory entities that are involved in the specification
> of
> >> the
> >> >>>> Regarding whether the types of requirements belong to #1 or #2,
> I
> >> >>>> believe
> >> >>>> it is more of #1 type, as the information to be exchanged would
> be
> >> >>>> known
> >> >>>> If we know it today, I see no reason why we should not work on
> it
> >> in
> >> >>>> the
> >> >>>> first phase of the work.
> >> >>>>
> >> >>>> Regards,
> >> >>>>
> >> >>>> Juan Carlos
> >> >>>>
> >> >>>>> Cc: [email-masked]; [email-masked];
> [email-masked];
> >> Pete
> >> >>>>> Resnick
> >> >>>>> rules and requirements. We need to understand those, and work
> to
> >> >>>>> address
> >> >>>>> reporting about the channels that a device is actually using.
> In
> >> my
> >> >>>>>    data exchanged between a device and a database might depend
> on
> >> the
> >> >>>>>    database operators and their governing regulations, and
> other
> >> >>>>> factors.
> >> >>>>>    Therefore, the database access method and the
> query/response
> >> data
> >> >>>>> It's unclear to me right now if the Ofcom requirement fits
> into
> >> #1 or
> >> >>>>>> future.  Certainly it seems that the FCC may change some
> rules,
> >> and
> >> >>>>>> we know that Ofcom is not yet finished with their
> regulations.
> >> Canada
> >> >>>>>> has their own, and other countries are working on this as
> well.
> >> Just
> >> >>>>>> a thought...Sharing is a realistic goal...as is off
> loading...
> >> Or you
> >> >>>>>> That way you leave the door open and outside of referencing
> what
> >> is
> >> >>>>>> Canada etc as of XX-XX-XXXX date. Out of scope not something
> we
> >> know
> >> >>>>>>> available to it in its current location. Reporting usage
> back
> >> to
> explicitly
> >> puts
> >> >>>>>>> An IETF charter defines what the working group shall work
> on.
> >> Many
> >> >>>>>>> Once the device learns of the available white space (e.g.,
> in a
> >> TV
> >> >>>>>>> white space implementation, the list of available channels
> at
> >> that
> >> >>>>>>> authorization was required in order to select one of the
> bands
> >> from
> >> >>>>>>>> charter limitation is really support for sharing of
> whitespace
> >> by
> >> >>>>>>>> supply available whitespace in a band.  This doesn't have
> any
> >> of
> >> >>>>>>>> with it that involves changing what spectrum it reports,
> then
> >> I
> >> >>>>>>>> think we cross the line.
> >> >>>>>>>>
> >> >>>>>>>> Brian
> >> >>>>>>>>
> >> >>>>>>>>> [email-masked]; Cheeseman,CJ,Chris,COD R;
> Dixon,JS,Johnny,COD
> >> R
> >> >>>>>>>>> is told what is available.  How can it send that
> information
> >> in
> >> >>>>>>>>> the request?
> >> >>>>>>>>>
> >> >>>>>>>>> Yours, Joel
> >> >>>>>>>>>
> >> >>>>>>>>>> believe channel usage information is integral to the
> channel
> >> >>>>>>>>>> request&   response messaging.
> >> >>>>>>>>>>
> >> >>>>>>>>>> Kind Regards, Scott
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>>>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03:
> channel
> >> >>>>>>>>>>>>> reporting
> >> >>>>>>>>>>>>>

---

From: Gerald Chouinard <[email-masked]>
Date: Thu, 8 Mar 2012 15:49:57 -0500

Juan-Carlos, Raz,

I agree to keep it to the WSDB. What this data is used for at the WSDB, be
it statistics on spectrum use, more detailed aggregate interference
analysis, co-existence, etc., is beyond the scope of PAWS. As long as the
data is provided to the database by this third level of message, the job
would be done as far as the protocol is concerned.

Gerald

-----Original Message-----
From: Zuniga, Juan Carlos [mailto:[email-masked]] 
Sent: Thursday, 08 March, 2012 15:42
To: [email-masked]; [email-masked];
[email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: RE: [paws] WGLC for
draft-ietf-paws-problem-stmt-usecases-rqmts-03:channel reporting

Hi Raj,

I was reusing the language used from Gerald (which I know is familiar to

>> forth but would not be involved in such spectrum use optimization.

Having said that, I have no issue sticking to the WSDB terminology. I like
keeping things simple :)

JC

> >> should
> regulators

---

From: <[email-masked]>
Date: Thu, 8 Mar 2012 20:53:55 +0000

Agree. Lets keep it simple and stick to the term WSDB in PAWS.
Co-existence is a rathole at this point in time which we should studiously
avoid.

-Raj

---

From: Siew Yoon Tan <[email-masked]>
Date: Thu, 8 Mar 2012 21:05:46 +0000

Dear All,

Regarding Ofcom's requirement to have a return channel as part of the protocol between the WSD and WSDB, I would like to confirm to following sequence of messaging

Channel request
Channel response
Channel acknowledgement

which was raised in an earlier email to this list.

Our view is that it would be beneficial to define the protocol between WSD and WSDB that supports this requirement even though how the information could be used is still subject to discussion in the UK.

Best regards,

Siew Yoon

________________________________________
From: [email-masked] [[email-masked]] on behalf of Zuniga, Juan Carlos [[email-masked]]
Sent: 08 March 2012 20:41
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [paws] WGLC for    draft-ietf-paws-problem-stmt-usecases-rqmts-03:channel reporting

Hi Raj,

JC

> >> >>>>>>>>>>>>>> specified as (470 + 8k + 0.2m) MHz, where 0 3?4 k 3?4
> >> >>>>>>>>>>>>>> 39, 0 3?4 n 3?4 39, 1 3?4 m 3?4 40, and n<    m.
> >> >>>>>>>>>>>>>>

******************************************************************************************************************
For more information visit www.ofcom.org.uk

This email (and any attachments) is confidential and intended for the use of the addressee only.

If you have received this email in error please notify the originator of the message and delete it from your system.

This email has been scanned for viruses. However, you open any attachments at your own risk.

Any views expressed in this message are those of the individual sender and do not represent the views or opinions of Ofcom unless expressly stated otherwise.
******************************************************************************************************************

---

From: "Das, Subir" <[email-masked]>
Date: Fri, 9 Mar 2012 00:23:42 +0000

I have a question here. Is it really an acknowledgement or we would like to see a kind of notification message that includes channel, and other parameters?

Regards,
_Subir 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Siew Yoon Tan
Sent: Thursday, March 08, 2012 4:06 PM
To: Zuniga, Juan Carlos; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; Reza Karimi; [email-masked]; [email-masked]
Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03:channel reporting

Dear All,

Channel request
Channel response
Channel acknowledgement

Best regards,

Siew Yoon

Hi Raj,

JC

> Where/why did the coexistence manager come into the picture? Your 
> comment about "communicating back to the WSDB/coexistence manager" may 
> result in further misunderstanding. If we simply stick to to WSDB I 
> think we are okay.
>
> -Raj
>
> >of (at least) two regulatory entities it is important for the 
> >protocol
> to
> >> After all, that way it needs to do less work with the database.  
> >> And
> it
> >> [GC] You got it.  This would be useless for spectrum regulators. 
> >> One should realize that, from the spectrum regulator's point of 
> >> view, the
> second
> >> and
> >> and/or other entities such as those taking care of coexistence 
> >> could use the database in near-real-time to iterate on the two last 
> >> messages to reduce the range of channels that some systems may use 
> >> once they know precisely what channels are being used in the area. 
> >> The PAWS protocol would carry
> the
> >> device was to operate on its own, this would be true but a 
> >> communication device usually implies at least 2 devices to 
> >> communicate. Hence, the choice of the channel to be used will need 
> >> to be negotiated between the two devices before a choice can be 
> >> made.  The chosen channel will belong to the
> set
> >> of
> >> channels may be available at one device and not at the other 
> >> because
> of
> >> their geolocation or other reason. Extending this concept to a star 
> >> network topology, the channel that will be selected by this network 
> >> will
> have
> >> to
> >> This is why in such a star topology, it makes sense that the slave 
> >> devices to a base station or access point be represented by the 
> >> base station acting as the master on their behalf to query the 
> >> database and receive the list of available channels (and/or maximum 
> >> EIRP per channel). It is then the responsibility of the base 
> >> station to identify the set of available channels that is common 
> >> for itself and all its slaves to decide on the
> channel
> >> that
> >> the network will use. As you can see, in this case, there is no 
> >> need for each slave to receive its list of available channels. On 
> >> its own, it would not know what to do with it. The only thing that 
> >> needs to be sent
> from
> >> the
> >> I a more sophisticated operation, the master device may add one or 
> >> a few backup channels extracted from the common set of available 
> >> channel
> to
> >> the
> >> involved in defining this signaling between the base station and 
> >> its slaves devices.
> >> >>
> >> [GC] If the process involves 2 messages, then, the device and its 
> >> associated devices could change channels at will as long as all 
> >> these channels belong to the set of available channel. However, if 
> >> the third message is added, it would make sense that the master 
> >> device reports to the database any channel change that would occur 
> >> to the database, otherwise, the status of
> the
> >> >>> What Ofcom does with the information in the acknowledgement 
> >> >>> does
> >> not
> >> >>> means a channel request, response and acknowledgement in 
> >> >>> another regulator's domain, PAWS can support this. As a 
> >> >>> participating
> >> member of
> >> >>>> I agree should design a protocol with the best of our current 
> >> >>>> knowledge, and that should be accounting for all the known 
> >> >>>> regulations at
> >> present
> >> >>>>> opinion, it would be best to handle those in the next phase 
> >> >>>>> of
> >> work,
> >> >>>>>> responsibility is in the domain of the system, and what 
> >> >>>>>> comes
> >> under
> >> >>>>>> possible, and dividing and clarifying issues now will help 
> >> >>>>>> in
> >> the
> >> >>>>>>> As your responsible Area Director (until March 28, when 
> >> >>>>>>> Pete Resnick will take over from me), I have reviewed this
> thread.
> >> >>>>>>>
> >> >>>>>>> interesting features could be developed here. However, it 
> >> >>>>>>> is
> >> not
> >> >>>>>>> location), it can then select one of the bands from the 
> >> >>>>>>> list
> >> and
> >> >>>>>>> mistaken. If so, it would be good to have a discussion 
> >> >>>>>>> about
> >> that,
> >> >>>>>>> so we can determine if we need to revisit the assumptions 
> >> >>>>>>> we
> >> made
> >> >>>>>>>> whitespace devices.  Reporting what you use is not 
> >> >>>>>>>> sharing,
> >> it's
> >> >>>>>>>> just data gathering.
> >> >>>>>>>>
> >> >>>>>>>>> a flow diagram, so there may be some wrinkles, but we 
> >> >>>>>>>>> need
> to
> >> >>>>>>>>> the response to its channel request, but before the 
> >> >>>>>>>>> master
> >> can
> >> >>>>>>>>> and send further channel usage messages to the database 
> >> >>>>>>>>> on their behalf.
> >> >>>>>>>>>
> >> >>>>>>>>> Regards
> >> >>>>>>>>>
> >> >>>>>>>>> Andy
> >> >>>>>>>>>
> >> >>>>>>>>> Ahh.  I think I see where the request and my 
> >> >>>>>>>>> understanding divurge. If the idea here is that the 
> >> >>>>>>>>> master must provide,
> in
> >> >>>>>>>>> be needed to analyze actual interference effects. And 
> >> >>>>>>>>> that
> is
> >> >>>>>>>>> of available channels.  It will figure out which ones 
> >> >>>>>>>>> when
> it
> >> >>>>>>>>>> regulator, we accept it is a requirement from a 
> >> >>>>>>>>>> regulator
> >> and
> >> >>>>>>>>>>> spectrum is being used) are not in scope as I 
> >> >>>>>>>>>>> understand the earlier discussions, particularly the 
> >> >>>>>>>>>>> chartering discussions.
> >> >>>>>>>>>>>
> >> >>>>>>>>>>> Yours, Joel
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>>> As I understand, the information you are asking for 
> >> >>>>>>>>>>>>> is explicitly out of scope for the working group. 
> >> >>>>>>>>>>>>> Yours, Joel
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>>> use) that would inform the operation of a kill 
> >> >>>>>>>>>>>>>> switch capability. I suggest this deficiency can be 
> >> >>>>>>>>>>>>>> remedied with the following changes:
> >> >>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>> O.13bis:  According to local regulatory policy, 
> >> >>>>>>>>>>>>>> after connecting to a master device's radio network 
> >> >>>>>>>>>>>>>> a slave device MAY inform the master device of the 
> >> >>>>>>>>>>>>>> actual channel usage. The slave MUST include 
> >> >>>>>>>>>>>>>> parameters required by local regulatory policy, e.g. 
> >> >>>>>>>>>>>>>> device ID, manufacturer's serial number, channel 
> >> >>>>>>>>>>>>>> of the channel and power level it has chosen, and 
> >> >>>>>>>>>>>>>> the master/AP relays this information to the database.
> >> >>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>> - end of new text -
> >> >>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>> within the UHF TV band, a master WSD must 
> >> >>>>>>>>>>>>>> 3.18.1 The lower and upper frequency boundaries^13 
> >> >>>>>>>>>>>>>> of the in-block emissions of the master WSD, and 
> >> >>>>>>>>>>>>>> those of the in-block emissions of its associated 
> >> >>>>>>>>>>>>>> slaves. A lower frequency will be specified as (470 
> >> >>>>>>>>>>>>>> + 8k +
> >> >>>>>>>>>>>>>> collect more granular information with regards to 
> >> >>>>>>>>>>>>>> the usage of the frequency resource by narrowband 
> >> >>>>>>>>>>>>>> WSD technologies. The upper and lower frequencies of 
> >> >>>>>>>>>>>>>> a boundary pair do not straddle a DTT channel boundary.
> >> >>>>>>>>>>>>>> context of 3.18, that the reported information on 
> >> >>>>>>>>>>>>>> the DTT channels and EIRP spectral densities 
> >> >>>>>>>>>>>>>> actually used by the master and slave WSDs were 
> >> >>>>>>>>>>>>>> 18 This forms part of a handshake protocol and may 
> >> >>>>>>>>>>>>>> be an area where industry could harmonise without 
> >> >>>>>>>>>>>>>> the need for an explicit requirement in the regulations.
> >> >>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>> Regards
> >> >>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>> Andy
> >> >>>>>>>>>>>>>>

---

From: Paul Lambert <[email-masked]>
Date: Thu, 8 Mar 2012 18:15:20 -0800

>I have a question here. Is it really an acknowledgement or we would like
>to see a kind of notification message that includes channel, and other
>parameters?

What if it's multiple channels?  What happens if the device adapts and changes between modulation technique or bandwidth?  Does every change over the air need to be indicated to the GDB?

This Channel acknowledgement does not seem useful and would limit real world behaviors (like channel and modulation adaptation).

If viewed as a potential regulatory requirement - does this imply we need to parameterize the protocol to have different behaviors in different regions?

Paul

>Siew Yoon Tan
>To: Zuniga, Juan Carlos; [email-masked];
>[email-masked]; [email-masked];
>[email-masked]
>Cc: [email-masked]; [email-masked]; Reza Karimi;
>[email-masked]; [email-masked]
>Regarding Ofcom's requirement to have a return channel as part of the
>protocol between the WSD and WSDB, I would like to confirm to following
>sequence of messaging
>
>Channel request
>Channel response
>Channel acknowledgement
>
>Our view is that it would be beneficial to define the protocol between
>WSD and WSDB that supports this requirement even though how the
>information could be used is still subject to discussion in the UK.
>
>
>Best regards,
>
>Siew Yoon
>
>
>From: [email-masked] [[email-masked]] on behalf of Zuniga,
>Juan Carlos [[email-masked]]
>************************************************************************
>******************************************
>If you have received this email in error please notify the originator of
>the message and delete it from your system.
>
>Any views expressed in this message are those of the individual sender
>and do not represent the views or opinions of Ofcom unless expressly
>stated otherwise.
>************************************************************************
>******************************************

---

From: "Stine, John A." <[email-masked]>
Date: Fri, 9 Mar 2012 13:14:07 +0000

I just read this thread and had to jump in and emphasize the motivation for supporting the modularity of the data structures.  There will be as many data and messaging requirements as there are regulatory domains, device standards, and maybe even database administrators.  If PAWS were to focus on providing a messaging capability rather than specifying which messages must be used in a transaction it will be much easier.  When a device contacts a database it would learn or confirm which regulatory domain it is in, what messaging is required, and what data requirements are necessary.  The basics of a device having to contact a DB and its use being contingent on a list from the DB will be there but the specifics about the negotiation to get that approval and to keep it can be different.  Seeking this sort of loose coupling for PAWS will make this protocol much more versatile over time.

John

---

From: "Zuniga, Juan Carlos" <[email-masked]>
Date: Fri, 9 Mar 2012 09:41:01 -0500

Brian,

The charter does state the following:

"In order to ensure that
it takes into account a broad range of possible use cases and
requirements, the group should also reach out to other potential
"customers" for a white space database access method and consider input
from regulatory entities that are involved in the specification of the
rules for secondary use of spectrum in specific radio bands."

Not taking into account these Ofcom and Industry Canada inputs,
especially at this stage when solutions are not being discussed yet,
would be a mistake.

Besides, I don't see any statement in the charter that the protocol
should be a "two-way handshake" query/response only. This belongs to the
solution part of the work, not to the scope or to the requirements,
which is what we are discussing now.

We are in good time to correct the charter, if need be, and produce a
meaningful protocol to the industry. 

JC

> From: Rosen, Brian [mailto:[email-masked]]
> Sent: Friday, March 09, 2012 9:23 AM
> To: Paul Lambert
> Cc: Das, Subir; Siew Yoon Tan; Zuniga, Juan Carlos;
> [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]; Reza Karimi; [email-masked];
> [email-masked]
> Subject: Re: [paws] WGLC fordraft-ietf-paws-problem-stmt-usecases-
> <as chair>
> We are limited by our charter.  As you can see by the discussion, even
> a minor extension to report channels used in an ack is controversial.
> Adding a whole new transaction would clearly, in my opinion, be beyond
> our charter.  Charter limitations are good, if frustrating.  If we
feel
> we made an error in the original charter, we can ask that it be
> changed, but it's best to try to work within the charter, get that
> done, and then expand the scope of the work.
> 
> Right at the moment, we're trying to accommodate the regulatory
> requirements of the UK within our initial charter.  As such, I would
> like to see the simplest way to do that and stay within the charter.
> Any further work could be considered later when we accomplish our
> initial goals.
> 
> Brian
> 
> On Mar 8, 2012, at 9:15 PM, Paul Lambert wrote:
> 
> >
> >
> >
> >
> >
> > What if it's multiple channels?  What happens if the device adapts
> and changes between modulation technique or bandwidth?  Does every
> change over the air need to be indicated to the GDB?
> >
> > This Channel acknowledgement does not seem useful and would limit
> real world behaviors (like channel and modulation adaptation).
> >
> > If viewed as a potential regulatory requirement - does this imply we
> need to parameterize the protocol to have different behaviors in
> different regions?
> >
> > Paul
> >
> >
> >
> >>
> >> Regards,
> >> _Subir
> >>
Behalf
> One
> >> Having said that, I have no issue sticking to the WSDB terminology.
> I
> >> like keeping things simple :)
> >>
> >> JC
> >>
draft-ietf-paws-problem-stmt-usecases-
> >>>> So, from Gerald and Andy's comments, it seems like from the point
> of
> >>> view
> >>>>> Given that the stated goal of the Ofcom requriement was to be
> able
> >>> to
> >>>>> analyze interference effects, it seems that this will not
> actually
> >>> lead
> >>>>> third messages could be iterated upon to optimize the spectrum
> use.
> >>>>> Knowing
> >>>>>>> 1. Does the device know, when it receives the channel
response,
> >>>>> which
> >>>>> occurs, an instantaneous switch to the next backup channel can
be
> >>>>> 802.22-2011 Standard. This is why I don't believe that PAWS
> should
> >>> get
> >>>>>>>> request&  response in one regulator's domain, PAWS can
support
> >>>>> this. If
> >>>>>>>>>> protocol we've envisioned so far. One example might be
real-
> >>> time
> >>>>>>>>>> because as far as I can see they are outside the scope of
> our
> >>>>> charter.
> >>>>>>>>>>
> >>>>>>>>>>> I agree that it is important to revisit now, so that in
the
> >>>>> future,
> >>>>>>>>>>> it will be easy to align things in their proper place.
> Every
> >>>>> country
> >>>>>>>>>>> the PAWS charter is important.  Maybe some separation
might
> >>>>>>>>>>> protocol based on new information, new ideas, new
> innovation
> >>> new
> >>>>>>>>>>>> This text might have assumed that no further
communication
> >>> or
> >>>>>>>>>>>> the list and then transmit/receive. Perhaps that
> assumption
> >>> was
> >>>>>>>>>>>>> those issues, As long as it's just sending information,
I
> >>>>> don't
> >>>>>>>>>>>>>> the request, an indication of what channels it expects
> to
> >>>>> use,
> >>>>>>>>>>>>>> However, when you say "provide channel usage
> information,
> >>> in
> >>>>>>>>>>>>>> information, what channels it intends to use.  It
> doesn;t
> >>>>> know
> >>>>>>>>>>>>>> what channels it intends to use.  It intends to use
some
> >>>>> number
> >>>>>>>>>>>>>>> There is a similarity here with device ID. In context
> of
> >>>>> PAWS
> >>>>>>>>>>>>>>> we are not concerned with why a device ID is required
> by
> >>> a
***********************************************************************
> *
> >> This email (and any attachments) is confidential and intended for
> the
> >> use of the addressee only.
> >>
***********************************************************************
> *

---

From: Gerald Chouinard <[email-masked]>
Date: Fri, 9 Mar 2012 09:58:46 -0500

Brian,

Agreed.  This acknowledgement should be kept to its simplest form.

My guess is that confirming back to the WSDB the channel(s) that is(are)
being used by the device and the maximum EIRP that will be used (per
channel) should be sufficient for the purpose of interference
considerations. The current trend in modern digital communication is to
increase the efficiency of the modulation used by a system to its maximum.
Intrinsically, this brings the modulated signal close to be noise-like. As a
result, for most cases, an interfering signal is seen by other systems as an
apparent increase in the noise level.  Within certain limits, independent of
the actual modulation used, the interfering signal will be seen as noise
(e.g., C/I becomes C/N). Under this assumption, there is no need to specify
the actual modulation used but rather only the EIRP generated in each
channel.

This has been proven, for example, for the ATSC-DTV signal which will be
affected by any other signals wider than 100 kHz bandwidth as if this was a
noise contribution (CRC: ATSC-DTV subjective tests). Only in the case where
the interfering signal is narrower than 100 kHz and located in the vicinity
of the pilot carrier will the signal be more aggressive than noise. This is
likely to be even more the case for DVB-T where there is not pilot carrier
to be affected. This kind of assessment has most likely been carried out
somewhere in Europe.

Unless a modulation with poor spectrum efficiency is used in White Space,
all these systems should be seen by other systems as noise-like. If one can
assume that all modulation types would need to be approved by local
regulators in their territory, one could think that modulations with poor
spectrum efficiency would be rejected and then, the simple rule of maximum
EIRP per TV channel would be sufficient, leaving the need for only the
acknowledgement message carrying the channel(s) occupied and the maximum
EIRP per channel.

It would be very useful for PAWS that OFCOM clarifies their requirements for
the acknowledgement message in the light of what I described above.

Gerald 

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]] 
Sent: Friday, 09 March, 2012 09:23
To: Paul Lambert
Cc: Das, Subir; Siew Yoon Tan; Zuniga, Juan Carlos;
[email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]; Reza Karimi; [email-masked];
[email-masked]
Subject: Re: [paws] WGLC
fordraft-ietf-paws-problem-stmt-usecases-rqmts-03:channel reporting

<as chair>
We are limited by our charter.  As you can see by the discussion, even a
minor extension to report channels used in an ack is controversial.   Adding
a whole new transaction would clearly, in my opinion, be beyond our charter.
Charter limitations are good, if frustrating.  If we feel we made an error
in the original charter, we can ask that it be changed, but it's best to try
to work within the charter, get that done, and then expand the scope of the
work.

Right at the moment, we're trying to accommodate the regulatory requirements
of the UK within our initial charter.  As such, I would like to see the
simplest way to do that and stay within the charter.  Any further work could
be considered later when we accomplish our initial goals.

Brian

On Mar 8, 2012, at 9:15 PM, Paul Lambert wrote:

> What if it's multiple channels?  What happens if the device adapts and
changes between modulation technique or bandwidth?  Does every change over
the air need to be indicated to the GDB?
>
> This Channel acknowledgement does not seem useful and would limit real
world behaviors (like channel and modulation adaptation).
>
> If viewed as a potential regulatory requirement - does this imply we need
to parameterize the protocol to have different behaviors in different
regions?

---

From: <[email-masked]>
Date: Fri, 9 Mar 2012 11:36:02 +0000

Hi

My reading of the UK regulatory requirements that Ofcom has made available is that the Acknowledgement message that must be communicated back to the database from the white space device is simply the frequency range (or ranges) and maximum eirp density that the device intends to use (a subset of what it would have been offered by the database). I don't believe there is any intent to limit modulation schemes etc. as part of this exchange. This seems a relatively straightforward requirement and the PAWS protocol should accommodate this if it is to be relevant for the UK regulatory environment.

Regards,

Chris

-----Original Message-----
From: Paul Lambert [mailto:[email-masked]]
Sent: 09 March 2012 02:15
To: Das, Subir; 'Siew Yoon Tan'; Zuniga, Juan Carlos; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; Reza Karimi; Dixon,JS,Johnny,COD R; Cheeseman,CJ,Chris,COD R
Subject: RE: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03:channel reporting

>I have a question here. Is it really an acknowledgement or we would
>like to see a kind of notification message that includes channel, and
>other parameters?

Paul

>From: [email-masked] [[email-masked]] on behalf of
>Zuniga, Juan Carlos [[email-masked]]
>I was reusing the language used from Gerald (which I know is familiar
>to people working on IEEE 802 WS groups):
>
>>> should realize that, from the spectrum regulator's point of view,
>>> the second and third messages could be iterated upon to optimize the
>>> spectrum use.
>>> Knowing
>>> systems may use once they know precisely what channels are being
>>> used in the area. The PAWS protocol would carry the information back
>>> and forth but would not be involved in such spectrum use optimization.
>
>> comment about "communicating back to the WSDB/coexistence manager"
>> may result in further misunderstanding. If we simply stick to to WSDB
>> I think we are okay.
>>
>> -Raj
>>
>> >> could use the database in near-real-time to iterate on the two
>> >> last messages to reduce the range of channels that some systems
>> >> may use once they know precisely what channels are being used in the area.
>> >> their geolocation or other reason. Extending this concept to a
>> >> star network topology, the channel that will be selected by this
>> >> network will
>> have
>> >> to
>> >> database and receive the list of available channels (and/or
>> >> maximum EIRP per channel). It is then the responsibility of the
>> >> base station to identify the set of available channels that is
>> >> common for itself and all its slaves to decide on the
>> channel
>> >> that
>> >> >>>>>>>>>>>>> explicitly puts this out of scope. On the other
>> >> >>>>>>>>>>>>> hand, the charter says that the group will "consider
>> >> >>>>>>>>>>>>> input from regulatory entities", and this is one of
>> >> >>>>>>>>>>>>> the requirements from Ofcom that they have just
>published.
>> >> >>>>>>>>>>>>> The protocol will be worthless for the UK if it
>> >> >>>>>>>>>>>>> omits some requirements.
>> >> >>>>>>>>>>>>>
>> >> >>>>>>>>>>>>> Regards
>> >> >>>>>>>>>>>>>
>> >> >>>>>>>>>>>>> Andy
>> >> >>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>> The channel usage message MUST include parameters
>> >> >>>>>>>>>>>>>> as required by local regulatory requirement.  These
>> >> >>>>>>>>>>>>>> message from the master device to the database.
>> >> >>>>>>>>>>>>>> The channel usage message MUST include parameters
>> >> >>>>>>>>>>>>>> as required by local regulatory requirement for the
>> >> >>>>>>>>>>>>>> MAY include device ID, manufacturer's serial
>> >> >>>>>>>>>>>>>> number, channel usage and power level information.
>> >> >>>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>> by local regulation, the slave informs the
>> >> >>>>>>>>>>>>>> master/AP of the channel and power level it has
>> >> >>>>>>>>>>>>>> chosen, and the master/AP relays this information
>> >> >>>>>>>>>>>>>> to the
>database.
>> >> >>>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>> - end of new text -
>> >> >>>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>> relation to the maximum permitted EIRPs over the
>> >> >>>>>>>>>>>>>> DTT channels, and prior to initiating transmissions
>> >> >>>>>>>>>>>>>> WSD technologies. The upper and lower frequencies
>> >> >>>>>>>>>>>>>> of a boundary pair do not straddle a DTT channel
>boundary.
>> >> >>>>>>>>>>>>>> information from a WSDB to a master WSD is
>> >> >>>>>>>>>>>>>> optional, master WSDs must be able to receive and
>> >> >>>>>>>>>>>>>> interpret these.
>> >> >>>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>> Footnote 18 states:
>> >> >>>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>> 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
>> >> >>>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>>
>> >> >
>If you have received this email in error please notify the originator
>of the message and delete it from your system.
>

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 9 Mar 2012 09:23:15 -0500

<as chair>
We are limited by our charter.  As you can see by the discussion, even a minor extension to report channels used in an ack is controversial.   Adding a whole new transaction would clearly, in my opinion, be beyond our charter.  Charter limitations are good, if frustrating.  If we feel we made an error in the original charter, we can ask that it be changed, but it's best to try to work within the charter, get that done, and then expand the scope of the work.

Right at the moment, we're trying to accommodate the regulatory requirements of the UK within our initial charter.  As such, I would like to see the simplest way to do that and stay within the charter.  Any further work could be considered later when we accomplish our initial goals.

Brian

---

From: Pete Resnick <[email-masked]>
Date: Fri, 9 Mar 2012 09:56:49 -0600

> channel) should be sufficient for the purpose of interference

Folks,

Fair warning as your incoming AD, but also as a current AD who thought 
he understood what work this group was chartered to do:

The group is chartered to do (1) database discovery, (2) database 
access, (3) data formats for that database access, and (4) security for 
that database access. The charter also describes what that database 
access is like: (a) provide geolocation and other info to query the 
database, and (b) receive the whitespace that can be used.

Insofar as what this charter only allows for protocol that is about 
database discovery and database access, the so-called "acknowledgment" 
you all are talking is either writing back to the database (if the 
"acknowledgment" data gets saved into the same database) or is 
non-database-access protocol to talk to a third party. In either case, 
I, as an AD, would be extremely surprised to find out either that the 
database was writeable by the client (that was not my understanding of 
the query described in the "rough outline of the protocol" section of 
the charter) or that there was to be additional protocol that sent data 
from the client to a third party. There is a whole new set of 
considerations on such protocol (e.g., Does the information sent back 
from the client need TTL values? Is there a renewal process on the data 
after some time? What if there are multiple clients accessing at the 
same time and they choose the same value? Can the response get back an 
error and the client has to choose something different?).

If you wish to take on this work, you need to go back to the IESG and 
re-charter. That's fine: If the WG feels that this piece of protocol is 
required in order to make the rest of the protocol at all useful, now is 
the time to tell the IESG that and figure out how to write it into the 
charter. But doing this work without a charter change is going to cause 
heartache later.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 09 Mar 2012 10:59:51 -0500

I am having trouble connecting the goal of the requirement, the expected 
protocol behavior, and the expected real-world operation.

Lets keep it simple.  A master, connected by wired internet to the 
World.  A set of slaves who want to use whitespace to talk to the 
master.  All within a small physical space.  All within the the time 
limit of whatever answer the master gets from the database.

The Ofcom requirement is described as being important for understanding 
interference effects.  Therefore, presumably, it needs to relate to 
actual spectrum usage.

The stated protocol behavior is that the master would reply to the 
shitespace database with an ack indicating what it expects to use, at 
what power level.
The way folks are writing this, I believe the intention is "respond once".

As I understand such master / slave behavior (and I am by no means a 
radio expert), the actual usage of spectrum, within the whitespace band, 
will depend upon how many slaves are active, and possibly on what they 
are doing.

If the actual usage is going to depend upon the slave device population 
/ behavior, then the only answer the master can correctly provide is "I 
will use all of the whitespace you have identified, with the highest 
power I might use.

Such an answer is a valid answer in terms of protocol and in terms of 
the stated regulatory requirements.  However, it is utterly useless in 
terms of the stated goal.
As an engineer, I am very uncomfortable designing a protocol messaging 
exchange which I know will not meet the end-users needs.

Note1: If I have mischaracterized ro misunderstood what folks ahve 
explained, I apologize.

Note2: If instead the intention is for the master to update the database 
every time it changes the spectrum usage pattern, then this is NOT an 
acknowledgment of the reply from the database.  It is a dynamic behavior 
reporting requirement.

Yours,
Joel

---

From: Andrew Gowans <[email-masked]>
Date: Fri, 9 Mar 2012 16:03:58 +0000

All I agree with Chris, the aim of the return information is to collect the max power levels and channels/frequency ranges that the master and its associated slaves are using. This information in con-junction with the other information collected (e.g. technology ID) may be used to estimate the interference potential to the incumbent services in any given area.  There is no intention here to have the device indicate to the WSDB its configuration at any given instant.

Regards

Andy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 09 March 2012 11:36
To: [email-masked]; [email-masked]; Siew Yoon Tan; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; Reza Karimi; [email-masked]
Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03:channel reporting

Hi

Regards,

Chris

-----Original Message-----
From: Paul Lambert [mailto:[email-masked]]
Sent: 09 March 2012 02:15
To: Das, Subir; 'Siew Yoon Tan'; Zuniga, Juan Carlos; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; Reza Karimi; Dixon,JS,Johnny,COD R; Cheeseman,CJ,Chris,COD R
Subject: RE: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03:channel reporting

Paul

---

From: <[email-masked]>
Date: Fri, 9 Mar 2012 16:14:56 +0000

This mail thread has a dozen recipients in the To: and CC: fields and the ietf mail system is complaining about that, requiring me to manually authorize each and every email.
May I ask you all to refrain from using the 'reply-all' button when replying to these emails, and send your reply simply to [email-masked]'?

Thanks, Gabor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Andrew Gowans
Sent: Friday, March 09, 2012 8:04 AM
To: [email-masked]; [email-masked]; [email-masked]; Siew Yoon Tan; [email-masked]; Patil Basavaraj (Nokia-CIC/Dallas); [email-masked]; [email-masked]; Probasco Scott (Nokia-CIC/Dallas)
Cc: [email-masked]; [email-masked]; Reza Karimi; [email-masked]
Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03:channel reporting

Regards

Andy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 09 March 2012 11:36
To: [email-masked]; [email-masked]; Siew Yoon Tan; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; Reza Karimi; [email-masked]
Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03:channel reporting

Hi

Regards,

Chris

-----Original Message-----
From: Paul Lambert [mailto:[email-masked]]
Sent: 09 March 2012 02:15
To: Das, Subir; 'Siew Yoon Tan'; Zuniga, Juan Carlos; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; Reza Karimi; Dixon,JS,Johnny,COD R; Cheeseman,CJ,Chris,COD R
Subject: RE: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03:channel reporting

Paul

---

From: <[email-masked]>
Date: Sat, 10 Mar 2012 07:44:24 +0000

When we started this paws effort not that long ago, the whole purpose was to define a protocol which can help devices make use of white spaces, according to rules set by the regulators. The charter we came up with covered the regulatory requirements available at the time of writing, and we did not anticipate requirements like the one Ofcom came up with recently. That is why we do not have, as Pete pointed out, explicitly listed an item for the client devices to report back anything to the server. We do have, however, the following sentence in the charter: 
" In order to ensure that the WG takes into account a broad range of possible use cases and
requirements, the group should also reach out to other potential
"customers" for a white space database access method and consider input
from regulatory entities that are involved in the specification of the rules "
It just does not say how the inputs from regulatory entities are to be considered ...

I would put aside the solution proposals on whether the client should use an acknowledgement message or a separate transaction for reporting back, what exactly to report, etc, and consider for the time being that we have a requirements document and this whole thread started with Andy proposing new requirements the be added there to meet Ofcom requirements.

I see the following possibilities:
1. ignore the Ofcom requirements on channel reporting back to the db. I believe, if we choose this path, then the protocol we'll design will not meet the original goals, and we may just as well go home and play soccer instead
2. try to fit the Ofcom requirements into the charter. One could argue this is possible, as the Ofcom requirements do not specify what the db is supposed to do with that data, we could consider it is just for informational purposes. We've seen both pro and con opinions on this on the list, so we could continue to argue. But since both the outgoing and incoming AD thinks this is not the way to go, I do not see much hope we can succeed on this path.
3. go back to iesg and modify the charter to include the channel reporting back to the db aspect. If we do this, we can then include the relevant requirements into the reqs draft, issue a new wglc and start the work on the protocol itself. I see this the fastest and least controversial (at least from the ADs pow) path.

So what do folks, who believe they know the ietf process well enough, prefer? I am just trying to get the wg out of this deadlock situation, so please be constructive.

- Gabor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Pete Resnick
Sent: Friday, March 09, 2012 7:57 AM
To: Gerald Chouinard
Cc: [email-masked]
Subject: Re: [paws] WGLC fordraft-ietf-paws-problem-stmt-usecases-rqmts-03:channel reporting

Folks,

Fair warning as your incoming AD, but also as a current AD who thought he understood what work this group was chartered to do:

The group is chartered to do (1) database discovery, (2) database access, (3) data formats for that database access, and (4) security for that database access. The charter also describes what that database access is like: (a) provide geolocation and other info to query the database, and (b) receive the whitespace that can be used.

Insofar as what this charter only allows for protocol that is about database discovery and database access, the so-called "acknowledgment" 
you all are talking is either writing back to the database (if the "acknowledgment" data gets saved into the same database) or is non-database-access protocol to talk to a third party. In either case, I, as an AD, would be extremely surprised to find out either that the database was writeable by the client (that was not my understanding of the query described in the "rough outline of the protocol" section of the charter) or that there was to be additional protocol that sent data from the client to a third party. There is a whole new set of considerations on such protocol (e.g., Does the information sent back from the client need TTL values? Is there a renewal process on the data after some time? What if there are multiple clients accessing at the same time and they choose the same value? Can the response get back an error and the client has to choose something different?).

If you wish to take on this work, you need to go back to the IESG and re-charter. That's fine: If the WG feels that this piece of protocol is required in order to make the rest of the protocol at all useful, now is the time to tell the IESG that and figure out how to write it into the charter. But doing this work without a charter change is going to cause heartache later.

pr

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 10 Mar 2012 10:36:01 -0500

I don't know which path I would prefer.

But, given the charter, and the discussion around the charter for the 
need for focus in the working group, I believe that if the working group 
wants to work on something akin to the stated ofcom usage reporting 
requirement then it needs to
1) ask the IESG if that is acceptable
2) if the IESG agrees in principle, then work with the IESG on a 
revision to the charter.

Yours,
Joel

---

From: <[email-masked]>
Date: Mon, 12 Mar 2012 18:16:15 +0000

Hi Gabor,

The WG charter has been defined with a very narrow focus in order to
ensure that a protocol solution for use between white space devices and
database(s) can be delivered within a reasonable timeframe.
However at the time of the chartering, we did not have ofcom requirements
and hence the scope was limited to a request/response protocol for the
device-2-database interface.
Now that we do have a better view of Ofcom requirements, it would be
shortsighted to not consider those.
I believe that the scope of the extension to the protocol that is being
discussed is not significant enough to cause a major rethink of the
charter or the protocol.
Hence I would be in favor of option 3.
The IETF process allows working groups to recharter at any time. I believe
there is enough reason for a minimal extension of the charter scope to
accommodate the Ofcom requirement.

-Raj

On 3/10/12 1:44 AM, "ext [email-masked]" <[email-masked]>
wrote:

>When we started this paws effort not that long ago, the whole purpose was
>to define a protocol which can help devices make use of white spaces,
>according to rules set by the regulators. The charter we came up with
>covered the regulatory requirements available at the time of writing, and
>we did not anticipate requirements like the one Ofcom came up with
>recently. That is why we do not have, as Pete pointed out, explicitly
>listed an item for the client devices to report back anything to the
>server. We do have, however, the following sentence in the charter:
>rules "
>I would put aside the solution proposals on whether the client should use
>an acknowledgement message or a separate transaction for reporting back,
>what exactly to report, etc, and consider for the time being that we have
>a requirements document and this whole thread started with Andy proposing
>new requirements the be added there to meet Ofcom requirements.
>
>1. ignore the Ofcom requirements on channel reporting back to the db. I
>believe, if we choose this path, then the protocol we'll design will not
>meet the original goals, and we may just as well go home and play soccer
>instead
>2. try to fit the Ofcom requirements into the charter. One could argue
>this is possible, as the Ofcom requirements do not specify what the db is
>supposed to do with that data, we could consider it is just for
>informational purposes. We've seen both pro and con opinions on this on
>the list, so we could continue to argue. But since both the outgoing and
>incoming AD thinks this is not the way to go, I do not see much hope we
>can succeed on this path.
>3. go back to iesg and modify the charter to include the channel
>reporting back to the db aspect. If we do this, we can then include the
>relevant requirements into the reqs draft, issue a new wglc and start the
>work on the protocol itself. I see this the fastest and least
>controversial (at least from the ADs pow) path.
>
>So what do folks, who believe they know the ietf process well enough,
>prefer? I am just trying to get the wg out of this deadlock situation, so
>please be constructive.
>
>- Gabor
>
>
>
>ext Pete Resnick
>Fair warning as your incoming AD, but also as a current AD who thought he
>understood what work this group was chartered to do:
>
>The group is chartered to do (1) database discovery, (2) database access,
>(3) data formats for that database access, and (4) security for that
>database access. The charter also describes what that database access is
>like: (a) provide geolocation and other info to query the database, and
>(b) receive the whitespace that can be used.
>
>non-database-access protocol to talk to a third party. In either case, I,
>as an AD, would be extremely surprised to find out either that the
>the query described in the "rough outline of the protocol" section of the
>charter) or that there was to be additional protocol that sent data from
>the client to a third party. There is a whole new set of considerations
>on such protocol (e.g., Does the information sent back from the client
>need TTL values? Is there a renewal process on the data after some time?
>What if there are multiple clients accessing at the same time and they
>choose the same value? Can the response get back an error and the client
>has to choose something different?).
>

---

From: Paul Lambert <[email-masked]>
Date: Fri, 9 Mar 2012 15:58:54 -0800

+1 to all of Joels comments

Why would a third ack message ever be different from the original request?

There's been no time to connect clients or make any other interesting choices that would change the way the spectrum would be used.  The ack is a useless message and any such informative information about the capabilities or plans of a device to use a range of spectrum should have been carried in the first message.

Paul

>Sent: Friday, March 09, 2012 8:00 AM
>To: [email-masked]
>Cc: Paul Lambert; [email-masked]; [email-masked];
>[email-masked]; [email-masked];
>[email-masked]; [email-masked]; [email-masked];
>[email-masked]; [email-masked]; [email-masked]
>> My reading of the UK regulatory requirements that Ofcom has made
>available is that the Acknowledgement message that must be communicated
>back to the database from the white space device is simply the frequency
>range (or ranges) and maximum eirp density that the device intends to
>use (a subset of what it would have been offered by the database). I
>don't believe there is any intent to limit modulation schemes etc. as
>part of this exchange. This seems a relatively straightforward
>requirement and the PAWS protocol should accommodate this if it is to be
>relevant for the UK regulatory environment.
>>
>> Regards,
>>
>> Chris
>>
>> To: Das, Subir; 'Siew Yoon Tan'; Zuniga, Juan Carlos;
>Dixon,JS,Johnny,COD R; Cheeseman,CJ,Chris,COD R
>changes between modulation technique or bandwidth?  Does every change
>over the air need to be indicated to the GDB?
>>

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 19 Mar 2012 11:17:02 -0400

<as individual>
Remembering that so far, it appears this discussion is out of scope:

While it may be the case that devices dynamically change their choice of what "channels" they will use between queries of the database, it's at least equally likely that it will get the list of available channels, choose one, and stick to it.  If they wanted to change at some point, it seems very feasible to query the database again, since the available spectrum may have changed.

The device can't tell the database what it's going to use before it knows what is available.

The "ack" sequence would be:
Device to DB: What could I use at location x,y?
DB to Device: You could use channels 3, 11 or 15
Device to DB: Okay, I'll use channel 11

Brian

---

From: Teco Boot <[email-masked]>
Date: Mon, 19 Mar 2012 17:04:34 +0100

I don't prefer any delay in getting out a first release of a PAWS protocol. We already know the protocol must be extendable and new requirements from regulators will be on the horizon. So I suggest to continue with our work, based on current charter. Meanwhile, we can discuss extensions.

On 1: I don't play soccer. Let's continue fulfilling our current task.
On 2: We can work on new documents for additional requirements and protocol extensions. No WG adoption yet.
On 3: Let's do this in parallel. When having candidate documents and a new charter, it shouldn't take much time to get this published.

Thanks, Teco

---

From: Nancy Bravin <[email-masked]>
Date: Mon, 19 Mar 2012 09:35:10 -0700

I will of course go along with the consensus, however, there is one advantage in going back to the IESG now, because the "sentence" allows for additional
Regulatory changes/input it should be a quick decision since Ofcom is probably the most advanced in implementing a DB(s) and WSD's.

The FCC is probably going to have changes but more slowly, Industry Canada also implementing regulations.

If one looks at the Ofcom model of licensed, only 4 TV stations, one could assume that what they are doing may be similar to other countries
that may have a similar model, or those that have State run TV with limited channels.  If we do not are we making ourselves irrelevant to Ofcom now…and will have to play catch up
not only with what is already known now, but what will be changing in the future? 
The next round will assumably start on more detailed work…why not clear that path now? And once cleared we can do both…in parallel?

Sincerely, Nancy

---

From: Paul Lambert <[email-masked]>
Date: Mon, 19 Mar 2012 11:58:41 -0700

>Sent: Monday, March 19, 2012 8:17 AM
>To: Paul Lambert
>Cc: Joel M. Halpern; [email-masked]; [email-masked];
>[email-masked]; [email-masked]; [email-masked]
>While it may be the case that devices dynamically change their choice of
>what "channels" they will use between queries of the database, it's at
>least equally likely that it will get the list of available channels,
>choose one, and stick to it.  If they wanted to change at some point, it
>seems very feasible to query the database again, since the available
>spectrum may have changed.
>

But the "ack" in this sequence occurs right after the "you could use" message.  Any intelligent AP/Master might some time to evaluate each channel and pick one later that has the lowest utilization.  It would not have this knowledge in time for an "ack".  If it picked a channel for the ack, it would likely change soon to another channel.

Given that the "ack" has only informative information that will change - there is nothing useful that can be done by the DB with this information.  Unless the Master provides continuous updates of channel utilization - there is no reason to have this information carried in an ack.

We should not create extra messages to carry information that will not be used in any processing.

Paul

>> There's been no time to connect clients or make any other interesting
>choices that would change the way the spectrum would be used.  The ack
>is a useless message and any such informative information about the
>capabilities or plans of a device to use a range of spectrum should have
>been carried in the first message.
>>
>>
>> Paul
>>
>real
>>>>>>>>>>>>>>>> <as individual, at least for now>   I'd also suggest
>that
>>>>>> our
>>>>>>>>>>>>>>>>>>>>>> http://www.ietf.org/internet-drafts/draft-ietf-
>paws
>>>>>>>>>>>>>>>>>>>>>> -
>>>>>>>> problem-
>>>>>>>>>>>>> stmt-u
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>> seca
>>>>>>>>>>>>>>>>>>>>>> ses-rqmts-03.txt
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 19 Mar 2012 16:08:12 -0400

<as individual>
Depends on the time period allowed for the ack.

The device won't start another transaction with the database before it decides.

The db doesn't have anything except a bit of state to keep if the ack takes a while.  So, let it take a while.

Eventually, it would decide it wasn't going to get an answer and treat it like an error (timeout).

While we have to deal with charter issues, I don't like producing a protocol spec that only works with the US rules.  Tracking usage is not an unreasonable regulatory requirement, and not a complicated protocol mechanism.  It only gets complicated when the spectrum returned from any query depends on the usage information.  That's somewhere I don't want to go yet.

<as chair>
Let's assume, at least for now, that this subject is out of scope.  We'll have a discussion of what to do in Paris, and bring that back to the list.  Let's move forward on the document without this capability, and we'll pick it up later if/when we get the charter issue settled.
That means I would like to stop discussion until Paris, and then we will continue it on the list.

Brian

---

From: Paul Lambert <[email-masked]>
Date: Mon, 19 Mar 2012 13:26:15 -0700

If we are supporting multiple regulatory domains that have different protocol requirements and state change behaviors we need to define some parameterization of regulatory requirements - like "USE_TRACKING", which if true would generate a message to the DB on each change of the Masters channel/power/modulation settings.  This is NOT the same as an ACK.  In FCC regions, this parameter would be FALSE and there would be no additional messages indicating usage.

Seems like USE_TRACKING would be a simple extension to a more basic protocol state machine and so could be layered in later or sooner depending on the charter.

Paul

>Sent: Monday, March 19, 2012 1:08 PM
>To: Paul Lambert
>While we have to deal with charter issues, I don't like producing a
>protocol spec that only works with the US rules.  Tracking usage is not
>an unreasonable regulatory requirement, and not a complicated protocol
>mechanism.  It only gets complicated when the spectrum returned from any
>query depends on the usage information.  That's somewhere I don't want
>to go yet.
>
><as chair>
>Let's assume, at least for now, that this subject is out of scope.
>We'll have a discussion of what to do in Paris, and bring that back to
>the list.  Let's move forward on the document without this capability,
>and we'll pick it up later if/when we get the charter issue settled.
>> But the "ack" in this sequence occurs right after the "you could use"
>message.  Any intelligent AP/Master might some time to evaluate each
>channel and pick one later that has the lowest utilization.  It would
>not have this knowledge in time for an "ack".  If it picked a channel
>for the ack, it would likely change soon to another channel.
>>
>> Given that the "ack" has only informative information that will change
>- there is nothing useful that can be done by the DB with this
>information.  Unless the Master provides continuous updates of channel
>utilization - there is no reason to have this information carried in an
>ack.
>>
>>>>> / behavior, then the only answer the master can correctly provide
>is
>>> "I
>>>>> requirement and the PAWS protocol should accommodate this if it is
>to
>>> be
>>>>>> Subject: RE: [paws] WGLC for draft-ietf-paws-problem-stmt-
>usecases-
>>>>>>>>> the second and third messages could be iterated upon to
>optimize
>>>>> the
>>>>>>>>> spectrum use.
>>>>>>>>> Knowing
>>>>>>>>> The actual messages/IEs that would carry this information
>should
>>> be
>>>>>>>>>> to them getting what they want, even if it does comply with
>the
>>>>>>>>>> regulations.
>>>>>>>>>> may use once they know precisely what channels are being used
>in
>>>>> the area.
>>>>>>>>>>> On 3/8/12 11:39 AM, "ext Peter Saint-
>Andre"<[email-masked]>
>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>> available channels that is common to both devices. Remember
>that
>>>>>>>> some
>>>>>>>>>> I a more sophisticated operation, the master device may add
>one
>>> or
>>>>>>>>>> transparent to the user. It is the scheme that has been
>included
>>>>>>>>>> in
>>>>>>>> the
>>>>>>>>>> IEEE
>>>>>>>>>>> Scott->My interpretation of section 3.18 is that the device
>can
>>>>>>>> only
>>>>>>>>>> these channels belong to the set of available channel.
>However,
>>> if
>>>>>>>>>>>>> order to operate a whitespace radio in the UK. I believe
>the
>>>>>>>> scope
>>>>>>>>>> of
>>>>>>>>>>>>> the
>>>>>>>>>>>>>> rules for secondary use of spectrum in specific radio
>bands.
>>> "
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Regarding whether the types of requirements belong to #1
>or
>>>>>>>>>>>>>> #2,
>>>>>>>> I
>>>>>>>>>>>>>> believe
>>>>>>>>>>>>>> If we know it today, I see no reason why we should not
>work
>>>>>>>>>>>>>> on
>>>>>>>> it
>>>>>>>>>> in
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> first phase of the work.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Juan Carlos
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> From: [email-masked] [mailto:paws-
>[email-masked]]
>>>>>>>>>>>>>>> On
>>>>>>>>>> Behalf
>>>>>>>>>>>>>>> Of
>>>>>>>>>>>>>>> Peter Saint-Andre
>>>>>>>>>>>>>>>> slim line and every 6 months decide what to incorporate
>in
>>>>>>>> the
>>>>>>>>>>>>>>>>> goes beyond what the charter defined as the scope of
>this
>>>>>>>>>> working
>>>>>>>>>>>>>>>>> group, which was to enable a device to discover the
>white
>>>>>>>> space
>>>>>>>>>>>>>>>>> the job of the charter to mention explicitly that each
>of
>>>>>>>> those
>>>>>>>>>>>>>>>>>>> Indeed, the regulator has not described the process
>or
>>>>>>>>>> provided
>>>>>>>>>>>>>>>>>>> provide for their intent. To answer your question,
>the
>>>>>>>>>> channels
>>>>>>>>>>>>>>>>>>> as they associate, the master will need to gather
>their
>>>>>>>>>> details
>>>>>>>>>>>>>>>>>>> Sent: 06 March 2012 17:05 To:
>[email-masked]
>>>>>>> Cc:
>>>>>>>>>>>>>>>>>>> are being used, and at what power levels.  That is
>what
>>>>>>>> would
>>>>>>>>>>>>>>>>>>> I do see a technical difficulty with having the
>master
>>>>>>>>>> provide,
>>>>>>>>>>>>>>>>>>>> include it to the protocol. Ofcom identifies in
>3.18&
>>>>>>>> 3.19
>>>>>>>>>>>>>>>>>>>> that channel usage information is required and thus
>we
>>>>>>>> need
>>>>>>>>>>>>>>>>>>>>>>>> atory-requirements-for-white-space-devices-in-
>the-
>>>>>>>> UHF-
>>>>>>>>>> TV-
>>>>>>>>>>>>>>> band,
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> New P requirements (probably best placed
>following
>>>>>>>>>>>>>>>>>>>>>>>> P.12):
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> P.12qua: The protocol MUST support a channel
>usage
>>>>>>>>>>>>>>>>>>>>>>>> message acknowledgement.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> New O requirements (probably best placed
>following
>>>>>>>>>>>>>>>>>>>>>>>> O13):
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> specified as (470 + 8k + 0.2m) MHz, where 0 3?4
>k
>>>>>>> 3?4
>>>>>>>>>>>>>>>>>>>>>>>> non-contiguous, whole DTT channels or fractions
>of
>>>>>>>>>>>>>>>>>>>>>>>> DTT channels.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Therefore, I'd like to initiate a WG Last Call
>for
>>>>>>>>>>>>>>>>>>>>>>>> comments on
>>>>>>>>>>>>>>>>>>>>>>>> Please review the draft and send your comments
>to
>>>>>>>>>>>>>>>>>>>>>>>> the list by March 20th, 2012.
>>>>>>>>>>>>>>>>>>>>>>>>

---

From: Teco Boot <[email-masked]>
Date: Mon, 19 Mar 2012 17:17:22 +0100

> Device to DB: Okay, I'll use channel 11

What to do when switched to another channel?

I can think of another extension:
  Device to DB: By the way, channel 15 is heavily used here.
Again, lifetime of his info would be limited.

Teco

---

From: Gerald Chouinard <[email-masked]>
Date: Tue, 20 Mar 2012 09:52:23 -0400

Brian,

What you may want to consider during the face-to-face meeting is to form an
ad-hoc group that would develop a paper describing the implications of such
third message back to the database to be sent to OFCOM. Although useful for
the purpose of tracking the use of the spectrum, OFCOM may not have
thoroughly analyzed the implications of such a requirement.  The views from
the protocol experts present in PAWS would very likely be appreciated in
identifying the pros and cons of such an approach and would be useful in
verifying its feasibility. A possible consequence of such analysis may be a
precise description of this requirement with a more specific scope developed
by OFCOM so that it is genuinely feasible, practical and useful.

Gerald

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Rosen, Brian
Sent: Monday, 19 March, 2012 16:08
To: Paul Lambert
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: Re: [paws] WGLC for
draft-ietf-paws-problem-stmt-usecases-rqmts-03:channel reporting

<as individual>

The device won't start another transaction with the database before it
decides.

The db doesn't have anything except a bit of state to keep if the ack takes
a while.  So, let it take a while.

Eventually, it would decide it wasn't going to get an answer and treat it
like an error (timeout).

While we have to deal with charter issues, I don't like producing a protocol
spec that only works with the US rules.  Tracking usage is not an
unreasonable regulatory requirement, and not a complicated protocol
mechanism.  It only gets complicated when the spectrum returned from any
query depends on the usage information.  That's somewhere I don't want to go
yet.

<as chair>
Let's assume, at least for now, that this subject is out of scope.  We'll
have a discussion of what to do in Paris, and bring that back to the list.
Let's move forward on the document without this capability, and we'll pick
it up later if/when we get the charter issue settled.
That means I would like to stop discussion until Paris, and then we will
continue it on the list.

Brian

> But the "ack" in this sequence occurs right after the "you could use"
message.  Any intelligent AP/Master might some time to evaluate each channel
and pick one later that has the lowest utilization.  It would not have this
knowledge in time for an "ack".  If it picked a channel for the ack, it
would likely change soon to another channel.
>
> Given that the "ack" has only informative information that will change -
there is nothing useful that can be done by the DB with this information.
Unless the Master provides continuous updates of channel utilization - there
is no reason to have this information carried in an ack.