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
[email protected]
https://www.ietf.org/mailman/listinfo/paws
_______________________________________________
paws mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/paws
