Hi Pete,
I believe you are reading too much into my explanation. I was merely trying
to identify whether the response back to the database will include the
actual channel being used at the time of the response or the channel that is
anticipated to be used later. This is only a question of relative timing.
Furthermore, the regulators will likely prefer getting information on the
channels that are actually being used rather than the channels that are
anticipated to be used, in other words, those that are used rather than
those that may eventually be used. In practice, if one can equate the
"anticipated usage" to the "actual usage", then there is no problem.
Gerald
-----Original Message-----
From: Pete Resnick [mailto:[email protected]]
Sent: Friday, 20 April, 2012 18:02
To: Gerald Chouinard
Cc: [email protected]
Subject: Re: [paws] charter update
Hi Gerald,
On 4/19/12 10:01 PM, Gerald Chouinard wrote:
The "anticipated usage" describes the response that the WSD will make in a
transitional state when it initiates its operation after having queried
the
database.
Actually, no. The "anticipated usage" (or, again, perhaps "intended
usage") describes the response that the radio device will make
*whenever* it queries the database. Whether it does this as a
transitional state when it initiates its operation or at a later time in
order to refresh is completely an implementation detail. As far as the
protocol is concerned, the response is about which of frequencies it
intends to use given what the WSD has reported.
However, since the regulatory bodies in different countries will require
that the WSD queries the database on a regular basis (e.g., within 24
hours
in the USA), the question is whether the WSD will need to send its
spectrum
occupation after every query, even if it has not changed (i.e., the
behavior
in a steady-state).
No, this is absolutely irrelevant. This is outside of the protocol
operation and is strictly about the semantics of the use of the
protocol. It does not effect what the protocol will require.
If this is not needed, then the term "anticipated usage"
would be appropriate since the WSD would only respond when it changes its
spectrum occupation (however, see paragraph below). If a confirmation is
needed every time, then in most of the cases, the WSD would report its
current spectrum usage and only when it happens to change its usage would
it
nee to report its "anticipated usage". if it has not already re-tuned to
the
new allowed channel before it sends its report to the database.
The server cannot tell the difference between "I have queried to
refresh; I've been using this WS and intend to continue to do so" versus
"I had stopped using this WS some time ago and I am making a new request
for WS; here's what I intend to use now" versus "I am requesting WS for
the first time; here is what I intend to use". It is protocol-irrelevant
which case is being used.
My guess is that since it will need to free the channel that it was
operating on and that is no longer available as soon as possible to avoid
interference, it will likely re-tune right away and not wait for the
report
to be sent to the database over the internet before re-tuning (my guess is
this would be done over TCP with proper transmission confirmation rather
than UDP). In such case, it would then report on its "actual usage" rather
than the "anticipated usage".
As you can see, this depends on what is being assumed as the process
taking
place at the WSD when it queries the database. Once this is clearly
understood, it will be to the group to decide.
I simply disagree with your assessment.
If the group thinks that you will (potentially) need to work on a
separate protocol piece for notifications of current usage, I think you
should add that to the proposed charter changes. But I don't see a need
for that protocol requirement. It seems to me that all of the
functionality can be satisfied with a response after receiving the list
of WS indicating intended usage.
pr
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of
Pete
Resnick
Sent: Tuesday, 17 April, 2012 09:43
To: [email protected]
Cc: [email protected]
Subject: Re: [paws] charter update
Folks,
1. As was said by others, "anticipated" is correct. The change in the
charter was not to include a constant dynamic update to the database of
what the device is currently using, but a one-time immediate report of
what the device intends to use. If you prefer "intended" to
"anticipated", that is also fine, but we have *not* discussed the
possibility of writing the protocol to have an update mechanism to
inform the database of the current actual usage. If that's needed, we
should further discuss.
2. I should repeat the admonition I made at the meeting in Paris: We are
*not* writing regulatory requirements into the protocol. We are writing
the protocol to have enough flexibility to satisfy regulatory
requirements. I am quite sure if we asked Ofcom whether they wanted
"anticipated usage" or "actual usage" in the protocol, they'd say
"actual usage", but that is entirely the wrong question to be asking and
we'd be getting a bogus answer. If the regulatory requirement we are
trying to make sure we are able to cover is "a single report by the
device of which spectrum it will be using", then "anticipated" is our
design requirement. Regulators (like end users in general) are not
protocol designers and the language they use for requirements should not
be used in our charter or protocol documents. We need to interpret what
their high-level requirements mean for our protocol and use language
within our documents (including our charter) that makes sense for a
protocol.
So, my question to the list:
Does anybody think we need to have the device constantly report back to
the database about its current usage?
If I don't hear from anybody, I'm going to assume that this is *not*
needed and that the correct charter update to submit to the IESG should
have "anticipated" or "intended".
pr
On 4/16/12 5:13 AM, [email protected] wrote:
Gabor
Like Gerald, I am uneasy with the use of the word "anticipated". We can
ask Ofcom, but I am sure they will just point us to their regulatory
requirements which use phrasing like "a master WSD must communicate to the
WSDB the following information: .... The lower and upper frequency
boundaries of the in-block emissions.... The maximum in-block EIRP
spectral
densities (in dBm/(0.2 MHz)) that the master WSD, and its associated
slaves,
actually radiate ....". So their regulatory requirements are for actual
usage, not anticipated. It may be foolish for the group to agree charter
text that says something different. Can we just delete the word
"anticipated" in the new bullet 5? The word order could be changed to"
Report spectrum usage to the white space database at a suitable
granularity".
Andy
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of
Gerald Chouinard
Sent: 15 April 2012 18:40
To: [email protected]
Cc: [email protected]; [email protected]
Subject: Re: [paws] charter update
Gabor,
I am wandering is the word "anticipated" will be good enough for OFCOM.
You may want to verify with them. To establish a status of the spectrum
usage in an area, the regulator will likely need the actual usage of this
spectrum and not only its "anticipated" usage.
My two cents ...
Gerald
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of
[email protected]
Sent: Friday, 13 April, 2012 16:31
To: [email protected]; [email protected]
Cc: [email protected]
Subject: Re: [paws] charter update
Pete, Peter,
There doesn't seem to be any objection to this charter update text on the
list from the WG members. Could you guys take this charter proposal text
to
the iesg's telechat?
Thanks, Gabor
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of
Bajko Gabor (Nokia-CIC/SiliconValley)
Sent: Wednesday, April 11, 2012 1:02 PM
To: [email protected]
Cc: [email protected]
Subject: Re: [paws] charter update
Here's the charter update proposal text:
http://www.ietf.org/proceedings/83/slides/slides-83-paws-4.txt
According to diff, the are 6 lines changed, including the update to the
milestones. The main change is adding bullet point 5: " Report to the
white
space database anticipated spectrum usage at a suitable granularity."
- Gabor
-----Original Message-----
From: ext Peter Saint-Andre [mailto:[email protected]]
Sent: Tuesday, April 10, 2012 6:06 PM
To: Bajko Gabor (Nokia-CIC/SiliconValley)
Cc: [email protected]
Subject: Re: [paws] charter update
On 4/9/12 3:40 PM, [email protected] wrote:
Folks,
There was long discussion on the list before the Paris F2F about the
newly surfaced Ofcom requirements, which require the master devices to
report back to the wsdb the spectrum chosen for operation. Since this
aspect is not captured in the current charter, during the F2F we
discussed how to capture those requirements and there was no objection
to a slight charter update.
The tentative charter update text I showed in slide 7 of
http://www.ietf.org/proceedings/83/slides/slides-83-paws-0.pptx had
one objection to the text added as a 5^th bullet point: "5. Report
back to the white space database use information, including the chosen
channels for operation and other relevant information", noting that
the result may be a chatty behavior in case of frequency hopping (see
the
minutes).
The new proposal would be to replace the text in bullet 5 with "Report
to the white space database anticipated spectrum usage at a suitable
granularity." This text seem to be fine with Joel, who raised the
objection.
I hope there is consensus in the wg for this new wording for the
charter update text. If there is no objection on the list to this
newly proposed text in the next few days, I would ask our AD to take
the proposed charter update text in slide 7 of
http://www.ietf.org/proceedings/83/slides/slides-83-paws-0.pptx, with
the new text for bullet 5, to the iesg.
Hi Gabor,
Would you be so kind as to send the actual text to the list? That will
make it easier for people to track the changes, search on this thread,
etc.
Thanks!
Peter
--
Peter Saint-Andre
https://stpeter.im/
