Multi-Protocol IoT Gateway Architecture: A Unified Approach to Smart-Home Connectivity

Abstract

The Internet of Things (IoT) has a decentralized smart home ecosystem, as each protocol has its own gateway infrastructure needs. This study advances gateway convergence by proposing and rigorously evaluating a scalable architectural framework for future smart-home infrastructure. Specifically, this paper provides a detailed analysis of a proposed integrated multi-protocol gateway design that supports 18 of the most widely used IoT communication protocols simultaneously. It is a one-device implementation combining wireless technologies, including short-range radios (Sub-1 GHz, 2.4 GHz), LPWANs (Long Power Wide Area Networks), cellular (LTE, Long-Term Evolution), and wired (Ethernet, KNX). Using the ns-3 network simulator, this paper shows that this architecture is practical in a simulated smart-home environment with a large number of interconnected devices distributed across various zones. The results demonstrate substantial reductions in energy consumption and operational complexity, without compromising quality of service across heterogeneous communication technologies.

1. Introduction

Living in the era of Industry 4 (I4.0), many devices are now part of a specific network. These can be utilized in many ways, such as in industry or in agriculture. Despite the protocol used, all these components can be accessed from anywhere in the world because they are all connected to the internet. The IoT (Internet of Things) is now a common term used in everyday life. More and more devices are equipped with network controllers, enabling them to access and manage networks. There is a plethora of network technologies that can achieve this kind of communication. Wi-Fi, LTE (Long Term Evolution), and BLE (Bluetooth Low Energy) are the most common, used mostly on computers and smartphones. According to the application needed, many other technologies are being used. More particularly, in home automation, Zigbee, Thread, Z-Wave and KNX are the most commonly used, alongside others applied in communications. For agriculture and for distance management, LoRa, Sigfox and Mioty are used [1,2]. All of these technologies can be combined in the same home, enabling coexistence.

Inside a typical home in 2026, the most common smart devices use Wi-Fi, BLE, Zigbee, Z-Wave and Thread for wireless communication. These protocols cannot exchange data directly with each other; therefore, gateways are used. Some of them are one-device solutions (smart gateways) or part of ecosystems like Alexa [3], Samsung SmartThings [4], Apple HomeKit [5,6] or even the newly introduced Matter [7]. There are also solutions for wired devices like Ethernet and KNX, also used in home automation. These require infrastructure to be available in a building.

New trends are introducing new technologies in this area, like EnOcean, an energy-harvesting technology that reduces total consumption in a home. Other LPWAN technologies can be used for managing devices outside the geographical borders of the home [8].

To reduce the cost and complexity of the systems, users have to buy a solution for a single protocol or to support the popular ones. Despite having all of these solutions, the minimum number of gateways required to support all of these protocols is 7–10. Considering factors such as price, cable, power consumption, and maintenance, the total cost is significant.

The evolution of Moore’s Law [9,10] has surfaced solutions with System-on-Chip (SoC) radio modules, which are not only affordable but also more integrated. These can consolidate all of these radio front ends into a single universal gateway, making this solution technically and economically attractive.

This work pursues five objectives:

• Design a complete gateway architecture supporting all 18 commercially relevant IoT protocols in Layers 1 and 2;
• Derive realistic per-protocol traffic and energy profiles for a typical family household;
• Execute a 24 h ns-3 simulation and collect gateway-load, throughput, and energy time series;
• Assess protocol-coexistence risks and propose mitigation strategies;
• Minimize the use of modules according to the protocols’ characteristics.

Existing multi-radio gateway surveys and prototypes—including those reviewed in Section 2—address at most five or six protocols simultaneously and typically omit LPWAN (LoRa, Sigfox, Mioty), proprietary building-automation buses (KNX, Insteon), and single-pair Ethernet (10BASE-T1L/SPE). No published work simultaneously models 18 distinct PHY/MAC technologies within a single gateway, derives per-protocol duty-cycle-accurate energy profiles from real device datasheets, and quantifies 24 h gateway load under a documented residential usage pattern.

In what follows, related work is presented in Section 2. The architecture of the universal gateway is described in Section 3. In Section 4, the operation of the proposed system is evaluated via simulation results. A discussion is presented in Section 5. Finally, concluding remarks are drawn in Section 6.

2. Related Work

In previous research, IoT gateways were primarily focused on solutions using a single protocol or a small set of home automation technologies. In Fuqaha et al. [11] IoT-enabled technologies were surveyed, but no gateway consolidation was addressed. In Minerva et al. [12] edge computing was explored in IoT gateways, but there was no protocol convergence coexistence in the 2.4 GHz band, particularly between Wi-Fi and IEEE 802.15.4. Technologies such as ZigBee and Thread were studied in Han et al. [13], Yang et al. [14], and Natarajan et al. [15]. In Guo et al. [16] and Nagai et al. [17] coexistence was studied in the sub-1 GHz band. In Silabs [18] Bluetooth interference, among other protocols using the same radio, was explored as well. There are other works, like Polak et al. [19], where coexistence between LoRa and Wi-Fi was studied. Lastly, in Orfanos et al. [1,2,8] various characteristics of the protocols were explored, divided into ISO (International Organization for Standardization) model implementation, user interaction, technical characteristics, QoS (quality of service), security and energy consumption.

There were also approaches for protocol collaboration. Mikhaylov et al. [20] and Haxhibeqiri et al. [21] analyzed LoRa capacity and sub-gigahertz interference. Also, a controllable measurement platform was built for LoRa, Sigfox, Z-Wave and IO Home Control and demonstrated that Sigfox can degrade LoRa packet delivery by up to 20%. The work of Nolan et al. [22] performed an evaluation of LPWAN in eastern Ireland. The recent work in Garlisi et al. [23] presented a large-scale urban interference modeling of LoRaWAN and Sigfox using the SEAMCAT tool, confirming the need for careful spectrum planning when both technologies share the ISM bands. Also, in Lauridsen et al. [24] a measurement was made in the 868 MHz European ISM band, in an urban environment. This resulted in a 22–33% probability of interfering signals having a value of 105 dBm, which is directly relevant to the Sub-1 GHz module design.

There are available solutions for commercial use, like Cisco IR829 [25], MultiTech Conduit IP67 base station [26], LORIX One [27] and Meshlium [28], which support two to four protocols. Also, the commercial SoC front, Samsung’s ARTIK platform [29], represented an early attempt at multi-radio integration, combining Wi-Fi, Bluetooth, ZigBee, and Thread on a single chip. However, this scope was limited to the 2.4 GHz ISM band and a narrow subset of mesh protocols, leaving Sub-1 GHz LPWAN standards (LoRa, Sigfox, Z-Wave) and building-automation buses (KNX) unaddressed. Moreover, the ARTIK ecosystem lacked the rigorous architectural convergence analysis and quantitative energy-throughput evaluation that this work provides. WisGate Edge Pro RAK7289V2 [30] is one of the most recent commercial multi-radio gateways combining LoRaWAN concentrator, LTE, Wi-Fi and Ethernet connectivity in one device. It is a low-power consumption device (8 W), but in can only support four protocols. There are also Software Defined Radio (SDR) platforms, like the USRP B200 by Ettus Research [31], offering an unlimited protocol flexibility. This is achieved through software-implemented PHY layers. However, despite its low consumption (15–25 W), it cannot achieve the real-time latency required by protocols like Z-Wave (10 ms) and KNX RF (20 ms). Also, it only supports wireless protocols. All the important features of the related works are summarized in

Table 1. Classification of prior multi-protocol IoT gateway work by category, protocol coverage, key contribution, identified gap, and relationship to the proposed architecture.

Category	Representative Works	Protocols Covered	Key Contributions	Identified Gap	Proposed Contribution
Commercial Gateways	Cisco IR829 [25] MultiTech Conduit IP67 [26] LORIX One [27] Meshlium [28]	2–5	Proven industrial reliability,   Single-chassis integration   Commercial support	Max 5 protocols   Up to 5 protocols supported   No energy model	18 protocols in one chassis   Quantifies the 9-gateway overhead this creates
Commercial Multi-Radio (current)	RAK7289 V2 [30]	4	Low power (~8 W)   Wi-Fi, Ethernet, LoRa and LTE in a single unit	Only 4 protocols supported   No protocol energy model	Matches RAK7289 power profile (~15 W)   Covering 14 more protocols
SDR-Based Approach	Ettus USRP B200 [31]	∞ (software)	Theoretically unlimited protocol flexibility via software PHY	15–25 W continuous regardless of traffic   Latency incompatible with Z-Wave (10 ms) and KNX (20 ms),   Cost scales with N radios	Hardware-module architecture meets real-time constraints,   Duty-cycled power
Research Prototypes, Protocol Studies	Samsung ARTIK [29] Nolan et al. [22] Han et al. [13] Yang et al. [14] Lauridsen et al. [24]	2–4	Protocol comparison studies (LPWAN vs. LPWAN; WiFi vs. ZigBee)   SDK-based multi-protocol hub	Studies target LPWAN comparison OR coexistence   Not unified integration,   No household energy model   Max 4 protocols in any single system	First work to integrate all 18 protocols with per-device energy for a realistic household scenario
LPWAN Integration	Mikhaylov et al. [20] Haxhibeqiri et al. [21] Garlisi et al. [23] Sanchez-Iborra et al. [32]	1–3	LoRa capacity analysis; sub-GHz interference measurement   LoRa/Sigfox RF coexistence characterization	LoRa, Sigfox, Mioty are separate systems   no duty-cycle accounting for combined LPWAN module	LPWAN TDM: three protocols share one antenna   Power reduction vs. 3 independent gateways
Coexistence Analysis	Han et al. [13] Yang et al. [14] Natarajan et al. [15] Guo et al. [16] Nagai et al. [17] Polak et al. [19]	2–3 (pairs)	Pair-wise interference characterization (Wi-Fi /ZigBee, Wi-Fi/BLE, LoRa/Sigfox, Z-Wave /EnOcean)   Mitigation techniques identified	Protocol-pair-specific analyses   No hardware architecture that mitigates risks through module isolation	Unified coexistence risk matrix covering all 18 protocols   Hardware-separated modules as structural mitigation strategy
Authors’ Prior Work	Orfanos et al. [1,2,8]	Survey	Identified multi-protocol convergence problem,   Surveyed IoT gateway trends,   defined unified L1/L2 handling as research objective	Conceptual framework only	Quantitative realization of the conceptual framework   Hardware specification   Multi-device traffic model simulation

.

Comprehensive solutions, supporting the full spectrum of short-range, medium-range and long-range protocols, have not been fully studied in academic literature. This is the gap that our approach tries to fill.

3. Description of the Universal Gateway Architecture

3.1. Hardware and Antenna-Module Design

The proposed universal gateway integrates six RF antenna modules, each independently optimized for a specific physical-layer (PHY) communication domain. These are integrated with a single ARM-based SoC board supporting a Gigabit Ethernet interface for backhaul interconnection. Each of these, according to the frequency band, modulation and range characteristics, serves multiple protocols. These modules are hardware-isolated from one another to prevent RF (Radio Frequency) interference.

Table 2. Proposed universal gateway hardware configuration.

Module	Frequency (MHz)	Protocols	Devices	Pwr (W)	Representative Chipset
Sub-1 GHz Radio	868/915	Z-Wave, EnOcean, Wi-Fi HaLow, DASH7	14	0.38	EFR32FG23 [33] TI CC1352P [34] MM6108 [35]
2.4 GHz Radio	2400	Wi-Fi, BLE, ZigBee, Thread	34	5.80	ESP32-S3 [36] nRF52840 [37]
LPWAN 1	868/915	LoRa, Sigfox, Mioty	7	0.02	SX1262 (LoRa) [38] ATA8520 [39] STM32WL55xx [40] SKY13348 [41]
LPWAN 2	Licensed	LTE-M, NB-IoT	6	0.65	Quectel BG96 [42]
Short-Range	UHF/ 3000–9000	UWB	6	0.075	DW3000 (UWB) [43]
Building Automation I/F	Mixed	KNX, Insteon	4	0.35	Siemens KNX TP1 [44] Insteon PLM [45]
Wired Interface	N/A	Ethernet, SPE	7	3.25	RTL8211F GigE PHY [46] TI DP83TD510 (SPE) [47]
SUM			78	10.525

summarizes the configuration of the proposed model. The representative chipsets were chosen due to their popularity and the low-cost development they provide.

From Table 1, the total energy consumption is estimated at 10.525 W. Additional energy savings can be achieved by employing dynamic module activation. More specifically, only those required to service traffic are enabled (powered on) at the specific time needed for the transport layer. Typically, the interfaces that remain active all the time are the 2.4 GHz radio (Wi-Fi background keep-alive, P_Wi-Fi), the Ethernet link (kept alive, P_Ethernet) and the host SoC baseband. The energy consumption of an ARM Cortex A53 (P_SoC) is measured to be 1.5 W [48]. Using the previous energy estimations, the total consumption can be calculated:

P_active = P_Wi-Fi + P_Ethernet + P_SoC = 5.8 + 3.25 + 1.5 = 10.55 W

(1)

Taking into consideration the energy gain from the Wi-Fi radio’s transmit amplifier during no traffic periods, where the energy consumption (P_Wi-Fi(idle)) is low, its draw is reduced from 5.8 W to 1.2 W [36].

Therefore, the energy would be

P_idle = P_Wi-Fi(idle) + P_Ethernet + P_SoC = 1.6 + 3.25 + 1.5 = 6.35 W

(2)

In peak load, during hours 18:00–22:00, in which it is assumed that the whole family is in the building, all of the protocols would be active. Consumptions of Wi-Fi (P_Wi-Fi), Zigbee (P_Zigbee), Z-Wave (P_Z-wave), LoRa (P_LoraWAN), Thread (P_Thread), KNX (P_KNX(IP)), Ethernet (P_Wi-Fi) and the automation server (P_{Automationserver}) will participate. Therefore, the gateway would consume the maximum amount of energy (P_Peak):

P_Peak = _PWi-Fi + P_Zigbee + P_Z-Wave + P_LoRaWAN + P_Thread + P_KNX(IP) + P_NB-IoT + P_Ethernet + P_{Automationserver} ⇒
P_Peak = 12 + 5 + 4 + 8 + 6 + 7 + 9 + 15 + 24 = 90 W

(3)

In the proposed model, all six antenna modules simultaneously work, consuming 10.63 W. Additionally, apart from PSY Layers there is also power need for the APP Layer and more particularly from the ARM SoC, which is in full processing mode. According to the data sheet, an additional 4 W of power is consumed. Therefore, the total power consumption (P_total) is

P_total = P_active + P_{SoC_APPLayer} = 10.55 W + 4 W = 14.55 W

(4)

The idle-state power of the gateway is approximately 6.35 W, rising to 15 W under peak load. This number is significantly lower than 90 W for nine independent gateways running simultaneously. The 2.4 GHz radio module draws the largest share (5.80 W) due to the high-duty-cycle Wi-Fi radios it serves.

3.2. Protocol-to-Module Mapping

All of the protocols used in the simulated scenario were grouped by three characteristics:

• Carrier frequency;
• Modulation bandwidth;
• Maximum output power.

LoRa (chirp spread spectrum), Sigfox (ultra-narrow-band), and Mioty (ETSI LPWAN) all operate in the 868/915 MHz ISM bands, having output powers below 150 mW. A solution would be for them to share the same LPWAN module. Although in this simulation this might look possible, there is a significant issue to be addressed: their incompatibility in spreading implementation. LoRa uses the chirp spread spectrum (CSS), Sigfox’s Ultra-Narrow-Band (UNB), and Mioty’s Telegram-Splitting Multi-Access (TSMA). These modulation types cannot be decoded by a single conventional radio transceiver, as CSS requires dedicated chirp-correlation hardware, UNB demands extremely narrow filtering (100 Hz bandwidth), and TSMA requires GMSK demodulation with sub-packet reassembly. To overcome this obstacle, the LPWAN module will use time-division multiplexing to serve three specialized radios: Semtech SX1262 (LoRa CSS), ATA8520 (Sigfox UNB), and STMicroelectronics STM32WL (Mioty TSMA). These will share the same RF antenna (Skyworks SKY13348) with 0.5 dB insertion loss.

Traffic analysis (as produced from the simulation results in Section 4.2) reveals that LPWAN protocols generate a small number of packets (40 per hour, 0.13% of total gateway load), comprising 21 LoRa packets from 3 devices (Weather Station: 12 pkt/h, Garden Moisture: 6 pkt/h, Mailbox Sensor: 3 pkt/h), 16 Mioty packets from 2 devices (Street Parking: 12 pkt/h, Trash Bin: 4 pkt/h), and 3 Sigfox packets from 2 devices (Propane Tank: 2 pkt/h, Septic Monitor: 1 pkt/h). This low-aggregate traffic rate allows sequential time-division reception without packet loss. The controller allocates duty cycles proportionally to observed traffic: 75% for Sigfox (highest traffic density), 15% for LoRa, and 10% for Mioty. Only the active radio consumes transmit/receive power at any given instant; unused radios remain in sleep mode (<1 μW per SX1262 datasheet) [38]. The average module power is 20 mW, calculated as the weighted sum of per-protocol power draw.

P_LPWLAN = 0.149 × LoRa_{_TX} + 0.10 × Mioty_{_TX} + 0.751 × Sigfox_{_TX}⇒
P_LPWLAN = 0.149 × 15.2 mW + 0.10 × 16.5 mW + 0.751 × 20 mW = 18.93 mW

(5)

Compared to the operation of three independent LPWAN gateways (RAK7258 LoRa ~5 W, Sigfox BS ~10 W, Mioty BS ~8 W, total ~23 W), there is a 99.913% reduction while maintaining full protocol support.

The time-division approach is feasible due to LPWAN’s inherently low duty cycle. According to EU regulations (ETSI EN 300 220) [49], LPWAN transmissions are limited to a 1% duty cycle (36 s per hour) in the 868 MHz band, with even stricter 0.1% limits in certain sub-bands. The test deployment’s LPWAN devices transmit for a cumulative 7.4 s per hour.

T_airtime = 21 LoRa packets × 56.58 ms + 16 Mioty packets × 50 ms + 3 Sigfox packets × 2 s = 0.222% aggregate duty cycle

(6)

Since the module is active for only 7.99 s/h (0.222% duty cycle) and the consuming power (P_idle) is 2 mW, its time-averaged power (P_LPWLAN(av)) would be

P_LPWLAN(av) = P_LPWLAN × T_airtime + P_idle × (1 − T_airtime)_{_TX}⇒
P_LPWLAN(av) = 18.9 mW × 0.222 + 2 mW × 99.778__TX= 2.04 mW

(7)

This result, compared to the operation of three independent LPWAN gateways, now represents a reduction of 99.991%.

The gateway can sequentially scan each protocol’s frequency range without missing packets. The controller uses a priority-based scheduling algorithm that allocates longer listening windows to LoRa (due to its spreading-factor-dependent variable airtime, ranging from 56 ms for SF7 to 1.3 s for SF12) and shorter windows to Sigfox (fixed 2 s uplink transmission). Packet arrival prediction based on device-reported schedules further optimizes the scanning order, reducing average latency from 180 ms (random scan) to 42 ms (scheduled scan). Figure 1 shows the time-division approach with a 10 s sampling window.

Wi-Fi, BLE, ZigBee, and Thread all use the 2.4 GHz band and are grouped on the 2.4 GHz radio module, which employs a software-defined PTA (Packet Traffic Arbitration) scheme consistent with IEEE 802.15.2 recommendations to coordinate access [18].

KNX (powerline + RF) and Insteon (dual-band powerline + RF) are all heterogeneous protocols. Despite that, they can be co-located in building-automation applications. Therefore, they share a dedicated interface with both RF and wired front ends.

3.3. Traffic Priority Management

The proposed gateway processes incoming frames in three stages: protocol-layer reception in each module, translation to a normalized internal message format, and routing to the cloud broker via the wire/cellular backhaul. With this architecture, the RF domain is separated from the IP domain, allowing protocol-specific processing (duty-cycle enforcement, fragmentation, and acknowledgement retry) to be handled by each module’s dedicated chipset rather than from the central SoC.

In order to prevent high-volume protocols like Wi-Fi (cameras using 7200 pkt/h) from taking use of the whole bandwidth at expense of the low-frequency critical sensors, the proposed gateway implements a 4-class priority queue:

• Safety critical (highest): This involves devices like security alarms, door locks, and smoke sensors. These have guaranteed 0 latency forwarding with no buffering.
• Real-time control: In this class HVAC and commands for lightning are handled. The maximum queuing delay is 50 ms.
• Telemetry: Devices like energy meters, temperature sensors, trackers are in this class. The maximum delay is 500 ms.
• Bulk media (lowest): This involves camera streams, NAS transfers, and TV streaming feedback. This is rate-limited to the 80%R of the available backhaul bandwidth used to protect Classes 1–3.

It should be noted that this priority scheme is not in the proposed gateway’s simulation but is a design specification. All devices in ns-3 are modeled as equal-priority flows. Validation of the QoS mechanism for the configuration of queue scheduling is a feature that will be examined in future work.

3.4. Simulation Framework

The implementation is made with the use of the ns-3 network simulator [50] with its latest version (3.46.1). For visual results, the NetAnim application was used. In this study, research works by Kunz et al. [51] and Mohamad et al. [52] were taken into consideration. The topology consists of 78 nodes: one cloud broker, one universal gateway and 70 IoT endpoints. These cover the scenario of 69 IoT household devices in a building having 19 zones and outdoor areas of a 120 m² house near Ilion, Attika, Greece. As displayed in Figure 2, these are

• Ground floor: storage room, living room, dining room, kitchen, hallway, and WC;
• Lower floor: Basement and garage;
• First floor: master bedroom, second bedroom, third bedroom (and office), and bathroom;
• Roof: attic;
• Outdoor zones: front door, back yard, garden, outdoor, driveway, and back door.

This choice was made to represent the minimum logical scenario for all of the 18 protocols to coexist. Backbone communication, between the broker and gateway, is handled via a CSMA channel at 1 Gbps with a propagation delay of 6560 ns. Each endpoint is assigned a unique IPv4 address in the 192.168.1.0/24 subnet. A block diagram of this topology is displayed in Figure 3.

All of the data exchanged utilizes UDP Echo applications over a CSMA channel in order to generate realistic model packet rate and energy behavior at the MAC/application boundary. It should be noted that the scope of this abstraction is the simulation caption per-protocol traffic volume, per-device energy consumption (P_TX × T_airtime × N_packets) and gateway aggregate load profiles. It does not model Physical Layer signal propagation, RF interference between the same radios, multipath fading or MAC Layer contention within individual protocol domains. Coexistence between protocols is studied in Section 4.8. This simplification is made in order to specify that the universal gateway uses hardware-separated antenna modules operating on distinct frequency bands or time slots, and inter-protocol RF interference is structurally mitigated by design. The simulation run time lasts for one hour, representing 24 h of real-world operation, through time compression. In this study, no specific season was taken into consideration, because in winter or summer in Attica, Greece, HVAC (Heating, Ventilation and Air Conditioning) systems are heavily used. Therefore, although they have IoT capabilities, they were not used.

Mobility is fixed, and the positions are assigned by room. An XML trace was generated for topology visualization; part of this code is displayed in Figure 4.

An important issue that must be acknowledged is that ns-3 (version 3.46.1) does not natively support LoRaWAN, Sigfox and Mioty Physical Layers. As LPWAN protocols are represented as equivalent UDP traffic bursts, each one of them is carrying the correct payload size (typically 12–15 Bytes). They are injected in the correct inter-arrival internal derived from real-world duty cycles. The consumption matches the simulated energy (P_TX × T_airtime × N_packets). Chirp spread spectrum channel coding, the LoRaWAN ADR mechanism, Sigfox 100 Hz ultra-narrowband filtering, Mioty sub-packet TSMA reassembly, the capture effect, and near-far interference were not modeled. Therefore, this simulation validates packet-rate feasibility and energy accounting for the LPWAN module but cannot substitute over-the-air protocol testing. This limitation also applies equally to Zigbee, Z-Wave, KNX and all protocols not supporting UDP frames. All of them are abstracted as flows with protocol-correct packet rates and energy parameters.

3.5. Traffic and Energy Model

Each device has a per-hour packet rate derived from its real-world duty cycle. For instance, each of the 2 Wi-Fi security cameras generates 7200 packets/hour (one every 0.5 s), while the Septic Monitor (Sigfox) sends a single packet per hour. Transmission-power values (mW) were taken from manufacturer data sheets for representative chipsets. Energy consumed per hour is calculated using protocol-specific airtime models and a three-state power model (transmit, receive, and idle) based on the methodology of Mikhaylov et al. [20] and Sanchez-Iborra et al. [32] as

E_pkt = (P_tx × T_tx) + (P_rx × T_rx) + (P_idle × T_idle)

(8)

where T_tx is the protocol-dependent airtime (e.g., Wi-Fi ≈ 100 μs, ZigBee ≈ 4 ms, LoRa SF7 ≈ 56 ms, LoRa SF12 ≈ 1.3 s), T_rx accounts for acknowledgement reception where applicable, and T_idle is the inter-packet idle time.

Total hourly energy for a device is then

E_hour = E_pkt × N_packets

(9)

For gateway modules serving multiple devices, the aggregate energy is the sum of per-device contributions plus a constant baseband processing overhead (Table 1, column ‘Pwr (W)’). This model captures the order-of-magnitude energy differences between protocols, for example, LoRa’s long airtime at low data rates versus Wi-Fi’s short bursts at high power, without requiring full PHY Layer waveform simulation. Airtime formulas for LoRa follow the LoRaWAN specification [53].

The simulation clock runs one simulated hour, during which all 24 h patterns are replayed at 24× speed via an ns-3 application scheduler.

The total packets injected across all 78 devices is 30,226. The mean gateway throughput is 8.40 packets/second.

4. Evaluation of the Universal Gateway Operation

This section presents the key quantitative outputs of the simulation performed using ns-3. All values labeled “simulated” are derived directly from the traffic and energy models defined in the simulation methodology described previously. After the simulation is completed, the screen shown in Figure 5 appears, indicating that everything ran correctly.

4.1. Device-Level Traffic and Energy

After the simulation is completed, the resulting XML file is opened in NetAnim. The results are shown in Figure 6, Figure 7, Figure 8 and Figure 9.

The devices used in the scenario are exported in a CSV file and displayed in

Table 3. Simulated hourly traffic and energy of BLE protocol.

Location	Device	Packets per Hour	Energy (mJ)	Airtime (s)	TxPower (W)	Range (m)	Data Rate	Reference Model
Living Room	Smartwatch—Dad	120	0.6768	0.000376	0.015	30	Low (Kbps)	Apple Watch Series 9 GPS [54]
	Smartwatch—Mom	120	0.6768	0.000376	0.015	30	Low (Kbps)	Samsung Galaxy Watch 6 [55]
	Smartphone—Dad	60	0.0338	0.000376	0.015	30	Low (Kbps)	Samsung Galaxy S24 [56]
	Smartphone—Mom	60	0.0338	0.000376	0.015	30	Low (Kbps)	Apple iPhone 15 [57]
Master Bedroom	Wireless Headphones	240	1.3536	0.000376	0.015	10	Low (Kbps)	Sony WH-1000XM5 [58]
Bathroom	Blood Pressure	6	0.0338	0.000376	0.015	10	Low (Kbps)	Withings BPM Connect [59]
Bedroom 2	Tablet—Kids	30	0.1692	0.000376	0.015	30	Low (Kbps)	Apple iPad 10th gen (2022) [60]

,

Table 4. Simulated hourly traffic and energy of DASH7 protocol.

Location	Device	Packets per Hour	Energy (mJ)	Airtime (s)	TxPower (W)	Range (m)	Data Rate	Reference Model
Garage	Pet Tracker	60	0.48	0.002	0.04	50	Low (Kbps)	Wizzilab DASH7 Tag Gen2 [61]
	Asset Tag Tools	30	2.400	0.002	0.04	50	Low (Kbps)	Wizzilab DASH7 Tag Gen2

,

Table 5. Simulated hourly traffic and energy of EnOcean protocol.

Location	Device	Packets per Hour	Energy (mJ)	Airtime (s)	TxPower (W)	Range (m)	Data Rate	Reference Model
Hallway	Light Switch Hall	24	0.024	0.001	0.001	30	Low (Kbps)	EnOcean PTM 215B [62]
Bedroom Office	Light Switch Bedroom	18	0.018	0.001	0.001	30	Low (Kbps)	EnOcean PTM 215B
Living Room	Window Handle Sensor	12	0.012	0.001	0.001	30	Low (Kbps)	EnOcean STM 550J [63]

,

Table 6. Simulated hourly traffic and energy of Ethernet protocol.

Location	Device	Packets per Hour	Energy (mJ)	Airtime (s)	TxPower (W)	Range (m)	Data Rate	Reference Model
Storage Room	NAS Server	600	7.2	0.000012	1	100	High (Mbps)	Synology DS923+ [64]
	Security—NVR	1200	14.4	0.000012	1	100	High (Mbps)	Synology NVR1218 [65]
	Smart Hub	600	7.2	0.000012	1	100	High (Mbps)	Home Assistant Yellow [66]
Hallway	Security Panel	180	2.16	0.000012	1	100	High (Mbps)	Honeywell Galaxy Flex3-20 alarm [67]

,

Table 7. Simulated hourly traffic and energy of Insteon protocol.

Location	Device	Packets per Hour	Energy (mJ)	Airtime (s)	TxPower (W)	Range (m)	Data Rate	Reference Model
Living Room	Dimmer	72	59.4	0.015	0.055	30	Low (Kbps)	2477D Dimmer [68]
Back Yard	Outlet	36	29.7	0.015	0.055	30	Low (Kbps)	Insteon 2634-222 Outdoor [69]

,

Table 8. Simulated hourly traffic and energy of KNX protocol.

Location	Device	Packets per Hour	Energy (mJ)	Airtime (s)	TxPower (W)	Range (m)	Data Rate	Reference Model
Living Room	Blinds	48	43.2	0.02	0.045	30	Low (Kbps)	Somfy RS100 io KNX [70]
Master Bedroom	Blinds	36	32.4	0.02	0.045	30	Low (Kbps)	Somfy RS100 io KNX

,

Table 9. Simulated hourly traffic and energy of LTE protocol.

Location	Device	Packets per Hour	Energy (mJ)	Airtime (s)	TxPower (W)	Range (m)	Data Rate	Reference Model
Living Room	Smartphone—Dad	12	39	0.005	0.65	5000	Medium (Kbps)	Samsung Galaxy S24
	Smartphone—Mom	12	39	0.005	0.65	5000	Medium (Kbps)	Apple iPhone 15
Hallway	Security Panel	6	19.5	0.005	0.65	5000	Medium (Kbps)	Honeywell Galaxy Flex3-20 alarm
Driveway	Vehicle Tracker	12	39	0.005	0.65	5000	Medium (Kbps)	Teltonika FMB920 [71]

,

Table 10. Simulated hourly traffic and energy of LoRa protocol.

Location	Device	Packets per Hour	Energy (mJ)	Airtime (s)	TxPower (W)	Range (m)	Data Rate	Reference Model
Roof	Weather Station	12	84.87	0.05658	0.125	2000	Very Low (bps)	Dragino WSC1-L [72]
Garden	Garden Moisture	6	42.435	0.05658	0.125	1500	Very Low (bps)	Dragino LSE01 LoRaWAN [73]
Street Mailbox	Mailbox Sensor	3	21.2175	0.05658	0.125	500	Very Low (bps)	Dragino-LDS02 [74]

,

Table 11. Simulated hourly traffic and energy of Mioty protocol.

Location	Device	Packets per Hour	Energy (mJ)	Airtime (s)	TxPower (W)	Range (m)	Data Rate	Reference Model
Driveway	Street Parking	12	30	0.05	0.05	2500	Very Low (bps)	Sentinum Juno ID [75]
Street Side	Trash Bin Sensor	4	10	0.05	0.05	2500	Very Low (bps)	Sentinum Apollon-Q [76]

,

Table 12. Simulated hourly traffic and energy of NB-IoT protocol.

Location	Device	Packets per Hour	Energy (mJ)	Airtime (s)	TxPower (W)	Range (m)	Data Rate	Reference Model
Garage	Smart Meter Electric	4	88	0.1	0.22	10,000	Very Low (bps)	Landis + Gyr E360 NB-IoT [77]
Basement	Smart Meter Water	2	44	0.1	0.22	10,000	Very Low (bps)	Axioma W1 NB-IoT [78]

,

Table 13. Simulated hourly traffic and energy of SPE protocol.

Location	Device	Packets per Hour	Energy (mJ)	Airtime (s)	TxPower (W)	Range (m)	Data Rate	Reference Model
Front Door	Door Intercom	480	4.608	0.000048	0.2	50	Medium (Kbps)	2N IP Verso 2.0 [79]
Hallway	HVAC Controller	48	0.4608	0.000048	0.2	100	Medium (Kbps)	ADI AD-SWIOT1L-SL [80]
Garage	Ventilation Controller	24	0.2304	0.000048	0.2	100	Medium (Kbps)	ADI AD-SWIOT1L-SL

,

Table 14. Simulated hourly traffic and energy of Sigfox protocol.

Location	Device	Packets per Hour	Energy (mJ)	Airtime (s)	TxPower (W)	Range (m)	Data Rate	Reference Model
Back Yard	Propane Tank Sensor	2	180	2	0.045	3000	Very Low (bps)	Tekelek TEK766 Sigfox [81]
Garden	Septic Monitor	1	90	2	0.045	3000	Very Low (bps)	NKE Watteco IN’O Sigfox [82]

,

Table 15. Simulated hourly traffic and energy of Thread protocol.

Location	Device	Packets per Hour	Energy (mJ)	Airtime (s)	TxPower (W)	Range (m)	Data Rate	Reference Model
Front Door	Smart Lock	120	16.128	0.0042	0.032	30	Low (Kbps)	Yale Linus L2 (Matter/Thread) [83]
Dining Room	Smart Plug	60	8.064	0.0042	0.032	30	Low (Kbps)	Eve Energy (Thread) [84]
Master Bedroom	Smart Plug	60	8.064	0.0042	0.032	30	Low (Kbps)	Eve Energy (Thread)

,

Table 16. Simulated hourly traffic and energy of UWB protocol.

Location	Device	Packets per Hour	Energy (mJ)	Airtime (s)	TxPower (W)	Range (m)	Data Rate	Reference Model
Master Bedroom	Tracker Keys	12	0.18	0.0002	0.075	10	High (Mbps)	Apple AirTag [85]
	Tag—Elderly	120	1.8	0.0002	0.075	10	High (Mbps)	Qorvo DWM3001CDK [86]
	Tracker Car Keys	60	0.9	0.0002	0.075	10	High (Mbps)	NXP SR150 UWB Tag [87]
Bedroom 2	Tracker—Child	120	1.8	0.0002	0.075	10	High (Mbps)	Qorvo DWM3001CDK
Bedroom Office	Tracker Bag	12	0.18	0.0002	0.075	10	High (Mbps)	Apple AirTag
Living Room	Smartphone—Mom	30	0.45	0.0002	0.075	10	High (Mbps)	Apple iPhone 15

,

Table 17. Simulated hourly traffic and energy of Wi-Fi HaLow protocol.

Location	Device	Packets per Hour	Energy (mJ)	Airtime (s)	TxPower (W)	Range (m)	Data Rate	Reference Model
Attic	Temp Hum	48	5.76	0.001	0.12	200	Medium (Kbps)	Deviceworx xTAG [88]
Basement	Temp Sensor	30	3.6	0.001	0.12	200	Medium (Kbps)	Deviceworx xTAG Temperature/Humidity Sensor
Back Yard	Irrigation Control	12	1.44	0.001	0.12	150	Medium (Kbps)	Deviceworx xTAG

,

Table 18. Simulated hourly traffic and energy of Wi-Fi protocol.

Location	Device	Packets per Hour	Energy (mJ)	Airtime (s)	TxPower (W)	Range (m)	Data Rate	Reference Model
Living Room	Smartphone—Dad	1800	171	0.0001	0.95	50	High (Mbps)	Samsung Galaxy S24
	Smartphone—Mom	1200	114	0.0001	0.95	50	High (Mbps)	Apple iPhone 15
	Smart TV	4800	456	0.0001	0.95	50	High (Mbps)	Samsung QE55QN85C [89]
	Smart Fridge	240	22.8	0.0001	0.95	50	High (Mbps)	Samsung RF65A967FSR/TG [90]
	Coffee Machine	48	4.56	0.0001	0.95	50	High (Mbps)	De’Longhi ECAM370.95.T [91]
	AC	720	68.4	0.0001	0.95	50	High (Mbps)	Mitsubishi MSZ-AP50VGK [92]
Master Bedroom	Laptop—Gaming	3600	342	0.0001	0.95	50	High (Mbps)	ASUS ROG Zephyrus G14 2024 [93]
	AC	360	34.2	0.0001	0.95	50	High (Mbps)	Mitsubishi MSZ-AP25VGK
Bedroom 2	Tablet—Kids	1500	142.5	0.0001	0.95	50	High (Mbps)	Apple iPad 10th gen (2022)
	AC	360	34.2	0.0001	0.95	50	High (Mbps)	Mitsubishi MSZ-AP20VGK
Bedroom Office	Laptop—Work	2400	228	0.0001	0.95	50	High (Mbps)	Dell Latitude 7440 [94]
	AC	360	34.2	0.0001	0.95	50	High (Mbps)	Mitsubishi MSZ-AP20VGK
Front Door	Wi-Fi Camera	7200	684	0.0001	0.95	30	High (Mbps)	Reolink RLC-810A [95]
Basement	AC	180	17.1	0.0001	0.95	50	High (Mbps)	Mitsubishi MSZ-AP25VGK
Hallway	Security Panel	60	5.7	0.0001	0.95	30	High (Mbps)	Honeywell Galaxy Flex3-20 alarm

,

Table 19. Simulated hourly traffic and energy of Z-Wave protocol.

Location	Device	Packets per Hour	Energy (mJ)	Airtime (s)	TxPower (W)	Range (m)	Data Rate	Reference Model
Kitchen	Oven Meter	12	4.32	0.01	0.036	30	Low (Kbps)	Shelly Pro 1PM [96]
	Water Sensor	12	4.32	0.01	0.036	30	Low (Kbps)	Aeotec Water Sensor 7 Pro [97]
Back Door	Door Lock	48	17.28	0.01	0.036	30	Low (Kbps)	Yale Assure Lock 2 [98]
Garage	Garage Door	24	8.64	0.01	0.036	30	Low (Kbps)	Aeotec Garage Door Controller [99]
Bathroom	Water Sensor	12	4.32	0.01	0.036	30	Low (Kbps)	Aeotec Water Sensor 7 Pro
Basement	Water Sensor	12	4.32	0.01	0.036	30	Low (Kbps)

and

Table 20. Simulated hourly traffic and energy of ZigBee protocol.

Location	Device	Packets per Hour	Energy (mJ)	Airtime (s)	TxPower (W)	Range (m)	Data Rate	Reference Model
Living Room—Dining Room	Light	120	14.880	0.004	0.031	30	Low (Kbps)	Philips Hue White & Color E27 [100]
	Light	120	14.880	0.004	0.031	30	Low (Kbps)
Master Bedroom	Light	60	7.440	0.004	0.031	30	Low (Kbps)	Philips Hue White Ambiance E27 [101]
	Window Sensor	6	0.744	0.004	0.031	30	Low (Kbps)	SONOFF SNZB-04
Front Door	Light	30	3.720	0.004	0.031	30	Low (Kbps)	Philips Hue Lily XL [102]
	Door Sensor	12	1.488	0.004	0.031	30	Low (Kbps)	SONOFF SNZB-04 [103]
Bedroom 2	Light	60	7.440	0.004	0.031	30	Low (Kbps)	Philips Hue White Ambiance E27
Garage	Motion Light	24	2.976	0.004	0.031	30	Low (Kbps)	Philips Hue Motion Sensor [104]
Attic	Motion Sensor	24	2.9760	0.0040	0.031	30	Low (Kbps)

. They are listed with their location, purpose, packet count, energy, range and data rate.

4.2. Protocol-Level Traffic and Energy

In

Table 21. Simulated hourly traffic and energy per communication technology (PHY/MAC level).

Protocol	Category	Dev.	Radio Freq (MHz)	Range (m)	Pkts/h	P_tx (mW)	E (mJ/h)
Ethernet	Wired	4	Wired	100	2580	1000	30.960
SPE	Wired	3	Wired	100	552	200	5.299
Insteon	Mixed	2	Mixed	30	108	55	89.100
KNX	Mixed	2	Mixed	30	84	45	75.600
UWB	Short	6	3000–9000	10	354	75	5.310
DASH7	Sub-1 GHz	2	868	50	36	40	2.880
EnOcean	Sub-1 GHz	3	868	30	54	1	0.054
Z-Wave	Sub-1 GHz	6	868	30	120	36	43.200
LoRa	Sub-1 GHz	3	868	2000	21	125	148.523
Mioty	Sub-1 GHz	2	868	2500	16	50	40.000
Sigfox	Sub-1 GHz	2	868	3000	3	45	270.000
LTE-M	Cellular	4	Licensed	5000	42	650	136.500
NB-IoT	Cellular	2	Licensed	10,000	6	220	132.000
BLE	2.4 GHz	7	2400	30	636	15	3.587
Zigbee	2.4 GHz	9	2400	30	456	31	56.544
Thread	2.4 GHz	3	2400	30	240	32	32.256
Wi-Fi	2.4 GHz	15	2400	50	24,828	950	2358.660
Wi-Fi HaLow	Sub-1 GHz	3	868	200	90	120	10.800
TOTAL					30,226		3441.273

, all protocols used are listed, with their simulated packet count, transmit power and hourly energy consumption.

The total simulated transmission energy across all L1 and L2 technologies during the one-hour evaluation window amounts to 341.273 mJ. As expected in a modern smart-home environment, Wi-Fi communications have the largest value in both traffic (82% of all packets) and energy (68.54% of total IoT device energy). EnOcean contributes negligible energy due to energy-harvesting operation. LPWAN protocols (LoRa, Sigfox, and Mioty) account for about 40 packets/hour in total but achieve the longest ranges (up to 10 km) for NB-IoT. The protocol-level results, corrected to account solely for PHY/MA Layer transmission energy, are presented in the revised

Table 22. Percentage contribution by technology.

Technology	Energy (mJ/h)	Share (%)	E/Device (%)	E/Packet (%)
Wi-Fi	2358,660	68.45	26.91	0.07
Sigfox	270.000	7.84	23.10	70.59
LoRa	148.523	4.31	8.47	5.55
LTE-M	136.500	3.96	5.84	2.55
NB-IoT	132.000	3.83	11.29	17.25
Insteon	89.100	2.59	7.62	0.65
KNX	75.600	2.19	6.47	0.71
Zigbee	56.544	1.64	1.08	0.10
Z-Wave	43.200	1.25	1.23	0.28
Mioty	40.000	1.16	3.42	1.96
Thread	32.256	0.94	1.84	0.11
Ethernet	30.960	0.90	1.32	0.01
Wi-Fi HaLow	10.800	0.31	0.62	0.09
DASH7	2.880	0.08	0.25	0.06
UWB	5.310	0.15	0.15	0.01
SPE	5.299	0.15	0.30	0.01
BLE	3.587	0.10	0.09	~0.00
EnOcean	0.054	0.00	0.00	0.00

. The last two columns represent the normalized share of energy per % device and per packet to system mean. Application-layer protocols such as MQTT are excluded from independent energy attribution because their transmission costs are inherently absorbed by the underlying physical bearer (e.g., Wi-Fi or Ethernet).

The total simulated transmission energy across all L1 and L2 technologies during the one-hour evaluation window amounts to 3441.593 mJ. As expected in a modern smart-home environment, Wi-Fi (2.4 GHz) overwhelmingly dominates the energy budget, accounting for 68.54% of the total radio energy consumption as well as the energy per device percentage by 26.91. In contrast Sigfox, despite having a small percentage in share, due to its architecture, has the highest value in energy per packet. Figure 10 is a graphical representation of the share of all the protocols in this scenario.

When grouped by frequency band, as shown in

Table 23. Results aggregated by radio category.

Technology	Protocols	Energy (mJ/h)	Share (%)
2.4 GHz Radio	Wi-Fi, BLE, ZigBee, Thread	2451.047	71.23
Sub 1-Hz Radio	Z-Wave, EnOcean, Wi-Fi HaLow, DASH7	56.934	1.65
LPWAN Module	LoRa, Sigfox, Mioty	458.523	13.32
Cellular	LTE-M, NB-IoT	268.500	7.80
Mixed	KNX, Insteon	164.700	4.79
Wired	Ethernet + SPE	36.259	1.05
Short-Range	UWB	5.310	0.15

, 2.4 GHz technologies collectively contribute 71.14% of total transmission energy.

In contrast, Sub-1 GHz LPWAN and low-power sensor technologies—including LoRa, Sigfox, Μioty, Z-Wave, EnOcean, and DASH7—account for about 15% of the total energy budget, despite supporting significantly longer communication ranges. Cellular technologies (LTE-M and NB-IoT) account for 7.8% of the total, reflecting their moderate power and influential transmissions.

Wired interfaces (Ethernet and SPE) represent only 1.05% of total energy consumption, driven mainly by continuous desktop and network video recorder activity. Short-range technology UWB contributes less than 0.2%.

These results confirm that in realistic smart-home deployments, radio energy consumption is not dominated by long-range IoT protocols but instead by high-bandwidth, user-facing Wi-Fi devices. Consequently, power-optimization strategies should primarily target the 2.4 GHz front-end, as improvements in LPWAN or Sub-1 GHz modules would yield negligible overall system-level savings. According to these results, power-optimization strategies should primarily focus on the 2.4 GHz front end and more particularly on Wi-Fi.

4.3. Antenna-Module Aggregates

Table 24. Results aggregated by radio category (simulated).

Module	Devices	Pkts/h	Energy (mJ/h)	Share of Total Energy (%)
2.4 GHz	34	26,160	2451.047	71.23
Sub 1-GHz	14	300	56.934	1.65
LPWAN Module	7	40	458.523	13.32
Cellular	6	48	268.500	7.80
Short-Range	6	354	5.310	0.15
KNX/Insteon	4	192	164.700	4.79
Wired	7	3132	36.259	1.05
Total	70	30,226	3441.273	100

summarizes the protocol-level results by antenna module. The combined device count, as well as the total packets and total energy per hour served by each module, are shown. Both the hardware power budget and the bandwidth-planning requirements are displayed.

The 2.4 GHz radio module has by far the heaviest workload. It serves the Wi-Fi cameras and the streaming devices whose duty cycles require even higher bandwidth than any Sub-1 GHz sensor. This finding emphasizes the need for careful power planning on the 2.4 GHz front-end and enhances the need for PTA-based coexistence scheduling. Figure 11 illustrates the share of total energy for each module.

4.4. 24-Hour Gateway Load Profile

The simulated aggregate gateway ingress rate (packets per second) at every hour of a representative day is displayed in

Table 25. The 24-h gateway load (packets/second, simulated).

Time	Load (pkt/s)	Time	Load (pkt/s)
00:00	0.88	12:00	11.00
01:00	0.69	13:00	10.24
02:00	0.50	14:00	9.77
03:00	0.43	15:00	10.41
04:00	0.40	16:00	11.29
05:00	0.45	17:00	13.74
06:00	1.47	18:00	15.95
07:00	8.06	19:00	15.28
08:00	9.55	20:00	14.38
09:00	11.58	21:00	13.41
10:00	12.76	22:00	11.10
11:00	11.74	23:00	6.77

. The profile scenario follows a typical usage pattern of a Greek family. Overnight, everything is on standby due to limited usage. A short morning spike acts like a trigger when the household wakes up. As all members are away from the household, there is a mid-day reduction. Then, there is the afternoon–evening peak when the family returns.

The peak load is 15.95 pkt/s at 18:00, when the first person’s return triggers door-sensor, smart-lock, presence-sensor, and HVAC commands simultaneously. The trough is 0.4 pkt/s at 04:00. The 40:1 peak-to-trough ratio confirms that a single gateway must be sized for the peak but will be lightly utilized for most of the night. Figure 12 visualizes the gateway load for each hour.

The simulated throughput (Mbps) carried by each major antenna module at two-hour intervals is displayed in

Table 26. Module throughput by 2-h interval (Mbps)—hours 00:00 to 10:00.

Module (Mbps)	00:00	02:00	04:00	06:00	08:00	10:00
2.4 GHz Radio	0.25	0.14	0.11	0.42	2.72	3.64
Sub-1 GHz Radio	0.01	0.01	0.00	0.02	0.11	0.15
Cellular Module	0.00	0.00	0.00	0.00	0.03	0.04
Wired Interface	0.08	0.05	0.04	0.14	0.91	1.21

and

Table 27. Module throughput by 2-h interval (Mbps)—hours 12:00 to 22:00.

Module (Mbps)	12:00	14:00	16:00	18:00	20:00	22:00
2.4 GHz Radio	3.14	2.79	3.22	4.55	4.10	3.17
Sub-1 GHz Radio	0.13	0.12	0.13	0.19	0.17	0.13
Cellular Module	0.03	0.03	0.03	0.05	0.04	0.03
Wired Interface	1.05	0.93	1.07	1.52	1.37	1.06

. Values are averaged over each two-hour window. Note the strong diurnal pattern on the 2.4 GHz and Wired modules, driven by user-facing devices, while the Sub-1 GHz module remains nearly flat—consistent with the always-on, low-duty-cycle sensor devices it serves.

In the evening peak hours, from 18:00 to 20:00, the 2.4 GHz module reaches 4.55 Mbps of traffic. This value is significantly below the PHY rate of 54 Mbps, confirming that a single 802.11n radio can handle the combined smart-home load without saturation. The Wired’s module peak of 1.52 Mbps likewise uses only a small portion of the provided Gigabit capacity. In Figure 13 the module throughput is displayed with a 2 h interval.

4.5. Energy Consumption by Module

As shown in

Table 28. Module energy ranking (simulated, 1 h window).

Module	Energy (mJ/h)	Share (%)	Cumulative (%)
2.4 GHz Radio	2451.047	71.14	71.14
LPWAN Module	458.523	13.31	84.44
Cellular Module	268.500	7.79	92.24
Mixed	164.700	4.78	97.02
Sub-1 GHz Radio	61.254	1.78	98.79
Wired Interface	36.259	1.05	99.85
Short-Range	5.310	0.15	100

, the antenna modules are ranked by their hourly energy contribution. In the cumulative and share columns, it can be seen that collectively the 2.4 GHz radio, cellular module and LPWAN interfaces account for more than 92.35% of the IoT device energy budget.

4.6. Cost–Benefit Analysis

In

Table 29. Total-Cost-of-Ownership Comparison (5-Year).

Metric	Baseline (9 GW)	Universal GW
Unit Count	9	1
Hardware Cost (€)	2700–4500	500–800
Idle Power (W)	~45	~6.3
Peak Power (W)	~90	~15
Annual Energy Cost (€)	94.61	15.77
5-Year Energy Cost (€)	473.05	78.85
5-Year TCO (€)	3173–4973	579–879
Savings vs. Baseline (€)	-	2400–4100

, a comparison is made between the universal gateway and the baseline of nine independent gateways that would normally be needed to cover the same 18 protocols. Greek electricity costs are taken at the average price of €0.15/kWh (Hellenic Energy Authority) [105,106]. Annual energy costs are calculated from the simulated peak power and a weighted average occupancy factor, derived from the 24 h load profile (Table 5).

The 83% power reduction is consistent with the simulation results, which showed that the universal gateway never exceeds 15 W of power. This is because only one set of baseband processors and power-management ICs is active at any time. The 2400€–4100€ five-year savings per household is a significant value for the family budget. This number across a smart-city deployment of millions of residential units would rise linearly.

4.7. Universal Gateway vs. Alternative Multi-Protocol Architectures

Another comparison that needs to be made is with other architectures using one or more gateways.

Table 30. Multi-protocol gateway architecture comparison.

Architecture	Protocols	Peak Power (W)	Hardware Cost (€)	Energy/yr. (€)	Key Limitations
9 independent single-protocol gateways	18	90	2700–4500	94.61	9 management interfaces, 9× power, no unified control
RAK7289 V2	4	~8	~350	~12.55	Supports only 4 protocols
SDR/USRP B200	∞ (software defined)	~20	~1500	~31.41	Real-time latency, no type approval, cost scales with N
Proposed gateway	18	15	500–800	15.77	Only on simulation, hardware prototype as future work

lists a comparison of the proposed gateway against existing solutions. The first one uses nine independent gateways supporting a single protocol each. The second one is based on the multi-protocol hub RAK7289 V2 (supporting four protocols, i.e., LoRa, Wi-Fi, LTE and Ethernet) [30]. The last one makes use of a hypothetical SDR approach with the use of Ettus Research USRP B200, capable of implementing multiple Physical Layers in software.

4.8. Protocol-Coexistence Risk Assessment

Sharing a single physical device can increase the risk of interference from neighboring ones.

Table 31. Coexistence risk matrix.

Protocol Pair	Shared Resource	Duty-Cycle Overlap	Severity	Mitigation
Wi-Fi vs. ZigBee/Thread	2.4 GHz ISM	High	Medium	IEEE 802.15.2 PTA; ZigBee channels 25–26
Wi-Fi vs. BLE	2.4 GHz ISM	Medium	Low	BLE frequency hopping (37 adv. channels)
LoRa vs. Sigfox	868 MHz ISM	Very Low	458.523	1% duty-cycle regulation; separated sub-bands
Z-Wave vs. LoRa	Sub-1 GHz	Very Low	268.500	100 kHz vs. 125 kHz chirps—spectral separation adequate
KNX RF vs. EnOcean	868 MHz ISM	Low	Low	EnOcean bursts < 1 ms; KNX duty cycle < 1%
LTE-M vs. NB-IoT	Licensed band	N/A	None	Operator-managed; orthogonal carriers

groups the significant risk pairs, displays the shared resource that is claimed, assigns a severity level based on the simulation-observed duty-cycle overlap, and proposes the mitigation employed in this architecture.

The only pair rated with “medium” severity is the Wi-Fi vs. ZigBee/Thread coexistence. This is the most heavily studied coexistence scenario [13,14,15,16,18]. The PTA mechanism implemented on the 2.4 GHz module has been demonstrated to reduce ZigBee packet loss to below 2% even under heavy Wi-Fi traffic [18].

4.9. Security Analysis

The consolidation of 18 protocols into a single gateway introduces concerns about security since an attack can be distributed across separate devices in a baseline deployment. In order to ensure this issue, four factors are examined.

The first one is the physical protection. Physical access to the gateway could cause firmware extraction, JTAG (Join Test Action Group) debugging, or radio module replacement. In order to ensure its safety, features like the use of a locked enclosure with tamper protection, enforcing a secure boot (with hardware root of trust), and the use of signed firmware updates can be applied. The use of a standalone gateway reduces the probability of an unpatched device persisting on the network. This is a common vulnerability in multi-gateway deployments where secondary gateways receive infrequent updates [52].

A second issue has to do with the protocol bridging and lateral movement. Not all of the 18 protocols provide the same level of security. Protocols like Insteon, EnOcean, KNX RF, DASH7 do not provide mandatory encryption. This could cause a breach of security and reach the CSMA backbone and enumerate higher value targets. In order to avoid this, protocol-level isolation and implementation is recommended, providing separate VLANs (Virtual Local Area Networks) or software-defined network segments per antenna module. The gateway’s firmware should enforce strict ingress filtering, and each protocol’s device should not be permitted to initiate connections to another device directly [2].

Another security concern has to do with traffic isolation. All data from the protocols are terminated to the gateway before they are forwarded to the internet. Some of these do not need any external connection, while others are more independent in managing their own cloud connection. The use of the universal gateway can improve end-to-end security, as all the traffic is managed from it [2].

A final concern regarding security is the RF vulnerabilities. In the open 868 MHz band, protocols like LoRa, Sigfox, Mioty, Z-Wave, EnOcean, KNX RF and Wi-Fi HaLow can be affected. A distributed deployment with geographically separated gateways would be more resilient to localized interference (jamming) [2].

5. Discussion

The simulated results demonstrate that gateway consolidation is not only technically feasible but also provides an economic advantage. A single universal gateway can handle 70 heterogeneous devices with a peak load of only 8.40 pkt/s (<6 Mbps), far below the CSMA channel’s capacity of 1 Gbps. The 40:1 peak-to-trough ratio in gateway load suggests that dynamic power scaling (putting idle modules to sleep) could reduce the already low 15 W peak further, potentially to below 8 W during night hours. The reduction in gateways by 59% can be translated and improve user experience through unified management interfaces.

Several limitations must be acknowledged. First of all, the entire validation framework is built on ns-3 simulations, which, while appropriate for network-level analysis, inherently lack Physical Layer realism. The simulator does not model RF propagation at the Physical Layer. Therefore, real-world multipath fading, wall attenuation, and near–far effects are calculated. Also, the energy model assumes constant transmit power per protocol. In real conditions, link-adaptation algorithms adjust power dynamically. Therefore, a power reduction of 83% represents the worst-case scenario. In order to have a more realistic number the normalized share should be taken into account. Another acknowledgement is that the household traffic model is based on a single representative Greek family schedule. A wider demographic sampling would strengthen the statistics of the results. The ns-3 application layer uses a simplified packet-injection model rather than full protocol-stack implementations. For instance, LoRa devices are modeled using a custom LoRa packet type in OMNeT++ [107] (ns-3 does not natively support it). This requires the study to approximate LoRa’s spreading-factor-dependent airtime and duty-cycle constraints via equivalent UDP traffic bursts. This abstraction captures the aggregate load and energy profile but does not reproduce the Physical Layer chirp spread spectrum modulation or the MAC Layer adaptive data-rate (ADR) algorithm that would be present in a real LoRaWAN deployment. Also, this architecture is validated at the system-design and simulation level. Prototype fabrication and over-the-air protocol testing remain as future work. The last issue concerns the long-term hardware reliability of a densely integrated multi-radio board. This has not been assessed here, and a long-term field-trial investigation is needed.

Future research should explore adaptive protocol scheduling, hardware implementation of the gateway, machine learning-based resource allocation, and integration with edge computing frameworks. Also, the development of the QoS mechanism for prioritizing the protocol’s traffic will be examined. Additionally, field testing in diverse geographic and demographic settings would validate the simulated results.

6. Conclusions

In this paper, a comprehensive study of a multi-protocol IoT gateway was presented, capable of supporting 18 distinct home automation protocols, with the use of six consolidated RF modules. It is represented through a detailed network simulation, with the use of ns-3 simulator. The results that this gateway convergence offer have the following substantial benefits:

• A total of 78 devices across 18 L1/L2 protocols handled by a single gateway with six antenna modules;
• Peak gateway load of 15.95 pkt/s and a 24 h total of 3441.273 packets—well within CSMA capacity;
• Up to 83% decrease in power consumption for full gateway load: nine-gateway baseline at 90 W reduced to a 15 W peak;
• Five-year TCO savings of €2400–€4100 per household at Greek electricity rates;
• Simplified management is offered through a unified control interface;
• Wi-Fi vs. ZigBee/Thread is the sole medium-severity coexistence risk; this is mitigated by IEEE 802.15.2 PTA;
• Energy is dominated (92.24%) by the 2.4 GHz, cellular, and LPWAN modules.

The architecture presented in this article is a practical blueprint for future gateway implementations and home infrastructure. As IoT ecosystems are expanding, gateway convergence has become extremely important for managing complex and costly attributes. This work provides a theoretical foundation and a practical implementation guide for this transition.

Beyond the home area, the principles of the demonstrated protocol consolidation and resource sharing can be extended to industrial areas, smart cities and even larger areas. This example of a universal gateway creates a path towards more sustainable, managed and cost-effective IoT infrastructure for future deployments.