# Dynamic QoS Management for a Flexible 5G/6G Network Core: A Step toward a Higher Programability
## 5 Testbed Design
### Methodology Implementation
If queues have not been configured for the slice, we must create a new queue with its maximum throughput parameter for each switch. We also add the proactive flows supporting these new queues to the switches. In some cases, a specified queue entry does not exist in the SQL database, but its configuration exists on switches. The script removes both the queues and the flows from the switches. As already mentioned, the program repeats itself, while the second parameter of the script defines the period of repetition. The time interval for refreshing the QoS policy depends on the dynamic QoS implementation policy. Thus, for example, QoS policies do not need to be updated frequently for subscriptions and unsubscriptions to service groups. On the other hand, when it is necessary to provide a quick response to a changed state of link quality, it is necessary to support a fast update of QoS parameters. Our testbed presents a case when a quick QoS policy change is unnecessary, so we refresh every second. It could have contained different periods of updating QoS dynamics. ### Traffic Generators

Instead of simulation, we decided to make an emulation of the environment and manage traffic by implementing the appropriate software on the servers to provide an ade

Figure 6: Process diagram of dynamic QoS management. quate testbed environment. To better organize the service architecture, we have segmented service groups by creating different slices and arranging traffic with Table 2 parameters. We have installed the Apache web service and PHP engine on server SP1 to generate traffic for the Internet (NET) slice. Then, we have created a PHP script that generates a random size response between 0.05 and 5 megabytes for each web request [54] generated once every second. Such a generator realistically reflects the Internet traffic and users' needs for web surfing and downloading web resources of different sizes. Since users mainly use the HTTP protocol, web services rely on the TCP, which allows them to use built-in mechanisms to control data flows and even dynamically adapt to the current availability of the transport link bandwidth (through the windowing mechanism). We have implemented two more slices (service groups). These two slices are named the Multimedia and Security slice. The Multimedia (MM) slice relies on multicast traffic or Video-on-Demand (VoD) video signal transmission. They use UDP streaming and do not have automatic flow-control mechanisms. We have used the D-ITG tool [55] to generate traffic with an uneven exponential distribution. In the direction from the service provider to the user, we have generated around 2000 packets per second with a total throughput between 5.5-6.2 Mbps. The Security slice (SEC) has the role of performing constant video streaming of surveillance signals and sensor values to the \"black box\" cloud. The purpose of these services is to allow real-time analysis and enable the forensics of adverse events and optimize the operation of all engines within the vehicle. In the direction from the vehicle to the service provider, we have generated traffic of around 900 packets per second and a total throughput of 2.8-3.2 Mbps. Similar to the MM slice, we have used the D-ITG tool to generate an exponential traffic distribution. ### Testing Scenarios

To evaluate the proposed solution for dynamic QoS in a multi-slice network, we have defined different testing scenarios and their parameters (Table 3):

* Scenario 1--represents a testing baseline with enough bandwidth capacity for two active service groups.