# An Architecture for the Performance Management of Smart Healthcare Applications
## 5 Performance Evaluation  
The PRIMUS architecture was evaluated on Mininet-WiFi Network Emulator [22] that supports virtualization techniques (SDN and NFV) and network slicing. The emulator runs on the operational system Linux Ubuntu 18.04 LTS over a virtual environment (VirtualBox tool) with Intel Core i7 8500H processor (Santa Clara, California) and 8 GB of RAM. The emulation comprises of an emulated wireless network infrastructure containing two switches, one access point, three wired devices, three wireless devices, and three servers, as shown in Figure 5. The network was virtualized and sliced based on Openflow rules by Libera Hypervisor [23], and the tenants' slices were managed by ONOS based SDN controllers [50]. The six devices are divided among the three network service/slice types (\(SST\)): URLLC, eMBB, and Best Effort (BE). Each device generates synthetic traffic simulating the specific \(SST\) to a server by iPerf tool v2.0.5 (iPerf Tool: [[https://iperf.fr/](https://iperf.fr/)]([https://iperf.fr/](https://iperf.fr/)). Accessed on July 2020). One way latency was captured by Python scripts using the Scapy v3.7 library. We call each \(SST\) as its corresponding traffic, i.e., URLLC, eMBB, and Best Effort slices for each bit of traffic.  
The evaluation scenario allows the management of slices and bandwidth use. Hence, we have compared the network performance over two scenarios: (i) considering network slicing isolation and \(SST\) priority (called **NSI scenario**), and (ii) without slicing isolation (called **no-NSI scenario**). The NSI scenario implements the slicing isolation with one specific slice for each slice type (\(SST\)), following a priority queue where URLLC has the highest priority. In contrast, the no-NSI did not implement isolation. All traffic generated compete to access the same slice (one link). The network slices compete with each other because they share the same communication physical links. Hence, 1 Mbits/s, 15 Mbits/s, and 15 Mbits for URLLC, eMBB, and BE, were generated, respectively. For BE, traffic was created threads of traffic generation to increase the competition and the amount of traffic.  
In the scenarios, by the iPerf tool, all devices start the workload generation together over 100 s. As PRIMUS mechanism aims to achieve s-health requirements, we have considered network traffic similar to s-health applications. The characteristics of eMBB slice traffic correspond to telemedicine application, whereas the characteristics of the URLLC slice traffic corresponds to critical care monitoring, as shown in Table 2. At every 0.3 s interval, network traffic was generated. Moreover, we have generated best effort traffic to massive concurrent traffic to consider a more realistic scenario. Hence, the URLLC traffic has a lower throughput compared to the eMBB and BE throughput [6]. However, the URLLC requires stringent requirements than other slices. Thus, the tenant responsible for the URLLC service requested to network hypervisor for higher  
Figure 5: Emulation scenario.  
\begin{table}
\begin{tabular}{l c c} \hline \hline
**Control Message** & **Content** & **Description** \\ \hline \multirow{2}{*}{Announce} & Application type and requirements & Inform if application is s-health \\ \hline \multirow{2}{*}{Monitor} & Network resources & Inform about network \\  & (e.g., resources use) & resources availability \\ \hline \hline \end{tabular}
\end{table}
Table 3: PRIMUS control messages.  
priorities in the processing of OpenFlow rules. We have computed the average TCP latency packet loss rates as the performance metric. The one way latency was computed by the difference between the timestamp of the message received by the server and sent by the host (_received_timestamp_ -- _sent_timestamp_). We have extracted the metrics from the three servers that receive the traffic generated by the devices. These metrics were measured using scripts in Python v2.7 with Scapy library. Each plotted result is an average of 33 repetitions for both scenarios. Results consider the latency metric.