## 4 Performance Evaluation
### Experiments
#### 4.1.1 Analysis on Effectiveness of Techniques Used for _HeaLow_  
As explained in Section 3.3, we have implemented various algorithms and techniques to optimize the performance of _HeaLow_. In addition, we conducted some experiments to analyze the effectiveness of the techniques, as presented in this section. Figure 3 shows the drop rate and the offload rate of _HeaLow_ with and without various optimization techniques we have adopted. The \"\(\times\)\" notation in x-axis indicates the amount of workload generated compared to a basic state. In the experiments, we used smartphones, so the devices had powerful computation powers. However, it is to be noted that the performance of smartphones degrades quickly over time, which is why we tested intermittently with 15-min interval for more reliable results. The methodology used to obtain Figure 4 is as follows. When a workload is being offloaded, the system counts the number of offloaded workloads as it returns to the device. The queue length is recorded when each of workload processing is finished. Therefore, the peaks shown in Figure 4d,e may seem out of place as the peaks are recorded when the packets are returned to the original device. As we implemented delayed response, this causes the peaks to be a few hundred milliseconds to seconds later than when they are offloaded. First, each case is as follows. Case 0 is for a single device processing all data by itself, which means that _HeaLow_ was not applied, and Case 0 stands for the case of current WSNs. In Case 0, there is no other device to offload to, so Case 0 is not shown in the offloaded ratio graph. In Case 1, we applied no optimization method as a base case. In Case 2, we added _buffered message method_ which is the biggest improvement for the performance. _Buffered message method_, as explained in Section 3.3.1, is a method of using the network bandwidth with a message buffer, sending multiple messages together instead of sending one by one. In Case 3, _buffer length management_ and _hazard state management_ have been added on top of Case 2, because _buffer length management_ is a supportive technique for other following techniques. _Buffer length management_ mentioned in Section 3.4.2 is a method of maintaining the length of the buffer to consider the network delay and the current processing power. _Hazard state management_, as explained in Section 3.3.2, is a method to manage the device in two states, stabilizing the behavior of offloading. _Delayed response_ explained in Section 3.3.3 is a method for the receiving device to monitor the time left until the deadline and hold on to the result if more than twice the network transmission time is left. Case 4 has _delayed response_ and _buffer length management_ on top of Case 2. Case 5 has all four methods implemented. In Case 0, which is without _HeaLow_, there are a lot of failed workloads because it is difficult for a single node to perform heavy-computation and low-latency processing by itself. In Case 1, no matter how many workloads are failing, offloading does not exceed 2%. Since each device is blind to other devices' status, each offloading needs a permission from the target device. Sending each packet after permission means each workload requires three-way packet exchange (request, response, and offloading), so the performance is unacceptably low. In Case 2, the amount of offloading increases to 22% as dropping packets increase. As a result, the sum of amount being dropped and offloaded is close to the amount being dropped in Case 1. This is expected as network utilization increases significantly with _buffered message method_. In Case 3, the amount being offloaded does not increase compared to  
Figure 3: The effectivenesses of the techniques used for _HeaLow_: (**a**) the drop rate of each case; and (**b**) the offload rate of each case. Case 2. Rather, it decreases slightly, while the amount being dropped decreases significantly. At first glance, it may not be logical to have the same amount offloaded and have fewer failures.