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. | [email protected] | 408-230-0522 On Wed, Sep 25, 2013 at 3:56 PM, <[email protected]> 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:[email protected]] > *Sent:* Wednesday, September 25, 2013 1:57 PM > *To:* Peter Stanforth > *Cc:* Paul Lambert; Vincent Chen; Bajko Gabor (Nokia-CIC/SiliconValley); > [email protected] > > *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 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-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" protection > 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" 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 apriori > 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. |**** > > [email protected] |**** > > 408-230-0522**** > > ** ** > > 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**** > > **** > > ** ** > > ** ** > > > _______________________________________________ > paws mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/paws**** > > ** ** >
_______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
