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