Session Date/Time: 16 Mar 2026 01:00
This is a verbatim transcript of the IETF 125 DMM Working Group session.
Drafts discussed:
Slides:
- Working Group Status
- Mobile Traffic Steering
- Mobility Management for Inter-SNO Sharing in LEO Satellite Networks
- A YANG Data Model for Attachment Circuit as a Service with UDP Tunnel Support
Sri Gundavelli: Okay, maybe for the time being we'll go with the local version. You can let me try to share one last time, if not you can share Satoru-san.
Satoru Matsushima: I found you uploaded the slide.
Sri Gundavelli: Okay. Can you—do you mind sharing it actually? Or I can skip fast, I think, you know, I can...
Satoru Matsushima: Okay, I will try to share.
Sri Gundavelli: No, I’ll share the local version, that’s fine actually. No, it's not an entry yet. Okay, thank you so much, yeah. Okay, maybe we should get started. John, we can get started?
John Kaippallimalil: Yeah, yeah, I think it looks good here and let me know if you need anything.
Sri Gundavelli: Okay. Satoru-san, should we start?
Satoru Matsushima: Yes, please.
Sri Gundavelli: Okay, folks, welcome to IETF 125 DMM Working Group. My name is Sri Gundavelli, I work for Cisco, with my co-chair Satoru-san.
Satoru Matsushima: Satoru Matsushima from SoftBank.
Sri Gundavelli: And we have John K—John Kaippallimalil for helping us for locally chairing the session. John, thank you so much. Next slide, please.
Sri Gundavelli: Okay, please be—please read the Note Well statement. By participating in the IETF, you agree to the IETF processes and policies. This Note Well is a reminder of some of these policies. Please go through this. There are some rules on how you conduct in these meetings, in this—your participation has to be bound by those rules. If you disagree, you have to leave the meeting or disconnect the call. Next slide, please.
Sri Gundavelli: Okay, we need a note-taker. Any help? John, can you ask someone on the floor?
John Kaippallimalil: Yes, sure thing. Thanks Sri. I did talk to Luis and Luis has agreed to take notes for us today.
Sri Gundavelli: Luis, thank you so much. Great job. Thank you so much. Okay, agenda—agenda link, Satoru-san has put in the link. Please see here. And these are the Working Group documents, I think. Yeah, please previous slide actually. I think just—let's do a quick review of where we are. One is the Mobility Aware Transport Network Slicing for 5G. Satoru-san, you want to say a few words about this?
Satoru Matsushima: From my side, the update regarding the working group drafts is not just on slides but the commercial deployment happened on the SoftBank network, one of the major mobile operators in Japan, deployed successfully the SRv6 MUP. So that would be the update on the DMM Working Group.
Sri Gundavelli: I was asking about the first document, I think is Mobility Aware Transport Network Slicing for 5G, John Kaippallimalil's paper.
Satoru Matsushima: Okay, great. Yeah. The Mobility Aware Transport Network now in the status of the publication request. So the AD—IESG AD will review the draft and then be sent to IESG soon.
Sri Gundavelli: Thank you. So John and authors, we assume you guys will be tracking these IESG comments and closing them. Any discussed comments.
John Kaippallimalil: Yes, we will.
Sri Gundavelli: Okay. I think first there is the AD review and then it will go—I think first the AD review will come. I think next, architecture discussions on SRv6 Mobile User plane, Satoru-san, any thoughts, comments?
Satoru Matsushima: Yeah, the order of the SRv6 MUP related draft be updated with my previous comment—commercial deployment be happened—but in the draft, the major text update doesn't made so far, but next IETF meeting we will have.
Sri Gundavelli: Okay. On the SRH, I think this draft has expired. I think...
Satoru Matsushima: Yeah, same thing happened—same thing for SRH related action for SRv6 GTP-IPv6, yes.
Sri Gundavelli: Thank you, Satoru-san. Mobile Traffic Steering, we have a update presentation from Marco Liebsch, so we'll hopefully get to that. Next slide, please. I think there are a couple of other discussions on the—the two documents, the—the split document and individual drafts, there's some new proposal on LEO satellites, we're going to hear presentation I believe today. I think this is all we have on the agenda. If anyone have questions, comments, anything that you'd like to add, delete, any comments?
John Kaippallimalil: Sri, a quick question on the UDP Tunnel ACaaS, which is—for which Satoru-san has issued the Working Group call. Do we need to present that? I mean, I did submit the slides just in case.
Satoru Matsushima: Yeah, I—yeah, I see your slide, so I think it would be good to have your presentation to make sure the adoption call be success or—or not.
John Kaippallimalil: Okay, thank you Sri.
Sri Gundavelli: So John, we'll—we'll go with the Working Group document, Marco's, followed by yours or the Yunan Hou's document, yeah? Okay, with that, we close this agenda, we go to the first presentation. Marco is locally present or—or on site?
John Kaippallimalil: Yeah, Marco is here, I can see him.
Sri Gundavelli: Okay, Marco can... Okay. You need to be a bit closer maybe, raise the mic. Now it should work. No, now it works. Okay.
Marco Liebsch: All right. Mobile Traffic Steering. So, this work has been adopted as Working Group draft end of last year, and we currently talk about the first revision of the draft, the Working Group draft, and to proceed and close that work in the near future there are a couple of things that we need to converge and discuss with the Working Group. Next slide, please. All right. The one before. Okay. Quick—quick recap on on this work. So the draft actually specifies a clear API to extend mobile communication systems towards the transport network in order to enable end-to-end traffic steering. The reason to do that is that today mobile communication systems are not end-to-end, full stop. So, as investigated and also described in the draft, we have various use cases that today and also in the near future require such kind of steering because network operation, flow management will be way more agile as in today's network. So we grayed out a little bit the past history on that. Still you can read it. Important is Version 4 has been discussed at last IETF in Montreal and it covers major review comments including the ones from—from John, and based on Version 4, that draft has been adopted in December resulting from a Working Group adoption call. Next slide, please.
All right. So from Version 4 we published version 00 for the DMM Working Group draft in December. In February we published the first revision of that draft, also capturing Carlos Bernas' comments which we received well, during last IETF. So it addresses further comments, mainly also editorial clarification wise. So we—we moved a bit the reference architecture picture to have it more in a section that the first time refers to it. We added a figure to the use case on node ephemerality, mainly on non-terrestrial networks which was one of the cases described here. There were a few things that we depicted, though the draft doesn't focus much on it, which was a user data plane interface in the mobile communication system and in the transport network, so we clarified a little bit or added more clarifying text to that. And also on the routing interface that we exemplarily depicted in a figure in Section 6.3 and also applied some editorial nits. So, next slide, please.
All right, that's the current draft structure. We think it's pretty concise and self-contained. And there are a few things, in particular in the later parts and sections of the draft, that we want to further evolve and discuss with with you to have a close, let's say, status of—of the draft in a mature state. And as you see, we talk about a reference architecture, just to have a picture about where, what is the system that the draft applies to, and what is the interfaces that the draft focuses on and provide specification. So we have in Section 4 a couple of use cases. Section 5 we mainly discuss two different architectural deployment options which is mainly a dedicated controller and alternatively a decentralized control plane. Then Section 6 we discuss based on these deployment options, three different modes how to operate the whole thing, either in a—with a dedicated control plane, decentralized, or in a hybrid approach. So the Section 6 is mainly about who talks to whom to enable traffic steering, this is in the proactive, reactive way, so we discuss the different cases just to understand how the later discussed information model applies here. And currently we have a draft version of an information model in the appendix. That's something that needs to be worked on a bit more and that's what we want to discuss today and in the next days. So next slide, please.
All right. Reference end-to-end architecture. On the top you see there is a mobile user connected to Mobile Communication System (MCS) and the mobile user talks to a service provided by data network. In between there is a transport network. Below we show that we want to be as flexible as possible in terms of any kind of constellations of User Plane Anchors (UPAs) in mobile communication system, data plane nodes in the transport network, and data network side kind of operation. Next slide, please.
All right, just to depict the—the main interface that draft focuses on. So we show forward forwarding plane but want to be flexible here which kind of forwarding planes are used. But mainly this API that we specify between the access points C1 and C2 is the Control Plane Mobile Traffic Steering (CMTS). And that's what we focus on. In the above picture you see it applies between the two dedicated controllers, one in the mobile control plane—mobile communication system control plane, the other one in the transport network as an MTS controller. Below we also discuss the option of a decentralized approach and here the API applies between data plane nodes and user plane anchors. Next slide, please.
All right. The plan and open discussion points are as follows. So we think the draft is pretty mature in its core part regarding use cases, deployment options, architectural aspects. There may be more description needed on operational aspects. Here we would like to ask you to provide feedback if you want to have more detailed description, different cases covered. Of course some editorial manicure, and I think these are leftover general comments from John's review that we sometimes use terms like flexible deployment, dynamic reconfigurability, which requires a little bit more definition what we mean with that. So it seems to be broad terminology for some people it may not be clear. So here we want to have a second look at it and try to clarify things. Security consideration, now that the operational aspects API seems to be pretty mature and confirmed, we would like to investigate input for that section. And information model, that's something how we want to make now a proposal how to work on it and proceed to have it in the next weeks and months well, concluded. And then there was a discussion about shall this draft, even though it tries to abstract from a particular mobile communication system, have an application example, in particular since 3GPP currently discusses and has adopted studies on user plane evolution for their next generations? So it could be an option to discuss how that draft applies to that discussion and the current architectural directions in as well—the SDO that takes care about the evolution of mobile communication systems. So currently we have a easy picture in the appendix. There are different opinions if that draft should describe this or should be silent about it, right? So we really have different views here. That's something we need to decide. It's—it's easy to describe in the appendix and may be appreciated information. We also talk to some 3GPP delegates and this is still not decided yet. Okay. Next slide, please.
All right. Information model. So the appendix currently has a rough picture of tables representation of information that we want to manage in the view of the operational aspects that the draft covers. It's—it's a bit confusing to progress this only on tables. So as a working proposal, we decided and started with an ERD with an—you see it here, there are different representations and for the cardinality we decided to apply a cross-foot kind of picture here and this just a starting point and this needs to be evolved in terms of information elements, attributes that need to be added here and the relationship. So that's something we would like to have discussion with the Working Group during this week and also maybe after this IETF we plan to schedule a couple of calls, whoever is interested in raising opinion, views. So we would like to really have this converged very quickly. So that by next IETF we would like to have a mature draft that we may only manicure, get reviews on and process quickly towards official reviews, Working Group last call, etc. So here as you see we currently have four elements defined: Traffic as an Anchor Point, the traffic ID, and it connects basically path and user plane anchors. So there is a path identifier and user plane anchor ID. And as you see, a particular traffic can be aggregated traffic for one user equipment or on a flow data basis. So here the info model just refers to traffic descriptor. Optionally it may also hold information about session descriptor. So if we want to apply that to other drafts in this Working Group like MUP, there is an interface that retrieves session information from a mobile communication system and transfers that into routing information. So if session descriptor can be useful and optional in this model, we're glad to have input, otherwise we focus on a generic descriptor. In terms of path, this is basically the relationship between nodes and times, so a list of attributes. In a table model this is easy, there is an agreed notation. So here we said so the path can be a single data plane node which is maybe the next hop, or a segment of data plane nodes. So if it's a data plane node identified as a node, or if it's a hop ID, that could be a segment ID. So here the model wants to be flexible enough. And then for every hop or node, then the DPNs are being described with a hop ID being supported and also we consider DPN nodes which are ephemeral: either they move or they enter power save mode. So that is also reason to steer the traffic between the mobile communication system and the data network. So this is starting point to discuss and converge on the information model which when it's mature, hopefully soon enough, then we will add a proper table representation in the ID. Covering that kind of pictures in a draft with ASCII is a little bit difficult. But as a working document to discuss with interested people, it's—I think the right approach. Yeah, so we would like to get your opinion here, and I think that's the last slide of the presentation. Either you have an immediate comment, question, input regarding the information model. If you're interested in joining the discussion on progressing this, please let me know, just send me an email. We'll also send out some proposals for calls in the next weeks. And second, yeah, the question before, I mean, I—we asked also some 3GPP delegates because it applies and some of the authors also contribute to 3GPP in the view of next generation evolution. So there is relevance of this use cases and associated ideas in the evolution of 3GPP. So if you have an opinion now, maybe you can provide it as feedback already, I think we have some time.
Sri Gundavelli: So Marco, if I may ask a simple question. On topological identifier, what exactly you plan to hold, keep there in the topological versus UPA topo—UPA topological locator versus geographic locator? Geographic I understood, but topological locator what exactly you plan to keep—hold?
Marco Liebsch: Well, if we have data plane nodes or user plane anchors on nodes that move, so they may change in terms of their geographic location, that's clear, but also in terms of their topological location. If they are treated as a router and they move, so the routing system is something more more agile. So the peers that connect to each other, the routing tables, they change.
Sri Gundavelli: No, I guess my question is what is the data type actually, so what do you plan to...
Marco Liebsch: Well, this is an information model. So what is the data type here that we currently leave open. Also we have a reference or an information regarding supplementary information. So if there is any service that can provide more information on the topology, on the agility how that topology or geographic location changes, which is, for example, important for satellites that are not stationary but move. So here we just provide a pointer to retrieve such information without going into details here.
Sri Gundavelli: Makes sense, yeah. Okay.
Marco Liebsch: If it—I hope it makes sense. I mean that—that's the points that we want to discuss, right, if people see that relevant in the information model. But please start looking at the use cases because we should not think only about use cases from fourth generation, fifth generation, but a little bit more into the agility that will expect us in the future generations here. Look at the use cases, think about the description here, and then we should nail down an appropriate information model. Is it a bit clear, Sri?
Sri Gundavelli: Okay, thank you Marco. Any—is that your last slide Marco, or...
Marco Liebsch: That's—I think so. There is an appendix, yeah, that's the last slide. The one before we just have the plan presented and that includes discussion on the 3GPP aspects. If you don't want to have an opinion now, please let us know by email.
Sri Gundavelli: Yeah, we can ask. Any questions, comments on this presentation? Looks like John has a comment.
John Kaippallimalil: A few questions for clarification actually. So you know I'm also participating in the 3GPP side on the user plane, so from that point of view, flexibility and reselection, you know. So in a session, there may be multiple flows. And if you're going to reselect these data plane nodes, what is the—I mean which flow are you going to prioritize in terms of taking that decision to relocate or reallocate more flexibly? You know, I'm assuming that one flow may go to one data center, let's say, another one to some other place, so how are you going to manage this or what are the principles around that, you know?
Marco Liebsch: The principles under the use case behind is that a mobile user may have one or multiple user plane anchors associated, right, though one flow traverses only one dedicated user plane anchor, either identified by the user IP address or other means. So the rationale behind is if the user plane anchor changes, that's not a decision from the transport network or the data network, but the mobile communication system takes that decision, right? But it needs to notify towards transport network. So if the user plane anchor changes, you don't want to have, let's say, remaining flow anchored at the previous anchor, but in terms of optimized routing you need to steer the traffic to the newly selected and serving user plane anchor. So this is notified through the API that we specify here, and transport network adjusts the flow.
John Kaippallimalil: I think that's an assumption you're making and it should be sort of made explicit in the draft because you could have more than one flow with not exactly the same destination or—or even, you know, I mean there are different models, it's not clear yet what's going to happen especially going forward.
Marco Liebsch: For the granularity about the traffic descriptor, we leave it open here. So you may have one flow, particular flow being assigned to one particular user plane anchor and a path towards one data network, and another flow of the same mobile user through another user plane anchor or the same user plane anchor to another data network.
John Kaippallimalil: Okay, so those assumptions—it would be good to clarify because I think it's important. Maybe let's look together at the use cases because they are clear about that. A second question also, I mean and we can discuss after. So second one is about, you know, how does this impact flows above? Because if you reselect, then the IP address potentially changes, right? Or do you keep the IP address?
Marco Liebsch: We don't touch the IP address here. It's really about—IP address is the one that's being used anyway, either fixed IP address of the user or a delegated prefix or IPv4 address with NAT in the mobile communication system, that's transparent to this kind of steering, right? The mobile communication system says for this flow identified by this IP address or this flow identifier or this token, I use this user plane anchor now, or it has been relocated from anchor 1 to anchor 2. Steering must be adjusted in transport network.
John Kaippallimalil: Okay. So, I mean if the anchor—if the user plane anchor is the one that assigns the address then if you change it, the address will change?
Marco Liebsch: Not necessarily. If it changes, this is captured by the information on traffic descriptor here, okay.
John Kaippallimalil: Right, right, okay. Thank you.
Sri Gundavelli: Any other questions, comments on this? Okay, Satoru-san, I think next—John's slide, let me share it.
John Kaippallimalil: Thank you, Sri and Satoru-san. So this is a YANG data model for Attachment Circuit as a Service with UDP Tunnel Support. Next slide, please. Okay. Just as a refresher, you know, this has been looked at in the context of two documents that this working group has been working on. One of which is already in working group process already, that's the TNA Aware Mobility. And this draft with the ACaaS side was split out because the data models or the YANG model with the UDP and ACaaS is independent to an extent. I mean, it is not necessarily tied only to the TNA Aware Mobility mechanisms and can be used generally anywhere else. So hence we have these two drafts. One that's more of an informational draft that discusses all of the the way it can be used in a 3GPP network. But in general, this particular one with the YANG model is only describing a bearer, ACaaS bearer, a connectivity—I mean circuit bearer, UDP bearer. So that's the context in which we're looking at it. So this figure here is just showing how this was split, because I see there are lots of newer people here, just to let you know this is how this draft is split up. Okay, so next slide and I can go over very briefly what we've changed. So the next couple of slides are just going to talk about what this UDP model is conveying. As a context, the current—the—the this is an extension, right, of the YANG models that are already there with the AC models and that's already a draft in L2SM—I mean L2—and L3. John, please keep going. Okay, sorry. I just issued the polling more or less, but that's okay. Yeah, so this is a YANG model extension because the previous attachment circuit models considered Layer 2, so basically VLAN and so on. What we're doing here is simply extending it to a Layer 3 bearer, a UDP bearer, and the attachment models for that. So this has been reviewed by multiple people who have forgotten to acknowledge also and I apologize for that. You know, but there has been some really serious reviews on this draft. The model that—the YANG model has been validated and, you know, it's—it's current and so I think there's a fair amount of confidence that it represents a model that can be generally used beyond the scope of just this one slicing draft. So that's the aim with which we're working on this draft. I think that's a very high-level summary of where we are on this. So just to summarize, I have another slide which put together the comments that I got during the Working Group adoption call. All of these comments are pretty straightforward to address. So I think in the next revision we can clearly make those changes. You know, some of which may require some discussion on the Working Group list, but otherwise they are very straightforward and we can address that and go forward. So that's where we're at. I don't think we need to look through the rest of the slides. I mean, this has been looked at several times. So appreciate any comments if you have, or otherwise we can... that's all I have to say.
Lionel Morand: Yes, thank you. Good morning. Yeah, actually we can—so from my understanding what we have done already in the previous draft was just to—so base—I still don't understand why, but based on the feedback that we have received it was necessary to split, but from my point of view what we have so far is exactly what we had in the Working Group document that was already ready for publication. So, I think it's straightforward to—so of course people are invited to review it, but I think that the content so far in the description of the YANG model is according to what we have done since more than one year now and—and I think it's okay to adopt it and even as soon as it is adopted to move it forward for Working Group Last Call and so on. There is no specific reason to delay this process because what we are doing here is just administrative work initiated by someone else saying that from my point of view it was not needed at all, but actually we are just following the guidelines provided by the reviewers and so on, so but just to say that okay to adopt it and even to push it forward as soon as it is adopted.
John Kaippallimalil: Thanks Lionel. My sentiments and glad to hear the feedback from others.
Satoru Matsushima: Also from my side, just to reinforce that I agree with Lionel. There's no need to split from the TNA mobility draft, but Ops AD requested so unfortunately the YANG model be separated. But there is no reason to argue that the adoption and Working Group Last Call be happening at the same time. Thank you, John.
Sri Gundavelli: Thank you, John. Any other questions, comments? Okay, if not, thanks John. Eric is saying we don't even have to run this, but I guess it's up to you, yeah, it's totally fine. Thank you. Chairs can just unilaterally declare a document adopted. That's it. Secret chair power. I see. Okay. All right, thank you. Eric, while you are on that, the other one—the other document, it's in your—Tommy is going to take care of this, or have you guys decided or...
Eric Vyncke: Yeah, it's on me to do kind of an AD eval, but then just hand that off to Tommy as a guide for him to get started. That's gonna probably have to wait till the end of this week, though.
Sri Gundavelli: Sure. Thank you. Okay, so I guess we'll wait for—we'll wait for Tommy's and your reviews and we'll go from there. Thank you so much and I think... yeah, all right, we can close this deck. Next, Yunan Hou from Tsinghua University. Mobility management for inter-SNO sharing in LEO satellite networks. Yunan, are you in the room?
Yunan Hou: Good morning everyone. I am Yunan Hou from Tsinghua University. Today I will talk about our work on mobility management for inter-SNO sharing in LEO satellite networks. This work studies a new trend in LEO networks, where different satellite network operators may work together and share infrastructure. This can help deployment but it also brings new mobility problems. In this talk, I will first introduce the background, then explain the main challenge, and finally present our solution.
Here is the outline of my talk. First, I will briefly introduce the LEO networks and satellite network operators or SNOs. Then I will talk about satellite mobility and handover. After that, I will explain inter-SNO collaboration and the challenges under LEO mobility. Finally, I will present our mobility management solution and give a short conclusion.
This slide shows a typical LEO network architecture operated by one satellite network operator. In this architecture, users connect to the internet through satellites and ground stations. The traffic then goes through the SNO core network, which provides functions such as authentication, accounting, and IP address management. For example, in this figure, a user connects to a ground station through one or more satellites. Then the ground station connects to the SNO core network, and after core functions like authentication, accounting, and IP address management, the user can access the internet. A key point here is that the all satellites and the ground stations belong to one operator, and the users access network services through that operator's full system. So, in this typical architecture, the LEO access network and the core network are tightly connected to one single SNO.
One important feature of LEO satellites is that they fly at extremely high speed because of their low orbit altitude. Because the satellites move so fast, a user terminal or a ground station cannot stay connected to the same satellite for a long time. So, they have to switch from one satellite to another again and again. For example, in this picture, the satellites move quickly from left to right. When one connected satellite moves out of the visible range of the user terminal or ground station, they switch to a new satellite that is coming into view. This process is called handover. That means mobility is a—is not a rare event in LEO networks. It is a basic and continuous feature.
Meanwhile, because the LEO satellites move so fast, we need a very large of satellites—we need a large—we need a very large number of satellites to provide continuous global service. This is why mega-constellations like Starlink, Amazon Kuiper, and Telesat all plan or deploy thousands of satellites. For example, in their earlier plans, Starlink wanted to launch more than 4,400 satellites, Amazon Kuiper wanted to launch more than 3,200 satellites, and Telesat wanted to launch more than 1,600 satellites so they could provide global coverage. So, the first message of this slide is high mobility leads to large constellation size, and the second message is building and operating such a huge constellation is very expensive for an operator. This also gives us a reason to think about cooperation between different operators.
Deploying so many satellites is complex, time-consuming, and costly for one operator alone. So, now there is a trend towards inter-SNO collaboration. That means different SNOs may share infrastructure to speed up deployment and improve service coverage. This figure gives a simple example. In the early deployment stage, the number of satellites is still small. So, it is hard for one SNO to provide continuous global coverage. Taking North America as an example, if Amazon Kuiper works alone, its coverage is limited. If Telesat works alone, its coverage is also limited. But, if they collaborate, the overall coverage can become better as shown in Fig C. So, inter-SNO collaboration can bring clear benefits.
But, under LEO mobility, it also creates new challenges. The main problem is that LEO mobility can frequently trigger inter-SNO handovers. This is different from normal handover inside one operator's network. In an inter-SNO handover, the user may move from the service of one SNO to another SNO. This means the handover is no longer only a link level issue. It also needs coordination between different SNO core networks. For example, in the left picture, at first, the user is connected to a satellite of SNO A and accesses to the internet through the core of network of SNO A. But, as satellites move very fast, after some time, that satellite moves away and a satellite of SNO B comes into view. Then the user connects to the satellite of SNO B and accesses the internet through the core network of SNO B. At this point, the core network is also changed, which can lead network disruption. If this happens too often, the seamless service becomes very difficult. As shown in the right figure, in major cities around the world, users may experience about 20 to 80 inter-SNO handovers per hour. So, this is a very serious mobility management problem.
To address this problem, we propose a new mobility management solution with two core components. The first component is shared LEO access, the second component is independent SNO core networks. On top of this architecture, we design a tunneling-based mechanism to support flexible and dynamic satellite SNO association. In simple words, within our architecture, this means a satellite is not fixed to only one operator all the time. Instead, it can be authorized with different SNO core networks in a flexible way.
Now, let me explain this architecture a bit more. First, satellites are decoupled from individual SNOs through shared LEO access. This means the satellite access part can be shared among operators. Second, the SNO core networks remain independent. This is important because each operator still wants to keep its own core functions. So, our design tries to balance two goals. On one hand, we want to sharing and flexibility. On the other hand, we still want each SNO to keep control of its own core network.
Based on this architecture, each satellite can be dynamically authorized with different SNO core networks and different SNO core networks can communicate through tunnels. This tunneling support is very important. It makes dynamic satellite SNO association possible in practice. So, even if a user is served through a shared access network, the traffic can still be delivered to the correct SNO core network. In this way, the system can adjust satellite SNO association according to mobility and service needs, instead of using a fixed binding.
Now, let's talk about mitigating the impact of inter-SNO handovers. Our first goal is to reduce the number of inter-SNO handovers as much as possible. The key idea is to make smart satellite SNO assignment. We use three pieces of information. First, satellite trajectories are predictable. Second, we know the existing user SNO associations. Thirdly, based on this, we can assign satellites to suitable SNOs to reduce users' inter-SNO handovers. If we can avoid unnecessary inter-SNO handovers in advance, seamless service will be much easier to support.
However, not all inter-SNO handovers can be avoided. So, our second goal is to make an unavoidable handover faster. The left is the baseline handover process RFC 6275 Mobility Support in IPv6. Needs several steps after the new link is formed, such as core discovery, authentication, and tunnel setup. These steps increase disruption time. Our idea is proactive switching. Using pre-computed satellite SNO associations, we can prepare some operations earlier, before the handover fully happens. For example, we can do proactive authentication and proactive tunneling. As a result, when the actual handover happens, the process becomes shorter and the service disruption time can be reduced. So, the key message of this slide is, first, reduce the number of inter-SNO handovers; second, when they cannot be avoided, shorten their interruption time.
To conclude, LEO mobility makes inter-SNO collaboration both necessary and challenging. To support this new trend, we propose an architecture with shared LEO access, independent SNO core networks, and flexible satellite SNO association. Our solution works in two ways. First, it reduces the number of inter-SNO handovers through a trajectory-aware satellite SNO assignment. Second, for unavoidable handovers, it uses proactive fast switching to shorten service disruption. Thank you all.
Sri Gundavelli: Thank you, Yunan. Any questions, comments from the room? I see John.
John Kaippallimalil: Thank you for the presentation. Just a few comments. So one is that the point of presence to the internet you show is the same for both of the independent satellite networks. So, I think that's a big assumption. I mean, usually there would be different points of presence to the internet, right? Meaning that the router that connects to the internet from SNO 1 is different from the point of presence for internet 2, I mean for SNO 2. So that could have some implications on the architecture, it may be something to look at. Okay, I can talk to you offline also. So that's one of my comments. Another comment is that you make an analogy between the—I mean, the motivation for this is collaboration to reduce infrastructure cost and comparison to an MNO. In the MNO case, there is no inter-operator handover during a session, at least as far as I can see. So that's another big assumption you're making. So in the flows that you show, you do all of the proactive authentication and all that, but that's also a big assumption that you have to think about how that goes. So there are some architectural impacts on that. Quite different from the MNO use case, I would say.
Yunan Hou: Like from the mobile network operator use case? Yes, in the LEO networks, it has a fundamental difference to the traditional mobile networks. The LEO network fundamental difference comes from the LEO satellites' flies at very very speed, about six kilometers per second. So, the user terminal have to in first switch among different satellites. But in traditional mobile network, a user when a user leave a base station of a operator and they access to another operator base station, they will switch the operator. It's roaming. In the LEO network, it's similarly a roaming, but this roaming is in first—is passive.
John Kaippallimalil: Right, right, so that's what I'm saying. I mean if you take that and the fact that the termination points, the point of presence or exit to the LAN network, they are also going to be different. So something to look at. We can talk offline.
Lionel Morand: Thank you for your presentation. I think that before jumping to the solution space, as said by John, there is maybe some working assumption that need to be first validated. Looking at the use cases for user trying to use satellite services, especially the need for inter-SNO. Because actually you said that you may have multiple SNO that cooperate, which is true, but in that case, like in mobile network, if you have a shared access network, from the user point of view it will be only one SNO. So the SNO will manage to provide the same access to the ground floor or even on the pop behind. So in that case you don't have this kind of handover from the IP level point of view. So you will switch from one satellite to another satellite, but you will not change your IP address. In the same—we have the same case for mobile network when you have a shared access network. So I think this kind of working assumptions need to be evaluated and to see if there is a real need for an handover at the IP layer between these satellite networks. But we can talk about this after the session if you want.
Satoru Matsushima: Thank you for your presentation. I think this is interesting. Sorry, keep stand on mic. Thank you for your presentation. Can you hear me? From my side, it's be question or comment. So as you presented, the inter-SNO make a certain level of the cost saving. So how much of the cost be saved, could be my question. Did you have such simulation or estimates the cost to be saved?
Yunan Hou: Yes, in the real world, the Starlink has launched more than 9,000 satellites. But in our simulation, we find that when Amazon Kuiper and Telesat collaborative, they can only launch the 40% satellites. 40% satellites, it can do the similarly the coverage with the now Starlink. Only from the coverage perspective.
Satoru Matsushima: You mean 40% satellite be reduced, is that correct? If the inter-SNO be achieved.
Yunan Hou: Yeah, when the Amazon Kuiper and the Telesat, their total satellite is about 3,000 and 1,600 satellites. So about 40% of 4,000 satellites is coverage—is enough to coverage the global earth.
Satoru Matsushima: Okay. Have you simulate the exact cost—simulation for example how much the money, how much the dollar, how much of the RMB be saved by inter-SNO operation?
Yunan Hou: The economic issues and the security issues in current we don't care them. In the future work, we will consider the economic and the security. Now we only focus on the performance.
Satoru Matsushima: Okay, so I think it would be very good to do in your—in the future to convince the industry how many—how much the cost, how the security issue be solved by inter-SNO. Thank you very much.
Sri Gundavelli: So thank you. Any other questions, comments? Yunan, good presentation. I'm glad you guys are doing this in university, great stuff. So I think, as John, Lionel and others advised, right? I think you may want to focus on the problem statement more than—instead of quickly jumping into the solution and call flows, right? Even if you can document your observations, whatever you are doing simulations, like I think you know the how you can optimize the network or whatever right by inter-SNO handoffs, right? I think whatever I think just as a documenting a problem statement itself might be good first step in my opinion. But this is definitely good work, looks promising. Yeah, please keep us updated the group what you guys are doing next. Thank you Yunan. Satoru-san, any next topic you want to discuss anything?
Satoru Matsushima: No, I will confirm the adoption call be success in the mailing list for the John's draft.
Sri Gundavelli: Okay. Any other questions, comments from the room John that you see? I don't see any. Maybe I'll ask again, you know, if anyone has comments on any of the topics. No, none that I can see. Okay, before I think that's our last topic as far as I know there is no other... anything from the ADs? Eric or Tommy?
Eric Vyncke: Not about this specific presentation or... No, in general. I would just say, at some point, thank you for bearing with me for six years. It's been interesting. I'll leave you in Tommy's hands.
Sri Gundavelli: Yeah, maybe should Eric maybe should tell the group that, right? I think Eric is stepping down as AD after a long time. He's done some excellent work. We want to thank Eric from everyone. Thank you so much Eric. And Tommy... Tommy you want to say a few words, introduce yourself? I think that would be great.
Tommy Jensen: Certainly. Hello everyone, I'm Tommy Jensen. I'm stepping up this Wednesday as your new responsible AD. I've been in the IETF for a few years, my background is from the DNS area and first intersecting with the 3GPP world when doing IPv6 stuff and making the brazen assumption that router advertisements are ubiquitous everywhere. Been learning a lot about how cellular networks work since then. So I'm looking forward to supporting you in everything you're doing, which for the most part ought to be staying out of the way and making sure that everyone else stays out of your way.
Sri Gundavelli: Thank you very much Tommy. We look forward to working with you. Once again, John, thank you for hosting the meeting locally. We greatly appreciate it. With that we wrap up this meeting, a short meeting this time. But thanks everyone. Thank you Satoru-san, thank you Eric, thank you John, thank you Luis for the notes. See you in Vienna. Meeting's closed.