G2… V2!

Today the cat is out of the bag… check out the full review of the cool new AirCheck G2 features from our secret MFD2 session right here.

I think this is a killer update to the G2 – here’s a quick recap:

iPerf performance testing. (!!!!!) Not only can you now check upstream and downstream throughput against an iPerf server, there’s even a slick new accessory so you don’t have to build your own iPerf box. I’ve been using this on projects and it’s a great way to check only the links you really want to – rather than pulling out speedtest.net on my iPhone where I can’t tell if the internet link is the bottleneck. The accessory looks just like a darker coloured LinkSprinter and can run on PoE (or a couple of AAs), and has a basic web server. Hot damn.

iPerf

Captive Portal Support. Another big feature, this has made my G2 fully functional where it used to have a fatal weakness – captive portals would render it useless for active association testing. Now the built-in browser makes it possible to fully enter authentication credentials or accept a AUP. Brilliant.

Captive Portal Authentication

ACL / Authorization classes. This is really AP categorization. Set a big ‘ol flag on that unauthorized AP so you know it’s, well, unauthorized. The G2 will also flag rogues detected on the auto test. Could be handy.

Interferer Identification. I relate this to Cisco’s clean air. The G2 can now detect things like Bluetooth devices, Microwaves, and other sources of interference. The G2 shows duty cycle and which channels are affected. This is not full spectrum analysis, but meet your new handheld interference locator. Shut the front door.

Interferer List

Interferer Details

 

 

Packet Capture. Save your session file and now optionally add a PCAP of all the testing you did; then take it away for offline analysis. Includes radio tap headers. Yes please.

Channel Overlap View. Another way of visualizing where all of those APs are camped out, in a view we’re all familiar with these days. From the channels menu, find the overlap button in the bottom left corner to get to the new view. from there, you can tap on any of the parabolic arcs to get an expanded view of the AP BSSIDs that are on that channel.

Ch Overlap View

Channel Overlap View

 

Phew. Let’s take a break right there. That’s a LOT of big features that just got jammed into our handy little tool. Way to go Netscout on adding value to the platform!

If you have MasterCare support for your AirCheck G2, download firmware version 2.0.0 from this link.

You can also find a technical overview from Netscout here, and a recent webinar where Netscout talks with George Stefanick with Houston Methodist hospital about how they’re using the new Aircheck G2 features here.

 

Hours saved by the AirCheck G2

I really enjoyed visiting Netscout HQ during Mobility Field Day 2. They just might have the coolest social media manager in the tech industry (Hi Kendall!!!) and I was excited to meet some of the people on their wireless team behind my favorite tool, the AirCheck G2.  Chris Hinz pointed out a couple of things I didn’t already know about my Aircheck G2. Check out Chris’s presentations at the Tech Field Day page: Netscout at MFD2

In a similar vein, I thought I’d share my two favorite G2 features. I just spent an entire month on a industrial mine site physically recabling fiber optics and replacing switches.

To get an idea of the environment I’m talking about, take a look at these pics:

This is nothing linear about this facility, and I got turned around every day. Thankfully, my G2 has saved me from  hours of frustration on more than one occasion.

I’m almost ashamed to say that I probably use the G2 to trace wires more than I use it for troubleshooting wireless. Looking back at the pics above, you might imagine how difficult it was to follow cables visually. Without a tool like the G2, it would have been next to impossible to determine what was on the other end of a cable. The Aircheck’s Ethernet test has the ability to read CDP/LLDP and give us the name of the switch and the specific port number we’re connected to.

Screenshot0010

Not to mention confirming that PoE is available, that we’re connected to a Gigabit port, and that DHCP is working. We can see that the G2 has even reached out to Google to confirm that there is a working internet connection, and then uploaded all of the test results to my Link-Live dashboard (a free service).

Screenshot0011

Besides tracing wired endpoints while I was replacing switches, I was also challenged with some actual wireless reconfiguration. I needed to reboot several wireless access points, but few of the switches in this facility were PoE enabled, and all of the (old 1242s) APs were powered by AC adapters. No easy power cycles from the switch port for me. Now I have the opposite problem from above – I know where the switch is, but there’s no way I can trace cables visually to the AP. AirCheck G2 to the rescue again:

Screenshot0012

The AP locator gives me an easy “hot and cold” way to find an AP by signal strength. I could do this with a laptop and Inssider or Wi-Fi Explorer Pro, but in this industrial facility, safety concerns make this an impractical approach (and safety rules actually prohibit having both hands full). I need to be able to have two free hands, not to mention that I am wearing gloves, along with a hard hat, safety glasses, and sometimes earplugs.

The G2 simplifies the whole process, giving me a visual indicator as well as an audible beep like a metal detector. I haven’t tried it, but the spec sheet says you can even plug in a USB headset instead of listening to the beep from the unit, which, looking back, would have been useful for working with ear protection. I can also slide the unit into a pocket in order to have both hands free for going up and down stairs and it’s small enough to operate with one hand once I’ve chosen the AP to track down. These are all big improvements over a laptop when I’m not working in a carpeted office environment.

These APs are also al in NEMA enclosures in a facility that has NEMA enclosures everywhere; and most aren’t protecting APs. Suffice to say, it was much easier to locate the APs I needed with the G2. I am even questioning my earlier decision to not purchase the directional antenna for the G2 (which Chris discusses in the TFD presentation linked above). I will gladly fork out the cash for that tool if I ever have to spend a month doing this kind of work again.

Netscout has done a great job with the AirCheck G2. Best of all, the G2 is still a new tool – so expect plenty of innovations and improvements to the G2 feature set to come out of Netscout soon. I can smell good things cooking in the Netscout kitchen…

Wearing the Cape

Looking at Cape Networks after their presentation at Mobility Field Day 2.

There’s a trend in the networking industry of turning client devices into trustworthy monitoring and troubleshooting devices. In the past it was common for users to call the network team to say “the Wi-Fi isn’t working” and the network team would promptly log into the controller/dashboard/APs or other network gear and say “it looks good from this end.” Especially with Wi-Fi, it can be very difficult to understand the client perspective when you’re looking at the network – it’s like the other side of the fence.

Cape Networks is doing a solid job of putting the network engineer on the client side of the fence. Check out the #MFD2 presentation here:

Cape Networks Presents at Mobility Field Day 2

Cape gives us a client device whose entire purpose is to report standard, trustworthy, and consistent performance metrics to the network engineer, in their own language. It’s an interesting idea if you think about it – they’re making a user talk like a network engineer… usually the network engineers are tasked with putting themselves in the users’ shoes.

No more “It was WAY faster yesterday!”

How do I even measure that…?

No more “The Wi-Fi is down everywhere!”

Does that really mean Wi-Fi, or did DNS crash again?

How about a user that can tell you that how much download throughput they’ve had from YouTube for every ten minutes over the last 24 hours, and even as far back as the last 30 days?

Cape - Youtube perf

How about a user that can give you bar graphs tying RSSI to Channel Utilization, Retry Rate, and BSSID, again for every ten minutes in the last 24 hours to 30 days?

Cape - Wifi stats

Oh and this user has PCAPs every time they have a “bad” experience, triggered by crossing a performance threshold.

Cape - PCAPs

But wait… there’s more! Your superhero user has iPerf stats too.

Cape - iperf setup

Icing on the cake: when this user can’t connect to Wi-Fi, the tests still run, and you are still seeing the results in your monitoring dashboard because the user is sending you the stats via their cellular hotspot. There’s also a battery – so the sensor can still send you a notification via cellular when it loses power. In fact, my office sensor has been the first way I find out someone has blown the 2nd floor breaker every time without fail. Damn 100+ year-old buildings and interns with their space heaters. But I digress…

I have junior engineers that can do this for me. But it’s not productive to have them sitting in a remote office running these tests all the time. Plus my boss would make me feed them and give them bathroom breaks. My Cape sensors dutifully sit on the wall, PoE powered, reporting stats 24 hours a day, 7 days a week, 365 days a year, without a dime in overtime pay.

If you’re like me, you’re also digging this dashboard UI. Cape has some killer UI designers. The whole interface is easy to navigate and configure. Having an intuitive and simple UI is an advantage that is hard to overstate – if the functionality is there, an easy UI makes the Cape sensor the Most Valuable Employee you’ve got – but you never have to promote them and search for months for a replacement that will never be as effective and still a pleasure to deal with.

There is some room for improvement. Email notifications get annoying and are often just noise, but this is an issue with any NMS too. I’ve found myself ignoring most notifications, because I’ve learned that those I do check into are often back to normal by the time I log into the dashboard, usually just a couple of minutes. Tuning alert thresholds can help with this. Better yet, I’ve suggested to Cape that something like a mobile app that can give me the green light/red light behaviour without emailing me to death would be a welcome addition – and I’ve been told this is being explored.

Cape - thresholds

Which is another strength – like all of the good cloud based services these days, Cape is pushing out new firmware and features on a regular basis. Both iPerf testing and PCAPs are features that have appeared since I first got a sensor to test in February, and the Cape team is hard at work making improvements all the time.

I’ve had Cape in the office and lab since then, and it definitely beats every infrastructure based NMS I’ve worked with. Keep an eye on these guys and reach out to their team if you’d like to try them out. They’ve been very great to deal with as a company.

In the interest of full disclosure, I won a Cape sensor with free service as a door prize at the WLPC conference in February, and was also provided a sensor as a #MFD2 delegate. I have not otherwise been paid to review their product but have chosen to do so because I have been impressed with them as a solution and company.

 

 

Here comes Mobility Field Day 2! 

I’m currently sitting in the Saskatoon airport waiting to board my first flight on the way to Mobility Field Day 2 in San Jose, and I am really excited to be a delegate for the first time!

Side note: as I prepare to spend two days seeing what the best in the mobility industry are up to, I’m disappointed to be sitting at YXE airport using my hotspot because the Wi-Fi is currently completely inoperable. It had been working very well on recent trips. Oh well.

First of all, I’d like to send a little shout out to the Tech Field Day crew – they have been awesome in helping us get ready to travel to San Jose and participate in this fantastic event. They’ve clearly done this before and know all of the steps to make sure everything goes as smoothly as possible. Thank you TFD team!

Tune into MFD2 on Tuesday, July 25 here. Dont forget to follow the hashtag #MFD2 on Twitter during the event to catch our up to date thoughts, and mention me (@CdnBeacon) or any of the other delegates if you have any questions you’d like us to ask!

Here’s what I’m looking forward to:

Mist Systems

I’ve had the chance to play with the Mist APs a little bit recently, and I’ve been impressed. It was very easy to get an SSID spun up, and what was really neat was how easy it was to setup their virtual BLE (Bluetooth low-energy) beacons. It took me longer to find the floor plans for my house (and I already knew where they were) than it did to set up the beacons and use their app to watch myself wander around the house. I wasn’t terribly familiar with Mist’s solutions before this, so I’m really looking forward to going in depth. Keep your ears open for things like “blue-dot experience” and lots about client experience analytics.

Mojo Networks

Mojo has gone through some reinventions over the past years. I was more familiar with them as Airtight, but they have a new focus now. I saw them at WLPC and their mojopackets online PCAP analyzer it pretty neat. I’m very curious to hear about their plans for Wi-Fi on open hardware. We’ve heard that idea before, let’s see if someone can make it a feasible reality for the enterprise, and in my case, industrial use cases as well.

Cape Networks

I was fortunate to come home from WLPC with my own Cape sensor, and I’ve had it running in my office ever since. Cape has a great UI, making it really easy to see the important metrics – how is the Wi-Fi working? I think it’s narrow-minded though to think of the Cape sensor as a Wi-Fi sensor only, because it’s really good at letting me know when the network isn’t the problem. Cape has some great potential and now that I’ve spent some time with it, I’m ready with some ideas for tweaks and improvements – bring your notepad, Drew. 

Nyansa

Nyansa has been doing some really interesting work in gathering huge amounts of Wi-Fi client behaviour data, and turning it into informative insights. This is another one that I am looking forward to learning about a bit more in depth. With so much client variation in our environments, I really love the idea of being able to identify, for example, that any iPhone 6 running iOS 9 has a bad habit of sticking to an AP well past when it should have roamed. 

Netscout

One of my favorite tools is my Netscout Aircheck G2. There is a lot of talk in the Wi-Fi industry these days about how difficult it is to get relevant data about Wi-Fi and client performance from the wireless clients themselves. My G2 is great for giving me data from a client perspective, and sometimes there is no substitute for a handheld tool. I’m still a network engineer as much as a mobility engineer, and I admit I’m trying to find a good reason to buy a LinkRunner AT. Netscout’s tools are great for giving me the answers I need quickly. 

On-premise IT roundtable

Rumor has it there might be a recording of Gestalt IT’s On-premise podcast. I’ve been enjoying these episodes since they started as a “just the right length” dive into various issues and technologies for our industry. Keep an eye out for an episode from MFD2 on iTunes, or the website here.

See you in San Jose!

Changing Wireshark Link-layer Header settings on Mac OS

This is one of those quick posts aiming to save me and (maybe you) some time the next time I forget this.

On my Mac, I use Wireshark primarily to capture Wi-Fi traffic, in monitor mode. I want to see the Radiotap and 802.11 headers. Usually I leave Wireshark set this way.

On occasion, I actually use Wireshark to inspect higher level traffic – I want to see the IP addresses and TCP/UDP ports etc. I might be troubleshooting an issue and am using my Mac as the client trying to recreate the issue – so I don’t need monitor mode for that. Simple enough – turn it off in the interface settings (Find this button on the Main toolbar Wi-Fi. en0 Wireshark, Today at 9.20.38 PM  to access the menu, then scroll to the right to find the Monitor mode drop down and make sure your Wi-Fi interface has this disabled):

Wireshark · Capture Interfaces Wireshark, Today at 9.30.03 PM

Then just set the Link-layer header back to Ethernet, just like your other interfaces:

Wireshark · Capture Interfaces Wireshark, Today at 9.30.57 PM

Except “Ethernet” isn’t an option. I could’ve sworn that’s what it is set to by default after install…

I can’t believe this still trips me up every few months. I spent half an hour the other day scratching my head, when the trick is simply to restart Wireshark. Close it entirely, reopen it and voila:

Wireshark · Capture Interfaces Wireshark, Today at 9.34.30 PM

Ethernet is back! Also, the 802.11 options have disappeared because we’re no longer in monitor mode. Now I can see Ethernet, IP, and TCP/UDP headers again:

Wi-Fi. en0 Wireshark, Today at 9.35.58 PM

In comparison to capturing 802.11 frames in monitor mode:

Wi-Fi. en0 Wireshark, Today at 9.38.08 PM

I keep forgetting the need to restart Wireshark for the Link-layer options to change #facepalm.

Note: you also need to restart Wireshark after enabling monitor mode before the 802.11 options will show up in the Link-layer header drop down option.

Or maybe it’s just me. I’m confident that I’ll still forget all about this post next time I try to show a University Computer Engineering class how many packets it takes to load the Facebook home page.

It was 781 (including DNS lookups and a couple of retransmitted frames), in case you’re wondering…

PING! Not always what you think! – Meraki Wireless troubleshooting

I’m quite fond of the Meraki dashboard. I’ve seen firsthand how it can enable lean and low-skilled IT departments to manage more of their own networks themselves. The dashboard GUI makes it easy to find status and troubleshoot at a basic level, but it’s still important to actually understand what is going on under the hood.

Here’s an example. If you’ve ever seen the Meraki dashboard, you’ve probably seen the Ping tool on every client status page. Here, a Meraki AP is successfully Ping-ing my MacBook Pro:

pign-success-invalid-ip

Pretty straightforward. Ping the client, client responds, client is online and working, right?

If you have a Meraki Security Appliance, you may stumble across this little note on the Addressing & VLANs page:

ping-is-arp

Wait… Ping is based on ARP? What happened to ICMP?

We may have jumped to conclusions here. As it turns out, Meraki is not using ICMP like most of us would assume. Here’s an example of a few PCAP frames of that same Meraki AP ARP-Ping-ing my MacBook Pro:

directed-arp

Notice this is a directed-ARP; the Meraki AP (MAC 13:da:90) is sending an ARP request to the MBP (MAC 91:75:d8) rather than sending a broadcast. That is, the Meraki AP already knows the MBPs MAC address. But the ARP response tells the Meraki AP that the MBP is alive, and online – just like an ICMP Ping.

This brings about an interesting question. We network engineers often use Ping as a way to confirm that the network is working. A successful Ping means that routing, IP addressing and the physical path are all functioning correctly at layer 3. But if we’re doing a Ping at layer 2 with ARP – would we be wrongly assuming all is well when we get a response, just like with ICMP?

There is definitely some potential to make incorrect assumptions here. In fact, even though that screenshot above of the Meraki AP Ping-ing my MBP has a loss of 0%, at the time, my MBP had an incorrect IP address and was not Ping-able by other devices in the network (well, via ICMP at least). Here’s the PCAP’d ARP frames from the same time as that Ping output:

directed-arp-wrong-ip

Almost identical, except that both the ARP request and response are from 10.11.3.1, when the subnet is actually 10.11.30.0/24. However, the client is still responding, albeit at layer 2, and that’s good enough for the Meraki AP.

Now, I do think this is one of those things where the vendor has made an odd decision to label this as a Ping without being clear about what is actually being done, but it is after all our responsibility as the network engineer to know what we’re looking at. There are similar examples where traceroute can use UDP or ICMP, depending on the OS, and now you know that sometimes Ping is ARP instead of ICMP.

Here’s the relevant documentation:

Meraki Ping Tool

Wireless Professionals Compensation Survey

Today, Wednesday, November 30th there will be a one-day independent survey to gather information on the current state of compensation in the Wireless LAN community. We respectfully request your participation in this 90-second survey. The current results will be available to all survey takers as they complete the survey for instant feedback. Later, the complete results will freely reported back the entire community.
Thank you for your support and participation!
http://surveymonkey.com/r/wlccs2016 – Wireless LAN Community Compensation Benchmark

Cisco Live! recap – Tuesday

I was pretty exhausted Tuesday morning. With two young kids at home, I run on a minimum of sleep already, and all of the activity of CLUS pushed me over the edge very quickly. When the alarm went off Tuesday AM, I had to make a command decision – I knew I was not going to be able to keep up the pace set at the start without recharging my batteries, so I reset my alarm and went back to sleep.

Yep, I was a rookie at CLUS, this year, and I’ll try to be better prepared next time. Unfortunately, that means I had to miss my morning session “Fog Computing at the World’s Largest Copper Mine”. Which it too bad, because I spend a lot of time in mining and we have been looking into Fog Computing a lot lately.

The presentation is missing from the link above, but thankfully the session video is there. Funny that the first thing presenter Francisco Soto says is “Thanks for waking up early for this.” Now I feel terrible.

RowellRobMitch, and I had a meeting setup before lunch with Jerry Olla from Ekahau. I was stoked to be meeting some of the Ekahau crew! Jerry sprung for coffee, and that coupled with a little extra beauty rest meant I was having a pretty good start to day #2! Thanks Jerry!

Jerry answered some of our nagging questions about using Ekahau Site Survey. ESS is indispensable in the WLAN design stage for helping to develop real requirements and turn them into actual channel plans, power settings, antenna coverages. Without a tool like this, many people are just “eyeballing” WLAN design. Jerry also showed us a neat little project he had been working on using an ODROID C2 to build a custom iPerf server.

Jerry is awesome. We may have thought that there was some potential to abuse our new insider relationship with Ekahau to get our hands on some sweet, sweet swag:

Buoyed by the warm reception from Jerry, and our unrequited love for Ekahau, we weren’t ready to part ways just yet, so we headed over to WoS to meet the rest of the Ekahau crew!

Jussi Kiviniemi is well known in the Wi-Fi community, and an excellent representative of the Ekahau team. I was excited to meet him in person he is all class! The whole Ekahau crew just has the right approach to being part of the community. For example, Hannele managed to dig out some primo swag in return for some testimonials:

Maybe I was excited most of all for the legendary Finnish candy. I wear my Ekahau Polo to work all the time.

I may have gotten a little carried away:

Also this happened. No explanations will be forthcoming.

Big Kudos to Ekahau for their continued community support and participation. Also a well deserved shout out to Robert Bartz!

There were TONS of other badass vendors to meet!

Check out Smitty and the team at Acceltex. They’ve got a nice spread of antennas and even better some well thought out brackets and mounts for their own gear and the Cisco APs with internal and external antennas as well. Meru Mitch swears by these guys.

We are all pretty pumped this summer about the new Aircheck G2 from NETSCOUT, and meeting their social media manager Kendall was another highlight.Robb was doing his best to see if a Aircheck G2 could find it’s way to his home somehow (Kendall, he ended up paying good money for one – so you won that round!). I think Kendall probably saw more of us at CLUS than anyone would have wanted, but if anyone could handle these hosers, it was her.

That wouldn’t be the last Kendall saw of us…

Ok I did also squeeze in a session Tuesday afternoon. BRKEWN-3014 “Best practices to deploy high-availability in Wireless LAN Architectures with Patrick Croak.

  • Patrick had some great advice regarding minimizing the number of SSIDs:

BRKEWN-3014.pdf (page 17 of 120) Preview, Today at 9.28.03 PM

  • And a good reminder about client based CCI:

Check out the presentation link above for all of the good stuff.

I was looking forward to the evening events on Tuesday, namely… the CCIE Party! Steve, Mitch and I were off to the Hard Rock Hotel for a beach party.

With Food, Music and Beer taken care of, it was back to meeting some familiar names.


Brian McGahan with INE, whose videos are in part responsible for me qualifying to attend this party. Brian was pumped about my tramp stamp.

Amy Renee is a well known ginger CCIE with a well known sparkly bat. My kids are gingers, so we cool.

I also had the pleasure of meeting and shooting the breeze with Fish herself. I’m confident that I learned something just standing near her.

I learned that Tom Hollingsworth is also a fan of the CCIE tramp stamp, and I was glad to meet one of the minds behind Tech Field Day. I’d love to participate in a TFD or better yet Mobility Field Day, so fingers crossed!

The biggest surprise though, would come from closer to home than expected, when I had the pleasure of meeting another fellow Canuck and Wifi guru @wirelessstew!
I was blown away when Stew said that, not only did he know who I was from my (very new) online presence, but that he had hoped to meet me and find out more about me and my mobility experience. Stew would turn out to be the final, and likely most influential of the hosers group of Canadians (Stew, Steve, and myself), and honorary Canadians, Robb and Meru Mitch.

Us Canadians were a bad influence on Mitch:

But the night was still young so we decided to brave the Vegas heat and check out some more of the CLUS festivities. It was only logical that we take our Canadianized Meru Mitch to the Cisco Canada party. Beer was once againMore beer, music and food, although we never did figure this part out:

So now I have to figure out how to introduce Mitch to poutine…

TL;DR: Tuesday was the meet/make friends/network day. CLUS is an amazing opportunity to make connections and I have already benefitted from my new connections.

Also, I was glad I slept in.

Stay tuned, more shenanigans came Wednesday.

When a 6 means 5 – Cisco WLAN QoS

Making sure QoS does its job as expected includes ensuring that the WLC is properly configured to translate between WMM markings on the WLAN and CoS/DSCP markings on the LAN. Many of us know that the WLC uses the Platinum QoS profile which is associated to the Access Category (AC) AC_VO which uses a user priority (UP) marking of 6. On the wired LAN, we tend to use a layer 2 CoS (or 802.1P) marking of 5, which is also usually mapped to a layer 3 DSCP marking of 46, or EF. So we know that a WLC or AP should map the UP 6 to a CoS 5 when bridging frames between the WLAN and LAN.

I’ve been reviewing some past projects, and I was reminded that Cisco documentation used to recommend that we map UP 6 to CoS 6. This didn’t make a lot of sense to me at the time, especially when I wanted the voice traffic to end up with a CoS 5 or DSCP EF on the wired LAN. Here is a screenshot I had taken from the Cisco configuration guide at the time:

Cisco Unified Wireless QoS Tech Note - Cisco Safari, Today at 8.28.19 PM

Sometimes mistakes make their way into documentation, so at the time I decided I had better test to see what the WLC would do with these settings. I set up packet captures on the wired switch ports and used a Cisco 7925 handset to get WLAN captures. With the QoS profile mapping set according to the screenshot above, here is what happened:

  • The 7925 marked the voice payload frame with UP 6 at L2, and DSCP EF at L3
  • From AP to WLC, the CAPWAP encapsulated frame was marked with DSCP EF
    • APs were on access ports, so no L2 CoS markings
  • When the WLC placed the packet on the wired LAN as an 802.3 frame, the markings were L2 CoS 5 and L3 DSCP EF

Wait – didn’t we map the Platinum (UP 6) profile to CoS 6? Even better, if we mapped the profile to Cos 5, the result was… exactly the same!

Turns out Cisco’s was saying one thing and doing another. Here’s a recent tech-note where they come clean:

Cisco Unified Wireless QoS Tech Note - Cisco Safari, Today at 8.58.42 PM
source

 

 

I knew I remembered this from somewhere! What a odd behaviour. Note that the all that has changed is the default setting and thus the recommendation – we should map WMM 6 to CoS 5. The behaviour hasn’t changed and if you map to CoS 6, well then Cisco still goes ahead and spits out a 5 anyhow.

And frankly, that’s the right choice in my opinion.

My First Design part 2 – Overall design

I want to thank everyone for their feedback on the first post in this series! Next I’m going to share the “Overall Design” section of my first predictive design project. This section describes some of the specifications that the predictive design is based on, like the AP transmit power and placements.

This section is a little verbose – the client does not have a lot of expertise in RF so I wanted to give them some context to read; but in the future I’m hoping to clean this up. Recommendations or examples are welcome!

A couple of notes:

  • While this section is technical, I did try to keep it understandable for non-experts. We had an in-person meeting where we went over the document and they asked questions. At this time, they are primarily concerned with telling the architects where the Ethernet pulls should be located (with service loops to allow for repositioning).
  • You will see RRM referenced. Yes, the client (and I) are planning on allowing RRM to make channel and power level decisions – but I will be tuning RRM from the defaults.  I would love to hear recommendations on good ways to do this to work with this design. I have a few years of experience with Cisco’s implementation, but could certainly use a refresher. I’m planning to decide on the RRM settings during the validation phase.
  • I’m curious to hear feedback on the AP power settings – did I make a good choice?
  • Also curious to hear feedback on the choice to use 40MHz channels. There are non-VoIP clients which have less stringent RF needs, but who can make use of the bonded channels. I think the indirect benefit to the VoIP handset in addition to the other clients makes this a good choice… am I right?

I realize that some of these items rely on details regarding the building. Here’s a sneak peek of the placements and map of the 2nd floor:

2nd Floor - Access Points

Aperture science will occupy all 3 floors of this side of the building, which is a mix of office space and research/lab areas. I’ll go into more detail on some of the materials and spaces in upcoming posts.

Credit to Steve McKim of Great White Wifi for his post on AP to client power matching which I referenced in describing the power settings for the design.

I’m really looking forward to hearing the Wi-Fi community’s opinion on some of these points!

2.4.  Overall Design

Design Power levels:

Device 1702I AP 7925G Handset
Max Transmit Power 22 dBm 16 dBm
Antenna Gain 4 dBi 3.11 dBi
Design Minimum Transmit Power 13 dBm 13 dBm
Design Maximum Transmit Power 16 dBm 16 dBm

In keeping with Aperture’s current WLAN hardware, the WLAN is modeled using only the Cisco 1702I model AP, which has an internal omni-directional antenna.

The design assumes that the APs are mounted at a ceiling height of 8 feet, with standard alignment. For the 1702I, the standard alignment is horizontally mounted, with the Cisco logo facing the floor.

APs are all modeled using a reduced power output in both the 5GHz, and the 2.4GHz band, where enabled, of 20 mW (or 13 dBm), which, when the antenna gain is taken into account, amounts to a total EIRP (Effective Isotropic Radiated Power) of 17 dBm. The 7925G-EX handset is capable of a maximum power output of 40 mW, which is 16 dBm. This means that the maximum output power of the handset is higher than the modeled power of the AP. Note that the handset will likely operate at a lower average power level (i.e. 13 dBm) when possible to conserve battery power.

A higher power on the AP compared to the client device can cause issues where the client may “hear” the AP at a strong signal level (e.g. “Full Bars”), but the AP may not be able to hear the client at an adequate level. However, antenna gain (in contrast to output power) improves the ability to both hear and to be heard. Therefore, an increase in antenna gain is preferred over and increase of output power when there is any imbalance between EIRP of the client devices and the APs.

With this design, an example can be made showing the signal levels from the perspective of the AP and the handset; in this case, at 50 meters apart. Power gains and losses are simple additions/subtractions:

Link Budget – Cisco 1702I AP at 13 dBm and Cisco 7925G Client at max power

Downlink Uplink
AP sending to Client Client Sending to AP
Transmit Power 13 dBm 16 dBm
Transmit Antenna Gain 4 dBi 3.1 dBi
Effective Power (EIRP) 17 dBm 19.1 dBm
Free Space Loss -80 dBm -80 dBm
Receive Antenna Gain 3.1 dBi 4 dBi
Received Signal Level Client hears -59.9 dBm AP hears -56.9 dBm

Here the client hears the AP at -59.9 dBm, and the AP hears the client at -56.9 dBm. This means the AP is hearing the client better than the opposite. This also means that the AP could increase its own power slightly (matching the client) if necessary.

At one power level higher, the client hears the AP at the same level as the AP hears the client – a good, equal link:

Link Budget – Cisco 1702I AP at 16 dBm and Cisco 7925G Client at max power

AP sending to Client Client Sending to AP
Transmit Power 16 dBm 16 dBm
Transmit Antenna Gain 4 dBi 3.1 dBi
Effective Power (EIRP) 20 dBm 19.1 dBm
Free Space Loss -80 dBm -80 dBm
Receive Antenna Gain 3.1 dBi 4 dBi
Received Signal Level -56.9 dBm -56.9 dBm

Therefore, the design allows some room for transmit power to be adjusted by Cisco’s Radio Resource Management (RRM) to close perceived coverage holes where clients are at the edge of a service area.

Finally, if the AP is operating at 13 dBm and the handset reduces power to 13 dBm to save battery life:

Link Budget – Cisco 1702I AP and Cisco 7925G Client both at 13 dBm

AP sending to Client Client Sending to AP
Transmit Power 13 dBm 13 dBm
Transmit Antenna Gain 4 dBi 3.1 dBi
Effective Power (EIRP) 17 dBm 16.1 dBm
Free Space Loss -80 dBm -80 dBm
Receive Antenna Gain 3.1 dBi 4 dBi
Received Signal Level -59.9 dBm -59.9 dBm

In all 3 examples, the Received Signal Levels are quite strong, and the handset RSL is well above the -67 dBm requirement.

 

The 5 GHz band is the recommended band for serving VoIP due to the higher number of available channels and significantly lower likelihood of interference from non-Wi-Fi sources such as microwaves and cordless phones. As such, the design is for the requirements to be met only in the 5 GHz band. This design uses 40 MHz channels, which bonds two adjacent channels together, for more than twice the available bandwidth than a single channel.

While the 7925G handset is not able to use 40 MHz channels, most data devices can, and these devices require less airtime to send data when more bandwidth is available. Since they require less airtime, more is left available for the devices that can only use a single 20 MHz channel, so there is an indirect benefit for the handset.

Once the requirements were met using the 5 GHz band, the 2.4 GHz band was designed without attention to meeting the requirements. Instead, coverage levels were maximized as best as possible with the minimum amount of co-channel interference. The intent is for Aperture to push all capable client devices to the 5 GHz WLAN, and to only use the 2.4 GHz band with clients that are unable to use 5 GHz until they can be replaced.

Again, let me know what you think in the comments or on twitter @bmroute.