Peter, Nancy, I agree should design a protocol with the best of our current knowledge, and that should be accounting for all the known regulations at present time. We should not limit the scope with the purpose of designing a protocol 'faster'. Our goal is not only to design a WSDB protocol. Our goal is to design a WSDB protocol that is USEFUL to the community.
The charter does state that "...the group should also reach out to other potential "customers" for a white space database access method and consider input from regulatory entities that are involved in the specification of the rules for secondary use of spectrum in specific radio bands. " I think that is exactly what we are doing now. Regarding whether the types of requirements belong to #1 or #2, I believe it is more of #1 type, as the information to be exchanged would be known after the initial query/response. If we know it today, I see no reason why we should not work on it in the first phase of the work. Regards, Juan Carlos > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Peter Saint-Andre > Sent: Thursday, March 08, 2012 11:59 AM > To: Nancy Bravin > Cc: [email protected]; [email protected]; [email protected]; Pete > Resnick > Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases- > rqmts-03: channel reporting > > 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
