# A QoS-Enabled Medium-Transparent MAC Protocol for Fiber-Wireless 5G RAN Transport Networks
## 4 Results  
In order to assess the performance of qMT-MAC and its ability to combine CEXP, EXP, and BE flows, while maintaining the strict Fronthaul standards, a performance evaluation based on the OMNET++ simulator [31] was carried out. The evaluation was performed against the SoA gMT-MAC protocol in order to assess the improvement with respect to throughput, delay, delay jitter, and packet drops for X-Haul traffic patterns falling under the CEXP, EXP, and BE categories. The network setup follows the schematic of Figure 1, while the full simulation specifications are presented in Table 2.  
Figure 6 displays the performance evaluation of qMT-MAC vs. the SoA gMT-MAC protocol for three CEXP flows vs. fiber length. The three combined CEXP flows have IFG 4 (normalized load 25%), IFG 8 (normalized load 12.5%), and IFG 16 (normalized load 6.25%), respectively, totaling an aggregated load of 43.75% at the network. Normalized load corresponds to the produced payload as a percentage of the Channel Bit Rate, i.e., a 0.1 normalized load corresponds to payload generation equal to 10% of the Channel Bit Rate, etc. As our work targets dense urban environments, the tested fiber length ranged from 1 km up to 10 km, with a step of 1 km. As can be observed in Figure 6a, throughput was always constant, as expected from CBR traffic sources, and both qMT-MAC and gMT-MAC achieved similar performance in terms of throughput, managing to steadily output all incoming CEXP traffic flows. However, examination of Figure 6b reveals that the two protocols exhibited different behaviors in terms of average packet delay and delay jitter of the latter. In the case of qMT-MAC, delays for all three flows exhibited a linear increment with fiber length as the propagation delay adds a constant delay of 5 us per km. In all tested cases and for fiber lengths up to 10 km, all three CEXP flows exhibited delays that \begin{table}
\begin{tabular}{c c} \hline \hline
**Parameter** & **Value** \\ \hline Speed of light in fiber & \(2\times 10^{8}\) m/s \\ RAU range & 50 m \\ Air propagation delay & 0.2 μs \\ Bit rate per wavelength & 1 Gbps \\ Data packet size & 1512 Bytes \\ ID packet size & 72 Bytes \\ POLL packet size & 72 Bytes \\ ACK packet size & 16 Bytes \\ Fiber length & 1–10 km \\ \hline \hline \end{tabular}
\end{table} 
Table 2: Simulation parameters. consistently remained lower than the target value of 100 us set by the eCPRI standard. By means of Figure 6b, it can also be seen that flows with higher IFGs (lower load) exhibited higher delay compared to the flows with lower IFG values (higher load). This is due to the CEXP-Fit algorithm utilized in qMT-MAC, which prioritizes flows with a lower IFG (higher load) while shifting each flow with a lower IFG by one packet transmission delay, thus attributing a constant delay difference amongst each flow. The simulation results also showed that in the case of qMT-MAC, the delay jitter for all three CEXP flows was always zero, again meeting the strict requirements set by the eCPRI standard. This is due to the fact that in qMT-MAC, CEXP flows have reserved slots in the PS, and therefore, the protocol manages to guarantee service delivery at a stable rate, while respecting the strict delay and delay jitter requirements. In the SoA protocol gMT-MAC, however, we noticed that average delay values increased faster with added fiber length, while the rate of increment depended on the IFG value, i.e., the load of the flow. Specifically, we observed that CEXP flow with IFG 4 (normalized load 25%) increased faster with fiber length as opposed to CEXP flow with IFG 8 (normalized load 12.5%), which in turn increased at a faster rate than the CEXP flow with IFG 16 (normalized load 6.25%). This was attributed to the fact that the longer fiber lengths led to a higher SF duration, which in turn allowed for more packets to be generated by each node before the start of the next SF. As more packets reside in the node buffers, it took more time for these packets to reach the head of the queue, thus increasing the average packet delay.