From vchen@google.com Tue Sep 3 09:32:37 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95F0E11E80F4 for ; Tue, 3 Sep 2013 09:32:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.535 X-Spam-Level: X-Spam-Status: No, score=-1.535 tagged_above=-999 required=5 tests=[AWL=-0.442, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UeyVpPxGRQue for ; Tue, 3 Sep 2013 09:32:36 -0700 (PDT) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 7EEF011E81B1 for ; Tue, 3 Sep 2013 09:32:36 -0700 (PDT) Received: by mail-ie0-f177.google.com with SMTP id e14so10199449iej.8 for ; Tue, 03 Sep 2013 09:32:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=116n6dlhlkhfstuRVv6zGP8ukOiR6OUfnkhbpPkMGVk=; b=anKG2FY0eXBas1v9buzhjEx0ABHEnz/DkdcGwSSJ/tXWrHQtnq7E9xFHmW9Nlh7xZb HwbZl9m0LKaZEMlIhKW7g5wL66H1LC53kRPqKdtbyrghUHMLUjoXXgi6bBXgFRnISEWb ZHmfq6oa2+hLRYZs10qNMskhSKi0YrApnmjb/Xb4+nfekgzWkHfiU8NcTmMg1xSsgTFg MGdbAFUCIn/NocBnB5VSWI0e8gbquipjbzD4aEWug9zZc+Vcmu9J0QA5TsiNb134x6oU lYXQjnrm/KTHmhH1nU0VXbS/9NB9DuWiBGiOfekpCiAaNSQLw7GwzH4SVxp2n82AaKu0 aUkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=116n6dlhlkhfstuRVv6zGP8ukOiR6OUfnkhbpPkMGVk=; b=Z2bf60iHLjB/yUnpRTeUKpXNw09jo86qLFpDqcdPpl9VoaJQxrZ1gx6WvntWxiuND4 anf//c9jivCrgLxmwJDn8s9wEs5GXDa32P1iw8aCSIgioB3VcZskcrQagL6P+vo++Z0E AzvOuESQ+e3geF97jptks1DK6ZYHU5zPfE/mWnLKGNpPXgCJ2zb+wkC0NFrt8jYpGNIB 9KQOhfeYrboo1oEYe2rKj+w/bVYuSlvq4AqrHYgc1XYKhpU01pcylgvT7siHTShNLYWW LtnzgBS727K3q++ZAbtqck1bBkSkJXRlvdhAfchp9EkR7fYoWgciK2FQ+X0pPKPgaFnl ZO8Q== X-Gm-Message-State: ALoCoQkEUE6S6xV+Rx7OM80Gm3SISAFN/mTSaqAoHHkX6qFcBLDq0dqmbawZnSUxz8aFsj59VpRdjB0IASGzNx3e3ZmeP7ag4nM/y95bzEgDfhzNo/BNZS9+xZpGkVc1SxiLj6m0CugLKaxHT4OKkY1CXZ3Mxu6S09xU/rKDA4/MPK3KmlM9giQBcrAK2zgQU8wYxJvi4cKN MIME-Version: 1.0 X-Received: by 10.42.171.71 with SMTP id i7mr858459icz.69.1378225955839; Tue, 03 Sep 2013 09:32:35 -0700 (PDT) Received: by 10.231.113.202 with HTTP; Tue, 3 Sep 2013 09:32:35 -0700 (PDT) In-Reply-To: References: Date: Tue, 3 Sep 2013 09:32:35 -0700 Message-ID: From: Vincent Chen To: Michael Head Content-Type: multipart/alternative; boundary=90e6ba613a6a84c3cb04e57d3c04 Cc: "paws@ietf.org" Subject: Re: [paws] Spectrum_use_notify as pure notification X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 16:32:37 -0000 --90e6ba613a6a84c3cb04e57d3c04 Content-Type: text/plain; charset=ISO-8859-1 I suppose it does not make sense to change the spec to using JSON-RPC notification, then allow for deviation. So, could we see if there is a consensus for one of the following? Option 1: No change to Draft 06: notifySpectrumUse is a JSON-RPC request, with a response that contains only the message type and version: { "jsonrpc": "2.0", "result": { "type": "SPECTRUM_USE_RESP", "version": "1.0" }, "id": "xxxxxxx" } Option 2: Change notifySpectrumUse to be a pure JSON-RPC notification that will not have a JSON-RPC response (i.e., empty HTTP response body). Thanks. -vince On Sat, Aug 24, 2013 at 4:19 PM, Michael Head wrote: > If spectrum_use_notify is a pure JSON-RPC notification, this could be a > problem for our implementation. > > We can't easily guarantee that the there would be no JSON-RPC response > body for this method, but I believe JSON-RPC requires this for notification > calls. > > If clients would ignore any body included in the response, then it would > be fine for us, but I suppose the specification would need to make special > note of that deviation from the JSON-RPC spec. > > Thanks, > -- mike > > -- > ---------------------------------- > Michael R Head > http://www.cs.binghamton.edu/~mike > +1-201-BLISTER > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > > -- -vince --90e6ba613a6a84c3cb04e57d3c04 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

I suppose it does not make sense to ch= ange the spec to using JSON-RPC notification, then allow for deviation.

So, could we see if there is a consensus for one of t= he following?

Option 1: No change to Draft 06: notifySpectrumUse is a= JSON-RPC request, with a response that contains only the message type and = version:

{
=A0 "jsonrpc": &quo= t;2.0",
=A0 "result": {
=A0 =A0 "type": "SP= ECTRUM_USE_RESP",
=A0 =A0 "version": "1.0&quo= t;
=A0 },
=A0 "id": "xxxxxxx"
=
}

Option 2: Change notifySpectrumUse to be a pure JSON-RP= C notification that will not have a JSON-RPC response (i.e., empty HTTP res= ponse body).

Thanks.

-vince=A0


On Sat, Aug 24, 2013 at 4:19 PM, Michael Head <= ;mrhead@google.com> wrote:

_______________________________________________
paws mailing list
paws@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/paws




--
-vince
--90e6ba613a6a84c3cb04e57d3c04-- From vchen@google.com Wed Sep 4 17:23:58 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E61521F9EB8 for ; Wed, 4 Sep 2013 17:23:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.456 X-Spam-Level: X-Spam-Status: No, score=-1.456 tagged_above=-999 required=5 tests=[AWL=-0.079, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W7BwYZ0r-ETC for ; Wed, 4 Sep 2013 17:23:56 -0700 (PDT) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 76F0421F9E9A for ; Wed, 4 Sep 2013 17:23:56 -0700 (PDT) Received: by mail-ob0-f178.google.com with SMTP id ef5so1249529obb.9 for ; Wed, 04 Sep 2013 17:23:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=njLba+hiUBQgJ5YZ2COF3EddEKSMjVL98VBdS/n+KTE=; b=lOmXU4+Uj7dyVRQI9inB/O6TLquRpHjvACSIdehwMqwpSC9irHM+PFfXzAaIW5e6Sd ev0wniRglreXkyuMn3a1xzML67Qmzycv1WIuI8tdx+3g5DAL899s9jAG1rlCNplao1rW B5yCXrD7EuE2z5ecBcunTAsszj5lUNhOq4t6iB8ubPWi1ZpZzNgAVMaYwANCrdderg/c 9deB11wsQMIBco8x0jyO85O97vl/SFlax/QIqZPwehlkZhLynXAA6DBWQKFPz7/wj1/n gA+kNwQdfCjXUizSQnN7jwzdie11zbXhs356ZqHIrIkLCn2hgfoDub6JyMePBJ7MyfMf vl8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=njLba+hiUBQgJ5YZ2COF3EddEKSMjVL98VBdS/n+KTE=; b=QMdV+7+1/prgK+7S8AIXK9SqKpSEmZi0Z6zkFYE3fMVxxyEm3fc7BjtxT481FqKqfn GOKse1yyu0iZmcsN+aE2O6W/+41021PHZRNeUJGwikykUVjldoR8DfVOWthksatn3UnZ FTMCa4xEKdznQ/OsES0nyAwh0BkYh0rHp40hOWl6ClvvBD1jdU8trqta1YA6CU6ctdpG noBNCl3gE2p7c3KxsRq0urO/g3u4BmFI5CI5e2s9l3sbZoP50Hp4VDKWOb6yPT6vYrI1 r0JoRe2O7Bz1QLQmfIuEOykmmGEUdvC94aJHIXa7+Qv32+tDKWl+qXiFq0tls/vx+bvD /0TA== X-Gm-Message-State: ALoCoQnbT4TD3MISBdKdOwx+v0FLPpuTQk08f/wkxedhMT7afIOGFtNdZwFxdSdXjV8dUdSGXkn+Zk27n1V0hc6LLOX9frXZfKJrtOr3otIWJbv4TSCDIuF39KvyTlQI8FQNjzhNJtiJfvqdu22ugYQa43yh5tR3Vv9V1IT/gNdFgnGylwlCknBIcIMYiGrF6iGD2DXWphXq MIME-Version: 1.0 X-Received: by 10.182.106.4 with SMTP id gq4mr4354750obb.4.1378340634943; Wed, 04 Sep 2013 17:23:54 -0700 (PDT) Received: by 10.182.250.134 with HTTP; Wed, 4 Sep 2013 17:23:54 -0700 (PDT) In-Reply-To: References: Date: Wed, 4 Sep 2013 17:23:54 -0700 Message-ID: From: Vincent Chen To: Andy Lee Content-Type: multipart/alternative; boundary=e89a8fb1fa62ed015c04e597efb2 Cc: "paws@ietf.org" Subject: Re: [paws] Encoding of spectrum profile X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 00:23:58 -0000 --e89a8fb1fa62ed015c04e597efb2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Thanks everyone. Here's a more refined description of Option 2, based on the comments. - A spectrum profile provides the maximum permissible power levels across a range of frequencies, where power levels are expressed as maximum power spectral densities over a specified bandwidth - When regulations have requirements at multiple bandwidths (e.g., Ofcom, ETSI), there would be a spectrum profile for each bandwidth. The device emissions must be bounded by all the profiles (logical AND). - The spectrum profile is expressed in terms of an "Ordered List" of (freqHz, psd) pairs - The points must be ordered in non-decreasing "freqHz" value - Two consecutive points may have the same "freqHz" to represent a "step function" - Three or more points may NOT share the same "freqHz" value - The encoding uses an array, for example (thanks for the catch, Dan!): [ { "freqHz": 4.70e8, "maxPsdDbmPerBw": -56.8 }, { "freqHz": 5.18e8, "maxPsdDbmPerBw": -56.8 }, { "freqHz": 5.18e8, "maxPsdDbmPerBw": 30.0 }, { "freqHz": 5.24e8, "maxPsdDbmPerBw": 30.0 }, { "freqHz": 5.24e8, "maxPsdDbmPerBw": 36.0 }, { "freqHz": 5.30e8, "maxPsdDbmPerBw": 36.0 }, { "freqHz": 5.30e8, "maxPsdDbmPerBw": -56.8 }, { "freqHz": 6.98e8, "maxPsdDbmPerBw": -56.8 } ] - Even for regulatory domains that do not compute a level for all channels, there are still generalized (absolute) limits on unintended EM emissions, so there should be no need to use special values, such as -inf, null, etc. for indicating the "unavailable" ranges. Should we adopt this more general encoding over the "channelized" encoding in Draft 06? -vince On Fri, Aug 30, 2013 at 12:43 PM, Andy Lee wrote: > On Thu, Aug 29, 2013 at 1:33 PM, Harasty, Daniel J > wrote: > >> *How to Indicate =93Unavailable=94 >> * >> There are a few options to indicate that a subband is =93unavailable=94. >> 1) **The spec could state a value that means =93unavailable=94, suc= h as >> -100, -1000.0, or -56.8. >> ****2) **The spec could not state that value, and the Database >> could choose an arbitrary small number at its discretion. >> ****3) **The spec could state that the JSON value *null* means >> =93unavailable=94, or a reserved string such as =93-Inf=94 > > ** > > ** > > ** > In the case of Ofcom white space rules, I believe that a power level will > be computed for every channel, albeit very low on some channels. > > In the case of the FCC, there are also specific levels specified for OOB > white space emissions. > > For Industry Canada, the FCC, and probably everywhere, there are also > generalized limits on unintended EM emissions (e.g., IC "RSS-Gen" and FCC > "Part 15" rules). This should make it possible to specify a theoretical > power "floor" without having to resort to weirdness like "-Inf" or "null" > values. It would be much better to fill in real values based on actual > rules from the regulator. > > > Andy Lee | Google Inc. | tvfool@google.com | 408-230-0522 > > > On Thu, Aug 29, 2013 at 3:30 PM, Kalle Kuismanen < > kalle.kuismanen@fairspectrum.com> wrote: > >> Hi All, >> >> I haven't participated in the discussion much, but I just had to solve >> this very issue about a week ago so here a my two cents: >> >> on the issue of "-Inf" or null. We've also used in our paws and other >> protocol implementation "-Inf" as indication of channel being unavailabl= e, >> but problem is that it's somewhat misleading. For example if a channel i= s >> "usable" only above 20 dBm and we calculate maximum transmission to be 1= 9 >> dBm it is bit silly to send -Inf. Null value is even more misleading, >> because it usually indicates that we don't know what the value is, which= in >> this case probably would mean an implementation error in the calculation >> code. >> >> Then of course considering the implementation. I tried to use in our paw= s >> implementation "-Inf", but of course Javascript doesn't recognize that >> string as a number, so it causes a type casting problem i.e. sometimes = the >> value is a number and sometimes a string. Which of course led to first o= ur >> server not validating the JSON against the PAWS schema and then when I b= y >> passed that (bad thing, but I was in a rush) our test client side >> validation failed also. >> >> See below how I decided it should be solved, but in the end, because >> didn't want to burden the device side implementers I just dropped the >> channels that couldn't be used from the array. >> >> On the client side or device side the JSON needs to be checked for the >> special value or a simple field will suffice. Mutable nature of JSON mak= es >> it easy. >> >> On client side the code would check in Javascript in node.js: >> >> var a =3D [ >> { "freqHz": 4.70e8, "unavailable": true}, >> { "freqHz": 5.18e8, "unavailable": true}, >> { "freqHz": 5.18e8, "maxPsdDbmPerBw": 30.0 }, >> { "freqHz": 5.24e8, "maxPsdDbmPerBw": 30.0 }, >> ]; >> var b =3D ""; >> >> for(var f in a) >> { >> if(a[f]["unavailable"]!=3D=3Dtrue) >> b +=3D a[f].freqHz+":"+a[f].maxPsdDbmPerBw+"\n"; >> } >> >> process.stdout.write( b ); >> >> This is not so different from using "-Inf" or "null" implementation. >> >> var a =3D [ >> { "freqHz": 4.70e8, "maxPsdDbmPerBw": "-Inf"}, >> { "freqHz": 5.18e8, "maxPsdDbmPerBw": "-Inf"}, >> { "freqHz": 5.18e8, "maxPsdDbmPerBw": 30.0 }, >> { "freqHz": 5.24e8, "maxPsdDbmPerBw": 30.0 }, >> ]; >> var b =3D ""; >> >> for(var f in a) >> { >> if(a[f]["maxPsdDbmPerBw"]!=3D=3D"-Inf") >> b +=3D a[f].freqHz+":"+a[f].maxPsdDbmPerBw+"\n"; >> } >> process.stdout.write( b ); >> >> Both cases usually just do one comparison. But as I said first version >> preserves type of maxPsdDbmPerBw other does not. Both cost about the >> same on the wire. >> >> But of course this is just a suggestion. JSON is very malleable. >> >> Cheers, >> Kalle Kuismanen >> FairSpectrum >> >> >> On Thu, Aug 29, 2013 at 11:33 PM, Harasty, Daniel J < >> dharasty@appcomsci.com> wrote: >> >>> ** ** >>> >>> I rather prefer option 2, but I realize this is more a point of persona= l >>> taste; I think either are workable.**** >>> >>> ** ** >>> >>> Regarding option 2, I have the following comments. (Some may apply to >>> option 1, also.)**** >>> >>> ** ** >>> >>> *Ordering Matters* >>> >>> **** >>> >>> I think the spec should require that the =93points=94 be in >>> frequency-increasing order of =93freqHz=94 value. (The need is obvious= , so >>> let=92s state it as a requirement.)**** >>> >>> ** ** >>> >>> Two =93points=94 may have the same =93freqHz=94 value; their order is >>> significant, too. (For example, the first four points in Vince=92s exa= mple >>> constitute a =93step function=94. However, if points #2 and #3 were sw= apped, >>> it would indicate a =93sawtooth=94 spectral mask.)**** >>> >>> ** ** >>> >>> Three (or more) =93points=94 may NOT share a =93freqHz=94 value.**** >>> >>> ** ** >>> >>> *Should be an Array* >>> >>> ** ** >>> >>> I think the term =93point=94 is rather vague, an repeatedly re-using it= in a >>> single object can=92t be kosher. **** >>> >>> ** ** >>> >>> Thus, I propose this structure be an array of objects:**** >>> >>> ** ** >>> >>> [**** >>> >>> { "freqHz": 4.70e8, "maxPsdDbmPerBw": -56.8 },**** >>> >>> { "freqHz": 5.18e8, "maxPsdDbmPerBw": -56.8 },**** >>> >>> { "freqHz": 5.18e8, "maxPsdDbmPerBw": 30.0 },**** >>> >>> { "freqHz": 5.24e8, "maxPsdDbmPerBw": 30.0 },**** >>> >>> .**** >>> >>> .**** >>> >>> .**** >>> >>> ]**** >>> >>> ** ** >>> >>> *How to Indicate =93Unavailable=94* >>> >>> ** ** >>> >>> There are a few options to indicate that a subband is =93unavailable=94= .**** >>> >>> **1) **The spec could state a value that means =93unavailable=94, = such >>> as -100, -1000.0, or -56.8.**** >>> >>> **2) **The spec could not state that value, and the Database could >>> choose an arbitrary small number at its discretion.**** >>> >>> **3) **The spec could state that the JSON value *null* means >>> =93unavailable=94, or a reserved string such as =93-Inf=94**** >>> >>> ** ** >>> >>> I rather prefer option 3. If we use a reserved string, I prefer =93-In= f=94 >>> in particular as it is an IEEE standard for negative infinity, and many >>> programming languages support interpreting =93-Inf=94 as a parsable str= ing >>> resulting in a valid IEEE float.**** >>> >>> ** ** >>> >>> [**** >>> >>> { "freqHz": 4.70e8, "maxPsdDbmPerBw": null},**** >>> >>> { "freqHz": 5.18e8, "maxPsdDbmPerBw": null },**** >>> >>> { "freqHz": 5.18e8, "maxPsdDbmPerBw": 30.0 },**** >>> >>> { "freqHz": 5.24e8, "maxPsdDbmPerBw": 30.0 },**** >>> >>> ]**** >>> >>> ** ** >>> >>> or**** >>> >>> ** ** >>> >>> [**** >>> >>> { "freqHz": 4.70e8, "maxPsdDbmPerBw": =93-Inf=94},**** >>> >>> { "freqHz": 5.18e8, "maxPsdDbmPerBw": =93-Inf=94},**** >>> >>> { "freqHz": 5.18e8, "maxPsdDbmPerBw": 30.0 },**** >>> >>> { "freqHz": 5.24e8, "maxPsdDbmPerBw": 30.0 },**** >>> >>> ]**** >>> >>> ** ** >>> >>> ** ** >>> >>> *From:* paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] *On Behalf >>> Of *Vincent Chen >>> *Sent:* Sunday, August 25, 2013 6:40 PM >>> *To:* paws@ietf.org >>> *Subject:* [paws] Encoding of spectrum profile**** >>> >>> ** ** >>> >>> All,**** >>> >>> ** ** >>> >>> As was brought up before (and at) the F2F, the current encoding for a >>> spectrum profile**** >>> >>> has a "channelized" view:**** >>> >>> - List of (startHz, stopHz, power)**** >>> >>> - Has no ability to specify power level in "unavailable" ranges**** >>> >>> ** ** >>> >>> Example:**** >>> >>> {**** >>> >>> "point": { "startHz": 5.18e8, "stopHz": 5.24e8, "maxPsdDbmPerBw": >>> 30.0 },**** >>> >>> "point": { "startHz": 5.24e8, "stopHz": 5.30e8, "maxPsdDbmPerBw": >>> 36.0 },**** >>> >>> }**** >>> >>> ** ** >>> >>> Question: Should we use a more flexible encoding?**** >>> >>> ** ** >>> >>> There were two proposals made on the list:**** >>> >>> - Option 1: List of (startHz, startPower, stopHz, stopPower)**** >>> >>> - Option 2: Ordered list of (freqHz, power)**** >>> >>> ** ** >>> >>> At the F2F, we agreed that Option 2 was the more general form.**** >>> >>> ** ** >>> >>> Example:**** >>> >>> {**** >>> >>> "point": { "freqHz": 4.70e8, "maxPsdDbmPerBw": -56.8 },**** >>> >>> "point": { "freqHz": 5.18e8, "maxPsdDbmPerBw": -56.8 },**** >>> >>> "point": { "freqHz": 5.18e8, "maxPsdDbmPerBw": 30.0 },**** >>> >>> "point": { "freqHz": 5.24e8, "maxPsdDbmPerBw": 30.0 },**** >>> >>> "point": { "freqHz": 5.24e8, "maxPsdDbmPerBw": 36.0 },**** >>> >>> "point": { "freqHz": 5.30e8, "maxPsdDbmPerBw": 36.0 },**** >>> >>> "point": { "freqHz": 5.30e8, "maxPsdDbmPerBw": -56.8 },**** >>> >>> "point": { "freqHz": 6.98e8, "maxPsdDbmPerBw": -56.8 }**** >>> >>> }**** >>> >>> >>> **** >>> >>> This example explicitly specifies the power levels in the unavailable >>> frequency ranges.**** >>> >>> ** ** >>> >>> This example also shows that it's possible to encode "square edges" by >>> having two**** >>> >>> points using the same frequency, but does allow for "slanted edges" for >>> more gentle roll-offs.**** >>> >>> ** ** >>> >>> -- >>> -vince **** >>> >>> _______________________________________________ >>> paws mailing list >>> paws@ietf.org >>> https://www.ietf.org/mailman/listinfo/paws >>> >>> >> >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws >> >> > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > > --=20 -vince --e89a8fb1fa62ed015c04e597efb2 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Thanks everyone.

Here's a more refi= ned description of Option 2, based on the comments.

- A spectrum profile provides the maximum permissible power levels across = a range of frequencies, where power levels are expressed as maximum power s= pectral densities over a specified bandwidth

- When regulations have requirements at multiple bandwi= dths (e.g., Ofcom, ETSI), there would be a spectrum profile for each bandwi= dth. The device emissions must be bounded by all the profiles (logical AND)= .

- The spectrum profile is expressed in terms of an &quo= t;Ordered List" of (freqHz, psd) pairs
=A0 - The points must= be ordered in non-decreasing "freqHz" value
=A0 - Two = consecutive points may have the same "freqHz" to represent a &quo= t;step function"
=A0 - Three or more points may NOT share the same "freqHz" v= alue

- The encoding uses an array, for example (th= anks for the catch, Dan!):
=A0[
= =A0 =A0 { "freqHz": 4.70e8, "maxPsdDbmPerBw": -56.8 },<= br>
=A0 =A0= { "freqHz": 5.18e8, "maxPsdDbmPerBw": -56.8 },
=A0 =A0 { = "freqHz": 5.18e8, "maxPsdDbmPerBw": 30.0 },
=A0 =A0 { "freqHz= ": 5.24e8, "maxPsdDbmPerBw": 30.0 },
=A0 =A0 { "= freqHz": 5.24e8, "maxPsdDbmPerBw": 36.0 },
=A0 =A0 { "freqHz&quo= t;: 5.30e8, "maxPsdDbmPerBw": 36.0 },
=A0 =A0 { "= freqHz": 5.30e8, "maxPsdDbmPerBw": -56.8 },
=A0 =A0 { "freqHz&quo= t;: 6.98e8, "maxPsdDbmPerBw": -56.8 }
=A0 ]

- Even for regulatory= domains that do not compute a level for all channels, there are still gene= ralized (absolute) limits on unintended EM emissions, so there should be no= need to use special values, such as -inf, null, etc. for indicating the &q= uot;unavailable" ranges.

Should we adopt thi= s more general encoding over the "channelized" encoding in Draft = 06?

-vince


On Fri, Aug 30, 2013 at 12:43 PM, Andy= Lee <tvfool@google.com> wrote:

On Thu, Aug 29, 2013 at 1:33 PM= , Harasty, Daniel J=A0&l= t;dharasty@appc= omsci.com>= =A0wrote:

How to Indicate =93Unavailable=94
=A0
There are a few options to indicat= e that a subband is =93unavailable=94.
1)=A0=A0=A0=A0=A0=A0The spec could sta= te a value that means =93unavailable=94, such as -100, -1000.0, or -56.8. 2)=A0=A0=A0=A0=A0=A0The= spec could not state that value, and the Database could choose an arbitrar= y small number at its discretion.
3)=A0=A0=A0=A0=A0=A0The= spec could state that the JSON value=A0null=A0means =93unavailable=94, or a reserved string such as =93-Inf= =94

In the case of Ofcom white space rules, I believe that a power level will b= e computed for every channel, albeit very low on some channels.

In the case of th= e FCC, there are also specific levels specified for OOB white space emissio= ns.

For Industr= y Canada, the FCC, and probably everywhere, there are also generalized limi= ts on unintended EM emissions (e.g., IC "RSS-Gen" and FCC "P= art 15" rules). =A0This should make it possible to specify a theoretic= al power "floor" without having to resort to weirdness like "= ;-Inf" or "null" values. =A0It would be much better to fill = in real values based on actual rules from the regulator.


Andy Lee=A0| =A0Google Inc. |=A0tvfool@google.com=A0| =A040= 8-230-0522


On Thu, Aug= 29, 2013 at 3:30 PM, Kalle Kuismanen <kalle.kuismanen@fair= spectrum.com> wrote:
Hi All,

I haven't = participated in the discussion much, but I just had to solve this very issu= e about a week ago so here a my two cents:

on the issue of "-Inf" or null. We've als= o used in our paws and other protocol implementation "-Inf" as in= dication of channel being unavailable, but problem is that it's somewha= t misleading. For example if a channel is "usable" only above 20 = dBm and we calculate maximum transmission to be 19 dBm it is bit silly to s= end -Inf. Null value is even more misleading, because it usually indicates = that we don't know what the value is, which in this case probably would= mean an implementation error in the calculation code.

Then of course considering the implementation. I tried = to use in our paws implementation "-Inf", but of course Javascrip= t doesn't recognize that string =A0as a number, so it causes a type cas= ting problem i.e. sometimes the value is a number and sometimes a string. W= hich of course led to first our server not validating the JSON against the = PAWS schema and then when I by passed that (bad thing, but I was in a rush)= our test client side validation failed also.

See below how I decided it should be solved, but in the= end, because didn't want to burden the device side implementers I just= dropped the channels that couldn't be used from the array.

On the client side or device side the JSON needs to be check= ed for the special value or a simple field will suffice. Mutable nature of = JSON makes it easy.

On client side the code would = check in Javascript in node.js:

var a =3D [=
=A0 =A0 { "fre= qHz": 4.70e8, "unavailable": true},=A0
=A0 =A0 { "freqHz": 5.18e8, &qu= ot;unavailable": true},
=A0 =A0 { "freqHz": 5.= 18e8, "maxPsdDbmPerBw": 30.0 },
=A0 =A0 { "freqHz": 5.24e8, "maxPsdDbm= PerBw": 30.0 },
];
var b =3D "";

for(var f in a)
=A0 =A0 {
=A0 =A0 if(a[f]["unavailable"]!= =3D=3Dtrue)=A0
=A0 = =A0 =A0 =A0 b +=3D a[f].freqHz+":"+a[f].maxPsdDbmPerBw+"\n&q= uot;;
=A0 =A0 }

process.stdout.write( b );

This is not so different from using "-Inf" or "null" = implementation.

var a = =3D [
=A0 =A0 {= "freqHz": 4.70e8, "maxPsdDbmPerBw": "-Inf"},= =A0
=A0 =A0 { "freqHz": 5.= 18e8, "maxPsdDbmPerBw": "-Inf"},
=A0 =A0 { "freqHz": 5.18e8, &quo= t;maxPsdDbmPerBw": 30.0 },
=A0 =A0 { "freqHz": 5.= 24e8, "maxPsdDbmPerBw": 30.0 },
];
var b =3D "";

for(var f in a)
=A0 =A0 {
=A0 =A0 if(a[f]["maxPsdDbmPerBw"]!=3D=3D"-Inf&= quot;)
=A0 =A0 =A0 =A0 b +=3D a[f].freq= Hz+":"+a[f].maxPsdDbmPerBw+"\n";
=A0 =A0 }
process.stdout.write( b );
maxPsdDbmPerBw other does not. Both cost ab= out the same on the wire.=A0

But of course this is just a suggestion. JSON is very m= alleable.

Cheers,
Kalle Kuismanen
FairSpectrum


On Thu, Aug 29, 2013 at 11:33 PM, Harasty, Daniel J <<= a href=3D"mailto:dharasty@appcomsci.com" target=3D"_blank">dharasty@appcoms= ci.com> wrote:

= =A0

I rather prefer option 2, but I realize thi= s is more a point of personal taste; I think either are workable.=

=A0

Regarding option 2, I hav= e the following comments.=A0 (Some may apply to option 1, also.)<= /u>

=A0

Ordering Matters

I think the spec should req= uire that the =93points=94 be in frequency-increasing order of =93freqHz=94= value.=A0 (The need is obvious, so let=92s state it as a requirement.)<= /u>

=A0

Two =93points=94 may have= the same =93freqHz=94 value; their order is significant, too.=A0 (For exam= ple, the first four points in Vince=92s example constitute a =93step functi= on=94.=A0 However, if points #2 and #3 were swapped, it would indicate a = =93sawtooth=94 spectral mask.)

=A0

Three (or more) =93points= =94 may NOT share a =93freqHz=94 value.

=A0

Should be an Array<= /u>

=A0

I think the term =93point= =94 is rather vague, an repeatedly re-using it in a single object can=92t b= e kosher.=A0

=A0

Thus, I propose this stru= cture be an array of objects:

=A0

[

=A0=A0 =A0{ "freqHz": 4.70e8, "maxPsdDbmPerB= w": -56.8 },

=A0=A0=A0 { "freqHz": 5.18e8, "maxPsdDbmPer= Bw": -56.8 },

=A0=A0=A0 { "freqHz": 5.18e8, "maxPsdDbmPerBw&quo= t;: 30.0 },

=A0=A0=A0 { "freqHz": 5.24e8, "maxPsdDbmPerBw":= 30.0 },

=A0=A0 .

=A0=A0 .

=A0=A0 .

]

=A0

How to Indicate =93Unavailable=94

=A0

There are a few options to indicate that a subband is =93unavail= able=94.

1)=A0=A0=A0=A0=A0 The spec could state a value that means =93un= available=94, such as -100, -1000.0, or -56.8.

2)=A0=A0=A0=A0=A0 The= spec could not state that value, and the Database could choose an arbitrar= y small number at its discretion.

3)=A0=A0=A0=A0=A0 The= spec could state that the JSON value null<= span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73= ,125)"> means =93unavailable=94, or a reserved string such as =93-Inf=94=

=A0

I rather prefer option 3.= =A0 If we use a reserved string, I prefer =93-Inf=94 in particular as it is= an IEEE standard for negative infinity, and many programming languages sup= port interpreting =93-Inf=94 as a parsable string resulting in a valid IEEE= float.

=A0

[

=A0=A0 =A0{ "freqHz": 4.70e8, "maxPsdDbmPerBw&quo= t;: =A0null},

=A0=A0=A0 { "freqHz": 5.18e8, "maxPsdDbmPerBw":= null },

=A0=A0=A0 { "freqHz": 5.18e8, "maxPsdDbmPerBw":= 30.0 },

=A0=A0=A0 { "freqHz": 5.24e8, "maxPsdDbmPerBw":= 30.0 },

]

=A0

or

=A0

[

=A0=A0 =A0{ "freqHz": 4.70e8, "maxPsdDbmPerBw&quo= t;: =93-Inf=94},

=A0=A0=A0 { "freqHz": 5.18e8, "maxPsdDbmPerBw":= =93-Inf=94},

=A0=A0=A0 { "freqHz": 5.18e8, "maxPsdDbmPerBw":= 30.0 },

=A0=A0=A0 { "freqHz": 5.24e8, "maxPsdDbmPerBw":= 30.0 },

]

=A0

=A0<= /p>

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On B= ehalf Of Vincent Chen
Sent: Sunday, August 25, 2013 6:40 PM
To: paws@ietf.org
Subject: [pa= ws] Encoding of spectrum profile

=A0

All,

=A0

As was brought up before (and at) the F2F,= the current encoding for a spectrum profile

has a "channelized" view:

=A0- List of (startHz, stopHz, power)

= =A0- Has no ability to specify power level in "unavailable" range= s

=A0

Example:

=

=A0 {

=A0 =A0 "point"= ;: { "startHz": 5.18e8, "stopHz": 5.24e8, "maxPsdD= bmPerBw": 30.0 },

=A0 =A0 "point": { "startHz": 5.24e8, &qu= ot;stopHz": 5.30e8, "maxPsdDbmPerBw": 36.0 },<= /p>

=A0 }

=A0

Question: Should we use a more f= lexible encoding?

=A0

There were two proposals made on the list:

= =A0 - Option 1: List of (startHz, startPower, stopHz, stopPower)<= /u>

=A0 - Option 2: Ordered list of (freqHz, power)=

=A0

At the F2F, we agreed that= Option 2 was the more general form.

= =A0

Example:

=A0 {

=A0 =A0 "point": { "freqHz": 4.70e8, "maxPsdD= bmPerBw": -56.8 },

=A0 =A0 "point": { "freqHz": 5.18e8, &quo= t;maxPsdDbmPerBw": -56.8 },

=A0 =A0 &qu= ot;point": { "freqHz": 5.18e8, "maxPsdDbmPerBw": 3= 0.0 },

=A0 =A0 "point": { "freqHz": 5.24e8, &quo= t;maxPsdDbmPerBw": 30.0 },

=A0 =A0 &quo= t;point": { "freqHz": 5.24e8, "maxPsdDbmPerBw": 36= .0 },

=A0 =A0 "point": { "freqHz": 5.30e8, &quo= t;maxPsdDbmPerBw": 36.0 },

=A0 =A0 &quo= t;point": { "freqHz": 5.30e8, "maxPsdDbmPerBw": -5= 6.8 },

=A0 =A0 "point": { "freqHz": 6.98e8, &quo= t;maxPsdDbmPerBw": -56.8 }

=A0 }=


This example explicitly specifi= es the power levels in the unavailable frequency ranges.

<= /div>

=A0

This example also shows that it's possible to encode "squa= re edges" by having two

points using th= e same frequency, but does allow for "slanted edges" for more gen= tle roll-offs.

=A0

--
-vince


_________________= ______________________________
paws mailing list
paws@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/paws



_______________________________________________
paws mailing list
paws@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/paws



_______________________________________________
paws mailing list
paws@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/paws




--
-vince
--e89a8fb1fa62ed015c04e597efb2-- From paul@marvell.com Wed Sep 4 18:09:56 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54F2111E8150 for ; Wed, 4 Sep 2013 18:09:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cqZZSlpJt+Xx for ; Wed, 4 Sep 2013 18:09:51 -0700 (PDT) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) by ietfa.amsl.com (Postfix) with ESMTP id 5E7F511E8222 for ; Wed, 4 Sep 2013 18:09:51 -0700 (PDT) Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.14.5/8.14.5) with SMTP id r8519m0o003978; Wed, 4 Sep 2013 18:09:48 -0700 Received: from sc-owa.marvell.com ([199.233.58.135]) by mx0b-0016f401.pphosted.com with ESMTP id 1enapvx8jm-37 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 04 Sep 2013 18:09:48 -0700 Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA.marvell.com ([::1]) with mapi; Wed, 4 Sep 2013 18:09:44 -0700 From: Paul Lambert To: Vincent Chen , Andy Lee Date: Wed, 4 Sep 2013 18:09:42 -0700 Thread-Topic: [paws] Encoding of spectrum profile Thread-Index: Ac6p1JsAxwx/3oyIR1W8b4yelmFtpQ== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CE4D254F21396paulmarvellcom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-09-04_10:2013-09-05, 2013-09-04, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1309040124 Cc: "paws@ietf.org" Subject: Re: [paws] Encoding of spectrum profile X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 01:09:56 -0000 --_000_CE4D254F21396paulmarvellcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thanks everyone. Here's a more refined description of Option 2, based on the comments. - A spectrum profile provides the maximum permissible power levels across a= range of frequencies, where power levels are expressed as maximum power sp= ectral densities over a specified bandwidth - When regulations have requirements at multiple bandwidths (e.g., Ofcom, E= TSI), there would be a spectrum profile for each bandwidth. The device emis= sions must be bounded by all the profiles (logical AND). - The spectrum profile is expressed in terms of an "Ordered List" of (freqH= z, psd) pairs - The points must be ordered in non-decreasing "freqHz" value - Two consecutive points may have the same "freqHz" to represent a "step = function" - Three or more points may NOT share the same "freqHz" value - There must be two or more points with different "freqHz" values =85 Should we adopt this more general encoding over the "channelized" encoding = in Draft 06? Yes. Seems like a significant improvement! Paul -vince On Fri, Aug 30, 2013 at 12:43 PM, Andy Lee > wrote: On Thu, Aug 29, 2013 at 1:33 PM, Harasty, Daniel J > wrote: How to Indicate =93Unavailable=94 There are a few options to indicate that a subband is =93unavailable=94. 1) The spec could state a value that means =93unavailable=94, such as = -100, -1000.0, or -56.8. 2) The spec could not state that value, and the Database could choose = an arbitrary small number at its discretion. 3) The spec could state that the JSON value null means =93unavailable= =94, or a reserved string such as =93-Inf=94 In the case of Ofcom white space rules, I believe that a power level will b= e computed for every channel, albeit very low on some channels. In the case of the FCC, there are also specific levels specified for OOB wh= ite space emissions. For Industry Canada, the FCC, and probably everywhere, there are also gener= alized limits on unintended EM emissions (e.g., IC "RSS-Gen" and FCC "Part = 15" rules). This should make it possible to specify a theoretical power "f= loor" without having to resort to weirdness like "-Inf" or "null" values. = It would be much better to fill in real values based on actual rules from t= he regulator. Andy Lee | Google Inc. | tvfool@google.com | 408-230-0522 On Thu, Aug 29, 2013 at 3:30 PM, Kalle Kuismanen > wrote: Hi All, I haven't participated in the discussion much, but I just had to solve this= very issue about a week ago so here a my two cents: on the issue of "-Inf" or null. We've also used in our paws and other proto= col implementation "-Inf" as indication of channel being unavailable, but p= roblem is that it's somewhat misleading. For example if a channel is "usabl= e" only above 20 dBm and we calculate maximum transmission to be 19 dBm it = is bit silly to send -Inf. Null value is even more misleading, because it u= sually indicates that we don't know what the value is, which in this case p= robably would mean an implementation error in the calculation code. Then of course considering the implementation. I tried to use in our paws i= mplementation "-Inf", but of course Javascript doesn't recognize that strin= g as a number, so it causes a type casting problem i.e. sometimes the valu= e is a number and sometimes a string. Which of course led to first our serv= er not validating the JSON against the PAWS schema and then when I by passe= d that (bad thing, but I was in a rush) our test client side validation fai= led also. See below how I decided it should be solved, but in the end, because didn't= want to burden the device side implementers I just dropped the channels th= at couldn't be used from the array. On the client side or device side the JSON needs to be checked for the spec= ial value or a simple field will suffice. Mutable nature of JSON makes it e= asy. On client side the code would check in Javascript in node.js: var a =3D [ { "freqHz": 4.70e8, "unavailable": true}, { "freqHz": 5.18e8, "unavailable": true}, { "freqHz": 5.18e8, "maxPsdDbmPerBw": 30.0 }, { "freqHz": 5.24e8, "maxPsdDbmPerBw": 30.0 }, ]; var b =3D ""; for(var f in a) { if(a[f]["unavailable"]!=3D=3Dtrue) b +=3D a[f].freqHz+":"+a[f].maxPsdDbmPerBw+"\n"; } process.stdout.write( b ); This is not so different from using "-Inf" or "null" implementation. var a =3D [ { "freqHz": 4.70e8, "maxPsdDbmPerBw": "-Inf"}, { "freqHz": 5.18e8, "maxPsdDbmPerBw": "-Inf"}, { "freqHz": 5.18e8, "maxPsdDbmPerBw": 30.0 }, { "freqHz": 5.24e8, "maxPsdDbmPerBw": 30.0 }, ]; var b =3D ""; for(var f in a) { if(a[f]["maxPsdDbmPerBw"]!=3D=3D"-Inf") b +=3D a[f].freqHz+":"+a[f].maxPsdDbmPerBw+"\n"; } process.stdout.write( b ); Both cases usually just do one comparison. But as I said first version pres= erves type of maxPsdDbmPerBw other does not. Both cost about the same on th= e wire. But of course this is just a suggestion. JSON is very malleable. Cheers, Kalle Kuismanen FairSpectrum On Thu, Aug 29, 2013 at 11:33 PM, Harasty, Daniel J > wrote: I rather prefer option 2, but I realize this is more a point of personal ta= ste; I think either are workable. Regarding option 2, I have the following comments. (Some may apply to opti= on 1, also.) Ordering Matters I think the spec should require that the =93points=94 be in frequency-incre= asing order of =93freqHz=94 value. (The need is obvious, so let=92s state = it as a requirement.) Two =93points=94 may have the same =93freqHz=94 value; their order is signi= ficant, too. (For example, the first four points in Vince=92s example cons= titute a =93step function=94. However, if points #2 and #3 were swapped, i= t would indicate a =93sawtooth=94 spectral mask.) Three (or more) =93points=94 may NOT share a =93freqHz=94 value. Should be an Array I think the term =93point=94 is rather vague, an repeatedly re-using it in = a single object can=92t be kosher. Thus, I propose this structure be an array of objects: [ { "freqHz": 4.70e8, "maxPsdDbmPerBw": -56.8 }, { "freqHz": 5.18e8, "maxPsdDbmPerBw": -56.8 }, { "freqHz": 5.18e8, "maxPsdDbmPerBw": 30.0 }, { "freqHz": 5.24e8, "maxPsdDbmPerBw": 30.0 }, . . . ] How to Indicate =93Unavailable=94 There are a few options to indicate that a subband is =93unavailable=94. 1) The spec could state a value that means =93unavailable=94, such as = -100, -1000.0, or -56.8. 2) The spec could not state that value, and the Database could choose = an arbitrary small number at its discretion. 3) The spec could state that the JSON value null means =93unavailable= =94, or a reserved string such as =93-Inf=94 I rather prefer option 3. If we use a reserved string, I prefer =93-Inf=94= in particular as it is an IEEE standard for negative infinity, and many pr= ogramming languages support interpreting =93-Inf=94 as a parsable string re= sulting in a valid IEEE float. [ { "freqHz": 4.70e8, "maxPsdDbmPerBw": null}, { "freqHz": 5.18e8, "maxPsdDbmPerBw": null }, { "freqHz": 5.18e8, "maxPsdDbmPerBw": 30.0 }, { "freqHz": 5.24e8, "maxPsdDbmPerBw": 30.0 }, ] or [ { "freqHz": 4.70e8, "maxPsdDbmPerBw": =93-Inf=94}, { "freqHz": 5.18e8, "maxPsdDbmPerBw": =93-Inf=94}, { "freqHz": 5.18e8, "maxPsdDbmPerBw": 30.0 }, { "freqHz": 5.24e8, "maxPsdDbmPerBw": 30.0 }, ] From:paws-bounces@ietf.org [mailto:paws-bounc= es@ietf.org] On Behalf Of Vincent Chen Sent: Sunday, August 25, 2013 6:40 PM To: paws@ietf.org Subject: [paws] Encoding of spectrum profile All, As was brought up before (and at) the F2F, the current encoding for a spect= rum profile has a "channelized" view: - List of (startHz, stopHz, power) - Has no ability to specify power level in "unavailable" ranges Example: { "point": { "startHz": 5.18e8, "stopHz": 5.24e8, "maxPsdDbmPerBw": 30.0 = }, "point": { "startHz": 5.24e8, "stopHz": 5.30e8, "maxPsdDbmPerBw": 36.0 = }, } Question: Should we use a more flexible encoding? There were two proposals made on the list: - Option 1: List of (startHz, startPower, stopHz, stopPower) - Option 2: Ordered list of (freqHz, power) At the F2F, we agreed that Option 2 was the more general form. Example: { "point": { "freqHz": 4.70e8, "maxPsdDbmPerBw": -56.8 }, "point": { "freqHz": 5.18e8, "maxPsdDbmPerBw": -56.8 }, "point": { "freqHz": 5.18e8, "maxPsdDbmPerBw": 30.0 }, "point": { "freqHz": 5.24e8, "maxPsdDbmPerBw": 30.0 }, "point": { "freqHz": 5.24e8, "maxPsdDbmPerBw": 36.0 }, "point": { "freqHz": 5.30e8, "maxPsdDbmPerBw": 36.0 }, "point": { "freqHz": 5.30e8, "maxPsdDbmPerBw": -56.8 }, "point": { "freqHz": 6.98e8, "maxPsdDbmPerBw": -56.8 } } This example explicitly specifies the power levels in the unavailable frequ= ency ranges. This example also shows that it's possible to encode "square edges" by havi= ng two points using the same frequency, but does allow for "slanted edges" for mor= e gentle roll-offs. -- -vince _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws -- -vince --_000_CE4D254F21396paulmarvellcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Thanks everyone.

Here's a more refined description of Option 2, based on= the comments.

- A spectrum profile provides the maximum permissi= ble power levels across a range of frequencies, where power levels are expr= essed as maximum power spectral densities over a specified bandwidth
<= div>
- When regulations have requirements at multiple bandwid= ths (e.g., Ofcom, ETSI), there would be a spectrum profile for each bandwid= th. The device emissions must be bounded by all the profiles (logical AND).=

- The spectrum profile is= expressed in terms of an "Ordered List" of (freqHz, psd) pairs
  - The points must be ordered in non-decreasing "freqHz= " value
  - Two consecutive points may have the same &q= uot;freqHz" to represent a "step function"
  = - Three or more points may NOT share the same "freqHz" value
     = ;  - There must be two or more points with different "freqHz"= ; values
=85

Should we adopt th= is more general encoding over the "channelized" encoding in Draft= 06?

=
Yes.  Seems like a significant improvement!

<= div>Paul



-vince
<= br>
On Fri, Aug 30, 2013 at 12:43 PM, Andy Le= e <tvfool@google.co= m> wrote:
=

On Thu, Aug = 29, 2013 at 1:33 PM, Harasty, Daniel J <dharasty@appcomsci.com> wrote:

How to Indicate =93Unavailable=94
&n= bsp;
There are a few options to indicate that a= subband is =93unavailable=94.
1)    =   The spec could state a value that means =93unavailable=94, such as -100, -1000= .0, or -56.8.
2)    &nb= sp; The spec could not state that value, and the Database could choose an arbitrar= y small number at its discretion.
3) &= nbsp;    The spec could state that the JSON value null means =93unavailable=94, or a reserved string such as =93-Inf=94

In the case of Ofcom whi= te space rules, I believe that a power level will be computed for every cha= nnel, albeit very low on some channels.
In the case of the FCC, there are also sp= ecific levels specified for OOB white space emissions.

For Industry Canada, the F= CC, and probably everywhere, there are also generalized limits on unintende= d EM emissions (e.g., IC "RSS-Gen" and FCC "Part 15" ru= les).  This should make it possible to specify a theoretical power &qu= ot;floor" without having to resort to weirdness like "-Inf" or "null" va= lues.  It would be much better to fill in real values based on actual = rules from the regulator.


Andy Lee |  Google Inc. |  tvfool@google.= com |  408-230-0522


<= div>
On Thu, Aug 29, 2013 at 3:= 30 PM, Kalle Kuismanen <k= alle.kuismanen@fairspectrum.com> wrote:
=
Hi All,

I haven't participated in the discussion much, but I ju= st had to solve this very issue about a week ago so here a my two cents:

on the issue of "-Inf" or null. We've also= used in our paws and other protocol implementation "-Inf" as ind= ication of channel being unavailable, but problem is that it's somewhat mis= leading. For example if a channel is "usable" only above 20 dBm a= nd we calculate maximum transmission to be 19 dBm it is bit silly to send -Inf. = Null value is even more misleading, because it usually indicates that we do= n't know what the value is, which in this case probably would mean an imple= mentation error in the calculation code.

Then of course considering the implementati= on. I tried to use in our paws implementation "-Inf", but of cour= se Javascript doesn't recognize that string  as a number, so it causes= a type casting problem i.e. sometimes the value is a number and sometimes a string. Which of course led to first our server not validating the JSON = against the PAWS schema and then when I by passed that (bad thing, but I wa= s in a rush) our test client side validation failed also.

See below how I decided it should be solved, but in the end, becaus= e didn't want to burden the device side implementers I just dropped the cha= nnels that couldn't be used from the array.

On the= client side or device side the JSON needs to be checked for the special va= lue or a simple field will suffice. Mutable nature of JSON makes it easy.

On client side the code would check in Javascript i= n node.js:

  =   { "freqHz": 4.70e8, "unavailable": true}, <= /font>
    { "= ;freqHz": 5.18e8, "unavailable": true},
    { "freqHz": = 5.18e8, "maxPsdDbmPerBw": 30.0 },
    { "freqHz": 5.24e8, "ma= xPsdDbmPerBw": 30.0 },
];
var b= =3D "";
for(var f in a)
    {<= /div>
    if(a[f]["= unavailable"]!=3D=3Dtrue) 
        b +=3D a[f].freqHz+&quo= t;:"+a[f].maxPsdDbmPerBw+"\n";
    }

process.stdout.write( b );

This= is not so different from using "-Inf" or "null" implem= entation.

var a =3D [
    { "freqHz": 5.18e8, "maxPsdDbmPerBw": = "-Inf"},
&n= bsp;   { "freqHz": 5.18e8, "maxPsdDbmPerBw": 30.0 = },
    { &q= uot;freqHz": 5.24e8, "maxPsdDbmPerBw": 30.0 },
<= /div>
];
var b =3D "";

for(var f in a)
    {
    if(a[f]["maxPsdDbmPerBw"]!=3D=3D"-Inf&qu= ot;)
    &n= bsp;   b +=3D a[f].freqHz+":"+a[f].maxPsdDbmPerB= w+"\n";
    }
process.stdout.write( b );

Bot= h cases usually just do one comparison. But as I said first version preserv= es type of max= PsdDbmPerBw other does not. Both cost about the same on the wire. 

But of course this is just a suggestion. JSON is very mall= eable.

Cheers,
Kalle Kuismanen
=
FairSpectrum


On Thu, Aug 29, 2013 at 11:33 PM, Harasty, Danie= l J <dharasty@appcomsci.com> wrote:
=

 

 

Regarding option= 2, I have the following comments.  (Some may apply to option 1, also.= )

 <= /p>

Ordering Matters

=

I think the= spec should require that the =93points=94 be in frequency-increasing order= of =93freqHz=94 value.  (The need is obvious, so let=92s state it as = a requirement.)

 <= u>

Two =93points=94 may have the same = =93freqHz=94 value; their order is significant, too.  (For example, th= e first four points in Vince=92s example constitute a =93step function=94.&= nbsp; However, if points #2 and #3 were swapped, it would indicate a =93sawtooth=94 spect= ral mask.)

 

Three (or more) =93points=94 may NOT share= a =93freqHz=94 value.

=  

Should be an Array

 

= I think the term =93point=94 is rather vague, an repeated= ly re-using it in a single object can=92t be kosher. 

 

Thus, I propose this structure be an array of object= s:

 =

[

  = ;  { "freqHz": 5.18e8, "maxPsdDbmPerBw": -56.8 },<= u>

    { "fre= qHz": 5.18e8, "maxPsdDbmPerBw": 30.0 },=

    { "freqHz": 5.24e8, &= quot;maxPsdDbmPerBw": 30.0 },

   .

 &n= bsp; .

   .

]

 

How to Indi= cate =93Unavailable=94

=  

There are a few options to= indicate that a subband is =93unavailable=94.

<= u>1)      The spec could state a value = that means =93unavailable=94, such as -100, -1000.0, or -56.8.

2)      The spec could not state that= value, and the Database could choose an arbitrary small number at its disc= retion.

3)   =    The spec could state that the= JSON value null means =93unavailabl= e=94, or a reserved string such as =93-Inf=94

 

I rathe= r prefer option 3.  If we use a reserved string, I prefer =93-Inf=94 i= n particular as it is an IEEE standard for negative infinity, and many prog= ramming languages support interpreting =93-Inf=94 as a parsable string resulting in a valid IEEE flo= at.

 

[

&n= bsp;   { "freqHz": 4.70e8, "maxPsdDbmPerBw": =  null},

   = ; { "freqHz": 5.18e8, "maxPsdDbmPerBw": null },<= u>

    { "freqH= z": 5.18e8, "maxPsdDbmPerBw": 30.0 },

    { "freqHz": 5.24e= 8, "maxPsdDbmPerBw": 30.0 },

]

 

or

 

[<= /span>

    { "freqHz": 4.7= 0e8, "maxPsdDbmPerBw": =93-Inf=94},

    { "freqHz": 5.18e8, "maxP= sdDbmPerBw": =93-Inf=94},

    { "freqHz": 5.18e8, "maxPsdDbmPerB= w": 30.0 },

 &= nbsp;  { "freqHz": 5.24e8, "maxPsdDbmPerBw": 30.0 = },

]

<= p> 

=  

= From:= paws-bounces@= ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Vincent Chen
Sent: Sunday, August 25, 2013 6:= 40 PM
To: paws= @ietf.org
Subject: [paws] Encoding of spectrum profile=

 

A= ll,

 

As= was brought up before (and at) the F2F, the current encoding for a spectru= m profile

has a "channelized" view= :

 - List of (startHz, stopHz, power)

 - Has no ability to specify power level= in "unavailable" ranges

&n= bsp;

Example:

 = {

    "point": { "= startHz": 5.18e8, "stopHz": 5.24e8, "maxPsdDbmPerBw&quo= t;: 30.0 },

    "point":= { "startHz": 5.24e8, "stopHz": 5.30e8, "maxPsdDbm= PerBw": 36.0 },

  }<= /p>

 

Question: Should we = use a more flexible encoding?

 <= u>

There were two proposals made on the list:

  - Option 1: List of (startHz, startPower, sto= pHz, stopPower)

  - Option 2: Ordered l= ist of (freqHz, power)

 <= /p>

At the F2F, we agreed that Option 2 was the more general f= orm.

 

E= xample:

  {

    "point": { "freqHz": 4.70e8, "ma= xPsdDbmPerBw": -56.8 },

    &= quot;point": { "freqHz": 5.18e8, "maxPsdDbmPerBw":= -56.8 },

    "point": {= "freqHz": 5.18e8, "maxPsdDbmPerBw": 30.0 },<= /u>

    "point": { "freqHz":= 5.24e8, "maxPsdDbmPerBw": 30.0 },

    "point": { "freqHz": 5.24e8, "maxPs= dDbmPerBw": 36.0 },

    "= ;point": { "freqHz": 5.30e8, "maxPsdDbmPerBw": 36.= 0 },

    "point": { &quo= t;freqHz": 5.30e8, "maxPsdDbmPerBw": -56.8 },<= /p>

    "point": { "freqHz": 6.9= 8e8, "maxPsdDbmPerBw": -56.8 }

&nb= sp; }


This example explicitly specifies the power levels in the unavailable= frequency ranges.

 

<= /div>

This example also shows that it's possible to encode "squ= are edges" by having two

points using t= he same frequency, but does allow for "slanted edges" for more ge= ntle roll-offs.

 

--
-vince


_______________________________________________
paws mailing list
paw= s@ietf.org
https://www.ietf.org/mailman/listinfo/paws



_______________________________________________
paws mailing list
paw= s@ietf.org
https://www.ietf.org/mailman/listinfo/paws



_______________________________________________
paws mailing list
paws@ietf.org
= ht= tps://www.ietf.org/mailman/listinfo/paws


=

--
-vince


= --_000_CE4D254F21396paulmarvellcom_-- From d.joslyn@spectrumbridge.com Thu Sep 5 07:36:05 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF0FF11E81A4 for ; Thu, 5 Sep 2013 07:36:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ys+1CI1P5zMj for ; Thu, 5 Sep 2013 07:36:01 -0700 (PDT) Received: from mail.spectrumbridge.com (mail.spectrumbridge.com [64.132.248.82]) by ietfa.amsl.com (Postfix) with ESMTP id 8145611E80EC for ; Thu, 5 Sep 2013 07:36:00 -0700 (PDT) Received: from shelby.sbi.com ([127.0.0.1]) by shelby ([127.0.0.1]) with mapi; Thu, 5 Sep 2013 10:35:59 -0400 From: Don Joslyn To: Vincent Chen , Michael Head Date: Thu, 5 Sep 2013 10:35:58 -0400 Thread-Topic: [paws] Spectrum_use_notify as pure notification Thread-Index: Ac6ow2L1SmbhQbgQSbWhqH35s4WSUQBgGqcw Message-ID: <8375F6DAEFB09F48815203F1FE23B79734B36464ED@shelby> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_8375F6DAEFB09F48815203F1FE23B79734B36464EDshelby_" MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] Spectrum_use_notify as pure notification X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 14:36:05 -0000 --_000_8375F6DAEFB09F48815203F1FE23B79734B36464EDshelby_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I vote for option #1, keep it the way it is currently defined in Draft 06. = The main justification is the current notification message flow defined in = Draft 06 can be easily extended to include additional parameters in the rep= ly sent back to the radio. If we change it to a pure JSON notification, the= n we lose this capability. Thanks, Don From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Vin= cent Chen Sent: Tuesday, September 3, 2013 12:33 PM To: Michael Head Cc: paws@ietf.org Subject: Re: [paws] Spectrum_use_notify as pure notification I suppose it does not make sense to change the spec to using JSON-RPC notif= ication, then allow for deviation. So, could we see if there is a consensus for one of the following? Option 1: No change to Draft 06: notifySpectrumUse is a JSON-RPC request, w= ith a response that contains only the message type and version: { "jsonrpc": "2.0", "result": { "type": "SPECTRUM_USE_RESP", "version": "1.0" }, "id": "xxxxxxx" } Option 2: Change notifySpectrumUse to be a pure JSON-RPC notification that = will not have a JSON-RPC response (i.e., empty HTTP response body). Thanks. -vince On Sat, Aug 24, 2013 at 4:19 PM, Michael Head > wrote: If spectrum_use_notify is a pure JSON-RPC notification, this could be a pro= blem for our implementation. We can't easily guarantee that the there would be no JSON-RPC response body= for this method, but I believe JSON-RPC requires this for notification cal= ls. If clients would ignore any body included in the response, then it would be= fine for us, but I suppose the specification would need to make special no= te of that deviation from the JSON-RPC spec. Thanks, -- mike -- ---------------------------------- Michael R Head > http://www.cs.binghamton.edu/~mike +1-201-BLISTER _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws -- -vince --_000_8375F6DAEFB09F48815203F1FE23B79734B36464EDshelby_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I vote fo= r option #1, keep it the way it is currently defined in Draft 06. The main = justification is the current notification message flow defined in Draft 06 = can be easily extended to include additional parameters in the reply sent b= ack to the radio. If we change it to a pure JSON notification, then we lose= this capability.

&nb= sp;

Thanks,

Don

 

From: paws-bounces@i= etf.org [mailto:paws-bounces@ietf.org] On Behalf Of Vincent Chen
= Sent: Tuesday, September 3, 2013 12:33 PM
To: Michael Head=
Cc: paws@ietf.org
Subject: Re: [paws] Spectrum_use_not= ify as pure notification

&nb= sp;

 

I suppose it does not make sense to change the spec t= o using JSON-RPC notification, then allow for deviation.

 

So, could we see if there is a consensus for one of the following?

 

Option 1: No change to Draft 06: notifySpectrumUse is= a JSON-RPC request, with a response that contains only the message type an= d version:

 <= /p>

{

  "jsonrpc": "2.0",

  "result": {

    "type": "SPECTRUM_USE_= RESP",

    &qu= ot;version": "1.0"

  },

  "i= d": "xxxxxxx"

= }

 

=

Option 2: Change notifySpectrumUse to be a pure J= SON-RPC notification that will not have a JSON-RPC response (i.e., empty HT= TP response body).

 = ;

Thanks.

 

= -vince 

 

On Sat,= Aug 24, 2013 at 4:19 PM, Michael Head <mrhead@google.com> wrote:

=

= If spectrum_use_notify is a pure JSON-RPC notification, this could be a pro= blem for our implementation.

 

We can't easily guarantee that the there = would be no JSON-RPC response body for this method, but I believe JSON-RPC = requires this for notification calls.

 

If clients would ignore any body= included in the response, then it would be fine for us, but I suppose the = specification would need to make special note of that deviation from the JS= ON-RPC spec.

&nbs= p;

Thanks,

-- mike

&= nbsp;

--

-----------= -----------------------

Michael R Head <mrhead@google.com>= ;

http://www.c= s.binghamton.edu/~mike<= /span>

+1-201-BLISTER<= o:p>


_______________________________________________
paws= mailing list
paws@ietf.org
https:= //www.ietf.org/mailman/listinfo/paws



&n= bsp;

--
-vince

= --_000_8375F6DAEFB09F48815203F1FE23B79734B36464EDshelby_-- From dharasty@appcomsci.com Thu Sep 5 12:58:28 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D242C21F9DF0 for ; Thu, 5 Sep 2013 12:58:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5wikoCKfmMTh for ; Thu, 5 Sep 2013 12:58:24 -0700 (PDT) Received: from thumper.appcomsci.com (thumper.appcomsci.com [205.132.0.196]) by ietfa.amsl.com (Postfix) with ESMTP id CDAAD21F9C33 for ; Thu, 5 Sep 2013 12:58:23 -0700 (PDT) Received: from bambi.appcomsci.com (bambi.appcomsci.com [192.4.5.54]) by thumper.appcomsci.com (8.14.2/8.14.2) with ESMTP id r85JwKnh011867 for ; Thu, 5 Sep 2013 15:58:22 -0400 (EDT) Received: from brg-ats-exhb1.ats.atsinnovate.com (exch.appcomsci.com [192.4.5.112]) by bambi.appcomsci.com (8.14.4/8.13.4) with ESMTP id r85JwKo0005375 for ; Thu, 5 Sep 2013 15:58:20 -0400 Received: from RRC-ATS-EXMB2.ats.atsinnovate.com ([2002:c004:56a::c004:56a]) by brg-ats-exhb1.ats.atsinnovate.com ([2002:c004:570::c004:570]) with mapi; Thu, 5 Sep 2013 15:58:19 -0400 From: "Harasty, Daniel J" To: "paws@ietf.org" Thread-Topic: [paws] Spectrum_use_notify as pure notification Thread-Index: AQHOoSB3lcCDmdAtqEWJgf7bxsvHOZm0hzGAgAMEFACAAAy48A== Date: Thu, 5 Sep 2013 19:58:19 +0000 Message-ID: References: <8375F6DAEFB09F48815203F1FE23B79734B36464ED@shelby> In-Reply-To: <8375F6DAEFB09F48815203F1FE23B79734B36464ED@shelby> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_EC510C021D06A34C92F5A5A488B5290B0CF17151rrcatsexmb2atsa_" MIME-Version: 1.0 Subject: Re: [paws] Spectrum_use_notify as pure notification X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 19:58:29 -0000 --_000_EC510C021D06A34C92F5A5A488B5290B0CF17151rrcatsexmb2atsa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I do prefer Option 2 - after all, I proposed it. However I admit there is no harm in keeping the regular JSON-RPC response a= round, as per Draft 06 - even though it is semantically empty. If anyone else is strongly in favor of "Option 2", please speak up, as I be= lieve Vince is going to make an editorial call on this one soon. Dan Harasty From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Don= Joslyn Sent: Thursday, September 05, 2013 10:36 AM To: Vincent Chen; Michael Head Cc: paws@ietf.org Subject: Re: [paws] Spectrum_use_notify as pure notification I vote for option #1, keep it the way it is currently defined in Draft 06. = The main justification is the current notification message flow defined in = Draft 06 can be easily extended to include additional parameters in the rep= ly sent back to the radio. If we change it to a pure JSON notification, the= n we lose this capability. Thanks, Don From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of Vincent Chen Sent: Tuesday, September 3, 2013 12:33 PM To: Michael Head Cc: paws@ietf.org Subject: Re: [paws] Spectrum_use_notify as pure notification I suppose it does not make sense to change the spec to using JSON-RPC notif= ication, then allow for deviation. So, could we see if there is a consensus for one of the following? Option 1: No change to Draft 06: notifySpectrumUse is a JSON-RPC request, w= ith a response that contains only the message type and version: { "jsonrpc": "2.0", "result": { "type": "SPECTRUM_USE_RESP", "version": "1.0" }, "id": "xxxxxxx" } Option 2: Change notifySpectrumUse to be a pure JSON-RPC notification that = will not have a JSON-RPC response (i.e., empty HTTP response body). Thanks. -vince On Sat, Aug 24, 2013 at 4:19 PM, Michael Head > wrote: If spectrum_use_notify is a pure JSON-RPC notification, this could be a pro= blem for our implementation. We can't easily guarantee that the there would be no JSON-RPC response body= for this method, but I believe JSON-RPC requires this for notification cal= ls. If clients would ignore any body included in the response, then it would be= fine for us, but I suppose the specification would need to make special no= te of that deviation from the JSON-RPC spec. Thanks, -- mike -- ---------------------------------- Michael R Head > http://www.cs.binghamton.edu/~mike +1-201-BLISTER _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws -- -vince --_000_EC510C021D06A34C92F5A5A488B5290B0CF17151rrcatsexmb2atsa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I do pref= er Option 2 – after all, I proposed it.

 

However I admit there is no harm in keeping the regular JSON-RPC response = around, as per Draft 06 – even though it is semantically empty.<= /o:p>

 

If anyone else is strongly in favor of “Opti= on 2”, please speak up, as I believe Vince is going to make an editor= ial call on this one soon.

 

Dan Harasty

 

 

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On= Behalf Of Don Joslyn
Sent: Thursday, September 05, 2013 10:3= 6 AM
To: Vincent Chen; Michael Head
Cc: paws@ietf.orgSubject: Re: [paws] Spectrum_use_notify as pure notification<= /o:p>

 

I vote for option #1, keep it the way it is currentl= y defined in Draft 06. The main justification is the current notification m= essage flow defined in Draft 06 can be easily extended to include additiona= l parameters in the reply sent back to the radio. If we change it to a pure= JSON notification, then we lose this capability.

 

Thanks,

Don

 

From: paws-bounces@iet= f.org [mailto:paws-bounces@iet= f.org] On Behalf Of Vincent Chen
Sent: Tuesday, Septem= ber 3, 2013 12:33 PM
To: Michael Head
Cc: paws@ietf.org
Subject: Re: [paws] Spectru= m_use_notify as pure notification

 

 

<= /div>

I suppose it does not make sense to change t= he spec to using JSON-RPC notification, then allow for deviation.

 

So, could we see if there is a consensus for one of the foll= owing?

 

<= /div>

Option 1: No change to Draft 06: notifySpect= rumUse is a JSON-RPC request, with a response that contains only the messag= e type and version:

&nbs= p;

{

  "jsonrpc": "2.0",

  "result": {

    "type": "SPEC= TRUM_USE_RESP",

  &= nbsp; "version": "1.0"

  },

 = ; "id": "xxxxxxx"

}

 <= /p>

Option 2: Change notifySpectrumUse to be= a pure JSON-RPC notification that will not have a JSON-RPC response (i.e.,= empty HTTP response body).

<= o:p> 

Thanks.

<= /div>

 

-vince 

 

On Sat, Aug 24, 2013 at 4:19 PM, Michael Head <mrhead@google.com> wrote:=

If spectrum_use_notify is a pure JSON-RPC notification, this could= be a problem for our implementation.

 

We can't easily guarantee that t= he there would be no JSON-RPC response body for this method, but I believe = JSON-RPC requires this for notification calls.

<= div>

 

If clients would ignore= any body included in the response, then it would be fine for us, but I sup= pose the specification would need to make special note of that deviation fr= om the JSON-RPC spec.

=  

Thanks,

-- mike

 

--

--= --------------------------------

Michael R Head= <mrhead@google.c= om>

=

+1-201-BLISTER


_____________________________________________= __
paws mailing list
paws@ietf.org
https://www.ietf.org/mailman/listinfo/paws



 

--
-vince

= --_000_EC510C021D06A34C92F5A5A488B5290B0CF17151rrcatsexmb2atsa_-- From Gabor.Bajko@nokia.com Thu Sep 5 18:41:51 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 866EA11E8129 for ; Thu, 5 Sep 2013 18:41:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TpChX+kunDe0 for ; Thu, 5 Sep 2013 18:41:46 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 3C3B711E8212 for ; Thu, 5 Sep 2013 18:41:36 -0700 (PDT) Received: from smtp.mgd.nokia.com ([65.54.30.59]) by mgw-sa01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r861cBNI013119 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Fri, 6 Sep 2013 04:38:13 +0300 Received: from 008-AM1MPN1-006.mgdnok.nokia.com ([169.254.6.201]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi id 14.03.0136.001; Fri, 6 Sep 2013 01:38:11 +0000 From: To: , Thread-Topic: [paws] Spectrum_use_notify as pure notification Thread-Index: AQHOoSB0Lh/NInbBt0yNw7lLwOb8EZm0RCKAgAMEFQCAAFoQgIAAXlSw Date: Fri, 6 Sep 2013 01:38:10 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E4760531513E@008-AM1MPN1-006.mgdnok.nokia.com> References: <8375F6DAEFB09F48815203F1FE23B79734B36464ED@shelby> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [69.181.65.212] Content-Type: multipart/alternative; boundary="_000_1ECAFF543A2FED4EA2BEB6CACE08E4760531513E008AM1MPN1006mg_" MIME-Version: 1.0 X-Nokia-AV: Clean Subject: Re: [paws] Spectrum_use_notify as pure notification X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 01:41:51 -0000 --_000_1ECAFF543A2FED4EA2BEB6CACE08E4760531513E008AM1MPN1006mg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As an individual (and not as chair), I also prefer option #1, for the exact= same reasons as Don. And yes, we'll need to conclude on this soon, so anyone with an opinion, pl= ease speak up. - Gabor From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext= Harasty, Daniel J Sent: Thursday, September 05, 2013 12:58 PM To: paws@ietf.org Subject: Re: [paws] Spectrum_use_notify as pure notification I do prefer Option 2 - after all, I proposed it. However I admit there is no harm in keeping the regular JSON-RPC response a= round, as per Draft 06 - even though it is semantically empty. If anyone else is strongly in favor of "Option 2", please speak up, as I be= lieve Vince is going to make an editorial call on this one soon. Dan Harasty From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of Don Joslyn Sent: Thursday, September 05, 2013 10:36 AM To: Vincent Chen; Michael Head Cc: paws@ietf.org Subject: Re: [paws] Spectrum_use_notify as pure notification I vote for option #1, keep it the way it is currently defined in Draft 06. = The main justification is the current notification message flow defined in = Draft 06 can be easily extended to include additional parameters in the rep= ly sent back to the radio. If we change it to a pure JSON notification, the= n we lose this capability. Thanks, Don From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of Vincent Chen Sent: Tuesday, September 3, 2013 12:33 PM To: Michael Head Cc: paws@ietf.org Subject: Re: [paws] Spectrum_use_notify as pure notification I suppose it does not make sense to change the spec to using JSON-RPC notif= ication, then allow for deviation. So, could we see if there is a consensus for one of the following? Option 1: No change to Draft 06: notifySpectrumUse is a JSON-RPC request, w= ith a response that contains only the message type and version: { "jsonrpc": "2.0", "result": { "type": "SPECTRUM_USE_RESP", "version": "1.0" }, "id": "xxxxxxx" } Option 2: Change notifySpectrumUse to be a pure JSON-RPC notification that = will not have a JSON-RPC response (i.e., empty HTTP response body). Thanks. -vince On Sat, Aug 24, 2013 at 4:19 PM, Michael Head > wrote: If spectrum_use_notify is a pure JSON-RPC notification, this could be a pro= blem for our implementation. We can't easily guarantee that the there would be no JSON-RPC response body= for this method, but I believe JSON-RPC requires this for notification cal= ls. If clients would ignore any body included in the response, then it would be= fine for us, but I suppose the specification would need to make special no= te of that deviation from the JSON-RPC spec. Thanks, -- mike -- ---------------------------------- Michael R Head > http://www.cs.binghamton.edu/~mike +1-201-BLISTER _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws -- -vince --_000_1ECAFF543A2FED4EA2BEB6CACE08E4760531513E008AM1MPN1006mg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

As an individual (and not= as chair), I also prefer option #1, for the exact same reasons as Don.

And yes, we’ll need= to conclude on this soon, so anyone with an opinion, please speak up.=

 <= /p>

- =          Gabor<= /span>

 <= /p>

From: paws-bou= nces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext Harasty, Daniel J
Sent: Thursday, September 05, 2013 12:58 PM
To: paws@ietf.org
Subject: Re: [paws] Spectrum_use_notify as pure notification

 

I do prefer Option 2 R= 11; after all, I proposed it.

 <= /p>

However I admit there is = no harm in keeping the regular JSON-RPC response around, as per Draft 06 &#= 8211; even though it is semantically empty.

 <= /p>

If anyone else is strongl= y in favor of “Option 2”, please speak up, as I believe Vince i= s going to make an editorial call on this one soon.

 <= /p>

Dan Harasty

 <= /p>

 <= /p>

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Don Joslyn
Sent: Thursday, September 05, 2013 10:36 AM
To: Vincent Chen; Michael Head
Cc: paws@ietf.org
Subject: Re: [paws] Spectrum_use_notify as pure notification

 

I vote for option #1, kee= p it the way it is currently defined in Draft 06. The main justification is= the current notification message flow defined in Draft 06 can be easily extended to include additional parameters in the reply se= nt back to the radio. If we change it to a pure JSON notification, then we = lose this capability.

 <= /p>

Thanks,=

Don

 <= /p>

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Vincent Chen
Sent: Tuesday, September 3, 2013 12:33 PM
To: Michael Head
Cc: paws@ietf.org
Subject: Re: [paws] Spectrum_use_notify as pure notification

 

 

I suppose it does not make sense to change the spec = to using JSON-RPC notification, then allow for deviation.

 

So, could we see if there is a consensus for one of = the following?

 

Option 1: No change to Draft 06: notifySpectrumUse i= s a JSON-RPC request, with a response that contains only the message type a= nd version:

 

{

  "jsonrpc": "2.0",

  "result": {

    "type": "SPECTRUM_USE_R= ESP",

    "version": "1.0"

  },

  "id": "xxxxxxx"

}

 

Option 2: Change notifySpectrumUse to be a pure JSON= -RPC notification that will not have a JSON-RPC response (i.e., empty HTTP = response body).

 

Thanks.

 

-vince 

 

On Sat, Aug 24, 2013 at 4:19 PM, Michael Head <mrhead@google.com&= gt; wrote:

If spectrum_use_notify is a pure JSON-RPC notification, th= is could be a problem for our implementation.

 

We can't easily guarantee that the there would be no JSON-= RPC response body for this method, but I believe JSON-RPC requires this for= notification calls.

 

If clients would ignore any body included in the response,= then it would be fine for us, but I suppose the specification would need t= o make special note of that deviation from the JSON-RPC spec.

 

Thanks,

-- mike

 

--

----------------------------------

Michael R Head <mrhead@google.com>=

+1-201-BLISTER<= /o:p>


_______________________________________________
paws mailing list
paws@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/paws



 

--
-vince

--_000_1ECAFF543A2FED4EA2BEB6CACE08E4760531513E008AM1MPN1006mg_-- From nbravin@earthlink.net Thu Sep 5 18:47:42 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B987211E8217 for ; Thu, 5 Sep 2013 18:47:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p8KDP10aXD85 for ; Thu, 5 Sep 2013 18:47:38 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by ietfa.amsl.com (Postfix) with ESMTP id C1E9C11E8212 for ; Thu, 5 Sep 2013 18:47:37 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=rjnK5BVHOY7Nn6AFianEHvftxUUuRkOffj0NCno5eeZPstswghbnAGpXsNa4XldJ; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Message-Id:References:To:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [76.178.247.187] (helo=[10.0.1.7]) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1VHl90-0007Q4-LE; Thu, 05 Sep 2013 21:47:30 -0400 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_C6BEA63B-34D8-4D44-B479-AA934D5190AD" From: Nancy Bravin In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E4760531513E@008-AM1MPN1-006.mgdnok.nokia.com> Date: Thu, 5 Sep 2013 21:47:29 -0400 Message-Id: References: <8375F6DAEFB09F48815203F1FE23B79734B36464ED@shelby> <1ECAFF543A2FED4EA2BEB6CACE08E4760531513E@008-AM1MPN1-006.mgdnok.nokia.com> To: X-Mailer: Apple Mail (2.1283) X-ELNK-Trace: 9a7a58baebc0701cd780f4a490ca6956d5d4673fe7faad868a718c5e43b426fe2c0261f9e6ab0412350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 76.178.247.187 Cc: paws@ietf.org Subject: Re: [paws] Spectrum_use_notify as pure notification X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 01:47:43 -0000 --Apple-Mail=_C6BEA63B-34D8-4D44-B479-AA934D5190AD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I also prefer option # 1 for the same reasons as Gabor and Don. Nancy On Sep 5, 2013, at 9:38 PM, wrote: > As an individual (and not as chair), I also prefer option #1, for the = exact same reasons as Don. > And yes, we=92ll need to conclude on this soon, so anyone with an = opinion, please speak up. > =20 > - Gabor > =20 > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf = Of ext Harasty, Daniel J > Sent: Thursday, September 05, 2013 12:58 PM > To: paws@ietf.org > Subject: Re: [paws] Spectrum_use_notify as pure notification > =20 > I do prefer Option 2 =96 after all, I proposed it. > =20 > However I admit there is no harm in keeping the regular JSON-RPC = response around, as per Draft 06 =96 even though it is semantically = empty. > =20 > If anyone else is strongly in favor of =93Option 2=94, please speak = up, as I believe Vince is going to make an editorial call on this one = soon. > =20 > Dan Harasty > =20 > =20 > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf = Of Don Joslyn > Sent: Thursday, September 05, 2013 10:36 AM > To: Vincent Chen; Michael Head > Cc: paws@ietf.org > Subject: Re: [paws] Spectrum_use_notify as pure notification > =20 > I vote for option #1, keep it the way it is currently defined in Draft = 06. The main justification is the current notification message flow = defined in Draft 06 can be easily extended to include additional = parameters in the reply sent back to the radio. If we change it to a = pure JSON notification, then we lose this capability. > =20 > Thanks, > Don > =20 > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf = Of Vincent Chen > Sent: Tuesday, September 3, 2013 12:33 PM > To: Michael Head > Cc: paws@ietf.org > Subject: Re: [paws] Spectrum_use_notify as pure notification > =20 > =20 > I suppose it does not make sense to change the spec to using JSON-RPC = notification, then allow for deviation. > =20 > So, could we see if there is a consensus for one of the following? > =20 > Option 1: No change to Draft 06: notifySpectrumUse is a JSON-RPC = request, with a response that contains only the message type and = version: > =20 > { > "jsonrpc": "2.0", > "result": { > "type": "SPECTRUM_USE_RESP", > "version": "1.0" > }, > "id": "xxxxxxx" > } > =20 > Option 2: Change notifySpectrumUse to be a pure JSON-RPC notification = that will not have a JSON-RPC response (i.e., empty HTTP response body). > =20 > Thanks. > =20 > -vince=20 > =20 >=20 > On Sat, Aug 24, 2013 at 4:19 PM, Michael Head = wrote: > If spectrum_use_notify is a pure JSON-RPC notification, this could be = a problem for our implementation. > =20 > We can't easily guarantee that the there would be no JSON-RPC response = body for this method, but I believe JSON-RPC requires this for = notification calls. > =20 > If clients would ignore any body included in the response, then it = would be fine for us, but I suppose the specification would need to make = special note of that deviation from the JSON-RPC spec. > =20 > Thanks, > -- mike > =20 > -- > ---------------------------------- > Michael R Head > http://www.cs.binghamton.edu/~mike > +1-201-BLISTER >=20 > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws >=20 >=20 >=20 > =20 > --=20 > -vince > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws --Apple-Mail=_C6BEA63B-34D8-4D44-B479-AA934D5190AD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I also prefer option # 1 for the same reasons as = Gabor and Don.

Nancy
On Sep 5, 2013, at = 9:38 PM, <Gabor.Bajko@nokia.com> = wrote:

As an = individual (and not as chair), I also prefer option #1, for the exact = same reasons as Don.
And yes, we=92ll need to conclude on this soon, so = anyone with an opinion, please speak up.
- Gabor
 
From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org= ] On Behalf Of ext Harasty, Daniel = J
Sent: Thursday, September 05, = 2013 12:58 PM
To: paws@ietf.org
Subject: Re: [paws] = Spectrum_use_notify as pure = notification
I do prefer = Option 2 =96 after all, I proposed it.
If = anyone else is strongly in favor of =93Option 2=94, please speak up, as = I believe Vince is going to make an editorial call on this one = soon.
Dan = Harasty
From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Don = Joslyn
Sent: Thursday, September 05, = 2013 10:36 AM
To: Vincent Chen; Michael = Head
Cc: paws@ietf.org
Subject: Re: [paws] = Spectrum_use_notify as pure = notification
I vote for = option #1, keep it the way it is currently defined in Draft 06. The main = justification is the current notification message flow defined in Draft = 06 can be easily extended to include additional parameters in the reply = sent back to the radio. If we change it to a pure JSON notification, = then we lose this capability.
 paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Vincent = Chen
Sent: Tuesday, September 3, 2013 = 12:33 PM
To: Michael = Head
Cc: paws@ietf.org
Subject: Re: [paws] = Spectrum_use_notify as pure notification
 
 
I suppose it does not make sense to change the spec to = using JSON-RPC notification, then allow for = deviation.
So, could we see if there = is a consensus for one of the following?
 
Option 1: No change to Draft 06: notifySpectrumUse is a = JSON-RPC request, with a response that contains only the message type = and version:
  "jsonrpc": = "2.0",
  "result": = {
    "type": = "SPECTRUM_USE_RESP",
    = "version": "1.0"
  = },
  "id": = "xxxxxxx"
Option 2: Change = notifySpectrumUse to be a pure JSON-RPC notification that will not have = a JSON-RPC response (i.e., empty HTTP response = body).

paws@ietf.org


_______________________________________________
paws = mailing list
paws@ietf.org
To: Vincent Chen Thread-Topic: [paws] Encoding of spectrum profile Thread-Index: AQHOoeQCmU+qkDwvDUSLePEjGLDDY5msmYcAgAAgqoCAAWO2gIAIKfUAgAIaGoA= Date: Fri, 6 Sep 2013 08:29:51 +0000 Message-ID: <53F00E5CD8B2E34C81C0C89EB0B4FE732DE89725@wds-exc1.okna.nominet.org.uk> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.2.1] Content-Type: multipart/alternative; boundary="_000_53F00E5CD8B2E34C81C0C89EB0B4FE732DE89725wdsexc1oknanomi_" MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] Encoding of spectrum profile X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 08:30:42 -0000 --_000_53F00E5CD8B2E34C81C0C89EB0B4FE732DE89725wdsexc1oknanomi_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On 5 Sep 2013, at 01:23, Vincent Chen > wrote: - The encoding uses an array, for example (thanks for the catch, Dan!): [ { "freqHz": 4.70e8, "maxPsdDbmPerBw": -56.8 }, { "freqHz": 5.18e8, "maxPsdDbmPerBw": -56.8 }, { "freqHz": 5.18e8, "maxPsdDbmPerBw": 30.0 }, { "freqHz": 5.24e8, "maxPsdDbmPerBw": 30.0 }, { "freqHz": 5.24e8, "maxPsdDbmPerBw": 36.0 }, { "freqHz": 5.30e8, "maxPsdDbmPerBw": 36.0 }, { "freqHz": 5.30e8, "maxPsdDbmPerBw": -56.8 }, { "freqHz": 6.98e8, "maxPsdDbmPerBw": -56.8 } ] - Even for regulatory domains that do not compute a level for all channels,= there are still generalized (absolute) limits on unintended EM emissions, = so there should be no need to use special values, such as -inf, null, etc. = for indicating the "unavailable" ranges. Should we adopt this more general encoding over the "channelized" encoding = in Draft 06? I don't like it at all. The questions I raised about the "Bw" part of "maxPsdDbmPerBw" and the exac= t mechanism of how to encode multiple bandwidth PSDs are still unanswered. It *appears* that "Bw" is supposed to be the delta between the current entr= y and the previous entry? Not only does this result in a potential divisio= n-by-zero that has to be detected, it would seem that to encode the OFCOM/E= TSI rules that require a PSD over 100 kHz would require an entry (or in fac= t a pair of entries) for *every single 100 kHz subchannel* within the band. Also, I'm pretty certain that the OFCOM/ETSI model will actually result in = channels that simply cannot be used. We haven't seen the DTT sample data ye= t but previous conversations have strongly suggested that in certain square= s they will not permit any transmissions in certain channels. This simple = contiguous set of power vs frequency points cannot encode that. Ray --_000_53F00E5CD8B2E34C81C0C89EB0B4FE732DE89725wdsexc1oknanomi_ Content-Type: text/html; charset="Windows-1252" Content-ID: <8B641F8C9CFA8F41BD7DB285A46DB138@okna.nominet.org.uk> Content-Transfer-Encoding: quoted-printable


- The encoding uses an array, for example (thanks for the catch, Dan!)= :
 [
    { = "freqHz": 4.70e8, "maxPsdDbmPerBw": -56.8 },
    { = "freqHz": 5.18e8, "maxPsdDbmPerBw": -56.8 },
    { = "freqHz": 5.18e8, "maxPsdDbmPerBw": 30.0 },
    { = "freqHz": 5.24e8, "maxPsdDbmPerBw": 30.0 },
    { = "freqHz": 5.24e8, "maxPsdDbmPerBw": 36.0 },
    { = "freqHz": 5.30e8, "maxPsdDbmPerBw": 36.0 },
    { = "freqHz": 5.30e8, "maxPsdDbmPerBw": -56.8 },
    { = "freqHz": 6.98e8, "maxPsdDbmPerBw": -56.8 }
  ]

- Even for regul= atory domains that do not compute a level for all channels, there are still= generalized (absolute) limits on unintended EM emissions, so there should = be no need to use special values, such as -inf, null, etc. for indicating the "unavailable" ranges= .

Should we adopt this more general encoding over the "channelized&= quot; encoding in Draft 06?

I don't like it at all.

The questions I raised about the "Bw" part of "maxPsdDb= mPerBw" and the exact mechanism of how to encode multiple bandwidth PS= Ds are still unanswered.

It *appears* that "Bw" is supposed to be the delta between t= he current entry and the previous entry?  Not only does this result in= a potential division-by-zero that has to be detected, it would seem that t= o encode the OFCOM/ETSI rules that require a PSD over 100 kHz would require an entry (or in fact a pair of entries) for *ev= ery single 100 kHz subchannel* within the band.

Also, I'm pretty certain that the OFCOM/ETSI model will actually resul= t in channels that simply cannot be used. We haven't seen the DTT sample da= ta yet but previous conversations have strongly suggested that in certain s= quares they will not permit any transmissions in certain channels.  This simple contiguous set of pow= er vs frequency points cannot encode that.

Ray



--_000_53F00E5CD8B2E34C81C0C89EB0B4FE732DE89725wdsexc1oknanomi_-- From Ray.Bellis@nominet.org.uk Fri Sep 6 02:06:50 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDF7911E8124 for ; Fri, 6 Sep 2013 02:06:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zAHYZgpY6FEp for ; Fri, 6 Sep 2013 02:06:41 -0700 (PDT) Received: from mx2.nominet.org.uk (mx2.nominet.org.uk [213.248.242.49]) by ietfa.amsl.com (Postfix) with ESMTP id A1BE011E811D for ; Fri, 6 Sep 2013 02:06:40 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:From:To:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:x-originating-ip: Content-Type:Content-ID:Content-Transfer-Encoding: MIME-Version; b=5u13ctAOKFpuu4GjBGC1Kuu9xUZfxJLWMBmi2boF6DcjaHRtr/t6FT/b w8N0k0VMVi2/sJUA0JZb2jtZX9IoU0Wi/Sd9lI0k3KTiFlwstRBcBIZa3 tGmvC8v7EhND3tw; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1378458400; x=1409994400; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=5WW+V8ltLv9XCT1ukHRpGNMnHF6mD58eNZ8QjEm0+a8=; b=5Txb8IFEfkk89bebSYchslwc7bq8Dr7uqqw3BWa5IoDbYdLQ8neAzQ/+ ZoRt9wy1MvZyuk/7GHyOvHxQA2bIiSVKzP3hz8mT+M1TPWX6iPQCZwX8E Rzel8wPuNPbp+/t; X-IronPort-AV: E=Sophos;i="4.90,853,1371078000"; d="scan'208";a="2868136" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx2.nominet.org.uk with ESMTP; 06 Sep 2013 10:06:38 +0100 Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4%17]) with mapi id 14.02.0318.004; Fri, 6 Sep 2013 10:06:38 +0100 From: Ray Bellis To: "paws@ietf.org" Thread-Topic: [paws] Spectrum_use_notify as pure notification Thread-Index: AQHOoSBysURoAgE5Hkyi48RstUNe+Jm0M1+AgAMEFQCAAFoQgIAAXvQAgAACmoCAAHqxgA== Date: Fri, 6 Sep 2013 09:06:37 +0000 Message-ID: <53F00E5CD8B2E34C81C0C89EB0B4FE732DE899D9@wds-exc1.okna.nominet.org.uk> References: <8375F6DAEFB09F48815203F1FE23B79734B36464ED@shelby> <1ECAFF543A2FED4EA2BEB6CACE08E4760531513E@008-AM1MPN1-006.mgdnok.nokia.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.2.1] Content-Type: text/plain; charset="Windows-1252" Content-ID: <770404005105E241BE3CDF70C90CA5AE@okna.nominet.org.uk> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [paws] Spectrum_use_notify as pure notification X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 09:06:50 -0000 On 6 Sep 2013, at 02:47, Nancy Bravin wrote: > I also prefer option # 1 for the same reasons as Gabor and Don. +1 Ray From mrhead@google.com Fri Sep 6 08:01:09 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8323011E82C5 for ; Fri, 6 Sep 2013 08:01:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.093 X-Spam-Level: X-Spam-Status: No, score=-1.093 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z7X3Tb23R7XR for ; Fri, 6 Sep 2013 08:01:08 -0700 (PDT) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 7E8BD11E82B6 for ; Fri, 6 Sep 2013 08:01:07 -0700 (PDT) Received: by mail-ie0-f175.google.com with SMTP id u16so6725508iet.6 for ; Fri, 06 Sep 2013 08:01:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=R4z+dciA0sqBEogBLjf2kb4EMthSw/YgPp+BSAqoSxw=; b=i35SiSEVGe2ujiIU23CzzdB1pMzIj+W8CSE+5vv20QXJjbp8kbCJ8kaKeCw0r4jjNW UHrbwm1+4f8s5OVvA75Rpv5ziTYcoyKbQIZRh6KtG1RoacJpZ33s/Wg3gEXtabobBfs8 SpifpQYt3bCIqAZ+silVLOrIDGbPq8KfiJCz+KohQnvxVbJ0EvddbSZF7TbXPyH4X6Lx h16Vq9xnD7nDHX8FEIFca8TAQF8NG59bz0J96CIKUw1LmvMnd5q0unLJ0jx0zzM9qMgX 3ZcuFf6Uadev0Vvjs5H1lTUYDx72BSg/WX90HpA/tAu1P9ATip9r2TO3rHrSkk61Ljqf NwGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=R4z+dciA0sqBEogBLjf2kb4EMthSw/YgPp+BSAqoSxw=; b=jE/4aCFzC4AvQujrr/rw9kO5s1eYjPcEPy+mqeUi5SuTQsDQNslb51/BAm0pRt9EqK 4xA71SoWdAKpDp8nsrlyScB89j5M5j4AMC2rOeeF+0jzDLEaewbUQ4YzEfHr4xmDKHhQ n00Sq6C5G5i1cTbwB3B9MQ9Iscb5rEKQqIXj9eVwVSFQf0zPJm3zQHdV+byCPVeLV1yu /X4FeJimc/+ziufqt4+OT4IBHPpzCKNanBiWJBK/s28DYn0ZqnCOxshKKShwnOKvGEHU IShwe13ux0ELqCvXjo7XGSPA8VfOYDpihoNte1Ut31G6KX1m5YBxLyeJzjmCL7VNDK2U WyyQ== X-Gm-Message-State: ALoCoQnabO4Zpu8099mZALhlUHBKsNxXVctAU/rCbeX/Iexv0Tl12bvrh1M5ApjTuKwT/1JZP/L8Rz9zMKR02xLbiDfFYxRxLYPvFipeG9ptkUD1aADVX3B0A4l6OY6uF1FdqrECJR/R9nLxc5ZGY810Gc2dTCnGM7arRU6GiwkeuAvWqLPepozHOGNSLX34t9z/PGr8iPrq MIME-Version: 1.0 X-Received: by 10.50.43.170 with SMTP id x10mr2026518igl.45.1378479666800; Fri, 06 Sep 2013 08:01:06 -0700 (PDT) Received: by 10.64.32.74 with HTTP; Fri, 6 Sep 2013 08:01:06 -0700 (PDT) In-Reply-To: <53F00E5CD8B2E34C81C0C89EB0B4FE732DE899D9@wds-exc1.okna.nominet.org.uk> References: <8375F6DAEFB09F48815203F1FE23B79734B36464ED@shelby> <1ECAFF543A2FED4EA2BEB6CACE08E4760531513E@008-AM1MPN1-006.mgdnok.nokia.com> <53F00E5CD8B2E34C81C0C89EB0B4FE732DE899D9@wds-exc1.okna.nominet.org.uk> Date: Fri, 6 Sep 2013 08:01:06 -0700 Message-ID: From: Michael Head To: "paws@ietf.org" Content-Type: multipart/alternative; boundary=089e01176cadded2dd04e5b84ea1 Subject: Re: [paws] Spectrum_use_notify as pure notification X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 15:01:09 -0000 --089e01176cadded2dd04e5b84ea1 Content-Type: text/plain; charset=ISO-8859-1 Following up, I prefer option #1. Since all the other requests and responses are extensible, it seems awkward to strictly limit the response for just this one call. -- mike On Fri, Sep 6, 2013 at 2:06 AM, Ray Bellis wrote: > > On 6 Sep 2013, at 02:47, Nancy Bravin wrote: > > > I also prefer option # 1 for the same reasons as Gabor and Don. > > +1 > > Ray > > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > -- ---------------------------------- Michael R Head http://www.cs.binghamton.edu/~mike +1-201-BLISTER --089e01176cadded2dd04e5b84ea1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Following up, I prefer option #1.

Since= all the other requests and responses are extensible, it seems awkward to s= trictly limit the response for just this one call.

-- mike


On Fri, Sep 6, 2013 at 2:06 AM, Ray Bellis <Ray.Bellis@nomin= et.org.uk> wrote:

On 6 Sep 2013, at 02:47, Nancy Bravin <nbravin@earthlink.net> wrote:

> I also prefer option # 1 for the same reasons as Gabor and Don.

+1

Ray


_______________________________________________
paws mailing list
paws@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/paws



--
=
----------------------------------
Michael R Head <mrhead@google.com>
+1-201-BLISTER
--089e01176cadded2dd04e5b84ea1-- From vchen@google.com Fri Sep 6 10:04:50 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 285CA21E80C2 for ; Fri, 6 Sep 2013 10:04:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.77 X-Spam-Level: X-Spam-Status: No, score=0.77 tagged_above=-999 required=5 tests=[AWL=-2.253, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_SUMOF=5, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tUGPnpl3xuv2 for ; Fri, 6 Sep 2013 10:04:49 -0700 (PDT) Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 3A0EF11E80E0 for ; Fri, 6 Sep 2013 10:04:48 -0700 (PDT) Received: by mail-ob0-f182.google.com with SMTP id wo10so3666364obc.41 for ; Fri, 06 Sep 2013 10:04:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=02RTMvWhe2d2QlokIo6fopHt7ugj17GQpg6etl5S8F4=; b=igXmp/ceUMmQNe8jeSpNxtYPqjg2aS4IZAeY06A3iYCOot/Sxm8hi1Wbt2l/Gx0rFG SXFk0ItbZa0LXi6OqLpfFOKpaC/YiqYdDXNrghDx75heozIQcVcztYbNpQy7I1Xv+5go rhzQbLCco5MgaGsTRMBDdgpIxiwQ44IqhK0rPNCqdyHCBS3wxA2so5NPo+NG9edPF4G9 XsjRmQ5MLU4SrOvRoVKgME5lNYXA8s4tN6AcoUlEzliB+Rrk0EdxAlsYkwbTY9sMQxxV nmGiB7ciEjZgc75qgLyNEAVG1SQqFPrs0on9hyGM/IyNq8gH3o/CaNmOT10de9tp4mpo 1gtg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=02RTMvWhe2d2QlokIo6fopHt7ugj17GQpg6etl5S8F4=; b=VOhQpVX6QVF6Ravc+fz03zk+IrnZj69DB4vB4iLCqws8+KwowfgfYS5A7CClUTO+ba Uyf4GuoT6/iZBJcO18+EXzv6S8QqQGnUN70cKA/j3/H+q0rzfVX8p7hnh83DOepycj9r MZGiomrsKISqimT6VEuyqKAEI/cJRHF4MmZzdNIyVm1uRFJpZ5gjtACw68+/zDlCr1L1 0N/nMW4OyGntCOZ2STP2VjLbkvwsBdrVOchy4jSSaG8t7GlNbEXUfGv1taLP3anoalu2 ciBzKmfn+kApODf7nOjnvSx0DGDIJR8d6rXslooSRXjU3HgCkHtslNXsL9jOdAkKDBEE 2Osw== X-Gm-Message-State: ALoCoQmlChrIH7HMcSPrRUJiv0xUT3l5+GQ2SbCZaxlk/TNubplf+WVMk317TE2Q2Uf9Qs7PKizrmfR+NTdph9LQ4gBwqt9NJI8a3MEkM0cCnmS5EvfFiGTamw2hcH/NnAjOkl9IlzMmz93ujodogpYENTfLg4F4CwahL+qhFD3T0zTS1OkpyIi0qPegHj1fLWK5GLNVZoNU MIME-Version: 1.0 X-Received: by 10.60.117.198 with SMTP id kg6mr1026631oeb.80.1378487088424; Fri, 06 Sep 2013 10:04:48 -0700 (PDT) Received: by 10.182.250.134 with HTTP; Fri, 6 Sep 2013 10:04:48 -0700 (PDT) In-Reply-To: <53F00E5CD8B2E34C81C0C89EB0B4FE732DE89725@wds-exc1.okna.nominet.org.uk> References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DE89725@wds-exc1.okna.nominet.org.uk> Date: Fri, 6 Sep 2013 10:04:48 -0700 Message-ID: From: Vincent Chen To: Ray Bellis Content-Type: multipart/alternative; boundary=047d7b3a99f83bc36f04e5ba09b0 Cc: "paws@ietf.org" Subject: Re: [paws] Encoding of spectrum profile X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 17:04:50 -0000 --047d7b3a99f83bc36f04e5ba09b0 Content-Type: text/plain; charset=ISO-8859-1 Ray, Sorry for not providing the full example (which is in Section 6.4.2). The Bw refers a bandwidth that surrounds the entire array. That is, each Spectrum Profile is associated with a Bandwidth specification (e.g., 6MHz, 8MHz, 100kHz), allowing a regulator to provide different requirements for different operating modes. There would be one complete profile for each bandwidth. A more complete example would be something like the following, where "spectra" includes multiple spectrum profiles: "spectra": [ { "bandwidth": 6e6, "points": [ { "freqHz": 4.70e8, "maxPsdDbmPerBw": -56.8 }, { "freqHz": 5.18e8, "maxPsdDbmPerBw": -56.8 }, { "freqHz": 5.18e8, "maxPsdDbmPerBw": 30.0 }, { "freqHz": 5.24e8, "maxPsdDbmPerBw": 30.0 }, { "freqHz": 5.24e8, "maxPsdDbmPerBw": 36.0 }, { "freqHz": 5.30e8, "maxPsdDbmPerBw": 36.0 }, { "freqHz": 5.30e8, "maxPsdDbmPerBw": -56.8 }, { "freqHz": 6.98e8, "maxPsdDbmPerBw": -56.8 } ] }, { "bandwidth": 1e5, "points": [ { "freqHz": 4.70e8, "maxPsdDbmPerBw": -74.58 }, { "freqHz": 5.18e8, "maxPsdDbmPerBw": -74.58}, { "freqHz": 5.18e8, "maxPsdDbmPerBw": 27.0 }, { "freqHz": 5.24e8, "maxPsdDbmPerBw": 27.0 }, { "freqHz": 5.24e8, "maxPsdDbmPerBw": 33.0 }, { "freqHz": 5.30e8, "maxPsdDbmPerBw": 33.0 }, { "freqHz": 5.30e8, "maxPsdDbmPerBw": -74.58 }, { "freqHz": 6.98e8, "maxPsdDbmPerBw": -74.58 } ] } ] (note that the example does not match any actual rule, it's just an example of the encoding) - The first set of values for maxPsdDbmPerBw represents max power (dBm) over any 6MHz - The first set of values for maxPsdDbmPerBw represents max power (dBm) over any 100kHz A device must satisfy both. In this hypothetical example, a device may, for instance, operate 2 100kHz sub-channels within [518MHz, 524HMz) at 27dBm, but not any more. - Each sub-channel meets the 100kHz spec - The sum of the two meets the 6MHz spec Does that make more sense? -vince On Fri, Sep 6, 2013 at 1:29 AM, Ray Bellis wrote: > > On 5 Sep 2013, at 01:23, Vincent Chen wrote: > > > - The encoding uses an array, for example (thanks for the catch, Dan!): > [ > { "freqHz": 4.70e8, "maxPsdDbmPerBw": -56.8 }, > { "freqHz": 5.18e8, "maxPsdDbmPerBw": -56.8 }, > { "freqHz": 5.18e8, "maxPsdDbmPerBw": 30.0 }, > { "freqHz": 5.24e8, "maxPsdDbmPerBw": 30.0 }, > { "freqHz": 5.24e8, "maxPsdDbmPerBw": 36.0 }, > { "freqHz": 5.30e8, "maxPsdDbmPerBw": 36.0 }, > { "freqHz": 5.30e8, "maxPsdDbmPerBw": -56.8 }, > { "freqHz": 6.98e8, "maxPsdDbmPerBw": -56.8 } > ] > > - Even for regulatory domains that do not compute a level for all > channels, there are still generalized (absolute) limits on unintended EM > emissions, so there should be no need to use special values, such as -inf, > null, etc. for indicating the "unavailable" ranges. > > Should we adopt this more general encoding over the "channelized" > encoding in Draft 06? > > > I don't like it at all. > > The questions I raised about the "Bw" part of "maxPsdDbmPerBw" and the > exact mechanism of how to encode multiple bandwidth PSDs are still > unanswered. > > It *appears* that "Bw" is supposed to be the delta between the current > entry and the previous entry? Not only does this result in a potential > division-by-zero that has to be detected, it would seem that to encode the > OFCOM/ETSI rules that require a PSD over 100 kHz would require an entry (or > in fact a pair of entries) for *every single 100 kHz subchannel* within the > band. > > Also, I'm pretty certain that the OFCOM/ETSI model will actually result > in channels that simply cannot be used. We haven't seen the DTT sample data > yet but previous conversations have strongly suggested that in certain > squares they will not permit any transmissions in certain channels. This > simple contiguous set of power vs frequency points cannot encode that. > > Ray > > > > -- -vince --047d7b3a99f83bc36f04e5ba09b0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Ray,

Sorry for not providing the full e= xample (which is in Section 6.4.2).

The Bw refers a = bandwidth that surrounds the entire array. That is, each Spectrum Profile i= s associated with a Bandwidth specification (e.g., 6MHz, 8MHz, 100kHz), all= owing a regulator to provide different requirements for different operating= modes. There would be one complete profile for each bandwidth.

A more complete example would be something like the fol= lowing, where "spectra" includes multiple spectrum profiles:

"spectra": [
=A0 {
=A0 = =A0 "bandwidth": 6e6,
=A0 =A0 "points": [
=A0 =A0 =A0 { "freqHz&quo= t;: 4.70e8, "maxPsdDbmPerBw": -56.8 },
=A0 =A0 =A0 { &q= uot;freqHz": 5.18e8, "maxPsdDbmPerBw": -56.8 },
= =A0 =A0 =A0 { "freqHz": 5.18e8, "maxPsdDbmPerBw": 30.0 = },
=A0 =A0 =A0 { "freqHz": 5.24e8, "maxPsdDbmPerBw": = 30.0 },
=A0 =A0 =A0 { "freqHz": 5.24e8, "maxPsdDbm= PerBw": 36.0 },
=A0 =A0 =A0 { "freqHz": 5.30e8, &q= uot;maxPsdDbmPerBw": 36.0 },
=A0 =A0 =A0 { "freqHz": 5.30e8, "maxPsdDbmPerBw": = -56.8 },
=A0 =A0 =A0 { "freqHz": 6.98e8, "maxPsdDb= mPerBw": -56.8 }
=A0 =A0 ]
=A0 },
=A0 {<= /div>
=A0 =A0 "bandwidth": 1e5,
=A0 =A0 "points": [
=A0=A0 =A0 =A0{ "freqHz&q= uot;: 4.70e8, "maxPsdDbmPerBw": -74.58 },
=A0 =A0 =A0 {= "freqHz": 5.18e8, "maxPsdDbmPerBw": -74.58},
=A0 =A0 =A0 { "freqHz": 5.18e8, "maxPsdDbmPerBw": 27.0= },
=A0 =A0 =A0 { "freqHz": 5.24e8, "maxPsdDbmPerBw": = 27.0 },
=A0 =A0 =A0 { "freqHz": 5.24e8, "maxPsdDbm= PerBw": 33.0 },
=A0 =A0 =A0 { "freqHz": 5.30e8, &q= uot;maxPsdDbmPerBw": 33.0 },
=A0 =A0 =A0 { "freqHz": 5.30e8, "maxPsdDbmPerBw": = -74.58 },
=A0 =A0 =A0 { "freqHz": 6.98e8, "maxPsdD= bmPerBw": -74.58 }
=A0 =A0 ]
=A0 }
]

(note that the example does not match any actual rule, it's just a= n example of the encoding)

- The first set of valu= es for maxPsdDbmPerBw represents max power (dBm) over any 6MHz
- The first set of values for maxPsdDbmPerBw represents max power (dBm) ove= r any 100kHz

A device must satisfy both.

In this hypothetical example, a device may, for instance, o= perate 2 100kHz sub-channels within [518MHz, 524HMz) at 27dBm, but not any = more.
=A0- Each sub-channel meets the 100kHz spec
=A0- The sum of = the two meets the 6MHz spec

Does that make more se= nse?

-vince


On Fri, Sep 6, 2013 at 1:29 AM, Ray Bell= is <Ray.Bellis@nominet.org.uk> wrote:

On 5 Sep 2013, at 01:23, Vincent Chen <vchen@google.com> wrote:


- The encoding uses an array, for example (thanks for the catch, Dan!)= :
=A0[
=A0 =A0 { "= freqHz": 4.70e8, "maxPsdDbmPerBw": -56.8 },
=A0 =A0 { "= freqHz": 5.18e8, "maxPsdDbmPerBw": -56.8 },
=A0 =A0 { "= freqHz": 5.18e8, "maxPsdDbmPerBw": 30.0 },
=A0 =A0 { "= freqHz": 5.24e8, "maxPsdDbmPerBw": 30.0 },
=A0 =A0 { "= freqHz": 5.24e8, "maxPsdDbmPerBw": 36.0 },
=A0 =A0 { "= freqHz": 5.30e8, "maxPsdDbmPerBw": 36.0 },
=A0 =A0 { "= freqHz": 5.30e8, "maxPsdDbmPerBw": -56.8 },
=A0 =A0 { "= freqHz": 6.98e8, "maxPsdDbmPerBw": -56.8 }
=A0 ]

- Even for regul= atory domains that do not compute a level for all channels, there are still= generalized (absolute) limits on unintended EM emissions, so there should = be no need to use special values, such as -inf, null, etc. for indicating the "unavailable" ranges= .

Should we adopt this more general encoding over the "channelized&= quot; encoding in Draft 06?

I don't like it at all.

The questions I raised about the "Bw" part of "maxPsdDb= mPerBw" and the exact mechanism of how to encode multiple bandwidth PS= Ds are still unanswered.

It *appears* that "Bw" is supposed to be the delta between t= he current entry and the previous entry? =A0Not only does this result in a = potential division-by-zero that has to be detected, it would seem that to e= ncode the OFCOM/ETSI rules that require a PSD over 100 kHz would require an entry (or in fact a pair of entries) for *ev= ery single 100 kHz subchannel* within the band.

Also, I'm pretty certain that the OFCOM/ETSI model will actually r= esult in channels that simply cannot be used. We haven't seen the DTT s= ample data yet but previous conversations have strongly suggested that in c= ertain squares they will not permit any transmissions in certain channels. =A0This simple contiguous set of power = vs frequency points cannot encode that.

Ray






--
-vince
--047d7b3a99f83bc36f04e5ba09b0-- From Ray.Bellis@nominet.org.uk Fri Sep 6 11:31:16 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C57411E81CB for ; Fri, 6 Sep 2013 11:31:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gZIBSU-KKggW for ; Fri, 6 Sep 2013 11:31:11 -0700 (PDT) Received: from mx2.nominet.org.uk (mail.nominet.org.uk [213.248.242.49]) by ietfa.amsl.com (Postfix) with ESMTP id DFBA911E81B5 for ; Fri, 6 Sep 2013 11:31:10 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:From:To:CC:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:Content-Type: Content-Transfer-Encoding:MIME-Version; b=A0bduXGGXpVEGpN8xcsiZU16uyXBqfgiOir3X0LN7HTnfjZqfbea7cqR lS+4t7Pa0kOJcq2yjdXSl+0XwAVvZ658YjlGuRBWDFDAcjQly4+EInnxD edaHsW1w8Slu1Yk; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1378492270; x=1410028270; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=BTNoH+nAgcQ6bbgI9TNgPoGWGb0JGfxag9G8cL4F/pM=; b=QezY5HKlVIEYffdCrDtwJvK44lN+M68gK9s5DFrw8Y+9wlc3hks3Y9IY P8A4UiClFo7ZWQS3/nFH0/Q8l/lAykd/3bzVPQ7c6SfU//VEa5VskAoD4 V4N4DzVnKQLwmcq; X-IronPort-AV: E=Sophos;i="4.90,855,1371078000"; d="scan'208";a="2879527" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx2.nominet.org.uk with ESMTP; 06 Sep 2013 19:31:08 +0100 Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4%17]) with mapi id 14.02.0318.004; Fri, 6 Sep 2013 19:31:08 +0100 From: Ray Bellis To: Vincent Chen Thread-Topic: [paws] Encoding of spectrum profile Thread-Index: AQHOoeQCmU+qkDwvDUSLePEjGLDDY5msmYcAgAAgqoCAAWO2gIAIKfUAgAIaGoCAAI/hAIAAKOJG Date: Fri, 6 Sep 2013 18:31:07 +0000 Message-ID: References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DE89725@wds-exc1.okna.nominet.org.uk>, In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] Encoding of spectrum profile X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 18:31:17 -0000 > Ray, >=20 > Sorry for not providing the full example (which is in Section 6.4.2). Ah, that makes more sense - I couldn't find anything in the previous emails= that confirmed that this proposal only covered the inner part of the spe= ctra structure. My point about being able to represent discontinuities in the frequency ran= ge still appears to stand, however. Kind regards Ray From d.joslyn@spectrumbridge.com Tue Sep 10 06:32:23 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 840CE11E81AD for ; Tue, 10 Sep 2013 06:32:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.739 X-Spam-Level: X-Spam-Status: No, score=-0.739 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zIjBUU+Oqx-g for ; Tue, 10 Sep 2013 06:32:18 -0700 (PDT) Received: from mail.spectrumbridge.com (mail.spectrumbridge.com [64.132.248.82]) by ietfa.amsl.com (Postfix) with ESMTP id 0F63021E8053 for ; Tue, 10 Sep 2013 06:32:14 -0700 (PDT) Received: from shelby.sbi.com ([127.0.0.1]) by shelby ([127.0.0.1]) with mapi; Tue, 10 Sep 2013 09:32:13 -0400 From: Don Joslyn To: "paws@ietf.org" Date: Tue, 10 Sep 2013 09:32:12 -0400 Thread-Topic: RulesetInfo issue Thread-Index: Ac6uKiVBsmzGOBrDSWup6mKacHYFSQ== Message-ID: <8375F6DAEFB09F48815203F1FE23B79734B3646560@shelby> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_8375F6DAEFB09F48815203F1FE23B79734B3646560shelby_" MIME-Version: 1.0 Subject: [paws] RulesetInfo issue X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 13:32:23 -0000 --_000_8375F6DAEFB09F48815203F1FE23B79734B3646560shelby_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The INIT_RESP message contains Authority, maxLocationChange, maxPollingSecs= , and RulesetIds supported by the database. The maxLocationChange and maxPo= llingSecs properties may be different for each RulesetId that is specified,= but it appears that we're assuming these values will always apply to only = the returned Authority and that all RulesetIds would always use the same va= lues per Authority. Is it the intent that maxLocationChange returned to the= device should be the minimum of the maxLocationChange for all of the Rules= etIds supported by the database or should this property be a separate prope= rty for each RulesetId that is supported? The same issue applies to maxPoll= ingSecs. A hypothetical example where this might break... If the database supports "= US" Authority and supports RulesetId =3D "FccTvBandWhiteSpace-2010" and Rul= esetId =3D "FccPcast3.5-2014" (made this one up), then these two rule sets = would be forced to share the same values for maxLocationChange and maxPolli= ngSecs. Thoughts? Thanks, Don --_000_8375F6DAEFB09F48815203F1FE23B79734B3646560shelby_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The INIT_RESP me= ssage contains Authority, maxLocationChange, maxPollingSecs, and RulesetIds= supported by the database. The maxLocationChange and maxPollingSecs proper= ties may be different for each RulesetId that is specified, but it appears = that we’re assuming these values will always apply to only the return= ed Authority and that all RulesetIds would always use the same values per A= uthority. Is it the intent that maxLocationChange returned to the device sh= ould be the minimum of the maxLocationChange for all of the RulesetIds supp= orted by the database or should this property be a separate property for ea= ch RulesetId that is supported? The same issue applies to maxPollingSecs.

 

A hypothetical example where this might break… If the database suppo= rts “US” Authority and supports RulesetId =3D “FccTvBandW= hiteSpace-2010” and RulesetId =3D “FccPcast3.5-2014” (mad= e this one up), then these two rule sets would be forced to share the same = values for maxLocationChange and maxPollingSecs.

 

Thoughts?

=

 

Thanks,=

Don

= --_000_8375F6DAEFB09F48815203F1FE23B79734B3646560shelby_-- From d.joslyn@spectrumbridge.com Tue Sep 10 08:11:00 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F28321F9D7B for ; Tue, 10 Sep 2013 08:11:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.669 X-Spam-Level: X-Spam-Status: No, score=-1.669 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id to2HZBh9h5qX for ; Tue, 10 Sep 2013 08:10:55 -0700 (PDT) Received: from mail.spectrumbridge.com (mail.spectrumbridge.com [64.132.248.82]) by ietfa.amsl.com (Postfix) with ESMTP id 9806E21F91F2 for ; Tue, 10 Sep 2013 08:10:54 -0700 (PDT) Received: from shelby.sbi.com ([127.0.0.1]) by shelby ([127.0.0.1]) with mapi; Tue, 10 Sep 2013 11:10:53 -0400 From: Don Joslyn To: "paws@ietf.org" Date: Tue, 10 Sep 2013 11:10:51 -0400 Thread-Topic: Validating multiple rulesetIds during registration Thread-Index: Ac6uN+4VMmoFDRmcSler1KNDi9IUow== Message-ID: <8375F6DAEFB09F48815203F1FE23B79734B3646569@shelby> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_8375F6DAEFB09F48815203F1FE23B79734B3646569shelby_" MIME-Version: 1.0 Subject: [paws] Validating multiple rulesetIds during registration X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 15:11:00 -0000 --_000_8375F6DAEFB09F48815203F1FE23B79734B3646569shelby_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The REGISTRATION_REQ message includes deviceDesc which includes a list of r= ulesetIds. If the device includes multiple rulesetIds in the REGISTRATION_R= EQ message, the database should validate the included registration informat= ion against each rulesetId specified by the device. If validation fails for= one or more of the rulesetIds included in the request message, there is no= way to indicate in the registration response message which rulesetId faile= d validation. In the event that multiple rulesetIds are specified in the registration req= uest, if more than one requires registration and one or more fails, should = we: a. Return an overall error response indicating the first rulesetId that= failed registration. b. Return all rulesetIds that failed registration with an error message= indicating the nature for each failure. In the event that one or more rulesets fail, but also one or more rulesets = are successful, should we return: a. A successful response indicating the rulesets that were successful. b. A failure response indicating one or more rulesets that failed. Thanks, Don --_000_8375F6DAEFB09F48815203F1FE23B79734B3646569shelby_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The REGISTRATION= _REQ message includes deviceDesc which includes a list of rulesetIds. If th= e device includes multiple rulesetIds in the REGISTRATION_REQ message, the = database should validate the included registration information against each= rulesetId specified by the device. If validation fails for one or more of = the rulesetIds included in the request message, there is no way to indicate= in the registration response message which rulesetId failed validation.

 

= In the event that multiple rulesetIds are specified in the registration req= uest, if more than one requires registration and one or more fails, should = we:

   a.  Return an over= all error response indicating the first rulesetId that failed registration.=

   b.  Return all rulese= tIds that failed registration with an error message indicating the nature f= or each failure.

 

In the event that one or more rulesets fail, but also on= e or more rulesets are successful, should we return:

   a.  A successful response indicating the rul= esets that were successful.

  = b.  A failure response indicating one or more rulesets that failed.

 

Thanks,

Don

= = --_000_8375F6DAEFB09F48815203F1FE23B79734B3646569shelby_-- From vchen@google.com Tue Sep 10 09:14:00 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D12121E8143 for ; Tue, 10 Sep 2013 09:14:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aWB5oDtz2beB for ; Tue, 10 Sep 2013 09:13:59 -0700 (PDT) Received: from mail-oa0-x230.google.com (mail-oa0-x230.google.com [IPv6:2607:f8b0:4003:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id 60EB521E813D for ; Tue, 10 Sep 2013 09:13:59 -0700 (PDT) Received: by mail-oa0-f48.google.com with SMTP id o17so8034135oag.35 for ; Tue, 10 Sep 2013 09:13:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HrIEJ8ldDkSug+Yb/SdNAAZWKtCAhY8Ay3A+n7i2POw=; b=a6KXsE7mr3md4rQT4pJrF0cbmSPF5FoSw6frzP+weKhfb79TB3uXMj8a9mErKm0nZd hmFivNEnebEbQqjKV+/zs8RGTPTjIgbHf+nB79eTsEZIdg9ou+bdo9yisRq9v+kpTwkv o4xV3JDmhnIGVDRGbJRYOnNL/ZsGNmiW3CxmF5T1kwLt/BtiAoQe0/bLDZ1Xx+BkaoeB h1+NH1Fr44myTiLjbvzuSE8uMQVuE8u5QXvlOg/paErx+v3li+OwFZpZ9OC/IMfuiThR Ug+zIueBa5YnNFU56LkVSfGfUwQoICnzkKG92ZxdH86VEB3S95hoc3BSlRKkHkkpZ2aw fp3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=HrIEJ8ldDkSug+Yb/SdNAAZWKtCAhY8Ay3A+n7i2POw=; b=ANy1PIg9bNLrZ5IqsXV3QQK/Lp+3ZIhaKkGiMHAUkpsb8UgybPJFrU1MmQDUpwUT4v EUc8wBzmPpg3mJANiRzCqgwIh2Q9vxc4lZiF2qjR68U/nqfN1okpyX+OFugXavFmdCWH eeal/rrG/OhcKvEHr6l1siNqpcoQYGXoQ5fRM41/eDIff2SThTkhLZMzOUKLxbZOJJuQ 2xM++53YZNHmn84nUfjbdhYQE9OcJbQj/u63OxgV5Bq35n/Y3k8A7VwBTnZQUAi9tsxT L399DbuaVPXvNRba58kpd4vKCuZTnVk+hxdi+jnNSx9DadksONu4NVUzIZh7tj4n4KGI uywQ== X-Gm-Message-State: ALoCoQnTeGGaAd2BXMuI55u043ieJw8DfJaaC1APpCjROT1VzM+z3rQd2YbgnJ3MZz8onqDYq4yJE33AGgn9loChW7ODjD6NHqpdIHTQo9kML9FK/dpMdAkbCLVhqpGgt698MVopQURbZoD56erCnP/Ajt5tKFNhfy9eCp1viLXA5WdKq+bPOC5LxwrmyycRtFNmOQwW+zxT MIME-Version: 1.0 X-Received: by 10.60.50.135 with SMTP id c7mr6866788oeo.41.1378829638803; Tue, 10 Sep 2013 09:13:58 -0700 (PDT) Received: by 10.182.250.134 with HTTP; Tue, 10 Sep 2013 09:13:58 -0700 (PDT) In-Reply-To: <8375F6DAEFB09F48815203F1FE23B79734B3646560@shelby> References: <8375F6DAEFB09F48815203F1FE23B79734B3646560@shelby> Date: Tue, 10 Sep 2013 09:13:58 -0700 Message-ID: From: Vincent Chen To: Don Joslyn Content-Type: multipart/alternative; boundary=001a11c2f776d3bd3e04e609ca5f Cc: "paws@ietf.org" Subject: Re: [paws] RulesetInfo issue X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 16:14:00 -0000 --001a11c2f776d3bd3e04e609ca5f Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Don, Thanks for bringing this up. At the F2F, we agreed to support multiple rulesets in the AVAIL_SPECTRUM_RESP, so we would also change the INIT_RESP. Summary: - RulesetInfo message changes to contain only a single rulesetId - There would be list of RulesetInfo messages RulesetInfo contains: - authority - rulesetId - maxLocationChange - maxPollingSecs INIT_RESP contains: - List of RulesetInfo messages - databaseChange SpectrumSpec: - RulesetInfo - needsSpectrumReport - List of SpectrumSchedule messages AVAIL_SPECTRUM_RESP contains: - timestamp - deviceDescriptor - location - List of SpectrumSpec messages Does that make more sense? -vince On Tue, Sep 10, 2013 at 6:32 AM, Don Joslyn wr= ote: > The INIT_RESP message contains Authority, maxLocationChange, > maxPollingSecs, and RulesetIds supported by the database. The > maxLocationChange and maxPollingSecs properties may be different for each > RulesetId that is specified, but it appears that we=92re assuming these > values will always apply to only the returned Authority and that all > RulesetIds would always use the same values per Authority. Is it the inte= nt > that maxLocationChange returned to the device should be the minimum of th= e > maxLocationChange for all of the RulesetIds supported by the database or > should this property be a separate property for each RulesetId that is > supported? The same issue applies to maxPollingSecs.**** > > ** ** > > A hypothetical example where this might break=85 If the database supports > =93US=94 Authority and supports RulesetId =3D =93FccTvBandWhiteSpace-2010= =94 and > RulesetId =3D =93FccPcast3.5-2014=94 (made this one up), then these two r= ule sets > would be forced to share the same values for maxLocationChange and > maxPollingSecs.**** > > ** ** > > Thoughts?**** > > ** ** > > Thanks,**** > > Don**** > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > > --=20 -vince --001a11c2f776d3bd3e04e609ca5f Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Don,

Thanks for bringing this up. At th= e F2F, we agreed to support multiple rulesets in the AVAIL_SPECTRUM_RESP, s= o we would also change the INIT_RESP.

Summary:
=A0 - RulesetInfo message changes to contain only a single rulesetId
=A0 - There would be list of RulesetInfo messages

RulesetInfo contains:
=A0 - authority
=A0 - ru= lesetId
=A0 - maxLocationChange
=A0 - maxPollingSecs

<= /div>
INIT_RESP contains:
=A0 - List of RulesetInfo messages<= /div>
=A0 - databaseChange


Spec= trumSpec:
=A0- RulesetInfo
=A0- needsSpectrumReport
=A0- Lis= t of SpectrumSchedule messages=A0

AVAIL_SPECTRUM_R= ESP contains:
=A0 - timestamp
=A0 - deviceDescriptor
=A0 - location
=A0 - List of SpectrumSpec messages

=
Does that make more sense?

-vince
=


On Tue,= Sep 10, 2013 at 6:32 AM, Don Joslyn <d.joslyn@spectrumbridge.co= m> wrote:

The INIT_RESP message contains Authority= , maxLocationChange, maxPollingSecs, and RulesetIds supported by the databa= se. The maxLocationChange and maxPollingSecs properties may be different fo= r each RulesetId that is specified, but it appears that we=92re assuming th= ese values will always apply to only the returned Authority and that all Ru= lesetIds would always use the same values per Authority. Is it the intent t= hat maxLocationChange returned to the device should be the minimum of the m= axLocationChange for all of the RulesetIds supported by the database or sho= uld this property be a separate property for each RulesetId that is support= ed? The same issue applies to maxPollingSecs.

=A0

A hypoth= etical example where this might break=85 If the database supports =93US=94 = Authority and supports RulesetId =3D =93FccTvBandWhiteSpace-2010=94 and Rul= esetId =3D =93FccPcast3.5-2014=94 (made this one up), then these two rule s= ets would be forced to share the same values for maxLocationChange and maxP= ollingSecs.

=A0

Thoughts= ?

=A0

Thanks,

Don


_______________________________________________
paws mailing list
paws@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/paws




--
-vince
--001a11c2f776d3bd3e04e609ca5f-- From vchen@google.com Tue Sep 10 10:00:44 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A53311E81F5 for ; Tue, 10 Sep 2013 10:00:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cx3eQK7g+9Fd for ; Tue, 10 Sep 2013 10:00:17 -0700 (PDT) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 899E421E8181 for ; Tue, 10 Sep 2013 09:59:30 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id er7so7490523obc.3 for ; Tue, 10 Sep 2013 09:59:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=avKWsaHcFx6ElsVoeVgEPoXwvcjnAwmhnxKF9i71psQ=; b=RumV0z5bbXT0dNWY2SMzIU/W/ee81/tMOh+QzO1ZyvsEo1tn9XM3pAclz2wPKK3TGC r/EvyqugS6yACVSe4MQRxvgRLhw1PsAnTKN/Zmixru1Qz1BuJUMqdK6FvoxYGGm8Ossw 1BZN8nPy057DVyoIpdO+N2dV4bk0qGU3/kOAUmggnhHlUS/cbaL82oKQ8J01TqBscree +vkyGuahl9szO4fpxxdw8xSOHhOvgfNH5CA//JflQLb8qHLk6RMKsx7NPXV6Kj3qZA/8 y/f9RxA5xu6LDBJfwJXfrCQhsk4jytbNOOH6A1GeULbex1Bm7UyK5NEDDODq6RKUWOyX 9kMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=avKWsaHcFx6ElsVoeVgEPoXwvcjnAwmhnxKF9i71psQ=; b=bsNYNhubeEIXiidrsyM0Fi0njbZ5U/CAyXkjQwbPn2mzOElAcu5f6JA6rmtICxMgxQ 0fpFebONetbqiytKtP3qjN/IPWe6DvGSi7/JO6H+HoI88B7BYPmtbwMW9f67LKU/c36m chAhx1WfEy9JSgQnQrlE6VoTV0u5pqzPzv3xiKdeVShTOvJP67r+tE9i3GE3oNfCNTT5 knrRW7nJIre7pkpgJu4DFa7XBcBF61JOI39CyY1AVCBUC8QAoJWo32DWSi/isf/I3/UC 3maJg/QseaHhb+mnZZRKFuzoTXeZAn/mm90u8a1oBYMnzzB81CoYR0eMtzoTPkM2fU6/ HJ2Q== X-Gm-Message-State: ALoCoQl6/vqhpLEpLbXO9No6Heedaxo1xckB6hqoFQRgMYUg1rZKb2OgLTq4wuw09XZPdb4bc4ssU1Hq97XqLZ002LDyygOGngIonLrPQlAf7Kz4shBeMuVU/AZz9Uk2hQ/khZ6nMDoSLyAafbgabhClFNao6Fq/XGn05XIZAiGNtTSwpGIiwuvuNcHN/r6HwEg6y/uwMmCY MIME-Version: 1.0 X-Received: by 10.60.43.230 with SMTP id z6mr1418311oel.92.1378832368540; Tue, 10 Sep 2013 09:59:28 -0700 (PDT) Received: by 10.182.250.134 with HTTP; Tue, 10 Sep 2013 09:59:28 -0700 (PDT) In-Reply-To: <8375F6DAEFB09F48815203F1FE23B79734B3646569@shelby> References: <8375F6DAEFB09F48815203F1FE23B79734B3646569@shelby> Date: Tue, 10 Sep 2013 09:59:28 -0700 Message-ID: From: Vincent Chen To: Don Joslyn Content-Type: multipart/alternative; boundary=001a11330e1c88338404e60a6dfd Cc: "paws@ietf.org" Subject: Re: [paws] Validating multiple rulesetIds during registration X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 17:00:49 -0000 --001a11330e1c88338404e60a6dfd Content-Type: text/plain; charset=ISO-8859-1 Don, Great points! To be consistent with the proposed change to INIT_RESP, I think the REGISTRATION_RESP should also contain a list of RulesetInfo messages, one for each successful registration. - If any registrations are successful, the response is successful and contains RulesetInfo messages that are successful - If no registrations are successful, it is an error response, with a failure code indicating type of error (e.g., REQUIRED for missing required fields) Justification: When device includes multiple rultesetIds in its request messages, it's expecting a "best efforts/best match" behavior, and this matches that expectation. Does that sound OK? -vince On Tue, Sep 10, 2013 at 8:10 AM, Don Joslyn wrote: > The REGISTRATION_REQ message includes deviceDesc which includes a list of > rulesetIds. If the device includes multiple rulesetIds in the > REGISTRATION_REQ message, the database should validate the included > registration information against each rulesetId specified by the device. If > validation fails for one or more of the rulesetIds included in the request > message, there is no way to indicate in the registration response message > which rulesetId failed validation.**** > > ** ** > > In the event that multiple rulesetIds are specified in the registration > request, if more than one requires registration and one or more fails, > should we:**** > > a. Return an overall error response indicating the first rulesetId > that failed registration.**** > > b. Return all rulesetIds that failed registration with an error > message indicating the nature for each failure.**** > > ** ** > > In the event that one or more rulesets fail, but also one or more rulesets > are successful, should we return:**** > > a. A successful response indicating the rulesets that were successful. > **** > > b. A failure response indicating one or more rulesets that failed.**** > > ** ** > > Thanks,**** > > Don**** > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > > -- -vince --001a11330e1c88338404e60a6dfd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Don,

Great points!

=
To be consistent with the proposed change to INIT_RESP, I think the RE= GISTRATION_RESP should also contain a list of RulesetInfo messages, one for= each successful registration.

=A0- If any registrations are successful, the response = is successful and contains RulesetInfo messages that are successful
=A0- If no registrations are successful, it is an error response, with a= failure code indicating type of error (e.g., REQUIRED for missing required= fields)

Justification: When device includes multiple rultesetId= s in its request messages, it's expecting a "best efforts/best mat= ch" behavior, and this matches that expectation.

Does that sound OK?

-vince
<= div class=3D"gmail_extra">

On Tue, Sep 10= , 2013 at 8:10 AM, Don Joslyn <d.joslyn@spectrumbridge.com&g= t; wrote:

The REGISTRATION_REQ message includes de= viceDesc which includes a list of rulesetIds. If the device includes multip= le rulesetIds in the REGISTRATION_REQ message, the database should validate= the included registration information against each rulesetId specified by = the device. If validation fails for one or more of the rulesetIds included = in the request message, there is no way to indicate in the registration res= ponse message which rulesetId failed validation.

=A0

In the e= vent that multiple rulesetIds are specified in the registration request, if= more than one requires registration and one or more fails, should we:

=A0=A0 a.=A0 Return an overall error response indica= ting the first rulesetId that failed registration.

=A0=A0 b.=A0 Return all rulesetIds that failed registration= with an error message indicating the nature for each failure.

=A0

In the e= vent that one or more rulesets fail, but also one or more rulesets are succ= essful, should we return:

=A0=A0 a.= =A0 A successful response indicating the rulesets that were successful.<= /u>

=A0=A0 b.=A0 A failure response indicating one or mo= re rulesets that failed.

=A0=

Thanks,

Don


_______________________________________________
paws mailing list
paws@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/paws




--
-vince
--001a11330e1c88338404e60a6dfd-- From d.joslyn@spectrumbridge.com Tue Sep 10 11:08:32 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0335621E815E for ; Tue, 10 Sep 2013 11:08:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.133 X-Spam-Level: X-Spam-Status: No, score=-2.133 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WrESjH9j0yKV for ; Tue, 10 Sep 2013 11:08:27 -0700 (PDT) Received: from mail.spectrumbridge.com (mail.spectrumbridge.com [64.132.248.82]) by ietfa.amsl.com (Postfix) with ESMTP id 80D8321E812C for ; Tue, 10 Sep 2013 11:08:27 -0700 (PDT) Received: from shelby.sbi.com ([127.0.0.1]) by shelby ([127.0.0.1]) with mapi; Tue, 10 Sep 2013 14:08:26 -0400 From: Don Joslyn To: Vincent Chen Date: Tue, 10 Sep 2013 14:08:24 -0400 Thread-Topic: [paws] RulesetInfo issue Thread-Index: Ac6uQMJiw2BjGRz6SROstls9hNpmZQADrDNAAABOOSA= Message-ID: <8375F6DAEFB09F48815203F1FE23B79734B3646573@shelby> References: <8375F6DAEFB09F48815203F1FE23B79734B3646560@shelby> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_8375F6DAEFB09F48815203F1FE23B79734B3646573shelby_" MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] RulesetInfo issue X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 18:08:32 -0000 --_000_8375F6DAEFB09F48815203F1FE23B79734B3646573shelby_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Vince, This makes perfect sense to me, and I'm satisfied with your proposed change= s. Thanks, Don From: Vincent Chen [mailto:vchen@google.com] Sent: Tuesday, September 10, 2013 12:14 PM To: Don Joslyn Cc: paws@ietf.org Subject: Re: [paws] RulesetInfo issue Don, Thanks for bringing this up. At the F2F, we agreed to support multiple rule= sets in the AVAIL_SPECTRUM_RESP, so we would also change the INIT_RESP. Summary: - RulesetInfo message changes to contain only a single rulesetId - There would be list of RulesetInfo messages RulesetInfo contains: - authority - rulesetId - maxLocationChange - maxPollingSecs INIT_RESP contains: - List of RulesetInfo messages - databaseChange SpectrumSpec: - RulesetInfo - needsSpectrumReport - List of SpectrumSchedule messages AVAIL_SPECTRUM_RESP contains: - timestamp - deviceDescriptor - location - List of SpectrumSpec messages Does that make more sense? -vince On Tue, Sep 10, 2013 at 6:32 AM, Don Joslyn > wrote: The INIT_RESP message contains Authority, maxLocationChange, maxPollingSecs= , and RulesetIds supported by the database. The maxLocationChange and maxPo= llingSecs properties may be different for each RulesetId that is specified,= but it appears that we're assuming these values will always apply to only = the returned Authority and that all RulesetIds would always use the same va= lues per Authority. Is it the intent that maxLocationChange returned to the= device should be the minimum of the maxLocationChange for all of the Rules= etIds supported by the database or should this property be a separate prope= rty for each RulesetId that is supported? The same issue applies to maxPoll= ingSecs. A hypothetical example where this might break... If the database supports "= US" Authority and supports RulesetId =3D "FccTvBandWhiteSpace-2010" and Rul= esetId =3D "FccPcast3.5-2014" (made this one up), then these two rule sets = would be forced to share the same values for maxLocationChange and maxPolli= ngSecs. Thoughts? Thanks, Don _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws -- -vince --_000_8375F6DAEFB09F48815203F1FE23B79734B3646573shelby_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Vince,

 

=

This makes perfect sense to me, and I’m s= atisfied with your proposed changes.

 

Thanks,<= o:p>

Don

<= p class=3DMsoNormal> 

From= : Vincent Chen [mailto:vchen@google.= com]
Sent: Tuesday, September 10, 2013 12:14 PM
To: Don Joslyn
Cc: paws@ietf.org
Subject: Re: [paws] RulesetInfo issue

 

Don,<= /o:p>

 

On Tue, Sep 10, 2013 at 6:32 AM, Don Joslyn <d.joslyn@spectrumbridge.com&g= t; wrote:

The INIT_RESP message contains Aut= hority, maxLocationChange, maxPollingSecs, and RulesetIds supported by the = database. The maxLocationChange and maxPollingSecs properties may be differ= ent for each RulesetId that is specified, but it appears that we’re a= ssuming these values will always apply to only the returned Authority and t= hat all RulesetIds would always use the same values per Authority. Is it th= e intent that maxLocationChange returned to the device should be the minimu= m of the maxLocationChange for all of the RulesetIds supported by the datab= ase or should this property be a separate property for each RulesetId that = is supported? The same issue applies to maxPollingSecs.

 

A hypothetical example where this might break= … If the database supports “US” Authority and supports Ru= lesetId =3D “FccTvBandWhiteSpace-2010” and RulesetId =3D “= ;FccPcast3.5-2014” (made this one up), then these two rule sets would= be forced to share the same values for maxLocationChange and maxPollingSec= s.

 

Thoughts?

 

Thanks,

Don

_______________________________________________
paws mailing list
paws@ietf.org
https://www.ietf.org/mail= man/listinfo/paws



 

--
-vince

= --_000_8375F6DAEFB09F48815203F1FE23B79734B3646573shelby_-- From d.joslyn@spectrumbridge.com Tue Sep 10 11:09:44 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CCCC21E815E for ; Tue, 10 Sep 2013 11:09:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.288 X-Spam-Level: X-Spam-Status: No, score=-2.288 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oh67dK9xSAu7 for ; Tue, 10 Sep 2013 11:09:40 -0700 (PDT) Received: from mail.spectrumbridge.com (mail.spectrumbridge.com [64.132.248.82]) by ietfa.amsl.com (Postfix) with ESMTP id DDED221E8157 for ; Tue, 10 Sep 2013 11:09:39 -0700 (PDT) Received: from shelby.sbi.com ([127.0.0.1]) by shelby ([127.0.0.1]) with mapi; Tue, 10 Sep 2013 14:09:39 -0400 From: Don Joslyn To: Vincent Chen Date: Tue, 10 Sep 2013 14:09:39 -0400 Thread-Topic: [paws] Validating multiple rulesetIds during registration Thread-Index: Ac6uRx1ZHQIT5dllQzqzRTs2AWgVdgACMyaw Message-ID: <8375F6DAEFB09F48815203F1FE23B79734B3646574@shelby> References: <8375F6DAEFB09F48815203F1FE23B79734B3646569@shelby> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_8375F6DAEFB09F48815203F1FE23B79734B3646574shelby_" MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] Validating multiple rulesetIds during registration X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 18:09:44 -0000 --_000_8375F6DAEFB09F48815203F1FE23B79734B3646574shelby_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Vince, Your proposal sounds good to me. I wonder if anyone would be interested in also including failed Rulesets wi= th a status that indicates what went wrong. Maybe we could add a "status" f= ield to the RulesetInfo for that purpose? Thanks, Don From: Vincent Chen [mailto:vchen@google.com] Sent: Tuesday, September 10, 2013 12:59 PM To: Don Joslyn Cc: paws@ietf.org Subject: Re: [paws] Validating multiple rulesetIds during registration Don, Great points! To be consistent with the proposed change to INIT_RESP, I think the REGISTR= ATION_RESP should also contain a list of RulesetInfo messages, one for each= successful registration. - If any registrations are successful, the response is successful and cont= ains RulesetInfo messages that are successful - If no registrations are successful, it is an error response, with a fail= ure code indicating type of error (e.g., REQUIRED for missing required fiel= ds) Justification: When device includes multiple rultesetIds in its request mes= sages, it's expecting a "best efforts/best match" behavior, and this matche= s that expectation. Does that sound OK? -vince On Tue, Sep 10, 2013 at 8:10 AM, Don Joslyn > wrote: The REGISTRATION_REQ message includes deviceDesc which includes a list of r= ulesetIds. If the device includes multiple rulesetIds in the REGISTRATION_R= EQ message, the database should validate the included registration informat= ion against each rulesetId specified by the device. If validation fails for= one or more of the rulesetIds included in the request message, there is no= way to indicate in the registration response message which rulesetId faile= d validation. In the event that multiple rulesetIds are specified in the registration req= uest, if more than one requires registration and one or more fails, should = we: a. Return an overall error response indicating the first rulesetId that= failed registration. b. Return all rulesetIds that failed registration with an error message= indicating the nature for each failure. In the event that one or more rulesets fail, but also one or more rulesets = are successful, should we return: a. A successful response indicating the rulesets that were successful. b. A failure response indicating one or more rulesets that failed. Thanks, Don _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws -- -vince --_000_8375F6DAEFB09F48815203F1FE23B79734B3646574shelby_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Vince,

 

=

Your proposal sounds good to me.

 

I wonder if anyone would be interested in also including fa= iled Rulesets with a status that indicates what went wrong. Maybe we could = add a “status” field to the RulesetInfo for that purpose?<= /o:p>

 

Thanks,

= Don

 

From: Vincent Chen [mailto:vchen@google.com= ]
Sent: Tuesday, September 10, 2013 12:59 PM
To: Don J= oslyn
Cc: paws@ietf.org
Subject: Re: [paws] Validating = multiple rulesetIds during registration

 

Don,

 

Great points!

 

To be consistent with the proposed = change to INIT_RESP, I think the REGISTRATION_RESP should also contain a li= st of RulesetInfo messages, one for each successful registration.

 

 - If any registrations are successful, the response is= successful and contains RulesetInfo messages that are successful

 - If no registrations are succes= sful, it is an error response, with a failure code indicating type of error= (e.g., REQUIRED for missing required fields)

 

Justi= fication: When device includes multiple rultesetIds in its request messages= , it's expecting a "best efforts/best match" behavior, and this m= atches that expectation.

 

Does that sound OK?

 

-vince

 

On Tue, Sep 10, 2013 at 8:10 AM, Don Joslyn <d.joslyn@spectrumbridge.com&= gt; wrote:

The REGISTRATION_REQ message incl= udes deviceDesc which includes a list of rulesetIds. If the device includes= multiple rulesetIds in the REGISTRATION_REQ message, the database should v= alidate the included registration information against each rulesetId specif= ied by the device. If validation fails for one or more of the rulesetIds in= cluded in the request message, there is no way to indicate in the registrat= ion response message which rulesetId failed validation.

 

In the event that multiple rulesetIds are spe= cified in the registration request, if more than one requires registration = and one or more fails, should we:

   a.&nbs= p; Return an overall error response indicating the first rulesetId that fai= led registration.

   b.  Return all rul= esetIds that failed registration with an error message indicating the natur= e for each failure.

 

In the= event that one or more rulesets fail, but also one or more rulesets are su= ccessful, should we return:

   a.  A su= ccessful response indicating the rulesets that were successful.<= /p>

   b.  A failure response indicating one or more r= ulesets that failed.

 

Thank= s,

Don


________________________________________= _______
paws mailing list
paws@ietf.= org
https://www.ietf.org/mailman/listinfo/paws



 

--
-vince =

= --_000_8375F6DAEFB09F48815203F1FE23B79734B3646574shelby_-- From vchen@google.com Fri Sep 13 09:00:27 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F271921F9FAD for ; Fri, 13 Sep 2013 09:00:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.77 X-Spam-Level: X-Spam-Status: No, score=-0.77 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mPlfUPmIaz+s for ; Fri, 13 Sep 2013 09:00:25 -0700 (PDT) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 105F021F9FC9 for ; Fri, 13 Sep 2013 09:00:24 -0700 (PDT) Received: by mail-ob0-f177.google.com with SMTP id wp18so1242964obc.22 for ; Fri, 13 Sep 2013 09:00:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dVCKnQjWrpp/1w6+8eHlMg312Co4DEiyjYdFh/LgqW4=; b=gJuMhM76mJJ6GZEN3kR6NxLLJBnXPtcJnQ6/3hb7mlmSulgZWEDUoytGoaqFTx7IPJ /X+Uvq3vv1s7qgQYgpNlMaHHnWKx+9UaC7bNZeNNcz8RDP+EhjDjandm9k0fIR1mHESA 4jbXZCuqkfzc8D5ynS9GN2UFSuOlc0FU9JkqinxmWhei/ONb68qnH+Gi0dDXSBxshFHN qLRw9uJ0LxlLV/Z/s6imxtmD32Dbl2CZ8YYiRSRN5BYWZnvWgHVjddoe8KpbLIfxpFLo EZwPmu5Ahahwa51UnjNkeTQgHBrEFwG5ye8rWq4tvhH9se3oAhdXFP4sejTtKXgBizGa b00Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=dVCKnQjWrpp/1w6+8eHlMg312Co4DEiyjYdFh/LgqW4=; b=fOXLl5Gu3YdGjjp4iRYDfUeeAdcWGlKgRwwJxai2T4VFwtD1MYQJG7xazjsofTQSOt Y87i3DTIkUaig1cZhwqHMJYPQQtL7LBb9T2gcz6IYNtWtspygkvp/6WlK95rPK1GnxZA BBHclKxa5f8tlfmLWu+oE9SMZZYROlEyFiNq6FOs2AERpUt8/zIvh1H3/KexSm0FZ6C+ rJ/2R4vplAzpGQSO9XcgcxuYVF7oMfORWFarZNGMYQzPtsX4YWSZ1Yvnyk+xx5WXPTHn dhT9sw8gDMb4TcZoNmqFoVTxKg8ZhJlmHn7cFEO1arbi7bovZ1FAAt7+Kbn5MABK4dsh m7QQ== X-Gm-Message-State: ALoCoQn/q5IwUuge7E5KvV2CGVKvEisQJXqAJBI8j41h450opDBQWdGRz+8kU+zuzH3woNWrQmNz1QehND5+V+0ZivmEBNlyupevCW9rWds1a2bKUT62XwH9sQIli0UVvGSqq7LfG0YQcnaySyNCy0oGq1EMSYSmjDb4qxWPNbakicZO8FKNjXwFn4psmYIpLwN0V37NFD3/ MIME-Version: 1.0 X-Received: by 10.182.242.112 with SMTP id wp16mr1699020obc.85.1379088024383; Fri, 13 Sep 2013 09:00:24 -0700 (PDT) Received: by 10.182.250.134 with HTTP; Fri, 13 Sep 2013 09:00:24 -0700 (PDT) In-Reply-To: References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DE89725@wds-exc1.okna.nominet.org.uk> Date: Fri, 13 Sep 2013 09:00:24 -0700 Message-ID: From: Vincent Chen To: Ray Bellis Content-Type: multipart/alternative; boundary=e89a8ff1c9c0cecc3804e645f39c Cc: "paws@ietf.org" Subject: Re: [paws] Encoding of spectrum profile X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 16:00:27 -0000 --e89a8ff1c9c0cecc3804e645f39c Content-Type: text/plain; charset=ISO-8859-1 Ray, Sorry for the delay in response. > My point about being able to represent discontinuities in the frequency > range still appears to stand, however. > I see. Television channels do not occupy a contiguous range of frequencies. In the US, - [54MHz, 72MHz] Channel 2-4 - [76MHz, 88MHz] Channels 5-6 - [174MHz, 216MHz] Channels 7-13 - [470MHz, 698MHz] Channels 14-51 So the response given by the database should not include any frequencies not in the plan. That means a "spectrum profile" should be encoded as a list of "array" of (frequency, power) points. - Each array represents a "profile" for a contiguous range of frequencies - The range of frequencies within a list of profiles MUST be disjoint and SHOULD be sorted - The entire set of frequency bands defined by the regulatory domain MUST be represented by a single list of "profiles" (rather than split them across multiple lists) That last point is to remove ambiguity and, thus, variations in database implementation, to simplify logic on devices. Example: "spectra": [ { "bandwidth": 6e6, "profiles": [ [ { "freqHz": 5.4e7, "maxPsdDbmPerBw": -56.8 }, { "freqHz": 7.2e7, "maxPsdDbmPerBw": -56.8 }, ], [ { "freqHz": 7.6e7, "maxPsdDbmPerBw": -56.8 }, { "freqHz": 8.8e7, "maxPsdDbmPerBw": -56.8 }, ], [ { "freqHz": 1.74e8, "maxPsdDbmPerBw": -56.8 }, { "freqHz": 2.16e8, "maxPsdDbmPerBw": -56.8 }, ], [ { "freqHz": 4.70e8, "maxPsdDbmPerBw": -56.8 }, { "freqHz": 5.18e8, "maxPsdDbmPerBw": -56.8 }, { "freqHz": 5.18e8, "maxPsdDbmPerBw": 30.0 }, { "freqHz": 5.24e8, "maxPsdDbmPerBw": 30.0 }, { "freqHz": 5.24e8, "maxPsdDbmPerBw": 36.0 }, { "freqHz": 5.30e8, "maxPsdDbmPerBw": 36.0 }, { "freqHz": 5.30e8, "maxPsdDbmPerBw": -56.8 }, { "freqHz": 6.98e8, "maxPsdDbmPerBw": -56.8 } ] ] }, { "bandwidth": 1e5, "profiles": [ [ { "freqHz": 5.4e7, "maxPsdDbmPerBw": -74.58 }, { "freqHz": 7.2e7, "maxPsdDbmPerBw": -74.58 }, ], [ { "freqHz": 7.6e7, "maxPsdDbmPerBw": -74.58 }, { "freqHz": 8.8e7, "maxPsdDbmPerBw": -74.58 }, ], [ { "freqHz": 1.74e8, "maxPsdDbmPerBw": -74.58 }, { "freqHz": 2.16e8, "maxPsdDbmPerBw": -74.58 }, ], [ { "freqHz": 4.70e8, "maxPsdDbmPerBw": -74.58 }, { "freqHz": 5.18e8, "maxPsdDbmPerBw": -74.58}, { "freqHz": 5.18e8, "maxPsdDbmPerBw": 27.0 }, { "freqHz": 5.24e8, "maxPsdDbmPerBw": 27.0 }, { "freqHz": 5.24e8, "maxPsdDbmPerBw": 33.0 }, { "freqHz": 5.30e8, "maxPsdDbmPerBw": 33.0 }, { "freqHz": 5.30e8, "maxPsdDbmPerBw": -74.58 }, { "freqHz": 6.98e8, "maxPsdDbmPerBw": -74.58 } ] ] } ] Does that address your concern? -- -vince --e89a8ff1c9c0cecc3804e645f39c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Ray,

Sorry for the delay in response.


My point about being able to represent discontinuities in the frequency ran= ge still appears to stand, however.

I s= ee. Television channels do not occupy a contiguous range of frequencies. In= the US,=A0

=A0 - [54MHz, 72MHz] =A0Channel 2-4
=A0 - [76= MHz, 88MHz] =A0Channels 5-6
=A0 - [174MHz, 216MHz] Channels 7-13<= /div>
=A0 - [470MHz, 698MHz] =A0Channels 14-51

So the response given by the database should not include any frequencies n= ot in the plan.

That means a "spectrum profile" should be enc= oded as a list of "array" of (frequency, power) points.
=A0- Each array represents a "profile" for a contiguous range of= frequencies
=A0- The range of frequencies within a list of profiles MUST be disjoi= nt and SHOULD be sorted
=A0- The entire set of frequency bands de= fined by the regulatory domain MUST be represented by a single list of &quo= t;profiles"
=A0 =A0(rather than split them across multiple lists)

That last point is to remove ambiguity and, thus, variations in da= tabase implementation, to simplify logic on devices.

Example:

"spectra": [
=A0 {
=A0 =A0 "bandwidth": 6e6,
=A0 =A0 "profiles": [
=A0 =A0 =A0 [
=A0 =A0 =A0 =A0 { "freqHz": 5.4e7, "maxPsdDbmPerBw": -5= 6.8 },
=A0 = =A0 =A0 =A0 { "freqHz": 7.2e7, "maxPsdDbmPerBw": -56.8 = },
=A0 =A0 =A0 ],
=A0 =A0 =A0 [
=A0 =A0 =A0 =A0 { "freqHz": 7.6e7, "maxPsdDbmPerBw&qu= ot;: -56.8 },
=A0 =A0 =A0 =A0 { "freqHz": 8.8e7, "maxPsdDbmPerBw": -5= 6.8 },
=A0 = =A0 =A0 ],
= =A0 =A0 =A0 [
=A0 =A0 =A0 =A0 { "freqHz": 1.74e8, "maxPsdDbmPerBw": -= 56.8 },
=A0= =A0 =A0 =A0 { "freqHz": 2.16e8, "maxPsdDbmPerBw": -56.= 8 },
=A0 =A0 =A0 ],
=A0 =A0 =A0 [
=A0 =A0 =A0 =A0 { "freqHz": 4.70e8, &quo= t;maxPsdDbmPerBw": -56.8 },
=A0 =A0 =A0 =A0 { "freqHz": 5.18e8, "maxPsdDbmPerBw&quo= t;: -56.8 },
=A0 =A0 =A0 =A0 { "freqHz": 5.18e8, "= maxPsdDbmPerBw": 30.0 },
=A0 =A0 =A0 =A0 { "freqHz"= ;: 5.24e8, "maxPsdDbmPerBw": 30.0 },
=A0 =A0 =A0 =A0 { "freqHz": 5.24e8, "maxPsdDbmPerBw&quo= t;: 36.0 },
=A0 =A0 =A0 =A0 { "freqHz": 5.30e8, "m= axPsdDbmPerBw": 36.0 },
=A0 =A0 =A0 =A0 { "freqHz"= : 5.30e8, "maxPsdDbmPerBw": -56.8 },
=A0 =A0 =A0 =A0 { "freqHz": 6.98e8, "maxPsdDbmPerBw&quo= t;: -56.8 }
=A0 =A0 =A0 ]
=A0 =A0 ]
=A0 },
=A0 {
=A0 = =A0 "bandwidth": 1e5,
=A0 =A0 "profiles": [
=A0 =A0 =A0 [
=A0 =A0 =A0 =A0 { "freqHz": 5.4e7, "maxPsdDbmPerBw":= =A0-74.58=A0},
=A0 =A0 =A0 =A0 { "freqHz": 7.2e7, "maxPsdDbmPerBw"= :=A0-74.58=A0},
=A0 =A0 =A0 ],
=A0 =A0 =A0 = [
=A0 =A0 = =A0 =A0 { "freqHz": 7.6e7, "maxPsdDbmPerBw":=A0-74.58= =A0},
=A0 =A0 =A0 =A0 = { "freqHz": 8.8e7, "maxPsdDbmPerBw":=A0-74.58=A0},
=A0 =A0 =A0 ],<= /div>
=A0 =A0 =A0 [
=A0 =A0 =A0 =A0 { "freqHz": 1.74e8, "maxPsdDbmPerBw"= :=A0-74.58=A0},
=A0 =A0 =A0 =A0 { "freqHz": 2.16e8, "maxPsdDbmPerBw&quo= t;:=A0-74.58=A0},
=A0 =A0 =A0 ],
=A0 =A0 =A0 = [
=A0 =A0 = =A0 =A0 { "freqHz": 4.70e8, "maxPsdDbmPerBw": -74.58 },=
=A0 =A0 =A0 =A0 = { "freqHz": 5.18e8, "maxPsdDbmPerBw": -74.58},
=A0 =A0 =A0 =A0 { &= quot;freqHz": 5.18e8, "maxPsdDbmPerBw": 27.0 },
=A0 =A0 =A0 =A0 = { "freqHz": 5.24e8, "maxPsdDbmPerBw": 27.0 },
=A0 =A0 =A0 =A0 { &q= uot;freqHz": 5.24e8, "maxPsdDbmPerBw": 33.0 },
=A0 =A0 =A0 =A0 = { "freqHz": 5.30e8, "maxPsdDbmPerBw": 33.0 },
=A0 =A0 =A0 =A0 { &q= uot;freqHz": 5.30e8, "maxPsdDbmPerBw": -74.58 },
=A0 =A0 =A0 =A0 = { "freqHz": 6.98e8, "maxPsdDbmPerBw": -74.58 }
=A0 =A0 =A0 ]
=
=A0 =A0 ]
= =A0 }
]

Does that address your concern?

--
-vince
--e89a8ff1c9c0cecc3804e645f39c-- From peter@spectrumbridge.com Fri Sep 13 09:06:58 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A02FE11E819D for ; Fri, 13 Sep 2013 09:06:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xRzU2m2EILql for ; Fri, 13 Sep 2013 09:06:48 -0700 (PDT) Received: from mail.spectrumbridge.com (mail.spectrumbridge.com [64.132.248.82]) by ietfa.amsl.com (Postfix) with ESMTP id A657411E8167 for ; Fri, 13 Sep 2013 09:06:41 -0700 (PDT) Received: from shelby.sbi.com ([127.0.0.1]) by shelby ([127.0.0.1]) with mapi; Fri, 13 Sep 2013 12:06:39 -0400 From: Peter Stanforth To: Vincent Chen , Ray Bellis Date: Fri, 13 Sep 2013 12:06:33 -0400 Thread-Topic: [paws] Encoding of spectrum profile Thread-Index: Ac6wmzqVe17eCboCQj+8lB5lde/U4g== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CE58AFB217B11peterspectrumbridgecom_" MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] Encoding of spectrum profile X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 16:06:58 -0000 --_000_CE58AFB217B11peterspectrumbridgecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The US is not unique in having discontinuous bands, we have come across a m= ix of VHF and UHF channels in a number of countries. From: Vincent Chen > Date: Friday, September 13, 2013 12:00 PM To: Ray Bellis = > Cc: "paws@ietf.org" > Subject: Re: [paws] Encoding of spectrum profile Ray, Sorry for the delay in response. My point about being able to represent discontinuities in the frequency ran= ge still appears to stand, however. I see. Television channels do not occupy a contiguous range of frequencies.= In the US, - [54MHz, 72MHz] Channel 2-4 - [76MHz, 88MHz] Channels 5-6 - [174MHz, 216MHz] Channels 7-13 - [470MHz, 698MHz] Channels 14-51 So the response given by the database should not include any frequencies no= t in the plan. That means a "spectrum profile" should be encoded as a list of "array" of (= frequency, power) points. - Each array represents a "profile" for a contiguous range of frequencies - The range of frequencies within a list of profiles MUST be disjoint and = SHOULD be sorted - The entire set of frequency bands defined by the regulatory domain MUST = be represented by a single list of "profiles" (rather than split them across multiple lists) That last point is to remove ambiguity and, thus, variations in database im= plementation, to simplify logic on devices. Example: "spectra": [ { "bandwidth": 6e6, "profiles": [ [ { "freqHz": 5.4e7, "maxPsdDbmPerBw": -56.8 }, { "freqHz": 7.2e7, "maxPsdDbmPerBw": -56.8 }, ], [ { "freqHz": 7.6e7, "maxPsdDbmPerBw": -56.8 }, { "freqHz": 8.8e7, "maxPsdDbmPerBw": -56.8 }, ], [ { "freqHz": 1.74e8, "maxPsdDbmPerBw": -56.8 }, { "freqHz": 2.16e8, "maxPsdDbmPerBw": -56.8 }, ], [ { "freqHz": 4.70e8, "maxPsdDbmPerBw": -56.8 }, { "freqHz": 5.18e8, "maxPsdDbmPerBw": -56.8 }, { "freqHz": 5.18e8, "maxPsdDbmPerBw": 30.0 }, { "freqHz": 5.24e8, "maxPsdDbmPerBw": 30.0 }, { "freqHz": 5.24e8, "maxPsdDbmPerBw": 36.0 }, { "freqHz": 5.30e8, "maxPsdDbmPerBw": 36.0 }, { "freqHz": 5.30e8, "maxPsdDbmPerBw": -56.8 }, { "freqHz": 6.98e8, "maxPsdDbmPerBw": -56.8 } ] ] }, { "bandwidth": 1e5, "profiles": [ [ { "freqHz": 5.4e7, "maxPsdDbmPerBw": -74.58 }, { "freqHz": 7.2e7, "maxPsdDbmPerBw": -74.58 }, ], [ { "freqHz": 7.6e7, "maxPsdDbmPerBw": -74.58 }, { "freqHz": 8.8e7, "maxPsdDbmPerBw": -74.58 }, ], [ { "freqHz": 1.74e8, "maxPsdDbmPerBw": -74.58 }, { "freqHz": 2.16e8, "maxPsdDbmPerBw": -74.58 }, ], [ { "freqHz": 4.70e8, "maxPsdDbmPerBw": -74.58 }, { "freqHz": 5.18e8, "maxPsdDbmPerBw": -74.58}, { "freqHz": 5.18e8, "maxPsdDbmPerBw": 27.0 }, { "freqHz": 5.24e8, "maxPsdDbmPerBw": 27.0 }, { "freqHz": 5.24e8, "maxPsdDbmPerBw": 33.0 }, { "freqHz": 5.30e8, "maxPsdDbmPerBw": 33.0 }, { "freqHz": 5.30e8, "maxPsdDbmPerBw": -74.58 }, { "freqHz": 6.98e8, "maxPsdDbmPerBw": -74.58 } ] ] } ] Does that address your concern? -- -vince --_000_CE58AFB217B11peterspectrumbridgecom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
The US is not unique in = having discontinuous bands, we have come across a mix of VHF and UHF channe= ls in a number of countries. 

From: Vincent Chen <vchen@google.com>
Date= : Friday, September 13, 2013 12:00 PM
To: Ray Bellis <Ray.Bellis@nominet.org.uk>
C= c: "paws@ietf.org" <paws@ietf.org>
Subject: Re: [paws] Encoding of spectrum profile
=

Ray,

Sorry for the delay in response.


My point about being able to represent discontinuities in the frequency ran= ge still appears to stand, however.

I s= ee. Television channels do not occupy a contiguous range of frequencies. In= the US, 

  - [54MHz, 72MHz]  Chann= el 2-4
  - [76MHz, 88MHz]  Channels 5-6
 = ; - [174MHz, 216MHz] Channels 7-13
  - [470MHz, 698MHz] &nbs= p;Channels 14-51

So the response given by the data= base should not include any frequencies not in the plan.

That means a "spectrum profile" should be encoded as a list of "arra= y" of (frequency, power) points.
 - Each array represents a = "profile" for a contiguous range of frequencies
 - The range= of frequencies within a list of profiles MUST be disjoint and SHOULD be so= rted
 - The entire set of frequency bands defined by the reg= ulatory domain MUST be represented by a single list of "profiles"
   (rather than split them across multiple lists)

=
That last point is to remove ambiguity and, thus, variations in = database implementation, to simplify logic on devices.

=
Example:

"spectra": [
  {
    "bandwidth": 6e6,
    "profiles": [
    =   [
&n= bsp;       { "freqHz": 5.4e7, "maxPsdDbmPerBw": -56.8 },
    =     { "freqHz": 7.2e7, "maxPsdDbmPerBw": -56.8 },
      ],
   =   [
&= nbsp;       { "freqHz": 7.6e7, "maxPsdDbmPerBw": -56.8 },
   =     { "freqHz": 8.8e7, "maxPsdDbmPerBw": -56.8 },
      ],
   = ;   [
=         { "freqHz": 1.74e8, "maxPsdDbmPerBw": -56.8 },<= /div>
  &nbs= p;     { "freqHz": 2.16e8, "maxPsdDbmPerBw": -56.8 },
      ]= ,
  &n= bsp;   [
        { "freqHz": 4.70e8, "maxPs= dDbmPerBw": -56.8 },
        { "freqHz": 5.18= e8, "maxPsdDbmPerBw": -56.8 },
        { "fre= qHz": 5.18e8, "maxPsdDbmPerBw": 30.0 },
      &nbs= p; { "freqHz": 5.24e8, "maxPsdDbmPerBw": 30.0 },
    &n= bsp;   { "freqHz": 5.24e8, "maxPsdDbmPerBw": 36.0 },
  =       { "freqHz": 5.30e8, "maxPsdDbmPerBw": 36.0 },
        { "freqHz": 5.30e8, "maxPsdDbmPerBw": -56.8 }= ,
        { "freqHz": 6.98e8, "maxPsdDbmPerBw= ": -56.8 }
      ]
    ]
=
  },<= /div>
  {
   = "bandwidth": 1e5,
    "profiles": [
      [
        { "freqHz"= : 5.4e7, "maxPsdDbmPerBw": -74.58 },
        { "freqHz":= 7.2e7, "maxPsdDbmPerBw": -74.58 },
      ],
      [
    =     { "freqHz": 7.6e7, "maxPsdDbmPerBw": -74.58 },
    &= nbsp;   { "freqHz": 8.8e7, "maxPsdDbmPerBw": -74.58 },
=
    &n= bsp; ],
&nb= sp;     [
        { "freqHz": 1.74e8, "maxPsdDbmPerBw":&= nbsp;-74.58 },
        { "freqHz": 2.16e8, "maxPsdDbmPerBw":&= nbsp;-74.58 },
      ],
      [
        { "freqHz": 4= .70e8, "maxPsdDbmPerBw": -74.58 },
        { "freqHz": 5.18e8, "ma= xPsdDbmPerBw": -74.58},
        { "freqHz": 5.18e8, "maxPsdDbmPerB= w": 27.0 },
        { "freqHz": 5.24e8, "maxPsdDbmPerBw": 27.0 },<= /div>
  &nbs= p;     { "freqHz": 5.24e8, "maxPsdDbmPerBw": 33.0 },
      &n= bsp; { "freqHz": 5.30e8, "maxPsdDbmPerBw": 33.0 },
        { "freq= Hz": 5.30e8, "maxPsdDbmPerBw": -74.58 },
        { "freqHz": 6.98e= 8, "maxPsdDbmPerBw": -74.58 }
      ]
    ]
  }
]

Does tha= t address your concern?

--
-vince
--_000_CE58AFB217B11peterspectrumbridgecom_-- From vchen@google.com Fri Sep 13 09:33:19 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 595FA21F9BEB for ; Fri, 13 Sep 2013 09:33:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.575 X-Spam-Level: X-Spam-Status: No, score=-1.575 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HNE4yj2zIzUv for ; Fri, 13 Sep 2013 09:33:18 -0700 (PDT) Received: from mail-oa0-x229.google.com (mail-oa0-x229.google.com [IPv6:2607:f8b0:4003:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id E21A621E8105 for ; Fri, 13 Sep 2013 09:33:11 -0700 (PDT) Received: by mail-oa0-f41.google.com with SMTP id j6so1386154oag.28 for ; Fri, 13 Sep 2013 09:33:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7BYTLzkVjYfIsWsl3lzk5F1Ptt8omjhZAakaM2qYtLo=; b=gcwLrGJGEoSd9aVwnMcLVoSUKYnmsC9GJGjhFpDTqPOl4zhi/F9zKk0//R3Mv/e37n TD4kn7uztvsg5C8S1NO3gh11ggl9gpFMmzlmfFUiP2Pan78NoifHd/fg+YatwFWendu1 b6ezEHrVTYf11oiToBe0SKSRTy/DxrMIxXW9k4wIg/X66S2Y+SXcWNwCyN8sJkQu4CyT 3nT5O363LZRsCd9t0eJEcKCNQDbA6Gv0pcXkAT43JSDpKFeTtP3imti5V3+bUohTzcVv 1zoIwDUgHXjkbGbndH+UbMnRGq8j9kllqJGt1+L1sruL5HiukCf029A85zRidJTWyzX3 CEYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=7BYTLzkVjYfIsWsl3lzk5F1Ptt8omjhZAakaM2qYtLo=; b=HCLv7t+zbrI0aWjyhCLcfUvAldVFbhho1uZe4MwVEhKVqdmVw7zwAzNiVKDskl1W6E +CaOFdUwpRfzhVegWZtG5PxmdwgKTw+RwJZ4KOrBMNSVA2k5X6LNwH+eHLwUQR1JrvHh TJMXN9097RsLqFNw8eyNTIfR+MS60qxYHr4xmv9DOX8NGzPDzke2uv9VJIo+9KA8mNQ5 +OgqP37v9P0HmuzDuTwtcT6AIOMyqauM0E9kyUqAAx7NjXOgqVkjkGhdQdJ3LcRG4t7I XgSLISvG0hMlP+UdyVbUjCsnTlrmgAlPOOq+bO24xSkKmTpyK1vPjYxvoVXQUpoWKNNx QeHQ== X-Gm-Message-State: ALoCoQl7AFbkmxEu8KkSSsvMDZ2o+Hvuysj9EV9Z4bV9cHdPvJN/Tfs11BaPDgqorQblNFs52KpZEMZQqqVWdIEb1WcNUJsiMRdvvgW14JNFVNe5WXP58tMnOO9gUMv+sFTM7TT13y21bL/dggIhq4avcg7cN67P1KKF+JT24CAXhq1JAIt+y6NAPbkRkwdsEzAdMDls2PFg MIME-Version: 1.0 X-Received: by 10.60.84.165 with SMTP id a5mr1806559oez.83.1379089990323; Fri, 13 Sep 2013 09:33:10 -0700 (PDT) Received: by 10.182.250.134 with HTTP; Fri, 13 Sep 2013 09:33:09 -0700 (PDT) In-Reply-To: References: Date: Fri, 13 Sep 2013 09:33:09 -0700 Message-ID: From: Vincent Chen To: Peter Stanforth Content-Type: multipart/alternative; boundary=089e01182678fcab3a04e64668fd Cc: "paws@ietf.org" Subject: Re: [paws] Encoding of spectrum profile X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 16:33:19 -0000 --089e01182678fcab3a04e64668fd Content-Type: text/plain; charset=ISO-8859-1 Peter, Agreed. So it is important for the protocol to be able to represent discontiguous bands. Thanks. -vince On Fri, Sep 13, 2013 at 9:06 AM, Peter Stanforth wrote: > The US is not unique in having discontinuous bands, we have come across a > mix of VHF and UHF channels in a number of countries. > > From: Vincent Chen > Date: Friday, September 13, 2013 12:00 PM > To: Ray Bellis > Cc: "paws@ietf.org" > > Subject: Re: [paws] Encoding of spectrum profile > > Ray, > > Sorry for the delay in response. > > >> My point about being able to represent discontinuities in the frequency >> range still appears to stand, however. >> > > I see. Television channels do not occupy a contiguous range of > frequencies. In the US, > > - [54MHz, 72MHz] Channel 2-4 > - [76MHz, 88MHz] Channels 5-6 > - [174MHz, 216MHz] Channels 7-13 > - [470MHz, 698MHz] Channels 14-51 > > So the response given by the database should not include any frequencies > not in the plan. > > That means a "spectrum profile" should be encoded as a list of "array" of > (frequency, power) points. > - Each array represents a "profile" for a contiguous range of frequencies > - The range of frequencies within a list of profiles MUST be disjoint and > SHOULD be sorted > - The entire set of frequency bands defined by the regulatory domain MUST > be represented by a single list of "profiles" > (rather than split them across multiple lists) > > That last point is to remove ambiguity and, thus, variations in database > implementation, to simplify logic on devices. > > Example: > > "spectra": [ > { > "bandwidth": 6e6, > "profiles": [ > [ > { "freqHz": 5.4e7, "maxPsdDbmPerBw": -56.8 }, > { "freqHz": 7.2e7, "maxPsdDbmPerBw": -56.8 }, > ], > [ > { "freqHz": 7.6e7, "maxPsdDbmPerBw": -56.8 }, > { "freqHz": 8.8e7, "maxPsdDbmPerBw": -56.8 }, > ], > [ > { "freqHz": 1.74e8, "maxPsdDbmPerBw": -56.8 }, > { "freqHz": 2.16e8, "maxPsdDbmPerBw": -56.8 }, > ], > [ > { "freqHz": 4.70e8, "maxPsdDbmPerBw": -56.8 }, > { "freqHz": 5.18e8, "maxPsdDbmPerBw": -56.8 }, > { "freqHz": 5.18e8, "maxPsdDbmPerBw": 30.0 }, > { "freqHz": 5.24e8, "maxPsdDbmPerBw": 30.0 }, > { "freqHz": 5.24e8, "maxPsdDbmPerBw": 36.0 }, > { "freqHz": 5.30e8, "maxPsdDbmPerBw": 36.0 }, > { "freqHz": 5.30e8, "maxPsdDbmPerBw": -56.8 }, > { "freqHz": 6.98e8, "maxPsdDbmPerBw": -56.8 } > ] > ] > }, > { > "bandwidth": 1e5, > "profiles": [ > [ > { "freqHz": 5.4e7, "maxPsdDbmPerBw": -74.58 }, > { "freqHz": 7.2e7, "maxPsdDbmPerBw": -74.58 }, > ], > [ > { "freqHz": 7.6e7, "maxPsdDbmPerBw": -74.58 }, > { "freqHz": 8.8e7, "maxPsdDbmPerBw": -74.58 }, > ], > [ > { "freqHz": 1.74e8, "maxPsdDbmPerBw": -74.58 }, > { "freqHz": 2.16e8, "maxPsdDbmPerBw": -74.58 }, > ], > [ > { "freqHz": 4.70e8, "maxPsdDbmPerBw": -74.58 }, > { "freqHz": 5.18e8, "maxPsdDbmPerBw": -74.58}, > { "freqHz": 5.18e8, "maxPsdDbmPerBw": 27.0 }, > { "freqHz": 5.24e8, "maxPsdDbmPerBw": 27.0 }, > { "freqHz": 5.24e8, "maxPsdDbmPerBw": 33.0 }, > { "freqHz": 5.30e8, "maxPsdDbmPerBw": 33.0 }, > { "freqHz": 5.30e8, "maxPsdDbmPerBw": -74.58 }, > { "freqHz": 6.98e8, "maxPsdDbmPerBw": -74.58 } > ] > ] > } > ] > > Does that address your concern? > > -- > -vince > -- -vince --089e01182678fcab3a04e64668fd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Peter,

Agreed. So it is important for t= he protocol to be able to represent discontiguous bands. Thanks.
=
-vince


On Fri, Sep 13, 2013 at 9:06 AM, Peter Stanforth <peter@spectrumbri= dge.com> wrote:
The US is not unique in having discontinuous bands, we have com= e across a mix of VHF and UHF channels in a number of countries.=A0

From: Vincent Chen <vchen@google.com>
Date: Friday, September 13, 2013 12:00= PM
To: Ray Bellis <Ray.Bellis@nominet.org.uk>
Cc: "paws@ietf.org" <paws@ietf.org>

Subject: Re: [paws] Encoding o= f spectrum profile

Ray,

Sorry for the delay in response.


My point about being able to represent discontinuities in the frequency ran= ge still appears to stand, however.

I s= ee. Television channels do not occupy a contiguous range of frequencies. In= the US,=A0

=A0 - [54MHz, 72MHz] =A0Channel 2-4
=A0 - [76= MHz, 88MHz] =A0Channels 5-6
=A0 - [174MHz, 216MHz] Channels 7-13<= /div>
=A0 - [470MHz, 698MHz] =A0Channels 14-51

So the response given by the database should not include any frequencies n= ot in the plan.

That means a "spectrum profile" should be enc= oded as a list of "array" of (frequency, power) points.
=A0- Each array represents a "profile" for a contiguous range of= frequencies
=A0- The range of frequencies within a list of profiles MUST be disjoi= nt and SHOULD be sorted
=A0- The entire set of frequency bands de= fined by the regulatory domain MUST be represented by a single list of &quo= t;profiles"
=A0 =A0(rather than split them across multiple lists)

That last point is to remove ambiguity and, thus, variations in da= tabase implementation, to simplify logic on devices.

Example:

"spectra": [
=A0 {
=A0 =A0 "bandwidth": 6e6,
=A0 =A0 "profiles": [
=A0 =A0 =A0 [
=A0 =A0 =A0 =A0 { "freqHz": 5.4e7, "maxPsdDbmPerBw": -5= 6.8 },
=A0 = =A0 =A0 =A0 { "freqHz": 7.2e7, "maxPsdDbmPerBw": -56.8 = },
=A0 =A0 =A0 ],
=A0 =A0 =A0 [
=A0 =A0 =A0 =A0 { "freqHz": 7.6e7, "maxPsdDbmPerBw&qu= ot;: -56.8 },
=A0 =A0 =A0 =A0 { "freqHz": 8.8e7, "maxPsdDbmPerBw": -5= 6.8 },
=A0 = =A0 =A0 ],
= =A0 =A0 =A0 [
=A0 =A0 =A0 =A0 { "freqHz": 1.74e8, "maxPsdDbmPerBw": -= 56.8 },
=A0= =A0 =A0 =A0 { "freqHz": 2.16e8, "maxPsdDbmPerBw": -56.= 8 },
=A0 =A0 =A0 ],
=A0 =A0 =A0 [
=A0 =A0 =A0 =A0 { "freqHz": 4.70e8, "maxPsdDbmPe= rBw": -56.8 },
=A0 =A0 =A0 =A0 { "freqHz": 5.18e8, "maxPsdDbmPerBw&quo= t;: -56.8 },
=A0 =A0 =A0 =A0 { "freqHz": 5.18e8, "= maxPsdDbmPerBw": 30.0 },
=A0 =A0 =A0 =A0 { "freqHz"= ;: 5.24e8, "maxPsdDbmPerBw": 30.0 },
=A0 =A0 =A0 =A0 { "freqHz": 5.24e8, "maxPsdDbmPerBw&quo= t;: 36.0 },
=A0 =A0 =A0 =A0 { "freqHz": 5.30e8, "m= axPsdDbmPerBw": 36.0 },
=A0 =A0 =A0 =A0 { "freqHz"= : 5.30e8, "maxPsdDbmPerBw": -56.8 },
=A0 =A0 =A0 =A0 { "freqHz": 6.98e8, "maxPsdDbmPerBw&quo= t;: -56.8 }
=A0 =A0 =A0 ]
=A0 =A0 ]
=A0 },
=A0 {
=A0 = =A0 "bandwidth": 1e5,
=A0 =A0 "profiles": [
=A0 =A0 =A0 [
=A0 =A0 =A0 =A0 { "freqHz": 5.4e7, "maxPsdDbmPerBw":= =A0-74.58=A0},
=A0 =A0 =A0 =A0 { "freqHz": 7.2e7, "maxPsdDbmPerBw"= :=A0-74.58=A0},
=A0 =A0 =A0 ],
=A0 =A0 =A0 = [
=A0 =A0 = =A0 =A0 { "freqHz": 7.6e7, "maxPsdDbmPerBw":=A0-74.58= =A0},
=A0 =A0 =A0 =A0 = { "freqHz": 8.8e7, "maxPsdDbmPerBw":=A0-74.58=A0},
=A0 =A0 =A0 ],<= /div>
=A0 =A0 =A0 [
=A0 =A0 =A0 =A0 { "freqHz": 1.74e8, "maxPsdDbmPerBw"= :=A0-74.58=A0},
=A0 =A0 =A0 =A0 { "freqHz": 2.16e8, "maxPsdDbmPerBw&quo= t;:=A0-74.58=A0},
=A0 =A0 =A0 ],
=A0 =A0 =A0 = [
=A0 =A0 = =A0 =A0 { "freqHz": 4.70e8, "maxPsdDbmPerBw": -74.58 },=
=A0 =A0 =A0 =A0 = { "freqHz": 5.18e8, "maxPsdDbmPerBw": -74.58},
=A0 =A0 =A0 =A0 { &= quot;freqHz": 5.18e8, "maxPsdDbmPerBw": 27.0 },
=A0 =A0 =A0 =A0 = { "freqHz": 5.24e8, "maxPsdDbmPerBw": 27.0 },
=A0 =A0 =A0 =A0 { &q= uot;freqHz": 5.24e8, "maxPsdDbmPerBw": 33.0 },
=A0 =A0 =A0 =A0 = { "freqHz": 5.30e8, "maxPsdDbmPerBw": 33.0 },
=A0 =A0 =A0 =A0 { &q= uot;freqHz": 5.30e8, "maxPsdDbmPerBw": -74.58 },
=A0 =A0 =A0 =A0 = { "freqHz": 6.98e8, "maxPsdDbmPerBw": -74.58 }
=A0 =A0 =A0 ]
=
=A0 =A0 ]
= =A0 }
]

Does that address your concern?

--
-vince



--
-vince
--089e01182678fcab3a04e64668fd-- From sajeevmanikkoth@gmail.com Fri Sep 13 20:04:03 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E95D921E8085 for ; Fri, 13 Sep 2013 20:04:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WOM5LcFSChaZ for ; Fri, 13 Sep 2013 20:04:03 -0700 (PDT) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 3D98111E811D for ; Fri, 13 Sep 2013 20:03:56 -0700 (PDT) Received: by mail-pa0-f52.google.com with SMTP id kq13so3236382pab.39 for ; Fri, 13 Sep 2013 20:03:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:thread-index:content-language; bh=crLT8wlrFKP0dJHe5qVx4qGbLrXss6U2SLWFREmgAR8=; b=u7sMgCObajSWNnLbVYWoWvqZwqR8RSnACelXCN1e4WfxhU7RzWuiooI/zdHlkZWqIL PUSnd+XbiZLWbJqQZxm5klpm1BDvA+RCbHW9cf6QOro3lFHYzEAWkPx1IE3z5LUf4+54 E04QGo8wMgvJd7zytzeDXI90KHrcYaJFuOIJRjZJaHvEg3fhLWeQ9LBl5BNsU+j8pPR5 TXdSdxT3pktYQMQqfcEJ+nSbY5DADiWqdr62PogK61Yq9jBBfV9AboLQjmwPHIfdP2a/ vuv8VWBBBCAkx0Xgz04klHtiodkkV6wIgpoDoS1IwnsNpXyFVZkrxCxPdh/9rprLkAMj LBUw== X-Received: by 10.66.140.40 with SMTP id rd8mr994530pab.119.1379127833860; Fri, 13 Sep 2013 20:03:53 -0700 (PDT) Received: from adminPC ([117.213.240.26]) by mx.google.com with ESMTPSA id ht5sm15146164pbb.29.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 13 Sep 2013 20:03:52 -0700 (PDT) From: sajeevmanikkoth@gmail.com To: "'Vincent Chen'" , "'Peter Stanforth'" References: In-Reply-To: Date: Sat, 14 Sep 2013 08:33:48 +0530 Message-ID: <001201ceb0f7$0c4cbf10$24e63d30$@org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0013_01CEB125.2604FB10" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac6wnvaq5jsf1JxoTqqoNgAe/rgiCgAVm1Ng Content-Language: en-us Cc: paws@ietf.org Subject: Re: [paws] Encoding of spectrum profile X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Sep 2013 03:04:04 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0013_01CEB125.2604FB10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, Not just the spectrum is available in non-contiguous bands, but a whitespace radio with higher bandwidth requirement may use non-contiguous spectrum aggregation, and consume available spectrum across multiple bands too. Thanks and Regards, Sajeev From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Vincent Chen Sent: Friday, September 13, 2013 10:03 PM To: Peter Stanforth Cc: paws@ietf.org Subject: Re: [paws] Encoding of spectrum profile Peter, Agreed. So it is important for the protocol to be able to represent discontiguous bands. Thanks. -vince On Fri, Sep 13, 2013 at 9:06 AM, Peter Stanforth wrote: The US is not unique in having discontinuous bands, we have come across a mix of VHF and UHF channels in a number of countries. From: Vincent Chen Date: Friday, September 13, 2013 12:00 PM To: Ray Bellis Cc: "paws@ietf.org" Subject: Re: [paws] Encoding of spectrum profile Ray, Sorry for the delay in response. My point about being able to represent discontinuities in the frequency range still appears to stand, however. I see. Television channels do not occupy a contiguous range of frequencies. In the US, - [54MHz, 72MHz] Channel 2-4 - [76MHz, 88MHz] Channels 5-6 - [174MHz, 216MHz] Channels 7-13 - [470MHz, 698MHz] Channels 14-51 So the response given by the database should not include any frequencies not in the plan. That means a "spectrum profile" should be encoded as a list of "array" of (frequency, power) points. - Each array represents a "profile" for a contiguous range of frequencies - The range of frequencies within a list of profiles MUST be disjoint and SHOULD be sorted - The entire set of frequency bands defined by the regulatory domain MUST be represented by a single list of "profiles" (rather than split them across multiple lists) That last point is to remove ambiguity and, thus, variations in database implementation, to simplify logic on devices. Example: "spectra": [ { "bandwidth": 6e6, "profiles": [ [ { "freqHz": 5.4e7, "maxPsdDbmPerBw": -56.8 }, { "freqHz": 7.2e7, "maxPsdDbmPerBw": -56.8 }, ], [ { "freqHz": 7.6e7, "maxPsdDbmPerBw": -56.8 }, { "freqHz": 8.8e7, "maxPsdDbmPerBw": -56.8 }, ], [ { "freqHz": 1.74e8, "maxPsdDbmPerBw": -56.8 }, { "freqHz": 2.16e8, "maxPsdDbmPerBw": -56.8 }, ], [ { "freqHz": 4.70e8, "maxPsdDbmPerBw": -56.8 }, { "freqHz": 5.18e8, "maxPsdDbmPerBw": -56.8 }, { "freqHz": 5.18e8, "maxPsdDbmPerBw": 30.0 }, { "freqHz": 5.24e8, "maxPsdDbmPerBw": 30.0 }, { "freqHz": 5.24e8, "maxPsdDbmPerBw": 36.0 }, { "freqHz": 5.30e8, "maxPsdDbmPerBw": 36.0 }, { "freqHz": 5.30e8, "maxPsdDbmPerBw": -56.8 }, { "freqHz": 6.98e8, "maxPsdDbmPerBw": -56.8 } ] ] }, { "bandwidth": 1e5, "profiles": [ [ { "freqHz": 5.4e7, "maxPsdDbmPerBw": -74.58 }, { "freqHz": 7.2e7, "maxPsdDbmPerBw": -74.58 }, ], [ { "freqHz": 7.6e7, "maxPsdDbmPerBw": -74.58 }, { "freqHz": 8.8e7, "maxPsdDbmPerBw": -74.58 }, ], [ { "freqHz": 1.74e8, "maxPsdDbmPerBw": -74.58 }, { "freqHz": 2.16e8, "maxPsdDbmPerBw": -74.58 }, ], [ { "freqHz": 4.70e8, "maxPsdDbmPerBw": -74.58 }, { "freqHz": 5.18e8, "maxPsdDbmPerBw": -74.58}, { "freqHz": 5.18e8, "maxPsdDbmPerBw": 27.0 }, { "freqHz": 5.24e8, "maxPsdDbmPerBw": 27.0 }, { "freqHz": 5.24e8, "maxPsdDbmPerBw": 33.0 }, { "freqHz": 5.30e8, "maxPsdDbmPerBw": 33.0 }, { "freqHz": 5.30e8, "maxPsdDbmPerBw": -74.58 }, { "freqHz": 6.98e8, "maxPsdDbmPerBw": -74.58 } ] ] } ] Does that address your concern? -- -vince -- -vince ------=_NextPart_000_0013_01CEB125.2604FB10 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Not just the spectrum is available in non-contiguous = bands, but a whitespace radio with higher bandwidth requirement may use = non-contiguous spectrum aggregation, and consume available spectrum across multiple = bands too.

 

Thanks and Regards,

Sajeev

 

From:= paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of = Vincent Chen
Sent: Friday, September 13, 2013 10:03 PM
To: Peter Stanforth
Cc: paws@ietf.org
Subject: Re: [paws] Encoding of spectrum = profile

 

Peter,

 

Agreed. So it is important for the protocol to be = able to represent discontiguous bands. Thanks.

 

-vince

 

On Fri, Sep 13, 2013 at 9:06 AM, Peter Stanforth = <peter@spectrumbridge.com> wrote:

The US is not unique in having discontinuous bands, we have come across a = mix of VHF and UHF channels in a number of = countries. 

 =

From: Vincent Chen <vchen@google.com>
Date: Friday, September 13, 2013 12:00 PM
To: Ray Bellis <Ray.Bellis@nominet.org.uk>
Cc: "paws@ietf.org" <paws@ietf.org>


Subject: Re: [paws] Encoding of spectrum = profile

 =

Ray,

 =

Sorry for the delay in response.

 =


My point about being able to represent discontinuities in the frequency = range still appears to stand, however.

 =

I see. Television channels do not occupy a contiguous range of = frequencies. In the US, 

 =

  - [54MHz, 72MHz]  Channel 2-4

  - [76MHz, 88MHz]  Channels 5-6

  - [174MHz, 216MHz] Channels 7-13

  - [470MHz, 698MHz]  Channels 14-51

 =

So the response given by the database should not include any frequencies = not in the plan.

 =

That means a "spectrum profile" should be encoded as a list of "array" of (frequency, power) points.

 - Each array represents a "profile" for a contiguous range of frequencies

 - The range of frequencies within a list of profiles MUST be disjoint and = SHOULD be sorted

 - The entire set of frequency bands defined by the regulatory domain MUST = be represented by a single list of = "profiles"

   (rather than split them across multiple = lists)

 =

That last point is to remove ambiguity and, thus, variations in database implementation, to simplify logic on devices.

 =

Example:

 =

"spectra= ": [

  {

    "bandwidth": 6e6,

    "profiles": [

      [

        { "freqHz": 5.4e7, = "maxPsdDbmPerBw": -56.8 },

        { "freqHz": 7.2e7, = "maxPsdDbmPerBw": -56.8 },

      ],

      [

        { "freqHz": 7.6e7, = "maxPsdDbmPerBw": -56.8 },

        { "freqHz": 8.8e7, = "maxPsdDbmPerBw": -56.8 },

      ],

      [

        { "freqHz": 1.74e8, = "maxPsdDbmPerBw": -56.8 },

        { "freqHz": 2.16e8, = "maxPsdDbmPerBw": -56.8 },

      ],

      [

        { "freqHz": 4.70e8, = "maxPsdDbmPerBw": -56.8 },

        { "freqHz": 5.18e8, = "maxPsdDbmPerBw": -56.8 },

        { "freqHz": 5.18e8, = "maxPsdDbmPerBw": 30.0 },

        { "freqHz": 5.24e8, = "maxPsdDbmPerBw": 30.0 },

        { "freqHz": 5.24e8, = "maxPsdDbmPerBw": 36.0 },

        { "freqHz": 5.30e8, = "maxPsdDbmPerBw": 36.0 },

        { "freqHz": 5.30e8, = "maxPsdDbmPerBw": -56.8 },

        { "freqHz": 6.98e8, = "maxPsdDbmPerBw": -56.8 }

      ]

    ]

  },

  {

    "bandwidth": 1e5,

    "profiles": [

      [

        { "freqHz": 5.4e7, "maxPsdDbmPerBw": -74.58 },

        { "freqHz": 7.2e7, "maxPsdDbmPerBw": -74.58 },

      ],

      [

        { "freqHz": 7.6e7, "maxPsdDbmPerBw": -74.58 },

        { "freqHz": 8.8e7, "maxPsdDbmPerBw": -74.58 },

      ],

      [

        { "freqHz": 1.74e8, "maxPsdDbmPerBw": -74.58 },

        { "freqHz": 2.16e8, "maxPsdDbmPerBw": -74.58 },

      ],

      [

        { "freqHz": 4.70e8, = "maxPsdDbmPerBw": -74.58 },

        { "freqHz": 5.18e8, = "maxPsdDbmPerBw": -74.58},

        { "freqHz": 5.18e8, = "maxPsdDbmPerBw": 27.0 },

        { "freqHz": 5.24e8, = "maxPsdDbmPerBw": 27.0 },

        { "freqHz": 5.24e8, = "maxPsdDbmPerBw": 33.0 },

        { "freqHz": 5.30e8, = "maxPsdDbmPerBw": 33.0 },

        { "freqHz": 5.30e8, = "maxPsdDbmPerBw": -74.58 },

        { "freqHz": 6.98e8, = "maxPsdDbmPerBw": -74.58 }

      ]

    ]

  }

]<= /span>

 =

Does that address your concern?

 =

--
-vince



 

--
-vince

------=_NextPart_000_0013_01CEB125.2604FB10-- From ben@blindcreek.com Sat Sep 14 19:33:35 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99F8E21F9A5F for ; Sat, 14 Sep 2013 19:33:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.805 X-Spam-Level: X-Spam-Status: No, score=0.805 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B4x9eSVNMR40 for ; Sat, 14 Sep 2013 19:33:30 -0700 (PDT) Received: from blu0-omc3-s22.blu0.hotmail.com (blu0-omc3-s22.blu0.hotmail.com [65.55.116.97]) by ietfa.amsl.com (Postfix) with ESMTP id 34D3821F860A for ; Sat, 14 Sep 2013 19:33:29 -0700 (PDT) Received: from BLU0-SMTP246 ([65.55.116.73]) by blu0-omc3-s22.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 14 Sep 2013 19:33:29 -0700 X-TMN: [VjwD1pdLTO5nHB2Fd0isJcjj1ot35i60] X-Originating-Email: [ben@blindcreek.com] Message-ID: Received: from [127.0.0.1] ([58.212.29.24]) by BLU0-SMTP246.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sat, 14 Sep 2013 19:33:27 -0700 Date: Sat, 14 Sep 2013 19:33:25 -0700 From: "Benjamin A. Rolfe" User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: paws@ietf.org References: <001201ceb0f7$0c4cbf10$24e63d30$@org> In-Reply-To: <001201ceb0f7$0c4cbf10$24e63d30$@org> Content-Type: multipart/alternative; boundary="------------090601090707060100050301" X-Antivirus: avast! (VPS 130914-1, 09/14/2013), Outbound message X-Antivirus-Status: Not-Tested X-OriginalArrivalTime: 15 Sep 2013 02:33:28.0254 (UTC) FILETIME=[F5E1CDE0:01CEB1BB] Sender: Subject: Re: [paws] Encoding of spectrum profile X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Sep 2013 02:33:35 -0000 --------------090601090707060100050301 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit The Whitespace spectrum allocations I have been following in various regions are made of of non-contiguous collections of contiguous spectrum, as illustrated by the US situation for TVWS below: each TV channel is a contiguous chunk of spectrum 6MHz wide; TV channels are spread dis-contiguously across the spectrum. . Multiple standards exist and others are under development to utilize whitespace allocations. In 802.11, mhe ultiple TV channels may be aggregated to one 802.11 channel; in 802.15 we do e opposite: we divide a single TV channel into many physical channels. In the current drafts, we assume the database provides the boundaries of the TV channel (somehow) and the standard maps that to the PHY channels defined. There is also a need to specify unavailability of a small part of a TV channel. The regional regulations for allowable use, in particular the methods for specifying transmit signal energy limitations, vary greatly. In the US the current TVWS is quite simple compared how power limits are specified in other bands. As we see the whitespace concept catching on (and it seems to be), I expect we will see the variety of methods used in other subparts of Part 15 applied. If the goal is to be able to get this information from the database so an implementation can be regulation agnostic, it may be wise to look at some of the methods likely to be applied when we move beyond "TVWS" into application of the whitespace management concept to other spectrum allocations. In Part 15 we see emission limits expressed as total power in a specified bandwidth, peak measured in any xHz accross the entire signal or band, field strength (energy level measured at a specified distance) and several other methods. In the more popular license exempt bands we have different methods applied, with different effective emissions limits, that are based on modulation type, modulation bandwidth (signalling rate), how the band is sub-divided into communcation channels (number of channels and occupied bandwidth of each), if the system employs frequency hopping, etc. We also see constraints such as minimum and maximum occupied bandwidth for a communications channel. I don't know if there is much concern over data volume for database exchanges. Specifying an approximation of a spectral mask point by point is possible, but may become quite a few points. There are a few standard models for approximating spectral shape which could be used to reduce the data volume, which may have value in the long run. A few thoughts I hope will help from a humble and hopeful future user of the protocol! -Ben On 9/13/2013 8:03 PM, sajeevmanikkoth@gmail.com wrote: > > Hi, > > Not just the spectrum is available in non-contiguous bands, but a > whitespace radio with higher bandwidth requirement may use > non-contiguous spectrum aggregation, and consume available spectrum > across multiple bands too. > > Thanks and Regards, > > Sajeev > > *From:*paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] *On Behalf > Of *Vincent Chen > *Sent:* Friday, September 13, 2013 10:03 PM > *To:* Peter Stanforth > *Cc:* paws@ietf.org > *Subject:* Re: [paws] Encoding of spectrum profile > > Peter, > > Agreed. So it is important for the protocol to be able to represent > discontiguous bands. Thanks. > > -vince > > On Fri, Sep 13, 2013 at 9:06 AM, Peter Stanforth > > wrote: > > The US is not unique in having discontinuous bands, we have come > across a mix of VHF and UHF channels in a number of countries. > > *From: *Vincent Chen > > *Date: *Friday, September 13, 2013 12:00 PM > *To: *Ray Bellis > > *Cc: *"paws@ietf.org " > > > > *Subject: *Re: [paws] Encoding of spectrum profile > > Ray, > > Sorry for the delay in response. > > > My point about being able to represent discontinuities in the > frequency range still appears to stand, however. > > I see. Television channels do not occupy a contiguous range of > frequencies. In the US, > > - [54MHz, 72MHz] Channel 2-4 > > - [76MHz, 88MHz] Channels 5-6 > > - [174MHz, 216MHz] Channels 7-13 > > - [470MHz, 698MHz] Channels 14-51 > > So the response given by the database should not include any > frequencies not in the plan. > > That means a "spectrum profile" should be encoded as a list of "array" > of (frequency, power) points. > > - Each array represents a "profile" for a contiguous range of frequencies > > - The range of frequencies within a list of profiles MUST be disjoint > and SHOULD be sorted > > - The entire set of frequency bands defined by the regulatory domain > MUST be represented by a single list of "profiles" > > (rather than split them across multiple lists) > > That last point is to remove ambiguity and, thus, variations in > database implementation, to simplify logic on devices. > > Example: > > "spectra": [ > > { > > "bandwidth": 6e6, > > "profiles": [ > > [ > > { "freqHz": 5.4e7, "maxPsdDbmPerBw": -56.8 }, > > { "freqHz": 7.2e7, "maxPsdDbmPerBw": -56.8 }, > > ], > > [ > > { "freqHz": 7.6e7, "maxPsdDbmPerBw": -56.8 }, > > { "freqHz": 8.8e7, "maxPsdDbmPerBw": -56.8 }, > > ], > > [ > > { "freqHz": 1.74e8, "maxPsdDbmPerBw": -56.8 }, > > { "freqHz": 2.16e8, "maxPsdDbmPerBw": -56.8 }, > > ], > > [ > > { "freqHz": 4.70e8, "maxPsdDbmPerBw": -56.8 }, > > { "freqHz": 5.18e8, "maxPsdDbmPerBw": -56.8 }, > > { "freqHz": 5.18e8, "maxPsdDbmPerBw": 30.0 }, > > { "freqHz": 5.24e8, "maxPsdDbmPerBw": 30.0 }, > > { "freqHz": 5.24e8, "maxPsdDbmPerBw": 36.0 }, > > { "freqHz": 5.30e8, "maxPsdDbmPerBw": 36.0 }, > > { "freqHz": 5.30e8, "maxPsdDbmPerBw": -56.8 }, > > { "freqHz": 6.98e8, "maxPsdDbmPerBw": -56.8 } > > ] > > ] > > }, > > { > > "bandwidth": 1e5, > > "profiles": [ > > [ > > { "freqHz": 5.4e7, "maxPsdDbmPerBw": -74.58 }, > > { "freqHz": 7.2e7, "maxPsdDbmPerBw": -74.58 }, > > ], > > [ > > { "freqHz": 7.6e7, "maxPsdDbmPerBw": -74.58 }, > > { "freqHz": 8.8e7, "maxPsdDbmPerBw": -74.58 }, > > ], > > [ > > { "freqHz": 1.74e8, "maxPsdDbmPerBw": -74.58 }, > > { "freqHz": 2.16e8, "maxPsdDbmPerBw": -74.58 }, > > ], > > [ > > { "freqHz": 4.70e8, "maxPsdDbmPerBw": -74.58 }, > > { "freqHz": 5.18e8, "maxPsdDbmPerBw": -74.58}, > > { "freqHz": 5.18e8, "maxPsdDbmPerBw": 27.0 }, > > { "freqHz": 5.24e8, "maxPsdDbmPerBw": 27.0 }, > > { "freqHz": 5.24e8, "maxPsdDbmPerBw": 33.0 }, > > { "freqHz": 5.30e8, "maxPsdDbmPerBw": 33.0 }, > > { "freqHz": 5.30e8, "maxPsdDbmPerBw": -74.58 }, > > { "freqHz": 6.98e8, "maxPsdDbmPerBw": -74.58 } > > ] > > ] > > } > > ] > > Does that address your concern? > > -- > -vince > > > > -- > -vince > > > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws --------------090601090707060100050301 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit The Whitespace spectrum allocations I have been following in various regions are made of of non-contiguous collections of contiguous spectrum, as illustrated by the US situation for TVWS below: each TV channel is a contiguous chunk of spectrum 6MHz wide; TV channels are spread dis-contiguously across the spectrum. .

Multiple standards exist and others are under development to utilize whitespace allocations. In 802.11, mhe ultiple TV channels may be aggregated to one 802.11 channel; in 802.15 we do e opposite:  we divide a single TV channel into many physical channels.  In  the current drafts, we assume the database provides the boundaries of the TV channel (somehow) and the standard maps that to the PHY channels defined.  There is also a need to specify unavailability of a small part of a TV channel.

The regional regulations for allowable use,  in particular the methods for specifying  transmit signal energy limitations, vary greatly.   In the US the current TVWS is quite simple compared how power limits are specified in other bands.  As we see the whitespace concept catching on (and it seems to be), I expect we will see the variety of methods used in other subparts of Part 15 applied.  If the goal is to be able to get this information from the database so an implementation can be regulation agnostic, it may be wise to look at some of the methods likely to be applied when we move beyond "TVWS" into application of the whitespace management concept to other spectrum allocations.

In Part 15 we see emission limits expressed as total power in a specified bandwidth, peak measured in any xHz accross the entire signal or band, field strength (energy level measured at a specified distance)  and several other methods.  In the more popular license exempt bands we have different methods applied, with different effective emissions limits, that are based on modulation type, modulation bandwidth (signalling rate), how the band is sub-divided into communcation channels (number of channels and occupied bandwidth of each), if the system employs frequency hopping, etc.  We also see constraints such as minimum and maximum occupied bandwidth for a communications channel.

I don't know if there is much concern over data volume for database exchanges.  Specifying an approximation of a spectral mask point by point is possible, but may become quite a few points. There are a few standard models for approximating spectral shape which could be used to reduce the data volume, which may have value  in the long run.

A few thoughts I hope will help from a humble and hopeful future user of the protocol!


-Ben



On 9/13/2013 8:03 PM, sajeevmanikkoth@gmail.com wrote:

Hi,

 

Not just the spectrum is available in non-contiguous bands, but a whitespace radio with higher bandwidth requirement may use non-contiguous spectrum aggregation, and consume available spectrum across multiple bands too.

 

Thanks and Regards,

Sajeev

 

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Vincent Chen
Sent: Friday, September 13, 2013 10:03 PM
To: Peter Stanforth
Cc: paws@ietf.org
Subject: Re: [paws] Encoding of spectrum profile

 

Peter,

 

Agreed. So it is important for the protocol to be able to represent discontiguous bands. Thanks.

 

-vince

 

On Fri, Sep 13, 2013 at 9:06 AM, Peter Stanforth <peter@spectrumbridge.com> wrote:

The US is not unique in having discontinuous bands, we have come across a mix of VHF and UHF channels in a number of countries. 

 

From: Vincent Chen <vchen@google.com>
Date: Friday, September 13, 2013 12:00 PM
To: Ray Bellis <Ray.Bellis@nominet.org.uk>
Cc: "paws@ietf.org" <paws@ietf.org>


Subject: Re: [paws] Encoding of spectrum profile

 

Ray,

 

Sorry for the delay in response.

 


My point about being able to represent discontinuities in the frequency range still appears to stand, however.

 

I see. Television channels do not occupy a contiguous range of frequencies. In the US, 

 

  - [54MHz, 72MHz]  Channel 2-4

  - [76MHz, 88MHz]  Channels 5-6

  - [174MHz, 216MHz] Channels 7-13

  - [470MHz, 698MHz]  Channels 14-51

 

So the response given by the database should not include any frequencies not in the plan.

 

That means a "spectrum profile" should be encoded as a list of "array" of (frequency, power) points.

 - Each array represents a "profile" for a contiguous range of frequencies

 - The range of frequencies within a list of profiles MUST be disjoint and SHOULD be sorted

 - The entire set of frequency bands defined by the regulatory domain MUST be represented by a single list of "profiles"

   (rather than split them across multiple lists)

 

That last point is to remove ambiguity and, thus, variations in database implementation, to simplify logic on devices.

 

Example:

 

"spectra": [

  {

    "bandwidth": 6e6,

    "profiles": [

      [

        { "freqHz": 5.4e7, "maxPsdDbmPerBw": -56.8 },

        { "freqHz": 7.2e7, "maxPsdDbmPerBw": -56.8 },

      ],

      [

        { "freqHz": 7.6e7, "maxPsdDbmPerBw": -56.8 },

        { "freqHz": 8.8e7, "maxPsdDbmPerBw": -56.8 },

      ],

      [

        { "freqHz": 1.74e8, "maxPsdDbmPerBw": -56.8 },

        { "freqHz": 2.16e8, "maxPsdDbmPerBw": -56.8 },

      ],

      [

        { "freqHz": 4.70e8, "maxPsdDbmPerBw": -56.8 },

        { "freqHz": 5.18e8, "maxPsdDbmPerBw": -56.8 },

        { "freqHz": 5.18e8, "maxPsdDbmPerBw": 30.0 },

        { "freqHz": 5.24e8, "maxPsdDbmPerBw": 30.0 },

        { "freqHz": 5.24e8, "maxPsdDbmPerBw": 36.0 },

        { "freqHz": 5.30e8, "maxPsdDbmPerBw": 36.0 },

        { "freqHz": 5.30e8, "maxPsdDbmPerBw": -56.8 },

        { "freqHz": 6.98e8, "maxPsdDbmPerBw": -56.8 }

      ]

    ]

  },

  {

    "bandwidth": 1e5,

    "profiles": [

      [

        { "freqHz": 5.4e7, "maxPsdDbmPerBw": -74.58 },

        { "freqHz": 7.2e7, "maxPsdDbmPerBw": -74.58 },

      ],

      [

        { "freqHz": 7.6e7, "maxPsdDbmPerBw": -74.58 },

        { "freqHz": 8.8e7, "maxPsdDbmPerBw": -74.58 },

      ],

      [

        { "freqHz": 1.74e8, "maxPsdDbmPerBw": -74.58 },

        { "freqHz": 2.16e8, "maxPsdDbmPerBw": -74.58 },

      ],

      [

        { "freqHz": 4.70e8, "maxPsdDbmPerBw": -74.58 },

        { "freqHz": 5.18e8, "maxPsdDbmPerBw": -74.58},

        { "freqHz": 5.18e8, "maxPsdDbmPerBw": 27.0 },

        { "freqHz": 5.24e8, "maxPsdDbmPerBw": 27.0 },

        { "freqHz": 5.24e8, "maxPsdDbmPerBw": 33.0 },

        { "freqHz": 5.30e8, "maxPsdDbmPerBw": 33.0 },

        { "freqHz": 5.30e8, "maxPsdDbmPerBw": -74.58 },

        { "freqHz": 6.98e8, "maxPsdDbmPerBw": -74.58 }

      ]

    ]

  }

]

 

Does that address your concern?

 

--
-vince



 

--
-vince 



_______________________________________________
paws mailing list
paws@ietf.org
https://www.ietf.org/mailman/listinfo/paws

--------------090601090707060100050301-- From peter@spectrumbridge.com Sun Sep 15 05:45:47 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CE251F0D10 for ; Sun, 15 Sep 2013 05:45:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WHqAgMe0t6zn for ; Sun, 15 Sep 2013 05:45:33 -0700 (PDT) Received: from mail.spectrumbridge.com (mail.spectrumbridge.com [64.132.248.82]) by ietfa.amsl.com (Postfix) with ESMTP id 30DE11F0D07 for ; Sun, 15 Sep 2013 05:45:21 -0700 (PDT) Received: from shelby.sbi.com ([127.0.0.1]) by shelby ([127.0.0.1]) with mapi; Sun, 15 Sep 2013 08:45:20 -0400 From: Peter Stanforth To: "Benjamin A. Rolfe" , "paws@ietf.org" Date: Sun, 15 Sep 2013 08:45:13 -0400 Thread-Topic: [paws] Encoding of spectrum profile Thread-Index: Ac6yEW94uQvgsZulTiGHfu8CBiI2tQ== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.7.130812 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CE5B21B417C03peterspectrumbridgecom_" MIME-Version: 1.0 Subject: Re: [paws] Encoding of spectrum profile X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Sep 2013 12:45:47 -0000 --_000_CE5B21B417C03peterspectrumbridgecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The purpose of the database is to protect incumbent operations. How seconda= ry users then access the spectrum is beyond the regulatory scope (though th= e way the FCC defined the way PSD is measured narrow channel use is effecti= vely banned). So far all Regulators have defined protection in terms of 6 o= r 8 MHz channels, not partial channels. So unless we believe we can convinc= e regulators to change their definition and protect partial channels (when = used by PMSE for instance) the way it is defined is adequate. I apologize for sounding like I am pouring cold water on your ideas but, al= though the Charter says "protocol for access White Space", there was a cons= cious decision made at the beginning to solve the problem for TVWS, thus av= oiding scope creep and getting a standard out there. While we have tried to remain flexible we really don't know how other bands= , beyond a proposal by PCAST in the US, and a notion of LSA in the EU, will= be managed so I would keep to the plan. We are already a year late from th= e original objective. Peter S. From: "Benjamin A. Rolfe" > Date: Saturday, September 14, 2013 10:33 PM To: "paws@ietf.org" > Subject: Re: [paws] Encoding of spectrum profile The Whitespace spectrum allocations I have been following in various region= s are made of of non-contiguous collections of contiguous spectrum, as illu= strated by the US situation for TVWS below: each TV channel is a contiguous= chunk of spectrum 6MHz wide; TV channels are spread dis-contiguously acros= s the spectrum. . Multiple standards exist and others are under development to utilize whites= pace allocations. In 802.11, mhe ultiple TV channels may be aggregated to o= ne 802.11 channel; in 802.15 we do e opposite: we divide a single TV chann= el into many physical channels. In the current drafts, we assume the data= base provides the boundaries of the TV channel (somehow) and the standard m= aps that to the PHY channels defined. There is also a need to specify unav= ailability of a small part of a TV channel. The regional regulations for allowable use, in particular the methods for = specifying transmit signal energy limitations, vary greatly. In the US t= he current TVWS is quite simple compared how power limits are specified in = other bands. As we see the whitespace concept catching on (and it seems to= be), I expect we will see the variety of methods used in other subparts of= Part 15 applied. If the goal is to be able to get this information from t= he database so an implementation can be regulation agnostic, it may be wise= to look at some of the methods likely to be applied when we move beyond "T= VWS" into application of the whitespace management concept to other spectru= m allocations. In Part 15 we see emission limits expressed as total power in a specified b= andwidth, peak measured in any xHz accross the entire signal or band, field= strength (energy level measured at a specified distance) and several othe= r methods. In the more popular license exempt bands we have different meth= ods applied, with different effective emissions limits, that are based on m= odulation type, modulation bandwidth (signalling rate), how the band is sub= -divided into communcation channels (number of channels and occupied bandwi= dth of each), if the system employs frequency hopping, etc. We also see co= nstraints such as minimum and maximum occupied bandwidth for a communicatio= ns channel. I don't know if there is much concern over data volume for database exchang= es. Specifying an approximation of a spectral mask point by point is possi= ble, but may become quite a few points. There are a few standard models for= approximating spectral shape which could be used to reduce the data volume= , which may have value in the long run. A few thoughts I hope will help from a humble and hopeful future user of th= e protocol! -Ben On 9/13/2013 8:03 PM, sajeevmanikkoth@gmail.com wrote: Hi, Not just the spectrum is available in non-contiguous bands, but a whitespac= e radio with higher bandwidth requirement may use non-contiguous spectrum a= ggregation, and consume available spectrum across multiple bands too. Thanks and Regards, Sajeev From:paws-bounces@ietf.org [mailto:paws-bounc= es@ietf.org] On Behalf Of Vincent Chen Sent: Friday, September 13, 2013 10:03 PM To: Peter Stanforth Cc: paws@ietf.org Subject: Re: [paws] Encoding of spectrum profile Peter, Agreed. So it is important for the protocol to be able to represent discont= iguous bands. Thanks. -vince On Fri, Sep 13, 2013 at 9:06 AM, Peter Stanforth > wrote: The US is not unique in having discontinuous bands, we have come across a m= ix of VHF and UHF channels in a number of countries. From: Vincent Chen > Date: Friday, September 13, 2013 12:00 PM To: Ray Bellis = > Cc: "paws@ietf.org" > Subject: Re: [paws] Encoding of spectrum profile Ray, Sorry for the delay in response. My point about being able to represent discontinuities in the frequency ran= ge still appears to stand, however. I see. Television channels do not occupy a contiguous range of frequencies.= In the US, - [54MHz, 72MHz] Channel 2-4 - [76MHz, 88MHz] Channels 5-6 - [174MHz, 216MHz] Channels 7-13 - [470MHz, 698MHz] Channels 14-51 So the response given by the database should not include any frequencies no= t in the plan. That means a "spectrum profile" should be encoded as a list of "array" of (= frequency, power) points. - Each array represents a "profile" for a contiguous range of frequencies - The range of frequencies within a list of profiles MUST be disjoint and = SHOULD be sorted - The entire set of frequency bands defined by the regulatory domain MUST = be represented by a single list of "profiles" (rather than split them across multiple lists) That last point is to remove ambiguity and, thus, variations in database im= plementation, to simplify logic on devices. Example: "spectra": [ { "bandwidth": 6e6, "profiles": [ [ { "freqHz": 5.4e7, "maxPsdDbmPerBw": -56.8 }, { "freqHz": 7.2e7, "maxPsdDbmPerBw": -56.8 }, ], [ { "freqHz": 7.6e7, "maxPsdDbmPerBw": -56.8 }, { "freqHz": 8.8e7, "maxPsdDbmPerBw": -56.8 }, ], [ { "freqHz": 1.74e8, "maxPsdDbmPerBw": -56.8 }, { "freqHz": 2.16e8, "maxPsdDbmPerBw": -56.8 }, ], [ { "freqHz": 4.70e8, "maxPsdDbmPerBw": -56.8 }, { "freqHz": 5.18e8, "maxPsdDbmPerBw": -56.8 }, { "freqHz": 5.18e8, "maxPsdDbmPerBw": 30.0 }, { "freqHz": 5.24e8, "maxPsdDbmPerBw": 30.0 }, { "freqHz": 5.24e8, "maxPsdDbmPerBw": 36.0 }, { "freqHz": 5.30e8, "maxPsdDbmPerBw": 36.0 }, { "freqHz": 5.30e8, "maxPsdDbmPerBw": -56.8 }, { "freqHz": 6.98e8, "maxPsdDbmPerBw": -56.8 } ] ] }, { "bandwidth": 1e5, "profiles": [ [ { "freqHz": 5.4e7, "maxPsdDbmPerBw": -74.58 }, { "freqHz": 7.2e7, "maxPsdDbmPerBw": -74.58 }, ], [ { "freqHz": 7.6e7, "maxPsdDbmPerBw": -74.58 }, { "freqHz": 8.8e7, "maxPsdDbmPerBw": -74.58 }, ], [ { "freqHz": 1.74e8, "maxPsdDbmPerBw": -74.58 }, { "freqHz": 2.16e8, "maxPsdDbmPerBw": -74.58 }, ], [ { "freqHz": 4.70e8, "maxPsdDbmPerBw": -74.58 }, { "freqHz": 5.18e8, "maxPsdDbmPerBw": -74.58}, { "freqHz": 5.18e8, "maxPsdDbmPerBw": 27.0 }, { "freqHz": 5.24e8, "maxPsdDbmPerBw": 27.0 }, { "freqHz": 5.24e8, "maxPsdDbmPerBw": 33.0 }, { "freqHz": 5.30e8, "maxPsdDbmPerBw": 33.0 }, { "freqHz": 5.30e8, "maxPsdDbmPerBw": -74.58 }, { "freqHz": 6.98e8, "maxPsdDbmPerBw": -74.58 } ] ] } ] Does that address your concern? -- -vince -- -vince _______________________________________________ paws mailing list paws@ietf.orghttps://www.ietf.org/mailman/listinfo/pa= ws --_000_CE5B21B417C03peterspectrumbridgecom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
The purpose of the datab= ase is to protect incumbent operations. How secondary users then access the= spectrum is beyond the regulatory scope (though the way the FCC defined th= e way PSD is measured narrow channel use is effectively banned). So far all= Regulators have defined protection in terms of 6 or 8 MHz channels, not pa= rtial channels. So unless we believe we can convince regulators to change t= heir definition and protect partial channels (when used by PMSE for instanc= e) the way it is defined is adequate.

I apologize = for sounding like I am pouring cold water on your ideas but, although the C= harter says "protocol for access White Space", there was a conscious decisi= on made at the beginning to solve the problem for TVWS, thus avoiding scope= creep and getting a standard out there.
While we have tried to r= emain flexible we really don't know how other bands, beyond a proposal by P= CAST in the US, and a notion of LSA in the EU, will be managed so I would k= eep to the plan. We are already a year late from the original objective.
Peter S.

= From: "Benjamin A. Rolfe" <ben@blindcreek.com>
Date: Saturday, September 14, 2013 10:33 PM
To: "paws@ietf.org" <paws@ietf.org>
Subject: Re: [paws] Encoding of spectrum profile

The Whitespace spectrum allocations I have been following in various region= s are made of of non-contiguous collections of contiguous spectrum, as illu= strated by the US situation for TVWS below: each TV channel is a contiguous= chunk of spectrum 6MHz wide; TV channels are spread dis-contiguously across the spectrum. .

Multiple standards exist and others are under development to utilize whites= pace allocations. In 802.11, mhe ultiple TV channels may be aggregated to o= ne 802.11 channel; in 802.15 we do e opposite:  we divide a single TV = channel into many physical channels.  In  the current drafts, we assume the database provides the boundarie= s of the TV channel (somehow) and the standard maps that to the PHY channel= s defined.  There is also a need to specify unavailability of a small = part of a TV channel.

The regional regulations for allowable use,  in particular the methods= for specifying  transmit signal energy limitations, vary greatly.&nbs= p;  In the US the current TVWS is quite simple compared how power limi= ts are specified in other bands.  As we see the whitespace concept catching on (and it seems to be), I expect we will see the variety= of methods used in other subparts of Part 15 applied.  If the goal is= to be able to get this information from the database so an implementation = can be regulation agnostic, it may be wise to look at some of the methods likely to be applied when we move beyo= nd "TVWS" into application of the whitespace management concept to other sp= ectrum allocations.

In Part 15 we see emission limits expressed as total power in a specified b= andwidth, peak measured in any xHz accross the entire signal or band, field= strength (energy level measured at a specified distance)  and several= other methods.  In the more popular license exempt bands we have different methods applied, with different eff= ective emissions limits, that are based on modulation type, modulation band= width (signalling rate), how the band is sub-divided into communcation chan= nels (number of channels and occupied bandwidth of each), if the system employs frequency hopping, etc.  We= also see constraints such as minimum and maximum occupied bandwidth for a = communications channel.

I don't know if there is much concern over data volume for database exchang= es.  Specifying an approximation of a spectral mask point by point is = possible, but may become quite a few points. There are a few standard model= s for approximating spectral shape which could be used to reduce the data volume, which may have value  in the= long run.

A few thoughts I hope will help from a humble and hopeful future user of th= e protocol!


-Ben



On 9/13/2013 8:03 PM, sajeevmanikkoth@gmail.com wrote:

Hi,

 

Not just the spectrum is available in non-contiguous bands, but a= whitespace radio with higher bandwidth requirement may use non-contiguous = spectrum aggregation, and consume available spectrum across multiple bands too.

 

<= p class=3D"MsoNormal">Thanks and Regards,

Sajeev

=

 

From:paws-= bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Vincent Chen
Sent: Friday, September 13, 2013= 10:03 PM
To: Peter Stanforth
Cc: paws@ietf.org
Subj= ect: Re: [paws] Encoding of spectrum profile

 

Pe= ter,

 

<= div>

Agreed. So it is important for the protocol to b= e able to represent discontiguous bands. Thanks.

<= p class=3D"MsoNormal"> 

-vince

 

On Fri,= Sep 13, 2013 at 9:06 AM, Peter Stanforth <peter@spectrumbri= dge.com> wrote:

The US is = not unique in having discontinuous bands, we have come across a mix of VHF = and UHF channels in a number of countries. 

 

= From: Vincent Chen <vchen@google.com>
Date: Friday, S= eptember 13, 2013 12:00 PM
To: Ray Bellis <Ray.B= ellis@nominet.org.uk>
Cc: "paws@ietf.org" <paws@i= etf.org>


Subject: <= /b>Re: [paws] Encoding of spectrum profile

 

Ray,

 

Sorry for the delay in response.

 


My point about being able to represent discontinuities in the frequency ran= ge still appears to stand, however.

=

 

= I see. Television channels do not occupy a contiguous range of frequencies.= In the US, 

&n= bsp;

  - [54MHz, 72MHz] &= nbsp;Channel 2-4

  -= [76MHz, 88MHz]  Channels 5-6

  - [174MHz, 216MHz] Channels 7-13

  - [470MHz, 698MHz]  Channels 14-51

 

=

So the response given by the database should n= ot include any frequencies not in the plan.

 

That means a "spectrum profile" should be encoded as a list of "array" of = (frequency, power) points.

 - The rang= e of frequencies within a list of profiles MUST be disjoint and SHOULD be s= orted

 - The entire = set of frequency bands defined by the regulatory domain MUST be represented= by a single list of "profiles"

   (rather than split them across multiple lists)

 

That last point is to remove ambiguity and, thus, v= ariations in database implementation, to simplify logic on devices.

 

Example:

 

"spectr= a": [

  {

    "bandwidth": 6e6,<= /span>

    "profiles": [

      [<= /p>

        { "freqHz": 5.4e7, = "maxPsdDbmPerBw": -56.8 },

&n= bsp;       { "freqHz": 7.2e7, "maxPsdDbmPerBw": -56.8 },

      ],

      [

        { "freqHz": 7.6= e7, "maxPsdDbmPerBw": -56.8 },

      ],=

      [=

        { "freqHz":= 1.74e8, "maxPsdDbmPerBw": -56.8 },

        { "freqHz": 2.16e8, "maxPsdDbmPerBw": -5= 6.8 },

     = ],

      [

       = ; { "freqHz": 4.70e8, "maxPsdDbmPerBw": -56.8 },

        { "freqHz": 5.18e8, "maxPsd= DbmPerBw": -56.8 },

=   &n= bsp;     { "freqHz": 5.18e8, "maxPsdDbmPerBw": 30.0 },=

        { "freqHz":= 5.24e8, "maxPsdDbmPerBw": 30.0 },

        { "freqHz": 5.24e8, "maxPsdDbmPerBw": 36.= 0 },

      &nb= sp; { "freqHz": 5.30e8, "maxPsdDbmPerBw": 36.0 },

        { "freqHz": 5.30e8, "maxPs= dDbmPerBw": -56.8 },

  &= nbsp;     { "freqHz": 6.98e8, "maxPsdDbmPerBw": -56.8 }

      ]

    ]

<= /div>

  },

  {

    = "bandwidth": 1e5,

  &nbs= p; "profiles": [

   = ;   [

    &nbs= p;   { "freqHz": 5.4e7, "maxPsdDbmPerBw": -74.58 },

        { "freqHz= ": 7.2e7, "maxPsdDbmPerBw": -74.58 },

=

      ],

=

      [

        { "freqHz": 7.6e7, "maxPsdDbmPerBw":&nb= sp;-74.58 },

  &nbs= p;     { "freqHz": 8.8e7, "maxPsdDbmPerBw": -74.58 },

      ],

      [

        { "freqHz": 1= .74e8, "maxPsdDbmPerBw": -74.58 },

        { "freqHz": 2.16e8, "maxPsdDbmP= erBw": -74.58 },

&n= bsp;     ],

  =     [

   =     { "freqHz": 4.70e8, "maxPsdDbmPerBw": -74.58 },

        { "freqHz": 5= .18e8, "maxPsdDbmPerBw": -74.58},

        { "freqHz": 5.18e8, "maxPsdDbmPerBw": 27.= 0 },

      &nb= sp; { "freqHz": 5.24e8, "maxPsdDbmPerBw": 27.0 },

        { "freqHz": 5.24e8, "maxPs= dDbmPerBw": 33.0 },

=   &n= bsp;     { "freqHz": 5.30e8, "maxPsdDbmPerBw": 33.0 },=

        { "freqHz":= 5.30e8, "maxPsdDbmPerBw": -74.58 },

        { "freqHz": 6.98e8, "maxPsdDbmPerBw": -= 74.58 }

     = ]

    ]=

  }

]

<= o:p> 

Does that address y= our concern?

<= span style=3D"font-size: 10.5pt; font-family: Calibri, sans-serif; ">&= nbsp;

--
-vince



 

-- <= br> -vince 



________________________________________=
_______
paws mailing list
paws@ie=
tf.orghttps://www.ietf.org/mailman/listinfo/paws
<= /blockquote>
--_000_CE5B21B417C03peterspectrumbridgecom_-- From tvfool@google.com Sun Sep 15 10:34:51 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6B9311E8138 for ; Sun, 15 Sep 2013 10:34:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4SvKT6Jb0P3m for ; Sun, 15 Sep 2013 10:34:50 -0700 (PDT) Received: from mail-qe0-x230.google.com (mail-qe0-x230.google.com [IPv6:2607:f8b0:400d:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id 3407711E8137 for ; Sun, 15 Sep 2013 10:34:50 -0700 (PDT) Received: by mail-qe0-f48.google.com with SMTP id nd7so2257547qeb.21 for ; Sun, 15 Sep 2013 10:34:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=D1rZo2eduJEM6fVbO6I32ptcoyhjE8wcmCIDmyqWgYc=; b=G5hN7dyKxXwpKlzgUk7mqaxHjKnaPgzbKiyEOyvZ48HtI0prk0t/lp73wkAHcB9626 cASVCIv2Bk9BKTupIU2xTpoLbNtiTXhgg26d9IUbSbFGQ6IZSwh/wF8qXeuxO4to3xy2 A5PM872dlnQivMYh0pdFF0CKKLxzNycKX4G86BUk3ziRDQnV8CO6Fc/P2pi+VEmlkwtD kSQkUMtBStNf0W0x30rK3HuEJMAdW6MjTMhFL+uav9i7FmqdYVjSUYkBRo1I6we/VytX 10WbHxYPoDTkNU+4rwx0GR7UbMSjGSsMYOYXiciiJefdiBdu4Hvnbj2vsQ/2ojOvLFGy b5tw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=D1rZo2eduJEM6fVbO6I32ptcoyhjE8wcmCIDmyqWgYc=; b=fb77k6pIPhcw762ncAjqgyC6Xn27b+dVR2RYdMF153/j8T7ajHBcSeDMy97sCzv12P fzxN0P58pbar+LteAExDOKpmB9+1iL1l/yduoAnwd3OX6mb/CH1bLw+azAMuky1yEM2P DXQixhmVZGbTSdNQTeIZ8dh7sdw4EwxZtrwfSBlUijiMZLS63RfcK6/dEi8GLt8urLh1 fyiJtFivDtJRlcuAPLMU69ejdf8Po4WPkt/VxvHiaEkhaf89gT6US8UZIZn6HncfgPGM 1zb0Le7NpILUdTrbpr4TGwYF6xuK2AdD2ubJEDov8GW/XBB6J4P22vXNtmii1aeiggLA zsHQ== X-Gm-Message-State: ALoCoQn/scI2LquhXSE4f/x04bW8IolXoBzzDK3KkT0Ze0YO/Ooclw/RHAMquaRZoz74OP01muOhCtjRsHk9jBwayZp8xHJC52rryJ+Q2TaBzh8XWkEdOQqXwXi8VTuQ5iIG4IWWNes2tgVGxjH21ysyMZ7uYMHA3DJgZZiHRpWCKhdKmCyL5sbjGzCfI9gEM+nxHixq08zI MIME-Version: 1.0 X-Received: by 10.224.131.74 with SMTP id w10mr2203622qas.104.1379266489602; Sun, 15 Sep 2013 10:34:49 -0700 (PDT) Received: by 10.229.207.8 with HTTP; Sun, 15 Sep 2013 10:34:49 -0700 (PDT) In-Reply-To: References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DE89725@wds-exc1.okna.nominet.org.uk> Date: Sun, 15 Sep 2013 10:34:49 -0700 Message-ID: From: Andy Lee To: Vincent Chen Content-Type: multipart/alternative; boundary=001a11c2957229e5fe04e66f8194 Cc: "paws@ietf.org" Subject: Re: [paws] Encoding of spectrum profile X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Sep 2013 17:34:51 -0000 --001a11c2957229e5fe04e66f8194 Content-Type: text/plain; charset=ISO-8859-1 In the FCC, there technically aren't any parts of the spectrum that are not "in the plan". Every frequency is governed by something under the FCC's Part 15 rules. There are some underlying "baseline" or "default" emission rules, and then there are some specific carve-outs or overrides that apply to specific devices or sub-bands. TV white space is defined as specialized overrides within the context of the Part 15 rules (specifically, sections 15.701 thru 15.717 ). In other words, sections 15.701 thru 15.717 can grant higher emissions limits on some frequencies, and impose additional limits on others, but anything else not specifically called out would fall to some other default rule within the Part 15 rules (e.g., section 15.109). Part 15 rules define the upper bound of what a device is allowed to radiate. Any device that exceeds these limits will fail the FCC certification tests. In addition to the hard limits defined by Part 15, devices are encouraged to lower their emissions as much as possible, as a general "politeness protocol". For example, section 15.709(a)(5) talks about white space in-band emission limits and section 15.709(c)(1) talks about emission limits on the first-adjacent channel to a TV broadcast. The rules are silent on what happens for second-adjacent channels, and channels that are further out, so one should assume that the the "default" rules then apply. Another example is section 15.709(c)(4), where there are special emission constraints around TV channel 37. It gives specific power spectral density limits for frequencies around channel 37 as illustrated in the following ASCII diagram. Field strength numbers have been converted to dBm values for convenience. -63.19 dBm -- + + \ / \ / -65.22 dBm -- +--+ +--+ | | | | ch36 | ch37 | ch38 | | | | -75.23 dBm -- +--------+ | | | | | | 602 607 608 614 615 620 MHz This example also illustrates a case where the emission profile has a non-zero slope for some frequency ranges (i.e., 602-607 and 615-620 MHz have sloped psd profiles). Andy Lee | Google Inc. | tvfool@google.com | 408-230-0522 On Fri, Sep 13, 2013 at 9:00 AM, Vincent Chen wrote: > Ray, > > Sorry for the delay in response. > > >> My point about being able to represent discontinuities in the frequency >> range still appears to stand, however. >> > > I see. Television channels do not occupy a contiguous range of > frequencies. In the US, > > - [54MHz, 72MHz] Channel 2-4 > - [76MHz, 88MHz] Channels 5-6 > - [174MHz, 216MHz] Channels 7-13 > - [470MHz, 698MHz] Channels 14-51 > > So the response given by the database should not include any frequencies > not in the plan. > > That means a "spectrum profile" should be encoded as a list of "array" of > (frequency, power) points. > - Each array represents a "profile" for a contiguous range of frequencies > - The range of frequencies within a list of profiles MUST be disjoint and > SHOULD be sorted > - The entire set of frequency bands defined by the regulatory domain MUST > be represented by a single list of "profiles" > (rather than split them across multiple lists) > > That last point is to remove ambiguity and, thus, variations in database > implementation, to simplify logic on devices. > > Example: > > "spectra": [ > { > "bandwidth": 6e6, > "profiles": [ > [ > { "freqHz": 5.4e7, "maxPsdDbmPerBw": -56.8 }, > { "freqHz": 7.2e7, "maxPsdDbmPerBw": -56.8 }, > ], > [ > { "freqHz": 7.6e7, "maxPsdDbmPerBw": -56.8 }, > { "freqHz": 8.8e7, "maxPsdDbmPerBw": -56.8 }, > ], > [ > { "freqHz": 1.74e8, "maxPsdDbmPerBw": -56.8 }, > { "freqHz": 2.16e8, "maxPsdDbmPerBw": -56.8 }, > ], > [ > { "freqHz": 4.70e8, "maxPsdDbmPerBw": -56.8 }, > { "freqHz": 5.18e8, "maxPsdDbmPerBw": -56.8 }, > { "freqHz": 5.18e8, "maxPsdDbmPerBw": 30.0 }, > { "freqHz": 5.24e8, "maxPsdDbmPerBw": 30.0 }, > { "freqHz": 5.24e8, "maxPsdDbmPerBw": 36.0 }, > { "freqHz": 5.30e8, "maxPsdDbmPerBw": 36.0 }, > { "freqHz": 5.30e8, "maxPsdDbmPerBw": -56.8 }, > { "freqHz": 6.98e8, "maxPsdDbmPerBw": -56.8 } > ] > ] > }, > { > "bandwidth": 1e5, > "profiles": [ > [ > { "freqHz": 5.4e7, "maxPsdDbmPerBw": -74.58 }, > { "freqHz": 7.2e7, "maxPsdDbmPerBw": -74.58 }, > ], > [ > { "freqHz": 7.6e7, "maxPsdDbmPerBw": -74.58 }, > { "freqHz": 8.8e7, "maxPsdDbmPerBw": -74.58 }, > ], > [ > { "freqHz": 1.74e8, "maxPsdDbmPerBw": -74.58 }, > { "freqHz": 2.16e8, "maxPsdDbmPerBw": -74.58 }, > ], > [ > { "freqHz": 4.70e8, "maxPsdDbmPerBw": -74.58 }, > { "freqHz": 5.18e8, "maxPsdDbmPerBw": -74.58}, > { "freqHz": 5.18e8, "maxPsdDbmPerBw": 27.0 }, > { "freqHz": 5.24e8, "maxPsdDbmPerBw": 27.0 }, > { "freqHz": 5.24e8, "maxPsdDbmPerBw": 33.0 }, > { "freqHz": 5.30e8, "maxPsdDbmPerBw": 33.0 }, > { "freqHz": 5.30e8, "maxPsdDbmPerBw": -74.58 }, > { "freqHz": 6.98e8, "maxPsdDbmPerBw": -74.58 } > ] > ] > } > ] > > Does that address your concern? > > -- > -vince > --001a11c2957229e5fe04e66f8194 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
In the FCC, there technically aren't any parts of the = spectrum that are not "in the plan". =A0Every frequency is govern= ed by something under the FCC's Part 15 rules. =A0There are some u= nderlying "baseline" or "default" emission rules, and t= hen there are some specific carve-outs or overrides that apply to specific = devices or sub-bands. =A0TV white space is defined as specialized overrides= within the context of the Part 15 rules (specifically, sections 15.701 thru 15.717).

In other words, sections 15.701 thru 15.717 can grant h= igher emissions limits on some frequencies, and impose additional limits on= others, but anything else not specifically called out would fall to some o= ther default rule within the Part 15 rules (e.g., section 15.109). =A0Part 15 rules define the upper bound of what a device= is allowed to radiate. =A0Any device that exceeds these limits will fail t= he FCC certification tests. =A0In addition to the hard limits defined by Pa= rt 15, devices are encouraged to lower their emissions as much as possible,= as a general "politeness protocol".

For example, section 15.709(= a)(5) talks about white space in-band emission limits and section 15.709(c)= (1) talks about emission limits on the first-adjacent channel to a TV broad= cast. =A0The rules are silent on what happens for second-adjacent channels,= and channels that are further out, so one should assume that the the "= ;default" rules then apply.



Another example is sectio= n 15.709(c)(4), where there are special emission constraints around TV chan= nel 37. =A0It gives specific power spectral density limits for frequencies = around channel 37 as illustrated in the following ASCII diagram. =A0Field s= trength numbers have been converted to dBm values for convenience.

=A0 =A0-63.19 dBm= =A0-- =A0+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0+
=
=A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0\ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0\ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/
=A0 =A0-65.22 dBm =A0-- =A0 =A0 =A0 =A0+--+=A0= =A0 =A0 =A0 =A0= +--+
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 |=A0=A0 =A0 =A0 =A0|
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 |=A0=A0 =A0 =A0 =A0|
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 ch36 =A0|=A0=A0ch37 =A0| =A0ch38
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 |=A0=A0 =A0 =A0 =A0|
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0|
=A0 =A0-75.23 dBm =A0-- =A0 =A0 =A0 =A0 =A0 +-------= -+
=A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0| =A0 =A0 | =A0| =A0 =A0 =A0 =A0| =A0| =A0 =A0 |
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 602= =A0 607 608 =A0 =A0614 615 =A0 620 MHz

This example also illustrates a case where the emission profile has a = non-zero slope for some frequency ranges (i.e., 602-607 and 615-620 MHz hav= e sloped psd profiles).





On Fri, Sep 13, 2013 at 9:00 AM, Vincent= Chen <vchen@google.com> wrote:
Ray,

Sorry for the delay in response.


My point about being able to represent discontinuities in the frequency ran= ge still appears to stand, however.

I see. Television channels do not occupy a contiguous range of frequenci= es. In the US,=A0

=A0 - [54MHz, 72MHz] =A0Channel 2-4
=A0 - [76= MHz, 88MHz] =A0Channels 5-6
=A0 - [174MHz, 216MHz] Channels 7-13<= /div>
=A0 - [470MHz, 698MHz] =A0Channels 14-51

So the response given by the database should not include any frequencies n= ot in the plan.

That means a "spectrum profile" should be enc= oded as a list of "array" of (frequency, power) points.
=A0- Each array represents a "profile" for a contiguous range of= frequencies
=A0- The range of frequencies within a list of profiles MUST be disjoi= nt and SHOULD be sorted
=A0- The entire set of frequency bands de= fined by the regulatory domain MUST be represented by a single list of &quo= t;profiles"
=A0 =A0(rather than split them across multiple lists)

That last point is to remove ambiguity and, thus, variations in da= tabase implementation, to simplify logic on devices.

Example:

"spectra": [
=A0 {
=A0 =A0 "bandwidth": 6e6,
=A0 =A0 "profiles": [
=A0 =A0 =A0 [
=A0 =A0 =A0 =A0 { "freqHz": 5.4e7, "maxPsdDbmPerBw": -5= 6.8 },
=A0 = =A0 =A0 =A0 { "freqHz": 7.2e7, "maxPsdDbmPerBw": -56.8 = },
=A0 =A0 =A0 ],
=A0 =A0 =A0 [
=A0 =A0 =A0 =A0 { "freqHz": 7.6e7, "maxPsdDbmPerBw&qu= ot;: -56.8 },
=A0 =A0 =A0 =A0 { "freqHz": 8.8e7, "maxPsdDbmPerBw": -5= 6.8 },
=A0 = =A0 =A0 ],
= =A0 =A0 =A0 [
=A0 =A0 =A0 =A0 { "freqHz": 1.74e8, "maxPsdDbmPerBw": -= 56.8 },
=A0= =A0 =A0 =A0 { "freqHz": 2.16e8, "maxPsdDbmPerBw": -56.= 8 },
=A0 =A0 =A0 ],
=A0 =A0 =A0 [
=A0 =A0 =A0 =A0 { "freqHz": 4.70e8,= "maxPsdDbmPerBw": -56.8 },
=A0 =A0 =A0 =A0 { "freqHz": 5.18e8, "maxPsdDbmPerBw&quo= t;: -56.8 },
=A0 =A0 =A0 =A0 { "freqHz": 5.18e8, "= maxPsdDbmPerBw": 30.0 },
=A0 =A0 =A0 =A0 { "freqHz"= ;: 5.24e8, "maxPsdDbmPerBw": 30.0 },
=A0 =A0 =A0 =A0 { "freqHz": 5.24e8, "maxPsdDbmPerBw&quo= t;: 36.0 },
=A0 =A0 =A0 =A0 { "freqHz": 5.30e8, "m= axPsdDbmPerBw": 36.0 },
=A0 =A0 =A0 =A0 { "freqHz"= : 5.30e8, "maxPsdDbmPerBw": -56.8 },
=A0 =A0 =A0 =A0 { "freqHz": 6.98e8, "maxPsdDbmPerBw&quo= t;: -56.8 }
=A0 =A0 =A0 ]
=A0 =A0 ]
=A0 },
=A0 {
=A0 = =A0 "bandwidth": 1e5,
=A0 =A0 "profiles": [
=A0 =A0 =A0 [
=A0 =A0 =A0 =A0 { "freqHz": 5.4e7, "maxPsdDbmPerBw":= =A0-74.58=A0},
=A0 =A0 =A0 =A0 { "freqHz": 7.2e7, "maxPsdDbmPerBw"= :=A0-74.58=A0},
=A0 =A0 =A0 ],
=A0 =A0 =A0 = [
=A0 =A0 = =A0 =A0 { "freqHz": 7.6e7, "maxPsdDbmPerBw":=A0-74.58= =A0},
=A0 =A0 =A0 =A0 = { "freqHz": 8.8e7, "maxPsdDbmPerBw":=A0-74.58=A0},
=A0 =A0 =A0 ],<= /div>
=A0 =A0 =A0 [
=A0 =A0 =A0 =A0 { "freqHz": 1.74e8, "maxPsdDbmPerBw"= :=A0-74.58=A0},
=A0 =A0 =A0 =A0 { "freqHz": 2.16e8, "maxPsdDbmPerBw&quo= t;:=A0-74.58=A0},
=A0 =A0 =A0 ],
=A0 =A0 =A0 [
=A0 =A0 =A0 =A0 { "freqHz": 4.70e8, "maxPsdDbmPerBw= ": -74.58 },
=A0 =A0 =A0 =A0 = { "freqHz": 5.18e8, "maxPsdDbmPerBw": -74.58},
=A0 =A0 =A0 =A0 { &= quot;freqHz": 5.18e8, "maxPsdDbmPerBw": 27.0 },
=A0 =A0 =A0 =A0 = { "freqHz": 5.24e8, "maxPsdDbmPerBw": 27.0 },
=A0 =A0 =A0 =A0 { &q= uot;freqHz": 5.24e8, "maxPsdDbmPerBw": 33.0 },
=A0 =A0 =A0 =A0 = { "freqHz": 5.30e8, "maxPsdDbmPerBw": 33.0 },
=A0 =A0 =A0 =A0 { &q= uot;freqHz": 5.30e8, "maxPsdDbmPerBw": -74.58 },
=A0 =A0 =A0 =A0 = { "freqHz": 6.98e8, "maxPsdDbmPerBw": -74.58 }
=A0 =A0 =A0 ]
=
=A0 =A0 ]
= =A0 }
]

Does that address your concern?

--
-vince

--001a11c2957229e5fe04e66f8194-- From Ray.Bellis@nominet.org.uk Mon Sep 16 02:17:20 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A018721F8613 for ; Mon, 16 Sep 2013 02:17:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.148 X-Spam-Level: X-Spam-Status: No, score=-8.148 tagged_above=-999 required=5 tests=[AWL=-2.450, BAYES_50=0.001, HTML_MESSAGE=0.001, MANGLED_OFF=2.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Ryeql+uN-CU for ; Mon, 16 Sep 2013 02:17:10 -0700 (PDT) Received: from mx2.nominet.org.uk (mail.nominet.org.uk [213.248.242.49]) by ietfa.amsl.com (Postfix) with ESMTP id 6AB5011E8259 for ; Mon, 16 Sep 2013 02:06:40 -0700 (PDT) DomainKey-Signature: s=main2.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:From:To:CC:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:x-originating-ip: Content-Type:MIME-Version; b=cYbeb1NtuibredWoZgx6nzau0gx6fEw8QBzCiSzuTG9maC0oWMs0onX0 gi2uXlCIm1Q/fOvDtV1cXPj+FgZm47NOxmoshaw9PLn92Nok/RWgoKHHT pQnn7Ur0Tdt7+1mz5xqzNgDn5tVgYWGy9C23/z7dyPXyHJ7nS/SkHoL8n J97p4CBrer8wMtI5jQ8bOaDIhmfsLLK+sSVEdikB8BoNADRWPB0wUHqxh DeX/ixVqBVIUQ5TkI2qhItwRTUnsQ; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=@nominet.org.uk; q=dns/txt; s=main2.dkim.nominet.selector; t=1379322437; x=1410858437; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=WNCtIcEeBe5p4ungr2FbYKLmF/maTyn74UpdkQ10uAA=; b=qLXjMSGcT5ukdrgqV/RcCPZ8Y5Hwkhm9pCr9/iy7nKoc7LaTrr2N4gUM twdOEZwcT3Dsr7j/M/jNsbRd6aDYzUYMLTkNxBAitAZF6wp5sQ+FPCfvO iP0rZ0l5+pW1yhuVx3tturTcYlnB64jToxUbMhusg/12HsJvh1jqOxsCj SkU2riw/gYBWcrDqTj7HOcQqA3Mg4NJkD68pqaJalmY0vvNNH/Kiu/Fsa u8HG9hhGhZF8g3Ax5HwhA195J0PsC; X-IronPort-AV: E=Sophos;i="4.90,913,1371078000"; d="scan'208,217";a="3056111" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx2.nominet.org.uk with ESMTP; 16 Sep 2013 10:06:06 +0100 Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4%17]) with mapi id 14.02.0318.004; Mon, 16 Sep 2013 10:06:05 +0100 From: Ray Bellis To: Vincent Chen Thread-Topic: [paws] Encoding of spectrum profile Thread-Index: AQHOoeQCmU+qkDwvDUSLePEjGLDDY5msmYcAgAAgqoCAAWO2gIAIKfUAgAIaGoCAAI/hAIAAKOJGgArFcQCABEM7AA== Date: Mon, 16 Sep 2013 09:06:04 +0000 Message-ID: <53F00E5CD8B2E34C81C0C89EB0B4FE732DE9A5BE@wds-exc1.okna.nominet.org.uk> References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DE89725@wds-exc1.okna.nominet.org.uk> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.2.1] Content-Type: multipart/alternative; boundary="_000_53F00E5CD8B2E34C81C0C89EB0B4FE732DE9A5BEwdsexc1oknanomi_" MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] Encoding of spectrum profile X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2013 09:17:20 -0000 --_000_53F00E5CD8B2E34C81C0C89EB0B4FE732DE9A5BEwdsexc1oknanomi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On 13 Sep 2013, at 17:00, Vincent Chen > wrote: I see. Television channels do not occupy a contiguous range of frequencies.= In the US, - [54MHz, 72MHz] Channel 2-4 - [76MHz, 88MHz] Channels 5-6 - [174MHz, 216MHz] Channels 7-13 - [470MHz, 698MHz] Channels 14-51 So the response given by the database should not include any frequencies no= t in the plan. That means a "spectrum profile" should be encoded as a list of "array" of (= frequency, power) points. - Each array represents a "profile" for a contiguous range of frequencies - The range of frequencies within a list of profiles MUST be disjoint and = SHOULD be sorted - The entire set of frequency bands defined by the regulatory domain MUST = be represented by a single list of "profiles" (rather than split them across multiple lists) That last point is to remove ambiguity and, thus, variations in database im= plementation, to simplify logic on devices. Example: ... Does that address your concern? It does, although I still think the original #1 data model where each avail= able frequency range was simply defined by (f1, f2, psd1, psd2) is much bet= ter. It's also more consistent with the ETSI draft spec. Using the #2 model of an array of (f, psd) points is only more efficient as= an encoding mechanism in those few cases where non-zero PSD slopes do actu= ally need to be encoded. Any time there's a "step" jump in Psd you need ju= st as much data to encode that jump using (f, psd) points as you would if y= ou used (f1, f2, psd1, psd2). Regarding splitting the lists in the way you propose, that's not just a que= stion of what frequencies are "in the plan". The current OFCOM consultatio= n proposes (=A75.93) "not to allow WSD operation in channel 38" (606 - 614 = MHz) as that's used for nationwide PMSE. Channel 38 is definitely "in the = plan", but it's also a discontinuity. Your proposed model would appear to = require that we break our frequency table in two either side of channel 38,= and ends up with a two dimensional array of arrays in the JSON encoding. Using (f1, f2, p1, p2) allows the use of a single level list of values, wit= h the only constraint being that frequency ranges not overlap. Your example for the US plan then just becomes (omitting the 100 kHz bandwi= dth): "spectra": [ { "bandwidth": 6e6, "frequencyRanges": [ {"startHz": 5.4e7, "stopHz", 7.2e7, "startPsd": -56.8, "stopPsd": -= 56.8}, {"startHz": 7.6e7, "stopHz", 8.8e7, "startPsd": -56.8, "stopPsd": -= 56.8}, {"startHz": 1.74e8, "stopHz", 2.16e8, "startPsd": -56.8, "stopPsd":= -56.8}, {"startHz": 4.70e8, "stopHz", 5.18e8, "startPsd": -56.8, "stopPsd":= -56.8}, {"startHz": 5.18e8, "stopHz", 5.24e8, "startPsd": 30.0, "stopPsd": = 30.0}, {"startHz": 5.24e8, "stopHz", 5.30e8, "startPsd": 36.0, "stopPsd": = 36.0}, {"startHz": 5.30e8, "stopHz", 5.30e8, "startPsd": -56.8, "stopPsd":= -56.8} ] ] ] This requires 28 data values, exactly the same as in your example. It's al= so the smallest change necessary from the current spec in draft-ietf-paws-p= rotocol-06 to support non-zero Psd slopes. For encoding efficiency one cou= ld also specify that PSD just be either a single value or a pair [psd1, psd= 2] for those non-zero slope cases. kind regards, Ray --_000_53F00E5CD8B2E34C81C0C89EB0B4FE732DE9A5BEwdsexc1oknanomi_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <33B2EC693B3D0D44BA72BA2A863DE446@okna.nominet.org.uk> Content-Transfer-Encoding: quoted-printable
On 13 Sep 2013, at 17:00, Vincent Chen <vchen@google.com>
 wrote:

I see. Television channels do not occupy a contiguous range of frequen= cies. In the US, 

  - [54MHz, 72MHz]  Channel 2-4
  - [76MHz, 88MHz]  Channels 5-6
  - [174MHz, 216MHz] Channels 7-13
  - [470MHz, 698MHz]  Channels 14-51

So the response given by the database should not include any frequenci= es not in the plan.

That means a "spectrum profile" should be encoded as a list = of "array" of (frequency, power) points.
 - Each array represents a "profile" for a contiguous r= ange of frequencies
 - The range of frequencies within a list of profiles MUST be dis= joint and SHOULD be sorted
 - The entire set of frequency bands defined by the regulatory do= main MUST be represented by a single list of "profiles"
   (rather than split them across multiple lists)

That last point is to remove ambiguity and, thus, variations in databa= se implementation, to simplify logic on devices.

Example:

...

Does that address your concern?

It does, although I still think the original #1 data model where each = available frequency range was simply defined by (f1, f2, psd1, psd2) is muc= h better.  It's also more consistent with the ETSI draft spec.

Using the #2 model of an array of (f, psd) points is only more efficie= nt as an encoding mechanism in those few cases where non-zero PSD slopes do= actually need to be encoded.  Any time there's a "step" jum= p in Psd you need just as much data to encode that jump using (f, psd) points as you would if you used (f1, f2, psd1, psd2).<= /div>
Regarding splitting the lists in the way you propose, that's not = just a question of what frequencies are "in the plan".  The = current OFCOM consultation proposes (=A75.93) "not to allow WSD operat= ion in channel 38" (606 - 614 MHz) as that's used for nationwide PMSE.  Channel 38 is definitely "in the plan", but it's als= o a discontinuity.  Your proposed model would appear to require that w= e break our frequency table in two either side of channel 38, and ends up w= ith a two dimensional array of arrays in the JSON encoding.

Using (f1, f2, p1, p2) allows the use of a single level list of values= , with the only constraint being that frequency ranges not overlap.

Your example for the US plan then just becomes (omitting the 100 kHz b= andwidth):

"spectra": [
  {
     "bandwidth": 6e6,
     "frequencyRanges": [
        {"startHz": 5.4e7, "stopHz&= quot;, 7.2e7, "startPsd": -56.8, "stopPsd": -56.8},
        {"startHz": 7.6e7, "stopHz&= quot;, 8.8e7, "startPsd": -56.8, "stopPsd": -56.8},
        {"startHz": 1.74e8, "stopHz= ", 2.16e8, "startPsd": -56.8, "stopPsd": -56.8},
        {"startHz": 4.70e8, "stopHz= ", 5.18e8, "startPsd": -56.8, "stopPsd": -56.8},
        {"startHz": 5.18e8, "stopHz= ", 5.24e8, "startPsd": 30.0, "stopPsd": 30.0},
        {"startHz": 5.24e8, "stopHz= ", 5.30e8, "startPsd": 36.0, "stopPsd": 36.0},
        {"startHz": 5.30e8, "stopHz= ", 5.30e8, "startPsd": -56.8, "stopPsd": -56.8}
     ]
  ]
]

This requires 28 data values, exactly the same as in your example. &nb= sp;It's also the smallest change necessary from the current spec in draft-i= etf-paws-protocol-06 to support non-zero Psd slopes.  For encoding eff= iciency one could also specify that PSD just be either a single value or a pair [psd1, psd2] for those non-zero slope c= ases.

kind regards,

Ray

--_000_53F00E5CD8B2E34C81C0C89EB0B4FE732DE9A5BEwdsexc1oknanomi_-- From dharasty@appcomsci.com Mon Sep 16 09:17:10 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FE8E11E82A7 for ; Mon, 16 Sep 2013 09:17:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.298 X-Spam-Level: X-Spam-Status: No, score=-0.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_OFF=2.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3FAXdFbzIRYZ for ; Mon, 16 Sep 2013 09:16:46 -0700 (PDT) Received: from thumper.appcomsci.com (thumper.appcomsci.com [205.132.0.196]) by ietfa.amsl.com (Postfix) with ESMTP id E866621F9D21 for ; Mon, 16 Sep 2013 09:16:32 -0700 (PDT) Received: from bambi.appcomsci.com (bambi.appcomsci.com [192.4.5.54]) by thumper.appcomsci.com (8.14.2/8.14.2) with ESMTP id r8GGGQto025724; Mon, 16 Sep 2013 12:16:28 -0400 (EDT) Received: from brg-ats-exhb1.ats.atsinnovate.com (exch.appcomsci.com [192.4.5.112]) by bambi.appcomsci.com (8.14.4/8.13.4) with ESMTP id r8GGGN6Z026280; Mon, 16 Sep 2013 12:16:23 -0400 Received: from RRC-ATS-EXMB2.ats.atsinnovate.com ([2002:c004:56a::c004:56a]) by brg-ats-exhb1.ats.atsinnovate.com ([2002:c004:570::c004:570]) with mapi; Mon, 16 Sep 2013 12:16:23 -0400 From: "Harasty, Daniel J" To: Ray Bellis , Vincent Chen Thread-Topic: [paws] Encoding of spectrum profile Thread-Index: AQHOoeQIX1El7GNnWkeMJWYlOxECypmspRHAgABo8oCAAWO1gIAIKfUAgAIaG4CAAI/gAIAAGB6AgArWNgCABEM7AIAANDCw Date: Mon, 16 Sep 2013 16:16:22 +0000 Message-ID: References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DE89725@wds-exc1.okna.nominet.org.uk> <53F00E5CD8B2E34C81C0C89EB0B4FE732DE9A5BE@wds-exc1.okna.nominet.org.uk> In-Reply-To: <53F00E5CD8B2E34C81C0C89EB0B4FE732DE9A5BE@wds-exc1.okna.nominet.org.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_EC510C021D06A34C92F5A5A488B5290B0CF2AC51rrcatsexmb2atsa_" MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] Encoding of spectrum profile X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2013 16:17:11 -0000 --_000_EC510C021D06A34C92F5A5A488B5290B0CF2AC51rrcatsexmb2atsa_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I very much agree with Ray's observations and resulting proposal. In fact:= this exact email was in draft form in my head... I may have a few things to add - but first, I have one technical question f= irst: what is the origin of the "-56.8" value for PSD that keeps cropping u= p in the examples to indicate "not available"? Thanks, Dan Harasty From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Ray= Bellis Sent: Monday, September 16, 2013 5:06 AM To: Vincent Chen Cc: paws@ietf.org Subject: Re: [paws] Encoding of spectrum profile On 13 Sep 2013, at 17:00, Vincent Chen > wrote: I see. Television channels do not occupy a contiguous range of frequencies.= In the US, - [54MHz, 72MHz] Channel 2-4 - [76MHz, 88MHz] Channels 5-6 - [174MHz, 216MHz] Channels 7-13 - [470MHz, 698MHz] Channels 14-51 So the response given by the database should not include any frequencies no= t in the plan. That means a "spectrum profile" should be encoded as a list of "array" of (= frequency, power) points. - Each array represents a "profile" for a contiguous range of frequencies - The range of frequencies within a list of profiles MUST be disjoint and = SHOULD be sorted - The entire set of frequency bands defined by the regulatory domain MUST = be represented by a single list of "profiles" (rather than split them across multiple lists) That last point is to remove ambiguity and, thus, variations in database im= plementation, to simplify logic on devices. Example: ... Does that address your concern? It does, although I still think the original #1 data model where each avail= able frequency range was simply defined by (f1, f2, psd1, psd2) is much bet= ter. It's also more consistent with the ETSI draft spec. Using the #2 model of an array of (f, psd) points is only more efficient as= an encoding mechanism in those few cases where non-zero PSD slopes do actu= ally need to be encoded. Any time there's a "step" jump in Psd you need ju= st as much data to encode that jump using (f, psd) points as you would if y= ou used (f1, f2, psd1, psd2). Regarding splitting the lists in the way you propose, that's not just a que= stion of what frequencies are "in the plan". The current OFCOM consultatio= n proposes (=A75.93) "not to allow WSD operation in channel 38" (606 - 614 = MHz) as that's used for nationwide PMSE. Channel 38 is definitely "in the = plan", but it's also a discontinuity. Your proposed model would appear to = require that we break our frequency table in two either side of channel 38,= and ends up with a two dimensional array of arrays in the JSON encoding. Using (f1, f2, p1, p2) allows the use of a single level list of values, wit= h the only constraint being that frequency ranges not overlap. Your example for the US plan then just becomes (omitting the 100 kHz bandwi= dth): "spectra": [ { "bandwidth": 6e6, "frequencyRanges": [ {"startHz": 5.4e7, "stopHz", 7.2e7, "startPsd": -56.8, "stopPsd": -= 56.8}, {"startHz": 7.6e7, "stopHz", 8.8e7, "startPsd": -56.8, "stopPsd": -= 56.8}, {"startHz": 1.74e8, "stopHz", 2.16e8, "startPsd": -56.8, "stopPsd":= -56.8}, {"startHz": 4.70e8, "stopHz", 5.18e8, "startPsd": -56.8, "stopPsd":= -56.8}, {"startHz": 5.18e8, "stopHz", 5.24e8, "startPsd": 30.0, "stopPsd": = 30.0}, {"startHz": 5.24e8, "stopHz", 5.30e8, "startPsd": 36.0, "stopPsd": = 36.0}, {"startHz": 5.30e8, "stopHz", 5.30e8, "startPsd": -56.8, "stopPsd":= -56.8} ] ] ] This requires 28 data values, exactly the same as in your example. It's al= so the smallest change necessary from the current spec in draft-ietf-paws-p= rotocol-06 to support non-zero Psd slopes. For encoding efficiency one cou= ld also specify that PSD just be either a single value or a pair [psd1, psd= 2] for those non-zero slope cases. kind regards, Ray --_000_EC510C021D06A34C92F5A5A488B5290B0CF2AC51rrcatsexmb2atsa_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I very mu= ch agree with Ray’s observations and resulting proposal.=A0 In fact: = this exact email was in draft form in my head…

<= p class=3DMsoNormal> 

I may have a few things to add – but first, I have one techni= cal question first: what is the origin of the “-56.8” value for= PSD that keeps cropping up in the examples to indicate “not availabl= e”?

 

Thanks,

 

Dan Harasty

 <= /p>

 

 

= From:= paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Ray Bellis
Sent: Monday, September 16, 2013 5:06 AM
To: Vincent Chen
Cc: paws@ietf.org
Subject: Re: [paws] E= ncoding of spectrum profile

 

 

=

On 13 Sep 2013, at 17:00, Vincent Chen <vchen@google.com>

=

 wrote:



I see.= Television channels do not occupy a contiguous range of frequencies. In th= e US, 

 =

  - [54MHz, 72MHz]  Channel 2= -4

  - [76MHz, 88MHz] &n= bsp;Channels 5-6

  - [17= 4MHz, 216MHz] Channels 7-13

&= nbsp; - [470MHz, 698MHz]  Channels 14-51

 

So th= e response given by the database should not include any frequencies not in = the plan.

 

That means a "spectrum profile"= should be encoded as a list of "array" of (frequency, power) poi= nts.

 - Each array repre= sents a "profile" for a contiguous range of frequencies

 - The range of frequencies withi= n a list of profiles MUST be disjoint and SHOULD be sorted

 - The entire set of frequency bands def= ined by the regulatory domain MUST be represented by a single list of "= ;profiles"

   = (rather than split them across multiple lists)

 

That= last point is to remove ambiguity and, thus, variations in database implem= entation, to simplify logic on devices.

 

Example:<= o:p>

 

...

=



Does that address your concern?

 

It does, although I still think the original #1 data model w= here each available frequency range was simply defined by (f1, f2, psd1, ps= d2) is much better.  It's also more consistent with the ETSI draft spe= c.

 

Using the #2 model of an array of (f, psd) point= s is only more efficient as an encoding mechanism in those few cases where = non-zero PSD slopes do actually need to be encoded.  Any time there's = a "step" jump in Psd you need just as much data to encode that ju= mp using (f, psd) points as you would if you used (f1, f2, psd1, psd2).

 

Regarding splitting the lists in the way you propose, that's= not just a question of what frequencies are "in the plan".  = ;The current OFCOM consultation proposes (=A75.93) "not to allow WSD o= peration in channel 38" (606 - 614 MHz) as that's used for nationwide = PMSE.  Channel 38 is definitely "in the plan", but it's also= a discontinuity.  Your proposed model would appear to require that we= break our frequency table in two either side of channel 38, and ends up wi= th a two dimensional array of arrays in the JSON encoding.

 

Using (f1, f2, p1, p2) allows the use of a single level list of val= ues, with the only constraint being that frequency ranges not overlap.=

 

<= p class=3DMsoNormal>Your example for the US plan then just becomes (omittin= g the 100 kHz bandwidth):

 

"spectra": [

  {

     "bandwidth": 6e6,

     "freque= ncyRanges": [

  &nb= sp;     {"startHz": 5.4e7, "stopHz", 7.2e7, &= quot;startPsd": -56.8, "stopPsd": -56.8},

        {"startHz= ": 7.6e7, "stopHz", 8.8e7, "startPsd": -56.8, &quo= t;stopPsd": -56.8},

        {"startHz": 1.74e8, "stop= Hz", 2.16e8, "startPsd": -56.8, "stopPsd": -56.8},=

    &nb= sp;   {"startHz": 4.70e8, "stopHz", 5.18e8, "= startPsd": -56.8, "stopPsd": -56.8},

        {"startH= z": 5.18e8, "stopHz", 5.24e8, "startPsd": 30.0, &q= uot;stopPsd": 30.0},

        {"startHz": 5.24e8, "sto= pHz", 5.30e8, "startPsd": 36.0, "stopPsd": 36.0},<= o:p>

    &nbs= p;   {"startHz": 5.30e8, "stopHz", 5.30e8, "s= tartPsd": -56.8, "stopPsd": -56.8}

     ]

<= p class=3DMsoNormal>  ]

= ]

 

=

This requires 28 data values, exactly the same as= in your example.  It's also the smallest change necessary from the cu= rrent spec in draft-ietf-paws-protocol-06 to support non-zero Psd slopes. &= nbsp;For encoding efficiency one could also specify that PSD just be either= a single value or a pair [psd1, psd2] for those non-zero slope cases.=

 

<= p class=3DMsoNormal>kind regards,

 

Ray

 

= --_000_EC510C021D06A34C92F5A5A488B5290B0CF2AC51rrcatsexmb2atsa_-- From Gabor.Bajko@nokia.com Mon Sep 16 10:45:32 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A72B021F8BCE for ; Mon, 16 Sep 2013 10:45:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.298 X-Spam-Level: X-Spam-Status: No, score=-4.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_OFF=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MeMEGTqoVHFM for ; Mon, 16 Sep 2013 10:45:26 -0700 (PDT) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id E6D8511E810D for ; Mon, 16 Sep 2013 10:45:25 -0700 (PDT) Received: from smtp.mgd.nokia.com ([65.54.30.23]) by mgw-sa02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r8GHXwn5022628 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 16 Sep 2013 20:34:00 +0300 Received: from 008-AM1MPN1-006.mgdnok.nokia.com ([169.254.6.139]) by 008-AM1MMR1-007.mgdnok.nokia.com ([65.54.30.23]) with mapi id 14.03.0136.001; Mon, 16 Sep 2013 17:33:58 +0000 From: To: , , Thread-Topic: [paws] Encoding of spectrum profile Thread-Index: AQHOoeQFDw04TflTEUWcOZ+GLdKNBJmsqkoAgAAgq4CAAWO1gIAIKfUAgAIaG4CAAI/gAIAAGB6AgArWNgCABEM7AIAAeDkAgAAVL+A= Date: Mon, 16 Sep 2013 17:33:57 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E4760532D5F9@008-AM1MPN1-006.mgdnok.nokia.com> References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DE89725@wds-exc1.okna.nominet.org.uk> <53F00E5CD8B2E34C81C0C89EB0B4FE732DE9A5BE@wds-exc1.okna.nominet.org.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [69.181.65.212] Content-Type: multipart/alternative; boundary="_000_1ECAFF543A2FED4EA2BEB6CACE08E4760532D5F9008AM1MPN1006mg_" MIME-Version: 1.0 X-Nokia-AV: Clean Cc: paws@ietf.org Subject: Re: [paws] Encoding of spectrum profile X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2013 17:45:32 -0000 --_000_1ECAFF543A2FED4EA2BEB6CACE08E4760532D5F9008AM1MPN1006mg_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =D8 what is the origin of the "-56.8" value for PSD that keeps cropping up= in the examples to indicate "not available"? I thought this was clarified in http://www.ietf.org/mail-archive/web/paws/c= urrent/msg01615.html - gabor From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext= Harasty, Daniel J Sent: Monday, September 16, 2013 9:16 AM To: Ray Bellis; Vincent Chen Cc: paws@ietf.org Subject: Re: [paws] Encoding of spectrum profile I very much agree with Ray's observations and resulting proposal. In fact:= this exact email was in draft form in my head... I may have a few things to add - but first, I have one technical question f= irst: what is the origin of the "-56.8" value for PSD that keeps cropping u= p in the examples to indicate "not available"? Thanks, Dan Harasty From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of Ray Bellis Sent: Monday, September 16, 2013 5:06 AM To: Vincent Chen Cc: paws@ietf.org Subject: Re: [paws] Encoding of spectrum profile On 13 Sep 2013, at 17:00, Vincent Chen > wrote: I see. Television channels do not occupy a contiguous range of frequencies.= In the US, - [54MHz, 72MHz] Channel 2-4 - [76MHz, 88MHz] Channels 5-6 - [174MHz, 216MHz] Channels 7-13 - [470MHz, 698MHz] Channels 14-51 So the response given by the database should not include any frequencies no= t in the plan. That means a "spectrum profile" should be encoded as a list of "array" of (= frequency, power) points. - Each array represents a "profile" for a contiguous range of frequencies - The range of frequencies within a list of profiles MUST be disjoint and = SHOULD be sorted - The entire set of frequency bands defined by the regulatory domain MUST = be represented by a single list of "profiles" (rather than split them across multiple lists) That last point is to remove ambiguity and, thus, variations in database im= plementation, to simplify logic on devices. Example: ... Does that address your concern? It does, although I still think the original #1 data model where each avail= able frequency range was simply defined by (f1, f2, psd1, psd2) is much bet= ter. It's also more consistent with the ETSI draft spec. Using the #2 model of an array of (f, psd) points is only more efficient as= an encoding mechanism in those few cases where non-zero PSD slopes do actu= ally need to be encoded. Any time there's a "step" jump in Psd you need ju= st as much data to encode that jump using (f, psd) points as you would if y= ou used (f1, f2, psd1, psd2). Regarding splitting the lists in the way you propose, that's not just a que= stion of what frequencies are "in the plan". The current OFCOM consultatio= n proposes (=A75.93) "not to allow WSD operation in channel 38" (606 - 614 = MHz) as that's used for nationwide PMSE. Channel 38 is definitely "in the = plan", but it's also a discontinuity. Your proposed model would appear to = require that we break our frequency table in two either side of channel 38,= and ends up with a two dimensional array of arrays in the JSON encoding. Using (f1, f2, p1, p2) allows the use of a single level list of values, wit= h the only constraint being that frequency ranges not overlap. Your example for the US plan then just becomes (omitting the 100 kHz bandwi= dth): "spectra": [ { "bandwidth": 6e6, "frequencyRanges": [ {"startHz": 5.4e7, "stopHz", 7.2e7, "startPsd": -56.8, "stopPsd": -= 56.8}, {"startHz": 7.6e7, "stopHz", 8.8e7, "startPsd": -56.8, "stopPsd": -= 56.8}, {"startHz": 1.74e8, "stopHz", 2.16e8, "startPsd": -56.8, "stopPsd":= -56.8}, {"startHz": 4.70e8, "stopHz", 5.18e8, "startPsd": -56.8, "stopPsd":= -56.8}, {"startHz": 5.18e8, "stopHz", 5.24e8, "startPsd": 30.0, "stopPsd": = 30.0}, {"startHz": 5.24e8, "stopHz", 5.30e8, "startPsd": 36.0, "stopPsd": = 36.0}, {"startHz": 5.30e8, "stopHz", 5.30e8, "startPsd": -56.8, "stopPsd":= -56.8} ] ] ] This requires 28 data values, exactly the same as in your example. It's al= so the smallest change necessary from the current spec in draft-ietf-paws-p= rotocol-06 to support non-zero Psd slopes. For encoding efficiency one cou= ld also specify that PSD just be either a single value or a pair [psd1, psd= 2] for those non-zero slope cases. kind regards, Ray --_000_1ECAFF543A2FED4EA2BEB6CACE08E4760532D5F9008AM1MPN1006mg_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

=D8  what is the origi= n of the “-56.8” value for PSD that keeps cropping up in the ex= amples to indicate “not available”?

I thought this was clarif= ied in http://www.ietf.org/mail-archive/web/paws/cu= rrent/msg01615.html

- =          gabor<= /span>

 <= /p>

From: paws-bou= nces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext Harasty, Daniel J
Sent: Monday, September 16, 2013 9:16 AM
To: Ray Bellis; Vincent Chen
Cc: paws@ietf.org
Subject: Re: [paws] Encoding of spectrum profile

 

I very much agree with Ra= y’s observations and resulting proposal.  In fact: this exact em= ail was in draft form in my head…

 <= /p>

I may have a few things t= o add – but first, I have one technical question first: what is the o= rigin of the “-56.8” value for PSD that keeps cropping up in th= e examples to indicate “not available”?

 <= /p>

Thanks,=

 <= /p>

Dan Harasty

 

 <= /p>

 <= /p>

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Ray Bellis
Sent: Monday, September 16, 2013 5:06 AM
To: Vincent Chen
Cc: paws@ietf.org
Subject: Re: [paws] Encoding of spectrum profile

 

 

On 13 Sep 2013, at 17:00, Vincent Chen <vchen@google.com>

 wrote:

 

I see. Television channels do not occupy a contiguou= s range of frequencies. In the US, 

 

  - [54MHz, 72MHz]  Channel 2-4=

  - [76MHz, 88MHz]  Channels 5-6

  - [174MHz, 216MHz] Channels 7-13

  - [470MHz, 698MHz]  Channels 14-51<= /o:p>

 

So the response given by the database should not inc= lude any frequencies not in the plan.

 

That means a "spectrum profile" should be = encoded as a list of "array" of (frequency, power) points.

 - Each array represents a "profile" = for a contiguous range of frequencies

 - The range of frequencies within a list of pr= ofiles MUST be disjoint and SHOULD be sorted

 - The entire set of frequency bands defined by= the regulatory domain MUST be represented by a single list of "profil= es"

   (rather than split them across multiple= lists)

 

That last point is to remove ambiguity and, thus, va= riations in database implementation, to simplify logic on devices.

 

Example:

 

...

 

Does that address your concern?

 

It does, although I still think the original #1 data= model where each available frequency range was simply defined by (f1, f2, = psd1, psd2) is much better.  It's also more consistent with the ETSI d= raft spec.

 

Using the #2 model of an array of (f, psd) points is= only more efficient as an encoding mechanism in those few cases where non-= zero PSD slopes do actually need to be encoded.  Any time there's a &q= uot;step" jump in Psd you need just as much data to encode that jump using (f, psd) points as you would if you used (f= 1, f2, psd1, psd2).

 

Regarding splitting the lists in the way you pr= opose, that's not just a question of what frequencies are "in the plan= ".  The current OFCOM consultation proposes (=A75.93) "not t= o allow WSD operation in channel 38" (606 - 614 MHz) as that's used for nationwide PMSE.  Channel 38 is definitely "in the plan= ", but it's also a discontinuity.  Your proposed model would appe= ar to require that we break our frequency table in two either side of chann= el 38, and ends up with a two dimensional array of arrays in the JSON encoding.

 

Using (f1, f2, p1, p2) allows the use of a single le= vel list of values, with the only constraint being that frequency ranges no= t overlap.

 

Your example for the US plan then just becomes (omit= ting the 100 kHz bandwidth):

 

"spectra": [

  {

     "bandwidth": 6e6,=

     "frequencyRanges": [

        {"startHz": 5.= 4e7, "stopHz", 7.2e7, "startPsd": -56.8, "stopPsd&= quot;: -56.8},

        {"startHz": 7.= 6e7, "stopHz", 8.8e7, "startPsd": -56.8, "stopPsd&= quot;: -56.8},

        {"startHz": 1.= 74e8, "stopHz", 2.16e8, "startPsd": -56.8, "stopPs= d": -56.8},

        {"startHz": 4.= 70e8, "stopHz", 5.18e8, "startPsd": -56.8, "stopPs= d": -56.8},

        {"startHz": 5.= 18e8, "stopHz", 5.24e8, "startPsd": 30.0, "stopPsd= ": 30.0},

        {"startHz": 5.= 24e8, "stopHz", 5.30e8, "startPsd": 36.0, "stopPsd= ": 36.0},

        {"startHz": 5.= 30e8, "stopHz", 5.30e8, "startPsd": -56.8, "stopPs= d": -56.8}

     ]

  ]

]

 

This requires 28 data values, exactly the same as in= your example.  It's also the smallest change necessary from the curre= nt spec in draft-ietf-paws-protocol-06 to support non-zero Psd slopes. &nbs= p;For encoding efficiency one could also specify that PSD just be either a single value or a pair [psd1, psd2] for those no= n-zero slope cases.

 

kind regards,

 

Ray

 

--_000_1ECAFF543A2FED4EA2BEB6CACE08E4760532D5F9008AM1MPN1006mg_-- From tvfool@google.com Mon Sep 16 11:12:01 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2659111E8139 for ; Mon, 16 Sep 2013 11:12:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.827 X-Spam-Level: X-Spam-Status: No, score=-0.827 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MANGLED_OFF=2.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iI6mFo6WTobH for ; Mon, 16 Sep 2013 11:12:00 -0700 (PDT) Received: from mail-qe0-x229.google.com (mail-qe0-x229.google.com [IPv6:2607:f8b0:400d:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id 93A1011E82CD for ; Mon, 16 Sep 2013 11:11:59 -0700 (PDT) Received: by mail-qe0-f41.google.com with SMTP id ff1so3110929qeb.28 for ; Mon, 16 Sep 2013 11:11:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1cIrz+Paoo8P3Jin0SuOH5tjLTrE1SDtYR+jTnKu3ik=; b=fJ+jAFuI+4r9R4m9KQVQIO8SycC4+4ypdTqL0cvTpBuVlVdVZmEdE9fo0+KL265w0k GO16pIKZUKEF06ZN3bjL+kMvU/OSMA2sPiZ2elBtOTpcf3VThQaRqfbdXci/Ypjqh8Ro NbPi9B89sB8sUCZGiyx2UFxp+XMu/M/QwxAIamVd9XWDQ00dPCdPcBpaSODqo33tue/H 560AS6il5Es5u6nhPuSPcCIwT+Tc2tHq7Pt4xVW75pRlQ/t8Woqi8BzeD/LH3pI05SFT nnZubpYQehMJLZXRtDN3sC2pcPw/VH7YgJueE2WpSlDKPCyWL5h/nrQDrWPQ9YFFiIbu ZnCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=1cIrz+Paoo8P3Jin0SuOH5tjLTrE1SDtYR+jTnKu3ik=; b=cRZJcEtbLRLXDCdLrD7M25F9rEmg0Td/3FhxQffKkT9+3n73ww6zPMAvGNudrqZ5pz hbZ7VZytV73ent7v8EYXxlvDMr/TLBeuUe/lY6iGQFyzbELLdeAfNS97amfRtrFW2NiC u9i7X3b78RB99XyDKkqwBTvw770cs+cMfBCq+jb6/kPqtenkVB89MZFyH+diM6CjGCCI o6ONKtb9VUxITdV69TC93QKqjLq9/fRRRYIMZOFRYFSL9XiK4HrgLmN4z9V0GBVq5wR+ rNWupO008LVeH8dYjo2CbwU/YwtKNapBaqKKDdpDYdLEHWyNXgYM2D+Jik6Tga9A4fI8 b5EQ== X-Gm-Message-State: ALoCoQn/9XsDZJfVD0zOUt+G7DLgneALzESBF+8ZLL4ITf1FnG3QKzNp2+rXxdxiTITEoOTrQr3zoI1eEOs3a4+Sd2q3Nm53FMT/muv1MJXBG8LLLP6/TrO6rIJTz79GgzByMe+7yWooEalXCkWYn0O5Q+82HbVAasPIn77YM64M/FQTMV491XmrPVI5eHi0/mmeBIXDLYaK MIME-Version: 1.0 X-Received: by 10.49.107.226 with SMTP id hf2mr47255709qeb.17.1379355118845; Mon, 16 Sep 2013 11:11:58 -0700 (PDT) Received: by 10.229.207.8 with HTTP; Mon, 16 Sep 2013 11:11:58 -0700 (PDT) In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E4760532D5F9@008-AM1MPN1-006.mgdnok.nokia.com> References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DE89725@wds-exc1.okna.nominet.org.uk> <53F00E5CD8B2E34C81C0C89EB0B4FE732DE9A5BE@wds-exc1.okna.nominet.org.uk> <1ECAFF543A2FED4EA2BEB6CACE08E4760532D5F9@008-AM1MPN1-006.mgdnok.nokia.com> Date: Mon, 16 Sep 2013 11:11:58 -0700 Message-ID: From: Andy Lee To: Gabor.Bajko@nokia.com Content-Type: multipart/alternative; boundary=047d7bb04386e0da2004e68423f9 Cc: Protocol to Access White Space database Subject: Re: [paws] Encoding of spectrum profile X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2013 18:12:01 -0000 --047d7bb04386e0da2004e68423f9 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable That's correct, the example values come from the FCC rules under section 15.709(c)(1) Andy Lee | Google Inc. | tvfool@google.com | 408-230-0522 On Mon, Sep 16, 2013 at 10:33 AM, wrote: > **=D8 **what is the origin of the =93-56.8=94 value for PSD that keeps > cropping up in the examples to indicate =93not available=94?**** > > I thought this was clarified in > http://www.ietf.org/mail-archive/web/paws/current/msg01615.html**** > > **- **gabor**** > > ** ** > > *From:* paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] *On Behalf > Of *ext Harasty, Daniel J > *Sent:* Monday, September 16, 2013 9:16 AM > *To:* Ray Bellis; Vincent Chen > > *Cc:* paws@ietf.org > *Subject:* Re: [paws] Encoding of spectrum profile**** > > ** ** > > I very much agree with Ray=92s observations and resulting proposal. In > fact: this exact email was in draft form in my head=85**** > > ** ** > > I may have a few things to add =96 but first, I have one technical questi= on > first: what is the origin of the =93-56.8=94 value for PSD that keeps cro= pping > up in the examples to indicate =93not available=94?**** > > ** ** > > Thanks,**** > > ** ** > > Dan Harasty**** > > ** ** > > ** ** > > ** ** > > *From:* paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] > *On Behalf Of *Ray Bellis > *Sent:* Monday, September 16, 2013 5:06 AM > *To:* Vincent Chen > *Cc:* paws@ietf.org > *Subject:* Re: [paws] Encoding of spectrum profile**** > > ** ** > > ** ** > > On 13 Sep 2013, at 17:00, Vincent Chen **** > > wrote:**** > > ** ** > > I see. Television channels do not occupy a contiguous range of > frequencies. In the US, **** > > ** ** > > - [54MHz, 72MHz] Channel 2-4**** > > - [76MHz, 88MHz] Channels 5-6**** > > - [174MHz, 216MHz] Channels 7-13**** > > - [470MHz, 698MHz] Channels 14-51**** > > ** ** > > So the response given by the database should not include any frequencies > not in the plan.**** > > ** ** > > That means a "spectrum profile" should be encoded as a list of "array" of > (frequency, power) points.**** > > - Each array represents a "profile" for a contiguous range of frequencie= s > **** > > - The range of frequencies within a list of profiles MUST be disjoint an= d > SHOULD be sorted**** > > - The entire set of frequency bands defined by the regulatory domain MUS= T > be represented by a single list of "profiles"**** > > (rather than split them across multiple lists)**** > > ** ** > > That last point is to remove ambiguity and, thus, variations in database > implementation, to simplify logic on devices.**** > > ** ** > > Example:**** > > ** ** > > ...**** > > ** ** > > Does that address your concern?**** > > ** ** > > It does, although I still think the original #1 data model where each > available frequency range was simply defined by (f1, f2, psd1, psd2) is > much better. It's also more consistent with the ETSI draft spec.**** > > ** ** > > Using the #2 model of an array of (f, psd) points is only more efficient > as an encoding mechanism in those few cases where non-zero PSD slopes do > actually need to be encoded. Any time there's a "step" jump in Psd you > need just as much data to encode that jump using (f, psd) points as you > would if you used (f1, f2, psd1, psd2).**** > > ** ** > > Regarding splitting the lists in the way you propose, that's not just a > question of what frequencies are "in the plan". The current OFCOM > consultation proposes (=A75.93) "not to allow WSD operation in channel 38= " > (606 - 614 MHz) as that's used for nationwide PMSE. Channel 38 is > definitely "in the plan", but it's also a discontinuity. Your proposed > model would appear to require that we break our frequency table in two > either side of channel 38, and ends up with a two dimensional array of > arrays in the JSON encoding.**** > > ** ** > > Using (f1, f2, p1, p2) allows the use of a single level list of values, > with the only constraint being that frequency ranges not overlap.**** > > ** ** > > Your example for the US plan then just becomes (omitting the 100 kHz > bandwidth):**** > > ** ** > > "spectra": [**** > > {**** > > "bandwidth": 6e6,**** > > "frequencyRanges": [**** > > {"startHz": 5.4e7, "stopHz", 7.2e7, "startPsd": -56.8, "stopPsd": > -56.8},**** > > {"startHz": 7.6e7, "stopHz", 8.8e7, "startPsd": -56.8, "stopPsd": > -56.8},**** > > {"startHz": 1.74e8, "stopHz", 2.16e8, "startPsd": -56.8, > "stopPsd": -56.8},**** > > {"startHz": 4.70e8, "stopHz", 5.18e8, "startPsd": -56.8, > "stopPsd": -56.8},**** > > {"startHz": 5.18e8, "stopHz", 5.24e8, "startPsd": 30.0, "stopPsd"= : > 30.0},**** > > {"startHz": 5.24e8, "stopHz", 5.30e8, "startPsd": 36.0, "stopPsd"= : > 36.0},**** > > {"startHz": 5.30e8, "stopHz", 5.30e8, "startPsd": -56.8, > "stopPsd": -56.8}**** > > ]**** > > ]**** > > ]**** > > ** ** > > This requires 28 data values, exactly the same as in your example. It's > also the smallest change necessary from the current spec in > draft-ietf-paws-protocol-06 to support non-zero Psd slopes. For encoding > efficiency one could also specify that PSD just be either a single value = or > a pair [psd1, psd2] for those non-zero slope cases.**** > > ** ** > > kind regards,**** > > ** ** > > Ray**** > > ** ** > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > > --047d7bb04386e0da2004e68423f9 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
That's correct, the example values come from the FCC r= ules under section 15.709(c)(1)


Andy Lee=A0|=A0Google Inc. | =A0tvfool@google.com= =A0|=A0408-230-0522
Andy Lee=A0| =A0Google Inc. |=A0tvfool@google.com=A0| =A0408-230-0522


On Mon, Sep 16, 2013 at 10:33 AM, <Gabor.Bajko@nokia.com> wrote:

=D8=A0 what is the origin o= f the =93-56.8=94 value for PSD that keeps cropping up in the examples to i= ndicate =93not available=94?

I thought this was clarif= ied in http://www.ietf.org/mail-a= rchive/web/paws/current/msg01615.html

-=A0=A0=A0=A0=A0=A0=A0=A0=A0 gabor<= /span>

=A0<= /p>

From: paws-bounces@ietf.org [mailto:paws-= bounces@ietf.org] On Behalf Of ext Harasty, Daniel J
Sent: Monday, September 16, 2013 9:16 AM
To: Ray Bellis; Vincent Chen


Cc: paws@ietf.org=
Subject: Re: [paws] Encoding of spectrum profile
=

=A0

I very much agree with Ra= y=92s observations and resulting proposal.=A0 In fact: this exact email was= in draft form in my head=85

=A0<= /p>

I may have a few things t= o add =96 but first, I have one technical question first: what is the origi= n of the =93-56.8=94 value for PSD that keeps cropping up in the examples to indicate =93not available=94?

=A0<= /p>

Thanks,

=A0<= /p>

Dan Harasty=

=A0

=A0<= /p>

=A0<= /p>

From: paws-bounces@iet= f.org [mailt= o:paws-bounces@ietf.org] On Behalf Of Ray Bellis
Sent: Monday, September 16, 2013 5:06 AM
To: Vincent Chen
Cc: paws@ietf.org=
Subject: Re: [paws] Encoding of spectrum profile

=A0

=A0

On 13 Sep 2013, at 17:00, Vincent Chen <vchen@google.com><= /u>

=A0wrote:

=A0

I see. Television channels do not occupy a contiguou= s range of frequencies. In the US,=A0

=A0

=A0 - [54MHz, 72MHz] =A0Channel 2-4

=A0 - [76MHz, 88MHz] =A0Channels 5-6

=A0 - [174MHz, 216MHz] Channels 7-13

=A0 - [470MHz, 698MHz] =A0Channels 14-51

=A0

So the response given by the database should not inc= lude any frequencies not in the plan.

=A0

That means a "spectrum profile" should be = encoded as a list of "array" of (frequency, power) points.=

=A0- Each array represents a "profile" for= a contiguous range of frequencies

=A0- The range of frequencies within a list of profi= les MUST be disjoint and SHOULD be sorted

=A0- The entire set of frequency bands defined by th= e regulatory domain MUST be represented by a single list of "profiles&= quot;

=A0 =A0(rather than split them across multiple lists= )

=A0

That last point is to remove ambiguity and, thus, va= riations in database implementation, to simplify logic on devices.

=A0

Example:

=A0

...

=A0

Does that address your concern?

=A0

It does, although I still think the original #1 data= model where each available frequency range was simply defined by (f1, f2, = psd1, psd2) is much better. =A0It's also more consistent with the ETSI = draft spec.

=A0

Using the #2 model of an array of (f, psd) points is= only more efficient as an encoding mechanism in those few cases where non-= zero PSD slopes do actually need to be encoded. =A0Any time there's a &= quot;step" jump in Psd you need just as much data to encode that jump using (f, psd) points as you would if you used (f= 1, f2, psd1, psd2).

=A0

Regarding=A0splitting the lists in the way you propo= se, that's not just a question of what frequencies are "in the pla= n". =A0The current OFCOM consultation proposes (=A75.93) "not to = allow WSD operation in channel 38" (606 - 614 MHz) as that's used for nationwide PMSE. =A0Channel 38 is definitely "in the plan&qu= ot;, but it's also a discontinuity. =A0Your proposed model would appear= to require that we break our frequency table in two either side of channel= 38, and ends up with a two dimensional array of arrays in the JSON encoding.

=A0

Using (f1, f2, p1, p2) allows the use of a single le= vel list of values, with the only constraint being that frequency ranges no= t overlap.

=A0

Your example for the US plan then just becomes (omit= ting the 100 kHz bandwidth):

=A0

"spectra": [

=A0 {

=A0 =A0 =A0"bandwidth": 6e6,=

=A0 =A0 =A0"frequencyRanges": [<= /u>

=A0 =A0 =A0 =A0 {"startHz": 5.4e7, "s= topHz", 7.2e7, "startPsd": -56.8, "stopPsd": -56.8= },

=A0 =A0 =A0 =A0 {"startHz": 7.6e7, "s= topHz", 8.8e7, "startPsd": -56.8, "stopPsd": -56.8= },

=A0 =A0 =A0 =A0 {"startHz": 1.74e8, "= stopHz", 2.16e8, "startPsd": -56.8, "stopPsd": -56= .8},

=A0 =A0 =A0 =A0 {"startHz": 4.70e8, "= stopHz", 5.18e8, "startPsd": -56.8, "stopPsd": -56= .8},

=A0 =A0 =A0 =A0 {"startHz": 5.18e8, "= stopHz", 5.24e8, "startPsd": 30.0, "stopPsd": 30.0= },

=A0 =A0 =A0 =A0 {"startHz": 5.24e8, "= stopHz", 5.30e8, "startPsd": 36.0, "stopPsd": 36.0= },

=A0 =A0 =A0 =A0 {"startHz": 5.30e8, "= stopHz", 5.30e8, "startPsd": -56.8, "stopPsd": -56= .8}

=A0 =A0 =A0]

=A0 ]

]

=A0

This requires 28 data values, exactly the same as in= your example. =A0It's also the smallest change necessary from the curr= ent spec in draft-ietf-paws-protocol-06 to support non-zero Psd slopes. =A0= For encoding efficiency one could also specify that PSD just be either a single value or a pair [psd1, psd2] for those no= n-zero slope cases.

=A0

kind regards,

=A0

Ray

=A0


_______________________________________________
paws mailing list
paws@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/paws


--047d7bb04386e0da2004e68423f9-- From tvfool@google.com Mon Sep 16 11:18:36 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44B9311E82CD for ; Mon, 16 Sep 2013 11:18:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.252 X-Spam-Level: X-Spam-Status: No, score=-0.252 tagged_above=-999 required=5 tests=[AWL=-0.575, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MANGLED_OFF=2.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S-UQpBfwiYFN for ; Mon, 16 Sep 2013 11:18:35 -0700 (PDT) Received: from mail-qa0-x229.google.com (mail-qa0-x229.google.com [IPv6:2607:f8b0:400d:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id F2F8C11E813F for ; Mon, 16 Sep 2013 11:18:34 -0700 (PDT) Received: by mail-qa0-f41.google.com with SMTP id cr7so1319943qab.14 for ; Mon, 16 Sep 2013 11:18:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=E1XNdp9EkdbVFUmOKsA13gPY7vPyhi3pfzqYT0ZG1DM=; b=naE7sdOF/w6A7CNhcZv+oazx6o+eM/6eBtY99D0geEAYi9vi09F3WHpw3PEl5RvVFa j4m60TtYdH2OYXbyFojqlw9F28CI8smIEjxdXxDJjU5fw6sIEM8vsohn2d1yNLz1EHcz 0srImI9krWJUXJN+ks/fRYFX2jSKIvAf9gvKxQDjcftju8xp0n6edFqVpLs5YerA28ec KZu6vP+xm5w3HJVSho4zqvqThF+sUCGJkMhrrC9P1e0XyZoi6dyfL0kCmE5lfRGb2jtj bTMAmcSda8X3m5L4L1Ym83o5GMrlSlu+3RWLzU2LQy8UEFy1CY+jB963ocXds7RcrwrN KCjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=E1XNdp9EkdbVFUmOKsA13gPY7vPyhi3pfzqYT0ZG1DM=; b=lZmE8vierRQk8PdiYn2nhYp1udHv1MDhc0IeMYkTvWUfG6ZNEok8KrSjlEH2LGkjBN TXlQ2sMitOhnaMlaiembRi5P8n+1E8c3cDuluQFh13058xvxV9hGXGG2p3UR/XnVo313 fo/SrbmYLaaXK7YeImQkpI9sgCbTdRwgPKdw3jbleMyTIg30i7eUW4j+0eIvBhWJC2mi x4XV1ONyr+SP00BywLKHqPIT9G0JmJ/c8NfU7gimVWvK6AFsTy3NphnT+XZtkEm+jrwR nbiYZmforcmZlGWldyP/7nREX5Nz6G8VvipNMJ1o0Pqf3PX1MYa1hZ/lnfc5+5IIYYTY MmOA== X-Gm-Message-State: ALoCoQn8gBH+2kYW6Cc51bFTUmJiDxR6eMhRKH4Z4c+ng9As0Kd6rwBq/wmp8Tc4YcJoU5OCUEPwrb9QtzOrINJ0UGocjDOzH3Bd+nc92JBu+S9kxzLRUzA0Hp+HNaYk/PEhYp2kleoftI3Q83GMTse9eTbQWM7JGuPQec1NCaAkT7tr4seD+pb0qpDt5lbTXaxFQhs/IvE7 MIME-Version: 1.0 X-Received: by 10.49.75.103 with SMTP id b7mr3985254qew.85.1379355513899; Mon, 16 Sep 2013 11:18:33 -0700 (PDT) Received: by 10.229.207.8 with HTTP; Mon, 16 Sep 2013 11:18:33 -0700 (PDT) In-Reply-To: References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DE89725@wds-exc1.okna.nominet.org.uk> <53F00E5CD8B2E34C81C0C89EB0B4FE732DE9A5BE@wds-exc1.okna.nominet.org.uk> Date: Mon, 16 Sep 2013 11:18:33 -0700 Message-ID: From: Andy Lee To: "Harasty, Daniel J" Content-Type: multipart/alternative; boundary=047d7bd76dba6ce2c004e6843ba7 Cc: "paws@ietf.org" Subject: Re: [paws] Encoding of spectrum profile X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2013 18:18:36 -0000 --047d7bd76dba6ce2c004e6843ba7 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable > > what is the origin of the =93-56.8=94 value for PSD that keeps cropping u= p in > the examples to indicate =93not available=94? The FCC rules under 15.709(c)(1) require devices to have these adjacent channel emission limits to protect TV broadcasts. The "on" channels can be 16, 20, or 36 dBm EIRP, and the "off" channels have specific limits of -52.8, -56.8, or -36.8 dBm EIRP on adjacent channels that are occupied by TV. Andy Lee | Google Inc. | tvfool@google.com | 408-230-0522 On Mon, Sep 16, 2013 at 9:16 AM, Harasty, Daniel J wrote: > I very much agree with Ray=92s observations and resulting proposal. In > fact: this exact email was in draft form in my head=85**** > > ** ** > > I may have a few things to add =96 but first, I have one technical questi= on > first: what is the origin of the =93-56.8=94 value for PSD that keeps cro= pping > up in the examples to indicate =93not available=94?**** > > ** ** > > Thanks,**** > > ** ** > > Dan Harasty**** > > ** ** > > ** ** > > ** ** > > *From:* paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] *On Behalf > Of *Ray Bellis > *Sent:* Monday, September 16, 2013 5:06 AM > *To:* Vincent Chen > *Cc:* paws@ietf.org > *Subject:* Re: [paws] Encoding of spectrum profile**** > > ** ** > > ** ** > > On 13 Sep 2013, at 17:00, Vincent Chen **** > > wrote:**** > > > > **** > > I see. Television channels do not occupy a contiguous range of > frequencies. In the US, **** > > ** ** > > - [54MHz, 72MHz] Channel 2-4**** > > - [76MHz, 88MHz] Channels 5-6**** > > - [174MHz, 216MHz] Channels 7-13**** > > - [470MHz, 698MHz] Channels 14-51**** > > ** ** > > So the response given by the database should not include any frequencies > not in the plan.**** > > ** ** > > That means a "spectrum profile" should be encoded as a list of "array" of > (frequency, power) points.**** > > - Each array represents a "profile" for a contiguous range of frequencie= s > **** > > - The range of frequencies within a list of profiles MUST be disjoint an= d > SHOULD be sorted**** > > - The entire set of frequency bands defined by the regulatory domain MUS= T > be represented by a single list of "profiles"**** > > (rather than split them across multiple lists)**** > > ** ** > > That last point is to remove ambiguity and, thus, variations in database > implementation, to simplify logic on devices.**** > > ** ** > > Example:**** > > ** ** > > ...**** > > > > **** > > Does that address your concern?**** > > ** ** > > It does, although I still think the original #1 data model where each > available frequency range was simply defined by (f1, f2, psd1, psd2) is > much better. It's also more consistent with the ETSI draft spec.**** > > ** ** > > Using the #2 model of an array of (f, psd) points is only more efficient > as an encoding mechanism in those few cases where non-zero PSD slopes do > actually need to be encoded. Any time there's a "step" jump in Psd you > need just as much data to encode that jump using (f, psd) points as you > would if you used (f1, f2, psd1, psd2).**** > > ** ** > > Regarding splitting the lists in the way you propose, that's not just a > question of what frequencies are "in the plan". The current OFCOM > consultation proposes (=A75.93) "not to allow WSD operation in channel 38= " > (606 - 614 MHz) as that's used for nationwide PMSE. Channel 38 is > definitely "in the plan", but it's also a discontinuity. Your proposed > model would appear to require that we break our frequency table in two > either side of channel 38, and ends up with a two dimensional array of > arrays in the JSON encoding.**** > > ** ** > > Using (f1, f2, p1, p2) allows the use of a single level list of values, > with the only constraint being that frequency ranges not overlap.**** > > ** ** > > Your example for the US plan then just becomes (omitting the 100 kHz > bandwidth):**** > > ** ** > > "spectra": [**** > > {**** > > "bandwidth": 6e6,**** > > "frequencyRanges": [**** > > {"startHz": 5.4e7, "stopHz", 7.2e7, "startPsd": -56.8, "stopPsd": > -56.8},**** > > {"startHz": 7.6e7, "stopHz", 8.8e7, "startPsd": -56.8, "stopPsd": > -56.8},**** > > {"startHz": 1.74e8, "stopHz", 2.16e8, "startPsd": -56.8, > "stopPsd": -56.8},**** > > {"startHz": 4.70e8, "stopHz", 5.18e8, "startPsd": -56.8, > "stopPsd": -56.8},**** > > {"startHz": 5.18e8, "stopHz", 5.24e8, "startPsd": 30.0, "stopPsd"= : > 30.0},**** > > {"startHz": 5.24e8, "stopHz", 5.30e8, "startPsd": 36.0, "stopPsd"= : > 36.0},**** > > {"startHz": 5.30e8, "stopHz", 5.30e8, "startPsd": -56.8, > "stopPsd": -56.8}**** > > ]**** > > ]**** > > ]**** > > ** ** > > This requires 28 data values, exactly the same as in your example. It's > also the smallest change necessary from the current spec in > draft-ietf-paws-protocol-06 to support non-zero Psd slopes. For encoding > efficiency one could also specify that PSD just be either a single value = or > a pair [psd1, psd2] for those non-zero slope cases.**** > > ** ** > > kind regards,**** > > ** ** > > Ray**** > > ** ** > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > > --047d7bd76dba6ce2c004e6843ba7 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
what is the origin of the =93-56.= 8=94 value for PSD that keeps cropping up in the examples to indicate =93no= t available=94?

The FCC rul= es under 15.709(c)(1) require devices to have these adjacent channel emissi= on limits to protect TV broadcasts. =A0The "on" channels can be 1= 6, 20, or 36 dBm EIRP, and the "off" channels have specific limit= s of -52.8, -56.8, or -36.8 dBm EIRP on adjacent channels that are occupied= by TV.


=

On Mon, Sep 16, 2013 at 9:16 AM, Harasty= , Daniel J <dharasty@appcomsci.com> wrote:

I very much agree with Ray=92s observations = and resulting proposal.=A0 In fact: this exact email was in draft form in m= y head=85

=A0<= /p>

I may have a few thing= s to add =96 but first, I have one technical question first: what is the or= igin of the =93-56.8=94 value for PSD that keeps cropping up in the example= s to indicate =93not available=94?

=A0<= /p>

Thanks,<= /span>

=A0<= /p>

Dan Harasty<= /u>

=A0

=A0

=A0

From: paws-bounc= es@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Ray Bellis
Sent: Monday, September 16, 2013 5:06 AM
To: Vincent Chen<= br>Cc: paws@ietf.= org
Subject: Re: [paws] Encoding of spectrum profile

=A0=

=A0

On 13 Sep 2013, at 17:00, Vincent Chen <vchen@google.com>

=A0wrote:



I see. Television channels do not occupy a contiguous range of fre= quencies. In the US,=A0

=A0

=A0 - [54MHz, 72MHz] =A0Channel 2-4

<= div>

=A0 - [76MHz, 88MHz] =A0Channels 5-6

=A0 - [174MHz, 216MHz] Channels 7-13

=A0 - [470MHz, 698MHz] =A0Channels 14-5= 1

=A0

<= /div>

So the response given by the database should not inc= lude any frequencies not in the plan.

=A0

That = means a "spectrum profile" should be encoded as a list of "a= rray" of (frequency, power) points.

=A0- Each array represents a "profil= e" for a contiguous range of frequencies

<= p class=3D"MsoNormal">=A0- The range of frequencies within a list of profil= es MUST be disjoint and SHOULD be sorted

=A0- The entire set of frequency bands de= fined by the regulatory domain MUST be represented by a single list of &quo= t;profiles"

=A0 =A0= (rather than split them across multiple lists)

=A0

That last point is to remove ambiguity and, thus, variations= in database implementation, to simplify logic on devices.

=A0

Example:

= =A0

...<= u>



=

Does that address your = concern?

=A0

It does, although I = still think the original #1 data model where each available frequency range= was simply defined by (f1, f2, psd1, psd2) is much better. =A0It's als= o more consistent with the ETSI draft spec.

=A0

Using the #2 model of an array of (f, psd) points is only mo= re efficient as an encoding mechanism in those few cases where non-zero PSD= slopes do actually need to be encoded. =A0Any time there's a "ste= p" jump in Psd you need just as much data to encode that jump using (f= , psd) points as you would if you used (f1, f2, psd1, psd2).<= /p>

=A0

Regarding=A0splitting the lists in the way you propose, that's not j= ust a question of what frequencies are "in the plan". =A0The curr= ent OFCOM consultation proposes (=A75.93) "not to allow WSD operation = in channel 38" (606 - 614 MHz) as that's used for nationwide PMSE.= =A0Channel 38 is definitely "in the plan", but it's also a d= iscontinuity. =A0Your proposed model would appear to require that we break = our frequency table in two either side of channel 38, and ends up with a tw= o dimensional array of arrays in the JSON encoding.

=A0

Using (f1, f2, p1, p2) allows the use of a single level list= of values, with the only constraint being that frequency ranges not overla= p.

=A0

Your example for the US plan then just becomes (omitting the= 100 kHz bandwidth):

= =A0

"spectra": [

<= /div>

=A0 {

=A0 =A0 =A0"bandwidth": 6e6,

=A0 =A0 =A0"frequencyRanges": [

=A0 =A0 =A0 =A0 {"startHz": 5.4e7, "stopHz= ", 7.2e7, "startPsd": -56.8, "stopPsd": -56.8},=

=A0 =A0 =A0 =A0 {"startHz"= : 7.6e7, "stopHz", 8.8e7, "startPsd": -56.8, "stop= Psd": -56.8},

=A0 =A0 =A0 =A0 {"startHz": 1.74e8, "stopHz", 2.1= 6e8, "startPsd": -56.8, "stopPsd": -56.8},

=A0 =A0 =A0 =A0 {"startHz= ": 4.70e8, "stopHz", 5.18e8, "startPsd": -56.8, &q= uot;stopPsd": -56.8},

=A0 =A0 =A0 =A0 {"startHz": 5.18e8, "stopHz", 5.24e8, &= quot;startPsd": 30.0, "stopPsd": 30.0},

=A0 =A0 =A0 =A0 {"startHz&qu= ot;: 5.24e8, "stopHz", 5.30e8, "startPsd": 36.0, "= stopPsd": 36.0},

=A0 =A0 =A0 =A0 {"startHz= ": 5.30e8, "stopHz", 5.30e8, "startPsd": -56.8, &q= uot;stopPsd": -56.8}

=A0 =A0 =A0]

=A0 ]

]

=A0

This requires 28 data values, exactly the same as in your example. =A0I= t's also the smallest change necessary from the current spec in draft-i= etf-paws-protocol-06 to support non-zero Psd slopes. =A0For encoding effici= ency one could also specify that PSD just be either a single value or a pai= r [psd1, psd2] for those non-zero slope cases.

=A0

kind regards,

=A0

Ray

=A0


_______________________________________________
paws mailing list
paws@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/paws


--047d7bd76dba6ce2c004e6843ba7-- From Ray.Bellis@nominet.org.uk Mon Sep 16 12:25:26 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A63311E830B for ; Mon, 16 Sep 2013 12:25:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.836 X-Spam-Level: X-Spam-Status: No, score=-8.836 tagged_above=-999 required=5 tests=[AWL=-0.538, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_OFF=2.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bMb6q+P05BP7 for ; Mon, 16 Sep 2013 12:25:21 -0700 (PDT) Received: from mx2.nominet.org.uk (mail.nominet.org.uk [213.248.242.49]) by ietfa.amsl.com (Postfix) with ESMTP id DF3C311E8317 for ; Mon, 16 Sep 2013 12:25:13 -0700 (PDT) DomainKey-Signature: s=main2.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:From:To:CC:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:Content-Type: MIME-Version; b=a3xsWoiODaJzbuVCu86l58IQS4TkY6hEggqUxlm5XBQL0zk/jjBDlMt9 MU4dq/YE7ersChioikVaU3ZjXyBmj/1J+o1CJ122P0x9nmY7pQYOyGpnL QkQgfsTHaC5tvAkfqNsTuo4eTfCo+pqonfakekrH2SUhzZketwmgXvxq8 IUUBFOm48EepQ0rGsMXbtU02/w4o9CQLb2Ojpzy/6QA/W/O/e4zfbNkAB PPjuH5KsxWxO52IfxJEvCxljZjcnw; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=@nominet.org.uk; q=dns/txt; s=main2.dkim.nominet.selector; t=1379359514; x=1410895514; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=w5QIlEmFeN1ABHO+HX2uO5Neo5deiOtcx/jYhIpm+U0=; b=Gd26OEkru1UJBe3lnCjX2Nfr6nMXQ1xBSwS58NIuKMc/xcUNeilAvudn obP9eOCmBoFUwuVsoV3TVkj8u10UllcQ7vTRaAt7e4aaowjAKbQD6mJCV sfoKmvFZdjV95nNlfxj53wpRlcGMDzlX1qd+aXTSjjyj+Q/ocIapzRy6R zePodbMM/jpKFQxJB28659RURPWvc9JH97GPTeqHQ65PZC3ziI5hj/ylO W3wN9eMTgAShXRvTlgA3KfaoCOMlp; X-IronPort-AV: E=Sophos;i="4.90,917,1371078000"; d="scan'208,217";a="3071121" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx2.nominet.org.uk with ESMTP; 16 Sep 2013 20:25:02 +0100 Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4%17]) with mapi id 14.02.0318.004; Mon, 16 Sep 2013 20:25:01 +0100 From: Ray Bellis To: Andy Lee Thread-Topic: [paws] Encoding of spectrum profile Thread-Index: AQHOoeQCmU+qkDwvDUSLePEjGLDDY5msmYcAgAAgqoCAAWO2gIAIKfUAgAIaGoCAAI/hAIAAKOJGgArFcQCABEM7AIAAeDoAgAAiI4CAACNWVA== Date: Mon, 16 Sep 2013 19:25:00 +0000 Message-ID: <66C00FFB-47B3-4CC8-B592-5CE929E69702@nominet.org.uk> References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DE89725@wds-exc1.okna.nominet.org.uk> <53F00E5CD8B2E34C81C0C89EB0B4FE732DE9A5BE@wds-exc1.okna.nominet.org.uk> , In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_66C00FFB47B34CC8B5925CE929E69702nominetorguk_" MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] Encoding of spectrum profile X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2013 19:25:26 -0000 --_000_66C00FFB47B34CC8B5925CE929E69702nominetorguk_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable And adjacent channel leakage into otherwise permitted channels is a matter = of regulatory device approval? Ray Sent from my iPhone On 16 Sep 2013, at 19:18, "Andy Lee" > wrote: what is the origin of the =93-56.8=94 value for PSD that keeps cropping up = in the examples to indicate =93not available=94? The FCC rules under 15.709(c)(1) require devices to have these adjacent cha= nnel emission limits to protect TV broadcasts. The "on" channels can be 16= , 20, or 36 dBm EIRP, and the "off" channels have specific limits of -52.8,= -56.8, or -36.8 dBm EIRP on adjacent channels that are occupied by TV. Andy Lee | Google Inc. | tvfool@google.com | 408-230-0522 On Mon, Sep 16, 2013 at 9:16 AM, Harasty, Daniel J > wrote: I very much agree with Ray=92s observations and resulting proposal. In fac= t: this exact email was in draft form in my head=85 I may have a few things to add =96 but first, I have one technical question= first: what is the origin of the =93-56.8=94 value for PSD that keeps crop= ping up in the examples to indicate =93not available=94? Thanks, Dan Harasty From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of Ray Bellis Sent: Monday, September 16, 2013 5:06 AM To: Vincent Chen Cc: paws@ietf.org Subject: Re: [paws] Encoding of spectrum profile On 13 Sep 2013, at 17:00, Vincent Chen > wrote: I see. Television channels do not occupy a contiguous range of frequencies.= In the US, - [54MHz, 72MHz] Channel 2-4 - [76MHz, 88MHz] Channels 5-6 - [174MHz, 216MHz] Channels 7-13 - [470MHz, 698MHz] Channels 14-51 So the response given by the database should not include any frequencies no= t in the plan. That means a "spectrum profile" should be encoded as a list of "array" of (= frequency, power) points. - Each array represents a "profile" for a contiguous range of frequencies - The range of frequencies within a list of profiles MUST be disjoint and = SHOULD be sorted - The entire set of frequency bands defined by the regulatory domain MUST = be represented by a single list of "profiles" (rather than split them across multiple lists) That last point is to remove ambiguity and, thus, variations in database im= plementation, to simplify logic on devices. Example: ... Does that address your concern? It does, although I still think the original #1 data model where each avail= able frequency range was simply defined by (f1, f2, psd1, psd2) is much bet= ter. It's also more consistent with the ETSI draft spec. Using the #2 model of an array of (f, psd) points is only more efficient as= an encoding mechanism in those few cases where non-zero PSD slopes do actu= ally need to be encoded. Any time there's a "step" jump in Psd you need ju= st as much data to encode that jump using (f, psd) points as you would if y= ou used (f1, f2, psd1, psd2). Regarding splitting the lists in the way you propose, that's not just a que= stion of what frequencies are "in the plan". The current OFCOM consultatio= n proposes (=A75.93) "not to allow WSD operation in channel 38" (606 - 614 = MHz) as that's used for nationwide PMSE. Channel 38 is definitely "in the = plan", but it's also a discontinuity. Your proposed model would appear to = require that we break our frequency table in two either side of channel 38,= and ends up with a two dimensional array of arrays in the JSON encoding. Using (f1, f2, p1, p2) allows the use of a single level list of values, wit= h the only constraint being that frequency ranges not overlap. Your example for the US plan then just becomes (omitting the 100 kHz bandwi= dth): "spectra": [ { "bandwidth": 6e6, "frequencyRanges": [ {"startHz": 5.4e7, "stopHz", 7.2e7, "startPsd": -56.8, "stopPsd": -= 56.8}, {"startHz": 7.6e7, "stopHz", 8.8e7, "startPsd": -56.8, "stopPsd": -= 56.8}, {"startHz": 1.74e8, "stopHz", 2.16e8, "startPsd": -56.8, "stopPsd":= -56.8}, {"startHz": 4.70e8, "stopHz", 5.18e8, "startPsd": -56.8, "stopPsd":= -56.8}, {"startHz": 5.18e8, "stopHz", 5.24e8, "startPsd": 30.0, "stopPsd": = 30.0}, {"startHz": 5.24e8, "stopHz", 5.30e8, "startPsd": 36.0, "stopPsd": = 36.0}, {"startHz": 5.30e8, "stopHz", 5.30e8, "startPsd": -56.8, "stopPsd":= -56.8} ] ] ] This requires 28 data values, exactly the same as in your example. It's al= so the smallest change necessary from the current spec in draft-ietf-paws-p= rotocol-06 to support non-zero Psd slopes. For encoding efficiency one cou= ld also specify that PSD just be either a single value or a pair [psd1, psd= 2] for those non-zero slope cases. kind regards, Ray _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws --_000_66C00FFB47B34CC8B5925CE929E69702nominetorguk_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
And adjacent channel leakage into otherwise permitted channels is a ma= tter of regulatory device approval?

Ray

Sent from my iPhone

On 16 Sep 2013, at 19:18, "Andy Lee" <tvfool@google.com> wrote:

what is the origin of the =93-56.8=94 value for PSD that keeps crop= ping up in the examples to indicate =93not available=94?

The FCC rules under 15.709(c)(1) require devices= to have these adjacent channel emission limits to protect TV broadcasts. &= nbsp;The "on" channels can be 16, 20, or 36 dBm EIRP, and the &qu= ot;off" channels have specific limits of -52.8, -56.8, or -36.8 dBm EIRP on adjacent channels that are occupied by TV.


Andy Lee=A0|=A0Google Inc. | =A0tvfool@google.com= =A0|=A0408-230-0522
Andy Lee |  Google Inc. |  tvfool@google.= com |  408-230-0522


On Mon, Sep 16, 2013 at 9:16 AM, Harasty, Daniel= J <dharasty@ap= pcomsci.com> wrote:

I very much agree with Ra= y=92s observations and resulting proposal.  In fact: this exact email = was in draft form in my head=85

 

I may have a few things t= o add =96 but first, I have one technical question first: what is the origi= n of the =93-56.8=94 value for PSD that keeps cropping up in the examples to indicate =93not available=94?

 

Thanks,

 

Dan Harasty=

 

 

 

From: paws-bounces@iet= f.org [mailto:paws-bounces@ietf.org] On Behalf Of Ray Bellis
Sent: Monday, September 16, 2013 5:06 AM
To: Vincent Chen
Cc: paws@ietf.org=
Subject: Re: [paws] Encoding of spectrum profile

 

 

On 13 Sep 2013, at 17:00, Vincent Chen <vchen@google.com><= /u>

 wrote:



I see. Television channels do not occupy a contiguou= s range of frequencies. In the US, 

 

  - [54MHz, 72MHz]  Channel 2-4<= /u>

  - [76MHz, 88MHz]  Channels 5-6=

  - [174MHz, 216MHz] Channels 7-13

  - [470MHz, 698MHz]  Channels 14-51

 

So the response given by the database should not inc= lude any frequencies not in the plan.

 

That means a "spectrum profile" should be = encoded as a list of "array" of (frequency, power) points.=

 - Each array represents a "profile" = for a contiguous range of frequencies

 - The range of frequencies within a list of pr= ofiles MUST be disjoint and SHOULD be sorted

 - The entire set of frequency bands defined by= the regulatory domain MUST be represented by a single list of "profil= es"

   (rather than split them across multiple= lists)

 

That last point is to remove ambiguity and, thus, va= riations in database implementation, to simplify logic on devices.

 

Example:

 

...



Does that address your concern?

 

It does, although I still think the original #1 data= model where each available frequency range was simply defined by (f1, f2, = psd1, psd2) is much better.  It's also more consistent with the ETSI d= raft spec.

 

Using the #2 model of an array of (f, psd) points is= only more efficient as an encoding mechanism in those few cases where non-= zero PSD slopes do actually need to be encoded.  Any time there's a &q= uot;step" jump in Psd you need just as much data to encode that jump using (f, psd) points as you would if you used (f= 1, f2, psd1, psd2).

 

Regarding splitting the lists in the way you pr= opose, that's not just a question of what frequencies are "in the plan= ".  The current OFCOM consultation proposes (=A75.93) "not t= o allow WSD operation in channel 38" (606 - 614 MHz) as that's used for nationwide PMSE.  Channel 38 is definitely "in the plan= ", but it's also a discontinuity.  Your proposed model would appe= ar to require that we break our frequency table in two either side of chann= el 38, and ends up with a two dimensional array of arrays in the JSON encoding.

 

Using (f1, f2, p1, p2) allows the use of a single le= vel list of values, with the only constraint being that frequency ranges no= t overlap.

 

Your example for the US plan then just becomes (omit= ting the 100 kHz bandwidth):

 

"spectra": [

  {

     "bandwidth": 6e6,

     "frequencyRanges": [

        {"startHz": 5.= 4e7, "stopHz", 7.2e7, "startPsd": -56.8, "stopPsd&= quot;: -56.8},

        {"startHz": 7.= 6e7, "stopHz", 8.8e7, "startPsd": -56.8, "stopPsd&= quot;: -56.8},

        {"startHz": 1.= 74e8, "stopHz", 2.16e8, "startPsd": -56.8, "stopPs= d": -56.8},

        {"startHz": 4.= 70e8, "stopHz", 5.18e8, "startPsd": -56.8, "stopPs= d": -56.8},

        {"startHz": 5.= 18e8, "stopHz", 5.24e8, "startPsd": 30.0, "stopPsd= ": 30.0},

        {"startHz": 5.= 24e8, "stopHz", 5.30e8, "startPsd": 36.0, "stopPsd= ": 36.0},

        {"startHz": 5.= 30e8, "stopHz", 5.30e8, "startPsd": -56.8, "stopPs= d": -56.8}

     ]

  ]

]

 

This requires 28 data values, exactly the same as in= your example.  It's also the smallest change necessary from the curre= nt spec in draft-ietf-paws-protocol-06 to support non-zero Psd slopes. &nbs= p;For encoding efficiency one could also specify that PSD just be either a single value or a pair [psd1, psd2] for those no= n-zero slope cases.

 

kind regards,

 

Ray

 


_______________________________________________
paws mailing list
paws@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/paws


--_000_66C00FFB47B34CC8B5925CE929E69702nominetorguk_-- From tvfool@google.com Mon Sep 16 13:12:19 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67A6411E82BD for ; Mon, 16 Sep 2013 13:12:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.06 X-Spam-Level: X-Spam-Status: No, score=-0.06 tagged_above=-999 required=5 tests=[AWL=-0.383, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MANGLED_OFF=2.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dlTtOAAjauWO for ; Mon, 16 Sep 2013 13:12:18 -0700 (PDT) Received: from mail-qc0-x235.google.com (mail-qc0-x235.google.com [IPv6:2607:f8b0:400d:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id D6BF311E81A1 for ; Mon, 16 Sep 2013 13:12:17 -0700 (PDT) Received: by mail-qc0-f181.google.com with SMTP id q4so2956671qcx.40 for ; Mon, 16 Sep 2013 13:12:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=84eTKZxz2+BqJERMRwY0Y7miF4GoEIP6WdgZaPRTe/c=; b=iXkJacPuxWBZSiu+fbnteEpyzmhscsrhPwpFevUVfjQlRInBNhOxVgC9OqYrkdoPNH GQN+RRovWC4N7N2P7BTNYXzjwgc1MJiUlzaGQIfSQSz3BGWWsRbu5X1CihAhRbAJ5bj2 P5O8oHXSjA0xWjOxLnj4BdefDHbalv57Ri7bBxMUMRfxtYmJpGd9LsSGTcA2kkrQgUHU U6Z9tFn5RaLYi9p6PGOYnbUxt6WR3+vSsagwepVR0VJLA85CgBqY2XeaRRpmv+8nNsNI jHp2AHSzNixl31hyO04QwCv2jgvqhjfkVKuCknRJVcoh/lHeJNOwWZudySob2yxm4XEq iV1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=84eTKZxz2+BqJERMRwY0Y7miF4GoEIP6WdgZaPRTe/c=; b=YRWzH/7LclJ2nPUZUG7uKEDhQW1fYk3qb62hfcXchbHJAx1EogpCD4z6EeGqiPysTN tLaqg28/Ga3811QkQ30f9jJwUXfCmTuyS+Ez0//WKtf/hJNCDdTSDlZ0j5G2z+Uhaw+5 23gPfiSUf71VYUXE+31E6yl3OBmNgECdlas/qwZOQPbJfjTct9VNDuNMrOy5HjFQ2xSU XsDaH98sx6v0j7Ug6kWzArCKdrAC7IwGjUpJYqoAIKSeNG/shgPPTf+2mmZs8ZHrsBx/ Y2IezWIkJGPOfD01nu3WM27C/vS9UCStQp0i5ZxFjQlmCj8pOoa/f+aCO1PVpDsbiKiy 8n1A== X-Gm-Message-State: ALoCoQm7Ut7Ub8NCXua7LqrgvamCOd1qDqntJ2p2sG1pmPxgsfCwyUsrdE3lnhpoIh+xy/DWIqhljFMK1KkiiZce17ZgnF1Kkl/hl1CnPCmNYt+tFLcnho39wpNp6m8J040iPyV5hgZIVdcAohHGWi0GX33oQb2qjKtWgmgbi85RB8edopT7XdGHQNETVEp/UXtuZc1Y/w7Y MIME-Version: 1.0 X-Received: by 10.224.45.197 with SMTP id g5mr1521545qaf.2.1379362336898; Mon, 16 Sep 2013 13:12:16 -0700 (PDT) Received: by 10.229.207.8 with HTTP; Mon, 16 Sep 2013 13:12:16 -0700 (PDT) In-Reply-To: <66C00FFB-47B3-4CC8-B592-5CE929E69702@nominet.org.uk> References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DE89725@wds-exc1.okna.nominet.org.uk> <53F00E5CD8B2E34C81C0C89EB0B4FE732DE9A5BE@wds-exc1.okna.nominet.org.uk> <66C00FFB-47B3-4CC8-B592-5CE929E69702@nominet.org.uk> Date: Mon, 16 Sep 2013 13:12:16 -0700 Message-ID: From: Andy Lee To: Ray Bellis Content-Type: multipart/alternative; boundary=001a11c35d141b940e04e685d261 Cc: "paws@ietf.org" Subject: Re: [paws] Encoding of spectrum profile X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2013 20:12:19 -0000 --001a11c35d141b940e04e685d261 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable What do you mean by "otherwise permitted channels"? Andy Lee | Google Inc. | tvfool@google.com | 408-230-0522 On Mon, Sep 16, 2013 at 12:25 PM, Ray Bellis wro= te: > And adjacent channel leakage into otherwise permitted channels is a > matter of regulatory device approval? > > Ray > > Sent from my iPhone > > On 16 Sep 2013, at 19:18, "Andy Lee" wrote: > > what is the origin of the =93-56.8=94 value for PSD that keeps croppin= g up >> in the examples to indicate =93not available=94? > > > The FCC rules under 15.709(c)(1) require devices to have these adjacent > channel emission limits to protect TV broadcasts. The "on" channels can = be > 16, 20, or 36 dBm EIRP, and the "off" channels have specific limits of > -52.8, -56.8, or -36.8 dBm EIRP on adjacent channels that are occupied by > TV. > > > Andy Lee | Google Inc. | tvfool@google.com | 408-230-0522 > > > On Mon, Sep 16, 2013 at 9:16 AM, Harasty, Daniel J > wrote: > >> I very much agree with Ray=92s observations and resulting proposal. In >> fact: this exact email was in draft form in my head=85**** >> >> ** ** >> >> I may have a few things to add =96 but first, I have one technical quest= ion >> first: what is the origin of the =93-56.8=94 value for PSD that keeps cr= opping >> up in the examples to indicate =93not available=94?**** >> >> ** ** >> >> Thanks,**** >> >> ** ** >> >> Dan Harasty**** >> >> ** ** >> >> ** ** >> >> ** ** >> >> *From:* paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] *On Behalf >> Of *Ray Bellis >> *Sent:* Monday, September 16, 2013 5:06 AM >> *To:* Vincent Chen >> *Cc:* paws@ietf.org >> *Subject:* Re: [paws] Encoding of spectrum profile**** >> >> ** ** >> >> ** ** >> >> On 13 Sep 2013, at 17:00, Vincent Chen **** >> >> wrote:**** >> >> >> >> **** >> >> I see. Television channels do not occupy a contiguous range of >> frequencies. In the US, **** >> >> ** ** >> >> - [54MHz, 72MHz] Channel 2-4**** >> >> - [76MHz, 88MHz] Channels 5-6**** >> >> - [174MHz, 216MHz] Channels 7-13**** >> >> - [470MHz, 698MHz] Channels 14-51**** >> >> ** ** >> >> So the response given by the database should not include any frequencies >> not in the plan.**** >> >> ** ** >> >> That means a "spectrum profile" should be encoded as a list of "array" o= f >> (frequency, power) points.**** >> >> - Each array represents a "profile" for a contiguous range of frequenci= es >> **** >> >> - The range of frequencies within a list of profiles MUST be disjoint >> and SHOULD be sorted**** >> >> - The entire set of frequency bands defined by the regulatory domain >> MUST be represented by a single list of "profiles"**** >> >> (rather than split them across multiple lists)**** >> >> ** ** >> >> That last point is to remove ambiguity and, thus, variations in database >> implementation, to simplify logic on devices.**** >> >> ** ** >> >> Example:**** >> >> ** ** >> >> ...**** >> >> >> >> **** >> >> Does that address your concern?**** >> >> ** ** >> >> It does, although I still think the original #1 data model where each >> available frequency range was simply defined by (f1, f2, psd1, psd2) is >> much better. It's also more consistent with the ETSI draft spec.**** >> >> ** ** >> >> Using the #2 model of an array of (f, psd) points is only more efficient >> as an encoding mechanism in those few cases where non-zero PSD slopes do >> actually need to be encoded. Any time there's a "step" jump in Psd you >> need just as much data to encode that jump using (f, psd) points as you >> would if you used (f1, f2, psd1, psd2).**** >> >> ** ** >> >> Regarding splitting the lists in the way you propose, that's not just a >> question of what frequencies are "in the plan". The current OFCOM >> consultation proposes (=A75.93) "not to allow WSD operation in channel 3= 8" >> (606 - 614 MHz) as that's used for nationwide PMSE. Channel 38 is >> definitely "in the plan", but it's also a discontinuity. Your proposed >> model would appear to require that we break our frequency table in two >> either side of channel 38, and ends up with a two dimensional array of >> arrays in the JSON encoding.**** >> >> ** ** >> >> Using (f1, f2, p1, p2) allows the use of a single level list of values, >> with the only constraint being that frequency ranges not overlap.**** >> >> ** ** >> >> Your example for the US plan then just becomes (omitting the 100 kHz >> bandwidth):**** >> >> ** ** >> >> "spectra": [**** >> >> {**** >> >> "bandwidth": 6e6,**** >> >> "frequencyRanges": [**** >> >> {"startHz": 5.4e7, "stopHz", 7.2e7, "startPsd": -56.8, "stopPsd"= : >> -56.8},**** >> >> {"startHz": 7.6e7, "stopHz", 8.8e7, "startPsd": -56.8, "stopPsd"= : >> -56.8},**** >> >> {"startHz": 1.74e8, "stopHz", 2.16e8, "startPsd": -56.8, >> "stopPsd": -56.8},**** >> >> {"startHz": 4.70e8, "stopHz", 5.18e8, "startPsd": -56.8, >> "stopPsd": -56.8},**** >> >> {"startHz": 5.18e8, "stopHz", 5.24e8, "startPsd": 30.0, >> "stopPsd": 30.0},**** >> >> {"startHz": 5.24e8, "stopHz", 5.30e8, "startPsd": 36.0, >> "stopPsd": 36.0},**** >> >> {"startHz": 5.30e8, "stopHz", 5.30e8, "startPsd": -56.8, >> "stopPsd": -56.8}**** >> >> ]**** >> >> ]**** >> >> ]**** >> >> ** ** >> >> This requires 28 data values, exactly the same as in your example. It's >> also the smallest change necessary from the current spec in >> draft-ietf-paws-protocol-06 to support non-zero Psd slopes. For encodin= g >> efficiency one could also specify that PSD just be either a single value= or >> a pair [psd1, psd2] for those non-zero slope cases.**** >> >> ** ** >> >> kind regards,**** >> >> ** ** >> >> Ray**** >> >> ** ** >> >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws >> >> > --001a11c35d141b940e04e685d261 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
What do you mean by "otherwise permitted channels&quo= t;?


Andy Lee=A0|=A0Google Inc= . | =A0tvfool@google.com=A0| =A0408-230-0522


On Mon, Sep 16, 2013 at 12:25 PM, Ray Be= llis <Ray.Bellis@nominet.org.uk> wrote:
And adjacent channel leakage into otherwise permitted channels is a ma= tter of regulatory device approval?

Ray

Sent from my iPhone

On 16 Sep 2013, at 19:18, "Andy Lee" <tvfool@google.com> wrote:

what is the origin of the =93-56.8=94 value for PSD that keeps crop= ping up in the examples to indicate =93not available=94?

The FCC rules under 15.709(c)(1) require devices= to have these adjacent channel emission limits to protect TV broadcasts. = =A0The "on" channels can be 16, 20, or 36 dBm EIRP, and the "= ;off" channels have specific limits of -52.8, -56.8, or -36.8 dBm EIRP on adjacent channels that are occupied by TV.


Andy Lee=A0| =A0Google Inc. | =A0tvfool@google.com= =A0| =A040= 8-230-0522


On Mon, Sep 16, 2013 at 9:16 AM, Harasty, Daniel= J <dharasty@ap= pcomsci.com> wrote:

I very much agree with Ra= y=92s observations and resulting proposal.=A0 In fact: this exact email was= in draft form in my head=85

=A0<= /p>

I may have a few things t= o add =96 but first, I have one technical question first: what is the origi= n of the =93-56.8=94 value for PSD that keeps cropping up in the examples to indicate =93not available=94?

=A0<= /p>

Thanks,

=A0<= /p>

Dan Harasty=

=A0

=A0<= /p>

=A0<= /p>

From: paws-bounces@iet= f.org [mailto:paws-bounces@ietf.org] On Behalf Of Ray Bellis
Sent: Monday, September 16, 2013 5:06 AM
To: Vincent Chen
Cc: paws@ietf.org=
Subject: Re: [paws] Encoding of spectrum profile

=A0

=A0

On 13 Sep 2013, at 17:00, Vincent Chen <vchen@google.com><= /u>

=A0wrote:



I see. Television channels do not occupy a contiguou= s range of frequencies. In the US,=A0

=A0

=A0 - [54MHz, 72MHz] =A0Channel 2-4

=A0 - [76MHz, 88MHz] =A0Channels 5-6

=A0 - [174MHz, 216MHz] Channels 7-13

=A0 - [470MHz, 698MHz] =A0Channels 14-51

=A0

So the response given by the database should not inc= lude any frequencies not in the plan.

=A0

That means a "spectrum profile" should be = encoded as a list of "array" of (frequency, power) points.=

=A0- Each array represents a "profile" for= a contiguous range of frequencies

=A0- The range of frequencies within a list of profi= les MUST be disjoint and SHOULD be sorted

=A0- The entire set of frequency bands defined by th= e regulatory domain MUST be represented by a single list of "profiles&= quot;

=A0 =A0(rather than split them across multiple lists= )

=A0

That last point is to remove ambiguity and, thus, va= riations in database implementation, to simplify logic on devices.

=A0

Example:

=A0

...



Does that address your concern?

=A0

It does, although I still think the original #1 data= model where each available frequency range was simply defined by (f1, f2, = psd1, psd2) is much better. =A0It's also more consistent with the ETSI = draft spec.

=A0

Using the #2 model of an array of (f, psd) points is= only more efficient as an encoding mechanism in those few cases where non-= zero PSD slopes do actually need to be encoded. =A0Any time there's a &= quot;step" jump in Psd you need just as much data to encode that jump using (f, psd) points as you would if you used (f= 1, f2, psd1, psd2).

=A0

Regarding=A0splitting the lists in the way you propo= se, that's not just a question of what frequencies are "in the pla= n". =A0The current OFCOM consultation proposes (=A75.93) "not to = allow WSD operation in channel 38" (606 - 614 MHz) as that's used for nationwide PMSE. =A0Channel 38 is definitely "in the plan&qu= ot;, but it's also a discontinuity. =A0Your proposed model would appear= to require that we break our frequency table in two either side of channel= 38, and ends up with a two dimensional array of arrays in the JSON encoding.

=A0

Using (f1, f2, p1, p2) allows the use of a single le= vel list of values, with the only constraint being that frequency ranges no= t overlap.

=A0

Your example for the US plan then just becomes (omit= ting the 100 kHz bandwidth):

=A0

"spectra": [

=A0 {

=A0 =A0 =A0"bandwidth": 6e6,=

=A0 =A0 =A0"frequencyRanges": [<= /u>

=A0 =A0 =A0 =A0 {"startHz": 5.4e7, "s= topHz", 7.2e7, "startPsd": -56.8, "stopPsd": -56.8= },

=A0 =A0 =A0 =A0 {"startHz": 7.6e7, "s= topHz", 8.8e7, "startPsd": -56.8, "stopPsd": -56.8= },

=A0 =A0 =A0 =A0 {"startHz": 1.74e8, "= stopHz", 2.16e8, "startPsd": -56.8, "stopPsd": -56= .8},

=A0 =A0 =A0 =A0 {"startHz": 4.70e8, "= stopHz", 5.18e8, "startPsd": -56.8, "stopPsd": -56= .8},

=A0 =A0 =A0 =A0 {"startHz": 5.18e8, "= stopHz", 5.24e8, "startPsd": 30.0, "stopPsd": 30.0= },

=A0 =A0 =A0 =A0 {"startHz": 5.24e8, "= stopHz", 5.30e8, "startPsd": 36.0, "stopPsd": 36.0= },

=A0 =A0 =A0 =A0 {"startHz": 5.30e8, "= stopHz", 5.30e8, "startPsd": -56.8, "stopPsd": -56= .8}

=A0 =A0 =A0]

=A0 ]

]

=A0

This requires 28 data values, exactly the same as in= your example. =A0It's also the smallest change necessary from the curr= ent spec in draft-ietf-paws-protocol-06 to support non-zero Psd slopes. =A0= For encoding efficiency one could also specify that PSD just be either a single value or a pair [psd1, psd2] for those no= n-zero slope cases.

=A0

kind regards,

=A0

Ray

=A0


_______________________________________________
paws mailing list
paws@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/paws



--001a11c35d141b940e04e685d261-- From Ray.Bellis@nominet.org.uk Mon Sep 16 13:17:52 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57CEC11E8113 for ; Mon, 16 Sep 2013 13:17:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.728 X-Spam-Level: X-Spam-Status: No, score=-8.728 tagged_above=-999 required=5 tests=[AWL=-0.430, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_OFF=2.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sGKi4TBmwHwu for ; Mon, 16 Sep 2013 13:17:47 -0700 (PDT) Received: from mx2.nominet.org.uk (mail.nominet.org.uk [213.248.242.49]) by ietfa.amsl.com (Postfix) with ESMTP id B080D11E80FC for ; Mon, 16 Sep 2013 13:17:45 -0700 (PDT) DomainKey-Signature: s=main2.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:From:To:CC:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:Content-Type: MIME-Version; b=EL/VEn0IS7gnU8OwJgWIAOiAR/3ArP3mENFP1AWLuKcMFJk/aJ+e3zWl jv+kZ6USQwJjIUxKEBQAXqR+6OO71k1C3xCyYGZv7Ovr+M+hLVvKAqZml eE1wLJINXZ5tYwmXK5GRGoq1YvA+QIsp3znDP32DNVv7jpp6Gi7cPngf2 q6oaElYSvb8s2AjsGaImtv8XeURNb6Kga/mTMloELwTdsoool2Uuq8Jqf hKVkraTUZJBOqqVFMeldhBY8CTWED; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=@nominet.org.uk; q=dns/txt; s=main2.dkim.nominet.selector; t=1379362666; x=1410898666; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=EoBnVnnCjbsPfSWF6zBvurayLtPbUvlNyT/etq+/8mo=; b=tqyCu8DXNt2DQdtYvImehaEW6ScK7nie7raIjJHjH+bpFkrK+Kns508S QUYhbOPepOsmZOvo+/X4GKG1eiF5sIgRWu8hlPpjqx+j9jAJiA4BjFBo7 Z1Kec7XuWIj3dO3fXOMtDv1Qsb7bQxSne3knE05UaV3BdYednvi8Khrsr cT7BBR41h1xxTGkGrKAJQAxU5hes8fwnxIu1qdIWko3wyBpCbBWE3bvmw Tw79d6e9MfLDQ5QBEhxmY6ObLz46N; X-IronPort-AV: E=Sophos;i="4.90,917,1371078000"; d="scan'208,217";a="3071369" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx2.nominet.org.uk with ESMTP; 16 Sep 2013 21:17:43 +0100 Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4%17]) with mapi id 14.02.0318.004; Mon, 16 Sep 2013 21:17:43 +0100 From: Ray Bellis To: Andy Lee Thread-Topic: [paws] Encoding of spectrum profile Thread-Index: AQHOoeQCmU+qkDwvDUSLePEjGLDDY5msmYcAgAAgqoCAAWO2gIAIKfUAgAIaGoCAAI/hAIAAKOJGgArFcQCABEM7AIAAeDoAgAAiI4CAACNWVP///HAAgAASSOw= Date: Mon, 16 Sep 2013 20:17:41 +0000 Message-ID: <4BEA42CA-5E20-4261-9833-9C84CC179C28@nominet.org.uk> References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DE89725@wds-exc1.okna.nominet.org.uk> <53F00E5CD8B2E34C81C0C89EB0B4FE732DE9A5BE@wds-exc1.okna.nominet.org.uk> <66C00FFB-47B3-4CC8-B592-5CE929E69702@nominet.org.uk>, In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_4BEA42CA5E20426198339C84CC179C28nominetorguk_" MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] Encoding of spectrum profile X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2013 20:17:52 -0000 --_000_4BEA42CA5E20426198339C84CC179C28nominetorguk_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Per my previous message, I mean the case where the WSDB profile permits two= adjacent channels to be used but the device only uses one of those. Is the permitted adjacent channel leakage into the unused channel supposed = to be specified in the PAWS spectrum profile or (as I would expect) by regu= latory device requirements? Ray Sent from my iPhone On 16 Sep 2013, at 21:12, "Andy Lee" > wrote: What do you mean by "otherwise permitted channels"? Andy Lee | Google Inc. | tvfool@google.com | 408-230-0522 On Mon, Sep 16, 2013 at 12:25 PM, Ray Bellis > wrote: And adjacent channel leakage into otherwise permitted channels is a matter = of regulatory device approval? Ray Sent from my iPhone On 16 Sep 2013, at 19:18, "Andy Lee" > wrote: what is the origin of the =93-56.8=94 value for PSD that keeps cropping up = in the examples to indicate =93not available=94? The FCC rules under 15.709(c)(1) require devices to have these adjacent cha= nnel emission limits to protect TV broadcasts. The "on" channels can be 16= , 20, or 36 dBm EIRP, and the "off" channels have specific limits of -52.8,= -56.8, or -36.8 dBm EIRP on adjacent channels that are occupied by TV. Andy Lee | Google Inc. | tvfool@google.com | 408-230-0522 On Mon, Sep 16, 2013 at 9:16 AM, Harasty, Daniel J > wrote: I very much agree with Ray=92s observations and resulting proposal. In fac= t: this exact email was in draft form in my head=85 I may have a few things to add =96 but first, I have one technical question= first: what is the origin of the =93-56.8=94 value for PSD that keeps crop= ping up in the examples to indicate =93not available=94? Thanks, Dan Harasty From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of Ray Bellis Sent: Monday, September 16, 2013 5:06 AM To: Vincent Chen Cc: paws@ietf.org Subject: Re: [paws] Encoding of spectrum profile On 13 Sep 2013, at 17:00, Vincent Chen > wrote: I see. Television channels do not occupy a contiguous range of frequencies.= In the US, - [54MHz, 72MHz] Channel 2-4 - [76MHz, 88MHz] Channels 5-6 - [174MHz, 216MHz] Channels 7-13 - [470MHz, 698MHz] Channels 14-51 So the response given by the database should not include any frequencies no= t in the plan. That means a "spectrum profile" should be encoded as a list of "array" of (= frequency, power) points. - Each array represents a "profile" for a contiguous range of frequencies - The range of frequencies within a list of profiles MUST be disjoint and = SHOULD be sorted - The entire set of frequency bands defined by the regulatory domain MUST = be represented by a single list of "profiles" (rather than split them across multiple lists) That last point is to remove ambiguity and, thus, variations in database im= plementation, to simplify logic on devices. Example: ... Does that address your concern? It does, although I still think the original #1 data model where each avail= able frequency range was simply defined by (f1, f2, psd1, psd2) is much bet= ter. It's also more consistent with the ETSI draft spec. Using the #2 model of an array of (f, psd) points is only more efficient as= an encoding mechanism in those few cases where non-zero PSD slopes do actu= ally need to be encoded. Any time there's a "step" jump in Psd you need ju= st as much data to encode that jump using (f, psd) points as you would if y= ou used (f1, f2, psd1, psd2). Regarding splitting the lists in the way you propose, that's not just a que= stion of what frequencies are "in the plan". The current OFCOM consultatio= n proposes (=A75.93) "not to allow WSD operation in channel 38" (606 - 614 = MHz) as that's used for nationwide PMSE. Channel 38 is definitely "in the = plan", but it's also a discontinuity. Your proposed model would appear to = require that we break our frequency table in two either side of channel 38,= and ends up with a two dimensional array of arrays in the JSON encoding. Using (f1, f2, p1, p2) allows the use of a single level list of values, wit= h the only constraint being that frequency ranges not overlap. Your example for the US plan then just becomes (omitting the 100 kHz bandwi= dth): "spectra": [ { "bandwidth": 6e6, "frequencyRanges": [ {"startHz": 5.4e7, "stopHz", 7.2e7, "startPsd": -56.8, "stopPsd": -= 56.8}, {"startHz": 7.6e7, "stopHz", 8.8e7, "startPsd": -56.8, "stopPsd": -= 56.8}, {"startHz": 1.74e8, "stopHz", 2.16e8, "startPsd": -56.8, "stopPsd":= -56.8}, {"startHz": 4.70e8, "stopHz", 5.18e8, "startPsd": -56.8, "stopPsd":= -56.8}, {"startHz": 5.18e8, "stopHz", 5.24e8, "startPsd": 30.0, "stopPsd": = 30.0}, {"startHz": 5.24e8, "stopHz", 5.30e8, "startPsd": 36.0, "stopPsd": = 36.0}, {"startHz": 5.30e8, "stopHz", 5.30e8, "startPsd": -56.8, "stopPsd":= -56.8} ] ] ] This requires 28 data values, exactly the same as in your example. It's al= so the smallest change necessary from the current spec in draft-ietf-paws-p= rotocol-06 to support non-zero Psd slopes. For encoding efficiency one cou= ld also specify that PSD just be either a single value or a pair [psd1, psd= 2] for those non-zero slope cases. kind regards, Ray _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws --_000_4BEA42CA5E20426198339C84CC179C28nominetorguk_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Per my previous message, I mean the case where the WSDB profile permit= s two adjacent channels to be used but the device only uses one of those.

Is the permitted adjacent channel leakage into the unused channel supp= osed to be specified in the PAWS spectrum profile or (as I would expect) by= regulatory device requirements?

Ray

Sent from my iPhone

On 16 Sep 2013, at 21:12, "Andy Lee" <tvfool@google.com> wrote:

What do you mean by "otherwise permitted channels&quo= t;?


Andy Lee |  Google Inc. |  tvfool@google.= com |  408-230-0522


On Mon, Sep 16, 2013 at 12:25 PM, Ray Bellis <Ray.Bell= is@nominet.org.uk> wrote:
And adjacent channel leakage into otherwise permitted channels is a ma= tter of regulatory device approval?

Ray

Sent from my iPhone

On 16 Sep 2013, at 19:18, "Andy Lee" <tvfool@google.com> wrote:

what is the origin of the =93-56.8=94 value for PSD that keeps crop= ping up in the examples to indicate =93not available=94?

The FCC rules under 15.709(c)(1) require devices= to have these adjacent channel emission limits to protect TV broadcasts. &= nbsp;The "on" channels can be 16, 20, or 36 dBm EIRP, and the &qu= ot;off" channels have specific limits of -52.8, -56.8, or -36.8 dBm EIRP on adjacent channels that are occupied by TV.


Andy Lee |  Google Inc. |  tvfool@google.= com |  408-230-0522


On Mon, Sep 16, 2013 at 9:16 AM, Harasty, Daniel= J <dharasty@ap= pcomsci.com> wrote:

I very much agree with Ra= y=92s observations and resulting proposal.  In fact: this exact email = was in draft form in my head=85

 

I may have a few things t= o add =96 but first, I have one technical question first: what is the origi= n of the =93-56.8=94 value for PSD that keeps cropping up in the examples to indicate =93not available=94?

 

Thanks,

 

Dan Harasty=

 

 

 

From: paws-bounces@iet= f.org [mailto:paws-bounces@ietf.org] On Behalf Of Ray Bellis
Sent: Monday, September 16, 2013 5:06 AM
To: Vincent Chen
Cc: paws@ietf.org=
Subject: Re: [paws] Encoding of spectrum profile

 

 

On 13 Sep 2013, at 17:00, Vincent Chen <vchen@google.com><= /u>

 wrote:



I see. Television channels do not occupy a contiguou= s range of frequencies. In the US, 

 

  - [54MHz, 72MHz]  Channel 2-4<= /u>

  - [76MHz, 88MHz]  Channels 5-6=

  - [174MHz, 216MHz] Channels 7-13

  - [470MHz, 698MHz]  Channels 14-51

 

So the response given by the database should not inc= lude any frequencies not in the plan.

 

That means a "spectrum profile" should be = encoded as a list of "array" of (frequency, power) points.=

 - Each array represents a "profile" = for a contiguous range of frequencies

 - The range of frequencies within a list of pr= ofiles MUST be disjoint and SHOULD be sorted

 - The entire set of frequency bands defined by= the regulatory domain MUST be represented by a single list of "profil= es"

   (rather than split them across multiple= lists)

 

That last point is to remove ambiguity and, thus, va= riations in database implementation, to simplify logic on devices.

 

Example:

 

...



Does that address your concern?

 

It does, although I still think the original #1 data= model where each available frequency range was simply defined by (f1, f2, = psd1, psd2) is much better.  It's also more consistent with the ETSI d= raft spec.

 

Using the #2 model of an array of (f, psd) points is= only more efficient as an encoding mechanism in those few cases where non-= zero PSD slopes do actually need to be encoded.  Any time there's a &q= uot;step" jump in Psd you need just as much data to encode that jump using (f, psd) points as you would if you used (f= 1, f2, psd1, psd2).

 

Regarding splitting the lists in the way you pr= opose, that's not just a question of what frequencies are "in the plan= ".  The current OFCOM consultation proposes (=A75.93) "not t= o allow WSD operation in channel 38" (606 - 614 MHz) as that's used for nationwide PMSE.  Channel 38 is definitely "in the plan= ", but it's also a discontinuity.  Your proposed model would appe= ar to require that we break our frequency table in two either side of chann= el 38, and ends up with a two dimensional array of arrays in the JSON encoding.

 

Using (f1, f2, p1, p2) allows the use of a single le= vel list of values, with the only constraint being that frequency ranges no= t overlap.

 

Your example for the US plan then just becomes (omit= ting the 100 kHz bandwidth):

 

"spectra": [

  {

     "bandwidth": 6e6,

     "frequencyRanges": [

        {"startHz": 5.= 4e7, "stopHz", 7.2e7, "startPsd": -56.8, "stopPsd&= quot;: -56.8},

        {"startHz": 7.= 6e7, "stopHz", 8.8e7, "startPsd": -56.8, "stopPsd&= quot;: -56.8},

        {"startHz": 1.= 74e8, "stopHz", 2.16e8, "startPsd": -56.8, "stopPs= d": -56.8},

        {"startHz": 4.= 70e8, "stopHz", 5.18e8, "startPsd": -56.8, "stopPs= d": -56.8},

        {"startHz": 5.= 18e8, "stopHz", 5.24e8, "startPsd": 30.0, "stopPsd= ": 30.0},

        {"startHz": 5.= 24e8, "stopHz", 5.30e8, "startPsd": 36.0, "stopPsd= ": 36.0},

        {"startHz": 5.= 30e8, "stopHz", 5.30e8, "startPsd": -56.8, "stopPs= d": -56.8}

     ]

  ]

]

 

This requires 28 data values, exactly the same as in= your example.  It's also the smallest change necessary from the curre= nt spec in draft-ietf-paws-protocol-06 to support non-zero Psd slopes. &nbs= p;For encoding efficiency one could also specify that PSD just be either a single value or a pair [psd1, psd2] for those no= n-zero slope cases.

 

kind regards,

 

Ray

 


_______________________________________________
paws mailing list
paws@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/paws



--_000_4BEA42CA5E20426198339C84CC179C28nominetorguk_-- From tvfool@google.com Mon Sep 16 13:30:28 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90D8311E81B1 for ; Mon, 16 Sep 2013 13:30:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.035 X-Spam-Level: X-Spam-Status: No, score=0.035 tagged_above=-999 required=5 tests=[AWL=-0.287, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MANGLED_OFF=2.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jew0pPyZjfAO for ; Mon, 16 Sep 2013 13:30:27 -0700 (PDT) Received: from mail-qc0-x234.google.com (mail-qc0-x234.google.com [IPv6:2607:f8b0:400d:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 2421511E8113 for ; Mon, 16 Sep 2013 13:30:26 -0700 (PDT) Received: by mail-qc0-f180.google.com with SMTP id p19so3090095qcv.11 for ; Mon, 16 Sep 2013 13:30:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZyC7hZB/f3fbmqEccyOKYhSwUtzHioavUH5kq+TAMSw=; b=DTfTs+RzckXx8UanRqDded2tO1ROqNYdh6J26FXMlQMZhYNTimwS8accqtkJOqxwtF FMkKUm9gY0D4CJT5RPWUjRNJZbfz4YAjNEO3GG/O3V4E4Vj/6ebu9HzxRvReYdK+xo5m HpW55oKHJqkfyhF9cY5InIjuCL9VZOGlstcQad/4Ff1E7J2Na4AtwKTe8L7eerWCVpXZ e+C+8wJUZ8++ua7cMrh+AxyPK41eKzkjr9GJ7uxY9Q3HRqbo2I3/DjXMzkIA8aOqAqHd AdSsLLQNjni/ZNMrn5NHUo9sCgzRxcc7dTxXd2mHZdLHF2mCER/QLE2mF2u6S+67D50m yeSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ZyC7hZB/f3fbmqEccyOKYhSwUtzHioavUH5kq+TAMSw=; b=YoKX9AtM4CUoyCytS4q4kdLW4IJS/UQfgNlH5S+B30vyORU68Pypw7VVg9FPH7akoN THylnoSlEGisGnQCwue7eGw7Ty88B4aO1W3iLrAQUdrv79s1L/1sjityBTODKQZVackU N9aNMgaGU6x9E9BTiVU59Jfl47Yuzuteu6lDB1ZnIZlNZpkMKmPtGp2AL0zPqDH2E3nZ HvnNVwd5yBFj5TL4dCYzYksrWW6Ly2Rs1+T/GM/wsrLecW3VgdHf55s/Zs4nnZJnmyi3 NkKHIKE5GY5T35Dd4rBWhP99+//ukDs8aDcLDygLeG+c5cgGLZZ2dGFN7MuQPdHG8bsd bweQ== X-Gm-Message-State: ALoCoQl0zyfQbq2O/Y6f9yyY4quCgPDnOXS1vq0glif054m+609ZkR2lEOP4MRa7A3/SavGvUY1pQJLFJAC+JkwNeFSvOXbNouHBXw4WgrB4slWsnlrH7we5rFQy0OlP8++LtQgopZMbNyQDNRnseQwFA1wcLpoxL7jPGYGJJJdVCkHovBGP1HdXlgZYSe8Vln9+KMxzdYOq MIME-Version: 1.0 X-Received: by 10.49.75.103 with SMTP id b7mr4662708qew.85.1379363426391; Mon, 16 Sep 2013 13:30:26 -0700 (PDT) Received: by 10.229.207.8 with HTTP; Mon, 16 Sep 2013 13:30:26 -0700 (PDT) In-Reply-To: <4BEA42CA-5E20-4261-9833-9C84CC179C28@nominet.org.uk> References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DE89725@wds-exc1.okna.nominet.org.uk> <53F00E5CD8B2E34C81C0C89EB0B4FE732DE9A5BE@wds-exc1.okna.nominet.org.uk> <66C00FFB-47B3-4CC8-B592-5CE929E69702@nominet.org.uk> <4BEA42CA-5E20-4261-9833-9C84CC179C28@nominet.org.uk> Date: Mon, 16 Sep 2013 13:30:26 -0700 Message-ID: From: Andy Lee To: Ray Bellis Content-Type: multipart/alternative; boundary=047d7bd76dba0bf26804e6861303 Cc: "paws@ietf.org" Subject: Re: [paws] Encoding of spectrum profile X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2013 20:30:28 -0000 --047d7bd76dba0bf26804e6861303 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Under FCC rules, there is no specific requirement for how signal power is distributed between multiple "on" channels. The rules are designed to protect the TV broadcasts, so as long as the WSD's out-of-band emissions stay below the "off" channel power limits, the TV broadcasts will have the protection they need. Andy Lee | Google Inc. | tvfool@google.com | 408-230-0522 On Mon, Sep 16, 2013 at 1:17 PM, Ray Bellis wrot= e: > Per my previous message, I mean the case where the WSDB profile permits > two adjacent channels to be used but the device only uses one of those. > > Is the permitted adjacent channel leakage into the unused channel > supposed to be specified in the PAWS spectrum profile or (as I would > expect) by regulatory device requirements? > > Ray > > Sent from my iPhone > > On 16 Sep 2013, at 21:12, "Andy Lee" wrote: > > What do you mean by "otherwise permitted channels"? > > > Andy Lee | Google Inc. | tvfool@google.com | 408-230-0522 > > > On Mon, Sep 16, 2013 at 12:25 PM, Ray Bellis w= rote: > >> And adjacent channel leakage into otherwise permitted channels is a >> matter of regulatory device approval? >> >> Ray >> >> Sent from my iPhone >> >> On 16 Sep 2013, at 19:18, "Andy Lee" wrote: >> >> what is the origin of the =93-56.8=94 value for PSD that keeps croppi= ng >>> up in the examples to indicate =93not available=94? >> >> >> The FCC rules under 15.709(c)(1) require devices to have these adjacent >> channel emission limits to protect TV broadcasts. The "on" channels can= be >> 16, 20, or 36 dBm EIRP, and the "off" channels have specific limits of >> -52.8, -56.8, or -36.8 dBm EIRP on adjacent channels that are occupied b= y >> TV. >> >> >> Andy Lee | Google Inc. | tvfool@google.com | 408-230-0522 >> >> >> On Mon, Sep 16, 2013 at 9:16 AM, Harasty, Daniel J < >> dharasty@appcomsci.com> wrote: >> >>> I very much agree with Ray=92s observations and resulting proposal. I= n >>> fact: this exact email was in draft form in my head=85**** >>> >>> ** ** >>> >>> I may have a few things to add =96 but first, I have one technical >>> question first: what is the origin of the =93-56.8=94 value for PSD tha= t keeps >>> cropping up in the examples to indicate =93not available=94?**** >>> >>> ** ** >>> >>> Thanks,**** >>> >>> ** ** >>> >>> Dan Harasty**** >>> >>> ** ** >>> >>> ** ** >>> >>> ** ** >>> >>> *From:* paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] *On Behalf >>> Of *Ray Bellis >>> *Sent:* Monday, September 16, 2013 5:06 AM >>> *To:* Vincent Chen >>> *Cc:* paws@ietf.org >>> *Subject:* Re: [paws] Encoding of spectrum profile**** >>> >>> ** ** >>> >>> ** ** >>> >>> On 13 Sep 2013, at 17:00, Vincent Chen **** >>> >>> wrote:**** >>> >>> >>> >>> **** >>> >>> I see. Television channels do not occupy a contiguous range of >>> frequencies. In the US, **** >>> >>> ** ** >>> >>> - [54MHz, 72MHz] Channel 2-4**** >>> >>> - [76MHz, 88MHz] Channels 5-6**** >>> >>> - [174MHz, 216MHz] Channels 7-13**** >>> >>> - [470MHz, 698MHz] Channels 14-51**** >>> >>> ** ** >>> >>> So the response given by the database should not include any frequencie= s >>> not in the plan.**** >>> >>> ** ** >>> >>> That means a "spectrum profile" should be encoded as a list of "array" >>> of (frequency, power) points.**** >>> >>> - Each array represents a "profile" for a contiguous range of >>> frequencies**** >>> >>> - The range of frequencies within a list of profiles MUST be disjoint >>> and SHOULD be sorted**** >>> >>> - The entire set of frequency bands defined by the regulatory domain >>> MUST be represented by a single list of "profiles"**** >>> >>> (rather than split them across multiple lists)**** >>> >>> ** ** >>> >>> That last point is to remove ambiguity and, thus, variations in databas= e >>> implementation, to simplify logic on devices.**** >>> >>> ** ** >>> >>> Example:**** >>> >>> ** ** >>> >>> ...**** >>> >>> >>> >>> **** >>> >>> Does that address your concern?**** >>> >>> ** ** >>> >>> It does, although I still think the original #1 data model where each >>> available frequency range was simply defined by (f1, f2, psd1, psd2) is >>> much better. It's also more consistent with the ETSI draft spec.**** >>> >>> ** ** >>> >>> Using the #2 model of an array of (f, psd) points is only more efficien= t >>> as an encoding mechanism in those few cases where non-zero PSD slopes d= o >>> actually need to be encoded. Any time there's a "step" jump in Psd you >>> need just as much data to encode that jump using (f, psd) points as you >>> would if you used (f1, f2, psd1, psd2).**** >>> >>> ** ** >>> >>> Regarding splitting the lists in the way you propose, that's not just a >>> question of what frequencies are "in the plan". The current OFCOM >>> consultation proposes (=A75.93) "not to allow WSD operation in channel = 38" >>> (606 - 614 MHz) as that's used for nationwide PMSE. Channel 38 is >>> definitely "in the plan", but it's also a discontinuity. Your proposed >>> model would appear to require that we break our frequency table in two >>> either side of channel 38, and ends up with a two dimensional array of >>> arrays in the JSON encoding.**** >>> >>> ** ** >>> >>> Using (f1, f2, p1, p2) allows the use of a single level list of values, >>> with the only constraint being that frequency ranges not overlap.**** >>> >>> ** ** >>> >>> Your example for the US plan then just becomes (omitting the 100 kHz >>> bandwidth):**** >>> >>> ** ** >>> >>> "spectra": [**** >>> >>> {**** >>> >>> "bandwidth": 6e6,**** >>> >>> "frequencyRanges": [**** >>> >>> {"startHz": 5.4e7, "stopHz", 7.2e7, "startPsd": -56.8, >>> "stopPsd": -56.8},**** >>> >>> {"startHz": 7.6e7, "stopHz", 8.8e7, "startPsd": -56.8, >>> "stopPsd": -56.8},**** >>> >>> {"startHz": 1.74e8, "stopHz", 2.16e8, "startPsd": -56.8, >>> "stopPsd": -56.8},**** >>> >>> {"startHz": 4.70e8, "stopHz", 5.18e8, "startPsd": -56.8, >>> "stopPsd": -56.8},**** >>> >>> {"startHz": 5.18e8, "stopHz", 5.24e8, "startPsd": 30.0, >>> "stopPsd": 30.0},**** >>> >>> {"startHz": 5.24e8, "stopHz", 5.30e8, "startPsd": 36.0, >>> "stopPsd": 36.0},**** >>> >>> {"startHz": 5.30e8, "stopHz", 5.30e8, "startPsd": -56.8, >>> "stopPsd": -56.8}**** >>> >>> ]**** >>> >>> ]**** >>> >>> ]**** >>> >>> ** ** >>> >>> This requires 28 data values, exactly the same as in your example. It'= s >>> also the smallest change necessary from the current spec in >>> draft-ietf-paws-protocol-06 to support non-zero Psd slopes. For encodi= ng >>> efficiency one could also specify that PSD just be either a single valu= e or >>> a pair [psd1, psd2] for those non-zero slope cases.**** >>> >>> ** ** >>> >>> kind regards,**** >>> >>> ** ** >>> >>> Ray**** >>> >>> ** ** >>> >>> _______________________________________________ >>> paws mailing list >>> paws@ietf.org >>> https://www.ietf.org/mailman/listinfo/paws >>> >>> >> > --047d7bd76dba0bf26804e6861303 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Under FCC rules, there is no specific requirement for how = signal power is distributed between multiple "on" channels. =A0Th= e rules are designed to protect the TV broadcasts, so as long as the WSD= 9;s out-of-band emissions stay below the "off" channel power limi= ts, the TV broadcasts will have the protection they need.




On Mon, Sep 16, 2013 at 1:17 PM, Ray Bel= lis <Ray.Bellis@nominet.org.uk> wrote:
Per my previous message, I mean the case where the WSDB profile permit= s two adjacent channels to be used but the device only uses one of those.

Is the permitted adjacent channel leakage into the unused channel supp= osed to be specified in the PAWS spectrum profile or (as I would expect) by= regulatory device requirements?

Ray

Sent from my iPhone

On 16 Sep 2013, at 21:12, "Andy Lee" <tvfool@google.com> wrote:

What do you mean by "otherwise permitted channels&quo= t;?


Andy Lee=A0|=A0Google Inc. | =A0tvfool@google.com= =A0|=A0408-230-0522
Andy Lee=A0| =A0Google Inc. | =A0tvfool@google.com= =A0| =A040= 8-230-0522


On Mon, Sep 16, 2013 at 12:25 PM, Ray Bellis <Ray.Bell= is@nominet.org.uk> wrote:
And adjacent channel leakage into otherwise permitted channels is a ma= tter of regulatory device approval?

Ray

Sent from my iPhone

On 16 Sep 2013, at 19:18, "Andy Lee" <tvfool@google.com> wrote:

what is the origin of the =93-56.8=94 value for PSD that keeps crop= ping up in the examples to indicate =93not available=94?

The FCC rules under 15.709(c)(1) require devices= to have these adjacent channel emission limits to protect TV broadcasts. = =A0The "on" channels can be 16, 20, or 36 dBm EIRP, and the "= ;off" channels have specific limits of -52.8, -56.8, or -36.8 dBm EIRP on adjacent channels that are occupied by TV.


Andy Lee=A0| =A0Google Inc. | =A0tvfool@google.com= =A0| =A040= 8-230-0522


On Mon, Sep 16, 2013 at 9:16 AM, Harasty, Daniel= J <dharasty@ap= pcomsci.com> wrote:

I very much agree with Ra= y=92s observations and resulting proposal.=A0 In fact: this exact email was= in draft form in my head=85

=A0<= /p>

I may have a few things t= o add =96 but first, I have one technical question first: what is the origi= n of the =93-56.8=94 value for PSD that keeps cropping up in the examples to indicate =93not available=94?

=A0<= /p>

Thanks,

=A0<= /p>

Dan Harasty=

=A0

=A0<= /p>

=A0<= /p>

From: paws-bounces@iet= f.org [mailto:paws-bounces@ietf.org] On Behalf Of Ray Bellis
Sent: Monday, September 16, 2013 5:06 AM
To: Vincent Chen
Cc: paws@ietf.org=
Subject: Re: [paws] Encoding of spectrum profile

=A0

=A0

On 13 Sep 2013, at 17:00, Vincent Chen <vchen@google.com><= /u>

=A0wrote:



I see. Television channels do not occupy a contiguou= s range of frequencies. In the US,=A0

=A0

=A0 - [54MHz, 72MHz] =A0Channel 2-4

=A0 - [76MHz, 88MHz] =A0Channels 5-6

=A0 - [174MHz, 216MHz] Channels 7-13

=A0 - [470MHz, 698MHz] =A0Channels 14-51

=A0

So the response given by the database should not inc= lude any frequencies not in the plan.

=A0

That means a "spectrum profile" should be = encoded as a list of "array" of (frequency, power) points.=

=A0- Each array represents a "profile" for= a contiguous range of frequencies

=A0- The range of frequencies within a list of profi= les MUST be disjoint and SHOULD be sorted

=A0- The entire set of frequency bands defined by th= e regulatory domain MUST be represented by a single list of "profiles&= quot;

=A0 =A0(rather than split them across multiple lists= )

=A0

That last point is to remove ambiguity and, thus, va= riations in database implementation, to simplify logic on devices.

=A0

Example:

=A0

...



Does that address your concern?

=A0

It does, although I still think the original #1 data= model where each available frequency range was simply defined by (f1, f2, = psd1, psd2) is much better. =A0It's also more consistent with the ETSI = draft spec.

=A0

Using the #2 model of an array of (f, psd) points is= only more efficient as an encoding mechanism in those few cases where non-= zero PSD slopes do actually need to be encoded. =A0Any time there's a &= quot;step" jump in Psd you need just as much data to encode that jump using (f, psd) points as you would if you used (f= 1, f2, psd1, psd2).

=A0

Regarding=A0splitting the lists in the way you propo= se, that's not just a question of what frequencies are "in the pla= n". =A0The current OFCOM consultation proposes (=A75.93) "not to = allow WSD operation in channel 38" (606 - 614 MHz) as that's used for nationwide PMSE. =A0Channel 38 is definitely "in the plan&qu= ot;, but it's also a discontinuity. =A0Your proposed model would appear= to require that we break our frequency table in two either side of channel= 38, and ends up with a two dimensional array of arrays in the JSON encoding.

=A0

Using (f1, f2, p1, p2) allows the use of a single le= vel list of values, with the only constraint being that frequency ranges no= t overlap.

=A0

Your example for the US plan then just becomes (omit= ting the 100 kHz bandwidth):

=A0

"spectra": [

=A0 {

=A0 =A0 =A0"bandwidth": 6e6,=

=A0 =A0 =A0"frequencyRanges": [<= /u>

=A0 =A0 =A0 =A0 {"startHz": 5.4e7, "s= topHz", 7.2e7, "startPsd": -56.8, "stopPsd": -56.8= },

=A0 =A0 =A0 =A0 {"startHz": 7.6e7, "s= topHz", 8.8e7, "startPsd": -56.8, "stopPsd": -56.8= },

=A0 =A0 =A0 =A0 {"startHz": 1.74e8, "= stopHz", 2.16e8, "startPsd": -56.8, "stopPsd": -56= .8},

=A0 =A0 =A0 =A0 {"startHz": 4.70e8, "= stopHz", 5.18e8, "startPsd": -56.8, "stopPsd": -56= .8},

=A0 =A0 =A0 =A0 {"startHz": 5.18e8, "= stopHz", 5.24e8, "startPsd": 30.0, "stopPsd": 30.0= },

=A0 =A0 =A0 =A0 {"startHz": 5.24e8, "= stopHz", 5.30e8, "startPsd": 36.0, "stopPsd": 36.0= },

=A0 =A0 =A0 =A0 {"startHz": 5.30e8, "= stopHz", 5.30e8, "startPsd": -56.8, "stopPsd": -56= .8}

=A0 =A0 =A0]

=A0 ]

]

=A0

This requires 28 data values, exactly the same as in= your example. =A0It's also the smallest change necessary from the curr= ent spec in draft-ietf-paws-protocol-06 to support non-zero Psd slopes. =A0= For encoding efficiency one could also specify that PSD just be either a single value or a pair [psd1, psd2] for those no= n-zero slope cases.

=A0

kind regards,

=A0

Ray

=A0


_______________________________________________
paws mailing list
paws@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/paws




--047d7bd76dba0bf26804e6861303-- From paul@marvell.com Mon Sep 16 18:03:21 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C048C11E82CB for ; Mon, 16 Sep 2013 18:03:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V3s0LoyEsuL2 for ; Mon, 16 Sep 2013 18:03:16 -0700 (PDT) Received: from mx0a-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) by ietfa.amsl.com (Postfix) with ESMTP id B677111E82BF for ; Mon, 16 Sep 2013 18:03:14 -0700 (PDT) Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.14.5/8.14.5) with SMTP id r8H13C8J013137; Mon, 16 Sep 2013 18:03:12 -0700 Received: from sc-owa.marvell.com ([199.233.58.135]) by mx0a-0016f401.pphosted.com with ESMTP id 1evmnbu960-4 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 16 Sep 2013 18:03:12 -0700 Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA.marvell.com ([::1]) with mapi; Mon, 16 Sep 2013 18:03:03 -0700 From: Paul Lambert To: "Harasty, Daniel J" , Ray Bellis , Vincent Chen Date: Mon, 16 Sep 2013 18:03:02 -0700 Thread-Topic: [paws] Encoding of spectrum profile Thread-Index: Ac6zQajO5s1yMkf0RJKIdJcO4dHuWw== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CE5CF7EA2227Epaulmarvellcom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-09-16_05:2013-09-16, 2013-09-16, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1309160135 Cc: "paws@ietf.org" Subject: Re: [paws] Encoding of spectrum profile X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 01:03:22 -0000 --_000_CE5CF7EA2227Epaulmarvellcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Using (f1, f2, p1, p2) allows the use of a single level list of values, wit= h the only constraint being that frequency ranges not overlap. The proposal from Vince is a more rational structure and maintains the sema= ntics of groups of bands. There's no need to be throwing away information to save a few octets. Paul --_000_CE5CF7EA2227Epaulmarvellcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Using (f1, f2, p1, p2) allows the use of a single level list of values, wit= h the only constraint being that frequency ranges not overlap.


The proposal from Vi= nce is a more rational structure and maintains the semantics of groups of b= ands.

There's no need to be throwing away informat= ion to save a few octets.

Paul

--_000_CE5CF7EA2227Epaulmarvellcom_-- From Ray.Bellis@nominet.org.uk Tue Sep 17 01:12:14 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E57EF11E83A4 for ; Tue, 17 Sep 2013 01:12:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.807 X-Spam-Level: X-Spam-Status: No, score=-9.807 tagged_above=-999 required=5 tests=[AWL=0.791, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iX9trXPmUj0s for ; Tue, 17 Sep 2013 01:12:10 -0700 (PDT) Received: from mx1.nominet.org.uk (mx1.nominet.org.uk [213.248.242.48]) by ietfa.amsl.com (Postfix) with ESMTP id 8234111E83A2 for ; Tue, 17 Sep 2013 01:12:08 -0700 (PDT) DomainKey-Signature: s=main2.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:From:To:CC:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:x-originating-ip: Content-Type:MIME-Version; b=vFrsEZw6lGSlWvV56h8vpr/Qz4KRTgjV5jS/IhUPCZONAL1oYUsOecUV /okvX12PBDTwdFaaPadFYnJ61NZOtXYTodwHCoAQQMv4D5RFW24GVgbQB Lt2mW3XfFpJ/N1Ko770e63eR/3v1ZnfCrcuMNy5+Ig1z1YcvkK5mvJFsv vK1mYjSll80B/fDC0NPotmhi24D7vvPaO0JCkiE6gJagKUKBw26OugqGq C8TR7PZ3rTr3soLeN+9mXTyY36MOL; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=@nominet.org.uk; q=dns/txt; s=main2.dkim.nominet.selector; t=1379405529; x=1410941529; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=/ndf/WCJH3MFRJj9OkD27Iyt9t2gHf0MMhNG3s9zOYg=; b=Py4up5+9CKC4ZBkAiH06K3JiuydwtNwZsxpmSXmC25jS+rcO3W/xwQlZ qjuh168YI4/rdEkvWzb5lvn/m3GhZg8drX62f1+Pn04cQcZ+62KoOIj20 aox11uSLrMu6vUYWWFgKhLhCRKWH6dz7uwylFvOMXC5sVYvWfe1caBp2C GllGEJKrjf5iCtwSor0swEWy0ZeKni/puPcpR9ndLBwd8ptOrSHlATRvc XhJ+CzwV2ekHyKXPjpEq9GVylEEkT; X-IronPort-AV: E=Sophos;i="4.90,921,1371078000"; d="scan'208,217";a="3398343" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx1.nominet.org.uk with ESMTP; 17 Sep 2013 09:12:06 +0100 Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4%17]) with mapi id 14.02.0318.004; Tue, 17 Sep 2013 09:12:06 +0100 From: Ray Bellis To: Paul Lambert Thread-Topic: [paws] Encoding of spectrum profile Thread-Index: AQHOoeQCmU+qkDwvDUSLePEjGLDDY5msmYcAgAAgqoCAAWO2gIAIKfUAgAIaGoCAAI/hAIAAKOJGgArFcQCABEM7AIAAeDoAgACTJgCAAHfggA== Date: Tue, 17 Sep 2013 08:12:05 +0000 Message-ID: <53F00E5CD8B2E34C81C0C89EB0B4FE732DE9D173@wds-exc1.okna.nominet.org.uk> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.2.1] Content-Type: multipart/alternative; boundary="_000_53F00E5CD8B2E34C81C0C89EB0B4FE732DE9D173wdsexc1oknanomi_" MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] Encoding of spectrum profile X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 08:12:15 -0000 --_000_53F00E5CD8B2E34C81C0C89EB0B4FE732DE9D173wdsexc1oknanomi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On 17 Sep 2013, at 02:03, Paul Lambert > wrote: The proposal from Vince is a more rational structure and maintains the sema= ntics of groups of bands. Can you clarify exactly what you mean by "groups of bands"? Previous messa= ges talked about how the US TV spectrum is indeed a set of four separate ba= nds. However the EuroDTT spectrum is not, it's a single contiguous band. There's no need to be throwing away information to save a few octets. What information is being being thrown away? This is not about saving octets. (f1, f2, p1, p2) is at best the same as (= f, p) and when the PSD slope is non-zero it's slightly less efficient. I need the ability to represent a frequency discontinuity *within* a nomina= lly contiguous band, ideally without having to treat that band as if it wer= e actually two or more separate bands. If your intention above is to allow the full information about the _channel= plan_ to be represented that's OK, but that's _not_ the right semantics fo= r representing a non-permitted channel in a contiguous band. Ray --_000_53F00E5CD8B2E34C81C0C89EB0B4FE732DE9D173wdsexc1oknanomi_ Content-Type: text/html; charset="us-ascii" Content-ID: <8C723EDB063B644D8D31D777021A7758@okna.nominet.org.uk> Content-Transfer-Encoding: quoted-printable
On 17 Sep 2013, at 02:03, Paul Lambert <paul@marvell.com>
 wrote:

The proposal from Vince is a more rational structure and maintains the= semantics of groups of bands.

Can you clarify exactly what you mean by "groups of bands"? =  Previous messages talked about how the US TV spectrum is indeed a set= of four separate bands.  However the EuroDTT spectrum is not, it's a = single contiguous band.

There's no need to be throwing away information to save a few octets.<= /div>

What information is being being thrown away?

This is not about saving octets.  (f1, f2, p1, p2) is at bes= t the same as (f, p) and when the PSD slope is non-zero it's slightly = less efficient. 

I need the ability to represent a frequency discontinuity *within* a n= ominally contiguous band, ideally without having to treat that band as if i= t were actually two or more separate bands.

If your intention above is to allow the full information about the _ch= annel plan_ to be represented that's OK, but that's _not_ the right semanti= cs for representing a non-permitted channel in a contiguous band.

Ray

--_000_53F00E5CD8B2E34C81C0C89EB0B4FE732DE9D173wdsexc1oknanomi_-- From paul@marvell.com Tue Sep 17 01:34:07 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFA1511E80F3 for ; Tue, 17 Sep 2013 01:34:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oq0YYGJxTWmt for ; Tue, 17 Sep 2013 01:34:02 -0700 (PDT) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) by ietfa.amsl.com (Postfix) with ESMTP id ED65E11E8396 for ; Tue, 17 Sep 2013 01:34:01 -0700 (PDT) Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.14.5/8.14.5) with SMTP id r8H8Vp18008242; Tue, 17 Sep 2013 01:34:01 -0700 Received: from sc-owa02.marvell.com ([199.233.58.137]) by mx0b-0016f401.pphosted.com with ESMTP id 1exh9trkdt-1 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 17 Sep 2013 01:34:00 -0700 Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by sc-owa02.marvell.com ([10.93.76.22]) with mapi; Tue, 17 Sep 2013 01:33:59 -0700 From: Paul Lambert To: Ray Bellis Date: Tue, 17 Sep 2013 01:33:57 -0700 Thread-Topic: [paws] Encoding of spectrum profile Thread-Index: Ac6zgKf/hilsdNl/RDuBnzpoNn7+bw== Message-ID: In-Reply-To: <53F00E5CD8B2E34C81C0C89EB0B4FE732DE9D173@wds-exc1.okna.nominet.org.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CE5E340B22413paulmarvellcom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-09-17_03:2013-09-17, 2013-09-16, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1309170009 Cc: "paws@ietf.org" Subject: Re: [paws] Encoding of spectrum profile X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 08:34:07 -0000 --_000_CE5E340B22413paulmarvellcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable The proposal from Vince is a more rational structure and maintains the sema= ntics of groups of bands. Can you clarify exactly what you mean by "groups of bands"? Previous messa= ges talked about how the US TV spectrum is indeed a set of four separate ba= nds. However the EuroDTT spectrum is not, it's a single contiguous band. There's no need to be throwing away information to save a few octets. What information is being being thrown away? This is not about saving octets. (f1, f2, p1, p2) is at best the same as (= f, p) and when the PSD slope is non-zero it's slightly less efficient. I need the ability to represent a frequency discontinuity *within* a nomina= lly contiguous band, ideally without having to treat that band as if it wer= e actually two or more separate bands. If your intention above is to allow the full information about the _channel= plan_ to be represented that's OK, but that's _not_ the right semantics fo= r representing a non-permitted channel in a contiguous band. Yes =96 I feel it's important to retain a definition and identification of = the channels. I may not be fully understanding your notion of a discontinu= ity within a band. I'd typically assume that system need well defined chan= nels within a band that each could be also given masks that might vary depe= nding on adjacency considerations. Paul Ray --_000_CE5E340B22413paulmarvellcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
=
The proposal from Vince is a more rational structure and maintains the= semantics of groups of bands.

Can you clarify exa= ctly what you mean by "groups of bands"?  Previous messages = talked about how the US TV spectrum is indeed a set of four separate bands.=  However the EuroDTT spectrum is not, it's a single contiguous band.<= /div>

There's no ne= ed to be throwing away information to save a few octets.

What information is being being thrown away?

This is not about saving octets.  (f1, f2, p1, p2) is = at best the same as (f, p) and when the PSD slope is non-zero it'= s slightly less efficient. 

I need the abilit= y to represent a frequency discontinuity *within* a nominally contiguous ba= nd, ideally without having to treat that band as if it were actually two or= more separate bands.

If your intention above is t= o allow the full information about the _channel plan_ to be represented tha= t's OK, but that's _not_ the right semantics for representing a non-permitt= ed channel in a contiguous band.
= Yes =96 I feel it's important to retain a definition and identification of = the channels.  I may not be fully understanding your notion of a disco= ntinuity within a band.  I'd typically assume that system need well de= fined channels within a band that each could be also given masks that might= vary depending on adjacency considerations.  

Paul



Ray



--_000_CE5E340B22413paulmarvellcom_-- From Ray.Bellis@nominet.org.uk Tue Sep 17 02:08:07 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE0AD11E83CD for ; Tue, 17 Sep 2013 02:08:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.92 X-Spam-Level: X-Spam-Status: No, score=-9.92 tagged_above=-999 required=5 tests=[AWL=0.678, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fT6aM58JjOvF for ; Tue, 17 Sep 2013 02:08:02 -0700 (PDT) Received: from mx1.nominet.org.uk (mail.nominet.org.uk [213.248.242.48]) by ietfa.amsl.com (Postfix) with ESMTP id 4445D11E83AB for ; Tue, 17 Sep 2013 02:08:01 -0700 (PDT) DomainKey-Signature: s=main2.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:From:To:CC:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:x-originating-ip: Content-Type:MIME-Version; b=SfgW7lWfzcN8R0os4oasxdh/T2ItyfegFDpLCm20SXktvT7djObv0lae an3edtkgZ+uq10w1OkDQvmrPFZCG5b8Fa0mmVEgx2NCErUyNMKf/bjkcB uKMJhKmeC1DwcfXgMaUnMsjDgeWIaWz08amWW0YpUTkfwbNFKeWRHpSmH 0C1f0H8lPV9kCl9I+nF9TnpvAQB7+2yUXz6qlsgxEkiTVnmEhIP/38NHu TfCsYSbtuin9AyrVbrg9td8Kcuwki; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=@nominet.org.uk; q=dns/txt; s=main2.dkim.nominet.selector; t=1379408882; x=1410944882; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Mzu7d5EoaznsWKuV8YqcW1+q8Lz69U0pbJU5l18K3Ws=; b=ESpt0P9wM2SHSicBSW5XHfbXtjCbUbjDMJs8nhIUdfGVUL9HxDRTdv0R 6UGadcTj4OPpNqHFzKoEorlPpSsnx4VY2wJ3Z/vbzlqBQqrcL89xKc2Aw vxOb3kBG1q5iwtrtGMECv3F0eA80qHA2jrs0Ihg9nFln0bDe4nJc2ctD5 ySnLbEAwLMnLFEbybxjZB1biKPx3AihSALzHrMGK0naWESo8tw5/YfiNC TAXOkmI4Rug6o3B6sq1OMIC1RBpVX; X-IronPort-AV: E=Sophos;i="4.90,922,1371078000"; d="scan'208,217";a="3399809" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx1.nominet.org.uk with ESMTP; 17 Sep 2013 10:08:00 +0100 Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4%17]) with mapi id 14.02.0318.004; Tue, 17 Sep 2013 10:07:59 +0100 From: Ray Bellis To: Paul Lambert Thread-Topic: [paws] Encoding of spectrum profile Thread-Index: AQHOoeQCmU+qkDwvDUSLePEjGLDDY5msmYcAgAAgqoCAAWO2gIAIKfUAgAIaGoCAAI/hAIAAKOJGgArFcQCABEM7AIAAeDoAgACTJgCAAHfggIAABhyAgAAJgoA= Date: Tue, 17 Sep 2013 09:07:59 +0000 Message-ID: <53F00E5CD8B2E34C81C0C89EB0B4FE732DE9D633@wds-exc1.okna.nominet.org.uk> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.2.1] Content-Type: multipart/alternative; boundary="_000_53F00E5CD8B2E34C81C0C89EB0B4FE732DE9D633wdsexc1oknanomi_" MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] Encoding of spectrum profile X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 09:08:07 -0000 --_000_53F00E5CD8B2E34C81C0C89EB0B4FE732DE9D633wdsexc1oknanomi_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On 17 Sep 2013, at 09:33, Paul Lambert > wrote: Yes =96 I feel it's important to retain a definition and identification of = the channels. Can you elaborate on why you feel that's important? Why does a device "car= e" about the fact that the US TV band is split into four discrete bands - s= urely all that matters is the specific frequencies it's permitted to use? I may not be fully understanding your notion of a discontinuity within a ba= nd. I'd typically assume that system need well defined channels within a b= and that each could be also given masks that might vary depending on adjace= ncy considerations. In the OFCOM model channel 38 will not be available for _primary_ transmiss= ion, but AIUI a very small amount of adjacent channel leakage into it will = be permitted. The OFCOM / ETSI model doesn't need (or want) masks to be encoded within th= e messages for that channel, they're implicit in the device approval requi= rements. To further reduce the adjacent channel leakage the permitted power levels (= for certain WSD emission classes) for primary transmissions in the adjacent= channels are also reduced. That frequency is therefore simply omitted from the list of available chann= els. What I don't want to see is that break _within_ the band getting conf= lated with breaks _between_ bands. Ray --_000_53F00E5CD8B2E34C81C0C89EB0B4FE732DE9D633wdsexc1oknanomi_ Content-Type: text/html; charset="Windows-1252" Content-ID: <216A7B875A842F4AA367BD01509CC4E2@okna.nominet.org.uk> Content-Transfer-Encoding: quoted-printable
On 17 Sep 2013, at 09:33, Paul Lambert <paul@marvell.com>
 wrote:

Yes =96 I feel it's important to retain a definition and identificatio= n of the channels.

Can you elaborate on why you feel that's important?  Why does a device= "care" about the fact that the US TV band is split into four dis= crete bands - surely all that matters is the specific frequencies it's perm= itted to use?

I may not be fully understanding your notion of a discontinuity within= a band.  I'd typically assume that system need well defined channels = within a band that each could be also given masks that might vary depending= on adjacency considerations.  

In the OFCOM model channel 38 will not be available for _primary_ transmiss= ion, but AIUI a very small amount of adjacent channel leakage into it will = be permitted.

The OFCOM / ETSI model doesn't need (or want) masks to be encoded with= in the messages for that channel,  they're implicit in the device= approval requirements.

To further reduce the adjacent channel leakage the permitted power lev= els (for certain WSD emission classes) for primary transmissions in the adj= acent channels are also reduced.

That frequency is therefore simply omitted from the list of avail= able channels.  What I don't want to see is that break _within_ the ba= nd getting conflated with breaks _between_ bands.

Ray

--_000_53F00E5CD8B2E34C81C0C89EB0B4FE732DE9D633wdsexc1oknanomi_-- From Gabor.Bajko@nokia.com Tue Sep 17 15:17:10 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30A6811E85EF for ; Tue, 17 Sep 2013 15:17:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.448 X-Spam-Level: X-Spam-Status: No, score=-5.448 tagged_above=-999 required=5 tests=[AWL=1.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v1I5vqkttGy6 for ; Tue, 17 Sep 2013 15:17:03 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 69A3511E85EB for ; Tue, 17 Sep 2013 15:16:57 -0700 (PDT) Received: from smtp.mgd.nokia.com ([65.54.30.59]) by mgw-da02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r8HMDtIn005498 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 18 Sep 2013 01:13:57 +0300 Received: from 008-AM1MPN1-006.mgdnok.nokia.com ([169.254.6.139]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi id 14.03.0136.001; Tue, 17 Sep 2013 22:13:55 +0000 From: To: , Thread-Topic: [paws] Encoding of spectrum profile Thread-Index: AQHOoeQFDw04TflTEUWcOZ+GLdKNBJmsqkoAgAAgq4CAAWO1gIAIKfUAgAIaG4CAAI/gAIAAGB6AgArWNgCABEM7AIAAeDkAgACTJgCAAHfggIAABhyAgAAJg4CAANTVUA== Date: Tue, 17 Sep 2013 22:13:53 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E47605331D88@008-AM1MPN1-006.mgdnok.nokia.com> References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DE9D633@wds-exc1.okna.nominet.org.uk> In-Reply-To: <53F00E5CD8B2E34C81C0C89EB0B4FE732DE9D633@wds-exc1.okna.nominet.org.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [69.181.65.212] Content-Type: multipart/alternative; boundary="_000_1ECAFF543A2FED4EA2BEB6CACE08E47605331D88008AM1MPN1006mg_" MIME-Version: 1.0 X-Nokia-AV: Clean Cc: paws@ietf.org Subject: Re: [paws] Encoding of spectrum profile X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 22:17:10 -0000 --_000_1ECAFF543A2FED4EA2BEB6CACE08E47605331D88008AM1MPN1006mg_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Ray, Could you elaborate on this point: =D8 What I don't want to see is that break _within_ the band getting confl= ated with breaks _between_ bands. This is the only issue which we do not have consensus and prevents the edit= or to submit an updated version of the draft. We do seem to have consensus that the current encoding in the draft has to = be updated, as with the current encoding it is not possible to specify the = power levels for unavailable ranges. What we do not have consensus on is on the options below: - Option 1: List of (startHz, startPower, stopHz, stopPower) - Option 2: Ordered list of (freqHz, power) So far we have few people speaking for either of the options. We need to agree on this asap and move forward, so please send a mail to th= e list and indicate whether you are ok with either option, or you feel stro= ngly for one or the other. - gabor From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext= Ray Bellis Sent: Tuesday, September 17, 2013 2:08 AM To: Paul Lambert Cc: paws@ietf.org Subject: Re: [paws] Encoding of spectrum profile On 17 Sep 2013, at 09:33, Paul Lambert > wrote: Yes - I feel it's important to retain a definition and identification of th= e channels. Can you elaborate on why you feel that's important? Why does a device "car= e" about the fact that the US TV band is split into four discrete bands - s= urely all that matters is the specific frequencies it's permitted to use? I may not be fully understanding your notion of a discontinuity within a ba= nd. I'd typically assume that system need well defined channels within a b= and that each could be also given masks that might vary depending on adjace= ncy considerations. In the OFCOM model channel 38 will not be available for _primary_ transmiss= ion, but AIUI a very small amount of adjacent channel leakage into it will = be permitted. The OFCOM / ETSI model doesn't need (or want) masks to be encoded within th= e messages for that channel, they're implicit in the device approval requi= rements. To further reduce the adjacent channel leakage the permitted power levels (= for certain WSD emission classes) for primary transmissions in the adjacent= channels are also reduced. That frequency is therefore simply omitted from the list of available chann= els. What I don't want to see is that break _within_ the band getting conf= lated with breaks _between_ bands. Ray --_000_1ECAFF543A2FED4EA2BEB6CACE08E47605331D88008AM1MPN1006mg_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Ray,

Could you elaborate on th= is point:

=D8  What I don't want to see is that break _with= in_ the band getting conflated with breaks _between_ bands.

 <= /p>

This is the only issue wh= ich we do not have consensus and prevents the editor to submit an updated v= ersion of the draft.

We do seem to have consen= sus that the current encoding in the draft has to be updated, as with the c= urrent encoding it is not possible to specify the power levels for unavailable ranges.

 <= /p>

What we do not have conse= nsus on is on the options below:

  - Option 1: List of (startHz, startPower, sto= pHz, stopPower)

  - Option 2: Ordered list of (freqHz, power)

 <= /p>

So far we have few people= speaking for either of the options.

We need to agree on this = asap and move forward, so please send a mail to the list and indicate wheth= er you are ok with either option, or you feel strongly for one or the other.

 <= /p>

- =          gabor<= /span>

 <= /p>

 <= /p>

From: paws-bou= nces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext Ray Bellis
Sent: Tuesday, September 17, 2013 2:08 AM
To: Paul Lambert
Cc: paws@ietf.org
Subject: Re: [paws] Encoding of spectrum profile

 

 

On 17 Sep 2013, at 09:33, Paul Lambert <paul@marvell.com>

 wrote:



Yes – I feel it's important to re= tain a definition and identification of the channels.

 

Can you elaborate on why you feel that's important? =  Why does a device "care" about the fact that the US TV band= is split into four discrete bands - surely all that matters is the specifi= c frequencies it's permitted to use?



I may not be fully understanding your n= otion of a discontinuity within a band.  I'd typically assume that sys= tem need well defined channels within a band that each could be also given masks that might vary depending on adjacency considerations.=  

 

In the OFCOM model channel 38 will not be available = for _primary_ transmission, but AIUI a very small amount of adjacent channe= l leakage into it will be permitted.

 

The OFCOM / ETSI model doesn't need (or want) masks = to be encoded within the messages for that channel,  they're impl= icit in the device approval requirements.

 

To further reduce the adjacent channel leakage the p= ermitted power levels (for certain WSD emission classes) for primary transm= issions in the adjacent channels are also reduced.

 

That frequency is therefore simply omitted from= the list of available channels.  What I don't want to see is that bre= ak _within_ the band getting conflated with breaks _between_ bands.

 

Ray

 

--_000_1ECAFF543A2FED4EA2BEB6CACE08E47605331D88008AM1MPN1006mg_-- From vchen@google.com Tue Sep 17 16:34:03 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB44F11E81D7 for ; Tue, 17 Sep 2013 16:34:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.675 X-Spam-Level: X-Spam-Status: No, score=-1.675 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rL3WxSNlhqYO for ; Tue, 17 Sep 2013 16:34:03 -0700 (PDT) Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 08ADC11E81DA for ; Tue, 17 Sep 2013 16:34:02 -0700 (PDT) Received: by mail-ob0-f176.google.com with SMTP id uy5so6544605obc.35 for ; Tue, 17 Sep 2013 16:34:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WJ//FNugmJrLFwUjtx/iHUkhbU9yB7imbojKDxBw7es=; b=QSY7ZT6ZE06FT0XUGRPyNPo/tGu3uDC6rnEo4YyshQli9K91NNXdtW9x6b/ZIUrJFl wUcu8mlkzyq3Wp8eeRqINgigsdND980mKsYnDnE33kh6djq+KxcnLYIuJ2lGhK6fqOUv hXRDFtGSlgyCRP6YxVIMA7TCKNQcnsiLAQQLXKR43LdPdHJPI7+spVmA1rq2ziBLIJUy vdmG41YRePDZDdQN9Rc/LbxJ7SfBYO3E/TurDMN6UtCpTcBOqcgkygeXDrZQf1wf6R3w NKLbsD8ATsf4NovpT8B4fuKMlRvbpY6bQsY5k95OkoyW/ouMj4oSaRnc7Y1hyJ7yNAmx 5/7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=WJ//FNugmJrLFwUjtx/iHUkhbU9yB7imbojKDxBw7es=; b=IW2XNNGhw2l3/niKFMD5MdyAibnVeK2lVVR9vEZShUE6lMTwIbZBgZQI2HVmwjhMDa VtxmWkTO/al81hgv0WU6xdyXwhporKvecOK/8nKKjFWkTfcD+voolTVb1BvxQvbf5r48 DcXv9QqGFCcqC9JBHDqtDbZBU9jBeQx/vvU7hsEysO00i3pvhGxgOEKjHIMNWHypyKMf H5XJFKwHATCJHUbqvRnhowFikC23tz4PSxSQ6xxLaDP2cn/g6dwIQqOqjKaUcmAAzzzd 6ziAB4kbRwAn45GUqIbKtaXrOVx+LkHpPVhsqN2up6GSZQ141RcnhdCXpUXbVP6/X830 4bJQ== X-Gm-Message-State: ALoCoQkYQnJHlCXb28UltcO/prT/SQ6tnC6LOIRfsOJJwMcahZFxnVwQGc/sFajfYoxrNUbIfotrblBT/ckyDE2+oPptNMXzioR6AyvVSf09nlJQxq7m/yx1WIUCl+YSN0DGS4tPW5nOgXQZXusqYDle65kqyGkU75NY+lUTfH/LlY+zTg0+FXoUUAZIZFIDPm4QH9jvJh5t MIME-Version: 1.0 X-Received: by 10.182.60.194 with SMTP id j2mr31544096obr.2.1379460842383; Tue, 17 Sep 2013 16:34:02 -0700 (PDT) Received: by 10.182.250.134 with HTTP; Tue, 17 Sep 2013 16:34:02 -0700 (PDT) In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E47605331D88@008-AM1MPN1-006.mgdnok.nokia.com> References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DE9D633@wds-exc1.okna.nominet.org.uk> <1ECAFF543A2FED4EA2BEB6CACE08E47605331D88@008-AM1MPN1-006.mgdnok.nokia.com> Date: Tue, 17 Sep 2013 16:34:02 -0700 Message-ID: From: Vincent Chen To: "gabor.bajko@nokia.com" Content-Type: multipart/alternative; boundary=089e01633baa7e548004e69cc116 Cc: "paws@ietf.org" Subject: Re: [paws] Encoding of spectrum profile X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 23:34:04 -0000 --089e01633baa7e548004e69cc116 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable With slight modification to Option 2. Repeating both below: - Option 1: List of (startHz, startPower, stopHz, stopPower) - Option 2: Ordered list of list of (freqHz, power) ^^^^^^^ I prefer Option 2, as described above. -vince On Tue, Sep 17, 2013 at 3:13 PM, wrote: > Ray,**** > > Could you elaborate on this point:**** > > **=D8 **What I don't want to see is that break _within_ the band getting > conflated with breaks _between_ bands.**** > > ** ** > > This is the only issue which we do not have consensus and prevents the > editor to submit an updated version of the draft.**** > > We do seem to have consensus that the current encoding in the draft has t= o > be updated, as with the current encoding it is not possible to specify th= e > power levels for unavailable ranges.**** > > ** ** > > What we do not have consensus on is on the options below:**** > > - Option 1: List of (startHz, startPower, stopHz, stopPower)**** > > - Option 2: Ordered list of (freqHz, power)**** > > ** ** > > So far we have few people speaking for either of the options. **** > > We need to agree on this asap and move forward, so please send a mail to > the list and indicate whether you are ok with either option, or you feel > strongly for one or the other.**** > > ** ** > > **- **gabor**** > > ** ** > > ** ** > > *From:* paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] *On Behalf > Of *ext Ray Bellis > *Sent:* Tuesday, September 17, 2013 2:08 AM > *To:* Paul Lambert > > *Cc:* paws@ietf.org > *Subject:* Re: [paws] Encoding of spectrum profile**** > > ** ** > > ** ** > > On 17 Sep 2013, at 09:33, Paul Lambert **** > > wrote:**** > > > > **** > > Yes =96 I feel it's important to retain a definition and identification o= f > the channels.**** > > ** ** > > Can you elaborate on why you feel that's important? Why does a device > "care" about the fact that the US TV band is split into four discrete ban= ds > - surely all that matters is the specific frequencies it's permitted to u= se? > **** > > > > **** > > I may not be fully understanding your notion of a discontinuity within a > band. I'd typically assume that system need well defined channels within= a > band that each could be also given masks that might vary depending on > adjacency considerations. **** > > ** ** > > In the OFCOM model channel 38 will not be available for _primary_ > transmission, but AIUI a very small amount of adjacent channel leakage in= to > it will be permitted. **** > > ** ** > > The OFCOM / ETSI model doesn't need (or want) masks to be encoded within > the messages for that channel, they're implicit in the device approval > requirements.**** > > ** ** > > To further reduce the adjacent channel leakage the permitted power levels > (for certain WSD emission classes) for primary transmissions in the > adjacent channels are also reduced.**** > > ** ** > > That frequency is therefore simply omitted from the list of available > channels. What I don't want to see is that break _within_ the band getti= ng > conflated with breaks _between_ bands.**** > > ** ** > > Ray**** > > ** ** > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > > --=20 -vince --089e01633baa7e548004e69cc116 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
With slight modification to Option 2. Repeating both below= :

- Option 1: List= of (startHz, startPower, stopHz, stopPower)
- Option 2: Ordered list of list of (freqHz, power= )
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 ^^^^^^^

I prefer Option 2, as descr= ibed above.

-vince


On Tue, Sep 17, 2013 at 3:13 PM, <Gabor.Bajko@nokia.com> wrote:

Ray,=

Could you elaborate on th= is point:

=D8=A0 What I don't want to see is that break _wit= hin_ the band getting conflated with breaks _between_ bands.

=A0<= /p>

This is the only issue wh= ich we do not have consensus and prevents the editor to submit an updated v= ersion of the draft.

We do seem to have consen= sus that the current encoding in the draft has to be updated, as with the c= urrent encoding it is not possible to specify the power levels for unavailable ranges.

=A0<= /p>

What we do not have conse= nsus on is on the options below:

=A0 - Option 1: List of (startHz, startPower, stopHz= , stopPower)

=A0 - Option 2: Ordered list of (freqHz, power)

=A0<= /p>

So far we have few = people speaking for either of the options.

We need to agree on this = asap and move forward, so please send a mail to the list and indicate wheth= er you are ok with either option, or you feel strongly for one or the other.

=A0<= /p>

-=A0=A0=A0=A0=A0=A0=A0=A0=A0 gabor<= /span>

=A0<= /p>

=A0<= /p>

From: paws-bounces@ietf.org [mailto:paws-= bounces@ietf.org] On Behalf Of ext Ray Bellis
Sent: Tuesday, September 17, 2013 2:08 AM
To: Paul Lambert


Cc: paws@ietf.org=
Subject: Re: [paws] Encoding of spectrum profile
=

=A0

=A0

On 17 Sep 2013, at 09:33, Paul Lambert <paul@marvell.com><= /u>

=A0wrote:



Yes =96 I feel it's important to re= tain a definition and identification of the channels.<= /p>

=A0

Can you elaborate on why you feel that's importa= nt? =A0Why does a device "care" about the fact that the US TV ban= d is split into four discrete bands - surely all that matters is the specif= ic frequencies it's permitted to use?



I may not be fully understanding your n= otion of a discontinuity within a band. =A0I'd typically assume that sy= stem need well defined channels within a band that each could be also given masks that might vary depending on adjacency considerations.= =A0

=A0

In the OFCOM model channel 38 will not be available = for _primary_ transmission, but AIUI a very small amount of adjacent channe= l leakage into it will be permitted.

=A0

The OFCOM / ETSI model doesn't need (or want) ma= sks to be encoded within the messages for that channel,=A0=A0they're im= plicit in the device approval requirements.

=A0

To further reduce the adjacent channel leakage the p= ermitted power levels (for certain WSD emission classes) for primary transm= issions in the adjacent channels are also reduced.

=A0

That frequency is therefore simply=A0omitted from th= e list of available channels. =A0What I don't want to see is that break= _within_ the band getting conflated with breaks _between_ bands.=

=A0

Ray

=A0


_______________________________________________
paws mailing list
paws@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/paws




--
-vince
--089e01633baa7e548004e69cc116-- From mrhead@google.com Tue Sep 17 16:38:47 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7026D21F9C8E for ; Tue, 17 Sep 2013 16:38:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.093 X-Spam-Level: X-Spam-Status: No, score=-1.093 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yKjtfhXQ8ZXJ for ; Tue, 17 Sep 2013 16:38:46 -0700 (PDT) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 3EC3511E8638 for ; Tue, 17 Sep 2013 16:38:42 -0700 (PDT) Received: by mail-ie0-f171.google.com with SMTP id at1so11266151iec.2 for ; Tue, 17 Sep 2013 16:38:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=cJYRT8gqkdOB/ktN/kZXP/MdDfa4dnY+1DGJpiHFKvE=; b=adrWiCUMF4fy1VY6pjZ+ye1JxoqYVDD713u711uMobWZTL33kFnwM+H2D9RQG5DDm9 lT1PSrt/MN+nrXIqXMGvvDydVyI3XBkNHPmZB/Bduig+GQzAkkq3h1NAexKD4SRB+kY0 Zxf74sc4AIsw+zig1CKkYGaIXuHEZxxRlzE9pMla/tbTheo+Rb1hhJZ148OlgnYmEHpX rhCJlB1aonX+PuHvW01MwsRLtPAPB/cz5UvWZNkFZMavhoImj4i1BkxBpNINbnBla7VQ 9QXecOecbW+kx+iBNEUlGX5fw0bQ0rWj8iJpN/OB9nHW1+Q3OmD/rMbmk9t3IEgzTguM /cyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=cJYRT8gqkdOB/ktN/kZXP/MdDfa4dnY+1DGJpiHFKvE=; b=NuJ5Ma6JefcTsXDFk9dGzgF6arZJ1AZeMH9yMS23qD0DyxdIM7pBndfBsaS4yfSuaC nddisjq3tC5xP2Bcny/+CZ64VSn+GxyBYYuBcxvKBiWlCU5nIUE8aM0DxEO4QsD2LyvH L12atM/RRbh7i9rSoNREFeqdtxrx5ftu+m8JBpEOoAWRTeSR2JLOi9pF1X0nT/o4eLA6 /XxvsjSjye5j1Kc3V3U0aLzkQeRadPhxb3ZFFPMS8euIxVufWmYP4jQ4dNaf/V/cur7K xcLJT0gM5xWlaaKvFW1PQ5P+27NtxouZxZZ071zYUV+1DhjUCbxDNjmMuK4mzQDMLMCw ehVw== X-Gm-Message-State: ALoCoQmxeIwZgp/hkYlGKVSWpdn8208wNltmARy6C/4ONrtSlGPNOzFyjSMLcMTs3nhnyq8CP0cYoOdmbYBSsb5DShE0KYHGgxJ4AQg0uJy/pgrRTnvAHBX3v51QTXTrE4YLfUCewfq1bvs8WHR8TrXz23U8cMKVIpDPet+XmvYzeCiRG165UiSE7dVjWUq0JWujhIj+LGpp MIME-Version: 1.0 X-Received: by 10.50.120.104 with SMTP id lb8mr2168964igb.22.1379461121485; Tue, 17 Sep 2013 16:38:41 -0700 (PDT) Received: by 10.64.107.104 with HTTP; Tue, 17 Sep 2013 16:38:41 -0700 (PDT) In-Reply-To: References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DE9D633@wds-exc1.okna.nominet.org.uk> <1ECAFF543A2FED4EA2BEB6CACE08E47605331D88@008-AM1MPN1-006.mgdnok.nokia.com> Date: Tue, 17 Sep 2013 16:38:41 -0700 Message-ID: From: Michael Head To: Vincent Chen Content-Type: multipart/alternative; boundary=047d7bd76bb220cc7a04e69cd251 Cc: "paws@ietf.org" Subject: Re: [paws] Encoding of spectrum profile X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 23:38:47 -0000 --047d7bd76bb220cc7a04e69cd251 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Option 2 makes sense to me because it conceptually organizes the spectrum into a profile and clearly groups the response into banded segments. On Tue, Sep 17, 2013 at 4:34 PM, Vincent Chen wrote: > With slight modification to Option 2. Repeating both below: > > - Option 1: List of (startHz, startPower, stopHz, stopPower) > - Option 2: Ordered list of list of (freqHz, power) > ^^^^^^^ > > I prefer Option 2, as described above. > > -vince > > > On Tue, Sep 17, 2013 at 3:13 PM, wrote: > >> Ray,**** >> >> Could you elaborate on this point:**** >> >> **=D8 **What I don't want to see is that break _within_ the band gettin= g >> conflated with breaks _between_ bands.**** >> >> ** ** >> >> This is the only issue which we do not have consensus and prevents the >> editor to submit an updated version of the draft.**** >> >> We do seem to have consensus that the current encoding in the draft has >> to be updated, as with the current encoding it is not possible to specif= y >> the power levels for unavailable ranges.**** >> >> ** ** >> >> What we do not have consensus on is on the options below:**** >> >> - Option 1: List of (startHz, startPower, stopHz, stopPower)**** >> >> - Option 2: Ordered list of (freqHz, power)**** >> >> ** ** >> >> So far we have few people speaking for either of the options. **** >> >> We need to agree on this asap and move forward, so please send a mail to >> the list and indicate whether you are ok with either option, or you feel >> strongly for one or the other.**** >> >> ** ** >> >> **- **gabor**** >> >> ** ** >> >> ** ** >> >> *From:* paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] *On Behalf >> Of *ext Ray Bellis >> *Sent:* Tuesday, September 17, 2013 2:08 AM >> *To:* Paul Lambert >> >> *Cc:* paws@ietf.org >> *Subject:* Re: [paws] Encoding of spectrum profile**** >> >> ** ** >> >> ** ** >> >> On 17 Sep 2013, at 09:33, Paul Lambert **** >> >> wrote:**** >> >> >> >> **** >> >> Yes =96 I feel it's important to retain a definition and identification = of >> the channels.**** >> >> ** ** >> >> Can you elaborate on why you feel that's important? Why does a device >> "care" about the fact that the US TV band is split into four discrete ba= nds >> - surely all that matters is the specific frequencies it's permitted to = use? >> **** >> >> >> >> **** >> >> I may not be fully understanding your notion of a discontinuity within a >> band. I'd typically assume that system need well defined channels withi= n a >> band that each could be also given masks that might vary depending on >> adjacency considerations. **** >> >> ** ** >> >> In the OFCOM model channel 38 will not be available for _primary_ >> transmission, but AIUI a very small amount of adjacent channel leakage i= nto >> it will be permitted. **** >> >> ** ** >> >> The OFCOM / ETSI model doesn't need (or want) masks to be encoded within >> the messages for that channel, they're implicit in the device approval >> requirements.**** >> >> ** ** >> >> To further reduce the adjacent channel leakage the permitted power level= s >> (for certain WSD emission classes) for primary transmissions in the >> adjacent channels are also reduced.**** >> >> ** ** >> >> That frequency is therefore simply omitted from the list of available >> channels. What I don't want to see is that break _within_ the band gett= ing >> conflated with breaks _between_ bands.**** >> >> ** ** >> >> Ray**** >> >> ** ** >> >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws >> >> > > > -- > -vince > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > > --=20 ---------------------------------- Michael R Head http://www.cs.binghamton.edu/~mike +1-201-BLISTER --047d7bd76bb220cc7a04e69cd251 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Option 2 makes sense to me because it conceptually organiz= es the spectrum into a profile and clearly groups the response into banded = segments.


On Tue, Sep 17, 2013 at 4:34 PM, Vincent Chen <vchen@google.com> wrote:
With slight modification to= Option 2. Repeating both below:

- Option 1: List of (startHz, startPower, = stopHz, stopPower)
- Option 2: Ordered list o= f list of (freqHz, power)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 ^^^^^^^

I prefer Option 2, as descr= ibed above.

-vince


On Tue, Sep 17, 2013 at 3:13 PM, <Gabor.Bajko@nokia.com> wrote:

Ray,=

Could you elaborate on th= is point:

=D8=A0 What I don't want to see is that break _wit= hin_ the band getting conflated with breaks _between_ bands.

=A0<= /p>

This is the only issue wh= ich we do not have consensus and prevents the editor to submit an updated v= ersion of the draft.

We do seem to have consen= sus that the current encoding in the draft has to be updated, as with the c= urrent encoding it is not possible to specify the power levels for unavailable ranges.

=A0<= /p>

What we do not have conse= nsus on is on the options below:

=A0 - Option 1: List of (startHz, startPower, stopHz= , stopPower)

=A0 - Option 2: Ordered list of (freqHz, power)

=A0<= /p>

So far we have few = people speaking for either of the options.

We need to agree on this = asap and move forward, so please send a mail to the list and indicate wheth= er you are ok with either option, or you feel strongly for one or the other.

=A0<= /p>

-=A0=A0=A0=A0=A0=A0=A0=A0=A0 gabor<= /span>

=A0<= /p>

=A0<= /p>

From: paws-bounces@ietf.org [mailto:paws-= bounces@ietf.org] On Behalf Of ext Ray Bellis
Sent: Tuesday, September 17, 2013 2:08 AM
To: Paul Lambert


Cc: paws@ietf.org=
Subject: Re: [paws] Encoding of spectrum profile
=

=A0

=A0

On 17 Sep 2013, at 09:33, Paul Lambert <paul@marvell.com><= /u>

=A0wrote:



Yes =96 I feel it's important to re= tain a definition and identification of the channels.<= /p>

=A0

Can you elaborate on why you feel that's importa= nt? =A0Why does a device "care" about the fact that the US TV ban= d is split into four discrete bands - surely all that matters is the specif= ic frequencies it's permitted to use?



I may not be fully understanding your n= otion of a discontinuity within a band. =A0I'd typically assume that sy= stem need well defined channels within a band that each could be also given masks that might vary depending on adjacency considerations.= =A0

=A0

In the OFCOM model channel 38 will not be available = for _primary_ transmission, but AIUI a very small amount of adjacent channe= l leakage into it will be permitted.

=A0

The OFCOM / ETSI model doesn't need (or want) ma= sks to be encoded within the messages for that channel,=A0=A0they're im= plicit in the device approval requirements.

=A0

To further reduce the adjacent channel leakage the p= ermitted power levels (for certain WSD emission classes) for primary transm= issions in the adjacent channels are also reduced.

=A0

That frequency is therefore simply=A0omitted from th= e list of available channels. =A0What I don't want to see is that break= _within_ the band getting conflated with breaks _between_ bands.=

=A0

Ray

=A0


_________________________________________= ______
paws mailing list
paws@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/paws




--
-vince

_______________________________________________
paws mailing list
paws@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/paws




--
= ----------------------------------
Michael R Head <mrhead@google.com>
+1-201-BLISTER
--047d7bd76bb220cc7a04e69cd251-- From Ray.Bellis@nominet.org.uk Wed Sep 18 02:13:09 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4247211E821A for ; Wed, 18 Sep 2013 02:13:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.004 X-Spam-Level: X-Spam-Status: No, score=-10.004 tagged_above=-999 required=5 tests=[AWL=0.594, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hKpRw0nM-7+X for ; Wed, 18 Sep 2013 02:13:04 -0700 (PDT) Received: from mx2.nominet.org.uk (mx2.nominet.org.uk [213.248.242.49]) by ietfa.amsl.com (Postfix) with ESMTP id B0BBE11E8215 for ; Wed, 18 Sep 2013 02:13:03 -0700 (PDT) DomainKey-Signature: s=main2.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:X-IPAS-Result:Received:Received:From:To:CC: Subject:Thread-Topic:Thread-Index:Date:Message-ID: References:In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:x-originating-ip: Content-Type:MIME-Version; b=VsWeZYOgGKdAcUG4mtIHx3Fx2rE7G6jTs9wDuSKeamxZhUTcldI9HDZv YVwOksON8my08hO3Bj7aA9eTLtxpJQ6Cj/R9I7vUiSP27k3HoMoZAWWo+ OMQI/6GGzQ1i+iXaD9mTEY7Y9tUsw4TqaR2ZQTjFSrVKncU5fud/Qv4V0 NhooMnsjY7ltYZMA/pjB0/6U+2bEeNDoYApNl+jQt4Fjuyi33qTu1MC75 oIaMPHQKt3hwlbP3a90xqw7+WEvfm; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=@nominet.org.uk; q=dns/txt; s=main2.dkim.nominet.selector; t=1379495583; x=1411031583; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=IZTXC2BOzjdVSL9LecYBBGV+6tMiajoCvGHIRh8OBB4=; b=VIhiUrB9tSvNzMWyiGv1D7Z0lLxFG+BvvS6lwbDDG7tdKvPKlSyYDcY8 s0JN4VzAgYcMHIC2Ryml3rQ8pHidZ8HXwUlheNuUhV5bI8Sj1JSpSVztY 6+SVlyonKxW/HNUHor0LGLRUKkNk/OnAjaN7cARbXy7aNqQ2hnu9B7hVc +yhMH9KWv+tWVoKzIKWRlQNDWIHzhgRp26mBKIFBirxM4Pa1QHihSGtni ZnxbNxIYu/EUZpQebH/kqQnNjElat; X-IronPort-AV: E=Sophos;i="4.90,929,1371078000"; d="scan'208,217";a="3092944" X-IPAS-Result: Am0FADJuOVLV+MWR/2dsb2JhbABagkMjIYEKwSqBGBZtB4ImAQEEUyYQAgEIIh0HMhQRAgQOBQiHfAO6Eo4ugQgxB4MegQADiQCgb4MkgXE5 Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx2.nominet.org.uk with ESMTP; 18 Sep 2013 10:13:01 +0100 Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4%17]) with mapi id 14.02.0318.004; Wed, 18 Sep 2013 10:13:01 +0100 From: Ray Bellis To: "Gabor.Bajko@nokia.com" Thread-Topic: [paws] Encoding of spectrum profile Thread-Index: AQHOoeQCmU+qkDwvDUSLePEjGLDDY5msmYcAgAAgqoCAAWO2gIAIKfUAgAIaGoCAAI/hAIAAKOJGgArFcQCABEM7AIAAeDoAgACTJgCAAHfggIAABhyAgAAJgoCAANuUgIAAuCgA Date: Wed, 18 Sep 2013 09:12:59 +0000 Message-ID: <53F00E5CD8B2E34C81C0C89EB0B4FE732DEA1700@wds-exc1.okna.nominet.org.uk> References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DE9D633@wds-exc1.okna.nominet.org.uk> <1ECAFF543A2FED4EA2BEB6CACE08E47605331D88@008-AM1MPN1-006.mgdnok.nokia.com> In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E47605331D88@008-AM1MPN1-006.mgdnok.nokia.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.2.1] Content-Type: multipart/alternative; boundary="_000_53F00E5CD8B2E34C81C0C89EB0B4FE732DEA1700wdsexc1oknanomi_" MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] Encoding of spectrum profile X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 09:13:09 -0000 --_000_53F00E5CD8B2E34C81C0C89EB0B4FE732DEA1700wdsexc1oknanomi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On 17 Sep 2013, at 23:13, Gabor.Bajko@nokia.com wrote: Ray, Could you elaborate on this point: > What I don't want to see is that break _within_ the band getting conflat= ed with breaks _between_ bands. Certain people appear to want the entire UHF channel plan encoded in the PA= WS response, using very low PSD values to represent permitted leakage into = "unavailable channels". IMHO, this is a very US/FCC-centric model. In the ETSI model, each available channel is _explicitly_ listed, with a lo= w and high frequency. "Unavailable channels" are omitted, and there's no c= oncept of needing to describe the channel plan. Devices just do what they'= re told, and adjacent channel leakage into otherwise unusable channels is c= ontrolled by device approval regulations. Option #2 _could_ be used to represent the ETSI model, but doing so changes= the semantics from representing the channel plan to being a workaround to = get around the inability of option #2 to explicitly specify "unavailable ch= annels" without resorting to magic values. So far we have few people speaking for either of the options. We need to agree on this asap and move forward, so please send a mail to th= e list and indicate whether you are ok with either option, or you feel stro= ngly for one or the other. Strongly for #1, of course :) I would also be happy with a variant of #1 where the profile is still prese= nted as a list-of-lists to support representing a US-style non-contiguous c= hannel plan, but which still permits frequency ranges to be omitted within = each contiguous band). Ray --_000_53F00E5CD8B2E34C81C0C89EB0B4FE732DEA1700wdsexc1oknanomi_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
On 17 Sep 2013, at 23:13, Gab= or.Bajko@nokia.com wrote:

Ray,
Could you elaborate on this point:
=D8  What I don't want to see is that break _within_ the band getting conflated with= breaks _between_ bands.

Certain people appear to want the entire UHF channel plan encoded in the PA= WS response, using very low PSD values to represent permitted leakage into = "unavailable channels".

IMHO, this is a very US/FCC-centric model.

In the ETSI model, each available channel is _explicitly_ listed, with= a low and high frequency.  "Unavailable channels" are omitt= ed, and there's no concept of needing to describe the channel plan.  D= evices just do what they're told, and adjacent channel leakage into otherwise unusable channels is controlled by device approval = regulations.

Option #2 _could_ be used to represent the ETSI model, but doing so ch= anges the semantics from representing the channel plan to being a workaroun= d to get around the inability of option #2 to explicitly specify "unav= ailable channels" without resorting to magic values.

So far we have few people speaking for either of the opti= ons.
We need to agree on this asap and move forward, so please= send a mail to the list and indicate whether you are ok with either option= , or you feel strongly for one or the other.

Strongly for #1, of course :)

I would also be happy with a variant of #1 where the profile is still = presented as a list-of-lists to support representing a US-style non-contigu= ous channel plan, but which still permits frequency ranges to be omitted wi= thin each contiguous band).

Ray


--_000_53F00E5CD8B2E34C81C0C89EB0B4FE732DEA1700wdsexc1oknanomi_-- From tvfool@google.com Wed Sep 18 14:01:43 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E4F411E8131 for ; Wed, 18 Sep 2013 14:01:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.543 X-Spam-Level: X-Spam-Status: No, score=0.543 tagged_above=-999 required=5 tests=[AWL=-0.680, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gLkEsDcVtle2 for ; Wed, 18 Sep 2013 14:01:42 -0700 (PDT) Received: from mail-qe0-x22c.google.com (mail-qe0-x22c.google.com [IPv6:2607:f8b0:400d:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 3147111E810B for ; Wed, 18 Sep 2013 14:01:41 -0700 (PDT) Received: by mail-qe0-f44.google.com with SMTP id 3so5160221qeb.31 for ; Wed, 18 Sep 2013 14:01:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=Fo5NG7r4VQKTzJEgl7m2/p/YqlJctNLgnzMmm9skVPw=; b=c4qftfpioc+BB3W7/K7otqaJ1eLa2rQ+CekRmgC0JiHW26QkLIwJ7+eEWVgfU+SGmr vNq1PLZTpukiS/x2XbSduintx0biSU+gAcY0TgvugZRBI7/tiCgHj+rPePQCK3t79uoV 1/5VzRCtTrF6vq+gtjloNpbw/U7+VaV0B+YuKmumG7cQspaTLpp5hN61BUyCQ8CLjUG1 9uy3thyEcp+inhCXkJP7NVQVUuirLbYZ+5gI8EZHntFQqQ7NRHAxRrT5L6oHpkJWCr3i hkYAN8zfA3Mw75O+tCXogUtzZwkzYSmntuKwvTnvUDuDRaDrTPSySMFw3zDm9BX3ZcpY Vwng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc :content-type; bh=Fo5NG7r4VQKTzJEgl7m2/p/YqlJctNLgnzMmm9skVPw=; b=cjyE1Rv+O+FEN3Yo8YmqjBZzn3ppGLcDXjNsI1BtJ/XA4bOLnXr85ORrVRXF5o4G1t N3p369hiSC5sSWzdHKE+U8tkgUWipJRHjRhiM10mfUIRupV45fuVzE9cGY9y9AtvRXGs BEQf9hEzJES/nSc6GJFrgPvAoHch6IihhPMTTMSOcH2NS4t+X7jhz6AmScgCCvnJf+la J7kTbTJULdz0+C03mZBr7pYMFO4qVwH5ot3DSVVpvG9lojZISUB3E4f+uA5iqL735oB1 uOxDEfsyGpfxFJK4oyxFgyEdFqMlvR4AEDUku60XYPFFtycLYh5pus2t0O6Fgy9YlKrq 0t0w== X-Gm-Message-State: ALoCoQkE3gTcTDCY1YzRkRFWEKWEA+d5a1sHG//SW99AjfoMXITjvO+Wa9Ardx/sSYHWPeckxHoV8Vw11z0jA82hKMV4q+n+oO7/GDrwT8Ha2nQp+yka9gDu7z0ser+QexMoIQFL7GDohODoCmZUEGD1rgN3zpbiuRd7SG0M3MJBJUEzqnoRTHBv9tVep5GuEbEKlJKn3fRN MIME-Version: 1.0 X-Received: by 10.49.81.133 with SMTP id a5mr64771781qey.55.1379538095428; Wed, 18 Sep 2013 14:01:35 -0700 (PDT) Received: by 10.229.207.8 with HTTP; Wed, 18 Sep 2013 14:01:34 -0700 (PDT) Date: Wed, 18 Sep 2013 14:01:34 -0700 Message-ID: From: Andy Lee To: Ray Bellis Content-Type: multipart/related; boundary=047d7b5da29d21eca804e6aebe57 Cc: "paws@ietf.org" Subject: [paws] Spectrum encoding discussion X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 21:01:43 -0000 --047d7b5da29d21eca804e6aebe57 Content-Type: multipart/alternative; boundary=047d7b5da29d21eca404e6aebe56 --047d7b5da29d21eca404e6aebe56 Content-Type: text/plain; charset=ISO-8859-1 -- tl;dr Moving this to separate discussion thread -- Hi Ray, Certain people appear to want the entire UHF channel plan encoded in the > PAWS response, using very low PSD values to represent permitted leakage > into "unavailable channels". > IMHO, this is a very US/FCC-centric model. > In the ETSI model, each available channel is _explicitly_ listed, with a > low and high frequency. "Unavailable channels" are omitted, and there's no > concept of needing to describe the channel plan. Devices just do what > they're told, and adjacent channel leakage into otherwise unusable channels > is controlled by device approval regulations. I humbly suggest a few alternate viewpoints: a) AFAIK, in every regulatory domain, multiple device regulations are simultaneously in effect at all times. Just because a device is following TV WS rules, does not excuse it from complying with other rules like EMI leakage or electrical safety testing. Just because a set of frequencies is not explicitly mentioned in one section of the law does not mean that those frequencies are unregulated. Every piece of spectrum is controlled by at least one law. There is no such thing as completely unregulated spectrum. b) In the case of the ETSI model, the emission limits on channel 38 can be derived using the adjacent channel leakage ratios for each device class. From a technical standpoint, Ofcom must assume some kind of power limit (interference threshold) on channel 38 in order to compute the white space power limits on channels 37 and 39. The power limit on channel 38 is the same one that can (and should) be communicated to the device. Not having looked at Ofcom's data set yet, I think it's a little premature to say that they will be silent or explicitly omit data for channel 38. c) From a future-proofing perspective, I think it's important to communicate these "band edge" requirements. One of the great features of a spectrum database is the ability to modify the rules over time. Future changes to the white space rules might involve shifts in the frequency ranges, changes to power levels, or perhaps changes to the band edge roll off. The key is that the DB is responsible for protecting the primary spectrum users, and by communicating the "left-over" spectrum envelope to white space devices, you give them the chance to opportunistically use that spectrum. The way in which the white space spectrum is specified can determine how effectively a WSD can search for opportunities within that envelope. I've put together some crude hypothetical examples in the following illustrations: Case 1: Old profile has "square" channel edge restrictions. WSD needs to narrow its in-band emissions to avoid causing interference on the adjacent channel. [image: Inline image 1] Case 2: New rules define a more realistic band edge rolloff, but also lowers the emission limits on the left-most channel. WSD peak emission power remains the same, and its in-band emissions can be moved closer to the channel edge because the new rules allow it. [image: Inline image 2] Case 3: Consider what white space devices must do when they try to find optimal channels to transmit on. Specifying the channel edge emission masks actually gives the device more information to work with. The band edges can and should be factored into the search for the optimum spectral fit of a signal. A legacy device does not know how the out-of-band rules might change in the future, but with a fully defined profile, the device can still do the right thing at the band edges even when the rules change. [image: Inline image 3] Best regards, Andy Lee | Google Inc. | tvfool@google.com | 408-230-0522 --047d7b5da29d21eca404e6aebe56 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
-- tl;dr =A0Moving this to separate discussion thread= --


Hi Ray,

Certain people appear to want the entire UHF channel plan encoded in the=A0= PAWS=A0response, using very low PSD values to represent permit= ted leakage into "unavailable channels".
IMHO, this is a very US/FCC-centric model.
In the ETSI model, each avail= able channel is _explicitly_ listed, with a low and high frequency. =A0&quo= t;Unavailable channels" are omitted, and there's no concept of nee= ding to describe the channel plan. =A0Devices just do what they're told= , and adjacent channel leakage into otherwise unusable channels is controll= ed by device approval regulations.


I humbly suggest a few alternate v= iewpoints:

a) AFAIK, in every regulatory domain, m= ultiple device regulations are simultaneously in effect at all times. =A0Ju= st because a device is following TV WS rules, does not excuse it from compl= ying with other rules like EMI leakage or electrical safety testing.

Just because a set of frequencies is not explicitly men= tioned in one section of the law does not mean that those frequencies are u= nregulated. =A0Every piece of spectrum is controlled by at least one law. = =A0There is no such thing as completely unregulated spectrum.



b) In the case of the ETS= I model, the emission limits on channel 38 can be derived using the adjacen= t channel leakage ratios for each device class. =A0From a technical standpo= int, Ofcom must assume some kind of power limit (interference threshold) on= channel 38 in order to compute the white space power limits on channels 37= and 39. =A0The power limit on channel 38 is the same one that can (and sho= uld) be communicated to the device. =A0Not having looked at Ofcom's dat= a set yet, I think it's a little premature to say that they will be sil= ent or explicitly omit data for channel 38.



c) From a future-proofing= perspective, I think it's important to communicate these "band ed= ge" requirements. =A0One of the great features of a spectrum database = is the ability to modify the rules over time. =A0Future changes to the whit= e space rules might involve shifts in the frequency ranges, changes to powe= r levels, or perhaps changes to the band edge roll off.

The key is that the DB is responsible for protecting th= e primary spectrum users, and by communicating the "left-over" sp= ectrum envelope to white space devices, you give them the chance to opportu= nistically use that spectrum. =A0The way in which the white space spectrum = is specified can determine how effectively a WSD can search for opportuniti= es within that envelope.



I've put together som= e crude hypothetical examples in the following illustrations:
Case 1: Old profile has "square" channel edge restric= tions. =A0WSD needs to narrow its in-band emissions to avoid causing interf= erence on the adjacent channel.

3D"Inline



Case 2: Ne= w rules define a more realistic band edge rolloff, but also lowers the emis= sion limits on the left-most channel. =A0WSD peak emission power remains th= e same, and its in-band emissions can be moved closer to the channel edge b= ecause the new rules allow it.

3D"Inline



Case 3: Co= nsider what white space devices must do when they try to find optimal chann= els to transmit on. =A0Specifying the channel edge emission masks actually = gives the device more information to work with. =A0The band edges can and s= hould be factored into the search for the optimum spectral fit of a signal.= =A0A legacy device does not know how the out-of-band rules might change in= the future, but with a fully defined profile, the device can still do the = right thing at the band edges even when the rules change.

3D"Inline

Best regards,

=
--047d7b5da29d21eca404e6aebe56-- --047d7b5da29d21eca804e6aebe57 Content-Type: image/png; name="Unspecified channel.png" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: ii_141326efefab74bb iVBORw0KGgoAAAANSUhEUgAAAeAAAAGPCAYAAACEdgMaAAAAAXNSR0IArs4c6QAAEp5JREFUeNrt 3d9rlvX/wPHXvWUxWQTiQd4zoxQNc26eTGViiP+AiP2QBEEIpwdJ3aIHCwxhLp2GehTUgQzaaoY1 80CCwM+R0MlkRoXkYJruLOhkU4j7/hx8Ufz6cercfd+7fjwesKPm0vd9X9fzel33e/ddqFQqlQBS aWJioqo/b9GiRRYV6nS8NVhSAKg/AQYAAQYAAQYABBgABBgAEGAAEGAAQIABIHmeswSQPcVi8bH/ /fbt2xYJBBioNoGF5HMLGjJuZGQkNm/eHC0tLU81HQMCDFRBqVSK7u7u8LkrIMBAHY2Pj0dnZ2dE RExOTkZzc7NFAQEGaq29vT2Gh4cjIuLChQvR0dFhUUCAgVrr6+uLwcHBaGpqioGBgThy5IhFgQQo VLwwBKlV7Q8IX7RokUWFOh1vJmDIuOHh4VizZk0Ui8X7X4AJGKjxFXlbW1ucPHkyNm3aZAIGEzBQ L3fu3Il169ZZCEgYAYaM6+rqisHBwSiXyxYDEsQtaEixp7kl9qjXfKd7q0q3oGF2x9tMeC9oyDjv Cw3J5BY0ZJxd0JBMbkFDitkFDck63kzAwH12QUMyCTBknF3QkExuQUOK2QUNyTreZsIuaMg4u6Ah mdyChoy7dOlSbNy4MRYvXmwXNAgwUC8HDx6Mo0ePRrlcjjNnzsT+/fstCggwUGs3b96MtWvXRmNj Y2zYsCH6+/stCggwUJcDvaEhisViXL58OaampiwI1MjIyEhs3rw5WlpaIiIe+5KPAEPG3duEtXfv 3tizZ090dXVZFKiRUqkU3d3d8TS/YGQXNOTEzp07Y+fOnRYCamh8fDw6OzsjImJycjKam5tNwJBX 3gsa6qe9vT2Gh4cjIuLChQvR0dEx7fd6Iw5IMe8FDck63sbGxqJUKsXo6Gi0trbG6dOnY8mSJQIM eTwhrFixIq5cuRJNTU0CDDU+3mbCLWjIOO8FDfXz4Es9xWIxli1bFlu2bImrV6+agCEPV+RPep3X e0FDbSbgnp6eaGlpiXfeeSeGhobi+vXr0dLSEmfPno2ff/5ZgCFPJ4SZEGCY3fG2dOnSuHr1asyf Pz+mpqZi1apV8fvvv8frr78ef/311//7XregAaBKXnnllfjuu+9iamoqzp49G4sXL47nn3/+kS8B CTBk3MO3o/0aEtTOqVOnYmBgIN58880YGBiI06dPR8SjX/bxRhyQcfPmzYu7d+/GCy+8EHfv3o3G xkaLAjXS1tYWFy9efKrvFWDIuNbW1ujv74/3338/vv7662htbbUoUEXPuulRgCHjjh8/Hh999FH0 9vbGG2+8ESdOnLAoUEUPBranpydefvnl2L59ewwNDcWtW7em/XN2QUOK2QUNyTreHrUL+vr164/8 XpuwAKBKlixZEkNDQ/d3QU/3NpQCDABVdOrUqfjmm2/u74I+derUtN/rFjSkmFvQkN7jzSYsyKBn 3ZUJzM7IyEjs378//vjjj7h161YUi0W7oCFPnnVXJjA7pVIpPvnkk9ixY8cTv9ctaEixau/KdAsa Zn+8/fbbb/Haa6/Fn3/+Ge3t7XHt2rVHfq9NWJBxM9mVCcxOe3t7DA8PR0TEhQsXoqOjwwQMeb0i Hx0djQMHDsS1a9di+fLlcezYsVi9erUJGGpwvI2NjUWpVIrR0dFobW2N06dPT3vRK8CQ8RPCTAgw 1O94cwsaMm5kZCQ2b94cLS0tEeHTkCApBBgyrlQqRXd3d7jZBQIM1NH4+Hh0dnZGRMTk5GQ0Nzdb FEgAvwcMGTeTXZnAzPk4QuCR+vr6olQqRVNTUwwMDMTp06ctClSRjyOEHLILGpJ1vPk4QgCYAzN5 4xsTMGTwivzBN4B/1OtT070mZQKG2U3AM3njG68BQw749COoj9WrV8fFixef6nvdgoYMWrBgQYyO jloIqLPh4eFYs2ZNFIvF+1/TcQsaUmy6W2Lnz5+Pnp6euHXrVpTL5aeeiN2Chpkfbw9qa2uLkydP xqZNm574vQIMGT8hPO4DwQUYqnu8rVixIq5cuRJNTU1P/F63oCHjvP4L9dPV1RWDg4OPvPNkAoYc XJHbBQ1zMwHP5HgTYMj4CWEmBBjqd7y5BQ0AVXLp0qXYuHFjLF68+Im7oAUYMu7hE4DPA4baOXjw YBw9ejTK5XKcOXMm9u/fL8CQV/PmzYu7d+9GRMTdu3ejsbHRokCN3Lx5M9auXRuNjY2xYcOG6O/v F2DIq9bW1ujv74/Jycno7++P1tZWiwI11NDQEMViMS5fvhxTU1MCDHl1/PjxOHfuXKxatSq+//77 OHHihEWBGrm343nv3r2xZ8+e6OrqmvZ77YKGFLMLGtJ7vJmAIeNGRkZi8+bN0dLSEhE2YUFSCDBk XKlUiu7u7nCzC2rnxx9/jJUrV0ZnZ2f89NNPsX79+li5cmX88MMP0/4ZH0cIGTc+Ph6dnZ0RETE5 ORnNzc0WBaqsp6cnvvjii4iI2LFjR3z77bcREfHhhx/Gli1bBBjyqL29PYaHhyMi4sKFC9HR0WFR oMpu3rwZGzZsiIiIf//9N9atWxcREbdu3Zr2z7gFDRnX19cXg4OD0dTUFAMDA3HkyBGLAlVWqVSi oaEhGhr+L6uFQiEKhcJj/4xd0JBidkFDMo63x21unO7DGNyChowbHR2NAwcOxLVr12L58uVx7Nix WL16tYWBKnqWj/10Cxoybt++ffH222/Hr7/+Gu+9917s27fPokACCDBk3I0bN2L79u0xf/78ePfd d+PGjRsWBQQYqLVdu3bF0NBQTE1NxdmzZ2PXrl0WBRLAJixIsafZhDWTzSE2YcHsjreZsAkLMu5Z NocAtecWNGTcvQn4+PHjsXTp0jh16pRFAQEG6mFqaiq++uqrOHfuXHz55ZcWBAQYqLUFCxbEuXPn YtmyZdHW1hZ///23RQEBBmrtgw8+iE8//dTuZ0gYu6AhxbwVJaT3eDMBQ8YNDw/HmjVrolgs3v8C TMBAja/I29ra4uTJk7Fp0yYTMJiAgXq5c+fO/c8mBZJDgCHjurq6YnBwMMrlssWABHELGlLsWd+K crp3x3ILGmZ3vM2Et6KEjPNWlJBMAgwZ9fDk++KLL8b69eujt7fXpAsJ4DVgyPDk++DXL7/8Eq++ +mp0d3dbHDABA/Xy0ksvxccff2xHNJiAAUCAgYz7559/4vPPPzcBQ0K4BQ0Z9fAmrObm5li3bl18 9tlnFgcEGKgVv34EyeYWNAAIMAAIMAAgwAAgwACAAAOAAAMAAgwAAgwACDAACDAACDAAIMAAIMAA gAADgAADAAIMAAIMAAgwAAgwAAgwACDAACDAAIAAA4AAAwACDAACDAAIMAAIMAAIMAAgwAAgwACA AANASj1nCaA+CoVCzX727du3LTCYgAEAAQaABHILGuZApVKpys+ZmJiwmGACBgAEGAAEGAAQYAAQ YAAQYABAgAFAgAEAAQYAAQYABBgABBgAEGAAEGDgEQqFQhQKhVi4cGH09fVZEBBgoB4qlUqUy+U4 f/589Pb2WhAQYKBexsbGYvfu3XH48GGLARn0nCV4doVCoaYTEPm2devWOHToUGzbts1iON7I4nO6 4pnnhEDdny9P8/g2NDREuVx+7PdMTExU9e+4aNEixxvOz09w+/btqvwct6AhoZ4UXyDd3IJO0BV0 La/YSOcVvMnM8YYAAymMDFC9Y6naL/kIMJiQABMwaQmI6QxgdmzCAgATMCSTiR8QYOYsIF4TBRDg 1CrEA2/GEKYqcLyRV14DBgABzs/VOOB4I99ydQvaa5geXzweYALO+dW416PA8YYAAwB1lttd0LX+ vc7Hvf7kajz9jy+ONzABA4AA88RJwNU4ON5AgB344HgDAXaSABxv1FWhUIhCoRALFy6Mvr4+AXYC ABxv1OV5U6lEuVyO8+fPR29vb13/394LOqEnBW9iACJMfYyNjcXu3bvj8OHDAgxAvszl0LF169Y4 dOhQbNu2rb7/5kqOfmHywQc4if/sWj4Bq/1xhElfv7w8rScmJqr68xYtWpTL483vjef7/NfQ0BDl crnux5sJOEGcBJhLxWLRIpBLTxPfWhBggJRPcIaR2T92c7HGdkEDkGtzdYEjwEBERNy+fTsqlUpN voD/5RY0QAInKr+KmH0mYABI+wRsEwIAzEGAgepfzLr4hGxyCxoAsjQB24QAACZgSC0XotOvy70v MAFTtROt1/08D7BGmIBxggHHBghwvk40TjaIDggwTr7gWIAq8Rpwik48SXpduNonQq95p+85IL4g wJlRqVQee5K599/ECvElSWvonPRs3IJ2IOGxtSZgAuZJU/Bc/92cWOc+RqYNkUeAAYQxpRf6Hpu5 5xZ0DiZNEF8wAVPFk5NQgwtdTMDMwcnBhJCv58O9LyAjE7CTeLqC/PDjZRLO7oVX3o/NJG9IhKoE 2BKkawp+1ElJhMnbhWfeuBDJJregMxJmByhAyiZgk1N6I2wSJo/Tn+c4M71bkNTnjFvQIgwk9PhO c/Ty8P+eLbegM3iQuh2dj6t6z3fyfDxk4eNaTcAmYYHB8wIXbQJMniPMkx9TELbscAs64weEEzhZ mX6d8JnpcyHpzxkTsEnYFTSQ6ouztHrOgoswZGXiQXjT9JxxCzpHJywXMbjgRnwFGBEGeKrwTnfe SvudkUTfgnbbqTpr6HY0WbuQJN9T74PPiYfPcWl6vtiEJcKQipMungPTBTat5zK3oHM8RTjRAWma erM2NAiwCFsYUvWcJbvhzeprvQKMCJPa6QdTrwAjwgCmXgFGhE0J+XqOYuoVYEQYXGBg6hVgRNgU CKZeAUaEYZYnZhcepl4BRoQBTL0CjAiTz+chpl4BRoShThMSpl4BRoSdJAFTrwAjwuTreYepV4Bx MhRh6nTSxtQrwIiwCAOmXgFGhMnX8wxTrwDj5CjC1Gl6wtQrwCDCgKlXgBFhsrvWTuCmXgEGEcaF BKZeAUaEcaLD1CvAIMLU4MTuZG7qFWAQYXBxZOoVYESYfD53MPUKMIgwdZqwMPUKMIgwmHqFV4AR YfL1XMHUK8AgwtTppI+pV4BBhMHUiwAjwuTruYGpV4BBhKnT9IWpV4BBhMHUiwAjwmR3mhQAUy8C jAjjgsHUiwAjwpgaMfUKMIgJNQiDx97UiwCTsAibgsHUK8CQsBMK2bzowtQrwJCgE7IIu6DC1CvA IMJg6kWAEWGy9Rhj6hVgEGHqFA2qF18EGEQYahDeRz33Tb0CDCLMrB5TTL0IMCJMnQLCs0294ivA IMIwB1Ov+AowiLApsyqPIaZeBBgRJqcXBqZeBBhE2DRp6vUYCzCIMNWb6MTE1IsAI8Jg6kWAQYTz +TiZek29CDAiTJ0iY+o19SLAiDCYehFgEOF8PS6mXlMvAowIU6dpzzqYehFgRBhMvQgwiHC+HgdT LwgwIkydAmTqBQFGhEUYUy8CDCKc3ekz6/Ex9SLAIMIuAEy9CDCIsCnT1AsCDCbhOZkIsxgjUy8C DCKMqRcBBhEmu1Ey9SLAIMKpi5SpFwQYRBhTLwIMIpyvtTT1ggCDCNdpWjT1ggCDCGPqRYBBhPO1 dqZeEGAQ4ToFzNQLAgwijKkXAQYRrr1isZiYtTL1ggCDSbhOk6SpFwQYchNhETH1IsAgwjmcfpMY M1MvAgwijKkXBBhEuPbrYeoFAQYRrlPkTL0gwCDCOWLqRYBBhHMX4bkMnKkXAQYRzk2Ek/LvMvUi wIBJ2NQLAgwiPLf/XlMvCDCIcJ0CaOoFAQYRzhhTLwIMpCrCtf5EpFrHz9SLAAMm4Tr/vU29CDCQ qginPU6mXhBgMAk/5u9aixiaekGAQYRNvSDAIMLJ/zeYekGAQYSrrBa7qU29IMAgwnVm6oUnHCMV RwLUPUbVOOwe/JlJ/3mmXjABQ2Im4bz9+8UXTMAAYAIGAAEGAAQYAAQYABBgABBgAECAAUCAAQAB BgABBgABBgAEGAAEGAAQYAAQYABAgAFAgAEAAQYAAQYAAQYABBgAsu05SwAZ8Z//PPuffest6wcm YAAQYABAgAFAgAEAAYYcm80GrGr8eUCAAUCAAQABBgABBgABBgAEGAAEGAAQYKA2/C4wCDAgnCDA AIAAA4AAAwACDAACDAAIMAAIMJBMfqUJBBgABBgwsQICDAACDAAIMAAIMAAgwAAgwEAy2VkNAgwA AgwACDDknlvFIMAAgAADpmsQYABAgAFTMAgwkPA4ijAIMGASBgEGBBEQYBBf0QcBBsQfEGAQQBEG AQaEDxBgEF8XAyDAQLouCoQYZqVQqVQqlgFMvs/srbc8ViDAILxCDAIM5CG8IgwCDMIrxCDAQP7C K8IgwCC8QgwCDOT713ZEGP6H3wMGAAEGgHz4Lyk1aCrSQ9aCAAAAAElFTkSuQmCC --047d7b5da29d21eca804e6aebe57 Content-Type: image/png; name="Spectrum profile old.png" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: ii_141324520f039d9b iVBORw0KGgoAAAANSUhEUgAAAeAAAAHqCAYAAADcT53zAAAAAXNSR0IArs4c6QAAGrhJREFUeNrt 3X9sXXX9P/BXsYOt7Vz3I6COYUxG3EC3ZpkaMLgZ41yicYMthqDRIFHUhESNDhPiQvwLmKiLRiMb kBkTjflG4g+UHypbUKZGEowGYghg5vjhxgZ1XSnb3Ov7x+fTfuja09673tuenvN4JPvn9tLee57v c57nnFdv6cjMDEpj3759sW7dOhtCHshDHhV3jk1QMhazPJCHPBQwAFDSAu7o6IiOjo6WP7e29u2r /Fvs7++Pz3zmM7Fs2bI455xzRtbEeOtjxtdMDfKYrv1/JvJo5+tzPLN/tLSA+/v74+abb47Vq1dH T09P9PT0xKpVq2L79u3x8ssv21p2wJb48pe/HN///vfj4MGD4VcQrEeo7T47/EtYTzzxRGzcuDEO HDgw7hMvuuiiuO+++2LlypVjdvqIaOhA2sxzZ8sBr9XvZ19EVH2qsnTp0njuuefiV7/6VWzYsCFe 97rXlXbNzKY8ZmJbTffPrMP+MasugOUx9SvgwcHB2LRpUxw4cCBWr14dv/71r+PYsWMxMDAQ999/ f/T19cWBAwdi06ZNMTg4aKsxJc8//3xERGzcuHHC8gWofAHv2rUrnnzyyVi5cmX8/ve/j40bN0ZP T090d3fHhg0b4uGHH44VK1bEk08+Gbt37570mz7zzDOxefPm6OnpiSVLlsRnP/vZpor7lVdeie3b t8eKFSuiu7s7FixYEO9///vjl7/85Ziz746OjhgcHIzrr78+lixZEvPnz48rr7wy/vnPf475vj/8 4Q9j/fr10dvbG+edd14sX748tm3bFv39/aOed+rUqdi5c2esXbs2enp6oqurK9avXx+/+MUvxpz5 v/Z1jPfYK6+8EjfccENccMEF0dnZOepr411NrC+YgQ4MDMS1114bCxYsiDe+8Y2xc+fOiIg4evRo fOxjH4uFCxfGkiVL4qabbmrqaqSZbTjRezpx4kTceuut0dfXF11dXdHV1RV9fX2xY8eOOHny5Kj/ fvj1Dc9/z/zXiEazPNOLL74Yc+fOjc7OznjhhRfGfP348ePR29sbF1xwQZw8eTJefeCBhtZisx58 8MH40Ic+FL29vdHV1RWXX355/Pa3vx33ua1cj0X5n+1ra1ajuRWt+/93ww1Nrfsz318jx5Zmjz+v 1ch+MN6+d91118WCBQtiyZIl8ZWvfGX23CU0A56azMz3vOc9GRH54x//OIv86Ec/yojIdevWjXo8 IvJ/v01mZr744ot54YUXjjw+/O+qq64a89win/jEJ8b89+P9t+N97+F/F154YR45ciQzM0+fPp3X XHNN4fe89NJLs7+/PzMzT5w4kRs2bJj05zf69S1btoz5etF2mOg9XnnllWN+1s9+9rN85zvfOebx H/zgB9moRrfhRO9paGhoZA2N9++9731vnjhxovDrjWQ8rJksi1x99dUZEfmNb3xjzNd2796dEZFf +tKXMjPzAx/4QEOvs1njfb85c+bkX/7yl1HPa/V6bGbNTfbaJvq+Z2o2t1at+zNfXyPHlmaPP8Ma 3Q/O/O+3bt065rnf/va3czbYu3dvMoXjQGbmokWLMiLy3//+d+ETn3/++YyIXLx48YSLcNu2bRkR +eY3vzn37t2bx44dy4ceeigvuuiihnfW3t7ejIi8/fbb8+jRo/nqq6/mn/70p7zqqqvG/dlFP2vb tm2Zmblr166RQvnJT36Shw8fzsHBwXzkkUfyHe94R0ZE3njjjZmZ+fWvfz0jInt6enLnzp35r3/9 K4eGhvKRRx7JzZs3N3zwGf7a0qVL8957781jx45N6WDY19eXf/3rX7O/vz8/97nPZUTkggULxn38 3e9+d9NFMNk2nOg93XLLLRkR2dvbm3fddVceOnQoDx06lHfeeWe+/vWvz4jI2267bUrvf1gzWRb5 3e9+lxGRa9asGfO1tWvXZkTkE088kZmZPQ2uxWZt3bo1H3300RwaGsqnnnpqpGiuvvrqUc9r9Xps 5PFGX1szBdxsbq1a92e+vkaOLc0ef4ad7X6wZs2a/Nvf/pYvv/xyfvrTn86IyLVr186OAtahUy/g zs7OjIg8efJk4ROHr2A6OzsnXIQrVqzIiMif//zno553zz33NLyzXnzxxRkR+cEPfjBvvvnm3Ldv X/73v/8t3LmKftbKlSszM/Nd73pXRkQ+/PDDY77HU089lRGRF198cWZmrl69OiMi77jjjobLa6Kv /fSnP53SwXD4sf3794889txzz034+Pnnn990AU+2DSd6T6tWrcqIyLvvvrvwirKvr68lBdxMlo2s sccff3zksUcffTQjIi+//PKRx5Y2uBan6tChQxkRuWzZslGPt3o9nk2BFr22Zgq42dxate7PfH2N HFuaPf5MdT/44x//OPLYs88+mxGR3d3dCtgV8P954YUXGroCPu+88zIi8qWXXhr1vKNHjza8s/7m N7/J888/f9QtmeXLl+djjz027s8u+llz587NzMyurq5Jb3vOmTMnMzPnzZuXEZGHDh1qyQHv6NGj LSngoaGhUbfzJnq8o6Oj6QKebBtO9J7mzp2bEZGHDx8uPHjPmzevJQXcTJYTue222zIi8qabbhp5 bPjqY/fu3SOP3X777Q2txWacOnUqd+zYkX19fWPez7nnnjvqua1ej5M93sxra6aAm82tVev+zNfX yLGl2ePPVPeDovfoFnRNCriVM+BWFHBm5uDgYN577735+c9/Pt/0pjdlROQVV1xxVuUxfBBrZPbY 7gPea792+vTpUfOjRgqoFVc0Uy3gM01nATeT5WRXdeeee26+5S1vydOnT+d//vOf7OnpyZ6enlHj gr179za0FpvxhS98oeHX3ur1ONmaa+a1NbPems2tVet+vMcbybOZ48907AcKuMIF/K1vfSsjIi+5 5JIcGBgY86SBgYG85JJLMiJy586dbb8FfabhW0xdXV1ndft0eK735z//edKf1dfXlxGRu3btmvS5 HR0dGRF56tSppnaiJUuWZETkwYMHRx7bv3//jBZwM7egzzR8623Pnj1jvnbXXXe19BZ0M1lO5iMf +cjIbdHvfe97GRH5yU9+csJbbEVrsRnDd5z27NmTR44cyVOnTuWRI0fGff+tWo+NrrlmXlsz663Z 3NpZwM3mOdnxZzr2A7egK1zAAwMDuXz58pFfCLj//vtzYGAgjx8/ng8++GCuWbNmZEZz/PjxCRdL K34Ja+PGjfnAAw/kwMBAHjt2LL/73e+OuRp77c+e7BeIhhf/G97whty1a1c+88wzOTg4mENDQ/mP f/wj77jjjrzssstGbjlGRM6fPz+/853v5MGDB3NoaCj3798/5pdeFi9enBGR991335gZ0UTv9bLL LsuIyOuvvz77+/vz73//+8g2nqkCbuaXsM40/MsnCxcuzD179uThw4fz8OHDeffdd4/8Qkurfgmr mSwbGXUM5zBcdH/4wx9GPeedDa7FZixcuDAjIu+5556RX3R67W+Wv1ar1mOja66Z19bMems2t3YV cCPHlmaPP9OxHyjgChdwZubjjz+ey5YtK7w1tGzZslG/sFK0WFrxMaSi13DNNdeM+7zxPqpw5kdo brjhhoZuf504cSLf9773NXQLbryPDzSyE915551j/ruig9x0FXAj27Doew8NDeUVV1xRuM3Wr1+f r776aksKuJksJ3P69Olcvnz5yNhkxYoVU16LjRjv4zibN28e93u0aj02uuaaeW3Nvu9mcmtXATeS 59lm3s79wC3oihdwZuZLL72U27dvz7e//e3Z1dWVXV1d+ba3vS2/+tWvjpkRTrRYnn766fzwhz+c 3d3duWjRovzUpz6Vx48fb3hhPfTQQ7lly5ZcvHhxzps3L9/61rfm1772tRwcHBz3Zw8MDOR1112X CxcuzO7u7ty0aVM+/fTT417xbN26NZcuXZpz5szJefPm5aWXXppf/OIXR/2CxYkTJ3LHjh25atWq nDt3bnZ3d+f69evH3KZ99tlnc8uWLblo0aKR23+N7ESnT5/OG2+8MRcvXpzz58/Pj3/84zkwMDCj BdzINpzoew8NDeUtt9wyss3mzZuXq1atyltvvXXUQacVBdxMlpMZvmo58+pk2De/+c2m1mIjjhw5 kh/96Edz0aJF2dvbm9dee20eO3as8Hu0Yj02uuaafW3NrrdGc2tXATdybGn2+DMd+4ECrqaRvwU9 G1Xtb0tHTP/fVq3iNpzNeSAPedTsT1ECAAq45qeU/raqPJCHPBQwANAWs3oGXMkTyjBTkQfykIcr YABAAdfjlNJMRR7IQx4KGABQwLWwzkRFHshDHgoYAFDAtWCmIg/kIQ8FDAAo4HowU5EH8pCHAgYA FHA9mKnIA3nIQwEDAAq4HsxU5IE85KGAAQAFXA9mKvJAHvJQwACAAq4HMxV5IA95KGAAQAHXg5mK PJCHPBQwAKCA68FMRR7IQx4KGABQwPVgpiIP5CEPBQwAKOB6MFORB/KQhwIGABRwPZipyAN5yEMB AwAKuB7MVOSBPOShgAEABVwPZiryQB7yUMAAgAKuBzMVeSAPeShgAEAB14OZijyQhzwUMACggOvB TEUeyEMeChgAUMD1YKYiD+QhDwUMACjgejBTkQfykIcCBgAUcD2YqcgDechDAQMACrgezFTkgTzk oYABAAVcD2Yq8kAe8lDAAIACrgczFXkgD3koYABAAdeDmYo8kIc8FDAAoIDrwUxFHshDHgoYAFDA 9WCmIg/kIQ8FDAAo4HowU5EH8pCHAgYAFHA9mKnIA3nIQwEDAAq4HsxU5IE85KGAAQAFXA9mKvJA HvJQwACAAq4HMxV5IA95KGAAQAHXg5mKPJCHPBQwANAenTZBeXR0dNgIJZWZNkIZmDnKwxUwAKCA gXowc5RHhbgFXVItu+VpB/kfZ3GrzEgAcAUMcJYnUshDAQMAChiYhYxU5KGAsXPYFgAKGKgHM0d5 KGAAQAED9WCUIA8FDAAoYKAezBzloYABAAUM1IOZozwUMACggIF6MHOUhwKm9Nwask0ABQzgJEoe KGAAUMAADTNzlIcCBgAUMFAPZo7yUMAAgAIG6sHMUR4KGABQwEA9mDnKQwFjp7BtABQwUA9mjvJQ wACAAgbqwQhBHgoYAFDAQD2YOcpDAQMAChioBzNHeShgAEABA/Vg5igPBQwAKGD+j5mMbSQ75KGA AQAFDMx2Zo7yUMAAgAIG6sHMUR4KGABQwEA9mDnKQwEDAAoYqAczR3koYABAAeNs1LaqBzNHeShg AEABA/XgzoU8FDAAoICBejBzlIcCBgAUMFAPZo7yUMAAgAIG6sHMUR4KGABQwJjF2GYyQx4KGABQ wEB1mDnKQwEDAAoYqAczR3koYABAAQP1YOYoDwUMAChgoB7MHOWhgAEABQzUg5mjPBQwpeI2kG0H KGAAJ0zyQAEDgAIGmBIzR3koYABAAQP1YOYoDwUMAChgoB7MHOWhgAEABQzUg5mjPBQwdgDbEEAB A/Vg5igPBQwAKGCgHowL5KGAAQAFDNSDmaM8KqTTJgBmg46ODhuhpDLTRnAFDAAKGAAo4BY0MOu4 5TnzjARcAdebjwDYloACBgAUMAAoYABAAQOAAgYABQwAKGAAUMAAgAIGAAUMACjgWvCnE21TQAED AAoYABQwAKCAAaAUOm0CmJz/+TjgChgAFDAAcDbcgoYCmRn7ImKdTVEa8sAVMACggOt3GeAvNk3b trWtrX1QwACggKEe1pk4ygMUMAAoYKgFM0d5gAIGAAUM9WDmKA9QwACggKEezBzlAQoYABQwrgDq sY3NHMtFHihgAEABw3RcDSMPUMAAoIChuswc5QEKGAAUMNSDmaM8QAEDgAKGejBzlAcoYABQwFAP Zo7yAAWMg49tDShgqAczR3mAAgYABQz14Fa0PEABA4AChnowc5QHKGAAUMBQD2aO8gAFDAAKGOrB zFEeoIBrzq032xxQwKCEkQcoYABQwFApZo7yAAUMAAoY6sHMUR6ggAFAAUM9mDnKAxQwAChgqAcz R3kwqY6Ojkr8G+/9tOsxBeygwyQWPPaYjQC4AoZp19dnG5SJGTAV0mkTANCszIx9EbGuou+t3Y+5 AobJuAVdLsYx8qgQBQwAChhKxgy4XMyA5aGAAQAFDO1iBlwuZo7yUMAAgAKGdjEDLhczR3koYABA AVeZGcvMeuwxGdgfkIcCBgAFDHVgBlwuZo7yUMAAgAKGdvE54HIxc5SHAgYAFDC0ixlwuZg5ykMB AwAKGNrFDLhczBzloYABAAXs7JJ2GZ4By6IczBzloYABAAUM7WIGXC7uRMhDAQMAChjaxeeAy8XM UR4KGABQwNAuZsDlYuYoDwUMAChgaBcz4HIxc5SHAgYAFHAVma2Uw2tnwDKxXyAPBQwAChiqywy4 XMwc5aGAAQAFDO3ic8DlYuYoDwUMAChgaBcz4HIxc5SHAgYAFDC0ixlwuZg5ykMBAwAKGNrFDLhc zBzloYChptxyAxQwTAMzYCdAyEMBA4AChnowAy4XM0d5KGAAQAFDu5gBl4uZozwUMAAwFZ0dHR22 AhQxAy4XM0d5uAIGABQwtIsZcLmYOcqjQjoz01Yo0/F+587oc9uz/Acdt94AV8AVo3zlQTEnPvJQ wACAAq4SM0d5UMzMUR4KGABQwFVi5igPipk5ykMBAwAKuErMHOVBMTNHeShgAEABV4mZozwoZuYo DwVMW7idIytAATNDzBzlgRMfeShgAEAB14OZozwoZuYoDwUMACjgKjFzlAfFzBzloYABAAVcJWaO 8qCYmaM8FDAAoICrxMxRHhQzc5SHAgYAFHCVziTNHMtlojyc/U8/M0d5KGAAQAFXiZmjPCjmroM8 FDAAoICrxAxYHhQzc5SHAgYAFHCVmDnKg2JmjvJQwACAAq4SM0d5UMzMUR4KGABQwLPda+coZo7l MlkeZmAzt68gDwUMACjg2c7MUR4UM3OUhwIGABRwlZgBy4NiZo7yUMAAgAKuEjNHeVDMzFEeChgA UMBVYuYoD4qZOcpDAQMACrhKZ5BmjuXSSB6uAqaPmaM8FDAAoICrxMxRHhRzt0EeChgAUMBVYgYs D4qZOcpDAQMACrhKzBzlQTEzR3koYABAAVeJmaM8KGbmKA8FDAAo4Coxc5QHxcwc5aGAsXiRJaCA q8TMUR4UM3OUhwIGABRwlZg5yoNibvXLQwEDAAq4Sswc5UExM0d5KGAAQAFXiZmjPChm5igPBQwA KOAqMXOUB8XMHOWhgJkyt25kCihgSsTMUR44yZGHAgYAFHA9mDnKg2JmjvJQwACAAq4SM0d5UMzM UR4KGABQwFVi5igPipk5ykMBAwAKuErMHOVBMTNHeShgLFpkCyjgKjFzlAfFzBzloYABAAVcJWaO 8qCYW/zyUMAAgAKuEjNHeVDMzFEeChgAUMBVYuYoD4qZOcpDAQMACrhKzBzlQTEzR3koYABAAc8m k81MzBzL5WzyMBebuf0HeShgAEABzyZmjvKgmJmjPBQwAKCAq8QMWB4UM3OUhwIGABRwlZg5yoNi Zo7yUMAAgAKuEjNHeVDMzFEeChgAUMBVOls0cyyXs83DlUF7mDnKQwEDAAq4Sswc5UExdxbkoYAB AAVcJWbA8qCYmaM8FDAAoICrxMxRHhQzc5SHAgYAFHCVmDnKg2JmjvJQwACAAp4NGp2VmDmWy1Ty MB+buf0IeShgAEABzwZmjvKgmJmjPBQwAKCAq8QMWB4UM3OUhwIGABRwlc4SzRzLZap5uEJoLTNH eShgAEABV+XqN8LMsWxakYer4Jnbn5CHArY4AUABl5kZcDXzcDLWGmaO8lDAOOBiTQAKuEoHWjPg cpGHkxjkoYDBAQtQwLTrAGsGXC7yKBczR3koYFzdYJ0ACrhKzBzlgZMXeShgLESsF0AB1+NgauZY Lu3MQwk3z8xRHgoYAFDAVbn6jTBzLJt25+Eq2PaShwLG4gNAAdeXGXD98nAi1zgzR3koYBw0sZ4A BVylg6UZcLnIw4kK8lDA4GAGKGAHyXYxAy4XeZSLmaM8FLDyBWsMUMBVYuYoD5ygyEMBY6FhrQEK uB4HRDPHcpmpPJTw+Mwc5aGAAQAFXKUrETPHcpnJPFwF2ybyUMAWFwAo4GozA5aHk8BiZo7yUMCu fsFaBBRwlQ54ZsDlIg/7JvJQwOBAByhgB7p2MQMuF3mUi5mjPBSw8gXrE1DAVWLmKA+chMhDAVtI YJ0CCrgeBzUzx3IpYx51LmEzR3koYABAAVfpasLMUR6ugr1veShgiwcAFHA9mAHLwwlkMTNHeShg V79gHQMKuEoHLTNgeeCEQx4KGHAQBBRwPQ5WZsDyoJiZozwUsPIFaxtQwFVi5igPnGjIQwFbKGCN Awq4HgcmM0d5KOFiZo7yUMAAgAKu0hWBmaM8XAXX9wpfHgrY4gAABVwvZsDycPJZzMxRHgrYAQjs A4ACrtKBxwxYHjipkIcCBhwgAQVcjwOOGbA8KGbmKA8FrHzBfgEo4Coxc5QHTibkoYAtBLB/AO3R kZnpwFKiC66IMHWUR1vN4rndvogwdZRHVXQqXqjp1bBfoIEZNTtvQVe5fM0c5WE/cuItD1fAwgZX w0B7zI4ZcI2K1wxYHjOq5EVs5iiPKin/LWhXvWB/AwU8zQeCOh4MzIDlYd9zguCErRY6BQpMuC+a D0MNroCVr789LA9XORNxMlAu8qjAFbDiBVfD4Ap4mndq5TuaGbA8yl7EM7nPOl6U88SMWVbAggMH Xqix6f8csB134guu8Dlgecwy03hb2udOS3YeJo8pmb4ZsOKFal8Nmw9DU86Z1h2UBi65zBzlMcuL 2LFE5pTgClg44GoYGFd7ZsCK9+wvuMLMUR4V0uIiNnMs2fmWPKak9beglS/geADTWMA+09uiSy4z R3lUsIRbdWxwjHGCVSGdAgCm9WBtPgwtuAJWvq3nbw/Lw1VTMeVdLvKYgStgxQu4GoZpvAI2520/ M0d51K2ImzmmOP6U80SKNhewDQ04kEPLTP45YDvG9F5whc+dyqPmJrgt7XOnJTtvkseUdCpeoJRX w+bDVNw5yrdsl1xmjvKg8Djk2FT+jDjLK2AbE3A1DNNYwIq3PHzuVB4o4tlCHlPy/wElls5zjZBO ygAAAABJRU5ErkJggg== --047d7b5da29d21eca804e6aebe57 Content-Type: image/png; name="Spectrum profile new.png" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: ii_141324764ff6b6f8 iVBORw0KGgoAAAANSUhEUgAAAeAAAAHqCAYAAADcT53zAAAAAXNSR0IArs4c6QAAIABJREFUeNrt 3WtsZHd9N/Df+LIXrze295Zknc22UbKbQBW2UboIKM32qYqoWolLooqHUhBFaiokBK0aaItUVbwC 0ryIelMJF9FFfVGp8KQl9AbNrlBJGxUpFVWjNSUt7CXZNeu111577PX6/7wIM1pfjj1jj+2/z3w+ Eiq1B3vmfM+c7/mf3/FsJaWUgmycPn06HnroIRtCHshDHiXXYRNkxs4sD+QhDwUMACjg9nD6tG0Q EWNjY/Ebv/EbcejQoejo6IhKpRIREZVKpf7fa5b6mjzy0dJ81iGP9dx/1nXfdLwqTwHXdpTHHnus PXekrXDwaSOPPfZY/Pmf/3mcO3cu3KZgf4RSvh9rN2HV3pTd3d3xne98J44ePbrojRsRDoarOOA1 s91OR4SpSsTg4GBcuHAhvva1r8Vb3vKW6OzsbNk2buoEv2R5bMb7uJW/0/sjswWwPFqzAq65fv16 fPjDH7Zl2FQvv/xyRES89a1vXbZ8AUpTwL/wC78Q//AP/xBPP/10Qz/gS1/6Upw4cSL6+/tj+/bt cffdd8dHP/rRGBsbqz+mWq3G9u3bo7OzMyYmJupfP3bsWFQqlfjJn/zJ+tcmJiais7MzduzYEdVq tfD3Tk1Nxe///u/HvffeG7t27Yq+vr74+Z//+fjqV7+66Oy7UqnE5ORkPProo7Fv377YvXt3vOMd 74j//d//XdXriYiYnZ2NJ598Mh588MHo7e2Nnp6eOHHiRPzt3/7tojP/m5/HUl+bmpqKD33oQ3Hr rbfG//lR2RRdKlxuBjoxMRHvf//7o6+vL26//fZ48sknIyJiZGQk3vOe98TAwEDs27cvPv7xjze1 GmlmGy71mrq6uiIiYmZmJj71qU/FsWPHoqenJ3p6euLYsWPx+OOPx/Xr1+f972vPrzb/XfifVu2b S/nhD38YO3bsiK6urrj85S8v+v61a9eiv78/br311rh+/XrD+2Kz/umf/il+6Zd+Kfr7+6Onpyfe +MY3xje+8Y0lH9vK/bGRfa6Z59asZXO7aebYqv1+4etrJM9mjz83a+R9sNR77wMf+ED09fXFvn37 4nd+53fyuBppBrw26UciIkVEevHFF1NXV1f68R//8TQ1NZUWfr9mbm4uvfvd765/feF/Xvva16ax sbH649/0pjeliEjPPvtsSimlkZGR1NHRkSIidXR0pNHR0ZRSSqdOnUoRkX76p386Led973tf4e++ We1r73znOxc97o477kiXL19u+vXMzMykt7zlLSv+/ka///DDDy/6/lKvpejrta+94x3vWPS7nn76 6XT8+PFFX/+Lv/iL1KhGt+Fyr6laraaf+ZmfKdwmP/uzP5tmZmYKv99IxqvdN5fyrne9K0VE+uAH P7joe5/97GdTRKTf/u3fbmpfbNZSP6+7uzv9+7//+7zHtXp/bGafW+m5LfdzF2okt2eeeabl+/3C 59dIns0ef2oafR8s/N8/8sgjix77R3/0R2mznTp1KrGG9/hSO8qHP/zhFBHpE5/4ROGO9NRTT9UP wH/1V3+VhoeH0+TkZPrWt76VfuqnfipFRPrYxz5Wf/zv/u7vpohIn/70p1NKKT399NMpItJdd92V IiJ99atfTSml9Pjjj6eISL/3e7+37BPv7+9PEZGeeOKJNDIykqanp9O//du/pXe+851LvgEOHz6c Tp06lcbHx9Ozzz6b7rzzzhQR6aMf/WjTr+cP//APU0Sk3t7e9OSTT6azZ8+marWavvWtb6W3v/3t DR98at8bHBxMzzzzTBofH0+n1nAwPHbsWPqP//iPNDY2lj74wQ+miEh9fX1Lfv1Nb3pT00Ww0jYs ek0ppfTJT34yRUTq7+9Pn//859OlS5fSpUuX0uc+97l0yy23zNs3Vvv6V7tvLuWf//mfU0Skex54 YNH3HnzwwfrJajP7YrMeeeSR9O1vfztVq9X0ve99r14073rXu+Y9rtX7YyNfb/S5NVPAjeT2f2/K rVX7/cLn10iezR5/alb7PnjggQfSd77znTQ6Opp+/dd/PUVEevDBBze/gHVo6wt4ZGQk7d27N/X0 9KTvf//7S+5Ir3/961NEpG9+85uLfuj3vve9Vw9e99xT/9rXvva1+plcSin95m/+ZoqI9Jd/+Zfz DuK//Mu/nCIi/d3f/d2yT/yee+5JEZF+8Rd/Mf3BH/xBOn36dLpx40bhm+tv/uZv5n39K1/5SoqI dN999zX9el73uteliEif+cxnGi6v5b735S9/edEOvZoCeu655+pfu3DhwrJfP3DgQNMFvNI2LHpN KaV0//33p4hIX/jCFwpXlMeOHWtJATe7b660j/3Xf/1X/Wvf/va3U0SkN77xjU3vi2t16dKlFBHp 0KFD877e6v1xNQVa9NyaKeBGchu8KbdW7fcLn18jeTZ7/Fnr++Bf//Vf6187f/58ioi0a9cuBVzG Ak4ppT/5kz+ZV5gLv9/T07PiZcLu7u7648fGxlJnZ2c6fPhwSimlBx54IB08eDDNzc2l22+/Pb3+ 9a9PKaV01113pc7OznT16tVln/jXv/71dODAgXm/7+67704vvPDCkm+AK1euzPv6yMhIioi0Y8eO pl/Pzp07U0SkS5cuteSANzIysuiSzmoKqFqtzruct9zXK5VK0wW80jYsek0ppbRjx44UEWl4eLjw 4L1z586WFHCz+2aRT3/60yki0sc//vH612qrj89+9rNN74vNmJ2dTY8//ng6duzYotezbdu2eY9t 9f640tebeW7NFHAjuXV2drZ8v1/4/BrJs9njz1rfB0Wv0SXokhbw7Oxs+omf+IkUEekb3/jGou/X 3vTNzOoeeOCBFBFpaGgodXR0pPe9730ppZTe+973pu7u7vT973+/frmlEZOTk+mZZ55JH/nIR9LB gwdTRKQ3v/nNqyqPZl7Peh7wFhbw3NzcvPlRIwXUihXNWgt4oY0s4NXsm0Wrutr9EHNzc+nq1aup t7c39fb21i+tN7MvNqN2haiR597q/XGlfa6Z59bM/tZsbq3a75f6eiN5NnP82Yj3gQIuUQHXzvIi Ir3mNa9Z9P3aHOz5559v+JfVZsuPPvpoioj0pS99KaWU0smTJ+s3tURE+shHPtL0C6ldYurp6VnV 5dNmXs+xY8dSRKSnnnpqxcdWKpUUEWl2draxAv7R/923b1+KiHTu3Ln695577rlNLeBmLkEvVLv0 9sUvfnHR9z7/+c+39BL0avbNIid+NBL55je/mf7sz/4sRUT6tV/7tVXti83Ys2dPfXtdvnw5zc7O psuXLy/5+lu1Pza6zzXz3JrZ3xrJ7dQ67PcrPb9G8lzp+LMR7wOXoEtWwCml9La3vW3Js8/aznLb bbelp556Kv3P//xPmpycTNVqNZ05cyZ95jOfSW94wxvm/ay//uu/rq+YKpVKunjxYkoppVdeeSVV KpXU19e35PxwKW9961vTP/7jP6aJiYk0Pj6e/vRP/3TRauzm17XSDUTNvJ4nnngiRUTavXt3+uM/ /uN07ty5VK1W03PPPbfoppe9e/emiEh///d/v2hGtFwBv+ENb6ifrIyNjaX//M//rF9B2KwCbuYm rIVqN58MDAykL37xi2l4eDgNDw+nL3zhC/UbWlp1E9Zq9s0iT/zoJPTRRx+tF92//Mu/rGpfbMbA wECKiPSVr3ylfqPTzXeWz3uOLdofG93nmnluzexvjeT2mptyW68CbiTPZo8/G/E+UMAlLODvfve7 adu2bUt+/0Mf+lBTl/lql1giIr3uda9bcoXU7KW0hf9597vfveTjlvpThYV/QtPo65mZmUk/93M/ 19BrXurPBxq5BP25z31u0f+u6CC3UQXcyDYs+tnVajW9+c1vLtxmJ06cSNPT0y0p4NXsm0WeffbZ dPfdd6ft27eniEj33nvvmvfFRiz15zhvf/vbl/wZrdofG93nmnluzb7uZnJbrwJuJM/VZr6e7wOX oEtYwCml9NhjjxV+/+tf/3p65JFH0uDgYOru7k47d+5Mr33ta9Nv/dZvLXkTyr333psiIj322GPz vl67/Hzz5cyVDowPP/xw2rt3b9q5c2c6evRo+sQnPpEmJyeX3FEnJibSBz7wgTQwMJB27dqV3va2 t6WXXnpp1a9nZmYmPf744+n+++9PO3bsSLt27UonTpxYdJn2/Pnz6eGHH0579uypX/5rpIDn5ubS xz72sbR37960e/fu9N73vjdNTExsagE3sg2X+9nVajV98pOfrG+znTt3pvvvvz996lOfmnfQaUUB r2bfLDrA1FYtC1cnq90XG3H58uX0K7/yK2nPnj2pv78/vf/970/j4+OFP6MV+2Oj+1yzz63Z/W25 3G6++W29CriRPNeS+Xq9DxTw1lP/LOiy2mqfYZ3jZ6u28+eA+6xbeSCPDfsoSgBAAbfhKaXPVpUH 8pCHAgYA1kXpZ8Bb7oQyzFTkgTzkYQUMAORZwENDQzE0NNTyx7bvKWX5Zypzc3Nx8eLFeOmll+bt E0vtH5u+z5hxeX8gj3XStfDAeOXKlZiYmKj/w9Dd3d3R29sbAwMD0dFhwbywHCIijhw5YmM0YXh4 +NV/XB1AAUfMzMzEuXPnYnZ2dt4DpqenY3p6OsbGxuKOO+6Ibdu22Wrr6aHyT1SuXbsWERGDg4Ox a9eu+tezPJF5yIRLHshjHQs4pRQXLlyI2dnZ2L59e+zbty927twZERHVajWGh4djeno6Lly4EIcP H65/MAOsRu0k7+byBWjLAh4dHY2ZmZnYtm1bHDp0aN6l5p6enjh06FD84Ac/iJmZmRgbG4v+/v5l f+j169djeHg4Jicno1KpRG9vbxw4cKDhJ5VSipGRkRgfH4/r169HpVKJHTt2xMDAwLyDdu0S8D33 3BOXLl2KiYmJSClFT09P7N+/P7q7u+f93KtXr8bY2FhMT09HSim6urqit7c39u7dO+81p5RidHQ0 xsfHY2ZmJlJKsWPHjtizZ0/99988l7z5v9dWcTc/t+Hh4RgfH48bN27EkSNHCi9dDw0Nxdnnn494 z3sW/ey77767/ho7OjpiYGAgBgYG4saNGzE8PBwTExNRqVSir68v9u3b1/C2bmYbLveaUkpx5cqV +jaLiNi2bVvccsst0d/fH5VKZcn57lIaWQk3muWanT7tLD8n8pBH2Qp4YmIiIqLw4NXR0RF79+6N l19+OcbHx5ct4Bs3bsTZs2fnXcoeGxuLGzduNPykLl68GFevXp1XiJOTkzE5Obnkwfnll1+uv4ba 66lWq3H48OHo7OysP2Z8fHzRicKVK1fi2rVrceedd0ZHR0eklOL8+fMxOTk577FTU1Nx/vz5pi+T Lnxuq/XKK6/Uf87c3FwMDw9Hd3d3jIyMRLVarT9uZGSkXnxreZ5LbcOix6aU4ty5czE1NTXvcdPT 0zE8PBzXrl2LwcHBlu20jWYJkH0B11YsPT09hQ+sXZKuPbbIlStXYnZ2Nrq7u+O2226L7du3R7Va jVdeeaXhJ1U7uO/fvz9uueWW6OjoiOnp6RgZGVny8dPT03Ho0KF5v2t2djauXLkS+/bti7GxsRgf H4+urq7Yv39/9PT01H/mpUuXolqtxsjISOzbty9GR0djcnIyOjo6Yt++fdHb2xudnZ2Lfv9yK9mb VavVGBwcjJ07dzZWCsePF15VOHz4cHR3d8cPf/jDGB0djVdeeSW6u7sXfX1sbKzpAl5pGy73mkZG RmJqaio6OjriwIED9asEExMT9Ssho6Oji64OLHUFYCXNZNkSzu7zIg95lEhHbUVVW+kWqa2Cao9d qTwPHDhQP0D39PQ0dQm6q+vVe8NqB+5qtRo7duyIgwcPLvn4ot9Vey61O25vv/322L17d3R2dtYv a99+++3zHltbee/fvz/6+/ujq6ur/tii37+cWiGtdUV26623xvbt26OjoyP27NlTz2Kpr690krSa bbjca6qtRg8cOBC33HJLdHZ2RmdnZ/T19cX+/fvnbde1aiZLgOxXwB0dHXHjxo2Ym5tbdLmxppGS rq3Ubl4xL1xBN1oGL7/8cly7di2uXbsWly9fju7u7jh48GBs3769cHW+8P+vPZfp6emIiDh79uyK z7tWXr29vS3ZwM287oiIeP75iCVW1De/7toJStHXm7nc3+g2XO6xtW221E1Vvb29cfHixVWdFBSt 1BvNsiXMuPIiD3mUbQVc+9OihXPPm9W+txF/htTT0xN33XVXDA4OxsDAQHR1dcX169fj0qVL6/Y7 1+sTOYtOaJr9/UV3nm/GHemNvqbN4tNVgS2zAu7t7Y2pqam4fPnykpdL5+bm4vLlyxERsXv37mV/ YHd3d8zMzMTU1NS8FdHCG3RWUqlUYteuXbFr164YGBiIl156ad7NRjcr+l21O3hrc80777wzduzY sezv3bZtW0xPT8fExET09fWtW4HduHEjZmdn66vW2squaAa83lbaho1ss2vXri2aPdf+5rdVJ27N ZNkSzu7zIg95lG0F3NfXVy/Os2fPxuTkZMzNzdXvPj579mz9z5RWKqXapdtLly7F1NRUzM3NxeTk ZFOr19pdyHNzczE3N7fiTK/od9WeS+2u7QsXLsTY2Fhcv349UkqRUqr/adUPfvCDiIh6gQwPD8fo 6GjMzs5GSimq1WpcuHBhyZVgrWQaVSu1y5cvx9zcXMzMzMTFixc3dUdYaRsup3ZSNjw8HFevXo0b N27EjRs34urVq/Wf0+xNYUWayRIg+xVwR0dHDA4Oxrlz52J6ejrOnTu3+IFdXXHw4MEVL3kODAzE 1atX4/r16/PmdL29vQ3fHFOb/RaV+1KrooUzwa6urhgYGKgf/KvVaoyOjq5YdP39/XHt2rV6CS13 4tDT0xPj4+Nx/vz5+tca+TOlvr6+qFarMTY2Vr+pqLe399VVcMEMeL2ttA1XyvzatWsxNTW15N3u PT09K/7teKOaybIlzLjyIg95lK2AI169RPhjP/Zj9c+CvvnDFJr5LOjOzs44dOjQkh/E8d3vfreh J3XHHXfE6OhofUXW3d0du3fvrt/lu9Btt91W/zCKmz9E4uZZ5YEDB6K3tzfGxsZiamqqfqNSd3d3 7Nq1q75Cq1QqMTg4GKOjo3H16tWYmZmZ90EgN9u/f3+klOb9vEb09fXF9evXY2xsLFJK9e3z3//9 35u2IzSyDYtUKpW44447lvwgjt27d8fAwEBLZ9WNZgmQsy397wGX8R9D2Oh/X9M/KJFXHshDHu3D xwUBgALGv68pD+QhDwUMAKyTLT0DLuUJZZipyAN5yMMKGABQwO1xSmmmIg/kIQ8FDAAo4LbgU2Xk gTzkoYABAAXcHsxU5IE85KGAAQAF3B7MVOSBPOShgAEABdwezFTkgTzkoYABAAXcHsxU5IE85KGA AQAF3B7MVOSBPOShgAEABdwezFTkgTzkoYABAAXcHsxU5IE85KGAAQAF3B7MVOSBPOShgAEABdwe zFTkgTzkoYABAAXcHsxU5IE85KGAAQAF3B7MVOSBPOShgAEABdwezFTkgTzkoYABAAXcHsxU5IE8 5KGAAQAF3B7MVOSBPOShgAEABdwezFTkgTzkoYABAAXcHsxU5IE85KGAAQAF3B7MVOSBPOShgAEA BdwezFTkgTzkoYABAAXcHsxU5IE85KGAAQAF3B7MVOSBPOShgAEABdwezFTkgTzkoYABgPVRSSkl myEPQ0ND8XxEHF/hcUePHrWxWuTMmTPLfr+Wx5EjR2ysHBZcEWHqKA8rYABAAZfG88/bBvKgcMll 5iiP8uiyCfLU6CXPdOqUjdWkyokT9f9+9OjRKJrCDA0N2ViAFXDbOH7cNpAHRfzdqTwUMGxdrhoA CpjFVpg5VioV2yijPNhgZo7yUMAAgAIukyZmji6ltsayVxXMgPNi5igPBQwAKOAyMXPcEA1fPZBH Xswc5aGAAQAFXCZmjvKgmJmjPBQwAKCAy8TMcVMU3gktj7yYOcpDAQMACrhMzBw3TEN3QssjL2aO 8lDAbAYfQwmggFkvZo7yoJiZozwUMJvNx1C2nisMgAJuZ2aO8qCYmaM8FDCUgysJgALmVWaO8qCY maM8FDAAoIDLxMxxUy26EUseeTFzlIcCBgAUcJmYOW64lJI8tgozR3koYHAQAVDAZVIwc/QhEXnl wSYxc5SHAobycrIDKOB21MDM0YdH5JUHG8i4QB4KGMpl2RuxABRwGzBzlAfFzBzloYABAAVcJmaO 8qCYmaM8FDCUmzuhAQXcbswc5UExM0d5KGAoH3dCAwq4nZk5bo6iWZY8tkZOyEMBsx7MIwEUMOvN zDEbR48elUduzBzloYDZLD6GEkABsx7MHDf3BGfhjVjyyIuZozwUMACggMvEzFEeFDNzlIcChvbw q0eP2giAAm4LZo5QzMxRHgoYyssnYgEKuB2ZOTqbp5iZozwUMACggMtkwQzYx1BuvqNuxMqHqxTy UMAAgAIuk2VmwD6GcuO4EStTZo7yUMAAgAIuE38HDMXMHOWhgAEABVwm/g44S+5Gz4SZozwUMACg gMvEDHhz3TTTOnPmjO2RcT7IQwEDAAp4yzMDhmJmjvJQwGwEN/7IA1DAbBQzYChm5igPBcxG8zGU m+PkyZM2AqCA24IZsDwoZuYoDwUMACjgMjEDzjoPN2JtMjNHeShgAEABl4mZY3Z5+ESsjJg5ykMB Q4m5rAYo4DZkBiwPnBzJQwEDi7kRC1DAZfSjGbCDfF55kAkzR3koYGgvKSUbAVDApbbEzNHHUOaV B5vIzFEeChgAUMBlYuYoD4qZOcpDAUN7c5McoIDLxsxRHhQzc5SHAob2O7C4ExpQwGVm5igPipk5 ykMBAwAKuEzMHLdMHm7E2gRmjvJQwKyno0eP2ggACpgNZeaYdR5uxNpkZo7yKJEumyBvPoYSXjU0 NBRnI2Johce5gtQ6Z86cWfb7tTyOHDliY1kBl4AZsDxYdR7K1/tDAUObcCNWPpSvbbrVuASdGzNg ebBiHgsveS51ImRe35qTyqLLy0NDQ94fVsCwTgourzmw510YMlob204BO+gjD1bMQ/luzgmO94cC BhSD8kUB0yJmKlsuDzdibXweynd9NbwtHa8UMNA+lrozV/migFmzX3Xbf17ciJX9+0MW66/wKo8Z sAIGrHxBAdMyPoYyA2Zc2a7AlO86H38a2b7eHwoYUL5sfA4oYFg/Dc64HJw27qC/0j8QQH7vDxQw sMXL9+TJkzbMBnKlYX35LGhYxu4VDk5Wvhu78rXe2vxc5pWyGbAVMFDu8rUSQwFDu3nxRdsgp/I1 c9xwy578yEMBQ67lgZWv/RwFDKtx3322QU7la+aYF3msiZuwMnLUx1Bma2hoaMmvnzlzZl5uVget cebMmcJtzsZzw6EVMGw8M+BNKd9CZo55kYcCLuUZp4+hRPmSKavh1nAJGgocOXQoJg8diiNHjix/ suRGoQ3z8pEjccRmyIcZsBUwAOvLiaYCho31wgsRp0/bDrmQRTaOHj1qBqyAAUABQ7kcO2Yb5OSh h2yDTbToMrQZsAIGYOP9qs8uUMCwbl54wTbIiRkwChiAduRuaAVcOv6wPVNmwHkxA86Oj9BVwACg gFmbMydP2gi5MAPOixlwFlyGVsAAoIChlGozYCuvPJgBZ8k9LAoYABQwlIIZcF5ciciGfzpSAQOQ AZehFTC0lr8DzosZMAoYgHZ30mVoBQzrxgw4L2bAeVnw7wG7DK2Atxw7LYACBm5mBpwXM+C8HD/u bmgFXB7/z8dQAluYK3oKeOt68UXbICdmwHkxA87LghkwChgc/GED+ccZFHA53HefbZATM+C8mAHn 5fhx20ABA5ALc2AFvDWZAefFDDgvxgB5MQNWwABsLnNgBbz1mQHnxQw4L2bAeVlmBuwytAIGAAVM A2eJZsB5MQPOixlwXhbMgF2GVsAA5LjAYJ4umyAfZ06eDOvfzJgB58UMOC/+DtgKGDaMS6CwLJeh FfDWZQacFzNgJ0AUa+DvgF2GVsAAoIBZhr8DzosZcF7MgPNSMAN2GVoBA4ACpkFmwHkxA86LGXBe GvwsaHNgBQwACpgCZsB5MQPOixlwXpb5O2BzYAWcNZdlAMe79uWTsHLz4otWwTl54QWr4JycPm0V nJPnn484fjyGhoZKUcK1VfvNz3O9vmYFnFPwp07ZCFupBIAVnTlzxkZYhgLOjdVvXqx+82L1mxef Bb0mLkED0LQjR47EyxFxZIXHbcWbsZZ6zq3+mhVwjvwdcF78HXBeXP6XR4koYABQwJgBZ8YMOC9m wPJQwACAAi4TM+C8mAHnxcxRHgoYAFDAW1DhJ8KYAefFDDgvZo7yUMAAgALe4uZ9DKUZcF6KZsBm X5vDdpeHAgYAFHCZmAHnxQw4L2aO8lDAAIACLhMz4Lz4O+C8mDnKQwEDAAq4TMyA82IGnBczR3ko YABAAZeJGXBezIDzYuYoDwXMWhR+DCUACphNYgacl+VmwM7+N56ZozwUMK0y72MoAVDAbBIz4LyY AefFVQd5KGAAQAGXiRlwXvwdcF7MHOWhgAEABVwmZsB5MQPOi5mjPBQwAKCAy8QMOC9mwHkxc5SH AgYAFPAWsuLHUJoB52WlGbAZ2MayveWhgAEABbxFLfkxlGbAeTEDzouZozwUMACggMvEDDgv/g44 L2aO8lDAAIACLhMz4LyYAefFzFEeChgAUMBlYgacFzPgvJg5ykMBAwAKuEzMgPNiBpwXM0d5KGBW Y8WPoWRrchkOUMAlYAacFzNgJzvIQwGXy5IfQwmAAmaTmAHnxQw4L2aO8lDAAIACLhMz4LyYAefF zFEeChgAWIuuoaEhW2ETDJ09u/Q3zIDzYgacFzNHeVgBAwAKuEzMgPNiBpwXM0d5lEjXkSNHbIVN 2FGPHDq05MMmL18u/B6Z5+tyHGAFnJ/KiRONPdDMMS/yyIuTHHklPdi4AAAHW0lEQVQoYABAAW8x y34MpZljXuSRFzNHeShgAEABl4mZozwoZuYoDwUMACjgMjFzlAfFzBzloYABAAVcJmaO8qCYmaM8 FDBNcZlGzgAKOHNmjvLASY48FDCt0fDHUAKggNkkZo7yoJiZozwUMKu17MdQAqCA2SRmjvKgmJmj PBQwALAWXZVKxVbIiZmjPChm5igPK2AAQAGXiZmjPChm5iiPEulKKdkKdlIArIDbvHzNHPPSbB5O ttaXmaM8FDAAoIDLxMxRHhRzhUEeChgAUMBlYgYsD4qZOcpDAQMACrhMzBzlQTEzR3koYABAAZeJ maM8KGbmKA8FDAAo4FytZj5i5piX1eRhLpbXewp5KGAAQAHnysxRHhQzc5SHAgYAFHCZmAHLg2Jm jvJQwACAAi4TM0d5UMzMUR4KGABQwGVi5igPipk5ykMBAwAKuExnhmaOeVltHlYG68PMUR4KGABQ wGVi5igPirmyIA8FDAAo4DIxA5YHxcwc5aGAAQAFXCZmjvKgmJmjPBQwAKCAy8TMUR4UM3OUhwIG ABRwmZg5yoNiZo7yUMDYKbEfAAq4TMwc5UExM0d5KGAAQAGXiZmjPCjmsr48FDAAoIDLxMxRHhQz c5SHAgYAFHCZmDnKg2JmjvJQwACAAi4TM0d5UMzMUR4KmEIuyWB/ABTwFmTmKA+c0MhDAQMACrg9 mDnKg2JmjvJQwACAAi4TM0d5UMzMUR4KGABQwGVi5igPipk5ykMBAwAKuEzMHOVBMTNHeShg7IzY LwAFXCZmjvKgmJmjPBQwAKCAy8TMUR4UczlfHgoYAFDAZWLmKA+KmTnKQwEDAAq4TMwc5UExM0d5 KGAAQAGXiZmjPChm5igPBQwAKOActGoWYuaYl1blYVZmO8oDBQwACpiFzBzlQTEzR3koYABAAZeJ GbA8KGbmKA8FDAAo4DIxc5QHxcwc5aGAAQAFXCZmjvKgmJmjPBQwAKCAy3QWaOaYl1bmYbWwdmaO 8lDAAIACLhMzR3lQzFUEeShgAEABl4kZsDwoZuYoDwUMACjgMjFzlAfFzBzloYABAAVcJmaO8qCY maM8FDAAoIA3U6tnIGaOeWl1HmZmtp88UMAAoICpMXOUB8XMHOWhgAEABVwmZsDyoJiZozwUMACg gMt09mfmmJf1yMOqYfXMHOWhgAEABVyW1W+EmWNu1isPq2DbTR4K2Caw0wGggDEDbp88nMg1z8xR HgrY6hfsT4ACLtPB0gw4L/JwwoI8FDA4iAEK2EFyvZgB50UeeTFzlIcCVr5gHwMUcJmYOcoDJyry UMDYwbCvAQq4PQ6IZo552eg8lPDyzBzloYABAAVcppWImWNeNiMPq2DbRh4K2E4FAAq4PZgBy8NJ YDEzR3koYKtfsC8CCrhMBzwz4LzIw3sUeShgcIADFLAD3XoxA86LPPJi5igPBax8wf4JKOAyMXOU B05G5KGA7UBgPwUUcHsc1Mwc5aGEi5k5ykMBAwAKuEyrCTNHeVgFe/3yUMB2GgBQwO3BDFgeTiCL mTnKQwFb/YL9GFDAZTpomQHLAyce8lDAgIMfoIDb42BlBiwPipk5ykMBK1+wbwMKuEzMHOWBEw55 KGA7CNjHAQXcHgcmM0d5KOFiZo7yUMAAgAIu04rAzFEeVsFW+vJQwHYKAFDA7cEMWB5OPouZOcpD ATsAgfcAoIDLdOAxA5YHTi7koYABB0ZAAbfHAccMWB4UM3OUhwJWvuB9ASjgMjFzlAdOKuShgO0A 4P0BKOD2OLiYOcrD+6SYmaM8FDAA0J4FXNZLa2aO8vB+ab/3vTwUsNABQAG3JzNgeThxLWbmKA8F 7CACShhonwJuh4OHGbA8cAIhDwUMOGgC7V7A7XLQMAOWB8XMHOWhgJUvWAUD7bECbhdmjvLAiYM8 FLCAwcETWB+VlFJycMhowRURpo7y2HBbZJZ3OiJMHeVRFl2KF6i/79xUAxumI8uDQFsvucwc5eE9 6Bhhf7ECFiJYDQPrYnNnwIp38YIrzIDlkZmMitjMMbNzNXmsyeZdgla+sLVWxMAWL+DTp72hl11y mQHLI9MSzuF969jh5KxEugQFNP0+Nh+GLbICVr6N89nD8rDyKab48yKPjFfAiheshoENXAGb866e maM8tmIRb9T73XElz5MwMilggYCDMbCi1v0dsDdfaxZc4e9O5VEC63RZ2t+dZnbOJY81WfsMWPEC RccF82Eo1NGSNxktXHKZOcqjhEWc689DHltuBWyjA1bDsCbNzYAV7/ovuMLMUR4lt4YiNnPM7NxK HmvS+CVo5Qu0ckUMCriBN4s3zAYuucwc5dEmJbya44pjkZOpEumyYYFNP4CbD2MFrHw3nc8eloeV VDFFnRd5tHAFrHgBq2HYwBWwOW8+zBzloYiLj0eOU3meNLHKArYBAQd32KQVMPkwc5QHxathl6fz Ig8FDLRZEYMCpuXMHOVBob4nn7QRcjsxQgEDVsOggFk9M0d50FgeinjzmQGvyf8Hle86jLKd4KQA AAAASUVORK5CYII= --047d7b5da29d21eca804e6aebe57-- From Ray.Bellis@nominet.org.uk Thu Sep 19 03:15:23 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C88A221F999D for ; Thu, 19 Sep 2013 03:15:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.77 X-Spam-Level: X-Spam-Status: No, score=-8.77 tagged_above=-999 required=5 tests=[AWL=-0.772, BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nNGJR-HxsnIT for ; Thu, 19 Sep 2013 03:15:18 -0700 (PDT) Received: from mx2.nominet.org.uk (mx2.nominet.org.uk [213.248.242.49]) by ietfa.amsl.com (Postfix) with ESMTP id 698B021F995B for ; Thu, 19 Sep 2013 03:15:17 -0700 (PDT) DomainKey-Signature: s=main2.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:X-IPAS-Result:Received:Received:From:To:CC: Subject:Thread-Topic:Thread-Index:Date:Message-ID: References:In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:x-originating-ip: Content-Type:MIME-Version; b=QmIz/VYx/t2eoBwJs6FDym/HQtNQKyxmawztVouN5V4lIAzT7Y6nIZh/ Trzhbw59Eoj+m3i7jXNy7migs6W9ccM/2AMLgl5KJnZfphpkQg2LE1g9Z T81hallBmynZhWrVCOqrlo9Q2jLvvnAnlr76RrUB+OaJrYpH4RIW1FQyT tfwVHiGMgWfJBBKYxJcElnvC5wsk1Trod16T/MUIjCWy6Fm12Sie994BY NyC1DYf4XUk6EwMYirXsONBEYUEOx; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=@nominet.org.uk; q=dns/txt; s=main2.dkim.nominet.selector; t=1379585718; x=1411121718; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Uo/c5W8KXFQGe/HhjCtqBbIU5ERxnt+Na7q4M3Tpyn0=; b=DDIIPc9ZAmB5lTbMg4DW7j/hrTj0eOZHVzKdR72/xoKTJMqUQdUF24kg WrdpqAgGxYTB92SU7kXEYaKElOx0WvoVVHb9U0ajSiyjt9Iuyiy3MTUEs hrDN8sTSLYG3kLpih11y8rHvVgharOMta6DD/QTJszKKAoWM0ug7eWg9p QViyjQ3YDbFhJoZZ2cK138w51zLUpgQUyD29T0pDvVTurvhxl3QlJRgqm AmvOmhhN2rokicxdfMAWZ98fic/32; X-IronPort-AV: E=Sophos;i="4.90,936,1371078000"; d="scan'208,217";a="3114654" X-IPAS-Result: AhEFAJLNOlLV+MWR/2dsb2JhbABbgmYhgQrBLIEhFnSCJgEBBFMmEAIBCAQKFB0HMhQRAgQOBQiHfAO6EI82MQeDHoEAA4kAoHGDJIIq Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx2.nominet.org.uk with ESMTP; 19 Sep 2013 11:15:16 +0100 Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4%17]) with mapi id 14.02.0318.004; Thu, 19 Sep 2013 11:15:16 +0100 From: Ray Bellis To: Andy Lee Thread-Topic: Spectrum encoding discussion Thread-Index: AQHOtLJH/FWG06ATlUqxs+HiIH56lZnMyBoA Date: Thu, 19 Sep 2013 10:15:13 +0000 Message-ID: <53F00E5CD8B2E34C81C0C89EB0B4FE732DEA4362@wds-exc1.okna.nominet.org.uk> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.2.1] Content-Type: multipart/alternative; boundary="_000_53F00E5CD8B2E34C81C0C89EB0B4FE732DEA4362wdsexc1oknanomi_" MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] Spectrum encoding discussion X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 10:15:23 -0000 --_000_53F00E5CD8B2E34C81C0C89EB0B4FE732DEA4362wdsexc1oknanomi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On 18 Sep 2013, at 22:01, Andy Lee > wrote: lots of interesting stuff... :) Andy, your examples are good. If the FCC regime folks want to specify chan= nel edge emission masks that's OK with me, so long as it doesn't prohibit t= he ETSI approach at the same time. However on this particular point: Not having looked at Ofcom's data set yet, I think it's a little premature = to say that they will be silent or explicitly omit data for channel 38. I must disagree. As mentioned last week, OFCOM have specifically said in t= heir most recent consultation document in =A75.93: "Consequently, given the risk of harmful interference and the very stringen= t emission limits, we believe it would be prudent not to allow WSD operatio= n in channel 38". which we read as a very strong steer that they expect the WSD to specify (b= y omission, since that's the ETSI model) 0W (-Inf dBm) EIRP on channel 38. kind regards, Ray --_000_53F00E5CD8B2E34C81C0C89EB0B4FE732DEA4362wdsexc1oknanomi_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
On 18 Sep 2013, at 22:01, Andy Lee <tvfool@google.com> wrote:

lots of interesting stuff... :)

Andy, your examples are good.  If the FCC regime folks want to sp= ecify channel edge emission masks that's OK with me, so long as it doesn't = prohibit the ETSI approach at the same time.

However on this particular point:

Not having looked at Ofcom's data set yet, I think it's a little premature to = say that they will be silent or explicitly omit data for channel 38.=

I must disagree.  As mentioned last week, OFCOM have specifically= said in their most recent consultation document in =A75.93:

"Consequently, given the risk of harmful interference and the ver= y stringent emission limits, we believe it would be prudent not to allow WS= D operation in channel 38".

which we read as a very strong steer that they expect the WSD to speci= fy (by omission, since that's the ETSI model) 0W (-Inf dBm) EIRP on channel= 38.

kind regards,

Ray

--_000_53F00E5CD8B2E34C81C0C89EB0B4FE732DEA4362wdsexc1oknanomi_-- From vchen@google.com Thu Sep 19 07:30:55 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6340521F9473 for ; Thu, 19 Sep 2013 07:30:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.736 X-Spam-Level: X-Spam-Status: No, score=-1.736 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jRIP0f4zoFfU for ; Thu, 19 Sep 2013 07:30:54 -0700 (PDT) Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id BFE5321F943C for ; Thu, 19 Sep 2013 07:30:53 -0700 (PDT) Received: by mail-ob0-f181.google.com with SMTP id gq1so9536468obb.26 for ; Thu, 19 Sep 2013 07:30:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=02wkYrHAaEiMJ5HsTGCSCtO64fA5ojfYefcERhDcQ78=; b=SIgi2JMsfD+nevGyYPLe0h95buz3uN5jLKJo2z1SbK24JNZ601L8YdxC1NafGQ1kuH A4f5wHnuEcXY2ARU8pOYPIeiHlvX8n2SbMoWY1E7qoBeERfo4mKava5hZxH73Cj7zeoe BNKbR6Qz9+mTFXy/5KT8o/mMV+Gd+pYGsgwZTeFgLJyIxXr4Z5SCiDl55/6nhZdWfzLO pWt+/AvaE8HOHW3LegAmrLN1Jt6i6jREVTDzr1vEBexMb4AGT4bp8RveKzD2358uY5dM PP3HnNDkbuKI00PPh9j0/raQMFgpsa87lRk3y34gG1tkaEzebBHwlV0liShbQGiMqtyQ QPhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=02wkYrHAaEiMJ5HsTGCSCtO64fA5ojfYefcERhDcQ78=; b=NNihjSCOONGs5rqQcrVvz/P8AX0I0/yYX4ZaM5qpa7Wp/jkBYadpl6b7qIJT/zkyb/ s4efui87JG7o5RZ5MS942vmf01r1e3J14fdXsu2hkg9oA13BwqwxU5rFoB60jTmZryIm raX83EHpdcotzNg8rybYzPBG7stTmH0ynN+vbuLYoq/9DT8qxP33RiOOqBXPVpUm8FYv 38R3O+2gMEDAmcZwgQvOOx8q10H1F20awbmK/RygURsxlv+JRV9VxxV9+Ud1Zmxc2LCo yWqzSBQhWZnl4ExZ+1WCS1i3dk1V19dWuFEgS/OWpTBLKrW/hAYOjmhD3mSunoVQtOG2 O+fg== X-Gm-Message-State: ALoCoQkbCrU3FvkwVki+w1GrvstN2JAVohN8STWQNgqTTUswmuZEW6OrjwDFurFCy5TdoMAS/CoNcPIuuv3y9E8LnOZy5Qq9eD7NwlwHerrF+EVNCS4Fqriu0eTd+3YgSC5yO8sI0m/PVbZp0ZNxXC/lo/wOirTwyDNQ3vXBI4W9lz3nz3uZVY773kKYpYbh5gBDJmWeYgFE MIME-Version: 1.0 X-Received: by 10.60.42.168 with SMTP id p8mr78674oel.73.1379601049691; Thu, 19 Sep 2013 07:30:49 -0700 (PDT) Received: by 10.182.250.134 with HTTP; Thu, 19 Sep 2013 07:30:49 -0700 (PDT) In-Reply-To: <53F00E5CD8B2E34C81C0C89EB0B4FE732DEA4362@wds-exc1.okna.nominet.org.uk> References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DEA4362@wds-exc1.okna.nominet.org.uk> Date: Thu, 19 Sep 2013 07:30:49 -0700 Message-ID: From: Vincent Chen To: Ray Bellis Content-Type: multipart/alternative; boundary=047d7b5d41a6800d0004e6bd6649 Cc: "paws@ietf.org" Subject: Re: [paws] Spectrum encoding discussion X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 14:30:55 -0000 --047d7b5d41a6800d0004e6bd6649 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Ray, Perhaps this is a terminology issue. There must be some specification for emissions (intended or not) that the device must meet during certification / testing. I believe you're focusing on intentional emissions, and Andy is speaking to any emissions. I don't think it's reasonable to state that a device it must have 0W -Inf dBm emissions at channel 38, if it intends to use any channels nearby? -vince On Thu, Sep 19, 2013 at 3:15 AM, Ray Bellis wrot= e: > > On 18 Sep 2013, at 22:01, Andy Lee wrote: > > lots of interesting stuff... :) > > Andy, your examples are good. If the FCC regime folks want to specify > channel edge emission masks that's OK with me, so long as it doesn't > prohibit the ETSI approach at the same time. > > However on this particular point: > > Not having looked at Ofcom's data set yet, I think it's a little > premature to say that they will be silent or explicitly omit data for > channel 38. > > > I must disagree. As mentioned last week, OFCOM have specifically said in > their most recent consultation document in =A75.93: > > "Consequently, given the risk of harmful interference and the very > stringent emission limits, we believe it would be prudent not to allow WS= D > operation in channel 38". > > which we read as a very strong steer that they expect the WSD to specify > (by omission, since that's the ETSI model) 0W (-Inf dBm) EIRP on channel = 38. > > kind regards, > > Ray > > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > > --=20 -vince --047d7b5d41a6800d0004e6bd6649 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Ray,

Perhaps this is a terminology issu= e. There must be some specification for emissions (intended or not) that th= e device must meet during certification / testing.
I believe you&= #39;re focusing on intentional emissions, and Andy is speaking to any emiss= ions.

I don't think it's reasonable to state that a d= evice it must have 0W -Inf dBm emissions at channel 38, if it intends to us= e any channels nearby?

-vince


On Thu, Sep 19, 2013 at 3:15 AM, Ray Bel= lis <Ray.Bellis@nominet.org.uk> wrote:

On 18 Sep 2013, at 22:01, Andy Lee <tvfool@google.com> wrote:

lots of interesting stuff... :)

Andy, your examples are good. =A0If the FCC regime folks want to speci= fy channel edge emission masks that's OK with me, so long as it doesn&#= 39;t prohibit the ETSI approach at the same time.

However on this particular point:

Not having looked at Ofcom's data set yet, I think it's a little prema= ture to say that they will be silent or explicitly omit data for channel 38= .

I must disagree. =A0As mentioned last week, OFCOM have specifically sa= id in their most recent consultation document in =A75.93:

"Consequently, given the risk of harmful interference and the ver= y stringent emission limits, we believe it would be prudent not to allow WS= D operation in channel 38".

which we read as a very strong steer that they expect the WSD to speci= fy (by omission, since that's the ETSI model) 0W (-Inf dBm) EIRP on cha= nnel 38.

kind regards,

Ray


_______________________________________________
paws mailing list
paws@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/paws




--
-vince
--047d7b5d41a6800d0004e6bd6649-- From Ray.Bellis@nominet.org.uk Thu Sep 19 07:55:43 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B99F21F991E for ; Thu, 19 Sep 2013 07:55:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.994 X-Spam-Level: X-Spam-Status: No, score=-9.994 tagged_above=-999 required=5 tests=[AWL=0.605, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iQyIAFh8Gfm5 for ; Thu, 19 Sep 2013 07:55:35 -0700 (PDT) Received: from mx1.nominet.org.uk (mail.nominet.org.uk [213.248.242.48]) by ietfa.amsl.com (Postfix) with ESMTP id 9FDE221F9767 for ; Thu, 19 Sep 2013 07:55:27 -0700 (PDT) DomainKey-Signature: s=main2.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:X-IPAS-Result:Received:Received:From:To:CC: Subject:Thread-Topic:Thread-Index:Date:Message-ID: References:In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:x-originating-ip: Content-Type:Content-ID:Content-Transfer-Encoding: MIME-Version; b=JwNAWa6Od+PT8D7tXoAnrMz1taE94l6LRb1Df8JUhRjGwQSxGfx51Pz5 /CQYanxu8yRhgPz7ZXlNn9SOLdGQNKXR/l31Bpo4DtcqUUnQbW76Mi7cn pRSlsnyt4YMcakTw6SSRPdxmoEVCGfnuI8HN7Jl7s9ZLiusIlqZlZ/8Tz c5yL1W/pRC9vPB7cYrc3ZDR+qAFDuFm0k1nt2paTjzXUF9liPWaVMUt2O 0kIJfFXJJiriC3Ysjd6R2RHlceQbX; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=@nominet.org.uk; q=dns/txt; s=main2.dkim.nominet.selector; t=1379602534; x=1411138534; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=HGFRX6tUyceIzquwSRMC3hOak9F5oJLsUzHiwl+Nnds=; b=dqRxLSJwR3y+ruhdK9I9IvO8wOvsngTX13rexHzfMvbWffG6Z+sZET+D yteGY6cZnQPie8OIPAluUewMvp9Ct1uuAabNEJKMtqzOcYMogM76zaGiR Qo+nleaEq3FxjxwMcnq0/7aYoa4irbrE2W97m2SJHsFuBB041PI9L+aa5 I3OJoLZiJy7AI3xylC5wKArHfrUqd1zOO77kCUU4qRG3PHbxpKMx0ZjtY vgjPW68XGOgvRH9pKjBm3rYNDLYE8; X-IronPort-AV: E=Sophos;i="4.90,937,1371078000"; d="scan'208";a="3467055" X-IPAS-Result: AhEFAO0OO1LV+MWR/2dsb2JhbABbgmYhgQrBLIEgFnSCJQEBAQECAScsJgULAgEIDhQkMiUCBA4FCId1BwO6BY4vgQUCMQeDHoEAA4kAoHGDJIIq Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx1.nominet.org.uk with ESMTP; 19 Sep 2013 15:55:24 +0100 Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4%17]) with mapi id 14.02.0318.004; Thu, 19 Sep 2013 15:55:24 +0100 From: Ray Bellis To: Vincent Chen Thread-Topic: [paws] Spectrum encoding discussion Thread-Index: AQHOtLJH/FWG06ATlUqxs+HiIH56lZnMyBoAgABHaYCAAAbdgA== Date: Thu, 19 Sep 2013 14:55:23 +0000 Message-ID: <53F00E5CD8B2E34C81C0C89EB0B4FE732DEA5B73@wds-exc1.okna.nominet.org.uk> References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DEA4362@wds-exc1.okna.nominet.org.uk> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.2.1] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] Spectrum encoding discussion X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 14:55:43 -0000 On 19 Sep 2013, at 15:30, Vincent Chen wrote: > Perhaps this is a terminology issue. Perhaps :) > There must be some specification for emissions (intended or not) that the= device must meet during certification / testing. Indeed. The OFCOM / ETSI WSDB device<->DB interface only specifies intende= d in-block emissions. All "Unintentional" out-of-block emissions are constrained by the ETSI draf= t specification. > I believe you're focusing on intentional emissions, and Andy is speaking = to any emissions. That's my understanding. > I don't think it's reasonable to state that a device it must have 0W -Inf= dBm emissions at channel 38, if it intends to use any channels nearby? I disagree - OFCOM are stating 0W -Inf dBm *intentional* in-block emissions= at channel 38. They are not requiring that there be absolutely no emissions into channel 3= 8. Leakage from adjacent channels will be managed through a combination of= the device's emission class and OFCOM's rules on maximum permitted power l= evels in those nearby channels. For example, in channels 37 and 39, OFCOM require Class 5 devices to transm= it at 11 dBm max, Class 4 at 21 dBm and Class 3 at 31 dBm, with no constrai= nts on Class 1 or 2. OFCOM have proposed that this is sufficient to ensure that the unintentiona= l leakage into channel 38 is not harmful to the PMSE devices operating in t= hat channel. kind regards, Ray From tvfool@google.com Thu Sep 19 08:21:37 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C61D21F8F09 for ; Thu, 19 Sep 2013 08:21:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.944 X-Spam-Level: X-Spam-Status: No, score=-0.944 tagged_above=-999 required=5 tests=[AWL=1.033, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MwCEVHlHau1o for ; Thu, 19 Sep 2013 08:21:35 -0700 (PDT) Received: from mail-qc0-x236.google.com (mail-qc0-x236.google.com [IPv6:2607:f8b0:400d:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 8DE7221F9193 for ; Thu, 19 Sep 2013 08:21:34 -0700 (PDT) Received: by mail-qc0-f182.google.com with SMTP id n4so5458568qcx.41 for ; Thu, 19 Sep 2013 08:21:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wIoH/htdZK97uS79BrKdjJRF5naf6UrrRx7qSE7y0A0=; b=G82H6b7GlVuTqbdhQ/rg0sZPgi25n6Z/Kt+vVekyj/d8O3czFZwVOhJIrX717C4GQk GZScV9SLBnzfffd5HHT3jck1pBkz7OYpnySayAeHkJ24WLqFBZQRqJJyiISjeYzPOL1a OsNVXk5kiXzYjf5xyKQ9Cm+veCh/7XBfkD2HE0QwjoUyso04oPsQNXpj3jwQkfrX9V74 1dF1C1ShquEP3Dt6Z+3yrkOOpTWBKRbxh9fgua1nLtJeWjcC0qWsctTy0IGKeZIpvN/9 NJ9T1cjjrN7frtsCY84ktqYZElSCQ3gzwfiGfOIMLn26gJnfPf8jtDoMN70zwOS+GvI/ BQEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=wIoH/htdZK97uS79BrKdjJRF5naf6UrrRx7qSE7y0A0=; b=YcI1X3o3hZBl07iccpuFXQWYJ/VZxJDvBfl1SE9S7lZGJKyIQ5JqusqP2hNBV9nvDh Af1scOdyvLRUMPDhTsLh7h8tYE4YfLx/c1WRKd3Nee9Z9veUyYJwNAZCmU876j0X5m8D I1OsXiXojXs/o8xu5I3NwgrNyi4nKvfWiS5SR15yDTeQk1/t2TMLtxIJRsl1hXI72rA6 R3iqLkm7wuypZwBG+AWXSAe7TA7H/4KMCuwlTKHdnrhV3gjrhVWcvZI0/uTKKOByAMGO CfGxuGltKGpUqMeBRJ4VapbU9n+3isKnnRJMypU/Vd9Rlw/ToGDo95JQt8IlAmbMY4Ap RuYg== X-Gm-Message-State: ALoCoQlgYTdYC7dqXeEpApHjOX9CPsj7Fv6gVObYoi0pQUari4rtjdAi2LRxtaNgSppwJodMCpUqW1bWZS9lmyWdfiwGFctwnxlpQzHZXAFwLpjrHQL1BQupuRxPbSuHBgkVGsWXQYMJe5PUEz3YKVzEA0r+ZOvxkBnoP+cX5UYrJuqFCU5JPO7zSESNoiQqVs4rDLfcLpMg MIME-Version: 1.0 X-Received: by 10.229.244.8 with SMTP id lo8mr4727386qcb.20.1379604093704; Thu, 19 Sep 2013 08:21:33 -0700 (PDT) Received: by 10.229.207.8 with HTTP; Thu, 19 Sep 2013 08:21:33 -0700 (PDT) In-Reply-To: <53F00E5CD8B2E34C81C0C89EB0B4FE732DEA5B73@wds-exc1.okna.nominet.org.uk> References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DEA4362@wds-exc1.okna.nominet.org.uk> <53F00E5CD8B2E34C81C0C89EB0B4FE732DEA5B73@wds-exc1.okna.nominet.org.uk> Date: Thu, 19 Sep 2013 08:21:33 -0700 Message-ID: From: Andy Lee To: Ray Bellis Content-Type: multipart/alternative; boundary=001a11c2be1eefaea004e6be1bf2 Cc: "paws@ietf.org" Subject: Re: [paws] Spectrum encoding discussion X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 15:21:37 -0000 --001a11c2be1eefaea004e6be1bf2 Content-Type: text/plain; charset=ISO-8859-1 Hi Ray, For example, in channels 37 and 39, OFCOM require Class 5 devices to > transmit at 11 dBm max, Class 4 at 21 dBm and Class 3 at 31 dBm, with no > constraints on Class 1 or 2. This actually shows that Ofcom has picked a power threshold on channel 38 of -33 dBm. If you look at the ACLR numbers for class 3, 4, and 5 devices, you'll see they are 10 dB apart from each other and that they all work out to be -33 dBm on channel 38. The reason there are no limits for class 1 and 2 devices is because the in-band power on channels 37 and 39 cannot exceed +36 dBm/8MHz, and therefore the power on channel 38 will naturally be less than -33 dBm. Andy Lee | Google Inc. | tvfool@google.com | 408-230-0522 On Thu, Sep 19, 2013 at 7:55 AM, Ray Bellis wrote: > > On 19 Sep 2013, at 15:30, Vincent Chen > wrote: > > > Perhaps this is a terminology issue. > > Perhaps :) > > > There must be some specification for emissions (intended or not) that > the device must meet during certification / testing. > > Indeed. The OFCOM / ETSI WSDB device<->DB interface only specifies > intended in-block emissions. > > All "Unintentional" out-of-block emissions are constrained by the ETSI > draft specification. > > > I believe you're focusing on intentional emissions, and Andy is speaking > to any emissions. > > That's my understanding. > > > I don't think it's reasonable to state that a device it must have 0W > -Inf dBm emissions at channel 38, if it intends to use any channels nearby? > > I disagree - OFCOM are stating 0W -Inf dBm *intentional* in-block > emissions at channel 38. > > They are not requiring that there be absolutely no emissions into channel > 38. Leakage from adjacent channels will be managed through a combination > of the device's emission class and OFCOM's rules on maximum permitted power > levels in those nearby channels. > > For example, in channels 37 and 39, OFCOM require Class 5 devices to > transmit at 11 dBm max, Class 4 at 21 dBm and Class 3 at 31 dBm, with no > constraints on Class 1 or 2. > > OFCOM have proposed that this is sufficient to ensure that the > unintentional leakage into channel 38 is not harmful to the PMSE devices > operating in that channel. > > kind regards, > > Ray > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > --001a11c2be1eefaea004e6be1bf2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Ray,

For exam= ple, in channels 37 and 39, OFCOM require Class 5 devices to transmit at 11= dBm max, Class 4 at 21 dBm and Class 3 at 31 dBm, with no constraints on C= lass 1 or 2.

This actual= ly shows that Ofcom has picked a power threshold on channel 38 of -33 dBm. = =A0If you look at the ACLR numbers for class 3, 4, and 5 devices, you'l= l see they are 10 dB apart from each other and that they all work out to be= -33 dBm on channel 38.

The reason = there are no limits for class 1 and 2 devices is because the in-band power = on channels 37 and 39 cannot exceed +36 dBm/8MHz, and therefore the power o= n channel 38 will naturally be less than -33 dBm.


Andy Lee=A0|=A0Google Inc. | =A0tvfool@google.com= =A0|=A0408-230-0522


On Thu, Sep 19, 2013 at 7:55 AM, Ray Bel= lis <Ray.Bellis@nominet.org.uk> wrote:

On 19 Sep 2013, at 15:30, Vincent Chen <vchen@google.com>
=A0wrote:

> Perhaps this is a terminology issue.

Perhaps :)

> There must be some specification for emissions (intended or not) that = the device must meet during certification / testing.

Indeed. =A0The OFCOM / ETSI WSDB device<->DB interface only spe= cifies intended in-block emissions.

All "Unintentional" out-of-block emissions are constrained by the= ETSI draft specification.

> I believe you're focusing on intentional emissions, and Andy is sp= eaking to any emissions.

That's my understanding.

> I don't think it's reasonable to state that a device it must h= ave 0W -Inf dBm emissions at channel 38, if it intends to use any channels = nearby?

I disagree - OFCOM are stating 0W -Inf dBm *intentional* in-block emi= ssions at channel 38.

They are not requiring that there be absolutely no emissions into channel 3= 8. =A0Leakage from adjacent channels will be managed through a combination = of the device's emission class and OFCOM's rules on maximum permitt= ed power levels in those nearby channels.

For example, in channels 37 and 39, OFCOM require Class 5 devices to transm= it at 11 dBm max, Class 4 at 21 dBm and Class 3 at 31 dBm, with no constrai= nts on Class 1 or 2.

OFCOM have proposed that this is sufficient to ensure that the unintentiona= l leakage into channel 38 is not harmful to the PMSE devices operating in t= hat channel.

kind regards,

Ray

_______________________________________________
paws mailing list
paws@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/paws

--001a11c2be1eefaea004e6be1bf2-- From Ray.Bellis@nominet.org.uk Thu Sep 19 08:30:17 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D9DB21F93F3 for ; Thu, 19 Sep 2013 08:30:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.049 X-Spam-Level: X-Spam-Status: No, score=-10.049 tagged_above=-999 required=5 tests=[AWL=0.550, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uuYNRFC1I8ok for ; Thu, 19 Sep 2013 08:30:12 -0700 (PDT) Received: from mx1.nominet.org.uk (mx1.nominet.org.uk [213.248.242.48]) by ietfa.amsl.com (Postfix) with ESMTP id A62A921F9223 for ; Thu, 19 Sep 2013 08:30:11 -0700 (PDT) DomainKey-Signature: s=main2.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:X-IPAS-Result:Received:Received:From:To:CC: Subject:Thread-Topic:Thread-Index:Date:Message-ID: References:In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:x-originating-ip: Content-Type:Content-ID:Content-Transfer-Encoding: MIME-Version; b=ha6leG6f+pjKwvoT1CAezPWPVQlmqQLou/2t6bR0iOUb6N0t+8+xy83e 5LHUO+ypKV26qLta1+rP4JfxcIRVaoMqtUV91FuUtRMApB81W1/eEP75+ pQWVH61Zb7J4qoitNgY8Ted9Hkpi7XpkkWLYTAGTkVhmnkWVwWgycpGhe 1L39Z1LO3VFdkFDOzB2VqKyqg7Myc3w9Xs+8C1ycCh+Zm93jQ/u0DWiuz +yVG3m0jntKZNAoUS+iz5e8AI8qNz; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=@nominet.org.uk; q=dns/txt; s=main2.dkim.nominet.selector; t=1379604611; x=1411140611; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Ugz8ZAlYgRklZLeXv/QTSv9sGemx8uftB54oaZV3bRY=; b=M6g9j5eTkwdTdJ/fJNKFuMiY8wdReM/H5ujZjMuJzu1W/acBKpoKuNSF 5B7kvHSy2DF2ToIqovB65kXBGZYvrIsc6BTEEWqycSFaEv4guDvlqbkuP 2SGq6YpBoff+NII96eq+APLTswkkE+rNF8S6epDqeDo24DLM0VjvZVocv qV+cMrpIjYyn7DQcUsGlH96E3Nizi3HgYC2vJLXTrGPlgxK57IDExMbrd LNVUWwMFDVmpYWhC2+5y49A4B1fvH; X-IronPort-AV: E=Sophos;i="4.90,937,1371078000"; d="scan'208";a="3467459" X-IPAS-Result: AhEFAB8XO1LV+MWR/2dsb2JhbABbgmYhgQrBLIEhFnSCJQEBAQECAVMmBQsCAQgOFCQyJQIEDgUIh3UHA7ocji+BBQIxB4MegQADiQCgcYMkgio Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx1.nominet.org.uk with ESMTP; 19 Sep 2013 16:30:03 +0100 Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4%17]) with mapi id 14.02.0318.004; Thu, 19 Sep 2013 16:30:03 +0100 From: Ray Bellis To: Andy Lee Thread-Topic: [paws] Spectrum encoding discussion Thread-Index: AQHOtLJH/FWG06ATlUqxs+HiIH56lZnMyBoAgABHaYCAAAbdgIAAB1CAgAACXwA= Date: Thu, 19 Sep 2013 15:30:02 +0000 Message-ID: <53F00E5CD8B2E34C81C0C89EB0B4FE732DEA5FE1@wds-exc1.okna.nominet.org.uk> References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DEA4362@wds-exc1.okna.nominet.org.uk> <53F00E5CD8B2E34C81C0C89EB0B4FE732DEA5B73@wds-exc1.okna.nominet.org.uk> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.2.1] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <53B33904E360E34F92435DBA7BE32501@okna.nominet.org.uk> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] Spectrum encoding discussion X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 15:30:17 -0000 On 19 Sep 2013, at 16:21, Andy Lee wrote: > This actually shows that Ofcom has picked a power threshold on channel 38= of -33 dBm. If you look at the ACLR numbers for class 3, 4, and 5 devices= , you'll see they are 10 dB apart from each other and that they all work ou= t to be -33 dBm on channel 38. >=20 > The reason there are no limits for class 1 and 2 devices is because the i= n-band power on channels 37 and 39 cannot exceed +36 dBm/8MHz, and therefor= e the power on channel 38 will naturally be less than -33 dBm. The math bears that out, but nonetheless OFCOM are still effectively propos= ing that *no* in-block transmissions are allowed in that channel. Per OFCOM / ETSI device interface requirements it would be incorrect for us= to actually send that value of -33 dBm to a device. Ray From tvfool@google.com Thu Sep 19 09:09:27 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4D6421F8BFD for ; Thu, 19 Sep 2013 09:09:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.091 X-Spam-Level: X-Spam-Status: No, score=-1.091 tagged_above=-999 required=5 tests=[AWL=0.886, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yoj9YTIywZ-T for ; Thu, 19 Sep 2013 09:09:27 -0700 (PDT) Received: from mail-qe0-x233.google.com (mail-qe0-x233.google.com [IPv6:2607:f8b0:400d:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id F07B021F841D for ; Thu, 19 Sep 2013 09:09:26 -0700 (PDT) Received: by mail-qe0-f51.google.com with SMTP id ne12so5953972qeb.10 for ; Thu, 19 Sep 2013 09:09:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=sp3h3/wwIZpYe+RunwRJ8ZOKddFJ2OvRc6y2wyajaGg=; b=hA4+RfUlpszRXilW/gnsNqvIgqENQ/EI4qgSdBWkpOW//WsK72XNI70teCrxtJ4nTj skw8Okwuv5yi1HUI8WqfEXOzDPbAFImPd+blA+GBM5nkk3xbsQuqMNYzItPaWzThs+ag NdtXi6MLtJrE6ClNvHWPXLWU1tFxseGiAKj4rTQ7Xa0eHk9LXYlOIjtyItcejm1cxktA LcSIdpceldQdkn1c6RK+9DHboNvfNWVFp0dr5/MNA4B9OBsWCutEJOmugQP4jJwFc8bD 5+cOQQbpvOJ4TLAoKULtwyLwiE8OtooncKZBelj1Tb22dLIpAOK7jOoLaRfjPQXhI5l6 NLKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=sp3h3/wwIZpYe+RunwRJ8ZOKddFJ2OvRc6y2wyajaGg=; b=CnmAhWX5VJ8+9FxPnZyVgB60y2ZVuvea18sA7JvBaQKP2ML8ngbDfF9bbLFT8wAxsR +DuFY+wQC9kfbOeO5x+FxBIBFdf6ajna/4kuAZRAMmKGKbVEVYS0vtHcUJSfDBb2YTya SNUn5M2soy6iDtSadE532A//732coR+bYPNEANS0+DqT8fn9aiA0QZirQmpe7aDNgtvN xJHuURKWj9lLGP20AKlNP5PrZHchkn5+Voa+pVLoLwEta/ijtsih3l50hU68b1U8F/N+ hQVzLJjXvjfDPVzju1nW5x6xGE0gsXh91JZ96ZyyeKt9yu/skienovBzpVsg0JpN/NTX fv4g== X-Gm-Message-State: ALoCoQmUS3C4+h3sMkJatqtsnuTTZxxNqq4cUcCDm3LkFPsbhK/BOxzQgJy3vs8pCltdT6xR5lFcYKyOvFZipF4eJJwvY8XUWXmOq8wokfCJE5nBoOTFiAuCpfCkYEbcyTz7qmHB+Levf47glJ1FkU+8YXJEfg1dYkuDPyAARTpsLXN25bWLPZF3F6z/TThNUWsyqT03AfFz MIME-Version: 1.0 X-Received: by 10.229.47.71 with SMTP id m7mr5090912qcf.25.1379606966219; Thu, 19 Sep 2013 09:09:26 -0700 (PDT) Received: by 10.229.207.8 with HTTP; Thu, 19 Sep 2013 09:09:26 -0700 (PDT) In-Reply-To: <53F00E5CD8B2E34C81C0C89EB0B4FE732DEA5FE1@wds-exc1.okna.nominet.org.uk> References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DEA4362@wds-exc1.okna.nominet.org.uk> <53F00E5CD8B2E34C81C0C89EB0B4FE732DEA5B73@wds-exc1.okna.nominet.org.uk> <53F00E5CD8B2E34C81C0C89EB0B4FE732DEA5FE1@wds-exc1.okna.nominet.org.uk> Date: Thu, 19 Sep 2013 09:09:26 -0700 Message-ID: From: Andy Lee To: Ray Bellis Content-Type: multipart/alternative; boundary=001a1133b3e426ca5304e6bec708 Cc: "paws@ietf.org" Subject: Re: [paws] Spectrum encoding discussion X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 16:09:28 -0000 --001a1133b3e426ca5304e6bec708 Content-Type: text/plain; charset=ISO-8859-1 > > The math bears that out, but nonetheless OFCOM are still effectively > proposing that *no* in-block transmissions are allowed in that channel. Same is true for the FCC. The FCC also assumes that "off" channels are not used by WSDs. Specifying a low power level like -33 dBm is effectively the same thing as specifying no in-band emissions there. Even if someone did try to put an in-band emission there (regardless of how impractical that actually is), it would be too low to cause interference to anyone and no harm has been done to the "RF environment". The advantage of having an "well behaved" spectrum profile (contiguous and without special values like -inf) is that the channel selection algorithm on the WSDs becomes much simpler and logical. There's no need to have lots of special boundary condition checks and code paths that only get triggered under special circumstances. I'd like to avoid ambiguous interpretations on the device side as much as possible. Andy Lee | Google Inc. | tvfool@google.com | 408-230-0522 On Thu, Sep 19, 2013 at 8:30 AM, Ray Bellis wrote: > > On 19 Sep 2013, at 16:21, Andy Lee > wrote: > > > This actually shows that Ofcom has picked a power threshold on channel > 38 of -33 dBm. If you look at the ACLR numbers for class 3, 4, and 5 > devices, you'll see they are 10 dB apart from each other and that they all > work out to be -33 dBm on channel 38. > > > > The reason there are no limits for class 1 and 2 devices is because the > in-band power on channels 37 and 39 cannot exceed +36 dBm/8MHz, and > therefore the power on channel 38 will naturally be less than -33 dBm. > > The math bears that out, but nonetheless OFCOM are still effectively > proposing that *no* in-block transmissions are allowed in that channel. > > Per OFCOM / ETSI device interface requirements it would be incorrect for > us to actually send that value of -33 dBm to a device. > > Ray > > > --001a1133b3e426ca5304e6bec708 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
The math bears that out, but nonetheless=A0OFCOM=A0are still effectively= proposing that *no* in-block transmissions are allowed in that channel.

Same is true for the FCC. =A0The FCC also assumes that = "off" channels are not used by WSDs.

Spe= cifying a low power level like -33 dBm is effectively the same thing as spe= cifying no in-band emissions there.

Even if someone did try to put an in-band emission ther= e (regardless of how impractical that actually is), it would be too low to = cause interference to anyone and no harm has been done to the "RF envi= ronment".

The advantage of having an "well behaved&quo= t; spectrum profile=A0(contiguous and without special values like -inf)=A0i= s that the channel selection algorithm on the WSDs becomes much simpler and= logical. =A0There's no need to have lots of special boundary condition= checks and code paths that only get triggered under special circumstances.= =A0I'd like to avoid ambiguous interpretations on the device side as m= uch as possible.


Andy Lee=A0|=A0Google Inc. | =A0tvfool@google.com= =A0|=A0408-230-0522


On Thu, Sep 19, 2013 at 8:30 AM, Ray Bel= lis <Ray.Bellis@nominet.org.uk> wrote:

On 19 Sep 2013, at 16:21, Andy Lee <tvfool@google.com>
=A0wrote:

> This actually shows that Ofcom has picked a power threshold on channel= 38 of -33 dBm. =A0If you look at the ACLR numbers for class 3, 4, and 5 de= vices, you'll see they are 10 dB apart from each other and that they al= l work out to be -33 dBm on channel 38.
>
> The reason there are no limits for class 1 and 2 devices is because th= e in-band power on channels 37 and 39 cannot exceed +36 dBm/8MHz, and there= fore the power on channel 38 will naturally be less than -33 dBm.

The math bears that out, but nonetheless OFCOM are still effectively = proposing that *no* in-block transmissions are allowed in that channel.

Per OFCOM / ETSI device interface requirements it would be incorrect for us= to actually send that value of -33 dBm to a device.

Ray



--001a1133b3e426ca5304e6bec708-- From tvfool@google.com Thu Sep 19 09:11:37 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A222121F995F for ; Thu, 19 Sep 2013 09:11:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[AWL=0.775, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J2jfL3FtFhsk for ; Thu, 19 Sep 2013 09:11:37 -0700 (PDT) Received: from mail-qc0-x22b.google.com (mail-qc0-x22b.google.com [IPv6:2607:f8b0:400d:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id F399F21F8BFD for ; Thu, 19 Sep 2013 09:11:36 -0700 (PDT) Received: by mail-qc0-f171.google.com with SMTP id x19so5601093qcw.16 for ; Thu, 19 Sep 2013 09:11:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vQZvBy9Pr1p4eAuGxQi0tr++ri0xdBTmnl4mbMaQBRk=; b=hcIr7UZEK7ZF05vcgNISQ2eQmrNmX5FFW/HNBzWKLYoX9rGMGCmOVh3jNoo0N1DZ+c bstCYvFXR/K5vh8TbPYp8PEIoMSrPBp5MB75pLMNeOML25N7LORf8cftTD3QnG4bsdvK 8xlO6l1vmv2JFHh5ulsCpkXuZR5ZglD4nSNZk4hp7dg6lhhUhkgwMrRdKIAkzCFUaiCV /38tMvTNAzQtNZ2t+PBnN7YpudvwEWwlfqUvjECy6cLJ/YOe9vTUxX797WqC4ObLvvap Jm5UmO/knfHssRZ/Z4wKNLkWzE3M/telqaDHjfzQNtT1d8vmE7ACCpvgj4JwriwhHw2C iPWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=vQZvBy9Pr1p4eAuGxQi0tr++ri0xdBTmnl4mbMaQBRk=; b=mq/h/ewVFa09PwOAC0rWjXQe6LkmTxO1ceWuewipgJ1OenCQxX2JROX/nLNoBAUdM7 /j4pM+6B0ZKbWoVvZ2CsQnsh/EwHe5kxZKyw0aWGi/dga7kQTN/Cwurfxl/6nFXUOmTs xhmfCCrl+FGRajY8o+0Li90zq6GmjE8hk5d/HdCs5vnqzknFLuXF04O5ZR9C/8dqGcek 9RQw6PJoYxsGcjhRoxNKgFXBKfrtrxCtafE1W2Wpm/VDDGBjxaOrZB78KEbaILb6nr5g bvlPvxYiLzz6h17mdLjx1t4yW2V+onQt0cSi+OsMVW5XHDAhTaBdMBsT0AelEbbqRj5C hHjA== X-Gm-Message-State: ALoCoQkSKUnOKgWdZa26RjboEIavR8sO6hyhjsa+O55nIOK+JxHkB4yhljy2OJTc6tE+HxY3lXbmYRDw7gnJv1NAfUTgmqWzJEZTOHE48utCM/+fZIboHFaWuiSw0vBNj0LRCfE+KB1pdp+eGs9XZ8ozU5XVHx/n2gQcI/jrs54yJ2zUinaVSXuA+Vdwq2lbF4P80QqsUfc8 MIME-Version: 1.0 X-Received: by 10.49.6.232 with SMTP id e8mr5204235qea.18.1379607096088; Thu, 19 Sep 2013 09:11:36 -0700 (PDT) Received: by 10.229.207.8 with HTTP; Thu, 19 Sep 2013 09:11:36 -0700 (PDT) In-Reply-To: <53F00E5CD8B2E34C81C0C89EB0B4FE732DEA5FE1@wds-exc1.okna.nominet.org.uk> References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DEA4362@wds-exc1.okna.nominet.org.uk> <53F00E5CD8B2E34C81C0C89EB0B4FE732DEA5B73@wds-exc1.okna.nominet.org.uk> <53F00E5CD8B2E34C81C0C89EB0B4FE732DEA5FE1@wds-exc1.okna.nominet.org.uk> Date: Thu, 19 Sep 2013 09:11:36 -0700 Message-ID: From: Andy Lee To: Ray Bellis Content-Type: multipart/alternative; boundary=047d7bd74a16e4726204e6becea1 Cc: "paws@ietf.org" Subject: Re: [paws] Spectrum encoding discussion X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 16:11:37 -0000 --047d7bd74a16e4726204e6becea1 Content-Type: text/plain; charset=ISO-8859-1 > > Per OFCOM / ETSI device interface requirements it would be incorrect for > us to actually send that value of -33 dBm to a device. I'd be interested in seeing the language for this. Do you have a reference I could look at? Thanks Andy Lee | Google Inc. | tvfool@google.com | 408-230-0522 On Thu, Sep 19, 2013 at 8:30 AM, Ray Bellis wrote: > > On 19 Sep 2013, at 16:21, Andy Lee > wrote: > > > This actually shows that Ofcom has picked a power threshold on channel > 38 of -33 dBm. If you look at the ACLR numbers for class 3, 4, and 5 > devices, you'll see they are 10 dB apart from each other and that they all > work out to be -33 dBm on channel 38. > > > > The reason there are no limits for class 1 and 2 devices is because the > in-band power on channels 37 and 39 cannot exceed +36 dBm/8MHz, and > therefore the power on channel 38 will naturally be less than -33 dBm. > > The math bears that out, but nonetheless OFCOM are still effectively > proposing that *no* in-block transmissions are allowed in that channel. > > Per OFCOM / ETSI device interface requirements it would be incorrect for > us to actually send that value of -33 dBm to a device. > > Ray > > > --047d7bd74a16e4726204e6becea1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Per OFCOM / ETSI device interface require= ments it would be incorrect for us to actually send that value of -33 dBm t= o a device.

I'd be = interested in seeing the language for this. =A0Do you have a reference I co= uld look at?

Thanks

Andy Lee=A0|=A0Google Inc. | =A0tvfool@google.com= =A0|=A0408-230-0522


On Thu, Sep 19, 2013 at 8:30 AM, Ray Bel= lis <Ray.Bellis@nominet.org.uk> wrote:

On 19 Sep 2013, at 16:21, Andy Lee <tvfool@google.com>
=A0wrote:

> This actually shows that Ofcom has picked a power threshold on channel= 38 of -33 dBm. =A0If you look at the ACLR numbers for class 3, 4, and 5 de= vices, you'll see they are 10 dB apart from each other and that they al= l work out to be -33 dBm on channel 38.
>
> The reason there are no limits for class 1 and 2 devices is because th= e in-band power on channels 37 and 39 cannot exceed +36 dBm/8MHz, and there= fore the power on channel 38 will naturally be less than -33 dBm.

The math bears that out, but nonetheless OFCOM are still effectively = proposing that *no* in-block transmissions are allowed in that channel.

Per OFCOM / ETSI device interface requirements it would be incorrect for us= to actually send that value of -33 dBm to a device.

Ray



--047d7bd74a16e4726204e6becea1-- From ben@blindcreek.com Fri Sep 20 03:07:21 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F81921F8FDC for ; Fri, 20 Sep 2013 03:07:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.249 X-Spam-Level: X-Spam-Status: No, score=0.249 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_05=-1.11, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Ovq54ayfVMs for ; Fri, 20 Sep 2013 03:07:12 -0700 (PDT) Received: from blu0-omc3-s6.blu0.hotmail.com (blu0-omc3-s6.blu0.hotmail.com [65.55.116.81]) by ietfa.amsl.com (Postfix) with ESMTP id 852B121F8F97 for ; Fri, 20 Sep 2013 03:07:12 -0700 (PDT) Received: from BLU0-SMTP234 ([65.55.116.74]) by blu0-omc3-s6.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 20 Sep 2013 03:07:11 -0700 X-TMN: [0lznI2VV9lcD7LPD5Peu7rP2IrVf6gHr] X-Originating-Email: [ben@blindcreek.com] Message-ID: Received: from [127.0.0.1] ([58.212.29.75]) by BLU0-SMTP234.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 20 Sep 2013 03:07:10 -0700 Date: Fri, 20 Sep 2013 03:07:07 -0700 From: "Benjamin A. Rolfe" User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: paws@ietf.org References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DEA4362@wds-exc1.okna.nominet.org.uk> <53F00E5CD8B2E34C81C0C89EB0B4FE732DEA5B73@wds-exc1.okna.nominet.org.uk> <53F00E5CD8B2E34C81C0C89EB0B4FE732DEA5FE1@wds-exc1.okna.nominet.org.uk> In-Reply-To: Content-Type: multipart/alternative; boundary="------------020005040402010609070605" X-Antivirus: avast! (VPS 130920-1, 09/20/2013), Outbound message X-Antivirus-Status: Not-Tested X-OriginalArrivalTime: 20 Sep 2013 10:07:11.0479 (UTC) FILETIME=[2C410870:01CEB5E9] Sender: Subject: Re: [paws] Spectrum encoding discussion X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 10:07:21 -0000 --------------020005040402010609070605 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit On 9/19/2013 9:09 AM, Andy Lee wrote: > > The math bears that out, but nonetheless OFCOM are still > effectively proposing that *no* in-block transmissions are allowed > in that channel. > > > Same is true for the FCC. The FCC also assumes that "off" channels > are not used by WSDs. And that means NO intentional radiation in the channel. > > Specifying a low power level like -33 dBm is effectively the same > thing as specifying no in-band emissions there. If you are reading this as "transmitted emissions in band should be lower than -33dBm" then, no, this is not the same as "no emissions" per FCC rules. If one were to intentionally transmit at -33dBm where no intentional emissions are allowed, that would not be the same as "no" under the rules. > > Even if someone did try to put an in-band emission there (regardless > of how impractical that actually is), it would be too low to cause > interference to anyone and no harm has been done to the "RF environment". Should be a little careful here for a couple reasons. I've designed and shipped communication systems that operate quite well with transmit power levels intentionally below -33dBm and do very useful things. It's pretty easy to design a receive with sensitivity better than -96dBm, so an intentional radiator at -33dBm near by will be noticed - at 900 MHz your 10dB above sensitivity at 10m and at 54MHz you'd be 10 dB above sensitivity at 100m, possibly. And when it comes to protecting their spectrum, people always use the best propagation model to calculate interfence impact on them :-). I've probably misunderstood something badly, but -33dBm is certainly enough power to be noticed. I have tried the "too low to be noticed" argument a few times in the past in regulatory discussions, and incumbent and/or protected users usually set the threshold closer to -120dBm and usually argue that even at really low TX power, the "aggregate impact" of multiple devices in the "RF Environment" is an unacceptable impact. We had trouble with this argument when the intentional radiator TX limit was below the maximum unintentional emission limits for most non-transmitting devices (-41.3dBm). So it would be fairly important to ensure a device does not interpret -33dBm as it's ok to use that channel so long as it's TX power is below -33dBm. I may be off base here because of how y'all see the DB providing and what I am expecting to support future needs. "protected users" includes more than TV stations in the US. Not sure that helps, but hope so. > > The advantage of having an "well behaved" spectrum profile (contiguous > and without special values like -inf) is that the channel selection > algorithm on the WSDs becomes much simpler and logical. There's no > need to have lots of special boundary condition checks and code paths > that only get triggered under special circumstances. I'd like to > avoid ambiguous interpretations on the device side as much as possible. Certainly ambiguous interpretations on the device side are a bad thing. Some apps are aggregating multiple TV channels to get a logical channel that that can carry a 'wide' data pipe. Other uses can fit many useful channels in one TV channel. In 802.15.4m we divide the TV channel up into multiple physical channels carrying low data rate signals. Right now we assume a peak power level for the TV channel, and we get that value with the start frequency and width (or end frequency) from the database. However, I've heard it proposed to the FCC that we may get different power limits different parts of the TV channel, changing over time, as a protection mechanism for deal with narrow band protected users while allowing effective use of the rest of the TV channel. For what we do, this is a good thing - our physical channel may be less than 200kHz wide. There are a LOT of applications in IoT that need < 200kHz channels, and blocking an entire TV channel to protect a wireless microphone using < 200kHz of it means there are 28 other usable channels not being used - not efficient use of the spectrum. Hope this helps. -Ben > > > Andy Lee | Google Inc. | tvfool@google.com > | 408-230-0522 > > > > On Thu, Sep 19, 2013 at 8:30 AM, Ray Bellis > wrote: > > > On 19 Sep 2013, at 16:21, Andy Lee > > wrote: > > > This actually shows that Ofcom has picked a power threshold on > channel 38 of -33 dBm. If you look at the ACLR numbers for class > 3, 4, and 5 devices, you'll see they are 10 dB apart from each > other and that they all work out to be -33 dBm on channel 38. > > > > The reason there are no limits for class 1 and 2 devices is > because the in-band power on channels 37 and 39 cannot exceed +36 > dBm/8MHz, and therefore the power on channel 38 will naturally be > less than -33 dBm. > > The math bears that out, but nonetheless OFCOM are still > effectively proposing that *no* in-block transmissions are allowed > in that channel. > > Per OFCOM / ETSI device interface requirements it would be > incorrect for us to actually send that value of -33 dBm to a device. > > Ray > > > > > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws --------------020005040402010609070605 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit
On 9/19/2013 9:09 AM, Andy Lee wrote:
The math bears that out, but nonetheless OFCOM are still effectively proposing that *no* in-block transmissions are allowed in that channel.

Same is true for the FCC.  The FCC also assumes that "off" channels are not used by WSDs.
And that means NO intentional radiation in the channel. 

Specifying a low power level like -33 dBm is effectively the same thing as specifying no in-band emissions there.

If you are reading this as "transmitted emissions in band should be lower than -33dBm" then, no, this is not the same as "no emissions" per FCC rules. If one were to intentionally transmit at -33dBm where no intentional emissions are allowed, that would not be the same as "no" under the rules.


Even if someone did try to put an in-band emission there (regardless of how impractical that actually is), it would be too low to cause interference to anyone and no harm has been done to the "RF environment".
Should be a little careful here for a couple reasons.  I've designed and shipped communication systems that operate quite well with transmit power levels intentionally below -33dBm and do very useful things. It's pretty easy to design a receive with sensitivity better than -96dBm, so an intentional radiator at -33dBm near by will be noticed - at 900 MHz your 10dB above sensitivity at 10m and at 54MHz you'd be 10 dB above sensitivity at 100m, possibly. And when it comes to protecting their spectrum, people always use the best propagation model to calculate interfence impact on them :-).  I've probably misunderstood something badly, but -33dBm is certainly enough power to be noticed.

I have tried the "too low to be noticed" argument a few times in the past  in regulatory discussions, and incumbent and/or protected users usually set the threshold closer to -120dBm and usually argue that even at really low TX power, the "aggregate impact" of multiple devices in the "RF Environment" is an unacceptable impact.   We had trouble with this argument when the intentional radiator TX limit was below the maximum unintentional emission limits for most non-transmitting devices (-41.3dBm).

So it would be fairly important to ensure a device does not interpret -33dBm as it's ok to use that channel so long as it's TX power is below -33dBm.

I may be off base here because of  how y'all see the DB providing and what I am expecting to support future needs. "protected users" includes more than TV stations in the US. 

Not sure that helps, but hope so. 



The advantage of having an "well behaved" spectrum profile (contiguous and without special values like -inf) is that the channel selection algorithm on the WSDs becomes much simpler and logical.  There's no need to have lots of special boundary condition checks and code paths that only get triggered under special circumstances.  I'd like to avoid ambiguous interpretations on the device side as much as possible.
Certainly ambiguous interpretations on the device side are a bad thing.

Some apps are aggregating multiple TV channels to get a logical channel that that can carry a 'wide'  data pipe. Other uses can fit many useful channels in one TV channel. In 802.15.4m we divide the TV channel up into multiple physical channels carrying low data rate signals.  Right now we assume a peak power level for the TV channel, and we get that value with the start frequency and width (or end frequency) from the database. However, I've heard it proposed to the FCC that we may get different power limits different parts of the TV channel, changing over time, as a protection mechanism for deal with narrow band protected users while allowing effective use of the rest of the TV channel.  For what we do, this is a good thing - our physical channel may be less than 200kHz wide. There are a LOT of applications  in IoT that need < 200kHz channels,  and blocking an entire TV channel to protect a wireless microphone using < 200kHz of it means there are 28 other usable channels  not being used - not efficient use of the spectrum.  

Hope this helps.  

-Ben



Andy Lee=A0|=A0Google Inc. | =A0tvfool@google.com= =A0|=A0408-230-0522
Andy Lee |  Google Inc. |  tvfool@google.com |  408-230-0522


On Thu, Sep 19, 2013 at 8:30 AM, Ray Bellis <Ray.Bellis@nominet.org.uk> wrote:

On 19 Sep 2013, at 16:21, Andy Lee <tvfool@google.com>
 wrote:

> This actually shows that Ofcom has picked a power threshold on channel 38 of -33 dBm.  If you look at the ACLR numbers for class 3, 4, and 5 devices, you'll see they are 10 dB apart from each other and that they all work out to be -33 dBm on channel 38.
>
> The reason there are no limits for class 1 and 2 devices is because the in-band power on channels 37 and 39 cannot exceed +36 dBm/8MHz, and therefore the power on channel 38 will naturally be less than -33 dBm.

The math bears that out, but nonetheless OFCOM are still effectively proposing that *no* in-block transmissions are allowed in that channel.

Per OFCOM / ETSI device interface requirements it would be incorrect for us to actually send that value of -33 dBm to a device.

Ray





_______________________________________________
paws mailing list
paws@ietf.org
https://www.ietf.org/mailman/listinfo/paws

--------------020005040402010609070605-- From tvfool@google.com Fri Sep 20 13:00:23 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 683F721F9DAA for ; Fri, 20 Sep 2013 13:00:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.012 X-Spam-Level: X-Spam-Status: No, score=0.012 tagged_above=-999 required=5 tests=[AWL=-0.611, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ezmZoA6oPoAe for ; Fri, 20 Sep 2013 13:00:22 -0700 (PDT) Received: from mail-qe0-x235.google.com (mail-qe0-x235.google.com [IPv6:2607:f8b0:400d:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id 006C121F9C46 for ; Fri, 20 Sep 2013 13:00:21 -0700 (PDT) Received: by mail-qe0-f53.google.com with SMTP id jy17so590019qeb.26 for ; Fri, 20 Sep 2013 13:00:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Isypsvdzzyy+8jf1wGZFYTV1E+qHCQYZDIvJhr875sc=; b=LSUAj9J9qytFTdIHH/LttXk4djucmVW3vpnw6Ft73nD8rJU7btfE/ToLZXy9Tmksot prcA3nuB1c5dFz8P2hVmbIiYevaoP7amwTMcHJpwi7hPwljxf6S0krtN78oXPAkUNct9 dxZ9N962SVSCBCjaDQmsVgwk/bYNgt3wnbt8KbSj/7ctMtsJXOyvPzrVm52hBvoSsolu GSvTfYyDaF9w+bxBaWHclvtjyjkdhdzSHT2DObke2KfelHpndGY5vocsl6DzIlGRNPPf IAec59odFNb7bhzb2Diza2sCiJywhc3mgBaxb7P6hiuheL0ZO3n3IqsOvYVrGoUFCyrf lQsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Isypsvdzzyy+8jf1wGZFYTV1E+qHCQYZDIvJhr875sc=; b=f9jOw5B2GkiSx6E8PC4+yeJWTjvrB5zFbP3XgJyigaMKRv1X48rPx3FrujirVdtPU9 +gHTmRFcZrzgwwqX5z1XEpfTTMNMdPOFeqMf4yGKK99OBNFIFO2s4p2r02sjq0nxDTtk eR1HcFi6WAH3fPIeFZUQGIaU468Y2pk0vHcDLzsq8nUVjZPXAdzFI0oVQpdbwu2inG3h xkDCUbPHgL0XVVo0iWvcPChn7t5YppriGrN49KryxrPgyW8ulwlc9a0EKqiAYq6TEANa 47l6d92bQajIb3eH/ZvT5nkLyB172casbH1pVLmsakN9Ns4J1nQW6vxa310CSt+/Unod 2yQA== X-Gm-Message-State: ALoCoQk/FpH7GUN2Fg8UuimuKY2yQZ1tsEmAVhtgKA4rqD7RXWD2OnX6r1qEBmueI/9bzBugrTcraiU1tKi7xNARg3ScNTF8HlqdtlKmgPlsmJi7YxMVq85ndgbaV2Bt+4Goq0E5WxDD7ZEyONlr6aeqd3l5Drx8bLeFkLHVaw1ANqwqmJyksv9DSDiFQJJSW1Jby/V816Km MIME-Version: 1.0 X-Received: by 10.224.45.197 with SMTP id g5mr7796648qaf.2.1379707221201; Fri, 20 Sep 2013 13:00:21 -0700 (PDT) Received: by 10.229.207.8 with HTTP; Fri, 20 Sep 2013 13:00:20 -0700 (PDT) In-Reply-To: References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DEA4362@wds-exc1.okna.nominet.org.uk> <53F00E5CD8B2E34C81C0C89EB0B4FE732DEA5B73@wds-exc1.okna.nominet.org.uk> <53F00E5CD8B2E34C81C0C89EB0B4FE732DEA5FE1@wds-exc1.okna.nominet.org.uk> Date: Fri, 20 Sep 2013 13:00:20 -0700 Message-ID: From: Andy Lee To: "Benjamin A. Rolfe" Content-Type: multipart/related; boundary=001a11c35d14d068a904e6d61e3b Cc: Protocol to Access White Space database Subject: Re: [paws] Spectrum encoding discussion X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 20:00:23 -0000 --001a11c35d14d068a904e6d61e3b Content-Type: multipart/alternative; boundary=001a11c35d14d068a704e6d61e3a --001a11c35d14d068a704e6d61e3a Content-Type: text/plain; charset=ISO-8859-1 Hi Ben, And that means NO intentional radiation in the channel. If you are reading this as "transmitted emissions in band should be lower > than -33dBm" then, no, this is not the same as "no emissions" per FCC > rules. If one were to intentionally transmit at -33dBm where no intentional > emissions are allowed, that would not be the same as "no" under the rules. There is certainly no intention to encourage any malicious behavior. In general, we expect devices to be trying to do the right thing and just need some information to understand where the boundaries are. These boundaries include both intentional and unintentional emissions. Various modulation types have known spectral profiles, including both in-band and out-of-band emissions. Knowing where the "shelf" is on the adjacent channel makes it possible to match that with the "skirt" of the intended modulation pattern. The "skirt" is not part of the intended emission, but is important in trying to avoid causing interference on adjacent channels. A crude example of this is shown in the following image: [image: Inline image 1] Best regards, Andy Lee | Google Inc. | tvfool@google.com | 408-230-0522 On Fri, Sep 20, 2013 at 3:07 AM, Benjamin A. Rolfe wrote: > > On 9/19/2013 9:09 AM, Andy Lee wrote: > > The math bears that out, but nonetheless OFCOM are still effectively >> proposing that *no* in-block transmissions are allowed in that channel. > > > Same is true for the FCC. The FCC also assumes that "off" channels are > not used by WSDs. > > And that means NO intentional radiation in the channel. > > > Specifying a low power level like -33 dBm is effectively the same thing > as specifying no in-band emissions there. > > > If you are reading this as "transmitted emissions in band should be lower > than -33dBm" then, no, this is not the same as "no emissions" per FCC > rules. If one were to intentionally transmit at -33dBm where no intentional > emissions are allowed, that would not be the same as "no" under the rules. > > > > Even if someone did try to put an in-band emission there (regardless of > how impractical that actually is), it would be too low to cause > interference to anyone and no harm has been done to the "RF environment". > > Should be a little careful here for a couple reasons. I've designed and > shipped communication systems that operate quite well with transmit power > levels intentionally below -33dBm and do very useful things. It's pretty > easy to design a receive with sensitivity better than -96dBm, so an > intentional radiator at -33dBm near by will be noticed - at 900 MHz your > 10dB above sensitivity at 10m and at 54MHz you'd be 10 dB above sensitivity > at 100m, possibly. And when it comes to protecting their spectrum, people > always use the best propagation model to calculate interfence impact on > them :-). I've probably misunderstood something badly, but -33dBm is > certainly enough power to be noticed. > > I have tried the "too low to be noticed" argument a few times in the past > in regulatory discussions, and incumbent and/or protected users usually set > the threshold closer to -120dBm and usually argue that even at really low > TX power, the "aggregate impact" of multiple devices in the "RF > Environment" is an unacceptable impact. We had trouble with this argument > when the intentional radiator TX limit was below the maximum unintentional > emission limits for most non-transmitting devices (-41.3dBm). > > So it would be fairly important to ensure a device does not interpret > -33dBm as it's ok to use that channel so long as it's TX power is below > -33dBm. > > I may be off base here because of how y'all see the DB providing and what > I am expecting to support future needs. "protected users" includes more > than TV stations in the US. > > Not sure that helps, but hope so. > > > > The advantage of having an "well behaved" spectrum profile (contiguous > and without special values like -inf) is that the channel selection > algorithm on the WSDs becomes much simpler and logical. There's no need to > have lots of special boundary condition checks and code paths that only get > triggered under special circumstances. I'd like to avoid ambiguous > interpretations on the device side as much as possible. > > Certainly ambiguous interpretations on the device side are a bad thing. > > Some apps are aggregating multiple TV channels to get a logical channel > that that can carry a 'wide' data pipe. Other uses can fit many useful > channels in one TV channel. In 802.15.4m we divide the TV channel up into > multiple physical channels carrying low data rate signals. Right now we > assume a peak power level for the TV channel, and we get that value with > the start frequency and width (or end frequency) from the database. > However, I've heard it proposed to the FCC that we may get different power > limits different parts of the TV channel, changing over time, as a > protection mechanism for deal with narrow band protected users while > allowing effective use of the rest of the TV channel. For what we do, this > is a good thing - our physical channel may be less than 200kHz wide. There > are a LOT of applications in IoT that need < 200kHz channels, and > blocking an entire TV channel to protect a wireless microphone using < > 200kHz of it means there are 28 other usable channels not being used - not > efficient use of the spectrum. > > Hope this helps. > > -Ben > > > > Andy Lee | Google Inc. | tvfool@google.com | 408-230-0522 > > > On Thu, Sep 19, 2013 at 8:30 AM, Ray Bellis wrote: > >> >> On 19 Sep 2013, at 16:21, Andy Lee >> wrote: >> >> > This actually shows that Ofcom has picked a power threshold on channel >> 38 of -33 dBm. If you look at the ACLR numbers for class 3, 4, and 5 >> devices, you'll see they are 10 dB apart from each other and that they all >> work out to be -33 dBm on channel 38. >> > >> > The reason there are no limits for class 1 and 2 devices is because the >> in-band power on channels 37 and 39 cannot exceed +36 dBm/8MHz, and >> therefore the power on channel 38 will naturally be less than -33 dBm. >> >> The math bears that out, but nonetheless OFCOM are still effectively >> proposing that *no* in-block transmissions are allowed in that channel. >> >> Per OFCOM / ETSI device interface requirements it would be incorrect for >> us to actually send that value of -33 dBm to a device. >> >> Ray >> >> >> > > > _______________________________________________ > paws mailing listpaws@ietf.orghttps://www.ietf.org/mailman/listinfo/paws > > > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > > --001a11c35d14d068a704e6d61e3a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Ben,

And that means NO intentional= radiation in the channel.=A0=A0
If you are read= ing this as "transmitted emissions in band should be lower than -33dBm= " then, no, this is not the same as "no emissions" per FCC r= ules. If one were to intentionally transmit at -33dBm where no intentional = emissions are allowed, that would not be the same as "no" under t= he rules.

=
There is certainly no in= tention to encourage any malicious behavior. =A0In general, we expect devic= es to be trying to do the right thing and just need some information to und= erstand where the boundaries are. =A0These boundaries include both intentio= nal and unintentional emissions.

Various modulation types have known spectral profiles, in= cluding both in-band and out-of-band emissions. =A0Knowing where the "= shelf" is on the adjacent channel makes it possible to match that with= the "skirt" of the intended modulation pattern. =A0The "ski= rt" is not part of the intended emission, but is important in trying t= o avoid causing interference on adjacent channels.

A crude example of this is shown in the following image:<= /font>

3D"I=

Best regards,


Andy = Lee=A0| =A0Google Inc. |=A0tvfool@google.com=A0| =A0408-230-0522

On Fri, Sep 20, 2013 at 3:07 AM, Benjami= n A. Rolfe <ben@blindcreek.com> wrote:
=20 =20 =20

On 9/19/2013 9:09 AM, Andy Lee wrote:
The math bears that out, but nonetheless=A0OFCOM=A0are still effectively proposing that *no* in-block transmissions are allowed in that channel.

Same is true for the FCC. =A0The FCC also assumes that "o= ff" channels are not used by WSDs.
And that means NO intentional radiation in the channel.=A0

Specifying a low power level like -33 dBm is effectively the same thing as specifying no in-band emissions there.

If you are reading this as "transmitted emissions in band should b= e lower than -33dBm" then, no, this is not the same as "no emis= sions" per FCC rules. If one were to intentionally transmit at -33dBm where no intentional emissions are allowed, that would not be the same as "no" under the rules.



Even if someone did try to put an in-band emission there (regardless of how impractical that actually is), it would be too low to cause interference to anyone and no harm has been done to the "RF environment".
Should be a little careful here for a couple reasons.=A0 I've desig= ned and shipped communication systems that operate quite well with transmit power levels intentionally below -33dBm and do very useful things. It's pretty easy to design a receive with sensitivity bette= r than -96dBm, so an intentional radiator at -33dBm near by will be noticed - at 900 MHz your 10dB above sensitivity at 10m and at 54MHz you'd be 10 dB above sensitivity at 100m, possibly. And when it comes to protecting their spectrum, people always use the best propagation model to calculate interfence impact on them :-).=A0 I'= ve probably misunderstood something badly, but -33dBm is certainly enough power to be noticed.

I have tried the "too low to be noticed" argument a few times= in the past=A0 in regulatory discussions, and incumbent and/or protected users usually set the threshold closer to -120dBm and usually argue that even at really low TX power, the "aggregate impact" of m= ultiple devices in the "RF Environment" is an unacceptable impact.=A0= =A0 We had trouble with this argument when the intentional radiator TX limit was below the maximum unintentional emission limits for most non-transmitting devices (-41.3dBm).

So it would be fairly important to ensure a device does not interpret -33dBm as it's ok to use that channel so long as it's= TX power is below -33dBm.

I may be off base here because of=A0 how y'all see the DB providing and what I am expecting to support future needs. "protected users&= quot; includes more than TV stations in the US.=A0

Not sure that helps, but hope so.=A0



The advantage of having an "well behaved" spectrum profile=A0(contiguous and without special values like -inf)=A0is that the channel selection algorithm on the WSDs becomes much simpler and logical. =A0There's no need to have lots of speci= al boundary condition checks and code paths that only get triggered under special circumstances. =A0I'd like to avoid ambiguous interpretations on the device side as much as possible.
Certainly ambiguous interpretations on the device side are a bad thing.

Some apps are aggregating multiple TV channels to get a logical channel that that can carry a 'wide'=A0 data pipe. Other uses c= an fit many useful channels in one TV channel. In 802.15.4m we divide the TV channel up into multiple physical channels carrying low data rate signals.=A0 Right now we assume a peak power level for the TV channel, and we get that value with the start frequency and width (or end frequency) from the database. However, I've heard it proposed to th= e FCC that we may get different power limits different parts of the TV channel, changing over time, as a protection mechanism for deal with narrow band protected users while allowing effective use of the rest of the TV channel.=A0 For what we do, this is a good thing - our physical channel may be less than 200kHz wide. There are a LOT of applications=A0 in IoT that need < 200kHz channels,=A0 and blocking an entire TV channel to protect a wireless microphone using < 200kHz of it means there are 28 other usable channels=A0 not being used - not efficient use of the spectrum.=A0=A0

Hope this helps.=A0=A0

-Ben



Andy Lee=A0| =A0Google Inc. | =A0tvfool@google.com=A0| =A0408-230-0522


On Thu, Sep 19, 2013 at 8:30 AM, Ray Bellis <Ray.Bellis@nominet.org.uk> wrote:

On 19 Sep 2013, at 16:21, Andy Lee <tvfool@google.com>
=A0wrote:

> This actually shows that Ofcom has picked a power threshold on channel 38 of -33 dBm. =A0If you look at the ACLR numbers for class 3, 4, and 5 devices, you'll see they are 10 dB apart from each other and that they all work out to be -33 dBm on channel 38.
>
> The reason there are no limits for class 1 and 2 devices is because the in-band power on channels 37 and 39 cannot exceed +36 dBm/8MHz, and therefore the power on channel 38 will naturally be less than -33 dBm.

The math bears that out, but nonetheless OFCOM are still effectively proposing that *no* in-block transmissions are allowed in that channel.

Per OFCOM / ETSI device interface requirements it would be incorrect for us to actually send that value of -33 dBm to a device.

Ray





________________________________________=
_______
paws mailing list
paws@ietf.org
ht=
tps://www.ietf.org/mailman/listinfo/paws


_______________________________________________
paws mailing list
paws@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/paws


--001a11c35d14d068a704e6d61e3a-- --001a11c35d14d068a904e6d61e3b Content-Type: image/png; name="Intentional vs Unintentional signal.png" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: ii_1413cf17c2d2661a iVBORw0KGgoAAAANSUhEUgAAAZAAAAGQCAYAAACAvzbMAAAAAXNSR0IArs4c6QAAFFxJREFUeNrt 3XuQlXXhx/HPIfzhWikgCaMToIhBRjqZOfaPNTbWFpNNpSNdtGGyZNSAdMyw0ZhRCC21zHI0Z/Cv bOoPxy5qJuBfTTOMIpe4tKAmeCmSaMIFlH1+fzyd3QX2xrrLuezrNbMDu+e6z3nO8z7f79nzPJWi KIoAwBEaZREAICAACAgAAgKAgACAgAAgIEdPpVKxEAD6C0ilUun8mjBhQi6++OI8//zzlhoA/Y9A iqJIURTZtGlTZs6cmcsvv9xSA2DgU1gTJkzIokWL8uyzzyZJ9u3blwULFmTSpEmZNGlSFixYkH37 9mX69OnZvHlzkmTHjh0ZNWpUXn755STJpk2bMn369M7r7OjoyK233ppTTz0148ePz9y5c7Nnz57O 0c9dd92V9773vRk1que72d/l77vvvkydOjUtLS05//zzs379+jz33HOZNm1aun8AvyiKTJs2LWvX ru33ervrbRlUb//222/PxIkTc+KJJ+aaa67J/v37B3TfAZoqIDt37sySJUty9tlnJ0luu+22bNiw IatXr87q1auzdu3aLFmyJK2trVm1alWS5NFHH82YMWPyu9/9LkmycuXKfPrTn+68zrvvvjurVq3K ihUrsnXr1rz55pu5+eabO09/+umn85e//CUdHR093qf+Lv/EE09k1apV2blzZ1pbW3PVVVflrLPO ytixY7NixYrO8z311FMZN25cPvjBDw7oeqt6WwZVTz75ZJ555pmsXbs2mzdvztKlSwd83wHqXtGH JJ1f48ePL2bPnl20tbUVRVEUp512WrFhw4bO865bt66YNm1a8Yc//KGYM2dOURRF0draWtxwww3F 7Nmzi6IoiksvvbR47LHHOi8zY8aMYtOmTZ3fv/rqq8WUKVM6b/uFF17o6+71e/lXXnml87Q9e/YU LS0tRVEUxU9/+tPi0ksv7TztkksuKe69994BX29Vb8uger7up61fv77ztP5uA6ARVPramWKlUklv J7e0tGTXrl059thjkyR79+7NuHHj8vrrr2fWrFlZs2ZNJk+enG3btmXatGl56aWXcuaZZ2bjxo2d lznuuOM6p3WKokhHR0dGjRqVAwcOpFKppKOjo8+/eurv8ofe9+rP/v3vf2fKlCnZunVriqLI6aef nhdffDFjx449ouvtbRm0t7enUqmkvb29x9P6uw2ApprCOtTJJ5+cbdu2dX7f1taWU045JS0tLZk+ fXruvffenHvuuRk7dmzOOeec3HPPPZk5c2bnBjVJJk+enLa2trz11ls5cOBAiqI4aAPa35/M9nf5 3owdOzaf+cxnsnz58ixfvjyzZ8/ujMeRXG9vy6Cq+2nbtm076LTB3neAhg/InDlzMn/+/Gzfvj3b t2/P/PnzM2fOnCRJa2trli5dmosuuihJctFFF2Xp0qVpbW096DrmzZuXK6+8Mhs3bsz+/fuzbt26 XHbZZQO+D2/n8nPnzs0DDzyQX/ziF5k7d+6grrevZZAkCxcuzI4dO7Jjx44sXLgwX/7yl4fsdweo +/dAetPe3l5ce+21xcSJE4uJEycW1157bdHe3l4URVFs2bKlSFI899xzRVEUxZo1a4okxd/+9reD ruPAgQPFT37yk2LGjBnFmDFjilmzZhWPPPJIv7c92Mt3/1lHR0cxderUYurUqUVHR8egrrevZZCk WLZsWXHSSScV48aNK+bNm1fs3bt3QLcB0PDvgTB4fb1/BDCip7AAGNlGWwS83ZEWjc1IGSMQT0oA AQGg/pnCwqhrBDL1iBEIACNsBFKpJAN9tXok56XhLV5sGfTnllssAxphBFKpJA88cPjPH3usPK2+ xuQD+9lw3dbR/D2rXwB1G5Akuf/+5NB9NN1+e2P8ds04cikKIzKgLvQ/hXXBBckvf5l85Svl97// fTJjRvK/Y34kSfbtS77zneThh8vvL7ssWbYsGTMm2b8/WbiwPO2YY5Lrrjv8FfWhG8Tepq22bEkW LUpWrkzeeiu58MIycO95z8Ejg+plu19PX/exUkl+/vPkBz9IXnstOfvscuT1gQ/0Pvqo/vv668kZ ZyQbNyYTJpQ/e/PN5JRTkvXrk5NOKs+7bFnyox+V93vOnOTOO5P/+7/y/B0dyZIlyYMPJrt3J5/7 XHLPPck73zmiV84rrvAErXroIcuARhyBXH11ufGrbogXL07mzz/4PLfdlmzYkKxeXX6tXVtuEJPy 3y1byp+tXl1Ofw3WJZeU92f79uTvfy830t/9btd96+vVeV/3MUmeeKKM4s6dSWtrctVVfY9qqrc1 blwZo/vv7zrPypXJRz5SxqPqySeTZ54pb3fz5qTbwaVy993lba9YkWzdWgbIwaWAOtf3vrCqr+Av vji5/PLyFfPPftb1Hkj1otOmJb/9bfL+95ffr19fvopua0tOPz159NGDT5s1q+dRQk8jkL7eRP/P f5Izz0xeeqn/6+nrPlYqySuvJJMmlae98UY5mnjjjb6XS9W2bcnHP15e1zHHJPPmlSO36t51K5Uy XtXb3rChXKZtbeX3M2cmjzySvO995fevvZacd17ywgvp97Gp9QrU7b2Yofgz3u5vohuB9DwCGYo3 0Yf6cUNAet9I/elPyQ03lN8vWZJ88pMHb8BaWpJdu5LqsT727i1fmbe393xaS8vgArJ6dTkN9eyz 5XUmyTveUU4L9Xc9fd3HI5lG6+20Sy5JPv/5MhozZ5b3saWl6/zt7T3fdpIcd1w51Vcd2XR0JKNG Hf7eU5MH5NC/wBKQ3qew3m5EBISjM4WVJJ/4RLnRa29P/neMj4OcfHL5Kryqra2cXkrKf7uftnXr wZc99tiDX+m/+mrv9+Oyy8qtSltbGY1//atrI9vfXyX1dR+P/Nl3+M+uvz758Y+TP/85Of/8rnh0 H6V0/3/32548uet3OnCgDIODSwFNEZAk+etfy6+eNp5z5pTvi2zfXn7Nn1/+LEm+9KXyTfQdO8qv BQsOvuw55yQ//GGyZ0/y/PPJN7/Z+33Ysyc5/vjyzeUXX0y+8Y2u0yZMKN/I7k1f9/FI9XRb551X Tl8tWpR89auHX6b7Mli4MOl2cKnMm5dceWV5nfv3J+vWdU1/jVBGH5YHzRSQvnzve+W0zYc/XH6d eWZy003laTfdlJx2Wvm+x4c+dPgI5r77yvdUJkwo30f41Kd6v50HH0xuvDF597vL815wQddpN96Y fPSjvY9E+rqPR6q327r++nKE9bGPHX6ZCy8sf/9Zs8r3YxYt6jrt2muTz362nAI7/vgyLr3Frftn QHweBKghB5QaSvfdV46ili07fKPfpIt5uN4D8Yr7cEP5Rrr3QBgKdqY4VHbvTu66q/xTXAABYYAv 58q/mrrnnsG/MQ8gICNQf1MApgiAJmR37gAICAACAoCAQP8cSMryQkAG5Eg+++ZzcgANGBAHJKy/ qD3+ePmh9paWcvdeX/96uUuwZuJDhJYLTTICcUDC+nLnneUeU/75z2TNmmT0aBsWoE4DUj0gYVX1 gITd7dtX7iNx0qTya8GC8mdJuW/Aq69OTjyxPO2OOwY/ctiyJfniF8vrOuGEctdRO3f2vmuo7v/v 6z5WKuVeSKZOLV/Zn39+ebiQvkYf1dvatas8IOLOnV3nefPN8lhS//hH13lvvz2ZOLG879dc07X3 9qTce/uttyannpqMH5/MnVvuN7Inf/xjebyrd72rvI077jj44JAAdRMQByTseVRTLwckXLEiOfdc KzJw9PW5M0UHJOx7uVTV4oCESXnMqi98oXxf5IwzarQCDdFO+exIcWCGaoeKdqbIURmBJOXexm+7 Lfn+9w8/nEeSvPxyucf2qtNPLw97kZT/HnraYK1eXb6BPH58uVE+4YRywz8Qfd3HpCseSXmAwOrB AgfitNPKEcdvflOGZeXKMhCHnqdq2rSDb/vFF8sQjh5dHmBx0qQyin1ZtaoM4MMP1y4ewMg2oH1h VQ9ImPR9QMLqK+yeDkhYPa23AxIed1z5fX8HJLz55uTXvy7jsXt3+Z5C9VV+X/q6j0f+6u3wn11/ fTm1N2VK7wckrN52TwckfPzx8j2YgfjVr5Jvf7sc2Z1zTh2uVYP5kMKqbsd2meKJ2fty6v7N00d+ +aE4oDocyQgkcUDC7mp5QMI77ywPT//UU3UaD0BAjoQDEnaNQob7gITXXVf+AcHMmV1/CVapJP/9 r5UZOLockXAIjcADEvb8Zuwg3hFffPcJXRf5mnWpNw8t7/r/LQt2D/BCh7/z7k106mYEQtcBCb/1 LcviSHWPB5YbjcMBpYbkVbgDEgICwiA4IOHQMX3V//LpPo0FtWQKCwABAUBAABAQAAQEAAQEAAEB QEAAEBDol91xWH4ICAACArVhNyaWEwICgIAAgIAAICAACAgAAgKAgACAgAAgIDQRu+GwHBEQAAQE asPuOSwvBAQAAQEAAQFAQAAQEAAEBAABAQABAUBAaCJ2v2F5IiAACAjUht1yWG4ICAACAgACAoCA ACAgAAgIAAICAAICgIAAICCMdPbbZLkiIAAICNSG/TlZfggIAAICAAICgIAAICAACAgAAgIAAgKA gNBE7G7D8kVAABAQqA274bAcERAABAQABAQAAQFAQAAQEAAEBAAEBAABoYnYzYbljIAAgIBQG3a/ YXkiIAAICAAICAACAoCAACAgAAgIAAgIAAJCE7F7DcsbAQEAAaE27HbDckVAABAQABAQAAQEAAEB QEAAQEAAEBAABAQAAWGks18myx0BAQABoTbsr8nyRUAAEBAAEBAABAQAAQFAQABAQAAQEAAEhCZi dxqWPwICAAJCbdjNhuWMgACAgAAgIAAICAACAoCAAICAACAgAAgITWTxqgssBI8DAgIAAkIN2L2G 5Y2AAICAACAgAAgIAAICgIAAgIAAICAACAhNxO4zPB4ICAAICLVhtxqWOwICAAICgIAAICAACAgA AgIAAgKAgAAgIAAICCOd/S55XBAQABAQasP+mCx/BAQABAQAAQGgRkZXKhVLAUYw2wCMQAAQEADq 3+iiKCwFGGE87zECAaB2IxCLoI4sXtz4v4LdZdT34/PxVbnlY083/i9yyy0eTAGhWcIBNXnOCImA CEdzuuIKD3G9PA4PPSQkCMjICEcjb3l3ndD1/7M91HXh7LOSNd3Xr6mN+7v0VkIhERDh8JIdBvQc ERIBEQ7hACEREIQDhERAEA4QEgREOEBIhERAhAMQEgERDkBIGl6lsFc14RiqxXL3CQcvhq9ZVerF Q8sP/v6WBbtH6ILo5xOVQmIEIhyAEYkRiHA06AjE6KO+RyEjdgRiRGIEIhyAEYmACAcgJAIiHICQ CIhwCAcIiZAIiHAAQiIgwgEIiYAIByAkAiIcgJCMwJA09wcJhePoLWq7Mal7dmcynAt3ZH4gsTlH IMIBGJEYgQhH441AjD4aYxRiBGJEYgQiHIARiYAIByAkAiIcAE0eksYKiHAAQiIgwgEISWOHpL4D IhyAkNRtSOozIMIBCEndh6S+AiIcgJA0TEjqIyDCAdBwIantJ9GFoynYD1bjsD+sRn3g6vOT7bUZ gQgHQMOPSI7uCEQ4mn4EYvTRWKMQIxAjkvofgQgHQNONSIY3IMIB0LQhGZ6ACAdA04dkaAMiHAAj JiRDExDhABhxIXl7AREOgBEbksEFRDgARnxIjiwgwgEgJP8zsA8SCge9rRp2Y9Jw7M6ErpXh7X0g cbRwABiRDGZE0vMIRDgYxAjE6KMxRyFGIAx2RDJaOAAYzIhktHAAMJiQjO4zHsIBICS9hGS0cAAw mJCMOuxM4sEAHfonvHgcGQEh6daI0YIBwGBGJKMsCYZkffqaZeDxYqQREMA0FgKCDQ4gIMAwM42F gGBDBAgIjcH0lccVBAQAAaE2TF95/BAQGBDTHB5fEBAABITaMP3hcURAADqZxkJAsGEBBAQYXqax EBBscAABob6YvvJ4g4AAICDUhukrjysICANiOsPjDgICgIBQG6Y5PL4gIEC/TGMhINiAAAICDC/T WAgINiyAgFAbpq+wHiAgAAgItWH6yuMNAsKAmLbA+oCAACAg1IbpDI87CAgwaKaxEBBsKAABAYaX aSwEBBsQQEAYXqavsH4gIAAICLVh+grrAQLCgJiewHqCgAAgINSGaQusDwgIMORMYyEg2CAAAgIM L9NYCAg2FICAMDRMX2G9QUAAEBBqw/QV1g8EhAExDYH1BwEBQECoDdMTWE8QEOCoMY0lIHjiAwgI MLxMYyEg2CAAAsKRMX2F9QkBAUBAqA3TV1hvEBAGxHQD1isEBAABoTZMQ2D9QUCAmjONJSB4ggMI CDC8TGMJCJ74AAJCz0xfYT1DQAAQEGrD9BXWJwSEATGtgPUNAQFAQKgN0w1YrxAQoG6ZxhIQPJEB BAQYXqaxBARPcAABGelMX2H9Q0AAEBBqw/QV1jMEhAExfYD1EAEBQECoDdMKWN8QEKDhmMYSEDxh AQQEGF6msQQET2QAARkpTF9hvURAABAQasP0FdY/BIQBMU2A9RMBAUBAqA3TB1gPERCgaZjGEhA8 MQEBARheprEEBE9YAAFpNqavsL4iIAAICLVh+grrJQKC6QCstwgIAAJCHTNNgPUTAQGanmksAcET EBAQgOFlGktA8MQEBIRGZfoK6zECAoCAUBumr7C+IiAY9mN9RkAAEBBMB4D1FgEB6o9pLAHBEw0Q EIDhZRpLQPAEBASEemf6Cus3AgKAgFAbpq+wHiMgGN6D9VxAABAQDPvB+oyAAI3DNJaA4AkFCAjA 8DKNJSB4ogECQr0wfYX1HgEBQECoDdNXWL8REAzjwfovIAAICIb3YD1HQIDGZxpLQPDEAQQEYHiZ xhIQPKEAAeFoM30Fng8CAoCAUBumr7DeIyAYroPnhYAAICAYxoP1HwEBmpdpLAHBEwQQEIDhZRpL QPDEAQSE4WL6CjxPBASApvf/5iHIqNxWR4QAAAAASUVORK5CYII= --001a11c35d14d068a904e6d61e3b-- From Gabor.Bajko@nokia.com Fri Sep 20 14:02:19 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F3C621F9E3B for ; Fri, 20 Sep 2013 14:02:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.223 X-Spam-Level: X-Spam-Status: No, score=-4.223 tagged_above=-999 required=5 tests=[AWL=-1.225, BAYES_50=0.001, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0zxyo7p+qzNz for ; Fri, 20 Sep 2013 14:02:11 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 6832E21F9DF7 for ; Fri, 20 Sep 2013 14:02:09 -0700 (PDT) Received: from smtp.mgd.nokia.com ([65.54.30.50]) by mgw-sa01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r8KKsdvC009543 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Fri, 20 Sep 2013 23:54:39 +0300 Received: from 008-AM1MPN1-006.mgdnok.nokia.com ([169.254.6.131]) by 008-AM1MMR2-016.mgdnok.nokia.com ([65.54.30.50]) with mapi id 14.03.0136.001; Fri, 20 Sep 2013 20:54:38 +0000 From: To: , Thread-Topic: [paws] Spectrum encoding discussion Thread-Index: AQHOtLJJlV0A7sF1Y0u4PChODFE3GpnM2N2AgABHaoCAAAbdgIAAB0+AgAACXwCAAAsCAIABLRqAgAClvgCAAAR7EA== Date: Fri, 20 Sep 2013 20:54:38 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E476053422B0@008-AM1MPN1-006.mgdnok.nokia.com> References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DEA4362@wds-exc1.okna.nominet.org.uk> <53F00E5CD8B2E34C81C0C89EB0B4FE732DEA5B73@wds-exc1.okna.nominet.org.uk> <53F00E5CD8B2E34C81C0C89EB0B4FE732DEA5FE1@wds-exc1.okna.nominet.org.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [69.181.65.212] Content-Type: multipart/related; boundary="_004_1ECAFF543A2FED4EA2BEB6CACE08E476053422B0008AM1MPN1006mg_"; type="multipart/alternative" MIME-Version: 1.0 X-Nokia-AV: Clean Cc: paws@ietf.org Subject: Re: [paws] Spectrum encoding discussion X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 21:02:19 -0000 --_004_1ECAFF543A2FED4EA2BEB6CACE08E476053422B0008AM1MPN1006mg_ Content-Type: multipart/alternative; boundary="_000_1ECAFF543A2FED4EA2BEB6CACE08E476053422B0008AM1MPN1006mg_" --_000_1ECAFF543A2FED4EA2BEB6CACE08E476053422B0008AM1MPN1006mg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Aren't we talking past each other in this thread? If the rules are supposed to specify what is the max intended power level a= device can put into a channel (available or not), then I also think this i= s what the DB should communicate to the device. If Ofcom specifies that the max leakage into an unavailable channel is -33d= bm, I assume the device will not be certified if it leaks more. If the devi= ce supports multiple modulation types and one of them leaks more than what = is permitted in that regulatory domain, then the device will need to know i= t, and in that regulatory domain avoid using that particular modulation typ= e. How does the device come to know it? Andy proposes the DB to indicate th= at level for the unavailable channels. Others folks seem to suggest a devic= e built to operate under a certain ruleset has to implicitly know it. Another way of looking at it might be to say that the max level of permitte= d unintentional leakage into an adjacent channel is part of the rulesetInfo= , and the spectrum response only lists the available channels. Could this b= e a way forward? - gabor From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext= Andy Lee Sent: Friday, September 20, 2013 1:00 PM To: Benjamin A. Rolfe Cc: Protocol to Access White Space database Subject: Re: [paws] Spectrum encoding discussion Hi Ben, And that means NO intentional radiation in the channel. If you are reading this as "transmitted emissions in band should be lower t= han -33dBm" then, no, this is not the same as "no emissions" per FCC rules.= If one were to intentionally transmit at -33dBm where no intentional emiss= ions are allowed, that would not be the same as "no" under the rules. There is certainly no intention to encourage any malicious behavior. In ge= neral, we expect devices to be trying to do the right thing and just need s= ome information to understand where the boundaries are. These boundaries i= nclude both intentional and unintentional emissions. Various modulation types have known spectral profiles, including both in-ba= nd and out-of-band emissions. Knowing where the "shelf" is on the adjacent= channel makes it possible to match that with the "skirt" of the intended m= odulation pattern. The "skirt" is not part of the intended emission, but i= s important in trying to avoid causing interference on adjacent channels. A crude example of this is shown in the following image: [Inline image 1] Best regards, Andy Lee | Google Inc. | tvfool@google.com | 408-230-0522 On Fri, Sep 20, 2013 at 3:07 AM, Benjamin A. Rolfe > wrote: On 9/19/2013 9:09 AM, Andy Lee wrote: The math bears that out, but nonetheless OFCOM are still effectively propos= ing that *no* in-block transmissions are allowed in that channel. Same is true for the FCC. The FCC also assumes that "off" channels are not= used by WSDs. And that means NO intentional radiation in the channel. Specifying a low power level like -33 dBm is effectively the same thing as = specifying no in-band emissions there. If you are reading this as "transmitted emissions in band should be lower t= han -33dBm" then, no, this is not the same as "no emissions" per FCC rules.= If one were to intentionally transmit at -33dBm where no intentional emiss= ions are allowed, that would not be the same as "no" under the rules. Even if someone did try to put an in-band emission there (regardless of how= impractical that actually is), it would be too low to cause interference t= o anyone and no harm has been done to the "RF environment". Should be a little careful here for a couple reasons. I've designed and sh= ipped communication systems that operate quite well with transmit power lev= els intentionally below -33dBm and do very useful things. It's pretty easy = to design a receive with sensitivity better than -96dBm, so an intentional = radiator at -33dBm near by will be noticed - at 900 MHz your 10dB above sen= sitivity at 10m and at 54MHz you'd be 10 dB above sensitivity at 100m, poss= ibly. And when it comes to protecting their spectrum, people always use the= best propagation model to calculate interfence impact on them :-). I've p= robably misunderstood something badly, but -33dBm is certainly enough power= to be noticed. I have tried the "too low to be noticed" argument a few times in the past = in regulatory discussions, and incumbent and/or protected users usually set= the threshold closer to -120dBm and usually argue that even at really low = TX power, the "aggregate impact" of multiple devices in the "RF Environment= " is an unacceptable impact. We had trouble with this argument when the i= ntentional radiator TX limit was below the maximum unintentional emission l= imits for most non-transmitting devices (-41.3dBm). So it would be fairly important to ensure a device does not interpret -33dB= m as it's ok to use that channel so long as it's TX power is below -33dBm. I may be off base here because of how y'all see the DB providing and what = I am expecting to support future needs. "protected users" includes more tha= n TV stations in the US. Not sure that helps, but hope so. The advantage of having an "well behaved" spectrum profile (contiguous and = without special values like -inf) is that the channel selection algorithm o= n the WSDs becomes much simpler and logical. There's no need to have lots = of special boundary condition checks and code paths that only get triggered= under special circumstances. I'd like to avoid ambiguous interpretations = on the device side as much as possible. Certainly ambiguous interpretations on the device side are a bad thing. Some apps are aggregating multiple TV channels to get a logical channel tha= t that can carry a 'wide' data pipe. Other uses can fit many useful channe= ls in one TV channel. In 802.15.4m we divide the TV channel up into multipl= e physical channels carrying low data rate signals. Right now we assume a = peak power level for the TV channel, and we get that value with the start f= requency and width (or end frequency) from the database. However, I've hear= d it proposed to the FCC that we may get different power limits different p= arts of the TV channel, changing over time, as a protection mechanism for d= eal with narrow band protected users while allowing effective use of the re= st of the TV channel. For what we do, this is a good thing - our physical = channel may be less than 200kHz wide. There are a LOT of applications in I= oT that need < 200kHz channels, and blocking an entire TV channel to prote= ct a wireless microphone using < 200kHz of it means there are 28 other usab= le channels not being used - not efficient use of the spectrum. Hope this helps. -Ben Andy Lee | Google Inc. | tvfool@google.com | 408-230-0522 On Thu, Sep 19, 2013 at 8:30 AM, Ray Bellis > wrote: On 19 Sep 2013, at 16:21, Andy Lee > wrote: > This actually shows that Ofcom has picked a power threshold on channel 38= of -33 dBm. If you look at the ACLR numbers for class 3, 4, and 5 devices= , you'll see they are 10 dB apart from each other and that they all work ou= t to be -33 dBm on channel 38. > > The reason there are no limits for class 1 and 2 devices is because the i= n-band power on channels 37 and 39 cannot exceed +36 dBm/8MHz, and therefor= e the power on channel 38 will naturally be less than -33 dBm. The math bears that out, but nonetheless OFCOM are still effectively propos= ing that *no* in-block transmissions are allowed in that channel. Per OFCOM / ETSI device interface requirements it would be incorrect for us= to actually send that value of -33 dBm to a device. Ray _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws --_000_1ECAFF543A2FED4EA2BEB6CACE08E476053422B0008AM1MPN1006mg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Aren’t we talking p= ast each other in this thread?

If the rules are supposed= to specify what is the max intended power level a device can put into a ch= annel (available or not), then I also think this is what the DB should communicate to the device.

If Ofcom specifies that t= he max leakage into an unavailable channel is -33dbm, I assume the device w= ill not be certified if it leaks more. If the device supports multiple modulation types and one of them leaks more than what is permitte= d in that regulatory domain, then the device will need to know it, and in t= hat regulatory domain avoid using that particular modulation type. How does= the device come to know it? Andy proposes the DB to indicate that level for the unavailable channels. Other= s folks seem to suggest a device built to operate under a certain ruleset h= as to implicitly know it.

Another way of looking at= it might be to say that the max level of permitted unintentional leakage i= nto an adjacent channel is part of the rulesetInfo, and the spectrum response only lists the available channels. Could this be a w= ay forward?

- =          gabor<= /span>

 <= /p>

From: paws-bou= nces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext Andy Lee
Sent: Friday, September 20, 2013 1:00 PM
To: Benjamin A. Rolfe
Cc: Protocol to Access White Space database
Subject: Re: [paws] Spectrum encoding discussion

 

Hi Ben,

 

And that means NO intentional radiation i= n the channel.  

 

If you are reading this as "transmit= ted emissions in band should be lower than -33dBm" then, no, this is n= ot the same as "no emissions" per FCC rules. If one were to inten= tionally transmit at -33dBm where no intentional emissions are allowed, that would = not be the same as "no" under the rules.

 

There is certainly no intention to encourage any malicious= behavior.  In general, we expect devices to be trying to do the right= thing and just need some information to understand where the boundaries are.  These boundaries include both intentional and uninte= ntional emissions.

 

Various modulation types have known spectral profiles, inc= luding both in-band and out-of-band emissions.  Knowing where the &quo= t;shelf" is on the adjacent channel makes it possible to match that with the "skirt" of the intended modulation pattern.  The &= quot;skirt" is not part of the intended emission, but is important in = trying to avoid causing interference on adjacent channels.

 

A crude example of this is shown in the following image:

 

3D"Inline=

 

Best regards,


 

Andy Lee |

 Google Inc. |

 tvfool@google.com |

 408-230-0522

 

On Fri, Sep 20, 2013 at 3:07 AM, Benjamin A. Rolfe &= lt;ben@blindcreek.c= om> wrote:

 

On 9/19/2013 9:09 AM, Andy Lee wrote:

The math bears that out, but nonetheless&= nbsp;OFCOM are still effectively proposing that *no* in-block transmis= sions are allowed in that channel.

 

Same is true for the FCC.  The FCC also assumes= that "off" channels are not used by WSDs.

And that means NO intentional radiation in the chann= el. 

 

Specifying a low power level like -33 dBm is effecti= vely the same thing as specifying no in-band emissions there.

 

If you are reading this as "transmitted emissio= ns in band should be lower than -33dBm" then, no, this is not the same= as "no emissions" per FCC rules. If one were to intentionally tr= ansmit at -33dBm where no intentional emissions are allowed, that would not be the same as "no" under the rules.




 

Even if someone did try to put an in-band emission t= here (regardless of how impractical that actually is), it would be too low = to cause interference to anyone and no harm has been done to the "RF e= nvironment".

Should be a little careful here for a couple reasons= .  I've designed and shipped communication systems that operate quite = well with transmit power levels intentionally below -33dBm and do very usef= ul things. It's pretty easy to design a receive with sensitivity better than -96dBm, so an intentional radiator at= -33dBm near by will be noticed - at 900 MHz your 10dB above sensitivity at= 10m and at 54MHz you'd be 10 dB above sensitivity at 100m, possibly. And w= hen it comes to protecting their spectrum, people always use the best propagation model to calculate interf= ence impact on them :-).  I've probably misunderstood something badly,= but -33dBm is certainly enough power to be noticed.

I have tried the "too low to be noticed" argument a few times in = the past  in regulatory discussions, and incumbent and/or protected us= ers usually set the threshold closer to -120dBm and usually argue that even= at really low TX power, the "aggregate impact" of multiple devices in the "RF Environment" is an unacceptable i= mpact.   We had trouble with this argument when the intentional r= adiator TX limit was below the maximum unintentional emission limits for mo= st non-transmitting devices (-41.3dBm).

So it would be fairly important to ensure a device does not interpret -33dB= m as it's ok to use that channel so long as it's TX power is below -33dBm.<= br>
I may be off base here because of  how y'all see the DB providing and = what I am expecting to support future needs. "protected users" in= cludes more than TV stations in the US. 

Not sure that helps, but hope so. 




 

The advantage of having an "well behaved" = spectrum profile (contiguous and without special values like -inf)&nbs= p;is that the channel selection algorithm on the WSDs becomes much simpler = and logical.  There's no need to have lots of special boundary condition checks and code paths that only get triggered under spe= cial circumstances.  I'd like to avoid ambiguous interpretations on th= e device side as much as possible.

Certainly ambiguous interpretations on the device si= de are a bad thing.

Some apps are aggregating multiple TV channels to get a logical channel tha= t that can carry a 'wide'  data pipe. Other uses can fit many useful c= hannels in one TV channel. In 802.15.4m we divide the TV channel up into mu= ltiple physical channels carrying low data rate signals.  Right now we assume a peak power level for the TV= channel, and we get that value with the start frequency and width (or end = frequency) from the database. However, I've heard it proposed to the FCC th= at we may get different power limits different parts of the TV channel, changing over time, as a protection mec= hanism for deal with narrow band protected users while allowing effective u= se of the rest of the TV channel.  For what we do, this is a good thin= g - our physical channel may be less than 200kHz wide. There are a LOT of applications  in IoT that need &= lt; 200kHz channels,  and blocking an entire TV channel to protect a w= ireless microphone using < 200kHz of it means there are 28 other usable = channels  not being used - not efficient use of the spectrum.  

Hope this helps.  

-Ben



 

Andy Lee |

 Google Inc. |

 tvfool@google.com |

 408-230-0522

 

On Thu, Sep 19, 2013 at 8:30 AM, Ray Bellis <Ray.Bellis@nomin= et.org.uk> wrote:


On 19 Sep 2013, at 16:21, Andy Lee <tvfool@google.com>

 wrote:

> This actually shows that Ofcom has picked a power threshold on channel= 38 of -33 dBm.  If you look at the ACLR numbers for class 3, 4, and 5= devices, you'll see they are 10 dB apart from each other and that they all= work out to be -33 dBm on channel 38.
>
> The reason there are no limits for class 1 and 2 devices is because th= e in-band power on channels 37 and 39 cannot exceed +36 dBm/8MHz, and t= herefore the power on channel 38 will naturally be less than -33 dBm.<= /o:p>

The math bears that o= ut, but nonetheless OFCOM are still effectively proposing that *no* in-bloc= k transmissions are allowed in that channel.

Per OFCOM / ETSI device interface requirements it would be incorrect for us= to actually send that value of -33 dBm to a device.

Ray

 

 

_______________________________________________
paws mailing list
paws@ietf.org
https://www.ietf.org/mailman/listinfo/paws

 


_______________________________________________
paws mailing list
paws@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/paws

 

--_000_1ECAFF543A2FED4EA2BEB6CACE08E476053422B0008AM1MPN1006mg_-- --_004_1ECAFF543A2FED4EA2BEB6CACE08E476053422B0008AM1MPN1006mg_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=5282; creation-date="Fri, 20 Sep 2013 20:54:37 GMT"; modification-date="Fri, 20 Sep 2013 20:54:37 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAZAAAAGQCAYAAACAvzbMAAAAAXNSR0IArs4c6QAAFFxJREFUeNrt 3XuQlXXhx/HPIfzhWikgCaMToIhBRjqZOfaPNTbWFpNNpSNdtGGyZNSAdMyw0ZhRCC21zHI0Z/Cv bOoPxy5qJuBfTTOMIpe4tKAmeCmSaMIFlH1+fzyd3QX2xrrLuezrNbMDu+e6z3nO8z7f79nzPJWi KIoAwBEaZREAICAACAgAAgKAgACAgAAgIEdPpVKxEAD6C0ilUun8mjBhQi6++OI8//zzlhoA/Y9A iqJIURTZtGlTZs6cmcsvv9xSA2DgU1gTJkzIokWL8uyzzyZJ9u3blwULFmTSpEmZNGlSFixYkH37 9mX69OnZvHlzkmTHjh0ZNWpUXn755STJpk2bMn369M7r7OjoyK233ppTTz0148ePz9y5c7Nnz57O 0c9dd92V9773vRk1que72d/l77vvvkydOjUtLS05//zzs379+jz33HOZNm1aun8AvyiKTJs2LWvX ru33ervrbRlUb//222/PxIkTc+KJJ+aaa67J/v37B3TfAZoqIDt37sySJUty9tlnJ0luu+22bNiw IatXr87q1auzdu3aLFmyJK2trVm1alWS5NFHH82YMWPyu9/9LkmycuXKfPrTn+68zrvvvjurVq3K ihUrsnXr1rz55pu5+eabO09/+umn85e//CUdHR093qf+Lv/EE09k1apV2blzZ1pbW3PVVVflrLPO ytixY7NixYrO8z311FMZN25cPvjBDw7oeqt6WwZVTz75ZJ555pmsXbs2mzdvztKlSwd83wHqXtGH JJ1f48ePL2bPnl20tbUVRVEUp512WrFhw4bO865bt66YNm1a8Yc//KGYM2dOURRF0draWtxwww3F 7Nmzi6IoiksvvbR47LHHOi8zY8aMYtOmTZ3fv/rqq8WUKVM6b/uFF17o6+71e/lXXnml87Q9e/YU LS0tRVEUxU9/+tPi0ksv7TztkksuKe69994BX29Vb8uger7up61fv77ztP5uA6ARVPramWKlUklv J7e0tGTXrl059thjkyR79+7NuHHj8vrrr2fWrFlZs2ZNJk+enG3btmXatGl56aWXcuaZZ2bjxo2d lznuuOM6p3WKokhHR0dGjRqVAwcOpFKppKOjo8+/eurv8ofe9+rP/v3vf2fKlCnZunVriqLI6aef nhdffDFjx449ouvtbRm0t7enUqmkvb29x9P6uw2ApprCOtTJJ5+cbdu2dX7f1taWU045JS0tLZk+ fXruvffenHvuuRk7dmzOOeec3HPPPZk5c2bnBjVJJk+enLa2trz11ls5cOBAiqI4aAPa35/M9nf5 3owdOzaf+cxnsnz58ixfvjyzZ8/ujMeRXG9vy6Cq+2nbtm076LTB3neAhg/InDlzMn/+/Gzfvj3b t2/P/PnzM2fOnCRJa2trli5dmosuuihJctFFF2Xp0qVpbW096DrmzZuXK6+8Mhs3bsz+/fuzbt26 XHbZZQO+D2/n8nPnzs0DDzyQX/ziF5k7d+6grrevZZAkCxcuzI4dO7Jjx44sXLgwX/7yl4fsdweo +/dAetPe3l5ce+21xcSJE4uJEycW1157bdHe3l4URVFs2bKlSFI899xzRVEUxZo1a4okxd/+9reD ruPAgQPFT37yk2LGjBnFmDFjilmzZhWPPPJIv7c92Mt3/1lHR0cxderUYurUqUVHR8egrrevZZCk WLZsWXHSSScV48aNK+bNm1fs3bt3QLcB0PDvgTB4fb1/BDCip7AAGNlGWwS83ZEWjc1IGSMQT0oA AQGg/pnCwqhrBDL1iBEIACNsBFKpJAN9tXok56XhLV5sGfTnllssAxphBFKpJA88cPjPH3usPK2+ xuQD+9lw3dbR/D2rXwB1G5Akuf/+5NB9NN1+e2P8ds04cikKIzKgLvQ/hXXBBckvf5l85Svl97// fTJjRvK/Y34kSfbtS77zneThh8vvL7ssWbYsGTMm2b8/WbiwPO2YY5Lrrjv8FfWhG8Tepq22bEkW LUpWrkzeeiu58MIycO95z8Ejg+plu19PX/exUkl+/vPkBz9IXnstOfvscuT1gQ/0Pvqo/vv668kZ ZyQbNyYTJpQ/e/PN5JRTkvXrk5NOKs+7bFnyox+V93vOnOTOO5P/+7/y/B0dyZIlyYMPJrt3J5/7 XHLPPck73zmiV84rrvAErXroIcuARhyBXH11ufGrbogXL07mzz/4PLfdlmzYkKxeXX6tXVtuEJPy 3y1byp+tXl1Ofw3WJZeU92f79uTvfy830t/9btd96+vVeV/3MUmeeKKM4s6dSWtrctVVfY9qqrc1 blwZo/vv7zrPypXJRz5SxqPqySeTZ54pb3fz5qTbwaVy993lba9YkWzdWgbIwaWAOtf3vrCqr+Av vji5/PLyFfPPftb1Hkj1otOmJb/9bfL+95ffr19fvopua0tOPz159NGDT5s1q+dRQk8jkL7eRP/P f5Izz0xeeqn/6+nrPlYqySuvJJMmlae98UY5mnjjjb6XS9W2bcnHP15e1zHHJPPmlSO36t51K5Uy XtXb3rChXKZtbeX3M2cmjzySvO995fevvZacd17ywgvp97Gp9QrU7b2Yofgz3u5vohuB9DwCGYo3 0Yf6cUNAet9I/elPyQ03lN8vWZJ88pMHb8BaWpJdu5LqsT727i1fmbe393xaS8vgArJ6dTkN9eyz 5XUmyTveUU4L9Xc9fd3HI5lG6+20Sy5JPv/5MhozZ5b3saWl6/zt7T3fdpIcd1w51Vcd2XR0JKNG Hf7eU5MH5NC/wBKQ3qew3m5EBISjM4WVJJ/4RLnRa29P/neMj4OcfHL5Kryqra2cXkrKf7uftnXr wZc99tiDX+m/+mrv9+Oyy8qtSltbGY1//atrI9vfXyX1dR+P/Nl3+M+uvz758Y+TP/85Of/8rnh0 H6V0/3/32548uet3OnCgDIODSwFNEZAk+etfy6+eNp5z5pTvi2zfXn7Nn1/+LEm+9KXyTfQdO8qv BQsOvuw55yQ//GGyZ0/y/PPJN7/Z+33Ysyc5/vjyzeUXX0y+8Y2u0yZMKN/I7k1f9/FI9XRb551X Tl8tWpR89auHX6b7Mli4MOl2cKnMm5dceWV5nfv3J+vWdU1/jVBGH5YHzRSQvnzve+W0zYc/XH6d eWZy003laTfdlJx2Wvm+x4c+dPgI5r77yvdUJkwo30f41Kd6v50HH0xuvDF597vL815wQddpN96Y fPSjvY9E+rqPR6q327r++nKE9bGPHX6ZCy8sf/9Zs8r3YxYt6jrt2muTz362nAI7/vgyLr3Frftn QHweBKghB5QaSvfdV46ili07fKPfpIt5uN4D8Yr7cEP5Rrr3QBgKdqY4VHbvTu66q/xTXAABYYAv 58q/mrrnnsG/MQ8gICNQf1MApgiAJmR37gAICAACAoCAQP8cSMryQkAG5Eg+++ZzcgANGBAHJKy/ qD3+ePmh9paWcvdeX/96uUuwZuJDhJYLTTICcUDC+nLnneUeU/75z2TNmmT0aBsWoE4DUj0gYVX1 gITd7dtX7iNx0qTya8GC8mdJuW/Aq69OTjyxPO2OOwY/ctiyJfniF8vrOuGEctdRO3f2vmuo7v/v 6z5WKuVeSKZOLV/Zn39+ebiQvkYf1dvatas8IOLOnV3nefPN8lhS//hH13lvvz2ZOLG879dc07X3 9qTce/uttyannpqMH5/MnVvuN7Inf/xjebyrd72rvI077jj44JAAdRMQByTseVRTLwckXLEiOfdc KzJw9PW5M0UHJOx7uVTV4oCESXnMqi98oXxf5IwzarQCDdFO+exIcWCGaoeKdqbIURmBJOXexm+7 Lfn+9w8/nEeSvPxyucf2qtNPLw97kZT/HnraYK1eXb6BPH58uVE+4YRywz8Qfd3HpCseSXmAwOrB AgfitNPKEcdvflOGZeXKMhCHnqdq2rSDb/vFF8sQjh5dHmBx0qQyin1ZtaoM4MMP1y4ewMg2oH1h VQ9ImPR9QMLqK+yeDkhYPa23AxIed1z5fX8HJLz55uTXvy7jsXt3+Z5C9VV+X/q6j0f+6u3wn11/ fTm1N2VK7wckrN52TwckfPzx8j2YgfjVr5Jvf7sc2Z1zTh2uVYP5kMKqbsd2meKJ2fty6v7N00d+ +aE4oDocyQgkcUDC7mp5QMI77ywPT//UU3UaD0BAjoQDEnaNQob7gITXXVf+AcHMmV1/CVapJP/9 r5UZOLockXAIjcADEvb8Zuwg3hFffPcJXRf5mnWpNw8t7/r/LQt2D/BCh7/z7k106mYEQtcBCb/1 LcviSHWPB5YbjcMBpYbkVbgDEgICwiA4IOHQMX3V//LpPo0FtWQKCwABAUBAABAQAAQEAAQEAAEB QEAAEBDol91xWH4ICAACArVhNyaWEwICgIAAgIAAICAACAgAAgKAgACAgAAgIDQRu+GwHBEQAAQE asPuOSwvBAQAAQEAAQFAQAAQEAAEBAABAQABAUBAaCJ2v2F5IiAACAjUht1yWG4ICAACAgACAoCA ACAgAAgIAAICAAICgIAAICCMdPbbZLkiIAAICNSG/TlZfggIAAICAAICgIAAICAACAgAAgIAAgKA gNBE7G7D8kVAABAQqA274bAcERAABAQABAQAAQFAQAAQEAAEBAAEBAABoYnYzYbljIAAgIBQG3a/ YXkiIAAICAAICAACAoCAACAgAAgIAAgIAAJCE7F7DcsbAQEAAaE27HbDckVAABAQABAQAAQEAAEB QEAAQEAAEBAABAQAAWGks18myx0BAQABoTbsr8nyRUAAEBAAEBAABAQAAQFAQABAQAAQEAAEhCZi dxqWPwICAAJCbdjNhuWMgACAgAAgIAAICAACAoCAAICAACAgAAgITWTxqgssBI8DAgIAAkIN2L2G 5Y2AAICAACAgAAgIAAICgIAAgIAAICAACAhNxO4zPB4ICAAICLVhtxqWOwICAAICgIAAICAACAgA AgIAAgKAgAAgIAAICCOd/S55XBAQABAQasP+mCx/BAQABAQAAQGgRkZXKhVLAUYw2wCMQAAQEADq 3+iiKCwFGGE87zECAaB2IxCLoI4sXtz4v4LdZdT34/PxVbnlY083/i9yyy0eTAGhWcIBNXnOCImA CEdzuuIKD3G9PA4PPSQkCMjICEcjb3l3ndD1/7M91HXh7LOSNd3Xr6mN+7v0VkIhERDh8JIdBvQc ERIBEQ7hACEREIQDhERAEA4QEgREOEBIhERAhAMQEgERDkBIGl6lsFc14RiqxXL3CQcvhq9ZVerF Q8sP/v6WBbtH6ILo5xOVQmIEIhyAEYkRiHA06AjE6KO+RyEjdgRiRGIEIhyAEYmACAcgJAIiHICQ CIhwCAcIiZAIiHAAQiIgwgEIiYAIByAkAiIcgJCMwJA09wcJhePoLWq7Mal7dmcynAt3ZH4gsTlH IMIBGJEYgQhH441AjD4aYxRiBGJEYgQiHIARiYAIByAkAiIcAE0eksYKiHAAQiIgwgEISWOHpL4D IhyAkNRtSOozIMIBCEndh6S+AiIcgJA0TEjqIyDCAdBwIantJ9GFoynYD1bjsD+sRn3g6vOT7bUZ gQgHQMOPSI7uCEQ4mn4EYvTRWKMQIxAjkvofgQgHQNONSIY3IMIB0LQhGZ6ACAdA04dkaAMiHAAj JiRDExDhABhxIXl7AREOgBEbksEFRDgARnxIjiwgwgEgJP8zsA8SCge9rRp2Y9Jw7M6ErpXh7X0g cbRwABiRDGZE0vMIRDgYxAjE6KMxRyFGIAx2RDJaOAAYzIhktHAAMJiQjO4zHsIBICS9hGS0cAAw mJCMOuxM4sEAHfonvHgcGQEh6daI0YIBwGBGJKMsCYZkffqaZeDxYqQREMA0FgKCDQ4gIMAwM42F gGBDBAgIjcH0lccVBAQAAaE2TF95/BAQGBDTHB5fEBAABITaMP3hcURAADqZxkJAsGEBBAQYXqax EBBscAABob6YvvJ4g4AAICDUhukrjysICANiOsPjDgICgIBQG6Y5PL4gIEC/TGMhINiAAAICDC/T WAgINiyAgFAbpq+wHiAgAAgItWH6yuMNAsKAmLbA+oCAACAg1IbpDI87CAgwaKaxEBBsKAABAYaX aSwEBBsQQEAYXqavsH4gIAAICLVh+grrAQLCgJiewHqCgAAgINSGaQusDwgIMORMYyEg2CAAAgIM L9NYCAg2FICAMDRMX2G9QUAAEBBqw/QV1g8EhAExDYH1BwEBQECoDdMTWE8QEOCoMY0lIHjiAwgI MLxMYyEg2CAAAsKRMX2F9QkBAUBAqA3TV1hvEBAGxHQD1isEBAABoTZMQ2D9QUCAmjONJSB4ggMI CDC8TGMJCJ74AAJCz0xfYT1DQAAQEGrD9BXWJwSEATGtgPUNAQFAQKgN0w1YrxAQoG6ZxhIQPJEB BAQYXqaxBARPcAABGelMX2H9Q0AAEBBqw/QV1jMEhAExfYD1EAEBQECoDdMKWN8QEKDhmMYSEDxh AQQEGF6msQQET2QAARkpTF9hvURAABAQasP0FdY/BIQBMU2A9RMBAUBAqA3TB1gPERCgaZjGEhA8 MQEBARheprEEBE9YAAFpNqavsL4iIAAICLVh+grrJQKC6QCstwgIAAJCHTNNgPUTAQGanmksAcET EBAQgOFlGktA8MQEBIRGZfoK6zECAoCAUBumr7C+IiAY9mN9RkAAEBBMB4D1FgEB6o9pLAHBEw0Q EIDhZRpLQPAEBASEemf6Cus3AgKAgFAbpq+wHiMgGN6D9VxAABAQDPvB+oyAAI3DNJaA4AkFCAjA 8DKNJSB4ogECQr0wfYX1HgEBQECoDdNXWL8REAzjwfovIAAICIb3YD1HQIDGZxpLQPDEAQQEYHiZ xhIQPKEAAeFoM30Fng8CAoCAUBumr7DeIyAYroPnhYAAICAYxoP1HwEBmpdpLAHBEwQQEIDhZRpL QPDEAQSE4WL6CjxPBASApvf/5iHIqNxWR4QAAAAASUVORK5CYII= --_004_1ECAFF543A2FED4EA2BEB6CACE08E476053422B0008AM1MPN1006mg_-- From peter@spectrumbridge.com Fri Sep 20 14:35:25 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1830421F9EB5 for ; Fri, 20 Sep 2013 14:35:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.298 X-Spam-Level: X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7GvEPcbWfDxt for ; Fri, 20 Sep 2013 14:35:20 -0700 (PDT) Received: from mail.spectrumbridge.com (mail.spectrumbridge.com [64.132.248.82]) by ietfa.amsl.com (Postfix) with ESMTP id 5D87D21F99F7 for ; Fri, 20 Sep 2013 14:35:20 -0700 (PDT) Received: from shelby.sbi.com ([127.0.0.1]) by shelby ([127.0.0.1]) with mapi; Fri, 20 Sep 2013 17:35:19 -0400 From: Peter Stanforth To: "Gabor.Bajko@nokia.com" , "tvfool@google.com" , "ben@blindcreek.com" Date: Fri, 20 Sep 2013 17:35:12 -0400 Thread-Topic: [paws] Spectrum encoding discussion Thread-Index: Ac62SU0cHh2AuSQNT1GuTnPkEvnD5g== Message-ID: In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E476053422B0@008-AM1MPN1-006.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.7.130812 acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_004_CE6236B91890Epeterspectrumbridgecom_" MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] Spectrum encoding discussion X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 21:35:25 -0000 --_004_CE6236B91890Epeterspectrumbridgecom_ Content-Type: multipart/alternative; boundary="_000_CE6236B91890Epeterspectrumbridgecom_" --_000_CE6236B91890Epeterspectrumbridgecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable We have, until know, always worked on the assumption that the device would = be certified, or not, to comply with any out of band emissions. The FCC for= instance specifically tests the more stringent rule around channel 37, as = well as the more general case. The Database is not, and cannot be, the enfo= rcement agency. So simply providing a list of channels that it can use is s= ufficient. It should be of no consequence to a device why it cannot use a channel othe= r than to behave with its compliant emissions. I agree with Gabor, why are we overly complicating this? From: "Gabor.Bajko@nokia.com" > Date: Friday, September 20, 2013 4:54 PM To: "tvfool@google.com" >, "ben@blindcreek.com" > Cc: "paws@ietf.org" > Subject: Re: [paws] Spectrum encoding discussion Aren=92t we talking past each other in this thread? If the rules are supposed to specify what is the max intended power level a= device can put into a channel (available or not), then I also think this i= s what the DB should communicate to the device. If Ofcom specifies that the max leakage into an unavailable channel is -33d= bm, I assume the device will not be certified if it leaks more. If the devi= ce supports multiple modulation types and one of them leaks more than what = is permitted in that regulatory domain, then the device will need to know i= t, and in that regulatory domain avoid using that particular modulation typ= e. How does the device come to know it? Andy proposes the DB to indicate th= at level for the unavailable channels. Others folks seem to suggest a devic= e built to operate under a certain ruleset has to implicitly know it. Another way of looking at it might be to say that the max level of permitte= d unintentional leakage into an adjacent channel is part of the rulesetInfo= , and the spectrum response only lists the available channels. Could this b= e a way forward? - gabor From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of ext Andy Lee Sent: Friday, September 20, 2013 1:00 PM To: Benjamin A. Rolfe Cc: Protocol to Access White Space database Subject: Re: [paws] Spectrum encoding discussion Hi Ben, And that means NO intentional radiation in the channel. If you are reading this as "transmitted emissions in band should be lower t= han -33dBm" then, no, this is not the same as "no emissions" per FCC rules.= If one were to intentionally transmit at -33dBm where no intentional emiss= ions are allowed, that would not be the same as "no" under the rules. There is certainly no intention to encourage any malicious behavior. In ge= neral, we expect devices to be trying to do the right thing and just need s= ome information to understand where the boundaries are. These boundaries i= nclude both intentional and unintentional emissions. Various modulation types have known spectral profiles, including both in-ba= nd and out-of-band emissions. Knowing where the "shelf" is on the adjacent= channel makes it possible to match that with the "skirt" of the intended m= odulation pattern. The "skirt" is not part of the intended emission, but i= s important in trying to avoid causing interference on adjacent channels. A crude example of this is shown in the following image: [cid:image001.png@01CEB604.4DA2EA90] Best regards, Andy Lee | Google Inc. | tvfool@google.com | 408-230-0522 On Fri, Sep 20, 2013 at 3:07 AM, Benjamin A. Rolfe > wrote: On 9/19/2013 9:09 AM, Andy Lee wrote: The math bears that out, but nonetheless OFCOM are still effectively propos= ing that *no* in-block transmissions are allowed in that channel. Same is true for the FCC. The FCC also assumes that "off" channels are not= used by WSDs. And that means NO intentional radiation in the channel. Specifying a low power level like -33 dBm is effectively the same thing as = specifying no in-band emissions there. If you are reading this as "transmitted emissions in band should be lower t= han -33dBm" then, no, this is not the same as "no emissions" per FCC rules.= If one were to intentionally transmit at -33dBm where no intentional emiss= ions are allowed, that would not be the same as "no" under the rules. Even if someone did try to put an in-band emission there (regardless of how= impractical that actually is), it would be too low to cause interference t= o anyone and no harm has been done to the "RF environment". Should be a little careful here for a couple reasons. I've designed and sh= ipped communication systems that operate quite well with transmit power lev= els intentionally below -33dBm and do very useful things. It's pretty easy = to design a receive with sensitivity better than -96dBm, so an intentional = radiator at -33dBm near by will be noticed - at 900 MHz your 10dB above sen= sitivity at 10m and at 54MHz you'd be 10 dB above sensitivity at 100m, poss= ibly. And when it comes to protecting their spectrum, people always use the= best propagation model to calculate interfence impact on them :-). I've p= robably misunderstood something badly, but -33dBm is certainly enough power= to be noticed. I have tried the "too low to be noticed" argument a few times in the past = in regulatory discussions, and incumbent and/or protected users usually set= the threshold closer to -120dBm and usually argue that even at really low = TX power, the "aggregate impact" of multiple devices in the "RF Environment= " is an unacceptable impact. We had trouble with this argument when the i= ntentional radiator TX limit was below the maximum unintentional emission l= imits for most non-transmitting devices (-41.3dBm). So it would be fairly important to ensure a device does not interpret -33dB= m as it's ok to use that channel so long as it's TX power is below -33dBm. I may be off base here because of how y'all see the DB providing and what = I am expecting to support future needs. "protected users" includes more tha= n TV stations in the US. Not sure that helps, but hope so. The advantage of having an "well behaved" spectrum profile (contiguous and = without special values like -inf) is that the channel selection algorithm o= n the WSDs becomes much simpler and logical. There's no need to have lots = of special boundary condition checks and code paths that only get triggered= under special circumstances. I'd like to avoid ambiguous interpretations = on the device side as much as possible. Certainly ambiguous interpretations on the device side are a bad thing. Some apps are aggregating multiple TV channels to get a logical channel tha= t that can carry a 'wide' data pipe. Other uses can fit many useful channe= ls in one TV channel. In 802.15.4m we divide the TV channel up into multipl= e physical channels carrying low data rate signals. Right now we assume a = peak power level for the TV channel, and we get that value with the start f= requency and width (or end frequency) from the database. However, I've hear= d it proposed to the FCC that we may get different power limits different p= arts of the TV channel, changing over time, as a protection mechanism for d= eal with narrow band protected users while allowing effective use of the re= st of the TV channel. For what we do, this is a good thing - our physical = channel may be less than 200kHz wide. There are a LOT of applications in I= oT that need < 200kHz channels, and blocking an entire TV channel to prote= ct a wireless microphone using < 200kHz of it means there are 28 other usab= le channels not being used - not efficient use of the spectrum. Hope this helps. -Ben Andy Lee | Google Inc. | tvfool@google.com | 408-230-0522 On Thu, Sep 19, 2013 at 8:30 AM, Ray Bellis > wrote: On 19 Sep 2013, at 16:21, Andy Lee > wrote: > This actually shows that Ofcom has picked a power threshold on channel 38= of -33 dBm. If you look at the ACLR numbers for class 3, 4, and 5 devices= , you'll see they are 10 dB apart from each other and that they all work ou= t to be -33 dBm on channel 38. > > The reason there are no limits for class 1 and 2 devices is because the i= n-band power on channels 37 and 39 cannot exceed +36 dBm/8MHz, and therefor= e the power on channel 38 will naturally be less than -33 dBm. The math bears that out, but nonetheless OFCOM are still effectively propos= ing that *no* in-block transmissions are allowed in that channel. Per OFCOM / ETSI device interface requirements it would be incorrect for us= to actually send that value of -33 dBm to a device. Ray _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws --_000_CE6236B91890Epeterspectrumbridgecom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
We have, until know, always wor= ked on the assumption that the device would be certified, or not, to comply= with any out of band emissions. The FCC for instance specifically tests th= e more stringent rule around channel 37, as well as the more general case. = The Database is not, and cannot be, the enforcement agency. So simply provi= ding a list of channels that it can use is sufficient.
It should = be of no consequence to a device why it cannot use a channel other than to = behave with its compliant emissions. 
I agree with Gabor, wh= y are we overly complicating this?

From: "Gabor.Bajko@nokia.com" <Gabor.Bajko@nokia.com>
Dat= e: Friday, September 20, 2013 4:54 PM
To: "tvfool@google= .com" <tvfool@google.com>, "ben@blindcreek.com&= quot; <ben@blindcreek.com><= br>Cc: "paws@ietf.org" <pa= ws@ietf.org>
Subject: Re= : [paws] Spectrum encoding discussion

Aren=92t we talking past each other in this thread?

If the rules are supposed to = specify what is the max intended power level a device can put into a channe= l (available or not), then I also think this is what the DB should communicate to the device.

If Ofcom specifies that the max leakage into a= n unavailable channel is -33dbm, I assume the device will not be certified = if it leaks more. If the device supports multiple modulation types and one of them leaks more than what is permitte= d in that regulatory domain, then the device will need to know it, and in t= hat regulatory domain avoid using that particular modulation type. How does= the device come to know it? Andy proposes the DB to indicate that level for the unavailable channels. Other= s folks seem to suggest a device built to operate under a certain ruleset h= as to implicitly know it.

Another way of looking at it might be to say that the max leve= l of permitted unintentional leakage into an adjacent channel is part of th= e rulesetInfo, and the spectrum response only lists the available channels. Could this be a w= ay forward?

-       &n= bsp;  gabor

 

<= p class=3D"MsoNormal">From: paws-bou= nces@ietf.org [mailto:paws-bou= nces@ietf.org] On Behalf Of ext Andy Lee
Sent: Friday, September 20, 2013= 1:00 PM
To: Benjamin A. Rolfe
Cc: Protocol to Access W= hite Space database
Subject: Re: [paws] Spectrum encoding discuss= ion

 

<= p class=3D"MsoNormal">Hi Ben,

 

And that means NO intentional radiation in the channel.=   

= &nbs= p;

If you are reading this as "transmitted emissions in b= and should be lower than -33dBm" then, no, this is not the same as &qu= ot;no emissions" per FCC rules. If one were to intentionally transmit at -33dBm where no intentional emissions are allowed, that would = not be the same as "no" under the rules.

 

Th= ere is certainly no intention to encourage any malicious behavior.  In= general, we expect devices to be trying to do the right thing and just nee= d some information to understand where the boundaries are.  These boundaries include both intentional and uninte= ntional emissions.

<= o:p> 

Various modulation types have known spectral pr= ofiles, including both in-band and out-of-band emissions.  Knowing whe= re the "shelf" is on the adjacent channel makes it possible to ma= tch that with the "skirt" of the intended modulation pattern.  The &= quot;skirt" is not part of the intended emission, but is important in = trying to avoid causing interference on adjacent channels.

 

A crude= example of this is shown in the following image:

 

3D"Inline

 

Best regards,

<= /div>


&= nbsp;

<= /tbody>

 Google Inc. |

 tvfool@google.com |

 408-230-0522

=  

On Fri, Sep 20, 2013 at 3:= 07 AM, Benjamin A. Rolfe <ben@blindcreek.com> wrote:

 

On 9/19/= 2013 9:09 AM, Andy Lee wrote:

The math bears that out, but nonetheless = ;OFCOM are still effectively proposing that *no* in-block transmission= s are allowed in that channel.

 

Sa= me is true for the FCC.  The FCC also assumes that "off" cha= nnels are not used by WSDs.

And that means NO intentional radiation in the channel= . 

 

Specifying a low power level like -33 dBm is effec= tively the same thing as specifying no in-band emissions there.<= /p>

 

If you are reading this as "transmitted emis= sions in band should be lower than -33dBm" then, no, this is not the s= ame as "no emissions" per FCC rules. If one were to intentionally= transmit at -33dBm where no intentional emissions are allowed, that would not be the same as "no" under the rules.




 

Even = if someone did try to put an in-band emission there (regardless of how impr= actical that actually is), it would be too low to cause interference to any= one and no harm has been done to the "RF environment".=

Should be a little careful her= e for a couple reasons.  I've designed and shipped communication syste= ms that operate quite well with transmit power levels intentionally below -= 33dBm and do very useful things. It's pretty easy to design a receive with sensitivity better than -96dBm, so an intentional radiator at= -33dBm near by will be noticed - at 900 MHz your 10dB above sensitivity at= 10m and at 54MHz you'd be 10 dB above sensitivity at 100m, possibly. And w= hen it comes to protecting their spectrum, people always use the best propagation model to calculate interf= ence impact on them :-).  I've probably misunderstood something badly,= but -33dBm is certainly enough power to be noticed.

I have tried the "too low to be noticed" argument a few times in = the past  in regulatory discussions, and incumbent and/or protected us= ers usually set the threshold closer to -120dBm and usually argue that even= at really low TX power, the "aggregate impact" of multiple devices in the "RF Environment" is an unacceptable i= mpact.   We had trouble with this argument when the intentional r= adiator TX limit was below the maximum unintentional emission limits for mo= st non-transmitting devices (-41.3dBm).

So it would be fairly important to ensure a device does not interpret -33dB= m as it's ok to use that channel so long as it's TX power is below -33dBm.<= br>
I may be off base here because of  how y'all see the DB providing and = what I am expecting to support future needs. "protected users" in= cludes more than TV stations in the US. 

Not sure that helps, but hope so. 




&n= bsp;

The advantage of having an = "well behaved" spectrum profile (contiguous and without spec= ial values like -inf) is that the channel selection algorithm on the W= SDs becomes much simpler and logical.  There's no need to have lots of= special boundary condition checks and code paths that only get triggered under spe= cial circumstances.  I'd like to avoid ambiguous interpretations on th= e device side as much as possible.

Certainly ambiguous interpretations on the device side are a= bad thing.

Some apps are aggregating multiple TV channels to get a logical channel tha= t that can carry a 'wide'  data pipe. Other uses can fit many useful c= hannels in one TV channel. In 802.15.4m we divide the TV channel up into mu= ltiple physical channels carrying low data rate signals.  Right now we assume a peak power level for the TV= channel, and we get that value with the start frequency and width (or end = frequency) from the database. However, I've heard it proposed to the FCC th= at we may get different power limits different parts of the TV channel, changing over time, as a protection mec= hanism for deal with narrow band protected users while allowing effective u= se of the rest of the TV channel.  For what we do, this is a good thin= g - our physical channel may be less than 200kHz wide. There are a LOT of applications  in IoT that need &= lt; 200kHz channels,  and blocking an entire TV channel to protect a w= ireless microphone using < 200kHz of it means there are 28 other usable = channels  not being used - not efficient use of the spectrum.  

Hope this helps.  

-Ben



 

 Google Inc. |

Andy Lee |

 tvfool@google.com |

 408-230-0522

 

On Thu, Sep 19, 2013 at= 8:30 AM, Ray Bellis <Ray.Bellis@nominet.org.uk> wrote:


On 19 Sep 2013, at 16:21, Andy Lee <tvfool@google.com>

 wrote:

> This actually shows that Ofcom has picked a power threshold on channel= 38 of -33 dBm.  If you look at the ACLR numbers for class 3, 4, and 5= devices, you'll see they are 10 dB apart from each other and that they all= work out to be -33 dBm on channel 38.
>
> The reason there are no limits for class 1 and 2 devices is because th= e in-band power on channels 37 and 39 cannot exceed +36 dBm/8MHz, and t= herefore the power on channel 38 will naturally be less than -33 dBm.<= /o:p>

The ma= th bears that out, but nonetheless OFCOM are still effectively proposing th= at *no* in-block transmissions are allowed in that channel.

Per OFCOM / ETSI device interface requirements it would be incorrect for us= to actually send that value of -33 dBm to a device.

Ray

 

&n= bsp;

_____________________________________________=
__
paws mailing list
paws@ietf.org
https://www.ietf.org/mailman/listinfo/paws

 


_______________________________________________
paws mailing list
paws@ietf.org
= ht= tps://www.ietf.org/mailman/listinfo/paws

 

<= /html> --_000_CE6236B91890Epeterspectrumbridgecom_-- --_004_CE6236B91890Epeterspectrumbridgecom_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: attachment; filename="image001.png"; size=5282; creation-date="Fri, 20 Sep 2013 17:35:18 GMT"; modification-date="Fri, 20 Sep 2013 17:35:18 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAZAAAAGQCAYAAACAvzbMAAAAAXNSR0IArs4c6QAAFFxJREFUeNrt 3XuQlXXhx/HPIfzhWikgCaMToIhBRjqZOfaPNTbWFpNNpSNdtGGyZNSAdMyw0ZhRCC21zHI0Z/Cv bOoPxy5qJuBfTTOMIpe4tKAmeCmSaMIFlH1+fzyd3QX2xrrLuezrNbMDu+e6z3nO8z7f79nzPJWi KIoAwBEaZREAICAACAgAAgKAgACAgAAgIEdPpVKxEAD6C0ilUun8mjBhQi6++OI8//zzlhoA/Y9A iqJIURTZtGlTZs6cmcsvv9xSA2DgU1gTJkzIokWL8uyzzyZJ9u3blwULFmTSpEmZNGlSFixYkH37 9mX69OnZvHlzkmTHjh0ZNWpUXn755STJpk2bMn369M7r7OjoyK233ppTTz0148ePz9y5c7Nnz57O 0c9dd92V9773vRk1que72d/l77vvvkydOjUtLS05//zzs379+jz33HOZNm1aun8AvyiKTJs2LWvX ru33ervrbRlUb//222/PxIkTc+KJJ+aaa67J/v37B3TfAZoqIDt37sySJUty9tlnJ0luu+22bNiw IatXr87q1auzdu3aLFmyJK2trVm1alWS5NFHH82YMWPyu9/9LkmycuXKfPrTn+68zrvvvjurVq3K ihUrsnXr1rz55pu5+eabO09/+umn85e//CUdHR093qf+Lv/EE09k1apV2blzZ1pbW3PVVVflrLPO ytixY7NixYrO8z311FMZN25cPvjBDw7oeqt6WwZVTz75ZJ555pmsXbs2mzdvztKlSwd83wHqXtGH JJ1f48ePL2bPnl20tbUVRVEUp512WrFhw4bO865bt66YNm1a8Yc//KGYM2dOURRF0draWtxwww3F 7Nmzi6IoiksvvbR47LHHOi8zY8aMYtOmTZ3fv/rqq8WUKVM6b/uFF17o6+71e/lXXnml87Q9e/YU LS0tRVEUxU9/+tPi0ksv7TztkksuKe69994BX29Vb8uger7up61fv77ztP5uA6ARVPramWKlUklv J7e0tGTXrl059thjkyR79+7NuHHj8vrrr2fWrFlZs2ZNJk+enG3btmXatGl56aWXcuaZZ2bjxo2d lznuuOM6p3WKokhHR0dGjRqVAwcOpFKppKOjo8+/eurv8ofe9+rP/v3vf2fKlCnZunVriqLI6aef nhdffDFjx449ouvtbRm0t7enUqmkvb29x9P6uw2ApprCOtTJJ5+cbdu2dX7f1taWU045JS0tLZk+ fXruvffenHvuuRk7dmzOOeec3HPPPZk5c2bnBjVJJk+enLa2trz11ls5cOBAiqI4aAPa35/M9nf5 3owdOzaf+cxnsnz58ixfvjyzZ8/ujMeRXG9vy6Cq+2nbtm076LTB3neAhg/InDlzMn/+/Gzfvj3b t2/P/PnzM2fOnCRJa2trli5dmosuuihJctFFF2Xp0qVpbW096DrmzZuXK6+8Mhs3bsz+/fuzbt26 XHbZZQO+D2/n8nPnzs0DDzyQX/ziF5k7d+6grrevZZAkCxcuzI4dO7Jjx44sXLgwX/7yl4fsdweo +/dAetPe3l5ce+21xcSJE4uJEycW1157bdHe3l4URVFs2bKlSFI899xzRVEUxZo1a4okxd/+9reD ruPAgQPFT37yk2LGjBnFmDFjilmzZhWPPPJIv7c92Mt3/1lHR0cxderUYurUqUVHR8egrrevZZCk WLZsWXHSSScV48aNK+bNm1fs3bt3QLcB0PDvgTB4fb1/BDCip7AAGNlGWwS83ZEWjc1IGSMQT0oA AQGg/pnCwqhrBDL1iBEIACNsBFKpJAN9tXok56XhLV5sGfTnllssAxphBFKpJA88cPjPH3usPK2+ xuQD+9lw3dbR/D2rXwB1G5Akuf/+5NB9NN1+e2P8ds04cikKIzKgLvQ/hXXBBckvf5l85Svl97// fTJjRvK/Y34kSfbtS77zneThh8vvL7ssWbYsGTMm2b8/WbiwPO2YY5Lrrjv8FfWhG8Tepq22bEkW LUpWrkzeeiu58MIycO95z8Ejg+plu19PX/exUkl+/vPkBz9IXnstOfvscuT1gQ/0Pvqo/vv668kZ ZyQbNyYTJpQ/e/PN5JRTkvXrk5NOKs+7bFnyox+V93vOnOTOO5P/+7/y/B0dyZIlyYMPJrt3J5/7 XHLPPck73zmiV84rrvAErXroIcuARhyBXH11ufGrbogXL07mzz/4PLfdlmzYkKxeXX6tXVtuEJPy 3y1byp+tXl1Ofw3WJZeU92f79uTvfy830t/9btd96+vVeV/3MUmeeKKM4s6dSWtrctVVfY9qqrc1 blwZo/vv7zrPypXJRz5SxqPqySeTZ54pb3fz5qTbwaVy993lba9YkWzdWgbIwaWAOtf3vrCqr+Av vji5/PLyFfPPftb1Hkj1otOmJb/9bfL+95ffr19fvopua0tOPz159NGDT5s1q+dRQk8jkL7eRP/P f5Izz0xeeqn/6+nrPlYqySuvJJMmlae98UY5mnjjjb6XS9W2bcnHP15e1zHHJPPmlSO36t51K5Uy XtXb3rChXKZtbeX3M2cmjzySvO995fevvZacd17ywgvp97Gp9QrU7b2Yofgz3u5vohuB9DwCGYo3 0Yf6cUNAet9I/elPyQ03lN8vWZJ88pMHb8BaWpJdu5LqsT727i1fmbe393xaS8vgArJ6dTkN9eyz 5XUmyTveUU4L9Xc9fd3HI5lG6+20Sy5JPv/5MhozZ5b3saWl6/zt7T3fdpIcd1w51Vcd2XR0JKNG Hf7eU5MH5NC/wBKQ3qew3m5EBISjM4WVJJ/4RLnRa29P/neMj4OcfHL5Kryqra2cXkrKf7uftnXr wZc99tiDX+m/+mrv9+Oyy8qtSltbGY1//atrI9vfXyX1dR+P/Nl3+M+uvz758Y+TP/85Of/8rnh0 H6V0/3/32548uet3OnCgDIODSwFNEZAk+etfy6+eNp5z5pTvi2zfXn7Nn1/+LEm+9KXyTfQdO8qv BQsOvuw55yQ//GGyZ0/y/PPJN7/Z+33Ysyc5/vjyzeUXX0y+8Y2u0yZMKN/I7k1f9/FI9XRb551X Tl8tWpR89auHX6b7Mli4MOl2cKnMm5dceWV5nfv3J+vWdU1/jVBGH5YHzRSQvnzve+W0zYc/XH6d eWZy003laTfdlJx2Wvm+x4c+dPgI5r77yvdUJkwo30f41Kd6v50HH0xuvDF597vL815wQddpN96Y fPSjvY9E+rqPR6q327r++nKE9bGPHX6ZCy8sf/9Zs8r3YxYt6jrt2muTz362nAI7/vgyLr3Frftn QHweBKghB5QaSvfdV46ili07fKPfpIt5uN4D8Yr7cEP5Rrr3QBgKdqY4VHbvTu66q/xTXAABYYAv 58q/mrrnnsG/MQ8gICNQf1MApgiAJmR37gAICAACAoCAQP8cSMryQkAG5Eg+++ZzcgANGBAHJKy/ qD3+ePmh9paWcvdeX/96uUuwZuJDhJYLTTICcUDC+nLnneUeU/75z2TNmmT0aBsWoE4DUj0gYVX1 gITd7dtX7iNx0qTya8GC8mdJuW/Aq69OTjyxPO2OOwY/ctiyJfniF8vrOuGEctdRO3f2vmuo7v/v 6z5WKuVeSKZOLV/Zn39+ebiQvkYf1dvatas8IOLOnV3nefPN8lhS//hH13lvvz2ZOLG879dc07X3 9qTce/uttyannpqMH5/MnVvuN7Inf/xjebyrd72rvI077jj44JAAdRMQByTseVRTLwckXLEiOfdc KzJw9PW5M0UHJOx7uVTV4oCESXnMqi98oXxf5IwzarQCDdFO+exIcWCGaoeKdqbIURmBJOXexm+7 Lfn+9w8/nEeSvPxyucf2qtNPLw97kZT/HnraYK1eXb6BPH58uVE+4YRywz8Qfd3HpCseSXmAwOrB AgfitNPKEcdvflOGZeXKMhCHnqdq2rSDb/vFF8sQjh5dHmBx0qQyin1ZtaoM4MMP1y4ewMg2oH1h VQ9ImPR9QMLqK+yeDkhYPa23AxIed1z5fX8HJLz55uTXvy7jsXt3+Z5C9VV+X/q6j0f+6u3wn11/ fTm1N2VK7wckrN52TwckfPzx8j2YgfjVr5Jvf7sc2Z1zTh2uVYP5kMKqbsd2meKJ2fty6v7N00d+ +aE4oDocyQgkcUDC7mp5QMI77ywPT//UU3UaD0BAjoQDEnaNQob7gITXXVf+AcHMmV1/CVapJP/9 r5UZOLockXAIjcADEvb8Zuwg3hFffPcJXRf5mnWpNw8t7/r/LQt2D/BCh7/z7k106mYEQtcBCb/1 LcviSHWPB5YbjcMBpYbkVbgDEgICwiA4IOHQMX3V//LpPo0FtWQKCwABAUBAABAQAAQEAAQEAAEB QEAAEBDol91xWH4ICAACArVhNyaWEwICgIAAgIAAICAACAgAAgKAgACAgAAgIDQRu+GwHBEQAAQE asPuOSwvBAQAAQEAAQFAQAAQEAAEBAABAQABAUBAaCJ2v2F5IiAACAjUht1yWG4ICAACAgACAoCA ACAgAAgIAAICAAICgIAAICCMdPbbZLkiIAAICNSG/TlZfggIAAICAAICgIAAICAACAgAAgIAAgKA gNBE7G7D8kVAABAQqA274bAcERAABAQABAQAAQFAQAAQEAAEBAAEBAABoYnYzYbljIAAgIBQG3a/ YXkiIAAICAAICAACAoCAACAgAAgIAAgIAAJCE7F7DcsbAQEAAaE27HbDckVAABAQABAQAAQEAAEB QEAAQEAAEBAABAQAAWGks18myx0BAQABoTbsr8nyRUAAEBAAEBAABAQAAQFAQABAQAAQEAAEhCZi dxqWPwICAAJCbdjNhuWMgACAgAAgIAAICAACAoCAAICAACAgAAgITWTxqgssBI8DAgIAAkIN2L2G 5Y2AAICAACAgAAgIAAICgIAAgIAAICAACAhNxO4zPB4ICAAICLVhtxqWOwICAAICgIAAICAACAgA AgIAAgKAgAAgIAAICCOd/S55XBAQABAQasP+mCx/BAQABAQAAQGgRkZXKhVLAUYw2wCMQAAQEADq 3+iiKCwFGGE87zECAaB2IxCLoI4sXtz4v4LdZdT34/PxVbnlY083/i9yyy0eTAGhWcIBNXnOCImA CEdzuuIKD3G9PA4PPSQkCMjICEcjb3l3ndD1/7M91HXh7LOSNd3Xr6mN+7v0VkIhERDh8JIdBvQc ERIBEQ7hACEREIQDhERAEA4QEgREOEBIhERAhAMQEgERDkBIGl6lsFc14RiqxXL3CQcvhq9ZVerF Q8sP/v6WBbtH6ILo5xOVQmIEIhyAEYkRiHA06AjE6KO+RyEjdgRiRGIEIhyAEYmACAcgJAIiHICQ CIhwCAcIiZAIiHAAQiIgwgEIiYAIByAkAiIcgJCMwJA09wcJhePoLWq7Mal7dmcynAt3ZH4gsTlH IMIBGJEYgQhH441AjD4aYxRiBGJEYgQiHIARiYAIByAkAiIcAE0eksYKiHAAQiIgwgEISWOHpL4D IhyAkNRtSOozIMIBCEndh6S+AiIcgJA0TEjqIyDCAdBwIantJ9GFoynYD1bjsD+sRn3g6vOT7bUZ gQgHQMOPSI7uCEQ4mn4EYvTRWKMQIxAjkvofgQgHQNONSIY3IMIB0LQhGZ6ACAdA04dkaAMiHAAj JiRDExDhABhxIXl7AREOgBEbksEFRDgARnxIjiwgwgEgJP8zsA8SCge9rRp2Y9Jw7M6ErpXh7X0g cbRwABiRDGZE0vMIRDgYxAjE6KMxRyFGIAx2RDJaOAAYzIhktHAAMJiQjO4zHsIBICS9hGS0cAAw mJCMOuxM4sEAHfonvHgcGQEh6daI0YIBwGBGJKMsCYZkffqaZeDxYqQREMA0FgKCDQ4gIMAwM42F gGBDBAgIjcH0lccVBAQAAaE2TF95/BAQGBDTHB5fEBAABITaMP3hcURAADqZxkJAsGEBBAQYXqax EBBscAABob6YvvJ4g4AAICDUhukrjysICANiOsPjDgICgIBQG6Y5PL4gIEC/TGMhINiAAAICDC/T WAgINiyAgFAbpq+wHiAgAAgItWH6yuMNAsKAmLbA+oCAACAg1IbpDI87CAgwaKaxEBBsKAABAYaX aSwEBBsQQEAYXqavsH4gIAAICLVh+grrAQLCgJiewHqCgAAgINSGaQusDwgIMORMYyEg2CAAAgIM L9NYCAg2FICAMDRMX2G9QUAAEBBqw/QV1g8EhAExDYH1BwEBQECoDdMTWE8QEOCoMY0lIHjiAwgI MLxMYyEg2CAAAsKRMX2F9QkBAUBAqA3TV1hvEBAGxHQD1isEBAABoTZMQ2D9QUCAmjONJSB4ggMI CDC8TGMJCJ74AAJCz0xfYT1DQAAQEGrD9BXWJwSEATGtgPUNAQFAQKgN0w1YrxAQoG6ZxhIQPJEB BAQYXqaxBARPcAABGelMX2H9Q0AAEBBqw/QV1jMEhAExfYD1EAEBQECoDdMKWN8QEKDhmMYSEDxh AQQEGF6msQQET2QAARkpTF9hvURAABAQasP0FdY/BIQBMU2A9RMBAUBAqA3TB1gPERCgaZjGEhA8 MQEBARheprEEBE9YAAFpNqavsL4iIAAICLVh+grrJQKC6QCstwgIAAJCHTNNgPUTAQGanmksAcET EBAQgOFlGktA8MQEBIRGZfoK6zECAoCAUBumr7C+IiAY9mN9RkAAEBBMB4D1FgEB6o9pLAHBEw0Q EIDhZRpLQPAEBASEemf6Cus3AgKAgFAbpq+wHiMgGN6D9VxAABAQDPvB+oyAAI3DNJaA4AkFCAjA 8DKNJSB4ogECQr0wfYX1HgEBQECoDdNXWL8REAzjwfovIAAICIb3YD1HQIDGZxpLQPDEAQQEYHiZ xhIQPKEAAeFoM30Fng8CAoCAUBumr7DeIyAYroPnhYAAICAYxoP1HwEBmpdpLAHBEwQQEIDhZRpL QPDEAQSE4WL6CjxPBASApvf/5iHIqNxWR4QAAAAASUVORK5CYII= --_004_CE6236B91890Epeterspectrumbridgecom_-- From tvfool@google.com Fri Sep 20 16:11:48 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 853B621F9EB8 for ; Fri, 20 Sep 2013 16:11:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.227 X-Spam-Level: X-Spam-Status: No, score=-1.227 tagged_above=-999 required=5 tests=[AWL=0.750, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I8PtmL-64ucP for ; Fri, 20 Sep 2013 16:11:47 -0700 (PDT) Received: from mail-qa0-x22c.google.com (mail-qa0-x22c.google.com [IPv6:2607:f8b0:400d:c00::22c]) by ietfa.amsl.com (Postfix) with ESMTP id B496E21F9E43 for ; Fri, 20 Sep 2013 16:11:46 -0700 (PDT) Received: by mail-qa0-f44.google.com with SMTP id j7so125877qaq.3 for ; Fri, 20 Sep 2013 16:11:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ViqVEg9DSgIyEYVcfPOL9lfyc3+/ST+uuXKlU3yYlv4=; b=Ky90JJERdRyhZaZ6IqoyUu9BOlQl+mwZWcxoMoSeevYIheKreaZzgbM/KbApTXesXU n+9onH2PfY2bDvCWLpUK6+8duUi26DkO8/wiKNvEoPcKcLZ2LBVBfZgV1HuXyWY2n8Eb NxUmc8FdTAE4E7aYzgla7Lsai2vPo9Qk9zo4ErdeEX2t6aOw00BemJWO3yB1VlbZqt77 pmxy7KH2/eY7YhR7DJVjXYEVRw8aVHmIiYggDTWZgkIGI/TWb8DbE/BW4Ot8S85Kit44 LYc0T1T2fzG3iMA8kyhgl2o1rlQzOTLYOVJa+iC5OpOj3B3MyKaJADJu5bDY9Lj7sKq4 SK7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ViqVEg9DSgIyEYVcfPOL9lfyc3+/ST+uuXKlU3yYlv4=; b=K7xtEsEMJc/vETFsj7BYbgk3zE2zZTh/gth0uSs49zZRZJpy6WDag0n8+fBY0qsK6C JvxwlrlaAHHD2rBgFSth0RQYJWz4s5IunlLc+94g8zc+r2xAaH76eLkUo1CmcnuxpVm/ C/ybsPzOM0ctolrKoi6wuNzkaIX/mSfFj+x0CmWWoCzXRbkqiYTc51LWKNCPdiHBlZsd m8qYrd51xxmLKi+raV6q8VFwo6HPYK6XeB+aszw6yHVL/bCDO3EIcmH8zX6uwBDf1mgJ j8wwYyNSgdKijyZ73q5DyGC2Snk4ZUZDNYJCFacGbkQ0r0p8gpHWwm5nxAa1Wx7utTr1 Yjcg== X-Gm-Message-State: ALoCoQnHNkOmz4zIkC4eQGb8rNb+QJ+dFQ+HlqTHL4MRJ573Auo7QT6/Cyy8UQ9+CHrp3aPy7ICfnkSWpl7NLXRQNASQ+fIgJHGgu/aH5QJ6SenczF3U7b27VT1EgatSDqL32lBo4oD+qzwugk5etRPSZphhgh1Edx7L/6Uf+0ZtKlxtKF9iTlVC42dBcml9kHOejsSijenH MIME-Version: 1.0 X-Received: by 10.49.75.103 with SMTP id b7mr4963755qew.85.1379718705075; Fri, 20 Sep 2013 16:11:45 -0700 (PDT) Received: by 10.229.207.8 with HTTP; Fri, 20 Sep 2013 16:11:44 -0700 (PDT) In-Reply-To: References: <1ECAFF543A2FED4EA2BEB6CACE08E476053422B0@008-AM1MPN1-006.mgdnok.nokia.com> Date: Fri, 20 Sep 2013 16:11:44 -0700 Message-ID: From: Andy Lee To: Peter Stanforth Content-Type: multipart/related; boundary=047d7bd76dba4e6b4404e6d8cbaf Cc: "paws@ietf.org" Subject: Re: [paws] Spectrum encoding discussion X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 23:11:48 -0000 --047d7bd76dba4e6b4404e6d8cbaf Content-Type: multipart/alternative; boundary=047d7bd76dba4e6b4204e6d8cbae --047d7bd76dba4e6b4204e6d8cbae Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I was actually hoping to simplify things for devices. 1) Having a fully specified spectrum profile without discontinuities and without "special" values like -inf make it much easier to write the client side code. This minimizes the number of special edge cases that need to be handled by the parsing logic and "emission fitting" code on the client. 2) We still seem to be thinking in terms of TV channels only. PAWS is designed for other frequency bands too, and there won't always be such a distinct concept of on-channel vs. adjacent-channel emissions. 3) We don't know what future WSD technologies will be capable of. Wi-Fi already supports a long list of modulation types (e.g., BPSK, QPSK, DSSS, FHSS, OFDM) and channel widths. Software defined radios and other technologies can dynamically choose modulation types, channel widths, and power distribution. These agile radio technologies need the full spectrum profile to help them choose the right combination of emission parameters. WSDs are just a "black box" from the database's point of view. Andy Lee | Google Inc. | tvfool@google.com | 408-230-0522 On Fri, Sep 20, 2013 at 2:35 PM, Peter Stanforth wrote: > We have, until know, always worked on the assumption that the device woul= d > be certified, or not, to comply with any out of band emissions. The FCC f= or > instance specifically tests the more stringent rule around channel 37, as > well as the more general case. The Database is not, and cannot be, the > enforcement agency. So simply providing a list of channels that it can us= e > is sufficient. > It should be of no consequence to a device why it cannot use a channel > other than to behave with its compliant emissions. > I agree with Gabor, why are we overly complicating this? > > From: "Gabor.Bajko@nokia.com" > Date: Friday, September 20, 2013 4:54 PM > To: "tvfool@google.com" , "ben@blindcreek.com" < > ben@blindcreek.com> > Cc: "paws@ietf.org" > > Subject: Re: [paws] Spectrum encoding discussion > > Aren=92t we talking past each other in this thread?**** > > If the rules are supposed to specify what is the max intended power level > a device can put into a channel (available or not), then I also think thi= s > is what the DB should communicate to the device.**** > > If Ofcom specifies that the max leakage into an unavailable channel is > -33dbm, I assume the device will not be certified if it leaks more. If th= e > device supports multiple modulation types and one of them leaks more than > what is permitted in that regulatory domain, then the device will need to > know it, and in that regulatory domain avoid using that particular > modulation type. How does the device come to know it? Andy proposes the D= B > to indicate that level for the unavailable channels. Others folks seem to > suggest a device built to operate under a certain ruleset has to implicit= ly > know it.**** > > Another way of looking at it might be to say that the max level of > permitted unintentional leakage into an adjacent channel is part of the > rulesetInfo, and the spectrum response only lists the available channels. > Could this be a way forward?**** > > - gabor**** > > ** ** > > *From:* paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] > *On Behalf Of *ext Andy Lee > *Sent:* Friday, September 20, 2013 1:00 PM > *To:* Benjamin A. Rolfe > *Cc:* Protocol to Access White Space database > *Subject:* Re: [paws] Spectrum encoding discussion**** > > ** ** > > Hi Ben,**** > > ** ** > > And that means NO intentional radiation in the channel. **** > > ** ** > > If you are reading this as "transmitted emissions in band should be lower > than -33dBm" then, no, this is not the same as "no emissions" per FCC > rules. If one were to intentionally transmit at -33dBm where no intention= al > emissions are allowed, that would not be the same as "no" under the rules= . > **** > > ** ** > > There is certainly no intention to encourage any malicious behavior. In > general, we expect devices to be trying to do the right thing and just ne= ed > some information to understand where the boundaries are. These boundarie= s > include both intentional and unintentional emissions.**** > > ** ** > > Various modulation types have known spectral profiles, including both > in-band and out-of-band emissions. Knowing where the "shelf" is on the > adjacent channel makes it possible to match that with the "skirt" of the > intended modulation pattern. The "skirt" is not part of the intended > emission, but is important in trying to avoid causing interference on > adjacent channels.**** > > ** ** > > A crude example of this is shown in the following image:**** > > ** ** > > [image: Inline image 1]**** > > ** ** > > Best regards,**** > > > **** > > ** ** > > Andy Lee |**** > > Google Inc. |**** > > tvfool@google.com |**** > > 408-230-0522**** > > ** ** > > On Fri, Sep 20, 2013 at 3:07 AM, Benjamin A. Rolfe > wrote:**** > > ** ** > > On 9/19/2013 9:09 AM, Andy Lee wrote:**** > > The math bears that out, but nonetheless OFCOM are still effectively > proposing that *no* in-block transmissions are allowed in that channel.**= * > * > > ** ** > > Same is true for the FCC. The FCC also assumes that "off" channels are > not used by WSDs.**** > > And that means NO intentional radiation in the channel. **** > > ** ** > > Specifying a low power level like -33 dBm is effectively the same thing a= s > specifying no in-band emissions there.**** > > ** ** > > If you are reading this as "transmitted emissions in band should be lower > than -33dBm" then, no, this is not the same as "no emissions" per FCC > rules. If one were to intentionally transmit at -33dBm where no intention= al > emissions are allowed, that would not be the same as "no" under the rules= . > **** > > > > > **** > > ** ** > > Even if someone did try to put an in-band emission there (regardless of > how impractical that actually is), it would be too low to cause > interference to anyone and no harm has been done to the "RF environment".= * > *** > > Should be a little careful here for a couple reasons. I've designed and > shipped communication systems that operate quite well with transmit power > levels intentionally below -33dBm and do very useful things. It's pretty > easy to design a receive with sensitivity better than -96dBm, so an > intentional radiator at -33dBm near by will be noticed - at 900 MHz your > 10dB above sensitivity at 10m and at 54MHz you'd be 10 dB above sensitivi= ty > at 100m, possibly. And when it comes to protecting their spectrum, people > always use the best propagation model to calculate interfence impact on > them :-). I've probably misunderstood something badly, but -33dBm is > certainly enough power to be noticed. > > I have tried the "too low to be noticed" argument a few times in the past > in regulatory discussions, and incumbent and/or protected users usually s= et > the threshold closer to -120dBm and usually argue that even at really low > TX power, the "aggregate impact" of multiple devices in the "RF > Environment" is an unacceptable impact. We had trouble with this argume= nt > when the intentional radiator TX limit was below the maximum unintentiona= l > emission limits for most non-transmitting devices (-41.3dBm). > > So it would be fairly important to ensure a device does not interpret > -33dBm as it's ok to use that channel so long as it's TX power is below > -33dBm. > > I may be off base here because of how y'all see the DB providing and wha= t > I am expecting to support future needs. "protected users" includes more > than TV stations in the US. > > Not sure that helps, but hope so. **** > > > > > **** > > ** ** > > The advantage of having an "well behaved" spectrum profile (contiguous an= d > without special values like -inf) is that the channel selection algorithm > on the WSDs becomes much simpler and logical. There's no need to have lo= ts > of special boundary condition checks and code paths that only get trigger= ed > under special circumstances. I'd like to avoid ambiguous interpretations > on the device side as much as possible.**** > > Certainly ambiguous interpretations on the device side are a bad thing. > > Some apps are aggregating multiple TV channels to get a logical channel > that that can carry a 'wide' data pipe. Other uses can fit many useful > channels in one TV channel. In 802.15.4m we divide the TV channel up into > multiple physical channels carrying low data rate signals. Right now we > assume a peak power level for the TV channel, and we get that value with > the start frequency and width (or end frequency) from the database. > However, I've heard it proposed to the FCC that we may get different powe= r > limits different parts of the TV channel, changing over time, as a > protection mechanism for deal with narrow band protected users while > allowing effective use of the rest of the TV channel. For what we do, th= is > is a good thing - our physical channel may be less than 200kHz wide. Ther= e > are a LOT of applications in IoT that need < 200kHz channels, and > blocking an entire TV channel to protect a wireless microphone using < > 200kHz of it means there are 28 other usable channels not being used - n= ot > efficient use of the spectrum. > > Hope this helps. > > -Ben > > > **** > > > **** > > ** ** > > Andy Lee |**** > > Google Inc. |**** > > tvfool@google.com |**** > > 408-230-0522**** > > ** ** > > On Thu, Sep 19, 2013 at 8:30 AM, Ray Bellis > wrote:**** > > > On 19 Sep 2013, at 16:21, Andy Lee **** > > wrote: > > > This actually shows that Ofcom has picked a power threshold on channel > 38 of -33 dBm. If you look at the ACLR numbers for class 3, 4, and 5 > devices, you'll see they are 10 dB apart from each other and that they al= l > work out to be -33 dBm on channel 38. > > > > The reason there are no limits for class 1 and 2 devices is because the > in-band power on channels 37 and 39 cannot exceed +36 dBm/8MHz, and > therefore the power on channel 38 will naturally be less than -33 dBm.***= * > > The math bears that out, but nonetheless OFCOM are still effectively > proposing that *no* in-block transmissions are allowed in that channel. > > Per OFCOM / ETSI device interface requirements it would be incorrect for > us to actually send that value of -33 dBm to a device. > > Ray > > **** > > ** ** > > ** ** > > _______________________________________________**** > > paws mailing list**** > > paws@ietf.org**** > > https://www.ietf.org/mailman/listinfo/paws**** > > ** ** > > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws**** > > ** ** > --047d7bd76dba4e6b4204e6d8cbae Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
I was actually hoping to simplify things for devices.
=
1) Having a fully specified spectrum profile without discont= inuities and without "special" values like -inf make it much easi= er to write the client side code. =A0This minimizes the number of special e= dge cases that need to be handled by the parsing logic and "emission f= itting" code on the client.

2) We still seem to be thinking in terms of TV channels= only. =A0PAWS is designed for other frequency bands too, and there won'= ;t always be such a distinct concept of on-channel vs. adjacent-channel emi= ssions.

3) We don't know what future WSD technologies will = be capable of. =A0Wi-Fi already supports a long list of modulation types (e= .g., BPSK, QPSK, DSSS, FHSS, OFDM) and channel widths. =A0Software defined = radios and other technologies can dynamically choose modulation types, chan= nel widths, and power distribution. =A0These agile radio technologies need = the full spectrum profile to help them choose the right combination of emis= sion parameters. =A0WSDs are just a "black box" from the database= 's point of view.





On Fri, Sep 20, 2013 at 2:35 PM, Peter S= tanforth <peter@spectrumbridge.com> wrote:
We have, until know, always worked on the assumption that the d= evice would be certified, or not, to comply with any out of band emissions.= The FCC for instance specifically tests the more stringent rule around cha= nnel 37, as well as the more general case. The Database is not, and cannot = be, the enforcement agency. So simply providing a list of channels that it = can use is sufficient.
It should be of no consequence to a device why it cannot use a channel= other than to behave with its compliant emissions.=A0
I agree wi= th Gabor, why are we overly complicating this?

From: "Gabor.Bajko@nokia.com" <Gabor.Bajko@nokia.= com>
Date: Friday, September 20, 2013 4= :54 PM
To: "tvfool@google.com" <tvfool@google.com&= gt;, "ben@blin= dcreek.com" <ben@blindcreek.com>
Cc: "paws@ietf.org" <paws@ietf.org>
=
Subject: Re: [paws] Spectrum e= ncoding discussion

Ar= en=92t we talking past each other in this thread?

If the rules are supposed to specify what is= the max intended power level a device can put into a channel (available or= not), then I also think this is what the DB should communicate to the device.

If Ofcom specifies that the max leakage into an unav= ailable channel is -33dbm, I assume the device will not be certified if it = leaks more. If the device supports multiple modulation types and one of them leaks more than what is permitte= d in that regulatory domain, then the device will need to know it, and in t= hat regulatory domain avoid using that particular modulation type. How does= the device come to know it? Andy proposes the DB to indicate that level for the unavailable channels. Other= s folks seem to suggest a device built to operate under a certain ruleset h= as to implicitly know it.

Another way of looking at it might be to say that the max level of = permitted unintentional leakage into an adjacent channel is part of the rul= esetInfo, and the spectrum response only lists the available channels. Could this be a w= ay forward?

-=A0=A0=A0=A0=A0=A0=A0= =A0=A0 gabor

=A0

From: p= aws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext Andy Lee
Sent: Friday, September 20, 2013= 1:00 PM
To: Benjamin A. Rolfe
Cc: Protocol to Access W= hite Space database
Subject: Re: [paws] Spectrum encoding discuss= ion

=A0

Hi = Ben,

=A0

And that means NO intentional radiation in the channel.=A0=A0

=A0

If you ar= e reading this as "transmitted emissions in band should be lower than = -33dBm" then, no, this is not the same as "no emissions" per= FCC rules. If one were to intentionally transmit at -33dBm where no intentional emissions are allowed, that would = not be the same as "no" under the rules.

=

=A0

Th= ere is certainly no intention to encourage any malicious behavior. =A0In ge= neral, we expect devices to be trying to do the right thing and just need s= ome information to understand where the boundaries are. =A0These boundaries include both intentional and unintenti= onal emissions.

<= u>=A0

Various modulation types have known spectral profil= es, including both in-band and out-of-band emissions. =A0Knowing where the = "shelf" is on the adjacent channel makes it possible to match tha= t with the "skirt" of the intended modulation pattern. =A0The &quo= t;skirt" is not part of the intended emission, but is important in try= ing to avoid causing interference on adjacent channels.

=A0

A crude example= of this is shown in the following image:

=A0

3D"Inline

=

=A0

Best regards,=


= =A0

Andy Lee=A0|=A0Google Inc. | =A0tvfool@google.com= =A0|=A0408-230-0522

Andy Lee=A0|

=A0Google = Inc. |

=A0tvfool@google.com=A0|

=A0408-230-0522

=A0

On Fri, Sep 20,= 2013 at 3:07 AM, Benjamin A. Rolfe <ben@blindcreek.com> wrote:

=A0

On 9/19/2013 9:09 AM, Andy Lee wrote:

The math bears that out, but nonetheless=A0OFCOM=A0are still effect= ively proposing that *no* in-block transmissions are allowed in that channe= l.

=A0

Same is true for the FCC. =A0The FCC also assumes that= "off" channels are not used by WSDs.

And that means NO intentional radiation in the= channel.=A0

=A0

<= /div>

Specifying a low power level like -33 dBm is effecti= vely the same thing as specifying no in-band emissions there.=

=A0

If you are reading this as "transmitted emissio= ns in band should be lower than -33dBm" then, no, this is not the same= as "no emissions" per FCC rules. If one were to intentionally tr= ansmit at -33dBm where no intentional emissions are allowed, that would not be the same as "no" under the rules.




=A0

Even if someone did try to put an in-band emission there (regardless of ho= w impractical that actually is), it would be too low to cause interference = to anyone and no harm has been done to the "RF environment".

Should be a little careful here fo= r a couple reasons.=A0 I've designed and shipped communication systems = that operate quite well with transmit power levels intentionally below -33d= Bm and do very useful things. It's pretty easy to design a receive with sensitivity better than -96dBm, so an intentional radiator at= -33dBm near by will be noticed - at 900 MHz your 10dB above sensitivity at= 10m and at 54MHz you'd be 10 dB above sensitivity at 100m, possibly. A= nd when it comes to protecting their spectrum, people always use the best propagation model to calculate interf= ence impact on them :-).=A0 I've probably misunderstood something badly= , but -33dBm is certainly enough power to be noticed.

I have tried the "too low to be noticed" argument a few times in = the past=A0 in regulatory discussions, and incumbent and/or protected users= usually set the threshold closer to -120dBm and usually argue that even at= really low TX power, the "aggregate impact" of multiple devices in the "RF Environment" is an unacceptable i= mpact.=A0=A0 We had trouble with this argument when the intentional radiato= r TX limit was below the maximum unintentional emission limits for most non= -transmitting devices (-41.3dBm).

So it would be fairly important to ensure a device does not interpret -33dB= m as it's ok to use that channel so long as it's TX power is below = -33dBm.

I may be off base here because of=A0 how y'all see the DB providing and= what I am expecting to support future needs. "protected users" i= ncludes more than TV stations in the US.=A0

Not sure that helps, but hope so.=A0




<= /u>=A0

The advantage of having = an "well behaved" spectrum profile=A0(contiguous and without spec= ial values like -inf)=A0is that the channel selection algorithm on the WSDs= becomes much simpler and logical. =A0There's no need to have lots of s= pecial boundary condition checks and code paths that only get triggered under spe= cial circumstances. =A0I'd like to avoid ambiguous interpretations on t= he device side as much as possible.

Certainly ambiguous interpretations on the device side are a bad thing.

Some apps are aggregating multiple TV channels to get a logical channel tha= t that can carry a 'wide'=A0 data pipe. Other uses can fit many use= ful channels in one TV channel. In 802.15.4m we divide the TV channel up in= to multiple physical channels carrying low data rate signals.=A0 Right now we assume a peak power level for the TV ch= annel, and we get that value with the start frequency and width (or end fre= quency) from the database. However, I've heard it proposed to the FCC t= hat we may get different power limits different parts of the TV channel, changing over time, as a protection mec= hanism for deal with narrow band protected users while allowing effective u= se of the rest of the TV channel.=A0 For what we do, this is a good thing -= our physical channel may be less than 200kHz wide. There are a LOT of applications=A0 in IoT that need <= 200kHz channels,=A0 and blocking an entire TV channel to protect a wireles= s microphone using < 200kHz of it means there are 28 other usable channe= ls=A0 not being used - not efficient use of the spectrum.=A0=A0

Hope this helps.=A0=A0

-Ben



=A0

=A0tvfo= ol@google.com=A0|

Andy Lee=A0|

<= /td>

=A0Google Inc. |

=A0408-230-0522=

=A0

On Thu, Sep 19, 2013 at 8:= 30 AM, Ray Bellis <Ray.Bellis@nominet.org.uk> wrote:


On 19 Sep 2013, at 16:21, Andy Lee <tvfool@google.com>

=A0wrote:

> This actually shows that Ofcom has picked a power threshold on channel= 38 of -33 dBm. =A0If you look at the ACLR numbers for class 3, 4, and 5 de= vices, you'll see they are 10 dB apart from each other and that they al= l work out to be -33 dBm on channel 38.
>
> The reason there are no limits for class 1 and 2 devices is because th= e in-band power on channels 37 and 39 cannot exceed +36 dBm/8MHz, and there= fore the power on channel 38 will naturally be less than -33 dBm.=

The math bears = that out, but nonetheless OFCOM are still effectively proposing that *no* i= n-block transmissions are allowed in that channel.

Per OFCOM / ETSI device interface requirements it would be incorrect for us= to actually send that value of -33 dBm to a device.

Ray

=A0=

<= /u>=A0

__________________________________________=
_____
paws mailing list
paws@ietf.org
https://www.=
ietf.org/mailman/listinfo/paws

=A0


_______________________________________________
paws mailing list
paw= s@ietf.org
https://www.ietf.org/mailman/listinfo/paws

=A0

<= /div>

--047d7bd76dba4e6b4204e6d8cbae-- --047d7bd76dba4e6b4404e6d8cbaf Content-Type: image/png; name="image001.png" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: 999cbcc67a765c1b_0.1 iVBORw0KGgoAAAANSUhEUgAAAZAAAAGQCAYAAACAvzbMAAAAAXNSR0IArs4c6QAAFFxJREFUeNrt 3XuQlXXhx/HPIfzhWikgCaMToIhBRjqZOfaPNTbWFpNNpSNdtGGyZNSAdMyw0ZhRCC21zHI0Z/Cv bOoPxy5qJuBfTTOMIpe4tKAmeCmSaMIFlH1+fzyd3QX2xrrLuezrNbMDu+e6z3nO8z7f79nzPJWi KIoAwBEaZREAICAACAgAAgKAgACAgAAgIEdPpVKxEAD6C0ilUun8mjBhQi6++OI8//zzlhoA/Y9A iqJIURTZtGlTZs6cmcsvv9xSA2DgU1gTJkzIokWL8uyzzyZJ9u3blwULFmTSpEmZNGlSFixYkH37 9mX69OnZvHlzkmTHjh0ZNWpUXn755STJpk2bMn369M7r7OjoyK233ppTTz0148ePz9y5c7Nnz57O 0c9dd92V9773vRk1que72d/l77vvvkydOjUtLS05//zzs379+jz33HOZNm1aun8AvyiKTJs2LWvX ru33ervrbRlUb//222/PxIkTc+KJJ+aaa67J/v37B3TfAZoqIDt37sySJUty9tlnJ0luu+22bNiw IatXr87q1auzdu3aLFmyJK2trVm1alWS5NFHH82YMWPyu9/9LkmycuXKfPrTn+68zrvvvjurVq3K ihUrsnXr1rz55pu5+eabO09/+umn85e//CUdHR093qf+Lv/EE09k1apV2blzZ1pbW3PVVVflrLPO ytixY7NixYrO8z311FMZN25cPvjBDw7oeqt6WwZVTz75ZJ555pmsXbs2mzdvztKlSwd83wHqXtGH JJ1f48ePL2bPnl20tbUVRVEUp512WrFhw4bO865bt66YNm1a8Yc//KGYM2dOURRF0draWtxwww3F 7Nmzi6IoiksvvbR47LHHOi8zY8aMYtOmTZ3fv/rqq8WUKVM6b/uFF17o6+71e/lXXnml87Q9e/YU LS0tRVEUxU9/+tPi0ksv7TztkksuKe69994BX29Vb8uger7up61fv77ztP5uA6ARVPramWKlUklv J7e0tGTXrl059thjkyR79+7NuHHj8vrrr2fWrFlZs2ZNJk+enG3btmXatGl56aWXcuaZZ2bjxo2d lznuuOM6p3WKokhHR0dGjRqVAwcOpFKppKOjo8+/eurv8ofe9+rP/v3vf2fKlCnZunVriqLI6aef nhdffDFjx449ouvtbRm0t7enUqmkvb29x9P6uw2ApprCOtTJJ5+cbdu2dX7f1taWU045JS0tLZk+ fXruvffenHvuuRk7dmzOOeec3HPPPZk5c2bnBjVJJk+enLa2trz11ls5cOBAiqI4aAPa35/M9nf5 3owdOzaf+cxnsnz58ixfvjyzZ8/ujMeRXG9vy6Cq+2nbtm076LTB3neAhg/InDlzMn/+/Gzfvj3b t2/P/PnzM2fOnCRJa2trli5dmosuuihJctFFF2Xp0qVpbW096DrmzZuXK6+8Mhs3bsz+/fuzbt26 XHbZZQO+D2/n8nPnzs0DDzyQX/ziF5k7d+6grrevZZAkCxcuzI4dO7Jjx44sXLgwX/7yl4fsdweo +/dAetPe3l5ce+21xcSJE4uJEycW1157bdHe3l4URVFs2bKlSFI899xzRVEUxZo1a4okxd/+9reD ruPAgQPFT37yk2LGjBnFmDFjilmzZhWPPPJIv7c92Mt3/1lHR0cxderUYurUqUVHR8egrrevZZCk WLZsWXHSSScV48aNK+bNm1fs3bt3QLcB0PDvgTB4fb1/BDCip7AAGNlGWwS83ZEWjc1IGSMQT0oA AQGg/pnCwqhrBDL1iBEIACNsBFKpJAN9tXok56XhLV5sGfTnllssAxphBFKpJA88cPjPH3usPK2+ xuQD+9lw3dbR/D2rXwB1G5Akuf/+5NB9NN1+e2P8ds04cikKIzKgLvQ/hXXBBckvf5l85Svl97// fTJjRvK/Y34kSfbtS77zneThh8vvL7ssWbYsGTMm2b8/WbiwPO2YY5Lrrjv8FfWhG8Tepq22bEkW LUpWrkzeeiu58MIycO95z8Ejg+plu19PX/exUkl+/vPkBz9IXnstOfvscuT1gQ/0Pvqo/vv668kZ ZyQbNyYTJpQ/e/PN5JRTkvXrk5NOKs+7bFnyox+V93vOnOTOO5P/+7/y/B0dyZIlyYMPJrt3J5/7 XHLPPck73zmiV84rrvAErXroIcuARhyBXH11ufGrbogXL07mzz/4PLfdlmzYkKxeXX6tXVtuEJPy 3y1byp+tXl1Ofw3WJZeU92f79uTvfy830t/9btd96+vVeV/3MUmeeKKM4s6dSWtrctVVfY9qqrc1 blwZo/vv7zrPypXJRz5SxqPqySeTZ54pb3fz5qTbwaVy993lba9YkWzdWgbIwaWAOtf3vrCqr+Av vji5/PLyFfPPftb1Hkj1otOmJb/9bfL+95ffr19fvopua0tOPz159NGDT5s1q+dRQk8jkL7eRP/P f5Izz0xeeqn/6+nrPlYqySuvJJMmlae98UY5mnjjjb6XS9W2bcnHP15e1zHHJPPmlSO36t51K5Uy XtXb3rChXKZtbeX3M2cmjzySvO995fevvZacd17ywgvp97Gp9QrU7b2Yofgz3u5vohuB9DwCGYo3 0Yf6cUNAet9I/elPyQ03lN8vWZJ88pMHb8BaWpJdu5LqsT727i1fmbe393xaS8vgArJ6dTkN9eyz 5XUmyTveUU4L9Xc9fd3HI5lG6+20Sy5JPv/5MhozZ5b3saWl6/zt7T3fdpIcd1w51Vcd2XR0JKNG Hf7eU5MH5NC/wBKQ3qew3m5EBISjM4WVJJ/4RLnRa29P/neMj4OcfHL5Kryqra2cXkrKf7uftnXr wZc99tiDX+m/+mrv9+Oyy8qtSltbGY1//atrI9vfXyX1dR+P/Nl3+M+uvz758Y+TP/85Of/8rnh0 H6V0/3/32548uet3OnCgDIODSwFNEZAk+etfy6+eNp5z5pTvi2zfXn7Nn1/+LEm+9KXyTfQdO8qv BQsOvuw55yQ//GGyZ0/y/PPJN7/Z+33Ysyc5/vjyzeUXX0y+8Y2u0yZMKN/I7k1f9/FI9XRb551X Tl8tWpR89auHX6b7Mli4MOl2cKnMm5dceWV5nfv3J+vWdU1/jVBGH5YHzRSQvnzve+W0zYc/XH6d eWZy003laTfdlJx2Wvm+x4c+dPgI5r77yvdUJkwo30f41Kd6v50HH0xuvDF597vL815wQddpN96Y fPSjvY9E+rqPR6q327r++nKE9bGPHX6ZCy8sf/9Zs8r3YxYt6jrt2muTz362nAI7/vgyLr3Frftn QHweBKghB5QaSvfdV46ili07fKPfpIt5uN4D8Yr7cEP5Rrr3QBgKdqY4VHbvTu66q/xTXAABYYAv 58q/mrrnnsG/MQ8gICNQf1MApgiAJmR37gAICAACAoCAQP8cSMryQkAG5Eg+++ZzcgANGBAHJKy/ qD3+ePmh9paWcvdeX/96uUuwZuJDhJYLTTICcUDC+nLnneUeU/75z2TNmmT0aBsWoE4DUj0gYVX1 gITd7dtX7iNx0qTya8GC8mdJuW/Aq69OTjyxPO2OOwY/ctiyJfniF8vrOuGEctdRO3f2vmuo7v/v 6z5WKuVeSKZOLV/Zn39+ebiQvkYf1dvatas8IOLOnV3nefPN8lhS//hH13lvvz2ZOLG879dc07X3 9qTce/uttyannpqMH5/MnVvuN7Inf/xjebyrd72rvI077jj44JAAdRMQByTseVRTLwckXLEiOfdc KzJw9PW5M0UHJOx7uVTV4oCESXnMqi98oXxf5IwzarQCDdFO+exIcWCGaoeKdqbIURmBJOXexm+7 Lfn+9w8/nEeSvPxyucf2qtNPLw97kZT/HnraYK1eXb6BPH58uVE+4YRywz8Qfd3HpCseSXmAwOrB AgfitNPKEcdvflOGZeXKMhCHnqdq2rSDb/vFF8sQjh5dHmBx0qQyin1ZtaoM4MMP1y4ewMg2oH1h VQ9ImPR9QMLqK+yeDkhYPa23AxIed1z5fX8HJLz55uTXvy7jsXt3+Z5C9VV+X/q6j0f+6u3wn11/ fTm1N2VK7wckrN52TwckfPzx8j2YgfjVr5Jvf7sc2Z1zTh2uVYP5kMKqbsd2meKJ2fty6v7N00d+ +aE4oDocyQgkcUDC7mp5QMI77ywPT//UU3UaD0BAjoQDEnaNQob7gITXXVf+AcHMmV1/CVapJP/9 r5UZOLockXAIjcADEvb8Zuwg3hFffPcJXRf5mnWpNw8t7/r/LQt2D/BCh7/z7k106mYEQtcBCb/1 LcviSHWPB5YbjcMBpYbkVbgDEgICwiA4IOHQMX3V//LpPo0FtWQKCwABAUBAABAQAAQEAAQEAAEB QEAAEBDol91xWH4ICAACArVhNyaWEwICgIAAgIAAICAACAgAAgKAgACAgAAgIDQRu+GwHBEQAAQE asPuOSwvBAQAAQEAAQFAQAAQEAAEBAABAQABAUBAaCJ2v2F5IiAACAjUht1yWG4ICAACAgACAoCA ACAgAAgIAAICAAICgIAAICCMdPbbZLkiIAAICNSG/TlZfggIAAICAAICgIAAICAACAgAAgIAAgKA gNBE7G7D8kVAABAQqA274bAcERAABAQABAQAAQFAQAAQEAAEBAAEBAABoYnYzYbljIAAgIBQG3a/ YXkiIAAICAAICAACAoCAACAgAAgIAAgIAAJCE7F7DcsbAQEAAaE27HbDckVAABAQABAQAAQEAAEB QEAAQEAAEBAABAQAAWGks18myx0BAQABoTbsr8nyRUAAEBAAEBAABAQAAQFAQABAQAAQEAAEhCZi dxqWPwICAAJCbdjNhuWMgACAgAAgIAAICAACAoCAAICAACAgAAgITWTxqgssBI8DAgIAAkIN2L2G 5Y2AAICAACAgAAgIAAICgIAAgIAAICAACAhNxO4zPB4ICAAICLVhtxqWOwICAAICgIAAICAACAgA AgIAAgKAgAAgIAAICCOd/S55XBAQABAQasP+mCx/BAQABAQAAQGgRkZXKhVLAUYw2wCMQAAQEADq 3+iiKCwFGGE87zECAaB2IxCLoI4sXtz4v4LdZdT34/PxVbnlY083/i9yyy0eTAGhWcIBNXnOCImA CEdzuuIKD3G9PA4PPSQkCMjICEcjb3l3ndD1/7M91HXh7LOSNd3Xr6mN+7v0VkIhERDh8JIdBvQc ERIBEQ7hACEREIQDhERAEA4QEgREOEBIhERAhAMQEgERDkBIGl6lsFc14RiqxXL3CQcvhq9ZVerF Q8sP/v6WBbtH6ILo5xOVQmIEIhyAEYkRiHA06AjE6KO+RyEjdgRiRGIEIhyAEYmACAcgJAIiHICQ CIhwCAcIiZAIiHAAQiIgwgEIiYAIByAkAiIcgJCMwJA09wcJhePoLWq7Mal7dmcynAt3ZH4gsTlH IMIBGJEYgQhH441AjD4aYxRiBGJEYgQiHIARiYAIByAkAiIcAE0eksYKiHAAQiIgwgEISWOHpL4D IhyAkNRtSOozIMIBCEndh6S+AiIcgJA0TEjqIyDCAdBwIantJ9GFoynYD1bjsD+sRn3g6vOT7bUZ gQgHQMOPSI7uCEQ4mn4EYvTRWKMQIxAjkvofgQgHQNONSIY3IMIB0LQhGZ6ACAdA04dkaAMiHAAj JiRDExDhABhxIXl7AREOgBEbksEFRDgARnxIjiwgwgEgJP8zsA8SCge9rRp2Y9Jw7M6ErpXh7X0g cbRwABiRDGZE0vMIRDgYxAjE6KMxRyFGIAx2RDJaOAAYzIhktHAAMJiQjO4zHsIBICS9hGS0cAAw mJCMOuxM4sEAHfonvHgcGQEh6daI0YIBwGBGJKMsCYZkffqaZeDxYqQREMA0FgKCDQ4gIMAwM42F gGBDBAgIjcH0lccVBAQAAaE2TF95/BAQGBDTHB5fEBAABITaMP3hcURAADqZxkJAsGEBBAQYXqax EBBscAABob6YvvJ4g4AAICDUhukrjysICANiOsPjDgICgIBQG6Y5PL4gIEC/TGMhINiAAAICDC/T WAgINiyAgFAbpq+wHiAgAAgItWH6yuMNAsKAmLbA+oCAACAg1IbpDI87CAgwaKaxEBBsKAABAYaX aSwEBBsQQEAYXqavsH4gIAAICLVh+grrAQLCgJiewHqCgAAgINSGaQusDwgIMORMYyEg2CAAAgIM L9NYCAg2FICAMDRMX2G9QUAAEBBqw/QV1g8EhAExDYH1BwEBQECoDdMTWE8QEOCoMY0lIHjiAwgI MLxMYyEg2CAAAsKRMX2F9QkBAUBAqA3TV1hvEBAGxHQD1isEBAABoTZMQ2D9QUCAmjONJSB4ggMI CDC8TGMJCJ74AAJCz0xfYT1DQAAQEGrD9BXWJwSEATGtgPUNAQFAQKgN0w1YrxAQoG6ZxhIQPJEB BAQYXqaxBARPcAABGelMX2H9Q0AAEBBqw/QV1jMEhAExfYD1EAEBQECoDdMKWN8QEKDhmMYSEDxh AQQEGF6msQQET2QAARkpTF9hvURAABAQasP0FdY/BIQBMU2A9RMBAUBAqA3TB1gPERCgaZjGEhA8 MQEBARheprEEBE9YAAFpNqavsL4iIAAICLVh+grrJQKC6QCstwgIAAJCHTNNgPUTAQGanmksAcET EBAQgOFlGktA8MQEBIRGZfoK6zECAoCAUBumr7C+IiAY9mN9RkAAEBBMB4D1FgEB6o9pLAHBEw0Q EIDhZRpLQPAEBASEemf6Cus3AgKAgFAbpq+wHiMgGN6D9VxAABAQDPvB+oyAAI3DNJaA4AkFCAjA 8DKNJSB4ogECQr0wfYX1HgEBQECoDdNXWL8REAzjwfovIAAICIb3YD1HQIDGZxpLQPDEAQQEYHiZ xhIQPKEAAeFoM30Fng8CAoCAUBumr7DeIyAYroPnhYAAICAYxoP1HwEBmpdpLAHBEwQQEIDhZRpL QPDEAQSE4WL6CjxPBASApvf/5iHIqNxWR4QAAAAASUVORK5CYII= --047d7bd76dba4e6b4404e6d8cbaf-- From dharasty@appcomsci.com Fri Sep 20 17:16:09 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CFC521F9F3A for ; Fri, 20 Sep 2013 17:16:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.948 X-Spam-Level: X-Spam-Status: No, score=-0.948 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FYqRRdDqK8FQ for ; Fri, 20 Sep 2013 17:15:57 -0700 (PDT) Received: from thumper.appcomsci.com (thumper.appcomsci.com [205.132.0.196]) by ietfa.amsl.com (Postfix) with ESMTP id 795AB21F9C68 for ; Fri, 20 Sep 2013 17:15:55 -0700 (PDT) Received: from bambi.appcomsci.com (bambi.appcomsci.com [192.4.5.54]) by thumper.appcomsci.com (8.14.2/8.14.2) with ESMTP id r8L0FqbO015414 for ; Fri, 20 Sep 2013 20:15:52 -0400 (EDT) Received: from brg-ats-exhb1.ats.atsinnovate.com (exch.appcomsci.com [192.4.5.112]) by bambi.appcomsci.com (8.14.4/8.13.4) with ESMTP id r8L0Fnn5026122 for ; Fri, 20 Sep 2013 20:15:51 -0400 Received: from RRC-ATS-EXMB2.ats.atsinnovate.com ([2002:c004:56a::c004:56a]) by brg-ats-exhb1.ats.atsinnovate.com ([2002:c004:570::c004:570]) with mapi; Fri, 20 Sep 2013 20:15:42 -0400 From: "Harasty, Daniel J" To: "paws@ietf.org" Thread-Topic: [paws] Spectrum encoding discussion Thread-Index: AQHOtUTmeub++vJf50Opuy0OoCfF4pnNaQ2AgAAHT4CAAAJfAIAACwIAgAEtGoCAAKW+AIAADywAgAALVgCAABr4AP//vY7w Date: Sat, 21 Sep 2013 00:15:21 +0000 Message-ID: References: <1ECAFF543A2FED4EA2BEB6CACE08E476053422B0@008-AM1MPN1-006.mgdnok.nokia.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Content-Type: multipart/related; boundary="_004_EC510C021D06A34C92F5A5A488B5290B0CF2EF13rrcatsexmb2atsa_"; type="multipart/alternative" MIME-Version: 1.0 Subject: Re: [paws] Spectrum encoding discussion X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Sep 2013 00:16:09 -0000 --_004_EC510C021D06A34C92F5A5A488B5290B0CF2EF13rrcatsexmb2atsa_ Content-Type: multipart/alternative; boundary="_000_EC510C021D06A34C92F5A5A488B5290B0CF2EF13rrcatsexmb2atsa_" --_000_EC510C021D06A34C92F5A5A488B5290B0CF2EF13rrcatsexmb2atsa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All: I know this is a long winded reply to an already laborious conversation. B= ut I think I can put a finger on the essential "disagreement", and even off= er a compromise that will allow us to move forward. Hint: the whole "option 1"/"option 2" debate is a bit of a misdirection, as= those two options did NOT capture the two sides of the essential disagreem= ent; the issue at hand is really about "is an out-of-band emission limit a = good way to express that a channel is unavailable?" There seems to be the camp that "out of band emission limits" are the SAME = as "channel unavailable". In my reading of the FCC rules, that is simply n= ot the case. There are times when FCC rules require me (as a Database) to = say "this channel is unavailable" other than "a protected entity occupies t= his channel". For example: * It is a channel categorically excluded from the Whitespace spectr= um (e.g. US Channel 3 or Channel 37). * There is an ad-hoc (FCC provided) polygon establishing an ad-hoc = exclusion zone. * A device is blacklisted. To say that "Channel 37 is available at -36.8 dBm" is just not the same as = "Channel 37 is unavailable", IMO. To tell all devices in an ad-hoc exclusion zone that "all channels are avai= lable at -36.8 dBm" is just not the same as "all channels are unavailable". To tell a blacklisted device that "all channels are available at -36.8 dBm"= is just not the same as "all channels are unavailable". In other words: If PAWS does not give me a way to say a channel is unequivo= cally "unavailable", then, in my opinion as a Database provider, it is not = sufficiently expressive for me to meet the FCC rules. If we DO use PAWS to encode out-of-band emissions limits, I have to say, I = think it is farfetched that a device implemented today to today's rules wil= l be able to - in the future - either "take advantage" of a less stringent = "out-of-band mask" or comply to a more stringent mask. As marvelous as SDR= s are/can be, that degree of flexibility is just not common in consumer-gra= de mass market devices owing to cost. That leads me to the conclusion that= expecting to use PAWS that way is just not going to be that useful. However, I realize we may differ on this point. But the notion of "PAWS av= ailable-spectrum replies should encode out-of-band emissions limits" is jus= t a separate notion from "PAWS must allow a way to encode 'channel unavaila= ble'". It is confounding those two concepts that - IMO - has lead to the c= urrent "disagreement". OK, time for my proposed grand compromise: * Let's define a way to unequivocally encode "channel unavailable" = that is NOT synonymous with "out of band emissions limits". I need it as a= Database provider. (Again: I offer to recap several different ways to do = this later.) * Once we have a way to unequivocally encode "channel unavailable",= we can have a separate discussion as to whether or not it is ever used. P= erhaps different Databases will interpret their legal/regulatory obligation= s differently. Or even, a given Database may use "-36.8 dBm" in some cases= and "channel unavailable" in others. The purpose of this WG is to produce a protocol that: 1. Provides for interoperability (because it is sufficiently clear). 2. Allows all parties to meet their legal/regulatory obligations as t= hey interpret them. I feel the above proposed compromise accomplishes both. Dan Harasty From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of And= y Lee Sent: Friday, September 20, 2013 7:12 PM To: Peter Stanforth Cc: paws@ietf.org Subject: Re: [paws] Spectrum encoding discussion I was actually hoping to simplify things for devices. 1) Having a fully specified spectrum profile without discontinuities and wi= thout "special" values like -inf make it much easier to write the client si= de code. This minimizes the number of special edge cases that need to be h= andled by the parsing logic and "emission fitting" code on the client. 2) We still seem to be thinking in terms of TV channels only. PAWS is desi= gned for other frequency bands too, and there won't always be such a distin= ct concept of on-channel vs. adjacent-channel emissions. 3) We don't know what future WSD technologies will be capable of. Wi-Fi al= ready supports a long list of modulation types (e.g., BPSK, QPSK, DSSS, FHS= S, OFDM) and channel widths. Software defined radios and other technologie= s can dynamically choose modulation types, channel widths, and power distri= bution. These agile radio technologies need the full spectrum profile to h= elp them choose the right combination of emission parameters. WSDs are jus= t a "black box" from the database's point of view. Andy Lee | Google Inc. | tvfool@google.com | 408-230-0522 On Fri, Sep 20, 2013 at 2:35 PM, Peter Stanforth > wrote: We have, until know, always worked on the assumption that the device would = be certified, or not, to comply with any out of band emissions. The FCC for= instance specifically tests the more stringent rule around channel 37, as = well as the more general case. The Database is not, and cannot be, the enfo= rcement agency. So simply providing a list of channels that it can use is s= ufficient. It should be of no consequence to a device why it cannot use a channel othe= r than to behave with its compliant emissions. I agree with Gabor, why are we overly complicating this? From: "Gabor.Bajko@nokia.com" > Date: Friday, September 20, 2013 4:54 PM To: "tvfool@google.com" >, "ben@blindcreek.com" > Cc: "paws@ietf.org" > Subject: Re: [paws] Spectrum encoding discussion Aren't we talking past each other in this thread? If the rules are supposed to specify what is the max intended power level a= device can put into a channel (available or not), then I also think this i= s what the DB should communicate to the device. If Ofcom specifies that the max leakage into an unavailable channel is -33d= bm, I assume the device will not be certified if it leaks more. If the devi= ce supports multiple modulation types and one of them leaks more than what = is permitted in that regulatory domain, then the device will need to know i= t, and in that regulatory domain avoid using that particular modulation typ= e. How does the device come to know it? Andy proposes the DB to indicate th= at level for the unavailable channels. Others folks seem to suggest a devic= e built to operate under a certain ruleset has to implicitly know it. Another way of looking at it might be to say that the max level of permitte= d unintentional leakage into an adjacent channel is part of the rulesetInfo= , and the spectrum response only lists the available channels. Could this b= e a way forward? - gabor From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of ext Andy Lee Sent: Friday, September 20, 2013 1:00 PM To: Benjamin A. Rolfe Cc: Protocol to Access White Space database Subject: Re: [paws] Spectrum encoding discussion Hi Ben, And that means NO intentional radiation in the channel. If you are reading this as "transmitted emissions in band should be lower t= han -33dBm" then, no, this is not the same as "no emissions" per FCC rules.= If one were to intentionally transmit at -33dBm where no intentional emiss= ions are allowed, that would not be the same as "no" under the rules. There is certainly no intention to encourage any malicious behavior. In ge= neral, we expect devices to be trying to do the right thing and just need s= ome information to understand where the boundaries are. These boundaries i= nclude both intentional and unintentional emissions. Various modulation types have known spectral profiles, including both in-ba= nd and out-of-band emissions. Knowing where the "shelf" is on the adjacent= channel makes it possible to match that with the "skirt" of the intended m= odulation pattern. The "skirt" is not part of the intended emission, but i= s important in trying to avoid causing interference on adjacent channels. A crude example of this is shown in the following image: [Inline image 1] Best regards, Andy Lee | Google Inc. | tvfool@google.com | 408-230-0522 On Fri, Sep 20, 2013 at 3:07 AM, Benjamin A. Rolfe > wrote: On 9/19/2013 9:09 AM, Andy Lee wrote: The math bears that out, but nonetheless OFCOM are still effectively propos= ing that *no* in-block transmissions are allowed in that channel. Same is true for the FCC. The FCC also assumes that "off" channels are not= used by WSDs. And that means NO intentional radiation in the channel. Specifying a low power level like -33 dBm is effectively the same thing as = specifying no in-band emissions there. If you are reading this as "transmitted emissions in band should be lower t= han -33dBm" then, no, this is not the same as "no emissions" per FCC rules.= If one were to intentionally transmit at -33dBm where no intentional emiss= ions are allowed, that would not be the same as "no" under the rules. Even if someone did try to put an in-band emission there (regardless of how= impractical that actually is), it would be too low to cause interference t= o anyone and no harm has been done to the "RF environment". Should be a little careful here for a couple reasons. I've designed and sh= ipped communication systems that operate quite well with transmit power lev= els intentionally below -33dBm and do very useful things. It's pretty easy = to design a receive with sensitivity better than -96dBm, so an intentional = radiator at -33dBm near by will be noticed - at 900 MHz your 10dB above sen= sitivity at 10m and at 54MHz you'd be 10 dB above sensitivity at 100m, poss= ibly. And when it comes to protecting their spectrum, people always use the= best propagation model to calculate interfence impact on them :-). I've p= robably misunderstood something badly, but -33dBm is certainly enough power= to be noticed. I have tried the "too low to be noticed" argument a few times in the past = in regulatory discussions, and incumbent and/or protected users usually set= the threshold closer to -120dBm and usually argue that even at really low = TX power, the "aggregate impact" of multiple devices in the "RF Environment= " is an unacceptable impact. We had trouble with this argument when the i= ntentional radiator TX limit was below the maximum unintentional emission l= imits for most non-transmitting devices (-41.3dBm). So it would be fairly important to ensure a device does not interpret -33dB= m as it's ok to use that channel so long as it's TX power is below -33dBm. I may be off base here because of how y'all see the DB providing and what = I am expecting to support future needs. "protected users" includes more tha= n TV stations in the US. Not sure that helps, but hope so. The advantage of having an "well behaved" spectrum profile (contiguous and = without special values like -inf) is that the channel selection algorithm o= n the WSDs becomes much simpler and logical. There's no need to have lots = of special boundary condition checks and code paths that only get triggered= under special circumstances. I'd like to avoid ambiguous interpretations = on the device side as much as possible. Certainly ambiguous interpretations on the device side are a bad thing. Some apps are aggregating multiple TV channels to get a logical channel tha= t that can carry a 'wide' data pipe. Other uses can fit many useful channe= ls in one TV channel. In 802.15.4m we divide the TV channel up into multipl= e physical channels carrying low data rate signals. Right now we assume a = peak power level for the TV channel, and we get that value with the start f= requency and width (or end frequency) from the database. However, I've hear= d it proposed to the FCC that we may get different power limits different p= arts of the TV channel, changing over time, as a protection mechanism for d= eal with narrow band protected users while allowing effective use of the re= st of the TV channel. For what we do, this is a good thing - our physical = channel may be less than 200kHz wide. There are a LOT of applications in I= oT that need < 200kHz channels, and blocking an entire TV channel to prote= ct a wireless microphone using < 200kHz of it means there are 28 other usab= le channels not being used - not efficient use of the spectrum. Hope this helps. -Ben Andy Lee | Google Inc. | tvfool@google.com | 408-230-0522 On Thu, Sep 19, 2013 at 8:30 AM, Ray Bellis > wrote: On 19 Sep 2013, at 16:21, Andy Lee > wrote: > This actually shows that Ofcom has picked a power threshold on channel 38= of -33 dBm. If you look at the ACLR numbers for class 3, 4, and 5 devices= , you'll see they are 10 dB apart from each other and that they all work ou= t to be -33 dBm on channel 38. > > The reason there are no limits for class 1 and 2 devices is because the i= n-band power on channels 37 and 39 cannot exceed +36 dBm/8MHz, and therefor= e the power on channel 38 will naturally be less than -33 dBm. The math bears that out, but nonetheless OFCOM are still effectively propos= ing that *no* in-block transmissions are allowed in that channel. Per OFCOM / ETSI device interface requirements it would be incorrect for us= to actually send that value of -33 dBm to a device. Ray _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws --_000_EC510C021D06A34C92F5A5A488B5290B0CF2EF13rrcatsexmb2atsa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All:=

 

I know this is a long winded reply to an already = laborious conversation.  But I think I can put a finger on the essenti= al “disagreement”, and even offer a compromise that will allow = us to move forward.

 

Hint: the whole “= option 1”/”option 2” debate is a bit of a misdirection, a= s those two options did NOT capture the two sides of the essential disagree= ment; the issue at hand is really about “is an out-of-band emission l= imit a good way to express that a channel is unavailable?”=

 

There seems to be the camp that “out of band emis= sion limits” are the SAME as “channel unavailable”. = In my reading of the FCC rules, that is simply not the case.  There a= re times when FCC rules require me (as a Database) to say “thi= s channel is unavailable” other than “a protected entity= occupies this channel”.  For example:

 

·         = It is a channel categorically excluded from the Whitespace= spectrum (e.g. US Channel 3 or Channel 37).

·         There is an ad-hoc (FCC provided) polygon e= stablishing an ad-hoc exclusion zone.

·         = A device is blacklisted.

 

To say that “Channel 37 is available at -36.8 dBm” is just = not the same as “Channel 37 is unavailable”, IMO.

 

To tell all devices in an ad-hoc exclusion zone that ̶= 0;all channels are available at -36.8 dBm” is just not the same as &#= 8220;all channels are unavailable”.

 

To = tell a blacklisted device that “all channels are available at -36.8 d= Bm” is just not the same as “all channels are unavailable”= ;.

 

In other words: If PAWS does not give m= e a way to say a channel is unequivocally “unavailable”, then, = in my opinion as a Database provider, it is not sufficiently expressive for= me to meet the FCC rules.  

 

If we D= O use PAWS to encode out-of-band emissions limits, I have to say, I think i= t is farfetched that a device implemented today to today’s rules will= be able to – in the future – either “take advantage̶= 1; of a less stringent “out-of-band mask” or comply to a more s= tringent mask.  As marvelous as SDRs are/can be, that degree of flexib= ility is just not common in consumer-grade mass market devices owing to cos= t.  That leads me to the conclusion that expecting to use PAWS that wa= y is just not going to be that useful.

 

Howe= ver, I realize we may differ on this point.  But the notion of “= PAWS available-spectrum replies should encode out-of-band emissions limits&= #8221; is just a separate notion from “PAWS must allow a way to encod= e ‘channel unavailable’”.  It is confounding those t= wo concepts that – IMO – has lead to the current “disagre= ement”.

 <= /o:p>

OK, time for my proposed grand = compromise:

 

·     &nb= sp;   Let’s define a = way to unequivocally encode “channel unavailable” that is NOT s= ynonymous with “out of band emissions limits”.  I need = it as a Database provider.  (Again: I offer to recap several diffe= rent ways to do this later.)

 

·  &nbs= p;      Once= we have a way to unequivocally encode “channel unavailable”, w= e can have a separate discussion as to whether or not it is ever use= d.  Perhaps different Databases will interpret their legal/regulatory = obligations differently.  Or even, a given Database may use “-36= .8 dBm” in some cases and “channel unavailable” in others= .

 =

The purpose of this WG is to produce a prot= ocol that:

 

1.    =    Provides for interoperab= ility (because it is sufficiently clear).

 

2.       = Allows all parties to meet their legal/regulatory obligations as the= y interpret them.

&nb= sp;

I feel the above proposed c= ompromise accomplishes both.

 

 

Dan Harasty

 

=  

 <= /o:p>

From: paws-bounces@ietf.org [ma= ilto:paws-bounces@ietf.org] On Behalf Of Andy Lee
Sent: Fr= iday, September 20, 2013 7:12 PM
To: Peter Stanforth
Cc: paws@ietf.org
Subject: Re: [paws] Spectrum encoding discussion<= o:p>

 

<= p class=3DMsoNormal>I was actually hoping to simplify things for devices.

 

1) Having a fully specified spectrum profile without disco= ntinuities and without "special" values like -inf make it much ea= sier to write the client side code.  This minimizes the number of spec= ial edge cases that need to be handled by the parsing logic and "emiss= ion fitting" code on the client.

 

2) We still s= eem to be thinking in terms of TV channels only.  PAWS is designed for= other frequency bands too, and there won't always be such a distinct conce= pt of on-channel vs. adjacent-channel emissions.

<= p class=3DMsoNormal> 

3)= We don't know what future WSD technologies will be capable of.  Wi-Fi= already supports a long list of modulation types (e.g., BPSK, QPSK, DSSS, = FHSS, OFDM) and channel widths.  Software defined radios and other tec= hnologies can dynamically choose modulation types, channel widths, and powe= r distribution.  These agile radio technologies need the full spectrum= profile to help them choose the right combination of emission parameters. =  WSDs are just a "black box" from the database's point of vi= ew.

 


 

 tvfool@google.com |

Andy Lee |

<= /td>

 Google Inc. |

 408-230-0522

 

<= p class=3DMsoNormal>On Fri, Sep 20, 2013 at 2:35 PM, Peter Stanforth <peter@spectrumb= ridge.com> wrote:

We have, unt= il know, always worked on the assumption that the device would be certified= , or not, to comply with any out of band emissions. The FCC for instance sp= ecifically tests the more stringent rule around channel 37, as well as the = more general case. The Database is not, and cannot be, the enforcement agen= cy. So simply providing a list of channels that it can use is sufficient.

It should be of no consequence= to a device why it cannot use a channel other than to behave with its comp= liant emissions. 

I agre= e with Gabor, why are we overly complicating this?

 

From: "Gabor.Bajko@nokia.com" <Gabor.Bajko@nokia.com>
Date: = Friday, September 20, 2013 4:54 PM
To: "tvfool@google.com" <tvfool@google.com>, = "ben@blindcree= k.com" <ben@blindcreek.com>
Cc: "paws@ietf.org" <paws@ietf.org>


Subject: Re: [paws] Spectrum encoding discus= sion

 

Aren’t= we talking past each other in this thread?

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'>If the rules are supposed to specify what is the max intended power l= evel a device can put into a channel (available or not), then I also think = this is what the DB should communicate to the device.

=

If Ofcom specifies that the max leakage into an unavailable c= hannel is -33dbm, I assume the device will not be certified if it leaks mor= e. If the device supports multiple modulation types and one of them leaks m= ore than what is permitted in that regulatory domain, then the device will = need to know it, and in that regulatory domain avoid using that particular = modulation type. How does the device come to know it? Andy proposes the DB = to indicate that level for the unavailable channels. Others folks seem to s= uggest a device built to operate under a certain ruleset has to implicitly = know it.

Another way of looking at it mi= ght be to say that the max level of permitted unintentional leakage into an= adjacent channel is part of the rulesetInfo, and the spectrum response onl= y lists the available channels. Could this be a way forward?

-&nbs= p;         gabor=

 

From: paws-bounces@ietf.org= [mailto:paw= s-bounces@ietf.org] On Behalf Of ext Andy Lee
Sent: Fr= iday, September 20, 2013 1:00 PM
To: Benjamin A. Rolfe
Cc:<= /b> Protocol to Access White Space database
Subject: Re: [paws] S= pectrum encoding discussion

 

Hi Ben,

 

=

And that means NO intentional radiation in the channel.&nb= sp; 

 

=

If you are reading this as "transmitted emissions in= band should be lower than -33dBm" then, no, this is not the same as &= quot;no emissions" per FCC rules. If one were to intentionally transmi= t at -33dBm where no intentional emissions are allowed, that would not be t= he same as "no" under the rules.

 

There is certainly no intention to encoura= ge any malicious behavior.  In general, we expect devices to be trying= to do the right thing and just need some information to understand where t= he boundaries are.  These boundaries include both intentional and unin= tentional emissions.

 

Va= rious modulation types have known spectral profiles, including both in-band= and out-of-band emissions.  Knowing where the "shelf" is on= the adjacent channel makes it possible to match that with the "skirt&= quot; of the intended modulation pattern.  The "skirt" is no= t part of the intended emission, but is important in trying to avoid causin= g interference on adjacent channels.

 

A crude example of this is shown in the following image:

 

<= span style=3D'font-family:"Arial","sans-serif"'>3D"Inline

 

Best regards,


&= nbsp;

Andy Lee |

<= /td>

 Google Inc. |

 tvfool@google.com&= nbsp;|

 408-230-0522

=

 

On Fri, Sep 20, 2013 at 3:07 AM, Be= njamin A. Rolfe <ben@blindcreek.com> wrote:

 

On 9/19/2013 9:09 AM, Andy Lee wrote:

The math bears that out, but nonetheless OFCOM are still = effectively proposing that *no* in-block transmissions are allowed in that = channel.

 

Same is true for the FCC.  The FCC also assumes th= at "off" channels are not used by WSDs.

And that means NO intentional radiation in the c= hannel. 

 

S= pecifying a low power level like -33 dBm is effectively the same thing as s= pecifying no in-band emissions there.

 

If you are reading this as "= ;transmitted emissions in band should be lower than -33dBm" then, no, = this is not the same as "no emissions" per FCC rules. If one were= to intentionally transmit at -33dBm where no intentional emissions are all= owed, that would not be the same as "no" under the rules.



 

<= /div>

Even if someone did try to put an in-band emission there (= regardless of how impractical that actually is), it would be too low to cau= se interference to anyone and no harm has been done to the "RF environ= ment".

Should be a little caref= ul here for a couple reasons.  I've designed and shipped communication= systems that operate quite well with transmit power levels intentionally b= elow -33dBm and do very useful things. It's pretty easy to design a receive= with sensitivity better than -96dBm, so an intentional radiator at -33dBm = near by will be noticed - at 900 MHz your 10dB above sensitivity at 10m and= at 54MHz you'd be 10 dB above sensitivity at 100m, possibly. And when it c= omes to protecting their spectrum, people always use the best propagation m= odel to calculate interfence impact on them :-).  I've probably misund= erstood something badly, but -33dBm is certainly enough power to be noticed= .

I have tried the "too low to be noticed" argument a few= times in the past  in regulatory discussions, and incumbent and/or pr= otected users usually set the threshold closer to -120dBm and usually argue= that even at really low TX power, the "aggregate impact" of mult= iple devices in the "RF Environment" is an unacceptable impact.&n= bsp;  We had trouble with this argument when the intentional radiator = TX limit was below the maximum unintentional emission limits for most non-t= ransmitting devices (-41.3dBm).

So it would be fairly important to = ensure a device does not interpret -33dBm as it's ok to use that channel so= long as it's TX power is below -33dBm.

I may be off base here becau= se of  how y'all see the DB providing and what I am expecting to suppo= rt future needs. "protected users" includes more than TV stations= in the US. 

Not sure that helps, but hope so. 



 

The advantage of having an "well behaved" spectru= m profile (contiguous and without special values like -inf) is th= at the channel selection algorithm on the WSDs becomes much simpler and log= ical.  There's no need to have lots of special boundary condition chec= ks and code paths that only get triggered under special circumstances. &nbs= p;I'd like to avoid ambiguous interpretations on the device side as much as= possible.

Certainly ambiguous interpretat= ions on the device side are a bad thing.

Some apps are aggregating = multiple TV channels to get a logical channel that that can carry a 'wide'&= nbsp; data pipe. Other uses can fit many useful channels in one TV channel.= In 802.15.4m we divide the TV channel up into multiple physical channels c= arrying low data rate signals.  Right now we assume a peak power level= for the TV channel, and we get that value with the start frequency and wid= th (or end frequency) from the database. However, I've heard it proposed to= the FCC that we may get different power limits different parts of the TV c= hannel, changing over time, as a protection mechanism for deal with narrow = band protected users while allowing effective use of the rest of the TV cha= nnel.  For what we do, this is a good thing - our physical channel may= be less than 200kHz wide. There are a LOT of applications  in IoT tha= t need < 200kHz channels,  and blocking an entire TV channel to pro= tect a wireless microphone using < 200kHz of it means there are 28 other= usable channels  not being used - not efficient use of the spectrum.&= nbsp; 

Hope this helps.  

-Ben

<= /o:p>


 

 408-230-0522<= /span>

Andy Lee |

 Google Inc. |

 tvfool@google.com |

 

On Thu, Sep 19, 2013 at 8:30 AM, Ray Bellis <Ray.Bellis@nominet.org.uk> w= rote:


On 19 Sep 2013, at 16:21, Andy Lee <tvfool@google.com>=

 wrote:

> This actually shows that Ofco= m has picked a power threshold on channel 38 of -33 dBm.  If you look = at the ACLR numbers for class 3, 4, and 5 devices, you'll see they are 10 d= B apart from each other and that they all work out to be -33 dBm on channel= 38.
>
> The reason there are no limits for class 1 and 2 devic= es is because the in-band power on channels 37 and 39 cannot exceed +36 dBm= /8MHz, and therefore the power on channel 38 will naturally be less than -3= 3 dBm.

The math bears that out, but nonetheless OFCOM = are still effectively proposing that *no* in-block transmissions are allowe= d in that channel.

Per OFCOM / ETSI device interface requirements it= would be incorrect for us to actually send that value of -33 dBm to a devi= ce.

Ray

 

 

______=
_________________________________________
paws mailing=
 list
paws@ietf.org
https://www.ietf.org/mailman/listin=
fo/paws

 


__= _____________________________________________
paws mailing list
paws@ietf.org
https://w= ww.ietf.org/mailman/listinfo/paws

 

 

= --_000_EC510C021D06A34C92F5A5A488B5290B0CF2EF13rrcatsexmb2atsa_-- --_004_EC510C021D06A34C92F5A5A488B5290B0CF2EF13rrcatsexmb2atsa_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=5282; creation-date="Sat, 21 Sep 2013 00:15:21 GMT"; modification-date="Sat, 21 Sep 2013 00:15:21 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAZAAAAGQCAYAAACAvzbMAAAAAXNSR0IArs4c6QAAFFxJREFUeNrt 3XuQlXXhx/HPIfzhWikgCaMToIhBRjqZOfaPNTbWFpNNpSNdtGGyZNSAdMyw0ZhRCC21zHI0Z/Cv bOoPxy5qJuBfTTOMIpe4tKAmeCmSaMIFlH1+fzyd3QX2xrrLuezrNbMDu+e6z3nO8z7f79nzPJWi KIoAwBEaZREAICAACAgAAgKAgACAgAAgIEdPpVKxEAD6C0ilUun8mjBhQi6++OI8//zzlhoA/Y9A iqJIURTZtGlTZs6cmcsvv9xSA2DgU1gTJkzIokWL8uyzzyZJ9u3blwULFmTSpEmZNGlSFixYkH37 9mX69OnZvHlzkmTHjh0ZNWpUXn755STJpk2bMn369M7r7OjoyK233ppTTz0148ePz9y5c7Nnz57O 0c9dd92V9773vRk1que72d/l77vvvkydOjUtLS05//zzs379+jz33HOZNm1aun8AvyiKTJs2LWvX ru33ervrbRlUb//222/PxIkTc+KJJ+aaa67J/v37B3TfAZoqIDt37sySJUty9tlnJ0luu+22bNiw IatXr87q1auzdu3aLFmyJK2trVm1alWS5NFHH82YMWPyu9/9LkmycuXKfPrTn+68zrvvvjurVq3K ihUrsnXr1rz55pu5+eabO09/+umn85e//CUdHR093qf+Lv/EE09k1apV2blzZ1pbW3PVVVflrLPO ytixY7NixYrO8z311FMZN25cPvjBDw7oeqt6WwZVTz75ZJ555pmsXbs2mzdvztKlSwd83wHqXtGH JJ1f48ePL2bPnl20tbUVRVEUp512WrFhw4bO865bt66YNm1a8Yc//KGYM2dOURRF0draWtxwww3F 7Nmzi6IoiksvvbR47LHHOi8zY8aMYtOmTZ3fv/rqq8WUKVM6b/uFF17o6+71e/lXXnml87Q9e/YU LS0tRVEUxU9/+tPi0ksv7TztkksuKe69994BX29Vb8uger7up61fv77ztP5uA6ARVPramWKlUklv J7e0tGTXrl059thjkyR79+7NuHHj8vrrr2fWrFlZs2ZNJk+enG3btmXatGl56aWXcuaZZ2bjxo2d lznuuOM6p3WKokhHR0dGjRqVAwcOpFKppKOjo8+/eurv8ofe9+rP/v3vf2fKlCnZunVriqLI6aef nhdffDFjx449ouvtbRm0t7enUqmkvb29x9P6uw2ApprCOtTJJ5+cbdu2dX7f1taWU045JS0tLZk+ fXruvffenHvuuRk7dmzOOeec3HPPPZk5c2bnBjVJJk+enLa2trz11ls5cOBAiqI4aAPa35/M9nf5 3owdOzaf+cxnsnz58ixfvjyzZ8/ujMeRXG9vy6Cq+2nbtm076LTB3neAhg/InDlzMn/+/Gzfvj3b t2/P/PnzM2fOnCRJa2trli5dmosuuihJctFFF2Xp0qVpbW096DrmzZuXK6+8Mhs3bsz+/fuzbt26 XHbZZQO+D2/n8nPnzs0DDzyQX/ziF5k7d+6grrevZZAkCxcuzI4dO7Jjx44sXLgwX/7yl4fsdweo +/dAetPe3l5ce+21xcSJE4uJEycW1157bdHe3l4URVFs2bKlSFI899xzRVEUxZo1a4okxd/+9reD ruPAgQPFT37yk2LGjBnFmDFjilmzZhWPPPJIv7c92Mt3/1lHR0cxderUYurUqUVHR8egrrevZZCk WLZsWXHSSScV48aNK+bNm1fs3bt3QLcB0PDvgTB4fb1/BDCip7AAGNlGWwS83ZEWjc1IGSMQT0oA AQGg/pnCwqhrBDL1iBEIACNsBFKpJAN9tXok56XhLV5sGfTnllssAxphBFKpJA88cPjPH3usPK2+ xuQD+9lw3dbR/D2rXwB1G5Akuf/+5NB9NN1+e2P8ds04cikKIzKgLvQ/hXXBBckvf5l85Svl97// fTJjRvK/Y34kSfbtS77zneThh8vvL7ssWbYsGTMm2b8/WbiwPO2YY5Lrrjv8FfWhG8Tepq22bEkW LUpWrkzeeiu58MIycO95z8Ejg+plu19PX/exUkl+/vPkBz9IXnstOfvscuT1gQ/0Pvqo/vv668kZ ZyQbNyYTJpQ/e/PN5JRTkvXrk5NOKs+7bFnyox+V93vOnOTOO5P/+7/y/B0dyZIlyYMPJrt3J5/7 XHLPPck73zmiV84rrvAErXroIcuARhyBXH11ufGrbogXL07mzz/4PLfdlmzYkKxeXX6tXVtuEJPy 3y1byp+tXl1Ofw3WJZeU92f79uTvfy830t/9btd96+vVeV/3MUmeeKKM4s6dSWtrctVVfY9qqrc1 blwZo/vv7zrPypXJRz5SxqPqySeTZ54pb3fz5qTbwaVy993lba9YkWzdWgbIwaWAOtf3vrCqr+Av vji5/PLyFfPPftb1Hkj1otOmJb/9bfL+95ffr19fvopua0tOPz159NGDT5s1q+dRQk8jkL7eRP/P f5Izz0xeeqn/6+nrPlYqySuvJJMmlae98UY5mnjjjb6XS9W2bcnHP15e1zHHJPPmlSO36t51K5Uy XtXb3rChXKZtbeX3M2cmjzySvO995fevvZacd17ywgvp97Gp9QrU7b2Yofgz3u5vohuB9DwCGYo3 0Yf6cUNAet9I/elPyQ03lN8vWZJ88pMHb8BaWpJdu5LqsT727i1fmbe393xaS8vgArJ6dTkN9eyz 5XUmyTveUU4L9Xc9fd3HI5lG6+20Sy5JPv/5MhozZ5b3saWl6/zt7T3fdpIcd1w51Vcd2XR0JKNG Hf7eU5MH5NC/wBKQ3qew3m5EBISjM4WVJJ/4RLnRa29P/neMj4OcfHL5Kryqra2cXkrKf7uftnXr wZc99tiDX+m/+mrv9+Oyy8qtSltbGY1//atrI9vfXyX1dR+P/Nl3+M+uvz758Y+TP/85Of/8rnh0 H6V0/3/32548uet3OnCgDIODSwFNEZAk+etfy6+eNp5z5pTvi2zfXn7Nn1/+LEm+9KXyTfQdO8qv BQsOvuw55yQ//GGyZ0/y/PPJN7/Z+33Ysyc5/vjyzeUXX0y+8Y2u0yZMKN/I7k1f9/FI9XRb551X Tl8tWpR89auHX6b7Mli4MOl2cKnMm5dceWV5nfv3J+vWdU1/jVBGH5YHzRSQvnzve+W0zYc/XH6d eWZy003laTfdlJx2Wvm+x4c+dPgI5r77yvdUJkwo30f41Kd6v50HH0xuvDF597vL815wQddpN96Y fPSjvY9E+rqPR6q327r++nKE9bGPHX6ZCy8sf/9Zs8r3YxYt6jrt2muTz362nAI7/vgyLr3Frftn QHweBKghB5QaSvfdV46ili07fKPfpIt5uN4D8Yr7cEP5Rrr3QBgKdqY4VHbvTu66q/xTXAABYYAv 58q/mrrnnsG/MQ8gICNQf1MApgiAJmR37gAICAACAoCAQP8cSMryQkAG5Eg+++ZzcgANGBAHJKy/ qD3+ePmh9paWcvdeX/96uUuwZuJDhJYLTTICcUDC+nLnneUeU/75z2TNmmT0aBsWoE4DUj0gYVX1 gITd7dtX7iNx0qTya8GC8mdJuW/Aq69OTjyxPO2OOwY/ctiyJfniF8vrOuGEctdRO3f2vmuo7v/v 6z5WKuVeSKZOLV/Zn39+ebiQvkYf1dvatas8IOLOnV3nefPN8lhS//hH13lvvz2ZOLG879dc07X3 9qTce/uttyannpqMH5/MnVvuN7Inf/xjebyrd72rvI077jj44JAAdRMQByTseVRTLwckXLEiOfdc KzJw9PW5M0UHJOx7uVTV4oCESXnMqi98oXxf5IwzarQCDdFO+exIcWCGaoeKdqbIURmBJOXexm+7 Lfn+9w8/nEeSvPxyucf2qtNPLw97kZT/HnraYK1eXb6BPH58uVE+4YRywz8Qfd3HpCseSXmAwOrB AgfitNPKEcdvflOGZeXKMhCHnqdq2rSDb/vFF8sQjh5dHmBx0qQyin1ZtaoM4MMP1y4ewMg2oH1h VQ9ImPR9QMLqK+yeDkhYPa23AxIed1z5fX8HJLz55uTXvy7jsXt3+Z5C9VV+X/q6j0f+6u3wn11/ fTm1N2VK7wckrN52TwckfPzx8j2YgfjVr5Jvf7sc2Z1zTh2uVYP5kMKqbsd2meKJ2fty6v7N00d+ +aE4oDocyQgkcUDC7mp5QMI77ywPT//UU3UaD0BAjoQDEnaNQob7gITXXVf+AcHMmV1/CVapJP/9 r5UZOLockXAIjcADEvb8Zuwg3hFffPcJXRf5mnWpNw8t7/r/LQt2D/BCh7/z7k106mYEQtcBCb/1 LcviSHWPB5YbjcMBpYbkVbgDEgICwiA4IOHQMX3V//LpPo0FtWQKCwABAUBAABAQAAQEAAQEAAEB QEAAEBDol91xWH4ICAACArVhNyaWEwICgIAAgIAAICAACAgAAgKAgACAgAAgIDQRu+GwHBEQAAQE asPuOSwvBAQAAQEAAQFAQAAQEAAEBAABAQABAUBAaCJ2v2F5IiAACAjUht1yWG4ICAACAgACAoCA ACAgAAgIAAICAAICgIAAICCMdPbbZLkiIAAICNSG/TlZfggIAAICAAICgIAAICAACAgAAgIAAgKA gNBE7G7D8kVAABAQqA274bAcERAABAQABAQAAQFAQAAQEAAEBAAEBAABoYnYzYbljIAAgIBQG3a/ YXkiIAAICAAICAACAoCAACAgAAgIAAgIAAJCE7F7DcsbAQEAAaE27HbDckVAABAQABAQAAQEAAEB QEAAQEAAEBAABAQAAWGks18myx0BAQABoTbsr8nyRUAAEBAAEBAABAQAAQFAQABAQAAQEAAEhCZi dxqWPwICAAJCbdjNhuWMgACAgAAgIAAICAACAoCAAICAACAgAAgITWTxqgssBI8DAgIAAkIN2L2G 5Y2AAICAACAgAAgIAAICgIAAgIAAICAACAhNxO4zPB4ICAAICLVhtxqWOwICAAICgIAAICAACAgA AgIAAgKAgAAgIAAICCOd/S55XBAQABAQasP+mCx/BAQABAQAAQGgRkZXKhVLAUYw2wCMQAAQEADq 3+iiKCwFGGE87zECAaB2IxCLoI4sXtz4v4LdZdT34/PxVbnlY083/i9yyy0eTAGhWcIBNXnOCImA CEdzuuIKD3G9PA4PPSQkCMjICEcjb3l3ndD1/7M91HXh7LOSNd3Xr6mN+7v0VkIhERDh8JIdBvQc ERIBEQ7hACEREIQDhERAEA4QEgREOEBIhERAhAMQEgERDkBIGl6lsFc14RiqxXL3CQcvhq9ZVerF Q8sP/v6WBbtH6ILo5xOVQmIEIhyAEYkRiHA06AjE6KO+RyEjdgRiRGIEIhyAEYmACAcgJAIiHICQ CIhwCAcIiZAIiHAAQiIgwgEIiYAIByAkAiIcgJCMwJA09wcJhePoLWq7Mal7dmcynAt3ZH4gsTlH IMIBGJEYgQhH441AjD4aYxRiBGJEYgQiHIARiYAIByAkAiIcAE0eksYKiHAAQiIgwgEISWOHpL4D IhyAkNRtSOozIMIBCEndh6S+AiIcgJA0TEjqIyDCAdBwIantJ9GFoynYD1bjsD+sRn3g6vOT7bUZ gQgHQMOPSI7uCEQ4mn4EYvTRWKMQIxAjkvofgQgHQNONSIY3IMIB0LQhGZ6ACAdA04dkaAMiHAAj JiRDExDhABhxIXl7AREOgBEbksEFRDgARnxIjiwgwgEgJP8zsA8SCge9rRp2Y9Jw7M6ErpXh7X0g cbRwABiRDGZE0vMIRDgYxAjE6KMxRyFGIAx2RDJaOAAYzIhktHAAMJiQjO4zHsIBICS9hGS0cAAw mJCMOuxM4sEAHfonvHgcGQEh6daI0YIBwGBGJKMsCYZkffqaZeDxYqQREMA0FgKCDQ4gIMAwM42F gGBDBAgIjcH0lccVBAQAAaE2TF95/BAQGBDTHB5fEBAABITaMP3hcURAADqZxkJAsGEBBAQYXqax EBBscAABob6YvvJ4g4AAICDUhukrjysICANiOsPjDgICgIBQG6Y5PL4gIEC/TGMhINiAAAICDC/T WAgINiyAgFAbpq+wHiAgAAgItWH6yuMNAsKAmLbA+oCAACAg1IbpDI87CAgwaKaxEBBsKAABAYaX aSwEBBsQQEAYXqavsH4gIAAICLVh+grrAQLCgJiewHqCgAAgINSGaQusDwgIMORMYyEg2CAAAgIM L9NYCAg2FICAMDRMX2G9QUAAEBBqw/QV1g8EhAExDYH1BwEBQECoDdMTWE8QEOCoMY0lIHjiAwgI MLxMYyEg2CAAAsKRMX2F9QkBAUBAqA3TV1hvEBAGxHQD1isEBAABoTZMQ2D9QUCAmjONJSB4ggMI CDC8TGMJCJ74AAJCz0xfYT1DQAAQEGrD9BXWJwSEATGtgPUNAQFAQKgN0w1YrxAQoG6ZxhIQPJEB BAQYXqaxBARPcAABGelMX2H9Q0AAEBBqw/QV1jMEhAExfYD1EAEBQECoDdMKWN8QEKDhmMYSEDxh AQQEGF6msQQET2QAARkpTF9hvURAABAQasP0FdY/BIQBMU2A9RMBAUBAqA3TB1gPERCgaZjGEhA8 MQEBARheprEEBE9YAAFpNqavsL4iIAAICLVh+grrJQKC6QCstwgIAAJCHTNNgPUTAQGanmksAcET EBAQgOFlGktA8MQEBIRGZfoK6zECAoCAUBumr7C+IiAY9mN9RkAAEBBMB4D1FgEB6o9pLAHBEw0Q EIDhZRpLQPAEBASEemf6Cus3AgKAgFAbpq+wHiMgGN6D9VxAABAQDPvB+oyAAI3DNJaA4AkFCAjA 8DKNJSB4ogECQr0wfYX1HgEBQECoDdNXWL8REAzjwfovIAAICIb3YD1HQIDGZxpLQPDEAQQEYHiZ xhIQPKEAAeFoM30Fng8CAoCAUBumr7DeIyAYroPnhYAAICAYxoP1HwEBmpdpLAHBEwQQEIDhZRpL QPDEAQSE4WL6CjxPBASApvf/5iHIqNxWR4QAAAAASUVORK5CYII= --_004_EC510C021D06A34C92F5A5A488B5290B0CF2EF13rrcatsexmb2atsa_-- From Gabor.Bajko@nokia.com Fri Sep 20 18:32:11 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9584521F9EA8 for ; Fri, 20 Sep 2013 18:32:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.115 X-Spam-Level: X-Spam-Status: No, score=-5.115 tagged_above=-999 required=5 tests=[AWL=0.483, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nbDcmmhhqLVu for ; Fri, 20 Sep 2013 18:32:02 -0700 (PDT) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id 954C121F9E3A for ; Fri, 20 Sep 2013 18:32:01 -0700 (PDT) Received: from smtp.mgd.nokia.com ([65.54.30.56]) by mgw-sa02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r8L1VSFk023469 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Sat, 21 Sep 2013 04:31:29 +0300 Received: from 008-AM1MPN1-006.mgdnok.nokia.com ([169.254.6.131]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi id 14.03.0136.001; Sat, 21 Sep 2013 01:31:28 +0000 From: To: , Thread-Topic: [paws] Spectrum encoding discussion Thread-Index: AQHOtLJJlV0A7sF1Y0u4PChODFE3GpnM2N2AgABHaoCAAAbdgIAAB0+AgAACXwCAAAsCAIABLRqAgAClvgCAAAR7EIAAFgcAgAAa+ACAABHGgIAADQKA Date: Sat, 21 Sep 2013 01:31:27 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E47605342356@008-AM1MPN1-006.mgdnok.nokia.com> References: <1ECAFF543A2FED4EA2BEB6CACE08E476053422B0@008-AM1MPN1-006.mgdnok.nokia.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [69.181.65.212] Content-Type: multipart/related; boundary="_004_1ECAFF543A2FED4EA2BEB6CACE08E47605342356008AM1MPN1006mg_"; type="multipart/alternative" MIME-Version: 1.0 X-Nokia-AV: Clean Subject: Re: [paws] Spectrum encoding discussion X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Sep 2013 01:32:11 -0000 --_004_1ECAFF543A2FED4EA2BEB6CACE08E47605342356008AM1MPN1006mg_ Content-Type: multipart/alternative; boundary="_000_1ECAFF543A2FED4EA2BEB6CACE08E47605342356008AM1MPN1006mg_" --_000_1ECAFF543A2FED4EA2BEB6CACE08E47605342356008AM1MPN1006mg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Few things to consider: 1. I think we first have to agree whether we need at all to encode an= 'unavailable channel'. Current draft section 4.4.2 says: "The response mes= sage for the Available Spectrum Query contains a schedule of available spectrum for the Device." To me this means that ch= annels which are not listed are implicitly unavailable and leakage into una= vailable spectrum has to conform to the rules. 2. If one wants to be explicit on what the rules say for the leakage = limits, then we can encode those into the rulesetInfo. 3. If we take on Andy's argument that PAWS could be used outside TVWS= , *and* leakage limits may potentially be different for different bands wit= hin the same regulatory domain, then encoding all those bands and leakage l= imits into rulesetInfo might just complement what is missing from the avail= able spectrum response and we may be better off just encoding everything in= to available spectrum response. 1 and 2 doesn't require an encoding for unavailable channel. Simply not lis= ting it as available does the job. 3 would require us to agree how to encode unavailable channel, but the WSD = would still need to know what the emission limits are in that regulatory do= main for the unavailable channels. - gabor From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext= Harasty, Daniel J Sent: Friday, September 20, 2013 5:15 PM To: paws@ietf.org Subject: Re: [paws] Spectrum encoding discussion All: I know this is a long winded reply to an already laborious conversation. B= ut I think I can put a finger on the essential "disagreement", and even off= er a compromise that will allow us to move forward. Hint: the whole "option 1"/"option 2" debate is a bit of a misdirection, as= those two options did NOT capture the two sides of the essential disagreem= ent; the issue at hand is really about "is an out-of-band emission limit a = good way to express that a channel is unavailable?" There seems to be the camp that "out of band emission limits" are the SAME = as "channel unavailable". In my reading of the FCC rules, that is simply n= ot the case. There are times when FCC rules require me (as a Database) to = say "this channel is unavailable" other than "a protected entity occupies t= his channel". For example: * It is a channel categorically excluded from the Whitespace spectr= um (e.g. US Channel 3 or Channel 37). * There is an ad-hoc (FCC provided) polygon establishing an ad-hoc = exclusion zone. * A device is blacklisted. To say that "Channel 37 is available at -36.8 dBm" is just not the same as = "Channel 37 is unavailable", IMO. To tell all devices in an ad-hoc exclusion zone that "all channels are avai= lable at -36.8 dBm" is just not the same as "all channels are unavailable". To tell a blacklisted device that "all channels are available at -36.8 dBm"= is just not the same as "all channels are unavailable". In other words: If PAWS does not give me a way to say a channel is unequivo= cally "unavailable", then, in my opinion as a Database provider, it is not = sufficiently expressive for me to meet the FCC rules. If we DO use PAWS to encode out-of-band emissions limits, I have to say, I = think it is farfetched that a device implemented today to today's rules wil= l be able to - in the future - either "take advantage" of a less stringent = "out-of-band mask" or comply to a more stringent mask. As marvelous as SDR= s are/can be, that degree of flexibility is just not common in consumer-gra= de mass market devices owing to cost. That leads me to the conclusion that= expecting to use PAWS that way is just not going to be that useful. However, I realize we may differ on this point. But the notion of "PAWS av= ailable-spectrum replies should encode out-of-band emissions limits" is jus= t a separate notion from "PAWS must allow a way to encode 'channel unavaila= ble'". It is confounding those two concepts that - IMO - has lead to the c= urrent "disagreement". OK, time for my proposed grand compromise: * Let's define a way to unequivocally encode "channel unavailable" = that is NOT synonymous with "out of band emissions limits". I need it as a= Database provider. (Again: I offer to recap several different ways to do = this later.) * Once we have a way to unequivocally encode "channel unavailable",= we can have a separate discussion as to whether or not it is ever used. P= erhaps different Databases will interpret their legal/regulatory obligation= s differently. Or even, a given Database may use "-36.8 dBm" in some cases= and "channel unavailable" in others. The purpose of this WG is to produce a protocol that: 1. Provides for interoperability (because it is sufficiently clear). 2. Allows all parties to meet their legal/regulatory obligations as t= hey interpret them. I feel the above proposed compromise accomplishes both. Dan Harasty From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of Andy Lee Sent: Friday, September 20, 2013 7:12 PM To: Peter Stanforth Cc: paws@ietf.org Subject: Re: [paws] Spectrum encoding discussion I was actually hoping to simplify things for devices. 1) Having a fully specified spectrum profile without discontinuities and wi= thout "special" values like -inf make it much easier to write the client si= de code. This minimizes the number of special edge cases that need to be h= andled by the parsing logic and "emission fitting" code on the client. 2) We still seem to be thinking in terms of TV channels only. PAWS is desi= gned for other frequency bands too, and there won't always be such a distin= ct concept of on-channel vs. adjacent-channel emissions. 3) We don't know what future WSD technologies will be capable of. Wi-Fi al= ready supports a long list of modulation types (e.g., BPSK, QPSK, DSSS, FHS= S, OFDM) and channel widths. Software defined radios and other technologie= s can dynamically choose modulation types, channel widths, and power distri= bution. These agile radio technologies need the full spectrum profile to h= elp them choose the right combination of emission parameters. WSDs are jus= t a "black box" from the database's point of view. Andy Lee | Google Inc. | tvfool@google.com | 408-230-0522 On Fri, Sep 20, 2013 at 2:35 PM, Peter Stanforth > wrote: We have, until know, always worked on the assumption that the device would = be certified, or not, to comply with any out of band emissions. The FCC for= instance specifically tests the more stringent rule around channel 37, as = well as the more general case. The Database is not, and cannot be, the enfo= rcement agency. So simply providing a list of channels that it can use is s= ufficient. It should be of no consequence to a device why it cannot use a channel othe= r than to behave with its compliant emissions. I agree with Gabor, why are we overly complicating this? From: "Gabor.Bajko@nokia.com" > Date: Friday, September 20, 2013 4:54 PM To: "tvfool@google.com" >, "ben@blindcreek.com" > Cc: "paws@ietf.org" > Subject: Re: [paws] Spectrum encoding discussion Aren't we talking past each other in this thread? If the rules are supposed to specify what is the max intended power level a= device can put into a channel (available or not), then I also think this i= s what the DB should communicate to the device. If Ofcom specifies that the max leakage into an unavailable channel is -33d= bm, I assume the device will not be certified if it leaks more. If the devi= ce supports multiple modulation types and one of them leaks more than what = is permitted in that regulatory domain, then the device will need to know i= t, and in that regulatory domain avoid using that particular modulation typ= e. How does the device come to know it? Andy proposes the DB to indicate th= at level for the unavailable channels. Others folks seem to suggest a devic= e built to operate under a certain ruleset has to implicitly know it. Another way of looking at it might be to say that the max level of permitte= d unintentional leakage into an adjacent channel is part of the rulesetInfo= , and the spectrum response only lists the available channels. Could this b= e a way forward? - gabor From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of ext Andy Lee Sent: Friday, September 20, 2013 1:00 PM To: Benjamin A. Rolfe Cc: Protocol to Access White Space database Subject: Re: [paws] Spectrum encoding discussion Hi Ben, And that means NO intentional radiation in the channel. If you are reading this as "transmitted emissions in band should be lower t= han -33dBm" then, no, this is not the same as "no emissions" per FCC rules.= If one were to intentionally transmit at -33dBm where no intentional emiss= ions are allowed, that would not be the same as "no" under the rules. There is certainly no intention to encourage any malicious behavior. In ge= neral, we expect devices to be trying to do the right thing and just need s= ome information to understand where the boundaries are. These boundaries i= nclude both intentional and unintentional emissions. Various modulation types have known spectral profiles, including both in-ba= nd and out-of-band emissions. Knowing where the "shelf" is on the adjacent= channel makes it possible to match that with the "skirt" of the intended m= odulation pattern. The "skirt" is not part of the intended emission, but i= s important in trying to avoid causing interference on adjacent channels. A crude example of this is shown in the following image: [Inline image 1] Best regards, Andy Lee | Google Inc. | tvfool@google.com | 408-230-0522 On Fri, Sep 20, 2013 at 3:07 AM, Benjamin A. Rolfe > wrote: On 9/19/2013 9:09 AM, Andy Lee wrote: The math bears that out, but nonetheless OFCOM are still effectively propos= ing that *no* in-block transmissions are allowed in that channel. Same is true for the FCC. The FCC also assumes that "off" channels are not= used by WSDs. And that means NO intentional radiation in the channel. Specifying a low power level like -33 dBm is effectively the same thing as = specifying no in-band emissions there. If you are reading this as "transmitted emissions in band should be lower t= han -33dBm" then, no, this is not the same as "no emissions" per FCC rules.= If one were to intentionally transmit at -33dBm where no intentional emiss= ions are allowed, that would not be the same as "no" under the rules. Even if someone did try to put an in-band emission there (regardless of how= impractical that actually is), it would be too low to cause interference t= o anyone and no harm has been done to the "RF environment". Should be a little careful here for a couple reasons. I've designed and sh= ipped communication systems that operate quite well with transmit power lev= els intentionally below -33dBm and do very useful things. It's pretty easy = to design a receive with sensitivity better than -96dBm, so an intentional = radiator at -33dBm near by will be noticed - at 900 MHz your 10dB above sen= sitivity at 10m and at 54MHz you'd be 10 dB above sensitivity at 100m, poss= ibly. And when it comes to protecting their spectrum, people always use the= best propagation model to calculate interfence impact on them :-). I've p= robably misunderstood something badly, but -33dBm is certainly enough power= to be noticed. I have tried the "too low to be noticed" argument a few times in the past = in regulatory discussions, and incumbent and/or protected users usually set= the threshold closer to -120dBm and usually argue that even at really low = TX power, the "aggregate impact" of multiple devices in the "RF Environment= " is an unacceptable impact. We had trouble with this argument when the i= ntentional radiator TX limit was below the maximum unintentional emission l= imits for most non-transmitting devices (-41.3dBm). So it would be fairly important to ensure a device does not interpret -33dB= m as it's ok to use that channel so long as it's TX power is below -33dBm. I may be off base here because of how y'all see the DB providing and what = I am expecting to support future needs. "protected users" includes more tha= n TV stations in the US. Not sure that helps, but hope so. The advantage of having an "well behaved" spectrum profile (contiguous and = without special values like -inf) is that the channel selection algorithm o= n the WSDs becomes much simpler and logical. There's no need to have lots = of special boundary condition checks and code paths that only get triggered= under special circumstances. I'd like to avoid ambiguous interpretations = on the device side as much as possible. Certainly ambiguous interpretations on the device side are a bad thing. Some apps are aggregating multiple TV channels to get a logical channel tha= t that can carry a 'wide' data pipe. Other uses can fit many useful channe= ls in one TV channel. In 802.15.4m we divide the TV channel up into multipl= e physical channels carrying low data rate signals. Right now we assume a = peak power level for the TV channel, and we get that value with the start f= requency and width (or end frequency) from the database. However, I've hear= d it proposed to the FCC that we may get different power limits different p= arts of the TV channel, changing over time, as a protection mechanism for d= eal with narrow band protected users while allowing effective use of the re= st of the TV channel. For what we do, this is a good thing - our physical = channel may be less than 200kHz wide. There are a LOT of applications in I= oT that need < 200kHz channels, and blocking an entire TV channel to prote= ct a wireless microphone using < 200kHz of it means there are 28 other usab= le channels not being used - not efficient use of the spectrum. Hope this helps. -Ben Andy Lee | Google Inc. | tvfool@google.com | 408-230-0522 On Thu, Sep 19, 2013 at 8:30 AM, Ray Bellis > wrote: On 19 Sep 2013, at 16:21, Andy Lee > wrote: > This actually shows that Ofcom has picked a power threshold on channel 38= of -33 dBm. If you look at the ACLR numbers for class 3, 4, and 5 devices= , you'll see they are 10 dB apart from each other and that they all work ou= t to be -33 dBm on channel 38. > > The reason there are no limits for class 1 and 2 devices is because the i= n-band power on channels 37 and 39 cannot exceed +36 dBm/8MHz, and therefor= e the power on channel 38 will naturally be less than -33 dBm. The math bears that out, but nonetheless OFCOM are still effectively propos= ing that *no* in-block transmissions are allowed in that channel. Per OFCOM / ETSI device interface requirements it would be incorrect for us= to actually send that value of -33 dBm to a device. Ray _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws --_000_1ECAFF543A2FED4EA2BEB6CACE08E47605342356008AM1MPN1006mg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
Few things to consider:

 


=
1.  &=
nbsp;    I think we first have to agree whether we need at all to encode an &=
#8216;unavailable channel’. Current draft section 4.4.2 says: “=
The response message for the Available Spectrum Query contains a


   schedule of available spectrum for the Device=
.” To me this means that channels w=
hich are
 not listed are implicitly unavailable and leakage into unavailable spectru=
m has to conform to the rules.


 <=
/p>

2. =
;     
If one wants to b=
e explicit on what the rules say for the leakage limits, then we can encode=
 those into the rulesetInfo.


 <=
/p>

3. =
;     
If we take on And=
y’s argument that PAWS could be used outside TVWS, *and* leaka=
ge limits may potentially be different for different bands within
 the same regulatory domain, then encoding all those bands and leakage limi=
ts into rulesetInfo might just complement what is missing from the availabl=
e spectrum response and we may be better off just encoding everything into =
available spectrum response.


 <=
/p>

1 and 2 doesn’t req=
uire an encoding for unavailable channel. Simply not listing it as availabl=
e does the job.


3 would require us to agr=
ee how to encode unavailable channel, but the WSD would still need to know =
what the emission limits are in that regulatory domain for
 the unavailable channels.


 <=
/p>

- =
        
gabor<=
/span>




 <=
/p>





From: paws-bou=
nces@ietf.org [mailto:paws-bounces@ietf.org]
On Behalf Of ext Harasty, Daniel J

Sent: Friday, September 20, 2013 5:15 PM

To: paws@ietf.org

Subject: Re: [paws] Spectrum encoding discussion





 


All:

 <=
/p>

I know this is a long win=
ded reply to an already laborious conversation.  But I think I can put=
 a finger on the essential “disagreement”, and even offer a com=
promise
 that will allow us to move forward.


 <=
/p>

Hint: the whole “op=
tion 1”/”option 2” debate is a bit of a misdirection, as =
those two options did NOT capture the two sides of the essential disagreeme=
nt; the
 issue at hand is really about “is an out-of-band emission limit a go=
od way to express that a channel is unavailable?”

 <=
/p>

There seems to be the cam=
p that “out of band emission limits” are the SAME as “cha=
nnel unavailable”.  In my reading of the FCC rules, that is simp=
ly not the
 case.  There are times when FCC rules require me (as a Databas=
e) to say “this channel is unavailable”
other than “a protected entity occupies this channel”.&n=
bsp; For example:


 <=
/p>

·      =
;  
It is a channel c=
ategorically excluded from the Whitespace spectrum (e.g. US Channel 3 or Ch=
annel 37).


·      =
;  
There is an ad-ho=
c (FCC provided) polygon establishing an ad-hoc exclusion zone.<=
/span>


·      =
;  
A device is black=
listed.


 <=
/p>

To say that “Channe=
l 37 is available at -36.8 dBm” is just not the same as “Channe=
l 37 is unavailable”, IMO.


 <=
/p>

To tell all devices in an=
 ad-hoc exclusion zone that “all channels are available at -36.8 dBm&=
#8221; is just not the same as “all channels are unavailable”.<=
o:p>


 <=
/p>

To tell a blacklisted dev=
ice that “all channels are available at -36.8 dBm” is just not =
the same as “all channels are unavailable”.

 <=
/p>

In other words: If PAW=
S does not give me a way to say a channel is unequivocally “unavailab=
le”, then, in my opinion as a Database provider, it is not sufficient=
ly
 expressive for me to meet the FCC rules.  


 <=
/p>

If we DO use PAWS to enco=
de out-of-band emissions limits, I have to say, I think it is farfetched th=
at a device implemented today to today’s rules will be able
 to – in the future – either “take advantage” of a =
less stringent “out-of-band mask” or comply to a more stringent=
 mask.  As marvelous as SDRs are/can be, that degree of flexibility is=
 just not common in consumer-grade mass market devices owing to cost. =
 That
 leads me to the conclusion that expecting to use PAWS that way is just not=
 going to be that useful.


 <=
/p>

However, I realize we may=
 differ on this point.  But the notion of “PAWS available-spectr=
um replies should encode out-of-band emissions limits” is just a sepa=
rate
 notion from “PAWS must allow a way to encode ‘channel unavaila=
ble’”.  It is confounding those two concepts that – =
IMO – has lead to the current “disagreement”.<=
/span>


 <=
/p>

OK, time for my proposed =
grand compromise:


 <=
/p>

·      =
;  
Let’s defin=
e a way to unequivocally encode “channel unavailable” that is N=
OT synonymous with “out of band emissions limits”.
 I need it as a Database provider.  (Again: I offer to rec=
ap several different ways to do this later.)


 <=
/p>

·      =
;  
Once we have a wa=
y to unequivocally encode “channel unavailable”, we can have a
separate discussion as to whether or not it is ever used.  Perh=
aps different Databases will interpret their legal/regulatory obligations d=
ifferently.  Or even, a given Database may use “-36.8 dBm”=
 in some cases and “channel unavailable” in others.<=
/span>


 <=
/p>

The purpose of this WG is=
 to produce a protocol that:


 <=
/p>

1. =
;     
Provides for inte=
roperability (because it is sufficiently clear).


 <=
/p>

2. =
;     
Allows all partie=
s to meet their legal/regulatory obligations as they interpret them.


 <=
/p>

I feel the above proposed=
 compromise accomplishes both.


 <=
/p>

 <=
/p>

Dan Harasty


 <=
/p>

 <=
/p>

 <=
/p>



From:
paws-bounces@ietf.org [mailto:paws-bounces@ietf.org]
On Behalf Of Andy Lee

Sent: Friday, September 20, 2013 7:12 PM

To: Peter Stanforth

Cc: paws@ietf.org

Subject: Re: [paws] Spectrum encoding discussion



 




I was actually hoping to simplify things for devices=
.




 






1) Having a fully specified spectrum profile without=
 discontinuities and without "special" values like -inf make it m=
uch easier to write the client side code.  This minimizes the number o=
f special edge cases that need to be handled by the
 parsing logic and "emission fitting" code on the client.






 






2) We still seem to be thinking in terms of TV chann=
els only.  PAWS is designed for other frequency bands too, and there w=
on't always be such a distinct concept of on-channel vs. adjacent-channel e=
missions.






 






3) We don't know what future WSD technologies will b=
e capable of.  Wi-Fi already supports a long list of modulation types =
(e.g., BPSK, QPSK, DSSS, FHSS, OFDM) and channel widths.  Software def=
ined radios and other technologies can dynamically
 choose modulation types, channel widths, and power distribution.  The=
se agile radio technologies need the full spectrum profile to help them cho=
ose the right combination of emission parameters.  WSDs are just a &qu=
ot;black box" from the database's point of view.






 















 








Andy Lee |




 Google Inc. |




 tvfool@google.com |




 408-230-0522










 




On Fri, Sep 20, 2013 at 2:35 PM, Peter Stanforth <=
;peter@spectr=
umbridge.com> wrote:






We have, until know, always worked on t=
he assumption that the device would be certified, or not, to comply with an=
y out of band emissions. The FCC for instance specifically
 tests the more stringent rule around channel 37, as well as the more gener=
al case. The Database is not, and cannot be, the enforcement agency. So sim=
ply providing a list of channels that it can use is sufficient.<=
/span>






It should be of no consequence to a dev=
ice why it cannot use a channel other than to behave with its compliant emi=
ssions. 






I agree with Gabor, why are we overly c=
omplicating this?






 






From:
"Gabor.Bajko@nokia.com" <Gabor.Bajko@nokia.com>

Date: Friday, September 20, 2013 4:54 PM

To: "tvf=
ool@google.com" <tvfool@google.com>, "ben@blindcreek.com" <ben@blindcreek.com>

Cc: "paws@ie=
tf.org" <paw=
s@ietf.org>








Subject: Re: [paws] Spectrum encoding discussion













 










Aren’t we talking past each other=
 in this thread?


If the rules are supposed to specify wh=
at is the max intended power level a device can put into a
 channel (available or not), then I also think this is what the DB should c=
ommunicate to the device.


If Ofcom specifies that the max leakage=
 into an unavailable channel is -33dbm, I assume the device
 will not be certified if it leaks more. If the device supports multiple mo=
dulation types and one of them leaks more than what is permitted in that re=
gulatory domain, then the device will need to know it, and in that regulato=
ry domain avoid using that particular
 modulation type. How does the device come to know it? Andy proposes the DB=
 to indicate that level for the unavailable channels. Others folks seem to =
suggest a device built to operate under a certain ruleset has to implicitly=
 know it.


Another way of looking at it might be t=
o say that the max level of permitted unintentional leakage
 into an adjacent channel is part of the rulesetInfo, and the spectrum resp=
onse only lists the available channels. Could this be a way forward?=



-         
gabor


 


From:
paws-bounces@iet=
f.org [mailt=
o:paws-bounces@ietf.org]
On Behalf Of ext Andy Lee

Sent: Friday, September 20, 2013 1:00 PM

To: Benjamin A. Rolfe

Cc: Protocol to Access White Space database

Subject: Re: [paws] Spectrum encoding discussion

 




Hi Ben,




 








And that means NO intentional radiation in the channel.=
  






 






If you are reading this as "transmitted emissions =
in band should be lower than -33dBm" then, no, this is not the
 same as "no emissions" per FCC rules. If one were to intentional=
ly transmit at -33dBm where no intentional emissions are allowed, that woul=
d not be the same as "no" under the rules.








 






There is certainly no intention to encourage any malicious behavior. &nb=
sp;In general, we expect devices to be trying to do the right thing
 and just need some information to understand where the boundaries are. &nb=
sp;These boundaries include both intentional and unintentional emissions.






 






Various modulation types have known spectral profiles, including both in=
-band and out-of-band emissions.  Knowing where the "shelf"
 is on the adjacent channel makes it possible to match that with the "=
skirt" of the intended modulation pattern.  The "skirt"=
 is not part of the intended emission, but is important in trying to avoid =
causing interference on adjacent channels.






 






A crude example of this is shown in the following image:






 






3D"Inline=







 






Best regards,















&n=
bsp;








Andy Lee |




 Google Inc. |




 tvfool@google.com |




 408-2=
30-0522










 




On Fri, Sep 20, 2013 at 3:07 AM, Benjamin A. Rolfe <ben@blindcreek.com> wro=
te:






 




On 9/19/2013 9:09 AM, Andy Lee wrote:










The math bears that out, but nonetheless OFCOM&nbs=
p;are still effectively proposing that *no* in-block transmissions are
 allowed in that channel.






 






Same is true for the FCC.  The FCC also assumes that "of=
f" channels are not used by WSDs.










And that means NO intentional radiation in the channel. 











 






Specifying a low power level like -33 dBm is effectively the same =
thing as specifying no in-band emissions there.








 




If you are reading this as "transmitted emissions in band sho=
uld be lower than -33dBm" then, no, this is not the same as "no e=
missions" per FCC rules. If one were to intentionally
 transmit at -33dBm where no intentional emissions are allowed, that would =
not be the same as "no" under the rules.




 






 






Even if someone did try to put an in-band emission there (regardle=
ss of how impractical that actually is), it would be too low to cause inter=
ference to anyone and no harm has been
 done to the "RF environment".








Should be a little careful here for a couple reasons.  I've d=
esigned and shipped communication systems that operate quite well with tran=
smit power levels intentionally below -33dBm
 and do very useful things. It's pretty easy to design a receive with sensi=
tivity better than -96dBm, so an intentional radiator at -33dBm near by wil=
l be noticed - at 900 MHz your 10dB above sensitivity at 10m and at 54MHz y=
ou'd be 10 dB above sensitivity
 at 100m, possibly. And when it comes to protecting their spectrum, people =
always use the best propagation model to calculate interfence impact on the=
m :-).  I've probably misunderstood something badly, but -33dBm is cer=
tainly enough power to be noticed.




I have tried the "too low to be noticed" argument a few times in =
the past  in regulatory discussions, and incumbent and/or protected us=
ers usually set the threshold closer to -120dBm and usually argue that even=
 at really low TX power, the "aggregate impact"
 of multiple devices in the "RF Environment" is an unacceptable i=
mpact.   We had trouble with this argument when the intentional r=
adiator TX limit was below the maximum unintentional emission limits for mo=
st non-transmitting devices (-41.3dBm).




So it would be fairly important to ensure a device does not interpret -33dB=
m as it's ok to use that channel so long as it's TX power is below -33dBm.<=
br>


I may be off base here because of  how y'all see the DB providing and =
what I am expecting to support future needs. "protected users" in=
cludes more than TV stations in the US. 




Not sure that helps, but hope so.  




 






 






The advantage of having an "well behaved" spectrum profi=
le (contiguous and without special values like -inf) is that the =
channel selection algorithm on the WSDs becomes much simpler
 and logical.  There's no need to have lots of special boundary condit=
ion checks and code paths that only get triggered under special circumstanc=
es.  I'd like to avoid ambiguous interpretations on the device side as=
 much as possible.








Certainly ambiguous interpretations on the device side are a bad thing.




Some apps are aggregating multiple TV channels to get a logical channel tha=
t that can carry a 'wide'  data pipe. Other uses can fit many useful c=
hannels in one TV channel. In 802.15.4m we divide the TV channel up into mu=
ltiple physical channels carrying low
 data rate signals.  Right now we assume a peak power level for the TV=
 channel, and we get that value with the start frequency and width (or end =
frequency) from the database. However, I've heard it proposed to the FCC th=
at we may get different power limits
 different parts of the TV channel, changing over time, as a protection mec=
hanism for deal with narrow band protected users while allowing effective u=
se of the rest of the TV channel.  For what we do, this is a good thin=
g - our physical channel may be less
 than 200kHz wide. There are a LOT of applications  in IoT that need &=
lt; 200kHz channels,  and blocking an entire TV channel to protect a w=
ireless microphone using < 200kHz of it means there are 28 other usable =
channels  not being used - not efficient use of
 the spectrum.   



Hope this helps.   



-Ben













&n=
bsp;








Andy Lee |




 Google Inc. |




 tvfool@google.com |




 408-2=
30-0522










 




On Thu, Sep 19, 2013 at 8:30 AM, Ray Bellis <Ray.Bellis@nominet.org.uk&=
gt; wrote:




On 19 Sep 2013, at 16:21, Andy Lee <tvfool@google.com>




 wrote:



> This actually shows that Ofcom has picked a power threshold on channel=
 38 of -33 dBm.  If you look at the ACLR numbers for class 3, 4, and 5=
 devices, you'll see they are 10 dB apart from each other and that they all=
 work out to be -33 dBm on channel 38.

>

> The reason there are no limits for class 1 and 2 devices is because th=
e in-band power on channels 37 and 39 cannot exceed +36 dBm/8MHz, and t=
herefore the power on channel 38 will naturally be less than -33 dBm.<=
/o:p>




The math bears that out, but nonetheless OFCOM are still effectively pro=
posing that *no* in-block transmissions are allowed in that channel.



Per OFCOM / ETSI device interface requirements it would be incorrect for us=
 to actually send that value of -33 dBm to a device.



Ray




 




 






_______________________________________________


paws mailing list


paws@ietf.org


https://www.ietf.org/mailman/listinfo/paws




 






_______________________________________________

paws mailing list

paws@ietf.org

ht=
tps://www.ietf.org/mailman/listinfo/paws




 


















 
--_000_1ECAFF543A2FED4EA2BEB6CACE08E47605342356008AM1MPN1006mg_-- --_004_1ECAFF543A2FED4EA2BEB6CACE08E47605342356008AM1MPN1006mg_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=5282; creation-date="Sat, 21 Sep 2013 01:31:27 GMT"; modification-date="Sat, 21 Sep 2013 01:31:27 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAZAAAAGQCAYAAACAvzbMAAAAAXNSR0IArs4c6QAAFFxJREFUeNrt 3XuQlXXhx/HPIfzhWikgCaMToIhBRjqZOfaPNTbWFpNNpSNdtGGyZNSAdMyw0ZhRCC21zHI0Z/Cv bOoPxy5qJuBfTTOMIpe4tKAmeCmSaMIFlH1+fzyd3QX2xrrLuezrNbMDu+e6z3nO8z7f79nzPJWi KIoAwBEaZREAICAACAgAAgKAgACAgAAgIEdPpVKxEAD6C0ilUun8mjBhQi6++OI8//zzlhoA/Y9A iqJIURTZtGlTZs6cmcsvv9xSA2DgU1gTJkzIokWL8uyzzyZJ9u3blwULFmTSpEmZNGlSFixYkH37 9mX69OnZvHlzkmTHjh0ZNWpUXn755STJpk2bMn369M7r7OjoyK233ppTTz0148ePz9y5c7Nnz57O 0c9dd92V9773vRk1que72d/l77vvvkydOjUtLS05//zzs379+jz33HOZNm1aun8AvyiKTJs2LWvX ru33ervrbRlUb//222/PxIkTc+KJJ+aaa67J/v37B3TfAZoqIDt37sySJUty9tlnJ0luu+22bNiw IatXr87q1auzdu3aLFmyJK2trVm1alWS5NFHH82YMWPyu9/9LkmycuXKfPrTn+68zrvvvjurVq3K ihUrsnXr1rz55pu5+eabO09/+umn85e//CUdHR093qf+Lv/EE09k1apV2blzZ1pbW3PVVVflrLPO ytixY7NixYrO8z311FMZN25cPvjBDw7oeqt6WwZVTz75ZJ555pmsXbs2mzdvztKlSwd83wHqXtGH JJ1f48ePL2bPnl20tbUVRVEUp512WrFhw4bO865bt66YNm1a8Yc//KGYM2dOURRF0draWtxwww3F 7Nmzi6IoiksvvbR47LHHOi8zY8aMYtOmTZ3fv/rqq8WUKVM6b/uFF17o6+71e/lXXnml87Q9e/YU LS0tRVEUxU9/+tPi0ksv7TztkksuKe69994BX29Vb8uger7up61fv77ztP5uA6ARVPramWKlUklv J7e0tGTXrl059thjkyR79+7NuHHj8vrrr2fWrFlZs2ZNJk+enG3btmXatGl56aWXcuaZZ2bjxo2d lznuuOM6p3WKokhHR0dGjRqVAwcOpFKppKOjo8+/eurv8ofe9+rP/v3vf2fKlCnZunVriqLI6aef nhdffDFjx449ouvtbRm0t7enUqmkvb29x9P6uw2ApprCOtTJJ5+cbdu2dX7f1taWU045JS0tLZk+ fXruvffenHvuuRk7dmzOOeec3HPPPZk5c2bnBjVJJk+enLa2trz11ls5cOBAiqI4aAPa35/M9nf5 3owdOzaf+cxnsnz58ixfvjyzZ8/ujMeRXG9vy6Cq+2nbtm076LTB3neAhg/InDlzMn/+/Gzfvj3b t2/P/PnzM2fOnCRJa2trli5dmosuuihJctFFF2Xp0qVpbW096DrmzZuXK6+8Mhs3bsz+/fuzbt26 XHbZZQO+D2/n8nPnzs0DDzyQX/ziF5k7d+6grrevZZAkCxcuzI4dO7Jjx44sXLgwX/7yl4fsdweo +/dAetPe3l5ce+21xcSJE4uJEycW1157bdHe3l4URVFs2bKlSFI899xzRVEUxZo1a4okxd/+9reD ruPAgQPFT37yk2LGjBnFmDFjilmzZhWPPPJIv7c92Mt3/1lHR0cxderUYurUqUVHR8egrrevZZCk WLZsWXHSSScV48aNK+bNm1fs3bt3QLcB0PDvgTB4fb1/BDCip7AAGNlGWwS83ZEWjc1IGSMQT0oA AQGg/pnCwqhrBDL1iBEIACNsBFKpJAN9tXok56XhLV5sGfTnllssAxphBFKpJA88cPjPH3usPK2+ xuQD+9lw3dbR/D2rXwB1G5Akuf/+5NB9NN1+e2P8ds04cikKIzKgLvQ/hXXBBckvf5l85Svl97// fTJjRvK/Y34kSfbtS77zneThh8vvL7ssWbYsGTMm2b8/WbiwPO2YY5Lrrjv8FfWhG8Tepq22bEkW LUpWrkzeeiu58MIycO95z8Ejg+plu19PX/exUkl+/vPkBz9IXnstOfvscuT1gQ/0Pvqo/vv668kZ ZyQbNyYTJpQ/e/PN5JRTkvXrk5NOKs+7bFnyox+V93vOnOTOO5P/+7/y/B0dyZIlyYMPJrt3J5/7 XHLPPck73zmiV84rrvAErXroIcuARhyBXH11ufGrbogXL07mzz/4PLfdlmzYkKxeXX6tXVtuEJPy 3y1byp+tXl1Ofw3WJZeU92f79uTvfy830t/9btd96+vVeV/3MUmeeKKM4s6dSWtrctVVfY9qqrc1 blwZo/vv7zrPypXJRz5SxqPqySeTZ54pb3fz5qTbwaVy993lba9YkWzdWgbIwaWAOtf3vrCqr+Av vji5/PLyFfPPftb1Hkj1otOmJb/9bfL+95ffr19fvopua0tOPz159NGDT5s1q+dRQk8jkL7eRP/P f5Izz0xeeqn/6+nrPlYqySuvJJMmlae98UY5mnjjjb6XS9W2bcnHP15e1zHHJPPmlSO36t51K5Uy XtXb3rChXKZtbeX3M2cmjzySvO995fevvZacd17ywgvp97Gp9QrU7b2Yofgz3u5vohuB9DwCGYo3 0Yf6cUNAet9I/elPyQ03lN8vWZJ88pMHb8BaWpJdu5LqsT727i1fmbe393xaS8vgArJ6dTkN9eyz 5XUmyTveUU4L9Xc9fd3HI5lG6+20Sy5JPv/5MhozZ5b3saWl6/zt7T3fdpIcd1w51Vcd2XR0JKNG Hf7eU5MH5NC/wBKQ3qew3m5EBISjM4WVJJ/4RLnRa29P/neMj4OcfHL5Kryqra2cXkrKf7uftnXr wZc99tiDX+m/+mrv9+Oyy8qtSltbGY1//atrI9vfXyX1dR+P/Nl3+M+uvz758Y+TP/85Of/8rnh0 H6V0/3/32548uet3OnCgDIODSwFNEZAk+etfy6+eNp5z5pTvi2zfXn7Nn1/+LEm+9KXyTfQdO8qv BQsOvuw55yQ//GGyZ0/y/PPJN7/Z+33Ysyc5/vjyzeUXX0y+8Y2u0yZMKN/I7k1f9/FI9XRb551X Tl8tWpR89auHX6b7Mli4MOl2cKnMm5dceWV5nfv3J+vWdU1/jVBGH5YHzRSQvnzve+W0zYc/XH6d eWZy003laTfdlJx2Wvm+x4c+dPgI5r77yvdUJkwo30f41Kd6v50HH0xuvDF597vL815wQddpN96Y fPSjvY9E+rqPR6q327r++nKE9bGPHX6ZCy8sf/9Zs8r3YxYt6jrt2muTz362nAI7/vgyLr3Frftn QHweBKghB5QaSvfdV46ili07fKPfpIt5uN4D8Yr7cEP5Rrr3QBgKdqY4VHbvTu66q/xTXAABYYAv 58q/mrrnnsG/MQ8gICNQf1MApgiAJmR37gAICAACAoCAQP8cSMryQkAG5Eg+++ZzcgANGBAHJKy/ qD3+ePmh9paWcvdeX/96uUuwZuJDhJYLTTICcUDC+nLnneUeU/75z2TNmmT0aBsWoE4DUj0gYVX1 gITd7dtX7iNx0qTya8GC8mdJuW/Aq69OTjyxPO2OOwY/ctiyJfniF8vrOuGEctdRO3f2vmuo7v/v 6z5WKuVeSKZOLV/Zn39+ebiQvkYf1dvatas8IOLOnV3nefPN8lhS//hH13lvvz2ZOLG879dc07X3 9qTce/uttyannpqMH5/MnVvuN7Inf/xjebyrd72rvI077jj44JAAdRMQByTseVRTLwckXLEiOfdc KzJw9PW5M0UHJOx7uVTV4oCESXnMqi98oXxf5IwzarQCDdFO+exIcWCGaoeKdqbIURmBJOXexm+7 Lfn+9w8/nEeSvPxyucf2qtNPLw97kZT/HnraYK1eXb6BPH58uVE+4YRywz8Qfd3HpCseSXmAwOrB AgfitNPKEcdvflOGZeXKMhCHnqdq2rSDb/vFF8sQjh5dHmBx0qQyin1ZtaoM4MMP1y4ewMg2oH1h VQ9ImPR9QMLqK+yeDkhYPa23AxIed1z5fX8HJLz55uTXvy7jsXt3+Z5C9VV+X/q6j0f+6u3wn11/ fTm1N2VK7wckrN52TwckfPzx8j2YgfjVr5Jvf7sc2Z1zTh2uVYP5kMKqbsd2meKJ2fty6v7N00d+ +aE4oDocyQgkcUDC7mp5QMI77ywPT//UU3UaD0BAjoQDEnaNQob7gITXXVf+AcHMmV1/CVapJP/9 r5UZOLockXAIjcADEvb8Zuwg3hFffPcJXRf5mnWpNw8t7/r/LQt2D/BCh7/z7k106mYEQtcBCb/1 LcviSHWPB5YbjcMBpYbkVbgDEgICwiA4IOHQMX3V//LpPo0FtWQKCwABAUBAABAQAAQEAAQEAAEB QEAAEBDol91xWH4ICAACArVhNyaWEwICgIAAgIAAICAACAgAAgKAgACAgAAgIDQRu+GwHBEQAAQE asPuOSwvBAQAAQEAAQFAQAAQEAAEBAABAQABAUBAaCJ2v2F5IiAACAjUht1yWG4ICAACAgACAoCA ACAgAAgIAAICAAICgIAAICCMdPbbZLkiIAAICNSG/TlZfggIAAICAAICgIAAICAACAgAAgIAAgKA gNBE7G7D8kVAABAQqA274bAcERAABAQABAQAAQFAQAAQEAAEBAAEBAABoYnYzYbljIAAgIBQG3a/ YXkiIAAICAAICAACAoCAACAgAAgIAAgIAAJCE7F7DcsbAQEAAaE27HbDckVAABAQABAQAAQEAAEB QEAAQEAAEBAABAQAAWGks18myx0BAQABoTbsr8nyRUAAEBAAEBAABAQAAQFAQABAQAAQEAAEhCZi dxqWPwICAAJCbdjNhuWMgACAgAAgIAAICAACAoCAAICAACAgAAgITWTxqgssBI8DAgIAAkIN2L2G 5Y2AAICAACAgAAgIAAICgIAAgIAAICAACAhNxO4zPB4ICAAICLVhtxqWOwICAAICgIAAICAACAgA AgIAAgKAgAAgIAAICCOd/S55XBAQABAQasP+mCx/BAQABAQAAQGgRkZXKhVLAUYw2wCMQAAQEADq 3+iiKCwFGGE87zECAaB2IxCLoI4sXtz4v4LdZdT34/PxVbnlY083/i9yyy0eTAGhWcIBNXnOCImA CEdzuuIKD3G9PA4PPSQkCMjICEcjb3l3ndD1/7M91HXh7LOSNd3Xr6mN+7v0VkIhERDh8JIdBvQc ERIBEQ7hACEREIQDhERAEA4QEgREOEBIhERAhAMQEgERDkBIGl6lsFc14RiqxXL3CQcvhq9ZVerF Q8sP/v6WBbtH6ILo5xOVQmIEIhyAEYkRiHA06AjE6KO+RyEjdgRiRGIEIhyAEYmACAcgJAIiHICQ CIhwCAcIiZAIiHAAQiIgwgEIiYAIByAkAiIcgJCMwJA09wcJhePoLWq7Mal7dmcynAt3ZH4gsTlH IMIBGJEYgQhH441AjD4aYxRiBGJEYgQiHIARiYAIByAkAiIcAE0eksYKiHAAQiIgwgEISWOHpL4D IhyAkNRtSOozIMIBCEndh6S+AiIcgJA0TEjqIyDCAdBwIantJ9GFoynYD1bjsD+sRn3g6vOT7bUZ gQgHQMOPSI7uCEQ4mn4EYvTRWKMQIxAjkvofgQgHQNONSIY3IMIB0LQhGZ6ACAdA04dkaAMiHAAj JiRDExDhABhxIXl7AREOgBEbksEFRDgARnxIjiwgwgEgJP8zsA8SCge9rRp2Y9Jw7M6ErpXh7X0g cbRwABiRDGZE0vMIRDgYxAjE6KMxRyFGIAx2RDJaOAAYzIhktHAAMJiQjO4zHsIBICS9hGS0cAAw mJCMOuxM4sEAHfonvHgcGQEh6daI0YIBwGBGJKMsCYZkffqaZeDxYqQREMA0FgKCDQ4gIMAwM42F gGBDBAgIjcH0lccVBAQAAaE2TF95/BAQGBDTHB5fEBAABITaMP3hcURAADqZxkJAsGEBBAQYXqax EBBscAABob6YvvJ4g4AAICDUhukrjysICANiOsPjDgICgIBQG6Y5PL4gIEC/TGMhINiAAAICDC/T WAgINiyAgFAbpq+wHiAgAAgItWH6yuMNAsKAmLbA+oCAACAg1IbpDI87CAgwaKaxEBBsKAABAYaX aSwEBBsQQEAYXqavsH4gIAAICLVh+grrAQLCgJiewHqCgAAgINSGaQusDwgIMORMYyEg2CAAAgIM L9NYCAg2FICAMDRMX2G9QUAAEBBqw/QV1g8EhAExDYH1BwEBQECoDdMTWE8QEOCoMY0lIHjiAwgI MLxMYyEg2CAAAsKRMX2F9QkBAUBAqA3TV1hvEBAGxHQD1isEBAABoTZMQ2D9QUCAmjONJSB4ggMI CDC8TGMJCJ74AAJCz0xfYT1DQAAQEGrD9BXWJwSEATGtgPUNAQFAQKgN0w1YrxAQoG6ZxhIQPJEB BAQYXqaxBARPcAABGelMX2H9Q0AAEBBqw/QV1jMEhAExfYD1EAEBQECoDdMKWN8QEKDhmMYSEDxh AQQEGF6msQQET2QAARkpTF9hvURAABAQasP0FdY/BIQBMU2A9RMBAUBAqA3TB1gPERCgaZjGEhA8 MQEBARheprEEBE9YAAFpNqavsL4iIAAICLVh+grrJQKC6QCstwgIAAJCHTNNgPUTAQGanmksAcET EBAQgOFlGktA8MQEBIRGZfoK6zECAoCAUBumr7C+IiAY9mN9RkAAEBBMB4D1FgEB6o9pLAHBEw0Q EIDhZRpLQPAEBASEemf6Cus3AgKAgFAbpq+wHiMgGN6D9VxAABAQDPvB+oyAAI3DNJaA4AkFCAjA 8DKNJSB4ogECQr0wfYX1HgEBQECoDdNXWL8REAzjwfovIAAICIb3YD1HQIDGZxpLQPDEAQQEYHiZ xhIQPKEAAeFoM30Fng8CAoCAUBumr7DeIyAYroPnhYAAICAYxoP1HwEBmpdpLAHBEwQQEIDhZRpL QPDEAQSE4WL6CjxPBASApvf/5iHIqNxWR4QAAAAASUVORK5CYII= --_004_1ECAFF543A2FED4EA2BEB6CACE08E47605342356008AM1MPN1006mg_-- From vchen@google.com Fri Sep 20 19:00:50 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5432D21F9FB4 for ; Fri, 20 Sep 2013 19:00:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.776 X-Spam-Level: X-Spam-Status: No, score=-1.776 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S00dpRwtk1YL for ; Fri, 20 Sep 2013 19:00:47 -0700 (PDT) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 9D53D21F9FB1 for ; Fri, 20 Sep 2013 19:00:47 -0700 (PDT) Received: by mail-ob0-f177.google.com with SMTP id wp18so1466651obc.36 for ; Fri, 20 Sep 2013 19:00:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TtTmSpLQGMBBe3HcGVsM1yBtO8RDpnpe2cVDAzmh/KQ=; b=N9th+Mzz97SMWv28P2fVZ8GFAEv/8oI7A5pfCsEsAiJ3sLHMcZ0SQauNbSKT3uI1Qn 4/wCB484rHCDeLvn6GJvdjh/yluL+CiPxLxPgh+jSxicra/UiAwJVhfpxW90ja37PQcX J2qf47Os66T/IZDtPpEykggoYpkKiFUaqHG1+S3HR2raObGnqQ7o3H9jtV3/GebvbTQ6 N3PhEizZmTcaUyCS4RIgmm5UfXqXDJBxm2BsyyHcQhraRvKQDLZpYdcRGo+71bmcCHIh cvtP4/ruiDsmT7nTYvO3QmnGRIwasWOR+2wE9hQpqNpqwCGSXkeuj7rwWIk+cS7VjKti IRZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=TtTmSpLQGMBBe3HcGVsM1yBtO8RDpnpe2cVDAzmh/KQ=; b=aLFRJqCIAnsOEGpfYzBt4vtFneB8MsqIgOoX6qN8RsNfeihbz0AlPY/Nvi2pkgD6hb MSlCxphuziEgTzzmWpEkueq5Eexcu4FmoArfgHspMUOLkXIqFj8PwfpE3GdE3XQm1LgS 6frmT8bP3e3JnF1kojfujxlYg1C8X6D3iaeakgmNc4BfDT+k4qhTNX889N+C7ODJCubh i2ppuV1yesDfK/vpiwyTkmCTyb/XOdZmEvdCv/Q5H1bTqu0TSijq0JlVA1XeIz5hvB81 VgMg8TPAjwGMkP3e4boMb3SGNDptl4MRY4/SOh+LXHiZN3ZlwLSBByGB9wV4xQF/BIdG qrFA== X-Gm-Message-State: ALoCoQneY44+wGgdgMt6CaK1GcbhM3/SDErJ8OH7tqKm9hT3wcBAwOn2DhaB6ssllihFKS5JbHx5LUdjKssDF7p7PQmZv+tklBIlFeGSYuADJ/K+1Kg1qtC9pkcbPgZ1rHXRUMGPJ2k3Xnchq1yYTwGOxYzndgA0aJVWCqYGuQdepMLcKhHRcK21e/AFzxogUi6OkE/E2uGL MIME-Version: 1.0 X-Received: by 10.182.49.166 with SMTP id v6mr8407114obn.13.1379728847001; Fri, 20 Sep 2013 19:00:47 -0700 (PDT) Received: by 10.182.250.134 with HTTP; Fri, 20 Sep 2013 19:00:46 -0700 (PDT) In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E47605342356@008-AM1MPN1-006.mgdnok.nokia.com> References: <1ECAFF543A2FED4EA2BEB6CACE08E476053422B0@008-AM1MPN1-006.mgdnok.nokia.com> <1ECAFF543A2FED4EA2BEB6CACE08E47605342356@008-AM1MPN1-006.mgdnok.nokia.com> Date: Fri, 20 Sep 2013 19:00:46 -0700 Message-ID: From: Vincent Chen To: "gabor.bajko@nokia.com" Content-Type: multipart/related; boundary=047d7b5d2ea4d03e9704e6db27e0 Cc: "paws@ietf.org" Subject: Re: [paws] Spectrum encoding discussion X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Sep 2013 02:00:50 -0000 --047d7b5d2ea4d03e9704e6db27e0 Content-Type: multipart/alternative; boundary=047d7b5d2ea4d03e9404e6db27df --047d7b5d2ea4d03e9404e6db27df Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable All, Thanks Dan for framing the discussion. We do not like a magic value, such as "-inf" to indicate off, but simply leaving off the power would be acceptable. To make it more concrete, a Database that chooses to explicitly represent "off" channels may be encoded as the following. I've annotated the first profile with US channels. It is able to represent only frequencies that are only in the band plan and within the band plan, frequencies without a power is interpreted by the device as OFF. "spectra": [ { "bandwidth": 6e6, "profiles": [ [ { "freqHz": 5.4e7 }, // channels 2-4 off { "freqHz": 7.2e7 }, ], [ { "freqHz": 7.6e7 }, // channels 5-6 off { "freqHz": 8.8e7 }, ], [ { "freqHz": 1.74e8 }, // channels 7-13 off { "freqHz": 2.16e8 }, ], [ { "freqHz": 4.70e8, "maxPsdDbmPerBw": 30.0 }, // channel 14 { "freqHz": 4.76e8, "maxPsdDbmPerBw": 30.0 }, { "freqHz": 4.76e8 }, // channel 15-21 off { "freqHz": 5.18e8 }, { "freqHz": 5.18e8, "maxPsdDbmPerBw": 30.0 }, // channel 22 { "freqHz": 5.24e8, "maxPsdDbmPerBw": 30.0 }, { "freqHz": 5.24e8, "maxPsdDbmPerBw": 36.0 }, // channel 23 { "freqHz": 5.30e8, "maxPsdDbmPerBw": 36.0 }, { "freqHz": 5.30e8 }, { "freqHz": 6.98e8 } ] ] }, { "bandwidth": 1e5, "profiles": [ [ { "freqHz": 5.4e7 }, { "freqHz": 7.2e7 }, ], [ { "freqHz": 7.6e7 }, { "freqHz": 8.8e7 }, ], [ { "freqHz": 1.74e8 }, { "freqHz": 2.16e8 }, ], [ { "freqHz": 4.70e8, "maxPsdDbmPerBw": 27.0 }, { "freqHz": 4.76e8, "maxPsdDbmPerBw": 27.0 }, { "freqHz": 4.76e8 }, { "freqHz": 5.18e8 }, { "freqHz": 5.18e8, "maxPsdDbmPerBw": 27.0 }, { "freqHz": 5.24e8, "maxPsdDbmPerBw": 27.0 }, { "freqHz": 5.24e8, "maxPsdDbmPerBw": 33.0 }, { "freqHz": 5.30e8, "maxPsdDbmPerBw": 33.0 }, { "freqHz": 5.30e8 }, { "freqHz": 6.98e8 } ] ] } ] I hope this is getting closer to addressing most of the concerns. -vince On Fri, Sep 20, 2013 at 6:31 PM, wrote: > Few things to consider:**** > > ** ** > > **1. **I think we first have to agree whether we need at all to enc= ode an =91unavailable channel=92. Current draft section 4.4.2 says: =93The = response message for the Available Spectrum Query contains a**** > > schedule of available spectrum for the Device.=94 To me this means tha= t > channels which are not listed are implicitly unavailable and leakage into > unavailable spectrum has to conform to the rules.**** > > ** ** > > **2. **If one wants to be explicit on what the rules say for the > leakage limits, then we can encode those into the rulesetInfo.**** > > ** ** > > **3. **If we take on Andy=92s argument that PAWS could be used > outside TVWS, **and** leakage limits may potentially be different for > different bands within the same regulatory domain, then encoding all thos= e > bands and leakage limits into rulesetInfo might just complement what is > missing from the available spectrum response and we may be better off jus= t > encoding everything into available spectrum response.**** > > ** ** > > 1 and 2 doesn=92t require an encoding for unavailable channel. Simply not > listing it as available does the job.**** > > 3 would require us to agree how to encode unavailable channel, but the WS= D > would still need to know what the emission limits are in that regulatory > domain for the unavailable channels.**** > > ** ** > > **- **gabor**** > > **** > > ** ** > > *From:* paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] *On Behalf > Of *ext Harasty, Daniel J > *Sent:* Friday, September 20, 2013 5:15 PM > *To:* paws@ietf.org > > *Subject:* Re: [paws] Spectrum encoding discussion**** > > ** ** > > All:**** > > ** ** > > I know this is a long winded reply to an already laborious conversation. > But I think I can put a finger on the essential =93disagreement=94, and e= ven > offer a compromise that will allow us to move forward.**** > > ** ** > > Hint: the whole =93option 1=94/=94option 2=94 debate is a bit of a misdir= ection, > as those two options did NOT capture the two sides of the essential > disagreement; the issue at hand is really about =93is an out-of-band emis= sion > limit a good way to express that a channel is unavailable?=94**** > > ** ** > > There seems to be the camp that =93out of band emission limits=94 are the= SAME > as =93channel unavailable=94. In my reading of the FCC rules, that is si= mply > not the case. There are times when FCC rules *require* me (as a > Database) to say =93this channel is unavailable=94 *other* than =93a prot= ected > entity occupies this channel=94. For example:**** > > ** ** > > **=B7 **It is a channel categorically excluded from the Whitespac= e > spectrum (e.g. US Channel 3 or Channel 37).**** > > **=B7 **There is an ad-hoc (FCC provided) polygon establishing an > ad-hoc exclusion zone.**** > > **=B7 **A device is blacklisted.**** > > ** ** > > To say that =93Channel 37 is available at -36.8 dBm=94 is just not the sa= me as > =93Channel 37 is unavailable=94, IMO.**** > > ** ** > > To tell all devices in an ad-hoc exclusion zone that =93all channels are > available at -36.8 dBm=94 is just not the same as =93all channels are > unavailable=94.**** > > ** ** > > To tell a blacklisted device that =93all channels are available at -36.8 > dBm=94 is just not the same as =93all channels are unavailable=94.**** > > ** ** > > *In other words: If PAWS does not give me a way to say a channel is > unequivocally =93unavailable=94, then, in my opinion as a Database provid= er, it > is not sufficiently expressive for me to meet the FCC rules. * > > ** ** > > If we DO use PAWS to encode out-of-band emissions limits, I have to say, = I > think it is farfetched that a device implemented today to today=92s rules > will be able to =96 in the future =96 either =93take advantage=94 of a le= ss > stringent =93out-of-band mask=94 or comply to a more stringent mask. As > marvelous as SDRs are/can be, that degree of flexibility is just not comm= on > in consumer-grade mass market devices owing to cost. That leads me to th= e > conclusion that expecting to use PAWS that way is just not going to be th= at > useful.**** > > ** ** > > However, I realize we may differ on this point. But the notion of =93PAW= S > available-spectrum replies should encode out-of-band emissions limits=94 = is > just a separate notion from =93PAWS must allow a way to encode =91channel > unavailable=92=94. It is confounding those two concepts that =96 IMO =96= has lead > to the current =93disagreement=94.**** > > ** ** > > OK, time for my proposed grand compromise:**** > > ** ** > > **=B7 **Let=92s define a way to unequivocally encode =93channel > unavailable=94 that is NOT synonymous with =93out of band emissions limit= s=94. * I > need it as a Database provider*. (Again: I offer to recap several > different ways to do this later.)**** > > ** ** > > **=B7 **Once we have a way to unequivocally encode =93channel > unavailable=94, we can have a *separate* discussion as to whether or not = it > is ever used. Perhaps different Databases will interpret their > legal/regulatory obligations differently. Or even, a given Database may > use =93-36.8 dBm=94 in some cases and =93channel unavailable=94 in others= .**** > > ** ** > > The purpose of this WG is to produce a protocol that:**** > > ** ** > > **1. **Provides for interoperability (because it is sufficiently > clear).**** > > ** ** > > **2. **Allows all parties to meet their legal/regulatory > obligations as they interpret them.**** > > ** ** > > I feel the above proposed compromise accomplishes both.**** > > ** ** > > ** ** > > Dan Harasty**** > > ** ** > > ** ** > > ** ** > > *From:* paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] > *On Behalf Of *Andy Lee > *Sent:* Friday, September 20, 2013 7:12 PM > *To:* Peter Stanforth > *Cc:* paws@ietf.org > *Subject:* Re: [paws] Spectrum encoding discussion**** > > ** ** > > I was actually hoping to simplify things for devices.**** > > ** ** > > 1) Having a fully specified spectrum profile without discontinuities and > without "special" values like -inf make it much easier to write the clien= t > side code. This minimizes the number of special edge cases that need to = be > handled by the parsing logic and "emission fitting" code on the client.**= * > * > > ** ** > > 2) We still seem to be thinking in terms of TV channels only. PAWS is > designed for other frequency bands too, and there won't always be such a > distinct concept of on-channel vs. adjacent-channel emissions.**** > > ** ** > > 3) We don't know what future WSD technologies will be capable of. Wi-Fi > already supports a long list of modulation types (e.g., BPSK, QPSK, DSSS, > FHSS, OFDM) and channel widths. Software defined radios and other > technologies can dynamically choose modulation types, channel widths, and > power distribution. These agile radio technologies need the full spectru= m > profile to help them choose the right combination of emission parameters. > WSDs are just a "black box" from the database's point of view.**** > > ** ** > > > **** > > ** ** > > Andy Lee |**** > > Google Inc. |**** > > tvfool@google.com |**** > > 408-230-0522**** > > ** ** > > On Fri, Sep 20, 2013 at 2:35 PM, Peter Stanforth > wrote:**** > > We have, until know, always worked on the assumption that the device woul= d > be certified, or not, to comply with any out of band emissions. The FCC f= or > instance specifically tests the more stringent rule around channel 37, as > well as the more general case. The Database is not, and cannot be, the > enforcement agency. So simply providing a list of channels that it can us= e > is sufficient.**** > > It should be of no consequence to a device why it cannot use a channel > other than to behave with its compliant emissions. **** > > I agree with Gabor, why are we overly complicating this?**** > > ** ** > > *From: *"Gabor.Bajko@nokia.com" > *Date: *Friday, September 20, 2013 4:54 PM > *To: *"tvfool@google.com" , "ben@blindcreek.com" < > ben@blindcreek.com> > *Cc: *"paws@ietf.org" **** > > > *Subject: *Re: [paws] Spectrum encoding discussion**** > > ** ** > > Aren=92t we talking past each other in this thread?**** > > If the rules are supposed to specify what is the max intended power level > a device can put into a channel (available or not), then I also think thi= s > is what the DB should communicate to the device.**** > > If Ofcom specifies that the max leakage into an unavailable channel is > -33dbm, I assume the device will not be certified if it leaks more. If th= e > device supports multiple modulation types and one of them leaks more than > what is permitted in that regulatory domain, then the device will need to > know it, and in that regulatory domain avoid using that particular > modulation type. How does the device come to know it? Andy proposes the D= B > to indicate that level for the unavailable channels. Others folks seem to > suggest a device built to operate under a certain ruleset has to implicit= ly > know it.**** > > Another way of looking at it might be to say that the max level of > permitted unintentional leakage into an adjacent channel is part of the > rulesetInfo, and the spectrum response only lists the available channels. > Could this be a way forward?**** > > - gabor**** > > **** > > *From:* paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] > *On Behalf Of *ext Andy Lee > *Sent:* Friday, September 20, 2013 1:00 PM > *To:* Benjamin A. Rolfe > *Cc:* Protocol to Access White Space database > *Subject:* Re: [paws] Spectrum encoding discussion**** > > **** > > Hi Ben,**** > > **** > > And that means NO intentional radiation in the channel. **** > > **** > > If you are reading this as "transmitted emissions in band should be lower > than -33dBm" then, no, this is not the same as "no emissions" per FCC > rules. If one were to intentionally transmit at -33dBm where no intention= al > emissions are allowed, that would not be the same as "no" under the rules= . > **** > > **** > > There is certainly no intention to encourage any malicious behavior. In > general, we expect devices to be trying to do the right thing and just ne= ed > some information to understand where the boundaries are. These boundarie= s > include both intentional and unintentional emissions.**** > > **** > > Various modulation types have known spectral profiles, including both > in-band and out-of-band emissions. Knowing where the "shelf" is on the > adjacent channel makes it possible to match that with the "skirt" of the > intended modulation pattern. The "skirt" is not part of the intended > emission, but is important in trying to avoid causing interference on > adjacent channels.**** > > **** > > A crude example of this is shown in the following image:**** > > **** > > [image: Inline image 1]**** > > **** > > Best regards,**** > > > **** > > **** > > Andy Lee |**** > > Google Inc. |**** > > tvfool@google.com |**** > > 408-230-0522**** > > **** > > On Fri, Sep 20, 2013 at 3:07 AM, Benjamin A. Rolfe > wrote:**** > > **** > > On 9/19/2013 9:09 AM, Andy Lee wrote:**** > > The math bears that out, but nonetheless OFCOM are still effectively > proposing that *no* in-block transmissions are allowed in that channel.**= * > * > > **** > > Same is true for the FCC. The FCC also assumes that "off" channels are > not used by WSDs.**** > > And that means NO intentional radiation in the channel. **** > > **** > > Specifying a low power level like -33 dBm is effectively the same thing a= s > specifying no in-band emissions there.**** > > **** > > If you are reading this as "transmitted emissions in band should be lower > than -33dBm" then, no, this is not the same as "no emissions" per FCC > rules. If one were to intentionally transmit at -33dBm where no intention= al > emissions are allowed, that would not be the same as "no" under the rules= . > **** > > ** ** > > **** > > Even if someone did try to put an in-band emission there (regardless of > how impractical that actually is), it would be too low to cause > interference to anyone and no harm has been done to the "RF environment".= * > *** > > Should be a little careful here for a couple reasons. I've designed and > shipped communication systems that operate quite well with transmit power > levels intentionally below -33dBm and do very useful things. It's pretty > easy to design a receive with sensitivity better than -96dBm, so an > intentional radiator at -33dBm near by will be noticed - at 900 MHz your > 10dB above sensitivity at 10m and at 54MHz you'd be 10 dB above sensitivi= ty > at 100m, possibly. And when it comes to protecting their spectrum, people > always use the best propagation model to calculate interfence impact on > them :-). I've probably misunderstood something badly, but -33dBm is > certainly enough power to be noticed. > > I have tried the "too low to be noticed" argument a few times in the past > in regulatory discussions, and incumbent and/or protected users usually s= et > the threshold closer to -120dBm and usually argue that even at really low > TX power, the "aggregate impact" of multiple devices in the "RF > Environment" is an unacceptable impact. We had trouble with this argume= nt > when the intentional radiator TX limit was below the maximum unintentiona= l > emission limits for most non-transmitting devices (-41.3dBm). > > So it would be fairly important to ensure a device does not interpret > -33dBm as it's ok to use that channel so long as it's TX power is below > -33dBm. > > I may be off base here because of how y'all see the DB providing and wha= t > I am expecting to support future needs. "protected users" includes more > than TV stations in the US. > > Not sure that helps, but hope so. **** > > ** ** > > **** > > The advantage of having an "well behaved" spectrum profile (contiguous an= d > without special values like -inf) is that the channel selection algorithm > on the WSDs becomes much simpler and logical. There's no need to have lo= ts > of special boundary condition checks and code paths that only get trigger= ed > under special circumstances. I'd like to avoid ambiguous interpretations > on the device side as much as possible.**** > > Certainly ambiguous interpretations on the device side are a bad thing. > > Some apps are aggregating multiple TV channels to get a logical channel > that that can carry a 'wide' data pipe. Other uses can fit many useful > channels in one TV channel. In 802.15.4m we divide the TV channel up into > multiple physical channels carrying low data rate signals. Right now we > assume a peak power level for the TV channel, and we get that value with > the start frequency and width (or end frequency) from the database. > However, I've heard it proposed to the FCC that we may get different powe= r > limits different parts of the TV channel, changing over time, as a > protection mechanism for deal with narrow band protected users while > allowing effective use of the rest of the TV channel. For what we do, th= is > is a good thing - our physical channel may be less than 200kHz wide. Ther= e > are a LOT of applications in IoT that need < 200kHz channels, and > blocking an entire TV channel to protect a wireless microphone using < > 200kHz of it means there are 28 other usable channels not being used - n= ot > efficient use of the spectrum. > > Hope this helps. > > -Ben**** > > > **** > > **** > > Andy Lee |**** > > Google Inc. |**** > > tvfool@google.com |**** > > 408-230-0522**** > > **** > > On Thu, Sep 19, 2013 at 8:30 AM, Ray Bellis > wrote:**** > > > On 19 Sep 2013, at 16:21, Andy Lee **** > > wrote: > > > This actually shows that Ofcom has picked a power threshold on channel > 38 of -33 dBm. If you look at the ACLR numbers for class 3, 4, and 5 > devices, you'll see they are 10 dB apart from each other and that they al= l > work out to be -33 dBm on channel 38. > > > > The reason there are no limits for class 1 and 2 devices is because the > in-band power on channels 37 and 39 cannot exceed +36 dBm/8MHz, and > therefore the power on channel 38 will naturally be less than -33 dBm.***= * > > The math bears that out, but nonetheless OFCOM are still effectively > proposing that *no* in-block transmissions are allowed in that channel. > > Per OFCOM / ETSI device interface requirements it would be incorrect for > us to actually send that value of -33 dBm to a device. > > Ray**** > > **** > > **** > > _______________________________________________**** > > paws mailing list**** > > paws@ietf.org**** > > https://www.ietf.org/mailman/listinfo/paws**** > > **** > > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws**** > > **** > > ** ** > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > > --=20 -vince --047d7b5d2ea4d03e9404e6db27df Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable =
All,

Thanks Dan for framing the discuss= ion. We do not like a magic value, such as "-inf" to indicate off= , but simply leaving off the power would be acceptable.
To make i= t more concrete, a Database that chooses to explicitly represent "off&= quot; channels may be encoded as the following.=A0

I've annotated the first profile with US channels. = It is able to represent only frequencies that are only in the band plan
and within the band plan, frequencies without a power is interpreted= by the device as OFF.

"spectra": [
=A0 {
= =A0 =A0 "bandwidth": 6e6,
=A0 =A0 "profiles":= [
=A0 =A0 =A0 [
=A0 =A0 =A0 =A0 { "freqHz": = 5.4e7 }, =A0// channels 2-4 off
=A0 =A0 =A0 =A0 { "freqHz": 7.2e7 },
=A0 =A0 =A0 ]= ,
=A0 =A0 =A0 [
=A0 =A0 =A0 =A0 { "freqHz": 7= .6e7 }, =A0// channels 5-6 off
=A0 =A0 =A0 =A0 { "freqHz&quo= t;: 8.8e7 },
=A0 =A0 =A0 ],
=A0 =A0 =A0 [
=A0 =A0 =A0 =A0 { "freqHz": 1.74e8 }= , // channels 7-13 off
=A0 =A0 =A0 =A0 { "freqHz": 2.16= e8 },
=A0 =A0 =A0 ],
=A0 =A0 =A0 [
=A0 =A0 = =A0 =A0 { "freqHz": 4.70e8, "maxPsdDbmPerBw": 30.0 }, = =A0// channel 14
=A0 =A0 =A0 =A0 { "freqHz": 4.76e8, "maxPsdDbmPerBw&quo= t;: 30.0 },
=A0 =A0 =A0 =A0 { "freqHz": 4.76e8 }, =A0//= channel 15-21 off
=A0 =A0 =A0 =A0 { "freqHz": 5.18e8 }= ,
=A0 =A0 =A0 =A0 { "freqHz": 5.18e8, "maxPsdDbmPe= rBw": 30.0 }, =A0// channel 22
=A0 =A0 =A0 =A0 { "freqHz": 5.24e8, "maxPsdDbmPerBw&quo= t;: 30.0 },
=A0 =A0 =A0 =A0 { "freqHz": 5.24e8, "m= axPsdDbmPerBw": 36.0 }, =A0// channel 23
=A0 =A0 =A0 =A0 { &= quot;freqHz": 5.30e8, "maxPsdDbmPerBw": 36.0 },
=A0 =A0 =A0 =A0 { "freqHz": 5.30e8 },
=A0 =A0 =A0 = =A0 { "freqHz": 6.98e8 }
=A0 =A0 =A0 ]
=A0 = =A0 ]
=A0 },
=A0 {
=A0 =A0 "bandwidth&qu= ot;: 1e5,
=A0 =A0 "profiles": [
=A0 =A0 =A0 [
=A0 =A0 =A0 =A0 { "freqHz": 5.4e7 },=
=A0 =A0 =A0 =A0 { "freqHz": 7.2e7 },
=A0 =A0= =A0 ],
=A0 =A0 =A0 [
=A0 =A0 =A0 =A0 { "freqHz&qu= ot;: 7.6e7 },
=A0 =A0 =A0 =A0 { "freqHz": 8.8e7 },
=A0 =A0 =A0 ],
=A0 =A0 =A0 [
=A0 =A0 =A0 =A0 { &qu= ot;freqHz": 1.74e8 },
=A0 =A0 =A0 =A0 { "freqHz": = 2.16e8 },
=A0 =A0 =A0 ],
=A0 =A0 =A0 [
=A0 = =A0 =A0 =A0 { "freqHz": 4.70e8, "maxPsdDbmPerBw": 27.0 = },
=A0 =A0 =A0 =A0 { "freqHz": 4.76e8, "maxPsdDbmPerBw&quo= t;: 27.0 },
=A0 =A0 =A0 =A0 { "freqHz": 4.76e8 },
=
=A0 =A0 =A0 =A0 { "freqHz": 5.18e8 },
=A0 =A0 =A0 = =A0 { "freqHz": 5.18e8, "maxPsdDbmPerBw": 27.0 },
=A0 =A0 =A0 =A0 { "freqHz": 5.24e8, "maxPsdDbmPerBw&quo= t;: 27.0 },
=A0 =A0 =A0 =A0 { "freqHz": 5.24e8, "m= axPsdDbmPerBw": 33.0 },
=A0 =A0 =A0 =A0 { "freqHz"= : 5.30e8, "maxPsdDbmPerBw": 33.0 },
=A0 =A0 =A0 =A0 { "freqHz": 5.30e8 },
=A0 =A0 =A0 = =A0 { "freqHz": 6.98e8 }
=A0 =A0 =A0 ]
=A0 = =A0 ]
=A0 }
]

I hope thi= s is getting closer to addressing most of the concerns.

-vince


On Fri, Sep 20, 2013 at 6:31 PM, <Gabor.Bajk= o@nokia.com> wrote:
Few things to consider:
=A0
1.<=
span style=3D"font:7.0pt "Times New Roman"">=A0=A0=A0=A0=A0=A0 I think we first have =
to agree whether we need at all to encode an =91unavailable channel=92. Cur=
rent draft section 4.4.2 says: =93The response message for the Avail=
able Spectrum Query contains a

=A0=A0 schedule of available spectrum for the Device.=94 To me this means that channels which are not listed are implicitly unavailable and leakage into unavailable spectru= m has to conform to the rules.

=A0<= /p>

2.=A0=A0=A0=A0=A0=A0 If one wants to be e= xplicit on what the rules say for the leakage limits, then we can encode th= ose into the rulesetInfo.

=A0<= /p>

3.=A0=A0=A0=A0=A0=A0 If we take on Andy= =92s argument that PAWS could be used outside TVWS, *and* leakage li= mits may potentially be different for different bands within the same regulatory domain, then encoding all those bands and leakage limi= ts into rulesetInfo might just complement what is missing from the availabl= e spectrum response and we may be better off just encoding everything into = available spectrum response.

=A0<= /p>

1 and 2 doesn=92t require= an encoding for unavailable channel. Simply not listing it as available do= es the job.

3 would require us to agr= ee how to encode unavailable channel, but the WSD would still need to know = what the emission limits are in that regulatory domain for the unavailable channels.

=A0<= /p>

-=A0=A0=A0=A0=A0=A0=A0=A0=A0 gabor<= /span>

=A0<= /p>

From: paws-bounces@ietf.org [mailto:paws-= bounces@ietf.org] On Behalf Of ext Harasty, Daniel J
Sent: Friday, September 20, 2013 5:15 PM
To: paws@ietf.org=


Subject: Re: [paws] Spectrum encoding discussion
=

=A0

All:=

=A0<= /p>

I know this is a long win= ded reply to an already laborious conversation.=A0 But I think I can put a = finger on the essential =93disagreement=94, and even offer a compromise that will allow us to move forward.

=A0<= /p>

Hint: the whole =93option= 1=94/=94option 2=94 debate is a bit of a misdirection, as those two option= s did NOT capture the two sides of the essential disagreement; the issue at hand is really about =93is an out-of-band emission limit a good w= ay to express that a channel is unavailable?=94

=A0<= /p>

There seems to be the cam= p that =93out of band emission limits=94 are the SAME as =93channel unavail= able=94.=A0 In my reading of the FCC rules, that is simply not the case.=A0 There are times when FCC rules require me (as a Database) = to say =93this channel is unavailable=94 other than =93a protected entity occupies this channel=94.=A0 For ex= ample:

=A0<= /p>

=B7=A0=A0=A0= =A0=A0=A0=A0=A0 It is a channel cate= gorically excluded from the Whitespace spectrum (e.g. US Channel 3 or Chann= el 37).

=B7=A0=A0=A0= =A0=A0=A0=A0=A0 There is an ad-hoc (= FCC provided) polygon establishing an ad-hoc exclusion zone.<= /span>

=B7=A0=A0=A0= =A0=A0=A0=A0=A0 A device is blacklis= ted.

=A0<= /p>

To say that =93Channel 37= is available at -36.8 dBm=94 is just not the same as =93Channel 37 is unav= ailable=94, IMO.

=A0<= /p>

To tell all devices in an= ad-hoc exclusion zone that =93all channels are available at -36.8 dBm=94 i= s just not the same as =93all channels are unavailable=94.

=A0<= /p>

To tell a blacklisted dev= ice that =93all channels are available at -36.8 dBm=94 is just not the same= as =93all channels are unavailable=94.

=A0<= /p>

In other words: If PAW= S does not give me a way to say a channel is unequivocally =93unavailable= =94, then, in my opinion as a Database provider, it is not sufficiently expressive for me to meet the FCC rules. =A0

=A0<= /p>

If we DO use PAWS to enco= de out-of-band emissions limits, I have to say, I think it is farfetched th= at a device implemented today to today=92s rules will be able to =96 in the future =96 either =93take advantage=94 of a less stringent = =93out-of-band mask=94 or comply to a more stringent mask.=A0 As marvelous = as SDRs are/can be, that degree of flexibility is just not common in consum= er-grade mass market devices owing to cost.=A0 That leads me to the conclusion that expecting to use PAWS that way is just not= going to be that useful.

=A0<= /p>

However, I realize we may= differ on this point.=A0 But the notion of =93PAWS available-spectrum repl= ies should encode out-of-band emissions limits=94 is just a separate notion from =93PAWS must allow a way to encode =91channel unavailable=92= =94.=A0 It is confounding those two concepts that =96 IMO =96 has lead to t= he current =93disagreement=94.

=A0<= /p>

OK, time for my proposed = grand compromise:

=A0<= /p>

=B7=A0=A0=A0= =A0=A0=A0=A0=A0 Let=92s define a way= to unequivocally encode =93channel unavailable=94 that is NOT synonymous w= ith =93out of band emissions limits=94. =A0I need it as a Database provider.=A0 (Again: I offer to recap sev= eral different ways to do this later.)

=A0<= /p>

=B7=A0=A0=A0= =A0=A0=A0=A0=A0 Once we have a way t= o unequivocally encode =93channel unavailable=94, we can have a separate discussion as to whether or not it is ever used.=A0 Perhaps= different Databases will interpret their legal/regulatory obligations diff= erently.=A0 Or even, a given Database may use =93-36.8 dBm=94 in some cases= and =93channel unavailable=94 in others.

=A0<= /p>

The purpose of this WG is= to produce a protocol that:

=A0<= /p>

1.=A0=A0=A0=A0=A0=A0 Provides for interop= erability (because it is sufficiently clear).

=A0<= /p>

2.=A0=A0=A0=A0=A0=A0 Allows all parties t= o meet their legal/regulatory obligations as they interpret them.=

=A0<= /p>

I feel the above proposed= compromise accomplishes both.

=A0<= /p>

=A0<= /p>

Dan Harasty=

=A0<= /p>

=A0<= /p>

=A0<= /p>

From: paws-bounces@iet= f.org [mailt= o:paws-bounces@ietf.org] On Behalf Of Andy Lee
Sent: Friday, September 20, 2013 7:12 PM
To: Peter Stanforth
Cc: paws@ietf.org=
Subject: Re: [paws] Spectrum encoding discussion

=A0

I was actually hoping to simplify things for devices= .

=A0

1) Having a fully specified spectrum profile without= discontinuities and without "special" values like -inf make it m= uch easier to write the client side code. =A0This minimizes the number of s= pecial edge cases that need to be handled by the parsing logic and "emission fitting" code on the client.<= u>

=A0

2) We still seem to be thinking in terms of TV chann= els only. =A0PAWS is designed for other frequency bands too, and there won&= #39;t always be such a distinct concept of on-channel vs. adjacent-channel = emissions.

=A0

3) We don't know what future WSD technologies wi= ll be capable of. =A0Wi-Fi already supports a long list of modulation types= (e.g., BPSK, QPSK, DSSS, FHSS, OFDM) and channel widths. =A0Software defin= ed radios and other technologies can dynamically choose modulation types, channel widths, and power distribution. =A0These = agile radio technologies need the full spectrum profile to help them choose= the right combination of emission parameters. =A0WSDs are just a "bla= ck box" from the database's point of view.

=A0


=A0

Andy Lee=A0|

=A0Google Inc. |

=A0tvfool@google.com=A0|

=A0408-230-0522

=A0

On Fri, Sep 20, 2013 at 2:35 PM, Peter Stanforth <= ;peter@spectr= umbridge.com> wrote:

We have, until know, always worked on t= he assumption that the device would be certified, or not, to comply with an= y out of band emissions. The FCC for instance specifically tests the more stringent rule around channel 37, as well as the more gener= al case. The Database is not, and cannot be, the enforcement agency. So sim= ply providing a list of channels that it can use is sufficient.

It should be of no consequence to a dev= ice why it cannot use a channel other than to behave with its compliant emi= ssions.=A0

I agree with Gabor, why are we overly c= omplicating this?

=A0

From: "Gabor.Bajko@nokia.com" <Gabor.Bajko@nokia.com>
Date: Friday, September 20, 2013 4:54 PM
To: "tvf= ool@google.com" <tvfool@google.com>, "ben@blindcreek.com" <ben@blindcreek.com>
Cc: "paws@ie= tf.org" <paw= s@ietf.org>


Subject: Re: [paws] Spectrum encoding discussion

=A0

Aren=92t we talking past = each other in this thread?

If the rules are supposed= to specify what is the max intended power level a device can put into a channel (available or not), then I also think this is what the DB should c= ommunicate to the device.

If Ofcom specifies that t= he max leakage into an unavailable channel is -33dbm, I assume the device will not be certified if it leaks more. If the device supports multiple mo= dulation types and one of them leaks more than what is permitted in that re= gulatory domain, then the device will need to know it, and in that regulato= ry domain avoid using that particular modulation type. How does the device come to know it? Andy proposes the DB= to indicate that level for the unavailable channels. Others folks seem to = suggest a device built to operate under a certain ruleset has to implicitly= know it.

Another way of looking at= it might be to say that the max level of permitted unintentional leakage into an adjacent channel is part of the rulesetInfo, and the spectrum resp= onse only lists the available channels. Could this be a way forward?=

-=A0=A0=A0=A0=A0=A0=A0=A0=A0 gabor

=A0<= /p>

From: paws-bounces@iet= f.org [mailt= o:paws-bounces@ietf.org] On Behalf Of ext Andy Lee
Sent: Friday, September 20, 2013 1:00 PM
To: Benjamin A. Rolfe
Cc: Protocol to Access White Space database
Subject: Re: [paws] Spectrum encoding discussion

=A0

Hi Ben,

=A0

And that means NO intentional radiation i= n the channel.=A0=A0

=A0

If you are reading this as "transmit= ted emissions in band should be lower than -33dBm" then, no, this is n= ot the same as "no emissions" per FCC rules. If one were to intentional= ly transmit at -33dBm where no intentional emissions are allowed, that woul= d not be the same as "no" under the rules.

=A0

There is certainly no intention to encourage any malicious= behavior. =A0In general, we expect devices to be trying to do the right th= ing and just need some information to understand where the boundaries are. =A0= These boundaries include both intentional and unintentional emissions.

=A0

Various modulation types have known spectral profiles, inc= luding both in-band and out-of-band emissions. =A0Knowing where the "s= helf" is on the adjacent channel makes it possible to match that with the "= skirt" of the intended modulation pattern. =A0The "skirt" is= not part of the intended emission, but is important in trying to avoid cau= sing interference on adjacent channels.

=A0

A crude example of this is shown in the following image:

=A0

3D"Inline

=A0

Best regards,


=A0

Andy Lee=A0|

=A0Google Inc. |

=A0tvfool@google.com=A0|

=A0408-230-0522

=A0

On Fri, Sep 20, 2013 at 3:07 AM, Benjamin A. Rolfe &= lt;ben@blindcreek.c= om> wrote:

=A0

On 9/19/2013 9:09 AM, Andy Lee wrote:<= /p>

The math bears that out, but nonetheless= =A0OFCOM=A0are still effectively proposing that *no* in-block transmissions= are allowed in that channel.

=A0

Same is true for the FCC. =A0The FCC also assumes th= at "off" channels are not used by WSDs.

And that means NO intentional radiation in the chann= el.=A0

=A0

Specifying a low power level like -33 dBm is effecti= vely the same thing as specifying no in-band emissions there.=

=A0

If you are reading this as "transmitted emissio= ns in band should be lower than -33dBm" then, no, this is not the same= as "no emissions" per FCC rules. If one were to intentionally transmit at -33dBm where no intentional emissions are allowed, that would = not be the same as "no" under the rules.

=A0

=A0

Even if someone did try to put an in-band emission t= here (regardless of how impractical that actually is), it would be too low = to cause interference to anyone and no harm has been done to the "RF environment".

Should be a little careful here for a couple reasons= .=A0 I've designed and shipped communication systems that operate quite= well with transmit power levels intentionally below -33dBm and do very useful things. It's pretty easy to design a receive with s= ensitivity better than -96dBm, so an intentional radiator at -33dBm near by= will be noticed - at 900 MHz your 10dB above sensitivity at 10m and at 54M= Hz you'd be 10 dB above sensitivity at 100m, possibly. And when it comes to protecting their spectrum, people = always use the best propagation model to calculate interfence impact on the= m :-).=A0 I've probably misunderstood something badly, but -33dBm is ce= rtainly enough power to be noticed.

I have tried the "too low to be noticed" argument a few times in = the past=A0 in regulatory discussions, and incumbent and/or protected users= usually set the threshold closer to -120dBm and usually argue that even at= really low TX power, the "aggregate impact" of multiple devices in the "RF Environment" is an unacceptable i= mpact.=A0=A0 We had trouble with this argument when the intentional radiato= r TX limit was below the maximum unintentional emission limits for most non= -transmitting devices (-41.3dBm).

So it would be fairly important to ensure a device does not interpret -33dB= m as it's ok to use that channel so long as it's TX power is below = -33dBm.

I may be off base here because of=A0 how y'all see the DB providing and= what I am expecting to support future needs. "protected users" i= ncludes more than TV stations in the US.=A0

Not sure that helps, but hope so.=A0

=A0

=A0

The advantage of having an "well behaved" = spectrum profile=A0(contiguous and without special values like -inf)=A0is t= hat the channel selection algorithm on the WSDs becomes much simpler and logical. =A0There's no need to have lots of special boundary condi= tion checks and code paths that only get triggered under special circumstan= ces. =A0I'd like to avoid ambiguous interpretations on the device side = as much as possible.

Certainly ambiguous i= nterpretations on the device side are a bad thing.

Some apps are aggregating multiple TV channels to get a logical channel tha= t that can carry a 'wide'=A0 data pipe. Other uses can fit many use= ful channels in one TV channel. In 802.15.4m we divide the TV channel up in= to multiple physical channels carrying low data rate signals.=A0 Right now we assume a peak power level for the TV ch= annel, and we get that value with the start frequency and width (or end fre= quency) from the database. However, I've heard it proposed to the FCC t= hat we may get different power limits different parts of the TV channel, changing over time, as a protection mec= hanism for deal with narrow band protected users while allowing effective u= se of the rest of the TV channel.=A0 For what we do, this is a good thing -= our physical channel may be less than 200kHz wide. There are a LOT of applications=A0 in IoT that need <= 200kHz channels,=A0 and blocking an entire TV channel to protect a wireles= s microphone using < 200kHz of it means there are 28 other usable channe= ls=A0 not being used - not efficient use of the spectrum.=A0=A0

Hope this helps.=A0=A0

-Ben


=A0

Andy Lee=A0|

=A0Google Inc. |

=A0tvfool@google.com=A0|

=A0408-230-0522

=A0

On Thu, Sep 19, 2013 at 8:30 AM, Ray Bellis <Ray.Bellis@nomin= et.org.uk> wrote:


On 19 Sep 2013, at 16:21, Andy Lee <tvfool@google.com>

=A0wrote:

> This actually shows that Ofcom has picked a power threshold on channel= 38 of -33 dBm. =A0If you look at the ACLR numbers for class 3, 4, and 5 de= vices, you'll see they are 10 dB apart from each other and that they al= l work out to be -33 dBm on channel 38.
>
> The reason there are no limits for class 1 and 2 devices is because th= e in-band power on channels 37 and 39 cannot exceed +36 dBm/8MHz, and there= fore the power on channel 38 will naturally be less than -33 dBm.=

The math bears that o= ut, but nonetheless OFCOM are still effectively proposing that *no* in-bloc= k transmissions are allowed in that channel.

Per OFCOM / ETSI device interface requirements it would be incorrect for us= to actually send that value of -33 dBm to a device.

Ray

=A0

=A0

_______________________________________________
paws mailing list
paws@ietf.org
https://www.ietf.org/mailman/listinfo/paws

=A0


_______________________________________________
paws mailing list
paws@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/paws

=A0

=A0


_______________________________________________
paws mailing list
paws@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/paws




--
-vince
--047d7b5d2ea4d03e9404e6db27df-- --047d7b5d2ea4d03e9704e6db27e0 Content-Type: image/png; name="image001.png" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: 606c1362c91ef9f4_0.0.1 iVBORw0KGgoAAAANSUhEUgAAAZAAAAGQCAYAAACAvzbMAAAAAXNSR0IArs4c6QAAFFxJREFUeNrt 3XuQlXXhx/HPIfzhWikgCaMToIhBRjqZOfaPNTbWFpNNpSNdtGGyZNSAdMyw0ZhRCC21zHI0Z/Cv bOoPxy5qJuBfTTOMIpe4tKAmeCmSaMIFlH1+fzyd3QX2xrrLuezrNbMDu+e6z3nO8z7f79nzPJWi KIoAwBEaZREAICAACAgAAgKAgACAgAAgIEdPpVKxEAD6C0ilUun8mjBhQi6++OI8//zzlhoA/Y9A iqJIURTZtGlTZs6cmcsvv9xSA2DgU1gTJkzIokWL8uyzzyZJ9u3blwULFmTSpEmZNGlSFixYkH37 9mX69OnZvHlzkmTHjh0ZNWpUXn755STJpk2bMn369M7r7OjoyK233ppTTz0148ePz9y5c7Nnz57O 0c9dd92V9773vRk1que72d/l77vvvkydOjUtLS05//zzs379+jz33HOZNm1aun8AvyiKTJs2LWvX ru33ervrbRlUb//222/PxIkTc+KJJ+aaa67J/v37B3TfAZoqIDt37sySJUty9tlnJ0luu+22bNiw IatXr87q1auzdu3aLFmyJK2trVm1alWS5NFHH82YMWPyu9/9LkmycuXKfPrTn+68zrvvvjurVq3K ihUrsnXr1rz55pu5+eabO09/+umn85e//CUdHR093qf+Lv/EE09k1apV2blzZ1pbW3PVVVflrLPO ytixY7NixYrO8z311FMZN25cPvjBDw7oeqt6WwZVTz75ZJ555pmsXbs2mzdvztKlSwd83wHqXtGH JJ1f48ePL2bPnl20tbUVRVEUp512WrFhw4bO865bt66YNm1a8Yc//KGYM2dOURRF0draWtxwww3F 7Nmzi6IoiksvvbR47LHHOi8zY8aMYtOmTZ3fv/rqq8WUKVM6b/uFF17o6+71e/lXXnml87Q9e/YU LS0tRVEUxU9/+tPi0ksv7TztkksuKe69994BX29Vb8uger7up61fv77ztP5uA6ARVPramWKlUklv J7e0tGTXrl059thjkyR79+7NuHHj8vrrr2fWrFlZs2ZNJk+enG3btmXatGl56aWXcuaZZ2bjxo2d lznuuOM6p3WKokhHR0dGjRqVAwcOpFKppKOjo8+/eurv8ofe9+rP/v3vf2fKlCnZunVriqLI6aef nhdffDFjx449ouvtbRm0t7enUqmkvb29x9P6uw2ApprCOtTJJ5+cbdu2dX7f1taWU045JS0tLZk+ fXruvffenHvuuRk7dmzOOeec3HPPPZk5c2bnBjVJJk+enLa2trz11ls5cOBAiqI4aAPa35/M9nf5 3owdOzaf+cxnsnz58ixfvjyzZ8/ujMeRXG9vy6Cq+2nbtm076LTB3neAhg/InDlzMn/+/Gzfvj3b t2/P/PnzM2fOnCRJa2trli5dmosuuihJctFFF2Xp0qVpbW096DrmzZuXK6+8Mhs3bsz+/fuzbt26 XHbZZQO+D2/n8nPnzs0DDzyQX/ziF5k7d+6grrevZZAkCxcuzI4dO7Jjx44sXLgwX/7yl4fsdweo +/dAetPe3l5ce+21xcSJE4uJEycW1157bdHe3l4URVFs2bKlSFI899xzRVEUxZo1a4okxd/+9reD ruPAgQPFT37yk2LGjBnFmDFjilmzZhWPPPJIv7c92Mt3/1lHR0cxderUYurUqUVHR8egrrevZZCk WLZsWXHSSScV48aNK+bNm1fs3bt3QLcB0PDvgTB4fb1/BDCip7AAGNlGWwS83ZEWjc1IGSMQT0oA AQGg/pnCwqhrBDL1iBEIACNsBFKpJAN9tXok56XhLV5sGfTnllssAxphBFKpJA88cPjPH3usPK2+ xuQD+9lw3dbR/D2rXwB1G5Akuf/+5NB9NN1+e2P8ds04cikKIzKgLvQ/hXXBBckvf5l85Svl97// fTJjRvK/Y34kSfbtS77zneThh8vvL7ssWbYsGTMm2b8/WbiwPO2YY5Lrrjv8FfWhG8Tepq22bEkW LUpWrkzeeiu58MIycO95z8Ejg+plu19PX/exUkl+/vPkBz9IXnstOfvscuT1gQ/0Pvqo/vv668kZ ZyQbNyYTJpQ/e/PN5JRTkvXrk5NOKs+7bFnyox+V93vOnOTOO5P/+7/y/B0dyZIlyYMPJrt3J5/7 XHLPPck73zmiV84rrvAErXroIcuARhyBXH11ufGrbogXL07mzz/4PLfdlmzYkKxeXX6tXVtuEJPy 3y1byp+tXl1Ofw3WJZeU92f79uTvfy830t/9btd96+vVeV/3MUmeeKKM4s6dSWtrctVVfY9qqrc1 blwZo/vv7zrPypXJRz5SxqPqySeTZ54pb3fz5qTbwaVy993lba9YkWzdWgbIwaWAOtf3vrCqr+Av vji5/PLyFfPPftb1Hkj1otOmJb/9bfL+95ffr19fvopua0tOPz159NGDT5s1q+dRQk8jkL7eRP/P f5Izz0xeeqn/6+nrPlYqySuvJJMmlae98UY5mnjjjb6XS9W2bcnHP15e1zHHJPPmlSO36t51K5Uy XtXb3rChXKZtbeX3M2cmjzySvO995fevvZacd17ywgvp97Gp9QrU7b2Yofgz3u5vohuB9DwCGYo3 0Yf6cUNAet9I/elPyQ03lN8vWZJ88pMHb8BaWpJdu5LqsT727i1fmbe393xaS8vgArJ6dTkN9eyz 5XUmyTveUU4L9Xc9fd3HI5lG6+20Sy5JPv/5MhozZ5b3saWl6/zt7T3fdpIcd1w51Vcd2XR0JKNG Hf7eU5MH5NC/wBKQ3qew3m5EBISjM4WVJJ/4RLnRa29P/neMj4OcfHL5Kryqra2cXkrKf7uftnXr wZc99tiDX+m/+mrv9+Oyy8qtSltbGY1//atrI9vfXyX1dR+P/Nl3+M+uvz758Y+TP/85Of/8rnh0 H6V0/3/32548uet3OnCgDIODSwFNEZAk+etfy6+eNp5z5pTvi2zfXn7Nn1/+LEm+9KXyTfQdO8qv BQsOvuw55yQ//GGyZ0/y/PPJN7/Z+33Ysyc5/vjyzeUXX0y+8Y2u0yZMKN/I7k1f9/FI9XRb551X Tl8tWpR89auHX6b7Mli4MOl2cKnMm5dceWV5nfv3J+vWdU1/jVBGH5YHzRSQvnzve+W0zYc/XH6d eWZy003laTfdlJx2Wvm+x4c+dPgI5r77yvdUJkwo30f41Kd6v50HH0xuvDF597vL815wQddpN96Y fPSjvY9E+rqPR6q327r++nKE9bGPHX6ZCy8sf/9Zs8r3YxYt6jrt2muTz362nAI7/vgyLr3Frftn QHweBKghB5QaSvfdV46ili07fKPfpIt5uN4D8Yr7cEP5Rrr3QBgKdqY4VHbvTu66q/xTXAABYYAv 58q/mrrnnsG/MQ8gICNQf1MApgiAJmR37gAICAACAoCAQP8cSMryQkAG5Eg+++ZzcgANGBAHJKy/ qD3+ePmh9paWcvdeX/96uUuwZuJDhJYLTTICcUDC+nLnneUeU/75z2TNmmT0aBsWoE4DUj0gYVX1 gITd7dtX7iNx0qTya8GC8mdJuW/Aq69OTjyxPO2OOwY/ctiyJfniF8vrOuGEctdRO3f2vmuo7v/v 6z5WKuVeSKZOLV/Zn39+ebiQvkYf1dvatas8IOLOnV3nefPN8lhS//hH13lvvz2ZOLG879dc07X3 9qTce/uttyannpqMH5/MnVvuN7Inf/xjebyrd72rvI077jj44JAAdRMQByTseVRTLwckXLEiOfdc KzJw9PW5M0UHJOx7uVTV4oCESXnMqi98oXxf5IwzarQCDdFO+exIcWCGaoeKdqbIURmBJOXexm+7 Lfn+9w8/nEeSvPxyucf2qtNPLw97kZT/HnraYK1eXb6BPH58uVE+4YRywz8Qfd3HpCseSXmAwOrB AgfitNPKEcdvflOGZeXKMhCHnqdq2rSDb/vFF8sQjh5dHmBx0qQyin1ZtaoM4MMP1y4ewMg2oH1h VQ9ImPR9QMLqK+yeDkhYPa23AxIed1z5fX8HJLz55uTXvy7jsXt3+Z5C9VV+X/q6j0f+6u3wn11/ fTm1N2VK7wckrN52TwckfPzx8j2YgfjVr5Jvf7sc2Z1zTh2uVYP5kMKqbsd2meKJ2fty6v7N00d+ +aE4oDocyQgkcUDC7mp5QMI77ywPT//UU3UaD0BAjoQDEnaNQob7gITXXVf+AcHMmV1/CVapJP/9 r5UZOLockXAIjcADEvb8Zuwg3hFffPcJXRf5mnWpNw8t7/r/LQt2D/BCh7/z7k106mYEQtcBCb/1 LcviSHWPB5YbjcMBpYbkVbgDEgICwiA4IOHQMX3V//LpPo0FtWQKCwABAUBAABAQAAQEAAQEAAEB QEAAEBDol91xWH4ICAACArVhNyaWEwICgIAAgIAAICAACAgAAgKAgACAgAAgIDQRu+GwHBEQAAQE asPuOSwvBAQAAQEAAQFAQAAQEAAEBAABAQABAUBAaCJ2v2F5IiAACAjUht1yWG4ICAACAgACAoCA ACAgAAgIAAICAAICgIAAICCMdPbbZLkiIAAICNSG/TlZfggIAAICAAICgIAAICAACAgAAgIAAgKA gNBE7G7D8kVAABAQqA274bAcERAABAQABAQAAQFAQAAQEAAEBAAEBAABoYnYzYbljIAAgIBQG3a/ YXkiIAAICAAICAACAoCAACAgAAgIAAgIAAJCE7F7DcsbAQEAAaE27HbDckVAABAQABAQAAQEAAEB QEAAQEAAEBAABAQAAWGks18myx0BAQABoTbsr8nyRUAAEBAAEBAABAQAAQFAQABAQAAQEAAEhCZi dxqWPwICAAJCbdjNhuWMgACAgAAgIAAICAACAoCAAICAACAgAAgITWTxqgssBI8DAgIAAkIN2L2G 5Y2AAICAACAgAAgIAAICgIAAgIAAICAACAhNxO4zPB4ICAAICLVhtxqWOwICAAICgIAAICAACAgA AgIAAgKAgAAgIAAICCOd/S55XBAQABAQasP+mCx/BAQABAQAAQGgRkZXKhVLAUYw2wCMQAAQEADq 3+iiKCwFGGE87zECAaB2IxCLoI4sXtz4v4LdZdT34/PxVbnlY083/i9yyy0eTAGhWcIBNXnOCImA CEdzuuIKD3G9PA4PPSQkCMjICEcjb3l3ndD1/7M91HXh7LOSNd3Xr6mN+7v0VkIhERDh8JIdBvQc ERIBEQ7hACEREIQDhERAEA4QEgREOEBIhERAhAMQEgERDkBIGl6lsFc14RiqxXL3CQcvhq9ZVerF Q8sP/v6WBbtH6ILo5xOVQmIEIhyAEYkRiHA06AjE6KO+RyEjdgRiRGIEIhyAEYmACAcgJAIiHICQ CIhwCAcIiZAIiHAAQiIgwgEIiYAIByAkAiIcgJCMwJA09wcJhePoLWq7Mal7dmcynAt3ZH4gsTlH IMIBGJEYgQhH441AjD4aYxRiBGJEYgQiHIARiYAIByAkAiIcAE0eksYKiHAAQiIgwgEISWOHpL4D IhyAkNRtSOozIMIBCEndh6S+AiIcgJA0TEjqIyDCAdBwIantJ9GFoynYD1bjsD+sRn3g6vOT7bUZ gQgHQMOPSI7uCEQ4mn4EYvTRWKMQIxAjkvofgQgHQNONSIY3IMIB0LQhGZ6ACAdA04dkaAMiHAAj JiRDExDhABhxIXl7AREOgBEbksEFRDgARnxIjiwgwgEgJP8zsA8SCge9rRp2Y9Jw7M6ErpXh7X0g cbRwABiRDGZE0vMIRDgYxAjE6KMxRyFGIAx2RDJaOAAYzIhktHAAMJiQjO4zHsIBICS9hGS0cAAw mJCMOuxM4sEAHfonvHgcGQEh6daI0YIBwGBGJKMsCYZkffqaZeDxYqQREMA0FgKCDQ4gIMAwM42F gGBDBAgIjcH0lccVBAQAAaE2TF95/BAQGBDTHB5fEBAABITaMP3hcURAADqZxkJAsGEBBAQYXqax EBBscAABob6YvvJ4g4AAICDUhukrjysICANiOsPjDgICgIBQG6Y5PL4gIEC/TGMhINiAAAICDC/T WAgINiyAgFAbpq+wHiAgAAgItWH6yuMNAsKAmLbA+oCAACAg1IbpDI87CAgwaKaxEBBsKAABAYaX aSwEBBsQQEAYXqavsH4gIAAICLVh+grrAQLCgJiewHqCgAAgINSGaQusDwgIMORMYyEg2CAAAgIM L9NYCAg2FICAMDRMX2G9QUAAEBBqw/QV1g8EhAExDYH1BwEBQECoDdMTWE8QEOCoMY0lIHjiAwgI MLxMYyEg2CAAAsKRMX2F9QkBAUBAqA3TV1hvEBAGxHQD1isEBAABoTZMQ2D9QUCAmjONJSB4ggMI CDC8TGMJCJ74AAJCz0xfYT1DQAAQEGrD9BXWJwSEATGtgPUNAQFAQKgN0w1YrxAQoG6ZxhIQPJEB BAQYXqaxBARPcAABGelMX2H9Q0AAEBBqw/QV1jMEhAExfYD1EAEBQECoDdMKWN8QEKDhmMYSEDxh AQQEGF6msQQET2QAARkpTF9hvURAABAQasP0FdY/BIQBMU2A9RMBAUBAqA3TB1gPERCgaZjGEhA8 MQEBARheprEEBE9YAAFpNqavsL4iIAAICLVh+grrJQKC6QCstwgIAAJCHTNNgPUTAQGanmksAcET EBAQgOFlGktA8MQEBIRGZfoK6zECAoCAUBumr7C+IiAY9mN9RkAAEBBMB4D1FgEB6o9pLAHBEw0Q EIDhZRpLQPAEBASEemf6Cus3AgKAgFAbpq+wHiMgGN6D9VxAABAQDPvB+oyAAI3DNJaA4AkFCAjA 8DKNJSB4ogECQr0wfYX1HgEBQECoDdNXWL8REAzjwfovIAAICIb3YD1HQIDGZxpLQPDEAQQEYHiZ xhIQPKEAAeFoM30Fng8CAoCAUBumr7DeIyAYroPnhYAAICAYxoP1HwEBmpdpLAHBEwQQEIDhZRpL QPDEAQSE4WL6CjxPBASApvf/5iHIqNxWR4QAAAAASUVORK5CYII= --047d7b5d2ea4d03e9704e6db27e0-- From peter@spectrumbridge.com Sat Sep 21 08:24:01 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11E1611E8170 for ; Sat, 21 Sep 2013 08:24:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.731 X-Spam-Level: X-Spam-Status: No, score=-1.731 tagged_above=-999 required=5 tests=[AWL=0.867, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qld3cfkH4fSt for ; Sat, 21 Sep 2013 08:23:56 -0700 (PDT) Received: from mail.spectrumbridge.com (mail.spectrumbridge.com [64.132.248.82]) by ietfa.amsl.com (Postfix) with ESMTP id 3FABC11E816E for ; Sat, 21 Sep 2013 08:23:39 -0700 (PDT) Received: from shelby.sbi.com ([127.0.0.1]) by shelby ([127.0.0.1]) with mapi; Sat, 21 Sep 2013 11:23:38 -0400 From: Peter Stanforth To: "Gabor.Bajko@nokia.com" Date: Sat, 21 Sep 2013 11:23:35 -0400 Thread-Topic: [paws] Spectrum encoding discussion Thread-Index: Ac623otXIq83x1AVSu6QnzkzefwdoA== Message-ID: References: <1ECAFF543A2FED4EA2BEB6CACE08E476053422B0@008-AM1MPN1-006.mgdnok.nokia.com> <1ECAFF543A2FED4EA2BEB6CACE08E47605342356@008-AM1MPN1-006.mgdnok.nokia.com> In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E47605342356@008-AM1MPN1-006.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C31A91B2C81F417AA1D982067EDF2B5Bspectrumbridgecom_" MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] Spectrum encoding discussion X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Sep 2013 15:24:01 -0000 --_000_C31A91B2C81F417AA1D982067EDF2B5Bspectrumbridgecom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 R2Fib3IgaW4gcHJpbmNpcGxlIEkgdGhpbmsgeW91IGFuZCBBbmR5IGFyZSBib3RoIHJpZ2h0LiBJ dCB3YXMgY2FsbGVkIFBBV1MgYmVjYXVzZSBpdCB3YXMgc3VwcG9zZWQgdG8gYmUgYWJsZSB0byBj b3ZlciBtb3JlIHRoYW4gVFZXUy4gQnV0IHdoZW4gd2Ugd3JvdGUgdGhlIGNoYXJ0ZXIgd2Ugb25s eSBoYWQgdGhlIEZDQyBhcyBhIGd1aWRlLiBNeSBwcmVmZXJlbmNlIGlzIHRvIHN0YXkgd2l0aGlu IHRoZSBjaGFydGVyIGFuZCBhY2NlcHQgdGhhdCB0aGVyZSB3aWxsIGJlIGZ1dHVyZSB2ZXJzaW9u cyBvZiBhIHRoZSBzcGVjIGFzIG5ldyBzcGVjdHJ1bSBiYW5kcyBvcGVuIHVwDQoNCk9uIFNlcCAy MCwgMjAxMywgYXQgOTozMiBQTSwgIkdhYm9yLkJhamtvQG5va2lhLmNvbTxtYWlsdG86R2Fib3Iu QmFqa29Abm9raWEuY29tPiIgPEdhYm9yLkJhamtvQG5va2lhLmNvbTxtYWlsdG86R2Fib3IuQmFq a29Abm9raWEuY29tPj4gd3JvdGU6DQoNCg0KRmV3IHRoaW5ncyB0byBjb25zaWRlcjoNCg0KDQoN CjEuICAgICAgIEkgdGhpbmsgd2UgZmlyc3QgaGF2ZSB0byBhZ3JlZSB3aGV0aGVyIHdlIG5lZWQg YXQgYWxsIHRvIGVuY29kZSBhbiDigJh1bmF2YWlsYWJsZSBjaGFubmVs4oCZLiBDdXJyZW50IGRy YWZ0IHNlY3Rpb24gNC40LjIgc2F5czog4oCcVGhlIHJlc3BvbnNlIG1lc3NhZ2UgZm9yIHRoZSBB dmFpbGFibGUgU3BlY3RydW0gUXVlcnkgY29udGFpbnMgYQ0KICAgc2NoZWR1bGUgb2YgYXZhaWxh YmxlIHNwZWN0cnVtIGZvciB0aGUgRGV2aWNlLuKAnSBUbyBtZSB0aGlzIG1lYW5zIHRoYXQgY2hh bm5lbHMgd2hpY2ggYXJlIG5vdCBsaXN0ZWQgYXJlIGltcGxpY2l0bHkgdW5hdmFpbGFibGUgYW5k IGxlYWthZ2UgaW50byB1bmF2YWlsYWJsZSBzcGVjdHJ1bSBoYXMgdG8gY29uZm9ybSB0byB0aGUg cnVsZXMuDQoNCg0KMi4gICAgICAgSWYgb25lIHdhbnRzIHRvIGJlIGV4cGxpY2l0IG9uIHdoYXQg dGhlIHJ1bGVzIHNheSBmb3IgdGhlIGxlYWthZ2UgbGltaXRzLCB0aGVuIHdlIGNhbiBlbmNvZGUg dGhvc2UgaW50byB0aGUgcnVsZXNldEluZm8uDQoNCg0KMy4gICAgICAgSWYgd2UgdGFrZSBvbiBB bmR54oCZcyBhcmd1bWVudCB0aGF0IFBBV1MgY291bGQgYmUgdXNlZCBvdXRzaWRlIFRWV1MsICph bmQqIGxlYWthZ2UgbGltaXRzIG1heSBwb3RlbnRpYWxseSBiZSBkaWZmZXJlbnQgZm9yIGRpZmZl cmVudCBiYW5kcyB3aXRoaW4gdGhlIHNhbWUgcmVndWxhdG9yeSBkb21haW4sIHRoZW4gZW5jb2Rp bmcgYWxsIHRob3NlIGJhbmRzIGFuZCBsZWFrYWdlIGxpbWl0cyBpbnRvIHJ1bGVzZXRJbmZvIG1p Z2h0IGp1c3QgY29tcGxlbWVudCB3aGF0IGlzIG1pc3NpbmcgZnJvbSB0aGUgYXZhaWxhYmxlIHNw ZWN0cnVtIHJlc3BvbnNlIGFuZCB3ZSBtYXkgYmUgYmV0dGVyIG9mZiBqdXN0IGVuY29kaW5nIGV2 ZXJ5dGhpbmcgaW50byBhdmFpbGFibGUgc3BlY3RydW0gcmVzcG9uc2UuDQoNCjEgYW5kIDIgZG9l c27igJl0IHJlcXVpcmUgYW4gZW5jb2RpbmcgZm9yIHVuYXZhaWxhYmxlIGNoYW5uZWwuIFNpbXBs eSBub3QgbGlzdGluZyBpdCBhcyBhdmFpbGFibGUgZG9lcyB0aGUgam9iLg0KMyB3b3VsZCByZXF1 aXJlIHVzIHRvIGFncmVlIGhvdyB0byBlbmNvZGUgdW5hdmFpbGFibGUgY2hhbm5lbCwgYnV0IHRo ZSBXU0Qgd291bGQgc3RpbGwgbmVlZCB0byBrbm93IHdoYXQgdGhlIGVtaXNzaW9uIGxpbWl0cyBh cmUgaW4gdGhhdCByZWd1bGF0b3J5IGRvbWFpbiBmb3IgdGhlIHVuYXZhaWxhYmxlIGNoYW5uZWxz Lg0KDQoNCi0gICAgICAgICAgZ2Fib3INCg0KRnJvbTogcGF3cy1ib3VuY2VzQGlldGYub3JnPG1h aWx0bzpwYXdzLWJvdW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86cGF3cy1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgZXh0IEhhcmFzdHksIERhbmllbCBKDQpTZW50OiBGcmlkYXksIFNlcHRl bWJlciAyMCwgMjAxMyA1OjE1IFBNDQpUbzogcGF3c0BpZXRmLm9yZzxtYWlsdG86cGF3c0BpZXRm Lm9yZz4NClN1YmplY3Q6IFJlOiBbcGF3c10gU3BlY3RydW0gZW5jb2RpbmcgZGlzY3Vzc2lvbg0K DQpBbGw6DQoNCkkga25vdyB0aGlzIGlzIGEgbG9uZyB3aW5kZWQgcmVwbHkgdG8gYW4gYWxyZWFk eSBsYWJvcmlvdXMgY29udmVyc2F0aW9uLiAgQnV0IEkgdGhpbmsgSSBjYW4gcHV0IGEgZmluZ2Vy IG9uIHRoZSBlc3NlbnRpYWwg4oCcZGlzYWdyZWVtZW504oCdLCBhbmQgZXZlbiBvZmZlciBhIGNv bXByb21pc2UgdGhhdCB3aWxsIGFsbG93IHVzIHRvIG1vdmUgZm9yd2FyZC4NCg0KSGludDogdGhl IHdob2xlIOKAnG9wdGlvbiAx4oCdL+KAnW9wdGlvbiAy4oCdIGRlYmF0ZSBpcyBhIGJpdCBvZiBh IG1pc2RpcmVjdGlvbiwgYXMgdGhvc2UgdHdvIG9wdGlvbnMgZGlkIE5PVCBjYXB0dXJlIHRoZSB0 d28gc2lkZXMgb2YgdGhlIGVzc2VudGlhbCBkaXNhZ3JlZW1lbnQ7IHRoZSBpc3N1ZSBhdCBoYW5k IGlzIHJlYWxseSBhYm91dCDigJxpcyBhbiBvdXQtb2YtYmFuZCBlbWlzc2lvbiBsaW1pdCBhIGdv b2Qgd2F5IHRvIGV4cHJlc3MgdGhhdCBhIGNoYW5uZWwgaXMgdW5hdmFpbGFibGU/4oCdDQoNClRo ZXJlIHNlZW1zIHRvIGJlIHRoZSBjYW1wIHRoYXQg4oCcb3V0IG9mIGJhbmQgZW1pc3Npb24gbGlt aXRz4oCdIGFyZSB0aGUgU0FNRSBhcyDigJxjaGFubmVsIHVuYXZhaWxhYmxl4oCdLiAgSW4gbXkg cmVhZGluZyBvZiB0aGUgRkNDIHJ1bGVzLCB0aGF0IGlzIHNpbXBseSBub3QgdGhlIGNhc2UuICBU aGVyZSBhcmUgdGltZXMgd2hlbiBGQ0MgcnVsZXMgcmVxdWlyZSBtZSAoYXMgYSBEYXRhYmFzZSkg dG8gc2F5IOKAnHRoaXMgY2hhbm5lbCBpcyB1bmF2YWlsYWJsZeKAnSBvdGhlciB0aGFuIOKAnGEg cHJvdGVjdGVkIGVudGl0eSBvY2N1cGllcyB0aGlzIGNoYW5uZWzigJ0uICBGb3IgZXhhbXBsZToN Cg0KDQrCtyAgICAgICAgIEl0IGlzIGEgY2hhbm5lbCBjYXRlZ29yaWNhbGx5IGV4Y2x1ZGVkIGZy b20gdGhlIFdoaXRlc3BhY2Ugc3BlY3RydW0gKGUuZy4gVVMgQ2hhbm5lbCAzIG9yIENoYW5uZWwg MzcpLg0KDQrCtyAgICAgICAgIFRoZXJlIGlzIGFuIGFkLWhvYyAoRkNDIHByb3ZpZGVkKSBwb2x5 Z29uIGVzdGFibGlzaGluZyBhbiBhZC1ob2MgZXhjbHVzaW9uIHpvbmUuDQoNCsK3ICAgICAgICAg QSBkZXZpY2UgaXMgYmxhY2tsaXN0ZWQuDQoNClRvIHNheSB0aGF0IOKAnENoYW5uZWwgMzcgaXMg YXZhaWxhYmxlIGF0IC0zNi44IGRCbeKAnSBpcyBqdXN0IG5vdCB0aGUgc2FtZSBhcyDigJxDaGFu bmVsIDM3IGlzIHVuYXZhaWxhYmxl4oCdLCBJTU8uDQoNClRvIHRlbGwgYWxsIGRldmljZXMgaW4g YW4gYWQtaG9jIGV4Y2x1c2lvbiB6b25lIHRoYXQg4oCcYWxsIGNoYW5uZWxzIGFyZSBhdmFpbGFi bGUgYXQgLTM2LjggZEJt4oCdIGlzIGp1c3Qgbm90IHRoZSBzYW1lIGFzIOKAnGFsbCBjaGFubmVs cyBhcmUgdW5hdmFpbGFibGXigJ0uDQoNClRvIHRlbGwgYSBibGFja2xpc3RlZCBkZXZpY2UgdGhh dCDigJxhbGwgY2hhbm5lbHMgYXJlIGF2YWlsYWJsZSBhdCAtMzYuOCBkQm3igJ0gaXMganVzdCBu b3QgdGhlIHNhbWUgYXMg4oCcYWxsIGNoYW5uZWxzIGFyZSB1bmF2YWlsYWJsZeKAnS4NCg0KSW4g b3RoZXIgd29yZHM6IElmIFBBV1MgZG9lcyBub3QgZ2l2ZSBtZSBhIHdheSB0byBzYXkgYSBjaGFu bmVsIGlzIHVuZXF1aXZvY2FsbHkg4oCcdW5hdmFpbGFibGXigJ0sIHRoZW4sIGluIG15IG9waW5p b24gYXMgYSBEYXRhYmFzZSBwcm92aWRlciwgaXQgaXMgbm90IHN1ZmZpY2llbnRseSBleHByZXNz aXZlIGZvciBtZSB0byBtZWV0IHRoZSBGQ0MgcnVsZXMuDQoNCklmIHdlIERPIHVzZSBQQVdTIHRv IGVuY29kZSBvdXQtb2YtYmFuZCBlbWlzc2lvbnMgbGltaXRzLCBJIGhhdmUgdG8gc2F5LCBJIHRo aW5rIGl0IGlzIGZhcmZldGNoZWQgdGhhdCBhIGRldmljZSBpbXBsZW1lbnRlZCB0b2RheSB0byB0 b2RheeKAmXMgcnVsZXMgd2lsbCBiZSBhYmxlIHRvIOKAkyBpbiB0aGUgZnV0dXJlIOKAkyBlaXRo ZXIg4oCcdGFrZSBhZHZhbnRhZ2XigJ0gb2YgYSBsZXNzIHN0cmluZ2VudCDigJxvdXQtb2YtYmFu ZCBtYXNr4oCdIG9yIGNvbXBseSB0byBhIG1vcmUgc3RyaW5nZW50IG1hc2suICBBcyBtYXJ2ZWxv dXMgYXMgU0RScyBhcmUvY2FuIGJlLCB0aGF0IGRlZ3JlZSBvZiBmbGV4aWJpbGl0eSBpcyBqdXN0 IG5vdCBjb21tb24gaW4gY29uc3VtZXItZ3JhZGUgbWFzcyBtYXJrZXQgZGV2aWNlcyBvd2luZyB0 byBjb3N0LiAgVGhhdCBsZWFkcyBtZSB0byB0aGUgY29uY2x1c2lvbiB0aGF0IGV4cGVjdGluZyB0 byB1c2UgUEFXUyB0aGF0IHdheSBpcyBqdXN0IG5vdCBnb2luZyB0byBiZSB0aGF0IHVzZWZ1bC4N Cg0KSG93ZXZlciwgSSByZWFsaXplIHdlIG1heSBkaWZmZXIgb24gdGhpcyBwb2ludC4gIEJ1dCB0 aGUgbm90aW9uIG9mIOKAnFBBV1MgYXZhaWxhYmxlLXNwZWN0cnVtIHJlcGxpZXMgc2hvdWxkIGVu Y29kZSBvdXQtb2YtYmFuZCBlbWlzc2lvbnMgbGltaXRz4oCdIGlzIGp1c3QgYSBzZXBhcmF0ZSBu b3Rpb24gZnJvbSDigJxQQVdTIG11c3QgYWxsb3cgYSB3YXkgdG8gZW5jb2RlIOKAmGNoYW5uZWwg dW5hdmFpbGFibGXigJnigJ0uICBJdCBpcyBjb25mb3VuZGluZyB0aG9zZSB0d28gY29uY2VwdHMg dGhhdCDigJMgSU1PIOKAkyBoYXMgbGVhZCB0byB0aGUgY3VycmVudCDigJxkaXNhZ3JlZW1lbnTi gJ0uDQoNCk9LLCB0aW1lIGZvciBteSBwcm9wb3NlZCBncmFuZCBjb21wcm9taXNlOg0KDQoNCsK3 ICAgICAgICAgTGV04oCZcyBkZWZpbmUgYSB3YXkgdG8gdW5lcXVpdm9jYWxseSBlbmNvZGUg4oCc Y2hhbm5lbCB1bmF2YWlsYWJsZeKAnSB0aGF0IGlzIE5PVCBzeW5vbnltb3VzIHdpdGgg4oCcb3V0 IG9mIGJhbmQgZW1pc3Npb25zIGxpbWl0c+KAnS4gIEkgbmVlZCBpdCBhcyBhIERhdGFiYXNlIHBy b3ZpZGVyLiAgKEFnYWluOiBJIG9mZmVyIHRvIHJlY2FwIHNldmVyYWwgZGlmZmVyZW50IHdheXMg dG8gZG8gdGhpcyBsYXRlci4pDQoNCg0KwrcgICAgICAgICBPbmNlIHdlIGhhdmUgYSB3YXkgdG8g dW5lcXVpdm9jYWxseSBlbmNvZGUg4oCcY2hhbm5lbCB1bmF2YWlsYWJsZeKAnSwgd2UgY2FuIGhh dmUgYSBzZXBhcmF0ZSBkaXNjdXNzaW9uIGFzIHRvIHdoZXRoZXIgb3Igbm90IGl0IGlzIGV2ZXIg dXNlZC4gIFBlcmhhcHMgZGlmZmVyZW50IERhdGFiYXNlcyB3aWxsIGludGVycHJldCB0aGVpciBs ZWdhbC9yZWd1bGF0b3J5IG9ibGlnYXRpb25zIGRpZmZlcmVudGx5LiAgT3IgZXZlbiwgYSBnaXZl biBEYXRhYmFzZSBtYXkgdXNlIOKAnC0zNi44IGRCbeKAnSBpbiBzb21lIGNhc2VzIGFuZCDigJxj aGFubmVsIHVuYXZhaWxhYmxl4oCdIGluIG90aGVycy4NCg0KVGhlIHB1cnBvc2Ugb2YgdGhpcyBX RyBpcyB0byBwcm9kdWNlIGEgcHJvdG9jb2wgdGhhdDoNCg0KDQoxLiAgICAgICBQcm92aWRlcyBm b3IgaW50ZXJvcGVyYWJpbGl0eSAoYmVjYXVzZSBpdCBpcyBzdWZmaWNpZW50bHkgY2xlYXIpLg0K DQoNCjIuICAgICAgIEFsbG93cyBhbGwgcGFydGllcyB0byBtZWV0IHRoZWlyIGxlZ2FsL3JlZ3Vs YXRvcnkgb2JsaWdhdGlvbnMgYXMgdGhleSBpbnRlcnByZXQgdGhlbS4NCg0KSSBmZWVsIHRoZSBh Ym92ZSBwcm9wb3NlZCBjb21wcm9taXNlIGFjY29tcGxpc2hlcyBib3RoLg0KDQoNCkRhbiBIYXJh c3R5DQoNCg0KDQpGcm9tOiBwYXdzLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnBhd3MtYm91bmNl c0BpZXRmLm9yZz4gW21haWx0bzpwYXdzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBB bmR5IExlZQ0KU2VudDogRnJpZGF5LCBTZXB0ZW1iZXIgMjAsIDIwMTMgNzoxMiBQTQ0KVG86IFBl dGVyIFN0YW5mb3J0aA0KQ2M6IHBhd3NAaWV0Zi5vcmc8bWFpbHRvOnBhd3NAaWV0Zi5vcmc+DQpT dWJqZWN0OiBSZTogW3Bhd3NdIFNwZWN0cnVtIGVuY29kaW5nIGRpc2N1c3Npb24NCg0KSSB3YXMg YWN0dWFsbHkgaG9waW5nIHRvIHNpbXBsaWZ5IHRoaW5ncyBmb3IgZGV2aWNlcy4NCg0KMSkgSGF2 aW5nIGEgZnVsbHkgc3BlY2lmaWVkIHNwZWN0cnVtIHByb2ZpbGUgd2l0aG91dCBkaXNjb250aW51 aXRpZXMgYW5kIHdpdGhvdXQgInNwZWNpYWwiIHZhbHVlcyBsaWtlIC1pbmYgbWFrZSBpdCBtdWNo IGVhc2llciB0byB3cml0ZSB0aGUgY2xpZW50IHNpZGUgY29kZS4gIFRoaXMgbWluaW1pemVzIHRo ZSBudW1iZXIgb2Ygc3BlY2lhbCBlZGdlIGNhc2VzIHRoYXQgbmVlZCB0byBiZSBoYW5kbGVkIGJ5 IHRoZSBwYXJzaW5nIGxvZ2ljIGFuZCAiZW1pc3Npb24gZml0dGluZyIgY29kZSBvbiB0aGUgY2xp ZW50Lg0KDQoyKSBXZSBzdGlsbCBzZWVtIHRvIGJlIHRoaW5raW5nIGluIHRlcm1zIG9mIFRWIGNo YW5uZWxzIG9ubHkuICBQQVdTIGlzIGRlc2lnbmVkIGZvciBvdGhlciBmcmVxdWVuY3kgYmFuZHMg dG9vLCBhbmQgdGhlcmUgd29uJ3QgYWx3YXlzIGJlIHN1Y2ggYSBkaXN0aW5jdCBjb25jZXB0IG9m IG9uLWNoYW5uZWwgdnMuIGFkamFjZW50LWNoYW5uZWwgZW1pc3Npb25zLg0KDQozKSBXZSBkb24n dCBrbm93IHdoYXQgZnV0dXJlIFdTRCB0ZWNobm9sb2dpZXMgd2lsbCBiZSBjYXBhYmxlIG9mLiAg V2ktRmkgYWxyZWFkeSBzdXBwb3J0cyBhIGxvbmcgbGlzdCBvZiBtb2R1bGF0aW9uIHR5cGVzIChl LmcuLCBCUFNLLCBRUFNLLCBEU1NTLCBGSFNTLCBPRkRNKSBhbmQgY2hhbm5lbCB3aWR0aHMuICBT b2Z0d2FyZSBkZWZpbmVkIHJhZGlvcyBhbmQgb3RoZXIgdGVjaG5vbG9naWVzIGNhbiBkeW5hbWlj YWxseSBjaG9vc2UgbW9kdWxhdGlvbiB0eXBlcywgY2hhbm5lbCB3aWR0aHMsIGFuZCBwb3dlciBk aXN0cmlidXRpb24uICBUaGVzZSBhZ2lsZSByYWRpbyB0ZWNobm9sb2dpZXMgbmVlZCB0aGUgZnVs bCBzcGVjdHJ1bSBwcm9maWxlIHRvIGhlbHAgdGhlbSBjaG9vc2UgdGhlIHJpZ2h0IGNvbWJpbmF0 aW9uIG9mIGVtaXNzaW9uIHBhcmFtZXRlcnMuICBXU0RzIGFyZSBqdXN0IGEgImJsYWNrIGJveCIg ZnJvbSB0aGUgZGF0YWJhc2UncyBwb2ludCBvZiB2aWV3Lg0KDQoNCg0KQW5keSBMZWUgfA0KDQog R29vZ2xlIEluYy4gfA0KDQogdHZmb29sQGdvb2dsZS5jb208bWFpbHRvOnR2Zm9vbEBnb29nbGUu Y29tPiB8DQoNCiA0MDgtMjMwLTA1MjINCg0KDQpPbiBGcmksIFNlcCAyMCwgMjAxMyBhdCAyOjM1 IFBNLCBQZXRlciBTdGFuZm9ydGggPHBldGVyQHNwZWN0cnVtYnJpZGdlLmNvbTxtYWlsdG86cGV0 ZXJAc3BlY3RydW1icmlkZ2UuY29tPj4gd3JvdGU6DQpXZSBoYXZlLCB1bnRpbCBrbm93LCBhbHdh eXMgd29ya2VkIG9uIHRoZSBhc3N1bXB0aW9uIHRoYXQgdGhlIGRldmljZSB3b3VsZCBiZSBjZXJ0 aWZpZWQsIG9yIG5vdCwgdG8gY29tcGx5IHdpdGggYW55IG91dCBvZiBiYW5kIGVtaXNzaW9ucy4g VGhlIEZDQyBmb3IgaW5zdGFuY2Ugc3BlY2lmaWNhbGx5IHRlc3RzIHRoZSBtb3JlIHN0cmluZ2Vu dCBydWxlIGFyb3VuZCBjaGFubmVsIDM3LCBhcyB3ZWxsIGFzIHRoZSBtb3JlIGdlbmVyYWwgY2Fz ZS4gVGhlIERhdGFiYXNlIGlzIG5vdCwgYW5kIGNhbm5vdCBiZSwgdGhlIGVuZm9yY2VtZW50IGFn ZW5jeS4gU28gc2ltcGx5IHByb3ZpZGluZyBhIGxpc3Qgb2YgY2hhbm5lbHMgdGhhdCBpdCBjYW4g dXNlIGlzIHN1ZmZpY2llbnQuDQpJdCBzaG91bGQgYmUgb2Ygbm8gY29uc2VxdWVuY2UgdG8gYSBk ZXZpY2Ugd2h5IGl0IGNhbm5vdCB1c2UgYSBjaGFubmVsIG90aGVyIHRoYW4gdG8gYmVoYXZlIHdp dGggaXRzIGNvbXBsaWFudCBlbWlzc2lvbnMuDQpJIGFncmVlIHdpdGggR2Fib3IsIHdoeSBhcmUg d2Ugb3Zlcmx5IGNvbXBsaWNhdGluZyB0aGlzPw0KDQpGcm9tOiAiR2Fib3IuQmFqa29Abm9raWEu Y29tPG1haWx0bzpHYWJvci5CYWprb0Bub2tpYS5jb20+IiA8R2Fib3IuQmFqa29Abm9raWEuY29t PG1haWx0bzpHYWJvci5CYWprb0Bub2tpYS5jb20+Pg0KRGF0ZTogRnJpZGF5LCBTZXB0ZW1iZXIg MjAsIDIwMTMgNDo1NCBQTQ0KVG86ICJ0dmZvb2xAZ29vZ2xlLmNvbTxtYWlsdG86dHZmb29sQGdv b2dsZS5jb20+IiA8dHZmb29sQGdvb2dsZS5jb208bWFpbHRvOnR2Zm9vbEBnb29nbGUuY29tPj4s ICJiZW5AYmxpbmRjcmVlay5jb208bWFpbHRvOmJlbkBibGluZGNyZWVrLmNvbT4iIDxiZW5AYmxp bmRjcmVlay5jb208bWFpbHRvOmJlbkBibGluZGNyZWVrLmNvbT4+DQpDYzogInBhd3NAaWV0Zi5v cmc8bWFpbHRvOnBhd3NAaWV0Zi5vcmc+IiA8cGF3c0BpZXRmLm9yZzxtYWlsdG86cGF3c0BpZXRm Lm9yZz4+DQoNClN1YmplY3Q6IFJlOiBbcGF3c10gU3BlY3RydW0gZW5jb2RpbmcgZGlzY3Vzc2lv bg0KDQpBcmVu4oCZdCB3ZSB0YWxraW5nIHBhc3QgZWFjaCBvdGhlciBpbiB0aGlzIHRocmVhZD8N CklmIHRoZSBydWxlcyBhcmUgc3VwcG9zZWQgdG8gc3BlY2lmeSB3aGF0IGlzIHRoZSBtYXggaW50 ZW5kZWQgcG93ZXIgbGV2ZWwgYSBkZXZpY2UgY2FuIHB1dCBpbnRvIGEgY2hhbm5lbCAoYXZhaWxh YmxlIG9yIG5vdCksIHRoZW4gSSBhbHNvIHRoaW5rIHRoaXMgaXMgd2hhdCB0aGUgREIgc2hvdWxk IGNvbW11bmljYXRlIHRvIHRoZSBkZXZpY2UuDQpJZiBPZmNvbSBzcGVjaWZpZXMgdGhhdCB0aGUg bWF4IGxlYWthZ2UgaW50byBhbiB1bmF2YWlsYWJsZSBjaGFubmVsIGlzIC0zM2RibSwgSSBhc3N1 bWUgdGhlIGRldmljZSB3aWxsIG5vdCBiZSBjZXJ0aWZpZWQgaWYgaXQgbGVha3MgbW9yZS4gSWYg dGhlIGRldmljZSBzdXBwb3J0cyBtdWx0aXBsZSBtb2R1bGF0aW9uIHR5cGVzIGFuZCBvbmUgb2Yg dGhlbSBsZWFrcyBtb3JlIHRoYW4gd2hhdCBpcyBwZXJtaXR0ZWQgaW4gdGhhdCByZWd1bGF0b3J5 IGRvbWFpbiwgdGhlbiB0aGUgZGV2aWNlIHdpbGwgbmVlZCB0byBrbm93IGl0LCBhbmQgaW4gdGhh dCByZWd1bGF0b3J5IGRvbWFpbiBhdm9pZCB1c2luZyB0aGF0IHBhcnRpY3VsYXIgbW9kdWxhdGlv biB0eXBlLiBIb3cgZG9lcyB0aGUgZGV2aWNlIGNvbWUgdG8ga25vdyBpdD8gQW5keSBwcm9wb3Nl cyB0aGUgREIgdG8gaW5kaWNhdGUgdGhhdCBsZXZlbCBmb3IgdGhlIHVuYXZhaWxhYmxlIGNoYW5u ZWxzLiBPdGhlcnMgZm9sa3Mgc2VlbSB0byBzdWdnZXN0IGEgZGV2aWNlIGJ1aWx0IHRvIG9wZXJh dGUgdW5kZXIgYSBjZXJ0YWluIHJ1bGVzZXQgaGFzIHRvIGltcGxpY2l0bHkga25vdyBpdC4NCkFu b3RoZXIgd2F5IG9mIGxvb2tpbmcgYXQgaXQgbWlnaHQgYmUgdG8gc2F5IHRoYXQgdGhlIG1heCBs ZXZlbCBvZiBwZXJtaXR0ZWQgdW5pbnRlbnRpb25hbCBsZWFrYWdlIGludG8gYW4gYWRqYWNlbnQg Y2hhbm5lbCBpcyBwYXJ0IG9mIHRoZSBydWxlc2V0SW5mbywgYW5kIHRoZSBzcGVjdHJ1bSByZXNw b25zZSBvbmx5IGxpc3RzIHRoZSBhdmFpbGFibGUgY2hhbm5lbHMuIENvdWxkIHRoaXMgYmUgYSB3 YXkgZm9yd2FyZD8NCg0KLSAgICAgICAgICBnYWJvcg0KDQpGcm9tOiBwYXdzLWJvdW5jZXNAaWV0 Zi5vcmc8bWFpbHRvOnBhd3MtYm91bmNlc0BpZXRmLm9yZz4gW21haWx0bzpwYXdzLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBleHQgQW5keSBMZWUNClNlbnQ6IEZyaWRheSwgU2VwdGVt YmVyIDIwLCAyMDEzIDE6MDAgUE0NClRvOiBCZW5qYW1pbiBBLiBSb2xmZQ0KQ2M6IFByb3RvY29s IHRvIEFjY2VzcyBXaGl0ZSBTcGFjZSBkYXRhYmFzZQ0KU3ViamVjdDogUmU6IFtwYXdzXSBTcGVj dHJ1bSBlbmNvZGluZyBkaXNjdXNzaW9uDQoNCkhpIEJlbiwNCg0KQW5kIHRoYXQgbWVhbnMgTk8g aW50ZW50aW9uYWwgcmFkaWF0aW9uIGluIHRoZSBjaGFubmVsLg0KDQpJZiB5b3UgYXJlIHJlYWRp bmcgdGhpcyBhcyAidHJhbnNtaXR0ZWQgZW1pc3Npb25zIGluIGJhbmQgc2hvdWxkIGJlIGxvd2Vy IHRoYW4gLTMzZEJtIiB0aGVuLCBubywgdGhpcyBpcyBub3QgdGhlIHNhbWUgYXMgIm5vIGVtaXNz aW9ucyIgcGVyIEZDQyBydWxlcy4gSWYgb25lIHdlcmUgdG8gaW50ZW50aW9uYWxseSB0cmFuc21p dCBhdCAtMzNkQm0gd2hlcmUgbm8gaW50ZW50aW9uYWwgZW1pc3Npb25zIGFyZSBhbGxvd2VkLCB0 aGF0IHdvdWxkIG5vdCBiZSB0aGUgc2FtZSBhcyAibm8iIHVuZGVyIHRoZSBydWxlcy4NCg0KVGhl cmUgaXMgY2VydGFpbmx5IG5vIGludGVudGlvbiB0byBlbmNvdXJhZ2UgYW55IG1hbGljaW91cyBi ZWhhdmlvci4gIEluIGdlbmVyYWwsIHdlIGV4cGVjdCBkZXZpY2VzIHRvIGJlIHRyeWluZyB0byBk byB0aGUgcmlnaHQgdGhpbmcgYW5kIGp1c3QgbmVlZCBzb21lIGluZm9ybWF0aW9uIHRvIHVuZGVy c3RhbmQgd2hlcmUgdGhlIGJvdW5kYXJpZXMgYXJlLiAgVGhlc2UgYm91bmRhcmllcyBpbmNsdWRl IGJvdGggaW50ZW50aW9uYWwgYW5kIHVuaW50ZW50aW9uYWwgZW1pc3Npb25zLg0KDQpWYXJpb3Vz IG1vZHVsYXRpb24gdHlwZXMgaGF2ZSBrbm93biBzcGVjdHJhbCBwcm9maWxlcywgaW5jbHVkaW5n IGJvdGggaW4tYmFuZCBhbmQgb3V0LW9mLWJhbmQgZW1pc3Npb25zLiAgS25vd2luZyB3aGVyZSB0 aGUgInNoZWxmIiBpcyBvbiB0aGUgYWRqYWNlbnQgY2hhbm5lbCBtYWtlcyBpdCBwb3NzaWJsZSB0 byBtYXRjaCB0aGF0IHdpdGggdGhlICJza2lydCIgb2YgdGhlIGludGVuZGVkIG1vZHVsYXRpb24g cGF0dGVybi4gIFRoZSAic2tpcnQiIGlzIG5vdCBwYXJ0IG9mIHRoZSBpbnRlbmRlZCBlbWlzc2lv biwgYnV0IGlzIGltcG9ydGFudCBpbiB0cnlpbmcgdG8gYXZvaWQgY2F1c2luZyBpbnRlcmZlcmVu Y2Ugb24gYWRqYWNlbnQgY2hhbm5lbHMuDQoNCkEgY3J1ZGUgZXhhbXBsZSBvZiB0aGlzIGlzIHNo b3duIGluIHRoZSBmb2xsb3dpbmcgaW1hZ2U6DQoNCjxpbWFnZTAwMS5wbmc+DQoNCkJlc3QgcmVn YXJkcywNCg0KDQpBbmR5IExlZSB8DQoNCiBHb29nbGUgSW5jLiB8DQoNCiB0dmZvb2xAZ29vZ2xl LmNvbTxtYWlsdG86dHZmb29sQGdvb2dsZS5jb20+IHwNCg0KIDQwOC0yMzAtMDUyMjx0ZWw6NDA4 LTIzMC0wNTIyPg0KDQoNCk9uIEZyaSwgU2VwIDIwLCAyMDEzIGF0IDM6MDcgQU0sIEJlbmphbWlu IEEuIFJvbGZlIDxiZW5AYmxpbmRjcmVlay5jb208bWFpbHRvOmJlbkBibGluZGNyZWVrLmNvbT4+ IHdyb3RlOg0KDQpPbiA5LzE5LzIwMTMgOTowOSBBTSwgQW5keSBMZWUgd3JvdGU6DQpUaGUgbWF0 aCBiZWFycyB0aGF0IG91dCwgYnV0IG5vbmV0aGVsZXNzIE9GQ09NIGFyZSBzdGlsbCBlZmZlY3Rp dmVseSBwcm9wb3NpbmcgdGhhdCAqbm8qIGluLWJsb2NrIHRyYW5zbWlzc2lvbnMgYXJlIGFsbG93 ZWQgaW4gdGhhdCBjaGFubmVsLg0KDQpTYW1lIGlzIHRydWUgZm9yIHRoZSBGQ0MuICBUaGUgRkND IGFsc28gYXNzdW1lcyB0aGF0ICJvZmYiIGNoYW5uZWxzIGFyZSBub3QgdXNlZCBieSBXU0RzLg0K QW5kIHRoYXQgbWVhbnMgTk8gaW50ZW50aW9uYWwgcmFkaWF0aW9uIGluIHRoZSBjaGFubmVsLg0K DQpTcGVjaWZ5aW5nIGEgbG93IHBvd2VyIGxldmVsIGxpa2UgLTMzIGRCbSBpcyBlZmZlY3RpdmVs eSB0aGUgc2FtZSB0aGluZyBhcyBzcGVjaWZ5aW5nIG5vIGluLWJhbmQgZW1pc3Npb25zIHRoZXJl Lg0KDQpJZiB5b3UgYXJlIHJlYWRpbmcgdGhpcyBhcyAidHJhbnNtaXR0ZWQgZW1pc3Npb25zIGlu IGJhbmQgc2hvdWxkIGJlIGxvd2VyIHRoYW4gLTMzZEJtIiB0aGVuLCBubywgdGhpcyBpcyBub3Qg dGhlIHNhbWUgYXMgIm5vIGVtaXNzaW9ucyIgcGVyIEZDQyBydWxlcy4gSWYgb25lIHdlcmUgdG8g aW50ZW50aW9uYWxseSB0cmFuc21pdCBhdCAtMzNkQm0gd2hlcmUgbm8gaW50ZW50aW9uYWwgZW1p c3Npb25zIGFyZSBhbGxvd2VkLCB0aGF0IHdvdWxkIG5vdCBiZSB0aGUgc2FtZSBhcyAibm8iIHVu ZGVyIHRoZSBydWxlcy4NCg0KDQpFdmVuIGlmIHNvbWVvbmUgZGlkIHRyeSB0byBwdXQgYW4gaW4t YmFuZCBlbWlzc2lvbiB0aGVyZSAocmVnYXJkbGVzcyBvZiBob3cgaW1wcmFjdGljYWwgdGhhdCBh Y3R1YWxseSBpcyksIGl0IHdvdWxkIGJlIHRvbyBsb3cgdG8gY2F1c2UgaW50ZXJmZXJlbmNlIHRv IGFueW9uZSBhbmQgbm8gaGFybSBoYXMgYmVlbiBkb25lIHRvIHRoZSAiUkYgZW52aXJvbm1lbnQi Lg0KU2hvdWxkIGJlIGEgbGl0dGxlIGNhcmVmdWwgaGVyZSBmb3IgYSBjb3VwbGUgcmVhc29ucy4g IEkndmUgZGVzaWduZWQgYW5kIHNoaXBwZWQgY29tbXVuaWNhdGlvbiBzeXN0ZW1zIHRoYXQgb3Bl cmF0ZSBxdWl0ZSB3ZWxsIHdpdGggdHJhbnNtaXQgcG93ZXIgbGV2ZWxzIGludGVudGlvbmFsbHkg YmVsb3cgLTMzZEJtIGFuZCBkbyB2ZXJ5IHVzZWZ1bCB0aGluZ3MuIEl0J3MgcHJldHR5IGVhc3kg dG8gZGVzaWduIGEgcmVjZWl2ZSB3aXRoIHNlbnNpdGl2aXR5IGJldHRlciB0aGFuIC05NmRCbSwg c28gYW4gaW50ZW50aW9uYWwgcmFkaWF0b3IgYXQgLTMzZEJtIG5lYXIgYnkgd2lsbCBiZSBub3Rp Y2VkIC0gYXQgOTAwIE1IeiB5b3VyIDEwZEIgYWJvdmUgc2Vuc2l0aXZpdHkgYXQgMTBtIGFuZCBh dCA1NE1IeiB5b3UnZCBiZSAxMCBkQiBhYm92ZSBzZW5zaXRpdml0eSBhdCAxMDBtLCBwb3NzaWJs eS4gQW5kIHdoZW4gaXQgY29tZXMgdG8gcHJvdGVjdGluZyB0aGVpciBzcGVjdHJ1bSwgcGVvcGxl IGFsd2F5cyB1c2UgdGhlIGJlc3QgcHJvcGFnYXRpb24gbW9kZWwgdG8gY2FsY3VsYXRlIGludGVy ZmVuY2UgaW1wYWN0IG9uIHRoZW0gOi0pLiAgSSd2ZSBwcm9iYWJseSBtaXN1bmRlcnN0b29kIHNv bWV0aGluZyBiYWRseSwgYnV0IC0zM2RCbSBpcyBjZXJ0YWlubHkgZW5vdWdoIHBvd2VyIHRvIGJl IG5vdGljZWQuDQoNCkkgaGF2ZSB0cmllZCB0aGUgInRvbyBsb3cgdG8gYmUgbm90aWNlZCIgYXJn dW1lbnQgYSBmZXcgdGltZXMgaW4gdGhlIHBhc3QgIGluIHJlZ3VsYXRvcnkgZGlzY3Vzc2lvbnMs IGFuZCBpbmN1bWJlbnQgYW5kL29yIHByb3RlY3RlZCB1c2VycyB1c3VhbGx5IHNldCB0aGUgdGhy ZXNob2xkIGNsb3NlciB0byAtMTIwZEJtIGFuZCB1c3VhbGx5IGFyZ3VlIHRoYXQgZXZlbiBhdCBy ZWFsbHkgbG93IFRYIHBvd2VyLCB0aGUgImFnZ3JlZ2F0ZSBpbXBhY3QiIG9mIG11bHRpcGxlIGRl dmljZXMgaW4gdGhlICJSRiBFbnZpcm9ubWVudCIgaXMgYW4gdW5hY2NlcHRhYmxlIGltcGFjdC4g ICBXZSBoYWQgdHJvdWJsZSB3aXRoIHRoaXMgYXJndW1lbnQgd2hlbiB0aGUgaW50ZW50aW9uYWwg cmFkaWF0b3IgVFggbGltaXQgd2FzIGJlbG93IHRoZSBtYXhpbXVtIHVuaW50ZW50aW9uYWwgZW1p c3Npb24gbGltaXRzIGZvciBtb3N0IG5vbi10cmFuc21pdHRpbmcgZGV2aWNlcyAoLTQxLjNkQm0p Lg0KDQpTbyBpdCB3b3VsZCBiZSBmYWlybHkgaW1wb3J0YW50IHRvIGVuc3VyZSBhIGRldmljZSBk b2VzIG5vdCBpbnRlcnByZXQgLTMzZEJtIGFzIGl0J3Mgb2sgdG8gdXNlIHRoYXQgY2hhbm5lbCBz byBsb25nIGFzIGl0J3MgVFggcG93ZXIgaXMgYmVsb3cgLTMzZEJtLg0KDQpJIG1heSBiZSBvZmYg YmFzZSBoZXJlIGJlY2F1c2Ugb2YgIGhvdyB5J2FsbCBzZWUgdGhlIERCIHByb3ZpZGluZyBhbmQg d2hhdCBJIGFtIGV4cGVjdGluZyB0byBzdXBwb3J0IGZ1dHVyZSBuZWVkcy4gInByb3RlY3RlZCB1 c2VycyIgaW5jbHVkZXMgbW9yZSB0aGFuIFRWIHN0YXRpb25zIGluIHRoZSBVUy4NCg0KTm90IHN1 cmUgdGhhdCBoZWxwcywgYnV0IGhvcGUgc28uDQoNCg0KVGhlIGFkdmFudGFnZSBvZiBoYXZpbmcg YW4gIndlbGwgYmVoYXZlZCIgc3BlY3RydW0gcHJvZmlsZSAoY29udGlndW91cyBhbmQgd2l0aG91 dCBzcGVjaWFsIHZhbHVlcyBsaWtlIC1pbmYpIGlzIHRoYXQgdGhlIGNoYW5uZWwgc2VsZWN0aW9u IGFsZ29yaXRobSBvbiB0aGUgV1NEcyBiZWNvbWVzIG11Y2ggc2ltcGxlciBhbmQgbG9naWNhbC4g IFRoZXJlJ3Mgbm8gbmVlZCB0byBoYXZlIGxvdHMgb2Ygc3BlY2lhbCBib3VuZGFyeSBjb25kaXRp b24gY2hlY2tzIGFuZCBjb2RlIHBhdGhzIHRoYXQgb25seSBnZXQgdHJpZ2dlcmVkIHVuZGVyIHNw ZWNpYWwgY2lyY3Vtc3RhbmNlcy4gIEknZCBsaWtlIHRvIGF2b2lkIGFtYmlndW91cyBpbnRlcnBy ZXRhdGlvbnMgb24gdGhlIGRldmljZSBzaWRlIGFzIG11Y2ggYXMgcG9zc2libGUuDQpDZXJ0YWlu bHkgYW1iaWd1b3VzIGludGVycHJldGF0aW9ucyBvbiB0aGUgZGV2aWNlIHNpZGUgYXJlIGEgYmFk IHRoaW5nLg0KDQpTb21lIGFwcHMgYXJlIGFnZ3JlZ2F0aW5nIG11bHRpcGxlIFRWIGNoYW5uZWxz IHRvIGdldCBhIGxvZ2ljYWwgY2hhbm5lbCB0aGF0IHRoYXQgY2FuIGNhcnJ5IGEgJ3dpZGUnICBk YXRhIHBpcGUuIE90aGVyIHVzZXMgY2FuIGZpdCBtYW55IHVzZWZ1bCBjaGFubmVscyBpbiBvbmUg VFYgY2hhbm5lbC4gSW4gODAyLjE1LjRtIHdlIGRpdmlkZSB0aGUgVFYgY2hhbm5lbCB1cCBpbnRv IG11bHRpcGxlIHBoeXNpY2FsIGNoYW5uZWxzIGNhcnJ5aW5nIGxvdyBkYXRhIHJhdGUgc2lnbmFs cy4gIFJpZ2h0IG5vdyB3ZSBhc3N1bWUgYSBwZWFrIHBvd2VyIGxldmVsIGZvciB0aGUgVFYgY2hh bm5lbCwgYW5kIHdlIGdldCB0aGF0IHZhbHVlIHdpdGggdGhlIHN0YXJ0IGZyZXF1ZW5jeSBhbmQg d2lkdGggKG9yIGVuZCBmcmVxdWVuY3kpIGZyb20gdGhlIGRhdGFiYXNlLiBIb3dldmVyLCBJJ3Zl IGhlYXJkIGl0IHByb3Bvc2VkIHRvIHRoZSBGQ0MgdGhhdCB3ZSBtYXkgZ2V0IGRpZmZlcmVudCBw b3dlciBsaW1pdHMgZGlmZmVyZW50IHBhcnRzIG9mIHRoZSBUViBjaGFubmVsLCBjaGFuZ2luZyBv dmVyIHRpbWUsIGFzIGEgcHJvdGVjdGlvbiBtZWNoYW5pc20gZm9yIGRlYWwgd2l0aCBuYXJyb3cg YmFuZCBwcm90ZWN0ZWQgdXNlcnMgd2hpbGUgYWxsb3dpbmcgZWZmZWN0aXZlIHVzZSBvZiB0aGUg cmVzdCBvZiB0aGUgVFYgY2hhbm5lbC4gIEZvciB3aGF0IHdlIGRvLCB0aGlzIGlzIGEgZ29vZCB0 aGluZyAtIG91ciBwaHlzaWNhbCBjaGFubmVsIG1heSBiZSBsZXNzIHRoYW4gMjAwa0h6IHdpZGUu IFRoZXJlIGFyZSBhIExPVCBvZiBhcHBsaWNhdGlvbnMgIGluIElvVCB0aGF0IG5lZWQgPCAyMDBr SHogY2hhbm5lbHMsICBhbmQgYmxvY2tpbmcgYW4gZW50aXJlIFRWIGNoYW5uZWwgdG8gcHJvdGVj dCBhIHdpcmVsZXNzIG1pY3JvcGhvbmUgdXNpbmcgPCAyMDBrSHogb2YgaXQgbWVhbnMgdGhlcmUg YXJlIDI4IG90aGVyIHVzYWJsZSBjaGFubmVscyAgbm90IGJlaW5nIHVzZWQgLSBub3QgZWZmaWNp ZW50IHVzZSBvZiB0aGUgc3BlY3RydW0uDQoNCkhvcGUgdGhpcyBoZWxwcy4NCg0KLUJlbg0KDQoN CkFuZHkgTGVlIHwNCg0KIEdvb2dsZSBJbmMuIHwNCg0KIHR2Zm9vbEBnb29nbGUuY29tPG1haWx0 bzp0dmZvb2xAZ29vZ2xlLmNvbT4gfA0KDQogNDA4LTIzMC0wNTIyPHRlbDo0MDgtMjMwLTA1MjI+ DQoNCg0KT24gVGh1LCBTZXAgMTksIDIwMTMgYXQgODozMCBBTSwgUmF5IEJlbGxpcyA8UmF5LkJl bGxpc0Bub21pbmV0Lm9yZy51azxtYWlsdG86UmF5LkJlbGxpc0Bub21pbmV0Lm9yZy51az4+IHdy b3RlOg0KDQpPbiAxOSBTZXAgMjAxMywgYXQgMTY6MjEsIEFuZHkgTGVlIDx0dmZvb2xAZ29vZ2xl LmNvbTxtYWlsdG86dHZmb29sQGdvb2dsZS5jb20+Pg0KIHdyb3RlOg0KDQo+IFRoaXMgYWN0dWFs bHkgc2hvd3MgdGhhdCBPZmNvbSBoYXMgcGlja2VkIGEgcG93ZXIgdGhyZXNob2xkIG9uIGNoYW5u ZWwgMzggb2YgLTMzIGRCbS4gIElmIHlvdSBsb29rIGF0IHRoZSBBQ0xSIG51bWJlcnMgZm9yIGNs YXNzIDMsIDQsIGFuZCA1IGRldmljZXMsIHlvdSdsbCBzZWUgdGhleSBhcmUgMTAgZEIgYXBhcnQg ZnJvbSBlYWNoIG90aGVyIGFuZCB0aGF0IHRoZXkgYWxsIHdvcmsgb3V0IHRvIGJlIC0zMyBkQm0g b24gY2hhbm5lbCAzOC4NCj4NCj4gVGhlIHJlYXNvbiB0aGVyZSBhcmUgbm8gbGltaXRzIGZvciBj bGFzcyAxIGFuZCAyIGRldmljZXMgaXMgYmVjYXVzZSB0aGUgaW4tYmFuZCBwb3dlciBvbiBjaGFu bmVscyAzNyBhbmQgMzkgY2Fubm90IGV4Y2VlZCArMzYgZEJtLzhNSHosIGFuZCB0aGVyZWZvcmUg dGhlIHBvd2VyIG9uIGNoYW5uZWwgMzggd2lsbCBuYXR1cmFsbHkgYmUgbGVzcyB0aGFuIC0zMyBk Qm0uDQpUaGUgbWF0aCBiZWFycyB0aGF0IG91dCwgYnV0IG5vbmV0aGVsZXNzIE9GQ09NIGFyZSBz dGlsbCBlZmZlY3RpdmVseSBwcm9wb3NpbmcgdGhhdCAqbm8qIGluLWJsb2NrIHRyYW5zbWlzc2lv bnMgYXJlIGFsbG93ZWQgaW4gdGhhdCBjaGFubmVsLg0KDQpQZXIgT0ZDT00gLyBFVFNJIGRldmlj ZSBpbnRlcmZhY2UgcmVxdWlyZW1lbnRzIGl0IHdvdWxkIGJlIGluY29ycmVjdCBmb3IgdXMgdG8g YWN0dWFsbHkgc2VuZCB0aGF0IHZhbHVlIG9mIC0zMyBkQm0gdG8gYSBkZXZpY2UuDQoNClJheQ0K DQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0K cGF3cyBtYWlsaW5nIGxpc3QNCg0KcGF3c0BpZXRmLm9yZzxtYWlsdG86cGF3c0BpZXRmLm9yZz4N Cg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wYXdzDQoNCg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnBhd3MgbWFpbGluZyBs aXN0DQpwYXdzQGlldGYub3JnPG1haWx0bzpwYXdzQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wYXdzDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCnBhd3MgbWFpbGluZyBsaXN0DQpwYXdzQGlldGYub3Jn PG1haWx0bzpwYXdzQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9wYXdzDQo= --_000_C31A91B2C81F417AA1D982067EDF2B5Bspectrumbridgecom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPjxkaXY+R2Fib3Ig aW4gcHJpbmNpcGxlIEkgdGhpbmsgeW91IGFuZCBBbmR5IGFyZSBib3RoIHJpZ2h0LiBJdCB3YXMg Y2FsbGVkIFBBV1MgYmVjYXVzZSBpdCB3YXMgc3VwcG9zZWQgdG8gYmUgYWJsZSB0byBjb3ZlciBt b3JlIHRoYW4gVFZXUy4gQnV0IHdoZW4gd2Ugd3JvdGUgdGhlIGNoYXJ0ZXIgd2Ugb25seSBoYWQg dGhlIEZDQyBhcyBhIGd1aWRlLiBNeSBwcmVmZXJlbmNlIGlzIHRvIHN0YXkgd2l0aGluIHRoZSBj aGFydGVyIGFuZCBhY2NlcHQgdGhhdCB0aGVyZSB3aWxsIGJlIGZ1dHVyZSB2ZXJzaW9ucyBvZiBh IHRoZSBzcGVjIGFzIG5ldyBzcGVjdHJ1bSBiYW5kcyBvcGVuIHVwJm5ic3A7PC9kaXY+PGRpdj48 YnI+T24gU2VwIDIwLCAyMDEzLCBhdCA5OjMyIFBNLCAiPGEgaHJlZj0ibWFpbHRvOkdhYm9yLkJh amtvQG5va2lhLmNvbSI+R2Fib3IuQmFqa29Abm9raWEuY29tPC9hPiIgJmx0OzxhIGhyZWY9Im1h aWx0bzpHYWJvci5CYWprb0Bub2tpYS5jb20iPkdhYm9yLkJhamtvQG5va2lhLmNvbTwvYT4mZ3Q7 IHdyb3RlOjxicj48YnI+PC9kaXY+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGRpdj4NCjxtZXRh IGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PVdp bmRvd3MtMTI1MiI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRlbnQ9Ik1pY3Jvc29mdCBX b3JkIDE0IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjwhLS1baWYgIW1zb10+PHN0eWxlPnZcOioge2Jl aGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCm9cOioge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNW TUwpO30NCndcOioge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCi5zaGFwZSB7YmVoYXZp b3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KPC9zdHlsZT48IVtlbmRpZl0tLT48c3R5bGU+PCEtLQ0K LyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpXaW5nZGlu Z3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OldpbmdkaW5nczsNCglwYW5vc2UtMTo1IDAgMCAwIDAgMCAwIDAgMCAwO30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDEx IDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0K CXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6VGltZXM7DQoJcGFub3NlLTE6MiAyIDYgMyA1IDQgNSAyIDMgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1h cmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnByZQ0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1h cmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUs IGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJp ZiI7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlz dFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJ bWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDouNWlu Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hh cg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9u dC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5h bWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0 eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2Vy aWYiO30NCnNwYW4uRW1haWxTdHlsZTIzDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFu LkVtYWlsU3R5bGUyNA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9 DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGlu IDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv bjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6OTE3 ODI2NzU7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi00 MjUwMzExOTYgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2 OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTU7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC10YWIt c3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9 DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6 bGV2ZWw1DQoJe21zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsNg0KCXtt c28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLXRh Yi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC10YWItc3RvcDo0LjBp bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu O30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBs MQ0KCXttc28tbGlzdC1pZDo2NTQ3Mjc4NTg7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNv LWxpc3QtdGVtcGxhdGUtaWRzOjQwNjkwMTc3OCAtNTM4MDI2NjQwIDY3Njk4NzEzIDY3Njk4NzE1 IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1O30N CkBsaXN0IGwxOmxldmVsMQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjsN Cgltc28tYXNjaWktZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tZmFyZWFzdC1mb250LWZhbWls eTpDYWxpYnJpOw0KCW1zby1oYW5zaS1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZv bnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KQGxpc3QgbDE6 bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwxOmxl dmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxOmxldmVsNQ0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu O30NCkBsaXN0IGwxOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dl cjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMTpsZXZlbDcNCgl7bXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTps ZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0 LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDINCgl7bXNvLWxpc3QtaWQ6MTAyMzkwMDk4NTsNCglt c28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTE1MzcxNzM4NTIg Njc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2 OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDI6bGV2ZWwxDQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpcRjBCNzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDINCgl7 bXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDI6bGV2ZWwzDQoJe21zby1sZXZlbC10 YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluO30NCkBsaXN0IGwyOmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6Mi4w aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjt9DQpAbGlzdCBsMjpsZXZlbDUNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3Qg bDI6bGV2ZWw2DQoJe21zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwyOmxldmVsNw0K CXttc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMjpsZXZlbDgNCgl7bXNvLWxldmVs LXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDI6bGV2ZWw5DQoJe21zby1sZXZlbC10YWItc3RvcDo0 LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluO30NCkBsaXN0IGwzDQoJe21zby1saXN0LWlkOjEyNzQzNjE1ODM7DQoJbXNvLWxpc3QtdHlw ZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xNzI0NTkwNzAwIC0xODcyODI3NTMw IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3 Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwzOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6 MzsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6LTsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTt9DQpAbGlzdCBsMzpsZXZl bDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30N CkBsaXN0IGwzOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ6XEYwQTc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWls eTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDM6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpcRjBCNzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMzpsZXZlbDUNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwzOmxldmVsNg0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6XEYwQTc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxp c3QgbDM6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDpcRjBCNzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5 bWJvbDt9DQpAbGlzdCBsMzpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZh bWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwzOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6XEYwQTc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDQNCgl7bXNvLWxpc3Qt aWQ6MTI5MjAwNzg4NTsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0 ZS1pZHM6MzgyNzcxOTY2IDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4 NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGw0OmxldmVs MQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6XEYw Qjc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp c3QgbDQ6bGV2ZWwyDQoJe21zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGw0OmxldmVs Mw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsNDpsZXZlbDQNCgl7bXNvLWxl dmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDQ6bGV2ZWw1DQoJe21zby1sZXZlbC10YWItc3Rv cDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluO30NCkBsaXN0IGw0OmxldmVsNg0KCXttc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpA bGlzdCBsNDpsZXZlbDcNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDQ6bGV2 ZWw4DQoJe21zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGw0OmxldmVsOQ0KCXttc28t bGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXtt YXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwh W2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9 ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlv dXQ+PC94bWw+PCFbZW5kaWZdLS0+DQoNCg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw cmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkZldyB0aGluZ3Mg dG8gY29uc2lkZXI6PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3By ZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW47dGV4dC1pbmRlbnQ6LS4yNWluO21zby1s aXN0OmwxIGxldmVsMSBsZm83Ij48IS0tW2lmICFzdXBwb3J0TGlzdHNdLS0+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25v cmUiPjEuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjwvc3Bhbj48L3Nw YW4+PCEtLVtlbmRpZl0tLT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+SSB0aGluayB3ZSBmaXJzdCBoYXZlIHRvIGFncmVlIHdoZXRoZXIgd2UgbmVlZCBhdCBhbGwg dG8gZW5jb2RlIGFuIOKAmHVuYXZhaWxhYmxlIGNoYW5uZWzigJkuIEN1cnJlbnQgZHJhZnQgc2Vj dGlvbiA0LjQuMiBzYXlzOiDigJw8L3NwYW4+VGhlIHJlc3BvbnNlIG1lc3NhZ2UgZm9yIHRoZSBB dmFpbGFibGUgU3BlY3RydW0gUXVlcnkgY29udGFpbnMgYTxvOnA+PC9vOnA+PC9wcmU+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IHNjaGVkdWxlIG9mIGF2YWls YWJsZSBzcGVjdHJ1bSBmb3IgdGhlIERldmljZS48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPuKAnSBUbyBtZSB0aGlzIG1lYW5zIHRoYXQgY2hhbm5lbHMg d2hpY2ggYXJlDQogbm90IGxpc3RlZCBhcmUgaW1wbGljaXRseSB1bmF2YWlsYWJsZSBhbmQgbGVh a2FnZSBpbnRvIHVuYXZhaWxhYmxlIHNwZWN0cnVtIGhhcyB0byBjb25mb3JtIHRvIHRoZSBydWxl cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1 aW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzciPjwhLS1baWYgIXN1cHBvcnRMaXN0c10tLT48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1s aXN0Oklnbm9yZSI+Mi48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwv c3Bhbj48L3NwYW4+PCEtLVtlbmRpZl0tLT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+SWYgb25lIHdhbnRzIHRvIGJlIGV4cGxpY2l0IG9uIHdoYXQgdGhlIHJ1bGVz IHNheSBmb3IgdGhlIGxlYWthZ2UgbGltaXRzLCB0aGVuIHdlIGNhbiBlbmNvZGUgdGhvc2UgaW50 byB0aGUgcnVsZXNldEluZm8uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0i dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwxIGxldmVsMSBsZm83Ij48IS0tW2lmICFzdXBw b3J0TGlzdHNdLS0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxz cGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjMuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhLS1bZW5kaWZdLS0+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPklmIHdlIHRha2Ugb24gQW5keeKAmXMgYXJndW1l bnQgdGhhdCBQQVdTIGNvdWxkIGJlIHVzZWQgb3V0c2lkZSBUVldTLCAqPGI+YW5kPC9iPiogbGVh a2FnZSBsaW1pdHMgbWF5IHBvdGVudGlhbGx5IGJlIGRpZmZlcmVudCBmb3IgZGlmZmVyZW50IGJh bmRzIHdpdGhpbg0KIHRoZSBzYW1lIHJlZ3VsYXRvcnkgZG9tYWluLCB0aGVuIGVuY29kaW5nIGFs bCB0aG9zZSBiYW5kcyBhbmQgbGVha2FnZSBsaW1pdHMgaW50byBydWxlc2V0SW5mbyBtaWdodCBq dXN0IGNvbXBsZW1lbnQgd2hhdCBpcyBtaXNzaW5nIGZyb20gdGhlIGF2YWlsYWJsZSBzcGVjdHJ1 bSByZXNwb25zZSBhbmQgd2UgbWF5IGJlIGJldHRlciBvZmYganVzdCBlbmNvZGluZyBldmVyeXRo aW5nIGludG8gYXZhaWxhYmxlIHNwZWN0cnVtIHJlc3BvbnNlLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+MSBhbmQgMiBk b2VzbuKAmXQgcmVxdWlyZSBhbiBlbmNvZGluZyBmb3IgdW5hdmFpbGFibGUgY2hhbm5lbC4gU2lt cGx5IG5vdCBsaXN0aW5nIGl0IGFzIGF2YWlsYWJsZSBkb2VzIHRoZSBqb2IuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjMgd291bGQgcmVxdWlyZSB1cyB0byBhZ3JlZSBob3cgdG8gZW5j b2RlIHVuYXZhaWxhYmxlIGNoYW5uZWwsIGJ1dCB0aGUgV1NEIHdvdWxkIHN0aWxsIG5lZWQgdG8g a25vdyB3aGF0IHRoZSBlbWlzc2lvbiBsaW1pdHMgYXJlIGluIHRoYXQgcmVndWxhdG9yeSBkb21h aW4gZm9yDQogdGhlIHVuYXZhaWxhYmxlIGNoYW5uZWxzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBh cmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMyBsZXZlbDEgbGZv OCI+PCEtLVtpZiAhc3VwcG9ydExpc3RzXS0tPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4tPHNwYW4gc3R5bGU9 ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9z cGFuPjwhLS1bZW5kaWZdLS0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPmdhYm9yPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0 REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij4gPGEgaHJlZj0ibWFpbHRvOnBhd3MtYm91bmNlc0BpZXRmLm9y ZyI+cGF3cy1ib3VuY2VzQGlldGYub3JnPC9hPiBbPGEgaHJlZj0ibWFpbHRvOnBhd3MtYm91bmNl c0BpZXRmLm9yZyI+bWFpbHRvOnBhd3MtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhh bGYgT2YgPC9iPmV4dCBIYXJhc3R5LCBEYW5pZWwgSjxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXks IFNlcHRlbWJlciAyMCwgMjAxMyA1OjE1IFBNPGJyPg0KPGI+VG86PC9iPiA8YSBocmVmPSJtYWls dG86cGF3c0BpZXRmLm9yZyI+cGF3c0BpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4g UmU6IFtwYXdzXSBTcGVjdHJ1bSBlbmNvZGluZyBkaXNjdXNzaW9uPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkFsbDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkga25vdyB0aGlzIGlzIGEgbG9uZyB3aW5k ZWQgcmVwbHkgdG8gYW4gYWxyZWFkeSBsYWJvcmlvdXMgY29udmVyc2F0aW9uLiZuYnNwOyBCdXQg SSB0aGluayBJIGNhbiBwdXQgYSBmaW5nZXIgb24gdGhlIGVzc2VudGlhbCDigJxkaXNhZ3JlZW1l bnTigJ0sIGFuZCBldmVuIG9mZmVyIGEgY29tcHJvbWlzZQ0KIHRoYXQgd2lsbCBhbGxvdyB1cyB0 byBtb3ZlIGZvcndhcmQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaW50OiB0aGUgd2hvbGUg4oCcb3B0aW9uIDHigJ0v 4oCdb3B0aW9uIDLigJ0gZGViYXRlIGlzIGEgYml0IG9mIGEgbWlzZGlyZWN0aW9uLCBhcyB0aG9z ZSB0d28gb3B0aW9ucyBkaWQgTk9UIGNhcHR1cmUgdGhlIHR3byBzaWRlcyBvZiB0aGUgZXNzZW50 aWFsIGRpc2FncmVlbWVudDsgdGhlDQogaXNzdWUgYXQgaGFuZCBpcyByZWFsbHkgYWJvdXQg4oCc aXMgYW4gb3V0LW9mLWJhbmQgZW1pc3Npb24gbGltaXQgYSBnb29kIHdheSB0byBleHByZXNzIHRo YXQgYSBjaGFubmVsIGlzIHVuYXZhaWxhYmxlP+KAnTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlcmUgc2VlbXMgdG8g YmUgdGhlIGNhbXAgdGhhdCDigJxvdXQgb2YgYmFuZCBlbWlzc2lvbiBsaW1pdHPigJ0gYXJlIHRo ZSBTQU1FIGFzIOKAnGNoYW5uZWwgdW5hdmFpbGFibGXigJ0uJm5ic3A7IEluIG15IHJlYWRpbmcg b2YgdGhlIEZDQyBydWxlcywgdGhhdCBpcyBzaW1wbHkgbm90IHRoZQ0KIGNhc2UuJm5ic3A7IFRo ZXJlIGFyZSB0aW1lcyB3aGVuIEZDQyBydWxlcyA8aT5yZXF1aXJlPC9pPiBtZSAoYXMgYSBEYXRh YmFzZSkgdG8gc2F5IOKAnHRoaXMgY2hhbm5lbCBpcyB1bmF2YWlsYWJsZeKAnQ0KPGk+b3RoZXI8 L2k+IHRoYW4g4oCcYSBwcm90ZWN0ZWQgZW50aXR5IG9jY3VwaWVzIHRoaXMgY2hhbm5lbOKAnS4m bmJzcDsgRm9yIGV4YW1wbGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0i dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwyIGxldmVsMSBsZm8yIj48IS0tW2lmICFzdXBw b3J0TGlzdHNdLS0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6U3lt Ym9sO2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4g c3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9z cGFuPjwhLS1bZW5kaWZdLS0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPkl0IGlzIGEgY2hhbm5lbCBjYXRlZ29yaWNhbGx5IGV4Y2x1ZGVkIGZyb20gdGhlIFdoaXRl c3BhY2Ugc3BlY3RydW0gKGUuZy4gVVMgQ2hhbm5lbCAzIG9yIENoYW5uZWwgMzcpLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1p bmRlbnQ6LS4yNWluO21zby1saXN0OmwyIGxldmVsMSBsZm8yIj48IS0tW2lmICFzdXBwb3J0TGlz dHNdLS0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sO2Nv bG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9 ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwh LS1bZW5kaWZdLS0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRo ZXJlIGlzIGFuIGFkLWhvYyAoRkNDIHByb3ZpZGVkKSBwb2x5Z29uIGVzdGFibGlzaGluZyBhbiBh ZC1ob2MgZXhjbHVzaW9uIHpvbmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDIgbGV2 ZWwxIGxmbzIiPjwhLS1baWYgIXN1cHBvcnRMaXN0c10tLT48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTpTeW1ib2w7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1z by1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCEtLVtlbmRpZl0tLT48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QSBkZXZpY2UgaXMgYmxhY2tsaXN0ZWQuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5UbyBzYXkgdGhhdCDigJxDaGFubmVsIDM3IGlzIGF2YWlsYWJsZSBhdCAtMzYuOCBkQm3i gJ0gaXMganVzdCBub3QgdGhlIHNhbWUgYXMg4oCcQ2hhbm5lbCAzNyBpcyB1bmF2YWlsYWJsZeKA nSwgSU1PLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+VG8gdGVsbCBhbGwgZGV2aWNlcyBpbiBhbiBhZC1ob2MgZXhjbHVz aW9uIHpvbmUgdGhhdCDigJxhbGwgY2hhbm5lbHMgYXJlIGF2YWlsYWJsZSBhdCAtMzYuOCBkQm3i gJ0gaXMganVzdCBub3QgdGhlIHNhbWUgYXMg4oCcYWxsIGNoYW5uZWxzIGFyZSB1bmF2YWlsYWJs ZeKAnS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPlRvIHRlbGwgYSBibGFja2xpc3RlZCBkZXZpY2UgdGhhdCDigJxhbGwg Y2hhbm5lbHMgYXJlIGF2YWlsYWJsZSBhdCAtMzYuOCBkQm3igJ0gaXMganVzdCBub3QgdGhlIHNh bWUgYXMg4oCcYWxsIGNoYW5uZWxzIGFyZSB1bmF2YWlsYWJsZeKAnS48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPklu IG90aGVyIHdvcmRzOiBJZiBQQVdTIGRvZXMgbm90IGdpdmUgbWUgYSB3YXkgdG8gc2F5IGEgY2hh bm5lbCBpcyB1bmVxdWl2b2NhbGx5IOKAnHVuYXZhaWxhYmxl4oCdLCB0aGVuLCBpbiBteSBvcGlu aW9uIGFzIGEgRGF0YWJhc2UgcHJvdmlkZXIsIGl0IGlzIG5vdCBzdWZmaWNpZW50bHkNCiBleHBy ZXNzaXZlIGZvciBtZSB0byBtZWV0IHRoZSBGQ0MgcnVsZXMuICZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PklmIHdlIERPIHVzZSBQQVdTIHRvIGVuY29kZSBvdXQtb2YtYmFuZCBlbWlzc2lvbnMgbGltaXRz LCBJIGhhdmUgdG8gc2F5LCBJIHRoaW5rIGl0IGlzIGZhcmZldGNoZWQgdGhhdCBhIGRldmljZSBp bXBsZW1lbnRlZCB0b2RheSB0byB0b2RheeKAmXMgcnVsZXMgd2lsbCBiZSBhYmxlDQogdG8g4oCT IGluIHRoZSBmdXR1cmUg4oCTIGVpdGhlciDigJx0YWtlIGFkdmFudGFnZeKAnSBvZiBhIGxlc3Mg c3RyaW5nZW50IOKAnG91dC1vZi1iYW5kIG1hc2vigJ0gb3IgY29tcGx5IHRvIGEgbW9yZSBzdHJp bmdlbnQgbWFzay4mbmJzcDsgQXMgbWFydmVsb3VzIGFzIFNEUnMgYXJlL2NhbiBiZSwgdGhhdCBk ZWdyZWUgb2YgZmxleGliaWxpdHkgaXMganVzdCBub3QgY29tbW9uIGluIGNvbnN1bWVyLWdyYWRl IG1hc3MgbWFya2V0IGRldmljZXMgb3dpbmcgdG8gY29zdC4mbmJzcDsgVGhhdA0KIGxlYWRzIG1l IHRvIHRoZSBjb25jbHVzaW9uIHRoYXQgZXhwZWN0aW5nIHRvIHVzZSBQQVdTIHRoYXQgd2F5IGlz IGp1c3Qgbm90IGdvaW5nIHRvIGJlIHRoYXQgdXNlZnVsLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SG93ZXZlciwgSSBy ZWFsaXplIHdlIG1heSBkaWZmZXIgb24gdGhpcyBwb2ludC4mbmJzcDsgQnV0IHRoZSBub3Rpb24g b2Yg4oCcUEFXUyBhdmFpbGFibGUtc3BlY3RydW0gcmVwbGllcyBzaG91bGQgZW5jb2RlIG91dC1v Zi1iYW5kIGVtaXNzaW9ucyBsaW1pdHPigJ0gaXMganVzdCBhIHNlcGFyYXRlDQogbm90aW9uIGZy b20g4oCcUEFXUyBtdXN0IGFsbG93IGEgd2F5IHRvIGVuY29kZSDigJhjaGFubmVsIHVuYXZhaWxh Ymxl4oCZ4oCdLiZuYnNwOyBJdCBpcyBjb25mb3VuZGluZyB0aG9zZSB0d28gY29uY2VwdHMgdGhh dCDigJMgSU1PIOKAkyBoYXMgbGVhZCB0byB0aGUgY3VycmVudCDigJxkaXNhZ3JlZW1lbnTigJ0u PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5PSywgdGltZSBmb3IgbXkgcHJvcG9zZWQgZ3JhbmQgY29tcHJvbWlzZTo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNv LWxpc3Q6bDQgbGV2ZWwxIGxmbzQiPjwhLS1baWYgIXN1cHBvcnRMaXN0c10tLT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpTeW1ib2w7Y29sb3I6IzFGNDk3RCI+PHNw YW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCEtLVtlbmRpZl0tLT48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TGV04oCZcyBkZWZpbmUgYSB3 YXkgdG8gdW5lcXVpdm9jYWxseSBlbmNvZGUg4oCcY2hhbm5lbCB1bmF2YWlsYWJsZeKAnSB0aGF0 IGlzIE5PVCBzeW5vbnltb3VzIHdpdGgg4oCcb3V0IG9mIGJhbmQgZW1pc3Npb25zIGxpbWl0c+KA nS4NCjxpPiZuYnNwO0kgbmVlZCBpdCBhcyBhIERhdGFiYXNlIHByb3ZpZGVyPC9pPi4mbmJzcDsg KEFnYWluOiBJIG9mZmVyIHRvIHJlY2FwIHNldmVyYWwgZGlmZmVyZW50IHdheXMgdG8gZG8gdGhp cyBsYXRlci4pPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRl bnQ6LS4yNWluO21zby1saXN0Omw0IGxldmVsMSBsZm80Ij48IS0tW2lmICFzdXBwb3J0TGlzdHNd LS0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sO2NvbG9y OiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZv bnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhLS1b ZW5kaWZdLS0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk9uY2Ug d2UgaGF2ZSBhIHdheSB0byB1bmVxdWl2b2NhbGx5IGVuY29kZSDigJxjaGFubmVsIHVuYXZhaWxh Ymxl4oCdLCB3ZSBjYW4gaGF2ZSBhDQo8aT5zZXBhcmF0ZTwvaT4gZGlzY3Vzc2lvbiBhcyB0byB3 aGV0aGVyIG9yIG5vdCBpdCBpcyBldmVyIHVzZWQuJm5ic3A7IFBlcmhhcHMgZGlmZmVyZW50IERh dGFiYXNlcyB3aWxsIGludGVycHJldCB0aGVpciBsZWdhbC9yZWd1bGF0b3J5IG9ibGlnYXRpb25z IGRpZmZlcmVudGx5LiZuYnNwOyBPciBldmVuLCBhIGdpdmVuIERhdGFiYXNlIG1heSB1c2Ug4oCc LTM2LjggZEJt4oCdIGluIHNvbWUgY2FzZXMgYW5kIOKAnGNoYW5uZWwgdW5hdmFpbGFibGXigJ0g aW4gb3RoZXJzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlIHB1cnBvc2Ugb2YgdGhpcyBXRyBpcyB0byBwcm9kdWNl IGEgcHJvdG9jb2wgdGhhdDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0 ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzYiPjwhLS1baWYgIXN1cHBv cnRMaXN0c10tLT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PHNw YW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+MS48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCEtLVtlbmRpZl0tLT48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UHJvdmlkZXMgZm9yIGludGVyb3BlcmFiaWxpdHkg KGJlY2F1c2UgaXQgaXMgc3VmZmljaWVudGx5IGNsZWFyKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQ YXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxm bzYiPjwhLS1baWYgIXN1cHBvcnRMaXN0c10tLT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+Mi48c3BhbiBzdHls ZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCEtLVtlbmRpZl0t LT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QWxsb3dzIGFsbCBw YXJ0aWVzIHRvIG1lZXQgdGhlaXIgbGVnYWwvcmVndWxhdG9yeSBvYmxpZ2F0aW9ucyBhcyB0aGV5 IGludGVycHJldCB0aGVtLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBmZWVsIHRoZSBhYm92ZSBwcm9wb3NlZCBjb21w cm9taXNlIGFjY29tcGxpc2hlcyBib3RoLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkRhbiBIYXJhc3R5PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4w cHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ DQo8YSBocmVmPSJtYWlsdG86cGF3cy1ib3VuY2VzQGlldGYub3JnIj5wYXdzLWJvdW5jZXNAaWV0 Zi5vcmc8L2E+IFs8YSBocmVmPSJtYWlsdG86cGF3cy1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86 cGF3cy1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+QW5keSBMZWU8 YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBTZXB0ZW1iZXIgMjAsIDIwMTMgNzoxMiBQTTxicj4N CjxiPlRvOjwvYj4gUGV0ZXIgU3RhbmZvcnRoPGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWls dG86cGF3c0BpZXRmLm9yZyI+cGF3c0BpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4g UmU6IFtwYXdzXSBTcGVjdHJ1bSBlbmNvZGluZyBkaXNjdXNzaW9uPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHdhcyBhY3R1YWxseSBob3BpbmcgdG8gc2lt cGxpZnkgdGhpbmdzIGZvciBkZXZpY2VzLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+MSkgSGF2aW5nIGEgZnVsbHkgc3BlY2lmaWVkIHNwZWN0cnVtIHByb2Zp bGUgd2l0aG91dCBkaXNjb250aW51aXRpZXMgYW5kIHdpdGhvdXQgInNwZWNpYWwiIHZhbHVlcyBs aWtlIC1pbmYgbWFrZSBpdCBtdWNoIGVhc2llciB0byB3cml0ZSB0aGUgY2xpZW50IHNpZGUgY29k ZS4gJm5ic3A7VGhpcyBtaW5pbWl6ZXMgdGhlIG51bWJlciBvZiBzcGVjaWFsIGVkZ2UgY2FzZXMg dGhhdCBuZWVkIHRvIGJlIGhhbmRsZWQgYnkgdGhlDQogcGFyc2luZyBsb2dpYyBhbmQgImVtaXNz aW9uIGZpdHRpbmciIGNvZGUgb24gdGhlIGNsaWVudC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MikgV2Ugc3RpbGwgc2VlbSB0byBiZSB0aGlu a2luZyBpbiB0ZXJtcyBvZiBUViBjaGFubmVscyBvbmx5LiAmbmJzcDtQQVdTIGlzIGRlc2lnbmVk IGZvciBvdGhlciBmcmVxdWVuY3kgYmFuZHMgdG9vLCBhbmQgdGhlcmUgd29uJ3QgYWx3YXlzIGJl IHN1Y2ggYSBkaXN0aW5jdCBjb25jZXB0IG9mIG9uLWNoYW5uZWwgdnMuIGFkamFjZW50LWNoYW5u ZWwgZW1pc3Npb25zLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4zKSBXZSBkb24ndCBrbm93IHdoYXQgZnV0dXJlIFdTRCB0ZWNobm9sb2dpZXMg d2lsbCBiZSBjYXBhYmxlIG9mLiAmbmJzcDtXaS1GaSBhbHJlYWR5IHN1cHBvcnRzIGEgbG9uZyBs aXN0IG9mIG1vZHVsYXRpb24gdHlwZXMgKGUuZy4sIEJQU0ssIFFQU0ssIERTU1MsIEZIU1MsIE9G RE0pIGFuZCBjaGFubmVsIHdpZHRocy4gJm5ic3A7U29mdHdhcmUgZGVmaW5lZCByYWRpb3MgYW5k IG90aGVyIHRlY2hub2xvZ2llcyBjYW4gZHluYW1pY2FsbHkNCiBjaG9vc2UgbW9kdWxhdGlvbiB0 eXBlcywgY2hhbm5lbCB3aWR0aHMsIGFuZCBwb3dlciBkaXN0cmlidXRpb24uICZuYnNwO1RoZXNl IGFnaWxlIHJhZGlvIHRlY2hub2xvZ2llcyBuZWVkIHRoZSBmdWxsIHNwZWN0cnVtIHByb2ZpbGUg dG8gaGVscCB0aGVtIGNob29zZSB0aGUgcmlnaHQgY29tYmluYXRpb24gb2YgZW1pc3Npb24gcGFy YW1ldGVycy4gJm5ic3A7V1NEcyBhcmUganVzdCBhICJibGFjayBib3giIGZyb20gdGhlIGRhdGFi YXNlJ3MgcG9pbnQgb2Ygdmlldy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7VGltZXMmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHNw YWNpbmc9IjAiIGNlbGxwYWRkaW5nPSIwIj4NCjx0Ym9keT4NCjx0cj4NCjx0ZCBub3dyYXA9IiIg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0Q1MEYyNSAxLjVwdDtwYWRkaW5n OjBpbiAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj NTU1NTU1Ij5BbmR5IExlZSZuYnNwO3w8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPHRk IG5vd3JhcD0iIiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjMzM2OUU4IDEu NXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiM1NTU1NTUiPiZuYnNwO0dvb2dsZSBJbmMuIHw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L3RkPg0KPHRkIG5vd3JhcD0iIiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjMDA5OTM5IDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM1NTU1NTUiPiZuYnNwOzxhIGhyZWY9Im1haWx0bzp0 dmZvb2xAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnR2Zm9vbEBnb29nbGUuY29tPC9hPiZu YnNwO3w8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPHRkIG5vd3JhcD0iIiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRUVCMjExIDEuNXB0O3BhZGRpbmc6MGluIDBp biAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM1NTU1NTUi PiZuYnNwOzQwOC0yMzAtMDUyMjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8L3RyPg0K PC90Ym9keT4NCjwvdGFibGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+T24gRnJpLCBTZXAgMjAsIDIwMTMgYXQgMjozNSBQTSwgUGV0ZXIgU3Rh bmZvcnRoICZsdDs8YSBocmVmPSJtYWlsdG86cGV0ZXJAc3BlY3RydW1icmlkZ2UuY29tIiB0YXJn ZXQ9Il9ibGFuayI+cGV0ZXJAc3BlY3RydW1icmlkZ2UuY29tPC9hPiZndDsgd3JvdGU6PG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+V2UgaGF2ZSwgdW50aWwga25vdywgYWx3YXlzIHdvcmtlZCBvbiB0 aGUgYXNzdW1wdGlvbiB0aGF0IHRoZSBkZXZpY2Ugd291bGQgYmUgY2VydGlmaWVkLCBvciBub3Qs IHRvIGNvbXBseSB3aXRoIGFueSBvdXQgb2YgYmFuZCBlbWlzc2lvbnMuIFRoZSBGQ0MgZm9yIGlu c3RhbmNlIHNwZWNpZmljYWxseQ0KIHRlc3RzIHRoZSBtb3JlIHN0cmluZ2VudCBydWxlIGFyb3Vu ZCBjaGFubmVsIDM3LCBhcyB3ZWxsIGFzIHRoZSBtb3JlIGdlbmVyYWwgY2FzZS4gVGhlIERhdGFi YXNlIGlzIG5vdCwgYW5kIGNhbm5vdCBiZSwgdGhlIGVuZm9yY2VtZW50IGFnZW5jeS4gU28gc2lt cGx5IHByb3ZpZGluZyBhIGxpc3Qgb2YgY2hhbm5lbHMgdGhhdCBpdCBjYW4gdXNlIGlzIHN1ZmZp Y2llbnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5JdCBzaG91bGQgYmUgb2Ygbm8g Y29uc2VxdWVuY2UgdG8gYSBkZXZpY2Ugd2h5IGl0IGNhbm5vdCB1c2UgYSBjaGFubmVsIG90aGVy IHRoYW4gdG8gYmVoYXZlIHdpdGggaXRzIGNvbXBsaWFudCBlbWlzc2lvbnMuJm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5JIGFncmVlIHdpdGggR2Fib3IsIHdoeSBhcmUgd2Ug b3Zlcmx5IGNvbXBsaWNhdGluZyB0aGlzPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGlu IDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPkZyb206DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IjxhIGhy ZWY9Im1haWx0bzpHYWJvci5CYWprb0Bub2tpYS5jb20iIHRhcmdldD0iX2JsYW5rIj5HYWJvci5C YWprb0Bub2tpYS5jb208L2E+IiAmbHQ7PGEgaHJlZj0ibWFpbHRvOkdhYm9yLkJhamtvQG5va2lh LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPkdhYm9yLkJhamtvQG5va2lhLmNvbTwvYT4mZ3Q7PGJyPg0K PGI+RGF0ZTogPC9iPkZyaWRheSwgU2VwdGVtYmVyIDIwLCAyMDEzIDQ6NTQgUE08YnI+DQo8Yj5U bzogPC9iPiI8YSBocmVmPSJtYWlsdG86dHZmb29sQGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5r Ij50dmZvb2xAZ29vZ2xlLmNvbTwvYT4iICZsdDs8YSBocmVmPSJtYWlsdG86dHZmb29sQGdvb2ds ZS5jb20iIHRhcmdldD0iX2JsYW5rIj50dmZvb2xAZ29vZ2xlLmNvbTwvYT4mZ3Q7LCAiPGEgaHJl Zj0ibWFpbHRvOmJlbkBibGluZGNyZWVrLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmJlbkBibGluZGNy ZWVrLmNvbTwvYT4iICZsdDs8YSBocmVmPSJtYWlsdG86YmVuQGJsaW5kY3JlZWsuY29tIiB0YXJn ZXQ9Il9ibGFuayI+YmVuQGJsaW5kY3JlZWsuY29tPC9hPiZndDs8YnI+DQo8Yj5DYzogPC9iPiI8 YSBocmVmPSJtYWlsdG86cGF3c0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnBhd3NAaWV0Zi5v cmc8L2E+IiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBhd3NAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij5wYXdzQGlldGYub3JnPC9hPiZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGJy Pg0KPGI+U3ViamVjdDogPC9iPlJlOiBbcGF3c10gU3BlY3RydW0gZW5jb2RpbmcgZGlzY3Vzc2lv bjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5BcmVu4oCZdCB3ZSB0YWxraW5nIHBhc3QgZWFjaCBvdGhlciBpbiB0 aGlzIHRocmVhZD88L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JZiB0aGUgcnVsZXMg YXJlIHN1cHBvc2VkIHRvIHNwZWNpZnkgd2hhdCBpcyB0aGUgbWF4IGludGVuZGVkIHBvd2VyIGxl dmVsIGEgZGV2aWNlIGNhbiBwdXQgaW50byBhDQogY2hhbm5lbCAoYXZhaWxhYmxlIG9yIG5vdCks IHRoZW4gSSBhbHNvIHRoaW5rIHRoaXMgaXMgd2hhdCB0aGUgREIgc2hvdWxkIGNvbW11bmljYXRl IHRvIHRoZSBkZXZpY2UuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SWYgT2Zjb20g c3BlY2lmaWVzIHRoYXQgdGhlIG1heCBsZWFrYWdlIGludG8gYW4gdW5hdmFpbGFibGUgY2hhbm5l bCBpcyAtMzNkYm0sIEkgYXNzdW1lIHRoZSBkZXZpY2UNCiB3aWxsIG5vdCBiZSBjZXJ0aWZpZWQg aWYgaXQgbGVha3MgbW9yZS4gSWYgdGhlIGRldmljZSBzdXBwb3J0cyBtdWx0aXBsZSBtb2R1bGF0 aW9uIHR5cGVzIGFuZCBvbmUgb2YgdGhlbSBsZWFrcyBtb3JlIHRoYW4gd2hhdCBpcyBwZXJtaXR0 ZWQgaW4gdGhhdCByZWd1bGF0b3J5IGRvbWFpbiwgdGhlbiB0aGUgZGV2aWNlIHdpbGwgbmVlZCB0 byBrbm93IGl0LCBhbmQgaW4gdGhhdCByZWd1bGF0b3J5IGRvbWFpbiBhdm9pZCB1c2luZyB0aGF0 IHBhcnRpY3VsYXINCiBtb2R1bGF0aW9uIHR5cGUuIEhvdyBkb2VzIHRoZSBkZXZpY2UgY29tZSB0 byBrbm93IGl0PyBBbmR5IHByb3Bvc2VzIHRoZSBEQiB0byBpbmRpY2F0ZSB0aGF0IGxldmVsIGZv ciB0aGUgdW5hdmFpbGFibGUgY2hhbm5lbHMuIE90aGVycyBmb2xrcyBzZWVtIHRvIHN1Z2dlc3Qg YSBkZXZpY2UgYnVpbHQgdG8gb3BlcmF0ZSB1bmRlciBhIGNlcnRhaW4gcnVsZXNldCBoYXMgdG8g aW1wbGljaXRseSBrbm93IGl0Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFub3Ro ZXIgd2F5IG9mIGxvb2tpbmcgYXQgaXQgbWlnaHQgYmUgdG8gc2F5IHRoYXQgdGhlIG1heCBsZXZl bCBvZiBwZXJtaXR0ZWQgdW5pbnRlbnRpb25hbCBsZWFrYWdlDQogaW50byBhbiBhZGphY2VudCBj aGFubmVsIGlzIHBhcnQgb2YgdGhlIHJ1bGVzZXRJbmZvLCBhbmQgdGhlIHNwZWN0cnVtIHJlc3Bv bnNlIG9ubHkgbGlzdHMgdGhlIGF2YWlsYWJsZSBjaGFubmVscy4gQ291bGQgdGhpcyBiZSBhIHdh eSBmb3J3YXJkPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj4tPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4w cHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPmdhYm9yPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJv bTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4NCjxhIGhyZWY9Im1haWx0 bzpwYXdzLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5wYXdzLWJvdW5jZXNAaWV0 Zi5vcmc8L2E+IFs8YSBocmVmPSJtYWlsdG86cGF3cy1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+bWFpbHRvOnBhd3MtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYg T2YgPC9iPmV4dCBBbmR5IExlZTxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIFNlcHRlbWJlciAy MCwgMjAxMyAxOjAwIFBNPGJyPg0KPGI+VG86PC9iPiBCZW5qYW1pbiBBLiBSb2xmZTxicj4NCjxi PkNjOjwvYj4gUHJvdG9jb2wgdG8gQWNjZXNzIFdoaXRlIFNwYWNlIGRhdGFiYXNlPGJyPg0KPGI+ U3ViamVjdDo8L2I+IFJlOiBbcGF3c10gU3BlY3RydW0gZW5jb2RpbmcgZGlzY3Vzc2lvbjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5IaSBCZW4sPG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxl ZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij5BbmQgdGhhdCBtZWFucyBOTyBpbnRlbnRpb25hbCByYWRpYXRpb24gaW4gdGhlIGNoYW5uZWwu Jm5ic3A7Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGlu IDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBp bjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+SWYgeW91IGFyZSByZWFkaW5nIHRoaXMgYXMgInRyYW5zbWl0dGVk IGVtaXNzaW9ucyBpbiBiYW5kIHNob3VsZCBiZSBsb3dlciB0aGFuIC0zM2RCbSIgdGhlbiwgbm8s IHRoaXMgaXMgbm90IHRoZQ0KIHNhbWUgYXMgIm5vIGVtaXNzaW9ucyIgcGVyIEZDQyBydWxlcy4g SWYgb25lIHdlcmUgdG8gaW50ZW50aW9uYWxseSB0cmFuc21pdCBhdCAtMzNkQm0gd2hlcmUgbm8g aW50ZW50aW9uYWwgZW1pc3Npb25zIGFyZSBhbGxvd2VkLCB0aGF0IHdvdWxkIG5vdCBiZSB0aGUg c2FtZSBhcyAibm8iIHVuZGVyIHRoZSBydWxlcy48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+VGhlcmUgaXMgY2VydGFpbmx5IG5vIGludGVudGlvbiB0byBlbmNvdXJhZ2UgYW55IG1h bGljaW91cyBiZWhhdmlvci4gJm5ic3A7SW4gZ2VuZXJhbCwgd2UgZXhwZWN0IGRldmljZXMgdG8g YmUgdHJ5aW5nIHRvIGRvIHRoZSByaWdodCB0aGluZw0KIGFuZCBqdXN0IG5lZWQgc29tZSBpbmZv cm1hdGlvbiB0byB1bmRlcnN0YW5kIHdoZXJlIHRoZSBib3VuZGFyaWVzIGFyZS4gJm5ic3A7VGhl c2UgYm91bmRhcmllcyBpbmNsdWRlIGJvdGggaW50ZW50aW9uYWwgYW5kIHVuaW50ZW50aW9uYWwg ZW1pc3Npb25zLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5WYXJpb3VzIG1vZHVsYXRpb24gdHlwZXMgaGF2 ZSBrbm93biBzcGVjdHJhbCBwcm9maWxlcywgaW5jbHVkaW5nIGJvdGggaW4tYmFuZCBhbmQgb3V0 LW9mLWJhbmQgZW1pc3Npb25zLiAmbmJzcDtLbm93aW5nIHdoZXJlIHRoZSAic2hlbGYiDQogaXMg b24gdGhlIGFkamFjZW50IGNoYW5uZWwgbWFrZXMgaXQgcG9zc2libGUgdG8gbWF0Y2ggdGhhdCB3 aXRoIHRoZSAic2tpcnQiIG9mIHRoZSBpbnRlbmRlZCBtb2R1bGF0aW9uIHBhdHRlcm4uICZuYnNw O1RoZSAic2tpcnQiIGlzIG5vdCBwYXJ0IG9mIHRoZSBpbnRlbmRlZCBlbWlzc2lvbiwgYnV0IGlz IGltcG9ydGFudCBpbiB0cnlpbmcgdG8gYXZvaWQgY2F1c2luZyBpbnRlcmZlcmVuY2Ugb24gYWRq YWNlbnQgY2hhbm5lbHMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkEgY3J1ZGUgZXhhbXBsZSBvZiB0aGlz IGlzIHNob3duIGluIHRoZSBmb2xsb3dpbmcgaW1hZ2U6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZsdDtp bWFnZTAwMS5wbmcmZ3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkJlc3QgcmVnYXJkcyw8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMmcXVvdDssJnF1 b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjx0YWJsZSBjbGFz cz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9IjAiIGNlbGxwYWRkaW5n PSIwIj4NCjx0Ym9keT4NCjx0cj4NCjx0ZCBub3dyYXA9IiIgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci10b3A6c29saWQgI0Q1MEYyNSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDBpbiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM1NTU1NTUiPkFuZHkgTGVlJm5i c3A7fDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgbm93cmFwPSIiIHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICMzMzY5RTggMS41cHQ7cGFkZGluZzowaW4gMGlu IDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNTU1NTU1 Ij4mbmJzcDtHb29nbGUgSW5jLiB8PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCBu b3dyYXA9IiIgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgIzAwOTkzOSAxLjVw dDtwYWRkaW5nOjBpbiAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiM1NTU1NTUiPiZuYnNwOzxhIGhyZWY9Im1haWx0bzp0dmZvb2xAZ29vZ2xlLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPnR2Zm9vbEBnb29nbGUuY29tPC9hPiZuYnNwO3w8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L3RkPg0KPHRkIG5vd3JhcD0iIiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjRUVCMjExIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gMGluIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzU1NTU1NSI+Jm5ic3A7PGEgaHJl Zj0idGVsOjQwOC0yMzAtMDUyMiIgdGFyZ2V0PSJfYmxhbmsiPjQwOC0yMzAtMDUyMjwvYT48L3Nw YW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bWFyZ2luLWJvdHRvbToxMi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+T24gRnJpLCBTZXAgMjAsIDIwMTMgYXQgMzowNyBBTSwgQmVuamFt aW4gQS4gUm9sZmUgJmx0OzxhIGhyZWY9Im1haWx0bzpiZW5AYmxpbmRjcmVlay5jb20iIHRhcmdl dD0iX2JsYW5rIj5iZW5AYmxpbmRjcmVlay5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIDkvMTkvMjAxMyA5OjA5IEFN LCBBbmR5IExlZSB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGJsb2Nr cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7 cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlRoZSBtYXRoIGJlYXJzIHRoYXQg b3V0LCBidXQgbm9uZXRoZWxlc3MmbmJzcDtPRkNPTSZuYnNwO2FyZSBzdGlsbCBlZmZlY3RpdmVs eSBwcm9wb3NpbmcgdGhhdCAqbm8qIGluLWJsb2NrIHRyYW5zbWlzc2lvbnMgYXJlDQogYWxsb3dl ZCBpbiB0aGF0IGNoYW5uZWwuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlNhbWUgaXMgdHJ1ZSBmb3IgdGhlIEZD Qy4gJm5ic3A7VGhlIEZDQyBhbHNvIGFzc3VtZXMgdGhhdCAib2ZmIiBjaGFubmVscyBhcmUgbm90 IHVzZWQgYnkgV1NEcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QW5kIHRoYXQgbWVhbnMgTk8gaW50 ZW50aW9uYWwgcmFkaWF0aW9uIGluIHRoZSBjaGFubmVsLiZuYnNwOw0KPG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlNwZWNp ZnlpbmcgYSBsb3cgcG93ZXIgbGV2ZWwgbGlrZSAtMzMgZEJtIGlzIGVmZmVjdGl2ZWx5IHRoZSBz YW1lIHRoaW5nIGFzIHNwZWNpZnlpbmcgbm8gaW4tYmFuZCBlbWlzc2lvbnMgdGhlcmUuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5JZiB5b3UgYXJlIHJlYWRpbmcgdGhpcyBhcyAidHJhbnNtaXR0ZWQgZW1pc3Npb25zIGlu IGJhbmQgc2hvdWxkIGJlIGxvd2VyIHRoYW4gLTMzZEJtIiB0aGVuLCBubywgdGhpcyBpcyBub3Qg dGhlIHNhbWUgYXMgIm5vIGVtaXNzaW9ucyIgcGVyIEZDQyBydWxlcy4gSWYgb25lIHdlcmUgdG8g aW50ZW50aW9uYWxseQ0KIHRyYW5zbWl0IGF0IC0zM2RCbSB3aGVyZSBubyBpbnRlbnRpb25hbCBl bWlzc2lvbnMgYXJlIGFsbG93ZWQsIHRoYXQgd291bGQgbm90IGJlIHRoZSBzYW1lIGFzICJubyIg dW5kZXIgdGhlIHJ1bGVzLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPkV2ZW4gaWYgc29tZW9uZSBkaWQgdHJ5IHRvIHB1dCBhbiBpbi1iYW5kIGVtaXNzaW9u IHRoZXJlIChyZWdhcmRsZXNzIG9mIGhvdyBpbXByYWN0aWNhbCB0aGF0IGFjdHVhbGx5IGlzKSwg aXQgd291bGQgYmUgdG9vIGxvdyB0byBjYXVzZSBpbnRlcmZlcmVuY2UgdG8gYW55b25lIGFuZCBu byBoYXJtIGhhcyBiZWVuDQogZG9uZSB0byB0aGUgIlJGIGVudmlyb25tZW50Ii48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+U2hv dWxkIGJlIGEgbGl0dGxlIGNhcmVmdWwgaGVyZSBmb3IgYSBjb3VwbGUgcmVhc29ucy4mbmJzcDsg SSd2ZSBkZXNpZ25lZCBhbmQgc2hpcHBlZCBjb21tdW5pY2F0aW9uIHN5c3RlbXMgdGhhdCBvcGVy YXRlIHF1aXRlIHdlbGwgd2l0aCB0cmFuc21pdCBwb3dlciBsZXZlbHMgaW50ZW50aW9uYWxseSBi ZWxvdyAtMzNkQm0NCiBhbmQgZG8gdmVyeSB1c2VmdWwgdGhpbmdzLiBJdCdzIHByZXR0eSBlYXN5 IHRvIGRlc2lnbiBhIHJlY2VpdmUgd2l0aCBzZW5zaXRpdml0eSBiZXR0ZXIgdGhhbiAtOTZkQm0s IHNvIGFuIGludGVudGlvbmFsIHJhZGlhdG9yIGF0IC0zM2RCbSBuZWFyIGJ5IHdpbGwgYmUgbm90 aWNlZCAtIGF0IDkwMCBNSHogeW91ciAxMGRCIGFib3ZlIHNlbnNpdGl2aXR5IGF0IDEwbSBhbmQg YXQgNTRNSHogeW91J2QgYmUgMTAgZEIgYWJvdmUgc2Vuc2l0aXZpdHkNCiBhdCAxMDBtLCBwb3Nz aWJseS4gQW5kIHdoZW4gaXQgY29tZXMgdG8gcHJvdGVjdGluZyB0aGVpciBzcGVjdHJ1bSwgcGVv cGxlIGFsd2F5cyB1c2UgdGhlIGJlc3QgcHJvcGFnYXRpb24gbW9kZWwgdG8gY2FsY3VsYXRlIGlu dGVyZmVuY2UgaW1wYWN0IG9uIHRoZW0gOi0pLiZuYnNwOyBJJ3ZlIHByb2JhYmx5IG1pc3VuZGVy c3Rvb2Qgc29tZXRoaW5nIGJhZGx5LCBidXQgLTMzZEJtIGlzIGNlcnRhaW5seSBlbm91Z2ggcG93 ZXIgdG8gYmUgbm90aWNlZC4NCjxicj4NCjxicj4NCkkgaGF2ZSB0cmllZCB0aGUgInRvbyBsb3cg dG8gYmUgbm90aWNlZCIgYXJndW1lbnQgYSBmZXcgdGltZXMgaW4gdGhlIHBhc3QmbmJzcDsgaW4g cmVndWxhdG9yeSBkaXNjdXNzaW9ucywgYW5kIGluY3VtYmVudCBhbmQvb3IgcHJvdGVjdGVkIHVz ZXJzIHVzdWFsbHkgc2V0IHRoZSB0aHJlc2hvbGQgY2xvc2VyIHRvIC0xMjBkQm0gYW5kIHVzdWFs bHkgYXJndWUgdGhhdCBldmVuIGF0IHJlYWxseSBsb3cgVFggcG93ZXIsIHRoZSAiYWdncmVnYXRl IGltcGFjdCINCiBvZiBtdWx0aXBsZSBkZXZpY2VzIGluIHRoZSAiUkYgRW52aXJvbm1lbnQiIGlz IGFuIHVuYWNjZXB0YWJsZSBpbXBhY3QuJm5ic3A7Jm5ic3A7IFdlIGhhZCB0cm91YmxlIHdpdGgg dGhpcyBhcmd1bWVudCB3aGVuIHRoZSBpbnRlbnRpb25hbCByYWRpYXRvciBUWCBsaW1pdCB3YXMg YmVsb3cgdGhlIG1heGltdW0gdW5pbnRlbnRpb25hbCBlbWlzc2lvbiBsaW1pdHMgZm9yIG1vc3Qg bm9uLXRyYW5zbWl0dGluZyBkZXZpY2VzICgtNDEuM2RCbSkuDQo8YnI+DQo8YnI+DQpTbyBpdCB3 b3VsZCBiZSBmYWlybHkgaW1wb3J0YW50IHRvIGVuc3VyZSBhIGRldmljZSBkb2VzIG5vdCBpbnRl cnByZXQgLTMzZEJtIGFzIGl0J3Mgb2sgdG8gdXNlIHRoYXQgY2hhbm5lbCBzbyBsb25nIGFzIGl0 J3MgVFggcG93ZXIgaXMgYmVsb3cgLTMzZEJtLjxicj4NCjxicj4NCkkgbWF5IGJlIG9mZiBiYXNl IGhlcmUgYmVjYXVzZSBvZiZuYnNwOyBob3cgeSdhbGwgc2VlIHRoZSBEQiBwcm92aWRpbmcgYW5k IHdoYXQgSSBhbSBleHBlY3RpbmcgdG8gc3VwcG9ydCBmdXR1cmUgbmVlZHMuICJwcm90ZWN0ZWQg dXNlcnMiIGluY2x1ZGVzIG1vcmUgdGhhbiBUViBzdGF0aW9ucyBpbiB0aGUgVVMuJm5ic3A7DQo8 YnI+DQo8YnI+DQpOb3Qgc3VyZSB0aGF0IGhlbHBzLCBidXQgaG9wZSBzby4mbmJzcDsgPG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhlIGFkdmFudGFnZSBv ZiBoYXZpbmcgYW4gIndlbGwgYmVoYXZlZCIgc3BlY3RydW0gcHJvZmlsZSZuYnNwOyhjb250aWd1 b3VzIGFuZCB3aXRob3V0IHNwZWNpYWwgdmFsdWVzIGxpa2UgLWluZikmbmJzcDtpcyB0aGF0IHRo ZSBjaGFubmVsIHNlbGVjdGlvbiBhbGdvcml0aG0gb24gdGhlIFdTRHMgYmVjb21lcyBtdWNoIHNp bXBsZXINCiBhbmQgbG9naWNhbC4gJm5ic3A7VGhlcmUncyBubyBuZWVkIHRvIGhhdmUgbG90cyBv ZiBzcGVjaWFsIGJvdW5kYXJ5IGNvbmRpdGlvbiBjaGVja3MgYW5kIGNvZGUgcGF0aHMgdGhhdCBv bmx5IGdldCB0cmlnZ2VyZWQgdW5kZXIgc3BlY2lhbCBjaXJjdW1zdGFuY2VzLiAmbmJzcDtJJ2Qg bGlrZSB0byBhdm9pZCBhbWJpZ3VvdXMgaW50ZXJwcmV0YXRpb25zIG9uIHRoZSBkZXZpY2Ugc2lk ZSBhcyBtdWNoIGFzIHBvc3NpYmxlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21hcmdpbi1ib3R0b206MTIuMHB0Ij5DZXJ0YWlubHkgYW1iaWd1b3VzIGludGVycHJldGF0aW9u cyBvbiB0aGUgZGV2aWNlIHNpZGUgYXJlIGEgYmFkIHRoaW5nLg0KPGJyPg0KPGJyPg0KU29tZSBh cHBzIGFyZSBhZ2dyZWdhdGluZyBtdWx0aXBsZSBUViBjaGFubmVscyB0byBnZXQgYSBsb2dpY2Fs IGNoYW5uZWwgdGhhdCB0aGF0IGNhbiBjYXJyeSBhICd3aWRlJyZuYnNwOyBkYXRhIHBpcGUuIE90 aGVyIHVzZXMgY2FuIGZpdCBtYW55IHVzZWZ1bCBjaGFubmVscyBpbiBvbmUgVFYgY2hhbm5lbC4g SW4gODAyLjE1LjRtIHdlIGRpdmlkZSB0aGUgVFYgY2hhbm5lbCB1cCBpbnRvIG11bHRpcGxlIHBo eXNpY2FsIGNoYW5uZWxzIGNhcnJ5aW5nIGxvdw0KIGRhdGEgcmF0ZSBzaWduYWxzLiZuYnNwOyBS aWdodCBub3cgd2UgYXNzdW1lIGEgcGVhayBwb3dlciBsZXZlbCBmb3IgdGhlIFRWIGNoYW5uZWws IGFuZCB3ZSBnZXQgdGhhdCB2YWx1ZSB3aXRoIHRoZSBzdGFydCBmcmVxdWVuY3kgYW5kIHdpZHRo IChvciBlbmQgZnJlcXVlbmN5KSBmcm9tIHRoZSBkYXRhYmFzZS4gSG93ZXZlciwgSSd2ZSBoZWFy ZCBpdCBwcm9wb3NlZCB0byB0aGUgRkNDIHRoYXQgd2UgbWF5IGdldCBkaWZmZXJlbnQgcG93ZXIg bGltaXRzDQogZGlmZmVyZW50IHBhcnRzIG9mIHRoZSBUViBjaGFubmVsLCBjaGFuZ2luZyBvdmVy IHRpbWUsIGFzIGEgcHJvdGVjdGlvbiBtZWNoYW5pc20gZm9yIGRlYWwgd2l0aCBuYXJyb3cgYmFu ZCBwcm90ZWN0ZWQgdXNlcnMgd2hpbGUgYWxsb3dpbmcgZWZmZWN0aXZlIHVzZSBvZiB0aGUgcmVz dCBvZiB0aGUgVFYgY2hhbm5lbC4mbmJzcDsgRm9yIHdoYXQgd2UgZG8sIHRoaXMgaXMgYSBnb29k IHRoaW5nIC0gb3VyIHBoeXNpY2FsIGNoYW5uZWwgbWF5IGJlIGxlc3MNCiB0aGFuIDIwMGtIeiB3 aWRlLiBUaGVyZSBhcmUgYSBMT1Qgb2YgYXBwbGljYXRpb25zJm5ic3A7IGluIElvVCB0aGF0IG5l ZWQgJmx0OyAyMDBrSHogY2hhbm5lbHMsJm5ic3A7IGFuZCBibG9ja2luZyBhbiBlbnRpcmUgVFYg Y2hhbm5lbCB0byBwcm90ZWN0IGEgd2lyZWxlc3MgbWljcm9waG9uZSB1c2luZyAmbHQ7IDIwMGtI eiBvZiBpdCBtZWFucyB0aGVyZSBhcmUgMjggb3RoZXIgdXNhYmxlIGNoYW5uZWxzJm5ic3A7IG5v dCBiZWluZyB1c2VkIC0gbm90IGVmZmljaWVudCB1c2Ugb2YNCiB0aGUgc3BlY3RydW0uJm5ic3A7 Jm5ic3A7IDxicj4NCjxicj4NCkhvcGUgdGhpcyBoZWxwcy4mbmJzcDsmbmJzcDsgPGJyPg0KPGJy Pg0KLUJlbjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzJnF1b3Q7LCZx dW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8dGFibGUgY2xh c3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxzcGFjaW5nPSIwIiBjZWxscGFkZGlu Zz0iMCI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgbm93cmFwPSIiIHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItdG9wOnNvbGlkICNENTBGMjUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiAwaW4iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNTU1NTU1Ij5BbmR5IExlZSZu YnNwO3w8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIG5vd3JhcD0iIiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjMzM2OUU4IDEuNXB0O3BhZGRpbmc6MGluIDBp biAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzU1NTU1 NSI+Jm5ic3A7R29vZ2xlIEluYy4gfDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQg bm93cmFwPSIiIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICMwMDk5MzkgMS41 cHQ7cGFkZGluZzowaW4gMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojNTU1NTU1Ij4mbmJzcDs8YSBocmVmPSJtYWlsdG86dHZmb29sQGdvb2dsZS5j b20iIHRhcmdldD0iX2JsYW5rIj50dmZvb2xAZ29vZ2xlLmNvbTwvYT4mbmJzcDt8PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCBub3dyYXA9IiIgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci10b3A6c29saWQgI0VFQjIxMSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDBpbiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM1NTU1NTUiPiZuYnNwOzxhIGhy ZWY9InRlbDo0MDgtMjMwLTA1MjIiIHRhcmdldD0iX2JsYW5rIj40MDgtMjMwLTA1MjI8L2E+PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21hcmdpbi1ib3R0b206MTIuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPk9uIFRodSwgU2VwIDE5LCAyMDEzIGF0IDg6MzAgQU0sIFJheSBC ZWxsaXMgJmx0OzxhIGhyZWY9Im1haWx0bzpSYXkuQmVsbGlzQG5vbWluZXQub3JnLnVrIiB0YXJn ZXQ9Il9ibGFuayI+UmF5LkJlbGxpc0Bub21pbmV0Lm9yZy51azwvYT4mZ3Q7IHdyb3RlOjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YnI+DQpPbiAxOSBTZXAgMjAxMywg YXQgMTY6MjEsIEFuZHkgTGVlICZsdDs8YSBocmVmPSJtYWlsdG86dHZmb29sQGdvb2dsZS5jb20i IHRhcmdldD0iX2JsYW5rIj50dmZvb2xAZ29vZ2xlLmNvbTwvYT4mZ3Q7PG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij4mbmJzcDt3cm90ZTo8YnI+DQo8YnI+DQomZ3Q7IFRo aXMgYWN0dWFsbHkgc2hvd3MgdGhhdCBPZmNvbSBoYXMgcGlja2VkIGEgcG93ZXIgdGhyZXNob2xk IG9uIGNoYW5uZWwgMzggb2YgLTMzIGRCbS4gJm5ic3A7SWYgeW91IGxvb2sgYXQgdGhlIEFDTFIg bnVtYmVycyBmb3IgY2xhc3MgMywgNCwgYW5kIDUgZGV2aWNlcywgeW91J2xsIHNlZSB0aGV5IGFy ZSAxMCBkQiBhcGFydCBmcm9tIGVhY2ggb3RoZXIgYW5kIHRoYXQgdGhleSBhbGwgd29yayBvdXQg dG8gYmUgLTMzIGRCbSBvbiBjaGFubmVsIDM4Ljxicj4NCiZndDs8YnI+DQomZ3Q7IFRoZSByZWFz b24gdGhlcmUgYXJlIG5vIGxpbWl0cyBmb3IgY2xhc3MgMSBhbmQgMiBkZXZpY2VzIGlzIGJlY2F1 c2UgdGhlIGluLWJhbmQgcG93ZXIgb24gY2hhbm5lbHMgMzcgYW5kIDM5IGNhbm5vdCBleGNlZWQg KzM2IGRCbS84TUh6LCBhbmQgdGhlcmVmb3JlIHRoZSBwb3dlciBvbiBjaGFubmVsIDM4IHdpbGwg bmF0dXJhbGx5IGJlIGxlc3MgdGhhbiAtMzMgZEJtLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2lu LWJvdHRvbToxMi4wcHQiPlRoZSBtYXRoIGJlYXJzIHRoYXQgb3V0LCBidXQgbm9uZXRoZWxlc3Mg T0ZDT00gYXJlIHN0aWxsIGVmZmVjdGl2ZWx5IHByb3Bvc2luZyB0aGF0ICpubyogaW4tYmxvY2sg dHJhbnNtaXNzaW9ucyBhcmUgYWxsb3dlZCBpbiB0aGF0IGNoYW5uZWwuPGJyPg0KPGJyPg0KUGVy IE9GQ09NIC8gRVRTSSBkZXZpY2UgaW50ZXJmYWNlIHJlcXVpcmVtZW50cyBpdCB3b3VsZCBiZSBp bmNvcnJlY3QgZm9yIHVzIHRvIGFjdHVhbGx5IHNlbmQgdGhhdCB2YWx1ZSBvZiAtMzMgZEJtIHRv IGEgZGV2aWNlLjxicj4NCjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij48YnI+DQpSYXk8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cHJlPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3ByZT4NCjxwcmU+cGF3cyBtYWlsaW5nIGxp c3Q8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJtYWlsdG86cGF3c0BpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPnBhd3NAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+ PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wYXdzIiB0YXJn ZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wYXdzPC9h PjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpwYXdzIG1haWxpbmcg bGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpwYXdzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ cGF3c0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3Bhd3MiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3Bhd3M8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KDQoNCjwvZGl2 PjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48ZGl2PjxzcGFuPl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPC9zcGFuPjxicj48c3Bhbj5w YXdzIG1haWxpbmcgbGlzdDwvc3Bhbj48YnI+PHNwYW4+PGEgaHJlZj0ibWFpbHRvOnBhd3NAaWV0 Zi5vcmciPnBhd3NAaWV0Zi5vcmc8L2E+PC9zcGFuPjxicj48c3Bhbj48YSBocmVmPSJodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bhd3MiPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vcGF3czwvYT48L3NwYW4+PGJyPjwvZGl2PjwvYmxvY2txdW90ZT48 L2JvZHk+PC9odG1sPg== --_000_C31A91B2C81F417AA1D982067EDF2B5Bspectrumbridgecom_-- From Ray.Bellis@nominet.org.uk Mon Sep 23 02:20:38 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A302711E8182 for ; Mon, 23 Sep 2013 02:20:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.165 X-Spam-Level: X-Spam-Status: No, score=-9.165 tagged_above=-999 required=5 tests=[AWL=-0.426, BAYES_20=-0.74, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qR7uZOoAJ1-o for ; Mon, 23 Sep 2013 02:20:32 -0700 (PDT) Received: from mx1.nominet.org.uk (mx1.nominet.org.uk [213.248.242.48]) by ietfa.amsl.com (Postfix) with ESMTP id 3F72421F9EE1 for ; Mon, 23 Sep 2013 02:20:21 -0700 (PDT) DomainKey-Signature: s=main2.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:X-IPAS-Result:Received:Received:From:To:CC: Subject:Thread-Topic:Thread-Index:Date:Message-ID: References:In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:x-originating-ip: Content-Type:MIME-Version; b=Oc4LzqYpJoYRd4zVJF0MjwETPbzImeMCOomVEA1tLnb0rO1rkkM4fU1M 5t+eEOuHQq3/Pd9IESwx180SfpDGDHOuJW7y9jzzsWineZHMkSdUo9Fas iXeMPNX4bwTdyucj3WCiigE7ypQ1j8/+28n9SUOYon3UI0AeOcKq1pdQd DpvIOEPBKQn7bU6F1EtyeBsCOYF/98i+5G82bPa8vZ8PrV0cSut81yyUT ekczrLB2k50OwglsRSWlIxDLB/3vD; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=@nominet.org.uk; q=dns/txt; s=main2.dkim.nominet.selector; t=1379928021; x=1411464021; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=lJ1TOw+bx9lEF9ZM28amH7ZVpf19XePGGLHXdKGE4+4=; b=fC13TW18pJwTV2a3lGtEJI7kxs0exGEq7nGnWTKhTFzbBnWm1IIUv5RF ynSGPn32JxnL2qCm0OpiuZsKrkVm8HfF4lRh0NN93E6jnixufP1WHipNC P0/9G/FWJ2g1FY82Y/zi7+5Mv/pTDjQ3cvKxqI+md7OH8bej4E2p8Z5vA VOqG/1l6kC8Wi8ywKZH3L3FnFiPUBVg4brYY7bcHuv5B/Te28FJEd4rpn DdakWmclOOi+ReWTa12Uc0tr7THdJ; X-IronPort-AV: E=Sophos;i="4.90,960,1371078000"; d="scan'208,217";a="3514221" X-IPAS-Result: ArsFAKYGQFLV+MWR/2dsb2JhbABZgkMjIYEKwTCBGxZtB4ImAQEEUyYQAgEIIh0HMhQRAgQOBQiHfgO6PI80MQYBgx6BAAOpc4Mkgio Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx1.nominet.org.uk with ESMTP; 23 Sep 2013 10:20:18 +0100 Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4%17]) with mapi id 14.02.0318.004; Mon, 23 Sep 2013 10:20:18 +0100 From: Ray Bellis To: "Gabor.Bajko@nokia.com" Thread-Topic: [paws] Spectrum encoding discussion Thread-Index: AQHOtLJH/FWG06ATlUqxs+HiIH56lZnMyBoAgABHaYCAAAbdgIAAB1CAgAACXwCAAAsCAIABLRqAgAClvgCAAA8sAIAAC1UAgAAa+QCAABHGgIAAFUOAgAOnp4A= Date: Mon, 23 Sep 2013 09:20:16 +0000 Message-ID: <53F00E5CD8B2E34C81C0C89EB0B4FE732DEABFA0@wds-exc1.okna.nominet.org.uk> References: <1ECAFF543A2FED4EA2BEB6CACE08E476053422B0@008-AM1MPN1-006.mgdnok.nokia.com> <1ECAFF543A2FED4EA2BEB6CACE08E47605342356@008-AM1MPN1-006.mgdnok.nokia.com> In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E47605342356@008-AM1MPN1-006.mgdnok.nokia.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.2.1] Content-Type: multipart/alternative; boundary="_000_53F00E5CD8B2E34C81C0C89EB0B4FE732DEABFA0wdsexc1oknanomi_" MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] Spectrum encoding discussion X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 09:20:39 -0000 --_000_53F00E5CD8B2E34C81C0C89EB0B4FE732DEABFA0wdsexc1oknanomi_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On 21 Sep 2013, at 02:31, Gabor.Bajko@nokia.com wrote: Few things to consider: 1. I think we first have to agree whether we need at all to encode an= =91unavailable channel=92. Current draft section 4.4.2 says: =93The respon= se message for the Available Spectrum Query contains a schedule of available spectrum for the Device.=94 To me this means that = channels which are not listed are implicitly unavailable and leakage into u= navailable spectrum has to conform to the rules. +1 2. If one wants to be explicit on what the rules say for the leakage = limits, then we can encode those into the rulesetInfo. +1 3. If we take on Andy=92s argument that PAWS could be used outside TV= WS, *and* leakage limits may potentially be different for different bands w= ithin the same regulatory domain, then encoding all those bands and leakage= limits into rulesetInfo might just complement what is missing from the ava= ilable spectrum response and we may be better off just encoding everything = into available spectrum response. 1 and 2 doesn=92t require an encoding for unavailable channel. Simply not l= isting it as available does the job. Agreed! [but with the caveat, as I've been arguing all along, that encodi= ng option #2 doesn't permit that] 3 would require us to agree how to encode unavailable channel, but the WSD = would still need to know what the emission limits are in that regulatory do= main for the unavailable channels. I believe Andy wants to encode "band edge info" (i.e. to supply information= about the four non-contiguous frequency ranges that the US TV channels fit= into). Would that fit in your proposed rulesetInfo enhancement in point #= 3? kind regards, Ray --_000_53F00E5CD8B2E34C81C0C89EB0B4FE732DEABFA0wdsexc1oknanomi_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
On 21 Sep 2013, at 02:31, Gab= or.Bajko@nokia.com wrote:

Few things to consider:

 


1. &nbs=
p;     I think w=
e first have to agree whether we need at all to encode an =91unavailable ch=
annel=92. Current draft section 4.4.2 says: =93The response message =
for the Available Spectrum Query contains a



   =
schedule of available spectrum for the Device.=94 =
To me this means that channels which are not listed
 are implicitly unavailable and leakage into unavailable spectrum has to co=
nform to the rules.

+1
 
2.       If one wants to be explicit on what the rules say for the leakage limits, the= n we can encode those into the rulesetInfo.

+1

 
3.       If we take on Andy=92s argument that PAWS could be used outside TVWS, *and= * leakage limits may potentially be different for different bands withi= n the same regulatory domain, then encoding all those bands and leakage lim= its into rulesetInfo might just complement what is missing from the available spectrum response and we may be better = off just encoding everything into available spectrum response.
 
1 and 2 doesn=92t require an encoding for unavailable cha= nnel. Simply not listing it as available does the job.

Agreed!   [but with the caveat, as I've been arguing all along, that e= ncoding option #2 doesn't permit that]

3 would require us to agree how to encode unavailable cha= nnel, but the WSD would still need to know what the emission limits are in = that regulatory domain for the unavailable channels.

I believe Andy wants to encode "band edge info" (i.e. to sup= ply information about the four non-contiguous frequency ranges that the US = TV channels fit into).  Would that fit in your proposed rulesetInfo en= hancement in point #3?

kind regards,

Ray

--_000_53F00E5CD8B2E34C81C0C89EB0B4FE732DEABFA0wdsexc1oknanomi_-- From dharasty@appcomsci.com Mon Sep 23 06:20:48 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A802421F9C0E for ; Mon, 23 Sep 2013 06:20:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.843 X-Spam-Level: X-Spam-Status: No, score=-0.843 tagged_above=-999 required=5 tests=[AWL=-0.104, BAYES_20=-0.74, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GulM190RXIos for ; Mon, 23 Sep 2013 06:20:40 -0700 (PDT) Received: from thumper.appcomsci.com (thumper.appcomsci.com [205.132.0.196]) by ietfa.amsl.com (Postfix) with ESMTP id 8C05B21F8790 for ; Mon, 23 Sep 2013 06:20:38 -0700 (PDT) Received: from bambi.appcomsci.com (bambi.appcomsci.com [192.4.5.54]) by thumper.appcomsci.com (8.14.2/8.14.2) with ESMTP id r8NDKbF7003691 for ; Mon, 23 Sep 2013 09:20:37 -0400 (EDT) Received: from brg-ats-exhb1.ats.atsinnovate.com (exch.appcomsci.com [192.4.5.112]) by bambi.appcomsci.com (8.14.4/8.13.4) with ESMTP id r8NDKblw031921 for ; Mon, 23 Sep 2013 09:20:37 -0400 Received: from RRC-ATS-EXMB2.ats.atsinnovate.com ([2002:c004:56a::c004:56a]) by brg-ats-exhb1.ats.atsinnovate.com ([2002:c004:570::c004:570]) with mapi; Mon, 23 Sep 2013 09:20:37 -0400 From: "Harasty, Daniel J" To: "paws@ietf.org" Thread-Topic: "unavailable" vs "no information" Thread-Index: Ac64X7CP/99v4WWKS9qoCDPV6Zb/qA== Date: Mon, 23 Sep 2013 13:20:37 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_EC510C021D06A34C92F5A5A488B5290B0CF2FB2Crrcatsexmb2atsa_" MIME-Version: 1.0 Subject: [paws] "unavailable" vs "no information" X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 13:20:48 -0000 --_000_EC510C021D06A34C92F5A5A488B5290B0CF2FB2Crrcatsexmb2atsa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Gabor Bajko mentioned: I think we first have to agree whether we need at all to encode an 'unavail= able channel'. Current draft section 4.4.2 says: "The response message for = the Available Spectrum Query contains a schedule of available spectrum for = the Device." To me this means that channels which are not listed are implic= itly unavailable and leakage into unavailable spectrum has to conform to th= e rules. I agree that "no mention of a segment of spectrum as available" is a possib= le way to express "it is unavailable". Let's call this "implicit unavailab= ility". However, if I'm a Device, and I received a SPECTRUM_AVAIL_RESP that says "C= hannel 17 is available until 6pm" (and nothing else is mentioned about Chan= nel 17 for the time period after 6pm)... does that mean "Channel 17 is unav= ailable after 6pm" or "I have no information about Channel 17 after 6pm (ma= ybe it is available, maybe it's not)"? Thus I propose that we still need some sort of "explicit unavailable" notat= ion, and "no mention" should be reserved to express "there is no informatio= n about this piece of spectrum in this time period - ask again later". Stated another way: I propose that PAWS is better off if the Database has s= ome way to express the difference between "channel unavailable" and "no inf= ormation given about this channel [in this time period]". Perhaps the "i= mplicit unavailability" approach could be made to work by then ADDING more = fields to the event structures, like "response valid through" or "response = expiration" values... but I find that more convoluted than a "explicit unav= ailable" notation, which can express "this bit of spectrum is unavailable i= n this time period". Dan Harasty --_000_EC510C021D06A34C92F5A5A488B5290B0CF2FB2Crrcatsexmb2atsa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Gabor Baj= ko mentioned:

 <= /o:p>

I th= ink we first have to agree whether we need at all to encode an ‘unava= ilable channel’. Current draft section 4.4.2 says: “The respons= e message for the Available Spectrum Query contains a schedule of available= spectrum for the Device.” To me this means that channels which are n= ot listed are implicitly unavailable and leakage into unavailable spectrum = has to conform to the rules.

 

I agree that = 220;no mention of a segment of spectrum as available” is a possible w= ay to express “it is unavailable”.  Let’s call this = “implicit unavailability”.

 

Howe= ver, if I’m a Device, and I received a SPECTRUM_AVAIL_RESP that says = “Channel 17 is available until 6pm” (and nothing else is mentio= ned about Channel 17 for the time period after 6pm)… does that mean &= #8220;Channel 17 is unavailable after 6pm” or “I = have no information about Channel 17 after 6pm (maybe it is a= vailable, maybe it’s not)”?

 

Thus= I propose that we still need some sort of “explicit unavailable̶= 1; notation, and “no mention” should be reserved to express = 220;there is no information about this piece of spectrum in this time perio= d – ask again later”.

 

Stated anot= her way: I propose that PAWS is better off if the Database has some way to = express the difference between "channel unavailable" and "no= information given about this channel [in this time period]".  &n= bsp; Perhaps the “implicit unavailability” approach could = be made to work by then ADDING more fields to the event structures, like &#= 8220;response valid through” or “response expiration” val= ues… but I find that more convoluted than a “explicit unavailab= le” notation, which can express “this bit of spectrum is unavai= lable in this time period”.

 

Dan Harasty=

 <= /p>

= --_000_EC510C021D06A34C92F5A5A488B5290B0CF2FB2Crrcatsexmb2atsa_-- From james@talkunafraid.co.uk Mon Sep 23 06:35:58 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C92A21F9F03 for ; Mon, 23 Sep 2013 06:35:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fOoGzPwDuiEA for ; Mon, 23 Sep 2013 06:35:48 -0700 (PDT) Received: from caconym.talkunafraid.co.uk (pandora.mmmetrics.co.uk [94.229.74.162]) by ietfa.amsl.com (Postfix) with ESMTP id 4ECE321F8BFD for ; Mon, 23 Sep 2013 06:35:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by caconym.talkunafraid.co.uk (Postfix) with ESMTP id 65D7459C25E0 for ; Mon, 23 Sep 2013 14:35:45 +0100 (BST) X-Virus-Scanned: Debian amavisd-new at no.rdns-yet.ukservers.com Received: from caconym.talkunafraid.co.uk ([127.0.0.1]) by localhost (caconym.talkunafraid.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f46dBDIZhU7L for ; Mon, 23 Sep 2013 14:35:44 +0100 (BST) Received: from [132.185.132.11] (gateb.kw.bbc.co.uk [132.185.132.11]) by caconym.talkunafraid.co.uk (Postfix) with ESMTPSA id 2EEAE59C2560 for ; Mon, 23 Sep 2013 14:35:43 +0100 (BST) Message-ID: <524043B5.5090201@talkunafraid.co.uk> Date: Mon, 23 Sep 2013 14:35:49 +0100 From: James Harrison User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: paws@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------090503000101050106060601" Subject: Re: [paws] "unavailable" vs "no information" X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 13:35:58 -0000 This is a multi-part message in MIME format. --------------090503000101050106060601 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 23/09/13 14:20, Harasty, Daniel J wrote: > > Thus I propose that we still need some sort of "explicit unavailable" > notation, and "no mention" should be reserved to express "there is no > information about this piece of spectrum in this time period -- ask > again later". > > Stated another way: I propose that PAWS is better off if the Database > has some way to express the difference between "channel unavailable" > and "no information given about this channel [in this time period]". > Perhaps the "implicit unavailability" approach could be made to work > by then ADDING more fields to the event structures, like "response > valid through" or "response expiration" values... but I find that more > convoluted than a "explicit unavailable" notation, which can express > "this bit of spectrum is unavailable in this time period". > > (First time poster, not-a-long-time lurker - hello! Do excuse me if I've missed anything...) I'm not sure I can see the situation where, as a DB operator, I would want to say "I don't have anything to say about this piece of spectrum in this time period". Either I can allocate that spectrum - in which case I'd be providing freq/power data - or I can't, either for regulatory reasons or operational reasons (regulator-triggered shutdown, DB maintainence, etc). Lack of definition in a response should always imply the spectrum is unavailable, in my opinion. That said - I don't see a huge issue in adding a way to express the "no information available" case if there's a use-case to support that. But I think that should be a distinct note against some spectrum, with "not present in response" reserved for "explicitly unavailable". Cheers, James Harrison --------------090503000101050106060601 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 23/09/13 14:20, Harasty, Daniel J wrote:

Thus I propose that we still need some sort of “explicit unavailable” notation, and “no mention” should be reserved to express “there is no information about this piece of spectrum in this time period – ask again later”.

 

Stated another way: I propose that PAWS is better off if the Database has some way to express the difference between "channel unavailable" and "no information given about this channel [in this time period]".    Perhaps the “implicit unavailability” approach could be made to work by then ADDING more fields to the event structures, like “response valid through” or “response expiration” values… but I find that more convoluted than a “explicit unavailable” notation, which can express “this bit of spectrum is unavailable in this time period”.

 


(First time poster, not-a-long-time lurker - hello! Do excuse me if I've missed anything...)

I'm not sure I can see the situation where, as a DB operator, I would want to say "I don't have anything to say about this piece of spectrum in this time period". Either I can allocate that spectrum - in which case I'd be providing freq/power data - or I can't, either for regulatory reasons or operational reasons (regulator-triggered shutdown, DB maintainence, etc).

Lack of definition in a response should always imply the spectrum is unavailable, in my opinion.

That said - I don't see a huge issue in adding a way to express the "no information available" case if there's a use-case to support that. But I think that should be a distinct note against some spectrum, with "not present in response" reserved for "explicitly unavailable".

Cheers,
James Harrison
--------------090503000101050106060601-- From peter@spectrumbridge.com Mon Sep 23 07:00:50 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A9DC21F89A6 for ; Mon, 23 Sep 2013 07:00:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.648 X-Spam-Level: X-Spam-Status: No, score=-0.648 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rmBm4xaIM38g for ; Mon, 23 Sep 2013 07:00:45 -0700 (PDT) Received: from mail.spectrumbridge.com (mail.spectrumbridge.com [64.132.248.82]) by ietfa.amsl.com (Postfix) with ESMTP id CE96B21F8F61 for ; Mon, 23 Sep 2013 07:00:28 -0700 (PDT) Received: from shelby.sbi.com ([127.0.0.1]) by shelby ([127.0.0.1]) with mapi; Mon, 23 Sep 2013 10:00:28 -0400 From: Peter Stanforth To: "Harasty, Daniel J" , "paws@ietf.org" Date: Mon, 23 Sep 2013 10:00:27 -0400 Thread-Topic: [paws] "unavailable" vs "no information" Thread-Index: Ac64ZUHJKhFynbvvSqa9QAk+GAUP/Q== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.7.130812 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CE65B92C189C8peterspectrumbridgecom_" MIME-Version: 1.0 Subject: Re: [paws] "unavailable" vs "no information" X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 14:00:50 -0000 --_000_CE65B92C189C8peterspectrumbridgecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Speaking as a database provider who has been certified, and someone who has= helped a number of radios get FCC certification I have to suggest your int= erpretation is wrong. There is no ambiguity as far as the FCC is concerned, and conversations wi= th IDA, IC, and Ofcom lead to a similar conclusion. >From the Regulator perspective, the database provides a list of channels th= at are available and anything that is not specifically identified as availa= ble is unavailable =96 period. There is no notion, to use your example, that channel 17 is undefined after= 6pm. The database told you you can only use it till 6pm. At 6pm you can q= uery the database and you may be told that it is available. Does this mean = it was always available? Absolutely not, but at the time of the original qu= ery it was unavailable. I also have to deal with the situation where I am = required to tell a device "no channels available". At the time I give that= answer it is unambiguous. If the device asks again later it may, or may no= t, get the same answer. I don't understand how I do this if we are returnin= g a complete "channel list" with any kind of emission criteria, and satisfy= the Regulator that we are doing what we are required to do. As I have said previously the database is not the enforcer or the decision = maker. It simply provides information based on the Regulator rules and poli= cy. I have found this is not open to debate. In most countries Regulators = are not allowed to delegate or abdicate responsibility for spectrum managem= ent. We exist, as a database provider, by acting as an agent or subcontract= or to the Regulator (depending on the domain). We are not permitted to make= interpretations or make decisions. We simply implement their rules. Maybe = this will change in the future but this is the environment we operate in to= day. As far as spectrum availability is concerned I think the current specificat= ion allows us to comply with all the known regulatory environments we are a= ware of. Including vague notions around implicit, or maybe, concepts not on= ly give me concern about how I comply with the agreement I have in place wi= th the regulator, it is likely to give the incumbents fits. We have enough = fights with the incumbents today even with the simple definition that exist= . Suggesting that the database is "interpreting" anything simply makes the = likelihood of spectrum sharing in whitespace less likely. All that being said. I go back to my other concern, which is that this is t= aking way too long. Based on the original charter we should be done by now.= So even though I think some of these ideas are academically interesting, = and maybe in the longer term future of PAWS. I really want to get a PAWS pr= otocol finished that supports the TVWS activities that are percolating arou= nd the world. To paraphrase Voltaire I strongly believe that an imperfect, = but finished, PAWS protocol sends a stronger message of industry commitment= to wanting access to TVWS and spectrum sharing than continuing to debate w= hat PAWS maybe one day. Peter S From: , Daniel J > Date: Monday, September 23, 2013 9:20 AM To: "paws@ietf.org" > Subject: [paws] "unavailable" vs "no information" Gabor Bajko mentioned: I think we first have to agree whether we need at all to encode an =91unava= ilable channel=92. Current draft section 4.4.2 says: =93The response messag= e for the Available Spectrum Query contains a schedule of available spectru= m for the Device.=94 To me this means that channels which are not listed ar= e implicitly unavailable and leakage into unavailable spectrum has to confo= rm to the rules. I agree that =93no mention of a segment of spectrum as available=94 is a po= ssible way to express =93it is unavailable=94. Let=92s call this =93implic= it unavailability=94. However, if I=92m a Device, and I received a SPECTRUM_AVAIL_RESP that says = =93Channel 17 is available until 6pm=94 (and nothing else is mentioned abou= t Channel 17 for the time period after 6pm)=85 does that mean =93Channel 17= is unavailable after 6pm=94 or =93I have no information about Channel 17 a= fter 6pm (maybe it is available, maybe it=92s not)=94? Thus I propose that we still need some sort of =93explicit unavailable=94 n= otation, and =93no mention=94 should be reserved to express =93there is no = information about this piece of spectrum in this time period =96 ask again = later=94. Stated another way: I propose that PAWS is better off if the Database has s= ome way to express the difference between "channel unavailable" and "no inf= ormation given about this channel [in this time period]". Perhaps the = =93implicit unavailability=94 approach could be made to work by then ADDING= more fields to the event structures, like =93response valid through=94 or = =93response expiration=94 values=85 but I find that more convoluted than a = =93explicit unavailable=94 notation, which can express =93this bit of spect= rum is unavailable in this time period=94. Dan Harasty --_000_CE65B92C189C8peterspectrumbridgecom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Speaking as a database provider= who has been certified, and someone who has helped a number of radios get = FCC certification I have to suggest your interpretation is  wrong.
There is no ambiguity as far as the FCC is concerned, and  conv= ersations with IDA, IC, and Ofcom lead to a similar conclusion.
F= rom the Regulator perspective, the database provides a list of channels tha= t are available and anything that is not specifically identified as availab= le is unavailable =96 period.
There is no notion, to use your exa= mple, that channel 17 is undefined after 6pm. The database told you you can= only use it till 6pm.  At 6pm you can query the database and you may = be told that it is available. Does this mean it was always available? Absol= utely not, but at the time of the original query it was unavailable.  = I also have to deal with the situation where I am required to tell a device= "no channels available".  At the time I give that answer it= is unambiguous. If the device asks again later it may, or may not, get the= same answer. I don't understand how I do this if we are returning a comple= te "channel list" with any kind of emission criteria, and satisfy= the Regulator that we are doing what we are required to do.

=
As I have said previously the database is not the enforcer or th= e decision maker. It simply provides information based on the Regulator rul= es and policy.  I have found this is not open to debate. In most count= ries Regulators are not allowed to delegate or abdicate responsibility for = spectrum management. We exist, as a database provider, by acting as an agen= t or subcontractor to the Regulator (depending on the domain). We are not p= ermitted to make interpretations or make decisions. We simply implement the= ir rules. Maybe this will change in the future but this is the environment = we operate in today.

As far as spectrum availabili= ty is concerned I think the current specification allows us to comply with = all the known regulatory environments we are aware of. Including vague noti= ons around implicit, or maybe, concepts not only give me concern about how = I comply with the agreement I have in place with the regulator, it is likel= y to give the incumbents fits. We have enough fights with the incumbents to= day even with the simple definition that exist. Suggesting that the databas= e is "interpreting" anything simply makes the likelihood of spect= rum sharing in whitespace less likely.

All that be= ing said. I go back to my other concern, which is that this is taking way t= oo long. Based on the original charter we should be done by now. So even th= ough I think some of these ideas are academically  interesting, and ma= ybe in the longer term future of PAWS. I really want to get a PAWS protocol= finished that supports the TVWS activities that are percolating around the= world. To paraphrase Voltaire I strongly believe that an imperfect, but fi= nished, PAWS protocol sends a stronger message of industry commitment to wa= nting access to TVWS and spectrum sharing than continuing to debate what PA= WS maybe one day.

Peter S


From: <Harasty&= gt;, Daniel J <dharasty@appcom= sci.com>
Date: Monday, S= eptember 23, 2013 9:20 AM
To: &= quot;paws@ietf.org" <paws@ietf.org>
Subject: [paws] "unavailable" vs "no inform= ation"

Gabor Bajko mentioned:

<= span style=3D"font-size: 11pt; color: rgb(31, 73, 125); font-family: Calibr= i, sans-serif; "> 

I think we first have to agree whet= her we need at all to encode an =91unavailable channel=92. Current draft se= ction 4.4.2 says: =93The response message for the Available Spectrum Query contains a schedule of available = spectrum for the Device.=94 To me this means that channels which are not li= sted are implicitly unavailable and leakage into unavailable spectrum has t= o conform to the rules.

 

I agree that =93no mention of a segment of spectrum as available=94 = is a possible way to express =93it is unavailable=94.  Let=92s call th= is =93implicit unavailability=94.

 

However, if I=92m a Device, and I received a SPECTRUM_AVAIL_= RESP that says =93Channel 17 is available until 6pm=94 (and nothing else is= mentioned about Channel 17 for the time period after 6pm)=85 does that mean =93Channel 17 is un= available after 6pm=94 or =93I have no information about Channel 17 after 6pm (maybe it is availa= ble, maybe it=92s not)=94?

 

Thus I propose that we still need some sort of =93explicit unavaila= ble=94 notation, and =93no mention=94 should be reserved to express =93ther= e is no information about this piece of spectrum in this time period =96 ask again later=94.

 

Stated another way: I prop= ose that PAWS is better off if the Database has some way to express the dif= ference between "channel unavailable" and "no information given about this channel [in this time period]".    Pe= rhaps the =93implicit unavailability=94 approach could be made to work by t= hen ADDING more fields to the event structures, like =93response valid thro= ugh=94 or =93response expiration=94 values=85 but I find that more convoluted than a =93explicit unavailable=94 notation, which can express = =93this bit of spectrum is unavailable in this time period=94.

 <= /p>

Dan Harasty

 

--_000_CE65B92C189C8peterspectrumbridgecom_-- From Cesar.Gutierrez@ofcom.org.uk Mon Sep 23 07:49:28 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C42F921F9F01 for ; Mon, 23 Sep 2013 07:49:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.108 X-Spam-Level: X-Spam-Status: No, score=-2.108 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kt43G1M3ZIah for ; Mon, 23 Sep 2013 07:49:23 -0700 (PDT) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.165]) by ietfa.amsl.com (Postfix) with ESMTP id C96F721F9F2B for ; Mon, 23 Sep 2013 07:49:15 -0700 (PDT) Received: from [85.158.137.83:53606] by server-5.bemta-3.messagelabs.com id 1F/73-23058-9E450425; Mon, 23 Sep 2013 14:49:13 +0000 X-Env-Sender: Cesar.Gutierrez@ofcom.org.uk X-Msg-Ref: server-2.tower-140.messagelabs.com!1379947752!23748881!1 X-Originating-IP: [194.33.160.65] X-StarScan-Received: X-StarScan-Version: 6.9.12; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15400 invoked from network); 23 Sep 2013 14:49:12 -0000 Received: from unknown (HELO WOK-INTRA-EDG02.intra.ofcom.local) (194.33.160.65) by server-2.tower-140.messagelabs.com with AES128-SHA encrypted SMTP; 23 Sep 2013 14:49:12 -0000 Received: from WOK-INTRA-EXC01.intra.ofcom.local (10.130.130.67) by WOK-INTRA-EDG02.intra.ofcom.local (10.130.239.20) with Microsoft SMTP Server (TLS) id 14.1.289.1; Mon, 23 Sep 2013 15:49:12 +0100 Received: from WOK-INTRA-EXC02.intra.ofcom.local ([fe80::550e:933d:224e:6a19]) by WOK-INTRA-EXC01.intra.ofcom.local ([fe80::f0b6:2506:a722:c58b%15]) with mapi id 14.01.0289.001; Mon, 23 Sep 2013 15:49:11 +0100 From: Cesar Gutierrez To: Peter Stanforth , "Harasty, Daniel J" , "paws@ietf.org" Thread-Topic: [paws] "unavailable" vs "no information" Thread-Index: Ac64X7CP/99v4WWKS9qoCDPV6Zb/qP//+l6A///tyoA= Date: Mon, 23 Sep 2013 14:49:11 +0000 Message-ID: <5D3E853BEE49C848BB63047C794C8655AE9CA837@WOK-INTRA-EXC02.intra.ofcom.local> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.131.249] Content-Type: multipart/alternative; boundary="_000_5D3E853BEE49C848BB63047C794C8655AE9CA837WOKINTRAEXC02in_" MIME-Version: 1.0 Subject: Re: [paws] "unavailable" vs "no information" X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 14:49:28 -0000 --_000_5D3E853BEE49C848BB63047C794C8655AE9CA837WOKINTRAEXC02in_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, Some views from the regulator's perspective including on the spectrum encod= ing issue. I recognise that some of this has been argued repeatedly and tha= t the discussion has moved on. * In the ETSI/Ofcom model, the databases only communicate maximum in= tentional power in each channel. Unwanted emissions are regulated via compl= iance with one of the classes defined in ETSI EN 301 598. So, if the DB say= s that a channel is not available, the a device must not have wanted emiss= ions on it. The device is allowed have "skirt" on it, but only up to the le= vels allowed by its emission class. * The DB should have a clear way of telling the device that a channe= l is unavailable. I am not in favour of assuming that certain low dBm numbe= r means unavailability. * From a regulator's perspective, there is no requirement on HOW the= DB specifies unavailable channels. 2 approaches have been mentioned here: = 1) to exclude the channel from the list, and 2) a codification such "-inf = dBm". Either would work for us. * Peter is right that the regulatory requirement is that a DB should= simply tell a device that a channel is available, the allowed power and th= e start/end of availability. I am not comfortable with the notion of "no in= formation given" , in case the device decides that a spectrum availability = info remains valid in the absence of newer information. Having said that you may want to accommodate value added services in future= versions of the protocol, to indicate things such as "this channel is norm= ally the best even though from 3:00 to 6:00 is not available", but it looks= too advanced to me at this stage. * Future proofing devices. The way we plan to accommodate better unw= anted emissions or less interfering technologies in the ETSI framework is 1= ) through update of the ETSI standard (not very quick), and 2) by means of = the "technology ID" field (hopefully quicker). If a new technology is asses= sed (how this is done is TBD) to be more benign to DTT/PMSE receivers, the = DB will allow higher power levels to devices declaring that technology. Hope this helps, Cesar From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Pet= er Stanforth Sent: 23 September 2013 15:00 To: Harasty, Daniel J; paws@ietf.org Subject: Re: [paws] "unavailable" vs "no information" Speaking as a database provider who has been certified, and someone who has= helped a number of radios get FCC certification I have to suggest your int= erpretation is wrong. There is no ambiguity as far as the FCC is concerned, and conversations wi= th IDA, IC, and Ofcom lead to a similar conclusion. >From the Regulator perspective, the database provides a list of channels th= at are available and anything that is not specifically identified as availa= ble is unavailable - period. There is no notion, to use your example, that channel 17 is undefined after= 6pm. The database told you you can only use it till 6pm. At 6pm you can q= uery the database and you may be told that it is available. Does this mean = it was always available? Absolutely not, but at the time of the original qu= ery it was unavailable. I also have to deal with the situation where I am = required to tell a device "no channels available". At the time I give that= answer it is unambiguous. If the device asks again later it may, or may no= t, get the same answer. I don't understand how I do this if we are returnin= g a complete "channel list" with any kind of emission criteria, and satisfy= the Regulator that we are doing what we are required to do. As I have said previously the database is not the enforcer or the decision = maker. It simply provides information based on the Regulator rules and poli= cy. I have found this is not open to debate. In most countries Regulators = are not allowed to delegate or abdicate responsibility for spectrum managem= ent. We exist, as a database provider, by acting as an agent or subcontract= or to the Regulator (depending on the domain). We are not permitted to make= interpretations or make decisions. We simply implement their rules. Maybe = this will change in the future but this is the environment we operate in to= day. As far as spectrum availability is concerned I think the current specificat= ion allows us to comply with all the known regulatory environments we are a= ware of. Including vague notions around implicit, or maybe, concepts not on= ly give me concern about how I comply with the agreement I have in place wi= th the regulator, it is likely to give the incumbents fits. We have enough = fights with the incumbents today even with the simple definition that exist= . Suggesting that the database is "interpreting" anything simply makes the = likelihood of spectrum sharing in whitespace less likely. All that being said. I go back to my other concern, which is that this is t= aking way too long. Based on the original charter we should be done by now.= So even though I think some of these ideas are academically interesting, = and maybe in the longer term future of PAWS. I really want to get a PAWS pr= otocol finished that supports the TVWS activities that are percolating arou= nd the world. To paraphrase Voltaire I strongly believe that an imperfect, = but finished, PAWS protocol sends a stronger message of industry commitment= to wanting access to TVWS and spectrum sharing than continuing to debate w= hat PAWS maybe one day. Peter S From: , Daniel J > Date: Monday, September 23, 2013 9:20 AM To: "paws@ietf.org" > Subject: [paws] "unavailable" vs "no information" Gabor Bajko mentioned: I think we first have to agree whether we need at all to encode an 'unavail= able channel'. Current draft section 4.4.2 says: "The response message for = the Available Spectrum Query contains a schedule of available spectrum for = the Device." To me this means that channels which are not listed are implic= itly unavailable and leakage into unavailable spectrum has to conform to th= e rules. I agree that "no mention of a segment of spectrum as available" is a possib= le way to express "it is unavailable". Let's call this "implicit unavailab= ility". However, if I'm a Device, and I received a SPECTRUM_AVAIL_RESP that says "C= hannel 17 is available until 6pm" (and nothing else is mentioned about Chan= nel 17 for the time period after 6pm)... does that mean "Channel 17 is unav= ailable after 6pm" or "I have no information about Channel 17 after 6pm (ma= ybe it is available, maybe it's not)"? Thus I propose that we still need some sort of "explicit unavailable" notat= ion, and "no mention" should be reserved to express "there is no informatio= n about this piece of spectrum in this time period - ask again later". Stated another way: I propose that PAWS is better off if the Database has s= ome way to express the difference between "channel unavailable" and "no inf= ormation given about this channel [in this time period]". Perhaps the "i= mplicit unavailability" approach could be made to work by then ADDING more = fields to the event structures, like "response valid through" or "response = expiration" values... but I find that more convoluted than a "explicit unav= ailable" notation, which can express "this bit of spectrum is unavailable i= n this time period". Dan Harasty ________________________________ ***************************************************************************= *************************************** For more information visit www.ofcom.org.uk This email (and any attachments) is confidential and intended for the use o= f the addressee only. If you have received this email in error please notify the originator of th= e message and delete it from your system. This email has been scanned for viruses. However, you open any attachments = at your own risk. Any views expressed in this message are those of the individual sender and = do not represent the views or opinions of Ofcom unless expressly stated oth= erwise. ***************************************************************************= *************************************** --_000_5D3E853BEE49C848BB63047C794C8655AE9CA837WOKINTRAEXC02in_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

 

Some views from the reg= ulator’s perspective including on the spectrum encoding issue. I reco= gnise that some of this has been argued repeatedly and that the discussion has moved on.

 

&midd= ot;   = ;     In the ETSI/Ofcom model, = the databases only communicate maximum intentional power in each channel. U= nwanted emissions are regulated via compliance with one of the classes defined in ETSI EN 301 598. So, if the DB says that a chann= el is  not available, the a device must not have wanted emissions on i= t. The device is allowed have “skirt” on it, but only up to the= levels allowed by its emission class.

&midd= ot;   = ;     The DB should have a clea= r way of telling the device that a channel is unavailable. I am not in favo= ur of assuming that certain low dBm number means unavailability.

&midd= ot;   = ;     From a regulator’s = perspective, there is no requirement on HOW the DB specifies unavailable ch= annels. 2 approaches have been mentioned here: 1) to exclude the channel from the list, and 2) a codification such  “-inf dB= m”. Either would work for us.

&midd= ot;   = ;     Peter is right that the r= egulatory requirement is that a DB should simply tell a device that a chann= el is available, the allowed power and the start/end of availability. I am not comfortable with the notion of “no informatio= n given” , in case the device decides that a spectrum availability in= fo remains valid in the absence of newer information.
Having said that you may want to accommodate value added services in future= versions of the protocol, to indicate things such as “this channel i= s normally the best even though from 3:00 to 6:00 is not available”, = but it looks too advanced to me at this stage.

&midd= ot;   = ;     Future proofing devices. = The way we plan to accommodate better unwanted emissions or less interferin= g technologies in the ETSI framework is 1) through update of the ETSI standard (not very quick), and 2) by means of the “techn= ology ID” field (hopefully quicker). If a new technology is assessed = (how this is done is TBD) to be more benign to DTT/PMSE receivers, the DB w= ill allow higher power levels to devices declaring that technology.

 

Hope this helps,=

Cesar

 

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org= ] On Behalf Of Peter Stanforth
Sent: 23 September 2013 15:00
To: Harasty, Daniel J; paws@ietf.org
Subject: Re: [paws] "unavailable" vs "no information&= quot;

 

Speaking as a database pro= vider who has been certified, and someone who has helped a number of radios= get FCC certification I have to suggest your interpretation is  wrong.

There is no ambiguity as f= ar as the FCC is concerned, and  conversations with IDA, IC, and Ofcom= lead to a similar conclusion.

From the Regulator perspec= tive, the database provides a list of channels that are available and anyth= ing that is not specifically identified as available is unavailable – period.

There is no notion, to use= your example, that channel 17 is undefined after 6pm. The database told yo= u you can only use it till 6pm.  At 6pm you can query the database and you may be told that it is available. Does this mean it was a= lways available? Absolutely not, but at the time of the original query it w= as unavailable.  I also have to deal with the situation where I am req= uired to tell a device "no channels available".  At the time I give that answer it is unambiguous. If the device asks= again later it may, or may not, get the same answer. I don't understand ho= w I do this if we are returning a complete "channel list" with an= y kind of emission criteria, and satisfy the Regulator that we are doing what we are required to do.

 

As I have said previously = the database is not the enforcer or the decision maker. It simply provides = information based on the Regulator rules and policy.  I have found this is not open to debate. In most countries Regulators are no= t allowed to delegate or abdicate responsibility for spectrum management. W= e exist, as a database provider, by acting as an agent or subcontractor to = the Regulator (depending on the domain). We are not permitted to make interpretations or make decisions. W= e simply implement their rules. Maybe this will change in the future but th= is is the environment we operate in today.

 

As far as spectrum availab= ility is concerned I think the current specification allows us to comply wi= th all the known regulatory environments we are aware of. Including vague notions around implicit, or maybe, concepts not only give = me concern about how I comply with the agreement I have in place with the r= egulator, it is likely to give the incumbents fits. We have enough fights w= ith the incumbents today even with the simple definition that exist. Suggesting that the database is "in= terpreting" anything simply makes the likelihood of spectrum sharing i= n whitespace less likely.

 

All that being said. I go = back to my other concern, which is that this is taking way too long. Based = on the original charter we should be done by now. So even though I think some of these ideas are academically  interesting, and= maybe in the longer term future of PAWS. I really want to get a PAWS proto= col finished that supports the TVWS activities that are percolating around = the world. To paraphrase Voltaire I strongly believe that an imperfect, but finished, PAWS protocol sends a stronger me= ssage of industry commitment to wanting access to TVWS and spectrum sharing= than continuing to debate what PAWS maybe one day.

 

Peter S

 

 

From: <Harasty>, Daniel J <dharasty@appcomsci.com>
Date: Monday, September 23, 2013 9:20 AM
To: "paws@ietf.org" &= lt;paws@ietf.org>
Subject: [paws] "unavailable" vs "no information"= ;

 

Gabor Ba= jko mentioned:

 

I think we first have to agree whether we need at all = to encode an ‘unavailable channel’. Current draft section 4.4.2 says: “The response message for the Available Spectrum Query contain= s a schedule of available spectrum for the Device.” To me this means = that channels which are not listed are implicitly unavailable and leakage i= nto unavailable spectrum has to conform to the rules.

 

I agree = that “no mention of a segment of spectrum as available” is a po= ssible way to express “it is unavailable”.  Let’s ca= ll this “implicit unavailability”.

 

However,= if I’m a Device, and I received a SPECTRUM_AVAIL_RESP that says R= 20;Channel 17 is available until 6pm” (and nothing else is mentioned = about Channel 17 for the time period after 6pm)… does that mean “Cha= nnel 17 is unavailable after 6pm” or “I have no information about Channel 17 after 6pm (maybe it is availa= ble, maybe it’s not)”?

 

Thus I p= ropose that we still need some sort of “explicit unavailable” n= otation, and “no mention” should be reserved to express “= there is no information about this piece of spectrum in this time period – ask again later&#= 8221;.

 

Stated a= nother way: I propose that PAWS is better off if the Database has some way = to express the difference between "channel unavailable" and "no information given about this channel [in this time period]".=     Perhaps the “implicit unavailability” approa= ch could be made to work by then ADDING more fields to the event structures= , like “response valid through” or “response expiration&#= 8221; values… but I find that more convoluted than a “explicit unavailable” nota= tion, which can express “this bit of spectrum is unavailable in this = time period”.

 

Dan Hara= sty

 



***************************************************************************= ***************************************
For more information visit www.ofcom.org.uk

This email (and any attachments) is confidential and intended for the use o= f the addressee only.

If you have received this email in error please notify the originator of th= e message and delete it from your system.

This email has been scanned for viruses. However, you open any attachments = at your own risk.

Any views expressed in this message are those of the individual sender and = do not represent the views or opinions of Ofcom unless expressly stated oth= erwise.
***************************************************************************= ***************************************
 --_000_5D3E853BEE49C848BB63047C794C8655AE9CA837WOKINTRAEXC02in_-- From ben@blindcreek.com Mon Sep 23 11:48:26 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FB7621F9FBA for ; Mon, 23 Sep 2013 11:48:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.795 X-Spam-Level: X-Spam-Status: No, score=-1.795 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qbIVlsqBB+-f for ; Mon, 23 Sep 2013 11:48:20 -0700 (PDT) Received: from blu0-omc3-s20.blu0.hotmail.com (blu0-omc3-s20.blu0.hotmail.com [65.55.116.95]) by ietfa.amsl.com (Postfix) with ESMTP id DEC2A21F9FB6 for ; Mon, 23 Sep 2013 11:48:19 -0700 (PDT) Received: from BLU0-SMTP347 ([65.55.116.73]) by blu0-omc3-s20.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 23 Sep 2013 11:48:16 -0700 X-TMN: [bgp7qQzovM4L5xbGVPWzy94sGVyHP72G] X-Originating-Email: [ben@blindcreek.com] Message-ID: Received: from [127.0.0.1] ([64.74.213.174]) by BLU0-SMTP347.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 23 Sep 2013 11:48:15 -0700 Date: Mon, 23 Sep 2013 11:48:15 -0700 From: "Benjamin A. Rolfe" User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: paws@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------000508040706060405070907" X-Antivirus: avast! (VPS 130923-0, 09/23/2013), Outbound message X-Antivirus-Status: Not-Tested X-OriginalArrivalTime: 23 Sep 2013 18:48:15.0903 (UTC) FILETIME=[768ACAF0:01CEB88D] Sender: Subject: Re: [paws] "unavailable" vs "no information" X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 18:48:26 -0000 --------------000508040706060405070907 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Based on the US rules, only when a channel is explicitly identified as available at the time and place may it be used. If no information is obtained indicating it is OK to use at the time and location of the device it shall not transmit on a channel except as provided in the rules for making initial contact and queries for the purpose of obtaining channel availability information. Last version of OFCOM and EU proposals I read were similar (except last version of EU rules I read did not have any provision for making an initial query, but that may have been fixed). So absence of permission is (in this case) an implicit "No". Hope that helps. On 9/23/2013 6:20 AM, Harasty, Daniel J wrote: > > Gabor Bajko mentioned: > > I think we first have to agree whether we need at all to encode an > 'unavailable channel'. Current draft section 4.4.2 says: "The response > message for the Available Spectrum Query contains a schedule of > available spectrum for the Device." To me this means that channels > which are not listed are implicitly unavailable and leakage into > unavailable spectrum has to conform to the rules. > > I agree that "no mention of a segment of spectrum as available" is a > possible way to express "it is unavailable". Let's call this > "implicit unavailability". > > However, if I'm a Device, and I received a SPECTRUM_AVAIL_RESP that > says "Channel 17 is available until 6pm" (and nothing else is > mentioned about Channel 17 for the time period after 6pm)... does that > mean "Channel 17 is /_unavailable_/ after 6pm" or "I have /_no > information_/ about Channel 17 after 6pm (maybe it is available, maybe > it's not)"? > > Thus I propose that we still need some sort of "explicit unavailable" > notation, and "no mention" should be reserved to express "there is no > information about this piece of spectrum in this time period -- ask > again later". > > Stated another way: I propose that PAWS is better off if the Database > has some way to express the difference between "channel unavailable" > and "no information given about this channel [in this time period]". > Perhaps the "implicit unavailability" approach could be made to work > by then ADDING more fields to the event structures, like "response > valid through" or "response expiration" values... but I find that more > convoluted than a "explicit unavailable" notation, which can express > "this bit of spectrum is unavailable in this time period". > > Dan Harasty > > > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws --------------000508040706060405070907 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Based on the US rules, only when a channel is explicitly identified as available at the time and place may it be used.  If no information is obtained indicating it is OK to use at the time and location of the device it shall not transmit on a channel except as provided in the rules for making initial contact and queries for the purpose of obtaining channel availability information.   Last version of OFCOM and EU proposals I read were similar (except last version of EU rules I read did not have any provision for making an initial query, but that may have been fixed).

So absence of permission is (in this case) an implicit "No". 

Hope that helps.


On 9/23/2013 6:20 AM, Harasty, Daniel J wrote:

Gabor Bajko mentioned:

 

I think we first have to agree whether we need at all to encode an ‘unavailable channel’. Current draft section 4.4.2 says: “The response message for the Available Spectrum Query contains a schedule of available spectrum for the Device.” To me this means that channels which are not listed are implicitly unavailable and leakage into unavailable spectrum has to conform to the rules.

 

I agree that “no mention of a segment of spectrum as available” is a possible way to express “it is unavailable”.  Let’s call this “implicit unavailability”.

 

However, if I’m a Device, and I received a SPECTRUM_AVAIL_RESP that says “Channel 17 is available until 6pm” (and nothing else is mentioned about Channel 17 for the time period after 6pm)… does that mean “Channel 17 is unavailable after 6pm” or “I have no information about Channel 17 after 6pm (maybe it is available, maybe it’s not)”?

 

Thus I propose that we still need some sort of “explicit unavailable” notation, and “no mention” should be reserved to express “there is no information about this piece of spectrum in this time period – ask again later”.

 

Stated another way: I propose that PAWS is better off if the Database has some way to express the difference between "channel unavailable" and "no information given about this channel [in this time period]".    Perhaps the “implicit unavailability” approach could be made to work by then ADDING more fields to the event structures, like “response valid through” or “response expiration” values… but I find that more convoluted than a “explicit unavailable” notation, which can express “this bit of spectrum is unavailable in this time period”.

 

Dan Harasty

 



_______________________________________________
paws mailing list
paws@ietf.org
https://www.ietf.org/mailman/listinfo/paws

--------------000508040706060405070907-- From Gabor.Bajko@nokia.com Mon Sep 23 12:57:35 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC9FD21F9DE1 for ; Mon, 23 Sep 2013 12:57:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.236 X-Spam-Level: X-Spam-Status: No, score=-5.236 tagged_above=-999 required=5 tests=[AWL=0.362, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m-hKT2RUIGlo for ; Mon, 23 Sep 2013 12:57:21 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 51E7621F9DD6 for ; Mon, 23 Sep 2013 12:57:19 -0700 (PDT) Received: from smtp.mgd.nokia.com ([65.54.30.58]) by mgw-da02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r8NJu9qp026314 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 23 Sep 2013 22:56:11 +0300 Received: from 008-AM1MPN1-007.mgdnok.nokia.com ([169.254.7.71]) by 008-AM1MMR1-003.mgdnok.nokia.com ([65.54.30.58]) with mapi id 14.03.0136.001; Mon, 23 Sep 2013 19:56:09 +0000 From: To: Thread-Topic: [paws] Spectrum encoding discussion Thread-Index: AQHOtLJJlV0A7sF1Y0u4PChODFE3GpnM2N2AgABHaoCAAAbdgIAAB0+AgAACXwCAAAsCAIABLRqAgAClvgCAAAR7EIAAFgcAgAAa+ACAABHGgIAADQKAgAAQcgCABElGUA== Date: Mon, 23 Sep 2013 19:56:08 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E47605350FC6@008-AM1MPN1-007.mgdnok.nokia.com> References: <1ECAFF543A2FED4EA2BEB6CACE08E476053422B0@008-AM1MPN1-006.mgdnok.nokia.com> <1ECAFF543A2FED4EA2BEB6CACE08E47605342356@008-AM1MPN1-006.mgdnok.nokia.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [69.181.65.212] Content-Type: multipart/related; boundary="_004_1ECAFF543A2FED4EA2BEB6CACE08E47605350FC6008AM1MPN1007mg_"; type="multipart/alternative" MIME-Version: 1.0 X-Nokia-AV: Clean Cc: paws@ietf.org Subject: Re: [paws] Spectrum encoding discussion X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 19:57:36 -0000 --_004_1ECAFF543A2FED4EA2BEB6CACE08E47605350FC6008AM1MPN1007mg_ Content-Type: multipart/alternative; boundary="_000_1ECAFF543A2FED4EA2BEB6CACE08E47605350FC6008AM1MPN1007mg_" --_000_1ECAFF543A2FED4EA2BEB6CACE08E47605350FC6008AM1MPN1007mg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Vince, This proposal of yours below could potentially become very confusing. The m= essage itself is named Available Spectrum Request, and you propose the Avai= lable Spectrum Response to include a bunch of channels with unspecified pow= er levels, which are btw, not available channels. So far, we have 4 proposed ways to indicate unavailable channels: a) Not listing it, implicit unavailability b) List unavailable channels and specify the power limit, eg -56dbm c) List unavailable channels and specify -inf as power limit d) List unavailable channels and do not specify any power limit So far, we have majority in favour of a), few people who could live or pref= er c) and sort of consensus to strike out option b) from the list above. We'll wait for more input on the list before declaring rough consensus for = the question above; then we'll go back to the original question on whether = the encoding of spectrum profile should be option 1 or option 2. p.s. It looks to me, that if we want to specify unavailable channels, we ma= y need to modify the names of the paws messages to 'Spectrum schedule' or s= g along these lines. - Gabor From: ext Vincent Chen [mailto:vchen@google.com] Sent: Friday, September 20, 2013 7:01 PM To: Bajko Gabor (Nokia-CIC/SiliconValley) Cc: Harasty, Daniel J; paws@ietf.org Subject: Re: [paws] Spectrum encoding discussion All, Thanks Dan for framing the discussion. We do not like a magic value, such a= s "-inf" to indicate off, but simply leaving off the power would be accepta= ble. To make it more concrete, a Database that chooses to explicitly represent "= off" channels may be encoded as the following. I've annotated the first profile with US channels. It is able to represent = only frequencies that are only in the band plan and within the band plan, frequencies without a power is interpreted by the= device as OFF. "spectra": [ { "bandwidth": 6e6, "profiles": [ [ { "freqHz": 5.4e7 }, // channels 2-4 off { "freqHz": 7.2e7 }, ], [ { "freqHz": 7.6e7 }, // channels 5-6 off { "freqHz": 8.8e7 }, ], [ { "freqHz": 1.74e8 }, // channels 7-13 off { "freqHz": 2.16e8 }, ], [ { "freqHz": 4.70e8, "maxPsdDbmPerBw": 30.0 }, // channel 14 { "freqHz": 4.76e8, "maxPsdDbmPerBw": 30.0 }, { "freqHz": 4.76e8 }, // channel 15-21 off { "freqHz": 5.18e8 }, { "freqHz": 5.18e8, "maxPsdDbmPerBw": 30.0 }, // channel 22 { "freqHz": 5.24e8, "maxPsdDbmPerBw": 30.0 }, { "freqHz": 5.24e8, "maxPsdDbmPerBw": 36.0 }, // channel 23 { "freqHz": 5.30e8, "maxPsdDbmPerBw": 36.0 }, { "freqHz": 5.30e8 }, { "freqHz": 6.98e8 } ] ] }, { "bandwidth": 1e5, "profiles": [ [ { "freqHz": 5.4e7 }, { "freqHz": 7.2e7 }, ], [ { "freqHz": 7.6e7 }, { "freqHz": 8.8e7 }, ], [ { "freqHz": 1.74e8 }, { "freqHz": 2.16e8 }, ], [ { "freqHz": 4.70e8, "maxPsdDbmPerBw": 27.0 }, { "freqHz": 4.76e8, "maxPsdDbmPerBw": 27.0 }, { "freqHz": 4.76e8 }, { "freqHz": 5.18e8 }, { "freqHz": 5.18e8, "maxPsdDbmPerBw": 27.0 }, { "freqHz": 5.24e8, "maxPsdDbmPerBw": 27.0 }, { "freqHz": 5.24e8, "maxPsdDbmPerBw": 33.0 }, { "freqHz": 5.30e8, "maxPsdDbmPerBw": 33.0 }, { "freqHz": 5.30e8 }, { "freqHz": 6.98e8 } ] ] } ] I hope this is getting closer to addressing most of the concerns. -vince On Fri, Sep 20, 2013 at 6:31 PM, > wrote: Few things to consider: 1. I think we first have to agree whether we need at all to encode an= 'unavailable channel'. Current draft section 4.4.2 says: "The response mes= sage for the Available Spectrum Query contains a schedule of available spectrum for the Device." To me this means that ch= annels which are not listed are implicitly unavailable and leakage into una= vailable spectrum has to conform to the rules. 2. If one wants to be explicit on what the rules say for the leakage = limits, then we can encode those into the rulesetInfo. 3. If we take on Andy's argument that PAWS could be used outside TVWS= , *and* leakage limits may potentially be different for different bands wit= hin the same regulatory domain, then encoding all those bands and leakage l= imits into rulesetInfo might just complement what is missing from the avail= able spectrum response and we may be better off just encoding everything in= to available spectrum response. 1 and 2 doesn't require an encoding for unavailable channel. Simply not lis= ting it as available does the job. 3 would require us to agree how to encode unavailable channel, but the WSD = would still need to know what the emission limits are in that regulatory do= main for the unavailable channels. - gabor From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of ext Harasty, Danie= l J Sent: Friday, September 20, 2013 5:15 PM To: paws@ietf.org Subject: Re: [paws] Spectrum encoding discussion All: I know this is a long winded reply to an already laborious conversation. B= ut I think I can put a finger on the essential "disagreement", and even off= er a compromise that will allow us to move forward. Hint: the whole "option 1"/"option 2" debate is a bit of a misdirection, as= those two options did NOT capture the two sides of the essential disagreem= ent; the issue at hand is really about "is an out-of-band emission limit a = good way to express that a channel is unavailable?" There seems to be the camp that "out of band emission limits" are the SAME = as "channel unavailable". In my reading of the FCC rules, that is simply n= ot the case. There are times when FCC rules require me (as a Database) to = say "this channel is unavailable" other than "a protected entity occupies t= his channel". For example: * It is a channel categorically excluded from the Whitespace spectr= um (e.g. US Channel 3 or Channel 37). * There is an ad-hoc (FCC provided) polygon establishing an ad-hoc = exclusion zone. * A device is blacklisted. To say that "Channel 37 is available at -36.8 dBm" is just not the same as = "Channel 37 is unavailable", IMO. To tell all devices in an ad-hoc exclusion zone that "all channels are avai= lable at -36.8 dBm" is just not the same as "all channels are unavailable". To tell a blacklisted device that "all channels are available at -36.8 dBm"= is just not the same as "all channels are unavailable". In other words: If PAWS does not give me a way to say a channel is unequivo= cally "unavailable", then, in my opinion as a Database provider, it is not = sufficiently expressive for me to meet the FCC rules. If we DO use PAWS to encode out-of-band emissions limits, I have to say, I = think it is farfetched that a device implemented today to today's rules wil= l be able to - in the future - either "take advantage" of a less stringent = "out-of-band mask" or comply to a more stringent mask. As marvelous as SDR= s are/can be, that degree of flexibility is just not common in consumer-gra= de mass market devices owing to cost. That leads me to the conclusion that= expecting to use PAWS that way is just not going to be that useful. However, I realize we may differ on this point. But the notion of "PAWS av= ailable-spectrum replies should encode out-of-band emissions limits" is jus= t a separate notion from "PAWS must allow a way to encode 'channel unavaila= ble'". It is confounding those two concepts that - IMO - has lead to the c= urrent "disagreement". OK, time for my proposed grand compromise: * Let's define a way to unequivocally encode "channel unavailable" = that is NOT synonymous with "out of band emissions limits". I need it as a= Database provider. (Again: I offer to recap several different ways to do = this later.) * Once we have a way to unequivocally encode "channel unavailable",= we can have a separate discussion as to whether or not it is ever used. P= erhaps different Databases will interpret their legal/regulatory obligation= s differently. Or even, a given Database may use "-36.8 dBm" in some cases= and "channel unavailable" in others. The purpose of this WG is to produce a protocol that: 1. Provides for interoperability (because it is sufficiently clear). 2. Allows all parties to meet their legal/regulatory obligations as t= hey interpret them. I feel the above proposed compromise accomplishes both. Dan Harasty From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of Andy Lee Sent: Friday, September 20, 2013 7:12 PM To: Peter Stanforth Cc: paws@ietf.org Subject: Re: [paws] Spectrum encoding discussion I was actually hoping to simplify things for devices. 1) Having a fully specified spectrum profile without discontinuities and wi= thout "special" values like -inf make it much easier to write the client si= de code. This minimizes the number of special edge cases that need to be h= andled by the parsing logic and "emission fitting" code on the client. 2) We still seem to be thinking in terms of TV channels only. PAWS is desi= gned for other frequency bands too, and there won't always be such a distin= ct concept of on-channel vs. adjacent-channel emissions. 3) We don't know what future WSD technologies will be capable of. Wi-Fi al= ready supports a long list of modulation types (e.g., BPSK, QPSK, DSSS, FHS= S, OFDM) and channel widths. Software defined radios and other technologie= s can dynamically choose modulation types, channel widths, and power distri= bution. These agile radio technologies need the full spectrum profile to h= elp them choose the right combination of emission parameters. WSDs are jus= t a "black box" from the database's point of view. Andy Lee | Google Inc. | tvfool@google.com | 408-230-0522 On Fri, Sep 20, 2013 at 2:35 PM, Peter Stanforth > wrote: We have, until know, always worked on the assumption that the device would = be certified, or not, to comply with any out of band emissions. The FCC for= instance specifically tests the more stringent rule around channel 37, as = well as the more general case. The Database is not, and cannot be, the enfo= rcement agency. So simply providing a list of channels that it can use is s= ufficient. It should be of no consequence to a device why it cannot use a channel othe= r than to behave with its compliant emissions. I agree with Gabor, why are we overly complicating this? From: "Gabor.Bajko@nokia.com" > Date: Friday, September 20, 2013 4:54 PM To: "tvfool@google.com" >, "ben@blindcreek.com" > Cc: "paws@ietf.org" > Subject: Re: [paws] Spectrum encoding discussion Aren't we talking past each other in this thread? If the rules are supposed to specify what is the max intended power level a= device can put into a channel (available or not), then I also think this i= s what the DB should communicate to the device. If Ofcom specifies that the max leakage into an unavailable channel is -33d= bm, I assume the device will not be certified if it leaks more. If the devi= ce supports multiple modulation types and one of them leaks more than what = is permitted in that regulatory domain, then the device will need to know i= t, and in that regulatory domain avoid using that particular modulation typ= e. How does the device come to know it? Andy proposes the DB to indicate th= at level for the unavailable channels. Others folks seem to suggest a devic= e built to operate under a certain ruleset has to implicitly know it. Another way of looking at it might be to say that the max level of permitte= d unintentional leakage into an adjacent channel is part of the rulesetInfo= , and the spectrum response only lists the available channels. Could this b= e a way forward? - gabor From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of ext Andy Lee Sent: Friday, September 20, 2013 1:00 PM To: Benjamin A. Rolfe Cc: Protocol to Access White Space database Subject: Re: [paws] Spectrum encoding discussion Hi Ben, And that means NO intentional radiation in the channel. If you are reading this as "transmitted emissions in band should be lower t= han -33dBm" then, no, this is not the same as "no emissions" per FCC rules.= If one were to intentionally transmit at -33dBm where no intentional emiss= ions are allowed, that would not be the same as "no" under the rules. There is certainly no intention to encourage any malicious behavior. In ge= neral, we expect devices to be trying to do the right thing and just need s= ome information to understand where the boundaries are. These boundaries i= nclude both intentional and unintentional emissions. Various modulation types have known spectral profiles, including both in-ba= nd and out-of-band emissions. Knowing where the "shelf" is on the adjacent= channel makes it possible to match that with the "skirt" of the intended m= odulation pattern. The "skirt" is not part of the intended emission, but i= s important in trying to avoid causing interference on adjacent channels. A crude example of this is shown in the following image: [Inline image 1] Best regards, Andy Lee | Google Inc. | tvfool@google.com | 408-230-0522 On Fri, Sep 20, 2013 at 3:07 AM, Benjamin A. Rolfe > wrote: On 9/19/2013 9:09 AM, Andy Lee wrote: The math bears that out, but nonetheless OFCOM are still effectively propos= ing that *no* in-block transmissions are allowed in that channel. Same is true for the FCC. The FCC also assumes that "off" channels are not= used by WSDs. And that means NO intentional radiation in the channel. Specifying a low power level like -33 dBm is effectively the same thing as = specifying no in-band emissions there. If you are reading this as "transmitted emissions in band should be lower t= han -33dBm" then, no, this is not the same as "no emissions" per FCC rules.= If one were to intentionally transmit at -33dBm where no intentional emiss= ions are allowed, that would not be the same as "no" under the rules. Even if someone did try to put an in-band emission there (regardless of how= impractical that actually is), it would be too low to cause interference t= o anyone and no harm has been done to the "RF environment". Should be a little careful here for a couple reasons. I've designed and sh= ipped communication systems that operate quite well with transmit power lev= els intentionally below -33dBm and do very useful things. It's pretty easy = to design a receive with sensitivity better than -96dBm, so an intentional = radiator at -33dBm near by will be noticed - at 900 MHz your 10dB above sen= sitivity at 10m and at 54MHz you'd be 10 dB above sensitivity at 100m, poss= ibly. And when it comes to protecting their spectrum, people always use the= best propagation model to calculate interfence impact on them :-). I've p= robably misunderstood something badly, but -33dBm is certainly enough power= to be noticed. I have tried the "too low to be noticed" argument a few times in the past = in regulatory discussions, and incumbent and/or protected users usually set= the threshold closer to -120dBm and usually argue that even at really low = TX power, the "aggregate impact" of multiple devices in the "RF Environment= " is an unacceptable impact. We had trouble with this argument when the i= ntentional radiator TX limit was below the maximum unintentional emission l= imits for most non-transmitting devices (-41.3dBm). So it would be fairly important to ensure a device does not interpret -33dB= m as it's ok to use that channel so long as it's TX power is below -33dBm. I may be off base here because of how y'all see the DB providing and what = I am expecting to support future needs. "protected users" includes more tha= n TV stations in the US. Not sure that helps, but hope so. The advantage of having an "well behaved" spectrum profile (contiguous and = without special values like -inf) is that the channel selection algorithm o= n the WSDs becomes much simpler and logical. There's no need to have lots = of special boundary condition checks and code paths that only get triggered= under special circumstances. I'd like to avoid ambiguous interpretations = on the device side as much as possible. Certainly ambiguous interpretations on the device side are a bad thing. Some apps are aggregating multiple TV channels to get a logical channel tha= t that can carry a 'wide' data pipe. Other uses can fit many useful channe= ls in one TV channel. In 802.15.4m we divide the TV channel up into multipl= e physical channels carrying low data rate signals. Right now we assume a = peak power level for the TV channel, and we get that value with the start f= requency and width (or end frequency) from the database. However, I've hear= d it proposed to the FCC that we may get different power limits different p= arts of the TV channel, changing over time, as a protection mechanism for d= eal with narrow band protected users while allowing effective use of the re= st of the TV channel. For what we do, this is a good thing - our physical = channel may be less than 200kHz wide. There are a LOT of applications in I= oT that need < 200kHz channels, and blocking an entire TV channel to prote= ct a wireless microphone using < 200kHz of it means there are 28 other usab= le channels not being used - not efficient use of the spectrum. Hope this helps. -Ben Andy Lee | Google Inc. | tvfool@google.com | 408-230-0522 On Thu, Sep 19, 2013 at 8:30 AM, Ray Bellis > wrote: On 19 Sep 2013, at 16:21, Andy Lee > wrote: > This actually shows that Ofcom has picked a power threshold on channel 38= of -33 dBm. If you look at the ACLR numbers for class 3, 4, and 5 devices= , you'll see they are 10 dB apart from each other and that they all work ou= t to be -33 dBm on channel 38. > > The reason there are no limits for class 1 and 2 devices is because the i= n-band power on channels 37 and 39 cannot exceed +36 dBm/8MHz, and therefor= e the power on channel 38 will naturally be less than -33 dBm. The math bears that out, but nonetheless OFCOM are still effectively propos= ing that *no* in-block transmissions are allowed in that channel. Per OFCOM / ETSI device interface requirements it would be incorrect for us= to actually send that value of -33 dBm to a device. Ray _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws -- -vince --_000_1ECAFF543A2FED4EA2BEB6CACE08E47605350FC6008AM1MPN1007mg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Vince,<= /p>

This proposal of yours be= low could potentially become very confusing. The message itself is named Av= ailable Spectrum Request, and you propose the Available Spectrum Response to include a bunch of channels with unspecified power le= vels, which are btw, not available channels.

 <= /p>

 <= /p>

So far, we have 4 propose= d ways to indicate unavailable channels:

a) = ;     Not listing it, i= mplicit unavailability

b) = ;     List unavailable = channels and specify the power limit, eg -56dbm

c) = ;      List unavailable = channels and specify –inf as power limit

d) = ;     List unavailable = channels and do not specify any power limit

 <= /p>

So far, we have majority = in favour of a), few people who could live or prefer c) and sort of consens= us to strike out option b) from the list above.

 <= /p>

We’ll wait for more= input on the list before declaring rough consensus for the question above;= then we’ll go back to the original question on whether the encoding of spectrum profile should be option 1 or option 2.

 <= /p>

p.s. It looks to me, that= if we want to specify unavailable channels, we may need to modify the name= s of the paws messages to ‘Spectrum schedule’ or sg along these lines.

 <= /p>

- =          Gabor<= /span>

 <= /p>

From: ext Vinc= ent Chen [mailto:vchen@google.com]
Sent: Friday, September 20, 2013 7:01 PM
To: Bajko Gabor (Nokia-CIC/SiliconValley)
Cc: Harasty, Daniel J; paws@ietf.org
Subject: Re: [paws] Spectrum encoding discussion

 

All,

 

Thanks Dan for framing the discussion. We do not lik= e a magic value, such as "-inf" to indicate off, but simply leavi= ng off the power would be acceptable.

To make it more concrete, a Database that chooses to= explicitly represent "off" channels may be encoded as the follow= ing. 

 

I've annotated the first profile with US channels. I= t is able to represent only frequencies that are only in the band plan=

and within the band plan, frequencies without a powe= r is interpreted by the device as OFF.

 

"spectra": [

  {

    "bandwidth": 6e6,=

    "profiles": [

      [

        { "freqHz": 5.= 4e7 },  // channels 2-4 off

        { "freqHz": 7.= 2e7 },

      ],

      [

        { "freqHz": 7.= 6e7 },  // channels 5-6 off

        { "freqHz": 8.= 8e7 },

      ],

      [

        { "freqHz": 1.= 74e8 }, // channels 7-13 off

        { "freqHz": 2.= 16e8 },

      ],

      [

        { "freqHz": 4.= 70e8, "maxPsdDbmPerBw": 30.0 },  // channel 14

        { "freqHz": 4.= 76e8, "maxPsdDbmPerBw": 30.0 },

        { "freqHz": 4.= 76e8 },  // channel 15-21 off

        { "freqHz": 5.= 18e8 },

        { "freqHz": 5.= 18e8, "maxPsdDbmPerBw": 30.0 },  // channel 22

        { "freqHz": 5.= 24e8, "maxPsdDbmPerBw": 30.0 },

        { "freqHz": 5.= 24e8, "maxPsdDbmPerBw": 36.0 },  // channel 23

        { "freqHz": 5.= 30e8, "maxPsdDbmPerBw": 36.0 },

        { "freqHz": 5.= 30e8 },

        { "freqHz": 6.= 98e8 }

      ]

    ]

  },

  {

    "bandwidth": 1e5,=

    "profiles": [

      [

        { "freqHz": 5.= 4e7 },

        { "freqHz": 7.= 2e7 },

      ],

      [

        { "freqHz": 7.= 6e7 },

        { "freqHz": 8.= 8e7 },

      ],

      [

        { "freqHz": 1.= 74e8 },

        { "freqHz": 2.= 16e8 },

      ],

      [

        { "freqHz": 4.= 70e8, "maxPsdDbmPerBw": 27.0 },

        { "freqHz": 4.= 76e8, "maxPsdDbmPerBw": 27.0 },

        { "freqHz": 4.= 76e8 },

        { "freqHz": 5.= 18e8 },

        { "freqHz": 5.= 18e8, "maxPsdDbmPerBw": 27.0 },

        { "freqHz": 5.= 24e8, "maxPsdDbmPerBw": 27.0 },

        { "freqHz": 5.= 24e8, "maxPsdDbmPerBw": 33.0 },

        { "freqHz": 5.= 30e8, "maxPsdDbmPerBw": 33.0 },

        { "freqHz": 5.= 30e8 },

        { "freqHz": 6.= 98e8 }

      ]

    ]

  }

]

 

I hope this is getting closer to addressing most of = the concerns.

 

-vince

 

On Fri, Sep 20, 2013 at 6:31 PM, <Gabor.Bajko@nokia.com> w= rote:

Few things to consider:

 


1.       I think we first have to agree whether we need at all to =
encode an ‘unavailable channel’. Current draft section 4.4.2 sa=
ys: “The response message for the Available Spectrum Query con=
tains a


   schedule of available spectrum for the Device.”
 To me this means that channels which are not listed are implicitly unavail=
able and leakage into unavailable spectrum has to conform to the rules.


 


2.      
If one wants to be explicit on what the r=
ules say for the leakage limits, then we can encode those into the rulesetI=
nfo.


 


3.      
If we take on Andy’s argument that =
PAWS could be used outside TVWS, *and* leakage limits may potentiall=
y be different for different bands within the same regulatory
 domain, then encoding all those bands and leakage limits into rulesetInfo =
might just complement what is missing from the available spectrum response =
and we may be better off just encoding everything into available spectrum r=
esponse.


 


1 and 2 doesn’t require an encodi=
ng for unavailable channel. Simply not listing it as available does
 the job.


3 would require us to agree how to enco=
de unavailable channel, but the WSD would still need to know
 what the emission limits are in that regulatory domain for the unavailable=
 channels.


 


-         
gabor


 






From:
paws-bounces@iet=
f.org [mailto:paws-bounces@ietf.org]
On Behalf Of ext Harasty, Daniel J

Sent: Friday, September 20, 2013 5:15 PM

To: paws@ietf.org=









Subject: Re: [paws] Spectrum encoding discussion














 


All:


 


I know this is a long winded reply to a=
n already laborious conversation.  But I think I can put a
 finger on the essential “disagreement”, and even offer a compr=
omise that will allow us to move forward.


 


Hint: the whole “option 1”/=
”option 2” debate is a bit of a misdirection, as those two opti=
ons did
 NOT capture the two sides of the essential disagreement; the issue at hand=
 is really about “is an out-of-band emission limit a good way to expr=
ess that a channel is unavailable?”


 


There seems to be the camp that “=
out of band emission limits” are the SAME as “channel unavailab=
le”. 
 In my reading of the FCC rules, that is simply not the case.  There a=
re times when FCC rules
require me (as a Database) to say “this channel is unavailable=
” other than “a protected entity occupies this channel&#=
8221;.  For example:


 


&middo=
t;   &n=
bsp;    
It is a channel categorically excluded fr=
om the Whitespace spectrum (e.g. US Channel 3 or Channel 37).


&middo=
t;   &n=
bsp;    
There is an ad-hoc (FCC provided) polygon=
 establishing an ad-hoc exclusion zone.


&middo=
t;   &n=
bsp;    
A device is blacklisted.


 


To say that “Channel 37 is availa=
ble at -36.8 dBm” is just not the same as “Channel 37 is unavai=
lable”,
 IMO.


 


To tell all devices in an ad-hoc exclus=
ion zone that “all channels are available at -36.8 dBm” is
 just not the same as “all channels are unavailable”.


 


To tell a blacklisted device that ̶=
0;all channels are available at -36.8 dBm” is just not the same
 as “all channels are unavailable”.


 


In other words: If PAWS does not giv=
e me a way to say a channel is unequivocally “unavailable”,
 then, in my opinion as a Database provider, it is not sufficiently express=
ive for me to meet the FCC rules.  


 


If we DO use PAWS to encode out-of-band=
 emissions limits, I have to say, I think it is farfetched
 that a device implemented today to today’s rules will be able to =
211; in the future – either “take advantage” of a less st=
ringent “out-of-band mask” or comply to a more stringent mask.&=
nbsp; As marvelous as SDRs are/can be, that degree of flexibility is just n=
ot common
 in consumer-grade mass market devices owing to cost.  That leads me t=
o the conclusion that expecting to use PAWS that way is just not going to b=
e that useful.


 


However, I realize we may differ on thi=
s point.  But the notion of “PAWS available-spectrum replies
 should encode out-of-band emissions limits” is just a separate notio=
n from “PAWS must allow a way to encode ‘channel unavailable=
217;”.  It is confounding those two concepts that – IMO &#=
8211; has lead to the current “disagreement”.=



 


OK, time for my proposed grand compromi=
se:


 


&middo=
t;   &n=
bsp;    
Let’s define a way to unequivocally=
 encode “channel unavailable” that is NOT synonymous with ̶=
0;out of band emissions limits”.
 I need it as a Database provider.  (Again: I offer to rec=
ap several different ways to do this later.)


 


&middo=
t;   &n=
bsp;    
Once we have a way to unequivocally encod=
e “channel unavailable”, we can have a
separate discussion as to whether or not it is ever used.  Perh=
aps different Databases will interpret their legal/regulatory obligations d=
ifferently.  Or even, a given Database may use “-36.8 dBm”=
 in some cases and “channel unavailable” in others.=



 


The purpose of this WG is to produce a =
protocol that:


 


1.      
Provides for interoperability (because it=
 is sufficiently clear).


 


2.      
Allows all parties to meet their legal/re=
gulatory obligations as they interpret them.


 


I feel the above proposed compromise ac=
complishes both.


 


 


Dan Harasty


 


 


 




From:
paws-bounces@iet=
f.org [mailt=
o:paws-bounces@ietf.org]
On Behalf Of Andy Lee

Sent: Friday, September 20, 2013 7:12 PM

To: Peter Stanforth

Cc: paws@ietf.org=


Subject: Re: [paws] Spectrum encoding discussion



 




I was actually hoping to simplify things for devices.



 






1) Having a fully specified spectrum profile without discontinuiti=
es and without "special" values like -inf make it much easier to =
write the client side code.  This minimizes the
 number of special edge cases that need to be handled by the parsing logic =
and "emission fitting" code on the client.






 






2) We still seem to be thinking in terms of TV channels only. &nbs=
p;PAWS is designed for other frequency bands too, and there won't always be=
 such a distinct concept of on-channel vs.
 adjacent-channel emissions.






 






3) We don't know what future WSD technologies will be capable of. =
 Wi-Fi already supports a long list of modulation types (e.g., BPSK, Q=
PSK, DSSS, FHSS, OFDM) and channel widths.
  Software defined radios and other technologies can dynamically choos=
e modulation types, channel widths, and power distribution.  These agi=
le radio technologies need the full spectrum profile to help them choose th=
e right combination of emission parameters.
  WSDs are just a "black box" from the database's point of v=
iew.






 















&n=
bsp;








Andy Lee |




 Google Inc. |




 tvfool@google.com |




 408-2=
30-0522










 




On Fri, Sep 20, 2013 at 2:35 PM, Peter Stanforth <peter@spectrumbridge.com> wrote:






We have, until know, always worked on the assumption =
that the device would be certified, or not, to comply with
 any out of band emissions. The FCC for instance specifically tests the mor=
e stringent rule around channel 37, as well as the more general case. The D=
atabase is not, and cannot be, the enforcement agency. So simply providing =
a list of channels that it can use
 is sufficient.






It should be of no consequence to a device why it can=
not use a channel other than to behave with its compliant
 emissions. 






I agree with Gabor, why are we overly complicating th=
is?






 






From:
"Gabor.Bajko@nokia.com" <Gabor.Bajko@nokia.com>

Date: Friday, September 20, 2013 4:54 PM

To: "tvf=
ool@google.com" <tvfool@google.com>, "ben@blindcreek.com" <ben@blindcreek.com>

Cc: "paws@ie=
tf.org" <paw=
s@ietf.org>








Subject: Re: [paws] Spectrum encoding discussion













 










Aren’t we talking past each other=
 in this thread?


If the rules are supposed to specify wh=
at is the max intended power level a device can put into a
 channel (available or not), then I also think this is what the DB should c=
ommunicate to the device.


If Ofcom specifies that the max leakage=
 into an unavailable channel is -33dbm, I assume the device
 will not be certified if it leaks more. If the device supports multiple mo=
dulation types and one of them leaks more than what is permitted in that re=
gulatory domain, then the device will need to know it, and in that regulato=
ry domain avoid using that particular
 modulation type. How does the device come to know it? Andy proposes the DB=
 to indicate that level for the unavailable channels. Others folks seem to =
suggest a device built to operate under a certain ruleset has to implicitly=
 know it.


Another way of looking at it might be t=
o say that the max level of permitted unintentional leakage
 into an adjacent channel is part of the rulesetInfo, and the spectrum resp=
onse only lists the available channels. Could this be a way forward?=



-         
gabor


 


From:
paws-bounces@iet=
f.org [mailt=
o:paws-bounces@ietf.org]
On Behalf Of ext Andy Lee

Sent: Friday, September 20, 2013 1:00 PM

To: Benjamin A. Rolfe

Cc: Protocol to Access White Space database

Subject: Re: [paws] Spectrum encoding discussion

 




Hi Ben,




 








And that means NO intentional radiation in the channel.=
  






 






If you are reading this as "transmitted emissions =
in band should be lower than -33dBm" then, no, this is not the
 same as "no emissions" per FCC rules. If one were to intentional=
ly transmit at -33dBm where no intentional emissions are allowed, that woul=
d not be the same as "no" under the rules.








 






There is certainly no intention to encourage any malicious behavior. &nb=
sp;In general, we expect devices to be trying to do the right thing
 and just need some information to understand where the boundaries are. &nb=
sp;These boundaries include both intentional and unintentional emissions.






 






Various modulation types have known spectral profiles, including both in=
-band and out-of-band emissions.  Knowing where the "shelf"
 is on the adjacent channel makes it possible to match that with the "=
skirt" of the intended modulation pattern.  The "skirt"=
 is not part of the intended emission, but is important in trying to avoid =
causing interference on adjacent channels.






 






A crude example of this is shown in the following image:






 






3D"Inline=







 






Best regards,















&n=
bsp;








Andy Lee |




 Google Inc. |




 tvfool@google.com |




 408-2=
30-0522










 




On Fri, Sep 20, 2013 at 3:07 AM, Benjamin A. Rolfe <ben@blindcreek.com> wro=
te:






 




On 9/19/2013 9:09 AM, Andy Lee wrote:










The math bears that out, but nonetheless OFCOM&nbs=
p;are still effectively proposing that *no* in-block transmissions are
 allowed in that channel.






 






Same is true for the FCC.  The FCC also assumes that "of=
f" channels are not used by WSDs.










And that means NO intentional radiation in the channel. 











 






Specifying a low power level like -33 dBm is effectively the same =
thing as specifying no in-band emissions there.








 




If you are reading this as "transmitted emissions in band sho=
uld be lower than -33dBm" then, no, this is not the same as "no e=
missions" per FCC rules. If one were to intentionally
 transmit at -33dBm where no intentional emissions are allowed, that would =
not be the same as "no" under the rules.




 






 






Even if someone did try to put an in-band emission there (regardle=
ss of how impractical that actually is), it would be too low to cause inter=
ference to anyone and no harm has been
 done to the "RF environment".








Should be a little careful here for a couple reasons.  I've d=
esigned and shipped communication systems that operate quite well with tran=
smit power levels intentionally below -33dBm
 and do very useful things. It's pretty easy to design a receive with sensi=
tivity better than -96dBm, so an intentional radiator at -33dBm near by wil=
l be noticed - at 900 MHz your 10dB above sensitivity at 10m and at 54MHz y=
ou'd be 10 dB above sensitivity
 at 100m, possibly. And when it comes to protecting their spectrum, people =
always use the best propagation model to calculate interfence impact on the=
m :-).  I've probably misunderstood something badly, but -33dBm is cer=
tainly enough power to be noticed.




I have tried the "too low to be noticed" argument a few times in =
the past  in regulatory discussions, and incumbent and/or protected us=
ers usually set the threshold closer to -120dBm and usually argue that even=
 at really low TX power, the "aggregate impact"
 of multiple devices in the "RF Environment" is an unacceptable i=
mpact.   We had trouble with this argument when the intentional r=
adiator TX limit was below the maximum unintentional emission limits for mo=
st non-transmitting devices (-41.3dBm).




So it would be fairly important to ensure a device does not interpret -33dB=
m as it's ok to use that channel so long as it's TX power is below -33dBm.<=
br>


I may be off base here because of  how y'all see the DB providing and =
what I am expecting to support future needs. "protected users" in=
cludes more than TV stations in the US. 




Not sure that helps, but hope so.  




 






 






The advantage of having an "well behaved" spectrum profi=
le (contiguous and without special values like -inf) is that the =
channel selection algorithm on the WSDs becomes much simpler
 and logical.  There's no need to have lots of special boundary condit=
ion checks and code paths that only get triggered under special circumstanc=
es.  I'd like to avoid ambiguous interpretations on the device side as=
 much as possible.








Certainly ambiguous interpretations on the device side are a bad thing.




Some apps are aggregating multiple TV channels to get a logical channel tha=
t that can carry a 'wide'  data pipe. Other uses can fit many useful c=
hannels in one TV channel. In 802.15.4m we divide the TV channel up into mu=
ltiple physical channels carrying low
 data rate signals.  Right now we assume a peak power level for the TV=
 channel, and we get that value with the start frequency and width (or end =
frequency) from the database. However, I've heard it proposed to the FCC th=
at we may get different power limits
 different parts of the TV channel, changing over time, as a protection mec=
hanism for deal with narrow band protected users while allowing effective u=
se of the rest of the TV channel.  For what we do, this is a good thin=
g - our physical channel may be less
 than 200kHz wide. There are a LOT of applications  in IoT that need &=
lt; 200kHz channels,  and blocking an entire TV channel to protect a w=
ireless microphone using < 200kHz of it means there are 28 other usable =
channels  not being used - not efficient use of
 the spectrum.   



Hope this helps.   



-Ben













&n=
bsp;








Andy Lee |




 Google Inc. |




 tvfool@google.com |




 408-2=
30-0522










 




On Thu, Sep 19, 2013 at 8:30 AM, Ray Bellis <Ray.Bellis@nominet.org.uk&=
gt; wrote:




On 19 Sep 2013, at 16:21, Andy Lee <tvfool@google.com>




 wrote:



> This actually shows that Ofcom has picked a power threshold on channel=
 38 of -33 dBm.  If you look at the ACLR numbers for class 3, 4, and 5=
 devices, you'll see they are 10 dB apart from each other and that they all=
 work out to be -33 dBm on channel 38.

>

> The reason there are no limits for class 1 and 2 devices is because th=
e in-band power on channels 37 and 39 cannot exceed +36 dBm/8MHz, and t=
herefore the power on channel 38 will naturally be less than -33 dBm.<=
/o:p>




The math bears that out, but nonetheless OFCOM are still effectively pro=
posing that *no* in-block transmissions are allowed in that channel.



Per OFCOM / ETSI device interface requirements it would be incorrect for us=
 to actually send that value of -33 dBm to a device.



Ray




 




 






_______________________________________________


paws mailing list


paws@ietf.org


https://www.ietf.org/mailman/listinfo/paws




 






_______________________________________________

paws mailing list

paws@ietf.org

ht=
tps://www.ietf.org/mailman/listinfo/paws




 


















 


_______________________________________________
paws mailing list
paws@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/paws



 

--
-vince

--_000_1ECAFF543A2FED4EA2BEB6CACE08E47605350FC6008AM1MPN1007mg_-- --_004_1ECAFF543A2FED4EA2BEB6CACE08E47605350FC6008AM1MPN1007mg_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=5282; creation-date="Mon, 23 Sep 2013 19:56:07 GMT"; modification-date="Mon, 23 Sep 2013 19:56:07 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAZAAAAGQCAYAAACAvzbMAAAAAXNSR0IArs4c6QAAFFxJREFUeNrt 3XuQlXXhx/HPIfzhWikgCaMToIhBRjqZOfaPNTbWFpNNpSNdtGGyZNSAdMyw0ZhRCC21zHI0Z/Cv bOoPxy5qJuBfTTOMIpe4tKAmeCmSaMIFlH1+fzyd3QX2xrrLuezrNbMDu+e6z3nO8z7f79nzPJWi KIoAwBEaZREAICAACAgAAgKAgACAgAAgIEdPpVKxEAD6C0ilUun8mjBhQi6++OI8//zzlhoA/Y9A iqJIURTZtGlTZs6cmcsvv9xSA2DgU1gTJkzIokWL8uyzzyZJ9u3blwULFmTSpEmZNGlSFixYkH37 9mX69OnZvHlzkmTHjh0ZNWpUXn755STJpk2bMn369M7r7OjoyK233ppTTz0148ePz9y5c7Nnz57O 0c9dd92V9773vRk1que72d/l77vvvkydOjUtLS05//zzs379+jz33HOZNm1aun8AvyiKTJs2LWvX ru33ervrbRlUb//222/PxIkTc+KJJ+aaa67J/v37B3TfAZoqIDt37sySJUty9tlnJ0luu+22bNiw IatXr87q1auzdu3aLFmyJK2trVm1alWS5NFHH82YMWPyu9/9LkmycuXKfPrTn+68zrvvvjurVq3K ihUrsnXr1rz55pu5+eabO09/+umn85e//CUdHR093qf+Lv/EE09k1apV2blzZ1pbW3PVVVflrLPO ytixY7NixYrO8z311FMZN25cPvjBDw7oeqt6WwZVTz75ZJ555pmsXbs2mzdvztKlSwd83wHqXtGH JJ1f48ePL2bPnl20tbUVRVEUp512WrFhw4bO865bt66YNm1a8Yc//KGYM2dOURRF0draWtxwww3F 7Nmzi6IoiksvvbR47LHHOi8zY8aMYtOmTZ3fv/rqq8WUKVM6b/uFF17o6+71e/lXXnml87Q9e/YU LS0tRVEUxU9/+tPi0ksv7TztkksuKe69994BX29Vb8uger7up61fv77ztP5uA6ARVPramWKlUklv J7e0tGTXrl059thjkyR79+7NuHHj8vrrr2fWrFlZs2ZNJk+enG3btmXatGl56aWXcuaZZ2bjxo2d lznuuOM6p3WKokhHR0dGjRqVAwcOpFKppKOjo8+/eurv8ofe9+rP/v3vf2fKlCnZunVriqLI6aef nhdffDFjx449ouvtbRm0t7enUqmkvb29x9P6uw2ApprCOtTJJ5+cbdu2dX7f1taWU045JS0tLZk+ fXruvffenHvuuRk7dmzOOeec3HPPPZk5c2bnBjVJJk+enLa2trz11ls5cOBAiqI4aAPa35/M9nf5 3owdOzaf+cxnsnz58ixfvjyzZ8/ujMeRXG9vy6Cq+2nbtm076LTB3neAhg/InDlzMn/+/Gzfvj3b t2/P/PnzM2fOnCRJa2trli5dmosuuihJctFFF2Xp0qVpbW096DrmzZuXK6+8Mhs3bsz+/fuzbt26 XHbZZQO+D2/n8nPnzs0DDzyQX/ziF5k7d+6grrevZZAkCxcuzI4dO7Jjx44sXLgwX/7yl4fsdweo +/dAetPe3l5ce+21xcSJE4uJEycW1157bdHe3l4URVFs2bKlSFI899xzRVEUxZo1a4okxd/+9reD ruPAgQPFT37yk2LGjBnFmDFjilmzZhWPPPJIv7c92Mt3/1lHR0cxderUYurUqUVHR8egrrevZZCk WLZsWXHSSScV48aNK+bNm1fs3bt3QLcB0PDvgTB4fb1/BDCip7AAGNlGWwS83ZEWjc1IGSMQT0oA AQGg/pnCwqhrBDL1iBEIACNsBFKpJAN9tXok56XhLV5sGfTnllssAxphBFKpJA88cPjPH3usPK2+ xuQD+9lw3dbR/D2rXwB1G5Akuf/+5NB9NN1+e2P8ds04cikKIzKgLvQ/hXXBBckvf5l85Svl97// fTJjRvK/Y34kSfbtS77zneThh8vvL7ssWbYsGTMm2b8/WbiwPO2YY5Lrrjv8FfWhG8Tepq22bEkW LUpWrkzeeiu58MIycO95z8Ejg+plu19PX/exUkl+/vPkBz9IXnstOfvscuT1gQ/0Pvqo/vv668kZ ZyQbNyYTJpQ/e/PN5JRTkvXrk5NOKs+7bFnyox+V93vOnOTOO5P/+7/y/B0dyZIlyYMPJrt3J5/7 XHLPPck73zmiV84rrvAErXroIcuARhyBXH11ufGrbogXL07mzz/4PLfdlmzYkKxeXX6tXVtuEJPy 3y1byp+tXl1Ofw3WJZeU92f79uTvfy830t/9btd96+vVeV/3MUmeeKKM4s6dSWtrctVVfY9qqrc1 blwZo/vv7zrPypXJRz5SxqPqySeTZ54pb3fz5qTbwaVy993lba9YkWzdWgbIwaWAOtf3vrCqr+Av vji5/PLyFfPPftb1Hkj1otOmJb/9bfL+95ffr19fvopua0tOPz159NGDT5s1q+dRQk8jkL7eRP/P f5Izz0xeeqn/6+nrPlYqySuvJJMmlae98UY5mnjjjb6XS9W2bcnHP15e1zHHJPPmlSO36t51K5Uy XtXb3rChXKZtbeX3M2cmjzySvO995fevvZacd17ywgvp97Gp9QrU7b2Yofgz3u5vohuB9DwCGYo3 0Yf6cUNAet9I/elPyQ03lN8vWZJ88pMHb8BaWpJdu5LqsT727i1fmbe393xaS8vgArJ6dTkN9eyz 5XUmyTveUU4L9Xc9fd3HI5lG6+20Sy5JPv/5MhozZ5b3saWl6/zt7T3fdpIcd1w51Vcd2XR0JKNG Hf7eU5MH5NC/wBKQ3qew3m5EBISjM4WVJJ/4RLnRa29P/neMj4OcfHL5Kryqra2cXkrKf7uftnXr wZc99tiDX+m/+mrv9+Oyy8qtSltbGY1//atrI9vfXyX1dR+P/Nl3+M+uvz758Y+TP/85Of/8rnh0 H6V0/3/32548uet3OnCgDIODSwFNEZAk+etfy6+eNp5z5pTvi2zfXn7Nn1/+LEm+9KXyTfQdO8qv BQsOvuw55yQ//GGyZ0/y/PPJN7/Z+33Ysyc5/vjyzeUXX0y+8Y2u0yZMKN/I7k1f9/FI9XRb551X Tl8tWpR89auHX6b7Mli4MOl2cKnMm5dceWV5nfv3J+vWdU1/jVBGH5YHzRSQvnzve+W0zYc/XH6d eWZy003laTfdlJx2Wvm+x4c+dPgI5r77yvdUJkwo30f41Kd6v50HH0xuvDF597vL815wQddpN96Y fPSjvY9E+rqPR6q327r++nKE9bGPHX6ZCy8sf/9Zs8r3YxYt6jrt2muTz362nAI7/vgyLr3Frftn QHweBKghB5QaSvfdV46ili07fKPfpIt5uN4D8Yr7cEP5Rrr3QBgKdqY4VHbvTu66q/xTXAABYYAv 58q/mrrnnsG/MQ8gICNQf1MApgiAJmR37gAICAACAoCAQP8cSMryQkAG5Eg+++ZzcgANGBAHJKy/ qD3+ePmh9paWcvdeX/96uUuwZuJDhJYLTTICcUDC+nLnneUeU/75z2TNmmT0aBsWoE4DUj0gYVX1 gITd7dtX7iNx0qTya8GC8mdJuW/Aq69OTjyxPO2OOwY/ctiyJfniF8vrOuGEctdRO3f2vmuo7v/v 6z5WKuVeSKZOLV/Zn39+ebiQvkYf1dvatas8IOLOnV3nefPN8lhS//hH13lvvz2ZOLG879dc07X3 9qTce/uttyannpqMH5/MnVvuN7Inf/xjebyrd72rvI077jj44JAAdRMQByTseVRTLwckXLEiOfdc KzJw9PW5M0UHJOx7uVTV4oCESXnMqi98oXxf5IwzarQCDdFO+exIcWCGaoeKdqbIURmBJOXexm+7 Lfn+9w8/nEeSvPxyucf2qtNPLw97kZT/HnraYK1eXb6BPH58uVE+4YRywz8Qfd3HpCseSXmAwOrB AgfitNPKEcdvflOGZeXKMhCHnqdq2rSDb/vFF8sQjh5dHmBx0qQyin1ZtaoM4MMP1y4ewMg2oH1h VQ9ImPR9QMLqK+yeDkhYPa23AxIed1z5fX8HJLz55uTXvy7jsXt3+Z5C9VV+X/q6j0f+6u3wn11/ fTm1N2VK7wckrN52TwckfPzx8j2YgfjVr5Jvf7sc2Z1zTh2uVYP5kMKqbsd2meKJ2fty6v7N00d+ +aE4oDocyQgkcUDC7mp5QMI77ywPT//UU3UaD0BAjoQDEnaNQob7gITXXVf+AcHMmV1/CVapJP/9 r5UZOLockXAIjcADEvb8Zuwg3hFffPcJXRf5mnWpNw8t7/r/LQt2D/BCh7/z7k106mYEQtcBCb/1 LcviSHWPB5YbjcMBpYbkVbgDEgICwiA4IOHQMX3V//LpPo0FtWQKCwABAUBAABAQAAQEAAQEAAEB QEAAEBDol91xWH4ICAACArVhNyaWEwICgIAAgIAAICAACAgAAgKAgACAgAAgIDQRu+GwHBEQAAQE asPuOSwvBAQAAQEAAQFAQAAQEAAEBAABAQABAUBAaCJ2v2F5IiAACAjUht1yWG4ICAACAgACAoCA ACAgAAgIAAICAAICgIAAICCMdPbbZLkiIAAICNSG/TlZfggIAAICAAICgIAAICAACAgAAgIAAgKA gNBE7G7D8kVAABAQqA274bAcERAABAQABAQAAQFAQAAQEAAEBAAEBAABoYnYzYbljIAAgIBQG3a/ YXkiIAAICAAICAACAoCAACAgAAgIAAgIAAJCE7F7DcsbAQEAAaE27HbDckVAABAQABAQAAQEAAEB QEAAQEAAEBAABAQAAWGks18myx0BAQABoTbsr8nyRUAAEBAAEBAABAQAAQFAQABAQAAQEAAEhCZi dxqWPwICAAJCbdjNhuWMgACAgAAgIAAICAACAoCAAICAACAgAAgITWTxqgssBI8DAgIAAkIN2L2G 5Y2AAICAACAgAAgIAAICgIAAgIAAICAACAhNxO4zPB4ICAAICLVhtxqWOwICAAICgIAAICAACAgA AgIAAgKAgAAgIAAICCOd/S55XBAQABAQasP+mCx/BAQABAQAAQGgRkZXKhVLAUYw2wCMQAAQEADq 3+iiKCwFGGE87zECAaB2IxCLoI4sXtz4v4LdZdT34/PxVbnlY083/i9yyy0eTAGhWcIBNXnOCImA CEdzuuIKD3G9PA4PPSQkCMjICEcjb3l3ndD1/7M91HXh7LOSNd3Xr6mN+7v0VkIhERDh8JIdBvQc ERIBEQ7hACEREIQDhERAEA4QEgREOEBIhERAhAMQEgERDkBIGl6lsFc14RiqxXL3CQcvhq9ZVerF Q8sP/v6WBbtH6ILo5xOVQmIEIhyAEYkRiHA06AjE6KO+RyEjdgRiRGIEIhyAEYmACAcgJAIiHICQ CIhwCAcIiZAIiHAAQiIgwgEIiYAIByAkAiIcgJCMwJA09wcJhePoLWq7Mal7dmcynAt3ZH4gsTlH IMIBGJEYgQhH441AjD4aYxRiBGJEYgQiHIARiYAIByAkAiIcAE0eksYKiHAAQiIgwgEISWOHpL4D IhyAkNRtSOozIMIBCEndh6S+AiIcgJA0TEjqIyDCAdBwIantJ9GFoynYD1bjsD+sRn3g6vOT7bUZ gQgHQMOPSI7uCEQ4mn4EYvTRWKMQIxAjkvofgQgHQNONSIY3IMIB0LQhGZ6ACAdA04dkaAMiHAAj JiRDExDhABhxIXl7AREOgBEbksEFRDgARnxIjiwgwgEgJP8zsA8SCge9rRp2Y9Jw7M6ErpXh7X0g cbRwABiRDGZE0vMIRDgYxAjE6KMxRyFGIAx2RDJaOAAYzIhktHAAMJiQjO4zHsIBICS9hGS0cAAw mJCMOuxM4sEAHfonvHgcGQEh6daI0YIBwGBGJKMsCYZkffqaZeDxYqQREMA0FgKCDQ4gIMAwM42F gGBDBAgIjcH0lccVBAQAAaE2TF95/BAQGBDTHB5fEBAABITaMP3hcURAADqZxkJAsGEBBAQYXqax EBBscAABob6YvvJ4g4AAICDUhukrjysICANiOsPjDgICgIBQG6Y5PL4gIEC/TGMhINiAAAICDC/T WAgINiyAgFAbpq+wHiAgAAgItWH6yuMNAsKAmLbA+oCAACAg1IbpDI87CAgwaKaxEBBsKAABAYaX aSwEBBsQQEAYXqavsH4gIAAICLVh+grrAQLCgJiewHqCgAAgINSGaQusDwgIMORMYyEg2CAAAgIM L9NYCAg2FICAMDRMX2G9QUAAEBBqw/QV1g8EhAExDYH1BwEBQECoDdMTWE8QEOCoMY0lIHjiAwgI MLxMYyEg2CAAAsKRMX2F9QkBAUBAqA3TV1hvEBAGxHQD1isEBAABoTZMQ2D9QUCAmjONJSB4ggMI CDC8TGMJCJ74AAJCz0xfYT1DQAAQEGrD9BXWJwSEATGtgPUNAQFAQKgN0w1YrxAQoG6ZxhIQPJEB BAQYXqaxBARPcAABGelMX2H9Q0AAEBBqw/QV1jMEhAExfYD1EAEBQECoDdMKWN8QEKDhmMYSEDxh AQQEGF6msQQET2QAARkpTF9hvURAABAQasP0FdY/BIQBMU2A9RMBAUBAqA3TB1gPERCgaZjGEhA8 MQEBARheprEEBE9YAAFpNqavsL4iIAAICLVh+grrJQKC6QCstwgIAAJCHTNNgPUTAQGanmksAcET EBAQgOFlGktA8MQEBIRGZfoK6zECAoCAUBumr7C+IiAY9mN9RkAAEBBMB4D1FgEB6o9pLAHBEw0Q EIDhZRpLQPAEBASEemf6Cus3AgKAgFAbpq+wHiMgGN6D9VxAABAQDPvB+oyAAI3DNJaA4AkFCAjA 8DKNJSB4ogECQr0wfYX1HgEBQECoDdNXWL8REAzjwfovIAAICIb3YD1HQIDGZxpLQPDEAQQEYHiZ xhIQPKEAAeFoM30Fng8CAoCAUBumr7DeIyAYroPnhYAAICAYxoP1HwEBmpdpLAHBEwQQEIDhZRpL QPDEAQSE4WL6CjxPBASApvf/5iHIqNxWR4QAAAAASUVORK5CYII= --_004_1ECAFF543A2FED4EA2BEB6CACE08E47605350FC6008AM1MPN1007mg_-- From ietf-ipr@ietf.org Mon Sep 23 15:18:15 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA67B21F9EBE; Mon, 23 Sep 2013 15:18:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.396 X-Spam-Level: X-Spam-Status: No, score=-102.396 tagged_above=-999 required=5 tests=[AWL=0.204, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LtOEwTFqMEQ2; Mon, 23 Sep 2013 15:18:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4143121F9E62; Mon, 23 Sep 2013 15:18:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: vchen@google.com, sdas@appcomsci.com, lei.zhu@huawei.com, peter.mccann@huawei.com, jmalyar@iconectiv.com X-Test-IDTracker: no X-IETF-IDTracker: 4.72 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20130923221810.17387.28376.idtracker@ietfa.amsl.com> Date: Mon, 23 Sep 2013 15:18:10 -0700 X-Mailman-Approved-At: Mon, 23 Sep 2013 15:19:30 -0700 Cc: presnick@qti.qualcomm.com, paws@ietf.org, br@brianrosen.net, barryleiba@computer.org, ipr-announce@ietf.org Subject: [paws] IPR Disclosure: InterDigital Patent Holdings, Inc.'s Statement about IPR related to draft-ietf-paws-protocol-06 X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 22:18:16 -0000 Dear Vincent Chen, Subir Das, Lei Zhu, Pete McCann, John Malyar: An IPR disclosure that pertains to your Internet-Draft entitled "Protocol = to Access Spectrum Database" (draft-ietf-paws-protocol) was submitted to the I= ETF Secretariat on 2013-09-23 and has been posted on the "IETF Page of Intellec= tual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/2203/). The = title of the IPR disclosure is "InterDigital Patent Holdings, Inc.'s Statement ab= out IPR related to draft-ietf-paws-protocol-06.""); The IETF Secretariat From tvfool@google.com Mon Sep 23 16:15:33 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A650621F92B8 for ; Mon, 23 Sep 2013 16:15:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.295 X-Spam-Level: X-Spam-Status: No, score=-1.295 tagged_above=-999 required=5 tests=[AWL=0.682, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UZU8kJMSC4PS for ; Mon, 23 Sep 2013 16:15:33 -0700 (PDT) Received: from mail-qc0-x22c.google.com (mail-qc0-x22c.google.com [IPv6:2607:f8b0:400d:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id B9D4621F9228 for ; Mon, 23 Sep 2013 16:15:32 -0700 (PDT) Received: by mail-qc0-f172.google.com with SMTP id l13so2615795qcy.17 for ; Mon, 23 Sep 2013 16:15:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vmWAP8FOH7zFvbQIQaItAd9LmHFc/MS5x4aVsQfxFkY=; b=OcreBbnBrtQx/kvl3kKwgZkVOt04Y9ymQqWpGNdFkV6txFEt1AnHQmGxH7uFzueRoN Yv+rf2m3vA22HRue39TQiR6AOfAfuQDToXPmBElRWOiccdf+HeHbJeUnoNC9zQoxlfbl lWSks7RKYZKR7rBYrte/rnx2I+BfEBpQw9W5Wq/ZvvJwvLWIYELSBQJD2ptROBnPN5w0 q8w33A6Rwx211MxlTMUwjQFDnMFMQzsiN1ITuZ1xSr/kAAlB9VmpuJ0TAmjLFN6V4ymy IcSZQkJPjukdrxjgCHCgopM4fJs9X44amk+bqEUaLWSXcrCooxk2qThtoJI+5g2CidPh QW8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=vmWAP8FOH7zFvbQIQaItAd9LmHFc/MS5x4aVsQfxFkY=; b=AuLkFMGm/tXRwByTxngpEae72GclKk1oP63BOfM017ZwKDEiftHKYJnq0W7xMepOeq wml2E7KiSwIlUDG/qYybjvWEU28unWP8Z9jlt89pO61OL0eYn43dvSwbk++ZfkWOlgXv LIJUmvjARWvSp6hsMD/JHFEywpaYlSdmM3yhDXdWrBnU2MNPbhGIoeYh69z4ILaX/Hnn 7O5r+3NWeZZ92aHHFIOnetZ9xUXB/HncaGb494N+/Mwc6ckfxqp9b+PVycL9H+nN9rIZ W5dDHu/91Gmgr+DEL8RAqlK4bkZb2iizO5gIEQhzfUzPcukmm7csBH2iJ49Eamg754oa kWmw== X-Gm-Message-State: ALoCoQl7LGUM7OdhkzUo+jtXM3o4LDoVNV8+HPt0XfgMxrAF74HVfkaUT0zb3cIR4iwOA18NpkpSGE79IRmRou2WSAMBYUCzsRXz13m1QpcrMq+NJ+sFp5bEChmhCJD1GDJlDkACPCHxTOZpVF2aexs1OJ5Kt+Xb8r212fmWtsli9iUjoM2+0SMl423gp9qWR5AA3Ub+QcBC MIME-Version: 1.0 X-Received: by 10.224.54.129 with SMTP id q1mr26114567qag.19.1379978131687; Mon, 23 Sep 2013 16:15:31 -0700 (PDT) Received: by 10.229.201.1 with HTTP; Mon, 23 Sep 2013 16:15:31 -0700 (PDT) In-Reply-To: References: Date: Mon, 23 Sep 2013 16:15:31 -0700 Message-ID: From: Andy Lee To: "Benjamin A. Rolfe" Content-Type: multipart/alternative; boundary=001a11c3127e565ad704e715329d Cc: Protocol to Access White Space database Subject: Re: [paws] "unavailable" vs "no information" X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 23:15:33 -0000 --001a11c3127e565ad704e715329d Content-Type: text/plain; charset=ISO-8859-1 Hi Ben, I think we're in total agreement. The way the FCC rules are written, there is always a baseline set of rules, with specific additional authorizations granted by rule. Section 15.709 grants radio emission permissions under very specific conditions. Anything not mentioned in section 15.709 is an implicit fallback to the baseline set of rules. Section 15.109 of the rules specifically covers non-transmitting devices, and according to the FCC, non-transmitting devices are limited to a power of 0.000000012 Watts in the UHF band (which is the same as 0.000012 mW, or -49.2 dBm, or 200 uV/M @ 3 meters). This IS the FCC's definition of "off"; they had to pick a value, and this is it. Any channel not specifically granted an "on" power level in section 15.709 would implicitly be "off". The laws in most jurisdictions are defined this way, where all the rules are "additive". Anything not mentioned in a specific add-on rule would implicitly fall back to the more general rules underneath. I'm fine with there being an implicit "off" whenever there is not an explicit "on" contained within a message. Whether the DB communicates the "off" parameters to the device is separate matter. Best regards, Andy --001a11c3127e565ad704e715329d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Ben,

I think we're in total agre= ement. =A0The way the FCC rules are written, there is always a baseline set= of rules, with specific additional authorizations granted by rule. =A0Sect= ion 15.709 grants radio emission permissions under very specific conditions= . =A0Anything not mentioned in section 15.709 is an implicit fallback to th= e baseline set of rules.

Section 15.109 of the rules specifically covers non-tra= nsmitting devices, and according to the FCC, non-transmitting devices are l= imited to a power of 0.000000012 Watts in the UHF band (which is the same a= s 0.000012 mW, or -49.2 dBm, or 200 uV/M @ 3 meters). =A0This IS the FCC= 9;s definition of "off"; they had to pick a value, and this is it= . =A0Any channel not specifically granted an "on" power level in = section 15.709 would implicitly be "off".

The laws in most jurisdictions are defined this way, wh= ere all the rules are "additive". =A0Anything not mentioned in a = specific add-on rule would implicitly fall back to the more general rules u= nderneath.

I'm fine with there being an implicit "off&quo= t; whenever there is not an explicit "on" contained within a mess= age. =A0Whether the DB communicates the "off" parameters to the d= evice is separate matter.

Best regards,
Andy
--001a11c3127e565ad704e715329d-- From vchen@google.com Mon Sep 23 18:19:48 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19F1421F9FD5 for ; Mon, 23 Sep 2013 18:19:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.805 X-Spam-Level: X-Spam-Status: No, score=-1.805 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HcjKouDu6MYK for ; Mon, 23 Sep 2013 18:19:47 -0700 (PDT) Received: from mail-oa0-x231.google.com (mail-oa0-x231.google.com [IPv6:2607:f8b0:4003:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id 41AB521F9F4F for ; Mon, 23 Sep 2013 18:19:47 -0700 (PDT) Received: by mail-oa0-f49.google.com with SMTP id i4so1460804oah.8 for ; Mon, 23 Sep 2013 18:19:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ulHkyCjLW9xdXSVFDBIjg46rEjXvl3l98H37YdOeBjU=; b=lIPZUc0CSxeZLDmgI72HEY3y6tcsTICnZjAj6majra9GVBjae1QLeYdS2R7O7iec9Y SLY+FhcDvjYJ+EUDRwopJE6gOL1UCcHWxyu3Wf95TS+hwfpwFq7fiQbZtsmnuQMGvSML J6p4tITSVos2xLCcBMAboorgvXG6F4izTzloTMp4C/qOjBLcgeOcFJpxUjwQIvOtZD1d xjqkv64gCNNPry3HUCy6dChjVJZjiIubU7SuhLoSQTVdjD9z4t+qQWfA4t7NPQeZRI5q +rs1BP0hWquLBnviwOAFNhGbCkqrBgraq+HCOi1J9Jy01wjSfZWZd+6wtw7BNvnwdB6u h4QA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ulHkyCjLW9xdXSVFDBIjg46rEjXvl3l98H37YdOeBjU=; b=enPZMjk/QyWXiFV7+MVyp6jyH6sB4imbXJahVcJqcxxV7ADNerV0hUbJK1hzXIcKCR 8GtOMNvhkGUNteZHJcOylmryKK5OYtNxHooICFxs6XWVmDA3a+l0kaxmaw4pUGg/thjV mkM+JSH7LNEd4MzOufK2a/FTHXjyAi8mK+yLEXDiVTiNtdyqnf0vqR6DcmNxFJIcvNxW c7eMTrD5b++5dbRMdM9ys+0vdWI81FDTiZQMJbYmSmphblHcKfZzYREnKdbn/259lnmH WyzSpl4Hxusp0NeWxFUsq/YNhSZIhv1wqvjLGkHX8Nr3QuUNlG7Ecung+BmBnREYw7oJ ipgg== X-Gm-Message-State: ALoCoQmhByJ9T4MvF79dl2bY/dbLPHwvq4VQ3h0HTv6cWMYqtY7AvdoxfzukdY1Sr8nz9/n4QwpUeDdluMgfYxCir2+CtOXI/k7lWqWteUKXOF5fm4QI3bf+KfNZhIx2E5fS7LeAdam8VcUD/kA5UInZlJ93aSBZZTab/Z6tgvrKv+JWjW/Ay5go9ypzwCc2n0M9D/0KLwYe MIME-Version: 1.0 X-Received: by 10.182.243.138 with SMTP id wy10mr299376obc.83.1379985586602; Mon, 23 Sep 2013 18:19:46 -0700 (PDT) Received: by 10.182.250.134 with HTTP; Mon, 23 Sep 2013 18:19:45 -0700 (PDT) In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E47605350FC6@008-AM1MPN1-007.mgdnok.nokia.com> References: <1ECAFF543A2FED4EA2BEB6CACE08E476053422B0@008-AM1MPN1-006.mgdnok.nokia.com> <1ECAFF543A2FED4EA2BEB6CACE08E47605342356@008-AM1MPN1-006.mgdnok.nokia.com> <1ECAFF543A2FED4EA2BEB6CACE08E47605350FC6@008-AM1MPN1-007.mgdnok.nokia.com> Date: Mon, 23 Sep 2013 18:19:45 -0700 Message-ID: From: Vincent Chen To: "gabor.bajko@nokia.com" Content-Type: multipart/alternative; boundary=001a11c2a120af5a8b04e716ee87 Cc: "paws@ietf.org" Subject: Re: [paws] Spectrum encoding discussion X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 01:19:48 -0000 --001a11c2a120af5a8b04e716ee87 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Gabor, I agree on possible renaming, if we want to specify unavailable channels. Please see comments inline. On Mon, Sep 23, 2013 at 12:56 PM, wrote: > Vince,**** > > This proposal of yours below could potentially become very confusing. The > message itself is named Available Spectrum Request, and you propose the > Available Spectrum Response to include a bunch of channels with unspecifi= ed > power levels, which are btw, not available channels. **** > > ** ** > > ** ** > > So far, we have 4 proposed ways to indicate unavailable channels:**** > > **a) **Not listing it, implicit unavailability > This has the drawback of not distinguishing between being silent about a channel that is within the database's purview (channel off), and being silent about a channel that is outside the database's purview (out of scope for given ruleset). > **** > > **b) **List unavailable channels and specify the power limit, eg > -56dbm > Since the protocol should stand on its own, independent of any particular regulatory rule, do we really want to rule this out? In our interpretations of the FCC rules, for example, a Database is not prevented from doing this. > **** > > **c) **List unavailable channels and specify =96inf as power limit > "-Inf" is not really workable, because JSON does not allow Infinity or NaNs (http://tools.ietf.org/html/rfc4627), hence the d) proposal. **** > > **d) **List unavailable channels and do not specify any power limit > **** > > ** ** > > So far, we have majority in favour of a), few people who could live or > prefer c) and sort of consensus to strike out option b) from the list abo= ve. > **** > > ** ** > > We=92ll wait for more input on the list before declaring rough consensus = for > the question above; then we=92ll go back to the original question on whet= her > the encoding of spectrum profile should be option 1 or option 2.**** > > ** ** > > p.s. It looks to me, that if we want to specify unavailable channels, we > may need to modify the names of the paws messages to =91Spectrum schedule= =92 or > sg along these lines.**** > > ** ** > > **- **Gabor**** > > ** > --001a11c2a120af5a8b04e716ee87 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Gabor,

I agree on possible renaming, if= we want to specify unavailable channels.

Please s= ee comments inline.=A0

On Mon, Sep 23, 2013 at 12:56 PM, <Gabor.Bajko@nokia.com> wrote:

Vince,

This proposal of yours below could potentially become= very confusing. The message itself is named Available Spectrum Request, an= d you propose the Available Spectrum Response to include a bunch of channels with unspecified power le= vels, which are btw, not available channels.

=A0

=A0

So far, we have 4 proposed ways to indicate unavailab= le channels:

a)=A0=A0=A0=A0=A0 Not listing it, implicit unavailability=

This has the drawback of not disti= nguishing between=A0bei= ng silent about a channel that is within the database's purview (channe= l off), and being silent about a channel that is outside the database's= purview (out of scope for given ruleset).
=A0

b)=A0=A0=A0=A0=A0 List unavailable channels and specify t= he power limit, eg -56dbm

Since the= protocol should stand on its own, independent of any particular regulatory= rule, do we really want to rule this out? In our interpretations of the FC= C rules, for example, a Database is not prevented from doing this.
=A0

c)=A0=A0=A0=A0=A0=A0 List unavailable channels and specify = =96inf as power limit


"-Inf" is not really workable, because JSON does not allow Infini= ty or NaNs (http://tools.iet= f.org/html/rfc4627), hence the d) proposal.

<= u>

d)=A0=A0=A0=A0=A0 List unavailable channels and do not sp= ecify any power limit=A0

<= u>

=A0

So far, we have majority in favour of a), few people = who could live or prefer c) and sort of consensus to strike out option b) f= rom the list above.

=A0

We=92ll wait for more input on the list before declar= ing rough consensus for the question above; then we=92ll go back to the ori= ginal question on whether the encoding of spectrum profile should be option 1 or option 2.

=A0

p.s. It looks to me, that if we want to specify unava= ilable channels, we may need to modify the names of the paws messages to = =91Spectrum schedule=92 or sg along these lines.

=A0

-=A0=A0=A0=A0=A0=A0=A0=A0=A0 Gabor

=A0

<= /div>
--001a11c2a120af5a8b04e716ee87-- From br@brianrosen.net Tue Sep 24 05:54:29 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F28F11E8136 for ; Tue, 24 Sep 2013 05:54:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.523 X-Spam-Level: X-Spam-Status: No, score=-103.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id biFPKnfJ3RrO for ; Tue, 24 Sep 2013 05:54:22 -0700 (PDT) Received: from mail-yh0-f52.google.com (mail-yh0-f52.google.com [209.85.213.52]) by ietfa.amsl.com (Postfix) with ESMTP id 83B2711E811F for ; Tue, 24 Sep 2013 05:54:09 -0700 (PDT) Received: by mail-yh0-f52.google.com with SMTP id v1so1851928yhn.25 for ; Tue, 24 Sep 2013 05:54:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=H3Bsq/iY+5FawQmZu2jPd0tteDcxxs0lZxDlpZokgyw=; b=PFMehRFfIlYAHprUCR8oiizZgdKOuglFpAqMOLpOlBxEQre5s8WU4qlASgedWHwOlI WTjdrN4pgDkOxgmMpDsMbayc3rA/Lh1vcvMB3J2BLjYg7IFFp8dMsjXcioxL+eLwBYbS AJXeeP9h7/VT4z/BGykiyQWhjJiiMPqSukVpKbru1Cg5lI9X9twDfkASGXpmjd8/Ci3c wdN/jxvMenN5tm0ggPl6h+Bcu+FcdxKFmSXXQty2bvXaunZfFbTHAsjrn+rIOfrOpvfq yZRSppJQfKJPzdynF33O1XHDxptRjXJjsGLRLNPuLLpAmduyvms0u5Jgash3gDPEsxDJ E/Bw== X-Gm-Message-State: ALoCoQnZxUKXGbjMCtldKarztgKwPKpDnXfDj8jgsPwuep85xwogaq8ywBPCrj1s6W+Jm3210cQl X-Received: by 10.236.173.41 with SMTP id u29mr1058101yhl.72.1380027248974; Tue, 24 Sep 2013 05:54:08 -0700 (PDT) Received: from [10.33.193.37] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id q9sm44118773yhk.16.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 24 Sep 2013 05:54:07 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_438A1BE4-0DC5-42BA-8EB7-ADC613623E41" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Brian Rosen In-Reply-To: <20130923221810.17387.28376.idtracker@ietfa.amsl.com> Date: Tue, 24 Sep 2013 08:54:05 -0400 Message-Id: References: <20130923221810.17387.28376.idtracker@ietfa.amsl.com> To: IETF Secretariat X-Mailer: Apple Mail (2.1508) X-Mailman-Approved-At: Tue, 24 Sep 2013 05:59:13 -0700 Cc: presnick@qti.qualcomm.com, paws@ietf.org, barryleiba@computer.org, jmalyar@iconectiv.com, peter.mccann@huawei.com, ipr-announce@ietf.org Subject: Re: [paws] IPR Disclosure: InterDigital Patent Holdings, Inc.'s Statement about IPR related to draft-ietf-paws-protocol-06 X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 12:54:29 -0000 --Apple-Mail=_438A1BE4-0DC5-42BA-8EB7-ADC613623E41 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This is a remarkable patent application. You can read the abstract and = claims at: http://patents.com/us-20110287802.html This application appears to be dated November 2011, and seems to me = (IANAL, let alone a PA) that it claims any whitespace database that = involves what it calls "supplemental spectrum usage data". As always when we get these kinds of notices, we need to ask if anyone = has concerns about the notice that might cause us to change direction on = our protocol. Brian On Sep 23, 2013, at 6:18 PM, IETF Secretariat wrote: >=20 > Dear Vincent Chen, Subir Das, Lei Zhu, Pete McCann, John Malyar: >=20 > An IPR disclosure that pertains to your Internet-Draft entitled = "Protocol to > Access Spectrum Database" (draft-ietf-paws-protocol) was submitted to = the IETF > Secretariat on 2013-09-23 and has been posted on the "IETF Page of = Intellectual > Property Rights Disclosures" (https://datatracker.ietf.org/ipr/2203/). = The title > of the IPR disclosure is "InterDigital Patent Holdings, Inc.'s = Statement about > IPR related to draft-ietf-paws-protocol-06.""); >=20 > The IETF Secretariat >=20 > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws --Apple-Mail=_438A1BE4-0DC5-42BA-8EB7-ADC613623E41 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii This = is a remarkable patent application.  You can read the abstract and = claims at:

This application appears to be = dated November 2011, and seems to me (IANAL, let alone a PA) that it = claims any whitespace database that involves what it calls "supplemental = spectrum usage data".

As always when we get = these kinds of notices, we need to ask if anyone has concerns about the = notice that might cause us to change direction on our = protocol.

Brian

On Sep = 23, 2013, at 6:18 PM, IETF Secretariat <ietf-ipr@ietf.org> = wrote:


Dear Vincent Chen, Subir Das, Lei Zhu, Pete McCann, = John Malyar:

An IPR disclosure that pertains to your = Internet-Draft entitled "Protocol to
Access Spectrum Database" = (draft-ietf-paws-protocol) was submitted to the IETF
Secretariat on = 2013-09-23 and has been posted on the "IETF Page of = Intellectual
Property Rights Disclosures" (https://datatracker.ietf.o= rg/ipr/2203/). The title
of the IPR disclosure is "InterDigital = Patent Holdings, Inc.'s Statement about
IPR related to = draft-ietf-paws-protocol-06."");

The IETF = Secretariat

_______________________________________________
paws= mailing list
paws@ietf.org
https://www.ietf.org/ma= ilman/listinfo/paws

= --Apple-Mail=_438A1BE4-0DC5-42BA-8EB7-ADC613623E41-- From presnick@qti.qualcomm.com Tue Sep 24 08:30:37 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 649BC21F994A; Tue, 24 Sep 2013 08:30:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oxnXzP93nZpy; Tue, 24 Sep 2013 08:30:33 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) by ietfa.amsl.com (Postfix) with ESMTP id 0FC8321F960D; Tue, 24 Sep 2013 08:30:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1380036633; x=1411572633; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=vcI1VcXqTaqOLdlFg2YmHiCO3L8QP4YhmjSh5yDedUY=; b=b2/jUWEhOhihHdKtBqpJXCtq/8ugxnOgvPLOEsMC1zG/gT+1jfgBqJSA n9tOXZ6Tr+5SgPIuZNUR+6fn7hDrABeMFg+Gtl3FIbKxZr+qn02g8Cn3F 9L2TGYoVsbqoyuiMUaFbhgkZGWdBXFGoDHZWQIMrpPbbqkIRY71WmMTzx 0=; X-IronPort-AV: E=McAfee;i="5400,1158,7207"; a="52038660" Received: from unknown (HELO ironmsg02-lv.qualcomm.com) ([10.47.202.183]) by sabertooth01.qualcomm.com with ESMTP; 24 Sep 2013 08:30:32 -0700 X-IronPort-AV: E=McAfee;i="5400,1158,7207"; a="20048902" Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by ironmsg02-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 24 Sep 2013 08:30:31 -0700 Received: from resnick2.qualcomm.com (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 24 Sep 2013 08:30:31 -0700 Message-ID: <5241B015.9050301@qti.qualcomm.com> Date: Tue, 24 Sep 2013 10:30:29 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Brian Rosen References: <20130923221810.17387.28376.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.39.5] Cc: paws@ietf.org, IETF Secretariat , barryleiba@computer.org, jmalyar@iconectiv.com, peter.mccann@huawei.com, ipr-announce@ietf.org Subject: Re: [paws] IPR Disclosure: InterDigital Patent Holdings, Inc.'s Statement about IPR related to draft-ietf-paws-protocol-06 X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 15:30:37 -0000 On 9/24/13 7:54 AM, Brian Rosen wrote: > As always when we get these kinds of notices, we need to ask if anyone > has concerns about the notice that might cause us to change direction > on our protocol. And just to be clear: None of us in leadership are going to evaluate the merits of any patent. Basically what we're asking of the WG is for you all to take a look at the information provided in the disclosure and see if this would cause you (or anyone else you know of) problems with implementing the current protocol interoperably. If so, let the rest of us know why/how, and we can discuss whether we need to work around the problem. But it is for each of you to evaluate the disclosure and the intellectual property referenced therein. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From d.joslyn@spectrumbridge.com Tue Sep 24 10:57:54 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 054F111E8162 for ; Tue, 24 Sep 2013 10:57:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A6SBRtP-doe3 for ; Tue, 24 Sep 2013 10:57:41 -0700 (PDT) Received: from mail.spectrumbridge.com (mail.spectrumbridge.com [64.132.248.82]) by ietfa.amsl.com (Postfix) with ESMTP id 1DC0221F9E00 for ; Tue, 24 Sep 2013 10:57:38 -0700 (PDT) Received: from shelby.sbi.com ([127.0.0.1]) by shelby ([127.0.0.1]) with mapi; Tue, 24 Sep 2013 13:57:29 -0400 From: Don Joslyn To: Vincent Chen , "gabor.bajko@nokia.com" Date: Tue, 24 Sep 2013 13:57:27 -0400 Thread-Topic: [paws] Spectrum encoding discussion Thread-Index: Ac64xCsdw3JWt/B0RtKzrZ9oq++LwwAic1Vw Message-ID: <8375F6DAEFB09F48815203F1FE23B79734B364673A@shelby> References: <1ECAFF543A2FED4EA2BEB6CACE08E476053422B0@008-AM1MPN1-006.mgdnok.nokia.com> <1ECAFF543A2FED4EA2BEB6CACE08E47605342356@008-AM1MPN1-006.mgdnok.nokia.com> <1ECAFF543A2FED4EA2BEB6CACE08E47605350FC6@008-AM1MPN1-007.mgdnok.nokia.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_8375F6DAEFB09F48815203F1FE23B79734B364673Ashelby_" MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] Spectrum encoding discussion X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 17:57:54 -0000 --_000_8375F6DAEFB09F48815203F1FE23B79734B364673Ashelby_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Vince, Please see my comments below (Marked with [DJ]). Thanks, Don From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Vin= cent Chen Sent: Monday, September 23, 2013 9:20 PM To: gabor.bajko@nokia.com Cc: paws@ietf.org Subject: Re: [paws] Spectrum encoding discussion Gabor, I agree on possible renaming, if we want to specify unavailable channels. Please see comments inline. On Mon, Sep 23, 2013 at 12:56 PM, > wrote: Vince, This proposal of yours below could potentially become very confusing. The m= essage itself is named Available Spectrum Request, and you propose the Avai= lable Spectrum Response to include a bunch of channels with unspecified pow= er levels, which are btw, not available channels. So far, we have 4 proposed ways to indicate unavailable channels: a) Not listing it, implicit unavailability This has the drawback of not distinguishing between being silent about a ch= annel that is within the database's purview (channel off), and being silent= about a channel that is outside the database's purview (out of scope for g= iven ruleset). [DJ - Why should the database care about channels that are outside the scop= e of the ruleset specified by the radio? For example, if the specified rule= set is FCC-related, then why would I need to include Ofcom-related channels= in the response? Am I missing something?] b) List unavailable channels and specify the power limit, eg -56dbm Since the protocol should stand on its own, independent of any particular r= egulatory rule, do we really want to rule this out? In our interpretations = of the FCC rules, for example, a Database is not prevented from doing this. [DJ - I'm still in favor of just using the implicit unavailability method d= escribed above in a). What value is there in providing a power level for an= unavailable channel? If I'm the radio, I can't use the channel, and I'm no= t going to intentionally transmit in that channel. This comment also applie= s to c) and d).] c) List unavailable channels and specify -inf as power limit "-Inf" is not really workable, because JSON does not allow Infinity or NaNs= (http://tools.ietf.org/html/rfc4627), hence the d) proposal. d) List unavailable channels and do not specify any power limit So far, we have majority in favour of a), few people who could live or pref= er c) and sort of consensus to strike out option b) from the list above. We'll wait for more input on the list before declaring rough consensus for = the question above; then we'll go back to the original question on whether = the encoding of spectrum profile should be option 1 or option 2. p.s. It looks to me, that if we want to specify unavailable channels, we ma= y need to modify the names of the paws messages to 'Spectrum schedule' or s= g along these lines. - Gabor --_000_8375F6DAEFB09F48815203F1FE23B79734B364673Ashelby_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Vince,

Please see my comments below= (Marked with [DJ]).

Than= ks,

Don<= /p>

 

= From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf = Of Vincent Chen
Sent: Monday, September 23, 2013 9:20 PM
<= b>To: gabor.bajko@nokia.com
Cc: paws@ietf.org
Subject:<= /b> Re: [paws] Spectrum encoding discussion

 

Gabor,

 

I agree on possible renaming, if we want to specify unavailable c= hannels.

 

Please see comments inline. 

 

On Mon, Sep 23, 2013 at 12:56 PM, <Gabor.Bajko@nokia.com> wrote:

Vince,

T= his proposal of yours below could potentially become very confusing. The me= ssage itself is named Available Spectrum Request, and you propose the Avail= able Spectrum Response to include a bunch of channels with unspecified powe= r levels, which are btw, not available channels.

 So far, we have 4 proposed ways to indicate unavailable cha= nnels:

a)      Not listing = it, implicit unavailability

This has the drawback of not distinguishing between being silent a= bout a channel that is within the database's purview (channel off), and bei= ng silent about a channel that is outside the database's purview (out of sc= ope for given ruleset).

 

[DJ – Why shoul= d the database care about channels that are outside the scope of the rulese= t specified by the radio? For example, if the specified ruleset is FCC-rela= ted, then why would I need to include Ofcom-related channels in the respons= e? Am I missing something?]

 

b)      List unavailable cha= nnels and specify the power limit, eg -56dbm

Since the protocol should stand o= n its own, independent of any particular regulatory rule, do we really want= to rule this out? In our interpretations of the FCC rules, for example, a = Database is not prevented from doing this.

 

[DJ ̵= 1; I’m still in favor of just using the implicit unavailability metho= d described above in a). What value is there in providing a power level for= an unavailable channel? If I’m the radio, I can’t use the chan= nel, and I’m not going to intentionally transmit in that channel. Thi= s comment also applies to c) and d).]

 

c)       List= unavailable channels and specify –inf as power limit

 <= /p>

"-Inf" is not really workable,= because JSON does not allow Infinity or NaNs (http://tools.ietf.org/html/rfc4627), hence the d) pr= oposal.

 

=

d)   = ;   List unavailable channels and do not specify an= y power limit 

 

So far, we have majority in favour of a),= few people who could live or prefer c) and sort of consensus to strike out= option b) from the list above.

 

We’ll wait for more input on the li= st before declaring rough consensus for the question above; then we’l= l go back to the original question on whether the encoding of spectrum prof= ile should be option 1 or option 2.

&nbs= p;

p.s. It looks to me, that if we want = to specify unavailable channels, we may need to modify the names of the paw= s messages to ‘Spectrum schedule’ or sg along these lines.

 

-    &= nbsp;     Gabor

 

=
= --_000_8375F6DAEFB09F48815203F1FE23B79734B364673Ashelby_-- From paul@marvell.com Tue Sep 24 11:48:39 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBDE911E80F2 for ; Tue, 24 Sep 2013 11:48:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cMF20fYZIyVq for ; Tue, 24 Sep 2013 11:48:35 -0700 (PDT) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) by ietfa.amsl.com (Postfix) with ESMTP id 3177321F92C2 for ; Tue, 24 Sep 2013 11:48:31 -0700 (PDT) Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.14.5/8.14.5) with SMTP id r8OImUHM018171; Tue, 24 Sep 2013 11:48:30 -0700 Received: from sc-owa01.marvell.com ([199.233.58.136]) by mx0b-0016f401.pphosted.com with ESMTP id 1f36natnsp-41 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 24 Sep 2013 11:48:30 -0700 Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA01.marvell.com ([10.93.76.21]) with mapi; Tue, 24 Sep 2013 11:48:28 -0700 From: Paul Lambert To: Don Joslyn , Vincent Chen , "gabor.bajko@nokia.com" , "paws@ietf.org" Date: Tue, 24 Sep 2013 11:48:22 -0700 Thread-Topic: [paws] Spectrum encoding discussion Thread-Index: Ac65VqfddTZ8+QPVTvecaMYc4M8L8g== Message-ID: In-Reply-To: <8375F6DAEFB09F48815203F1FE23B79734B364673A@shelby> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CE672B41234FFpaulmarvellcom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-09-24_08:2013-09-24, 2013-09-24, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1309240106 Subject: Re: [paws] Spectrum encoding discussion X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 18:48:40 -0000 --_000_CE672B41234FFpaulmarvellcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable In line below =85 speaking strongly in favor of "b" Gabor, I agree on possible renaming, if we want to specify unavailable channels. Please see comments inline. On Mon, Sep 23, 2013 at 12:56 PM, > wrote: Vince, This proposal of yours below could potentially become very confusing. The m= essage itself is named Available Spectrum Request, and you propose the Avai= lable Spectrum Response to include a bunch of channels with unspecified pow= er levels, which are btw, not available channels. So far, we have 4 proposed ways to indicate unavailable channels: a) Not listing it, implicit unavailability This has the drawback of not distinguishing between being silent about a ch= annel that is within the database's purview (channel off), and being silent= about a channel that is outside the database's purview (out of scope for g= iven ruleset). [DJ =96 Why should the database care about channels that are outside the sc= ope of the ruleset specified by the radio? For example, if the specified ru= leset is FCC-related, then why would I need to include Ofcom-related channe= ls in the response? Am I missing something?] The rules have strict adjacent channel requirements. Meeting the spectral = mask for the adjacent channels is one of the hardest parts for fielding re= al equipment. If the rules allow relative measurement of the adjacent chan= nel energy, you can simply lower your transmit power to the point that you = can meet the adjacent requirements. For a general White Spaces solution =96 it is critical to have knowledge fo= r the full spectrum mask. The full spectrum mask includes adjacent non-all= owed channels. RF channel usage are NOT a binary on/off or a simple transmit level. The m= ask has a specific contour that extends beyond the "allowed" channel. Tran= smitters will always send energy in more than the allowed channel! Paul b) List unavailable channels and specify the power limit, eg -56dbm Since the protocol should stand on its own, independent of any particular r= egulatory rule, do we really want to rule this out? In our interpretations = of the FCC rules, for example, a Database is not prevented from doing this. [DJ =96 I=92m still in favor of just using the implicit unavailability meth= od described above in a). What value is there in providing a power level fo= r an unavailable channel? If I=92m the radio, I can=92t use the channel, an= d I=92m not going to intentionally transmit in that channel. This comment a= lso applies to c) and d).] c) List unavailable channels and specify =96inf as power limit "-Inf" is not really workable, because JSON does not allow Infinity or NaNs= (http://tools.ietf.org/html/rfc4627), hence the d) proposal. d) List unavailable channels and do not specify any power limit So far, we have majority in favour of a), few people who could live or pref= er c) and sort of consensus to strike out option b) from the list above. We=92ll wait for more input on the list before declaring rough consensus fo= r the question above; then we=92ll go back to the original question on whet= her the encoding of spectrum profile should be option 1 or option 2. p.s. It looks to me, that if we want to specify unavailable channels, we ma= y need to modify the names of the paws messages to =91Spectrum schedule=92 = or sg along these lines. - Gabor --_000_CE672B41234FFpaulmarvellcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable In line below =85 speaking stro= ngly in favor of "b" 


G= abor,

 

=

I agree on possible renaming, if we want to spe= cify unavailable channels.

=  

Please see comments = inline. 

 

On Mon, Sep 23, 2013 at 12:56 PM, <<= a href=3D"mailto:Gabor.Bajko@nokia.com" target=3D"_blank">Gabor.Bajko@nokia= .com> wrote:

Vinc= e,

This proposal of yours b= elow could potentially become very confusing. The message itself is named Available Spectrum Request, and you propose the Available Spectrum Respons= e to include a bunch of channels with unspecified power levels, which are b= tw, not available channels.

 So far, we have 4 pr= oposed ways to indicate unavailable channels:

a) &= nbsp;    Not listing it, implicit unavailability

This has the drawback of= not distinguishing between being silent about a channel that is within the dat= abase's purview (channel off), and being silent about a channel that is outside the database's purview (out of scope for given ruleset).

 

[DJ =96 Why should the da= tabase care about channels that are outside the scope of the ruleset specif= ied by the radio? For example, if the specified ruleset is FCC-related, then why would I need to include Ofcom-related channels in th= e response? Am I missing something?]


The rules have strict= adjacent channel requirements.  Meeting the spectral mask for the adj= acent channels  is one of the hardest parts for fielding real equipmen= t.  If the rules allow relative measurement of the adjacent channel en= ergy, you can simply lower your transmit power to the point that you can me= et the adjacent requirements.  

For a general= White Spaces solution =96 it is critical to have knowledge for the full sp= ectrum mask.  The full spectrum mask includes adjacent non-allowed cha= nnels.

RF channel usage are NOT a binary on/off or= a simple transmit level.  The mask has a specific contour that extend= s beyond the "allowed" channel.  Transmitters will always se= nd energy in more than the allowed channel!



Paul


=

<= span style=3D"font-size: 11pt; font-family: Calibri, sans-serif; color: rgb= (31, 73, 125); ">

&n= bsp;

b)      List unavailable channels and specify the power li= mit, eg -56dbm

Since the protocol should stand on its own, independent of a= ny particular regulatory rule, do we really want to rule this out? In our i= nterpretations of the FCC rules, for example, a Database is not prevented f= rom doing this.

 

[DJ =96 I= =92m still in favor of just using the implicit unavailability method descri= bed above in a). What value is there in providing a power level for an unav= ailable channel? If I=92m the radio, I can=92t use the channel, and I=92m not goin= g to intentionally transmit in that channel. This comment also applies to c= ) and d).]

 

=

c)       List unavailable channels and specify =96inf as po= wer limit

 

"-Inf&= quot; is not really workable, because JSON does not allow Infinity or NaNs = (http://tools.ietf.org/html/= rfc4627), hence the d) proposal.

 

d)      List unavailable channels and do not specify any p= ower limit 

So far, we have ma= jority in favour of a), few people who could live or prefer c) and sort of = consensus to strike out option b) from the list above.

 

W= e=92ll wait for more input on the list before declaring rough consensus for= the question above; then we=92ll go back to the original question on whether the encoding of spectr= um profile should be option 1 or option 2.

 

p.s.= It looks to me, that if we want to specify unavailable channels, we may ne= ed to modify the names of the paws messages to =91Spectrum schedule=92 or sg along these lines.

 

=

-=           Gabor

 



--_000_CE672B41234FFpaulmarvellcom_-- From vchen@google.com Tue Sep 24 11:57:44 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E32F21F9D0A for ; Tue, 24 Sep 2013 11:57:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.826 X-Spam-Level: X-Spam-Status: No, score=-1.826 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bn7D206amTlI for ; Tue, 24 Sep 2013 11:57:43 -0700 (PDT) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id AC33721F9E2B for ; Tue, 24 Sep 2013 11:57:34 -0700 (PDT) Received: by mail-ob0-f179.google.com with SMTP id wn1so5492465obc.10 for ; Tue, 24 Sep 2013 11:57:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rZTbbhlzJuThELRBpLI4nt2IF2Ho3gGFon7di5b7c0s=; b=bfO29AStzsD3YDFI2eBZA7RMYKQiXqVlYCGt2Yjywq40+b9Qi+OZecv5S7UljKuAlI m5g0qzeNKP2waey1ck4oDPqXGYErNOKnGzQo0d0EWXWi2YHoaaziZq0ecnnQAcgaQ/v5 XqDf/tbv8fp1KHak4RRi4Li8L873AfZVWmg/Uv7Yl8exxV81MWY6GOP9xlNzmVKvBW61 RKfYX10lHuEz+/wB4Jujh5TCPkx/DYf2JSYtp0jbthcMKuug/VXYHRA58uhDY1WtauvB 9b/cj7UxARJvl9aLdQGv+GdFe4GL9sUeROmt1ySHxhWfDPmQUnx8S4NnPPEV0dVSPcw1 3ruA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=rZTbbhlzJuThELRBpLI4nt2IF2Ho3gGFon7di5b7c0s=; b=jlZlTMAEGwE3sOoB/okTDu1/cVFtW4JRHS1xpkfxktYETDIJ/XXRhz4cXTet59sWdG 5RbbQdeIXZGumQ2pVOazoNdyqpOAQpowXjWPAQOudh7O/x7GFHxMtSQ0mks2jIfcXXte bo5bND53bkaNFQ8KFoW/K3v7wpz9aGoau4xND/8RNCHEwbH+3RTpJON9IISvg8qmyTal BaTFFzCJYH0qMS/C/1WEeK0TfjEqh24PyIJshnO8NJ4jTcmU56m6u4oCJ91IKpaE4gaz 7IrtOE8+KdoA5CuoG+mM/ZmOjV8TIwIrKi0r/tIsSZuhYd/RqtzEjoXIqhPlSviYrf5z InOQ== X-Gm-Message-State: ALoCoQlMlSThpFsCz+fQM9eSeU8zYoN3zEbRgXcOpSKih+lsgQEa49HWmoOwimc0MyUOxrBJKhGbCowPnne1F2f/LjwioWNLM4GlWPJDRZwK4OhA2LQIPQbSg3O5b2P/T2/kiAnBS9XZYkCI4cyEvTI3yKKc29iICI9Lg5WGcpxZymvxL45RVRj+jd/gmTUb2vg1aui4eHB5 MIME-Version: 1.0 X-Received: by 10.60.52.81 with SMTP id r17mr27010572oeo.3.1380049052869; Tue, 24 Sep 2013 11:57:32 -0700 (PDT) Received: by 10.182.250.134 with HTTP; Tue, 24 Sep 2013 11:57:32 -0700 (PDT) In-Reply-To: <8375F6DAEFB09F48815203F1FE23B79734B364673A@shelby> References: <1ECAFF543A2FED4EA2BEB6CACE08E476053422B0@008-AM1MPN1-006.mgdnok.nokia.com> <1ECAFF543A2FED4EA2BEB6CACE08E47605342356@008-AM1MPN1-006.mgdnok.nokia.com> <1ECAFF543A2FED4EA2BEB6CACE08E47605350FC6@008-AM1MPN1-007.mgdnok.nokia.com> <8375F6DAEFB09F48815203F1FE23B79734B364673A@shelby> Date: Tue, 24 Sep 2013 11:57:32 -0700 Message-ID: From: Vincent Chen To: Don Joslyn Content-Type: multipart/alternative; boundary=001a1133073a91c51004e725b54c Cc: "paws@ietf.org" Subject: Re: [paws] Spectrum encoding discussion X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 18:57:44 -0000 --001a1133073a91c51004e725b54c Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Thanks for the comments Don. Answers inline, marked with [V] Gabor,**** > > ** ** > > I agree on possible renaming, if we want to specify unavailable channels.= * > *** > > ** ** > > Please see comments inline. **** > > ** ** > > On Mon, Sep 23, 2013 at 12:56 PM, wrote:**** > > Vince,**** > > This proposal of yours below could potentially become very confusing. The > message itself is named Available Spectrum Request, and you propose the > Available Spectrum Response to include a bunch of channels with unspecifi= ed > power levels, which are btw, not available channels. **** > > So far, we have 4 proposed ways to indicate unavailable channels:**** > > a) Not listing it, implicit unavailability**** > > This has the drawback of not distinguishing between being silent about a > channel that is within the database's purview (channel off), and being > silent about a channel that is outside the database's purview (out of sco= pe > for given ruleset).**** > > ** ** > > [DJ =96 Why should the database care about channels that are outside the > scope of the ruleset specified by the radio? For example, if the specifie= d > ruleset is FCC-related, then why would I need to include Ofcom-related > channels in the response? Am I missing something?] > [V] In my latest proposal, frequencies mentioned, but with no power is interpreted to be "within purview, but you should not use it". Gaps in the frequency (unmentioned) means "out of scope". My comment simply says that using a), you cannot distinguish between the two cases, not that we propose to say something about the "out of scope" frequencies. **** > > **** > > b) List unavailable channels and specify the power limit, eg -56dbm*= * > ** > > Since the protocol should stand on its own, independent of any particular > regulatory rule, do we really want to rule this out? In our interpretatio= ns > of the FCC rules, for example, a Database is not prevented from doing thi= s. > **** > > ** ** > > [DJ =96 I=92m still in favor of just using the implicit unavailability me= thod > described above in a). What value is there in providing a power level for > an unavailable channel? If I=92m the radio, I can=92t use the channel, an= d I=92m > not going to intentionally transmit in that channel. This comment also > applies to c) and d).] > See Paul's comment....from the perspective of a radio :) > **** > > **** > > c) List unavailable channels and specify =96inf as power limit**** > > ** ** > > "-Inf" is not really workable, because JSON does not allow Infinity or > NaNs (http://tools.ietf.org/html/rfc4627), hence the d) proposal.**** > > ** ** > > d) List unavailable channels and do not specify any power limit **** > > **** > > So far, we have majority in favour of a), few people who could live or > prefer c) and sort of consensus to strike out option b) from the list abo= ve. > **** > > **** > > We=92ll wait for more input on the list before declaring rough consensus = for > the question above; then we=92ll go back to the original question on whet= her > the encoding of spectrum profile should be option 1 or option 2.**** > > **** > > p.s. It looks to me, that if we want to specify unavailable channels, we > may need to modify the names of the paws messages to =91Spectrum schedule= =92 or > sg along these lines.**** > > **** > > - Gabor**** > > **** > > --=20 -vince --001a1133073a91c51004e725b54c Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Thanks for the comments Don. Answers inline, marked with [= V]


Gabor,

=A0

I agree on possi= ble renaming, if we want to specify unavailable channels.

=A0

Please see comments inline.=A0

=

=A0

On Mon, Sep 23, 2013 at 12:56 PM, <Gabor.Bajko@nokia.com> wrote:

Vince,<= u>

This proposal of yours be= low could potentially become very confusing. The message itself is named Av= ailable Spectrum Request, and you propose the Available Spectrum Response t= o include a bunch of channels with unspecified power levels, which are btw,= not available channels.

=A0So far, we have 4 prop= osed ways to indicate unavailable channels:

a)=A0=A0=A0=A0=A0 Not listing it, implic= it unavailability

This has th= e drawback of not distinguishing between=A0being silent about a = channel that is within the database's purview (channel off), and being = silent about a channel that is outside the database's purview (out of s= cope for given ruleset).

=A0<= /p>

[DJ =96 Why shou= ld the database care about channels that are outside the scope of the rules= et specified by the radio? For example, if the specified ruleset is FCC-rel= ated, then why would I need to include Ofcom-related channels in the respon= se? Am I missing something?]


[V] In= my latest proposal, frequencies mentioned, but with no power is interprete= d to be "within purview, but you should not use it". Gaps in the = frequency (unmentioned) means "out of scope". My comment simply s= ays that using a), you cannot distinguish between the two cases, not that w= e propose to say something about the "out of scope" frequencies.<= /div>

=A0

b)=A0=A0=A0=A0=A0 List unavailable channel= s and specify the power limit, eg -56dbm

Since the protocol should stand on its own, independent of any particular= regulatory rule, do we really want to rule this out? In our interpretation= s of the FCC rules, for example, a Database is not prevented from doing thi= s.

=A0<= /p>

[DJ =96 I=92m st= ill in favor of just using the implicit unavailability method described abo= ve in a). What value is there in providing a power level for an unavailable= channel? If I=92m the radio, I can=92t use the channel, and I=92m not goin= g to intentionally transmit in that channel. This comment also applies to c= ) and d).]


See Pa= ul's comment....from the perspective of a radio :)
=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">

=A0

c)=A0= =A0=A0=A0=A0=A0 List unavailable channels= and specify =96inf as power limit

=A0

<= /div>

"-Inf" is not really workable, b= ecause JSON does not allow Infinity or NaNs (http://tools.ietf.org/html/rfc4627),= hence the d) proposal.

=A0

d)=A0=A0=A0=A0=A0 <= /span>List unavailable channels and do not speci= fy any power limit=A0

=A0=

So far, we have majority = in favour of a), few people who could live or prefer c) and sort of consens= us to strike out option b) from the list above.

=A0<= /p>

We=92ll wait for more = input on the list before declaring rough consensus for the question above; = then we=92ll go back to the original question on whether the encoding of sp= ectrum profile should be option 1 or option 2.

=A0<= /p>

p.s. It looks to me, t= hat if we want to specify unavailable channels, we may need to modify the n= ames of the paws messages to =91Spectrum schedule=92 or sg along these line= s.

=A0<= /p>

-=A0=A0=A0=A0=A0=A0=A0=A0=A0 G= abor

=A0<= /p>




--
-vince
--001a1133073a91c51004e725b54c-- From peter@spectrumbridge.com Wed Sep 25 05:02:03 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEDEE11E80C5 for ; Wed, 25 Sep 2013 05:02:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.818 X-Spam-Level: X-Spam-Status: No, score=-1.818 tagged_above=-999 required=5 tests=[AWL=0.780, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QidgHHyoSXSt for ; Wed, 25 Sep 2013 05:01:59 -0700 (PDT) Received: from mail.spectrumbridge.com (mail.spectrumbridge.com [64.132.248.82]) by ietfa.amsl.com (Postfix) with ESMTP id 46FA021F9E96 for ; Wed, 25 Sep 2013 05:01:59 -0700 (PDT) Received: from shelby.sbi.com ([127.0.0.1]) by shelby ([127.0.0.1]) with mapi; Wed, 25 Sep 2013 08:01:58 -0400 From: Peter Stanforth To: Paul Lambert , Vincent Chen , "gabor.bajko@nokia.com" , "paws@ietf.org" Date: Wed, 25 Sep 2013 08:01:53 -0400 Thread-Topic: [paws] Spectrum encoding discussion Thread-Index: Ac655whzHaIb+GTSSbOQxpyIbDB8bQ== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.7.130812 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CE6760AA18E18peterspectrumbridgecom_" MIME-Version: 1.0 Subject: Re: [paws] Spectrum encoding discussion X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 12:02:03 -0000 --_000_CE6760AA18E18peterspectrumbridgecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Lowering the power to meet the mask is the easy way you get a radio certif= ied =96 thus permission to operate. How is that anything to do with the dat= abase - which is simply managing Regulator policy? The ruleset is going to tell you what masks and other operating parameters = are acceptable within a regulatory domain. I can't imagine a Regulator allo= wing a database operator to manipulate the unintentional interference in ad= jacent channels. If it did why stop there? Why couldn't the database manipu= late co-channel interference to nearby protected entities? I thought we had a fairly elegant and simple solution. The ruleset defines = the box the device can operate in and the database provides a specific set = of permitted channels/frequencies within that box based on the location, ti= me, and type of device making the request. All with respect to the specific= list of entities the database has been told to protect at that location at= that time. One final comment and then I will rest my case. I have had conversations wi= th several Regulators about this recently, and they do not like any notion = that the database is "thinking" about the answer. In every case they have said something along the lines of "if the database = does not explicitly give a device permission to use a channel the device is= not allowed to use it". In every case they have gone somewhat further stating that if the database = operation goes beyond this simple approach they think it highly unlikely th= at they will get cooperation from incumbents. If you don't believe me =96 g= o ask them! Which brings me back to my soap box. We want to get PAWS done so we can ena= ble white space. In my humble opinion, the more time we spend pontificating= and the more complex we make it we are likely to achieve the opposite. Peter S. From: Paul Lambert > Date: Tuesday, September 24, 2013 2:48 PM To: Don Joslyn >, Vincent Chen >, "gabor.baj= ko@nokia.com" >, "paws@ietf.org" > Subject: Re: [paws] Spectrum encoding discussion In line below =85 speaking strongly in favor of "b" Gabor, I agree on possible renaming, if we want to specify unavailable channels. Please see comments inline. On Mon, Sep 23, 2013 at 12:56 PM, > wrote: Vince, This proposal of yours below could potentially become very confusing. The m= essage itself is named Available Spectrum Request, and you propose the Avai= lable Spectrum Response to include a bunch of channels with unspecified pow= er levels, which are btw, not available channels. So far, we have 4 proposed ways to indicate unavailable channels: a) Not listing it, implicit unavailability This has the drawback of not distinguishing between being silent about a ch= annel that is within the database's purview (channel off), and being silent= about a channel that is outside the database's purview (out of scope for g= iven ruleset). [DJ =96 Why should the database care about channels that are outside the sc= ope of the ruleset specified by the radio? For example, if the specified ru= leset is FCC-related, then why would I need to include Ofcom-related channe= ls in the response? Am I missing something?] The rules have strict adjacent channel requirements. Meeting the spectral = mask for the adjacent channels is one of the hardest parts for fielding re= al equipment. If the rules allow relative measurement of the adjacent chan= nel energy, you can simply lower your transmit power to the point that you = can meet the adjacent requirements. For a general White Spaces solution =96 it is critical to have knowledge fo= r the full spectrum mask. The full spectrum mask includes adjacent non-all= owed channels. RF channel usage are NOT a binary on/off or a simple transmit level. The m= ask has a specific contour that extends beyond the "allowed" channel. Tran= smitters will always send energy in more than the allowed channel! Paul b) List unavailable channels and specify the power limit, eg -56dbm Since the protocol should stand on its own, independent of any particular r= egulatory rule, do we really want to rule this out? In our interpretations = of the FCC rules, for example, a Database is not prevented from doing this. [DJ =96 I=92m still in favor of just using the implicit unavailability meth= od described above in a). What value is there in providing a power level fo= r an unavailable channel? If I=92m the radio, I can=92t use the channel, an= d I=92m not going to intentionally transmit in that channel. This comment a= lso applies to c) and d).] c) List unavailable channels and specify =96inf as power limit "-Inf" is not really workable, because JSON does not allow Infinity or NaNs= (http://tools.ietf.org/html/rfc4627), hence the d) proposal. d) List unavailable channels and do not specify any power limit So far, we have majority in favour of a), few people who could live or pref= er c) and sort of consensus to strike out option b) from the list above. We=92ll wait for more input on the list before declaring rough consensus fo= r the question above; then we=92ll go back to the original question on whet= her the encoding of spectrum profile should be option 1 or option 2. p.s. It looks to me, that if we want to specify unavailable channels, we ma= y need to modify the names of the paws messages to =91Spectrum schedule=92 = or sg along these lines. - Gabor --_000_CE6760AA18E18peterspectrumbridgecom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
 Lowering the power to mee= t the mask is the easy way you get a radio certified =96 thus permission to= operate. How is that anything to do with the database - which is simply ma= naging Regulator policy?
The ruleset is going to tell you what ma= sks and other operating parameters are acceptable within a regulatory domai= n. I can't imagine a Regulator allowing a database operator to manipulate t= he unintentional interference in adjacent channels. If it did why stop ther= e? Why couldn't the database manipulate co-channel interference to nearby p= rotected entities?
I thought we had a fairly elegant and simple s= olution. The ruleset defines the box the device can operate in and the data= base provides a specific set of permitted channels/frequencies within that = box based on the location, time, and type of device making the request. All= with respect to the specific list of entities the database has been told t= o protect at that location at that time.

One final= comment and then I will rest my case. I have had conversations with severa= l Regulators about this recently, and they do not like any notion that the = database is "thinking" about the answer.
In every case = they have said something along the lines of "if the database does not = explicitly give a device permission to use a channel the device is not allo= wed to use it".
In every case they have gone somewhat furthe= r stating that if the database operation goes beyond this simple approach t= hey think it highly unlikely that they will get cooperation from incumbents= . If you don't believe me =96 go ask them!
Which brings me back t= o my soap box. We want to get PAWS done so we can enable white space. In my= humble opinion, the more time we spend pontificating and the more complex = we make it we are likely to achieve the opposite.
Peter S.
<= div>

From: = Paul Lambert <paul@marvell.c= om>
Date: Tuesday, Septe= mber 24, 2013 2:48 PM
To: Don J= oslyn <d.joslyn@spectrumb= ridge.com>, Vincent Chen <vch= en@google.com>, "gabor= .bajko@nokia.com" <Gab= or.Bajko@nokia.com>, "paws@iet= f.org" <paws@ietf.org><= br>Subject: Re: [paws] Spectrum en= coding discussion

In line below =85 speaking strongly in favor of "b" 


Gabor,

 

I agree on possi= ble renaming, if we want to specify unavailable channels.

 

Please see comments inline. 

 

On Mon, = Sep 23, 2013 at 12:56 PM, <Gabor.Bajko@nokia.com> wrote:

=

Vince,

This proposal of yours below could potentially become very confusing= . The message itself is named Available Spectrum Request, and you propose the Available Spectru= m Response to include a bunch of channels with unspecified power levels, wh= ich are btw, not available channels.

 So far, we have 4 pr= oposed ways to indicate unavailable channels:

a) &= nbsp;    Not listing it, implicit unavailability

This has the drawback of= not distinguishing between being silent about a channel that is within the dat= abase's purview (channel off), and being silent about a channel that is outside the database's purview (out of scope for given ruleset).

 

[DJ =96 Why should the da= tabase care about channels that are outside the scope of the ruleset specif= ied by the radio? For example, if the specified ruleset is FCC-related, then why would I need to include Ofcom-related cha= nnels in the response? Am I missing something?]


The rules = have strict adjacent channel requirements.  Meeting the spectral mask = for the adjacent channels  is one of the hardest parts for fielding re= al equipment.  If the rules allow relative measurement of the adjacent= channel energy, you can simply lower your transmit power to the point that you can meet the adjacent requ= irements.  

For a general White Spaces soluti= on =96 it is critical to have knowledge for the full spectrum mask.  T= he full spectrum mask includes adjacent non-allowed channels.
RF channel usage are NOT a binary on/off or a simple transmit l= evel.  The mask has a specific contour that extends beyond the "a= llowed" channel.  Transmitters will always send energy in more th= an the allowed channel!



<= div>Paul


 

<= /div>

b) &= nbsp;    List unavailable channels and specify the power li= mit, eg -56dbm

Since the protocol should stand on its own, independent of a= ny particular regulatory rule, do we really want to rule this out? In our i= nterpretations of the FCC rules, for example, a Database is not prevented f= rom doing this.

 

[DJ =96 I= =92m still in favor of just using the implicit unavailability method descri= bed above in a). What value is there in providing a power level for an unavailable channel? If I=92m the radio, I can=92t use the channel, and= I=92m not going to intentionally transmit in that channel. This comment al= so applies to c) and d).]

 

c)       List unavailable channels and specify =96inf as po= wer limit

 

"-Inf&= quot; is not really workable, because JSON does not allow Infinity or NaNs = (http://tools.ietf.org/html/= rfc4627), hence the d) proposal.

 

d)      List unavailable channels and do not specify any p= ower limit 

So far, we have ma= jority in favour of a), few people who could live or prefer c) and sort of consensus to strike out option b) from the list above.

 

We=92ll wait for more input on the list before declaring rough = consensus for the question above; then we=92ll go back to the original question on whether the encodi= ng of spectrum profile should be option 1 or option 2.

 

p.s. It looks to me, that if we want to specify unavailable channel= s, we may need to modify the names of the paws messages to =91Spectrum schedule=92 or sg along thes= e lines.

 =

-          Gabor

 

=


--_000_CE6760AA18E18peterspectrumbridgecom_-- From vchen@google.com Wed Sep 25 09:10:00 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C64821F9D42 for ; Wed, 25 Sep 2013 09:10:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.843 X-Spam-Level: X-Spam-Status: No, score=-1.843 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9r3azk7g0Z0c for ; Wed, 25 Sep 2013 09:09:59 -0700 (PDT) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 9DC2121F9D04 for ; Wed, 25 Sep 2013 09:09:58 -0700 (PDT) Received: by mail-ob0-f171.google.com with SMTP id wm4so6981752obc.2 for ; Wed, 25 Sep 2013 09:09:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fX56HF8QS8/J78mvlD1G/gu3pNseOFN30IBczYPuFs0=; b=XSYNSE039Li9xJx8mUOBCDbBk6C/5rUD0yQHDmWD9bOHmt1uw/Lr5YpGq6VPdUUphr ie0etWsyjH1Dg7R9qxJdkDbIdJLF/0IuHoZ1MHrCohdJNUACcEKyT9X1Vw6qGLTMO0mb HECdzThjwf+BXyLtmvy3vKc071vvWuPPCVq2dtnQ2Lm/FD5mfdAw3a2wsqZA+HziCvyI LpdJWP5c3pRhegBpHlKOeW+tPLqqQEpfgsWREtaSltP1QvpLcXU5iew913ZoLcnzixTl FEgh5n0B0xgo9VUbVscwf6BEsPHyMTt5EmmWI6uUnocB7Um6bCT0CuYIlb9EGL6w0S7w 4FYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=fX56HF8QS8/J78mvlD1G/gu3pNseOFN30IBczYPuFs0=; b=ZaHB+pgp3lEBpUQ+KlMkwOBKKM/aZBdZOZEcwC5iK26YwCfV7dNYGCeWVd9zIDsp0w t0Y7lkDQe3QziGVQEU/zS+z/xxAorVknqye3eO1MQcHh7ASeg76sKkJKblRYWNtGG/ml 0C0JNlSIIeDGdY45G/Hx+11aRWzeKetJ2JeeoKb7QzrvUfxyBbsV35frimXPSMlj1ubo i64mzpDM7ykXxjLBH6zdqiLyvmzZd6rVyhVDuHDEUyp2FP56xOo0cgGwu9HzamvjsjNK YScgVFrsH2q7AMR9uD/R+5DPt1ezpUqEb0Wq19Eh9zbE/Le5ACJx3Xy+O2opK4ORwBRR btrw== X-Gm-Message-State: ALoCoQlhPCPkIcZHqcm8s1MfZd1abOWMATM82JP3n4hO0G1PEPuI4uchZygz5WCPTFLIKbmZp2Ru2jRp0fPDWuG452KBepXvR0EvdF3rkT7Mp9LOWg8zHVHQX+JmF1aO8LzcwJzqt4d01m33epY5xKL/oYit3+KNG6lMoUwtEXgFRNV4lgnpCZprMOTEDfxvOj+YKbNua/5/ MIME-Version: 1.0 X-Received: by 10.60.80.8 with SMTP id n8mr13854957oex.33.1380125398088; Wed, 25 Sep 2013 09:09:58 -0700 (PDT) Received: by 10.182.250.134 with HTTP; Wed, 25 Sep 2013 09:09:57 -0700 (PDT) In-Reply-To: References: Date: Wed, 25 Sep 2013 09:09:57 -0700 Message-ID: From: Vincent Chen To: Peter Stanforth Content-Type: multipart/alternative; boundary=089e011606781965f904e7377c94 Cc: "paws@ietf.org" Subject: Re: [paws] Spectrum encoding discussion X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 16:10:00 -0000 --089e011606781965f904e7377c94 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Thanks for sharing your insights Peter. This is an opportunity to have the protocol be a bit more forward thinking than what current regulators are thinking. Let's try to focus on Gabor's question again of how to express "unavailability", but phrasing it differently. If we were to take the view that the Database provides responses for frequencies where the device may operate, then - Any frequency ranges missing for the response means the device "is not granted permission" to operate in those frequencies under the rules implemented by the Database Then is it still useful to distinguish why permission is not granted? (off vs outside band plan) If not, then Option a), simply having gaps in the frequency ranges would satisfy this use case. Is this a good compromise? -vince On Wed, Sep 25, 2013 at 5:01 AM, Peter Stanforth wrote: > Lowering the power to meet the mask is the easy way you get a radio > certified =96 thus permission to operate. How is that anything to do with= the > database - which is simply managing Regulator policy? > The ruleset is going to tell you what masks and other operating parameter= s > are acceptable within a regulatory domain. I can't imagine a Regulator > allowing a database operator to manipulate the unintentional interference > in adjacent channels. If it did why stop there? Why couldn't the database > manipulate co-channel interference to nearby protected entities? > I thought we had a fairly elegant and simple solution. The ruleset define= s > the box the device can operate in and the database provides a specific se= t > of permitted channels/frequencies within that box based on the location, > time, and type of device making the request. All with respect to the > specific list of entities the database has been told to protect at that > location at that time. > > One final comment and then I will rest my case. I have had conversations > with several Regulators about this recently, and they do not like any > notion that the database is "thinking" about the answer. > In every case they have said something along the lines of "if the databas= e > does not explicitly give a device permission to use a channel the device = is > not allowed to use it". > In every case they have gone somewhat further stating that if the databas= e > operation goes beyond this simple approach they think it highly unlikely > that they will get cooperation from incumbents. If you don't believe me = =96 > go ask them! > Which brings me back to my soap box. We want to get PAWS done so we can > enable white space. In my humble opinion, the more time we spend > pontificating and the more complex we make it we are likely to achieve th= e > opposite. > Peter S. > > > From: Paul Lambert > Date: Tuesday, September 24, 2013 2:48 PM > To: Don Joslyn , Vincent Chen < > vchen@google.com>, "gabor.bajko@nokia.com" , " > paws@ietf.org" > > Subject: Re: [paws] Spectrum encoding discussion > > In line below =85 speaking strongly in favor of "b" > > > Gabor,**** > > ** ** > > I agree on possible renaming, if we want to specify unavailable channels.= * > *** > > ** ** > > Please see comments inline. **** > > ** ** > > On Mon, Sep 23, 2013 at 12:56 PM, wrote:**** > > Vince,**** > > This proposal of yours below could potentially become very confusing. The > message itself is named Available Spectrum Request, and you propose the > Available Spectrum Response to include a bunch of channels with unspecifi= ed > power levels, which are btw, not available channels. **** > > So far, we have 4 proposed ways to indicate unavailable channels:**** > > a) Not listing it, implicit unavailability**** > > This has the drawback of not distinguishing between being silent about a > channel that is within the database's purview (channel off), and being > silent about a channel that is outside the database's purview (out of sco= pe > for given ruleset).**** > > ** ** > > [DJ =96 Why should the database care about channels that are outside the > scope of the ruleset specified by the radio? For example, if the specifie= d > ruleset is FCC-related, then why would I need to include Ofcom-related > channels in the response? Am I missing something?] > > > The rules have strict adjacent channel requirements. Meeting the spectra= l > mask for the adjacent channels is one of the hardest parts for fielding > real equipment. If the rules allow relative measurement of the adjacent > channel energy, you can simply lower your transmit power to the point tha= t > you can meet the adjacent requirements. > > For a general White Spaces solution =96 it is critical to have knowledge = for > the full spectrum mask. The full spectrum mask includes adjacent > non-allowed channels. > > RF channel usage are NOT a binary on/off or a simple transmit level. The > mask has a specific contour that extends beyond the "allowed" channel. > Transmitters will always send energy in more than the allowed channel! > > > > Paul > > > **** > > **** > > b) List unavailable channels and specify the power limit, eg -56dbm*= * > ** > > Since the protocol should stand on its own, independent of any particular > regulatory rule, do we really want to rule this out? In our interpretatio= ns > of the FCC rules, for example, a Database is not prevented from doing thi= s. > **** > > ** ** > > [DJ =96 I=92m still in favor of just using the implicit unavailability me= thod > described above in a). What value is there in providing a power level for > an unavailable channel? If I=92m the radio, I can=92t use the channel, an= d I=92m > not going to intentionally transmit in that channel. This comment also > applies to c) and d).]**** > > **** > > c) List unavailable channels and specify =96inf as power limit**** > > ** ** > > "-Inf" is not really workable, because JSON does not allow Infinity or > NaNs (http://tools.ietf.org/html/rfc4627), hence the d) proposal.**** > > ** ** > > d) List unavailable channels and do not specify any power limit **** > > **** > > So far, we have majority in favour of a), few people who could live or > prefer c) and sort of consensus to strike out option b) from the list abo= ve. > **** > > **** > > We=92ll wait for more input on the list before declaring rough consensus = for > the question above; then we=92ll go back to the original question on whet= her > the encoding of spectrum profile should be option 1 or option 2.**** > > **** > > p.s. It looks to me, that if we want to specify unavailable channels, we > may need to modify the names of the paws messages to =91Spectrum schedule= =92 or > sg along these lines.**** > > **** > > - Gabor**** > > **** > > > > --=20 -vince --089e011606781965f904e7377c94 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Thanks for sharing your insights Peter.

This is an opportunity to have the protocol be a bit more forward thinking= than what current regulators are thinking.

Let= 9;s try to focus on Gabor's question again of how to express "unav= ailability", but phrasing it differently.

If we were to take the view that the Database provides = responses for frequencies where the device may operate, then

=
=A0- Any frequency ranges missing for the response means the dev= ice "is not granted permission" to operate in those frequencies u= nder the rules implemented by the Database

Then is it still useful to distinguish why permission i= s not granted? (off vs outside band plan)

If not, = then Option a), simply having gaps in the frequency ranges would satisfy th= is use case.

Is this a good compromise?

-vi= nce


On Wed, Sep 25, 2013 at 5:01 AM, Peter Stanforth <peter@spectrumb= ridge.com> wrote:
=A0Lowering the power to meet the mask is the easy way you get = a radio certified =96 thus permission to operate. How is that anything to d= o with the database - which is simply managing Regulator policy?
The ruleset is going to tell you what masks and other operating parame= ters are acceptable within a regulatory domain. I can't imagine a Regul= ator allowing a database operator to manipulate the unintentional interfere= nce in adjacent channels. If it did why stop there? Why couldn't the da= tabase manipulate co-channel interference to nearby protected entities?
I thought we had a fairly elegant and simple solution. The ruleset def= ines the box the device can operate in and the database provides a specific= set of permitted channels/frequencies within that box based on the locatio= n, time, and type of device making the request. All with respect to the spe= cific list of entities the database has been told to protect at that locati= on at that time.

One final comment and then I will rest my case. I have = had conversations with several Regulators about this recently, and they do = not like any notion that the database is "thinking" about the ans= wer.
In every case they have said something along the lines of "if the= database does not explicitly give a device permission to use a channel the= device is not allowed to use it".
In every case they have g= one somewhat further stating that if the database operation goes beyond thi= s simple approach they think it highly unlikely that they will get cooperat= ion from incumbents. If you don't believe me =96 go ask them!
Which brings me back to my soap box. We want to get PAWS done so we ca= n enable white space. In my humble opinion, the more time we spend pontific= ating and the more complex we make it we are likely to achieve the opposite= .
Peter S.



In line below =85 speaking strongly in favor of "b"=A0


Gabor,

=A0

I agree on= possible renaming, if we want to specify unavailable channels.

=A0

Please see comments inline.=A0

<= p class=3D"MsoNormal">=A0

On M= on, Sep 23, 2013 at 12:56 PM, <Gabor.Bajko@nokia.com> wrote:

Vince,

This proposal of yours below could potentially = become very confusing. The message itself is named Available Spectrum Request, and you propose the Available Spectru= m Response to include a bunch of channels with unspecified power levels, wh= ich are btw, not available channels.

=A0So far, we have = 4 proposed ways to indicate unavailable channels:

<= p> a)=A0=A0=A0=A0= =A0 Not listing it, implicit unavailability=

This has the drawback of not di= stinguishing between=A0being silent about a channel that is within the database's purv= iew (channel off), and being silent about a channel that is outside the database's purview (out of scope for given ruleset).=

=A0

[DJ =96 Why should the database care about c= hannels that are outside the scope of the ruleset specified by the radio? F= or example, if the specified ruleset is FCC-related, then why would I need to include Ofcom-related cha= nnels in the response? Am I missing something?]




RF channel usage are NOT a binary on/off or a simple tr= ansmit level. =A0The mask has a specific contour that extends beyond the &q= uot;allowed" channel. =A0Transmitters will always send energy in more = than the allowed channel!



Paul

=

=A0

b)=A0=A0=A0=A0=A0 List unavailable channels and specify the power limit, eg -5= 6dbm

Since the protocol should stand on its own, independent of any particular r= egulatory rule, do we really want to rule this out? In our interpretations = of the FCC rules, for example, a Database is not prevented from doing this.=

=A0

[DJ =96 I=92m still in favor of just using the implicit unav= ailability method described above in a). What value is there in providing a= power level for an unavailable channel? If I=92m the radio, I can=92t use the channel, and= I=92m not going to intentionally transmit in that channel. This comment al= so applies to c) and d).]

=A0

c)=A0=A0=A0=A0=A0=A0 List unavailable channels and specify =96inf as power limit<= /span>

=A0

=A0

d)=A0=A0=A0=A0=A0 List unavailable channels and do not specify any power limit= =A0

=A0

So far, we have majority in favour of a), few peop= le who could live or prefer c) and sort of consensus to strike out option b) from the list above.=

=A0

We=92ll wait for more input on the list before declaring rough cons= ensus for the question above; then we=92ll go back to the original question on whether the encodi= ng of spectrum profile should be option 1 or option 2.=

=A0

p.s. It looks to me, that if we want to spec= ify unavailable channels, we may need to modify the names of the paws messages to =91Spectrum schedule=92 or sg along thes= e lines.

=A0<= u>

-=A0=A0=A0= =A0=A0=A0=A0=A0=A0 Gabor

=A0

<= /span>





--
-vince
--089e011606781965f904e7377c94-- From peter@spectrumbridge.com Wed Sep 25 11:05:13 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5217421F9F01 for ; Wed, 25 Sep 2013 11:05:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.948 X-Spam-Level: X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EbEV9iy9drIJ for ; Wed, 25 Sep 2013 11:05:06 -0700 (PDT) Received: from mail.spectrumbridge.com (mail.spectrumbridge.com [64.132.248.82]) by ietfa.amsl.com (Postfix) with ESMTP id 63DE321F9F3A for ; Wed, 25 Sep 2013 11:05:03 -0700 (PDT) Received: from shelby.sbi.com ([127.0.0.1]) by shelby ([127.0.0.1]) with mapi; Wed, 25 Sep 2013 14:05:02 -0400 From: Peter Stanforth To: Vincent Chen Date: Wed, 25 Sep 2013 14:04:56 -0400 Thread-Topic: [paws] Spectrum encoding discussion Thread-Index: Ac66GcDR36tEYiFsSWKRfw3LQy9n1Q== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.7.130812 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CE68976F19202peterspectrumbridgecom_" MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] Spectrum encoding discussion X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 18:05:13 -0000 --_000_CE68976F19202peterspectrumbridgecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thanks Vince, I am not trying to grind an axe or be a luddite. I am concer= ned that the battle for spectrum sharing is far from over and the more tang= ible progress we can make with PAWS the better prepared we are. So I am try= ing to be pragmatic in suggesting we try to get a PAWS standard completed q= uickly and one that minimizes the push back from the incumbents. This means= we need to be able to get the Regulators to be able to continue to suppor= t us. If I understand what you are suggesting, as a US TVWS database, then my ban= d plan would be channels 2-51 and I would return a list of 2-51 channels. = If the list of 2-51 was populated by either "off" or a "permitted use" then= I have logically addressed the regulator concern. By implication anything = outside of that list is outside my band plan. Therefore I have not only tol= d you what channels you can use I have informed you why you can't use anyth= ing else (off =3D no permission, anything else is out of band plan). That = seems like a reasonable compromise to me. Peter S. From: Vincent Chen > Date: Wednesday, September 25, 2013 12:09 PM To: Peter Stanforth > Cc: Paul Lambert >, "gabor.bajko@= nokia.com" >, "paws@ietf.org" > Subject: Re: [paws] Spectrum encoding discussion Thanks for sharing your insights Peter. This is an opportunity to have the protocol be a bit more forward thinking = than what current regulators are thinking. Let's try to focus on Gabor's question again of how to express "unavailabil= ity", but phrasing it differently. If we were to take the view that the Database provides responses for freque= ncies where the device may operate, then - Any frequency ranges missing for the response means the device "is not g= ranted permission" to operate in those frequencies under the rules implemen= ted by the Database Then is it still useful to distinguish why permission is not granted? (off = vs outside band plan) If not, then Option a), simply having gaps in the frequency ranges would sa= tisfy this use case. Is this a good compromise? -vince On Wed, Sep 25, 2013 at 5:01 AM, Peter Stanforth > wrote: Lowering the power to meet the mask is the easy way you get a radio certif= ied =96 thus permission to operate. How is that anything to do with the dat= abase - which is simply managing Regulator policy? The ruleset is going to tell you what masks and other operating parameters = are acceptable within a regulatory domain. I can't imagine a Regulator allo= wing a database operator to manipulate the unintentional interference in ad= jacent channels. If it did why stop there? Why couldn't the database manipu= late co-channel interference to nearby protected entities? I thought we had a fairly elegant and simple solution. The ruleset defines = the box the device can operate in and the database provides a specific set = of permitted channels/frequencies within that box based on the location, ti= me, and type of device making the request. All with respect to the specific= list of entities the database has been told to protect at that location at= that time. One final comment and then I will rest my case. I have had conversations wi= th several Regulators about this recently, and they do not like any notion = that the database is "thinking" about the answer. In every case they have said something along the lines of "if the database = does not explicitly give a device permission to use a channel the device is= not allowed to use it". In every case they have gone somewhat further stating that if the database = operation goes beyond this simple approach they think it highly unlikely th= at they will get cooperation from incumbents. If you don't believe me =96 g= o ask them! Which brings me back to my soap box. We want to get PAWS done so we can ena= ble white space. In my humble opinion, the more time we spend pontificating= and the more complex we make it we are likely to achieve the opposite. Peter S. From: Paul Lambert > Date: Tuesday, September 24, 2013 2:48 PM To: Don Joslyn >, Vincent Chen >, "gabor.baj= ko@nokia.com" >, "paws@ietf.org" > Subject: Re: [paws] Spectrum encoding discussion In line below =85 speaking strongly in favor of "b" Gabor, I agree on possible renaming, if we want to specify unavailable channels. Please see comments inline. On Mon, Sep 23, 2013 at 12:56 PM, > wrote: Vince, This proposal of yours below could potentially become very confusing. The m= essage itself is named Available Spectrum Request, and you propose the Avai= lable Spectrum Response to include a bunch of channels with unspecified pow= er levels, which are btw, not available channels. So far, we have 4 proposed ways to indicate unavailable channels: a) Not listing it, implicit unavailability This has the drawback of not distinguishing between being silent about a ch= annel that is within the database's purview (channel off), and being silent= about a channel that is outside the database's purview (out of scope for g= iven ruleset). [DJ =96 Why should the database care about channels that are outside the sc= ope of the ruleset specified by the radio? For example, if the specified ru= leset is FCC-related, then why would I need to include Ofcom-related channe= ls in the response? Am I missing something?] The rules have strict adjacent channel requirements. Meeting the spectral = mask for the adjacent channels is one of the hardest parts for fielding re= al equipment. If the rules allow relative measurement of the adjacent chan= nel energy, you can simply lower your transmit power to the point that you = can meet the adjacent requirements. For a general White Spaces solution =96 it is critical to have knowledge fo= r the full spectrum mask. The full spectrum mask includes adjacent non-all= owed channels. RF channel usage are NOT a binary on/off or a simple transmit level. The m= ask has a specific contour that extends beyond the "allowed" channel. Tran= smitters will always send energy in more than the allowed channel! Paul b) List unavailable channels and specify the power limit, eg -56dbm Since the protocol should stand on its own, independent of any particular r= egulatory rule, do we really want to rule this out? In our interpretations = of the FCC rules, for example, a Database is not prevented from doing this. [DJ =96 I=92m still in favor of just using the implicit unavailability meth= od described above in a). What value is there in providing a power level fo= r an unavailable channel? If I=92m the radio, I can=92t use the channel, an= d I=92m not going to intentionally transmit in that channel. This comment a= lso applies to c) and d).] c) List unavailable channels and specify =96inf as power limit "-Inf" is not really workable, because JSON does not allow Infinity or NaNs= (http://tools.ietf.org/html/rfc4627), hence the d) proposal. d) List unavailable channels and do not specify any power limit So far, we have majority in favour of a), few people who could live or pref= er c) and sort of consensus to strike out option b) from the list above. We=92ll wait for more input on the list before declaring rough consensus fo= r the question above; then we=92ll go back to the original question on whet= her the encoding of spectrum profile should be option 1 or option 2. p.s. It looks to me, that if we want to specify unavailable channels, we ma= y need to modify the names of the paws messages to =91Spectrum schedule=92 = or sg along these lines. - Gabor -- -vince --_000_CE68976F19202peterspectrumbridgecom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Thanks Vince, I am not trying t= o grind an axe or be a luddite.  I am concerned that the battle for sp= ectrum sharing is far from over and the more tangible progress we can make = with PAWS the better prepared we are. So I am trying to be pragmatic in sug= gesting we try to get a PAWS standard completed quickly and one that minimi= zes the push back from the incumbents. This means we need to be able to get= the Regulators to  be able to continue to support us. 
If I understand what you are suggesting, as a US TVWS database, then my ba= nd plan would be channels 2-51 and I would return a list of 2-51 channels. =  If the list of 2-51 was populated by either "off" or a &quo= t;permitted use" then I have logically addressed the regulator concern= . By implication anything outside of that list is outside my band plan= . Therefore I have not only told you what channels you can use I have infor= med you why you can't use anything else (off =3D no permission, anything el= se is out of band plan).  That seems like a reasonable compromise to m= e.
Peter S.

From: Vincent Chen <vch= en@google.com>
Date: Wed= nesday, September 25, 2013 12:09 PM
To:= Peter Stanforth <pe= ter@spectrumbridge.com>
Cc: Paul Lambert <paul@marvell.com>, "gabor.bajko@nokia.co= m" <Gabor.Bajko@nokia.= com>, "paws@ietf.org"= <paws@ietf.org>
Subject: Re: [paws] Spectrum encoding discuss= ion

Thanks for sharing y= our insights Peter.

This is an opportunity to have the protocol be a bit mo= re forward thinking than what current regulators are thinking.
Let's try to focus on Gabor's question again of how to express= "unavailability", but phrasing it differently.

If we were to take the view that the Database provides responses fo= r frequencies where the device may operate, then

&= nbsp;- Any frequency ranges missing for the response means the device "= ;is not granted permission" to operate in those frequencies under the = rules implemented by the Database

Then is it still= useful to distinguish why permission is not granted? (off vs outside band = plan)

If not, then Option a), simply having gaps i= n the frequency ranges would satisfy this use case.

Is this a good compromise?

-vince


On Wed, Sep 25, = 2013 at 5:01 AM, Peter Stanforth <peter@spe= ctrumbridge.com> wrote:
 Lowering the power to meet the mask is the easy way you get = a radio certified =96 thus permission to operate. How is that anything to d= o with the database - which is simply managing Regulator policy?
= The ruleset is going to tell you what masks and other operating parameters = are acceptable within a regulatory domain. I can't imagine a Regulator allo= wing a database operator to manipulate the unintentional interference in ad= jacent channels. If it did why stop there? Why couldn't the database manipulate co-channel interferen= ce to nearby protected entities?
I thought we had a fairly elegan= t and simple solution. The ruleset defines the box the device can operate i= n and the database provides a specific set of permitted channels/frequencie= s within that box based on the location, time, and type of device making the request. All with respect to the specific list of entities the databas= e has been told to protect at that location at that time.

One final comment and then I will rest my case. I have had conversa= tions with several Regulators about this recently, and they do not like any= notion that the database is "thinking" about the answer.
In every case they have said something along the lines of "if the d= atabase does not explicitly give a device permission to use a channel the d= evice is not allowed to use it".
In every case they have gon= e somewhat further stating that if the database operation goes beyond this = simple approach they think it highly unlikely that they will get cooperatio= n from incumbents. If you don't believe me =96 go ask them!
Which= brings me back to my soap box. We want to get PAWS done so we can enable w= hite space. In my humble opinion, the more time we spend pontificating and = the more complex we make it we are likely to achieve the opposite.
Peter S.


From: Paul Lambert <paul@marvell.com>
Date: Tuesday, September 24, 2013 2:48 PM
<= span style=3D"font-weight:bold">To: Don Joslyn <d.joslyn@spectrumbridge.com= >, Vincent Chen <vchen@google.com>, "gabor.bajko@nokia.com" <Gabor.Bajko= @nokia.com>, "paws@ietf.org" <paws@ietf.org>

Subject: Re: = [paws] Spectrum encoding discussion
<= div>
In line below =85 speaking strongly in favor of "b" 


Gabor,<= u>

 

I agree on possible renaming, if we want to specify un= available channels.

<= /u> 

Please see comments i= nline. 

&nbs= p;

On Mon, Sep 23, 2013 at 12:56 PM, = <Gabor.Bajko@= nokia.com> wrote:

= Vince,

This proposal of yours below could potentially become very c= onfusing. The message itself is named Available Spectrum Request, and you p= ropose the Available Spectrum Response to include a bunch of channels with unspecified power le= vels, which are btw, not available channels.

 So = far, we have 4 proposed ways to indicate unavailable channels:

a)      Not listing it, implicit unavailability<= /u>

This has the drawback= of not distinguishing between being silent about a channel that is within the = database's purview (channel off), and being silent about a channel that is = outside the database's purview (out of scope for given ruleset).

 =

[DJ =96 Why should the databas= e care about channels that are outside the scope of the ruleset specified b= y the radio? For example, if the specified ruleset is FCC-related, then why would I need to include Ofcom-related channels in th= e response? Am I missing something?]


The rules have strict= adjacent channel requirements.  Meeting the spectral mask for the adj= acent channels  is one of the hardest parts for fielding real equipmen= t.  If the rules allow relative measurement of the adjacent channel en= ergy, you can simply lower your transmit power to the point that you can meet the adjacent requ= irements.  

For a general White Spaces soluti= on =96 it is critical to have knowledge for the full spectrum mask.  T= he full spectrum mask includes adjacent non-allowed channels.
RF channel usage are NOT a binary on/off or a simple transmit l= evel.  The mask has a specific contour that extends beyond the "a= llowed" channel.  Transmitters will always send energy in more th= an the allowed channel!



<= div>Paul


 

b)      List unavailable channels and specify the power li= mit, eg -56dbm

Since the protocol should stand on its own, independent of= any particular regulatory rule, do we really want to rule this out? In our= interpretations of the FCC rules, for example, a Database is not prevented= from doing this.

 

[D= J =96 I=92m still in favor of just using the implicit unavailability method= described above in a). What value is there in providing a power level for = an unavailable channel? If I=92m the radio, I can=92t use the channel, and I=92m not goin= g to intentionally transmit in that channel. This comment also applies to c= ) and d).]

 =

c)       List unavailable channels and specify =96inf as po= wer limit

 

"= ;-Inf" is not really workable, because JSON does not allow Infinity or= NaNs (htt= p://tools.ietf.org/html/rfc4627), hence the d) proposal.<= /p>

 

= d)   &n= bsp;  List unavailable channels and do not specify any p= ower limit 

 

So far, we have majority in favour of a), few people who co= uld live or prefer c) and sort of consensus to strike out option b) from th= e list above.

 

We=92ll wait for more input on the list before declaring rough consensus f= or the question above; then we=92ll go back to the original question on whe= ther the encoding of spectrum profile should be option 1 or option 2.

 

<= p class=3D"MsoNormal">p.s. It looks to me, that if we wan= t to specify unavailable channels, we may need to modify the names of the p= aws messages to =91Spectrum schedule=92 or sg along these lines.

 

-      &nbs= p;   Gabor

 





--
-vince --_000_CE68976F19202peterspectrumbridgecom_-- From vchen@google.com Wed Sep 25 11:28:53 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C336111E8135 for ; Wed, 25 Sep 2013 11:28:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.856 X-Spam-Level: X-Spam-Status: No, score=-1.856 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B5nD93FS6l6k for ; Wed, 25 Sep 2013 11:28:52 -0700 (PDT) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 0565811E812B for ; Wed, 25 Sep 2013 11:28:51 -0700 (PDT) Received: by mail-ob0-f169.google.com with SMTP id wp4so115405obc.14 for ; Wed, 25 Sep 2013 11:28:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8FSgn/hvnpS+IQm5w9GDcGiBzko7uJr3S92GPl68oNQ=; b=DG5bSoTYTk+sAUANcBpJYxrCHqCM+h22lXck9D2B8lhG6TJmS2Akr7VjYakm0RCW6k 99sAugbN5gRAa741qn9UU1G2S3TGmByqdlfSLRgySuM4SThjbVlUkYlAZEmrXcBO8kyk S1yhE2xQKl4d/C0y/bjKKGMRQUlhpvk99s9YsJeRIc03Ed6k6+jf36pZb8q8ZOBdgG8Y XXRiTismeT8yfpNWBxWKFIj9Vx0uA43dQrBUM7ulyKz8BmB9XVevF9l8ckdetP6PYzS4 o0MUI5Nn87bcZ5P8ejLXN6ftFGRLKFhRHy4sRdZqXugVLmMGuUwhLAe40dXt6GnPQdw1 4foQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=8FSgn/hvnpS+IQm5w9GDcGiBzko7uJr3S92GPl68oNQ=; b=dKCSI2BENYc5s7DhPxyDWykNWRfwx8mSaWMjiLRx0sEOJvSrKKbPCJyQ4TvoSifwce LhdRmtCkVXv90d0CUbVx6Wpdd9WS7SYD5Dbn4TTIe+9uEkzUwVUtvPDqz7fs7N0+Ga8r MDbIIsIA594SXubWO9ApkygmZ9d/4tbVIlQk8arjIQNo5jB589CQ1ucDcl2/Gbv6oTbo n+73palBMZQ3GhNNj+s1vVzMxOJnoetmRjQO2hIMycrxv8Po8TL62FLwydXAYkfLc8sF onabaC63BO1r8rKthL+iGtAfZ9vgbQwNdVd4npK7cQac1LLBPRjOVtSMqVu+rFSUYGeC Q2bA== X-Gm-Message-State: ALoCoQkvSiuN0H2KmoXtr+LKFP88BGb8vbIcWWJDFkOMp0MUZl0NHUIzI3DpVs4meX7Om33kFbLJoGdlHfuRwL0ArQm3BXSqUkEJgOXD/VSj5ieV/W6XG6V04WLVHMGIss+D788UqUVhdI0TkpSfXqsRpd/bSuHmJPFC6ngiwE/e5gQlg0dswyS/5eDibknSywNWAlmppfN8 MIME-Version: 1.0 X-Received: by 10.182.44.167 with SMTP id f7mr31586968obm.3.1380133728585; Wed, 25 Sep 2013 11:28:48 -0700 (PDT) Received: by 10.182.250.134 with HTTP; Wed, 25 Sep 2013 11:28:48 -0700 (PDT) In-Reply-To: References: Date: Wed, 25 Sep 2013 11:28:48 -0700 Message-ID: From: Vincent Chen To: Peter Stanforth Content-Type: multipart/alternative; boundary=001a11c1d7e0a2a71a04e7396ca1 Cc: "paws@ietf.org" Subject: Re: [paws] Spectrum encoding discussion X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 18:28:53 -0000 --001a11c1d7e0a2a71a04e7396ca1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Peter, Ah, I needed an example. You are articulating our preferred solution, but we have not been able to agree on how to represent "off". So I was actually trying to take a step back (toward your position). Using your example - My band plan is channels 2-51 - I return information about (only) channels 3, 23, 24 I've told you that you are permitted to use 3, 23, and 24. E.g., I have not granted you permission to use any other channels whether or not they are inside the band plan, under my set of rules. So we have the following two options to work out first: 1) Allow gaps in the frequency ranges to indicate "no permission granted" as opposed to "must not use" 2) Must list all frequencies in a bland plan and continue to work on how to represent "off" -vince On Wed, Sep 25, 2013 at 11:04 AM, Peter Stanforth wrote: > Thanks Vince, I am not trying to grind an axe or be a luddite. I am > concerned that the battle for spectrum sharing is far from over and the > more tangible progress we can make with PAWS the better prepared we are. = So > I am trying to be pragmatic in suggesting we try to get a PAWS standard > completed quickly and one that minimizes the push back from the incumbent= s. > This means we need to be able to get the Regulators to be able to contin= ue > to support us. > If I understand what you are suggesting, as a US TVWS database, then my > band plan would be channels 2-51 and I would return a list of 2-51 > channels. If the list of 2-51 was populated by either "off" or a > "permitted use" then I have logically addressed the regulator concern. By > implication anything outside of that list is outside my band plan. > Therefore I have not only told you what channels you can use I have > informed you why you can't use anything else (off =3D no permission, anyt= hing > else is out of band plan). That seems like a reasonable compromise to me= . > Peter S. > > From: Vincent Chen > Date: Wednesday, September 25, 2013 12:09 PM > To: Peter Stanforth > Cc: Paul Lambert , "gabor.bajko@nokia.com" < > Gabor.Bajko@nokia.com>, "paws@ietf.org" > > Subject: Re: [paws] Spectrum encoding discussion > > Thanks for sharing your insights Peter. > > This is an opportunity to have the protocol be a bit more forward thinkin= g > than what current regulators are thinking. > > Let's try to focus on Gabor's question again of how to express > "unavailability", but phrasing it differently. > > If we were to take the view that the Database provides responses for > frequencies where the device may operate, then > > - Any frequency ranges missing for the response means the device "is not > granted permission" to operate in those frequencies under the rules > implemented by the Database > > Then is it still useful to distinguish why permission is not granted? (of= f > vs outside band plan) > > If not, then Option a), simply having gaps in the frequency ranges would > satisfy this use case. > > Is this a good compromise? > > -vince > > > On Wed, Sep 25, 2013 at 5:01 AM, Peter Stanforth > wrote: > >> Lowering the power to meet the mask is the easy way you get a radio >> certified =96 thus permission to operate. How is that anything to do wit= h the >> database - which is simply managing Regulator policy? >> The ruleset is going to tell you what masks and other operating >> parameters are acceptable within a regulatory domain. I can't imagine a >> Regulator allowing a database operator to manipulate the unintentional >> interference in adjacent channels. If it did why stop there? Why couldn'= t >> the database manipulate co-channel interference to nearby protected >> entities? >> I thought we had a fairly elegant and simple solution. The ruleset >> defines the box the device can operate in and the database provides a >> specific set of permitted channels/frequencies within that box based on = the >> location, time, and type of device making the request. All with respect = to >> the specific list of entities the database has been told to protect at t= hat >> location at that time. >> >> One final comment and then I will rest my case. I have had conversations >> with several Regulators about this recently, and they do not like any >> notion that the database is "thinking" about the answer. >> In every case they have said something along the lines of "if the >> database does not explicitly give a device permission to use a channel t= he >> device is not allowed to use it". >> In every case they have gone somewhat further stating that if the >> database operation goes beyond this simple approach they think it highly >> unlikely that they will get cooperation from incumbents. If you don't >> believe me =96 go ask them! >> Which brings me back to my soap box. We want to get PAWS done so we can >> enable white space. In my humble opinion, the more time we spend >> pontificating and the more complex we make it we are likely to achieve t= he >> opposite. >> Peter S. >> >> >> From: Paul Lambert >> Date: Tuesday, September 24, 2013 2:48 PM >> To: Don Joslyn , Vincent Chen < >> vchen@google.com>, "gabor.bajko@nokia.com" , " >> paws@ietf.org" >> >> Subject: Re: [paws] Spectrum encoding discussion >> >> In line below =85 speaking strongly in favor of "b" >> >> >> Gabor,**** >> >> ** ** >> >> I agree on possible renaming, if we want to specify unavailable channels= . >> **** >> >> ** ** >> >> Please see comments inline. **** >> >> ** ** >> >> On Mon, Sep 23, 2013 at 12:56 PM, wrote:**** >> >> Vince,**** >> >> This proposal of yours below could potentially become very confusing. Th= e >> message itself is named Available Spectrum Request, and you propose the >> Available Spectrum Response to include a bunch of channels with unspecif= ied >> power levels, which are btw, not available channels. **** >> >> So far, we have 4 proposed ways to indicate unavailable channels:**** >> >> a) Not listing it, implicit unavailability**** >> >> This has the drawback of not distinguishing between being silent about a >> channel that is within the database's purview (channel off), and being >> silent about a channel that is outside the database's purview (out of sc= ope >> for given ruleset).**** >> >> ** ** >> >> [DJ =96 Why should the database care about channels that are outside the >> scope of the ruleset specified by the radio? For example, if the specifi= ed >> ruleset is FCC-related, then why would I need to include Ofcom-related >> channels in the response? Am I missing something?] >> >> >> The rules have strict adjacent channel requirements. Meeting the >> spectral mask for the adjacent channels is one of the hardest parts for >> fielding real equipment. If the rules allow relative measurement of the >> adjacent channel energy, you can simply lower your transmit power to the >> point that you can meet the adjacent requirements. >> >> For a general White Spaces solution =96 it is critical to have knowledge >> for the full spectrum mask. The full spectrum mask includes adjacent >> non-allowed channels. >> >> RF channel usage are NOT a binary on/off or a simple transmit level. Th= e >> mask has a specific contour that extends beyond the "allowed" channel. >> Transmitters will always send energy in more than the allowed channel! >> >> >> >> Paul >> >> >> **** >> >> **** >> >> b) List unavailable channels and specify the power limit, eg -56dbm= * >> *** >> >> Since the protocol should stand on its own, independent of any particula= r >> regulatory rule, do we really want to rule this out? In our interpretati= ons >> of the FCC rules, for example, a Database is not prevented from doing th= is. >> **** >> >> ** ** >> >> [DJ =96 I=92m still in favor of just using the implicit unavailability m= ethod >> described above in a). What value is there in providing a power level fo= r >> an unavailable channel? If I=92m the radio, I can=92t use the channel, a= nd I=92m >> not going to intentionally transmit in that channel. This comment also >> applies to c) and d).]**** >> >> **** >> >> c) List unavailable channels and specify =96inf as power limit**** >> >> ** ** >> >> "-Inf" is not really workable, because JSON does not allow Infinity or >> NaNs (http://tools.ietf.org/html/rfc4627), hence the d) proposal.**** >> >> ** ** >> >> d) List unavailable channels and do not specify any power limit ***= * >> >> **** >> >> So far, we have majority in favour of a), few people who could live or >> prefer c) and sort of consensus to strike out option b) from the list ab= ove. >> **** >> >> **** >> >> We=92ll wait for more input on the list before declaring rough consensus >> for the question above; then we=92ll go back to the original question on >> whether the encoding of spectrum profile should be option 1 or option 2.= * >> *** >> >> **** >> >> p.s. It looks to me, that if we want to specify unavailable channels, we >> may need to modify the names of the paws messages to =91Spectrum schedul= e=92 or >> sg along these lines.**** >> >> **** >> >> - Gabor**** >> >> **** >> >> >> >> > > > -- > -vince > --=20 -vince --001a11c1d7e0a2a71a04e7396ca1 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Peter,

Ah, I needed an example. You are= articulating our preferred solution, but we have not been able to agree on= how to represent "off".

So I was actual= ly trying to take a step back (toward your position).

Using your example
=A0- My band plan is chann= els 2-51
=A0- I return information about (only) channels 3, 23, 2= 4

I've told you that you are permitted to use = 3, 23, and 24. E.g., I have not granted you permission to use any other cha= nnels whether or not they are inside the band plan, under my set of rules.<= /div>

So we have the following two options to work out first:=

=A01) Allow gaps in the frequency ranges to indic= ate "no permission granted" as opposed to "must not use"= ;=A0

=A02) Must list all frequencies in a bland plan and con= tinue to work on how to represent "off"

=
-vince


On Wed, Sep 25, 2013 at 11:04 AM, Peter Stanforth <peter@spectrumbr= idge.com> wrote:
Thanks Vince, I am not trying to grind an axe or be a luddite. = =A0I am concerned that the battle for spectrum sharing is far from over and= the more tangible progress we can make with PAWS the better prepared we ar= e. So I am trying to be pragmatic in suggesting we try to get a PAWS standa= rd completed quickly and one that minimizes the push back from the incumben= ts. This means we need to be able to get the Regulators to =A0be able to co= ntinue to support us.=A0
If I understand what you are suggesting, as a US TVWS database, then m= y band plan would be channels 2-51 and I would return a list of 2-51 channe= ls. =A0If the list of 2-51 was populated by either "off" or a &qu= ot;permitted use" then I have logically addressed the regulator concer= n.=A0By implication anything outside of that list is outside my band plan. = Therefore I have not only told you what channels you can use I have informe= d you why you can't use anything else (off =3D no permission, anything = else is out of band plan). =A0That seems like a reasonable compromise to me= .
Peter S.

From: Vincent Chen <vchen@google.com>
Date: Wednesday, September 25, 2013 12= :09 PM
To: Peter Stanforth <peter@spectrumbridge.co= m>
Cc: Paul Lambert <= paul@marvell.com&= gt;, "gabor= .bajko@nokia.com" <Gabor.Bajko@nokia.com>, "paws@ietf.org" <paws@ietf.org>

Subject: Re:= [paws] Spectrum encoding discussion

Thanks for sharing your i= nsights Peter.

This is an opportunity to have the protocol be a bit mo= re forward thinking than what current regulators are thinking.
Let's try to focus on Gabor's question again of how to= express "unavailability", but phrasing it differently.

If we were to take the view that the Database provides = responses for frequencies where the device may operate, then

=
=A0- Any frequency ranges missing for the response means the dev= ice "is not granted permission" to operate in those frequencies u= nder the rules implemented by the Database

Then is it still useful to distinguish why permission i= s not granted? (off vs outside band plan)

If not, = then Option a), simply having gaps in the frequency ranges would satisfy th= is use case.

Is this a good compromise?

-vi= nce


On Wed, Sep 25, 2013 at 5:01 AM, Peter Stanforth <peter@spe= ctrumbridge.com> wrote:
=A0Lowering the power to meet the mask is the easy way you get a radio= certified =96 thus permission to operate. How is that anything to do with = the database - which is simply managing Regulator policy?
The rul= eset is going to tell you what masks and other operating parameters are acc= eptable within a regulatory domain. I can't imagine a Regulator allowin= g a database operator to manipulate the unintentional interference in adjac= ent channels. If it did why stop there? Why couldn't the database manipulate co-channel interf= erence to nearby protected entities?
I thought we had a fairly el= egant and simple solution. The ruleset defines the box the device can opera= te in and the database provides a specific set of permitted channels/freque= ncies within that box based on the location, time, and type of device makin= g the request. All with respect to the specific list of entities the databas= e has been told to protect at that location at that time.

One final comment and then I will rest my case. I have had conversa= tions with several Regulators about this recently, and they do not like any= notion that the database is "thinking" about the answer.
In every case they have said something along the lines of "if the= database does not explicitly give a device permission to use a channel the= device is not allowed to use it".
In every case they have g= one somewhat further stating that if the database operation goes beyond thi= s simple approach they think it highly unlikely that they will get cooperat= ion from incumbents. If you don't believe me =96 go ask them!
Which brings me back to my soap box. We want to get PAWS done so we ca= n enable white space. In my humble opinion, the more time we spend pontific= ating and the more complex we make it we are likely to achieve the opposite= .
Peter S.


From: Paul Lambert <paul@marvell.com>
Date: Tuesday, September 24, 2013 2:48 P= M
To: Don Joslyn <d.joslyn@spectrumbridge.co= m>, Vincent Chen <vchen@google.com>, "gabor.bajko@nokia.com" <Gabor.Bajko= @nokia.com>, "paws@ietf.org" <paws@ietf.org>

Subject: Re: [paws] Spectr= um encoding discussion

In line below =85 speaking strongly in favor of "b"=A0


Gabor,

=A0

I agree on= possible renaming, if we want to specify unavailable channels.

=A0

Please see comments inline.=A0

<= p class=3D"MsoNormal">=A0

On M= on, Sep 23, 2013 at 12:56 PM, <Gabor.Bajko@nokia.com> wrote:

Vince,

This proposal of yours below could potentially = become very confusing. The message itself is named Available Spectrum Reque= st, and you propose the Available Spectrum Response to include a bunch of channels with unspecified power le= vels, which are btw, not available channels.

=A0So far, we have = 4 proposed ways to indicate unavailable channels:

<= p> a)=A0=A0=A0=A0= =A0 Not listing it, implicit unavailability=

This has the drawback of not di= stinguishing between=A0being silent about a channel that is within the database's purv= iew (channel off), and being silent about a channel that is outside the database's purview (out of scope for given ruleset).=

=A0

[DJ =96 Why should the database care about channels that are outsid= e the scope of the ruleset specified by the radio? For example, if the spec= ified ruleset is FCC-related, then why would I need to include Ofcom-related channels in th= e response? Am I missing something?]


The rules have strict= adjacent channel requirements. =A0Meeting the spectral mask for the adjace= nt channels =A0is one of the hardest parts for fielding real equipment. =A0= If the rules allow relative measurement of the adjacent channel energy, you= can simply lower your transmit power to the point that you can meet the adjacent requ= irements. =A0

For a general White Spaces solution = =96 it is critical to have knowledge for the full spectrum mask. =A0The ful= l spectrum mask includes adjacent non-allowed channels.

RF channel usage are NOT a binary on/off or a simple tr= ansmit level. =A0The mask has a specific contour that extends beyond the &q= uot;allowed" channel. =A0Transmitters will always send energy in more = than the allowed channel!



Paul

=

=A0

b)=A0=A0=A0=A0=A0 List unavailable channels and specify the power limit, eg -5= 6dbm

Since the protocol should stand on its own, independent of any particular r= egulatory rule, do we really want to rule this out? In our interpretations = of the FCC rules, for example, a Database is not prevented from doing this.=

=A0

[DJ =96 I=92m still in favor of just using the implicit unav= ailability method described above in a). What value is there in providing a= power level for an unavailable channel? If I=92m the radio, I can=92t use the channel, and I=92m not goin= g to intentionally transmit in that channel. This comment also applies to c= ) and d).]

=A0=

c)=A0=A0=A0=A0=A0= =A0 List unavailable channels and specify =96inf as power limit<= /span>

=A0

"-Inf" is = not really workable, because JSON does not allow Infinity or NaNs (http://tools.ietf= .org/html/rfc4627), hence the d) proposal.

=A0

d)=A0=A0=A0=A0=A0 List unavailable channels and do not specify any power limit= =A0

=A0

So far, we have majority in favour of a), few peop= le who could live or prefer c) and sort of consensus to strike out option b= ) from the list above.

=A0

We=92ll wait for more input on the list before declaring rou= gh consensus for the question above; then we=92ll go back to the original q= uestion on whether the encoding of spectrum profile should be option 1 or option 2.

=A0

p.s. It looks to me, that if we want to specify unavailable channel= s, we may need to modify the names of the paws messages to =91Spectrum sche= dule=92 or sg along these lines.

=A0

-=A0=A0=A0=A0=A0=A0=A0=A0=A0 Gabor

=A0

<= /span>





--
-vince


--
-vince --001a11c1d7e0a2a71a04e7396ca1-- From dharasty@appcomsci.com Wed Sep 25 13:39:41 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9573B21F9FB6 for ; Wed, 25 Sep 2013 13:39:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.738 X-Spam-Level: X-Spam-Status: No, score=-1.738 tagged_above=-999 required=5 tests=[AWL=0.860, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LxTxvteZd0lf for ; Wed, 25 Sep 2013 13:39:36 -0700 (PDT) Received: from thumper.appcomsci.com (thumper.appcomsci.com [205.132.0.196]) by ietfa.amsl.com (Postfix) with ESMTP id E241221E804D for ; Wed, 25 Sep 2013 13:39:34 -0700 (PDT) Received: from bambi.appcomsci.com (bambi.appcomsci.com [192.4.5.54]) by thumper.appcomsci.com (8.14.2/8.14.2) with ESMTP id r8PKdVea001351; Wed, 25 Sep 2013 16:39:31 -0400 (EDT) Received: from brg-ats-exhb1.ats.atsinnovate.com (exch.appcomsci.com [192.4.5.112]) by bambi.appcomsci.com (8.14.4/8.13.4) with ESMTP id r8PKdSZA016840; Wed, 25 Sep 2013 16:39:28 -0400 Received: from RRC-ATS-EXMB2.ats.atsinnovate.com ([2002:c004:56a::c004:56a]) by brg-ats-exhb1.ats.atsinnovate.com ([2002:c004:570::c004:570]) with mapi; Wed, 25 Sep 2013 16:39:28 -0400 From: "Harasty, Daniel J" To: Vincent Chen , Peter Stanforth Thread-Topic: [paws] Spectrum encoding discussion Thread-Index: AQHOtUTmeub++vJf50Opuy0OoCfF4pnNaQ2AgAAHT4CAAAJfAIAACwIAgAEtGoCAAKW+AIAADywAgAALVgCAABr4AP//vY7wgABpe4CAAAgxAIAEUR4AgABaa4CAARbBgIAADjoAgAEgw4CAAEVPgIAAAOww Date: Wed, 25 Sep 2013 20:39:27 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_EC510C021D06A34C92F5A5A488B5290B0CF30E87rrcatsexmb2atsa_" MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] Spectrum encoding discussion X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 20:39:41 -0000 --_000_EC510C021D06A34C92F5A5A488B5290B0CF30E87rrcatsexmb2atsa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As a Database provider, I think it is VERY IMPORTANT to have the ability to= state either of these unambiguously: * These are the handful of channels that are available until 6pm. o (Implicitly: if you want to know about stuff after 6pm, send another re= quest between now and then - preferable closer to 6pm.) * These are the handful of channels that are available until 6pm, a= nd I'm telling you NOW that NOTHING is available starting at 6pm for the ne= xt 18 hours. o (Implicitly: I've told you everything I can about all availability unti= l Noon tomorrow; don't bother sending me another request until close to Noo= n tomorrow.) This is close - but not exactly the same as Gabor's sentiment: This has the drawback of not distinguishing between being silent about a ch= annel that is within the database's purview (channel off), and being silent= about a channel that is outside the database's purview (out of scope for g= iven ruleset). In other words, sometimes the server is "being silent" because "certain fre= quencies are outside the database's purview". But another reason to "be si= lent" is that the database is only telling the Device about events up to a = certain time. This is the very concept I was trying to get at when I tried to formulate a= n example where "being silent" (Gabor's term) or "no mention" (my term - sa= me concept) confers "no information". In my example, I was NOT saying "the= Database has no information about the future"; rather I was giving and exa= mple where the message had "no information" about use of the channel at som= e future time. (I apologize if I was not clear in my point at that time.) >From a Device's perspective - there are really THREE states that a given ch= annel might be in: a) I've been told I can use it, b) I've been told it is unavailable, c) I haven't been told either. I think we ALL agree: The device CAN'T USE THE CHANNEL if it is in either case "b= " or "c" above. But the point I've been trying to make is: The device NEED NOT ASK AGAIN if it knows that the channel = is in case "a" or "b" above. That is why case "b" and "c" are not synonymous. All along, that's been my= objection to "no mention" being synonymous with the Database declaring tha= t a channel is "is unavailable". And that's why I think it is important for the Database to have a way to EX= PLICTLY state a "channel unavailable". If it is a weakness in PAWS - with = impact to the Database - if I can't express the difference between "b" and= "c". Dan Harasty From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Vin= cent Chen Sent: Wednesday, September 25, 2013 12:10 PM To: Peter Stanforth Cc: paws@ietf.org Subject: Re: [paws] Spectrum encoding discussion Thanks for sharing your insights Peter. This is an opportunity to have the protocol be a bit more forward thinking = than what current regulators are thinking. Let's try to focus on Gabor's question again of how to express "unavailabil= ity", but phrasing it differently. If we were to take the view that the Database provides responses for freque= ncies where the device may operate, then - Any frequency ranges missing for the response means the device "is not g= ranted permission" to operate in those frequencies under the rules implemen= ted by the Database Then is it still useful to distinguish why permission is not granted? (off = vs outside band plan) If not, then Option a), simply having gaps in the frequency ranges would sa= tisfy this use case. Is this a good compromise? -vince On Wed, Sep 25, 2013 at 5:01 AM, Peter Stanforth > wrote: Lowering the power to meet the mask is the easy way you get a radio certif= ied - thus permission to operate. How is that anything to do with the datab= ase - which is simply managing Regulator policy? The ruleset is going to tell you what masks and other operating parameters = are acceptable within a regulatory domain. I can't imagine a Regulator allo= wing a database operator to manipulate the unintentional interference in ad= jacent channels. If it did why stop there? Why couldn't the database manipu= late co-channel interference to nearby protected entities? I thought we had a fairly elegant and simple solution. The ruleset defines = the box the device can operate in and the database provides a specific set = of permitted channels/frequencies within that box based on the location, ti= me, and type of device making the request. All with respect to the specific= list of entities the database has been told to protect at that location at= that time. One final comment and then I will rest my case. I have had conversations wi= th several Regulators about this recently, and they do not like any notion = that the database is "thinking" about the answer. In every case they have said something along the lines of "if the database = does not explicitly give a device permission to use a channel the device is= not allowed to use it". In every case they have gone somewhat further stating that if the database = operation goes beyond this simple approach they think it highly unlikely th= at they will get cooperation from incumbents. If you don't believe me - go = ask them! Which brings me back to my soap box. We want to get PAWS done so we can ena= ble white space. In my humble opinion, the more time we spend pontificating= and the more complex we make it we are likely to achieve the opposite. Peter S. From: Paul Lambert > Date: Tuesday, September 24, 2013 2:48 PM To: Don Joslyn >, Vincent Chen >, "gabor.baj= ko@nokia.com" >, "paws@ietf.org" > Subject: Re: [paws] Spectrum encoding discussion In line below ... speaking strongly in favor of "b" Gabor, I agree on possible renaming, if we want to specify unavailable channels. Please see comments inline. On Mon, Sep 23, 2013 at 12:56 PM, > wrote: Vince, This proposal of yours below could potentially become very confusing. The m= essage itself is named Available Spectrum Request, and you propose the Avai= lable Spectrum Response to include a bunch of channels with unspecified pow= er levels, which are btw, not available channels. So far, we have 4 proposed ways to indicate unavailable channels: a) Not listing it, implicit unavailability This has the drawback of not distinguishing between being silent about a ch= annel that is within the database's purview (channel off), and being silent= about a channel that is outside the database's purview (out of scope for g= iven ruleset). [DJ - Why should the database care about channels that are outside the scop= e of the ruleset specified by the radio? For example, if the specified rule= set is FCC-related, then why would I need to include Ofcom-related channels= in the response? Am I missing something?] The rules have strict adjacent channel requirements. Meeting the spectral = mask for the adjacent channels is one of the hardest parts for fielding re= al equipment. If the rules allow relative measurement of the adjacent chan= nel energy, you can simply lower your transmit power to the point that you = can meet the adjacent requirements. For a general White Spaces solution - it is critical to have knowledge for = the full spectrum mask. The full spectrum mask includes adjacent non-allow= ed channels. RF channel usage are NOT a binary on/off or a simple transmit level. The m= ask has a specific contour that extends beyond the "allowed" channel. Tran= smitters will always send energy in more than the allowed channel! Paul b) List unavailable channels and specify the power limit, eg -56dbm Since the protocol should stand on its own, independent of any particular r= egulatory rule, do we really want to rule this out? In our interpretations = of the FCC rules, for example, a Database is not prevented from doing this. [DJ - I'm still in favor of just using the implicit unavailability method d= escribed above in a). What value is there in providing a power level for an= unavailable channel? If I'm the radio, I can't use the channel, and I'm no= t going to intentionally transmit in that channel. This comment also applie= s to c) and d).] c) List unavailable channels and specify -inf as power limit "-Inf" is not really workable, because JSON does not allow Infinity or NaNs= (http://tools.ietf.org/html/rfc4627), hence the d) proposal. d) List unavailable channels and do not specify any power limit So far, we have majority in favour of a), few people who could live or pref= er c) and sort of consensus to strike out option b) from the list above. We'll wait for more input on the list before declaring rough consensus for = the question above; then we'll go back to the original question on whether = the encoding of spectrum profile should be option 1 or option 2. p.s. It looks to me, that if we want to specify unavailable channels, we ma= y need to modify the names of the paws messages to 'Spectrum schedule' or s= g along these lines. - Gabor -- -vince --_000_EC510C021D06A34C92F5A5A488B5290B0CF30E87rrcatsexmb2atsa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

As a Data= base provider, I think it is VERY IMPORTANT to have the ability to state ei= ther of these unambiguously:

·These are the handful of channels that are available until 6= pm.

o&nbs= p;  (Implicitly: if you want to = know about stuff after 6pm, send another request between now and then ̵= 1; preferable closer to 6pm.)

·         <= ![endif]>These are the handful of channels that are available until = 6pm, and I’m telling you NOW that NOTHING is available starting at 6p= m for the next 18 hours.

o   (Implic= itly: I’ve told you everything I can about all availability until Noo= n tomorrow; don’t bother sending me another request until close to No= on tomorrow.)

 <= /o:p>

This is close – but not e= xactly the same as Gabor’s sentiment:

This has the drawback of not distinguishing between being silen= t about a channel that is within the database's purview (channel off), and = being silent about a channel that is outside the database's purview (out of= scope for given ruleset).

In other words, sometimes the server is “being silent” because= “certain frequencies are outside the database’s purview”= .  But another reason to “be silent” is that the database = is only telling the Device about events up to a certain time.

 

This is the very concept I was trying to get at when I tri= ed to formulate an example where “being silent” (Gabor’s = term) or “no mention” (my term – same concept) confers &#= 8220;no information”.  In my example, I was NOT saying “th= e Database has no information about the future”; rather I was giving = and example where the message had “no information” about= use of the channel at some future time.  (I apologize if I was not cl= ear in my point at that time.)

 

From a Devi= ce’s perspective – there are really THREE sta= tes that a given channel might be in:

a) I’ve been told I can use i= t,

b) I’ve been told it is unavailable,

c) I haven’t been t= old either.

 

I think we ALL agree:<= /span>

      &= nbsp;         The device CAN’= T USE THE CHANNEL if it is in either case “b” or “c”= ; above.

 =

But the point I’ve been trying= to make is:

  &= nbsp;           &nbs= p; The device NEED NOT ASK AGAIN if it knows that the channel is in case &#= 8220;a” or “b” above.

 

That= is why case “b” and “c” are not synonymous.=   All along, that’s been my objection to “no mention”= ; being synonymous with the Database declaring that a channel is “is = unavailable”. 

 

And that’s w= hy I think it is important for the Database to have a way to EXPLICTLY stat= e a “channel unavailable”.  If it is a weakness in PAWS &#= 8211; with impact to the Database –  if I can’t express th= e difference between “b” and “c”.=

 

 

Dan = Harasty

 <= /span>

 

 

Fr= om: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of= Vincent Chen
Sent: Wednesday, September 25, 2013 12:10 PMTo: Peter Stanforth
Cc: paws@ietf.org
Subject: = Re: [paws] Spectrum encoding discussion

 

Thanks for shar= ing your insights Peter.

 = ;

This is an opportunity to have t= he protocol be a bit more forward thinking than what current regulators are= thinking.

 <= /p>

Let's try to focus on Gabor's question a= gain of how to express "unavailability", but phrasing it differen= tly.

 

If we were to take the view that the Database = provides responses for frequencies where the device may operate, then<= /o:p>

 

 - Any frequency ranges missing for the response me= ans the device "is not granted permission" to operate in those fr= equencies under the rules implemented by the Database

<= div>

 

Then is it still useful to distinguish why permission is not granted? (o= ff vs outside band plan)

 

If not, then Option a), si= mply having gaps in the frequency ranges would satisfy this use case.<= /o:p>

 

Is this a good compromise?

 

-vinc= e

 

On Wed, Sep 25, 20= 13 at 5:01 AM, Peter Stanforth <peter@spectrumbridge.com> wrote:

 Lowering the power to meet the mask is the e= asy way you get a radio certified – thus permission to operate. How i= s that anything to do with the database - which is simply managing Regulato= r policy?

The ruleset is goi= ng to tell you what masks and other operating parameters are acceptable wit= hin a regulatory domain. I can't imagine a Regulator allowing a database op= erator to manipulate the unintentional interference in adjacent channels. I= f it did why stop there? Why couldn't the database manipulate co-channel in= terference to nearby protected entities?

I thought we had a fairly elegant and simple solution. The rule= set defines the box the device can operate in and the database provides a s= pecific set of permitted channels/frequencies within that box based on the = location, time, and type of device making the request. All with respect to = the specific list of entities the database has been told to protect at that= location at that time.

=  

One final comment and then = I will rest my case. I have had conversations with several Regulators about= this recently, and they do not like any notion that the database is "= thinking" about the answer.

In every case they have said something along the lines of "if th= e database does not explicitly give a device permission to use a channel th= e device is not allowed to use it".

In every case they have gone somewhat further stating that if t= he database operation goes beyond this simple approach they think it highly= unlikely that they will get cooperation from incumbents. If you don't beli= eve me – go ask them!

W= hich brings me back to my soap box. We want to get PAWS done so we can enab= le white space. In my humble opinion, the more time we spend pontificating = and the more complex we make it we are likely to achieve the opposite.=

Peter S.

 

=  

From: Paul = Lambert <paul@marv= ell.com>
Date: Tuesday, September 24, 2013 2:48 PM
T= o: Don Joslyn <d.joslyn@spectrumbridge.com>, Vincent Chen <vchen@google.com>, &q= uot;gabor.bajko@= nokia.com" <Gabor.Bajko@nokia.com>, "paws@ietf.org" <paws@ietf.org>


Subject: Re: [paws] Spectrum encoding discussion

 

In line below … sp= eaking strongly in favor of "b" 

=

 

 

Gabor,

 =

I agree on possible renaming, if we want t= o specify unavailable channels.

 =

Please see comments inline. 

 

On Mon, Sep 23, 2013 at= 12:56 PM, <G= abor.Bajko@nokia.com> wrote:

V= ince,

This proposal of yours below could= potentially become very confusing. The message itself is named Available S= pectrum Request, and you propose the Available Spectrum Response to include= a bunch of channels with unspecified power levels, which are btw, not avai= lable channels.

 So far, we have 4= proposed ways to indicate unavailable channels:

a)      Not listin= g it, implicit unavailability

= This has the drawback of not distinguishing between being silent about a channe= l that is within the database's purview (channel off), and being silent abo= ut a channel that is outside the database's purview (out of scope for given= ruleset).

 

<= p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:= auto'>[DJ – Why should the database care about channels that a= re outside the scope of the ruleset specified by the radio? For example, if= the specified ruleset is FCC-related, then why would I need to include Ofc= om-related channels in the response? Am I missing something?]

 

The rules have = strict adjacent channel requirements.  Meeting the spectral mask for t= he adjacent channels  is one of the hardest parts for fielding real eq= uipment.  If the rules allow relative measurement of the adjacent chan= nel energy, you can simply lower your transmit power to the point that you = can meet the adjacent requirements.  

=

 

<= span style=3D'font-size:10.5pt;font-family:"Calibri","sans-serif"'>For a ge= neral White Spaces solution – it is critical to have knowledge for th= e full spectrum mask.  The full spectrum mask includes adjacent non-al= lowed channels.

 

RF channel usage are NOT a binary o= n/off or a simple transmit level.  The mask has a specific contour tha= t extends beyond the "allowed" channel.  Transmitters will a= lways send energy in more than the allowed channel!

 

 

 

Paul

 

 

 

b)      List unavailable channels and specify the power limit, eg -56dbm= =

Since the protoc= ol should stand on its own, independent of any particular regulatory rule, = do we really want to rule this out? In our interpretations of the FCC rules= , for example, a Database is not prevented from doing this.

<= p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:= auto'> 

[DJ – I’= m still in favor of just using the implicit unavailability method described= above in a). What value is there in providing a power level for an unavail= able channel? If I’m the radio, I can’t use the channel, and I&= #8217;m not going to intentionally transmit in that channel. This comment a= lso applies to c) and d).]

 

c) &n= bsp;     List unavailable channels and sp= ecify –inf as power limit

 

"-Inf" is= not really workable, because JSON does not allow Infinity or NaNs (http://tools.ietf= .org/html/rfc4627), hence the d) proposal.

 

d)<= span style=3D'font-size:7.0pt;font-family:"Calibri","sans-serif";color:#1F4= 97D'>      List unavailable channels= and do not specify any power limit 

=

 =

So far, we have majority in favour of a), few people who = could live or prefer c) and sort of consensus to strike out option b) from = the list above.

 =

We’ll wait for more input on the list before declar= ing rough consensus for the question above; then we’ll go back to the= original question on whether the encoding of spectrum profile should be op= tion 1 or option 2.

 

p.s. It looks to me, that if we want to specify unava= ilable channels, we may need to modify the names of the paws messages to &#= 8216;Spectrum schedule’ or sg along these lines.

 

- &n= bsp;        Gabor

 

 

 =



 

<= /div>

--
-vince

<= /html>= --_000_EC510C021D06A34C92F5A5A488B5290B0CF30E87rrcatsexmb2atsa_-- From tvfool@google.com Wed Sep 25 13:56:51 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F3B521F9D95 for ; Wed, 25 Sep 2013 13:56:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.352 X-Spam-Level: X-Spam-Status: No, score=-1.352 tagged_above=-999 required=5 tests=[AWL=0.625, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pFrKa204WOgJ for ; Wed, 25 Sep 2013 13:56:49 -0700 (PDT) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id B979B21F9FB6 for ; Wed, 25 Sep 2013 13:56:46 -0700 (PDT) Received: by mail-ob0-f173.google.com with SMTP id vb8so496051obc.32 for ; Wed, 25 Sep 2013 13:56:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=biWA6rAgv/CreMABblJqnEzPZ7iMYdUSfyvbXt1lczk=; b=RKHc1ZLdSlajrFlCvyICEIYSi0wKQ5u47bIx4E0qtSZt7dqKHutsQpgHMX8h6E7Ol/ qWl+BmUAFcU7O17eZIece8wXNA6zM4mrp6PloX8vydkXamXBOMtc3sZVKN0oXodEkAV8 z3FMeRJFijbmt/FIVieECbQr+vYFUlPRCqTq8Ru0gDhZSXmwJCFpl7Q8WVQRVVI2tnRG ANlYhEhEf1AluBptzwU2BHAI/RCbzbLeUAWoriXa4fpZwB6f7cHCOyA/ltRe/Adr16Qp C3EoCCe1obkCrcSp9XbXjAzMVV7gGfQ9AbaCdi2asseEJzfKRHOTjONfZ01qb6M0sKpb k/hQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=biWA6rAgv/CreMABblJqnEzPZ7iMYdUSfyvbXt1lczk=; b=Xs0JaigXfXj3n0Ac5clROqmxjxO4ggNi+gIqJTCG/IHHfMy3zmzmYXdhyX+jT4kGgt C0GJ6zp5dawVf3czjYhoYwUWOr4cpSzdrf1yYR6d7dB2SISLFh3s4+1ekEUsexmVAkUO 8SJ4HOFjH1nnZ6on2joq7fdUg8VJL7kTXmkvbPNH38h8yPnEnHZuNBBXfZJCCxcCDC7M Jx+6ug5dW7PCslCkcw5gR+UI2ZCIj8HDqHN6DyHzFWbAmvnMPjIMMhwIV7vRidTArNui 8givscwNm/2psnO5N8V5rzZ0w4fJXzGZh/4hU0bpKCmMrSFUrq+jbQt2DIqlgjACxYfA f0pQ== X-Gm-Message-State: ALoCoQlL2wp0Idge7Yt5f1f5XNcsiCXOZcLOY0GzxY4duqEXwbDZJoPWSEMsiEn28cdBXb0RENl7pbBY0DP9ek4jMMcjXyVoyvClIikVm+gDsZzp/zlyKGXEUIa3VyqMSpLVlpL7hdcW7Bp5cwtJSWP9z2yb8WTvT1FS+WDOmoBXB+hYBb0ZYxCIc2AE9F3eUyYRTgHYc556 MIME-Version: 1.0 X-Received: by 10.60.50.135 with SMTP id c7mr13915753oeo.41.1380142606007; Wed, 25 Sep 2013 13:56:46 -0700 (PDT) Received: by 10.182.142.196 with HTTP; Wed, 25 Sep 2013 13:56:45 -0700 (PDT) In-Reply-To: References: Date: Wed, 25 Sep 2013 13:56:45 -0700 Message-ID: From: Andy Lee To: Peter Stanforth Content-Type: multipart/alternative; boundary=001a11c2f776c5c52504e73b7d4f Cc: "paws@ietf.org" Subject: Re: [paws] Spectrum encoding discussion X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 20:56:51 -0000 --001a11c2f776c5c52504e73b7d4f Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Peter, > I can't imagine a Regulator allowing a database operator to manipulate th= e > unintentional interference in adjacent channels. If it did why stop there= ? > Why couldn't the database manipulate co-channel interference to nearby > protected entities? The recent discussions have been about data encoding and nothing more. The premise is that *IF* there is some information the database wants to communicate to the white space device, *HOW* is that data encoded into the message. As a case in point, section 15.709(c)(1) of the rules clearly defines what the "off" channel power limits must be. The rules originally called for a "relative" OOB emission limit, but after some industry discussion, the FCC settled on these "absolute" OOB emission limits instead. The values are clearly defined, but its not clear whether a database would want to communicate these parameters to the device or not. On one hand, the database can assume that the device has these values hard-coded into its firmware and therefore does not need to send that information over PAWS. On the other hand, these power levels are part of the TVWS rules and perhaps is something that the database should communicate to the WSD. There are potentially beneficial things that a WSD could do with that information if it was provided at run-time (e.g., for future-proofing the device, or choosing operating channels more intelligently). *PAWS does not need to address WHY a particular parameter should or should not be sent over the protocol.* There are many regulatory, business, or technological reasons why these choices might change, and those decisions are beyond the scope of the protocol itself. However, *PAWS can and should address HOW data gets encoded IF a device or database decides to send it.* i.e., IF you want to encode [X], then you SHALL use [encoding X] IF you want to encode [Y], then you SHALL use [encoding Y] etc. I can identify at least three distinct concepts that have been discussed so far, which I would categorize as follows: - (i) Explicit "on", Implicit "off" - Anything not explicitly specified as "on" would implicitly be treated as "off" - The recipient must have apriori knowledge about how to comply with the "off" channel, "special" channel (e.g., channel 37), and "band-ed= ge" protection ratios - There is no distinction between "off" channels, "special" channels, and "band-edge" constraints in the message itself - This requires a way to encode gaps or discontinuities in the spectrum profile - This is equivalent to Gabor's option (a) - (ii) Explicit "on", Explicit "off" with no power level given - Every channel would be either explicitly "on" or explicitly "off" - Any frequency blocks that are not explicitly "on" or explicitly "off" are considered to be "out-of-scope" for the current database or ruleset, and this implicitly gives the "band-edge" boundaries - The recipient must have apriori knowledge about how to comply with the "off" channel, "special" channel, and "band-edge" protection rati= os - The recipient can infer from the message when to apply "off" channel constraints and when to apply "band-edge" constraints - This requires a way to encode gaps or discontinuities in the spectrum profile AND requires a way to encode explicit "off" channels with no specified power value - This is equivalent to Gabor's options (c) and (d) - (iii) Explicit "on", Explicit "off" with power level given - Every channel would be either explicitly "on" or explicitly "off" - Any frequency blocks that are not explicitly "on" or explicitly "off" are considered to be "out-of-scope" for the current database or ruleset, and this implicitly gives the "band-edge" boundaries - The "off" channel, "special" channel, and "band-edge" protection ratios are explicitly provided in the message, and a device has the option of either using that information or ignoring it (default back to apri= ori knowledge of the protection ratios) - This requires a way to encode gaps or discontinuities in the spectrum profile - This is equivalent to Gabor's option (b) I think all three types of encoding have their uses, and PAWS should probably allow all three possibilities. It looks like all three encoding types need a way to express gaps or discontinuities in the spectrum profile. I think the latest proposal from Vince, using a list of lists, addresses this problem nicely. It also looks like encodings for (i) and (iii) are logically equivalent, with the only real difference being that encoding (iii) includes more data points in the spectrum profile than encoding (i). I don't think anything else needs to be added to the spec to support both of these encodings. That leaves us with encoding (ii), where we need to add something new to the spec to encode explicitly "off" frequency blocks that have no power level given. For this, we have two proposals: Option (c): Use -inf as the power value in a spectrum profile element Option (d): Leave the power value blank in a spectrum profile element I'd suggest maybe considering yet another proposal: Option (e): Use normal encoding (i) for explicit "on" channels, and then have a separate list of frequency start/stop pairs indicating the authoritative bands for which the database operates. Anything that is inside the authoritative bands but not in an explicitly "on" chunk is effectively saying it's explicitly "off". Anything outside of the list of authoritative bands is considered "out-of-scope" for the database and this essentially lists the "band-edge" boundaries. Best regards, Andy Lee | Google Inc. | tvfool@google.com | 408-230-0522 On Wed, Sep 25, 2013 at 5:01 AM, Peter Stanforth wrote: > Lowering the power to meet the mask is the easy way you get a radio > certified =96 thus permission to operate. How is that anything to do with= the > database - which is simply managing Regulator policy? > The ruleset is going to tell you what masks and other operating parameter= s > are acceptable within a regulatory domain. I can't imagine a Regulator > allowing a database operator to manipulate the unintentional interference > in adjacent channels. If it did why stop there? Why couldn't the database > manipulate co-channel interference to nearby protected entities? > I thought we had a fairly elegant and simple solution. The ruleset define= s > the box the device can operate in and the database provides a specific se= t > of permitted channels/frequencies within that box based on the location, > time, and type of device making the request. All with respect to the > specific list of entities the database has been told to protect at that > location at that time. > > One final comment and then I will rest my case. I have had conversations > with several Regulators about this recently, and they do not like any > notion that the database is "thinking" about the answer. > In every case they have said something along the lines of "if the databas= e > does not explicitly give a device permission to use a channel the device = is > not allowed to use it". > In every case they have gone somewhat further stating that if the databas= e > operation goes beyond this simple approach they think it highly unlikely > that they will get cooperation from incumbents. If you don't believe me = =96 > go ask them! > Which brings me back to my soap box. We want to get PAWS done so we can > enable white space. In my humble opinion, the more time we spend > pontificating and the more complex we make it we are likely to achieve th= e > opposite. > Peter S. > > > From: Paul Lambert > Date: Tuesday, September 24, 2013 2:48 PM > To: Don Joslyn , Vincent Chen < > vchen@google.com>, "gabor.bajko@nokia.com" , " > paws@ietf.org" > > Subject: Re: [paws] Spectrum encoding discussion > > In line below =85 speaking strongly in favor of "b" > > > Gabor,**** > > ** ** > > I agree on possible renaming, if we want to specify unavailable channels.= * > *** > > ** ** > > Please see comments inline. **** > > ** ** > > On Mon, Sep 23, 2013 at 12:56 PM, wrote:**** > > Vince,**** > > This proposal of yours below could potentially become very confusing. The > message itself is named Available Spectrum Request, and you propose the > Available Spectrum Response to include a bunch of channels with unspecifi= ed > power levels, which are btw, not available channels. **** > > So far, we have 4 proposed ways to indicate unavailable channels:**** > > a) Not listing it, implicit unavailability**** > > This has the drawback of not distinguishing between being silent about a > channel that is within the database's purview (channel off), and being > silent about a channel that is outside the database's purview (out of sco= pe > for given ruleset).**** > > ** ** > > [DJ =96 Why should the database care about channels that are outside the > scope of the ruleset specified by the radio? For example, if the specifie= d > ruleset is FCC-related, then why would I need to include Ofcom-related > channels in the response? Am I missing something?] > > > The rules have strict adjacent channel requirements. Meeting the spectra= l > mask for the adjacent channels is one of the hardest parts for fielding > real equipment. If the rules allow relative measurement of the adjacent > channel energy, you can simply lower your transmit power to the point tha= t > you can meet the adjacent requirements. > > For a general White Spaces solution =96 it is critical to have knowledge = for > the full spectrum mask. The full spectrum mask includes adjacent > non-allowed channels. > > RF channel usage are NOT a binary on/off or a simple transmit level. The > mask has a specific contour that extends beyond the "allowed" channel. > Transmitters will always send energy in more than the allowed channel! > > > > Paul > > > **** > > **** > > b) List unavailable channels and specify the power limit, eg -56dbm*= * > ** > > Since the protocol should stand on its own, independent of any particular > regulatory rule, do we really want to rule this out? In our interpretatio= ns > of the FCC rules, for example, a Database is not prevented from doing thi= s. > **** > > ** ** > > [DJ =96 I=92m still in favor of just using the implicit unavailability me= thod > described above in a). What value is there in providing a power level for > an unavailable channel? If I=92m the radio, I can=92t use the channel, an= d I=92m > not going to intentionally transmit in that channel. This comment also > applies to c) and d).]**** > > **** > > c) List unavailable channels and specify =96inf as power limit**** > > ** ** > > "-Inf" is not really workable, because JSON does not allow Infinity or > NaNs (http://tools.ietf.org/html/rfc4627), hence the d) proposal.**** > > ** ** > > d) List unavailable channels and do not specify any power limit **** > > **** > > So far, we have majority in favour of a), few people who could live or > prefer c) and sort of consensus to strike out option b) from the list abo= ve. > **** > > **** > > We=92ll wait for more input on the list before declaring rough consensus = for > the question above; then we=92ll go back to the original question on whet= her > the encoding of spectrum profile should be option 1 or option 2.**** > > **** > > p.s. It looks to me, that if we want to specify unavailable channels, we > may need to modify the names of the paws messages to =91Spectrum schedule= =92 or > sg along these lines.**** > > **** > > - Gabor**** > > **** > > > > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > > --001a11c2f776c5c52504e73b7d4f Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi Peter,
=A0
I can't imagine = a Regulator allowing a database operator to manipulate the unintentional in= terference in adjacent channels. If it did why stop there? Why couldn't= the database manipulate co-channel interference to nearby protected entiti= es?

The recent discussions have been about data encoding an= d nothing more. =A0The premise is that IF there is some information = the database wants to communicate to the white space device, HOW is = that data encoded into the message.

As a case in point, section 15.709(c)(1) of the rules c= learly defines what the "off" channel power limits must be. =A0Th= e rules originally called for a "relative" OOB emission limit, bu= t after some industry discussion, the FCC settled on these "absolute&q= uot; OOB emission limits instead. =A0The values are clearly defined, but it= s not clear whether a database would want to communicate these parameters t= o the device or not.

On one hand, the database can assume that the dev= ice has these values hard-coded into its firmware and therefore does not ne= ed to send that information over PAWS.

On the othe= r hand, these power levels are part of the TVWS rules and perhaps is someth= ing that the database should communicate to the WSD. =A0There are potential= ly beneficial things that a WSD could do with that information if it was pr= ovided at run-time (e.g., for future-proofing the device, or choosing opera= ting channels more intelligently).





=
PAWS does not need to address WHY a particular parameter should or = should not be sent over the protocol.=A0 There are many regulatory, bus= iness, or technological reasons why these choices might change, and those d= ecisions are beyond the scope of the protocol itself.

However, PAWS can and should address HOW data gets e= ncoded IF a device or database decides to send it. =A0i.e.,
<= br>
IF you want to encode [X], then you SHALL use [encoding X]
IF you want to encode [Y], then you SHALL use [encoding Y]
e= tc.

I can identify at least three distinct concept= s that have been discussed so far, which I would categorize as follows:
  • (i) Explicit "on", Implicit "off"
    • Anything not explicitly specified as "on" would implicit= ly be treated as "off"
    • The recipient must have apriori kn= owledge about how to comply with the "off" channel, "special= " channel (e.g., channel 37), and "band-edge" protection rat= ios
    • There is no distinction between "off" channels, "special= " channels, and "band-edge" constraints in the message itsel= f
    • This requires a way to encode gaps or discontinuities in the spec= trum profile
    • This is equivalent to Gabor's option (a)

  • (ii)=A0Explicit "on",=A0Explicit "off" with = no power level given
    • Every channel would be either explicitly &= quot;on" or explicitly "off"
    • Any frequency blocks that are not explicitly "on" or explicit= ly "off" are considered to be "out-of-scope" for the cu= rrent database or ruleset, and this implicitly gives the "band-edge&qu= ot; boundaries
    • The recipient must have apriori knowledge about how to comply with the = "off" channel, "special" channel, and "band-edge&q= uot; protection ratios
    • The recipient can infer from the message whe= n to apply "off" channel constraints and when to apply "band= -edge" constraints
    • This requires a way to encode gaps or discontinuities in the spect= rum profile AND requires a way to encode explicit "off" channels = with no specified power value
    • This is equivalent to Gabor's opt= ions (c) and (d)

  • (iii)=A0Explicit "on",=A0Explici= t "off" with power level given
    • Every channel would be= either explicitly "on" or explicitly "off"
    • Any= frequency blocks that are not explicitly "on" or explicitly &quo= t;off" are considered to be "out-of-scope" for the current d= atabase or ruleset, and this implicitly gives the "band-edge" bou= ndaries
    • The "off" channel, "special" channel, and "ban= d-edge" protection ratios are explicitly provided in the message, and = a device has the option of either using that information or ignoring it (de= fault back to apriori knowledge of the protection ratios)
    • This requires a way to encode gaps or discontinuities in the spectrum p= rofile
    • This is equivalent to Gabor's option (b)
<= /div>

I think all three types of encoding have= their uses, and PAWS should probably allow all three possibilities.

It looks like all three encoding types need a way to ex= press gaps or discontinuities in the spectrum profile. =A0I think the lates= t proposal from Vince, using a list of lists, addresses this problem nicely= .

It also looks like encodings for (i) and (iii) are logi= cally equivalent, with the only real difference being that encoding (iii) i= ncludes more data points in the spectrum profile than encoding (i). =A0I do= n't think anything else needs to be added to the spec to support both o= f these encodings.



That leaves us with encod= ing (ii), where we need to add something new to the spec to encode explicit= ly "off" frequency blocks that have no power level given. =A0For = this, we have two proposals:

Option (c): Use -inf as the power value in a spectrum p= rofile element
Option (d): Leave the power value blank in a spect= rum profile element

I'd suggest maybe consider= ing yet another proposal:

Option (e): Use normal encoding (i) for explicit "= on" channels, and then have a separate list of frequency start/stop pa= irs indicating the authoritative bands for which the database operates. =A0= Anything that is inside the authoritative bands but not in an explicitly &q= uot;on" chunk is effectively saying it's explicitly "off"= ;. =A0Anything outside of the list of authoritative bands is considered &qu= ot;out-of-scope" for the database and this essentially lists the "= ;band-edge" boundaries.



Best regards,
=


Andy Lee=A0|=A0Google Inc= . | =A0tvfool@google.com=A0| =A0408-230-0522


On Wed, Sep 25, 2013 at 5:01 AM, Peter S= tanforth <peter@spectrumbridge.com> wrote:
=A0Lowering the power to meet the mask is the easy way you get = a radio certified =96 thus permission to operate. How is that anything to d= o with the database - which is simply managing Regulator policy?
The ruleset is going to tell you what masks and other operating parame= ters are acceptable within a regulatory domain. I can't imagine a Regul= ator allowing a database operator to manipulate the unintentional interfere= nce in adjacent channels. If it did why stop there? Why couldn't the da= tabase manipulate co-channel interference to nearby protected entities?
I thought we had a fairly elegant and simple solution. The ruleset def= ines the box the device can operate in and the database provides a specific= set of permitted channels/frequencies within that box based on the locatio= n, time, and type of device making the request. All with respect to the spe= cific list of entities the database has been told to protect at that locati= on at that time.

One final comment and then I will rest my case. I have = had conversations with several Regulators about this recently, and they do = not like any notion that the database is "thinking" about the ans= wer.
In every case they have said something along the lines of "if the= database does not explicitly give a device permission to use a channel the= device is not allowed to use it".
In every case they have g= one somewhat further stating that if the database operation goes beyond thi= s simple approach they think it highly unlikely that they will get cooperat= ion from incumbents. If you don't believe me =96 go ask them!
Which brings me back to my soap box. We want to get PAWS done so we ca= n enable white space. In my humble opinion, the more time we spend pontific= ating and the more complex we make it we are likely to achieve the opposite= .
Peter S.



In line below =85 speaking strongly in favor of "b"=A0


Gabor,

=A0

I agree on= possible renaming, if we want to specify unavailable channels.

=A0

Please see comments inline.=A0

<= p class=3D"MsoNormal">=A0

On M= on, Sep 23, 2013 at 12:56 PM, <Gabor.Bajko@nokia.com> wrote:

Vince,

This proposal of yours below could potentially = become very confusing. The message itself is named Available Spectrum Request, and you propose the Available Spectru= m Response to include a bunch of channels with unspecified power levels, wh= ich are btw, not available channels.

=A0So far, we have = 4 proposed ways to indicate unavailable channels:

<= p> a)=A0=A0=A0=A0= =A0 Not listing it, implicit unavailability=

This has the drawback of not di= stinguishing between=A0being silent about a channel that is within the database's purv= iew (channel off), and being silent about a channel that is outside the database's purview (out of scope for given ruleset).=

=A0

[DJ =96 Why should the database care about c= hannels that are outside the scope of the ruleset specified by the radio? F= or example, if the specified ruleset is FCC-related, then why would I need to include Ofcom-related cha= nnels in the response? Am I missing something?]




RF channel usage are NOT a binary on/off or a simple tr= ansmit level. =A0The mask has a specific contour that extends beyond the &q= uot;allowed" channel. =A0Transmitters will always send energy in more = than the allowed channel!



Paul

=

=A0

b)=A0=A0=A0=A0=A0 List unavailable channels and specify the power limit, eg -5= 6dbm

Since the protocol should stand on its own, independent of any particular r= egulatory rule, do we really want to rule this out? In our interpretations = of the FCC rules, for example, a Database is not prevented from doing this.=

=A0

[DJ =96 I=92m still in favor of just using the implicit unav= ailability method described above in a). What value is there in providing a= power level for an unavailable channel? If I=92m the radio, I can=92t use the channel, and= I=92m not going to intentionally transmit in that channel. This comment al= so applies to c) and d).]

=A0

c)=A0=A0=A0=A0=A0=A0 List unavailable channels and specify =96inf as power limit<= /span>

=A0

=A0

d)=A0=A0=A0=A0=A0 List unavailable channels and do not specify any power limit= =A0

=A0

So far, we have majority in favour of a), few peop= le who could live or prefer c) and sort of consensus to strike out option b) from the list above.=

=A0

We=92ll wait for more input on the list before declaring rough cons= ensus for the question above; then we=92ll go back to the original question on whether the encodi= ng of spectrum profile should be option 1 or option 2.=

=A0

p.s. It looks to me, that if we want to spec= ify unavailable channels, we may need to modify the names of the paws messages to =91Spectrum schedule=92 or sg along thes= e lines.

=A0<= u>

-=A0=A0=A0= =A0=A0=A0=A0=A0=A0 Gabor

=A0

<= /span>



_______________________________________________
paws mailing list
paws@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/paws


--001a11c2f776c5c52504e73b7d4f-- From tvfool@google.com Wed Sep 25 14:24:08 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A0CD21F922A for ; Wed, 25 Sep 2013 14:24:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[AWL=0.577, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z1vlgEcwbd5x for ; Wed, 25 Sep 2013 14:24:06 -0700 (PDT) Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 70BEA11E80E0 for ; Wed, 25 Sep 2013 14:24:02 -0700 (PDT) Received: by mail-ob0-f176.google.com with SMTP id uy5so567958obc.21 for ; Wed, 25 Sep 2013 14:23:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zNUD8VjFsVJtCafkEZkTEEbZt3+R+LHiLn6fggbdTmk=; b=av5U8ml9fkrCgeGWK/rXCZ2qTHMHojK0qphg2cC8SuIlTmBNs9HYM+XYlqIxBn2rPu Bljue0CvQVidTwDtOAfPuPc+zThoxw+jsmNMAVBEWUEOYy2o2Sk6stTLhWfS+uDumGwe fdZXg9cSCVA24TlgY2vzo/zA0d8adCsx0J9xjgYfbDjqGJHIMvkI2UYYku6GPJCkGF4G wtEGLnDMnc1KNqEzqGCv7xgnL0fAL6ldiBh/BvdiTzBeC2AAeXruoMdSuwnuwoupv8q8 pum8hRrdVbh2Xc6OjTCG9kgEUXepo8tG7Ju31mL7+/OtrKc3AmP3c0ogwena0xQZ7M6N p16A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=zNUD8VjFsVJtCafkEZkTEEbZt3+R+LHiLn6fggbdTmk=; b=DKnNfnAB7NjAJQSXYD2X3iDQKzsjzShtv6eynMzObiHJlO8n5wWLsGDLkcHWVIOXQu iF8TcEwXNghw4SgzNJI5XMUWEa4Iuf/bOgJFi8oaZQPadhbAbDPqXv7AFlX657R6Wlwc 9tL6z6N6dnbqbZFiz91lfPmampm2c7KG07kJLW2jKVmxQSy+ED9h3ni/AvfYnRPdWxZi ZYANmMbccBspvqI05Ir9hmJSJtr9J0JEb02qMAy1LV4GEDuoij1eaYfEz6X0jNAnBKjk JdUquTCBai10hwfHLW8hHfSVP/YlHT6sK0Ki58JtzMlmD49JJvujWImIaV4XmMeD1nco gUOw== X-Gm-Message-State: ALoCoQkDn+knt1xbOIZmibhEqz+BOu8uAKUS2Is9F/Amsb1X5oy9BHjdzOf9SOarwKcEzneWYyJqvEpoMN8j6Yzzw2TRqA1rGSKLKOeWuScX2Sbgbef0Zqo7DykDhntrnYIhmxBEa2N5i5EaomdEkigOH1V93b7tyd3c1i3uSWAd3W8ilijWWRuLwcWYZXO3UcKh0h/yVhGq MIME-Version: 1.0 X-Received: by 10.60.60.105 with SMTP id g9mr32021040oer.8.1380144229853; Wed, 25 Sep 2013 14:23:49 -0700 (PDT) Received: by 10.182.142.196 with HTTP; Wed, 25 Sep 2013 14:23:49 -0700 (PDT) In-Reply-To: References: Date: Wed, 25 Sep 2013 14:23:49 -0700 Message-ID: From: Andy Lee To: "Harasty, Daniel J" Content-Type: multipart/alternative; boundary=089e0149d0ae8fa67204e73bdea9 Cc: "paws@ietf.org" Subject: Re: [paws] Spectrum encoding discussion X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 21:24:08 -0000 --089e0149d0ae8fa67204e73bdea9 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Dan, **These are the handful of channels that are available until 6pm. > ****o **(Implicitly: if you want to know about stuff after 6pm, send > another request between now and then =96 preferable closer to 6pm.) > ****=B7 **These are the handful of channels that are available > until 6pm, and I=92m telling you NOW that NOTHING is available starting a= t > 6pm for the next 18 hours. > ****o **(Implicitly: I=92ve told you everything I can about all > availability until Noon tomorrow; don=92t bother sending me another reque= st > until close to Noon tomorrow.) Thanks for the nice example. This sounds like a new concept to me. To me it's suggesting a distinction of a channel "on-to-off" transition as being either "hard" (off permanently as far as the database is aware) or "soft" (ask me again later and the channel might come back "on"). Do you have any suggestions on how to encode that? *From a Device=92s perspective* =96 there are really THREE states that a gi= ven > channel might be in: > ****a) I=92ve been told I can use it, > b) I=92ve been told it is unavailable, > c) I haven=92t been told either. I agree. I'm not sure this does anything to address the "temporal stickiness" of the channel on/off information you had in your example. Best regards, Andy Lee | Google Inc. | tvfool@google.com | 408-230-0522 On Wed, Sep 25, 2013 at 1:39 PM, Harasty, Daniel J wrote: > As a Database provider, I think it is VERY IMPORTANT to have the ability > to state either of these unambiguously:**** > > **=B7 **These are the handful of channels that are available unti= l > 6pm.**** > > **o **(Implicitly: if you want to know about stuff after 6pm, send > another request between now and then =96 preferable closer to 6pm.)**** > > **=B7 **These are the handful of channels that are available unti= l > 6pm, and I=92m telling you NOW that NOTHING is available starting at 6pm = for > the next 18 hours.**** > > **o **(Implicitly: I=92ve told you everything I can about all > availability until Noon tomorrow; don=92t bother sending me another reque= st > until close to Noon tomorrow.)**** > > ** ** > > This is close =96 but not exactly the same as Gabor=92s sentiment:**** > > This has the drawback of not distinguishing between being silent about a > channel that is within the database's purview (channel off), and being > silent about a channel that is outside the database's purview (out of sco= pe > for given ruleset).**** > > In other words, sometimes the server is =93being silent=94 because =93cer= tain > frequencies are outside the database=92s purview=94. But another reason = to =93be > silent=94 is that the database is only telling the Device about events up= to > a certain time.**** > > ** ** > > This is the very concept I was trying to get at when I tried to formulate > an example where =93being silent=94 (Gabor=92s term) or =93no mention=94 = (my term =96 > same concept) confers =93no information=94. In my example, I was NOT say= ing > =93the Database has no information about the future=94; rather I was givi= ng and > example where the *message* had =93no information=94 about use of the cha= nnel > at some future time. (I apologize if I was not clear in my point at that > time.)**** > > ** ** > > *From a Device=92s perspective* =96 there are really THREE states that a > given channel might be in: **** > > a) I=92ve been told I can use it, **** > > b) I=92ve been told it is unavailable, **** > > c) I haven=92t been told either.**** > > ** ** > > I think we ALL agree:**** > > The device CAN=92T USE THE CHANNEL if it is in either cas= e > =93b=94 or =93c=94 above.**** > > ** ** > > But the point I=92ve been trying to make is:**** > > The device NEED NOT ASK AGAIN if it knows that the channe= l > is in case =93a=94 or =93b=94 above.**** > > ** ** > > That is why case =93b=94 and =93c=94 are *not synonymous*. All along, th= at=92s > been my objection to =93no mention=94 being synonymous with the Database > declaring that a channel is =93is unavailable=94. **** > > ** ** > > And that=92s why I think it is important for the Database to have a way t= o > EXPLICTLY state a =93channel unavailable=94. If it is a weakness in PAWS= =96 > with impact to the Database =96 if I can=92t express the difference betw= een > =93b=94 and =93c=94.**** > > ** ** > > ** ** > > Dan Harasty**** > > ** ** > > ** ** > > ** ** > > *From:* paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] *On Behalf > Of *Vincent Chen > *Sent:* Wednesday, September 25, 2013 12:10 PM > *To:* Peter Stanforth > *Cc:* paws@ietf.org > > *Subject:* Re: [paws] Spectrum encoding discussion**** > > ** ** > > Thanks for sharing your insights Peter.**** > > ** ** > > This is an opportunity to have the protocol be a bit more forward thinkin= g > than what current regulators are thinking.**** > > ** ** > > Let's try to focus on Gabor's question again of how to express > "unavailability", but phrasing it differently.**** > > ** ** > > If we were to take the view that the Database provides responses for > frequencies where the device may operate, then**** > > ** ** > > - Any frequency ranges missing for the response means the device "is not > granted permission" to operate in those frequencies under the rules > implemented by the Database**** > > ** ** > > Then is it still useful to distinguish why permission is not granted? (of= f > vs outside band plan)**** > > ** ** > > If not, then Option a), simply having gaps in the frequency ranges would > satisfy this use case.**** > > ** ** > > Is this a good compromise?**** > > ** ** > > -vince**** > > ** ** > > On Wed, Sep 25, 2013 at 5:01 AM, Peter Stanforth > wrote:**** > > Lowering the power to meet the mask is the easy way you get a radio > certified =96 thus permission to operate. How is that anything to do with= the > database - which is simply managing Regulator policy?**** > > The ruleset is going to tell you what masks and other operating parameter= s > are acceptable within a regulatory domain. I can't imagine a Regulator > allowing a database operator to manipulate the unintentional interference > in adjacent channels. If it did why stop there? Why couldn't the database > manipulate co-channel interference to nearby protected entities?**** > > I thought we had a fairly elegant and simple solution. The ruleset define= s > the box the device can operate in and the database provides a specific se= t > of permitted channels/frequencies within that box based on the location, > time, and type of device making the request. All with respect to the > specific list of entities the database has been told to protect at that > location at that time.**** > > ** ** > > One final comment and then I will rest my case. I have had conversations > with several Regulators about this recently, and they do not like any > notion that the database is "thinking" about the answer.**** > > In every case they have said something along the lines of "if the databas= e > does not explicitly give a device permission to use a channel the device = is > not allowed to use it".**** > > In every case they have gone somewhat further stating that if the databas= e > operation goes beyond this simple approach they think it highly unlikely > that they will get cooperation from incumbents. If you don't believe me = =96 > go ask them!**** > > Which brings me back to my soap box. We want to get PAWS done so we can > enable white space. In my humble opinion, the more time we spend > pontificating and the more complex we make it we are likely to achieve th= e > opposite.**** > > Peter S.**** > > ** ** > > ** ** > > *From: *Paul Lambert > *Date: *Tuesday, September 24, 2013 2:48 PM > *To: *Don Joslyn , Vincent Chen < > vchen@google.com>, "gabor.bajko@nokia.com" , " > paws@ietf.org" **** > > > *Subject: *Re: [paws] Spectrum encoding discussion**** > > ** ** > > In line below =85 speaking strongly in favor of "b" **** > > ** ** > > ** ** > > Gabor,**** > > **** > > I agree on possible renaming, if we want to specify unavailable channels.= * > *** > > **** > > Please see comments inline. **** > > **** > > On Mon, Sep 23, 2013 at 12:56 PM, wrote:**** > > Vince,**** > > This proposal of yours below could potentially become very confusing. The > message itself is named Available Spectrum Request, and you propose the > Available Spectrum Response to include a bunch of channels with unspecifi= ed > power levels, which are btw, not available channels. **** > > So far, we have 4 proposed ways to indicate unavailable channels:**** > > a) Not listing it, implicit unavailability**** > > This has the drawback of not distinguishing between being silent about a > channel that is within the database's purview (channel off), and being > silent about a channel that is outside the database's purview (out of sco= pe > for given ruleset).**** > > **** > > [DJ =96 Why should the database care about channels that are outside the > scope of the ruleset specified by the radio? For example, if the specifie= d > ruleset is FCC-related, then why would I need to include Ofcom-related > channels in the response? Am I missing something?]**** > > ** ** > > The rules have strict adjacent channel requirements. Meeting the spectra= l > mask for the adjacent channels is one of the hardest parts for fielding > real equipment. If the rules allow relative measurement of the adjacent > channel energy, you can simply lower your transmit power to the point tha= t > you can meet the adjacent requirements. **** > > ** ** > > For a general White Spaces solution =96 it is critical to have knowledge = for > the full spectrum mask. The full spectrum mask includes adjacent > non-allowed channels.**** > > ** ** > > RF channel usage are NOT a binary on/off or a simple transmit level. The > mask has a specific contour that extends beyond the "allowed" channel. > Transmitters will always send energy in more than the allowed channel!**= * > * > > ** ** > > ** ** > > ** ** > > Paul**** > > ** ** > > ** ** > > **** > > b) List unavailable channels and specify the power limit, eg -56dbm*= * > ** > > Since the protocol should stand on its own, independent of any particular > regulatory rule, do we really want to rule this out? In our interpretatio= ns > of the FCC rules, for example, a Database is not prevented from doing thi= s. > **** > > **** > > [DJ =96 I=92m still in favor of just using the implicit unavailability me= thod > described above in a). What value is there in providing a power level for > an unavailable channel? If I=92m the radio, I can=92t use the channel, an= d I=92m > not going to intentionally transmit in that channel. This comment also > applies to c) and d).]**** > > **** > > c) List unavailable channels and specify =96inf as power limit**** > > **** > > "-Inf" is not really workable, because JSON does not allow Infinity or > NaNs (http://tools.ietf.org/html/rfc4627), hence the d) proposal.**** > > **** > > d) List unavailable channels and do not specify any power limit **** > > **** > > So far, we have majority in favour of a), few people who could live or > prefer c) and sort of consensus to strike out option b) from the list abo= ve. > **** > > **** > > We=92ll wait for more input on the list before declaring rough consensus = for > the question above; then we=92ll go back to the original question on whet= her > the encoding of spectrum profile should be option 1 or option 2.**** > > **** > > p.s. It looks to me, that if we want to specify unavailable channels, we > may need to modify the names of the paws messages to =91Spectrum schedule= =92 or > sg along these lines.**** > > **** > > - Gabor**** > > **** > > ** ** > > ** ** > > > > **** > > ** ** > > -- > -vince **** > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > > --089e0149d0ae8fa67204e73bdea9 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi Dan,

=A0<= span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73= ,125)">These are the handful of channels that are available until 6pm.
o=A0=A0=A0(Implicitly= : if you want to know about stuff after 6pm, send another request between n= ow and then =96 preferable closer to 6pm.)
=B7=A0=A0=A0=A0=A0=A0=A0=A0=A0These = are the handful of channels that are available until 6pm, and I=92m telling= you NOW that NOTHING is available starting at 6pm for the next 18 hours. o=A0=A0=A0(Implicitly= : I=92ve told you everything I can about all availability until Noon tomorr= ow; don=92t bother sending me another request until close to Noon tomorrow.= )

Thank= s for the nice example.

This sounds like a new concept to me. =A0To me it's s= uggesting a distinction of a channel "on-to-off" transition as be= ing either "hard" (off permanently as far as the database is awar= e) or "soft" (ask me again later and the channel might come back = "on"). =A0Do you have any suggestions on how to encode that?


<= div class=3D"gmail_extra">
From a Device=92s perspective=A0=96 there are= really THREE states that a given channel might be in:
a) I=92ve been told I can use it,
b) I=92ve been told it is unavailable,
c) I haven=92t been told either.

I agree.

I'm not sure this does= anything to address the "temporal stickiness" of the channel on/= off information you had in your example.


<= div class=3D"gmail_extra">
Best regards= ,

Andy Lee=A0| =A0Google Inc. |=A0tvfool@google.com=A0| =A0408-230-0522


On Wed, Sep 25, 2013 at 1:39 PM, Harasty= , Daniel J <dharasty@appcomsci.com> wrote:

As a Database provider, I think it is VERY IMPORTANT to have the ability= to state either of these unambiguously:

=B7=A0=A0=A0=A0=A0=A0=A0=A0 The= se are the handful of channels that are available until 6pm.<= /span>

o=A0=A0 (Implicitly: if you want to know about stuff after 6pm, sen= d another request between now and then =96 preferable closer to 6pm.)

=B7=A0=A0=A0=A0=A0=A0=A0=A0 The= se are the handful of channels that are available until 6pm, and I=92m tell= ing you NOW that NOTHING is available starting at 6pm for the next 18 hours= .

o=A0=A0 (Implicitly: I=92ve told you everything I can about all ava= ilability until Noon tomorrow; don=92t bother sending me another request un= til close to Noon tomorrow.)

=A0

Thi= s is close =96 but not exactly the same as Gabor=92s sentiment:

This has the dr= awback of not distinguishing between=A0being silent about a channel that is within the dat= abase's purview (channel off), and being silent about a channel that is= outside the database's purview (out of scope for given ruleset).

In other words, sometimes the server is =93bein= g silent=94 because =93certain frequencies are outside the database=92s pur= view=94.=A0 But another reason to =93be silent=94 is that the database is o= nly telling the Device about events up to a certain time.

=A0

Thi= s is the very concept I was trying to get at when I tried to formulate an e= xample where =93being silent=94 (Gabor=92s term) or =93no mention=94 (my te= rm =96 same concept) confers =93no information=94.=A0 In my example, I was = NOT saying =93the Database has no information about the future=94; rather I= was giving and example where the message had =93no information=94 a= bout use of the channel at some future time.=A0 (I apologize if I was not c= lear in my point at that time.)

=A0

= >From a Device=92s perspective =96 there are really THREE= states that a given channel might be in:

a) I=92ve been told I can= use it,

b) I=92ve been told it is unavailable,

c) I haven=92t been told = either.

=A0

I think we ALL agree:

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 The device CAN= =92T USE THE CHANNEL if it is in either case =93b=94 or =93c=94 above.

=A0

But= the point I=92ve been trying to make is:

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 The dev= ice NEED NOT ASK AGAIN if it knows that the channel is in case =93a=94 or = =93b=94 above.

=A0

Tha= t is why case =93b=94 and =93c=94 are not synonymous.=A0 All along, = that=92s been my objection to =93no mention=94 being synonymous with the Da= tabase declaring that a channel is =93is unavailable=94.=A0 <= /span>

=A0

And= that=92s why I think it is important for the Database to have a way to EXP= LICTLY state a =93channel unavailable=94.=A0 If it is a weakness in PAWS = =96 with impact to the Database =96 =A0if I can=92t express the difference = between =93b=94 and =93c=94.

=A0

= =A0

Dan Harasty

=A0

=A0

= =A0

=A0

Thanks for sharing your insights Peter.<= /p>

=A0

This is= an opportunity to have the protocol be a bit more forward thinking than wh= at current regulators are thinking.

=A0

Let&= #39;s try to focus on Gabor's question again of how to express "un= availability", but phrasing it differently.

=A0

If we were to t= ake the view that the Database provides responses for frequencies where the= device may operate, then

= =A0

=A0- Any frequency ranges missing for the response= means the device "is not granted permission" to operate in those= frequencies under the rules implemented by the Database

<= /div>

=A0

Then is it= still useful to distinguish why permission is not granted? (off vs outside= band plan)

=A0

=

If not, then Option a), simply having gaps in the freque= ncy ranges would satisfy this use case.

=A0

Is this a good comprom= ise?

=A0

-vin= ce

=A0

On Wed, Sep 25, 2013 at 5:01 A= M, Peter Stanforth <peter@spectrumbridge.com> wrote:

=A0Lowering the power to meet the mask is the easy way you get= a radio certified =96 thus permission to operate. How is that anything to = do with the database - which is simply managing Regulator policy?=

The ruleset is going to tell you what masks and other operati= ng parameters are acceptable within a regulatory domain. I can't imagin= e a Regulator allowing a database operator to manipulate the unintentional = interference in adjacent channels. If it did why stop there? Why couldn'= ;t the database manipulate co-channel interference to nearby protected enti= ties?

I thought we had a fairly elegant and simple solution. The ru= leset defines the box the device can operate in and the database provides a= specific set of permitted channels/frequencies within that box based on th= e location, time, and type of device making the request. All with respect t= o the specific list of entities the database has been told to protect at th= at location at that time.

=A0

One final comment a= nd then I will rest my case. I have had conversations with several Regulato= rs about this recently, and they do not like any notion that the database i= s "thinking" about the answer.

In every case they have said something along the lines of &qu= ot;if the database does not explicitly give a device permission to use a ch= annel the device is not allowed to use it".

In every case they have gone somewhat further stating that if= the database operation goes beyond this simple approach they think it high= ly unlikely that they will get cooperation from incumbents. If you don'= t believe me =96 go ask them!

Which brings me back to my soap box. We want to get PAWS done= so we can enable white space. In my humble opinion, the more time we spend= pontificating and the more complex we make it we are likely to achieve the= opposite.

Peter S.

=A0<= /u>

=A0

From: Paul Lambert <paul@marvell.com>
Date: Tuesday, September 24, 2013 2:48 PM
To: Don Joslyn &= lt;d.josly= n@spectrumbridge.com>, Vincent Chen <vchen@google.com>, "gabor.bajko@nokia.com" &= lt;Gabor.Bajko@n= okia.com>, "= paws@ietf.org" <paws@ietf.org>


Subject: Re: [paws] Spectrum encoding discussion=

=A0

<= span style=3D"font-size:11pt;font-family:Calibri,sans-serif">In line below = =85 speaking strongly in favor of "b"=A0

=A0

=A0

Gabor,<= /u>

=A0

I agree on= possible renaming, if we want to specify unavailable channels.

=A0

Please see comments inline.=A0

=A0

On Mon, Se= p 23, 2013 at 12:56 PM, <Gabor.Bajko@nokia.com> wrote:

Vince,

This proposal = of yours below could potentially become very confusing. The message itself = is named Available Spectrum Request, and you propose the Available Spectrum= Response to include a bunch of channels with unspecified power levels, whi= ch are btw, not available channels.

=A0So far, we have 4 proposed ways to indicate unavai= lable channels:

a)=A0=A0= =A0=A0=A0 Not listing it, implicit unavailability<= /span>

This has the drawback of not distinguishing = between=A0being= silent about a channel that is within the database's purview (channel = off), and being silent about a channel that is outside the database's p= urview (out of scope for given ruleset).

=A0

[DJ= =96 Why should the database care about channels that are outside the scope= of the ruleset specified by the radio? For example, if the specified rules= et is FCC-related, then why would I need to include Ofcom-related channels = in the response? Am I missing something?]

<= span style=3D"font-size:10.5pt;font-family:Calibri,sans-serif">=A0

The rules have strict adjacent channel requir= ements. =A0Meeting the spectral mask for the adjacent channels =A0is one of= the hardest parts for fielding real equipment. =A0If the rules allow relat= ive measurement of the adjacent channel energy, you can simply lower your t= ransmit power to the point that you can meet the adjacent requirements. =A0=

=A0

For a general White= Spaces solution =96 it is critical to have knowledge for the full spectrum= mask. =A0The full spectrum mask includes adjacent non-allowed channels.=

=A0

RF channel usage ar= e NOT a binary on/off or a simple transmit level. =A0The mask has a specifi= c contour that extends beyond the "allowed" channel. =A0Transmitt= ers will always send energy in more than the allowed channel!=

=A0

=A0

=A0

Paul<= /span>

=A0

=A0

=A0

b)=A0=A0=A0=A0=A0 List unavailable channels and specify the p= ower limit, eg -56dbm

Since the protocol should stand= on its own, independent of any particular regulatory rule, do we really wa= nt to rule this out? In our interpretations of the FCC rules, for example, = a Database is not prevented from doing this.

=A0

[DJ= =96 I=92m still in favor of just using the implicit unavailability method = described above in a). What value is there in providing a power level for a= n unavailable channel? If I=92m the radio, I can=92t use the channel, and I= =92m not going to intentionally transmit in that channel. This comment also= applies to c) and d).]

=A0

<= p> c)=A0=A0=A0=A0=A0=A0 List unavailable = channels and specify =96inf as power limit

=A0

"-Inf" is not really workable, because JSON does n= ot allow Infinity or NaNs (http://tools.ietf.org/html/rfc4627), hence the d) prop= osal.

=A0

<= p> d)=A0=A0=A0=A0=A0 List unavailable cha= nnels and do not specify any power limit=A0

=A0

So far, we have majority in favour of a), few people = who could live or prefer c) and sort of consensus to strike out option b) f= rom the list above.

=A0

We= =92ll wait for more input on the list before declaring rough consensus for = the question above; then we=92ll go back to the original question on whethe= r the encoding of spectrum profile should be option 1 or option 2.

=A0

p.s= . It looks to me, that if we want to specify unavailable channels, we may n= eed to modify the names of the paws messages to =91Spectrum schedule=92 or = sg along these lines.

=A0

-=A0=A0=A0=A0=A0=A0=A0=A0=A0 Gabor

=A0

=

=A0<= /span>

=A0



=A0

--
-vince


_______________________________________________
paws mailing list
paws@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/paws


--089e0149d0ae8fa67204e73bdea9-- From Gabor.Bajko@nokia.com Wed Sep 25 16:04:10 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A43B711E8117 for ; Wed, 25 Sep 2013 16:04:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.808 X-Spam-Level: X-Spam-Status: No, score=-5.808 tagged_above=-999 required=5 tests=[AWL=0.790, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DXdx2uQGws+p for ; Wed, 25 Sep 2013 16:03:54 -0700 (PDT) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id 4055821F9E26 for ; Wed, 25 Sep 2013 16:03:39 -0700 (PDT) Received: from smtp.mgd.nokia.com ([65.54.30.48]) by mgw-sa02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r8PMuUr7018517 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 26 Sep 2013 01:56:31 +0300 Received: from 008-AM1MPN1-006.mgdnok.nokia.com ([169.254.6.66]) by 008-AM1MMR1-014.mgdnok.nokia.com ([2002:4136:1e30::4136:1e30]) with mapi id 14.03.0136.001; Wed, 25 Sep 2013 22:56:30 +0000 From: To: , Thread-Topic: [paws] Spectrum encoding discussion Thread-Index: AQHOtLJJlV0A7sF1Y0u4PChODFE3GpnM2N2AgABHaoCAAAbdgIAAB0+AgAACXwCAAAsCAIABLRqAgAClvgCAAAR7EIAAFgcAgAAa+ACAABHGgIAADQKAgAAQcgCABElGUIAAYkOAgAEWwYCAAA46AIABIMOAgACVcYCAABzt8A== Date: Wed, 25 Sep 2013 22:56:29 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E47605364C49@008-AM1MPN1-006.mgdnok.nokia.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [69.181.65.212] Content-Type: multipart/alternative; boundary="_000_1ECAFF543A2FED4EA2BEB6CACE08E47605364C49008AM1MPN1006mg_" MIME-Version: 1.0 X-Nokia-AV: Clean Cc: paws@ietf.org Subject: Re: [paws] Spectrum encoding discussion X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 23:04:11 -0000 --_000_1ECAFF543A2FED4EA2BEB6CACE08E47605364C49008AM1MPN1006mg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Andy, This option (e) proposal sounds like you may want to encode two things whic= h could be separated; the available channels, and the authoritative bands. We could leave the available spectrum req/resp unchanged, and eg have a sep= arate req/resp for the authoritative bands. And we could also encode the power leakage limits eg inside the ruleset inf= o, so that devices would not necessarily need to be hard-coded with those, = to satisfy everyone. Could this be an agreeable way forward? - Gabor From: ext Andy Lee [mailto:tvfool@google.com] Sent: Wednesday, September 25, 2013 1:57 PM To: Peter Stanforth Cc: Paul Lambert; Vincent Chen; Bajko Gabor (Nokia-CIC/SiliconValley); paws= @ietf.org Subject: Re: [paws] Spectrum encoding discussion Hi Peter, I can't imagine a Regulator allowing a database operator to manipulate the = unintentional interference in adjacent channels. If it did why stop there? = Why couldn't the database manipulate co-channel interference to nearby prot= ected entities? The recent discussions have been about data encoding and nothing more. The= premise is that IF there is some information the database wants to communi= cate to the white space device, HOW is that data encoded into the message. As a case in point, section 15.709(c)(1) of the rules clearly defines what = the "off" channel power limits must be. The rules originally called for a = "relative" OOB emission limit, but after some industry discussion, the FCC = settled on these "absolute" OOB emission limits instead. The values are cl= early defined, but its not clear whether a database would want to communica= te these parameters to the device or not. On one hand, the database can assume that the device has these values hard-= coded into its firmware and therefore does not need to send that informatio= n over PAWS. On the other hand, these power levels are part of the TVWS rules and perhap= s is something that the database should communicate to the WSD. There are = potentially beneficial things that a WSD could do with that information if = it was provided at run-time (e.g., for future-proofing the device, or choos= ing operating channels more intelligently). PAWS does not need to address WHY a particular parameter should or should n= ot be sent over the protocol. There are many regulatory, business, or tech= nological reasons why these choices might change, and those decisions are b= eyond the scope of the protocol itself. However, PAWS can and should address HOW data gets encoded IF a device or d= atabase decides to send it. i.e., IF you want to encode [X], then you SHALL use [encoding X] IF you want to encode [Y], then you SHALL use [encoding Y] etc. I can identify at least three distinct concepts that have been discussed so= far, which I would categorize as follows: * (i) Explicit "on", Implicit "off" * Anything not explicitly specified as "on" would implicitly be trea= ted as "off" * The recipient must have apriori knowledge about how to comply with= the "off" channel, "special" channel (e.g., channel 37), and "band-edge" p= rotection ratios * There is no distinction between "off" channels, "special" channels= , and "band-edge" constraints in the message itself * This requires a way to encode gaps or discontinuities in the spect= rum profile * This is equivalent to Gabor's option (a) * (ii) Explicit "on", Explicit "off" with no power level given * Every channel would be either explicitly "on" or explicitly "off" * Any frequency blocks that are not explicitly "on" or explicitly "o= ff" are considered to be "out-of-scope" for the current database or ruleset= , and this implicitly gives the "band-edge" boundaries * The recipient must have apriori knowledge about how to comply with= the "off" channel, "special" channel, and "band-edge" protection ratios * The recipient can infer from the message when to apply "off" chann= el constraints and when to apply "band-edge" constraints * This requires a way to encode gaps or discontinuities in the spect= rum profile AND requires a way to encode explicit "off" channels with no sp= ecified power value * This is equivalent to Gabor's options (c) and (d) * (iii) Explicit "on", Explicit "off" with power level given * Every channel would be either explicitly "on" or explicitly "off" * Any frequency blocks that are not explicitly "on" or explicitly "o= ff" are considered to be "out-of-scope" for the current database or ruleset= , and this implicitly gives the "band-edge" boundaries * The "off" channel, "special" channel, and "band-edge" protection r= atios are explicitly provided in the message, and a device has the option o= f either using that information or ignoring it (default back to apriori kno= wledge of the protection ratios) * This requires a way to encode gaps or discontinuities in the spect= rum profile * This is equivalent to Gabor's option (b) I think all three types of encoding have their uses, and PAWS should probab= ly allow all three possibilities. It looks like all three encoding types need a way to express gaps or discon= tinuities in the spectrum profile. I think the latest proposal from Vince,= using a list of lists, addresses this problem nicely. It also looks like encodings for (i) and (iii) are logically equivalent, wi= th the only real difference being that encoding (iii) includes more data po= ints in the spectrum profile than encoding (i). I don't think anything els= e needs to be added to the spec to support both of these encodings. That leaves us with encoding (ii), where we need to add something new to th= e spec to encode explicitly "off" frequency blocks that have no power level= given. For this, we have two proposals: Option (c): Use -inf as the power value in a spectrum profile element Option (d): Leave the power value blank in a spectrum profile element I'd suggest maybe considering yet another proposal: Option (e): Use normal encoding (i) for explicit "on" channels, and then ha= ve a separate list of frequency start/stop pairs indicating the authoritati= ve bands for which the database operates. Anything that is inside the auth= oritative bands but not in an explicitly "on" chunk is effectively saying i= t's explicitly "off". Anything outside of the list of authoritative bands = is considered "out-of-scope" for the database and this essentially lists th= e "band-edge" boundaries. Best regards, Andy Lee | Google Inc. | tvfool@google.com | 408-230-0522 On Wed, Sep 25, 2013 at 5:01 AM, Peter Stanforth > wrote: Lowering the power to meet the mask is the easy way you get a radio certif= ied - thus permission to operate. How is that anything to do with the datab= ase - which is simply managing Regulator policy? The ruleset is going to tell you what masks and other operating parameters = are acceptable within a regulatory domain. I can't imagine a Regulator allo= wing a database operator to manipulate the unintentional interference in ad= jacent channels. If it did why stop there? Why couldn't the database manipu= late co-channel interference to nearby protected entities? I thought we had a fairly elegant and simple solution. The ruleset defines = the box the device can operate in and the database provides a specific set = of permitted channels/frequencies within that box based on the location, ti= me, and type of device making the request. All with respect to the specific= list of entities the database has been told to protect at that location at= that time. One final comment and then I will rest my case. I have had conversations wi= th several Regulators about this recently, and they do not like any notion = that the database is "thinking" about the answer. In every case they have said something along the lines of "if the database = does not explicitly give a device permission to use a channel the device is= not allowed to use it". In every case they have gone somewhat further stating that if the database = operation goes beyond this simple approach they think it highly unlikely th= at they will get cooperation from incumbents. If you don't believe me - go = ask them! Which brings me back to my soap box. We want to get PAWS done so we can ena= ble white space. In my humble opinion, the more time we spend pontificating= and the more complex we make it we are likely to achieve the opposite. Peter S. From: Paul Lambert > Date: Tuesday, September 24, 2013 2:48 PM To: Don Joslyn >, Vincent Chen >, "gabor.baj= ko@nokia.com" >, "paws@ietf.org" > Subject: Re: [paws] Spectrum encoding discussion In line below ... speaking strongly in favor of "b" Gabor, I agree on possible renaming, if we want to specify unavailable channels. Please see comments inline. On Mon, Sep 23, 2013 at 12:56 PM, > wrote: Vince, This proposal of yours below could potentially become very confusing. The m= essage itself is named Available Spectrum Request, and you propose the Avai= lable Spectrum Response to include a bunch of channels with unspecified pow= er levels, which are btw, not available channels. So far, we have 4 proposed ways to indicate unavailable channels: a) Not listing it, implicit unavailability This has the drawback of not distinguishing between being silent about a ch= annel that is within the database's purview (channel off), and being silent= about a channel that is outside the database's purview (out of scope for g= iven ruleset). [DJ - Why should the database care about channels that are outside the scop= e of the ruleset specified by the radio? For example, if the specified rule= set is FCC-related, then why would I need to include Ofcom-related channels= in the response? Am I missing something?] The rules have strict adjacent channel requirements. Meeting the spectral = mask for the adjacent channels is one of the hardest parts for fielding re= al equipment. If the rules allow relative measurement of the adjacent chan= nel energy, you can simply lower your transmit power to the point that you = can meet the adjacent requirements. For a general White Spaces solution - it is critical to have knowledge for = the full spectrum mask. The full spectrum mask includes adjacent non-allow= ed channels. RF channel usage are NOT a binary on/off or a simple transmit level. The m= ask has a specific contour that extends beyond the "allowed" channel. Tran= smitters will always send energy in more than the allowed channel! Paul b) List unavailable channels and specify the power limit, eg -56dbm Since the protocol should stand on its own, independent of any particular r= egulatory rule, do we really want to rule this out? In our interpretations = of the FCC rules, for example, a Database is not prevented from doing this. [DJ - I'm still in favor of just using the implicit unavailability method d= escribed above in a). What value is there in providing a power level for an= unavailable channel? If I'm the radio, I can't use the channel, and I'm no= t going to intentionally transmit in that channel. This comment also applie= s to c) and d).] c) List unavailable channels and specify -inf as power limit "-Inf" is not really workable, because JSON does not allow Infinity or NaNs= (http://tools.ietf.org/html/rfc4627), hence the d) proposal. d) List unavailable channels and do not specify any power limit So far, we have majority in favour of a), few people who could live or pref= er c) and sort of consensus to strike out option b) from the list above. We'll wait for more input on the list before declaring rough consensus for = the question above; then we'll go back to the original question on whether = the encoding of spectrum profile should be option 1 or option 2. p.s. It looks to me, that if we want to specify unavailable channels, we ma= y need to modify the names of the paws messages to 'Spectrum schedule' or s= g along these lines. - Gabor _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws --_000_1ECAFF543A2FED4EA2BEB6CACE08E47605364C49008AM1MPN1006mg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Andy,

 <= /p>

This option (e) proposal = sounds like you may want to encode two things which could be separated; the= available channels, and the authoritative bands.

We could leave the availa= ble spectrum req/resp unchanged, and eg have a separate req/resp for the au= thoritative bands.

And we could also encode = the power leakage limits eg inside the ruleset info, so that devices would = not necessarily need to be hard-coded with those, to satisfy everyone.

Could this be an agreeabl= e way forward?

 <= /p>

- =          Gabor<= /span>

 <= /p>

From: ext Andy= Lee [mailto:tvfool@google.com]
Sent: Wednesday, September 25, 2013 1:57 PM
To: Peter Stanforth
Cc: Paul Lambert; Vincent Chen; Bajko Gabor (Nokia-CIC/SiliconValley= ); paws@ietf.org
Subject: Re: [paws] Spectrum encoding discussion

 

Hi Peter,

 

I can't imagine a Regulator allowing a = database operator to manipulate the unintentional interference in adjacent = channels. If it did why stop there? Why couldn't the database manipulate co-channel interference to nearby protected entities?

 

The recent discussions have been about data encoding= and nothing more.  The premise is that IF there is some information the database wants to communicate to th= e white space device, HOW is that data encoded into the message.

 

As a case in point, section 15.709(c)(1) of the rule= s clearly defines what the "off" channel power limits must be. &n= bsp;The rules originally called for a "relative" OOB emission lim= it, but after some industry discussion, the FCC settled on these "absolute" OOB emission limits instead.  The values a= re clearly defined, but its not clear whether a database would want to comm= unicate these parameters to the device or not.

 

On one hand, the database can assume that the device= has these values hard-coded into its firmware and therefore does not need = to send that information over PAWS.

 

On the other hand, these power levels are part of th= e TVWS rules and perhaps is something that the database should communicate = to the WSD.  There are potentially beneficial things that a WSD could = do with that information if it was provided at run-time (e.g., for future-proofing the device, or choosing operating c= hannels more intelligently).

 

 

 

 

 

PAWS does not need to address WHY a particular pa= rameter should or should not be sent over the protocol.  There are= many regulatory, business, or technological reasons why these choices migh= t change, and those decisions are beyond the scope of the protocol itself.

 

However, PAWS can and should address HOW data get= s encoded IF a device or database decides to send it.  i.e.,<= /o:p>

 

IF you want to encode [X], then you SHALL use [encod= ing X]

IF you want to encode [Y], then you SHALL use [encod= ing Y]

etc.

 

I can identify at least three distinct concepts that= have been discussed so far, which I would categorize as follows:

  • (i) Explicit "on", Implicit "off"
    • Anything not explicitly specified as "on" would implicitly be tre= ated as "off"
    • The recipient must have apriori knowledge about how to comply with the &quo= t;off" channel, "special" channel (e.g., channel 37), and &q= uot;band-edge" protection ratios
    • There is no distinction between "off" channels, "special&quo= t; channels, and "band-edge" constraints in the message itself
    • This requires a way to encode gaps or discontinuities in the spectrum profi= le
    • This is equivalent to Gabor's option (a)

 

  • (ii) Explicit "on", Explicit "off" with no po= wer level given
    • Every channel would be either explicitly "on" or explicitly "= ;off"
    • Any frequency blocks that are not explicitly "on" or explicitly &= quot;off" are considered to be "out-of-scope" for the curren= t database or ruleset, and this implicitly gives the "band-edge" = boundaries
    • The recipient must have apriori knowledge about how to comply with the &quo= t;off" channel, "special" channel, and "band-edge"= protection ratios
    • The recipient can infer from the message when to apply "off" chan= nel constraints and when to apply "band-edge" constraints
    • This requires a way to encode gaps or discontinuities in the spectrum profi= le AND requires a way to encode explicit "off" channels with no s= pecified power value
    • This is equivalent to Gabor's options (c) and (d)

 

  • (iii) Explicit "on", Explicit "off" with powe= r level given
    • Every channel would be either explicitly "on" or explicitly "= ;off"
    • Any frequency blocks that are not explicitly "on" or explicitly &= quot;off" are considered to be "out-of-scope" for the curren= t database or ruleset, and this implicitly gives the "band-edge" = boundaries
    • The "off" channel, "special" channel, and "band-ed= ge" protection ratios are explicitly provided in the message, and a de= vice has the option of either using that information or ignoring it (defaul= t back to apriori knowledge of the protection ratios)
    • This requires a way to encode gaps or discontinuities in the spectrum profi= le
    • This is equivalent to Gabor's option (b)

 

 

I think all three types of encoding have their uses,= and PAWS should probably allow all three possibilities.

 

It looks like all three encoding types need a way to= express gaps or discontinuities in the spectrum profile.  I think the= latest proposal from Vince, using a list of lists, addresses this problem = nicely.

 

It also looks like encodings for (i) and (iii) are l= ogically equivalent, with the only real difference being that encoding (iii= ) includes more data points in the spectrum profile than encoding (i). &nbs= p;I don't think anything else needs to be added to the spec to support both of these encodings.

 

 

 

That leaves us with encoding (ii), where we need to = add something new to the spec to encode explicitly "off" frequenc= y blocks that have no power level given.  For this, we have two propos= als:

 

Option (c): Use -inf as the power value in a spectru= m profile element

Option (d): Leave the power value blank in a spectru= m profile element

 

I'd suggest maybe considering yet another proposal:<= o:p>

 

Option (e): Use normal encoding (i) for explicit &qu= ot;on" channels, and then have a separate list of frequency start/stop= pairs indicating the authoritative bands for which the database operates. =  Anything that is inside the authoritative bands but not in an explicitly "on" chunk is effectively saying it's e= xplicitly "off".  Anything outside of the list of authoritat= ive bands is considered "out-of-scope" for the database and this = essentially lists the "band-edge" boundaries.

 

 

 

Best regards,


 

Andy Lee |

 Google Inc. |

 tvfool@google.com |

 408-230-0522

 

On Wed, Sep 25, 2013 at 5:01 AM, Peter Stanforth <= ;peter@spectr= umbridge.com> wrote:

 Lowering the power to meet the ma= sk is the easy way you get a radio certified – thus permission to ope= rate. How is that anything to do with the database - which is simply managing Regulator policy?

The ruleset is going to tell you what m= asks and other operating parameters are acceptable within a regulatory doma= in. I can't imagine a Regulator allowing a database operator to manipulate the unintentional interference in adjacent channels. If it d= id why stop there? Why couldn't the database manipulate co-channel interfer= ence to nearby protected entities?

I thought we had a fairly elegant and s= imple solution. The ruleset defines the box the device can operate in and t= he database provides a specific set of permitted channels/frequencies within that box based on the location, time, and type of device making the= request. All with respect to the specific list of entities the database ha= s been told to protect at that location at that time.

 

One final comment and then I will rest = my case. I have had conversations with several Regulators about this recent= ly, and they do not like any notion that the database is "thinking" about the answer.

In every case they have said something = along the lines of "if the database does not explicitly give a device = permission to use a channel the device is not allowed to use it".

In every case they have gone somewhat f= urther stating that if the database operation goes beyond this simple appro= ach they think it highly unlikely that they will get cooperation from incumbents. If you don't believe me – go ask them!

Which brings me back to my soap box. We= want to get PAWS done so we can enable white space. In my humble opinion, = the more time we spend pontificating and the more complex we make it we are likely to achieve the opposite.

Peter S.

 

 

From: Paul Lambert <paul@marvell.com>
Date: Tuesday, September 24, 2013 2:48 PM
To: Don Joslyn <d.joslyn@spectrumbridge.com>, Vincent Chen <vchen@google.com>, = "gabor.bajk= o@nokia.com" <Gabor.Bajko= @nokia.com>, "paws@ietf.org" <paws@ietf.org>


Subject: Re: [paws] Spectrum encoding discussion

 

In line below … speaking strongly= in favor of "b" 

 

 

Gabor,

 

I agree on possible renaming, if we want to specify unavailable ch= annels.

 

Please see comments inline. 

 

On Mon, Sep 23, 2013 at 12:56 PM, <Gabor.Bajko@nokia.com> wrote:

Vince,

This proposal of yours below could pote= ntially become very confusing. The message itself is named Available Spectrum Request, and you propose the Available Spectrum Respons= e to include a bunch of channels with unspecified power levels, which are b= tw, not available channels.

 So far, we have 4 proposed ways t= o indicate unavailable channels:

a) &nbs= p;    Not listing it, implicit unavailability

This has the drawback of not distinguishing between&nbs= p;being silent about a channel that is within the database's purview (channel off), and being silent about a channel that is outside the databa= se's purview (out of scope for given ruleset).

 

[DJ – Why should the database car= e about channels that are outside the scope of the ruleset specified by the radio? For example, if the specified ruleset is FCC-related, then w= hy would I need to include Ofcom-related channels in the response? Am I mis= sing something?]

 

The rules have strict adjacent channel = requirements.  Meeting the spectral mask for the adjacent channels &nb= sp;is one of the hardest parts for fielding real equipment.  If the rules allow relative measurement of the adjacent channel energy, you can s= imply lower your transmit power to the point that you can meet the adjacent= requirements.  

 

For a general White Spaces solution = 211; it is critical to have knowledge for the full spectrum mask.  The= full spectrum mask includes adjacent non-allowed channels.

 

RF channel usage are NOT a binary on/of= f or a simple transmit level.  The mask has a specific contour that ex= tends beyond the "allowed" channel.  Transmitters will alway= s send energy in more than the allowed channel!

 

 

 

Paul

 

 

 

b) &nbs= p;    List unavailable channels and specify the= power limit, eg -56dbm

Since the protocol should stand on its own, independent of any par= ticular regulatory rule, do we really want to rule this out? In our interpr= etations of the FCC rules, for example, a Database is not prevented from doing this.

 

[DJ – I’m still in favor of= just using the implicit unavailability method described above in a). What value is there in providing a power level for an unavailable channel?= If I’m the radio, I can’t use the channel, and I’m not g= oing to intentionally transmit in that channel. This comment also applies t= o c) and d).]

 

c) &nbs= p;     List unavailable channels and specify = 211;inf as power limit

 

"-Inf" is not really workable, because JSON does not all= ow Infinity or NaNs (http://tools.ietf.org/html/rfc4627), hence the d) proposal.

 

d) &nbs= p;    List unavailable channels and do not spec= ify any power limit 

 

So far, we have majority in favour of a= ), few people who could live or prefer c) and sort of consensus to strike out option b) from the list above.

 

We’ll wait for more input on the = list before declaring rough consensus for the question above; then we’ll go back to the original question on whether the encoding of sp= ectrum profile should be option 1 or option 2.

 

p.s. It looks to me, that if we want to= specify unavailable channels, we may need to modify the names of the paws messages to ‘Spectrum schedule’ or sg along these = lines.

 

-  = ;        Gabor

 

 

 


_______________________________________________
paws mailing list
paws@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/paws

 

--_000_1ECAFF543A2FED4EA2BEB6CACE08E47605364C49008AM1MPN1006mg_-- From peter@spectrumbridge.com Wed Sep 25 16:53:49 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A9FD11E80ED for ; Wed, 25 Sep 2013 16:53:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.041 X-Spam-Level: X-Spam-Status: No, score=-2.041 tagged_above=-999 required=5 tests=[AWL=0.557, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TssgrSHK5wNI for ; Wed, 25 Sep 2013 16:53:42 -0700 (PDT) Received: from mail.spectrumbridge.com (mail.spectrumbridge.com [64.132.248.82]) by ietfa.amsl.com (Postfix) with ESMTP id 3173321F9F01 for ; Wed, 25 Sep 2013 16:53:37 -0700 (PDT) Received: from shelby.sbi.com ([127.0.0.1]) by shelby ([127.0.0.1]) with mapi; Wed, 25 Sep 2013 19:53:35 -0400 From: Peter Stanforth To: "Harasty, Daniel J" , Vincent Chen Date: Wed, 25 Sep 2013 19:53:29 -0400 Thread-Topic: [paws] Spectrum encoding discussion Thread-Index: Ac66SnKT/H2tGDfiT56FF1O5GvzMeQ== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.7.130812 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CE68ECB0192F8peterspectrumbridgecom_" MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] Spectrum encoding discussion X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 23:53:52 -0000 --_000_CE68ECB0192F8peterspectrumbridgecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Dan, I understand your desire to be more specific about why, and when spectrum = may be available but I am struggling to understand why we can't do that tod= ay, and maybe that is why I missed the subtlety in your original post. We have a, per channel, start and stop time in spectrum availability (Sect= ions 5.10 and 5.11) and my understanding is that this would allow you to sa= y a channel is available from now until 6pm, or conversely it is not availa= ble until 6pm. Is this what you are trying to accomplish in your example b= elow? Part of your concern seems to be that if we use "off" that this may offer a= qualification like, you are not permitted to use it ever, you are just not= allowed to use it now, it is out of my domain. That may be good information to convey but are all of these examples still = relevant within the context of start and stop time =96 assuming I got it r= ight? As a side I have been wondering how relevant future is when Ofcom is propo= sing spectrum "leases" be for 15 minutes and the waiver just granted by the= FCC for a low power fixed device to use adjacent channels requires leases = of no more than 30 minutes. From: , Daniel J > Date: Wednesday, September 25, 2013 4:39 PM To: Vincent Chen >, Peter Stanfor= th > Cc: "paws@ietf.org" > Subject: RE: [paws] Spectrum encoding discussion As a Database provider, I think it is VERY IMPORTANT to have the ability to= state either of these unambiguously: =B7 These are the handful of channels that are available until 6pm. o (Implicitly: if you want to know about stuff after 6pm, send another re= quest between now and then =96 preferable closer to 6pm.) =B7 These are the handful of channels that are available until 6pm,= and I=92m telling you NOW that NOTHING is available starting at 6pm for th= e next 18 hours. o (Implicitly: I=92ve told you everything I can about all availability un= til Noon tomorrow; don=92t bother sending me another request until close to= Noon tomorrow.) This is close =96 but not exactly the same as Gabor=92s sentiment: This has the drawback of not distinguishing between being silent about a ch= annel that is within the database's purview (channel off), and being silent= about a channel that is outside the database's purview (out of scope for g= iven ruleset). In other words, sometimes the server is =93being silent=94 because =93certa= in frequencies are outside the database=92s purview=94. But another reason= to =93be silent=94 is that the database is only telling the Device about e= vents up to a certain time. This is the very concept I was trying to get at when I tried to formulate a= n example where =93being silent=94 (Gabor=92s term) or =93no mention=94 (my= term =96 same concept) confers =93no information=94. In my example, I was= NOT saying =93the Database has no information about the future=94; rather = I was giving and example where the message had =93no information=94 about u= se of the channel at some future time. (I apologize if I was not clear in = my point at that time.) >From a Device=92s perspective =96 there are really THREE states that a give= n channel might be in: a) I=92ve been told I can use it, b) I=92ve been told it is unavailable, c) I haven=92t been told either. I think we ALL agree: The device CAN=92T USE THE CHANNEL if it is in either case = =93b=94 or =93c=94 above. But the point I=92ve been trying to make is: The device NEED NOT ASK AGAIN if it knows that the channel = is in case =93a=94 or =93b=94 above. That is why case =93b=94 and =93c=94 are not synonymous. All along, that= =92s been my objection to =93no mention=94 being synonymous with the Databa= se declaring that a channel is =93is unavailable=94. And that=92s why I think it is important for the Database to have a way to = EXPLICTLY state a =93channel unavailable=94. If it is a weakness in PAWS = =96 with impact to the Database =96 if I can=92t express the difference be= tween =93b=94 and =93c=94. Dan Harasty From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of Vincent Chen Sent: Wednesday, September 25, 2013 12:10 PM To: Peter Stanforth Cc: paws@ietf.org Subject: Re: [paws] Spectrum encoding discussion Thanks for sharing your insights Peter. This is an opportunity to have the protocol be a bit more forward thinking = than what current regulators are thinking. Let's try to focus on Gabor's question again of how to express "unavailabil= ity", but phrasing it differently. If we were to take the view that the Database provides responses for freque= ncies where the device may operate, then - Any frequency ranges missing for the response means the device "is not g= ranted permission" to operate in those frequencies under the rules implemen= ted by the Database Then is it still useful to distinguish why permission is not granted? (off = vs outside band plan) If not, then Option a), simply having gaps in the frequency ranges would sa= tisfy this use case. Is this a good compromise? -vince On Wed, Sep 25, 2013 at 5:01 AM, Peter Stanforth > wrote: Lowering the power to meet the mask is the easy way you get a radio certif= ied =96 thus permission to operate. How is that anything to do with the dat= abase - which is simply managing Regulator policy? The ruleset is going to tell you what masks and other operating parameters = are acceptable within a regulatory domain. I can't imagine a Regulator allo= wing a database operator to manipulate the unintentional interference in ad= jacent channels. If it did why stop there? Why couldn't the database manipu= late co-channel interference to nearby protected entities? I thought we had a fairly elegant and simple solution. The ruleset defines = the box the device can operate in and the database provides a specific set = of permitted channels/frequencies within that box based on the location, ti= me, and type of device making the request. All with respect to the specific= list of entities the database has been told to protect at that location at= that time. One final comment and then I will rest my case. I have had conversations wi= th several Regulators about this recently, and they do not like any notion = that the database is "thinking" about the answer. In every case they have said something along the lines of "if the database = does not explicitly give a device permission to use a channel the device is= not allowed to use it". In every case they have gone somewhat further stating that if the database = operation goes beyond this simple approach they think it highly unlikely th= at they will get cooperation from incumbents. If you don't believe me =96 g= o ask them! Which brings me back to my soap box. We want to get PAWS done so we can ena= ble white space. In my humble opinion, the more time we spend pontificating= and the more complex we make it we are likely to achieve the opposite. Peter S. From: Paul Lambert > Date: Tuesday, September 24, 2013 2:48 PM To: Don Joslyn >, Vincent Chen >, "gabor.baj= ko@nokia.com" >, "paws@ietf.org" > Subject: Re: [paws] Spectrum encoding discussion In line below =85 speaking strongly in favor of "b" Gabor, I agree on possible renaming, if we want to specify unavailable channels. Please see comments inline. On Mon, Sep 23, 2013 at 12:56 PM, > wrote: Vince, This proposal of yours below could potentially become very confusing. The m= essage itself is named Available Spectrum Request, and you propose the Avai= lable Spectrum Response to include a bunch of channels with unspecified pow= er levels, which are btw, not available channels. So far, we have 4 proposed ways to indicate unavailable channels: a) Not listing it, implicit unavailability This has the drawback of not distinguishing between being silent about a ch= annel that is within the database's purview (channel off), and being silent= about a channel that is outside the database's purview (out of scope for g= iven ruleset). [DJ =96 Why should the database care about channels that are outside the sc= ope of the ruleset specified by the radio? For example, if the specified ru= leset is FCC-related, then why would I need to include Ofcom-related channe= ls in the response? Am I missing something?] The rules have strict adjacent channel requirements. Meeting the spectral = mask for the adjacent channels is one of the hardest parts for fielding re= al equipment. If the rules allow relative measurement of the adjacent chan= nel energy, you can simply lower your transmit power to the point that you = can meet the adjacent requirements. For a general White Spaces solution =96 it is critical to have knowledge fo= r the full spectrum mask. The full spectrum mask includes adjacent non-all= owed channels. RF channel usage are NOT a binary on/off or a simple transmit level. The m= ask has a specific contour that extends beyond the "allowed" channel. Tran= smitters will always send energy in more than the allowed channel! Paul b) List unavailable channels and specify the power limit, eg -56dbm Since the protocol should stand on its own, independent of any particular r= egulatory rule, do we really want to rule this out? In our interpretations = of the FCC rules, for example, a Database is not prevented from doing this. [DJ =96 I=92m still in favor of just using the implicit unavailability meth= od described above in a). What value is there in providing a power level fo= r an unavailable channel? If I=92m the radio, I can=92t use the channel, an= d I=92m not going to intentionally transmit in that channel. This comment a= lso applies to c) and d).] c) List unavailable channels and specify =96inf as power limit "-Inf" is not really workable, because JSON does not allow Infinity or NaNs= (http://tools.ietf.org/html/rfc4627), hence the d) proposal. d) List unavailable channels and do not specify any power limit So far, we have majority in favour of a), few people who could live or pref= er c) and sort of consensus to strike out option b) from the list above. We=92ll wait for more input on the list before declaring rough consensus fo= r the question above; then we=92ll go back to the original question on whet= her the encoding of spectrum profile should be option 1 or option 2. p.s. It looks to me, that if we want to specify unavailable channels, we ma= y need to modify the names of the paws messages to =91Spectrum schedule=92 = or sg along these lines. - Gabor -- -vince --_000_CE68ECB0192F8peterspectrumbridgecom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Dan,
 I understa= nd your desire to be more specific about why, and when spectrum may be avai= lable but I am struggling to understand why we can't do that today, and may= be that is why I missed the subtlety in your original post.
We ha= ve a, per channel, start and stop time in spectrum availability  (Sect= ions 5.10 and 5.11) and my understanding is that this would allow you to sa= y a channel is available from now until 6pm, or conversely it is not availa= ble until 6pm.  Is this what you are trying to accomplish in your exam= ple below?

Part of your concern seems to be that i= f we use "off" that this may offer a qualification like, you are = not permitted to use it ever, you are just not allowed to use it now, it is= out of my domain.
That may be good information to convey but are= all of these examples still relevant  within the context of start and= stop time =96 assuming I got it right? 

As a= side I have been wondering how relevant future  is when Ofcom is prop= osing spectrum "leases" be for 15 minutes and the waiver just gra= nted by the FCC for a low power fixed device to use adjacent channels requi= res leases of no more than 30 minutes.

From: <Harasty>, Daniel J <dharasty@appcomsci.com>
Date: Wednesday, September 25, 2013 4:39= PM
To: Vincent Chen <vchen@google.com>, Peter Stanforth <= ;peter@spectrumbridge.com&g= t;
Cc: "paws@ietf.org" <paws@ietf.org>
Subject: = RE: [paws] Spectrum encoding discussion

As a Database provider, I think it is VERY IMPORTANT to have the abi= lity to state either of these unambiguously:

= =B7         These are the handful = of channels that are available until 6pm.

o   (Implicitly: if you wa= nt to know about stuff after 6pm, send another request between now and then= =96 preferable closer to 6pm.)

=B7         These are the handful = of channels that are available until 6pm, and I=92m telling you NOW that NO= THING is available starting at 6pm for the next 18 hours.

o   (Implicitly: I=92ve to= ld you everything I can about all availability until Noon tomorrow; don=92t= bother sending me another request until close to Noon tomorrow.)

<= o:p> 

This is= close =96 but not exactly the same as Gabor=92s sentiment:

This has the drawback of not distinguishing between being silent about a channe= l that is within the database's purview (channel off), and being silent abo= ut a channel that is outside the database's purview (out of scope for given ruleset).

In other words, sometimes the server is =93be= ing silent=94 because =93certain frequencies are outside the database=92s p= urview=94.  But another reason to =93be silent=94 is that the database is only telling the Device about events up to a certa= in time.

 

This is th= e very concept I was trying to get at when I tried to formulate an example = where =93being silent=94 (Gabor=92s term) or =93no mention=94 (my term =96 = same concept) confers =93no information=94.  In my example, I was NOT saying =93the= Database has no information about the future=94; rather I was giving and e= xample where the message had =93no information=94 about use of the channel at some fu= ture time.  (I apologize if I was not clear in my point at that time.)=

 <= /o:p>

From a Device= =92s perspective =96 there are really THREE st= ates that a given channel might be in:

a) I=92ve been told I can use = it,

b) I=92ve been told it is unavailable,

c) I haven=92t been told either.

 

I think we ALL agree:

      &= nbsp;         The device CAN=92T US= E THE CHANNEL if it is in either case =93b=94 or =93c=94 above.<= /span>

 =

But the point I=92ve been tryi= ng to make is:

 

That is why case =93b=94 and =93c=94 are not synonymous.  All along, that=92s been my objection to =93no= mention=94 being synonymous with the Database declaring that a channel is = =93is unavailable=94. 

 <= /o:p>

And that=92s why I= think it is important for the Database to have a way to EXPLICTLY state a = =93channel unavailable=94.  If it is a weakness in PAWS =96 with impac= t to the Database =96  if I can=92t express the difference between =93b= =94 and =93c=94.

 

 

Dan Hara= sty

&nbs= p;

 

 

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Vincent Chen
Sent: Wednesday, September 25, 2= 013 12:10 PM
To: Peter Stanforth
Cc: paws@ietf.org
Subject: Re: [paws] Spectrum enc= oding discussion

&nb= sp;

Thanks for sharing your insights P= eter.

 

=

This is an opportunity to have the protocol be = a bit more forward thinking than what current regulators are thinking.=

 

Let's try to focus on Gabor's question again of how= to express "unavailability", but phrasing it differently.

 

<= p class=3D"MsoNormal">If we were to take the view that the Database provide= s responses for frequencies where the device may operate, then

 

 - Any frequency ranges missing for the response means= the device "is not granted permission" to operate in those frequ= encies under the rules implemented by the Database

 

Then is it still useful to distinguish why permission is not granted? (= off vs outside band plan)

<= o:p> 

If not, then Option a= ), simply having gaps in the frequency ranges would satisfy this use case.<= o:p>

 

=

Is this a good compromise?

=

 

-vince

 

= On Wed, Sep 25, 2013 at 5:01 AM, Peter Stanforth <peter@spectrumbridge.com> wr= ote:

 Lowering the power to = meet the mask is the easy way you get a radio certified =96 thus permission= to operate. How is that anything to do with the database - which is simply managing Regulator policy?

I thought we had a fairly elegant and simple solution. The rulese= t defines the box the device can operate in and the database provides a spe= cific set of permitted channels/frequencies within that box based on the location, time, and type of device making the= request. All with respect to the specific list of entities the database ha= s been told to protect at that location at that time.

=

 

One final comment and then I will rest my case. I have had conve= rsations with several Regulators about this recently, and they do not like = any notion that the database is "thinking" about the answer.

In every case they have said something along the lines of &q= uot;if the database does not explicitly give a device permission to use a c= hannel the device is not allowed to use it".

In every case = they have gone somewhat further stating that if the database operation goes= beyond this simple approach they think it highly unlikely that they will g= et cooperation from incumbents. If you don't believe me =96 go ask them!

Which brings me back to my soap box. We w= ant to get PAWS done so we can enable white space. In my humble opinion, th= e more time we spend pontificating and the more complex we make it we are likely to achieve the opposite.

Peter S.

 

&nb= sp;

From: Paul Lambert <= paul@marvell.com>
Date: Tuesday, September 24, 2013 2:48 P= M
To: Don Joslyn <d.joslyn@spectrumbridge.com>, Vincent Chen <= vchen@google.com&= gt;, "gabor= .bajko@nokia.com" <Gabor.Bajko= @nokia.com>, "paws@ietf.org" <paws@ietf.org>


<= b>Subject: Re: [paws] Spectrum encoding discussion

 

<= /div>

In line below =85 speaking strongly= in favor of "b" 

 

&nb= sp;

Gabor,

 <= o:p>

I agree on possible renaming, if we want = to specify unavailable channels.

 

Please see comments inline. 

 

On Mon, Sep 23= , 2013 at 12:56 PM, <Gabor.Bajko@nokia.com> wrote:

Vince,

This proposal of yours below could potentially become very confusing. The = message itself is named Available Spectrum Request, and you propose the Available Spectrum Respons= e to include a bunch of channels with unspecified power levels, which are b= tw, not available channels.

 So far, we have 4 pr= oposed ways to indicate unavailable channels:

a)      Not listing it, implicit unavailability

This has the drawback of not disting= uishing between being silent about a channel that is within the database's purv= iew (channel off), and being silent about a channel that is outside the databa= se's purview (out of scope for given ruleset).

 

= [DJ =96 Why should the database care about channels that are outside the sc= ope of the ruleset specified by the radio? For example, if the specified ruleset is FCC-related, then w= hy would I need to include Ofcom-related channels in the response? Am I mis= sing something?]

<= /div>

 

=

The rules have strict adjacent channel requirements.=  Meeting the spectral mask for the adjacent channels  is one of = the hardest parts for fielding real equipment.  If the rules allow relative measurement of the adjacent channel energy, you can s= imply lower your transmit power to the point that you can meet the adjacent= requirements.  

 

For a general White S= paces solution =96 it is critical to have knowledge for the full spectrum m= ask.  The full spectrum mask includes adjacent non-allowed channels.

 

RF channel usage are NOT a binary on/off or = a simple transmit level.  The mask has a specific contour that extends= beyond the "allowed" channel.  Transmitters will always send energy in more than the allowed channel!

<= div>

 

 

 

Paul

=

 

 

 

b)      List unavailable channels and specify the power li= mit, eg -56dbm

Since the protocol should stand on its own, independent of any particular= regulatory rule, do we really want to rule this out? In our interpretation= s of the FCC rules, for example, a Database is not prevented from doing this.

 

[DJ =96 = I=92m still in favor of just using the implicit unavailability method descr= ibed above in a). What value is there in providing a power level for an unavailable channel?= If I=92m the radio, I can=92t use the channel, and I=92m not going to inte= ntionally transmit in that channel. This comment also applies to c) and d).= ]

 

c) &nb= sp;     List unavailable channels and specify =96inf as po= wer limit

&nb= sp;

"-Inf" is not really workab= le, because JSON does not allow Infinity or NaNs (http://tools.ietf.org/html/rfc4627<= /a>), hence the d) proposal.

 

So far, we have majority in favour of a), few people w= ho could live or prefer c) and sort of consensus to strike out option b) from the list above.

 

W= e=92ll wait for more input on the list before declaring rough consensus for= the question above; then we=92ll go back to the original question on whether the encoding of spectr= um profile should be option 1 or option 2.

 

p.s.= It looks to me, that if we want to specify unavailable channels, we may ne= ed to modify the names of the paws messages to =91Spectrum schedule=92 or sg along these lines.

 

=

-     = ;     Gabor

 

=



--_000_CE68ECB0192F8peterspectrumbridgecom_-- From tvfool@google.com Wed Sep 25 18:08:57 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02D7721F9AA2 for ; Wed, 25 Sep 2013 18:08:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.441 X-Spam-Level: X-Spam-Status: No, score=-1.441 tagged_above=-999 required=5 tests=[AWL=0.536, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jRQ-wFYF2oKJ for ; Wed, 25 Sep 2013 18:08:55 -0700 (PDT) Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 4F2EE21F9BD5 for ; Wed, 25 Sep 2013 18:08:51 -0700 (PDT) Received: by mail-ob0-f182.google.com with SMTP id wo20so1021021obc.41 for ; Wed, 25 Sep 2013 18:08:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9SkPb19a1KVLjmZWU4tZkrZNi8LoCfMdwrhT3aAkSqE=; b=Rbj1BeEUc8WWlWI37d6CAoAdU3uavmpZb2QyoAN30smAWOhrwsWGH5DIbrsg6emUSj CIc7I5Am5wH/g+0GoQq9QuZVJjbI6Mm8KQvVCYN7z1DG/KWnbW6PsbovTrM5xMEXa/NP wePcioG0txAtDKuygRfNhNg86C273nPYouX9p0Fh96sYEiTXoXDwgNXptuoBOc5dqS4V JWAfS36wPcgiBzg3LJlvw/ySnx2rNBWU9i0kYTxtz8hS/v0E4V5VfYPD5HKvbq/HmP8R 4FqYGsm2F9jpSBWrFDZO3II9h9NSKKGsGgyzQFVr/dQrhrExA88C3c5rQw3FWgmdBgtV xXsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=9SkPb19a1KVLjmZWU4tZkrZNi8LoCfMdwrhT3aAkSqE=; b=j+VRmb4LXgwWX6K9ASCuuDLzP2jHy3lPBC3/RVK4+L/Ud5z4gadMciczQDvagpN/Qp TIJ5XmPx5gEZ0E6vw2pzzJUTqJUGkAtcBL9Yn73WREC1T8gIZv4NrYPVtZFSrq1V5SeR kTSkElHIpFn0M3bBVS8/YmzgsGLJ7FF5zAqd10yswg5ceCTk3z6UiqUHaNUguEvw6AFp 5/ijOtUSkVaOVGOUcbon0fIXzRLq4Bp7+l6++RJeV10/yTQKhrX96CyokrID2bjP0/9I CF4Gl/2DGWdewuMWZWPTx2JRf9/v7GdKu2N0tBmtqkEAcMpDc8wJJnF8Hi0iVbevPbns +raA== X-Gm-Message-State: ALoCoQnPGMV7s3wkWIYVo57w46x/0VrHbtfQsv97XIpvPfpiBq2oYoEYjbUO3iTk2jwB8aFjC4dzdSnO3r1IZ2B1DS4fdAtVc3NwAjyGMFUwvcp+myE+pDjYf013iTAOrVEagGfWtB65yPyoadl6a9yFIWpAvljA55MyuTnCVbxdRjHxVSH8OdsU/VffNseP9ije9JpkjzwG MIME-Version: 1.0 X-Received: by 10.60.52.81 with SMTP id r17mr33304231oeo.3.1380157729723; Wed, 25 Sep 2013 18:08:49 -0700 (PDT) Received: by 10.182.142.196 with HTTP; Wed, 25 Sep 2013 18:08:49 -0700 (PDT) In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E47605364C49@008-AM1MPN1-006.mgdnok.nokia.com> References: <1ECAFF543A2FED4EA2BEB6CACE08E47605364C49@008-AM1MPN1-006.mgdnok.nokia.com> Date: Wed, 25 Sep 2013 18:08:49 -0700 Message-ID: From: Andy Lee To: "Gabor.Bajko@nokia.com" Content-Type: multipart/alternative; boundary=001a1133073a37a46804e73f0355 Cc: Protocol to Access White Space database Subject: Re: [paws] Spectrum encoding discussion X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2013 01:08:57 -0000 --001a1133073a37a46804e73f0355 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Gabor, Thanks for the suggestion. Just to be clear, the encoding of information about the "off" channels is * OPTIONAL*. The current FCC rules give specific values for what should happen on the "special" channel 37 as well as "off" channels in the TV band, but the rules do not require the databases to send those details to the device as part of the spectrum query. If one assumes that a WSD has implicit knowledge of these "off" channel rules, then there's no need for a database to send this information. *IF* the database decides to include this information in its message, then I think it makes the most sense to include the information directly in the spectrum profile itself. Many of these special rules for channel 37 or band edges are unique to the frequencies where they apply. It seems like a very natural fit to simply encode the data with the spectrum profile in the frequency context where they belong. I think it would be difficult to encode these things with the ruleset part of the message because there can be different behaviors unique to each frequency or band edge. I can't think of a good way to generically encode this with the ruleset. Best regards, Andy Lee | Google Inc. | tvfool@google.com | 408-230-0522 On Wed, Sep 25, 2013 at 3:56 PM, wrote: > Andy,**** > > ** ** > > This option (e) proposal sounds like you may want to encode two things > which could be separated; the available channels, and the authoritative > bands.**** > > We could leave the available spectrum req/resp unchanged, and eg have a > separate req/resp for the authoritative bands. **** > > And we could also encode the power leakage limits eg inside the ruleset > info, so that devices would not necessarily need to be hard-coded with > those, to satisfy everyone.**** > > Could this be an agreeable way forward?**** > > ** ** > > **- **Gabor**** > > ** ** > > *From:* ext Andy Lee [mailto:tvfool@google.com] > *Sent:* Wednesday, September 25, 2013 1:57 PM > *To:* Peter Stanforth > *Cc:* Paul Lambert; Vincent Chen; Bajko Gabor (Nokia-CIC/SiliconValley); > paws@ietf.org > > *Subject:* Re: [paws] Spectrum encoding discussion**** > > ** ** > > Hi Peter,**** > > **** > > I can't imagine a Regulator allowing a database operator to manipulate th= e > unintentional interference in adjacent channels. If it did why stop there= ? > Why couldn't the database manipulate co-channel interference to nearby > protected entities?**** > > ** ** > > The recent discussions have been about data encoding and nothing more. > The premise is that *IF* there is some information the database wants to > communicate to the white space device, *HOW* is that data encoded into > the message.**** > > ** ** > > As a case in point, section 15.709(c)(1) of the rules clearly defines wha= t > the "off" channel power limits must be. The rules originally called for = a > "relative" OOB emission limit, but after some industry discussion, the FC= C > settled on these "absolute" OOB emission limits instead. The values are > clearly defined, but its not clear whether a database would want to > communicate these parameters to the device or not.**** > > ** ** > > On one hand, the database can assume that the device has these values > hard-coded into its firmware and therefore does not need to send that > information over PAWS.**** > > ** ** > > On the other hand, these power levels are part of the TVWS rules and > perhaps is something that the database should communicate to the WSD. > There are potentially beneficial things that a WSD could do with that > information if it was provided at run-time (e.g., for future-proofing the > device, or choosing operating channels more intelligently).**** > > ** ** > > ** ** > > ** ** > > ** ** > > ** ** > > *PAWS does not need to address WHY a particular parameter should or > should not be sent over the protocol.* There are many regulatory, > business, or technological reasons why these choices might change, and > those decisions are beyond the scope of the protocol itself.**** > > ** ** > > However, *PAWS can and should address HOW data gets encoded IF a device > or database decides to send it.* i.e.,**** > > ** ** > > IF you want to encode [X], then you SHALL use [encoding X]**** > > IF you want to encode [Y], then you SHALL use [encoding Y]**** > > etc.**** > > ** ** > > I can identify at least three distinct concepts that have been discussed > so far, which I would categorize as follows:**** > > - (i) Explicit "on", Implicit "off"**** > > > - Anything not explicitly specified as "on" would implicitly be > treated as "off"**** > - The recipient must have apriori knowledge about how to comply > with the "off" channel, "special" channel (e.g., channel 37), and > "band-edge" protection ratios**** > - There is no distinction between "off" channels, "special" > channels, and "band-edge" constraints in the message itself**** > - This requires a way to encode gaps or discontinuities in the > spectrum profile**** > - This is equivalent to Gabor's option (a)**** > > ** ** > > - (ii) Explicit "on", Explicit "off" with no power level given**** > > > - Every channel would be either explicitly "on" or explicitly "off"**= * > * > - Any frequency blocks that are not explicitly "on" or explicitly > "off" are considered to be "out-of-scope" for the current database = or > ruleset, and this implicitly gives the "band-edge" boundaries**** > - The recipient must have apriori knowledge about how to comply > with the "off" channel, "special" channel, and "band-edge" protecti= on ratios > **** > - The recipient can infer from the message when to apply "off" > channel constraints and when to apply "band-edge" constraints**** > - This requires a way to encode gaps or discontinuities in the > spectrum profile AND requires a way to encode explicit "off" channe= ls with > no specified power value**** > - This is equivalent to Gabor's options (c) and (d)**** > > ** ** > > - (iii) Explicit "on", Explicit "off" with power level given**** > > > - Every channel would be either explicitly "on" or explicitly "off"**= * > * > - Any frequency blocks that are not explicitly "on" or explicitly > "off" are considered to be "out-of-scope" for the current database = or > ruleset, and this implicitly gives the "band-edge" boundaries**** > - The "off" channel, "special" channel, and "band-edge" protection > ratios are explicitly provided in the message, and a device has the= option > of either using that information or ignoring it (default back to ap= riori > knowledge of the protection ratios)**** > - This requires a way to encode gaps or discontinuities in the > spectrum profile**** > - This is equivalent to Gabor's option (b)**** > > ** ** > > ** ** > > I think all three types of encoding have their uses, and PAWS should > probably allow all three possibilities.**** > > ** ** > > It looks like all three encoding types need a way to express gaps or > discontinuities in the spectrum profile. I think the latest proposal fro= m > Vince, using a list of lists, addresses this problem nicely.**** > > ** ** > > It also looks like encodings for (i) and (iii) are logically equivalent, > with the only real difference being that encoding (iii) includes more dat= a > points in the spectrum profile than encoding (i). I don't think anything > else needs to be added to the spec to support both of these encodings.***= * > > ** ** > > ** ** > > ** ** > > That leaves us with encoding (ii), where we need to add something new to > the spec to encode explicitly "off" frequency blocks that have no power > level given. For this, we have two proposals:**** > > ** ** > > Option (c): Use -inf as the power value in a spectrum profile element**** > > Option (d): Leave the power value blank in a spectrum profile element**** > > ** ** > > I'd suggest maybe considering yet another proposal:**** > > ** ** > > Option (e): Use normal encoding (i) for explicit "on" channels, and then > have a separate list of frequency start/stop pairs indicating the > authoritative bands for which the database operates. Anything that is > inside the authoritative bands but not in an explicitly "on" chunk is > effectively saying it's explicitly "off". Anything outside of the list o= f > authoritative bands is considered "out-of-scope" for the database and thi= s > essentially lists the "band-edge" boundaries.**** > > ** ** > > ** ** > > ** ** > > Best regards,**** > > > **** > > ** ** > > Andy Lee |**** > > Google Inc. |**** > > tvfool@google.com |**** > > 408-230-0522**** > > ** ** > > On Wed, Sep 25, 2013 at 5:01 AM, Peter Stanforth > wrote:**** > > Lowering the power to meet the mask is the easy way you get a radio > certified =96 thus permission to operate. How is that anything to do with= the > database - which is simply managing Regulator policy?**** > > The ruleset is going to tell you what masks and other operating parameter= s > are acceptable within a regulatory domain. I can't imagine a Regulator > allowing a database operator to manipulate the unintentional interference > in adjacent channels. If it did why stop there? Why couldn't the database > manipulate co-channel interference to nearby protected entities?**** > > I thought we had a fairly elegant and simple solution. The ruleset define= s > the box the device can operate in and the database provides a specific se= t > of permitted channels/frequencies within that box based on the location, > time, and type of device making the request. All with respect to the > specific list of entities the database has been told to protect at that > location at that time.**** > > ** ** > > One final comment and then I will rest my case. I have had conversations > with several Regulators about this recently, and they do not like any > notion that the database is "thinking" about the answer.**** > > In every case they have said something along the lines of "if the databas= e > does not explicitly give a device permission to use a channel the device = is > not allowed to use it".**** > > In every case they have gone somewhat further stating that if the databas= e > operation goes beyond this simple approach they think it highly unlikely > that they will get cooperation from incumbents. If you don't believe me = =96 > go ask them!**** > > Which brings me back to my soap box. We want to get PAWS done so we can > enable white space. In my humble opinion, the more time we spend > pontificating and the more complex we make it we are likely to achieve th= e > opposite.**** > > Peter S.**** > > ** ** > > ** ** > > *From: *Paul Lambert > *Date: *Tuesday, September 24, 2013 2:48 PM > *To: *Don Joslyn , Vincent Chen < > vchen@google.com>, "gabor.bajko@nokia.com" , " > paws@ietf.org" **** > > > *Subject: *Re: [paws] Spectrum encoding discussion**** > > ** ** > > In line below =85 speaking strongly in favor of "b" **** > > ** ** > > ** ** > > Gabor,**** > > **** > > I agree on possible renaming, if we want to specify unavailable channels.= * > *** > > **** > > Please see comments inline. **** > > **** > > On Mon, Sep 23, 2013 at 12:56 PM, wrote:**** > > Vince,**** > > This proposal of yours below could potentially become very confusing. The > message itself is named Available Spectrum Request, and you propose the > Available Spectrum Response to include a bunch of channels with unspecifi= ed > power levels, which are btw, not available channels. **** > > So far, we have 4 proposed ways to indicate unavailable channels:**** > > a) Not listing it, implicit unavailability**** > > This has the drawback of not distinguishing between being silent about a > channel that is within the database's purview (channel off), and being > silent about a channel that is outside the database's purview (out of sco= pe > for given ruleset).**** > > **** > > [DJ =96 Why should the database care about channels that are outside the > scope of the ruleset specified by the radio? For example, if the specifie= d > ruleset is FCC-related, then why would I need to include Ofcom-related > channels in the response? Am I missing something?]**** > > ** ** > > The rules have strict adjacent channel requirements. Meeting the spectra= l > mask for the adjacent channels is one of the hardest parts for fielding > real equipment. If the rules allow relative measurement of the adjacent > channel energy, you can simply lower your transmit power to the point tha= t > you can meet the adjacent requirements. **** > > ** ** > > For a general White Spaces solution =96 it is critical to have knowledge = for > the full spectrum mask. The full spectrum mask includes adjacent > non-allowed channels.**** > > ** ** > > RF channel usage are NOT a binary on/off or a simple transmit level. The > mask has a specific contour that extends beyond the "allowed" channel. > Transmitters will always send energy in more than the allowed channel!**= * > * > > ** ** > > ** ** > > ** ** > > Paul**** > > ** ** > > ** ** > > **** > > b) List unavailable channels and specify the power limit, eg -56dbm= * > *** > > Since the protocol should stand on its own, independent of any > particular regulatory rule, do we really want to rule this out? In our > interpretations of the FCC rules, for example, a Database is not prevente= d > from doing this.**** > > **** > > [DJ =96 I=92m still in favor of just using the implicit unavailability me= thod > described above in a). What value is there in providing a power level for > an unavailable channel? If I=92m the radio, I can=92t use the channel, an= d I=92m > not going to intentionally transmit in that channel. This comment also > applies to c) and d).]**** > > **** > > c) List unavailable channels and specify =96inf as power limit**** > > **** > > "-Inf" is not really workable, because JSON does not allow Infinity or > NaNs (http://tools.ietf.org/html/rfc4627), hence the d) proposal.**** > > **** > > d) List unavailable channels and do not specify any power limit ***= * > > **** > > So far, we have majority in favour of a), few people who could live or > prefer c) and sort of consensus to strike out option b) from the list abo= ve. > **** > > **** > > We=92ll wait for more input on the list before declaring rough consensus = for > the question above; then we=92ll go back to the original question on whet= her > the encoding of spectrum profile should be option 1 or option 2.**** > > **** > > p.s. It looks to me, that if we want to specify unavailable channels, we > may need to modify the names of the paws messages to =91Spectrum schedule= =92 or > sg along these lines.**** > > **** > > - Gabor**** > > **** > > ** ** > > ** ** > > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws**** > > ** ** > --001a1133073a37a46804e73f0355 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi Gabor,

Thanks for the suggestion.

Just to be clear, the encoding of information about = the "off" channels is OPTIONAL. =A0The current FCC rules g= ive specific values for what should happen on the "special" chann= el 37 as well as "off" channels in the TV band, but the rules do = not require the databases to send those details to the device as part of th= e spectrum query. =A0If one assumes that a WSD has implicit knowledge of th= ese "off" channel rules, then there's no need for a database = to send this information.

IF the database decides to include this informat= ion in its message, then I think it makes the most sense to include the inf= ormation directly in the spectrum profile itself. =A0Many of these special = rules for channel 37 or band edges are unique to the frequencies where they= apply. =A0It seems like a very natural fit to simply encode the data with = the spectrum profile in the frequency context where they belong.

I think it would be difficult to encode these things wi= th the ruleset part of the message because there can be different behaviors= unique to each frequency or band edge. =A0I can't think of a good way = to generically encode this with the ruleset.

Best regards,

Andy Lee=A0|=A0Google Inc= . | =A0tvfool@google.com=A0| =A0408-230-0522


On Wed, Sep 25, 2013 at 3:56 PM, <= Gabor.Bajko@nokia.com> wrote:

Andy,

=A0

This option (e) proposal sounds like you may want to = encode two things which could be separated; the available channels, and the= authoritative bands.

We could leave the available spectrum req/resp unchan= ged, and eg have a separate req/resp for the authoritative bands.

And we could also encode the power leakage limits eg = inside the ruleset info, so that devices would not necessarily need to be h= ard-coded with those, to satisfy everyone.

Could this be an agreeable way forward?=

=A0

-=A0=A0=A0=A0=A0=A0=A0=A0=A0 Gabor

=A0

From: ext Andy Lee [mailto:tvfool@google.com]
Sent: Wednesday, September 25, 2013 1:57 PM
To: Peter Stanforth
Cc: Paul Lambert; Vincent Chen; Bajko Gabor (Nokia-CIC/SiliconValley= ); paws@ietf.org


Subject: Re: [paws] Spectrum encoding discussion
=

=A0

Hi Peter,

=A0

I can't imagine a Regulator allowing a database operator to manipula= te the unintentional interference in adjacent channels. If it did why stop = there? Why couldn't the database manipulate co-channel interference to nearby protected entities?=

=A0

The recent discussions have been about data encoding and noth= ing more. =A0The premise is that IF there is some information the database wants to communicate to th= e white space device, HOW is that data encoded into the message.

=A0

As a case in point, section 15.709(c)(1) of the rules clearly= defines what the "off" channel power limits must be. =A0The rule= s originally called for a "relative" OOB emission limit, but afte= r some industry discussion, the FCC settled on these "absolute" OOB emission limits instead. =A0The values are = clearly defined, but its not clear whether a database would want to communi= cate these parameters to the device or not.

=A0

On one hand, the database can assume that the device has thes= e values hard-coded into its firmware and therefore does not need to send t= hat information over PAWS.

=A0

On the other hand, these power levels are part of the TVWS ru= les and perhaps is something that the database should communicate to the WS= D. =A0There are potentially beneficial things that a WSD could do with that= information if it was provided at run-time (e.g., for future-proofing the device, or choosing operating c= hannels more intelligently).

=A0

=A0

=A0

=A0

=A0

PAWS does not need to address WHY a particular parameter s= hould or should not be sent over the protocol.=A0 There are many regula= tory, business, or technological reasons why these choices might change, an= d those decisions are beyond the scope of the protocol itself.

=A0

However, PAWS can and should address HOW data gets encoded= IF a device or database decides to send it. =A0i.e.,

=A0

IF you want to encode [X], then you SHALL use [encoding X]=

IF you want to encode [Y], then you SHALL use [encoding Y]=

etc.

=A0

I can identify at least three distinct concepts that have bee= n discussed so far, which I would categorize as follows:

  • (i) Explicit "on", Implicit "off"
      • Anything not explicitly specified as "on" would implicitly be tre= ated as "off"
      • The recipient must have apriori knowledge about how to comply with the &quo= t;off" channel, "special" channel (e.g., channel 37), and &q= uot;band-edge" protection ratios
      • There is no distinction between "off" channels, "special&quo= t; channels, and "band-edge" constraints in the message itself=
      • This requires a way to encode gaps or discontinuities in the spectrum profi= le
      • This is equivalent to Gabor's option (a)

    =A0

    • (ii)=A0Explicit "on",=A0Explicit "off" with no power le= vel given
      • Every channel would be either explicitly "on" or explicitly "= ;off"
      • Any frequency blocks that are not explicitly "on" or explicitly &= quot;off" are considered to be "out-of-scope" for the curren= t database or ruleset, and this implicitly gives the "band-edge" = boundaries
      • The recipient must have apriori knowledge about how to comply with the &quo= t;off" channel, "special" channel, and "band-edge"= protection ratios
      • The recipient can infer from the message when to apply "off" chan= nel constraints and when to apply "band-edge" constraints<= u>
      • This requires a way to encode gaps or discontinuities in the spectrum profi= le AND requires a way to encode explicit "off" channels with no s= pecified power value
      • This is equivalent to Gabor's options (c) and (d)

      =A0

      • (iii)=A0Explicit "on",=A0Explicit "off" with power leve= l given
        • Every channel would be either explicitly "on" or explicitly "= ;off"
        • Any frequency blocks that are not explicitly "on" or explicitly &= quot;off" are considered to be "out-of-scope" for the curren= t database or ruleset, and this implicitly gives the "band-edge" = boundaries
        • The "off" channel, "special" channel, and "band-ed= ge" protection ratios are explicitly provided in the message, and a de= vice has the option of either using that information or ignoring it (defaul= t back to apriori knowledge of the protection ratios)
        • This requires a way to encode gaps or discontinuities in the spectrum profi= le
        • This is equivalent to Gabor's option (b)

=A0

=A0

I think all three types of encoding have their uses, and PAWS= should probably allow all three possibilities.

=A0

It looks like all three encoding types need a way to express = gaps or discontinuities in the spectrum profile. =A0I think the latest prop= osal from Vince, using a list of lists, addresses this problem nicely.

=A0

It also looks like encodings for (i) and (iii) are logically = equivalent, with the only real difference being that encoding (iii) include= s more data points in the spectrum profile than encoding (i). =A0I don'= t think anything else needs to be added to the spec to support both of these encodings.

=A0

=A0

=A0

That leaves us with encoding (ii), where we need to add somet= hing new to the spec to encode explicitly "off" frequency blocks = that have no power level given. =A0For this, we have two proposals:<= u>

=A0

Option (c): Use -inf as the power value in a spectrum profile= element

Option (d): Leave the power value blank in a spectrum profile= element

=A0

I'd suggest maybe considering yet another proposal:

=A0

Option (e): Use normal encoding (i) for explicit "on&quo= t; channels, and then have a separate list of frequency start/stop pairs in= dicating the authoritative bands for which the database operates. =A0Anythi= ng that is inside the authoritative bands but not in an explicitly "on" chunk is effectively saying it'= ;s explicitly "off". =A0Anything outside of the list of authorita= tive bands is considered "out-of-scope" for the database and this= essentially lists the "band-edge" boundaries.

=A0

=A0

=A0

Best regards,


=A0

Andy Lee=A0|

=A0Google Inc. |

=A0tvfool@google= .com=A0|

=A0408-230-0522

=A0

On Wed, Sep 25, 2013 at 5:01 AM, Peter Stanforth <peter@spectrumbridge= .com> wrote:

=A0Lowering the power to meet the mask is the easy way you get a radio c= ertified =96 thus permission to operate. How is that anything to do with th= e database - which is simply managing Regulator policy?

The ruleset is going to tell you what masks and other operating paramete= rs are acceptable within a regulatory domain. I can't imagine a Regulat= or allowing a database operator to manipulate the unintentional interference in adjacent channels. If it d= id why stop there? Why couldn't the database manipulate co-channel inte= rference to nearby protected entities?

I thought we had a fairly elegant and simple solution. The ruleset defin= es the box the device can operate in and the database provides a specific s= et of permitted channels/frequencies within that box based on the location, time, and type of device making the= request. All with respect to the specific list of entities the database ha= s been told to protect at that location at that time.<= /p>

=A0

One final comment and then I will rest my case. I have had conversations= with several Regulators about this recently, and they do not like any noti= on that the database is "thinking" about the answer.

In every case they have said something along the lines of "if the d= atabase does not explicitly give a device permission to use a channel the d= evice is not allowed to use it".

In every case they have gone somewhat further stating that if the databa= se operation goes beyond this simple approach they think it highly unlikely= that they will get cooperation from incumbents. If you don't believe me =96 go ask them!

Which brings me back to my soap box. We want to get PAWS done so we can = enable white space. In my humble opinion, the more time we spend pontificat= ing and the more complex we make it we are likely to achieve the opposite.

Peter S.

=A0

=A0

From: Pa= ul Lambert <paul@m= arvell.com>
Date: Tuesday, September 24, 2013 2:48 PM
To: Don Joslyn <d.joslyn@spectrumbridge.com>, Vincent Chen <vchen@google.com>, = "gabor.bajk= o@nokia.com" <Gabor.Bajko= @nokia.com>, "paws@ietf.org" <paws@ietf.org>


Subject: Re: [paws] Spectrum encoding discussion

=A0

In line below =85 speaking strongly in favor of "b"=A0=

=A0

=A0

Gabor,

=A0

I agree on possible renaming, if we want to specify unavailab= le channels.

=A0

Please see comments inline.=A0

=A0

On Mon, Sep 23, 2013 at 12:56 PM, <Gabor.Bajko@nokia.com> wrote:=

Vince,

This proposal of yours below could potentially become= very confusing. The message itself is named Available Spectrum Request, and you propose the Available Spectrum Respons= e to include a bunch of channels with unspecified power levels, which are b= tw, not available channels.

=A0So far, we have 4 proposed ways to indicate unavai= lable channels:

a)=A0=A0=A0=A0=A0 Not listing it, implicit unavailability

This has the drawback of not distinguishing between=A0being silent about a c= hannel that is within the database's purview (channel off), and being silent about a channel that is outside the databa= se's purview (out of scope for given ruleset).

=A0

[DJ =96 Why should the database care about channels t= hat are outside the scope of the ruleset specified by the radio? For example, if the specified ruleset is FCC-related, then w= hy would I need to include Ofcom-related channels in the response? Am I mis= sing something?]

=A0

The rules have strict adjacent channel requirements. =A0Meeting the spec= tral mask for the adjacent channels =A0is one of the hardest parts for fiel= ding real equipment. =A0If the rules allow relative measurement of the adjacent channel energy, you can s= imply lower your transmit power to the point that you can meet the adjacent= requirements. =A0

=A0

For a general White Spaces solution =96 it is critical to have knowledge= for the full spectrum mask. =A0The full spectrum mask includes adjacent no= n-allowed channels.

=A0

RF channel usage are NOT a binary on/off or a simple transmit level. =A0= The mask has a specific contour that extends beyond the "allowed"= channel. =A0Transmitters will always send energy in more than the allowed channel!

=A0

=A0

=A0

Paul

=A0

=A0

=A0

b)=A0=A0=A0=A0=A0 List unavailable channels and specify the power limit, eg -5= 6dbm=

Since the protocol should stand on its own, independent of an= y particular regulatory rule, do we really want to rule this out? In our in= terpretations of the FCC rules, for example, a Database is not prevented from doing this.

=A0

[DJ =96 I=92m still in favor of just using the implic= it unavailability method described above in a). What value is there in providing a power level for an unavailable channel?= If I=92m the radio, I can=92t use the channel, and I=92m not going to inte= ntionally transmit in that channel. This comment also applies to c) and d).= ]

=A0

c)=A0=A0=A0=A0=A0=A0 List unavailable channels and specify =96inf as power limit<= /span>

=A0

"-Inf" is not really workable, because JSON does no= t allow Infinity or NaNs (http://tools.ietf.org/html/rfc4627), hence the d) proposal.

=A0

d)=A0=A0=A0=A0=A0 List unavailable channels and do not specify any power limit= =A0<= u>

=A0

So far, we have majority in favour of a), few people = who could live or prefer c) and sort of consensus to strike out option b) from the list above.

=A0

We=92ll wait for more input on the list before declar= ing rough consensus for the question above; then we=92ll go back to the original question on whether the encoding of spectr= um profile should be option 1 or option 2.

=A0

p.s. It looks to me, that if we want to specify unava= ilable channels, we may need to modify the names of the paws messages to =91Spectrum schedule=92 or sg along these lines.

=A0

-=A0=A0=A0=A0=A0=A0=A0=A0=A0 Gabor

=A0

=A0

=A0


_______________________________________________
paws mailing list
paws@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/paws

=A0


--001a1133073a37a46804e73f0355-- From jstine@mitre.org Thu Sep 26 03:15:04 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9057F11E818A for ; Thu, 26 Sep 2013 03:15:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X4h8KkOHMV2r for ; Thu, 26 Sep 2013 03:14:55 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 160E211E818C for ; Thu, 26 Sep 2013 03:14:54 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 5C1352260164; Thu, 26 Sep 2013 06:14:53 -0400 (EDT) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 12A642260161; Thu, 26 Sep 2013 06:14:53 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.97]) by IMCCAS01.MITRE.ORG ([129.83.29.68]) with mapi id 14.03.0158.001; Thu, 26 Sep 2013 06:14:52 -0400 From: "Stine, John A." To: "Gabor.Bajko@nokia.com" , "tvfool@google.com" , "peter@spectrumbridge.com" Thread-Topic: [paws] Spectrum encoding discussion Thread-Index: AQHOujG+P/HLGDjFz0KsZ4ADL3ZozZnXU5uAgAB118A= Date: Thu, 26 Sep 2013 10:14:51 +0000 Message-ID: <2782C93FD2244441893673F3F912819226D27F2C@IMCMBX01.MITRE.ORG> References: <1ECAFF543A2FED4EA2BEB6CACE08E47605364C49@008-AM1MPN1-006.mgdnok.nokia.com> In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E47605364C49@008-AM1MPN1-006.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.56] Content-Type: multipart/alternative; boundary="_000_2782C93FD2244441893673F3F912819226D27F2CIMCMBX01MITREOR_" MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] Spectrum encoding discussion X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2013 10:15:04 -0000 --_000_2782C93FD2244441893673F3F912819226D27F2CIMCMBX01MITREOR_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable For what it is worth I have been working on methods to model spectrum use t= hat can be used to give guidance to radios. (We have just started to standa= rdize these methods in IEEE 1900.5.2.) We have two different kinds of guid= ance, permissive and restrictive. They are sent in separate lists. The pe= rmissive (aka authorization) list identifies channels a device or system ca= n operate and if combined with a restrictive (aka constraint) list then so = long as the user does not violate a listed restriction. Each of these list= s use spectrum and time at two levels. The top level indicates the band an= d time period the list is comprehensive. The second level indicates the pa= rticular channels and time periods of availability or restriction. I would= imagine that TVWS would only need the authorization list. Future applicat= ions where spectrum owners add spectrum to the database and coexistence is = managed will require both. John From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Gab= or.Bajko@nokia.com Sent: Wednesday, September 25, 2013 6:56 PM To: tvfool@google.com; peter@spectrumbridge.com Cc: paws@ietf.org Subject: Re: [paws] Spectrum encoding discussion Andy, This option (e) proposal sounds like you may want to encode two things whic= h could be separated; the available channels, and the authoritative bands. We could leave the available spectrum req/resp unchanged, and eg have a sep= arate req/resp for the authoritative bands. And we could also encode the power leakage limits eg inside the ruleset inf= o, so that devices would not necessarily need to be hard-coded with those, = to satisfy everyone. Could this be an agreeable way forward? - Gabor From: ext Andy Lee [mailto:tvfool@google.com] Sent: Wednesday, September 25, 2013 1:57 PM To: Peter Stanforth Cc: Paul Lambert; Vincent Chen; Bajko Gabor (Nokia-CIC/SiliconValley); paws= @ietf.org Subject: Re: [paws] Spectrum encoding discussion Hi Peter, I can't imagine a Regulator allowing a database operator to manipulate the = unintentional interference in adjacent channels. If it did why stop there? = Why couldn't the database manipulate co-channel interference to nearby prot= ected entities? The recent discussions have been about data encoding and nothing more. The= premise is that IF there is some information the database wants to communi= cate to the white space device, HOW is that data encoded into the message. As a case in point, section 15.709(c)(1) of the rules clearly defines what = the "off" channel power limits must be. The rules originally called for a = "relative" OOB emission limit, but after some industry discussion, the FCC = settled on these "absolute" OOB emission limits instead. The values are cl= early defined, but its not clear whether a database would want to communica= te these parameters to the device or not. On one hand, the database can assume that the device has these values hard-= coded into its firmware and therefore does not need to send that informatio= n over PAWS. On the other hand, these power levels are part of the TVWS rules and perhap= s is something that the database should communicate to the WSD. There are = potentially beneficial things that a WSD could do with that information if = it was provided at run-time (e.g., for future-proofing the device, or choos= ing operating channels more intelligently). PAWS does not need to address WHY a particular parameter should or should n= ot be sent over the protocol. There are many regulatory, business, or tech= nological reasons why these choices might change, and those decisions are b= eyond the scope of the protocol itself. However, PAWS can and should address HOW data gets encoded IF a device or d= atabase decides to send it. i.e., IF you want to encode [X], then you SHALL use [encoding X] IF you want to encode [Y], then you SHALL use [encoding Y] etc. I can identify at least three distinct concepts that have been discussed so= far, which I would categorize as follows: * (i) Explicit "on", Implicit "off" o Anything not explicitly specified as "on" would implicitly be treated = as "off" o The recipient must have apriori knowledge about how to comply with the= "off" channel, "special" channel (e.g., channel 37), and "band-edge" prote= ction ratios o There is no distinction between "off" channels, "special" channels, an= d "band-edge" constraints in the message itself o This requires a way to encode gaps or discontinuities in the spectrum = profile o This is equivalent to Gabor's option (a) * (ii) Explicit "on", Explicit "off" with no power level given o Every channel would be either explicitly "on" or explicitly "off" o Any frequency blocks that are not explicitly "on" or explicitly "off" = are considered to be "out-of-scope" for the current database or ruleset, an= d this implicitly gives the "band-edge" boundaries o The recipient must have apriori knowledge about how to comply with the= "off" channel, "special" channel, and "band-edge" protection ratios o The recipient can infer from the message when to apply "off" channel c= onstraints and when to apply "band-edge" constraints o This requires a way to encode gaps or discontinuities in the spectrum = profile AND requires a way to encode explicit "off" channels with no specif= ied power value o This is equivalent to Gabor's options (c) and (d) * (iii) Explicit "on", Explicit "off" with power level given o Every channel would be either explicitly "on" or explicitly "off" o Any frequency blocks that are not explicitly "on" or explicitly "off" = are considered to be "out-of-scope" for the current database or ruleset, an= d this implicitly gives the "band-edge" boundaries o The "off" channel, "special" channel, and "band-edge" protection ratio= s are explicitly provided in the message, and a device has the option of ei= ther using that information or ignoring it (default back to apriori knowled= ge of the protection ratios) o This requires a way to encode gaps or discontinuities in the spectrum = profile o This is equivalent to Gabor's option (b) I think all three types of encoding have their uses, and PAWS should probab= ly allow all three possibilities. It looks like all three encoding types need a way to express gaps or discon= tinuities in the spectrum profile. I think the latest proposal from Vince,= using a list of lists, addresses this problem nicely. It also looks like encodings for (i) and (iii) are logically equivalent, wi= th the only real difference being that encoding (iii) includes more data po= ints in the spectrum profile than encoding (i). I don't think anything els= e needs to be added to the spec to support both of these encodings. That leaves us with encoding (ii), where we need to add something new to th= e spec to encode explicitly "off" frequency blocks that have no power level= given. For this, we have two proposals: Option (c): Use -inf as the power value in a spectrum profile element Option (d): Leave the power value blank in a spectrum profile element I'd suggest maybe considering yet another proposal: Option (e): Use normal encoding (i) for explicit "on" channels, and then ha= ve a separate list of frequency start/stop pairs indicating the authoritati= ve bands for which the database operates. Anything that is inside the auth= oritative bands but not in an explicitly "on" chunk is effectively saying i= t's explicitly "off". Anything outside of the list of authoritative bands = is considered "out-of-scope" for the database and this essentially lists th= e "band-edge" boundaries. Best regards, Andy Lee | Google Inc. | tvfool@google.com | 408-230-0522 On Wed, Sep 25, 2013 at 5:01 AM, Peter Stanforth > wrote: Lowering the power to meet the mask is the easy way you get a radio certif= ied - thus permission to operate. How is that anything to do with the datab= ase - which is simply managing Regulator policy? The ruleset is going to tell you what masks and other operating parameters = are acceptable within a regulatory domain. I can't imagine a Regulator allo= wing a database operator to manipulate the unintentional interference in ad= jacent channels. If it did why stop there? Why couldn't the database manipu= late co-channel interference to nearby protected entities? I thought we had a fairly elegant and simple solution. The ruleset defines = the box the device can operate in and the database provides a specific set = of permitted channels/frequencies within that box based on the location, ti= me, and type of device making the request. All with respect to the specific= list of entities the database has been told to protect at that location at= that time. One final comment and then I will rest my case. I have had conversations wi= th several Regulators about this recently, and they do not like any notion = that the database is "thinking" about the answer. In every case they have said something along the lines of "if the database = does not explicitly give a device permission to use a channel the device is= not allowed to use it". In every case they have gone somewhat further stating that if the database = operation goes beyond this simple approach they think it highly unlikely th= at they will get cooperation from incumbents. If you don't believe me - go = ask them! Which brings me back to my soap box. We want to get PAWS done so we can ena= ble white space. In my humble opinion, the more time we spend pontificating= and the more complex we make it we are likely to achieve the opposite. Peter S. From: Paul Lambert > Date: Tuesday, September 24, 2013 2:48 PM To: Don Joslyn >, Vincent Chen >, "gabor.baj= ko@nokia.com" >, "paws@ietf.org" > Subject: Re: [paws] Spectrum encoding discussion In line below ... speaking strongly in favor of "b" Gabor, I agree on possible renaming, if we want to specify unavailable channels. Please see comments inline. On Mon, Sep 23, 2013 at 12:56 PM, > wrote: Vince, This proposal of yours below could potentially become very confusing. The m= essage itself is named Available Spectrum Request, and you propose the Avai= lable Spectrum Response to include a bunch of channels with unspecified pow= er levels, which are btw, not available channels. So far, we have 4 proposed ways to indicate unavailable channels: a) Not listing it, implicit unavailability This has the drawback of not distinguishing between being silent about a ch= annel that is within the database's purview (channel off), and being silent= about a channel that is outside the database's purview (out of scope for g= iven ruleset). [DJ - Why should the database care about channels that are outside the scop= e of the ruleset specified by the radio? For example, if the specified rule= set is FCC-related, then why would I need to include Ofcom-related channels= in the response? Am I missing something?] The rules have strict adjacent channel requirements. Meeting the spectral = mask for the adjacent channels is one of the hardest parts for fielding re= al equipment. If the rules allow relative measurement of the adjacent chan= nel energy, you can simply lower your transmit power to the point that you = can meet the adjacent requirements. For a general White Spaces solution - it is critical to have knowledge for = the full spectrum mask. The full spectrum mask includes adjacent non-allow= ed channels. RF channel usage are NOT a binary on/off or a simple transmit level. The m= ask has a specific contour that extends beyond the "allowed" channel. Tran= smitters will always send energy in more than the allowed channel! Paul b) List unavailable channels and specify the power limit, eg -56dbm Since the protocol should stand on its own, independent of any particular r= egulatory rule, do we really want to rule this out? In our interpretations = of the FCC rules, for example, a Database is not prevented from doing this. [DJ - I'm still in favor of just using the implicit unavailability method d= escribed above in a). What value is there in providing a power level for an= unavailable channel? If I'm the radio, I can't use the channel, and I'm no= t going to intentionally transmit in that channel. This comment also applie= s to c) and d).] c) List unavailable channels and specify -inf as power limit "-Inf" is not really workable, because JSON does not allow Infinity or NaNs= (http://tools.ietf.org/html/rfc4627), hence the d) proposal. d) List unavailable channels and do not specify any power limit So far, we have majority in favour of a), few people who could live or pref= er c) and sort of consensus to strike out option b) from the list above. We'll wait for more input on the list before declaring rough consensus for = the question above; then we'll go back to the original question on whether = the encoding of spectrum profile should be option 1 or option 2. p.s. It looks to me, that if we want to specify unavailable channels, we ma= y need to modify the names of the paws messages to 'Spectrum schedule' or s= g along these lines. - Gabor _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws --_000_2782C93FD2244441893673F3F912819226D27F2CIMCMBX01MITREOR_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

For what it is worth I ha= ve been working on methods to model spectrum use that can be used to give g= uidance to radios. (We have just started to standardize these methods in IEEE 1900.5.2.)  We have two different kinds of guid= ance, permissive and restrictive.  They are sent in separate lists.&nb= sp; The permissive (aka authorization) list identifies channels a device or= system can operate and if combined with a restrictive (aka constraint) list then so long as the user does not violate a listed r= estriction.  Each of these lists use spectrum and time at two levels.&= nbsp; The top level indicates the band and time period the list is comprehe= nsive.  The second level indicates the particular channels and time periods of availability or restriction.  I would im= agine that TVWS would only need the authorization list.  Future applic= ations where spectrum owners add spectrum to the database and coexistence i= s managed will require both.

 <= /p>

John

 <= /p>

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Gabor.Bajko@nokia.com
Sent: Wednesday, September 25, 2013 6:56 PM
To: tvfool@google.com; peter@spectrumbridge.com
Cc: paws@ietf.org
Subject: Re: [paws] Spectrum encoding discussion

 

-  &n= bsp;       Gabor<= /span>

From: ext Andy Lee [mailt= o:tvfool@google.com]
Sent: Wednesday, September 25, 2013 1:57 PM
To: Peter Stanforth
Cc: Paul Lambert; Vincent Chen; Bajko Gabor (Nokia-CIC/SiliconValley= ); paws@ietf.org
Subject: Re: [paws] Spectrum encoding discussion

 

Hi Peter,

 

I can't imag= ine a Regulator allowing a database operator to manipulate the unintentiona= l interference in adjacent channels. If it did why stop there? Why couldn't the database manipulate co-channel interference to nearby pro= tected entities?

 

The recent discussions ha= ve been about data encoding and nothing more.  The premise is that IF there is some information the database wants to communicate to th= e white space device, HOW is that data encoded into the message.

 

As a case in point, secti= on 15.709(c)(1) of the rules clearly defines what the "off" chann= el power limits must be.  The rules originally called for a "rela= tive" OOB emission limit, but after some industry discussion, the FCC settled on these "absolute" OOB emission limits instead.=  The values are clearly defined, but its not clear whether a database= would want to communicate these parameters to the device or not.

 

On one hand, the database= can assume that the device has these values hard-coded into its firmware a= nd therefore does not need to send that information over PAWS.

 

On the other hand, these = power levels are part of the TVWS rules and perhaps is something that the d= atabase should communicate to the WSD.  There are potentially benefici= al things that a WSD could do with that information if it was provided at run-time (e.g., for future-proofing the device, or c= hoosing operating channels more intelligently).

 

 

 

 

 

PAWS does not need to = address WHY a particular parameter should or should not be sent over the pr= otocol.  There are many regulatory, business, or technological rea= sons why these choices might change, and those decisions are beyond the scope of the protocol itself.

 

However, PAWS can and = should address HOW data gets encoded IF a device or database decides to sen= d it.  i.e.,

 

IF you want to encode [X]= , then you SHALL use [encoding X]

IF you want to encode [Y]= , then you SHALL use [encoding Y]

etc.

 

I can identify at least t= hree distinct concepts that have been discussed so far, which I would categ= orize as follows:

·         (i) Explicit "on", Implicit "= off"

o    Anything not explicitly specified as "o= n" would implicitly be treated as "off"

o    The recipient must have apriori knowledge ab= out how to comply with the "off" channel, "special" cha= nnel (e.g., channel 37), and "band-edge" protection ratios

o    There is no distinction between "off&qu= ot; channels, "special" channels, and "band-edge" const= raints in the message itself

o    This requires a way to encode gaps or discon= tinuities in the spectrum profile

o    This is equivalent to Gabor's option (a)

 

·         (ii) Explicit "on", Expl= icit "off" with no power level given

o    Every channel would be either explicitly &qu= ot;on" or explicitly "off"

o    Any frequency blocks that are not explicitly= "on" or explicitly "off" are considered to be "ou= t-of-scope" for the current database or ruleset, and this implicitly g= ives the "band-edge" boundaries

o    The recipient must have apriori knowledge ab= out how to comply with the "off" channel, "special" cha= nnel, and "band-edge" protection ratios

o    The recipient can infer from the message whe= n to apply "off" channel constraints and when to apply "band= -edge" constraints

o    This requires a way to encode gaps or discon= tinuities in the spectrum profile AND requires a way to encode explicit &qu= ot;off" channels with no specified power value

o    This is equivalent to Gabor's options (c) an= d (d)

 

·         (iii) Explicit "on", Exp= licit "off" with power level given

o    Every channel would be either explicitly &qu= ot;on" or explicitly "off"

o    Any frequency blocks that are not explicitly= "on" or explicitly "off" are considered to be "ou= t-of-scope" for the current database or ruleset, and this implicitly g= ives the "band-edge" boundaries

o    The "off" channel, "special&q= uot; channel, and "band-edge" protection ratios are explicitly pr= ovided in the message, and a device has the option of either using that inf= ormation or ignoring it (default back to apriori knowledge of the protection ratios)

o    This requires a way to encode gaps or discon= tinuities in the spectrum profile

o    This is equivalent to Gabor's option (b)

 

 

I think all three types o= f encoding have their uses, and PAWS should probably allow all three possib= ilities.

 

It looks like all three e= ncoding types need a way to express gaps or discontinuities in the spectrum= profile.  I think the latest proposal from Vince, using a list of lis= ts, addresses this problem nicely.

 

It also looks like encodi= ngs for (i) and (iii) are logically equivalent, with the only real differen= ce being that encoding (iii) includes more data points in the spectrum prof= ile than encoding (i).  I don't think anything else needs to be added to the spec to support both of these encod= ings.

 

 

 

That leaves us with encod= ing (ii), where we need to add something new to the spec to encode explicit= ly "off" frequency blocks that have no power level given.  F= or this, we have two proposals:

 

Option (c): Use -inf as t= he power value in a spectrum profile element

Option (d): Leave the pow= er value blank in a spectrum profile element

 

I'd suggest maybe conside= ring yet another proposal:

 

Option (e): Use normal en= coding (i) for explicit "on" channels, and then have a separate l= ist of frequency start/stop pairs indicating the authoritative bands for wh= ich the database operates.  Anything that is inside the authoritative bands but not in an explicitly "on" chunk is e= ffectively saying it's explicitly "off".  Anything outside o= f the list of authoritative bands is considered "out-of-scope" fo= r the database and this essentially lists the "band-edge" boundar= ies.

 

 

 

Best regards,<= /p>


 

Andy Lee |

 Google Inc. |

 tvfool@google.com |

 408-230-0522

 

On Wed, Sep 25, 2013 at 5= :01 AM, Peter Stanforth <peter@spectrumbridge.com> wrote:

 Loweri= ng the power to meet the mask is the easy way you get a radio certified = 211; thus permission to operate. How is that anything to do with the database - which is simply managing Regulator policy?

The ruleset = is going to tell you what masks and other operating parameters are acceptab= le within a regulatory domain. I can't imagine a Regulator allowing a database operator to manipulate the unintentional interference = in adjacent channels. If it did why stop there? Why couldn't the database m= anipulate co-channel interference to nearby protected entities?<= /span>

I thought we= had a fairly elegant and simple solution. The ruleset defines the box the = device can operate in and the database provides a specific set of permitted channels/frequencies within that box based on the locatio= n, time, and type of device making the request. All with respect to the spe= cific list of entities the database has been told to protect at that locati= on at that time.

 <= /o:p>

One final co= mment and then I will rest my case. I have had conversations with several R= egulators about this recently, and they do not like any notion that the database is "thinking" about the answer.

In every cas= e they have said something along the lines of "if the database does no= t explicitly give a device permission to use a channel the device is not allowed to use it".

In every cas= e they have gone somewhat further stating that if the database operation go= es beyond this simple approach they think it highly unlikely that they will get cooperation from incumbents. If you don't believe me &#= 8211; go ask them!

Which brings= me back to my soap box. We want to get PAWS done so we can enable white sp= ace. In my humble opinion, the more time we spend pontificating and the more complex we make it we are likely to achieve the opposite.

Peter S.

 <= /o:p>

 <= /o:p>

From: Paul Lambert <paul@marvell.com>
Date: Tuesday, September 24, 2013 2:48 PM
To: Don Joslyn <d.joslyn@spectrumbridge.com>, Vincent Chen <vchen@google.com>, = "gabor.bajk= o@nokia.com" <Gabor.Bajko= @nokia.com>, "paws@ietf.org" <paws@ietf.org>


Subject: Re: [paws] Spectrum encoding discussion

 <= /o:p>

In line belo= w … speaking strongly in favor of "b" 

 <= /o:p>

 <= /o:p>

Gabor,

 

I agree on possible renaming, if we want to specify unavailable channels.

 

Please see comments inline. 

 

On Mon, Sep 23, 2013 at 12:56 PM, <Gabor.Bajko@nokia.com> wrote:

Vince,

This proposal of yours below could potentially b= ecome very confusing. The message itself is named Available Spectrum Reques= t, and you propose the Available Spectrum Response to include a bunch of channels with unspecified power levels, which are btw, = not available channels.

 So far, we have 4 proposed ways to indicat= e unavailable channels:

a)      Not listing it, implicit unavailability

This has the drawback of not distinguishing between being s= ilent about a channel that is within the database's purview (channel off), = and being silent about a channel that is outside the database's purview (out of scope for given ruleset).

 

[DJ – Why should the database care about c= hannels that are outside the scope of the ruleset specified by the radio? F= or example, if the specified ruleset is FCC-related, then why would I need to include Ofcom-related channels in the response? Am I missi= ng something?]

 <= /o:p>

The rules ha= ve strict adjacent channel requirements.  Meeting the spectral mask fo= r the adjacent channels  is one of the hardest parts for fielding real equipment.  If the rules allow relative measurement of the adjac= ent channel energy, you can simply lower your transmit power to the point t= hat you can meet the adjacent requirements.  

 <= /o:p>

For a genera= l White Spaces solution – it is critical to have knowledge for the fu= ll spectrum mask.  The full spectrum mask includes adjacent non-allowe= d channels.

 <= /o:p>

RF channel u= sage are NOT a binary on/off or a simple transmit level.  The mask has= a specific contour that extends beyond the "allowed" channel.  Transmitters will always send energy in more than the allowed channe= l!

 <= /o:p>

 <= /o:p>

 <= /o:p>

Paul

 <= /o:p>

 <= /o:p>

 

b)      List unavailable channels and specify the= power limit, eg -56dbm

Since the protocol should stand on its own, independent of any particular r= egulatory rule, do we really want to rule this out? In our interpretations = of the FCC rules, for example, a Database is not prevented from doing this.=

 

[DJ – I’m still in favor of just usi= ng the implicit unavailability method described above in a). What value is = there in providing a power level for an unavailable channel? If I’m the radio, I can’t use the channel, and I’m not going to inten= tionally transmit in that channel. This comment also applies to c) and d).]=

 

c)       List unavailable channels and specify = 211;inf as power limit

 

"-Inf" is not really workable, because JSON does not allow Infini= ty or NaNs (http://tools.ietf.org/html/rfc4627), hence the d) proposal.

 

d)      List unavailable channels and do not spec= ify any power limit 

 

So far, we have majority in favour of a), few pe= ople who could live or prefer c) and sort of consensus to strike out option= b) from the list above.

 

We’ll wait for more input on the list befo= re declaring rough consensus for the question above; then we’ll go ba= ck to the original question on whether the encoding of spectrum profile should be option 1 or option 2.

 

p.s. It looks to me, that if we want to specify = unavailable channels, we may need to modify the names of the paws messages = to ‘Spectrum schedule’ or sg along these lines.

 

-          Gabor

 

 <= /o:p>

 <= /o:p>


_______________________________________________
paws mailing list
paws@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/paws

 

--_000_2782C93FD2244441893673F3F912819226D27F2CIMCMBX01MITREOR_-- From vchen@google.com Thu Sep 26 17:36:32 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F26321F9950 for ; Thu, 26 Sep 2013 17:36:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.867 X-Spam-Level: X-Spam-Status: No, score=-1.867 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pj0J98Ps7haF for ; Thu, 26 Sep 2013 17:36:25 -0700 (PDT) Received: from mail-oa0-x22e.google.com (mail-oa0-x22e.google.com [IPv6:2607:f8b0:4003:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 8C1C221F9E12 for ; Thu, 26 Sep 2013 17:36:10 -0700 (PDT) Received: by mail-oa0-f46.google.com with SMTP id k14so1586380oag.19 for ; Thu, 26 Sep 2013 17:36:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8d7IUFKzVGCPM8r6bbUuDiqqfPflpeQJLspzqf2xEnM=; b=m0ed8rE8lMqLtUYE7Zfj9GqrFxBlEhzeTpSdB4EmhWOi+1SzBENzu7x7VNG4X4NC+t CryqLUTLtTesDqEYh14Q5MBQO5nBsajVeeKL5GzK8zowdv4gd40sm3MLNF7LsySXAGQc P9KuXvtKPU7bQKmMHkcA0BA8e0JpxiT68bWWJjNIYbNiI40kCaCK7x5AYu3IKRPEcueA BODOHnw6tfw+/HJE9PA0lzhGz5wPEAO+3Y7e4+HBjPutvDiKPD7G/2UNmGupVSZF4WhP 95CguH5S8T54VAstA7D8E4yN0jPtGY85MQy2dz8cXAd45QVphO4Gc3BnMlQrSCpnG6tr ZCPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=8d7IUFKzVGCPM8r6bbUuDiqqfPflpeQJLspzqf2xEnM=; b=f7cucvjAO8n0cwOo1iaZWDeLMFK16E4veDeCO+KsPXBSfGGwTtPcPTvQ1kjriMV8i9 Fb9FQ5wPqljGlQvbtxetAYGuMgXWIukzhUrOQ2I5EZQgGQ7H0xkeHL69/so051DDnN6R cmuQ5Wa79im3qsIl20XOTBjPkXSgFO2O4zRMynrCf9+HAcreHpxU9j1zV1pnSXVeUX9+ lsEzQNPdgtws/5WLe9vL5q5jGppBy4UhUZq5rVHVbaZswIbw62wl365QRiLitgbk2gdH HXuBrV1d8hKoih4CONDYFgx4wFr+YlSciH6sz9pLcqjGwjeR24uM3Xad1hVOUG4IsQZ/ dzcw== X-Gm-Message-State: ALoCoQmrHoe4ES3Bjo+62aYBWOadlEEs7+sI+kKdGX2CE8VlT9ZWdVX2ejmX/3K121tbRiyyXHz5798FTtHRlgjigUWrX4vaX+3WMR4LBO0isILHve/KelxFmiZ2hC+Rb/ULfDr8/Pt+L58+kawljBewtQTjFcHVAohL6+Bje6svE6+nyKvFwqVY2aDS01l7oiZMO4LGVqi/ MIME-Version: 1.0 X-Received: by 10.60.60.5 with SMTP id d5mr3326799oer.0.1380242168844; Thu, 26 Sep 2013 17:36:08 -0700 (PDT) Received: by 10.182.250.134 with HTTP; Thu, 26 Sep 2013 17:36:08 -0700 (PDT) In-Reply-To: <2782C93FD2244441893673F3F912819226D27F2C@IMCMBX01.MITRE.ORG> References: <1ECAFF543A2FED4EA2BEB6CACE08E47605364C49@008-AM1MPN1-006.mgdnok.nokia.com> <2782C93FD2244441893673F3F912819226D27F2C@IMCMBX01.MITRE.ORG> Date: Thu, 26 Sep 2013 17:36:08 -0700 Message-ID: From: Vincent Chen To: "Stine, John A." Content-Type: multipart/alternative; boundary=089e0149c3c02dac9404e752acf0 Cc: "paws@ietf.org" Subject: Re: [paws] Spectrum encoding discussion X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 00:36:32 -0000 --089e0149c3c02dac9404e752acf0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable John, Thanks for your input. It aligns nicely with Andy's suggestion of specifying "authoritative bands" separately. Taking your suggestion of also expressing "authoritative time range", we could have an encoding example like the following: { "rulesetInfo": { ... }, "timeRange": [ "2013-10-01T00:00:00Z", "2013-10-03T00:00:00Z" ], "frequencyRanges": [ [5.4e7, 7.2e7], // channels 2-4 [7.6e7, 8.8e7], // channels 5-6 [1.74e8, 2.16e8], // channels 7-13 [4.70e8, 6.98e8], // channels 14-51 ], "spectrumSchedules": [ { "time": [ "2013-10-01T00:00:00Z", "2013-10-01T05:00:00Z" ], "spectra" [ { "psdBandwidthHz": 6e6, [ { "freqHz": 4.70e8, "maxPsdDbmPerBw": 30.0 }, // channel 14 { "freqHz": 4.76e8, "maxPsdDbmPerBw": 30.0 }, { "freqHz": 5.18e8, "maxPsdDbmPerBw": 30.0 }, // channel 22 { "freqHz": 5.24e8, "maxPsdDbmPerBw": 30.0 }, { "freqHz": 5.24e8, "maxPsdDbmPerBw": 36.0 }, // channel 23 { "freqHz": 5.30e8, "maxPsdDbmPerBw": 36.0 } ] }, { "psdBandwidthHz": 1e5, [ { "freqHz": 4.70e8, "maxPsdDbmPerBw": 27.0 }, // channel 14 { "freqHz": 4.76e8, "maxPsdDbmPerBw": 27.0 }, { "freqHz": 5.18e8, "maxPsdDbmPerBw": 27.0 }, // channel 22 { "freqHz": 5.24e8, "maxPsdDbmPerBw": 27.0 }, { "freqHz": 5.24e8, "maxPsdDbmPerBw": 33.0 }, // channel 23 { "freqHz": 5.30e8, "maxPsdDbmPerBw": 33.0 } ] } ] }, { "time": [ "2013-10-01T05:00:00Z", "2013-10-03T00:00:00Z" ], ... }, ... ], ... } Features - Explicit indication of authoritative time ranges and frequency ranges associated with the response - Within a spectrum list, missing frequencies now can be interpreted unambiguously as unavailable without magic values - If there are gaps in time intervals, it also may be interpreted unambiguously as no available frequencies - Still allows the protocol to express of full mask where allowed Thoughts? -vince On Thu, Sep 26, 2013 at 3:14 AM, Stine, John A. wrote: > For what it is worth I have been working on methods to model spectrum > use that can be used to give guidance to radios. (We have just started to > standardize these methods in IEEE 1900.5.2.) We have two different kinds > of guidance, permissive and restrictive. They are sent in separate lists= . > The permissive (aka authorization) list identifies channels a device or > system can operate and if combined with a restrictive (aka constraint) li= st > then so long as the user does not violate a listed restriction. Each of > these lists use spectrum and time at two levels. The top level indicates > the band and time period the list is comprehensive. The second level > indicates the particular channels and time periods of availability or > restriction. I would imagine that TVWS would only need the authorization > list. Future applications where spectrum owners add spectrum to the > database and coexistence is managed will require both.**** > > ** ** > > John**** > > ** ** > > *From:* paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] *On Behalf > Of *Gabor.Bajko@nokia.com > *Sent:* Wednesday, September 25, 2013 6:56 PM > *To:* tvfool@google.com; peter@spectrumbridge.com > *Cc:* paws@ietf.org > > *Subject:* Re: [paws] Spectrum encoding discussion**** > > ** ** > > Andy,**** > > ** ** > > This option (e) proposal sounds like you may want to encode two things > which could be separated; the available channels, and the authoritative > bands.**** > > We could leave the available spectrum req/resp unchanged, and eg have a > separate req/resp for the authoritative bands. **** > > And we could also encode the power leakage limits eg inside the ruleset > info, so that devices would not necessarily need to be hard-coded with > those, to satisfy everyone.**** > > Could this be an agreeable way forward?**** > > ** ** > > **- **Gabor**** > > ** ** > > *From:* ext Andy Lee [mailto:tvfool@google.com ] > *Sent:* Wednesday, September 25, 2013 1:57 PM > *To:* Peter Stanforth > *Cc:* Paul Lambert; Vincent Chen; Bajko Gabor (Nokia-CIC/SiliconValley); > paws@ietf.org > *Subject:* Re: [paws] Spectrum encoding discussion**** > > ** ** > > Hi Peter,**** > > **** > > I can't imagine a Regulator allowing a database operator to manipulate th= e > unintentional interference in adjacent channels. If it did why stop there= ? > Why couldn't the database manipulate co-channel interference to nearby > protected entities?**** > > ** ** > > The recent discussions have been about data encoding and nothing more. > The premise is that *IF* there is some information the database wants to > communicate to the white space device, *HOW* is that data encoded into > the message.**** > > ** ** > > As a case in point, section 15.709(c)(1) of the rules clearly defines wha= t > the "off" channel power limits must be. The rules originally called for = a > "relative" OOB emission limit, but after some industry discussion, the FC= C > settled on these "absolute" OOB emission limits instead. The values are > clearly defined, but its not clear whether a database would want to > communicate these parameters to the device or not.**** > > ** ** > > On one hand, the database can assume that the device has these values > hard-coded into its firmware and therefore does not need to send that > information over PAWS.**** > > ** ** > > On the other hand, these power levels are part of the TVWS rules and > perhaps is something that the database should communicate to the WSD. > There are potentially beneficial things that a WSD could do with that > information if it was provided at run-time (e.g., for future-proofing the > device, or choosing operating channels more intelligently).**** > > ** ** > > ** ** > > ** ** > > ** ** > > ** ** > > *PAWS does not need to address WHY a particular parameter should or > should not be sent over the protocol.* There are many regulatory, > business, or technological reasons why these choices might change, and > those decisions are beyond the scope of the protocol itself.**** > > ** ** > > However, *PAWS can and should address HOW data gets encoded IF a device > or database decides to send it.* i.e.,**** > > ** ** > > IF you want to encode [X], then you SHALL use [encoding X]**** > > IF you want to encode [Y], then you SHALL use [encoding Y]**** > > etc.**** > > ** ** > > I can identify at least three distinct concepts that have been discussed > so far, which I would categorize as follows:**** > > **=B7 **(i) Explicit "on", Implicit "off"**** > > **o **Anything not explicitly specified as "on" would implicitly be > treated as "off"**** > > **o **The recipient must have apriori knowledge about how to comply > with the "off" channel, "special" channel (e.g., channel 37), and > "band-edge" protection ratios**** > > **o **There is no distinction between "off" channels, "special" > channels, and "band-edge" constraints in the message itself**** > > **o **This requires a way to encode gaps or discontinuities in the > spectrum profile**** > > **o **This is equivalent to Gabor's option (a)**** > > ** ** > > **=B7 **(ii) Explicit "on", Explicit "off" with no power level gi= ven > **** > > **o **Every channel would be either explicitly "on" or explicitly "off= " > **** > > **o **Any frequency blocks that are not explicitly "on" or explicitly > "off" are considered to be "out-of-scope" for the current database or > ruleset, and this implicitly gives the "band-edge" boundaries**** > > **o **The recipient must have apriori knowledge about how to comply > with the "off" channel, "special" channel, and "band-edge" protection rat= ios > **** > > **o **The recipient can infer from the message when to apply "off" > channel constraints and when to apply "band-edge" constraints**** > > **o **This requires a way to encode gaps or discontinuities in the > spectrum profile AND requires a way to encode explicit "off" channels wit= h > no specified power value**** > > **o **This is equivalent to Gabor's options (c) and (d)**** > > ** ** > > **=B7 **(iii) Explicit "on", Explicit "off" with power level give= n** > ** > > **o **Every channel would be either explicitly "on" or explicitly "off= " > **** > > **o **Any frequency blocks that are not explicitly "on" or explicitly > "off" are considered to be "out-of-scope" for the current database or > ruleset, and this implicitly gives the "band-edge" boundaries**** > > **o **The "off" channel, "special" channel, and "band-edge" protection > ratios are explicitly provided in the message, and a device has the optio= n > of either using that information or ignoring it (default back to apriori > knowledge of the protection ratios)**** > > **o **This requires a way to encode gaps or discontinuities in the > spectrum profile**** > > **o **This is equivalent to Gabor's option (b)**** > > ** ** > > ** ** > > I think all three types of encoding have their uses, and PAWS should > probably allow all three possibilities.**** > > ** ** > > It looks like all three encoding types need a way to express gaps or > discontinuities in the spectrum profile. I think the latest proposal fro= m > Vince, using a list of lists, addresses this problem nicely.**** > > ** ** > > It also looks like encodings for (i) and (iii) are logically equivalent, > with the only real difference being that encoding (iii) includes more dat= a > points in the spectrum profile than encoding (i). I don't think anything > else needs to be added to the spec to support both of these encodings.***= * > > ** ** > > ** ** > > ** ** > > That leaves us with encoding (ii), where we need to add something new to > the spec to encode explicitly "off" frequency blocks that have no power > level given. For this, we have two proposals:**** > > ** ** > > Option (c): Use -inf as the power value in a spectrum profile element**** > > Option (d): Leave the power value blank in a spectrum profile element**** > > ** ** > > I'd suggest maybe considering yet another proposal:**** > > ** ** > > Option (e): Use normal encoding (i) for explicit "on" channels, and then > have a separate list of frequency start/stop pairs indicating the > authoritative bands for which the database operates. Anything that is > inside the authoritative bands but not in an explicitly "on" chunk is > effectively saying it's explicitly "off". Anything outside of the list o= f > authoritative bands is considered "out-of-scope" for the database and thi= s > essentially lists the "band-edge" boundaries.**** > > ** ** > > ** ** > > ** ** > > Best regards,**** > > > **** > > ** ** > > Andy Lee |**** > > Google Inc. |**** > > tvfool@google.com |**** > > 408-230-0522**** > > ** ** > > On Wed, Sep 25, 2013 at 5:01 AM, Peter Stanforth > wrote:**** > > Lowering the power to meet the mask is the easy way you get a radio > certified =96 thus permission to operate. How is that anything to do with= the > database - which is simply managing Regulator policy?**** > > The ruleset is going to tell you what masks and other operating parameter= s > are acceptable within a regulatory domain. I can't imagine a Regulator > allowing a database operator to manipulate the unintentional interference > in adjacent channels. If it did why stop there? Why couldn't the database > manipulate co-channel interference to nearby protected entities?**** > > I thought we had a fairly elegant and simple solution. The ruleset define= s > the box the device can operate in and the database provides a specific se= t > of permitted channels/frequencies within that box based on the location, > time, and type of device making the request. All with respect to the > specific list of entities the database has been told to protect at that > location at that time.**** > > ** ** > > One final comment and then I will rest my case. I have had conversations > with several Regulators about this recently, and they do not like any > notion that the database is "thinking" about the answer.**** > > In every case they have said something along the lines of "if the databas= e > does not explicitly give a device permission to use a channel the device = is > not allowed to use it".**** > > In every case they have gone somewhat further stating that if the databas= e > operation goes beyond this simple approach they think it highly unlikely > that they will get cooperation from incumbents. If you don't believe me = =96 > go ask them!**** > > Which brings me back to my soap box. We want to get PAWS done so we can > enable white space. In my humble opinion, the more time we spend > pontificating and the more complex we make it we are likely to achieve th= e > opposite.**** > > Peter S.**** > > ** ** > > ** ** > > *From: *Paul Lambert > *Date: *Tuesday, September 24, 2013 2:48 PM > *To: *Don Joslyn , Vincent Chen < > vchen@google.com>, "gabor.bajko@nokia.com" , " > paws@ietf.org" **** > > > *Subject: *Re: [paws] Spectrum encoding discussion**** > > ** ** > > In line below =85 speaking strongly in favor of "b" **** > > ** ** > > ** ** > > Gabor,**** > > **** > > I agree on possible renaming, if we want to specify unavailable channels.= * > *** > > **** > > Please see comments inline. **** > > **** > > On Mon, Sep 23, 2013 at 12:56 PM, wrote:**** > > Vince,**** > > This proposal of yours below could potentially become very confusing. The > message itself is named Available Spectrum Request, and you propose the > Available Spectrum Response to include a bunch of channels with unspecifi= ed > power levels, which are btw, not available channels. **** > > So far, we have 4 proposed ways to indicate unavailable channels:**** > > a) Not listing it, implicit unavailability**** > > This has the drawback of not distinguishing between being silent about a > channel that is within the database's purview (channel off), and being > silent about a channel that is outside the database's purview (out of sco= pe > for given ruleset).**** > > **** > > [DJ =96 Why should the database care about channels that are outside the > scope of the ruleset specified by the radio? For example, if the specifie= d > ruleset is FCC-related, then why would I need to include Ofcom-related > channels in the response? Am I missing something?]**** > > ** ** > > The rules have strict adjacent channel requirements. Meeting the spectra= l > mask for the adjacent channels is one of the hardest parts for fielding > real equipment. If the rules allow relative measurement of the adjacent > channel energy, you can simply lower your transmit power to the point tha= t > you can meet the adjacent requirements. **** > > ** ** > > For a general White Spaces solution =96 it is critical to have knowledge = for > the full spectrum mask. The full spectrum mask includes adjacent > non-allowed channels.**** > > ** ** > > RF channel usage are NOT a binary on/off or a simple transmit level. The > mask has a specific contour that extends beyond the "allowed" channel. > Transmitters will always send energy in more than the allowed channel!**= * > * > > ** ** > > ** ** > > ** ** > > Paul**** > > ** ** > > ** ** > > **** > > b) List unavailable channels and specify the power limit, eg -56dbm= * > *** > > Since the protocol should stand on its own, independent of any > particular regulatory rule, do we really want to rule this out? In our > interpretations of the FCC rules, for example, a Database is not prevente= d > from doing this.**** > > **** > > [DJ =96 I=92m still in favor of just using the implicit unavailability me= thod > described above in a). What value is there in providing a power level for > an unavailable channel? If I=92m the radio, I can=92t use the channel, an= d I=92m > not going to intentionally transmit in that channel. This comment also > applies to c) and d).]**** > > **** > > c) List unavailable channels and specify =96inf as power limit**** > > **** > > "-Inf" is not really workable, because JSON does not allow Infinity or > NaNs (http://tools.ietf.org/html/rfc4627), hence the d) proposal.**** > > **** > > d) List unavailable channels and do not specify any power limit ***= * > > **** > > So far, we have majority in favour of a), few people who could live or > prefer c) and sort of consensus to strike out option b) from the list abo= ve. > **** > > **** > > We=92ll wait for more input on the list before declaring rough consensus = for > the question above; then we=92ll go back to the original question on whet= her > the encoding of spectrum profile should be option 1 or option 2.**** > > **** > > p.s. It looks to me, that if we want to specify unavailable channels, we > may need to modify the names of the paws messages to =91Spectrum schedule= =92 or > sg along these lines.**** > > **** > > - Gabor**** > > **** > > ** ** > > ** ** > > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws**** > > ** ** > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > > --=20 -vince --089e0149c3c02dac9404e752acf0 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
John,

Thanks for your input. It aligns = nicely with Andy's suggestion of specifying "authoritative bands&q= uot; separately. Taking your suggestion of also expressing "authoritat= ive time range", we could have an encoding example like the following:=

{
=A0 "rulesetInfo": { ... },<= /div>
=A0 "timeRange": [ "2013-10-01T00:00:00Z", &q= uot;2013-10-03T00:00:00Z" ],
=A0 "frequencyRanges"= : [
=A0 =A0 [5.4e7, 7.2e7], =A0 // channels 2-4
=A0 =A0 [7.6e7, = 8.8e7], =A0 // channels 5-6
=A0 =A0 [1.74e8, 2.16e8], // channels= 7-13
=A0 =A0 [4.70e8, 6.98e8], // channels 14-51
=A0 ]= ,
=A0 "spectrumSchedules": [
=A0 =A0 {
=A0 =A0 =A0 "time": [ "2013-10-01T0= 0:00:00Z", "2013-10-01T05:00:00Z" ],
=A0 =A0 =A0 &= quot;spectra" [
=A0 =A0 =A0 =A0{
=A0 =A0 =A0 =A0 = =A0"psdBandwidthHz": 6e6,
=A0 =A0 =A0 =A0 =A0[
=A0 =A0 =A0 =A0 =A0 { "freqHz"= ;: 4.70e8, "maxPsdDbmPerBw": 30.0 }, =A0// channel 14
= =A0 =A0 =A0 =A0 =A0 { "freqHz": 4.76e8, "maxPsdDbmPerBw"= ;: 30.0 },
=A0 =A0 =A0 =A0 =A0 { "freqHz": 5.18e8, &quo= t;maxPsdDbmPerBw": 30.0 }, =A0// channel 22
=A0 =A0 =A0 =A0 =A0 { "freqHz": 5.24e8, "maxPsdDbmPerBw= ": 30.0 },
=A0 =A0 =A0 =A0 =A0 { "freqHz": 5.24e8,= "maxPsdDbmPerBw": 36.0 }, =A0// channel 23
=A0 =A0 =A0= =A0 =A0 { "freqHz": 5.30e8, "maxPsdDbmPerBw": 36.0 }
=A0 =A0 =A0 =A0 =A0]
=A0 =A0 =A0 =A0},
=A0 =A0 =A0= =A0{
=A0 =A0 =A0 =A0 =A0"psdBandwidthHz": 1e5,
=A0 =A0 =A0 =A0 =A0[
=A0 =A0 =A0 =A0 =A0 { "freqHz":= 4.70e8, "maxPsdDbmPerBw": 27.0 }, =A0// channel 14
=A0 =A0 =A0 =A0 =A0 { "freqHz": 4.76e8, "maxPsdDbmPerBw= ": 27.0 },
=A0 =A0 =A0 =A0 =A0 { "freqHz": 5.18e8,= "maxPsdDbmPerBw": 27.0 }, =A0// channel 22
=A0 =A0 =A0= =A0 =A0 { "freqHz": 5.24e8, "maxPsdDbmPerBw": 27.0 },<= /div>
=A0 =A0 =A0 =A0 =A0 { "freqHz": 5.24e8, "maxPsdDbmPerBw= ": 33.0 }, =A0// channel 23
=A0 =A0 =A0 =A0 =A0 { "freq= Hz": 5.30e8, "maxPsdDbmPerBw": 33.0 }
=A0 =A0 =A0 = =A0 =A0]
=A0 =A0 =A0 =A0}
=A0 =A0 =A0 ]
=A0 =A0 },
=A0 =A0 {
=A0 = =A0 =A0 "time": [ "2013-10-01T05:00:00Z", "2013-10= -03T00:00:00Z" ],
=A0 =A0 =A0 ...
=A0 =A0 },
=
=A0 =A0 ...
=A0 ],
=A0 ...
}

Features
=
  • Explicit indication of authoritative time ranges and frequency= ranges associated with the response
  • Within a spectrum list, missin= g frequencies now can be interpreted unambiguously as unavailable without m= agic values
  • If there are gaps in time intervals, it also may be interpreted unambig= uously as no available frequencies
  • Still allows the protocol to exp= ress of full mask where allowed
Thoughts?

-vince


On Thu, Sep 26, 2013 at 3:14 AM, Stine, John A. <jstine@m= itre.org> wrote:

For what it is worth I ha= ve been working on methods to model spectrum use that can be used to give g= uidance to radios. (We have just started to standardize these methods in IEEE 1900.5.2.)=A0 We have two different kinds of guidanc= e, permissive and restrictive.=A0 They are sent in separate lists.=A0 The p= ermissive (aka authorization) list identifies channels a device or system c= an operate and if combined with a restrictive (aka constraint) list then so long as the user does not violate a listed r= estriction.=A0 Each of these lists use spectrum and time at two levels.=A0 = The top level indicates the band and time period the list is comprehensive.= =A0 The second level indicates the particular channels and time periods of availability or restriction.=A0 I would imagi= ne that TVWS would only need the authorization list.=A0 Future applications= where spectrum owners add spectrum to the database and coexistence is mana= ged will require both.

=A0<= /p>

John=

=A0<= /p>

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Gabor.Bajko@nokia.com
Sent: Wednesday, September 25, 2013 6:56 PM
To: tvfool@go= ogle.com; peter@spectrumbridge.com
Cc: paws@ietf.org=


Subject: Re: [paws] Spectrum encoding discussion
=

=A0

-=A0=A0=A0=A0=A0=A0=A0=A0=A0 Gabor<= /span>

From: ext Andy Lee [mailto:tvfool@google.com]
Sent: Wednesday, September 25, 2013 1:57 PM
To: Peter Stanforth
Cc: Paul Lambert; Vincent Chen; Bajko Gabor (Nokia-CIC/SiliconValley= ); paws@ietf.org
Subject: Re: [paws] Spectrum encoding discussion

=A0

Hi Peter,

=A0

I can't = imagine a Regulator allowing a database operator to manipulate the unintent= ional interference in adjacent channels. If it did why stop there? Why couldn't the database manipulate co-channel interference to nearby= protected entities?

=A0

The recent discussions ha= ve been about data encoding and nothing more. =A0The premise is that IF there is some information the database wants to communicate to th= e white space device, HOW is that data encoded into the message.

=A0

As a case in point, secti= on 15.709(c)(1) of the rules clearly defines what the "off" chann= el power limits must be. =A0The rules originally called for a "relativ= e" OOB emission limit, but after some industry discussion, the FCC settled on these "absolute" OOB emission limits instead.= =A0The values are clearly defined, but its not clear whether a database wo= uld want to communicate these parameters to the device or not.

=A0

On one hand, the database= can assume that the device has these values hard-coded into its firmware a= nd therefore does not need to send that information over PAWS.

=A0

On the other hand, these = power levels are part of the TVWS rules and perhaps is something that the d= atabase should communicate to the WSD. =A0There are potentially beneficial = things that a WSD could do with that information if it was provided at run-time (e.g., for future-proofing the device, or c= hoosing operating channels more intelligently).

=A0

=A0

=A0

=A0

=A0

PAWS does not need to = address WHY a particular parameter should or should not be sent over the pr= otocol.=A0 There are many regulatory, business, or technological reason= s why these choices might change, and those decisions are beyond the scope of the protocol itself.=

=A0

However, PAWS can and = should address HOW data gets encoded IF a device or database decides to sen= d it. =A0i.e.,

=A0

IF you want to encode [X]= , then you SHALL use [encoding X]

IF you want to encode [Y]= , then you SHALL use [encoding Y]

etc.

=A0

I can identify at least t= hree distinct concepts that have been discussed so far, which I would categ= orize as follows:

=B7=A0=A0=A0=A0=A0=A0=A0=A0 (i) Explicit "on", Implicit "off= "

o=A0=A0=A0 Anything not explicitly specified as "on&q= uot; would implicitly be treated as "off"

o=A0=A0=A0 The recipient must have apriori knowledge about= how to comply with the "off" channel, "special" channe= l (e.g., channel 37), and "band-edge" protection ratios=

o=A0=A0=A0 There is no distinction between "off"= channels, "special" channels, and "band-edge" constrai= nts in the message itself

o=A0=A0=A0 This requires a way to encode gaps or discontin= uities in the spectrum profile

o=A0=A0=A0 This is equivalent to Gabor's option (a)=

=A0

=B7=A0=A0=A0=A0=A0=A0=A0=A0 (ii)=A0Explicit "on",=A0Explicit &quo= t;off" with no power level given

o=A0=A0=A0 Every channel would be either explicitly "= on" or explicitly "off"

o=A0=A0=A0 Any frequency blocks that are not explicitly &q= uot;on" or explicitly "off" are considered to be "out-o= f-scope" for the current database or ruleset, and this implicitly give= s the "band-edge" boundaries

o=A0=A0=A0 The recipient must have apriori knowledge about= how to comply with the "off" channel, "special" channe= l, and "band-edge" protection ratios

o=A0=A0=A0 The recipient can infer from the message when t= o apply "off" channel constraints and when to apply "band-ed= ge" constraints

o=A0=A0=A0 This requires a way to encode gaps or discontin= uities in the spectrum profile AND requires a way to encode explicit "= off" channels with no specified power value

o=A0=A0=A0 This is equivalent to Gabor's options (c) a= nd (d)

=A0

=B7=A0=A0=A0=A0=A0=A0=A0=A0 (iii)=A0Explicit "on",=A0Explicit &qu= ot;off" with power level given

o=A0=A0=A0 Every channel would be either explicitly "= on" or explicitly "off"

o=A0=A0=A0 Any frequency blocks that are not explicitly &q= uot;on" or explicitly "off" are considered to be "out-o= f-scope" for the current database or ruleset, and this implicitly give= s the "band-edge" boundaries

o=A0=A0=A0 The "off" channel, "special"= ; channel, and "band-edge" protection ratios are explicitly provi= ded in the message, and a device has the option of either using that inform= ation or ignoring it (default back to apriori knowledge of the protection ratios)

o=A0=A0=A0 This requires a way to encode gaps or discontin= uities in the spectrum profile

o=A0=A0=A0 This is equivalent to Gabor's option (b)=

=A0

=A0

I think all three types o= f encoding have their uses, and PAWS should probably allow all three possib= ilities.

=A0

It looks like all three e= ncoding types need a way to express gaps or discontinuities in the spectrum= profile. =A0I think the latest proposal from Vince, using a list of lists,= addresses this problem nicely.

=A0

It also looks like encodi= ngs for (i) and (iii) are logically equivalent, with the only real differen= ce being that encoding (iii) includes more data points in the spectrum prof= ile than encoding (i). =A0I don't think anything else needs to be added to the spec to support both of these encod= ings.

=A0

=A0

=A0

That leaves us with encod= ing (ii), where we need to add something new to the spec to encode explicit= ly "off" frequency blocks that have no power level given. =A0For = this, we have two proposals:

=A0

Option (c): Use -inf as t= he power value in a spectrum profile element

Option (d): Leave the pow= er value blank in a spectrum profile element

=A0

I'd suggest maybe con= sidering yet another proposal:

=A0

Option (e): Use normal en= coding (i) for explicit "on" channels, and then have a separate l= ist of frequency start/stop pairs indicating the authoritative bands for wh= ich the database operates. =A0Anything that is inside the authoritative bands but not in an explicitly "on" chunk is e= ffectively saying it's explicitly "off". =A0Anything outside = of the list of authoritative bands is considered "out-of-scope" f= or the database and this essentially lists the "band-edge" bounda= ries.

=A0

=A0

=A0

Best regards,


=A0

Andy Lee=A0|

=A0Google Inc. |

=A0tvfool@google.com=A0|

=A0408-230-0522

=A0

On Wed, Sep 25, 2013 at 5= :01 AM, Peter Stanforth <peter@spectrumbridge.com> wrote:

=A0Lowering = the power to meet the mask is the easy way you get a radio certified =96 th= us permission to operate. How is that anything to do with the database - which is simply managing Regulator policy?=

The ruleset = is going to tell you what masks and other operating parameters are acceptab= le within a regulatory domain. I can't imagine a Regulator allowing a database operator to manipulate the unintentional interference = in adjacent channels. If it did why stop there? Why couldn't the databa= se manipulate co-channel interference to nearby protected entities?<= u>

I thought we= had a fairly elegant and simple solution. The ruleset defines the box the = device can operate in and the database provides a specific set of permitted channels/frequencies within that box based on the locatio= n, time, and type of device making the request. All with respect to the spe= cific list of entities the database has been told to protect at that locati= on at that time.

=A0

One final co= mment and then I will rest my case. I have had conversations with several R= egulators about this recently, and they do not like any notion that the database is "thinking" about the answer.<= /span>

In every cas= e they have said something along the lines of "if the database does no= t explicitly give a device permission to use a channel the device is not allowed to use it".

In every cas= e they have gone somewhat further stating that if the database operation go= es beyond this simple approach they think it highly unlikely that they will get cooperation from incumbents. If you don't believe m= e =96 go ask them!

Which brings= me back to my soap box. We want to get PAWS done so we can enable white sp= ace. In my humble opinion, the more time we spend pontificating and the more complex we make it we are likely to achieve the opposite.<= /u>

Peter S.<= /u>

=A0

=A0

From: Paul Lambert <paul@marvell.com>
Date: Tuesday, September 24, 2013 2:48 PM
To: Don Joslyn <d.joslyn@spectrumbridge.com>, Vincent Chen <vchen@google.com>, = "gabor.bajk= o@nokia.com" <Gabor.Bajko= @nokia.com>, "paws@ietf.org" <paws@ietf.org>


Subject: Re: [paws] Spectrum encoding discussion

=A0

In line belo= w =85 speaking strongly in favor of "b"=A0

=A0

=A0

Gabor,

=A0

I agree on possible renaming, if we want to specify unavailable channels.

=A0

Please see comments inline.=A0

=A0

On Mon, Sep 23, 2013 at 12:56 PM, <Gabor.Bajko@nokia.com> wrote:

Vince,

This proposal of yours below could potentially b= ecome very confusing. The message itself is named Available Spectrum Reques= t, and you propose the Available Spectrum Response to include a bunch of channels with unspecified power levels, which are btw, = not available channels.

=A0So far, we have 4 proposed ways to indicate u= navailable channels:

a)=A0=A0=A0=A0=A0 Not listing it, implicit unavailability

This has the drawback of not distinguishing between=A0being sile= nt about a channel that is within the database's purview (channel off),= and being silent about a channel that is outside the database's purview (out of scope for given ruleset).

=A0

[DJ =96 Why should the database care about chann= els that are outside the scope of the ruleset specified by the radio? For e= xample, if the specified ruleset is FCC-related, then why would I need to include Ofcom-related channels in the response? Am I missi= ng something?]

=A0

The rules ha= ve strict adjacent channel requirements. =A0Meeting the spectral mask for t= he adjacent channels =A0is one of the hardest parts for fielding real equipment. =A0If the rules allow relative measurement of the adjacent= channel energy, you can simply lower your transmit power to the point that= you can meet the adjacent requirements. =A0

=A0

For a genera= l White Spaces solution =96 it is critical to have knowledge for the full s= pectrum mask. =A0The full spectrum mask includes adjacent non-allowed channels.

=A0

RF channel u= sage are NOT a binary on/off or a simple transmit level. =A0The mask has a = specific contour that extends beyond the "allowed" channel. =A0Transmitters will always send energy in more than the allowed channel!<= u>

=A0

=A0

=A0

Paul<= u>

=A0

=A0

=A0

b)=A0=A0=A0=A0=A0 List unavailable channels and specify the= power limit, eg -56dbm

Since the protocol should stand on its own, independent of any particular r= egulatory rule, do we really want to rule this out? In our interpretations = of the FCC rules, for example, a Database is not prevented from doing this.=

=A0

[DJ =96 I=92m still in favor of just using the i= mplicit unavailability method described above in a). What value is there in= providing a power level for an unavailable channel? If I=92m the radio, I can=92t use the channel, and I=92m not going to intentionally= transmit in that channel. This comment also applies to c) and d).]<= u>

=A0

c)=A0=A0=A0=A0=A0=A0 List unavailable channels and specify =96= inf as power limit

=A0

"-Inf" is not really workable, because JSON does not allow Infini= ty or NaNs (http://tools.ietf.org/html/rfc4627), hence the d) proposal.=

=A0

d)=A0=A0=A0=A0=A0 List unavailable channels and do not spec= ify any power limit=A0

=A0

So far, we have majority in favour of a), few pe= ople who could live or prefer c) and sort of consensus to strike out option= b) from the list above.

=A0

We=92ll wait for more input on the list before d= eclaring rough consensus for the question above; then we=92ll go back to th= e original question on whether the encoding of spectrum profile should be option 1 or option 2.

=A0

p.s. It looks to me, that if we want to specify = unavailable channels, we may need to modify the names of the paws messages = to =91Spectrum schedule=92 or sg along these lines.

=A0

-=A0=A0=A0=A0=A0=A0=A0=A0=A0 Gabor

=A0

=A0

=A0


_______________________________________________
paws mailing list
paws@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/paws

=A0


_______________________________________________
paws mailing list
paws@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/paws




--
-vince
--089e0149c3c02dac9404e752acf0-- From vchen@google.com Thu Sep 26 20:29:30 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7454D11E80ED for ; Thu, 26 Sep 2013 20:29:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.876 X-Spam-Level: X-Spam-Status: No, score=-1.876 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uoou7IFL4kxU for ; Thu, 26 Sep 2013 20:29:28 -0700 (PDT) Received: from mail-oa0-x235.google.com (mail-oa0-x235.google.com [IPv6:2607:f8b0:4003:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id 365AD11E80EF for ; Thu, 26 Sep 2013 20:29:27 -0700 (PDT) Received: by mail-oa0-f53.google.com with SMTP id i7so1649805oag.26 for ; Thu, 26 Sep 2013 20:29:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wCU4PyM1Rbec/fsVFk7y6aKPpSXTOZOFUul4hzsEnzc=; b=V1PIsjSaYFsKRWhl/J+tECWFVRKELVftwg3I7qYcmX5zaeK1uHPqLvqM1bWkT5YyP8 Wn564le6Fh2n8foZjAIQ8KOpEEO9dQ4/rJRgiyZY9o2YUrqsaXOGd1yRtcju1ycE0v7O y+3xKm2h5Ypy8xNYOY2hlOSirAO9sYkNyrvUwAW5bKFxJ43Att4jlvQjjvIVMsJYePbZ TUzPn+HzBqICSRLy742ha1vynPG/8YFy677U9FtJeq7cDqhkTyq2akMlCD34pHVtC02L Oj15UpxVLZilF8caINqH7YZCmIBpSnZRQheONQblZy462+P5q71hgx4pwLJI1rrmyP2O CXeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=wCU4PyM1Rbec/fsVFk7y6aKPpSXTOZOFUul4hzsEnzc=; b=JZlvsuaUUJwRf02gTyBUfVyD81Usph/+0/rA/0jraXBF4VX251kFm8ymGTTy71VNc0 1UF0MQmZ+L0mOFqNs8JEI/ovx2PGI4zuR+0PHWtXXtq8jvbaDKP8GuAUDfvHn0/PRnGK eF9QhQwFkecbEbqOWVMDKx3Q+6A7yWchAW3MS3bAHKuDV0LdctDrjwJQevj7/e7S6itc BdlSX3inp+oa3w0YH0/FaMIKZfP3tCq6roy1QGTy7jzVptHeDoQN7hKYzySw2atkgi4Y FfNp9wRAtWyxIb2SqXbXvVaHsk5vPl5Xrp2cxAS5H+CkvR98vOG83u34lkJfCxI6zzWz mZjg== X-Gm-Message-State: ALoCoQmNxGeI0XeCVKBUOrbMznAps4C7Z7j8Gl2PfEPcqB7nkUyNprZeDQwyYk9Y7sq4m8m5JxHMTcjv2lRd+ZF1Rozfh1ffC4EaoFbR7Fnx+hmKEyLU6mYHdGOoHQ8Eah8WOqkK/9Z2EoNgZe7HAKcUIZjtbNkJ/3bNj0h5k2HDzKgIKz8eUAz5uPqPhOeIiFzbbbCaG0OF MIME-Version: 1.0 X-Received: by 10.182.176.105 with SMTP id ch9mr3842857obc.40.1380252566660; Thu, 26 Sep 2013 20:29:26 -0700 (PDT) Received: by 10.182.250.134 with HTTP; Thu, 26 Sep 2013 20:29:26 -0700 (PDT) In-Reply-To: References: <1ECAFF543A2FED4EA2BEB6CACE08E47605364C49@008-AM1MPN1-006.mgdnok.nokia.com> <2782C93FD2244441893673F3F912819226D27F2C@IMCMBX01.MITRE.ORG> Date: Thu, 26 Sep 2013 20:29:26 -0700 Message-ID: From: Vincent Chen To: "Stine, John A." Content-Type: multipart/alternative; boundary=e89a8ff1bf9aefc0f304e755173a Cc: "paws@ietf.org" Subject: Re: [paws] Spectrum encoding discussion X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 03:29:30 -0000 --e89a8ff1bf9aefc0f304e755173a Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Let me try that example again....missing a nested list segments. Features - Explicit indication of authoritative time ranges and frequency ranges associated with the response - Within a spectrum list, missing frequencies now can be interpreted unambiguously as unavailable without magic values - If there are gaps in time intervals, it also may be interpreted unambiguously as no available frequencies - Still allows the protocol to express of full mask where allowed Example: { "rulesetInfo": { ... }, "timeRange": [ "2013-10-01T00:00:00Z", "2013-10-03T00:00:00Z" ], "frequencyRanges": [ [5.4e7, 7.2e7], // channels 2-4 [7.6e7, 8.8e7], // channels 5-6 [1.74e8, 2.16e8], // channels 7-13 [4.70e8, 6.98e8], // channels 14-51 ], "spectrumSchedules": [ { "time": [ "2013-10-01T00:00:00Z", "2013-10-01T05:00:00Z" ], "spectra" [ { "psdBandwidthHz": 6e6, "segments": [ [ { "freqHz": 4.70e8, "maxPsdDbmPerBw": 30.0 }, // channel 14 { "freqHz": 4.76e8, "maxPsdDbmPerBw": 30.0 } ], [ { "freqHz": 5.18e8, "maxPsdDbmPerBw": 30.0 }, // channel 22 { "freqHz": 5.24e8, "maxPsdDbmPerBw": 30.0 }, { "freqHz": 5.24e8, "maxPsdDbmPerBw": 36.0 }, // channel 23 { "freqHz": 5.30e8, "maxPsdDbmPerBw": 36.0 } ] ] }, { "psdBandwidthHz": 1e5, "segments": [ [ { "freqHz": 4.70e8, "maxPsdDbmPerBw": 27.0 }, // channel 14 { "freqHz": 4.76e8, "maxPsdDbmPerBw": 27.0 } ], [ { "freqHz": 5.18e8, "maxPsdDbmPerBw": 27.0 }, // channel 22 { "freqHz": 5.24e8, "maxPsdDbmPerBw": 27.0 }, { "freqHz": 5.24e8, "maxPsdDbmPerBw": 33.0 }, // channel 23 { "freqHz": 5.30e8, "maxPsdDbmPerBw": 33.0 } ] ] } ] }, { "time": [ "2013-10-01T05:00:00Z", "2013-10-03T00:00:00Z" ], ... }, ... ], ... } On Thu, Sep 26, 2013 at 5:36 PM, Vincent Chen wrote: > John, > > Thanks for your input. It aligns nicely with Andy's suggestion of > specifying "authoritative bands" separately. Taking your suggestion of al= so > expressing "authoritative time range", we could have an encoding example > like the following: > > { > "rulesetInfo": { ... }, > "timeRange": [ "2013-10-01T00:00:00Z", "2013-10-03T00:00:00Z" ], > "frequencyRanges": [ > [5.4e7, 7.2e7], // channels 2-4 > [7.6e7, 8.8e7], // channels 5-6 > [1.74e8, 2.16e8], // channels 7-13 > [4.70e8, 6.98e8], // channels 14-51 > ], > "spectrumSchedules": [ > { > "time": [ "2013-10-01T00:00:00Z", "2013-10-01T05:00:00Z" ], > "spectra" [ > { > "psdBandwidthHz": 6e6, > [ > { "freqHz": 4.70e8, "maxPsdDbmPerBw": 30.0 }, // channel 14 > { "freqHz": 4.76e8, "maxPsdDbmPerBw": 30.0 }, > { "freqHz": 5.18e8, "maxPsdDbmPerBw": 30.0 }, // channel 22 > { "freqHz": 5.24e8, "maxPsdDbmPerBw": 30.0 }, > { "freqHz": 5.24e8, "maxPsdDbmPerBw": 36.0 }, // channel 23 > { "freqHz": 5.30e8, "maxPsdDbmPerBw": 36.0 } > ] > }, > { > "psdBandwidthHz": 1e5, > [ > { "freqHz": 4.70e8, "maxPsdDbmPerBw": 27.0 }, // channel 14 > { "freqHz": 4.76e8, "maxPsdDbmPerBw": 27.0 }, > { "freqHz": 5.18e8, "maxPsdDbmPerBw": 27.0 }, // channel 22 > { "freqHz": 5.24e8, "maxPsdDbmPerBw": 27.0 }, > { "freqHz": 5.24e8, "maxPsdDbmPerBw": 33.0 }, // channel 23 > { "freqHz": 5.30e8, "maxPsdDbmPerBw": 33.0 } > ] > } > ] > }, > { > "time": [ "2013-10-01T05:00:00Z", "2013-10-03T00:00:00Z" ], > ... > }, > ... > ], > ... > } > > Features > > - Explicit indication of authoritative time ranges and frequency > ranges associated with the response > - Within a spectrum list, missing frequencies now can be interpreted > unambiguously as unavailable without magic values > - If there are gaps in time intervals, it also may be interpreted > unambiguously as no available frequencies > - Still allows the protocol to express of full mask where allowed > > Thoughts? > > -vince > > > On Thu, Sep 26, 2013 at 3:14 AM, Stine, John A. wrote: > >> For what it is worth I have been working on methods to model spectrum >> use that can be used to give guidance to radios. (We have just started t= o >> standardize these methods in IEEE 1900.5.2.) We have two different kind= s >> of guidance, permissive and restrictive. They are sent in separate list= s. >> The permissive (aka authorization) list identifies channels a device or >> system can operate and if combined with a restrictive (aka constraint) l= ist >> then so long as the user does not violate a listed restriction. Each of >> these lists use spectrum and time at two levels. The top level indicate= s >> the band and time period the list is comprehensive. The second level >> indicates the particular channels and time periods of availability or >> restriction. I would imagine that TVWS would only need the authorizatio= n >> list. Future applications where spectrum owners add spectrum to the >> database and coexistence is managed will require both.**** >> >> ** ** >> >> John**** >> >> ** ** >> >> *From:* paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] *On Behalf >> Of *Gabor.Bajko@nokia.com >> *Sent:* Wednesday, September 25, 2013 6:56 PM >> *To:* tvfool@google.com; peter@spectrumbridge.com >> *Cc:* paws@ietf.org >> >> *Subject:* Re: [paws] Spectrum encoding discussion**** >> >> ** ** >> >> Andy,**** >> >> ** ** >> >> This option (e) proposal sounds like you may want to encode two things >> which could be separated; the available channels, and the authoritative >> bands.**** >> >> We could leave the available spectrum req/resp unchanged, and eg have a >> separate req/resp for the authoritative bands. **** >> >> And we could also encode the power leakage limits eg inside the ruleset >> info, so that devices would not necessarily need to be hard-coded with >> those, to satisfy everyone.**** >> >> Could this be an agreeable way forward?**** >> >> ** ** >> >> **- **Gabor**** >> >> ** ** >> >> *From:* ext Andy Lee [mailto:tvfool@google.com ] >> *Sent:* Wednesday, September 25, 2013 1:57 PM >> *To:* Peter Stanforth >> *Cc:* Paul Lambert; Vincent Chen; Bajko Gabor (Nokia-CIC/SiliconValley); >> paws@ietf.org >> *Subject:* Re: [paws] Spectrum encoding discussion**** >> >> ** ** >> >> Hi Peter,**** >> >> **** >> >> I can't imagine a Regulator allowing a database operator to manipulate >> the unintentional interference in adjacent channels. If it did why stop >> there? Why couldn't the database manipulate co-channel interference to >> nearby protected entities?**** >> >> ** ** >> >> The recent discussions have been about data encoding and nothing more. >> The premise is that *IF* there is some information the database wants >> to communicate to the white space device, *HOW* is that data encoded >> into the message.**** >> >> ** ** >> >> As a case in point, section 15.709(c)(1) of the rules clearly defines >> what the "off" channel power limits must be. The rules originally calle= d >> for a "relative" OOB emission limit, but after some industry discussion, >> the FCC settled on these "absolute" OOB emission limits instead. The >> values are clearly defined, but its not clear whether a database would w= ant >> to communicate these parameters to the device or not.**** >> >> ** ** >> >> On one hand, the database can assume that the device has these values >> hard-coded into its firmware and therefore does not need to send that >> information over PAWS.**** >> >> ** ** >> >> On the other hand, these power levels are part of the TVWS rules and >> perhaps is something that the database should communicate to the WSD. >> There are potentially beneficial things that a WSD could do with that >> information if it was provided at run-time (e.g., for future-proofing th= e >> device, or choosing operating channels more intelligently).**** >> >> ** ** >> >> ** ** >> >> ** ** >> >> ** ** >> >> ** ** >> >> *PAWS does not need to address WHY a particular parameter should or >> should not be sent over the protocol.* There are many regulatory, >> business, or technological reasons why these choices might change, and >> those decisions are beyond the scope of the protocol itself.**** >> >> ** ** >> >> However, *PAWS can and should address HOW data gets encoded IF a device >> or database decides to send it.* i.e.,**** >> >> ** ** >> >> IF you want to encode [X], then you SHALL use [encoding X]**** >> >> IF you want to encode [Y], then you SHALL use [encoding Y]**** >> >> etc.**** >> >> ** ** >> >> I can identify at least three distinct concepts that have been discussed >> so far, which I would categorize as follows:**** >> >> **=B7 **(i) Explicit "on", Implicit "off"**** >> >> **o **Anything not explicitly specified as "on" would implicitly be >> treated as "off"**** >> >> **o **The recipient must have apriori knowledge about how to comply >> with the "off" channel, "special" channel (e.g., channel 37), and >> "band-edge" protection ratios**** >> >> **o **There is no distinction between "off" channels, "special" >> channels, and "band-edge" constraints in the message itself**** >> >> **o **This requires a way to encode gaps or discontinuities in the >> spectrum profile**** >> >> **o **This is equivalent to Gabor's option (a)**** >> >> ** ** >> >> **=B7 **(ii) Explicit "on", Explicit "off" with no power level >> given**** >> >> **o **Every channel would be either explicitly "on" or explicitly >> "off"**** >> >> **o **Any frequency blocks that are not explicitly "on" or explicitly >> "off" are considered to be "out-of-scope" for the current database or >> ruleset, and this implicitly gives the "band-edge" boundaries**** >> >> **o **The recipient must have apriori knowledge about how to comply >> with the "off" channel, "special" channel, and "band-edge" protection ra= tios >> **** >> >> **o **The recipient can infer from the message when to apply "off" >> channel constraints and when to apply "band-edge" constraints**** >> >> **o **This requires a way to encode gaps or discontinuities in the >> spectrum profile AND requires a way to encode explicit "off" channels wi= th >> no specified power value**** >> >> **o **This is equivalent to Gabor's options (c) and (d)**** >> >> ** ** >> >> **=B7 **(iii) Explicit "on", Explicit "off" with power level giv= en* >> *** >> >> **o **Every channel would be either explicitly "on" or explicitly >> "off"**** >> >> **o **Any frequency blocks that are not explicitly "on" or explicitly >> "off" are considered to be "out-of-scope" for the current database or >> ruleset, and this implicitly gives the "band-edge" boundaries**** >> >> **o **The "off" channel, "special" channel, and "band-edge" >> protection ratios are explicitly provided in the message, and a device h= as >> the option of either using that information or ignoring it (default back= to >> apriori knowledge of the protection ratios)**** >> >> **o **This requires a way to encode gaps or discontinuities in the >> spectrum profile**** >> >> **o **This is equivalent to Gabor's option (b)**** >> >> ** ** >> >> ** ** >> >> I think all three types of encoding have their uses, and PAWS should >> probably allow all three possibilities.**** >> >> ** ** >> >> It looks like all three encoding types need a way to express gaps or >> discontinuities in the spectrum profile. I think the latest proposal fr= om >> Vince, using a list of lists, addresses this problem nicely.**** >> >> ** ** >> >> It also looks like encodings for (i) and (iii) are logically equivalent, >> with the only real difference being that encoding (iii) includes more da= ta >> points in the spectrum profile than encoding (i). I don't think anythin= g >> else needs to be added to the spec to support both of these encodings.**= * >> * >> >> ** ** >> >> ** ** >> >> ** ** >> >> That leaves us with encoding (ii), where we need to add something new to >> the spec to encode explicitly "off" frequency blocks that have no power >> level given. For this, we have two proposals:**** >> >> ** ** >> >> Option (c): Use -inf as the power value in a spectrum profile element***= * >> >> Option (d): Leave the power value blank in a spectrum profile element***= * >> >> ** ** >> >> I'd suggest maybe considering yet another proposal:**** >> >> ** ** >> >> Option (e): Use normal encoding (i) for explicit "on" channels, and then >> have a separate list of frequency start/stop pairs indicating the >> authoritative bands for which the database operates. Anything that is >> inside the authoritative bands but not in an explicitly "on" chunk is >> effectively saying it's explicitly "off". Anything outside of the list = of >> authoritative bands is considered "out-of-scope" for the database and th= is >> essentially lists the "band-edge" boundaries.**** >> >> ** ** >> >> ** ** >> >> ** ** >> >> Best regards,**** >> >> >> **** >> >> ** ** >> >> Andy Lee |**** >> >> Google Inc. |**** >> >> tvfool@google.com |**** >> >> 408-230-0522**** >> >> ** ** >> >> On Wed, Sep 25, 2013 at 5:01 AM, Peter Stanforth < >> peter@spectrumbridge.com> wrote:**** >> >> Lowering the power to meet the mask is the easy way you get a radio >> certified =96 thus permission to operate. How is that anything to do wit= h the >> database - which is simply managing Regulator policy?**** >> >> The ruleset is going to tell you what masks and other operating >> parameters are acceptable within a regulatory domain. I can't imagine a >> Regulator allowing a database operator to manipulate the unintentional >> interference in adjacent channels. If it did why stop there? Why couldn'= t >> the database manipulate co-channel interference to nearby protected >> entities?**** >> >> I thought we had a fairly elegant and simple solution. The ruleset >> defines the box the device can operate in and the database provides a >> specific set of permitted channels/frequencies within that box based on = the >> location, time, and type of device making the request. All with respect = to >> the specific list of entities the database has been told to protect at t= hat >> location at that time.**** >> >> ** ** >> >> One final comment and then I will rest my case. I have had conversations >> with several Regulators about this recently, and they do not like any >> notion that the database is "thinking" about the answer.**** >> >> In every case they have said something along the lines of "if the >> database does not explicitly give a device permission to use a channel t= he >> device is not allowed to use it".**** >> >> In every case they have gone somewhat further stating that if the >> database operation goes beyond this simple approach they think it highly >> unlikely that they will get cooperation from incumbents. If you don't >> believe me =96 go ask them!**** >> >> Which brings me back to my soap box. We want to get PAWS done so we can >> enable white space. In my humble opinion, the more time we spend >> pontificating and the more complex we make it we are likely to achieve t= he >> opposite.**** >> >> Peter S.**** >> >> ** ** >> >> ** ** >> >> *From: *Paul Lambert >> *Date: *Tuesday, September 24, 2013 2:48 PM >> *To: *Don Joslyn , Vincent Chen < >> vchen@google.com>, "gabor.bajko@nokia.com" , " >> paws@ietf.org" **** >> >> >> *Subject: *Re: [paws] Spectrum encoding discussion**** >> >> ** ** >> >> In line below =85 speaking strongly in favor of "b" **** >> >> ** ** >> >> ** ** >> >> Gabor,**** >> >> **** >> >> I agree on possible renaming, if we want to specify unavailable channels= . >> **** >> >> **** >> >> Please see comments inline. **** >> >> **** >> >> On Mon, Sep 23, 2013 at 12:56 PM, wrote:**** >> >> Vince,**** >> >> This proposal of yours below could potentially become very confusing. Th= e >> message itself is named Available Spectrum Request, and you propose the >> Available Spectrum Response to include a bunch of channels with unspecif= ied >> power levels, which are btw, not available channels. **** >> >> So far, we have 4 proposed ways to indicate unavailable channels:**** >> >> a) Not listing it, implicit unavailability**** >> >> This has the drawback of not distinguishing between being silent about a >> channel that is within the database's purview (channel off), and being >> silent about a channel that is outside the database's purview (out of sc= ope >> for given ruleset).**** >> >> **** >> >> [DJ =96 Why should the database care about channels that are outside the >> scope of the ruleset specified by the radio? For example, if the specifi= ed >> ruleset is FCC-related, then why would I need to include Ofcom-related >> channels in the response? Am I missing something?]**** >> >> ** ** >> >> The rules have strict adjacent channel requirements. Meeting the >> spectral mask for the adjacent channels is one of the hardest parts for >> fielding real equipment. If the rules allow relative measurement of the >> adjacent channel energy, you can simply lower your transmit power to the >> point that you can meet the adjacent requirements. **** >> >> ** ** >> >> For a general White Spaces solution =96 it is critical to have knowledge >> for the full spectrum mask. The full spectrum mask includes adjacent >> non-allowed channels.**** >> >> ** ** >> >> RF channel usage are NOT a binary on/off or a simple transmit level. Th= e >> mask has a specific contour that extends beyond the "allowed" channel. >> Transmitters will always send energy in more than the allowed channel!*= * >> ** >> >> ** ** >> >> ** ** >> >> ** ** >> >> Paul**** >> >> ** ** >> >> ** ** >> >> **** >> >> b) List unavailable channels and specify the power limit, eg -56db= m >> **** >> >> Since the protocol should stand on its own, independent of any >> particular regulatory rule, do we really want to rule this out? In our >> interpretations of the FCC rules, for example, a Database is not prevent= ed >> from doing this.**** >> >> **** >> >> [DJ =96 I=92m still in favor of just using the implicit unavailability m= ethod >> described above in a). What value is there in providing a power level fo= r >> an unavailable channel? If I=92m the radio, I can=92t use the channel, a= nd I=92m >> not going to intentionally transmit in that channel. This comment also >> applies to c) and d).]**** >> >> **** >> >> c) List unavailable channels and specify =96inf as power limit***= * >> >> **** >> >> "-Inf" is not really workable, because JSON does not allow Infinity or >> NaNs (http://tools.ietf.org/html/rfc4627), hence the d) proposal.**** >> >> **** >> >> d) List unavailable channels and do not specify any power limit **= * >> * >> >> **** >> >> So far, we have majority in favour of a), few people who could live or >> prefer c) and sort of consensus to strike out option b) from the list ab= ove. >> **** >> >> **** >> >> We=92ll wait for more input on the list before declaring rough consensus >> for the question above; then we=92ll go back to the original question on >> whether the encoding of spectrum profile should be option 1 or option 2.= * >> *** >> >> **** >> >> p.s. It looks to me, that if we want to specify unavailable channels, we >> may need to modify the names of the paws messages to =91Spectrum schedul= e=92 or >> sg along these lines.**** >> >> **** >> >> - Gabor**** >> >> **** >> >> ** ** >> >> ** ** >> >> >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws**** >> >> ** ** >> >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws >> >> > > > -- > -vince > --=20 -vince --e89a8ff1bf9aefc0f304e755173a Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Let me try that example again....missing a nested list seg= ments.

Features
  • Explicit indication of authoritative tim= e ranges and frequency ranges associated with the response
  • Within a spectrum list, missing frequencies now can be i= nterpreted unambiguously as unavailable without magic values
  • If there are gaps in time intervals, it also= may be interpreted unambiguously as no available frequencies
  • Still allows the protocol to express of full mask whe= re allowed
Example:

{
=A0 "rule= setInfo": { ... },
=A0 "timeRange": [ "2013-1= 0-01T00:00:00Z", "2013-10-03T00:00:00Z" ],
=A0 &qu= ot;frequencyRanges": [
=A0 =A0 [5.4e7, 7.2e7], =A0 // channels 2-4
=A0 =A0 [7.6e7, = 8.8e7], =A0 // channels 5-6
=A0 =A0 [1.74e8, 2.16e8], // channels= 7-13
=A0 =A0 [4.70e8, 6.98e8], // channels 14-51
=A0 ]= ,
=A0 "spectrumSchedules": [
=A0 =A0 {
=A0 =A0 =A0 "time": [ "2013-10-01T0= 0:00:00Z", "2013-10-01T05:00:00Z" ],
=A0 =A0 =A0 &= quot;spectra" [
=A0 =A0 =A0 =A0{
=A0 =A0 =A0 =A0 = =A0"psdBandwidthHz": 6e6,
=A0 =A0 =A0 =A0 =A0"segments": [
=A0 =A0 =A0 =A0 = =A0 =A0[
=A0 =A0 =A0 =A0 =A0 =A0 { "freqHz": 4.70e8, &q= uot;maxPsdDbmPerBw": 30.0 }, =A0// channel 14
=A0 =A0 =A0 = =A0 =A0 =A0 { "freqHz": 4.76e8, "maxPsdDbmPerBw": 30.0 = }
=A0 =A0 =A0 =A0 =A0 =A0],
=A0 =A0 =A0 =A0 =A0 =A0[
=A0 =A0 =A0 =A0 =A0 =A0 { "freqHz": 5.18e8, "maxPsdDbmPerBw= ": 30.0 }, =A0// channel 22
=A0 =A0 =A0 =A0 =A0 =A0 { "= freqHz": 5.24e8, "maxPsdDbmPerBw": 30.0 },
=A0 =A0 =A0 =A0 =A0 =A0 { "freqHz": 5.24e8, "maxPsdDbmP= erBw": 36.0 }, =A0// channel 23
=A0 =A0 =A0 =A0 =A0 =A0 { &q= uot;freqHz": 5.30e8, "maxPsdDbmPerBw": 36.0 }
=A0 = =A0 =A0 =A0 =A0 =A0]
=A0 =A0 =A0 =A0 =A0]
=A0 =A0 =A0 =A0},
=A0 =A0 =A0 =A0{
=A0 =A0 =A0 =A0= =A0"psdBandwidthHz": 1e5,
=A0 =A0 =A0 =A0 =A0"seg= ments": [
=A0 =A0 =A0 =A0 =A0 =A0[
=A0 =A0 =A0 =A0= =A0 =A0 { "freqHz": 4.70e8, "maxPsdDbmPerBw": 27.0 }, = =A0// channel 14
=A0 =A0 =A0 =A0 =A0 =A0 { "freqHz": 4.76e8, "maxPsdDbmP= erBw": 27.0 }
=A0 =A0 =A0 =A0 =A0 =A0],
=A0 =A0 = =A0 =A0 =A0 =A0[
=A0 =A0 =A0 =A0 =A0 =A0 { "freqHz": 5.= 18e8, "maxPsdDbmPerBw": 27.0 }, =A0// channel 22
=A0 =A0 =A0 =A0 =A0 =A0 { "freqHz": 5.24e8, "maxPsdDbmP= erBw": 27.0 },
=A0 =A0 =A0 =A0 =A0 =A0 { "freqHz":= 5.24e8, "maxPsdDbmPerBw": 33.0 }, =A0// channel 23
=A0= =A0 =A0 =A0 =A0 =A0 { "freqHz": 5.30e8, "maxPsdDbmPerBw&quo= t;: 33.0 }
=A0 =A0 =A0 =A0 =A0 =A0]
=A0 =A0 =A0 =A0 =A0]
=A0 = =A0 =A0 =A0}
=A0 =A0 =A0 ]
=A0 =A0 },
=A0 =A0= {
=A0 =A0 =A0 "time": [ "2013-10-01T05:00:00Z&quo= t;, "2013-10-03T00:00:00Z" ],
=A0 =A0 =A0 ...
=A0 =A0 },
=A0 =A0 ...
=A0 ],=
=A0 ...
}

=


On Thu, Sep 2= 6, 2013 at 5:36 PM, Vincent Chen <vchen@google.com> wrote:
John,

Th= anks for your input. It aligns nicely with Andy's suggestion of specify= ing "authoritative bands" separately. Taking your suggestion of a= lso expressing "authoritative time range", we could have an encod= ing example like the following:

{
=A0 "rulesetInfo": { ... },<= /div>
=A0 "timeRange": [ "2013-10-01T00:00:00Z", &q= uot;2013-10-03T00:00:00Z" ],
=A0 "frequencyRanges"= : [
=A0 =A0 [5.4e7, 7.2e7], =A0 // channels 2-4
=A0 =A0 [7.6e7, = 8.8e7], =A0 // channels 5-6
=A0 =A0 [1.74e8, 2.16e8], // channels= 7-13
=A0 =A0 [4.70e8, 6.98e8], // channels 14-51
=A0 ]= ,
=A0 "spectrumSchedules": [
=A0 =A0 {
=A0 =A0 =A0 "time": [ "2013-10-01T0= 0:00:00Z", "2013-10-01T05:00:00Z" ],
=A0 =A0 =A0 &= quot;spectra" [
=A0 =A0 =A0 =A0{
=A0 =A0 =A0 =A0 = =A0"psdBandwidthHz": 6e6,
=A0 =A0 =A0 =A0 =A0[
=A0 =A0 =A0 =A0 =A0 { "freqHz"= ;: 4.70e8, "maxPsdDbmPerBw": 30.0 }, =A0// channel 14
= =A0 =A0 =A0 =A0 =A0 { "freqHz": 4.76e8, "maxPsdDbmPerBw"= ;: 30.0 },
=A0 =A0 =A0 =A0 =A0 { "freqHz": 5.18e8, "maxPsdDbmPerBw= ": 30.0 }, =A0// channel 22
=A0 =A0 =A0 =A0 =A0 { "freqHz": 5.24e8, "maxPsdDbmPerBw= ": 30.0 },
=A0 =A0 =A0 =A0 =A0 { "freqHz": 5.24e8,= "maxPsdDbmPerBw": 36.0 }, =A0// channel 23
=A0 =A0 =A0= =A0 =A0 { "freqHz": 5.30e8, "maxPsdDbmPerBw": 36.0 }
=A0 =A0 =A0 =A0 =A0]
=A0 =A0 =A0 =A0},
=A0 =A0 =A0= =A0{
=A0 =A0 =A0 =A0 =A0"psdBandwidthHz": 1e5,
=A0 =A0 =A0 =A0 =A0[
=A0 =A0 =A0 =A0 =A0 { "freqHz&= quot;: 4.70e8, "maxPsdDbmPerBw": 27.0 }, =A0// channel 14
=A0 =A0 =A0 =A0 =A0 { "freqHz": 4.76e8, "maxPsdDbmPerBw= ": 27.0 },
=A0 =A0 =A0 =A0 =A0 { "freqHz": 5.18e8,= "maxPsdDbmPerBw": 27.0 }, =A0// channel 22
=A0 =A0 =A0 =A0 =A0 { "freqHz": 5.24e8, "maxPsdDbmPer= Bw": 27.0 },
=A0 =A0 =A0 =A0 =A0 { "freqHz": 5.24e8, "maxPsdDb= mPerBw": 33.0 }, =A0// channel 23
=A0 =A0 =A0 =A0 =A0 { &quo= t;freqHz": 5.30e8, "maxPsdDbmPerBw": 33.0 }
=A0 = =A0 =A0 =A0 =A0]
=A0 =A0 =A0 =A0}
=A0 =A0 =A0 ]
=A0 =A0 },
=A0 =A0 {
=A0 = =A0 =A0 "time": [ "2013-10-01T05:00:00Z", "2013-10= -03T00:00:00Z" ],
=A0 =A0 =A0 ...
=A0 =A0 },
=
=A0 =A0 ...
=A0 ],
=A0 ...
}

Features
=
  • Explicit indication of authoritative time ranges and frequency= ranges associated with the response
  • Within a spectrum list, missin= g frequencies now can be interpreted unambiguously as unavailable without m= agic values
  • If there are gaps in time intervals, it also may be interpreted unambig= uously as no available frequencies
  • Still allows the protocol to exp= ress of full mask where allowed
Thoughts?

-vince


On Thu, Sep 26, 2013 at 3:14 AM, Sti= ne, John A. <jstine@mitre.org> wrote:

For what it is worth I ha= ve been working on methods to model spectrum use that can be used to give g= uidance to radios. (We have just started to standardize these methods in IEEE 1900.5.2.)=A0 We have two different kinds of guidanc= e, permissive and restrictive.=A0 They are sent in separate lists.=A0 The p= ermissive (aka authorization) list identifies channels a device or system c= an operate and if combined with a restrictive (aka constraint) list then so long as the user does not violate a listed r= estriction.=A0 Each of these lists use spectrum and time at two levels.=A0 = The top level indicates the band and time period the list is comprehensive.= =A0 The second level indicates the particular channels and time periods of availability or restriction.=A0 I would imagi= ne that TVWS would only need the authorization list.=A0 Future applications= where spectrum owners add spectrum to the database and coexistence is mana= ged will require both.

=A0<= /p>

John=

=A0<= /p>

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Gabor.Bajko@nokia.com
Sent: Wednesday, September 25, 2013 6:56 PM
To: tvfool@go= ogle.com; peter@spectrumbridge.com
Cc: paws@ietf.org=


Subject: Re: [paws] Spectrum encoding discussion
=

=A0

-=A0=A0=A0=A0=A0=A0=A0=A0=A0 Gabor<= /span>

From: ext Andy Lee [mailto:tvfool@google.com]
Sent: Wednesday, September 25, 2013 1:57 PM
To: Peter Stanforth
Cc: Paul Lambert; Vincent Chen; Bajko Gabor (Nokia-CIC/SiliconValley= ); paws@ietf.org
Subject: Re: [paws] Spectrum encoding discussion

=A0

Hi Peter,

=A0

I can't = imagine a Regulator allowing a database operator to manipulate the unintent= ional interference in adjacent channels. If it did why stop there? Why couldn't the database manipulate co-channel interference to nearby= protected entities?

=A0

The recent discussions ha= ve been about data encoding and nothing more. =A0The premise is that IF there is some information the database wants to communicate to th= e white space device, HOW is that data encoded into the message.

=A0

As a case in point, secti= on 15.709(c)(1) of the rules clearly defines what the "off" chann= el power limits must be. =A0The rules originally called for a "relativ= e" OOB emission limit, but after some industry discussion, the FCC settled on these "absolute" OOB emission limits instead.= =A0The values are clearly defined, but its not clear whether a database wo= uld want to communicate these parameters to the device or not.

=A0

On one hand, the database= can assume that the device has these values hard-coded into its firmware a= nd therefore does not need to send that information over PAWS.

=A0

On the other hand, these = power levels are part of the TVWS rules and perhaps is something that the d= atabase should communicate to the WSD. =A0There are potentially beneficial = things that a WSD could do with that information if it was provided at run-time (e.g., for future-proofing the device, or c= hoosing operating channels more intelligently).

=A0

=A0

=A0

=A0

=A0

PAWS does not need to = address WHY a particular parameter should or should not be sent over the pr= otocol.=A0 There are many regulatory, business, or technological reason= s why these choices might change, and those decisions are beyond the scope of the protocol itself.=

=A0

However, PAWS can and = should address HOW data gets encoded IF a device or database decides to sen= d it. =A0i.e.,

=A0

IF you want to encode [X]= , then you SHALL use [encoding X]

IF you want to encode [Y]= , then you SHALL use [encoding Y]

etc.

=A0

I can identify at least t= hree distinct concepts that have been discussed so far, which I would categ= orize as follows:

=B7=A0=A0=A0=A0=A0=A0=A0=A0 (i) Explicit "on", Implicit "off= "

o=A0=A0=A0 Anything not explicitly specified as "on&q= uot; would implicitly be treated as "off"

o=A0=A0=A0 The recipient must have apriori knowledge about= how to comply with the "off" channel, "special" channe= l (e.g., channel 37), and "band-edge" protection ratios=

o=A0=A0=A0 There is no distinction between "off"= channels, "special" channels, and "band-edge" constrai= nts in the message itself

o=A0=A0=A0 This requires a way to encode gaps or discontin= uities in the spectrum profile

o=A0=A0=A0 This is equivalent to Gabor's option (a)=

=A0

=B7=A0=A0=A0=A0=A0=A0=A0=A0 (ii)=A0Explicit "on",=A0Explicit &quo= t;off" with no power level given

o=A0=A0=A0 Every channel would be either explicitly "= on" or explicitly "off"

o=A0=A0=A0 Any frequency blocks that are not explicitly &q= uot;on" or explicitly "off" are considered to be "out-o= f-scope" for the current database or ruleset, and this implicitly give= s the "band-edge" boundaries

o=A0=A0=A0 The recipient must have apriori knowledge about= how to comply with the "off" channel, "special" channe= l, and "band-edge" protection ratios

o=A0=A0=A0 The recipient can infer from the message when t= o apply "off" channel constraints and when to apply "band-ed= ge" constraints

o=A0=A0=A0 This requires a way to encode gaps or discontin= uities in the spectrum profile AND requires a way to encode explicit "= off" channels with no specified power value

o=A0=A0=A0 This is equivalent to Gabor's options (c) a= nd (d)

=A0

=B7=A0=A0=A0=A0=A0=A0=A0=A0 (iii)=A0Explicit "on",=A0Explicit &qu= ot;off" with power level given

o=A0=A0=A0 Every channel would be either explicitly "= on" or explicitly "off"

o=A0=A0=A0 Any frequency blocks that are not explicitly &q= uot;on" or explicitly "off" are considered to be "out-o= f-scope" for the current database or ruleset, and this implicitly give= s the "band-edge" boundaries

o=A0=A0=A0 The "off" channel, "special"= ; channel, and "band-edge" protection ratios are explicitly provi= ded in the message, and a device has the option of either using that inform= ation or ignoring it (default back to apriori knowledge of the protection ratios)

o=A0=A0=A0 This requires a way to encode gaps or discontin= uities in the spectrum profile

o=A0=A0=A0 This is equivalent to Gabor's option (b)=

=A0

=A0

I think all three types o= f encoding have their uses, and PAWS should probably allow all three possib= ilities.

=A0

It looks like all three e= ncoding types need a way to express gaps or discontinuities in the spectrum= profile. =A0I think the latest proposal from Vince, using a list of lists,= addresses this problem nicely.

=A0

It also looks like encodi= ngs for (i) and (iii) are logically equivalent, with the only real differen= ce being that encoding (iii) includes more data points in the spectrum prof= ile than encoding (i). =A0I don't think anything else needs to be added to the spec to support both of these encod= ings.

=A0

=A0

=A0

That leaves us with encod= ing (ii), where we need to add something new to the spec to encode explicit= ly "off" frequency blocks that have no power level given. =A0For = this, we have two proposals:

=A0

Option (c): Use -inf as t= he power value in a spectrum profile element

Option (d): Leave the pow= er value blank in a spectrum profile element

=A0

I'd suggest maybe con= sidering yet another proposal:

=A0

Option (e): Use normal en= coding (i) for explicit "on" channels, and then have a separate l= ist of frequency start/stop pairs indicating the authoritative bands for wh= ich the database operates. =A0Anything that is inside the authoritative bands but not in an explicitly "on" chunk is e= ffectively saying it's explicitly "off". =A0Anything outside = of the list of authoritative bands is considered "out-of-scope" f= or the database and this essentially lists the "band-edge" bounda= ries.

=A0

=A0

=A0

Best regards,


=A0

Andy Lee=A0|

=A0Google Inc. |

=A0tvfool@google.com=A0|

=A0408-230-0522

=A0

On Wed, Sep 25, 2013 at 5= :01 AM, Peter Stanforth <peter@spectrumbridge.com> wrote:

=A0Lowering = the power to meet the mask is the easy way you get a radio certified =96 th= us permission to operate. How is that anything to do with the database - which is simply managing Regulator policy?=

The ruleset = is going to tell you what masks and other operating parameters are acceptab= le within a regulatory domain. I can't imagine a Regulator allowing a database operator to manipulate the unintentional interference = in adjacent channels. If it did why stop there? Why couldn't the databa= se manipulate co-channel interference to nearby protected entities?<= u>

I thought we= had a fairly elegant and simple solution. The ruleset defines the box the = device can operate in and the database provides a specific set of permitted channels/frequencies within that box based on the locatio= n, time, and type of device making the request. All with respect to the spe= cific list of entities the database has been told to protect at that locati= on at that time.

=A0

One final co= mment and then I will rest my case. I have had conversations with several R= egulators about this recently, and they do not like any notion that the database is "thinking" about the answer.<= /span>

In every cas= e they have said something along the lines of "if the database does no= t explicitly give a device permission to use a channel the device is not allowed to use it".

In every cas= e they have gone somewhat further stating that if the database operation go= es beyond this simple approach they think it highly unlikely that they will get cooperation from incumbents. If you don't believe m= e =96 go ask them!

Which brings= me back to my soap box. We want to get PAWS done so we can enable white sp= ace. In my humble opinion, the more time we spend pontificating and the more complex we make it we are likely to achieve the opposite.<= /u>

Peter S.<= /u>

=A0

=A0

From: Paul Lambert <paul@marvell.com>
Date: Tuesday, September 24, 2013 2:48 PM
To: Don Joslyn <d.joslyn@spectrumbridge.com>, Vincent Chen <vchen@google.com>, = "gabor.bajk= o@nokia.com" <Gabor.Bajko= @nokia.com>, "paws@ietf.org" <paws@ietf.org>


Subject: Re: [paws] Spectrum encoding discussion

=A0

In line belo= w =85 speaking strongly in favor of "b"=A0

=A0

=A0

Gabor,

=A0

I agree on possible renaming, if we want to specify unavailable channels.

=A0

Please see comments inline.=A0

=A0

On Mon, Sep 23, 2013 at 12:56 PM, <Gabor.Bajko@nokia.com> wrote:

Vince,

This proposal of yours below could potentially b= ecome very confusing. The message itself is named Available Spectrum Reques= t, and you propose the Available Spectrum Response to include a bunch of channels with unspecified power levels, which are btw, = not available channels.

=A0So far, we have 4 proposed ways to indicate u= navailable channels:

a)=A0=A0=A0=A0=A0 Not listing it, implicit unavailability

This has the drawback of not distinguishing between=A0being sile= nt about a channel that is within the database's purview (channel off),= and being silent about a channel that is outside the database's purview (out of scope for given ruleset).

=A0

[DJ =96 Why should the database care about chann= els that are outside the scope of the ruleset specified by the radio? For e= xample, if the specified ruleset is FCC-related, then why would I need to include Ofcom-related channels in the response? Am I missi= ng something?]

=A0

The rules ha= ve strict adjacent channel requirements. =A0Meeting the spectral mask for t= he adjacent channels =A0is one of the hardest parts for fielding real equipment. =A0If the rules allow relative measurement of the adjacent= channel energy, you can simply lower your transmit power to the point that= you can meet the adjacent requirements. =A0

=A0

For a genera= l White Spaces solution =96 it is critical to have knowledge for the full s= pectrum mask. =A0The full spectrum mask includes adjacent non-allowed channels.

=A0

RF channel u= sage are NOT a binary on/off or a simple transmit level. =A0The mask has a = specific contour that extends beyond the "allowed" channel. =A0Transmitters will always send energy in more than the allowed channel!<= u>

=A0

=A0

=A0

Paul<= u>

=A0

=A0

=A0

b)=A0=A0=A0=A0=A0 List unavailable channels and specify the= power limit, eg -56dbm

Since the protocol should stand on its own, independent of any particular r= egulatory rule, do we really want to rule this out? In our interpretations = of the FCC rules, for example, a Database is not prevented from doing this.=

=A0

[DJ =96 I=92m still in favor of just using the i= mplicit unavailability method described above in a). What value is there in= providing a power level for an unavailable channel? If I=92m the radio, I can=92t use the channel, and I=92m not going to intentionally= transmit in that channel. This comment also applies to c) and d).]<= u>

=A0

c)=A0=A0=A0=A0=A0=A0 List unavailable channels and specify =96= inf as power limit

=A0

"-Inf" is not really workable, because JSON does not allow Infini= ty or NaNs (http://tools.ietf.org/html/rfc4627), hence the d) proposal.=

=A0

d)=A0=A0=A0=A0=A0 List unavailable channels and do not spec= ify any power limit=A0

=A0

So far, we have majority in favour of a), few pe= ople who could live or prefer c) and sort of consensus to strike out option= b) from the list above.

=A0

We=92ll wait for more input on the list before d= eclaring rough consensus for the question above; then we=92ll go back to th= e original question on whether the encoding of spectrum profile should be option 1 or option 2.

=A0

p.s. It looks to me, that if we want to specify = unavailable channels, we may need to modify the names of the paws messages = to =91Spectrum schedule=92 or sg along these lines.

=A0

-=A0=A0=A0=A0=A0=A0=A0=A0=A0 Gabor

=A0

=A0

=A0


_______________________________________________
paws mailing list
paws@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/paws

=A0


_______________________________________________
paws mailing list
paws@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/paws




--
-vince



--
-vince
--e89a8ff1bf9aefc0f304e755173a--