Describe the Wireless Design Process

0:05Welcome to design the wireless design process.

0:08Here we are, starting in on domain one of this blueprint.

0:12And so everything up until now, if you've

0:13watched through all of the conversations and the skills

0:17that we've had up until now, those

0:18have all been laying a foundation

0:20to make sure that we are good to go

0:22from just a baseline level of knowledge

0:23about wireless, to ensuring that we can now

0:25start to have conversations around wireless designs.

0:28And so what we're going to do is we're going to, first of all,

0:30take a look at Cisco's lifecycle for the network.

0:34The idea here is that we don't just create networks--

0:37we design a network.

0:38We install a network.

0:39And then that network is forever good.

0:41I think most of us have been in the industry long enough

0:43to understand that, at a minimum,

0:46everything gets old eventually and everything will eventually

0:49be replaced.

0:50However, we also want to make sure

0:51that we're looking for ways to optimize our network,

0:53even while we're running it.

0:55And so we're going to take a look at Cisco's definition

0:57of that network lifecycle.

0:58And from there, we're going to look

1:00at the process of a wireless design.

1:02We're going to start with the idea of gathering information.

1:04How do we go about having a conversation

1:06with the key stakeholders?

1:07Now some of us might be IT consultants

1:10and so we're going to a company and asking them questions.

1:12Others of us might work within a networking

1:15team for an organization.

1:16And even then, we need to go to the business people who

1:19are involved with this decision-making process

1:21and try to figure out, OK, what exactly are we

1:24trying to solve here?

1:25Do you just want Wi-Fi 6 because you watched a YouTube video

1:28on it?

1:28Or are we having problems or are we

1:30delivering new applications that are

1:32going to be business drivers for deploying a new wireless

1:34network?

1:35From there, we're going to talk about site surveys

1:37and understand what exactly those are

1:39and how we go about performing those.

1:41And then we're going to end with just what it looks like

1:44to put together a design and hand that off

1:46to the decision-makers in order to make that decision,

1:49and hopefully, end up going towards an implementation.

1:51So by the end of this, hopefully,

1:53we'll have a good understanding of what

1:54this design process is supposed to look like from start

1:56to finish.

1:57So with that, let's get started.

1:58I'll see you in the next video.

0:00[MUSIC PLAYING]

0:05All right, PPDIOO and PBM.

0:08Jeff, what in the world are we talking about here?

0:10Well, as mentioned in the intro video,

0:11we never deploy a network and it's just done forever.

0:17Instead, we're going to find that as we work on a network,

0:20that we're going to look for ways to optimize it and improve

0:22it.

0:23And every now and again, we're going to

0:24have to replace old hardware with new hardware.

0:26And so this is a cycle.

0:27We're always looking for what's the next step in this cycle?

0:31We've gone from a design, maybe, to an implement,

0:33and from an implement to an operate.

0:35And that's what PPDIOO defines for us.

0:38So this stands for Prepare, Plan, Design, Implement,

0:41Operate, and Optimize.

0:42This is the life cycle that Cisco wants us to understand,

0:45and so we're going to cover that in this video.

0:47And then Cisco eventually also simplified that model

0:49to the Plan, Build, and Manage--

0:52that would be the PBM model.

0:53And we'll take a look at how that

0:54compares to PPDIOO, as well.

0:58Cisco has been touting the network lifecycle, this PPDIOO

1:01concept, for a very long time.

1:03In fact, in the mid-2000s, I was taking Cisco wireless exams

1:06when I first heard about this network lifecycle.

1:09And we had to memorize all of the steps, the prepare,

1:12and the plan, and the design, and the implement,

1:14and the operate, and the optimize.

1:16And then each one of these major steps had subcomponents.

1:19So I had to learn all the subcomponents that

1:21went along with each one.

1:22And then each one of those had tasks.

1:24And so it was this nightmare of a memorization exam

1:27that, fortunately, Cisco doesn't seem

1:29to drill that deep into on exams anymore.

1:32And so for the purposes of this exam, primarily

1:34what we need to understand are each one of these steps,

1:37and how that helps define for us the network lifecycle.

1:39And so what we already mentioned is that we don't actually

1:41just design a network, and then we implement the network,

1:46and then it's done forever.

1:47I mean, that's just not even the case,

1:48even if we were to add on here, for example,

1:50OK now I'm going to operate the network.

1:53The reality is that eventually we're

1:54going to have to come back, somehow, to this design phase

1:57because we are going to be ready to replace hardware.

2:00And so this is why it's more of a cycle.

2:02And so the idea, here, is that we've

2:04got these six concepts around in a circle,

2:08and so we're going around in the circle this way.

2:10And so we start with the prepare phase up here.

2:13Let's just say that this is prepare, PR,

2:15and then we've got plan over here, PL,

2:18and then we've got the design phase, the implement phase,

2:21the-- oh, I know, all these dots look like O's, so that's not

2:23super helpful.

2:24So we've got the operational stage right here,

2:27where we're operating this network.

2:28And then we've got the optimization stage

2:30over here, which is where we might identify

2:32weak points in the network.

2:34Maybe it's time to upgrade our wireless LAN controllers,

2:36or our licensing, or the access points,

2:39or something like that, which is why we lead back

2:41to the prepare phase, which ultimately ends up

2:44going through planning and resulting in another design.

2:47Let's talk about each one of these phases.

2:49We'll start with the prepare phase.

2:50The prepare phase is truly just the very start of any process

2:54where we're going to start asking some questions.

2:57For example, what is needed here,

2:59as well as a very important question,

3:01which is, why is something needed here?

3:03What's the business case leading towards a network design?

3:08This is often going to result in the creation

3:10of a high-level design.

3:12When we say high-level design, we mean very few details.

3:15So the way I like to think of it is,

3:17if you're in an airplane way up above the sky like this,

3:21you're at a very high level.

3:22You're maybe at, I don't know, 20,000 feet above the surface.

3:26And so when you're looking down at the ground down here,

3:30you're going to see a whole lot fewer details.

3:33And then a low-level design is as if you were maybe either

3:36flying lower, sure, or maybe you're

3:37actually down here standing on the ground.

3:40Once you're standing on the ground,

3:41you can absolutely see if there's

3:44ants on the ground right next to you,

3:46or the details of every blade of grass.

3:48You can see all of those details because you're

3:50a whole lot lower to the ground versus if you're

3:53in that airplane which you're, at that point,

3:56way higher off the ground.

3:57And so I just like to use that analogy

3:58to help us understand the difference between a high-level

4:01and a low-level design.

4:02So when we're talking about a high-level design,

4:04we might say something like, you know what, we really just want

4:07some Wi-Fi 6E in here.

4:09And that's it.

4:10We don't know if we're going with Cisco access points.

4:12We don't know if we're going to go with a particular Cisco

4:15access point.

4:15Now at the time of this video, there's

4:16only one access point that supports 6E, but by the time

4:19you're watching this, there might be two or three.

4:21And so we're not going into those details.

4:23We're just sort of giving this high-level option to say,

4:26this is what I'd like, and this is why--

4:29we need more bandwidth, we need better coverage,

4:31we're having drops, or what have you.

4:33And so we've defined, now, the what and the why as

4:36part of our prepare phase.

4:37Now planning sounds sort of similar.

4:39However, the focus, here, is to start looking at what we have.

4:43And that's what's key.

4:44We're going to start to identify specific needs,

4:47and we're going to start to set some requirements as well.

4:50And so we might say, all right, the new solution

4:52needs to support voice and video.

4:54Maybe we've needed location services,

4:57and that's what we're lacking.

4:58So ultimately, what we've done, here,

4:59between preparing and planning, is

5:01we've laid the groundwork for creating an actual network

5:04design.

5:05And this network design, as we see over here in the life cycle

5:08down here, this, ideally, is going

5:10to lead to an implementation.

5:12And so we've been gathering a lot of information

5:14up until now.

5:14It's time to put it all together and create an actual design.

5:17And so this is where we would decide

5:19to go perform a site survey.

5:21We're also going to create a Bill Of Materials, otherwise

5:23called a BOM.

5:24And, yeah, that's BOM without a B, by the way,

5:27because in English the word bomb means explosive,

5:30and we don't want to talk about that kind of bomb.

5:32This 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

5:39than that.

5:40We need to include software components.

5:41We need to include licensing.

5:43We need to include SmartNet, for example.

5:45And so this bill of materials is going

5:47to be all of the components of a solution

5:49that we need to purchase.

5:51Now typically what really matters is the quote.

5:54And so, if you're working for an IT consultant,

5:56you're probably going to have to create a BOM,

5:58and then you're going to end up creating a quote as a result,

6:01and delivering the quote to the customer.

6:03If you work for an organization, you're

6:04working with a Cisco partner in this situation,

6:07you might work with the Cisco partner to create the BOM,

6:09but ultimately what matters a lot,

6:11is the quote because that's going

6:12to be the final pricing as far as

6:14what it's going to cost your organization to purchase it.

6:16Now I always say that documentation is absolutely

6:19king, especially in this phase.

6:21We need as much documentation as possible,

6:24laying out the solution, as well as the justification.

6:27So we're going to say the same two

6:29questions-- what is included in this, and why it's included?

6:34For example, I'm including a wireless LAN controller,

6:36a 9800-80, because we have established

6:40that 80 gigabits per second is required.

6:43The last thing we want to do is go implement something

6:45like this wireless LAN controller,

6:47and 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,

6:55because that would have been a whole lot better fit.

6:57And if we justify it, we say, well we

6:59ran a particular set of tests, and it

7:01indicated it would be 45 gigabits per second,

7:04or 30 gigabits per second.

7:06We wanted room for growth.

7:07And that way we can at least point back

7:09to why we were including it.

7:11And that'll help answer a whole lot

7:12of those types of questions.

7:13But importantly, as well, the "what" right here,

7:16this is going to spell out for our implementation team

7:18what exactly we're doing.

7:20And for example, we included 10 gig twinax for connectivity

7:23between the wireless LAN controller

7:25and this particular switch.

7:27And so if they go to that switch, and they realize that,

7:29hey, this switch is full.

7:31And then we can say, well, at the time,

7:32that switch wasn't full.

7:33And so we didn't just make a bad assumption.

7:35We actually validated it, and at the time,

7:38it was good information.

7:39We also might need a Scope Of Work, or an SOW.

7:42The scope of work is primarily needed for situations

7:45where we have labor involved.

7:47Now, this can have a lot of different angles.

7:49It could be that you're again an IT consultant,

7:52and you're selling your labor.

7:53You could be part of an organization

7:55where they want to understand how much labor

7:58is going to be expected.

8:00And so a project manager will use the scope of work

8:02to help us understand, OK, this project

8:05should have taken 150 hours.

8:07It ended up taking 250 hours.

8:08And they can look at this and say, well,

8:10that's because we went above and beyond what

8:12we said we were going to do.

8:14And so this is a very important document as well.

8:16The point of all of this is, as we recall,

8:18up here we talked about creating a high-level design

8:21in the prepare phase, but in the design phase,

8:23this is all very low level.

8:25So the end result of this phase is

8:27that we've got the low level, in other words

8:30the detailed design.

8:31And there should be a set of documentation

8:33that includes a lot of these documents.

8:35It's got to have the bill of materials, and the quote,

8:38and the scope of work, and the general documentation

8:40describing the "what" and the "why" of what we're installing.

8:43Now, the goal of the design phase

8:45is to lead to an implementation phase.

8:47Now, it's always possible that the decision

8:49makers decided not to do the implementation,

8:52and that's fine.

8:53However, assuming that the design is accepted

8:55and purchased, we are now going to be

8:57implementing the solution.

8:58And so we have to place the order for all of the equipment.

9:02And so there might be a downtime.

9:03We might have to wait six or eight weeks for all

9:05the equipment to get in.

9:06And so it's important that we do this part first.

9:08Like when you're baking cookies--

9:10I don't know about you, but I always forget to set the oven.

9:13Set the oven for 350 degrees, and then start

9:16making the cookie dough.

9:17And that way, when you're done with the cookie dough,

9:18the oven is all warmed up.

9:20And inevitably I make the cookie dough.

9:21I turn around.

9:22I never set the oven.

9:23And so now I have to wait 20 minutes for the oven

9:25to heat up and start baking the cookies.

9:27I don't know if that analogy really works that well.

9:30But hey, if we forget to order the equipment up front,

9:32then we might do a whole lot of work

9:33and then realize that we've still

9:34got to wait two months in order for that equipment to arrive.

9:37Now while that equipment is coming,

9:39we can go stage the area.

9:41So that might mean that we've got a rip apart a room that

9:44is going to house all of the switches that we're installing,

9:47all the access points.

9:48Maybe it's just going to be a desk somewhere.

9:50But we need a place for all of the equipment

9:52to go where we can configure it and get it up and running.

9:55And maybe, especially in a multiphase project,

9:58we might be operating out of this room, as well, as far as

10:01installing so many access points at night.

10:03At some point, the goal here is to perform

10:05the cutover, where we're actually

10:07installing this equipment.

10:08Maybe it's all rip and replace, maybe it's a phase migration.

10:11But after the cutover, we do the Network Ready

10:13For Use tests, or NRFUs, which more or less allows

10:16all of the stakeholders to sign off

10:18and say, yes, the network is working.

10:20Everything is working as intended.

10:21And at that point, the implementation phase is done.

10:24Now next up is the operate phase.

10:26This phase is simply us using the network

10:28that we just installed.

10:29And so we need to keep the system online and operational.

10:33We need to make sure everybody is trained on the new system

10:36because that's kind of a big deal.

10:37If we just changed maybe from Aruba access points

10:40to Cisco access points, does the team

10:42understand how to actually manage

10:44this from a Cisco perspective?

10:45We want to make sure that we have

10:47good documentation in place so that our NOC understands what

10:50to do, and our engineering team understands

10:53what to do when problems get escalated.

10:55And so this is just all part of what we call

10:57keeping the lights on in IT--

10:59making sure that the system stays online

11:01and operational for the entire life

11:03that it's intended to deliver.

11:04And lastly, we have optimize.

11:06Optimize just means that we're looking for ways

11:08to make it better, constantly.

11:10And so we want to be proactive in this sense.

11:13We want to be paying attention to what's going well

11:15and what's not going well.

11:16Are there ways that we can improve life here?

11:19In the wireless world this might be paying attention

11:21to RF signal and reports to say, hey, maybe the signal over here

11:26is now dead.

11:26Maybe a wall was put in, and so we

11:28don't have good coverage in the conference room anymore.

11:30I mean, who knows what's happening here.

11:32But the idea is that things are always changing, especially

11:35in today's modern era.

11:36Nothing ever seems to stay the same for long.

11:38So we can't just assume that we're

11:40going to be operating this as it was installed for five or six

11:43years.

11:44Things are going to change.

11:45And we need to be reacting to those changes as best we can.

11:48And so this might actually end up leading

11:50to another prepare phase.

11:52And that's the idea, here, is we're in a cycle.

11:54So we notice something, hey, we need a couple of access points,

11:57here.

11:58Well that is going to take us back around this cycle,

12:01back through operate and optimize, all the way

12:03to our prepare phase.

12:05And so we're ready to do another design.

12:07And this design might be small.

12:08It might just be adding a few access points,

12:10or it might be large where we're going

12:12to completely replace what we installed

12:14five or six years ago.

12:15Now we also need to be aware of the fact

12:17that Cisco has this PBM model in place, as well, now.

12:21This is their way of trying to optimize

12:22this muddled mess, PPDIOO.

12:26Yeah, it actually works pretty well when we draw it out

12:28like this, and we can understand what each phase does.

12:31But it is a tall order for us to be able to memorize something

12:35like that, especially if we have to memorize the components

12:37of each phase as well.

12:38And so what they did was, they took these three first three

12:41phases--

12:42prepare, plan, and design--

12:43and they just wrapped this up into plan.

12:45And understand that that means everything

12:47from asking the initial questions to creating

12:49the low-level design.

12:51Then they have build.

12:52Build is the exact same thing as implementation.

12:55And so that's just a one-to-one mapping.

12:57Now manage, manage would be this section down here.

13:01We are operating, and we're looking continuously

13:03and proactively for how we can optimize our network.

13:06So this would be the M side.

13:08So I didn't write these out but, Plan, Build and Manage.

13:13And so understanding that that model exists as well,

13:16is going to be important.

13:17However I suspect in a lot of cases,

13:19we're going to find Cisco continuing to really relate

13:22back to the PPDIOO lifecycle, at least that's what I've

13:25seen in their documentation.

13:27And it'll be interesting to see over time

13:29if Cisco just sort of abandons that and goes more

13:31towards plan, build, and manage.

13:34All right, so our key takeaway here is that PPDIOO,

13:37it's all about the lifecycle.

13:38And that keyword cycle being that it's a circle.

13:40We're just going to continue to go around in this circle

13:43pretty much forever.

13:44I often joke like, when do we win this game?

13:46When is it over?

13:47It's never over.

13:48We're always looking for the next thing,

13:50whether that's moving from design to implement,

13:52or implement to operate, operate to optimize,

13:55or optimize right back around to preparing, and planning,

13:59and creating a new design.

14:00And so let's just make sure that we have all of those down.

14:03I just listed them all, but from prepare, to plan, to design,

14:06to implement, to operate, and optimize--

14:08we should have that memorized, and the order of operations

14:11as well.

14:12And it shouldn't matter where we start in the cycle.

14:13We do typically start by saying prepare,

14:16but ultimately, hey, if we're in the middle

14:17of an implementation, we need to know what

14:19phase is next in the lifecycle.

14:21Now lastly, we do have plan, build, manage.

14:23Plan, build, manage is the exact same concept.

14:25It's all the same tasks.

14:26It's just categorized under three phases rather than six,

14:30and so we just need to know which of the PPDIOO phases

14:33fit into which of the PBM phases.

14:35I hope this has been informative for you,

14:37and I'd like to thank you for viewing.

0:00[MUSIC PLAYING]

0:05All right now that we know Cisco's lifecycle,

0:07the PPDIOO lifecycle that we just defined,

0:10we're going to jump into the prepare and the plan phases

0:12in this video.

0:13That involves a lot of information gathering.

0:15We're going to be asking a lot of questions.

0:17Remember, we need to define what it is we want to accomplish,

0:20and we need to define why it is we want

0:22to accomplish those things.

0:23And so we need to differentiate between what

0:25we'd like to install, in other words our wants, and our needs.

0:28So let's go ahead and dive in and see what kinds of questions

0:31we should be asking in this phase.

0:33All right so let's start with this idea of need versus want.

0:36Because I don't know about you, but I absolutely

0:38love some of this technology that we've been talking about.

0:41I love Wi-Fi 6E.

0:43And if we love Wi-Fi 6E, and the 6 gigahertz

0:47spectrum, and 160 megahertz channels

0:49and all of these things, and if I love Wi-Fi 6E that much,

0:52I might find that every time I'm presented with a problem

0:55that Wi-Fi 6E ends up being my recommended solution.

0:58And so this can quickly become something

1:00that we call a solution looking for a problem,

1:02rather than what we ideally have,

1:04which is a problem that needs a solution.

1:06In other words, if I have a problem

1:08that Wi-Fi 6E will help me with, the Wi-Fi 6E

1:10should be the solution.

1:12It should never be the other way around.

1:13It should never be that, hey, Wi-Fi 6E has

1:16this great 6 gigahertz space, and therefore you

1:19must have a problem with contention in the 5 gigahertz

1:22space.

1:23It just shouldn't work that way.

1:25And that's what we mean by a solution looking for a problem.

1:28So the reality is that it's possible

1:29that we have problems in the 5 gigahertz spectrum.

1:32Maybe we're in a tight metro area,

1:34and we're trying to use 80 megahertz channels.

1:36And so we don't have a lot of those channels,

1:38and therefore the 5 gigahertz space has a lot of contention.

1:41But this is a question we should be asking,

1:44is this a problem that we have?

1:45Do we have a lot of contention in the 5 gigahertz space?

1:48Is this something that maybe we could solve

1:50with dual 5 gigahertz radios?

1:52Is it something that we could solve

1:53by going down from 80 megahertz channels

1:56to 40 megahertz channels and just making smaller cells?

1:59I mean, we've got a lot of different, other solutions

2:02to this type of problem, other than just Wi-Fi 6E.

2:05But the reality is that we might not

2:07have any contention in this spectrum space.

2:09And, therefore, we don't actually need Wi-Fi 6E,

2:12because we can deploy our solution into the 5 gigahertz

2:15band.

2:15So our job as design engineers, ideally,

2:18is to find the right solution.

2:21And when I say the right solution,

2:22I mean what is needed in this situation, while also

2:26taking into account things like budgets

2:27and trying to find the balance there.

2:29Because we shouldn't be looking at "my favorite technologies."

2:33If my job is being perceived as just going in and saying,

2:36hey, this is my favorite technology.

2:38This is what I want to deploy.

2:40Then, we're going to end up losing trust

2:42as design engineers, and we really need to work on trust.

2:45So this should never be our methodology.

2:47Now there is one thing that we can do as design engineers that

2:49will always make sure that we're looking for the right solution,

2:53and that is to ask a lot of questions.

2:55We want to make sure that we best

2:57understand the situation so we don't immediately

2:59go to solving problems.

3:01So in other words, I might want to start by talking,

3:04and say, OK, hey, have you heard about Cisco Wi-Fi?

3:08Have you heard about the Catalyst Series?

3:10So we've got the Cat9Ks, the 9100s, and the 9800s.

3:14And have you heard, by the way, about Cisco's cloud controllers

3:17that we can deploy?

3:18And have you heard, by the way, of Cisco's Wi-Fi 6E access

3:21points?

3:22And this is what we love to do.

3:24We love to go into a room and talk about the things

3:27that we're excited about.

3:28But the reality is that this is a bad strategy.

3:31And this is coming from somebody who

3:32worked for a Cisco partner, who walked

3:34into rooms to have conversations with people about this.

3:37This doesn't work because it shows

3:39that I'm more interested in what I have to offer,

3:42in other words, I'm more interested in what

3:43I want to do, versus what you actually need me to accomplish.

3:48And so instead, we're going to ask questions.

3:50We're going to get the stakeholders to talk.

3:53We want them to talk more than ourselves.

3:55And so what are we going to ask about?

3:57Well we can, first of all, and this

3:59is a huge one, what I would always

4:00start with is, what are the pain points to the current solution,

4:04if we've got a non-Cisco wireless solution in place?

4:07How is managing that?

4:08Is that a pain point?

4:09Do we have RF signal issues?

4:12Are we having dead spots?

4:14Are we deploying real-time applications, maybe, and so

4:17my VoIP calls, they're actually getting dropped.

4:19And so that would be bad.

4:20That would be a lot of pain points that would--

4:23so there's something that we could actually fix pretty fast,

4:25I would think.

4:26Well, we don't just want to stop there.

4:28As soon as I ask about pain points,

4:29and they maybe give some pain points,

4:31if I once again just immediately say,

4:32OK, well, we can fix those, OK, well,

4:34let's hold the phone there because we want

4:36to keep asking more questions.

4:38And so maybe we should also ask about,

4:40what are your primary care abouts in the new solution?

4:43And so, do you care about these voice drops

4:46more so than the manageability?

4:48Because if I hear you say you don't like the way

4:50Aruba is managed, I could really tout how Cisco is managed.

4:54But maybe you care more about the voice over IP drops,

4:57and you don't really care about the management of the solution.

4:59And at some point, we do actually

5:01have to ask about the technical requirements of the solution

5:04that you're looking for.

5:05And so there's a lot of questions,

5:07here, we should ask about that we're going

5:09to be reviewing over time.

5:10But we can talk about, for example, client density.

5:13Is this an environment that we've got 50 school students

5:18all in one room, and they've all got a device or two,

5:20and we need to focus on this high level of client density?

5:24Or is that not of concern?

5:26We do want to ask about real-time applications.

5:28So we just mentioned voice over IP.

5:31And so that's certainly a concern.

5:33We could also ask about video calls, and just

5:37maybe EMR-type applications in a hospital environment-- that'd

5:41be electronic medical records.

5:42And so, what are the apps that are

5:44being deployed into the Wi-Fi space that

5:46are our primary concerns?

5:48We want to find out, hey, do you need location services

5:51as part of this?

5:52Are you planning to track devices

5:53over the course of time?

5:55And, by the way, what are your switching capabilities?

5:57And do we think that we might need

5:59to upgrade our switches as part of this design?

6:01We also want to make sure that we, at some point,

6:03ask about the budget.

6:05In a lot of situations--

6:07again, I'm approaching this from an IT consultant perspective--

6:09you're not necessarily given the budget because we don't

6:12necessarily have the trust level to not just completely spend

6:15every single dollar in the budget.

6:17We should at least get an idea of whether there is a budget,

6:19and, if so, how constrained is it.

6:22Like get a range, so to speak, so we understand

6:24what we're talking about.

6:25Now if we're not IT consultants, if we're

6:27working for the organization in question,

6:29then we probably need to, at least at some point,

6:32get an idea of what that budget is, as well.

6:34Now something we might need to ask,

6:35especially if we're talking about a Cisco

6:37solution versus a non-Cisco solution,

6:39is what are your preconceived notions of a Cisco wireless

6:43solution?

6:44Have you heard about Cisco wireless?

6:46Do you think that you'd be open to that question?

6:48And this is true, by the way, I should

6:50say all of these are true regardless

6:52of whether we're IT consultants or whether we're

6:54working for an IT shop.

6:55Because my decision makers, their preconceived notions

6:59are going to impact whether they want to go with my recommended

7:02solution.

7:03So I might go and say, hey, I'm recommending the Cisco access

7:06points in the 9800s, and the 9136 access points,

7:10and all of this.

7:11And they look at that and say, OK, nah, I'm

7:13not interested in Cisco.

7:15Oh well, why?

7:15Like let's talk about that.

7:16Let's talk about that up front to make sure

7:18that I don't do a whole lot of work that

7:20isn't going to go anywhere.

7:22It also gives us a chance, by the way, to counter those,

7:24to say, well I had a Cisco access point,

7:26and it completely failed, and I hated it.

7:28And you might find out, oh, well that

7:30was a small-medium business access point.

7:33Those are really, really cheap access points,

7:34and we're not going to be talking about those.

7:36And say, oh, OK, well then we could

7:38consider enterprise-level Cisco access

7:40points, such as an example.

7:42And lastly, we probably do want to ask about,

7:44hey, what has worked and especially what

7:47has not worked in the past?

7:49Because if they do say that a Cisco access point hasn't

7:52worked in the past, or if they say that we tried to get away

7:55from the 2.4 gigahertz spectrum, and we tried 5,

7:57and it didn't work, again, this is a chance for us

8:00to address that up front, rather than surprising them,

8:03I suppose, with a quote that involves a band that they

8:06say, well, that didn't work before,

8:07so I'm not going to do that.

8:09So I've got a story that goes along with this, that I think

8:11really exemplifies what I'm trying to say,

8:13which is that when I was working for the Cisco partner, me

8:16and a fellow engineer, we went to a bid meeting--

8:20a bid meeting for a library that they wanted a new data center

8:23network.

8:23And so we went and we were not the incumbents, meaning

8:26that they had purchased Cisco solutions, traditionally

8:29from a different Cisco partner.

8:30But because this is a bid, and it's for a public entity,

8:33anybody can show up.

8:34And so I showed up with my engineering friend,

8:37and we just asked so many questions.

8:40And it wasn't just for the sake of opening our mouths.

8:43We had legitimate questions.

8:44They're saying that they wanted this, and it's like, well,

8:47did you want this, or did you want that?

8:48And so of the probably 10 to 15 questions that were asked,

8:52we asked about 75% of the questions ourselves.

8:55And I think that went a long way because, ultimately, we

8:58were able to create a design that satisfied

9:00all of their actual needs.

9:02I wasn't making any assumptions.

9:04I wasn't putting solutions in that I wanted to.

9:07I mean, yes, ultimately I was putting solutions

9:09in I wanted to, but it was to match their needs.

9:12And so that became very clear in the design

9:15that we put together.

9:16And so when we delivered the quote,

9:17I don't even think we had the cheapest design.

9:19In fact, I can assure you that we did not

9:21have the cheapest design.

9:22But it best matched what they were looking for.

9:25And because it best match what they were looking for,

9:27and they could tell just from the limited experience

9:29that they had with us that we cared about what they wanted,

9:32that ended up becoming our job.

9:34And so we won the business away from somebody

9:36else who would really have liked to have had that business,

9:39I promise you.

9:40They weren't expecting to lose it.

9:42But the reason that they did, was

9:43because they didn't do their due diligence, unlike us,

9:46in making sure that they were addressing the needs,

9:48rather than the wants.

9:49And so this is why it's so important to open our mouths

9:52and ask questions, rather than opening

9:54our mouths to explain what it is we'd like to install.

9:57Now one last thing I want to talk about

9:58is this idea of finding the right solution.

10:02I'm putting this in quotes because, really, what I

10:04want to say here is that there is

10:05no such thing as a right solution.

10:08What do I mean by that?

10:09Well everything we design is going to have upsides to it,

10:12and it's going to have downsides to it.

10:14Now the downsides might be as simple as saying,

10:16you know what, this is a more expensive solution?

10:18Or hey, it might actually be a cheaper solution,

10:21but you're not as familiar with it.

10:23So it might not be technical.

10:25It might be something that exists

10:26outside of the technical realm.

10:28We might also disagree on these concepts.

10:31For example, we might actually be going into a situation

10:34where the decision makers prefer a solution like Aruba.

10:37And so they're saying, hey, we really

10:38like Aruba access points.

10:40And so I'm touting all of the benefits and value

10:42that Cisco has, and ultimately they go with a solution

10:47that we weren't recommending.

10:48Whether, again, we were consultants

10:50or whether this is our own shop making this decision,

10:52it doesn't matter.

10:53The idea, here, is that the decision makers

10:56went with a solution that we disagree with.

10:58And I want to say that that's OK.

11:00Because if we, as engineers, focus entirely

11:03on the technical side of the solution,

11:05we might actually lose a whole lot

11:07of these types of situations.

11:08The reason is, not everybody looks 100%

11:11to the technical side of things.

11:12In fact, I would argue that none of us do.

11:14We're always going to have an emotional response to something

11:17in the same way that somebody came up to me

11:19and tried to sell me on non-Cisco solution,

11:22I'd probably be like, you know what,

11:23I mean you might say that you have the technical chops,

11:26that your solution is technically better than Cisco,

11:29but in my heart I don't believe you

11:30because I really love Cisco.

11:32And so I'm probably just going to end up

11:34going with that in the same way that maybe these decision

11:36makers went with a non-Cisco solution.

11:39I remember once I lost a deal in this fashion.

11:41It was us versus another vendor, and we got really skinny.

11:44We actually were hoping to do a little bit of community

11:47service, in this sense.

11:49We wanted to not make a whole lot of money on this deal.

11:51We just want to get a really good solution

11:53in for a local entity.

11:55And we were the cheaper solution,

11:56even though we were selling Cisco.

11:58We were by far the more technically superior solution.

12:02And yet, they went with the other guys.

12:05What in the world happened here?

12:06Well what happened is that they decided

12:08that they were more comfortable with what they

12:10knew rather than something new.

12:12And so even though that bothered me to the point

12:14that I remember it to this day, I

12:16need to end up respecting that decision

12:18and to understand that we're not always going

12:19to win every single situation.

12:21Even if we have the best technical design,

12:23even if we have the best price, we

12:25might find that we lose a deal.

12:26And all we can do is learn from that

12:28and hopefully take that information with us

12:30into the next situation.

12:32So a few big takeaways here.

12:33First and foremost, as designers,

12:35we need to focus on what is needed in a solution,

12:37not necessarily what we want to install.

12:39And even though that sounds really obvious,

12:42potentially, on paper, we're going

12:43to find that we've got a lot of biases in as far

12:46as what our favorite technologies are,

12:47what our favorite vendors are.

12:48And we carry those biases into our design sessions.

12:51And so one of the best tools that we

12:53can do to make sure that we're not just following that,

12:56is to ask a lot of questions.

12:58Let other people talk.

12:59Ask the questions like we talked about here about, what

13:02are your pain points?

13:03What do you care most about?

13:04What are the technical requirements?

13:05And that way, once you have a grasp of what exactly is needed

13:09here, then we can turn around and say,

13:10you know what, I don't think the 9136 access points are

13:13required in this situation.

13:15And maybe we can get away with something a little bit cheaper

13:19that better meets their budget and still gives them

13:21a solid Cisco solution.

13:23So lastly, we understand that the best or the right solution

13:26doesn't necessarily exist.

13:28Absolutely there are wrong solutions out there.

13:30If we're not meeting the technical requirements,

13:32that's a wrong solution.

13:33But we need to make sure that we respect those

13:35who are making the decisions.

13:36But also understand that decisions are not always made

13:39based on technical specs.

13:41And so the more that we can address, maybe,

13:43the emotional problems that might

13:45be arising with considering a solution we recommend,

13:48if we can address those up front,

13:49there's a greater chance that they'll

13:51pull the trigger on what we would consider the best

13:53technical solution.

13:55I hope this has been informative for you,

13:56and I'd like to thank you for viewing.

0:00[MUSIC PLAYING]

0:05Well, we have heard a lot about site surveys,

0:07and we're going to keep talking about wireless site surveys.

0:10In this video, we're going to lay a foundation

0:12for defining what exactly a site survey is, what the goals are,

0:14and how we go about doing them.

0:16Wireless designs have a dimension to them

0:18that no other type of network design has,

0:21which is the concept of RF signal.

0:23We've got to worry about the radio frequency signals

0:26in our environment and where they're going to go

0:28and whether they're going to reach to the corners.

0:30And so, as a result, we need to know where every single access

0:34point should be placed.

0:35So AP placement is a very important part

0:37of every wireless design.

0:39Well, I can't know for sure where each access

0:42point is going to go unless I test and figure it out myself.

0:46And there's a lot of methods to this,

0:48but the goal is ultimately the same.

0:49It's to determine the optimal placement

0:51for the access points that gives me the coverage that I need.

0:54And eventually we're also going to talk about not just

0:56coverage but capacity.

0:58Because we need both of those to be

1:00considered as part of a modern wireless site survey.

1:03So how exactly do we go about doing this?

1:05Well, first and foremost, we're going

1:07to leverage some kind of software tool.

1:09And there's a lot of software packages out there

1:11that accomplish this.

1:12In my experience, the two more popular ones, I would say,

1:15are going to be Ekahau as well as AirMagnet.

1:19And the idea here is that we're going

1:21to walk around the environment and figure out

1:23where certain signals map as far as the floor plan is concerned.

1:28And so the goal is to create a heat map.

1:31The heat map is going to look like any kind of temperature

1:34map, maybe a weather map that you've seen, that in this case

1:37is going to show the floor plan.

1:38And so we've got a floor plan here.

1:40We've got a bunch of rooms.

1:41We've got the doors, the hallways, et cetera.

1:44And so ideally what we're doing is we're walking around,

1:47we're recording signal strength, and that's

1:49going to map the heat map on top of this.

1:51So we've got a wireless signal that

1:52looks like this and a wireless signal that looks like this

1:55over here, and we see that it's maybe weaker in the corners

1:58and stronger right next to the access point.

2:00And so that is the ultimate goal of a site survey.

2:03Now, a site survey is always going

2:04to come with a set of requirements that

2:06must be defined ahead of time.

2:08Because we've got several different types

2:10of wireless networks that we could end up implementing,

2:12and the site survey needs to reflect that.

2:14For example, we need to define whether there are

2:16real-time applications in use.

2:18And the most common, most prevalent real-time application

2:22that we need to concern ourselves with

2:23would be voice over IP.

2:25Do we have voice over IP calls happening,

2:28and do we have video calls, or some kind of video application?

2:31Or any type of real-time application,

2:33really, is what we care most about.

2:35Because if we do have real-time applications, then

2:38this is going to affect many things.

2:40It's going to affect the overlap of our different cells.

2:43It's going to affect the overall signal strength as far

2:47as what's considered to be a valid signal strength

2:50and what is considered to be a not valid signal strength.

2:53And then packet loss is also going

2:54to be affected by these types of decisions.

2:57And so if we don't have good enough packet loss percent,

3:00in other words, if the percentage is too high,

3:02then at that point it might have worked for a data site survey,

3:05but it's not going to work for a real-time services

3:08type of survey.

3:09The other question we might ask is, are we

3:10going to need location services?

3:13Because if we're going to be tracking devices

3:15and where they go, this changes where we place the access

3:17points as well.

3:18We form this sort of cage of access points

3:21with location services.

3:23So if we don't have location services in place,

3:25we might have our access points that look something

3:27like this, where we're trying to service the entire area

3:30and get coverage everywhere.

3:31I know my circles didn't quite cover everywhere,

3:33but for the sake of this demonstration,

3:36let's just assume that they are.

3:37Location is going to change that, in that we're

3:39going to place access points around the perimeter, as well,

3:42and try to form triangles.

3:44And so the triangulation concept is

3:45going to come into play here.

3:47And so, depending on whether we need location services or not,

3:51naturally this is going to heavily impact

3:53our AP placement.

3:54And we might end up having to do a survey that

3:56looks like this versus one that just supports

3:58real-time applications.

4:00And lastly, we might just find that we're

4:02deploying a data network.

4:04A data network these days is pretty far

4:06and few between that we have these actually.

4:09It means that we're not having any kinds

4:10of real-time applications and we're not deploying

4:13any location services.

4:14So this is basically just a vanilla type

4:16of site survey, which is going to look a whole lot

4:18like the one on the left here.

4:20However, our overlap and our signal strength and our packet

4:23loss are less stringent than they

4:24would be if we were deploying voice over IP.

4:27So ideally, what we're going to do

4:28is we're going to perform an on-site walkthrough in order

4:31to do the site survey.

4:33And so this typically actually involves

4:35some kind of AP on a stick, I like to call it.

4:38An AP on a stick means that we're literally mounting

4:40an access point to a stick.

4:42And so we've got the access point hanging here,

4:44and it needs to be mounted as if it's on the ceiling.

4:47We want the access point to be as

4:48close to the ceiling as possible,

4:50so we want this to be a pretty tall stick.

4:51And then maybe this is on wheels in some capacity.

4:54And so we're rolling it around.

4:56And what we do, assuming we've got some kind of battery

4:58on here that powers the access point,

5:00is we leave this in a place and I, with my laptop or my tablet

5:04or 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.

5:10I don't know what happened to my leg there.

5:12But ultimately, I'm going on a walk,

5:13and I'm letting the software know that, hey, I'm

5:16in this part of the map.

5:18And so I click this spot, and it maps the signal

5:20to that location.

5:21And I map myself all throughout this domain.

5:25And then I go and I move my access point

5:26to a different spot, and that helps

5:28me to determine where the access points are going to go.

5:31And so this is the ideal type of survey that we need to do.

5:35However, there are a couple of roadblocks to this.

5:37First and foremost, it assumes that I

5:39have access to the location which I might not have access

5:42to.

5:43It might be overseas.

5:44It might be too far away to drive.

5:47Or maybe it's a dangerous chemical plant,

5:49or something like that.

5:50And so I might not have access.

5:52And second of all, it might not be ready.

5:54I once showed up for a wireless site survey,

5:57and literally the walls for the building were not up yet.

6:00That was a gross miscommunication

6:02between me and the customer.

6:03However, naturally, there's not much

6:05point in doing a wireless site survey

6:07if there are no walls in place.

6:09Because when we install the walls,

6:11it's going to completely change the RF signal.

6:13And so that site wasn't ready.

6:15And therefore, we need to make sure we

6:16not only have access to the site,

6:18but we need to make sure that it is ready to go,

6:20that there's no walls that are going

6:22to be built after the site survey is completed.

6:24Otherwise, the site survey is going to be very inaccurate.

6:28So in the situation where one of these

6:30is not actually applicable, we can

6:32use what's known as a predictive site survey.

6:35A predictive site survey is going to leverage software

6:38in order to predict what the wireless

6:41signal is going to look like.

6:43And so we can ideally use a software package,

6:46like one of these we mentioned over here.

6:48By the way, Cisco's Prime Infrastructure

6:50will also do a predictive site survey.

6:52But what we can end up doing is we upload a map, a floor plan.

6:57And so we've kind of got this deal that we had on the left.

7:00So we've got some rooms on here, et cetera.

7:03And so I end up mapping--

7:04I have no idea what's going on with this floor plan;

7:06there's no hallways in there-- but either way, I actually

7:09tell it where the walls are.

7:11And so I say, OK, these are the walls.

7:13They are drywall, for example.

7:15Or maybe they're brick, or whatever the situation is.

7:18And the software is going to be able to interpret the RF

7:21propagation through these concepts based on just

7:24mathematical operations.

7:26And so I can sort of drag my access points around

7:28and say, OK, I'm going to maybe place the access points here,

7:31and it runs a predictive survey, and it tells me

7:33what that RF signal is going to look like.

7:35Now, as we might imagine, if we do a predictive survey,

7:38the accuracy isn't going to be quite what we'd get out

7:41of the on-site type of survey.

7:43However, sometimes it's the best we can do.

7:45And so let's make sure we're taking

7:47advantage of this software in order to give us something.

7:51Now, in this situation, it's highly advised

7:53that when we do our design that we include some amount

7:55of spare access points.

7:56Because at this point, we might have

7:59to make some underlying assumptions that

8:01don't end up being true.

8:02And that's nobody's fault unless we didn't

8:04think about this in advance.

8:05So it's better to include some spare access points

8:08to say, hey, we do actually need a fifth access

8:10point right here.

8:11Where are we going to get that?

8:13I don't want to have to go back and ask for more money in order

8:15to buy another access point.

8:17Instead, I'll just tap into my spares, which we all

8:19agreed in advance what we would purchase.

8:21Now, regardless of whether we do an on-site survey

8:24or predictive survey, either way,

8:26we're going to want to make sure that we

8:27do a post-deployment survey.

8:30Meaning that, once the access points are in place

8:33and the environment is ready to go, before we go live,

8:36we want to do one more survey.

8:38We want to establish one more heat

8:40map that tells us what the actual signal ended up

8:43looking like.

8:44And so we can do a few things here.

8:46First of all, we can make sure that it

8:47did end up being good enough.

8:49And so, hey, yes, we're either good or, hey,

8:51maybe we need another access point somewhere.

8:52Which, once again, is more reason

8:54to have a few spare APs in the deal.

8:56However, the other thing we can do is we can take this back

8:59and look at our methodology for performing the site survey, as

9:02well as possibly the predictive site survey, if that's

9:04what we used, and try to figure out, OK, we

9:06had a few dead spots in here.

9:08What happened?

9:08Oh, we made a bad assumption.

9:10Or maybe the site wasn't as ready as we thought.

9:12And we can take those as lessons learned into the next site

9:14survey that we do.

9:15But ultimately, this part right here,

9:18this post-deployment survey, is going

9:20to tell us whether the wireless environment is

9:22ready for live production traffic

9:25before we actually put that live production traffic in place.

9:28So the goal of the site survey is

9:30that we want to create one of those heat maps,

9:32to help us determine what the wireless coverage is

9:34going to look like as part of our design.

9:36And so ideally, we can get on site

9:39and do a physical site survey.

9:40But that does require that we have access to the site

9:43and it also requires that the site is ready.

9:45And if either of those things isn't in place,

9:47then we can do a predictive site survey as well.

9:50Now, lastly, once the implementation is done,

9:52we should always do a post-deployment survey.

9:54That's going to tell us what the actual environment looks like.

9:57It's good for documentation as well,

9:58in case something changes in the future.

10:00But at the same time, it's going to tell us whether or not

10:02we're ready for live production traffic

10:04to get on here before we actually flip the switch

10:07and put it on there.

10:08I hope this has been informative for you,

10:09and I'd like to thank you for viewing.

0:05We did all of our information gathering.

0:07We've done the site survey.

0:08It is time to create that low-level design.

0:10In this video, we're going to just do

0:12an overview of what this design process looks like so that we

0:14can know what to expect when we start doing wireless designs.

0:18So we have all of the information

0:19that we gathered as part of our prepare and plan phases.

0:22We also performed the site survey.

0:24And so we know all of the RF requirements-- in other words,

0:27the number of access points and where they're going to go.

0:29And so now it's time for us to deliver

0:31the low-level, or detailed, design plan.

0:35This is going to be a set of documentation

0:37that we're going to deliver for the purposes of making

0:39a decision.

0:40This might, by the way, also include

0:42some kind of presentation.

0:43And as I always say, it doesn't matter

0:45whether this is us as IT consultants or us

0:48on an IT team.

0:49Either way, we are typically not the decision makers

0:52if we're also doing the technical design.

0:54If we are, then, hey, this is a cut and dry situation.

0:57I'm just going to approve my own designs.

0:59But chances are, we have other stakeholders

1:01that are going to need to understand this.

1:03And this is why documentation and presentation

1:05are going to be very important.

1:07Now, I know us as engineers, these

1:09are two things that we're not always typically very

1:11comfortable with.

1:12However, I highly encourage everyone

1:15who's watching this to put a little bit of effort

1:17into presentation skills as well as being

1:20able to write well because these are non-technical skills.

1:24These are what we call soft skills that

1:26go a long way towards developing us

1:28towards a lifelong career as a network architect.

1:32It can't always be knowing the technical differences

1:34between wireless LAN controller A

1:36and wireless LAN controller B. If this

1:38is all we end up focusing on as solutions architects,

1:41then we're going to miss a big part of what

1:43it means to be in this role.

1:45Now, fortunately for us, this is not on the exam.

1:48So we don't need to worry about this.

1:50This is just more of something that I encourage us all

1:52to participate in as far as real life is concerned.

1:56So now that we have all this info, what kinds of things

1:58go into our design?

2:00Well, we do need to start with the individual components.

2:03And one of the biggest components

2:05in a Cisco lightweight wireless design

2:08is going to be the wireless LAN controller.

2:10This is huge.

2:11We need to decide, for example, are we deploying a hardware

2:14controller?

2:14Or are we deploying some kind of software controller?

2:17Are we going to go with an embedded wireless

2:18controller for a smaller site?

2:20Are we going to go with the 9800-CL

2:23for deploying into a private or public cloud?

2:25We also need to decide where in the network this is going.

2:29Especially if it's a hardware solution,

2:31this might be going into the distribution

2:33layer or the core layer or possibly the data center.

2:36And we've indicated before that this matters a lot

2:39because if we are tunneling data through the wireless LAN

2:42controller, then our clients are actually

2:45going to show up wherever the wireless LAN controller is.

2:48And if that's inside the data center,

2:49we might have just bypassed firewalls

2:51that were supposed to be inspecting client traffic going

2:54into and out of the data center.

2:56And so let's be very careful if we're

2:58tunneling our data traffic, which in most cases we will be.

3:00We also need to figure out the high-availability portion

3:03of this.

3:04Our wireless LAN controller environment

3:05needs to stay online.

3:06And so are we going to take advantage

3:08of stateful switchover?

3:09Are we going to have redundant wireless LAN controllers

3:11in different locations?

3:12And also, we need to make sure that licensing is all set.

3:16And not just licensing, I suppose, but also sizing.

3:19And that's especially true, once again,

3:20if we're deploying hardware wireless LAN controllers.

3:23Now, naturally, we also need to make

3:25sure we're getting the correct access points in place.

3:27And do we need 6-gigahertz radios?

3:29Is that what we decided as part of our info gathering?

3:33Can we get away with dual 5-gig bands?

3:35And so that might be an option.

3:37Or can we go with single 5-gigahertz radios?

3:40Do we need, by the way, the Cisco RF ASIC?

3:42I would argue in most cases, absolutely.

3:44This is the value of Cisco, and we

3:46want to be leading with this.

3:47However, did we decide that we don't actually

3:50need this in this environment?

3:51Maybe it's a small, medium business type of situation.

3:54Regardless, we need to make sure that we

3:55are meeting the minimum specs for our design.

3:59If we're not meeting the minimum specs,

4:00then this is not a valid design whatsoever.

4:03So let's make sure we're meeting the minimum

4:05and possibly then adding some other maybe optional features

4:09into the mix that could create at least

4:11some conversations around whether or not

4:13that's a good idea.

4:14Now, we've also mentioned a few different times

4:16that we need to consider the switching environment.

4:19And so this isn't just about wireless.

4:21At least in the real world, I don't

4:23expect to be asked a whole lot of questions on the ENWLSD

4:26about the switching infrastructure.

4:28However, in real life we need to ask questions.

4:30For example, does the current switching infrastructure

4:33support multigig?

4:34Does it support the right version of PoE.

4:36In other words, do we have PoE+ on here?

4:39Do we have PoE++?

4:40Do we have Cisco's UPOE?

4:43And so we covered these earlier on in the course as well.

4:45And importantly also, the power budget

4:48because it's one thing to say that we support UPOE.

4:51But if we're deploying a whole lot of UPOE access points,

4:54if each switch only supports a limited power budget,

4:57then we might run out of power really fast.

5:00And then there is the other category,

5:01which is pretty much just everything else that we should

5:04be talking about as part of a design

5:05that we might not actually think about to start with.

5:08For example, do we need to include any copper or fiber

5:11patch cables especially if we're connecting our wireless LAN

5:14controllers into larger switches at 10 gig, 40 gig, even 100

5:18gig, which is supported?

5:20What type of connectivity are we using there?

5:22Furthermore, do we need copper connectivity

5:25to the access points?

5:26A lot of times when we're installing the access

5:28points in the ceiling, the copper run

5:30is going to be terminated into a female connector.

5:32And so we'll need a patch cord to connect our access point in.

5:35And by the way, is that Cat6A?

5:37Is it some other type of connector?

5:39So let's make sure that we've got the right cables there.

5:42Furthermore, by the way, who's pulling all of these runs?

5:45Is that going to be us?

5:46Are we responsible for that?

5:48Or are we hiring somebody to do that?

5:50And so let's just make an assumption there

5:52that those runs are just going to magically show up.

5:54And by the way, if we're doing it,

5:55do we have the tools in order to accomplish this?

5:57Or do we need to go purchase some of these?

5:59And if we have labor involved, whether it's

6:01our own labor or somebody else's labor,

6:03do we have that scope of work document

6:05that's going to define what's being done and what's not?

6:08So if we are a consultant going into a shop,

6:11we probably better create a scope of work

6:13defining what we're doing and what we're not.

6:15And conversely, if we're a Cisco IT shop,

6:17do we have an SOW internally to say how we're doing things

6:21for our own project management?

6:22And do we have an SOW from our consultant

6:24which might be defining for us what

6:26we're expecting them to do?

6:28And so ultimately, what we're going to do

6:30is we're going to create the final design deliverable.

6:32And so for example we're going to have the overall design

6:35document that talks about what we're doing

6:38and why we're doing it.

6:39We're also going to have the associated bills of materials

6:42or possibly quotes depending on the situation.

6:44Either way is fine.

6:45We need to understand what the price is

6:47as well as what we're getting.

6:49That's what the bill of materials would list.

6:51Although, the quote should list that as well.

6:52We also need to make sure that, once again, we've

6:55got the scopes of work in there if we have any of those

6:58as well as just anything else that's

6:59relevant to the overall design.

7:02And so all of this needs to go ultimately

7:04to the decision makers.

7:06Maybe that's our bosses.

7:07Maybe that's a customer.

7:08Maybe that's the team.

7:10Maybe you or me or whoever put this together

7:13is actually going to be part of a committee that

7:15makes this decision.

7:16But in the end, we've got to make sure

7:18that we have everything together so that the right decision

7:20can end up being made as far as the design that we created.

7:24So ideally, at this point, we've done our due diligence.

7:27And hopefully the decision is made to go to implementation.

7:29But we can only control what we can control.

7:31And so that's why we need to make sure

7:32we're controlling all of this, regardless

7:35of what decision is made around the implementation itself.

7:38So as far as this part is concerned,

7:40we want to make sure that we are creating a formal design

7:43document.

7:43That needs to have everything in it that

7:45is justifying the purchase of the solution,

7:48but also making sure that we give the reasons

7:51why we're speccing things out so that if questions are asked

7:53later we can refer back to this document

7:55because we might also forget why we specced out

7:58this particular type of fiber cable or what have you.

8:01And so we're going to assemble all these documents.

8:03The BOM, the quote should have all of the components

8:07in it, whether it's wireless LAN controllers and access

8:09points and switches and cables.

8:11All of these things should be part of the document

8:13that we put together.

8:14And then we're just we're going to hand it over and say,

8:16OK, here you go.

8:17And maybe there's a presentation involved.

8:19Or maybe it's truly just an email or physically

8:22handing things off.

8:23But ultimately, it's up to the decision

8:25makers at that point to read things through and maybe get

8:28back to us with questions.

8:29But ultimately, we respect their decision.

8:31And hey, hopefully, we end up moving on to an implementation.

8:35I hope this has been informative for you,

8:37and I'd like to thank you for viewing.

0:00[LOGO MUSIC]

0:05All right.

0:05Let's take a quiz to see if we can describe

0:07that wireless design process.

0:09First up out of three questions--

0:10starting with "Prepare" at the top,

0:12map the six Cisco lifecycle phases to this diagram.

0:21All right.

0:21So hopefully, we can remember this acronym down here--

0:24PPDIOO.

0:25And then, we just have to keep track of which P is which,

0:28and which O is which.

0:30And so it starts with Prepare, and then it goes to Plan.

0:32And then from there, we go to Design and Implement--

0:35that would be our D and our I--

0:37and then to our two Os.

0:38Well, the first one is going to be Operate, because that just

0:41means that we're operating the network we just installed.

0:43And while we're operating it, we're

0:45going to occasionally move into this Optimization, or Optimize

0:48phase.

0:49That helps us to figure out what we need in order to maybe make

0:53our network better.

0:54And so that'll lead to another Prepare phase, which

0:56leads to another Plan, and ultimately,

0:58another Design that could lead to new implementations.

1:01And so again, the focus here is the fact

1:03that we're always going to be in this lifecycle at some point.

1:06We've never arrived at the end of the network.

1:09Instead, we are going to continually

1:11be going around this cycle, which is just

1:13part of our lives in IT.

1:15Question 2-- what is the best way to ensure we

1:18are seeking the best solution rather than

1:20the one we would rather, or want to, deploy?

1:27All right, so the answer here is going to be C--

1:30asking a lot of questions.

1:32Remember, we want to open our mouths not to talk, but to ask

1:35a lot of questions, and to get the customer, the stakeholder,

1:38whoever is responsible for this decision-- we

1:40want to get them talking so we understand the needs.

1:44The more we can meet the needs of the technical solution,

1:46the more likely it is that our technical solution

1:49will get accepted.

1:50So yeah.

1:50At some point, we might have to defend the benefits

1:52of the Cisco solution.

1:53But that shouldn't be the first thing out of our mouths.

1:56We also don't want to just sell the least expensive solutions.

1:58That's not the point.

1:59Customers aren't always looking for the least expensive

2:02solution.

2:02If that was the case, Cisco would be out of business,

2:05because Cisco is rarely the least expensive solution.

2:07Instead, we need to make sure that we're finding, again,

2:09the right solution that meets the needs.

2:12And opting out of ever selling our favorite access points--

2:14that might just get us into trouble.

2:16We don't want to say, OK, I'm never

2:17going to sell my favorites.

2:19That would be counterproductive.

2:20Instead, let's just make sure that we're

2:22mapping the appropriate solution to the need,

2:24regardless of what that solution ends up being.

2:26All right.

2:27Last question.

2:28What information is needed prior to starting

2:30a pre-installation wireless site survey?

2:38The key here is, what information

2:39is needed prior to starting it?

2:41And it's the fact that this isn't

2:42our post-installation survey.

2:44This is a pre-installation survey.

2:46And so the answer here is going to be B-- whether or not voice

2:49and video or in use.

2:50Because this, as we've mentioned,

2:51is going to affect our received signal strength indicator,

2:54what we consider to be a good value and not a good value.

2:57It's going to affect our cell overlaps.

2:59And it's going to affect of percent of packet loss.

3:03And so if we're doing a wireless site survey

3:05where voice and video aren't going to be in use,

3:07but then we find out later that it will be in use,

3:10that site survey is rendered obsolete.

3:12We're going to have to do it again.

3:14So let's make sure we have that information up front.

3:16As for the rest of these, if we're

3:18planning to reuse existing access point poles,

3:20that can be a beneficial piece of information.

3:23However, we have to be careful about this,

3:24because we don't want this dictating where the access

3:27points will go.

3:27We want the RF signal to be dictating where our APs go.

3:31We'd rather re-pole an access point connector

3:33rather than installing an access point where it doesn't belong.

3:36Now, how many access points will be needed?

3:38Well, this is the point of the site survey.

3:40We're not going to have that information before the survey.

3:42Otherwise, we don't need to perform the survey.

3:44And which wireless LAN controllers are

3:46going to be in use should not actually affect the RF signal.

3:49If anything, which access points would be in use--

3:52that's going to matter, because that might determine whether

3:54we're doing the 2.4-gig band, or the 5-gig band,

3:57or the 6-gigahertz band.

3:59And so this information is good.

4:00However, the wireless LAN controllers--

4:02that's not going to affect our wireless site surveys.

4:04So with that, the quiz is done.

4:05If you found that you didn't quite

4:07survey all of this information appropriately,

4:09then be sure to go back and do that

4:10before moving on to the next skill.

4:12Otherwise, congratulations on completing

4:14Describe the Wireless Design Process.

4:15I hope this has been informative for you,

4:17and I'd like to thank you for viewing.