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