Lightweight and Secure Publish-Subscribe System for Cloud-Connected Ultra Low Power IoT Devices

—The Internet of Things (IoT) enables the devel- opment of innovative applications in various domains such as healthcare, transportation, and Industry 4.0. The integration of the cloud platform’s large processing and storage capacity with the ubiquitous sensing and actuation provided by the devices creates an IoT architecture that provides vast raw data. The IoT devices send the data to the cloud platform with the developed IoT applications, which can use publish-subscribe systems. However, messages with sensitive content require end- to-end security. Besides that, IoT devices may present processing, memory, payload, and energy restrictions. In this sense, messages in an IoT architecture need to achieve both energy-efﬁciency and secure message delivery. Thus, this article’s main contribution refers to a system that standardizes the publish-subscribe topic and payload used by the cloud platform and the IoT devices. Our system also provides end-to-end security while surpassing the energy-efﬁciency to send data than the main related works in the literature regarding the use of publish-subscribe systems in IoT.


I. INTRODUCTION
The Internet of Things (IoT) enables the development of applications in various domains, such as healthcare, transportation, and Industry 4.0 [1][2][3], providing services of sensing, monitoring, and automation of activities [4]. For this, IoT applications require the union of the resources provided by devices (such as environmental sensing) and the processing power of cloud computing [5][6][7].
The IoT is ubiquitous because of the many devices connected via the Internet [1; 8], which contain sensors and actuators to interact with their environment [9; 10]. Thus, there are data transmission standards in several layers [11] aiming to connect IoT devices to the Internet [1; 8] such as 5G, Narrow Band IoT (NBIoT) or Bluetooth, and not all protocols are IP-based. In turn, IPv6 over Low energy Wireless Personal Area Network (6LoWPAN) is an IETF standard that provides native integration to the Internet, with end-to-end message forwarding [7] for 6LoWPAN devices on Wireless Sensor Networks (WSN). 6LoWPAN devices, from now on, referred to as Constrained Wireless IoT devices (CWIoT), present restrictions in processing, memory, payload, and energy [12], a fact that poses challenges about the communication with the cloud.
With the integration of the constrained devices with the cloud computing the CWIoT respond to requests coming only from the cloud [5], as well as enabling aggregation and use of sensing data by cloud applications.
For this integration to be successful, CWIoT and the cloud platform need to exchange standardized messages. The cloud platform is IP-based; therefore, the integration of CWIoT to the cloud platform is only possible if the upper layers of the IP layer use the same protocols, which poses a challenge considering the restricted nature of CWIoT.
In this scenario, for the exchange of messages between CWIoT and the cloud platform, the Message Queuing Telemetry Transport (MQTT) and the Constrained Application Protocol (CoAP) are the de facto standards [13][14][15][16]. The MQTT uses messages in the publish/subscribe format, which contains two parts: the MQTT topic (a hierarchical list indicating which context the data sent refers to) and the MQTT payload. The CoAP messages use the request/response format using RESTful standard. Also, the LightWeight Machine-to-Machine (LWM2M) protocol [17] provides standardized and contextaware messages on top of CoAP.

A. Problem fundamentals and contribution
MQTT lacks standardization of its topic and payload. Because of that, we observe in the works of [14; 18-20], proposals for topics and payloads without concern for standardized messages -nor data (devices measurements), nor metadata (identification of devices and their sensors, deployment location). This lack of standardization results in MQTT topics and payloads, ranging from tens to hundreds of bytes. For instance, [19] defines an MQTT topic requiring 33 bytes and an MQTT payload with at least 64 bytes, while [20] defines a topic with at least 70 bytes.
For this reason, the works of [14; 18-20] are not directly concerned with the energy efficiency of the topic or the payload, mainly because they use devices of higher capacity than the CWIoT. The use of CWIoT poses challenges in communicating with the cloud via the Internet, given their restricted characteristics. However, even in the middle of these challenges, there is the advantage that CWIoT is more energyefficient than higher capacity devices [21]. Considering the problems presented, the lack of standardization in publish-subscribe applications based on MQTT is a relevant gap. Standardization needs to be fully integrated into the MQTT topic and payload. On the cloud platform, the context-aware services [13; 15] allow embedding metadata (location, data type, device sensor used, and other characteristics) about the devices' data. Thus, both the MQTT topic and payload must be context-aware at the same time as being energy efficient.
Given the above, we observed that the WSN-cloud integration using MQTT lacks standardization and security. Also, CWIoT-cloud communication addresses other challenges, such as orchestrating possible billions of devices [1; 8] at the cloud platform.
Also, Transport Layer Security (TLS), as used by [22] on 802.11 devices, is not an option for WSN devices given its constrained nature [23; 24]. Because of that, a security mechanism must be used to overcome this issue.
Thus, our contribution consists of a LightWeight, energyefficient, and end-to-end secure Publish-Subscribe system based on MQTT (LWPubSub) to interconnect WSN devices (CWIoT) to the cloud. Our system provides MQTT topic and payload standardization, which permits unique identification of a device (and each of its sensors) within the IoT architecture, and meets the CWIoT restrictions. The messages also accomplish the triad confidentiality, authenticity, and integrity system, providing end-to-end security between the CWIoT and the cloud platform. In this secure scenario, one can use any MQTT Broker to deliver the LWPubSub messages. At the cloud platform, the orchestration and provisioning of CWIoT devices occur in domains [1; 6; 7] (for instance, school, hospital, transportation, industry, among others) and their sites (each network of a specific domain). The IoT Agent, at the cloud platform, is the service responsible for receiving messages from CWIoT on the cloud platform [15; 25]. Fig. 1 presents the panorama of the system within the proposed IoT architecture.
The LWPubSub represents advances in interconnecting constrained devices to the cloud. The results obtained in comparison with the main related works show a 40% lower topic and a 48% lower payload (even when comparing works that do not implement security). The most important result is related to energy since the use of LWPubSub on the CWIoT in an IoT Architecture is 98% more energy efficient than the best work identified in the related works.

B. Article organization
The remainder of this article is organized as follows. In Section II, we define the main aspects of the interconnection of CWIoT-cloud and introduce the security concerns in IoT. In Section III, we present our lightweight, energy-efficient, and secure publish-subscribe system used in our proposed IoT architecture to interconnect the CWIoT with the cloud platform. The evaluation of the proposed system is in Section IV, and we present the results, discussion and comparison with the main related works in Section V. We highlight the main related works in Section VI. Finally, in Section VII, conclusions and future works are given.

II. WSN-CLOUD SECURE COMMUNICATION
Cloud environments support prediction and detection security controls [26; 27]. Often security is in the devices and systems used in the supported services. WSN devices (CWIoT) in this work are 6LoWPAN devices: embedded systems restricted in processing, memory, payload, and energy resources [12].
The connection of the CWIoT to the Internet (as stated in RFC 6282) requires the use of the 6LoWPAN Border Router (6LBR) [28]. The 6LBR performs IPv6 packet routing -using the IPv6 Routing Protocol for Low-Power and Lossy Networks (RPL -RFC 6550) -with compressed headers on IEEE 802.15.4 networks (MTU 127 bytes) -the 6LBR is more robust equipment when compared to other nodes in the network.
For link-local communication, the 6LoWPAN network provides the devices with an energy-efficient link-layer protocol to exchange packets: the Time Slotted Channel Hopping (TSCH) protocol. TSCH is defined in the IEEE 802.15.4-2015 standard and is highly reliable and energy-efficient [29][30][31]. In a 6LoWPAN TSCH network, time is divided into slots, with the clock of all devices synchronized by the network coordinator (6LBR), with transmission and reception actions occurring at predefined times. There are mainly three types of slots: reception, transmission, and sleep (to save energy) [21; 29-31].
However, even with their limitations, 6LoWPAN devices can perform end-to-end communication and end-to-end security [7].
With cloud integration, CWIoT provides large volumes of raw data that need to be appropriately stored by the cloud (which, among other tasks, should analyze the data to remove outliers and misreadings) [32]. This performance of the cloud platform makes the data decision process more efficient.
For the decision to be more efficient, the raw data must contain some meaningful context [32][33][34]. Context-aware services at the cloud platform provide semantic meaning for the data (typically, the context information comprises a place and a device sensor, among others [17; 33; 35].
The MQTT publish-subscribe protocol use a server to deliver messages between the devices and the cloud: the MQTT Broker.
MQTT is a reliable protocol (by using TCP) for message delivery in IoT scenarios [36]. MQTT uses the publish/subscribe architecture and enables the interaction of multiple endpoints (broker, publisher, and subscriber) [18; 20], as presented in Fig. 2. As seen in Fig. 2, the central entity in this communication is the MQTT Broker. This server allows communication between clients, which can operate as publishers (to send data), as subscribers (to receive data), or both. Interactions between clients are moderated by the broker, so clients do not need to know each other to exchange messages [20]. A client is a peer, an application, or a device that exchanges application messages over a given topic with another client. Client communication occurs at a request to the broker to subscribe or publish messages, specifying the topic and payload fields of the message. Thus, clients who want to receive a message, subscribe to a specific topic with the message delivered on the payload [1; 16; 20].
The main MQTT messages are [16]: CONNECT (connect a client to the broker), SUBSCRIBE (subscribe/unsubscribe a client to/from a topic), PUBLISH (send a message from a publisher to the broker or from the broker to a client who previously subscribed to the topic). The communication architecture of the MQTT protocol, shown in Fig. 2, exemplifies a communication with an IoT device (publisher) posting data from its sensors and actuators on a given topic. The other clients (subscribers) -laptop, desktop, smartphone -who previously subscribed to that topic, receive the message posted by the device through the MQTT broker.
Topics are hierarchically organized in a tree structure using the "/" separator. The payload (second field) is topic dependent.
As presented by [37; 38] it is common to use JSON in the payload of the MQTT message. In this way, an MQTT message (topic and payload) could be: "school/firstfloor/kitchen {"temp": "25.00"}".
We observe that the main disadvantage of MQTT is the lack of standardization in both fields of the MQTT message, causing messages to varying greatly in size, from tens to hundreds of Bytes [18][19][20], which may require incompatible resources of a CWIoT, and can lead to an unfeasible communication.
However, even with end-to-end message delivery using MQTT, end-to-end security in the CWIoT/WSN-Cloud union is a challenge (given the restricted characteristics of CWIoT) and a mandatory requirement, according to [7; 11; 28; 34; 39].
According to [40], it is urgent to research security issues in IoT. For instance, security is essential for the following IoT scenarios: patient data [34], node location [41], message traffic [2].
However, correctly apply end-to-end security is critical. The work of [10] presents an example of data leakage with the inappropriate use of encryption (mainly related to the repetition of the initialization vectors with the same key).
Another example of the necessity of secure messages is with smart homes. If the messages are unencrypted, a compromised smart lock may permit unrestricted access to the home [7].

III. LWPUBSUB SYSTEM FOR WSN-CLOUD INTEGRATION
USING SECURE MQTT MESSAGES This section presents our LWPubSub system 1 based on MQTT, providing WSN devices-cloud integration with endto-end security.
We understand the IoT as an architecture involving the union of devices, gateways, networks, and servers. Hence we use the term IoT architecture, also used by [1; 7; 10].
Because of that, we propose an IoT architecture able to manage the large amount of CWIoTs (and their sensors) attached to it on the cloud platform.
The IoT architecture presented in Fig. 3 comprises three layers, structured as follows: objectID/instanceID metadata, where objectID is the type of the sensor and instanceID is the sensor itself. The gateway (6LBR) is an unconstrained device (although more compact than edge and core routers), usually connected to a continuous power source, and is the coordinator of the WSN. • MQTT Broker: the destination of the encrypted message generated by the LWPubSub system (on the CWIoT or the cloud platform). • Cloud: sends commands to and receives measurements from the CWIoT (through the IoT Agent), storing and providing services for the IoT data.
The IoT architecture can act in several domains, managing, orchestrating, and provisioning the CWIoT on the respective sites, together with their respective sensors. The cloud platform aggregates and manipulates the CWIoT sensors data using the provided metadata.
Our LWPubSub system receives the following requirements and parameters from the IoT architecture for its operation presents in Fig. 4. The domains are the vertical markets [1] that build the IoT architecture. A given IoT architecture, for example, can contain the following domains: school, healthcare, transportation, among others (this work does not restrict the design of the domain, one can use a numeric sequence). The sites of each domain specify the sites of a specific domain (the sites are the places to deploy and use the CWIoT) and its respective IPv6 prefix. The IPv6 suffix of the CWIoT (deviceID) ensures the unique identification of each CWIoT at a domain. We utilize the objectID/instanceID metadata provided by the IPSO registry [42] to identify the CWIoT sensors.
The system requirements presented are essential and manda-tory in an IoT Architecture. These requirements guide the required number of bytes of the MQTT topic and payload used in the publish-subscribe actions. The number of transmitted bytes directly impacts the energy efficiency of the CWIoT and, consequently, the architecture as a whole. Fig. 4 shows the LWPubSub structure. According to Fig. 4, the LWPubSub contains three structures for the execution of its tasks: Cross-platform publishsubscribe message, Cloud platform layer, and CWIoT layer.
LWPubSub constructs the MQTT message (topic and payload) as shown in Fig. 4. We define two topics in the system: one for sending messages from CWIoT to the cloud platform (/<# of domain>/<CWIoT IPv6 suffix>) and another for sending from the cloud to CWIoT (/<# of domain>/<CWIoT IPv6 suffix>/cmd) -the first part contains the domain number, and the second the IPv6 suffix of the CWIoT.
Still in the sense of standardization, the MQTT payload contains the objectID and instanceID metadata, and the data to be sent (<objectID><instanceID>|<data>). For the LWPubSub system use any MQTT Broker, the system sends the topic in plaintext, which guarantees the endto-end delivery of messages between MQTT clients without the need for an intermediate proxy.
Furthermore, to guarantee end-to-end security, the LWPub-Sub system encrypts the MQTT payload using symmetric encryption. Considering the restrictions of CWIoT, the Advanced Encryption Standard (AES) is safe and suitable for this purpose [43]. LWPubSub permit the use of AES Cipher-Block-Chaining (AES-CBC) or Counter (AES-CTR), which require a 16-byte Initialization Vector (IV), that must never be repeated together with the key for the same message. Thus,  before sending each message, the CWIoT and the IoT Agent must generate a random 16-byte number to be used as the IV.
The LWPubSub system encrypts the MQTT message and generates the MQTT payload according to these steps: 1) The first byte is an identifier of the encryption algorithm used.
2) The next 16 bytes refer to IV.
3) The next bytes (at least 16) refer to the encrypted message.
We consider end-to-end secure the messages exchanged between the CWIoT and the IoT Agent.
Regarding the CWIoT communication, radio uptime is the device resource that requires more energy [21; 44; 45]. Therefore, two resources require attention: the link-layer protocol must have low energy consumption, and messages should avoid fragmentation since the MTU on 6LoWPAN networks is limited to 127 bytes. Thus, we use the TSCH protocol, which provides reliability in the delivery of messages [29; 30] while presenting low energy consumption compared to other linklayer protocols used in 6LoWPAN networks [29].
At the cloud platform (as shown in Fig. 4) occurs the CWIoT provisioning according to the metadata of the devices sensors (objectID/instanceID). After provisioning, the cloud can receive contextualized data from each CWIoT sensor.
After cloud provisioning, CWIoTs can initialize. The LW-PubSub system (as shown in Fig. 4) defines three types of messages, according to the following: • CWIoT-cloud (most common case): -Send measurement: the CWIoT obtains the sensor measurement, and composes the MQTT payload by inserting the metadata (objectID and instanceID), followed by the data. In this case, the CWIoT sends messages after waiting for predetermined time intervals or after a request from the cloud platform.
• Cloud-CWIoT: -Request measurement: requires the CWIoT to respond to the requested sensor measurement immediately, sending in the MQTT payload only the objectID and instanceID metadata that represent from which sensor of the CWIoT it wants to receive the measurement. -Command execution: similarly to "Request measurement", in this message the cloud platform sends, in addition to metadata, the command to be executed in the "data" field.
Regardless of the originator, the MQTT payload is encrypted and linked to the respective MQTT topic, thus composing the LWPubSub message.
As shown in Fig. 4, the cloud platform subscribe to all topics of its orchestrated and provisioned CWIoT (excluding, therefore, the topics that end with "/cmd"). CWIoT subscribes exclusively on the topic of its deployment domain (and with its IPv6 suffix) -the third part of the topic ends with "/cmd". Upon receiving the message, the actions performed are: • Cloud platform: the IoT Agent interprets the MQTT topic to define the orchestration and provisioning location (domain, site, CWIoT triad). After that, the context-aware service store, along with previous information, the sensor measurements sent in the MQTT payload. • CWIoT: execute a command or send a measurement from a sensor based on the cloud platform's message.

IV. LWPUBSUB EVALUATION AND RESULTS
To analyze the efficiency and performance of the proposed LWPubSub system, we conducted several experiments. In this section, we also present the results.
We observe and evaluate, with the execution of the experiments, the following metrics: 1) Energy consumption: intends to observe the behavior of CWIoT in different operating conditions, obtaining measurements with variations in poll frequencies and encryption modes (both further detailed). In Table I, we summarize the characteristics of the equipment, devices, sensors, and the parameters of the LWPubSub system.
For the validation of the IoT Architecture, and considering as a premise the use of open standards, the FIWARE platform [15; 46] provides the needed infrastructure for an opensource cloud. The FIWARE platform contains Generic Enablers (GE), including services called IoT Agents that receive CWIoT measurements. The Orion Context-Broker (the main GE) is the context-aware service provided by FIWARE. Contextualized data enable the correct processing of information by the cloud platform [46]. We developed an IoT Agent for MQTT (based on the existing FIWARE) that interprets LWPubSub messages (an additional contribution of this work), and we integrated it in the FIWARE-based cloud platform.
The cloud platform is the first layer of an IoT Architecture that needs to be structured and initialized. In the cloud platform, the domains, sites, and devices are orchestrated and provisioned first (in the case of this experiment, we provision the domain "99", prefix "fd00::/64", and the CWIoT suffix "00124b05257a"). Based on this triad, we create the following structure using objectID and instanceID: 33030 (HDC temperature sensor), 33110 (red LED), 33111 (green LED), and 33380 (alarm). We use the pattern defined in Section III with the use of IPSO Objects concatenated with the object's existing instance (sensor).
The MQTT Broker, based on mosquitto [47] runs at the Huawei Cloud. The IoT gateway runs on a Raspberry Pi model 3B, which contains an IEEE 802.11 interface connected to the Internet and an IEEE 802.15.4 interface (via Launchpad -the 6LBR) for communication with the 6LoWPAN network.
Next, we start the CWIoT and its network, since the cloud platform is structured to receive the lightweight, contextaware, and secure LWPubSub messages.
The devices of the validation scenario are the Texas Instruments Sensortag (CWIoT) and Launchpad (6LBR), both with CC2650 (IEEE 802.15.4) radio, 128 KB ROM, 20 KB RAM. To comply with the energy-efficient goal of the LWPubSub, we use the Time Slotted Channel Hopping (TSCH) as the link-layer protocol as it presents the lowest energy consumption relative to this layer on 6LoWPAN networks [30] (we use TSCH minimal schedule). Above TSCH, the 6LoWPAN protocol uses RPL, followed by the TCP protocol that loads the MQTT payload with the LWPubSub application.
We use Contiki-NG, an opensource Operating System (OS) for CWIoT, which supports the constrained features of devices while allowing the development of firmware for specific applications such as MQTT.
Thus, as can be seen in Fig 5, the 6LBR (Launchpad) receives the LWPubSub messages from the CWIoT (Sensortag) and forwards them to MQTT Broker (Raspberry Pi).
For end-to-end security, we implement symmetric encryption with the system being able to use AES-CBC or AES-CTR with 128, 192, and 256-bit keys.
In possession of the metadata (objectID and instanceID) and the data, the LWPubSub system follows these steps: 1) IoT Agent: Handle received data using context-aware service. 2) CWIoT: Sends requested measurement or executes a command. Fig. 6 presents a measurement sample taken from the experiments. In this example, the 16 bytes of the topic (not ciphered) -uniquely identifies the CWIoT on the domain. The first 5 bytes of the payload uniquely identifies the HDC temperature sensor of the Sensortag (the remaining bytes comprise the separator between metadata and data -the measurement sent). Only the payload (11 bytes) is encrypted. We note the importance of end-to-end security, since if the LWPubSub system does not encrypt the MQTT payload, the device structure and data may be maliciously observed in the MQTT Broker.
IoT applications may require different time intervals when collecting sensor measurements, which can range from use as wearable (which requires many measurements per minute) to use as measuring environmental conditions (which requires few measurements per day). Therefore, to observe the behavior of CWIoT in different operating conditions, the experiments conducted include the following poll frequencies to obtain and send measurements: We performed a 24-hour experiment for each poll frequency, totaling five days of the experiment, with periodic sending of temperature sensor measurements.

V. RESULTS AND DISCUSSION
The experiments performed have the purpose of observing the footprint, size in bytes of the topic and payload, and the energy required from CWIoT for two situations: 1) Connection and subscribe actions with MQTT Broker. 2) Exchange of messages considering the execution of the activities outlined in Fig. 4: • CWIoT: send measurement at specified time interval, send sensor measurements after receiving a request, execute action after receiving a command. • Cloud platform: receive sensor measurement, send command execution, send measurement request.
In the first round of experiments, we performed each of the previous CWIoT activities 100 times (we waited 10 seconds between executing each event) at each of the six encryption modes (AES-CBC or AES-CTR with 128, 192, and 256-bit keys). These experiments allow us to obtain the mean and standard deviation of the energy involved in these operations, making a total of 1800 messages.
With the conclusion of this first round of experiments, we summarize the main results of LWPubSub in Table II.
The second round of experiments aims to evaluate the CWIoT in a scenario of periodic sending of measurements. Thus, it will consider the wide variety of IoT applications presented in Section IV, which require different time intervals when sending measurements. Therefore, the experiments based on poll frequencies shown in Table I were executed (each one) for 24 hours, so we evaluate the real conditions of an IoT device with the use of LWPubSub. The main objective is to evaluate the daily energy consumption of a CWIoT.

A. Standardization and interoperability of MQTT messages
As stated by [48], standardization decreases the gaps and reduce system complexity. Our LWPubSub system goes in this direction once we provide a unique MQTT topic to each device and standardized the metadata.
Regarding the MQTT topic, our system design proposes a short and lightweight, yet complete, MQTT topic. The MQTT topic generated by our proposed system retain the unique identification of devices in the respective domain.
Our proposal is opposed to the various messages exchanged between devices -a resource used by [18; 19], which generates longer messages. The smallest possible MQTT topic observed in the work of [18] is 27 Bytes, while in [19] it is 33 Bytes.
The work of [20] covers the interconnection of IoT devices to the cloud platform. However, it does not act in standardizing the MQTT messages and presents different topics when exchanging control and data messages. For data messages, the topic is at least 70 bytes. Fig. 7 presents our MQTT topic results, comparing it with the results of the main related works (the smaller, the better). Regarding the MQTT payload, the experiments demonstrated that an humidity or temperature messages using LW-PubSub (MQTT payload with confidentiality, authenticity, and integrity) is 32 Bytes long. The total IPv6 packet is 113 (CWIoT-cloud) or 117 (cloud-CWIoT) Bytes, thus, there is no fragmentation of messages sent/received by the CWIoT. The lowest MQTT payload observed in the works of [18; 19] is 64 Bytes, and the total IP packet is even greater. Fig. 8 presents our results, comparing it with the main related works (the smaller the message, the better). Our proposal still includes end-to-end security, while only [18] applies security.

B. Footprint
The result of the footprint shown in Table II comprises the LWPubSub system developed in Contiki-NG using the Sensortag CWIoT. We segregate the LWPubSub system from the rest of the operating system's (OS) functions to identify the footprint required in ROM by the application. The other OS functions, such as TSCH, RPL, 6LoWPAN, and TCP, among others, require 98088 Bytes. The LWPubSub system (considering the application itself that runs on the MQTT plus the encryption functions) corresponds to 9507 Bytes (the CBC and CTR modes and the different AES-key sizes do not influence the space required in the memory).
The use of LWPubSub system in CWIoT brings advantages relative to the footprint. Our 9.5KB footprint covers the entire MQTT standard stack plus the LWPubSub system inside the CWIoT and is smaller than [19]. The work of [18] presents a 13MB footprint but includes not only the MQTT in the footprint calculation (even though, extracting, for example, half of the footprint requires many more bytes than the LWPubSub footprint results). Fig. 9 presents the footprint comparison (the smaller the footprint, the better).

C. Energy consumption
For energy consumption calculation, we proceed according to Eq. 1, using the Contiki-NG Energest [49] module. We calculate the energy (in millijoules) from the time spent (in seconds) of each CWIoT resource (CPU, LPM, TX, RX). The voltage is fixed at 3 V (when supplied by two AA batteries), and the current (I) for each resource is shown in Table I.
The CWIoT connection with the MQTT Broker requires 19.800 mJ, while MQTT subscribe action requires 6.367 mJthese actions do not depend on the encryption algorithm since they are not encrypted.
The energy consumption of the LWPubSub presented in Fig. 10 refers to the CWIoT messages "Send measurement", "Execute a command", and "Receive a request and send response". These messages require respectively, on average, 0.985, 0.940, and 1.986 mJ (considering all measurements covering all encryption modes and key sizes). In Fig. 10, we present the detailed energy consumption of these messages.  We summarize the results of daily energy consumption in Fig. 11. Observing the results presented in Fig 11, regardless of the poll frequency, the commands sent by the cloud platform consume significantly lower energy compared to a day of CWIoT usage (which sends measurements periodically). Therefore, we conclude that one can intersperse the messages sent from the cloud to the CWIoT with the messages previously configured in the poll frequencies once what guides the energy consumption of the CWIoT are: sleep time (LPM) and listening (RX). CPU and TX consumption barely rises and is practically the same for medium, low, and very low poll frequencies. Thus, sending 96, 4, or 1 message per day (medium, low, and very low poll frequencies) consumes almost the same amount of energy.
Furthermore, the "very high" poll frequency, which demands more energy from the CWIoT, ends up not differing from the other poll frequencies' energy consumption, even those that wait longer between measurements such as "low" and "very low". We can observe the previous comparison of energy consumption when looking at the battery life of the CWIoT at each poll frequency. Two AA batteries provide 30780 J (2.85Ah * 1.5V * 3600secs. * 2) of energy. We present in Fig. 12 the battery life in each experiment scenario, given the poll frequencies presented and the daily energy consumption in Fig. 11.
The use of CWIoT on an IoT Architecture was the better decision once the constrained device can perform the same tasks as an unconstrained device like Raspberry Pi, relative to MQTT messages.
Our system requires 0.940 mJ of energy of a CWIoT to send a message (details in Table II and Fig. 10). This energy consumption requires 41 times less energy than the best result of [19] -39.47 mJ (their work does not apply security) and 320 times less energy than the best result of [18] -301 mJ.
Regarding receiving messages and executing commands, our LWPubSub system also demonstrates an advantage over the works of [18; 19]. Our proposal requires 1.986 mJ of energy, while the work of [18] requires 561 mJ and [19] 39.9 mJ.
The LWPubSub system is also advantageous for connecting with the MQTT Broker, which requires 19.800 mJ, while [18] requires 222 mJ, and [19] 298.5 mJ. The work of [20] does not present results regarding the energy consumption of IoT devices.
The comparative results are consolidated and presented in Fig. 13.

D. Security
The LWPubSub system applies confidentiality to the MQTT payload allowing the use of six encryption modes. As a comparison, [18] has only one mode, which contains a vulnerability: the authors use the same generated session key Fig. 13. Energy results compared with the related works to encrypt the same message (for instance, on/off a sensor). Thereby, new encrypted on/off messages transmitted later will be identical. By contrast, our system sends a byte to identify the encryption algorithm and a new IV at each message to not reuse the triad: key, IV, message.
Moreover, we achieve end-to-end security between MQTT clients (CWIoT and IoT Agent), thus allowing the use of any MQTT Broker without customization.

VI. RELATED WORKS
Regarding cloud-to-devices messaging using MQTT, the works of [18][19][20] aim to exchange MQTT messages using unrestricted IoT devices. The work of [20] proposes integration to the cloud platform, while [18; 19] uses a framework developed by the authors for communication between IoT devices. Regardless of the approach, the previously cited works use robust equipment like the Raspberry Pi as an IoT device, which we use as a gateway between the network of IoT devices and the cloud. Conversely, our architecture proposes the use of CWIoT to perform sensing and actuation tasks in the environment.
Also, the platform proposed by [20] does not send periodic messages from the IoT device to the cloud. Instead, the cloud platform sends several rules to be followed by the devices that, in turn, perform the scheduled actions. Their platform also requests the device's sensors' status, which can generate messages of at least 87 Bytes. Furthermore, the works of [19; 20] do not use security to protect the MQTT payload.
About context-aware messages on WSN, the work of [50] proposes the integration of legacy embedded systems software applications, which uses TinyOS. The authors present in the conclusion as a future work add new features to provide context-awareness capabilities. We use context-aware messages in both the topic and the payload. These messages enable the provisioning of constrained devices and their sensors on the cloud platform.
In the sense of MQTT security for IoT, the work of [23] comprises three security levels for publish/subscribe MQTT messages. Although the authors cite constrained devices, they do not evaluate energy consumption nor message size. Also, the work of [23] does not present the structure of the MQTT topics. An implementation is essential to verify the suitability for constrained devices, such as footprint, message size (to evaluate fragmentation), and energy consumption. If a security mechanism requires an amount of energy that does not fit the constrained device's requirements, the solution is not an option.
Diro et al. [24] propose a security scheme in the interconnection of the IoT-device with the MQTT Broker. The proposed security mechanism requires a trusted and customized MQTT Broker to deliver modified MQTT messages between publishers and subscribers, breaking end-to-end security. The message is only secure because the MQTT Broker is responsible for ensuring the MQTT header's new security proposed fields. The proposed security mechanism contains only the proposal's schematics, and the authors do not implement the solution in real IoT devices.

VII. CONCLUSION
In this article, we presented and evaluated our LWPubSub system within a cloud-connected IoT architecture. Our system provides standardization and end-to-end secure messages between constrained wireless IoT devices and the cloud platform through any MQTT Broker.
Our LWPubSub system includes standardization to the MQTT messages, meeting the requirements of IoT architectures. Besides, the MQTT topic generated by the LWPubSub system guarantees the unique device identification on its domain and site. In the MQTT payload, we guarantee endto-end security and the unique identification of each device's sensors. We include all these metadata (along with the data) in our LWPubSub system's message. The demonstrated LWPubSub system standardization provides the lowest energy consumption among the main related works, the smallest footprint, and the smallest MQTT topic and payload size, as shown in our results.
The strategic decision of using constrained wireless IoT devices is critical for the success of the IoT architecture -given the ubiquity and proliferation of these devices and low energy consumption. Also, some sensors (temperature, humidity, led, light) are natively present in CWIoT, such as Sensortag.
Furthermore, compared to Raspberry Pi, CWIoTs are cheaper, restricted in size to be coupled with other equipment, and (even being constrained) can perform the same sensing and actuation functions in IoT scenarios using MQTT. We use the Raspberry Pi as a more robust device: the gateway, not the IoT end-device. a) Limitations and Future works: The confidentiality applied to the MQTT payload ensures that an intermediary like the MQTT Broker cannot read the message, ensuring endto-end security. However, one of the limitations of this paper is not to explore the use of authentication and integrity and the energy consumption needed by it. It should be addressed in future works, for example, using AES CCM 8.
Although the results obtained prove the low energy consumption and message size without resorting to fragmentation, the LWPubSub system only sends one measurement from one sensor at a time. An extension to this work could be evaluating the message size to verify if sending measurements from more than one sensor in the same message requires fragmentation and what energy consumption and other implications this may cause. The authenticity and integrity of the MQTT payload are important features for future works. Additionally, other encryption models can take place when considering security, using key derivation functions and features to deliver the static keys, which also require analysis of the message size and energy consumption. Regarding total energy consumption, future work may include evaluating another TSCH Schedule.