Ray: I'm less familiar with the UK use cases. Is this the case you are contemplating?:
1. Device requests AVAIL_SPECTRUM_REQ 2. Database sends AVAIL_SPECTRUM_RESP with a list of available channels and max power values 3. Device picks one that is either not available, or picks a power that exceeds the limit on an available channel 4. Device reports its [non-conforming] selection via the [optional] SPECTRUM_USE_NOTIFY 5. Database "rejects" that notification 6. Device stops transmitting on the frequency it selected due to the "rejection" If the Device is willing to conform to the "rejection", why did it pick - and report - a non-conforming value to start with? The one possible case I can see some use for a "rejection" is this: a substantial amount of time passes between the AVAIL_SPECTRUM_RESP and the Device's selection/notification, and the selected channel is - contrary to the original AVAIL_SPECTRUM_RESP - no longer available. I propose that the better way to handle that possibility is: the Device should simply send its AVAIL_SPECTRUM_RESP just before its selection. That way, it will have the most accurate info: it can avoid the then-unavailable/undesirable channels - and thus obviate the need for any sort of "rejection". Furthermore, it may find that there are additional/somewhat-better then-available channels. Is this a viable approach under UK (and similar) rules? Dan Harasty From: Ray Bellis [mailto:[email protected]] Sent: Friday, July 26, 2013 3:41 AM To: Harasty, Daniel J Cc: [email protected] Subject: Re: [paws] SPECTRUM_USE_NOTIFY: nomenclature and response On 25 Jul 2013, at 21:06, "Harasty, Daniel J" <[email protected]<mailto:[email protected]>> wrote: The JSONRPC spec defines a "notification" as a type of request that needs no response; in fact a response is not even allowed. Since the PAWS SPECTRUM_USE_NOTIFY is "this kind of message" semantically (note that SPECTRUM_USE_RESP is empty), I propose we: * State that the SPECTRUM_USE_NOTIFY uses the JSONRPC "Notification" Request object (see: http://www.jsonrpc.org/specification#notification), and * That we eliminate the SPECTRUM_USE_RESP from the PAWS spec. This is consistent with Vince's characterization that SPECTRUM_USE_NOTIFY is an "async notify, fire-and-forget, from the perspective of the device". The UK pilot spec requires that the WSDB tell the device to stop transmitting if the channel usage parameters are inconsistent with those that the WSDB issued, i.e. it is not merely "informational". I note however that there appears to be no such specific requirement in the ETSI draft. In my (non PAWS) implementation I was expecting to return an immediate error in these circumstances, rather than wait for the device's next 15 minute poll. Ray
_______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
