## 3 The Design of _HeaLow_ and Implementation
### Workflow of HeaLow  
In _HeaLow_, the workload generator indicates the module where workloads, i.e., microphone input data, are generated. Through the rest of the manuscript, workload is used with certain amount of ambiguity as we want the concept of our system design to be of use with other systems. However, in this work, we only conducted experiments where a workload is a block of audio input read from the microphone. We have a discrete definition of workload, where a set of microphone input data for one FFT operation is taken as one workload. As mentioned before, most audio related systems use FFT for signal processing, especially when it is also used by other signal processing tools: cross correlation, convolution, auto correlation, etc. It is to be noted that we defined workload as a block of audio input data because FFT is done by blocks. In other studies and systems, this goes straight to a worker thread. This is based on the assumption that the device has enough computational resources. In _HeaLow_, the worker thread has a work queue, because the processing rate can be smaller than the incoming rate. This should be considered in applications for WSNs. When a worker thread has a work queue attached to it, the queue either empties or fills up. If the queue fills up over a certain length, the availability checker denies requests for enqueuing and sends the data to a dump queue. In this manner, the work queue only has an amount that the worker thread can handle.  
When a workload is thrown into the dump queue, it needs to either be dropped out or be offloaded somewhere else. The dump queue consistently asks the manager for queue availability of other devices in the membership, where the communication support module of the manager broadcasts the request. The availability checker of another device answers with the amount it can process on top of its own workload, which is delivered back to the requesting device through the communication support module. The dump queue then offloads the number of workloads it is allowed through a peer-to-peer connection to the device. We use the term peer-to-peer connection on the application layer level. In _HeaLow_, a peer-to-peer connection means a connection through which one device sends a data to another device without going through a server device. For instance, the offloading device directly connects to the destination device based on the address given from the server. This avoids a server having to process all traffic. That is, if the devices are connected through Wi-Fi as in our system, if it needs to go through the server's socket, device A sends the data to the Wi-Fi AP, the AP sends it to the server device, the server device sends it to the AP, and the AP sends it to the destination device. However, if device A directly connects to the destination, transmission only occurs twice. This connection is used again when the result of the offload is returned. The result organizer collects the results directly from the work queue and the offloaded work, and reorders the results for the application. Some of the missing explanation for implementation details are given in Section 3.3, along with the design choices for them.