LwM2M protocol
Introduction
LwM2M, for Lightweight Machine 2 Machine, is a communication protocol standard from the Open Mobile Alliance. It was designed specifically for remote device management and telemetry within the Internet of Things. Unlike MQTT, LwM2M fully specifies the application layer for device management and provides an extensive set of standard objects for telemetry data, enabling interoperability between objects and platforms from different vendors. LwM2M supports also optimized protocol headers and payload encodings to reduce bandwidth consumption and extend sensor’s battery lifetime.
Currently Live Objects LwM2M connector uses CoAPs for the message transfer by using IP connectivity and DTLS secure connections. In the future more connectivities and more security mechanisms will be available (TLS, OSCORE).
Live Objects implements 1.1 version of the protocol which includes the main features (the older version 1.0 of LwM2M protocol is also supported), in addition includes the specific features of device management and data management.
Live Objects provide the following features:
-
LwM2M standard features coming from the specification, which are the standardized interfaces between a lwm2m device and a lwm2m server (LiveObjects).
-
Higher Level features (mainly Device Twin) specific to LiveObjects which allows an advanced and industrial management of LwM2M devices and data, and which allows to benefit from all LiveObjects features also for lwm2m devices.
LwM2M protocol support
In the LwM2M common features, we find the main ones as specified in the OMA 1.0 and 1.1 specifications, here is the supported features as specified in LWM2M specifications.
Supported network stack
| Layer | Supported protocol |
|---|---|
Transport |
UDP |
Security |
DTLS 1.2 (using PSK identity + PSK key) |
Session |
|
Application |
LwM2M 1.0 supported features
| Legend | |
|---|---|
☑ |
Fully implemented |
☐ |
Not applicable |
⛔ |
Not implemented |
🚧 |
On roadmap |
Client registration
| Feature | Live objects implementation |
|---|---|
Register |
☑ |
Register update |
☑ |
De-register |
☑ |
Device Management
| Feature | Live objects implementation |
|---|---|
Read |
☑ |
Write |
☑ |
Execute |
☑ |
Create |
⛔ |
Delete |
⛔ |
Write attributes |
🚧 |
Discover |
⛔ |
Information Reporting
| Feature | Live objects implementation |
|---|---|
Observe |
☑ |
Passive cancel observation |
☑ |
Active cancel observation |
☑ |
Notify |
☑ |
Supported format
| Feature | Live objects implementation |
|---|---|
Plain-text |
☑ |
Opaque |
☑ |
Tlv |
☑ |
Json |
☑ |
Resource Model
| Feature | Live objects implementation |
|---|---|
Object |
☑ |
Object instance |
☑ |
Single Resource |
☑ |
Multi-instance Resource |
☑ |
Object Version |
☑ |
Security
| Feature | Live objects implementation |
|---|---|
NoSec |
🚧 |
Pre-Shared-Key |
☑ |
Raw-Public-Key |
⛔ |
X.509 |
⛔ |
Est |
⛔ |
Transport binding and mode
| Feature | Live objects implementation |
|---|---|
Udp |
☑ |
Queue Mode |
☑ |
Sms |
⛔ |
Access Control
| Feature | Live objects implementation |
|---|---|
Access Control |
☐ |
Attributes
| Feature | Live objects implementation |
|---|---|
Version |
☑ |
Dimension |
☑ |
Minimum Period |
☑ |
Maximum Period |
☑ |
GreateThan |
☑ |
LessThan |
☑ |
Step |
☑ |
LwM2M 1.1 supported features
| Legend | |
|---|---|
☑ |
Fully implemented |
☐ |
Non applicable |
⛔ |
Not implemented |
🚧 |
On roadmap |
Device Management
| Feature | Live objects implementation |
|---|---|
Read-Composite |
☑ |
Write-Composite |
☑ |
| Registration | Live objects implementation |
|---|---|
Supported content format (ct=<format>) |
☑ |
Information Reporting
| Feature | Live objects implementation |
|---|---|
Send |
☑ |
Observe-Composite |
☑ |
Cancel-Observe-Composite |
☑ |
Resource Instance Operation
| Registration | Live objects implementation |
|---|---|
Read |
☑ |
Write |
☑ |
Observe |
☑ |
Cancel observe |
☑ |
Write attributes |
☑ |
Supported additional formats
| Resource instance codec | tlv | txt | json | opaque | cbor | senml-json | senml-cbor |
|---|---|---|---|---|---|---|---|
encoding |
☑ |
☑ |
☑ |
☑ |
☑ |
☑ |
☑ |
decoding |
☑ |
☑ |
☑ |
☑ |
☑ |
☑ |
☑ |
| New data type | tlv | txt | json | cbor | senml-json | senml-cbor |
|---|---|---|---|---|---|---|
Unsigned Integer |
☑ |
☑ |
☑ |
☑ |
☑ |
☑ |
coreLnk |
⛔ |
⛔ |
⛔ |
⛔ |
⛔ |
⛔ |
| New Data Formats | Live objects implementation |
|---|---|
CBOR |
☑ |
senML-JSON |
☑ |
senML-CBOR |
☑ |
Resource Model
| New Attributes | Live objects implementation |
|---|---|
short server id |
☑ |
server URI |
☑ |
enabler version |
☑ |
epmin/epmax |
☑ |
Security
| Encryption type | Live objects implementation |
|---|---|
OSCORE |
🚧 |
Certificate Usage |
⛔ |
Transport binding and mode
| Protocol stack | Live objects implementation |
|---|---|
Tcp |
⛔ |
LoRa® |
⛔ |
CIoT |
🚧 |
Live Objects integration features
Additionally, the Live Objects service provides the LwM2M device management and specific device representation implemented behind the LwM2M device interface (Live objects connector):
-
Live Objects integration features
-
LwM2M devices are included in the unified inventory API (covering all connectivities : LwM2M, MQTT, SMS, LoRa, external connector). LwM2M connectivity configuration (include multi-connectivity).
-
Twin capability management service to manage the LwM2M device objects and stores the latest LwM2M device ressource values.
-
Custom object management to define and register the OMA owners objects.
-
-
Specific features
-
Live Objects exposes an API that can managing the operations on a given device and monitoring the results of each operation.
-
To improve the usage in a disturbed network environment, retrieving a device representation of a resource and keep this representation updated by the server over a period of time is persistent. when this happens, and after a device re-register, the OBSERVE operations are automatically reactivated then persisted by the TWIN service.
-
In the other hand, RFC 7641 tries to sync the "most recent state" and doesn’t care about a "complete history". But in Live Objects the complete /part history can be retrieved using the DataRule. The user can configure a datarule, when triggering, the rule generate and store the uplink message sended by the device.
-
In a bad network environment, the retrieval of resource values from a device and their updating by the server over a period of time can be affected. The resources objects are persistent even when there are many disconnections or packet loss due bad network QOS. When this happens, and after a device re-register, Live Objects automatically reactivate the OBSERVE operations which are then persisted by the TWIN service.
-
-
Common features used in the Live Objects environment
-
LwM2M datamessage stream management (Uplink).
-
LwM2M datamessage decoding.
-
Firmware update.
-
Telemetry data sampling in time series, enrichment and pushing to multiple platforms using Live Objects Custom Pipelines and Datamessage Routing.
-
Telemetry data vizualisation widgets using Live Objects Data Store & Search.
-
Alarms and notifications on LwM2M device behavior and telemetry data.
-
Data formats
Live Objects supports all data formats defined in the LwM2M v1.1 specification.
A client supporting LwM2M v1.0 must support TLV as stated in the LwM2M V1.0 specification (chapter 6.4). A client supporting LwM2M v1.1 must support Plain Text, Opaque, CoRE Link and at least one of SenML CBOR or SenML JSON.
If supporting optional data formats a LwM2M client may inform the server by including them in the Register operation.
When sending a Write Request or a Composite Request, Live Objects encodes the payload with a data format selected from those that are mandatory for the client and those that are declared as supported by the client (sent in the Register operation). The following rules apply:
| LwM2M version | request on a singular resource* | request on multiple resources* | composite request |
|---|---|---|---|
v1.0 |
|
|
N/A |
v1.1 |
|
|
|
The preferred response data format can be specified by Live Objects for Read, Observe, and their composite variants. If not specified, the client uses its own preferred format. The following rules apply:
| LwM2M version | request on a singular resource* | request on multiple resources* | composite request |
|---|---|---|---|
v1.0 |
not specified |
not specified |
N/A |
v1.1 |
not specified |
not specified |
|
- *Request on a singular resource
-
Request targeting a single Resource (ex: /3442/0/110) or a multiple Resource Instance (ex: /3442/0/1110/0).
- *Request on multiple resources
-
Request targeting either an Object Instance (ex: /3442/0) or a multiple Resource (ex: /3442/0/1110).
LwM2M endpoints
CoAP server URI
For the LwM2M protocol, only secured CoAP binding is supported using DTLS Pre-Shared Key (PSK). The command bellow will bind the Live objects LwM2M server to the server CoAP interface. It known as Live objects LwM2M server URI.
coaps://lwm2m.liveobjects.orange-business.com:5684Device identifier : Endpoint Name
Known as endpoint client name in OMA specifications. It should be provided to the LwM2M Server during Registration, also should be provided to LwM2M Bootstrap-Server when executing the Bootstrap procedure when is available. This identifier must respect the URN format.
Bootstrap server URI
For the LwM2M protocol, only secured CoAP binding is supported using DTLS Pre-Shared Key (PSK). The command bellow will bind the Live objects LwM2M bootstrap server to the server CoAP interface. It known as Live objects Bootstrap LwM2M server URI.
coaps://bootstrap.lwm2m.liveobjects.orange-business.com:5684Secure your LwM2M connection
Security and encryption
To securing CoAP and due to using UDP with datagram packets without connexion, we optimize the computing effort on the device side (power low consumption), the CoAP transport layer uses the DTLS with a Pre-Shared Key (PSK) to secure the communications between Live Objects and the device fleets. This includes the paired "PSK identity" and shared secret to be used with the Live Objects platform.
|
DTLS 1.2 is used, to provision and configure your device, you need:
To learn more, see this section. |
As specified in the CoAP rfc7252 specifications, devices should support the Server Name Indication (SNI) to indicate their authority in the SNI HostName field as defined in section 3 of RFC6066. This is needed so that when a host that acts as a virtual server for multiple authorities receives a new DTLS connection, it knows which keys to use for initialise the DTLS session.
DTLS Ciphers suite
During a device register steps, a DTLS session (1.2) use a PSK (Pre-Shared Key) mode. In this case, the device need a mandatory-to-implement cipher suites as specified in the CoAP rfc7252 specifications.
|
Supported ciphers are (static list) :
|
LwM2M device register simulation
Once the identity provisioned, the device can perform a register on the server, which mean that the device is ready to receive a LwM2M messages (CoAP). During this request, the device presents its supported object definitions.
The following sample will provide a simulator in Java:
-
Prerequisites : Java development kit installed on your system (JDK), A PSK and PSK identity correctly generated then provisioned in the device interface.
-
Download the Leshan client demo artifact.
-
To register the device in Live Objects, run the following commands :
java -jar leshan-client-demo.jar -u lwm2m.liveobjects.orange-business.com:5684 -n <endpoint LWM2M> -i <PSK_identity> -p <PSK_KEY>
| Where : -n <endpoint LWM2M>, -i <PSK_identity>, -p <PSK_KEY> hex format. |
-
You should see the DeviceTwin in the Parc menu (select LwM2M device twin tab) of your portal.
-
You should be able to apply the operations ( read,write,execute) on a device and see the results in the Parc menu (select LwM2M operation tab) of your portal.
-
If your device can reports value changes while sending data, under certain conditions, you can see the generated data messages in the data menu (select Data messages tab) of your portal.
|