Rick shares insights on problem solving for Wireless LAN Professionals
Richard "Rick" Steiner
Senior Systems Engineer
Read the Transcript
Podcast Episode 203 - Rick Steiner.mp3 transcript powered by Sonix—easily convert your audio to text with Sonix.
Podcast Episode 203 - Rick Steiner.mp3 was automatically transcribed by Sonix with the latest audio-to-text algorithms. This transcript may contain errors. Sonix is the best audio automated transcription service in 2020. Our automated transcription algorithms works with many of the popular audio file formats.
Wireless LAN professionals podcast episode 203.
To answer your question, I do think that people generally tend to lean on what's already out there and available. And if they can't step outside the box or if they're unwilling to step outside the box in order to common approach a problem with a new angle that tends to limit their capabilities in solving the problem.
Wireless LAN professionals is a place to educate, inform, encourage and entertain those involved in wireless LANs. This wireless LAN professionals podcast is an audio manifestation of these goals. Our host is a wireless land veteran, consultant, designer and teacher Keith Parsons, and now the podcast for wireless LAN professionals by wireless LAN professionals.
Well, Rick, thank you for being here. How are you, sir? I'm doing well. How about yourself? I'm doing good. Yes, yes, yes. It's nice and warm here in Arizona, but I am doing good.
Up here in Washington, we've got some rain coming in, hanging around this weekend. We had some beautiful weather before, but it's definitely made a change.
So for those who don't know you, Rick, introduce yourself. What do you do in Wi-Fi and what are you up to these days?
Absolutely. Well, I go by the name Rick. My actual name is Richard Steiner. I work for a small VAR out of Seattle, Washington, called the Arrow Path, Inc.. We are primarily a professional services organization. We deal with pretty much anything Wi-Fi. But we are also primarily a Cisco VAR. So that encompasses both the the Cisco enterprise line as well as the Meraki line. We also have done Mist and Aruba deployments.
We travel all over the world, performing site surveys, AP amnestic surveys, troubleshooting, pretty much encompassing all types and manners of Wi-Fi professional services from that standpoint. We also have gotten into some point to point links and point to multipoint links and things like that for some of our more hardcore wireless clients. But that's pretty much what I do. My official title is Senior Systems Engineer, but realistically, I am the subject matter expert on the payroll, so pretty much cover just about anything wireless related. It comes to me.
And how did you get start or find your way here?
Well, I actually started a long time ago in the service back. I entered in the Army in 1990. And it was a newer military occupational specialty, or M.O.S, that was brought out of the need for doing things like telephone switching out in the field. And so they started with this program where they took some off the shelf equipment and put it together in a new way and basically created a mobile telephone switching operations scenario. And I did that for a while. Mostly it was just programing the the phone switches. But we also had some S.H.F and UHF radio shots. So I had to learn radio propagation and that type of stuff after I left the service. I entered into my cabling phase. And so I spent several years as a cable installer, whether it was, you know, cat five, cat six, fiber optics, that kind of thing. And that kind of just started everything down the road from that standpoint and then kind of got a little bored with the cabling side. And so I ended up moving into wireless, probably about to get an old, 15, 18 years ago, and have basically worked with the guys that are that I'm working with now in different capacities because Airopath has actually bounced around a few times and changed hands, quote unquote, or changed names a couple times. But I've worked with these guys for probably about ten or fifteen years of that timeframe. So. And so that's basically it. And then and I've had been a Cisco vare for pretty much forever. We didn't make a change over to Aruba. So I started, you know, getting all of those certifications and and things of that nature from the manufacturers and then started down the CWNP course track.
I was going to ask you what your path in that versus your Cisco search path.
Yeah. So as far as like my CWNP probably about I don't know, about 10 years ago I was turned on to CWNP by my current CEO, Brad King, and he basically said, no, this is really good vendor agnostic kind of certification. And it really delved into it. Now, I obtained my CWNP couple years ago. I am CWNP number 234. So, you know, from that standpoint, I mean, went through all the CWNP certs and I actually enjoyed the CWNP program a lot better than I do the manufacturer of programs only from the standpoint of it. It's more vendor agnostic and it seems like it's more during the ised information across a broad range of subjects.
Absolutely. What about your Cisco's thirt path where you land in that?
Well, I've kind of bounced around. I've been a CCMA for many, many years, but I've done like the CCMA Wireless. I've gone down the security path. I've been toying with the idea of going to the Cia.. I'm a little hesitant to do that or have been hesitant to do that here in the last couple of years, only because of the fact that they were changing the program so much that I didn't want to get stuck into a situation where I was studying for one thing and then finding out that that wasn't something that I needed. So now that they've sort of settled that out, I may pick that mantle up again. As far as like Aruba is concerned, I've been through the Aruba path and. Currently, NASED X number 128. I never went to the ACM max level, but I did go through the professional level back in the day when a RuBo was before a RuBo is HP. And I'm up actually this year for my ECD X research. So I need to get that done. So anyway, I mean, I'm I'm all over. As far as that goes, I'm also what I guess they call it the Mixmaster. I'm one of those people as well. So that's great. Got a lot of certifications. It seems to be the classic way of doing things in the I.T. world.
Well, from your presentation, it comes across that you are always a learner and always diving in and problem solving. One of the things that really stood out to me in your presentation is kind of the creative problem solving a WLPC. You talked about a specific thing and we'll get more into that. But. You had these three steps to creative problem solving. Assess. Learn and emulate. And we can talk about how you appropriated that with this specific issue. But tell me a little bit about that process and those you know, where did that come from? And just kind of your approach to problem solving.
Being that the subject matter expert for an organization. And, you know, even though we're a small organization, most of my learning that I've done has actually been trial by fire. The organizations that I've worked for, they've generally been the sales people. And this is going to sound bad. But now I'm going to say it anyway. The sales people will generally sit there and nod their head and saying, yes, we can do that. And to the customer. And then they turn around us and go, OK, how are we going to do this? So being in that situation more than once has lended itself to a very broad range of knowledge and definitely a broad range and broad spectrum of capabilities. And so plus, I like to tinker with things. I like to I'd like to kind of work with things. I'm a big advocate of open source projects because it's fun to get in inside the program and things like that. So realistically, I mean, to me, learning is an ever lasting process. It's something that you need to continually do. And I'm hoping that I'll be learning up until the day I die because, you know, the minute I stop and the minute my brain will stop functioning as basically my mind set on that. Yeah.
And I'm always willing to try new things even if I don't know anything about it, because in order to have a success, you have to have challenges and obstacles that you've been able to overcome throughout the path and the journey. And I tend to get bored once I hit the end of the journey and I'm going, you know, that's it. So then it's off to something new, you know, and moving on to something different.
So you talk about emulating, you know, not reinventing the wheel when you're problem solving. Do you think that's a hangup for people to always feel like they have to reinvent the wheel? Did you have to get over that in your own thinking at times?
To answer your question, I do think that people generally tend to lean on what's already out there and available. And if they can't step outside the box or if they're unwilling to step outside the box in order to common approach a problem with a new angle that tends to limit their capabilities in solving the problem. And I do think that, you know, granted out of the box thinking is something that has to be developed, I think. But by the same token, you know, in the box solutions, if it's already developed, sometimes, you know, if you don't have to reinvent the wheel, don't do it. But if it's something that you kind of have no other choice based on the parameters that are being present to you in any given situation, going and thinking outside the box. If you consider, you know, back in the 80s, there was a show called McGyver and it's just been rebooted earlier here a couple of years ago. But I used to love that show. And the reason being is because he came up with creative solutions based upon what he was looking at. And the situation that he was in. And it was more of use. What's available to you rather than going out and trying to solve a problem with something that you may not be able to obtain.
And so, you know that I've kind of applied that same thing to my thinking, and that's everything in everyday life.
So specifically, you shared a story at WLPC. And this particular problem was how you solved a driving loss for VO Wi-Fi with Eco Alpro and the W lamp. I so talk us through that story.
Ok. So I mean, obviously, again, I've gained at least with the guys that I've worked with for many years, I've gained a reputation for coming up with solutions when there doesn't appear to be any. And so in this particular case, my CEO came to me and he pretty much said, hey, I've got a customer who is asking for us to prove that their voice over Wi-Fi is ready for them to turn on the switch, to start handling, you know. Voice over Wi-Fi clients and stuff. How are we gonna be able to do that, utilizing the tools that we already have? And, of course, you know, putting on his salesmanship hat, he's like, oh, and by the way, I already bid this for X dollars. So there's nothing else that we can really add to the project. And so from that standpoint, I had to sit down and kind of like I looked at him and I said, yep, yep, we can do that. I know we can do that. And then internally, I look back on myself and I went, OK, how am I going to do this? So one of the biggest things that I think really plays into situations like this is being able to do research and digging through Cloon. That other people might have already come across and have put it out there. I mean, the Internet's a great thing. You can you can search it really easily. So. So one of the things that I did is I wanted to do my research. First of all, I had to understand what the MOS score was and how does it come about? How is it derived from that standpoint? That led me to an article that was published by Pargneaux of Net BS. I'm not even going to try and like mention his full name or his last name because I'm sure Eminem ends meet it. But I ran across an article, a little blog post that he wrote on how net BS, which is the monitoring system, derives MOS. And so in looking at that, I figured, well, shoot, if that's the way they're doing it.
And he explained it explicitly in the article. He explained what the calculations were. Where are they going get them, you know, and how those calculations are put together. And so in my research, I basically said, well, if that's what they're going to do, then shoot works for them, might as well work for me or I'm a broker.
A great case. Reminder to share knowledge. If you come across something or you know how to sell something, it's always worth putting it out there, either in a blog or sharing it somehow.
Oh, absolutely. And this community is fantastic for that. I mean, just think of everything, you know, everything that's being presented both at WLPC, its engineers speaking to engineers in all the way to projects like the Dubie.
Lan PI is an example. It's everything is just sharing knowledge and understanding. It's an incredible community to be a part of. I feel very honored and blessed to actually even be allowed to sit in the room with some of these people.
So you found Panoz, his article. He explained it. You then could appropriate that, I guess, in your specific situation.
Well, absolutely. I mean, he his article explained the calculations and in particular what needed to be used in order to create those calculations. And so essentially, I just basically copied from him. I mean, I pretty much plagiarized everything that he did as far as the calculations are concerned. But then I had to figure out. OK. So I know the calculations. I know what I'm looking for in terms of the metrics that I need to use to put into these calculations to be able to derive this score. Now, it's like, how do I gather that data? How do I gather what's necessary? And in the presentation that I gave, you know, the couple things that have to happen is you have to have packet loss. You have to have jitter. And you have to have latency. And all of these numerical values need to go into the Mosse score, and they're used in different ways. His blog post explained how they use it. But the reality is, is that I didn't understand that.
So I had to sit and figure out how do I collect that data. And this is where, you know, again, like I said, I'm a fan of open source. So open source availability. I already had a Dubie LAN pie in my hand. And I knew that w DoubleLine pie could do things like using iBOT to or I purchased three. In order to achieve a latency number, it can also do jitter based on using a UDP testing. So I pretty much knew that already.
Plus, it's also a good endpoint to grab Ping in order to get packet loss throughout the network, because when you're doing packet loss and you're doing something across a network, especially in Wi-Fi, you don't necessarily want to ping something like a switch or a router, because if you do that, the ping by itself, by its very nature, is at the low end of the totem pole in terms of what the priority is for that device to respond to it. So when you're trying to test Wi-Fi, you never really want to ping your gateway because you're gateway has other things that it needs to be doing, like routing. As an example that make it sometimes where it can give you false results. And so utilizing like just the gateway by itself was a bit of a problem. And so I had to come up with a way to have a device on the network.
And because of this particular site was in New York. So I was flying there. I had to carry something small enough that it could just fit my backpack in the WLAN Pi fit perfectly, does all three things. It allows me to use a known end point on the network. And it was it was just perfect.
That's great. So where where did you go from there?
Ok. So the next question that I had is. All right. So I've got the data. I've got the endpoint to utilize. Now, how do I be how am I going to be able to visualize that or provide a visualization of that to my client? Because, you know, I could gather all this data manually and throw it into like an Excel spreadsheet or something like that. But that's going to take a while. So what is it that I can use that as? Already set up to provide some of that information and turns out how pro, you know, ECKA, how proactive survey it can gather. You know, a couple of these things at the same time and in this particular case, latency and jitter from the throughput testing. And unfortunately, I can't do both. They cannot pain and do a throughput test. You have to have it. Do you have a choice of either one or the other? And so the harder part was trying to figure out, OK, which one is going to be more important when it comes to the visualization? Which one is going to be the more important piece to be able to show this to my clients? And so I chose the throughput option on how to be able to gather the latency in the jitters statistics.
And then just for the packet loss, I just basically took my same laptop that I was doing the survey with and just pinged the W LAN pie and wrote that off to a file so that I could evaluate it later, you know, look for things like large gaps and in ping loss rather than just like an overall percentage or whatever from that kind of thing. And I also had to collect it in the time that I was given, because if you remember, when I when I started the discussion, I'm only given, by the way, of you know, I've already quoted this for a certain amount of time, so we can't lie or add a whole bunch of time to this thing. So anyway, so that was how I decided to go ahead and collect the data so that I could put it all together into a report and make it look good.
Well, you had mentioned in your talk about the continuous option, which was a little controversial. You had been told not to do that part a little bit about that.
Ok. So one of the challenges that you have with doing a test like this is the fact that inherently roaming can give you a bit of a problem, especially if the client device takes too long to actually roam. Now, granted, understanding, you know, that people are going to be holding their cell phone or voice over Wi-Fi, phone, whatever device they're actually using, and they're going to walk through the area anyway. So standing still in one spot and doing like a stop and go survey, which you're not supposed to move during a stop and go survey. So standing there in one spot and doing throughput tests, which would be more ideal in the situation if you're looking at just throughput. So being understanding that the clients are not going to necessarily stand still, that they're actually going to start walking and talking. I also wanted to incorporate the idea of, you know, survivability across a drone. That being said, that's not necessarily the recommended way to gather throughput data because, you know, you can impacting throughput is going to be impacted by the roaming process and, you know, moving away from the first AP that you're connected to. And then the disconnect from that AP, the connection to the new AP, all of those processes during the RE association and everything else is going to impact your throughput. So realistically, you know, looking back on it, could I have done it differently yet? Maybe somebody else could come up with a better way of doing it. But the thing that I was trying to prove was the fact that no matter what happens, whether your client is roaming, whether your person's walking around, you're going to get a decent quality MOS score across this space. And so in order to do that, I had to get as close to emulating the actual situation as possible.
So you gathered the data then what?
Ok. Looking at the data, once I had the numbers. Now I've got to run them through the whole manual process of going through the entire calculation to come up with the final MOS score. If you read panels blog post, there's actually like three steps to it. The first step, you've got to create what is considered the effective latency. So in order to do that, you need to combine your latency in your jitter together in the net BES option. What they do is they add or they multiply jitter by two because of the fact that jitter is a really big impact to a voice situation because UDP packets are sent, they're basically sent. Reset it and send it and forget it.
There's no like it's a connection loss protocol. So there's no confirmation that a packet has actually reached the end server or not. Now, when you do that over a Wi-Fi network, Wi-Fi has its own inherent checks and balances. Sort of like TCAP is. But with UDP across the entire link, you're actually not going to get that confirmation, that acknowledgment from the other end that you've actually got it. So having more jitter, which basically means that packets are arriving out of order or it's taking too long for a packet to arrive in the proper order, that kind of thing. If you have a large number of jitter it. Becomes hard to follow the conversation, because if the packets don't arrive right, the sound quality is horrible. So what Nev's does is they go ahead and they use that jetter value. They double it and then add it to the latency in order to get an effective Jeter number. And then they also, as a part of that, they add a 10 millisecond timeframe in order to account for things like delays in codec encoding and decoding. So once you do that, that gets you to your effective latency number. Now, there's a couple different models that you can use for voice over Wi-Fi evaluations.
The one that's most commonly used, I found through research is called the E model, and that's actually the same model that Net Beas uses. OK. So the E model basically gives a rating or what's called an R value to the quality of the communication.
And this are value. They found the best quality has to be at least in ninety three point two hour value. So from that standpoint, that's the target that we're trying to get. We're trying to look at that our value. We're trying to get to ninety three point two for that are value. So we start off with the effective latency. We figure that out. Then there's two different calculations that are done. This is step two. So two different calculations that are done. If the effective latency is greater than one hundred and sixty milliseconds, then you use a separate, different calculation than what you do. If the effective latency is over 160 milliseconds. And then essentially both of those are subtracted in the effective latency calculation with the one hundred and sixty milliseconds is actually divided by 40. So effective latency divided by 40.
And then that values subtracted from ninety three point two in the other calculation where it's greater than one hundred and sixty milliseconds. There's some additional numbers added on. And so what you do there is you take your effective latency. You subtract 120 out of it. Take that value. Divide that by 10 and then subtract that number from ninety three point two. Because keep in mind, latency and jitter are your two big numbers in this, because, again, if the packets take too long to reach there or if they arrive out of order, that's gonna be murder on the quality of the call. So once we go through step two, then we have to add in.
So we've looked at effective latency. We've known as a part of that. We've included jitters. So our last value that we're going to look at is packet loss. So at that point, we take the, ah, value or the value that we had from before. And we subtract a two and a half times the packet loss value. And that gives us essentially a R value, an R rating.
Ok. Does that make sense. Yeah. And of course we can react to this where people can see visual. So I'll, I'll get a link to pantos, his blog. And then to your presentation as well. So if someone wants to kind of see it as they're hearing, it will definitely connect them to their abs.
Absolutely. OK. So then the last piece of the puzzle is dependent upon that are value that you've derived out of those three previous steps. So if that R value comes out to be less than zero, your more score is a one which is absolutely the worst. If that value falls between zero and 100, then you do this calculation. And it's got, you know, a bunch of numbers. I'm not going to walk through the whole thing. Look at the presentation to get it. But you do this this calculation on it and you derive your MOS score. If the are value, the number that you've brought from those three previous steps is greater than one hundred. Then it's automatically assigned to my score four and a half. Now even though moss' technically one through five, four and a half is actually the highest number that you can actually get utilizing. I'm trying to remember the codec numbers. Don't remember right off top my head, but it's in the blog. It's in the blog. But there's a specific codec. I think it's the G-7 dot 11 codec. So the highest value that you can get is 4.5. Now, keep in mind, you know, if you're using some different codec, you could come up with some different values, different calculations in order to do it. But the G-7 dot 11 one, I believe is one of the most common that's used. And so because of that, that's kind of why I wanted to lean on this this particular methodology in order to come up with the most score.
So what did you end up producing them for the client? Did it come out the way you had hoped? And were they pleased with the end result?
To be honest with you, half the time, I don't even know if they're pleased or not. I was just sort of hand the report over and I never hear from them again if anything is good progress. So, you know, that kind of stinks in a way. Either that or all of a sudden we'll just start getting a whole bunch of more work from them. Yeah. One or the other. Which is basically, you know, my validation that, hey, what I did was good. Yay! I'm back now. But from that standpoint, what I did at that point is I said. Well, first of all, they want. They're going to want to see signal strength. They're definitely going to want to see the signal strength across the entire space. The next thing that I wanted to show them was some visualization or some way to sort of show them in kind of a pass or fail format. In this case, red or green, because that's what. How does the jitter visualization. So because Jeter was the only one that actually gives me a map with the cover, both red and green, I pretty much incorporated those visualizations out of alcohol as a part of the report. Realistically, throughout most of the of the facility, the Jeter visit visualizations actually showed that Jeter was good across, you know, a good 95 percent.
He was only a couple of places. This was a retail outlet. So there is only a couple of places in some of the stock rooms that they didn't have an AP close by that caused the Jeter to go down or go up, I should say, cause Jeter to go up and get really bad.
So from that standpoint, I mean, that was expected. And then when I went ahead and did is I provided a written explanation of everything that I've just told you. So all of you know what Moss actually is, how I derived it. And then I showed them a final table that basically gave a low, a medium and high across the entire floor.
And mostly cases, it was pretty close. It was like between 4.0 and 4.5 for the most cases. There wasn't any place that I can think of right off my head that actually went below a 4.0. So it pretty much basically showed them that the entire area that they were asking us to validate came out as being ready for voice over Wi-Fi.
Very cool. Did any of this translate into other jobs you've done since solving this? Have you utilized this anywhere else?
Yeah, I actually just this last last fall, I think just this last fall. It wasn't for voice over Wi-Fi, but we did have a couple of clients that popped up and said, hey, can you guys do like a throughput evaluation? Can you guys go through and evaluate the throughput across? In this case, this was a university, so across our outdoor space and our campuses. And so I was able to pull out my W LAN PIs. I've got eight of the suckers today, but I was able to pull out the double and pies outfit, a couple of my guys with them and get them up on their network and just said have at it and go through and do the throughput. I mean, most people look at, you know, they look at signal strength and they think signal strength is awesome, we're good. But that only tells one aspect of the story. There are so many other metrics that can be gathered, but more often than not, people are not necessarily willing or they're not aware of these other metrics and what these impacts actually are.
So more often than not, our clients will just say, hey, just do me a single signal validation and call it good. And so oftentimes I'll sit there and I'm just like, OK, signal validation is great. I mean, you have to have layer one. You have to have signal. But that doesn't give you the entire picture. So being able to break out, you know, a tool like the W LAN pie and doing an active survey versus a passive survey. That part actually kind of fascinates me because, again, we don't get it often chance to do it on a regular basis. But on the times that we do, it was really kind of cool, first of all, to do the voice over Wi-Fi, because we don't do that a lot. I actually wish that I had that capability. This was, you know, several years ago before the Dubie LAN pie even came out. I wish I had had that capability back then. But it turns out that, you know, now that I've got it, I'm going to use it again. I'm definitely gonna use it again.
Well, Rick, I really appreciate your time. Thank you for kind of doing a deeper dove on your presentation and giving us a few different angles and perspective. Really appreciate it.
Thank you for joining us for another episode of the wireless LAN professionals podcast. The podcast for wireless LAN professionals by wireless LAN professionals. Be sure to follow us on Twitter at Wireless Landreaux. For all the latest news and updates and also connect directly with Keith on Twitter at Keith Parsons. Head over to w w w w LAN prose dot com.
For this episode show notes as well as the latest in all things Wi-Fi.
Automatically convert your audio files to text with Sonix. Sonix is the best online, automated transcription service.
Better audio means a higher transcript accuracy rate. Automated transcription can quickly transcribe your skype calls. All of your remote meetings will be better indexed with a Sonix transcript. Create better transcripts with online automated transcription. Automated transcription is much more accurate if you upload high quality audio. Here's how to capture high quality audio. Get the most out of your audio content with Sonix. Sonix converts audio to text in minutes, not hours. Rapid advancements in speech-to-text technology has made transcription a whole lot easier. Here are five reasons you should transcribe your podcast with Sonix.