Get the Most Out of Your Low-Power Wi-Fi Devices

So today we're going to talk about Wi-Fi in connected, responsive, and efficient. 
  
So really what we're talking here is about low power Wi-Fi. 
  
And so I'll jump into this, but before I do, I did want to introduce Vaseem. 
  
Vaseem is a staff product manager here in our Wi-Fi group. 
  
So he's really responsible for both hardware and software for Wi-Fi. 
  
If you're familiar with our SIWX917 product, he's responsible for that as well as future roadmap products. 
  
So he's a great resource to have on this. 
  
I'm really looking forward to hearing him on some of this stuff we're doing on Wi-Fi. 
  
So as we do that, if we look at the agenda that we're going to do today, we're going to be looking at really why do you need low power Wi-Fi, and a little bit about what low power Wi-Fi is. 
  
We're going to talk about the Wi-Fi specification and low power improvements, talk a little bit about designing for low power Wi-Fi, because there is some things you have to consider and some things you need to do a little bit differently than standard Wi-Fi. 
  
We'll do a quick conclusions and key takeaways, and then we'll have Q&A. 
  
So as a reminder during this, if you have any questions, use the Q&A feature in Zoom. 
  
Bring that up, go ahead and put those questions in. 
  
Some of them we can answer directly in the Q&A. 
  
Others we'll leave and answer at the end during our Q&A session. 
  
I expect us to have 15 to 20 minutes at the end to do that. 
  
So with that, let's jump in and really talk about why low power Wi-Fi. 
  
So, we've been hearing about low power Wi-Fi for really over a decade. 
  
But really, what does that mean? 
  
I think one of the things we think about, even when we say low power Wi-Fi, it's still orders of magnitude more power than other technologies out there that we see. 
  
Things like Bluetooth or 802.15.4, which can include Zigbee, Thread, and even Matter over Thread. 
  
So, it is much higher power consumption than those, but Wi-Fi really offers unique benefits over those other technologies that makes it applicable for this low power. 
  
Obviously, one of the biggest ones you have is just the availability of Wi-Fi. 
  
If you look it up, they say basically in what they consider developed countries, that greater than 90% of homes have Wi-Fi connectivity. 
  
So what that means is there's no need to have a separate gateway or hub that would be required for, example, Zigbee or Matter over Thread, where you need an OTBR. 
  
You have that native cloud connectivity. 
  
And that really simplifies things for the users. 
  
If you're developing product, you know pretty reliable that if they have Wi-Fi, if you sell a Wi-Fi enabled product, it's going to easily connect into the home. 
  
That's not the case if you have something like Zigbee. 
  
For Zigbee, most likely, they're going to need a separate hub, whether you provide the hub or it's functionality that's included maybe through an Amazon Echo or something like that, but it's not guaranteed. 
  
And then, of course, there are some other advantages to Wi-Fi, mainly around higher throughput. 
  
So there is actually applications that you can do that cannot be done with these lower power or lower throughput technologies like Bluetooth, Zigbee, et cetera. 
  
So, if you're doing things like video streaming, large data transfers, or more real-time applications, Wi-Fi is what you're going to need to do that. 
  
And then, of course, there's other things that even though it's higher current consumption overall, it does have a lower energy per bit. 
  
Now, if I'm transferring lots of data, maybe I'm doing an over-the-air update, that's efficient. 
  
But however, the downside is if I'm just sending a simple command, like an on command or an off command, it's not efficient for small payloads because there's so much overhead. 
  
So all of this has to be taken in consideration when you're saying, "Is Wi-Fi the right technology for my low power application?" And then, of course, many applications require low power Wi-Fi. 
  
And what I mean by that is low power Wi-Fi is more than just running on batteries. 
  
Obviously, battery powered is a big percentage of that. 
  
It addresses a lot of applications, but you also have power-constrained applications. 
  
So let me talk a little bit about those. 
  
So obviously from battery powered, typically we'll see things that in a IoT home environment or an IoT environment, you're going to be running off of coin cells. 
  
These are very low capacity devices. 
  
Wi-Fi may not be applicable for that just because of the current consumption that's required. 
  
These may be very small sensors, et cetera. 
  
But we also see applications that run off of multiple primary cells like alkaline. 
  
And in those applications, Wi-Fi is definitely applicable, but you need low power Wi-Fi. 
  
For example, locks that you would see, Wi-Fi enabled locks. 
  
They typically run on four AA batteries. 
  
And there's a lot of other things happening with those, with current consumptions, operating the lock mechanism. 
  
But several years ago, if you looked at one of those, you may be getting six months of battery life out of that. 
  
Now with devices like we have and low power, we're seeing 18 months of battery life very common in that application. 
  
And of course, you have rechargeable batteries, and those are a little bit more flexible because these have to be recharged. 
  
And again, battery capacity and size depends on the application. 
  
If I'm in a wearable device, then I have a very small battery. My current or my amount of current I can draw is lower, but I'm recharging that more often. 
  
In applications like battery-powered video cameras, whether it be a game cam or something like that, you can have a much larger battery. 
  
They still have to be recharged, but they do have a longer battery life between recharges. 
  
But beyond batteries, what you have is really power-constrained devices as well. 
  
And we're seeing a lot of applications for that. 
  
So in the US, we have a neutral wire that typically comes to things like switches. 
  
And what that means is that neutral wire is not used in that switch. 
  
In that switch, I'm cutting line and load. 
  
The problem with that is if I have a smart device, typically, I need the neutral connection to power my smart device. 
  
But you can do a no neutral smart device where you actually are pulling power from that line load and from the light that's on that. 
  
But you're very limited on how much power you could draw, because if I draw too much power, I'm going to get flicker in that LED bulb. 
  
So you do need low-power Wi-Fi for applications like that. 
  
Also in thermostats, some thermostats don't have that common wire that provides voltage. 
  
So in those scenarios, you're stealing voltage off the other lines, but you are very limited on how much you could draw. 
  
So typically, you're stealing to charge either a rechargeable battery or a cap. 
  
And then when you need that higher current for things like receive or transmit, you could use that source and then trickle charge. 
  
And that sort of gets into the same thing on this low current budget or vampire current. 
  
A great application or great example, in the US, again, we have something called Title 24, which this limits how much current a bulb can draw when it's in the off state. 
  
The problem on a smart bulb, if it's in that off state, I still have to have my connectivity active. 
  
So my Wi-Fi has to be active. 
  
So I have to fall below a certain threshold during that off time and still be able to have that connection. 
  
So things like that become important for these, what I'm going to call power constraint devices. 
  
So what are some of the devices and modes that we're looking at? 
  
Obviously, depending on the device, there's different modes of operation. 
  
For example, with smart locks, again, these run on typically primary cell batteries. 
  
But these are what I'm going to call an actuator. 
  
What I mean by that is it is a device that has to respond in a certain amount of time. 
  
So it has to wake up and poll that access point. 
  
Do you have a message for me? 
  
For example, if somebody remotely through Wi-Fi in the house, say they want to lock the door or unlock the door, they don't want to wait around 10 seconds. 
  
So typically, that's a three to five second response they need. 
  
So that is a different use case in that versus where I may have a wireless sensor. 
  
In a wireless sensor, I'm not typically polling that wireless sensor for it to do something. 
  
What I'm doing is getting reports from it. 
  
So maybe that sensor is giving me a heartbeat every 30 seconds or 10 seconds or maybe even longer. 
  
But what it does need to do is wake up and then be able to report on an event. 
  
But latency is not critical there. 
  
And in these environments, throughput is typically pretty low, and it may not even support a firmware update just because of the smaller size and the battery. 
  
Where if you look at other things like locks, typically, again, for a lock command, you have a very low throughput, but there also may be a requirement for that higher throughput when I'm doing an over-the-air update. 
  
Same thing, similar with smart thermostats. 
  
These are really actuators. 
  
Again, they could be mains power, they could be primary cells, rechargeable, lot of flexibility on how they're powered, but they do need to respond fairly quickly. 
  
Not within 100 milliseconds or even in a second, because if I'm sending a command, for example, to adjust a thermostat, I'm usually not there, so I don't need to see an immediate adjustment. 
  
There's not a visual that, hey, it just changed. 
  
So those can be a little bit longer in how quickly they respond, but they still are actuators. 
  
They still need to respond to a message. 
  
And then, of course, things like wearable devices are a little bit different because really, they're sort of more on-demand, but when you are active, you actually have a very high throughput typically. 
  
So these are rechargeable devices that last days or weeks. 
  
They may be off for a period of time. 
  
For example, maybe I go in and I turn Wi-Fi off completely, but when I want to use it, it needs to be on and active. 
  
In similar mode with medical devices. 
  
Here, I'm talking more medical devices that you would see like in a hospital environment. 
  
I'm not talking about a CGM patch or something like that. 
  
But again, these could run on lithium primary cells or rechargeables. 
  
And again, they're looking at polling, so it really varies on their activity on what that type of device is. 
  
So there is some flexibility there. 
  
But I think the key here is when I'm thinking about Wi-Fi, there's going to be sort of those three modes. 
  
You're going to have what I'm going to talk about as a sensor, where really that's a pretty low duty cycle. 
  
And that's something that basically it could be actually disconnected from the Wi-Fi network during that time. 
  
And then if there is an event or it needs to do a heartbeat, it can reconnect. 
  
And these are something that in some cases, what's really good here is to look what is my use case, and then you could put that use case through a power estimator to see what's the best use case for me. 
  
What should I be using? 
  
What type of mode should I be going into between these events? 
  
And then again, we talked about the actuators, I talked about the locks, et cetera, where it does need to respond in a timely fashion, but it still can go to sleep.And then you have duty cycled. 
  
And in reality, all these are duty cycled, but this third case is something a little more specific that there are times when I need to be active and connected at all times, and I'm really not sleeping. 
  
And again, this depends on the application that you're using. 
  
So, quickly to look at some of the Wi-Fi modes that-- And we'll get more details on this. 
  
Vaseem is going to go into much more detail on Wi-Fi. 
  
I'm just trying to give you sort of what are the reasons for low power, what are some of the different modes. 
  
But, again, you have this associated, where I'm sort of always on, this standby associated, where I am alternating between a low power sleep mode and a connected mode. 
  
There's things like legacy power save, WMM power save, and DTIM intervals as well, where I could actually sleep for longer intervals of time. 
  
And then disassociation, that's where I disconnect completely. 
  
So, for example, if a sensor doesn't need to really have a lot of connectivity, I'm going to get longer battery life if I disassociate from the network for 30 seconds and then come up for a heartbeat, or I disassociate and on an event, I come up. 
  
While my connection time on that event may be seconds, that's not critical typically in that situation. 
  
So it's, again, about what is your use case and your low power mode that you need. 
  
So, a little bit more on this. 
  
What are some examples we see? 
  
Obviously, things like always on are security cameras, lighting, wearables. 
  
Lighting is always on because, again, if you're using it as a switch, when I press that switch, in general, you have about 100 milliseconds of time before that light can turn on, before there's a visible notice, and then there's a dissatisfaction. 
  
If somebody pushes a switch and they have to wait two seconds for that light to come on, most likely they're going to push that switch again and again, et cetera. 
  
So those are very low latencies. 
  
The dominant power factor in those is really your transmit power, and they're sort of optimized for that efficient data transmission. 
  
Periodically connected things like actuators. 
  
Again, we talked about some of these. 
  
They could be door locks, thermostats, shades, things where you want a relatively quick response, but it doesn't have to be in the range of 100 milliseconds, and you're sort of balancing power and latency. 
  
In that mode, sort of your receive current as well as your sleep current are both equally important. 
  
And using things like DTIM and WMM power save will help in that environment. 
  
And then finally, when you really have an event-driven, things like sensors, order buttons, door/window sensors, smoke, et cetera, you can have a little bit more latency on those. 
  
And so you can go into this really ultra low stand power, where you just disconnect from the network and then connect as needed. 
  
An order button's a good thing. 
  
Like the old Amazon, they don't do this anymore, but they had that order button. 
  
It was in basically a disassociated mode. 
  
You push the button, it connects to the network, transmits that data, and then disconnects. 
  
So there are some examples of different sort of low power IoT applications for Wi-Fi. 
  
So with that, what I'm going to do is turn it over to Vaseem and let him go into more depth. 
  
Thank you, Matt. 
  
Morning, everyone. 
  
Let me get started. 
  
Matt spoke about a lot of things on the low power. 
  
Let me go a little bit in details of Wi-Fi specifications and some of the low power enhancements we have done in Wi-Fi on our products. 
  
And then we'll leave time for a demo for Wi-Fi power estimator as well. 
  
All right, so as you guys know, Wi-Fi's come a long way since its inception more than 25 years ago. 
  
Today, it's not just about internet access. 
  
It's become a fundamental part of our digital lives, continuously evolving to serve new applications and industries. 
  
Just on market adoption, it is estimated that 21 billion-plus devices are there in market which use Wi-Fi, and it's continuously growing at five-plus percentage annual growth rate. 
  
Wi-Fi Alliance just estimate just the global value of Wi-Fi is close to $5 trillion at 2025. 
  
So that's a lot of GDP growth in a lot of countries that has been enabled with just enabling Wi-Fi. 
  
Now, when we see traditionally, Wi-Fi as being just for internet access, but that has been changing over the course of time. 
  
There are a lot of new cases and new use cases and new areas that have been enabled in Wi-Fi, which were traditionally not been there in last 10, 15 years. 
  
Some of the examples are Wi-Fi sensing. 
  
It goes much beyond connectivity. 
  
You can measure fall detection, heart rate, and elderly care. 
  
A lot of things, use cases are possible which were not possible in traditional Wi-Fi. 
  
Wi-Fi has also enabled very high throughput applications such as AR/VR, which are used for immersive gaming, and Wi-Fi has also become daily part of lives in even automotive industry, especially in the EVs, where without Wi-Fi, a lot of EVs don't work at all. 
  
If you see on the right side, the evolution of Wi-Fi standard, it started from 802.11ABG, and it has transformed over years all the way to Wi-Fi 8. 
  
Every three to four years, we've seen new Wi-Fi standards coming, with latest being Wi-Fi 8, which is currently already ratified by IEEE and going to get a stamp from Wi-Fi Alliance as well. 
  
Let's go through some details of some of these Wi-Fi specifications. 
  
If you see Wi-Fi evolution, standard evolution over the course of year, I'll start with, instead of Wi-Fi 1, 2, 3, start with Wi-Fi 4, which was most common Wi-Fi standard, and it's where it picked up quite a bit. 
  
That's still a predominant standard on Wi-Fi IoT. 
  
Still continues to be shipped in high volume. 
  
It enabled HD streaming, MU-MIMO, and dual band for the first time. 
  
And it still continues to be one of the flavor of choice for a lot of IoT products. 
  
Next came Wi-Fi 5, which essentially enabled really high throughput, because of enabling 5 GHz with MU-MIMO plus 4K streaming, and also added a lot of additional bandwidth, especially on 160 MHz and 256 QAM. Then what happened after Wi-Fi 5 is Wi-Fi 6. 
  
It was really a transformational standard. 
  
It did not just introduce new high throughputs, but also added a lot of protocol features such as TWT, which is enabling low power for IoT and other devices. 
  
Added OFDMA, which increases throughput in both uplink and downlink, and also allows multiple clients to send in parallel streams, and also added completely new band, six gigahertz, which was not available in Wi-Fi 4 and 5 before. 
  
So just with Wi-Fi 6 and 6E, you can get close to 10 gigs of throughput for general Wi-Fi devices. 
  
Next came Wi-Fi 7, which is out in market. 
  
A lot of APs have been continuously being sold. 
  
Majority of the APs that are being sold today, which is an increasing market share, is Wi-Fi 7. 
  
Wi-Fi 7 introduced some of the key new features such as multi-link MLO, and restricted target wake time. 
  
It also added a lot of different reliability features such as 4K QAM and also 320 MHz to enable new use cases such as AR/VR. 
  
As you have seen over the course of Wi-Fi 4 to Wi-Fi 7, the primary driver was speed. 
  
Now, with Wi-Fi 8, that has changed a little bit. 
  
It's not just focused on speed, but also on reliability. 
  
Wi-Fi 8 adds completely new set of features such as map coordination. 
  
Now, the multiple APs can coordinate between your own home and also your neighbors. 
  
It also adds completely new areas of time-sensitive networking and also optimized power save for not just IoT devices, but it goes beyond IoT devices. 
  
As Wi-Fi evolves, it continuously unlocks new possibilities, along with new features. 
  
And let's look at some of the key features of Wi-Fi 6 and 7 and 8. 
  
Wi-Fi 6 has been one of the dominant choice, along with Wi-Fi 4 for IoT. 
  
And that's where our current product, 917, is based off as well. 
  
If you look at some of the key features of Wi-Fi 6, the first and dominant feature is OFDMA. 
  
It allows multiple devices to transmit simultaneously. 
  
Unlike Wi-Fi 4 or 5, every device had to have its own slot, and no two devices could transmit simultaneously. 
  
Wi-Fi 6, with the enabling of OFDMA, it allows multiple devices to send simultaneously, and also it reduces latency for latency-sensitive applications. 
  
The other key driver is MU-MIMO. 
  
While MU-MIMO was available in Wi-Fi 5 as well, Wi-Fi 6 mandated it for both uplink and downlink on AP, and at least on downlink on the client side. 
  
It also enabled 1024 QAM to further increase throughput. 
  
The next feature is TWT. 
  
This is one of the most important feature for IoT, target wake time. 
  
Now, previously in Wi-Fi 4, for a client to go to the power save, it went in a very predetermined time. 
  
There was no way to negotiate between client and access point. 
  
Target wake time, TWT, gives you that option to negotiate with AP, when does the client go to sleep, how long does the client go to sleep, and it formalizes a lot of that interaction between AP and client. 
  
It also added number of other features such as BSS coloring, preamble puncturing, and extended range for busy environment and also extending the range. 
  
Let's look at some of the other features that were added in Wi-Fi 7 and Wi-Fi 8. 
  
The current standard which are being extensively certified are Wi-Fi 7 and Wi-Fi 7 R2. 
  
Let's look at just couple of features. 
  
There's way more features in Wi-Fi 7 itself, but I'm looking at just two or three high-level features which are important to an IoT world and some of the cellular world as well. 
  
The first one is MLO. 
  
Back in Wi-Fi 3, 4, 5, and 6, client could only connect to AP on one channel. 
  
Wi-Fi 7 changes that. 
  
You can have multiple connections. 
  
You can have a 2.4 and 5 connection simultaneously talking to access point. 
  
What this improves is reliability. 
  
A client could be connected on 2.4 for a longer range, and when it needs to send data packets, it could switch to five gigahertz, both of them connected simultaneously and using bands and switching packets between bands as it prefers based on the link connection. 
  
The second feature is multi-RU. 
  
In Wi-Fi 6, a device could only send packet on just one RU, and then the additional RUs, if there were no clients that were going to use it, the RUs were getting wasted. 
  
And Wi-Fi 7 solved that problem by clients could choose multiple RUs in the same transmission. 
  
The third and most important feature on Wi-Fi 7 is, again, enabling our 20 MHz state. 
  
It was started in Wi-Fi 6. 
  
That will continue to Wi-Fi 7. 
  
This is one of the most critical features for IoT. 
  
Most of the IoT devices don't need 160 or 320 MHz of bandwidth to send traffic. 
  
A lot of IoT devices just need a small pipe. 
  
So enabling 20 MHz as a certification and also as a supported option opens doors for IoT devices and increases Wi-Fi adoption for IoT world. 
  
Let's look at a little bit on the Wi-Fi 8. 
  
Wi-Fi 8 standard, 8011be, has been ratified already. There is talks already in WFA on what features to be mandated for certification. 
  
So I'm just highlighting some of the features that will be enabled. 
  
There are many more for Wi-Fi 8, first being MAP-C or Multi-AP Coordination. 
  
In Wi-Fi 7 or earlier, your APs could talk in just in your own system. 
  
And there's not a close coordination between APs except for some of the mesh devices. 
  
Wi-Fi 8 solves that. 
  
APs can work together intelligently and could add AI layer on top of it and continuously improve signal. 
  
Suppose a client is in a specific corner of the house, it can beamform with the help of one or two more APs, and it can do coordinated beamforming. 
  
It can also enhance efficiency for mesh networks by reducing the hops as well. 
  
The second important feature is enhanced power save or dynamic power save, known in WFA world as well. 
  
For a lot of clients, such as even for phones and tablets, you don't need to be locked to 160 or 320 megahertz all the time. 
  
You can be sleeping or be using 20 megahertz for most of the time and jump to 160 or 320 megahertz when you need to really do a 4K stream, download a large file. 
  
So that 20 megahertz power-saving capability is being brought not just to IoT devices, but for a lot of other devices. 
  
So in future, in Wi-Fi 8, your phones and your tablets could be more power sensitive by using these features, and also save much more power. 
  
The third important feature is enhanced long range. 
  
Wi-Fi 6 had extended range. 
  
Wi-Fi 7 also continued it. 
  
Wi-Fi 8 improved it even further. 
  
It added new PPDU or packet format for uplink communication to even increase the long range. 
  
So if you have a Wi-Fi 8 stay with ELR, the range could go even further than what it was with Wi-Fi 6 and Wi-Fi 7. 
  
Go to the next. 
  
So as you see, Wi-Fi has evolved over time with different standard, with different features. 
  
If we even go back to really old way, BGN, you had the legacy power save. 
  
Most of the clients go to sleep. 
  
They wake up frequently, could be either DTIM1, DTIM3, or even DTIM10 for some of the devices. 
  
The problem was the sleep state or the dose state wasn't very deep. 
  
While other devices have implemented their own proprietary mechanism, Wi-Fi 6 has enabled target wake time. 
  
What this does is, as I mentioned earlier, it allows station and AP to talk to each other to negotiate much longer sleep times. 
  
So Wi-Fi 6 has enabled that completely new paradigm shift for IoT. 
  
Along with target wake time, it also included basis coloring in OFDMA, which further increases in efficiency and also it avoids devices listening to just other packets. 
  
With basis coloring, they can listen to their own packets when the packets are colored out in the heavily congested environment. 
  
Wi-Fi 7 is going to be the future of the low power efficiency along with Wi-Fi 6 features. 
  
And when you enable MLO, you can continue to be connected to both the bands, and with punctured transmission and restricted target wait time, it further enhances power-saving mechanisms. 
  
Now let's do a reality check. 
  
While all these features are great, it's important to take a step back and look at the real-world deployment. 
  
One key point is just the device or station capability is not enough. 
  
The access point also needs to support all these features. 
  
And the good news is access point deployments are ahead of the stations, especially in the client world. 
  
For example, Wi-Fi 6 and Wi-Fi 6E are widely spread right now. 
  
Most of the deployments are either Wi-Fi 6E or beyond, and 6E adoption with six gigahertz is continuously accelerating with the clean state deployments, even for IoT world. 
  
And also multiple countries have enabled six gigahertz band, not just US, Canada, and Europe, but also it's increasing to most of the other APAC countries as well. 
  
So while the new features take time to fully penetrate, the ecosystem is moving quickly. 
  
The key takeaway here is the infrastructure is evolving in parallel, in many cases leading the way, and which is critical for enabling these advanced features and real deployment. 
  
Now let's look at some of the how do we design for low power and some of the improvements we have done on our products. 
  
And there are many more, but we'll just go through some of the enhancement we have done, 91W7 and some of the other Wi-Fi products. 
  
All right. 
  
Let's take a closer look at what's actually happening, like in practice on a Silicon Lab Wi-Fi device. 
  
What you see on the left is a current consumption plot over time. 
  
At first glance, it looks like a periodic spikes, and that's exactly what is happening. 
  
The device spends most of the time in low-power state and periodically wakes up for very short intervals. 
  
These wakeups are typically driven by DDIM intervals, listen intervals, or could be a target wake time. 
  
During each wake up, if you zoom into the plot a little bit more, the radio powers on, the device listens to beacon or data, and then quickly go back to sleep if there is nothing to process.It starts with even smallest part of the chip, such as regulator or crystal oscillator powering up, the MAC and baseband initializes, followed by radio entering into the listen state, and then when there's data, it receives it. 
  
If it has data to send for such as MQTT or TCP packets for upstream, it sends it, and then it go right back to sleep. 
  
The key point here is each wake-up is highly optimized and very short in duration, which keeps the average power extremely low. 
  
On the right side, we've summarized few of the techniques to enable this. 
  
Some examples include sleep time between wake-ups are highly optimized. 
  
So, the drain is actually very low in ultra-low power state. 
  
The boot-up times are extremely fast, unlike an access point or a larger phone boot-up times. 
  
The boot-up times are in matter of seconds. 
  
And the wake-up for wireless listen is also very fast, and it uses low-power radios. 
  
We have multiple radios on the devices, a high-power radio for transmission, and also low-power receive radio. 
  
It can use either one of them to reduce the power consumption. 
  
And we transmit only when needed. 
  
And most of it is all done in parallel, being connected to an access point. 
  
We don't lose the connectivity, so it's always associated, so that your access point does not kick you out or disconnect you to cause you the whole WPA authentication cycle, which increases the power. 
  
Let's look at few other hardware level improvements we have done. 
  
So at a device level, Wi-Fi supports multiple sleep mode, allowing designers to optimize based on different power and performance trade-offs. 
  
At a high level, you have two categories, low power and an ultra-low power mode. 
  
The low power mode is where the device system maintains a state, the host interface also talks and maintains its states, and device responds more quickly when needed. 
  
So this mode is useful for devices which are typically line powered or rechargeable batteries, where it's important to reserve, conserve power, but still be available very quickly. 
  
The second mode is ultra-low power mode or a deep sleep mode. 
  
Here, almost entire system is shut down except for the ULB subsystem. 
  
We have two options within this. 
  
A mode with RAM retention, where most of the system state is saved, and mode without RAM retention, where most system state is lost. 
  
In this mode, a host interface is not active. 
  
It's mostly sleeping. 
  
It's completely shut down. 
  
The device wakes up using external triggers such as GPIO or external triggers or something, a sensor attached to the device. 
  
This is best suited for battery-operated devices, which needs maximum lifetime, such as sensors, et cetera. 
  
So overall, we have flexible sleep modes, which allows developers to define power versus responsiveness based on the application needs. 
  
Going on to additional Wi-Fi power save profile. 
  
Now, those were the, the previous slide was talking about hardware improvements or changes with multiple sleep modes and power save modes. 
  
In addition to hardware sleep mode, we also have different power save profile at the protocol level. 
  
Wi-Fi itself defines some of them, but we have enhanced them with some proprietary mechanisms to improve the power save by a large margin on Wi-Fi devices. 
  
So there are three big categories of the power save, MAX PSP or enhanced MAX PSP, and Fast PSP and UAPSD PSP, which is one of the standards of Wi-Fi Alliance. 
  
The first one, MAX PSP, here's where the device enters sleep, and then data using PS-Poll mechanism. 
  
It wakes up for data and listen intervals. 
  
It minimizes radio usage, but also can introduce latency. 
  
So if you need super high throughput performance, MAX PSP is not the best profile, but it saves a lot of battery life. 
  
We also have enhanced MAX PSP, which improves on MAX PSP a little bit. 
  
If AP access point response is delayed, the device can temporarily switch to a faster mode, which is enhanced MAX PSP. 
  
This improves reliability with power savings. 
  
So those are the two modes of MAX and enhanced MAX PSPs. 
  
Next one is Fast PSP. 
  
This is a middle ground between power save and the performance. 
  
It provides a better balance between latency and power. 
  
IoT applications where responsiveness matters, but also power is important. 
  
Finally, we have UAPSD PSP. 
  
This is application-based priority based on WMM 802.11e class of service. 
  
It's designed for real-time applications such as VoIP or real-time traffic, which you need. 
  
So traffic can be categorized as video, audio, best effort, background, according to 802.11 key queues, and it requires AP, most of the APs support the 802.11 queuing mechanism. 
  
So once you have the support, the stations on 907 can support UAPSD as well. 
  
All right. 
  
We have designed a Silicon Labs power estimator. 
  
Let's go through that demo, which helps you to do a real-world power measurement before you even build devices. 
  
Common assumption is that Wi-Fi and long battery life don't go together, especially for always connected devices. 
  
But in reality, with right configuration, Wi-Fi devices can run for months or years on battery. 
  
Let us show you how you can estimate that using Silicon Labs Wi-Fi power estimator. 
  
Let's take an example of environment sensor, things like temperature, humidity, or even air quality sensor, that typically don't send data continuously. 
  
They sample frequently, but transmit less often. 
  
So the key to power optimization is batching data, minimizing transmit events, staying low power connected states as much as possible. 
  
Instead of guessing, we can model all of that before you even think about building hardware. 
  
Let's define a typical environment sensor. 
  
Start with the battery. 
  
In this case, I'm choosing a two triple A battery setup, which is around 1,000 milliamp hours, which would be common for a mid-size environmental sensor. 
  
Now, for the wireless configuration, I'll keep a device associated with using Wi-Fi 4 beacon-based power save. 
  
I'll set the listening interval to roughly 2,000 milliseconds, which is two second, and increase the wireless WLAN keep alive to 90 seconds. 
  
So we maintain connectivity without frequent reconnects. 
  
Now, let's set an application behavior. 
  
Let's say the sensor samples data every one minute, temperature, humidity, or any kind of environment data. 
  
The processing itself is very short, roughly could be around 15 milliseconds. 
  
So the most of the time, the system's still sleeping. 
  
So we set the priority to minute, and with a duration of 15 milliseconds. 
  
Now, let's go to data transfer. 
  
Instead of sending data every minute, we can batch it and transmit every five minutes. 
  
Let's turn on the transfer and set the priority to 600 seconds, which is five minutes. 
  
And for the packet size, we could send roughly 1,024 bytes of either HTTP or NT traffic, which should be enough for sending a sensor data. 
  
Optionally, you could also turn on the receive, for example, for checking firmware updates or configuration changes from cloud. 
  
You could turn it on as well for calculation. 
  
I'll turn it off for now for this demo. 
  
And finally, we can add a peripheral configuration connection load for one of the sensors. 
  
Let's keep it around five microamp. 
  
Now you get the result instantly on the right side, which shows you roughly 70 to 75 microamp current consumption, which shows roughly 12 plus months of battery life. 
  
What's important here is device spending vast majority of the time sleeping and only waking up briefly for sensing and transmission. 
  
Also, the Wi-Fi connection avoids the high cost of reconnecting every time. 
  
Now, let's explore a quick trade-off. 
  
If I increase the transmission frequency, for example, instead of sending data every five minutes, we send it every minute. 
  
So I'm going to change the TXPri to 60 seconds. 
  
You can see that instantly, the battery life has reduced from 12 plus months to just eight months. 
  
There's a significant impact of just sending data every 60 seconds instead of every five minutes. 
  
So these are exactly the kind of system-level trade-offs you can evaluate instantly. 
  
So the takeaway is Wi-Fi is absolutely viable for low-power sensors and other devices, which even needs always-on connectivity, but the system design really matters. 
  
Things like batching data, sleep strategies, and transmission frequency. 
  
And with a tool like this, you can explore those decisions early and design for both performance and battery life with confidence. 
  
All right. 
  
So I think some of the really key takeaways here is your wireless technology choice really depends on your specific application requirements. 
  
With Wi-Fi today, it really is a viable option for low-power, battery-powered IoT devices. 
  
This really wasn't necessarily the case years ago. 
  
There's power-saving features that are starting to come into the specifications, like TWT, that are crucial for really extending this battery life. 
  
And then we're going to continue to see innovation in Wi-Fi that really enhances those applications for low-power Wi-Fi. 
  
Whether it handles it directly or indirectly, you'll be able to see continued improvements for this.