Close

Deciding on the Underlying Architecture

A project log for Hardware-orientated mesh networks

Our attempts to create a mesh network, plug-'n'-play product.

connorwood71connorwood71 06/19/2014 at 14:550 Comments

This project is all about ease of use - it should be fast to deploy, deployable by nearly anybody, and not have software stacks that reach to the sky. So, how best to do this? We decided pretty early on that we wanted to support 802.11s, the IEEE standard for mesh networks. This, of course, meant supporting one of the underlying protocols as well; we decided 802.11b/g was the way to go. The reason for this was that this is only an early iteration, and 802.11n would be overkill. We can always go back and change it later.

So, now that we've decided on the standard, next we need a way of connecting it to a computer. After all, what's the point in setting up a network if nothing can connect to it? We evaluated using Ethernet, USB, and PCI(e) for this, and decided on USB. Each has their benefits and drawbacks, but USB seems to be the most widely accessible, although it will require a bit more code. Factors that went into this decision were - how much code has to be written to support it. How widely implemented is it? Can we draw power from the bus, and if so, how much? USB seemed to best suit our needs.

Now, we need an actual architecture. Three designs exist here as well - using a microcontroller, using an FPGA, and using an embedded ARM computer. Of course, using the embedded ARM computer means that we still have massive software stacks, and difficulty implementing, however the burden is now on us, not the end user. A microcontroller is relatively easy to set up, but rather slow, and furthermore will not have prewritten software that can be used. The FPGA will easily be fast enough to shoulder 100% utilization of the net, but again will require a lot of custom code. Running some back-of-the-envelope calculations indicated that around 2400kframe/s would need to be handled and routed, give or take, meaning that an ARM processor should be able to run easily, and means that much less work has to be done - 802.11s already exists in the Linux kernel, and all the support software needing to go on the stack already exists too! Furthermore, Linux already has a BPF interpreter coded in.

Discussions