 Okay, so as I said name is Stefan Schmidt. I'm working for something on source group Running your own six local network We'll talk a little bit about that what you can do on the link side and what you can do on the on the client side There's different operating systems there So the agenda That's all in the morning or I mean it's not that early anymore But if you start with a little bit of a motivation, then I will go into the Linux WPN project There's just the base of most of these things here and then I'm gonna talk a little bit of the user space utilities We have to configure the networking stack on the on the kernel side Then I go into the what kind of hardware we are supporting right now what hardware you could use The basic setup you would have to do to get that running And then I will take a bit into how you communicating this with riot That's one of the operating system for Internet of Things and the other one would be Contiki So that's what we are testing against here I Will finish up this a little bit inside in the link there security which is the security specified by the fifth not for specification itself Just goes through it always Yeah, and then we close up with some some words about the current routing situation We have so I saw it over or mesh under networking protocols there Just a small advertisement in the beginning here. We will have a demo showcase at the technical showcase tomorrow evening That's together with a colleague of mine who is running who's working on the JavaScript engine called Jerry script So what we would have there would be on one side a Raspberry Pi with the fifth not for transceiver on the other side a small small note with my control and to transceiver and One side runs the other one runs the riot and both are communicating over six low-pan and on both sides That's running the JavaScript engine and then they are communicating doing a networking game for Tetris So that would be something we showcase tomorrow that would also be a possibility to ask me more questions But I should be around for all days here. So Good, so let's get started here. I'm 15.4 It's a IEEE specification designed for low rate on personal area networks In fact, it's not only for low rate, but also polar power So one of the design goals have been to have something like a small sensor or something like that running on a Coinset battery for many years or at least a year or something I mean that obviously depends on the duty cycles you're having on this kind of devices Deuze like us for radio as well as normal code. You're running Some characteristics here The MTU itself is quite small one out 27 bytes and the bandwidth you have is also not that big but for Small scenarios where you don't want to transmit that many data. Anyway, that's quite okay One confusion that often comes up is this confusion between 15.4 and Zigbee So Zigbee is using the fine Mac layer. That is what is defined in 15.4 So they're using that on the lower layers But everything on top of that their own application layer and in the beginning also their own networking layer That was also own in their own specification protocol suite Six low pen on the other hand Is something that sits on top of these fine Mac layer which has been defined by IEEE So six open is something that comes from the IETF starting from 2007. There are two main RFCs for that that actually helps there 49 for 4 and 62 82 But they're basically defined as an adaptation layer sitting on top of the Mac and below the normal IP version 6 Protocol so everything on top of that doesn't really know that it's using six low pen or what kind of fire Mac layer It's using so all the whole adaptation all things are happening transparently so the whole motivation for that is That in a 15.4 network with such a small MTU You would need to go to have some sort of Header compression or something like that to make sure that you're actually getting a lot more payload Through the normal network if you want to use IP in that case So just the worst case scenario calculation here if you start with the maximum transfer unit for 15.4 And you would deduct the maximum frame header from 15.4 itself You would be down to one or two bytes already if you then enable link layer security You'd be down to 80 bytes if you then would use a normal IP version 6 header and UDP you would be down to 33 bytes Which means it's just 33 bytes payload in in one frame You're sending out the ratio is really bad in that case So you have like one two one three to one for header versus payload So that's something you normally don't really want to use in your network because that means you can transmit just a few bytes And the rest is just wasted for headers. I mean obviously that's the worst case scenario calculation to make a point here but Still it's not a good thing if you just use a normal IP version 6 header But still a lot of people want to use IP on this kind of device On this kind of network on this kind of device because that's a proven protocol People know how to use it you have a lot of other protocols depending on it so there would need to be some solution for that so and The solution in that case for the for the size would be header compression I go into the details of that a bit later So that's just still motivation here if you would go with the IP version 6 with just linker communication and UDP on top of that And you would use IP header compression with next header compression for UDP You could shape down the 48 bytes for the header Down to something like six bytes which in the end would mean that you would have instead of these thirty three bytes For payload you would have been going up to 75 bytes So that's quite a gain here the ratio you can see that approved as well So that's something where you can really make a difference in that case So why would we do this kind of work on the Linux side? A lot of people ask me that because I think it's just for the for the center network So for the smaller device or something like that But in the end you need something that communicates with the rest of the network being it either the wireless in your home or the ethernet or whatever Just as why the internet you need some kind of border router scenario And that is something where Linux really comes into play because that is used in this kind of devices Since years already so that really would mean that having Having support native support for 15 or four and six local in the kernel and in the US based utilities Would really help to just run a normal platform We already have at a 15 or 14 see what to it which is quite simple to do Adding to that to an existing hardware design You would be just extending your your product in that that area for example Yeah, an example would be the Google on hub router That's an we're not at point that something they have a 50 not for transceiver already inside the hardware It's deactivated. It's a moment They talk about an evidence that with some software update at some point I don't know if it's going to happen or not, but they have that another thing is the CIF 40 creator board from imagination technologies But it's aimed to be an IOT hub at home They also have a 50 unfortunately directly on the hardware and they they're using our Stack for that part. So that's really helping them I mean on the other hand all kind of smaller device you have like being battery powered and so on there Most of the time unlikely to run something like Linux I mean, especially if they're just in small MCU with a whatever 64-bit of RAM or something they would run something like riot or contiki or maybe that fire or something else there Okay, so what is about this project itself? Just a few Few corner points here Yeah, our main goal is to get 15.4 and six open support in the main on Linux kernel It was started in 2008 at that point. It was still named Linuxic be Was started on source at that point Mainlining really start in 2012 So it took a long time to get to that point and we really at some point decided that it's needed a rename because a lot of People got confused with the this is it be part here We never had any support for the for the upper layer of the be application level protocols and stuff like that So really just only fine max. So we made sense to rename at that point We got a new maintainer who's maintaining the things. You said you're not here today. That's Alexander ring from Pengatronics And the rest is just yeah, the normal kernel development model So we are just posting patrick's remain this they're getting reviewed and then applied and somehow find their way to the Tooliness tree at some point. It's a quite small community They're just two core developers. That's mainly Alexander myself There's a few more people interested in the in the drivers to support their own hardware or maybe in some specific areas of the stack or so But I would say that's not more than four more additional people So as I said, we small one on the other hand, there is quite some interest the main does itself has Over 90 people subscribes to it. So that means there's some at least some interest sparked there on the IC channel We also have over 20 people hanging out there Which is quite good to see Yeah, on GitHub we have our use base utilities and stuff like that. So, yeah Nothing too important So the current status we have. Yes, the 1504 layer. It's already mainline since quite a few years We have support for various transceivers. So various soft Mac transceivers. They have six open support for fragmentation Reassembly, which is needed for the 1504 part because it's a small empty you have you need to handle fragmentation reassembly because the IPv6 packets might be bigger than that We also have support for header compression IP header compression and next set of compression for UDP There are some gaps there, but the important things here for UDP that is already working That is shared with the Bluetooth subsystem because you can also run six open over Bluetooth and The catacompression part here shared and the fragmentation part is not shared because Bluetooth does not need that They have their own mechanism for that. We also have link layer security support in the kernel At least the button nuts and bolts for that I mean all the stuff to make it really usable are more complicated But I have some more slides on that later and we're doing regular testing between Linux and Linux links riot links and Kentucky So, yeah, if you want to play around with that you're bored or whatever you're working on should at least run 4.2 4.1 I would say we have earlier support, but there have been a lot of bugs and so from 4.1 onwards should be better What kind of development boards we are working on or what kind of stuff is available? On the down side on the right here, you can see the CI-40 crater board. That's a board released from imaginary technologies just a few months ago, or they just started chipping them, I think They already have a transceiver directly on board So that's something you could certainly use. The most popular one is just a Raspberry Pi with the OpenLabs shield Which basically is just an admiral transceiver just in a small nice package So you can just drop it on the header so that makes it easy for people to just plug it in instead of Finding out what kind of pins you have to connect to make sure that everything is set up correctly I think you can get these shields for something like whatever $12 or something ship from CS So that's quite cheap So that's some of the boards that most people are using actually Then there's the Arctic 5 and 10 that's a board from Samsung. They also have to 15 to 12 transceiver Directly connected that one is actually a networking sock So there is a microcontroller that is driving the transceiver and then the microcontroller is talking to the main CPU So you can offload some parts to the firmware if you want or so on I mean that is not that widespread right now. So the Raspberry Pi is used more often And I mean we have support for other drivers I come to that also and all of them can normally easily set up to whatever embedded board you you favor today It's basically most of the time It's an SPI port and some extra GPOs for IRQ handling and some some signaling so that's really easy And all of our drivers entry have device tree handling the binding so that should be also easy to set up The thing on the left side here you can see that's in USB dongle Which is really handy if you want to develop on your normal laptop or workstation or whatever you have Sadly this thing is sold out right now, but we are working on producing another batch of these Yeah, I hope for hope that we are going to get that doing this year. So Yeah, so a fragmentation I already started talking about that The MTU we have in 504 is just too small to transport What we need in minimum for IP version 6 Packet so we need to have some sort of a fragmentation header or mechanism inside the adaptation layer and six open has an 11-bit fragmentation header in that case so we can have packets up to size to 2048 I would still not recommend to go with protocols or Design the application in a way that you're using this kind of big packets because you're still in a lossy network in that case And if you really have to retransmit all the frames and stuff like that the fragments that really makes a Bad impact on performance quite often So really make sure that the upper level protocols you're using are quite compact So there are things like co-app for example constraint application protocol and stuff like that So you should really avoid using something like whatever XML over HTTP or something like that You should really try to avoid that. I mean depends on what you want to do, but it's not a good idea I would say Yeah, so The compression so that's one of the biggest parts here That make it interesting or what what makes it so pen interesting for this kind of networks So we have this 40 bite IP version 6 header, which is quite an impact On the kind of small empty we have so what the people at ITF come up with that They thought about how they can compress it down without even having stayed shared between the network So just stateless compression makes it really Quite good in the first case. So something like the version field We always have version 6 here because that's the only one we support so we can just ignore that one Traffic class and flow level that's something that makes sense in a lot of networks It doesn't make that much sense in in wireless sensor networks So we can set them to zero at that point we can still Try to bring this kind of information back So have some these headers carried in line at some point, but right now that's just doesn't really make that much of sense So hop limit the same you we can just set it to some well known values The payload length fields and that's something we can get from the layer 2 in that case for the data link layer Or the the fragment header in that case, but the the real needs that we are saving here would be on the addresses Because we are reusing the addresses from layer 2 So in tip not for you have either extended or short addresses. So the extended one is already 64 bit and the short one you can Bring into a 48 bit address is just using the network pen ID here and then some zeros and then the short address Which is also 16 bit and from the 48 you can go to an EU 64 bit again Then then you have the address part of the IP version 6 that is The prefix on the other hand that's something that's I saw link local So that is also shared already or there are mechanisms to distribute context is between the network Which helps you to have if you have specific prefixes you always use like a connection to your your data and you serve on the cloud or something then you can just Distribute this kind of prefix to the network or the notes know about it and can reference to a specific context ID in that case And you can delete the this the address again or parts of the prefix or something like that. So in a really optimal Scenario that mean you could reduce it down from 40 to 2 bytes that would be on top of here. So you would have Okay On the right side on the top you can see just a dispatch by it and the the header for the IP header compression That would only be linked local communication So if you would go for a multi-hop scenario in that case You would need part of the address and would need a hop limit or something like that Then you would be something like seven bytes, which is more but still a lot better than the 40 bytes you had to begin this On top of that, I mean you need another protocol on IP most of the time you the piece used here and for you the piece you also have a little bit of Compression methods mechanisms around One of it is something you could use if you design your the applications on the server side on your own You can choose what kind of ports are used So what they are offering is that they are compressing the port range of UDP down to four bits So that would mean you only have 16 ports around that sounds not that much But if you have a really limited scope what the network is running that might be enough So that could shave off. I think like one or two bytes. I think two bytes or something from the UDP header It's something you could do as well It's not really is that recommended to do but you could do is Leading the UDP checks on but you really should only do that if you are making sure that the upper layers are handling all the message integrity And so on if you are if you know that your application protocols doing that handling that already You could make sure that the UDP section is Elated as well so that would save you more more space as well Then there's something that's a bit newer Well, there's not really implementation for that out there. That's generic header compression, which is just an LZ77 style compressing scheme So you have bytecodes for appending zeros So if a message with a lot of zeros in there you can compress it down and then you have a dictionary which is shared between the So 16 bits of that dictionary are Defined in the specification so they're known by all nodes and the other 16 bits are the address of the source on the address of the Destinations so you know all these information they are shared between the nodes and then you have that kind of is your dictionary Which you can back reference to that really makes a lot of sense If you're having upper-level protocols like detail as or ripple which is a routing protocol Because they are referencing in the in the payload of of UDP or in the pedal of IP They're referencing to addresses that are lower and then you can back reference us to a dictionary and then can elite and Compress a lot of things there as well That's something we are still working on implementing. So that's not out there yet. So So WPN tools that are use-based utilities, which is Aiming for configuration from configuring the call networking stack It goes over netlink the netlink interface the ideas of that and some of the code is actually borrowed from the IW utility which is used for 182.11 wireless So because they have kind of the same scopes same problem scope yet some some ideas of them borrowed over I mean use it for configuring your file and your Mac layer The parameters of that would be like channel your network ID What kind of power settings they have for your device what kind of short address how often the transceiver should retry to send frames out that are failed All stuff like that. So we have released version 0.7 for this use-based utilities just two or three weeks ago We have the latest thing we added was namespace support. That's something the kernel just recently gained there Yeah, it's packaged by some distributions really up to date in Fedora and Debian for example It's behind in Ubuntu and I think other distributions are not packaging as well So if you want to make sure that you have the latest version you would have to compile it from source most of the time Another small utility we are shipping with this use-based Disto is WP and ping which is just a really basic ping utility on the 15.4 layer. So that's really below IP in that case It's not a full ICMP replacement, but at least it's helping for doing some basic debugging maybe even some basic measurements so Because it's not the full ICMP thing and we have we can't really run that part in the protocols We need to run a daemon on one one side Just start in daemon mode on one node and the other one with just sending out packets and you give a packet count You give an extended or short address and then you can set the size of the frames and so on then you can yeah The output looks really similar to what you get from IP from ping version 6 So but that helps you to debug the lower layers before going into 6 low-end Okay, so what would you need to actually get your own network running? I mean you obviously have to start with some hardware. I briefly touched on that already So we have mainland drivers for a various admiral transceivers. I think that's like three or four of them by now We have support for a microchip transceiver. We have support for one sensor from TI We have the 80 USB that's a small USB dongle which is basically also an admiral transceiver just a connected over USB with mic controller and we have support for a transceiver from analog devices There's another pending driver for a driver from Cascota Which is used on these CI 40 crater boards. I mentioned before that is I just yesterday got a patch series That I can that I should start getting reviewing So that's something that should get mainline within I would say the next few months or something There's also this kind of XP devices, which are connected over just a serial connector There's a autofree driver for that but It's quite huge and really in a state where we are not going to merge it as is And there's nobody working on that and I don't have the hardware for that So that's really lingering outside. So it's we're not really recommended But as I said, most of these transceivers are really cheap to get I think the microchip one you can get for something like Seven euro or so and the admiral ones are not I mean what I mean there is a complete module Not only the transceivership, but a module which can really hook up to SPI Yeah, and then if you have a board with SPI and jubilee You just set it up and then make sure that the bindings are working correctly And then you should be up and running on the hardware side there Yeah, the speed dongles That's something people are asking for and I hope they are getting to getting a new batch of them produce Can sell them again Yeah, on the binding side As long as your board has support for that as a mainline or in your in your private tree or whatever That should be quite easy to do On the right side you have an example for the admiral transceiver I mean there's not much to say about that you have just a complete compatible part You can set the maximum frequency for SPI you set the SPI register On what GPIOs interrupt comes in what kinds interrupt parent is in that case. It's just a normal GPIO and Then for these transceivers, there are some more GPIO flex You have for example for research sleep Excel trim and so on but not all transceivers have that but the upper part Until interrupt that's quite common. So If you want to start play around with these kind of things without any hardware You could also start with a virtual driver. We are having We have a so-called fake loop back driver Which is very similar to the hardware simulator driver from wireless as well. It's really great for testing We have support in riot or anything is not in riot yet But on the way there a same for open sweat Both of these can run as a native Linux user user process Which means we have support for them This is what we added for our virtual driver They can use as a native process these kind of virtual device and that mean that you can just set up a Virtual network with all kind of devices and all kind of networking stacks of example You see below here if you would not prob the fake loop back driver with four devices I would just show up for network virtual network devices You could configure one for Linux one for riot one for open sweat And the other one would just be a monitor device and then you can test around ping devices Testing different upper-layer protocols make sure that they are working together or not And if it's a monitor device you can always sniff and see what's going on there on the on the packet level So that's something really convenient for for testing and debugging If you want to do that so If you either have your virtual Hardware or your real hardware brought up to a point that it's going to work the WP and interface would just show up show up automatically After that you would need to configure some basic parameters to make sure that all the things are working So in that case you would just bring down The interface set the the pen ID is a network ID and the channel so that are the two basic things you would have to do and as you can see Just normal IP link to set down the link and then it's I WP and to set the fire and Mac parameters after that you would add the extra low-pen interface on top of the WP and zero interface That one is the one that runs the six low-pen stack So you have two interfaces in the end which if you're using that one You would just use a normal 15.4 traffic just normal frames and everything no IP version six involved at all And if you're using the low-pen zero interface that would be a normal IP version six and everything interface You could use and everything below all the fragmentation compression everything you don't have to care about that. That's all handed transparently Yeah, if you are going to set all these kind of things up obviously there will be problems in the beginning And you want to see what's going on so having some kind of monitor Is a good thing You could either run via shark obviously on the WP and zero or low-pen devices That's something you couldn't run on the host But it sometimes makes also makes a lot of sense to sniff really in the air what's going on between two devices to make sure that you're ruling out problems on on the host on the note or whatever In that case you would just delete the auto the interface that comes up automatically and bring up in you on on the in the fire Interface you adding the a monitor type of device Then you're again setting the channel bring up the device and then you can start wire shark shark tcp. Dump Shark whatever you want whatever using there one thing you have to keep in mind So is that there's no automatic channel hopping or something like that? So you would have to do that in the background if you want to scan I mean once you have found the network on But you want to use you can just stay with the channel because it's not hopping around or so But if you want to scan for example around in the room What kind of networks on that channels are available you have to do that in the background? Yeah going from there I mean once you have the basic stuff running on your Linux side you want to communicate I mean you obviously can communicate with other Linux Notes in that case, but that might not be that interesting You might want really want to communicate with a small node running on a battery sitting in the next room Having a temperature sensor or something you want to read that out and on of these kind of device It's more likely that they're running different operating systems. So I'm going here this was riot in Kentucky Defire is quite similar to that. Yeah, make your own judgments there So riot in this case, they call themselves a friendly operating system for the internet of things They are LGPL licensed They're testing against Linux WP and doing the normal release process They have already which is quite nice for us because that makes sure that once they agree going to do a new release They make sure that it's working with us or at least they can contact us. So we're getting the things sorted out That is another thing here. We have quite an active developer relation with them. So for bug fixing and Just discussions about how to interpret that the ITF standards and stuff like that. That's really a good Communication going on there. So that's quite nice Kentucky, yeah, they call open source of open source of those internal things there be still license They're really a really fragmented project, which is quite sad actually. I mean, they're one of the pioneers in this area But they there are a lot of folks around either for academic or commercial purpose and They seldomly got much back. I would say I mean it got better with Kentucky is 3.0 But there's still a lot of things out there that people just I say have hardware support in their own for three or support for different Protocols and stuff like that and then sometimes is never an intention to merge it back So that's really a bad situation if you want to use that for your own things But nonetheless, it's still a really important Operating system this kind of space because a lot of people are using it either for research or for for products So you have to somehow work with that Yeah, just a really quick comparison here Focusing on the parts that are not supported Beacon Mac frame support that's something 15.4 Which none of us is supporting they would be needed if you want to have a way more automatic scenario or For configuring network or deploying your networks that would be sending out beacons frames having met Command frames for something like scanning for networks Joining a network having a pen coin data for example central parts that would hand out short addresses to the nodes and so on So that's something that's not supported in any of these which is Quite bad because one you have to start implementing it and there's nothing you can test again So I mean obviously you can test against yourself, but that most of the time just means you're back completes a Buck compatible Yeah on the linkless security side We support that and contiki support that I'm right certainly has no support for that right now The basic six low pin stuff that's supported by all of us. I mean Something that's also in the works that's I'm for example on the next side I'm working on that as generic header compression But so far there's nothing in mainline or anything like that Then there is some optimization for the neighbor discovery mechanisms and IP version six We have basic support for that on our side There still need to be things to be improved there riot has implementation for that that we are testing against actually Contiki mainline does not have that I think there's some forks somewhere that supports that but I'm not really putting that into the chart here And then there's ripple the rooting protocol which is used quite often this kind of networks Riot has support for that contiki on the link side We don't have any support for that on the on the kernel level But we don't need to because as a user space demon handling all kind of these things for us So yeah, there's something new coming up the mesh link establishment draft from the ITF Which should help a little bit if you want to have your mesh under protocols running this in these networks and make sure that you're setting up your links between the different nodes in the mesh to make sure that the security parameters are exchanged and the network parameters are exchanged and stuff like that So but there's no support for that. I mean there's support for that in open thread and I know that Exxon has looking into that how we can support that on the link side Yeah, there are other Systems here for example, there's the embedded rest from arm, but The thing here is that the networking stack is closed sources. So I completely lost interest in doing any testing on that part I mean that might work good or not. I can't really tell I don't have any hardware for that And I don't really want to invest my time and testing against the closed source decks there Then there's the fire and they're using the contiki stack. I know that they're working on a new networking stick I don't know how far that approach and not follow that too closely, but there should be some sessions around here Which might talk about that a little bit more but as long as it's using the contiki stack that should be fine working there Yeah, and then there's open thread I mentioned that briefly before that's an open source implementation of the thread protocol from the thread group which is also Something we are supporting this in this virtual driver there And could also put that on some device and then you can start some of the communication So the basic stuff is 15 or 4 and 6 low-point should work or the upper level Protocols sweat has in their vertical stack that might be a bit more problematic for example all the security parts they're having We have no support for that. I mean we have support for the link layer nuts and bolts Plumbing layer, but not how they are going to do the key Exchange the key re keying the group keys and stuff like that all of these things are defined in their own specification Sadly the specification itself is not available for for the public So you would have to go with the open source implementation to see what's going on there Yeah, talking about link layer security here Fishman 4 defines that for various things so they have Security streets for confidality integrity encryption authentication. That's all combinations of as I service Mac or CCM stuff like that So all the nuts and bolts I would say are there But all the things on top of that like how you would do key handling how you would exchange keys between the nodes How you would do a rollover and stuff like that that is not defined at all so that they leave that completely to The companies doing in vertical networking stack or they people doing products or stuff like that They're just kind of complicated because I mean what I can do test is something like having a network Why key using between different nodes, but once these key is compromised or something the complete network would be compromised So that's something. Yeah, we have to put more energy into that I don't know. I mean I've seen some papers what you can do in that area, but I don't know of any implementations for that I mean I might miss it or so, but yeah, it's a complicated part. I would say so what I did or what I tested at least was Linux against Contiki 3.0 Yeah, we can test against where because they don't support that right now If you want to do testing on the Linux side You have to jump over a few hurdles right now For example, the user space utility Does the support we have in there is not in a release yet? It's it still sits in a sec branch right now because we are not satisfied with the User interface you have for the command line. I mean you can see that below here All the scripted things you have to put in there are really hard to get right and So we really want to revamp the user interface or the command line interface before we are putting that in a release and On the corner side you would to enable the net link 504 experimental Config option because without that we would wouldn't run the security part either But if you jumped over this holds You could set up the just said security enabled and then you would see key in that guy Part for for the specific extended address and the pen ID So what you can do is like having Dedicated keys for different nodes for receiving transmitting and so on so you have all the mechanisms in there But it makes it also complicated to get it all right to make sure that all the nodes can communicate Yeah, then you're setting your your security level And adding the device in that case so that would be just handing the receiving site on the Linux on the next site here If you go for for contiki now You would define some things in your project confeder file Which basically means it's hard coded and it's compiled into the binary blob You're flushing on device and you're not having any way of configuring that or changes that on the runtime So at least as far as I have seen on the contiki side There's no way to do that runtime or getting because they're also missing any protocols to getting information for rekeying Or so with a network There's no way to make that more flexible right now, which is quite sad. So it doesn't really has such Good impact as we hope normally. So yeah, you would just go setting the security level and Then you would just say set the key here in here That would be a network right key in that case which is shared between all the devices Okay So wrapping up here with the look at the routing protocols that are available That is mostly I saw mesh under route over. So that's the distinction That is normally done this kind of wireless Sensor networks mesh under really sounds really good in the beginning. So the idea is to just forward the packets On the layer below the IP stack. So you don't have to travel the whole IP stack. You can save Cycles there On the other hand 504 has no No support or no specification for for mesh networking in the Mac layer so that means the mesh implementation would sit on top of the Mac and not inside it and You have to put it in there. I mean there are implementations for that I think there's wireless heart and then there's either 100 a or something like that So they have limitation for that so that it's working But it's more complicated than it should be Six open just has support for that in terms of that. It has a Mesh header that you can just append for every frame you're sending For that kind of things on the long side. We don't have any support for that If you're getting this kind of mesh error, we are just printing out a warning in Dmask And that's all because we don't have any support right now It might also cause trouble if you're going with bigger packets and losing fragments and stuff like that because you Don't know that you lost a fragment and you're still Happily forwarding all of these of kind of things because you don't travel the IPsec So you don't know that there was something missing in between It might get better. I mean there's there's these mesh link establishment Draft which could help in that area is obviously not defining how a mesh but just parts of it Yeah, but that's something right now. We have no No support for that. I mean we are not opposed it or something is just that there was no need or no interest I would say what we are mostly going this is ripple Most of the time we do that because it's it's implemented in contiki and riot. So it's already there. It's a well defined It's an over protocol And on the long side, we don't really have to care that much about it because there's someone else working on the user space reference implementations for that and the thing we have Need to make sure is that we are giving him all the information from the stacks that he might need to know I mean for example does how good is the link quality to the neighboring note and stuff like that There also have been some ripple patches for an entry an internal Protocol implementation. I've seen them. I think one or two years ago I think by now they're a bit rotted and there's and I've seen no intent or so bringing that forward and We are certainly not aiming for that right now I mean if anyone wants to pick up on that might be a good idea But you really have to battle with the it's networking people directly on that. That's nothing we can we can help you with Yeah, a little bit outlook of the future what we need to do I mean as mentioned that the beacon Mac frame part that is still missing completely That would really help you if you want to make it a bit more automatic to bring notes onto the network Making sure that they are scanning for a network what's available and then trying to join them getting the address from the coordinator And from that point on maybe getting information about network settings and security settings and stuff like that But as I said that's missing right now Also something like having a coordinator running on the link side user space might be a good idea Especially if you're the border root of this kind of networks and your main part That means that you are most likely up and running while other parts of the network might be running out of battery Right now are being not because being mobile and being not around or something like that Yeah The existing drivers you might need to improve them right now. That's quite good Adding new hardware support. That's I mean most of these transceivers are I mean not many of them showing up normally So that's quite quite a good coverage right now We need to keep working on the neighbor discovery optimizations stuff. We have there is not finished yet But at least we started on it For the open thread part. We just started Evaluating how we can run that on the link side. So right now as I said that would be running on top of these virtual driver But that basically means that open thread would still use their own 15.04 and six open implementation and We would really like if they run on the link side We would really like them to use our stack on that part So that would mean we need to find a better abstraction Point where they would start using our stack or not, but that's still something to evaluate For the header compression modules, we really need them Configuration to face all that because right now they are just modules and you either load them or unload them and then that means the compression scheme is either available or not. So there's nothing like Just enable it for this node for receiving from the other node for transmitting or just Disable it for this note and stuff like that. So that's all completely missing right now. Sadly Yeah, and we might need expose more information what we have inside the stack to user space But we are just doing that step by step and there's really a need for that because once we are doing that They are fixed in the user space API and we don't really want to expose too much information there that we don't need So what would be summary here to you should take home Doing this kind of 15.4 wireless networks on our Linux is really not hard We have the basic support for that in the kernel We have the basic tooling getting the hardware up and running should be really easy for people doing embedded And with something like the USB dongle should be even easier The most likely scenario that would come back to you would be in a if you have like an exo point platform Or something like that or just a device that's it's used in Automation on appliance where you have like a wireless interface or net or an ethernet interface And you would just add another interface that would mean you kind of act like a border router in this scenario You could it could also be just a normal router or just a normal note in this kind of networks But if you're running Linux, you're mostly beefy enough to also have something like Wi-Fi or so on board So that means you're more likely in the router case Yeah, so thank you that would be from my side and I would be open for questions now questions Really hard actually The problem there is It's a networking stock So that means you would get the the firmware on the MCU on that part Which means I don't know how the status is Right now, but last time I checked you needed an external a flesh up for that So that means you couldn't load that from the just for them from the main CPU or something loads a firmware And that was not possible So you really needed an external flesh up to flesh that in and then you would have like a user space component on the link side communicating with that and For my side, but I would like to see there's a really tiny Firmware that just gets all the access over to the link side so we have can run the native site on the Linux But there's nothing like that what I've seen so far the firmware images are like for a full Zigbee stack and maybe some some other things so then you would have a Serial interface to this kind and then you're configuring that but the whole network instead would be offloaded at that point So that's quite a common scenario for this kind of devices and Yeah, it's not really easy to get that up and running after say sadly There is a documentation for that on the on the Arctic back side But as I said you need an hardware flasher and you might need extra software So I just I looked at it briefly and I just thought they are that's too much trouble for me right now The Arctic one as far as I know only has Bluetooth support and not 15.04 so That means that you would do run something like a six open of a Bluetooth that would be something but There would be no Linux support for the Arctic one. So that would be a real time operating system So that would be again something like whatever the fire not a x y at Kentucky something like that But you could you from there you can go with just Bluetooth six low-pan and yeah from there You would on the link side that would be a Bluetooth interface obviously, but then you can do IP on top of that More questions No, for example on the long side easy the as stuff is something we do in the colonel So that's nothing we offload to the transceivers the transceivers offer that but that's mostly because they're designed for As a company in component to something like an MCU which just has a problem doing all the ace Encryption there and so you don't have to do that on the long side At the moment, we are not using SSI that much or ED values and stuff like that, but it should be recommended to have So so but if you want to do your own transceiver You could start with really something simple and then could still use that right now that there's for example and So for different radio implementations for that So that's could be something you can just start and have your own transceiver You can start really simple I would say right now. We are not using this kind of information, but it might be It might be needed at some later point if you're exposing this kind of information to the routing protocols for example So like like what kind of link quality do you have to a next note or something at that point? It might be mandatory that we are getting this kind of information out of the out of the transceiver Not not the moment not now All right Yes, the thing is that what we are doing is we either we have support for the automatic egg handling in the hardware For example, that's a flag you just set in your driver And you want to to propagate this kind of formation up about the stack for something. Yes Yeah, now we should do that. I agree that the problem We're not having that right now But that's another part of the information that make sure that we see how reliable a link is to another note And that's something actually the people from from answer on the ripple user space inflation requested us to gift to them It's just for us It's more the problem how to define a good user space API for giving that out But we have to propagate it to the whole stack before that you're right on that so we at the moment We're ignoring that and that's bad. That's a good point. Yeah Good Some people do but I mean obviously it's a promise you're going with a handshake and everything that might be a problem Most of these things I now use UDP and then use something else on top of that So, I mean as a UDP this this co-op for example is something like the ITF is really promoting I've seen LW to M also, I don't know what the exact abbreviation is there I've seen that running on these kind of networks and I've also seen MQTT running there But yeah, I would see I would think UDP is not really giving you a good benefit for not that much waste of Header space and if you use something like co-op on top of that that would be I mean for the people don't know that co-op is some sort of Slimmed-down HTTP version where you just have a binary representation of most of these things So you are saving a lot of space there because you're not having a text protocol but you still have some of the Mechanisms and and schemes you are used to this HTTP. So that's something a lot of people are using that area Yeah, if it's really fits your needs or not, that's really depends a lot I mean and it also depends if you have a lot of device device communication going on if it's more device to cloud That's really depending on what kind of stuff you want to use More questions Yeah Myself I don't have that. I know that people are running it on Bluetooth. So muscle Hoffman sitting there behind there They're running it on Bluetooth. For example, muscle Hoffman is sitting behind there. He's doing that a lot And for example, they're doing that that in combination with the Zafia project There are people running it on top of Things like NFC which is sounds a bit crazy to me, but they're doing that I mean don't know really what use cases are and for example power lines also something They're using it a lot for for Laura It might be a good idea, but Laura's really really tiny on the pilot side. So you might want to have completely different compression Schemes there as well. I've seen one talk about it at some point and they had a lot more state between the different devices So they could even shape even bring down these bites you're transmitting because you have a lot more state So that I would say six opens not really fitting that good for that bill because I think what is it like tens of bytes or something? You can only transmit Okay, so I'm over time I mean we have lunch time right now so you can just go ahead