Toward a Correct Implementation of LwM2M Client with Event-B

Ines Mouakher

, Fatma Dhaou

and J. Christian Attiogb

University of Tunis El Manar, Tunis, Tunisia

University of Nantes, Nantes, France

Keywords:

IoT, Device Management, OMA LwM2M, Formal Veriﬁcation, Event-B.

Abstract:

Within the Internet of Things (IoT), billions of connected devices can collaborate anytime, anywhere and in

any form in various domains of applications. These devices with minimal storage and computational power

are based on standards and lightweight protocols. Due to the critical nature of application domains of the IoT

systems, the veriﬁcation of various properties is crucial. To this end, the beneﬁts of using formal methods are

widely recognized.

In this paper, we present an approach that integrates modelling and veriﬁcation techniques, required for the

speciﬁcation of IoT systems, by exploiting the OMA Lightweight M2M (LwM2M) enabler. We propose a

formal model of the LwM2M client, which is located in an LwM2M device, by building several mathematical

models of discrete transition systems using Event-B. Indeed, we opt for a systematic and reﬁnement-based

approach that helps us to model and to verify gradually the speciﬁcation. The Rodin tool is used to specify

and verify the Event-B models. The generated Event-B models allow us to analyze and verify the behavior of

LwM2M client that supports the latest LwM2M 1.1 version. Furthermore, it is a ﬁrst step towards providing

formally proven LwM2M client implementations.

1 INTRODUCTION

The IoT ﬁnds applications in various areas such as au-

tomotive, home automation, smart cities, energy ef-

ﬁciency, industry, agriculture, health, education and

others. The IoT extends the internet connection to

a diverse range of devices, and everyday things that

are equipped with embedded technology, including

sensors, actuators, RFID

tags, etc. With advanc-

ing technologies, these devices have communication

and computing capabilities, and they can be remotely

monitored and controlled.

Remote device management is a critical issue

since the connected devices are diverse and their num-

ber is growing rapidly over time. Hence, it is essential

to efﬁciently manage this huge amount of devices, as

well as to equip the IoT with open standards to en-

sure its durability. This calls for abstraction of device

management functions that have to hide the complex-

ity, and to be independent of the technology. Such an

abstraction can be provided by the OMA

The OMA LwM2M enabler (Open Mobile Al-

RFID = Radio-Frequency IDentiﬁcation.

OMA = Open Mobile Alliance, https://www.

omaspecworks.org

liance, 2018a) is based on a client/server architec-

ture. The device acts as the LwM2M clients, and

the platform or the application acts as the LwM2M

server. The LwM2M enabler deﬁnes the application

layer communication protocol between an LwM2M

server and an LwM2M client. We investigate only the

client side (device). The target devices for this enabler

are essentially resource-constrained devices; there-

fore, this enabler makes use of a light and compact

protocol as well as an efﬁcient resource data model.

The LwM2M enabler includes the speciﬁcation of ap-

plication protocol for device management, and ser-

vice enablement for LwM2M devices. There are sev-

eral IoT platforms based on this standard, which ex-

plains the various implementations of the LwM2M

speciﬁcation. Some of them implement either the

server side or the client side. Others implement both

of them (client and server). These implementations

support most of the features of the LwM2M protocol.

Our ﬁnal objective is the correct implementation

of the LwM2M client; but we proceed incrementally.

Indeed, in this article, we deal with the preliminary

steps of modelling and analysing the LwM2M speci-

ﬁcation. We use formal methods to help in ensuring

correctness, consistency, and clarity of the LwM2M

speciﬁcation. Since a well-deﬁned and veriﬁed pro-

172

Mouakher, I., Dhaou, F. and Attiogbé, J.

Toward a Correct Implementation of LwM2M Client with Event-B.

DOI: 10.5220/0009832601720179

In Proceedings of the 15th International Conference on Software Technologies (ICSOFT 2020), pages 172-179

ISBN: 978-989-758-443-5

tocol speciﬁcation can reduce the cost for its imple-

mentation and maintenance. Modelling and analysis

are important steps of the protocol development life

cycle from the viewpoint of protocol engineering.

Event-B (Abrial, 2010) is a state-based formal

method, hence we can easily describe resources data

model associated with client. The Event-B method is

dedicated to describe event-driven reactive systems;

it allows us to describe interactions between LwM2M

clients and servers. We take advantage of the Event-

B method reﬁnement, which permits us to represent

the LwM2M client at different abstraction levels, and

it allow us to generate correct-by-construction code

from Event-B models.

In this work, we propose to model the behavior

of the LwM2M client as a discrete transition system

by building its mathematical models with Event-B.

Our models are compliant with the enabler technical

speciﬁcation for LwM2M 1.1. The generated Event-

B models allow us to analyze and verify the behavior

of the LwM2M client. The Event-B method and its

tools support are used to specify, validate and simu-

late our models. We choose an approach that grad-

ually models a complex behavior of the client using

layered reﬁnement, such that in each reﬁnement we

focus on modelling and verifying a subset of the en-

abler speciﬁcation. The proposed approach is based

on the systematic rules to generate the Event-B mod-

els. To better describe our models, we use State

Machine Diagrams (SMD) to specify protocols in-

volved in the interactions between LwM2M client and

servers. These diagrams allow us to summarize the

speciﬁcation in a graphical way, and to better explain

some Event-B models, since they are presented as a

translation of SMD. Furthermore, we deﬁne the rules

to translate interaction patterns into Event-B such as

request/response and subscribe/notify.

This paper is structured as follows: Sec. 2 is ded-

icated to a brief presentation of LwM2M enabler and

some background notions of the Event-B method, In

Sec. 3, we explain our approach of the formal mod-

elling of the LwM2M client. In Sec. 4, we summarize

the Event-B development of the LwM2M client.In

Sec. 5, we discuss some related work. Finally, Sec. 6

presents our conclusions and future work.

2 BACKGROUND

2.1 Brief Introduction to LwM2M

With LwM2M enabler (Open Mobile Alliance,

2018a; Open Mobile Alliance, 2018b), OMA has re-

sponded to the market demand for a common standard

to the managing lightweight and low power devices

on a variety of networks that is necessary to achieve

the potential of the IoT.

A client-server architecture (Fig. 1) is introduced

for the LwM2M enabler, where the LwM2M device

acts as an LwM2M client and, platform or application

acts as the LwM2M server. The LwM2M enabler has

two components: an LwM2M server and an LwM2M

client.

LwM2M Server

LwM2M

Bootstrap-Server

Interfaces

Client Registration

Device Management &

Service Enablement

Interfaces

Information Reporting

Bootstrap

DEVICE

LwM2M Client

Objects

Figure 1: The overall architecture of the LwM2M en-

abler (Open Mobile Alliance, 2018a).

Four interfaces are speciﬁed between the LwM2M

client and the LwM2M servers: Bootstrap Inter-

face (I1), Registration Interface (I2) Device Manage-

ment and Service Enable Interface (I3), and Infor-

mation Reporting Interface (I4). The operations for

the four interfaces can be classiﬁed into uplink or

downlink operations. The LwM2M operations for

each interface are mapped to CoAP Methods. The

CoAP protocol provides a request/response interac-

tion model. The LwM2M client must ignore the

LwM2M server operations on the I3 interface and on

the I4 interface during a server initiated bootstrap and

until it received its registration acknowledgement.

The LwM2M objects are identiﬁed with an Ob-

ject ID (i.e. Security object ID:0, Server object ID:1,

Access Control object ID:2, Device object ID:3, Con-

nectivity Monitoring object ID:4, Firmware Update

ID:5, Location object ID:6 and Connectivity Statistics

object ID:7). The resource data model is extensible,

thus any companies can deﬁne additional LwM2M

objects.

2.2 Brief Introduction to Event-B

Event-B (Abrial, 2010) is a formal method, which is

used in numerous industry projects. It is dedicated to

the modelling of critical systems. The basis for the

mathematical language in Event-B is ﬁrst logic and a

typed set theory. Set-theoretical notation of Event-B

Toward a Correct Implementation of LwM2M Client with Event-B

173

deﬁnes different types of relations and functions

en-

hanced by different properties. The Event-B method

is supported by the Rodin toolkit which comprises ed-

itors, theorem provers, animators and model checkers.

Two basic constructs compose Event-B models: con-

texts and machines. The static part of models is de-

ﬁned in a context. The behavior of a system is mod-

elled as a transition system. A machine speciﬁcation

usually deﬁnes variables that specify the states of a

system and guarded events that specify the system’s

transitions.

3 FORMAL MODELLING OF

THE LwM2M CLIENT

The behavior of the LwM2M client is given mainly

by the interactions with the servers through four in-

terfaces. It can also have some internal processes.

The supported operations are based on different com-

munication models: a request/response interaction

model, synchronous or asynchronous model and sub-

scribe/notify model, we deﬁne how we model each of

them in Event-B (Sec. 3.1).

In addition, the performance of these operations

depends on the state of the client and on the protocol

required by the interfaces. For example, the LwM2M

client must ignore LwM2M server operations on the

I3 interface during a server initiated bootstrap and un-

til it received its registration acknowledgment. For

this purpose, we use state transition diagram that al-

lows us, on the one hand, to summarize the descrip-

tion of the client, and on the other hand, to give a pre-

liminary model based on state and transition which

structures the translation into Event-B (Sec. 3.2).

3.1 Modelling Interaction Patterns

3.1.1 Request/Response Pattern

The operations of the LwM2M client are based on a

request/response interaction pattern. We consider that

there is no loss of messages. Then, for each received

or sent operation, the client must respectively send or

receive its response. For each operation, there are two

kinds of response: f ailure and success.

For each operation, we associate one event for

the request. For some operations, we associate two

events to their response in order to distinguish be-

tween f ailure and success responses; for the others,

Total (→) or partial ( 7→) functions, total () or par-

tial ( 7) injections, total () or partial ( 7) surjections and

bijections ().

we associate one event that will group the two kinds

of response. We use the naming convention as illus-

trated by the examples in Tab. 1.

Table 1: Naming convention for Event-B events.

Operations Event-B events

Request is uplink opera-

tion from I1 interface

s Request I1,

r Request I1 Response

Discover is downlink

operation from I1 inter-

face

r Discover I1,

s Discover I1 Response

We use one variable to synchronize between re-

quest and response of each interface. Then we deﬁne

partial functions that map the operations with the cor-

responding interface. For the I1 interface, the client

communicates with one bootstrap server. The I1 State

variable is deﬁned as a partial function that associates

True to an operation if it waits for a response other-

wise it is False, i.e. I1 State ∈ OPERAT IONS I1 7→

BOOL.

For the rest of the interfaces I2, I3 and I4, the

client can interact with several servers, and can re-

ceive several simultaneously requests from different

servers. The variable Ii State (with i ∈ {1, 2, 3})

is a partial function that associates an operation

with the set of servers waiting for a response for

that operation (e.g. I3 State ∈ OPERAT IONS I3 7→

P (dom(ServersState))

3.1.2 Subscribe/Notify Pattern

The I4 interface allows the server to observe any

changes in resource values on the LwM2M client

based on subscribe/notify pattern. The server initiates

the conversation by sending an Observe or Observe-

Composite operation that expresses interest in receiv-

ing notiﬁcation messages about an object, an object

instance or a resource. Then, the client delivers a

stream of Noti f y messages to the server at the place

in which data becomes available. When a Cancel Ob-

servation or a Cancel Observation-Composite opera-

tion is performed, the observation terminates. Partic-

ularly, there are two sequences of operations based

on subscribe/notify pattern: Observe/Notify/Cancel

Observation and Observe-Composite/Notify/Cancel

Observation-Composite.

For I4 interface, in addition to the I4 State vari-

able introduced to support request/response pattern,

the variable tokens is introduced to support sub-

scribe/notify pattern. The variable tokens is used as a

set of tokens.This variable is used to match the asyn-

chronous notiﬁcations with previous Observe opera-

dom: domain, P : powerset.

ICSOFT 2020 - 15th International Conference on Software Technologies

174

tions. For each successful Observe operation, a token

is added to the tokens variable and it will be deleted

when the client receive Cancel Observation.

3.1.3 Synchronous and Asynchronous

Communication Pattern

The OMA LwM2M enabler don’t specify if the com-

munication is synchronous or asynchronous then the

implementation can support both of them. We only

consider the context of synchronous communication.

In the context of uplink operation, the client can not

start another sending operation until it has received

the response to the already sent one; but it can re-

ceive operations (downlink operation). In the context

of downlink operation, the client can receives opera-

tions from several servers. Other servers are assumed

to communicate in a synchronous manner. Therefore,

if the client has received an operation from a server,

he can not receive another one until he has sent the

response of the ﬁrst one.

The asynchronous communication can be easily

supported by our models by modifying the guards of

operations.

3.1.4 Example of Interaction Model Events

To illustrate the rules proposed in the Sec. 3.1.1,

Sec. 3.1.2 and Sec. 3.1.3, we give the example of

the two Event-B events associated to Noti f y opera-

tion (Fig. 2).

Event s Notify I4 hordinaryi b=

any

where

grd3: I2 State = (OPERATIONS I2 × {∅})

grd4: I3 State = (OPERATIONS I3 × {∅})

grd5: I4 State = (OPERATIONS I4 × {∅})

grd6: s ∈ tokens

then

act1: I4 State(Noti f y) :=

I4 State(Noti f y) ∪ {s}

end

Event s Notify I4 Response hordinaryi b=

any

where

grd5: (Noti f y ∈ dom(I4 State)) ⇒

(s ∈ I4 State(Noti f y))

grd6: s ∈ tokens

then

act1: I4 State(Noti f y) :=

I4 State(Noti f y) \ {s}

end

Figure 2: Event-B events associated to Noti f y operation.

• Request/response pattern : the Noti f y operation is

an uplink operation from I4 interface, then it has

two events: s Notify I4 and s Notify I4 Response.

The variable I4 State appears in the guard of the

two events (grd5 in Fig. 2) and it is updated in

their action (act1 in Fig. 2). The variable I4 State

allows us to synchronize between request and re-

sponse of the operation Noti f y.

• Subscribe/notify pattern: the Noti f y operation

can be performed (i.e. the s Notify I4 and

s Notify I4 Response events can be executed)

only if the considered server has a token in the

tokens variable (grd6 in Fig. 2)

• Synchronous communication pattern: the event

s Notify I4 is sending event and it can be per-

formed only if there is not another received or

sent operation waiting for response (grd3, grd4

and grd5

3.2 Modelling Interfaces Protocol

3.2.1 Description of the LwM2M Client with a

State Machine Diagram

The abstract behavior of the LwM2M client can be

shown as a SMD in Fig. 3. This diagram includes

two composite states, “attempting to Bootstrap” and

“Bootstrap Success”, and one simple state “Bootstrap

Failure”.

The “Attempting to Bootstrap” state has three

nested states: “Attempting to Factory Bootstrap”,

“Attempting to Bootstrap from Smartcard”, and “At-

tempting Client Initiated Bootstrap”. In this compos-

ite state, the device sequentially try to bootstrap via

Smartcard and/or Factory Bootstrap mode. If these

two steps fail (i.e. the client has not any LwM2M

Server object instances), the LwM2M client performs

the Client Initiated Bootstrap. If the Client Initi-

ated Bootstrap also fails, then the LwM2M client is

in a deadlock state:“Bootstrap Failure”. In the “At-

tempting Client Initiated Bootstrap” state, there is

the “Client Initiated Bootstrap” activity. This activ-

ity consists of a set of interactions between the client

and the bootstrap server through the operations of the

I1 interface.

In the “Bootstrap Success” state, we introduce the

operations of I2 interface: Register, U pdate and De-

must have at least one server account. As soon as

the client registers to a server, the client can per-

form the other operations of I2 interface with this

server as well as the operations of I3 and I4 in-

terfaces. Finally, the client can De-register and

stop interaction with the LwM2M server. In the

“Bootstrap Success” state, we can deduce three sub-

states: “Not Registered”, “Registered” and “Fail Reg-

Toward a Correct Implementation of LwM2M Client with Event-B

175

[Bootstrap server

Account not exist]

Bootstrap

BootstrapFail

A emp ng to Bootstrap

do/Factory Bootstrap

BootstrapFail

Fail Registered (s

)

De-Register(I2)

UpdateFail(I2)

do/Opera ons(I3, I4)

/Update(I2)

Not Registered (s

)

RegisterSucces

Bootstrap Success

Bootstrap Failure

Success

Bootstrap

Perform

[Bootstrap

data changed]

Figure 3: Behavior of an LwM2M client with a State Machine Diagram.

istered”. Since the LwM2M client can register to sev-

eral LwM2M servers, the state of client is deﬁned by

the set of LwM2M server’s instances. The “Boot-

strap Success” state is a composite state; it has three

nested states: “Not Registered (s

)”, “Fail Registered

)” and “Registered (s

)”; each of them refers to a

LwM2M server instance. If registration succeeds, the

client can interact with the corresponding LwM2M

server via operations on I3 and I4 interfaces. If the

registration fails, the client can perform bootstrap or

trying to register again.

In the “Not Registered (s

)” state, the client can

perform Register operation; upon the client receives

a response it can change its state. In the “Registered

)” state, there is an activity composed of interac-

tions between the client and a server s

. These inter-

actions use I3 and I4 interfaces, and also update and

De-register operations from I2 interface can be per-

formed.

3.2.2 Translation of the State Machine Diagram

into Event-B

We propose some rules to translate SMD to an Event-

B model associated with the LwM2M client. The

translation rules are not exhaustive since we restrict

ourselves to the elements used in the SMD of Fig. 3.

These rules are applied progressively since we rely

on a reﬁnement-based approach. The elements of

SMD that will be covered, and its associated trans-

lation rules are summarized below.

Translation of a State. We associate a variable

with the states (simple state and composite state) of a

SMD, e.g. ClientState, and we ignore the sub-states.

For each composite state, we associate a variable to

its direct substates (i.e. it is not contained by any

other state), e.g. AttemptingToBootstrapState and

ServersState, and so on. We deﬁne two rules for the

type of the generated variables.

The ﬁrst rule applies when the generated vari-

able is an enumerated set, which is generated

from the states of the considered states. It is

the same rule as the one proposed in (Snook and

Butler, 2006) and called enumeration translation

in iUML-B tool (Snook, 2014). For the SMD

depicted in Fig. 3, we introduce two variables,

ClientState that represents the three states of the

SMD and AttemptingToBootstrapState that repre-

sents the three nested states of “Attempting to Boot-

strap”.

The second rule applies when the generated vari-

able is a function that associates to each instance its

state. We use another variable that represents the set

of the considered instances.

For the SMD depicted in Fig. 3, we introduce two

new variables: Servers and ServersState. The ﬁrst

one represents the servers with which the client can

interact. These servers are setting up in the bootstrap

phase. The second ServersState variable represents

the three nested states of “Bootstrap Succes” state and

it is deﬁned by the function that associates a state to

each server.

ServersState ∈ servers → SERV ER STATE

Translation of a Transition. Transitions are trans-

lated into events. The Tab. 2 presents some of the

rules used to generate Event-B events associated to

activities and transitions: simple transition (R1), ini-

tial transition (R2), junctions (R3), choice (R4), and

transition and activity (R5).

In these rules, hin S1i, hinitiated by S1i and

hbecomes S2i depend on the data that represents the

state. The rules R5 considers that there is an ac-

tivity and an outcoming transition in the same state.

ICSOFT 2020 - 15th International Conference on Software Technologies

176

Table 2: Client’ behavior translation rules.

Ri SMD elements Transition into Event-B

e b= when hin S1i

then hbecomes S2i

INITIALISATION

then hinitiated by S1i

e b= when hin S1 or S2i

then hbecomes S3i

R4 e b= when hin S1i then

hbecome S2 or S3i

e b=

when hin S1 and cond1i

then hbecomes S2i

e’ b=

when hin S1 and cond2i

then hbecomes S3i

do/ a

a b= when hin S1 ∧

ActProcessed = 0i

then hbecomes S2

ActProcessed := 1i

e b= when hin S1 ∧

ActProcessed = 1 i

then hbecomes S2

ActProcessed := 0i

When a state contains activity, triggering the transi-

tion marks the end of the activity. We use a variable

ActProcessed that can take the value 0 or 1 to syn-

chronize between the execution of the activity and the

transitions in the same state. Translation of an Ac-

tivity. A state can hold a list of internal actions and

activities (do), that are performed while the element is

in the state. We associate at least one event with each

activity that depends on the description of the activity

and the considered level of abstraction.

In the “Attempting to factory Bootstrap” and the

“Attempting to Bootstrap from Smartcard” states,

there is respectively “Factory Bootstrap” and “Boot-

strap from Smartcard” activities. Each of these activ-

ities is translated into an Event-B event.

In the “Attempting to client initiated Bootstrap”

state, the operations from Bootstrap Interface can be

performed. This activity consists of a set of inter-

actions between the client and the bootstrap server

through the operations of I1 interface: Request,

Discover, Read, Delete, W rite and Finished. Boot-

strap communication starts with Bootstrap-Request

message and ends with a Bootstrap-Finish message.

Between these two messages, the bootstrap server

may conﬁgure the client with the necessary informa-

tion. In the Event-B model, we introduce the events

associated to the operations from I1 Interface and the

I1 State variable.

In the “Registered(s

)” state, the operations from

I3 and I4 interfaces, and U pdate and De-register op-

erations from I3 interface can be performed. The

events associated to these operations are added. The

events associated to I4 interface are based on sub-

scribe/notify pattern.

In the “Not registered (si)” state, the client can

send register request to the server and wait for the

response. If it receives f ailure response it can send

4 EVENT-B DEVELOPMENT OF

THE CLIENT

We summarize in this section the Event-B develop-

ment of the LwM2M client.

4.1 Architecture of the Event-B Models

The summary of the hierarchy of speciﬁcation pre-

sented in Sec. 3 is illustrated in Fig. 4. In the Event-B

speciﬁcations, beside the ctx context, which gathers

all the used sets, we use the following contexts:

• ctx

Interfaces: contains constants that are re-

quired for the deﬁnition of the client interfaces

and their properties.

• ctx InterfaceInstances Properties: contains the

properties on the client interfaces.

ctx

ctx_Interfaces

M_I

R_I1

R_I4

R_I2

R_I3

Legend

extends

sees

re nes

ctx_InterfaceInstances-

Properties

Figure 4: Development hierarchy.

We construct several successive models. In the

ﬁrst following ﬁve models, we focus on the mod-

elling of operations associated with the four inter-

faces. Therefore, we focus more on the protocol as-

pect (order of execution of operations) which is con-

sidered in Event-B by protocol variables that allow

synchronization between operations. Then in the last

Toward a Correct Implementation of LwM2M Client with Event-B

177

model we introduce the resource data model. We use

the following Event-B machines:

• M I: we focus on the bootstrap process by intro-

ducing the four modes for bootstrapping: Factory

Bootstrap, Bootstrap from Smartcard, Client Initi-

ated Bootstrap and Server Initiated Bootstrap; no

operation is considered yet.

• R I1: we increase the ﬁrst model with the de-

scription of the operations in I1 interface involved

in Client initiated bootstrap and Server initiated

bootstrap modes.

• R I2: we reﬁne R I1 machine by adding the de-

scription of the operations in I2 Interface. The

client can interact with one or several LwM2M

servers.

• R I3: the machine R I3 reﬁnes the machine R I2,

and it contains new events associated with the I3

interface.

• R I4: the machine R I4 reﬁnes the machine R I3,

and it is enhanced by the events associated to the

I4 interface.

4.2 Proof Statistics

The development is formalized and proved using the

Rodin platform

(version 3.4). The veriﬁcation of the

Event-B models is provided via means of proof obli-

gations (PO). The summary of the POs for the de-

velopment is as follow: M I (9 POs), R I1 (23 POs),

R I2 (50 POs), R I3 (68 POs) and R I4 (55 POs). The

POs are proved automatically (about 60%) or manu-

ally using the theorem provers of Rodin.

5 RELATED WORK

IoT protocols are the most crucial part of the IoT

technology. Indeed, without them, hardware would

be useless as the IoT protocols allow us to ex-

change data in a structured and meaningful way.

The IoT communication protocols attract numerous

researchers (Aziz, 2014), (Che and Maag, 2013),

(Schmelzer and Akelbein, 2019), (A. Nikolov and

Atanasov, 2016), (Thangavel et al., 2014), (Diwan

and D’Souza, 2017), (Snook et al., 2017). These

works deal with different issues and each of them is

interested in distinct protocols or deal with different

issues.

There are few works (Aziz, 2014), (Che and

Maag, 2013) that provide formal semantics for some

http://www.event-b.org/

IoT protocols in order to check some communication

properties.

Event-B method is already used to provide for-

mal semantics for communication protocols in IoT.

In (Diwan and D’Souza, 2017), the authors propose

an approach to verify an IoT communication protocol

through a framework in Event-B. They present mod-

els of MQTT, MQTT-SN and CoAP protocols, and

they verify some communication properties.

In (Snook et al., 2017), a general approach is pro-

posed for constructing and analysing security proto-

cols using Event-B. The approach is based on abstrac-

tion, reﬁnement, and a systematic modelling method

using the UML state and class diagrams of iUML-

B (Snook and Butler, 2006; Said et al., 2015). Due to

the exponential growth of network endpoint devices,

several studies have been made on protocols towards

efﬁcient remote device management (de C. Silva

et al., 2019). In this paper, we focus on the LwM2M

emerging open standard that meets the requirements

for managing constrained devices. It is adopted by

several manufacturers such as Microsoft and Intel.

Several implementations of the LwM2M protocol

stack became available in the last few years, such that

the open source implementations Wakaama

and Le-

shan

that are, widely used.

Consequently LwM2M implementations attract

numerous researchers. In (Schmelzer and Akelbein,

2019), the authors propose useful metrics for mea-

suring device management capabilities on constrained

nodes based on the LwM2M standard. They present

their work as an upfront analysis for selecting an ap-

propriate implementation and they give a comparison

between two open source implementations: Wakaama

and Leshan.

In (Thramboulidis and Christoulakis, 2016), the

main contribution is the deﬁnition of a UML proﬁle

for the IoT, namely the UML4IoT proﬁle. The authors

deﬁne a UML proﬁle based on the LwM2M protocol,

designed to integrate the smart devices into industrial-

level Iot-based systems. UML proﬁle is used to auto-

matically generate code and they propose a prototype

implementation of the OMA LwM2M (v1.0) protocol

based on meta programming.

To our knowledge, there is one work that pro-

vides formal semantics for this standard. In the

paper (A. Nikolov and Atanasov, 2016), the au-

thors deﬁne a formal approach to the veriﬁcation of

LwM2M server and client behaviour. Behavioral

models of LwM2M server and client for connectiv-

ity management are proposed. Both models are for-

mally described as labeled transition systems, and

http://www.eclipse.org/wakaama/

http://www.eclipse.org/leshan/

ICSOFT 2020 - 15th International Conference on Software Technologies

178

they are compliant with Enabler Test Speciﬁcation for

Lightweight M2M (v1.0). Then, it is proved that both

models are synchronized using the concept of weak

bisimulation. The considered behavioral models of

LwM2M server and client are at a very abstract level.

In our work, we provided a formal semantics for

the LwM2M protocol by using Event-B method. We

analyzed and veriﬁed the behavior of LwM2M client

with The Rodin tool and the ProB model checker. We

intend to generate automatically the code from the

Event-B models that we have deﬁned for the LwM2M

protocol.

6 CONCLUSION

To better understand and trust the LwM2M enabler,

formally derived and veriﬁed models should be de-

ﬁned. In this paper, we presented an approach of

modelisation and veriﬁcation for the speciﬁcation of

the IOT systems by exploiting the OMA lightweight

M2M enabler. We focused on the behavior of the

LwM2M client. We followed a reﬁnement-based ap-

proach by building several formal models by using

the Event-B method. Indeed, we proposed systematic

rules for the translation of the LwM2M enabler to-

ward Event-B. The reﬁnement-based approach allows

us to master the complexity of the model and facili-

tates the proof and the correction of the sub-models.

The proof of the correctness of models, and the check-

ing of consistency properties are made with the pow-

erful tools of the Event-B platform.

We are conducting more experimentations on

modelling with Event-B. We project to deﬁne an ap-

proach for providing code generation. A possible

perspective consists to consider the modelisation of

LwM2M server side and then to consider both sides

(client and server). In the latest case, the checking

of the compatibility between client and server must

be established. Our future work will focus on valida-

tion, which includes running scenarios in the form of

model acceptance test.

REFERENCES

A. Nikolov, E. P. and Atanasov, I. (2016). Formal veri-

ﬁcation of connectivity management models in m2m

communications. In 2016 IEEE International Black

Sea Conference on Communications and Networking

(BlackSeaCom), pages 1–4.

Abrial, J.-R. (2010). Modeling in Event-B: System and Soft-

ware Engineering. Cambridge University Press, 1st

edition.

Aziz, B. (2014). A formal model and analysis of the

mq telemetry transport protocol. In Ninth Interna-

tional Conference, Availability, Reliability and Secu-

rity (ARES), pages 59–68, Fribourg.

Che, X. and Maag, S. (2013). A passive testing approach for

protocols in internet of things. In Green Computing

and Communications (GreenCom), IEEE and Inter-

net of Things (iThings/CPSCom), IEEE International

Conference on and IEEE Cyber, Physical and Social

Computing, pages 678–684.

de C. Silva, J., Rodrigues, J. J. P. C., Al-Muhtadi, J., Rab

elo,

R. A. L., and Furtado, V. (2019). Management plat-

forms and protocols for internet of things: A survey.

Sensors, 19(3):676.

Diwan, M. and D’Souza, M. (2017). A framework for mod-

eling and verifying iot communication protocols. In

Dependable Software Engineering. Theories, Tools,

and Applications, SETTA 2017, volume 10606 of

LNCS, pages 266–280. Springer.

Open Mobile Alliance (2018a). Lightweight machine to

machine technical speciﬁcation: Core.

Open Mobile Alliance (2018b). Lightweight machine to

machine technical speciﬁcation: Transport layer.

Said, M. Y., Butler, M., and Snook, C. (2015). A method of

reﬁnement in uml-b. Softw. Syst. Model., 14(4):1557–

1580.

Schmelzer, P. and Akelbein, J.-P. (2019). Evaluation

of hardware requirements for device management of

constrained nodes based on the lwm2m standard. In

Proceedings of the 5th Collaborative European Re-

search Conference (CERC 2019), pages 103–110.

Snook, C. (2014). iUML-B statemachines. In Proceed-

ings of the Rodin Workshop 2014, SE’08, pages 29–

30, Toulouse, France.

Snook, C. and Butler, M. (2006). Formal modeling and de-

sign aided by UML. ACM Transactions on Software

Engineering and Methodology (TOSEM), 15(1):92–

122.

Snook, C. F., Hoang, T. S., and Butler, M. J. (2017).

Analysing security protocols using reﬁnement in

iuml-b. In NASA Formal Methods - 9th International

Symposium, NFM 2017, volume 10227 of LNCS,

pages 84–98. Springer.

Thangavel, D., Ma, X., Valera, A., Tan, H., and Tan, C. K.

(2014). Performance evaluation of mqtt and coap via

a common middleware. In 2014 IEEE Ninth Interna-

tional Conference on Intelligent Sensors, Sensor Net-

works and Information Processing (ISSNIP), pages 1–

6. IEEE Press.

Thramboulidis, K. and Christoulakis, F. (2016). UML4IoT

- A UML-based approach to exploit IoT in cyber-

physical manufacturing systems. Computers in Indus-

try, 82:259–272.

Toward a Correct Implementation of LwM2M Client with Event-B

179