Comparison and Evaluation

As presented in Chapter 4, few infrastructure abstractions utilize in-network pro-cessing. Most notably, T-RES [8] and design of Leppänen et al. [122, 123] allow distributed processing over heterogeneous WSNs.

The Leppänen et al. design uses mobile agents and an REST interface for distribu-tion. The devices can communicate and share resources through the interface and migration of the agents. The design has two major differences when compared with the embedded cloud:

1. The task code in the mobile agents is not homogenized. It can be arbitrary machine code, VM code, or interpret byte code that can be queried from a code repository. This requires the implementation of the task code for all possible technologies that are expected to migrate the mobile agents that use the task.

2. Combining arbitrary resources remotely is not possible with mobile agents, as they connect directly to the remote resources to get the data for the task code to process. The PDL process in the embedded cloud can connect any resource to a remote processing service. In theory, a mobile agent could mimic similar behavior through its migration. It is unclear from [122, 123] if this is possible.

The evaluation of Leppänen et al. concentrates on the implementation size, delays and message sizes. The design of Leppänen et al. consumes 28864 B of program memory and 3850 B of data memory on an 8-bit Atmel ATmega MCUs. These figures are larger than with the embedded cloud. The embedded cloud uses 1 s granularity in its functioning, as many low duty cycle WSNs are not able to deliver data with a lower delay. The total delay depends on the protocol stack utilized. Therefore, the point-to-point delay is not considered for the embedded cloud. The message sizes of Leppänen et al. vary between 8 B and 66 B toward the WSN nodes when using a

1 GW

2 3

4 Actuator Server

1 GW

2 3

4 Actuator Server

1 GW

2 3

4 Actuator Server

1 GW

2 3

4 Actuator Server

Topology #0 Topology #1 Topology #2 Topology #3

Fig. 22:The topologies used to evaluate T-RES [8] and the embedded cloud.

20 B task code. These are similar figures to the 9 B minimum message size of the embedded cloud.

T-RES is evaluated using simulations of four different topologies with applications that control actuators according to sensor values [8]. Figure 22 presents these topolo-gies. Unfortunately, direct comparison is impossible, since [8] did not provide enough detail of the T-RES simulations to allow the embedded cloud to be fitted exactly to the same simulations. However, the same application and topologies can be used to compare the embedded cloud with the in-network processing to a server only logic similar to the T-RES evaluation.

The following assumptions were used for the embedded cloud analysis that was cre-ated using Excel: 1) there is no packet loss, 2) the network is only executing one PDL process on Node 4 that takes the average of the temperature from all four nodes including itself and adjusts the actuator accordingly. 3) the temperature is measured every 5 minutes, 4) each embedded cloud packet is 9 B except the PDL delivery packet, which is 9 B + PDL Process size of 62 B (such a PDL process is given in [P6]). Thus, the packet headers of the protocol stack are not calculated, 5) proto-col stack-related handshaking and communication packets are not considered in this simulation, 6) at the time of 0, the embedded cloud has generated 340 B of initializa-tion data traffic (registrainitializa-tion, service pushing, and service subscripinitializa-tion) whereas the server-only logic is assumed to generate 0 B.

Figure 23 presents the worst case scenario, where the in-network processing re-quires packet routing through the gateway and server. The embedded cloud results in slightly more traffic due to the initial 340 B overhead. The results have a similar form to T-RES.

Figure 24 presents the best case scenario, where Nodes 1, 2, and 3 can send tempera-ture packets directly to Node 4. The in-network processing reduces data traffic

signif-5.2. Embedded Cloud 63

0 10 20 30 40 50 60

0 1000 2000 3000

Network Traffic (KB)

Time (minutes)

Server Logic Only Embedded Cloud

Fig. 23:An analysis of the cumulative network traffic with Topology #0 for the heating con-troller application. This is the worst case scenario for the embedded cloud.

0 10 20 30 40 50 60

0 1000 2000 3000

Network Traffic (KB)

Time (minutes)

Server Logic Only Embedded Cloud

Fig. 24:An analysis of the cumulative network traffic with Topology #3 for the heating con-troller application. This is the best case scenario for the embedded cloud.

icantly, as expected from the related work on in-network processing [8,112,134,170].

Figure 25 presents network traffic at the 3600 minute mark for all of the topologies.

The results are similar to T-RES and show the benefits of in-network processing when the topology is suitable. Unlike T-RES, the embedded cloud can execute a PDL

0 10 20 30 40 50 60

0 1 2 3

Network Traffic (KB)

Topology #

Server Logic Only Embedded Cloud

Fig. 25:An analysis of the cumulative network traffic with all the topologies at the 3600 minute mark for the heating controller application.

process on the embedded cloud infrastructure to ensure the best performance, if the topology is not suitable for efficient in-network processing. Furthermore, the T-RES implementation is heavier due to the python interpreter, which consumes 8 KB of data memory and 45 KB of program memory.

The energy consumption of the presented topologies and network traffic depends on the HW, WSN software and network protocols used. The overhead of running PDL processes is the main factor in the energy consumption in the embedded cloud. The actions of PDL processes are executed every 100 ms [P6]. All PDL actions take less than 1 ms on a PIC18F8722, which consumes 1 mA with 2.0 V supply voltage at a 4 MHz clock speed. Thus, one action of a PDL process takes the maximum of 0.76µJ of energy. This results in ca. 630 J of energy consumed in a year, which is 3.15% of the 20000 J energy budget.

In practice, PDL processes wait for a timer, a trigger, or a get action most of the time. These actions take less than 200µs of execution time [P6]. Thus, the best case energy consumption of one PDL process would be 126 J per year, which is 0.63%

of the 20000 J energy budget. Figure 26 presents the energy consumption of 1 to 50 PDL processes in a year in the worst and best case. The PDL execution can be configured to execute PDL processes with round robin scheduling. Then, each 100 ms iteration executes only one PDL process action. This would limit the energy consumption of PDL execution to between 126 J to 630 J a year, with the drawback of a slower reaction to events.

5.2. Embedded Cloud 65

0 5000 10000 15000 20000 25000 30000 35000

0 10 20 30 40 50

Consumed Energy (J)

Amount of PDL Processes Best Case Worst Case

Fig. 26:The energy consumption of PDL processes in a year for Microchip PIC18F8722.