Nowadays, resource constrained devices are seen as one of the main components for building the Internet of Things (IoT). Typical constraints of such devices are given by the size of the built-in memory, a non-continuous power supply, and limited computing power. A categorization for such constraints into classes is given in RFC7228. The exponential growth of the number of end devices demand for a centralized, automated, and secure device management to handle the complexity of the upcoming IoT. The emerging open standard Lightweight Machine to Machine (LWM2M) is one of the first approaches to meet the requirements for managing constrained devices. A growing variety of implementations of the LWM2M protocol stack became available in the past years. This paper aims to define useful metrics for measuring device management capabilities on constrained nodes. Two relevant open source implementations are compared by their memory usage. The results show that LWM2M is feasible on Class 2 devices.
According to Gartner and other analysts the amount of IoT devices in consumer
and business environments doubles each two years. Such an increase of
interconnected devices forming complex systems with broader attack surfaces demands
for an appropriate security level of communication protocols and firmware for
IoT devices. These new requirements ask for a new infrastructure for managing
devices in an automated and centralized manner. This approach is well known
for interconnected devices like personal computers, mobile phones, printers, etc.
In the field of constrained devices such as small sensor nodes for measuring
temperature, humidity, pressure etc. or actuators like thermostats or light switches,
device management is not yet widespread [
Before personal computers got interconnected through a network, management
functionality was rarely required. Each user had to manage its personal device
manually and physical access to the device was required. By interconnecting
such devices, large enterprises introduced a centralized device management
enabling remote control over a continuously growing number of computers. In
general, such management consists of configuration, monitoring and
administration of managed entities. Managed entities could be network elements,
applications, system resources or services [
Comparing common management protocols, the way of managing entities is
very similar [
LWM2M implementations: As of today, the LWM2M standard has a very
low market penetration. For now there are a couple of open implementations
already available. Some of them are part of IoT operating systems like MBED,
RIOT, Contiki or Zephyr. Others are maintained by companies [
Evaluation of hardware requirements for device management 3 LWM2M server requires a more powerful machine where resource constraints should not be an obstacle.
Related Work: The literature provides already some work on evaluating
device management on constrained nodes. Z. Sheng et al. presented an efficient
way minimizing packet size with Constrained Application Protocol (CoAP) [
Devices for large IoT environments bring their own non-functional requirements. When the number of devices grows, manual workload for changing batteries after one or a few years drive operational cost becoming a strong inhibitor for new business models based on such large IoT environments. Hence their energy consumption should allow periods of 5, 10, or even more years of running time. Another criteria is on limiting the required size of memory to a minimum for using the cheapest hardware configuration of microcontroller variants. Both energy consumption and memory size depend on the hardware architecture and a modest resource footprint of the used software. The following list of non-functional requirements should be used for assessing the eligibility of network protocols and their implementations in resource constrained environments.
Memory usage: Several software components like an operating system, IP stack, etc. build the software stack running on constrained devices. Device management adds further components to the stack. Its code is stored in ROM/Flash where the size can be determined after compilation time. The size of the data segments define the size of required RAM. It is used for variables, buffers etc. where only the size of the static part of memory can be determined after compilation time exactly. During runtime the size of dynamically allocated memory like a heap needs to be added. For constrained devices, an implementation should achieve that only a minimal part of RAM is being used dynamically. 4
Paul Schmelzer and Jens-Peter Akelbein
Energy usage: For a very low energy consumption constrained devices should
be in a power saving or sleeping mode most of the time. Both optimizing the
software stack behaviour for maximizing the deep sleep time and measuring the
energy consumption per software function is an active research area [
Protocol overhead: Reducing the overhead of communication protocols for constrained node networks (CNN) can be achieved by minimizing the size of messages and the number of messages to be sent. Readable formats like XML or JSON use much more bytes as a consequence compared to binary formats. Corresponding metrics allow measuring the efficiency of the complete network stack or layers of it.
Encryption: Public key infrastructures (PKI) are hardly implementable even
for class 2 devices. Current open approaches are based on DTLS with PSK or
raw public keys. If weaker encryption is sufficient there are a few lightweight
cipher suites choosable [
Modularity: For maintaining a software stack over a long lifetime, the implementation should be modularized. Configurability allows providing only the required code parts within the shipped firmware.
As the following results were gained in an ongoing project this paper presents
first results investigating memory usage. For determining the memory footprint a
tool from G. Mukundan [
In total, four LWM2M implementations were selected for this examination. Data
for two of them were already provided by Han et al. [
Evaluation of hardware requirements for device management 5 The implementation requires a lot of dynamic memory. Such RAM usage is not recommended for embedded programming. Nevertheless, the code was ported to RIOT OS. The ROM usage results in 24250 Byte which is closer to the size cited by Han. Wakaama provides DTLS security with PSK and raw public key, certificates are not implemented. Depending on the used DTLS library and its modularity, security adds around 4-8 KB in RAM and 25-60 KB in ROM. The RAM and ROM size also depends on which LWM2M capabilities are already provided by an implementation. This may differ to a small extend between the presented implementations. The RAM usage of Wakaama with 7010 Byte is still beyond design objectives for class 2 devices.
(a) RAM
(b) ROM
As a sort of hacky workaround for the port, around 5 KB of memory are allocated statically for simulating the previous dynamic memory design on the heap. This results in memory leaks by assigning static blocks bigger than the containing data. The memory actually been used by the wakaama code is less than the reserved memory. To fix this issue it would be advisable to allocate only the utilized memory for the used objects and identify the parts where dynamic memory is needed. Furthermore, on RIOT the occupied stack size on the nRF52DK could be measured. It was about 1,2 KB.
Additional Results: LWM2M suggests the use of TLS PSK WITH AES
128 CCM 8 or TLS EC-DHE PSK WITH AES 128 CCM 8 as cipher suites.
These should suffice security needs of interconnected constraint devices according
to RFC 7925 [
Paul Schmelzer and Jens-Peter Akelbein for choosing modules to be contained within the firmware e.g. cipher suites, IPv4/IPv6, LWM2M bootstrapping etc. 5
For using IoT networks including large numbers of constrained devices manageability of all components becomes a strong requirement. Therefore, device management on constrained nodes needs to be seen as essential for building secure and mature IoT solutions soon. As hardware resources on these nodes are limited, appropiate software components for implementing device management need to fulfil non-functional requirements on memory and CPU consumption as well. LWM2M is an emerging standard in the IoT for managing constrained devices. Because these devices are restricted, there are special requirements for software and hardware. The important metrics are memory usage, energy usage, protocol overhead, encryption and modularity. The presented implementations vary especially on there memory usage and functionality. Although it has a big ROM capacity, the mbed client contains all standard functionality and has a well rounded C++ API. Wakaama on RIOT can still be optimized in its RAM usage compared to other implementations. Both libraries are maintained actively. The amount of memory usage justifies the feasibility on Class 2 devices.
For future work it would be worth considering on how to validate the presented requirements for an application protocol. This paper presents first results of evaluating the memory footprint as part of a research project. Furthermore, questions need to be answered how to optimize functional coverage versus memory footprint, how RAM usage can be minimized, and energy consumption can be reduced during runtime. Another drawback of current implementations is that LWM2M clients have to wait for server requests actively. Constrained nodes are usually active for sending sensor data only while sleeping most of their time. Keeping the radio module on for receiving requests leads to unnecessary power consumption. So adding a timing schema with active slots for managing nodes will be another optimization.
Evaluation of hardware requirements for device management 7