Discussion for a new capability for RegionDeviceCount

[bigludo7]

Problem description
Thinking about our API and UC I'm wondering if we shouldn't think about adding a new capability to send notification when the volume of devices go up or below a threshold.

We will offer a deviceCount-subscription endpoint (or other better name) to allow developer to subscribe for these events (number of devices above threshold, number of devices below a threshold), providing this threshold value and providing a sink url where notification must be send.

When situation occurs we trigger this event.

I saw UCs where depending on the volume of connected devices you want to propose/trigger to user some offers to get always a good connectivity.

What do you think?

Possible evolution
Add a second yaml to manage deviceCount-subscription

Alternative solution

Additional context
Do we need to go through the API backlog WG?

[chinaunicomyangfan]

@bigludo7 I think this is a great proposal. Adding subscription functionality can meet more scenario requirements. Some of the scenarios I can think of now, such as hosting large-scale conferences or events, organizers can use this API to monitor the number of devices in the activity area. When the number of devices approaches or falls below the set threshold, notifications can be sent to event organizers so that they can adjust the activity process or provide personnel guidance in a timely manner.

Do we need to go through the API backlog WG?

In my understanding, changing yaml should not require notifying WG, right？
@ShutingQing What do you think?

[ShutingQing]

@bigludo7 👍 I think this is a really great proposal that i can see potential value. Developers will have this need to be notified in which area, users are increase or decrease in a fast speed.

If we add such a function, should we make it an independent API? RegionDeviceCount is applied for those who request for a specific area. A new API with device num changes can applied for those who subscribe the service.

[bigludo7]

Thanks @ShutingQing and @chinaunicomyangfan for your positive feedback.

We need a separate yaml following CAMARA subscription ruling (here) so I guess we need to trigger a request to the API backlog WG.

Our plan could be:

• Let's tackle first the API name change with the backlog team (@chinaunicomyangfan manages this)
• once done we can trigger this new feature to the backlog team (I can make a PR in backlog for this and getting your support)
• we propose to work on this API in our project

[gregory1g]

suggestion for a UC. A targeted advertisement on in some area (video screens). Less people - show cheaper ads, more people show more expensive ads. Filters are useful in this scenario as well.

[ShutingQing]

Agree with Gregory.

Another use case I come across is, for Uber/Lyft/Gaode Map/Bolt taxi APPs, they can call the API, combined with GPS, to provide more accurate prediction of people. For some users, they allow the authentification of GPS only when "allow GSP when using the APP only", under such scenario, they can have one more input for predicting potential users, and so as to arrange the drivers.

As well for some food delivery APPs, they can call the API and provide an option for restaurants a reference, where to choose the restaurant location.