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 – preferable closer to 6pm.) > ****· **These are the handful of channels that are available > until 6pm, and I’m telling you NOW that NOTHING is available starting at > 6pm for the next 18 hours. > ****o **(Implicitly: I’ve told you everything I can about all > availability until Noon tomorrow; don’t bother sending me another request > 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’s perspective* – there are really THREE states that a given > channel 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 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. | [email protected] | 408-230-0522 On Wed, Sep 25, 2013 at 1:39 PM, Harasty, Daniel J <[email protected]>wrote: > 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 request between now and then – preferable closer to 6pm.)**** > > **· **These are the handful of channels that are available until > 6pm, and I’m telling you NOW that NOTHING is available starting at 6pm for > the next 18 hours.**** > > **o **(Implicitly: I’ve told you everything I can about all > availability until Noon tomorrow; don’t bother sending me another request > until close to Noon 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 > 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 tried to formulate > an example where “being silent” (Gabor’s term) or “no mention” (my term – > same concept) confers “no information”. In my example, I was NOT saying > “the 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 clear in my point at that > time.)**** > > ** ** > > *From a Device’s perspective* – there are really THREE states that a > given channel 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 that a channel is “is unavailable”. **** > > ** ** > > And that’s why I think it is important for the Database to have a way to > EXPLICTLY 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:* [email protected] [mailto:[email protected]] *On Behalf > Of *Vincent Chen > *Sent:* Wednesday, September 25, 2013 12:10 PM > *To:* Peter Stanforth > *Cc:* [email protected] > > *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 > "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 <[email protected]> > wrote:**** > > Lowering the power to meet the mask is the easy way you get a radio > certified – 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 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 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 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 > 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 <[email protected]> > *Date: *Tuesday, September 24, 2013 2:48 PM > *To: *Don Joslyn <[email protected]>, Vincent Chen < > [email protected]>, "[email protected]" <[email protected]>, " > [email protected]" <[email protected]>**** > > > *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, <[email protected]> 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, 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).**** > > **** > > [DJ – Why should the database care about channels that are 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 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 – 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 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 going to intentionally transmit in that channel. This comment also > applies 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 > 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 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**** > > **** > > ** ** > > ** ** > > > > **** > > ** ** > > -- > -vince **** > > _______________________________________________ > paws mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/paws > >
_______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
