Single-spacecraft missions rarely surface scheduling conflicts as a first-order problem. You have a handful of contact windows per day, a single NORAD ID, and relatively predictable contact demand. Conflicts are edge cases. The moment you add a second spacecraft to the same orbital plane — or worse, two spacecraft in different planes both needing Ka-band downlinks — the edge case becomes routine. By the time you have five or more active spacecraft on a shared ground network, conflict management is no longer a scheduling footnote. It is a core operational function.
Why Conflicts Emerge: The Aperture and Slew Time Constraints
Each ground station antenna is a single physical resource. It can track one spacecraft at a time. An overlap conflict occurs when two spacecraft have visible pass windows at the same station at the same time, or when the slew time required to reposition from one contact to the next is insufficient to meet the second AOS.
Slew rate is a real mechanical constraint, not a software one. Az/El mount systems used on 3.7–7.3 m antennas typically slew at 3–10 degrees per second in azimuth and 2–6 degrees per second in elevation. After LOS on spacecraft A, the antenna must slew to the predicted AOS position of spacecraft B, acquire signal, and start recording. If the gap between LOS(A) and AOS(B) is 90 seconds and the angular separation between the two positions is 120 degrees, a 3 deg/s azimuth drive cannot complete the slew. The result is either a late AOS on spacecraft B or a missed contact entirely.
For a single station serving multiple operators, the slew time constraint creates a de facto exclusion zone between contacts. In practice, most network operators enforce a minimum inter-contact gap of 3–5 minutes on the same antenna to account for mechanical settling, RF configuration switching, and contact verification procedures. That 3–5 minute gap is antenna capacity that no one can schedule.
Priority Levels and What They Actually Control
Orbitvein's scheduler operates with three priority tiers for contact reservations:
- Mission Critical — time-sensitive contacts that cannot be rescheduled without mission impact. Typical use: emergency TT&C, single-orbit data downlink windows for time-critical imagery, scheduled conjunction avoidance maneuver command uplinks.
- Standard — routine data downlink and TT&C contacts. Most contacts in a healthy constellation operation fall here. Scheduling is best-effort within a ±15 minute window of the preferred AOS.
- Best Effort — speculative contacts for opportunistic capacity, secondary stations, or lower-priority payload data. These are the first to be bumped when a higher-priority conflict arises.
Priority levels affect two distinct scheduling decisions: initial slot allocation (higher-priority requests get first access to contested windows) and pre-emption (what happens when a Mission Critical contact is submitted after a Standard contact is already reserved in the same window).
Pre-emption: When It Applies and What Triggers It
Pre-emption is the most operationally sensitive part of a multi-operator scheduling system, and it is worth being precise about when it is and is not invoked. A pre-emption event occurs when a Mission Critical contact request is submitted for a window that is already reserved by a Standard or Best Effort contact from the same or a different operator.
The affected operator receives a conflict notification through the API (a schedule.conflict_detected webhook event with the pre-empted contact ID, the reason code, and a list of alternative windows). The scheduler simultaneously runs a re-optimization pass to find the best available alternative slot for the pre-empted contact within a ±90-minute window of the original. If an alternative is found, it is proposed automatically; if not, the pre-empted contact is placed in a pending queue and the operator's mission ops team is notified.
We are not saying pre-emption is uncommon in busy network periods — during high-activity windows like post-launch commissioning for multiple customers, pre-emption events do occur. The key design principle is that pre-emption is deterministic and auditable: every affected contact gets a notification with a reason code and a re-schedule proposal, never a silent cancellation.
Greedy vs. Optimization-Based Scheduling Approaches
Two broad classes of scheduling algorithm appear in operational ground networks. Greedy algorithms process contact requests in arrival order: the first request gets the best available slot, the next request gets the best remaining slot, and so on. This is fast and simple to reason about, but it produces suboptimal global allocation when contact requests arrive in bursts — common at the start of a planning period when operators submit 24-hour contact plans simultaneously.
Integer linear programming (ILP) schedulers consider the full set of pending requests before committing any slots, minimizing a weighted cost function that accounts for priority, contact duration, altitude-dependent window quality, and station capacity. The output is a globally better schedule, but at the cost of higher computational complexity and a longer time-to-first-response for the operator.
Orbitvein's engine uses a hybrid: greedy initial allocation for real-time single-contact API requests (sub-second response time), followed by a periodic ILP re-optimization pass over the rolling 24-hour window every 30 minutes. The re-optimization may revise slot assignments for pending Best Effort contacts to improve overall throughput, with notifications to affected operators. Mission Critical contacts are never moved by the re-optimization pass once confirmed.
Partial Pass Acceptance and Contingency Windows
Not every conflict can be resolved by moving a contact to a different slot. Sometimes there is no equivalent alternative window within the operator's acceptable timeframe. In these cases, partial pass acceptance becomes relevant: a contact that was planned for 8 minutes at high elevation may be trimmed to 4 minutes at the available uncontested portion of the window.
For bulk X-band data downlink, 4 minutes at 7.3 m aperture at a 45° mean elevation still delivers substantial data — depending on the modcod selected, this can represent 8–12 GB of transfer even at a partial contact. The tradeoff is that the mission ops team needs to plan for variable contact durations in their downlink scheduling rather than assuming fixed 8–10 minute windows.
Contingency windows address a different failure mode: what if the primary station has a hardware issue or maintenance conflict at contact time? Operators at Orbitvein's Constellation tier can configure a secondary station contingency for any Mission Critical contact. The scheduling engine pre-computes the pass geometry for the backup station for the same orbit window and holds that slot in soft reserve. If the primary contact proceeds normally, the reserve slot is released 15 minutes before its AOS. If the primary contact fails, the backup slot activates automatically and the operator's API receives a contact.station_failover event.
Practical Setup: Multi-Spacecraft API Configuration
For operators managing three or more spacecraft on the same account, the scheduling API accepts batch contact requests in a single JSON payload. The priority field on each request object accepts values mission_critical, standard, or best_effort. Requests without an explicit priority field default to standard. The response includes a per-contact allocation status and, for any unresolved conflicts, the proposed alternative windows ranked by combined score of elevation quality, station G/T, and proximity to requested AOS time.
The practical recommendation for growing constellation operators: submit your 24-hour contact plan as a single batch request at the start of each UTC day rather than submitting contacts individually throughout the day. Batch submission allows the ILP optimizer to run across all your spacecraft simultaneously, producing a globally better allocation than sequential greedy requests would generate — particularly when your spacecraft pass the same station within minutes of each other.