For any WISP, having a robust, fast and high capacity distribution infrastructure between sites is one of the key factors in getting clients the full speeds they expect with predictable latency and reliability.

Many WISPs start by building a multi-point access point on their first tower, and then install a number of clients on that access point. This is a typical and ideal configuration.

Often at some point later, there is a need to install another AP at one of those client’s locations to act as a repeater to additional clients.  Using clients as repeaters can be a good, low cost way to expand coverage and reach additional clients.  There are legal and business considerations with this, but for this article I will focus on the technical considerations.

Many WISPs will simply connect another access point at the client location, using the existing connection as the feed for that AP.  In some cases, simply enabling AP-Repeater mode can also look like a quick and inexpensive way to get service to more subscribers.  These two techniques have some significant challenges and are not suited to professional grade services that will then be resold.  These features were included by manufacturers for hobbyists to use as experimental or home-use features only.

What’s wrong with AP-Repeater mode?

Every time an AP-Repeater is used, speed and capacity for all the customers on those access points are cut in half.  Some might say “No big deal, I only have a few users out there, I can afford to reduce speeds”, but the issue is much larger than that.  Here’s how AP-Repeater mode works:

AP#1 is where the Internet feed is supplied, it has 20 subscribers on it, one of them is another AP, running AP-repeater mode (AP#2).  AP#2 has a further 10 subscribers on it.  One of those subscribers is Joe.

When Joe is downloading, his packets are sent from AP#1 to AP#2, While AP#1 and AP#2 are communicating, all users on both APs must stop their traffic.  Once AP#2 receives the packets, it then sends them on to Joe’s CPE.  While AP#2 is sending the data to Joe, AP#1 and all users on both APs must still remain silent and with no communication.  So, if a data transfer to Joe would normally consume 20% of the airtime on the network, it now eats up a whopping 40%, and it gets worse. Once we consider protocol overhead and other factors, Joe’s download can utilize between 50-60% of the capacity of that part of the network, when it could only be using 20%.

This relay process also has a major impact on latency for all users on both access points.  Joe’s download could be why users on AP#1 are having issues with VOIP or gaming dropouts.

It is also important to consider that AP#2 is already a client on AP#1 and has a subscription ratio of 1:20.  This is ok and and how WISPs work, but when AP#2 is serving its clients, it is doing so at a 1:10 subscription ratio.  So what is Joe’s oversubscription ratio?  His is 1:200!  This is way more than is sustainable and is not something that can be sold in good conscience to the paying public.

During the install at Joe’s place, we may have seen acceptable speeds, but those speeds will never be predictable and he is going to have random slowdowns and be very displeased with his service.  Many users will complain once or twice, then the operator goes out a few times and does a speed test, which looks good at the time.  The subscriber quickly resign themselves to bad service and will simply switch providers once a competitor comes along.

The multiplier factor on subscription ratios is also why it is never sustainable to use a client connection as a feed to another AP, even if it is a separate physical AP.

Network capacity and latency is only one reason why “subscriber repeaters” should never be used on a WISP network.

Managing these sort of configurations is very difficult.  Common tools such as traceroute will not give us diagnostic information and much of the network becomes a “black box” where we have no idea what is going on inside that segment of the network.

Security is another major concern, because all devices must bridge, it is very difficult to keep clients from impacting other clients.  For example if a user accidentally plugs their router in backward, it will start handing out invalid DHCP leases to all other users on the network causing random loss of Internet access.  Users with malicious intent can do far worse.

All APs and clients on both APs must also use the same SSID.  This can create random slowdowns as users on AP#2 might roam to AP#1 where the signal is very poor for them, thus service speeds will drop randomly and with no warning.  It is possible to force the clients to associate to the correct AP by hard-coding the MAC address of the correct AP into the CPE, however this can create enormous issues later.  When the AP fails someday, a new AP will be installed.  But all the CPEs are looking for the MAC address of the old AP.  The only way to get the users back online is to drive to their house and reprogram every single CPE.  This can be very onerous if there are 20, 30 or 40 subscribers, and leave a lot of very upset customers.

The “Lock to AP MAC” feature should never be used in a production WISP network.  That feature is for testing purposes only.

Frequency management and interference mitigation are also very difficult when several sites are all locked into the same channel together.

The Right Way to Build a Backhaul

Ok, so Subscriber Repeaters and AP-Repeaters are not workable, what should I do instead?

Building a Point to Point connection between every single site is mandatory for a scalable and robust network.  It is not very expensive or difficult and is always best done right from the start.

A pair of Nanobeam M5-400 radios can make a very low cost dedicated backhaul between two sites for under $200 and will significantly boost speeds, reliability and solve all the issues that subscriber repeater configurations cause.

It also adds a bit of future-proofing as if the tower at AP#2 gets to be very popular, there is no scrambling around after the fact upgrading capacity because users are having connectivity issues.

Always ensure that backhauls have a clear line of sight (LOS).  Non-LOS backhauls cannot be expected to provide solid connectivity and any jitter or slowdowns on a backhaul will be magnified over all the users on the far end of that link.  If the remote site cannot get a clean LOS back to the main site, then add more height, build a repeater or find another site that is suited to the purpose of acting as a transmitter.  That remote site might start out with only a few clients, but before long it will have 5, 10, 30 or more customers. Those customers will have a bad experience and won’t hesitate to tell all, far and wide.

A well built WISP network will actually cost far less to operate and give the WISP operator more time to focus on building their business and family, so a bit of extra effort and a few more dollars spent from the start will save many hours and lost subscribers later.  Taking a shortcut at the start, creates far bigger issues down the road and as subscriber numbers go up, the problems will only get bigger and more expensive to fix.