3. LwM2M 1.1
• Open Mobile Alliance (OMA
SpecWorks) standard for Device
Management and Service Enablement
• First release: July 10, 2018
• Designed for resource constrained
devices and working even over unstable
and low bandwidth networks (cellular,
sensor, LPWA radio networks etc.)
Transport
UDP, SMS, TCP,
LoRaWAN, Non-IP
Application layer CoAP
Payload
TLV, JSON, CBOR,
Opaque
Data model Defined
IPv6 YES
Security TLS, DTLS 1.2+
Standardization body OMA, IETF
Bandwidth consumption Low
5. COAP – CONSTRAINED
APPLICATION
PROTOCOL
• Binary protocol with HTTP-like
semantics (RESTful paradigm)
• Provides reliability over UDP
channel
• Designed for M2M
communication on constrained
devices
Transport UDP, TCP
Payload Undefined
Data model Undefined
IPv6 YES also 6LoWPAN
Security DTLS, TLS
Standardization body IETF
Bandwidth
consumption
Depends on payload
encoding
6. DTLS – DATAGRAM
TRANSPORT LAYER
SECURITY
• Supported by LwM2M and CoAP
• Provides security for datagram-based applications
• Prevents eavesdropping, tampering and message
forgery
• Provides security for transport layer – User
Datagram Protocol (UDP)
8. HOW DOES IT WORK?
• Information is exchanged between
LwM2M Server and LwM2M Client
(located on a device and radio module)
• Bootstrap interface is responsible for
provisioning the client with security keys
and information needed to register with
the Server
• Client Registration interface is needed to
perform „register” action enabling
functionality of device management and
telemetry on the device
• Device Management & Service Enablement
interface are used to access Client’s
resources
• Information Reporting interface is used to
obtain notifications about changes in values
of the resources
• As far as telemetry is concerned, Send
operation is used to send raw or buffered
data to the server in a form of unsolicited
notifications
10. LwM2M DATA MODEL
• Simple tree with maximum depth of 4
• Objects can have Object Instances
• Resources can have Resource Instances
• Maintained by OMNA
• Resources defined into certain data types:
string, integer, float, Boolean, opaque and
others
• Semi-open data model – there are standard
objects built-in, but you can also create your
own objects and decide whether to publish
them or not
11. IPSO SMART OBJECTS
• Ensuring interoperability
o Common design pattern
o Easily adjusted to new use cases
o Can be reused
• Editor of objects provided by OMA
o Ability to define your own objects
o Registering new objects with Open Mobile
Naming Authority (OMNA) for evaluation
13. SECURITY
• Security based on standard IoT protocols: Datagram
Transport Layer Security (DTLS) or Transport Layer
Security (TLS) both being utilized by CoAP
• Device authentication
• Ensured confidentiality and data integrity between
the Server and the Client
• 3 security modes:
o Certificates
o Raw public keys
o Pre-shared keys
• High bootstrap security requirements
14. MQTT
• Widely-adapted lightweight
telemetry protocol
• Uses Publish-Subscribe
messaging paradigm
• Available within majority of
IoT Platforms / IoT Hubs
Transport TCP
Payload Undefined
Data model Undefined
IPv6 YES
Security SSL/TLS
Standardization body OASIS, ISO
Bandwidth
consumption
Depends on payload
encoding
15. • LwM2M clearly defines payload and semantics of the
operations, while MQTT transports only custom
payloads
• MQTT ranks lower in the layering scheme than LwM2M
(placing on the same level as for example CoAP)
• LwM2M is a full-fledged device management protocol
• MQTT is a publish/subscribe type of
messaging/transport protocol
WHAT IS THE
DIFFERENCE BETWEEN
LwM2M AND MQTT?
19. • Simplifies deployments on public APNs
with NAT
• Improved Firewall traversal capabilities
• Simplifies loadbalancing (Azure, AWS,
Google Cloud)
• Uses more popular security layer (TLS
instead of DTLS)
LwM2M 1.1 – COAP OVER
TCP
20. LwM2M PROS
UDP (lack of problems with TCP exponential
backoff for mobile devices)
SMS binding
Standardized semantics (Object-Resource data
model, payloads)
Private Objects and Resources
Secure bootstrapping
Parametrized notifications
Very low bandwidth and memory usage
State-of-the-art security
Improved Device Management Interface and
Reporting Information Interface
New TCP binding supported by CoAP
Non-IP transport
Enabled asynchronous sending of resource values
in JSON/CBOR format thanks to Send operation
Enhanced bootstrapping
One technology for device management and
telemetry
Reduction of the fragmentation of IoT
21. LwM2M CONS
Existing Object-Resource data
models probably not sufficient
Devices supporting LwM2M mainly
consists of chipsets and radio
modules
Non-IP Data Delivery is not very
present in the market yet
Tight coupling with CoAP
UDP traffic treated harshly by
firewalls on public APNs
Probably not sufficient solution
for enterprise devices
22. • The most lightweight standard for device management available
• Universal: suited for resource constrained device (sensors,
actuators etc.) and unstable networks but can be used effectively
with more demanding devices (hubs, gateways etc.)
• Interoperable thanks to multi-layered architecture and well
defined data model
• Low-cost and plug-and-play solution able to handle the increasing
variety of IoT devices
• Expanding the M2M market by enabling device management in
industry segments that require sustainable business models
• Improved time-to-market by fulfilling not only device
management tasks but also enabling application data and services
LwM2M HIGHLIGHTS
23. ANJAY – LwM2M SDK
• Open source C99 library (Apache 2.0 license)
• Commercial support available
• Tested on different hardware architectures: Intel, ARM and
operating systems: Free RTOS, Linux, Android, Tread-X, Contiki
• Compatible with LwM2M 1.1 (only commercial version of
Anjay)
• Contains vendor-specific extensions
• Very little external dependencies (DTLS): mbedTLS or OpenSSL
• Available on Github: https://github.com/AVSystem/Anjay