## 5 Performance Evaluation of MEC B5G Cellular Networks
### Proof-of-Concept Description  
The experiment field structure is shown in Figure 10. The outdoor PoC field was constructed at the Tokyo Institute of Technology, Ookayama campus. As the 5G environment, multiple RUs were deployed for n77/n257 frequency bands and one LTE sector was deployed for various kind of applications. Table 2 shows hardware equipment and radio information, such as the frequency of each RU. 4G uses 5 MHz channel bandwidth (UL: 1825-1830 MHz, DL: 1730-1735 MHz) in Band 3 (FDD), while 5G bands are prepared in both Sub6 n77 (TDD, 3.8-3.9 GHz) and mmWave n257 (TDD, 27.0-27.4 GHz). In the case of the mmWave band, 400 MHz Bandwidth, i.e., 4 CC (4 \(\times\) 100 MHz Component Carrier), was assigned to the downlink, while that for the uplink was 100 MHz Bandwidth, i.e., 1 CC (1 \(\times\) 100 MHz CC). As a network connection, Edge Cloud was defined from after Fronthaul to before the Internet Security Getaway. 4G/5G of RAN (vDU/vCU) was deployed in the Edge cloud, and MEC and Apps that could be capsulized by GTP of User Plane were prepared. In addition, a cloud vApps server was prepared on the cloud side. In the vApps, iperf3 software was installed to compare the communication performance of MEC and cloud. As a user equipment terminal, a 5G-compliant Rakuten Big s [68] was used. Its local App can specify IP for Iperf3 of vApp in MEC and register itself in DNS for Iperf3 of Apps in cloud. Each of those settings can be confirmed by connecting with the specified Name. In addition, 4G was used for C-Plane signalling, and measurement was performed based on conditions in a state where PDU session establishment was completed. In other words, PoC measurement starts from UE connection establishment, and does not take into account the latency imposed by the attach procedure or any handover scenario. This is why only a stational terminal was involved in the PoC and the measurement was performed in a static condition, as the main purpose of this PoC was to verify how essential and efficient the use of 5G MEC is for Private/Local Operators scenarios from the user plane performance standpoint. This PoC field coverage could be expanded by additionally deploying more RUs to fully support the 5G area. Regarding the connections of the terminal, a PC was connected to the terminal via USB3.0 and the log information of the terminal was collected via XCAL [69]. With this measurement tool, it is possible to acquire information such as RSRP, each protocol sequence, physical/MAC layer information, and wireless throughput. The captured data can be combined and analyzed using XCAP [70]. Performance tendencies with different network configuration for fronthaul/backhaul will be investigated separately. For measurement, the application deployment location (either MEC or Cloud) is determined by the objective function in order to minimize the cost that satisfies the latency conditions. End users would like to select the more inexpensive computation environments. Here, the cost model based on [28] was calculated by numerical analysis conducted with the actual field measurement results. The actual results in the testbed field were obtained by measuring the performance on the RAN side using XCAL. Meanwhile, the logic of judgment needs to be added in the MEC/Cloud Orchestrator, as shown in Figure 3. In this paper, we explain how to determine the minimum latency. The latency on the MEC side can be determined by the computing process, because it is assumed that the MEC will be deployed on the RAN side. Regarding to the latency imposed on the cloud side, it is necessary to consider two kinds, namely, backhaul network bandwidth and computing processing. The cloud side needs to evaluate both the latency effect and cost increase, whether the network bandwidth or computing resource is added. The MEC latency \(t_{k,j}\)[28] is expressed as  
\[t_{k,j}=\frac{\alpha_{k}w_{k}}{N_{\text{MEC}}f_{k,j}}+\epsilon_{j},w_{k}= \delta b_{k} \tag{1}\]