Skip to content

Temporal Contact Scheduling

Scheduling protocol — instantiates Spanning Connectivity Formation

Makes a network spannable through time by scheduling intermittent contacts so a time-respecting sequence of links carries flow across the whole domain within the deadline — even when the links are never all up at once.

Temporal Contact Scheduling is the mechanism for networks whose links exist only intermittently — satellites drifting into view, ferries on a timetable, people meeting, trucks in transit. Such a network is never fully connected at any single instant, yet flow can still cross it if links activate in the right time order: hand off to a relay now, and it delivers when its own window opens later. This mechanism arranges those contact windows so a time-respecting path spans the target domain within the required horizon, and measures how much of the domain is reachable in time. It is the only sibling where connectivity is a property of timing rather than of topology — where the question is not "is there a path?" but "is there a path whose hops occur in the right order, soon enough?"

Example

A science probe cannot see Earth directly. It hands its data to a relay orbiter, which hours later comes into view of a ground station and downlinks it. At no single moment does an end-to-end link exist — connectivity is assembled from a sequence of scheduled contacts. Temporal Contact Scheduling lays out the visibility windows and the store-and-forward hops so every packet reaches the ground within its deadline, holding data at intermediate nodes until the next usable window opens, and reports the fraction of the network reachable in time. A domain that is instantaneously disconnected is nonetheless spanned across the horizon — the standard pattern of delay-tolerant networking in deep-space and satellite systems.

How it works

  • Map the contact windows. Record when each link is actually available; availability, not mere adjacency, is the raw material.
  • Find time-respecting paths. Look for hop sequences where each link's window comes after the previous hop has delivered — ordering, not just connectivity, decides what is reachable.
  • Schedule store-and-forward. Arrange for flow to wait at intermediate nodes for the next usable window, bridging gaps that no single link spans.
  • Measure temporal reachability. Report the share of the domain reachable within the deadline, which can be far smaller than the static topology implies.

Tuning parameters

  • Horizon / deadline — how long a time-respecting path may take; a longer horizon reaches more of the domain but delays delivery.
  • Scheduling stance — fixed pre-planned windows (predictable, rigid) versus opportunistic seizing of contacts as they arise (flexible, uncertain).
  • Buffering depth — how much flow can wait at intermediate nodes for the next window; more buffer bridges longer gaps.
  • Window prioritization — which scarce contacts to reserve for high-priority flow.
  • Time-path redundancy — how many alternative time-respecting routes to keep, in case a contact is missed.

When it helps, and when it misleads

Its strength is extracting spanning connectivity from links that are never simultaneously up — often the only way to connect an intermittently-linked domain — and making the timing constraint explicit instead of assuming a static graph. Its failure mode is mistaking static connectivity for temporal connectivity: a path that exists in the time-flattened graph may have no valid ordering, so the network looks connected while nothing actually gets through in time, and a single missed contact can break the whole chain.[1] The classic misuse is planning on the aggregated topology and discovering only in operation that the windows do not line up. The discipline is to verify reachability on the temporal graph against the deadline, and to keep redundant time-paths so a missed contact does not sever the domain.

How it implements the components

Temporal Contact Scheduling fills the timing side of the archetype's machinery — the components that make reachability a question of when, not just whether:

  • temporal_contact_window — it records when each link is available, the raw material every schedule is built from.
  • reachability_coverage_metric — measured here as temporal reachability: the fraction of the domain reachable by a time-respecting path within the deadline.

It does not build the physical links themselves (candidate_activation_set — Link-Activation Program and Mesh-Link Deployment), map the static topology and its components (Connected-Component Scan), or translate incompatible formats (Interoperability Adapter Rollout).

Notes

Static connectivity does not imply temporal connectivity, and the gap between them can be large: a network that a topology map shows as fully connected may have no schedule that delivers anything within the deadline. That divergence is the whole reason this mechanism is distinct from the topology-based siblings — a reachability test on the aggregated graph will pass while the domain remains, in practice, unreachable in time.

References

[1] A time-respecting path is a sequence of contacts whose times are non-decreasing along the path, so information can actually traverse it. Reachability over such paths — the subject of temporal-network and delay-tolerant-networking analysis — can be far more restrictive than reachability on the same links flattened into a static graph. ↩