The POSCON Air Traffic Control System is a large departure what can be found on legacy networks. Over the past few years, our Facility Data Team has working hard to develop and upload airspace volumes to the server. As a result of the server now being aware of these volumes, it can effectively use them to analyze routes, sector ownership, handoffs, CPDLC, traffic management, and other complex interactions. Currently, we have the entire United States on the server and many other foreign countries as well. Why does server airspace awareness matter to the average controller? Here are a few important understandings controllers must have:

1. The server handles the tracking of aircraft, not the client software.
   When you sign onto a position, you are simply letting the server know that you wish to take ownership of that sector and any other sectors that combine to it. This is hugely advantageous if you accidently get disconnected from the server. If this happens, all you have to do is sign back into the sector you were working and all of the aircraft that you had tracked prior to the disconnect will still be tracked.
    
2. The server automatically combines airspace based on the configurations set by Facility Data Specialists.
   In the facility data, sectors can configured to pair to another sector in the event that sector is not owned or assumed by another controller. This "combined-to" logic typically starts at the Clearance Delivery being the lowest level and Center being the highest.
    
3. The server evaluates aircraft positions and automatically assign squawk codes from ranges specific to the FIR/ACC/ARTCC the aircraft are in.
   On legacy networks, squawk code ranges are created in files and distributed to users as part of the client package or often a separate download. On POSCON, the ranges are configured by Facility Data Specialists and then are automatically invoked when flight plan is filed or when a controller requests a squawk code.
    
4. The server knows where the aircraft will be in the future based on trajectory analysis.
   The server evaluates aircraft trajectories and can predict where a they will be in the future. While this feature is not currently being used, it will be very useful in the future when we implement auto-handoffs and traffic management software.

There are regions surrounding each ARTCC/FIR that define the extent of coverage of that ARTCC/FIR. These regions are defined on the server and configured by network administration at the time the ARTCC/FIR is first created.

• Surveillance Area of Interest (Surv AOI)
  This defines the area around an ARTCC/FIR where aircraft will be displayed to ATC. This area essentially filters all other network traffic and only shows relevant targets within range of that particular ARTCC/FIR. It is depicted as the gray rectangle in the image below.
• Aircraft Problem Detection Area (APD)
  This boundary defines the area within which the controller receives conflict probe alerts. It is depicted as the purple boundary in the image below.
• Flight Planning Area of Interest (FP AOI)
  This boundary is an adapted area outside the Center Boundary where Flight Plan (FP) data is available from other ERAM facilities. It is depicted as the green boundary in the image below.
• Area of Responsibility (AOR)
  This boundary is also known as the Center Boundary. It is depicted as the red boundary in the image below.