Harnessing Communication Heterogeneity: Architectural Design, Analytical Modeling, and Performance Evaluation of an IoT Multi-Interface Gateway

Given the massive deployment of Internet of Things (IoT) applications over the last decade, the need for gateways able to efficiently route information flows across multiple heterogeneous networks has emerged, bringing new challenges. Therefore, the design and implementation of IoT gateways is crucial. In this article, with reference to the architecture of a prototypical multi-interface gateway (MIG) (based on commercial-off-the-shelf (COTS) devices), we evaluate its performance: 1) analytically, through an innovative Markov chain-based model; 2) by simulation, with a Python simulator; and 3) experimentally, through the (starting) COTS device-based prototype. In detail, the MIG is equipped with heterogeneous wireless communication interfaces (namely, LoRaWAN, BLE, cellular 4G Cat. 4, and IEEE 802.11 Wi-Fi 2.4 GHz) and is applicable to multiple IoT scenarios. The obtained simulation and experimental results show the validity of the proposed analytical model. Further improvements of the proposed framework are eventually discussed.


I. INTRODUCTION
A MONG the technologies and paradigms which have recently changed the way of thinking about the Internet, a key role is played by the Internet of Things (IoT), which entails the development of a multitude of nodes equipped with sensors/actuators and different (often wireless) communication interfaces.To this regard, thanks to the large number of contexts and scenarios which IoT can be applied to (e.g., smart cities, Industry 4.0, and smart farming), IoT entities are often organized (from a network point of view) as systems of systems.
In general, a reference IoT scenario encompasses heterogeneous communication protocols from short range (usually with high data transmission rate) to long range (typically with low data transmission rate) [1], as shown in Fig. 1.Due to this heterogeneity and the need to "federate" IoT networks, one of the main challenges is to allow a transparent (from a highlevel point of view) interaction between different networks.Therefore, a key element is a gateway, whose features and capabilities play a crucial role in enabling IoT applications by efficiently routing data.
Gateways are typically multilayered (with reference to the ISO/OSI and TCP-IP layered protocol stacks) network entities which support: intelligent information flows' routing; data processing; and queuing mechanisms (this is crucial, as we will see, in the presence of heterogeneous communication interfaces).On the other hand, heterogeneous networks, with a large number of nodes collecting data (e.g., through sensors) from the surrounding environment, exploit proper data processing techniques to extract relevant (nonredundant) information and made its transfer compatible with low data-rate protocols [e.g., Long Range Wide Area Network (LoRaWAN)].
In this article, we first present the architecture of a commercial-off-the-shelf (COTS) device-based prototypical implementation of an enhanced scalable and modular multiinterface gateway (MIG) with four heterogeneous communication interfaces, namely: IEEE 802.11 (2.4 GHz) Wi-Fi; Bluetooth low energy (BLE); LoRaWAN; and cellular 4G (Cat.4).Then, in order to accurately predict the experimental performance of our COTS device-based MIG in various scenarios, we derive a novel Markov chain-based queuing model of the MIG.Various input distributions for the packet interarrival times are considered, in order to evaluate their impact on the system performance.Finally, we develop a Python-based software simulator of the MIG in order to verify the analytical performance predicted by our Markov chain-based queuing model, thus paving the way to a comparison between analytical and simulation results, as well as to a deeper analysis of the limitations of the used communication protocols.Unlike classical approaches, which move from theoretical modeling to experimental validation, in this study we move from a COTS device-based MIG (with a specific architecture) to its analytical and simulation models.
Eventually, the performance of the MIG prototype, equipped with pairwise bidirectional smart data routing mechanisms between the four aforementioned communication interfaces (namely: Wi-Fi, BLE, 4G, and LoRaWAN), is experimentally evaluated and compared with the analytical and simulation performances.The proposed MIG architecture supports internal data preprocessing to make high throughput information flows (from the BLE, Wi-Fi, and cellular interfaces) compatible with the constrained transmission capabilities of LoRaWAN.In particular, proper parsing, adaptation, and conversion rules are used to minimize resource consumption, thus guaranteeing the highest possible (sustainable) throughput.The modular design of the MIG allows: 1) to make use of constrained protocols (namely, LoRaWAN) feasible and 2) to introduce predictive processing mechanisms (e.g., based on artificial intelligence (AI) techniques) to be applied to the data flows (e.g., to optimize resource utilization).
The main contributions of this work can be summarized as follows.
1) We present the architecture of a COTS device-based prototypical implementation of a modular MIG. 2) We evaluate the experimental performance of the MIG with heterogeneous communication interfaces, namely: IEEE 802.11Wi-Fi, BLE, LoRaWAN, and cellular 4G. 3) We derive a novel Markov chain-based queuing model of the MIG, to analytically estimate its performance as a function of the input traffic data distribution.4) We consider different input distributions for the packet interarrival times, in order to evaluate their impacts on resource utilization of the MIG.5) We develop a Python simulator to verify the analytical performance predicted by the proposed Markov chainbased queuing model.

6)
We compare analytical, simulation, and experimental performance results in the presence of pairwise bidirectional smart data routing mechanisms between the communication interfaces.The remainder of this article is organized as follows.In Section II, we overview existing solutions and comment on related research works available in the literature.Section III introduces and characterizes the internal MIG architecture, with reference to a specific prototypical implementation.In Section IV, we derive a Markov chain-based queuing model to describe the behavior of the MIG.In Section V, we evaluate the performance predicted by the analytical queuing model (in the presence of a representative input data distribution) and compare it with that of a Python-based simulator.In Section VI, we rely on the validated analytical model to analyze the impact of the packet interarrival time distribution.In Section VII, this comparison is extended toward the experimental performance evaluation of the MIG prototype.Section VIII is dedicated to discussing possible improvements.Finally, in Section IX conclusions are drawn.

II. RELATED WORKS
The heterogeneity of IoT scenarios and applications requires to carefully consider communication aspects, thus looking for potential tradeoffs.The communication protocols shown in Fig. 1 are strongly heterogeneous in terms of data rate and applicability.In detail, widely adopted wireless communication protocols are: BLE for short-range communications [2]; IEEE 802.11 (Wi-Fi) and ZigBee [3] for medium-range communications; and narrowband-IoT (NB-IoT), cellular (e.g., 4G LTE), LoRaWAN, and Sigfox [4] for long-range communications.In order to make these protocols interoperable and manageable by a multi-interface node, their characteristics have to be carefully taken into account [5].Typically, two entities support interoperability: 1) bridges [6] and 2) gateways [7].Gateways should be preferred, with respect to bridges, in IoT scenarios, as they support intelligent data routing, queuing policies, and data analysis mechanisms for heterogeneous (in terms of resources and constraints) communication interfaces [8].Hence, the design and deployment of intelligent gateways play a crucial role, especially in the case of large heterogeneous networks requiring "intelligent" data preprocessing at the edge.
Even though there are different gateways available on the market (for example, [9]), they typically present relevant drawbacks, such as: high costs; limited communication interfaces available on the devices; and, most of all, "closed source" nature.This "closeness" prevents: the introduction of new routing/communication/processing features; the connection of new communication interfaces; and the implementation of complex network scenarios-e.g., with intelligent routing policies based on traffic offloading, as well as enhanced decision mechanisms (e.g., through the adoption of traffic engineering paradigms [10], [11]).Therefore, the design and implementation of modular and open gateway architectures, like the one proposed in this work, may lead to a faster deployment of new IoT applications based, for example, on the integration of heterogeneous wireless sensor networks (WSNs).
Focusing on the analytical characterization of a gateway, in [12] a hidden Markov model-based approach for latencyaware and energy-efficient computation offloading in fog computing-like scenarios is proposed.This analytical model is exploited to find the best possible candidate layer which application modules can be executed at.An interesting optimization tool for constrained IoT applications is then proposed.Markov queuing models have also been adopted in [13] and [14], looking for a tradeoff between energy consumption and latency in task assignment in next-generation systems, as well as in [15], [16], [17], and [18].
The research works mentioned in the previous paragraph focus on the use of Markov chain-based models for the characterization and optimization of a few network parameters only for specific IoT system aspects (e.g., energy consumption).Unlike our work, the above works are not applicable to an MIG supporting heterogeneous communication protocols and do not allow to derive a corresponding Markov chain-based model.More in detail, most of the above literature works focus on modeling a single communication protocol according to its specific (low level) protocol rules.For example, the analytical model of the LoRaWAN protocol proposed in [19] focuses on LoRaWAN UpLink (UL) latency, collision rate, and throughput, assuming that the packet interarrival time has an exponential distribution.An extended model is proposed in [20], where both UL and DownLink (DL) transmissions, together with other relevant features of the LoRaWAN protocol, are taken into account.Unlike [19], [20], the goal of our work is not the investigation of the behavior of each protocol per se, i.e., without considering the others.Rather, we want to model the behavior of a communication protocol and investigate its limits depending on the constraints imposed by its interaction with other protocols, e.g., when the input information flow comes from another communication interface the MIG is equipped with.
As for the LoRaWAN protocol case, most of the BLE scientific literature models the BLE behavior considering lowlayers' protocol details.In [21], an analytical model of BLE advertising channels is proposed for several applications (such as localization or data advertisement in IoT use cases).
Finally, in [22] a high-level characterization of a gateway, to be used for several IoT applications, is proposed.In detail, the authors highlight how the interactions among multiple devices can be modeled in large-scale applications, thus optimizing the deployment of gateways to guarantee efficient and adaptive communications in several scenarios.However, in [22] no internal modeling of such gateways is proposed, focusing more on the high-layer interactions among multiple gateways, rather than internal packet management between heterogeneous protocols, as presented and discussed in our work.

III. MIG ARCHITECTURE
The prototypical IoT-oriented MIG implementation proposed in this article is based on a Raspberry Pi 4 (RPi4) single board computer (SBC), equipped with an additional Dragino LoRaWAN hat [23], and an external 4G LTE Cat.4-enabled Huawei E3372 USB dongle connected to one USB port of the RPi4.Owing to this configuration, the MIG may operate with the following connectivities: BLE and Wi-Fi (through the communication interfaces natively provided by the RPi); LoRaWAN (through the external Dragino hat); and cellular (through the Huawei modem).In Fig. 2(b), we show: (a) the COTS device-based MIG prototype and (b) its corresponding internal architecture.From a software point of view, the MIG architecture is based on two high-layer types of modules, namely: 1) a dedicated software routine for each available communication interface and 2) an internal routing module, denoted as smart data broker (SDB), that, jointly operating with an internal message queue telemetry transport (MQTT) broker, is in charge of handling multiple MQTT topics and is used for temporary internal traffic packets' queuing and management purposes.We now describe in more detail each block.
The main role of the software routine associated with each communication interface equipping the MIG is: 1) to properly handle the tasks which may be required by the corresponding communication protocol (e.g., packet processing, payload constraints' validation, transmission policies' adoption, services' execution, UL and DL operation handling, etc.) and 2) to optimize, convert, and forward data (e.g., coming from on-field end nodes connected to the MIG) toward the right interface-specific MQTT topic.
In the following, we consider incoming packets (also denoted as DL packets, from end nodes toward the MIG) only through BLE and Wi-Fi interfaces.This is motivated by the fact that the LoRaWAN interface is practically used only for UL communications 1 and the same applies also to the cellular interface (as IoT nodes may rarely be equipped with a cellular interface to communicate with the MIG).In other words, the envisioned behavior of the MIG is that of collecting data from nearby Wi-Fi or BLE IoT nodes (DL data traffic) and forward this traffic (properly processed) across LoRaWAN or cellular networks (UL data traffic).
Suppose that the data collected from on-field end nodes have the illustrative structure shown in Fig. 3 (at the top).Once received by the MIG, these packets will then be processed by the proper DL interface' handler.The selected handler then "appends" a header field, denoted as ID ROUTE , specifying the routing rule which should be applied by the SDB routing system (e.g., forward to the LoRaWAN interface).Furthermore, in the case of a packet coming from Wi-Fi or BLE nodes (as discussed in the previous paragraph), this packet is extended to include the following fields: 1) the source node's MAC address SRC MAC and 2) a separator field.The final packet structure will thus possess a general form with a header H and a payload PKT.
Looking at the internal routing mechanism, the SDB relies on a standard MQTT broker handling different MQTT topics, each of them managed by a proper UL/DL handler in charge of processing input packets and forwarding them to the right output interface's UL queue according to a first-in-first-out (FIFO) policy.Then, the interfaces' servers, being subscribers to the MQTT UL topics of their corresponding communication interfaces: 1) are notified by the SDB with the updated data transfer units (DTUs), leading to aggregated packets; 2) perform the required actions on the data; and 3) execute the final UL operation, forwarding data to the right target device through the proper interface.To this end, it should be noted that, from an operational point of view, the MIG creates a new thread each time a message is notified via the proper UL MQTT topics.In the proposed implementation, the data are temporarily stored inside the RPi4's RAM, thus limiting the processing time and increasing the overall performance.
For the sake of completeness, it should be highlighted that each software entity managing its own communication interface also encapsulates (with a proper parsing technique) the retrieved data into DTUs, to make them suitable for constrained protocols.More in detail, IP and MAC addresses are properly "compressed" (to minimize occupation): an IP address is encoded as a single integer and an MAC address is translated into its corresponding HEX value.This approach is especially useful to minimize the dimension of  LoRaWAN messages' payloads.Finally, depending on the routing identifier, the resulting DTU is sent to the proper communication interface.An illustrative example of routing rules2 defined internally in the proposed MIG is shown in Table I.
The proposed DTU structure, shown in Fig. 4, allows processed data, to be transmitted by BLE and Wi-Fi communication interfaces, to be inserted in an output packet with a payload composed by N aggregated payloads {PKT i } N i=1 separated by the separator field "|," each one in turn composed by the identifier of the target (either IP or MAC address), separated from the payload by a separator field "@."At the opposite, in the case of data to be transmitted by the LoRaWAN interface, the resulting data packet will be a sequence of processed packets separated by the separator field "|."To this end, in order to further optimize the use of such constrained networks, intelligent (e.g., AI based) data preprocessing mechanisms could be used, as will be discussed in Section VIII.
In order to better highlight the relation between on-field end nodes and the proposed IoT MIG, in Fig. 5 the data flows inside the proposed architecture are shown.The introduction of new communication interfaces would be possible owing to the internal modular architecture of the MIG.In fact, only the specific software routines needed for a new communication interface should be written, abiding by their own constraints and rules, while MQTT broker and SDB would remain unchanged.Moreover, the adoption of publish/subscribe-based routing policies allows the MIG to accept incoming traffic flows even from additional data sources and, possibly, with different input data packets' format-this is not considered in the current paper but represents an interesting research direction.We also remark that routing policies' management could be outsourced and (logically) concentrated on external controllers (e.g., in the cloud) to enhance the infrastructure managementthis is out of the scope of this article and is left as a future development.
Looking at the operational conditions, since the interaction among MQTT topics requires a nonnegligible processing time, it can be assumed that the proposed MIG is suitable for nonreal-time applications, where data are collected from different sources (e.g., for environmental monitoring, as well as in noncritical Industrial IoT, IIoT, and domains) within a proper amount of time (e.g., at least 1 s).The system performance could be improved by reducing the internal processing time: this represents an interesting research direction.
As anticipated in Section I, the proposed MIG is applicable to several heterogeneous IoT scenarios where data may be collected from different data sources deployed in the environment of interest (e.g., environmental data sensing and remote monitoring), especially in those contexts in which communication protocols may be constrained and/or communication conditions may be challenging.
1) A first representative application scenario is smart farming, in which several IoT sensing/actuating nodes (e.g., based on ESP32 System-on-Chip (SoC) [25] and equipped with Wi-Fi and BLE connectivity, as well as several hardware sensors, such as DHT11 [26]) with short-range communication capabilities are deployed over a large area far away from an Internet access point.The collected data need to reach high-layer processing entities (e.g., cloud platforms, as well as end users, such as farmers) interested on these data, following a Farmas-a-Service (FaaS) approach [27].Therefore, the use of an MIG, similar to the prototypical implementation proposed in Section III and based on an RPi 4 with additional LoRaWAN and cellular communication interfaces, will be essential to support information collection from the field and forwarding to the Internet [28], as shown in Fig. 6. 2) A second scenario benefiting from the adoption of the proposed IoT-oriented MIG is unmanned aerial vehicle (UAV)-based remote monitoring.As an example, in smart city a large number of short-range WSNs might be deployed to collect data of interest, possibly preprocessing them before forwarding them to high-layer consumers.Then, a UAV equipped with a Wi-Fi-, BLE-,  and LoRaWAN-enabled MIG can, first, gather data (either using short-range or long-range communication protocols) by flying over/near these WSNs and, then, forward the collected data to an Internet-connected node using a long-range or cellular communication protocol, as shown in Fig. 7. 3) A third reference scenario, in the more general context of smart cities, involves Vehicle-to-Everything (V2X) communications [29].In this case, similarly to scenarios where UAVs should interact with each other, on the ground (i.e., along roads and highways) there may be the need to collect data (e.g., for monitoring purposes) directly from the vehicle and the driver by relying on the MIG.This would involve: a) the interaction of the MIG with the vehicle's on board unit (OBU) for diagnostic information retrieval, through wireless or wired communication interfaces, as well as b) data collection at the MIG from additional equipment and devices installed inside the vehicle's cabin (e.g., driver's smartphone and wearables for monitoring his/her stress levels [30]), through wireless communication interfaces.
After preliminary processing performed in the MIG inside the vehicle, the extracted information may be sent to the infrastructure (e.g., via LoRaWAN, provided that the obtained data can fit its payload constraints) as well as to vehicles in the neighborhood (e.g., via vehicular Wi-Fi or BLE, for warning alerting), possibly exploiting advanced driver assistance systems (ADASs) and targeting cooperative communications which urban and suburban mobility can benefit from.Finally, as a general remark, the proposed IoT MIG allows to exploit additional heterogeneous communication interfaces as backup communication interfaces in critical situations or when the communication interface under use fails [31].This can be the case, as shown in Fig. 8, in contexts involving drones (e.g., for UAV-to-Ground communications and vice-versa), where multiple data streams could be exchanged between flying UAVs and one (or more) ground control centers, as well as among the UAV and its human pilot (to ensure the correct execution of the flight operations).
All the illustrative applications outlined above require the use of heterogeneous communication protocols and the MIG plays a key role in enabling interactions with each other.

IV. ANALYTICAL QUEUING MODEL
In order to investigate how the proposed MIG harnesses communication heterogeneity by properly handling traffic data, in this section we derive a novel Markov chain-based queuing model for the MIG.In Section IV-A, the MIG is modeled through an embedded Markov chain with states corresponding to the communication interfaces: the chain is in one state if the corresponding interface is transmitting or receiving.We assume that one interface at a time can be active. 3he Markov chain transition matrix is associated with input and output flows across different interfaces.In Section IV-B, each communication interface's UL queue will be modeled as a G/G/1 queue.
We remark that our Markov chain-based model does not take into account the physical transmission channels associated with the communication interfaces equipping the MIG.In fact, our focus is on internal information flow management and we will assume that the wireless communication channels are error-free.An interesting extension encompasses the analysis of the impact of channel status on system performance (e.g., because of retransmissions).The proposed Markov chain model provides a simple, yet effective, way to predict the performance of the MIG, taking also into account possible limitations of a real system deployment (such as the internal processing time, due to the processing capabilities of the embedded SBC-an RPi, as indicated at the beginning of Section III).

A. Embedded Markov Chain
The flows of the DTUs (mentioned in Section III) inside the MIG can be characterized through an embedded Markov chain with states corresponding to the MIG's communication interfaces.The transition probability associated with a link between two states depends, in general, on the flow from the input (DL) interface (initial state) to the output where P i,j , i ∈ {W, C, B, L}, j ∈ {W, B, C} represents the transition probability from state i to state j or, in other words, the probability that an information flow has to be transferred from the ith interface (receiving interface) to the jth interface (transmitting interface).
Given that in our Markov chain-based queuing model the transition probabilities depend on: 1) the internal (inside the MIG) routing rules and 2) the input arrival rates at the MIG's communication interfaces (DL flows), the corresponding arrival rates at the output queues at the communication interfaces (UL flows) can be expressed as follows: We further remark that, while an output queue is considered at each MIG interface (for transmissions out of the MIG, i.e., 4 We remark that no arrival flow is considered in the LoRaWAN state (i.e., λ = 0 pkt/s), as the LoRaWAN interface is assumed to support only UL communications (no Class C IoT node is considered).The fact that λ (UL) are expressed in pkt/s, rather than DTU/s, will be clarified in the remainder of the section.
Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.
UL transmissions), no queues are associated with the links between pairs of states of the state diagram (i.e., between pairs of MIG interfaces), since: 1) packets received from end nodes are immediately processed (no need for input queues at the communication interfaces) and 2) internal transitions are managed at the software level and the corresponding latencies can thus be neglected in the Markov chain-based model (the internal latency is negligible).Therefore, we focus on the output queues associated with the MIG interfaces.
We finally assume that the internal routing between the different MIG interfaces considers direct information flows from one interface to another interface (e.g., an information flow entering from the BLE interface is forwarded to the LoRaWAN interface).This 1-in-to-1-out assumption on internal routing is meaningful (and nonrestrictive) for the following reasons: 1) it reflects a realistic behavior of the MIG for IoT applications, as discussed in Section III and 2) it keeps the internal Markov chain-based model tractable.The extension to the combination of multiple input information flows (e.g., BLE and Wi-Fi) into a single output information flow (e.g., LoRaWAN) is an interesting research extension.Taking into account (2), the 1-in-to-1-out assumption can be formalized with the following constraints: For example, assuming that an information flow from the BLE interface has to be forwarded to the LoRaWAN interface, in (2) one should set P B,L = 1, P C,L = 0, and P W,L = 0, obtaining Finally, we remark that, even if the proposed MIG's analytical model does not take into account network congestion (especially at the transport layer), the extension of the analytical model to encompass the presence of congestion represents an interesting research direction.For example, a preliminary strategy may require to dynamically update the transition probabilities, with a direct impact on the routing rules associated with each communication interface, taking into account the load at the interfaces' servers.As an example, if the LoRaWAN interface server is operating at a value closer to its stability threshold (i.e., ρ L −→ 1 − ), the associated LoRaWAN in-flow transition probabilities (namely: P B,L , P C,L , P W,L ) can be reduced, while the in-flow transition probabilities of another interface (e.g., Wi-Fi, namely: P B,W and P C,W ) can be increased, thus lowering λ (UL) L (in) to reduce the load at the LoRaWAN server and, therefore, congestion.Another possible approach to handle network congestion could be based on removing the 1-in-to-1-out assumption in (3): part of the information flow entering into a congested interface may be deflected to another interface available to reach the final intended destination.In general, there may be other approaches to handle congestion: however, this analysis goes beyond the scope of the current work and will be the subject of our future research.

B. G/G/1 Queues for Uplink Interfaces
In the proposed Markov chain model, we assume that each interface UL queue (outgoing traffic) is associated with a G/G/1 queue.This is an analytical queuing model of the MQTT-based system described, from an architectural point of view, in Section III.The G/G/1 queuing model has been chosen due to the generality of the distributions associated with arrival processes and service times.In fact, in the proposed MIG, for each communication interface: the interarrival time of DTUs has a general distribution with known parameters; and the service time has a distribution which depends on parameters related to the size of the packet being processed.
In order to accurately model the behavior of the G/G/1 queue at each UL interface, two remarks are expedient: 1) Wi-Fi and cellular G/G/1 queues transmit each DTU without performing any batch operation (on groups of DTUs), whereas 2) BLE and LoRaWAN G/G/1 queues perform DTUs batching to optimize the throughput.In other words, in BLE and LoRaWAN cases the output packet size is maximized by concatenating together, in a single payload, as many DTUs as allowed by the standards, taking into account the operational settings. 5) LoRaWAN G/G/1 Queue: LoRaWAN is the most constrained communication interface in the MIG.Its corresponding G/G/1 queue, shown in Fig. 10, can be decomposed into the concatenation of two subqueues: 1) a DTU Aggregator, receiving DTUs and batching them together in order to create a single LoRaWAN packet and 2) the LoRaWAN's Packet Transmitter, in charge of processing the packets and transmitting them.In the following, we characterize these two subqueues.
a) DTU aggregator: The DTU Aggregator can be modeled as a G/D/1 queue, where λ (UL) L (in) is the input arrival rate (dimension: [DTU/s]) of the single DTUs and T AGG is the average service time (dimension: [s]) needed to aggregate a packet. 6To this end, the G/D/1 queue model has been chosen, as the DTU arrival distribution can, in principle, be general, while the service time is deterministic, as it depends (uniquely) on the number of DTUs flowing into the DTU Aggregator.The behavior of the DTU Aggregator guarantees a tradeoff between LoRaWAN packet length maximizationand, consequently, LoRaWAN throughput maximization-and minimization of the waiting time inside the buffer of the DTU Aggregator.In particular, a maximum waiting time, defined as t max (dimension: [s]), is introduced: after t max , even if the number of DTUs in the buffer is smaller than the maximum (denoted as n) allowed in a single LoRaWAN packet payload, the DTUs are aggregated and, then, sent to the Packet Transmitter.As a consequence, this approach allows DTUs inside the DTU Aggregator to incur a limited waiting time, as a tradeoff between aggregated packets with small payloads (low throughput and short waiting time) and with large payloads (high throughput and long waiting time).
On the basis of the above assumptions, multiple DTUs will be aggregated together, up to a maximum of n DTUs, if and only if the interarrival times between consecutive DTUs is shorter than t max .Otherwise, the "incomplete" packet will be sent to the next subqueue in Fig. 10 (i can be derived according to (4) (i.e., based on the 1-in-to-1out information flow assumption).Moreover, it is possible to express the arrival rate as a function of the average interarrival time as follows: where T is the average interarrival time (dimension: [s]) between consecutive DTUs and depends on the distribution of the DTU arrival process-this will be further discussed in Section VI.
Owing to the previous discussion, considering: 1) the average interarrival time T between DTUs; 2) the average DTU size L DTU ; 3) the threshold value of the waiting time t max ; and 4) the DTU Aggregator flow diagram shown in Fig. 11, it is possible to evaluate the average LoRaWAN packet aggregation time and the average arrival rate λ AGG (dimension: [pkt/s]) at the input of the LoRaWAN Packet Transmitter.By using the total probability theorem one can write where and where Since {T i } are independent and identically distributed, defining P max P{T i > t max } one can write From ( 6), one obtains Finally, observing that T i = T ∀i ∈ {1, . . ., n}, it follows: Similarly, one can obtain the average quadratic value of T AGG as follows: Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.
b) Packet transmitter: In order to evaluate the waiting time in the buffer of the LoRaWAN Packet Transmitter, modeled as a G/G/1 queue, one can rely on Kingman's formula [33] where: ρ λ AGG •S L (adimensional); S L is the average service time of the LoRaWAN server (dimension: [s]); and C a and C s are the coefficients of variation of arrival and service times (adimensional), respectively.The coefficient of variation of arrival times C a can be expressed as follows: where and In order to evaluate the coefficient of variation of the service time, denoted as C s , further analysis on the LoRaWAN protocol behavior and policy rules is required.First, the service times' distribution should be related to the LoRaWAN packet size, thus associating each packet configuration (with a specific number of aggregated DTUs) with a proper probability, which depends on the parameters of the DTUs' source generating distribution.As an example, assuming an average DTU size L DTU = 20 bytes (as will be detailed in Section VII) and considering a maximum LoRaWAN useful achievable payload size equal to 222 bytes, 7 the maximum number of DTUs possibly inserted into a single LoRaWAN packet would be equal to 11, which would then correspond to the specific value of the parameter n in the previous derivation (e.g., in Fig. 11).
Then, taking into account the DTU size and the LoRaWAN constraints, it is possible to evaluate the service time of the LoRaWAN G/G/1 server.The service time of a packet containing i ∈ {1, . . ., n} aggregated DTUs, denoted as S L i , can be expressed as follows: where: T P PROC−i is the internal processing time (dimension: [s]) associated with i DTUs and can be expressed as follows: T P AIR is the packet airtime (dimension: [s]) and can be expressed as follows [34]: and T P DUTYCYCLE is the LoRaWAN duty cycle time (dimension: [s]) and can be expressed, according to the regional parameters [32], as follows: In the formulas above: T DTU PROC depends on the specific HW platform which the MIG builds upon; the LoRaWAN preamble size, denoted as n PREAMBLE , is set to 8 byte; SF= 7, BW = 125, DE = 0 (low data rate optimization), CR = 4 (coding rate); and PL (LoRa packet payload), which includes a 13-byte LoRaWAN packet header and the aggregated DTUs, can then be expressed (in our model) as PL = 13 + n • L DTU .These LoRaWAN-related parameters have been set according to the LoRaWAN regional parameters [32].
According to (18), the LoRaWAN packet service times The average service time, denoted as S L , can be calculated by applying the total probability theorem on the partition {A i } n i=1 in ( 7) and the service time defined by (18), thus obtaining Similarly, one can write At this point, the variance of the service time, denoted as σ 2 S L , can be calculated as follows: The coefficient of variation of the service time C s can thus be expressed as follows: At this point, one can evaluate the average waiting time in the buffer, denoted as W (L) q , according to (14).Finally, knowing W (L) q (14), S L (22), and T AGG (12), it is possible to calculate the overall average time (denoted as T PKT−SOJ L ) that each DTU is expected to spend at the LoRaWAN communication interface (namely, DTU Aggregator and Packet Transmitter), from the time instant of Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.
DTU arrival to the time instant of packet (in which the DTU has been aggregated) departure, as follows: 2) BLE G/G/1 Queue: Focusing on the BLE interface, its G/G/1 queue model is similar to the one detailed in Section IV-B1a.More specifically, the BLE DTU Aggregator has the same behavior of the LoRaWAN DTU Aggregator, while a proper G/G/1 queue, associated with the BLE Packet Transmitter, must be defined according to the BLE protocol rules.
BLE packets can have a larger dimension (with maximum corresponding to 512 bytes) than LoRaWAN ones.Therefore, the BLE DTU Aggregator is required to aggregate up to n = 25 DTUs.Moreover, similarly to the LoRaWAN DTU Aggregator, even for the BLE DTU Aggregator one can introduce the parameter t max , which takes the same value as the one considered in Section IV-B1a.The same holds for the other parameters (e.g., λ (UL) B (in) ), in order to fairly compare the performance of all communication interfaces.Hence, λ (UL) B (in) can be calculated as in ( 5), while T AGG and σ 2 T AGG can be evaluated as in ( 12) and ( 17) (relying on the state diagram in Fig. 11).
The main difference between BLE and LoRaWAN models is related to the service time of the G/G/1 queue modeling the Packet Transmitter.In fact, with the BLE protocol no duty cycle is used, thus resulting in a significantly shorter average service time.However, the BLE protocol requires the MIG (active as master) to connect to a BLE slave device before being able to communicate with it.Therefore, the BLE model has to take into account this connection time, denoted as T CONN B (dimension: [s]).On the basis of our experimental investigation, T CONN B ∼ = 7 s.The BLE packet service time can thus be calculated as follows: where T P PROC−i , defined by (19), is the processing time required to create a packet which aggregates i ∈ {1, . . ., n} DTUs.
Hence, once all BLE packet service times {S B i } n i=1 are calculated (similarly to the service times {S L i } n i=1 detailed in Section IV-B1a for the G/G/1 queue of the LoRaWAN Packet Transmitter), it is possible to evaluate the average waiting time in the buffer of the G/G/1 LoRaWAN queue according to (14), which still holds for the BLE protocol.Finally, the overall average time spent by the aggregated packet in the BLE interface, denoted as T PKT−SOJ B , can be calculated as follows: AGG . (28) 3) Wi-Fi and Cellular G/G/1 Queues: Given their similarity, in terms of performance and behavior, these two interfaces can be modeled in the same way.Since Wi-Fi and cellular interfaces have a significantly higher throughput than BLE and LoRaWAN interfaces, a batching operation on the incoming DTUs is not required and, then, the DTU Aggregator is no longer present in their corresponding models.Therefore, both Wi-Fi and cellular interfaces (UL) queues can be modeled as single G/G/1 queues and, furthermore, simplified to G/D/1 queues.In fact, the service time for each DTU can be seen as the sum of a fixed processing time (denoted as t DTU PROC and equal for both interfaces) and a fixed latency (denoted as t LATENCY W and t LATENCY C for Wi-Fi and cellular interfaces, respectively): they can thus be modeled as deterministic.In other words, one can write Since the service time is deterministic, the coefficient of variation of the service time C s becomes equal to 0. Therefore, the waiting time in the buffer, given by ( 14), reduces, in the Wi-Fi and cellular cases, to S W ( 31) where: S W and S C are the Wi-Fi and cellular service times [( 29) and (30), respectively]; ρ W λ (UL) Finally, it is possible to obtain the average waiting time W q .The overall times spent by a DTU at the Wi-Fi or cellular interfaces can then be expressed as follows: where q can be computed as in (31) and (32), respectively.
As a final remark, the main difference between Wi-Fi and cellular Packet Transmitter queues is that, according to experimental measurements, t LATENCY W t LATENCY C .In other words, the cellular interface has a significantly longer sojourn time (due to technological reasons).This aspect, further depending on the specific cellular protocol version (e.g., 4/5G), may introduce a relevant latency in some applications.

V. SIMULATION-BASED PERFORMANCE EVALUATION
In order to validate the analytical queuing model detailed in Section IV-B, a Python-based simulator has been developed taking into account all the blocks considered in the analytical model.More in detail, the simulator includes a DTU Generator with DTU interarrival time having a uniform distribution U [t a , t b ] [35].The DTU Generator generated the DTUs to be processed by the interface queues.In particular, the following reference values are initially considered: for all interfaces, t a = 0 s, t max = 5 s, L DTU = 20 bytes, T DTU PROC = 20 ms; for the BLE interface, T CONN B = 7 s; for cellular and Wi-Fi interfaces, t LATENCY C = 50 ms and t LATENCY W = 10 ms, respectively.
Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.By generating 1000 DTUs, 8 we characterize each communication interface according to the following performance metrics: 1) server utilization ratio ρ; 2) average service time S; 3) waiting time W q in the buffer of the G/G/1 queue and/or G/D/1 queue (depending on the presence or absence of the DTU Aggregator); and 4) sojourn time T DTU−SOJ (which includes, in the LoRaWAN and BLE cases, the DTU aggregation time).The selected metrics are relevant for the following reasons.
1) The average service time allows to estimate the processing time required by each protocol to serve packets.2) The sojourn time is relevant to understand the overall time spent by the data in the system, and consequently, the latency introduced by the MIG in routing data between heterogeneous communication interfaces.
3) The server utilization ratio is expedient to understand the load of the interface server, thus allowing to estimate if an information flow increment can be tolerated.Moreover, the server utilization ratio might be useful for energy consumption optimization purposes (e.g., to maximize battery energy savings with a battery-powered MIG).As the analytical model in Section IV, the Python-based simulator as well does not take into account the physical characteristics of the wireless transmission channels associated with the communication interfaces of the MIG.In other words, we assume that the corresponding communication channels are ideal.Extending the simulator to take into account the channel status is an interesting research direction.
In order to estimate the accuracy of the simulated performance indicators, we evaluate the confidence interval (CI) [36] of each simulation point as follows: where: z * is the z star parameter, set to 1.96 (as defined in [36]) to obtain a 95% CI; σ 2 is the variance of the analyzed indicator, obtained from the simulator's output; n sim corresponds to the population number, equal to the number of DTUs processed by the simulator, i.e., n sim = 1000.

A. Evaluation of the Server Utilization Ratio
In order to analyze the stability conditions of the different communication protocols, we investigate the behavior of the server utilization ratio of each interface as a function of t b (keeping all other parameters equal to the values set above), with DTUs' generation according to a uniform distribution U [0, t b ] (i.e., we assume t a = 0).Therefore, the average interarrival time T can be calculated as follows: In Fig. 12, analytical (an) and simulated (sim) server utilization ratios for the following interfaces are shown:  every 10 s can be, on average, handled by the LoRaWAN server.
Regarding Fig. 12(c) and (d), related to Wi-Fi (ρ W ) and cellular (ρ C ) server utilization ratios, respectively, it can be noted that ρ Finally, looking at Fig. 12(b), it can be concluded that the BLE interface can properly handle incoming DTUs for t b > t (min−B) b 0.6 s.Furthermore, from the analytical results one can notice that the BLE interface reaches a peak when t b 5 s.This corresponds to the value of the parameter t max , defined in Section IV-B1a, that maximizes the DTU aggregation process.This analytical result is confirmed also by simulation values and is further explained through an in-deep analysis of the behavior of the DTU Aggregator carried out in Section V-B.

B. Impact of the DTU Aggregator on the Server Utilization Ratio
In order to better understand the impact of the DTU Aggregator on the server utilization ratio ρ, we investigate the BLE case, i.e., the behavior of ρ shown in Fig. 12(b) and predicted by our analytical framework.Recall that the interarrival time between consecutive DTUs is T ∼ U [0, t b ], with average value T = t b /2.In Fig. 13, we highlight the analytical behavior of ρ, as a function of t b .It is possible to identify the following regions/values.1) 0 < t b < t < t max : Instability region corresponding to ρ > 1 (interval (a) in Fig. 13).

2) t (min−B) b
< t b < t max : First stability region, where ρ decreases until reaching a local minimum (region (b) in Fig. 13).
3) t b ≥ t max : Second stability region, where ρ further decreases, from "sudden" peak around t b t max (region (c) in Fig. 13).As mentioned above, there is a sudden peak, in the analytical curve, around t b = t max -we remark that the simulation results, depicted in Fig. 12(b), show a "smoothed" version of this sharp analytical peak.In the following, we motivate this behavior.
1) Instability Region: For 0 < t b < t , with t (min−B) b 0.6 s, holds that ρ (an) B > 1: the system is as the server cannot process all the incoming packets.In fact, the interarrival time T has always a value than t max , so that the DTU Aggregator always aggregates the largest possible number of DTUs (namely, n = 25 for the BLE interface) in each packet.In this region, the average packet generation time T AGG [which can be written as defined by (11)] is shorter than the average service time S B of the Packet Transmitter, defined according to (27).For the sake of clarity, this unstable behavior is illustrated in Fig. 14: the DTU Generator generates packets at a rate which cannot be sustained by the Packet Transmitter.
2) First Stability Region: This region is associated with values of t b such that t In this region, each packet derives from the aggregation of the largest possible number (namely, n) of DTUs.Unlike the previous instability region, in this case the average packet generation time T AGG is longer than the average service time S B of the Packet Transmitter.This situation is pictured illustratively in Fig. 15: the Packet Transmitter manages to serve efficiently the received packets.The service utilization ratio decreases as the packet arrival rate reduces and the service time does not change. 9) Second Stability Region: As can be observed in Fig. 13, in correspondence to t b = t max there is a sharp increase of ρ (an) B , which then decreases for increasing values of t b .This behavior can be explained as follows.As soon as t b overcomes t max , it then follows that each generated packet does not necessarily contains the maximum number n of DTUs: for example, if the interarrival time between two consecutive DTUs is longer than t max , then a packet is generated.This means that the packet arrival rate at the Packet Transmitter increases.However, as shown in Section IV, the connection time T CONN B is the largest component of the service time of a BLE packet: this implies that even if the number of DTUs aggregated in a packet reduces, its service time reduces, proportionally, much less.This explains the sudden increase of the server utilization ratio for t b t max .For increasing values of t b , both the packet arrival rate and the number of aggregated DTUs per packet reduce, thus leading to a constant decrease of ρ (an) B .In the limiting case with t b t max , each packet contains only one DTU, as shown in Fig. 16.
We remark that the simulation-based results shown in Fig. 12(b) approximate the behavior predicted by our analytical model.There is not the sharpest increase predicted by the analytical model as the number of DTUs considered for the simulation is finite (namely, 1000).By increasing the number of DTUs, the simulation-based curve would approximate more and more the analytical one.
In order to further investigate the presence of the peak of the server utilization ratio for t b t max , in Fig. 17 we evaluate the analytical queuing server utilization ratio ρ (an) , as a function of the parameter t b , associated with a uniform DTU generation distribution U [0, t b ], for various values of t max (in detail, 5, 10, and 15 s), considering both   LoRaWAN [Fig.17 This parameter affects the system efficiency by reducing, for small values of t max , the "idle times" between aggregated packets sent to the interface server.For the sake of completeness, this behavior is further investigated in Section VI in the presence of other (nonuniform) input distributions.This will allow to further highlight how the peaks, for both LoRaWAN and BLE interfaces, are due to the DTU Aggregator.

C. Evaluation of Average Service and Sojourn Times
It is of interest to investigate the behavior of: 1) the average service time S of each interface's server and 2) the total average time spent by a DTU at each interface, namely: LoRaWAN (T PKT−SOJ L ) and BLE (T PKT−SOJ B ), as defined Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.  in (26); and Wi-Fi (T DTU−SOJ W ) and cellular (T DTU−SOJ C ), as defined in (33) and (34), respectively.The obtained results (with the corresponding CI of each simulation point) are shown in Fig. 18.For the sake of clarity, we highlight that, even if these performance metrics have been studied as functions of t b ∈ [0, 60] s, in Fig. 18 the results are shown for t b ∈ [0, 30] s, since for t b ∈ [30, 60] s the performance metrics flatten.In other words, the most interesting behavior is observed for t b ∈ [0, 30] s.
From the results in Fig. 18(a), related to LoRaWAN, it can be noticed that the average service times S  respectively, confirm how analytical and simulation results are in very good agreement-note that the range of the y-axis is limited 10 and T DTU−SOJ grows rapidly at t b 0 s [as observed in Fig. 12(c) and (d)].

D. Impact of SF on LoRaWAN DTUs' Aggregation
With regard to the LoRaWAN interface, it is of interest to investigate the average service time and the number of DTUs that can be aggregated within a single LoRAWAN packet as functions of the SF.The obtained results, both analytical and simulation-based, are shown in Fig. 19.It can be observed that (as suggested by the LoRaWAN specifications [24]) increasing the SF: 1) limits the amount of DTUs possibly being aggregated and 2) significantly increases the average service time needed to process packets with aggregated DTUs, thus significantly increasing S.

E. Final Considerations
For the sake of readability and analysis, and to ease a performance comparison between the Markov chain-based model and the implemented Python simulator, in Table II the main performance indicators investigated before, in the case of uniform distribution U [t a , t b ] of generated DTUs, with t a = 0 s and t b = 15 s, are summarized.These results confirm that the most constrained communication interface is the LoRaWAN one, followed by the BLE interface and, then, by the cellular, with the Wi-Fi interface being the best performing.
Finally, through the developed simulator it is possible to evaluate the average data rate, denoted as ψ, achieved by each communication interface equipping the MIG itself.More in detail, the simulated average data rates (over 1000 generated DTUs) are listed below.
It can be concluded that the LoRaWAN interface has a data rate ψ L close to the value predicted by the protocol guidelines with same configuration (namely, 48 bps [24]).The 10 We that the seemingly irregular behavior the curves of both the and cellular simulated service and sojourn is due to reduced of the y-axis.interfaces may be limited the system's specific implementation, which reduces the useful payload processed by the MIG and introduces a high overhead, thus significantly lowering the achievable data rates.This is especially true for Wi-Fi and cellular communication interfaces.Moreover, the cellular technology is also affected by a higher average latency introduced by the network topology.These constraints are further investigated in Section VII, where the experimental performance evaluation of the MIG prototype introduced at the beginning of Section III is carried out.Possible additional improvements to overcome limitations of the proposed MIG implementation will be discussed in Section VIII.

A. Interarrival Time Distributions
While in Sections IV and V the performance of the MIG has been investigated (analytically and with simulations, respectively) in the presence of DTU interarrival time T ∈ U [t a , t b ] (with t a = 0 s and several values for t b ), it is of interest to investigate also the impact of nonuniform DTU interarrival time distributions.According to (5), in the LoRaWAN and BLE cases the average input arrival rate at the DTU Aggregator depends on the average interarrival time T between DTUs.In the following, we investigate the impact of three nonuniform DTU interarrival time distributions on system performance: 1) truncated Gaussian; 2) exponential; and 3) gamma.
Since, in Section V, the accuracy of our analytical model has been validated by our simulator, in the following we investigate the impact of the input distribution only analytically.More specifically, our goal is to investigate the impact of the input distribution on the server utilization ratio.In the LoRaWAN and BLE cases, we will further evaluate the impact of the following DTU Aggregator.
Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.
For the sake of comparison between the aforementioned nonuniform distributions, their corresponding parameters are summarized in the following.In order to make a fair comparison, we will assume that all distributions have the same average value.In order to make a fair comparison with the previously considered uniform distribution, in all cases the average value is set to μ = (t a + t b )/2.
1) Truncated Gaussian Distribution: The truncated Gaussian distribution can be derived from an initial Gaussian distribution [37].The corresponding probability density function (PDF) is expressed as follows: x−μ σ 2 (37) where μ = (t b +t a )/2 and σ 2 is the variance.By truncating the normal distribution N (μ, σ 2 ) over the interval [t a , t b ], the PDF of the corresponding truncated Gaussian distribution becomes Since the truncated Gaussian distribution is still symmetrical with respect to μ, its mean value is still equal to μ = (t b + t a )/2.

2) Exponential Distribution (Poisson Arrivals):
The exponential distribution characterizes the interarrival time of a Poisson DTU arrival process [37].The corresponding PDF can be expressed as follows: where μ is the average value.
3) Gamma Distribution: The gamma distribution is a 2-parameter distribution [37] with the following (general) PDF: where: α > 0 and β > 0 are shape parameters; and (α) is the Gamma function defined as follows: The average value of the gamma distribution is α/β: for comparison fairness, we impose μ = α/β.In the case with β = 1, it follows that:

4) Distributions Comparison and Motivation:
In Fig. 20, a graphical representation of the PDFs of the four considered DTU interarrival time distribution, with t a = 0 s and t b = 15 s, is shown.As indicated above, in all cases the average value is μ = (t a + t b )/2 = 7.5 s.The choice of the aforementioned distributions can be motivated as follows.
The uniform distribution is the reference distribution adopted in our analytical, simulation, and experimental performance analysis, since it is suitable to represent the DTU interarrival time in IoT applications, especially where multiple sensors are involved and randomly (over a reference sampling interval) transmit data to the MIG.
The truncated Gaussian distribution has been chosen to characterize an application where the DTU interarrival time concentrates more, with respect to the uniform distribution, around its mean value.The truncated Gaussian distribution is more suitable to represent multiple sensors transmitting data to the MIG with a predefined polling interval corresponding to the average value.However, due to possible problems (e.g., synchronization errors, packet delays, or collisions), some sensors might transmit their data a bit earlier or later than the predefined update instant, making the DTU interarrival time distribution similar to a truncated Gaussian PDF.
The exponential distribution has been taken into account because it is commonly used in queuing theory to model an arrival process.It is meaningful for IoT applications where a "memoryless" data transmission strategy might be adopted by IoT nodes interacting with the MIG.
Finally, the gamma distribution has been taken into account as it can be interpreted as an intermediate distribution between Gaussian and exponential distributions.

B. Impact on the Server Utilization Ratio
We now investigate the impact of the interarrival time distributions presented in Section VI-A on the server utilization ratio ρ.This analysis aims at evaluating the stability of the MIG as a function of the average DTU interarrival time T. In all cases, t a = 0 s, t b = 15 s, and T = t b /2 = 7.5 s.In the LoRaWAN and BLE cases, t max is set to 5 s.
In Fig. 21(a), we focus on the LoRaWAN interface.When t b < t max , the LoRaWAN server utilization ratio with uniform distribution (denoted as ρ     sojourn times, and server utilization ratios of the various interfaces.In order to fairly compare experimental results with analytical and simulation ones, we evaluate the time needed to process a specific amount of data-namely, a specific number of DTUs-at the various interfaces.To this end, the performance comparison is carried out by setting a common uniform distribution U [0, 15] for the DTU interarrival time T at any interface.This choice allows to compare the time needed by each interface to process a similar amount of DTUs. In the following, the experimental processing time (denoted as T (exp) PROC ) and the simulator processing time (denoted as T (sim) PROC ) have been obtained by measuring the difference between the time instant of system initialization and the time instant corresponding to processing completion of the last DTU.The analytical processing time (denoted as T (an) PROC ) for Wi-Fi and cellular interfaces has been calculated by multiplying the corresponding average sojourn time (T DTU−SOJ W and T DTU−SOJ C , respectively) of a DTU by the number of DTUs needed to send the defined amount of information through the specific interface.In fact, this allows to obtain an acceptable estimation of the overall processing time needed to send the chosen amount of data over the designated communication interface.
The analytical, simulated, and experimental performance results for LoRaWAN, BLE, Wi-Fi, and cellular interfaces are shown in Fig. 26(a)-(d), respectively.As can be seen from the results in Fig. 26, the trends obtained through analytical queuing model, simulator, and experimental testbed are very similar, with T (exp) PROC slightly higher than both T (sim)

PROC and T (an)
PROC .This is mainly due to the additional processing times introduced by the current MIG implementation based on COTS components, which may partially degrade the performance with respect to that predicted by both the Markov chain-based model and Python simulator.
For LoRaWAN and BLE interfaces (whose analytical, simulated, and experimental results are shown in Fig. 26 In detail, PKT−SOJ is obtained by dividing T PKT−SOJ by 2 to take into account the overlapping of aggregating and processing activities to the DTU Aggregator.In fact, while a packet is aggregated by the DTU Aggregator, the Packet Transmitter is processing another packet previously aggregated. Looking at the results shown in Fig. 26(a) and (b), it can be seen that T (an) PROC (for both LoRaWAN and BLE) is slightly underestimated if compared to both simulation-based and experimental values.This might be due to the approximation of the T PKT−SOJ introduced in (43).However, the maximum approximation error is lower than 10% for T (an) PROC L and lower than 15% for T (an) PROC B , respectively, with the relative error decreasing for larger amounts of aggregated DTUs.Instead, simulated and experimental values seem to be aligned (within a maximum 5% difference), thus confirming the overall accuracy of the simulator when compared to the experimental setup.
Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.
The obtained experimental results prove that the overall performance of the proposed MIG prototype can be well estimated using both the Markov chain-based model presented in Section IV and the Python-based simulator discussed in Section V.

VIII. IMPROVEMENTS AND FUTURE WORKS
Given the simulation and experimental performance results shown in Sections V-VII, together with the modularity of the proposed MIG architecture, further improvements might be considered in order to improve its performance.To this end, possible ideas are presented and discussed in the following.

A. Enhanced Queuing Mechanisms and Packet Overhead Optimization
The use of the proposed SDB (detailed in Section III) for DTUs' queuing purposes partially limits the performance of high throughput interfaces (such as Wi-Fi and cellular).To this end, the implementation of a faster and reliable queuing solution (e.g., based on Zenoh protocol [38]) may further improve both reliability and performance of the MIG, making it applicable to more complex and critical scenarios.
Moreover, the current version of the MIG is not optimized for massive data transfer (through Wi-Fi and cellular interfaces).Hence, an enhanced implementation of the MIG with a more efficient UDP socket creation and management might improve the IP-based protocols' performance.This would significantly reduce the packet overhead currently affecting the prototype and, in turn, improve the overall performance of both cellular and Wi-Fi communication interfaces.

B. Exploiting BLE Connection Optimization and Advertising
Focusing on the BLE communication interface, as discussed in Section IV-B2 the BLE capabilities seem to be mainly constrained by the BLE connection time required by external BLE end nodes to establish a communication link with the MIG.To this end, it might be possible to reduce idle times by scheduling and optimizing the connection phase, allowing also each external BLE node to keep its connection alive and to exchange multiple BLE packets with the MIG.This approach would drastically increase the maximum throughput achievable by the BLE interface handler of the MIG, allowing to approach the theoretical upper bound of the BLE application level data rate.
Furthermore, a different BLE interaction scheme might be adopted among on-field end nodes and the MIG, in particular for specific time-constrained applications-e.g., those requiring only mono-directional communication.To this end, one could exploit BLE advertising channels, where BLE end nodes could act as independent GATT servers, broadcasting new information (e.g., collected through their on-field sensors) through the packet data units (PDUs), which are then advertised with a small interval on each available BLE advertising channel.The MIG would act as a passive BLE scanner, sensing for the available PDUs in the air and processing them according to the rules detailed in Table I.As a consequence, this would require the implementation of a new interface entity in the architecture shown in Fig. 2(b), having to: 1) passively scan and detect BLE devices advertising PDUs and 2) forward the PDUs to the SDB in the proper way.Given the experimentally observed BLE connection time T (exp) CONN B 7 s, it is clear that this alternative approach would allow to handle a larger number of end nodes and to obtain a higher throughput on the BLE communication interface (despite the limited 27-byte advertisement packet size) [39].

C. AI-Based Interface Throughput Optimization
In order to optimize data transmission with a constrained protocol (e.g., LoRaWAN), the design and deployment of an on-board "data analysis block," in charge of deciding if an information is relevant (and needs to be forwarded to high-layer entities) or irrelevant (and can thus be discarded, avoiding to unnecessarily fill the MIG's queues), might be beneficial.More in detail, this data analysis block may be performed by an AI-based entity assigning proper weights (corresponding to the priorities in the system's queue) to data, thus leading to priority-based data transmission (in which irrelevant data will be assigned small weights).This approach could, in principle, increase the performance of the MIG's constrained communication interfaces, prioritizing only relevant data transfers, eventually exploiting innovative AI technologies able to improve and optimize data transfer [40].Moreover, this can open the way to other next-generation paradigms to be exploited in conjunction with the functionalities proper of the proposed MIG (e.g., serverless and quantum computing).

IX. CONCLUSION
In this article, the architecture of an enhanced modular MIG, equipped with four heterogeneous communication interfaces (namely, LoRaWAN, BLE, LTE, and Wi-Fi), has been presented, with reference to a specific prototypical COTS device-based implementation.A novel Markov chain-based queuing model, expedient to characterize the MIG behavior and evaluate its performance, has been proposed.A Pythonbased software simulator has been implemented to further validate the Markov chain-based queuing model's predicted analytical performance.Finally, the experimental performance of the COTS device-based MIG prototype has been directly compared to analytical and simulation-based performances, showing a very good agreement.Our results highlight the modularity and scalability of the proposed MIG architecture, allowing the integration of heterogeneous communication interfaces for several IoT applications and scenarios.Possible MIG improvements have also been discussed.His research interests focus on IoT, wireless communication systems, UAVs, and heterogeneous networking.
Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.

Fig. 3 .
Fig. 3. Data packets from the different communication interfaces adopted in the proposed MIG.

Fig. 4 .
Fig.4.Data packets format adopted in the proposed MIG to forward the processed information to end targets.

Fig. 6 .
Fig. 6.Smart farming scenario with RPi-based MIG and several ESP32-based Wi-Fi and BLE sensing nodes.

Fig. 8 .
Fig. 8. MIG adopted as network backup solution for UAV application.
.e., the Packet Transmitter) as-is.For the sake of clarity, the flow diagram detailing the behavior of the DTU Aggregator is shown in Fig. 11 and the meanings of the indicated parameters are the following.λ (UL) L (in) represents the average arrival rate (dimension: [DTU/s]) of the DTUs and, since the DTU Aggregator's model is based on a G/D/1 queue, the arrival rate λ (UL) L (in) with n = 11, depend on the packet dimension.In particular, the service time ranges from S L 1 ∼ = 7.2 s (packet with 1 DTU) up to S L n ∼ = 37 s (packet with n = 11 DTUs).
(a) LoRaWAN; (b) BLE; (c) Wi-Fi; and (d) cellular.This allows to directly compare (and validate) the performance predicted by the Markov chain-based analytical model with that predicted by the implemented Python simulator.From Fig. 12(a), it can be observed that ρ (sim) L = ρ (an) L = 1 for t b 10 s.Hence, it can be concluded that the LoRaWAN interface cannot support a DTU generation distribution U [0, t b ] with t b ≤ t (min−L) b 10 s.In other words, at most one DTU Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.

Fig. 13 .
Fig. 13.Behavior of ρ (an) B in the assumption of fixed DTU interarrival time T = T = t b /2.
t b 0.124 s, while ρ (an) W = ρ (sim) W = 1 for t b 0.056 s.A very good agreement between simulated and analytical performances can be observed.

Fig. 14 .
Fig. 14.Illustrative representation of the behavior of DTU Aggregator and Packet Transmitter in the instability region, for 0 < t b < t (min−B) b , with

Fig. 15 .
Fig. 15.Illustrative representation of the behavior of DTU Aggregator and Packet Transmitter for t (min−B) b < t b < t max .

Fig. 16 .
Fig. 16.Illustrative representation of the behavior of DTU Aggregator and Packet Transmitter for t b t max .
(a)] and BLE [Fig.17(b)] interfaces.The obtained results confirm how the server utilization ratios is influenced by the parameter t max of the DTU Aggregator.
L are in very good agreement.In particular, S (sim) L reaches its saturation value when the DTU aggregation is maximized, i.e., when t b ≤ t max .With regard to average analytical (T (an) PKT−SOJ L ) and simulated (T (sim) PKT−SOJ L ) sojourn times, given the fixed amount of DTUs processed in the simulator (namely, 1000 as indicated at the beginning of Section IV), it is possible to calculate the average waiting time of a DTU even when the analytical queuing model reaches ρ L = 1 (for t b 10 s), thus confirming the overall behavior of the system predicted by the Markov chain-based model proposed in Section IV.Similar considerations can be carried out for Fig. 18(b), referring to the BLE interface.It can be observed that both S (an) B and S (sim) B reach their maximum possible values when t b ≤ t max (i.e., when the BLE aggregated packet size is maximized), while T (an) PKT−SOJ B grows rapidly for t b 0.6 s, as confirmed by T (sim) DTU−SOJ B .Furthermore, it can be observed both analytical and simulation sojourn times have a peak at t b t max = 0.5 s, as already detailed.Finally, Fig. 18(c) and (d), referring to Wi-Fi and cellular interfaces' analytical and simulated service and sojourn times, Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.

Fig. 19 .
Fig. 19.LoRaWAN analytical (S (an) L ) and simulated (S (sim) L ) average service time and number of DTUs per aggregated packet as a function of the SFs allowed by the LoRaWAN protocol.

Fig. 20 .
Fig. 20.Comparison plot of the PDFs of the uniform, truncated Gaussian, exponential, gamma distributions, with t a = 0 s, t b s, and μ = 7.5 s.

L
) and with the truncated Gaussian distribution (denoted as ρ (TG) L) have almost the same behavior.At the opposite, when t b > t max , the truncated Gaussian distribution slightly increases the server utilization ratio.A similar behavior is experienced with both exponential (denoted as ρ (E) L ) and gamma (denoted as ρ (G) L ) distributions, with ρ (E) L being higher for high values of t b , while obtaining a higher ρ (G) L for t max < t b < 30 s.Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.

Fig. 25 .Fig. 26 .
Fig. 25.(a) Real IoT testbed built for the experimental performance evaluation of the proposed MIG, involving: an RPi4-based MIG implementation; a cellular base station; a LoRaWAN gateway; and ten IoT nodes (five BLE and five Wi-Fi).As shown in (b), each IoT node is based on the ESP32 SoC and equipped with a DHT11 humidity and temperature sensor.For the sake of readability, the IoT nodes are shown out of scale (with respect to the real distances among the MIG and both LTE and LoRaWAN equipments).

N
DTU /n DTU−PKT is the number of aggregated DTUs generated by the DTU Aggregator of LoRaWAN or BLE interfaces, as N DTU corresponds to the amount of DTUs to be sent and n DTU−PKT is the average amount of DTUs inside a single aggregated LoRaWAN or BLE packet at the output of the DTU Aggregator; PKT−SOJ T PKT−SOJ /2 corresponds to the average time spent into the queuing system, where T PKT−SOJ represents the overall time spent by the aggregated DTUs inside LoRaWAN or BLE interfaces, respectively.

Emanuele
Pagliari received the Dr.Ing.degree in communication engineering from the Department of Information Engineering, University of Parma, Parma, Italy, in 2020, where he is currently pursuing the Ph.D. degree with the Internet of Things (IoT) Laboratory, Department of Engineering and Architecture.

TABLE I ROUTING
RULES AVAILABLE IN THE PROPOSED IOT MIG