Unsupported timeInterval parameter for periodic subscriptions

[daniel-gonzalez-sanchez]

Hi everyone,

I was playing with NGSI-LD subscriptions when I discovered an issue. Following the ETSI CIM standard and the specification document for the NGSI-LD API V1.6.1 (i.e., ETSI GS CIM 009 V1.6.1), which is supported by ORION-LD Context Broker, according to the section 5.2.12 Subscription (Table 5.2.12-1: Subscription data type definition on page 79), there is a parameter named timeInterval that "Indicates that a notification shall be delivered periodically regardless of attribute changes. Actually, when the time interval (in seconds) specified in this value field is reached". But I've checked that creating a simple subscription with the timeInterval parameter does not work well because the timeInterval parameter for the periodic subscriptions seems not to be implemented.

Let me show an example:

Environment

• fiware/orion-ld:latest (using the sample docker-compose file found in the official ORION-LD Context Broker DockerHub repository)

Making the following HTTP GET request for getting the ORION-LD Context Broker version:

curl --location 'http://localhost:1026/version'

, the regarding response body is the following:

{
    "orionld version": "post-v1.2.0",
    "orion version": "1.15.0-next",
    "uptime": "0 d, 0 h, 13 m, 55 s",
    "git_hash": "nogitversion",
    "compile_time": "Tue May 30 09:49:52 UTC 2023",
    "compiled_by": "root",
    "compiled_in": "",
    "release_date": "Tue May 30 09:49:52 UTC 2023",
    "doc": "https://fiware-orion.readthedocs.org/en/master/"
}

Steps to reproduce

Creating a subscription to a sample Sensor NGSI-LD Entity with the timeInterval parameter:

curl --location --request POST 'localhost:1026/ngsi-ld/v1/subscriptions/' \
--header 'Content-Type: application/json' \
--header 'Link: <https://fiware.github.io/data-models/full-context.jsonld>; rel="http://www.w3.org/ns/json-ld#context"; type="application/ld+json"' \
--data-raw '{
    "id": "urn:ngsi-ld:Subscription:Sensor",
    "type": "Subscription",
    "entities": [{
        "type": "Sensor"
     }],
    "description": "Periodic subscription every 10 seconds to Sensor entities.",
    "timeInterval": 10,
    "notification": {
           "endpoint": {
           "uri": "http://consumer:8082/notify",
           "accept": "application/json"
           }
    }
}'

, the regarding response body is the following:

{
    "type": "https://uri.etsi.org/ngsi-ld/errors/BadRequestData",
    "title": "Not Implemented",
    "detail": "Subscription::timeInterval is not implemented"
}

Many thanks in advance!

Dani

[kzangeli]

Hello there!

Yeah, let me give you some background on "timeInterval": I was the architect and main developer of Orion, in Telefonica R&D, or TID (something tells me you've heard of the company :)) back in the day, and for OMA NGSI (or NGSIv1), we implemented periodic notifications. Afaik, nobody ever used it. A few years later we "invented" NGSIv2 and we didn't include periodic notifications, or "timeInterval". That was perhaps 2017. Six years later, nobody has complained nor asked for it ...

Unfortuinately, for NGSI-LD, the concept of periodic notifications was reintroduced. For Orion-LD I never had the intention of implementing it as I see it as a useless feature that only impacts performance negatively (every periodic subscription would have a running thread, well, that's one way of implementing it).

The context broker is not a timer, and should not be used that way. Do you want a periodic update? Do this;

while (1)
{
  getEntities();
  xleep(X);
}

That said, it IS part of the API and I should implement it even though I don't like it. BUT, I have a long long list of useful features that will be implemented before "timeInterval". That is, unless you can convince me (or my boss) that the feature is really needed. Sorry ... And, good luck!

[daniel-gonzalez-sanchez]

Hello @kzangeli,

Thank you so much for your quick answer and explanation! I think this periodic-based subscription might be interesting for some Context Consumer which wants to subscribe to frequently changing context data. For example, data that represents counters from devices or sensors that are constantly changing. But from what you comment, I understand that this type of subscription can have an impact on the performance and efficiency of the Context Broker.

The alternative that you propose to make periodic subscriptions, at the end would consist of a Context Consumer polling the Context Broker to request the status of an NGIS-LD entity. I don't see this poll-based mechanism as an efficient way either, since it consists of constant polling to obtain data, generating communication load on both sides of the Context Consumer and the Context Broker. If the broker could implement the complexity of periodic subscriptions, it would turn the solution into a push-based mechanism (e.g., a mechanism typically used in network monitoring where the complexity is on the managed network device) where consumers would only worry about subscribing and waiting for the arrival of the data periodically without generating constant requests to the Context Broker.

I understand the complexities and problems that the implementation of this timeInterval field in the ORION-LD Context Broker can cause but from my point of view it could be a very useful feature in the future.

Thanks again for everything!

Dani

[kzangeli]

Yeah, no, I agree. I should implement this. Mainly as it's part of the NGSI-LD standard. The thing is, my bandwidth is limited. If I implement this, is means I don't implement something else, and that something else is probably much more interesting than periodic notifications. It's all a matter of priorities. This issue is on my ToDo list and some day it will be implemented (unless I retire before that happens :))

[daniel-gonzalez-sanchez]

Thanks for the clarification and for taking into account the evaluations that I made @kzangeli! It would be interesting if one day periodic subscriptions are implemented :)