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-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 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 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-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
_______________________________________________
paws mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/paws
_______________________________________________
paws mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/paws
