High-Density WLAN Design Part 1

Determine Client Requirements:

Part one of this series of posts will cover how we can determine what the end users requirements are going to be and also how we can best serve them, but before I get started on that I feel a quick introduction to what defines a high-density wireless deployment.

High-density WiFi is an intersting challange, in a typical office environment you will generally speaking have a known quantity of devices in a given space and more often than not administrators are better in control of what those devices are and able to test and verify the performance and capabilities of the radio cards in them (though BYOD is set to change that I guess).

In an event environment we have people litterally bringing anything in with them and we normally assume that the average user these days is going to have three devices that are going to be connected to the network (laptop, tablet and phone).   Throw in a variety of performance metrics and device capabilities and it makes for a very interesting deployment!

So in the context of an auditorium the density of users in a given space increases dramatically from those seen in a typical office WLAN deployment.   Users are normally clustered very closely together so that the venue can hold the highest capacity possible.   Furthermore the actual distribution of users over the space is not always even, there are aisles between seats, stages etc. that all account for large amounts of unused space – this makes looking at a rooms dimensions fairly useless for antyhing other than working out the free space path loss of an AP if it were placed at a given point.

From an RF point of view there are also quite stark differences, in an office environment you would normally have a reasonable amount of attenuating materials between AP’s and also between AP’s and users, walls, cubicles etc.   In an auditorium we generally have the polar opposite, access points have excellent view of the client devices and also of eachother – more on the problems that can lead to later when we look at RRM 🙂

As we can’t really fix a lot of these things it is our job as engineers to design and implement as robust a network as possible to give it a fighting chance of working and we do that by understanding and where possible controlling all the variables that might conspire against us having a working WLAN.

So, lets crack on…

Establishing Per-Deivce Throughput Requirements:

How much bandwidth does each user require, on average for the given tasks they are going to be performing over the network?

In more or less all cases this is going to be determined by the types of applications people are wanting to use, though for the purpose of keeping this simple I am going to say we are looking to provide 1Mbit/sec per user for web browsing.

We can now look at working out the aggregate-throughput required in a given area.   To arrive at this number you simply multiply the minimum acceptable throughput per connection by the number of expected devices and this will give you the target bandwidth required.

50 x 1Mbit/sec = 50Mbit/sec Aggregate Throughput.

This though is a bit of an over simplification as generally not all devices will be in use constantly depending on the applications, so let’s say as this is web browsing we expect them to be busy 25% of the time, and that in reality we will need to provide a sustained throughput of around 10-15Mbit/s.   That is still quite a lot when you consider the capacity of a 2.4GHz channel in a typical environment.

Next I will be looking at how we can take these estimates and work towards supporting these requirements and some of the design considerations that will crop up.

One thought on “High-Density WLAN Design Part 1”

  1. Nice blog Will! I found my way here from Linked-In. It’s interesting to understand a bit more about what you go through at your client’s site. Keep up the good work!


Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.