Lightweight Frame Format for Interoperability in Wireless Sensor Networks of IoT-Based Smart Systems

Abstract

Applications of smart cities, smart buildings, smart agriculture systems, smart grids, and other smart systems benefit from Internet of Things (IoT) protocols, networks, and architecture. Wireless Sensor Networks (WSNs) in smart systems that employ IoT use wireless communication technologies between sensors in the Things layer and the Fog layer hub. Such wireless protocols and networks include WiFi, Bluetooth, and Zigbee, among others. However, the payload formats of these protocols are heterogeneous, and thus, they lack a unified frame format that ensures interoperability. In this paper, a lightweight, interoperable frame format for low-rate, small-size Wireless Sensor Networks (WSNs) in IoT-based systems is designed, implemented, and tested. The practicality of this system is underscored by the development of a gateway that transfers collected data from sensors that use the unified frame to online servers via message queuing and telemetry transport (MQTT) secured with transport layer security (TLS), ensuring interoperability using the JavaScript Object Notation (JSON) format. The proposed frame is tested using market-available technologies such as Bluetooth and Zigbee, and then applied to smart home applications. The smart home scenario is chosen because it encompasses various smart subsystems, such as healthcare monitoring systems, energy monitoring systems, and entertainment systems, among others. The proposed system offers several advantages, including a low-cost architecture, ease of setup, improved interoperability, high flexibility, and a lightweight frame that can be applied to other wireless-based smart systems and applications.

1. Introduction

A system becomes smart when information and communication technologies (ICTs) are applied to that system’s control and monitoring components. Hardware components can be equipped with software components that add smartness to the system. Smart systems include, but are not limited to, smart agriculture systems [1], smart cities [2], smart grids [3], and smart homes [4,5,6]. In particular, smart homes are of high interest because they include subsystems such as smart lighting systems [7], smart TV systems [8], smart heating systems [9], and smart alarm systems [10]. Therefore, this paper chooses the smart home as a platform to develop and test the proposed frame format. However, the proposed frame also applies to other IoT-based smart systems.

Smart systems’ components are equipped with control parts through actuators and monitoring parts through sensors. Smart sensors and actuators are equipped with hardware components, typically a microcontroller-based platform such as the Arduino [11], with software to transfer measurements from sensors and commands to actuators. Wireless communication technology is required to transfer commands from a hub to actuators and measurements from sensors to the hub. Wireless technologies include Bluetooth [12], Bluetooth Low Energy (BLE) [12], Zigbee [13], ZWave [14], Thread [15], long-range (LoRa) communications [16], and WiFi [17], among others. In general, sensors that use wireless technologies to transfer measurement data are called Wireless Sensor Networks (WSNs). If a connection to the Internet is required, a gateway is provided to the central hub, and hence an Internet connection is needed. When connected with the Internet, smart actuators and sensors in the smart system constitute an Internet of Things (IoT) [18,19] system. Applications of smart homes, smart cities, and smart grids that use WSNs benefit from the IoT architecture, namely, networks and protocols. The selection of a specific protocol depends on the field of application, timing requirements, and transmission rate [20]. Bluetooth, BLE, LoRa, and Zigbee, among other protocols, transfer measurement data from sensors to the central hub. However, the payload formats of these protocols are heterogeneous, and thus they lack a unified frame format that ensures interoperability. In this paper, an interoperable and lightweight frame format for small-size, low-rate WSNs of IoT-based systems is designed, implemented, and tested.

Moreover, a gateway is developed in the hub and tested to transfer received data from sensors over the Internet to online cloud servers. Telecommunication protocols available for the transfer of data from the gateway to online servers include, but are not limited to, hypertext transfer protocol (HTTP) [21], message queuing and telemetry transport (MQTT) [22], advanced message queuing protocol (AMQP) [23], and extensible messaging and presence protocol (XMPP) [24].

XMPP is an application-layer protocol suitable for building an Internet of Multimedia (IoMM) system [25,26]. The protocol has found its way into many applications, primarily in instant messaging, social media, and gaming. However, XMPP is an XML-based protocol that consumes significant overhead.

The AMQP is an application-layer communication protocol for passing business messages, developed by JPMorgan Chase [27] specifically for transactions between financial institutions and then proposed for IoT applications [28]. The protocol was standardized by OASIS [29] in 2012 and by the ISO and IEC in 2014 [30]. The protocol is the choice for building middleware for queuing-based IoT applications.

The MQTT protocol is a subscribe-and-publish, application-layer communications protocol suitable for building middleware for broker-based IoT applications [31]. The MQTT philosophy requires the use of a centralized server (broker). Things (sensors, actuators, etc.) are clients that use the publish-subscribe communication model to exchange data through the server (broker). Multiparty, intercommunicating publishers and subscribers require MQTT.

Comparisons between these protocols and others have been conducted in previous studies [32,33,34,35,36,37,38]. Latency and packet loss rate were addressed in [33,34,35], throughput and jitter in [36], and scalability in [37]. The authors of [38] conducted a comparative evaluation of AMQP, MQTT, and HTTP using real-time public smart city data, and found that HTTP had higher latency and higher CPU usage than MQTT and AMQP. These studies proposed MQTT for the smart home system. In [38], the authors found that MQTT is the most effective protocol regarding scalability, latency, and efficiency; therefore, it is chosen in this paper for the communication between the gateway in the Fog layer and the online server in the Cloud layer.

This paper proposes specific techniques to address interoperability issues in small-scale, low-rate WSNs used in IoT systems and applications. First, it proposes a unified frame format (a lightweight unified payload format) for wireless protocols in the Things layer and a gateway to format its data using JavaScript Object Notation (JSON) [39]. Second, the gateway of the Fog layer then transfers this information using MQTT. A smart home platform is developed as an example of a smart system, which is then tested for interoperability.

To enable data visualization directly in web browsers, MQTT delivers sensor data over WebSockets [40] by encapsulating MQTT packets within WebSocket frames. This mechanism is also employed in this paper for data visualization on the online server of the Cloud layer.

Security is a critical issue in IoT systems. Currently, the developed frame relies on the underlying wireless technology (e.g., Bluetooth and Zigbee) for security mechanisms. Future work will address security mechanisms such as authentication and encryption. However, transport layer security (TLS) has been applied to MQTT communications.

The developed environment is compared with the existing solutions discussed in the Literature Review section, and shows that this paper proposes a solution at a different level of abstraction. This comparison, together with the conducted tests, shows that the environment is low-cost, efficient, interoperable, easy to set up, and flexible for low-rate and small-scale WSNs. Moreover, it can be employed in many IoT-based smart systems, including smart homes, smart city sectors, and monitoring environments. However, time-critical applications that require real-time constraints may experience high latencies.

The remainder of the paper is organized as follows: Section 2 presents a review of the related literature; Section 3 presents the system design and the proposed frame format; Section 4 presents the results; Section 5 presents the discussion; and Section 6 concludes the paper.

2. Literature Review

The Things layer of the IoT system employs WSNs as an infrastructure, including wireless networks and protocols. Smart home applications, smart wearable devices, smart healthcare monitoring systems, and other IoT-based smart systems employ diverse wireless telecommunication technologies such as Bluetooth, BLE, Zigbee, and Narrowband Internet of Things (NB-IoT) [41]. These wireless technologies represent the wireless communication infrastructure between the Things layer, where sensors and actuators are installed, and the Fog layer, where a hub and gateway are installed. The following paragraphs review some previous research papers that used wireless networks and protocols to collect data from sensors with heterogeneous payload formats and no unified frame format that ensures interoperability between the Things layer and the Fog layer. However, interoperability is addressed in these studies using various techniques, mainly in the Fog layer, via market-available platforms, while leaving the Things layer that utilizes various telecommunication protocols with no unified frame in the application layer (a lightweight unified payload format) that solves interoperability.

The study in [42] presents a framework that integrates ontology-driven data standardization with FedProx to address interoperability, scalability, and real-time processing challenges in decentralized IoT-edge environments. By leveraging the unified ontology SAREF4IoT, the framework ensures semantic consistency across heterogeneous IoT devices. Additionally, FedProx effectively addresses issues arising from non-IID (Independent and Identically Distributed) data and resource constraints, outperforming FedAvg by achieving 89.4% accuracy, faster convergence, and a 30% reduction in communication costs through gradient compression. The framework also demonstrates a 95% success rate in ontology alignment, enabling the seamless integration of diverse datasets, such as traffic and parking data. Tested on real-world datasets, including CityPulse, the framework exhibits strong scalability, adaptability to new devices, and significant potential for applications in smart city initiatives and environmental and traffic monitoring.

The authors of [43] discussed the increasing complexity of Distribution Management Systems (DMSs) that arises from the integration of distributed energy resources, electric vehicle (EV) charging stations, and IoT sensors. This complexity leads to higher demands for interoperability in smart grids, and places pressure on topology processing (TP) performance. The authors propose a framework based on a Common Information Model (CIM)-oriented Ontology Database (ODB), which replaces traditional relational databases. This shift is intended to eliminate transformation overhead and enhance TP efficiency. By utilizing RDF triple stores and graph databases, their approach demonstrated TP speeds that are myriad times faster within Korea’s DMS. This speed improvement also enhances scalability, adaptability, interoperability, and compliance with IEC CIM standards for smart power distribution systems.

The authors of [44] addressed the challenge of interoperability in precision agriculture, where IoT sensors generate heterogeneous data formats that complicate analysis. The authors review IoT standards and protocols and assess key requirements such as lightweight data flow, geolocation, and scalability. They decided to adopt SensorThings due to its RESTful design, JSON encoding, and built-in geolocation features. The authors propose an architecture that employs connector devices to translate diverse sensor outputs into a standardized format. This approach facilitates integration across different protocols like MQTT and LoRaWAN. Case studies using real sensors demonstrated improvements in real-time monitoring, cost reduction, and enhanced decision-making, all while maintaining flexibility and low implementation costs.

Reference [45] introduces a smart city platform that integrates IoT, digital twins, and virtual reality to create an interactive virtual replica of urban infrastructure using IoT devices. This integration facilitates cross-domain interoperability, as well as real-time monitoring, control, and urban management. Developed at IoTMADLab in Madrid, the platform utilizes open protocols and frameworks such as HomeAssistant, MQTT, REST APIs, and the uCIFI data model to standardize data exchange across services including street lighting, parking, waste management, and watering. The system enhances urban management, decision-making, and citizen engagement.

Reference [46] introduces RIVMD-BO, a Blockchain Oracle mechanism specifically developed for IoT-enabled smart healthcare systems. This mechanism effectively addresses challenges related to data integrity, security, privacy, and interoperability. Employing cuckoo filter technology reduces computational complexity and enables real-time verification of medical data such as electronic medical records and remote monitoring data across heterogeneous systems. The approach ensures data authenticity while achieving significant optimizations. Additionally, it features dynamic trust scoring. Experiments and security analyses have shown that this mechanism is scalable, efficient, and resilient against potential attacks. Future improvements will aim to enhance interoperability and privacy.

The article in [47] introduces NextGenGW, a scalable software-based gateway architecture designed to tackle the interoperability challenges of the Industrial IoT (IIoT) across heterogeneous devices and protocols. By utilizing the IETF’s Semantic Data Format (SDF), it effectively bridges both syntactic and semantic gaps, allowing for meaningful data alignment and unified communication. Its modular, software-defined design enhances scalability and adaptability while minimizing reliance on proprietary hardware, making it ideal for IIoT and smart factory automation. In addition to simplifying deployments, NextGenGW establishes a foundation for semi-autonomous provisioning and lifecycle management of IoT infrastructure. This advancement supports the integration of diverse systems in Industry 4.0 and far-edge environments.

The researchers of the FED4IoT project [48] at Kanazawa Institute of Technology developed VirIoT, which is a virtualization-based platform designed to enable semantic interoperability across heterogeneous IoT systems for smart city applications. A key component to this initiative is the Root Data Domain Gateway (RDG), which standardizes IoT data formats, performs protocol translation, and routes information to cloud platforms such as FIWARE for unified access. The RDG utilizes ontology-based models and incorporates security mechanisms while providing essential functions such as registration, authentication, and query handling. This helps bridge fragmented IoT domains, enhance scalability, and simplify integration complexity. As a proof of concept, the researchers implemented a wildlife monitoring system using LoRaWAN-enabled devices to gather environmental data. The RDG transformed this data and uploaded it to FIWARE. This approach illustrates how IoT virtualization can support large-scale, interoperable, and data-driven smart city ecosystems through collaboration between the EU and Japan.

Reference [49] addresses the challenge of achieving semantic interoperability among heterogeneous IoT platforms. It proposes and validates a mechanism within the SEMIoTICS framework that facilitates seamless, bidirectional data exchange. The approach involves mapping various platform data models (such as FIWARE, MindSphere, and openHAB) to W3C WoT standards and iotschema.org. That is accomplished through a multi-phase process that includes flow design in Node-RED, requirement specification, semantic verification using Drools-based rules, validation with Thing Descriptions, and adaptation through dynamically generated adaptor nodes. A proof-of-concept is presented, demonstrating real-time communication between a FIWARE sensor and a SEMIoTICS thermostat, effectively resolving semantic mismatches as they occur. Performance evaluation in a Proxmox-based environment shows that the system is scalable and responsive. Furthermore, there is potential to extend interoperability across additional platforms, thereby enhancing IoT integration, scalability, and standardization.

The authors of the article in [50] introduce the MQTT-CoAP Interconnector (MCI), a lightweight application-layer solution designed for the IoT that bridges MQTT’s publish-and-subscribe model with CoAP’s request-and-response model. MCI is tailored for heterogeneous, resource-constrained devices and features a minimal 2-byte header to parse and convert messages. This design allows for seamless data exchange between local MQTT networks and remote CoAP systems with reduced overhead. When compared to open-source alternatives such as Kura, Eclipse IoT, and Ponte, MCI demonstrates higher throughput, lower latency, and minimal packet loss. The study concludes that MCI effectively addresses IoT interoperability challenges and outperforms alternatives in terms of efficiency and scalability.

The research article in [51] examines whether existing standards alone can achieve seamless interoperability in the Web of Things (WoT), especially given the fragmented nature of the IoT. While initiatives such as the W3C WoT Working Group, IEEE, and HL7-FHIR focus on technical and syntactic layers, achieving full interoperability, which includes semantic and organizational aspects, remains a challenge. The study draws insights from successful standardization in fields such as B2B e-business and healthcare IoT, concluding that while standards are essential, they are insufficient without widespread adoption, semantic alignment, and collaboration across different domains. Ongoing challenges include security, privacy, scalability, ethical considerations, and the need for dynamic reconfiguration. The article advocates for a comprehensive approach that combines standards with supportive tools, high-level architectures, and performance-aware solutions to create robust, scalable, and ethically sound WoT ecosystems.

The authors of [52] designed a cognitive IoT gateway framework to overcome ongoing interoperability challenges caused by heterogeneous devices, networks, and protocols. The proposed framework integrates all aspects of interoperability through a cognitive dynamic system inspired by human perception, memory, and attention. A key feature of the framework is a deterministic finite automaton-based multi-protocol parser that supports CoAP, MQTT, and AMQPs. It is further enhanced by standardized data formats such as SenML and semantic annotations that enable cross-domain data accessibility. The gateway facilitates adaptive, secure, and scalable integration of IoT systems. Future work will focus on formal modeling and expanding protocol support.

The article in [53] explores the challenges of achieving interoperability in the fragmented IoT ecosystem. The authors proposed the concept of “Rational Interoperability,” a pragmatic framework that focuses on achieving “good-enough” interoperability that is tailored to specific contexts, rather than striving for perfect universal compatibility. This approach emphasizes the importance of shared data models, semantic descriptions, standardized metadata, and architectural innovations such as Edge and Fog computing. These elements collectively facilitate meaningful data interpretation and decentralized processing. The framework promotes flexibility, minimizes vendor lock-in, and advances the maturity of IoT. Ultimately, it aims to create a more data-centric, scalable, and cooperative ecosystem.

The authors of [54] presents the Smart System for Device Interoperability in IoT (SI2oT), a middleware solution aimed at addressing interoperability challenges in heterogeneous IoT environments. SI2oT ensures network syntactic and semantic interoperability by supporting various communication protocols such as WiFi, Bluetooth, ZigBee, and ANT+. It uses lightweight JSON for data formatting and employs ontology-based semantic handling. The architecture of SI2oT consists of five components: Sender, Event Handler, Naive Bayesian Classifier, Ontology Handler, and Receiver. These components work together to manage device discovery, protocol conversion, semantic enrichment, and secure communication. A case study in health and fitness illustrates SI2oT’s ability to connect an ANT+ heart rate monitor with a Bluetooth smartphone, showcasing its lightweight, extensible, and domain-independent capabilities.

However, there is no unified frame format (lightweight unified payload format) in the application layer of the heterogeneous wireless technologies that ensures interoperability between the Things layer and the Fog layer. Therefore, in this article, a lightweight and interoperable frame format is designed and tested for the protocols of small-size and low-rate WSNs of IoT-based smart systems. A gateway is also developed to transfer collected data to online servers via the MQTT while ensuring interoperability between the Fog layer and the Cloud layer via the JSON format. The developed system is applied to smart home applications, but can be applied to other smart systems.

3. Materials and Methods

This section introduces the materials and methods employed for testing and verifying the environment. The first subsection explains the frame format suggested for the wireless communication networks and protocols, such as WiFi, Bluetooth, and Zigbee. The second subsection presents a scenario to test and verify the proposed frame. The scenario is built using the three-layer architecture of the IoT system.

3.1. The Proposed Frame Format

As mentioned in Section 1, smart systems include smart grids, smart cities, smart buildings, and smart agriculture systems, among others. However, the smart home is of particular interest in this study because it comprises many subsystems and applications. Such systems include, but are not limited to, smart security systems, smart entertainment systems, smart healthcare monitoring systems, and smart lighting systems. However, various wireless telecommunication networks are used for each subsystem, such as Zigbee for lighting control, Bluetooth for entertainment and ambient monitoring, and WiFi for healthcare monitoring. However, the payload formats of these protocols are heterogeneous; no unified frame format exists for these networks, and interoperability is unfulfilled.

The proposed frame format for wireless networks and protocols is based on the HDLC (High-Level Data Link Control) frame format, a datalink layer protocol developed in the 1970s [55]. The HDLC protocol serves as the basis for the frame structure of many telecommunication protocols developed for various applications, such as the frame of the Modbus/TCP application layer [56] and the datalink frames of Bluetooth, BLE, WiFi, and Zigbee.

Devices at the Things layer, such as actuators, sensors, LEDs, and switches, have different hardware and software components and controllers because different manufacturers develop them. Therefore, interoperability among smart systems, including smart home subsystems, can be achieved using a single unified frame at the application layer of wireless networks, such as Zigbee, Bluetooth, and BLE, as shown in Figure 1. This frame introduces a lightweight payload format that ensures interoperability in small-scale, low-rate WSNs for smart systems.

The suggested frame, shown in Figure 1, is a general-purpose frame structure applicable to the application layer of any WSN of smart systems. The original HDLC frame consists of three blocks: the header, the body, and the trailer. However, this application-layer frame does not require a trailer, which is required for the datalink-layer frame. In fact, the datalink layer of the underlying wireless network (e.g., BLE and Zigbee) has a trailer that contains an error-checking code, namely CRC.

The header consists of five fields and represents the control block. The first field of the header is the Starting Frame Delimiter (SFD), which consists of a single byte with the value 01011010 in binary or 5A in hexadecimal. However, the original SFD of the HDLC frame is 01111110 (0x7E); the SFD of IEC 60870-5-104 [57] is 0x68, 0xA7 for Zigbee, and 0xAB for Ethernet. Therefore, this frame is assigned an SFD of 0x5A, which is different and far from these standards. The second field of the header is the sequence, which can be a counter that works as a frame identifier for both the transmitter and the receiver. The third field represents the destination address and occupies one byte, allowing up to 256 destination addresses, which is sufficient for small-scale WSNs. The fourth field is the source identifier, which is a single byte, allowing up to 256 modules to be connected to a single system. Each module can, theoretically, handle up to 256 sensors. This large number of sensors (minimum: 256 modules × 25 sensors = 6400 sensors) at the source does not reflect the WSN size, but rather the modularity of WSNs that use this frame. Moreover, the maximum payload of the developed frame depends on the underlying wireless technology (e.g., Zigbee is around 100 bytes and BLE is around 244 bytes).

The fifth field is the length, which represents the total number of bytes of the body. They can handle up to 256 bytes, a maximum of 84 Things per module if each Thing handles 3 bytes, or a maximum of 42 Things if each handles 6 bytes. Each Thing field can handle a minimum of three bytes, which comprise one byte for the Thing identifier, one byte for the datatype, and one byte for the Thing value. However, each Thing field can handle a maximum of ten bytes, which include one byte for the Thing identifier, one byte for the datatype, and eight bytes for the Thing value, which results in minimum 25 Things per module.

The body consists of zero or n Things, each capable of handling a minimum of 3 bytes and a maximum of 10 bytes, depending on the datatype used by the Things layer device. The following subsection provides more information about the Things and their datatypes.

The application frame relies on the underlying wireless technology (e.g., BLE and Zigbee) to verify whether the frame is correct or contains errors, since these technologies include CRC fields. Moreover, the receiver must check the frame sequence number (counters) to maintain synchronization between the transmitters’ and receivers’ counters. More details are given in the Discussion Section, Section 5.3.

3.2. Frame Payload

The frame payload (body) is limited by the header’s length field, which is 1 byte. This means that the maximum payload is 256 bytes. Each Thing field is variable and depends on the datatype the sensor reads and produces. The Thing field holds a minimum of 3 bytes and a maximum of 10 bytes. In addition to the Thing value, which occupies 1 to 4 bytes, each Thing has an identifier byte and a datatype byte.

The frame’s payload size depends on the underlying wireless technology. For example, the maximum number of bytes in a single, non-fragmented Zigbee application payload is typically 80–100, depending on security settings and network overhead. For BLE, the maximum application data payload size is 244 bytes when the data length extension (DLE) feature is enabled.

A total of nine datatypes are suggested for the frame proposed in this paper: float32, which uses the IEEE 754 short floating-point format; int16, which uses the 16-bit integer for signed quantities and measurements; uint16, which uses the 16-bit integer for unsigned quantities and measurements; int32, which uses the 32-bit integer for signed quantities and measurements; uint32, which uses the 32-bit unsigned integer; int64, which uses the 64-bit integer for signed quantities and measurements; uint64, which uses the 64-bit integer for signed quantities and measurements; and byte, which uses one-byte ASCII characters and array of bit representation of switches, LEDs, and other logic values. These datatypes are presented in

Table 1. Datatypes of the suggested frame.

Datatype	Symbol	Hex Representation	Number of Bytes	Use Examples
Float	float32		4	Temperature
		41		Ampere
				Voltage
16-bit integer	int16	42	2	Signed quantities
16-bit unsigned integer	uint16	43	2	Motion
				Flame
				Gas
				Light
32-bit integer	int32	44	4	Counters
				Signed quantities
32-bit unsigned integer	uint32	45	4	Counters
				Unsigned quantities
64-bit integer	int64	46	8	Counters
				Signed quantities
64-bit unsigned integer	uint64	47	8	Counters
				Unsigned quantities
8-bit unsigned byte	Byte	48	1	LEDs
				Switches
				Array of Booleans
ASCII character	Byte	49	1	ASCII alphanumeric character

below, along with their hexadecimal representations and typical uses.

Typical uses of float32 are measurements from temperature, voltage, and current devices. Such measurements are formatted in IEEE 754 [58]. Signed quantities and counters may use int32, which occupies 4 bytes. Flame, gas, motion, and light sensors, among others, produce unsigned measurement values ranging from 0 to 1023. These values require at least 2 bytes and an unsigned datatype. The uint16 datatype is suitable for this type of measurement. The byte datatype can represent an array of Boolean values (switches and LEDs), as well as ASCII alphanumeric characters.

These datatypes can hold most exchanged values, mainly measurements and control values, communicated between the components of the Thing and Fog layers. Since the Thing value field is 8 bytes long, additional datatypes can be added without redesign.

The order of bytes in the frame is big-endian; therefore, the transmission of bytes starts with the most significant byte first in a multi-byte datatype. In general, most Arduino variants are little-endian, and thus must consider the byte order of multi-byte datatypes (e.g., float32, int32, uint64).

Floating-point numbers are represented in IEEE 754, Short Floating Point (SFP32), which is widely adopted for storing and exchanging floating-point numbers. It offers high performance and compact storage at the cost of limited precision, which is around seven decimal digits, and sensitivity to rounding. The float32 version is precise enough for most applications, but accuracy depends on the algorithm design [58].

3.3. System Design

A smart home can be defined as a house where a set of sensors and actuators in the Things layer exchange data with a centralized controlling device (hub) in the Fog layer, using wireless technologies to control, monitor, and manage residential appliances. As a result, the system can provide residents with entertainment and healthcare resources and improve their living quality securely while maintaining low-cost technology solutions. Based on this definition, a smart home may contain many applications and subsystems. Therefore, the following Section 3.3.1, presents the basic three-layer architecture of the IoT system, and Section 3.3.2 presents the scenario under which the proposed smart home system is tested and verified.

3.3.1. Three-Layer Architecture

The IoT system in this paper is designed based on the three-layer IoT architecture proposed in [59], comprising a Things layer, a Fog layer, and a Cloud layer. However, an interface layer is added to the architecture in this paperwork, which handles the graphical user interface (GUI) and user interactions.

The Things layer comprises sensors, actuators, and other devices. It involves collecting raw data from devices via networks such as Bluetooth, WiFi, BLE, and Zigbee. In this paper, the Things layer is the focus, where a unified frame format is proposed for the heterogeneous application-layer formats of these wireless technologies to ensure interoperability for the Things of this layer.

The Cloud layer is responsible for performing all the intelligence, analysis, and management on received insensitive data, and the results are stored on online servers. This layer enables online access and management of the stored data. Therefore, the GUI is added in this layer to handle user interactions.

The Fog layer includes a hub and gateway, bringing data processing and storage closer to the Things layer to speed up analysis and decision-making. Here, a gateway is developed based on IoT protocols to transfer the collected data to the Cloud layer.

3.3.2. Practical Scenario

As shown in Figure 2, the Arduino module is used in the Things layer to collect measurements from sensors and is equipped with software that formats the measurements using the application frame developed in the previous section.

The system utilizes two modules to group sensors, each of which employs three sensors. The first module employs flame, gas, and temperature sensors to detect fire alarms or abnormal measurement values. Module II uses light, sound, and motion sensors to detect theft alarms or abnormal measurement values in the specified environment.

The hub consists of a C# program. The software receives the signal from the receiver’s hardware and extracts the data from the application frame. The gateway receives the extracted frame payload, reformats it into JSON, and then transfers the JSON information over MQTT to online servers. In fact, HTTP is another IoT protocol that can be used as an alternative to MQTT. Section 4.1 provides more information about the application frame and the gateway operation.

4. Results

This section presents the results obtained from the environment developed in the previous section. Section 4.1 introduces the gateway and its functionality. Section 4.2 introduces latency tests. Section 4.3 tests the developed application frame over selected market-available and existing wireless technologies.

4.1. The Gatewy

As mentioned above, several protocols can be used to transfer the JSON string to the online server, including HTTP and MQTT. HTTP has various methods, including GET to retrieve web documents from the server and POST to send data to the server. However, the MQTT was chosen based on the comparison made in the Introduction Section.

As an illustrative example, the gateway receives the application frame using the C# software program, shown in Figure 3 below. The frame consists of two blocks: a header and a body. The header consists of five fields: the start (5A), sequence (0034), destination identifier (C1), source identifier (B0), and frame length (0E). The body consists of three Things (sensors), and each sensor has three fields: the Thing identifier, the datatype, and the thing value. The first thing (Thing 1), which is a gas sensor, has an identifier of 162 (A2), a datatype of 16-bit unsigned integer (43), and a value of 99 (0063). The second thing (Thing 2), which is a flame sensor, has an identifier of 163 (A3), a datatype of 16-bit unsigned integer (43), and a value of 65 (0041). The third thing (Thing 3), which is a temperature sensor, has an identifier of 164 (A4), a datatype of 32-bit IEEE SFP (41), and a value of 28.31 (41E27AE1).

Second, the gateway retrieves the binary data, extracts the value of each Thing, reformats the entire message into JSON, and then transfers the message over MQTT to an online server.

The gateway algorithm converts a lightweight, byte-oriented frame to a JSON string. This involves frame translation and serialization. The process follows several steps specific to the original frame: data acquisition, frame parsing and interpretation, data structuring, JSON serialization, and data transmission over MQTT. These steps are illustrated in Figure 4.

First, during data acquisition, the gateway receives a raw byte stream from the receiving device and stores the stream in an array of bytes sequentially, which is memory-efficient for ordered data. This stream is formatted according to a predefined, compact, byte-oriented frame format.

During the protocol parsing and interpretation step, the core of the algorithm first parses the source frame format as a byte stream. Next, the gateway interprets byte sequences as predefined datatypes, such as integer values, floating-point values, Boolean values, and status codes. This interpretation depends on predefined lengths, identifiers, and datatypes.

During data structuring, parsed data elements are mapped to a structured model in the gateway’s memory. The gateway’s standard library HiveMQTT in C# then serializes the C# objects to a JSON string using the System.Text.Json serializer, which offers generally high performance.

The resulting JSON string is sent over MQTT to the destination server, which is a free MQTT test server from HiveMQ.

Figure 5 illustrates the JSON message from the previous application frame, as shown in Figure 3, by following the previous steps.

The developed application-layer frame size of the smart system is 20 bytes; however, the JSON message size is 148 bytes without whitespaces. The gateway uses MQTT over TCP/IP/Ethernet, which adds additional headers from each protocol. The minimum headers of TCP, IP, Ethernet, and the MQTT are 20 bytes, 20 bytes, 14 bytes, and 2 bytes, respectively. In total, 56 bytes are required for headers, in addition to the JSON message size, increasing energy consumption, network traffic, and round-trip latency.

4.2. Latency Tests

Most round-trip time (RTT) values of the underlying wireless technologies were less than 70 ms. According to [60] and Silicon Labs [61], the manufacturers of these technology boards, these values are typical with security off and non-mesh networks. Most latency occurs during processing in the gateway, during transmission to and from the online server, and during processing in the server. Therefore, several tests were conducted with TLS-enabled MQTT and without TLS. The test results are shown in Figure 6. The tests were conducted on a public server, broker.hivemq.com, a public broker from HiveMQ dedicated to public testing, with a browser-based dashboard via the WebSocket protocol. Since it is a free public broker, it sometimes experiences periods of high traffic and heavy loads. Therefore, latencies increase, and packet loss percentage increases. To avoid packet loss during successive PUBLISH messages, measurements show that the addition of 100 ms delays between successive publishing solves the problem.

For each case, several tests were conducted during different times of the day, and the average value of each case is registered. The figure shows that TLS-based communications consume higher round-trip latency. A screenshot of the HiveMQ dashboard during one of the tests is shown in Figure 7.

These RTT values show that the developed system for the frame format is suitable for smart systems that have measurement time intervals of more than one second. Time-critical applications may suffer high latencies that are not compatible with real-time constraints.

4.3. Test of the Developed Frame over Wireless Technologies

To compare the competing protocols of smart systems, an illustrative example is constructed based on the practical scenario depicted in Figure 2. These protocols, namely BLE and Zigbee, were selected as a proof of concept. For example, to send the values of three sensors in Module I using the Zigbee wireless communication technology (Figure 2), 22 bytes are required (13 bytes for the header, 8 bytes for the payload, and 1 byte for the checksum). However, using the developed application frame over Zigbee, we need 34 bytes (13 bytes for the Zigbee header, 20 bytes for the frame, and 1 byte for the Zigbee checksum), and higher interoperability is achieved thanks to the unified frame format. With the BLE solution, approximately 22 bytes are required (9 bytes for the header and CRC, 8 bytes for the payload, and around 5 bytes for the name). However, if the developed frame is used over BLE, approximately 34 bytes are required (9 bytes for the header and CRC, 20 bytes for the frame, and about 5 bytes for the name), which achieves higher interoperability. These results are illustrated in Figure 8 below.

As illustrated in Figure 8, if the developed frame is used, the payload sizes of Zigbee and BLE are the same, at 20 bytes. These extra bytes come at a price for the unified frame that ensures interoperability. More information is given in Section 5.4.

As a result, the developed frame for the application layer of wireless communication technologies offers a unified format (payload format) for communications between the Things layer and the Fog layer. This arrangement ensures interoperability between communicating components of WSNs, specifically between the Things layer and the Fog layer of the IoT system.

5. Discussion

As shown in the literature review, the Things layer utilizes various wireless technologies to control and monitor IoT devices. The devices of the Things layer are heterogeneous, as are the payload frames of the wireless technologies. Therefore, a single, unified frame format based on the HDLC protocol is developed in this paper for the underlying wireless communication technology, ensuring interoperability at the Things layer.

The results from the previous section show that the developed environment is competitive. However, this section discusses these results, as well as the system’s advantages and limitations. Hence, Section 5.1 introduces a comparison with systems developed in previous studies, as mentioned in the Literature Review Section. Section 5.2 compares the proposed system with the protocols used in IoT systems. Section 5.3 addresses lost frames and frame errors, and Section 5.4 examines the system’s limitations.

5.1. Comparison with Previous Studies

The level of abstraction and the nature of information represented define the type of data to be used for a specific application. byte-oriented protocols are suitable for devices, such as sensors, in the Things layer (the lowest level), where data is stored in an array of bytes and transmitted as a stream of bytes. JSON is a plain-text, human-readable format for exchanging structured data at a medium level of abstraction. Ontology data focuses on the semantics (meaning) and relationships of data within a specific domain (e.g., RDF and OWL) in the highest level of abstraction. In this paper, an optimized data frame, represented as a stream of raw bytes, is developed to store and exchange data between the Things and Fog layers. To exchange data between the Fog and Cloud layers, JSON is used over TLS-enabled MQTT. Accordingly,

Table 2. Comparison between previous studies and the current paper.

Reference	Level of Abstraction	Solution	Gateway Availability	Limitations and Shortcomings
[42]	Highest	Ontology-driven data standardization using SAREF4IoT combined with FedProx federated learning and gradient compression	Framework (architecture) operates at edge nodes, (not explicit)	Requires ontology alignment; relies on federated learning
[43]	Highest	CIM-oriented Ontology Database using RDF triple stores and graph databases for DMS topology processing	No	Focused on power distribution domain; evaluated mainly in Korea’s DMS
[44]	Medium	SensorThings-based architecture with connector devices translating heterogeneous sensor data	Connector devices act as gateways	Targets precision agriculture
[45]	High	Integrated IoT-digital twin-VR platform using open protocols and uCIFI data model	Implicit gateways via HomeAssistant and MQTT brokers	System complexity; deployment-specific
[46]	High	Blockchain Oracle (RIVMD-BO) using Cuckoo filters and dynamic trust scoring	No	Interoperability enhancements remain future work; healthcare-specific
[47]	Highest	software-defined gateway (NextGenGW) using IETF Semantic Data Format (SDF)	Yes	Depends on SDF adoption; targets IIoT
[48]	Highest	VirIoT platform with Root Data Domain Gateway (RDG) via ontology-based models	RDG	Requires FIWARE ecosystem; added virtualization overhead
[49]	Highest	SEMIoTICS mechanism mapping platforms to W3C WoT using Node-RED and semantic rules	Logical adapters	Configuration complexity; runtime semantic processing overhead
[50]	High	MQTT-CoAP Interconnector (MCI) with minimal header translation	Yes	Limited to MQTT-CoAP only; application-layer focus
[51]	Medium	Analytical study of WoT standards and interoperability gaps	No	Conceptual analysis
[52]	High	Cognitive IoT gateway with multi-protocol parser and semantic annotations	Cognitive gateway	Formal modeling still future work
[53]	High	Rational Interoperability emphasizing context-aware, “good-enough” interoperability	No	Framework; abstract guidance
[54]	Highest	SI2oT middleware with protocol support and ontology-based semantics	Middleware gateway	Naive Bayesian classifier scalability unclear; limited to small case studies
This paper	Low/medium	Interoperable, lightweight, byte-oriented frame optimized for exchanging data between the Fog layer and the Things layer, and a gateway is provided in the Fog layer to translate the byte stream into JSON text and then transmit JSON text over TLS-enabled MQTT to an online server	Yes	Suitable for small-scale and low-rate WSNs; security tests remain future work

compares the environment developed in this paper with other environments discussed in the Literature Review Section.

Other standards for IoT devices have been proposed by non-profit organizations. The World Wide Web Consortium (W3C) proposed the Web of Things (WoT), a JSON-based format for IoT protocols such as MQTT, HTTP, and CoAP. Moreover, the IETF proposed the Sensor Measurement Lists (SenML) specifications in RFC 8428 and RFC 9100, which are standards based on the JSON format and primarily designed for CoAP. Developed by the Open Geospatial Consortium (OGC), the SensorThings API is a set of specifications that provides a unified, geospatial-enabled framework for managing and integrating heterogeneous sensor systems. It uses HTTP, MQTT, and JSON to connect IoT devices and applications over the web. However, byte-oriented frames over low-rate wireless technologies are more optimized for storing and exchanging data of WSNs in the Things layer.

5.2. Comparison with IoT Protocols

This subsection compares the proposed system with IoT protocols, namely CoAP, MQTT, and an IIoT protocol that is based on binary, commonly used in industrial applications, and has proven to perform well.

The MODBUS/TCP [58] is an industry standard for communication in industrial applications that uses TCP/IP communications. The industry standard is a binary protocol that offers good performance and a type of interoperability for industrial applications. For the example mentioned above, if the Modbus/TCP protocol is used, 29 bytes are required (in query-response mode, and the function code read/write multiple registers is used), but less interoperability is obtained with this arrangement. Additionally, Modbus/TCP incurs more overhead due to the use of TCP header bytes (minimum 20 bytes), IP header bytes (minimum 20 bytes), and the WiFi frame (minimum 28 bytes, comprising 24 bytes for the header and 4 bytes for the CRC). In total, Modbus/TCP requires a minimum of 157 bytes of headers to transfer 8 bytes of data if employed in the Things layer. This comparison is illustrated in Figure 9 below.

However, if MQTT is used in the Things layer, the total number of bytes required to transfer an 8-byte payload from the three sensors is 259. The publisher requires 47 bytes beyond the TCP/IP/WiFi headers, and the subscriber consumes 68 bytes beyond the TCP/IP/WiFi headers. In total, MQTT requires 251 bytes of headers (CONNECT, SUBSCRIBE, PUBLISH, and DISCONNECT) to transfer 8 bytes of payload. These headers increase energy consumption, network traffic, and round-trip latency if MQTT is employed in the Things layer.

As a result, the MQTT and Modbus/TCP solutions are less competitive than the developed frame when used over market-available wireless technologies for communications between the Things layer and the Fog layer of low-rate, small-size WSNs that involve battery-operated Things (or sensors). According to the comparison presented in the Introduction, MQTT is a competitive IoT protocol suitable for communication between the Fog and Cloud layers. Moreover, Modbus/TCP is the industry standard for IIoT applications and is well suited for SCADA (supervisory control and data acquisition) systems.

5.3. Frame Acknowledgement

In this paper, the application frame developed for the market-available wireless networks relies on the underlying technology (e.g., Bluetooth, BLE, Zigbee) to check whether the frame is correct or contains errors. If the frame is correct, the receiver returns an acknowledgment frame to the sender. As shown in Figure 10, the acknowledgment frame is the control part of the received frame, and its length field value is equal to zero. The transmitter then knows that the frame reached the destination correctly and drops the frame’s copy from its memory.

However, if the receiver detects an error, it does not send back an acknowledgment frame to the sender, and the sender must resend the same frame after a timeout, which depends on the underlying wireless technology. Retry limits and timeouts depend on the underlying technology. For example, the typical retry limit for Zigbee is 3, with a wait of 1.6 s per retry; hence, the typical timeout is 4.8 s. However, the typical Bluetooth timeout is 6 s. If retries occur, there is a potential for frame duplication. In this case, the receiver compares the sequences (counters) of both frames and ignores the new copy.

5.4. Limitations

The system is developed to solve the interoperability issue in the Things and Fog layers. For this purpose, the frame format’s payload is designed based on Things, and each Thing field requires 2 bytes in addition to the bytes of the datatype. This interoperability comes with an additional cost as an extra header of 2 bytes is added for each Thing. This problem is illustrated in Figure 11 below.

The relationship between the number of Things and the extra bytes of the previous curve is illustrated in Equation (1):

Extra_Bytes = 2n + 6,

(1)

where n is the number of Things, and the header consumes 6 bytes.

Other limitations include the one-type source and destination fields, frame security issues, lack of support for time-critical applications, scalability limitations, and lack of support for complex datatypes.

The maximum number of sources (modules) is 256, and the maximum number of sensors (things) per source is 256, which theoretically yields 65,536 things (sensors). Moreover, the maximum number of destinations is 256. For large smart city sectors, this is insufficient as the developed frame is intended for low-rate, small-scale WSNs that use existing wireless technologies. Therefore, scalability limitation in large-scale deployments is an issue. For large smart buildings and smart cities, the modularity of the developed frame will be investigated in future studies by subdividing the smart system into modules that collect multiple Things (e.g., sensors) in clusters.

Security is a critical issue in IoT-based smart systems. Communications between the Fog and Cloud layers are conducted via MQTT. Therefore, transport layer security (TLS) is applied between the gateway and the online server. However, security mechanisms, including authentication and encryption, were not implemented for the developed frame format. Security mechanisms of the underlying wireless technologies, such as Zigbee and BLE, will also be investigated for the developed frame in future studies.

The developed frame is not compatible with existing IoT standards and protocols; therefore, a gateway is built to transmit the collected data over MQTT, a widely used protocol. Other IoT protocols, such as HTTP, can be used; however, a gateway is required.

The developed frame relies on underlying wireless technologies, such as BLE, Bluetooth, and Zigbee, as transport media, which are low-rate, standardized communication technologies. Latency tests show that the developed system may not be suitable for time-critical applications that require real-time constraints.

Complex datatypes and hierarchical data structures are not supported in the developed byte-oriented frame format. However, complex datatypes are supported in the gateway via JSON.

Therefore, the developed application frame format for WSNs is a suitable solution for smart home subsystems that require interoperability. It is also a suitable choice for low-rate data transfer in WSNs of smart systems, as these systems, including home subsystems, typically require low-volume data transfers. The developed system, including the gateway, is also a good choice for monitoring systems where measurements of more than one-second time intervals are conducted and latencies are tolerable.

6. Conclusions and Future Work

Devices at the Things layer, such as sensors, actuators, LEDs, and switches, have different hardware and software components because they are developed by different manufacturers. Wireless networks and protocols for transferring data from the Things layer to the Fog layer include low-rate protocols such as Zigbee, LoRa, and BLE. The payload formats of these wireless standards are also heterogeneous. Therefore, interoperability can be achieved for heterogeneous smart home subsystems and other smart systems by using a single-frame (payload) format in the application layer of the underlying wireless technology. Thus, a lightweight frame format for smart home applications is developed in this work. The system can be applied to other smart systems, and to a wide range of applications and devices, including healthcare devices, wearables, and sports equipment, with a few specific examples mentioned. The developed system, including the gateway in the Fog layer, is suitable for non-time-critical applications, because it experiences latencies that can reach 600 ms.

The developed application frame format for small-size WSNs is a suitable solution for smart home subsystems that require interoperability. It is also a suitable choice for low-volume data transfer in WSNs of smart systems, as these systems, including home subsystems, typically require low-volume data transfers.

The proposed system is competitive with market-available IoT protocols such as MODBUS/TCP and MQTT. Moreover, the proposed environment is low-cost, efficient, interoperable, and easy to set up, and offers is an alternative to other market-available technologies.

Security is a critical issue in IoT systems. Currently, the developed frame relies on the underlying wireless technology (e.g., BLE and Zigbee) for security mechanisms. Future work will address security mechanisms, such as authentication and encryption, for the developed frame.