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
