 by interface hardware drivers, and it abstracts the IO drivers away from P, S, U, O, C, okay? So, the IOS is really kind of envisioned as the interface to talk to things that are outside of that base implementation. And that's in contrast to the TSS. We really see the TSS as providing the basic network capability and allowing for the exchange of data between the system network of computing resources while standardizing that interface to applications. So, what you'll see kind of here is the OSI stack. We compared that then across the different segments where there's some of this implemented in hardware as you would expect, and some of these things are actually implemented and supported by the operating system, like the fact that the sockets get called out in the operating system, UDP, and TCP protocols. And then as soon as you get to these higher-level services in the OSI stack, that's really where the TSS starts to fit in. Now, a lot of these session presentation and application layers, if you look at that closely, are likely to be maybe more on the optional side of the features and capabilities. But it will present, the minimum, it will present that TSS interface to those PCS and P-TRIPLE-S UOCs. They won't be going straight down here to this OSS interface, which in the face standard is either going to be sockets or airing 602.3, all right? Well, I think I went to the next page. So, how does the TSS compare to the use of a transport protocol module? So, one of the things that really strikes us in this conversation is that a TSS vendor makes an implicit guarantee of interoperability with itself. So, what that means is if you take one vendor, TSS, and you deploy that across your system, it should be interoperable with itself. That makes sense, right? So, if you use the same implementation data sent by that instance in the system can be received by another instance in the system of the same implementation, right? So, in a homogeneous system, where a single TSS implementation connects all system components, the integrator gets interoperability for free. That's what that means when we talk about the TSS in general. Now, we do see implementations where TSS implementations might realize the same wire protocol. So, if your implementation is based on a protocol like DDS and there's a wire protocol defined, then you get that interoperability across vendors just by selecting your implementation to use that DDS, right? We don't necessarily see all situations using the same middleware, which is one of the reasons why we ended up with the TSS as opposed to just requiring all systems to use DDS. But where the TPM really comes in is when we have a heterogeneous TSS implementation. So, what happens is it kind of creates a very local implementation between those two instances of the TSS. So, in general, there's this idea that these things can talk on the network. Every instance of the TSS can communicate with each other. But when they don't match in terms of protocols or technologies, in terms of the nodes of the network, then you can add in a TPM and you can create a local service between nodes of the TPM. And I know I'm running kind of low on time here, but this really is my last slide. So, this actually is part of the white paper. And we actually put this together when we wrote the right white paper. And so, this really talks about the intersegment, introsegment, and then other interfaces that are described within the standard that touch the TSS. These are the TSS EOCs across the top. They are in a different order than Table 7 is in the system. So, don't be thrown when you do that. And a lot of that is just because the users and providers of these interfaces can get, it gets very busy. So, they're out of an in a different order so that we can consolidate these user and provider indications. The gray really means that the interface is an optional interface. And there are some user notes like who provides this. So, you'll see like the recall backs is being used by the Transport Service, the Framework Service, or the TSTA. There's confusion in terms of who actually implements the recall back. And so, this table is to try and provide some clarity in terms of who all the providers and users are of the various interfaces. So, you'll see component state persistence. Here's type abstraction. We did add in the injectable. And at first that was deemed that we wouldn't necessarily need it. But I think it did provide us some additional clarity. The areas that we're still discussing is around the base. And the other one is around the serialization and who should use serialization. We envisioned serialization came in with the TPM, but there's been a desire to expand its use across the TSS and you do that in a standardized way. But in general, this is where we sit today with those interfaces. All right. I'm going, I think that's it for me and get to the last slide. Nope, that's it for me. All right. I didn't put a contact information. If there are any questions though, I think I have a few minutes. Actually, there is a question. Here it is. Is the TSS intended to support the communication between UOC running on different machines slash nodes? Question mark. If it is, can the transport protocol be, for example, mill standard 1553 and not ethernet? Yeah. So that's a good question. If you create a system design where your backbone network is mill standard 1553, then we would technically say yes, you could go implement a TSS in that manner. I would, you probably have a mismatch of technology to intended use, but in general, the standard does not govern what you use as your backbone communication. And yes, we do intend for the TSS to cross the physical boundary of the computing resources and to establish the network in the system. Okay. And that's it for questions. Thank you very much, Stephanie.