Hello, everyone, and welcome to my presentation.
I am Frédéric van Boogert.
I work for a company called Mind, and I'm here to present to you the PurpleMesh project,
which is an open source Wi-Fi mesh solution.
So who am I?
Like I said, I'm an embedded software developer, and I work for Mind.
And since 2020, I've been a project manager for this PurpleMesh project at the Purple Foundation.
And feel free to email me if you want after presentation, if you have any more questions
afterwards.
So what is the Purple Foundation?
So the Purple Foundation is really a very big conglomeration of the Telcoms industry.
So if you look at the logos that I have there, there are a lot of ISPs in there, like AT&T,
like Deutsche Telekom, like Dish, like Verizon, Vodafone.
So there's a lot of big ISPs in Purple Foundation, and also some hardware manufacturers
like ASCII, MediaTek, MaxDineur, Calm.
And so basically what we do is we sponsor the development of router firmware.
So how this came about is essentially operators, they want to provide their users, so with
operators, I mean internet service providers, they want to provide their users with access
points and routers, because not everyone can go out and buy them and configure them themselves.
But all of the software development is not really their core expertise.
So traditionally, they've relied on stacks developed by hardware, their hardware partners,
but they also, this is not their core expertise, and so Purple Foundation was kind of created
to collaborate on this with various partners.
So the main projects that we're working on are Purple OS, which is a router firmware based
on OpenWRT, Purple Mesh, which is a subject of this presentation, and also noteworthy
is Lifecycle Management, which is kind of an attempt to create an up-store infrastructure,
which is really cool actually.
And we are also heavily involved in talking about router security and router data models,
so basically the API of a router.
So that's kind of the overview of the Purple Foundation.
So Purple Mesh itself is an IEEE 1905 stack, so this is a layer 2.5 protocol.
So it sits on top of Wi-Fi and Ethernet, but below IP.
And the stack itself is based on open-sourced Intel codes.
So we are a fully functional easy mesh implementation with both agent and controller roles supported,
and I will talk later about what that means.
And we have extensive API centralization effort as well in collaboration with the Broadband
Forum, so we don't just want to write an API, we want to really think about it, and so we
are collaborating on that with other industry fora.
And we also have a very heavy emphasis on testing.
So we have some Wi-Fi Alliance testbeds that we extensively test with.
So I said Purple Mesh is an easy mesh implementation, so what do I mean by that?
So this is the easy mesh protocol.
It's Wi-Fi Alliance standards, just as Wi-Fi 6 and Wi-Fi 7 are Wi-Fi Alliance standards.
And this is all meant to simplify your Wi-Fi management.
So for Wi-Fi, often the problem that we have is you want to add an X point to your network.
So you want to add an X point to your network, but then you need to configure it, and then
it needs to, and that can be quite tedious.
So the easy mesh protocol can do that for you, so you just onboard new devices using
WPS pairing, which is also extended by the easy mesh standards, and the device will automatically
join your network and have all of your settings, including passphrases and the bands it needs
to operate on, the SSIDs, any guest networks that you have configured and so on.
Another thing that the easy mesh standard does is it shares the configuration, so if
you want to change that configuration, if you want to add SSIDs, if you want to add guest
networks or change any other part of your Wi-Fi configuration, you only need to do that
in one place, and it's applied to all of your X points in your entire network.
And finally also, it gathers a lot of metrics about your network, which can be used to optimize
how devices connect to your network.
So in the image there, you see various X points, and you also see various network devices,
and so what can often happen is that an X point that is used in your network simply gets
overloaded because all of the devices try to connect to that X point, and your other
X points don't see any use, and especially if you have a precarious backhaul that can
lead to some performance problems.
So applications that uses easy mesh standards, they can monitor this, they can see that there
is a problem, and they can try to steer these devices to use different X points.
Just solving performance problems in your network.
So purple mesh is an easy mesh implementation.
So basically we implement all of the functionality that I've just described.
It is portable to a number of different router operating systems, all based on Linux.
So OpenWRT, PurpleOS, and RDKB in particular, it's also portable in theory to other Linux-based
operating systems.
The main dependency that we have is we rely on all softwares, like UBUS or ARBUS is typically
used in these router operating systems, but we could also support something like DBUS for
other platforms.
The main problem that we encounter when trying to port purple mesh to new platforms is we
need really good Wi-Fi drivers because something like mesh networking tests your Wi-Fi drivers
like nothing else, and we find that most Wi-Fi drivers simply are not good enough to support
all the functionality that we need.
So that is one thing that we are also active in purple is we try to spur innovation in
the Wi-Fi drivers.
So we collaborate or we try to collaborate with hardware vendors to make sure that their
drivers are not just capable enough to support mesh, but that this is also done in their
open source drivers.
So we do still support some proprietary drivers for some hardware, but this is very much transitional,
and we hope to get various vendors to open source their wireless drivers and make sure
that all the functionality that we need is supported by those open drivers based on config
802.11 and 802.11.
And so yeah, why did we develop purple mesh?
So basically, like I mentioned, purple is a whole community of different service providers
coming together to develop a single solution.
So instead of everyone having to develop their own software, it makes sense to collaborate.
Also by developing the software ourselves, the service providers, they get independence
from system chip vendors.
So what we've seen in the past and what we still sometimes see is that there are SOC
vendors that try to force you to use their own proprietary software and to depend on their
proprietary interfaces, and that creates a vendor lock-in within the ecosystem, and that
is something that we are very much aware of and are trying to combat as well.
And another good reason to develop purple mesh, and in fact the original reason, is
as a stress test for the wireless drivers, because like I mentioned, Wi-Fi mesh, it taxes
your Wi-Fi drivers in ways that nothing else does, and that was kind of the original motivation
of purple mesh was to act as a test for open source Wi-Fi drivers, but it kind of ballooned
from there.
And one other thing that we do is try to encourage the development of a common API for easy mesh
implementations.
This API is usable for remote management, for network diagnostics, and to enable others
to create router apps to configure Wi-Fi, so they can plug into purple mesh and use
it to smartly configure your own Wi-Fi.
This also is enabled by the LCM project, which allows you to add router apps to your router,
and some of those might use purple mesh to optimize your network, or to show you more
information about your network.
So let me check the time here, we do have time.
Okay, so yeah, easy mesh itself, like I mentioned, it's based on IEEE 905.
This is a very extensible protocol on top of Ethernet and Wi-Fi.
So it uses a fixed multicast address, and the main feature of it is it works with TLV,
so type length value tuples, and you can add as many of these as you like, and the way
easy mesh works is it defines a set of TLVs that have a specific use.
So for instance, TLVs to configure access points, or to report certain metrics, or to
discover devices on the network, things like that.
So yeah, one thing that easy mesh uses, so one thing that easy mesh can also be used
for is discovery of devices on the network.
So all IEEE 905 devices, they can report all of their neighboring devices in the network,
and that helps you get the topology map of all the devices that are present in your network.
So it's easy to discover what's currently living in your network.
So this is also, of course, a vital tool to allow you to optimize the network, and one
other thing that we get is metrics, like I mentioned, so you can see how well the connection
is between various devices that you might have in your network, like your laptops and
your smart phones and your smart TVs, how well is the connection to their access points,
and is there any possibility that we can connect them to a different access point, that has
maybe a better connection.
So this is also very useful, and yeah, once we've determined that we would actually like
advice to connect to a different access point, this is something that we can also do.
So the EasyMesh protocol includes messages to steer advice, and what we will do is the
controller will tell the agents, try to tell the station connected to you to disconnect.
There's a number of mechanisms for that in the Wi-Fi standards, like 8211K, 8211V.
They are not always supported by all devices, in particular smart phones have a bit of
ignoring them, so what we can also then do as a final option is to just blacklist the
device, not allow it to connect to an agent anymore, so it's forced to connect to a different
wireless access point.
One other very crucial functionality is onboarding, so if you add a new agent, it's easy for
them to find the controller's symptom, and then onboard through WPS or DPP, new standards
from Wi-Fi Alliance.
So in conclusion, so Wi-Fi interest, they are getting more complex, and that means they
also need to get smarter, and that is really what we are doing within the PurpleMesh project,
and PurpleEcosystem in general, is we are trying to make Wi-Fi smarter.
We can use your help with that.
One thing that's also crucial to know is that open source is also very useful to get vendor
independence, so no more vendor lock-in, that is really a very big deal.
And also, sometimes you can find open ecosystems out there, even where you might not expect
it.
So all of the things that I've talked about, these router operating systems, this LCM,
App Store ecosystem, and PurpleMesh itself, it's all open source, but right now it's
still developed by the ISPs, basically, and Purple Foundation itself.
We don't get a lot of external contributions, but we welcome everyone who wants.
So yeah, check us out when you can, and yeah, related to that also, so you can make good
money developing open source codes.
So yeah, this is where I plug my own company, Minds.
We are software consultants, especially focused on embedded software and open source, and
we are hiring.
So yeah, I'll be around here outside of the whole after presentation, so yeah, hit me
up if that sounds interesting to you.
All right, then, any questions?
So the operators and ISPs have previously gotten together and made something called HomeNet,
and that went very much the same direction, and then they decided they didn't like it
because it supports you getting more than one internet provider and using that at the
same time, which this does not support.
And this also doesn't support other things, for example, meshing well with the ZigBee
or home automation stuff.
So I would ask you, have you actually evaluated whether this is a good standard to implement?
Do you think this is a good standard to implement?
And if yes, why?
Yeah, an interesting question.
I am not familiar with this HomeNet you're talking about, although behind you, Walter,
definitely is.
Maybe I can answer that because I'm one of the operators, and I was in the HomeNet working
group as well, I rejected being the chair at some point in time.
HomeNet was very challenging in the sense that it decided to remove all existing protocols
to communicate with the individual devices, such as let's get rid of the HEP, let's go
do something else.
So from a point of view of a realistic framework, a realistic path to get there, that was a
problem.
There are some parts of HomeNet, such as HNCP, that have been reused by some proprietary
vendors here and there, but it's all died.
Now, when it comes to the lineage of EasyMesh, that's a whole different story, and why it's
based on 1905, it was essentially a few companies that got together and said, what are we going
to do?
Are we going to do it at Layer 2?
Are we going to do it at Layer 3?
And it's mostly based on internal pressures of, well, we have something that's 1905-based,
it works together with our power line devices already, let's use that as a basis.
It wasn't too fond of it, but VHS versus Bitimaxa and V2000, right?
So to me, I still see value in HomeNet in trying to get some of the concepts in there.
Now, the other problem with HomeNet, and I had the discussion with the chair at the time
as well, is this mentality that there was that every access point had its own IP range
rather than what the reality is in a wireless network in a home, which is that it's all
a Layer 2, it's one single Layer 2.
If you do this steering that really explains where a device in milliseconds switches from
one access point to another while consistently maintaining like a video call or something
like that, you're not going to get a different IP address, you're not going to restart your
TCP connection or whatever, it doesn't make any sense.
So doing this at Layer 2 just makes a lot more sense than the HomeNet concept of multiple
segments and passing on from there.
So HomeNet does have the advantage that you don't need special hardware support in supporting
the 4-frame 802.11, so to get the data along.
I do actually agree with most of your points that I think that the best solution is somewhere
in the middle between the two, because this is so Wi-Fi centric that it can't really
support things that aren't Wi-Fi, but it is better for Wi-Fi itself, which I think is
to a good degree your point, especially with the mobility.
So the question is, is it possible to build both into one thing maybe?
Let's continue this conversation.
Yes, so right, so that's the nice thing of being based on.
So Wi-Fi Alliance is focused purely on the wireless side.
The rest of us are making sure that wired connections retain support, especially Ethernet.
Now, the good thing about 1905 is that it is a protocol that supports also other, not
only Ethernet, but also other things.
1905.1A added standard support for G.HN, you could have, so there's a modeling on top
of mocha, so you can have coaxial twisted pair, an intern in-home fiber, et cetera.
Protocols are all supported.
We just need to keep the Wi-Fi Alliance on us from time to time, because they're modeling
using Wi-Fi Alliance data elements of the network topology, tends to ignore everything
that's not wireless.
But when it comes to supporting network ports on a particular switch, et cetera, that all
comes natively in 1905.
So that's fully supported by EasyMesh, and we make sure that that is supported in purple
mesh.
Indeed.
That is indeed very important.
We try to go beyond Wi-Fi, that's what it is.
You mentioned that most hardware is not compatible, but can you give some examples, maybe?
Which hardware is?
Yeah.
So what I think Qualcomm tends to be fairly good about their hardware drivers.
Broadcom is not as good, so yeah, a message for anyone considering trying to make a new
SOC avoid Broadcom.
A bit more detail, I did get Broadcom to agree to support this as well, and it is supported.
There are some gaps in what the proprietary drivers support at the moment, and what they
supported in the later 2011.
So Linux Wireless does need to get upset.
We've identified the gaps, and we hope to work with the host AP and the Linux Wireless
community fix that.
Now, me as an operator, I've given it a hard requirement to all our silicon vendors who
want to do a gateway or an access point, that they must comply with this.
And we do have general support for it, it's just that every time there's a new standard
coming out, such as Wi-Fi 7 now, that they first develop proprietary interfaces and we
need to keep them on the right track.
That's a bit of the, that's the challenge, essentially.
I did mention before that the Purple Foundation is also involved in trying to set standards
for Wi-Fi drivers and low-level API.
That's my part.
This low-level API, this definition of that, I'm the chair of that, to make sure that all
the proprietary silicon uses standard Linux interfaces.
Some more questions?
Someone over there, yeah.
Hello.
In terms of vulnerability management, is there a way for the agents to be updated from the
central agent or in some other way without losing connectivity or would the need to patch
something cause everything to drop?
So if I understand correctly, the question is whether it's possible to steer a device
without causing the connection to drop, right?
Are steered or because you said that it's highly demanding on the wireless driver to
do that, so I'm guessing that in case you also need to patch something, you're risking
the connection.
So is there some handling internally to ensure that even during an update, could be a rolling
update, for example, one agent at a time or something like that, is there some provision
to make sure that it's not going to cost connectivity if it does an update or is something that's
still not being developed yet?
I think if you reconfigure your network, like change SSIDs and so on, connection will drop.
No?
Okay.
Yeah.
My apologies.
I'm not super into all of the technical details, but apparently there are ways to manage that
and so that your connections are not dropping.
And I should also mention the virtual BSS project, which we are also collaborating on
with an organization called Gable Labs.
And there the goal is to have a single virtual AP per device, so basically an AP that follows
your device around by means of, by way of speaking.
So it means that your phone, for instance, will always see the same AP regardless of
where you go.
And this means that no connections ever need to get dropped when you move around.
This is also a very interesting project that we are working on at the moment, so it is,
yeah.
But yeah, in general, no, the answer to your question is no, the connection doesn't need
to drop.
Okay.
Any more questions?
Okay.
So it is all very interesting.
The question is, is there any of the shelf equipments, which are more or less made-tried
at?
Yes.
We have some reference hardware that you can just buy on Amazon or other places.
So that's readily available that you can test per permission.
So we have two reference devices, the G-Linux B-1300s and the Taurus Omnia that are readily
available and we will be adding more in the future as well.
And I guess it is mentioned somewhere, so I'm going to check it out.
So if you go to our HitLock page for PurpleMesh, we have a lot of documentation on the wiki
including documentation about which hardware to get, so I think, yeah.
So yeah, actually I had it there.
So we have, in the Getting Started guides, we have a section here on device purchasing
options, so as you can see, I would recommend the Taurus Omnia and the G-Linux.
The NETgear Rex 40 is no longer really supported because it lacks a crucial feature that is
required for a while back also.
I would not recommend that one.
Okay, thank you.
Any more questions?
I think we are good.
There are no more questions for you.
Thank you very much for the presentation.