Modern industrial sites generate an enormous amount of telemetry. Sensors track temperature, humidity, vibration, air quality, energy usage, equipment status, and much more. For electric utilities production or construction sites are large so deploying wired infrastructure is often impossible or too costly.
This is exactly the case for Electricite de France (EDF), the French state-owned electricity utility, who contracted me to implement their idea of an efficient and standardized telemetry system for Lightweight M2M (LWM2M).
EDF deploys a variety of off-the-shelf, battery-powered LPWA wireless sensors, mainly LTE-M and NB-IoT, scattered across huge areas. They do not build custom hardware, so interoperability between vendors is essential. Using Lightweight M2M (LWM2M) is therefore the obvious choice: it ensures that heterogeneous sensors expose a consistent device management and telemetry interface.
Although this work started from an EDF use case, the limitations we encountered are common to many LWM2M deployments across industries.
This article presents the Zephyr based and open-source project I have been working on to address these needs: the Lightweight M2M Send Scheduler, an open and reusable system that extends how LWM2M devices collect, filter, batch, and push telemetry.
Why we built a Send Scheduler
While LwM2M already provides multiple telemetry mechanisms, none fully address the constraints of battery-powered LPWAN devices:
- LWM2M Observations (per-resource notification).
- LWM2M Composite Observations (multi-resource notifications).
- LWM2M Send / Data Push (the 1.1+ mechanism that allows device initiated telemetry upload).
In theory, observation looks attractive: you configure attributes (pmin, pmax, gt, lt, step) and get filtered notifications. But in practice, there are three major issues:
-
Too many packets = too much battery consumption.
If a device has 5 observed values, it sends 5 notifications. If the notifications are confirmable, that becomes 10 messages.
-
Composite Observation is not efficient.
Composite observation lets you monitor multiple paths together and avoid too many packet issues. But every time one resource triggers a rule, the device must:
- Resample all the resources of the composite observation, not only the triggering value.
- A single threshold crossing causes all resources to be re-sampled and transmitted.
This produces larger packets than necessary and requires backend based filtering.
-
Vendors reinvent the wheel.
With LWM2M Send/Data Push, devices can efficiently send batched telemetry, including historical samples with timestamps. LwM2M Send is efficient, but the specification intentionally leaves sampling and batching policies undefined. Every vendor ships a different proprietary configuration model.
EDF wanted one thing:
That is why they came with this idea of the Lightweight M2M Send Scheduler.
The Send Scheduler introduces two new LWM2M objects. The Send Scheduler does not define sensor semantics; it only defines when and why data is sampled and transmitted.
Scheduler Control Object
Scheduler Control Object which controls when accumulated samples are sent. Defines when to flush accumulated samples:
- Max number of samples.
- Max sample age.
- Flush on registration update.
- Pause/resume behavior.
- Manual flush (execute).
Sampling Rule Object
Sampling Rule Object which defines what sample to acquire in the cache. Defines what to sample and when:
- Target resource path.
- Filtering attributes following the observe filter pattern: (pmin,pmax,gt,lt,st).
- Minimum period between samples.
- Per-resource sampling logic.
Together, these objects replicate the capabilities of observation attributes but apply them to the Send/Data Push mechanism, unlocking:
- Efficient batching: the sampling is done following the rules but the transmission is based on another set of rules (max age, max sample, registration updates). Creating a way to decide when a sample is worth getting and when it is worth communicating.
- Standard configuration: the objects provide a clear and replicable way to configure the usage of the LWM2M Send, helping to standardise the configuration of this feature.
- Being able to decouple the sampling from the sending helps to optimize and predict your battery budget.
The implementation
To allow a better adoption of the system, the implementation of the send scheduler was contributed to the Zephyr project. Why Zephyr, because it is a full-fledged open-source RTOS for IoT devices, supporting a wide range of low-power wireless communication systems.
The Zephyr LWM2M client was already supporting LWM2M 1.1 and needed minimal modification to support the new feature. See the Zephyr documentation: LwM2M Send Scheduler helper objects.
Although implemented in Zephyr, the model itself is RTOS and vendor-agnostic and can be implemented on any LwM2M client.
Here is how the system works inside a device:
- Sensors produce raw samples (temperature, humidity...).
- Sampling Rules decide whether each sample should be kept or dropped, based on observation-style attributes (gt, lt, step, pmin) applied at sampling time.
- Valid samples are stored in the LWM2M Resource Data Cache.
The scheduler evaluates conditions:
- Maximum sample age.
- Max stored sample count.
- Cache remaining space.
- Registration update.
- Or a manual trigger is requested.
When triggered, the Scheduler uses LWM2M Send to encode and push a SenML/CBOR.
How to try it yourself
The fastest way to evaluate the send scheduler is to build the dedicated configuration for the LWM2M Send scheduler: https://docs.zephyrproject.org/latest/samples/net/lwm2m_client/README.html#lwm2m-client.
With the Zephyr native simulator which can run on your laptop: https://docs.zephyrproject.org/latest/boards/native/native_sim/doc/index.html.
Simply build like this:
west build -b native_sim samples/net/lwm2m_client -- -DCONF_FILE=overlay-send-scheduler.conf
And run the Eclipse Leshan server on the same machine: Eclipse Leshan demo instructions.
The device will show fake humidity and temperature sensor providing values, and also the two send scheduler objects (control and rules).
The goal is to make this mechanism adopted and possibly part of the standard:
- The current object IDs reserved by OMA are 10523 and 10524.
- And ultimately propose this to the Open Mobile Alliance (OMA) as a standard extension of LWM2M.
If sensor manufacturers adopt this model, we will finally have: a consistent, vendor-neutral way to configure telemetry sampling and batching in LWM2M.
If you are looking or testing this idea, please provide feedback: julien@clunkymachines.com.