A blog about Wi-Fi in Business

Menu

Tag Archives: wireless networks

If we prepare well, an excellent WiFi service and a happy customer should follow.

So what is involved in preparation to deliver an enterprise-grade Wireless service?

Information and Requirements gathering (this blogpost)

Wireless Design

Wireless Deployment & Testing

The below is a list of things I consider are absolutely key to understand before being able to move to the next step: designing the customer’s WiFi service.

The first engagement is usually a sit-down with the customer to understand what they want to achieve by installing an (enterprise-grade) WiFi service; understand their outcome expectations and to flesh out business and technical requirements. A heads up, the ‘outcome expectations’ can be a long conversation, as it should be.

Site Environment. We will discuss the site environments in the first meeting but we still need to get on-premise at some stage. Wall materials, ceiling heights, external and internal interference, numbers and density of users and more. It will entail at least one site inspection followed by one or more site surveys. The outcomes from these site surveys provide detailed information in order that we can plan the design.

Numbers of users accessing the service. How many users? Are the users clumped together in one main area or spread evenly across an area?

Types of applications used over the service. Find out the critical business applications to be prioritised and the resource requirements of these apps. We will need to estimate numbers of simultaneous users.

Types of technology accessing the service. Each device has different behaviour and different capability sets when using wireless. It’s not just about which 802.11 standard it supports.

Existing wireless – some or all of it may need to be removed. If some of the current Access Point placement is going to be maintained, we can re-use the existing infrastructure cabling = cost + time savings. Ta Dah!

PoE switch port availability. Enough PoE (Power over Ethernet) ports to supply power to all Access Points. Some vendors’ Access Points require extra grunt. PoE+ power rather than PoE. Check the customer’s switch fleet to see what is supported.

10GbE port availability. Some wireless vendors use wireless controllers that, in a chosen architecture, will require 10GbE interfaces to be utilised.

Preferred vendor. If customer has one. Some customers or their service providers will only work with a particular manufacturer. Vendor selection impacts the design phase as WiFi vendors diverge in their approach to deliver an enterprise-grade WiFi service.

Backhaul bandwidth. Calculations must consider bandwidth both per individual site and the aggregate to data centres/Internet. If creating an extra 300Mbps of sustained traffic for an event, then perhaps the existing 20 Megabit pipes to the site will not cut it.

Guest service. This sets off its own subset of requirements:

Presentation of the Guest service: some organisations require some legal Ts & Cs to be accepted by a Guest before allowing public access. Some will want to present logos or advertise something in a captive web portal. Some will wish to charge for access.

Where is Guest WiFi to be available in the organisation? Only at head office meeting rooms, only in cafe areas?

Guest on-boarding, security and network access. How do Guests receive their access credentials, how long are they allowed on the network, any bandwidth restrictions? In addition, there maybe separate levels of Guest use depending on the type of guest. Trusted contractor versus general public for example.

BYOD. If using BYOD, hopefully there’s already a framework in place to determine who is allowed to access what, from which device. If the BYOD device type isn’t standardised then we will make general assumptions about capability and tackle individual issues as they come up.

Security Requirements. This conversation is more about how to authenticate authorised users than type of encryption.

Application Visibility and Control (AVC) and Reporting. If the customer hasn’t had insight into what applications are going over their network before now, then they are in for a treat. AVC also provides the network with the ability to prioritise critical business apps over non-critical traffic, e.g. social media.

Support. Who will support the user community? Are they experienced at troubleshooting WiFi? Is training required?

Management. How the wireless infrastructure will be integrated into the organisation’s existing ICT management toolsets: alerting, reporting, maintenance, asset and lifecycle management.

At the end of this, Network Architects are armed with much of the information we need to begin design. For larger organisations, with multiple locations, it is just the beginning of perhaps months of work of site surveys and site analysis.

Site surveys will always uncover challenges, which is why we do them. At the end of a recent site survey, I found the office tenants below and above my customer were using 80MHz wide channels. Thank you. Thank you for messing up the spectrum for everyone. But also, sorry for what I’m going to do to your 80MHz channels when I turn my 27 APs on.

Following a wireless site survey, many organisations are sent automated wireless site survey reports in excess of 80 pages. These tree-unfriendly documents are the result of a click of a button on site survey software which spits out a colourful but massive report in a few seconds.

For a business however, they are about as readable and interesting as a dot matrix printout of line items at a warehouse. Everyone remember dot matrix printers?

Essentially, an automated site survey report is raw data. Factual, accurate and…Unhelpful. It doesn’t tell the business anything. A business without wireless specialists (the majority) will look at it and still have fundamental questions:

The heat maps are all green, so why is my WiFi rubbish?

What are your recommendations?

Should I be worried, is this normal?

Is -50dBm bad? It sounds bad.

What is Channel Overlap? Do we need more of it?

This is unintelligible.

It is nice marketing by wireless survey software vendors, to say ‘Hey, just press this button and your job is done; report generated. You can even put your own logo/branding in.’ It sounds good in theory and it actually is a real time-saver. But, does your doctor hand you a blood analysis report – composed of fun latin names – and leave you to interpret it on your own?

Myself, I created a template in MS Word. Each survey report is written in plain english, removing jargon wherever possible and customised to address the reason for the site survey in the first place. For example: to troubleshoot poor performance or to prove a new service works as designed or, a pre-deployment survey of the current environment.

The report’s content is supported by adding screenshots/tables from the survey into the body of the document or as an appendix. It also avoids sending a 20MB attachment of irrelevant data to my client.

This is my personal way of doing things and so far, customer feedback has been very positive.

In summary, I think if automated reports are going to be used and sent to customer IT managers, then at minimum they should be accompanied by a separate document. A summary in plain english that offers analysis, findings of interest and (if requested) recommendations.