Message-Based Communication for Heterogeneous Internet of Things Systems.

The Internet of Things (IoT) domain presents a wide spectrum of technologies for building IoT applications. The requirements are varying from one application to another granting uniqueness to each IoT system. Each application demands custom implementations to achieve efficient, secure and cost-effective environments. They pose a set of properties that cannot be addressed by a single-based protocol IoT network. Such properties are achievable by designing a heterogeneous IoT system, which integrates diverse IoT protocols and provides a network management solution to efficiently manage the system components. This paper proposes an IoT message-based communication model applied atop the IoT protocols in order to achieve functional scalability and network management transparency agnostic to the employed communication protocol. The paper evaluates the proposed communication model and proves its functional scalability in a heterogeneous IoT system. The experimental assessment compares the payload size of the proposed system with respect to the LwM2M standard, a protocol designed specifically for IoT applications. In addition, the paper discusses the energy consumption introduced by the proposed model as well as the options available to reduce such impact.


Introduction
Internet of Things devises and maintains the synergy between the digital and physical environment. IoT comprises a wide variety of applications and protocols that grant uniqueness to each implementation. In such complex ecosystems, the implementations are varying in accordance with multiple factors such as environment properties, in-use protocols, ecosystem efficiency and costs. Taking into consideration all these factors, building an efficient and cost-effective heterogeneous IoT system represents a big challenge.
To achieve an effective heterogeneous IoT system, besides the multi-protocol communication interoperability, the system must provide an effective network management solution responsible for configuring, monitoring and maintaining the IoT entities agnostic to the employed communication protocol. Heterogeneous IoT systems have various uplink and downlink traffic which is caused by protocol heterogeneity, device configuration, firmware upgrade, commands execution, etc. It becomes important for the implied entities to define a common set of rules and practices to achieve semantic interoperability.
This paper proposes an IoT message-based communication (IMBC) model applied atop the IoT communication protocols to achieve network management transparency despite the transmitting  The message payloads comprise at least one semantic data service representation which in turn consists of two parts, that is, the service identifier and the service message. The service identifier determines the service for which the following service message is intended. The service message Sensors 2020, 20, 861 4 of 17 contains the actual data associated with that service. The number of services comprised by a single message varies based on the limitation of the employed IoT protocols, such as the maximum payload size. In other words, IMBC allows sending data of multiple services in one single message, thus reducing the network load. A message can for example be sent by the end-node to publish both the temperature and its battery level. As a receiver, the central manager identifies the service representations based on the service identifiers, processes the service messages accordingly and extracts the corresponding data. The message format and its characteristics are described next.

The Message Format
A service is described as a JavaScript Object Notation (JSON) object of which the key is the service identifier byte value represented as a hexadecimal number. The JSON object definition comprises the service name, the title, the description and the service message particularities, such as the data structure, type and unit.
As shown in Figure 1, IMBC implements five different formats for the service messages: fixed-length data, variable-length data, fixed-length list, variable-length list and data mask. We will provide more details about each hereunder.

Fixed-Length Data Format
An object definition of a fixed length service message specifies the data length in bytes and its type. The total size of such a service message format is computed as follows, with s, s id and s dl representing the service, service identifier length and service data length, respectively. We note that the naming of s and s id will be consistent throughout this section. Below we exemplified a temperature service object definition which defines a service message of 4 bytes length represented as floating point.
contains the actual data associated with that service. The number of services comprised by a single message varies based on the limitation of the employed IoT protocols, such as the maximum payload size. In other words, IMBC allows sending data of multiple services in one single message, thus reducing the network load. A message can for example be sent by the end-node to publish both the temperature and its battery level. As a receiver, the central manager identifies the service representations based on the service identifiers, processes the service messages accordingly and extracts the corresponding data. The message format and its characteristics are described next.

The Message Format
A service is described as a JavaScript Object Notation (JSON) object of which the key is the service identifier byte value represented as a hexadecimal number. The JSON object definition comprises the service name, the title, the description and the service message particularities, such as the data structure, type and unit.
As shown in Figure 1, IMBC implements five different formats for the service messages: fixed-length data, variable-length data, fixed-length list, variable-length list and data mask. We will provide more details about each hereunder.

Fixed-Length Data Format
An object definition of a fixed length service message specifies the data length in bytes and its type. The total size of such a service message format is computed as follows, with s, s id and s dl representing the service, service identifier length and service data length, respectively. We note that the naming of s and s id will be consistent throughout this section. Below we exemplified a temperature service object definition which defines a service message of 4 bytes length represented as floating point.

Variable-Length Data Format
A service message transporting data of variable length comprises the data length, followed by the actual data. The data length is a decimal number given by the first bytes as specified by the service object definition. The service representation size is computed by where s dvl denotes the number of bytes necessary for describing the data length. The length of the service data itself is presented as s dl . As described below, the custom message service object defines a variable data length given by the first two bytes, resulting in a custom message of maximum 65,535 bytes long.

Variable-Length Data Format
A service message transporting data of variable length comprises the data length, followed by the actual data. The data length is a decimal number given by the first bytes as specified by the service object definition. The service representation size is computed by where s dvl denotes the number of bytes necessary for describing the data length. The length of the service data itself is presented as s dl . As described below, the custom message service object defines a variable data length given by the first two bytes, resulting in a custom message of maximum 65,535 bytes long.

Variable-Length Data Format
A service message transporting data of variable length comprises the data length, followed by the actual data. The data length is a decimal number given by the first bytes as specified by the service object definition. The service representation size is computed by where s dvl denotes the number of bytes necessary for describing the data length. The length of the service data itself is presented as s dl . As described below, the custom message service object defines a variable data length given by the first two bytes, resulting in a custom message of maximum 65,535 bytes long.

} }
The corresponding data representation is given in Figure 2b. From the figure, we see consists of the service identifier ("af" hexadecimal) and the service message, which is split as f the data length ("000a" hexadecimal: 10 bytes) and the data ("f944cc4f3862a643a574" hexadec where s ll represents the service list length and l el symbols the data size of each element. Be example is provided for a service which reports a location represented as a list of two float latitude and longitude. { "33": { "service": "location", "title": "Location", "description": "Location value given by the latitude and longitude.", "list-length": 2, "type": "float", "element-length": 4, "unit": "°" } } As shown in Figure 2c, the location service representation internally consists of two pa service identifier ("33" hexadecimal) followed by the service message, which is this case con the latitude ("424b62f8") and the longitude ("408b4452"), having floating point values "50.8466 "4.35209", respectively.

Variable-Length List Format
As will later be described in Section 3.2.1, IMBC provides three management procedures u for device configuration. The underlying component for these procedures is the service m format used to transport lists of variable length. Such service messages comprise the list leng the elements of the list. The payload size for such a message is given by vll(s) = s id + s lvl + s ll × l el , where s lvl is the number of bytes describing the list length. s ll and l el denote the number of elem the list and the length of each element, respectively.
The service object definition exemplified hereunder permits to transmit a list of serv maximum 256 elements, as the length is provided by the first byte which has a maximum value The corresponding data representation is given in Figure 2b. From the figure, we see that it consists of the service identifier ("af" hexadecimal) and the service message, which is split as follows, the data length ("000a" hexadecimal: 10 bytes) and the data ("f944cc4f3862a643a574" hexadecimal).

Fixed-Length List Format
The elements of a fixed length list are extracted based on the number of elements and their size in bytes specified by the service definition. Equation (3) computes the total size of a service representation carrying data lists. It is defined as where s ll represents the service list length and l el symbols the data size of each element. Below an example is provided for a service which reports a location represented as a list of two float values, latitude and longitude.

} }
The corresponding data representation is given in Figure 2b. From the figure, we see that it consists of the service identifier ("af" hexadecimal) and the service message, which is split as follows, the data length ("000a" hexadecimal: 10 bytes) and the data ("f944cc4f3862a643a574" hexadecimal).

Fixed-Length List Format
The elements of a fixed length list are extracted based on the number of elements and their size in bytes specified by the service definition. Equation (3) computes the total size of a service representation carrying data lists. It is defined as where s ll represents the service list length and l el symbols the data size of each element. Below an example is provided for a service which reports a location represented as a list of two float values, latitude and longitude.

Variable-Length List Format
As will later be described in Section 3.2.1, IMBC provides three management procedures utilised for device configuration. The underlying component for these procedures is the service message format used to transport lists of variable length. Such service messages comprise the list length and the elements of the list. The payload size for such a message is given by where s lvl is the number of bytes describing the list length. s ll and l el denote the number of elements in the list and the length of each element, respectively. The service object definition exemplified hereunder permits to transmit a list of services of maximum 256 elements, as the length is provided by the first byte which has a maximum value of 255.

Variable-Length List Format
As will later be described in Section 3.2.1, IMBC provides three management procedures utilised for device configuration. The underlying component for these procedures is the service message format used to transport lists of variable length. Such service messages comprise the list length and the elements of the list. The payload size for such a message is given by where s lvl is the number of bytes describing the list length. s ll and l el denote the number of elements in the list and the length of each element, respectively. The service object definition exemplified hereunder permits to transmit a list of services of maximum 256 elements, as the length is provided by the first byte which has a maximum value of 255.

} }
The corresponding data representation is given in Figure 2b. From the figure, we see that it consists of the service identifier ("af" hexadecimal) and the service message, which is split as follows, the data length ("000a" hexadecimal: 10 bytes) and the data ("f944cc4f3862a643a574" hexadecimal).

Fixed-Length List Format
The elements of a fixed length list are extracted based on the number of elements and their size in bytes specified by the service definition. Equation (3) computes the total size of a service representation carrying data lists. It is defined as where s ll represents the service list length and l el symbols the data size of each element. Below an example is provided for a service which reports a location represented as a list of two float values, latitude and longitude.

Variable-Length List Format
As will later be described in Section 3.2.1, IMBC provides three management procedures utilised for device configuration. The underlying component for these procedures is the service message format used to transport lists of variable length. Such service messages comprise the list length and the elements of the list. The payload size for such a message is given by where s lvl is the number of bytes describing the list length. s ll and l el denote the number of elements in the list and the length of each element, respectively. The service object definition exemplified hereunder permits to transmit a list of services of maximum 256 elements, as the length is provided by the first byte which has a maximum value of 255.

Data Mask Format
IMBC defines a data format responsible for handling data coming from multiple sources. More concretely, the data mask format carries multiple values corresponding to one specific service, which is called the reporting service. Using this format, one can send measurements of many different sensors in a single message, thus reducing the network load. The origins of the values are encoded in a binary mask. The message content of this data format contains the reporting service, the mask and the actual data. Its payload size is given by the following equation, with s sr and s sr_id representing the reporting service and reporting service identifier length. The service mask length is denoted by s ml . The number of bits in the mask having value 1 is given by m b . Finally, m f (s sr ) returns the data length as defined by Equations (1)-(4) of the reporting service depending on its data format.

Management Procedures
IMBC defines a set of services that enable management procedures responsible for device configuration, payload identification, transmission cycle configuration, device control, firmware update, protocol set-up and error handling. This section describes the applicability of these services in the network management of heterogeneous IoT applications.

Device Configuration
The device configuration procedure accomplishes two tasks, namely, device configuration announcement and device reconfiguration. The role of the former is to announce the implemented services at the device level whenever a device is initialised. The announcement is utilised by the server to automatically generate the necessary controls and device management functions. By implementing the device reconfiguration functions at both server and device level, the server acquires the ability to modify the device configuration at will.
The service representation described in Figure 2d transports a list of two services. The list length is given by the first byte ("02" hexadecimal). The list itself consists of the service identifiers for temperature ("20") and location ("33").

Data Mask Format
IMBC defines a data format responsible for handling data coming from multiple sources. More concretely, the data mask format carries multiple values corresponding to one specific service, which is called the reporting service. Using this format, one can send measurements of many different sensors in a single message, thus reducing the network load. The origins of the values are encoded in a binary mask. The message content of this data format contains the reporting service, the mask and the actual data. Its payload size is given by the following equation, with s sr and s sr_id representing the reporting service and reporting service identifier length. The service mask length is denoted by s ml . The number of bits in the mask having value 1 is given by m b . Finally, m f (s sr ) returns the data length as defined by Equations (1)-(4) of the reporting service depending on its data format.
Sensors 2020, xx, 5 7 of 17 "element-length": 1 } } The service representation described in Figure 2d transports a list of two services. The list length is given by the first byte ("02" hexadecimal). The list itself consists of the service identifiers for temperature ("20") and location ("33").

Data Mask Format
IMBC defines a data format responsible for handling data coming from multiple sources. More concretely, the data mask format carries multiple values corresponding to one specific service, which is called the reporting service. Using this format, one can send measurements of many different sensors in a single message, thus reducing the network load. The origins of the values are encoded in a binary mask. The message content of this data format contains the reporting service, the mask and the actual data. Its payload size is given by the following equation, with s sr and s sr_id representing the reporting service and reporting service identifier length. The service mask length is denoted by s ml . The number of bits in the mask having value 1 is given by m b . Finally, m f (s sr ) returns the data length as defined by Equations (1)-(4) of the reporting service depending on its data format.

Management Procedures
IMBC defines a set of services that enable management procedures responsible for device configuration, payload identification, transmission cycle configuration, device control, firmware update, protocol set-up and error handling. This section describes the applicability of these services in the network management of heterogeneous IoT applications.

Device Configuration
The device configuration procedure accomplishes two tasks, namely, device configuration announcement and device reconfiguration. The role of the former is to announce the implemented services at the device level whenever a device is initialised. The announcement is utilised by the server to automatically generate the necessary controls and device management functions. By implementing the device reconfiguration functions at both server and device level, the server acquires the ability to modify the device configuration at will. A service responsible for carrying multi-origin data is exemplified above. A message for this service is provided in Figure 2e. This particular message transmits the temperature ("20" hexadecimal) of two different sensors, of which the origin is defined by the mask ("a0" hexadecimal = "10100000" binary). The temperature values reported by the first and the third origins are "41f40000" and "41da0000", respectively.

Management Procedures
IMBC defines a set of services that enable management procedures responsible for device configuration, payload identification, transmission cycle configuration, device control, firmware update, protocol set-up and error handling. This section describes the applicability of these services in the network management of heterogeneous IoT applications.

Device Configuration
The device configuration procedure accomplishes two tasks, namely, device configuration announcement and device reconfiguration. The role of the former is to announce the implemented services at the device level whenever a device is initialised. The announcement is utilised by the server to automatically generate the necessary controls and device management functions. By implementing the device reconfiguration functions at both server and device level, the server acquires the ability to modify the device configuration at will. IMBC defines three services for device configuration announcement: dual service configuration ("00"), uplink service configuration ("01") and downlink service configuration ("02"). The upand downlink services allow for up and download traffic, respectively, whereas the dual service configuration allows for both. The dual service configuration can for example be used for a thermostat where the uplink traffic is employed for reporting the temperature to the server. The downlink traffic is then utilised for adjusting the temperature threshold to indicate when the heater should start. An example where only uplink traffic is necessary can be a device only reporting its battery level. A device only needing firmware updates can serve as another example only requiring a downlink service.

Payload Identification
This procedure identifies and processes the Payload Data Object (PDO) services that are responsible to carry the payload data. When originating from devices, the PDO's carry reporting data such as the battery level. When sent by the server, they can carry data used for device configuration. An example can be the temperature threshold for the thermostat.

Transmission Cycle Configuration
IMBC defines a service responsible for configuring the time period between two successive transmissions. The time period, expressed in milliseconds, is declared as an unsigned integer value which permits time period configurations with a maximum of ∼49 days.

Device Control
IMBC also provides a service which allows the server to perform actions such as power off, restart or sleep at the device level. This service has identifier "13". The actions are represented by a 1 byte value corresponding to the predefined actions listed in Table 3.

Firmware Update
IMBC handles firmware updates using two services: One service targets non-Internet devices, whereas the other handles Internet-connected devices. The former has service identifier "11" and carries firmware batches of variable length. The latter uses identifier "12" and transports the firmware's Uniform Resource Locator (URL) that points to the firmware available for download.

Protocol Setup
The protocol set-up procedure is meant for managing the IoT protocol used for succeeding transmissions. This is mandatory for hybrid devices implementing more than one IoT protocol. The identifier for this service is "10". The payload data comprises the desired protocol identifier chosen from the predefined list of protocols shown in Table 3. If the message sequence is "00", the transmitting protocol is automatically chosen by the receiver.

Error Handling
Error handling refers to the procedure of handling the error conditions present at the device level. This service is used to detect errors generated by the management procedures and maintaining device functionality. It has identifier "0a" and transports the predefined 1 byte error messages shown in Table 3.

Network Management Characteristics
IMBC achieves syntactic and semantic interoperability by implementing a common set of rules which are followed by both the server and the devices. Syntactic interoperability refers to the ability of each device within the network to communicate with one another. Note that, in this case, the term device is used broadly, and thus also includes the server. This type of interoperability is obtained by IMBC through the means of the service message formats. Semantic interoperability, on the other hand, is the result of the server and the devices implementing adaptors that automatically interpret data meaningfully by converting the service messages into system-readable representations. The syntactic and semantic interoperability allow IMBC to achieve device configuration adaptability and functional scalability.

Device Configuration Adaptability
Device configuration adaptability refers to the server's ability to adapt the management functions based on the device configuration. Concretely, the server automatically generates the list of interfacing functions for a device and the available services. It implements the interfacing functions for each IMBC service, which allow the users or the integrated applications to manage the IoT devices.
As illustrated in Figure 3, the device configuration is announced whenever a device is initialised. More specifically, each device provides a list of implemented services to the server, which in turns executes a function f with parameters the device identifier and the device configuration. This function therefore returns a list of interfacing routines that can be used for device management. These interfacing functions play an important role in achieving functional scalability described hereunder.

Functional Scalability
Functional scalability refers to the ability to enhance an IoT system by extending functionalities without disrupting existing activities. Being functionally scalable is highly advisable for IoT systems, due their evolving nature and their heterogeneity. Tasks such as battery replacement for battery-powered devices, device reporting adjustments or device reachability enhancement, demonstrate the need for such scalability to manage IoT systems with minimal effort. In this context, IMBC provides services and management procedures to adjust the device configuration, to perform service commands or to update service parameters at the device level as shown in Figure 4.
Though functional scalability vastly simplifies the management of IoT systems and in addition enhances the ability to automate data representations and application interactions, it does increase the overall complexity of the application. In other words, a trade-off between the management capabilities and energy consumption is to be made. In order to reduce the overhead introduced by IMBC, we have implemented support for power profiles that can be used to reduce power consumption. We will further elaborate on this next.

Transmission Energy Consumption
The transmission energy consumption varies with the payload size and the transmitting protocol particularities. It is calculated according to the following equation, with E tx , E p and p s denoting the transmission energy consumption in joule, protocol energy consumption per byte in joule and payload size in bytes, respectively. The payload size p s varies depending on the payload structure, the included services and the message formats. More concretely, it is the summation of the data sizes for all service representations. It is computed as follows, with s representing a service and fld, vld, fll, vll and dm representing the data length in bytes using the fixed-length, variable-length, fixed-length list, variable-length list and data mask format as explained in Section 3.1, respectively. The upper limits of the summations K, L, M, N and P represent the number of services for each format.

Experimental Evaluation
This section evaluates the proposed IMBC model and its use in a functional scalable heterogeneous IoT system. The system utilised for the experimental evaluation integrates various IoT protocols, namely, LoRaWAN, NB-IoT, WiFi and BLE. The aforementioned protocols support bidirectional communication allowing both server and devices to initiate the communication. The server implements a logically centralised management solution making use of IMBC, which provides interfacing functions for device management. The devices implement the IMBC services and the necessary adaptors to automatically extract and pack meaningful data. To evaluate the proposed communication model, a comparison has been conducted against the LwM2M standard to determine the payload size differences. In addition, we evaluate the energy consumption for two IoT protocols that target data transmission for low power devices.

Services
For the experimental evaluation, five services are transmitted within three different transmission profiles. A summary of the employed services can be found in Table 4. For our experiments, we have implemented three different transmission methods: The first one transmits the raw data, that is, the actual measured data with no additional identifiers for service identification. The second transmission technique utilises the proposed IMBC communication model and transmits the actual measured data together with the service identifiers, which allow extracting and packing meaningful data. The third transmission methods extends upon the second by adding three power profiles that prioritise the five services depending on freely chosen user parameters, such as battery percentage, for example. The power profiles are arbitrarily chosen to exemplify a scenario in which the device configuration is adjusted utilising the IMBC model in order to increase the battery lifetime. More specifically, power profile 1 transmits all service data until the battery capacity reaches 50%. Power profile 2 only transmits data associated with services having priority 0 and 1 until the battery capacity reaches 25%. Last, power profile 3 only sends data having priority 0 until the battery is fully discharged.
The power profiles play an important role for battery-powered devices as it can greatly increase their battery lifetime. Furthermore, and as previously mentioned, the power profiles can be arbitrarily chosen by the user. A key aspect of such an implementation is that one is able to predefine the lifetime of the devices by tuning the profiles. This can greatly aid in planning the battery replacement process, which can be problematic for large scale deployments.

Payload Size
This subsection compares the IMBC and LwM2M Tag-Length-Value (TLV) formats with respect to the generated payload sizes when bootstrapping the services described in Table 4. The values for LwM2M are determined by taking into account that multi-value messages are transmitted following the TLV format. Each service includes the type, the identifier, the length (if applicable) and the value as defined by the LwM2M specification [10]. Note that, in addition to the LwM2M TLV payload, a LwM2M message also comprises the transport bytes imposed by the CoAP protocol; this is not the case for IMBC, which does not rely on CoAP.
Embedding the aforementioned services in a single transmission message generates a message payload size of 36 bytes and 27 bytes for LwM2M TLV and IMBC, respectively. Note that this does not include the transport bytes for LwM2M TLV. The reduction in payload size provided by IMBC, approximately 25%, is significant for battery-powered devices and low-power transmitting protocols since the energy consumption for transmission is proportional to the data to be sent. Moreover, larger payloads may extend over the protocol limitations with regard to the maximum transmission payload size. For example, the maximum payload size for LoRaWAN varies between 51 bytes and 222 bytes for the EU863-870 band channels. In this case, the LwM2M messages may easily pass over the lower limit, therefore making the IMBC model much more suited for LoRaWAN transmitting devices. Table 4. Service data priority and the payload size of the raw data, the IMBC data and the LwM2M TLV data. Overall, IMBC advances over LwM2M in terms of payload size. Moreover, it eliminates the transport bytes imposed by the CoAP protocol and the need of a LwM2M objects translator for BLE devices as proposed by M. Ha et al. in [16]. In view of the foregoing, we may also conclude that the IMBC model is more suitable than LwM2M for low-power deployments.

Power Consumption
To evaluate the power consumption of IMBC, two IoT protocols have been taken into consideration: LoRaWAN and BLE v5.0. The reason for not incorporating WiFi and NB-IoT in our experiments is justified by the negligible impact of the proposed IMBC identifiers in terms of power consumption per transported bytes, as discussed in [11,18].

LoRaWAN
This subsection evaluates the impact of IMBC in terms of battery lifetime for LoRaWAN enabled devices. The theoretical battery lifetime is computed for a battery capacity of 2400 mAh based on the formalism established in [19]. Specifically, the battery lifetime T li f etime_unACK for unacknowledged transmission is given by with C battery and I avg_unACK denoting the battery capacity and average current consumption, respectively. I avg_unACK varies with respect to the notification period and transmission states. It is computed as follows, with T Noti f , N states , T i and I i denoting the notification period employed by the device, the number of transmission states, the duration of state i and the current consumption of state i, respectively. The average values for the different states are given in [19]. The battery lifetime is computed for three different data rates and the related configurations for EU863-870 band channels. For each data rate, the transmitted payload includes the transmission profiles particularities described below.
• Data rate 0-Spreading Factor 12, Bandwidth 125 kHz, • Data rate 3-Spreading Factor 9, Bandwidth 125 kHz, • Data rate 6-Spreading Factor 7, Bandwidth 250 kHz. Figure 5 demonstrates the relatively limited impact of the IMBC identifiers in terms of power consumption, despite enabling much more functionality with respect to network management. However, note that the impact is more pronounced for lower data rates. Transmitting IMBC data without power profiles utilising Data rate 0 results in a decreased battery lifetime of 14.5% when compared to sending the raw data. For Data rates 3 and 6 the diminished lifetime is reduced to approximately 3.2% and 0.5%, respectively. The negative impact on the battery lifetime, however, can be mitigated by introducing power profiles. When using thresholds 50% and 25% for example, we do not detect any decrease in battery lifetime for IMBC, as shown in Figure 5a,c,e. On the contrary, for Data rate 0 the lifetime increased by more than 3.2% when taking the raw data transmission as the reference.
The same conclusions can be drawn for LwM2M. Also in this case the impact on battery lifetime is more apparent for lower data rates. However, when compared to IMBC, we observe from the figures that the higher payload size of LwM2M negatively impacts the overall power consumption. Though the power profiles indeed mitigate this problem, the thresholds of 50% and 25% do not suffice in this case and the reduced battery lifetime is still substantial, unlike for IMBC. Figure 5 further shows the results when using power profiles with thresholds 30% and 15%. By comparing the results of using both power profiles thresholds, one can derive the impact of enabling different power profiles. In principle, the results demonstrates the ability to adjust the battery lifetime by tuning the thresholds. Note that this is also true for the highest data rate, where the difference in lifetime is still days. As mentioned previously, the ability to plan and manage the battery lifetime can greatly facilitate and streamline the battery replacement process, which can be very tedious for large scale deployments. (e) DR6 -Power profiles thresholds 50% and 25% (f) DR6 -Power profiles thresholds 30% and 15% Figure 5. Battery lifetime for LoRaWAN data rates DR0, DR3 and DR6 when transmitting Raw data, IMBC data, IMBC data with power profiles, LwM2M TLV data and LwM2M TLV data with power profiles. The orange coloured lines correspond to Raw data, the blue coloured lines correspond to IMBC data and the green coloured lines correspond to LwM2M data.

Bluetooth Low Energy v5.0
For BLE v5.0-enabled devices, we compute the theoretical battery lifetime for a battery capacity of 500 mAh by dividing the battery capacity with the estimated average current computed by the power profile estimator published by Nordic Semiconductor [20]. Similarly to LoRaWAN, we incorporate three different data rates in our tests for both IMBC and LwM2M TLV while implementing the same functionalities for both techniques: • PHY8S-LE Coded S = 8, data rate 128 kbps, • PHY1-LE 1M, data rate 1 Mbps, • PHY2-LE 2M, data rate 2 Mbps.
The evaluating device is a connected peripheral utilising an nRF52840 chip at a working voltage of 3.3 V with a connection interval of 100 ms and transmission power equal to 0 dBm. Figure 6 illustrates the battery lifetime computed for each data rate and each transmission profile for both IMBC and LwM2M TLV. Generally speaking, the same conclusions as for LoRaWAN can be drawn for the proposed method. Also, in this case, the impact of IMBC without power profiles is greater for lower data rates in terms of battery life. More specifically, for data rates PHY8S, PHY1 and PHY2, the power consumption is increased by approximately 14.5%, 6.5% and 3.7%, respectively, when taking the raw data transmission as a reference. Note that according to [20], values less than 5% are equivalent to device to device variations. For LwM2M TLV without power profiles the increase in power consumption is much more pronounced. In this case, the reduced battery lifetime increased correspondingly by 49%, 33%, and 27%, respectively, when taking the raw data transmission as a reference. Similarly as for LoRaWAN, the increased power consumption can be completely negated by using power profiles with thresholds 50% and 25% when using IMBC, as shown in Figure 6a,c,e. Moreover, they allow us to tune the battery lifetime in a variable window of 18, 24 and 16 days for data rates PHY8S, PHY1 and PHY2, respectively. For LwM2M TLV, however, the reduction in battery lifetime remains substantial even when using power profiles. Taking Figure 6a as an example, we observe a reduction in battery life of 20% for LwM2M TLV. In contrast, IMBC increased battery life time with 2.9%. (f) PHY2 -Power profiles thresholds: 30%, 15% Figure 6. Battery lifetime for Bluetooth data rates PHY8S, PHY1 and PHY2 when transmitting Raw data, IMBC data, IMBC data with power profiles, LwM2M TLV data and LwM2M TLV data with power profiles. The orange coloured lines correspond to Raw data, the blue coloured lines correspond to IMBC data and the green coloured lines correspond to LwM2M data.

Conclusions
This paper proposed a message-based communication model that achieves network management and functional scalability for heterogeneous IoT systems. The model comprises a dictionary of services utilised by the devices and the server to interact and to perform the desired actions agnostic to the implied IoT protocol. Syntactic and semantic interoperability is achieved by implementing adaptors that automatically interpret data meaningfully and convert the service messages into system-readable representations. This paper described the message formats, the management procedures and the interfacing functions introduced by the proposed communication model, and addressed the model's particularities in terms of network management and functional scalability. We evaluated the proposed methods and showed its applicability in a functional scalable heterogeneous IoT system that integrates LoRaWAN, NB-IoT, WiFi and BLE. Our experimental assessment revealed that our method allows for more compact data representation than that of the LwM2M standard, a protocol specifically designed with IoT applications in mind. Our experiments also revealed that our communication model has a limited impact in terms of power consumption, despite providing much more functionality with respect to network management. In fact, the increased power consumption can be completely negated when using the power profiles implemented on top of our communication model. Besides reducing the energy consumption, those power profiles allow one to predefine the battery lifetime of the devices, which can greatly aid in streamlining the battery replacement process in large scale deployments. Regarding future work, the underlying transmitting protocols impose limitations with respect to the payload size. In the current approach, the employed transmission protocol is predefined. Using the appropriate transmission protocol depending on the payload size is left as a topic for future investigation.