Networks in Motion, with Brian Barritt (CTO of Aalyria)

Yeah, thanks.

Thank you. It's really exciting. It took a bit, but glad to have it out there.

Yeah. Kind of begins in two places, two different timelines that sort of converge. One is kind of our software story, which has its origins in Google in around 2013 when there was sort of a range of projects going on there trying to connect the unconnected, bring, you know, billions of people in the world that lack broadband internet online. And Google was exploring a range of ways to do that, from using satellites in space to unmanned aircraft to novel sort of terrestrial networks. And our software story was kind of born out of that, which we can get into. And then the other story arc kind of begins in the late 90s at Lawrence Livermore National Labs where there were teams working on making laser communications work well through the atmosphere, and a group there kind of spun out from the lab, and Google saw a need for that technology for some of those things I mentioned earlier that it was pursuing and acquired that tech into Google. Both of these pieces of tech were incubated there over the course of about seven, eight years with a lot invested, some in stealth, some more well-known, and both of those technologies are now part of Valyria.

Yeah. Right. So, you know, when you look at this problem of connecting the unconnected, it's a problem that's like kind of highly related to population densities. You know, until these new rounds of like low Earth orbit and mid-Earth orbit satellite constellations, you generally only connected large areas from one of two altitudes. You do it from like the height of a cell tower or you do it all the way up at 36,000 kilometers into space in geostationary orbit. Geostationary satellites are great, but they can have like a third of the planet in their field of view, which can be like a third of the planet sharing their internet access. And then you're left with very few megabits per second per square kilometer, like not a lot of data to go around. And then towers work great when there's enough money in the radius of the towers to pay for the cost of the tower. But in emerging markets or places that are sparsely populated, there's just not enough wealth in the radius of a tower to like cover the cost of building the tower. And for, you know, many decades that's left a lot of people unconnected in the world. So when Google went looking at like how are we going to connect all these unconnected people, yeah, there's a component of it that was like subsidizing fiber deployment in Africa or other places, but a lot of the focus went to well, how do we make communications happen for these other population densities? Is there a way to like affordably connect people in that middle area? And so we started looking at low Earth orbit satellite constellations. We started looking at high altitude platforms like Loon, unmanned solar glider drones, which, you know, Facebook was also looking at with their Aquila project. And when you look at all those things, one of the things that you realize is unlike towers and geostationary satellites, if you're in any of the altitudes in between, now the network is moving. People are used to networks where the users move. We all walk around with our laptops and our cell phones. We, the users at the edge of the network, are moving and we're roaming between Wi-Fi access points and cell towers. But this part where the network is also moving, the infrastructure, the base stations are constantly moving around, that creates a bunch of challenges for networks. And so Spacetime, our software platform, was really born out of this need to operate networks in motion, not just support users in motion. And I think the part that was really unique, kind of happenstance, is that at Google we happened to have space projects, multiple types of unmanned aerial systems and terrestrial systems that were all facing that challenge. So the part we did that I think no one really did before is we asked ourselves, can we solve that problem like comprehensively? Can we solve it once and let four internal projects all use the same solution?

Instead of doing what people mostly done, which is like build pretty siloed, vertically like, you know, stacked things. So the original sort of mandate, for lack of a better word, was how do we figure out this kind of connectivity problem in general. But that bore that or that sort of gave birth to this new challenge, which is like we have all these different pieces of technology, but we don't have a connected software stack that like links all of them together.

Yeah. Yeah. We actually like when we were working on some of these different unmanned aerial vehicles like Loon, solar drones, some satellite work, we were all talking about how it would be kind of embarrassing if more than one of these projects succeeded at Google, but they couldn't use each other's ground stations or like, you know, the users couldn't roam from one to the other. Like we were Google, like we should be able to solve that. And so the theory was internally when we were setting out to build the software stack, it was like, well, maybe we could do twice as much work once, but build one system instead of four with like the four internal customers we have.

Yeah. Right. So one of the hallmarks of these aerospace and defense and satellite communications networks is directivity, meaning like when you want to get a lot of data at a long distance, you focus the energy at the receiver. It's like the analogy I make for people is if you're trying to talk to a friend that's like a long distance away across the room or outside, we all kind of cup our hands up to our mouth and we shout, and that's because if we didn't do that, we'd waste energy going in all directions, and we can talk, you know, we can communicate better further if we focus the energy, if we shape the energy that we're transmitting at a finite power level like at the receiver. We want it to — aerospace and defense systems use directivity in wireless also for reducing the probability of intercept and jam and detect. So it's like the same reason you put your hands up to whisper to somebody. By doing that and shaping the energy away from them, you're limiting how much energy goes to receivers.

Exactly. Like why, like your Wi-Fi, your cell phone, you know, they're giving off energy more like a light bulb. The energy is going in all directions, which is great at short ranges or if you don't have that much data to get through, if you're okay with low data rates like for LoRaWAN or how your smart meter works, right? Very little data needs to get through. So it goes over long distances the same way, blasting the energy off in all directions. Those networks where the energy is going in all directions make them much easier for you to detect, you know, like the Wi-Fi networks nearby and have things join and discover, or for the networks to like self-organize. You know, devices can make a list of all the wireless devices they hear and tell their neighbors who they hear and so on and so on and so on to build a view and a picture of what's around. But when the beams are like really focused and shaped and narrow and directional, that doesn't work anymore, right? You need something in the network to be this sort of coordinating entity to tell the different beams where to point when and when they should like change and point at something else, and what frequencies to use when and how to route data across all of these things. So, you know, you can just imagine in your mind aircraft or drones flying around if instead of light bulbs on them, they had laser pointers, right? And you can imagine an aircraft banks and now the wing is obstructing the laser to another aircraft, right? You have all this changing geometry, all this changing motion, all these changing obstructions that create a lot of complexity for how you build and operate a mesh of those things.

And cracking that was what we set out to do at Google because we had four of them and we thought, well, maybe we can just solve it once. But it turns out that by doing that, we solved it for all land, sea, air, and space. And we didn't really realize that our little microcosm in Google of having a satellite program, a couple unmanned aerial vehicles, some terrestrial stuff was sort of this small microcosm of what, you know, probably your listeners or readers of Tectonic and other things think about with like JADC2 and all-domain networking for DoD. Like the unification of land, air, and space networks has been something that's been worked on for 40 years without being cracked. And, you know, we were working on it for a commercial reason of connecting the unconnected and for just internal use inside of the Alphabet family of companies. But it turned out to have a lot of wide applications.

Yeah, that's right. You know, and there was a — you know, an amazing group of people, you know, at Google and Alphabet and X, you know, all worked to build the software that we now call Spacetime. And in Google it was called Minkowski, you know, which the naming is sort of a reference — that was Einstein's professor and the father of the concept of spacetime. And Project Minkowski was an amazing group of software engineers who, you know, started with a couple of us with the idea and kind of self-drafted into the project. We all started building it. And I think when we found out that Alphabet was winding down, you know, Loon, you know, people moved on and found new projects to work on, some within, outside Google and Alphabet, others, you know, went to other places. Some of our engineers went to Amazon Kuiper, or myself, I went to Facebook Connectivity. But I think universally people looked back fondly and said like, man, this is one of the greatest things I ever worked on. And I really loved this team. And so not only was it kind of my baby and I missed working on it from something I really believed needs to exist for the world, but I missed the team that I was working with, too. So at Meta, yeah, I was — you know, I had left because they were winding it down and there was an interesting opportunity over at Facebook Connectivity, which by the way, that group is amazing over there, too. Maybe people don't realize they build things and just give them away. They just open source everything to try to make connectivity cheaper for the world. They're building like open source cellular stacks, open source cellular radios, Wi-Fi systems, and just giving them away and open sourcing them with the Linux Foundation. So it's a pretty amazing mission. And I was over there working and yeah, I heard from someone in Google corporate development and then I also heard from our lead investor, Arthur Patterson, and my colleague and our current CEO and co-founder, Chris Taylor, who were putting together an effort to spin the technology out of Google and acquire it with a new venture-backed company, which was really, really exciting. Of course, I jumped at the occasion to be part of that. I'll say the folks at Meta were just amazing about it. The process took a while, as you can imagine. Google's really great at acquiring things, but they can take a while to divest things, so they don't do that as often. So it took a bit to get that transaction done.

But it was really exciting and the team at Meta understood that this was a real passion project for me and could not have been more generous about affording me the opportunity to see it through and then understanding when I ultimately wanted to go and pursue it. And the last point I want to make about this is how humbling it was where so many people from the original team were willing to leave, sometimes jobs they had only been in for a short amount of time, to sort of put the band back together.

Which was just really incredible.

Yeah, there was an amazing, amazing guy named Tony Ruggero from Lawrence Livermore National Labs. And, you know, I knew Tony and he was a friend. He's passed away, sadly, but he was really passionate about solving this problem of making laser communications work well through the atmosphere and had spun the tech out of the lab. And Google had acquired — or, sorry, Siros Photonics, I think it was around 2013, 2014, and incubated this technology in the office of the CTO for a while. This was sort of more of a long-term bet. I mentioned we were working on Loon and we were working on other unmanned airborne systems and satellite systems. And Google understood that if these projects were successful and they continued to scale, eventually the feeder links, the links back to the Earth, to the air and space layer, would become bottlenecks. And we see this now in commercial constellations and what's happening with mega-constellations like Starlink and Kuiper, and they see the same thing, that these feeder links will eventually need to increase in capacity and at some point become the bottleneck in sellable capacity. And said, hey, this is something we want to bet on and incubate for a while. It's interesting, Alphabet actually had a couple, two different laser communications projects. One of them in X, now Taara, was really focused on how do you do this affordably? How do you really make an impact in emerging markets with very affordable but resilient free-space optics? This other group more came from a national labs heritage pursuing aerospace and defense, quite exquisite, expensive, higher size, weight, mass, payload projects, but going for really high data rates. So nothing less than 100 gigabits a second through atmosphere is really the focus.

Right. Right. 20 gigs, right? 20 gigabyte file transferred in a second. Pretty astonishing data rates. But this is important for our industry because if you think about the trends going on, right? You want higher resolution imagery of the Earth, right? It helps to be lower in altitude. You want to serve more megabits per second per square kilometer, it helps to be lower in altitude. But the lower you get, the more the satellites need to proliferate. We're going from hundreds to thousands to tens of thousands of LEO satellites in these constellations. And so what was a ratio of maybe one-to-one, where each satellite had its own dedicated ground station, right? These ratios are changing. Two, the world's two-thirds oceans, right? So we can't have a ground station under every one of those thousands or tens of thousands of satellites. We have to have inter-satellite links to route the data back to relatively few ground stations compared to the number of satellites. So take however much data these satellites are generating, whether they're doing imagery or Earth science or communications, and then take the ratio of those satellites to the places that it's economically feasible to have fiber to them, to deploy these ground stations. Maybe it's 40-to-one, maybe it's 60-to-one. Well, now you need 60 times the capacity, right, for the average data being generated per satellite for the feeder link, right, for that link back to the ground station. So you need these high data rates, right? It becomes more and more important because it has to handle the capacity now of 40, 60-plus serving satellites.

Yeah. Right. At 100 gigs.

At 100 gigs. Yeah.

Yep.

Well, the first order of business is get the software running again. You know, we built this stuff in Google to run on Google's internal infrastructure, which is like what Google Cloud runs on. And so when you spin it out and you get all your source code again, it doesn't even run. So first order of business is like, band's back together, build the tech stack, get it running again, get it booting again, because start demoing to customers and start landing some business. And pretty soon we found both commercial and some government ones. Commercially, with our partners at Telesat, who've been really amazing, and we had done some work with them when we were still part of Google. And then our first contract with the US government was with the US Defense Innovation Unit.

Yeah. So I mentioned that the bet was made on Tightbeam and a lot of the thesis is on this space-to-ground feeder links being a bottleneck. But in the history of those seven years at Google, the space projects we were working on, you know, sort of were wound down earlier and the ones that lived the longest and saw production deployment were like airborne or Loon. And so when it spins out, we get one of Google's test aircraft. We've got a building with our labs, but it's an airborne terminal, right? It can be mounted on aircraft. You know, we have air-to-ground links and demonstrations and hundreds of flights and landings. But, you know, you could consider it, you know, something that's probably like TRL, you know, seven or eight sort of thing. It's like sort of on its fifth generation at that point. We're now on our sixth generation of terminals there. So premature test ranges that run all the time, but work to do to spin another iteration of terminals to make them even better, even more resilient, to be able to survive even more atmosphere. We want to integrate them with Spacetime so that, you know, Spacetime is sort of the brain, the network operation system that supports anyone's hardware. But certainly now that we're a combined company, you want your hardware to kind of come with the printer driver for the operating system, so to speak. You want it to like be plug-and-play for your customer. So doing the work to hook that up.

Yeah, I mean obviously people operate LEO and MEO constellations today that don't use Spacetime, right? And the way that they're doing it today and the way they always have done it is by usually having the spacecraft manufacturer build custom software that they deliver with the satellites that is hardcoded in the source code to leverage what simplifications they can about specific orbits, specific frequencies, specific antennas. Maybe if you're a MEO constellation, you just go around the equator. That geometry just keeps repeating. So the schedule could repeat forever, but that's not true in LEO constellations, for example. And so if you can use that simplification, you'll take it. These things are complicated enough, right? Everyone has enough risk on their hands when they're building a system like this. And so every person that's building one of these networks is embarking on, you know, a sizable engineering team to build and deliver to whoever is going to operate the network the brain of the network that's coded for that network. Okay. What is that? What's the downside of that? The downside would be one, this is an investment that everyone has to keep making over and over again, right? Which just adds costs and increases barriers to entry in our industry. But the second problem is that when you're trying to unify these networks or make them interconnect with each other, right? You know, I've noted to others that like the DoD has had slide decks that have icons of planes and ships and satellites with little lightning bolts between them proposing the unification of land, air, and space networks and hasn't pulled it off for a long time. We attribute kind of the primary reason for that is that all of the systems and platforms that they've procured have come from prime contractors with these bespoke, vertically integrated, hard-coded operation systems and brains that only work, you know, for those fleets of equipment with those obstructions, with those antennas. And when you want to say, okay, I need these two systems to both analyze when they could communicate, when they could point a radio or a laser beam at each other, when they're flying past each other and schedule a moment to like tunnel into another one's network and tunnel across it, like they can't. They only know where their obstructions are. They don't understand where the other vehicles would be. They don't have a way to speak the same language to each other to exchange information about such things. And so one of the things that's really changed in Valyria in our business since spinning out and our engagement with the market is that while people very much appreciate the opportunity of like buying a system and not having to build it again, the part that's been an even bigger unlock recently has been the power that that unlocks for their networks to talk to other networks and to broker when they could federate or interconnect and tunnel across each other to do networks of networks. It's sort of a secondary benefit and it's a true network effect.

Yeah, a lot of it is taking the problem more down to a physics level, into like a first principles level. And we actually kind of drew inspiration from the data models used by tools that some of your listeners might be familiar with, like the product STK from Ansys. We don't use STK, the Windows application, under the hood of Spacetime. But what's really impressive about what those folks did is they have an open way to model networks in a general way about transmitters, receivers, antennas, filters, amplifiers that let you sort of stitch together as someone trying to simulate a space network and do analysis on it. Other tools used in the networking industry to do modeling and simulation of like cell phone networks, Wi-Fi networks, they allow researchers in academia to experiment with new standards and not have to build the networks for real. And a lot of them have built kind of ways to model networks. So we had like a team of people who had worked in the modeling and simulation world of both wireless and computer networks and aerospace and said, okay, like how do they come up with something that's both general but detailed enough to be able to do all the math you need to do to analyze like time dynamic geometry and signal quality and stuff like that and to simulate networks with high fidelity. And we sort of built a large-scale distributed system the way Googlers would build it, of like hosted on Kubernetes. It runs in a cluster. It's got a bunch of microservices. It's built on best practices. And like we built something very scalable, right? Unlike the applications that maybe we drew our inspiration from that can run cloud-native and very scalable to pull this off.