Agree. Lets keep it simple and stick to the term WSDB in PAWS. Co-existence is a rathole at this point in time which we should studiously avoid.
-Raj On 3/8/12 2:49 PM, "ext Gerald Chouinard" <[email protected]> wrote: >Juan-Carlos, Raz, > >I agree to keep it to the WSDB. What this data is used for at the WSDB, be >it statistics on spectrum use, more detailed aggregate interference >analysis, co-existence, etc., is beyond the scope of PAWS. As long as the >data is provided to the database by this third level of message, the job >would be done as far as the protocol is concerned. > >Gerald > > >-----Original Message----- >From: Zuniga, Juan Carlos [mailto:[email protected]] >Sent: Thursday, 08 March, 2012 15:42 >To: [email protected]; [email protected]; >[email protected]; [email protected] >Cc: [email protected]; [email protected]; [email protected]; >[email protected] >Subject: RE: [paws] WGLC for >draft-ietf-paws-problem-stmt-usecases-rqmts-03:channel reporting > >Hi Raj, > >I was reusing the language used from Gerald (which I know is familiar to >people working on IEEE 802 WS groups): > >>> [GC] You got it. This would be useless for spectrum regulators. One >>> should realize that, from the spectrum regulator's point of view, the >>> second and third messages could be iterated upon to optimize the >>> spectrum use. >>> Knowing >>> what channels the systems in an area are using, the spectrum >>> regulators and/or other entities such as those taking care of >>> coexistence could use the database in near-real-time to iterate on >>> the two last messages to reduce the range of channels that some >>> systems may use once they know precisely what channels are being used >>> in the area. The PAWS protocol would carry the information back and >>> forth but would not be involved in such spectrum use optimization. > >Having said that, I have no issue sticking to the WSDB terminology. I like >keeping things simple :) > >JC > >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] >> Sent: Thursday, March 08, 2012 3:33 PM >> To: Zuniga, Juan Carlos; [email protected]; >> [email protected]; [email protected] >> Cc: [email protected]; [email protected]; [email protected]; >> [email protected] >> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases- >> rqmts-03:channel reporting >> >> >> Hi JC, >> >> Where/why did the coexistence manager come into the picture? Your >> comment >> about "communicating back to the WSDB/coexistence manager" may result >> in >> further misunderstanding. If we simply stick to to WSDB I think we are >> okay. >> >> -Raj >> >> On 3/8/12 2:25 PM, "ext Zuniga, Juan Carlos" >> <[email protected]> wrote: >> >> >So, from Gerald and Andy's comments, it seems like from the point of >> view >> >of (at least) two regulatory entities it is important for the protocol >> to >> >allow communicating back to the WSDB/coexistence manager the actual >> >channel usage after the first query is made. >> > >> >This is to me a very clear requirement. >> > >> >The actual messages/IEs that would carry this information should be >> >discussed as part of the solution document, and not the requirements. >> > >> >JC >> > >> >> -----Original Message----- >> >> From: [email protected] [mailto:[email protected]] On Behalf >> Of >> >> Gerald Chouinard >> >> Sent: Thursday, March 08, 2012 1:59 PM >> >> To: 'Joel M. Halpern'; [email protected] >> >> Cc: [email protected]; [email protected]; [email protected]; >> >> [email protected] >> >> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases- >> >> rqmts-03:channel reporting >> >> >> >> Joel, Scott, >> >> >> >> Interesting discussion! See my comments in line below. >> >> >> >> Gerald >> >> >> >> -----Original Message----- >> >> From: [email protected] [mailto:[email protected]] On Behalf >> Of >> >> Joel >> >> M. Halpern >> >> Sent: Thursday, 08 March, 2012 13:17 >> >> To: [email protected] >> >> Cc: [email protected]; [email protected]; [email protected]; >> >> [email protected] >> >> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases- >> >> rqmts-03: >> >> channel reporting >> >> >> >> So why won't the device simply say "I will use all of this?" >> >> [GC] This would defeat the purpose of the acknowledgement message. >> >> After all, that way it needs to do less work with the database. And >> it >> >> can change frequencies when it wants. >> >> Given that the stated goal of the Ofcom requriement was to be able >> to >> >> analyze interference effects, it seems that this will not actually >> lead >> >> to them getting what they want, even if it does comply with the >> >> regulations. >> >> [GC] You got it. This would be useless for spectrum regulators. One >> >> should >> >> realize that, from the spectrum regulator's point of view, the >> second >> >> and >> >> third messages could be iterated upon to optimize the spectrum use. >> >> Knowing >> >> what channels the systems in an area are using, the spectrum >> regulators >> >> and/or other entities such as those taking care of coexistence could >> >> use the >> >> database in near-real-time to iterate on the two last messages to >> >> reduce the >> >> range of channels that some systems may use once they know precisely >> >> what >> >> channels are being used in the area. The PAWS protocol would carry >> the >> >> information back and forth but would not be involved in such >> spectrum >> >> use >> >> optimization. >> >> >> >> Yours, >> >> joel >> >> >> >> On 3/8/2012 1:09 PM, [email protected] wrote: >> >> > 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. >> >> [GC] Agree with Scott but this is only a portion of the >> considerations. >> >> If a >> >> device was to operate on its own, this would be true but a >> >> communication >> >> device usually implies at least 2 devices to communicate. Hence, the >> >> choice >> >> of the channel to be used will need to be negotiated between the two >> >> devices >> >> before a choice can be made. The chosen channel will belong to the >> set >> >> of >> >> available channels that is common to both devices. Remember that >> some >> >> channels may be available at one device and not at the other because >> of >> >> their geolocation or other reason. Extending this concept to a star >> >> network >> >> topology, the channel that will be selected by this network will >> have >> >> to >> >> belong to the set of channels that are available to all devices. >> Each >> >> device >> >> will not be able to decide by itself which channel it wants to use. >> >> >> >> This is why in such a star topology, it makes sense that the slave >> >> devices >> >> to a base station or access point be represented by the base station >> >> acting >> >> as the master on their behalf to query the database and receive the >> >> list of >> >> available channels (and/or maximum EIRP per channel). It is then the >> >> responsibility of the base station to identify the set of available >> >> channels >> >> that is common for itself and all its slaves to decide on the >> channel >> >> that >> >> the network will use. As you can see, in this case, there is no need >> >> for >> >> each slave to receive its list of available channels. On its own, it >> >> would >> >> not know what to do with it. The only thing that needs to be sent >> from >> >> the >> >> master device to its slaves is the resulting operating channel. >> >> >> >> I a more sophisticated operation, the master device may add one or a >> >> few >> >> backup channels extracted from the common set of available channel >> to >> >> the >> >> message going to its slave so that if a change in channel >> availability >> >> occurs, an instantaneous switch to the next backup channel can be >> made >> >> without any further signaling, thus providing for a channel switch >> that >> >> is >> >> transparent to the user. It is the scheme that has been included in >> the >> >> IEEE >> >> 802.22-2011 Standard. This is why I don't believe that PAWS should >> get >> >> involved in defining this signaling between the base station and its >> >> slaves >> >> devices. >> >> >> >> >> >> 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). >> >> [GC] If the process involves 2 messages, then, the device and its >> >> associated >> >> devices could change channels at will as long as all these channels >> >> belong >> >> to the set of available channel. However, if the third message is >> >> added, it >> >> would make sense that the master device reports to the database any >> >> channel >> >> change that would occur to the database, otherwise, the status of >> the >> >> spectrum occupation would be wrong at any moment and would be >> useless >> >> for >> >> the purpose of any spectrum usage optimization such as coexistence. >> >> >> >> >> >> 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 >> >> > >> >> _______________________________________________ >> >> 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
