Executive Summary

As an IT enterprise organization, we get to deal with many users and understand that not all users are the same. Over the last few years, we have started to see that in many cases when a user is complaining about slowness, the real issue is high latency. This is mostly true for real time application users such as VNC, teams and so on

We wanted to understand the benefit of upgrading our infrastructure from WiFi5 to WiFi6 or WiFi6E and the improvement it can bring to these users. How many concurrent real time application users can we support with WiFi5 access points (AP) vs newer AP and can we improve the customer experience by applying different configuration on the wireless network.

Problem statement

At Intel almost 90% of the users are using wireless network as the primary and only means of access. Within a few years of experience, we were able to achieve a good WLAN design that should be applicable for most use cases, and was able to support office users, bring your own devices, guest and IoT over multiple SSIDs.

Figure 1. Users breakdown based on use case

Our design concept consists of the following guidelines:

1. Access points (APs) should be placed 13.7 m./45 ft. apart, to ensure good coverage on the 5GHz frequency band.
2. Maximum users per AP should not exceed 15.
3. Channel bandwidth is 40 MHz only in the cases where there are at least 6x 40 MHz non-overlapping channels. A channel width of 20 MHz is used where the above criteria is not met.
4. For 6GHz network we are enabling 80 MHz and follow the same rule as above.

However, when analyzing the key pain points for our high-end customer we noticed that the main challenge is for real time applications such as VNC, used mainly by our design engineers.

In the application breakdown below you can see that VNC takes 11% of the total downstream traffic over WLAN.

Figure 2. Breakdown of application usage example at an Intel site

VNC relies on network communication to transmit and receive screen updates. High latency can lead to delays in response time and a less responsive user experience. Therefore, the main concern and reason for most of the complaints was latency, specifically not the average latency but the maximum latency. VNC network behavior,  similar to other video applications, results in network traffic bursts. The traffic comes in spikes and has the potential to increase temporary the utilization on the AP. The issue is amplified when there are multiple users in the close proximity.

We could see a strong correlation to AP utilization, in the image below we can see that when we are above 70% utilization we can see ping latency spite to over 2000ms, however when the channel load is reduced the latency is way below 100ms.  

Figure 3. Ping latency to a local server over time

The impact on the users would be a slow refresh frame on a video session, image might freeze and for design users who work on a remote machine it means losing sight on the remote mouse movement. In some cases this mean starting the entire job over and over again.

Even when not using graphical based applications over VNC and only using text interface applications such as putty or command shell that is used to open SSH session to the server, screen refresh failures evidence was observed. In most cases what users would see is delay in writing or editing the text on the server.

Pilot Study

The idea behind this paper was to try to find the sweet spots that can estimate when an access point might become too busy to support real time video users. These numbers later can be used for either capacity planning or WLAN upgrade justification. We were able to identify two main contributors to getting high latency and user complaints:

1. The physical distance to the server. At Intel we have few cases where the end users are not located at the same site as the server they are working on and in some cases are not even in the same region.

Although the new hybrid mode of work means employees come to work less days within a week from the office, it may actually result in more load locally. To maximize the face-to-face benefits, teams attempt to align to the same days of work in the campus, and also sit in close vicinity within the building, potentially creating load. VNC usage is increasing while the number of LAN connection is declining. Typically, design engineer at Intel would be working by connecting to a remote server, opening either VNC or SSH to these servers, our focus in our testing was around VNC usage. In order to understand what is considered good or bad user experience we first had to map the best practice values for latency, jitter and packet loss.

• Latency – The recommended value is on average less than 100ms and the maximum should not exceed 200ms.
• Jitter – The recommended value on average less than 30ms and maximum should be less than 50ms
• Packet loss – The recommended value on average should be less than 1%and the maximum should be less than 5%.

The system under test (SUT), were connected to a different type of wireless network each time starting from WiFi5 all the way to WiFi6E.

The spectrum configuration at Intel is based on the following assumptions:

• Proper deployment will require at least 6 non overlapping channels – see related IT@Intel paper.
• WiFI5 / WiFi6 AP – are configured with 40MHz channel width unless the country regulatory does not allow 6 non overlapping 40MHz channels.
• WiFi6E AP – are configured for 80MHz channel width.

Test 1: VNC User Capacity per AP per channel width

This test used a single AP configured with a dedicated SSID to control the clients’ AP connection. All clients were deployed in the lab area and connected to the AP starting from 4 clients.

We increase the number of users gradually until we see the first client crossing the optimal threshold values.

One machine received synthetic traffic from a traffic generator, the rest had an active session to a VNC server. This server was running a 4K video stream which generated the download traffic, as for the upload traffic we used the synthetic traffic generator.

Each laptop generated around 0.1Mbps synthetic uplink traffic and around 10Mbps downlink traffic.

Figure 4. Lab test scenario.

We can see the strong correlation between 3 factors: the channel utilization, the channel width, and the AP generation. Once the channel utilization hit above 60-70% utilization we started seeing a degradation in traffic latency and started to observe network delays. Do we need to add max latency values of the tests?

There were couple of ways to mitigate these delays:

1. Increase the channel width – which would help to a certain level but may be limited by regulatory limitation.
2. Upgrade the AP hardware – we could clearly see how newer generation AP with the same channel widths perform better.

The combination of the two factors above was proven to be the best solution. This is where upgrading to a WiFi6E AP would really show the impact. The new 6GHz band allows in most deployment to safely work on a much wider channel width.

Increasing channel width is the most effective way to boost performance. Nevertheless, due to regulatory constraints limiting the number of available channels, optimal channel width on 5GHz is limited as well in order to avoid channel overlapping and interference. Therefore, upgrading to WiFi 6E APs that support the 6GHz band provides the opportunity to leverage wider channels for improved performance.  

Figure 5. Lab testing resulats.

Test 2: WiFi6 / WiFi6E MU-MIMO (Multi-User, Multiple input, Multiple output) impact

This test focused on validating the impact that MU-MIMO feature has on real time traffic as VNC. The feature allows utilizing the multiple antennas on the AP to send the traffic at the same time to multiple clients.

Our main focus was looking at the uplink MU-MIMO which requires the AP to coordinate the traffic transmission across the multiple clients.

In this case it looks like the maximum number of users each AP could support before we started to face latency glitches was not as high as when the feature was disabled .

No impact of MU-MIMO on channel utilization? MU-MIMO on 11ac: only downlink?

Wi-Fi 6 Best Practices

Based on all of the above testing, we can conclude that when talking about real time application the best option is using the latest WiFi standard possible. It gives the users the benefit of enjoining a standard that is well designed for real time application. The best way to make sure no glitches are seen and users can benefit from a flowless traffic is to make sure the AP channel utilization is not increasing above 60%-70%.

1. Channel width - With both WiFi6 and even more with WiFi6E this can be achieved using the same WLAN layout by adopting wider channel and newer features. At Intel we are utilizing 40Mhz channel width for 5GHz SSID and 80MHz for 6GHz SSID.
2. QoS - IT organization should keep a clear understanding of the application traffic that is used in the organization, priorities the one that need to be prioritized. At Intel we prioritize VNC and SSH and classify these traffic as Video both on the client and server front, while trusting the QoS marking on the WLAN network.
3. Client count – The IT organization should have a clear understanding not only about how many users per AP they support, but also how many of these users are using real time applications at the same time. In cases where the number exceed the recommended values showing in this article, we suggest adding more AP. It is recommended to make use of the largest amount of channels available by regulatory.

If you liked this paper, you may also be interested in these related white papers:

• Building a Faster, More Secure Enterprise Network with Wi‑Fi 6
• Building a Multi-Cloud-Ready Enterprise Network

For more information on Intel IT best practices, visit intel.com/IT.

Co - Authors

Omri Barkay
Principal Engineer, Intel IT

Liran Klein
Network Engineer, Intel IT

Ifat Peczenik
Network Engineer, Intel IT

Limor Sasson
Network Engineer, Intel IT

Ido Tenne
Network Engineer, Intel IT

Yaki Lanciano
Wireless Validation Architect, Client Computing

Ilan Fridman
Wireless Validation Architect, Client Computing

IT@Intel

We connect IT professionals with their IT peers inside Intel. Our IT department solves some of today’s most demanding and complex technology issues, and we want to share these lessons directly with our fellow IT professionals in an open peer-to-peer forum.

Our goal is simple: improve efficiency throughout the organization and enhance the business value of IT investments.

Follow us and join the conversation:

• Twitter
• #IntelIT
• LinkedIn
• IT Peer Network

Visit us today at intel.com/IT or contact your local Intel representative if you would like to learn more.