Write a conclusion for this report

Title: Lab Report on Management and Content Delivery for Smart Networks:
Algorithms and Modeling
Introduction
This lab experiment aims to analyze the performance of an IIoT queuing system in an Industry 4.0 scenario. It explores the effects of different configurations and network parameters on system behavior and optimization.

Methodology
The Python code to perform the tasks uses the SimPy library, which provides a framework for building discrete-event simulations with stochastic arrival and service times. The simulation code consists of several functions, including “packet arrivals” to generate and manage packet, edge node processing, and cloud node processing. Moreover, the micro_data_center and cloud_data_center objects act as the buffer for the edge nodes and cloud nodes respectively.
The main elements of the utilized code include parameters for the server configuration, service times, and costs, as well as inputs for the arrival rates and buffer sizes. To measure the results in terms of packet loss rate and average queuing delay, we use a Measure class to keep track of different metrics.
Results
Task 1:
(a) Observing System Behavior and Transition to Steady State:
During the warm-up transient period, the system adjusts to process incoming packets, resulting in performance fluctuations, including packet loss at the Cloud Data Center. Analysis of the loss probability plot reveals a stabilization point at around 2000 units of time, indicating entry into a steady state. 
Figure 1. Loss probability over time (left figure is shows the loss probability for shorter simulation time ) 
(b) Removing Warm-up Transient:
The provided Python code already addresses this task by monitoring packet drop probability and recording losses. A vertical line at time=2000 marks the end of the warm-up transient period. The simulation stabilizes after this point, with a packet drop probability of 5-20% in the Cloud Data Center. Longer simulation times or multiple runs can improve accuracy. Exploring additional metrics and system parameter modifications further optimize the system.

Task 2:
(a) How does the buffer size in the Micro Data Center affect system performance?
Increasing the buffer size in the Micro Data Center has several benefits for the system. It decreases the loss probability at the Cloud Data Center by allowing more packets to be accommodated and reducing the need for processing at the Cloud Data Center. This also helps balance resource utilization between the Micro and Cloud Data Centers, optimizing the use of available resources. Additionally, it improves response times by enabling more local processing in the Micro Data Center and reduces the overall system processing time. Moreover, it increases the system's throughput by accommodating and processing more incoming packets. Overall, increasing the buffer size in the Micro Data Center enhances the system's performance in terms of packet loss, resource utilization, response times, and throughput.
 
Figure 2. Loss probability over various local buffer sizes

(b) Does the buffer size in the Cloud Data Center have a similar impact on system performance?
Increasing the buffer size in the Cloud Data Center reduces loss probability but has a lesser impact compared to increasing the buffer size in the Micro Data Center. It has a minor effect on resource utilization, response time, and throughput for the overall system. The Micro Data Center has a more significant impact on system performance in terms of response time, resource utilization, and throughput.
(c) How does the input data characteristics (values of f) impact the average queuing delay?
As f (fraction of type B packets) increases, the average queuing delay is influenced as follows: for low f values, where most packets are type A, queuing delays accumulate due to longer processing times. As f increases, with a growing fraction of type B packets, processing times decrease at the Micro Data Center, and partial processing at the Cloud Data Center further reduces queuing delays. At high f values, where the majority of packets are type B, faster processing and smaller queuing delays occur due to shorter processing times in both Data Centers.
 
Figure 2. Average queuing delay over different values of f

Task 3:
(a) To reduce queuing time for type A packets, the minimum required service rate can be determined by replacing the edge node with a faster server.
To test the relationship between queueing delay and varying service time, we created a list called "edge_speed_coefficient_list" with coefficients ranging from 0 to 1 (0.1, 0.2, ..., 0.9, 1). These coefficients are multiplied by the initial "A_edge_service_time" and "B_edge_service_time" to adjust the speed of the edge node, allowing us to observe the impact on queueing delays.
The simulation calculates the average queuing delay for type A packets and plots it against the edge node service time speed. As the edge node service time speed decreases, the average queuing delay for type A packets increases. Slower edge node processing leads to longer waiting times in the queue for type A packets. This highlights the significance of efficient edge nodes for faster packet processing and better network performance.
By setting a specific threshold value, Tq (e.g., 15), we can determine the minimum required edge server speed on the diagram to ensure that the average queuing delay for type A packets does not exceed this threshold. (Figure 3)
 
Figure 3. Average queuing delay over different service time for the edge node

(b) Increase edge nodes to minimize queuing time below Tq with a fixed average service time per node.
Increasing edge nodes reduces queuing delay for type A packets. However, the relationship may not be linear, and there are diminishing returns after a certain point. (Figure 4). Hence, we must consider cost, energy consumption, and network resources when determining the optimal number of edge nodes to deploy.
The specific threshold value, Tq (e.g., 15), determines the minimum number of edge servers required (e.g., 2) on the diagram to keep the average queuing delay for type A packets below the threshold. (Figure 4)
 
Figure 4. Average queuing delay over different number of the edge node

Task 4:
(a) Investigate the impact of varying f over time on system performance in different observation periods.
We investigated the average queueing delay and the packet loss, respectively, as the metrics to investigate how varying f will impact the overall system performance.
Figure 5 represents the trend of the average queuing delay concerning the fraction of packet type B (f). The graph shows a falling curve, implying that the average queuing delay decreases as the fraction of type B packets increases.
 
Figure 5. Average queuing delay over different fraction of packet type B
This behavior can be explained by the fact that Type B packets have a shorter service time in the micro data centers (2 units) compared to Type A packets (4 units), which makes the processing faster in the edge nodes for mixed traffics with a higher proportion of Type B packets. Additionally, Type B packets are always sent to the cloud data centers after preprocessing. As a result, a higher fraction of Type B packets leads to a higher utilization level of the cloud data centers, which balances the packet load between the edge and the cloud. As a consequence, the average queuing delay decreases as the fraction of Type B packets increases.

Figure 6 represents the trend of the packet loss rate concerning the fraction of packet type B (f). The graph shows a rising curve until f near 0.6, followed by a falling curve as f increases beyond 0.6.
 
Figure 5. Packet loss rate over different fraction of packet type B
The packet loss rate initially rises due to increased Type B packets being processed at the cloud data center. When the fraction of Type B packets surpasses 0.6, the packet loss rate decreases as traffic becomes more balanced between micro and cloud data centers. 
We must note that, for the both scenarios, results may vary based on service times, delays, and buffer sizes, and experimenting with these values can offer additional insights.

(b) Consider at least 4 Cloud servers with different service speeds and operational costs. Test different combinations of server types to analyze the trade-off between overall cost, queuing delays, and packet drop probability.
Assuming 3 different types of cloud servers with 3 different costs (Server’s cost has an inverse relationship with their service time) by performing the simulation using 4 servers for both the node and cloud servers with 3 different clouds cost we have derived the results in 3 different scenarios depicted in the table 5.
Edge cost	Cloud cost	Total cost	Queuing delay (time unit)	Packet loss(%)
1	1	214697	1.917	70
1	2	412279	1.914	58
1	3	412279	1.931	50
Table 2. Simulation result for 3 different pricing scenarios
According to the table:
1. As the ‘cloud_cost’ increases (which indicates moving to a higher service speed and operational cost cloud server), the ‘total_cost’ of the simulation also increases which is expected. This increase in cost is approximately exponential, suggesting that higher service speed cloud servers come with significantly higher costs.
2. The ‘Average_queuing_delay’ remains generally consistent across different cloud servers, ranging from 1.91 to 1.93. This implies that the increase in service speed does not have a significant impact on reducing the queuing delay in this particular simulation.
3. The ‘packet_loss_rate’ shows a notable decrease as we move to higher cost cloud servers (from 0.70 to 0.59, and then to 0.51). This suggests that an increased investment in more expensive cloud servers can lead to a reduction in packet loss rate.
In conclusion, there is a trade-off between overall cost, queuing delay, and packet drop probability. Investing more in higher-cost cloud servers with better service speeds will lower the packet drop probability, but it may not have a substantial impact on reducing queuing delays. System designers should weigh the importance of reducing packet loss against the additional cost of adopting higher service speed cloud servers, depending on their specific requirements and constraints.

(c) Identify the best server combination to reduce cost below threshold while considering the queuing delay constraint.
To do the task, we performed the simulation similar to the last section with only adding 2 different type of edge servers (with different costs) to the system. Moreover, we defined the maximum operational cost equal to 150000 , the maximum average queuing delay equal to 1.5 and set f to 0.4 which is lower than 0.5. The code is modified to find the best combination (based on the lowest packet loss) of the servers with specifying whether it respects the maximum average delaying or not as the result is shown in Figure 6.
 
Figure 6. The best combination found by the code

(d) Compare cost and queuing delay for N Cloud servers versus N/2 Cloud servers, considering packets of type A and type B.
For the first part of this section of the task 4, we repeated the section c only removing 2 of the cloud server, hence performing simulation with 4 edge nodes and 2 cloud nodes.  The results shows