Thanks VInce, that does help. It's a laudable goal, it would be nice to
have all the regulatory information captured in the database and be able
to desing adaptable devices.
The advantages are obvious, starting with the certainty that today's
rules will change in the future(substantially).
It's a challenge in that you are trying to model things that don't
exist yet. The best we can do is look at how things have been done so far.
Using the FCC as (perhaps the simplest?) example, you have quite a bit
to consider as evidenced in this thread which the current methods does
not seem to (obviously) express, such as the different kinds of power
limits given (all are importantand which one dominates your allowable TX
configuration depends on modulation type, signal shapping and several
other factors).
hope that helps.
-Ben
On 10/3/2013 4:47 PM, Vincent Chen wrote:
Ben,
Answers inline.
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
What is “authoritative time range” and where does the value come
from or how is the value calculated?
·Within a spectrum list, missing frequencies now can be
interpreted unambiguously as unavailable without magic values
I agree, but I still think that any radio vendor writing code for
a specific ruleset would know that any channels not listed are
simply not available.
I am not even sure why the discussion of showing "unavailable"
came up, but I can guess that it may be due to some language in
one of the proposed regulations (ETSI or OFCOM ?) that implies a
"push" model for indicating that a channel is no longer available.
Maybe this started as an discussion on how to satisfy that
requirement?
No, actually. It arose from the language in the FCC TVWS rules, where
it's expressed as permitted and un-permitted channels, rather than
ETSI/OFCOM that expresses a power level for each channel.
·If there are gaps in time intervals, it also may be interpreted
unambiguously as no available frequencies
Is this statement true only for the /timeRange/ specified?
·Still allows the protocol to express of full mask where allowed
How do we express a /full mask/ in the protocol?
I don't know what is meant by a "full mask". If the intention is
to describe emission limits so that a WS implementation can be
adaptable to different regions and changes in regional regulations
over time, this representation does not allow the full story. For
an FCC compliant TVBD there are limits on PSD (BTW it appears from
this example that "Psd" means maximum TX power and not the PSD
limit n the FCC regulations) which vary based on device category
and usage, there are max power in the TV channel limits that
depend on device category and what is going on in adjacent TV
channels, and other limits that require you examine other sections
of the regulations such as 15.209 to understand (which specifies
adjacent channel field strength limits for example). I don't seen
how those other values are represented in this format - for
example how would we encode " 200 microvolts/meter electromagnetic
field strength measured in 120 kHz bandwidth at a distance of 3
meters s from the transmitter" which is a requirement US TVBDs
must meet for emissions outside the channel of use.
So I am back to the question I was asking - what is the intended
purpose of specifying a "mask"?
One exciting aspect of managing spectrum via a Database is that you
can move the complex logic you've described into the Database.
The "200 microvolts/meter electromagnetic field strength measured in
120 kHz bandwidth at a distance of 3 meters s" can be converted
to EIRP, and the Database may overlay all the applicable rules and
present to the Device a mask that it must meet, taking into account
its device type, device class, etc. Note that the DB's response is
tailored to the device that makes the query.
For devices that contain software-defined radios, they just have to
fit within the envelope defined by the mask and not have to carry
around these per-regulator rules.
Should the protocol be ready to support such a model? or only be
restricted to support the (few) existing rule sets?
-vince
_______________________________________________
paws mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/paws
