If we are supporting multiple regulatory domains that have different protocol requirements and state change behaviors we need to define some parameterization of regulatory requirements - like "USE_TRACKING", which if true would generate a message to the DB on each change of the Masters channel/power/modulation settings. This is NOT the same as an ACK. In FCC regions, this parameter would be FALSE and there would be no additional messages indicating usage.
Seems like USE_TRACKING would be a simple extension to a more basic protocol state machine and so could be layered in later or sooner depending on the charter. Paul >-----Original Message----- >From: Rosen, Brian [mailto:[email protected]] >Sent: Monday, March 19, 2012 1:08 PM >To: Paul Lambert >Cc: Joel M. Halpern; [email protected]; [email protected]; >[email protected]; [email protected]; [email protected] >Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases- >rqmts-03:channel reporting > ><as individual> >Depends on the time period allowed for the ack. > >The device won't start another transaction with the database before it >decides. > >The db doesn't have anything except a bit of state to keep if the ack >takes a while. So, let it take a while. > >Eventually, it would decide it wasn't going to get an answer and treat >it like an error (timeout). > >While we have to deal with charter issues, I don't like producing a >protocol spec that only works with the US rules. Tracking usage is not >an unreasonable regulatory requirement, and not a complicated protocol >mechanism. It only gets complicated when the spectrum returned from any >query depends on the usage information. That's somewhere I don't want >to go yet. > ><as chair> >Let's assume, at least for now, that this subject is out of scope. >We'll have a discussion of what to do in Paris, and bring that back to >the list. Let's move forward on the document without this capability, >and we'll pick it up later if/when we get the charter issue settled. >That means I would like to stop discussion until Paris, and then we will >continue it on the list. > >Brian > > > >On Mar 19, 2012, at 2:58 PM, Paul Lambert wrote: > >> >>> -----Original Message----- >>> From: Rosen, Brian [mailto:[email protected]] >>> Sent: Monday, March 19, 2012 8:17 AM >>> To: Paul Lambert >>> Cc: Joel M. Halpern; [email protected]; >[email protected]; >>> [email protected]; [email protected]; [email protected] >>> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases- >>> rqmts-03:channel reporting >>> >>> <as individual> >>> Remembering that so far, it appears this discussion is out of scope: >>> >>> While it may be the case that devices dynamically change their choice >of >>> what "channels" they will use between queries of the database, it's >at >>> least equally likely that it will get the list of available channels, >>> choose one, and stick to it. If they wanted to change at some point, >it >>> seems very feasible to query the database again, since the available >>> spectrum may have changed. >>> >>> The device can't tell the database what it's going to use before it >>> knows what is available. >>> >>> The "ack" sequence would be: >>> Device to DB: What could I use at location x,y? >>> DB to Device: You could use channels 3, 11 or 15 >>> Device to DB: Okay, I'll use channel 11 >> >> But the "ack" in this sequence occurs right after the "you could use" >message. Any intelligent AP/Master might some time to evaluate each >channel and pick one later that has the lowest utilization. It would >not have this knowledge in time for an "ack". If it picked a channel >for the ack, it would likely change soon to another channel. >> >> Given that the "ack" has only informative information that will change >- there is nothing useful that can be done by the DB with this >information. Unless the Master provides continuous updates of channel >utilization - there is no reason to have this information carried in an >ack. >> >> We should not create extra messages to carry information that will not >be used in any processing. >> >> Paul >> >> >>> >>> Brian >>> >>> On Mar 9, 2012, at 6:58 PM, Paul Lambert wrote: >>> >>>> >>>> >>>> +1 to all of Joels comments >>>> >>>> Why would a third ack message ever be different from the original >>> request? >>>> >>>> There's been no time to connect clients or make any other >interesting >>> choices that would change the way the spectrum would be used. The >ack >>> is a useless message and any such informative information about the >>> capabilities or plans of a device to use a range of spectrum should >have >>> been carried in the first message. >>>> >>>> >>>> Paul >>>> >>>>> -----Original Message----- >>>>> From: Joel M. Halpern [mailto:[email protected]] >>>>> Sent: Friday, March 09, 2012 8:00 AM >>>>> To: [email protected] >>>>> Cc: Paul Lambert; [email protected]; [email protected]; >>>>> [email protected]; [email protected]; >>>>> [email protected]; [email protected]; >>> [email protected]; >>>>> [email protected]; [email protected]; >[email protected] >>>>> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases- >>>>> rqmts-03:channel reporting >>>>> >>>>> I am having trouble connecting the goal of the requirement, the >>> expected >>>>> protocol behavior, and the expected real-world operation. >>>>> >>>>> Lets keep it simple. A master, connected by wired internet to the >>>>> World. A set of slaves who want to use whitespace to talk to the >>>>> master. All within a small physical space. All within the the >time >>>>> limit of whatever answer the master gets from the database. >>>>> >>>>> The Ofcom requirement is described as being important for >>> understanding >>>>> interference effects. Therefore, presumably, it needs to relate to >>>>> actual spectrum usage. >>>>> >>>>> The stated protocol behavior is that the master would reply to the >>>>> shitespace database with an ack indicating what it expects to use, >at >>>>> what power level. >>>>> The way folks are writing this, I believe the intention is "respond >>>>> once". >>>>> >>>>> As I understand such master / slave behavior (and I am by no means >a >>>>> radio expert), the actual usage of spectrum, within the whitespace >>> band, >>>>> will depend upon how many slaves are active, and possibly on what >>> they >>>>> are doing. >>>>> >>>>> If the actual usage is going to depend upon the slave device >>> population >>>>> / behavior, then the only answer the master can correctly provide >is >>> "I >>>>> will use all of the whitespace you have identified, with the >highest >>>>> power I might use. >>>>> >>>>> Such an answer is a valid answer in terms of protocol and in terms >of >>>>> the stated regulatory requirements. However, it is utterly useless >>> in >>>>> terms of the stated goal. >>>>> As an engineer, I am very uncomfortable designing a protocol >>> messaging >>>>> exchange which I know will not meet the end-users needs. >>>>> >>>>> Note1: If I have mischaracterized ro misunderstood what folks ahve >>>>> explained, I apologize. >>>>> >>>>> Note2: If instead the intention is for the master to update the >>> database >>>>> every time it changes the spectrum usage pattern, then this is NOT >an >>>>> acknowledgment of the reply from the database. It is a dynamic >>> behavior >>>>> reporting requirement. >>>>> >>>>> Yours, >>>>> Joel >>>>> >>>>> On 3/9/2012 6:36 AM, [email protected] wrote: >>>>>> Hi >>>>>> >>>>>> My reading of the UK regulatory requirements that Ofcom has made >>>>> available is that the Acknowledgement message that must be >>> communicated >>>>> back to the database from the white space device is simply the >>> frequency >>>>> range (or ranges) and maximum eirp density that the device intends >to >>>>> use (a subset of what it would have been offered by the database). >I >>>>> don't believe there is any intent to limit modulation schemes etc. >as >>>>> part of this exchange. This seems a relatively straightforward >>>>> requirement and the PAWS protocol should accommodate this if it is >to >>> be >>>>> relevant for the UK regulatory environment. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Chris >>>>>> >>>>>> -----Original Message----- >>>>>> From: Paul Lambert [mailto:[email protected]] >>>>>> Sent: 09 March 2012 02:15 >>>>>> To: Das, Subir; 'Siew Yoon Tan'; Zuniga, Juan Carlos; >>>>> [email protected]; [email protected]; >>>>> [email protected]; [email protected] >>>>>> Cc: [email protected]; [email protected]; Reza Karimi; >>>>> Dixon,JS,Johnny,COD R; Cheeseman,CJ,Chris,COD R >>>>>> Subject: RE: [paws] WGLC for draft-ietf-paws-problem-stmt- >usecases- >>>>> rqmts-03:channel reporting >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> I have a question here. Is it really an acknowledgement or we >would >>>>>>> like to see a kind of notification message that includes channel, >>> and >>>>>>> other parameters? >>>>>> >>>>>> What if it's multiple channels? What happens if the device adapts >>> and >>>>> changes between modulation technique or bandwidth? Does every >change >>>>> over the air need to be indicated to the GDB? >>>>>> >>>>>> This Channel acknowledgement does not seem useful and would limit >>> real >>>>> world behaviors (like channel and modulation adaptation). >>>>>> >>>>>> If viewed as a potential regulatory requirement - does this imply >we >>>>> need to parameterize the protocol to have different behaviors in >>>>> different regions? >>>>>> >>>>>> Paul >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> Regards, >>>>>>> _Subir >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: [email protected] [mailto:[email protected]] On >>> Behalf >>>>> Of >>>>>>> Siew Yoon Tan >>>>>>> Sent: Thursday, March 08, 2012 4:06 PM >>>>>>> To: Zuniga, Juan Carlos; [email protected]; >>>>>>> [email protected]; [email protected]; >>>>>>> [email protected] >>>>>>> Cc: [email protected]; [email protected]; Reza Karimi; >>>>>>> [email protected]; [email protected] >>>>>>> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt- >usecases- >>>>>>> rqmts-03:channel reporting >>>>>>> >>>>>>> Dear All, >>>>>>> >>>>>>> Regarding Ofcom's requirement to have a return channel as part of >>> the >>>>>>> protocol between the WSD and WSDB, I would like to confirm to >>>>> following >>>>>>> sequence of messaging >>>>>>> >>>>>>> Channel request >>>>>>> Channel response >>>>>>> Channel acknowledgement >>>>>>> >>>>>>> which was raised in an earlier email to this list. >>>>>>> >>>>>>> Our view is that it would be beneficial to define the protocol >>>>> between >>>>>>> WSD and WSDB that supports this requirement even though how the >>>>>>> information could be used is still subject to discussion in the >UK. >>>>>>> >>>>>>> >>>>>>> Best regards, >>>>>>> >>>>>>> Siew Yoon >>>>>>> >>>>>>> >>>>>>> ________________________________________ >>>>>>> From: [email protected] [[email protected]] on behalf of >>>>>>> Zuniga, Juan Carlos [[email protected]] >>>>>>> Sent: 08 March 2012 20:41 >>>>>>> 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:paws- >[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: paws- >[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 >>>>>>> >>>>>>> ________________________________ >>>>>>> >>>>>>> >>>>> >>> >*********************************************************************** >>>>>>> * >>>>>>> ****************************************** >>>>>>> For more information visit www.ofcom.org.uk >>>>>>> >>>>>>> This email (and any attachments) is confidential and intended for >>> the >>>>>>> use of the addressee only. >>>>>>> >>>>>>> If you have received this email in error please notify the >>> originator >>>>>>> of the message and delete it from your system. >>>>>>> >>>>>>> This email has been scanned for viruses. However, you open any >>>>>>> attachments at your own risk. >>>>>>> >>>>>>> Any views expressed in this message are those of the individual >>>>> sender >>>>>>> and do not represent the views or opinions of Ofcom unless >>> expressly >>>>>>> stated otherwise. >>>>>>> >>>>> >>> >*********************************************************************** >>>>>>> * >>>>>>> ****************************************** >>>>>>> _______________________________________________ >>>>>>> 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
