Op 19 mrt. 2012, om 16:17 heeft Rosen, Brian het volgende geschreven: > <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
What to do when switched to another channel? I can think of another extension: Device to DB: By the way, channel 15 is heavily used here. Again, lifetime of his info would be limited. Teco > 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 _______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
