When we were designing the SkyPilot multi-hop scheduling protocol, our task would have been much easier if we simply used one radio to talk to the parent node and another radio to talk to the child nodes. However, there are several reasons why we chose to tackle the much more difficult problem of single-radio multi-hop scheduling. Obvious reasons to use only a single radio include cost (radios might but cheap, but high power, industrial grade radios and the additional interconnect are not), power, size and the inability to find many clean channels…, but the main reason is that using multiple radios simply doesn’t work!
Focusing on that last claim, simultaneous transmissions and receptions over long-distance links simply do not work in the real world. This is based on physics. If a high-power radio is transmitting at +30dBm while another co-located radio is trying to receive a signal at -90dBm, then the +30dBm transmission will completely swamp the -90dBm reception. That’s a 120dB difference in signal levels, and to put that in perspective, the transmitted signal level is 1 trillion times stronger than the received signal level.
To combat this problem, multi-radio systems have traditionally tried using combinations of:
- filtering (but filtering is expensive and can not provide anywhere near the needed 100dB+ of isolation)
- physical separation of antennas (but using extremely long cables to externally mounted antennas is lossy, expensive, and doesn’t fit onto a pole – so it’s impractical to get the level of isolation required)
- increasing received signal strength by only allowing very short links (but this is still insufficient, and would only allow for very short links)
- lab demos (it’s common to see cabled multi-radio setups showing simultaneous active radios in the lab, but this is just smoke and mirrors where the cables are providing artificial path isolation and are allowing unrealistically high received signal levels)
- lowering modulation (where the radios are allowed to interfere and simply drop modulation and rely on CSMA – but then there is no capacity benefit to using multiple radios)
- requiring channel separation (but even skipping an entire channel is not enough, which you can see from radio vendors’ published “alternative channel rejection” values)
- and (in theory), trying to schedule around tx/rx situations (but, this requires symmetric upstream and downstream traffic, and is impractical)
Even if different channels are used, a typical wireless specification like 802.11a only requires adjacent channel rejection of up to 16 dB and alternate channel rejection up to 32 dB. So even different channels don’t help, and different frequency bands are sometimes recommended (for instance, one channel at 5.2Ghz and the other at 5.8Ghz) which is impractical due to power restrictions and availability.
Even the combination of many of these techniques is nowhere near sufficient to allow for simultaneous transmissions and receptions in a single device over reasonable link distances. So, while a multi-radio story might sound extremely compelling, and has somehow even found its way into some RFP requirements, there are many hidden technical challenges that make it not feasible in the real world.
And there is another important factor in the single versus multiple radio debate – in an “access network”, where the majority of traffic is flowing to and from a gateway node, the bottleneck is almost always the gateway. So, in order to increase capacity of the overall mesh, multiple radios can simply be used at the gateway (which I’ll talk about how to most effectively do in regard to SkyPilot devices in another post). So, if you happen to have access to a live mesh “access network”, try monitoring the utilization of all of your non-gateway radios versus your gateway radios, and this will show you how much money you’ve stranded on your poles.
