Final thesis
Energy Consumption Studies for 3G
Traffic Consolidation on Android using
WiFi and Bluetooth
by
Ugaitz Moreno Arocena
LITH-IDA-EX-2014/ERASMUS-A–14/002–SE
Final thesis
Energy Consumption Studies for 3G
Traffic Consolidation on Android using
WiFi and Bluetooth
by
Ugaitz Moreno Arocena
LITH-IDA-EX-2014/ERASMUS-A–14/002–SE
2014-01-05
Supervisor: Ekhiotz Jon Vergara Examiner: Simin Nadjm-Tehrani
Abstract
Mobile phones have evolved from being devices just to make phone calls to become smartphones with added capabilities like surfing the network. Wireless communication has played a very important role in the evolution of smartphones.
The work in this thesis aims to study the potential to reduce the energy consumption of the 3G communications by using a hybrid architecture. An idea first presented in the paper by Vergara and Nadjm-Tehrani [1]. This architecture consists of a group of nodes that communicate using WiFi or Bluetooth to forward their traffic using one node’s 3G interface. In this thesis the named energy sharing scheme is implemented on Android mobile devices and experiments have been performed using a number of realistic traces to assess achievable gains and the energy footprint of the scheme itself.
Even though communication technologies, screen features, multimedia capabilities, or processing power have been taken to the highest level, phones’ batteries have not improved at the same speed. Nowadays battery lifetime has become a major issue with respect to cellular communication.
With 3G communications Internet connection anytime and anywhere is provided to the terminals but this technology is optimized for peak perfor-mance whereas in underutilization it wastes a lot of energy. This makes it a big black hole from power consumption point of view when transmitting small amounts of data.
Contents
1 Introduction 1 1.1 Background . . . 1 1.2 Motivation . . . 2 1.3 Problem Definition . . . 2 1.4 Goals . . . 4 1.5 Eval. Methodology . . . 4 1.6 Related Works . . . 4 1.7 Report Structure . . . 5 2 Android 6 2.1 Architecture . . . 62.2 Implementing for Android . . . 8
2.3 Android Connectivity . . . 8
3 Wireless Technologies in Android 9 3.1 3G . . . 9
3.1.1 Network Architecture . . . 9
3.1.2 UE States and Data Transmissions . . . 10
3.2 WiFi . . . 11
3.2.1 WiFi Network Architeture . . . 11
3.2.2 Scanning Networks . . . 12 3.2.3 Connecting . . . 13 3.3 WiFi-Direct . . . 13 3.3.1 Architecture . . . 13 3.3.2 Discovery . . . 15 3.3.3 GO Negotiation . . . 15
3.3.4 Protection Setup and Configuration . . . 15
3.4 Bluetooth . . . 15
3.4.1 PAN Profile Architecture . . . 16
3.4.2 Inquiry . . . 17
3.4.3 Paging . . . 17
3.4.4 Bluetooth in Android . . . 17
CONTENTS CONTENTS 4 Implementation 19 4.1 WiFi . . . 20 4.2 WiFi-Direct . . . 20 4.3 Bluetooth . . . 22 5 Evaluation 24 5.1 Testing Environment . . . 24 5.2 Software Instrumentation . . . 26
5.3 Emulation and Measurement . . . 27
5.4 Evaluation Criteria . . . 30
6 Results 31 6.1 Architecture formation . . . 31
6.1.1 Enabling radio interfaces . . . 32
6.1.2 Idle . . . 33
6.1.3 Scanning . . . 35
6.1.4 Connection . . . 36
6.1.5 Connected . . . 37
6.1.6 Group Formation Process . . . 38
6.2 Client Data Transmission . . . 38
6.3 3G Energy consumption . . . 40
6.4 Hybrid vs. Pure 3G Scenario . . . 41
7 Conclusions and Future Works 45 7.1 Conclusions . . . 45
Chapter 1
Introduction
This report describes the work and results of a Master’s Thesis Project (30 ECTS) as a partial fulfilment of a Master degree in Embedded Systems at Mondragon Unibertsitatea. The thesis has been performed at the Depart-ment of Computer and Information Science at Link¨oping University as an Erasmus exchange project.
This chapter provides the necessary background information to follow the explanations of the work with a description of the motivation, problem definition, goals and methodology used in the project. Finally the work describes the structure of the rest of the report.
1.1
Background
Mobile phones have evolved from being devices just to make phone calls to become smartphones with added capabilities like surfing the network. Such capabilities have proven to be essential to the users and nowadays there are around 1.4 billion active smartphones in the world [14, 15], one for every five inhabitants [16]. Among the smartphones Android is the most widespread operating system with 75 percent of market share at the time of performing the thesis [15]. This evolution has not been balanced in all aspects. Even though communication technologies, screen features, multimedia capabilities, or processing power have been taken to the highest level, phones’ batteries have not improved at the same speed. Although ubiquitous connection to the Internet and advanced communication features are real, the devices run out of battery faster than their users would like. This reduces the quality of experience of the users that see themselves forced to charge their device every day.
Smartphones will continue evolving to bring the newest technologies and features but batteries have to improve faster and more not to decrease their duration and become a real problem for the users. Even if battery technology might improve providing longer lifetimes, the energy efficient usage of the
1.2. MOTIVATION CHAPTER 1. INTRODUCTION
battery resource is paramount.
1.2
Motivation
Wireless communications have played a very important role in the evolution of smartphones. Different technologies have been applied on the field making possible the data transmission between devices or connection to the Internet with almost true mobility for the user. These technologies are divided in two groups in this thesis: Long-range wireless technologies and short-range wireless technologies. In general long-range technologies offer a wider range of mobility associated with a greater energy consumption, whereas short-range technologies offers a reduced energy consumption and mobility.
Third generation of mobile telecommunications technology (3G) is cur-rently the most widespread one in the first group. It provides the phones with Internet connectivity anytime and anywhere but it is optimized for peak performance whereas when underutilized it wastes a lot of energy.
Technologies in the short-range group such as Wi-Fi, Wi-Fi Direct or Bluetooth entail limited coverage areas. While they offer more restricted connection to the Internet they also enable direct communications between devices. Even if Wi-Fi has spread a lot during last years the required infras-tructure to offer ubiquitous connectivity is not a reality and the daily use of 3G connectivity drains users’ batteries.
A hybrid architecture that combines the energy efficient aspects of both short and long range technologies has the potential to become the key to more energy efficient communications. When several users are underutilizing their 3G connection, the wasted energy taking into account the group of nodes reaches more significant values. This is where the hybrid architecture is helpful as this device grouping not only increases the total energy loss in an area but also opens the door to new collaborative solutions to try to reduce the energy consumption.
1.3
Problem Definition
The work of this thesis consists of implementing a hybrid architecture com-bining long and short range wireless technologies in real devices in order to analyse the energy consumption of a group of devices using their own inter-net connections and the hybrid architecture. These scenarios are named as pure 3G and hybrid architecture during the report.
The idea of forming a group of nodes to save energy while the 3G inter-face is being underutilized has been first presented in the paper by Vergara and Nadjm-Tehrani [1]. The hybrid architecture is formed by a cluster com-posed of two types of nodes: A cluster head and cluster members. The members send the data to the cluster head which is responsible for gather-ing all the data and transmittgather-ing it through its 3G connection as for sendgather-ing
1.3. PROBLEM DEFINITION CHAPTER 1. INTRODUCTION
back the information coming from the Internet to the clients. The one-hop communication between the members and the cluster head is achieved using the aforementioned short range communication technologies.
Figure 1.1 illustrates the previously described structure generically and from communications point of view.
Figure 1.1: Illustration of 3G and hybrid architectures.
With the hybrid architecture all nodes except the cluster head stop using their underutilized 3G connection to use a short range technology that is more efficient to transfer small amounts of data. As a drawback, the cluster head adds more traffic to its 3G communications and keeps permanently ac-tive another radio interface, the one needed for the communication with the members. Increasing this node’s 3G traffic to high utilization level reduces the energy loss as the 3G technology is more efficient in high utilisation. After clarifying these facts, it is worth to remark that the aim of the ar-chitecture is to achieve a reduction in the energy consumption of the whole group, taking into account all the nodes.
In the aforementioned work, a rotation scheme was suggested to change over the time the only node relaying all the traffic. This mechanism is not aimed to improve the energy saving but to balance the consumption of all nodes forming the group. The cluster head has higher power consumptions associated and rotating this role makes all nodes act as the device with the highest battery drain.
Although this thesis and the work on which the hybrid architecture is based share the main idea, there are two remarkable differences between the works: (1) in that paper, they implemented the proposed architecture using Wi-Fi whereas in this work it is implemented using different short range technologies (Wi-Fi, Wi-Fi Direct and Bluetooth), and (2) in this project the architecture is implemented in real devices allowing to measure the power consumption directly in handsets instead of doing it through simulations.
1.4. GOALS CHAPTER 1. INTRODUCTION
1.4
Goals
The aim of this project is to implement the aforementioned hybrid architec-ture in physical devices in order to perform a study of the potential energy savings of the hybrid architecture compared to the pure 3G scenario. The short-range technologies used in this work for device to device communi-cations are Wi-Fi, Wi-Fi Direct and Bluetooth. The list of goals are the following:
• Develop an application for the Android platform that creates a hybrid architectures using Wi-Fi, Wi-Fi Direct and Bluetooth where a single device, the aggregator, forwards the gathered data through 3G. • Measure and compare the energy cost of forming the hybrid
architec-ture using WiFi, WiFi-Direct and Bluetooth.
• In order to analyse the potential energy savings, measure and compare the energy consumption of the group of nodes in the 3G and hybrid scenario for the different short range technologies.
1.5
Evaluation Methodology
The approach of this thesis has been evaluated using physical measurements. The followed evaluation methodology is divided in three parts.
An application to form the hybrid architecture has been developed and tested. It has been instrumented in order to ensure the correct behaviour of the architecture.
Once the basic requirements of the architecture are fulfilled, a compar-ative analysis of the resulting energy consumption that each technology en-tails to form the hybrid architecture has been realized. In order to measure this process the steps followed by each technology have been studied, divided and reproduced by an application implemented during this work.
To finish the evaluation, real power measurements while transferring pre-viously recorded real user traffic using the different technologies have been done. Comparing these measurements the efficiency and energy consump-tion variances between the different technologies have been shown.
1.6
Related Works
3G technology has been the subject of many research works that have anal-ysed and explained how it works and different proposals to make a more energy-efficient use of it [3, 4].
As WiFi and Bluetooth are also very important and widespread tech-nologies in nowadays’ society several works have been done around them. Some of them explaining and comparing both in a power and throughput
1.7. REPORT STRUCTURE CHAPTER 1. INTRODUCTION
performance study [7], others describing new setups to improve their energy consumption [12].
Another technology used in this thesis, WiFi-Direct, has been analysed too in some works. Even if it is not as spread as the previous ones it is a technology with big potential and works giving an overview of the technology [6] or presenting power saving protocols for it [9] have been done.
Finally, and closer to the work of this thesis, works presenting collab-orative architectures have been published. Some of them presenting an architecture using WiFi or WiFi-Direct to provide the devices with internet connection using an architecture based on computers and phones [10] or fixed access points and handsets [8]. Another one, the one that presents the hybrid architecture developed during this work [1] uses only WiFi as sort-range communication technology and the measurements that they perform are made by simulations.
This work is the first one where the whole architecture has been imple-mented and tested in real handsets using WiFi and Bluetooth as short-range technologies.
1.7
Report Structure
In this section an overview of all chapters in the report is given with a brief description of each one.
Chapter 2, Android, explains all the basics of the operating system used during this work.
Chapter 3, Wireless Technologies in Android, provides all the background information about different communication technologies that have been used during the thesis. After giving a general overview of 3G, WiFi, WiFi-Direct and Bluetooth technologies the tethering feature that is able to combine them is explained.
Chapter 4, Implementation, describes all the process of coding followed in this work. With all the necessary background information explained, how the application to form hybrid architectures with the different short range technologies has been implemented and how it works is shown. All the details and decisions taking during the process are analysed and defended in this chapter.
Chapter 5, Evaluation, provides the reader with information about the testing methodology followed to evaluate the work of this thesis.
Chapter 6, Results, shows obtained results of performing the experiments descrived in the evaluation chapter.
Chapter 7, Conclusions and Future Works, shows the analysis and in-terpretations of the results explained on the previous chapter. These inter-pretations are the outcome of the work of this thesis and their meaning and relevance are exposed in this chapter. Finally, the future works of interest discovered during the realization of the thesis are given in this chapter.
Chapter 2
Android
Android is an open source Linux-based operating system aimed to be de-ployed in smartphones and tablets. At its early days the operating system that at the very beginning was thought to be a platform for digital cameras [17], was developed by Android Inc., company acquired by Google Inc. in 2005. The Open Handset Alliance (OHA), group formed by 84 companies from the mobile ecosystem and led by Google Inc., is the responsible of developing Android nowadays [18]. The first smartphone running Android was sold on 2008 and, as previously stated on this report, right now it is running on the 75% of the devices on the market[15].
2.1
Android Architecture
The architecture of Android, consists of four layers built on top of a Linux kernel. Each layer is explained in the following subsections and Figure 2.1 shows a graphical representation of the whole structure.
2.1. ARCHITECTURE CHAPTER 2. ANDROID
• Linux Kernel
Android is based on a Linux 2.6 kernel modified to deal with the needs of running in a phone. Apart from providing networking capabilities, drivers to control the hardware or memory management software com-mon in Linux enhancements such as a new power management mod-ule or an inter-process communication driver are brought with these changes. The drivers and modules at this layer are mostly written in C programming languages.
• Hardware Abstraction Layer (HAL)
This layer provides a hardware interface to abstract the platform logic from the the kernel layer. This abstraction was achieved inside the kernel layer until 2008 when Google built the specific HAL layer due to license issues and restrictions in some components’ drivers. C and C++ programming languages are the ones utilized at this level. • Libraries and Android Runtime Layer
This layer is formed by two main blocks: (1) A set of libraries and (2) the Android runtime module. The first one provides the libraries used by all applications to squeeze the features Android offers. These libraries enable accessing different kind of data as video or audio in the phone and are written in C and C++ programming language. The Android runtime is a combination of a set of core libraries and the Dalvik virtual machine (VM). The Dalvik VM, which in essence is a modified Java virtual machine, is register-based and optimized to run in mobile phones as it has low power and memory requirements. All applications are executed on the virtual machine but in order to make the system more reliable each one runs in its own process and Dalvik VM instance. The virtual machine works with .dex (dalvic executable) files, a conversion of .class and .jar files that enables their execution with lower resources. To provide the applications with access to the core functionalities of Android, the virtual machine is with the set of core libraries written in Java programming language.
• Application Framework Layer
The Application framework is written in Java and offers an abstrac-tions of native libraries with Dalvik capabilities to the applicaabstrac-tions. This layer provides the application programming interfaces (APIs) that developers use to access Android’s core functionalities in their applications.
• Application Layer
At this layer the applications that the user interacts with during the normal use of the phone are located. These applications that pro-vide the user basic functions such as making phone calls, sending text
2.2. IMPLEMENTING FOR ANDROID CHAPTER 2. ANDROID
messages or browsing the Internet are written in Java programming language and later compiled into Dalvik byte code to be installed on the device.
2.2
Implementing for Android
The implementation for android can be done at three different levels: user space or application level, framework level and kernel level.
Working at user space means to work at application layer. To program at this level the Java language is used and the methods provided by the APIs gives the necessary functionalities. The outcome of compiling the Java code using the Android SDK and and a development environment is an applica-tion that the user can install and run in the device. An Android applicaapplica-tion consists of an Android Package (APK) file, a compressed collection of the code compounding the application.
The development at framework level is located between the application and kernel layers and provides the possibility of adding or modifying system services. Working at this level means to modify the operating system’s source code and different languages must be used to manipulate different parts of it such as C, C++ or Java. To apply the changes at this level, building the source code and flashing the new system image on the phone is necessary.
Developing at kernel level is the lowest programming level in Android. It implies modifying the kernel layer and the way the device interacts with its hardware. Editing or adding new drivers can allow controlling new hardware from the phone or changing the core behaviour of the one using before. This changes require a build and flash of the new kernel on the device.
As an exception, the programming technique Reflection is used to work at application level accessing resources from framework level. This mechanism allows the developer to use methods that are hidden in the APIs and are located at lower levels from the user space level. In this way the user can control core system functionalities from an application.
2.3
Android Connectivity
Android has been evolving continuously since its creation to integrate the newest technologies on the market. Nowadays it is able to manage commu-nications using Third Generation (3G),Long Term Evolution (LTE), Near Field Communication (NFC), Universal Serial Bus (USB), WiFi, WiFi-Direct or Bluetooth. During this work just some of these technologies have been used and they have been divided in two groups: (1) Long-range tech-nologies where 3G is located, and (2) Short-range techtech-nologies where WiFi, WiFi-Direct and Bluetooth are gathered. In the following chapters a deeper explanation about them is given.
Chapter 3
Wireless Technologies in
Android
This chapter explains the most relevant communication technologies for the work of this thesis followed by a brief description of the functionality com-bining them: tethering.
3.1
3G Technology
In this chapter basic notions of 3G technology are given. First its general architecture will be explained followed by its behaviour and power consump-tion while transmitting data.
3.1.1
Network Architecture
The Universal Mobile Telecommunications System (UMTS) is a third gen-eration mobile communication system developed and maintained by the Third Generation Partnership Project (3GPP). The UMTS network is com-pounded by three main elements listed and explained below:
• User equipment (UE): This refers to the device using the 3G technol-ogy.
• Core Network (CN): Element of the network enabling the connection between an UMTS network and other telecommunication networks. • UMTS Terrestrial Radio Access Network (UTRAN): This part is the
one responsible of connecting a phone terminal to the CN. It contains many Radio Network Subsystems (RNS) which manage the resources and control the transmissions and receptions of a group of cells. A RNS itself is formed by a Radio Network Controller (RNC) connected to one or more Node B elements. The RNC controls the logic resources
3.1. 3G CHAPTER 3. WIRELESS TECHNOLOGIES
of the Node B, which is responsible of providing the connection to the UE.
Figure 3.1 illustrates the aforementioned architecture.
Figure 3.1: UMTS architecture.
3.1.2
States and data transmission
One of the factors affecting the most the behaviour of an UE using 3G is the Radio Resource Control (RRC) function implemented at the RNC. It is defined in the UMTS Wideband Code Division Multiple Access protocol stack and it is the responsible of assigning channels for data transmission to the UE. The RRC defines four states where the UE experience different data transmission performance and power consumptions. From highest to lowest power requirement, the states are Dedicated Channel (DCH), For-ward Access Channel (FACH), Paging Channel (PCH) and Idle. Figure 3.2 is a graphical representation of these states.
Figure 3.2: RRC States[4].
In the Dedicated state, a dedicated physical channel (CELL DCH) is allocated for the device and access to dedicated uplink or downlink transport channels, shared transport channels and a combination of them provides high data rates in uplink and downlink to the UE. In the Forward Access Channel (CELL FACH) a default common or shared transport channel is
3.2. WIFI CHAPTER 3. WIRELESS TECHNOLOGIES
assigned in the uplink traffic while the downlink is continuously monitored. At this state the UE can transmit small data packets at lower data rates. In the rest of states (CELL DCH and CELL FACH) the terminal is not able to transmit any data as it just keeps the connection to the RNC.
In Idle state there is not any network activity. The UE is not connected to the RNC but it checks whether there is any downlink packet available. The Stanby state is optional and the operator decides whether implementing it or not. It has a similar power consumtion to the Idle state but in this case the terminal remains connected to the RNC. The PCH is what makes faster the switch to higher states when the UTRAN Registration Area Paging Channel (URA PCH) notifies the UE the existence of incoming data. Since this moment, the states will be referred as DCH, FACH, PCH and Idle in this report.
3.2
WiFi
WiFi is a technology that enables a phone or another device transmitting data or connecting to the internet without the need of wires. It was first deployed in Android 1.6 and since then it has become one of the most used technologies among smartphones due to its capability of improving users’ Web surfing experience.
The technology is specified in the standard IEEE 802.11 and has many protocols defining communications varying in their characteristics as data rate or bandwidth. Since during the thesis this technology has been used with the purpose of forming the hybrid architecture consolidating the 3G traffic this chapter explains technical details about this process. The point of view of explanations about this and the following short-range technologies are focussed on the parts that are relevant for the hybrid architecture.
3.2.1
WiFi Network Architeture
There are two different methods to create a WiFi network: (1) The Ad-hoc mode and (2) the infrastructure mode. Ad-hoc mode consists on a set of devices close to each other connected in peer-to-peer using WiFi. All nodes must be configured in Ad-hoc mode to stablish the connection and once the group is formed they can communicate to each other directly when are in range. In contrast to the infrastructure mode where is no coordinator, in the Ad-hoc mode a device willing to communicate must be listening to the channel continuously what increases the power consumption of the device. In order to control the access to the channel there are different methods defined in the IEEE 802.11 as the Distributed Coordinator Factor (DCF), the Point Coordinatoion Function (PCF) or the Hybrid Coordination Function (HCF). In this work the infrastructure mode has been used and its characteristics and architecture are shown in this section.
3.2. WIFI CHAPTER 3. WIRELESS TECHNOLOGIES
A WiFi network in infrastructure mode always needs an Access Point (AP) with internet connection that the clients can connect to. This AP sends beacon frames periodically in order to announce itself and every client joining the network must connect to it to form part of the network. Nodes forming the cluster can communicate to each other but they must go through the AP. The technology also describes a Power Save Mode (PSM) that allows the clients to go to low power consumption or sleep mode while they are not transferring data and wake up periodically to ask the buffered data to the AP. A simple WiFi network is shown in Figure 3.3.
Figure 3.3: WiFi Network Architecture.
In this thesis the architecture has been formed purely by smartphones and this requires a device acting as AP. The mechanism used to make an Android device act as AP is called Software enabled Access Point (softAP). Enabling a softAP means that the terminal configures itself to accept clients’ connections and creates a bridge between its 3G and WiFi interfaces. More details about bridging are given in section 3.5.
3.2.2
Scanning Networks
In order to form the architecture, a client has to find the network first and then connect to the AP. To find the network the client can run two types of network scan: (1) A passive scan or (2) an active scan. The first method consists on listening to the periodic beacons sent by the AP whereas the second one is more complex and described next.
The active scan is the one performed by an Android device when dis-covering a WiFi network. In this process the client executing it broadcasts Probe Request into the analysed channels and wait for Probe Responses from an AP in order to discover a network. The logic of the scan is based on two timers called MinChannelTime (MinCT) and MaxChannelTime(MaxCT). After the client sends a Probe Request if no Probe Response is received in the period MinCT the client understands that the channel is empty and starts analysing another one. In case of receiving a Probe Response the client will wait the time interval MaxCT for more Probe Responses of APs in that channel. Figure 3.4 illustrates an active scan.
3.3. WIFI-DIRECT CHAPTER 3. WIRELESS TECHNOLOGIES
Figure 3.4: WiFi Active Scan[11].
3.2.3
Connecting
Once the network is discovered the next step is to stablish the connection between the client and the AP. The connection is divided in two parts: (1) authentication and (2) association. In the first one a exchange of packets between the client and the AP occurs to allow the AP authenticate and accept the client. Once this happens the client can proceed to associate to the AP using association request/responses with the AP.
3.3
WiFi-Direct
WiFi-Direct is a new technology specified by the WiFi Alliance with the purpose of enhancing device to device communication over WiFi. The pos-sibility of implementing it in software is so widespread and WiFi interfaces make of it a promising peer to peer connectivity technology. The power saving protocols defined in the specifications of this technology are also at-tractive compared to the existing device to device technologies as the ad-hoc mode of WiFi. WiFi-Direct has been introduced in Android in the 4.0 ver-sion and it is has been evolving since then even if it has not been such a long period. One of the scenarios the technology is designed for is the one where a user wants to connect and control several devices at a time in an easy way. This chapter describes in detail the WiFI-Direct architecture and explains the procedure of forming a group with this fairly new technology.
3.3.1
WiFi-Direct Architecture
In Android WiFi-Direct is also referred as peer to peer (P2P) so during the report we name the elements of this architecture with both names. The features of a P2P architecture are similar to the ones in infrastructure mode
3.3. WIFI-DIRECT CHAPTER 3. WIRELESS TECHNOLOGIES
in WiFi but with the main difference of not requiring an AP connected to the Internet.
Nodes forming a P2P group can play two different roles: (1) Group Owner (GO), with similar functionalities to an AP and (2) peer to peer client. These roles are decided during the connection process. The mecha-nism to determine the role that a node plays in the group is called group owner negotiation and happens once the nodes discover each other and pro-ceed to establish the connection. Once the roles are set they do not change until the group is destroyed. Figure 3.5 shows a basic WiFi-Direct architec-ture.
Figure 3.5: WiFi-Direct Architecture[13].
A node of a P2P group can form part of another group and play a different role there. A device will be able to play both roles by time-sharing the WiFi interface or in case of having two interfaces configuring and using both for the connection to the different groups. Once the group is formed only the GO will be visible for external devices and all new nodes joining the network must do it connecting to the GO. Inside the P2P group all nodes are capable of communicating to each other but they must do it through the GO.
The picture below show the process of forming a P2P group that has been performed in this work. An overview of different group formation methods is shown in a recent work [6]. The process has been divided in four parts in order to make it more understandable and in following sections the whole process is explained.
3.4. BLUETOOTH CHAPTER 3. WIRELESS TECHNOLOGIES
Figure 3.6: WiFi-Direct Formation Process[6].
3.3.2
Discovery
This process begins with a traditional WiFi scan and is followed by a new discovery algorithm that proceeds as follows. A P2P device selects a channel in which it will switch between two states: A search state in which the device performs an active scan and a listen state where it runs a passive scan listening for other devices’ Probe Requests.
3.3.3
GO Negotiation
Once the devices have discovered each other, the GO negotiation takes place. The negotiation is based on a numerical value called GO Intent Value. Higher value denotes a higher priority for becoming GO and in case of having the same priority level, a tie breaker mechanism exists to randomly determine the GO.
3.3.4
Protection Setup and Configuration
Once the roles of the group are established, a Wireless Protected Setup (WPS) provisioning process is executed regarding to the network security. After that, to finish the group formation, a Dynamic Host Control Protocol (DHCP) runs to assign Ip addresses to all nodes forming the group.
3.4
Bluetooth
Bluetooth is a technology that provides personal-area communication ca-pabilities to the terminals. It can be used to connect and communicate a wide range of devices such as hands free devices, computer peripherals or health equipment. Many profiles are specified in order to set different functioning modes and respond in an accurate way to the requirements of each device type. For the purpose of forming a collaborative architecture a device must work with the Personal Area Network (PAN) profile enabling ah-hoc connections between nodes and bridging its 3G interface with the Bluetooth one. In Bluetooth the name Piconect is used to name the cluster
3.4. BLUETOOTH CHAPTER 3. WIRELESS TECHNOLOGIES
formed in star where one or many devices are connected acting as slaves to another acting as master. In this chapter a deeper explanation about the PAN architecture is given followed by technical details about the scanning and connecting process. Finally an explanation of how the user perceives this process in the phone is given.
3.4.1
PAN Profile Architecture
The PAN profile allows the use of Bluetooth Network Encapsulation Pro-tocol (BNEP) as OSI layer three proPro-tocol for transporting packets over the Bluetooth link. The profile defines three different roles for the nodes forming the architecture.
• A Network Access Point (NAP) is the node where the interface bridge is configured and is capable of providing internet connection to the clients. This device has an additional network connection to another interface where the Ethernet packets are exchanged.
• The role of Group Ad-hoc Network (GN) enables two or more devices inside the group to interact with each other using a wireless network and without the need of additional hardware. This device does not provide connection to an additional network.
• A PAN User (PANU) is a device connected to a NAP or GN as a client through a point to point connection.
There are different combinations to form a Piconet using the PAN profile. It can be done connecting one or many PANUs to a NAP or connecting them to a GN. For the purpose of this thesis the architecture formed using a NAP is the most interesting one and Figure 3.7 represents a simple formation of this type.
3.5. TETHERING CHAPTER 3. WIRELESS TECHNOLOGIES
3.4.2
Inquiry
In order to form a Piconet the devices must first find each other in an inquiry process. According to the naming of the technology the device starting the discovery process is called master and the one receiving the inquiry request is the slave. In the inquiry process the master sends identifier (ID) packets to the slaves in different frequencies asking them to join itself to form a Piconet. The master remains waiting for Frequency Hoping Sequence (FHS) packets coming from slaves interested in joining the master. Once the master knows the slaves that want to form the Piconet the paging state begins.
3.4.3
Paging
The slave sends its address and clock information in the FHS packet during the inquiry process and once at paging state the master uses that information to connect to the slave. To succeed in the paging process the slave must be in paging scan mode listening to the connection request packets the master is sending. The master sends this request through the channels where the slave is potentially listening and once the slave answers the connection gets established.
3.4.4
Bluetooth in Android
While using this technology in an Android device the aforementioned pro-cesses can be found clearly separated. The user has to perform a scan of devices first, then the pairing process is realized and at the end the connec-tion of devices happens.
Basically, the first step consists of running an inquiry process. After that, the user is able to begin the pairing process. During the pairing, the information sent by the slave in the inquiry process is saved in the phone in order to form future connections. The third and last step, the connection, is the execution of the paging process.
3.5
Tethering in Android
The Tethering feature is a key feature to understand how the hybrid ar-chitecture works while the cluster head gathers and redirect all the group’s traffic. Since its 2.2 version [20] Android offers the tethering feature. In essence this technique consists of forming a bridge between the 3G interface and any other in order to share the phone’s 3G connection. This means that all the traffic transmitted from one interface is redirected through the other. The traffic forwarding is done at second layer of the Operating System Inter-connection (OSI) model enabling all kinds of protocols going transparently through the bridge. Since it was first introduced in Android, the operating system has improved the feature offering different ways of tethering the 3G
3.5. TETHERING CHAPTER 3. WIRELESS TECHNOLOGIES
connection of a device. The tethering capabilities related to the previous technologies are listed below:
• Tethering over WiFi: This means to share a device’s 3G connection through the WiFi interface. In order to do this, a device plays the aforementioned softAP role and the clients connect to it as to any other WiFi network.
• Tethering over WiFi-Direct: At the time of performing this project (Spring 2013) this feature was not offered in Android yet. Different experiments and some work-around has been realized during this thesis and and more detail about this is given in the implementation chapter. • Tethering over Bluetooth: In this case the 3G connection is shared through the Bluetooth interface. This is achieved enabling the Blue-tooth interface with the PAN profile acting as a NAP and configuring the clients to get the internet connection through the Bluetooth con-nection.
Chapter 4
Implementation
In this chapter the implementation of the application developed during this thesis is explained. The application forms a hybrid architecture where all nodes communicate between them using a short range communication tech-nology and one node relays all the traffic through its 3G connection. An overview of the application is given in the Figure 4.1 showing the different blocks forming it.
Figure 4.1: Application structure.
The block named Group Formation is responsible for the process of find-ing the nodes and connectfind-ing to them usfind-ing the proper configuration for the hybrid architecture. The Communications block is where all the communi-cations between the nodes and the tethering feature are controlled. Finally,
4.1. WIFI CHAPTER 4. IMPLEMENTATION
the GUI block is the block where all the interfaces to interact with the user in the aforementioned situations are implemented. In order to make the chapter easier to understand the implementation realized using the different technologies is explained separately in three parts: WiFi implementation, WiFi-Direct implementation and Bluetooth implementation.
4.1
WiFi Implementation
For the purpose of the application, the node consolidating the 3G traffic, the cluster head, tethers its 3G connection with all nodes using the WiFi interface. As previously mentioned, in order to achieve tethering over WiFi, it is necessary to use the softAP feature and WiFi networks management. The work with this technology has been focused on being able to control the softAP features from the application and setting up the necessary WiFi radio configuration to achieve the group formation.
As the softAP features are not available on the APIs the reflection mech-anism has been paramount in this work. Once studied the Android’s frame-work and determined the required methods, reflection has been used to reach those framework level methods from the application level. Meth-ods from the WiFiManager and the ConnectivityManager classes from the framework have been used for that purpose.
Once the application was able to control the softAP the next step was to go through setting up the hybrid architecture’s configuration in all the nodes in order to achieve automatic group formation. With all the nodes connected to the softAP the tethering feature has been used to redirect all the traffic properly. Communication between devices has been done using datagram sockets that have been bonded to predetermined ports and the softAP is responsible for transmitting the information through its 3G interface and return it back through the sockets.
4.2
WiFi-Direct Implementation
Applying the tethering functionality to the architecture formed using this technology has not been possible and this implementation has focussed on forming a P2P group and achieving desired data transmission between the nodes. Additional options have been implemented to gain detailed control for the measurement of the group formation. The manual adjustment capa-bility allows the selection of the GO via the application.
The implementation of this code has been done at application level and for the features referring to the group formation, the P2P API provided by Android has been used. Figure 4.2 shows the classes this API uses in order to control the group formation process and other WiFi-Direct features from the application.
4.2. WIFI-DIRECT CHAPTER 4. IMPLEMENTATION
Figure 4.2: WiFi-Direct Code structure.
The application uses the methods provided in the WiFiP2PManager class that is located at framework level and is capable of controlling the WiFi in-terface through the WiFiP2PService. This service communicates with the network and authentication manager wpa supplicant module at the HAL in order to control the WiFi driver at kernel level. To enable the commu-nication between Framework and HAL levels, JNI is used, a programming framework that enables Java code to interact with applications and libraries written in C, C++ or assembler languages.
The communication between devices is achieved using sockets as in the WiFi implementation but in this case an IntentService has been implemented for the data sending and a service for the data reception. The packet sending happens whenever a device wants to send anything to the GO whereas the packet reception service is continuously executed listening to the incoming information.
For the GO a packet broadcast feature has been implemented enabling sending the same packet using the datagram sockets to all the nodes at the same time. This is one of the main parts of the GO role rotation feature. The GO role rotation is based on the idea of balancing the energy consump-tion of a P2P group between all nodes. For that purpose a simple rotaconsump-tion based on time has been implemented. Since the role negotiation happens the GO measures the for how long it acts as GO and when a predefined period is reached, the GO broadcast a GO rotation message. After sending the message, the GO breaks the group and restarts the formation with a new configuration where another device will act as GO. The utilized API has some limitations that do not allow to have full control over these re-unifications and a satisfactory rotation protocol has not been implemented. The main problems that were faced during this implementation are:
4.3. BLUETOOTH CHAPTER 4. IMPLEMENTATION
the group selecting another device as GO the whole group breaks. • At the time of leaving and breaking the group, the GO is not able to
keep the information of the nodes forming the group. This information is erased and in order to restart the group formation the whole device discovery must be executed. This requires more time and energy than just disconnecting from the group and connecting to it again.
If a proper rotation scheme is desired, these characteristics have to be re implemented and this must be done at lower level than the API. For that purpose the framework level and the wpa supplicant have been analysed but no GO rotation has been developed at those levels.
As previously said, the tethering feature is not implemented in the appli-cation. The reason is that Android does not provide native tethering with WiFi-Direct, therefore other ways were tried without success:
• Using the reflection mechanism tethering features from the framework level has been used in order to tether the P2P interface. This has not been successful due to the fact that Android limits the tetherable interfaces to USB, WiFi and Bluetooth.
• The Android framework has been modified to try to remove the pre-vious limitations. The modified framework has been compiled and flashed into the device but it was unfortunately not properly function-ing.
These attempts suggests that changes at kernel level are required to achieve tethering with WiFi-Direct in Android.
4.3
Bluetooth Implementation
The implementation of this technology is similar to the one realized with WiFi. First control over the tethering feature has been obtained and the reflection mechanism has been used for the group formation.
In order to use the tethering feature over the Bluetooth interface full con-trol over the bluetooth profiles has been necessary. Specially concon-trol over the PAN profile. The profile selection is done configuring the BluetoothProfile with the profile-corresponding value. The PAN profile is hidden in this class and a study of Android’s framework and Android’s Bluetooth stack have been necessary to determine how to refer to the profile and hard code it in the application. Once the profile has been configured, reflection has been used to access the necessary methods from BluetoothProfile class to enable and disable the profile.
After managing to control the Bluetooth tethering, creating the group has been the next step. In order to make the group formation as invisible as possible for the user and measure the process without any user interaction
4.3. BLUETOOTH CHAPTER 4. IMPLEMENTATION
a static group formation has been developed. Bluetooth technology asks a lot of user interaction while pairing or connecting to a device due to security reasons and setting a predefined group has been the solution to avoid it. In order to be able to perform our energy measurements, the MAC numbers of the devices of the group have been hard coded to make the device identification and connection automatic.
The communication is done as in the WiFi implementation. The devices communicate to each other through datagram sockets and the tethering feature redirects the information from the Internet to the corresponding device through the sockets.
Chapter 5
Evaluation
This chapter shows the testing methodology followed in this work and the obtained results. The testing environment is described in section 5.1, the software instrumentation realized in the smartphone is presented in section 5.2, the process of emulating captured traces is described in section 5.3 and the evaluation methodology is given in section 5.4.
5.1
Testing Environment
As mentioned when describing the evaluation methodology, the energy con-sumption of the phones while forming the hybrid architecture and while using it for 3G traffic consolidation has been measured. For this purpose physical access to the battery connectors has been required as well as differ-ent measuremdiffer-ent tools and software. Figure 5.1 describes the measuremdiffer-ent environment.
Figure 5.1: Measurement environment. Adapted from [12].
In the following list, the modules forming the aforementioned scenario are named and briefly explained:
• Test smartphone: This is the device under test, whose power con-sumption is being measured. During this thesis the measured device
5.1. TESTING ENVIRONMENT CHAPTER 5. EVALUATION
has been a LG Nexus4 (E960) a phone released on November of 2012 and running the latest Android version, the 4.2.2 released on February of 2013. The phone has been rooted for debugging information and framework related experiments.
• Low-side sensing circuit: Circuit composed of an adaptation circuit and an amplification module.
The adaptation circuit consisting of two resistors: a precision shunt re-sistor (R1=0.1Ω) located between the 4V power supply and the phone
and a resistor (R2=3.3 KΩ) placed between the battery monitor pin
and the ground that enables the start-up of the device. The amplifi-cation module is in essence a Phoenix Contact’s configurable isolating amplifier, MINI MCR-SL-SHUNT-UI with a maximum transmission error of 0.4%.
• Data acquisition unit: A National Instrument’s NI myDAQ device designed for signal acquisition and analysis.
The analysis and treatment of measurements has been realized in a com-puter using different signal processing software listed below:
• LabVIEW: System design development environment owned by Na-tional Instrument. Aimed to build measurement or control applica-tions integrating hardware using a graphical programming language. • Matlab: High-level language environment with wide mathematical
ca-pabilities. It offers data and signal analysis and treatment as well as algorithm development or application and model creation.
Once all elements that take part in the measurements have been intro-duced, following and understanding the measuring process becomes simpler. The tested smartphone is powered by an external power supply and through the low-side sensing circuit enabling to control and set the voltage and cur-rent given to the phone during the experiments. The voltage dropped in the shunt resistor is amplified with the amplifier and given to the data acquisi-tion unit as an analogue input. Once there, the signal is sampled at 1 kHz frequency and transmitted to the computer via USB.
The measurement is treated in LabVIEW using an application that in-tegrates the NI myDAQ unit and the power consumption of the phone is inferred from the voltage drop measured. To make that computation, the following formula is used.
Pphone= Vphone· VR2 R2 · 1 Gamplif ier (5.1) Pphone stands for the power consumption of the phone, Vphone is the
voltage with which the phone is supplied, VR2 is the measured voltage drop
5.2. SOFTWARE INSTRUMENTATION CHAPTER 5. EVALUATION
resistor’s impedance. Last, Gamplif ier is the gain of the amplifier in the
amplification module. All values are known but the measured one and sub-stituting them the equation is as follows:
Pphone= 4 ·
VR2
0.1 · 1
50 (5.2)
Once the energy consumption over time is calculated in LabVIEW the values are processed, analysed and plotted using Matlab in order to obtain the most accurate conclusions as possible from the measurements.
5.2
Smartphone Software Instrumentation
In order to have full control over the phone and isolate the measurements from the rest of processes running on the measured phone a set of appli-cations have been used. In this section these appliappli-cations are introduced and explained. They have been classified in three groups: (1) CPU control applications, (2) measurement applications and (3) communications appli-cations.
It is very difficult to control the energy consumption produced by the CPU in a phone’s normal functioning as it is an alive system with many fluctuations in the resource consumption. In order to achieve a constant power consumption of the CPU its frequency has been set to a fixed value and stress to the maximum. This makes the CPU to work continuously at the maximum frequency that has been set producing a more or less constant power consumption. For that purpose, the following tools have been used:
• AnTuTu CPU master [19]: This application enables setting the CPU working frequency to a desired value.
• CPU Stress: Application developed by us that stresses the CPU of the phone. It creates low priority background threads taking all the spare cycles of the CPU.
To ensure the correct communications during the tests the following application has been used.
• Shark for root: It is a network protocol analyzer for Android based on tcpdump. Tcpdump captures the packets sent to the network by the device.
In order to measure exactly the desired features three applications have been used to make the phone perform the specified action in a controlled way.
• DroidWall: Application based on iptables that enables selecting the processes or applications that can use the communication interfaces and blocking the rest (i.e., a firewall).
5.3. EMULATION&MEASUREMENT CHAPTER 5. EVALUATION
• Hybrid Architecture: Application developed by us that forms a hy-brid architecture where a node is sharing its 3G connection with the rest. It is capable of doing it using two different short-range technolo-gies: WiFi and Bluetooth. This software enables the analysis of the architecture formation and the communications going through it. • WiFi-Direct Architecture: Application developed by us enabling two
or more devices connecting and communicating between each other using WiFi-Direct and enables the measurement of this process. During chapter 4 the implementation of the second and third applications have been described. As stated in that chapter, the tethering feature has not been implemented for all the technologies and due to this difference the implementation has been divided into two applications for testing purposes: One implementing the whole hybrid architecture (as in Figure 1.1, section 1.3) using WiFi and Bluetooth and the other without tethering capabilities forming a group with WiFi-Direct.
5.3
Trace Emulation and Measurement
If a fair and meaningful comparison between the power consumption of a pure 3G scenario and a hybrid architecture using WiFi or Bluetooth is desired the behaviour of the nodes must be exactly the same in all the cases. As it is not possible to achieve recreating the phone usage each time due to the alive system and applications, a solution is to emulate the traffic for the tests. Emulated traffic refers to replaying real traffic which has been captured before.
In order to provide realism to the measurements, traffic generated by a phone during ten days of normal usage has been captured. This traffic has been generated by commonly used applications as Spotify, Facebook, Whatsapp or gmail. The capture has been realized using the application shark for root that generates a pcap file with all the information about the captured trace: packet timestamp, packet size and traffic type (uplink or downlink).
The captured traffic has been divided into uplink and downlink traffic and introduced in the traffic emulation environment shown in Figure 5.2 to perform the experiments. The measurement kit used to determine device’s energy consumption while generating the desired traffic is shown in detail in Figure 5.1 in section 5.1.
5.3. EMULATION&MEASUREMENT CHAPTER 5. EVALUATION
Figure 5.2: Traffic Emulation Environment. Example of the usage measur-ing the cluster head.
Uplink traces are given to the nodes and downlink traces are placed on a remote server. In this computer a Java application is installed designed for reading downlink traces and answer them with the corresponding packets. In the scenario implemented in this thesis the server has to answer simul-taneously to all the nodes forming the hybrid architecture, even though all that traffic is relayed on the cluster head. For that purpose each node sends the uplink packages to its corresponding port on the server and the server has been configured to answer with the appropriate downlink packages in each port.
With the explained testing environment only one device can be measured at a time. This means that to measure one scenario of one cluster head and three clients the experiment has to be performed four times and each time one node’s power consumption has to be measured.
Since the time allocated for the thesis does not allow to replay all the captured traces, we are interested in finding representative cases. For that purpose, the captured traces have been treated in the software Matlab and divided into five minute chunks. These chunks have been organized based on average IPI, amount of sent packets and transmitted data. Figure 5.3 shows the distribution of the chunks depending on their average IPI and transmitted data volume.
5.3. EMULATION&MEASUREMENT CHAPTER 5. EVALUATION
Figure 5.3: Ten Days’ Traffic Distribution.
After a deep analysis the most interesting chunks have been selected for different experiment scenarios. The chunks have been chosen based on the previously mentioned characteristics: average IPI, amount of packets and amount of data. Two extreme scenarios have been identified and four chunks of data have been chosen to represent each case. Each node forming the architecture has reproduced a chunk of similar characteristics in order to measure the hybrid architecture’s effect while the 3G interface has high and low activity.
The high activity scenario has been emulated using chunks with high number of packets and data volume transmitted with a low average IPI. Around 4000 transmitted packets with an average IPI smaller than 0.1 sec-onds and a total data volume larger than 1.5 MB have been the character-istics to distinguish the high activity chunks. On the other hand, the low activity scenario has been represented by chunks where a small amount of data and packets has been sent with a high average IPI but with a consid-erable activity: Around 150 transmitted packets with an average IPI larger than 1.5 seconds and less than 50 KB of total data volume.
Using these slots for the experiments, the 3G interface is taken to the least and most efficient scenarios and it will be compared with the con-sumption of the hybrid scenario. Due to 3G network’s implementation: data thresholds and timers the traces sending few small packets with a low frequency emphasize the inefficiency of this technology in underutilization while the opposite cases will take it to the most efficient situations.
5.4. EVALUATION CRITERIA CHAPTER 5. EVALUATION
5.4
Evaluation Criteria
The features that has been tested and analysed during this thesis are listed below:
• In order to identify the cost of forming the group with the different technologies, a fine grained analysis and comparison of the energy consumption of forming the hybrid architecture using WiFi, WiFi-Direct and Bluetooth has been performed.
• A profile of the cost of sending data with the aforementioned tech-nologies has been done. This has helped to determine which is the technology using the least energy to perform the inter-cluster commu-nications.
• 3G Power Consumption Analysis in order to see the power consump-tion of the scenario that the hybrid architecture is aimed to improve. • A comparative study of the power consumption of consolidating the 3G traffic via the hybrid architecture using Wifi and Bluetooth has been done. Due to the restrictions to apply tethering features to WiFi-Direct it has been left out in the full comparison, and only partially studied.
Chapter 6
Results
This section describes the results obtained from the different features tested during this work.
6.1
Architecture formation
A deep analysis of the battery consumption entailed by the process of form-ing the cluster usform-ing WiFi, WiFi-Direct and Bluetooth is explained in this subsection. The whole process has been divided in five parts in order to iso-late and study in detail the different steps: (1) Enabling the required radio interfaces, (2) idle state, (3) scanning of devices, (4) connection of nodes and (5) keeping the group connection. Figure 6.1 illustrates the mentioned process. Each stage has been analysed from clients and cluster head point of view showing the energy required by a node acting as client or as cluster head in every step.
6.1. ARCHITECTURE FORMATION CHAPTER 6. RESULTS
6.1.1
Enabling radio interfaces
The first step to form the architecture goes through enabling the required radio interfaces for the communication between devices. Depending on the role the device plays different capabilities of a technology must be used.
The cluster head has additional capabilities compared to the clients and it makes necessary to enable its radio interface in special modes. The mea-sured situations for each technology are the next ones.
• WiFi: A cluster head using WiFi must be acting as softAP and the energy cost of enabling the softAP feature has been measured in this scenario.
• WiFi-Direct: It needs to be considered an extra feature of the WiFi interface in the Android version deployed in this work. This means that enabling WiFi is necessary in order to use WiFi-Direct technology. Because of this reason, in this state the cost of enabling the WiFi interface has been measured for WiFi-Direct. As the role of the devices is not decided until later, the same value has been taken for both states (client and cluster head).
• Bluetooth: The device must be running the PAN profile in order to be able of receiving connections as cluster head. Apart from that, the de-vice needs to be visible for the nearby dede-vices to enable discoverability for unknown clients. The power required for enabling the Bluetooth interface with the mentioned characteristics has been measured. Clients do not need special characteristics as the cluster head, just en-abling the interface of the technology they will use. Table 6.1 shows the time in seconds (sec) and energy in Joules (J) that this step requires for a client using different technologies.
Table 6.1: Cost of a client enabling the interface. Time (sec) Energy (J)
WiFi 1.6 0.021
WiFi-Direct 1.6 0.021 Bluetooth 1.2 0.035
The results show that enabling the Bluetooth interface take 1.2 seconds and consumes 0.035 Joules while enabling the WiFi interface takes a bit longer, 1.6 seconds but has a power consumption of 0.021 Joules. On the other hand, enabling the softAP is a process of 1.6 seconds and requires 0.6 Joules whereas the cost of reaching the equivalent state with Bluetooth is almost negligible.
From this measurement its possible to say that the cost of enabling the interface is almost the same in both technologies while a big difference exists
6.1. ARCHITECTURE FORMATION CHAPTER 6. RESULTS
with the cluster head consumption. These results are due to the fact that enabling the softAP requires to reconfigure the WiFi interface and in the case of Bluetooth only configuring a determined profile is necessary.
6.1.2
Idle
In this work this state is considered as the situation where the cluster is not formed and the node is ready to start the group formation playing its own role. The specifications for each role and technology in this scenario and their power consumption analysis are given below.
For a cluster head this state means that it is visible for the client and ready to accept a connection. The specific description of this situation for each technology is as follows:
• WiFi: The device is acting as softAP enabling all nodes to discover or connect to itself. The energy needed to keep the softAP feature enabled has been measured in this scenario.
• WiFi-Direct: As explained before, the role the nodes will play is de-termined when the connection happens. For this technology the idle state has been defined as the moment when the device is visible to the other and they can start a connection. When a device is using this technology there are two situations when it is visible for others: (1) The device is running a scan looking for other nodes and (2) it is already the cluster head of a group formed via WiFi-Direct. As a requirement of the state is that the group is not formed yet, so the most pessimistic scenario has been set as idle: the moment that the device is running a scan has been set as idle state.
• Bluetooth: The cost of remaining in the state after having the interface enabled with the PAN profile and visible to nearby devices has been determined.
Figure 6.2 shows the different power consumptions over time of a cluster head in idle state. From the graph the energy required by a cluster head to remain in the mentioned state during 3 seconds has been determined for each technology. WiFi, showed on the top, requires 0.95 Joules of energy followed by WiFi-Direct, drawn on the middle, that consumes 0.74 Joules. Bluetooth, drawn in the lowest position has a power consumption of 0.09 Joules, 90% less than WiFi and 87% less than WiFi-Direct. The difference between WiFi and WiFi-Direct is due to the fact that WiFi is sending announcement beacons continuously while WiFi-Direct is switching between sending Probe Requests and listening to them. In case of Bluetooth, apart from the fact that it has a shorter action range with the consumption decrease it brings, the device does not send any notification until a possible peer runs a scan what decreases its consumption.
6.1. ARCHITECTURE FORMATION CHAPTER 6. RESULTS
Figure 6.2: Cluster head’s energy consumption in idle state. When a node is acting as a client the definition of this state is described as the moment when a device is able to start a scan or a connection to a cluster head. The specific characteristics for each technology are explained into detail below:
• WiFi: For a client the only requirement is to have the WiFi interface enabled which will allow the client running scans and look for cluster heads or start a connection to a known network.
• WiFi-Direct: This state is the same as the cluster head using this tech-nology. This is due to the aforementioned fact that the role the device will play is determined at the moment of establishing the connection between them.
• Bluetooth: A client in this situation must have the Bluetooth radio enabled in order launch a scan for devices, start a pairing process or connect to another device. As previously explained in the background, the Bluetooth interface can be enabled in two different modes and for this experiment the worst case or the most power consuming situation has been chosen: the interface enabled in visible mode. Even if the device is not in visible mode, previously paired devices could connect to it.
The different power consumption are shown in Figure 6.3. In this case the difference between WiFi (top position) and Bluetooth (bottom position) is very small as none of them is having any activity. In the case o WiFi-Direct (middle), as it is running a scan in order to be in a comparable characteristics to the rest, the power consumption is much higher reaching 0.74 Joules.
6.1. ARCHITECTURE FORMATION CHAPTER 6. RESULTS
Figure 6.3: Client’s energy consumption in idle state.
6.1.3
Scanning
In this state the cluster head starts from the idle state and receives a scan of one or many devices. The scanning process, and specially the time needed to perform it, varies between technologies as explained before. Performed measurements show the battery consumption of a cluster head receiving a scan and a client running it. The Figure 6.4 represents the measurements for the clients each technology.
Figure 6.4: Client’s energy consumption scanning.
In this section the factor that most affects the measurements is the differ-ent duration of each technology performing and receiving the scan. Tables 6.2 and 6.3 show the time and energy consumption of this state for the clients and the cluster heads.
6.1. ARCHITECTURE FORMATION CHAPTER 6. RESULTS
Table 6.2: Cost of a client performing a scan. Time (sec) Energy (J)
WiFi 0.8 0.3
WiFi-Direct 120 127.65 Bluetooth 13 1.16
Table 6.3: Cost of a cluster head performing a scan. Time (sec) Energy (J)
WiFi 0.4 0.66
WiFi-Direct 120 127.65 Bluetooth 0.2 0.52
• WiFi: Due to its short scanning period it is the less power consuming technology in this part. The client spends 800 milliseconds consuming 0.3 Joules and the cluster head reacts for 400 milliseconds spending 0.26 Joules. The duration difference is because the client continues looking for further networks after finding the cluster head and the cluster head just answers once. The consumption difference is caused by the beaconing of the cluster head that announces its network while the client is performing the scan.
• WiFi-Direct: A device needs to be scanning while searching for new devices but also to accept a connection before forming part of a group. This is the reason that makes its scan so long, it takes 2 minutes to perform a full scan with the energy cost of 127.65 Joules for both sides, the client and the cluster head. The device remains in this state for a long time in order to scan all the frequencies but specially to be available to connections.
• Bluetooth: It needs 13 seconds to complete a scan as a client using 1.16 Joules and 0.52 Joules for a cluster head. This difference is a result of the inquiry process of Bluetooth. The client was initiating the scan so it scans all the channels after finding the cluster head whereas the cluster head just answers when the client is scanning its listening frequency making the client consume more than the cluster head.
6.1.4
Connection
In the case of a cluster head the energy consumption to receive a connection of a client has been measured in this scenario. The energy cost for a client to connect to a cluster head has been measured as well. Tables 6.4 and 6.5 show the results of the measurements and an analysis of each one is given.
