The hidden node problem in wireless arises from a faulty way of devices talking to each other.  This causes a lot of network collisions.

Simply put, collisions are when two network devices try to talk at the same time.  This is bad, as it means that the receiving end can’t understand what just happened – and both senders have to try again.  It becomes especially troublesome at prime-time as more clients are attempting to use the network simultaneously, and collisions are often the primary cause of prime-time slowdowns.

CSMA: The default won’t work for WISPs

802.11-based equipment is great because of its low cost and wide compatibility, however the protocol was never designed with long-range WISPs in mind.  It was designed for a coffee shop or home environment.   By default, 802.11 uses a scheme called “CSMA” (Carrier Sense Multiple Access) to avoid collisions, which works as follows:

CSMA:

• Client: “I don’t hear anyone so I’m going to talk now”.

This works great in coffee shops because each device can hear every other device – they’re all using small omnidirectional antennas.   With long range WISPs, all the clients have very directional antennas and because of this they can hear the access point (AP) but not each other. This means when they listen using CSMA, they hear nothing, so they can always talk.  From the AP’s point of view, everyone is talking at once, so it constantly has to say “try that again” (aka. “retransmit”).   This situation where an AP can hear a device but nobody else is able to, is called “hidden node” – because the node is hidden from other clients.

Standards-based solution: RTS/CTS

Imagine that your AP is a presenter in a large classroom and they have a microphone connected to a huge PA system.  No matter what your AP says, everyone can hear.   Now imagine that the presenter wants to have a dialogue with each person in the classroom.   The AP asks a question, and everyone in the classroom answers at once!  Unable to understand, the AP repeats the question and everyone answers at once, again!

So the AP tries another strategy.  It asks someone to raise their hand before talking, and then picks one person at a time.  Someone raises their hand (RTS), the AP picks that person (CTS) and tells everyone else to “be quiet!” at that time.  The person answers, and the AP can hear them.  That’s great!

RTS/CTS:

• Bill:    “Can I talk?  My name is Bill and I need about 30 milliseconds”.
• AP:    “Yes you may talk now, everyone except Bill stay quiet for 30 milliseconds!”.

This continues, with each person in the classroom holding up their hand and the AP picking them one by one.   It takes a long time to get through everyone though, because there’s no rhyme or reason to how the AP picks the person.  It’s based on whoever has their hand up first.  The back and forth of “Can I talk?” and “Yes, you may talk.” adds a lot of time too.   It’s very inefficient, but almost all 802.11 equipment knows how to communicate this way, so it’s very compatible. It is a stop gap measure at best.

Polling/TDMA: Breaking the standards for a better solution

Both of these solutions are not part of 802.11, but they work much better than anything the 802.11 standard can offer.   The first is polling.  In the classroom example, this would essentially be the AP going through the list of names of every person in the classroom and giving them the opportunity to talk.

Polling:

• AP:     “Bill, please talk for 30 milliseconds”
• Bill:    “Here’s 30 milliseconds worth of data I have”
• AP:    “Frank, please talk for 30 milliseconds”
• Frank: “I don’t have anything, so here’s 30 milliseconds of silence”

There’s a lot of different ways to do polling, but they all require sending a “token” that each client responds to.  Unless clients hear their own name, they won’t talk.   This is essentially the “CTS” part of the RTS/CTS scheme, but the AP goes round-robin through all the clients instead of waiting for them to request.   If a client has nothing to say, they still get a time slot so bandwidth is wasted.

Another solution that works in a similar way is TDMA (time-division multiple access).   In this example, the AP assigns each client a time slot – and the client knows to only talk during their own time slot.  They are resynchronized regularly.

TDMA:

• AP:       “Synchronize your watches; Bill talks for 30ms, Frank for 10ms, then John for 50ms.”
• Bill:      “Here’s 30ms worth of data I have”
• Frank:  “Here’s 10ms worth of data I have”
• John:    “Here’s 50ms worth of data I have”

This is exceptionally efficient if the devices support it.   Examples of this technology are Ubiquiti AirMax and Mikrotik NSTREME.   Both are implemented by changing the internals of the 802.11 protocol so that it is no longer compatible with standard 802.11 devices.

This has the inherent drawback that you are locked to using a specific manufacturer for your client devices if you choose a non-standard protocol, but often this is a good compromise to make as you can sometimes almost double capacity on your APs and massively improve service by going this route.

Having TDMA based protocols on your network as an operator is a huge advantage.  It will enable your network to be far more resistant to interference, Torrent users and Denial of Service attacks.  It will also improve uptimes, boost speeds and vastly improve latency for gamers and VOIP.  In the end it will save you money and make service better.  You can have more users on an AP (thus saving channels) and give them better service in the process!

Migrating to a new MAC layer: Challenges and Ideas

If you are supporting legacy equipment in a mixed environment, such as old 802.11b Tranzeo or Senao/Engenius CB3 – you will not have access to new protocols.  The equipment doesn’t support them, so your only option will be to use RTS/CTS.

To enable this, you will need to look for a setting called the “RTS Threshold”.   This is a number (in bytes), that sets what size of packet the device will ask before trying to send.   You generally want to have the device make a request for most packets, so try setting it low – 150 bytes is a good starting point.  You will need to change this setting for every client on the AP.   If your AP requires turning on RTS/CTS, you can do this as well, but the AP itself does not need an RTS Threshold (it will usually be ignored if set).

If your network is entirely one class of device (eg. Ubiquiti M-series, Mikrotik) – you should consider enabling AirMax or NSTREME.   Both Ubiquiti and Mikrotik allow for devices to auto-detect this protocol so you should only have to turn it on in the AP and the clients will switch over automatically.   Monitor the performance of the clients (Swift Fox pinglogs are great for this) before and after the switch to make sure that you’ve improved things.

If your network is almost entirely one class of devices seriously consider either splitting the old devices off onto their own APs (or rigging new APs for the new class of devices), or going out and upgrading the old devices.   AirMax/NSTREME are an “all or nothing” thing – even if you have a single device that doesn’t support it on an AP, it will prevent you from using it.