LwM2M IoT Device Management Architecture (2026)

A cellular water meter with 128 KB of RAM, an 8-year battery budget, and a radio it is only allowed to wake for a few seconds a day is not going to run an MQTT client, a JSON parser, and a TLS 1.3 stack with certificate chains — and it certainly is not going to hold a persistent TCP socket open behind a carrier-grade NAT. Yet someone still has to provision it, watch its battery, patch its firmware, and rotate its keys for a decade. This is the constrained-fleet device-management problem, and it is exactly the problem LwM2M device management was designed to solve. LwM2M — the Open Mobile Alliance Lightweight M2M standard, now stewarded by OMA SpecWorks — gives you a compact, binary, RESTful device-management protocol that runs over CoAP and DTLS on hardware where a general-purpose cloud SDK will not fit.

This post is a working architect’s reference, not a marketing overview. We will walk the full data model, the four interfaces, the transport and security stack with exact RFCs, the firmware-update object, and a concrete reference deployment — then get honest about the failure modes.

What this covers: the LwM2M object/resource data model, its four interfaces, CoAP/DTLS/OSCORE transport, bootstrap and identity, FOTA over object /5, queue mode, a reference deployment, scaling and NAT considerations, and where LwM2M beats — and loses to — MQTT/Sparkplug and proprietary cloud device management.

Context and Background

Device management for constrained fleets splits into a handful of durable jobs: get a device its first credentials and server address (bootstrap), let it announce itself and stay reachable (registration), read and write its configuration and state (management), stream its telemetry efficiently (reporting), and update its firmware safely (FOTA). Before LwM2M, each vendor solved these with a bespoke, mutually incompatible cloud agent. The result was fleets locked to one cloud and gateways that could not be reused.

LwM2M standardises those jobs. Version 1.0 was published in 2017; 1.1 (2018) added CoAP over TCP and non-IP transports; version 1.2 followed in November 2020, adding transport bindings for HTTP and MQTT, application-layer security via OSCORE, and integration with DTLS 1.3. A maintenance release, 1.2.2, landed in June 2024 with interoperability and bug fixes, and OMA SpecWorks has confirmed that LwM2M 2.0 is under development as of late 2025, targeting larger-scale deployments. OMA SpecWorks itself was formed in 2018 through the merger of the Open Mobile Alliance with the IPSO Alliance, which is why the object registry inherits IPSO’s smart-object modelling.

The incumbents LwM2M competes with are proprietary cloud device-management stacks — AWS IoT Device Management and Azure IoT Hub / Device Provisioning Service — and the publish/subscribe world of MQTT and Sparkplug. LwM2M is not a telemetry bus; it is a management plane. That distinction, more than any feature checklist, is what should drive your choice. The canonical open reference implementation is the Eclipse Foundation’s Leshan project (server-side) with Eclipse Wakaama and Anjay on the device side, and it is the fastest way to see the protocol behave.

The LwM2M Reference Architecture

At its core, LwM2M is a client/server protocol where the device is the server of its own resources and the management platform acts as the client that reads, writes, and executes on them. A device runs an LwM2M client that exposes a tree of standardised objects; one or more LwM2M servers talk to that tree; and a separate bootstrap server hands the device its initial configuration and credentials. North-bound, the LwM2M server exposes those resources to your digital-twin, PLM, or analytics platform through a REST or messaging API.

In one paragraph: an LwM2M deployment is a constrained device running an LwM2M client that first contacts a bootstrap server to receive its security and server configuration, then registers with an LwM2M server over CoAP secured by DTLS, after which the server reads, writes, observes, and executes resources — including pushing firmware — while a north-bound platform consumes the resulting device state.

Figure 1: A reference LwM2M deployment — the device bootstraps, registers, is observed, and receives FOTA, with a north-bound platform consuming state.

The figure traces the four operational phases across a real deployment. The device first reaches the bootstrap server, which writes the Security (/0) and Server (/1) objects. The device then registers with the LwM2M server over DTLS-secured CoAP. The server observes resources and forwards notifications to an integration API, which populates a device-state store — often the same twin registry that feeds a unified namespace on the plant floor. Management and firmware operations flow back down the same secured channel.

The device is a tree of Objects, Instances, and Resources

Everything in LwM2M is addressed by a three-level path: /ObjectID/InstanceID/ResourceID. An Object is a type — Device, Firmware Update, Connectivity Monitoring. An Object Instance is a concrete occurrence of that type; a device can have multiple instances of the Server object if it talks to multiple servers. A Resource is a single readable, writable, or executable field. So /3/0/9 means “object 3 (Device), instance 0, resource 9 (Battery Level)”. This URI structure is not incidental — it is the CoAP path, so reading a resource is literally a CoAP GET on that URI.

Figure 2: The Object / Instance / Resource tree exposed by a single LwM2M client, showing well-known object IDs.

Object IDs 0–1023 are reserved for OMA-registered objects; the public registry at OMA SpecWorks assigns them. The well-known ones you will touch on almost every device are Security (/0), Server (/1), Access Control (/2), Device (/3), Connectivity Monitoring (/4), Firmware Update (/5), Location (/6), and Connectivity Statistics (/7). Vendor and third-party objects use IDs from higher ranges. Because the model is standardised, a fleet-management platform can read /3/0/9 for battery on a meter, a tracker, and a streetlight without knowing anything vendor-specific.

The well-known objects, concretely

The Device object (/3) is your fleet’s health baseline: manufacturer, model, serial, firmware version, available power sources, battery level, error codes, and a Reboot executable resource at /3/0/4. Connectivity Monitoring (/4) exposes radio technology, signal strength (RSRP/RSRQ on cellular), link quality, cell ID, and the device’s current IP addresses — indispensable when a device goes quiet and you need to know whether it is a radio problem or an application crash. Security (/0) holds bootstrap and server credentials and is deliberately not readable over the normal management interface. Server (/1) holds the registration lifetime, default minimum/maximum reporting periods, and the binding mode.

Here is a compact path table you would keep next to any integration:

Resource path	Object / Resource	Typical use
/3/0/0	Device / Manufacturer	Inventory, asset tagging
/3/0/3	Device / Firmware Version	Fleet patch-state audit
/3/0/9	Device / Battery Level	Predictive replacement
/3/0/11	Device / Error Code	Fault triage
/4/0/2	Connectivity / RSSI or RSRP	Signal diagnostics
/5/0/1	Firmware / Package URI	Pull-mode FOTA source
/5/0/3	Firmware / State	Update state machine
/1/0/1	Server / Lifetime	Registration TTL

The four interfaces

LwM2M organises all operations into four interfaces. Bootstrap provisions the device with credentials and server URIs. Registration lets the client announce itself, its objects, and its lifetime to the server, and refresh or de-register. Device Management and Service Enablement carries the request/response operations — Read, Write, Execute, Create, Delete, Write-Attributes, and Discover — the platform uses to manage the device. Information Reporting is the asynchronous half: the server sends an Observe on a resource or object, and the client streams Notify messages when values change, governed by attributes like minimum and maximum period. These four interfaces map cleanly onto CoAP methods and the CoAP Observe extension (RFC 7641), which is what makes the protocol so compact on the wire.

The operations are more granular than “read and write” implies, and the granularity is what makes the model efficient. Read can target a single resource (/3/0/9), a whole object instance (/3/0), or an entire object (/3), returning a SenML or TLV bundle in one round-trip rather than a request per field. Write similarly supports partial update (replace only the resources named) or full replace of an instance. Execute triggers an action with no persistent value — Reboot, Factory Reset, or the firmware Update itself — optionally passing arguments. Create and Delete manage instances of multi-instance objects at runtime; Discover returns the object/resource structure and its attached attributes so a server can learn what a device actually supports before it acts. Write-Attributes is the one that governs reporting: it sets the pmin, pmax, gt, lt, and step attributes that later shape every Notify.

Access Control and the multi-server case

A device is not limited to one server. It may register with several LwM2M servers — a manufacturer’s fleet server, an operator’s management server, an application server — each represented by its own instance of the Server object (/1). When multiple servers can touch the same device, the Access Control object (/2) arbitrates: each protected object instance gets an ACL entry naming which server (by Short Server ID) holds which rights — Read, Write, Execute, Delete, or Create. One server is designated the Access Control Owner and can amend the ACLs. On a single-server device the object is optional and access defaults to full, which is why many simple deployments never touch it; but the moment two parties share a device, /2 is what prevents the application server from, say, rewriting the security configuration the operator owns.

Transport, Security, and the FOTA Walk-through

LwM2M rides on the Constrained Application Protocol (CoAP), defined in RFC 7252 — a compact, binary, RESTful protocol with a four-byte header, confirmable and non-confirmable messages, and the same GET/PUT/POST/DELETE verbs you know from HTTP, mapped onto the LwM2M operations. The default binding is CoAP over UDP, which suits sleepy, NAT’d, lossy-radio devices far better than a long-lived TCP connection. Since 1.1 you can also bind CoAP over TCP and TLS (RFC 8323) where a stateful firewall or middlebox demands it, and 1.2 added HTTP and MQTT transport bindings for gateway and cloud-integration scenarios.

Block-wise transfer moves big payloads through small buffers

A firmware image is far larger than a single CoAP datagram — and a constrained device cannot buffer a megabyte anyway. CoAP block-wise transfer (RFC 7959) chunks a large resource into a sequence of blocks (Block1 for requests such as a firmware push, Block2 for responses), each carrying a block number, a “more” flag, and a negotiated block size down to 16 bytes. The receiver reassembles incrementally, so a device with a few kilobytes of RAM can accept a 700 KB image without ever holding it whole. This is the mechanism that makes push-mode FOTA feasible on the smallest hardware.

Security: DTLS, and OSCORE for end-to-end

For UDP transport, LwM2M secures the channel with DTLS 1.2, and version 1.2 integrates DTLS 1.3. DTLS provides confidentiality, integrity, and mutual authentication, and its session-resumption mechanism matters enormously for sleepy devices: a full handshake is several round-trips and a lot of energy, so resuming an existing session on wake-up — rather than renegotiating — is often the difference between an acceptable and an unacceptable battery budget.

LwM2M 1.2 also adds OSCORE (Object Security for Constrained RESTful Environments, RFC 8613), which secures the CoAP message at the application layer rather than the transport. Because OSCORE protects the payload independent of the underlying transport, it survives proxies and gateways that would otherwise terminate DTLS, enabling genuine end-to-end security from device to server across an intermediary. You can run OSCORE with or without DTLS, and over UDP, TCP, or SMS.

Figure 3: The end-to-end lifecycle — bootstrap, registration, observation, and a firmware update — as a message sequence.

Identity and bootstrap: PSK, RPK, and X.509

A device needs a credential and a server address before it can do anything. LwM2M supports three credential modes. Pre-Shared Key (PSK) is a symmetric key provisioned per device — simplest to deploy, but key distribution and storage is the whole game. Raw Public Key (RPK) uses an asymmetric key pair without a certificate chain, giving you public-key security without PKI overhead. X.509 certificates bring full PKI, chain validation, and revocation, at the cost of larger handshakes and certificate management. The bootstrap server’s job is to write these into the Security object (/0) — plus the LwM2M server URI and access-control configuration — either at first boot (factory bootstrap) or on demand when a device fails to register (client-initiated bootstrap). Because bootstrap is a distinct interface with its own credentials, you can rotate server-facing keys for the whole fleet without touching the factory-burned bootstrap secret, which is the property that makes 10-year key hygiene tractable. Device provisioning and attestation deserve their own treatment; see the device identity and attestation architecture for the deeper security model.

Registration lifecycle and lifetime

After bootstrap, the client sends a Register operation to the LwM2M server carrying its endpoint name, the list of objects and instances it supports, and a lifetime in seconds. The server replies 2.01 Created with a registration location. The client must send an Update before the lifetime expires, or the server considers it gone and drops the registration. Lifetime is a direct trade-off: a short lifetime detects dead devices quickly but forces frequent keepalive traffic that drains battery and, on cellular, costs money; a long lifetime saves power but leaves stale registrations lingering. For deep-sleep devices, lifetime is tuned in concert with queue mode rather than in isolation.

Queue mode for sleepy devices

Constrained devices spend most of their life with the radio off. Queue mode (a binding behaviour) tells the server that the client is not always reachable: instead of expecting an immediate response, the server queues downlink operations — a Write, an Execute, an Observe — and delivers them the next time the client is awake and sends any message. The client signals liveness by transmitting; the server flushes the queue in that window. This inverts the usual always-connected assumption and is what lets a battery device sleep for hours yet still receive commands, at the cost of command latency bounded by the wake interval.

FOTA: the Firmware Update object

Firmware over-the-air is where LwM2M earns its keep on a constrained fleet, and it is modelled entirely through the Firmware Update object (/5). The object exposes a Package resource (/5/0/0) for push delivery — the server writes the image directly, block-wise — and a Package URI resource (/5/0/1) for pull delivery, where the server writes a URI and the device fetches the image itself, typically over CoAP or HTTP. Pull scales better because the device pulls from a CDN or file server rather than streaming through the management server; push gives the server tighter control and works when the device cannot reach an external URL.

Figure 4: The Firmware Update object state machine — Idle, Downloading, Downloaded, Updating — with result codes and rollback.

The State resource (/5/0/3) exposes a well-defined machine: Idle → Downloading → Downloaded → Updating, with an Update Result resource (/5/0/5) reporting success or a specific failure (not enough storage, out of memory, connection lost, integrity-check failure, unsupported package). The server observes State and Update Result to track progress across the fleet. Critically, the object’s design assumes the device implements integrity verification and rollback: a good bootloader keeps the prior image, applies the new one, and reverts if the new image fails to boot or fails a post-update health check. LwM2M gives you the orchestration and reporting; the safety net is the device’s A/B partition scheme. For the full secure-update pattern — signing, staged rollout, and rollback — see the secure OTA firmware update architecture.

Content formats: SenML, CBOR, and TLV

LwM2M has to encode resource values compactly. It supports several content formats: plain text and opaque for single resources; TLV (a compact type-length-value binary format defined by LwM2M itself); SenML JSON and SenML CBOR (RFC 8428), the Sensor Measurement Lists format that carries resource paths, values, and timestamps; and CBOR for single resources. SenML CBOR is usually the sweet spot for multi-resource reads on constrained links — it is self-describing like JSON but binary and compact like TLV. A device advertises which formats it supports, and the server negotiates via the CoAP Content-Format and Accept options, exactly as HTTP content negotiation works.

Here is an illustrative registration payload (CoRE Link Format) a client sends on Register, listing its supported objects and instances:

POST /rd?ep=meter-4471&lt=86400&lwm2m=1.2&b=UQ
Content-Format: application/link-format

</3/0>,</4/0>,</5/0>,</1/0>,</1/1>

The ep is the endpoint name, lt the lifetime in seconds, lwm2m the protocol version, and b=UQ requests UDP with queue mode. The body enumerates the object instances the server may now manage.

Scaling the server and the deployment topology

The LwM2M server’s dominant cost at scale is not throughput but state. Every registered device is a live DTLS association plus a registration record with a lifetime timer; a million devices is a million security contexts and a million timers, not a million requests per second. That shape favours horizontal scaling of stateless-ish front ends behind a shared registration/security store, with two hard constraints. First, DTLS is connection-oriented state, so a datagram from a given device must reach the node holding its session — you route by DTLS connection ID, not by the source IP/port tuple, because NAT rebinding changes the tuple mid-session. Second, Observe subscriptions are held per server node, so notification fan-out to the north-bound platform has to be decoupled through a queue or event bus rather than handled inline, or a notification burst will back-pressure the CoAP layer.

Topologically, keep the bootstrap server separate and lightly loaded — it is touched rarely (first boot, credential rotation, recovery) but is the most security-sensitive node, so isolating it limits blast radius. Put a load balancer that understands DTLS connection ID in front of the LwM2M server tier. Behind the server, an integration layer translates the object/resource model into your platform’s schema and writes to the twin registry; this is also where you enforce back-pressure and dedup. For very large or intermittently connected fleets — NB-IoT metering is the canonical case — an LwM2M gateway (standardised in 1.2) can aggregate many downstream devices behind a single registration, which cuts the server-side context count dramatically at the cost of a more complex gateway.

Trade-offs, Gotchas, and What Goes Wrong

LwM2M is elegant, but a real fleet exposes its sharp edges, and most incidents cluster around the same handful of failure modes.

Lost registrations. If a device misses its lifetime-window Update — because the radio was down, the battery browned out, or a NAT binding expired mid-sleep — the server drops the registration and the device effectively vanishes until it re-registers. Over-aggressive lifetimes turn transient radio outages into a storm of re-registrations. The fix is to tune lifetime against the real wake cadence and to make re-registration cheap via DTLS session resumption.

NAT and keepalive. UDP behind carrier NAT is the classic trap. NAT mappings for UDP expire quickly — often tens of seconds to a couple of minutes — so a device that sleeps longer than the mapping lifetime becomes unreachable for downlink until it next transmits. You either send periodic keepalives (which costs power and money), rely on queue mode so the server only pushes during a known-awake window, or accept that all management is device-initiated-window-bounded. There is no free lunch; NAT is a physical constraint, not a protocol bug.

DTLS session resumption failures. Session resumption is what makes DTLS affordable on battery devices, but resumption state can be lost on either side — a server restart, a load-balancer that rehashes the connection to a different backend, or a device that dropped its session cache. When resumption fails, the device must do a full handshake, and a fleet reconnecting simultaneously after a server bounce can produce a handshake thundering herd. Sticky routing by DTLS connection ID (a DTLS 1.2 extension and native in 1.3) and jittered reconnect backoff are the mitigations.

FOTA rollback and bricking. The most expensive failure. If a device applies an image that boots but is subtly broken — a bad radio config that prevents it from ever reaching the server again — no amount of protocol design saves you; the device is dark. This is why the update object assumes A/B partitions and a watchdog-gated health check that auto-reverts. Never ship a FOTA campaign without a proven rollback path and a staged rollout that halts on rising Update-Result failures.

Observation storms. Set the minimum period too low, or Observe a rapidly changing resource across a large fleet, and every device notifies constantly — saturating the server, the link, and your ingestion pipeline. Worse, a synchronized event (a power blip that reboots a district of streetlights) makes them all re-register and re-notify at once. Rate-limit with the minimum-period and greater/less-than attributes, use non-confirmable notifications where loss is tolerable, and design ingestion to shed load gracefully rather than collapse.

LwM2M vs MQTT/Sparkplug vs Proprietary Cloud DM

Choosing between these is not a feature bake-off; it is about which layer of the stack you are solving for. LwM2M is a device-management protocol with a standardised data model. MQTT is a transport — a pub/sub bus with no data model — and Sparkplug adds a state-management payload spec on top of MQTT for industrial telemetry. Proprietary cloud device management (AWS, Azure) gives you turnkey management but binds device modelling to one vendor’s cloud.

Dimension	LwM2M	MQTT / Sparkplug	Proprietary cloud DM
Primary role	Device management + model	Telemetry transport / SCADA state	Turnkey management + telemetry
Data model	Standardised objects/resources	None (MQTT) / Sparkplug metrics	Vendor-specific device shadow/twin
Default transport	CoAP/UDP (also TCP, non-IP)	TCP (MQTT), long-lived socket	MQTT/HTTPS, TLS
Footprint on device	Very small (KB-class RAM)	Small, but needs persistent TCP	SDK-heavy, larger
Security	DTLS 1.2/1.3, OSCORE, PSK/RPK/X.509	TLS + app-level auth	TLS + cloud IAM
Standard FOTA	Yes (object /5)	Not defined by spec	Vendor FOTA service
Sleepy-device fit	Strong (queue mode, UDP)	Weak (TCP keepalive cost)	Varies
Lock-in risk	Low (open standard)	Low transport, model varies	High

The honest reading: if your devices are deep-sleep, cellular/NB-IoT, battery-powered, and you need standardised firmware update and management without cloud lock-in, LwM2M is the natural fit. If you are moving high-rate telemetry between always-on industrial gear and a SCADA or unified namespace, MQTT with Sparkplug is the better bus — and many real systems run both, LwM2M for management and MQTT for the data plane. If you want zero protocol engineering and are comfortable inside one cloud, the proprietary services are fastest to ship but hardest to leave.

Practical Recommendations

Start from the device’s power and reachability budget, because those constraints cascade into every other choice. If devices sleep, commit to CoAP/UDP with queue mode from day one; retrofitting queue mode onto an always-connected design is painful. Pick your credential mode by fleet economics: PSK for cost-sensitive high-volume fleets where you control provisioning end to end, RPK when you want asymmetric security without PKI overhead, and X.509 only when you genuinely need chain validation and revocation and can run the PKI to support it. Separate the bootstrap credential from the operational server credential so you can rotate the latter without a truck roll.

A short pre-production checklist:

• [ ] Lifetime tuned against real wake cadence, verified against NAT mapping timeouts on your carrier.
• [ ] DTLS connection ID enabled and sticky routing configured, with jittered reconnect backoff to avoid handshake herds.
• [ ] FOTA uses A/B partitions, signed images, integrity check on /5/0/5, and a watchdog-gated auto-rollback.
• [ ] FOTA rollout is staged and halts automatically on rising Update-Result failures.
• [ ] Observe attributes (minimum/maximum period, gt/lt/step) set to bound notification volume before scale testing.
• [ ] SenML CBOR or TLV chosen for multi-resource reads; content-format negotiation tested against every firmware variant.
• [ ] Bootstrap and operational credentials separated; key-rotation procedure rehearsed.

Validate the whole lifecycle against Eclipse Leshan before you build the north-bound integration; it will surface most model and negotiation mismatches in an afternoon.

Frequently Asked Questions

What is the current version of LwM2M in 2026?

The current stable release is LwM2M 1.2, published by OMA SpecWorks in November 2020, with a maintenance release 1.2.2 delivered in June 2024 for interoperability and bug fixes. Version 1.2 added HTTP and MQTT transport bindings, OSCORE application-layer security, and DTLS 1.3 integration on top of the 1.1 baseline. OMA SpecWorks has confirmed that LwM2M 2.0 is under development as of late 2025, aimed at larger-scale deployments, but 1.2.x remains what you deploy today.

How does LwM2M handle firmware updates?

Firmware updates use the Firmware Update object (/5). The server either pushes the image directly to the Package resource /5/0/0 using CoAP block-wise transfer, or writes a URI to /5/0/1 and lets the device pull the image itself. The device advances through a State machine — Idle, Downloading, Downloaded, Updating — and reports outcome in the Update Result resource /5/0/5. Safe rollback is the device’s responsibility, typically via A/B partitions and a bootloader that reverts if the new image fails a post-update health check.

What transport and security does LwM2M use?

LwM2M runs over CoAP (RFC 7252), by default on UDP, with optional CoAP over TCP/TLS (RFC 8323) and, since 1.2, HTTP and MQTT bindings. Large payloads use CoAP block-wise transfer (RFC 7959). Security is DTLS 1.2 or 1.3 for the transport channel, plus OSCORE (RFC 8613) for end-to-end application-layer security that survives proxies. Devices authenticate with Pre-Shared Keys, Raw Public Keys, or X.509 certificates provisioned through the bootstrap interface.

When should I choose LwM2M over MQTT?

Choose LwM2M when you need standardised device management — bootstrap, registration, configuration, and firmware update — on constrained, often battery-powered and NAT’d devices, and you want to avoid cloud lock-in. Choose MQTT (with Sparkplug for industrial state) when your priority is a high-rate telemetry bus between always-connected devices and a SCADA or broker. They are not mutually exclusive: many deployments use LwM2M as the management plane and MQTT as the data plane in the same fleet.

What is queue mode and why does it matter?

Queue mode is a binding behaviour that tells the LwM2M server the client is not always reachable. Rather than expecting immediate responses, the server queues downlink operations and delivers them the next time the client transmits and is briefly awake. This lets deep-sleep, battery-powered devices remain manageable without holding a connection open or answering constant keepalives. The trade-off is command latency: a downlink operation waits until the device’s next wake window, so worst-case latency is bounded by the sleep interval.

How does LwM2M deal with NAT and sleepy devices?

By defaulting to CoAP over UDP and using queue mode, LwM2M avoids the persistent-TCP keepalive cost that kills battery life behind carrier NAT. Because UDP NAT mappings expire quickly, the server only reliably reaches a device during its self-initiated wake window, so all downlink management is timed to that window. DTLS connection ID and session resumption keep reconnection cheap after sleep, and lifetime is tuned so a device that wakes on its normal cadence refreshes its registration before it is dropped.

Further Reading

• Secure OTA firmware update architecture for IoT — the full signing, staged-rollout, and rollback pattern behind object /5.
• IoT device identity and attestation architecture — the deeper security model behind bootstrap credentials and key rotation.
• Unified namespace architecture for industrial IoT — how device state feeds a plant-wide data backbone.
• OMA SpecWorks LwM2M — the authoritative specification and public object registry.
• RFC 7252: The Constrained Application Protocol (CoAP) — the transport LwM2M is built on.
• Eclipse Leshan — the reference open-source LwM2M server and client implementation.

By Riju — about