What’s The Difference Between Single- vs. Multi-Channel Wi-Fi?
Single-Channel Architecture (SCA) and Multi-Channel Architecture (MCA) are two different approaches to Wi-Fi infrastructure design. Most wireless vendors use MCA. SCA architecture is sometimes referred to as ‘Single Cell’ or ‘Virtual Cell’.
In this post, the differences between the two architectures will be analysed.
Single vs. Multi
First, what is the main difference between these two systems?
MCA Access Points (APs) operate across different channels. For example, if you have three APs on 2.4GHz, they may operate on channels 1, 6, and 11 simultaneously. This channel separation is intended to avoid Co-Channel Interference (CCI) (when a Wi-Fi radio hears another radio tranismitting on the same frequency, it must not transmit, but rather defer transmission until it has regained control of the channel through standardised methods of channel access (CSMA/CA)).
SCA would have those same three APs operating across a single channel, utilising proprietary access access mechanisms (CSMA/CA is not designed with SCA in mind!).
Why are there two different architectures? When Wi-Fi first came to Market, MCA was the only option and it came with several problems:
When Wi-Fi first came to Market, MCA was the only option and it came with several problems
- Difficult to deploy – No Radio Resource Management (RRM) meant interference avoidance relied upon a competent installation engineer manually configuring channels and power levels for each AP. This was a time-consuming process, required in-depth RF (Radio Frequency) knowledge, and would often result in multiple post-site surveys (which cost money!). If the environment changed post-deployment, manual intervention was required to optimise.
- Poor roaming – In the early days of Wi-Fi, roaming was not a primary focus. The 802.11 standard (and subsequently, MCA) was not optimised for roaming (especially voice traffic).
- Limited frequency space – In 2.4GHz, there are only three non-overlapping channels (four in Japan). This means if more than three APs in are close proximity, interference will ensue. The problem is less prevalent on 5GHz as more channels are available. Unfortunately, 5GHz did not see widespread client adoption until 802.11n devices started entering the market in 2009. Additionally, regulatory bodies were slower (and still are!) to make 5GHz space available for unlicensed use outside of the US/FCC.
Single Channel Architecture promised to fix these issues. – How? Let’s examine:
- Difficult to deploy – Channel planning is not necessarily required with SCA. Unfortunately, this has lead to a misconception that site surveys are not required. Instead, its ok to leave the hard work to those propriarty collision avoidance mechanisms. This is the wrong attitude … but unfortauntely one that prevails!
- Poor roaming – Ultimately, roaming is a decision made by the client. Traditionally, with MCA, a client will roam to another AP when it perceives a significantly more attractive signal. Unfortunately, this roaming process can sometimes be slow and disruptive. With SCA, all APs in the network appear as if they are one, single AP. This is achieved by all APs operating on the same channel and using the same BSSID (an ID in which the client associates to, and to which is traditionally unique per AP and SSID).
Operating in this way means that rather than the client making the roaming decision, it is made by the controller. As far as the client is concerned, it remains connected to one big AP. The controller moves (responsibility for) the client between APs within its ‘Virtual Cell’. The result is a near seamless roam that the client is unaware of. Operating in this way means that rather than the client making the roaming decision, it is made by the controller
A less well know detail is that although handoff in SCA is near seamless, the decision for the handoff takes time and is heavily dependant on AP placement and cell overlap.
- Limited Frequency Space – If all APs are operating on the same channel, then channel resource planning no longer poses a problem (in theory). The job of interference avoidance is not dependant on using non-overlapping channels. Of course, a single channel/frequency may not be suitable across larger installations. Interference in different parts of a building may make it difficult to find a single channel that can be used site-wide.
Does this mean SCA is superior? Not quite. SCA was a fantastic idea at inception and solved several problems. Since then, however, the industry has witnessed much change:
- Vendors have made numerous enhancements to their MCA architecture including RRM (Aerohive’s Cooperative Control protocol is one example).
- Client devices have had their drivers and roaming algorithms improved over the years.
- Various roaming enhancements have been created including OKC (Opportunistic Key Caching), PMK (Pairwise Master Key) caching, Pre-authentication and more. Info on these can be found here.
- The IEEE (Institute for Electrical and Electronics Engineers) has standardized several improvements such as 802.11r/k/v, which aid in roaming performance.
- The Wi-Fi Alliance has curated programs such as Voice Enterprise (based upon the aforementioned 802.11 standards), which “defines the requirements for enterprise-grade voice quality, mobility, power saving and security.”
With these improvements in mind, the use case for SCA has become increasingly limited (hence why most vendors have chosen to develop around MCA).
As the foundational benefits of SCA have slowly been eroded, alternative advantages are being touted. One such advantage is ‘to achieve the highest data rates, SCA is the only choice’. Let’s examine this claim.
To achieve very high data rates, wider channel widths (80 or 160MHz) must be used over 5GHz. MCA has limited frequency space to achieve this. Why? In 5GHz there are 25 non-overlapping 20MHz channels available in the US under FCC regulations (20 outside US). To achieve very high data-rates, an AP combines 20MHz channels to form wider 80 and 160MHz channels. This concept is illustrated in figure 1.2.
With MCA, (referencing the above illustration) it is therefore possible to have 6 APs using 80MHz channels or two APs using 160MHz before co-channel interference becomes a consideration. With SCA, all APs can share the same 160MHz-wide channel – great!
Unfortunately, receive sensitivity decreases for any radio operating on a wider channel. The wider the channel, the worse things get. A stronger signal and better SNR is therefore required to achieve the higher data rates offered at 160MHz. With SCA, it is likely that transmissions from APs and clients further away will contribute to raising the noise floor, subsequently decreasing SNR, meaning an even stronger signal is required. The result is higher data rates become increasingly difficult to hit. Furthermore, any DFS event (true for false positive) requires a channel change. This change can break the Virtual Cell which requires stations to handle the roaming process on their own after all!
Graphic courtesy of revolutionwifi.net
Ultimately, it is impossible to change the laws of physics. These laws dictate that if energy is emitted at any given frequency, energy from a different source emitted at the same frequency has the potential to interfere. SCA attempts to address this by using collision avoidance mechanisms.
The unavoidable truth is that the more clients attempting to transmit simultaneously, the worse performance becomes as clients end up queuing for their turn. This happens irrelevant of using 20Mhz or 160MHz channels as shown through figures 1.4-1.7.
As illustrated above, whether using SCA or MCA, contention is addressed by using some form of collision avoidance mechanism. There is no advantage to either platform – if CCIs present across a 160MHz-wide space, any following client must wait its turn or reduce channel width to talk without encountering interference. With that said, the use case for 160MHz is extremely limited. Basically, unless you’re benchmarking or your network consists of a couple of APs with no neigbouring networks or potential for DFS hits, 160MHz is impractical. You’ll introduce unnecessary co-channel contention (CCC) and reduce the range of your APs.
Conversely, MCA has a clear advantage when client density is compared. Figures 1.6-1.7 illustrate how multiple 20MHz channels operating across an MCA environment support simultaneous clients more effectively than SCA using wider channel widths (40MHz in this example).
Additionally, it’s worth noting that regardless of channel width (and high data rate potential), a large portion of traffic will still be broadcast at 20MHz with legacy rates. This leaves the rest of the 160/80/40MHz channel idle. With narrower channels, this inefficiency (protocol overhead) is reduced, and spectrum utilization is increased.
To conclude, SCA was successful in addressing several prevalent issues in the early days of Wi-Fi. Since then, OKC, PMK caching, pre-authentication, 802.11r, Voice Enterprise, protocol enhancements, client driver enhancements and more have greatly improved the capabilities and performance potential for 802.11. Consequently, SCA’s advantages have been eroded over time. SCA’s advantages have been eroded over time
The touted ability of operating multiple APs across a single, wider channel is ultimately negated as clients must round-robin their communication across the virtual cell/collision domain. With 802.11ac, channels will automatically reduce in size when interference is present which in turn reduces data rates. Combined with the effect DFS has on virtual cell operation, a very large question mark hangs over the usefulness of wider channels with SCA.
With SCA, if there is a requirement to extend throughput capacity of the network, the solution is to ‘layer’ channels. This involves multiple layers of virtual cells. For example, three APs on channel 36 and three APs on channel 40. Of course, this is almost an admission to MCA (but ends up costing a lot more money!)
Despite the two platforms achieving the same goal (communication), MCA ultimately has more flexibility and performance potential (if deployed correctly!) when multiple clients need to transmit simultaneously and scalability/density is a concern.