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
