Wi-Fi alliance announces mesh networking standard
wi-fi.org
wi-fi.org
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.
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.
Wi-Fi Direct is nothing more than running (e.g., 802.11n) software AP with WPS on one device ("Group Owner") and having (multiple) peers connect to it to form a "group" -- it's just a normal AP, you can even connect legacy Wi-Fi devices to it. It does add functionality to automatically negotiate which device becomes the access point and to do some service discovery on the link layer before connecting.
The problem with WiFi Direct is that all its local mobile-to-mobile capabilities are disabled if the group doesn't have a node connected to a tower at all times. For example, you can't have three devices up in the mountains exchange files or messages, unless one of them can get the OK from a service provider's tower. WiFi Direct stops as soon as you lose cellular signal or experience a service timeout. It's crippled by design.
EasyMesh doesn't seem to offer any neighbor-to-neighbor utility; It appears to be focused solely on expanding coverage of single-point-of-control networks which are already overcrowded (hence the need for so many range extenders). When are we not in range of half a dozen or more WiFi networks?
I see adding more APs as an exercise in futility. The primary issue is overcrowding, not signal strength. Remove all the other nearby networks & one router easily reaches across most buildings.
Sorry, I guess that's two topics in one comment, but I'll repeat my primary question: In what way are these different approaches "completely" different? They seem to all be chasing roughly the same goal. I also feel that "mesh" has stagnated due to lack of hardware support (& accompanying lack of open source firmware).
I'M SORRY! I was thinking of LTE Direct, which is crippled by design. Please disregard my statement about "WiFi Direct" needing a cellular tower.
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"
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.
Assuming audio between 2 peers at 1 meter was somehow a solved problem (per above it's not), and collision avoidance was a non-issue (problem worsens exponentially with additional peers), that's 1.16KB/sec in some idealized non-existent reality of bandwidth to run a compelling game for 62 people. Perhaps parent comment refers to a flash mob game of Chess.
Assuming Bluetooth only reliably fails between two peers 1% of the time (oh, but to dream), that's a 99%^62 = 5.36% chance of a bus full of people successfully joining a single mesh.
Silliness is in the eye of the beholder!
Out by an order of magnitude but your point still stands.
Note that the Nintendo 3DS effectively has this capability. I believe it's all WiFi-based.
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.
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.
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”.
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.
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.
Standards!
This can be already delivered without mesh networking. Too many privacy issues.
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.
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.
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?
- http://www.netgear.com/orbi/
- https://www.linksys.com/us/velop/
- https://www.engeniustech.com/whole-home-mesh-wifi.html
- https://store.plumewifi.com/
- https://www.asus.com/us/Networking/Lyra/
- https://store.google.com/product/google_wifi
- https://www.tp-link.com/us/products/details/cat-5700_Deco-M5...
Thread is neat, but you can't connect your laptop to Netflix with it. EasyMesh is clearly for standardizing those:
>Wi-Fi EasyMesh™ delivers a standards-based approach to deploying adaptable networks comprised of multiple access points from different vendors, extending uniform Wi-Fi coverage and enhancing performance throughout a larger service area than is possible with a single access point. Wi-Fi EasyMesh allows users and service providers to select interoperable devices across different brands to ensure fast, wide, and reliable Wi-Fi coverage.
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.
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.
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...
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
I would recommend listening to this presentation from ccc about the project: https://media.ccc.de/v/34c3-8937-briar
[0]https://briarproject.org/news/2018-1.0-released-new-funding....
I was thinking of using mesh networking for simple stuff at large events, like locating friends during a music festival (no cell reception).
A good start for interoperable AP's but a standard end-user device mesh is probably more useful to me.
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.
"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)
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.
If you're willing to overlook some GPL violations the ubiquity APs are pretty reliable/easy to setup.
And don't neglect a room that could need networking in case of one more/less inhabitant is living there in the future.
https://en.m.wikipedia.org/wiki/Wireless_mesh_network
> Zigbee has a defined rate of 250 kbit/s, best suited for intermittent data transmissions from a sensor or input device.
Is there something I am missing?
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
Seriously... I think this is an amazing project idea to follow... I have dreampt about it for years myself...
Godspeed!
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.