# Air Traffic Simulation Framework for Testing Automated Air Traffic Control Solutions +
## 3 Traffic Estimation Algorithm
### Area-Based Upgrading  
During the simulation, a specific region is designated for control operations, which may correspond to an entire FIR or a particular sector within it. This region is referred to as the \"inside area\". The \"outside area\" comprises the airspace beyond this boundary and is defined dynamically by extending the average distance an aircraft can travel within the user-selected prediction timeframe. This distance is computed by multiplying the average commercial aircraft speed by the timeframe parameter \(t_{E}\). A visual representation of the data refreshment process based on this spatial segregation is provided in Figure 4. At simulation start, the positions of all aircraft are initialized using real-world traffic data, which can be sourced either from live API or archived historical datasets. Following initialization, the estimation process overwrites the real aircraft positions within the specified timeframe to construct an estimated traffic demand scenario. As described in Section 2.3.2, this estimated traffic may serve as a sufficient output for certain applications. Alternatively, it may trigger control mode, as outlined in Section 2.3.3. In control mode, the positions of aircraft within the inside area are iteratively updated based on interactions with simulated ATCOs. As the simulation advances, these interactions increasingly diverge from the original traffic data, meaning that the inside area is no longer governed by real data, but instead reflects the effects of controller decisions and responses. For aircraft in the outside area, traffic is initially estimated using the same timeframe of \(t_{E}\) to project near-future positions, ensuring integration with the controller region. Once controller interactions conclude, the data for the outside area data can be refreshed using either live API data  
\begin{table}
\begin{tabular}{c c c} \hline
**Property** & **Type \({}^{*}\) & **Description** \\ \hline Timestamp & int & Unix timestamp (seconds) for the time of traffic picture. \\ \hline Callsign & string & Callsign of the aircraft. Can be null. \\ \hline Latitude & float & WGS-84 longitude in decimal degrees. \\ \hline Longitude & float & WGS-84 longitude in decimal degrees. \\ \hline Vertical rate & float & Vertical rate in feet/min. A positive value indicates that the airplane is climbing, a negative value indicates that it descends. Can be null. \\ \hline Flight level & int & Calculated from pressure altitude. \\ \hline Pressure altitude \({}^{**}\) & float & Barometric altitude in feet. \\ \hline Flight level \({}^{**}\) & int & Flight level of the aircraft. \\ \hline Wind speed \({}^{**}\) & int & Calculated by ADS-B Exchange [knots (kt)]. Can be null. \\ \hline Wind direction \({}^{**}\) & int & Calculated by ADS-B Exchange [\({}^{*}\)]. Can be null. \\ \hline Heading & float & True track in decimal degrees clockwise from north (north = 0\({}^{\circ}\)). Can be null. \\ \hline Velocity & float & Velocity over ground in m/s. \\ \hline Category \({}^{**}\) & int & Aircraft category. See API documentation [29]. \\ \hline ATC Approval & boolean & Whether the request is approved by ATC. \\ \hline \end{tabular} \({}^{*}\)Note: The data types listed in Table 2 follow common conventions used in computer programming. For clarity: int (integer): a whole number, positive or negative, without decimals; float (floating point): a number that may contain a decimal point; string: a sequence of characters or text; boolean: a binary value, either true or false. \({}^{**}\)Only available if ADS-B Exchange is used.  
\end{table}
Table 2: Definition of fields.  
(in which case the estimation must be recalculated, considering the updated timestamp (\(t_{E}\) adjusted for elapsed time)), archived data (which may eliminate the need for further estimation if accurate timestamps are available), or a simple interpolation can be used between the two nearest points.