A rose by any other name is still a rose. :) It might be true that some folks have a very clear requirement for adding coexistence managers to the architecture, but those are not necessarily the same things as white space databases.
On 3/8/12 1:32 PM, [email protected] wrote: > > 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
