Session Date/Time: 17 Mar 2026 08:00
Juan Fraire: Okay, good afternoon, everybody. Welcome to the second official meeting of the proposed Space RG: Systems and Protocol Aspects for Circumstellar Environments Research Group. We are an IRTF group. I'll remind you of what that means in a moment.
Since this is Tuesday, you've probably seen this before also in other Research Group meetings. Even though we are the IRTF, we are still governed by the rules of the IETF Note Well. You will have signed this upon registration, but just to be reminding you, there are certain IPR rules you should be aware of, especially when you do have knowledge about patented technologies that are being presented here, you are supposed to reveal that. There's more details to be looked at.
Moreover, the session is being recorded. IETF regularly makes recordings and creates transcripts and the like, so be aware that this is happening.
Thirdly, we do have a code of conduct of friendly and professional interaction with one another. So please always be reminded that any comments and so on should be on topic, not on persons and the likes. In case of any issues, we do have an ombudsteam that you could refer to to help settle these things.
And finally, so we are an IRTF group or proposed IRTF group, which means we don't build standards. We may write specifications, but we don't create RFCs that would influence product design from a standards compliance perspective, but rather we look into longer-term research. This is also reflected in today's agenda that I'll come to in a moment.
So we may publish documents, we may also have non-RFC documents such as wikis, living documents of some sort. But this is mostly, this group is about information sharing within this community, about tools and the like. And we'll have a few talks along these lines later on. And I'm going closer to the mic.
Okay, this gets us to our agenda. So we have a bunch of invited talks. Two in the beginning. Then we have brief presentations and updates on three different internet drafts plus an initial talk on the tools collection people have been doing. And then we'll have a final invited talk where the speaker is using his own laptop. This is why we put him last, but certainly not least.
We have a full agenda, so we'd like to ask everybody to stick to their respective time slots. We'll take note of the time, and in order to maximize the usefulness of our time, we'll finish this intro part early and move on to the first speaker.
Professor Zhao, please. Yes, thank you. Let me share the slides. Give me a second.
Kanglian Zhao: Thank you very much. It's a great honor to have this opportunity to present our some research and results here. Sorry. Okay, thank you.
So the topic I present here is Bridging the Future Digital Divide with Space Cloud Network Infrastructure. And I'm from Nanjing University. This work is a cooperation from Nanjing University and Inria, Juan.
So what we are working is these four parts. First, information infrastructure in space. Second, applications and use cases. The third part is architecture and performance evaluation, and finally the conclusions.
First, let's see what's information infrastructure in space. Actually, we all know like internet is the information infrastructure on the ground, right? But it's not only networking alone anymore. From the very beginning, ARPANET, it's a communication network and also a computation architecture or infrastructure. And on it, it's applications. We have experienced like at least four generations, like the web 1.0, web 2.0, the mobile internet, and nowadays it's an AI network, right?
But what's in space? What's happening in space? Of course we know Starlink, but most of us are focusing on the space segment of the Starlink network or constellation. Of course, it's the most important part, but we cannot leave out the terrestrial part or terrestrial segment. Normally, when you search the ground stations of Starlink, you will see these white balls. But these things are only the antennas of Starlink gateways. Actually, what we find recently is Starlink is building more and more ground stations with data centers. We have these three data centers. The first two are in US and the second is in Africa, Nigeria, these places.
So the ground station is directly installed besides or into the data centers. What's the benefits of this architecture? We can see this picture, right? Here, if we use the bent-pipe architecture, so directly the signal sent to the satellite, it's reflected to the ground station and into the data center. These have two benefits at least. First, this is the closest POP point, so it's connected into the internet. So it gets faster, get into the internet. Elon Musk is always talking about Starlink, only about the latency. It's 20 milliseconds, it's his goal of the Starlink performance. The second thing is when you connected to the POP, it's also a data center. So data and services are already there, or most of the data and services are already there.
So this we call it Space Internet with Terrestrial Cloud. Amazon is doing the same thing, right? We all know the Kuiper, or nowadays it's Amazon LEO system. And the second thing is AWS, Amazon Web Service, is the biggest or the number one, world number one public cloud for in the world. So these two parts connected together, it provides the benefits or advantages over Starlink, because Starlink only have the Space Internet. It connects with the terrestrial cloud with other data center providers. But in AWS, it's all integrated with one provider. It's normally better optimized.
But it's not just Kuiper or Amazon LEO, because recently just in January, Amazon, one company of Amazon, it's Blue Origin, which is doing the rockets, right? It also provided or proposed the new project, it's called the TerraWave. The TerraWave system is building a new backbone in the sky or in the space. We can see the speed is extremely fast. So with RF links, it's up to 144 gigabits, and with optical links, it's up to 6 terabits. It's more or less close to the ground links already. So this is a new trend, because with AWS, it's already have a good infrastructure on the ground with the cloud, which it doesn't have is the network, the global network. With Amazon LEO and the new TerraWave, the backbone and access network is already there.
But what's is taking, what's the difference here is SpaceX seems take another way. SpaceX also proposed a new project in January the 30th. It's called the Orbital Data Center project to the FCC. So it proposed to build one million satellites to put computation in the space. So this is a quite different way. And Amazon actually rejects or objects this idea. Amazon Web Service, AWS CEO said this is not economical, at least currently.
So we can see these two parts, we call it Cloud Network in Space, or Space Network plus the Terrestrial Cloud. These are two different ways.
Then other companies or players in this area, we can also see Google. It just published a paper in the arXiv. It's called "Towards a future space-based highly scalable AI infrastructure system design," this paper. And in this paper, it proposed to launch a cluster or a fleet of satellites to organize a distributed AI data center to like train the models or do these things. This is important for model training because this cluster is very densely located. It's in like 100 kilometers and like 81 satellites. This density is never seen before. We have also like a clusters or formation flying, either no such scalability or otherwise no such close densely placed fleets.
And the other thing, I think most of us are quite familiar, is the Startical. These people are also from Starlink, so it's quite similar to Starlink, and this is Startical. It just proposed to have a huge or a very big data center in the space to do model training. And this idea is behind is to save the money for energy, because when we in a special orbit, it's called a Dawn-Dusk orbit, we have always the sunshine. So the sun power is always there, so we don't need a battery and we can always have the energy to train the model. So there is a white paper from this company, we can download from the company's website. It says like in the 10 years period, the whole budget is much lower in sky than on the ground.
And what we also need to notice is the EU ASCEND system or the project. It called Advanced Space Cloud for European Net Zero Emission and Data Sovereignty. The first part is similar to model training, AI model training in the sky or in the space. But the second thing is quite important for us: the digital or the data sovereignty. Because as we know, we just mentioned AWS is number one or the biggest public cloud provider, right? The second actually is Google, and the third is Microsoft. Or maybe these two places are reflected. But it's true that the first or the third biggest public cloud providers are all American countries. So this is what EU is worrying about. They don't have the data sovereignty.
So if we go to the sky and put computation there, and several companies and organizations already proved that this is possible. Not just edge computation. It's also the big data centers there, like the 5 gigawatt data centers. So we put several different categories here. One thing is for applications. One of the applications is for model training, like the special ideas from Starlink and SunCatcher. And the second part is for the what we call it is Space Data, Space Computation, or Space Computing. Like we have already a lot of data produced in the space, right? Remote sensing, every day terabits data already produced in the space. So the traditional way is we send the data back to the ground and we process the data in the ground data station. But as we know, the bottleneck is in the space-terrestrial links. Nowadays, we have Ka or Ku data links for data transmissions for remote sensing satellites. It's like something lower than 1 gigabits per second. So this is already not enough for transmission all the data down to the earth. So these are two ways. One is go to the optical links. The other thing is we compute where the data is. So this space data, space computing, or space computation idea is we put computation devices or the hardware into the space and directly compute and transport only the information back to the ground.
And the third thing, sorry, the color is not so clear. It's called Space Data and, sorry, the Ground Data and Space Computing. So many people think this is a strange idea. Why we have the ground data and we transmit it to the space to computation? Actually, what we should know is like the idea talked in this presentation. We have a lot of undeveloped areas or countries, like on the sea, in the sky, or in Africa, in South America, or some these places. We don't have the infrastructures to communication or to do the computation. So for these countries, for people there, like Google already in the past have a O3b satellite communication project, right? It's called Another 3 Billion. The idea is to provide communication with satellites to those areas and peoples, another three billion people without the communication infrastructure. Actually, what we want to say is much worse thing is not only the communication infrastructure, also the computation and AI infrastructure, it's the gap is increasing. So with this idea, I mean ground data space computation, it's more probable to compute the data, ground data, for the undeveloped in the sky or in the space.
So like use cases, we have this Space Cloud Native NTN Core Networks. We already have cloud native networks, core network functions on the ground, right? Nowadays, as you know, Starlink buy the EchoStar spectrums. So basically, what we guess is like nowadays it cooperates with the ground mobile service providers. But afterwards, if it provides the core network or the cloud core network functions in the sky or in the space, Starlink can do the D2C directly by itself. And the service is like global D2C, a global inter-operator roaming, and marine service, aerial service. This is a huge markets.
And the second thing, these two things are for network. One for the core network functions, the other for the connections, interconnections, like the POP in the space, or space-based POP. We all know we just mentioned POP on the ground, it's in the data center because we need computation to interchange the network services. So why POP is located or placed in a data center? It's this reason. Then if we connect the different satellite networks, if we have this computation power in the space, it's much better or much faster.
So even with these requirements or use cases, it's already more or less useful for put computation into the sky, not only mention the remote sensing data processing requirements. So my students do some research on architecture and do some performance evaluation work. It's quite simple here. We propose two layers for this future infrastructure. One layer is cloud layer. We do the cloud computation in this layer with the data centers, with bigger computation power, with bigger storage power. And the second is access layer. This is only or this is already there some more or less, like the Starlink, like the Amazon LEO, or like some Chinese satellite networks. So the architecture or the organization of this cloud layer with two different kind of organizations. One is independent, the other is embedding. The embedded thing, we can put the satellites, the computation satellites or the data orbits, data centers, with the communication constellation. The other thing is it's a separate or independent location. And the second, where to put it? The orbit choice. One thing is Dawn-Dusk orbit. Most of the companies proposing to do computation in sky is proposing this orbit. But we also mention the inclined orbit with the satellite internet constellations.
And we have some simple results. Actually, this thing we don't do simulations. We already know the ideas. If we put data centers into the sky, then the access latency or delay must be much shorter than access the ground data centers. It's almost half of that, right? But it's different. If we choose the Dawn-Dusk orbit, it's only one orbit. But here we separate it or extend it to three orbits. Anyway, this results are better than the ground data centers.
And the conclusion is like three parts. The Space Cloud Network is important or promising architecture to provide global low-latency network and computation services. The second, although there are groups, working groups working on this terrestrial, someone call it computation power networking, the space is different, especially the mobility is different. The third is this place or this group, this Research Group, might be a very good place to start this research because these challenges are different in the space or on the ground. And it's glad to see there will be a group talking from China Mobile is already talking about some draft on this. Okay, this is my presentation. Thank you very much.
Juan Fraire: Thank you very much. I think we'll need to push any questions to the chat. There was already quite a bit of discussion about this and that in there, but we need to move on to the next talk. Thanks again, and I'll bring up the slides. One second. Okay. He Xiongwen, please go ahead.
He Xiongwen: Hello, everyone. My name is He Xiongwen. I'm from the Beijing University of Spacecraft Systems Engineering, China Academy of Space Technology. I'm also the CCSDS Deputy Area Director from Space Internetworking Services (SIS) area. Today, I'm going to share some information about our current research on Protocol Architecture of Earth-Moon Integrated Network.
First, currently in deep space exploration from China, we have the Chang'e-4 which landed on the far side of the Moon, and also we have Chang'e-5 and Chang'e-6, they are already successfully returned the soil from the far side of the Moon. And now the Tianwen-1, which has visited the Mars, and also last year, we have Tianwen-2 which is on the way to the asteroid exploration. And also in the coming year, China will still continue to carry out lunar exploration projects, such as we will have a Chang'e-7 which will have a high-precision lunar polar region landing. And also in the future, we will have the construction of International Lunar Research Station. And we will also carry out planetary exploration project and also like the missions which will return some samples from the Mars. And we have already announced the project which is that before the 2030, China will achieve a manned landing on the Moon. And also in the long term, we will have more projects which will utilize the lunar resources.
So from these major engineering projects, we can see that we have future needs for the lunar and also the deep space, such as the efficient network communication, which will have a higher speed and also the coverage will be wider. And also we need precise PNT service for the Moon and also the other planets. And also we need efficient space awareness ability, and also we will have information service sharing all this information from different nodes, from different countries.
Currently, we have done some research on different international organizations. For CCSDS, it have a different protocol architectures. From the left, you can see that there are two architecture for the space communication protocols. Currently, in the middle, you can see that it have a three layers. And for the application layer, you can see that there are a lot of protocols, they have a different interconnections. And from the right side, you can see that this is the protocol architecture for the onboard, for the onboard system. You can see that it has four layers, and currently, it combines the transport protocol and also the network protocol into one single layer called a Transfer Layer. And below that is a Subnetwork Layer, which will provide a lot of service no matter which link you use.
And also in the European Cooperation for Space Standardization (ECSS), it has some other standards, such as the 15-53 and also the packet utilization standard to do the ground and the onboard operation.
And for IETF, you can see that it has developed a lot of protocols such as the TCP and ISO. Currently, IP version 6 is widely used, and also BP and LTP.
So to summary this research work, you can see that in the future, we have to build heterogeneous interconnect Earth-Moon integrated networks. But the current protocol architecture is, it has different layering and also has different protocols and different applications.
So our work is to how to combine all these different protocol architecture into one single architecture. That is, we have a protocol architecture and also associated with this architecture, we have a lot of systems developed such as the network communication and evaluation system and also hardware protocol and Fuxi flight software architecture and the software components. And also we have the ground verification system and on-orbit validation system.
First, you can see that this architecture, it has four layers, and it combined the CCSDS-SIS architecture and space communication architecture. You can see that in the layering, there is one important layer, that is the Network Layer. We have two different protocols. One is the space packet protocol, which can be used among these low-speed links such as the 15-53 and also the ground-to-satellite link. And the other is the IP, IP normally we use IP version 6. This protocol is used on the high-speed links such as the TTE, TSM, and also the optical link from the ground to the satellite or between the satellites. So using this layer, we can isolate the different links that we use, no matter it's onboard link or the satellite-to-ground link or between the satellites.
And above that, we have the Transport Layer, which can support the TCP, UDP, and also LTP. And above that is the Application Layer. We have different protocols from CCSDS and also the ECSS-PUS protocol. And you can see that from this architecture, we can combine all these different protocols together. And of course, it has some connections between the each protocols. Currently, most of these protocols, we have the realization onboard.
And in order to use this protocol architecture in different missions, we need to have a network simulation and evaluation system. In this system, we can develop the different protocols and integrate them together in the simulated environment.
And also, we have developed an onboard information flow design system. In this system, we can design the onboard node and we can deploy different protocols inside each node and we can see this information flow between these different nodes and to evaluate the performance of this system.
After that, we have the hardware product and software product. And hardware product currently, we have developed the high-speed router for the space network, from the left side, you can see. And also we have the high-speed router for the network, there's another type which combines the TSN inside. And also from the right side, you can see that we have an Intelligent Network Unit for the deep space. And this product has also already been deployed in the Queqiao-2, the lunar relay satellite.
And in order to implement the whole protocol architecture, we also developed a software architecture called Fuxi. That is a flexible and unified flight software architecture. And from the right side, you can see it can support a lot of protocols such as the CCSDS AOS and also TC and also the USLP, etc. And from the left side, you can see that there's a layering called the middleware layer, which has also been subdivided into three layers. These three layers, it has a realization of different protocols of the protocol architecture. You can see the coordination between this protocol architecture and the software architecture. You can see that from the left side, all these protocols in each layer will be implemented into software components. This components can be configured in different missions, but the software code is can be reused for different missions. So using this middleware layer, we can develop the applications faster, and also we can make the integration between the software and hardware more easily.
And also, we have published the CCSDS recommendation, that is the "CAST flight software as a CCSDS onboard reference architecture." That's from the left side. And we also have our research in a book that's called the "Space Data System," which has give some examples how to use all these protocols together. And from the right side, we have another book called the "Spacecraft Avionic System Software Design Technology." In this book, we have the whole Fuxi software architecture, it describes how to develop these software components and how to use the architecture in different missions. So if you have some interest, you can look up these books.
And also, we have developed a ground verification system. In this system, we have developed the space network router and also onboard TSN switch. It can improve the whole communicating networking ability of the whole system.
And in 2024, we have deployed the Intelligent Network Unit into the Queqiao-2. That is China's lunar relay satellite. You can see that we have deployed a lot of protocols in that mission, which we integrated the CCSDS space link service and space onboard interface service and also the ECSS-PUS packet utilization service and also TSN onboard this satellite. And in the future, we will have the integration test on the CFDP, BP, LTP and USLP, which has already onboard that satellite, but it needs some ground station improvement to do this.
We think in this, with this architecture, we can support the ground application like simplify the operation and also receive advanced space information, etc. And also for spacecraft, we can have the cross-node manipulation and also cross-domain information sharing and also autonomous collaboration.
And in the future, I think we can build an Earth-Moon integrated network and in the far future, we can have like an interplanetary network. Okay, thank you.
Juan Fraire: Thank you very much. We do have time for questions this time. Please also join the queue on the thing just for record. Okay, Tony Lee.
Tony Lee: Could you please go back one slide? Please go back one slide. This one?
Tony Lee: Yeah, thank you. That's inspirational.
Juan Fraire: Okay, what's the question? I don't think there was a question. But it's a nice slide. And a cool picture. It will be shared anyway. Okay, thank you very much again. So we talked about space data centers, we talked about space communication protocols. We'll come back to constellations in the third invited talk. Now we'll have a quick detour to our tools collection effort that we have been trying to undertake here. And Nishanth Sastry will be presenting on this. Let me just bring up his slides and I hope he is able to speak.
Nishanth Sastry: Yeah, can you hear me?
Juan Fraire: Yes, we can hear you. Go ahead.
Nishanth Sastry: And I'm not sure if I can do the slides myself from remote.
Juan Fraire: I'm trying to find you here. Yes, now you can.
Nishanth Sastry: Okay, yeah. Let's see. Yes, okay, it works. Right. Thanks for this. So this was an effort that we started off in a recently conducted Dagstuhl Seminar. And essentially, the idea was that we have a lot of effort going on, a lot of research going on in this space. And can we collect together all the infrastructures that we have and how do we make use of it collectively together as a community? And I also sent out an email a couple of weeks earlier to the mailing list, and what I hope to do is to help collect all of these and make a living document in the end. More about that at the very end.
Okay, so how do we measure and understand LEO networks, right? So the way to understand this is to if I can make a contrast with let's say data center researcher. So if I'm researching data centers, not in space, in on Earth, then what I would do is I would probably bring up a couple of racks in my university and then link them all together and lo and behold, I have all the infrastructure that I need to evaluate my own proposals. But how do I do that for space? Well, what I would need to do is perhaps build my own constellation, do something similar to what Starlink does, which would be fantastic because Starlink doesn't currently grant me the whitebox visibility that I need to do all the networking research that I need to do. However, there are some problems here. First is that it's a very complex and expensive endeavor, right? So I can try to put up one or two satellites in space. Even that is very expensive, even finding a launch slot amidst all the other satellites that Starlink itself is trying to launch is not an easy job here. And even if I did manage to send up one or two or three satellites into space, it doesn't go towards capturing all of the complexity of the mega-constellations that we have today. Starlink, as we speak, has nearly 10,000 satellites with inter-satellite links, again something hard for us to achieve as researchers. And if we don't have that many nodes in our constellation or research constellation, then we may not replicate some of the emergent behavior.
So what I'm showing on the right is an effort happening in China called Tiansuan, which I believe is trying to send up up to six satellites. I'm not sure how many satellites they have sent so far. And even if I did manage to have, let's say visibility into Starlink itself, if I managed to collaborate with them, I will not get the same kind of constellation that other operators might have. So you cannot easily capture specificities beyond deployed or even planned constellations.
So these are problems that we'll need to contend with as researchers. So here are a few different ways in which we have gone about doing this in our own work and I want to expand from that into an effort for the community itself. So when we first published the very first study on Starlink, this was in Internet Measurements Conference (IMC) 2022, what we did was we developed a browser plugin and we asked people to install it. And the reason why we needed to do that was because you have as a researcher one vantage point, and for something like a LEO constellation you need multiple vantage points across different latitudes. And so for coverage reasons, you do need something where other users can help you at least. And the browser plugin was great for the very first study, but what we discovered was that you can't do too many networking-related heavy performance like I can't run an iPerf within a browser, for example. So we needed way more control than what a browser plugin could achieve. And so we started developing a testbed that we call LEOscope. And this gave us enormous control because I can run any experiment that I can encapsulate as a Docker container within LEOscope. Of course, it's a much harder to convince people to develop and deploy a node on LEOscope than to say, "Hey, just have your own browser plugin, install our browser plugin and start using it." So we have coverage, we have control, but if I want to go beyond what Starlink itself does into and get more visibility into the satellite aspects of it itself, I can't do that with LEOscope because LEOscope is only at the edge and I'm only an edge node behind user terminal and cannot look into the internals of the Starlink network. So for that flexibility then you need a different approach. You need a digital twin or a simulator. We've developed one such, as well several others have developed simulators too, which gives you a lot more flexibility.
In much later work, what we started doing was to look at using public datasets. So M-Lab, or Measurement Lab, publishes these Google speed tests which are enormously useful because for example if there's a network outage, lots more speed tests are happening. RIPE Atlas has about 60 to 80 nodes, I believe, behind Starlink. So it gives you volume and it also gives you coverage, but the tradeoff is that you can only run the tests that these infrastructures enable you to do. So RIPE is very contained in terms of what you can do. M-Lab is only speed tests.
So we have these four different ways that we just discussed of using Earth-based infrastructure to measure space-based networks, but we need cooperation. So I'll give you an example from an upcoming paper that we have where we've been looking at geomagnetic storms, because we're currently in the middle of the solar cycle 25, so the peak of the solar cycle 25, which means that you see a lot of geomagnetic storms happening. But in order to measure this, we needed vantage points up in the high North, and we could only do this because we had some collaborators who were kind enough to allow us to install LEOscope nodes up in the high North. So what this goes to show is that we can only do this research collectively, together. And this is a call for people to get in touch with me or maybe even use, you can go to leoscope.surrey.ac.uk, use all the nodes that are already there, but we'd really, really appreciate it if you have a node and could donate that node on to LEOscope.
So there are many operational issues. So one issue is, you know, do we need a PlanetLab-like testbed where we have full flexibility, or can we live with something like RIPE Atlas, which has a locked-down set of experiments? We decided to go with the former because we think we don't understand LEO well yet. Maintaining the testbed involves lots and lots of engineering, much of it is just art rather than science. Nodes can go down easily. There's one node in Nigeria, for example, which keeps going down because of power cuts. One huge issue that we have is how do we incentivize node contribution. PlanetLab would say, "Bring your own two servers and then you can participate in the big network of PlanetLab." But we can't do that because many countries still do not yet have Starlink.
So based on all of these things and on LEOscope, the experience with LEOscope, we've started collecting a list of all the other tools that exist. And here is the URL, which you can go to and add your own tool, and the slides will be available later as well. So from what we have seen, there are these different kinds of tools: there are browser plugins, which I talked about; there's data, which you can expect, but one very interesting thing is data collection scripts and methods; we have emulators and simulators—it's not always clear what the distinction is, who calls something an emulator, who calls something a simulator; we have reference implementations and I think we need to see more of that in the IRTF, IETF space; we also have a few research satellites and constellations, testbeds and visualizers as well.
So what I'd like feedback on, if we have time for questions and feedback, is what categories are we missing? Would a living tools document, which is what I intend to do with this with the help of this community, would that help Space RG? And please contribute. And maybe going beyond just the tools, if you could share the tips and tricks for how to enhance this tools culture and community cohesion here, that would be really appreciated. Yeah, I'm done. Your turn.
Juan Fraire: Okay, thank you very much, Nishanth. So in case you have been building tools or using tools and so on and you are not yet on that list, please consider contributing yours. Nishanth, there was a question in the chat about what's needed to become a node.
Nishanth Sastry: Ah, nothing much. So if you give me ten minutes, that might be helpful. Yes, definitely. So it's very, very easy. So we ship an Intel NUC or similar to you or if you have one, we can just use that. We flash an image and you just stick it behind a Starlink user terminal or a OneWeb or any other LEO network user terminal. We are also happy to include GEO as well. So if you basically have a space satellite-related user terminal and can stick a little device behind it, then you're good to go. About half an hour is all it takes. Yeah, it's just a VM behind a Starlink is how you think about it. And each experimenter, this is answering Warren Kumari's question, each experimenter gets a Docker container that they can use themselves.
Jörg Ott: Sorry, not in the queue, Jörg Ott here. So this is really great activity. Thanks very much, Nishanth. So this is really fantastic for a research group to have these testbeds and these tool collections. For the question here on the taxonomy, yeah, so you can think about, right, so I mean, how often will you expect updates to this? But not everything needs to be an ID in the first phase. So if you want to start this, a wiki page is just as good and more important is that somebody starts it and then it gets populated quickly. And yeah, just there is no need to do an ID, but it's a really great initiative.
Nishanth Sastry: Definitely, thank you. Yeah, wiki page is much easier as well. Yeah.
Juan Fraire: Cool, thanks much again and again, please remember to contribute. This gets us to our next talk. Thanks again, Nishanth, and this will be Juan. Give me one second to reorganize this. Yes. All right. Hello, everyone. I'm going to provide a quick update on the code to describe satellite constellations we have been working on, the group together with Maxime Pirot from Aerospace Lab in France.
Juan Fraire: So, in the last session of Space RG, we had a quick presentation introducing what is a simple and generic way of expressing constellation topologies that we can use to replicate and do research on them. And this is an evolution of that presentation.
So we are faced with the challenge of categorizing and describing a satellite constellation in research, but constellations are a very sophisticated element to describe. They involve orbital mechanics, orbital perturbations, coverage, inter-satellite link properties, etc. So it's important that we find a way to name them in a reproducible manner so that we can also make reasonable use of the more than 60 tools that Nishanth has just presented in a few minutes ago. But naming them in an accurate manner is challenging. So for those familiar, you might know already some of the catalogs online such as Norad that provide us with these TLE files that describes a satellite snapshot and orbital position that you can use it to propagate into the future understand where a satellite is going to be. So this is public and available, but the problem of Norad catalogs is that they only express existing constellations, right? And for research, we want to explore hypothetical constellations, hypothetical configurations, so the Norad catalog is actually limiting in that aspect. Secondly, what is really important for us from the networking perspective is actually how the links are established and evolving in time. And unfortunately, TLEs are not there to describe this, so we are missing a way of expressing how these links are actually described and this is the key focus of the presentation today.
So what we intended by starting this work was to actually come down to a common notation so that we can in an easily and reproducible manner refer to a specific satellite constellation of a specific dynamics with specific link communication characteristic so that we can unequivocally refer to it across the different tools and uses. So we try to honor such a coding or naming approach to be somewhat simple in a way so that we can actually don't we don't need to be orbital mechanical experts to actually understand it or actually creating it, but we still want to be realistic in the sense that we want to be able to represent the real systems from that code. But we also want this to be usable. So we want a code that can be expressed in a convenient format and this can be shared across the researchers.
So one key differentiator of the satellite constellation families that we have is the Walker Star and the Walker Delta topologies. These are two very famous and popular constellation shapes that basically split the constellation families into two worlds. And this is the first key element that we consider for the constellation code. The Walker Delta and Stars are actually depicted in this figure. In essence, the star constellation shape expresses a shift in the RAAN angle, which is the angle that basically rotates the orbital plane across the equatorial plane across from 0 to 180 degrees, while in the Delta constellation, it is rotated throughout the full circle. There is also a preference, and this is not normative, but it's typically assumed like this, that the Delta configuration actually uses a slightly inclined orbit as the one we see on the right hand side, while the Star constellation are actually mostly using polar orbits which are as we see them on the left hand side. And these are mostly constellations used by popular systems nowadays. And this is the first element we have in the constellation code. So in the constellation code, the first element we define is whether if this constellation is actually a Walker Star or Delta. And then we have the remaining important parameters to define that orbital configuration, so namely the altitude and the inclination. These are the two immediate elements that follows. And then of course, the total number of satellites, the total number of planes, and therefore the total set of satellites that you have per orbital plane. And there is a phasing factor as well that actually informs us of how shifted satellites, neighboring satellites are in the neighboring plane with respect to the local plane. This is a trick that most orbital constellation uses to provide a let's say an homogeneous coverage around the surface. And this means that with just one line, we can actually express a constellation shape. And then by using some ABNF grammar, we can also make a bit of more powerful expression from this so that we can express for instance multiple shells. So we have different shells of constellations with different constellation codes like the one I'm showing here, and by this we can actually express constellations using multiple shell approaches such as a Starlink for instance.
And these are some examples of how we can, using this constellation code, we can express existing constellations like GPS, Iridium, OneWeb and a Starlink as we see here. And it's quite convenient to use. It's just one line that we can share across the community and we can refer to a unequivocally to a specific satellite constellation.
But so far, I got to the point of the orbital parameter, so namely the position of the satellites and what is the physical topology looking like. The evolution that we did in the second version of this draft has to do with how do we express the connectivity patterns that emerges from such a constellation. To this end, we proposed a YAML file that extends the single liner that I just presented with some information regarding which are the link patterns that each of the constellation line that we define can actually have. And here we see that we define basically what is a rank and plane dimension, so namely we have neighbors across a plane and we have rank satellites within the single the same plane. And then for each of these planes, ranks and planes, we can actually define what are conditions for those links to exist. And across those conditions, we can use some very simple expressivity elements like equalities and modulus there to define which are the constraints that such a satellite will have to establish links. And for instance, in this example we have in this slide, using this modulus and equation, an equality expression, we can actually create what is kind of a checkered pattern. So we have satellites that are connected across a ring, and then there is a an uneven basically yes and no satellite connection link with the neighboring plane imitating what could be a constellation with only three inter-satellite link terminals, one to the front, one to the back, and one to either of the sides, which is also a very useful topology in many existing satellite constellations. And by this kind of format, we are allowing to express a more sophisticated connectivity pattern across constellations that can be also put in in an easy to understand format and also easy to share across the community.
So yes, this format is expressed in the version one of the of the draft. So we can define Walker Star and Delta constellation. There is this simple grammar to express in a one-liner the constellation shape and this YAML extension that we can use to also express how satellites are connected inside that constellation. And we can as I said represent GPS, Iridium, OneWeb and other constellations. So what we're discussing now to also make this work more complete, we want to focus as well in an emerging constellation shape within the research community is called the Flower constellation, where one of the key parameters here is the eccentricity of the orbit. The eccentricity is what actually is the parameter that changes across the plane, quite specific constellation that doesn't exist in any deployed constellation so far, but still quite a hot topic. We want to be powerful enough to express those as well, so that we can also capture the research community in that in that regard. And then also consider the optical communication terminal constraints, which might be limited to be expressed with the current YAML structure we are proposing because of the different aspects of this orbital terminal typically mounted into gimbal engines with with slew limitation and so on. And then potentially additional predicate operation as well to the code.
So what we're actually seeking for the group at the moment is for feedback on whether if the current expressiveness of the of the code is complete enough for the constellations that you are working on or you're evaluating, whether if such a code can actually be adopted as a as a clear way of describing scenarios for the many, many tools that Nishanth is actually collecting on the on the tool list, so that this would be really great if we can have a unique way of expressing scenarios so that we can also facilitate the comparison and the utilization of tools across the community. And then yes, whether there are any other comments regarding scope. So for instance, we have no talked about so far about space-to-ground links. So whether should this be incorporated on the code or not? And these are the kind of feedback we're actually looking at.
So that's basically it on my side. So thank you for the time and I'm open for questions if we have time.
Juan Fraire: Thanks much, Juan. At some point, you might want to have a kind of together with the tools something like a description format flowchart of what goes in a where, what goes comes out where, and so on. So this could be a joint effort between this as an initial starter here and then the tools effort run by Nishanth. Just as a thought. Any other comments? Description formats are not the most exciting things, but they are useful. Okay, so Juan, thanks again. And this gets us to our next talk, next two talks, which are given by Jing Wang. Switching slides, stopping sharing one, you will have clicker control in a second.
Jing Wang: Hello, everyone. This is Jing Wang from China Mobile. I'm here on behalf of authors to report the draft about Consideration for IP-Based Satellite Routing Protocol.
As you know, satellite and terrestrial networks utilize different physical and link layer protocols, making it challenging to achieve convergence at these layers. What's the advantage on IP-based satellite routing? The first is standardized based for global interconnection. As you know, TCP/IP is a simple open protocol that helps break down barriers between heterogeneous networks and enable global connectivity. The second, it can reduce operating and construction costs. The use of IP protocols enables seamless coordination between terrestrial and satellite operations.
Two key challenges outlined below. The first is dynamic topologies. As you know, the satellite network topology is periodically altered by orbital motion, resulting in link disruptions and abrupt bandwidth variations. The second is limited spaceborne resources. As you know, satellite equipment has limited resources, therefore multiple factors must be taken into account when routing.
Okay, in our proposed, there are three current researches. The first, there is a draft in LSR WG that describes the extensions for predictable and scheduled changes for TVR. This draft defines a set of extensions to traditional routing protocols. The second current research is LISP for satellite networks. There is draft in LISP WG gives the adaptation of LISP in satellite networks. The third research is a new network header for software defined satellite networking to further decrease overheads in packet encapsulation solutions. Time is limited. Can I talk directly to the second talk?
Juan Fraire: Yes. Wait a second, I need to take control back, then I can upload the slides. Selection, then I can give you clicker control back.
Jing Wang: Okay, thank you. Let us talk about the second topic. It's about Consideration for Space-Based Computing Infrastructure Network.
As you know, in recent years, the deployment of low earth orbit constellations, such as Starlink and OneWeb, has accelerated. The number of satellites has exceeded 10,000, forming the backbone of a global space-based network. Besides, the increasingly global satellite network has laid a solid foundation for the expansion of data centers into space.
Okay, what's the space-based computing infrastructure network? As you know, stable and reliable satellite links offer efficient interconnection channels for in-orbit data centers. And the widespread deployment of satellites has opened the door for the large-scale deployment of computing infrastructure in space. So the space-based computing infrastructure network is defined as an infrastructure that enables the interconnection of space-based computing resource via satellite networks.
In our draft, there are three use case. The first is emergency response and disaster monitoring. As you know, during natural disasters such as earthquakes and floods, traditional communication and computing systems are at the risk of damage. So with the help, with the space computing helper, we can rapidly establish emergency computing and communication nodes to process disaster footage in real-time. And we can effectively generate accurate disaster maps and optimal rescue routes.
The second use case is environmental monitoring and ecological management. As you know, the massive raw data collected by satellites need to be transmitted back to the ground. And constrained by the bandwidth of satellite-ground communication, less than 10% of the valid data can be transmitted. So by deploying AI models in orbit to perform real-time analysis of remote sensing imagery, and only key analysis results are transmitted back to the ground. We can accurately and efficiently identify changes in the status of farmland, forest and glaciers.
The third use case is deep space exploration mission support. As you know, deep space probes often encounter significant communication delays with Earth. In the space-based computing infrastructure network, we can perform in-orbit preprocessing, compression and intelligent filtering of data collected by satellite detectors. We can reduce the amount of data that need to be retransmitted to the ground, thereby effectively improving the response time to satellite detectors.
The fourth use case is in-orbit training and inference for large AI models. As you know, training AI models with hundreds of billions of parameters requires a massive amount of electricity. And on-premise data centers face bottlenecks in terms of energy consumption and heat dissipation. In space, there has a lot of clean energy. The second, the low temperatures in space facilitate the cooling of in-orbit data centers.
So two key requirements are outlined below. The first is space-based computing resource monitoring. As you know, the performance of computing device is constrained by size and power limitations. And in the event of a sudden surge in demand for remote sensing data processing with a region, onboard satellite computing resources are prone to overload. Therefore, effective monitoring of onboard computing resources is needed.
The second requirement is satellite routing considering onboard computing resource status. Due to the limited computing capacity of onboard equipment is prone to becoming overloaded. And the status of inter-satellite links is dynamic. Therefore, onboard traffic scheduling must consider both inter-satellite link status and onboard computing resource status.
That's all, thank you. Any discussion and comments?
Juan Fraire: Okay, thank you very much. So these two talks actually do have internet drafts backing them up, so you can actually go offline and read further and then also comment on this further on the list. I don't see anybody in the queue, but I would suggest that you take a look at the chat channel of this meeting because a few things were discussed back and forth, they might also provide some input for your work.
Jing Wang: Then thank you.
Juan Fraire: Thank you very much. We need to shuffle a bit. Give us one second to get to our last talk, given by Yuanjie Li, who will use his own laptop for presenting because of animations. We'll try to squeeze that in. I need to, really need to stop sharing first. There you go. Do you want to use this? Yeah. Let me see what it does. Give me a... Okay. Sorry.
Yuanjie Li: So, hello everyone. I'm Yuanjie Li from Tsinghua University. So I'm very happy to share our some thoughts about Sustainable Scaling of Satellite Network under Physical Space Constraints.
So why are we talking about it? So we have seen a great success of the satellite network, right? We have seen Starlink already have 10 million customers with 220 terabytes total capacity, which is a great success commercially. However, this great success is not without concerns. So first of all, the manufacturing and operation cost of satellites are very prohibitive, especially for the small ISPs and countries. It's very hard to build another Starlink in space, right? It's very expensive. The second issue is about monopoly because, you know, to date, only Starlink is the largest LEO constellation so far and it's very hard for other countries to catch up with them. So we are end up with somehow a centralized LEO network. And the third thing is about the space safety because we have occupied so many satellites in space which raises the space collision risks which will threaten the all the humanity. So it's a big problem.
So the question we are asking is do we really need tens of thousands of LEO satellites to meet huge global internet demands? Do we really need such a large LEO network? So we don't think that's a case. So instead, we are thinking whether it's possible to build a smaller network that can still meet the global demand. So in this talk, we are going to talk about whether we can do a sustainable scaling of satellite network.
So I'm going to show you three different paradigms that may be helpful. Scale-out: whether we can shrink the LEO network size to meet the same demands. Scale-up: whether we can use each satellite to meet as many services or as more demands as possible. And scale-safe: whether it is possible to safely scale the LEO network in the harsh outer space.
Our group has made some progress in all these three directions, and due to space limit, I will just briefly talk about the high-level ideas in each direction.
So let's look at the first one. How to build a small LEO network that can still meet global demands. So what we think is that whether we can build a LEO network from this to this, like a very, very small and sparse one, right? We still want a small network with similar performance. So why this is possible? Because we observe that most of satellites in space are wasted. So if you look at the constellations, most of the satellites reside over the oceans where, you know, 70% of populations stay on the ground, leaving all these satellites are highly wasted. So if we can cut these underutilized satellites, that basically means we can get a smaller LEO network with similar performance.
So is it possible? Well, conceptually it's possible, but it's very hard in practice for two reasons. Number one, in the physical space, it's not easy to keep this supply-demand match, because we know that all the LEO satellites are moving very fast, right? You may place enough satellites at hotspots, but it's soon move around over the seas so that this supply-demand match is violated. So it's very hard to keep this supply-demand match. And secondly, matching the satellites with the globally uneven demands basically means that we are ending up with a non-uniform LEO satellite network. That basically means that we will have a heterogeneous network with very dynamic network topology, routing and switching. So that would be very challenging for our routing protocol designs.
So how to solve these problems? So we make a case for a usefully sparse LEO network to solve this problem, we call it Tiny LEO. So we explore two ideas. Number one, in order to, you know, use as few satellites as possible to match the uneven global demands, we leverage diverse yet sparse orbits to complement each other to build a non-uniform LEO network. Of course, this would make this LEO network more heterogeneous. So in order to make this networking work, we developed a new traffic engineering intent so that we can decouple this dynamic satellite mobility from this high-level networking intent and routing scheduling.
So how does it work? Let's look at each one. So the first thing is whether we can build a non-uniform LEO network. So what we observe is that we can manipulate the orbital parameters to match heterogeneous demand across latitudes, longitudes and over time, right? You can see that if we change the inclination angle of the orbit, it will match people match users across different latitudes. If we change the right ascension angle of the orbit, it will it can match users across longitudes. And if we change the period of the orbit, it can match temporally varying demands. So basically, we are combining different orbital parameters to form heterogeneous orbits to match each other.
So you can think of this question as a sparse signal recovery problem. So think about this: you can think of the global user demand as a video, right? At each moment, there are some pixels over the earth with different, you know, demands. And you want to use as few orbital textures to match them as possible so that you can recover this demand using fewer satellites. So this is very similar to video compression. So we borrow some algorithms from video compressions to construct a sparse network, which is called Compressed Sensing. Basically we can for for each orbit, we can construct some orbital textures so that can match part of the, you know, global demand on earth. And then we have different orbital parameters, different orbits, right? That can match match part of the user demands over the world sometimes. And then we develop some, you know, compression algorithms so that you can combine them together to use as few satellites as to, you know, meet this uneven global demand. So if you're interested, you can check out our research papers about it. So using this technique, we can greatly cut the number of satellites with very minor performance loss. So you can see that we can save two times to 7.9 times fewer satellites compared to state-of-the-art Starlink.
The next question we're going to solve is how to make this sparse LEO network usable. You can see that now satellites stay on heterogeneous orbits very with very different motions. And we have thousands of satellites like this, right? That basically means we will have very heterogeneous inter-satellite links and topologies. This will have an impact on both our control plane and data plane. On the control plane, that basically means that we will have very frequent satellite routing changes, topology changes. If we still think from this traditional logical satellite networking perspective, this would be a disaster because you have to keep track with this frequently changing topology. That would cause a lot of signaling overhead. And at the data plane, because of this topology is very dynamic, so we will probably end up with packet loss, loops or even detours. And it's very hard to meet this high-level traffic engineering intent.
So how to solve this? So what we found is that we try to decouple this high-level networking intent from this low-level dynamics because in reality, most of the operators don't care which satellite will enforce this routing. Instead, they will only care about, you know, what networking intent they want to enforce. And regardless of this satellite mobility, you will see that the user's geography or the location still remain unchanged. So in that case, we can define a new abstraction for our high-level satellite topology. Instead of defining this topology at this inter-satellite level, we define a geographic topology among different users, right? And then we can leverage the predictability of satellite orbits to compile this high-level geographic topology into low-level runtime satellite topology.
So why this is helpful? Because from this high-level routing and traffic scheduling perspective, we don't need to care about this low-level satellite topology. Instead, we focus on this more stable geographic intent. We can try to schedule this traffic at its geographic level, which is more stable. And then at runtime, we use the data plane to enforce it. And we know that at each geographic area, we have a fixed number of satellites, right? Instead of forwarding traffic to a specific satellite, we can forward to any one of the satellites through this geographic topology. This is called we call it Geographic Segment Anycast, which can be implemented using SRv6 paradigms. So what it means that we can define geographic addressing to enforce of this geographic roots. And then we embed this segment-by-segment route into our packet headers. And then at runtime, each satellite just follows this geographic address to forward this packet to the next hop of the geographic cell, which can be any satellite covering this cell. Then that basically means that the satellite mobility doesn't affect this overall network topology dynamics. So we shift this handling of this runtime dynamics to the data plane instead of pre-scheduling it at control plane.
So in this way, we can greatly reduce this signaling overheads and we end up with very, very stable, you know, this geographic traffic engineering. So we end up in our evaluation we can see that it can save one to three orders of magnitude signaling costs and we can support very diverse traffic engineering policies, like shortest path routing, offloading or multi-path routing, or different kind of things. So we have released this set of traffic geographic traffic engineering intent and routing paradigms to the community. So it's an open community tool. If you are interested, welcome to use it.
So now let's briefly talk about the second issue. What we have talked about so far is how to shrink a single operator's LEO network using as few satellites as possible. Another possible way to scale up this LEO network is to reuse the same satellite to serve as many different operators as possible. Why this is the case? Let's use this direct-to-cell satellite network as an example. You see that Starlink has recently launched its mobile services. It partners with global mobile operators worldwide to provide this satellite network access to using our regular phones. What it does is that it will rent these satellites to different mobile operators. As the satellite passes by, it can serve T-Mobile in the US and can also serve Vodafone in the UK. This is a win-win game for both satellite operators and mobile network operators. Why? Because mobile operators do not have enough satellites. Launching so many satellites is very expensive. But on the other hand, satellite network operators do not have sufficient spectrum. Most of these 4G and 5G spectrum are owned by the mobile operators. So by renting satellites to mobile operators, they can scale their satellite service to more users, right? So this is a win-win game. But that basically means that for each individual satellite, you have to be able to be shared by multiple operators, right? So how to deal with it?
So we make an analogy with ridesharing. Think about this: if you call an Uber, you don't care which car you're going to rent, right? You just call it, you pay for it, and then you get the service, right? If you think about this Uber taxi as a satellite and you think about the user as a phone. The idea is that whether we can decouple these satellites from the operators so that we can enable a pay-as-you-go service, right? You can develop some tokens and this token is only for the mobile operators. You can use this token to use any to use any satellite if you want. Then this way, each mobile operator can rent as many satellite operators' satellites as possible and each satellite operator can lease its satellite to as mobile users as possible. We call it pay-as-you-go service. This can facilitate the scale up of this LEO network. So that's the second way of scaling the LEO network.
The last thing we have to be a careful with is the safety because different from this terrestrial networks, all the satellites are operating in a very crowded and harsh environment. So when scaling out and scaling up these LEO networks, we have to make sure that this entire LEO network is safe in the presence of physical collisions or even, you know, non-cooperative third-party satellites. So to understand it, you can think about this LEO network as a space fleet, right? Because all the satellites are moving fast. To avoid physical collisions, they have to keep a safety distance. And we know that we have very limited LEO Earth orbits. So what does it mean? If we want to place more satellites, we have to shrink the their safety space. But then we have a dilemma. So this is what we have found in the Starlink: whenever a Starlink satellite encounter a third-party satellite, it will do the maneuver to avoid physical collisions. However, this satellite will shrink the safety distance with its another Starlink satellite inside the same mega-constellation. Then in that case, the second Starlink satellite will do the maneuver again to enlarge the safety distance, which will further shrink the safety distance for the third satellite. This basically caused a cascade collision avoidance. It's a threat for safety.
So the problem here is that this problem will causes a dilemma between the network lifetime and network capacity. If we keep these things happen, it will exhaust each satellite's finite budget because for each maneuver, it will consume some budget, right? So we don't want this kind of cascade effect or domino effect. In order to avoid it, yeah, in order to avoid it, we have to enlarge the safety distance to prevent these things happen. But given the limited orbits, that basically means that we will end up with a small LEO network, which will threaten our LEO network capacity. So that's the dilemma we have seen so far. In order to avoid it, we are developing some, you know, fleet management solutions to prevent it. As you can see, this is somehow out of this networking scope, but what we see is that we probably need some cyber-physical co-designs to enable safe scaling during this, you know, scaling of this LEO network. We have developed some testbeds to evaluate these cyber-physical co-designs.
So in summary, so that's my last slide. So we have seen that, you know, we want to do scale-out, scale-up and scale-safe to enable a sustainable and safe scaling of satellite network. And we believe that this is not we need some community effort, especially like the IRTF, we need to do more research to do it and if you are interested, please feel free to join us. Thank you.
Juan Fraire: Thank you, Yuanjie, for the for the nice presentation. We are over time already, so just a quick wrap up of the session today. So you see that the research group is actually touching on many different topics. We have touched space data center, we have touched space protocols design from CCSDS, we have touched on constellation design and propagation and maneuver as well here, including some ongoing works by surveying the tooling that we have around and also trying to converge on constellation code all together. So if you have any feedback regarding topics or prioritization of the topics we have presented, we're very happy to take them offline towards Vienna so that we can prepare a successful Space RG session there as well.
I think otherwise, we are-
Juan Fraire: Yes, happy to close the session and then we'll see you all in Vienna. Thanks much.