Running a session

session, pause, resume and feedback act on the simulation as a whole rather than on one aircraft, so they need no callsign and ignore one in front of them.

What the values mean

On a replay the rate is a dial on real traffic rather than a setting. No field has a recorded replay at the moment, so this applies once one ships. Left out, the rate keeps the replay at its original pace, with the real arrival sequence and the real gaps between aircraft. Set above that pace it compresses the clock, and below it thins the traffic out while keeping the rhythm. session list prints the pace beside each scenario.

Rough guide for a three-position setup: 30 is comfortable, 45 to 60 is a busy peak, 90 is a stress test.

The rhythm modes

However high the rate, two aircraft through the same gate are never spawned closer than a safe in-trail spacing. Turning it up raises the flow rather than stacking aircraft on top of one another.

Choosing which gates the traffic comes from

A randomised session normally spreads your rate over every entry fix the direction serves, in the proportion real traffic uses them. Munich in the west feeds four: ROKIL and BETOS from the west, LANDU and NAPSA from the east.

You can name the gates instead, each with its own rate:

session start eddm random 26 rokil 20 betos 10

Twenty an hour over ROKIL, ten over BETOS, and nothing at all over LANDU and NAPSA. Naming any gate silences the ones you leave out, which is the point: two streams to merge is a different exercise from four, and one busy corridor is a different one again. The rhythm mode still goes on the end, and the 5 to 120 limit applies to the total you asked for across all the gates together.

A gate run that does not make sense is refused rather than quietly reinterpreted, and the reply says what is wrong with it:

• A fix the direction does not serve. The reply lists the ones it does.
• A fix where no arrival route begins in the direction you start. Its flights would carry an arrival route for the other runway direction, so it sends none.
• A fix with no flights behind it in the traffic pool.
• The same fix named twice.
• A rate that is not a whole number between one and the 120 the session as a whole is capped at.
• A rate the gate cannot deliver. Ask for more and you are told the ceiling, rather than being left to work out from the traffic that you are getting less than you asked for. The ceiling itself is approached to within about a percent, not to the last aircraft.

Every gate has a ceiling, because two aircraft through it are never spawned closer than the in-trail spacing. It follows from the speed traffic is handed over at, which is a property of the gate in the direction being flown rather than of the gate itself. At Munich the fast gates run at 56 an hour and the slow ones at 50, and which is which swaps with the direction: to the west (26) ROKIL and BETOS are the fast pair, to the east (08) LANDU and NAPSA are.

Where the traffic comes in

An arrival appears shortly before the point where the area controller hands it over to you, level at the handover level for that point and flying its route. It calls you straight away. It flies its route as far as its gate, or on along its arrival route to the handover point where that lies further in, and from there it holds its heading until you vector it.

At 23 of the airports the server serves, the handover points and their levels are the ones the IVAO divisions of Germany and Austria publish for handing arrivals from the area controller to approach. That is where sessions at those fields bring their traffic in; which fields ship traffic today is listed further down. Each flight is handed over at the first of those points its own flight plan crosses, at the level the agreement gives for the runway direction in use. Vienna hands Munich's south-east arrivals over at REDBU at FL140 or at AMADI at FL130, so a flight appears before whichever of the two its route files. A Frankfurt arrival via EMPAX appears before ADNIS on its arrival route, because that is where approach takes it over. At Munich the runway each gate's traffic lands on is preset too, because the network publishes it there.

How far before the point it appears is how early the frequency change comes. IVAO Germany has it at the latest two minutes or ten miles before the sector boundary, whichever comes later, so an arrival appears two minutes before its point, or ten miles where two minutes would be further. Munich's own page puts it ten miles before the boundary. The Austrian fields use the same rule, since no IVAO Austria document we found gives one. The server does not know where the sector boundaries lie, so it counts from the handover point, which usually sits near the boundary. At Munich that is a few miles late, because ROKIL, BETOS and LANDU lie inside the approach sector.

An arrival calls you as soon as it appears. At gates far out, that is sooner than it used to be, since arrivals used to wait until they were fifty miles from the airport.

Two arrivals never appear on top of each other. Where several arrival routes are handed over at one point, as Frankfurt's EMPAX and KISEK routes are at ADNIS, the second waits until the first has moved on.

A flight whose route crosses none of the points its gate is handed over at appears about ten miles before the gate, at the gate's level.

At an airport without researched agreements, the gates are the points the published arrival routes begin at, and the level is the one the chart publishes there when it gives a fixed level, an upper limit, or a lower limit of FL130 or more. Where it gives a lower limit below FL130, or nothing at all, traffic arrives at FL130, the level that comes closest on average to the agreements that are known. Where the chart gives no speed, traffic arrives at 250 knots. An aircraft is never placed above the highest level its type can fly. The message a session starts with says which source the field is using, and a randomised session also names the gates that arrive at FL130 because nothing is published there. It also names any gate that stays quiet because no observed arrival came through it in that direction, and any gate left out because no arrival route begins there in that direction. A gate with fewer different flights behind it than its share of your rate is named too. It sends fewer aircraft than you asked for, because a flight that is still in the air is not spawned a second time.

Where a field's arrival routes do not say which runway direction they serve, every gate is open in every direction.

Ending, freezing and reporting

session end is the clean wind-down: no new traffic, but everything airborne stays and is yours to work down, and the session closes itself once the last aircraft has gone. That holds while somebody who works the airport is connected. An ended session still ends by itself when nobody is, as described below. session delete is the hard stop, with pending spawns cancelled and session aircraft removed at once. Unassumed traffic that leaves every controller's range can still disappear before you have worked it down, as described below.

Sessions are kept per airport. Each command acts on the airport you name and leaves a session at another airport alone, session status answers with one line for every session that is running, and starting a session at an airport that already has one replaces that one. A server is set up to run traffic at a certain number of airports at once, two unless whoever runs it chose otherwise. Starting a session at one airport more than that is refused, and the refusal tells you the limit and which sessions are holding it, so you can end or delete one first. A session that has ended but still has aircraft to work down keeps its airport until the last one has left.

A session ends by itself once nobody who works its airport is connected. When the last controller for the airport leaves, the session has five minutes. If one of them connects again in that time, nothing changes. Otherwise its pending arrivals are cancelled, its traffic is removed, and the end is announced on the frequency the session was started from. A controller whose connection drops counts as gone too. If their Aurora goes quiet and stops answering the server, the server signs them off after about 45 seconds. Other radar clients have not been checked yet and can take up to about eight and a half minutes. So can a connection that drops in the few seconds after logging in, before Aurora has answered the server for the first time. Who else is still online makes no difference, so a controller working another airport neither keeps your session alive nor ends it. A position works the fields it is named after and the ones it covers alike, which means a Munich approach that covers Oberpfaffenhofen keeps an Oberpfaffenhofen session running.

An aircraft whose track has been assumed by a controller who is still online is the exception. It stays when its session ends and from then on belongs to no session, like an aircraft spawned by hand. Traffic worked without being assumed goes with the session, so assume what you are working. A session started while nobody who works its airport is connected runs on the same five minutes from the start, and the reply to session start tells you so.

Aircraft outside every controller's range disappear after five minutes. If nobody has assumed an aircraft and it stays outside the radar range of every connected controller for five minutes, the server removes it. This ends an arrival that nobody worked, which would otherwise keep its heading and fly on forever, and a track released into empty airspace.

The range is the one set in your radar client. In Aurora it counts from the centre of your radar screen, and that centre moves when you pan. Other radar clients have not been checked yet. So if you move your screen far away or set a small range, unassumed traffic can disappear. Assume the aircraft you are working.

An aircraft that a connected controller has assumed is never removed this way, however far away it is. If that controller disconnects, the aircraft counts as unassumed from then on. An aircraft that comes back into someone's range, or is assumed again, starts the five minutes over. Traffic that nobody has seen yet is left alone, so an arrival that appears beyond your range still reaches you. While the simulation is paused, the five minutes stand still.

Which fields the server has traffic for is a question of what it has been given rather than of what it can do. A randomised session at a field the server has nothing for says so instead of starting an empty one. Randomised sessions run at these fields today, each with the directions listed:

The traffic is real flights with the flight plans they filed, taken from days between 1 and 3 October 2026. Their routes were checked against the navigation data of the AIRAC cycle current then, and they are flown on whatever cycle the server has loaded. Each flight carries the route it filed on a day it landed in the direction you are running. The departure time on its strip is set to fit the moment the flight appears, as the time it left the stand, or for the few flights whose stand time was not recorded, as the time it took off. The elapsed time on the strip is the time the flight spent in the air that day. If that is too short for the moment it appears, the departure time is set so that the flight took off no later than the moment it appears. A direction in which no flight was seen landing in those days is refused at the start, and the reply says so. That applies to Hamburg 05, Cologne 06 and 24, and Vienna 29 and 34. There are no recorded replays at the moment, so session list <AIRPORT> answers that no sessions are bundled.

Friedrichshafen, and Hamburg in 15 and 33, have only a handful of flights behind each gate. Ask such a gate for more aircraft an hour than it has flights and it sends fewer than you asked for, and the message the session starts with names it.

pause freezes everything. Aircraft stop in place, no time passes, and resume picks up where it stopped rather than jumping ahead. It stops the traffic for every controller connected, not just yours, because separation between positions is shared. Anyone can do it, and it is announced on the frequency it was typed on. Sent in a private chat with SERVER, you are answered in that chat and the announcement goes out on the frequency your radar client reports. If it reports none, only you are told.

While the simulation is paused, an instruction to an aircraft, a session start or a spawn is refused. The reply names who paused it and since when, and asks you to type resume first. Nothing is held for later, so an instruction you typed against a frozen scope is not flown behind your back when somebody else resumes. session status says the simulation is paused and since when, which is the quickest way to find out when a scope you did not pause stops moving. delete, session end, session delete and feedback keep working while paused, and the confirmation of a report filed during a pause tells you the simulation is paused.

A pause does not outlive the last controller. When nobody has been connected for five minutes, the same clean-up that removes all traffic lifts the pause, so the next person to connect starts from a running simulation rather than one frozen by somebody who has gone. If you drop and come back within those five minutes, you find it exactly as you left it, paused and with your traffic in place.

feedback works with an aircraft selected, like pause. It was called report until September 2026, and report now asks an aircraft for information (see Requests), so a report typed on its own files nothing and tells you what to type instead. File it while the problem is still in front of you: the archive is cut at the moment you type the command. To file it without your frequency reading along, type .chat SERVER in Aurora and send it in that chat. The confirmation appears there too.