Overhead Analysis

The overhead of ASP while it is configured to use three different sampling rates (20 Hz, 10 Hz, 2 Hz) to collect hardware utilisation readings was analysed. The over- head increases with the rate. Considering the overhead of Sesame is above 80 mW, the overhead of ASP is relatively low. Additionally, to apply power signature-based estimation will reduce the needed sampling rates. Consequently, the overhead can be further reduced. Table 3.9 presents the overhead values obtained from real tests on the prototype.

3.9

Chapter Summary

ASP includes three-phase Energy-oriented Application-based System Profiling for mo- bile devices which (a) constructs a mapping between the work load on each hardware components and the corresponding system power value; (b) monitors the work load on the hardware components for each application, in order to construct the application profile table; (c) calculates current energy constraint of current context by referencing the above tables and monitoring current status of the device (screen brightness, ap- plication type, etc). This chapter starts with an introduction of the proposed energy modelling technique. Compared with other proposal, the advantages and contributions of the proposed solution are introduced. Next, the details of the conducted real tests for predictor selection are presented, including device set-up and results from each hardware subsystem using different approaches. A brief summary of the tests results outlines the concrete data and reasons backing up the design of the proposed energy modelling technique. Following predictor selection, the regression algorithm, training strategy along with software implementation of the prototype system are explained in details. Last, a series of comprehensive tests for model training and model validation are presented.

Application-aware Energy-efficient

Routing Architecture, Algorithms

and Testing

4.1

Overview

The latest mobile devices such as smart phones and tablet PCs, equipped with high resolution interactive screens, highly advanced CPUs, wireless networking and multi- media processing capabilities have become very important in people’s daily life. The growth of these devices’ popularity has determined an increased interest from shop- ping malls, theme parks, institutions, convention centres, etc. to deploy wireless net- work infrastructures and offer diverse online services addressed to such device users. However, infrastructure deployment is expensive and highly localized, so accessing content from mobile devices supported by ad-hoc wireless connectivity is considered a very good alternative solution. In such scenarios, energy efficiency has always been a key issue and is highly important especially for wireless routing algorithm designs as the mobile wireless devices are powered by batteries with limited power capac-

ity. Moreover, different applications, e.g. online games, online chat, video streaming, etc. put various loads on different hardware components (e.g. CPU, wireless card, screen) and result in different energy constraints. Such energy constraints of different devices are measured and recorded by the innovative ASP, which enables functional- ity of device-differentiated energy efficient solutions as described in chapter 3. In this context, this thesis proposes a novel Application-aWare Energy efficient Routing Algorithm (AWERA) for heterogeneous wireless networks which performs energy- aware routing based on application-related characteristics and nodes’ energy budget. AWERA makes use of ASP to keep track of nodes’ energy depletion according to the application type they run, network load and remaining battery energy level. Based on ASP, AWERA performs energy-aware routing that dynamically makes route selection to improve network energy efficiency.

The context of smart device usage in wireless networks includes: application prop- erties, device features (e.g. screen size, battery capacity, etc), network conditions and user preferences. This context is often energy related.

For example, different applications put different work load on the hardware and this results in different energy consumption. Compared with devices with smaller screens and larger battery size, those equipped with larger screens and smaller battery capacity suffer from shorter lifespan between recharges. Network condition is also a very important aspect of the mobile device usage. A wireless link with bad signal re- ception may need multiple re-transmissions before successful communication, which is energy consuming.

The device is aware about all the above-mentioned context information that can be accessed from the operating system at the application layer. As to the applications and device specifications, smart phones share a similar structure and the energy con- sumption of each hardware component shows distinctive features, and each typical application scenario (e.g. sending text message, watching video, etc.) shows distinc- tive energy requirements as well [8] [9].

Then this chapter presents the simulation-based testing environment and simula- tion scenarios used to fully evaluate the performance of AWERA. For each scenario, the simulation settings and scenario description are described. The schemes used for performance comparison are introduced as well. The metrics used for assessment dur- ing the testing are presented along with the testing results.

Compared with traditional wireless routing algorithms, AWERA introduces extra overhead. It needs periodical update to make sure it can make decision according to the latest energy distribution in the networks. However as far as I am aware of, the existing similar energy efficient routing solutions need periodical update process to ensure its energy saving policy. In addition, AWERA may face throughput reduction by choosing energy efficient routes. Consequently AWERA takes number of hops and link quality into consideration to address such issue.

The overhead for one node is computed as AWERA Routing Control Packet Size * Periodical Update Rate. The Control Packet Size is 24 bytes in this case. The Period- ical update rate is configurable. Besides, the use of more energy efficient routes may result in degradation in terms of throughput as demonstrated in the section ”Simulation Testing and Result Analysis”. Since AWERA uses ASP to obtain device energy con- straint information, the overhead of ASP is also included in the overhead of AWERA.

4.2

AWERA Use Case Scenario

A typical scenario for AWERA is depicted in Fig.4.1. In a very large public area, such as amusement park, shopping plaza, etc., it is difficult to maintain and manage high quality WiFi-based wireless networks [2]. This is due to the sheer size of the area to cover and high density of mobile users. Currently, 3G and 4G networks are the only available networking infrastructure in such scenarios.

Figure 4.1: Example of Use Case Scenario for AWERA - Theme Park

the often very expensive cellular networks. For example, a group of tourists queuing up for a roller coaster ride can well form an ad-hoc WLAN using their already available wireless NICs of their mobile devices. In this context, ad-hoc WLAN is an inexpensive and flexible choice for them to play WLAN-based games, share information and pass some time in a funny manner. Another possibility is to set up an AP for local Intranet services to enable access to maps and tourism information for example. The AP can help organise all the user devices to form an ad-hoc WLAN, which has better coverage and suffers less congestion than the traditional AP-based WLAN. This theory has been accepted as useful in many emergency recovery scenarios, tsunamis, earthquakes, etc in which ad-hoc WLANs can play critical roles.

In Fig.4.1, the cellular base station provides user devices with the ability to access the Internet. However, no additional infrastructure-based WLAN is organised. Instead, people near each amusement equipment have organised their own ad-hoc WLANs. AWERA is deployed among these devices aiming at prolonging device battery life

by using energy efficient ad-hoc routing. Moreover, AWERA tries to achieve load balancing to enable fair energy consumption among nodes.

To achieve the above objectives, the energy consumption in the context of device usage is recorded and referenced for route selection. The context of device usage in- cludes application type, remaining energy level, screen brightness and so on. ASP creates and automatically maintains the energy-oriented application-aware device en- ergy model. Using this model, AWERA considers the current energy constraint and performs energy-efficient sensible route selection.

Similar to all the other users near the roller coaster, Patrick’s tablet keeps a record of its energy constraints. All the devices within the self-organized network will ex- change their energy constraint on demand when route construction is needed. If all the devices nearby will relay Patrick’s data to the final destination, it is highly likely Patrick’s tablet will not choose John’s device to forward the data. This is because John’s device is running more energy consuming applications and uses brighter screen, resulting in lower remaining energy and tight energy budget. Instead Bob’s device will be used which has higher energy budgets. This energy-aware routing is made possible by both ASP and AWERA.

4.3

AWERA Architecture

The architecture of the proposed AWERA routing solution is presented in this section. AWERA is a cross-layer context-aware routing protocol involving application and net- work layers. Fig.4.2 illustrates the major components of AWERA and ASP, and the information sharing mechanism among them for energy efficient routing for wireless communications. The highlighted components comprise the structure of AWERA.

Since routing decisions are made in the network layer, all the context related infor- mation is aggregated by the Routing Info Centre located in the Network Layer. ASP

Figure 4.2: The Architecture of ASP and AWERA

notifies the Energy Constraint Monitor every time the Operating System finishes an old application and launches a new application. If the Energy Constraint Monitor can find the application profile for the current application, it will fetch that profile and passes it to the Routing Info Centre. Otherwise, it asks the App Profile Maintainer to create a new application profile. Meanwhile, the Network Environment Monitor monitors the link quality of the available links to neighbor nodes by detecting the signal strength of the incoming traffic. The weaker the received signal is, the more effort and energy are required for successful transmission to a neighbor node. Except for application layer feedback, link quality also needs to be evaluated for efficient routing decision making. This piece of link quality information is passed to the Routing Info Centre by the Net- work Environment Monitor. After the above process, Routing Info Centre will process all the context information and calculate the context-based energy constraint of current device and each available link. As a result, it maintains a Context-aware Cross-layer Energy-efficient Routing Table. The process of context monitoring and information processing is described in the next section.

The Packet Classifier module inspects all the incoming traffic, and hands over data packets to the Data Packet Processing module, control packets to the Control Packet Processingmodule. Data Packet Processing module will pass packets designated to the current device on to Transport Layer for local processing. Data Packet Processing module will check the Routing Table for the rest of data packets, and forwards the packet to the next hop if any routing record is available in the Routing Table. The Con- trol Packet Processingmodule is a very important element of this routing protocol. It passes valid routing control packets to the Routing Info Centre. The Routing Info Cen- trewill add fresher routes contained in the control packet to the Routing Table. Then the Routing Info Centre updates the control packet by adding the context-aware en- ergy constraint of the current device to the routing cost field, and forwards the control packet for route construction.

Table 4.1: Calculation of Individual Components’ Utility Functions GCPU GGRA GCELL GWLAN

Appj _{M axECPU}ECPU(j) _{M axEGRA}EGRA(j) _{M axECELL}ECELL(j) _{M axEWLAN}EWLAN(j)

Table 4.2: Real Readings in Idle State when GSM and WiFi Are Used GCPU GGRA GCELL GWLAN GSCR

Idle State 7% 80% 9% 1% variable

Fig.4.3 clearly illustrates the mechanism of ASP and how AWERA cooperates with ASP. At Application layer, the mapping between application type and typical observed work load on each major hardware components are recorded by App Info Maintaining module, which stores the processed information in App Info Table. Meanwhile, Net- work Environment Monitorperforms MAC layer feed back observing to evaluate the link quality of the available wireless link. The information collected from application layer and MAC layer is aggregated in network layer at Routing Info Centre.