# ZSM Framework for Autonomous Security Service Level Agreement Life-Cycle Management in B5G Networks
## 6 Performance Evaluation
### Proactive Experimental Results  
In this section, we explain the different KPIs used to evaluate the proactive stage of our ZSM-based framework for managing the security of a real B5G system, as well as provide insights gained during the process. The total initial time is calculated by summing the per-domain times. Specifically, the E2E SMD initial time is measured from the moment the E2E SO receives the slice and security requirements until these policies are distributed across each domain. For the UMU and TID SMDs, the initial time refers to the time elapsed from when each domain's SO receives the B5G security slice policy to its full deployment and configuration across the infrastructure. Figure 10a illustrates the initial time required to deploy and configure the security slice across the E2E, UMU, and TID SMDs. The results show that the E2E initial time is negligible, less than 2 s, as there are no VNF instantiation or configuration tasks at the E2E domain. In contrast, the TID and UMU domains have significantly longer times, averaging 95 s and 180 s, respectively. These times are attributed to the more extensive tasks handled in these domains, such as 5G core setup, channel protection, STA monitoring, and Proof of Transit (PoT). Figure 10b further breaks down these initial times by key processes in proactive slice deployment for each domain (UMU and TID). Key stages include as follows:  
* Orchestration time: The time taken by the SO to create and enforce the orchestration plan, including policy translation. This stage is minimal in both domains, taking less than 3 s.
* Deployment time: The time required to dynamically deploy security enablers, constituting a significant portion of the total time. This is primarily influenced by the type of virtualization used and the dependencies and coordination required between the assets. * Enforcement time: The time required for security enablers to be configured and ready. This varies based on dependencies. For instance, PoT becomes operational within 7.2 s, whereas other processes, like the I2 NSF agent, require longer wait times due to dependency sequencing. The I2 NSF agent's enforcement time is the largest component of UMU's total time, requiring approximately 100 s to be fully operational. In contrast, STA in TID takes about 25 s to reach readiness, with 15 s dedicated to its final configuration. Full details are presented in the following table. Table 2 shows the distribution of times required by each domain to apply each policy. It presents both the total elapsed time and a breakdown into specific operational phases, such as startup and configuration. These measurements were obtained using the technological and computational resources described at the end of Section 5. For I2 NSF and PoT, measurements appear only in the UMU SMD domain because the timing is recorded by controllers at the UMU premises. As a result, the reported startup time encompasses the period required for both the TID and UMU VNFs to become ready for configuration, while the configuration time refers to the additional time needed for full operational readiness. PoT requires the E2E channel protection to be operational before its configuration can take place. Additionally, note that the STA VNF is deployed exclusively in TID SMD alongside the 5G core VNF. These results are further compared with the state-of-the-art solutions in Section 6.3. Among the resources used, the 5G core with the STA enabler required a flavor powered by four cores, 4 GB of RAM, and 32 GB of disk space. The same flavor was used for the I2 NSF agents and PoT VMs. Analyzing the extracted data, the experimental results highlight the effectiveness and scalability of the ZSM-based framework for managing B5G system security.