Over recent years there has been a flurry of new devices and solutions aimed at the wireless network space; perhaps the most prevalent has been LocustWorld with its almost turnkey community-network in a box solution. Like many of these solutions, the design decisions appear to have been made on the basis that wireless is somehow different from other network systems, and that mesh networks are new. To an old-school network architect this will seem daft, but the growth of wireless mesh networks seems only to match the decline in the number of network architects. 

So is LocustWorld an example of good network architecture?

This essay explores whether wireless mesh networks really are different. Contact us if you'd like to know more.

Good Architecture?

The design of a network, like any thing, begins with a requirement which is then introduced to the limitations of the medium – good architecture optimises the trade-off, resulting in a creative design which at least meets the requirement within safe working limits.

The core market for solutions like LocustWorld are communities with either no access to mainstream broadband services, or where they need more control over the broadband environment than is typically afforded by mainstream operators. So the solution needs to have, as a minimum, many of the characteristics of a public broadband network, but it also needs to be simpler to manage and control.

Clearly digging the road to lay a new land-line technology is beyond the pockets of most communities, so wireless is a good medium. Further, wifi technology is low-cost and accessible – so there can be few arguments over the choice of physical medium.

What identifies a wireless network?

Apart from a singular lack of wires, what are the characteristics which define a wireless network?

When the 802.11b standard was drawn up, it took as the starting point wired Ethernet, and then – after asking the same question – adapted it to a life without wires. The core difference is that an Ethernet manager can largely control the environment within a cable, and can provide unique and solitary access; this is not possible in a wireless environment unless its built inside a lead-lined Faraday cage. Any number of similar networks in close proximity may have to share the airwaves, and natural events may cause further interference.

The resulting wifi standards are a good compromise between the requirement to build a network without wires, and the limitation of the medium. But its not perfect – while the network is pretty good at sharing, and is able to recover from many forms of interference, its not perfect and these imperfections affect the way the network behaves and needs to be managed. For example, its simply not possible to offer anything approaching the five-nines (99.999%) availability expected by telephone network, and connections may be periodically dropped as interference comes and goes – and this is not simply a boolean up-down status, but one where bandwidth and latency can vary almost organically.

A router of choice

What characteristics does a routing protocol have to demonstrate to offer a balance between the requirement to deliver a carrier-class network, and the limitations inherent in wireless technology. Firstly it needs to be dynamic – manually developing static routes across a network is both complex and rigid, forcing the network to simply stand-by and watch as performance waivers.

Beyond that, it needs to develop a picture of the network which understands things like latency or bandwidth, and not simply the smallest number of hops across the network. This normally rules out distance vector protocols like RIP and AODV, instead favouring link-state protocols. However, LocustWorld has opted for AODV as the routing protocol of choice. Does this matter?

Ad hoc On-Demand Distance Vector Routing (AODV), as the name suggests, is a reactive protocol which makes routing decisions based on the number of hops to a given point. This approach can have ramifications which may manifest themselves in a number of ways:

1. Firstly, the on-demand element means that it only develops a route across the network when it has a request, and only maintains a route so long as the conversation continues. This can cause a delay in passing traffic while it seeks suitable routes which will be most noticeable in interactive multimedia applications.

2. The route discovery process floods the network with requests, and replies are sent back from all nodes with an interest in the route. This can create sudden bursts of traffic on the network which may further disrupt jitter-sensitive protocols such as VoIP.

3. In a busy or unstable network, the discovery process becomes inefficient – routes are not maintained and the discovery responses are unicasted so other nodes which may benefit from the discovery process are blind, possibly duplicating the process.

4. Routing decisions are based on the distance vector, or number of hops, to the destination. Because it picks routes at one point in time and doesn't maintain routing information, its becomes impossible to detect jittery or high-latency routes. For example, if there are two possible routes to a destination, one using three 10 Gbps fibre-optic hops and another using a jittery 1 Mbps wireless hop, the slow link will be preferred by default.

Compare this with a pro-active link-state protocol such as OLSR:

1. Being a proactive protocol, it constantly maintains all possible routes across the network. This ensures there is minimal delay in setting up a path, allowing time sensitive data, such as VoIP, to be sent quickly.

2. While the proactive model creates a constant flow of data, the efficient manner means it is little more than a trickle, while the predictable and even nature of the flow lends itself better to sensitive interactive multimedia applications.

3. By optimising the route discovery process, the overhead does not become invasive in a busy or unstable network.

4. Link hysteresis is a mechanism used by OLSR to consider the quality of a link, and therefore can reject routes based on a more complex understanding of the network than simply the number of hops. The hysteresis function ensures that strict rules are applied when selecting a route, but a slightly less strict threshold is used to drop an active route. This ensures that transitory fluctuations aren't compounded by route switching.

Generally it appears that protocols like OLSR offer better support for wireless networks than AODV typically can. It is understood that some link-layer information is now used by Locustworld to influence the AODV route selection process. While this approach may overcome some of the of the deficiencies in native AODV, it may also embed a specific routing protocol deeper into the system and may make it harder to replace in the future.

By design or deployment?

Good network architecture defines the various functions of a network and protects those roles. In a typical community network this means a clear separation between the core network and the customer access network; blending the two limits upgrade options, may interfere with maintenance processes, and will reduce the core network performance.

In a wireless network, separating the two functions requires two radios running in different modes; typically a core mesh network will use Ad Hoc mode, while the customer access network will use Infrastructure mode. This also allows the core to scale independently of the customer access network, and even permit alternate technologies when appropriate. While it may be possible to have a scenario where both radios share a single aerial, this may not always be desirable, and in either case additional costs are inevitable.

However, it is common for community networks to combine the functions of the core mesh network and customer access network by using a single radio in WDS Infrastructure mode. This automatically reduces the available bandwidth, and limits the scalability of the solution. While AODV may have some less optimal characteristics, its ability to scale to large networks is not one of them; a WDS-based network will, however, severely limit the scale of the network. Additionally, since the core network's technology is indivisibly married to the customer access network; it will not be possible to upgrade the core network to add capacity or stability without impacting every customer, requiring a major overhaul of the entire system.

While the blending of roles is not dictated by LocustWorld, it is presented as an option. Where solutions aim to make technology more accessible and assist people in developing what might otherwise be complex systems, it is perhaps important to advise against or remove inadvisable options.

Overall

LocustWorld does a fair job of making a complex environment accessible for the many communities which understandably lack the skills of a teleco's network operations department. However, the choice of routing protocol seems less than ideal, and the efforts to compensate for its deficiencies has perhaps further compounded the problem. Whether it is matter of deployment or design, many installations make no distinction between the core and customer access networks, which impacts the flexibility and performance of the network.

While LocustWorld will work well for small networks with few desires to develop services, it may increasingly become a barrier to communities wishing to expand and offer more adventurous services - which is a real shame.

Perhaps if LocustWorld entered more into the spirit of OpenSource software rather than play lipservice to it, they might find a wealth of new development talent willing an able to help them regain their position as pioneers of a revolution. If they fail in this, they may well find that other solutions which underline principles of good architecture and developed within a spirit of openness by a peer reviewed community will steal their crown.