# End-to-End Performance Evaluation of MEC Deployments in 5G Scenarios
## 3 Co-Simulation Based E2E Evaluation Framework
### Co-Simulation Framework  
Our co-simulation architecture enhances the one in ref. [31], based on a 4G network, and incorporates a 5G one. With reference to Figure 5, Simu5G and CoFluent are configured independently, each with its own models, configuration files and simulation workflows, and also run independently. Coordination is achieved via file exchange. Simu5G will simulate the 5G RAN, composed of a configurable number of UEs and BSs. Each UE runs an application client, modeling the behavior of the selected use case, and initiates service requests to the MEC infrastructure. Requests' data packets traverse the UL of the RAN and the CN and get to the MEC host. The latter generates responses and sends them back to the UE through the DL path. BSs can be either eNBs of gNBs depending on the considered deployment. The structure of the CN depends on the deployment as well. CoFluent instead simulates the CN and the MEC environment. Service requests coming from Simu5G are processed by the MEC host, through the UPF and the MEC app, and CoFluent generates service responses, which are  
Figure 4: MEC host model on CoFluentTM. then fed back to Simu5G. Note that Simu5G includes also a model of the EPC, which is not instantiated to avoid duplication. The two tools interact via file exchange as follows:  
1. We instantiate a scenario, complete with UE location and mobility, and we run it in Simu5G. In the latter, UEs will generate application-level messages, to be transmitted on the UL leg of the radio access network, destined to the collector. These messages will accumulate delay on their way up, due to user contention, protocol delays, channel quality impairments, etc. The traffic that arrives to the collector (i.e., that exits the RAN) leaves Simu5G as well. We timestamp the traffic, and we log both timestamp and message sizes to Logfile#1 file. More specifically, we log both the simulated time at which a message is generated at the UE, and the simulated time at which it reaches the collector. These times are expressed in Simu5G's units. 2. We run CoFluent, using Logfile#1 as an input. The MEC elements modeled in CoFluent process the requests generated by the UEs, and the MEC server generates replies accordingly. These replies will contain a payload, which depends on the traffic model used within CoFluent. These replies are sent back to the RAN. Similar to step 1, replies are timestamped and logged in the Logfile#2 file. In the latter, timestamps are expressed in CoFluent's units. During step 2, time is spent traversing the necessary MEC elements, e.g., queueing up at contention points. 3. We run Simu5G once more, using the same scenario as for step 1. More specifically, the UE location and mobility are the same. We now use Logfile#2 to generate the replies to be transmitted to the UEs using the DL leg of the RAN. As in step 1, replies accumulate delay due to interference, channel issues, congestion and protocol mechanisms. We note that file reads and writes are actually made in C++ within the co-simulation endpoints. This is done, however, only at the beginning (read) and at the end (write) of the simulation. This allows us to avoid unnecessary file-based operations during the execution of the simulations, thus adding a negligible overhead to the simulation performance. Another benefit of this approach is that it allows us to compute end-to-end delays (e.g., the round-trip time of a request--RTT) without having to synchronize simulated times in the two frameworks. In fact, the RTT can be computed as the sum of the delays incurred in steps 1, 2, and 3, each one of which is computed within a simulator. Thus, if messages keep track of the delay accumulated thus far, the RTT is obtained automatically at the end of step 3. Finally, using a file-based interaction allows us to obtain a co-simulation framework with minimal modification of the two involved simulators, and notably without any impact on their core functionalities. This last characteristic is particularly important in the perspective of upgradability.