<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:[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 >>>>>> >>>>>> ________________________________ >>>>>> >>>>>> >>>> >> *********************************************************************** >>>>>> * >>>>>> ****************************************** >>>>>> 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
