Describe the Wireless Design Process

0:05Welcome to design the wireless design process. Here we are, starting in on domain one of this blueprint. And so everything up until now, if you've watched through all of the conversations and the skills that we've had up until now, those have all been laying a foundation to make sure that we are good to go from just a baseline level of knowledge about wireless, to ensuring that we can now start to have conversations around wireless designs. And so what we're going to do is we're going to, first of all, take a look at Cisco's lifecycle for the network. The idea here is that we don't just create networks-- we design a network.

0:38We install a network. And then that network is forever good. I think most of us have been in the industry long enough to understand that, at a minimum, everything gets old eventually and everything will eventually be replaced. However, we also want to make sure that we're looking for ways to optimize our network, even while we're running it. And so we're going to take a look at Cisco's definition of that network lifecycle. And from there, we're going to look at the process of a wireless design. We're going to start with the idea of gathering information. How do we go about having a conversation with the key stakeholders? Now some of us might be IT consultants and so we're going to a company and asking them questions.

1:12Others of us might work within a networking team for an organization. And even then, we need to go to the business people who are involved with this decision-making process and try to figure out, OK, what exactly are we trying to solve here? Do you just want Wi-Fi 6 because you watched a YouTube video on it? Or are we having problems or are we delivering new applications that are going to be business drivers for deploying a new wireless network? From there, we're going to talk about site surveys and understand what exactly those are and how we go about performing those. And then we're going to end with just what it looks like to put together a design and hand that off to the decision-makers in order to make that decision, and hopefully, end up going towards an implementation.

1:51So by the end of this, hopefully, we'll have a good understanding of what this design process is supposed to look like from start to finish. So with that, let's get started. I'll see you in the next video.

0:00[MUSIC PLAYING] All right, PPDIOO and PBM. Jeff, what in the world are we talking about here? Well, as mentioned in the intro video, we never deploy a network and it's just done forever. Instead, we're going to find that as we work on a network, that we're going to look for ways to optimize it and improve it. And every now and again, we're going to have to replace old hardware with new hardware. And so this is a cycle. We're always looking for what's the next step in this cycle?

0:31We've gone from a design, maybe, to an implement, and from an implement to an operate. And that's what PPDIOO defines for us. So this stands for Prepare, Plan, Design, Implement, Operate, and Optimize. This is the life cycle that Cisco wants us to understand, and so we're going to cover that in this video. And then Cisco eventually also simplified that model to the Plan, Build, and Manage-- that would be the PBM model. And we'll take a look at how that compares to PPDIOO, as well. Cisco has been touting the network lifecycle, this PPDIOO concept, for a very long time.

1:03In fact, in the mid-2000s, I was taking Cisco wireless exams when I first heard about this network lifecycle. And we had to memorize all of the steps, the prepare, and the plan, and the design, and the implement, and the operate, and the optimize. And then each one of these major steps had subcomponents. So I had to learn all the subcomponents that went along with each one. And then each one of those had tasks. And so it was this nightmare of a memorization exam that, fortunately, Cisco doesn't seem to drill that deep into on exams anymore. And so for the purposes of this exam, primarily what we need to understand are each one of these steps, and how that helps define for us the network lifecycle.

1:39And so what we already mentioned is that we don't actually just design a network, and then we implement the network, and then it's done forever. I mean, that's just not even the case, even if we were to add on here, for example, OK now I'm going to operate the network. The reality is that eventually we're going to have to come back, somehow, to this design phase because we are going to be ready to replace hardware. And so this is why it's more of a cycle. And so the idea, here, is that we've got these six concepts around in a circle, and so we're going around in the circle this way.

2:10And so we start with the prepare phase up here. Let's just say that this is prepare, PR, and then we've got plan over here, PL, and then we've got the design phase, the implement phase, the-- oh, I know, all these dots look like O's, so that's not super helpful. So we've got the operational stage right here, where we're operating this network. And then we've got the optimization stage over here, which is where we might identify weak points in the network. Maybe it's time to upgrade our wireless LAN controllers, or our licensing, or the access points, or something like that, which is why we lead back to the prepare phase, which ultimately ends up going through planning and resulting in another design.

2:47Let's talk about each one of these phases. We'll start with the prepare phase. The prepare phase is truly just the very start of any process where we're going to start asking some questions. For example, what is needed here, as well as a very important question, which is, why is something needed here? What's the business case leading towards a network design? This is often going to result in the creation of a high-level design. When we say high-level design, we mean very few details. So the way I like to think of it is, if you're in an airplane way up above the sky like this, you're at a very high level.

3:22You're maybe at, I don't know, 20,000 feet above the surface. And so when you're looking down at the ground down here, you're going to see a whole lot fewer details. And then a low-level design is as if you were maybe either flying lower, sure, or maybe you're actually down here standing on the ground. Once you're standing on the ground, you can absolutely see if there's ants on the ground right next to you, or the details of every blade of grass. You can see all of those details because you're a whole lot lower to the ground versus if you're in that airplane which you're, at that point, way higher off the ground.

3:57And so I just like to use that analogy to help us understand the difference between a high-level and a low-level design. So when we're talking about a high-level design, we might say something like, you know what, we really just want some Wi-Fi 6E in here. And that's it. We don't know if we're going with Cisco access points. We don't know if we're going to go with a particular Cisco access point. Now at the time of this video, there's only one access point that supports 6E, but by the time you're watching this, there might be two or three. And so we're not going into those details. We're just sort of giving this high-level option to say, this is what I'd like, and this is why-- we need more bandwidth, we need better coverage, we're having drops, or what have you.

4:33And so we've defined, now, the what and the why as part of our prepare phase. Now planning sounds sort of similar. However, the focus, here, is to start looking at what we have. And that's what's key. We're going to start to identify specific needs, and we're going to start to set some requirements as well. And so we might say, all right, the new solution needs to support voice and video. Maybe we've needed location services, and that's what we're lacking. So ultimately, what we've done, here, between preparing and planning, is we've laid the groundwork for creating an actual network design.

5:05And this network design, as we see over here in the life cycle down here, this, ideally, is going to lead to an implementation. And so we've been gathering a lot of information up until now. It's time to put it all together and create an actual design. And so this is where we would decide to go perform a site survey. We're also going to create a Bill Of Materials, otherwise called a BOM. And, yeah, that's BOM without a B, by the way, because in English the word bomb means explosive, and we don't want to talk about that kind of bomb. This bill of materials is a list of all the products we need.

5:36So we could just say "hardware," but there's more to it than that. We need to include software components. We need to include licensing. We need to include SmartNet, for example. And so this bill of materials is going to be all of the components of a solution that we need to purchase. Now typically what really matters is the quote. And so, if you're working for an IT consultant, you're probably going to have to create a BOM, and then you're going to end up creating a quote as a result, and delivering the quote to the customer. If you work for an organization, you're working with a Cisco partner in this situation, you might work with the Cisco partner to create the BOM, but ultimately what matters a lot, is the quote because that's going to be the final pricing as far as what it's going to cost your organization to purchase it.

6:16Now I always say that documentation is absolutely king, especially in this phase. We need as much documentation as possible, laying out the solution, as well as the justification. So we're going to say the same two questions-- what is included in this, and why it's included? For example, I'm including a wireless LAN controller, a 9800-80, because we have established that 80 gigabits per second is required. The last thing we want to do is go implement something like this wireless LAN controller, and then we've only got like 10 gigabits per second on there.

6:50And we say, well, why didn't we get the 40 or the dash L, because that would have been a whole lot better fit. And if we justify it, we say, well we ran a particular set of tests, and it indicated it would be 45 gigabits per second, or 30 gigabits per second. We wanted room for growth. And that way we can at least point back to why we were including it. And that'll help answer a whole lot of those types of questions. But importantly, as well, the "what" right here, this is going to spell out for our implementation team what exactly we're doing.

7:20And for example, we included 10 gig twinax for connectivity between the wireless LAN controller and this particular switch. And so if they go to that switch, and they realize that, hey, this switch is full. And then we can say, well, at the time, that switch wasn't full. And so we didn't just make a bad assumption. We actually validated it, and at the time, it was good information. We also might need a Scope Of Work, or an SOW. The scope of work is primarily needed for situations where we have labor involved. Now, this can have a lot of different angles. It could be that you're again an IT consultant, and you're selling your labor.

7:53You could be part of an organization where they want to understand how much labor is going to be expected. And so a project manager will use the scope of work to help us understand, OK, this project should have taken 150 hours. It ended up taking 250 hours. And they can look at this and say, well, that's because we went above and beyond what we said we were going to do. And so this is a very important document as well. The point of all of this is, as we recall, up here we talked about creating a high-level design in the prepare phase, but in the design phase, this is all very low level.

8:25So the end result of this phase is that we've got the low level, in other words the detailed design. And there should be a set of documentation that includes a lot of these documents. It's got to have the bill of materials, and the quote, and the scope of work, and the general documentation describing the "what" and the "why" of what we're installing. Now, the goal of the design phase is to lead to an implementation phase. Now, it's always possible that the decision makers decided not to do the implementation, and that's fine. However, assuming that the design is accepted and purchased, we are now going to be implementing the solution.

8:58And so we have to place the order for all of the equipment. And so there might be a downtime. We might have to wait six or eight weeks for all the equipment to get in. And so it's important that we do this part first. Like when you're baking cookies-- I don't know about you, but I always forget to set the oven. Set the oven for 350 degrees, and then start making the cookie dough. And that way, when you're done with the cookie dough, the oven is all warmed up. And inevitably I make the cookie dough. I turn around. I never set the oven. And so now I have to wait 20 minutes for the oven to heat up and start baking the cookies. I don't know if that analogy really works that well.

9:30But hey, if we forget to order the equipment up front, then we might do a whole lot of work and then realize that we've still got to wait two months in order for that equipment to arrive. Now while that equipment is coming, we can go stage the area. So that might mean that we've got a rip apart a room that is going to house all of the switches that we're installing, all the access points. Maybe it's just going to be a desk somewhere. But we need a place for all of the equipment to go where we can configure it and get it up and running. And maybe, especially in a multiphase project, we might be operating out of this room, as well, as far as installing so many access points at night.

10:03At some point, the goal here is to perform the cutover, where we're actually installing this equipment. Maybe it's all rip and replace, maybe it's a phase migration. But after the cutover, we do the Network Ready For Use tests, or NRFUs, which more or less allows all of the stakeholders to sign off and say, yes, the network is working. Everything is working as intended. And at that point, the implementation phase is done. Now next up is the operate phase. This phase is simply us using the network that we just installed. And so we need to keep the system online and operational. We need to make sure everybody is trained on the new system because that's kind of a big deal.

10:37If we just changed maybe from Aruba access points to Cisco access points, does the team understand how to actually manage this from a Cisco perspective? We want to make sure that we have good documentation in place so that our NOC understands what to do, and our engineering team understands what to do when problems get escalated. And so this is just all part of what we call keeping the lights on in IT-- making sure that the system stays online and operational for the entire life that it's intended to deliver. And lastly, we have optimize. Optimize just means that we're looking for ways to make it better, constantly.

11:10And so we want to be proactive in this sense. We want to be paying attention to what's going well and what's not going well. Are there ways that we can improve life here? In the wireless world this might be paying attention to RF signal and reports to say, hey, maybe the signal over here is now dead. Maybe a wall was put in, and so we don't have good coverage in the conference room anymore. I mean, who knows what's happening here. But the idea is that things are always changing, especially in today's modern era. Nothing ever seems to stay the same for long. So we can't just assume that we're going to be operating this as it was installed for five or six years.

11:44Things are going to change. And we need to be reacting to those changes as best we can. And so this might actually end up leading to another prepare phase. And that's the idea, here, is we're in a cycle. So we notice something, hey, we need a couple of access points, here. Well that is going to take us back around this cycle, back through operate and optimize, all the way to our prepare phase. And so we're ready to do another design. And this design might be small. It might just be adding a few access points, or it might be large where we're going to completely replace what we installed five or six years ago.

12:15Now we also need to be aware of the fact that Cisco has this PBM model in place, as well, now. This is their way of trying to optimize this muddled mess, PPDIOO. Yeah, it actually works pretty well when we draw it out like this, and we can understand what each phase does. But it is a tall order for us to be able to memorize something like that, especially if we have to memorize the components of each phase as well. And so what they did was, they took these three first three phases-- prepare, plan, and design-- and they just wrapped this up into plan.

12:45And understand that that means everything from asking the initial questions to creating the low-level design. Then they have build. Build is the exact same thing as implementation. And so that's just a one-to-one mapping. Now manage, manage would be this section down here. We are operating, and we're looking continuously and proactively for how we can optimize our network. So this would be the M side. So I didn't write these out but, Plan, Build and Manage. And so understanding that that model exists as well, is going to be important.

13:17However I suspect in a lot of cases, we're going to find Cisco continuing to really relate back to the PPDIOO lifecycle, at least that's what I've seen in their documentation. And it'll be interesting to see over time if Cisco just sort of abandons that and goes more towards plan, build, and manage. All right, so our key takeaway here is that PPDIOO, it's all about the lifecycle. And that keyword cycle being that it's a circle. We're just going to continue to go around in this circle pretty much forever. I often joke like, when do we win this game? When is it over? It's never over.

13:48We're always looking for the next thing, whether that's moving from design to implement, or implement to operate, operate to optimize, or optimize right back around to preparing, and planning, and creating a new design. And so let's just make sure that we have all of those down. I just listed them all, but from prepare, to plan, to design, to implement, to operate, and optimize-- we should have that memorized, and the order of operations as well. And it shouldn't matter where we start in the cycle. We do typically start by saying prepare, but ultimately, hey, if we're in the middle of an implementation, we need to know what phase is next in the lifecycle.

14:21Now lastly, we do have plan, build, manage. Plan, build, manage is the exact same concept. It's all the same tasks. It's just categorized under three phases rather than six, and so we just need to know which of the PPDIOO phases fit into which of the PBM phases. I hope this has been informative for you, and I'd like to thank you for viewing.

0:00[MUSIC PLAYING] All right now that we know Cisco's lifecycle, the PPDIOO lifecycle that we just defined, we're going to jump into the prepare and the plan phases in this video. That involves a lot of information gathering. We're going to be asking a lot of questions. Remember, we need to define what it is we want to accomplish, and we need to define why it is we want to accomplish those things. And so we need to differentiate between what we'd like to install, in other words our wants, and our needs. So let's go ahead and dive in and see what kinds of questions we should be asking in this phase.

0:33All right so let's start with this idea of need versus want. Because I don't know about you, but I absolutely love some of this technology that we've been talking about. I love Wi-Fi 6E. And if we love Wi-Fi 6E, and the 6 gigahertz spectrum, and 160 megahertz channels and all of these things, and if I love Wi-Fi 6E that much, I might find that every time I'm presented with a problem that Wi-Fi 6E ends up being my recommended solution. And so this can quickly become something that we call a solution looking for a problem, rather than what we ideally have, which is a problem that needs a solution.

1:06In other words, if I have a problem that Wi-Fi 6E will help me with, the Wi-Fi 6E should be the solution. It should never be the other way around. It should never be that, hey, Wi-Fi 6E has this great 6 gigahertz space, and therefore you must have a problem with contention in the 5 gigahertz space. It just shouldn't work that way. And that's what we mean by a solution looking for a problem. So the reality is that it's possible that we have problems in the 5 gigahertz spectrum. Maybe we're in a tight metro area, and we're trying to use 80 megahertz channels.

1:36And so we don't have a lot of those channels, and therefore the 5 gigahertz space has a lot of contention. But this is a question we should be asking, is this a problem that we have? Do we have a lot of contention in the 5 gigahertz space? Is this something that maybe we could solve with dual 5 gigahertz radios? Is it something that we could solve by going down from 80 megahertz channels to 40 megahertz channels and just making smaller cells? I mean, we've got a lot of different, other solutions to this type of problem, other than just Wi-Fi 6E. But the reality is that we might not have any contention in this spectrum space.

2:09And, therefore, we don't actually need Wi-Fi 6E, because we can deploy our solution into the 5 gigahertz band. So our job as design engineers, ideally, is to find the right solution. And when I say the right solution, I mean what is needed in this situation, while also taking into account things like budgets and trying to find the balance there. Because we shouldn't be looking at "my favorite technologies." If my job is being perceived as just going in and saying, hey, this is my favorite technology. This is what I want to deploy.

2:40Then, we're going to end up losing trust as design engineers, and we really need to work on trust. So this should never be our methodology. Now there is one thing that we can do as design engineers that will always make sure that we're looking for the right solution, and that is to ask a lot of questions. We want to make sure that we best understand the situation so we don't immediately go to solving problems. So in other words, I might want to start by talking, and say, OK, hey, have you heard about Cisco Wi-Fi? Have you heard about the Catalyst Series?

3:10So we've got the Cat9Ks, the 9100s, and the 9800s. And have you heard, by the way, about Cisco's cloud controllers that we can deploy? And have you heard, by the way, of Cisco's Wi-Fi 6E access points? And this is what we love to do. We love to go into a room and talk about the things that we're excited about. But the reality is that this is a bad strategy. And this is coming from somebody who worked for a Cisco partner, who walked into rooms to have conversations with people about this. This doesn't work because it shows that I'm more interested in what I have to offer, in other words, I'm more interested in what I want to do, versus what you actually need me to accomplish.

3:48And so instead, we're going to ask questions. We're going to get the stakeholders to talk. We want them to talk more than ourselves. And so what are we going to ask about? Well we can, first of all, and this is a huge one, what I would always start with is, what are the pain points to the current solution, if we've got a non-Cisco wireless solution in place? How is managing that? Is that a pain point? Do we have RF signal issues? Are we having dead spots? Are we deploying real-time applications, maybe, and so my VoIP calls, they're actually getting dropped.

4:19And so that would be bad. That would be a lot of pain points that would-- so there's something that we could actually fix pretty fast, I would think. Well, we don't just want to stop there. As soon as I ask about pain points, and they maybe give some pain points, if I once again just immediately say, OK, well, we can fix those, OK, well, let's hold the phone there because we want to keep asking more questions. And so maybe we should also ask about, what are your primary care abouts in the new solution? And so, do you care about these voice drops more so than the manageability? Because if I hear you say you don't like the way Aruba is managed, I could really tout how Cisco is managed.

4:54But maybe you care more about the voice over IP drops, and you don't really care about the management of the solution. And at some point, we do actually have to ask about the technical requirements of the solution that you're looking for. And so there's a lot of questions, here, we should ask about that we're going to be reviewing over time. But we can talk about, for example, client density. Is this an environment that we've got 50 school students all in one room, and they've all got a device or two, and we need to focus on this high level of client density? Or is that not of concern?

5:26We do want to ask about real-time applications. So we just mentioned voice over IP. And so that's certainly a concern. We could also ask about video calls, and just maybe EMR-type applications in a hospital environment-- that'd be electronic medical records. And so, what are the apps that are being deployed into the Wi-Fi space that are our primary concerns? We want to find out, hey, do you need location services as part of this? Are you planning to track devices over the course of time? And, by the way, what are your switching capabilities?

5:57And do we think that we might need to upgrade our switches as part of this design? We also want to make sure that we, at some point, ask about the budget. In a lot of situations-- again, I'm approaching this from an IT consultant perspective-- you're not necessarily given the budget because we don't necessarily have the trust level to not just completely spend every single dollar in the budget. We should at least get an idea of whether there is a budget, and, if so, how constrained is it. Like get a range, so to speak, so we understand what we're talking about. Now if we're not IT consultants, if we're working for the organization in question, then we probably need to, at least at some point, get an idea of what that budget is, as well.

6:34Now something we might need to ask, especially if we're talking about a Cisco solution versus a non-Cisco solution, is what are your preconceived notions of a Cisco wireless solution? Have you heard about Cisco wireless? Do you think that you'd be open to that question? And this is true, by the way, I should say all of these are true regardless of whether we're IT consultants or whether we're working for an IT shop. Because my decision makers, their preconceived notions are going to impact whether they want to go with my recommended solution. So I might go and say, hey, I'm recommending the Cisco access points in the 9800s, and the 9136 access points, and all of this.

7:11And they look at that and say, OK, nah, I'm not interested in Cisco. Oh well, why? Like let's talk about that. Let's talk about that up front to make sure that I don't do a whole lot of work that isn't going to go anywhere. It also gives us a chance, by the way, to counter those, to say, well I had a Cisco access point, and it completely failed, and I hated it. And you might find out, oh, well that was a small-medium business access point. Those are really, really cheap access points, and we're not going to be talking about those. And say, oh, OK, well then we could consider enterprise-level Cisco access points, such as an example.

7:42And lastly, we probably do want to ask about, hey, what has worked and especially what has not worked in the past? Because if they do say that a Cisco access point hasn't worked in the past, or if they say that we tried to get away from the 2.4 gigahertz spectrum, and we tried 5, and it didn't work, again, this is a chance for us to address that up front, rather than surprising them, I suppose, with a quote that involves a band that they say, well, that didn't work before, so I'm not going to do that. So I've got a story that goes along with this, that I think really exemplifies what I'm trying to say, which is that when I was working for the Cisco partner, me and a fellow engineer, we went to a bid meeting-- a bid meeting for a library that they wanted a new data center network.

8:23And so we went and we were not the incumbents, meaning that they had purchased Cisco solutions, traditionally from a different Cisco partner. But because this is a bid, and it's for a public entity, anybody can show up. And so I showed up with my engineering friend, and we just asked so many questions. And it wasn't just for the sake of opening our mouths. We had legitimate questions. They're saying that they wanted this, and it's like, well, did you want this, or did you want that? And so of the probably 10 to 15 questions that were asked, we asked about 75% of the questions ourselves.

8:55And I think that went a long way because, ultimately, we were able to create a design that satisfied all of their actual needs. I wasn't making any assumptions. I wasn't putting solutions in that I wanted to. I mean, yes, ultimately I was putting solutions in I wanted to, but it was to match their needs. And so that became very clear in the design that we put together. And so when we delivered the quote, I don't even think we had the cheapest design. In fact, I can assure you that we did not have the cheapest design. But it best matched what they were looking for.

9:25And because it best match what they were looking for, and they could tell just from the limited experience that they had with us that we cared about what they wanted, that ended up becoming our job. And so we won the business away from somebody else who would really have liked to have had that business, I promise you. They weren't expecting to lose it. But the reason that they did, was because they didn't do their due diligence, unlike us, in making sure that they were addressing the needs, rather than the wants. And so this is why it's so important to open our mouths and ask questions, rather than opening our mouths to explain what it is we'd like to install.

9:57Now one last thing I want to talk about is this idea of finding the right solution. I'm putting this in quotes because, really, what I want to say here is that there is no such thing as a right solution. What do I mean by that? Well everything we design is going to have upsides to it, and it's going to have downsides to it. Now the downsides might be as simple as saying, you know what, this is a more expensive solution? Or hey, it might actually be a cheaper solution, but you're not as familiar with it. So it might not be technical. It might be something that exists outside of the technical realm.

10:28We might also disagree on these concepts. For example, we might actually be going into a situation where the decision makers prefer a solution like Aruba. And so they're saying, hey, we really like Aruba access points. And so I'm touting all of the benefits and value that Cisco has, and ultimately they go with a solution that we weren't recommending. Whether, again, we were consultants or whether this is our own shop making this decision, it doesn't matter. The idea, here, is that the decision makers went with a solution that we disagree with. And I want to say that that's OK.

11:00Because if we, as engineers, focus entirely on the technical side of the solution, we might actually lose a whole lot of these types of situations. The reason is, not everybody looks 100% to the technical side of things. In fact, I would argue that none of us do. We're always going to have an emotional response to something in the same way that somebody came up to me and tried to sell me on non-Cisco solution, I'd probably be like, you know what, I mean you might say that you have the technical chops, that your solution is technically better than Cisco, but in my heart I don't believe you because I really love Cisco.

11:32And so I'm probably just going to end up going with that in the same way that maybe these decision makers went with a non-Cisco solution. I remember once I lost a deal in this fashion. It was us versus another vendor, and we got really skinny. We actually were hoping to do a little bit of community service, in this sense. We wanted to not make a whole lot of money on this deal. We just want to get a really good solution in for a local entity. And we were the cheaper solution, even though we were selling Cisco. We were by far the more technically superior solution. And yet, they went with the other guys.

12:05What in the world happened here? Well what happened is that they decided that they were more comfortable with what they knew rather than something new. And so even though that bothered me to the point that I remember it to this day, I need to end up respecting that decision and to understand that we're not always going to win every single situation. Even if we have the best technical design, even if we have the best price, we might find that we lose a deal. And all we can do is learn from that and hopefully take that information with us into the next situation. So a few big takeaways here. First and foremost, as designers, we need to focus on what is needed in a solution, not necessarily what we want to install.

12:39And even though that sounds really obvious, potentially, on paper, we're going to find that we've got a lot of biases in as far as what our favorite technologies are, what our favorite vendors are. And we carry those biases into our design sessions. And so one of the best tools that we can do to make sure that we're not just following that, is to ask a lot of questions. Let other people talk. Ask the questions like we talked about here about, what are your pain points? What do you care most about? What are the technical requirements? And that way, once you have a grasp of what exactly is needed here, then we can turn around and say, you know what, I don't think the 9136 access points are required in this situation.

13:15And maybe we can get away with something a little bit cheaper that better meets their budget and still gives them a solid Cisco solution. So lastly, we understand that the best or the right solution doesn't necessarily exist. Absolutely there are wrong solutions out there. If we're not meeting the technical requirements, that's a wrong solution. But we need to make sure that we respect those who are making the decisions. But also understand that decisions are not always made based on technical specs. And so the more that we can address, maybe, the emotional problems that might be arising with considering a solution we recommend, if we can address those up front, there's a greater chance that they'll pull the trigger on what we would consider the best technical solution.

13:55I hope this has been informative for you, and I'd like to thank you for viewing.

0:00[MUSIC PLAYING] Well, we have heard a lot about site surveys, and we're going to keep talking about wireless site surveys. In this video, we're going to lay a foundation for defining what exactly a site survey is, what the goals are, and how we go about doing them. Wireless designs have a dimension to them that no other type of network design has, which is the concept of RF signal. We've got to worry about the radio frequency signals in our environment and where they're going to go and whether they're going to reach to the corners.

0:30And so, as a result, we need to know where every single access point should be placed. So AP placement is a very important part of every wireless design. Well, I can't know for sure where each access point is going to go unless I test and figure it out myself. And there's a lot of methods to this, but the goal is ultimately the same. It's to determine the optimal placement for the access points that gives me the coverage that I need. And eventually we're also going to talk about not just coverage but capacity. Because we need both of those to be considered as part of a modern wireless site survey.

1:03So how exactly do we go about doing this? Well, first and foremost, we're going to leverage some kind of software tool. And there's a lot of software packages out there that accomplish this. In my experience, the two more popular ones, I would say, are going to be Ekahau as well as AirMagnet. And the idea here is that we're going to walk around the environment and figure out where certain signals map as far as the floor plan is concerned. And so the goal is to create a heat map. The heat map is going to look like any kind of temperature map, maybe a weather map that you've seen, that in this case is going to show the floor plan.

1:38And so we've got a floor plan here. We've got a bunch of rooms. We've got the doors, the hallways, et cetera. And so ideally what we're doing is we're walking around, we're recording signal strength, and that's going to map the heat map on top of this. So we've got a wireless signal that looks like this and a wireless signal that looks like this over here, and we see that it's maybe weaker in the corners and stronger right next to the access point. And so that is the ultimate goal of a site survey. Now, a site survey is always going to come with a set of requirements that must be defined ahead of time. Because we've got several different types of wireless networks that we could end up implementing, and the site survey needs to reflect that.

2:14For example, we need to define whether there are real-time applications in use. And the most common, most prevalent real-time application that we need to concern ourselves with would be voice over IP. Do we have voice over IP calls happening, and do we have video calls, or some kind of video application? Or any type of real-time application, really, is what we care most about. Because if we do have real-time applications, then this is going to affect many things. It's going to affect the overlap of our different cells. It's going to affect the overall signal strength as far as what's considered to be a valid signal strength and what is considered to be a not valid signal strength.

2:53And then packet loss is also going to be affected by these types of decisions. And so if we don't have good enough packet loss percent, in other words, if the percentage is too high, then at that point it might have worked for a data site survey, but it's not going to work for a real-time services type of survey. The other question we might ask is, are we going to need location services? Because if we're going to be tracking devices and where they go, this changes where we place the access points as well. We form this sort of cage of access points with location services.

3:23So if we don't have location services in place, we might have our access points that look something like this, where we're trying to service the entire area and get coverage everywhere. I know my circles didn't quite cover everywhere, but for the sake of this demonstration, let's just assume that they are. Location is going to change that, in that we're going to place access points around the perimeter, as well, and try to form triangles. And so the triangulation concept is going to come into play here. And so, depending on whether we need location services or not, naturally this is going to heavily impact our AP placement.

3:54And we might end up having to do a survey that looks like this versus one that just supports real-time applications. And lastly, we might just find that we're deploying a data network. A data network these days is pretty far and few between that we have these actually. It means that we're not having any kinds of real-time applications and we're not deploying any location services. So this is basically just a vanilla type of site survey, which is going to look a whole lot like the one on the left here. However, our overlap and our signal strength and our packet loss are less stringent than they would be if we were deploying voice over IP.

4:27So ideally, what we're going to do is we're going to perform an on-site walkthrough in order to do the site survey. And so this typically actually involves some kind of AP on a stick, I like to call it. An AP on a stick means that we're literally mounting an access point to a stick. And so we've got the access point hanging here, and it needs to be mounted as if it's on the ceiling. We want the access point to be as close to the ceiling as possible, so we want this to be a pretty tall stick. And then maybe this is on wheels in some capacity. And so we're rolling it around. And what we do, assuming we've got some kind of battery on here that powers the access point, is we leave this in a place and I, with my laptop or my tablet or my device or what have you, I'm going to go on a walk.

5:07And so, yeah, this is me taking a walk, I suppose. I don't know what happened to my leg there. But ultimately, I'm going on a walk, and I'm letting the software know that, hey, I'm in this part of the map. And so I click this spot, and it maps the signal to that location. And I map myself all throughout this domain. And then I go and I move my access point to a different spot, and that helps me to determine where the access points are going to go. And so this is the ideal type of survey that we need to do. However, there are a couple of roadblocks to this. First and foremost, it assumes that I have access to the location which I might not have access to.

5:43It might be overseas. It might be too far away to drive. Or maybe it's a dangerous chemical plant, or something like that. And so I might not have access. And second of all, it might not be ready. I once showed up for a wireless site survey, and literally the walls for the building were not up yet. That was a gross miscommunication between me and the customer. However, naturally, there's not much point in doing a wireless site survey if there are no walls in place. Because when we install the walls, it's going to completely change the RF signal.

6:13And so that site wasn't ready. And therefore, we need to make sure we not only have access to the site, but we need to make sure that it is ready to go, that there's no walls that are going to be built after the site survey is completed. Otherwise, the site survey is going to be very inaccurate. So in the situation where one of these is not actually applicable, we can use what's known as a predictive site survey. A predictive site survey is going to leverage software in order to predict what the wireless signal is going to look like. And so we can ideally use a software package, like one of these we mentioned over here.

6:48By the way, Cisco's Prime Infrastructure will also do a predictive site survey. But what we can end up doing is we upload a map, a floor plan. And so we've kind of got this deal that we had on the left. So we've got some rooms on here, et cetera. And so I end up mapping-- I have no idea what's going on with this floor plan; there's no hallways in there-- but either way, I actually tell it where the walls are. And so I say, OK, these are the walls. They are drywall, for example. Or maybe they're brick, or whatever the situation is.

7:18And the software is going to be able to interpret the RF propagation through these concepts based on just mathematical operations. And so I can sort of drag my access points around and say, OK, I'm going to maybe place the access points here, and it runs a predictive survey, and it tells me what that RF signal is going to look like. Now, as we might imagine, if we do a predictive survey, the accuracy isn't going to be quite what we'd get out of the on-site type of survey. However, sometimes it's the best we can do. And so let's make sure we're taking advantage of this software in order to give us something.

7:51Now, in this situation, it's highly advised that when we do our design that we include some amount of spare access points. Because at this point, we might have to make some underlying assumptions that don't end up being true. And that's nobody's fault unless we didn't think about this in advance. So it's better to include some spare access points to say, hey, we do actually need a fifth access point right here. Where are we going to get that? I don't want to have to go back and ask for more money in order to buy another access point. Instead, I'll just tap into my spares, which we all agreed in advance what we would purchase.

8:21Now, regardless of whether we do an on-site survey or predictive survey, either way, we're going to want to make sure that we do a post-deployment survey. Meaning that, once the access points are in place and the environment is ready to go, before we go live, we want to do one more survey. We want to establish one more heat map that tells us what the actual signal ended up looking like. And so we can do a few things here. First of all, we can make sure that it did end up being good enough. And so, hey, yes, we're either good or, hey, maybe we need another access point somewhere.

8:52Which, once again, is more reason to have a few spare APs in the deal. However, the other thing we can do is we can take this back and look at our methodology for performing the site survey, as well as possibly the predictive site survey, if that's what we used, and try to figure out, OK, we had a few dead spots in here. What happened? Oh, we made a bad assumption. Or maybe the site wasn't as ready as we thought. And we can take those as lessons learned into the next site survey that we do. But ultimately, this part right here, this post-deployment survey, is going to tell us whether the wireless environment is ready for live production traffic before we actually put that live production traffic in place.

9:28So the goal of the site survey is that we want to create one of those heat maps, to help us determine what the wireless coverage is going to look like as part of our design. And so ideally, we can get on site and do a physical site survey. But that does require that we have access to the site and it also requires that the site is ready. And if either of those things isn't in place, then we can do a predictive site survey as well. Now, lastly, once the implementation is done, we should always do a post-deployment survey. That's going to tell us what the actual environment looks like. It's good for documentation as well, in case something changes in the future.

10:00But at the same time, it's going to tell us whether or not we're ready for live production traffic to get on here before we actually flip the switch and put it on there. I hope this has been informative for you, and I'd like to thank you for viewing.

0:05We did all of our information gathering. We've done the site survey. It is time to create that low-level design. In this video, we're going to just do an overview of what this design process looks like so that we can know what to expect when we start doing wireless designs. So we have all of the information that we gathered as part of our prepare and plan phases. We also performed the site survey. And so we know all of the RF requirements-- in other words, the number of access points and where they're going to go. And so now it's time for us to deliver the low-level, or detailed, design plan. This is going to be a set of documentation that we're going to deliver for the purposes of making a decision.

0:40This might, by the way, also include some kind of presentation. And as I always say, it doesn't matter whether this is us as IT consultants or us on an IT team. Either way, we are typically not the decision makers if we're also doing the technical design. If we are, then, hey, this is a cut and dry situation. I'm just going to approve my own designs. But chances are, we have other stakeholders that are going to need to understand this. And this is why documentation and presentation are going to be very important. Now, I know us as engineers, these are two things that we're not always typically very comfortable with.

1:12However, I highly encourage everyone who's watching this to put a little bit of effort into presentation skills as well as being able to write well because these are non-technical skills. These are what we call soft skills that go a long way towards developing us towards a lifelong career as a network architect. It can't always be knowing the technical differences between wireless LAN controller A and wireless LAN controller B. If this is all we end up focusing on as solutions architects, then we're going to miss a big part of what it means to be in this role.

1:45Now, fortunately for us, this is not on the exam. So we don't need to worry about this. This is just more of something that I encourage us all to participate in as far as real life is concerned. So now that we have all this info, what kinds of things go into our design? Well, we do need to start with the individual components. And one of the biggest components in a Cisco lightweight wireless design is going to be the wireless LAN controller. This is huge. We need to decide, for example, are we deploying a hardware controller? Or are we deploying some kind of software controller?

2:17Are we going to go with an embedded wireless controller for a smaller site? Are we going to go with the 9800-CL for deploying into a private or public cloud? We also need to decide where in the network this is going. Especially if it's a hardware solution, this might be going into the distribution layer or the core layer or possibly the data center. And we've indicated before that this matters a lot because if we are tunneling data through the wireless LAN controller, then our clients are actually going to show up wherever the wireless LAN controller is.

2:48And if that's inside the data center, we might have just bypassed firewalls that were supposed to be inspecting client traffic going into and out of the data center. And so let's be very careful if we're tunneling our data traffic, which in most cases we will be. We also need to figure out the high-availability portion of this. Our wireless LAN controller environment needs to stay online. And so are we going to take advantage of stateful switchover? Are we going to have redundant wireless LAN controllers in different locations? And also, we need to make sure that licensing is all set. And not just licensing, I suppose, but also sizing.

3:19And that's especially true, once again, if we're deploying hardware wireless LAN controllers. Now, naturally, we also need to make sure we're getting the correct access points in place. And do we need 6-gigahertz radios? Is that what we decided as part of our info gathering? Can we get away with dual 5-gig bands? And so that might be an option. Or can we go with single 5-gigahertz radios? Do we need, by the way, the Cisco RF ASIC? I would argue in most cases, absolutely. This is the value of Cisco, and we want to be leading with this. However, did we decide that we don't actually need this in this environment?

3:51Maybe it's a small, medium business type of situation. Regardless, we need to make sure that we are meeting the minimum specs for our design. If we're not meeting the minimum specs, then this is not a valid design whatsoever. So let's make sure we're meeting the minimum and possibly then adding some other maybe optional features into the mix that could create at least some conversations around whether or not that's a good idea. Now, we've also mentioned a few different times that we need to consider the switching environment. And so this isn't just about wireless.

4:21At least in the real world, I don't expect to be asked a whole lot of questions on the ENWLSD about the switching infrastructure. However, in real life we need to ask questions. For example, does the current switching infrastructure support multigig? Does it support the right version of PoE. In other words, do we have PoE+ on here? Do we have PoE++? Do we have Cisco's UPOE? And so we covered these earlier on in the course as well. And importantly also, the power budget because it's one thing to say that we support UPOE. But if we're deploying a whole lot of UPOE access points, if each switch only supports a limited power budget, then we might run out of power really fast.

5:00And then there is the other category, which is pretty much just everything else that we should be talking about as part of a design that we might not actually think about to start with. For example, do we need to include any copper or fiber patch cables especially if we're connecting our wireless LAN controllers into larger switches at 10 gig, 40 gig, even 100 gig, which is supported? What type of connectivity are we using there? Furthermore, do we need copper connectivity to the access points? A lot of times when we're installing the access points in the ceiling, the copper run is going to be terminated into a female connector.

5:32And so we'll need a patch cord to connect our access point in. And by the way, is that Cat6A? Is it some other type of connector? So let's make sure that we've got the right cables there. Furthermore, by the way, who's pulling all of these runs? Is that going to be us? Are we responsible for that? Or are we hiring somebody to do that? And so let's just make an assumption there that those runs are just going to magically show up. And by the way, if we're doing it, do we have the tools in order to accomplish this? Or do we need to go purchase some of these? And if we have labor involved, whether it's our own labor or somebody else's labor, do we have that scope of work document that's going to define what's being done and what's not?

6:08So if we are a consultant going into a shop, we probably better create a scope of work defining what we're doing and what we're not. And conversely, if we're a Cisco IT shop, do we have an SOW internally to say how we're doing things for our own project management? And do we have an SOW from our consultant which might be defining for us what we're expecting them to do? And so ultimately, what we're going to do is we're going to create the final design deliverable. And so for example we're going to have the overall design document that talks about what we're doing and why we're doing it.

6:39We're also going to have the associated bills of materials or possibly quotes depending on the situation. Either way is fine. We need to understand what the price is as well as what we're getting. That's what the bill of materials would list. Although, the quote should list that as well. We also need to make sure that, once again, we've got the scopes of work in there if we have any of those as well as just anything else that's relevant to the overall design. And so all of this needs to go ultimately to the decision makers. Maybe that's our bosses. Maybe that's a customer. Maybe that's the team.

7:10Maybe you or me or whoever put this together is actually going to be part of a committee that makes this decision. But in the end, we've got to make sure that we have everything together so that the right decision can end up being made as far as the design that we created. So ideally, at this point, we've done our due diligence. And hopefully the decision is made to go to implementation. But we can only control what we can control. And so that's why we need to make sure we're controlling all of this, regardless of what decision is made around the implementation itself. So as far as this part is concerned, we want to make sure that we are creating a formal design document.

7:43That needs to have everything in it that is justifying the purchase of the solution, but also making sure that we give the reasons why we're speccing things out so that if questions are asked later we can refer back to this document because we might also forget why we specced out this particular type of fiber cable or what have you. And so we're going to assemble all these documents. The BOM, the quote should have all of the components in it, whether it's wireless LAN controllers and access points and switches and cables. All of these things should be part of the document that we put together.

8:14And then we're just we're going to hand it over and say, OK, here you go. And maybe there's a presentation involved. Or maybe it's truly just an email or physically handing things off. But ultimately, it's up to the decision makers at that point to read things through and maybe get back to us with questions. But ultimately, we respect their decision. And hey, hopefully, we end up moving on to an implementation. I hope this has been informative for you, and I'd like to thank you for viewing.

0:00[LOGO MUSIC] All right. Let's take a quiz to see if we can describe that wireless design process. First up out of three questions-- starting with "Prepare" at the top, map the six Cisco lifecycle phases to this diagram. All right. So hopefully, we can remember this acronym down here-- PPDIOO. And then, we just have to keep track of which P is which, and which O is which.

0:30And so it starts with Prepare, and then it goes to Plan. And then from there, we go to Design and Implement-- that would be our D and our I-- and then to our two Os. Well, the first one is going to be Operate, because that just means that we're operating the network we just installed. And while we're operating it, we're going to occasionally move into this Optimization, or Optimize phase. That helps us to figure out what we need in order to maybe make our network better. And so that'll lead to another Prepare phase, which leads to another Plan, and ultimately, another Design that could lead to new implementations.

1:01And so again, the focus here is the fact that we're always going to be in this lifecycle at some point. We've never arrived at the end of the network. Instead, we are going to continually be going around this cycle, which is just part of our lives in IT. Question 2-- what is the best way to ensure we are seeking the best solution rather than the one we would rather, or want to, deploy? All right, so the answer here is going to be C-- asking a lot of questions.

1:32Remember, we want to open our mouths not to talk, but to ask a lot of questions, and to get the customer, the stakeholder, whoever is responsible for this decision-- we want to get them talking so we understand the needs. The more we can meet the needs of the technical solution, the more likely it is that our technical solution will get accepted. So yeah. At some point, we might have to defend the benefits of the Cisco solution. But that shouldn't be the first thing out of our mouths. We also don't want to just sell the least expensive solutions. That's not the point. Customers aren't always looking for the least expensive solution.

2:02If that was the case, Cisco would be out of business, because Cisco is rarely the least expensive solution. Instead, we need to make sure that we're finding, again, the right solution that meets the needs. And opting out of ever selling our favorite access points-- that might just get us into trouble. We don't want to say, OK, I'm never going to sell my favorites. That would be counterproductive. Instead, let's just make sure that we're mapping the appropriate solution to the need, regardless of what that solution ends up being. All right. Last question. What information is needed prior to starting a pre-installation wireless site survey?

2:38The key here is, what information is needed prior to starting it? And it's the fact that this isn't our post-installation survey. This is a pre-installation survey. And so the answer here is going to be B-- whether or not voice and video or in use. Because this, as we've mentioned, is going to affect our received signal strength indicator, what we consider to be a good value and not a good value. It's going to affect our cell overlaps. And it's going to affect of percent of packet loss. And so if we're doing a wireless site survey where voice and video aren't going to be in use, but then we find out later that it will be in use, that site survey is rendered obsolete.

3:12We're going to have to do it again. So let's make sure we have that information up front. As for the rest of these, if we're planning to reuse existing access point poles, that can be a beneficial piece of information. However, we have to be careful about this, because we don't want this dictating where the access points will go. We want the RF signal to be dictating where our APs go. We'd rather re-pole an access point connector rather than installing an access point where it doesn't belong. Now, how many access points will be needed? Well, this is the point of the site survey. We're not going to have that information before the survey. Otherwise, we don't need to perform the survey.

3:44And which wireless LAN controllers are going to be in use should not actually affect the RF signal. If anything, which access points would be in use-- that's going to matter, because that might determine whether we're doing the 2.4-gig band, or the 5-gig band, or the 6-gigahertz band. And so this information is good. However, the wireless LAN controllers-- that's not going to affect our wireless site surveys. So with that, the quiz is done. If you found that you didn't quite survey all of this information appropriately, then be sure to go back and do that before moving on to the next skill. Otherwise, congratulations on completing Describe the Wireless Design Process.

4:15I hope this has been informative for you, and I'd like to thank you for viewing.