Subject: [paws] SPECTRUM_USE_NOTIFY: nomenclature and response

From: "Harasty, Daniel J" <[email-masked]>
Date: Thu, 25 Jul 2013 20:06:26 +0000

Sanjeev mentioned:

From: [email-masked]
Sent: Thursday, July 25, 2013 10:31 AM
[...]
5. REGISTRATION_REQ, and SPECTRUM_USE_NOTIFY transctions; can it have repsonses like accepted/denied by database?
[...]

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".

Thoughts?

Dan Harasty

---

From: Ray Bellis <[email-masked]>
Date: Fri, 26 Jul 2013 07:41:09 +0000

On 25 Jul 2013, at 21:06, "Harasty, Daniel J" <[email-masked]<mailto:[email-masked]>> 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

---

From: "Harasty, Daniel J" <[email-masked]>
Date: Fri, 26 Jul 2013 12:52:43 +0000

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-masked]]
Sent: Friday, July 26, 2013 3:41 AM
To: Harasty, Daniel J
Cc: [email-masked]
Subject: Re: [paws] SPECTRUM_USE_NOTIFY: nomenclature and response

Ray

---

From: Ray Bellis <[email-masked]>
Date: Fri, 26 Jul 2013 12:58:50 +0000

On 26 Jul 2013, at 13:52, "Harasty, Daniel J" <[email-masked]<mailto:[email-masked]>>
 wrote:

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?

Well, quite :)

In theory of course a device shouldn't do that, but this is in effect the OFCOM requirement.

I'll suggest to the OFCOM folks that the SPECTRUM_USE_NOTIFY should become "informational only", and not require any positive action other than logging those values.

kind regards,

Ray

---

From: "Harasty, Daniel J" <[email-masked]>
Date: Fri, 26 Jul 2013 15:41:18 +0000

Ray,

Thanks for considering my input.

I want to make clear that I'm not opposed to the notion of the ability for the Database to "reject" a Device's selection, or somehow "rescind" a channel previously stated as available -- provided if there is a widely accepted use case based on regulatory guidelines.

My original proposal is more about nomenclature than use case. Just to be clear about my input:

*         If SPECTRUM_USE_NOTIFY is a "true notification", let's use the JSONRPC "notification" message type for SPECTRUM_USE_NOTIFY, and strike the [empty] SPECTRUM_USE_RESP from PAWS.

*         If there is a bonafide use case for the Database to "reject" or "rescind", let's define an appropriate pair of messages, such as SPECTRUM_USE_REQ and [a non-empty] SPECTRUM_USE_RESP.

*         If necessary, update ruleset definitions to clarify which is used when/where.

Kindest regards,

Dan

From: Ray Bellis [mailto:[email-masked]]
Sent: Friday, July 26, 2013 8:59 AM
To: Harasty, Daniel J
Cc: [email-masked]
Subject: Re: [paws] SPECTRUM_USE_NOTIFY: nomenclature and response

Well, quite :)

kind regards,

Ray

---

From: Rex Buddenberg <[email-masked]>
Date: Fri, 26 Jul 2013 10:07:54 -0700

On Fri, 2013-07-26 at 15:41 +0000, Harasty, Daniel J wrote:
> somehow “rescind” a channel previously stated as available -- provided
> if there is a widely accepted use case based on regulatory guidelines.

Dan,

The use case has already been stated.  Consider an emergency that
requires a public safety mobilization type of response -- earthquake or
hurricane or somebody flying airliners into buildings ... any will do.
Emergency services needs to mobilize and they need more spectrum (or
access to spectrum ... contention-free MACs are time-share):
  - to accommodate a quickly accelerated operations tempo
  - to replace wired connectivity that has been interrupted by the
disaster.

---

From: Vincent Chen <[email-masked]>
Date: Fri, 26 Jul 2013 10:13:07 -0700

Rex,

This is a requirement of capability, but it does not require that it be
done through the use of SPECTRUM_NOTIFY.
It could be easily satisfied if the Device were to use AVAIL_SPECTRUM_GET
periodically to refresh its list, which could
result in 0 spectrum.

-vince

On Fri, Jul 26, 2013 at 10:07 AM, Rex Buddenberg <[email-masked]>wrote:

> _______________________________________________
> paws mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/paws
>

-- 
-vince

---

From: Rex Buddenberg <[email-masked]>
Date: Fri, 26 Jul 2013 10:19:24 -0700

Agreed.  I was carefully avoiding the 'how'.

On Fri, 2013-07-26 at 10:13 -0700, Vincent Chen wrote:
> Rex,
> 
> 
> This is a requirement of capability, but it does not require that it
> be done through the use of SPECTRUM_NOTIFY.
> It could be easily satisfied if the Device were to use
> AVAIL_SPECTRUM_GET periodically to refresh its list, which could
> result in 0 spectrum.
> 
> 
> -vince
> 
> 
> On Fri, Jul 26, 2013 at 10:07 AM, Rex Buddenberg
> <[email-masked]> wrote: