Ad Hoc Wireless Networks Architectures And Protocols

Setting Up Ad Hoc Wireless Networks Architectures And Protocols

I spent three days trying to get a stable ad hoc network running between four Raspberry Pi units in a warehouse with thick concrete walls. The documentation said it should work out of the box. It didn't. By hour seventy-two I had figured out that the real problem wasn't the protocol stack at all. It was the physical layer and how poorly 802.11 ad hoc mode handles hidden nodes in dense deployments. An ad hoc network is a peer-to-peer wireless setup where devices connect directly without any central access point. There's no infrastructure layer routing traffic. Every node participates in both data transmission and route discovery. The architecture falls into two main categories. Flat or mesh-based topologies treat all nodes as equals with no hierarchy. Hierarchical or cluster-based topologies group nodes under cluster heads that handle routing decisions for their members. Flat topologies are simpler but scale poorly. Once you push past roughly fifteen to twenty nodes, the flooding-based routing protocols generate enough overhead to choke the network. Cluster-based architectures solve the scaling problem by electing cluster heads and organizing routing around them. The trade-off is added complexity and a single point of failure whenever a cluster head drops out.

Routing Protocols You Need to Know

AODV, or Ad-hoc On-Demand Distance Vector, is probably the most widely implemented protocol. It discovers routes only when needed. A source node broadcasts a Route Request. Intermediate nodes forward it until it reaches the destination. The destination then sends a Route Reply back along the reversed path. Route maintenance happens through periodic hello messages and explicit route error packets when links break. It works well in mobile environments with moderate node counts. I ran AODV in a testbed with thirty nodes moving at pedestrian speeds and saw route recovery times average around 200 milliseconds after a link failure. That's acceptable for voice over IP but not for anything that needs sub-50 millisecond convergence. OLSR, the Optimized Link State Routing protocol, takes a different approach. Instead of reactive route discovery it maintains proactive routing tables using multipoint relays. Certain nodes are elected as relays and every relay floods link-state updates to the entire network. This eliminates route discovery latency because routes are always available. The cost is constant control plane overhead that doesn't scale beyond about fifty nodes in practice. In my testing with forty-five nodes, OLSR consumed roughly thirty-five percent of available bandwidth on the control channel even when no application data was being transferred. DSDV, Destination-Sequenced Distance Vector, is the oldest protocol in this space and still relevant in static or slow-moving deployments. Every node maintains a complete table of destinations with sequence numbers to prevent loops. Updates are periodic and use split horizon with triggered updates. It's deterministic but the control overhead grows with the square of the node count. I used DSDV in a fixed industrial sensor deployment with twelve nodes and it ran reliably for eight months without a single loop or stale route incident.

Practical Implementation Steps

If you're setting this up on Linux, the basic process involves configuring wireless interfaces in ad hoc mode and then deploying a routing daemon. Here's the actual workflow that worked for me. First you need kernel support for wireless ad hoc operation. Most modern distributions have this built in. Check with iw list and look for IBSS under supported interface modes. If it's not there your hardware or driver doesn't support it and you're done regardless of what you read elsewhere. Next configure the interface. The command looks something like iw dev wlan0 interface add mon0 type monitor followed by bringing up the ad hoc interface with a specified SSID and channel. Use a non-overlapping channel if you're in the 2.4 GHz band. Channel 1, 6, or 11 depending on your regional regulations. Don't skip this step. I once spent four hours debugging what I thought was a routing problem before realizing two of my nodes were on different channels because one had auto-selected a different frequency.

For the routing daemon, install bird or quagga with AODV support or use olsrd directly. Configure the daemon to listen on your ad hoc interface and set appropriate timers. AODV hello intervals between two and four seconds work well for mobile scenarios. For static deployments you can push that to eight to ten seconds to reduce overhead. OLSR hello intervals between one and three seconds are typical. The critical configuration parameter most people miss is the MTU. Ad hoc mode adds overhead from wireless headers and routing packets. Set your MTU to 1400 or even 1350 if you're running heavy application traffic. Leaving it at the default 1500 causes fragmentation that degrades throughput by roughly forty percent in multi-hop scenarios.

What Nobody Tells You About Ad Hoc Networks

Here's the thing that catches everyone off guard. Ad hoc wireless networks don't fail gradually. They fail catastrophically. You'll have a network that performs reasonably well with four or five nodes, then as you add the sixth or seventh node the throughput doesn't decrease linearly. It collapses. This happens because the routing overhead grows superlinearly with node count and the medium becomes saturated with control traffic before application data gets anywhere. Another counter-intuitive point. More nodes aren't always better for coverage. In a flat topology with flooding-based routing, adding a node can actually reduce overall network capacity because that node generates additional broadcast traffic. I observed this in a warehouse deployment where adding a thirteenth node to reduce hop count caused the total application throughput to drop by twenty-two percent due to increased contention. The hidden node problem is worse in ad hoc mode than in infrastructure mode because there's no central coordinator managing collision avoidance. Carrier sense multiple access with collision avoidance works on a per-node basis. If node A can't hear node C but both can reach node B, A and C will transmit simultaneously and collide at B with no warning. The standard workaround is RTS/CTS handshaking but enabling it everywhere creates its own overhead problem. I found that enabling RTS/CTS only on nodes with more than three neighbors and keeping it disabled elsewhere gave the best balance in my test deployments.

When Ad Hoc Mode Is the Wrong Choice

If you need anything beyond roughly twenty nodes with stable performance, stop and evaluate mesh protocols instead. IEEE 802.11s provides infrastructure-style mesh bridging with better scaling than pure IBSS ad hoc mode. It uses proactive path selection similar to OLSR but at the data link layer which reduces some of the overhead. For industrial or emergency response scenarios where nodes move unpredictably, consider a hybrid approach. Use ad hoc mode for initial network formation and device discovery, then transition to a cluster-based architecture once the topology stabilizes. I implemented this pattern in a disaster response deployment where initial ad hoc connections allowed first responders to establish communication within seconds of arriving on scene, and the cluster election kicked in after about ninety seconds once node positions stabilized. If your environment has significant physical obstructions like concrete walls or metal framing, ad hoc networks will struggle regardless of the protocol. Multipath fading and signal absorption create asymmetric links where node A can reach node B but not vice versa. These asymmetric links are incredibly hard for routing protocols to handle correctly and they cause the most persistent failures I've encountered. The workaround is careful site surveying with a spectrum analyzer before deployment, not after. Measuring RSSI values at potential node locations takes about ten minutes per location and prevents weeks of troubleshooting later.

Monitoring and Debugging

Use tcpdump on the ad hoc interface to capture raw 802.11 frames. Filter for your routing protocol packets to verify that route discovery and maintenance are functioning correctly. In AODV look for RREQ and RREP packets. In OLSR look for Hello and TC messages. If you're not seeing periodic control traffic your daemon isn't running or it's bound to the wrong interface. bmon or airmon-ng give you real-time throughput and packet loss statistics per node. I used bmon during a deployment to identify that one node was experiencing sixty percent packet loss due to being positioned near a microwave oven operating on the same frequency. Moving that node three meters away resolved the issue completely. For long-term monitoring, log the routing tables from your daemon at regular intervals. Comparing table entries over time reveals topology instability that users might not notice immediately. Flapping routes where the same destination appears and disappears from the table indicate physical layer problems that need investigation.