## 4 Analysis of the Experimental Results
### Analysis of Latency and Jitter for MPC  
In the first experiment, the performance of MPC is evaluated in terms of latency and jitter. The performance is evaluated for scenarios with packet sizes of 32 bytes up to 1500 bytes to cover both URLLC and enhanced mobile broadband 5G classes to understand how the packet size impacts the fronthaul latency. UDP packets, thus, with different sizes, are injected into the PDCP layer in the (CU + DU) entity in every frame. The protocol stack processes the packet then the MAC encodes it to \(n=4\) encoded blocks and transmits them on the fronthaul. The latency is measured as the RTT as explained in Section 3.2. The percentiles and probability density function results of the RTT are shown in Figures 5 and 6, respectively. Figure 5 shows the results for different percentile values of the latency as a function of UDP packet size. In general, as the UDP packet size increases, the percentile values of latency increase too; this is because larger packets take longer to be processed. The RTT for a packet size of 100 bytes is, however, less than that for the 32 bytes and 50 bytes packet  
Figure 5: Percentile of latency on the Ethernet-based multi path fronthaul as a function of different packet sizes. sizes. The reasoning behind this behaviour is that the packets of 32 bytes and 50 bytes are split by the coding block in the (CU + DU) entity to 16 bytes and 25 bytes, respectively. Even when the overhead header is added, the two packet sizes are still less than the minimum 64 bytes of the Ethernet frames. Therefore, prior to transmitting these packets, padding is added by the Ethernet network card, which adds an extra delay to their RTT. Figure 5 shows that MPC provides promising results, as 95 th percentile values remain below the maximum acceptable fronthaul latency for the MAC-PHY split. Figure 5 also shows that the 25 th, 50 th and 95 th percentile values are of low variability as they are close to each other. The difference between the 95 th and 25 th values is 8 us. Focusing on the 50 th percentile result, if the packet size is less than 500 bytes, the increase in latency is low and is around 4.43% from the packet size of 32 bytes to the packet size of 250 bytes. On the contrary, with packet sizes larger than 500 bytes, the increase in latency is 26% for a packet 3 times larger than 500 bytes. Such behaviour can be observed in Figure 6, whereby the probability density distributions of packet sizes from 32 bytes to 250 bytes are very close to each other. However, for packet sizes ranging from 500 bytes to 1500 bytes, the probability density distributions are further apart. Another observation from Figure 6 is that the standard deviation increases with the size of the packet. For example, for packets of size 1500 bytes, the deviation is 10 us, which is approximately two times as large as for packets of size 32 bytes. This indicates that the larger the packet size, the higher the variations in the processing time of the protocol stack, encoder/decoder and transport network. This plot provides insight into how to choose the packet size to be transmitted on the fronthaul. For example, if the probability density distribution of the latency for a service should have a deviation of less than 8 us, then the choice of packet size \(\leq\) 250 would satisfy the requirement. It can be concluded from Figures 5 and 6 that the average latency complies with the requirements of 3 GPP, that is, staying below 250 us [14]. Further analysis of jitter can be found in Figure 7. Two factors primarily introduce jitter:  
1. the packet switch network, which can introduce variation into the packet delay when processing packets; (ii) the operating system, whereby the variation of system daemons and interrupts results in jitter. From Figure 7, it can be seen that the distribution of jitter remains the same for different packet sizes and is just below 2 us. The tail latency of Figure 7 shows that latency values greater than 10 us have a very low probability that is close to zero.