Talk to a metering engineer
For utilities, meter OEMs and metering system integrators

The meter estate, run as one managed fleet.

Electricity meters on DLMS/COSEM. Water and gas meters on LwM2M over NB-IoT, Wi-SUN or wireless M-Bus. Legacy AMR still in the ground and a security patch cycle that now has a regulatory clock attached to it. This is the stack that runs all of it as one programme, from the first schematic to the fifteenth year in the field.

At a glance Friendly UltraMIN runs on the battery meter, UltraPRO on the concentrator or multi-utility hub, and the One-IoT™ platform operates the estate beneath: onboarding, delta FOTA, DTLS Connection ID for links that roam, SGP.32 eSIM steering, and the IoT Protocol Tester proving every build conforms before it ships. A Smart Grid Gateway bridging DLMS/COSEM and OMS meters into the same plane is on the roadmap for utilities running a mixed legacy estate.
Why metering programmes hurt

The estate outlives the org chart that specified it

Every meter type speaks differently

DLMS/COSEM electricity, LwM2M water and gas, legacy AMR and wireless M-Bus heat, each with its own head-end system and none of them showing the whole estate.

Battery life is the business case

A fifteen-year meter that needs a truck roll in year six has already broken the ROI model. Duty cycle and radio choice decide whether the contract is profitable, not an afterthought.

Firmware campaigns nobody dares run

A mandatory security patch across a million field meters, on networks billed per byte and batteries that don't forgive a bad wake cycle, is how a fleet-wide rollout becomes a fleet-wide outage.

The compliance clock is real

The EU Cyber Resilience Act requires demonstrable, auditable firmware update capability for every connected device shipped into Europe from September 2026, meters included.

The stack

Three layers, one estate

On the battery meter

UltraMIN LwM2M client

A C11 client sized to the meter, not the reference board: 30KB flash / 8KB RAM at NoSec, growing feature-by-feature to the Carrier OTADM preset built for GSMA SGP.32 and carrier-class OTADM programmes.

  • PSK-DTLS, X.509 and Raw Public Key security; DTLS Connection ID (RFC 9146) intent on the mbedTLS provider
  • Version-aware Queue Mode registration, plus 3GPP Power Saving Mode, eDRX and application-forced deep sleep wired into the engine loop
  • RFC 7959 block-wise delta FOTA and LwM2M 1.2 SEND for scheduled, client-initiated reads
On the concentrator

UltraPRO LwM2M client

A C++17 client for multi-utility hubs, concentrators and gateway-class meters: the full OMA LwM2M V1.0 to V2.0+ feature set with the headroom constrained silicon doesn't have.

  • OSCORE and EDHOC for application-layer security over constrained links, alongside live-verified PSK, RPK and X.509 DTLS
  • Composite Read/Write (FETCH/iPATCH, RFC 8132) for reading a bank of registers in one round trip
  • LwM2M Gateway object (Object 25) surfacing every meter behind a concentrator as one managed session
Under the fleet

One-IoT™

The same carrier-grade core that runs Airtel's roughly 20 million daily API calls, operating the meter estate from first registration for the life of the asset.

  • Multi-tenant onboarding at fleet scale, zero-touch from first registration
  • Delta FOTA campaigns with canary staging, wave rollout and abort conditions
  • An audit trail for every firmware and configuration change, evidenced rather than asserted

A fifteen-year meter should be a fifteen-year asset, not a fifteen-year liability: the client sizing and the battery budget are engineering decisions made once, at the schematic, not discovered in year four.

Capability detail

What fleet-scale metering actually needs

Queue Mode

Battery

Version-aware Q registration so a meter that wakes once a day still holds a session the server can reach, without holding the radio open to do it.

PSM and eDRX

Battery

3GPP Power Saving Mode and extended DRX wired into the client's engine loop alongside application-forced deep sleep, so the client's idea of "awake" matches the modem's.

DTLS Connection ID

Roaming links

RFC 9146 support means a meter that gets a new IP after a NAT rebind or a PSM wake keeps its DTLS session, instead of paying battery for a full handshake every time.

Delta FOTA at scale

Maintenance

RFC 7959 block-wise transfer through Firmware Update Object 5, with canary and wave rollout from One-IoT, so a security patch across a million meters isn't a million full-image downloads.

SEND for periodic reads

Reporting

Client-initiated SEND in TLV, JSON, SenML-JSON or SenML-CBOR: the billing read that used to need a server poll is now one scheduled uplink the meter controls.

eSIM SGP.32

Connectivity

LwM2M Objects 504 and 3443 with an embedded IPAd: the operator relationship becomes a fleet decision for a meter that will outlive several connectivity contracts.

Modern transport security

Security

OSCORE (RFC 8613) and EDHOC on UltraPRO for concentrators that need application-layer security over constrained links, alongside PSK, RPK and X.509 DTLS.

Battery budget engineering

Design

Duty cycle, radio choice and reporting interval modelled against the meter's actual chemistry before the first board is ordered, not discovered in year four of fifteen.

Build packages

A named UltraMIN build for every point on the metering curve

UltraMIN ships as CMake build presets, not one client with feature flags nobody has size-tested. Each preset is measured against a hard binary-size cap, so a meter OEM knows the footprint before a single byte is compiled.

PresetFlash / RAM targetAdds
ultra-min-30k30KB / 8KB, NoSecRegister/Update/Deregister, Read/Write/Execute over plain CoAP. The floor.
ultra-min-sec-45k45KB / 10KBPSK-DTLS (TinyDTLS), Composite Read/Write (FETCH/iPATCH), SEND and Queue Mode
ultra-min-plus-55k55KB / 12KBObserve/Notify (RFC 7641) and the Bootstrap interface
ultra-min-max-60k60KB / 15KBFirmware Update Object 5 and Connectivity Monitoring (Object 4)
ultra-min-carrier-75k75KB / 18KBRFC 7959 block-wise delta FOTA, SenML-CBOR SEND, the carrier PAL surface (SIM/APN/modem/PSM/SMS/GPS) and DTLS Connection ID intent, built for GSMA SGP.32 eSIM and carrier-class OTADM programmes
ultra-min-metering~130KB classA vendor-neutral smart-meter build: the full IPSO Smart Object suite over the mandatory objects, Bootstrap, FOTA with verify, SenML-CBOR SEND, Queue Mode and block-wise, ready for any utility's meter programme out of the box

Utility-specific object suites, built to order: when a utility's meter specification defines its own proprietary object model on top of the metering baseline, an AMI variant supersets ultra-min-metering with that utility's object suite. Friendly has built one of these to order, under NDA, for a major water utility's digital-metering programme.

Every preset name is a CMake build target, not a marketing tier: 2,254 GoogleTest cases run against the codebase, ASan/UBSan clean. Platform ports relevant to metering include Nordic nRF91-series (LTE-M/NB-IoT) and nRF9161 bare-metal, Quectel BG95, and Raspberry Pi Pico for low-cost sensor nodes. For concentrator and multi-utility hub hardware, UltraPRO ships as five SKUs (std, m2m, esim, aiml, plus an OpenWrt/embedded-Linux gateway SKU in development), each built and tested against its own capability matrix rather than one binary with runtime flags.

Network topology

NB-IoT, LTE-M, Wi-SUN or wireless M-Bus: a site decision, not a company decision

No single radio wins every meter site. Deep-indoor and rural favour cellular LPWAN; dense urban utility grids favour mesh; short-range residential gas and heat favour wireless M-Bus. The point that matters: the LwM2M session behaviour, the security model and the management evidence are identical on every one of them.

TopologyBandwidthRangeWhere it wins
NB-IoT~20 to 250 kbps5 km urban, 15 km ruralDeep indoor metering, rural AMI, cellular power-saving modes
LTE-M (Cat-M1)~300 kbps to 1 Mbps5 km urban, 15 km ruralReal-time reads and mobile assets that need more bandwidth than NB-IoT
Wi-SUN (FAN)~50 to 300 kbps1 to 5 km per hopDense-urban utility grids, IPv6-native field area networks
RF Mesh~100 bps to 100 kbps100 m to 1 km per hopLarge-scale AMI on legacy mesh infrastructure, real-time monitoring
LoRaWAN~0.3 to 50 kbps5 km urban, 15 km ruralRural deployments and gateway-managed edge devices on unlicensed spectrum
Wireless M-Bus (EN 13757)~1 to 10 kbps100 m to 1 kmResidential gas and heat, short-range OMS-profile meter reading
Meter UltraMIN client Topology lane NB-IoT / LTE-M Wi-SUN / RF Mesh LoRaWAN / wM-Bus the deployment choice Concentrator UltraPRO client Gateway Obj 25 DLMS/COSEM HES Smart Grid Gateway One-IoT one estate Same LwM2M session behaviour and management evidence, whichever lane the site needs.
Protocol positioning

OMA LwM2M v1.2.2, next to DLMS/COSEM and OMS, not instead of them

These protocols aren't rivals answering the same question. DLMS/COSEM and OMS define what a meter measures and bills. LwM2M defines how a device is managed. A mixed estate needs both, bridged into one plane.

ProtocolWhat it definesWhere it's strongWhere LwM2M adds the rest
DLMS/COSEM (IEC 62056)Object-oriented metrology data model: registers, tariffs, load profiles, billing semanticsDeep, standardised electricity metering data model; entrenched HES ecosystemNo standard bootstrap, no FOTA state machine, no client lifecycle. Firmware and security management sit outside the spec
OMS / Wireless M-Bus (EN 13757)European short-range profile for water, gas and heat meter readingVery low power, simple residential meter reading, wide EU adoptionNo IP-native session, no observe/notify, no OMA-compliant firmware object
OMA LwM2M v1.2.2Device management protocol: bootstrap, security (PSK/RPK/X.509, DTLS Connection ID, OSCORE), Queue Mode, FOTA state machine, Object 25 gateway bridgingStandardised lifecycle across cellular, mesh and gateway-bridged topologies; IPSO and vertical object registryDoesn't measure the utility itself: that's what the metrology layer is for

On the roadmap: a Smart Grid Energy Management Gateway that bridges DLMS/COSEM, Wi-SUN and OMS directly into LwM2M, so a legacy electricity estate and a new-build water and gas rollout land on the same One-IoT management plane instead of two. If a mixed DLMS and LwM2M estate is the immediate problem, talk to us about the programme, not just the product.

Connectivity control

eSIM steering for a meter that outlives the contract

A meter installed today can still be reading in 2041. The operator relationship over that span should be a fleet decision, not a factory decision baked in with the SIM tray.

eIM fleet steering policy Meter IPAd eUICC UltraMIN / UltraPRO Objects 504 / 3443 Operator A profile enabled Operator B profile standby ESipa over LwM2M or direct RSP Steering runs as a campaign across the estate: enable, disable and swap profiles in waves, with the same canary discipline as firmware.
  • GSMA SGP.32 v1.2 implemented in UltraMIN and UltraPRO: LwM2M Objects 504 and 3443, embedded IPAd, over LwM2M or direct RSP transport
  • Vendor adapter seams for Thales, G+D, Kigen and other eUICC and eIM back-ends
  • Dual-profile survivability for sites where the primary operator drops coverage
  • Steering as a fleet campaign: waves, canaries and rollback, run from the same console as firmware
Pre-certification

Prove the build conforms before a utility signs off on it

The IoT Protocol Tester is Friendly's LwM2M certification and compliance platform: a vendor-neutral conformance bench for any client, server or bootstrap-server, run before a meter ships rather than discovered after a truck roll.

553 test cases

Conformance

Bootstrap, Registration, Device Management, Information Reporting, Security/OSCORE and Firmware Update categories, plus 34 wireline conformance cases per-message across every OMA LwM2M version from v1.0 to v2.0.

Live DTLS security matrix

Security

PSK, RPK, X.509 and NoSec exercised without a restart between modes, RFC 7925 mandatory cipher suites, and RFC 9146 DTLS Connection ID as a configurable test dimension, not an afterthought.

Wire Frame Viewer

Diagnostics

CoAP and DTLS frames decoded alongside the northbound operation that triggered them, in the same console, so a failed test case comes with the wire evidence attached.

12 compliance content packs

Coverage

Five OMA ETS packs spanning v1.0 to v2.0, the uCIFI Smart City pack (Objects 3400 to 3449, including smart water and smart lighting), and six cyber-security framework packs.

Custom object library

Meter OEMs

Vendor-private, DDF-defined objects load alongside the OMA registry, so a meter OEM's proprietary object model gets the same conformance discipline as the standard one.

Signed, tamper-evident reports

Evidence

Ed25519-signed YAML and PDF test reports: the audit trail a utility's acceptance process and a regulator's request both want, generated once and reused for both.

Proven on a real certification programme Friendly commissioned an LwM2M certification server for South East Water in Melbourne in 2017, dedicated to testing and certifying NB-IoT smart water meters from any vendor, one of the first programmes of its kind. More than twelve meter vendors were certified through it over the following eighteen months. Friendly has since authored bespoke acceptance test profiles for utility firmware-regression programmes at production scale, including a 60-case digital water-meter profile covering commissioning, leak and tamper alarms, interval event data, clock sync, FOTA and battery-life verification.
Fleet observability

DevGuard: the fleet's second pair of eyes

DevGuard is Friendly's closed-loop AIOps system, built for infrastructure generally and extending toward LwM2M fleets: monitor, detect, analyse, propose, approve, fix, verify, learn. It runs in the same demo environment as the rest of this stack, wired to real dashboards and a real approval gateway, not a slide.

Closed loop, human-gated

Live today

An eight-stage loop from monitoring to a verified fix, with every proposed change scored for risk and routed to the right number of approvers before anything touches production.

Tiered approval, not automation theatre

Live today

Low-risk dev-environment fixes can auto-apply; production changes always need two MFA-verified approvers at the highest risk tier. Nothing patches a meter fleet unattended.

LwM2M and DTLS wire-level analysis

On the roadmap

Decoding CoAP, DTLS and registration traffic to catch protocol deviations and security-conformance drift across a live fleet, the same discipline the IoT Protocol Tester applies pre-ship, continuously in production.

Code-level Auto-Fix

On the roadmap

Root-cause analysis that opens a pull request with a diff, a rollback plan and verification criteria. A human always reviews and merges it; DevGuard never commits on its own.

The Friendly IoT Journey, for meters

Conceptualise to supported fleet, one continuous programme

Most metering programmes fail in the gaps between vendors: the client that was never tested against the head-end, the certification bench that tested a build nobody manufactured. The Journey closes those gaps.

  1. Conceptualise

    Model the business case before the schematic: meter class, topology per site, battery chemistry and duty cycle, and which parts of the estate are new build versus DLMS/COSEM or OMS legacy to bridge.

  2. Start

    Prototype on reference hardware and prove registration, security and a real duty cycle before a single custom board exists.

  3. Design

    Choose the UltraMIN preset, from NoSec 30KB through the Carrier OTADM tier, or UltraPRO for concentrator-class hardware, and the topology lane per site.

  4. Develop

    Embed the client and wire Queue Mode, PSM, eDRX and DTLS Connection ID into the meter's actual power and radio budget, not a reference default.

  5. Test

    The IoT Protocol Tester runs the conformance and DTLS security matrix against the build, with signed evidence, before a unit ships. Not a spot check: the same 553-case catalogue a certification programme would run.

  6. Manufacture

    Provisioning, credential injection and SGP.32 profile assignment at the production line, evidenced and auditable from the first unit off it.

  7. Support and manage

    One-IoT operates the estate for the life of the asset: onboarding, delta FOTA campaigns, diagnostics, and DevGuard watching the fleet with the same conformance discipline the bench applied before launch.

Where it runs

Meter estates in the field

South East Water NB-IoT smart water meter certification programme
Water · certification

South East Water

Friendly commissioned an LwM2M certification server for South East Water in 2017, one of the first programmes of its kind: more than twelve NB-IoT smart water meter vendors certified through it since.

Electricity grid with DLMS/COSEM meters, bridging to LwM2M on the roadmap
Electricity · roadmap

DLMS/COSEM, bridging

Legacy and mixed-vendor electricity meters brought into the same management plane as LwM2M estates: the Smart Grid Gateway that does this is on the roadmap, not yet shipped.

Wireless M-Bus heat and gas meters on multi-year battery life
Gas and heat

OMS and wireless M-Bus

Short-range, multi-year battery meters managed alongside the cellular estate rather than in a separate system.

Multi-utility concentrator aggregating several meter types on one site
Multi-utility

Concentrator sites

UltraPRO gateway-class hubs aggregating several meter types on one site into a single managed LwM2M session.

Live water-meter operations dashboard with leak, backflow and low-battery alarms
Live demo

Not a slide

A running water-meter operations dashboard in the Friendly IoT Journey environment: leak, backflow, blockage and low-battery alarms, NB-IoT signal strength, real MQTT traffic end to end.

Wherever the programme is today

New programme, meter OEM, scaling estate, or a legacy estate to bridge

Starting a new metering programme: the client, the topology and the battery budget are engineering decisions made once, at the schematic. Prototype on reference hardware, prove the duty cycle, and the production client is the same one you tested.

A meter OEM needing pre-certification: the IoT Protocol Tester runs the conformance and DTLS security matrix a utility's acceptance process will eventually run, before the estate does it for you and before the first field failure does.

Scaling a live estate: the question stops being "does it work" and becomes "does it work at a million units, on a network billed per byte, with a firmware campaign nobody wants to run twice." Delta FOTA, canary staging and an audit trail are what make that campaign runnable.

Bridging a mature or legacy estate: DLMS/COSEM electricity meters, OMS gas and heat, and AMR that predates any of it don't need to be replaced to be managed. A Smart Grid Gateway to bring them into the same plane as the new build is on the roadmap; talk to us about sequencing the programme today.

Map the Journey onto your meter

Tell us the meter type and estate stage; we'll map client sizing, topology and a management architecture onto it.

Submissions route to Friendly's CRM. No newsletter, no drip by default.

One estate. Every meter type. Managed for the life of the asset.

Talk to a metering engineer