Hi Peter, Answers below.
Kind Regards, Scott On 3/8/12 11:39 AM, "ext Peter Saint-Andre" <[email protected]> wrote: >Hi Scott, I have two clarifying questions: > >1. Does the device know, when it receives the channel response, which >channel it will actually use? Scott->This is all new and I am not aware of any existing implementations. I would argue that the device must decide what channel(s) it will use when it receives the channel response. > >2. If the device then uses another channel or a different channel, does >it need to report that change to the database? Scott->My interpretation of section 3.18 is that the device can only transmit within the upper & lower frequencies returned in the acknowledgment. I do not (quickly) find any reference in the requirements to changing channels. Thus operationally it could be that the channel request process must be repeated before the device can use a different channel (frequencies). > >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
