Hi Scott, I have two clarifying questions: 1. Does the device know, when it receives the channel response, which channel it will actually use?
2. If the device then uses another channel or a different channel, does it need to report that change to the database? Thanks! Peter On 3/8/12 10:17 AM, [email protected] wrote: > Hi, > > The point from Brian is very relevant: > > Channel request > Channel response > Channel acknowledgement > > What Ofcom does with the information in the acknowledgement does not > matter. As the regulator in UK, they write rules that must be followed in > order to operate a whitespace radio in the UK. I believe the scope of the > WG must be focused on a working solution. If this is simple channel > request & response in one regulator's domain, PAWS can support this. If it > means a channel request, response and acknowledgement in another > regulator's domain, PAWS can support this. As a participating member of > the work group, I believe the scope should be basic working solution, not > limited to a specific number of messages. > > Kind Regards, > Scott > > > > On 3/8/12 11:11 AM, "ext Zuniga, Juan Carlos" > <[email protected]> wrote: > >> 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
