Geofencing API - Adding capability to manage max number of notification

[bigludo7]

Problem description As of now we are only able to subscribe for a period of time but why not allowing also to subscribe to a number of notification?

We can have UC where we want to get notified when a device will reach or exit a geo zone once but without any time limit (like for sim card that are embedded in equipment that are not suppose to move like in traffic light...).

Possible evolution Add capability to define a max number of notifications.

Alternative solution

Additional context

[jlurien]

I don't fully understand the UC and the suggestion. Is that to set a limit to the number of notifications until subscriptionExpireTime, for certain device?

In case of a device with a fixed location, like a traffic light, I guess that the interesting use case is to detect if the device is being abnormally moved, e.g. stolen, right? In that case you would receive a single notification when leaving the geofence

[bigludo7]

@jlurien

Is that to set a limit to the number of notifications until subscriptionExpireTime, for certain device?

Yes. If the subscriptionExpireTime is provided, the subscriptions will stop when this date is reached or the max number of notification is reached. If the subscriptionExpireTime is not provided then the subscriptions will stop when the max number of notification is reached. There is same feature in 3GPP monitoringEvent with the maximumNumberOfReports attribute.

In case of a device with a fixed location, like a traffic light, I guess that the interesting use case is to detect if the device is being abnormally moved, e.g. stolen, right? In that case you would receive a single notification when leaving the geofence

Yes this is one of the UC. I was thinking that the expirationTime is not really the relevant request parameter as the expectation is to get notified when the device entered (or exited) the defined area whenever it is it is in one week, one month or 10 years...

One way to solve this perhaps is to consider that if subscriptionExpireTime is not provided then only one notification will be sent.

[jlurien]

This sort of limitation sounds like something generic, not specific to Geofencing, maybe it's convenient to discuss it at Commonalities level, as subscriptionExpireTime which comes from the guidelines. Only that it is not part of the CloudEvents format, so we would need something within the payload.

My assumption regarding subscriptionExpireTime, which is optional, was that if not provided there is no explicit time limit (other than that supported by implementations, that may be returned in the response). I think it is not a good idea to assume that only one event is to be sent in this case. If needed, better to have some dedicated attribute.

[bigludo7]

Thank @jlurien for your feedback. I will trigger a discussion in Commonalities.

We need a rule for subscriptionExpireTime anyway and I'm fine in both scenario as long as we have a rule.

I propose to let this issue open till we have an agreement.

[alpaycetin74]

My understanding so far is, if a device leaves the subscribed area, the API sends a notification to inform the user it has happened. There is only one notification. Even if the device continues to remain outside the area, no further notifications are sent. With that approach, a notification can be sent again only if the device enters the area again and leaves again.

[jlurien]

My understanding so far is, if a device leaves the subscribed area, the API sends a notification to inform the user it has happened. There is only one notification. Even if the device continues to remain outside the area, no further notifications are sent. With that approach, a notification can be sent again only if the device enters the area again and leaves again.

My understanding on this is the same

[bigludo7]

@alpaycetin74 @jlurien Agreed.... but it did not solve my point.

If I need to be notified once that a device entered or existed a zone what is the point to get the subscription valid, when notified, because the subcriptionExpiryTime is not reached ? My request is to be able to get notified once and get the subscription terminated when the event occurred.

[alpaycetin74]

I think we can position is like this: If we want to keep the subscription going irrespective of notification count, we can just input the subcriptionExpiryTime. An infinite/unimited number of notifications can be sent as long as the expiry time is not reached and the event keeps happening. If we both define a subcriptionExpiryTime and a max notification count, subscription ends whichever condition is satisfied first. Similarly, we can create a subscription without a subcriptionExpiryTime, only with a max count. Then, subscription does not expire based on time but terminates if entry/exit event happens n times. Lastly, it is possible to define neither of those conditions and the subscription goes forever with any number of notifications, unless the user explicitly unsubscribes. For an application, it may be possible to implement the uses cases without either of the parameters in the API definition, i.e. they can accept the max notification count from the user and count the notifications on their own. An app could even re-subscribe multiple times (without the user noticing) to fulfill the user's requirement. It depends on our preference - the api developer or the app developer running "more" logic.

[jlurien]

I suggest to open a new issue in Commonalites, different from https://github.com/camaraproject/Commonalities/issues/89, if we need a new use case to limit the amount of notifications per subscription. In this case we'll probably need a new property in the subscription creation and also to define a new terminationReason: MAX_EVENTS_REACHED, or similar, for subscription-ends.

[bigludo7]

Thanks - Fully inline with your proposal @alpaycetin74 and for the suggested way to proceed @jlurien. Will do the Commonalities issue and copy/paste @alpaycetin74 proposal.

[jlurien]

Following discussion in Commonalities.

[bigludo7]

Now that the subscriptionMaxEvents has been added in the guideline we can add it in our Geofencing API (https://github.com/camaraproject/Commonalities/pull/131)

@maxl2287 as you are the active contributor on this API, is it something you can consider ? Thanks !