Thursday, 2 October 2014

Survey For Your WiFi Clients

When designing WiFi networks, a crucial part of the design process is the wireless survey. This may be a traditional ‘AP on a stick’ survey or may be an off-site, ‘desktop’, predictive survey. In amongst the variety of variables that need to be considered, including coverage and capacity, there is one crucial item that is easy to forget: how does the designed wireless network look from the point of view WiFi clients that will actually use the network?

Background


Best practice for wireless surveying usually dictates that prior to completing a survey for a new WiFi deployment design, a pre-survey questionnaire will be supplied to your customer. This document will ask about the environment that the network is to be deployed into. It will include information such as physical building characteristics, cabling and switch infrastructure, health and safety considerations, access arrangements etc.  

In addition, the pre-survey questionnaire will also request information from the customer about the requirements of the new network to be installed. This will generally include information such as coverage requirements, capacity requirements, service requirements (e.g. voice, data, RTLS) and information about the types of wireless client to be used on the new WiFi network.

When considering the network requirements, many WiFi manufacturers are able to provide some very good guidelines around the design parameters to be used for a network. A classic approach is to design a voice-grade network which uses cell edges around -67dBm and a consistent SNR (Signal to Noise Ratio) of 25dB. There are also considerations around level of cell overlap, but these are a little less well defined and subject to debate about how to actually define/measure them. For ease of demonstration, we’ll go with a very simple -67dBm/25dB approach in our examples.

Performing the Survey


Now that we have a set of defined design criteria, we can press ahead with performing our design survey. In this case, I've chosen an example which shows data from a limited area of a building that was actually a partially complete test survey. The example itself does not stand up to close scrutiny in terms of best practice design, but serves to emphasize the point I am raising in this article.

The graphic below shows how part of the building has been surveyed by walking throughout the rooms in the coverage area. The survey has been performed with Ekahau’s Site Survey package.The walk-paths can be seen (green lines) , together with the placement of the access points (green dots). In addition, the overlaid heatmap shows the coverage of our -67dBm cell edge boundary, with the colouration showing the RF signal level variations. Areas with white-space are outside of our -67dBm threshold and outside of our design criteria (i.e. they are out of spec and need to be fixed). We can see a couple of areas of white-space in the middle of the graphic where we maybe need to place another AP to fill the coverage holes.


If we also take a look at our second design criteria, SNR, the graphic below shows the SNR over the same area, down to our threshold of 25dBm. Again, we've got some white-space in the middle of the graphic and really do need to think about placing an AP in that area to get this design back in-spec.


Once we’ve inserted another AP, we’ve almost certainly fixed our issue and we can put this design to bed - or can we? Although we may have measured the signal levels and SNR thresholds (using a professional surveying tool) and have them within specification, is this network really going to meet the requirements defined by the customer?

It’s All About the Clients


When designing a WiFi network, you have to consider how the network is going to look from the point of view of your WiFi clients - all of your clients. Clients come in a very wide variety of shapes, sizes and capabilities. Some may have good quality RF hardware and decent gain antennas, ensuring that they will have few issues in a reasonably well designed network. They should easily hear our deployed APs and achieve SNR levels that ensure low error rates and good throughput.

However, other clients may have miniscule, poorly designed antennas, with low-cost, low quality RF circuitry. Their antennas may often be in a housing partially made of metal (great for RF eh…?). They may have limited power available due to the power demands of a smartphone handset on a very limited battery. The explosion of mobile devices such as tablets and smartphone means that the majority of clients on a network may suffer these limitations . With the proliferation of these ‘less able’ clients, it is often best to be pessimistic about client capabilities when designing a wireless network and design for your ‘worst’ clients.

If we return to our original survey, we need to take a step back and think about the survey we performed. What were we measuring? Were signal levels and SNR actually measured with a smartphone or tablet? The answer is: no. We were actually measuring (in all likelihood) using a laptop with a USB wireless dongle that has very good RF capabilities. Will this survey 'client' see the network in the same way as a less capable tablet or smartphone? (The answer is no, by the way…)

An Alternative Point of View


In order to understand if this network is going to meet the design criteria laid down, we need to look at the survey data gathered from the point of view of the clients that will be using the network. As mentioned previously, we have to assume the worst, and design for our less able clients.

Fortunately, Ekahau SS provides a very nice feature that allows us to look at our survey data as it might look if it had been gathered by a different type of client. Remember, we have gathered this data using a laptop with a reasonable-gain antenna with good quality RF circuitry. What might this data look like if it has been gathered with a tablet device (perhaps an iPad?).

Ekahau SS considers the original, unfiltered data gathered by the USB dongle antenna to be “raw” measurements. If we take a look under the ‘Options’ button of the ESS display pane, we see a drop-down selection box labelled “Adapter”. By default, the adapter setting is “Raw Measurements” - this means we are seeing the RF data in the same way as the wireless NIC that gathered that data (see graphic below).

If we modify the adapter setting to something other than “Raw Measurements”, we can see how the RF survey data may look through the eyes of another type of wireless client. A whole variety of clients types are available including smartphones, Cisco phones, tablets and many others. For our example, we’ll take a look at our data through the eyes of a tablet device:




Back to the Drawing Board


The graphic below shows how our RF signal coverage may look from the point of view of a tablet device. Note that we still have the same cell edge limit of -67dBm - the only thing that has changed is the client viewing this data:



Unfortunately, we now see huge holes in our coverage. We simply cannot meet the design criteria for our agreed cell edges for tablet devices in this network. We would certainly have to look at adding in more access points, repositioning APs and perhaps winding up our AP transmit powers.Whichever way you look at it, we need to head back to the drawing board on this one if we want to provide ubiquitous coverage at the agreed design signal levels for all device types.

We’ve looked solely at RF signal levels in this example, but there are other considerations that also need to be considered.These include factors such as client transmit power, client sensitivity and the varying CCI view of each client type. The key takeaway from this is that client capabilities need to factored in to design considerations - a survey using raw measurements is generally an invalid approach on today’s “support everything” networks.

One final note is to use the adapter simulation setting within ESS with caution, It should only be used as a guide to how coverage may look. There is no substitute to verifying the data with an actual client device where possible.

Summary

In summary, we’ve taken a look at how we need to define design criteria for the type of wireless network that will meet customer requirements. We looked at a simplified voice-grade survey using cell edges of -67dBm and SNR of 25dB.

Although we may be able to measure the design criteria using a professional survey tool, we need to be mindful of how the measurements are collected. Survey data gathered with a high-spec wireless NIC is generally going to see RF signals at higher levels than a lower spec mobile device.

When considering how effective our design will be in meeting the design criteria, we have to consider how the gathered RF data will look from the point of view of a actual clients that will use the network. Only then can we be sure of whether we can meet the design criteria and the customers’ requirements.

References


As mentioned in the article, here are couple of sample vendor design guides to have a look at (there are plenty of others out there too):


Wednesday, 1 October 2014

ISE's Evil Default

Whilst working with Cisco ISE recently, I became aware of a setting within the product that could be a major ‘gotcha’ if you aren’t aware of it. We’ll take a very quick look at it in this article.


Background


Tucked away in the depths of the Cisco ISE menu structure is a rather innocent-looking configuration setting under the ‘Anomalous Client Detection’ section of the System Settings. The option I’m referring to can be found in the following location in ISE 1.2:


Administration > System> Settings > Protocols > RADIUS


The screenshot below shows the settings page I am discussing:





The settings on this page have been provided to protect ISE in the face of an onslaught of misbehaving or mis-configured clients that may flood it with authentication traffic (and hence RADIUS traffic). In larger environments, this could become an issue and affect ISE’s performance.


Suppress Anomalous Clients


The tick-box ‘Suppress Anomalous Clients’ provides a very useful function by quieting down the ‘noise’’ that you will start to see in the ISE logs once a reasonable number of clients are using the network. Instead of providing a line of information for each client transaction in the clients logs, only the most recent successful event is shown, providing a more manageable list of transactions to view. This effect is provided by the ‘Suppress Repeated Successful Authentications’ check-box, which is checked by default.


Reject Requests After Detection


One default side-effect of selecting the suppression of anomalous clients is that by default, the ‘Reject Requests After Detection’ check-box is also checked (highlighted in the graphic above). This is the ‘evil default’.


One might expect this option to simply provide another level of event suppression for misbehaving clients. Unfortunately, having this check-box enabled will actually add clients to an internal black-list of misbehaving clients for the period specified in the ‘Request Reject Interval’ - 60 minutes by default. Clients on this black-list will be ignored by ISE and effectively excluded.


Unfortunately, from the information I have been able to uncover so far, the internal black-list of excluded clients is not available to view, so there is no obvious way of knowing which clients have fallen foul of rejection (and hence exclusion) for being an ‘anomalous client’.


Exactly what qualifies a client as being anomalous isn’t too clear - the ‘Detection Interval’ and ‘Reporting Interval’ provide some clues, but they still don’t provide any clues about how many times a client has to be ‘anomalous’ to trip the rejection criteria.


Failure Scenario


Although the feature discussed above may not seem particularly worrisome, there are situations when it can kick-in and potentially take down your whole network for an hour (using the defaults).


If there is an extended period of time where clients are failing authentication, then if the anomalous client settings are enabled and left at default, all clients may become effectively excluded for an hour. A scenario such as the failure of an external authentication source (e.g. AD) or a policy configuration error could create such a situation. And, yes, I am speaking from experience of falling foul of such a scenario.


I’m not sure of Cisco’s official recommendation for this particular area of configuration, but I would think it is at least worth winding down the default ‘Request Rejection Interval’  to a lower value than 60 minutes - that’s a long time to lose your clients.


References

Cisco ISE 1.2 User Guide: http://www.cisco.com/c/en/us/td/docs/security/ise/1-2/user_guide/ise_user_guide/ise_ui_reference_administration.html#pgfId-1293445

Converting Images For Survey and Management Tools

Being able to convert electronic floor plans into formats supported by a wireless survey or management tool is a regular part of being a WiFi professional. A customer may often provide floor plans in a format that isn’t accepted by the particular tool that you are using, leaving you with a file-conversion headache. In this article we take a look at a solution (for Windows users) to convert two common file types into a useable format.


Background


When using a professional wireless survey tool, one of the first steps in preparing your survey project is to import an electronic copy of the building floor plans. The plans are used to show areas surveyed and the RF measurements (“heapmaps”) that have been taken.


Similarly, once a WiFi network has been installed, there is often a requirement to import floor plans into a network management system (NMS) to show the areas covered by the new deployment. This may be a cloud-based console or perhaps a dedicated on-site management server. The NMS may show the location of deployed access points, together with their status and heatmaps showing RF coverage.


In both of these cases, a file containing the floor plan needs to be imported so that AP positions and RF data can be overlaid on the plan within the tool. The challenge that we often face is that the floor plans supplied may be in a format that cannot be directly imported in to the survey or management tool. For instance, a tool may only support import formats of jpg, png and gif. However, the floors plans may only be available in pdf or dwg (AutoCad) format. This means we have to convert the files we have been given in to a useable format.


File Formats


In my experience, customers tend to provide floor plans in one of two formats: PDF or DWG. I’m not sure why this is - I suspect they ask their estates or facilities department for a copy of the floor plan and this is what they have on file. Both formats tend to present a challenge, as they are often not supported formats for importing into many tools.


PDF Plans
PDF is the number one format that I find customers tend to supply when I request building plans. Also, this format isn’t generally supported by the various tools I have used, so we have to find some way of converting it to an image file format.


Although PDF files are easy enough to open and view, using free viewers such as the Adobe Acrobat reader, the viewers do not allow you to save the file in an alternative format. If you are fortunate enough to have a full copy of the (rather expensive) Adobe Acrobat software, then you can extract the image from the PDF and save it as an alternative format. But, for the majority of us (on a tight budget), this isn’t an option.


PDF viewers also provide us with no option to manipulate the floor plan image. Often, it may be desirable to remove various features (e.g. borders and legends) from the original image before importing in to our survey tool. By converting to another image format, we have the opportunity to edit the image as required with a simple graphics editor (such as Paint).


DWG Plans
If customers haven’t supplied PDF-format plans, then I generally find that they will supply them as DWG files. These are the file format used by AutoCad software: a very large, very expensive piece of CAD software used to create drawings such as building plans.


Again, most of us won’t have a copy of AutoCad to enable us to open and manipulate our DWG files, but we can open them using the TrueView viewer package.


Trueview is a very useful package that will allow us to view a DWG file. It also allows us to do useful things such as turning layers on and off. Often, a DWG file will show many additional services that you perhaps don’t want included on your imported plan (such as pipework or electrical distribution). Many of these services are shown as a ‘layer’ of information that may be turned off in TrueView to de-clutter the final imported plan.


TrueView natively provides the ability to export the floor plan into an alternative file format, such as PNG of JPG. Rather confusingly, the feature you need to do this is referred to as ‘plot’ rather than export. By electing to plot a plan, it can be ‘plotted’ out to an PNG or JPG format. However, I have found this method to be quite difficult to get good results with, so I would advise avoiding this and using the method suggested later in this article.


‘Printing’ Required File Formats
Now that we have discussed the challenges that we face with DWG and PDF format files, it’s time to look at how we can consistently convert them into formats that we can use with our survey and management tools.
 
File Resolution and Plan Colour
Before we go ahead and look at how to  convert our files, it’s worth spending a few moments talking about file resolution. There is little point in spending time converting our floor plans into new formats if they end up as pixelated splodges which show no detail when you zoom in to view them. This is noticeable when performing operations such as placing access points on to plans and cannot see enough detail to accurately place them. Therefore, we need to ensure that during our conversion process, we create a reasonably high resolution image.


In addition to image resolution, I believe that image colour is also important. Many building plans may be multi-coloured, with different services and building materials shown in a variety of colours. When importing multi-coloured plans into any tool that will display information overlaid on to the plan, then I’d recommend using grayscale colouration. Grayscale simply means that all colours have been removed and that the plan is shown in varying shade of gray (like a black and white photograph). Trust me on this - it is much better to use a grayscale than colour images for your floor plans.


PDFCreator


Finally! We’re now ready to look at how to convert our floor plan into a high-resolution, grayscale image. Although there are a number of file formats that are supported by most survey and management tools (e.g. JPG, PNG, BMP, GIF etc.), my personal favourite format is PNG - it seems to be supported pretty much everywhere and gives great results in terms of file sizes and quality.


The tool we’re going to use for the conversion process is PDFCreator. It’s a free, Open Source project over at SourceForge.  Don’t be fooled by the name - although it can be used to create PDF files, it can also be used to create files in a wide variety of other formats (including many image file formats). Once it has been installed, it adds a new ‘virtual’ printer to your list of available printers within Windows. By simply printing the files you are displaying within your PDF or DWG viewer, it is ‘printed’ to a new file in the desired file format. Before printing, a number of options are available to control the resolution and colouration of the file that will be created.


Now that we’ve described how PDFCreator operates, we’ll run through an example of how to convert both a PDF and DWG file to a high resolution, grayscale PNG image file.


Creating A PNG Grayscale File


In both instances (DWG & PDF), the conversion is actually very simple. To convert our floor plan, we’ll perform the following steps:


  1. Open the image in the PDF or DWG viewer
  2. Select the ‘print’ (or plot) option
  3. Select the virtual PDFCreator printer
  4. Set options for resolution and colouration
  5. ‘Print’ the file to the virtual printer (this actually saves the image in the selected format)


Converting a PDF File


First let’s look at converting a PDF file. Here’s a step-by-step guide:


  1. Open our floor plan image using our selected PDF viewer (e.g. Adobe Acrobat Reader, Foxit PDF Reader) and hit the ‘Print’ button (highlighted in the image below) and view the print dialog box:


  1. Select the ‘PDFCreator’ printer and hit the ‘Properties’ button.





  1. In the Properties pop-up, hit the ‘Advanced’ button so that we can set our paper size (to ensure we get good resolution):




  1. In the ‘Advanced’ pop-up select a large paper size - this will ensure a high resolution to provide a clear, detailed image, instead of a pixelated mess.

    The size depends on the detail on your floor plan - the more details, the larger the paper size you need to get a good resolution. In this example I’ve gone for an ‘A2’ paper size (bear in mind that many DWG diagrams are ‘A0’ in their original format):





  1. Hit OK on the 2 pop-ups you have open and hit the ‘Print’ button on the original ‘Print’ pop-up  window.The initial PDFCreator pop-up will appear. Select the 'Options' button:



  1. You’ll now be presented with the PDFCreator options where you can select the screen resolution and  colouration on the final image. Use 300 dpi and Grayscale:





  1. Finally, ensure you select the ‘PNG’ file type when saving the image file that is created:





  1. If all goes well, you should end up with a nice, high resolution graphic that will be exactly what you need for your survey project or management software (Note: this was trimmed with Paint to remove extra white-space that wasn't required):




Converting a DWG  File


Now we’ll take a look at converting a DWG file. Here’s a step-by-step guide:


  1. Open the DWG file using the TrueView  viewer. Before we create our image file, you might like to experiment with turning of some layers that are  perhaps showing extraneous information on the floor plan






  1. Once you have made any required updates to layer visibility, hit the ‘Plot’ icon at the top of the panel (‘Plot’ is the equivalent to ‘Print’ in this software):





  1. In the ‘Plot’ pop-up that appears, select ‘PDFCreator’ as the printer, select a large paper size for good resolution of your final image. As with the PDF conversion, you may need to experiment with the paper size, which will vary depending on the detail in the plan that you are converting. The more detailed the plan, the larger the paper size you should select to obtain the detail you will require for your survey project or management software.

    Ensure that you select the Fit to Paper’ option:




  1. Hit the ‘OK’ button and then view the PDFCreator pop-up. Simply select the  ‘Options’ button in this window:





  1. In the PDFCreator options pop-up, select the PNG file type and set the resolution to 300dpi and colouration to grayscale:



  1. Finally, ensure you select the ‘PNG’ file type when saving the image file that is created:





Conclusion


In this article we have looked at why we might need to convert image file formats when we need to import floor plans into a wireless survey tool or network management tool.


We looked at two of the most common file types that are often supplied when electronic floor plans have been requested: DWG or PDF files. Both file types may be viewed with freely available software packages, but they may have limitations when exporting floor plan images into usable formats for survey and management tools.

Finally, we looked at a step-by-step guide of how to convert both DWG and PDF files into a commonly supported graphic file format: PNG. We also converted the image into a grayscale image to facilitate ease of use when overlaying information on the plan (e.g. network components such as APs, and RF heatmaps).