
Wi-Fi alliance announces mesh networking standard - jwilliams
https://www.wi-fi.org/discover-wi-fi/wi-fi-easymesh
======
donpdonp
_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...](https://developer.android.com/guide/topics/connectivity/wifip2p)
[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.

~~~
_wmd
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
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.

~~~
digi_owl
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.

------
nathancahill
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_Te...](https://www.wi-
fi.org/downloads-registered-guest/Multi-
AP_Technical_Specification-171212.pdf/35043)

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.

~~~
mrb
« _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
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
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...](https://www.tp-
link.com/us/products/details/cat-5700_Deco-M5.html)

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
Yes, and notably Ubiquiti and Meraki.

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

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

~~~
fiatjaf
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/).

------
komali2
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
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....](https://briarproject.org/news/2018-1.0-released-new-funding.html)

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

~~~
dcow
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...](https://www.reddit.com/r/eero/comments/8jdjlb/reposting_as_interesting_wonder_what_this_means/)

~~~
woah
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
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.

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

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

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

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

~~~
dcow
This is that.

~~~
woah
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
No one is trying to tar anything. A central controller for client devices
doesn't change anything.

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

------
steve19
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
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
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!

~~~
kalleboo
Do you need mesh since you can't run wires?

~~~
steve19
I guess I could, but not having to sounds easier.

~~~
namibj
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.

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

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

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

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

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

------
bullen
Meh, [http://radiomesh.org](http://radiomesh.org) is where it's at! ;)

~~~
flyGuyOnTheSly
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
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
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!

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

