Wi-Fi alliance announces mesh networking standard(wi-fi.org)
wi-fi.org
Wi-Fi alliance announces mesh networking standard
https://www.wi-fi.org/discover-wi-fi/wi-fi-easymesh
22 comments
Available since iOS 7 https://developer.apple.com/documentation/multipeerconnectiv...
16 years after that grand dream of ubiquitous personal mesh networking, and still today given a top of the line pair of headphones and a top of the line computer, the two will still reliably fail to communicate for some subset of users.
Nice try blaming it on political pressure, but I'd call it sound engineering! "Let's get the simple stuff right before we discuss the support costs of making mesh work over this junk"
Nice try blaming it on political pressure, but I'd call it sound engineering! "Let's get the simple stuff right before we discuss the support costs of making mesh work over this junk"
I'm in complete agreement with your comment. I have yet to see a sane looking bluetooth implementation. I think OpenBSD even dropped it entirely due to it being a hacky mess.
Thing is that bluetooth kinda clash with the unix /dev concept.
Because each pairing is effectively a new device in /dev, and doing anything with bluetooth require that one cross the user/root divide multiple times.
Because each pairing is effectively a new device in /dev, and doing anything with bluetooth require that one cross the user/root divide multiple times.
Holding a stack that can handle losses (TCP/IP) to the same standards as bluetooth audio is silly.
We're talking about a max 72KiB/sec connection (AptX HD) at one meter range between 2 peers, parent comment refers to flash mob gaming on a bus. A modern London bus seats 62 over a 11.23x2.52x4.39m area surrounded by numerous metallic partitions in a continuously changing RF environment (driving through a city).
Assuming audio between 2 peers at 1 meter was somehow a solved problem (per above it's not), and collision avoidance was a non-issue (problem worsens exponentially with additional peers), that's 1.16KB/sec in some idealized non-existent reality of bandwidth to run a compelling game for 62 people. Perhaps parent comment refers to a flash mob game of Chess.
Assuming Bluetooth only reliably fails between two peers 1% of the time (oh, but to dream), that's a 99%^62 = 5.36% chance of a bus full of people successfully joining a single mesh.
Silliness is in the eye of the beholder!
Assuming audio between 2 peers at 1 meter was somehow a solved problem (per above it's not), and collision avoidance was a non-issue (problem worsens exponentially with additional peers), that's 1.16KB/sec in some idealized non-existent reality of bandwidth to run a compelling game for 62 people. Perhaps parent comment refers to a flash mob game of Chess.
Assuming Bluetooth only reliably fails between two peers 1% of the time (oh, but to dream), that's a 99%^62 = 5.36% chance of a bus full of people successfully joining a single mesh.
Silliness is in the eye of the beholder!
> Now that bluetooth has returned to its roots with Bluetooth Low Energy, maybe we have another chance at flash-mob mobile gaming - everyone on the same bus can join in to a chatroom or a roleplaying game for the duration of the ride.
Note that the Nintendo 3DS effectively has this capability. I believe it's all WiFi-based.
Note that the Nintendo 3DS effectively has this capability. I believe it's all WiFi-based.
Yes. Even the original DS had this with pictochat.
> flash-mob mobile gaming - everyone on the same bus can join
This can be already delivered without mesh networking. Too many privacy issues.
This can be already delivered without mesh networking. Too many privacy issues.
From Wikipedia: "Wi-Fi Direct allows two devices to establish a direct Wi-Fi connection". That's not mesh networking though. You could build a mesh on top of it, but the main purpose seems to be very single-peer-2-single-peer.
And you still have to hope the two devices have a sane protocol between them to layer on top of the wifi...
[deleted]
the biggest value of Bluetooth, to me as a user, are the profiles.
This means that there are baked in standard ways for devices to communicate.
Damn it, back in the day i had a Nokia N800 going online via a SE featurephone, while listening to music via Jabra headphones from the same phone, and typing comments on various forums using a folding keyboard paired with the N800.
This means that there are baked in standard ways for devices to communicate.
Damn it, back in the day i had a Nokia N800 going online via a SE featurephone, while listening to music via Jabra headphones from the same phone, and typing comments on various forums using a folding keyboard paired with the N800.
Hm, you are conflating a few things there. Bluetooth "scatternets" were first of all never standardized, AFAIK, but had to be implemented in the application layer, which led to vast incompatibilities.
Bluetooth profiles, and vendors restricting their devices to sport only certain profiles, are a good thing for compatibility, since it ensures (if done correctly) that devices (i.e. applications in fact) from different vendors can talk to each other.
"WiFi direct" is yet another completely different thing, that is meant for peer-to-peer connections (note: two communication partners) without needing an AP, which 802.11 consumer standards (b,g,n,ac) all did and do otherwise.
Also this standard has nothing to to with flash-mob gaming, and won't allow for it. This is AFAIK meant as a standardization of several so far vendor-specific efforts to extend networks through the use of several APs (similarly to how repeaters were used). Still a good thing, because it is no longer vendor-specific if my devices support the standard.
By expecting mesh networking to solve your applications needs you are IMO skipping a few layers in between. You want ad-hoc, high throughput mesh networks, stateless auto-configuration, service discovery, and quite a few other things regarding routing, QoS and flow management as well as connection management (reliability, multicast?)...
This is not the standard you are looking for. For now you would need to look for solutions in the application layer IMO.
Bluetooth profiles, and vendors restricting their devices to sport only certain profiles, are a good thing for compatibility, since it ensures (if done correctly) that devices (i.e. applications in fact) from different vendors can talk to each other.
"WiFi direct" is yet another completely different thing, that is meant for peer-to-peer connections (note: two communication partners) without needing an AP, which 802.11 consumer standards (b,g,n,ac) all did and do otherwise.
Also this standard has nothing to to with flash-mob gaming, and won't allow for it. This is AFAIK meant as a standardization of several so far vendor-specific efforts to extend networks through the use of several APs (similarly to how repeaters were used). Still a good thing, because it is no longer vendor-specific if my devices support the standard.
By expecting mesh networking to solve your applications needs you are IMO skipping a few layers in between. You want ad-hoc, high throughput mesh networks, stateless auto-configuration, service discovery, and quite a few other things regarding routing, QoS and flow management as well as connection management (reliability, multicast?)...
This is not the standard you are looking for. For now you would need to look for solutions in the application layer IMO.
> "WiFi direct" is yet another completely different thing, that is meant for peer-to-peer connections (note: two communication partners) without needing an AP, which 802.11 consumer standards (b,g,n,ac) all did and do otherwise.
Wi-Fi Direct is nothing more than running (e.g., 802.11n) software AP with WPS on one device ("Group Owner") and having (multiple) peers connect to it to form a "group" -- it's just a normal AP, you can even connect legacy Wi-Fi devices to it. It does add functionality to automatically negotiate which device becomes the access point and to do some service discovery on the link layer before connecting.
Wi-Fi Direct is nothing more than running (e.g., 802.11n) software AP with WPS on one device ("Group Owner") and having (multiple) peers connect to it to form a "group" -- it's just a normal AP, you can even connect legacy Wi-Fi devices to it. It does add functionality to automatically negotiate which device becomes the access point and to do some service discovery on the link layer before connecting.
The way you just described WiFi Direct sounds closer to true mobile-to-mobile mesh connectivity than what is described above. WiFi Direct allows nodes to trade off AP duties; EasyMesh allows nodes to optimize AP selection; scatternet allowed (if I recall correctly) multi-AP piconet connections over Bluetooth, using application layer as a workaround for inadequate link-layer protocols. ... But I wouldn't say it's like comparing apples & oranges; more like comparing Newtons & Macintosh. It seems obvious to me that they approach the same challenge (flexible connectivity) from different directions, but if you have time, please clarify how these three protocols are substantially different in purpose?
The problem with WiFi Direct is that all its local mobile-to-mobile capabilities are disabled if the group doesn't have a node connected to a tower at all times. For example, you can't have three devices up in the mountains exchange files or messages, unless one of them can get the OK from a service provider's tower. WiFi Direct stops as soon as you lose cellular signal or experience a service timeout. It's crippled by design.
EasyMesh doesn't seem to offer any neighbor-to-neighbor utility; It appears to be focused solely on expanding coverage of single-point-of-control networks which are already overcrowded (hence the need for so many range extenders). When are we not in range of half a dozen or more WiFi networks?
I see adding more APs as an exercise in futility. The primary issue is overcrowding, not signal strength. Remove all the other nearby networks & one router easily reaches across most buildings.
Sorry, I guess that's two topics in one comment, but I'll repeat my primary question: In what way are these different approaches "completely" different? They seem to all be chasing roughly the same goal. I also feel that "mesh" has stagnated due to lack of hardware support (& accompanying lack of open source firmware).
The problem with WiFi Direct is that all its local mobile-to-mobile capabilities are disabled if the group doesn't have a node connected to a tower at all times. For example, you can't have three devices up in the mountains exchange files or messages, unless one of them can get the OK from a service provider's tower. WiFi Direct stops as soon as you lose cellular signal or experience a service timeout. It's crippled by design.
EasyMesh doesn't seem to offer any neighbor-to-neighbor utility; It appears to be focused solely on expanding coverage of single-point-of-control networks which are already overcrowded (hence the need for so many range extenders). When are we not in range of half a dozen or more WiFi networks?
I see adding more APs as an exercise in futility. The primary issue is overcrowding, not signal strength. Remove all the other nearby networks & one router easily reaches across most buildings.
Sorry, I guess that's two topics in one comment, but I'll repeat my primary question: In what way are these different approaches "completely" different? They seem to all be chasing roughly the same goal. I also feel that "mesh" has stagnated due to lack of hardware support (& accompanying lack of open source firmware).
Wifi direct exists independent of cell phones. There's even a windows 10 protocol adapter for it. The phone implementation could be terribly broken, but the standard says nothing about 4G connectivity or go-ahead (as it shouldn't!).
(Replying because I can't Edit, for some reason...)
I'M SORRY! I was thinking of LTE Direct, which is crippled by design. Please disregard my statement about "WiFi Direct" needing a cellular tower.
I'M SORRY! I was thinking of LTE Direct, which is crippled by design. Please disregard my statement about "WiFi Direct" needing a cellular tower.
Well, if I compare Bluetooth (often doesn't work for no apparent reason) to WiFi (works, and when it doesn't there are comprehensible reasons) - this one might actually work. Mesh networking is very hard to do right so I can imagine how well Bluetooth's attempt worked. Probably might as well not have it at all level.
Edit: I was thinking of more dynamic and larger meshes - those are really hard. This standard seems to have a smaller scope. It's still more difficult than one-to-one.
Edit: I was thinking of more dynamic and larger meshes - those are really hard. This standard seems to have a smaller scope. It's still more difficult than one-to-one.
>another mesh standard
Standards!
https://m.xkcd.com/927/ ;)
Standards!
https://m.xkcd.com/927/ ;)
The biggest problem with mesh networking is that the word “mesh” is used for many different things involving self configuring network devices.
Any use of the word “mesh” online invites commenters who, not having RTFA, will opine endlessly based on an incorrect understanding of a completely different use of “mesh”.
Any use of the word “mesh” online invites commenters who, not having RTFA, will opine endlessly based on an incorrect understanding of a completely different use of “mesh”.
Agreed, I feel that "mesh" has been reduced to a buzzword akin to "web" 10+ years ago. In particular, this usage of it for EasyMesh begins to feel like a misappropriation. Unfortunately for anyone concerned with clarity, the term describes a topology, not which layer it is implemented on.
I constantly find myself using qualifiers like "hybrid mesh cellular" (doesn't exist due to hostile regulation), "link-layer optimization for mesh processing", & "app-layer mesh protocols for decentralized Directed Acyclic Graph consensus". "Mesh", "matrix", "net", & "web" are all terms which are virtually interchangeable in contexts outside the IT realm. "Star" most accurately describes the topology of most people's single-AP WiFi implementations, yet the term is deprecated due to association with a specific old protocol nobody's done much with in thirty years, as far as I know.
The whole thing is a linguistic nightmare, from anything but a marketing perspective (marketing loves conflation; it's one of the industry's primary tools).
EasyMesh protocol finalization looks like great news for installers & WiFi network admins, but I expect the new range extenders it enables to make the overcrowding situation worse, not better.
If it doesn't enable peer nodes to communicate without a centralized point of control, I'd vastly prefer the term "mesh" not be used at all.
I constantly find myself using qualifiers like "hybrid mesh cellular" (doesn't exist due to hostile regulation), "link-layer optimization for mesh processing", & "app-layer mesh protocols for decentralized Directed Acyclic Graph consensus". "Mesh", "matrix", "net", & "web" are all terms which are virtually interchangeable in contexts outside the IT realm. "Star" most accurately describes the topology of most people's single-AP WiFi implementations, yet the term is deprecated due to association with a specific old protocol nobody's done much with in thirty years, as far as I know.
The whole thing is a linguistic nightmare, from anything but a marketing perspective (marketing loves conflation; it's one of the industry's primary tools).
EasyMesh protocol finalization looks like great news for installers & WiFi network admins, but I expect the new range extenders it enables to make the overcrowding situation worse, not better.
If it doesn't enable peer nodes to communicate without a centralized point of control, I'd vastly prefer the term "mesh" not be used at all.
I was working on a private mesh standard for a startup a few years back because of a perceived opportunity resulting from the fractured nature of the ecosystem, resulting in no devices really using mesh. We have Bluetooth mesh, Wifi mesh standards, Thread, Alljoyn, and plenty more, but no one is benefitting from any mesh protocols in day to day life.
Some of these standards are decent technologically, but the real problem comes down to device drivers. Most wifi/bluetooth devices have drivers (and sometimes firmware, too) which are completely inflexible in sending out frames outside of their standard protocols. This is especially difficult with the abstraction layers programmed into the firmware and the fact that very different hardware is used to share spectrum (to optimize for time hopping on bluetooth, for example).
The solution: adoption of a standardized, Linux-like driver protocol for enabling custom frames to easily be sent and received on shared spectrum BEFORE adoption of the protocols built on top.
That being said, augmenting the Wifi standard to support mesh is probably the closest development to that goal that I've seen in a while, since vendors typically start supporting the new 802.11 standards pretty quickly.
Some of these standards are decent technologically, but the real problem comes down to device drivers. Most wifi/bluetooth devices have drivers (and sometimes firmware, too) which are completely inflexible in sending out frames outside of their standard protocols. This is especially difficult with the abstraction layers programmed into the firmware and the fact that very different hardware is used to share spectrum (to optimize for time hopping on bluetooth, for example).
The solution: adoption of a standardized, Linux-like driver protocol for enabling custom frames to easily be sent and received on shared spectrum BEFORE adoption of the protocols built on top.
That being said, augmenting the Wifi standard to support mesh is probably the closest development to that goal that I've seen in a while, since vendors typically start supporting the new 802.11 standards pretty quickly.
Called EasyMesh. A better link with more info than the press release: https://www.wi-fi.org/discover-wi-fi/wi-fi-easymesh
And the technical specification (submit form to view): https://www.wi-fi.org/downloads-registered-guest/Multi-AP_Te...
Most importantly: Supports multiple vendors. Current solutions are locked in to vendor platforms.
Another nice detail: Supports 802.11n Wi-Fi devices. Support for 802.11ac is optional.
And the technical specification (submit form to view): https://www.wi-fi.org/downloads-registered-guest/Multi-AP_Te...
Most importantly: Supports multiple vendors. Current solutions are locked in to vendor platforms.
Another nice detail: Supports 802.11n Wi-Fi devices. Support for 802.11ac is optional.
Why is it nice that it 802.11ac is optional?
I guess he means shorter range AC is not required by client and/or mesh devices.
A vast amount of devices in the world don't support 802.11ac.
«Current solutions are locked in to vendor platforms»
Not true. For example, mesh technology Thread is built on 802.15.4 and is very much multi-vendor. At least 4 companies make Thread chipsets (Silicon Labs, NXP, Qualcom, Nordic Semiconductor) and has 100+ member companies: https://www.threadgroup.org/thread-group#OurMembers There is an open source implementation from Google (OpenThread) who is a major member. Adoption and interest is really ramping up rapidly. Recently the spec was made freely and openly available. No royalties. I think it's really promising.
Disclosure: I participated a little bit in the design of Thread by doing a security review on behalf of Google.
Not true. For example, mesh technology Thread is built on 802.15.4 and is very much multi-vendor. At least 4 companies make Thread chipsets (Silicon Labs, NXP, Qualcom, Nordic Semiconductor) and has 100+ member companies: https://www.threadgroup.org/thread-group#OurMembers There is an open source implementation from Google (OpenThread) who is a major member. Adoption and interest is really ramping up rapidly. Recently the spec was made freely and openly available. No royalties. I think it's really promising.
Disclosure: I participated a little bit in the design of Thread by doing a security review on behalf of Google.
I think the parent was talking about so far vendor-specific solutions for 802.11.
802.15.4, meant for low-rate, low-power applications, is something completely different. This standard doesn't even compare remotely, regarding applications (you will never be able to watch a youtube video over 802.15.4) or how it works internally IMO. Even the definition of what constitutes a "mesh" is considerably different.
802.15.4, meant for low-rate, low-power applications, is something completely different. This standard doesn't even compare remotely, regarding applications (you will never be able to watch a youtube video over 802.15.4) or how it works internally IMO. Even the definition of what constitutes a "mesh" is considerably different.
It seems to me (from a brief scan of the spec) that they actually are using 802.15.4 to establish the mesh at low-rate speeds, then switching to a different high-rate standard once the handshaking is complete.
Given the rate limitations of Thread (I'm assuming they're similar to the limitations of the underlying 802.15.4 standard), then it really isn't solving the same problem as this new specification, but are actually complementary.
Perhaps GP meant that existing high-rate mesh implementations are vendor-specific?
Given the rate limitations of Thread (I'm assuming they're similar to the limitations of the underlying 802.15.4 standard), then it really isn't solving the same problem as this new specification, but are actually complementary.
Perhaps GP meant that existing high-rate mesh implementations are vendor-specific?
Yes, I assume GP is referring to these sorts of wifi mesh devices:
- http://www.netgear.com/orbi/
- https://eero.com/
- https://www.linksys.com/us/velop/
- https://www.engeniustech.com/whole-home-mesh-wifi.html
- https://store.plumewifi.com/
- https://www.asus.com/us/Networking/Lyra/
- https://store.google.com/product/google_wifi
- https://www.tp-link.com/us/products/details/cat-5700_Deco-M5...
Thread is neat, but you can't connect your laptop to Netflix with it. EasyMesh is clearly for standardizing those:
>Wi-Fi EasyMesh™ delivers a standards-based approach to deploying adaptable networks comprised of multiple access points from different vendors, extending uniform Wi-Fi coverage and enhancing performance throughout a larger service area than is possible with a single access point. Wi-Fi EasyMesh allows users and service providers to select interoperable devices across different brands to ensure fast, wide, and reliable Wi-Fi coverage.
- http://www.netgear.com/orbi/
- https://eero.com/
- https://www.linksys.com/us/velop/
- https://www.engeniustech.com/whole-home-mesh-wifi.html
- https://store.plumewifi.com/
- https://www.asus.com/us/Networking/Lyra/
- https://store.google.com/product/google_wifi
- https://www.tp-link.com/us/products/details/cat-5700_Deco-M5...
Thread is neat, but you can't connect your laptop to Netflix with it. EasyMesh is clearly for standardizing those:
>Wi-Fi EasyMesh™ delivers a standards-based approach to deploying adaptable networks comprised of multiple access points from different vendors, extending uniform Wi-Fi coverage and enhancing performance throughout a larger service area than is possible with a single access point. Wi-Fi EasyMesh allows users and service providers to select interoperable devices across different brands to ensure fast, wide, and reliable Wi-Fi coverage.
Yes, and notably Ubiquiti and Meraki.
We've changed the link to that from https://www.wi-fi.org/news-events/newsroom/wi-fi-certified-e.... Thanks!
For folks who can't be bothered to submit the form just to view a document: https://ipfs.io/ipfs/QmUuzZnv4aFUXnEhxZ4CwqxCxMa2nDwDwtkp5is...
How does this relate to Thread?
This seems less for meshing actual devices and more for meshing access points... Is the idea to make regular devices access points? It doesn't seem so from how it's described:
> Wi-Fi EasyMesh is a certification program that defines multiple access point home and small office Wi-Fi networks that are easy to install and use, self-adapting, and add multi-vendor interoperability. This technology brings both consumers and service providers additional flexibility in choosing Wi-Fi EasyMesh devices for home deployment.
> Wi-Fi EasyMesh uses a controller to manage the network, which consists of the controller plus additional APs, called agents. Establishing controllers to manage and coordinate activity among the agents ensures that each AP does not interfere with the other, bringing both expanded, uniform coverage and more efficient service.
I guess this doesn't proclude using additional devices as meshing access points but the spirit & animation on the page[0] seems to.
[0]: https://www.wi-fi.org/discover-wi-fi/wi-fi-easymesh
This seems less for meshing actual devices and more for meshing access points... Is the idea to make regular devices access points? It doesn't seem so from how it's described:
> Wi-Fi EasyMesh is a certification program that defines multiple access point home and small office Wi-Fi networks that are easy to install and use, self-adapting, and add multi-vendor interoperability. This technology brings both consumers and service providers additional flexibility in choosing Wi-Fi EasyMesh devices for home deployment.
> Wi-Fi EasyMesh uses a controller to manage the network, which consists of the controller plus additional APs, called agents. Establishing controllers to manage and coordinate activity among the agents ensures that each AP does not interfere with the other, bringing both expanded, uniform coverage and more efficient service.
I guess this doesn't proclude using additional devices as meshing access points but the spirit & animation on the page[0] seems to.
[0]: https://www.wi-fi.org/discover-wi-fi/wi-fi-easymesh
It doesn't relate to Thread (had to Google that). It's for what's called WiFi Mesh Networking. Extending the range of WiFi networks without the need for wired connections.
From the image in this article [1], that’s more like repeaters on steroids. I don’t see mesh routing at all.
I also would’ve liked a mandatory dedicated backhaul radio, that would work in a incompatible mode from regular Wi-Fi communication, with proper mesh routing, including multi-path link aggregation and whatnot.
[1]: https://www.heise.de/newsticker/meldung/EasyMesh-Wi-Fi-Allia...
I also would’ve liked a mandatory dedicated backhaul radio, that would work in a incompatible mode from regular Wi-Fi communication, with proper mesh routing, including multi-path link aggregation and whatnot.
[1]: https://www.heise.de/newsticker/meldung/EasyMesh-Wi-Fi-Allia...
Yes, I thought mesh was something different than a way to spread repeaters in a building. Anyway, this is cool, but if you're looking for advances in mesh networks you should try https://altheamesh.com/.
Funny, I was just thinking this afternoon that I wished FireChat's code was open source, and was poking around to see if anybody else was tackling the "chat offline with your phones" problem, especially if anybody was playing with turning phones into "network repeaters" for however messages are being relayed.
Turns out it's much more sparse than I thought. A couple people playing with brutal bluetooth only solutions. I feel like there's a lot of possibility here, and it's probably good to explore now rather than when we really, really, need it :P
Turns out it's much more sparse than I thought. A couple people playing with brutal bluetooth only solutions. I feel like there's a lot of possibility here, and it's probably good to explore now rather than when we really, really, need it :P
The Briar project is probably the most interesting project in this area. They recently released the first stable version [0] which includes bluetooth peer to peer messaging as a fallback if there is no internet connection available. WiFi peer to peer is also planned.
I would recommend listening to this presentation from ccc about the project: https://media.ccc.de/v/34c3-8937-briar
[0]https://briarproject.org/news/2018-1.0-released-new-funding....
I would recommend listening to this presentation from ccc about the project: https://media.ccc.de/v/34c3-8937-briar
[0]https://briarproject.org/news/2018-1.0-released-new-funding....
You can always count on HN to find like-minded people. Walked down the same road around 2 years ago. I think if FireChat open-sourced its mesh networking code, we could make some real progress on this. Mostly because writing a mesh networking layer is a project in itself and skipping that would go a long way.
I was thinking of using mesh networking for simple stuff at large events, like locating friends during a music festival (no cell reception).
I was thinking of using mesh networking for simple stuff at large events, like locating friends during a music festival (no cell reception).
You can check out Loud-Hailer. (Full disclosure I work there.) We enable encrypted mesh networking with a mobile app, no need to buy a device. The messaging is embedded in two different city apps we have: Columbus2GO and Providence2GO. We've created engagement points throughout the city so you can receive hyperlocal content via the BLE mesh. You can also use the apps to message friends anywhere, just need to set up permissions. We're iOS only right now, but working on Android and SDKs.
We've worked on mesh network data sync for P2P environments ( https://github.com/amark/gun ), but like others in the thread lament, vendors at the hardware level haven't been very pioneering with the tech to make it common place. Hopefully low energy Bluetooth will help that, but it has been around for years now. So I'm not keeping my fingers crossed. :(
A number of kickstarters have started to saturate this market with semi-capable meshing text-only gadgets: GoTenna, Beartooth, and Sonnet come to mind.
Can anyone that's read the spec comment on how this compares to B.A.T.M.A.N., BMX, or 802.11s?
This is basically tue marketing name for 802.11s. And what people will learn very quickly is that vanilla 802.11s is not sufficient for arbitrary network topologies. See discussion on the eero subreddit: https://www.reddit.com/r/eero/comments/8jdjlb/reposting_as_i...
This looks like it is very different from 802.11s, which involves an ad-hoc routing protocol. Easy mesh has a central controller and manages handoff of client devices.
That's really not much different. Client device handoff is something worth improving because it's poorly managed by clients normally, but that doesn't address any of the practical issues with 11s as a link layer protocol.
Surprised this mesh standard is relatively simplistic and doesn't take advantage of any commercial advancements over the last 15 years. Come on vendors, open up your old stuff. Like node skipping that Meraki did.
"Wi-Fi EasyMesh technology coordinates multiple access points ... Access points organize themselves ...
Wi-Fi EasyMesh offers both service providers and Wi-Fi users a consistent approach to multiple AP solutions"
A good start for interoperable AP's but a standard end-user device mesh is probably more useful to me.
A good start for interoperable AP's but a standard end-user device mesh is probably more useful to me.
Replaced our AirPort Extremes with the Google WiFi and could not be happier.
The GW are super easy to setup and just work really well or to steal a phrase "just work".
Will be curious to see if with a standard if you will be able to interchange nodes.
The GW are super easy to setup and just work really well or to steal a phrase "just work".
Will be curious to see if with a standard if you will be able to interchange nodes.
what happened to 802.11s, the supposed-to-be mesh protocol for a long while?
This is that.
This is technically a very different thing from 802.11s. They don’t even fulfill the same purpose. Dcow’s source is an Eero engineer on reddit apparently wanting to tar this new standard with 802.11s’s failures.
No one is trying to tar anything. A central controller for client devices doesn't change anything.
any source for this? tried to look up but failed
Good lord is it just me that thinks wifi-org needs a better technical writer - this reads as low quality google spam.
"Wi-Fi EasyMesh™ networks employ multiple access points that work together to form a unified network that provides smart, efficient Wi-Fi throughout the home and outdoor spaces."
That that is what a properly designed wifi network does - doesn't even seem to mention that its using wireless as the DS (distribution system)
"Wi-Fi EasyMesh™ networks employ multiple access points that work together to form a unified network that provides smart, efficient Wi-Fi throughout the home and outdoor spaces."
That that is what a properly designed wifi network does - doesn't even seem to mention that its using wireless as the DS (distribution system)
It reads like marketing nonsense because it is a marketing page.
Secondly the standard doesn't require using wireless as the backhaul. It can use wireless, Ethernet, powerline, MOCA or a combination of them as the backhaul for the mesh.
Secondly the standard doesn't require using wireless as the backhaul. It can use wireless, Ethernet, powerline, MOCA or a combination of them as the backhaul for the mesh.
Anyone know when these certified devices will go on sale. I need a mesh system for home, and would rather a standard than a vendor locked in solution.
Have you tried/thought about using a PoE access point?
If you're willing to overlook some GPL violations the ubiquity APs are pretty reliable/easy to setup.
If you're willing to overlook some GPL violations the ubiquity APs are pretty reliable/easy to setup.
I tried an high up in the center of the house. I just can't get full coverage at AC speeds throughout the house. I think mesh is the only way to go. Thanks for the suggestion!
[deleted]
Do you need mesh since you can't run wires?
I guess I could, but not having to sounds easier.
Wires exhibit predictable behavior.
If you can, run wires. More than you need, in case the cost of having twice as many cables as necessary is lower than lying even one additional cable to the farthest-away location.
And if you can, go for Cat.7, which allows higher speeds should those be necessary.
And don't neglect a room that could need networking in case of one more/less inhabitant is living there in the future.
And don't neglect a room that could need networking in case of one more/less inhabitant is living there in the future.
For many more mesh technologies beyond those mentioned here:
https://en.m.wikipedia.org/wiki/Wireless_mesh_network
2017 https://news.ycombinator.com/item?id=15797079
2004 https://m.slashdot.org/story/47393
https://en.m.wikipedia.org/wiki/Wireless_mesh_network
2017 https://news.ycombinator.com/item?id=15797079
2004 https://m.slashdot.org/story/47393
[deleted]
I am too lazy to read the full spec, but does it allow to have a mix of wired/wireless APs in the mesh? For example, I have a couple of rooms with wired ethernet which would act as a backbone of wireless mesh I am building. Google WiFi allows that.
How does it relate to Zigbee https://en.wikipedia.org/wiki/Zigbee? Is it mostly that Zigbee is for low power devices and this for the rest?
Zigbee is a vastly lower range and bandwidth protocol. Suitable for low power sensor networks; not media devices.
> Zigbee has a defined rate of 250 kbit/s, best suited for intermittent data transmissions from a sensor or input device.
> Zigbee has a defined rate of 250 kbit/s, best suited for intermittent data transmissions from a sensor or input device.
Zigbee requires master/listener channel subscriptions for devices, I'm not clear how you could do that without fixed masters.
Seems to yet again only caring about the lower 3-4 layers of the stack, leaving the vendors to squabble over how devices are to find each other (if this is even meant as a p2p thing, and not just a continuation of repeaters).
So this is for home IoT only, but not for say a neighborhood Wi-Fi meshnet?
I never got time around to understand mesh, how is it different then good old wifi extension like apple airport express, ubnt, and many others had.
With more radios access points can be more clever about how frames are forwarded. Instead of everything happening on one channel resulting in a drop in bandwidth as new each extender is added, APs have freedom to choose the best way to forward frames while logically still participating in the same client facing network.
Meh, http://radiomesh.org is where it's at! ;)
Is it developed at all yet? Interesting idea... but the site doesn't seem to have any links or hardly any information at all.
Is there something I am missing?
Is there something I am missing?
No, you are completely right, it's just an idea so far...
Working on the hardware now, just received pogo pins: http://move.rupy.se/file/pogo_pins_final.png
But need a better screen and Eagle sucks so I'm going the long route and building my own Gerber editor to design my own pHAT! Xo
Ideas are easy, implementation is _hard_!
But it will be based on top of this source: https://github.com/tinspin/rupy
Working on the hardware now, just received pogo pins: http://move.rupy.se/file/pogo_pins_final.png
But need a better screen and Eagle sucks so I'm going the long route and building my own Gerber editor to design my own pHAT! Xo
Ideas are easy, implementation is _hard_!
But it will be based on top of this source: https://github.com/tinspin/rupy
All the power to you, bullen!!!
Seriously... I think this is an amazing project idea to follow... I have dreampt about it for years myself...
Godspeed!
Seriously... I think this is an amazing project idea to follow... I have dreampt about it for years myself...
Godspeed!
Radiomesh looks super cool! Looks like you/they made very specific choices in deciding the initial features and setting up the nodes to be interactive and with some level of feedback (via joystick hat). I am now curious for more info! Where does this project go next? Thanks for sharing.
[deleted]
Why not expand the capability of Freifunk to work on more channels, and include neighborhood detection based on BSSID readings, where all BSSIDs are used, not just those belonging to the mesh?
AFAIK the main issue there is that common firmware lacks support for multiple simultaneous connections using the same radio but different channels. The system would need to negotiate time slots between the channels, as a single radio can't be active on more than one channel, while all channels can be active in the same collision domain simultaneously.
Note that this is not just to prevent multiple senders to co-occupy a single channel as CSMA/CA does, but to prevent a receiver listening to another channel or sending to another channel during the transmission. That way the packet would just be 'lost'.
For meshes of sufficiently small size, they could also buffer packets of higher-throughput links through the mesh (defined by whether the following optimization is worth it, or if it should just use regular, BATMAN-adv style, packet passing towards the destination during the time slot for general nodeA to nodeB traffic), and negotiate explicit bandwidth for them, possibly making use of multi-path intra-mesh routing if necessary to prevent buffer backlog and unutilized bandwidth on a path between the nodes this buffer held traffic for. This might be done in a hierarchical fashion, to only consider area targeting during the calculations for intra-node traffic, or, perhaps use e.g. raft/paxos to map between mac addresses and small integers, in order to reduce the size of communication necessary for telling other nodes about the amount of data in pending buffers. Nodes would use PHY-broadcasting to their neighbors, which would then be followed by the receivers sending ACKs on a negotiated/inferred timeslot-raster, to prevent unnecessary airtime utilisation. Nodes would set their bitrate during those broadcasts to be just enough for those neighbours to receive which even need the data, potentially using unicast if the other neighbours don't need it. Receivers could infer their ACK time slot from the data, which would ensure that the whole ACK raster is just as long as needed. Nodes could possibly aggregate this data (which btw consists of source, target, length-prefixed bytecount (where the latter would sacrifice the first 3 bits of the first byte holding the bytecount to denote how many bytes will follow, and source/target having just as many bits as necessary to represent the maximum ID as negotiated by raft/paxos) and is therefore to be decoded with bit-offsets) over multiple cycles, to reduce the overhead of sending one such block. They would have to wait no longer than (max_aggregation ratio * longest_path), or just kick a downstream node out of this round of discovery, if transmission to it fails more than a pre-defined number of retries. This is to ensure that all nodes of the mesh that send on the mesh-channels agree on what traffic will flow.
This would include data without ACKs stuck on intermediate hops. If the data is too small for an individual link, it could either be shared with the negotiation step, or for purposes of negotiation it could be counted as "towards a region (measured by node's vicinity)", where those regions would be periodically defined via raft/paxos and allocated IDs out of the same range as nodes. This periodic definition should include tallies of recent data flows, possibly by just periodically transmitting a non-grouped view of dataflows between nodes, aggregated over the time since the last one. User-data forwarding and management communication could easily be interleaved, in order to reduce the delay for small, persistent channels (as something like VoIP could easily be seen as a constant stream of data and, properly QoS tagged, retransmits could be handled by the network more aggressively than usual, at a cost of higher actual bandwidth due to e.g. a lower bitrate being chosen (SNR), or some retransmits being figured in), as well as the impact of inherent delay figures of the process-and-forward bandwidth negotiation on a node's utilisation during that time. It should be possible to find a way around time slot allocations being unused due to the dynamic process of bandwidth negotiations not playing well with the fixed allocations necessary for using more channels with a node than it has channels.
If I didn't have better to do, I'd probably consider dabbling into this a little deeper, probably with ath9k devices (AR9280 seems to be a good candidate) and the open-source baseband, but I've allocated the time for other open-source things.
AFAIK the main issue there is that common firmware lacks support for multiple simultaneous connections using the same radio but different channels. The system would need to negotiate time slots between the channels, as a single radio can't be active on more than one channel, while all channels can be active in the same collision domain simultaneously.
Note that this is not just to prevent multiple senders to co-occupy a single channel as CSMA/CA does, but to prevent a receiver listening to another channel or sending to another channel during the transmission. That way the packet would just be 'lost'.
For meshes of sufficiently small size, they could also buffer packets of higher-throughput links through the mesh (defined by whether the following optimization is worth it, or if it should just use regular, BATMAN-adv style, packet passing towards the destination during the time slot for general nodeA to nodeB traffic), and negotiate explicit bandwidth for them, possibly making use of multi-path intra-mesh routing if necessary to prevent buffer backlog and unutilized bandwidth on a path between the nodes this buffer held traffic for. This might be done in a hierarchical fashion, to only consider area targeting during the calculations for intra-node traffic, or, perhaps use e.g. raft/paxos to map between mac addresses and small integers, in order to reduce the size of communication necessary for telling other nodes about the amount of data in pending buffers. Nodes would use PHY-broadcasting to their neighbors, which would then be followed by the receivers sending ACKs on a negotiated/inferred timeslot-raster, to prevent unnecessary airtime utilisation. Nodes would set their bitrate during those broadcasts to be just enough for those neighbours to receive which even need the data, potentially using unicast if the other neighbours don't need it. Receivers could infer their ACK time slot from the data, which would ensure that the whole ACK raster is just as long as needed. Nodes could possibly aggregate this data (which btw consists of source, target, length-prefixed bytecount (where the latter would sacrifice the first 3 bits of the first byte holding the bytecount to denote how many bytes will follow, and source/target having just as many bits as necessary to represent the maximum ID as negotiated by raft/paxos) and is therefore to be decoded with bit-offsets) over multiple cycles, to reduce the overhead of sending one such block. They would have to wait no longer than (max_aggregation ratio * longest_path), or just kick a downstream node out of this round of discovery, if transmission to it fails more than a pre-defined number of retries. This is to ensure that all nodes of the mesh that send on the mesh-channels agree on what traffic will flow.
This would include data without ACKs stuck on intermediate hops. If the data is too small for an individual link, it could either be shared with the negotiation step, or for purposes of negotiation it could be counted as "towards a region (measured by node's vicinity)", where those regions would be periodically defined via raft/paxos and allocated IDs out of the same range as nodes. This periodic definition should include tallies of recent data flows, possibly by just periodically transmitting a non-grouped view of dataflows between nodes, aggregated over the time since the last one. User-data forwarding and management communication could easily be interleaved, in order to reduce the delay for small, persistent channels (as something like VoIP could easily be seen as a constant stream of data and, properly QoS tagged, retransmits could be handled by the network more aggressively than usual, at a cost of higher actual bandwidth due to e.g. a lower bitrate being chosen (SNR), or some retransmits being figured in), as well as the impact of inherent delay figures of the process-and-forward bandwidth negotiation on a node's utilisation during that time. It should be possible to find a way around time slot allocations being unused due to the dynamic process of bandwidth negotiations not playing well with the fixed allocations necessary for using more channels with a node than it has channels.
If I didn't have better to do, I'd probably consider dabbling into this a little deeper, probably with ath9k devices (AR9280 seems to be a good candidate) and the open-source baseband, but I've allocated the time for other open-source things.
Bluetooth 1.0 in 2002 with support from the Palm Pilot, to give you a sense of how long ago that was technologically, already had this dream and implemented a Personal Area Network using 'scatternet'.
Probably the single largest blow to the dream of meshed devices everywhere, imho, was Apple's decision to limit the iPhone's (2007) bluetooth support to headset-only when bluetooth was capable of so much more. Admittedly there was probably substantial pressure from the carriers who were scared of the idea of phones communicating with out being mediated/dependent on cell tower infrasructure, but its one thing I cannot forgive apple for. The other phone vendors fell into line.
Android 4.0 (2011) implemented Wifi peer-to-peer, which the Wifi Alliance called "Wifi Direct" that would allow for Personal Area Networks using existing wifi hardware.
[1] https://developer.android.com/guide/topics/connectivity/wifi... [2] https://en.wikipedia.org/wiki/Wi-Fi_Direct
Now that bluetooth has returned to its roots with Bluetooth Low Energy, maybe we have another chance at flash-mob mobile gaming - everyone on the same bus can join in to a chatroom or a roleplaying game for the duration of the ride.