Re: [paws] Encoding of spectrum profile

[Benjamin A. Rolfe]

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, sajeevmanikk...@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-boun...@ietf.org [mailto:paws-boun...@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 
<pe...@spectrumbridge.com <mailto:pe...@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 <vc...@google.com <mailto:vc...@google.com>>
*Date: *Friday, September 13, 2013 12:00 PM
*To: *Ray Bellis <ray.bel...@nominet.org.uk 
<mailto:ray.bel...@nominet.org.uk>>
*Cc: *"paws@ietf.org <mailto:paws@ietf.org>" <paws@ietf.org 
<mailto: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

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