Exploring Wi-Fi 7 Access Points and Wireless Innovations

My name is Dave Benham. I am a product manager on the Cisco Wireless team. And, uh, I'm gonna talk some highlights of some really cool things we've been doing lately.

Uh, then Mi Kim will come up and dive into some even cooler things in the second half of the presentation. So we're gonna talk about some new aps. We're gonna talk about some test results that, uh, my friend Jim Wick and I did in our RF lab, and any locate, which is our, uh, AP auto location umbrella term, and then, uh, ultra reliable wireless backhaul.

So let's dive right in. At the show, we announced a new, uh, pair of access points. So these are our entry level access points, the CW 91, 72 I and H, and that is the internal Omni and the hospitality or wall plate version.

These are direct replacements for the 91 62. That level of access point. Um, get into some details.

I've highlighted the differences between the two in green on this slide. Uh, the coolest thing about these aps to me is that they are fully functional. The radios are fully functional on 30 watts of power.

So there are some things that shut off. We turn off the USB port on the I, we don't allow POE out on the H because there's no more PO oe to spare. But on 30 watts radio is fully functional.

They are, uh, very capable aps for, for, uh, their size. You can see they are each six spatial streams. And the CW 91 72 I, you can select whether you want tri band or a more robust dual band ap.

So it can be two by two on all three bands, or it can be two by two on two four and four by four on five gigahertz. You have that option. Doesn't have that option on the, uh, hospitality ap.

So to show you a bit more detail on the, the power and what shuts off if you, if you draw the power down, I've created a couple charts. Uh, again, you can see at the, the P OE plus level, the radios are the exact same as the P-U-P-O-E level. So you're able to, uh, get full radio functionality.

Uh, and then it shows the various things that states things as we, uh, draw the power back. Uh, what, what shuts off or degrades. Of course, these aps use our global use AP operation, technology or process, I should say, uh, that we introduced with wifi seven.

We also call it guapo. And what this is, is, ah, yes, yes, naturally the aps are handsome. So, uh, these are, uh, single pit devices.

We don't have a SKU for Europe and a SKU for United States, or a SKU for Meraki mode, and a SKU for catalyst or controller based mode one SKU for all the things. And I will dive into a little bit about what that looks like. So, because we did one sku, there's a process that needs to happen when you power these things on the first time to determine what the heck they are.

What country am I in? What should I be? Am I cloud-based?

Am I controller based? And that process takes a little bit of time to, to go through the first boot, only once the first boot is complete, stays in that mode until you reset it or change it. Um, there's no country code configured by default.

It, it derives that automatically through a whole number of ways, including GPS and neighboring access points, cloud connectivity, et cetera. There are of course, ways to deal with that. If you don't have your completely air gapped, we can absolutely take care of it.

But most customers that will do it automatically, this is what the process. Yeah, go ahead. So, So if you were, for example, wanting to deploy this at a, you would recommend it, you Ship it to yourself centrally configure it, and then ship it to the team?

Or would it be, could you remotely? The best part about it is you have the option to do either, uh, you could stage it and then clear the country code mm-hmm. And ship it to the remote location in another country, and it will rediscover the country code, but save the configuration when it gets there.

Okay. Or you could ship it over there and configure the whole thing. You could use plug and play.

Uh, the beauty of it is it will figure itself out regardless. Uh, you don't generally, uh, want to leave a country code configured and ship it to another country, but we let you just reset only the country code. Oh, or both.

You can reset the config as well. Of course. Cool.

So this is what the process looks like. Just real briefly, uh, you may have seen this slide before, but when it boots, it needs to determine whether it is Meraki or cloud based versus controller based. And that process starts by checking the Meraki cloud, looking for whether it's been claimed in a network, things like that.

If it doesn't see itself in the cloud, it will then start to discover controllers via the existing means. You're familiar with for controller based aps. There's a way to shortcut this as well to, to speed things up.

But, uh, you get that part, it, it figures out it's country code, it figures out its mode day one operation. It stays that way every time you reboot it. It doesn't do that discovery again, it remembers that it has this country code and this mode.

You can convert between the two. You no longer have to open attack case to convert from Meraki back to Catalyst. You can do it either way as many times as you want.

And then of course you can factory reset it. And if you factory reset it, it goes back to the beginning and starts that discovery process again. So I just wanna reiterate, if you do nothing, treat it just like an older access point.

It will function, it will get there. It just takes longer. Might take 15 minutes the first time it boots to figure all this stuff out, and then it will proceed with the normal boot.

But you can use some DHCP option 43 values, new values to kick it one way or the other, whether you want it to be controller or cloud-based. The options are there. I also wanna cover some stress test results.

My friend Jim and I went to Richfield, Ohio and, uh, ran some tests with wifi seven, uh, to see if we could break MLO. Basically we wanted to see what happened when we really loaded some aps down, and if you did things poorly or incorrectly, uh, or if your environment dictates that you have some channel overlap and that sort of thing. So we, we wanted to see how bad we could break it.

Um, this is the, the overlay of the, or the overview of the, uh, test layout. We had 20 Windows laptops in four groups of five, and we were pushing traffic to them with IX chariot. And each of them received two flows.

And I'll give you the aggregate flow, uh, data here in a second. But we were pushing them as hard as we could. These were dual band clients or tri band, but using two bands, five and six gigahertz clients.

And the aps of course were five and six gigahertz as well. They replaced about 15 meters apart through a wall, kind of a typical spacing. And then we also spaced the clients out.

You can see the blue rectangles on the map are the tables. We have the, the laptops on. So the first test is all radios on separate channels.

Basically the correct way to deploy wifi, nothing overlapping. 8 gig of, of average overall throughput. That's the complete amount to all clients.

Now, you might think that seems pretty low for 20 clients when you're at wifi seven, but we were literally doing bidirectional full throttle traffic to 20 clients at once on two aps. I think that's a pretty impressive number considering what was going on. I mean, everything screaming at each other at the same time in both directions.

Uh, latency stayed pretty low, around 65 milliseconds looked really good. So then we started to break things in various ways. We put the five gigahertz radios on the same channel with the same primaries, right?

Uh, not ideal, right? Uh, you can see that the throughput didn't change a whole lot. The latency just about doubled, but the throughput is still pretty good.

Most of the data is happening on six gigahertz in this, I mean, in this demo that's, clients seem to prefer six gigahertz for high throughput stuff. Uh, so it didn't affect it a whole lot. So we decided to keep breaking stuff.

Then we flipped the primary. So same channel, but on different primaries. So the aps can't really see each other, they can't coordinate back off anything.

They're just stepping on each other. That hurt it really bad. 2 gig and almost 400 milliseconds of latency.

So big difference there when, when you have a full conflict on five gig. And we decided to play with the six gigahertz side. So we put five gigahertz back on separate channels the way it should be.

And we split six gigahertz. You can see throughput came up a little bit. Latency got a little bit better, but it's still pretty rough.

And that's interesting, uh, because five gigahertz, when we put them on the same channel, it was still pretty good. So thinking maybe management traffic might be on one band versus data on the other, that sort of thing. Every client behaves a little bit differently, but this is just some food for thought, uh, from was mimicking a, a, an actual deployment.

So lastly, we put five gig on separate channels again, and we misalign the six gig primary. So this is the worst case scenario for six gigahertz. Uh, same channel, but different primaries.

6, but the latency got even worse, almost 600 milliseconds of latency. So just wanted to share some scenarios. Uh, it's not often that any of us are able to really sit down and kinda lab test to compare, uh, results from one to another with, with consistent surroundings.

So it was fun. Wanted to make sure to, uh, to show it. Now I wanna talk about any locate and, uh, I've, I've spoke about this before at field days, but I wanna give you kind of a high level of what it is and talk about the cool stuff we're doing.

So any locate is an umbrella term for our advanced location technologies, as well as the AP auto locate function that we have. And what it boils down to is the accuracy of AP positions on maps is the fundamental basis for all things location services. If your aps aren't placed properly on maps, you don't get good location accuracy, period.

Nothing will fix your accuracy if your aps are not well placed. So the AP auto locate function will auto place APS on maps. We've been doing this for a couple years now.

Works pretty well. We, we've been doing it with fine timing measurement on the wifi radios. And it measures the inter AP distance with FTM between the aps and then computes kind of a matrix of, uh, locations of aps And the heat map.

I'm sorry, and the Heat map also. Yeah, the, yeah, the heat map can, can benefit from it as well. Um, primarily we're trying to figure out exactly where the aps are.

If you rely on heat maps to show your RF coverage, they'll of course be more accurate as well. We also offer this same technology for client location. So you can do FTM with clients, but we wanted to step it up, take it to the next level with ultra wideband.

So we have ultra wideband radios integrated into our 91 76 and our 91 78. And that's my feeble attempt at an X-ray animation. So you may not be familiar with ultra wideband because it has nothing to do with wifi, but it's a short range, high frequency technology.

It exists in iPhones and other Android phones for searching for tags and things. You've probably seen it, it's very, very accurate. Submeter accuracy, way less than submeter in a lot of cases.

Um, and we we're integrating it to kind of make the existing use cases better and explore new use cases as well. So the first use case is that it enhances AP auto locate that we just talked, talked about. We're offering this technology between aps.

So we're combining the results from FTM, which were already pretty good, and also using UWB to get that submeter accuracy. So it has made a substantial improvement in the location accuracy, aps, that there's that area of certainty or uncertainty that you see sometimes when you're looking at the GPS on your phone. You're in a basement, it'll be very big shrink down.

That area gets smaller with, uh, with these, these technologies combined. This is an example of what it might look like for, uh, AP accuracy with FTM alone. So these circles are not coverage areas, these are areas of certainty for, for the location.

Uh, pretty large circles kind of shifted around, and this is, the AP would be in the center of the circle, but I'm trying to depict the difference. Um, this is what it looks like with ultra wideband. So much, much smaller circle, much more accurate consistent results.

We're seeing about 95% results better than two meters accuracy and quite a bit better than one meter accuracy as well. And that's a big improvement from FTM and pull me offline. I'd be happy to share, uh, some more details on it.

I also want to do a bit of a public service announcement because I get this question a lot for our AP auto locate. You can absolutely preview before committing. You do not have to accept the results, so don't, I guess don't be scared to run AP Auto.

It isn't going to ruin your existing map or AP locations. You can simply run it and it will preview the data and then you can say, yes, I'll save it or cancel it. And this is an all three platforms.

So it's in beta right now in Catalyst Center, but it's public on Meraki as well as spaces. So all three give you the ability to preview before commit. So don't be afraid to, to test it out.

These are the platforms and access points that are supported. I won't read through all of them, but it's supported on a lot of aps going back a few generations. Uh, and like I mentioned, all of our platforms, if you want to test it on Catalyst Center, please reach out to me and I can turn it on.

It's a controlled beta at the moment, but I can absolutely turn it on for anyone that wants to test it. So the last topic I wanna talk about is UR WB or ultra reliable wireless backhaul. If you ever wished that wireless could just be better, essentially lower latency, less loss during roaming, uh, more resilient, more redundant, et cetera.

You can't do that with wifi alone today. We're working on it, but you can't get there completely with just wifi. There are some fundamental challenges with the way that wifi works.

For example, the break before make nature of the Rome, it has to disconnect from the current AP before it connects to the next ap. You're going to get packet loss in that scenario, just naturally. That's how it works.

Depending on what you're doing, that may or may not affect the application, but you'll get some packet loss and you can only connect to one AP at a time. Of course, that's what we're used to. So that means can, can't really be redundant.

Now, MLO helps with that. You can do two connections or three connections to the same ap potentially different clients handle that differently, but it's not a true redundant solution. Now, some of the upcoming wireless standards may address this, when though probably not the initial release.

Uh, things are improving, but at a slower rate. And these are real problems that need to be solved today, and we can solve them. So we solve them with ultra reliable wireless backhaul, which has been around for a while now.

We've, uh, five years since we acquired fluid mesh. The technology has been there, but it has always been kind of a separate thing. Uh, it's a point, point to point supports, point to point, point to multipoint, mesh, mobile, all the things, uh, that you would expect for wireless backhaul to, to, uh, work.

Um, and clients connect through a Cisco ap. So think of it like a, on a fork truck in a warehouse or an A GV in a, in a manufacturing facility. There'd be a, like a 91 65 or some small Cisco AP on that acting as sort of a work group bridge with familiar terms to us if it would connect to URWB.

And the primary benefits of URWB over wifi are that it is zero loss roaming true, zero loss roaming, no packets lost. Uh, the latency is better because the backend is different. This is non wifi.

Uh, it, it operates on 8 0 2 11 5, but the, the whole communication's non wifi and, uh, multipath allows a device to connect to multiple aps at the same time, redundantly and send the same traffic to places. And it gets joined on the backend. So if anything fails, you don't lose a frame.

Now, that's not the way it's typically deployed, but if you have that need, it absolutely supports it. You can even have two aps on the vehicle connecting to two aps on the infrastructure. Completely redundant from end-to-end, separate power, everything if you want to.

How many paths are supported? Two, two paths. Yeah.

Yeah, two paths. So up until now, this has always been a separate infrastructure. Like I mentioned, you had to deploy different aps in this mode.

Uh, it's, it's been completely separate. Some of the use cases are manufacturing AGVs, like I mentioned, uh, mining real fast, moving things like, uh, high speed trains, et cetera. And a typical design would've been 91 60 sevens on the ceiling and 91 60 fives on the vehicles.

That's, that's kind of the most common way to deploy it. And you're probably thinking, why are we talking about this if we've been doing it for five years? And the reason is because we now offer it integrated into our, our aps at the same time as wifi.

So you can choose one radio and put it in UR WB mode and have the rest of them doing wifi. So if you have a dual five gig ap, one of the five gigs in curb, one of the five in wifi, and you lose nothing on the wifi side, you don't need to dual boot. It's the same image for both in the WLC, all the same.

And, uh, it can be enabled per, per radio or via a radio profile in the 9,800. And even the vehicle end of it is managed in the w. That's an ask that some of our work groupage customers have had for a decade at this point, is that they want that mobile end to be manageable.

And now it is in the WLC and other platforms to come. We are still offering the traditional way if you want to deploy this without a WLC or without the rest of the enterprise wifi infrastructure. Uh, but the cool thing we're talking about is joining it today.

And this is an example of what it might look like on a, on an AP split up the radios, one of the fives with URWB and one with wifi. So you can service wifi clients and curb clients or curb devices at the same time. These are the aps we are planning to support.

This may change, but this is the, the current planned list of supporting this, uh, mid, mid ish of this year. Uh, there's a lot of aps on this list. Again, just like with the, uh, AP auto locate, we went back quite a ways, few generations of aps to, to support this.

Uh, and there's a, a wide breadth of access points, uh, as well. Different styles, different use case aps. I wanna show you a video demo, a short video demo of what this technology can do.

This is the demo environment. I won't go through it in detail, but we have basically a vehicle with 2 91 60 fives on it. One of them is connected via wifi, and one of them is connected via URWB.

Those 91 60 fives have raspberry PIs behind them that are generating traffic. We, we did some stuff in Python, made a UDP traffic flow scenario so that we could very accurately show packet loss latency, et cetera. Uh, they're connecting to 91 70 eights on the ceiling and back to A WLC and a 91 67 as the traffic concentrator for the URWB pretty standard lab set up.

But, uh, let's get to the video. So the way that we are instrumenting this, uh, of course I love Grafana, you guys know, so I threw some stats in Grafana. Uh, the left half of this is URWB, the right half is wifi.

And we've got on the top chart the, uh, latency, both immediate and average. And then on the bottom chart, we have jitter the difference in latency from the last frame as well as packet loss. And this will, this is live data.

When we start the video, you'll see that, uh, that it's changing. And then along the top, I have some tiles that identify the state or the health of things, uh, in focus on the packet loss one, because that's what is, is going to be interesting for, uh, for this time through. Uh, and then we've got some stats in the middle center at the top there.

That's a three minute comparison showing the health of the connections between each other. So let me start with the video. That's the hallway 91 78 access point.

And, uh, that's my buddy Chris Williams that is, uh, pushing a vehicle around in our office. We've got URWB on one side and, uh, wifi on the other. So moving along, it's gonna roam here shortly.

If you pay attention to where it says hallway CW 91 78 on both sides, that's the currently connected access point, and that's gonna change real soon for both of them. And on the left side for curb, just roamed, nothing changed, no packet loss. Latency didn't change.

It was like it never happened. It roamed between the right side also is roaming. Now it, you'll see the AP change momentarily, but it lost 51 packets.

Now these packets are UDP frames being sent every 50 milliseconds. So it's an extreme test. You wouldn't see 51 pings drop via a simple wifi roam.

But, uh, we're trying to show you basically how long the outage is as it roams. And this is 11 R by the way. This is not, uh, artificially trying to make wifi look worse.

We gave it the best scenario on both sides. Uh, so we keep moving back and forth. You see another Rome there.

More packet loss on wifi, nothing on URWB. Uh, this continues on for a bit back and forth. And trust me, there's never any packet loss on the URWB side.

Uh, yeah, it's a, it's impressive to see the difference between the two when you're really looking at something like a streaming video or anything where data is, is sensitive to packet loss. So that is all I had. I'm gonna turn it over to Min se Kim, that's gonna dive, he's gonna dive into some, uh, awesome things that we've been working on.

Alright, can you go min mm-hmm. Thank you. Thank you, Dave.

I'm hoping to have Dell wifi as my home wifi. Isn't that great? Yeah.

So, uh, today I brought couple of AI iteration that we have done lately from the last tech field day to, uh, to, to, uh, February. And then, uh, we indeed, we made a couple of, uh, I mean, emerging progression such as the, uh, generic availability of interest capture. I've been presenting a couple times, but it was all about beta lab, POC, and now it's a fully functional, available to everybody.

I'll talk about that. Uh, we'll also talk about some of the, uh, monitoring and visibility improvement for the infrastructure. That's something that the, uh, Meraki user has not been fully appreciated on the, uh, some of the abstraction that we have done in the Meraki dashboard.

Sometime, like if you don't see a light, then uh, everything is green, right? So while we decided to expose everything, what's coming under the hood, under the scene, so now you have a full transparency of the device monitoring in the, in this case infrastructure. Third case that I want to cover is the, uh, the AI RM that what happened from past, especially from the, uh, the efficacy of the AI RRM, which it hasn't been covered in the prior topic.

So let's start from the in terms capture. So what it is and what we're trying to do. So let's assume the, some of the day-to-day operation.

And, uh, we all probably know that only time that the, uh, net or domain is trying to take a look on the wifi dashboard is, uh, some of the VP and the VIP is, uh, having a bad day in the morning. So, uh, it always reported in the, uh, delayed fashion. Hey, I have some bad things happen.

My WebEx, my, uh, my zoom, my meeting with my board members investor went south. Hey, check out what's happened in Amsterdam, right? So then the guy sitting in the, uh, maybe France or other theater, other continent found that there's a no expert in country level.

So, okay, what to do next, right? Okay. And, uh, looks like this is not the first time happened few times, but I really couldn't do, uh, much properly.

And then I still have to figure it out whether it is a network issue or client issue, basic one-on-one of the wifi troubleshooting. So let's get some K capture, right? This is a natural progression next step.

So, uh, to get a packet, capture what we have to do, let's start from the, uh, let's just bring my old LP cap card and try to get somehow, uh, hook up my wire shock. And then I suddenly bump into a couple of interesting challenges here, right? First of all, I need to know that which AP was serving that client and what was the channel for that part.

I need to know that which specific five gig channel they have to looking into. And obviously we are living in the high density world. There's a multiple AP multiple channel.

So there, okay, yeah, probably we have to use a channel bonding up to three, then realize that these packages are all encrypted. I mean, problem was, uh, my WebEx meeting problem. It wasn't really clear that it was a connectivity problem or application problem, but data is encrypted anyway.

So probably have to take the multiple package capture from the wired and wireless, right? 5 because of that. We enable it, especially with a six gig, right?

456 MLO, right? Dependent. PK dependent troubleshooting is a new norm with wifi seven.

How we are going to troubleshoot that. How are we going to take a package capture, right? This is super challenging.

I at the moment with a third party tool, we probably need to figure out what to do, right? What about the, uh, using AP as a packet capture devices, given that this is remote environment, I don't have anyone on site with a packet capture tool. So, uh, let's convert AP into ThreeForm mode, pro mucus mode, which is pretty much what we can do today.

But if we do that, what we found is, uh, is all about rx. I can't really correlate with a specific failure event with a P cap. Probably I need to use my own brain to make some chronological correlation.

I need some expert to look at that, right? What about the, uh, package itself? Can you get every packet?

Sometime it doesn't, right? Uh, three promote AP is sitting on the other side of the corner while the failure is happening the other end, right? So there's a distance limitation and sometime I need to get the boost wired and wireless, which is impossible to get the wired because of the packet failure happen on the one ap while the pro mode AP is sitting on the other side.

We can't get the wired and wireless package capture either. What about the, uh, dashboard? It looks like, uh, many vendors are kind of approaching, Hey, I have this amazing dashboard tool that you can, I mean, easily trigger and package captures and do that lot of things.

Looks like a great idea. But the, uh, what has been the, I mean, existing tools experience that the network vendors offered, there was some debate of whether we should store the P cap historically or not, especially important in Europe. All this, uh, privacy matter, but that's probably more compliance, not a real technology limit.

But sometime I do not get the full packet because of the packet capture through the dashboard. It take a lot of, uh, backend complexity. Sometimes that many vendors and implementation do not have a full data.

So in the Cisco cases, when you designed the interest capture first in the in catalyst center four, five years ago, we had to build a special mode called the full data packet capture. Because regular mode, we won't be able to get the full data packet. And sometime packet comes in a different order.

If I get the management frame data frame, let's say that you have, uh, I mean the block, the cast and ba in out of order fashion, entire packet is no use, right? You have to get the proper timestamp. And this is a little bit interesting topic.

I will explain later why this become one of the most common discovered scenario. Especi, when to try to capture from the dashboard size limit, wifi, seven ml at least. Uh, this one seems to be most advanced topic because of a lot of vendor try to monetize by adding additional functionality, but it doesn't come without their own caveat.

So let's come back with, uh, uh, traditional scenario. So this, this is a traditional inline package capture. So inline means that we are capturing from the data plane of the ap, which is great.

We can get all the data. Decrypted nice, looks like it working fine. But there's one caveat because of the, uh, in the design and architecture of ap, there's a two split head.

There's a data plane site, main os you can imagine the host, A-P-D-W-P-A, those things are all sit on here, but there is a wifi modem does all this low. And, uh, I mean low layer operation pcon proving control frame all happened, generated by modem. It never go back to data fledge.

So if you try to take a package capture often, then you miss this whole piece. And then you ended up, you only got partial packet capture. And this is a big problem in the wifi seven because of the more and more devices are relying on the, uh, the, the control frame, action frame, imagine that you are troubleshooting arrow star 11 U, which is using a and QP action frame, which all entirely generate from the AP modem, not on the main os.

So all these problems comes into the way that our package capture has been partially useful but not fully functional. What about the, uh, promus mode pro also promus mode seems like a answer for many cases because I don't need to worry about like a missing packet. Partial packet, but at the same time, it's just RX only.

There's no tx. So I only can approach it from the third party view. It's, uh, not too different from the, uh, just having a A LP cap, uh, adapter onsite.

But other than that, I still have to deal with all the problem that I had in the third party tool. So how we can solve this problem, how can move forward, right? That's why the interest capture comes in.

I think I've shown this, the slide. So, uh, I think that really the visualization, let's move on. I did that.

The key point is the internal architecture, how we made that happen, how Cisco was able to solve all this problem. To be honest, in a couple of pages that when I list out the challenge, it was only partial. It took like, it took me a 10 minute to list down all the problem that we have.

'cause there's so many limitations that we have in today's packet capture system. So what we have done at this time is we designed the entire packet capture from ground up at the, uh, AP and hardware level. So first of all, when you get the, uh, when you get the packet capture, the wifi model itself always replicate the exact outbound, the over the air traffic to the packet capture module.

So it happen all the time. So every time we take a packet capture, that's why we are able to get the probing and the, the, uh, the, the control frame and, uh, the b cutting all the time because we are replicating all the time. And then, uh, of course the data being comes in, in order.

And now the interesting part is how we can make this scalable because simply amount of the management frame and all the data trap can be overwhelmed. That's why we are able to increase or design the special buffer. So, uh, Cisco's, in terms of the capture buffer, what unique about it is we have, uh, the, uh, end number of the link buffer n be equal to client count, and how many client we can support for single AP 1,200 of humongous number of concurrent client support.

And then we have a 1,200 ring buffer. So thanks to new AP wifi 60 and seven, we just able to get so much of, uh, hardware capacity and now the, even the intrinsic functionality is fully leveraging, uh, these, uh, inherit hardware strengths into the product and put together as a solution. And, uh, what it does as a end result, I can get a full packet anytime, every time.

And we don't even even need to do any of the prep work because the system will always automatically capture store and upload to the cloud. So there are a lot more exciting architecture from the behind the scenes is the cloud layer. But I didn't go that too much because, uh, it might be most interesting, but I probably wouldn't cover any second topic.

So I'll just, uh, stop that. And then, uh, this is what we have added from the last time. Uh, we didn't show the, uh, the packet analyzer, uh, back in the, uh, last time.

So now we have a packet analyzer embedded extended with a wifi protocol. So, uh, our approach that we took was, uh, because we are gathering the millions and millions of file every day, the, we were able to kind of sorting top 10 failure cases and e in each top 10 cases, we were able to build a special parcel and the user was able to easily identify which package is the source of the problem, what course, and why it goes, and all these things available from dashboard with just one click. I have A question on the previous slides.

Yep. You are copying a wireshark effectively to the cloud. Yep.

Is that could have privacy data from customers that didn't agree to that. Yes. That's a potential data leak of sensitive data.

Yes. So, uh, that's why that this functionality, when you ship it, we ship it in disabled fashion. So there was a customer's comment on the community page, American community that why you guys are enabled by default, if this is so useful, you shouldn't enable in the disabled by default.

That was one of concern. I need to have a split end user consent to enable it. And then, and another part is, uh, we are developing the new mechanism of a store, the packet in their own local private accessory bucket, what we call the BYOB, bring your own bucket.

So bring your own bucket. I think the same question was made by the, uh, the, the SAM the other day. We haven't built that yet, but that's a part of the current r already to plan.

And, uh, probably this summer next tech field day, we'll be able to update the more, uh, BIOB plan. Yep. Thank you.

All right, let's get into kick demo. I have one last question for the last thing. Yeah.

Let's say I have a problem with roaming and clients moving. So I could file this up not for single ap. I could file this up for the Absolutely.

Let's all Cisco life. Yeah, Absolutely. Whole Cisco, All the aps.

Do we have then a comparison function as well where I can, let's say follow the client moving from different, uh mm-hmm. Points? So, uh, right now they, when client fail to Rome, we actually capture package from two different ap and then, uh, the first AP room from AP send a packet to their room two ap.

So, uh, when the packet gets sent to a cloud, it just sent as a one packet. So, uh, you, you don't need to kind of, uh, stitch the two different PA and try to Okay. Where the, from what or which AP to which ap, you don't need to worry about it.

Single PA failures with the roaming failure will have a voice. Okay. Yeah.

And according to that, because this is troubleshooting mm-hmm. Uh, when you have wifi problems mm-hmm. And I want to go, uh, a step before that mm-hmm.

To show more client analytics mm-hmm. Out of the, uh, node itself. Mm.

Mm-hmm. Mm-hmm. Um, is there an upgrade?

Yep. So, uh, that's what we call as a single client troubleshooting workflow, which you're actively working on. In fact, I have some slide, maybe the, uh, Tony is a PM for that project, single client experiences.

So we'll be able to, Tony will be able to show it next time, negative tech field day, which actually combine the wireless and wired, uh, all put together in the historical manner. So what I'm saying is, if you look at the traditional timeline of a Meraki, right, it only show one aspect, which is a wireless timeline. It doesn't show any wire timeline.

It doesn't show me any correlation with the switch capabilities or when failures or application problem. And I have to have it with the contextual manner in the chronological owner, right? I need to go back to yesterday, go back to last week and see what happened on that particular moment with the twich and application.

That's all putting together. And that will replace the current 360 pages of the Meraki and that will be brand new. Yes.

Tony? No, five minutes. Okay.

Okay. Plus, um, I mean you are doing a great job, uh, with, with with great state of the art access points and, and, and hardware. But clients rule wifi world, right?

Correct. And troubleshooting. Yep.

Wifi is going from down to top. Yep. So you need more information, more client analytics to do better troubleshooting out of taking a a hundred Percent sure.

A hundred percent. I think you are setting the stages for, for me, in fact, Cisco is only vendor who is getting gathering or actually getting, because they're sending us the property information of the client connection failure from their applicant directly over the L two from their each modem, each client to the Cisco ap. The vendor who agreed to sending and actually sending to us right now is Apple.

All the Apple devices, io, Mac, iPad, everything. Every Samsung devices, all the ac I mean the, the, the what's they're all sending the property. So error code to Cisco, AP and the Zebra, we are sending Intel, they're sending it.

The only thing is, hey, why you demoing us? We actually have it already in the DNA center. I probably would have shown it this time, but it just been available for quite some time.

Yeah. Maybe, Maybe more extra information out of the client before we go troubleshooting And Sure. Capture.

Yeah. Yeah, absolutely. I took a note and uh, actually that's indeed one of the project I'm working on.

So, uh, looking forward to, uh, so meet you again now, next time hopefully. Yep. That what we call the client analytic project and uh, there's some, some big things actually happening right now.

Uh, alright. Uh, Teo, I got only five minutes. Well, let me go real, real quick 'cause I have a lot to cover today.

Let's get into, uh, in terms of capture here. So a typical client overview pages, and I know that the, how to get into detail. There's some failures going on, authentication failures.

So, uh, let's get into the, any of, uh, let's say the temporarily refusal, which is, uh, super difficult to troubleshoot it in the most of cases, right? And then, uh, in such cases a device had been, uh, disconnected by AP a few times and let's find out what happened. Go to timeline and just filter with the packet capture.

Yeah, well, you have a package, right? Instead that the client failed during the association. And then here, just click the view packet capture.

Then now you have a familiar wire shot view, and then, uh, it also pre-filtered with, uh, colored with a proper, I mean the, the filtering, right? We have, uh, e messagings going on. So it seems like, uh, overall looking okay, but, uh, there is a, there is a des sensation happen from the client, uh, so I mean from the ap.

And the AP was not able to handle this client connection properly. So then that's why we have a package captures enabled with the timeline. So now we can work with a device maker to, uh, continue further default that why we are getting these messages.

But in these cases, it is happened once out of the thousands of authentication cases, but probably not so much of, uh, I mean the supportable imaging. But the, uh, when you have a three second of disconnection for certain unplanned time, now you have a full data to, uh, looking into and deep down, uh, delving into further. That's the key idea here.

Uh, let me get into our next topic here. I, I know that I'm kind of a launching here, but a lot to cover. Uh, I want to start with the basic, sometimes the Cisco saying that, uh, the, I mean the simplicity is a really rule, but no, I need to have every single bit of information.

'cause that's the whole point of assurance, right? And, uh, 99% of time, I don't need to look at this, but when things go south, when AP suddenly got rebooted, I need to know why AP got rebooted. How was or why was there any mely happen?

Was there any CP Hogan process happened? What is my, uh, device, the trending view of, uh, reviewing and uptime condition? Device uptime is a number one request the feature by every customer, and we are providing an additional context of the reboot reason.

So none of this has been available from Meraki the past few years. And, uh, I, we realized that every enterprise require this type of information as the most basic found foundation info. And now everything is available, customer can build their own dashboard, uh, using the API American Grand Funnel support that, uh, yeah.

Let me, uh, just kick, let me, let me cover one, just one last topic because my time is up. I will just cover one part. We got, we got a lot of these things going on, but I'll skip that.

I will, I'll just want to cover one thing. The whole A IRM story. I mean, we've been heard enough, right?

Okay. I mean, yeah, it's good. So what, how much is good?

How you can convince me, right? All these things look at slide. Well, so, uh, what we have done was, uh, building the A IRM into the measurable, I mean the statistic, any success has to be measurable, right?

So, uh, what is my wifi performance look like? How's my wifi, uh, score look like, which was done by Javier as in 2018. We use the same algorithm.

Now we can see a before afterword view of the how my network behave, how's my channel changes, channel optin, the, become a big source of the, the on unplanned disconnection. And now the channel change is being measured, monitored. And now see that how channel changes, um, contained after A IRM, what is my coch channel interference, which is number one reason of the bad wifi.

And now I can see, uh, my cross-channel interference trend, uh, before afterward. Not only that, we can compare it with, uh, global I manufac fashion. So what this actually measured with the PO with a very cherry picked, the, the, it's not done by the industry.

We are cherry picked by network density. We have a metric called the network density metric. So NDM.

And we took the same NDM and based on the similarly, I mean distributed ap, we know that which, uh, house might network behave compared to the similarly dense AP in the same, uh, trim metric. It, It's all about rf. Yes, but, but, uh, these are RRRM insights.

What about ar m in insights? Ai, A-R-M-A-R-M, adaptive Radio Metric, ah, Ah-ha, aha. Adaptive radiometric.

So, uh, we are working on the building, the RF Health Metric as a separate dashboard. And then, uh, right now RF Health Dashboard is a schedule in the coming months, not this time. So, uh, stay tuned and we'll be able to update there on the next technical day.

Update.