One of the biggest challenges in using a Wi-Fi device in a battery-powered application is overcoming its power-hungry nature. In many cases, the IoT devices make a compromise on the throughput by choosing BLE to communicate data. In order to make Wi-Fi devices more suitable for the IoT Edge, many offload features are employed to increase the duration for which the host MCU is in deep sleep. In this blog post, we will be going through the important features of the Low-Power Assistant (LPA) middleware which will help you use these offload functions to the Wi-Fi device for greater power savings.
So, what are these offload features? These offloads are mainly targeted at network packets that are frequently sent over the radio like the ARP packets or at providing the freedom to the application to choose which packets to process or at maintaining the connection by providing keep-alive responses. Let’s learn about them now!
ARP (Address Resolution Protocol) offload
ARP is a data link layer protocol for mapping an IP address to a physical MAC address of a device. Such mapping is necessary for any WLAN device to keep updated on [IP:MAC] details of all nearby devices in its network. Using the ARP protocol, a device can detect duplicate IP addresses in a network. This is also useful in notifying peer devices of an IP address change. ARP request and response packets are a common activity in any WLAN network. All the devices in the network need to respond to an ARP request even if they don’t care. The host device usually gets flooded by many requests. As a result, the host needs to remain active to respond to such requests, especially in a crowded network. ARP request packets from a peer usually wake the host if it is sleeping. The ARP offloading feature in CYW43xxx handles responding to ARP requests from a peer so that these requests will not disturb the host. The CYW43xxx device holds a cache (of 8 entries); the host will be woken up only if there is a cache miss as shown in the figure below.
In addition to auto-replying to peers, CYW43xxx can use the cache to reply to the host (PSoC 6 MCU) as well when the host sends an ARP request to the network. This host auto-reply feature works like a Peer auto-reply, where a cache miss is forwarded to the network and a cache hit returns an ARP response immediately to the host. This feature is complemented by the ability of the CYW43xxx device to snoop ARP info from host-network communication, i.e., whenever a host sends an ARP response packet over to the network, the [IP:MAC] information is cached into the CYW43xxx ARP cache table.
Packet filter offload
A Packet Filter prevents unwanted network packets from reaching the host MCU (PSoC 6 MCU) and waking it. This helps the host to stay in deep sleep for longer periods of time. WLAN packets can be filtered based on the port (in the application layer in the OSI model), protocol (transport layer), or Ether Type (network layer).
The Internet Assigned Numbers Authority (IANA) is responsible for maintaining the official assignments of port numbers, protocol numbers, or Ether type for WLAN packets. See the IANA Protocols Registry for information on protocol numbers.
The figure below shows the packet filters supported based on a standard IP Stack.
Filters can be configured to either Keep (send to host) or Toss (drop/discard). When configured to drop, only the specified packets are dropped, while any others not specifically filtered are passed to the host. Likewise, when configured to keep packets, only the specified packets are passed to the host and the rest discarded. The most helpful model is to use only 'keep' filters. In other words, use 'keep' filters to specify the complete list of packet types the host is interested in, and discard the rest. This works because (usually) it is much simpler to list the packets the host wants to receive versus creating a complete list of packets it doesn't want. Please note that all active filters need to be of the same type (keep or toss). Mixing active keep and toss filters will cause unexpected behaviors.
When using keep filters, use care to allow enough packets through for networking protocols to work properly. For instance, the processor must be able to join a network, get a DHCP address, respond to ARP requests, and possibly share network keys. Not creating enough keep filters to allow all these types of packets through will prevent the host from joining the network. A reasonable minimal set of keep filters includes:
Filters can be configured to be active either when the host processor is active or asleep, or both. When a filter is not active, it has no effect. When the system goes into sleep mode, it disables all wake filters and enables all sleep filters just before entering sleep. When waking, all sleep filters are disabled and wake filters enabled.
Normally, without packet filters, the WLAN subsystem passes all packets destined for the host up to the host network stack for processing. If the host is in System Deep Sleep, the WLAN subsystem will first wake the host and then pass the packet up to the stack. From there, the network stack will pass the packet on to the application that is listening for that type of packet. If no applications are listening for that type of packet, the network stack drops the packet.
In both cases, the host would awake from System Deep Sleep just to drop a packet. It is not hard to imagine scenarios where traffic your application doesn't want or doesn't care about ends up penalizing your battery usage by constantly waking the host from System Deep Sleep
For more details, see the Low Power Assistant Reference Manual.
TCP Keep-Alive offload
A TCP keepalive packet is a message sent by one device to another to check whether the link between the two is operational or to prevent the link from being disconnected. When two devices are connected over a network via TCP/IP, TCP keepalive packets can be used to determine whether the connection is still valid, and terminate if needed.
If a connection has been terminated due to a TCP keepalive timeout, and the other device eventually sends a packet for the old connection, the device that terminated the connection will send a packet with the RST flag set to signal the other device that the old connection is no longer active. This will force the other device to terminate its end of the connection, so a new connection can be established.
Therefore, TCP keepalive packets can be used in checking for dead peers or for preventing disconnection due to network inactivity. Typically, TCP keepalive packets are sent every 45 or 60 seconds on an idle TCP connection; the connection is dropped after three sequential ACKs are missed. This means that the host MCU must wake up periodically to send TCP keepalive packets to maintain the TCP connection during the idle state.
The TCP keepalive offload part of the LPA helps you improve the power consumption of your connected system by reducing the time the host needs to stay awake to support TCP keepalive requests. This is achieved by offloading the TCP keepalive functionality to the WLAN device so that the host MCU can be dedicated to your application.
The figure below shows that the host wakes up for incoming TCP traffic when offload is not enabled. On the other hand, the host can save more power by entering and staying in deep sleep for a longer time when the TCP keepalive activity is offloaded to the WLAN device.
Note: The TCP keepalive activity is offloaded only when the host MCU goes to sleep and the network stack is suspended.
In addition to these offloads, an important feature of the middleware is network activity handlers which take care of suspending the network stack on the host MCU when there is no activity on the Wi-Fi interface and resume the network stack when there is activity. Network stacks like lwIP require the host MCU to service different timers started by the stack. Suspending the network stack will mean that the host MCU no longer has to service these timers, thereby allowing the host to remain in deep sleep longer. The example, mtb-example-anycloud-wlan-lowpower, demonstrates how to use the network activity handlers from LPA. The example connects to a configured network. After connecting to the network successfully, the example configures the WLAN device in a power-save mode, suspends the network stack, and puts the host MCU in a wait state. During this wait state, the host MCU enters a low-power state and wakes up on any network activity detected on the MAC interface.
After you program the example, open a terminal application as explained in the example README.md. You can see the logs providing details of how long the host MCU has spent in deep sleep, sleep, and active. You can observe that the host MCU is woken up multiple times even if you are not the originator of the traffic. These spurious wake-up sources can be due to the multicast traffic on the network. This is where the offload features of the LPA middleware come in handy.
You can enable the ARP offload capability to the example by opening the design.modus file using the Device Configurator that is shipped with ModusToolbox software. You can find the design file used by the example in <application_folder>/COMPONENT_CUSTOM_DESIGN_MODUS/TARGET_<KIT_NAME>/design.modus. Before you enable the ARP offload, let’s see the behavior of the device without ARP offload using an ARP utility. You can install the ARP'ing network utility from these websites:
You can see that when you issue the command- arp-ping 192.168.0.109, the sleep stats on the serial terminal indicate that the host MCU is woken up to service the ARP requests.
Now, add the ARP offload to the example by opening the design file using the Device configurator, going to the tab for the connectivity device, and configuring the fields as follows.
You will see If you issue the ARP’ing command now, you can observe that the host MCU doesn’t wake-up to service these requests. But there is still other traffic on the network that can wake up the host which is not used by the application. As discussed, before we can configure the Wi-Fi device to forward only those packets to the host which is needed by the application. Again, open the design file and switch to the connectivity tab of the device and do the following to enable Packet filters,
If you issue the ARP ping command to the IP address of the device, the device responds without waking up the host MCU. But if you issue a ping command the device doesn’t respond because the WLAN device discards this packet based on the filter selection provided in the design.modus. You can add the filter to keep the packet associated with ping by opening the design file, going to the tab for the connectivity device, and configuring the fields as follows.
Open the design file, switch to the connectivity tab of the device, and do the following,
Now, the device responds back when there is a ping request for the device.
We have seen how to configure the ARP offloads and Packet Filter offloads which handle incoming traffic. Let’s move to the case where the offload caters to outgoing traffic i.e., the TCP Keep-Alive offload. The code example, mtb-example-anycloud-offload-tcp-keepalive, demonstrates the TCP keepalive Offload functionality by allowing the WLAN device to handle the TCP keepalive packets from the network on its own so that the PSoC 6 MCU can remain in a low-power mode longer. The example requires a TCP server. Use the python script provided with the example to start a TCP server on your PC. The example connects to the network whose credentials are provided in app_config.h and establishes a TCP socket connection with the configured TCP server. For more details on working with the example and details on how to verify the TCP Keep-alive feature, refer to the example documentation.
What’s in store?
LPA is provided as part of AnyCloud; a framework for IoT application development that is not tied to a specific cloud provider or management tool. In this release, LPA provides support for ARP offload, Packet filter offload, and TCP Keep-Alive offload. You can also go and explore other interesting libraries that can help in your IoT application development! You can refer to our AnyCloud code examples in Cypress GitHub repository for reference. Have fun with AnyCloud and ModusToolbox!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.