 Good morning. I'm going to talk today about a new specification put out by the Wi-Fi Alliance called EasyMesh and the effort I've been doing to make an open source implementation of that. Most of my time, oh, this is slow. Oh, shit, I pushed the wrong button. Sorry. So most of my time, I'm also actually going to spend to explain what this new specification is and why it exists, what the problem is and what the specification is about. Then I will explain why I'm doing this work, which is sponsored by Purple and what kind of architecture we envision. I'm also with a little bit of trepidation going to talk about security and finally about missing features, which hopefully will be implemented in the second revision of the specification. So the problem that Wi-Fi Alliance wants to deal with is when you have multiple access points in the house, when you have a single access point, it's easy. It has an SID and you connect to it and typically that's the gateway that's given to you by your, well, for you probably not, but for the normal home user, typically it's the gateway that is given to them by the carrier, the telecom operator. But of course, you don't get enough coverage, so you need multiple access points in your house. So you add another access point, but it's a bit complex to set that up. You need, well, ideally you should give both of them the same SSID so that when you have a device, it will automatically select one of the two access points, the one that is in reach. And of course, if you add more access points to get full coverage, this complexity only increases. So there is setup complexity, but it's not only that. Another issue is that of interference. If you have multiple access points and they're using the same channel, yeah, they're going to conflict with each other. And there is a bit of automatic channel selection that is done in access points, but sometimes you have two access points like this one and this one. They don't actually see each other, but anybody who is in the middle will still get interference from those two access points. So automatic channel selection does not work perfectly. And another issue is that the access points are used suboptimally. If you have, well, usually you have a lot of devices, a lot of Wi-Fi devices in the house, and all of them are smart enough to, when you have, when they see multiple access points with the same SSID, they will select the best one, the strongest one. Now, if you have devices which are concentrated in the same area, which is often the case, they all see the same access point as the strongest one. And the net effect is that all of them connect to the same access point, and these other access points, they go unused. So you have unused bandwidth in the air. So Wi-Fi certified EasyMesh is a way to deal with all that. So the idea is that the setup is easy, that you can add access points to your house, just push a button and they connect to each other. And also that they will automatically manage how different devices connect to the different access points. So it's the, the branding here is a bit complicated. The Wi-Fi Alliance, they make, well, originally they only did certification. Nowadays, they make specifications as well for new standards, industry standards. But then there's also always the specification, which is a certain name in this case. It's the Wi-Fi Alliance, oh, sorry. The Wi-Fi Alliance multi-access point or multi-AP specification. And then, so you have this specification. You make an implementation of that specification. It is put in some products and then in the end, the Wi-Fi Alliance gives you a certification so you can use the brands. That's why there is always a TM here because it's a brand name. You can use the brand EasyMesh to sell your product. And that's how Wi-Fi Alliance makes their money. They charge money for this certification and that's how they get an income, which hopefully they spent on developing better standards. So what we will be doing is only the multi-AP implementation parts, which allows vendors, product developers, to develop products more easily and where they know that it will be really easy to get this certification. Something similar is also happening in Bluetooth, for example, where you also have to go through such a certification process. So a little bit of insight in how this Wi-Fi multi-AP standard works. It is based on an existing IEEE standard 95.1, which I had before this never heard about. It's something that is used to allow different routers or bridges in a network, in a wired network, typically, to discover each other, to discover the topology, which can then be used to optimize the usage of the network. So it's a bit like an STP on steroids to discover how to route your packets. So what does this 95.1 thing look like? It's a purely L2 protocol, so there's no IP involved. It has a specific error type. It is number. And then it uses either a unicost L2 address or a multicost L2 address, so this 48-bit internet addresses. So to do the discovery, it will use multicost, and then the routers, the bridges, which are 95.1 enabled, they will capture this multicost and only forward it in certain situations. So that allows you to do the discovery in a controlled way. And once you discover which devices are available in the network, you use normal unicost Ethernet frames to go to that device, but it's using instead of the normal MAC address of an interface, it will use a special AL MAC address. For a bridge, it doesn't matter what this address is, it will just look at an address, it knows, ah, on that port, I have, I've seen that address before, so I send it to that port. And in case it's an unknown address, it will flood it, so this just works out of the box. And then all the packets that are used in this protocol, they use this kind of layout, so there is a, the packets are called CMD use for command units. So they have a header, as always, with a version and a message ID, and then they have TLVs, type, length, value elements. So it's always a one-byte type, then a two-byte length, and then a value, which is of varying length. And the different, so the message ID is the, sorry, the CMDU type is a type. Each type has a specific set of TLVs that is associated with it, and there's some catering for extensions for unknown TLVs and unknown CMD use, so it's specified how to deal with those, which is why it's easy for the multi-AP specification to reuse this protocol because they can, they can just add CMD use and they can add TLVs. And if there is some existing 1905.1 device in the network, it will correctly deal with that because it's all extensible. And then the other thing it has is this message ID, which is used for dealing with retransmissions and for lost packets, so it's, it's like a sequence number, and it also has possibilities for fragmentation. Some of these messages can be really large, larger than the MTU, and then they can be fragmented and collected together again. So the, what is, what the multi-AP standards reuses from the 1905 is mostly the topology discovery, so sending out packets in the network to see which other devices are in the network. And also the 1905.1 standard already has an onboarding concept. So they have had the concept of a push button configuration similar like WPS and actually reusing the same frames as WPS. So when you have two 1905.1 devices in the network and you push a button on both, they will start sending a specific type of message broadcast or multicasting them. And then the, the, that allows them to set up a secure connection just like you do WPS on an access point. So what it, what the multi-AP specification adds is a lot of new command units and TLVs. Actually, there are more in the multi-AP standards than that there are in the original 1905.1 standards. It also extended this onboarding procedure. So the, the new onboarding procedure, well, I'll come back to that. It's mainly to set up a, a wireless link between two access points. The 1905.1 standard assumes that access points were connected with a wire or, or devices which are onboarded are connected with a wire. The multi-AP specification allows it to be wireless. And then the, the core of the extensions is a collection of capabilities and metrics. So the capabilities are things like, does this access point support 5 GHz networks? Does it support in 5 GHz, 80 MHz bandwidth? Does it, does it need radar detection? Things like that. And then the metric collection is about which beacons do you see? So which other access points does that particular access point see? Which stations are connected to it? What kind of speeds do these stations get? What kind of RSSI do they get? So how strong is a signal? And all of that gets sent to a central device which is called the controller. And all the other devices, all the other access points are called agents. And so this controller based on that capability in metric information can make some decision, a global decision for the entire network. And then it sends back control frames for configuration, so which SSIDs should be enabled on the access point. Channel selection, so in which channel they should be, make sure that they're not interfering with each other. And also steering, meaning telling a specific client to connect to a specific access point. So a bit more details of how this works. So the discovery procedure allows the agents and the controller to discover each other. Usually the controller is going to be on a gateway, but this is not specified. So the controller can be anything. It can be a PC even. It doesn't even need to be an access point itself. But so the way that the carriers see it is that the controller is always going to be their gateway. And then the access points are, all access points are agents. Also the device which is the controller can also be an agent. So it will also be controlled by the same controller, obviously. In principle, there should be no additional information needed between these two. So there should not be any reason to have the controller on the same device, on an access point itself. So once they have discovered each other, the controller will ask all the agents for their metrics. It will ask all the agents for the configuration, for the capabilities. So then the agents start collecting metrics and these are sent autonomously to the controller. So the controller says, I want metrics every 10 seconds, for instance. And then the agent sends those metrics every 10 seconds. It should be a bit more than 10 seconds. And then based on that, the controller can take decisions. And for example, it can say to this access point, okay, this station was connected to you, send it a message that it should no longer connect to you, but it should instead connect to this access point. There is a Wi-Fi standard for allowing that. It's called CAC. I have no idea what it stands for. Not all devices support that. So if the device does not support it, there is an alternative and it's just blacklisting. So this access point will no longer accept a connection from that device. So that device basically sees I can't connect anymore to the network. And normally that device will then look for another access point with the same SSID and connect to that one instead. So normally it should work and it should find this access point and connect to that. Worst case, your device is disconnected, which is not so nice, but yeah. Price you have to pay. A more complicated thing is the onboarding procedure. So assuming that the devices are already connected, for example, with a wire, then the new agent, so this is a new agent that is connected to the network, it will send out a search message, which is broadcasted all over the network. And then the controller will reply to that and send a reply to it to say, okay, I'm the controller. Implication of that is obviously that you can have only a single controller in your entire network. There is no support for multiple controllers. There's not even any support for electing a controller. So if all these devices, if all access points would also have controller functionality, the system doesn't work. It's a bit like DGP. You can have only one DGP server in the network. So the controller sends a response. That's a unicast message. So the response goes straight to the correct agent. And from then on there is a, well, they know about each other. So the agents will know, okay, I can accept commands from this particular controller. And the controller knows that's one agent in the network that I have to control. Now if you don't have a wired connection, but you have a wireless connection, you need to set that up as well. And so for that, there is an, yeah. For making the wireless connection, there is a normal WPS procedure between them. So you push a button on one access point and you push a button on the new access point, which has to be in view of the other access points that you push the button on. The existing access point will start broadcasting beacons which have the WPS bit sets. And they also have these beacon messages have an additional element saying that it supports the multi-AP specification. And then the new agent, it waits for that kind of beacon message with the WPS indication. And if this beacon message has the multi-AP element, it will make, establish a backhaul link as it is called. So a backhaul link is a link where this one acts as the client, as a station. This one acts as the, as access point as usual. But the client is going to use that link for, as it's one site of the network, as it's white area network site of the network. And it's also going to use that link for the multi-AP communication. So once that is done, you just have a connection between those two agents. You don't have a connection to the controller yet. So then comes the, the controller discovery procedure. And once the controller has been discovered, the new agent is going to send an WSC, which is the, the protocol underlying WPS is going to send a WSC message to the controller. And the controller sends back a WSC message to the agent. So you get the same kind of protocol as you have for WPS. You get a second time, but now between the agent and the controller, which can't actually see each other directly. So it's, it's routed over, over this network. You get an interaction between the agent and the controller, and that interaction is then set up, used to set up the, the SSIDs on the agent. So which, for each radio that it has, which SSID should configure to it. And normally that would be the same SSID as all the other access points in the network have. But actually the controller can choose to give every access point a different SSID. So that is the, the 10-minute overview of the multi-AP standards. So the Wi-Fi Alliance developed this standard, approved it, I think, in March this year. And then, of course, chip vendors want to start implementing this multi-AP standard. So Broadcom, Intel, Contenna, Qualcomm, all these chip vendors, they, they want to sell chips that have this, that are enabled for this standard. And then OMS, so the, the companies that develop the, the, not really the, the routers, but the, the boards which are put in routers, they want to, to use the multi-AP standards, but they want to be able to use different chips from different vendors without having to swap out the software. This happened already with HostAPD. So in, in the past, every chip vendor would, instead of using the existing CFG A2211 infrastructure in your kernel, or extending the existing infrastructure, they would have their, their own way of setting up and their, their chips, because they have all kinds of extensions that they want to be able to use. And that meant that they also need a fork of HostAPD. So it makes it very difficult for the, the product developers to use different radios in their devices, because they anyway, every time have to install different software almost, which is annoying. So the, the product developers, they want to use the same thing without having to change their software all the time. And the carriers, they want two things. They want the interoperability, so they want that if they have one device coming from one OM vendor and another device coming from another OM vendor, that they actually work together. And they want manageability. The interoperability that is satisfied because now there is a standard. So before that, there already existed this kind of implementations, but then for a specific vendor. So you have to have that specific vendor to be able to use it. And all the devices in the network have to be from that specific vendor. With this Wi-Fi certified standard, we can have some interoperability. Interoperability. And then the manageability, that's something I don't fully understand myself, but the carriers, what they basically want is that they own all the devices which are in your house and that they can control everything. And if you put in some other device, that they can still control it. That's basically the way I read it. I think the reason that they want that is because when there's something wrong with your network, probably not your network, but the normal person's network, they're going to call the help desk of the carrier because that's the one that's providing the internet and the internet is not working. And then the carrier somehow has to solve it. So what they want is that they want to have some insight in what is happening in that network. And so then comes in the Purple Foundation. The Purple Foundation, it says a bit of a weird history. It actually started out as a foundation for developing MIPS, MIPS processors or software for MIPS, a bit like Linairo for ARM. But it evolved into a foundation for open source community-driven development for routers, for anything which is related to the network, the edge network, so in homes and in small businesses. And nowadays it's actually mostly oriented towards carriers, but it in principle also caters towards like links is normal router vendors. And so the Purple Foundation works on mainly standards and API, so making sure that different routers and different pieces of software in routers use the same kind of interfaces so that you can easily combine things together. And then you see a lot of companies that are members of the Purple Foundation ranging from carriers like Vodafone, chip vendors like Intel, I don't see it now, but Intel is a member here. And software vendors like Soft at Home and OMS so making the devices like Technicolor. And how does the Purple Foundation achieve this interoperability and so on. That's by making APIs and so the high-level architecture that is being developed basically by Purple Foundation consists of a high-level API in a low-level API. The low-level API is basically telling, for example, telling chip vendors you have to use CFG A2211 and then the OMS that you buy those chips they also tell the chip vendors you have to use A2211 and that's the way to convince those people that they should use A2211, CFG A2211. So the low-level API is basically standardizing how you talk to drivers or how you talk to hardware. The high-level API is a single way to manage the device so that's the manageability aspect that the carriers want. That's the way that you can get information about the device. The way that you can get that you can control the device is unified and so that the carriers can develop one web UI and use the same web UI on different devices because it uses the same API to talk to the device itself. And so in between is the stuff that actually makes things work. So things like configuration of access points, things like firewalling, things like multicast demons and forwarding multicast streams. And so their purple is also I think my project is the only one where it's actually doing software development but helping with the software development of that. So that's how we arrive at this purple mesh implementation. So the idea was in this context of this high-level API in the low-level API and the services which are in between in the push from chip vendors and OMS and carriers to have an open-source implementation of the multi-AP specification. The idea was to make an open-source reference implementation of this multi-AP implementation which is ready to be Wi-Fi certified. So the idea is not to actually get the label from Wi-Fi Alliance but to make it easy for open vendors to actually get that label. And concentrating on the agent. So the idea is that the controller which is actually making decisions which has the intelligence that that one is left as a differentiator so that different vendors can sell their controller and compete on that. Probably at some point in a faraway future there will also be conversions on the controller but for now the idea is that that's the differentiator. And of course it is something that should match with purple APIs and add carrier manageability which basically means it should be possible for the controller to not even be in your network in your gateway but be somewhere in the cloud and controlled by the carrier. The whole thing is anyway going to be controlled by the carrier so it doesn't make much of a difference. And so of course then somebody had to do it because the purple foundation does not employ any developers they only have they only do management and so they contracted Ascension and me to do this implementation. So yeah as I said before the path to implementation is that you have purple mesh which can then be integrated into one product by a vendor and because we know that this is certifiable it's going to be easy to get the certified label. There is also an involvement of the broadband forum so the basically this came to be because the broadband forum has already an implementation of the 1905.1 stack which is publicly available in Apache 2.0 license so you can find it here. So we started a relationship with the broadband forum and they also have a working group on multi-AP. The broadband forum is mostly concentrated on doing things well adding things to it for enabling carrier management like QoS. QoS is the idea that you're using this Wi-Fi to stream TV to digital TV and of course you want your TV to always work even if somebody is downloading something big. So the Wi-Fi access points should have a quality of service setup so that the TV can have priority over the bulk traffic or traffic. And then also metrics acquisition but on a bit higher level to so that the carrier can have an idea of the state of the network. And also they will do test plans so the certification the Wi-Fi line certification that's a bunch of test plans but broadband forum is going to have additional tests to test the carrier grade aspects to test that it is stable. Up to now I have not been involved very much with what happens at the broadband forum site. So the architecture of the purple mesh demon is going to be like this so the central thing is data model which basically models what the access well the capabilities of the access points the metrics and is able to send this information over the network and then you have the 1905 or multi AP stack that actually communicates over the network and then you have two pieces on the bottom platform integration in drivers. So yeah I'll start with the data model the data model looks a bit like this so the for agent this is the only the left hand side is the only thing which is relevant so you have a local device or if that's the only device it's not really important. We have a number of radios typically a 2.4 gigahertz and a 5 gigahertz radio and on each radio you have access points or backhaul links so station links with SSIDs and so on and so then the metrics and so on our children of this for the controller model you basically have this repeated for multiple devices so also for remote devices but the idea is that you have the same data model for local devices and remote devices so that you can operate easily. Now purple mesh is going to work just with CFG 8211 in upstream host step D well or patched upstream host step D because some patches are needed to make multi AP work but we do want vendors to be able to extend it in a way that they can support their specific hardware which is not CFG 211 enabled yet so to make that possible there will be callbacks on every structure instead of having a fixed way to configure a radio there will be a callback which is set up per radio to do specific things and by replacing that callback with something else the vendor can have their own implementation which I'm not going to do but they can do it and we can use the same mechanism also for remote devices in the controller so if the same callback also exists for remote radios and then the implementation of that is messages which go over 1905.1 I forgot to see until what at what time does my talk end okay they're now going to skip over how this works with OpenWRT so the OpenWRT is the way to show it in an entire environment this will be based on OpenWRT that will be my demo platform but the idea is also that it can be integrated in other platforms as well many OMS have their own integration platform fortunately many also use OpenWRT security I'm going to be very brief on it's not okay but hopefully this will be fixed in a future release although I don't trust it very much so some features which are missing are now it's all seen as one flat network there's no way to specify how you have to do firewalls or VLANs or whatever there's no quality of service there's no end-to-end authentication so there's the thing missing in the security aspect it's all just plain text going over the network and you can have only one controller on the network the second release is supposed to fix all that so I'll go in a little more detail about multiple bridges in a typical router you will have multiple bridges so you have your your LAN bridge so the LAN network and then you have a not that white area network but in on the LAN side you also have a few other bridges like a guest network which is an open Wi-Fi or a DMZ which is password protected Wi-Fi but which is more heavily firewalled so that's one device in the DMZ cannot talk to another one so the multi-AP standard has nothing to deal with this and that's one of the extensions that I hope will be coming in the second release so the with this multi-AP it should be possible to have for normal users to make it easier to set up Wi-Fi networks with multiple access points in their home I'm making an open source implementation of it but I'm actually hoping nobody will use it as it is now because of the security aspects which make it not very trustable but hopefully that will be fixed in the second release there is time for questions a little bit yeah but hang on I'll hand out the microphone for the video when will the second release be due I don't know the easy answer is I don't know they are so recently the starting to work on the second release has been approved by the Wi-Fi Alliance but when that then will actually happen I don't know I guess somewhere next year I'm mainly wondering about channel differentiation between the different APs so that they don't distribute distribute with multiple clients the what differentiation so if they're all running on the same channel and everybody's broadcasting on the same channel then you get interference from each other so I wonder if there would be or if there is a channel differentiation so that different APs can run on different channels yeah so the whole idea is that the controller because it knows the different APs and their capabilities and which channels they can operate on it will select for each AP a channel which does not interfere with another one and so they are better than commercial OEMs well there is actually air ties is a commercial system that exists that does the same thing is the source code for the current version already available yeah it's on jithub under the purple foundation group purple mission okay thank you I should have mentioned that and so the the repository is actually a fork of the broadband forum 1905.1 repository but which is so heavily refactored it's not recognizable anymore and it's very much still a working progress so I was hoping to have something demonstratable by today but unfortunately I understand that from different sort of organizational backgrounds but maybe you could compare purple or the wifi mesh with the batman spec if you are this is a mesh networking from the german fryfunk yeah I'm not happy with the name easy mesh or purple mesh because it's not actually really a mesh network so when you say wifi mesh isn't something that exists already for a while to allow stations to connect with each other and to discover connections between them unfortunately it never really took off it doesn't really work in different implementations don't actually work together very well so that's I think why the wifi line sets let's do something new which is completely different and give it the same name but so basically the main difference is that easy mesh is centrally controlled which makes it much simpler to set up in a way because you when once you have discovered controller you're just slave and you just have to execute and the controller sees everything and can make all the decisions and I believe batman is like wifi mesh but then working it's decentralized it's you have this covers system I'm not familiar so also yeah I should show this nice picture with the different hops that's something which is also lacking in the current standard it is actually possible for the controller to so the basically the how things are connected is initially defined by how you happen to have your push button configuration on it is possible for the controller to re reorganize that afterwards but it's not really the main thing so it's kind of assuming that you start with I mean it's it's section 21 or something in the specification of 23 sections so it looks a bit like an afterthought I think we're running out of time so thank you for your attention