How to generate an online time report for the device

I noticed that the online status of the Genieacs homepage is determined by comparing the time when the device last received an inform with the current time, and it is determined whether it has exceeded 300 seconds. This is because in the provisioning script, the periodic inform interval (PeriodicInformInterval) for the device notification is set to 300 seconds.

Assuming I also maintain this 300-second configuration. At this point, I want to have a clearer understanding of the time when a certain device is online and offline within a day, so as to draw a chart of the device’s online time. How can I achieve this function?

My current idea is to use preset + provision + ext. Every time the device receives 2 PERIODIC signals, it will trigger and save this record. When summarizing, if the interval between the two records exceeds 5 minutes, or if there is a redundancy of 30 seconds, it is considered that the device is offline during this period.

This method seems feasible, but is there a more elegant solution?

Thank you for your reply.
Best wishes!

Why do you want to track this with the ACS? It would be much less resource intensive to use ICMP(8) (tcp ping).

How do your devices authenticate? DHCP or PPP? If PPP, you can use the radius messages to know within 3-5 seconds (or what ever your LCP timeout window is configured for) to know when the CPE dropped offline.

Most of our CPEs are deployed behind NAT and managed through TR-069 with STUN, so ICMP reachability is not always available.

I’m actually trying to measure ACS-level availability (TR-069 connectivity) rather than pure network reachability.

I often see your replies on the forum, and I’ve learned a lot from them. Thanks for your sharing.

1 Like

Your plan of using a preset/provision/ext is the right path in that case.

I believe the commercial version of GenieACS stores historical information, and so may store the information you need. You would have to reach out to sales@genieacs.com for confirmation.

You are welcome!

Okay, I’ll look into it. Thanks for the suggestion.

If your NAT traversal is working fine, ideally via xmpp, you could query the GenieACS API every X minutes and know if the device answer back to genieACS and so, if up or down.

This way, you wouldn’t have to guest if down by lack of inform, you would get a clear answer by the GenieACS.

P.S. Seems like a good scenario for a serial timestamp database like Timescale, InfluxDB, Promotheus or Crate.

Hi,

Thanks for your suggestion.

That approach makes sense, but I’m a bit concerned about the overhead. My platform is designed to manage a large number of devices, so periodically sending connection requests to every device would generate a significant amount of CWMP traffic and additional load on GenieACS.

What do you mean by large number of device ?

I shouldn’t be that much of a workload and way to scale it so devices won’t all connect to the same ACS server. Anyway, bidirectionnal communication is now the insdustry standard with TR-369 (USP).

Another way would be to use Oktopus alongside GenieACS for TR-369. Oktopus is pretty much useless in it’s open source version since you don’t have provisionning script but the API is their and you could “ping” the CPE through it. This is what we plan to do, GenieACS for provisionning and Oktopus to collect CPE data.

Hi,

Thanks for the explanation.

Our long-term target is to manage around 100,000 devices. We do plan to scale horizontally with load balancing in the future, but at the moment we only have one GenieACS server because our deployment is still relatively small.

Right now we have around 1,000 devices online. My concern is that if we start sending periodic connection requests to every device, especially when there are already many provisioning tasks running, the additional CWMP sessions could consume a significant amount of CPU and memory.

Our current deployment uses a 4 vCPU / 16 GB RAM server for GenieACS and a separate 4 vCPU / 32 GB RAM server for MongoDB. I’m also still using the default maximum concurrent session limit of 20. I suspect that’s one of the reasons CPU and memory usage becomes high when many tasks are running simultaneously.

TR-369 is definitely something we’re interested in, and it’s part of our long-term roadmap. We just haven’t started development on that side yet, so for now our platform is still entirely based on TR-069.

Thanks for sharing your experience. It’s very helpful to hear how you’re approaching it.