Very high frequency updates

[draggett]

Note: not sure if this is the correct repository for this issue, please advise.

For some telemetry use cases, we may have very high frequency of updates for a thing's state. Each update can have multiple data values, e.g. where you want to transfer readings that were taken at the same time from multiple sensors. To handle this efficiently, it is desirable to bundle a sequence of successive updates into a single message. A related use case has a very high frequency of events, necessitating a means to bundle successive events.

Application developers shouldn't be concerned about the underlying protocols, but are certainly interested in ensuring that their use case is implemented efficiently by the Web of Things platform. For this purpose, there should be a means to request such bundling and to provide some hints to control this. I see value for exposing this control in the thing description as part of the communications metadata, but also through the scripting API, to allow applications to adapt to changing conditions.

The scripting API is also involved in that application developers may want to indicate that they are able to handle a bundle of state updates or events when they call the observe API.

My implementation experiments used a couple of metadata terms: frequency for the expected frequency of the updates (samples/second), and latency in seconds, which indirectly relates to the number of samples in each bundle. Please ask me for a demo.

[zolkis]

It is fine to discuss this here. Like in the Generic Sensor API, at the sensor level there is sampling frequency, and reporting frequency. In this issue we are talking about the case when reporting frequency is [much] smaller than sampling frequency, and we want to notify a sequence of readings in one notification.

The way I see it this should be possible now:

• define a TD that exposes an Event with data structure defined as sequence of readings (represented e.g. as objects)
• when consuming such a TD, the runtime creates bindings
• when subscribing to the event, the client is registered for value updates at the server runtime. One configuration parameter would be the size of the sequence buffer, which can be calculated from the reporting frequency, sampling frequency and local constraints in the device and network.

The question is what the Scripting API should support. I've been thinking to add optional options to the onEvent(), and eventually also the other observing methods. The nice thing of using the Observer pattern is the possibility to add such subscribe options. These options might contain the min/max reporting frequency and/or the max buffer size the client can handle at a time).

[zolkis]

As a related thing, @mjkoster mentioned the The Series Transfer Pattern (STP).

[mkovatsc]

On the ExposedThing use the emitEvent() to push in data.
On the ConsumedThing use the observable privided by onEvent() to receive the data.

Of couse, some sense has to be put into where the ExposedThing is deployed and what communication channel it uses toward the ConsumedThing.

For this, the event source device running the script with the ExposedThing should be equipped with a runtime that has enough processing power to handle the high frequency and a protocol binding that has enough bandwidth. Manufacturers of such an event source device know the requirements and are able to do so.

The client running the ConsumedThing subscribing to the event source needs to figure out if it has enough processing power to consume the very high frequency updates. For this, have the metadata in the TD. You can already include your own or "the common" very high frequency updates vocabulary. Maybe we want to get the stability term back into the TD core vocabulary.

In summary, this issue is already covered with what we have in the specs.

[draggett]

@mkovatsc - whilst a thing description could define an event as an array of values, this hides the semantics as a time sequence of sensor readings with a given sampling frequency and latency.

In my multichannel ECG demo, the client application drives a smoothly scrolling display of the sensor readings. The transfer of data from server to client is subject to jitter which needs to be allowed for in order to achieve smooth scrolling without drop outs when data isn't received in time. For this, I found it convenient to declare the frequency and buffering latency as part of the thing description, and use this information to manage the display buffer beyond the end of the display.

Sometimes you want to stream updates from a client to the server where similar considerations apply. For this, it is desirable to have an API for pushing a sequence of updates to the WoT runtime. Streams may represent continuously changing values, in which case, the data transferred may be a piecewise polynomial approximation. A use case is continuously driving actuators, e.g. the direction of a light beam, or the joints of a robot arm. We thus have a need to support streaming from server to client and from client to server. The thing description declares the data type of the properties along with the metadata for the frequency of updates and the buffering latency, which determine how long you can expect to wait for the next bundle of updates.

[mkovatsc]

Maybe a piece of the puzzle that has to be brought up explicitly: When you use a TCP-based channel or CoAP's CoCoA -- which is very advisable for high frequency updates -- there is flow control available: The event source can learn that the subscriber cannot handle the current update frequency. The runtime can use this to throttle the frequency according to the communications metadata (e.g., by re-sampling or just dropping frames). To keep things simple, there should not be a specialized extension to the Scripting API for just this use case (but use the metadata mechanism instead).

[zolkis]

Delays may come from other sources than networking issues alone.
IMHO having an API that can adapt to high frequency updates is a good thing, if it can be done in a simple way.

@draggett wrote:

I found it convenient to declare the frequency and buffering latency as part of the thing description, and use this information to manage the display buffer beyond the end of the display.

So the proposal would be to support such application hints by the Scripting API towards the Scripting runtime (from there on it depends on networking support). Such a use case/requirement makes sense IMHO. So we "leave space" in the API for such future API options (not necessarily WoT Interaction options).

[danielpeintner]

Scripting Call 2021-08-02

Does not seem to be limited to scripting but being rather a more generic (TD? )issue..
@ashimura mentions we should have concrete use-case also.

-> Propose Closing

[egekorkan]

I would say that this is also protocol specific and can be abstracted by a subscribeallevents operation that will get events bundled and it is up to the Thing to bundle them as needed. An interesting point would be if there should be a way for the Consumer to say that "I can only process 50 events a second, do not send more". That would be protocol specific but needs application-level knowledge, so a bit tricky to design for

[danielpeintner]

An interesting point would be if there should be a way for the Consumer to say that "I can only process 50 events a second, do not send more". That would be protocol specific but needs application-level knowledge, so a bit tricky to design for

That's exactly what we were discussing also.
Sure, we can create such a configuration option but it could make everything very complex....

Hence (as pointed out by @ashimura) we need actual uses where you need such a functionality.

[danielpeintner]

Scripting Call 2021-08-09

• @zolkis use case exists for @draggett
• @zolkis generic sensor api deals with it (sampling frequency and reporting frequency) -> should be moved to TD
• @ashimura ask in main call and make people aware

[danielpeintner]

Scripting API Call 2021-08-23

• should be aligned with TD work
• need good use-cases
• need to clarify implementation complexity
• Possible existing solutions (proof-of-concept desired)
  • handle as streams
  • do not observe but instead use polling