Intro: In an OTT streaming case it would be — you have the caching and you have the edge compute in the content delivery network in the CDN, but you still have your cloud infrastructure underneath. What is new about edge caching in the aircraft if all of this already is there? We often hear that statement of — I need edge caching and then the solution will work without connectivity. That's not the case. It's not part of the traditional thinking of edge caching, but it's important. The frequency of using those files — and not only the frequency but also the similarity. Looking at today's IFE landscape, these components are usually all made in stone on the server.

Ralph Wagner: Welcome to our podcast. LOADED — Talking Software for Connected Aircraft. And today we are talking about edge caching. So with me, Stefanie Schuster. My name is Ralph Wagner. And here we go. Stefi, let's talk about edge caching. What is it?

Stefanie Schuster: There are various definitions about edge caching in this industry, but when we take it back to the origin, where this is coming from and where it's used for many years already — this is the OTT streaming industry and the setup with content delivery networks. So a setup where you try to bring the data as close as possible to your users.

Ralph Wagner: We are talking about files, right? It's the files.

Stefanie Schuster: Caching files, making sure the users would get those files from an edge node that is very close to them. Instead of fetching it all the time from the central server or the ground. And now in aviation there are different variations and definitions around that. But I would say that's the core — trying to get the data as close as possible to the user, so you can make it very performant, fast, and you have less pressure on the network.

Ralph Wagner: Maybe we stay a bit on the ground side. On the classic CDN side, we have an edge cache for the context that typically belongs to all the CDN terminology — bring the files near. But you need also an infrastructure for that. Edge does not work on its own, right? What is the infrastructure?

Stefanie Schuster: That brings us to the topic of edge compute. Then it's not only anymore about the storage, about the files, but actually about an infrastructure that makes you very fast, very performant, resilient — so you really get more functionality, more performance to your solution.

Ralph Wagner: And this edge compute — where is this hosted? Where is this based?

Stefanie Schuster: In a typical OTT streaming scenario that is often part of the CDN. So when it's about load balancing, when it's about also some data transformations — not super complex logic, but still logic to make it fast and performant. For aviation that should be also at the edge. So in the aircraft.

Ralph Wagner: But let's still stay a little bit longer on the ground. You have described there is a delivery. And on the other hand there is a compute side for performance processes. But are the two enough to serve something?

Stefanie Schuster: No. You still need the software services. So if we talk about a streaming case, you need a DRM service. You need the Streaming Catalogue service. You need some Entitlements. All those services still need to remain somewhere. So in an OTT streaming case it would be — you have the caching and you have the edge compute in the content delivery network in the CDN, but you still have your cloud infrastructure underneath, which can also be redundant and in different locations. That's another topic. But still, it's the cloud infrastructure where those software services, like a DRM service, would remain. And if you would say your cloud would be off, then your OTT streaming application would not work just with a CDN.

Ralph Wagner: Right. I think it's an important topic to have something functioning from a service perspective to an end user or to another service. You need not only the edge caching, you need maybe the edge compute, which is a kind of hybrid of storing things and delivering and doing some logic. And you need still some cloud infrastructure that does some heavy lifting of transactions and of authentication and things like that. This triangle, kind of — you do need to have something that works. Okay, now let's move to the aircraft. What is edge caching on the server in the aircraft?

Stefanie Schuster: If we stay with the same definitions and the same logic, the edge caching is a software service that runs on board of the aircraft on that server — for caching, storing files, first of all. Any kind of files. We can talk about that later as well; we stay here in the entertainment streaming context. Okay — it's just the files. Then additionally, you would want to have edge compute because you want to be able to use those files in a performant way. You want to have some resilience around it. So that also could be software services on board of the aircraft. And they need to run still somewhere — software services allowing the cache to work in a smooth way. And then you have the cloud infrastructure. So if we stay in this CDN-cloud setup, you have a cloud infrastructure where you have all the functional services like DRM, Catalogue, Entitlement. Let's take DRM. They need to run in some cloud infrastructure. Traditionally on board of an aircraft they were running on the server in a cloud context. So if we're talking about edge caching, you connect that typically to cloud streaming. Caching is closely connected to cloud streaming. So those services can remain in the cloud.

Ralph Wagner: But if the DRM service would now reside on board, and the edge compute service is on board, and the edge server — so the files — is on board, then actually this triangle that we described before from typical OTT streaming — then you have everything on board. How about this statement?

Stefanie Schuster: Then it would still make sense if you have a huge content catalogue in the cloud. Then you have the functionality on board, but you cache — because you don't want to get all the content on board.

Ralph Wagner: Yeah. We did not talk yet about connectivity. If we just say, okay, you have a File Delivery service, you have a Compute service that does performing file delivery, and then you have your DRM service, your Entitlement service and so on — if you have everything of this on board, the argument you hear quite often is — oh, we have done edge caching all the time since ten years, we are doing edge caching. Because all of these components that I described on the ground, you have them on board. What is new about edge caching in the aircraft if all of this already is there?

Stefanie Schuster: This discussion of what is actually the difference between over-the-air sync and edge caching — the borders get more blurry. Because for example, prepositioning you can do with both. You can have logic to pre-position content on board of an aircraft. But probably the biggest difference is that edge caching is operating all the time, without any push or pull mechanism. In an over-the-air synchronization, you would still say, I want to update. I want to synchronize now, or daily or monthly or whatever cycle you have there. Caching I would understand rather as — this is happening all the time. It can happen based on parameters. You say, okay, one passenger streams that — then please automatically cache. You can even say, is it only the quality level which is streamed right now which would be cached. But you can also put much more complex logic in it to say what might be popular, what could be used on this flight, and then just keep caching all the time based on such logic you put in place.

Ralph Wagner: You're switching now from the onboard side to the cloud side. You're including cloud now. You're basically saying if somebody says, oh, we have already done edge caching since ten years — what you're saying is, yes, your edge caching was every six months or every three months you put new content on board.

Stefanie Schuster: Even if it would be weekly. But it's still…

Ralph Wagner: That would even not be edge caching, because it's not called from the onboard side. So you do it from the ground. What you just described is, the logic on board decides what it wants to have. When I request something and it's not there, it goes and fetches it — and it does it all the time. So it doesn't do it monthly or weekly. The condition for a real caching system is probably a connection that is present, that you really have a connection that is always available, and where you always can connect your cloud to your onboard infrastructure. That would be a real definition of edge caching — where the edge has the possibility to connect any time to the repository on ground to enhance the catalogue, or to bring more content to it. So edge caching actually only functions in a combination of a cloud infrastructure and onboard infrastructure.

Stefanie Schuster: How do you see this? If we take this parallel definition of content delivery networks and OTT — there are quite some topics when you talk about CDN, like the files expiring and all such topics. Which topics are there and which should be considered in an aviation case?

Ralph Wagner: In the aviation case, the topics are definitely about the space limitations you have on board. You also have the topics about what kind of connectivity do you have. When we are talking about the possibility of an edge cache to actually reach the ground and request new files — that functionality does need to work resilient. And now it gets, from my perspective, a bit different than the ground setups. On the ground you have a very clear separation: you have your origin servers, your Authentication services, your Edge Compute and your edge cache. The edge compute and the edge cache are in one network, and your origin servers and your cloud infrastructure are something else. Why is it like that? Because nobody counts on that everything needs to function just on the edge cache. Everybody thinks, okay, if the cache is not working or the cache is not filled, you still have the origin that actually delivers the data. Now, if you are translating this to avionics, it means that you have to be 100% sure that in the event of a disconnection between your edge cache and your CDN components on board and your ground infrastructure — the system is still functioning. In the ground definition of edge caching, it would not be the case. It would not work if you turn off the authentication, if you turn off the license. So in the event of an onboard scenario, you do need functionality on board that you actually have in the cloud, to basically sit side by side to support that. You do need a little bit more than just your cache and your edge compute for performance delivery. If you want to have it resilient working — disconnected — you do need to think about how you have additional services that actually support this cache. Nevertheless, what you can count on is less content. You could have quite a big content library on the ground where you do not have everything on board, and request all the files all the time as long as you have connectivity. If the connectivity should drop, you need to dynamically reduce your content library.

Stefanie Schuster: But those additional services — you say supporting, right? They are not part of edge caching. Just to also go into that definition, because we often hear that statement of — I need edge caching and then the solution will work without connectivity. So that's not the case.

Ralph Wagner: No, that's not the case. Not from the definition.

Stefanie Schuster: Then you still need the cloud, if you want to have it operating in a disconnected fashion. You can of course have onboard services, but that's not part of the edge caching.

Ralph Wagner: It's not part of the traditional thinking of edge caching, but it's important. Because if you're thinking that you have a specific file infrastructure, information infrastructure that you deliver from the ground, then the services on board do need to know about them. They do need to understand them. So you need, for example, a service that dynamically shrinks your catalogue in case the connectivity is off — and understands what kind of files are actually currently in your repository on board, so that as a user I don't click and then it's not available. I don't want to see that. You do need to have something on board. This is why in the edge caching solution, it kind of translates to: you need to think about your complete setup. It's not about just thinking about how do I get my files on board? It's also about how to actually deliver them. How do I have a consistent IFE experience — which goes into the catalogue, into the authentication, into the DRM and Entitlement. You need to have something on board that can take over in case you want to count on a disconnected case. And you can go without that. You can say, I don't care, I deliver everything from ground, I do it classic. On board, just edge caching, edge compute — that's it. But then you need to really 100% rely on your connectivity. So when we are talking about caching content on board and doing edge compute on board, this edge compute gets a bit… Because edge compute naturally is about serving performance from a server — helping to deliver requests from a user more performantly. And now this compute gets bigger. Or there is a third pillar, which is a mirroring of some of the services that are on ground that you need on board to have a disconnected IFE possibility.

Stefanie Schuster: If you need the disconnected — that is one part of the decision making. How to set up the infrastructure overall, and how far do I need to go in my edge caching setup. Do I need such supporting or side-by-side services on board? Or can I rely on the cloud because I have the connectivity and I know critical cases are covered.

Ralph Wagner: And also the time is crucial. It could be even a decision over time. In the beginning you are not sure, or there are still some regions in the world that need negotiations around whatever kind of connectivity you are going for, and at some point in time you might not need it. Now there is a second case — the personal devices and your mixed fleet. On a mixed fleet, you have on board parts of services that might also be on the ground. If you have a fleet where on parts of it you don't have a server on board, you have a traditional edge cache — the very traditional one, which is the CDN in the cloud.

Stefanie Schuster: The very, very traditional one. Yes.

Ralph Wagner: In this case, you need everything in the cloud. You need your DRM service in the cloud. You need your Entitlement in the cloud. You need your Content in the cloud. You need your CDN. You have maybe edge compute as well. The whole IFE system streams from the cloud. And your edge caching is the CDN network in the cloud. Because you try also here to get as near as possible to your uplink stations of your connectivity provider. Now, what happens if you have a fleet where you have servers on board and in some aircraft you don't have them, and you want to deliver your IFE to all the devices — be it seatbacks or personal devices. What does this mean for the software setup?

Stefanie Schuster: Well, you still need all the different layers, no matter which part of the fleet you talk about. You have edge caching, edge compute, and the services in all the cases. It's just a question of where do they live. In a fleet part without the servers, it all lives in the cloud and in content delivery networks. In the portion with servers, you can get edge caching, edge compute to the server — or even more services. But it's the same functionalities just in different places. And of course it has an implication on the connectivity and the network — how much bandwidth you use. Because you might stream the same file 20 times instead of once. But the basic setup is the same.

Ralph Wagner: So in such a case, you have everything in the cloud, obviously, because you need to deliver to personal devices. And then you have on board an edge cache, because you want to cache the content. You don't want to deliver more files than needed to the aircraft. If you have the chance to have here top 20 movies, have them on board and deliver them just from an on-board server — that's perfect. The second thing — if you count on disconnected areas, you could preposition more content on board. And you can also have additional services on board that are then like redundant services. You have a DRM service on board that delivers. You have a Decision service on board. You have an Entitlement on board that actually does the delivery to the clients even in a case when you have a full disconnection. So you need to think about the minimum setup of services, which is not just edge caching — it can be different services that you actually need to set up. But still these need to harmonize with the services on the ground, because we're talking about the same files, the same catalogue, the same structure, the same images. Maybe a shrunk catalogue — if you have so many movies, maybe you do not bring them all on board because you have no possibility to enhance it. And in parallel, this solution does not mean that only that is delivered which is on board. The solution delivers also everything which comes from the ground side. It can basically have the full set in both scenarios. But if we are thinking about the scenario on board — you have your edge cache on board — what kind of techniques are there to bring your content on board? What does it actually mean to do edge caching? Because you said in the beginning it means: the user is asking for a file. The file is there — it's delivered. The file is not there — it basically goes back to the origin, takes the file. So in our case, from the server on board goes to the cloud, fetches the file, brings it on board and delivers it. And the second user which asks for the same is getting it. But we know more ways to bring content on board than just this — the classic way.

Stefanie Schuster: By whom is it triggered? You mean by what is it triggered? It can be the user, the actual end user using his device or the seatback — it asks, is it in the cache or do you need to go to the ground and fetch it. It can also be logic, even a service running on the server, pretending to be a user — like some prepositioning service counting on what might be used soon based on whatever algorithms, whatever parameters you set. Or you have some logic running there which predicts what might be relevant. Because I am now flying to Germany, or I have a lot of children on board, or it is right now World Cup time, or whatever.

Ralph Wagner: But this would be a typical edge compute case then. So this would be edge compute besides —

Stefanie Schuster: Well, a supporting service.

Ralph Wagner: The supporting service for the CDN. Okay. And the third part —

Stefanie Schuster: Which third part? I thought you mean — yes, there is a third part.

Ralph Wagner: Pushing. So the way to push it — you basically have the content on the ground and you want to have your 20% best performing. You know this already when you get your movie. So you're basically directly triggering it — this needs to be on this cache, this needs to be uploaded.

Stefanie Schuster: Which goes again into the services on ground, which will help you predict that.

Ralph Wagner: Right. When we are going to this part — the services on the ground — what kind of services on ground do you actually need to fill your cache, to work on your cache, to decide what is going on board? From a perspective now of this push, how does this look like? And is this only movies?

Stefanie Schuster: No, I think it's an important topic to now look also outside of movies. Because especially when you decide what should be on board and what should be in the cloud — is it just about the data which is being cached, or do I need to have services which are running independently in case of disconnection? It's also crucial to discuss for which cases are you actually using it? What will happen in worst case? Is it a movie not playing, or is it some fly data I am not getting? Is it related to IoT? Is it related to transactions, payment, authentication, where it's already getting more critical? So yeah, definitely we should look into other cases.

Ralph Wagner: And the other cases work in a very similar way. You have files that you would like to have near to your consuming entity, which is either your passenger on the IFE side. But it could also be IoT devices. It could also be crew applications. You could basically think about bringing files on board that you run over similar technologies — either on request (the first crew member that wants something and it's not in the cache, then it gets loaded from the ground), or the cache itself has some prediction to get the content because it kind of predicts it would be needed, or you push it from the ground (you say on the ground, okay, this is actually the stuff that crew definitely will need — so you mark it to put it into the cache from that side). Again, it's a combination of cloud side and what you set up in the cloud does need to understand how the onboard side works. And also how all the applications onboard are working — how they request files, how they request content. What does this actually mean if you are talking about edge caching? What do you need to think about when you have your task in front of you? You have a lot of files — in this case, movies are really a lot of files. You need to bring them on board. You have the devices — personal devices, seatback screens, crew device, IoT. So you need to bring files, content, configurations, etc. on board. You need to deliver them. Make them available to all of these entities. What is the whole infrastructure you need to look at? How can you look at it? — our topic about looking at everything at the same time, because it's by the lot, or taking a use case? So what do you think about how you should go down this road as an airline?

Stefanie Schuster: Let's look at some key variables. Connectivity is one. Which kind of connectivity do I have, and how reliable is that connectivity? Can I just rely on that and I don't need to have a fallback solution? Or do I actually need to have a fallback because of whatever reasons — if it's regions or if it's the bandwidth I have, disruptions, whatever. Then another thing in this context of caching is the frequency of using those files — and not only the frequency but also the similarity. We talk here about users and caching content for them. How often are those files used and how similar are the requests coming from users? How much benefit do I have if I'm able to cache that as close as possible to them? Because I know many users will use that, or that data is used really often — compared to: okay, everybody wants to have something different anyway, or it's very personal data, which you typically don't cache so much as if you would have data which everybody uses. Or it's files you actually don't need so often. So it's maybe not so much about seeing the whole landscape already, but understanding what are the critical variables for me, and for which cases do I want to be prepared.

Ralph Wagner: And from the setup point of view, the connectivity needs to be in there. Without this, it does not make sense. If you have a really unreliable connectivity, it doesn't make sense if you have no prediction in there. So then you have an onboard solution, and maybe you have a connection which you can utilize if you're lucky — but you need a good connectivity. If you have a good connectivity, you can basically think about —

Stefanie Schuster: In such a case, you could cache on the devices. Even if everything is on board, you would stream wirelessly from the server — you could cache on devices. That's another area, but actually also edge caching, bringing it even closer.

Ralph Wagner: Right — where the edge cache is then on the seatback screen. I guess this is another episode. The part here for getting it on board and understanding the whole infrastructure and making a decision — you do need to look at all of these parameters. But you also need to look at what can you influence and what can you change. Because the one thing is you can put content on board. The other thing is, can you influence the way how you preposition content? Now you need to understand what kind of possibilities you have to pre-position. You also need to look at the possibilities you have to push content from the ground, and you need to have a look around for a resilient system — if you can extend the system with IFE components. Now looking at today's IFE landscape, these components are usually all made in stone on the server. So what is your take on that?

Stefanie Schuster: We always have this topic of how we started this podcast — the split of hardware and software. It's not such a strict split of course, because it's different vendors, different contexts, whatever is provided and it needs to work together. But that's the important point: it needs to work together. It needs to be possible to integrate, to truly integrate — and not just have the hardware infrastructure, then the orchestration there, then all the IFE services, and then you get some edge caching from somewhere and put it in. You can do that, but it really limits…

Ralph Wagner: It limits you.

Stefanie Schuster: …how far you can go. So then it's maybe an edge caching for entertainment files, period. But it's not the edge caching for transactions, for IoT, for user authentication. And it's caching, which means storage — it does not go into edge compute, more logic around it. So the more open the platform is, and the more it allows you to not just put one edge caching service there additionally to whatever else is there — the more free you as an airline are to really own that and to think about what do I want to cache? What do I need to cache? Which additional services I need side by side or supporting this cache. And then you're truly going into these discussions we had before — how to decide for the infrastructure, what to have in the cloud, what to have on the server, how to support different use cases.

Ralph Wagner: Totally with you. I think we really nicely laid out how it actually looks like — what is edge caching, and how it's supported by edge compute, by origin services. You very nicely explained that you really limit yourself if you're just focusing on the cache. You need to understand what kind of supporting services you have side by side. I think that's a very good closing for this podcast.