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:
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
On Mar 7, 2012, at 4:41 PM, Peter Saint-Andre wrote:
<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:
There's no language I can find in the charter that explicitly puts
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
On 3/7/12 9:40 AM, Rosen, Brian wrote:
<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
On Mar 6, 2012, at 12:28 PM,<[email protected]>
<[email protected]> wrote:
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 protected]
[mailto:[email protected]] On Behalf Of Joel M. Halpern
Sent: 06 March 2012 17:05 To: [email protected] Cc:
[email protected]; 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 protected] 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
On 3/6/12 10:30 AM, "ext Joel M.
Halpern"<[email protected]> wrote:
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 protected] wrote:
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 protected]"<[email protected]> 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 protected]] Sent: 06 March 2012 15:53
To: Sago,AJ,Andy,COD R Cc: [email protected];
[email protected] 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 protected] wrote:
All
Comparing the draft with the Ofcom requirements at
http://www.cept.org/Documents/se-43/4161/SE43(12)Info03_Draft-UK-r
egul
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:
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 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
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 protected]
[mailto:[email protected]] *On Behalf Of
*[email protected] *Sent:* 05 March 2012 19:46
*To:* [email protected] *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-u
seca
ses-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
_______________________________________________
paws mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/paws
_______________________________________________
paws mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/paws
