Measurements of Mobile Blockchain Execution Impact on Smartphone Battery

Abstract

This is a data descriptor paper for a set of the battery output data measurements during the turned on display discharge process caused by the execution of modern mobile blockchain projects on Android devices. The measurements were executed for Proof-of-Work (PoW) and Proof-of-Activity (PoA) consensus algorithms. In this descriptor, we give examples of Samsung Galaxy S9 operation while a broader range of measurements is available in the dataset. Examples provide the data about battery output current, output voltage, temperature, and status. We also show the measurements obtained utilizing short-range (IEEE 802.11n) and cellular (LTE) networks. This paper describes the proposed dataset and the method employed to gather the data. To provide a further understanding of the dataset’s nature, an analysis of the collected data is also briefly presented. This dataset may be of interest to both researchers from information security and human–computer interaction fields and industrial distributed ledger/blockchain developers.

Data Set:https://github.com/yuliabardinova/BCMes

Data Set License: CC-BY

1. Summary

The development of modern Information and Communications Technology (ICT) systems, along with their complexity, pushes an unalterable evolutionary step from conventional centralized systems towards decentralized ones [1]. Presently, many companies are either adopting the distributed operation of their internal systems or agree that the integration would take place in the oncoming years [2].

One of the main paradigms related to the distributed systems operation is laying in the consent of blockchain technology. Historically, blockchain is commonly correlated with the cryptocurrency area due to the public outreach caused by well-known Bitcoin around a decade ago, even though Ralph C. Merkle proposed it in 1979 [3]. However, blockchain is of great interest to many other niches due to its immutability property. These include but are not limited to Distributed Ledger Technology (DLT), supply chain monitoring, intellectual property control, smart energy grids, and many others [4].

One of those fields is particularly related to the operation on resource-constrained devices [5], i.e., sensors, actuators, wearables, and smartphones. The last group is the main focus of this work. The blockchain technology is a potential enabler for different applications executed on personal handheld devices including infrastructure and resource sharing [6,7], exchange of data in untrusted environments [8,9], user incentivization [10,11,12], security and access control [13,14] beyond others.

As a standard practice originated from cryptocurrencies, existing mobile blockchain projects mainly rely on the Proof-of-Work (PoW) consensus algorithm that involves the need to solve complicated computational puzzles as fast as possible [15]. This approach may be potentially harmful to autonomous devices due to natural battery limitations [16], which would be continuously negatively affected by PoW.

Those limitations pushed the developers to a new consensus titled Proof-of-Activity (PoA) [17]. Its main idea implies to involve a group of resource-constrained nodes in verifying the transactions instead of solving the computation puzzle. The blockchain measurements on resource-constrained devices are presently unavailable in the literature to the best of the authors’ knowledge.

The first motivation to generate a new dataset is that, especially while the technology readiness and perspectives levels are already quite high, the behavior that users expect from their handheld devices might not be pleasant from usability perspective in the case of conventional PoW execution [18]. Generally, users would expect the blockchain to either have limited or no impact on their devices’ operation. We were able to highlight that PoW-based systems have a tremendous negative impact on the user-experienced metrics, while the PoA-based solution has one comparable to the messenger application.

The remainder of the paper is as follows. Section 2 describes the dataset. Section 3 describes the methods used to collect data. Section 4 provides an example of the analysis and validation of the data collected.

2. Data Description

It was decided that the best solution for battery metric gathering is a specially developed smartphone application. This option allows us to accurately read the battery status on multiple devices without additional hardware tools. This approach can be used simultaneously on a large number of devices in order to receive the data in a more efficient way.

The developed application was designed to gather the data and then generate the dataset. The dataset consists of JSON files, each containing measurements of available devices’ battery condition. The data was gathered in a span of multiple hours for each device, starting at a maximum charge until fully discharged. Each measurement was taken with a 5-min interval for every device.

The files in the repository are divided into three main groups:

• Reference—the measurements of the device’s discharge with no blockchain application running but with a turned on screen (to make the measurements fair and decrease the observation time);
• PoA—the measurements of the device’s discharge with an active PoA-based blockchain application (ENQ project [19]);
• PoW—the measurements of the device’s discharge with an active PoW-based blockchain application (MIB [20] and uPlexa [21] projects).

The PoW dataset also consists of its subcategories, all named after the selected applications for measurements.

The PoA dataset, besides its main measurements, features an additional measurement done on a cellular link, while every other JSON file provides results executed on Wi-Fi.

Each JSON file contains parameters needed for blockchain application comparison:

• Timestamp—the exact time and date of the measurement;
• Level—the current battery status level, the maximum being 100, in percentage;
• Voltage—the current battery voltage, in mV;
• Temperature—the current battery temperature, in Celsius;
• Minutes from the start—the amount of time elapsed from the first taken measurement, in minutes.

An example of one entry could be found in the following listing:

Listing 1: JSON data representation example

Note, the results for the battery output current are not provided due to the Android API specifics. In particular, the actual output current could not be obtained via the software. The system only calculates it based on the battery capacity and current percentage instead of providing the real values. More details on the battery output current are provided in Section 2.2.

2.1. Environment

The data gathering was executed on devices presented in

Table 1. Selected devices with their corresponding specifications.

Device Model	Android Version	Type	SoC	Processor	RAM	Battery
Samsung Galaxy S9	9.0	Smartphone	Exynos 9810	2.7 GHz Quad-Core Mongoose M3, 1.7 GHz Quad-Core Cortex-A55	4 GB	Li-Ion 3000 mAh
Huawei P8	6.0	Smartphone	HiSilicon Kirin 930	2.0 GHz Quad-Core Cortex-A53, 1.5 GHz Quad-Core Cortex-A53	3 GB	Li-Ion 3400 mAh
Meizu M5c	6.0	Smartphone	Mediatek MT6737	1.3 GHz Quad-Core Cortex-A53	2 GB	Li-Ion 3000 mAh
Xiaomi Redmi 4A	7.1.2	Smartphone	Qualcomm MSM8917 Snapdragon 425	1.4 GHz Quad-Core Cortex-A53	2 GB	Li-Ion 3120 mAh
Xiaomi Redmi 5A	7.1.2	Smartphone	Qualcomm MSM8917 Snapdragon 425	1.4 GHz Quad-Core Cortex-A53	2 GB	Li-Ion 3000 mAh
Lenovo YOGA Tablet 2 8.0	5.1.0	Tablet	Intel Atom Z3745	1.33 GHz Quad-Core	2 GB	Li-Ion 6400 mAh

and Figure 1. Then, a more thorough analysis was performed on a modern smartphone Samsung Galaxy S9. While multiple devices validate the results, the flagship device inspection is needed for a more in-depth showcase of the analyzed data.

The listed devices are of different user markets, forming both economy-class old models and flagship smartphones. Besides smartphones, the list also includes one tablet to broaden the data.

Before the data gathering, all of the devices must have their battery at full charge state. The measurements take place with the devices’ screen constantly turned on in order to unify the test conditions. The test condition unification reduces the possibility of errors in the results because some devices perform vastly different from the turned-off screen due to built-in energy-saving mechanisms. Since the screen operation is one of the most battery-draining activities, it also mimics everyday user involvement with the device, e.g., replying to emails, browsing, or texting.

2.2. Measurement Metrics

The parameters to be gathered are the ones most valuable to user experience, that is, the device’s lifetime during operation and its temperature. Both of these parameters are affected by the blockchain’s high computational load on the device. The impact of this load concerns smartphones since their computational capabilities are limited in comparison to modern PCs.

The required parameters can be obtained through software means. One of Android’s classes includes BatteryManager, which provides methods for access to the battery and charging properties. The properties needed for the analysis consist of battery status, voltage, and temperature. Battery status shows the discharge rate; battery voltage is a controller value meant to demonstrate a more explicit impact on the battery; the temperature is merit important for both battery health and comfortable device use.

The corresponding BatteryManager class values are the following:

• EXTRA_STATUS containing the current battery status constant;
• EXTRA_VOLTAGE containing the current battery voltage level;
• EXTRA_TEMPERATURE containing the current battery temperature.

Interestingly, but the Android API does not provide the access to the battery output current real values through public Android Battery Manager. One way to overcome this issue was by using the os.PowerProfile as (Double) Class.forName(POWER_PROFILE_CLASS).getMethod(“getAveragePower”, java.lang.String.class).invoke(mPowerProfile_, “battery.capacity”) method. However, the results obtained on different smartphones/under different OS versions were incomparable and, sometimes, even zero.

Generally, Android Battery Manager claims to provide the overall battery current value from the API 22 via getBatteryCapacity() function. The recommended way to analyze the current value through the software is to obtain the battery charge percentage with getBatteryPercentage() (also listed in Table 1) and multiply it with the overall battery capacity divided by 100. Based on our analysis, we concluded that providing this data may be misleading for the readers. The appropriate way to get access to the current values is by utilizing the multimeter attached to the device’s battery controller, which does not fall within the software and reproducibility focus of our study.

2.3. Measurement Preparation

The selected mobile device is connected to the power supply until the battery is fully charged. After checking that the battery charge indicator shows the maximum level, the next stage of preparing the device for measurements is performed.

Before the measurement starts, the brightness level of the screen must be set to the maximum value so that each device selected for testing has identical conditions for measurements, which is also done to simulate user activity. The corresponding scenario is further recalled as a reference state.

It is essential to note that when the battery level is low on some mobile devices, the power saving mode is turned on automatically. It is implemented by the manufacturer to extend the device’s usage time. The power-saving mode has a different effect on the measurement depending on the device. In this regard, the power saving function should be turned off.

It is also necessary to pay attention to one more feature that is often found in mobile devices. By default, the device screen turns off after a short period of time for the same purpose specified above, saving battery power to increase battery life. Therefore, it is necessary to explicitly prohibit the screen’s automatic shutdown using a system or additional settings before measuring.

These requirements are meant to emulate the daily operation of the device. One of the main reasons for the rapid discharge of the mobile phone’s battery is precisely the on-screen, which the user interacts with [22]. Therefore, the easiest way to emulate the user’s work with the device is a constantly turned-on screen with a maximum brightness value.

After the above conditions are met, the selected blockchain application is launched on the mobile device. It is necessary to ensure that the device has started to perform work, i.e., carry out activities, ensuring the blockchain functionality. Next, the developed application for recording the battery status is launched.

The overall preparation for the method execution is summarized in Figure 2.

3. Measurement Method

The mobile device is disconnected from the power supply. Using the developed application, the recording of the battery indicators is ready to start.

During the phone’s operation, metrics are read from the battery with the period indicated in the program. Recording continues up to a predetermined charge level. After reaching this level, the readings are saved to a file and recorded on the device. In the final text file with the measurement results, in addition to the described metrics, the record timestamp is also indicated.

The application was developed with the use of Java language for devices running the Android operating system.

The application solves the following tasks:

• Implementation of the basic graphical interface;
• Reading device’s battery metrics;
• Recording results to device memory drive.

A graphical interface is necessary for convenient user interaction with the application. Since assessing the impact of blockchain technology on the device may take a different amount of time, it was essential to add an input field to indicate the threshold value upon reaching which the measurement will stop.

In order to start taking measurements, a button was implemented that the user must click on after setting up the environment. The button is located under the threshold input field to clarify the actions’ sequence after opening the application.

After pressing the button, the measured data to be written to the device memory is displayed below: measurement timestamp, charge level, maximum charge level, voltage, temperature, and time elapsed since the start of the measurements. The block with this data is informational and will be updated at the interval specified in the program. The data display allows the user to understand that the program has, in fact, begun to read battery indicators.

The recording of the battery status is as follows. A timer is created with a specified interval, equal to five minutes by default. Access to variables of the BatteryManager class storing battery data is requested. The contents of the variables that store information about the battery charge, voltage, and temperature of the device are recorded in separate variables. After saving this data, the exact time of taking measurements is separately recorded.

Next, the battery level is checked. If this value is higher than the threshold specified by the user earlier, a function is executed. The function writes the results stored in variables into one temporary variable by concatenation. This temporary variable, whose value will be overwritten each time the measurements are taken, is added by concatenation to the final string variable. After the time interval set by the timer has passed, the procedure is repeated. In order to exit this cycle, it is necessary to obtain a negative result when checking a logical expression comparing the battery charge with a threshold value.

If the battery charge value is less than the user’s threshold, then a message appears stating that the data gathering is completed. The function of recording the obtained results in the device memory is called, and the timer is turned off.

The function of results recording works as follows. A directory is created in the device’s memory in which the resulting file will be saved. Having created an output stream, the program generates an empty file into which the data stream is written, consisting of the final variable with the measurement results. After writing data to a file, the output stream handler clears the buffer and stops its operation. The work of the program is finished.

4. Example Results

We have plotted some example graphs depicting the blockchain impact on the selected device’s battery to represent the gathered data. Representative plots correspond to the data from Samsung S9. The parameters of the device can be found in Table 1. The measurements were carried out using Wi-Fi technology IEEE 802.11n operating at 2.4GHz unless stated otherwise.

As can be observed in Figure 3, the PoA-based ENQ application speeds up the battery discharge only by 5%, while the battery discharge rate is doubled compared to the reference state for PoW-based solutions (MIB and uPlexa) reaching 45%. This difference can be explained by the fact that PoW algorithms are more computationally challenging for smartphones compared to PoA.

Following the point mentioned above, Figure 4 depicts a similar pattern for temperature change. The ENQ-PoA solution has almost no impact on the battery’s temperature, unlike PoW, where the temperature reaches 44 ଌ. This value can cause discomfort while using the device and unintended behavior and even damage to the smartphone.

The graph depicted in Figure 5 indicates that the PoA blockchain application does not affect the battery output voltage of the device when compared to the reference state. It also demonstrates that the voltage drops a lot faster when PoW algorithms are active, which confirms the results derives from Figure 3.

Since the PoA algorithm shows little change in batter parameters, making it a promising one, further measurements involving cellular connection were carried out. The next set of graphs, Figure 6, Figure 7 and Figure 8, represents how the PoA-based application operates when utilizing different wireless technologies.

The graphs show that the cellular LTE technology has more negative impact than Wi-Fi. As explained above, the Wi-Fi impact on the battery level is about 5%; and when using a cellular connection, the discharge rate increases by 20% in comparison to a reference state, see Figure 6. More rapid battery use can also be seen in Figure 8, confirming the statement.

Interestingly, the cellular and Wi-Fi usage has close to no difference in battery temperature change, see Figure 7. Because of the LTE utilization’s little impact, the user can switch to from Wi-Fi to LTE safely unless the battery life impact is crucial for them.

5. Summary

This paper provides the data descriptor of the mobile blockchain execution impact on the smartphone battery. The measurements covered different consensus algorithms and were collected under the use of different wireless technology. The dataset may become a baseline for both academic and industrial researchers developing new distributed systems based on the blockchain technology.

In order to achieve better reproducibility of the results, we have added the code samples to the dataset GitHub repository.