# An Architecture for the Performance Management of Smart Healthcare Applications
## 5 Performance Evaluation
### Results  
The results comprise both scenario settings, NSI and no-NSI scenarios, with and without network slicing isolation. Moreover, in both scenarios, different values for bandwidth were considered. The bandwidth evaluated was 100 Mbit/s and 1 Gbit/s aiming to evaluate network slicing and PRIMUS in low and high competitive resource scenarios. The results employed network traffic from six devices competing for the same slice (no-NSI) and separated on three network slices (NSI) in the emulated network environment. Network traffic from the same slice type competes to transmit the traffic in the slice. These scenarios assist in showing the network slicing efficiency on isolating and controlling the physical network to share the resources, even in stringent concurrent scenarios. Hence, results are presented and discussed following a critical performance analysis. Figure 6 presents the results for latency on both scenarios. Particularly, Figure 6a,b show the average latency with 1 Gbit/s of bandwidth for scenarios with and without network slicing isolation. For all slice types, the latency has reached values around 10 ms and 25 ms since there is enough bandwidth to transmit all network traffic. In the NSI scenario, the URLLC traffic has reached better latency results, such as 8 ms, than in the no-NSI scenario once the first one implements network slicing isolation and priority. eMBB and BE have reached values higher in NSI than in no-NSI. However, they have still presented low-latency values, e.g., 15 ms and 18 ms. Figure 6c,d present the average latency with 100 Mbits/s of bandwidth, i.e., more congested scenarios. The average latency for both scenarios, NSI and no-NSI, achieved similar results as the 1 Gbits/s analyses. However, PRIMUS has achieved lower latency values for URLLC in NSI scenario, such as 5 ms.  
More details on the improvements in latency results are shown in Figure 7, considering the same scenarios and bandwidth values. Particularly, Figure 7a,b show the average latency on NSI and no-NSI with bandwidth available, and Figure 7c,d present the average latency in congested scenarios. While BE and eMBB traffic achieved latency values around 15 ms and 20 ms, URLLC reached 6 ms. In a stringent scenario without available bandwidth, the benefits for URLLC are clear. In Figure 7d, the URLLC traffic presented average latency values lower than 9 ms, while eMBB and BE reached values higher than 20 ms. Therefore, PRIMUS improved the average latency of URLLC, not harming other network traffic considerably. Moreover, URLLC did not present network packet losses. Figure 6: Average Latency. Figure 7: Average latency. Based on the results, PRIMUS was able to manage network slicing, network resources availability, and application requirements. Results have met low-latency even with different applications transmitting data simultaneously and stringent concurrent traffic. The high data rates transmitted on the physical link with restricted bandwidth and physical bottleneck did not interfere with PRIMUS performance. Although PRIMUS has achieved low-latency results, improvements are still necessary because the URLLC slice type demands only 1 ms of latency. However, such latency depends on efficient network physical infrastructure. Even in our network scenario, PRIMUS reached less than 125 ms of latency (value required by daily s-health applications). It is necessary to research latency since there is a delay for the controller to interact with other virtualized components. Moreover, differently from the literature, PRIMUS contributes to the implementation of a virtualized scenario with network slicing. The virtualized implementation is a potential solution to apply in the 5G/6G environment since it uses network slicing. For future analysis, a realistic smart hospital scenario containing many devices can be considered to evaluate PRIMUS scalability.