The idea of having an all-wireless office sounds great on a number of levels. Your business premises will look fantastic and you’ll be up to speed with the latest technology and ways of working. But will it work, and how easy would it be to have an all wireless office?
Let’s have a look at what we can be observed from one of our recent all wireless office installations, at a Human Resources client.
The Remit
Our client offers an employee engagement platform, and the company has offices across the world. They were opening two new offices in two of the largest UK cities, including one based in London, and they wanted these premises to be completely wireless.
They needed video conferencing facilities on site (Webex, Skype for business etc) and also Voice Over WiFi (VoWiFi). Hot-desking ad mobility were also of great importance to them. Also, if someone wanted to start a video conference or phone call at their desk, then wanted to take it to a meeting room or pod, then the process had to be seamless.
Design Requirements
Office 1 – Up to 100 staff and guests (think 300-plus devices). WAN connection – 400-500Mbps Leased Line.
Office 2 – Up to 30 staff and guests (think 100-plus devices). WAN connection – 100Mbps Leased Line. Each site required a Firewall with URL filtering, PoE+ switches, Access Points (APs) and individual user authentication for staff, as well as guest WiFi registration.
Where to start?
First, we had to understand the client’s requirements and likely usage, and asked them a number of questions. Where will the users be located within each office? This will affect the Access Point locations and the models required. What will the majority of staff devices consist of? In this case they were mainly Apple products – so MacBooks, iPads and iPhones. What phone system was to be used? (We did not know this as it was to be confirmed at a later date.) So once the main questions were out of the way we started with a predictive WiFi survey using Ekahau PRO software to determine the number/exact model and the locations of the Access Points. This requires good floor plans with scale; the wall materials can be inputted to show signal propagation once the Access Points are placed in the desired locations.
The model and number of APs tends to vary depending on the application, capacity and physical layout of the site. In this case, the main issue was capacity – due to the video and VoWiFi requirements. The designer takes all this into consideration – optimal power levels for each radio (for cell coverage), Data (bit) rates, channel planning (non-overlapping channels), Band-Steering methods (to encourage the 5GHz band) simultaneous VOIP calls per radio, QoS (Quality of service/802.11e) on both the wireless and wired network to ensure the higher priority traffic took precedence. Voice and video must take precedence over the network as they are very sensitive to delay, whereas normal Data isn’t. In a wireless network, Quality of Service alone cannot guarantee packets get to where they need to in time. If devices cannot access the network in a timely manner, due to the channel being busy – usually through interference – then voice and video quality will suffer. Good design, and a quality wireless controller setup with the correct parameters, can really help here.
The client also wanted a minimum of two SSIDs – one for Staff with access controlled via RADIUS accounts. Then the other for guest access, with a Captive portal. We also recommended another for VoWiFi (VoWLAN) access.
Hardware selections
Firewalls: Cisco ASA 5500-x with Firepower services (initially just for URL filtering). Models varied depending on throughput requirements.
Switches: Cisco 3650 PoE+ switches – PoE+ was required due the Access Points high power requirements.
Access Points: Ruckus R710s, chosen for throughput or capacity.
Wireless controllers: Both Ruckus Cloud and onsite controllers.
Adding to the complexity of the job, the voice vendor was confirmed just weeks before we were to go live with the project – and it was going to be a soft-client provider with no specific hardware on any of the sites. The phone software was going to be an APP on their laptops, tablets and phones. As all these devices were going to be used for data and voice, which meant we couldn’t VLAN the VOIP traffic and the VOIP packets were not going to be “tagged”. Although it was not best practice, this meant for an added challenge as part of the design, not to mention a lot of configuration testing.
So, time for a few coffees…
Now, we then had to make sure the 2.4Ghz (interference band) wasn’t used (well, was to be used as little as possible) through configuration tweaks. Then, we applied QoS to the VOIP via ACLs (Access Control Lists, detailing source and destination – Soft-client Provider IP Ranges) and DSCP marking on the LAN wired devices. We left the Automatic Heuristics based QoS on the Access Points to sort the wireless QoS.
Easy. Well, not quite…
It turned out the “AutoQoS” didn’t work any longer on the 802.11ac models. It’d been disabled due to processing power requirements – it’s maxing out the APs! So instead of just ensuring the feature was working, it was time to go onto each AP individually to setup QoS via ACLs again. Okay. So the lab worked, and we could relax. If only…
Now it was time to test, tweak, test, tweak – you get the idea. 95% of devices were to be on the 5GHz band. Roaming was seamless for video conferencing and VoWiFi, throughput levels were high, minimal Co-Channel interference, and so on.
Then we just had to monitor. After the initial bedding-in period, of approximately two to three weeks, everything looked good. The client was happy, as we’ve tested, tweaked and documented – and that mean we’re happy too. We could sign off on this job.
Considerations
One thing we learned was just how essential it is to work closely with the customer in order to ensure the correct phone system was purchased, even if you’re only providing the WiFi and LAN. All parties need to work together to ensure optimal performance.
Also, it’s important to test the WiFi QoS fully before installing onsite. Don’t assume the Auto-QoS that did work previously still functions – and this obviously applies to the whole install.
Design considerations
Cell overlap for roaming – More overlap is required for VoWLAN than Data. Cell Boundary no worse than -67dBM.
QoS – Using the same manufacturer’s hardware throughout can make this easier to apply. Purchase a system or handsets that can set the DSCP bit for QoS.
VLANs – Keep Voice separate to Data if possible. In fact, different Radios, too, if it can be done.
Channel Use – Try and use the 5GHz band to limit interference and increase the number of non-overlapping channels available. If possible use the UNII-1 and UNII-3 bands as these are non DFS bands.
Capacity – Amongst other things, consider what codec is being used by the VOIP system. Device density per AP Capacity cannot be worked out per AP or RADIO alone, and channel usage is more important. So the number of calls per AP can vary considerably.
NOTE: The heuristic “AutoQoS” feature has been fixed on the latest firmware.