Session Date/Time: 21 Jul 2026 09:00
[00:00:17] Chairperson: Alright. Hello, everyone. We're going to get started.
[00:00:24] Yorgos: Somebody in the somebody in the back would somebody in the back would please close the door. Thank you.
[00:00:39] Chairperson: So welcome to a new session for the proposed space RG group. Yes. So we're together here with Yorgos and supported by Nishanthth Sastry, and we're going to get started with today's agenda. Before, I want to to spend a few seconds on going over the Note Well notes that's applied also to this research group. So we follow the intellectual property rights of IETF. So please take a minute to go over this content. If you contribute or participate with some patented content, please make sure that this is properly disclosed and take your time to read the corresponding information that is in the in the IRTF Note Well. Then also by participating to the session, you acknowledge the audio and and video recording conditions of the group. So if we are on-site here, unless you have the the corresponding band in your neck, this means that you can be photographed. And then as well, if you jump into the mic, then, yes, this means that you are going to be recorded. So please make sure that, you consent, with the with these conditions. And also, privacy and code code of conduct apply as as well here. So we are collecting written audio, video, and photographic records of this session. So by participating, just be aware that you are acknowledging this. You have the corresponding RFC code of conduct, and anti harassment information as well in this slide. Please make sure that you have a good understanding of this before proceeding. So also as a friendly reminder, this is an IRTF group. So as such, we focused on longer term research issues, in our case, related to space protocols and architectures. We are and this is running in parallel with IRTF discussion where the engineering and the efforts are being carried on. So we are not developing standards. We are pursuing searching for agreement and consensus and collaboration among the community to try to address these long term research questions. This is the purpose of this group. Today, we have prepared the following agenda. So we have four invited talks on topics around Starlink and upcoming LEO waves of satellite deployment. We have a discussion on the limitation of uplink in low orbit systems. There is an industrial presentation on networks following up, and then I'll talk about the standardized routing in LEO networks. Finally, there are there is a group work session to present the ongoing work. This is a group work that's happening within the group on code to describe the satellite systems and therefore present a taxonomy of how we can describe on these these space networks. And then also ongoing work regarding a survey about tooling simulation, emulators, and so on that are available in the community that we could help to systematize and and and order for the purpose of of research of space and networks. Then we have a final ten minutes of wrap up and comments on AUV discussion topics. So that said, I think we can proceed with the first invited talk. So by Dan York. So, Dan, please feel free to join. Yeah.
[00:04:30] Yorgos: Give me a second.
[00:04:36] Dan York: Hi, everyone. So I'm Dan York. I'm on the staff of the Internet Society. And a couple years back in 2021, we did some work looking at the state of, low Earth orbit satellite systems for Internet access. And and ever since that time, we've been watching, monitoring all of that. So when when the call for proposals went out, I'd ask Yorgos, you know, would you would it be useful to talk about what people are seeing out there in the space? Let me begin with a question for you while we're getting the slides sorted up. What do you what are you is your understanding of ITU filings in terms of how many planned satellites there are for low Earth orbit? Any numbers? Millions. Okay. What else? Can you be more specific than millions? No? Thousand. Okay. Anybody else?
[00:05:32] Maxime Piraux: What? Hundreds. Hundreds thousands. Hundreds of thousands. All of that. 34,000.
[00:05:40] Dan York: 680. Do I hear? Okay. Oh. Alright. Well, in the next few minutes, I'm just gonna kinda look at what's going on out there in some larger ways so that we could think about from a research perspective, there's there's just a lot happening. And many you I didn't even really know about, but as I've been monitoring things. So right now, of course, the one we all know is is Starlink. And by their advertising, you would want to put one on the bow of your canoe and be out there. But they're planning to have 30 close to 35,000 satellites. Right? They currently have about 12, well, 12,612 that they've launched. I think they just did another launch this morning or yesterday, so it's my numbers are wrong, but there you go. So they're trying to that's the one everybody knows about. Right? The other one a lot of people you may not know about is they also have their military version of that, Star Shield, which is aimed to have about 1,600 satellites that are up there, of which they've launched around that. Amazon's Project Kuiper, which is now Amazon LEO Amazon LEO, let's be precise, is aiming to have almost 8,000 satellites up in space. They've launched a number of it. They're looking to start their their production Internet access soon, but that's obviously another large player in this space. You may or may not remember OneWeb has been around here for a while. They they launched about their sick their first constellation, 660 of them. They were acquired by Eutelsat. It's now Eutelsat OneWeb. Eutelsat is a longtime geo provider. They filed for another 528 that they'll be launching as part of their next constellations there. How
[00:07:21] Maxime Piraux: many
[00:07:21] Dan York: people have paid attention to AST SpaceMobile? Yeah. If you're a especially if you're in the astronomy world, you've been paying attention because these are ginormous satellites that literally are about the size of a of a basketball court, about half the size of that. And when they're fully unfurled, they're they're huge satellites that are up there, and and they are looking to be cell phone tower in space, you know, is their is their whole model. It's around out there. Link Global is another company that has also filed about 2,000. They are in that same kind of cell phone tower and space kind of model up there. They're not they're behind in that space, but they're that's what they're going for. Globalstar, how many people are iPhone users? Okay. Good number of folks. Alright. You're using Globalstar if you go anywhere. That's the the relationship that Apple's had to get you the satellite messaging and pieces of there. Well, they've just been bought by or they're in the process of being bought by Amazon who is going to be bringing that into their Amazon LEO network, etcetera. They're one of the old the original LEO constellations from back in the nineteen nineties that were there. They've filed for a new a new constellation of 1,946 satellites that are out there. But that's that's all to be integrated and part of that new world and things. Do you remember Iridium? Okay. Yes. Alright. Iridium has been around again since the nineteen nineties. They have also, they've been acquired interestingly by Rocket Lab. People know about Rocket Lab? Yeah. Okay. They're another one of the new launch providers, but they're interested what the media reports were. They're interested in being a a, you know, single vertical like SpaceX in being both a rocket launcher and having their own constellation, etcetera. And so they've recently purchased Iridium to go and build out the next generation of satellites using those paths and all of the pieces that are there. Then if you look at what's happening in China, there's a bunch of different constellations. And two of the biggest ones, this one, Guangwang, is about 14,000 satellites. They've launched 200 and some odd that are there as well, and they're continuously launching, not quite at the pace that SpaceX is where they're launching every two or three days almost, but they are launching repeatedly in a constant pace. And also a competing constellation, this one is the first one is out of the Chinese state entities. This one is out of the Shanghai region areas. This one called thousand sales is another 16,000 satellites. They're also launching. They're getting theirs up there at a at a significant rate as well. Then you the other major space power that is not as represented here is Russia. They have plans for what they call Rassvet. It is either 03/2018 or 09/2024 depending upon which filing I was looking at. So I'm not somewhere in there. Information's a little scarce, but they have about 21 or 22 up there right now, and they're continuing to build in that space. So that's the ones that are there now. Now I'm just looking at Internet access kind of things. There's, of course, all of the other mapping and the IoT related items, and there's a whole other range of LEO satellites in that space, but I'm looking at the ones that are that were just there. So now we get to plant. How many know how many satellites did Starlink recently apply for?
[00:10:48] Yorgos: They had the 10,000,000 speculation.
[00:10:49] Dan York: Oh, the million that's the we'll get to that one. Okay. They just recently filed for another 100,000 satellites in in Starlink, just in Starlink, for their generation three satellites that are going up there. Now they haven't launched any because they need Starship to be able to get them up there because they're big the the bigger gen three satellites that that will be up there. But they have filed and received approval for this 100,000 additional satellites that are going on well, gone up there. Blue Origin, Jeff Bezos' company, has filed for launching PteraWave, which is an another constellation. It's outside of it's separate from from Amazon LEO, and it is designed to provide to high speed. It's looking at optical download optical downlinks, I mean, and some other different capacities to go and provide this kind of, high speed Internet capacities there. Iris two is the European Union's look at how to go and and build that. It's out there. It's been delayed with some of the the the challenges they've had with looking at lining it all up, but Iris two is one of the constellations that is certainly being pursued by the European Union out there. Telesat out of Canada has been looking at getting a a a a satellite their light speed constellation up there. It was originally 300, then it was one ninety eight. There's another filing for 1,600, so I'm not exactly sure on the numbers around that. But it has received significant financing from the Canadian government. Telesat is a is it was a formerly a state and private and all of that. It's a geo provider for a long time. So they're looking at launching these. A common theme for many of these is they just haven't been able to launch. There's a general issue with getting, you know, rockets to be able to launch these things in the space. But here's another one coming out of China. There's a proposal for a 10,000 satellite LEO constellation on the the Hanwha three. There is also a company called Meridian Space. This is an interesting one because the launch platform have you seen about Spinlaunch? I see nodding heads. They're not gonna use a rocket. They're using a kinetic launcher system that will go and fire the things up there. So it's also being proposed for almost 1,200 satellites that are going out there. And then here's an interesting one coming out of India. This is actually just this past week. It was approved by the Indian Space Agency to go be filed with the ITU, so it hasn't even been filed there yet. But this is coming out of the the the folks involved with Reliance Jio, which is, if you're not aware, one of the largest telecommunications companies, etcetera, in in in India. So significant backing behind that. They have a lot of interest in in sovereign constellation and having control over their own kind of thing around that. I would suspect this one of all of these will probably go forward in some way. They also have launch capacity through the the Indian Space Agency as well at some point, although that's not confirmed around that. Another company called Logos Space has filed for about 4,000 and some odd. They're looking to do private networking or enterprise networking in space and and connecting around to different places around this. And then we get to another interesting one that came up earlier this year. There was a the Chinese Institute for Radio Spectrum Utilization and Technology Innovation filed for almost 200,000 satellites in two different batches. And as you could see there, 96,714. I don't know precisely why that number, but that's what they filed. There's probably some mathematical reason for it. But they, they have filed in this. No white no information about who's gonna launch this, who's behind it that I could find, but it is, you know, at least filed for the spectrum for the launch slots or or the, altitudes, the orbits, all that kind of space around that. So those are some of the ones that are there for this. Then the final thing, we get into ODC as the new language is. Right? And you I heard people down here saying, this one, of course, has been in the news. SpaceX filing for 1,198,120 satellites for orbital data center network because everybody wants to put their AI compute up into space. So this is the largest of these that are being out there, and they did put a demo satellite up there. It's being called they call it StarMind or other pieces. So that's SpaceX's exploration around this. They're not alone. There's a company, formerly called Lumen Orbit, which renamed itself Star Cloud. They're planning to launch 88,000 satellites up there as orbital data centers. And, Blue Origin, not to be left behind, also wants to go and do this. Interestingly, they're looking at using the PteraWave LEO constellation as the way to get information back down to to Earth. So it would be a complementary, you know, thing if you have all of your your project Sunrise data centers using TeraWave to get back down to the ground. And then another company called Orbital Compute is looking to go and launch a 100,000 of these orbital data centers up there as well. And then a company called Cowboy Space is looking to launch their stampede orbital data constellation of 20,000 satellites that will be up there for orbital data centers. And then Google has also announced their project Suncatcher, although they have not put any grand glorious numbers around that other than to say that they too want to be in the business of creating orbital data centers, and we'll be doing some work around that. So anybody wanna refine their guesses?
[00:16:51] Lin Han: Millions still.
[00:16:52] Dan York: Millions still. That's such a vague answer, Warren. Alright. So if how many people are familiar with Jonathan McDowell? Alright. He maintains he's a retired astronomer now, moved back to The UK recently, but he maintains his planet4589.org where he maintains these lists of con of the constellations that are out there. And if you want us and most people seem to refer to him because he's the one who's really doing a good job keeping up with it all. But if you look at his numbers between the mega constellations and the large constellations, it right now comes in at this. Yes. 2,345,078. Now how many of these will actually be launched given the current lack of launch capacity? Who knows? You know, it's not not very sure. We could have a whole separate talk around all of that. And there's all the other questions. Right? Some of which I know Liz will talk about a little bit in some of the kind of things that go out there. But all of these things are are out there. But I hope this was a useful little summary of what's what's going on out there. If you're not paying attention, there's a lot of stuff happening in that space. And that's all.
[00:18:09] Yorgos: Thank you very much. Dan, questions, concerns, considerations? I mean given these spectacular numbers, an interesting question, you put the economic viability already up there. And so launch cost so what's your speculation when are we going to see any of that? Maybe, maybe not.
[00:18:36] Dan York: Well, I mean
[00:18:37] Yorgos: I mean, there's the ones that do the that starting does right now for connectivity. That is one sensible thing to do. Beyond?
[00:18:48] Dan York: Well, mean, launch is the big variable here. Right? Because, you know, the only company launching consistently is Starlink and and one of the companies in in China that's doing somewhat consistent, not at the same pace as Starlink, but the you know, but outside of that, everybody else is is stuck. You know? They can't if you look at Amazon's Amazon LEO, was it three years ago, they signed the largest launch contracts, set of launch contracts ever, 83 contracts across everybody everybody but star but SpaceX. You know? And so they'd signed it with you all with United Launch Alliance, with with Arianespace, with, with Blue Origin. And none of those rockets are launching at the pace that they need to be able to go and and work. So, you know, these are wonderful dreams on paper. Well, for the for the companies. There's a lot of other reasons why they're not wonderful. But for the companies that are here, the question is just how will they actually get things up in there. And right now, that's not clear until we see more of that. But you're seeing a separate whole conversation would be the the enormous ecosystem of launch providers who are trying to get into this space to be able to go and launch. Probably the most successful of those is Rocket Lab, who's now acquiring Iridium, to try to be that like SpaceX to have a whole story a stack on there. But, otherwise, it is you know, everybody's trying to figure out how to do this.
[00:20:09] Yorgos: I suspect one interesting thing is going to be the, sustaining number of satellites in orbit. Right? If you're if the the the current LEO lifetime is somewhere in the order of three to maybe five years depending on where you are, and that that you can compute how many satellites you need to launch every day just to sustain a number in orbit as opposed to growing it.
[00:20:34] Dan York: Yeah. I mean, sustainability. Right? How do you keep if you're if you're putting down below 600 kilometers and they're and they're and they're coming down in here and you're you're they're only up there for, yeah, three to five years, how do you keep the pace to keep those up there and keep this all sustained in some way? Let alone the environmental issue of, you know, if you're having 50 or a 100 of these things burn up in the upper atmosphere every single day, do we have any sense of what that's actually doing to the upper atmosphere?
[00:21:06] Maxime Piraux: I see we have a queue.
[00:21:07] Yorgos: We have a queue. Yep. So thanks much, Dan. This is We have
[00:21:13] Chairperson: a queue. We have a queue.
[00:21:15] Yorgos: Okay. We have a queue. Now I see a queue.
[00:21:17] Dan York: Oh, Nintendo. Hey, Nintendo.
[00:21:19] Maxime Piraux: Go ahead.
[00:21:19] Nishanthth: Hi. Hi, Dan. Great as always. Fantastic talk. I want to continue with the line of questioning that was already happening there, which is I feel that many of these filings are essentially business decisions, like companies highlighting that, okay, putting their foot on the ground that, okay, we are also interested in the space. Can you comment on slightly, like, okay, how much of this, you know, numbers that you show is practically possible with all of the companies that are actually controlling the missiles costs and other aspects like that? What is the numbers that we're actually going to see, in, like, ten years from now?
[00:21:56] Dan York: I if I had a magic answer to that, Nishanthth, I I don't know. I mean, the reality is every time I think there's a barrier to that, I mean, there's people throwing insane amounts of money, especially when you put AI on anything. Right? You just are attracting enormous gobs of money into things. So I I don't know. I think the we'll see certainly over the next several years how much of this is really sustainable in in terms of the financing and the pieces around that. But I wouldn't hazard a guess because we're seeing so much money being thrown into this right now.
[00:22:31] Yorgos: The related question is the return on investment. I mean, the more stuff you have out there, the smaller is the delta that you can actually gain per per per per unit per satellite. We have Carlos in the queue next.
[00:22:43] Carlos: Yes. Hey, Carlos. Hi, Dan. Wonderful presentation. Thank you very much for that. I remember having an Iridium phone back in the days of y two k because our government was concerned that the whole thing was going to crash then. So besides the joke, I I would like to ask a clarification question. When you say a company files for a constellation, who's the proper authority? And since you mentioned Russia, China, and The US, if there is any coordination between these authorities in regards, I don't know, orbit heights or orbit planes and things like that.
[00:23:18] Dan York: So so this is an interesting aspect of that. And the reason why you're seeing things like those two enormous China filings is because the way it works is that the national authorities file with the ITU. And so, ultimately, the ITU is the the the holder of the of the list of of filings. They don't directly regulate that, but they they're the holder of the filings that are there. But it comes down to the national regulators of each country are the ones that must approve the filings, which then go to the ITU. So in the case of the Reliance Jio, they got it through the Indian Space Agency, which then would go and do that. In the case of The United States, it's the FCC who goes and so the companies like SpaceX and Amazon file with the US FCC first, get approval there, which then gets sent to the ITU for for going there.
[00:24:15] Carlos: Which which part of ITU? ITU R? Are you Intel side? What which division within the ITU does that? I I think it's
[00:24:23] Dan York: isn't it r
[00:24:24] Chairperson: because Must be r.
[00:24:25] Dan York: If it's not it's not right. ITU R. They're actually filing for spectrum and the spectrum usage and the orbits, inclinations, all of those things. I think it's a r. Thank you very much. All these years I've been saying that, I don't actually know.
[00:24:39] Yorgos: Ali?
[00:24:41] Chairperson: Hi. Ali Rezaaki, sustain RG co chair. We have recently had a workshop in which the AI data center challenges were discussed. And there, it was a prominent feedback that local communities should have a say where the data centers are operated. Now I see a extension of that here, but I don't know, like, if country regulation is sufficient. Like, the world population, shouldn't they have a say on who launches these satellites, how many? And it's it's a question we should raise, I think. It is it is, like, in your list, maybe you should add that the governance aspects are, I think, an extension of a different era when maybe a couple of satellites were launched a year. Now millions are requested. It's there is some incompatibility. I see.
[00:25:53] Dan York: Absolutely. I mean, the IT reg setup was done at a time when exactly that. You had 1,800 and something geostationary slots, and so you could assign those. You you filed for those kind of things. It was all in a different era that was much different than today. I there's but, otherwise, it's just this mechanism we have today, and I don't see that happening or changing with the amount of money being thrown into it, especially by corporations in various countries. Yeah. I agree,
[00:26:25] Yorgos: though. Yep. Okay. Please don't forget to get out of the queue again once you have spoken. So so next is Gianpaolo in the queue.
[00:26:38] Gianpaolo Scalone: Hi. Gianpaolo Scalone. So what do you think about the approach of satellites such as AST, so to have bigger antennas to reduce the number of satellite in orbit to have the same coverage, so to have lower pieces of
[00:26:56] Dan York: I am experiencing how hard it is to hear up here. So I think
[00:27:00] Gianpaolo Scalone: I I was saying, what do you think about the approach of big building bigger satellites such as AST? So to reduce the number of satellite in orbit to have the same coverage and so instead of having thousand and thousand satellite having coverage with the
[00:27:16] Dan York: Like, if everybody would interoperate and work together instead of sending up their own separate constellations?
[00:27:21] Gianpaolo Scalone: Bigger antennas. Yes, sir.
[00:27:23] Dan York: Yeah. Mean, it would be wonderful if people could, you know, interoperate and work in those kind of ways, but I don't think the the commercial incentives are not there. Everybody seems to want to launch their own set of satellites and and have it go there. I'm not sure how we change those commercial incentives because that seems to be what everybody wants to do right now.
[00:27:46] Yorgos: Curtis?
[00:27:48] Curtis Heimerall: Hi. Curtis Heimerall, University of Washington. I think it's kind of an kind of an add on to the last question in the sense, I'm sensing a lot of skepticism in the room. I I both up there and in the audience. And it feels like these kind of questions are very hard to start to answer in a highly skeptical world where I don't believe that they're going to build anywhere near that capacity. How do I figure out the economics, sustainability of that? And similarly, what does the IETF, IRTF have to do with this ecosystem given the highly commercial nature of it? So, like, where do you see levers for external actors, researchers, policymakers, engineers to have any influence on the trajectory of this set of systems?
[00:28:33] Dan York: It's an excellent question. I think one of the things is that we're just right now, there's this mad rush to launch, and the conversations are not happening or not happening enough about these other questions. You know, we just gloss over the fact that we're looking that we've only ever had 10,000 satellites ish in space, and now we're looking at going to 2,000,000 or or even if we don't even get take half of that. Take a third of it. It's way more than we've ever had out there, and we're not asking these questions. I think there's very real research questions around space debris, around the the the climate issues, around all of these kind of things. And and, also, you know, there's a centralization aspect too. If we all start to wind up using some of these large space based systems that are under the control of a few small entities, and it actually makes it so that other, you know, terrestrial systems don't work as well, is that good for us for an overall eco Internet ecosystem? I think not. I think we need to be talking about those questions and researching those around centralization, around climate, around economic sustainability, around space debris, all of those, and getting that information out more. Now the hype machine and the money behind this is huge. So it's an uphill battle to try to go and and make sure people understand that that these can be life changing I mean, I don't wanna diminish the fact that these can be life changing connectivity to people in many different ways. But the amount of all of these systems, the way that are up there, you know, can we truly sustain all of these? And what happens when somebody goes bankrupt and they go away? And all that stuff is still up there. There's a lot of those questions. Go ahead.
[00:30:13] Rick Taylor: So really is, Rick Taylor. So a very quick answer to the previous question. Yeah. I what does the ITF, IRTF have to do with any of this? There is a vast amount of money being spent to build communication systems that will interact with the Internet, and that that final part is the important bit. Yes. And we know how we allegedly know how the Internet does and should work, and so we should actively be involved and engaging with these corporations, many of whom are here or here through proxy to make sure that what is built continues to be as heterogeneous compatible and interoperable as the current Internet. And and that would be my answer to that
[00:30:59] Dan York: question. Perfect closing answer.
[00:31:02] Yorgos: Okay. Thanks again, Dan. That was this is actually a great great piece of work. It we were thinking that this might be useful thing to also collect the sources, pointers and maybe also something about the procedural approach of yours that one has actually one place to find this collection of resources rather than everybody going out for their own. And then there was a bunch of comments also made in the chat of other constellations that one could then add to it. So we'll chat with you about that. Okay.
[00:31:32] Chairperson: So we move to our next invited talk, Liz Izhikevich from University of California. The title of the presentation is the limitations of LEO Uplink.
[00:31:43] Liz Izhikevich: Okay. Okay. Thank you very much for the invitation. So hi, everyone. I'm Liz. I'm a professor at UCLA. And so I'm going to be speaking about some work that is a derivative of a larger piece of work that has been put together by me and my colleagues, listed all there. All authors have had or currently have affiliations with Netflix as a disclaimer. And most of this work has been done by Amanda Tran, who is the my lead PhD student here. So I'm going to be talking about low Earth orbit satellites as well, and particularly their uplink capabilities or the ability to send data up the network. And why? And that is because LEO Uplink enables a lot of important applications that we rely on upon today. One is real time video conferencing that requires a good Uplink connection, large file uploads, cloud backups, remote sensing, or just any type of live video upload, our interactive cloud and edge applications. Right? They all rely on our ability to send data up the network channel. LEO uplink, however, is a limited, shared, and dynamic resource that operates quite differently than the downlink resource that we most often study today. So first and foremost is Internet service providers generally provide significantly less uplink capacity compared to downlink, usually on the order of a ratio of nine to one. And second of all, when we have multiple dishes so on the bottom there, I'm depicting cell, a geographical area where we have multiple dishes from you might own multiple or your neighbors might have one and you might have one. When they're in the same geographical region, they may contend for the same satellites and therefore the same resources, which in a reality is similar how it might be on the terrestrial infrastructure. And then also each dish can experience sudden bursts of workloads. So oftentimes when we're uploading something that that happens in bursts and then there's a quiet period. And so with this in mind, what we set out to study was how does balancing load across multiple dishes affect LEO uplink performance in the real world today, and what are the bottlenecks and limitations? So the setups that we have and the data that I'll be presenting come from a setup of five Starlink dishes that were put on the roof of a Netflix building in Los Gatos, California. They are all hooked up to Starlink's business priority plan, which is one of their best plans. And this plan promises a downlink capacity of between a 130 to 300 megabits per second and an uplink capacity of roughly between 20 to 40. And this is quite standard in what you see today in LEO. These experiments are going to be UDP traffic that were sent to and from nearby destination. And let me show you what we found. So when you take a single dish, ignore the others, and you stream at 30 megabits per second, so this is the sweet spot that you've been promised, What I'm showing here is on the x axis is our time of our experiment at the granularity of seconds, so from zero to a hundred eighty seconds. And on the y axis is the loss rate. So this is the percent of packets that actually made it to its destination. And as you might quickly see, there are enormous bursts of packet loss rate where on the order of roughly fifteen seconds, perhaps 80% of your traffic will just not deliver to the destination. And so what we find is that these actually correspond often with the the fifteen second delimiters that STARLINK has when it reconfigures its LEO satellite topology. So this is, as you can imagine, concerning. And so what we found is, okay, well, how does that relate to your sending bit rate? And so what we find is that it it does actually correlate single dish packet loss increases super linearly with the increasing sending rate. So in the middle, in the black box, that's the 30 megabits per second result that was derived from the prior graph. You have an average loss of of still close to zero, although the bursts, right, creep up the outliers. And then as you go lower, your loss does decrease. But as you go higher, you know, if you try to send up 50 megabits per per second, then your loss starts increasing. And then at a 100 megabits per second, you can try. Right? You haven't been promised that bandwidth, but you're pretty much losing all of your packets. So why might this be happening? Well, as it turns out, nearby dish contention increases packet loss. In the single dish experiment, it was due to our neighbors, but we can actually recreate this using our five dishes. So the way you can test this is on the x axis, what we're doing is we're starting dish by dish, and we're starting to stream 30 megabits per second of traffic up. So on the very left, it's our one dish at 30 megabits per second, minimal packet loss. Then we turn on the second dish, still fairly minimal packet loss. But as we turn on the third, fourth, and fifth, so by the end, we're collectively uplinking a 150 megabits per second. Again, this is bandwidth that we've been promised we should have. The packet loss increases on average. Just 20% of everything is always gonna be dropped. But in in the worst case, sometimes, you know, 40% of everything. So what this means is that we actually have this, effectively, congestion. And if you look into the data more and more, what we find is that this happens often due to you being connected to the same satellite as your neighbor, and therefore, that satellite doesn't have enough resources to get all your traffic through. So, of course, a natural derivative to this question might be, well, how does distributing total traffic sending across dishes help decrease packet loss? So here in this experiment, what I'm gonna show you is we start with we wanna stream out a 100 megabits per second. So as we add more dishes to do the same workload, how might that help? And so, yes, it turns out distributing an aggregate sending rate across multiple dishes will decrease your packet loss. If you, on the very left, stream a 100 megabits per second up with one dish, the majority, nearly the majority of your packets get lost. But if you take the 100 megabits per second and divide it into two, so now you have two dishes streaming at 50 megabits per second, the packet loss goes down. And if you take all five dishes and distribute your 20 megabits per second, then your packet loss is again near zero, although not at zero. So you still have significantly more, orders of magnitude more packet loss than you would on a terrestrial network. And now if you are uploading something doing real time video conferencing, this is still a problem. Now another way to depict of what's going on is here, we are showing the loss percent. So x axis is time, y axis is loss percent of all five dishes at once. Each color is a particular dish, and that is their loss percent plotted. And what you may find is specifically between the time of thirty and forty five seconds is that all five dishes can experience loss simultaneously. So although when you use five dishes and you're streaming at 20 megabits per second up, your loss is near zero, there are chunks of time where your loss is still sixty, seventy, 80%. And there's effectively nothing you can do about that because you happen to have all connected to the same satellite and have contended for the same resource. Now how does packet loss affect the total uplink good put to how much you're actually able to push forward? And so what we find is that if you have five dishes, your bonded capacity scales roughly up to a 100 megabits per second. And then at that point, if you try sending traffic through, the amount that actually gets delivered really just plateaus. So your sending rate bit rate is there on x axis, y axis is the aggregate received. And so effectively, at ascending bit rate per dish of a 100 megabits per second, you can get roughly 200 megabits per second good put out, but you can never really reliably get more than that. And finally, in a fun experiment that we thought you guys would enjoy, is we heard a rumor that if you take up more downlink usage so if Starlink detects that you are a big user of their data, and so in this particular case, we're going to download at 200 megabits per second, then potentially, you might get allocated more capacity in general and therefore be allocated more uplink. And so we decided to put this to the test and found that it technically is true. So what we did is we before doing the experiment, we here, we're plotting a CDF where the x axis is the uploaded bits per second. The blue line is is our starting point. This is our fraction of of samples of the of the data collected. And so what we found is that our distribution is over there at the left. And then what we did is we streamed for ten minutes. We downloaded at 200 megabits per second data. And then we collected again. We run the upload experiment. We say, okay. Now how much are we actually able to to upload after streaming down? And what we found is we got roughly nearly twice the amount of capacity allocated to us. So there is some interesting traffic engineering and reallocation of resources going on. And then we did effectively the same thing again and found that it it roughly plateaued, meaning that it worked the first time, but then we didn't get allocated even more data. So, you know, whether or not this is something that one wants to use as a trick, who knows? But this just shows to you that this type of traffic engineering is going on, and everyone's effectively contending for resources, and resources are getting dynamically shuffled in Starling.
[00:41:45] Yorgos: This, have two people in the queue. I'm not sure whether they wanted to ask something to these specific slides and would or do you wanna have the questions in okay.
[00:41:52] Liz Izhikevich: Later. I'm near the end.
[00:41:53] Chairperson: I Okay.
[00:41:54] Liz Izhikevich: Left plenty of time for questions. So what I've showed you here, really, is that LEO Uplink contains very serious bottlenecks. This Uplink traffic experiences multi second bursts of packet loss due to neighboring congestion, whether it be you are your own neighbor with multiple dishes or you have neighbors that you simply cannot control. And operating more dishes does increase aggregate capacity, so that is good, but it does not eliminate the shared loss events or contention. So if you have very strict criteria that you cannot sustain any loss of packets, this becomes a a big issue. And so what this means for us actually as the the research community is that we need protocols that adapt to these bottlenecks. We need to assume that they're there. We also should assume that most LEO users only have one dish. And so we need, for example, transport layer protocols that can actually recover from high losses. We need application layer algorithms that can adapt to these network fluctuations and also, again, these high losses. And we do need better traffic engineering, Leo wide, you know, whether or not which particular service providers might be interested, you know, is is a question out there. But, clearly, there are there are issues. And so, yeah, that's all I have. Thank you.
[00:43:09] Yorgos: Thanks much, Liz. Okay. We have Warren first.
[00:43:13] Warren Kumari: Warren, Kamari, Google. Thank you. This was fascinating. Apologies if you mentioned this, and I just missed it. But you said you put five dishes on the roof in your office. Where is the office roughly? Just so can guess how many other people were also
[00:43:26] Liz Izhikevich: Yeah. So it's in Los Gatos, California,
[00:43:28] Rick Taylor: in the Bay. Okay.
[00:43:28] Warren Kumari: Yeah. And then for the can we go back two slides?
[00:43:32] Liz Izhikevich: Of course.
[00:43:33] Warren Kumari: The incentive model here seems like people are just gonna start running constant bit rate things that are always, you know, maximizing their download capacity for a while at least till Starlink catches on. Right? Like, your incentive model is to be downloading constantly as much as you can. Yes.
[00:43:51] Liz Izhikevich: Although, you will then pay more for the data, and so it's a question of the how much does it matter to you, etcetera. Yeah.
[00:43:58] Tony Lee: Hi. Tony Lee, HP. Were you able to observe the association between your dishes and their uplink satellites.
[00:44:08] Liz Izhikevich: Under under which satellites?
[00:44:10] Tony Lee: And the uplink satellites. Because with five dishes, you could be all using one uplink satellite or you could be using five.
[00:44:16] Liz Izhikevich: Oh, yeah. Yeah. Yeah. So we have that data. And although I can't give you the raw data, this effectively is a proxy. And I can tell you that when they all experienced the same burst, so between second thirty and forty five, they were all connected to the same satellite. And when for example, between second 60 to 75, there's a blue line that's doing quite well and everyone else is doing quite poorly. That's because it was connected to its own satellite. And yeah. So there are many ways that you can detect which satellite you are connected to. There's an open source way where you can use the obstruction maps to understand which one each is connected to. You can also call up a friend at Starlink. Sometimes that helps as well.
[00:45:03] Tony Lee: And were you able to determine if there was gateway congestion? So
[00:45:11] Liz Izhikevich: gateway congestion, in terms we know this is not gateway congestion because of who because of friends that we had. But in terms of open data and determining if it's gateway congestion, I think that is it'd be interesting. I don't know if there are any measurement techniques that exist today that can piece that apart quite easily.
[00:45:34] Eric: Thank you. Mhmm.
[00:45:38] Nalini Elkins: Hi. Nalini Elkins. So can you bring back your slide with the neighboring congestion thing?
[00:45:47] Liz Izhikevich: So Which one? Which one? Sorry.
[00:45:49] Nalini Elkins: This Whereas, like, neighbors, if you have neighbors that that gets you
[00:45:55] Liz Izhikevich: This one?
[00:45:56] Nalini Elkins: No. No. I think or or maybe it was. But, anyway, the you have that concept. It's like if you've got, like, a bunch of other people around, were you saying that that that causes condition too? Because, I mean, I can see, like, a potential for somebody who's not a very nice person. I mean or a problem. You know? It's like it's like I mean, I you know, it's like under what conditions? Like, you know, maybe if you're a disruptive person, then you start like I mean, I don't know who's control is is it really in some ways brings up, like, legal issues? It's like, who's controlling all this space? And then like, it's kinda like like in my neighborhood, somebody moves in and he's got a really loud dog and, you know, like, who do you go to?
[00:46:41] Liz Izhikevich: Yeah. Yeah. So this notion of yeah. You might have a neighbor that's constantly, let's say, like uploading something, and then you you rely on on Starlink or Leo, and you wanna do a Zoom call, and you happen to be by that neighbor, right, that's constantly uploading. And so because this is such a constrained resource, you're effectively unlucky in that scenario because you're constantly contending. And that's just something we don't really experience in terrestrial Internet because we have a lot more capacity available to us. And, yeah, I mean, I think this points to I I don't think there are any legal issues involved because you're each paying for a service, and the amount of uplink that you have been promised is still not a guarantee. Right? It's an approximation. But that means that we need better protocols and fairness algorithms that can help load balance between somebody who's hogging all the resources and you who might only want to use it once in a while.
[00:47:31] Nalini Elkins: No. Yeah. Well, yeah. I mean, that's certainly true. What I was thinking, were you saying that like if if I'm a dish in space and I've got, like, 10 other dishes around versus if I'm somebody in space and I have, like, nobody around, was that an impact too? If you are connecting to a satellite if you're
[00:47:50] Liz Izhikevich: in a very remote region
[00:47:51] Nalini Elkins: Yeah.
[00:47:51] Liz Izhikevich: And there are very few people around, then you have much better capacity connectivity. You will it'll be significantly better than an urban area. So yeah. Yeah. Because what I was
[00:48:01] Nalini Elkins: just thinking, like, from the presentation last time, if everybody and his brother is sticking stuff Yeah.
[00:48:07] Yorgos: There.
[00:48:07] Liz Izhikevich: So there's actually really good theoretical work done that shows why LEO satellites could never sustain the entire world population because we just have a bottleneck of how much surface area we have and how much capacity each satellite we have. Yeah. Yeah.
[00:48:23] Nalini Elkins: Sure. Yeah.
[00:48:26] Daniel Gulch: Daniel Gulch, hi. Have you talked to SpaceX on whether or not there are plans to shortening the link reconfiguration time? For example, with, like, version three of Starlink or something like this. And can you see in your data on how long the reconfiguration actually takes? Is this, like, tens of milliseconds, hundreds of milliseconds? Or, like, what's the effective, like, downtime with
[00:48:52] Liz Izhikevich: the packet loss? In terms of shortening the reconfiguration period, I have no idea. And we do see so if you squint at the dash lines, you always see this burst of packet loss because effectively that was the reconfiguration and the repointing. But this is on the order of I mean, I think no more than ten milliseconds or shorter. And that's just something that, yes, you always incur at that time. But, yeah, it's it's very short. There's better research papers out there that actually analyze, like, what's going on at that exact moment because it also affects your downlink. This is not unique to uplink. Yeah.
[00:49:32] Yorgos: Okay. Thank you. Very cool work. Thank you. Thanks so much for for bringing this.
[00:49:38] Liz Izhikevich: Okay. Thank you.
[00:49:41] Chairperson: Alright. Yep. So thank you, Liz. We invite then the next speaker, Florian Zeiger from Siemens. The talk is on the usual communication services via NTNs, requirements and challenges.
[00:50:00] Yorgos: Yes. Perfect.
[00:50:05] Florian Zeiger: So good morning. My name is Florian. I'm working at Siemens in the research department. I'm a principal key expert there for communication systems and communication services.
[00:50:15] Yorgos: Go go closer to the mic.
[00:50:16] Florian Zeiger: Closer to the mic. Okay. Better better now? Okay. Perfect. So I restart. So my name is Florian. I'm working at Siemens in the research department. I'm a principal key expert there for industrial communication services. Don't mix it up. So Siemens is building trains, locomotives, does industry automation. We are not the guys building the vacuum cleaners or the ovens. So it's about process automation, what we do. These are our customers' smart buildings and so on, and this is also required to understand why we are dealing with that NTN topic. So I will give you now a talk. Yeah, it's working. And we'll start with what I'm not talking about. So I will not talk about ATN architectures. I will not talk about the LEO constellations. I will not talk about the routing challenges, optical links, and the later on network concepts. I'm pretty sure you know all that stuff already, and most probably much better than I do. But what I will talk about is really on why do we, as industry, care about NTN. Our industrial traffic is a little bit different. I will show you what I mean by that. I will show you an example. We have a small experiment done where we do some industrial control using NTNs, and then we will talk a little bit about where current assumptions meet the industrial reality, and in the end, maybe some emerging research directions or research areas that might be interesting for you. Good. So why do we care for NTN, and what are we doing about doing with that? So it's it's pretty obvious. So we we can close coverage gaps. We can build systems that have higher resilience than just relying on one technology, bringing another one in. We can support mobility scenarios. Usually, new NTN systems, you can deploy your ground terminal very, very fast. So we talk about not even a minute, if you have done that already. And we also talk about sovereignty. And typically, use cases we have here I have depicted just six of them here are railways. So here, it's about fleet management, fleet control, train control, also remote services or maritime and transport sector. There, it's about remote services we do. In industry, we have remote outage services, so you have real remote access to complete plants. And there are really industrial installations in the middle of nowhere. Mining. In mining, you have temporary installations where you need connectivity to do your business on the ground, and then it's just for temporary setups. Or it's even dynamic. It's moving. Energy grids. With this energy transformation we are currently doing, we need a much higher degree of automation in the energy grids. Otherwise, they will break down. Also here, we talk about remote substations, which you want to operate with that. You need connectivity and specialized services for that. It's a little bit more than connectivity. I will come to that. And in the end, of course, critical infrastructures in general. Most of our critical infrastructures are pretty out in the wilderness. We are not talking about only Europe. So here, it's really about getting the services, the industrial communication services to your devices on the ground. So I have here a little bit of provocative statement. So most NTN discussions currently focus on on somehow connecting the users, you, me at home. Industrial systems are a little bit different, so we require really connecting machines, autonomous systems and safety critical services. So it's not just about using what's there and see how far you can go with it. You need a kind of quality of service with that. And our industrial traffic is different. So what I show you are just for examples where we have a little bit of a special cases in traffic. Massive telemetry. Here we talk about millions of sensors that deliver data. Just small data amounts, but just a lot of packets. Usually, it's delay tolerant. A different thing is monitoring. We talk about the time horizon of seconds. Supervisory control, it's getting a bit more tricky there. We talk about thousands of milliseconds that we need in terms of delay. We have a lot of actuators that are on ground. Packet losses are a little bit critical. And of course, closed loop control. This is pretty tricky, so we talk about milliseconds, maybe tens of milliseconds. Packet orderings are very, very important. Packet priorities are very important. And on the right side, you see just some examples. If we run our industrial services over satellites, you see satellites are coming, flying away. This is in the upper graph, for example, or the typical Starlink measurement, which we have shown also in the last presentation. If you run their industrial control with a twenty millisecond delay over that, it's exactly what delays you get out of right curve there. But in the end, industrial service quality somehow emerges from interaction between communication, computing and the control. It's really if you go to the next slide it's more than just connectivity, and I will show you that with a small example. We did an experiment. So in industry, we have our actuators, and we have our controllers. These controllers we call PLCs, the programmable logic controllers, and we have also virtual versions of that, which means I can put them somewhere in a cloud and they do control work. They control actuators. And what we did here, we took them and we wanted to do an experiment where we do robotics operations controlled from a PLC that is flying in space. So I put that on a compute capable satellite. Unfortunately, there are only a few available, we could not get access, so we had to emulate all that. So what we did there is we took link characteristics of existing systems, and we emulated such kind of a system, and we assumed that satellites can host our VPLC, our virtual PLC. Of course, these are LEO satellites. They are flying. And then we have a little bit of a programmable network below, which takes care of that controlled traffic. And you see it here. So we use Profinet. Profinet is a typical industrial protocol which we use for controlling devices. We have these Profinet connections to our emulated satellites, and then we let them fly in our emulation system. And the task was we have a robot. This robot holds a plate. On that plate is a ball, and I want to run a circle. Just a very simple thing. You see that something happens. You need some, let's say, defined control. Otherwise, it will not work. And you also see how accurate your control is because on the very right side, you see that your process quality decreases when your connectivity is not working well because then your circle looks not like a circle anymore. So what we did there really was we let that run, and then the satellite flies away, and we had to migrate. So first, of course, you need
[00:57:17] Lin Han: to migrate your controller, you
[00:57:19] Florian Zeiger: need to do state synchronization, and in the end, you also have to switch your connectivity, your communication link, from your primary PLC to the backup PLC. And that's exactly what we did in that experiment, and this clearly shows that very, very often in industrial systems, you can handle that. If you know what will happen, you can even manage sometimes a kind of graceful degradation. But this needs to be controlled. You need to be aware of that. Your application, your controller needs to be aware of that. In our example, we can easily keep that circle. For example, when we say, our quality of the link is degrading very, very soon, so I reduce the velocity the ball is traveling with. So I can somehow cater with a less strict control algorithm to do Of course, my process is then not running the most economically or the most perfect thing, but still it's a circle, which is the primary objective there. So the only thing which I want to say there is it's very, very, very difficult to just if you look only on the communication system or only on the controller, you need to have a joint view on that. And in the end, one question maybe which is interesting here in that round is which networking abstractions are needed to make that happen at scale? So what we did now is just a handful of VPLCs and one controller. I would like to have thousands of that I really want to operate real infrastructure out there, it needs to run with a little bit more than only one. Good. Next thing, some requirements, we might look closer there. One thing is predictability. I said already that unknown latency changes, they are really, really, really bad. Same also if you have variance in the delays also. And this very, very often hurts much more than a higher latency. If I know about a higher latency, very, very often I can adjust my process to that. It's just if it's all doing something, then it's getting tricky. Then in the end, the service continuity. Even if if I'm mobile or not, it doesn't matter for the satellite in the end, but the whole system is somehow mobile, dynamic, so I have mobility and handovers. This needs to be somehow managed. Failure transparency. That's what I just said. If if your application knows what your communication link is doing, it might react on that. It might even be possible if if if you know in advance what could happen there. Multipath resilience, it's it's important. We usually talk about terrestrial networks plus non terrestrial networks, so usually we have we operate a mix of that. How can it coexist? How can it converge? So if I have a multipath protocol, one thing is going over terrestrial and one over nonterrestrial. It's a pretty funny thing what will happen there. Most of the nonstream aware multipath protocols will end up in a real mess with your control traffic. Trust and security, of course, it's it's very important. We want to operate usually critical infrastructures with that, And in the end, time awareness. So all industrial systems somehow are synchronized, so this also needs to be taken care of. The last point, compute awareness. So our controllers, they are compute loads. They are small, but they are compute loads, and they move together with the traffic. This is something which you usually don't have in terrestrial networks, I'm pretty sure, or we see already, that the current, let's say, protocols are not not optimized for that, to to really cater for that. Question here, can a single NTN architecture support all of that or no? To work on that. So I also promised you to talk a little bit about where current assumptions meet the industrial reliability. I I picked out just four categories, transport, routing, computing, and operations. So on transport, it's really usually the challenge we have here is deterministic services, deterministic communication. We know what's happening there. And usually, we have one path. This path somehow reacts on congestion. And what we usually do in existing systems, we optimize for throughput. Industrial reality is here. Resilience is much more important than throughput. Our continuity of service is much, much more important than the peak performance, and we need a kind of a failover scenario that somehow you can handle that. This is really, really important. And so how how should such a new NTN system handle handle these these paths, this mobility in in the future? Second, routing. Yeah. The whole system is moving. Maybe the endpoints are also moving, so you have a lot of mobility everywhere. You have topology changes everywhere, and then you want to have an optimized path. Yeah, that's fine. But but in the end, what kind of routing is is really appropriate here? I I don't know that. Can it can it be a node centric as as we know it or a service centric one? I think this is a discussion which could be very interesting there. And the other thing, computing. We heard already that people talk about or think about putting compute centers in space. Maybe before you go to the compute centers, you have some smaller edge computing capabilities there. This is pretty close to happening, I would say. And then it's getting really, really important. So you have the compute nodes flying. You have your traffic going up and down there, the whole thing is then migrating to one or the other end. How can that really be really, really happen? So if your workloads also move not only between the non terrestrial parts, also between the terrestrial and the non terrestrial parts, because this also might happen then, how how can you how how can you deal with that? Last point, operations. So when I'm an industrial user, I I I don't buy a route. I I buy the outcome. I buy a service, and so here, it's really latency is is important. I yeah. I think I have to speed up, right? Yeah. So let's focus on this green green sentence here. How can a service intent be propagated in such a system? How can a system deal with that? So almost last slide. These are, from our point of view, some activity areas that could be of interest. So how should industrial applications express service intents in these highly dynamic infrastructures? Second would be how communication and computing resources can be managed in a single or in multi operator systems. Third, how should multipath NTN services expose the reliability guarantees? I told you it's more than just connectivity. We need a little bit more in the industry. Maybe we need industrial profiles for NTN architectures. I don't know how to handle that. And in the end, we think also about enabling somehow digital twins to predict more what these kind of systems can do and how we can build that up. Think I have thirty seconds, so for the summary, I think that's still fine. We have seen that NTNs are becoming industrial infrastructures already, so we are using it as far as it's currently possible. We are introducing service requirements far beyond connectivity. This is important also maybe to your community to think about how we can how we can do that. Communication, computing, and control must somehow be considered jointly. That's important from our point of view. And here, let's let's focus as a as a last word on this blue sentence. This I also would leave you now in in that room for the discussion, and I'm happy to share some more discussions with you on that later on in the coffee break. I think that's it now from my side.
[01:05:46] Yorgos: Thank you.
[01:05:50] Lars Eggert: I'm at ITF chair. Thanks, Florian, for bringing this to us. It's highly interesting. I just had one question on the, what you call, compute awareness. So this adapting local control loops and applications. So I understand what you presented was a bit like a prototype where you demonstrate the possibilities. Did you have a chance to think about what could be possible APIs where you expose the behavior and let application know what's going on? Do you think this could be a topic for the group here?
[01:06:24] Florian Zeiger: Good question. So in our experiment, we, of course, have not addressed it that way, but it's a very interesting point to view, to look at that. I would like to discuss with you later or maybe on that. Yeah, could be an option. Why not? Maybe this also goes a little bit into this direction of how can I, as an industrial service, express my intent, what I would like to have from that communication network?
[01:06:50] Lin Han: Okay.
[01:06:54] Lars Eggert: I know. So I mean, Eric just mentioned we also have a compute we have traffic steering work. It's a bit different topic, but just for some reference. Yeah, happy to discuss more later. Thank you.
[01:07:14] Yorgos: Yeah. Thank you very much. That was good. Let me switch to our
[01:07:21] Chairperson: last speaker. So we move to the last invited talk today by Lin Han. So the title of the talk is towards standardizing routing for LEO satellite networks, a comparative study. Thank you, Lin, joining. We are a bit behind schedule, so if we can keep the timings, that will be great. So thank you, Lin.
[01:07:40] Lin Han: My talk is about the standardization work. Actually, I worked for this part in ITF for quite a long time. And, unfortunately, many works is going on there, but there's no system systematic solution yet. And we had scattered drafts and the three side meetings already. And this ITF, we have another one. And the major issue is that we don't have consensus on whether a new working group is needed because many people think that the existing solution is good enough and just a small modification. Also, we have already had some draft proposed, but it's not standard yet. So I worked for the industry for more than twenty years, then just switched to academia. Then I find the IRTF maybe better better place for me to drive through this work. So what do we want? We want to lay down the foundation for a new satellite network routing. First thing is we we want to determine which type of routing is the most viable candidate for future standards of solution. Why we think this? Because the ITF community thinks that new standard new protocol is not accepted acceptable. The thing the existing protocol may be good enough. So we have to determine which type of existing protocol should be the candidate. Secondly is that which area we need to enhance for some exiting solution. So last one is that we we we want to drive the systematic systematic solution, not only scattered drafts. So, actually, in a both industry and academia, we have many proposals and centralized solution, distributed reactive, and distributed proactive. Also, proposal based on AI, and each one has its pros and cons. I just list here. And if you want good details, go to a paper. So here is the high level picture of 3GPP only, not for other use case. For CGPP, we have many place we have to do for the cell satellite network. And new satellite work, actually, we are we are provide the so called transport network or carrier network to wireless and also wireless access and and transport network function. So it's performance and the scalability and the reliability are most important. From this perspective, only proactive router routing can satisfy the requirements. Because it was already widely deployed and is based on the hardware pre programmed forwarding. However, the current proactive routing protocol cannot be used directly because that's have so many issues. First things is that the existing proactive routing protocol was designed for terrestrial network, and it was a relative steady, but new satellite network is not. It's very dynamic. And scalability is not enough because the current existing OSPF or IS-IS only works for about thousand nodes, but the new satellite can easily exceed to 10,000. Also, those protocol what was designed for hierarchy network, but new satellite network is not. It's completely flat network. So what we want keep and what we want to enhance? First of all, since we want to keep the architecture, is OSPF or ECS, including database and adjacency establishment and so on and so forth, and messages, some basic messages we can keep. But we have to enhance many areas such as a partitioning, convergence dependency, flooding in flooding reduction, and the key optimizations. Also, other critical works we have to do, such as the satellite address and network state fast detection, and also finally simulation is very important. So partitioning partitioning is the most difficult part for LEO satellite network because it is flat network. You you it's not as we think for the terrestrial network. You can divide the device as network as access aggregation or core. It's not because each satellite satellite will service every area on Earth. So now let her they will provide different directions. So current backbone plus non backbone partitioning will not work. And it very in limited the improvements of the message flooding. Also, they increase the complexity when when we do the realization. So we want to have a better partitioning method. Yeah. This one, I'm happy the the the other Tony is here. And this one is very very valuable, the drafts. We encountered many problems when we try to simulate it because the the the it's complete different as terrestrial network. Something is it's out of our for example, this is our simulation. We have 10,000 satellite and 50% in l one area, 50% in l two area. However, we we see many red light red dot is a kind of l two areas satellites because it's a it's a inter in interleaved network. So the l two area, for example, they have l one area satellite inside. So what what is kind of links should be? So we we don't know. That that's why we in the in the simulation, we we we encounter more complexities than the regular protocol. Convergence dependency because the IP forwarding is a hub by hub. So they have a convergence issue there, and we have to reduce the dependency. Right now, looks like second routing. Soft second routing can reduce it. But right now, it's it's both MPS and SRV six come even compressed is not good good enough because we can easily have 100 segments flooding reduction, which is tightly bounded with a partition method. So we we we have to reduce the, for example, message type and message flooding scenarios Because of time limit, I have to speed up. So address satellite address, also the inter satellite link address should be static, not changing. Even the satellite is moving and address assignment is down by the gateway ground station connect to another service provider, but we we we cannot accept the satellite addresses keep changing when they are moving. Then what type address we should use is kind of challenge. Simulation, this is most important part for our future protocol because no matter what kind of proposal we have to prove, it is reliable. It is performance is satisfactory. And we I just list a couple of requirement here, and it's a challenge even for the basic simulation platform because many people use the n s three, which is not scalable because we want a similar to similar to over 10,000 satellites, then we have to find a new way. Yeah. Other optimization, I just skip it. Yeah. That's it.
[01:16:49] Yorgos: Thank you. We have two people in the queue, Rick.
[01:16:53] Rick Taylor: So this is more of a a sort of a process question rather than a technology question. I I don't wanna dip into the tech. Where is the interoperability requirement?
[01:17:07] Lin Han: Yeah. That's a good question. So let me go. This is a very old question. People ask me why this one
[01:17:14] Rick Taylor: Yeah. Is the standard. Otherwise, it's it's great research and you can go and build your own calculation.
[01:17:18] Lin Han: Because here, you see this is a three g p p architecture. Yes. Three GPP architecture doesn't mean that you need the standard protocol for some transport network, but they are using a standard protocol. For example, they act access in the backhaul. Yeah. They don't have the interoperability requirements. Yeah. They need to run standard protocol because the device is coming from different vendor. I manufacture the satellite, but the communication module may coming from different vendors. I have to have some kind of open APIs definitions for those. We we don't want kind of closed vendors.
[01:18:04] Rick Taylor: Okay. I don't think that's how most of the vendors are thinking. I don't think Starlink are gonna open their routing. Yes. Starlink is the exception. Government are gonna Yeah. Their routing.
[01:18:16] Lin Han: I don't Definitely, Starlink is exceptional because the I'm not sure it is the exception.
[01:18:21] Rick Taylor: But I think this is IRTF.
[01:18:23] Lin Han: Yeah. Yeah.
[01:18:23] Rick Taylor: So quite happy to talk about
[01:18:25] Lin Han: Yeah. We have this argument very very old when I write some proposal. People said starting doesn't have a operability issue. Right? But you see the Starlink right now joins three three GPP Yep. For direct access, wireless access. Mhmm. Right? So at the early stages, I don't want it. But right now, they they need it.
[01:18:50] Rick Taylor: Yep. I don't I I think it's a compelling argument, and this is the other RTF. Other quick point, I believe this was reactive routing, not proactive, but that's just a detail.
[01:19:00] Lin Han: Yeah. Thank you.
[01:19:02] Yorgos: Maxime?
[01:19:03] Maxime Piraux: Hello. Maxime Piraux, Aerospace Lab. Thank you for bringing in this discussion. I think it's it's very relevant. I I could be also the advocate for, let's say, medium constellations, not necessarily the stalling, but constellations that would make this work with multiple vendors and that do need interoperability. So I'm interested in in keeping this discussion about how we can achieve satellite routing and and solve this problem. So thank you.
[01:19:30] Lin Han: Yeah. Yeah. So I think this one is still in in research topic. For example, three GPP. Right? The the even don't know the routing, how they can finish routing because I talked to them. And right now, the the major work is still focused on the the radio part. But later on, they will face it because some people to do the implementation, the the funds of the traditional way doesn't work because traditional way is that the genome b. They will do whatever the send the the the message to the core network. They don't care about the lower layer network. But right now, the the need to know what is the exact way.
[01:20:14] Maxime Piraux: I agree. There are changes to solve in the UI related flooding. This is one of them. And so I I would like to con the discussion to continue and try to solve those these problems.
[01:20:24] Lin Han: Yeah. Thanks, guys.
[01:20:28] Chairperson: Okay. Thank you, Ling, for for the talk. We move quickly to our next final part of the session today, which is the group work. So Maxime Pirotte will share up some updates on the code to describe satellite constellations. So
[01:20:45] Gianpaolo Scalone: I need
[01:20:45] Maxime Piraux: to stand here. Right?
[01:20:46] Chairperson: Yep. Alright. Rest of the mic. Works.
[01:20:49] Maxime Piraux: I get the mic this way. So hello. Maxime Piero again from Aerospace Lab. This is joint work with Juan, and so I'll be sharing a a quick update on our document to describe satellite constellation. So let me go briefly over the goals if you're not familiar with this document. So here we are trying to define a common notation or a taxonomy really to describe those satellite constellation, and this will be helpful to establish reference scenarios, architecture choices, which are much in line in the scope of the group, I believe. And then just in general help foster risk reproducible research with a set of common assumption that we can all agree on. So the goal is to capture enough parameters of those constellation to be relevant, to describe the current constellation that exists and that we know of, and then the upcoming constellation as well. We are so far focusing on Earth deployments, but we will try to remain simple enough that this can work this work can be also used for other use case such as interplanetary network, which are also which some other people within this space are interested in. So I will briefly go over the content of the document and the update we did. And one of the update is try to bring a bit of a landscape of what a satellite constellation is. And so you will find a similar diagram in the in the draft. So a satellite constellation to deliver its services is essentially spanning three kind of network. Starting from the left, we have the access network where the user equipment lives. And so this user equipment is establishing a service link to the constellation, to the satellite, to access the constellation. And then satellites together, they form what I what I call here a core network. So they form the transit network in between the access network and the ground network, will find on the right. And so on the ground network, have ground stations that would connect to the core network to this what is called the feeder link usually. And so the ground network is where the service is living, and so that's where you'll find typically point of presence, five g core network that would get you to the Internet in the case of Internet broadband access. So in the first version, we first focused on describing the constellation itself, where are the satellites. And so we captured the relevant mission parameters of the con of a constellation in a code notation. That's the original name of the document. So here is an example of a code for one shell of starring. So it's a short format where you can find all the relevant parameters to describe the constellation. It's very helpful for putting it into proposal papers. Even your command lines or tools, you can use it to to specify a constellation. Then in the next version, we focused on describing the type of links within the constellation. So we proposed the pattern system that will enable to describe the type of connectivity, whether it is a plus grid, whether it is something more more complex. And following the feedback of the group, we moved from YAML definitions to more formal CTDL schemas in this new version. So here's an example of what it can look like. I'll not describe it in details, but, basically, you have the flexibility to describe the type of pattern. So here we have two pattern, one that is describing the in orbit links, and so each satellite is establishing an in orbit link with its immediate neighbor and preceding neighbor. And then for the cross plane links, we have a more complex notation that can enable this kind of staggering pattern, but also, like, irregular pattern that you would expect. So in the updates we finalized in July, we added the description of the feed link in the ground station with a new schema to basically express where they where they are and their capabilities. So here is an example of such a description. So you can see that a ground station has a location and then a number of two other arc parameters. Let's say, One is the minimum elevation that it can sustain. So it this is an angle that will exclude coverage or the cone of coverage of the the conversation, and then a ground station has a number of antennas such that it can numb it can maintain several feeder link in parallel. So with this description, you can really compute easily from the constellation from a constellation description together with a current station description, you can compute the feasibility of of Fidelink in basic terms. So we also wanted to bring you a perspective on the tools that can use this. So we've been talking a lot about the tools that could use this. We we we're I'm going to describe two. So one is our internal tool. One of the internal tool that we have at Aerospace Lab, which basically enables you to generate a networking lab from a constellation. So you start from specification that is following the code, and then using our tool, we can generate content on that topologies and then have a real networking lab that has all the inter satellite link setup, all the feeder link setup at any point in time. And this way, we can study really real network stacks, real network protocols, and how they react to these kind of events. So as I mentioned, this is an internal tool, but today, with the draft specification, LLMs, and about what you would spend on lunch later today, you could generate an equivalent tool or one that is targeting the networking experiment technology that you prefer, for instance, Mininet or anything. This is really stuff that is, let's say, affordable, thanks to the to the specification. Then another tool proposed by by Juan is the contact plan designer, which is open source, which you can access at this URL. It runs in the browser and embeds the draft to describe terrestrial I mean, Earth focused deployment, but also IPN focused deployment. And so with the draft, you can you can specify also link patterns that are gonna be verified by the contact plan designer that is going to compute complex contact plan, let's say, between different orbital bodies and and things like this. Alright. I sped up a bit so we have some time for discussion because, obviously, there could be more future work to describe more capabilities. But at this point, we would really like to have feedback on the approach. If you have experiments running simulations, if you could use the the the code, or if you think something is missing in the code, then let us know, and let's try to improve it so we can we can move forward with this. There is purple if you wanna do some PRs, and also we can discuss on the list. Thank you.
[01:28:02] Yorgos: Very cool. Thanks for the update. Eric?
[01:28:08] Eric: Yes. Thank you very much. I I noticed the the CDDL for ground stations in section 4.1 and other sorts of things. And I wanted to say that I think, in general, you have two things, not, you know, the your your your special string is actually one encoding of a of a data model or an information model. And so Correct. If you were to express a set of aerospace network element IDs as each one of them having their own sort of CDDL, then the special stringification version is is just kind of one special encoding, and other encodings could be useful for other applications.
[01:28:47] Maxime Piraux: Yeah. Yes. To me, the point is not so much the encoding, which we could revise in many ways, but more about the taxonomy and what we agree on the elements, the basic elements.
[01:28:56] Eric: Right. So I yeah. I think this is a little little bit of restructuring for the for the next revision where you could sort of focus more on the CDL for CDDL for those things or or or the or Yang or whatever.
[01:29:06] Maxime Piraux: We could also adopt Yang if if that is the way, really.
[01:29:11] Yorgos: Okay. Ali?
[01:29:13] Chairperson: Hi. Ali, sustain RG co chair. Thanks very much for the presentation. May my question is more general, actually. I saw your network diagram with the access core and the ground segment. And in the past, I'm not a satellite NTN expert, but the, let's say, paradigm was to get from the access to the ground network as quickly as possible. Now I see a core network which can deploy routing and other things. And I'm asking from a sustainability perspective, when we consider this whole network, is that the best thing to do? Or, like, should we solve the problems taking the ground network into the equation more in the sense of resource efficiency, energy efficiency, and the other sustainability aspects.
[01:30:15] Maxime Piraux: I understand the the question. So indeed, in the past, most use case were what is called band pipe, so traffic coming up and back directly. What I can say is that we have now clients that would like such kind of connectivity, but it is indeed it is more energy efficient to do band pipe, but it's less service rich in a sense. And then some people are interested in those kind of consolation to actually not go to the terrestrial network as a requirement. And so this is where it also it is also interesting. Thank you. Thanks.
[01:30:56] Chairperson: Thank you, Maxime. So we are already over over time, but we want to make some room for also Nishanth shared the last part of the session, an update on the topology of base research infrastructure.
[01:31:09] Yorgos: Just four slides, this will be quick. Bear with us.
[01:31:12] Nishanthth Sastry: Yeah. I'll I'll keep it quick. Can you hear me?
[01:31:15] Chairperson: Confirmation, please.
[01:31:16] Nishanthth Sastry: Yeah. Excellent. Thank you. So last time, I had provided a very brief update of something that we started in tags tool workshop previously, collecting together all the different tools and infrastructures that people have been proposing as part of their research papers, as part of their lab efforts, and so forth. And that's what I was proposing. It was basically a simple Excel sheet where we had different kinds of resource types, and I invited people to contribute. Many of you did contribute. We also did a scouring, of, Internet, together with Juan. And we we've come up with this taxonomy of different kinds of infrastructures that people have been proposing, ranging from simulators, which are purely with within software space to emulators, which may have real protocol stacks embedded within them to test beds, which actually have real hardware in in in there as well to in in in orbit platforms, which includes some elements up in the sky. And then more data driven efforts such as datasets, measurement tools, also some reference implementations out there for certain protocols, libraries that that are reusable across across different different efforts. And, finally, visualizers and research platforms, which enable some of these efforts to happen. And what we in the process of doing this, and then the process of scoring the Internet, we have gone up from the original 60 tools that we had collected for the in the last idea of 210 tools. This taxonomy that we have come up with seems to be robust in the sense that we can extend from 60 to 100 and a similar taxonomy still holds. But if the taxonomy is not froze intended to be frozen, there could be new categories that could emerge in time. The taxonomy itself is up for discussion, and we've prepared an initial draft, which we'll share shortly in in the mailing list and invite feedback for this. And what we've also done is we've created with one's help community registry for for for this set of tools. It's intended as a living document that there's there's a QR code if people wanna look at that or the URL at least at the bottom of the slide. Each what we have done is each of these different tools and infrastructures that we've documented, we've made that as one machine treatable record, and each one belongs to one of the classes to one of the 10 classes that I briefly listed in in the previous slide. If anyone has a new resource, then they can just add that as yet another machine table record. So it's it's just one full request. Each registry we've we've we've added these 110 entries so far, and each one has a last verified date, which is the last time we verified it. We will be periodically verifying that. But we also recognize that some research tools are just stated for a paper and may not be maintained. So we could have a verification fail, but we do key intend to keep the the previous records as a as a point in time of when this this tool was created. So but if people are maintaining it, as an active, ongoing basis, then we will note that as well in in the in the the community registry. So that's what I wanted to give you an update of, very, very quickly, and we'll be shortly sharing an initial draft and the link to this in in this in the mailing list as well. Any Thank
[01:35:21] Yorgos: you very much, Nishanth. So check out the page. If your tool is on there, check whether it's correct. If it's not on there, please edit. That helps us collecting resources and keeping these things alive. And if you see something missing, please also reach out. I think this concludes our SPACERG meeting proposed this week. We are planning to do another meeting in the fall, potentially an interim not collocated with the ITF. This is yet to be found out. We'll update you on that. Thank you very much for attending. Have a great rest of the week.
[01:35:52] Chairperson: Thank you.