Building an Orbiting Internet Just for Satellites
Illustration: Eric Frommelt For decades, the astronomical cost of launching a satellite meant that only government agencies and large corporations ever undertook such a herculean task. But over the last two decades or so, newer, commercial rocket designs that accommodate multiple payloads have reduced launch costs dramatically-from about US $54,000 per kilogram in 2000 to about $2,720 in 2018. That trend in turn has fostered a boom in the private satellite industry. Since 2012, the number of small satellites-roughly speaking, those under 50 kilograms-being launched into low Earth orbit (LEO) has increased 30 percent every year.
One huge problem with this proliferation of small satellites is communicating with the ground. Satellites in low Earth orbit circle the planet about once every 90 minutes, and so they usually have only about a 10-minute window during which to communicate with any given ground station. If the satellite can't communicate with that ground station-because it's on the other side of the planet, for example-any valuable data the satellite needs to send won't arrive on Earth in a timely way.
At present, NASA's Tracking and Data Relay Satellite System (TDRSS) is the only network that can help route signals from satellites to the correct ground stations. However, TDRSS is rarely accessible to companies, prohibitively expensive to use, and over 25 years old. It's simply unable to handle the traffic created by all the new satellites. Getting data back to Earth from a satellite is oftentimes one of the bottlenecks that limits an observation system's capabilities.
With three other engineers, I started Kepler Communications in 2015 to break this bottleneck. Our goal is to create a commercial replacement for TDRSS by building a constellation of many tiny satellites in LEO. The satellites will form the backbone of a space-based mesh network, sending data back and forth between Earth and space in real time. Each of our satellites, roughly the size of a loaf of bread, will operate much like an Internet router-except in space. Our first satellite, nicknamed KIPP after the companion robot from the 2014 sci-fi epic Interstellar, launched in January 2018.
When fully deployed by 2022, Kepler's network will include 140 satellites spread equally among seven orbital planes. In essence, we're building an Internet service provider high above Earth's surface, to allow other satellites to stay in contact with one another and with ground stations, even if two satellites, or a satellite and a ground station, are on opposite sides of the planet. Our customers will include companies operating satellites or using satellite communications to transfer data, as well as government agencies like the Canadian Department of National Defense, the European Space Agency, and NASA. None of this would be possible without the ongoing developments in building tiny satellites.
Illustration: Kepler Communications Space Routers: This artist's illustration shows one of Kepler's CubeSats as it would look after being deployed in orbit. Kepler's satellites are what the aerospace community calls CubeSats. In the early 2000s, CubeSats were developed to try to reduce the cost of satellites by simplifying and standardizing their design and manufacture. At the time, each new satellite was a one-off, custom-built spacecraft, created by teams of highly specialized engineers using bespoke materials and fabrication methods. In contrast, a CubeSat is made up of a standardized multiple of 10- by 10- by 10-centimeter units. The fixed units allow manufacturers to develop essential CubeSat parts like batteries, solar panels, and computers as commercial, off-the-shelf components.
Thanks to CubeSats, space startups like Kepler can design, build, and launch a satellite, from napkin sketch to orbital insertion, in as little as 12 months. For comparison, a traditional satellite program can take three to seven years to complete.
The rise of CubeSats and the falling costs of launch have led to a surge in commercial satellite services. Companies around the world are building constellations of simultaneously operating spacecraft, with some planned constellations numbering in the hundreds. Companies like Planet are focused on delivering images of Earth, while others, like Spire Global, aim to monitor the weather.
So how are all those satellites getting all the data they collect back to customers on the ground? The short answer is, they're not. A single Earth-imaging CubeSat, for example, can collect something like 2 gigabytes in one orbit, or 26 GB per day. Realistically, the CubeSat will be able to send back only a fraction of that data during its short window above a particular ground station. And that's the case for all the companies now operating satellites to collect data on agriculture, climate, natural disasters, natural-resource management, and other topics. There is simply too much data for the communications infrastructure to handle efficiently.
To hand off its data, an Earth-observation satellite sends its imagery and other measurements by contacting its ground station when one is in sight. Such satellites are almost always in low Earth orbits to improve their image resolution, but, as I mentioned, that means they orbit the planet roughly once every 90 minutes. On average, the satellite has a line of sight-and therefore a line of communication-with a specific ground station for about 10 minutes. In that 10-minute window, the satellite must transmit all the data it has collected so that the ground station can then relay it through terrestrial networks to its final destination, such as a data center.
The result is that satellite operators often collect far more information than they can ever hope to send back to Earth, so they are constantly throwing away valuable data, or retrieving it only after a delay of hours or even days.
One recent solution is to operate ground stations as a service in order to increase the total number of ground stations available for use by any one company. Historically, when a company or government agency launched a satellite, it would also be responsible for developing its own ground stations-a very costly proposition. Imagine how expensive and complicated it would be if all cellphone users also had to purchase their own towers and operate their own network just to make a call. A cheaper alternative is for companies to build ground stations that anyone-for a price-can use to connect with their satellites, like Amazon's AWS Ground Stations.
But there's still a catch. To ensure that a LEO satellite can continuously communicate with a ground station, you basically need ground stations all over the globe. For continuous coverage, you would need several thousand ground stations-one every few hundred kilometers, though more closely spaced ground stations would ensure more reliable connections. That can be difficult at best in remote areas on land. It's even more difficult to maintain a connection over oceans, where islands to build on are few and far between, and those islands rarely, if ever, have robust fiber connections to the Internet.
That's why Kepler plans to move more of the communications infrastructure into orbit. Rather than creating a globe-spanning network of ground stations, we think it makes more sense to build a constellation of CubeSat routers, which can keep satellites connected to ground stations regardless of where the satellite or the ground station is.
Source: Spaceworks Skyrocketing Satellites: The number of newly launched small satellites weighing 50 kilograms or less rises every year, with nearly 500 such satellites expected to be launched in 2020. At the heart of each 5-kilogram Kepler satellite is a software-defined radio (SDR) and a proprietary antenna. SDRs have been around since the 1990s. At the most fundamental level, they replace analog radio components like modulators (which convert analog signals to ones and zeros) and filters (which limit what part of the analog signal gets converted) with software. In Kepler's SDR, these elements are implemented using software running on a field-programmable gate array, or FPGA. The result is a radio that's cheaper to develop and easier to configure. The use of SDRs has in turn allowed us to shrink our spacecraft to CubeSat scale. It's also one of the reasons our satellites cost one-hundredth as much as a traditional communication satellite.
To understand how the Kepler constellation will work, it helps to know how conventional satellite connections are made: with the "bent pipe" method. Imagine the pipe as two straight lengths of pipe joined together at an angle; the satellite sits where the two lengths meet so it has a continuous line of sight with both ends of the connection, whether they're two ground stations on different continents or a ground station and another spacecraft. The satellite essentially acts as a relay, receiving the signal at one end of the connection and transmitting it in a different direction to the other end.
In Kepler's network, when each satellite passes over a ground station it will receive data that has been routed to that ground station from elsewhere in terrestrial networks. The satellite will store the data and then transmit it later when the destination ground station becomes visible. Kepler's network will include five ground-station sites spread across five continents to connect all of our satellites. Unfortunately, this method doesn't allow for real-time communications. But those will become possible as our satellite constellation grows.
Here's how: Future iterations of our network will add the ability to send data between our satellites to create a real-time connection between two ground stations located anywhere on the planet, as well as between a ground station and an orbiting satellite. We're also planning to include new features such as transcoding-essentially a way to translate the data into different formats-and queueing the data according to what needs to be delivered most urgently.
We can make these big changes to how our satellites communicate relatively quickly, thanks to SDR. New code, for example, can be uploaded to an orbiting satellite like KIPP for testing. If the code passes muster, it can be deployed to the rest of the constellation without having to replace any of the hardware. Much like CubeSat standardization, SDR shortens development cycles and lets us prototype more ideas.
1/5 Some Assembly Required: A Kepler Communications engineer works to hand assemble KIPP the company's first satellite in orbit. Photo: Kepler Communications
2/5 Software-defined radio components replace many analog parts and make it possible to build satellites that are the size of a loaf of bread. Photo: Kepler Communications
3/5 A mostly completed KIPP waits for the finishing touches. Photo: Kepler Communications
4/5 Kepler has also built ground stations so that its satellites in orbit can communicate with terrestrial networks. Photo: Kepler Communications
5/5 The SatOps team keeps an eye on Kepler's orbiting satellites, which will grow in importance as the constellation becomes larger. Photo: Kepler Communications
Previous NextKepler is currently in the process of deploying our constellation. KIPP has been operating successfully for over two years and is supporting the communication needs of our ground users. The MOSAiC expedition, for example, is a yearlong effort to measure the arctic climate from an icebreaker ship near the North Pole. It's the largest polar expedition in history. Since the start of the mission, KIPP's high-bandwidth communication payload has been regularly transferring gigabytes of data from MOSAiC's vessel to the project's headquarters in Bremerhaven, Germany.
In December 2018, our second satellite, CASE (named after another robot companion from Interstellar), joined KIPP in orbit. Even with just two satellites in operation, we're able to provide some level of service to our customers, mostly by taking up data from one ground station and delivering it to another, in the method I previously described. That has allowed us to avoid the fate of some other satellite-constellation companies, which went bankrupt in the process of trying to deploy a complete network prior to delivering service.
While we've been successful so far, establishing a constellation of 140 satellites is not without challenges. When two fast-moving objects-such as satellites-try to talk to each other, their communications are affected by a Doppler shift. This phenomenon causes the frequencies of radio waves transmitted between the two objects to change as their relative positions change. Specifically, the frequency is compressed as the objects approach each other and stretched as they grow more distant. It's the same phenomenon that causes an ambulance siren to change in pitch as it speeds past you.
With our satellites traveling at over 7 kilometers per second relative to the ground or potentially communicating with another satellite moving in the opposite direction at the same speed, we end up with a very compressed or stretched signal. To deal with this issue, we've created a proprietary network architecture in which adjacent satellites will communicate with each other only when they're traveling in the same direction. We've also installed software on KIPP and CASE to manage Doppler shift by tracking the change in frequency caused by its relative motion. At this point, we believe we're able to compensate for any Doppler shifts, and we expect to improve upon that capability in future iterations of our network and software.
As the number of satellites in the constellation increases, we must also ensure that data is routed efficiently. We don't want to beam data among, say, 30 satellites when just 3 or 4 will do the job. To solve this problem, our satellites will run an algorithm in orbit that uses something called a two-line element set to determine the position of each satellite. A two-line element set operates in a way that's similar to how GPS identifies locations on Earth. Knowing every satellite's position, we can run an optimization algorithm to figure out the route with the shortest transit time.
Of course, all these challenges will be moot if we can't actually build the 140 satellites and place them in orbit. One thing we discovered early on is that supply chains for producing hundreds of spacecraft-even small ones-don't yet exist, even if the components are standardized. Ultimately, we've had to do most of the production of our satellites in-house. Our manufacturing facility in downtown Toronto can produce up to 10 satellites per month by automating what were previously manual processes, such as testing circuit boards to ensure they meet our requirements.
As I've said before, Kepler's constellation will be possible because of the drastic size and cost reductions in satellite components in recent years. But there is one area where efficiency has limited miniaturization: solar panels. Our CubeSats' ability to generate power is still constrained by the surface area on which we can mount solar panels.
We're also seeing limitations in antenna size, as antennas reach theoretical limits in efficiency. That means a certain amount of each satellite's surface area must be reserved for the antennas. Such limitations will make it hard to further shrink our satellites. The upside is that it's forcing us to be creative in finding new computational methods and software, and even develop foldable components inspired by origami.
By the end of 2020, we plan to have at least 10 more satellites operating in orbit-enough to run early tests on our in-space router network. If everything stays on schedule, by 2021 we will have 50 satellites in operation, and by 2022 all 140 satellites will be available to both users on Earth and other satellites in space.
Space is the new commercial frontier. With the increased level of access that the entrepreneurial space race has brought, upstart groups are imagining new opportunities that a spacecraft in orbit, and its data, can provide. By creating an Internet for space, Kepler's network will give those opportunities a route to success.
This article appears in the February 2020 print issue as "Routers
in Space."
Mina Mitry is an aerospace engineering and cofounder and CEO of Kepler Communications.