[00:00–00:30] Good morning, and thank you, Oana, Maxime and Christelle, for the invitation. I am Juan Fraire, from the Agora team in Lyon. Behind me, thirteen thousand satellites are weaving themselves into one network. It is a simulation, a constellation of orbital data centres. I will follow one of its satellites, number 48, through its life.

[00:30–01:00] [live] The network most of you know: Starlink. Twenty thousand satellites are in orbit today, seventeen thousand of them working, and eleven thousand of those are Starlink. This is its first shell, fifteen hundred satellites linked by lasers, here sixty times faster than real time. [point to the ringed satellite] Each one flies at seven and a half kilometres per second and circles the Earth in ninety-five minutes. [click] Data-centre constellations, like the one behind the title, fly another way: along the line between day and night. This one is our design, inside the orbits SpaceX filed with the FCC in January.

[01:00–01:40] [the view dives to satellite 48] Here is satellite 48, still sixty times faster than real time. It carries four laser terminals: two hold its neighbours in the same orbit, two re-point to other planes. [point to the panel] Every link it will make is known in advance: with whom, when, for how long, at what rate. We write each one as a contact and route on that schedule; contact graph routing is where my own work started. The topology changes all the time, and predictably.

[01:40–02:10] And short on everything. [point to the counter] Satellite 48 has seven hundred to fifteen hundred and fifty satellites in range, and about four terminals. A link lives for minutes. Energy runs short in eclipse, and every kilogram was paid at launch. [point to the equation] What a contact can carry is its duration times its rate, and that budget is what every scheduler shares out. Moving, predictable, scarce: keep these three words.

[02:10–02:55] First axis, AI for Space: if the orbits are predictable, what is left to learn? In ConstellAI, for ESA, with GMV, Thales Alenia Space and Saarland, we took routing. [point to the route] End-to-end delay has two parts. Propagation follows from the orbits, so we compute it: about forty milliseconds across the planet. Queueing follows from traffic and failures, so we learn it: with Q-routing, each node keeps the expected delay through each neighbour [point to the table] and corrects it after every packet. The white route is Dijkstra on propagation alone. [click] The learned route, in green, bends around busy nodes. In the study it beat Dijkstra by up to four milliseconds, and kept delivering when nodes failed.

[02:55–03:20] The second use case: scheduling acquisitions and downlinks for fifty to a hundred satellites. [point to the plan] We pitted reinforcement learning against simulated annealing, an algorithm from 1983 that shakes the plan while it is hot and settles it as it cools. [click] The 1983 algorithm won: up to fifteen percent more reward, and half the variance. With a known model and a large schedule, optimize; when the environment shifts, learn. In orbit, most of the model is known.

[03:20–03:50] [point to the bar] AI is also becoming a payload. Earth-observation satellites produce about five petabytes a day, and more than half never reaches the ground. So we bring the computation to the data. [click] Train in orbit: in FedSat-LAM, with UC Berkeley, only model updates travel, at 95 percent less energy per round. [click] Infer in orbit: drop the cloudy image before the downlink. [click] Either way, computing, communication and energy are designed together.

[03:50–04:30] Second axis, Space for AI: satellites are becoming data centres. [the camera moves in] Here is satellite 48 as one, a one-kilowatt node: solar wings, radiators, and in the middle a rack of GPUs. [point left] One GPU flew in November 2025; within months, filings asked for up to a million satellites. Six orders of magnitude. With Wenxiao Ge and Kanglian Zhao in Nanjing, we proposed a reference architecture: data-centre satellites on optical links, reached through an access constellation. Two choices dominate: where they fly, and whether they share the access network's orbits.

[04:30–05:05] We simulated both. [click] Embedded in Starlink's first shell, 48 data centres put about 90 percent of users within 12 milliseconds. [point to the left globe] But watch them: every orbit, a third of the time, they pass through Earth's shadow and run on batteries, hence mass. [click] An independent constellation on the dawn-dusk orbit and two planes beside it rides the line between day and night [point to the right globe]: the sun almost never sets, and every user stays within 40 milliseconds. That trade-off comes back with the bill.

[05:05–05:45] [live] Whatever runs up there must come back down, and the ground link moves too. From a gateway in Lyon, between a hundred and fifty and seven hundred satellites of this fleet are in view, typically four hundred, each one for about six minutes. [point to the gold link] So the gateway keeps handing over, about four times an hour. [click] Satellite 48 itself passes over Lyon twice a day, nine minutes in all. A data centre in orbit reaches the ground through whoever is passing, over laser links.

[05:45–06:20] To rehearse a space cloud before anything flies, we built MeteorNet with Camilo Rojas, Fabio Patrone and Mario Marchese in Genoa: real software over emulated orbits, open source. [follow the numbers] A task goes up, crosses laser links to a satellite whose server is on, and must come back before its deadline. [click] On a ring of ten satellites, about 80 percent of tasks failed whatever the policy: no satellite in view in time. The bottleneck was visibility, not compute.

[06:20–06:30] So, the limits. So far, how to build and run a space cloud. Now the harder question: what does it cost, and is the cost justified?

[06:30–07:25] First, the pitch. Data centres used about 415 terawatt-hours in 2024, and the IEA expects that to more than double by 2030. In orbit, a panel receives 1,361 watts per square metre, four times the Earth's average, and a dawn-dusk orbit sees the sun over 99 percent of the time. No cooling water, no land, no grid queue. Our models credit every one of these advantages. [click] But an advantage is one line on a bill. The whole bill is carbon accounting: the embodied carbon of every kilogram, built, launched and brought back down, plus operation, divided by the computing actually delivered. Our models, ESpaS and DepTax, are open: every number in this part can be recomputed.

[07:25–09:00] First, the carbon of getting there. Everyone expects the rocket to be the problem: launching a kilogram costs about 36 kilograms of CO2-equivalent on Falcon 9 and 21 on Starship. [click] The step nobody prices is coming back down. A deorbited satellite ablates, and part of it becomes nitrogen oxides in the upper atmosphere. At a twenty-year warming potential of 33, re-entry adds 46 to 62 percent on top of the launch. And the rules push fleets to burn: the FCC wants low-orbit satellites disposed of within five years. A graveyard orbit avoids the toll, and leaves a dead satellite behind for centuries. [click] Then, "energy is free". The sun is, but eclipses need batteries. Orbital electricity comes out at 52 grams per kilowatt-hour on Starship and 66 on Falcon 9, against 34 for solar plus storage on the ground. [click] The panels alone are six to eight grams; almost the whole bill is the battery. That is why the filings love dawn-dusk orbits. Keep that escape route in mind; it comes back with its own price.

[09:00–09:35] Second, the mass of staying alive. [the node opens] Here is satellite 48's node, opened up, every part to scale. Half of what we launch is radiator. A quarter is battery, a sixth is solar. [point to the rack] And the computer is this: five percent. The radiator alone weighs more than twelve times the GPU it cools. With no air or water to carry heat away, a coolant loop brings the heat out to those panels, which glow it into space as infrared light.

[09:35–10:20] Why so heavy? Every watt the chip dissipates must leave as radiation, and Stefan–Boltzmann sets the price: emissivity, area, and the fourth power of the panel's temperature, minus that of what it faces, cold space and a warm Earth. And the panel can never run hotter than the chip, about 80 degrees. [point to the bars] Hotter or lighter panels help, but in every case we computed, the radiator still outweighs the GPU at least three times. [click] That is also why PUE, facility power over IT power, misleads up there: it looks perfect, because the cost has moved into launched mass.

[10:20–11:30] So when does a one-kilowatt node pay back its launch? [point to the blue curve] Against the global-average data centre, within about two years: the headline number, against a low bar. Against a green data centre, on the Finnish grid at a PUE of 1.2, parity comes around year nine on Starship, and not within a decade on Falcon 9. [click] The staircase is reliability. Commercial GPUs are not built for radiation: the sparse public test data suggest a GPU dies after about three years. So a mission of T years flies T over three GPUs, the spares kept cold, and every step is one more GPU on the manifest. [click] The two escape routes in the filings, a battery-free dawn-dusk orbit or a graveyard instead of re-entry, pull parity to about year six. Each moves part of the bill elsewhere: to scarce orbits and more radiation, or to a dead satellite parked for centuries.

[11:30–12:55] And one property no terrestrial data centre pays for: orbit has no technicians. [the blade fails, a spare wakes] On Earth, a failed GPU is an operational event, swapped at two in the morning. In orbit it is a design event, paid in mass before launch: whatever redundancy you launch is all you will ever have. [click] What matters is the gap between expecting to survive and guaranteeing it. A node that expects two GPU failures survives with two spares only 68 percent of the time; guaranteeing 95 percent takes five. Certainty is bought at the tail. [click] Here is the price, for a one-kilowatt node over five years. Carbon per delivered GPU-hour against GPU copies on board, at 0.3 failures a year: the carbon-optimal node carries two. [click] Failure rates are unknown, so we span a factor of ten. [point to the black dots] A spare adds about 31 percent carbon on paper, yet at higher failure rates it pays for itself: the node delivers more work before it dies. [click] The guarantee, one chance in a thousand of failing, costs 77 to 86 percent more carbon per delivered GPU-hour, and between 5 and 14 copies. Spares on board still beat launching replacements, about three times greener. Orbital data centres will be born over-provisioned.

[12:55–13:00] Let me close with a research agenda: computing without repair. From one node to the fleet.

[13:00–13:35] [point to the loop] First, the environment is endogenous. Redundancy is bought with mass. Mass adds cross-section and, eventually, debris. Debris raises the collision hazard, which raises every failure rate, which demands more redundancy. [click] And failures in orbit are correlated: in February 2022, one geomagnetic storm brought down 38 of 49 freshly launched Starlink satellites. A consistent design survives the environment it helps create: a fixed point. When none exists, the design collapses under its own debris.

[13:35–14:10] And one more hazard, close to home. This is the sky over Lyon, live, on the evening of 21 December, ninety minutes after sunset: about two thousand stars to the naked eye. [click] This is the same sky with SpaceX's filed fleet of a million compute nodes, their solar arrays lit by a sun already below our horizon: nearly 25,000 nodes brighter than the naked-eye limit, more than ten for every star. Every kilowatt shines.

[14:10–14:55] Put together, the costs of one node and this loop turn a yes-or-no question into a region. A design fixes the orbit, the mission duration, the redundancy, the disposal and the application. It is feasible when it survives with probability one minus epsilon, beats the terrestrial carbon intensity, and stays within a footprint budget. [point to the green] Under one set of assumptions, there is a window. [click] Make radiation harsher and launch dirtier, and it closes. [click] Dependable or sustainable: orbital computing may not get both. That region can be empty, like the ring behind me, crossed by one line of debris.

[14:55–15:25] To wrap up, one line per part. [down the list] The network: moving, predictable, scarce. AI for Space: optimize what you can model, learn what shifts. Space for AI: visibility bounds the service. The bill: dependability is paid in mass, and mass in carbon. And without repair, the feasible region can be empty. [click] So orbital computing is flying ahead of its own science: nobody can yet say whether a data centre no one will ever repair can be both dependable and sustainable. That science should exist before the fleets do.

[15:25–15:35] Everything you saw stands on these papers, each a click away in the slides, with an open copy.

[15:35–16:00] None of this is mine alone: thanks to the teams in Saarland, Genoa, Nanjing and Berkeley, to ESA, GMV and Thales Alenia Space, and to my colleagues at Agora. The slides are behind this code, and the globe in them is live. Thank you, and I am happy to take your questions.