## 4 Performance Analysis and Discussion
### Latency Measurement
As \(t_{1,2}\), \(t_{2,3}\), and \(t_{total}\) involve two-way transmission, the acceptance criteria were defined as a double of the threshold set by [PERSON], [PERSON], [PERSON], [PERSON], [PERSON], and [PERSON] [34], i.e., 1000 ms. The boxplots of the latency values are provided in Figures A1-A6 in Appendix A. A 95% confidence interval of the results with specified lower bound and upper bound was constructed to demonstrate the system robustness. As such, the 95% confidence intervals of the KPIs for the take-off and climbing phase, en route cruising phase, and descent and landing phase are presented in Table 4. In general, the results demonstrated convincing performance in latency as the upper bound of the 95% confidence interval of \(t_{total}\) did not exceed the acceptable threshold at 1000 ms. This indicates that one can have 95% confidence that the latency value will not exceed the upper bound specified in Table 4. Furthermore, as \(t_{1,2}\) accounts for nearly negligible impact in latency, it is evident that the use of wireless connection settings is acceptable. Most importantly, the connection between aircraft and ground ATC centre is also wireless, and the current setup also retains such a feature. Interestingly, compared to the data visualisation delay \(t_{2,3}\), the network delay \(t_{1,2}\) was nearly trivial. Therefore, we can prove that the major source of latency is not a result of network delay. This phenomenon may be caused by the data processing time and refresh rate constrained by the user interface of BlueSky. The data request process is only a two-way byte stream transmission process without complicated manipulation. Compared to the data request process through \(SimConnect\), the data parsing process from the data request application to BlueSky incorporates data input from the data request application, \begin{table}
\begin{tabular}{c c c} \hline \hline
**Timestamp** & **Notation** & **Description** \\ \hline
1 & \(t_{1}\) & The flight parameter data request is sent out by W-ATCOs \\
2 & \(t_{2}\) & The flight parameter data are returned to W-ATCOs \\
3 & \(t_{3}\) & The flight parameter data are visualised and displayed on the radar map \\ \hline \hline \end{tabular}
\end{table} 
Table 2: Timestamp snapshotted for latency measurement. \begin{table}
\begin{tabular}{c c c} \hline \hline
**KPI** & **Description** & **Equation** \\ \hline \(t_{1,2}\) & Time elapsed for wireless data transmission & \(t_{2}-t_{1}\) \\ \(t_{2,3}\) & Time elapsed for flight parameters passing procedure and & \(t_{3}-t_{2}\) \\ \(t_{total}\) & Total time elapsed for a data request to be processed & \(t_{1,2}+t_{2,3}\) or \(t_{3}-t_{1}\) \\ \hline \hline \end{tabular}
\end{table} 
Table 3: Key performance indicators of system’s latency. passing the work to the second thread, control command executing, parsing data back to the main thread, and eventually executing the command. Therefore, the instantaneous computational load of the client for the second process would be significantly higher than that of the data request process. Hence, with the raised computational load for the client, the time spent on data visualisation is longer. Additionally, the refresh rate of BlueSky would limit the data input process from the data request application. It is noted that the ranges of mean values of \(t_{total}\) for 1 Hz and 6 Hz were 457-540 and 100-107, respectively. This implies that the range for the 1 Hz data request frequency was around four to five times that of the range of the 6 Hz data request frequency. As the data request application would only trigger the data input, the visualisation refresh rate is independent of the data request application. In addition to the refresh rate, the executing time of the code can cause a minor deviation of the refresh rate timer of BlueSky. As the final visualisation time is measured, the deviation may be coupled with the latency resulted from the data processing time. This phenomenon was more commonly seen when the data request application was running at 1 Hz.