 So good morning, lunchtime, whatever you want to call it. So I want to talk a little bit about OpenStrat as a solution for power effective or low power IP connectivity. So my name is Stefan. I'm working at the Huawei Open Source Technology Center. I'm a long background in open source. I started working like 2005. I started to look into kernel development and stuff like that. And over the last six, seven, eight years or something, I'm one of the co-maintenors of the 15.04 Substance and Linux kernel, which is not used in this talk, but I have a lot of 15.04 background and so on in this area. So what is the agenda for what I want to talk a little bit about? So giving a little bit of a scope to make sure what I want to talk and what is not part of it. So we all know that and what you can expect. I want to talk a little bit about the power budget we are talking about here. So because everybody is saying embedded IoT, everybody has very different opinions. It's a huge range of things that could be labeled as embedded IoT, right? So then I will talk a little bit of open thread, giving an overview. So I don't know, maybe some people have background in that and maybe not. So like setting a baseline here to have like a basic understanding, then have a few words on like bare metal versus a return operating system versus Linux. So also especially on how I used it. And then I go a bit more into the technical details of what open thread is using in terms of technology. So one of that is six low pan. I will talk about that, what it is and how it is used. And also things like multicast, DNS discovery and service registration protocol, which are more like new developments in thread to also help on the power side. And I will closing down with like some, talking a little bit of the work I did over the last year in form of a transparent gateway blueprint using these two kind of technologies and just one slide about an upcoming standard called Meta that might be relevant in that space later on. Okay, so let's go. Low power, low rate wireless. So that is like low rate means I'm not talking about like video streaming or not something like that. I'm talking about like a few bytes sensor data are being sent back and forth. So that's like what I'm talking about. And I want to make that very power efficient. So actually I can run the device on a coin cell battery for like years and not like just a day or week or something like that. I'm also talking about IP version six end to end. This is something that is very much to my heart. So there are a lot of solutions there for power and so on that give you a lot of characteristics and possibilities but they often don't go with a full IP stack or something like that. And they often don't really go with end to end connectivity. It's often at the hub or the gateway or something and it doesn't go up to your, the other device you're communicating with that could be the cloud, it can be something else. So that is also something I have in mind. And I'm also talking about mesh capabilities. So one of the few of these wireless solutions have like end to end connectivity which is working quite well for a lot of use cases but having mesh is like enabling a lot more wider nets to be available in your home, in your industry, in your factory or whatever. And I'm also talking about sleepy end devices which is like crucial for like the low power part here. Some caveats here. So I'm not working for the sweat group and the company I'm working for is also not a member of the sweat group or something, right? I'm really only looking at that for like an open source solution. So I was looking around what is available, what is like available in a form that I can integrate it easily and work with and maybe offer to some customers or partners or so on. Something so we wanted to use in the O'Neill project but I was looking around what is available and that's really based on the open source stuff here. So power budget. So the white screenshot you can see here that is from a white paper from the sweat group. So how they define their like power budget and how they think open sweat can be used on like small devices. So that's basically the calculations they are putting in there. So you can see like the link down below that's the link to the white paper that's all public available. So if you want to have all the details and everything like that, you can look into that. But it gives you an idea. So the scope they design or the sensor profile they're designing is like having a data report like every 60 seconds to maybe one hop or maybe a few more hops away and then checking in with a parent like every four seconds. So the checking in with a parent means the device is sleeping for the rest of the time. So that's very, very crucial for the power consumption that you have a way to like that the parent is holding the data for you while you can sleep and then checking in every few seconds or whatever time you want to define there. And the application data, so the payload itself it's they define something like 36 bytes that should be enough for some sensor data. It might depend on a use case and so on. So take all these numbers obviously with a grain of salt it has to be applied to your own use case needs but it's like a good baseline for you to understand what kind of things we are talking about. So I marked that up, you can see here that that is what they aim for like with this kind of profile they described here. So they go with a coincide battery with 200 milliampere and with all the calculations they are doing they hope to aim for something like three years. So even if you think that's like that is not what I'm using. I have more logic, I have more data or whatever I wake up more often or something. Even if that goes down to two years or something I think that's still very competitive and interesting use case you can like have your door sensor or something sitting there for two years instead of changing the battery like once a year or like over six months or something. So this is like the scope I want to talk about here. So how's the relation between 15.4 which is the underlying radio spec they're using in thread which is basically the same they're using ZigBee. So there are like a few functionalities within the spec that they are reusing in thread to make these kind of things possible. So there's like the reduced function set devices which are designed for like sleeping and being low power and so on. Some of them, some of the ships actually have like only receive or transmit capabilities. So that's how far down you can go. Most of the time you don't want that, you want to have both but you can, if you have a very specific use case there are also ships for that. And then there are things like in 15.4 there are things like the data request command to pull the parent. So that is what I meant with like waking up every four seconds, sending out this data command pull request and in the act that you're getting back there's already a bit field where you can say like there's a frame pending for you. And so then at that point you can say, okay, I need to ask for all the data from my parents that is queuing up there, getting it, processing it and then reacting in whatever way. And normally, hopefully that should be set to zero and that means I just work up send out one frame, get the arc, pass it, go down to sleep again. So that's like how you can really efficient do that in 15.4. So this whole relationship between sleepy end devices being a child, this whole relationship with the parent, a router in OpsetSpeak that is like what Opset really took over. And there's also other things like you can have like short addresses. So in 15.4 you have like short and long addresses could be like 16 bit or 64 bit. And if you want to save power you might want to use like the 16 bit addresses only in a given small range that is working quite well and then you don't have to transmit that much data. Again, so here you can see like one example from Nordic with like there was like some data sheets that put out for like their power consumption on the Nordic chip. They're using the specific sample data for the 52, 840. And here you can see like the numbers they argue with these kinds of the measurements they're doing for like various setups like sleeping, data requests in different power conditions and so on. So this is like to help you to understand what the scope is here basically. And yes, there's a lot of other solutions and Wi-Fi and Bluetooth low energy are definitely high on the list. And they definitely have a very good use case and what I'm talking about here is might just not fit well for what you want to do. So these ones might be better. It really depends on the use case and the profile you're having. So they're both very well established already. So especially like finding them in your phones and so on. So for Bluetooth smart for example having like an accessory connection to your phone that's like where Bluetooth really shines because it's already there. That is something you can do with 15.4 or something. Bluetooth is like kind of on the same power budget. They're also sometimes like chips that's like using the same parts of the core maybe even the same antenna on something like that like the Nordic chips they can use like Bluetooth and 15.4 but there are other solutions as well. So that's definitely an interesting point but if you're going to go like full mesh and having IP over that then it gets more tricky because in mesh stuff in Bluetooth is, I mean it exists. It's not very widely deployed and this really has some problems here and there. Also had a lot of latency problems. If that is not a problem for your use case, go for it. It's like very well established and the same if you have like a lot of data you want to transfer or you want to reuse existing infrastructure like in a building or something like that by far is always there but you have to keep in mind power budget is very, very different. Just to be fair here and clearing that it's not like one thing to rule everything. So open thread overview. The thread group is like the governance body to do all of that. Like so they develop the specification basically so all the companies come together there paying a fee then you get access to the working groups and specification development. This is like behind closed doors if you're not a member you don't have access to that. The thread 1.1, so 1.0 as well but 1.1 specification is publicly available so you can get that and develop against it if you want. Members already have access to a newer one. Again, I'm not a member so I don't have access to that. I just want to list it up here that is like how you do it. And if you want to do certification so you want to really get a product out that you want to be certified against thread to make sure that everything is working together you need to be a member you have to pay a fee and so on to do that. But for my use case developing prototypes developing open source software around it it was completely fine to just go with the open thread open source project which does exist. It's under the BC3 license. It's very active and very welcoming. You have to sign the Google CLA if you want to do upstream contributions which is something I don't really like personally but that's just how it is. It's driven by mostly by Google and Nest employees but that doesn't mean they very actively react on feedback from the community or something like that. So that is good. And it's a very established code base and also used in commercial projects and so on. So it's really nice to have that available. So in thread you have like different device types. So I briefly mentioned that in the beginning we was having like reduced function devices and also have like full function devices and so on. So that is like a full thread device is something that can act as a router and it would forward packet this and always has the transceiver enabled which is obviously impacting how the power budget is for these kind of devices. And then you have like so called read devices, router eligible enterprises which are basically standby, which are a router standby device that can get a router if the network needs it to like have more a bigger coverage in the mesh and so on to fit, yeah, to cover more devices and the address of it basically. And then you go down to mini build thread devices. They have reduced functionality are more designed for like low power and stuff like that. They're often designed as sleepy enterprises which I mentioned before like turning the transceiver off waking up only periodically and Paul messages from the parent described that already. And there's also something new which I think it's not part of the 1.1 spec. I see that they started to implement it in open thread. So I would expect it to be like in one of the newer specs which is synchronized schedule with the parents so synchronized sleepy devices. The key point here is that this needs a newer spec for the lower layers, the 50 note four layer. So it does normally spread needs like the 2006 edition this is really old. So normally all of the hardware would work with that. But for this one you would need a specific part called coordinated sample listening. So that is part of the spec and the hardware need to support that and so on. So this is something you keep in mind but it could help to have like synchronized schedules with your parent and even save a bit more battery. You also have different device roles. I touched on that with like the router being like forwarding packets and holding packets for as a parent for the child. So it's queuing them up until it wakes up. This always have to be in the reason obviously so you can't go ahead and say your child only wakes up like once a year and you expect the router to queue all the packets and everything that has been waiting for it. So that's not going to happen. But within reasons that is working well. Then you have the enterprises. They normally only communicate with their parent as a router and then you can disable the radio if you want. Then you have the threat leader which is basically like coordinating all the different routers in the network making sure that all the network information is distributed equally making sure that new devices can be commissioned into the network. I leave a lot of stuff out here because that would really go into a lot of details but threat is also allowing you to like how you commission a device into the network as a protocol called link establishment to make sure that all the links in the mesh networks are keep working and so on. So that is all like handled by the threat leader to make sure that it's distributed. And then you have a border router which would be a device which has on the one hand a link to a threat network. On the other hand have a link to a non-thread network and then being able to like root packets back and forth. This could be like commonly things are like the Apple TV and the Apple iPod, this pot thing, I don't know what's the name is, the speaker, whatever. So they have like devices, they have like Wi-Fi on the one side and threat on the other side and they would make sure that the packets are getting forwarded then back to the cloud or just in your home or something like that wherever you want it. And you're not bound to one. So you can have like several border routers in your home network which is great because if you like turn off your Apple TV or something like that then the threat network can just go over the other border routers and still be in communication. So you don't have a single point of failure at that point. Going to addressing. So it's IPv6 based. They have like different scopes for the addressing here. So they have like the link local which are all the directly reachable devices, the different nodes. And they're all within the FA80 IPv6 prefix. They also have a mesh local prefix. So that's like for all the devices in the mesh network they have a dedicated IPv6 prefix for that as well. And then you have like a global address that can be depending on the setting of your network can be reached either from the whole internet or it can be isolated or something like that. So it could be like isolated for your campus, your home, your factory or it can really reach out to like whatever server in the cloud where you want to put your data on or not. Which is really depending on how you set that up. If you want to go into more details of all the addressing. So that also has something called Routing Locator, ALOC, which they use very cleverly to like identify the nodes within the network topology in the network. So I don't go into that, it's going too far. But this something could be interesting if you want to know about that. Again, I put a link into that. So there's a guide about the thread primer from OpenThread where they talk about that in a bit more detail and also give links for further information. So give me a moment, that's better. So talking about OpenThread, the OpenSoft project, what kind of components do we have here? So we have, it's all sitting on GitHub and we have like one core repository called OpenThread. It's a core implementation, little of tools around and so on and also like the OpenThread daemon which is like a native POSIX service you can run under Linux if you want. And then you have like a load of different extra repositories where all the vendors can support their own socks and chipsets and so on and make sure that that is working. So this can be used for like the bare metal scenario where you run OpenThread and then combine that with one of these repositories and run bare metal. So basically what these repositories are like are the whole or the SDK from the vendor and then integrating that with OpenThread. So you can have like a use case for that. There's also a repository called OTRTOS which is based on FreeRTOS together with the LWIP. A networking stack. Haven't seen a lot of work going on there recently. So I think it's like a bit on a maintenance state or something, but it is there. And then there's the OTBR POSIX repo which is the full implementation of a border return on the Linux side, which takes most of the OpenThread repository like the OT daemon and so on then has all the glue around it to make all the services work and so on. And then there's an older thing called WPEN TUN which is used for network co-processing, interfacing. I come to that in a moment. So and then in addition to that, there's also the integration of OpenThread as a module into Zafire. So Zafire as in OTRTOS. They basically take the main repository and like add all the glue code you might need to make it work together with OpenThread. And that is something I've been using in my work. So bare metal with OTRTOS, with Linux just makes it short. There are use cases for all of these, definitely. Bare metal, obviously if you are sure you want to only go with a specific ship set, you have a very good relation with your vendor, for example, and you want to go to a really, really minimal approach. You might want to go that route. You can bring the price down if you go like high volume or stuff like that. It's normally, it's a sock design. It's normally go for like sleepy enterprises and minimal enterprises and it's normally battery powered. So really, you optimize for price here. You lose obviously flexibility. If you go for an RTOS, you might need a more pricey ship because you need more RAM and so on, but then you have more flexibility. Maybe you already have an application that running on an RTOS. You want to bring over some business logic or whatever, right? So you have to trade off here. And as I said, there's OTRTOS and OpenThread and Zafire to use that and you can do all kinds of designs for that. You can go from sleepy enterprises up to like a full router. I think I even saw like a solution on Zafire's side with being a full border router with OpenThread. I don't know if I would do that, but it seems to be possible. And as I said, the use cases means that you can either be battery or main powered at that point. The Linux side on the other hand, you normally would not go and make that just an enterprise. You could do that. I mean, there's something like OT Damian which can basically just act as an enterprise if you want to. And there's the full setup is OT border router. And then there's like two scenarios how you would use that. There's like the RCP and the NCP. So it's the radio coprocessor and the networking coprocessor. The main difference here being like how much of the thread stack is actually operating on the firmware on the radio side and how much is sitting on the Linux side. So the network coprocessor, there's almost all of the thread stuff is sitting in the radio firmware. And I mean, you still have control over that if you build it yourself and so on. But in the radio coprocessor is more like more the logic is sitting on the Linux side. So that is right now RCP is a bit more like in favor of this OTBR and so on. But again, depending on your use case, how you want to do that. But these devices are normally main powered. I mean, you could have like a Linux machine with like a big battery attached to it. You could do that, but normally I would expect these things to be like main powered. Okay, so going to the technologies that are used in OpenThread. One of these things, one of the key things they are using is six low pan. So six low pan, what is it? So it's like really like decades ago, people want to do like low wireless, low power wireless as well. But at that point, everybody's had like TCP IPs. That's just a waste of, just wasteful, right? We don't want to do that. We have like our own solution. We have our silos. We have like one vertical use case only where we go and we want to develop that. And we don't care about like working with other vendors, other systems and so on. So that worked for a while. And to be fair, at that point, the ships obviously haven't had like enough resources for all of that. But around 2003, they started to look a bit more into like micro IP stacks to get that into micro controllers. See what they can do there. But at that point, the focus was obviously more like trying to get it working at all and not so much focusing on frame size and like deployability and stuff like that. So in 2003, also the first 15.4 they're not have been kicked off. And that drove a lot of like academics, but also like industry to like look into how that could maybe use for low rate, low power with IP. And in 2007, they started to have like ITRFCs that actually define how you would do that. So Six Low-Pent is an RFC that helps you to like transmit IP version six over 15.4 frames. And by now, there's been a lot of like new RFCs coming out of that. So Six Low-Pent was, so 15.4 was the first one, but they also adapted it for Bluetooth, NFC, PLC and all the things. I think I missed a lot here. Okay, so what is it in a nutshell? So what Six Low-Pent is offering you is like it offers you one encapsulation and second header compression. So it is sitting as an adaption layer between link layer and the original networking layer. So it's sitting in between. And that normally means because for like IP version six, you need like 1,280 bytes like as a maximum packet size that might be used. And that is clashing very much with like the 127 byte maximum transfer unit that 15.4. So that's like a definitely a mismatch. So at that point, you needed to bring back like fragmentation, which was not really seen like needed for IP version six anymore. So they bring that back in the encapsulation frame. You still should avoid it if possible. So if you design your upper layers and you can avoid it to like send too much data that end up in fragmentation because it can have like bad performance in a lossy network, but it's still, it is possible to do. The second part is the header compression. So IP version six has like a 40 byte header you would need to put in there. And if you see like 127 byte, it's the MTU. That means 40 byte of that is like a huge chunk already taken just for a header for one of the protocols, right? So what they implemented or what they specified is was like how they can reduce the size of the IP version six header and maybe also the header coming along like UDP and so on. So that's what they, what they're done. And they have been a lot of iterations around that. So you have like header compression one, header compression two, IP header compression, next header compression, generic header compression. So a lot of these things going on. The first one, the first two are no longer used but the rest is still in use some here. So to demonstrate that a little bit, you go ahead and like have like a scenario where you have like your frame header that can be like, so I'm taking like the worst case scenario here, right? So 25 bytes as a frame header itself, then you want to have like link security already enabled for AES encryption stuff like that and 15.4 that is something the specs supports. You want that, so it's 21 bytes gone as well. Then you put the raw 50 IP version six header in, 40 bytes, then UDP and you end up with like 33 bytes of payload, which is a very bad ratio for like for one frame to get a bit data through. But it's obviously not ideal. So what IP version six is in a nutshell here, right? So the IP header compression, it looks, what kind of fields in the IP version six header are available and which we really need and the other ones we don't need, we can just screw, right? So like the version, it is always six because we know we only transfer IP version six header there. The traffic class and the flow level, we set to zero, we ignore that. It is a limitation, but it's something we are willing to pay at that point. And for like the hop limit, for example, instead of having the full range, we are only having like well-known values like 164 and stuff like that. So it's really reducing the scope and the number of bytes we need to do there. So length field, again, can be coming from the fragmentation header or it can come from the data link header. Yes, I know that it's kind of a layer violation if you want to look at it like that, but that is what really helping it to like make it work and make it work in a very good way, basically. So, but the other big saving is to don't have like the big IP version six addresses transmitted all the time. This is depending a little bit on the network setup and what the other end is for the communication. So how much of the prefix you have to integrate into that. But if it's linked local, the prefix is known by the network, so you can delete that. And the rest of the local address is basically just a part of the MAC address from the device itself, which is coming from the L2 already. So you can reuse that as well. So you can delete all of that if you want. And then you end up with six bytes instead of the 48 or something we had before with UDP and IP version six. So again, something we didn't change here is like the frame header and the link security. That is still all the same, but the red stuff is that what we reduced down. And that means we have like payload up to 75 bytes, which is quite good at that point. So the ratio is a lot better. Some Michelinius tips, I mentioned that before. If you can avoid it, design your upper layers in a way that they are not resulting in fragmentation of, so really make sure that you can fit it in one frame if possible. For sensor data that might be enough, for others not, it is working. It's not like so dramatic or something, but if you have a lossy network with some frames are getting lost, it's kind of really have an impact. Also initially there was a big push forwards to avoiding TCP, having the three way handshakes, the latency involved with that, with all the TLS and so on. There was a big push of going just for UDP and TLS. By now there is support for TCP in OpenStrat, and it is working better now. There are some solutions. Some people on the Berkeley University, they have been like working on like, how can they optimize that and so on. So it's working better now, but yeah, you have to make your trade off there as well. And then again, there's like protocols like co-op, like constraint application protocol, also designed by ITF for these kind of networks, but you don't have to use that. So there are other ones you can go with. Okay, so the next thing, I wanted to look a little bit into it because that's like related to power budget, power management, no, power management, sorry, for like the power budget for the whole network basically. So, okay, thanks. So there's like multicast DNS discovery proxy, which has been developed, and there's a service registration protocol. So the first one is already an idea, it's already a spec, it's already there. And the idea is to avoid sending the multicast traffic you're having into the threat network because in the threat network, that is broadcast. That means every device gets it, it might get filtered out on the hardware filter, or it might get filtered out really early in the stack, but still there might be some processing. And in the end, this data that's wasted and battery cycles that are wasted to do that, right? So what multicast, what the discovery proxy is doing, it's really, it's reaching out, finding all these kinds of services are available and offering them over unicast. So basically you can reach out, do that on the threat network and have the proxy sitting on the water router, and that would allow you to have like unicast traffic only to the one device you want to talk with, and then do all the data communication you are going to do, and instead of like broadcasting to all the traffic. This is really what reduced it down basically. And together with that, there's a service registration protocol. This is still a draft and development, but there was the idea coming, I think also coming from the threat people that they wanted to have like a way of register that with the boiler router directly. So the small end node would say I have a service, but I don't want to be available all the time to like react on that. So I register myself, I'm here, and then I can get waking up and then have the transfer going on. All of this is optimization. You don't have to do that. And the end-to-end paradigm from IPv6 is still working. So when I initially talked about like the history of six local and stuff like that, where you had like a vertical stacks and no interoperability with others and so on, that was like often the case because you have like an application level proxy where you would have like doing all the handling and so on. This is not the case here. There's no interruption or something like that. It's still the same. Which brings me to what I've been doing like on the last year, working on a transparent gateway blueprint. Transparent here is the part where I say there's the end-to-end paradigm, it's still standing. So you don't have anything in between. You want to have maybe a fireball or some rules or something like that, but the rest is still there. So that's something I've been working on for the NIO project. So the idea was to have like a Wi-Fi access point, have like ethernet obviously connected. And then you have like a border route on the, to host your mesh and stuff like that. On the Linux side, and then you have like small end devices in our case with the fire to also run open thread to either be like driving whatever application. So a door lock and stuff like that. So we have, we toyed around with various things here. So you can see a picture of what I did there. So it's, I try to use like very common devices that are easily available on the shelf. So it's the Raspberry Pi 4. And then you have like here, this is a Arduino device with a Nordic chip set, which is very well supported in the fire. And here's another Nordic device as a USB dongle which acts as the radio coprocessor basically. So the idea was really to like start a bit fresh, take modern technologies that we have and try to develop something in that space that might be interesting for our partners. So the current demo is like based on open thread on low-pan. It's all done and built with Yocto. All the receipts I did for that are upstreamed already. The fire side as well. All the, we didn't really have to do much fixes, but what we did is upstreamed already. They are very active working on that. So we have like demos for like the application, the fire application acting like that, as well as the Linux side for having like the whole setup bring up. So that is all the integration. And so it's working. And it's basically also a very nice kind of a turn case solution but because the thread group is offering an Android application that allows you to onboard devices. So that is why you have the barcode here or the QR code here. So that means I take like the thread dongle, the thread device out of box and want to onboard it to my network. So what I can do is like I saw on the packaging on the device itself, I have the QR code. I scan that, the mobile app initiates the commissioning with the border router and then it like integrates the device and the network without even the networking key never leaving like the network itself. So it's getting transferred over and then the device is onboard into the network and then have all the IP connectivity it wants to have. Just one more thing about Matters. It's an upcoming standard. It's interesting because it uses thread and it's also designed in the application layer protocol on top of that. It is also an open source implementation of that. The spec itself and the SDK to be like 1.0 is expected to come later this year. I don't know at what point it will happen or not but it's designed by the connectivity standards aligned which was formerly the ZigBee aligned. So that's like they still do ZigBee but Matters like the next big thing what they're planning on. And it's basically a lot of big players going in there like Apple, Amazon, Google, you name it. They're all there. The interesting part here saw is that they have a mechanism called multi-admin and what they aim for is having like devices connected to multiple platforms. So that means I bring in my device in my home network and whatever I have an Android phone I want to control it with Google Home or something or my brother wants to control it with what's the Apple thing called like HomeKit or something, right? It should in theory work with all of them. So that's one of the promises they are doing. You have to see if that holds up or not. That we have to see in practice but I think it's very interesting and for me obviously it's interesting because it allows like these whole mechanisms of having like sleepy end device and something like that. That goes from the bottom up to open thread into Matter as well to really make sure that you have like a door sensor that can live for like two years or something like that. And with that, I'm closing down. Thank you for your attention. Also, thank you for the internet for your attention and we have a whoever boost down. I'm sometimes there if you want to catch me or maybe you have a few minutes left. I don't know. Okay, so, questions? Go ahead. Okay. Okay. Okay. So what was he? It is, yeah, it's also very costly. Okay. So I mean, I've seen it like running for customers in deployments and so on. So it is possible. It is more like, yeah. This is a fair point. Yeah. I mean, that's definitely going that direction. But as I said, I don't know. We have to see what it really holds up to. I mean, that's the expectations we have but if it's really brings that, not. Yeah. But it's a fair point. Good. Thank you. But I mean, you're using like mesh. Bluetooth mesh. Okay. And you have no problems with latency and stuff like that for the application you're having there. Yeah, depending on use case, obviously, yeah. But it's good to know. Thanks. Okay, thank you. Over there. Not at all. I can talk about it, but it's not fitting in at all. So I'm the cost. Really? I will it. Okay. So my, okay, that's not part of the presentation, but yeah, I'm the cost as a sub maintainer of 504 Linux. And I obviously have an interest in that. One thing could be to have like an abstraction, hardware abstraction in open thread to run that instead of like going through all the spindle stuff and so on, talking to your radio coprocessor. You would go directly and talk to the radios to the next steps and so on. I've been thinking about that. There haven't been any work done yet. I would love to do it, but it's more like a spare time thing or something. So yeah, it's on my personal to-do list. I don't know when I come to it. No problem. Okay, so time for one more question. Okay, nobody. Okay, thanks again. Thanks again for your attention and bye-bye.