Add a Send Scheduler Object for store-and-forward sampling and delayed LWM2M send transmission

[jvermillard]

Problem Description

I would like to contribute a « Send Scheduler » mechanism for the LWM2M client, implemented as a pair of LWM2M Objects.

This feature enable store & forward sampling where sensor data collected locally and transmitted later based on configurable rules and triggers, optimizing for radio-time/power-consumption.

Motivations

My customer is a leading electricity producer and is using low power wireless devices to monitor large production buildings and construction sites. They use off-the-shelf battery powered, cellular devices using LWM2M send to be able to pack and send captured samples. But each manufacturer comes with their own way to configure and control the store and forward.

The target is to provide at minimum an open-source implementation (based on Zephyr) to help the ecosystem of sensors to emerge and re-use as much as possible. Once the system is working and proven to be useful, try to push the mecamism back to the LwM2M standard body.

Proposed Change (Summary)

High-level object design:

Object 1 – Scheduler Control (single instance)

ID	Name	Type	Op	Description
0	paused	Bool	R/W	Pause accumulation; flushing pending buffer on disable
1	max samples	Int	R/W	Max samples before forcing transmission
2	max old	Int	R/W	Max sample age before forced transmission

Object 2 – Sampling Rules (multi-instance)

ID	Name	Type	Op	Description
0	path	String	R/W	Resource path to monitor
1	collection rules	String[]	R/W	Rule strings like pmin=10, gt=25, lt=5, epmin=60, etc..

Proposed Change (Detailed)

Typical usage:

• sample frequently, filter using the LwM2M cache filter, but send infrequently (e.g. every 30 min) based on time rule or buffer size
• buffer timestamped SenML records (reuse the LwM2M cache already in place)
• may reconnect and flush opportunistically (RAI / scheduled link) or based on rule (max time, max number of sample accumulated)

Currently Zephyr’s LWM2M client supports per-resource caching (lwm2m_send) but lack :

• configurable scheduling logic
• configurable sample filtering logic (first step done: net: lwm2m: add cache filtering #97545)
• persistent configuration and samples

Note : This scheduler complements (not replaces) observations, a bit like /dp is not replacing observations in LWM2M.

Dependencies

No response

Concerns and Unresolved Questions

Validate that the Zephyr LwM2M maintainers agree this fits within the LwM2M roadmap or not, if it's something that needs to be published outside of Zephyr.

In the mean time I'll continue to clarify the object definition and start implementing a first version.

Alternatives Considered

Observation and composite observation, but they don't allow to create compact and predictable communication patterns which are critical for battery operated cellular devices. This is also why the standard body added the /dp + cbor-SenML resource on the server.

[rlubos]

I generally have no objections to have such module in the Zephyr tree if it proves useful and could be reused by others, a helper library to manage application's Send operations sounds reasonable.

I'm just thinking, given it seems to base on some non-standardized behaviors (the new objects you mention), perhaps we should keep it separately from the "core" LwM2M library? lwm2m_extensions lib or something similar. If I understood the RFC correctly, this mechanism seems to build on top of some standard LwM2M paradigms (object model, Send operation, resource caches), but doesn't necessarily need to be part of the core lib?

[rlubos]

CC @SeppoTakalo

[jvermillard]

If I understood the RFC correctly, this mechanism seems to build on top of some standard LwM2M paradigms (object model, Send operation, resource caches), but doesn't necessarily need to be part of the core lib?

Exactly