## 5 COGNIFOG Evaluation in an IoT Connectivity Testbed
### Test Description and Results  
The effectiveness of the implemented COGNIFOG framework in running the e-Health application was evaluated through a comprehensive test. The primary focus of this evaluation was on addressing connectivity issues to ensure the accurate, timely, and seamless transmission of data collected by IoT devices even when coexisting with other types of traffic sharing the same network resources. Specifically, the impact of a UDP background streaming flow (i.e., traffic type A) on the continuous delivery of MQTT messages from both the simulated e-Health application (i.e., traffic type B) and the real IoT devices (i.e., traffic type C) was quantified. Furthermore, the test incorporated the capability to limit the BW for specific services, thereby ensuring available network resources for other higher-priority services, as presented in Section 4. Performance results were obtained for the link connecting the IoT edge GW and the edge server, where all outgoing traffic from the IoT edge GW shared the capacity of a single Ethernet-based uplink connection, which was denoted as CUL. (The wireless link between the two IoT devices and the IoT edge GW is assumed to remain stable for the entire test duration, not introducing any major variations in the results obtained.) By default, this value amounts to 1 Gbps within the premises of the testbed environment. However, CUL was deliberately constrained to 4 Mbps using Wondershapear--a command-line utility for limiting an adapter's capacity [72]. This limitation was intended to emulate more realistic operational conditions of IoT-based e-Health applications, where the system might be subject to lower communication technology capacities, reduced BW allocation, or network saturation during emergencies [73]. No further restrictions were applied in the downlink. To better illustrate the impact of several traffic flows sharing the same link, a UDP background streaming flow was explicitly designed to exceed the network's capacity. This scenario intends to replicate situations such as an unexpected degradation of the uplink communication link or the sudden activation of one or multiple traffic sources, like those generated by alarm-triggered surveillance cameras. In this case, the UDP data generation rate (\(R_{\text{UDP}}\)) was set to 8 Mbps. The entire test lasted 10 min (\(T=10\) min; from 12:00:00 to 12:10:00) with the configuration parameters detailed in Table 1. During this time, a continuous stream of MQTT messages was first transmitted from both simulated and real IoT devices to the IoT edge GW and then forwarded to the edge server, adhering to the characteristics of traffic types B and C, respectively. \(T\) was divided into 3 differentiated stages (where \(T~{}=~{}T_{1}~{}+~{}T_{2}~{}+~{}T_{3}\)) with the following characteristics:  
* **Stage 1** (\(T_{1}~{}=~{}2\) min; from 12:00:00 to 12:02:00): Only MQTT traffic from types B and C was present on the link between the IoT edge GW and the edge server. * **Stage 2** (\(T_{2}~{}=~{}4\) min; from 12:02:00 to 12:06:00): Traffic from types A, B, and C was present on the same link simultaneously. * **Stage 3** (\(T_{3}~{}=~{}4\) min; from 12:06:00 to 12:10:00): Traffic from types A, B, and C was present on the same link simultaneously. However, the configuration of the iPerf3 pod handling UDP traffic was modified on the fly by the Slice Manager at the beginning of this stage to limit its egress BW to 2 Mbps (i.e., \(B^{\prime}_{\text{UDP}}~{}=~{}2\) Mbps). The conducted assessment involved analyzing only the messages from traffic type C: that is, those retrieved from the MQTT broker that were originally sent by the two ESP32 boards acting as smartwatches. These messages also contained timestamps, marking the exact moment each message was generated. As a consequence, some related performance metrics were computed, such as the end-to-end latency (\(L\)), the delay between consecutive messages (\(D\)), the jitter (\(J\)), and the packet-delivery ratio (PDR).