[00:00.000 --> 00:13.280]  Hello, everyone, and welcome to my presentation.
[00:13.280 --> 00:14.680]  I am Frédéric van Boogert.
[00:14.680 --> 00:20.280]  I work for a company called Mind, and I'm here to present to you the PurpleMesh project,
[00:20.280 --> 00:27.720]  which is an open source Wi-Fi mesh solution.
[00:27.720 --> 00:31.280]  So who am I?
[00:31.280 --> 00:36.120]  Like I said, I'm an embedded software developer, and I work for Mind.
[00:36.120 --> 00:43.520]  And since 2020, I've been a project manager for this PurpleMesh project at the Purple Foundation.
[00:43.520 --> 00:51.520]  And feel free to email me if you want after presentation, if you have any more questions
[00:51.520 --> 00:54.160]  afterwards.
[00:54.160 --> 00:55.520]  So what is the Purple Foundation?
[00:55.520 --> 01:02.640]  So the Purple Foundation is really a very big conglomeration of the Telcoms industry.
[01:02.640 --> 01:13.160]  So if you look at the logos that I have there, there are a lot of ISPs in there, like AT&T,
[01:13.160 --> 01:19.320]  like Deutsche Telekom, like Dish, like Verizon, Vodafone.
[01:19.320 --> 01:25.480]  So there's a lot of big ISPs in Purple Foundation, and also some hardware manufacturers
[01:25.480 --> 01:33.800]  like ASCII, MediaTek, MaxDineur, Calm.
[01:33.800 --> 01:43.760]  And so basically what we do is we sponsor the development of router firmware.
[01:43.760 --> 01:51.320]  So how this came about is essentially operators, they want to provide their users, so with
[01:51.320 --> 01:58.360]  operators, I mean internet service providers, they want to provide their users with access
[01:58.360 --> 02:06.760]  points and routers, because not everyone can go out and buy them and configure them themselves.
[02:06.760 --> 02:12.120]  But all of the software development is not really their core expertise.
[02:12.120 --> 02:16.600]  So traditionally, they've relied on stacks developed by hardware, their hardware partners,
[02:16.600 --> 02:25.040]  but they also, this is not their core expertise, and so Purple Foundation was kind of created
[02:25.040 --> 02:30.120]  to collaborate on this with various partners.
[02:30.120 --> 02:35.800]  So the main projects that we're working on are Purple OS, which is a router firmware based
[02:35.800 --> 02:43.000]  on OpenWRT, Purple Mesh, which is a subject of this presentation, and also noteworthy
[02:43.000 --> 02:49.320]  is Lifecycle Management, which is kind of an attempt to create an up-store infrastructure,
[02:49.320 --> 02:52.520]  which is really cool actually.
[02:52.520 --> 02:59.440]  And we are also heavily involved in talking about router security and router data models,
[02:59.440 --> 03:04.800]  so basically the API of a router.
[03:04.800 --> 03:10.040]  So that's kind of the overview of the Purple Foundation.
[03:10.040 --> 03:17.480]  So Purple Mesh itself is an IEEE 1905 stack, so this is a layer 2.5 protocol.
[03:17.480 --> 03:22.400]  So it sits on top of Wi-Fi and Ethernet, but below IP.
[03:22.400 --> 03:27.400]  And the stack itself is based on open-sourced Intel codes.
[03:27.400 --> 03:33.960]  So we are a fully functional easy mesh implementation with both agent and controller roles supported,
[03:33.960 --> 03:39.120]  and I will talk later about what that means.
[03:39.120 --> 03:43.360]  And we have extensive API centralization effort as well in collaboration with the Broadband
[03:43.360 --> 03:50.640]  Forum, so we don't just want to write an API, we want to really think about it, and so we
[03:50.640 --> 03:59.480]  are collaborating on that with other industry fora.
[03:59.480 --> 04:02.120]  And we also have a very heavy emphasis on testing.
[04:02.120 --> 04:11.400]  So we have some Wi-Fi Alliance testbeds that we extensively test with.
[04:11.400 --> 04:18.120]  So I said Purple Mesh is an easy mesh implementation, so what do I mean by that?
[04:18.120 --> 04:22.800]  So this is the easy mesh protocol.
[04:22.800 --> 04:29.840]  It's Wi-Fi Alliance standards, just as Wi-Fi 6 and Wi-Fi 7 are Wi-Fi Alliance standards.
[04:29.840 --> 04:33.360]  And this is all meant to simplify your Wi-Fi management.
[04:33.360 --> 04:48.680]  So for Wi-Fi, often the problem that we have is you want to add an X point to your network.
[04:48.680 --> 04:52.440]  So you want to add an X point to your network, but then you need to configure it, and then
[04:52.440 --> 04:56.360]  it needs to, and that can be quite tedious.
[04:56.360 --> 05:04.440]  So the easy mesh protocol can do that for you, so you just onboard new devices using
[05:04.440 --> 05:10.680]  WPS pairing, which is also extended by the easy mesh standards, and the device will automatically
[05:10.680 --> 05:16.000]  join your network and have all of your settings, including passphrases and the bands it needs
[05:16.000 --> 05:23.320]  to operate on, the SSIDs, any guest networks that you have configured and so on.
[05:23.320 --> 05:28.440]  Another thing that the easy mesh standard does is it shares the configuration, so if
[05:28.440 --> 05:33.480]  you want to change that configuration, if you want to add SSIDs, if you want to add guest
[05:33.480 --> 05:38.360]  networks or change any other part of your Wi-Fi configuration, you only need to do that
[05:38.360 --> 05:45.120]  in one place, and it's applied to all of your X points in your entire network.
[05:45.120 --> 05:56.000]  And finally also, it gathers a lot of metrics about your network, which can be used to optimize
[05:56.000 --> 05:59.280]  how devices connect to your network.
[05:59.280 --> 06:06.760]  So in the image there, you see various X points, and you also see various network devices,
[06:06.760 --> 06:13.360]  and so what can often happen is that an X point that is used in your network simply gets
[06:13.360 --> 06:17.840]  overloaded because all of the devices try to connect to that X point, and your other
[06:17.840 --> 06:24.320]  X points don't see any use, and especially if you have a precarious backhaul that can
[06:24.320 --> 06:27.800]  lead to some performance problems.
[06:27.800 --> 06:33.440]  So applications that uses easy mesh standards, they can monitor this, they can see that there
[06:33.440 --> 06:41.840]  is a problem, and they can try to steer these devices to use different X points.
[06:41.840 --> 06:49.640]  Just solving performance problems in your network.
[06:49.640 --> 06:54.120]  So purple mesh is an easy mesh implementation.
[06:54.120 --> 06:59.560]  So basically we implement all of the functionality that I've just described.
[06:59.560 --> 07:05.680]  It is portable to a number of different router operating systems, all based on Linux.
[07:05.680 --> 07:13.800]  So OpenWRT, PurpleOS, and RDKB in particular, it's also portable in theory to other Linux-based
[07:13.800 --> 07:16.000]  operating systems.
[07:16.000 --> 07:22.880]  The main dependency that we have is we rely on all softwares, like UBUS or ARBUS is typically
[07:22.880 --> 07:30.480]  used in these router operating systems, but we could also support something like DBUS for
[07:30.480 --> 07:32.880]  other platforms.
[07:32.880 --> 07:39.840]  The main problem that we encounter when trying to port purple mesh to new platforms is we
[07:39.840 --> 07:45.680]  need really good Wi-Fi drivers because something like mesh networking tests your Wi-Fi drivers
[07:45.680 --> 07:55.040]  like nothing else, and we find that most Wi-Fi drivers simply are not good enough to support
[07:55.040 --> 07:58.920]  all the functionality that we need.
[07:58.920 --> 08:06.960]  So that is one thing that we are also active in purple is we try to spur innovation in
[08:06.960 --> 08:08.480]  the Wi-Fi drivers.
[08:08.480 --> 08:15.440]  So we collaborate or we try to collaborate with hardware vendors to make sure that their
[08:15.440 --> 08:24.080]  drivers are not just capable enough to support mesh, but that this is also done in their
[08:24.080 --> 08:26.640]  open source drivers.
[08:26.640 --> 08:33.440]  So we do still support some proprietary drivers for some hardware, but this is very much transitional,
[08:33.440 --> 08:43.120]  and we hope to get various vendors to open source their wireless drivers and make sure
[08:43.120 --> 08:48.800]  that all the functionality that we need is supported by those open drivers based on config
[08:48.800 --> 08:57.040]  802.11 and 802.11.
[08:57.040 --> 09:02.400]  And so yeah, why did we develop purple mesh?
[09:02.400 --> 09:11.720]  So basically, like I mentioned, purple is a whole community of different service providers
[09:11.720 --> 09:15.160]  coming together to develop a single solution.
[09:15.160 --> 09:22.440]  So instead of everyone having to develop their own software, it makes sense to collaborate.
[09:22.440 --> 09:31.560]  Also by developing the software ourselves, the service providers, they get independence
[09:31.560 --> 09:34.880]  from system chip vendors.
[09:34.880 --> 09:39.840]  So what we've seen in the past and what we still sometimes see is that there are SOC
[09:39.840 --> 09:47.560]  vendors that try to force you to use their own proprietary software and to depend on their
[09:47.560 --> 09:56.080]  proprietary interfaces, and that creates a vendor lock-in within the ecosystem, and that
[09:56.080 --> 10:03.400]  is something that we are very much aware of and are trying to combat as well.
[10:03.400 --> 10:11.280]  And another good reason to develop purple mesh, and in fact the original reason, is
[10:11.280 --> 10:21.800]  as a stress test for the wireless drivers, because like I mentioned, Wi-Fi mesh, it taxes
[10:21.800 --> 10:33.200]  your Wi-Fi drivers in ways that nothing else does, and that was kind of the original motivation
[10:33.200 --> 10:42.680]  of purple mesh was to act as a test for open source Wi-Fi drivers, but it kind of ballooned
[10:42.680 --> 10:47.120]  from there.
[10:47.120 --> 10:53.320]  And one other thing that we do is try to encourage the development of a common API for easy mesh
[10:53.320 --> 10:55.560]  implementations.
[10:55.560 --> 11:02.480]  This API is usable for remote management, for network diagnostics, and to enable others
[11:02.480 --> 11:09.960]  to create router apps to configure Wi-Fi, so they can plug into purple mesh and use
[11:09.960 --> 11:14.280]  it to smartly configure your own Wi-Fi.
[11:14.280 --> 11:27.120]  This also is enabled by the LCM project, which allows you to add router apps to your router,
[11:27.120 --> 11:35.640]  and some of those might use purple mesh to optimize your network, or to show you more
[11:35.640 --> 11:45.520]  information about your network.
[11:45.520 --> 11:49.400]  So let me check the time here, we do have time.
[11:49.400 --> 11:54.880]  Okay, so yeah, easy mesh itself, like I mentioned, it's based on IEEE 905.
[11:54.880 --> 12:05.520]  This is a very extensible protocol on top of Ethernet and Wi-Fi.
[12:05.520 --> 12:14.480]  So it uses a fixed multicast address, and the main feature of it is it works with TLV,
[12:14.480 --> 12:23.600]  so type length value tuples, and you can add as many of these as you like, and the way
[12:23.600 --> 12:33.720]  easy mesh works is it defines a set of TLVs that have a specific use.
[12:33.720 --> 12:42.080]  So for instance, TLVs to configure access points, or to report certain metrics, or to
[12:42.080 --> 12:50.000]  discover devices on the network, things like that.
[12:50.000 --> 12:58.680]  So yeah, one thing that easy mesh uses, so one thing that easy mesh can also be used
[12:58.680 --> 13:02.080]  for is discovery of devices on the network.
[13:02.080 --> 13:09.760]  So all IEEE 905 devices, they can report all of their neighboring devices in the network,
[13:09.760 --> 13:16.040]  and that helps you get the topology map of all the devices that are present in your network.
[13:16.040 --> 13:24.160]  So it's easy to discover what's currently living in your network.
[13:24.160 --> 13:32.400]  So this is also, of course, a vital tool to allow you to optimize the network, and one
[13:32.400 --> 13:39.200]  other thing that we get is metrics, like I mentioned, so you can see how well the connection
[13:39.200 --> 13:45.000]  is between various devices that you might have in your network, like your laptops and
[13:45.000 --> 13:51.240]  your smart phones and your smart TVs, how well is the connection to their access points,
[13:51.240 --> 13:55.920]  and is there any possibility that we can connect them to a different access point, that has
[13:55.920 --> 13:59.480]  maybe a better connection.
[13:59.480 --> 14:06.360]  So this is also very useful, and yeah, once we've determined that we would actually like
[14:06.360 --> 14:12.400]  advice to connect to a different access point, this is something that we can also do.
[14:12.400 --> 14:18.960]  So the EasyMesh protocol includes messages to steer advice, and what we will do is the
[14:18.960 --> 14:27.400]  controller will tell the agents, try to tell the station connected to you to disconnect.
[14:27.400 --> 14:35.080]  There's a number of mechanisms for that in the Wi-Fi standards, like 8211K, 8211V.
[14:35.080 --> 14:40.400]  They are not always supported by all devices, in particular smart phones have a bit of
[14:40.400 --> 14:44.960]  ignoring them, so what we can also then do as a final option is to just blacklist the
[14:44.960 --> 14:50.560]  device, not allow it to connect to an agent anymore, so it's forced to connect to a different
[14:50.560 --> 14:59.160]  wireless access point.
[14:59.160 --> 15:08.920]  One other very crucial functionality is onboarding, so if you add a new agent, it's easy for
[15:08.920 --> 15:20.280]  them to find the controller's symptom, and then onboard through WPS or DPP, new standards
[15:20.280 --> 15:27.720]  from Wi-Fi Alliance.
[15:27.720 --> 15:37.160]  So in conclusion, so Wi-Fi interest, they are getting more complex, and that means they
[15:37.160 --> 15:43.040]  also need to get smarter, and that is really what we are doing within the PurpleMesh project,
[15:43.040 --> 15:54.520]  and PurpleEcosystem in general, is we are trying to make Wi-Fi smarter.
[15:54.520 --> 15:58.040]  We can use your help with that.
[15:58.040 --> 16:07.560]  One thing that's also crucial to know is that open source is also very useful to get vendor
[16:07.560 --> 16:20.040]  independence, so no more vendor lock-in, that is really a very big deal.
[16:20.040 --> 16:25.480]  And also, sometimes you can find open ecosystems out there, even where you might not expect
[16:25.480 --> 16:26.480]  it.
[16:26.480 --> 16:34.800]  So all of the things that I've talked about, these router operating systems, this LCM,
[16:34.800 --> 16:40.040]  App Store ecosystem, and PurpleMesh itself, it's all open source, but right now it's
[16:40.040 --> 16:47.880]  still developed by the ISPs, basically, and Purple Foundation itself.
[16:47.880 --> 16:55.920]  We don't get a lot of external contributions, but we welcome everyone who wants.
[16:55.920 --> 17:06.920]  So yeah, check us out when you can, and yeah, related to that also, so you can make good
[17:06.920 --> 17:10.280]  money developing open source codes.
[17:10.280 --> 17:14.960]  So yeah, this is where I plug my own company, Minds.
[17:14.960 --> 17:22.240]  We are software consultants, especially focused on embedded software and open source, and
[17:22.240 --> 17:23.320]  we are hiring.
[17:23.320 --> 17:31.360]  So yeah, I'll be around here outside of the whole after presentation, so yeah, hit me
[17:31.360 --> 17:34.320]  up if that sounds interesting to you.
[17:34.320 --> 17:46.840]  All right, then, any questions?
[17:46.840 --> 17:54.640]  So the operators and ISPs have previously gotten together and made something called HomeNet,
[17:54.640 --> 17:58.160]  and that went very much the same direction, and then they decided they didn't like it
[17:58.160 --> 18:01.720]  because it supports you getting more than one internet provider and using that at the
[18:01.720 --> 18:04.680]  same time, which this does not support.
[18:04.680 --> 18:09.040]  And this also doesn't support other things, for example, meshing well with the ZigBee
[18:09.040 --> 18:11.080]  or home automation stuff.
[18:11.080 --> 18:17.400]  So I would ask you, have you actually evaluated whether this is a good standard to implement?
[18:17.400 --> 18:20.160]  Do you think this is a good standard to implement?
[18:20.160 --> 18:22.120]  And if yes, why?
[18:22.120 --> 18:26.160]  Yeah, an interesting question.
[18:26.160 --> 18:33.360]  I am not familiar with this HomeNet you're talking about, although behind you, Walter,
[18:33.360 --> 18:34.360]  definitely is.
[18:34.360 --> 18:39.120]  Maybe I can answer that because I'm one of the operators, and I was in the HomeNet working
[18:39.120 --> 18:43.600]  group as well, I rejected being the chair at some point in time.
[18:43.600 --> 18:50.200]  HomeNet was very challenging in the sense that it decided to remove all existing protocols
[18:50.200 --> 18:54.320]  to communicate with the individual devices, such as let's get rid of the HEP, let's go
[18:54.320 --> 18:55.680]  do something else.
[18:55.680 --> 19:02.240]  So from a point of view of a realistic framework, a realistic path to get there, that was a
[19:02.240 --> 19:03.240]  problem.
[19:03.240 --> 19:07.520]  There are some parts of HomeNet, such as HNCP, that have been reused by some proprietary
[19:07.520 --> 19:10.320]  vendors here and there, but it's all died.
[19:10.320 --> 19:14.800]  Now, when it comes to the lineage of EasyMesh, that's a whole different story, and why it's
[19:14.800 --> 19:19.640]  based on 1905, it was essentially a few companies that got together and said, what are we going
[19:19.640 --> 19:20.640]  to do?
[19:20.640 --> 19:21.640]  Are we going to do it at Layer 2?
[19:21.640 --> 19:23.560]  Are we going to do it at Layer 3?
[19:23.560 --> 19:29.520]  And it's mostly based on internal pressures of, well, we have something that's 1905-based,
[19:29.520 --> 19:33.720]  it works together with our power line devices already, let's use that as a basis.
[19:33.720 --> 19:40.680]  It wasn't too fond of it, but VHS versus Bitimaxa and V2000, right?
[19:40.680 --> 19:49.440]  So to me, I still see value in HomeNet in trying to get some of the concepts in there.
[19:49.440 --> 19:53.600]  Now, the other problem with HomeNet, and I had the discussion with the chair at the time
[19:53.600 --> 20:01.240]  as well, is this mentality that there was that every access point had its own IP range
[20:01.240 --> 20:05.840]  rather than what the reality is in a wireless network in a home, which is that it's all
[20:05.840 --> 20:09.120]  a Layer 2, it's one single Layer 2.
[20:09.120 --> 20:13.760]  If you do this steering that really explains where a device in milliseconds switches from
[20:13.760 --> 20:19.960]  one access point to another while consistently maintaining like a video call or something
[20:19.960 --> 20:23.840]  like that, you're not going to get a different IP address, you're not going to restart your
[20:23.840 --> 20:27.400]  TCP connection or whatever, it doesn't make any sense.
[20:27.400 --> 20:34.960]  So doing this at Layer 2 just makes a lot more sense than the HomeNet concept of multiple
[20:34.960 --> 20:42.960]  segments and passing on from there.
[20:42.960 --> 20:47.920]  So HomeNet does have the advantage that you don't need special hardware support in supporting
[20:47.920 --> 20:52.560]  the 4-frame 802.11, so to get the data along.
[20:52.560 --> 20:57.120]  I do actually agree with most of your points that I think that the best solution is somewhere
[20:57.120 --> 21:02.920]  in the middle between the two, because this is so Wi-Fi centric that it can't really
[21:02.920 --> 21:09.800]  support things that aren't Wi-Fi, but it is better for Wi-Fi itself, which I think is
[21:09.800 --> 21:12.880]  to a good degree your point, especially with the mobility.
[21:12.880 --> 21:17.320]  So the question is, is it possible to build both into one thing maybe?
[21:17.320 --> 21:21.920]  Let's continue this conversation.
[21:21.920 --> 21:26.360]  Yes, so right, so that's the nice thing of being based on.
[21:26.360 --> 21:29.920]  So Wi-Fi Alliance is focused purely on the wireless side.
[21:29.920 --> 21:35.240]  The rest of us are making sure that wired connections retain support, especially Ethernet.
[21:35.240 --> 21:42.600]  Now, the good thing about 1905 is that it is a protocol that supports also other, not
[21:42.600 --> 21:44.560]  only Ethernet, but also other things.
[21:44.560 --> 21:51.440]  1905.1A added standard support for G.HN, you could have, so there's a modeling on top
[21:51.440 --> 21:57.920]  of mocha, so you can have coaxial twisted pair, an intern in-home fiber, et cetera.
[21:57.920 --> 21:59.640]  Protocols are all supported.
[21:59.640 --> 22:03.840]  We just need to keep the Wi-Fi Alliance on us from time to time, because they're modeling
[22:03.840 --> 22:09.760]  using Wi-Fi Alliance data elements of the network topology, tends to ignore everything
[22:09.760 --> 22:11.080]  that's not wireless.
[22:11.080 --> 22:16.360]  But when it comes to supporting network ports on a particular switch, et cetera, that all
[22:16.360 --> 22:17.840]  comes natively in 1905.
[22:17.840 --> 22:23.520]  So that's fully supported by EasyMesh, and we make sure that that is supported in purple
[22:23.520 --> 22:24.520]  mesh.
[22:24.520 --> 22:25.520]  Indeed.
[22:25.520 --> 22:28.480]  That is indeed very important.
[22:28.480 --> 22:33.800]  We try to go beyond Wi-Fi, that's what it is.
[22:33.800 --> 22:39.600]  You mentioned that most hardware is not compatible, but can you give some examples, maybe?
[22:39.600 --> 22:42.600]  Which hardware is?
[22:42.600 --> 22:45.240]  Yeah.
[22:45.240 --> 22:57.880]  So what I think Qualcomm tends to be fairly good about their hardware drivers.
[22:57.880 --> 23:08.480]  Broadcom is not as good, so yeah, a message for anyone considering trying to make a new
[23:08.480 --> 23:10.880]  SOC avoid Broadcom.
[23:10.880 --> 23:19.360]  A bit more detail, I did get Broadcom to agree to support this as well, and it is supported.
[23:19.360 --> 23:23.880]  There are some gaps in what the proprietary drivers support at the moment, and what they
[23:23.880 --> 23:25.920]  supported in the later 2011.
[23:25.920 --> 23:28.360]  So Linux Wireless does need to get upset.
[23:28.360 --> 23:32.880]  We've identified the gaps, and we hope to work with the host AP and the Linux Wireless
[23:32.880 --> 23:34.080]  community fix that.
[23:34.080 --> 23:38.560]  Now, me as an operator, I've given it a hard requirement to all our silicon vendors who
[23:38.560 --> 23:43.720]  want to do a gateway or an access point, that they must comply with this.
[23:43.720 --> 23:48.920]  And we do have general support for it, it's just that every time there's a new standard
[23:48.920 --> 23:53.960]  coming out, such as Wi-Fi 7 now, that they first develop proprietary interfaces and we
[23:53.960 --> 23:55.720]  need to keep them on the right track.
[23:55.720 --> 23:58.720]  That's a bit of the, that's the challenge, essentially.
[23:58.720 --> 24:04.360]  I did mention before that the Purple Foundation is also involved in trying to set standards
[24:04.360 --> 24:08.360]  for Wi-Fi drivers and low-level API.
[24:08.360 --> 24:09.360]  That's my part.
[24:09.360 --> 24:14.480]  This low-level API, this definition of that, I'm the chair of that, to make sure that all
[24:14.480 --> 24:22.360]  the proprietary silicon uses standard Linux interfaces.
[24:22.360 --> 24:26.960]  Some more questions?
[24:26.960 --> 24:30.720]  Someone over there, yeah.
[24:30.720 --> 24:33.200]  Hello.
[24:33.200 --> 24:40.120]  In terms of vulnerability management, is there a way for the agents to be updated from the
[24:40.120 --> 24:46.320]  central agent or in some other way without losing connectivity or would the need to patch
[24:46.320 --> 24:50.400]  something cause everything to drop?
[24:50.400 --> 24:57.440]  So if I understand correctly, the question is whether it's possible to steer a device
[24:57.440 --> 24:59.960]  without causing the connection to drop, right?
[24:59.960 --> 25:04.760]  Are steered or because you said that it's highly demanding on the wireless driver to
[25:04.760 --> 25:09.680]  do that, so I'm guessing that in case you also need to patch something, you're risking
[25:09.680 --> 25:10.680]  the connection.
[25:10.680 --> 25:15.880]  So is there some handling internally to ensure that even during an update, could be a rolling
[25:15.880 --> 25:21.240]  update, for example, one agent at a time or something like that, is there some provision
[25:21.240 --> 25:26.640]  to make sure that it's not going to cost connectivity if it does an update or is something that's
[25:26.640 --> 25:29.600]  still not being developed yet?
[25:29.600 --> 25:38.120]  I think if you reconfigure your network, like change SSIDs and so on, connection will drop.
[25:38.120 --> 25:40.120]  No?
[25:40.120 --> 25:41.120]  Okay.
[25:41.120 --> 25:42.120]  Yeah.
[25:42.120 --> 25:43.120]  My apologies.
[25:43.120 --> 25:51.680]  I'm not super into all of the technical details, but apparently there are ways to manage that
[25:51.680 --> 25:54.640]  and so that your connections are not dropping.
[25:54.640 --> 26:02.600]  And I should also mention the virtual BSS project, which we are also collaborating on
[26:02.600 --> 26:06.160]  with an organization called Gable Labs.
[26:06.160 --> 26:16.360]  And there the goal is to have a single virtual AP per device, so basically an AP that follows
[26:16.360 --> 26:21.000]  your device around by means of, by way of speaking.
[26:21.000 --> 26:25.640]  So it means that your phone, for instance, will always see the same AP regardless of
[26:25.640 --> 26:28.040]  where you go.
[26:28.040 --> 26:33.600]  And this means that no connections ever need to get dropped when you move around.
[26:33.600 --> 26:40.280]  This is also a very interesting project that we are working on at the moment, so it is,
[26:40.280 --> 26:41.280]  yeah.
[26:41.280 --> 26:46.240]  But yeah, in general, no, the answer to your question is no, the connection doesn't need
[26:46.240 --> 26:47.240]  to drop.
[26:47.240 --> 26:48.240]  Okay.
[26:48.240 --> 26:50.240]  Any more questions?
[26:50.240 --> 26:51.240]  Okay.
[26:51.240 --> 26:55.400]  So it is all very interesting.
[26:55.400 --> 27:00.840]  The question is, is there any of the shelf equipments, which are more or less made-tried
[27:00.840 --> 27:01.840]  at?
[27:01.840 --> 27:02.840]  Yes.
[27:02.840 --> 27:10.880]  We have some reference hardware that you can just buy on Amazon or other places.
[27:10.880 --> 27:15.040]  So that's readily available that you can test per permission.
[27:15.040 --> 27:23.280]  So we have two reference devices, the G-Linux B-1300s and the Taurus Omnia that are readily
[27:23.280 --> 27:27.480]  available and we will be adding more in the future as well.
[27:27.480 --> 27:31.360]  And I guess it is mentioned somewhere, so I'm going to check it out.
[27:31.360 --> 27:44.640]  So if you go to our HitLock page for PurpleMesh, we have a lot of documentation on the wiki
[27:44.640 --> 27:54.520]  including documentation about which hardware to get, so I think, yeah.
[27:54.520 --> 27:58.880]  So yeah, actually I had it there.
[27:58.880 --> 28:06.400]  So we have, in the Getting Started guides, we have a section here on device purchasing
[28:06.400 --> 28:13.560]  options, so as you can see, I would recommend the Taurus Omnia and the G-Linux.
[28:13.560 --> 28:20.320]  The NETgear Rex 40 is no longer really supported because it lacks a crucial feature that is
[28:20.320 --> 28:21.800]  required for a while back also.
[28:21.800 --> 28:23.560]  I would not recommend that one.
[28:23.560 --> 28:25.560]  Okay, thank you.
[28:25.560 --> 28:36.640]  Any more questions?
[28:36.640 --> 28:37.640]  I think we are good.
[28:37.640 --> 28:39.240]  There are no more questions for you.
[28:39.240 --> 28:46.240]  Thank you very much for the presentation.