9 ms·

Wi-Fi alliance announces mesh networking standard

295 points by jwilliams 8y ago

nathancahill 8y ago
Called EasyMesh. A better link with more info than the press release: https://www.wi-fi.org/discover-wi-fi/wi-fi-easymesh 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_Technical_Specification-171212.pdf/35043 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.
- scarface74 8y ago
  Why is it nice that it 802.11ac is optional?
  - steve19 8y ago
    I guess he means shorter range AC is not required by client and/or mesh devices.
  - nathancahill 8y ago
    A vast amount of devices in the world don't support 802.11ac.
- mrb 8y ago
  «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 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.
  - gervase 8y ago
    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?
    - wlesieutre 8y ago
      Yes, I assume GP is referring to these sorts of wifi mesh devices: - http://www.netgear.com/orbi/ http://www.netgear.com/orbi/ - https://eero.com/ https://eero.com/ - https://www.linksys.com/us/velop/ https://www.linksys.com/us/velop/ - https://www.engeniustech.com/whole-home-mesh-wifi.html https://www.engeniustech.com/whole-home-mesh-wifi.html - https://store.plumewifi.com/ https://store.plumewifi.com/ - https://www.asus.com/us/Networking/Lyra/ https://www.asus.com/us/Networking/Lyra/ - https://store.google.com/product/google_wifi https://store.google.com/product/google_wifi - https://www.tp-link.com/us/products/details/cat-5700_Deco-M5.html 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.
      - nathancahill 8y ago
        Yes, and notably Ubiquiti and Meraki.
  - bipson 8y ago
    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.
- dang 8y ago
  We've changed the link to that from https://www.wi-fi.org/news-events/newsroom/wi-fi-certified-easymesh-delivers-intelligent-wi-fi-networks https://www.wi-fi.org/news-events/newsroom/wi-fi-certified-e.... Thanks!
- diggan 8y ago
  For folks who can't be bothered to submit the form just to view a document: https://ipfs.io/ipfs/QmUuzZnv4aFUXnEhxZ4CwqxCxMa2nDwDwtkp5is7DpEhHm/Multi-AP_Technical_Specification-171212.pdf https://ipfs.io/ipfs/QmUuzZnv4aFUXnEhxZ4CwqxCxMa2nDwDwtkp5is...
steve19 8y ago
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.
- NegativeLatency 8y ago
  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.
  - steve19 8y ago
    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 8y ago
      [deleted]
    - kalleboo 8y ago
      Do you need mesh since you can't run wires?
      - steve19 8y ago
        I guess I could, but not having to sounds easier.
        namibj 8y ago
        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.
camel_gopher 8y ago
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.
hardwaresofton 8y ago
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 https://www.wi-fi.org/discover-wi-fi/wi-fi-easymesh
- rconti 8y ago
  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.
ausjke 8y ago
what happened to 802.11s, the supposed-to-be mesh protocol for a long while?
- dcow 8y ago
  This is that.
  - ausjke 8y ago
    any source for this? tried to look up but failed
  - woah 8y ago
    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.
    - dcow 8y ago
      No one is trying to tar anything. A central controller for client devices doesn't change anything.
tony-allan 8y ago
"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.
komali2 8y ago
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
- goatsi 8y ago
  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 https://media.ccc.de/v/34c3-8937-briar [0]https://briarproject.org/news/2018-1.0-released-new-funding.html https://briarproject.org/news/2018-1.0-released-new-funding....
- marknadal 8y ago
  We've worked on mesh network data sync for P2P environments ( https://github.com/amark/gun 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. :(
- eerikkivistik 8y ago
  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).
- kawfey 8y ago
donpdonp 8y ago
another mesh standard. 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/wifip2p https://developer.android.com/guide/topics/connectivity/wifi... [2] https://en.wikipedia.org/wiki/Wi-Fi_Direct 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.
- rvanmil 8y ago
  Available since iOS 7 https://developer.apple.com/documentation/multipeerconnectivity https://developer.apple.com/documentation/multipeerconnectiv...
- _wmd 8y ago
  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"
  - dijit 8y ago
    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.
jeena 8y ago
How does it relate to Zigbee https://en.wikipedia.org/wiki/Zigbee https://en.wikipedia.org/wiki/Zigbee? Is it mostly that Zigbee is for low power devices and this for the rest?
- loeg 8y ago
  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.
- Already__Taken 8y ago
  Zigbee requires master/listener channel subscriptions for devices, I'm not clear how you could do that without fixed masters.
bullen 8y ago
Meh, http://radiomesh.org http://radiomesh.org is where it's at! ;)
- flyGuyOnTheSly 8y ago
  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?
  - bullen 8y ago
    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 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 https://github.com/tinspin/rupy
    - flyGuyOnTheSly 8y ago
      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!
- jonnydubowsky 8y ago
  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.
voxadam 8y ago
Can anyone that's read the spec comment on how this compares to B.A.T.M.A.N., BMX, or 802.11s?
- dcow 8y ago
  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_interesting_wonder_what_this_means/ https://www.reddit.com/r/eero/comments/8jdjlb/reposting_as_i...
  - woah 8y ago
    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.
    - dcow 8y ago
      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.
ksec 8y ago
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.
- dcow 8y ago
  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.
deleted 8y ago
[deleted]
mtgx 8y ago
So this is for home IoT only, but not for say a neighborhood Wi-Fi meshnet?
fuzzy2 8y ago
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-Alliance-zertifiziert-jetzt-Mesh-WLAN-Systeme-4047177.html https://www.heise.de/newsticker/meldung/EasyMesh-Wi-Fi-Allia...
- fiatjaf 8y ago
  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/ https://altheamesh.com/.
digi_owl 8y ago
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).
jacksmith21006 8y ago
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.
walshemj 8y ago
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)
- tssva 8y ago
  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.
mkstowegnv 8y ago
For many more mesh technologies beyond those mentioned here: https://en.m.wikipedia.org/wiki/Wireless_mesh_network https://en.m.wikipedia.org/wiki/Wireless_mesh_network 2017 https://news.ycombinator.com/item?id=15797079 https://news.ycombinator.com/item?id=15797079 2004 https://m.slashdot.org/story/47393 https://m.slashdot.org/story/47393
vzaliva 8y ago
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.
deleted 8y ago
[deleted]
namibj 8y ago
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.

295 points by jwilliams 8y ago

Called EasyMesh. A better link with more info than the press release: https://www.wi-fi.org/discover-wi-fi/wi-fi-easymesh 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_Technical_Specification-171212.pdf/35043 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.

scarface74 8y ago
Why is it nice that it 802.11ac is optional?
- steve19 8y ago
  I guess he means shorter range AC is not required by client and/or mesh devices.
- nathancahill 8y ago
  A vast amount of devices in the world don't support 802.11ac.
mrb 8y ago
«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 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.
- gervase 8y ago
  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?
  - wlesieutre 8y ago
    Yes, I assume GP is referring to these sorts of wifi mesh devices: - http://www.netgear.com/orbi/ http://www.netgear.com/orbi/ - https://eero.com/ https://eero.com/ - https://www.linksys.com/us/velop/ https://www.linksys.com/us/velop/ - https://www.engeniustech.com/whole-home-mesh-wifi.html https://www.engeniustech.com/whole-home-mesh-wifi.html - https://store.plumewifi.com/ https://store.plumewifi.com/ - https://www.asus.com/us/Networking/Lyra/ https://www.asus.com/us/Networking/Lyra/ - https://store.google.com/product/google_wifi https://store.google.com/product/google_wifi - https://www.tp-link.com/us/products/details/cat-5700_Deco-M5.html 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.
    - nathancahill 8y ago
      Yes, and notably Ubiquiti and Meraki.
- bipson 8y ago
  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.
dang 8y ago
We've changed the link to that from https://www.wi-fi.org/news-events/newsroom/wi-fi-certified-easymesh-delivers-intelligent-wi-fi-networks https://www.wi-fi.org/news-events/newsroom/wi-fi-certified-e.... Thanks!
diggan 8y ago
For folks who can't be bothered to submit the form just to view a document: https://ipfs.io/ipfs/QmUuzZnv4aFUXnEhxZ4CwqxCxMa2nDwDwtkp5is7DpEhHm/Multi-AP_Technical_Specification-171212.pdf https://ipfs.io/ipfs/QmUuzZnv4aFUXnEhxZ4CwqxCxMa2nDwDwtkp5is...

steve19 8y ago

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.

NegativeLatency 8y ago
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.
- steve19 8y ago
  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 8y ago
    [deleted]
  - kalleboo 8y ago
    Do you need mesh since you can't run wires?
    - steve19 8y ago
      I guess I could, but not having to sounds easier.
      - namibj 8y ago
        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.

camel_gopher 8y ago

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.

hardwaresofton 8y ago

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 https://www.wi-fi.org/discover-wi-fi/wi-fi-easymesh

rconti 8y ago
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.

ausjke 8y ago

what happened to 802.11s, the supposed-to-be mesh protocol for a long while?

dcow 8y ago
This is that.
- ausjke 8y ago
  any source for this? tried to look up but failed
- woah 8y ago
  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.
  - dcow 8y ago
    No one is trying to tar anything. A central controller for client devices doesn't change anything.

tony-allan 8y ago

"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.

komali2 8y ago

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

goatsi 8y ago
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 https://media.ccc.de/v/34c3-8937-briar [0]https://briarproject.org/news/2018-1.0-released-new-funding.html https://briarproject.org/news/2018-1.0-released-new-funding....
marknadal 8y ago
We've worked on mesh network data sync for P2P environments ( https://github.com/amark/gun 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. :(
eerikkivistik 8y ago
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).
kawfey 8y ago

donpdonp 8y ago

another mesh standard. 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/wifip2p https://developer.android.com/guide/topics/connectivity/wifi... [2] https://en.wikipedia.org/wiki/Wi-Fi_Direct 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.

rvanmil 8y ago
Available since iOS 7 https://developer.apple.com/documentation/multipeerconnectivity https://developer.apple.com/documentation/multipeerconnectiv...
_wmd 8y ago
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"
- dijit 8y ago
  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.

jeena 8y ago

How does it relate to Zigbee https://en.wikipedia.org/wiki/Zigbee https://en.wikipedia.org/wiki/Zigbee? Is it mostly that Zigbee is for low power devices and this for the rest?

loeg 8y ago
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.
Already__Taken 8y ago
Zigbee requires master/listener channel subscriptions for devices, I'm not clear how you could do that without fixed masters.

bullen 8y ago

Meh, http://radiomesh.org http://radiomesh.org is where it's at! ;)

flyGuyOnTheSly 8y ago
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?
- bullen 8y ago
  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 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 https://github.com/tinspin/rupy
  - flyGuyOnTheSly 8y ago
    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!
jonnydubowsky 8y ago
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.

voxadam 8y ago

Can anyone that's read the spec comment on how this compares to B.A.T.M.A.N., BMX, or 802.11s?

dcow 8y ago
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_interesting_wonder_what_this_means/ https://www.reddit.com/r/eero/comments/8jdjlb/reposting_as_i...
- woah 8y ago
  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.
  - dcow 8y ago
    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.

ksec 8y ago

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.

dcow 8y ago
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.

deleted 8y ago

[deleted]

mtgx 8y ago

So this is for home IoT only, but not for say a neighborhood Wi-Fi meshnet?

fuzzy2 8y ago

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-Alliance-zertifiziert-jetzt-Mesh-WLAN-Systeme-4047177.html https://www.heise.de/newsticker/meldung/EasyMesh-Wi-Fi-Allia...

fiatjaf 8y ago
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/ https://altheamesh.com/.

digi_owl 8y ago

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).

jacksmith21006 8y ago

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.

walshemj 8y ago

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)

tssva 8y ago
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.

mkstowegnv 8y ago

For many more mesh technologies beyond those mentioned here: https://en.m.wikipedia.org/wiki/Wireless_mesh_network https://en.m.wikipedia.org/wiki/Wireless_mesh_network 2017 https://news.ycombinator.com/item?id=15797079 https://news.ycombinator.com/item?id=15797079 2004 https://m.slashdot.org/story/47393 https://m.slashdot.org/story/47393

vzaliva 8y ago

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.

deleted 8y ago

[deleted]

namibj 8y ago

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.