Offloading Scenarios

TreeGlass takes advantages of all devices and entities of the fog platform

where the computing tasks are executed. The wearable device and the cloud are always part involved in computing. If the smartphone is utilized as well, then formally TreeGlass is partitioned in a fog computing platform otherwise TreeGlass is partitioned in a mobile cloud computing platform. Overall, four scenarios are identified and they cover all the possible cases of TreeGlass partitioning over wearable devices, smartphones and the cloud. The scenarios comply with the theoretical model proposed in Section 8.1.2.

Scenario GG-C LOCAL Fig. 9.4 depicts the first scenario, which involves

only two entities: the wearable device and the cloud. This scenario o is called GG-C LOCAL because almost the whole computation effort is carried locally

on the Google Glass. The communication between the two entities is WiFi. The wearable device performs locally the first three tasks of the application (IC, IP, FE) and it sends the resulting data to the cloud. The data sent to

the cloud is a JSON string containing the features extracted from the picture captured by the user. Once the cloud receives this information, it compares the data with the entries in the database and it sends back to the Google Glass another JSON string containing the resulting match or mismatch (task FM).

The final task the wearable device has to complete is to build the received result and display it to the user (task BS).

Scenario GG-C REMOTE The second scenario is very similar to the previous

Gg C IC A IP A FE A A FM BS A

Figure 9.4: Scenario GG-C LOCAL

same and they use the same communication technology as before. This scenario differs from the previous one because the wearable device is only in charge of the input/output operations while all the computation is completely offloaded to the cloud. This scenario is therefore called GG-C REMOTEand

from the computation perspective is at the opposite side of GG-C LOCAL. The

Google Glass only performs the tasks ICand BS providing the input data to

the cloud and displaying the final result to the user. Thus, after the wearable device captures the picture, the whole picture is sent via WiFi to the cloud where tasks IP, FEand FM are executed. The result is then sent back to the

Google Glass using the same technology as the initial communication. The two communications this time exchange the whole picture instead of just a string as in the GG-C LOCALscenario.

Scenario GG-SM-C FOG Fig. 9.6 shows the third scenario. Unlike GG-C

LOCALand GG-C REMOTE, which follow a traditional mobile cloud computing

paradigm, this scenario is an example of fog computing approach. In fact, part of the computation is offloaded close to the user, namely on the smartphone which is the third entity of the fog platform with the wearable device and the cloud.

Similarly to GG-C REMOTE, in this scenario the Google Glass is in charge

of the input/output operations by capturing the input image in task ICand

displaying the final result in task BS. From the point of view of the wearable

device, the computation is completely offloaded like in the GG-C REMOTE

scenario. The wearable device sends via Bluetooth the image captured in task ICto the smartphone. The motivations behind this design choice are the

Gg C IC A A IP A FE A FM BS A

Figure 9.5: Scenario GG-C REMOTE

designed for communications in small operative range; ii) the majority of mobile OS already provide pairing functionalities between smartphones and IoT devices using Bluetooth, iii) the Google Glass can connect to a new WiFi network only if it is not protected by any password. The companion application installed on the smartphone helps the wearable device to connect to a new network protected by a password. Unfortunately, it is not possible to connect the Google Glass to a network that needs credential and this is the case where the smartphone is needed to connect the wearable device to the network using the latter as relay.

Once the information reaches the smartphone, it can proceed and reach the cloud via cellular technology or through WiFi according to the theoretical model proposed in Section 8.1.2. First, for practical reasons, WiFi technology is simpler to adopt and to profile and assess its energy consumption. The smartphone performs some preliminary computation on the received image and executes tasks IP and FEbefore involving the cloud. The smartphone

and the cloud communicate trough WiFi and, as in scenario GG-C LOCAL,

the exchanged data is a string containing the featured extracted by the smartphone. The cloud always executes task FMand it sends back the result

to the smartphone as string with the same communication technology. The final result (task BS) has to be displayed by the Google Glass because of the

direct interaction with the user. Thus the smartphone sends via Bluetooth the resulting image which the wearable device has to display with task BS

at the end. Finally the smartphone is only in charge of forwarding the final result to the wearable device.

Gg Sm C IC A A A IP A A FE A A A FM A ... A BS A A Figure 9.6: Scenario GG-SM-C FOG

Scenario GG-SM-C RELAY Fig. 9.7 depicts the fourth and last scenario,

where the entities and the communications technologies are the same of the GG-SM-C FOGscenario. Consequently, the GG-SM-C RELAYis also an example

of fog computing approach. In this scenario, the smartphone is only used for communication purposes and the computation is completely offloaded to the cloud. As a result, in GG-SM-C FOGscenario the computing capabilities of

the fog are utilized while GG-SM-C RELAYuses its communication potential.

The smartphone, indeed, behaves as relay for the Google Glass by redirecting the received data from the wearable device to the cloud and vice versa when the cloud makes available the result. The Google Glass execute input/output related tasks such as tasks ICand BS. Communications are performed again

using Bluetooth technology with the smartphone and the exchanged data is the raw input image (output of task IC), and the result given from the cloud

(input of task BS). The smartphone, after having received the data from the

Google Glass, immediately sends the image to the cloud via WiFi with no additional operations than the preparation of data needed to manipulate the stream coming from the Bluetooth communication stack and redirect it to the WiFi communication stream. Thus, the cloud is in charge of performing the tasks IP, FEand FM. After successful execution of FM, the cloud sends

back to the Google Glass the result, using the smartphone as relay in the opposite communication order of the beginning. Fig. 9.7 shows two blank spaces left in correspondence of the smartphone column. They represent the operations that the smartphone does in order to forward the data between wearable device and the cloud. It is not a unique arrow because between the

Gg Sm C IC A A A ... A A A IP A A FE A A FM A ... A BS A A

Figure 9.7: Scenario GG-SM-C RELAY

two communication there are small operations performed by the smartphone so it is not immediate forwarding.

9.2 Evaluation