Avoiding Unnecessary 3G Data Transmission Through Mobile Sensors

Institutionen för datavetenskap

Department of Computer and Information Science

Examensarbete

Avoiding Unnecessary 3G Data Transmission

Through Mobile Sensors

av

William Danielsson och Sebastian Waldmann

LIU-IDA/LITH-EX-G--14/086--SE

2014-12-02

Linköpings universitet Institutionen för datavetenskap

Examensarbete

Avoiding Unnecessary 3G Data Transmission

Through Mobile Sensors

av

William Danielsson och Sebastian Waldmann

LIU-IDA/LITH-EX-G--14/086--SE

2014-12-02

Handledare: Simin Nadjm-Tehrani och Ekhiotz Jon Vergara Examinator: Nahid Shahmehri

Students in the 5 year Information Technology program complete a semester-long software development project during their sixth semester (third year). The project is completed in mid-sized groups, and the students implement a mobile application intended to be used in a multi-actor setting, currently a search and rescue scenario. In parallel they study several topics relevant to the technical and ethical considerations in the project. The project culmi-nates by demonstrating a working product and a written report documenting the results of the practical development process including requirements elic-itation. During the final stage of the semester, students create small groups and specialise in one topic, resulting in a bachelor thesis. The current re-port represents the results obtained during this specialization work. Hence, the thesis should be viewed as part of a larger body of work required to pass the semester, including the conditions and requirements for a bachelor thesis.

Abstract

In recent years, instant messaging (IM) has started to replace short message service (SMS) in communication. IM offers more functionality but there is a great downside. IM demands more power and drains the mobile device battery faster. This paper shows the energy consumption of IM when the user is not using the application and how the consumption can be reduced by enabling mobile sensors and sending fewer packets by the application. We began by investigating the various sensors that are supported by mobile devices. With the retrieved vendor information, we evaluated the different sensors and chose two sensors, light sensor and proximity sensor in order to study their use for reduction of energy in an instant messaging scenario. These two sensors can together estimate if the mobile device is placed in the pocket of the user. The development of a simple IM application was completed and sensors were used to create an extension to the application. The extension would lengthen the interval between the updates of the au-tomatic update function when the mobile was inactive, reducing the energy consumption.

Two types of tests were performed. The first test evaluated if the extension would correctly deduce that the mobile device was placed inside a pocket. The mobile device with the pocket-aware application was used in different common situations and the tests showed that the extension made a cor-rect computation in seven of nine situations. The faulty situations were when the mobile device is placed with the screen faced down to a surface. The second test compared the energy consumed by a pocket-aware appli-cation compared to a mobile device without our extension. Based on the results that we retrieved, we estimated that during a one minute period the pocket-aware application with an update interval of ten seconds could save on average 12% and could save on average 62% when the update interval was increased to fifteen seconds.

Contents

1 Introduction 1

1.1 Problem Definition . . . 2

1.2 Methodology . . . 2

2 Background 4 2.1 Radio Resource Control . . . 4

2.2 IM-application . . . 5

2.3 PowerTutor2 . . . 6

3 Sensors in mobile devices 8 3.1 Accelerometer . . . 8

3.2 Gravity sensor . . . 9

3.3 Gyroscope . . . 9

3.4 Light sensor . . . 9

3.5 Linear acceleration sensor . . . 9

3.6 Magnetic field sensor . . . 10

3.7 Orientation sensor . . . 10

3.8 Pressure sensor . . . 10

3.9 Proximity sensor . . . 10

3.10 Rotation vector sensor . . . 11

3.11 Temperature sensor . . . 11

4 Combining sensors and IM 12 4.1 Evaluation of sensors . . . 12

4.2 Proximity problem . . . 13

4.3 Sensors combined with application . . . 13

5 Results 15 5.1 Testing the pocket-aware extension . . . 15

5.2 Quantifying the energy saving . . . 16

6 Conclusion 20

Chapter 1

Introduction

This thesis was done in parallel to two other projects where we created an application for the police and one for the health care. These applications were designed to help the two types of first responders during a crisis situa-tion where there would be a shortage of network access and battery charging possibilities. Since we were a part of two different project groups, this thesis was done separately from the other two.

However, our thesis results in a solution which could be used in the appli-cations from both projects. Our extension studies the problem of reducing the power consumption of the application which is very important in a crisis situation. By allowing the units in the field to have an application which could be used for a longer time, they could help more civilians before they would need to recharge their mobile devices.

The usage of smartphones has increased rapidly and 45% of smartphone owners use IM. IM is a fast and easy way to communicate where the ap-plication sends the messages in small packets via a cellular network, often the third or fourth generation. However, the energy consumption of IM is quite high due to data transmission and the frequent use of IM contributes to drain the battery from the mobile devices. Despite the fact that the users are discontent with the life time of their batteries, IM has commenced to replace SMS [11].

IM offers more functionality than SMS: the user can participate in a con-versation with another user or even a whole group, the user can see when the other participant is typing and the user can even get notifications if the other participant has received or read the message. But as stated earlier, these functions consume more energy and even though this displeases the user, he or she continues to use the IM application. The easiest way to be more energy-efficient would be to remove the non-primary functions in the application. However, it is these functions that contributes to users choosing IM instead of SMS. An obvious thing that we could optimise is the energy

1.1. PROBLEM DEFINITION CHAPTER 1. INTRODUCTION

consumption when the mobile device is inactive.

1.1

Problem Definition

This thesis focuses on whether sensors in our mobile device can help IM ap-plications in lowering the transmission energy footprint by identifying when the IM application is no longer in use by the user.

There are many different contexts where the device is not in use and there-fore we had to limit our work. We chose to examine how the energy con-sumption of IM applications can be reduced when the device is located in the pocket of the user. In this case, the user has chosen to not be active on the application and energy can therefore be saved with no impact on the quality of the service.

1.2

Methodology

To be able to use the built-in sensors in the mobile devices, we needed to know which sensors could be accessed. By considering every sensor avail-able, these could be compared with each other and we would be able to decide which sensors can be used to detect whether the IM application is no longer in use.

The next step was to obtain an IM application. We took over the develop-ment of an unfinished application named UltraApp, an application which only had an operating connection to a database. Later, we investigated which energy consuming function in the application we could modify during the time which the mobile device is located in the pocket.

With this knowledge, we were able to integrate the use of our selected sen-sors into the Android application and modify the energy draining func-tions which have been located. Our solution was subsequently tested using PowerTutor2[16] and the results were compared to the results of the appli-cation without our extension.

Test Messages

We predefined a conversation between two mobile devices that was used to test our pocket-aware application. The conversations were a monologue, meaning only one user was writing while the other user’s mobile device was located in the pocket. The conversation is short and has six small messages sent.

In table 1, the conversation is presented with timestamp and the content of the message.

1.2. METHODOLOGY CHAPTER 1. INTRODUCTION

Time Message 0:05 Hi

0:18 How are you? 0:29 Are you there? 0:42 I have to go. 0:50 Call me! 0:58 Bye!

Table 1.1: Test conversation

Examined Sensors

The extension which was created uses two sensors, the light sensor and the proximity sensors. The hypothesis is that these two sensors combined can estimate that the mobile device is indeed placed in a pocket. The light sensor will detect that there is no light and the proximity sensor will detect that it is placed close to another object. If these two values are returned at the same time, the extension will know that the mobile device is inactive.

Chapter 2

Background

Below, necessary information on how the energy consumption of instant messaging via 3G works is provided. It will also describe the tool which was used and the application which was created for this project in more detail.

2.1

Radio Resource Control

The Radio Resource Control (RRC) protocol layer exists in the user equip-ment (UE) and the base station. The RRC implements different states where each state has different performance and energy consumption and it is the base station which decides the state of the UE. The RRC idle mode has the lowest consumption and is active when the device has no connec-tion. The other UE states are active when the device is using the Paging Channel (CELL PCH), the Forward Access Channel (CELL FACH) and the Dedicated Channel (CELL DCH), sorted from the lowest to the highest in performance and energy consumption[9].

When the UE is in the PCH state, it can not transmit any data and if there are packets that need to be sent or retrieved by the UE, it will be moved from the PCH to the FACH. The UE can now transmit data with a low performance (low data rate and high response time) but low energy consumption. However, if the threshold for FACH is exceeded (the buffer occupation is greater than the maximum limit for FACH) the UE can move from FACH to DCH in order to gain a higher performance. This state will have the highest data rate and lowest response time but will also contribute with a high energy consumption[6][8].

When all the data has been transmitted, the UE will not need to be in the DCH state. After an interval T1 (most common value is approximately five

2.2. IM-APPLICATION CHAPTER 2. BACKGROUND

seconds) with no transmissions, the UE will be moved down to the FACH and obtain a lower consumption and performance. If the UE would once again exceed the threshold, it will be moved up to the DCH. After an interval T2 (most common value is approximately five seconds) with no transmis-sions, the UE will be moved down to the PCH state. This will not allow any transmissions and will have the lowest energy consumption level among the RRC states[10][12].

Figure 2.1: Simple image of the different states which RRC can manage.

2.2

IM-application

IM applications are a form of online chat which offer real-time text trans-missions over the Internet or other networks. What separates IM from other communication services is the psuedo real-time transmissions. When the user sends the message from the device it arrives almost instantly at the receiver who can then respond at once. A lot of IM applications al-low the user to communicate with several people at once and enable typing notifications[14].

To be able to test our solution, an IM application UltraApp, which is based on a work from Henning Hall, was created. His previous work granted us the usage of his server and database but still needed a client side of the application which could send and retrieve messages from another user. The

2.3. POWERTUTOR2 CHAPTER 2. BACKGROUND

reason this application was chosen was due to its simple structure and well-documented code.

The other IM applications which we considered using were Telegram[4] and an application created by Simon Andersson in his thesis[5]. The reason why these two were not used was due to their complicated and non-documented code. We never fully understood the code and therefore chose to focus on the other parts of the project.

2.3

PowerTutor2

PowerTutor2 is an application for Android phones and a powerful tool to measure the power consumption of the major components display, CPU and cellular interface in different applications[16].

Each hardware component in a smartphone has a couple of power states that influences the phone’s power consumption. For example, CPU has CPU utilisation and frequency level and OLED/LCD has brightness levels. The power model in PowerTutor is constructed by correlating the measured power consumption with these hardware power states of every running ap-plication. The power usage is calculated as if it was the only application running and the reason for this is that two applications that are running at the same time can cause hardware components to transition into states they would not otherwise be in. Due to this, we can be assured that the results of the cellular energy consumption are not influenced by another application. The consumption is calculated by measuring the voltage of the lithium-ion battery in the mobile device since the voltage changes during discharge. However, the discharge curves of different batteries may vary and PowerTu-tor2 needs to approximate the curve for each battery to a linear curve. The discharge curve may vary with temperature and to eliminate the effect of the external factors, the characterisation is recommended to be conducted at room temperature. In this environment, the average variance of the dis-charge curve for a typical modern battery is 4.3%.

Furthermore, there can also be a significant difference in power models for cellular interface of two mobile devices. The variety will have an impact on measuring the power consumption of 3G. Due to the variances between different mobile devices, the experiments should be conducted at the same time and place, with the same mobile device and in room temperature. The power consumption of the transmission varies between different opera-tors and the studies were performed with the standard setting of Powertutor. In our case Powertutor will handle our operator as an unknown operator and will therefore return the worst case scenario when it comes to the power needed for the different RRC states. This means that the numbers in the results are meaningless in themselves, but the proportions are reasonable approximations.

be-2.3. POWERTUTOR2 CHAPTER 2. BACKGROUND

cause it is a very simple application to use. Initially we thought of using EnergyBox but that meant that we had to adapt our application to a specific tool, such as EnergyBox, that need a certain input. Furthermore, Energy-Box does not operate on Windows, the only operative system that we had. Due to the use of Powertutor, it was easy to perform the studies and the results were returned in both numbers and graphics.

Chapter 3

Sensors in mobile

devices

Most of the Android devices have built-in sensors that measure motion, orientation and various environmental conditions. We used different mobile devices to obtain information about the different sensors that exist in each device. Elixir2[2] collects information about the sensors that the device supports and displays the consumption of each sensor when in use. By obtaining the name of a sensor through Elixir2, we were able to find the information about the sensor in the Android developer sensor section[1]. The values below are from a Samsung Galaxy S4 since that is the phone which was used during our tests. To provide a better context for the values of the sensors we give below, the Samsung Galaxy S4 has a battery capacity of 9.88 Wh[3].

3.1

Accelerometer

The accelerometer used in Samsung’s mobile devices is called MPL Ac-celerometer and measures the acceleration force that is applied in all three axes. This sensor in commonly used to detect motions as shake or tilt. The MPL accelerometer has a resolution of 0.038344003 m/s2, a maximum range of 19.6133 m/s2 and a minimum delay of 10 ms. When the MPL Accelerometer is in use, it consumes on average 0.5282 mW [1][2].

3.2. GRAVITY SENSORCHAPTER 3. SENSORS IN MOBILE DEVICES

3.2

Gravity sensor

Whereas the MPL Accelerometer returns the sum of all forces applied on the mobile device, the MPL Gravity only returns the influence of gravity. The gravity sensor is a hardware type but can be created from the accelerometer by extracting the gravity sensor values. The MPL Gravity has the same res-olution, range and delay as the accelerometer however the gravity consumes on average 38.9082 mW [1][2].

3.3

Gyroscope

The MPL Gyroscope is a sensor that measures the device’s rate of rotation in rad/s around each of the three physical axes. The resolution of MPL Gy-roscope is 0.57246757 rad/sec, the maximum range is 34.90656 rad/sec and the minimum delay is 10 ms. When the MPL Gyroscope is in use, it con-sumes on average 23.18 mW [1][2]. In some areas, both the gyroscope and the accelerometer can be used to accomplish the same result and in such cases, the accelerometer is preferred due its low energy consumption[1][2].

3.4

Light sensor

The light sensor used in Android mobile devices is GP2A Light sensor and measures the ambient light level in lux. The sensor is placed on top of the screen, left to camera and is commonly used to control the brightness of the screen. The GP2A Light sensor has a resolution of 1 lux and a maximum range of 646240 lux, which is the brightest level of illumination currently available from any slit lamp. The GP2A Light sensor’s delay is only when the data changes and it consumes on average 2.812 mW [1][2].

3.5

Linear acceleration sensor

The Linear Acceleration Sensor is created by Google Inc. and is very similar to the accelerometer. The Linear Acceleration Sensor measures the accel-eration force that is applied to the mobile device in all three axes but it excludes the force of gravity. The Linear Acceleration Sensor has a res-olution of 0.0047884034 m/s2, a maximum range of 19.6133 m/s2 and a minimum delay of 15 ms. When the sensor is in use, it consumes on average 0.95 mW [1][2].

3.6. MAGNETIC FIELD SENSORCHAPTER 3. SENSORS IN MOBILE DEVICES

3.6

Magnetic field sensor

Mobile devices also contain a magnetic field sensor called MPL Magnetic Field which measures the ambient geomagnetic field of all three physical axes. The MPL Magnetic Field is most commonly used in creating a compass and can determine the direction of the mobile device. The magnetic sensor has a resolution of 0.012 µs and a maximum range of 2000 µs. The minimum delay is 30 ms and the consumption is on average 22.8 mW [1][2].

3.7

Orientation sensor

Mobile devices contain an orientation sensor called the MPL Orientation that measures degrees of rotation that a device makes around all three physical axes. As of Android API level 3 you can obtain the values that the orientation sensor returns by combining the gravity sensor with the ge-omagnetic field sensor in conjunction with the getRotaionMatrix() method. The MPL Orientation has a resolution of 0.015625◦ and with a maximum range of 360 ◦. The minimum delay is 30 ms and the sensor consumes on average 29.64 mW during its use[1][2].

3.8

Pressure sensor

The pressure sensor in the mobile devices measures the ambient air pressure in hP a. The pressure sensor is used to calculate the position of the device in terms of altitude which contributes to more accurate positioning. The pressure sensor has a resolution of 0.01 hP a and a maximum range of 1100 hP a. The minimum delay is 20 ms and the energy consumption is on average 2.5688 mW [1][2].

3.9

Proximity sensor

The proximity sensor used in the mobile devices is the GP2A Proximity sensor which measures the proximity of an object relative to the view screen of a device. This sensor is typically used to determine whether a handset is being held up to a person’s ear. The proximity sensor returns two different values, far or near. If the object is within 5 cm of the sensor it returns near, otherwise it returns far. The only delay of the proximity sensor is when the data changes. The GP2A Proximity sensor consumes on average 2.85 mW [1][2].

3.10. ROTATION VECTOR SENSORCHAPTER 3. SENSORS IN MOBILE DEVICES

3.10

Rotation vector sensor

The rotation vector sensor used in the mobile devices is created by Google Inc. and measures the orientation of a device by providing the three el-ements of the device’s rotation vector. The rotation vector sensor has a resolution of 1E-8, a maximum range of 1 and a minimum delay of 10 ms. The energy consumption when the rotation vector is in use is on average 38.9082 mW [1][2].

3.11

Temperature sensor

Some mobile devices are equipped with a temperature sensor that measures the temperature of the device in degrees Celsius and in the Android API level 14, the temperature sensor was replaced with an ambient temperature sensor. This new sensor has a resolution of 0.1◦C and a maximum range of 165◦C. The minimum delay between two events is 1 second and the ambient temperature sensor consumes on average 1.14 mW [1][2].

Sensor name Sample rate Average power consumption Accelerometer 10 ms 0.5282 mW

Gravity sensor 10 ms 38.9082 mW Gyroscope 10 ms 23.18 mW Light sensor None 2.812 mW Linear acceleration sensor 15 ms 0.95 mW Magnetic field sensor 30 ms 22.8 mW Orientation sensor 30 ms 29.64 mW Pressure sensor 20 ms 2.5688 mW Proximity sensor None 2.85 mW Rotation vector sensor 10 ms 38.9082 mW Temperature sensor 1000 ms 1.14 mW

Table 3.1: Summary of available sensors on a typical mobile device Table 2 summarises the potential sensors available to a typical mobile device and the next chapter describes how the sensors were compared to each other. It also describes which sensors that were chosen and the reason for choosing them.

Chapter 4

Combining sensors and

IM

The general idea of our solution is to add an extension to the UltraApp application which will be able to detect if the mobile device is placed in a pocket. The pocket-aware application will use sensors to detect when the mobile device is placed in a pocket and will deactivate certain functions which are not necessary to be running when the device is inactive.

4.1

Evaluation of sensors

There are a lot of different sensors that are available to us but there is only two which were used to indicate that the mobile device was placed inside a pocket and this text explains which sensors and the reason for choosing them.

The accelerometer, gravity sensor and the linear acceleration sensors mea-sure acceleration force. This can be used to estimate if the user is performing a motion when the mobile device is being placed in a pocket. However, this motion is a common motion and is used in other contexts too. If one of these sensors would be used, it would be the accelerometer which consumes substantially less energy but it does not provide us with the information which we need[13].

The gyroscope measures the rate of rotation and is therefore not relevant to our project since a rotation is a very common movement and the rotation sensor is also indecisive since the rotation sensor can also show changing values when in the pocket.

The magnetic field sensor, orientation sensor, and pressure sensor are sen-sors that are primarily used in navigation and neither of them can supply

4.2. PROXIMITY PROBLEMCHAPTER 4. COMBINING SENSORS AND IM

us with information that would confirm that the mobile device is located in a pocket.

Finally two sensors remain, the light sensor and the proximity sensor. The light sensor can provide us with information that the mobile device is in a dark place, for example a pocket. With an energy consumption of only 2.812 mW this sensor is a good choice but in the night, the illumination is low which can result in the application believing that the mobile device is placed in a pocket when in fact it is outside. The proximity sensor can provide us with the information that the mobile is placed close to an object, for example in a pocket, by returning the value near. However if the user is talking to someone over the phone, the application should not believe that the mobile is in the pocket. This is because we do not want the applica-tion to deactivate certain funcapplica-tions since the user may want to receive chats while he or she is talking over the phone.

Our hypothesis is that by combining the light sensor and the proximity sen-sor, the application can retrieve enough information to accurately estimate that the mobile device is placed inside a pocket. If the user is using the mobile device in a dark room, the light sensor will return that the device is in a pocket but the proximity sensor will tell us it is not. When the device is finally placed inside a pocket, since the illumination will be non-existent and the device will be close to the pants, this results in both sensors believing that the device is placed inside a pocket.

4.2

Proximity problem

When the extension was created using the light and proximity sensor, it was clear that there would be a problem when the mobile device was held towards the head. This was important since when the user is talking over the phone, the mobile device is pressed against the head which results in the proximity sensor to return the value near and the light sensor will be covered, resulting in a low value of lux. This would result in the application believing that the device was placed in a pocket.

This problem was solved by using the AudioManager in Android and imple-menting a listener on the InCall − M ODE which is a constant that receives a value if the device is in a audio call. By doing this the application could now check if the user is calling or if the mobile device is likely to be placed inside the pocket.

4.3

Sensors combined with application

As mentioned in section 2.2, we chose to continue the development of

4.3. SENSORS COMBINED WITH APPLICATIONCHAPTER 4. COMBINING SENSORS AND IM

to send the written text to the Structured Query Language (SQL) database which already had been created by Henning Hall and stores the data. The application were given an update function that automatically searches for new messages in an interval T which by default is 2 seconds. IM is supposed to be a fast way to communicate, and with an application that is updated every two seconds, the user knows that the messages are up to date. If there is a new unread message, the application will retrieve the message through JavaScript Object Notation (JSON), save the message in a local text file and post the message in the message log. All in all the application code base was increased from 323 lines of code to 517 lines of code.

UltraApp has an update-function that, every interval T , calls the database to look for unread messages. Since the interval T is by default 2 seconds, this automatic update-function will constantly keep the application in the Dedicated Channel which will grant a high performance in data rate but will have a high energy consumption.

The light and proximity sensor were applied by implementing the Android SensorEventListener [15]. Then a SensorManager was created to be able to find the light and proximity sensor and to keep them separated from each other. The values from each sensor were retrieved by adding a Sen-sorEventListener who tracks if the value of a specific sensor is changing. When the value changes, we check if it is a value which are of interest to us. The interesting values are if the light value is 0 and if the proximity value is near. If the light sensor returns 0, we have a boolean named isLigh-tAchieved which we then assign the value true and if the proximity returns the value near we have a boolean named isProximityAchieved which we as-sign the value true. By combining these two booleans with the boolean that indicates if there is a call, one can create a function that computes that the mobile device is placed inside a pocket and can therefore deactivate unnec-essary functions.

In this case when the mobile device is placed in the pocket, the update func-tion is called every ten seconds since the user has no need to look for new messages so often. The code snippet in Figure 1 describes the logic. This will result in the UE to leave the Dedicated Channel since there are no data sent from the mobile device.

if(isLightAchieved == true && isProximityAchieved == true && isPhoneInCall == false){

autoUpdate(10); }else{

autoUpdate(2); }

Chapter 5

Results

This section will evaluate if the extension computes if the device is placed in-side a pocket and will also measure how much power consumption is reduced due to the deduction in correct cases.

5.1

Testing the pocket-aware extension

To test our extension, we performed a test where we used the values from the light and proximity sensor to investigate if the extension would correctly deduce that the mobile device was placed inside a pocket. We tried different common placements for a mobile device and the application printed the values of the booleans that can be seen in Figure 1 to a local file. By doing this, we could analyse if the extension would be triggered.

As can be seen in Table 3, the extension does not work fully as intended since situation 5 and 9 computes that the device is placed inside a pocket. The problem is that the extension is triggered when the screen is faced down. Situation 7, where the mobile device is outdoors with the screen faced down, does not trigger the extension due to the high values of lux that are illuminated from the sun. However, in situation 5 and 9 where the screen is faced down this will not be the case. The extension should not be triggered when the screen is faced down but it is hard, if not impossible, to manage this situation with the sensors that exist. The orientation sensor could be used to determine that the mobile device is placed on a flat surface and therefore it could be placed on a table. However, the same values from that sensor could be returned if the device was placed inside a pocket that is parallel to the floor.

5.2. QUANTIFYING THE ENERGY SAVING CHAPTER 5. RESULTS

Situation Sensors triggered Pocket-mode 1 In pocket Light, Proximity Yes

2 In pocket, thin clothes Light, Proximity Yes 3 In call Light, Proximity No 4 On table, indoors, screen up None No 5 On table, indoors, screen down Light, Proximity Yes 6 On table, outdoors, screen up None No 7 On table, outdoors, screen down Proximity No 8 Dark room, screen up Light No 9 Dark room, screen down Light, Proximity Yes

Table 5.1: Summary of tested situations. In lines one and two we expect the pocket mode deduction be ”Yes” and in the rest of the lines we expect the pocket mode deduction to be ”No”.

In situation 3, where the user is in call, both the sensors are triggered but the extension does not enter pocket-mode. This was intended and is a correct deduction.

5.2

Quantifying the energy saving

In this section we will cover the results of our experiments when the energy consumption of the original and the modified application was tested. Obvi-ously a redcution of consumption is possible if a correct deduction is made. The predefined conversation in section 1.2.1 was used as a guide for the experiment. Since the application has no support for automatic input, the messages were sent manually. The results were presented by PowerTutor2 which is describes in section 2.3 and the energy consumption of the sensors that were used in the extension has been added to the results.

Figure 2 shows the mean energy consumption of the two versions of the ap-plication during the time of the short conversation. The mean is calculated from five runs of the same experiment and where the consumption of the sensors (5,662 mW ) has been added.

5.2. QUANTIFYING THE ENERGY SAVING CHAPTER 5. RESULTS

Figure 5.1: The average power consumption of the two versions during the interval of the test.

Figure 2 clearly shows the reduction of the energy footprint for one simple conversation due to the integration of the two sensors. The reason why the extension was able to reduce the consumption was because the application required less power to retrieve data. When the mobile device was emulated to be placed in a pocket, the extension triggered the automatic update function to run every ten seconds instead of two which is default. This resulted in the mobile device not searching for new messages and accessing an Internet connection every two seconds, a connection which would constantly keep the UE in the Dedicated Chanel. The transmission energy footprint of the application without the extension can be seen in Figure 3.

Figure 5.2: The power consumption of the application without the extension from one run of the first experiment.

The UE was constantly kept in the highest energy consumption mode, the Dedicated Channel, as can be seen in Figure 3. However, when the extension is activated and the automatic update function is called every ten seconds

5.2. QUANTIFYING THE ENERGY SAVING CHAPTER 5. RESULTS

instead, the UE will leave the energy consuming DCH and access the For-ward Access Channel between the updates. When the update function is called, the UE will enter the DCH to retrieve the data and when the data has been gathered, the UE will leave the DCH and access the FACH since there will be an interval with no transmission.

Figure 5.3: The power consumption of the pocket-aware application from one run of the first experiment.

To further study the pocket-aware application we did another test where we increased the interval between the updates to fifteen seconds. This test was made to see how a small difference in update time (from ten seconds to fifteen seconds) would impact the RRC states and the energy footprint. As shown in Figure 5, the power consumption is dramatically reduced. When the time of update is increased to fifteen seconds, the UE will initially enter the Forward Access Channel to retrieve the latest messages. However, since the device will not require a connection between the updates, the UE will leave the FACH and enter the Paging Channel. In this state the UE can not conduct any data but when the update function is called, the UE will be moved to the FACH. Since it is only the low energy consuming PCH and FACH that are entered, the application reduces the energy footprint dra-matically. The energy consumption from the transmission and the different states can be seen in Figure 6.

5.2. QUANTIFYING THE ENERGY SAVING CHAPTER 5. RESULTS

Figure 5.4: The average power consumption of the application with an in-creased time of update in the second experiment.

Figure 5.5: The power consumption of the pocket-aware application from one run of the second experiment (with increased time of update).

Chapter 6

Conclusion

Based on the limited study that we have performed, using sensors in mobile devices to reduce the energy consumption can have a positive impact on any application. For example an IM application has no need to be in its default mode when it is not in use. However, since different applications operate in different ways, there are different ways of implementing a similar solution. There are, as stated in chapter 3, several sensors in modern mobile devices that can be integrated into any application. Some of them might not be ben-eficial for energy reduction when they are used one-by-one since they might not contribute with enough information. However, when some of them are combined, they may turn out to be very useful.

In our case, there was an update function which could be triggered to ob-tain new messages less frequently when the mobile device is placed inside the pocket. This was just an example of how this solution could be used and another option would be to simply disable the update function. However, this would force the user to pick up the mobile device from the pocket when he or she want to receive messages. Furthermore, since the extension can not flawlessly compute if the mobile device is placed inside a pocket, the user would not receive any messages when the device is placed with the screen down.

The extension shows the potential of avoiding draining the battery in an un-necessary context. By doing this, there was no need to limit the application by removing the non-primary functions. This can be functions as notifica-tions when the other user is typing, funcnotifica-tions which the user appreciates in an IM application. This would contribute to a longer battery life and more satisfied users.

Chapter 7

Discussion

The application which was created to conduct our tests on is not an ”intelli-gent” application. The fact that the version without the extension consumed 565 mW shows that this is the case and therefore it would be possible to reduce the energy consumption for the base application itself. The update-function of UltraApp checks for new messages in an interval of 2 seconds but a more advanced application would only update if there was a new message on the server. Even if the ”smarter” applications would consume less energy by only updating when there was a new message incoming, this function could also be altered when the phone is inactive. Other applica-tions also support notificaapplica-tions if the other user was typing which could be disabled when the mobile was in the pocket since the user has no use for that function. To sum up, even if our application may consume more energy than a more intelligent one, the extension would still be able to save battery but perhaps not by the same proportion.

A drawback in the current version of the extension is that it is hard to know whether or not the mobile device is placed inside a pocket. The application would believe that it is placed inside a pocket when the device is placed on a table with the screen faced down since the light will not reach the sensor. This would result in unplanned saving and a loss in application functional-ity since the user can by mistake place the mobile device with the screen down and would therefore, unknowingly, receive messages less frequently. As mentioned earlier, this is a difficult problem and can not be solved with the sensors that are supported by today’s mobile devices. However, if there were to be added another proximity sensor on the back of the mobile device it would solve the problem. This would allow us to check if both proximity sensors are triggered which would contribute to a more accurate evaluation of whether the mobile device is placed inside a pocket.

There was also very little time for us to conduct more experiments with dif-ferent values of the interval between the updates and difdif-ferent conversations.

CHAPTER 7. DISCUSSION

It would have been useful to perform more trials with different parameters. Energy conservation is something that is always on the table and with the increased usage of IM applications we believe that the implementation of sensors can reduce energy consumption in the future. There are a lot of different functions in an IM application that can, combined with sensor, be enhanced. Since the energy consumption of sensors is low, see the compari-son in section 3, a lot of battery drainage can be prevented.

Sensors can not only be used to save energy for IM. Using the technique of sensors you could activate or deactivate different functions for almost every mobile application which would result in reducing battery drainage. The new mobile devices use sensors to some extent, the proximity sensor is used to turn the screen off when held against something and the light sensor is used to adjust the background light of the screen. There are also some ap-plications which use sensors to see if the mobile device is placed in a pocket but instead of reducing the energy cost, they increase the volume of the device. In this way, it is easier for the user to hear the phone when it is placed in a pocket.

If we were to continue our studies we would create an application which would control the Internet connection for the mobile device and operate in a similar way as our extension. If this were to be possible you could use sensors to reduce the consumption for the entire mobile device and not only for a specific application.

Bibliography

[1] Android Sensor Overview. http://developer.android.com/guide/ top-ics/sensors/sensorsOverview.html. Accessed: 2014-08-25.

[2] Elixir2 - Sensor information. https://play.google.com/store/apps/ de-tails?id=com.bartat.android.elixir. Accessed: 2014-08-25.

[3] Samsung S4 Standard Battery. http://ziyang.eecs.umich.edu/ projects/powertutor/. Accessed: 2014-04-24.

[4] Telegram. https://telegram.org/apps. Accessed: 2014-08-25.

[5] S. Andersson. Energy Consumption of 3G Trans-missions for Instant Messaging on Mobile Devices. http://urn.kb.se/resolve?urn=urn:nbn:se:liu:diva-92756. ISRN: LIU-IDA/LITH-EX-G–13/009–SE. Link¨oping University. 2013.

[6] S. Antipolis. Universal Mobile Telecommunications System (UMTS); RRC Protocol Specification, V. 8.14.0. 2001-06.

[7] D. Crockford. The application/json Media Type for JavaScript Object Notation (JSON) rfc. http://tools.ietf.org/html/rfc4627, 2006.

[8] B. Furht and S. A. Ahson. Long Term Evaluation of 3GPP LTE Radio and Cellular Technology. CRC Press, 2009.

[9] H. Kaaranen, A. A. ad Lauri Laitinen, S. Naghian, and V. Niemi. UMTS NETWORKS: Architecture, Mobility and Services. Wiley, 2005. [10] F. Liers and A. Mitschele-Thiel. UMTS data capacity improvements employing dynamic RRC timeouts. In Personal, Indoor and Mobile Ra-dio Communications. PIMRC 2005. IEEE 16th International Sympo-sium. 2005.

[11] S.-M. Pi, Y.-C. Liu, T.-Y. Chen, and S.-H. Li. The Influence of Instant Messaging Usage Behavior on Organizational Communication Satisfac-tion. In HICSS ’08 Proceedings of the Proceedings of the 41st Annual Hawaii International Conference on System Sciences. 2008.

BIBLIOGRAPHY BIBLIOGRAPHY

[12] F. Qian, Z. Wang, A. Gerber, Z. M. Mao, S. Zen, and O. Spatscheck. Characterizing Radio Resource Allocation for 3G Networks. In IMC ’10 Proceedings of the 10th ACM SIGCOMM conference on Internet measurement. 2010.

[13] F. Sposaro and G. Tyson. iFall: An Android Application for Fall Mon-itoring and Response. In Engineering in Medicine and Biology Society, 2009. EMBC 2009. Annual International Conference of the IEEE. 2009. [14] E. J. Vergara, S. Andersson, and S. Nadjm-Tehrani. When mice con-sume like elephants: Instant messaging applications. In Proceedings of the 5th International Conference on Future Energy Systems, e-Energy ’14, pages 97–107, 2014.

[15] X. Wu, Z. Wu, B. Zhao, and M. Wang. A Design and Application of Tilt Angle Algorithm Based on the 3-axis Acceleration Sensor. In The International Workshop on Cloud Computing and Information Security (CCIS 2013). 2013.

[16] L. Zhang, B. Tiwana, Z. Qian, Z. Wang, R. Dick, M. Mao, and L. Yang. Accurate Online Power Estimation and Automatic Battery Behavior Based Power Model Generation for Smartphones. In Hard-ware/Software Codesign and System Synthesis (CODES+ISSS), 2010 IEEE/ACM/IFIP.

BIBLIOGRAPHY BIBLIOGRAPHY

P˚a svenska

Detta dokument h˚alls tillg¨angligt p˚a Internet – eller dess framtida ers¨attare – under en l¨angre tid fr˚an publiceringsdatum under f¨oruts¨attning att inga extra-ordin¨ara omst¨andigheter uppst˚ar. Tillg˚ang till dokumentet inneb¨ar tillst˚and f¨or var och en att l¨asa, ladda ner, skriva ut enstaka kopior f¨or en-skilt bruk och att anv¨anda det of¨or¨andrat f¨or ickekommersiell forskning och f¨or undervisning. ¨Overf¨oring av upphovsr¨atten vid en senare tidpunkt kan inte upph¨ava detta tillst˚and. All annan anv¨andning av dokumentet kr¨aver upphovsmannens medgivande. F¨or att garantera ¨aktheten, s¨akerheten och tillg¨angligheten finns det l¨osningar av teknisk och administrativ art. Up-phovsmannens ideella r¨att innefattar r¨att att bli n¨amnd som upphovsman i den omfattning som god sed kr¨aver vid anv¨andning av dokumentet p˚a ovan beskrivna s¨att samt skydd mot att dokumentet ¨andras eller presenteras i s˚adan form eller i s˚adant sammanhang som ¨ar kr¨ankande f¨or upphovsman-nens litter¨ara eller konstn¨arliga anseende eller egenart. F¨or ytterligare in-formation om Link¨oping University Electronic Press se f¨orlagets hemsida http://www.ep.liu.se/

In English

The publishers will keep this document online on the Internet - or its possible replacement - for a considerable time from the date of publication barring exceptional circumstances. The online availability of the document implies a permanent permission for anyone to read, to download, to print out single copies for your own use and to use it unchanged for any non-commercial research and educational purpose. Subsequent transfers of copyright can-not revoke this permission. All other uses of the document are conditional on the consent of the copyright owner. The publisher has taken technical and administrative measures to assure authenticity, security and accessi-bility. According to intellectual property law the author has the right to be mentioned when his/her work is accessed as described above and to be protected against infringement. For additional information about the Link¨oping University Electronic Press and its procedures for publication and for assurance of document integrity, please refer to its WWW home page: http://www.ep.liu.se/

c