Wi-Fi alliance announces mesh networking standard

https://www.wi-fi.org/discover-wi-fi/wi-fi-easymesh

by jwilliams • 8 years ago

295 83 8 years ago

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.

scarface74• 8 years ago

Why is it nice that it 802.11ac is optional?

steve194• 8 years ago

I guess he means shorter range AC is not required by client and/or mesh devices.

nathancahill3• 8 years ago

A vast amount of devices in the world don't support 802.11ac.

mrb• 8 years 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 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• 8 years 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?

bipson2• 8 years 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• 8 years ago

We've changed the link to that from https://www.wi-fi.org/news-events/newsroom/wi-fi-certified-e.... Thanks!

diggan• 8 years ago

For folks who can't be bothered to submit the form just to view a document: https://ipfs.io/ipfs/QmUuzZnv4aFUXnEhxZ4CwqxCxMa2nDwDwtkp5is...

steve194• 8 years 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• 8 years 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.

steve194• 8 years 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!

camel_gopher• 8 years 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• 8 years 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

rconti• 8 years 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.

ausjke2• 8 years ago

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

dcow5• 8 years ago

This is that.

ausjke2• 8 years ago

any source for this? tried to look up but failed

woah3• 8 years 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.

tony-allan• 8 years 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• 8 years 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• 8 years 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

[0]https://briarproject.org/news/2018-1.0-released-new-funding....

marknadal• 8 years ago

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. :(

eerikkivistik• 8 years 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• 8 years ago

A number of kickstarters have started to saturate this market with semi-capable meshing text-only gadgets: GoTenna, Beartooth, and Sonnet come to mind.

jccmec• 8 years ago

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.

donpdonp• 8 years 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/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.

rvanmil• 8 years ago

Available since iOS 7 https://developer.apple.com/documentation/multipeerconnectiv...

_wmd2• 8 years 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• 8 years 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.

pathseeker• 8 years ago

Holding a stack that can handle losses (TCP/IP) to the same standards as bluetooth audio is silly.

white-flame• 8 years ago

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.

Willson50• 8 years ago

Yes. Even the original DS had this with pictochat.

jankotek• 8 years ago

flash-mob mobile gaming - everyone on the same bus can join

This can be already delivered without mesh networking. Too many privacy issues.

viraptor• 8 years ago

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.

digi_owl4• 8 years ago

And you still have to hope the two devices have a sane protocol between them to layer on top of the wifi...

digi_owl4• 8 years ago

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.

bipson2• 8 years ago

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.

zmb_• 8 years ago

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

ahartmetz• 8 years ago

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.

whitingx• 8 years ago

another mesh standard

Standards!

https://m.xkcd.com/927/ ;)

woah3• 8 years ago

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

ProphetZarquon3• 8 years ago

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.

lend000• 8 years ago

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.

jeena• 8 years ago

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?

loeg• 8 years 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• 8 years ago

Zigbee requires master/listener channel subscriptions for devices, I'm not clear how you could do that without fixed masters.

bullen2• 8 years ago

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

flyGuyOnTheSly2• 8 years 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?

bullen2• 8 years 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

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

jonnydubowsky• 8 years 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• 8 years ago

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

dcow5• 8 years 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_i...

woah3• 8 years 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.

ksec• 8 years 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.

dcow5• 8 years 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.

mtgx• 8 years ago

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

fuzzy2• 8 years 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-Allia...

fiatjaf• 8 years 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/.

digi_owl4• 8 years 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• 8 years 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• 8 years 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• 8 years 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• 8 years ago

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

vzaliva• 8 years 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.

namibj2• 8 years 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.

Wi-Fi alliance announces mesh networking standard

Related Stories