My First Design Part 3 – ADDENDUM

I received some feedback on this post that I’d like to share. The idea behind this series of posts was to share my admittedly novice design process so that others could learn with me; and so, rather than edit the original post to fix errors, I’d like to call them out so others can see what I’m learning.

Here’s a quick recap of the coverage requirements set for this project:

CV-Reqs

Note that the channel overlap is set to a max of two APs at -86 dBm before the requirement is flagged as not being met. We’ll look at this later.

My signal strength heatmap settings were called into question:

SigStrLeg

Specifically, the fact that the grey edge ends at -73 dBm. What I had done was used the signal strength visualization to represent two metrics:

  1. Coverage I want – where the requirement is met, or anything above -67 dBm
  2. Coverage I don’t care about – where the requirement isn’t met, or anything below -67 dBm

Then I arbitrarily set -73 dBm as a threshold to indicate where the requirement wasn’t quite met, but wasn’t terrible overall. This was a poor choice on my part!

I had forgotten about something useful that I had learned in the ECSE course. The signal strength visualization can show us three useful metrics:

    1. Coverage I want – where the requirement is met, or anything above -67 dBm
    2. Coverage I DON’T WANT – where the requirement isn’t met, but the AP is still causing CCI on that channel, or -67 dBm to -86 dBm (-86 dBm to match the channel overlap requirement)
    3. Coverage I don’t care about – where the requirement isn’t met, and the AP signal should be low enough to not cause noticeable CCI; anything below -86 dBm

There’s an important distinction there!

Now this doesn’t change my design much. Let’s take a look with the heatmap coloring rules set to the appropriate “want/don’t want/don’t care” levels. Here again is the signal strength for the main floor showing the where the requirement is measured against the two strongest APs:

SS2-CCI86

and here is what it looked like before:

Main Floor - Signal Strength (2 Strongest APs)

Minor changes showing where CCI flows into the areas I had stopped caring about before hand. For reference, here is the signal heat map for the strongest one AP, with the “don’t want” levels set to go to -86 dBm:

SS1-CCI86.PNG

The real benefit of this though comes when we look at one AP at a time. Here I’m only looking at the coverage for a single AP. The green areas again indicate where our requirement is met, but look at all of that grey! These are areas where this AP is still heard above -86 dBm, meaning we can’t reuse that channel without causing CCI!

SS-OneAPCCI.PNG

Ok, so has there been any effect on my CCI metrics? Let’s take a look. In this heatmap, the “don’t want” signal strength level has been left at -67 to -86 dBm, but we’ve moved to the channel overlap visualization:

Main Floor - Channel Overlap

Looks the same! Phew! Let’s see what it’s telling us:

We’re still using the -86 dBm threshold as the point where we stop counting overlap as CCI, so here we have two APs on the 40 MHz channel covering channels 108 and 112, both heard above -86 dBm (-63 and -74 in this case).

Hopefully this helps to clear up some of the last post! Let me know if anyone has more questions or comments!

My First Design Part 3 – Main floor

UPDATE: When you finish reading this post, please see the addendum post HERE

Welcome to the next part of my first design saga! Now we get to the good stuff…

Here we get to see what every client wants to see, but often doesn’t really know how to interpret – fancy heat maps! There is a lot of potential here to mislead. It is very easy to make every heat map look a nice shade of green over the entire coverage area without any explanation as to what we’re actually looking at. Therefore, let’s start with my legends:

Signal Strength Color Legend (values in dBm):

SigStrLeg

The map is calibrated to show colors for values from the minimum requirement of -67dBm and higher (better signal). Any values below -67dBm and as low as -73dBm are shown in grey.

SNR Color Legend (values in dB):

SNRLeg

The map is calibrated to show colors for values ranging from the minimum requirement of 25dB and higher (better SNR). Any values below 25dB as low as 20dB are shown in grey.

Channel Overlap Color Legend:

CCILeg

The map is calibrated to show green for areas with no channel overlap (that is, only one AP on the channel over -86 dBm). Yellow indicates areas with 2 APs overlapping; and grey is anything more than 2.

This is exactly how it appears in the document delivered to my client, Aperture Science. It’s important that the heat maps give us a visual reference for where we are or are not meeting our design requirements (see part 1 and part 2!), so the legends are set so that grey shades are used anywhere where the model predicts that our requirements are not going to be met.

Let’s look at the main floor. It’s half the size of the two upper floors. First, what the client was looking for overall – AP placements:

dual AP This is an example AP transmitting in both the 2.4 GHz and 5GHz bands. The purple box indicates the 2.4 GHz channel. The orange box indicates the channel and channel width (40 MHz).

5 only AP This in an example AP transmitting in the 5 GHz band only. 2.4 GHz is disabled to avoid creating co-channel interference.

Main Floor

Main Floor - Access Points

Simple enough. Next, a brief summary of how we made out trying to meet our requirements. Color coding to match Ekahau’s health map for later.

Predicted Metrics

Main Floor

1F - Predicted Metrics

Next, a brief summary of areas the predictive design identified as possible problem areas:

Potential Problem Areas

Main Floor

Signal Strength – The areas which have some potential for issues are the north elevator, the walk-in cooler and freezer, and a small space in the radioactive storage room.

SNR – The predictive design for the main floor includes one small location where the minimum requirement is not met in the outside corner of the north elevator.

Number of APs – Minor spots in the cylinder storage room, walk-in cooler, radioactive storage room, and east fume hood room areas.

These two parts were repeated for each floor, at the beginning of the document. The idea is to give the less technical folks the high-level results in the first handful of pages of the design doc without having to wade through the techno-babble.

Further along, I provide the detailed heat maps. Starting with Signal Strength, against the requirement for TWO APs at -67 dBm or higher:

Appendix: Design Details – 5 GHz

Main Floor Details

Signal Strength – 2 Strongest APs

Color Legend (values in dBm):

SigStrLeg

Main Floor - Signal Strength (2 Strongest APs)

The areas which have some potential for issues are the north elevator, the walk-in cooler and freezer, and a small space in the radioactive storage room.

Here we can see the aforementioned potential problem areas. The elevator is in the top left corner and has a white area (-72 dBm or lower), but we agreed the elevators were not critical. The middle of the drawing has a large grey area (-67 to -71 dBm) which is inside the walk-in cooler/freezer. You can imagine that the steel construction is a strong attenuator here. Note that grey means that we’re within 5 dBm of our requirement, even if we haven’t met it. I can tell you that we do meet the requirement with a single AP, so it’s likely that a 7925 handset will be able to make a call without problems in the freezer, but we can’t guarantee a successful roam. Luckily for us, there’s not likely to be a lot of roaming going on whilst in the freezer.

There are also a couple of minor grey areas on the bottom of the drawing, in the edges of the service area, in shelves, concrete stairwells, and rooms that aren’t actually in our coverage area.

Also, I did provide all of the heatmap files in a separate zip archive, and included the heatmap for the single strongest AP; but, since the signal strength for a single AP is not a metric we’re using to meet our requirements, I did not use it in the main document (the document gets long with the rest of the heatmaps as it is).

I also provided the visualization statistics. I haven’t decided if I will continue to use these in future design documents:

SSstats

Less than 5% of the main floor area does not meet the signal strength requirement for the two strongest APs.

Next, SNR:

SNR

Color Legend (values in dB):

SNRLeg

Main Floor - SNR

The predictive design for the main floor includes one small location where the minimum requirement is not met, the outside corner of the north elevator.

Pretty solid I think.

Next, I briefly pointed out the visualization statistics for Data Rate (100% met) and Number or APs (98.2% met). The heat maps for these are less useful, so I didn’t include them in the document, and just pointed out that there was no concern with these metrics.

Then Channel Overlap, or Co-Channel Interference:

Channel Overlap

Color Legend:

CCILeg

Main Floor - Channel Overlap

Minor overlap of two APs in the lower rooms in the image.

Ok, we have a few areas where two APs on the same channel can be heard over our threshold of -86 dBm. This is not the end of the world, but it does mean that we do not have quite the full capacity of 14 APs across 40 MHz channels each; but we do have 96% of the area without overlap, and the experts I’ve heard from seem to agree that anything over 90% is quite good.

Now it’s important to remember here that this is the PREDICTIVE design, and therefore doesnt take into account interference from neighboring Wi-Fi radios that won’t be under Aperture’s control. This is a multi-tenant building; and looking at the floor plan for the main floor, this is about a quarter of the entire floor area in the building.

The good news is that Aperture is the only tenant on all three floors of this building’s East half. The main floor plan we’re looking at here is the North side of the East half, and the South side is also occupied only by Aperture. The building’s exterior facade is heavy brick masonry, and the construction should also do a good job of isolating radio signals from the West half of the building, so if I’m lucky, the CCI won’t be terribly higher than the predictive model. That being said, I am not banking on this assumption and the document is clear:

CCIstats

There is no channel overlap in the 96% of the coverage area. This will certainly change in the validation stage when some signals will be heard from sources outside of Aperture’s control.

Validation is important. We have no way of knowing whether or not we’ve met our design requirement unless we validate, and here I’m trying to imply that validation is not an optional step. This project was sold to the client with validation as an included component.

I also included Ekahau’s Health map as a high-level reference:

Main Floor – Overall Health & Problem Areas

1F - Health

Health Leg.png

Signal Strength – elevator and walk-in cooler, walk-in freezer areas. Minor reductions in signal at the east lab entry zone and radioactive storage room.

Number of APs – Minor spots in the cylinder storage room, walk-in cooler, radioactive storage room, and east fume hood room areas.

SNR – Minor spot inside the walk-in cooler/freezer which is actually within tolerance.

I’m not sure why, but Ekahau calls out SNR (blue tiles) in the cooler/freezer, even though the metric is met on the SNR heatmap. Jerry – if you’re reading this, feel free to comment if you can shed some light on this.

I’ll wrap this post up here, and we’ll look at the other floors next, then perhaps some of the specific obstacles on some of the floors that I’m curious to see how well my predictive results align with the real world behavior.

UPDATE: See the addendum post HERE

CWAP!

I got home from the CWAP bootcamp last Saturday, and, knowing that the CWAP exam was about to switch to the new version at the end of the month, immediately checked Pearson Vue for appointments to write the current version.

Unfortunately, For whatever Monday at 830am was the only appointment available, so I had no other choice but to take it. I had initially thought that it said Monday when I booked on Sunday, so I got quite concerned that I had roughly 12 hours to finish getting ready, but thankfully I quickly realized that I had one week to go – I wrote this morning, and can happily say I passed without too much difficulty.

CWAP has been a huge learning experience. The amount of packet level knowledge is phenomenal, and I’m glad I took the exam before it was refreshed.

Onto CWSP…

Mac – Set your static IP address fast!

A quick update on the last post – but for OS X!

The OS X terminal is more comfortable than the Windows CLI for route/switch guys like me. Here’s how I make quick IP changes in OS X.

You can create command aliases just like in Cisco IOS by adding them to the profile that terminal loads when you open the app. Just open terminal, and type “open .profile”. Here I’ve done just that, and you can see my terminal profile:

profile Sublime Text, Today at 10.21.49 AM

If you’ve never messed with the terminal profile, it will likely be empty. But the basic syntax is straightforward. Save the file and close/reopen terminal for the aliases to become available.

Here are a couple of my examples:

  • “setair 1.2.3.4 255.255.255.0” will statically set my Wi-Fi adapter address
  • “setethdhcp” will revert my ethernet NIC to DHCP
  • “shair” is like ipconfig in Windows, or a simpler version of ifconfig for OS X:

shair— -bash — 139×39 Terminal, Today at 10.26.43 AM.png

Note that any commands running SUDO will prompt you for your elevated password.

Set your static IP address fast!

Hello! Sorry for the radio silence – I have been a little sidetracked from welcoming my second daughter into the world on March 21st! Lack of sleep and going back to work this week are my excuses for a little blogging break – I’m not sure my ramblings would have made much sense anyhow…

But I was inspired by this tweet today:

John here wrote a really cool post about some of the ways he uses the netsh command in the Windows CLI. I knew about the “netsh WLAN show …” commands already, but John has demonstrated a neat way to monitor roaming with a simple loop. It’s elegant because it’s simple and works.

This got me thinking about a little trick I’ve been using for years now with netsh to avoid a certain pain in the arse I would otherwise be dealing with in Windows. Maybe I can help someone with my trick like John helped me with his.

I’m a CLI guy – if you’re a Cisco Route/Switch person, you know why. Heck, I try to avoid taking my hands off of the keyboard as much as possible.

If there is one thing I do a lot in Windows, it’s set static IP addresses on my NICs. And then set them back to DHCP. Sometimes several times a day.

Worse yet, when I need to bootstrap a router/switch/controller/network voodoo box, 9 times out of 10, I’m using wifi to remain internet connected while using my wired NIC to connect to the new unit – a lot of which provide DHCP out of the box. The problem with this is that my Windows wired NIC is preferred and I’m getting a default gateway from the DHCP server on the box I’m bootstrapping, even though that’s a dead end. There goes my internet until I set a static IP without a gateway on my wired NIC.

The default work flow to change the IP settings on your NIC is terrible (Windows 8.1 example):

Start > Control Panel > Network and Sharing Centre > Change Adapter Settings > Right-click adapter > Properties > TCP/IPv4 > Properties: Set your IP/Mask/Gateway if required > OK.

And don’t forget the three windows you now have to close. Then do it all over again to set back to DHCP. Sure, there are some shortcuts you can use to this process, but I still have nightmares about this. Enough complaining – here’s what I do.

First, I renamed my NICs to “wired” and “wireless” in the “network connections” window (after “Change Adapter Settings” in the work flow above). Just right click and rename, it won’t hurt anything and makes it so much easier to read CLI output.

Then I write myself a little script in notepad:

@ECHO off
cls
:start
ECHO.
set /p ipadd=Enter address and mask, press enter:
netsh interf ip set add wireless static %ipadd%
timeout /t 5
ipconfig
pause
goto end
:end
exit

Then I save it as a batch file called “Wireless Static.bat”. But wait, there’s more…

I right-click that sucker and choose “create shortcut”, which creates a “Wireless Static.bat – shortcut” file in the same folder. I rename it to “Wireless Static”, then right-click again and go to the file properties – here’s the magic:

CMD Batch file

The “Target” field will have the full path to the file. I prepend the path to the cmd.exe executable like so:

C:\Windows\System32\cmd.exe /c “full path to script”, then hit “Ok”. Now I have two files, the original batch file, and a shortcut with the CMD icon:

IP bat and shortcut

That CMD shortcut right there can be pinned to the Start page or Taskbar – the batch file can’t.

Still with me? Here’s the result! I pin mine to the Start page, so I hit the Windows key, and click the shortcut I want.

Start Page.png

Here’s the prompt, after I slap in my new static IP. The format is IP address, Mask, Gateway (if required), with a space between each.

Enter Address

I press enter, the script runs the netsh command, and counts down for 5 seconds before running an ipconfig to verify the result (I was remote desktop-ed to my Windows notebook when I took the screenshots, so I erased the wireless NIC addressing output to avoid confusion).

Static Wait.png

Finally, the “pause” parameter in the batch file leaves the output there for me to look at until I’m ready to dismiss it with a tap of the “Enter” key.

Three buttons, one click, and typing the addressing. YES.

You can do another script for returning to DHCP. I’ve got separate shortcuts for static and DHCP for each NIC, but you can modify the batch file to make the user type the NIC name and put it into the netsh command as well so you can use one shortcut for any NIC, if you prefer (this is where it helps to rename the NICs).

Here attached are my basic batch files for anyone who wants to try them out. PDF because wordpress won’t allow me to attach text files.

IP Static

IP DHCP

Wireless Static

Wireless DHCP

 

ESS Easter Eggs

I noticed some tongue in cheek progress bar comments in the the ESS CAD import dialog, so I took a few screengrabs. Here are the ones that were on screen long enough to catch:

Phase 4

Phase 5

Phase 6

Phase 9

Phase 10

ESS decides to stay in the Matrix…

Phase 11

Phase 13

I wonder who Stew is.

Phase 15

Multitasking!

Phase 16

Phase 20

Phase 23

Phase 26

There are some complex calculations involved in designing RF.

Phase 30

Phase 31

Phase 34

It’s always fun to see software engineers with a sense of humour 🙂

Wi-Fu

Howdy. I am a network engineer with a wifi hobby. I mean (cue Keanu) I know Kung-fu: routing and switching, firewalls, and data centre stuff, but I know wifi is an entirely different beast, and my wireless Kung-fu (henceforth “Wi-fu”) is weak.

Wifi has a well known community on the web. In the words of Keith Parsons: “You HAVE to be on Twitter”. I’ve been a spectator in this community via Twitter for a while, and I’ve learned TONS. But I was recently fortunate to meet some people who are a big deal in wifi (including the guy who actually wrote the book that I used to pass the CWNA certification); and I was able to experience the wifi community first hand.

While it was definitely intimidating at first to be in same room as these guys (the Bruce Lee, Mr Miyagi, and Chuck Norris of wifi), the community has earned a reputation for being inclusive and these black belts were omgsupercoooool ambassadors. Whilst they somewhat mocked my great white north heritage, it was no biggie for a few of us noobs to sit at the cool kids’ table for lunch and share a few drinks after class (eh!).

Which is why Im not surprised that I’m here trying valiantly (VALIANTLY) to not type “Dear Diary…”. The wifi community is also big on contributing to said community, so I was quickly asked about my blog. Everyone in wifi has a blog, so I was a hoser because I didn’t (extrapolation mine alone and tongue in cheek :P).

So now I’m a hoser with a blog. “Net Gain” was the most clever play on wired and wireless networking I could come up with in ten minutes.

Here’s to hoping that either:

-I remain relatively anonymous and therefore continue to embarrass myself to my direct clients and colleagues.

or

-Someone learns something from this. My apprentice seems to be doing alright, but who knows if that will translate into a larger scale experiment.

Subsequent posts to be networking and wifi-centric. Probably rant-y and self-deprecating!