Spacetime is a new twist on a Software Defined Network controller.  Whereas contemporary SDN controllers can only orchestrate the layer 3 network control plane (routing), Spacetime is capable of orchestrating the present and scheduled network control plane across layer 1 (physical link topology), layer 2 lower MAC (transceiver/air interface configuration), and layer 3 (routing).  We refer to this concept as Temporospatial SDN in academic literature; it reflects the fact that the controller’s information base must contain the ability to propagate the future motion of the physical platforms in order to model the candidate wireless link topology, to orchestrate that topology, and to compute routing paths across space and time.

‍

In addition to these layer 1-3 control plane functions, Spacetime is also capable of monitoring network telemetry (like signal quality and traffic congestion) for the purposes of network resource optimization.  It also exposes key metrics (like present and forecast fulfillment of service level agreements, comparisons of signal quality vs digital twin estimates, etc.) to facilitate automated alerting by external incident response and management systems.

‍

Aalyria’s primary target customers for Spacetime are those commercial and public sector organizations charged with operating communications network infrastructure – especially ones with mesh networks that incorporate steerable directional wireless communications.  These include commercial and military satellite network operators, earth observation and intelligence community satellite constellation operators, HAPS and airborne mesh network operators, maritime mesh network operators, terrestrial network operators employing millimeter wave and optical technology in integrated access and backhaul networks, and civil space exploration agencies.

‍

However, the network effect of Spacetime and the Federation model provides secondary benefits to organizations and enterprises even when they do not have any such infrastructure under their control. See “What if some/all of the satellite payloads are out of our control?” below.

‍

An instance of Spacetime can incorporate networks outside your control, supports automated network switching,  and can even support the automated brokering of dynamic interconnections with and across these networks – while simultaneously performing the complete control and optimization of any assets you fully control.  Each instance can mix and match assets and networks across the following tiers, which are listed and described in increasing order of capability afforded to the customer:

‍

(1) Basic: Like contemporary SD-WAN solutions, Spacetime can monitor key performance metrics for network services that transit networks outside of your control and reactively switch networks when necessary.  It does not need any information for this basic tier.

‍

(2) Enhanced: By adding to Spacetime any available information about the satellite orbits, transmitter and receiver chains, and antenna gain patterns, Spacetime can predict impacts caused by weather, terrain obstructions, potential jamming threats, and other disruptions – proactively switching connections for seamless continuity.  It can also proactively forecast disruptions to mission / customer end-to-end service requirements before they even occur.

(3) Federation: Buyers of satellite capacity can compel commercial satellite operators to add support for the open-source Federation API, even if they aren’t using Spacetime to orchestrate their networks.  A number of the largest commercial satellite network operators have already selected Spacetime to orchestrate their production networks, which natively supports the Federation API.  When these networks choose to share information with your network via these open APIs, Spacetime can dynamically broker connections across their networks in real-time, offering unparalleled flexibility and responsiveness.

(4) FullControl: For first party network infrastructure, Spacetime can directly orchestrate everything – satellites, ground stations, user terminals, etc. – for complete control and optimization.

‍

Contemporary SD-WAN solutions ignore that the physical wireless links and paths across the underlying networks are constantly changing. In reality, the commercial satellite providers have provisioned their network around certain expectations about the geographic locations and statistical distribution of demand – all based on the static procurement contracts and service level agreements they’ve signed with their customers.  These expectations determine the operators’ static schedule of beam handovers, management of satellite payload resources, and paths across their network.  SD-WAN solutions only attempt to sense the health and current performance of these paths and automate switching between commercial providers.

‍

This approach has its limitations. To illustrate them, consider a LEO constellation like SpaceX Starlink/Starshield configured to provide services to their static prediction of the statistical demand from a population of user terminals registered in known locations (labeled UT in the diagram below).

‍

In this example, SpaceX has configured their network expecting some statistical demand from US DoD customer terminals in configured geographies.  But, what if a US DoD customer terminal has a sudden mission requirement to log in from an unexpected cell / geography – one where SpaceX has not configured their network to expect a log-in?  Or what if it’s in an expected location; but, the customer has a mission constraint that requires transit through a certain POP to a private network instead of the Internet?  Or what if the US DoD mission requirements exceed the link layer capacity of the spectrum resources assigned to the cells – or the available capacity through ISLs and GWs, given competing flows?  SD-WAN cannot even attempt to solve such problems.

‍

Supporting these requirements requires the SATCOM provider to modify the way they are orchestrating their network.  Until now, typical turnaround times for a customer to ask a SATCOM provider to support such needs (for example, to provision a new beam in a new geography) would typically involve a human <> human request between the customer <> provider and then, once understood and approved, a human-in-the-loop network operations task to reconfigure the provider network. This would take hours or days. Those are not tactically responsive timeframes.

‍

In order to reduce this timeframe to mere seconds, three things are needed:

1. The SATCOM provider needs access to a technology capable of intent-driven, automated orchestration of the network topology, radio resource optimization, and routing within seconds of new requests.
2. The customer network (in this example, the US DoD) needs to compel the provider to implement open APIs that expose the candidate points of interconnection (ingress) and candidate reachable destinations (egress) and accept requests for on-demand network transit.  Note that the provider does not need to expose anything about the inner workings of their network.
3. The customer network (again, in this example, the US DoD) needs access to a technology capable of modeling the time periods when interconnection with the provider’s ingress points is possible.  For wired interconnections, this is trivial.  It’s also fairly straightforward for anyone to build software to model the time periods when a government-managed terminal has an unobstructed field of view of provider satellites. For interconnections from and between airborne terminals, maritime terminals, and in-space interconnections (e.g., between SDA PWSA and commercial LEO across SDA-compliant optical communication terminals), this is non-trivial.

‍

Spacetime fulfills all three of these needs.

‍

Yes, it is production-ready TRL9 infrastructure with a strong flight heritage.

‍

Spacetime ran a dynamic mesh network of high-altitude platforms with motion and conditions far less predictable than those of traditional satellite provider platforms and provided resilient connectivity to real-world commercial users in dynamic real-world conditions for three continuous years.

In that period of production operation, Spacetime’s core technology overcame challenging technical hurdles that exist in this space. Orchestrating the Loon network was in many respects more complex than even the largest proliferated LEO constellations: the motion of its platforms was far less predictable than the orbital ephemerides of traditional satellites, and the frequency bands of Loon’s mesh and backhaul network (E-band) are some of the most susceptible to rain and atmospheric conditions that exist. In spite of those challenges, Spacetime (known previously as "Minkowski" or the "Loon SDN" while in earlier stages of development at Google) autonomously operated and orchestrated these networks in production for years, serving hundreds of thousands of users across multiple continents.

The following references are available to substantiate the flight heritage:

• SDN in the Stratosphere: Loon's Aerospace Mesh Network [peer-reviewed paper]
• The Loon Library: Lessons from Building Loon’s Stratospheric Communications Service [“Minkowski” is discussed on pp. 207-215]
• A comprehensive dataset consisting of internal state from Spacetime and network telemetry gathered from years of serving commercial traffic and R&D experiments.

In addition, Space Systems Command (SSC), in collaboration with the Defense Innovation Unit (DIU) and the Naval Research Laboratory (NRL), successfully completed on Dec 7, 2023 a significant live on-orbit demonstration of Aalyria's Spacetime network orchestration software platform. This event represented a pivotal moment in the evaluation of the Spacetime platform's operational readiness by including familiar equipment and service providers (OneWeb, Viasat, iDirect, Kymeta, SpaceX, Viasat, and Comtech) as part of a comprehensive assessment of use cases where satellite payloads were outside of its control.

‍

Yes.  Several of the largest commercial SATCOM operators have already publicly announced long-term agreements to use Spacetime in their production networks.  See official press releases from Intelsat (for GEO and future NGSO), Telesat (LEO), and Rivada (LEO).

‍

The screenshot below shows one of the LEO mega constellations being operated at full scale in a real time emulation as visualized through the Spacetime NetOps User Interface.

‍

‍

Spacetime does allow human network operators to manually override its optimization engine to administratively “pin” use of a link or path.  In our own use of Spacetime in production networks, this feature was rarely used (for example, to prevent switching to a more optimal link to allow engineers time to debug a rare reoccurrence of a difficult to reproduce issue).  

‍

Spacetime was, however, designed to fully automate the tasking & scheduling of non-terrestrial networks; the growing adoption and incorporation of non-geostationary orbits, weather-sensitive communications bands, and multi-hop communication paths (inter-satellite links and in-space relays) are making it wholly impractical for human operators to manually schedule such networks on tactically responsive timeframes.  

‍

Our model of network operations is based around a human-on-the-loop, rather than a human-in-the-loop, operational support model.  Spacetime’s web based Network Operations User Interface (NetOps UI) provides human operators with situational awareness and a common operating picture of the network across all domains.  It also provides contextual mapping between geospatial (physical) and logical (networking) views across the past, present and future scheduled states.  URLs embedded into the alerts generated in external incident response and management systems allow human operators to jump directly into the relevant views in the NetOps UI to rapidly gain the context necessary to troubleshoot operational issues.

‍

No. Spacetime only exchanges network control plane messages with software “agents” that anyone can build and install on the network nodes – or via adapters to heritage ICDs (e.g., element managers). None of the data plane traffic flows through Spacetime.

‍

No; we’re able to elastically scale Spacetime to support very large networks (e.g., Telesat LEO Lightspeed, Rivada Space LEO).  Aalyria provides dedicated instances of Spacetime as a hosted, managed Software as a Service (SaaS) on the customer’s preferred Kubernetes-based compute cluster, which can support auto-scaling (i.e., on Google Cloud, AWS GovCloud, or AWS Secret and Top Secret Region) or be dimensioned based on the size of the network (for bare metal servers installed in private enclaves).

‍

Spacetime does not control the navigation, orbital maneuvers, or motion of any of the physical platforms or vehicles.  It only subscribes to changes to the parameters of motion for the physical platforms that are relevant to network control and orchestration (including 3rd party platforms like jamming threats, interception threats, or potential victims of interference).

‍

Spacetime does not command the satellite bus; it only communicates with satellite payloads (and other nodes in the network) to orchestrate the network topology, radio resource management, and network traffic routing.

‍

No. All of Spacetime’s APIs are modular and open source, which allow anyone to adapt individual nodes (or heritage element managers) to work with Spacetime.  These APIs use simple service definitions and support automatic generation of idiomatic client and server stubs in a variety of languages to facilitate rapid integration.

‍

Yes; Spacetime can orchestrate the intermittent storing and forwarding of data across a network.  This capability is especially relevant for sensing and earth observation.

‍

Spacetime’s APIs allow for any node to be designated as store-and-forward capable at the Application Layer (where an application on the originating node manages the queuing of data) or at the Network Layer (e.g., Bundle protocol).  The total memory storage capability of nodes can also be specified.  The latency field can optionally be used to limit the delivery timeline. 

‍