Energy Consumption of Internet of Things ... - Minerva Access

Energy Consumption of Internet ofThings Applications and Services

Chrispin GrayORCID iD: 0000-0002-5223-4314

Submitted in partial fulfilment of the requirements of the degree of

Doctor of Philosophy

Department of Electrical and Electronic EngineeringTHE UNIVERSITY OF MELBOURNE

August 2018

Produced on archival quality paper.

Copyright c© 2018 Chrispin Gray

All rights reserved. No part of the publication may be reproduced in any form by print,photoprint, microfilm or any other means without written permission from the author.

Abstract

THE Internet of Things (IoT) is a new paradigm of interconnectivity that has recently

garnered attention in the field of ICT, with an estimated proliferation of 50-200

billion connected devices (i.e. IoT/smart devices) by the end of the decade. This expo-

nential device growth raises concerns as it elicits potential risks including an increase in

global energy consumption arising from the deployment of such numbers of devices, the

additional network energy cost for handling potential IP traffic increment and the poten-

tial impact on the global energy consumption and carbon footprint of the ICT industry.

However, due to the development/deployment of many IoT services being in their em-

bryonic stage, there is little research on the characterisation of energy consumption of

these services in the literature.

In this thesis, we aim to investigate and gain a better understanding of the energy

consumption of IoT network applications and services. We do so by developing energy

consumption models and in turn, energy-efficient network architectures for the delivery

of IoT services. To achieve this goal, we employ and model a few case studies including

two of the most well-known and widely deployed IoT services, home automation and

security (HAS) and video surveillance services.

For the assessment of energy consumption of an IoT service, we obtained a range of

IoT products including a consumer-off-the-shelf (COTS) HAS system, as a representative

example. We analyse and model (through direct measurements) the energy consumption

of each component and the complete system including an IoT attributable share of the

home gateway energy consumption. Our results reveal that the energy consumption of

a simple COTS IoT service is non-trivial (more than one-third) when compared to the

annual energy usage of a mid-size suburban home. HAS energy consumption globally

iii

becomes substantial, in comparison with the ICT industry’s energy consumption projec-

tions, when IoT service numbers are scaled using published deployment estimates.

The IoT leverages a number of existing and emerging technologies to provide a com-

plete end-to-end service, one of which is short-range wireless network protocols. We

obtained, measured and analysed the energy-efficiency of five of the most popular COTS

wireless protocol modules, Bluetooth Classic & Low Energy, ZigBee, Wi-Fi and RF 433 MHz.

We compare these technologies through their application in a simple domestic stock-

control IoT service with three communication paradigm options. The results demonstrate

that careful consideration should be given to the choice of a communication mode and

wireless interface in IoT application development. Such decision should be driven by the

volume of traffic exchange and frequency of transmission of the application/service.

The emergence of edge/fog computing as an alternative to cloud computing promises

to tackle some critical pitfalls of cloud including energy consumption. To investigate

the energy efficiency of IoT network architectures, the data-intensive video surveillance

IoT service is employed as a case study. Using the end-to-end energy models devel-

oped, we investigate four (Local, Edge and Cloud) dissimilar network architectures for

the delivery of IoT services. We show that it is more energy-wise to adopt an edge-

based architecture for on-demand streaming applications but both live streaming and

computationally-intensive applications are more energy-efficient when designed with a

local access architecture.

We further study a number of access network technologies for the IoT. They include

very-high bit rate digital subscriber line (VDSL2), passive optical network (PON), point-

to-point optical network (PtP), fourth generation long term evolution (4G LTE), low power

wide area networks (LPWA) and Wi-Fi access (Shared and Unshared). We show that for

low data access rates, LPWA is more energy-efficient while a Shared Wi-Fi access with

PON backhaul is most energy-efficient for medium to higher data access rates.

The findings in this thesis reinforce the need for careful design consideration when

developing future IoT solutions.

iv

Declaration

This is to certify that

1. the thesis comprises only my original work towards the PhD,

2. due acknowledgement has been made in the text to all other material used,

3. the thesis is less than 100,000 words in length, exclusive of tables, maps, bibliogra-

phies and appendices.

Chrispin Gray, August 2018

v

Preface

This thesis is submitted for the degree of Doctor of Philosophy at the University of Mel-

bourne. The content of this thesis is completely original except where acknowledgement

and references are made to previous work. The research work described herein was

conducted by the student under the supervision of Laureate Professor Emeritus Rodney

Tucker, Dr Kerry Hinton, Mr Robert Ayre and Dr Leith Campbell. The student benefited

from technical comments and guidance from his supervisors through one-on-one interac-

tions and group meetings alike. All of the work towards this thesis was carried out after

enrolment into the degree and the thesis has not been submitted for any other degree or

qualification at any other university. In the preparation of this thesis, no third-party ed-

itorial assistance was solicited. Financial support for this undertaking was provided by

the Australian Government and University of Melbourne through the International Post-

graduate Research Scholarship (IPRS) and the Australian Postgraduate Award (APA).

The student was also a recipient of a top-up scholarship from the Centre for Energy-

Efficient Telecommunication (CEET) in collaboration with Alcatel-Lucent and Bell-labs.

Part of this work has been presented for publication. The following lists the publica-

tions and contributions of its authors:

• F. Jalali, S. Khodadustan, C. Gray, K. Hinton and F. Suits, ”Greening IoT with Fog:

A Survey,” IEEE International Conference on Edge Computing (EDGE), Honolulu, HI,

2017, pp. 25-31.

Contributions: The first three authors provided most of the content and co-wrote

the manuscript. The fourth and fifth authors provided technical comments, advice

and proofreading of the manuscript up to its publication.

vii

• C. Gray and L. Campbell, ”Should my toaster be polled? Towards an energy-

efficient Internet of Things,” 26th International Telecommunication Networks and Appli-

cations Conference (ITNAC), Dunedin, 2016, pp. 26-31. (Best Student Paper Award)

Contributions: The first author developed the main content of the work including

experiments, modelling and analysis and manuscript writing. The second author

provided the introduction, conclusion, proofreading and technical comments.

• C. Gray, R. Ayre, K. Hinton and R. S. Tucker, ”Power consumption of IoT access

network technologies,” IEEE International Conference on Communication Workshop

(ICCW), London, 2015, pp. 2818-2823.

Contributions: The first author carried out the modelling and analysis work and

developed the manuscript. The second and third authors mainly supervised the

development of this work and together with the fourth author, provided technical

comments and suggestions, including proofreading the manuscript prior to publi-

cation.

viii

Acknowledgements

Completing a PhD is a fulfilling and rewarding achievement that is impossible without

the help and support of a few amazing people. These people were instrumental in nudg-

ing me ever so slightly to the right path and supportive through challenging times.

Foremost, I would like to thank my supervisors, Laureate Professor Rodney Tucker,

Dr Kerry Hinton, Mr Robert Ayre and Dr Leith Campbell for their inspiration, guidance

and support throughout my PhD candidature. I deeply appreciate Kerry for shaping

the framework of this thesis and particularly grateful to Robert for his practical exper-

tise, mentorship and careful guidance especially during the experimental phase of this

study. Special thanks to Leith for his invaluable contribution towards this thesis. Thanks

to my advisory committee chair Professor Christopher Leckie for his time, feedback and

words of advice. I am thankful for the financial assistance I received from the Australian

Government, the University of Melbourne and the Center for Energy-Efficient Telecom-

munications (CEET).

It is a pleasure to also thank my friends and colleagues from CEET including Dinuka

Kudavithana, Fatemeh Jalali, Sascha Sussspeck, Hamid Khodakarami, Ashrar Matin and

Olivia Zhu. The friendship we share is one I would forever cherish.

I am indebted to my late dad Crispin Gray and my mum Paulina Gray for their un-

flinching love and support, without which none of this would be possible. Special thanks

and appreciation is also extended to my sister Crispina Lot-Thomas.

Most importantly, I would like to express my deepest gratitude to my loving wife

Mina for her love, patience and kind encouragement throughout this journey and for

affording me all the help I could ever ask for. Finally, thanks to my son Leon for putting

a smile on my face every time I walk through the door.

ix

x

To the memory of my dad, Crispin David Gray.

xi

Contents

1 Introduction 1

1.1 Energy Consumption of IoT Services . . . . . . . . . . . . . . . . . . . . . . 3

1.2 Energy-Efficient IoT Network Architecture . . . . . . . . . . . . . . . . . . 5

1.3 Focus of the Thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.4 Thesis Outline and Contributions . . . . . . . . . . . . . . . . . . . . . . . . 8

1.5 List of Publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2 Literature Review 13

2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.2 Background and Vision of the Internet of Things . . . . . . . . . . . . . . . 13

2.2.1 Multiple Visions of the Internet of Things . . . . . . . . . . . . . . . 14

2.2.2 Definition of the Internet of Things . . . . . . . . . . . . . . . . . . . 14

2.2.3 Internet of Things Services or Application Use Cases . . . . . . . . 15

2.2.4 Internet of Things Device and Network Traffic Growth . . . . . . . 16

2.3 Enabling Technologies for IoT Services . . . . . . . . . . . . . . . . . . . . . 17

2.3.1 Short-Range Wireless Protocols for IoT Applications . . . . . . . . 18

2.3.2 Energy Efficiency of Short-Range Wireless Protocols . . . . . . . . . 18

2.4 Network Structure for IoT Services . . . . . . . . . . . . . . . . . . . . . . . 20

2.4.1 IoT Device Network . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.4.2 Access Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.4.3 Metro and Edge Network . . . . . . . . . . . . . . . . . . . . . . . . 22

2.4.4 Core Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.4.5 Data Centres . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

xiii

2.4.6 Energy Consumption of Network Equipment . . . . . . . . . . . . 23

2.5 Systems, Architecture and Energy Consumption of IoT Services . . . . . . 25

2.5.1 HAS / Smart Home Systems . . . . . . . . . . . . . . . . . . . . . . 25

2.5.2 Localised HAS Systems . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.5.3 Cloud-based HAS Systems . . . . . . . . . . . . . . . . . . . . . . . 27

2.5.4 Energy Consumption of HAS Systems . . . . . . . . . . . . . . . . . 28

2.5.5 Energy Consumption of Video Surveillance Systems . . . . . . . . 29

2.6 Energy Efficiency of IoT Network Architectures . . . . . . . . . . . . . . . 30

2.7 Carbon Footprint of IoT Services . . . . . . . . . . . . . . . . . . . . . . . . 31

2.8 Summary of Literature and Conclusion . . . . . . . . . . . . . . . . . . . . 32

3 Energy Consumption of Home Automation and Security Systems 35

3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.2 Home Automation & Security System (HAS) . . . . . . . . . . . . . . . . . 36

3.2.1 IoT Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.2.2 IoT Device Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.2.3 IoT Device Network for HAS . . . . . . . . . . . . . . . . . . . . . . 39

3.2.4 HAS Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

3.3 Home Automation and Security System Energy Model . . . . . . . . . . . 40

3.3.1 Modelling the Energy Consumption of an IoT Device . . . . . . . . 41

3.3.2 Modelling a Sensor Device . . . . . . . . . . . . . . . . . . . . . . . 44

3.3.3 Modelling an Actuator Device . . . . . . . . . . . . . . . . . . . . . 47

3.3.4 Modelling a Smart Appliance . . . . . . . . . . . . . . . . . . . . . . 49

3.3.5 Modelling Energy Consumption of IoT Gateway . . . . . . . . . . . 49

3.3.6 Modelling the Energy Consumption of a Home Gateway Modem . 50

3.4 Experiment Methodology and Measurement Setup . . . . . . . . . . . . . 54

3.4.1 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

3.4.2 AC Power Meter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

3.4.3 DC Power Meter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

3.5 Traffic and Energy Measurements of a Ninja Block HAS - A Case Study . . 57

3.5.1 Sensor Energy Consumption Measurements . . . . . . . . . . . . . 57

xiv

3.5.2 Door and Window Sensor . . . . . . . . . . . . . . . . . . . . . . . . 60

3.5.3 Actuator Energy Consumption Measurements . . . . . . . . . . . . 63

3.5.4 IP Camera Energy Measurements . . . . . . . . . . . . . . . . . . . 64

3.5.5 IoT Gateway Traffic and Energy Consumption Measurement . . . 64

3.5.6 HGW Energy Consumption Measurement . . . . . . . . . . . . . . 67

3.6 Estimating the Energy Consumption of Home Automation and Security

Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

3.6.1 Estimating the Energy Impact on a Mid-Size Home . . . . . . . . . 69

3.6.2 Estimating the Global Energy Impact of HAS System Devices . . . 73

3.6.3 Estimating the Energy Impact of Smart Homes . . . . . . . . . . . . 75

3.7 Discussion and Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

4 Energy Consumption of IoT Wireless Network Protocols 79

4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

4.2 Wireless Network Communication Protocols . . . . . . . . . . . . . . . . . 80

4.2.1 Bluetooth Classic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

4.2.2 Bluetooth Low Energy . . . . . . . . . . . . . . . . . . . . . . . . . . 81

4.2.3 Wi-Fi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

4.2.4 ZigBee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

4.2.5 RF433 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

4.3 Measurement Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

4.3.1 Description of Measurement Setup . . . . . . . . . . . . . . . . . . . 83

4.3.2 RF Module Power Measurement Setup . . . . . . . . . . . . . . . . 85

4.4 Power Consumption Measurement . . . . . . . . . . . . . . . . . . . . . . . 87

4.4.1 BT Measurements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

4.4.2 BLE Measurement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

4.4.3 ZigBee Measurement . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

4.4.4 Wi-Fi Measurement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

4.4.5 RF433 Measurement . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

4.5 Domestic Stock Control IoT Application - A Case Study . . . . . . . . . . . 92

4.5.1 Application Architecture . . . . . . . . . . . . . . . . . . . . . . . . 92

xv

4.5.2 Communication Paradigms . . . . . . . . . . . . . . . . . . . . . . . 93

4.6 Energy Consumption Model . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

4.6.1 Energy Measurement . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

4.6.2 Processing and Storage Energy . . . . . . . . . . . . . . . . . . . . . 97

4.7 Comparison of Energy Consumption . . . . . . . . . . . . . . . . . . . . . . 98

4.8 Energy-Efficient Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

4.8.1 Interfaces Always On . . . . . . . . . . . . . . . . . . . . . . . . . . 100

4.8.2 Interfaces Powered Down When Not In Use . . . . . . . . . . . . . 101

4.9 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

5 Energy-Efficient Architecture for IoT Video Surveillance Services 103

5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

5.2 Motivation for study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

5.3 IoT video surveillance system . . . . . . . . . . . . . . . . . . . . . . . . . . 106

5.3.1 IP Camera Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

5.3.2 Network Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

5.4 Experimental Parameters and Measurements . . . . . . . . . . . . . . . . . 109

5.4.1 Measurement Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

5.4.2 Power Consumption Measurements . . . . . . . . . . . . . . . . . . 112

5.4.3 Power Consumption Model for an IP Camera . . . . . . . . . . . . 116

5.4.4 Traffic Measurements (Abit) . . . . . . . . . . . . . . . . . . . . . . . 117

5.5 IoT Video Surveillance Network Architecture . . . . . . . . . . . . . . . . . 119

5.6 Network Energy Consumption Modelling . . . . . . . . . . . . . . . . . . . 120

5.6.1 Modelling Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

5.6.2 Energy Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

5.6.3 Network Equipment Modelling . . . . . . . . . . . . . . . . . . . . . 122

5.7 Modelling IoT Live Video Streaming Architectures . . . . . . . . . . . . . . 126

5.7.1 Direct Live Streaming . . . . . . . . . . . . . . . . . . . . . . . . . . 126

5.7.2 Cloud Live Streaming . . . . . . . . . . . . . . . . . . . . . . . . . . 128

5.7.3 Edge Live Streaming . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

5.7.4 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

xvi

5.8 Modelling IoT On-Demand Video Streaming Architectures . . . . . . . . . 132

5.8.1 Energy Consumption of IPcam for On-Demand Streaming . . . . . 132

5.8.2 Direct On-Demand Streaming . . . . . . . . . . . . . . . . . . . . . . 134

5.8.3 Edge & Cloud On-Demand Streaming . . . . . . . . . . . . . . . . . 135

5.8.4 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

5.9 Application with Video Processing Load . . . . . . . . . . . . . . . . . . . . 141

5.9.1 Energy Consumption of Raspberry Pi . . . . . . . . . . . . . . . . . 142

5.9.2 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

5.10 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

6 Power Consumption of IoT Access Networks 147

6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

6.2 IoT Access Network Architecture . . . . . . . . . . . . . . . . . . . . . . . . 148

6.2.1 Passive Optical Network (PON) . . . . . . . . . . . . . . . . . . . . 150

6.2.2 Point-To-Point Optical Network (PtP) . . . . . . . . . . . . . . . . . 150

6.2.3 VDSL2 using FTTN . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151

6.2.4 Long Term Evolution (LTE) Wireless . . . . . . . . . . . . . . . . . . 151

6.2.5 Low-Power Wide Area (LPWA) Network . . . . . . . . . . . . . . . 152

6.2.6 Wi-Fi Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

6.3 Power Consumption Model . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

6.4 Network Element Modelling . . . . . . . . . . . . . . . . . . . . . . . . . . 154

6.4.1 Unshared Network Elements . . . . . . . . . . . . . . . . . . . . . . 155

6.4.2 Fixed-user Shared Network Elements . . . . . . . . . . . . . . . . . 156

6.4.3 Multi-user Shared Network Elements . . . . . . . . . . . . . . . . . 158

6.5 Traffic Measurement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162

6.6 Estimating the Power Consumption of Network Elements . . . . . . . . . 163

6.6.1 IoT Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163

6.6.2 Wi-Fi Access Network . . . . . . . . . . . . . . . . . . . . . . . . . . 163

6.6.3 Passive Optical Network Access (PON) . . . . . . . . . . . . . . . . 165

6.6.4 Point-to-Point Optical Network Access (PtP) . . . . . . . . . . . . . 165

6.6.5 VDSL2 Access Network . . . . . . . . . . . . . . . . . . . . . . . . . 166

xvii

6.6.6 4G LTE Network Access . . . . . . . . . . . . . . . . . . . . . . . . . 167

6.6.7 LPWA Access Network . . . . . . . . . . . . . . . . . . . . . . . . . 173

6.7 Results and Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

6.8 Potential Power Savings with Sleep-mode . . . . . . . . . . . . . . . . . . . 180

6.9 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181

7 Conclusions and Future Research Directions 183

7.1 Conclusions and Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . 183

7.1.1 Energy Consumption of IoT Applications and Services . . . . . . . 185

7.1.2 Energy-Efficient IoT Network Architecture . . . . . . . . . . . . . . 187

7.1.3 Energy-Efficient IoT Access Network Technologies . . . . . . . . . 189

7.2 Future Research Directions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190

A Ninja Block Home Automation & Security (HAS) System 193

A.1 Description of the Ninja Block HAS System . . . . . . . . . . . . . . . . . . 193

A.2 Functional Description and Measurement of Ninja Block End-Devices . . 195

A.2.1 Temperature and Humidity Sensor . . . . . . . . . . . . . . . . . . . 195

A.2.2 Passive Infrared Sensor (PIR) . . . . . . . . . . . . . . . . . . . . . . 196

A.2.3 Door or Window Sensor . . . . . . . . . . . . . . . . . . . . . . . . . 197

A.2.4 Actuator Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198

A.2.5 RF 433 MHz Transmitter and Receiver Modules . . . . . . . . . . . 199

B DC Power Meter Design 201

B.1 Description of the DC Power Meter Design . . . . . . . . . . . . . . . . . . 201

xviii

List of Figures

1.1 Example network architecture for IoT services. . . . . . . . . . . . . . . . . 8

2.1 ITU definition of the Internet of Things [1] . . . . . . . . . . . . . . . . . . . 15

2.2 Projected Estimates of Connected Devices by 2020 [2–6] . . . . . . . . . . . 17

2.3 A simplified schematic diagram of the IoT network structure [7] . . . . . . 21

2.4 Schematic diagram of an IoT device network connected to its parent IoT

gateway and an ISP’s access network. . . . . . . . . . . . . . . . . . . . . . 22

2.5 Power consumption profile of a generic network element . . . . . . . . . . 24

3.1 Schematic diagram of a generic IoT device. . . . . . . . . . . . . . . . . . . 38

3.2 Simple diagram of a Home Automation & Security System supported by

cloud data store and services. . . . . . . . . . . . . . . . . . . . . . . . . . . 40

3.3 Example power consumption time evolution of a time-based sensor device

operating periodically with fixed intervals between transmissions. . . . . 44

3.4 Example power consumption time evolution of an event-driven sensor de-

vice operating on randomly triggered events. . . . . . . . . . . . . . . . . . 46

3.5 Conceptual model of the power consumption time evolution of an actua-

tor device. The vertical rise of the rectangles demonstrates instantaneous

power consumption and the horizontal, elapsed time. . . . . . . . . . . . . 48

3.6 Traffic profile of a tier-2 ISP for a week [8]. . . . . . . . . . . . . . . . . . . . 51

3.7 Average diurnal traffic profile of a tier-2 ISP network with step load levels

which are percentages of the average load over a day [8]. . . . . . . . . . . 52

3.8 Schematic diagram of the measurement setup for recording both power

consumption and data throughput of a test device. . . . . . . . . . . . . . . 55

xix

3.9 dc power supply and power meter block diagram. A detailed diagram is

given in the appendix section. . . . . . . . . . . . . . . . . . . . . . . . . . . 56

3.10 Power plot of a Clas Ohlson temperature and humidity sensor transmit-

ting once per minute. The small spikes occurring every 7-8 seconds are the

sensing processes for collecting the temperature and humidity readings. . 58

3.11 Power plot of a 433 MHz PIR sensor device. . . . . . . . . . . . . . . . . . . 59

3.12 Power plot of a 433 MHz door and window sensor. . . . . . . . . . . . . . 60

3.13 Energy consumption of sensor devices for a 24 hours period. . . . . . . . . 61

3.14 Percentage of sensor device energy consumption by phase per day. . . . . 62

3.15 Power plot of a Watts Clever controlled socket in ON/OFF no-load states. 63

3.16 Power consumption of the components of the NB gateway unit. . . . . . . 65

3.17 Observed traffic from a Ninja Block linking sensors and cameras to the

cloud. Plot (a) & (b) shows the data rate (kb/s) and data volume (kb) of

the cameras; Plot (c) & (d) shows the data rate (kb/s) and data volume (kb)

of the sensors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

3.18 Power Consumption plot of a Billion BiPAC 7800NL ADSL2+ Modem [9] 68

3.19 ADSL2+ HGW power consumption attributable to the NB system traffic

as a function of its data access rate for 6 different background traffic level

profiles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

3.20 Percentage share of annual energy consumption of a HAS when the in-

stalled IoT devices are: (a) Mains and battery powered, and (b) Mains

powered only. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

3.21 Annual energy consumption by IoT devices type for a: (a) Mains and bat-

tery powered HAS, and (b) Mains powered HAS. . . . . . . . . . . . . . . 72

3.22 (a) Global forecast of installed HAS devices (2015 - 2025); (b) Global energy

consumption estimate of HAS from 2015 - 2025. . . . . . . . . . . . . . . . 74

3.23 (a) Cisco’s global forecast of installed HAS devices; (b) Global energy con-

sumption estimate of HAS. . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

3.24 Annual energy consumption estimate for mains-powered HAS devices vs.

mains and battery powered HAS devices. . . . . . . . . . . . . . . . . . . . 75

xx

3.25 Annual energy consumption estimate for smart home systems in North

America and Europe. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

4.1 Block diagram of experiment setup . . . . . . . . . . . . . . . . . . . . . . . 84

4.2 Image of measurement setup for a XBee ZigBee module . . . . . . . . . . . 84

4.3 Power trace of BT module (a) in standby state showing the scanning and

advertising phases and (b) showing the state transitions from standby to

pairing, connected and sniff states. . . . . . . . . . . . . . . . . . . . . . . . 88

4.4 Power consumption trace of BLE module configured as (a) peripheral (slave)

device showing advertisements and connection events (b) central (master)

device in scanning mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

4.5 Current draw of the XBee ZigBee end-device module during a connection

event. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

4.6 Power trace of an RF433 (a) transmitter module sending a 10B data (b)

receiver module in receiving the same amount of data. . . . . . . . . . . . 92

4.7 Plot of polling instances against demand. . . . . . . . . . . . . . . . . . . . 95

4.8 Energy consumption per week for BT, BLE, ZigBee, Wi-Fi and RF433 using

communications paradigms (a) Event-driven, (b) Broadcast and (c) Polling. 99

4.9 Energy consumption per week of an RF433 interface (Always On). . . . . 100

4.10 Energy consumption per week of the BT interface (toggled on/off). . . . . 101

5.1 Block diagram of the internal structure of an IP camera [10–12] . . . . . . . 107

5.2 Simple schematic network structure of a network IP camera-based video

surveillance service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

5.3 Measurement setup comprising IP camera, power meter and data logging

PCs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

5.4 Power consumption as a function of frame rate of a network IP camera

with (a) Ethernet access and (b) Wi-Fi access. . . . . . . . . . . . . . . . . . 112

5.5 Incremental energy per frame plotted as a function of frame size (in mega

pixels) for a network IP camera with (a) Ethernet access and (b) Wi-Fi access.114

xxi

5.6 Power consumption as a function of bit rate of a network IP camera with

(a) Ethernet access and (b) Wi-Fi access. . . . . . . . . . . . . . . . . . . . . 115

5.7 Measured traffic volume generated by the IPcam during live streaming

experiment with frame rate of 25 f/s and key frame interval of 2 sec, plotted

against (a) video file sizes and (b) video frame sizes. Bottom left and right:

(c) Bit rate (Mb/s) and (d) Number of IP packets, plotted against video

frame sizes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

5.8 An example network architecture (with PON) of an IoT video surveillance

service spanning from the IP camera to data storage centres. . . . . . . . . 119

5.9 Energy consumption of network architectures for a live video streaming

service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

5.10 Energy contributions of the different network segments in a live streaming

network architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

5.11 Power consumption of IPcam with attached SD card when streaming a 1

minute video file on-demand. . . . . . . . . . . . . . . . . . . . . . . . . . . 133

5.12 Energy consumption of network architectures for IoT on-demand video

streaming services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

5.13 Energy consumption as a function of number of downloads per month for

an on-demand video streaming service. . . . . . . . . . . . . . . . . . . . . 137

5.14 Energy per download as a function of number of downloads for on-demand

streaming of a 10 minute video file from a storage device. . . . . . . . . . . 139

5.15 Energy per download comparison for replicating a 10 minute video file in

2, 20, 200 and 2000 cloud and edge data centres. . . . . . . . . . . . . . . . 140

5.16 Power consumption of a Raspberry Pi 3 as a function of time when de-

tecting and recognising a single face from a video frame. Time elapsed

between time t1 and t2 is ≈ 4.5 seconds. . . . . . . . . . . . . . . . . . . . . 142

5.17 Energy consumption as a function of number of face recognition opera-

tions processed per day. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

xxii

6.1 High-level diagram of the IoT access network architecture. There are four

main nodes (left to right): the IoT gateway, the customer premises equip-

ment (CPE) modem, the remote node (RN) and the edge node (EN) lo-

cated at the central office (CO) or local exchange. The nodes are vertically

aligned while the technologies are horizontally aligned. . . . . . . . . . . . 149

6.2 Schematic diagram of the internal structure of an MSAN . . . . . . . . . . 157

6.3 Power consumption profile of a multi-user shared network element . . . . 161

6.4 Power consumption measurement of a ZTE MF823 4G Wireless Dongle . . 168

6.5 Daily BS traffic load profile of a dense urban area. 100 % corresponds to

the hourly traffic averaged at intervals over the 24 hour day [13]. . . . . . 170

6.6 4G LTE BS sector power attributable to IoT traffic as a function of IoT data

access rate for 5 different background traffic level profiles. . . . . . . . . . 172

6.7 Schematic diagram of a LPWA network structure [14] . . . . . . . . . . . . 174

6.8 Schematic diagram of the internal structure of an LPWA Gateway . . . . . 175

6.9 Current consumption characteristics of the iC880A RF module with a sup-

ply voltage of 5V from datasheet in the blue curve and the dash lines are

an extrapolation of the datasheets values. . . . . . . . . . . . . . . . . . . . 176

6.10 Power consumption per IoT gateway for different access network tech-

nologies. For LTE, power consumption varies according to the share of BS

power consumption attributable to the background traffic. . . . . . . . . . 178

6.11 Energy efficiency of different IoT access network technologies . . . . . . . 179

A.1 Ninja Block gateway components [15] . . . . . . . . . . . . . . . . . . . . . 194

A.2 Network architecture of Ninja Block home automation system . . . . . . . 194

A.3 Power consumption trace of a Clas Ohlson temperature and humidity sen-

sor device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195

A.4 Power consumption trace of an Ascot temperature and humidity sensor

device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196

A.5 Power consumption plot of a 433 MHz passive-infrared sensor device with

a 5 seconds lockout time. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197

xxiii

A.6 Power consumption plot of a 433 MHz passive-infrared sensor device with

a 50 seconds lockout time. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197

A.7 Power consumption trace of an 433 MHz door/window sensor device . . 198

A.8 Power consumption plot of a Watts Clever controlled socket in ON/OFF

no-load states. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199

A.9 Power consumption trace of an RF 433 MHz transmitter module sending

10 bytes of data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200

A.10 Power consumption trace of an RF 433 MHz receiver module receiving data.200

B.1 Block diagram of custom power supply and power meter (USB version) . 202

xxiv

List of Tables

2.1 Characteristics of common wireless network protocols for IoT applications

[16–22] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.1 Diurnal traffic load levels for a tier-2 ISP. The hourly average data rates for

the HGW are calculated using its estimated average daily traffic and load

levels (µl). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

3.2 Parameters of the ac and dc power meters used in the experiments . . . . 56

3.3 Measurement values for a WT450H T&H sensor for 1 cycle (1 min) . . . . 58

3.4 Measurement values of a 433 MHz PIR sensor device for 1 event. . . . . . 59

3.5 Measurement values of a 433 MHz door/window sensor for 1 event. . . . 61

3.6 Data rate and power consumption measurements of the FOSCAM FI9831W

IP Camera. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

3.7 Power consumption values of the main components of the NB gateway unit. 65

3.8 Measured average data rate and power consumption of NB gateway. . . . 67

3.9 Power consumption and data rate values for a BiPAC 7800NL ADSL2+

modem. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

3.10 IoT devices of a multi-function HAS and their annual energy consumption.

The table contains a mixture of battery and mains-powered IoT devices. . 70

3.11 Annual energy consumption of a multi-function HAS installed in a mid-

size household. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

3.12 Deployment scenarios of an IoT HAS. . . . . . . . . . . . . . . . . . . . . . 76

4.1 RF modules used in experiment. . . . . . . . . . . . . . . . . . . . . . . . . 86

4.2 Power consumption of RF modules in different operational phases. . . . . 87

xxv

4.3 Duration of operation in different phases. . . . . . . . . . . . . . . . . . . . 87

5.1 Parameters of the Foscam FI9831W IP Camera. . . . . . . . . . . . . . . . . 109

5.2 Experimental configuration of the IP Camera. . . . . . . . . . . . . . . . . . 111

5.3 Line of best-fit equations for power consumption as a function of frame

rate of the IPcam, where x = frame rate. . . . . . . . . . . . . . . . . . . . . 113

5.4 Line of best-fit equations for power consumption as a function of bit rate

of the IPcam, where z is the bit rate. . . . . . . . . . . . . . . . . . . . . . . 116

5.5 Energy per bit of network equipment in the transport network. . . . . . . 123

5.6 Power consumption of storage devices. . . . . . . . . . . . . . . . . . . . . 125

5.7 Descriptions of parameters defined in the energy models. . . . . . . . . . . 128

5.8 Parameters of the Raspberry Pi 3 Model B with attached Pi Camera. . . . . 141

6.1 Power consumption and data rate of unshared network elements . . . . . . 164

6.2 Power Consumption and data rates of shared network elements . . . . . . 164

6.3 Energy per bit values of shared network elements . . . . . . . . . . . . . . 165

6.4 Power consumption values for 4G LTE base station components from [23] 169

6.5 Traffic level distribution of a dense urban area over a 24 hour period . . . 170

xxvi

List of Acronyms

ADC Analogue to Digital ConversionADSL Asynchronous Digital Subscriber LineBNG Border Network GatewayBS Base StationCSMA/CA Carrier Sense Multiple Access with Collision AvoidanceDAC Digital to Analogue ConversionDC Data CentreDSLAM Digital Subscriber Line Access MultiplexerFTTN Fibre to the NodeFTTP Fibre to the PremisesHTTP Hyper-Text Transfer ProtocolICT Information and Communication TechnologyIoT Internet of ThingsIP Internet ProtocolISM Industrial Scientific and MedicalISP Internet Service ProviderLAN Local Area NetworkLPWA Low Power Wide Area NetworkLTE Long Term EvolutionM2M Machine-to-MachineMCU Microcontroller UnitPC Personal ComputerPON Passive Optical NetworkPtP Point-to-Point Optical NetworkPUE Power Usage EffectivenessQoS Quality of ServiceVDSL Very-high-bit-rate Digital Subscriber LineWSN Wireless Sensor Networks

xxvii

Chapter 1

Introduction

THE Internet of Things (IoT) is a novel paradigm of interconnectivity that has re-

cently garnered momentum in the field of modern telecommunications. The IoT

ecosystem is expected to usher in an era of ubiquitous presence of uniquely identifiable

physical objects or ”things” (referred to as IoT devices or smart devices), connected via

the Internet to measure, report and, in some cases, perform actions autonomously [24,25].

There are tens of IoT use-case applications and services across many industries in-

cluding but not limited to E-Health, Smart Building, Smart Manufacturing, Smart Agri-

culture, Connected Vehicle, Environmental Monitoring and Home Automation & Secu-

rity (HAS)/Smart Home [6,24,26]. A number of these IoT services are becoming increas-

ingly popular with users, partly aided by products and services from leading technology

pioneers like Apple, Google and Amazon. They include HAS (e.g. Apple HomePod,

Google Home, Amazon Echo), video surveillance (e.g. Google Nest Cam, Netgear Arlo)

and E-Health or Wearable applications (e.g. FitBit) to name a few. Many of these services

are still in the embryonic state of deployment and are yet to be fully characterised in the

literature.

It is estimated that the IoT will host between 50-200 billion connected devices by 2020

[2, 4–6]. These devices support a variety of IoT services. While there are many bene-

fits and opportunities arising from the adoption of these services [24, 25], those benefits

could come with potential risks, one of which is the additional electrical energy required

for powering these devices and their collective standby energy consumption to maintain

network connectivity and/or their ”smartness” [22, 27]. As the number of devices grows

exponentially, so too will the number of IoT services they support, the volume of traffic

1

2 Introduction

generated by said devices, the different types of traffic flows and the anticipated aggre-

gate network traffic across the Internet [28]. This growth further raises concerns for the

potential increase in energy consumption of existing and future networks to support IoT

service traffic volumes.

Growth in energy consumption of the information and communication technology

(ICT) industry is also of increasing concern. Some estimates suggest that the ICT industry

is accountable for 2-4% of global carbon emissions [29, 30], a value that could increase

with the deployment of billions of IoT devices. An International Energy Agency (IEA)

report [31] in 2013 forecast global energy consumption of network-enabled devices to

grow from 615 TWh in 2013 to 1,140 TWh in 2025, if no improvements are made to the

ICT industry’s energy usage. A similar study by Andrae et al. [32] in 2015 shows the

electricity usage trend of consumer devices is estimated to reach about 1,330 TWh by 2022

if only 1% annual improvement in energy efficiency is effected from 2010. A critical point

to mention is that the above estimates are based on network-enabled devices including

PCs, Smart TVs, mobile phones and home entertainment systems. They do not include

IoT devices such as IoT gateways, sensors, actuators, IP cameras and smart consumer

appliances (e.g. connected refrigerator). Thus, while there have been many studies of

trends in global energy consumption, and more specifically in ICT energy consumption,

the future impact of billions of IoT devices on ICT energy consumption has not been fully

explored.

The basic IoT service generally includes hardware IoT devices (i.e. sensors, actuators,

cameras, etc.) at the network edge, the IoT gateway with ”typical” gateway functions

(e.g. network access and traffic control, aggregation, etc.) and a cloud service for data

processing, storage, management and control. Communication between IoT devices and

their designated IoT gateway would likely be wireless [24, 33], provided by one of many

enabling wireless network protocols including Bluetooth Classic (BT), Bluetooth Low En-

ergy (BLE), Wi-Fi, ZigBee and Radio Frequency (RF) 433 MHz. The energy consumption

of two or more of these protocols has been studied and compared in the literature [34–39].

For example, the authors in [34] showed that Wi-Fi consumes 5-times more power than

BT when considering similar example chipsets with the same data rate for a single con-

1.1 Energy Consumption of IoT Services 3

nection, while the study in [35] revealed energy per unit data transferred for BLE to be

2.5-times better than ZigBee.

Between the IoT gateway and its parent cloud service, there are a number of network

segments including the access, metro/edge and core networks [7]. Research on the en-

ergy consumption of these network segments revealed the access network as the least

energy-efficient [7, 40, 41]. For IoT services, there exist a variety of wireline or wireless

network access technology choices ranging from xDSL (digital subscriber line) and opti-

cal network technologies, 4G/5G mobile technologies, to low-power wide area networks

(LPWA). Studies on the energy efficiency of access technologies have mostly considered

higher data access rates (> 1 Mb/s) and do not include more recent access network tech-

nologies like LPWA [42, 43]. IoT service access rates tend to be lower than other user

services [26, 33].

In this thesis, we aim to investigate and develop energy consumption models and

energy-efficient network architectures for the delivery of IoT services. To achieve this

goal, we employ a few case studies including two of the most well-known and widely

deployed IoT services, HAS and video surveillance systems.

1.1 Energy Consumption of IoT Services

Connected devices in HAS worldwide is expected to reach about half (50%) of all con-

nected devices by 2020 [28]. Hence the popularity of HAS in particular has attracted

significant research attention on mitigating potential energy consumption increase and

designing energy-efficient systems and protocols. Most studies on energy efficiency of

HAS or other IoT applications tend to take a more device-centric approach [22,27,44–50];

some, a more network-centric focus [51,52]; while others focus on processing and storage

centres [53]. These studies offer a variety of techniques for improving energy efficiency,

including duty-cycle optimisation, sleep-modes, efficient node placement, routing mech-

anisms, lower information transfer rate, virtualization and a move towards distributed

computing. A common theme among these studies is a focus on the energy efficiency of

the end-devices, their local networks and gateways/aggregators, with little attention to

4 Introduction

the energy consumed by other segments of the service including:

(i) (a share of) the energy consumed by the home gateway modem - which facilitates

Internet connectivity - attributable to IoT data traffic.

(ii) the energy consumed by the transport networks (including access, metro/edge and

core networks) for transmission of IoT data, events messages or commands and the

data centres which processes and stores the said data.

Another IoT service that is increasingly being embraced by users is the video surveil-

lance service, propelled by the ever increasing need for both private and public safety

and security. The modern IoT video surveillance service - unlike its legacy counter-

parts [54] - benefits immensely from an integrated (i.e. video camera, video encoder and

server/storage in one unit) and less complex system design (e.g. new generation net-

work IP camera [55]), and the availability of cheap, reliable and secure cloud computing

services [56, 57]. Some estimates suggest that video surveillance services would likely be

the most data-intensive IoT application [28, 58]. Given such estimates, with video trans-

mission being the most energy-demanding part of the system [59], there is an incentive

to minimise the number and size of video data frames transmitted using compression

algorithms [60]) and to develop more energy-efficient network architectures. Hence, the

research work in this area includes the design of energy-efficient video sensor devices

[12, 61], efficient multi-camera coverage overlap [62], local video processing as opposed

to cloud [63, 64] and balancing energy consumption with key parameters such as band-

width, delay and frame rate [65, 66]. From the survey of literature, there is a general lack

of extensive research on an end-to-end characterisation of IoT video surveillance services.

A related study is the 2016 IEA report [22], which estimated the standby energy con-

sumption of mains-powered IoT devices and IoT gateways for a number of IoT use-case

applications (e.g. HAS, Smart Roads). Then, using market-based device shipment projec-

tions, the authors estimated the standby energy consumption of these use-case applica-

tions to reach 46 TWh by 2025 with HAS alone bearing a 78% share of the total. Note that

this is an estimate of standby energy only. Some devices, however - for example the IoT

gateway - are critical enablers of the IoT, without which the ”smartness” of the system

1.2 Energy-Efficient IoT Network Architecture 5

is unachievable. An argument can be made that such devices should be considered as

the ”price of entry” for an IoT system and their full energy consumption be included in

such analysis (not just the standby energy). Furthermore, the estimate for the number of

sensors, actuators and cameras per household is somewhat conservative.

Given these differences in approach and the gaps in studies on energy consumption of

IoT services, a comprehensive investigation and analysis into the total energy consump-

tion of these services is needed. There is also merit in such study for a better understand-

ing of the potential global energy impact of these services on the ICT industry. In this

thesis we aim to fill these gaps by conducting detailed direct measurement of IoT devices

employed by these services, developing energy consumption models for the designated

services, presenting first-order estimates of the energy consumption of typical use-case

applications and analysing their wider implication on the ICT industry. This study can-

not be ”the last word” on the issues surrounding the energy consumption of IoT services,

but is intended to help guide the scope and detail of energy consideration needed as the

IoT evolves.

1.2 Energy-Efficient IoT Network Architecture

As discussed in the proceeding section, cloud computing has been the de-facto option

for the design and implementation of many IoT services [24, 25]. A cloud-based network

architecture has thus been pivotal to the growth and expansion of IoT services and appli-

cations. However, cloud computing is not necessarily the optimal solution for processing

and distribution of IoT data due to many quality-of-service (QoS) and other concerns, in-

cluding latency, bandwidth utilisation, mobility support, location awareness and energy

consumption [56, 57]. Fog computing, an emerging alternative to cloud, promises to ad-

dress these concerns by bringing cloud intelligence and resources much closer to the user,

with the implementation of distributed computing [67,68]. Although recent studies have

shown that fog computing could aid in reducing the energy consumed by IoT services

[63, 69], the energy efficiency of fog-based architectures and the benefits of hierarchically

distributing fog nodes much closer to the IoT devices (i.e. user’s premises) are yet to be

6 Introduction

fully investigated.

1.3 Focus of the Thesis

The focus of this thesis is to gain a better understanding of the energy consumption of

IoT network applications and services. Using a ”bottom-up” approach, we aim to in-

vestigate and model the system-level energy consumption of IoT services and further

estimate the energy impact of these services on the ICT industry. Where applicable, we

use energy consumption per information bit (i.e. energy per bit in joules/bit or J/b) as

the main metric in representing the energy efficiency of individual devices or networks.

To understand the relation between the network architecture, protocols, information rate,

communication paradigms and their energy consumption implications for IoT services,

we provide answers to the following fundamental questions:

• How much energy is required to support and sustain the emergence of IoT appli-

cations and services, currently and in the future?

• How can the energy consumption of an IoT application or service be minimised

with the selection of an energy optimal wireless network protocol and communica-

tion paradigm?

• How does the transport, storage and processing energy influence the total energy

consumption of the network architecture of an IoT application or service?

The energy consumption of a particular IoT service depends on the consumption of a

range of individual sensors, the signal communications and aggregation components

within the customer premises, in addition to the more traditional access, metro/edge

and core communications networks (see Figure 1.1) transporting IoT data, and that of the

data analysis centre. Each component is characterised by both a fixed idle power con-

sumption component and a traffic or data volume-dependent consumption component.

In order to fully characterise the energy consumption of each component, a combi-

nation of direct power measurement and modelling (where applicable) is utilised. We

obtained a complete commercial-off-the-shelf (COTS) HAS with additional devices for

1.3 Focus of the Thesis 7

our experiments. Using both purpose-built (see Appendix B for design) and commercial

power meters, direct power measurements are conducted for the sensors (e.g. tempera-

ture and humidity), actuators, IP cameras, IoT gateways (e.g. Raspberry Pi, BeagleBone

Black) and home gateway modems (HGW). We develop system-level energy consump-

tion models for said devices, taking into account their individual operational modes. Our

analysis excludes ”traditional” network-enabled home devices such as Smart TVs, PCs,

and other home entertainment systems.

Traffic measurements are conducted using packet-sniffing applications (i.e. Wire-

shark) on the network. We analyse and estimate IoT service energy consumption as a

function of its traffic volume. As HAS traffic would commonly use the same access mo-

dem as other household internet services, a novel shared energy model for the HGW,

which allocates energy consumed to an IoT service as a fraction of the average hourly

traffic-level over a complete diurnal cycle, is developed.

In analysing IoT access network technologies, a modelling technique that classifies

network equipment as shared and unshared devices is employed [69, 70]. This technique

allocates the total device energy consumption to a service accessing a single (or few) user

network equipment but proportionally allocates the total energy consumption of a multi-

user network equipment based on the number of users/services or as a function of their

respective data traffic flows.

For edge and core network equipment (e.g. routers, switches) along the public net-

work infrastructure and within data centres, direct power measurement is impractical.

Modelling is more practical; hence, an approach that proportionally allocates energy to a

service as a function of its application traffic flows is considered [70]. Modelling storage

devices at the data centres is achieved with the allocation of power per unit bit stored [7].

Representative examples of network equipment are used for evaluation of IoT services

and network architectures. These are obtained from a range of data sources including

measurements, equipment manufacturers’ datasheets and previous literature.

This thesis seeks to identify the least energy-efficient systems, protocols and archi-

tectures for IoT services through a unified measurement and modelling approach, and

where applicable, shed light on how energy utilisation of such services can be minimised.

8 Introduction

1.4 Thesis Outline and Contributions

In this section, we give an outline of the thesis structure and state the key contributions

of the thesis. Figure 1.1 (adapted from [7]) gives a schematic diagram of an example net-

work structure for IoT services (foreground), with an underlying Euler diagram (back-

ground) depicting the scope of each main chapter in the thesis.

Data Centre

Core Network Data Centre

Data Centre

IoT Device Network

IoT Gateway

Metro/Edge Network

Chapter 5

Chapter 6Chapter 4

Chapter 3

Ho

me

Gat

eway

Access Network

Data Centre

Cloud

Edge/Fog

Figure 1.1: Example network architecture for IoT services.

Chapter 2 presents an overview of the IoT ecosystem and gives a description of

the IoT network architecture, which includes the IoT device network (IDN), the access,

metro/edge and core networks, and the data centres. We discuss some key enabling

technologies including wireless network protocols and a number of access network tech-

nologies. The chapter also provides a survey of literature on the energy consumption of

IoT applications and services, with a focus on the HAS/smart home and video surveil-

lance use-cases, IoT wireless network protocols and IoT network architectures.

Chapter 3 presents an analysis of the energy consumption of HAS services. We pro-

vide power consumption and traffic measurements of a number of devices which may

be present in a representative example HAS. Energy consumption models are then de-

veloped and those models used to estimate the total energy consumption of the HAS. We

then use market forecasts to estimate the global energy consumption increment of the

ICT industry due to new HAS and smart home deployments. The key contributions in

Chapter 3 are as follows:

• Provided direct power and data traffic measurements of tens of IoT devices and

network equipment.

1.4 Thesis Outline and Contributions 9

• Developed new measurement-based energy consumption models for HAS includ-

ing sensors, actuators, IP cameras, and IoT gateways.

• Developed a new shared energy consumption model for the home gateway/modem.

The model allots the energy share attributable to the HAS using an energy alloca-

tion regime that is based on overall household average data rates.

• Identified the least efficient devices and highest contributors to consumption, which

should be the prime focus for future attention.

• Estimated the annual energy consumption of the HAS to be about 35% or more of

the annual energy consumption of a typical suburban home.

• Estimated the potential global energy consumption of HAS to be between 57 -

156 TWh by 2025 based on market research forecasts.

• Based on recent industry forecasts for two major smart home markets (i.e. North

America and EU28+2), we estimated the total energy consumption of their installed

base to reach about 63 TWh and 100 TWh respectively by 2025.

Chapter 4 provides power consumption measurements of five most commonly em-

ployed short-range wireless network communication protocols for IoT applications, which

includes Bluetooth Classic (BT), Bluetooth Low Energy (BLE), ZigBee, Wi-Fi and Radio

Frequency 433 MHz (RF433), for their respective operational states (e.g. Tx/Rx, Sleep).

We consider three communication paradigm options for a simple domestic stock control

application as a case study. The key contributions in Chapter 4 are as follows:

• Provided direct power consumption measurements for five popular wireless net-

work protocols for IoT services using representative example RF modules.

• Estimated the energy consumption of a domestic stock control IoT application when

designed with each of five wireless network protocol modules, and using each of

three communication paradigms, Event-driven, Broadcast, or Polling.

• Showed that BLE is the most energy-efficient wireless communication protocol for

10 Introduction

both event-driven and broadcast communication modes. ZigBee is more energy effi-

cient for polling mode due to its characteristic reverse polling capability.

• Showed that an event-driven communication mode is the most energy-efficient for

low traffic IoT applications with relatively low to medium number of operations

per week. A broadcast communication mode is more energy-efficient for higher

operation rates.

Chapter 5 presents an analysis of the energy consumption of network architectures

for IoT video surveillance services, which includes the access, metro/edge and core net-

works and the data centres. We conduct power consumption and data traffic measure-

ment and modelling of a new generation network IP camera. Energy consumption mod-

els for Local, Edge and Cloud-based network architectures are developed. Using typical

video streaming use-cases (i.e. live and on-demand streaming), we evaluate and com-

pare the energy consumption when the above network architectures are considered, for a

range of video file sizes and data traffic for video streaming, storage and processing. The

key contributions in Chapter 5 are as follows:

• Provided direct power consumption measurements of a new generation network

IP camera as a function of key parameters including video frame rate, bit rate and

pixel rate. The baseline power of the IP camera is shown to be over 90% of its

maximum power.

• Developed a new measurement-based power consumption model for new genera-

tion network IP cameras.

• Developed energy consumption models for Local, Edge and Cloud-based network

architectures for IoT video surveillance services.

• Showed that for live video streaming, a local access architecture is the most energy-

efficient. A cloud-based network architecture is less energy-efficient by a factor of

two.

• Showed that for on-demand streaming (includes the storage energy cost), irrespec-

1.4 Thesis Outline and Contributions 11

tive of the number of video file accesses or downloads (low to high), energy con-

sumption is minimised when an edge-based network architecture is utilised.

• Showed that for computationally-intensive video processing applications (e.g. face

recognition), energy consumption can be minimised if the processing is done at an

edge data centre for very low number of operation instances per day (few tens).

Local processing is more energy-efficient for higher number of operation instances

per day.

Chapter 6 presents an analysis of the energy consumption of a number of wireline

and wireless access network technologies suitable for the IoT. We develop energy con-

sumption models for these access technologies, which include very-high bit rate digital

subscriber line (VDSL2), passive optical network (PON), point-to-point optical network

(PtP), fourth generation long term evolution mobile wireless (4G LTE), low power wide

area networks (LPWA) and Wi-Fi (both shared and unshared). The key contributions of

Chapter 6 are as follows:

• Developed new energy consumption models for each of the access network tech-

nologies including VDSL2, PON, PtP, 4G LTE, Wi-Fi and LPWA.

• Applying a shared and unshared device modelling approach, we developed per-bit

energy models for key network elements in the access network (e.g. 4G LTE Base

Station, Ethernet Switch, etc.).

• Presented first-order estimates of the power per IoT gateway for these technologies

considering IoT-like data access rates (sub-1 Mb/s).

• Showed that LPWA network technology is the most energy-efficient for low IoT

data access rates, and Shared Wi-Fi combined with PON fixed access, the most

energy-efficient for higher access rates.

Chapter 7 gives a summary of the main results and conclusions of this thesis and

highlights some open research questions and future research directions.

12 Introduction

1.5 List of Publications

Journal Papers

1. C. Gray, R. Ayre, K. Hinton, L. Campbell, R. S. Tucker, ”Energy consumption mod-

elling of IoT applications and services - home automation & security use case,” In

preparation for submission to IEEE Internet of Things Journal, Sept. 2018.

2. C. Gray, L. Campbell, R. Ayre, K. Hinton and R. S. Tucker, ”Energy efficiency of

IoT wireless network protocols”, In preparation for submission to Australian Journal

for Telecommunication and the Digital Economy, Oct., 2018.

Conference Papers

1. F. Jalali, S. Khodadustan, C. Gray, K. Hinton and F. Suits, ”Greening IoT with Fog:

A Survey,” IEEE International Conference on Edge Computing (EDGE), Honolulu, HI,

2017, pp. 25-31.

2. C. Gray and L. Campbell, ”Should my toaster be polled? Towards an energy-

efficient Internet of Things,” 26th International Telecommunication Networks and Ap-

plications Conference (ITNAC), Dunedin, 2016, pp. 26-31. (BEST STUDENT PAPER

AWARD)

3. C. Gray, R. Ayre, K. Hinton and R. S. Tucker, ”Power consumption of IoT access

network technologies,” IEEE International Conference on Communication Workshop

(ICCW), London, 2015, pp. 2818-2823.

Other Publications

1. F. Jalali, C. Gray, A. Vishwanath, R. Ayre, T. Alpcan, K. Hinton and R. Tucker, ”En-

ergy Consumption of Photo Sharing in Online Social Networks,” 14th IEEE/ACM

International Symposium on Cluster, Cloud and Grid Computing (CCGrid), Chicago, IL,

2014, pp. 604-611.

Chapter 2

Literature Review

2.1 Introduction

W ITH the expected proliferation of billions of devices by the end of the decade,

the Internet of Things (IoT) could bring about significant changes to the ICT

world that may affect or disrupt many industries.

In this chapter, an overview of the IoT ecosystem and its enabling technologies is

presented. Some key enabling technologies including wireless network protocols and a

number of access network technologies are discussed, followed by a review of research

on the energy consumption of those technologies. A description of the network architec-

ture for the delivery of IoT services is then given, which includes the IoT device network

(IDN), the access, metro/edge and core networks, and the data centres. The chapter

then provides a survey of literature on the energy consumption of IoT applications and

services, with a focus on the home automation /smart home and video surveillance use-

cases and their network architectures.

2.2 Background and Vision of the Internet of Things

The first use of the term ”Internet of Things” can be traced back to an Auto-ID Cen-

tre publication of the Electronic Product Code (EPC) in 2001, which describes a naming

scheme to enumerate and uniquely identify physical objects [71]. This is seen as the pre-

13

14 Literature Review

cursor to a vision of an intelligent network infrastructure that automatically and seam-

lessly links physical objects to the Internet. EPC is based on Radio Frequency Identifiers

(RFID) technology as a replacement for the Universal Product Code. In [72], members of

the Auto-ID Centre, Ashton and Sarma, presented the vision of an EPC Network, mark-

ing the foundation of the Internet of Things in 2003. In the years following this publica-

tion, researchers, scientists and industry practitioners have carried this vision of the IoT.

Today, significant research effort is aimed at the design and development of protocols,

architectures, and software applications for the IoT.

2.2.1 Multiple Visions of the Internet of Things

The IoT is a multi-facet paradigm with many visions. Hence, there are many definitions

of the IoT, and they tend to reflect the vision of the proponent entity, individual or group.

Amongst the definitions surveyed thus far, three (3) complementary and overlapping vi-

sions have been identified: a things oriented vision [1,24], with emphasis on identity and

functionality of things (i.e. sensors, actuators, RFIDs, etc. . . ), an Internet oriented vision

[24,25] with emphases on the network infrastructure and integration with the current In-

ternet, and a semantics oriented vision [1, 24, 73] with emphasis on storing, representing

and accessing generated information.

2.2.2 Definition of the Internet of Things

The International Telecommunications Union (ITU) in its 2005 Internet report describes

the IoT as a dynamic network of networks with connectivity for anything from anyplace

at anytime [1]. This vision is depicted in Figure 2.1. Machine-to-Machine (M2M) commu-

nication – a proxy of the IoT – is interchangeably referred to as the IoT in the literature.

It is generally assumed that today’s M2M deployments are the first implementations of

an IoT domain. Perhaps, a more complete definition is the one given by the Cluster of

European Research Projects on the Internet of Things (CERP-IOT) in a 2009 publication

[73]. In the report, IoT is described as ”an integrated part of future Internet and defined

as a dynamic global network infrastructure with self-configuring capabilities based on

2.2 Background and Vision of the Internet of Things 15

Figure 2.1: ITU definition of the Internet of Things [1]

standard and interoperable communication protocols where physical and virtual ’things’

have identities, physical attributes, and virtual personalities and use intelligent inter-

faces, and are seamlessly integrated into the information network [73].”

The IoT has its roots in several research domains including RFID [74], M2M [75],

Wireless Sensor Networks (WSN) [76], Wireless Personal Area Networks (WPAN) and

Cloud Computing [56]. While the discourse on the IoT tends to focus on the ‘things’

related vision rather than its entire ecosystem, some have argued that the Internet has

always been an IoT and application use cases (e.g. home automation) have been around

for decades [77]. A subtle distinction may well be that the IoT domain leverage current

Internet infrastructure and provides a more accessible end-to-end service, unlike previ-

ous application service architectures that were mostly localised and not widely available.

This is partly due to the availability of data centres (DC) and their accessibility to devel-

opers and manufacturers [56].

2.2.3 Internet of Things Services or Application Use Cases

Several application use-cases are at the forefront of the discussion on IoT for a good rea-

son; i.e. they are at the cutting edge of today’s technological landscape and can easily put

16 Literature Review

the rationale of the IoT into context. The Cisco Report on the “Internet of Everything”

[2] identified eight (8) use-cases that would drive the IoT. CERP-IOT [73] categorises ap-

plications into 3 domains: Industry, Environment and Society, with a whole range of

applications (including the Cisco identified use-cases) falling under the three domains.

Looking at these use-case classifications, one could draw inference that they are repetitive

but represents major industries (e.g. Healthcare, Energy). Having considered the differ-

ent classifications, we can generally categorise IoT applications into 12 main use-cases.

This categorisation is by no mean exhaustive and include:

Home Automation / Connected Home(i) Smart Grid / Energy(ii)

Building Automation / Smart Buildings(iii) Smart Business / Manufacturing(iv)

Smart Cities / Government(v) Connected Retail(vi)

Connected Health / E-Health(vii) Connected Vehicle / Logistics(viii)

Smart Farming / Agriculture(ix) Environmental Monitoring(x)

Smart Roads(xi) Connected Education(xii)

The identified use-case categories represent a summary of future IoT covering both in-

dustry and domestic applications.

2.2.4 Internet of Things Device and Network Traffic Growth

Number of IoT devices and network traffic are set to grow exponentially over the next

decade [78]. Estimates suggest that the number of Internet-connected devices surpassed

that of humans between 2008 and 2009 [2]. Further projections since then (see Figure 2.2)

indicate the number of connected devices by 2020 would range from about 30 - 200 billion

[2–6], the vast variation in numbers being an indication of the degree of uncertainty with

those estimates. In contrast, there were roughly about 2.5 billion Internet-enabled PCs

and cell phones in 2010 [73]. Such growth creates increased traffic demand and subse-

quently, network energy usage as Internet Service Providers (ISPs) expand their networks

2.3 Enabling Technologies for IoT Services 17

Connected IoT Devices by 2020 (Billions)0 50 100 150 200 250

Gartner

ABI Research

IDC

Cisco

Ericsson

PwC

Intel

Figure 2.2: Projected Estimates of Connected Devices by 2020 [2–6]

to meet demand. The 2016 Cisco report (The Zettabyte Era [28]) showed that M2M con-

nections constituted one-third of global device connections in 2015, and is expected to

grow 2.5-fold by 2020. Furthermore, Connected Home or Home Automation & Security

(HAS) applications will represent about 50% of those connections by 2020, making it the

most dominant IoT use-case application, with E-Health being the fastest growing (38%

compound annual growth rate (CAGR)).

The biggest contributing IoT application towards global IP traffic growth would likely

be video surveillance. It is reported that Internet video surveillance traffic will increase

10-fold from 516 PB/month in 2015 to 5.2 EB/month in 2020, constituting about 4% of

global internet video traffic then [28]. IoT/M2M traffic growth is significant as a separate

domain albeit trivial relative to global IP traffic for now.

2.3 Enabling Technologies for IoT Services

A number of technologies have been earmarked as enablers of the IoT, covering the

key areas of unit identification, communication and transport. This section highlights

18 Literature Review

and discusses some of these established and emerging communication technologies and

their relative energy requirements. Communication technologies in focus include a va-

riety of wireless and wired network technologies, network architectures and protocols.

However, the advantages and practicality of un-tethered network connections for IoT de-

vices would ensure that those connections are largely facilitated by wireless technologies

[25, 73]. Hence, this thesis will focus on wireless enabling technologies for IoT services.

This section presents a survey of the most common wireless technologies for the IoT.

They can be classified into two groups: short-range wireless (e.g. Bluetooth Low Energy)

and long-range wireless (e.g. LoRa). The latter is discussed in Chapter 6.

2.3.1 Short-Range Wireless Protocols for IoT Applications

Table 2.1 lists a the most common short-range wireless protocol options and their charac-

teristic features in comparison. These protocols represent a significant percentage of the

wireless standards employed by IoT devices and their applications today. They include

Bluetooth Classic (BT) [16], Bluetooth Low Energy (BLE) [17], ZigBee [18] (based on IEEE

802.15.4 [79]), Z-Wave [19], Wi-Fi [20], EnOcean [80], ANT+ [81] and Radio Frequency

(RF) 433 MHz [82] (referred to as RF433 in this thesis). THREAD (proposed in 2014 [83])

is an emerging wireless protocol for the IoT, based on the IEEE 802.15.4 [79] and IETF

6LoWPAN [84].

2.3.2 Energy Efficiency of Short-Range Wireless Protocols

Of the short-range wireless network protocols surveyed thus far, ZigBee, BLE, ANT+,

THREAD and EnOcean are specifically designed for low-power and low data rate appli-

cations. Wi-Fi and BT were designed for high data throughput applications. Sleep-mode

technique is often employed for reducing the energy consumption of devices. ZigBee,

THREAD, BLE and ANT+ end-devices have characteristic sleep-mode capabilities wo-

ven in their protocol. This is essential to keep current usage to its minimum when de-

vices are inactive. RF433 and EnOcean end-devices are transmit-only (no ACK required).

However, EnOcean is the only energy-neutral protocol as it operates on harvested energy

2.3 Enabling Technologies for IoT Services 19

Table 2.1: Characteristics of common wireless network protocols for IoT applications [16–22]

.Range (m) Device

Protocol Frequency Maximum Indoor / Modulation Network Nodes / Power (mW)Data Rate Outdoor Topology Network (Typical)

Star,ANT+ 2.4 GHz 1 Mb/s 30 GFSK Tree, 352 1 - 10

MeshBT 2.4 GHz 1 - 3 Mb/s 10 GFSK Star 8 10 - 100

BLE 2.4 GHz 1 Mb/s 50 GFSK Star 12 1 - 10EnOcean 868 MHz 125 kb/s 30/300 ASK Star, Mesh 232 < 1

RF433 433 MHz 9.6 kb/s 100 ASK P2P - 10 - 100THREAD Star,

(6LoWPAN 2.4 GHz 250 kb/s 10/100 BPSK, Tree, 250+ 1 - 10& 802.15.4) O-QPSK Mesh

2.4 GHz B/QPSK Star,Wi-Fi 5 GHz 300 Mb/s 100 COFDM Tree, 2007 > 1 W

60 GHz QAM Mesh2.4 GHz 250 kb/s Star,

ZigBee 868 MHz 20 kb/s 10/100 BPSK, Tree, 65536 1 - 10(802.15.4) 915 MHz 40 kb/s O-QPSK Mesh

2.4 GHz 9.6 kb/sZ-Wave 868 MHz 40 kb/s 30/100 FSK, Star, Mesh 232 1 - 10

915 MHz 200 kb/s GFSK

to sense and transmit few bytes of data. RF433 on the other hand is a non-standardised

protocol that is popular with cheap off-the-shelf wireless sensors and actuators (e.g. pas-

sive infrared sensors). RF433 receivers are always-on, listening for transmission from

devices (transmitters).

There are a number of comparative studies in the literature, many of which feature

two or more wireless network communication protocols as given in [34–39]. These stud-

ies specifically discuss energy consumption of end-devices and not the consumption of

the entire end-to-end link. Some of these studies have focused on the energy utilization

of the wireless protocols irrespective of any specific application domain. For example,

the authors in [37] compared power consumption of four wireless protocols (BT, Zig-

Bee, Wi-Fi and Ultra-Wideband) using publicly available information (i.e. datasheet) for

representative wireless modules. Also, the authors in [34] presented a comprehensive

survey of the characteristics of BT and Wi-Fi protocols. Using similar example chipsets

programmed with the same data rate for a single connection scenario, they showed that

Wi-Fi consumes 5-times more power than BT. Applying datasheet values in a simula-

20 Literature Review

tion study of raw data transmission for BLE, ZigBee and Wi-Fi modules, the authors in

[39] showed ZigBee being more energy efficient for low data payloads while Wi-Fi was

least energy efficient; vice-versa for high data payloads. The difference is mainly at-

tributed to the shorter connection time of ZigBee as compared to Wi-Fi, and the larger

frame size of Wi-Fi enabled more data transmission per Tx/Rx transaction for high data

payloads. Other studies conduct measurement-based comparisons as in [35, 36, 38]. The

study in [38] examined the energy consumption of BLE, ZigBee and SimpliciTI (propri-

etary) transceivers in different modes of operation. The authors in [35] on the other-hand

compared only BLE and ZigBee transceivers, with their result showing the energy effi-

ciency of BLE being 2.5-times better than that of ZigBee. In [36], the authors compared

and reported power consumption of BLE, ZigBee and ANT+ protocols in varying cyclic

sleep intervals. They showed that a device sleep current draw is not always indicative of

its long-term energy consumption, highlighting the importance of shorter start-up con-

nection time.

While these studies aim to show one module as being more energy efficient than the

other, it should be noted that energy consumption ultimately depends on the device hard-

ware and this may vary from one manufacturer to the other. With some IoT services now

mainstream (e.g. HAS), and an increasing use of wireless protocols in such applications,

there is a need for application specific studies. IoT applications vary in requirement of bit

rate, latency, packet sizes and QoS and this must be taken into account while assessing

the energy-efficiency of wireless network protocols.

2.4 Network Structure for IoT Services

The network structure of the global IP Network (i.e. the Internet) can be segmented into

4 main parts: the access network, the metropolitan (metro) or edge network, the core

network and data centres (DC) [41]. A network structure for IoT services will include

these segments in addition to a network of IoT devices - built with a variety of network

technologies – referred to as the IoT Device Network (IDN). The IDN is akin to a WSN or

WPAN and may include up to hundreds or thousands of sensors, actuators or cameras,

2.4 Network Structure for IoT Services 21

connected in a mesh, star or cluster-tree topology to a gateway/hub device (i.e. IoT gate-

way). Adapted from [7], a much simplified network structure for IoT services is given in

Figure 2.3. The figure represents a typical ISP transport network infrastructure from the

Data Centre

Core Network Data Centre

Data Centre

IoT Device Network

Access Network

Metro/Edge Network

Data Centre

Cloud

Edge/Fog

Figure 2.3: A simplified schematic diagram of the IoT network structure [7]

access right through to the core network. The cloud DCs are linked to the core network

and provide a centralised storage and analysis facility for IoT sensed or generated data

streams [57]. The Edge/Fog DC provides the same services as cloud, but much closer to

the user’s network [67].

The following section will give an overview of the IoT device network and the differ-

ent segments of a global IP network architecture.

2.4.1 IoT Device Network

Figure 2.4 depicts an expanded view of the IDN. As seen from the figure, the IDN typi-

cally houses a plethora of memory-constrained, low-powered devices (i.e. sensors, actua-

tors, motes, etc.) communicating - via wired or wireless link - with its parent aggregating

network element, known as the IoT gateway. Internet access is then provided to the IoT

gateway (often through Ethernet/Wi-Fi/USB) via an ISP gateway modem at the edge

of the ISP’s access network. The IDN may include a variety of network architectures,

protocols, controls and management systems [19, 44, 85].

IoT gateways could undertake some data processing and storage (i.e. smart gate-

ways) or simply carry-out mundane packetization and encapsulation of acquired sensor

22 Literature Review

IoT Gateway

ISP

Gat

eway

Access Network

ANT+

BLE

ZigBee

= An IoT Device

Ethernet / Wi-Fi / USB

Wired / Wireless

Figure 2.4: Schematic diagram of an IoT device network connected to its parent IoT gate-way and an ISP’s access network.

data (i.e. dumb gateways) en-route to data centres, via the transmission and backhaul

network.

2.4.2 Access Network

The access network connects customer site and the IDN to the local exchange or network

hub. This network segment may contain a few different access technologies in a given re-

gion, but only one of those is used for any particular service. Several access network tech-

nologies deployed today may be considered as the state-of-the-art, and are more likely

to be used in future IoT deployments [86, 87]. These include VDSL2 (Very-high-bit-rate

Digital Subscriber Line) [86,88], the latest of the xDSL technologies, Fibre to the Premises

(FTTP) [87, 89] via Passive Optical Network (PON) and Point-to-Point Optical Networks

(PtP), 3GPP’s fourth generation (4G) Long Term Evolution (4G LTE) [90, 91] and LPWA

(Low Power Wide Area) Networks (e.g. LoRa, Narrowband IoT) [92,93]. While the lead-

ing four access technologies above are widely deployed today for broadband Internet

access, LPWA is a developing technology, designed specifically for IoT communications.

2.4.3 Metro and Edge Network

The metropolitan or edge network aggregates traffic emanating from the central offices.

It links the access and core networks and also ISPs within a city [41, 86]. The metro

network often includes Ethernet switches, broadband network gateways (BNG) and edge

routers. For redundancy purposes, edge switches connect to two or more BNGs and the

2.4 Network Structure for IoT Services 23

edge routers often connect to more than one core router. BNGs also provide access rate

control, authentication, and security services [41]. Unlike the access network with notable

architectural differences for the IoT, the metro/edge network could undergo little or no

changes with IoT deployment.

2.4.4 Core Network

The core network could be considered as the backbone of the global IP network, inter-

connecting cities, countries, and continents. It contains core routers which carry heavy

traffic as they interconnect major population centres. Core routers of a network are often

highly meshed and are interconnected by high capacity wavelength division multiplex-

ing (WDM) fibre links [41], sometimes across oceans.

2.4.5 Data Centres

Data centres are important in providing the services that run on today’s global IP net-

work and are crucial for cloud and IoT applications [57]. Data centres mainly provide

storage and analytic processing capabilities for ever demanding multimedia, business

and IoT applications, with strong data protection reliability [57]. A typical data centre

houses servers and storage equipment, plus a range of telecommunications equipment

including servers, routers, switches and high efficiency data stores. They also house net-

work infrastructure for intra- and inter-data centre connections and linkage with the rest

of the Internet.

Data centres may be classified as centralised or distributed [69]. Fog Computing refers

to a distributed data centre platform typically located at the network edge and provides

storage, compute and networking services to end devices [67]. Generally data centres can

be either private (e.g. corporate cloud) or public (e.g. Google, Amazon EC2).

2.4.6 Energy Consumption of Network Equipment

This section describes key energy consumption attributes and characteristics of network

equipment. The energy consumption of a network element, and network equipment

24 Literature Review

energy modelling, has been the focus of many studies in literature [40, 42, 70, 94–96]. A

network element can be described by its power consumption in both the idle and active

states. Based on measurements [95,96], the power consumption of many types of network

equipment can be modelled with a characteristic linear load-dependence as shown in

Figure 2.5. In many types of network equipment (e.g. routers), the load-dependence is

Pidle

Pmax

Rmax

Pow

er C

onsu

mp

tion

(W

atts

)

Load (bit/sec)

P(t)

R (t)

Slope = E

Figure 2.5: Power consumption profile of a generic network element

only slight. In the figure, P (t) represents the power consumption of a network element

with a maximum capacity Rmax (bit/sec) and actual traffic load R(t) (bit/sec). P (t) can

be expressed as:

P (t) = Pidle +

(Pmax − Pidle

Rmax

)R(t) = Pidle + ER(t) (2.1)

where Pidle is its no-load power consumption (when R(t) = 0) and E, its incremental

energy-per-bit (where E = (Pmax − Pidle)/Rmax), given by the slope of the graph. The

expression of power consumption of a network element given in equation (2.1) will be

used as the basis for network equipment modelling in this thesis.

2.5 Systems, Architecture and Energy Consumption of IoT Services 25

2.5 Systems, Architecture and Energy Consumption of IoT Ser-vices

In Section 2.2.3, a number of IoT use-case services across many industries were identified.

Then, the most popular IoT services by device numbers and traffic growth rate were

discussed in Section 2.2.4. HAS services would constitute about half of all connected

devices by 2020 while video surveillance will be the most data-intensive IoT service [28].

We use these two services as case studies in this work. In the following section, a review

of the different systems employed for the delivery of these services is given. Then, a

review of research on the energy efficiency of systems and architectures of the above

services is presented.

2.5.1 HAS / Smart Home Systems

Home Automation has been described as ”the introduction of technology within the

home to enhance the quality of life of its occupants, through the provision of different

services such as multimedia entertainment, energy conservation and security” [97]. In

its simplest form, HAS is a system of wireless network-enabled devices that can self-

identify, collect data and in some cases process data about their surroundings. This data

is often transmitted to a central processing centre (i.e. cloud) via a home gateway mo-

dem, a cellular Base Station or a specialised network grid. Essentially, an IDN is setup in

the home to connect IoT devices through a gateway to the public network or cloud, using

short-range wireless protocols discussed in the previous sections.

Early HAS system architectures were mostly localised or stand-alone systems, with

events and commands routed locally (sometimes with web-access), and acquired data

stored in local storage (e.g. PC) [98, 99]. However, the concept of the IoT and availability

of access to affordable data centres, (providing a choice of Infrastructure, Platform and

Software as a Service, e.g. Amazon EC2) encouraged the design of many cloud-based

HAS systems in the literature [100–102]. Today, HAS systems (e.g. SmartThings [103])

are often bundled as a service which includes the hardware sensors, actuators, and other

smart/IoT devices, a gateway device (i.e. IoT gateway) that interacts with and intercon-

26 Literature Review

nects the IoT devices and aggregates traffic generated by the said devices. That traffic is

passed through the public network, to a cloud service that is part of ”the bundle”, and

includes applications to manage, control and store data collected from the devices for

future use [15, 103, 104].

A survey of the different classes of HAS systems and some proposed energy efficient

architecture are discussed in the sections below.

2.5.2 Localised HAS Systems

A number of localised or stand-alone HAS systems have been proposed [98,99]. Consid-

ering a monitoring and access HAS application type, A. Al-Ali et al. in 2004 [99] designed

a Java-based HAS system using circuit boards with direct wired connections to devices

and relays for on/off switching. A PC serves as the main processing unit and as web-

server for remote access.

K. Gill et al. in [98] put forward one of the first ZigBee-based system for HAS services.

This design was proposed in 2009 as an alternative to wired-based systems [99] and to

mitigate energy cost and lack of interoperability between home networks technologies

(e.g. Bluetooth, PLC). The study was motivated by the lack of an off-the-shelf home gate-

way solution that could integrate multiple networks. A factor in that choice was that

Bluetooth shares the ISM frequency band with Wi-Fi and many other RF appliance ap-

plications, it is more susceptible to interference and suffer potential throughput degrada-

tion. In their design a Wi-Fi enabled home gateway provides high data rate connections

to multi-media devices via its Wi-Fi interface (802.11g) while sensors or actuators (fit-

ted with ZigBee interfaces) with low data rate demand, connect to the home gateway

via a ZigBee Coordinator [18]. The home gateway holds a local database of devices in

the network and services user remote commands to control devices and receive events.

The system provides neither sensor/multi-media data storage nor retrieval; hence data

collection is not an option. Such localised systems are vulnerable to a single point of

failure unlike their cloud-based counterpart. Furthermore, localised HAS systems are

less scalable with limited resources which can be a major weakness when compared to

cloud-based systems.

2.5 Systems, Architecture and Energy Consumption of IoT Services 27

2.5.3 Cloud-based HAS Systems

A cloud-based system architecture is particularly suited and often used in IoT applica-

tions or system deployments because it provides the benefits of cloud computing (i.e.

unlimited access and storage, scalability with over 99% availability [56]). Cloud-based

HAS systems have been proposed by several researchers [100–102]. Similar to many

other cloud applications, cloud-based HAS application services basically collect sensor

data from the edge of the home network, sometimes from sensors of local networks, to

be analysed, processed and stored in data centres for ”anytime” access by users or ma-

chines [100, 102]. System architectures for disability and wellness or elderly HAS appli-

cations come with additional challenges like latency and security requirements that must

be achieved for success [105–107].

M. Domingo in [107] proposed a HAS system based on the IEEE P2413 three-tiered

model (i.e. Application, Network and Perception). The proposed architecture provides a

signalling platform to address latency and mobility requirements for critical applications.

N. Lopes et al. in [106] argues for a four-tier architecture, splitting the application layer

above into two (i.e. application and service). Their argument is based on presenting a

homogeneous, independent and context-aware service to applications, whilst hiding the

heterogeneity of the network layer caused by different transport infrastructure and data

transmission. The study in [106] also calls for an all IP network architecture including an

IP wireless sensor network by virtue of IETF 6LoWPAN.

S. Kelly et al. [108] proposed a cloud-based energy management system whilst L.

Kau et al. in [102] proposed an environmental home monitoring system. Both systems

are ZigBee-based. S. Kelly et al. however designed as an integrated IoT gateway for

seamless routing (and address translation) between the ZigBee network and the IPv6

LAN. Their IoT sensing modules are reported to have a throughput of 1.6 b/s each, with

97% reliability. However, they did not use the more efficient 6LoWPAN protocol.

28 Literature Review

2.5.4 Energy Consumption of HAS Systems

Renewed attention on HAS systems stems from recent activities in the IoT space and its

estimated exponential growth in traffic and device numbers [2, 28]. Equally so, energy

consumption of the Internet and its services have received its share of attention with

many models and estimates available in literature [40,41,109]. Reducing energy usage of

the global IP network or ensuring growth in an energy efficient manner begins with the

design of energy-efficient applications and services.

According to a 2013 IEA report [31], global energy consumption of network-enabled

devices is forecasted to grow from 615 TWh in 2013 to 1,140 TWh in 2025, if no improve-

ments are made to the ICT industry’s energy usage. A 2015 study by Andrae et al. [32]

shows the electricity usage trend of consumer devices is estimated to peak at about 1,330

TWh in 2022 if only 1% annual improvement in energy efficiency is effected from 2010.

However, these estimates are based on network-enabled devices including PCs, Laptops,

Smart TVs, mobile phones and home entertainment systems, not including IoT devices

such as IoT gateways, sensors, actuators, security cameras and consumer appliances (e.g.

connected refrigerator).

Studies on energy consumption of HAS often take a more device-centric approach [22,

27, 44–50] while some take a more network-centric focus [51, 52] and others concentrate

on processing and storage centres [53]. These studies offer a variety of techniques for

improving energy efficiency, including duty-cycle optimisation, sleep-modes, efficient

node placement, routing mechanisms, lower information transfer rate, virtualization and

a move towards distributed computing.

A more related study is a 2016 IEA report [22] which estimates the standby energy

consumption of mains-powered IoT devices for a number of IoT use case applications

(e.g. Smart Lighting, Home Automation and Smart Roads). The authors considered

a measurement-based bottom-up approach for readily available devices, and relied on

vendor information, data from literature and their own estimates where measurement

was impractical. Using market-based device shipment projections, they estimated the

standby energy consumption of these use-case applications to reach 46 TWh by 2025

with home automation bearing 78% share of the total.

2.5 Systems, Architecture and Energy Consumption of IoT Services 29

Note that this is an estimate of standby energy only. Some devices (e.g. IoT gateway),

however, are critical enablers of the IoT, without which the ”smartness” of the system is

unachievable. An argument can be made that such devices should be considered as the

”price of entry” for an IoT system and their full energy consumption included in such

analysis (not just the standby energy). Furthermore, IEA’s estimate for the number IoT

devices per household are somewhat conservative.

Hence a full understanding of the energy impact of billions of IoT devices on ICT

industry energy consumption is necessary and merits further investigation.

2.5.5 Energy Consumption of Video Surveillance Systems

Legacy video surveillance systems required analog camera units, separate video encoder

devices (for image digitisation, compression and encoding), video streaming servers

(for transmitting captured video frames across the network or storage of video files)

and in some cases dedicating point-to-point cabling (e.g. PSTN leased-lines) [10, 11].

Hence, legacy video streaming services were inefficient and costly, limiting deployment

to mostly corporate sites and government installations [11].

Modern video surveillance systems are generally more efficient, due to a number of

factors including their simplicity and system integration; a user today could set up a

home security system in a matter of minutes, without the complexity (separate video

encoder, server and storage devices) and cost associated with legacy video surveillance

systems [10,11]. Another factor is the emergence of cloud computing services, which pro-

vide reliable and secure processing and storage, simplifying the provisioning of stream-

ing applications by service providers and users alike [56, 57].

Studies in this area includes the design of energy-efficient video sensor devices [12,

61], efficient multi-camera coverage overlap [62], local video processing as opposed to

cloud [63, 64] and balancing energy consumption with key video parameters [65, 66]. In

order to investigate the issues with using existing video streaming protocols like DASH

(Dynamic Adaptive Streaming over HTTP) for IoT video streaming, R. Pereira et al. in

[110] conducted experiments on streaming video from 6LoWPAN enabled devices with

limited packet size.

30 Literature Review

2.6 Energy Efficiency of IoT Network Architectures

Prior to the commencement of this research work, very few studies had considered the

energy consumption of IoT networks or energy efficiency of IoT architectures. This can

be attributed to the relative embryonic nature of the IoT ecosystem, which limits the

pool of literature available to the researcher. Many studies however considers the energy

efficiency of the IoT devices in the form of sensors and actuators. Some of these studies

are discussed here.

M. Tenaja in [45] proposed a framework for power reduction of IoT devices and gate-

ways within an IoT network architecture. The framework is based on a systematic data

buffering algorithm that prolongs sleep-mode durations while considering key factors

like QoS requirements, congestion and buffer size. The framework is built on IEEE

802.15.4 [111] based devices with inherent sleep states. The algorithm sought to limit

further transmission of notification beacons from an IoT gateway/coordinator to an IoT

device/end-device when some data is pending for the said IoT device and also delays

the response of the device to acknowledge and request pending data be transmitted im-

mediately. Ultimately, the IoT device makes the decision on whether the pending data is

critical (i.e. send immediately) or non-critical (i.e. hold-off transmission) and if the lat-

ter is true, the device stays in sleep mode for extended period of time, saving energy in

the process. The study however did not take synchronisation requirements into consid-

eration which can limit the energy savings and did not show simulations or numerical

analysis of the algorithm.

Z. Al-Azez et al. in [53] proposed an energy efficient IoT network architecture that is

based on a virtualization framework. In their model, data from the IoT devices - commu-

nicating using ZigBee protocol [18] - can be analysed either by relay nodes, the coordi-

nator (aggregation device) or the IoT gateway, each of which can host a distributed mini

cloud service. The mini cloud service is represented by a virtual machine (VM) placed

at the desired node with the aim of processing larger volumes of IoT data locally (i.e. at

the optimal position, e.g. relay node) while reducing the upstream traffic to centralised

cloud services. The authors claim the power savings are achieved by an optimal place-

ment of the distributed mini cloud services/VMs and by reducing the number of cloud

2.7 Carbon Footprint of IoT Services 31

services required to handle the traffic load. Their result estimates a 90% reduction in IoT

data traffic volume with up to 36% reduction in network power consumption.

J. Huang et al. in [46] proposed an energy optimised system framework for deploy-

ment of IoT network using an optimisation algorithm. The author’s model is based on

3-layer framework: sensing layer (i.e. sensors), relay layer (i.e. mesh routers) and conver-

gence (i.e gateway). The algorithm aims at reducing the number of relay nodes within the

network while subject to several constraints including energy budget and routing path.

Their results indicates much longer network lifetime when the algorithm is implemented

in deploying nodes unlike random placement and typical sensor network deployment

schemes. The study by J. Huang et al. [46] focuses on the IDN and reducing the overall

network energy of the IDN. The transport energy beyond the gateway is not considered.

A similar study to [46] by P. Sarwesh et al. [47] proposes an energy-efficient node

placement and routing mechanism to reduce energy usage in order to prolong sensor

battery lifetime. The authors showed a reference architecture with random placement

of sensor and relay nodes (no sensing) as compared to the proposed architecture. The

proposed network architecture ensures a balance network energy consumption by re-

routing packets through relay nodes with higher battery life remaining. Again, this study

takes a narrow look at the IoT network with focus on the IoT devices while ignoring the

gateway energy and transport energy to the Internet core.

2.7 Carbon Footprint of IoT Services

One major component in relation to sustainability or the environmental impact of a prod-

uct or service is its energy consumption. In order to fully understand the environmental

impact of IoT devices and their services, a life cycle assessment (LCA) is needed. The

product of such an assessment is often characterised as its carbon footprint. For IoT

devices, an LCA will involve an estimate of its carbon footprint from design and produc-

tion to its use-phase and end-of-use processes. A complete environmental impact must

also consider batteries (including their embedded energy) which would likely be a major

power source for a significant proportion of IoT devices.

32 Literature Review

While this study will mainly focus on the use-phase energy consumption of some

well-known IoT services, there is need for a detail and complete carbon footprint estimate

of IoT services and the IoT eco-system as a whole. A close example is the study on carbon

footprint of the global ICT sector [112], which suggests, based on device forecast, that

future IoT may contribute a marginal increment to the global ICT carbon footprint. IoT

devices and their data networks however have emerged as useful application tools for

performing more accurate product life cycle assessment and energy management of other

products and services across many sectors in recent studies [113, 114].

2.8 Summary of Literature and Conclusion

In this literature review, we surveyed existing and future IoT services, their enabling tech-

nologies and architectures, and existing research on their respective energy consumption.

The most dominant and promising services - HAS and Video Surveillance - were se-

lected as case studies. We surveyed a variety of application system design approaches

for HAS services. Early HAS applications were based on a localised server-client sys-

tem [85, 98, 99] where data generated by end-devices are stored on low capacity, less

efficient spinning disks and processed at a higher energy cost on PCs/ local gateways.

These approaches were also based on protocols that were neither designed nor optimised

for energy-efficiency. The second approach (i.e. cloud-based) is predominantly used by

many systems and services today [100–102, 105, 106]. These systems are based on cloud

computing, which provides centralised storage and processing facilities at data centres

[56, 57]. However, there exist a number of limitations with cloud-based services, one

of which is their energy consumption [69]. Video surveillance services may contribute

the greatest share to global IP network traffic increase [78]. However, studies on video

surveillance applications mostly consider the energy efficiency of the end-devices with

little work on an end-to-end characterisation of the service [65, 66]. To the best of our

knowledge, there was only one study that specifically focused on the assessment of en-

ergy consumption of an IoT service and its impact on the ICT industry [22].

In this chapter, we identified the gaps in studies on energy consumption of IoT ap-

2.8 Summary of Literature and Conclusion 33

plications and services, and showed that a comprehensive investigation and analysis of

the total energy consumption of IoT services is required, in order to gain a better under-

standing of their energy implications. There is also merit in such study for an estimate

of the potential global energy impact of these services on the ICT industry and its carbon

footprint. In this thesis we aim to fill these gaps providing the following:

(a) Direct detailed power and packet traffic measurement of representative IoT devices

(including sensors, actuators and IP cameras), gateways and modems are presented.

(b) New measurement-based energy consumption models for the individual compo-

nents and the complete HAS is developed and the model used to estimate the annual

energy consumption of the service.

(c) A shared energy consumption model for the home gateway modem is developed and

used to allocate a portion of the device energy attributable to the IoT traffic.

(d) Developed energy consumption models are applied to estimate the global energy

consumption of an IoT service and its impact on the ICT industry.

(e) Direct power consumption measurement of the five most common wireless network

protocols for IoT applications are presented and those measurements applied in a

comparative study using a simple IoT domestic stock-control application.

(f) Energy consumption models for four (4) dissimilar network architectures (Cloud and

Fog computing based) that can be used in the delivery of IoT video surveillance ser-

vices are developed and evaluated.

(g) A number of existing and emerging access network technologies (e.g. PON, LPWA)

suitable for the delivery of IoT services are modelled and first-order estimates applied

in a comparative study.

The measurements, modelling and estimation of the energy consumption of a HAS

service is given in Chapter 3 and the measurements and evaluation of wireless network

protocols detailed in Chapter 4. Chapter 5 provides the energy consumption study of

Cloud and Fog computing-based network architectures and the power consumption of

IoT access network technologies discussed in Chapter 6.

Chapter 3

Energy Consumption of HomeAutomation and Security Systems

3.1 Introduction

THE dawn of an ever-connected world with the Internet of Things (IoT) brings

unique capabilities, capacity and opportunities for a networked way of life. Of

the IoT use-cases discussed in Chapter 2, the home automation and security (HAS) use-

case may be the most well-known as many technology pioneers (e.g. Apple, Amazon

and Google) have delved into bringing a connected home to fruition. Additionally, HAS

services are expected to represent nearly 50% of all IoT device connections by 2020 [28].

While there could be many benefits of a HAS or ”smart home”, the proliferation

of billions of IoT devices comes with several potential risks and added levels of cost;

one of which is the additional electrical energy required to power these devices and

the idle/standby energy consumption required to maintain connectivity and/or their

”smartness”. An IoT device for HAS needs to have network connectivity almost all the

time [1]. This means that, at a minimum, its communication module or some part of it

must either maintain a connection with the gateway, or be able to initiate a connection

within the shortest possible time (e.g. reverse polling in ZigBee [111]). A significant ques-

tion arising from this added idle/standby energy is its magnitude relative to global ICT

energy consumption.

At the time of writing, this researcher is aware of only one other study - discussed

35

36 Energy Consumption of Home Automation and Security Systems

in the literature survey in Chapter 2 - aimed at quantifying the energy consumption of a

HAS and its potential impact on global ICT energy consumption. This chapter seeks to

illuminate the issue of energy consumption, as related to IoT use-case applications, with

a HAS as a test case. The contributions of the chapter are as follows:

(i) Measurement-based energy consumption models for sensors, actuators and an IoT

gateway associated with a HAS.

(ii) Application of an energy allocation regime for the home gateway energy consump-

tion to an IoT HAS, using a ”shared” energy model based on average data rates.

(iii) An energy consumption estimate of a HAS when installed at a mid-size suburban

household.

(iv) Global energy consumption estimate of HAS using a projection of the installed base.

The rest of this chapter is organised as follows: A description of HAS and its architecture

is given in Section 3.2. A HAS energy consumption model is detailed in Section 3.3.

Section 3.4 describes the experimental measurement methods applied in this work, while

the results of measurements of the energy consumption and data traffic for a range of

devices is reported in Section 3.5. An estimation of the energy consumption attributable

to a HAS in a mid-size suburban home is given in Section 3.6, together with an estimate

of the global energy impact of such consumption using HAS market device shipment

projections. The section also includes energy consumption estimates for smart homes in

two major markets. The chapter findings are summarised in Section 3.7.

3.2 Home Automation & Security System (HAS)

The main components of a typical HAS include IoT devices (i.e. sensors, actuators, smart

devices, etc.), a gateway device which provides network access to said IoT devices, and a

cloud service for data processing and storage. A user of a functional HAS could control,

actuate or access the system using web-based applications on a browser or a smartphone

mobile application, either via local access (e.g. Wi-Fi) through the home gateway device

or via the public network infrastructure.

3.2 Home Automation & Security System (HAS) 37

3.2.1 IoT Devices

There are different classes of IoT devices including, for example, wearables, sensors and

actuators, RFID tags, smartcards and consumer appliances. However, the scope of this

work is limited to devices ”typical” of a home. Hence, wearables, RFID tags and smart-

cards are excluded for the simple reason that wearables are often designed with a mobile

phone as a gateway, necessitating a different network architecture, while RFID tags and

smartcards require readers [24, 74] which are uncommon in a home setting.

IoT devices can be powered by four main sources: (i) mains power, (ii) battery power,

(iii) energy harvesting (iv) direct connection to a renewable energy source [22,24,25]. Due

to the need for untethered connections (i.e. wireless), installation convenience and cost,

most home IoT devices are likely to be battery-powered [24, 25]. In this work, the focus

will be on off-the-shelf network-enabled IoT devices, which today are mostly battery-

powered or mains-powered.

3.2.2 IoT Device Structure

A schematic diagram of a generic IoT device is shown in Figure 3.1. The device comprises

of three main elements: the Sensor or Actuator Unit (SAU), the Microcontroller Unit

(MCU) and a transceiver (communication module). The IoT devices studied so far are

either sensors or actuators and will be modelled as such. Therefore the IoT device in

Figure 3.1 can function as:

(i) Sensor Device: As a sensor device, a physical quantity datum is acquired (an external

physical process) by the sensor (e.g. transducer) and fed into the MCU, often via

an Analog-to-Digital Converter (ADC) which digitises the analog signals produced

by the sensor. The data is processed and in some cases stored to memory by the

MCU, often using an instruction set from a Real-Time Operating System (RTOS)

in memory (e.g. Flash memory). The MCU then prepares and transfers (using a

communication protocol, e.g. UART, SPI, I2C, etc.) the data to the communication

module for onward transmission to the gateway device (e.g. IoT gateway).

38 Energy Consumption of Home Automation and Security Systems

To IoT Gateway

Acquisition

Power(Mains / Battery)

Actuation

(External Physical Quantity)

Rad

io(C

om

mu

nicatio

n M

od

ule

)ActuatorSensor

IoT DeviceSen

sor

or

Act

uat

or

Uni

t (S

AU

)

ADC DAC

Microcontroller (MCU)

Memory(e.g. SRAM)

UART

SPI, I2C

PDEV

Figure 3.1: Schematic diagram of a generic IoT device.

(ii) Actuator Device: As an actuator device, a command received via the communica-

tion module gets processed by the MCU. The MCU can then send interpreted com-

mands/instructions to the actuator via a Digital-to-Analog Converter (DAC) when

required.

Generally, the process of sensing or actuating repeats over time. The energy consumed

by these processes in addition to energy drain when inactive/idle accounts for the total

energy consumption of the device. Some devices operate autonomously, so that for ex-

ample the sense-process-communicate flow repeats periodically. For others, the device

operation is triggered by an external event (e.g. a button press, door opening). Note

that while the three main elements described here are fundamental in most IoT devices,

a sensor/actuator device may include other elements (e.g. GPS, display unit) that are

application-specific, often with additional energy requirements of their own [76]. Fur-

thermore, a number of operating system choices (e.g. CoAP, TinyOS) have a variety of

operational requirements (e.g. OS monitoring, keep-alive) and additional complexities

with higher energy requirements [49, 76]. These are outside the scope of this work and

will not be accounted for in the modelling. For simplicity, the sensor and actuator blocks

in Figure 3.1 are referred to as the sensor or actuator unit (SAU) in the model.

3.2 Home Automation & Security System (HAS) 39

3.2.3 IoT Device Network for HAS

The IoT Device Network (IDN) here refers to a network of IoT devices within a HAS

with a common gateway (i.e. the IGW). In its most common form, communication be-

tween the IoT devices and IGW is facilitated via a wireless link. A number of short-

range wireless protocols are often deployed for HAS including Bluetooth (Classic and

Smart/Low-Energy), ZigBee, Wi-Fi, Z-Wave and RF 433 MHz. While many of these pro-

tocols are designed for point-to-point communication with a star-topology, a few can

operate in a mesh topology (e.g. ZigBee [18]) forming a daisy chain of links towards the

gateway. One disadvantage with a mesh topology is the presence of routers/repeaters

along the chain which must remain in an active state, consuming more energy, unlike the

end-devices (which can switch to standby/sleep state when inactive) [18, 111]. A point-

to-point single-hop, star-topology connection between the IoT devices and the IGW is

modelled in this work.

3.2.4 HAS Architecture

Many different network architectures for HAS have been proposed in the literature as

discussed in Chapter 2. Typically such architectures are cloud-based [100–102], struc-

tured around a client-server model. Figure 3.2 shows a simplified network architecture

of a HAS linked to a cloud computing service, with data storage at a data centre.

The HAS architecture shown in Figure 3.2 consists of the IoT devices within the IDN,

an IoT gateway, a home gateway/modem and data centres hosting cloud services, con-

nected via the Internet. At the centre of the IDN is the IGW which can act as a network

access device, a management and control device and an aggregator for IoT devices on the

local network or IDN. In a ”typical” installation, the IGW connects to the HGW either via

Ethernet line or Wi-Fi as in [15, 103, 104]. The IGW is also considered as a client-device

in some IoT cloud-based architectures [15, 102], with its unique identifier (e.g. MAC ad-

dress) utilised for authentication and authorisation purposes.

The HGW links the IGW and all IoT devices to the public network and data centres.

The HGW also handles the customer’s other network services. The first link from the

40 Energy Consumption of Home Automation and Security Systems

Internet

Home

Home Gateway (Modem)

IoT Gateway (IGW)

Data Centres

IoT Devices (e.g. sensors, smart appliances, ...)

xDSL, PON, HFC

PC, Laptop, Smartphone, Tablet, etc.

Figure 3.2: Simple diagram of a Home Automation & Security System supported bycloud data store and services.

HGW into the public network is known as the access network, and may employ differ-

ent access technologies (discussed in Chapter 6) including xDSL technologies, Passive

Optical Network (PON) and Hybrid Fibre-Coaxial (HFC) technologies. For the purpose

of estimating the additional energy cost of an IoT HAS, the network segment beyond

the HGW is not considered in this chapter. An analysis involving the energy cost of IoT

cloud-based applications and services which incorporates the energy consumption of the

transport network and data centres is discussed in Chapter 5.

3.3 Home Automation and Security System Energy Model

As described above, a HAS can be sub-divided into 3 main segments: (i) the IoT devices,

(ii) IoT gateway and (iii) the home gateway/modem, with the first two forming the IDN.

Each has its individual energy characteristics as will be described in the following section;

therefore each segment will be modelled separately. For a simple HAS as depicted in

Figure 3.2, the total energy consumption EHAS over a diurnal cycle is given by:

3.3 Home Automation and Security System Energy Model 41

EHAS = EDVS + EIGW + EHGW (3.1)

where EDVS is the total energy consumed by the IoT devices and corresponds to the sum

of energy (EDEV,i) consumed by each individual IoT device i within the HAS, such that

EDVS =∑N

i=1 EDEV,i, for i = 1, 2, ..., N , where N is the total number of devices; EIGW

represents the energy consumed by the IoT gateway and EHGW represents a share of the

energy (discussed in section 3.3.6) consumed by the home gateway device attributable to

the IoT traffic it supports. The following sections present energy models for these three

segments.

3.3.1 Modelling the Energy Consumption of an IoT Device

Over time, an IoT device will run through several operational cycles, initiated by its timer

or in response to an external stimulus. Typically, an operation includes a sequence of

tasks (e.g. sense, actuate, process, transmit/receive) which may be executed sequen-

tially or concurrently in time, and consume similar amounts of energy at every instance

[48, 49]. The factors that influence the energy consumption of an IoT device include the

message transfer rate, the type of wireless channel, the signal duty-cycle, the communi-

cation protocol, data security (i.e. authentication and encryption) and any redundancy

mechanisms (e.g. Retransmissions and ACKs) [48, 50]. Generally, a shorter duty-cycle

with longer sleep or standby periods could lower the energy consumption, hence length-

ening battery life [27, 48].

Let us consider the IoT device as shown in Figure 3.1. Drawing from the literature

and our in-house measurements (see Appendix A) of a number of IoT sensor and actua-

tor devices, the power consumption signature of these devices often show distinct power

levels attributable to individual tasks over a period of time. We can break down these

power levels into three fundamental tasks [i.e. sensing (acquisition) or actuation, pro-

cessing and communication] and the device standby state. A more detailed analysis of

the power consumption of specific IoT devices is presented in section 3.5.1.

For an IoT sensor device in a standby state, its power draw can be extremely low (few

42 Energy Consumption of Home Automation and Security Systems

µW) and is attributed to maintaining some elements of the device circuitry like the syn-

chronisation clock, volatile memory (e.g. SRAMs) and the MCU in sleep mode. Many

sensor devices follow the sense-process-communicate work-flow while others may be

polled (i.e. the communication module’s receiver is always on, often resulting in much

higher energy use over a long period of time) to trigger this work-flow. The power draw

of the sensing task is indicative of the power used to excite a transducer and may include

some low-levels of processing and storage associated with each task (e.g. ADC, DAC,

data averaging). The power draw of the processing task is reflective of the operations car-

ried out by the MCU, which may involve a number of smaller tasks including memory ac-

cess, data pre-processing/computation (e.g. data formatting and averaging), application

of error-correction techniques like Cyclic Redundancy Checks (CRC), and transmission

control. The power draw of the communications task is indicative of a set of processes

which may include transmission (Tx) and reception (Rx), Tx/Rx switching, modulation,

media access control processes (e.g. CSMA/CA) and interference-mitigation. These pro-

cesses have varying effect on the energy consumption of an RF radio depending on a

number of factors including the condition of the wireless channel, point-to-point dis-

tance and transmit power [76, 115]. To compensate for the inefficiencies of the wireless

channel, some devices perform multiple retransmissions of the same message to increase

the probability of successful message delivery.

For an IoT actuator device, its standby power may however be much higher than

most sensor devices because it is required to maintain some level of connectivity with

the gateway device in order to receive messages/commands (similar to a polled sen-

sor device). Generally, the work-flow of actuator devices are the reverse of sensors (i.e.

communicate-process-actuate) but with similar smaller tasks (e.g. ADC, DAC, memory

access, etc.). The power draw of the communication task is mainly attributed to the re-

ception of a command and that of the processing task, attributed to the interpretation of

such command. Lastly, the power draw of the actuating task is indicative of the power

for switching a relay, which may activate a secondary device with far more significant

power demands (e.g. the motor of an automatic garage door). The power consumption

of the secondary device is not considered in this model.

3.3 Home Automation and Security System Energy Model 43

Energy Consumption Model

To model an IoT device, consider the schema of a generic device given in Figure 3.1. The

total power consumed by an IoT device PDEV(t) at time t can be characterised by the

power consumed by its individual components and their processes and expressed as:

PDEV(t) = PSAU(t) + PMCU(t) + PCOM(t) + PSBY (3.2)

where PSBY is the power dissipated when the device is inactive or in a standby state,

PSAU is the additional power consumed by the sensor or actuator unit (SAU); PMCU is

the additional power consumed by the MCU and its interfaces in processing or handling

sample data or commands and PCOM, the additional power required for data commu-

nication with the gateway. For any particular IoT device, the energy required for each

sensing/actuating, processing or communications task can be expressed as the integral

of its instantaneous power consumption over the duration of said task as given by:

ESAU =

∫tSAU

PSAU(t)dt ; EMCU =

∫tMCU

PMCU(t)dt and ECOM =

∫tCOM

PCOM(t)dt

Over a given period of time (e.g. a day), there will be multiple sensing/actuating, pro-

cessing and communications tasks. Let there be NSAU sensing/actuating tasks, NMCU

processing tasks and NCOM communications tasks. Over that period, the total energy

consumption of an IoT device EDEV for total time T seconds is given as:

EDEV =∑j

ESAUj+∑k

EMCUk+∑m

ECOMm + ESBY (3.3)

where j = 1, 2, ..., NSAU, k = 1, 2, ..., NMCU, m = 1, 2, ..., NCOM and ESBY = PSBYT , for

PSBY = constant.

It is assumed that the SAU, MCU and COM tasks are independent processes. For an in-

dependent process X with a large sampling distribution (N 30), the expected value

E[X] = 〈X〉 =1

N

∑j Xj where j = 1, 2, ..., N . Using this expression and above assump-

44 Energy Consumption of Home Automation and Security Systems

tion, we can rewrite equation (3.3) as:

EDEV = NSAU〈ESAU〉+NMCU〈EMCU〉+NCOM〈ECOM〉+ ESBY (3.4)

3.3.2 Modelling a Sensor Device

Many sensor devices operate at very low duty-cycle (e.g. battery-powered temperature

sensor [116]) and are only active for a short burst of time, often with the majority of

their operational lifetime spent in the standby or sleep state. Most sensor devices can

be classified into one of two main types based on their differences in application and

communication methods. These two types are referred to as: (i) time-based sensor device

and (ii) event-driven sensor device in this model.

Time-Based Sensor Device

Time-based sensor devices perform periodic operations (e.g. once a minute) with fixed

intervals over time (e.g. temperature, pressure sensor devices). Figure 3.3 depicts the

PDEV

tCOM

Time (t)tMCU

1 Cycle (TC)

tSEN

0

PSEN

PMCU

PCOM

PSBY

Communications (COM)

Processing (MCU)

Sensing (SEN)

Standby (SBY)

NR

Figure 3.3: Example power consumption time evolution of a time-based sensor deviceoperating periodically with fixed intervals between transmissions.

3.3 Home Automation and Security System Energy Model 45

power consumption time evolution of a time-based sensor device. This figure emulates the

measured behaviour of example sensor devices (see Appendix A) on which the model is

developed. Each operational cycle consists of the three main tasks:

(i) Collect each data sample within a timeframe tSEN. A total of NSEN samples are

collected in one operational cycle. Depending on the application and the particular

device, only one, or many sample(s) may be collected per cycle.

(ii) Process or analyse the data samples collected using instructions/code in memory

within time tMCU. The data is also prepared for onward transmission via a commu-

nications module.

(iii) Transmit collected data to a parent device in time tCOM with NR number of retrans-

missions per message (e.g. NR = 3 as shown in Figure 3.3). A parent device can be

an IoT gateway or intermediate routing devices in a mesh network.

Figure 3.3 also includes a standby phase between the three main tasks when the system

is inactive. The figure shows PSBY continues through the SEN, MCU and COM periods

because the functions that make up this power consumption (e.g. basic clock, memory

keep-alive) continue concurrently with the main tasks. For a given sensor device, it is

assumed that the energy consumed for a particular task x (i.e. Ex = 〈Px〉× tx) is constant.

An expression of the energy consumption of a time-based sensor device (ts) for 1 complete

operational cycle (E(ts)DEVC) with a duration TC is therefore given by:

E(ts)DEVC= NSENESEN +NMCUEMCU +NCOM

(NRECOM

)+ ESBYC (3.5)

where NR > 1 and ESBYC = PSBYTC. The total energy consumption of a time-based sensor

device with NC cycles of operation over a long operating time T is then given as:

E(ts)DEV(T ) = NC(T )× E(ts)DEVC(3.6)

46 Energy Consumption of Home Automation and Security Systems

Event-Driven Sensor Device

An event-driven sensor device performs tasks at irregular intervals in response to an ex-

ternally observed phenomenon (e.g. motion/door sensor devices). This is known as an

event. A power consumption time evolution of an event-driven sensor device is shown

on in Figure 3.4. Similar to its time-based counterpart, an event-driven sensor device per-

PDEV

Time (t)tMCU

1 Event

tSEN

0

Trigger

PMCU

PSEN

PSBY

Communications (COM)

Processing (MCU)

Sensing (SEN)

Standby (SBY)

tCOM

PCOM

NR

Figure 3.4: Example power consumption time evolution of an event-driven sensor deviceoperating on randomly triggered events.

forms three main tasks. In most cases, the sensing task (with time tSEN) is continuous,

so that PSEN and PSBY are indistinguishable. The diagram and the model to follow allow

for this case, and for any in which the sensing period is interrupted, for example, so as

to prevent repetitive triggers arising from the same event, as is the case with some PIR

sensor devices (see Appendix A). Alternatively, for some other event-driven sensor de-

vices, the sensing process may be a continuous low-level communication process (i.e. a

radio receiver in listening mode) that receives a trigger or poll (an event) from its parent

gateway. The sensing process can be active with relatively low power draw, or passive

with negligible power draw (e.g. PIR). When an event is detected, the MCU is activated

3.3 Home Automation and Security System Energy Model 47

to process or analyse the data received from the sensor unit in time tMCU and determines

whether or not the data should be sent off via the communication module in time tCOM.

To model an event-driven sensor, consider a device having NE random number of events

detected in a total operating time T . Let us assume the sensor unit is always in the active

state (i.e. tSEN = T and PSEN = constant), and that each triggered event is reported to

the gateway device (i.e. NMCU = NCOM = NE). Based on measurement of some event-

driven sensor devices (see Appendix A), in most cases, PSEN = PSBY or alternatively,

PSEN PSBY such that PSEN + PSBY ≈ PSEN. Assuming that the events are repetitive

with a similar amount of data being processed and transmitted, applying (3.4), the total

energy consumption of an event-driven sensor device (es), over a long operating time T is

expressed as:

E(es)DEV(T ) ≈ ESEN +NE(T )(〈EMCU〉+NR〈ECOM〉

)(3.7)

for NE > 0 and NR > 1, where ESEN = PSENT .

3.3.3 Modelling an Actuator Device

In general, the operation of an actuator contains a period of communication, a period

of processing followed by the excitement of the actuating unit. More advanced devices

may have status reporting, ACK and ”keep alive” functions. The RF 433 MHz-based ac

actuator devices (see Appendix A) measured in this work did not show discernible power

level changes for the different tasks as seen with sensor devices, because the changes are

too small compared to the measuring resolution of the ac power meter (1 sec). However,

measurement of similar RF 433 MHz transmitter and receiver modules (in Appendix A)

used by these devices show quite distinct changes for the listening, transmitting and

receiving tasks. In addition, the power consumption of the actuator device itself is also

much greater than what was measured for the RF 433 MHz receiver module.

Figure 3.5 shows a conceptual model for the power consumption time evolution of

an actuator device receiving a random command which triggers an actuating event. The

actuator device can be regarded as the dual of an event-driven sensor, with the actua-

48 Energy Consumption of Home Automation and Security Systems

PDEV

Event

tACT

tMCU

tCOM

Time (t)

Command

ListeningListening

PCOM

PMCU PACT

PSBY

Communications (COM)

Processing (MCU)

Actuate (ACT)

Standby (SBY)

0

Figure 3.5: Conceptual model of the power consumption time evolution of an actuatordevice. The vertical rise of the rectangles demonstrates instantaneous power consump-tion and the horizontal, elapsed time.

tor’s COM and SBY functions being an equivalent to the SEN and SBY functions of the

event-driven sensor, and the ACT function being equivalent to the COM function of the

event-driven sensor. An event begins with the receipt of a command signal via the com-

munication module in ”listening mode” (i.e. radio receiver is ”always-on”) during time

tCOM, with a power draw PCOM. An interpretation or processing of each command by

the MCU follows during time tMCU (and power draw PMCU), and the event ends when

the MCU triggers the actuator unit for a period tACT, drawing power PACT.

Let us consider an actuator device having NE events triggered during an operating

time T . Assume that a part of the communication module (i.e. receiver in listening mode)

is always in an active state (i.e. tCOM = T andPCOM = constant) and that every event results

in an activation of the actuating unit (i.e. NMCU =NACT =NE), whereNACT in the number

of times the actuator unit is energised. It is also assumed that, in most cases,PCOM = PSBY

or alternatively, PCOM PSBY such that PCOM + PSBY ≈ PCOM. Thus, adapting equation

(3.4), the total energy consumption of an actuator device for a long operational period T

3.3 Home Automation and Security System Energy Model 49

is therefore given as:

E(a)DEV(T ) ≈ ECOM +NE(T )(〈EMCU〉+ 〈EACT〉

)(3.8)

where NE > 0 and ECOM = PCOMT .

3.3.4 Modelling a Smart Appliance

Smart appliances have separate and different primary functions (e.g. Toaster, Oven, LED

bulbs etc.) but are fitted with network-enabled communication modules (mostly wire-

less) to control, actuate or manage their basic internal functions, for example by using a

smartphone or an IoT web service via the Internet. Smart appliances are tethered to the

main electric grid, consuming a constant standby/idle power. The energy consumed to

maintain smart appliances in the ”listening” or ”standby” state can be significant [22].

In modelling the energy consumption of smart appliances, only the additional energy

required to maintain the network-enabled communication module is included here. The

energy consumed by the appliance in performing its core functions is not considered. We

used manufacturers’ datasheet values for communication modules and reported mea-

surements in the literature.

3.3.5 Modelling Energy Consumption of IoT Gateway

This section presents an energy model for a representative IoT gateway (IGW) device

shown in Figure 3.2. A common practice is the use of popular off-the-shelf development

platforms like BeagleBone Black (BB) [15] and Raspberry Pi (RPi) [117] as an IoT gateway.

The authors in [117] conducted power measurements of a Raspberry Pi Model B device

under network load of 0 - 90 Mb/s. Their results show a small but near linear network

load dependence on power consumption. The power consumption variation was only

approximately 70 mW corresponding to a less than 5% increment when compared to

the RPi idle power of ≈ 2 W. In the project work behind this thesis, the Ninja Block

system is employed as a representative HAS [15], although this product was discontinued

during the course of this project. Our measurement of the Ninja Block IoT gateway device

50 Energy Consumption of Home Automation and Security Systems

(which used a BeagleBone Black as the gateway processor and is described in section

3.5.5) revealed an insignificant variation in the gateway power consumption under light

network load (i.e. 0.1 - 2 Mb/s).

From the general expression of the power consumption of a network element ex-

pressed as equation (2.1) in Chapter 2, the power consumption (PIGW) of a representative

IoT gateway device is:

PIGW(t) = Pidle + ERIGW(t) (3.9)

Since the IGW does not generate a significant amount of data traffic, and its idle power

(Pidle) can be 95% [117] or more of its maximum power Pmax, i.e. Pidle ≥ 0.95Pmax, then

we make the approximation E = (Pmax−Pidle)/Cmax ≈ 0. Under this approximation, the

energy consumption of an IoT gateway (EIGW) for a period of time T is given as:

EIGW =

∫ T

0PIGW(t)dt ≈ Pidle × T (3.10)

3.3.6 Modelling the Energy Consumption of a Home Gateway Modem

Generally, a network element can be classified either as a lightly shared network ele-

ment (e.g. HGW or Optical Network Unit) or heavily shared network equipment (e.g.

Core Router) as described in [70]. A lightly shared network element deals with traffic

dedicated to a single-user or single-household, like a HGW for an xDSL service. To define

a single-household in this scenario, consider an IoT service installation in a home setting

(e.g. the HAS use-case) where the service shares a HGW with a number of traffic gen-

erating services (e.g. Facebook, YouTube, etc.). In modelling the energy consumption of

the HGW, careful consideration should be given to all applications and services gaining

network access, either intermittently or continuously, over a period of time.

It is assumed that the IoT devices report throughout the day resulting in a continuous

data flow from the IGW to the HGW. This continuous data flow could hinder poten-

tial energy saving from the implementation of some sleep-mode techniques [118], as the

HGW deals with the traffic flow with little or no idle periods. This consequential po-

tential energy penalty can therefore be accounted for by allocating it to the IoT service.

3.3 Home Automation and Security System Energy Model 51

Hence, in modelling the HGW, a shared power model [70] is adopted, which allocates to

each service part of the no-load/idle power as a proportion of the total traffic, in addition

to the incremental power consumption for each service as a function of its respective data

rate R, given as:

P (R) =

(Pidle

ρRmax+Pmax − Pidle

Rmax

)R (3.11)

where Pidle and Pmax are the no-load and maximum load power consumption of the

shared network element, Rmax its maximum data rate and ρ is the percentage utilisation

of the network element.

Let us consider a HAS in a home setting, having an IGW with a data rate RIoT such that

RIoT =∑

iRdevi, for i = 1, 2, ..., N , whereRdevi

represents the data rate of an IoT device i,

and N , the total number of IoT devices connected to the IGW. Let the background traffic

generated by all other services within the home be denoted by Rbgd, given that Rbgd =∑sRsvcs , for s = 1, 2, ..., Ns, where Rsvcs represents the data rate of a unique service s

and Ns being the total number of services accessing the HGW. Hence, the aggregated

total traffic RHGW [i.e. ρRmax in (3.11)], is given as:

RHGW(t) = Rbgd(t) +RIoT(t) (3.12)

Next, we estimate the background traffic (Rbgd) of a representative single-household. To

18/05/2017 0:0019/05/2017 0:0020/05/2017 0:0021/05/2017 0:0022/05/2017 0:0023/05/2017 0:0024/05/2017 0:0025/05/2017 0:00

0.00

1.00

2.00

3.00

4.00

5.00

6.00

0

2

4

6

8

10

12

18/05/2017 0:00

19/05/2017 0:00

20/05/2017 0:00

21/05/2017 0:00

22/05/2017 0:00

23/05/2017 0:00

24/05/2017 0:00

25/05/2017 0:00

Tra

ffic

Vol

ume

(Gb/

s) ISP Traffic ProfileTotalOutboundInbound

Figure 3.6: Traffic profile of a tier-2 ISP for a week [8].

achieve this, the diurnal traffic data of a tier-2 ISP with a predominately retail customer

52 Energy Consumption of Home Automation and Security Systems

base was obtained for 1 week in May 2017 [8], as shown in Figure 3.6.

The data in Figure 3.6 is for the ensemble of customers of that ISP, and we use this

relative traffic over time as a proxy for the traffic of an ”average” customer, recognising

that each individual customer’s traffic will differ. Furthermore, this study aims to later

estimate the total IoT energy consumption over many households (e.g. USA, Europe),

hence the rationale for the use of a profile that is the sum of many households.

The data is already quantised into 0.5 hour blocks. For ease of tabulation, we further

quantise the data into 2-hour blocks, and represent each block by one of six relative traffic

levels (i.e. steps). There is nothing particularly significant in the choice of six levels; other

researchers have used similar techniques [13] with different numbers of levels.

Figure 3.7: Average diurnal traffic profile of a tier-2 ISP network with step load levelswhich are percentages of the average load over a day [8].

Using this week-long data, the average hourly traffic for one diurnal cycle is repre-

sented by the traffic profile given by the blue trace of Figure 3.7, while the 2-hour average

traffic load levels (six steps) are represented by a fitted step profile in the same figure (red

trace). The six average traffic load levels µl, are expressed as a percentage of the average

load 〈Rave〉 (i.e. averaged over a day) where l = 1, 2, ..., 6. The step profile shows a swing

from 40% of average load at the early hours of a day, to 160% of average load during the

3.3 Home Automation and Security System Energy Model 53

Table 3.1: Diurnal traffic load levels for a tier-2 ISP. The hourly average data rates for theHGW are calculated using its estimated average daily traffic and load levels (µl).

Traffic Profile

lLoad Level Duration Hourly Average

(µl) (Tl) Data Rate (Mb/s)[Rbgdl

]1 40% 2 hrs 0.492 50% 4 hrs 0.613 90% 4 hrs 1.104 110% 8 hrs 1.355 140% 4 hrs 1.716 160% 2 hrs 1.96

busy-hours as given in Table 3.1. These relative load levels are subsequently used as an

approximation of a single-household hourly data rate for a 24 hour period relative to the

household’s average daily data rate 〈Rave〉 in the model. Tl in Table 3.1 is the duration in

hours of traffic load level µl over 1 diurnal cycle T , where T =∑6

l=1 Tl. An expression for

the household’s HGW background traffic (Rbgdl) in interval of traffic level l is therefore

given as:

Rbgdl= µl〈Rave〉 (3.13)

The average data volume usage of all Australian fixed-line households was 168 GB

per month (assuming 10% upload volume) [119] for the last quarter of 2017. Since the

household data volume usage is increasing at an annual rate of more than 50% [119]

(doubling every 2 years), we assume a household monthly data usage of 400 GB. For

this usage volume, the calculated daily average data rate 〈Rave〉 = 1.22 Mb/s (for 12.9

GB daily usage and 31 days per calendar month). Based on this daily usage, hourly aver-

age data rate or background traffic (Rbgdl) is calculated using (3.13) and given in Table 3.1.

With the estimated HGW background traffic, using equations (3.11), (3.12) and (3.13),

the average power consumption of the HGW attributable to the HAS with average data

rate RIoT, at a specific time of day with background traffic, Rbgdl, is given by:

PHGWl(RIoT) =

Pidle ×RIoT

µl〈Rave〉+RIoT+

(Pmax − Pidle

Rmax

)RIoT (3.14)

The total energy share, EHGW, consumed by the HGW over 24 hours, that is attributable

54 Energy Consumption of Home Automation and Security Systems

to the HAS is therefore given by:

EHGW =

6∑l=1

PHGWl(RIoT)× Tl (3.15)

3.4 Experiment Methodology and Measurement Setup

A detailed explanation of the experiment methodology, the experimental set-up, mea-

surement tools and applications are given in this section.

3.4.1 Methodology

Before the commencement of any experiment or measurement, the characteristics and

functionalities of the each test device was thoroughly studied. For IoT devices, the char-

acteristics considered here include the device’s bit-rate, transmit sequence, protocol stack,

energy consumption states (i.e. active, idle, standby, etc.) and trigger mechanisms. De-

pending on the operating mode of a device (i.e. always-on or triggered), the measure-

ments were conducted after a few minutes of operation. More than 10 iterations were

taken for a complete duty cycle of each device considered. The average power consump-

tion is calculated from at least 10 iterations. The power consumption results of each IoT

device measured is given in section 3.5.1.

To measure the power consumption of the IoT devices and gateways, 2 sets of power

meters were used:

i Powermate PM10AHDS ac Power Meter

ii Custom-built USB 3V, 5V and 9V dc Power Meters

A general block diagram of the measurement setup used is shown in Figure 3.8. The test

device is powered via the power meter which measures the power draw of the device by

sensing voltage drop across a low-value resistor that the meter inserts into the line. Data

traffic measurement is achieved by connecting a PC running the packet sniffing software,

3.4 Experiment Methodology and Measurement Setup 55

”Wireshark”, to the local area network. A detailed description of the ac and dc power

meters employed in this work is given below.

Figure 3.8: Schematic diagram of the measurement setup for recording both power con-sumption and data throughput of a test device.

3.4.2 AC Power Meter

The Powermate PM10AHDS ac power meter was utilised in the measurement of the NB

gateway, the HGW modem, the IP camera and ac power actuators which operate from

the mains power. The PM10AHDS has a 0.5% accuracy error for voltage ratings of 170 -

270 V RMS and a current rating up to 10 A RMS. It can accurately measure power as low

as 10 mW with a time granularity of 1 sec. Data logging of power values is achieved via

an RS-232 port. An RS-232 to USB adapter was used for connection to the data logging

PC. Table 3.2 lists the relevant parameters of the PM10AHDS and dc power meters, which

are discussed in the next section.

56 Energy Consumption of Home Automation and Security Systems

Table 3.2: Parameters of the ac and dc power meters used in the experiments

Parameter ac Power Meter dc Power MetersSupply Voltage (V) 230 V 3 V 5 V 9 VSampling Rate 1 sec 5 ms 5 ms 5 msAccuracy 10 mW 10 µW 100 µW 10 µW

3.4.3 DC Power Meter

Four (4) dc power meters, each with an in-built power supply, were used in this work: a

3V, 9V and two 5V (low current and high current) power meters. The power supply pro-

vides a controlled voltage to the IoT devices via an internal power supply circuitry and

simultaneously measures the device current draw using a range-specific current sensing

resistor. Measurements were conducted with a 10 µW and 100 µW accuracy and with 5

Figure 3.9: dc power supply and power meter block diagram. A detailed diagram isgiven in the appendix section.

ms granularity. Time granularity was commonly 5 ms, but could be re-programmed to

a granularity of below 1 ms where that granularity was important. Figure 3.9 shows a

simple illustration of the custom built power supply and power meter setup and Table

3.2 lists the important parameters of the dc power meters. The broken lines signify the

section of the setup that applies specifically to variants of the meters that were used with

3.5 Traffic and Energy Measurements of a Ninja Block HAS - A Case Study 57

USB devices. A more detailed diagram and description of the dc power meters can be

found in the Appendix B.

3.5 Traffic and Energy Measurements of a Ninja Block HAS - ACase Study

The Ninja Block HAS (NB) [15] was selected as a representative off-the-shelf example of

typical HAS, and used as a test-bed in this work. The NB system consists of wireless

sensor and actuator devices (i.e. IoT devices), a NB gateway unit (i.e. IoT gateway) and a

cloud service - hosted by Amazon EC2 servers (data centre) - through which control and

management of all connected IoT devices is facilitated. It uses the ISM band 433 MHz

RF protocol for wireless communication with end-devices. The network architecture of

the NB is similar to that shown in Figure 3.2. A detailed functional description of the NB

system is given in Appendix A.

3.5.1 Sensor Energy Consumption Measurements

This section presents the energy consumption measurements of the different IoT devices

considered as part of the NB system tested in this work. Detailed functional description

of these sensor devices is given in Appendix A.

Temperature and Humidity Sensor

The Clas Ohlson WT450H temperature and humidity sensor (T&H) [116] is a time-based

sensor device considered here. The T&H has a transmit-only 433 MHz communications

module which sends sensor readings to the NB gateway once every minute. This device

is normally powered by a 3V battery, but for these measurements, power was supplied

by the power meter. Power consumption measurements were conducted using the 3V dc

power meter. Figure 3.10 is a power plot of several operational cycles of the T&H. The

plot shows the T&H taking 8 temperature and humidity measurement samples (includ-

58 Energy Consumption of Home Automation and Security Systems

PSEN

tSEN

PMCU

PTx

tTx

tMCU

Figure 3.10: Power plot of a Clas Ohlson temperature and humidity sensor transmittingonce per minute. The small spikes occurring every 7-8 seconds are the sensing processesfor collecting the temperature and humidity readings.

Table 3.3: Measurement values for a WT450H T&H sensor for 1 cycle (1 min)

PhaseNo. of

Instances(N)

Durationt

(ms)

Current(mA)

Power *Draw(mW)

Energyper

cycle (mJ)Share

Sensing (SEN) 16 82 0.27 0.87 1.1 7%Transmit (Tx) 3 72 6.86 21.95 4.6 31%Wake-Up (MCU) 1 500 3.50 11.2 5.6 38%Standby (SBY) - 60,000 0.02 0.06 3.6 24%

* Supply Voltage = 3.2V

ing 2 between message bursts), then sending 3 bursts of the same message once every

minute. Table 3.3 lists the power draw and duration of each phase during an operational

cycle and the corresponding energy consumption.

Using values from Table 3.3 and equation (3.5) for one cycle (TC = 60 sec), the energy

consumption of a T&H sensor device is calculated as ≈ 15 mJ per cycle and ≈ 22 J per

day. A plot of T&H sensor energy consumption against number of measurement cycles

is given in Figure 3.13.

3.5 Traffic and Energy Measurements of a Ninja Block HAS - A Case Study 59

Passive Infrared Sensor (PIR)

The Passive Infrared (PIR) or motion sensor is an event-driven sensor device consisting

of an infrared detector, a microcontroller unit and a 433 MHz transmitter. This device

is normally powered by a 9V battery, but for these measurements, power was supplied

by the power meter. The PIR sensor sends a pre-defined message (unique code-word) to

the NB gateway whenever its IR background changes (an event). This is followed by a

selectable lockout time (5, 50 or 300 sec) which prevents excessive re-triggering. Using the

9V dc power meter, the power consumption of the PIR sensor device was measured for a

number of events. Figure 3.11 shows a power trace of 4 events triggered 5 seconds apart

Event

tTx

Lockout Time

Figure 3.11: Power plot of a 433 MHz PIR sensor device.

Table 3.4: Measurement values of a 433 MHz PIR sensor device for 1 event.

Phase Duration Current Power Energy per event*(ms) (mA) (mW) (mJ)

Transmit (Tx) 870 16.5 146.85 127.8Lockout Time (MCU) 3650 0.06 0.53 1.9

* Supply Voltage = 8.9V

while Table 3.4 lists the average power consumption and calculated energy per event for

60 Energy Consumption of Home Automation and Security Systems

the PIR sensor device. Negligible power draw was observed during the IR sensing period

prior to an event.

Using equation (3.7) with the values of Table 3.4, the energy consumption of the PIR

sensor device is calculated as 130 mJ per event, ≈ 1 J for 10 events per day and ≈ 13 J for

100 events per day. Figure 3.13 shows the energy consumption of the PIR sensor device

for a range of events per day.

3.5.2 Door and Window Sensor

The wireless 433 MHz Door and Window (D&W) sensor device is also an event-driven

sensor device comprising of a Reed switch, a MCU and a 433 MHz radio transmitter as

one unit, with movement of an external magnet used as a trigger. Measurement of the

D&W sensor device was conducted using the 9V power meter for more than 10 events.

Event

Sensing

tTx

PTx

Figure 3.12: Power plot of a 433 MHz door and window sensor.

Figure 3.12 shows a plot of the D&W sensor power draw for 5 events with the av-

erage current draw, duration and energy per event given in Table 3.5. The plot shows

two dominant phases: transmit and sensing. When triggered, the D&W sensor sends 14

3.5 Traffic and Energy Measurements of a Ninja Block HAS - A Case Study 61

Table 3.5: Measurement values of a 433 MHz door/window sensor for 1 event.

Phase Duration Current Power Energy per event*(ms) (mA) (mW) (mJ)

Transmit (Tx) 45 8.8 86.24 54.3Processing (MCU) 850 1.0 9.8 8.3Sensing (SEN) - 0.007 0.07 -

* Supply Voltage = 9.8V

bursts of message as can be seen from the plot.

The energy consumption of the D&W sensor device is therefore calculated using equation

(3.7) as ≈ 63 mJ per event, ≈ 7 J for 10 events per day and 12 J for 100 events per day.

Figure 3.13 gives the energy consumption of D&W sensor device for a range of events

per day.

Effect of the Number of Events/Cycles of the Sensor Devices

Figure 3.13 shows a plot of energy consumption as a function of the number of cycles or

events per day for the PIR, D&W and T&H sensor devices. The figure shows minimal

100 101 102 103 104

Number of cycles/events per day

10-2

10-1

100

101

102

103

104

Energy Consumption (Joules)

PIR Sensor

D&W Sensor

T&H Sensor

Figure 3.13: Energy consumption of sensor devices for a 24 hours period.

62 Energy Consumption of Home Automation and Security Systems

change in energy consumption for less than 10 events per day for the event-driven D&W

sensor device (6.3 - 7 J), with the sensing phases being the dominant contributor to the

total energy. Between 10 and 100 events per day, a slight increase in energy consumption

can be seen as the contribution for message transmission increases. Above 100 events

per day, the plot shows sharp increase in energy consumption of the D&W sensor device,

dominated by the message transmission energy, due to a higher number of events. The

plot of the PIR sensor device (blue curve) shows a linear increment with increase in the

number of events. This is due to the same amount of energy consumed for each event,

since there is negligible power draw in its sensing phase. For the time-based T&H sensor

(red curve), a fairly linear increment is also seen because the same amount of energy is

consumed every cycle. Therefore, for time-based sensor devices and some types of event-

driven sensor devices, a lower energy consumption can be achieved by minimising the

standby power.

100 101 102 103 104

Number of events per day

0

20

40

60

80

100

Percentage of energy (%)

D&W Sensor (sensing)

D&W Sensor (event)

Figure 3.14: Percentage of sensor device energy consumption by phase per day.

To further understand the relationship between the energy consumption of the two

major energy consuming phases of D&W sensor device, a plot of percentage energy con-

3.5 Traffic and Energy Measurements of a Ninja Block HAS - A Case Study 63

sumption as a function of number of events per day is given in Figure 3.14. From the

figure we can see that the communication (transmit phase) becomes the major contribu-

tor beyond about 100 events per day for the D&W sensor device. The reason for this is

that the daily energy consumption of the sensor is fixed while that for message transmis-

sion increases with the number of events per day. This can assist in determining sensor

battery usage prediction based on an approximate number of events over a period of

time.

3.5.3 Actuator Energy Consumption Measurements

An example actuator device that operates with the NB system is the Watts Clever Remote

Control Socket. The controlled socket is a wireless 230V power socket that can be used

Figure 3.15: Power plot of a Watts Clever controlled socket in ON/OFF no-load states.

to remotely turn on or off household appliances via the Internet. It includes a 433 MHz

wireless receiver which facilitates the actuation of a relay, opening or closing the power

circuit. Using the PowerMate ac power meter, its no-load average power consumption

was recorded as 702.4 mW in its ”Socket OFF” state and 670.1 mW in the ”Socket ON”

64 Energy Consumption of Home Automation and Security Systems

state. A power trace of the measurement given in Figure 3.15 shows the socket consuming

slightly more energy when switched ”OFF” than when switched ”ON”.

3.5.4 IP Camera Energy Measurements

The FOSCAM FI9831W IP camera (IPcam) [55] is used as a video surveillance IoT de-

vice. The IPcam is an integrated wireless video surveillance solution with an in-built

web-server that supports High Definition (HD) quality video (H.264 compression) and

images up to a maximum of 1280 x 960 resolution. The IPcam connects to the NB gateway

through Ethernet or Wi-Fi access via the HGW.

For this measurement, the IPcam is configured for a frame size of 1280 x 720 pixels at 25

frames per second. Using the ac power meter and Wireshark (see Fig 3.8), the IPcam was

tested when accessing the network via Ethernet through a Netgear DS108 dual speed

hub, and Wi-Fi through a Linksys BEFW11S4 2.4 GHz Wireless Broadband router, with

the measurement results given in Table 3.6. The 30 kb/s difference in data rate could be

Table 3.6: Data rate and power consumption measurements of the FOSCAM FI9831W IPCamera.

Network Access Data Rate (Mb/s) Power (W)Ethernet 1.90 3.25Wireless (Wi-Fi) 1.93 3.75

attributed to data re-transmissions due to a lower reliability in a wireless link, in con-

trast with a wired Ethernet connection. The notable difference in power is due to the

extra energy cost for running the wireless interface card. A more comprehensive suite of

measurements was made, and the details are included in Chapter 5.

3.5.5 IoT Gateway Traffic and Energy Consumption Measurement

The NB gateway consists of a BeagleBone Black (BB) main processor and an Arduino

microcomputer daughter-board or cape as one unit (detailed description in Appendix

A). To determine its energy profile, the gateway was set up with 3 T&H sensors, 2 PIR

sensors, a wireless electronic button (like a door bell), and 3 ac controlled socket actuators

3.5 Traffic and Energy Measurements of a Ninja Block HAS - A Case Study 65

(cameras were added later). Traffic generated by the NB gateway was observed and

recorded using the packet sniffer Wireshark, running on a test PC (see Fig 3.8) while its

power consumption was recorded on a data logging laptop.

Idle-mode Measurements

Figure 3.16 shows a component-level power consumption of the NB gateway unit as

listed in Table 3.7. Although the idle-mode power consumption of the complete NB gate-

way unit is around 1.2 W when powered via a 5V USB 2.0 port on the dc power meter,

a significant difference (2 W) was observed when the unit is mains-powered (measured

with the ac power meter) showing a powerpack inefficiency of about 40%.

Figure 3.16: Power consumption of the components of the NB gateway unit.

Table 3.7: Power consumption values of the main components of the NB gateway unit.

Ninja Block Gateway Components Power (mW)BeagleBone Black (BB) 585BB + Arduino Cape 745BB + Arduino Cape + Wi-Fi 1135BB + Arduino Cape + Ethernet 1181BB + Arduino Cape + Ethernet + ac Power Pack 2005

66 Energy Consumption of Home Automation and Security Systems

Active-mode Measurements

A description of active-mode in the context of this study refers to a successful communi-

cation link between the NB gateway, its IoT devices and the NB cloud server application,

with the IoT devices actively transmitting/receiving data. The observed traffic and corre-

sponding power consumption are listed in Table 3.8. An average power consumption of

2 W (same as idle-mode) was measured during the tests. Hence the energy consumption

of the IGW (EIGW) is calculated using equation (3.10). The observed traffic plots of the

0 20 40 60 80 100 120Time (seconds)

0

50

100

150

200

250

300

350

Data

Rate

(kb

/s)

(a)

Uplink (IPcam)

Downlink (IPcam)

Uplink (Webcam)

Downlink (Webcam)

0 20 40 60 80 100 120Time (seconds)

0

500

1000

1500

2000

2500

3000

3500

Data

(kb

yte

s)

(b)

Upload (IPcam)

Download (IPcam)

Upload (Webcam)

Download (Webcam)

0 20 40 60 80 100 120Time (seconds)

0

1

2

3

4

5

6

7

Data

Rate

(kb

/s)

(c)

Uplink (sensors)

Downlink (sensors)

0 20 40 60 80 100 120Time (seconds)

0

10

20

30

40

50

60

70

Data

(kb

yte

s)

(d)

Upload (sensors)

Download (sensors)

Figure 3.17: Observed traffic from a Ninja Block linking sensors and cameras to the cloud.Plot (a) & (b) shows the data rate (kb/s) and data volume (kb) of the cameras; Plot (c) &(d) shows the data rate (kb/s) and data volume (kb) of the sensors.

NB gateway are given in Figure 3.17 and the results recorded in Table 3.8. An average

3.5 Traffic and Energy Measurements of a Ninja Block HAS - A Case Study 67

Table 3.8: Measured average data rate and power consumption of NB gateway.

IoT Device Image Image Data Rate (kb/s) PowerResolution Size (kB) Downlink Uplink (W)

Sensors & Actuators - - 2 5 2FOSCAM IP Camera (HD) 1280 x 960 280 13 216 2Logitech 1.3M Webcam (SD) 640 x 480 64 17 126 3.4*

* The difference (i.e. 1.4 W) is due to the bus-powered Logitech USB webcam.

upstream and downstream traffic of 5 kb/s and 2 kb/s was recorded for all connected IoT

devices excluding the cameras. Unlike more recent HAS that are designed with a video

streaming application (e.g. Samsung SmartThings [103]), the NB system was designed

with an image streaming application only. When the NB system is connected with a USB

Webcam (via the NB gateway’s USB port) or an IPcam (via a LAN), the gateway grabs

still images from the camera at 3 sec intervals. These images are then streamed to the

cloud from where they can be accessed by users. The average downlink and uplink data

rate when the NB gateway is separately connected to a Logitech 1.3M (SD) Webcam and

the FOSCAM IPcam are given in Table 3.8. These results show that the traffic generated

by the cameras alone (Rcami) ≈ 20 - 33 times more than that of all other IoT devices if

connected. We can therefore assume that RIoT ≈∑

iRcami , where i = 1, 2, ..., N , for N

connected cameras.

3.5.6 HGW Energy Consumption Measurement

A Billion BiPAC 7800NL ADSL2+ wireless modem was used as a representative HGW

in the model. Tests were conducted with the Wi-Fi RF radio ”ON”. To measure the

power consumption of the 7800NL, the ac power meter was utilised with a setup similar

to Figure 3.8. Traffic was generated and controlled by an open-source torrent software

application, while downloading multiple large data files to a PC. Table 3.9 gives the data

recorded from these experiments and Figure 3.18 shows a plot of power consumption as

a function of data rate of the ADSL2+ HGW.

The power consumption of the HGW attributable to the NB system is calculated us-

ing equation (3.14). From the measurements given in Table 3.9, the incremental power

68 Energy Consumption of Home Automation and Security Systems

Table 3.9: Power consumption and data rate values for a BiPAC 7800NL ADSL2+ modem.

Data Rate (Mb/s) Power (W)0 7.0

0.4 7.00.9 7.01.6 7.13.2 7.14.8 7.27.2 7.28.8 7.310.4 7.3

Figure 3.18: Power Consumption plot of a Billion BiPAC 7800NL ADSL2+ Modem [9]

consumption for a data rate of 10 Mb/s is about 300 mW, which represents about 4%

increment. Doubling the data rate (close to the max for ADSL2+ technology) would give

about 8% (≈ 600 mW) increment which is small in comparison with an idle power of 7 W.

Hence from equation (3.14), the incremental energy term(Pmax−PidleRmax

)≪

(Pidle

µl〈Rave〉+RIoT

)and it is reasonable to make the approximation that PHGWl

(RIoT) ≈(

Pidle×RIoTµl〈Rave〉+RIoT

).

From this expression, the hourly average power consumption of the HGW, attributable

to the NB system is calculated for a range of RIoT data rates and plotted in Figure 3.19.

The total attributable energy (EHGW) over a day is then calculated using equation (3.15).

3.6 Estimating the Energy Consumption of Home Automation and Security Systems 69

0 250 500 750 1000 1250 1500 1750 2000IoT traffic data rate (kb/s)

0

1

2

3

4

5

IoT-related Power Consumption (W)

Background Traffic Level40% of daily average traffic level50% of daily average traffic level90% of daily average traffic level110% of daily average traffic level140% of daily average traffic level160% of daily average traffic level

Figure 3.19: ADSL2+ HGW power consumption attributable to the NB system traffic as afunction of its data access rate for 6 different background traffic level profiles.

3.6 Estimating the Energy Consumption of Home Automationand Security Systems

This section describes the methods applied in estimating the energy consumption of an

installed HAS for a mid-size family home, followed by a global estimate of the energy

consumption of HAS devices using market-based forecast of future numbers of installed

IoT devices. The section concludes with an estimation of the annual energy consumption

of HAS in the top two smart homes markets (i.e. North America and Europe).

3.6.1 Estimating the Energy Impact on a Mid-Size Home

As an illustrative example of the additional energy cost of a HAS and its potential impact

on global energy consumption, a simple home installation scenario is considered. An

average mid-size home is envisaged with a multi-function or whole-home installation

(i.e. sensors, actuators and IoT gateway) as an example HAS.

For this estimate, consider a 3 bedroom 2-storey house fitted with a HAS. The system

70 Energy Consumption of Home Automation and Security Systems

consists of door sensors (front, back and garage doors) having an average of 10 events per

day, door lock actuators (front and back doors), window sensors having 2 events per day,

smoke detectors (e.g. NEST Protect [104]), garage door actuator, PIR/motion sensors

having 288 events per day (i.e. once every 5 minutes), smart light bulbs (LIFX [120]),

controlled socket actuators (as in section 3.5.3), smart appliances (including Refrigerator,

Toaster, Dish Washer, Microwave, Food Warmer, Oven, Washing Machine, Dryer and

Coffee Maker, etc.), security cameras (e.g. FOSCAM in section 3.5.4), an IoT Gateway

(Ninja Block [15]) and an ADSL2+ home gateway modem [9]. Table 3.10 lists the number

Table 3.10: IoT devices of a multi-function HAS and their annual energy consumption.The table contains a mixture of battery and mains-powered IoT devices.

IoT DeviceNo. of Events Power Energy AnnualUnits per day (W) /day (kJ) Energy (kWh)

T&H Sensor 6 1440 - 0.13 0.01Door Sensor 3 10 - 0.02 0.002Window Sensor 15 2 - 0.10 0.01PIR/Motion Sensor 12 288 - 0.98 0.1Smoke Detector 3 - 1 259.2 26.28Door Lock Actuator 2 - 0.7 181.4 18.4Controlled Socket Actuator 15 - 0.7 1296 131.4Garage Door Actuator 1 - 0.7 60.5 6.13Smart Light Bulb 40 - 2 6912 700.8Smart Appliance 15 - 1 1209.6 122.74Security Camera 4 - 3.75 1296 131.4IoT Gateway 1 - 2 172.8 17.52Home Gateway Modem 1 - 7 268.1* 27.18

* This value represents a share of the daily energy consumption of the HGW allocated to the HAS as afraction of its average data rate, and is calculated using equation (3.15).

of each type of IoT device, their daily and annual energy consumption (assuming 365

days per calendar year) calculated using equation (3.16).

Annual Energy Consumption (kWh) =365 Days× Energy/Day (kJ)

3600(3.16)

Energy consumption values for the 433 MHz sensors and actuators described in the pre-

ceding sections are used in this analysis. Only the standby/idle power consumption

values are considered for the mains-powered devices. For smart light bulbs, the average

3.6 Estimating the Energy Consumption of Home Automation and Security Systems 71

number of lamps per household is 24 in EU [121], 36.6 in Australia [122] and 67.4 in the

US [123]. We assume 40 smart light bulbs for a mid-size home which is about average

of the 3 regions. Since no measurements were made for the smart light bulbs and smart

appliances, manufacturer datasheets and reported measurements in the literature were

applied. The idle power consumption of a LIFX LED smart light bulb is reported as 2 W

[120]. For the smart appliances, it is assumed that all devices are fitted with a Wi-Fi mod-

ule. The idle power consumption of the 802.11n Wi-Fi module is 1 W [124]. This takes

account of the inefficiencies of many power supply units which can be more than 30%

(see Figure 3.16).

(a) (b)

Figure 3.20: Percentage share of annual energy consumption of a HAS when the installedIoT devices are: (a) Mains and battery powered, and (b) Mains powered only.

Two scenarios were considered: (a) Mains & battery powered devices and (b) Mains pow-

ered devices only.

For scenario (a), all sensors are battery powered while all other devices are mains

powered. Using the data from Table 3.10 and applying equation (3.1), the calculated an-

nual additional energy consumption of this mid-size home installed with an off-the-shelf

HAS is ≈ 1,200 kWh. This corresponds to about 30% of the annual energy consumption

of a ”typical” mid-size (3-bedroom) suburban home in Victoria, Australia, estimated as

4,067 kWh [125]. The results are given in Table 3.11.

For scenario (b), all devices are mains powered. The average power consumption

of sensors and actuators were obtained from the recent IEA report [22] (sensor = 0.6 W;

72 Energy Consumption of Home Automation and Security Systems

(a)

0

100

200

300

400

500

600

700

800

Ener

gy C

on

sum

pti

on

(kW

h)

0

100

200

300

400

500

600

700

800

Ener

gy C

on

sum

pti

on

(kW

h)

(b)

Figure 3.21: Annual energy consumption by IoT devices type for a: (a) Mains and batterypowered HAS, and (b) Mains powered HAS.

Table 3.11: Annual energy consumption of a multi-function HAS installed in a mid-sizehousehold.

HAS System Annual Energy % of Ave. Mid-SizeConsumption (kWh) Household Energy Usage

Mains and Battery Powered 1,200 30%Mains Powered 1,434 35%

actuator = 1 W). The calculated annual energy consumption is slightly higher at 1,434

kWh, corresponding to just over one-third (≈ 35%) the annual energy consumption of

the same home. Pie charts breaking down the percentage share of each IoT device type

in both scenarios are given in Figure 3.20(a) and 3.20(b). The main difference between

the two charts is due to a lower share of energy consumed by the sensors when they

are battery powered as opposed to mains powered, as can be seen from Figure 3.21. This

difference may be relatively trivial for a single-household but is significant on a global scale

as demonstrated in section 3.6.2. However, for a ”fair” comparison, the battery life and

whole-of-life energy cost of the batteries should be included, but this information is not

readily available.

Potential Energy Savings

Smart light bulbs (LED) are clearly the least energy-efficient from the charts above and

will potentially reduce the energy savings achieved from replacing incandescent light

bulbs with their LED equivalent. To put this in perspective, a 60 W incandescent light

3.6 Estimating the Energy Consumption of Home Automation and Security Systems 73

bulb switched on for 4 hours/day consumes 87.6 kWh/year but a 10 W non-smart LED

equivalent consumes 14.5 kWh/year with ≈83% energy savings. However, a 10 W smart

LED equivalent having 2 W standby power (e.g. LIFX) consumes 32.1 kWh over the same

usage time, resulting in ≈63% energy savings only, the difference of which is the energy

cost of its ’smartness’. Beyond the ability to automate or remotely power on/off smart

light bulbs, which would depend on daily usage behaviours, it is unclear how much

energy savings there may be when compared with non-smart LED bulbs.

Other smart devices (e.g. Smart Washing Machine) may also provide discernible en-

ergy savings with the ability, for example, to reschedule their operation at an opportune

time, in coordination with a smart grid. Where such applications can be identified, the

absolute energy savings due to its IoT smart technology would need to be studied sepa-

rately and assessed to establish the overall energy benefit of the smartness.

3.6.2 Estimating the Global Energy Impact of HAS System Devices

Global forecasts of IoT device deployments tend to be coarse with very wide variations

between the views of different consultants [2,4,126,127]. To estimate the energy impact of

HAS deployment, market forecasts from different sources were used. ABI Research fore-

casts - used in the 2016 IEA Report on energy-efficiency of the IoT [22] - numbers of HAS

devices to grow from 700 million in 2015 to 1.9 billion by 2020 with a Compound Annual

Growth Rate (CAGR) of 22%. Cisco’s 2016 Zettabyte Era report forecasts a growth in HAS

devices from 2.4 billion in 2015 to 5.7 billion in 2020, a CAGR of 19.5% [28]. While the

more conservative ABI Research forecast forms the basis of this work, the Cisco forecast

is also applied to show a potential worst-case scenario or upper bound of recent forecasts.

To estimate the global energy impact over a longer time span, the ABI Research fore-

cast was extrapolated to 2025, giving a 10-year estimate of 5.1 billion devices, assuming

the same CAGR. For a fully-equipped HAS as given in Table 3.10, the distribution of

installed devices by device type (e.g. sensor, IP camera) is shown in Figure 3.22(a). Us-

ing the energy consumption values in Table 3.10, assuming mains powered sensors (unit

74 Energy Consumption of Home Automation and Security Systems

!"#$%&

%

(a)

!"#$%&

%

(b)

Figure 3.22: (a) Global forecast of installed HAS devices (2015 - 2025); (b) Global energyconsumption estimate of HAS from 2015 - 2025.

standby power = 0.6 W [22]), the global energy consumption for HAS is estimated to rise

from 7.8 TWh in 2015 to 57 TWh in 2025 as depicted in Figure 3.22(b).

Applying the same principle to the Cisco projection, the data was extrapolated to

2025 using the same CAGR giving a device number increase to 14 billion by 2025 (see

Figure 3.23(a)). The global energy consumption is estimated to increase from 26 TWh

in 2015 to 156 TWh in 2025 as shown in Figure 3.23(b). The disparity is considerable as

the Cisco projection is almost 3-fold higher than that of ABI Research, which shows the

coarse nature of today’s estimates.

To further demonstrate the significant energy impact of installing mains powered sen-

sors over battery-powered sensors as mentioned in section 3.6.1, consider the above ex-

(a) (b)

Figure 3.23: (a) Cisco’s global forecast of installed HAS devices; (b) Global energy con-sumption estimate of HAS.

3.6 Estimating the Energy Consumption of Home Automation and Security Systems 75

trapolated ABI Research projections. The energy consumption for mains and battery

powered devices as compared to mains powered is depicted in Figure 3.24. The plot

shows a potential energy savings of 11.7 TWh for battery over mains powered sensors.

This analysis however does not take into account the energy to manufacture and safely

dispose of the batteries. Neither does this illustrative example include potential reduc-

tions from the development of more energy efficient IoT devices in the future. From

Figures 3.20 and 3.21, the stand-out example of where more efficient devices would im-

prove the efficiency of such an extensive IoT implementation would be the development

of more efficient ”smart light bulbs.”

3.6.3 Estimating the Energy Impact of Smart Homes

A recent market-based report on smart homes by Berg Insight focuses on smart homes

or HAS that have smartphone apps or web portal as a user interface, thus excluding

legacy systems. Focusing on two major smart home markets (i.e. North America (NA)

and Europe), the report forecasts installed smart homes in North America to grow from

16.9 million in 2015 to 46.2 million in 2020, a CAGR of 30%. Similarly, a 54% CAGR in

Figure 3.24: Annual energy consumption estimate for mains-powered HAS devices vs.mains and battery powered HAS devices.

76 Energy Consumption of Home Automation and Security Systems

Europe (EU28+2) increasing from 6.6 million smart homes in 2015 to 44.9 million smart

homes in 2020. Since these projections end at 2020, an extrapolation of the data was done

for 2021 to 2025 but with half the CAGR - using the same CAGR would exceed the total

number of households. Hence, a 10-year forecast with an effective CAGR of ≈ 22% and

≈ 39% shows the number of smart homes in NA and EU28+2 to reach 92 million and 146

million respectively. To estimate the smart homes’ energy impact, an assumption of the

Table 3.12: Deployment scenarios of an IoT HAS.

HAS System DeploymentDevices Large-Scale Medium-Scale Small-ScaleSensors 44 25 10Actuators 20 10 4Smart LED Lamps 40 20 5Smart Appliances 15 6 3IP Camera 4 2 1IoT Gateway 1 1 1

number of devices per household is required. From the Berg Insight report, it was shown

that between 12 - 17% of the 2015 installed smart home systems were multi-function or

whole-home systems while the remainder were point solutions (i.e. function specific). To

cater for this skewed adoption pattern, 3 deployment scenarios (i.e. large, medium and

small) were proposed as given in Table 3.12. The large-scale deployment is effectively a

multi-function, whole-home HAS similar to that in Table 3.10, assuming mains-powered

sensors (average power = 0.6 W [22]).

The annual energy consumption of a large, medium and small-scale smart home sys-

tem, calculated using equation (3.1) and energy consumption values from Table 3.10, is

given as 1434 kWh, 730 kWh and 263 kWh respectively. Assuming the 3 deployment

scenarios are distributed such that 20% of smart homes are installed with large scale sys-

tems, 40% with medium-scale and 40% with small scale, the total energy consumption

estimate for smart home systems in NA and EU28+2 is given in Figure 3.25. Figure 3.25

shows that the additional energy consumption estimate for potential smart homes instal-

lations in NA and EU28+2 is scheduled to increase from 8.7 TWh and 3.6 TWh in 2015

to 63 TWh and 100 TWh in a decade, if installation rates keep up at the projected pace.

To put this in perspective, it will require about nine (9) large power plants [128] (2 GW

3.7 Discussion and Conclusions 77

Figure 3.25: Annual energy consumption estimate for smart home systems in NorthAmerica and Europe.

output power) to support smart home systems only in the two regions considered. Also,

the data suggest EU28+2 is on track to become the most users of smart home systems

worldwide.

3.7 Discussion and Conclusions

In this chapter, a measurement-based first-order estimate of the potential energy impact

of home automation and security systems has been presented. An example HAS was

modelled for a ”typical” mid-size household. A step-by-step approach of energy mod-

elling of the different components of the HAS is presented, starting with the sensors,

actuators, IP camera, down to the IoT gateway and home gateway/modem. A traffic-

based proportion of the HGW energy consumption is allotted to the HAS because it is

shared by other user applications and services in the home.

Measurement results for sensors indicate two main types: ones with autonomous

and regular reporting and others triggered by events. This difference is critical in un-

derstanding the energy usage patterns of IoT devices, especially the battery powered

devices. The results indicate HAS exhibit low data throughput (< 10 kb/s) when sen-

78 Energy Consumption of Home Automation and Security Systems

sors, actuators and other smart devices are connected but moderate data throughput for

an image streaming service if more than one camera is connected. Energy consumption

estimates of a complete HAS with mains and battery powered IoT devices could be as

high as 30% more than the average annual energy consumption of a typical mid-size

suburban household. This number could increase to about 35% (≈ 1,434 kWh) if the

entire HAS is mains-powered. Smart light bulbs stood out as the least energy efficient

among the IoT devices considered. Table 3.10 and Figure 3.20 showed that the ”smart-

ness” of smart LED bulbs and smart power sockets were the largest contributors to this

energy consumption growth. Smarter design of these products should be the first focus

for product development, and the balance between the potential energy saving through

”smartness” as against the energy cost of their ”smartness” considered carefully in their

deployment.

The potential global energy impact of HAS device deployment is non-trivial. From a

recent market-based device shipment forecast, an energy consumption between 57 TWh

and 156 TWh is possible by 2025. This could require up to 9 large power plants [128]

(2 GW power output) to support. However, the results indicate an opportunity for poten-

tial savings of about 12 TWh if battery powered sensors are chosen over mains powered

sensors. This must be explored further as the analyses provided here does not consider

embedded energy.

While this work presents a first-order estimate of the potential energy impact of one

IoT application use-case, it gives an indication that there is a price to pay if the market

projections of IoT devices by 2025 [2–4, 126] are to come to fruition. One caveat is the

expectation that more efficient energy usage behaviours could be achieved by the use of

the data and control capabilities enabled by the IoT. These potential energy savings have

not been considered here.

Chapter 4

Energy Consumption of IoT WirelessNetwork Protocols

4.1 Introduction

AS discussed in Chapters 2 and 3, the Internet of Things (IoT) [24] is not just about

new sensors and actuators but will include many consumer devices/physical ob-

jects that are not currently networked and do not draw electricity when they are not in

use. Bringing these devices into the IoT eco-system will require an addition of communi-

cations interfaces which will mostly be wireless. A naive approach to adding communica-

tions interfaces (e.g. a Wi-Fi module on each device) could lead to substantial additional

energy consumption without corresponding benefit in functionality, if an inappropriate

design option is chosen. While this effect may be marginal for a single device, energy

efficiency in communications design will be important for individual households and

in aggregate may have considerable effect, as discussed in Chapter 3 (for example, see

chapter 14 of [129]).

A variety of wireless communications interfaces have been considered as enablers of

the IoT with a wide range of characteristics (e.g. bit rate, topology and energy consump-

tion) as discussed in Chapter 2. In this chapter, we compare the energy consumption char-

acteristics of five common consumer off-the-shelf (COTS) wireless interfaces while con-

sidering three different communication paradigms (event-driven, broadcast and polling).

The five wireless interfaces considered here represent today’s dominant COTS equipment

79

80 Energy Consumption of IoT Wireless Network Protocols

for IoT application. They include Bluetooth Classic (BT), Bluetooth Low Energy (BLE),

ZigBee, Wi-Fi and 433 MHz module (referred to as RF433 in this study). Power consump-

tion measurement of the COTS interface options was conducted for their various states

of operation, and utilised to determine their energy use in different scenarios.

To examine the options for energy-efficient communication using the COTS devices,

we employ a simple stock control application involving a domestic toaster communi-

cating with a gateway hosting an inventory system. This application is rich enough

to encompass the full range of design options while being simple enough to enable a

straightforward analysis of energy consumption. The application choice is in-line with

developing interest in ’smart kitchens’ [130] and automated stock control for online re-

ordering of basic grocery items [131, 132] as part of assisted living. Also, a toaster is now

considered as the first ‘thing’ of the Internet-of-Things [133].

While the example given here may be somewhat contrived, it illustrates the point that

careful design for energy usage and efficiency in the IoT will be important. The type and

volume of data, the frequency of data transmission, and the type of communications in-

terface should all be considered. The chapter is organised as follows: Section 4.2 gives a

brief description of the five wireless network communication protocols employed in this

study. Section 4.3 describes the measurement setup and presents the RF modules used.

The power consumption measurements are given in Section 4.4 followed by a descrip-

tion of the domestic stock control IoT application in Section 4.5. The energy consumption

model is given in Section 4.6 and a comparison of energy consumption discussed in Sec-

tion 4.7. Section 4.8 discusses energy-efficient design based on the results and Section 4.9

concludes the chapter.

4.2 Wireless Network Communication Protocols

In Chapter 2, a number of wireless network communication protocols that can be consid-

ered a part of the enabling technologies of the IoT are presented. In this section, a brief

description of the five commonly employed wireless network communication protocols

for IoT applications is given. They include Bluetooth Classic, Bluetooth Low Energy,

4.2 Wireless Network Communication Protocols 81

Wi-Fi, ZigBee and Radio Frequency 433 MHz (RF433).

4.2.1 Bluetooth Classic

Bluetooth technology, based on the IEEE 802.15.1 standard, is designed to support short-

range, ad-hoc connectivity amongst devices. Traditional or Bluetooth Classic (BT) oper-

ates in the license-free 2.4 GHz Industrial Scientific and Medical (ISM) band using adap-

tive Frequency Hopping Spread Spectrum (FHSS) channel access (1600 hops/sec), with

79 defined channels of 1 MHz channel width, 32 of which are used for device discovery

[34]. BT devices can operate either as a master or slave with one master interconnecting

up to seven active slave devices - hence a star topology. BT is capable of data rates up

to 2 Mb/s. However, BT has some major disadvantages which limits widespread im-

plementation in IoT applications. These disadvantages include a relatively high power

consumption, large data packets with huge overhead, complex protocol stack with large

memory demand, long connection time and limited range (∼ 10 m) [134]. Additionally,

while BT has some low power modes (e.g. sniff mode), it lacks an effective sleep-mode

regime which is critical for minimising energy consumption for battery-operated IoT de-

vices.

4.2.2 Bluetooth Low Energy

Bluetooth Low Energy (BLE) is defined in the Bluetooth Specification 4.0 [135] as the low

energy version of BT, designed for IoT-like applications - low cost and complexity, low

duty-cycle and infrequent transmission. Like BT, BLE (or Bluetooth Smart) is based on

the 2.4 GHz ISM band and uses FHSS but with 40 channels (including 3 advertisement

channels for device discovery) of 2 MHz channel width, and a data rate of 1 Mb/s. BLE

can either operate as a central (master) or peripheral (slave) device, with a slave able to

connect to only one master device at a time (i.e. star topology). An important feature

of BLE is its sleep-mode capability which, in combination with a low duty-cycle appli-

cation, significantly reduces the device energy consumption. A slave may broadcast a

limited amount of data in an advertisement packet, or a communications link between

82 Energy Consumption of IoT Wireless Network Protocols

a master device and a slave device may be established for dedicated or higher volume

traffic applications. While BLE has a longer range (∼ 30 - 50 m) than BT, its deployment

is limited to IoT applications with short-range requirements.

4.2.3 Wi-Fi

Based on the IEEE 802.11 standard for wireless local area network (WLAN), Wi-Fi op-

erates on multiple frequency bands (e.g. 2.4 GHz, 5 GHz, 60 GHz) and is a widely

used short-range wireless protocol. The Wi-Fi protocol has undergone several revisions

(802.11a/b/g/n/ac) with its latest version (802.11ac) capable of achieving broadband

speeds in excess of 500 Mb/s [136]. Wi-Fi supports two operating modes in its topology

formation: Peer-to-Peer (Ad-hoc) network topology and Star (Infrastructure) network

topology. While Wi-Fi was originally designed for high-speed, short-range (up to 100 m)

communication, its ubiquity in homes and places of work has resulted in an increasing

use in a number of IoT applications (e.g. Smart Light Bulbs or Smart Appliances).

4.2.4 ZigBee

Based on the IEEE 802.15.4 standard, which defines the PHY and MAC layers, ZigBee has

an established set of specifications for low power, low data-rate and short-range appli-

cations. The ZigBee Alliance defines the Network and Application Support layers [18].

ZigBee operates on the license-free 868 MHz, 915 MHz and 2.4 GHz bands with data

rates of 20 kb/s, 40 kb/s and 250 kb/s, respectively. In addition to its star and cluster-

tree networking capabilities, the ZigBee protocol can be configured for mesh networking

which offers long reach by means of data relay. ZigBee defines three types of devices:

(a) ZigBee Coordinator - acts as a gateway/hub and is the most resourceful, (b) ZigBee

Router (ZR) - acts as intermediate router in addition to application functions, (c) ZigBee

End-Device (ZED) - performs application functions and is the least resourceful device.

ZC and ZR are classified as fully functional devices while ZED is a reduced functional

device. The ZigBee protocol was designed for low complexity and low energy usage with

a sleep-mode capability.

4.3 Measurement Setup 83

4.2.5 RF433

Based on the ISM 433 MHz band, RF433 can be used for wireless data transmission, in-

cluding in wireless sensors and home automation systems (see Chapter 3). Its frequency

range is 433.05 - 434.79 MHz. RF433 is not a standardised protocol like Bluetooth, Zig-

Bee and Wi-Fi but is a widely employed, inexpensive wireless communication option for

many IoT devices and applications. Based on this backdrop and the general belief that

RF433 will be a common hardware selection in future IoT applications, it is included in

this study.

4.3 Measurement Setup

In this study, we measure the power consumption (energy consumption) characteristics

of each of the above communication technologies, in order to be able to compare their

performance in typical applications. A description of the experiment and measurement

setup is given in this section. It is assumed that each COTS wireless interface commu-

nicates with an always-on gateway device (i.e. master, ZC, etc.) that is common to all

scenarios.

4.3.1 Description of Measurement Setup

The components used in the measurements include two COTS short-range RF modules

for each communication protocol, an Arduino Duemilanove (Due) board [137] equipped

with Atmel’s Atmega 328P-PU microcontroler (MCU), a dc power supply and power

meter unit (described in detail in Chapter 3), a test computer (PC) and smartphone.

A block diagram of the experiment setup is shown in Figure 4.1. Earlier RF mod-

ules might include separated transceiver circuitry, antenna, MCU and serial interface but

modern RF modules today are mostly designed as a System-on-Chip (SoC) with inte-

grated transceiver module and MCU. Hence, the RF modules in this study are measured

as one SoC unit, given that, in practice, they may be deployed as such.

The power meter records power consumption, current draw (mA) and voltage (V)

84 Energy Consumption of IoT Wireless Network Protocols

RF Module

Arduino DuePC/

Smartphone

Mains (240V)

Power Meter

Slave/End-device Master/Coordinator

2.4 GHz / 433 MHz

RF ModulePower Supply

Measurement Unit

Data Logging PC

(DUT)

(Data Sink)(Data Source)

Figure 4.1: Block diagram of experiment setup

of the device under test (DUT)/end-device, and the measurements are logged on a PC

for post-processing. Measurements are recorded at an average of 1 ms intervals with an

accuracy of 10 µA. With the exception of the RF433 modules, which are either transmit-

only or receive-only, each RF module has 4 leads connected: +ve power input (VCC),

Ground (GND), transmit (Tx) and receive (Rx). Figure 4.2 displays an image showing

Arduino Duemilanove Board

XBee ZigBee RF Module

Power Supply & Power Meter

USB Cable to PC(Arduino Power)

GND

Tx

Rx

GND

VCC

Figure 4.2: Image of measurement setup for a XBee ZigBee module

4.3 Measurement Setup 85

this setup with an XBee ZigBee RF module as an example. The same principle applies

to DUT modules with USB connection. For accurate measurements of the DUT power

consumption, the VCC and GND leads are directly connected to the dc power supply via

a power meter, while the Tx and Rx leads are either connected to the transmit and receive

rail (terminals 1 & 2) on the Arduino board or a USB port. A steady voltage of 5V (or 3.3V

where applicable) is supplied to the modules during the tests.

The master/coordinator (gateway device) modules are powered from the power rails

on an Arduino board, the USB interface of a PC or the smartphone battery. Packets re-

ceived from the DUT are recorded with timestamps. Measurements are collected over a

5 minutes duration. In one case a digital oscilloscope (e.g. Digilent Analog Discovery

USB Oscilloscope) in a setup with a 10 Ω current metering shunt resistor was used for the

measurement.

In the experiment, the DUT - positioned about 1 meter away from the master/ coor-

dinator - is programmed to send the pre-set 10-byte (10B) data payload every 5 seconds.

The master/coordinator receives and displays the transmitted data on a serial monitor

using a terminal emulator such as Tera Term or Bluetooth Smart Data app. The Arduino

Due generates the 10B test data and is independently powered (not measured).

4.3.2 RF Module Power Measurement Setup

Table 4.1 gives details of the RF modules used in the experiments. For BT measurements,

a JY-MCU HC-06 module, compliant with Bluetooth v2.1 standard was used. The serial

interface of the BT DUT (slave) was configured at 9600 Baud. Bluetooth v2.0 standard

lacks the very low power sleep-mode; therefore, it is assumed that the module, when not

operated continuously, is turned off after every Tx and Rx operation of the DUT.

For the measurement of BLE, the Redbear BLE Nano v2 [138] was used. The BLE

Nano is a breakout board that simplifies prototyping or small-scale production of new

IoT products, based on the Nordic nRF52832. The latter is a SoC including the RF module

and an ARM Cortex-M4F SoC at its core. The BLE Nano comes with Bluetooth v4.2

protocol stack (Bluetooth 5 ready) and can be configured as a central or peripheral device.

86 Energy Consumption of IoT Wireless Network Protocols

Table 4.1: RF modules used in experiment.

Standard Device RF Module RF Module Firmware OperatingName Manufacturer Number Version Voltage (V)

Bluetooth JY-MCU Linvor HC-06 1.8 5Bluetooth LE BLE Nano v2 Nordic nRF52832 - 3.3

ZigBee XBee Digi XBee S2 28A7 3.3Wi-Fi Nano Dongle Realtek RTL8188CU 4.816.2011 5RF433 N/A Exportise FS1000A/ZRW-01* - 5

* Transmitter/Receiver

As the DUT, the BLE Nano was configured as a peripheral device (see Figure 4.1).

For ZigBee measurements, the Digi International’s XBee Series 2 radio modules [139]

were used. Using Digi’s XCTU software, one of the modules was configured as an end-

device and the other as a coordinator, both with their respective firmware. Transparent

mode communication was set in both XBees (AT mode) for an asynchronous serial inter-

face of 9600 Baud. Since ZigBee modules have sleep-mode capabilities, the end-device RF

module was configured in cyclic sleep-mode, waking up at regular intervals to transmit

its data payload before going to sleep. Power consumption and duration for the different

stages were recorded.

A nano Wi-Fi dongle designed for power-constrained devices (e.g. Raspberry Pi) was

used as a Wi-Fi RF module. The nano dongle is based on Realtek RTL8188CU chipset

and is IEEE 802.11n compliant. To avoid significant variation in power due to dynamic

transmit power control, the Wi-Fi module (end-device) and Access Point (AP), i.e. master,

were configured in Infrastructure mode while maintaining a separation distance between

0.5 and 1 metre. The AP used was a Belkin Wireless Pre-N router (firmware version

1.01.03) compliant with 802.11g and configured for immediate acknowledgement (ACK).

For the measurement of an RF433 module, the FS1000A transmitter and ZRW-01 re-

ceiver radio modules were used. They both use ASK modulation or On-off keying and

permit bit rates up to 9.6 kb/s. Since the transmitter and receiver are independent chips,

two sets of experiment configuration were needed - one for the transmitter and the other

for the receiver. In Chapter 3, examination of a range of commercial wireless sensor de-

vices that use RF433 radio modules showed that they are mostly transmitters designed

to re-send each packet multiple times to compensate for the lack of ACK packets from

the receivers. This redundancy mechanism is implemented in our application case-study

4.4 Power Consumption Measurement 87

described in Section 4.5, assuming each message is sent three times.

4.4 Power Consumption Measurement

This section describes the measurements, power consumption plots and values for exam-

ples of each type of wireless protocol considered in the experiments. In addition to the

main communication task (i.e. Tx and Rx as described in Section 4.3.1), we monitor and

report on other housekeeping functions (e.g. idle, wake-up, sleep) with each protocol and

their associated energy consumption. Power consumption values generally depend on

the device hardware implementation, and may vary slightly between examples of each

module type. Table 4.2 lists the power draw of the RF modules during their main oper-

ational phases while Table 4.3 lists their respective duration (in milliseconds) for trans-

mitting a 10B packet. For simplicity, the duration of the wake-up, pre-processing and

synchronization phases was concatenated into one; i.e. wake-up, as given in Table 4.3.

Table 4.2: Power consumption of RF modules in different operational phases.

RF ModulePower Consumption (mW)

Sleep Idle Wake-up Tx RxBluetooth - 16 96 199 185

Bluetooth LE 0.03 2.2 21 41 33ZigBee 0.17 30 91 139 129Wi-Fi - 61 66 67 64RF433 - 29 12 45 33

Table 4.3: Duration of operation in different phases.

RF ModulePhase Duration (ms)Wake-up Tx Rx

Bluetooth 1836 1 1Bluetooth LE 4 1 1

ZigBee 5 2.5 3.5Wi-Fi 3165 1 1RF433 1 126 406

88 Energy Consumption of IoT Wireless Network Protocols

4.4.1 BT Measurements

A Bluetooth link controller has a number of connection states including standby, inquiry

(scan/advertise), paging, connected/active, sniff, park and hold states [16]. Figure 4.3(a)

shows the power consumption of the BT module in a non-connected standby state de-

picting the advertisement and scanning phases. The device sends advertisements on

Advertisements Scanning

(a)

Standby Pairing Connected (Active) Sniff State (Low Power)

(b)

Figure 4.3: Power trace of BT module (a) in standby state showing the scanning and ad-vertising phases and (b) showing the state transitions from standby to pairing, connectedand sniff states.

different channels, each round lasting about 5 ms. During advertisement, the BT module

draws an average of 79 mW, consuming about 0.4 mJ each round. During scanning with

nearly 100% duty cycle (duration≈ 320 ms), the module draws about 208 mW consuming

67 mJ, which is over 50 times more than its advertisement phase. Such a huge disparity

in energy usage explains the reasoning for slave/end-devices - which are often energy

constrained - being limited to sending advertisements while master devices (often with

more resources, e.g. PC/ Smartphone) engage in scanning during the discovery process.

Figure 4.3(b) gives a much wider view of the major stages a BT device undergoes.

The figure shows the standby state, when scanning and advertisements are performed,

the pairing stage, when paging and synchronisation process occurs, the connected stage,

which includes data Tx, Rx and ACK, and lastly the low-power sniff state (i.e. idle),

when the module is less-active but listens for transmissions at set intervals (125 ms in

this case), depicted by the spikes on the right-hand-side of the figure. The average power

4.4 Power Consumption Measurement 89

consumption in the low-power sniff mode is about 16 mW. For this power draw, an Alka-

line AA battery of 1800 mAh capacity [140] can power this module for about 23 days only

in its low-power state. BT communication transmits complete data frames per timeslot

(1 timeslot = duration in 1 frequency hop) in 0.625 ms, with an ACK packet received in

a subsequent timeslot. Since the power meter can only resolve variations down to 1 ms,

the minimum phase duration is assumed as such.

4.4.2 BLE Measurement

The measurement was conducted for the BLE non-connected and connected/active states.

Figure 4.4(a) shows the power consumption trace of a BLE peripheral device advertising

at 200 ms intervals and in connected mode with connection events depicted on the right-

hand-side. Each advertisement payload was 30B long and was transmitted to three ad-

AdvertisementsConnection Events

(a)

Scanning

(b)

Post-processing

Figure 4.4: Power consumption trace of BLE module configured as (a) peripheral (slave)device showing advertisements and connection events (b) central (master) device in scan-ning mode.

vertisement channels. For one advertisement round, the peripheral consumed about 0.08

mJ, lasting about 2 ms (0.625 ms per timeslot). If an example BLE peripheral module only

broadcasts its advertisement packet once every second, a 1800 mAh AA battery [140] can

power the module for over 2040 days.

Figure 4.4(b) shows the power consumption trace of a non-connected BLE central

device scanning three advertisement channels with a 20% duty cycle (i.e. scan window

90 Energy Consumption of IoT Wireless Network Protocols

= 200 ms, scan interval = 1s). The steps in Figure 4.4(b) can be attributed to its post-

processing activities drawing ≈ 23 mW. For scanning the central consumes 14.4 mJ per

cycle. The energy consumption of a BLE module in its non-connected states ultimately

depends on the choice of a number of parameters (e.g. connection interval) based on an

application usage scenario. The measured power draw and duration of BLE connected

phases are given in Tables 4.2 and 4.3.

4.4.3 ZigBee Measurement

With ZigBee, the measurement was carried out on a configured XBee ZigBee end-device

as the DUT, which connects to an XBee ZigBee coordinator (i.e. gateway). The DUT was

configured for cyclic sleep-mode with reverse polling. In reverse polling, the end-device

(in sleep-mode) wakes up at regular intervals (default = 100 ms but can be modified in

firmware) and polls its coordinator to request any data sent to its address while sleeping.

The end-device sends a poll once after its wake-up sequence and again before going to

sleep. In sleep-mode, the XBee draws a maximum of 50 µA at 3.3V [139]. Figure 4.5 shows

CSMA/CA

(RX Mode)Rx

(ACK)

Tx

Wake-up

Sequence

Sleep

Rx to Tx & Tx

to Rx switch

(100 µs)MCU Shutdown

Sequence

Time (ms)

Cu

rren

t (m

A)

Shutdown pollData

Sleep

6 12 18 24 30 36 42 480-6 54

10

20

30

40

50

60

70

0

-10

-20

-30

Figure 4.5: Current draw of the XBee ZigBee end-device module during a connectionevent.

a detailed plot of a ZigBee end-device module current draw for one connection event.

4.4 Power Consumption Measurement 91

The plot shows the wake-up sequence which includes MCU wake-up, pre-processing

and synchronisation. The initial poll is shown in the next phase, starting with channel

access process, which is the contention based CSMA/CA as defined by the 802.15.4 MAC

specification. The duration of the CSMA/CA process may vary depending on channel

availability. The power consumption and duration values are reported in Tables 4.2 and

4.3 for an operating voltage of 3.3V. A similar example ZigBee module transmitting a

message once every minute, and is powered by a 1800 mAh AA battery would operate

for about 953 days.

4.4.4 Wi-Fi Measurement

In measuring the Wi-Fi module, an infrastructure operating mode was used. The Wi-Fi

module and the AP were configured for the IEEE 802.11g standard, with a maximum

theoretical data rate of 54 Mb/s (highest of all the RF modules considered). At start-up

the Wi-Fi module scans the channels for periodic beacons from the AP before connection

process is initiated. The measured duration for establishing a connection was about 3165

ms. The Wi-Fi module power draw in different states is reported in Table 4.2 and their

duration in Table 4.3. As with BT, the phase durations are assumed to be the limit of the

power meter (1 ms). We note that the idle power consumption of Wi-Fi (61 mW) makes it

unreasonable to use batteries. The same 1800 mAh AA battery described in the previous

section will operate this module for nearly 6 days only when in the idle state.

4.4.5 RF433 Measurement

The RF433 transmitter and receiver modules were measured separately. Figure 4.6(a)

shows the power trace of the 433 MHz Tx module sending 10B of data and Figure 4.6(b)

shows the Rx module receiving the same amount of data at 5 sec intervals.

The transmitter module consumes a small amount of power (≈ 0.03 mW) when idle

and about 45 mW on average when transmitting. This is depicted by the spikes in Fig-

ure 4.6(a), indicative of its on-off keying modulation. Tables 4.2 and 4.3 list the power

draw and duration values of the RF433 modules. Because the Tx and Rx modules lack an

92 Energy Consumption of IoT Wireless Network Protocols

(a)

TX

(b)

RX Listening RX RXListening

Data (RX)

Post-processing

Figure 4.6: Power trace of an RF433 (a) transmitter module sending a 10B data (b) receivermodule in receiving the same amount of data.

integrated MCU, there is no substantial wake-up time for the transmitter and very little

for the receiver (about 3 ms). The receiver module however maintains a steady but rela-

tively higher power consumption level (≈ 29 mW) when idle (i.e. listening mode) as can

be seen from Figure 4.6(b). The RF433 module has the longest over-the-air transmission

time due to its low data transfer rate (9.6 kb/s max) which is several orders of magnitude

less than that of the other RF modules. Furthermore, while the Tx and Rx duration are

similar for the same data transfer, the receiver remained at a higher power level for an

additional duration of about 280 ms for post-processing or data verification. A combined

transmitter and receiver pair power by a 1800 mAh AA battery will operate for nearly 13

days.

4.5 Domestic Stock Control IoT Application - A Case Study

4.5.1 Application Architecture

The basic application architecture of the IoT application is considered to include a large

number of end devices (sensors and domestic appliances), communicating via a short-

range wireless medium to a gateway device (eg. a ’home gateway’) and being controlled

by that gateway. In some cases, the home gateway will communicate through an external

network with cloud-based applications. While the popular wireless interface options

4.5 Domestic Stock Control IoT Application - A Case Study 93

discussed in the preceding sections have propagation or performance characteristics that

may be important in particular applications, the focus of this case study is on the energy

efficiency of each option in the context of a domestic operational paradigm.

Let us consider a simple domestic stock control application, envisaging a toaster re-

porting to the home gateway the number of bread slices it has toasted up to a particular

time. Coupled with reporting of the bread quantity when it first enters the household

(and other events), this can enable automated stock control and replenishment of bread

supply by a commercial supplier.

To support this application, a wireless communications interface must be added to

the toaster assuming the home gateway is already equipped with suitable interfaces. The

toaster interface will consume power in addition to the normal operation of the toaster

and will, in some circumstances, add a few percentage points to the power consumption

of the toaster. For this application, it is assumed that the gateway is within the ’smart

kitchen’ so that the communication range is a few metres at most. The toaster need only

report the number of slices of toast in a given period, so the payload is only a few bytes.

All the wireless options in the experiments are capable of providing the necessary range

and throughput. The energy consumption of the application over a period of one week

is considered.

4.5.2 Communication Paradigms

There are three basic communications paradigms which have different energy implica-

tions. These are:

(i) Broadcast

(ii) Polling

(iii) Event-driven

Broadcast Mode

In Broadcast mode, the toaster reports its status (number of bread slices toasted) at reg-

ular intervals (e.g. every minute). The communications interface of the toaster will be

94 Energy Consumption of IoT Wireless Network Protocols

active periodically, perhaps frequently. Because the application will require reliable com-

munications between the toaster and the gateway, the communications interface will re-

main active after wake-up from its sleep/off state until an acknowledgement has been

successfully received (if possible). It can then return to an inactive ’sleep’ state until the

next communications cycle. In Broadcast mode, the natural cycle adopted for this appli-

cation is hourly: that is, the stock control algorithm determines when more bread will be

required and schedules a delivery at some future hour.

Polling Mode

In Polling mode, the gateway asks the toaster at particular times to report its status and

the toaster does so. The communications interface should be in a listening state at all

times and should become fully active when a polling request is received. When respond-

ing to a polling request, the communications interface is fully active until an acknowl-

edgement has been successfully received. It can then return to a listening state. The

Polling mode is assumed to be governed by a standard stock-control application in which

the economic order quantity (EoQ) is proportional to the square root of the demand, i.e.

EoQ = k√D, where D is the demand and k is a constant (see, for example, [141]). Figure

4.7 shows a plot of polling instances against demand. The red curve is a scaled square

root of demand and the blue curve, the average number of polling instances. Given the

assumption of EoQ, the next polling event is set at one-half of the estimated time to ex-

haustion of bread supply, with the restriction that polling should be no more frequent

than once per hour and no less frequent than once per day. This is a minimal polling

design: a ’simpler’ design (e.g. polling once per hour) could generate many more polling

events. In this design, the toaster is polled only once per day for low numbers of toasting

events. The number of polling events increases only as the square root of demand and,

with a suitable value of k, can be kept below 25 polling events per week even for large

numbers of toasting events.

4.6 Energy Consumption Model 95

Square root of demand (scaled)

Average number of polling instances

Figure 4.7: Plot of polling instances against demand.

Event-driven Mode

In Event-driven mode, the toaster reports only when a toasting operation begins. The

toaster interface becomes fully active when new bread is introduced to the toaster. It

remains active until an acknowledgement has been successfully received (or communi-

cation is deemed successful) before returning to inactive state. The number of events is

usage driven.

Which of these communications paradigms uses least energy for a specific wireless

interface depends both on the relative energy usage of the interface in its various states

and on the frequency of use, that is, on the traffic at the toaster. No one communications

paradigm is optimal over the full traffic range.

4.6 Energy Consumption Model

The main operational modes/states of the wireless interfaces (RF modules) for which

power consumption measurement was conducted include:

• Inactive or sleep mode - in cases without explicit sleep mode, this is when the interface

96 Energy Consumption of IoT Wireless Network Protocols

is turned off.

• Wake-up mode - Transitions between sleep and active and from active to inactive.

• Listening/Idle mode - when the interface can detect and receive a message but may

not be able to transmit.

• Transmit mode - when the interface is transmitting data.

• Receive mode - when the interface is receiving data.

The total energy consumption Etotal of a short-range RF module is a summation of the

ith wake-up (Ewui), transmit (Etxi) and receive (Erxi) energies, in addition to the energy

consumed in the sleep and idle states, Es and Eid, expressed as:

Etotal = Es + Eid +N∑i=1

(Ewui + Etxi + Erxi

)(4.1)

Etotal = PsDs + PidDid +

N∑i=1

(PwuiDwui + PtxiDtxi + PrxiDrxi

)(4.2)

where Ps, Pid, Pwu, Ptx and Prx are the power consumption of the RF module in the

sleep, idle, wake-up, Tx and Rx modes and Ds, Did, Dwu, Dtx and Drx their respective

durations. N is the number of communications: i.e. number of events, broadcasts or

polling requests.

4.6.1 Energy Measurement

The power draw and duration measurements given in Tables 4.2 and 4.3 are applied

to the model. The calculated energy is the product of the power draw and duration.

With polling communication (home gateway to end-device), the RF module remains in an

idle/listening state in order to detect incoming packets. Therefore, for Wi-Fi, BT (in sniff

mode), BLE and RF433, there is no sleep and wake-up power consumption component in

equation (4.2). In a weekly cycle, the time taken in the idle mode is the total weekly period

(604,800 seconds) less the time for all polling request transmissions. ZigBee, unlike the

other three interfaces, can go into sleep-mode during this phase, and reverse polls (end-

device to home gateway) its coordinator/master at regular intervals.

4.6 Energy Consumption Model 97

When designed for broadcast-only communication, a 10B payload is sent by the end-

device (toaster) once every hour. Consequently, there will be 168 transmissions (N = 168)

per week irrespective of the frequency of toast slices made. In an event-driven communi-

cation, however, the energy consumed by the modules scales linearly with the number N

of toasts made. The energy consumption of Wi-Fi and BT modules can be greatly influ-

enced by the time required (see Table 4.3) to power on and re-establish connection with

the master/coordinator. For the BT module, an average of 640 ms was measured for a

complete inquiry scan and advertisement (stages of BT protocol), assuming the interface

is completely turned off at the end of each transmission. It takes an average of 1836 ms

for the BT wake-up phase (including turn on, inquiry scan, paging and synchronization)

during which the HC-06 consumes an average of 96 mW. The nano Wi-Fi dongle takes a

little longer (3165 ms) in the wake-up phase but with lower average power consumption

(66 mW).

4.6.2 Processing and Storage Energy

A simple IoT hardware application like the toaster example requires some processing

and storage of data bits. Although the main focus of this work is on the measurement

and assessment of the communication energy consumption, an IoT toaster needs some

memory to store toast counts, which can be incremented step-wise until its reset point. It

is therefore necessary to consider its potential processing and storage energy usage.

For the same MCU and clock crystals on a circuit board, the processing energy usage

may be small but similar for the three communication methods. With regard to stor-

age, while an event-driven method may not necessarily require storage, the broadcast

and polling methods do. Recent RF modules are designed as a SoC, with a few kilo-

bytes/megabytes of static random access memory (SRAM) or NAND flash memory. For

example, the toaster could be designed with a 32-bit ARM Cortex M4F MCU (as in [142]),

which has 64 KB SRAM and 512 KB flash memory. The M4F consumes 1.2 µA (2V op-

erating voltage) in a low-power state with full SRAM retention. Hence, a toaster may

consume about 1.5 J per week to retain the toast count data of less than 10B, which is far

smaller than the capacity of the SRAM. Utilizing flash memory, on the other hand, does

98 Energy Consumption of IoT Wireless Network Protocols

not require power to retain data (non-volatile). A study in [143] shows that a NAND

flash memory consumes 4.72 µJ and 38.04 µJ to read and write data, respectively, to a 2

KB memory page within a 128 KB memory block. For 250 read/write operations, a flash

memory may consume as much as 10.7 mJ of energy.

The choice of memory is dependent on the type of application, the frequency of data

requests and amount to data per operational duty cycle. We can, however, conclude that

the energy use for running the processor and storing or retaining the data bits is small

and can be ignored if flash memory is utilized for this application.

4.7 Comparison of Energy Consumption

The plots in Figure 4.8 show the weekly energy usage comparison of BT, BLE, ZigBee,

Wi-Fi and RF433 for the three communication paradigms considered in this study. For

event-driven and broadcast modes, it is assumed that the interface is turned off between

communications events. In all modes, the Wi-Fi module is the most energy hungry, with

BLE being the most energy-efficient for all but one (i.e. Polling). ZigBee is more energy-

efficient than BLE for polling due to its reverse polling capability. This allows the ZigBee

module to sleep for longer periods while BLE periodically listens to the central (home

gateway) for polling requests. This result demonstrates an incentive for the communica-

tion to be driven by the end device. Whilst it is energy-wise (visibly from Figure 4.8 (a))

to choose event-driven mode for lower usage rates, the broadcast mode is more energy-

efficient beyond 168 servings per week. The energy usage of polling mode, however, is

several orders of magnitude higher than both broadcast and event-driven modes, since

the RF modules must stay in idle mode to receive incoming polling requests from the

home gateway. Note that the variation of the polling energy numbers is masked on the

plot due to the use of a logarithmic scale.

As an example, if toasting 20 slices of bread in a week, the BLE interface, configured in

polling, event-driven or broadcast mode, will consume 36.9 kJ, 4.2 J or 35.3 J, respectively.

Hence polling mode uses nearly 9000-times more energy (about 40000-times more for

BLE). To put this in perspective, an 800 W toaster will consume 72 kJ of energy in one

4.8 Energy-Efficient Design 99

BT

BLE

ZigBee

Event-drivenWi-Fi

RF433

(a)

BT

BLE

ZigBee

Broadcast Wi-Fi

RF433

(b)

BTBLE

ZigBee

Polling

Wi-Fi RF433

(c)

Figure 4.8: Energy consumption per week for BT, BLE, ZigBee, Wi-Fi and RF433 usingcommunications paradigms (a) Event-driven, (b) Broadcast and (c) Polling.

toasting operation (1.5 minute average toasting time). That is, adding an always-on Wi-

Fi interface to a toaster in this instance adds about 2.6% (1 slice per toasting event) or

5.1% (2 slices per toasting event) to the power consumption.

4.8 Energy-Efficient Design

This section draws some conclusions about energy-efficient design using the application

architecture from section 4.5 and power measurements from section 4.4. In particular, we

show that the most energy-efficient communications paradigm for each wireless interface

100 Energy Consumption of IoT Wireless Network Protocols

depends on the number of events reported (or amount of traffic) over the interface.

4.8.1 Interfaces Always On

The comparisons in Section 4.7 indicated that polling is not an energy-efficient option.

This assumed, however, that the interfaces would be turned off between events in event-

driven and broadcast modes. A naive design would just add a standard wireless interface

to an end-device and assume that the interface is always on. Figure 4.9 shows the total

energy per week used by an RF433 interface with the three communications paradigms

if the RF module stays on the entire time. In this case (and in general, if the interfaces are

Broadcast

Polling

Event-driven

RF433 (Always On)

Figure 4.9: Energy consumption per week of an RF433 interface (Always On).

always on), event-driven communication is preferred in the case where the number of

servings is very small. Once the number of toasting events exceeds a threshold (about 7

for this example), polling mode is more energy efficient. Broadcast mode will eventually

become the most energy efficient mode when the number of servings is very large (not

shown in the figure). Although this is a somewhat contrived example, it shows that the

energy-efficient design of the local wireless communications for the Internet of Things

can depend both on the choice of wireless interface and the amount of traffic (or applica-

tion) to be carried.

4.9 Conclusions 101

4.8.2 Interfaces Powered Down When Not In Use

For most traffic levels, sleep-mode is important for energy-efficient communications. For

very high traffic levels, always-on polling will eventually be preferable to event-driven

communication, but in this case broadcast will be the most energy efficient paradigm.

Figure 4.10 shows the total weekly energy used by a BT interface when toggling on/off

Polling

Event-driven

Broadcast

BT (Toggled On/Off)

Figure 4.10: Energy consumption per week of the BT interface (toggled on/off).

in the broadcast and event-driven modes. (Note the logarithmic scale in order to accom-

modate all three communication modes.) In this case, the event-driven mode is preferred

until the amount of traffic exceeds the constant broadcast frequency, after which broad-

cast mode is preferred.

4.9 Conclusions

In this chapter we have measured the energy use of five popular wireless interfaces when

they are in their inactive, listening and transmitting states. Using these measured values,

we have calculated the total energy usage for three different communications paradigms

– broadcast, polling and event-driven. In each case, it has been shown that the most

energy-efficient communications paradigm depends both on the relative energy usage by

102 Energy Consumption of IoT Wireless Network Protocols

the interface in its various modes and on the frequency and volume of traffic transmitted

over the interface.

These results suggest that for an IoT application developer, careful consideration of

the applications to be run over the wireless interfaces will be required to determine an

energy-efficient design. In many cases, the level of traffic will be uncertain (or will change

over time). The results suggest that applications should be designed to adapt to traffic

levels by selecting a different communications paradigm when it becomes more energy

efficient to do so.

Note also that a least-capital-cost solution may not be the most energy efficient (and

hence the least cost over the lifetime of the interface). Bluetooth and Wi-Fi interfaces,

for example, may be lowest cost and most readily available because of their volume pro-

duction but may consume more energy than alternatives. Their many communications

features may also be of no benefit for the specific application for which the communi-

cations interface has been added. A design process that takes into account total cost of

ownership (including both initial and operating costs) will be preferable.

Chapter 5

Energy-Efficient Architecture for IoTVideo Surveillance Services

5.1 Introduction

V IDEO surveillance systems and services are increasingly becoming a significant

application of the Internet-of-Things (IoT). IoT video surveillance application in-

volves generating streams from one or more video sources (cameras) at an end-user’s

premises, some level of signal compression and in some cases aggregation at those premises,

transmission through the public network to another user premises (live streaming), or

to a storage facility (e.g. data centre) from which the signal can be delivered to other

premises on demand.

Many emerging IoT services like video surveillance are still in the embryonic state of

deployment and yet to be fully characterised in the literature. Hence, there is little study

and analysis of their energy consumption and implications for the networks on which

the service is built. There is therefore a need for an end-to-end analysis of the application

data flow, taking into account the energy associated with every network segment. Fur-

thermore, a good understanding of step-wise energy consumption can be important in

determining an energy-efficient network architecture for the service.

Cloud computing has been pivotal to the growth of IoT services including video

surveillance applications. However, cloud computing may not always be an optimal so-

lution for processing and distribution of video data due to many quality-of-service (QoS)

103

104 Energy-Efficient Architecture for IoT Video Surveillance Services

and other concerns including latency, bandwidth utilisation, mobility support, location

awareness and energy consumption [56, 57]. Fog computing, an emerging alternative to

cloud, promises to address these concerns by bringing cloud intelligence and resources

much closer to the user with the implementation of distributed computing [67, 68]. It

has been shown that Fog computing could aid in the reduction of energy consumption,

both in the network architecture and cloud [63, 69]. The study in [63] shows that the

power consumption of an industrial IoT video streaming service could be improved by

more than 50% compared with cloud computing and storage alternatives. This could

be achieved through local processing in a local (fog) server as oppose to cloud, a result

achieved by applying machine learning techniques to analyse and prioritise the video

data.

In this chapter, an investigation of the energy trade-off between the network architec-

tures of IoT video surveillance systems is carried out. The study considers use cases of

live video streaming, on-demand video streaming from a fog [i.e. local (direct) or edge]

or cloud data storage, and processing of video data (using a face recognition applica-

tion). As with the rest of the work described in this thesis, the focus is on a domestic

(or small-business) IoT application context. Further, this chapter deals specifically with

streaming, storage and processing of an end-user or customer’s video data, and not the

larger scale streaming of video traffic from service providers such as ISPs or companies

such as Netflix.

A network IP camera (IPcam) based video surveillance service is employed as a use-

case model for a generalised IoT video surveillance service. Such a service might, as an

example, be part of a security service, or part of an in-home aged care monitor service,

etc. The contributions in this chapter are as follows:

(i) A detailed power consumption modelling of a network IP camera taking into ac-

count the effect of video frame rate, pixel rate and video bit rate on its power usage.

(ii) An end-to-end equipment-level energy consumption model for network architec-

tures of IoT video surveillance services and their video streaming and storage en-

ergy consumption implications.

(iii) An assessment of the energy implication of video processing when done locally as

5.2 Motivation for study 105

opposed to processing at an edge data centre or a more remote cloud data centre,

using as an example a face-recognition application.

Our empirical analysis, modelling and results offer insight into the energy efficiency

of video surveillance applications and services in an IoT context, and could help appli-

cation developers and architects make informed decisions in optimising and deploying

more energy efficient services.

The chapter is organised as follows. Section 5.2 gives the motivation for this study

and 5.3 introduces an IoT video surveillance system. Section 5.4 details experiments and

measurements conducted for this work and a model for power consumption of a net-

work IPcam is detailed in section 5.4.3. Section 5.5 gives a general network architecture

for IoT video streaming and the network element energy models are given in 5.6. Sections

5.7 and 5.8 discuss modelling for live streaming and on-demand streaming architectures

respectively and section 5.9 evaluates a face recognition application as an example of

surveillance-oriented video data processing. A conclusion and insights into the implica-

tions of the results is given in section 5.10.

5.2 Motivation for study

The principal component of a video surveillance application is the streaming of data-

intensive Standard Definition (SD), High Definition (HD) or Ultra High Definition (UHD)/

”4K” video across the public network infrastructure to Data Centres (DC), irrespective of

the geographical location of the service-specific DC. Today, a number of service providers

offer and actively promote 24/7 HD (1080p) or UHD (2160p) live video streaming ser-

vices with pay-per-use cloud storage (for on-demand access) for up to 30 days (e.g. Nest

Cam1, Amazon Cloud Cam2) or more. Furthermore, it is also actively promoted that

users can share - directly or via embedded web-links on a website - access to live video

streams or stored video files through the IPcam’s management application. Some of these

features could potentially have significant network energy implications for the service as

1https://nest.com/cameras2https://www.amazon.com

106 Energy-Efficient Architecture for IoT Video Surveillance Services

a whole. Investigating these possible energy consumption implications on the network

infrastructure (e.g. due to traffic increase) will form the basis of this work. To put the

ensuing traffic volumes of these services into perspective, let us consider a back-of-the-

envelope calculation for a representative example video surveillance system.

A 2 Megapixel HD IPcam operating at 30 frames per second (f/s) requires a bit rate

of 4-6 Mb/s for an acceptable video quality [11, 144]. An IPcam continuously streaming

at this rate will initiate and upload a data traffic volume of ≈ 1.6 TB/month across the

Internet to a DC. Such a traffic volume is about 10-12 times the monthly average Aus-

tralian household data consumption [119, 145] and exceeds many ISP broadband data

plans today. A full UHD video stream requires a bit rate 2-3 times more than a HD and

8-9 times more than a SD video stream [28]. Assuming UHD streaming, it will take just

under 15 million annually subscribed camera units (noting the projected shipment of 98

million camera units in 2017 [146]) to exceed the global IP traffic (≈ 1.06 Zettabytes) in

2016 [28]. Clearly, backhaul of UHD IoT video streams may come at a significant net-

work infrastructure energy cost and could degrade network QoS if this usage scenario

is adopted. A good understanding of the related energy consumption is needed, and

possible mitigation strategies are yet to be fully studied.

5.3 IoT video surveillance system

An IoT video surveillance system can be described as an all-in-one commercial off-the-

shelf IoT solution for personal or commercial video surveillance (e.g. Nest Cam1, Ama-

zon Cloud Cam2, Foscam3, Netgear Arlo4). A typical video surveillance system com-

prises of one or more network IPcam(s) and a bundled cloud service, with web-based

front-end applications through which live video streams from the IPcam, or on-demand

historical video clips can be accessed [10, 11, 144]. In contrast to older video surveil-

lance technologies, network IPcams are cost-effective and simpler to set up. They benefit

from the use of the standard public IP-based network infrastructure and relatively less

costly DC storage and processing services, enabling secured world-wide access to any

3https://www.foscam.com4https://www.arlo.com/en-us

5.3 IoT video surveillance system 107

connected IPcam unit. The internal structure of an IPcam and network topology of an

IoT video surveillance system are described in sections 5.3.1 and 5.3.2 below.

5.3.1 IP Camera Structure

Figure 5.1 shows a conceptual model of a network IPcam depicting the functional blocks

representing the processes within the IPcam [10–12]. The IPcam consists of three main

Camera Sensor (e.g. CCD)

CPU

Digital Image Processor

Compression Module

(e.g. H.264 Encoder)

Network Interface

Peripheral Ports

(e.g. MIC, Audio, SD Card, etc...)

Flash Memory

RAM

Image Processing Input / Output

IP Camera

Ethernet / Wi-Fi

External Ports

IoT Device IoT Gateway

Web Server

Power Supply

Figure 5.1: Block diagram of the internal structure of an IP camera [10–12]

subsystems: a Camera Sensor Unit (CSU), Image Processing Unit (IPU) and an embed-

ded web server. More recent IPcam models have integrated ASIC chip (CPU) with the

IPU integrated within the CPU [147]. During operation, captured image data from the

camera sensor arrives at the image processing unit after undergoing analogue-to-digital

signal conversion. The images are then compressed and encoded into video frames by the

compression module, applying a specified video encoding standard (e.g. H.264 or Ad-

vanced Video Coding standard). A preloaded firmware stored in flash memory provides

108 Energy-Efficient Architecture for IoT Video Surveillance Services

an instruction set by which encoded data is processed, stored or transmitted. Depending

on the configuration set and firmware, the web server may service HTTP/HTTPS or FTP

server requests, processed via the CPU. Encoded video data frames are then streamed

across the network using TCP/IP via the network interface as shown in the Figure 5.1.

Network access can be implemented either with Ethernet or Wi-Fi protocol, with some

IPcam systems having both. The camera sensor as a unit by itself and the IPU plus web

server combined are akin to an IoT device and IoT gateway, respectively. The IPcam has

an additional infrared night vision feature that is activated under low light conditions.

5.3.2 Network Structure

Figure 5.2 shows a schematic network structure of an IP camera-based video surveil-

lance service. The IPcam located within the IoT Device Network (IDN) captures real-

Network

Infrastructure

Network

Infrastructure

Cloud

Data Centre Data Centre

Ed

ge

/ F

og

Co

mp

uti

ng

Clo

ud

Co

mp

uti

ng

Remote Users

(via Cloud DC)

Gateway

Remote Users

(Direct or via Edge DC)

Gateway

Ethernet / Wi-Fi / 4G LTE

IP Camera

Storage (SD/HDD/SSD)

Gateway

Local UserIDN

Figure 5.2: Simple schematic network structure of a network IP camera-based videosurveillance service.

time signals for image stills/snapshots or video frames, formatted as data blocks for

5.4 Experimental Parameters and Measurements 109

uplink transmission through the network. Data from the IPcam is transmitted through

the LAN to a gateway. The gateway may be a home gateway (HGW) in a home set-

ting, an access point/router in an office/building or a cellular (4G LTE) wireless mo-

dem. The gateway in turn is connected to the public network. In the public network,

the data travels through the network infrastructure (discussed in section 5.5) en route

to a DC. A local user (having correct security credentials) with a network-enabled de-

vice (i.e. PC/Laptop/Smartphone/Tablet etc.) capable of running a web browser can

access live video streams from the IPcam, through the LAN, using a video management

software or mobile app. Remote users (direct or via edge/cloud DC) - also with correct

security credentials - are granted similar access either via port forwarding at the gateway

device, Dynamic Domain Name Service (DDNS) or the edge/cloud DC. Video/image

data blocks can be stored: (i) locally onto an attached SD Card, (ii) locally to a PC/laptop

or potentially in storage attached to the HGW within the LAN, or (iii) remotely at a DC.

5.4 Experimental Parameters and Measurements

In this section a description of the experiments and measurements carried out in this

study is presented. To demonstrate a typical IoT video streaming service, a Foscam

FI9831W network camera [55] was used as a test IPcam. Table 5.1 lists the features, config-

uration limitations and firmware version of the FI9831W IPcam. The camera parameters

limited the measurements ranges to a maximum frame size of 1280 x 960 pixels, a frame

Table 5.1: Parameters of the Foscam FI9831W IP Camera.

Parameter ValueVideo Resolution (max.) 1280 x 960 pixelsVideo Encoder H.264/AVSStorage (SD Card) 16 GBFrame Rate (f/s) 1 - 30 (max)Bit rate (max) 4 Mb/sNetwork Access Ethernet/Wi-FiSystem Firmware Version 1.4.1.10Application Version (Web Server) 2.11.1.120

110 Energy-Efficient Architecture for IoT Video Surveillance Services

rate of 30 f/s and a maximum configurable bit rate of 4 Mb/s. A frame in this context

refers to one image within a video stream. The IPcam’s video encoder runs a standard

H.264 video compression algorithm [60], which restricts all of the experiment measure-

ments to H.264 encoding. A 16 GB class 10 SD card was used as the local data storage

device for some of the experiments.

5.4.1 Measurement Setup

The measurement setup is as shown in Figure 5.3. For convenience, the IPcam is posi-

tioned facing a target scene with little motion - tests with constant motion did not show

a difference in power. The IPcam power consumption during each experiment was mea-

sured and recorded through a USB-connected data logging laptop (see Figure 5.3), using

a digital AC power meter, Power-Mate PM10AHDS [148]. The meter has an accuracy of

± 0.01 W and granularity of 1 second. Data traffic generated by the video stream was

captured using a packet sniffer application, ”Wireshark”, on the client PC, as shown in

Figure 5.3.

Power Meter

Gateway

Wireless Router

Power Data Logging Laptop

Ethernet/Wi-Fi

USBMains(240 V)

Web Browser & Packet Sniffer (Wireshark)

IP Camera(Web-server & Local Storage)

Pow

er

Cloud

Figure 5.3: Measurement setup comprising IP camera, power meter and data loggingPCs.

5.4 Experimental Parameters and Measurements 111

To determine the power consumption profile of the IPcam, a number of experiments

were conducted with varying load - load in this context referring to the video frame size,

frame rate and video bit rate. These settings were made through the IPcam’s web-based

video management application (version 2.11.1.120). Configuration settings are then writ-

ten to the IPcam’s video encoder and a pre-test wait time of 2 minutes was allowed prior

to commencing each test. The test-series configurations are given in Table 5.2. The first

Table 5.2: Experimental configuration of the IP Camera.

Frame Frame Size Number Aspect Bit RateDescriptor (pixels) of Pixels Ratio Limit (b/s)

180p 320 x 180 57600 16:9 200k240p 320 x 240 76800 4:3 256k360p 640 x 360 230400 16:9 512k480p 640 x 480 307200 4:3 1M720p 1280 x 720 921600 16:9 2M960p 1280 x 960 1228800 4:3 4M

column in Table 5.2 denotes a convenient shorthand frame descriptor employed in this

study to refer to the different frame sizes. A test-series may include the live stream-

ing frame size (i.e. 320 x 180 to 1280 x 960 pixels), the designated frame rate (i.e. 5 -

30 f/s in steps of 5 f/s), the maximum allowable bit rate (200 kb/s to 4 Mb/s) and the

H.264 key frame interval (i.e. time between 2 full frames). Applying industry best practice

[10, 11, 144], the key frame interval was set at 2 seconds for all test-series (e.g. for a 30 f/s

configuration, one full frame (i-frame) is produced every 60 frames while delta/p-frames

are produced between full frames. See [60] for more details.) The minimum configurable

key frame interval is 10 frames - hence the minimum frame rate measured is 5 f/s.

For each test-series, an elapsed video streaming time of 5 minutes was employed and

the reported power values are an average of 300 power readings (1 per second). Each test

was conducted using both Ethernet and Wi-Fi network access. Tests were also conducted

when recording and storing video files locally on the SD card and remotely to a DC. For

streaming and/or storage via a DC, power consumption models for cloud services were

developed using the IPcam’s parent cloud service (i.e. Foscam) and a third-party cloud

112 Energy-Efficient Architecture for IoT Video Surveillance Services

service (i.e. camCloud5) as examples. Both services use Amazon EC2 data centre servers

based in North America.

5.4.2 Power Consumption Measurements

The results of the power consumption measurements are presented in this section. Two

key parameters were varied in the tests for a set of frame sizes: (i) video frame rate and

(ii) video bit rate.

Power Consumption vs Frame Rate

Power consumption measurements were recorded while varying the IPcam frame rate

from 5 f/s to 30 f/s in steps of 5 f/s, for a maximum bit rate setting and key frame inter-

val (2 sec), when streaming video with frame size 180p, 240p, 360p, 480p, 720p, 960p

pixels as given in Table 5.2. Figure 5.4 (a) & (b) show results of power consumption

measurements as a function of video frame rate for Ethernet and Wi-Fi network access,

respectively. Each curve corresponding to a designated frame size (in pixels) consists

3.0

3.2

3.4

3.6

3.8

4.0

0 5 10 15 20 25 30 35

Pow

er (

W)

Frame rate (f/s)

240p

720p480p

960p

Ethernet

180p 360p

Linear ModelMeasurement

No-load / baseline power

(a)

3.0

3.2

3.4

3.6

3.8

4.0

0 5 10 15 20 25 30 35

Pow

er (

W)

Frame rate (f/s)

180p

720p

360p

960p

No-load / baseline power

Wi-Fi

240p

480p

Linear ModelMeasurement

(b)

Figure 5.4: Power consumption as a function of frame rate of a network IP camera with(a) Ethernet access and (b) Wi-Fi access.

of a baseline component (y-intercept), and an additional component that is linearly load-5https://www.camcloud.com

5.4 Experimental Parameters and Measurements 113

dependent, a behaviour analogous to that of some network devices and modern personal

computers, and corroborated by a number of studies [95,96]. The slope of the lines in Fig-

ure 5.4 increases with an increase in frame size due to the higher energy cost of encoding

and transmitting larger frames.

Table 5.3: Line of best-fit equations for power consumption as a function of frame rate ofthe IPcam, where x = frame rate.

Frame Number Power (Watts)Size of pixels Ethernet Wi-Fi180p 57600 3.07 + 0.5× 10−3x 3.51 + 0.9× 10−3x

240p 76800 3.07 + 1.2× 10−3x 3.52 + 1.2× 10−3x

360p 230400 3.08 + 1.6× 10−3x 3.52 + 1.4× 10−3x

480p 307200 3.08 + 2.3× 10−3x 3.53 + 2.2× 10−3x

720p 921600 3.06 + 4.5× 10−3x 3.51 + 4.3× 10−3x

960p 1228800 3.05 + 6.6× 10−3x 3.53 + 6.1× 10−3x

Using the linear least squares method, the lines of best-fit for each curve were plotted.

Thus for a given frame size, at x f/s, the IPcam power consumption is given as: bf +mfx,

where bf (in watts) denotes the y-intercept which corresponds to the no-load/baseline

power, mf is the slope/load-dependent power component representing the energy con-

sumption per frame and expressed in joules per frame (J/f) - the subscript f refers to

frame rate. Equations of the lines of best-fit for each curve are given in Table 5.3.

From Figure 5.4(a) [Ethernet] and Table 5.3, the baseline power consumption, bf ≈

3.07± 0.01 W represents more than 90% of the peak power draw at the maximum frame

rate. Table 5.3 lists the baseline power bf, and the incremental energy per frame mf as

the coefficient of frame rate x. Standard Deviation (SD) and Standard Error (SE) of bf are

≈ 0.01 and 0.005 respectively. Similarly for Wi-Fi network access, [see Figure 5.4(b)], the

baseline power draw, denoted by bf ≈ 3.52 ± 0.01 W [SD = 0.01, SE = 0.004], shows an

additional 0.45 W compared with that of the baseline with Ethernet. This difference is

attributable to the Wi-Fi network card. Note that the Ethernet port was in the on-state

during Wi-Fi experiments. The incremental energy per frame for the Wi-Fi connected

IPcam, mf is also given in Table 5.3.

114 Energy-Efficient Architecture for IoT Video Surveillance Services

From measurement, under low light conditions, the IPcam consumes an additional

baseline power of ≈ 2 W to drive its infrared camera functionality.

Estimating the Energy per pixel

The trends in the results above with increasing pixel counts imply that energy per pixel

is a unifying concept for the varying frame rates. To determine the per-pixel energy

consumption - expressed in joules per pixel (J/px), the energy per frame results presented

in Table 5.3 were utilised. Fig 5.5(a) and (b) show plots of the incremental energy per

frame (mf and mf) as a function of frame sizes (in megapixels). Using the linear line of

0

2

4

6

8

10

0 0.2 0.4 0.6 0.8 1 1.2 1.4

Millions

Incr

emen

tal E

ner

gy p

er F

ram

e (m

J)

Frame Size (Mega pixels)

Ethernet

(a)

Linear ModelMeasurement

Slope = Energy per pixel

0

2

4

6

8

10

0 0.2 0.4 0.6 0.8 1 1.2 1.4

Millions

Incr

emen

tal E

ner

gy p

er F

ram

e(m

J)

Frame Size (Mega pixels)

Wi-Fi

(b)

Linear ModelMeasurement

Slope = Energy per pixel

Figure 5.5: Incremental energy per frame plotted as a function of frame size (in megapixels) for a network IP camera with (a) Ethernet access and (b) Wi-Fi access.

best-fit equation, the incremental energy per framemf = bpx +mpxy and mf = bpx +mpxy,

where y represents the pixel count in the frame. The vertical intercepts (bpx and bpx) are

at 567 nJ with Ethernet and 693 nJ with Wi-Fi access. Similarly, the slopes/incremental

energy consumption per pixel (mpx and mpx) are 4.7 and 4.2 nJ/px with Ethernet and Wi-

Fi access respectively. This difference in energy per pixel might more likely be ascribed

to measurement uncertainty, since the measuring device had an accuracy of±10 mW (i.e.

10 mJ for 1 sec granularity), or to the Ethernet and Wi-Fi connectivity within the Foscam

being implemented with completely different driver chipsets.

5.4 Experimental Parameters and Measurements 115

Power Consumption vs Bit Rate

The IPcam configuration allows setting of its maximum video bit rate independently of

the frame size and frame rate; this is achieved by adapting its video encoding parameters.

Investigating the IPcam power consumption as a function of the video bit rate required

keeping the frame rate and number of key frames constant while varying the bit rate for

each configurable frame size. Only the top four bit rate steps were considered (i.e. 0.5,

1, 2, and 4 Mb/s) as there was no discernible difference in the consumption for lower bit

rate steps (i.e. 100 to 256 kb/s). A frame rate of 25 f/s and a key frame interval of 2 seconds

were used.

3.0

3.2

3.4

3.6

3.8

4.0

0 1 2 3 4 5

Pow

er (

W)

Bit rate (Mb/s)

240p720p

480p

960p

Ethernet

180p 360p

(a)

Linear Model

Measurement

3.0

3.2

3.4

3.6

3.8

4.0

0 1 2 3 4 5

Pow

er (

W)

Bit rate (Mb/s)

240p720p

480p

960p

Wi-Fi

180p360p

(b)

Linear Model

Measurement

Figure 5.6: Power consumption as a function of bit rate of a network IP camera with (a)Ethernet access and (b) Wi-Fi access.

The plot of power consumption as a function of bit rate is given in Figure 5.6(a) and

(b) for Ethernet and Wi-Fi access respectively. These figures demonstrate the net result of

employing an increasing coding effort with consequential energy cost to achieve lower

bit rate and thus achieving reduced energy cost for transmission. A similar linear charac-

teristic was observed with slight slopes for higher frame sizes, while the slopes of lower

frame sizes were substantially flat. This difference can be ascribed to the Foscam al-

ways employing a minimal level of encoding. For example, from the figure, a 240p video

stream at 25 f/s and 2 sec key frame interval requires no more than 1.2 Mb/s.

116 Energy-Efficient Architecture for IoT Video Surveillance Services

The equations of linear best-fit for each curve in Figure 5.6 are given in Table 5.4, using

the format br +mrz for a bit rate of z b/s, where br and mr are the baseline and incremen-

tal energy per bit respectively. Whereas the tests of power consumption against frame

rate, which showed a common baseline value among the frame sizes (Figure 5.4), these

results show a distinct difference in baseline consumption for different frame sizes. This

difference is mainly due to the additional power required for encoding at higher frame

sizes. The slopes for each of the traces, representing the incremental energy consumption

per bit, are also relatively consistent.

Table 5.4: Line of best-fit equations for power consumption as a function of bit rate of theIPcam, where z is the bit rate.

Frame Power (Watts)Size Ethernet Wi-Fi180p 3.09 + 6.1× 10−9z 3.53 + 6.6× 10−9z

240p 3.10 + 5.1× 10−9z 3.54 + 13.2× 10−9z

360p 3.11 + 5.2× 10−9z 3.56 + 10.7× 10−9z

480p 3.13 + 6.2× 10−9z 3.58 + 9.4× 10−9z

720p 3.17 + 5.1× 10−9z 3.60 + 14.7× 10−9z

960p 3.20 + 6.1× 10−9z 3.64 + 13.4× 10−9z

5.4.3 Power Consumption Model for an IP Camera

To model the power consumption of an IPcam, refer to Figure 5.1 which shows the cam-

era consisting of 3 main subsystems: the CSU, the IPU and the web server. The IPcam’s

power consumption, P , can be expressed as a sum of the power draw of these subsys-

tems, given as:

P = Pcsu + Pipu + Psrv (5.1)

where Pcsu, Pipu and Psrv represent the power consumed by the camera sensor unit, the

image processing unit and the web server respectively.

Studies have shown that the CSU, IPU (including the video encoder) and web server

exhibit power consumption to pixel rate, frame rate or bit rate relationships that can

be represented by a load-independent component and a load-proportional component

5.4 Experimental Parameters and Measurements 117

[149–151]. This behaviour is consistent with the measurements given in section 5.4.2.

Given that there are no ways to separate the power of Pcsu, Pipu and Psrv from external

measurements, we can therefore bring together their load-independent components and

their load-proportional components and rewrite (5.1) for a given time t as:

P (t) = Pidle +(EpQ

)f + EbR(t) (5.2)

where Pidle is the sum of the components of the camera power consumption that are

independent of the video parameters pixel rate, frame rate, and output bit rate, Ep is the

energy per pixel processed and Eb, the energy per bit, while Q and R are the number

of pixels per frame and video bit rate respectively. This equation is consistent with the

result presented in Tables 5.3 and 5.4 for an IPcam streaming video at f frames per second

with a bit rate R.

5.4.4 Traffic Measurements (Abit)

To measure the traffic volume,Abit (in bits), between the IPcam’s web-server and a client’s

web-browser, the packet sniffing tool (Wireshark in ”promiscuous mode”) was used to

record end-to-end traffic flows. Using the frame size : bit rate configuration combination

given in Table 5.2 at 25 f/s and a 2 sec key frame interval, live video streams (including a

128 kb/s audio stream) of a target scene were initiated and the resultant data traffic flow

recorded for 1 minute.

In a second experiment the camera was equipped with a 16 GB SD card storage and

the live stream recorded on the card for 1 minute, creating an Audio Video Interleave

(AVI) video file. Each session was repeated 5 times and the mean traffic volume and file

sizes calculated.

Figure 5.7(a) shows the measured traffic volume plotted against video file sizes for

a 1 minute video stream. The video file sizes range from 3 MB to 28 MB while the cor-

responding bit stream traffic volume was ≈ 1 MB higher on average, attributed to ACK

packets, framing (e.g. IP and Ethernet header), retransmission, and network/link man-

agement messages. Figure 5.7(b) and (c) show the measured traffic volume and bit rates

118 Energy-Efficient Architecture for IoT Video Surveillance Services

0

5

10

15

20

25

30

0 10 20 30

Mea

sure

d T

raff

ic V

olu

me

(MB

)

Video File Size (MB)

Upstream Traffic

Downstream Traffic

Total Traffic

(a)

0

5

10

15

20

25

30

180p 240p 480p 720p 960pM

easu

red

Tra

ffic

Vo

lum

e (M

B)

Frame Size

Upstream Traffic

Downstream Traffic

Total Traffic

(b)

0

1

2

3

4

5

180p 240p 480p 720p 960p

Bit

Rat

e (M

b/s

)

Frame Size

Upstream Bit Rate

Downstream Bit Rate

TotalBit Rate

(c)

0

5

10

15

20

25

30

35

180p 240p 480p 720p 960p

Nu

mb

er o

f D

ata

Pack

ets

('0

00

)

Frame Size

Upstream Packets

Downstream Packets

Total Packets

(d)

Figure 5.7: Measured traffic volume generated by the IPcam during live streaming exper-iment with frame rate of 25 f/s and key frame interval of 2 sec, plotted against (a) video filesizes and (b) video frame sizes. Bottom left and right: (c) Bit rate (Mb/s) and (d) Numberof IP packets, plotted against video frame sizes.

for the studied frame sizes (180p to 960p), while (d) depicts the packet distribution for the

traffic flow. On close examination of the Wireshark logs, the upstream traffic consisted

of mostly 1514 bytes TCP packets shortly followed by 54 bytes ACK downstream pack-

ets. The upstream/downstream packet ratio approached parity for lower frame sizes but

rapidly increases with increase in frame size (e.g. > 2 for 960p).

5.5 IoT Video Surveillance Network Architecture 119

5.5 IoT Video Surveillance Network Architecture

An example equipment-level network architecture for IoT video surveillance services is

as depicted by the upper half of Figure 5.8. Typical network architecture consists of 4

main segments: the access network, the metro/edge network, the core network and a

data centre for storage and processing [41, 94]. The IoT Device Network (IDN) - shown

Access Network

OLTEthernetSwitch

BNG

BNG

Edge Router

Edge Router

Core Router

Core Router

Core Router

Edge Router

Metro & Edge Network Core Network Cloud Data Centre

Server

Core Router

Edge Data Centre

Server

Storage

IDNs

Storage

EthernetSwitch

EthernetSwitch

ONU

ONU

ONU

HGW

HGW

HGW

HGW

IoT Device Network (IDN)

Figure 5.8: An example network architecture (with PON) of an IoT video surveillanceservice spanning from the IP camera to data storage centres.

in the breakout diagram below the main figure - may contain many IoT devices but the

focus here is the IPcam, which includes an IoT device and IoT gateway as one unit (see

Figure 5.1). For the access network, a Fibre-to-the-Premises (FTTP) architecture using

Passive Optical Network (PON) technology, which has been shown in [42] to be the most

energy efficient access network technology, is adopted. Hence, network access to the IP-

cam is facilitated via a HGW (Ethernet or Wi-Fi) and an Optical Network Unit (ONU),

both usually located within the customer’s premises, which ends at the broken line. With

PON access network, a single fibre from the Optical Line Terminal (OLT) feeds a num-

ber of subscriber (32/64 are common) ONUs via an optical splitter (i.e. the black dot)

[89]. The metro/edge network includes an Ethernet aggregation switch which combines

traffic from many subscribers while the Border Network Gateway (BNG) acts as the gate

keeper, providing authentication and authorisation services. Edge routers within the

metro/edge network segment represent the gateway to the global Internet. The core net-

120 Energy-Efficient Architecture for IoT Video Surveillance Services

work consists of several large routers, generally located in major population centres, plus

optical transmission systems linking those centres. The Cloud Data Center (cDC) is usu-

ally in a centralised location and consists of storage, servers, aggregation switches and

edge routers, the latter linking the cDC to the core network.

Data storage and processing facilities to the left of cDC in Figure 5.8 are generally

considered a part of fog computing [68]. The lower half of Figure 5.8 represents an Edge

Data Center (eDC) akin to Content Delivery Network (CDN) infrastructure [68,152]. The

eDC is modelled using equipment employed by CDNs. Local storage is represented by

the SD card attached to the IPcam.

5.6 Network Energy Consumption Modelling

A description of the modelling approach employed in this study and subsequent energy

consumption models applied in characterising network equipment depicted in Figure 5.8

is detailed in this section. Specifications for representative commercial network equip-

ment gathered from manufacturer datasheets and other resources in the public domain

(e.g. published papers) are used in the models.

5.6.1 Modelling Approach

In modelling the energy consumption of a network segment and its elements, a common

”bottom-up” approach is to characterise energy consumption of each network element

based on its number of users (i.e. a ”per user” model) [40–42]. Another useful approach

allocates energy consumption as a function of application traffic flows (i.e. a ”capacity-

based” model) through the network element [69, 70]. The latter approach is adopted in

this study for two main reasons:

(i) Video surveillance applications are data intensive, generating many traffic flows

and potentially accounting for a notable proportion of global Internet traffic [28, 58,

153].

(ii) It allows for the apportionment of energy consumption of all network elements in

5.6 Network Energy Consumption Modelling 121

the network (regardless of size, capacity or energy consumption), across each of the

services that use the network element.

5.6.2 Energy Model

For live video streaming, the IPcam must be ”always on”. Since live streaming is es-

sentially the primary function of the IPcam, its full power draw is accounted for in the

energy model. Considering an IPcam streaming from time t1 to t2. Given its power con-

sumption P (t), as expressed in equation (5.2), the energy consumption of the IPcam Ecam

can be expressed as:

Ecam =

∫ t2

t1

P (t)dt (5.3)

Network elements such as routers and switches shown in Figure 5.8 exhibit a linear

power-to-load relationship as discussed in Chapter 2 and corroborated by many studies

[95, 96, 151]. This relationship is expressed as P (R) = Pidle + EincR, where Pidle (which

can be > 90% of max power [95, 96]) is the no-load power component, and EincR, the

incremental power component for a bit rate R. Einc is the incremental energy per bit

given as: (Pmax−Pidle)/Rmax, where Pmax and Rmax are the maximum power consump-

tion and bit rate respectively. In addition to the traffic dependent power consumption

EincR, the ”capacity-based” modelling approach [70] apportions the device idle power

consumption across its traffic streams, using the expression Pidle/URmax, where U = av-

erage utilisation. Therefore, the average energy per bit, λ, of a network element is given

as:

λ =PidleURmax

+ Einc (5.4)

Many services concurrently access network elements at any given time. Given a ser-

vice that generates, transmits and/or receives a total traffic volume of Abit (in bits) across

the network, the additional energy consumption of a network element n, attributable to

such service (En) is given as:

En =

(PidleURmax

+ Einc

)Abit = λAbit (5.5)

122 Energy-Efficient Architecture for IoT Video Surveillance Services

Storage device energy consumption can be modelled as a function of the volume of

data stored over a period of time. For large storage facilities like DCs, data is often stored

on shared spinning disks that are accessible to many users/services through server re-

quests. Similar to some network elements, the power consumption of storage devices

contains an idle component (due to spinning disks) and a dynamic/incremental compo-

nent due to data input/output (IO) operations. In modelling a shared storage device, a

power per bit approach, which allocates the idle power consumption across the total data

volume stored, in addition to the incremental power for data IO, is adopted.

Consider a storage device with an idle power consumption Pidle and a maximum

power consumption and storage capacity Pmax and Bmax (in bits) respectively. Assum-

ing an average utilisation Us, the energy consumption (Es) attributable to a service with

stored video file(s) of size Abit, for a duration ts (in sec) can be expressed as:

Es =

(Pidle × tsUsBmax

+ Einc,s

)Abit (5.6)

where Einc,s is the incremental energy per bit for data IO operations.

For ts ≫ UsBmaxEinc,s/Pidle, then Pidlets/UsBmax + Einc,s ≈ Pidlets/UsBmax. Therefore

(5.6) can be written as:

Es ≈ µtsAbit (5.7)

where µ represents the average power per bit of the storage device, given by µ = Pidle/UsBmax.

5.6.3 Network Equipment Modelling

A selection of the representative network equipment applied in characterising the differ-

ent network architectures, modelling techniques and assumptions is presented below.

Customer Premises Equipment

The customer premises equipment (CPE) refers to energy consuming network devices

within a subscriber’s premises, that are a part of the network architecture being mod-

5.6 Network Energy Consumption Modelling 123

elled. They include the IPcam, home gateways and the ONU.

A) IP Camera: Applying equation (5.2) for a configuration of 720p (1280×720) pixels at

25 f/s (2 sec key frame interval) and 2 Mb/s video bit rate, the IPcam power draw P is

calculated as 3.18 W and 3.62 W for Ethernet and Wi-Fi network access. For a one minute

live video streaming, the energy consumption contribution of the IPcam is calculated

using (5.3) as 191 J and 217 J respectively. Wi-Fi network access is used in the calculations

below.

Table 5.5: Energy per bit of network equipment in the transport network.

Network ElementMax Capacity Idle Max Energy

Model [DL/UL]* Power Power per bit(Gb/s) (Watts) (Watts) (nJ/bit)

Wi-Fi Gateway EUCoC [124] 0.15 3.5 6.2 484.7ONU EUCoC [124] 2.4/1.2 3.2 4 27/54OLT Tellabs 1134 [154] 12 400 480 173.3

Ethernet Switch Cisco Catalyst 6905 [70] 256 1589 1766 13.1BNG Cisco ASR 9010 [70] 320 1701 1890 11.2

Edge Router Cisco 7609 [70] 560 4095 4550 15.4Core Router Cisco CRS-3 [70] 4480 11070 12300 5.2

* DL/UL: downlink and uplink

B) Home Gateway (HGW): As discussed in section 5.6.1, the HGW is modelled using (5.4).

A specification for a Wi-Fi router (Dual-band, 802.11n) is sourced from the European Union

Code of Conduct on Energy Consumption for Broadband Equipment [124], referred to in short

as EUCoC, as given in Table 5.5. The HGW serves as a host of other user applications and

services (e.g. YouTube, VoD, Skype, VoIP) with variable bit rates, but its average bit rate

can be considered low, relative to bit rates provided by a FTTP connection (0.1 - 1 Gb/s).

For example, a consumer data volume usage of 1000 GB per calendar month (30 days)

has an average daily bit rate of 3 Mb/s, which is 3% of a 100 Mb/s or 6% of a 50 Mb/s

FTTP connection. An average utilisation of 5% is assumed.

C) Optical Network Unit (ONU): Consider a GPON access network, which provides a

shared bit rate of 2.4 Gb/s downstream and 1.2 Gb/s upstream from the OLT to the

ONUs. Since a video surveillance system is mostly upstream driven, assuming a total of

124 Energy-Efficient Architecture for IoT Video Surveillance Services

32 customers sharing a single fibre-optic line to the OLT, each customer under full load-

ing conditions will have an upstream bit rate of ≈ 38 Mb/s. We therefore assume an

average utilisation of 5% and calculate the energy per bit for the ONU with (5.4). The

ONU’s specification is obtained from the EUCoC [124] and is listed in Table 5.5.

Access Network

For a GPON access network as described above, the access network segment terminates

at the Optical Line Terminal (OLT), which is located at the central office. The ONU and

OLT provide the transmission energy for the optical link between them. Tellab’s 1134

OLT [154] is used in the access network modelling with specification as detailed in Table

5.5. An average utilisation of 20% is assumed for the OLT [51].

Metro/Edge and Core Network

The metro/edge and core network equipment are modelled using data sourced from [70].

Specifications (idle/max. power and capacity) for the Ethernet aggregation switch, BNG,

edge and core routers are as listed in Table 5.5. Assuming a utilisation of 50%, the energy

per bit (in nJ/bit) is calculated using (5.4), and given in the last column of Table 5.5. Using

traceroute to ascertain the path between an IPcam and its parent service cDC servers, it

was observed that the bit stream traverses multiple edge and core routers. Therefore the

energy consumed by the metro/edge and core network segments depends on the number

of hops. This will be a factor in the estimates calculated below.

Cloud Data Centre (cDC)

Modelling cDC is a non-trivial exercise due to the lack of publicly available, detailed

information on the energy consumption of cDCs [including servers, routers, Ethernet

switches and overhead (e.g. cooling and power conversion)]. However, some cloud ser-

vice providers (e.g. Google, Facebook) publish the carbon intensity of certain services,

from which an average energy intensity of data transmission for a service can be inferred.

To account for uncertainty in these estimates, an approach with a range of values having

5.6 Network Energy Consumption Modelling 125

an upper bound and lower bound is adopted. The values referenced here are attributed

to the servers and attached network infrastructure of the cDC. For the upper bound, an

estimate of the energy per bit of Google’s YouTube servers, reportedly consuming 0.2 Wh

per 60 sec video, assuming an average bit rate of 0.9 Mb/s, is calculated as 13.3 µJ/bit

[155]. Obtained from the study in [69], the value for the lower bound energy per bit is an

estimate of Amazon’s DC given as 4 µJ/bit. It is assumed that a factor for redundancy is

already factored into these estimates.

The Power Usage Effectiveness (PUE) for cDC is assumed to be 1.2, a value stipulated

as the best practice for a highly energy efficient DC by the EU code of conduct for data

centres [156]. A few recent cDC facilities have reported PUE of 1.2 or less [156].

Data storage in a cDC (cloud storage) is facilitated by storage area network equipment

which includes hard disk drive arrays, drive enclosures, node controllers, fibre channel

adapters and redundant power supplies. Specification for the storage device used to

model a cloud storage device is given in Table 5.6. Considering a 3120 TB capacity cloud

storage device with a utilisation of 50%, the power per bit stored is calculated (see 5.7) as

0.89 pW/bit.

Table 5.6: Power consumption of storage devices.

DeviceStorage Power Power

Device Model Capacity (Watts) per bit [µ](TB) idle Max (pW/bit)

SD Card Patriot microSDHC [157] 16 GB 0.07 - -Edge Storage HPE 3PAR StoreServ 7000 [158] 672 2913 3520 1.04

Cloud Storage HPE 3PAR StoreServ 10000 [159] 3120 11118 13016 0.89

Edge Data Centre (eDC)

Bringing the content source closer to the user edge (i.e. fog computing) involves pro-

visioning what are described as ”fog nodes” or eDC, which can be edge routers (with

attached storage), servers, modems or gateway devices [67, 68]. An eDC can be readily

co-located within an ISP’s facility, adopting a similar architecture employed by CDNs at

the edge network. In this model, it is assumed that the eDC is populated with servers

and network equipment akin to that of a well-known CDN provider, Akamai [160]. Us-

126 Energy-Efficient Architecture for IoT Video Surveillance Services

ing Akamai’s quarterly reported carbon intensity for bandwidth, the study in [155] cal-

culated its energy per bit for data traffic as 0.89 nJ/bit. This value is assumed to include

a factor for redundancy.

For the eDC, a PUE of 1.8 is assumed; this value is closer to the average PUE of typical

facilities today [156,161]. The difference in PUE values between cDC and eDC is owing to

notion that newer cDC facilities are much more likely to be energy efficient (lower PUE)

than a central office or ISP facilities for example.

In modelling edge storage for the eDC, similar equipment used for cloud storage is

employed but of a smaller scale. Given the equipment specifications in Table 5.6, with

an assumed utilisation of 50%, the power per bit stored for an edge storage device is

calculated as 1.04 pW/bit.

5.7 Modelling IoT Live Video Streaming Architectures

With live video streaming, real-time video frames emanating from the IPcam are trans-

mitted directly to an end-user’s device without being stored. The energy consumed by

this service is therefore dependent on the IPcam, transport network (access, edge, core

networks), DCs (for some applications) and the end-user device on which video frames

are rendered. The last is not considered in this analysis as the focus is on the service

network architecture. Three models of IoT live video streaming can be considered; (i)

Direct Live Streaming (also known as HTTP/RTSP Streaming) (ii) Cloud Streaming and

(iii) Edge Streaming. The last two may interchangeably utilise HTTP or FTP protocols.

5.7.1 Direct Live Streaming

Direct live streaming is intuitively the default option when considering real-time video

streaming. Two possible user types are modelled; (i) Local User and (ii) Remote User.

(i) Local User (LU): This refers to a user within the same LAN accessing live streams from

the IPcam via the HGW. An example of such usage is the baby monitor application. Over

5.7 Modelling IoT Live Video Streaming Architectures 127

a time interval t the total energy consumed by a live (l) streaming service when accessed

by a local user (E(l)LU) is given as:

E(l)LU = Ecam +NuλhgwAbit (5.8)

whereNu is the number of concurrent users accessing live video streams from the IPcam,

λhgw is the energy per bit of the HGW,Abit is the total bits per exchange (upload) over the

interval, andEcam is the total energy consumed by the IPcam over the interval, calculated

using (5.2) and (5.3).

(ii) Remote User (RU): This refers to a user accessing direct live video streaming service

from the same or a different Autonomous System (AS), outside the IPcam’s LAN. The

latter is modelled here noting that only a small energy contribution from the core network

is missing from cases where the RU is close to the source (e.g. same ISP).

Since the data source is at the user premises, the video stream flows through the

access and edge networks twice. Two RU types can be defined; one in which the IPcam

and RU are within the same geographical region (e.g. same city/country) referred to as

RU-local, and the other in which they are in different geographical regions, RU-global. For

RU-local, the video data transits through its parent ISP’s access and edge networks, and

at least one core router (i.e. Hcn = 1), then through the edge and access networks again

to the destination user device. For RU-global, the traffic traverses multiple core network

elements in addition to the edge and access networks. The total energy consumed by a

live streaming service when accessed by a remote user (E(l)RU) can be expressed as:

E(l)RU = Ecam + 2

[λacc + ησn

(λes + λbng +Henλer +

Hcnλcr

2

)]NuAbit

= Ecam +(2λTPe +Hcnησnλcr

)NuAbit (5.9)

where λacc, λes, λbng, λer, λcr represent the energy per bit of the access network, Ether-

net switch, BNG, edge router and core router respectively; the factor of 2 in the second

term represents the number of times video data traverses the access and edge network

128 Energy-Efficient Architecture for IoT Video Surveillance Services

segments; η is a factor for redundancy, assumed to be 2, and σn, a factor for cooling and

power conversion overhead for the transport network equipment - akin to PUE of a DC

- assumed to be 1.8 [161]. Hen and Hcn are the number of hops/routers traversed in the

edge and core networks. Hcn = 1 for RU-local andHcn = 12 (from traceroute - discussed in

section 5.7.2) for RU-global. λTPe is the combined energy per bit of the transport network,

up to the edge, given by:

λTPe = λacc + ησn(λes + λbng +Henλer

)(5.10)

For the access network, λacc = λhgw + λonu + σnλolt, where λhgw, λonu, λolt are the energy

per bit of the HGW, ONU and OLT respectively. The HGW and ONU are self-cooled (no

cooling/overhead factor). All defined parameters in this section are listed in Table 5.7.

Table 5.7: Descriptions of parameters defined in the energy models.

Parameter DescriptionEcam Energy consumption of the IPcam streaming for duration t in secondsλhgw Energy per bit of the home gateway deviceλonu Energy per bit of the access network optical network unitλolt Energy per bit of the access network optical network terminalλes Energy per bit of the metro-grade Ethernet switchλbng Energy per bit of the border network gatewayλer Energy per bit of the edge routerλcr Energy per bit of the core routerλTPe Combined energy per bit of the transport network up to the edgeλTPc Combined energy per bit of the transport network up to the coreλeDC Total energy per bit of a edge data centreλcDC Total energy per bit of an cloud data centreNu Number of users streaming live video from the IPcamHen Number of hops/routers traversed in the edge networkHcn Number of hops/routers traversed in the core networkη factor for network redundancy or protectionσn Overhead factor for cooling and power conversion of network equipmentσe PUE of an edge data centreσc PUE of a cloud data centreAbit Total exchanged bits between the IPcam and a user device

5.7.2 Cloud Live Streaming

For cloud live streaming, the live video data is transmitted to the centralised cDC before

being routed to the user device, often with a some delay [68]. This model is conventional

5.7 Modelling IoT Live Video Streaming Architectures 129

for many IoT video streaming services today predicated on safe, worldwide accessible

storage of 24/7 video footage, captured by an IPcam. The energy consumed by a cloud

live streaming service is dependent on the energy consumed by the cDC server in addi-

tion to that of the transport network and the IPcam. Video data traverses the end-to-end

transport network twice (factor of 2). Therefore, the total energy consumption of a live

streaming service that is routed via a cDC (E(l)cloud) is given as:

E(l)cloud = Ecam + 2

[λacc + ησn

(λes + λbng +Henλer +Hcnλcr

)+σcλcDC

2

]NuAbit

= Ecam +(2λTPc + σcλcDC

)NuAbit (5.11)

where λcDC represent the energy per bit of the cDC server and its attached network ar-

chitecture, σc is the PUE of a cDC and λTPc , the combined energy per bit of the transport

network up to the core, given by:

λTPc = λacc + ησn(λes + λbng +Henλer +Hcnλcr

)(5.12)

Measurements using Foscam’s cloud services showed that its live streaming feature em-

ploys a direct HTTP streaming architecture with a delay 6 1 sec. With a third-party cloud

service (camCloud), however, the measurements revealed that video data is routed via a

cDC using FTP, with delay ≈ 8 - 13 sec. Both services use Amazon’s EC2 servers from a

similar DC location in the United States. To determine the path of video streams to the

cDC, the popular utility traceroute was employed from an end-user device to the desig-

nated servers. Both cloud services had similar edge and core network hop counts (i.e.

Hen ≈ 1, Hcn ≈ 12) but total hops between 23 and 28 - the difference attributed to ad-

ditional hops within Amazon’s AS. These values for number of hops (Hen and Hcn) are

used throughout this work.

130 Energy-Efficient Architecture for IoT Video Surveillance Services

5.7.3 Edge Live Streaming

With edge live streaming, video data is assumed to be streamed to an eDC closer to the

user before being re-routed to end-user device. Similar to direct and cloud streaming,

the live video stream passes through the access and edge network segments twice (factor

of 2). It is further assumed that most end-users access video streams within the same

geographical region [162], avoiding the need for routing across the core network. The

total energy consumed, E(l)edge, by service for live streaming via the eDC is expressed as:

E(l)edge = Ecam +

(2λTPe + σeλeDC

)NuAbit (5.13)

where λeDC is the energy per bit of the eDC, σe is the PUE of the eDC and λTPe , the

combined energy per bit of the transport network for an edge DC architecture.

Video File Size (MB)0 5 10 15 20 25 30

Ene

rgy

Con

sum

ptio

n (J

oule

s)

0

500

1000

1500

2000

2500

Direct (LU)

Direct (RU-local)

Edge

Direct (RU-global)

Cloud (Low)

Cloud (High)

Figure 5.9: Energy consumption of network architectures for a live video streaming ser-vice.

5.7 Modelling IoT Live Video Streaming Architectures 131

5.7.4 Evaluation

For this analysis, consider a single user scenario (Nu = 1) and an IPcam configured with

different frame sizes (180p to 960p), live streaming at 25 f/s (2 sec key frame interval) for

1 minute (t = 60 sec). The corresponding video traffic volume (Abit) is shown in Fig-

ure 5.7(a). The energy per bit and power per bit values for the network equipment are

taken from Tables 5.5 and 5.6 respectively, and the number of hops in the edge and core

networks areHen = 1 andHcn = 12.

Figure 5.9 shows a plot of the energy consumption of direct (LU and RU), edge and

cloud (lower and upper bound) live streaming architectures, as a function of video traffic

volume (0 - 30 MB). The values plotted include energy consumed by the IPcam, the trans-

port network and in some cases the DC servers and their attached network infrastructure

as described by equations (5.8) to (5.13). The plots scale linearly with higher video traffic

volumes.

From Figure 5.9, it is clear that live video streaming via cloud servers consumes the

greatest amount of energy, while the absence of the transport network energy in direct

streaming for a local user i.e. Direct (LU) ensures the least energy usage. An edge-

based architecture is more energy efficient than a cloud-based architecture but less energy

efficient than direct access. Evidently, the energy cost of routing live streams via a DC is

the underlying differentiator, given that there is no significant difference in the energy

cost for data transport among the three. At Abit = 0 (i.e. y-axis), the energy consump-

tion is only attributed to the IPcam. It is very likely that most live streaming requests

will come from outside the home LAN. Hence the figure indicates that it is more energy

efficient to access direct live streaming from the IPcam, avoiding additional energy cost

of DC servers. Since storage of video data at a DC is optional for video surveillance

services, adopting an architecture that always routes live video streams through a DC is

energy costly and inefficient when storage of the video footage is not required.

A breakdown of the energy consumption by the individual segments composing the

various network architectures is given in Figure 5.10.

132 Energy-Efficient Architecture for IoT Video Surveillance Services

Video File Sizes (MB)0 5 10 15 20 25 30

Ene

rgy

Con

sum

ptio

n (J

oule

s)

0

500

1000

1500

2000

2500

IPcamAccess Network

Edge & Core Network

eDC

cDC (Low)

cDC (High)

Figure 5.10: Energy contributions of the different network segments in a live streamingnetwork architecture.

5.8 Modelling IoT On-Demand Video Streaming Architectures

With IoT on-demand video streaming, the real-time video streams are recorded to storage

devices as video files, from where they can be accessed or downloaded on-demand at

any time. Therefore, IoT on-demand video streaming models include storage energy in

addition to the IPcam, transport and DC energy consumption. Three sources of video file

storage (i.e. SD card, edge and cloud storage) associated with the three on-demand video

streaming architectures: (direct, edge and cloud streaming) are analysed.

5.8.1 Energy Consumption of IPcam for On-Demand Streaming

In section 5.7, for a live streaming architecture, the energy consumption of the IPcam

(with no SD card) was calculated using its full power (baseline and incremental) con-

sumption. For on-demand streaming, however, the optional SD card is required. Fur-

thermore, on-demand streaming functionality operates independently of the IPcam’s pri-

5.8 Modelling IoT On-Demand Video Streaming Architectures 133

mary live streaming function. Hence, in this model, only the additional power consump-

tion when the SD card is installed (baseline and incremental) is considered in calculating

the IPcam’s energy consumption.

3.40

3.50

3.60

3.70

3.80

0 20 40 60 80

Pow

er C

onsu

mpti

on (

Wat

ts)

Time (sec)

Baseline power

Start

(t1)

Wi-Fi

End

(t2)

Baseline + Encoder (load) + SD Card

Baseline + Encoder (load)

PSD

δPcam

Figure 5.11: Power consumption of IPcam with attached SD card when streaming a 1minute video file on-demand.

To determine the IPcam incremental energy consumption for on-demand streaming,

the measurement setup described in section 5.4.1 is adopted. Figure 5.11 shows an exam-

ple of the measured power consumption of the Wi-Fi-connected IPcam when streaming

a 16.1 MB recorded one minute video file (1280 x 720 pixel, 25 f/s, 2 sec key frame interval)

from the SD card to a PC web browser. Figure 5.11 is a plot of power consumption as

a function of time (blue curve), and displays the average baseline power with light en-

coder load (lowest pixel rate format), the baseline plus high encoder (load) power (high

pixel rate format) with and without the SD card attached. The difference between the

latter two values (PSD ≈ 70 mW as given in Table 5.6) gives the baseline power of the SD

card which is attributed to the energy for storage. The encoder (load) is an indication of

the additional power consumed when the IPcam is configured for higher pixel rates (e.g.

134 Energy-Efficient Architecture for IoT Video Surveillance Services

720p from Table 5.2 in this case). The blue curve in Figure 5.11 shows the start (t1) and

end (t2) points of the streaming process.

The incremental energy consumption of an IPcam for the on-demand streaming pro-

cess, Ecam(inc), contains two components: one for storage and the other for streaming,

expressed as:

Ecam(inc) = ESD +NdEcam(str) (5.14)

where ESD is the storage energy given by PSDts, with ts being the length of time (in sec)

the video file is stored; Nd is the number of times the video is downloaded; Ecam(str) is

the energy consumed for streaming the video file, which is the integral (from t1 to t2) of

the difference between the blue curve and the line representing the baseline power for the

IPCam with encoder (load) and SD card (δPcam(t)) that is immediately below the curve.

For the 1 minute video file considered above, Ecam(str) is calculated as ≈ 3 joules.

5.8.2 Direct On-Demand Streaming

With direct on-demand video streaming, users can access video files that were previ-

ously recorded and stored on the SD Card attached to the IPcam. Since the source of

video streams is the same as with live streaming, a similar architecture applies. The total

energy consumption for a LU and RU (E(od)LU and E

(od)RU ) accessing direct on-demand (od)

streaming for Nd times within a time period ts is expressed as:

E(od)LU = ESD +Nd

(Ecam(str) + λhgwAbit

)(5.15)

E(od)RU = ESD +Nd

[Ecam(str) +

(2λTPe +Hcnησnλcr

)Abit

](5.16)

whereHcn = 1 for RU-local andHcn = 12 for RU-global.

5.8 Modelling IoT On-Demand Video Streaming Architectures 135

5.8.3 Edge & Cloud On-Demand Streaming

As with the previous on-demand architectures, streaming via edge and cloud services

incurs additional energy for DC storage of video files. The total energy consumption of

an on-demand video streaming service that is accessed from an eDC and cDC, E(od)edge and

E(od)cloud are given as:

E(od)edge =

[(Nd + 1

)(λTPe + σeλeDC

)+NR

(ησeµets

)]Abit (5.17)

E(od)cloud =

[(Nd + 1

)(λTPc + σcλcDC

)+NR

(ησcµcts

)]Abit (5.18)

where NR represents the number of edge or cloud DCs with stored replicas of the video

file of size Abit; µe and µc are the power per bit for edge and cloud storage devices. The

factor (Nd + 1) indicates that the video file must first be uploaded to a DC before it can

be streamed Nd times. λTPc and λTPc represents the per-bit transport energy to reach an

edge and cloud DC respectively, defined by equation (5.10) and (5.12).

5.8.4 Evaluation

To evaluate and compare the energy efficiency of IoT on-demand video streaming archi-

tectures described and modelled in the preceding section, let us consider a 1280 x 720

pixel, 25 f/s, 16.1 MB video file (Abit = 128.8 Mbits) that is 1 minute in length. Energy-

per-bit values for the transport network and DCs, and power-per-bit values for storage

devices are sourced from Tables 5.5 and 5.6 respectively. The PUE of the cDC and eDC

(σc and σe) are taken as 1.2 and 1.8. It is assumed the video file was stored for 1 minute

(ts = 60 sec) for a short-term storage scenario and located at a single DC facility (NR = 1).

Figure 5.12 shows plots of energy consumption of direct (LU and RU), edge and cloud

(low and high) network architectures for IoT on-demand video streaming services, as a

function of video file sizes (in MB). As with the live streaming case, both high and low

136 Energy-Efficient Architecture for IoT Video Surveillance Services

Video File Size (MB)0 5 10 15 20 25 30

Ene

rgy

Con

sum

ptio

n (J

oule

s)

0

500

1000

1500

2000

2500

3000

Direct(RU-local)Direct

(RU-global)

Cloud (Low)

Cloud (High)

Edge

Direct (LU)

Figure 5.12: Energy consumption of network architectures for IoT on-demand videostreaming services.

estimates for a cloud architecture are far less energy efficient than edge and direct on-

demand streaming mainly due to the energy cost of cDC and cloud storage in addition

to the transport energy cost. An edge architecture is a more energy efficient option than

a cloud architecture but less efficient than direct streaming. Figure 5.12 also shows no

significant difference between a RU streaming stored video files from the IPcam (i.e. lo-

cal fog) within the same geographical location (RU-local) and that from a distant user

(RU-global). Overall, direct streaming from the IPcam is the most energy efficient archi-

tecture for on-demand streaming provided the gateway can handle the load. An edge

architecture could be considered the most energy optimal if data protection, redundancy

and reliability are paramount to the service.

Number of Downloads

To further investigate the influence of storage energy cost on the energy efficiency of a

given network architecture, let us consider a 10 minute long 1280 x 720 pixel, 25 f/s video

5.8 Modelling IoT On-Demand Video Streaming Architectures 137

file of size 161 MB. Consider that the file is uploaded and stored in the DCs for 1 calendar

month (30 days x 86400 sec/day), hence ts = 2.592× 106 sec.

Number of downloads per month10-1 100 101 102 103

Ene

rgy

Con

sum

ptio

n (J

oule

s)

104

105

106

107

Direct (LU)

Direct (RU-global)

Cloud (Low)

Cloud (High)

Edge

Direct(RU-local)

Figure 5.13: Energy consumption as a function of number of downloads per month foran on-demand video streaming service.

Figure 5.13 shows the energy consumption of network architectures as a function of

number of downloads per month for an IoT on-demand video surveillance service. The

plot shows that for few download per month, total energy consumption of cloud and

edge-based architectures is largely dominated by the storage energy, but significantly

increases with an increase in the number of downloads per month, mainly due to the

energy cost of data transport and the DC servers. The cost of local storage (SD card) is

about 10 times that of edge and cloud, which is shown to be a major factor for direct

on-demand streaming being a less energy efficient option in this case. While there is

no clear difference between direct (RU-local) and direct (RU-global), they can be seen

as being more energy efficient than cloud, only for higher numbers of downloads (>

35) per month; this arises as the higher local storage cost becomes offset by the higher

transport costs involved in the transport network to a distant DC. A total number of

138 Energy-Efficient Architecture for IoT Video Surveillance Services

downloads of 1000 per month (limit of Figure 5.13) is an average of 1.4 per hour which

is within the performance capacity of the IPcam or a similar IoT gateway device (e.g.

Raspberry Pi). From Figure 5.14, an edge architecture can be clearly seen as the most

energy efficient for less than about 300 downloads per month, beyond which there is

hardly a clear distinction between an edge architecture and that of a direct streaming

architecture.

Energy per Download

A useful energy efficiency metric used to assess network architectures of a service is its

energy per download. Using the same 10 minute long video file as in the previous sec-

tion, the per-download energy can be determined for each of the network architectures

considered. For a direct (LU and RU), edge and cloud on-demand streaming service, the

per-download (pd) energy consumption E(pd)LU , E(pd)

RU , E(pd)edge and E(pd)

cloud, is given by:

E(pd)LU =

(ESD

Nd+ Ecam(str)

)+ λhgwAbit (5.19)

E(pd)RU =

(ESD

Nd+ Ecam(str)

)+(2λTPe +Hcnησnλcr

)Abit (5.20)

E(pd)edge =

[λTPe + σe

(λeDC +

NR(ηµets

)Nd

)]Abit (5.21)

E(pd)cloud =

[λTPc + σc

(λcDC +

NR(ηµcts

)Nd

)]Abit (5.22)

where NR = 1 and Nd > 1. All other parameters are defined in Table 5.7.

Figure 5.14 shows plots of energy per download as a function of number of down-

loads per month for an IoT on-demand video surveillance service. The figure depicts

plots for direct, edge and cloud-based network architectures for a range of downloads

per month. Figure 5.14 shows that for almost the entire range of number of downloads

5.8 Modelling IoT On-Demand Video Streaming Architectures 139

Number of downloads per month10-1 100 101 102 103

Ene

rgy

per

dow

nloa

d (J

oule

s)

103

104

105

106

Direct(RU-local)

Edge

Cloud (Low)

Direct (LU)

Direct(RU-global)

Cloud (High)

Figure 5.14: Energy per download as a function of number of downloads for on-demandstreaming of a 10 minute video file from a storage device.

per month, the energy consumption of the service is minimised when an edge-based

network architecture is adopted. As seen in the previous analysis, there is no distinct

difference when stored files are either accessed by remote users within the same city

(RU-local) or half way around the world (RU-global). This is attributed to the highly-

shared and highly efficient network elements in the core network. The absence of the

transport energy consumption for direct (LU) architecture makes it the most efficient but

it is limited to access within the IPcam’s LAN.

Effect of Video File Replication in Data Centres

To further understand the effect of replicating files in a number of DCs, a study of the per-

download energy consumption for a range of DC replicas is conducted. Using equations

(5.20) to (5.22) for a 10 minute (161 MB) video file that is replicated NR times, where NR

= 2, 20, 200 and 2000. While it is unlikely to have 200 or 2000 surveillance video files, the

140 Energy-Efficient Architecture for IoT Video Surveillance Services

Number of downloads per month10-1 100 101 102 103 104 105

Ene

rgy

per

dow

nloa

d (J

oule

s)

103

104

105

106

Edge(N

R= 2)

Cloud(N

R= 2000)

Edge(N

R= 2000)

Cloud(N

R= 200)

Edge(N

R= 200)

Cloud(N

R= 20)

Edge(N

R= 20)

Cloud(N

R= 2)

Direct(RU-global)

Figure 5.15: Energy per download comparison for replicating a 10 minute video file in 2,20, 200 and 2000 cloud and edge data centres.

model is indicative of other applications (e.g. VoD) with such file volume.

The plots in Figure 5.15 show energy per download as a function of number of down-

loads for edge and cloud-based network architectures with NR replicas of the video file.

The figure also shows a plot for direct (RU-global) on-demand streaming. Generally, the

plots show that an increase in the number of times a video file is downloaded comes with

an increase in the transport energy consumption. The results indicate that for a video file

that is accessed a few times a month (< 5), it is more energy efficient to store and serve

such a file from a cDC (4 µJ/bit) while maintaining replicas in two DCs. For low to

medium number of accesses (< 300 download per month), the total energy consumption

of the service is minimised when served from an eDC with two DC replicas. However,

if the number of downloads is high (exceeding about 300 downloads per month), the

results suggest that the total energy consumption of the service can be minimised with

a direct (RU-global) access architecture. Overall the energy consumption of the service

is minimised when video files are stored in a lower number of DCs much closer to the

5.9 Application with Video Processing Load 141

users, either in a distributed edge network architecture for fewer accesses per month or a

gateway device located at the customer’s premises for much higher accesses per month.

5.9 Application with Video Processing Load

In the previous sections, an analysis of the energy implications of a video surveillance

system is presented through the lens of energy consumed for a video transmission load

and a video storage load. In this section, an investigation of an energy efficient architec-

ture including a video processing load is presented. A comparison of the energy required

for local processing as opposed to cloud and edge processing is given, using a face detec-

tion and recognition application. An example use-case scenario is a facial identification

system utilised for gaining access to a home or office space or a video surveillance cam-

era capable of identifying subjects. In the place of the IPcam, a Raspberry Pi Model 3

(RPi) [163] with its attached pi camera was used (i.e. IoT gateway and IoT device respec-

tively). Specification of the RPi is given in Table 5.8. The face detection and recognition

Table 5.8: Parameters of the Raspberry Pi 3 Model B with attached Pi Camera.

Parameter ValueCPU Quad Core 1.2 GHzRAM 1 GBStorage (Patriot SDHC Card) 16 GBPi Camera 5 MP, 1080p @ 30 f/sNetwork Access Ethernet/Wi-FiOS Version Linux 8 (jessie)

application was programmed and ”trained” to detect and recognise facial features (using

the Eigenfaces algorithm) of 5 unique persons. The features were extracted from 12 im-

ages for each person. Hence, a face database of 60 images with a file size of 13 MB was

deployed on the RPi.

142 Energy-Efficient Architecture for IoT Video Surveillance Services

5.9.1 Energy Consumption of Raspberry Pi

To determine the energy consumed by the RPi when executing a face recognition process,

the measurement set up described in section 5.4.1 with a PowerMate power meter was

used. Figure 5.16 shows an example of a plot of power consumption as a function of time

0

1

2

3

4

0 5 10 15 20 25 30

Pow

er C

onsu

mpti

on (

Wat

ts)

Time (sec)

Start

(t1)

End

(t2)

Idle Power

Raspberry Pi

Figure 5.16: Power consumption of a Raspberry Pi 3 as a function of time when detectingand recognising a single face from a video frame. Time elapsed between time t1 and t2 is≈ 4.5 seconds.

for the RPi while detecting and recognising a known face (1 out of the 5 persons) from a

video frame.

The sequence of events for the face recognition process is as follows:

(i) with a prepared measurement set up, the pi camera was positioned facing the indi-

vidual to be identified.

(ii) the face recognition application was initiated at time t1 as shown in Figure 5.16; the

pi camera goes through a warm-up process (for 1 sec) prior to commencing video

capture; a video frame was grabbed and analysed for a positive match using the

face database.

(iii) an output of the recognition process was given at time t2 after which the RPi returns

5.9 Application with Video Processing Load 143

to its idle mode.

In calculating the incremental energy consumption of the RPi for a video processing

application, equation (5.3) is employed for a duration t1 to t2. Although the recognition

process at its core needs no storage capacity, the face database which holds the images

and features of known individuals requires some storage. Hence, the model should ac-

count for storage energy.

Unlike the IPcam, the RPi’s SD card is not dedicated to data storage as it also hosts

the Linux operating system upon which the RPi is based. It is impractical to separate

the energy consumption attributed to storage as was the case in the model for the IP-

cam. Hence, the energy consumption for face database storage on the RPi (using the

same SD card) is assumed to be similar to that of the IPcam as outlined in section 5.8.1.

The incremental energy consumption of a RPi (Epi(inc)) in conducting Np number of face

recognition processing operations is given as:

Epi(inc) = ESD +NpEprc (5.23)

where Eprc is the incremental energy for video processing, obtained from Figure 5.16 by

taking the integral (from t1 to t2) of the difference between the curve and the broken line

representing the RPi idle power.

5.9.2 Evaluation

Detailed information on the energy consumption for specific applications such as video

processing in a DC are not readily available in the literature. Furthermore, modelling

such processes for a DC is non-trivial. Therefore, in evaluating an energy efficient net-

work architecture for a video processing application, a different approach is needed.

It can be considered more energy efficient to run a video processing application ser-

vice locally (e.g. on the RPi), rather than an eDC or cDC if the following inequalities are

satisfied:

(ESD +NpEprc

)<

[Np(λTPe + σeλeDC

)+ σeηµets

]Abit (5.24)

144 Energy-Efficient Architecture for IoT Video Surveillance Services

(ESD +NpEprc

)<

[Np(λTPc + σcλcDC

)+ σcηµcts

]Abit (5.25)

where Abit is the video data volume (in bits) and Np, the number of face recognition

processing operations. All other parameters are defined in Table 5.7.

From (5.24) and (5.25), the left-hand-side of the inequalities represents the energy

allocated to storage of a local face database on the SD card (ESD) and the incremental

energy for local video processing. Without a means of separating the storage energy

allocated to a relatively small face database (13 MB) from that of the RPi Linux OS (> 1.5

GB), this estimate can be considered an upper limit. From the right-hand-side (RHS) of

(5.24) and (5.25), the terms in round brackets include both the transport energy incurred

in sending the video frames to a DC, and the energy consumed in the DC in handling the

video frames. The RHS also include the storage energy for a face database in the DC. It is

assumed that the DC face database is 100 MB in size.

Number of face recognition operations per day100 101 102 103 104

Ene

rgy

Con

sum

ptio

n (J

oule

s)

102

103

104

105

106

107

Local (RPi)

Edge

Cloud (Low)

Cloud (High)

Figure 5.17: Energy consumption as a function of number of face recognition operationsprocessed per day.

5.10 Conclusions 145

To run a face recognition application at a DC, video data frames must first be trans-

mitted to the DC. Let us assume the minimum video data required is one-second long.

Given that the pi camera outputs video of 5 megapixel frames at 30 f/s, the traffic volume

for a one-second long video stream with H.264 compression is ≈12 MB [164] (Abit = 96

Mbits). Figure 5.17 shows plots of energy consumption per day as a function of number

of face recognition operations per day for a local, edge and cloud-based service.

The results show that for local video processing, the energy cost of storage dominates

the total energy consumption of the service. The transport energy cost to transfer each

operation’s video data to a DC for processing in addition to the storage energy for the

DC face database is lower for an eDC than that of a cDC. Modelling with a much larger

DC face database (up to 1 TB) yielded no significant difference in the results. The results

further indicate that, for a low number of recognition operations per day (< 25), it is more

energy efficient to transport and process video data at an edge facility. However, the cost

of transport to a DC facility outweighs the cost of local processing for medium to higher

number of operations per day. Therefore, for a home setting (low usage scenario), it might

be deemed more energy efficient to process video data in an eDC with the assurance of

scale for more processor-intensive workloads. However, it is almost always more energy

efficient to process video data locally if the gateway device is capable of handling the

workload. If a face is not recognised from the local database (e.g. an infrequent visitor),

it might need to be referred to the eDC or cDC anyway.

5.10 Conclusions

In this chapter, an assessment has been made of the energy consumption of local (fog),

edge (fog) and cloud-based network architectures for IoT video surveillance services,

when considering video streaming, storage and processing energy implications. Using

energy consumption models for network equipment, experiments and measurements

where applicable, representative examples of network elements and relevant use-case

scenarios (live streaming, on-demand streaming and video processing), a first order esti-

mate of the energy consumption of the 4 main network architectures was presented. The

146 Energy-Efficient Architecture for IoT Video Surveillance Services

estimates were used as an indication of the energy efficiency of these network architec-

tures for IoT services.

A model for the power consumption of a network IP camera (IPcam), which takes into

account video parameters such as frame rate, video bit rate and pixel rate was given. The

results show that the power consumption of a network IPcam is linearly proportional to

its video pixel rate, but with an idle power that is greater than 90% of the total power.

The model can be used for similar new generation network IPcams.

To assess, evaluate and compare the energy consumption of IoT live streaming, on-

demand streaming and video processing, energy models for their respective network

architectures were developed. The results indicate that for accessing live video from an

IoT video surveillance system, it is more energy efficient to use direct (local) access from

the IPcam. Live streaming via an eDC or cDC is less efficient with no substantive benefit.

When considering on-demand streaming, however, the energy cost of local storage in

the IPcam can be 10 times higher than in a DC. However, storing video data closer to

the user (eDC) does not only reduce round trip latency, it is also shown to be a more

energy efficient option for data intensive applications like video surveillance services

and processor-intensive applications like face detection and recognition on video.

Deployment of the services for Internet of Things is ramping up with cloud comput-

ing being the de-facto option for many. The results shown here gives a clear indication

that fog computing may not only improve network QoS metrics for data intensive IoT

applications, but they also show that it can potentially save energy. In addition, the use

of fog computing may stave off core network and cDC capacity increments in the future.

Chapter 6

Power Consumption of IoT AccessNetworks

6.1 Introduction

IN previous chapters, it has been established that the IoT involves the use of many

sensing devices, actuators or ”things” connected over the Internet to measure, report,

and in some cases perform actions autonomously. Many of the ”devices” - referred to as

IoT devices in this thesis - within the IoT eco-system may be sensors, for example report-

ing periodically on their environment, sending small data packets at regular intervals,

with low-level data streams. However, some of the IoT devices may be video cameras,

sending a higher volume of data continuously, for which the traffic requirements may be

substantial.

Access networks provide the initial points of connection between the IoT network

and the Internet or the Cloud, enabling end-to-end bi-directional connectivity for the IoT

ecosystem. Some studies on energy consumption of the Internet (including the access,

edge and core network segment) have indicated that the access network is the least en-

ergy efficient segment of the Internet [40, 41, 43]. However, these studies tend to focus

on higher data access rates (above 1 Mb/s). Many IoT services or use-cases (e.g Smart

Farming or Environmental Monitoring) may involve low traffic volume per connected

device, with far greater numbers of connected devices [2, 24], each with low data access

rate demands, often outside the range considered by previous studies. A good under-

147

148 Power Consumption of IoT Access Networks

standing of the energy consumption of access network technologies for low bandwidth

requirements (as in IoT use-cases) is therefore important in assisting the ICT industry to

reduce its carbon footprint [165, 166] in future network deployments.

In modelling large networks (e.g. the Internet), it is impractical to perform direct

power measurements. A more practical approach is a combination of modelling and

measurement (where applicable) to determine the power consumption of large networks

[40, 70]. It is important to note that different access technologies provide different per-

user bandwidth levels, and have dissimilar power usage. In this chapter, a number of ac-

cess network technologies and architectures that are appropriate to IoT applications are

considered, then the more power-efficient access technologies for the IoT over a range

of traffic levels are identified. Using a range of data sources (equipment manufactur-

ers’ datasheets, some measurements and previous literature), an evaluation of current

wireline and wireless network architectures is presented. The power consumption and

energy-efficiency of the various technologies are compared for low bit rates (sub-1 Mb/s).

In the model, IoT device data traffic and their required protocol and signalling overheads

- which can be substantial for small-packet data flows - are treated as a whole. The chap-

ter concludes with suggestions on energy-efficient access network choices for future IoT

installations.

6.2 IoT Access Network Architecture

This section describes a range of access network architecture options enabling IoT con-

nectivity. The architectures considered here are shown in Figure 6.1. Access networks

provide connection from users and end-devices at the network edge, through to the In-

ternet core. Today, there are a number of access network technologies with different

transmission media (i.e. optical, copper, free-space wireless), traffic capacity and levels

of aggregation. The access network could include one or more wireline and wireless net-

work access technologies. It is assumed that the access network carrying aggregated IoT

traffic would broadly be the same or similar to today’s access networks, but handling dif-

ferent traffic loads. Hence the energy consumption of different types of access network

6.2 IoT Access Network Architecture 149

IoT Gateway

Wi-Fi

Internet Edge & Core

Networks

Passive Splitter

LPWA Base Station

LTE Base Station

DSLAM / MSAN

CPE Edge Node (EN)Remote Node (RN)

ONU

OMC

Modem

Modem

OLT

Ethernet Switch

IoT Gateway

IoT Gateway

IoT Gateway

IoT Gateway(IGW)

BLEANT+

ZigBee

IoT Device Network (IDN)

IDN

IDN

IDN

IDN

BLEANT+

ZigBee

BLEANT+

ZigBee

BLEANT+

ZigBee

IDN

PON

PtP

VDSL2

LTE

LPWA

LoRaWAN

NB-IoT

sigfox Wireless

Copper

Fibre

Figure 6.1: High-level diagram of the IoT access network architecture. There are fourmain nodes (left to right): the IoT gateway, the customer premises equipment (CPE) mo-dem, the remote node (RN) and the edge node (EN) located at the central office (CO) orlocal exchange. The nodes are vertically aligned while the technologies are horizontallyaligned.

technologies - both wireline and wireless - when handling traffic with IoT-like statistics

is considered.

In Wireline Access Networks, a physical connection joins the IoT gateway through

to the central office. Wireline access technologies benefit from a controlled medium with

high capacity, transfer speeds, low latency and security. For wireline access, considering

Passive Optical Network (PON), Point-to-Point Optical Network (PtP) and Very-high-bit-

rate Digital Subscriber Line (VDSL2), using a fibre to the node (FTTN) backhaul network.

With Wireless Access Networks, an IoT gateway connection to the Internet core is

established via a (at least one) wireless link. As seen in Figure 6.1, a wireless link can

be used as transport medium either between an IoT gateway and modem, or more com-

150 Power Consumption of IoT Access Networks

monly between the modem and base station (typical of mobile cellular network access),

transmitting traffic through to the central office. Wireless links are established using ra-

dio waves in free space with licensed or unlicensed frequency spectrum. Hence, they are

subject to the vagaries of an uncontrolled medium, including propagation losses, interfer-

ence, signal power attenuation, spectral inefficiencies and low capacity, and offer a range

of user access bit rates. Wireless technologies mostly differ in coverage range, frequency,

transmission power, multiplexing scheme and modulation. We consider recent wire-

less access technologies including Long Term Evolution (LTE), Low-Power Wide-Area

(LPWA) network and a shared (i.e. with hundreds of users) and unshared (i.e. single-user)

Wi-Fi network.

A detailed description of the afore-mentioned technologies are discussed in the sub-

sections below.

6.2.1 Passive Optical Network (PON)

PON is a widely used optical access network technology, owing to its low-cost, low main-

tenance sharing architecture [89]. With PON (see Figure 6.1), a cluster of customer sites

share a connection (single fibre line) to a network Optical Line Terminal (OLT) at the par-

ent exchange or CO via a passive splitter [87,89] (see Figure 6.1). Hence there is no power

requirement at the remote node. Common split ratios are 32-way (up to 20 km) or 64-way

(up to 10 km) [87, 89], but the selection of ratio depends on the planned traffic levels and

customer site density. An Optical Network Unit (ONU) at each customer site commu-

nicates with the OLT using Time Division Multiplexing (TDM). Gigabit Passive Optical

Network (GPON) is commonly deployed and can provide up to 2.4 Gb/s downstream

(DS) and 1.2 Gb/s upstream (US) bit rates between the ONU and OLT [89].

6.2.2 Point-To-Point Optical Network (PtP)

An optical Point-to-Point link provides a dedicated fibre connection from the customer

site to the CO [87]. As shown in Figure 6.1, an optical media converter is utilised as a

CPE modem connecting a single fibre line to an Ethernet switch, usually located at the

6.2 IoT Access Network Architecture 151

CO. This one-to-one relationship between customer site and fiber terminals (e.g. Ethernet

ports) at the CO makes a PtP first installation more costly and requires more powering

and maintenance [87]. PtP architecture also does not have a remote node, hence no power

is required. Such systems are more commonly used where customer traffic demands are

high (e.g. an office complex, hospital, or school).

6.2.3 VDSL2 using FTTN

VDSL2 (very-high-bit-rate digital subscriber line) - the latest of the xDSL generation -

takes advantage of existing copper pairs pre-installed for legacy telephony systems. In

DSL technology, fixed-line telephone service utilise lower frequency bands - to carry a 4

kHz voice signal - while higher frequency bands (up to 30 MHz) are allocated to broad-

band services [89,167]. Voice and data channels are separated at the customer site using a

low-pass filter. With VDSL2, customer sites connect via existing copper lines to a nearby

concentrating network element, often described as a DSLAM (Digital Subscriber Line Ac-

cess Multiplexer) or MSAN (Multi Service Access Node) as shown in Figure 6.1. In either

case, the node connects via optical fibre or FTTN network to its parent exchange. Shorter

copper loops as a result of a FTTN backhaul architecture provide increased bandwidth

capacity to the customer site. Using VDSL2, access rates of up to 100 Mb/s (symmetric)

are achievable [167].

6.2.4 Long Term Evolution (LTE) Wireless

Long-range wireless access is provided through the 4G LTE cellular network. LTE - a

recent generation (4G) of 3GPP’s cellular network technologies - is based on orthogonal

frequency division multiplexing (OFDM) in the downlink and single-carrier frequency-

division multiplexing in the uplink [90, 91]. In the model, LTE Rel-8 standard is used,

which offers higher peak data rates due to a large system bandwidth of up to 20 MHz

and higher order spacial multiplexing techniques [91]. In 4G LTE, the customer site mo-

dem connects to a local cellular base station/eNode-B, which in turn connects back to a

switch at the CO, typically via fibre (see Figure 6.1). The traffic capacity of 4G LTE de-

152 Power Consumption of IoT Access Networks

pends on the transmission path in terms of distance, topography, and interference from

other signals, and is generally lower than the theoretical figures quoted. Under ideal con-

ditions, downlink and uplink data transmission rates of up to 73.4 Mb/s and 20.6 Mb/s

respectively, are achievable for a 2x2 MIMO, 10 MHz bandwidth configuration [168].

6.2.5 Low-Power Wide Area (LPWA) Network

Low-Power Wide Area network is an emerging radio network technology specifically de-

signed for M2M/IoT communications with low power consumption and wide area cov-

erage being its most desired features. Operating in the unlicensed sub-1 GHz frequency

bands (i.e. 433 MHz, 868-915 MHz), LPWA caters for applications and services of partic-

ularly low data-rate (10 - 100 b/s typical; 100 kb/s max) demands and small daily traffic

volumes [92,93]. This limits the application of LPWA technology to a subset of M2M ser-

vices with infrequent small data transmissions, like smart meters, parking management

and asset/vehicle tracking. In a LPWA network, as depicted in Figure 6.1, a wireless

modem or module connected to or embedded in customer site end-devices (e.g. sensors)

links to the LPWA base station - known as a gateway/concentrator (referred to as a gate-

way from this point forward) - via the air interface. Traffic from hundreds/thousands

of these end-devices is backhauled from the gateway to an operator’s back-end network

and application servers (typically cloud applications) via Ethernet, 3G/4G/5G wireless

or optical IP links similar to those commissioned for LTE base stations. Depending on

the type of application, an LPWA end-device module may be deployed in remote loca-

tions without mains power and can be battery-powered with many years of continuous

operation [93]. Today, the LPWA deployment landscape is dominated by proprietary

technologies (e.g. sigfox, Narrowband IoT, Long Range (LoRa)) that are mostly incom-

patible with each other [169, 170].

LPWA is still a developing technology with presence in major markets around the

world [127,169]. Hence equipment information, traffic statistics and manufacturer datasheets

are not readily available in the literature.

6.3 Power Consumption Model 153

6.2.6 Wi-Fi Network

Wi-Fi network is a short-range wireless technology suited to cable-free connecting of user

devices to the customer site CPE modem. Wi-Fi is useful in providing connectivity be-

tween the IoT gateway and the network-facing modem, and in some instances between

the sensors or “things” and their gateway. Our model of an IoT access network - given

in Figure 6.1 - shows the IoT gateway connecting to the customer site CPE modem via

twisted-pair copper (i.e. Ethernet) for all wireline access technologies and via a USB mo-

dem dongle for 4G LTE Wireless. For LPWA network, a local IoT gateway is not required.

Although it is possible to utilise a Wi-Fi connection as a substitute for Ethernet to

connect the IoT gateway to the modem, the choice here is to model Wi-Fi connectivity

only with a passive optical network backhaul in the comparison. Wi-Fi operates in the

2.4 and 5 GHz ISM bands and under ideal conditions, can provide data rates in excess of

300 Mb/s [20].

6.3 Power Consumption Model

In this section, a description of a generic energy model for the IoT access network, dis-

cussed in the preceding section is presented. As seen from Figure 6.1, the IoT access net-

work includes four main nodes: the IoT gateway which aggregates traffic from the IDN,

the CPE modem which is technology-specific and located at the customer site, the remote

node (RN) which is usually at the street cabinet nearest to the customer site or base sta-

tion within few kilometres, and the exchange node (EN) located at the local exchange.

The power consumption per IoT gateway (Pi) for the complete IoT access network in

Figure 6.1 can be expressed as:

Pi = PIoT + PCPE +XRNPRN

NRN+XEN

PEN

NEN(6.1)

where PIoT, PCPE, PRN and PEN are the power consumed by the IoT gateway, the CPE mo-

dem, the remote node and the exchange node, while NRN and NEN represent the number

of users/ports of the remote and exchange nodes respectively. XRN and XEN are multi-

154 Power Consumption of IoT Access Networks

plier factors (where XRN, XEN > 1) used to account for the additional power consumed

for environmental control (i.e. cooling) of the facilities within which network nodes are

located plus overheads (e.g. power systems losses). These factors are akin to the power

usage effectiveness (PUE) ascribed to data centres [171]. The value of 1.5 is used as an

average overhead factor as in [42,70,171]. In the above model (6.1), the IoT gateway, CPE

modem and some remote nodes are naturally cooled.

The estimates presented in this chapter are developed using power consumption val-

ues for commercially available typical equipment, manufacturer data-sheets and some

experimental measurements (where applicable), to provide a first-order energy model.

The model in (6.1) thus provides an estimate of the power consumption of an IoT access

network considering IoT-like traffic statistics. Based on an in-house experimental mea-

surement of traffic levels of an example IoT service (i.e. a home automation system [15]),

a data access rate between 1 kb/s and 1 Mb/s is applied. Different access technologies

provide different data rates, which may also be dependent on the location of a customer

site with respect to its parent remote node. In order to achieve a fair comparison in the

analysis, practical and achievable data rates for each technology that are based on field

reports and data-sheets are used.

In the following section, a discussion of some power consumption modelling ap-

proaches used to represent the nodes of the IoT access network technologies described in

section 6.2 is given.

6.4 Network Element Modelling

This section describes the modelling of each network element in the IoT access network.

To aptly represent the different usage characteristics of networking equipment, they are

classified into three main types:

1. Unshared Network Elements

2. Fixed-user Shared Network Elements

3. Multi-user Shared Network Elements

6.4 Network Element Modelling 155

The unshared network element type refers to a ”single-user” equipment (e.g. modem),

hence its power consumption is allocated to one user in the model. Some shared network

elements may serve a fixed number of users (e.g. DSLAM) while others may service an

indeterminate number of users and services (e.g. Ethernet Switch). We therefore model

shared network elements as either ”fixed-user” equipment in which its power consump-

tion is allotted to a finite number of users or as ”multi-user” equipment in which power

consumption is allotted based on the access bit rate traffic generated by the users and

services traversing the network equipment. These energy models are discussed below.

6.4.1 Unshared Network Elements

An unshared network element refers to a network equipment that deals with traffic ded-

icated to a ”single-user” (e.g. modem for an xDSL service, an ONU). To define a ”single-

user”, consider two sets of use-cases; In the first set, an IoT service installation is in a

home or small business setting (e.g. HAS) where it shares a CPE modem with many

other traffic generating services (e.g. Facebook, Youtube, Outlook), often with higher

traffic flows than the IDN. However, in the second set (e.g. Environmental Monitoring,

Smart Agriculture), the IoT service (i.e. sensors and IoT gateway) installation may be

located in settings where the CPE modem is dedicated to carrying traffic flows generated

by the IoT service exclusively. The latter is considered here. Hence, for the modelling of

an unshared network element, a ”single-user” is defined as a single IoT service (i.e. one

IDN) comprising of many traffic generating IoT devices with an IoT gateway, communi-

cating via one CPE modem to the cloud. An unshared network element is thus referred

to as a single-user network element.

Consider a single IoT service with many IoT devices within its IDN. The ith IoT device

generates a steady stream of bits with rate Rdev,i(t) (bit/sec), where i = 1, 2, ..., n for n

number of IoT devices within the IDN. The sum of all data streams from IoT devices

within the IDN, RIoT(t) (bit/sec), can be expressed as:

RIoT(t) =

n∑i=1

Rdev,i(t) (6.2)

156 Power Consumption of IoT Access Networks

From the model of a generic network equipment in Chapter 2, we established that the

power consumption of a single-user network device can be represented by equation (2.1).

CPE modems tend to be ”always on” with continuous power consumed irrespective of

the traffic they handle. From an in-house measurement of an ADSL2+ modem [9], simi-

lar measurements in the literature [96] and the European Commission’s code of conduct

on energy consumption of broadband equipment [124] (referred to as the EUCoC), it is

known that the idle (no-load) power of a CPE modem (Pidle) can be a significant pro-

portion (90% or more) of its maximum power (Pmax); hence Pidle = βPmax (for β > 0.9)

where β is the fraction of maximum power consumed by the network equipment in its

idle state. For the equipment maximum capacity Rmax, the incremental energy portion

of equation (2.1) given by ERmax = (1 − β)Pmax << Pidle. The power consumption of a

single-user network element dealing with traffic generated by a single IoT service RIoT(t)

is given as:

Psu(t) = Pidle + ERIoT(t) ≈ Pidle (6.3)

Given that the power consumed by the network element Psu(t) varies only slightly with

load, the constant power consumption model given in (6.3) is adopted; hence power

consumption values from manufacturer data-sheets are used as representative of typical

single-user network elements in the modelling.

6.4.2 Fixed-user Shared Network Elements

A network element at the remote node or exchange node can be designed and dimen-

sioned to carry data traffic from a fixed number of users. For example, a multi-slot chassis

MSAN [172] contains management and switching cards plus a number of line cards fea-

turing several ports per line card. The number of ports provisioned on the downstream

(user) facing line cards often matches the number of users while the upstream ports back-

hauls user traffic to the Internet core. A schematic diagram of the main components of a

fixed-user shared network element is shown in Figure 6.2.

Consider a fixed-user shared network element (e.g. an MSAN) with a set number

6.4 Network Element Modelling 157

Switchfabric

Upstream port

Backplane

Management

Downstream (user) port

Line card

Line card

Line card

Line card

^PP

1

2

N

Figure 6.2: Schematic diagram of the internal structure of an MSAN

of user ports N (assuming 1 port per user modem) as shown in Figure 6.2. The power

consumption of the equipment can be divided into two main portions: 1) the dedicated

portion P (on the left hand-side) representing the power consumed by the line cards and

their downstream (user) ports and 2) the shared portion P (on the right hand-side) rep-

resenting the power consumed by the shared switch fabric, management and upstream

ports.

Consider a steady stream of traffic passing through one of the identical line card ports

j given as Rport,j , where j = 1, 2, ....,m, with m being the number of ports per line card

for L line cards. Assuming all network management traffic associated with each port is

an inclusive fraction of Rport,j , and for a fully-equipped network element with all ports

provisioned (i.e. number of ports = number of users), the total traffic through a fixed-

user network element Rtot can be expressed as: Rtot = (L×∑m

j=1Rportj). Equation (2.1),

expressed as a function of bit rate R (bit/sec) is then applied. The power consumption

of a fixed-user shared network element Pfu(Rtot) as a function of the total traffic (Rtot) is

calculated as the sum of the dedicated portion (P ) and shared portion (P ) (as indicated

158 Power Consumption of IoT Access Networks

in Figure 6.2) and expressed as:

Pfu(Rtot) = LmPidle + Lm∑j=1

EjRport,j + Pidle + ELm∑j=1

Rport,j

= LmPidle + Pidle + LmRport(E + E) (6.4)

where Pidle is the no-load power for each port per line card and Pidle, the no-load power

of the shared components (i.e. switch fabric, etc.), while E and E are the incremental

energy per bit per port and that of the shared components respectively.

Power consumption measurements of a similar network element [173] show that its

idle power can be about 92% or more of its full-load power, with the slope denoted as E

being very small. Thus even for a maximum bit rate of each port per line card Rport(max),

the expression in (6.4) may be simplified to:

Pfu(Rtot) ≈ NPidle + Pidle (6.5)

given that LmPidle + Pidle >> LmRport(max)(E + E) with the total number of ports N =

Lm. Under the same conditions Rtot = N〈Rport〉, where 〈Rport〉 (bit/sec) represents the

average traffic per port. Using equation (6.5), the expression for power consumption per

port (user) for a fixed-user shared network element Pfu(Rport) can be written as:

Pfu(Rport) ≈Pmax

N(6.6)

where Pmax ≈ (NPidle + Pidle) which is consistent with power consumption measure-

ments of a similar equipment described in [173]. Since a single IoT service uses one

modem which connects to one port, Rport = RIoT; hence Pfu(RIoT) ≈ Pmax/N .

6.4.3 Multi-user Shared Network Elements

A multi-user network element refers to an item of equipment dealing with traffic from

many (hundreds/tens of thousands) users, services and application data flows at any

given time. To determine the power consumption of a network user or service accessing

6.4 Network Element Modelling 159

a multi-user network element, a portion of the equipment power is allocated to that user

or service. To achieve this goal, the number of users or services traversing the network

element at any given time is an essential quantity. But determining a finite number of

users or services simultaneously accessing such an equipment may not be practical. One

method of modelling what can be described as a ”highly shared” network element is the

”traffic-based” approach described in [70].

Let us consider this approach, which allocates a portion of the total element power

consumption (idle and incremental power) P (Rtot) to a service with data traffic rate Rsrv,

as a fraction of the total element data rate Rtot. The power consumption attributable to

this service at time t is given as:

Psrv(t) =Pidle

Rtot(t)Rsrv(t) + ERsrv(t) (6.7)

whereE is the incremental energy per bit given byE = (Pmax−Pidle)/Rmax, Pmax and Pidle

are the network element maximum and idle power consumption, andRmax, its maximum

data rate in bits/sec.

We can calculate the energy consumption of the service by taking the integral of Psrv(t)

over a required period of time T (e.g. a diurnal cycle), given as:

Qsrv(T ) = Pidle

∫ T

0

Rsrv(t)

Rtot(t)dt+ E

∫ T

0Rsrv(t)dt

= Pidle

∫ T

0

Rsrv(t)

Rtot(t)dt+ EBsrv(T ) (6.8)

where Bsrv(T ) is the total data volume of the service in bits over a time duration T . We

can then obtain the average power consumption of the service 〈Psrv(T )〉, given by:

〈Psrv(T )〉 =Qsrv(T )

T= Pidle

(1

T

∫ T

0

Rsrv(t)

Rtot(t)dt

)+ E

(Bsrv(T )

T

)

= Pidle

⟨Rsrv

Rtot

⟩+ E〈Rsrv〉 (6.9)

given that the mean value 〈X〉 = 1/T∫ T0 X(t)dt.

160 Power Consumption of IoT Access Networks

In (6.9), the fractional data traffic rate of the service passing through the network element,

relative to the total data traffic is given by Rsrv(t)/Rtot(t), and its mean value 〈Rsrv/Rtot〉

over time T . This mean value can range from 0 to 1 as expressed by the inequality:

0 6

⟨Rsrv

Rtot

⟩6 1 (6.10)

Since the value of Rsrv(t)/Rtot(t) at a given time is highly dependent of the type of ser-

vice and its data flow rate, let us consider three example service scenarios to examine the

effect of the mean value 〈Rsrv/Rtot〉 on the attributable energy consumption allocation to

the service.

Scenario 1: For a given service with a data rate Rsrv(t) ≈ Rconst (e.g. video surveillance

service), where Rconst is a constant data rate, then we get:

⟨Rsrv

Rtot

⟩≈⟨

1

Rtot

⟩Rconst (6.11)

Then from (6.9),

〈Psrv〉 ≈(Pidle

⟨1

Rtot

⟩+ E

)Rconst (6.12)

Scenario 2: For a given service with a data rate that is approximately proportional to the

total data rate of the network element (a service with data rate similar to a typical diurnal

cycle), then Rsrv(t) ≈ kRtot(t) with 0 6 k 6 1, hence,

⟨Rsrv

Rtot

⟩≈ k (6.13)

Then from (6.9),

〈Psrv〉 ≈ Pidlek + E〈Rsrv〉 (6.14)

Scenario 3: For a given service with a data rate that is negligible in comparison with the

total data rate of the network element, such that Rsrv(t)/Rtot(t) 1, then,

⟨Rsrv

Rtot

⟩≈ 0 (6.15)

6.4 Network Element Modelling 161

Then from (6.9),

〈Psrv〉 ≈ E〈Rsrv〉 (6.16)

On the flip side, the service may have its maximum data traffic rate at a point when the

aggregate diurnal data traffic rate is at its minimum (i.e. Rsrv(t)/Rtot(t) ≈ 1), and vice

versa during the peak traffic period/busy hour, which will then give Rsrv(t)/Rtot(t) ≈ 0,

for which (6.16) applies. For the former instance, (6.9) can be written as:

〈Psrv〉 ≈ Pidle + E〈Rsrv〉 (6.17)

Both data and management traffic flowing through the network element - denoted as

background traffic (Rbgd) - can be expressed as the sum of individual service data flows

Rsrv,l at a given time t given by: Rbgd(t) =∑n

l=1Rsrv,l(t), where l = 1, 2, ...., n, for n

number of services. The traffic generated by an IoT service, RIoT(t) is regarded as an

Pidle

Pmax

Rmax

Pow

er

Con

sum

pti

on

(W

att

s)

Load (bit/sec)

Rbgd+RIoT

PIoT

Rbgd

Figure 6.3: Power consumption profile of a multi-user shared network element

addition to the background traffic Rbgd(t) as depicted in Figure 6.3; hence the aggregate

data traffic rate Rtot(t) passing through the network element at time t can be expressed

as:

Rtot(t) = Rbgd(t) +RIoT(t) (6.18)

162 Power Consumption of IoT Access Networks

Due to the burstiness and unpredictability of network traffic, operators manage the equip-

ment operating load utilization U and set by policy a maximum load utilization Umax,

such that 0 < U < Umax, in-order to mitigate possible congestion and minimise packet

loss. The total traffic Rtot(t) is a fraction of the maximum traffic level (Rmax) the network

element can support, such that (6.18) can be written as:

Rtot(t) = Rbgd(t) +RIoT(t) = U(t)Rmax, for 0 6 U(t) 6 1 (6.19)

From (6.9) and (6.19), the fractional power consumption of a multi-user shared network

element attributed to an IoT service with a data rate RIoT is given as:

〈PIoT〉 =Pidle

Rmax

⟨RIoT

U

⟩+ E〈RIoT〉 (6.20)

Hence, a convenient metric for the average energy-per-bit (idle plus incremental) of a

multi-user shared network element 〈EBIT〉measured in joules per bit (J/bit) is expressed

as:

〈EBIT〉 =Pidle

Rmax

⟨1

U

⟩+

(Pmax − Pidle

Rmax

)(6.21)

6.5 Traffic Measurement

Traditionally, the access networks are designed to handle traffic in which downstream

volumes dominate, or at most, traffic is symmetrical. IoT traffic instead involves the gen-

eration of a large number of small packets, with upstream traffic dominating the flow.

Our measurements of the open-source Ninja Block (NB) HAS [15] indicate an approxi-

mate uplink-downlink ratio 5:1 (4.6 kb/s uplink and 0.9 kb/s downlink) when few sen-

sors are connected to the block, and a ratio of about 23:1 (222.9 kb/s uplink and 9.7 kb/s)

for an image streaming IoT application. The full description of these experiments and

results is detailed in Chapter 3. Figure 3.17 is a plot showing total traffic and total data

volume measured over time when few sensors and a webcam are separately connected

to the NB. The observed variation departs from customary internet applications that are

downlink intensive (e.g. browsing, video-on-demand). Its importance can be critical in

6.6 Estimating the Power Consumption of Network Elements 163

network devices with unequal uplink and downlink power budget (e.g. cellular network

base station). A 5:1 ratio of uplink to downlink bit-streams typical of a sensor-based

network is assumed in later calculations.

6.6 Estimating the Power Consumption of Network Elements

In this section, a first-order estimate for power consumption of the network architectures

described in 6.1 is constructed. Each access network technology includes a CPE mo-

dem at the customer side. Table 6.1 lists these modems as unshared network elements,

detailing their power consumption and maximum data rates. Table 6.2 lists the shared

network elements considered in the model with their corresponding numbers of users or

ports, maximum upstream and downstream data rates and power consumption values.

The values listed in Table 6.1 and 6.2 are examples of commercially available network

equipment, typical of the network device types. The choices here are not necessarily the

”state-of-the-art” in terms of energy-efficiency, but are representative of 2016-era access

network devices. Because it is not common for some mainstream vendors to publish

power consumption values for network devices, data from some non-mainstream ven-

dors are used for a few devices.

6.6.1 IoT Network

The ninja block [15] - a model of an IoT gateway used in this work - contains a Beagle-

Bone Black Linux micro-computer coupled with a customized daughter board known

as an Arduino cape. Measurements indicate that the NB consumes about 2.2 W when

connected to the Ethernet port of a CPE modem.

6.6.2 Wi-Fi Access Network

Considering two types of Wi-Fi models: an unshared Wi-Fi model for which the network

is dedicated to IoT services (e.g. smart farming application) and a shared Wi-Fi model

164 Power Consumption of IoT Access Networks

Table 6.1: Power consumption and data rate of unshared network elements

Unshared Network Element Device ModelMax. DSCapacity

(Gb/s)

Max. USCapacity

(Gb/s)

PowerConsumption

(Watts)IoT Gateway Ninja Block v2 0.1 0.1 2.2 [15]VDSL2 Modem Eltek V7600 A1 0.1 0.1 7 [174]Unshared Wi-Fi Router Ad-Net GPON HGU 0.3 0.3 6 [175]4G LTE Wireless Modem ZTE MF 823 0.04 0.01 1.4 [176]Optical Network Unit (ONU) Zhone GPON 2301 2.4 1.2 5 [177]Ethernet Media Converter CTC-Union FRM220 1 1 4 [178]

Table 6.2: Power Consumption and data rates of shared network elements

Shared Network Element Device ModelMax. DSCapacity

(Gb/s)

Max. USCapacity

(Gb/s)

No. ofPorts orUsers

IdlePower(Watts)

Max.Power(Watts)

LPWA Gateway WiMOD iC880A 48 kb/s 48 kb/s - 3.1 4.4 [179]Ethernet Switch [Low-Range] Cisco 3750v2-24FS 2.4 2.4 24 93.2 94.2 [180]4G LTE Base Station EARTH 2012 Model 0.0734 0.0206 - 291 528 [23]Optical Line Terminal Tellabs 1134 38.4 19.2 512 400 480 [154]Ethernet Switch [Mid-Range] Cisco 3800X-24FS 24 24 24 161 238 [181]Shared Wi-Fi Access Point Cisco ME 4624 RGW 0.3 0.3 256 13.5 15 [182]Multi-Service Access Node ZyXel IES-5106 12 12 120 352 391 [172]

typical of a corporate or industrial setting with many users and services. The multi-user

shared network element model, given in (6.20) is employed for the shared Wi-Fi type and

the unshared network element model, given in (6.3) for the single-user type.

For the unshared Wi-Fi network model, an Ad-net GPON HGU ONT with built-in

Wi-Fi support [175] is used as an unshared Wi-Fi CPE modem with a reported power

consumption of 6 W. This Ad-net ONT represents a single IoT service in the model. PON

access is used as a backhaul network.

For a shared Wi-Fi network model, the Cisco ME 4624 Gateway [182] with built-in Wi-

Fi support, is employed as an Access Point (AP). The ME 4624 AP consumes a maximum

of 15 W. For shared Wi-Fi access modelling, equation (6.21) is applied to determine the

“per-bit” energy consumption of the AP, whilst considering a maximum bit rate of 150

Mb/s and an average utilization 〈U〉 of 20% (i.e. 〈Rbgd〉 ≈ 30 Mb/s). The energy-per-bit

of the shared Wi-Fi AP for 〈U〉 = 0.2 is thus calculated as 460 nJ/bit. Similar to the unshared

network, PON access is used for traffic backhaul to the network core.

Table 6.3 shows calculated energy-per-bit values for the AP and a mid-range Ethernet

Switch. The modelling of the Ethernet switch is discussed in section 6.6.5 below. The

6.6 Estimating the Power Consumption of Network Elements 165

values in table 6.3 are subject to traffic usage assumptions and are dependent on the

average utilization of the network element.

Table 6.3: Energy per bit values of shared network elements

Network Element Energy per bit (nJ/bit)Ethernet Switch [Mid-Range] 37Shared Wi-Fi Access Point 460

6.6.3 Passive Optical Network Access (PON)

In modelling a passive optical network, a GPON installed network with a 32-way split

ratio is considered. At the remote node a single fibre is passively split to serve up to 32

ONUs (28 ONUs in practice). Hence no power is required for the remote node (PRN = 0).

A Tellabs 1134 [154] optical line terminal is used as the exchange node for PON (see

Figure 6.1). An OLT can serve a determinate number of ONUs which depends on its

configuration; hence the fixed-user power model is used for the optical line terminal.

The 1134 OLT has 16 GPON downlink ports and twelve 1 GbE uplink interfaces. At

full configuration, with full port occupancy, the 1134 can service up to 512 customer sites

(i.e. 16 GPON ports x 32) with a 32-way split ratio per fibre line. The 1134 has a maximum

power consumption of 480 W [154]. Using the fixed-user shared network element model

in (6.6), the power per IoT service for the OLT is calculated as 0.9 W. The ONU used in

the model is the Zhone ZNID-2301 [177] with a power consumption of 3-5 W.

6.6.4 Point-to-Point Optical Network Access (PtP)

Point-to-Point optical access offers the highest bit rates to the subscriber by virtue of its

dedicated fibre links between the subscribers’ CPE modem and an exchange node (see

Figure 6.1). There is no remote node in a PtP installation, therefore no attributable power.

To model a PtP optical network, the low-range Cisco Catalyst 3750-24FS Ethernet

switch [183] is considered as the local exchange node. The 3750 switch provides 24 100FX

Ethernet ports and 2 SFP Gigabit Ethernet uplink ports, with a switching capacity of

166 Power Consumption of IoT Access Networks

32 Gb/s. The switching power consumption measured at 5% and 100% throughput is

reported as 54.2 W and 55.2 W [183] respectively and each port consumes 1.5 W [180].

Total idle and maximum power of the switch is 93.2 W and 94.2 W respectively, giving

a 1% load proportionality. PtP architecture ascribes 1 port per customer site (i.e. CPE

modem), hence the fixed-user shared network element model given in (6.6) is employed

for the low capacity Ethernet switch. The calculated power per IoT service is 3.9 W. A

CTC Union FRM-220 [178] optical media converter which consumes 4 W is selected as

the CPE modem for PtP architecture.

6.6.5 VDSL2 Access Network

A VDSL2 installation takes the form of a FTTN/FTTB network, terminating at the DSLAM

or MSAN, and a dedicated copper line from the DSLAM to the customer site. This model

is based on a fully-equipped ZyXel IES-5106 MSAN [172] with all ports occupied at the

remote node. At full configuration, the IES-5106 holds five VDSL2 line cards and a man-

agement switch card. Each VDSL2 line card supports 24 customer sites and consumes

about 66 W. Full-load power consumption of the IES-5106 MSAN is 391 W. The CPE mo-

dem for VDSL2 architecture is an Eltek V7601-A1 [174] which consumes 7 W.

For a model of an MSAN, a reported power consumption measurement of a similar

equipment showing its idle power being approximately 92% of its peak power is con-

sidered as a benchmark [173]. Furthermore, the number of port connections that can be

provisioned at the MSAN is fixed. With respect to the IES-5106, only 61 W of its maxi-

mum power 391 W can be shared amongst users on a traffic usage basis. Because most

of the IES-5106’s power is consumed in the idle state (> 84%), which is consistent with a

measured benchmark equipment, the slope E from Figure 2.5 for the MSAN is substan-

tially flat. Hence the power per IoT service for a VDSL2 remote node is calculated using

a fixed-user shared network element model given in (6.6), thus calculated as 3.3 W.

The exchange node is the mid-range Cisco ME 3800X-24FS Carrier Ethernet switch

providing 24 Gigabit Ethernet SFP ports with two 10 Gigabit SFP+ ports for traffic back-

haul, and a full-duplex switching capacity of 44 Gb/s [181]. The 3800X aggregates traffic

from multiple MSANs and base stations with an indeterminate number of users or ser-

6.6 Estimating the Power Consumption of Network Elements 167

vices [181]; hence a multi-user shared network element model is employed. In the model

an average utilization of 20% is assumed (i.e. 〈U〉 = 0.2), resulting in an average back-

ground traffic 〈Rbgd〉 = 4.8 Gb/s. Since the background traffic is far greater than that

from the IoT service (1 kb/s 6 RIoT 6 1 Mb/s), equation (6.21) is applied to calculate

the energy-per-bit of the Ethernet switch, which is calculated as 37 nJ/bit as given in

Table 6.3.

6.6.6 4G LTE Network Access

A simple 4G LTE access network involves a 4G LTE wireless modem at the customer site

connecting via a wireless link to the closest base station (i.e. the remote node), which in

turn connects to an Ethernet switch located at the local exchange (see Figure 6.1). Using

the 2012 state-of-the-art reference base station put forth by the Earth Project [23], an LTE

Rel-8 Macrocell BS, with 10 MHz bandwidth frequency division duplexing (FDD), is con-

sidered as the 4G LTE remote node. The Rel-8 BS has a 2x2 MIMO configuration with 2

transceivers per sector and a theoretical peak throughput of 73.4 Mb/s and 20.6 Mb/s in

the downlink and uplink respectively, achievable under ideal conditions [168]. A single

4G LTE BS can maintain hundreds or thousands of active users or gateway devices at any

given time and is therefore considered as multi-user shared network element.

A ZTE MF823 4G LTE wireless modem is utilized as the CPE modem. The plot in

Figure 6.4 shows the measured power consumption of the 4G Dongle having three dis-

tinct power levels: standby, idle and active, the latter accounting for power consumed

when transmitting and receiving data. The three levels are consistent with the EUCoC

[?], which sets out basic principles for component manufacturers, service providers and

network operators for improving energy efficiency of broadband equipment. In the ac-

tive state, the 4G dongle consumes an average of 1.4 W.

As shown in Figure 6.1, the BS connects to the core of the network via an Ethernet

switch at the local exchange. The Cisco 3800X is used to represent the Ethernet switch in

the model of a 4G LTE access network. Power consumption contribution of the exchange

node for a 4G LTE network access is hence calculated on a traffic volume basis using the

168 Power Consumption of IoT Access Networks

Figure 6.4: Power consumption measurement of a ZTE MF823 4G Wireless Dongle

energy-per-bit calculation in (6.21).

For the BS, it is assumed that the power consumption grows proportionally with the

number of transceivers. The total power consumption of a BS [23] with N transceivers

can be expressed as:

PBS = N × PPA + PRF + PBB

(1− σDC)(1− σMS)(1− σcool)(6.22)

where PPA, PRF and PBB account for the power draw by the power amplifier (PA), the

transceiver module and baseband unit (BBU), σDC, σMS, σcool account for the loss factors

due to the BS DC-DC power supply, main supply and cooling overheads (see table 6.4)

respectively. The radio frequency (RF) and signal processing components of a BS include

a number of functions common to both transmitter and receiver subsystems, for which

the power consumption is spilt equally, except where the data for each of the subsystems

is available separately. The RF power amplifier (PA) in the BS however is used only in

the transmitter, and its consumption is fully assigned to the downlink energy usage. The

transmitter PA power consumption is treated as load-proportional in accordance with

[23], whilst the consumption of the remaining components is considered to be indepen-

dent of load.

6.6 Estimating the Power Consumption of Network Elements 169

Table 6.4: Power consumption values for 4G LTE base station components from [23]

Base Station Component Transceiver (TRX)*RF Chain (TX / RX) 5.7 / 5.1 W

Baseband Unit 14.8 WPA Power (Idle / Max) 38.8 / 102.6 W

Main Supply Loss (σMS) 7%

Cooling Loss (σcool) 9%

DC-DC Loss (σDC) 6%

* A 2x2 MIMO base station described in [23] contains 2transceivers per sector, making a total of 6 transceiversfor a 3 sector base station. The above values apply to eachtransceiver.

Consider a single sector of the 2012 reference BS running in a 2x2 MIMO mode with

two transceivers per sector (N = 2). Using (6.22), the power consumption of the transmit

section (downlink) is calculated as 130 W and 291 W in the idle and full-load states,

respectively. For the receive section (uplink) of the BS there is no PA (hence PPA = 0).

The power consumed by the receiver of the BS is thus considerably lower than that of the

BS transmitter, hence the incentive for modelling the transmitter and receiver separately.

The power consumption of the receiver is calculate as 31 W.

Considering a one sector base station dealing with trafficRBS(t) at time t. Since the BS

is classified as a multi-user shared network element, equation (6.18) is applied to obtain

an expression for the aggregate traffic load RBS(t) handled by the BS sector as:

RBS(t) = Rbgd,BS(t) +RIoT(t) (6.23)

where Rbgd,BS(t) represent the background traffic of the BS sector and RIoT(t), the traffic

generated by an IoT service.

Wireless links exhibit uncontrollable channel characteristics with attributes such as

fading, interference and propagation losses, unlike a much more controlled medium in

the case of wireline. For 4G LTE, the average user access rate is dependent on the these

attributes, the user’s location with respect to the base station, the number of user requests

at that instant and available resource blocks to serve those users.

To estimate the BS sector’s uplink and downlink background traffic, consider a useful

170 Power Consumption of IoT Access Networks

approximation to a mobile network diurnal traffic profile given in [13], which is based

on data obtained from a telecoms operator. The BS hourly average traffic load levels, as a

percentage of the daily average for a dense urban area is listed in Table 6.5. A profile trace

of the BS hourly average traffic load, over a 24 hour period is shown in Figure 6.5. The

figure shows that the BS hourly traffic load utilization ρ(t) varies from 20% of the daily

average load Rave,BS during the early hours of a day to 140% of the daily average load

during busy-hours. Hence the BS sector background trafficRbgd,BS(t) = ρ(t)Rave,BS, given

that Rave,BS = 〈U〉Rmax,BS from equation (6.19), where 〈U〉 is the traffic load utilization

over the diurnal cycle and Rmax,BS the maximum throughput of the one sector BS.

Table 6.5: Traffic level distribution of a dense urban area over a 24 hour period

Traffic ProfileLevel ρ (%) Duration (hrs)

20 240 4100 4120 8140 6

Time of Day (hours)0 2 4 6 8 10 12 14 16 18 20 22 24

Rel

ativ

e Lo

ad L

evel

(%

)

0

20

40

60

80

100

120

140

160

Figure 6.5: Daily BS traffic load profile of a dense urban area. 100 % corresponds to thehourly traffic averaged at intervals over the 24 hour day [13].

Unlike other network elements listed in Table 6.2, the base station consumes unequal

6.6 Estimating the Power Consumption of Network Elements 171

power in each direction. A study in [184] reports that 87% of the BS power is consumed

in the downlink, with only 13% consumed in the uplink. These percentages are similar

to the BS (considered here) power consumption values as given in table 6.4 (i.e. ≈ 90%

downlink and 10% uplink). The substantial difference is due to the absence of the base

station PA in the uplink RF chain. For this reason, the incremental energy portion in

the uplink power model given below is disregarded. Using equation (6.20) the power

consumption for a one sector 4G LTE BS, PBSsect(RBS) can be written as:

PBSsect(RBS) =

(Pidle

RBS+Pmax − Pidle

Rmax,BS

)RBS (6.24)

where RBS is the aggregate average BS sector traffic load derived from (6.23), Pmax and

Pidle are the maximum and idle BS sector power and Rmax,BS the maximum BS sector

throughput.

Taking the average power for a 5:1 uplink to downlink traffic ratio (see Figure 3.17),

the expression for the 4G LTE BS sector uplink power PBSsect(RIoT,ul) attributable to an IoT

service can be expressed as:

PBSsect(RIoT,ul) =

(Pidle,ul

ρRave,ul +RIoT,ul

)RIoT,ul (6.25)

where RIoT,ul represents the uplink traffic generated by the IoT service, Rave,ul represents

the aggregate average uplink throughput of the BS and Pidle,ul represents the BS idle

power consumption of the uplink chain. As described above, there is no PA in the uplink

RF chain, hence the incremental energy portion of equation (6.24) is neglected.

Similarly, the expression for 4G LTE BS sector downlink power consumptionPBSsect(RIoT,dl),

attributable to an IoT service can be expressed as:

PBSsect(RIoT,dl) =

(Pidle,dl

ρRave,dl +RIoT,dl+Pmax,dl − Pidle,dl

Rmax,dl

)RIoT,dl (6.26)

where RIoT,dl represents the downlink traffic generated by the IoT service, Rave,dl repre-

sents the aggregate average downlink throughput of the BS, Rmax,dl represent the maxi-

mum downlink throughput of the BS and Pidle,dl and Pmax,dl represents the BS idle and

172 Power Consumption of IoT Access Networks

100 200 300 400 500 600 700 800 900 1000

IoT Data Access Rate (kb/s)

0

5

10

15

20

25

IoT

-rela

ted L

TE

BS

Secto

r P

ow

er

(W)

Background Traffic Level

20% of average background traffic level

40% of average background traffic level

100% of average background traffic level

120% of average background traffic level

140% of average background traffic level

Figure 6.6: 4G LTE BS sector power attributable to IoT traffic as a function of IoT dataaccess rate for 5 different background traffic level profiles.

maximum power consumption of its downlink chain. The aggregate average downlink

and uplink throughput of a 10 MHz 2x2 4G LTE BS sector is reported as 12 Mb/s and 6

Mb/s respectively, given typical deployment scenarios [168].

With the hourly average traffic utilization values ρ shown in Figure 6.5, the BS sector

aggregate average throughput Rave [168] and the expressions for power given in (6.25)

and (6.26), the BS sector power attributable to an IoT service accessing a BS remote node,

for throughputs between 1 kb/s and 1 Mb/s is calculated as:

PBSsect(RIoT) = PBSsect(RIoT,ul) + PBSsect(RIoT,dl) (6.27)

Figure 6.6 shows the BS sector power attributable to IoT traffic for the five different traffic

utilization profiles of a typical weekday.

6.6 Estimating the Power Consumption of Network Elements 173

6.6.7 LPWA Access Network

The most recent of all the architectures discussed so far is a LPWA network architecture.

In a typical LPWA network, low-powered, low data-rate IoT devices transmit and/or re-

ceive small data packets to or from an LPWA gateway, using purpose-built physical layer

(PHY) modulation schemes via a wireless link. As described in section 6.2.5, a number

of LPWA network technology options are available today (e.g. LoRa) with similar net-

work architectures. In this section, the LoRa architecture is described and modelled as a

representative example of an LPWA network.

In LoRa technology [185], the physical layer (PHY) modulation technique is based

on chirp spread spectrum (CSS) with integrated forward error correction (FEC), while

the MAC layer is defined by the LoRaWAN protocol that is standardised by the LoRa Al-

liance [186]. While the PHY permits different protocol architectures (i.e. Mesh, Star, etc..),

the MAC layer is designed for a long-range star topology network [185]. The gateway, as

shown in Figure 6.7, internally consists of an RF front-end module and a ”host” micro-

controller unit (MCU) (similar to Raspberry Pi, Beagle Bone) or PC. The role of a MCU

in the gateway is to prepare data bits - wrapped as IP packets - for transport through the

Internet to the IoT services back-end servers. The MCU connects to an Ethernet switch

or a 3G/4G/5G network (see Figure 6.7) en-route to the Internet core. LoRaWAN defines

10 channels: 8 multi data-rate LoRa channels with 125 kHz demodulation bandwidth

and a range between 250 b/s to 5.5 kb/s, one high capacity channel (11 kb/s) for inter-

gateway backhaul purposes and one FSK channel with data rate up to 50 kb/s [185].

LoRa technology transceivers support 6 spreading factors (SF7 to SF12) corresponding to

different bandwidth options (SF7 being the best and SF12 the worse). The choice of SF is

dependent on the channel signal-to-noise ratio, the link budget and range [186].

In modelling an LPWA network, the IMST iC880A module [14] is adopted as the RF

front-end of a LPWA gateway and a Raspberry Pi [163] as the MCU. The iC880A is based

on Semtech’s SX1301 radio (LoRa technology [179]) which operates on the 868 MHz ISM

frequency band with 10 programmable channel paths. The SX1301 has a line-of-sight

range of up to 15 km but only a few kilometres in an urban environment. Wireless trans-

174 Power Consumption of IoT Access Networks

1

iC880A(Radio Module)

Host(MCU)

Higher data rate

Higher range

234

Base Station (Gateway)

IoT DevicesEthernet

3G/4G/5G

LoRaWANBack-end Servers

Access, Metro & Core Networks

Internet

Figure 6.7: Schematic diagram of a LPWA network structure [14]

mission is achieved via shared medium with uncontrollable characteristics including in-

terference, propagation loss and fading, which influence the link spectral efficiency and

bandwidth, resulting in a range of possible transmission data rates. The iC880A therefore

employs ”Dynamic Data Rate Adaptation” to achieve a channel data throughput range

from 0.3 kb/s, for IoT devices in ”difficult” locations, and up to 6 kb/s (for a good chan-

nel) is achievable by IoT devices closer to the gateway [14]. We assume all 8 channels

are programmed as LoRa channels, assuming SF7 for good channels with the maximum

per-channel bit rate of 6 kb/s. The combined maximum data-rate of the gateway for 8

channel paths simultaneously occupied by nodes close to the gateway is 48 kb/s, pro-

vided that propagation conditions are favourable.

Let’s consider a single LPWA modem embedded with a sensor or actuator (i.e. IoT de-

vice) that communicates with one LPWA gateway as shown in Figure 6.8. The IoT device

’a’ transmits with a data-rate ra,j , where device ’a’ belongs to an IoT service j (e.g. an

agricultural installation with sensors measuring soil moisture). IoT service j can have

many IoT devices within its IDN, such that a = 1, 2, ..., A. Similarly, the LPWA gate-

way can communicate with many IDNs, with each IDN belonging to an IoT service j,

for j = 1, 2, ..., J . The LPWA gateway contains a radio module with a total of K chan-

nels (where K = 8 for the iC880A radio module). Each channel k (where k = 1, 2, ...,K)

communicates with a single IoT device ’a’ from an IoT service j at any given time.

The aggregate data-rate of the IoT service j is then given asRLPWA,j(t) =∑Aj

a=1 ra,j(t).

6.6 Estimating the Power Consumption of Network Elements 175

Assuming the IoT devices transmits at the same bit rate, then the effective data-rate of the

service RLPWA,j = Aj × ra,j .

Raspberry Pi

Mo

d/D

emo

d(R

adio

)

SPI

SPI

Pac

ket

Han

dle

r

1

2

A1

1

2

A2

1

2

AJ

K

1

2

iC880A Radio Module Host (MCU)

r1,1

r2,1

rA,J

Channels

LPWA Gateway

IoT Service 1

IoT Service 2

IoT Service J

LoRa Wireless Link

ToLoRaWAN

Servers

Figure 6.8: Schematic diagram of the internal structure of an LPWA Gateway

If a number of IoT services (where 1 IoT service≡many sensors/actuators≡ 1 owner

/user) with data-rates RLPWA,j connects through the same LPWA gateway, the effective

data-rate of the gateway is given by:

Reff (t) =J∑j=1

K∑k=1

RLPWA,j,k(t) (6.28)

The effective gateway utilization U is then given as:

U =Reff (t)

Rmax=

∑Jj=1

∑Kk=1RLPWA,j,k(t)

Rmax(6.29)

where Rmax is the maximum bit rate of the gateway.

Since LPWA gateways provide wide coverage (up to 15 km for LoRa) and could reach

tens of thousands of IoT devices, which in turn may be part of hundreds of unique IDNs

owned by many users, the gateway is deemed as a ”highly shared” network element.

From Figure 6.7, it is shown that the gateway includes a Raspberry Pi which, from mea-

surements in Chapter 5, exhibits slight linear load-dependence similar to network ele-

ments described in [96]. Furthermore, current consumption characteristics of the IMST

176 Power Consumption of IoT Access Networks

iC880A module (see Figure 6.9) seem to scale linearly with number of channels, provided

the channels are fully utilised. Hence, a multi-user power model is applied for the gate-

way as given in (6.20).

Number of Paths / Channels0 2 4 6 8 10 12

Cur

rent

(m

A)

0

50

100

150

200

250

300

350

400

450

500

linear current (typical)

X: 0Y: 171.3

Figure 6.9: Current consumption characteristics of the iC880A RF module with a supplyvoltage of 5V from datasheet in the blue curve and the dash lines are an extrapolation ofthe datasheets values.

In the modelling of an LPWA access network (see Fig 6.1), the IoT device’s LoRa

transmitter modem, which can be embedded within the IoT device circuitry, is not con-

sidered. The power consumption of an LPWA gateway PL(RLPWA,j) for an IoT service j

with data-rate RLPWA,j is then given as:

PL(RLPWA,j) =

(Pidle∑J

j=1

∑Kk=1RLPWA,j,k

+

(Pmax − Pidle

Rmax

))RLPWA,j (6.30)

where Pidle and Pmax represent the idle and maximum power consumption of the gate-

way.

Current consumption characteristics of the iC880A module [14] is shown in Figure 6.9.

The supply voltage for ”typical” operation is 5 V. Based on Figure 6.9, the idle power

(Pidle) and maximum power (Pmax) consumption of the RF module is calculated as 0.9 W

6.7 Results and Discussion 177

and 2.2 W respectively. From measurements, the Raspberry Pi consumes about 2.2 W.

6.7 Results and Discussion

In this chapter, a first-order estimate of the power consumption of different access tech-

nologies, using information from network element datasheets, and from measurements

where applicable, is constructed. The results presented here are indicative of the current

state-of-the-art but may slightly vary depending on the choice of representative equip-

ment and future equipment energy efficiency improvements.

The power consumption of each network element involved in the transport of IoT

traffic is summed in accordance with (6.1). The graph in Figure 6.10 depicts the power

consumption of all access network technology options considered here for IoT gateway

data access rates between 1 kb/s and 1 Mb/s. In all but one of the architectures (i.e.

LPWA), an IDN is assumed to have an IoT gateway which connects to the Internet core

through either a PON, PtP optical, VDSL2, 4G LTE wireless or Wi-Fi network access.

For LPWA, however, the each sensor of the IDN connects directly to the LPWA gate-

way without an IoT gateway. The results indicate that the power consumption of the

fixed access network technologies is largely dominated by the power consumption of

their respective CPE modems. PON access, compared to VDSL2 and PtP, is relatively

more power efficient amongst the wireline technologies, by virtue of its passive remote

node and effective port sharing regime. Given that the IoT bandwidth requirement is

several orders of magnitude lower as compared to the bandwidth capacity of PtP access,

its power consumption variation is negligible. VDSL2, which uses fibre backhaul from

the remote node, appears to be the least power efficient for sub-1Mb/s data access rates.

This is due to the presence of an active power consuming network element at the remote

node added to the power of a VDSL2 modem.

In the case of 4G LTE wireless technology, the model reflects a range of background

traffic levels as shown in Figure 6.6. Due to high volume of traffic during busy-hours

between 4pm and 10pm (140% daily of average load), the power share attributed to 4G

LTE access is low, but increases greatly after midnight between 2am and 4am (20% of

178 Power Consumption of IoT Access Networks

IoT Data Access Rate (kb/s)100 101 102 103

Pow

er C

onsu

mpt

ion

(Wat

ts)

0

5

10

15

20

25

30

35

40

VDSL2

Unshared Wi-FiPtP

Shared Wi-Fi

LTE (100% of average)

LTE (40% of average)

LTE (20% of average)

PON

LPWA

Figure 6.10: Power consumption per IoT gateway for different access network technolo-gies. For LTE, power consumption varies according to the share of BS power consump-tion attributable to the background traffic.

daily average load) as the volume of background traffic drops. For IoT services using

4G LTE access, the power consumption apportioned to IoT traffic for the low, medium

and high background traffic volume is depicted in Figure 6.10. Power consumption of

4G LTE below 10 kb/s is relatively independent of traffic level due to the dominance of

the customer modem and gateway power consumption but increases beyond 10 kb/s.

The relative difference in power consumption between the low background traffic (20%

of daily average load) scenario and that of the high background traffic (100% of daily

average load) can be explained by the cost of sharing the idle power of a macro cell

base station between a small number of users/gateways. In the future, as the move to

5G networks with small cells and Narrow-Band IoT provisioning becomes a reality, a

situation like this will not apply due to low-powered small cells and improved resource

allocation for small packets as an example.

At higher IoT traffic levels and lower 4G LTE utilisation, IoT service via VDSL2 and

6.7 Results and Discussion 179

4G LTE consume similar amounts of power and there is no distinct power advantage

of one over the other. In contrast, at very low data rates, 4G LTE has a distinct power

advantage over any of the wireline technologies.

The difference between unshared Wi-Fi deployment with a single user and shared Wi-

Fi with many users is substantial. Although a shared Wi-Fi deployment may operate at

higher total traffic rates and consume more power, the sharing strategy ensures a very

small per-gateway or per-user power footprint. For higher IoT traffic levels the curve for

shared Wi-Fi in Figure 6.10 shows a slight increment in power as the per-bit power share

increases.

For low IoT traffic levels, LPWA appears to be the most power efficient of the wireless

and wireline access network technologies combined. This arises because it is optimised

for very low traffic levels, i.e. low data rate and infrequent transmissions. LPWA has a

distinct power advantage over shared Wi-Fi but for low data access rates (≤ 10 kb/s).

IoT Data Access Rate (kb/s)100 101 102 103

Ene

rgy

Effi

cien

cy in

ene

rgy-

per-

bit (

J/bi

t)

10-6

10-5

10-4

10-3

10-2

10-1

Unshared Wi-FiShared Wi-FiPONPtPVDSL2LTE (20% of average)LTE (40% of average)LTE (100% of average)LPWA

LTE (100% of average)

Shared Wi-Fi

LTE (40% of average)

LTE (20% of average)LPWA

VDSL2PtP

PON

Unshared Wi-Fi

Figure 6.11: Energy efficiency of different IoT access network technologies

180 Power Consumption of IoT Access Networks

The graph in Figure 6.11 shows the energy-per-bit of the different access technologies

considering sub-1 Mb/s IoT data access rates. It further reinforces the results presented in

Figure 6.10. From Figure 6.11, the energy-per-bit decreases sharply for all access technolo-

gies with increase in data access rate. More generally, it is seen that 4G LTE can provide

an energy efficient access technology for IoT services under conditions of low IoT data-

rate and a well utilised base station. Under these circumstances, 4G LTE will likely be

more energy efficient than most of the wireline access technologies. In particular, VDSL2,

which uses a powered remote node, is very likely to be the least energy efficient access

technology for IoT. LPWA is specifically designed for low power and is the most energy

efficient but only applicable for low data access rates. Shared Wi-Fi has the advantage

of being both shared and using a low power wireless technology for limited coverage,

which makes it the most energy efficient access technology for a wide range of IoT access

rates considered here.

6.8 Potential Power Savings with Sleep-mode

In Figure 6.10, the power consumption of the wireline access network technologies is

seen to be dominated (more than 64% in VDSL2 and PON) by the idle power of the

customer premises equipment (i.e. modem, ONU and IoT gateway). This presents an

opportunity for substantial power savings if automated sleep-mode techniques [187] are

applied. Although many IoT services may require round the clock network access, unlike

some user applications and services which may require access only during certain hours

of the day when users are active (e.g. Email, Facebook, etc...), potential energy savings

could be made by implementing micro sleep modes (i.e. Dozing, Fast Sleep, Deep Sleep),

Wake-on-LAN and other advanced techniques [118].

In calculating the power consumption of an LTE access network, the ’active’ power

state for the 4G LTE modem and the ONU is used in order to present upper-bound power

values as some IoT services may require continuous network access. As can be seen from

Figure 6.4, the 4G modem has three power states: active, idle and standby. The standby

state consumes about 4-5 fold less energy than the active state, essentially demonstrating

6.9 Conclusion 181

a sleep-mode implementation. The observed difference in power seems congruent with

the EUCoC. Hence, if an IoT service with a 10% uplink duty cycle between bursts with

lower bit rates is considered, energy savings of more than 75% could be realised for the

4G LTE modem and more than 35% for the ONU. The LTE power level curves in Figure

6.10 will also change if macro base station hibernation becomes a reality.

6.9 Conclusion

In this chapter, the development of a power consumption model that provides a first-

order estimate of the power consumption per IoT gateway for sub-1 Mb/s data access

rates is given. The results indicate that the power per IoT gateway for wireline access

technologies is dominated by their CPE modems for the access rates under the consider-

ation for IoT services. LTE models might change when small cells are implemented with

the 5G revolution. VDSL2 is seen as the least energy efficient for most of the assessed data

throughput range, while 4G LTE is seen as least energy efficient above several hundred

kilobits/second, depending on the traffic volume and time of day. Among the wireline

access technologies, PON is relatively energy efficient for the full range of IoT access rate

while LPWA, among the wireless access technologies, is more energy efficient but appro-

priate only for a smaller range of access rates. Shared Wi-Fi access with PON backhaul is

overall most energy efficient access technology for medium to higher data access rates,

provided that the shared Wi-Fi also carries a modest level of background traffic. For lower

access rates, there is no clear power advantage of 4G LTE over shared Wi-Fi where both

are available, but a marked difference for higher access rates as the share of total traffic

allocated to the IoT becomes significant in comparison with the cell background traffic.

The dominance of power consumption by the modems provides an opportunity for

significant power savings with the implementation of sleep-mode regimes and duty cycle

optimisation. Whilst the inefficiencies of some network architectures relative to others is

shown here, the choice of an IoT access technology will ultimately depend on the type of

application, the rate of data generation and the cost of deployment. Wireless access has

a significant advantage of being ubiquitous today and easy to augment once deployed;

182 Power Consumption of IoT Access Networks

hence LPWA may be a good choice for IoT applications with low data throughput de-

mands. However, shared Wi-Fi could be a better choice if an IoT application throughput

demand is high.

Chapter 7

Conclusions and Future ResearchDirections

THIS chapter summarizes the key contributions and findings of this thesis on the

energy consumption of Internet of Things (IoT) networks and services. The chapter

further discusses potential future research directions of this work.

7.1 Conclusions and Discussion

The IoT is a new paradigm of interconnectivity that extends the traditional Internet to

non-network-enabled objects or things and to networks (e.g. SCADA) that were not pre-

viously part of the Internet, with a view to create more accessible end-to-end services.

The IoT leverages a number of established and emerging technologies (i.e. WSN, Cloud

and Fog Computing) to deliver more accessible end-to-end services. While there could

be many benefits (e.g. home security, assisted living, etc.) derived from an IoT ecosys-

tem with billions of devices, such deployment elicits potential risks. These include an

increase in device standby energy consumption to maintain connectivity or perceived

”smartness”, additional network energy cost for handling possible IP traffic increment

due to high-traffic IoT applications (e.g. video surveillance), and the potential impact on

the global energy consumption of the ICT industry as a whole.

In this thesis, the energy consumption of IoT applications, networks and services was

investigated, with primary focus on a few well-known IoT use-cases, home automation

and security systems (HAS) and video surveillance services. Measurement of power con-

sumption and data traffic constituted the basis of our modelling approach; hence a num-

183

184 Conclusions and Future Research Directions

ber of IoT devices and gateway devices were measured. Such measurements of power

consumption, or similar data from other sources where necessary, were used to estimate

the overall energy consumption over time of the IoT devices and services described. The

key contributions of this thesis are as follows:

• New measurement-based energy models were introduced for IoT devices includ-

ing sensors, actuators and IoT gateways, and a shared energy model for the home

gateway device was developed (Chapter 3).

• Using developed energy models, the total energy consumption of HAS was inves-

tigated and estimates of its energy impact on the global ICT industry presented

(Chapter 3).

• New energy consumption measurements of the most common wireless network

communication protocols for IoT devices was presented. Using these measure-

ments in conjunction with an example IoT application, the energy implications of a

number of communication paradigms for IoT devices was analysed (Chapter 4).

• A measurement-based power consumption model for new generation web-based

network IP cameras was introduced (Chapter 5).

• The energy consumption of Local, Edge and Cloud-based network architectures for

IoT video surveillance services was investigated and evaluated for different video

streaming application models (Chapter 5).

• The power consumption of several IoT access network technologies was investi-

gated, modelled and evaluated for IoT-like (sub-1 Mb/s) data access rates (Chap-

ter 6).

These contributions can be broadly categorised into three areas: (i) ”Energy Consump-

tion of IoT Applications and Services”, (ii) ”Energy-Efficiency of IoT Network Architec-

tures” and (iii) ”Energy-Efficiency of IoT Access Network Technologies”. These areas are

discussed in the sections below.

7.1 Conclusions and Discussion 185

7.1.1 Energy Consumption of IoT Applications and Services

In Chapter 3, the total energy consumption of HAS or ”smart homes”, which includes

IoT devices, IoT gateways and smart appliances, was investigated. In order to conduct

this study, a representative example HAS (i.e. Ninja Block) was considered for a ”typical”

mid-size home. We carried out power consumption and traffic measurements of a variety

of devices including the following:

Temperature & Humidity Sensor (×2)(i) Passive Infrared Sensor(ii)

Door Sensor(iii) Window Sensor(iv)

Power plug Actuator(v) Logitech USB Webcam (×2)(vi)

Network IP camera(vii) Ninja Block IoT gateway(viii)

Raspberry Pi (IoT gateway)(ix) BeagleBone Black (IoT gateway)(x)

Belkin Router (home gateway)(xi) Billion ADSL2+ Modem (home gateway)(xii)

We studied their characteristics, functionalities and operational modes. Then, energy

models for the devices were developed. Assuming reasonable profiles of device opera-

tion during a diurnal cycle, the annual energy consumption of a HAS was calculated to

be as high as 35% of the average annual energy consumption of a typical mid-size home.

This figure would be higher if all of the IoT devices considered in this work were de-

signed with connection-oriented wireless communication interfaces, which were shown

in Chapter 4 to consume much higher energy than their connectionless counterparts.

Smart LED bulbs were found to be the least energy-efficient of the devices considered

and therefore should be the prime target for smarter designs by IoT developers.

Chapter 3 also described the total energy consumption of HAS and its potential con-

tribution to the global ICT energy consumption. To conduct this study, we adopted

three different usage scenarios for HAS deployment, based on consumer market research.

Drawing from recent market-based IoT device shipment forecasts, our estimates showed

that the additional energy consumption to the global ICT industry can be between 57

TWh and 156 TWh by 2025. The wide range of this estimate is in congruence with to-

day’s market estimates, and indicative of the market forecast uncertainties associated

186 Conclusions and Future Research Directions

with IoT HAS adoption. This estimate shows that for one of many IoT application use-

cases, the potential additional energy consumption is a non-trivial value and that careful

consideration must be given to improving the energy efficiency of IoT devices (e.g. very

low standby energy and duty-cycle) and their enabling technologies if the total energy

consumption of the IoT eco-system is to be minimised. Our study does not account for

embedded energy of possibly billions of batteries and their potential environmental foot-

print.

Chapter 4 investigated the energy consumption of representative circuit modules im-

plementing five popular wireless communication protocols (i.e. BT, BLE, ZigBee, Wi-Fi

and RF433) that are commonly used for the design and development of IoT devices and

deployment of IoT applications. Consumer-off-the-shelf (COTS) RF modules for the five

communications protocols were obtained for the study. To determine the energy con-

sumed by these modules, we measured the power consumption in various operational

states (i.e. sleep, standby/idle, active-Tx/Rx). To further investigate the energy usage

of the RF modules in different scenarios, we considered their operation using three (3)

communications paradigms, Broadcast, Polling and Event-driven. A comparative study of

the wireless protocols was then conducted using a domestic stock-control IoT application

over a designated period of time. Generally, BLE emerged as the most energy-efficient

option for all but one communication paradigm (i.e. Polling), where ZigBee was most ef-

ficient due to its reverse polling capability. Wi-Fi was the least efficient across the board.

Our results further indicate that, for the most energy-efficient communication paradigm,

the choice of wireless interface is highly dependent on the frequency of transmission and

volume of traffic transmitted through the interface.

The results in Chapter 4 further suggest that for an IoT developer, in designing an IoT

application, the level of traffic (including management and possible keep-alive mech-

anisms) associated with said application should be carefully considered in selecting a

communication paradigm, choosing one only when it becomes more efficient to do so.

On the choice of wireless interface, our result outcomes suggest that, while the popu-

lar COTS modules may be least-costly, benefiting from economies of scale, they may not

necessarily be the most energy-efficient option, as in the case of BT and Wi-Fi. Although

7.1 Conclusions and Discussion 187

there may be a compelling reason for adopting a technology that is sub-optimal in its en-

ergy consumption, the decision should at least be made in an informed manner. Hence,

there is a trade-off between cost and energy efficiency. A design approach that balances

the two parameters would be most desirable.

7.1.2 Energy-Efficient IoT Network Architecture

In Chapter 5, the energy efficiency of Local, Edge and Cloud-based network architectures

for IoT video surveillance services was studied; Local and Edge-based architectures are

part of Fog computing. In all, four (4) different network architectures were investigated,

considering their related energy consumption for video streaming, storage and process-

ing. In order to conduct this study, we developed new energy models for the network

architectures in question. For representing network elements, a combination of energy

modelling and measurement (where applicable) approach was adopted. We evaluated

typical use-case scenarios (i.e. live streaming, on-demand streaming, etc.).

We first obtained and measured the power consumption of a representative new gen-

eration network IP camera (IPcam) in its various operational states, while varying its

functional parameters (i.e. video frame size, frame rate and video bit rate). A measurement-

based power model which expressed the power consumption of the new generation net-

work IPcam as a function of video parameters such as frame rate, video bit rate and pixel

rate, was presented. The measurements reveal substantial linearity between the power

consumption of the IPcam and video pixel rate, albeit with a baseline power of more than

90% of its total power. This model can be applicable to other new generation IPcams (e.g.

Arlo, Nest Cam).

In order to compare the energy consumption of the network architectures, the live

and on-demand streaming use-case scenarios were employed. For the case of a user

live streaming from an IoT video surveillance service, the analysis indicates the local

(direct) access architecture to be the most energy-efficient for practical use (i.e. outside

the local network) and the cloud-based architecture the least energy-efficient (by more

than a factor 2). For IoT application developers, a good design should avoid the routing

of video streams via an Edge Data Centre (eDC) or Cloud Data Centre (cDC) if video

188 Conclusions and Future Research Directions

storage is not a requirement. This can lead to energy savings in the transport network,

more so in the data centres (DC), while also conserving critical DC resources.

For the case of on-demand streaming, the analysis shows local access architecture as

a more energy-efficient option by a much larger margin when compared to edge-based

(more than 2-times) or cloud-based architectures (6-times or more).

A different picture emerges when the energy cost of storage is factored in, as against

the number of times a stored video file is accessed/downloaded. The results show that

the energy cost to store and read video files locally from an SD card is greater (10 times

more) than the cost of storage in an eDC or cDC. However, local storage leads to lower

transmission energy costs to local user sites. If the number of times a video file is down-

loaded is low to mid-range, then eDC storage enables a lower overall service energy cost.

However, for higher number of download instances, there was no significant difference

between the service energy cost for local versus eDC storage because it is balanced by

higher transmission costs. Therefore, for on-demand storage and streaming, an edge-

based architecture via an eDC is energy efficient indeed over a wide range of download

instance numbers (low to high), and brings with it the possibility of improved reliability.

In an effort to maximise energy savings, our results presented in Chapter 5 may help:

• Users in making informed decisions on an energy-efficient choice of storage for

their IoT video surveillance systems, provided storage volume limitation is not the

priority.

• IoT developers in opting for an energy-efficient architecture for hosting IoT video

services.

Where data protection, redundancy and reliability are of higher priority, an edge-based

architecture for on-demand streaming is the optimal option.

For video processing, the absence of specific processing energy models in the litera-

ture necessitated a slightly different approach. Instead of one-to-one comparison of the

total energy consumption of the different architectures, an approach that compares lo-

cal video frame processing against the energy cost of transport and storage of the same

video frames to an eDC or cDC was adopted. A computationally-intensive face detection

7.1 Conclusions and Discussion 189

and recognition application was used as a case study. Our analysis reveals that, for very

low (few tens) number of detection operation instances per day, remote processing at a

DC lowers the service energy footprint. This is explained by the lower transport energy

costs due to fewer transmissions and the more energy-efficient DC storage facilities. For

medium to high number of detection operation instances, however, the combined en-

ergy consumption for transmitting video frames across the network and storage of those

frames at the DC facility quickly exceeds the local storage and processing energy.

Therefore, for a low usage scenario (e.g. home setting) it may be more energy-efficient

to run video data processing in an eDC, which also comes with benefits of reliability

and scale for more computationally-intensive applications. Further energy savings can

be made by employing higher video compression algorithms, which could reduce video

data traffic and in-turn its transport energy consumption. Where processing performance

is not compromised by high workloads, however, our result suggests that it is almost

always more energy-efficient to perform video processing locally.

7.1.3 Energy-Efficient IoT Access Network Technologies

In Chapter 6, we developed power consumption models for a range of wireline and wire-

less access network technologies that can be considered enablers of the IoT. They include

very-high bit rate digital subscriber line (VDSL2), passive optical network (PON), point-

to-point optical network (PtP), fourth generation Long Term Evolution (4G LTE) and low

power wide area networks (LPWA). A Wi-Fi access network (Shared and Unshared) us-

ing PON backhaul was also considered. Unshared Wi-Fi access refers to a network dedi-

cated to a single IoT service, while a Shared Wi-Fi access refers to a network serving tens

to hundreds of IoT services. The models were then used to present first-order estimates

of the power per IoT gateway for these technologies considering IoT-like data access rates

(sub-1 Mb/s).

The analysis showed that the power per IoT gateway for wireline access technologies

is dominated by the consumption of their CPE modems. VDSL2 (the only copper-based

technology considered) is least efficient for most of the evaluated data access rates while

4G LTE is least efficient for higher data rates. PON is seen as the most energy-efficient

190 Conclusions and Future Research Directions

wireline technology, while LPWA is the most energy-efficient wireless technology but

only for very low access rates (< 30 kb/s). Shared Wi-Fi with PON backhaul, however,

is able to achieve the greatest energy efficiency for almost the entire span of access data

rates studied, due to its capacity sharing regime amongst many users and services. The

continued dominance of the power consumption of CPE modems shown in our result

presents an opportunity for significant power savings with advanced sleep-mode tech-

niques and duty-cycle optimisation.

7.2 Future Research Directions

This section discusses some future research directions in the area of energy consumption

of IoT networks and services.

In this thesis, we identified a non-exhaustive list of IoT use-cases including HAS, Con-

nected Building, Smart Grid, Smart Cities, Smart Business, E-Health (e.g. Wearables), etc.

While many of these are developmentally in the embryonic stage, a few are becoming

mainstream today with systems readily available off-the-shelf; HAS is one such exam-

ple and probably the most well-known. In this thesis, we investigated the total energy

consumption of the HAS application use-case and estimated its potential global energy

footprint. An analysis of the energy consumption and implications of other mainstream

IoT application use-cases (e.g. E-Health, Smart Business) are yet to be fully studied.

It is common knowledge within the research community that IoT networks pose

unique privacy and security concerns. Implementing adequate security protocols or

techniques can be energy-intensive. In estimating the energy consumption of HAS, the

sensor and actuator devices within the HAS package were largely battery-powered and

employed connectionless communication techniques with little or no security appara-

tus. Additionally, our results suggest potentially significant energy savings if battery-

powered sensor devices are adopted instead of their mains-powered counterparts. One

caveat is the exclusion of the embedded energy of batteries in the study. Another is the

expectation of more efficient energy usage behaviours driven by usage data with decision

making and control capabilities provided by HAS. Therefore, further research in this area

7.2 Future Research Directions 191

should account for these caveats and incorporate additional energy for security. A com-

plete life cycle assessment of the HAS and other IoT applications would be required to

fully understand the environmental footprint of these services.

The concept of a fog computing-based network architecture is quite broad and gen-

erally includes locating physical or logical computational, storage and networking re-

sources between the cloud and IoT devices. Fog nodes can be attached to a home gate-

way, routers and switches from the access network right up to the core (i.e. a mini DC

attached to a core router). While we have considered a more traditional server-based

fog architecture in this work, there remain open IoT research questions on the energy

consumption and implications of distributed computing architecture models when fully

deployed. Furthermore, the energy efficiency of interactive IoT applications and services

that demand distributed computing resources requires further investigation. It is also

unclear what influence the move towards Software Defined Networking (SDN) and Net-

work Function Virtualization (NFV) may have on the energy efficiency of IoT network

architectures, which merits further studies.

Appendix A

Ninja Block Home Automation &Security (HAS) System

A.1 Description of the Ninja Block HAS System

The Ninja Block home automation system (NB) comprises a gateway unit, wireless sen-

sors and actuators, and subscription to a cloud service and mobile application for control

and management of connected end-devices. It uses the ISM band 433 MHz for wireless

communication with end-devices. The NB gateway unit contains a BeagleBone Black

(BBB) main processor and a custom Arduino microcomputer daughter board known as

the Arduino Cape. The BBB is a low-power consumption, single board microcomputer

featuring 512 MB RAM, an AM335x 1 GHz ARM Cortex-A8 processor and provides con-

nectivity via mini HDMI, Ethernet, USB 2.0 and Wi-Fi (with a USB Wi-Fi dongle).

In the NB system, the BBB serves to connect to the host application on the cloud

service via the HGW, and controls communication with the sensors and actuators. The

Arduino daughter board contains a 433 MHz transmitter and receiver interface through

which wireless communications with 433 MHz enabled IoT devices is achieved. As

shown in Figure A.1, the BBB interfaces directly with an Arduino daughter board which

manages traffic to and from the sensors and actuators [15].

On initialisation, the NB gateway establishes communication with any non-proprietary

or non-secured 433 MHz enabled devices within its range using the RC switch protocol

(remote control protocol). However, a device driver is required for sensors and actuators

with proprietary protocols.

193

194 Ninja Block Home Automation & Security (HAS) System

!"#$%

&

!

#$$'(

)*%

Figure A.1: Ninja Block gateway components [15]

The NB system operates on a client-server architecture where the client is the NB

gateway and the server or NB platform is an Amazon EC2 Cloud server. Using Node.js

client API with JavaScript Object Notation (JSON), the client (NB gateway) maintains

an event-driven, non-blocking communication channel with the Ninja Platform via the

HGW or a local area network (LAN). The network architecture of the NB HAS system is

shown in Figure A.2.

Ninja Block

IoT Devices

Internet

Modem

Ninja Block Cloud Service (Amazon Data Centre)

433 MHz, Wi-Fi

Ethernet

Wi-Fi

xDSL, PON, HFC

PC, Laptop, IPad, etc...

Figure A.2: Network architecture of Ninja Block home automation system

A.2 Functional Description and Measurement of Ninja Block End-Devices 195

A.2 Functional Description and Measurement of Ninja Block End-Devices

A.2.1 Temperature and Humidity Sensor

A Clas Ohlson WT450H temperature and humidity (T&H) sensor provides temperature

readings to 1/10th degree resolution and humidity readings of 1% resolution. The T&H

sensor uses a 433.92 MHz transmitter (transmits-only with no receiver) for sending data

with 4 channels. The T&H sensor transmits once a minute with less than 1% duty-cycle

(≈ 500 ms). In the process of 1 complete cycle, the MCU and transmitter module wakes-

up after about 59.5 sec, 3 bursts of a message are sent to the IGW, and the device returns

to its inactive/standby state. Each transmission burst is 36 bits long and includes a 2-bit

channel code, 4-bit area ID code, 7-bit relative humidity value, 15-bit temperature value (8

bits decimal & 7 bits fractional) and a parity bit for data integrity check. An extra two re-

transmissions are made as a reliability mechanism in the absence of a more sophisticated

connection-oriented protocol. A further example of a T&H sensor branded ASCOT, but

PSEN

tSEN

PMCU

PTx

tTx

tMCU

Figure A.3: Power consumption trace of a Clas Ohlson temperature and humidity sensordevice

196 Ninja Block Home Automation & Security (HAS) System

tTx

PTx

PMCU

tMCU

Figure A.4: Power consumption trace of an Ascot temperature and humidity sensor de-vice

not compatible with the NB was obtained for measurement. Figure A.3 and A.4 show the

operational power trace of the Clas Olson and an Ascot T&H sensor devices.

A.2.2 Passive Infrared Sensor (PIR)

The Passive Infrared (PIR) or motion sensor device includes an infrared detector, a micro-

controller unit and a 433 MHz transmitter. With an operating voltage of 9-12 V DC, it can

detect motion (an event) from 5-8 m within its line of sight at a horizontal and vertical

angle of 110 and 60 degrees respectively. A 25 bit (24 address bits, 1 sync bit) data stream

is triggered only when its IR background changes. Using the remote control switching

protocol, a unique code-word (i.e. address of PIR Sensor) is transmitted twice (reliability

mechanism) over a 433 MHz channel. Excessive re-triggering due to the same motion can

be prevented by a lockout time using a time-delay switch. Lockout times of 5 seconds,

50 seconds and 5 minutes are selectable. Figure A.5 shows a power consumption plot of

PIR sensor device during normal operation.

A.2 Functional Description and Measurement of Ninja Block End-Devices 197

Event

tTx

Lockout Time

Figure A.5: Power consumption plot of a 433 MHz passive-infrared sensor device with a5 seconds lockout time.

Event

Lockout Time

tTx

Figure A.6: Power consumption plot of a 433 MHz passive-infrared sensor device with a50 seconds lockout time.

A.2.3 Door or Window Sensor

A wireless 433 MHz Door and Window (D&W) sensor device is considered here. The

D&W sensor device comprises of a Reed switch, a MCU and a 433 MHz radio transmitter

198 Ninja Block Home Automation & Security (HAS) System

(i.e. no receiver) as a unit, with an external magnet used as a trigger. Its trigger mecha-

nism operates when the reed switch is opened (for normally closed switch) or closed (for

normally opened switch) when the magnet moves away from the sensor unit. The device

has an operating voltage of 8.4-12 V DC and a transmit frequency of 433±0.2 MHz. Sim-

ilar to the PIR sensor, the D&W sensor employs the remote control switching protocol to

transmit a 25 bits message burst (i.e. a unique address code-word of the sensor). Figure

A.7 shows a power plot of a D&W sensor device during normal operation. When trig-

gered the D&W sensors squawks out 14 bursts of message as can be seen from the figure.

There is no receiver in its communication circuit, hence no acknowledgement message

post transmit.

Event

Sensing

tTx

PTx

Figure A.7: Power consumption trace of an 433 MHz door/window sensor device

A.2.4 Actuator Device

An example actuator device that operates with the NB system is the Watts Clever remote

control socket. The controlled socket is a wireless 230V power socket that can be used

to remotely turn on or off household appliances via the Internet. It includes a 433 MHz

A.2 Functional Description and Measurement of Ninja Block End-Devices 199

wireless receiver which facilitates the actuation of a relay, opening or closing the power

circuit. The controlled socket has a typical line-of-sight range of 20 m; actual achievable

ranges of 10 m or less is a practical limit for non-ideal radio conditions. As with the PIR

sensor, the controlled socket uses the non-standard RC switching protocol with a 24 bits

data stream received for every switch cycle. While all 24 bits represent the address space

for a 433 MHz PIR sensor, the controlled socket uses only 16 bits for device addressing

and 8 bits for data. The 8 bits data block forms a 2-state switching message for turning

the device ”ON” or ”OFF”. Figure A.8 shows a power plot of a Watts Clever controlled

AC socket in its ON/OFF no-load states.

Figure A.8: Power consumption plot of a Watts Clever controlled socket in ON/OFFno-load states.

A.2.5 RF 433 MHz Transmitter and Receiver Modules

The plots in Figure A.9 and A.10 show the power consumption trace of an operational

RF 433 MHz transmitter and receiver module respectively.

200 Ninja Block Home Automation & Security (HAS) System

tTx

PTx

Figure A.9: Power consumption trace of an RF 433 MHz transmitter module sending 10bytes of data.

PRx

tRx

Figure A.10: Power consumption trace of an RF 433 MHz receiver module receiving data.

Appendix B

DC Power Meter Design

B.1 Description of the DC Power Meter Design

This Appendix describes the test instrument designed and built by Robert Ayre to fa-

cilitate measurements of the power consumption of various IoT sensors as a function of

time. The candidate made no contribution to the circuit design. The candidate did how-

ever adapt and extend the embedded measurement software as necessary to perform

different types of measurements.

The current consumption of several of the IoT devices used in this study is charac-

terised by a high peak-to-average ratio, with a low idle current drain and intermittent

short bursts of current as high as 2-3 orders of magnitude greater. At the time work

commenced on this project, it was not possible to procure instruments suitable for mea-

suring such currents at the measurement speed required. Thus the energy consumption

measurements on the IoT modules reported here were made with instruments designed

in-house, both to supply power to the modules and to record voltage, current, and power

consumption for the modules being tested. For some of the modules, the ability to record

rapidly-changing consumption values was required.

Several such instruments were constructed, in order to test modules with different

current and voltage demands. Instruments for use with temperature and humidity sen-

sors for example were required to measure short-duration current peaks superimposed

on a microamp-level background current 100-fold below the peak. These instruments

operated with 3V and 9V modules drawing milliamp level peak currents. Instruments

for use with USB devices such as 3G/ 4G wireless transceivers or gateway devices pro-

201

202 DC Power Meter Design

vided 5V to the test modules and were optimised for either low current (up to ≈ 400

mA) or high current (up to ≈ 1A) modules. Each instrument included an LCD display

of measurement results and a USB-serial connection to a laptop computer used for data

logging. When the LCD display was in use and full reporting of voltage, current and

module power was selected, the achievable measurement interval was of the order of

5 ms. With different variants of the instrument driver software, measurement intervals

as short as ≈1 ms could be achieved if the LCD was disabled, and only the test module

operating current was being reported to the logging computer.

Figure B.1 below shows the functional blocks within the instruments used for USB

device measurements, these being the most complex of those made. However all of the

Figure B.1: Block diagram of custom power supply and power meter (USB version)

instruments constructed used the same circuit architecture, with component values to

suit the specific application. The key components in the instrument include:

• A power supply, typically a 12V mains-power pack.

• An Arduino Leonardo microcomputer, including A/D converters for measurement,

LCD display drivers, and USB-serial port for data and for programming.

B.1 Description of the DC Power Meter Design 203

• The LCD Display.

• A current sense resistor to measure the module’s current draw.

• A power supply circuit to provide the test module’s required voltage to its termi-

nals regardless of the voltage dropped across the current sense resistor.

• Voltage references for the measurements (A/D converters in the Arduino micro-

processor) and for the test IoT device power.

In the case of the USB modules, the cable connecting the module’s host computer was

interrupted, as shown. The USB uplink and downlink signal wires in the cable were

simply passed through. A current sensing resistor was interposed in the USB device

ground path, and the USB power (which would ordinarily be supplied from the USB

host) was replaced by power sourced from the measurement instrument as shown.

For IoT devices such as the temperature/humidity sensor, there was of course no USB

host or connection; the testing instrument simply replaced the battery ordinarily used

by the device. The main functions within instrument are implemented by the Arduino

microcomputer; making measurements, driving the LCD display, and reporting results to

the data logging computer. In instances when short measurement times were not critical,

signal averaging was also employed. Most variants of the instrument used the Arduino

Leonardo with a 10-bit A/D converter; one using a more powerful Arduino with 12-

bit A/D converter was constructed late in the project but not used in the measurements

reported here.

The voltage developed across the current sensing resistor was passed through a buffer

amplifier and measured at one of the Arduino microprocessor ADC ports. That buffered

voltage was added to a reference voltage to provide the constant supply voltage to the

IoT device, compensated for the voltage developed across the current sense resistor. A

difference amplifier enabled this IoT device supply voltage to be measured by the micro-

processor.

The current sensing resistor was selected to ensure that the signal representing the

peak current drawn by the IoT device occupied some 80% of the ADC dynamic range.

The calibration of each unit was confirmed by measurement of DC currents and voltages

204 DC Power Meter Design

against a precision meter available at the University. These calibrations were made at

a level of 50% of the dynamic range for current, and at the designed IoT device supply

voltage. Accounting for offset voltages in the operational amplifiers used, the maximum

errors in voltage measurement are estimated to be 1%. For current measurements, the

maximum error is also estimated to be 1% at the intended peak current, rising to 3% at

a reduced current level of 5% of the device peak current.

Bibliography

[1] ITU, “ITU Internet Reports 2005: The Internet of Things,” International Telecom-

munication Union (ITU), Geneva, ITU Report 27441, November 2005.

[2] D. Evans, “The internet of things: How the next evolution of the internet is chang-

ing everything,” CISCO white paper, vol. 1, no. 2011, pp. 1–11, 2011.

[3] A. Research, “More Than 30 Billion Devices Will Wirelessly Connect to the Inter-

net of Everything in 2020,” [Online]. Available: https://www.abiresearch.com/

press/more-than-30-billion-devices-will-wirelessly-conne/, [Accessed: 9 Novem-

ber 2016].

[4] L. Ericsson, “More than 50 billion connected devices,” White Paper, 2011.

[5] D. Lund, C. MacGillivray, V. Turner, and M. Morales, “Worldwide and Regional

Internet of Things (IoT) 2014–2020 Forecast: A Virtuous Circle of Proven Value and

Demand,” [Online]. Available: http://branden.biz/wp-content/uploads/2017/

06/IoT-worldwide regional 2014-2020-forecast.pdf, 2014.

[6] Intel, “Infograph.” [Online]. Available: http://www.intel.com/content/www/

us/en/internet-of-things/infographics/guide-to-iot.html

[7] J. Baliga, R. W. A. Ayre, K. Hinton, and R. S. Tucker, “Green cloud computing:

Balancing energy in processing, storage, and transport,” Proceedings of the IEEE,

vol. 99, no. 1, pp. 149–167, Jan 2011.

[8] IX Australia, “ISP Peering Traffic,” [Online]. Available: http://monitor.nsw.ix.asn.

au/cacti/graph view.php, [Accessed: 24 March 2017].

205

206 BIBLIOGRAPHY

[9] Billion BiPAC 7800NL ADSL2+ Modem Router, [Online]. Available:

http://au.billion.com/downloads/datasheet/wireless/BiPAC%207800NL%

20datasheet %200506.pdf, [Accessed: 25 February 2017].

[10] A. Lytkin, IP Video Surveillance. An Essential Guide., 2012, isbn 978-5-600-00033-9.

[11] F. Nilsson et al., Intelligent network video: Understanding modern video surveillance

systems. CRC Press, 2009.

[12] M. J. Yang, J. Y. Tham, D. Wu, and K. H. Goh, “Cost effective IP camera for video

surveillance,” in 2009 4th IEEE Conference on Industrial Electronics and Applications,

May 2009, pp. 2432–2435.

[13] O. Blume, A. Ambrosy, M. Wilhelm, and U. Barth, “Energy Efficiency of LTE Net-

works Under Traffic Loads of 2020,” in Wireless Communication Systems (ISWCS

2013), Proceedings of the Tenth International Symposium on. VDE, 2013, pp. 1–5.

[14] IMST, “WiMOD iC880A Module.” [Online]. Available: http:

//www.wireless-solutions.de/images/stories/downloads/Radio\%20Modules/

iC880A/iC880A Datasheet V0 15.pdf

[15] Ninja Block. [Online]. Available: https://www.ninjablocks.com

[16] S. Bluetooth, “Bluetooth Specifications 1.0–3.0+ HS,” 2009.

[17] N. Gupta, Inside Bluetooth low energy. Artech house, 2013.

[18] ZigBee Alliance, “Zigbee Specification,” 2006.

[19] C. Gomez and J. Paradells, “Wireless home automation networks: A survey of ar-

chitectures and technologies,” IEEE Communications Magazine, vol. 48, no. 6, pp.

92–101, June 2010.

[20] E. Perahia and R. Stacey, Next Generation Wireless LANS: 802.11n and 802.11ac.

Cambridge University Press, 2013.

BIBLIOGRAPHY 207

[21] A. J. D. Rathnayaka, V. M. Potdar, and S. J. Kuruppu, “Evaluation of wireless home

automation technologies,” in 5th IEEE International Conference on Digital Ecosystems

and Technologies (IEEE DEST 2011), May 2011, pp. 76–81.

[22] M. Friedli, L. Kaufmann, F. Paganini, and R. Kyburz, “Energy Efficiency of the In-

ternet of Things - Technology and Energy Assessment Report,” International Energy

Agency, vol. 1, 2016.

[23] G. Auer, O. Blume, V. Giannini, I. Godor, M. Imran, Y. Jading, E. Katranaras,

M. Olsson, D. Sabella, P. Skillermark et al., “D2.3: Energy Efficiency Analysis of the

Reference Systems, Areas of Improvements and Target Breakdown,” CORDIS-FP7,

Energy Aware Radio and NeTwork TecHnologies (EARTH) INFSO-ICT-247733

EARTH, 2010. [Online]. Available: http://cordis.europa.eu/docs/projects/cnect/

3/247733/080/deliverables/001-EARTHWP2D23v2.pdf

[24] L. Atzori, A. Iera, and G. Morabito, “The Internet of Things: A Survey,” Computer

Networks, vol. 54, no. 15, pp. 2787–2805, 2010.

[25] J. Gubbi, R. Buyya, S. Marusic, and M. Palaniswami, “Internet of Things (IoT): A

vision, architectural elements, and future directions,” Future Generation Computer

Systems, vol. 29, no. 7, pp. 1645–1660, 2013.

[26] J. Bradley, J. Barbier, and D. Handler, “Embracing the Internet of everything to

capture your share of 14.4 trillion,” White Paper, Cisco, 2013.

[27] H. Jayakumar, K. Lee, W. S. Lee, A. Raha, Y. Kim, and V. Raghunathan, “Powering

the Internet of Things,” in 2014 IEEE/ACM International Symposium on Low Power

Electronics and Design (ISLPED), Aug 2014, pp. 375–380.

[28] Cisco, “The Zettabyte Era - Trends and Analysis,” White Paper, May 2016.

[29] M. Pickavet, W. Vereecken, S. Demeyer, P. Audenaert, B. Vermeulen, C. Develder,

D. Colle, B. Dhoedt, and P. Demeester, “Worldwide energy needs for ICT: The rise

of power-aware networking,” in 2008 2nd International Symposium on Advanced Net-

works and Telecommunication Systems, Dec 2008, pp. 1–3.

208 BIBLIOGRAPHY

[30] M. Webb et al., “Smart 2020: Enabling the low carbon economy in the information

age,” The Climate Group. London, vol. 1, no. 1, pp. 1–1, 2008.

[31] IEA Report, “More Data, Less Energy: Making Network Standby More Efficient in

Billions of Connected Devices,” International Energy Agency, vol. 2, 2014.

[32] A. S. Andrae and T. Edler, “On global electricity usage of communication technol-

ogy: trends to 2030,” Challenges, vol. 6, no. 1, pp. 117–157, 2015.

[33] H. Okkonen, O. Mazhelis, P. Ahokangas, P. Pussinen, M. Rajahonka, R. Siuruainen,

S. Leminen, A. Shveykovskiy, J. Myllykoski, and H. Warma, “Internet-of-things

market, value networks, and business models: state of the art report,” Computer

science and information systems reports. TR, Technical reports, no. 39, 2013.

[34] E. Ferro and F. Potorti, “Bluetooth and Wi-Fi wireless protocols: a survey and a

comparison,” IEEE Wireless Communications, vol. 12, no. 1, pp. 12–26, Feb 2005.

[35] M. Siekkinen, M. Hiienkari, J. K. Nurminen, and J. Nieminen, “How low en-

ergy is bluetooth low energy? Comparative measurements with ZigBee/802.15.4,”

in Wireless Communications and Networking Conference Workshops (WCNCW), 2012

IEEE, April 2012, pp. 232–237.

[36] A. Dementyev, S. Hodges, S. Taylor, and J. Smith, “Power consumption analysis of

Bluetooth Low Energy, ZigBee and ANT sensor nodes in a cyclic sleep scenario,”

in Wireless Symposium (IWS), 2013 IEEE International, April 2013, pp. 1–4.

[37] J. S. Lee, Y. W. Su, and C. C. Shen, “A Comparative Study of Wireless Protocols:

Bluetooth, UWB, ZigBee, and Wi-Fi,” in Industrial Electronics Society, 2007. IECON

2007. 33rd Annual Conference of the IEEE, Nov 2007, pp. 46–51.

[38] K. Mikhaylov, N. Plevritakis, and J. Tervonen, “Performance analysis and compar-

ison of Bluetooth Low Energy with IEEE 802.15.4 and SimpliciTI,” Journal of Sensor

and Actuator Networks, vol. 2, no. 3, pp. 589–613, 2013.

[39] K. Shahzad and B. Oelmann, “A comparative study of in-sensor processing vs. raw

data transmission using ZigBee, BLE and Wi-Fi for data intensive monitoring ap-

BIBLIOGRAPHY 209

plications,” in 2014 11th International Symposium on Wireless Communications Systems

(ISWCS), Aug 2014, pp. 519–524.

[40] J. Baliga, R. Ayre, K. Hinton, W. V. Sorin, and R. S. Tucker, “Energy Consumption in

Optical IP Networks,” Journal of Lightwave Technology, vol. 27, no. 13, pp. 2391–2403,

July 2009.

[41] K. Hinton, J. Baliga, M. Feng, R. Ayre, and R. S. Tucker, “Power Consumption and

Energy Efficiency in the Internet,” Network, IEEE, vol. 25, no. 2, pp. 6–12, 2011.

[42] J. Baliga, R. Ayre, K. Hinton, and R. S. Tucker, “Energy Consumption in Wired

and Wireless Access Networks,” Communications Magazine, IEEE, vol. 49, no. 6, pp.

70–77, 2011.

[43] W. Vereecken, W. Van Heddeghem, M. Deruyck, B. Puype, B. Lannoo, W. Joseph,

D. Colle, L. Martens, and P. Demeester, “Power Consumption in Telecommuni-

cation Networks: Overview and Reduction Strategies,” Communications Magazine,

IEEE, vol. 49, no. 6, pp. 62–69, 2011.

[44] A. M. Efendi, S. Oh, A. F. P. Negara, and D. Choi, “Battery-less 6lowpan-based

wireless home automation by use of energy harvesting,” International Journal of Dis-

tributed Sensor Networks, vol. 2013, 2013.

[45] M. Taneja, “A framework for power saving in IoT networks,” in Advances in Com-

puting, Communications and Informatics (ICACCI, 2014 International Conference on,

Sept 2014, pp. 369–375.

[46] J. Huang, Y. Meng, X. Gong, Y. Liu, and Q. Duan, “A Novel Deployment Scheme for

Green Internet of Things,” IEEE Internet of Things Journal, vol. 1, no. 2, pp. 196–205,

April 2014.

[47] S. P, N. S. V. Shet, and C. K, “Energy efficient network architecture for IoT ap-

plications,” in Green Computing and Internet of Things (ICGCIoT), 2015 International

Conference on, Oct 2015, pp. 784–789.

210 BIBLIOGRAPHY

[48] B. Martinez, M. Monton, I. Vilajosana, and J. D. Prades, “The Power of Mod-

els: Modeling Power Consumption for IoT Devices,” IEEE Sensors Journal, vol. 15,

no. 10, pp. 5777–5789, Oct 2015.

[49] G. Bag, Z. Pang, M. E. Johansson, X. Min, and S. Zhu, “Engineering friendly tool

to estimate battery life of a wireless sensor node,” Journal of Industrial Information

Integration, vol. 4, pp. 8–14, 2016.

[50] V. Konstantakos, A. Chatzigeorgiou, S. Nikolaidis, and T. Laopoulos, “Energy Con-

sumption Estimation in Embedded Systems,” IEEE Transactions on Instrumentation

and Measurement, vol. 57, no. 4, pp. 797–804, April 2008.

[51] C. Gray, R. Ayre, K. Hinton, and R. S. Tucker, “Power consumption of IoT ac-

cess network technologies,” in 2015 IEEE International Conference on Communication

Workshop (ICCW), June 2015, pp. 2818–2823.

[52] A. Kamilaris, Y. Tofis, C. Bekara, A. Pitsillides, and E. Kyriakides, “Integrating web-

enabled energy-aware smart homes to the smart grid,” International Journal On Ad-

vances in Intelligent Systems, vol. 5, no. 1, pp. 15–31, 2012.

[53] Z. T. Al-Azez, A. Q. Lawey, T. E. H. El-Gorashi, and J. M. H. Elmirghani, “Virtual-

ization framework for energy efficient IoT networks,” in Cloud Networking (Cloud-

Net), 2015 IEEE 4th International Conference on, Oct 2015, pp. 74–77.

[54] T. D. Raty, “Survey on Contemporary Remote Surveillance Systems for Public

Safety,” IEEE Transactions on Systems, Man, and Cybernetics, Part C (Applications and

Reviews), vol. 40, no. 5, pp. 493–515, Sept 2010.

[55] Foscam, “1.3 Megapixel HD Wireless IP Camera,” [Online]. Available: https://

www.foscam.com/product/3.html, [Accessed: 05 Aug 2017].

[56] M. Armbrust, A. Fox, R. Griffith, A. D. Joseph, R. Katz, A. Konwinski,

G. Lee, D. Patterson, A. Rabkin, I. Stoica, and M. Zaharia, “A View of Cloud

Computing,” Commun. ACM, vol. 53, no. 4, pp. 50–58, Apr. 2010. [Online].

Available: http://doi.acm.org/10.1145/1721654.1721672

BIBLIOGRAPHY 211

[57] A. Greenberg, J. R. Hamilton, N. Jain, S. Kandula, C. Kim, P. Lahiri, D. A. Maltz,

P. Patel, and S. Sengupta, “VL2: a scalable and flexible data center network,” in

ACM SIGCOMM computer communication review, vol. 39, no. 4. ACM, 2009, pp.

51–62.

[58] M. Kihl, P. Odling, C. Lagerstedt, and A. Aurelius, “Traffic analysis and characteri-

zation of internet user behavior,” in International Congress on Ultra Modern Telecom-

munications and Control Systems, Oct 2010, pp. 224–231.

[59] S. Soro and W. Heinzelman, “A survey of visual sensor networks,” Advances in

multimedia, vol. 2009, 2009.

[60] G. J. Sullivan and T. Wiegand, “Video Compression - From Concepts to the

H.264/AVC Standard,” Proceedings of the IEEE, vol. 93, no. 1, pp. 18–31, Jan 2005.

[61] K. Abas, C. Porto, and K. Obraczka, “Wireless Smart Camera Networks for the

Surveillance of Public Spaces,” Computer, vol. 47, no. 5, pp. 37–44, May 2014.

[62] J. Zhu, S. Liao, and S. Z. Li, “Multicamera Joint Video Synopsis,” IEEE Transactions

on Circuits and Systems for Video Technology, vol. 26, no. 6, pp. 1058–1069, June 2016.

[63] H. Kanzaki, K. Schubert, and N. Bambos, “Video Streaming Schemes for Industrial

IoT,” in 2017 26th International Conference on Computer Communication and Networks

(ICCCN), July 2017, pp. 1–7.

[64] L. Calavia, C. Baladron, J. M. Aguiar, B. Carro, and A. Sanchez-Esguevillas, “A se-

mantic autonomous video surveillance system for dense camera networks in smart

cities,” Sensors, vol. 12, no. 8, pp. 10 407–10 429, 2012.

[65] C. B. Margi, R. Manduchi, and K. Obraczka, “Energy consumption tradeoffs in

visual sensor networks,” in 24th Brazilian Symposium on Computer Networks (SBRC

2006), vol. 1, 2006.

[66] L. Ferrigno, S. Marano, V. Paciello, and A. Pietrosanto, “Balancing computational

and transmission power consumption in wireless image sensor networks,” in IEEE

212 BIBLIOGRAPHY

Symposium on Virtual Environments, Human-Computer Interfaces and Measurement

Systems, July 2005, pp. 6 pp.–.

[67] F. Bonomi, R. Milito, J. Zhu, and S. Addepalli, “Fog computing and its role in the

internet of things,” in Proceedings of the first edition of the MCC workshop on Mobile

cloud computing. ACM, 2012, pp. 13–16.

[68] C. C. Byers, “Architectural Imperatives for Fog Computing: Use Cases, Require-

ments, and Architectural Techniques for Fog-Enabled IoT Networks,” IEEE Com-

munications Magazine, vol. 55, no. 8, pp. 14–20, 2017.

[69] F. Jalali, K. Hinton, R. Ayre, T. Alpcan, and R. S. Tucker, “Fog computing may help

to save energy in cloud computing,” IEEE Journal on Selected Areas in Communica-

tions, vol. 34, no. 5, pp. 1728–1739, May 2016.

[70] K. Hinton, F. Jalali, and A. Matin, “Energy Consumption Modelling of Optical Net-

works,” Photonic Network Communications, vol. 30, no. 1, pp. 4–16, 2015.

[71] D. L. Brock, “The electronic product code (epc),” Auto-ID Center White Paper MIT-

AUTOID-WH-002, 2001.

[72] K. Ashton and S. Sarma, “Introducing the EPC Network,” in EPC Symposium,

Chicago, USA, 2003.

[73] H. Sundmaeker, P. Guillemin, P. Friess, and S. Woelffle, “Vision and challenges for

realising the Internet of Things,” Cluster of European Research Projects on the Internet

of Things, European Commision, 2010.

[74] R. Want, “An introduction to RFID technology,” IEEE Pervasive Computing, vol. 5,

no. 1, pp. 25–33, Jan 2006.

[75] G. Wu, S. Talwar, K. Johnsson, N. Himayat, and K. D. Johnson, “M2M: From mobile

to embedded internet,” IEEE Communications Magazine, vol. 49, no. 4, pp. 36–43,

April 2011.

[76] J. Yick, B. Mukherjee, and D. Ghosal, “Wireless sensor network survey,” Computer

networks, vol. 52, no. 12, pp. 2292–2330, 2008.

BIBLIOGRAPHY 213

[77] R. James et al., “The Internet of Things: A study in Hype, Reality, Disruption, and

Growth,” Raymond James US Research, Technology & Communications, Industry Report,

2014.

[78] Cisco, “The Zettabyte Era - Trends and Analysis,” White Paper, May 2015.

[79] IEEE 802 Working Group and others, “IEEE Standard for Local and Metropoli-

tan Area Networks—Part 15.4: Low-Rate Wireless Personal Area Networks (LR-

WPANs),” IEEE Std, vol. 802, pp. 4–2011, 2011.

[80] C. Reinisch, W. Kastner, G. Neugschwandtner, and W. Granzer, “Wireless Technolo-

gies in Home and Building Automation,” in 2007 5th IEEE International Conference

on Industrial Informatics, vol. 1, June 2007, pp. 93–98.

[81] P. Smith, “Comparisons between low power wireless technologies,” US Patent CS-

213199-AN, 2011.

[82] K. Phaebua, C. Phongcharoenpanich, D. Torrungrueng, and J. Chinrungrueng,

“Short-distance and near-ground signal measurements in a car park of wireless

sensor network system at 433 MHz,” in Electrical Engineering/Electronics, Computer,

Telecommunications and Information Technology, 2008. ECTI-CON 2008. 5th Interna-

tional Conference on, vol. 1. IEEE, 2008, pp. 241–244.

[83] THREADGROUP, “THREAD,” [Online]. Available: https://www.threadgroup.

org/, [Accessed: 22 Mar 2018].

[84] J. Hui, D. Culler, and S. Chakrabarti, “6LoWPAN: Incorporating IEEE 802.15. 4 into

the IP architecture,” IPSO Alliance White Paper, vol. 3, 2009.

[85] G. Song, Y. Zhou, W. Zhang, and A. Song, “A multi-interface gateway architecture

for home automation networks,” IEEE Transactions on Consumer Electronics, vol. 54,

no. 3, pp. 1110–1113, August 2008.

[86] A. Shami, M. Maier, and C. Assi, Broadband access networks. Springer, 2009.

[87] T. Koonen, “Fiber To The Home/Fiber To The Premises: What, Where, and When?”

Proceedings of the IEEE, vol. 94, no. 5, pp. 911–934, 2006.

214 BIBLIOGRAPHY

[88] P.-E. Eriksson and B. Odenhammar, “VDSL2: Next important broadband technol-

ogy,” Ericsson Review, vol. 1, pp. 36–47, 2006.

[89] C.-H. Lee, W. V. Sorin, and B. Y. Kim, “Fiber To The Home Using a PON Infrastruc-

ture,” Journal of Lightwave Technology, vol. 24, no. 12, pp. 4568–4583, 2006.

[90] D. Astely, E. Dahlman, A. Furuskar, Y. Jading, M. Lindstrom, and S. Parkvall, “LTE:

The Evolution of Mobile Broadband,” IEEE Communications Magazine, vol. 47, no. 4,

pp. 44–51, April 2009.

[91] A. Damnjanovic, J. Montojo, Y. Wei, T. Ji, T. Luo, M. Vajapeyam, T. Yoo, O. Song,

and D. Malladi, “A Survey on 3GPP Heterogeneous Networks,” IEEE Wireless Com-

munications, vol. 18, no. 3, pp. 10–21, June 2011.

[92] ETSIGSLTN001, “Low Throughput Networks (LTN); Use Cases for Low Through-

put Networks,” ETSI, France, Tech. Rep. DGS/LTN-001v1.1.1, September 2014.

[93] X. Xiong, K. Zheng, R. Xu, W. Xiang, and P. Chatzimisios, “Low power wide area

machine-to-machine networks: key techniques and prototype,” IEEE Communica-

tions Magazine, vol. 53, no. 9, pp. 64–71, September 2015.

[94] A. Vishwanath, F. Jalali, R. Ayre, T. Alpcan, K. Hinton, and R. Tucker, “Energy

Consumption of Interactive Cloud-Based Document Processing Applications,” in

Communications (ICC), 2013 IEEE International Conference on. IEEE, 2013, pp. 4212–

4216.

[95] A. Vishwanath, K. Hinton, R. W. A. Ayre, and R. S. Tucker, “Modeling Energy Con-

sumption in High-Capacity Routers and Switches,” IEEE Journal on Selected Areas

in Communications, vol. 32, no. 8, pp. 1524–1532, Aug 2014.

[96] P. Mahadevan, P. Sharma, S. Banerjee, and P. Ranganathan, “A Power Benchmark-

ing Framework for Network Devices,” in NETWORKING 2009. Springer, 2009,

pp. 795–808.

BIBLIOGRAPHY 215

[97] C. Batten and T. Wills-Sandford, “The connected home: a reality.” [On-

line]. Available: http://www.intellectuk.org/publications/intellect-reports/

7743-the-connected-home-a-reality-report, 2011.

[98] K. Gill, S. H. Yang, F. Yao, and X. Lu, “A zigbee-based home automation system,”

IEEE Transactions on Consumer Electronics, vol. 55, no. 2, pp. 422–430, May 2009.

[99] A. R. Al-Ali and M. Al-Rousan, “Java-based home automation system,” IEEE Trans-

actions on Consumer Electronics, vol. 50, no. 2, pp. 498–504, May 2004.

[100] M. Soliman, T. Abiodun, T. Hamouda, J. Zhou, and C. H. Lung, “Smart Home:

Integrating Internet of Things with Web Services and Cloud Computing,” in 2013

IEEE 5th International Conference on Cloud Computing Technology and Science, vol. 2,

Dec 2013, pp. 317–320.

[101] X. Ye and J. Huang, “A framework for Cloud-based Smart Home,” in Computer

Science and Network Technology (ICCSNT), 2011 International Conference on, vol. 2,

Dec 2011, pp. 894–897.

[102] L.-J. Kau, B.-L. Dai, C.-S. Chen, and S.-H. Chen, “A cloud network-based power

management technology for smart home systems,” in 2012 IEEE International Con-

ference on Systems, Man, and Cybernetics (SMC). IEEE, 2012, pp. 2527–2532.

[103] SmartThings. [Online]. Available: https://www.smartthings.com

[104] Google, NEST. [Online]. Available: https://www.nest.com

[105] L. C. De Silva, C. Morikawa, and I. M. Petra, “State of the art of smart homes,”

Engineering Applications of Artificial Intelligence, vol. 25, no. 7, pp. 1313–1321, 2012.

[106] N. V. Lopes, F. Pinto, P. Furtado, and J. Silva, “IoT architecture proposal for disabled

people,” in 2014 IEEE 10th International Conference on Wireless and Mobile Computing,

Networking and Communications (WiMob), Oct 2014, pp. 152–158.

[107] M. C. Domingo, “An overview of the Internet of Things for people with disabili-

ties,” Journal of Network and Computer Applications, vol. 35, no. 2, pp. 584–596, 2012.

216 BIBLIOGRAPHY

[108] S. D. T. Kelly, N. K. Suryadevara, and S. C. Mukhopadhyay, “Towards the Imple-

mentation of IoT for Environmental Condition Monitoring in Homes,” IEEE Sensors

Journal, vol. 13, no. 10, pp. 3846–3853, Oct 2013.

[109] V. C. Coroama and L. M. Hilty, “Assessing Internet energy intensity: A review of

methods and results,” Environmental impact assessment review, vol. 45, pp. 63–68,

2014.

[110] R. Pereira and E. G. Pereira, “Video Streaming Considerations for Internet of

Things,” in Future Internet of Things and Cloud (FiCloud), 2014 International Confer-

ence on, Aug 2014, pp. 48–52.

[111] IEEE, “IEEE Approved Draft Standard for Local and metropolitan area net-

works - Part 15.4: Low-Rate Wireless Personal Area Networks (WPANs),” IEEE

P802.15.4REVi/D09, April 2011 (Revision of IEEE Std 802.15.4-2006), pp. 1–311, April

2013.

[112] J. Malmodin and D. Lunden, “The energy and carbon footprint of the global ICT

and E&M sectors 2010–2015,” Sustainability, vol. 10, no. 9, p. 3027, 2018.

[113] F. Tao, Y. Wang, Y. Zuo, H. Yang, and M. Zhang, “Internet of Things in product

life-cycle energy management,” Journal of Industrial Information Integration, vol. 1,

pp. 26 – 39, 2016. [Online]. Available: http://www.sciencedirect.com/science/

article/pii/S2452414X16000030

[114] F. Tao, Y. Zuo, L. D. Xu, L. Lv, and L. Zhang, “Internet of Things and BOM-Based

Life Cycle Assessment of Energy-Saving and Emission-Reduction of Products,”

IEEE Transactions on Industrial Informatics, vol. 10, no. 2, pp. 1252–1261, May 2014.

[115] Q. Wang, M. Hempstead, and W. Yang, “A Realistic Power Consumption Model for

Wireless Sensor Network Devices,” in 2006 3rd Annual IEEE Communications Society

on Sensor and Ad Hoc Communications and Networks, vol. 1, Sept 2006, pp. 286–295.

BIBLIOGRAPHY 217

[116] Clas Olson, “WT450H Temperature Sensor/Hygrometer,” [Online]. Available:

http://www.clasohlson.com/uk/Temperature-Sensor-Hygrometer/36-1797#

moreinfo, [Accessed: 22 November 2016].

[117] F. Kaup, P. Gottschling, and D. Hausheer, “PowerPi: Measuring and modeling the

power consumption of the Raspberry Pi,” in 39th Annual IEEE Conference on Local

Computer Networks, Sept 2014, pp. 236–243.

[118] G. P. Conservation, “ITU-T G-Series Recommendations-Supplement 45 (G.

sup45),” ITU-T, May, 2009.

[119] Australian Bureau of Statistics, “Internet Activity Report, December 2016,”

[Online]. Available: http://www.abs.gov.au/ausstats/[email protected]/mf/8153.0, [Ac-

cessed: 15 May 2017].

[120] LIFX Smart LED Bulbs , [Online]. Available: http://www.lifx.com/, [Accessed: 25

February 2017].

[121] B. Lapillonne, K. Pollier, and N. Samci, “Energy efficiency trends for

households in the EU,” Enerdata, Technical Report, May 2015. [Online].

Available: http://www.odyssee-mure.eu/publications/efficiency-by-sector/

household/household-eu.pdf

[122] P. Bertoldi, “2016 Residential Lighting Report,” Department of Indus-

try, Innovation and Science, Australia, Technical Report, July 2016. [On-

line]. Available: http://www.energyrating.gov.au/sites/new.energyrating/files/

documents/2016-Residential-Lighting-Report-Final.pdf

[123] W. R. Gifford, M. L. Goldberg, P. M. Tanimoto, D. R. Celnicker, and M. E. Poplawski,

“Residential Lighting End-Use Consumption Study: Estimation Framework and

Initial Estimates,” Pacific Northwest National Laboratory (PNNL), Richland, WA

(US), Tech. Rep., 2012.

[124] P. Bertoldi, “Code of Conduct on Energy Consumption of Broadband Equipment

- Version 6.0,” European Commission - DG JRC, Ispra, Technical Report, Febru-

218 BIBLIOGRAPHY

ary 2017. [Online]. Available: http://publications.jrc.ec.europa.eu/repository/

bitstream/JRC108354/kjna28874enn.pdf

[125] Energy Made Easy Comparison, [Online]. Available: https://www.

energymadeeasy.gov.au/benchmark, [Accessed: 25 February 2017].

[126] Gartner, “Gartner Says the Internet of Things Installed Base Will Grow to 26 Bil-

lion Units By 2020,” [Online]. Available: http://www.gartner.com/newsroom/id/

2636073, December 2013, [Accessed: 9 November 2016].

[127] MachinaResearch, “The Need for Low Cost, High Reach, Wide Area

Connectivity for the Internet of Things,” White Paper, 2014. [On-

line]. Available: http://www.neul.com/neul/wp-content/uploads/2014/02/

Neul Machina Research White Paper.pdf[Accessed:4-3-2016]

[128] AEMO, “Generation Information,” [Online]. Available: https://www.aemo.com.

au/Electricity/National-Electricity-Market-NEM/Planning-and-forecasting/

Generation-information, [Accessed: 25 May 2019].

[129] M. K. Weldon, The future X network: a Bell Labs perspective. CRC press, 2016.

[130] K. P. Amutha, C. Sethukkarasi, and R. Pitchiah, “Smart kitchen cabinet for aware

home,” in SMART 2012, The First International Conference on Smart Systems, Devices

and Technologies, 2012, pp. 9–14.

[131] C. F. Hsu, H. Y. M. Liao, P. C. Hsiu, Y. S. Lin, C. S. Shih, T. W. Kuo, and J. W. S. Liu,

“Smart Pantries for Homes,” in 2006 IEEE International Conference on Systems, Man

and Cybernetics, vol. 5, Oct 2006, pp. 4276–4283.

[132] H. Yang, R. Sawhney, G. Zhang, L. Marella, and Z. Han, “Using smart kitchen for

grocery purchase prediction,” in IIE Annual Conference. Proceedings. Institute of

Industrial and Systems Engineers (IISE), 2014, p. 2504.

[133] N. E. Oweis, C. Aracenay, W. George, M. Oweis, H. Soori, and V. Snasel, “Internet

of Things: overview, sources, applications and challenges,” in Proceedings of the

BIBLIOGRAPHY 219

Second International Afro-European Conference for Industrial Advancement AECIA 2015.

Springer, 2016, pp. 57–67.

[134] E. Mackensen, M. Lai, and T. M. Wendt, “Performance analysis of an Bluetooth

Low Energy sensor system,” in 2012 IEEE 1st International Symposium on Wireless

Systems (IDAACS-SWS), Sept 2012, pp. 62–66.

[135] Bluetooth SIG, “Bluetooth core specification version 4.0,” Specification of the Blue-

tooth System, 2010.

[136] E. Perahia and M. X. Gong, “Gigabit wireless LANs: an overview of IEEE 802.11

ac and 802.11 ad,” ACM SIGMOBILE Mobile Computing and Communications Review,

vol. 15, no. 3, pp. 23–33, 2011.

[137] Arduino Duemilanove. [Online]. Available: https://www.arduino.cc/en/Main/

arduinoBoardDuemilanove

[138] Redbear, “BLE Nano v2,” [Online]. Available: https://redbear.cc/product/ble/

ble-nano-2.html, [Accessed: 25 Apr 2018].

[139] DIGI, “XBee & XBee PRO ZigBee,” [Online]. Available: https://www.digi.com/

pdf/ds xbee zigbee.pdf, [Accessed: 22 Jan 2016].

[140] Energiser, “AA Alkaline 1.5V Engineering Data,” [Online]. Available: http://

www.farnell.com/datasheets/104293.pdf, [Accessed: 15 May 2019].

[141] D. K. Corke, Production control in engineering. Arnold London et al., 1987.

[142] Nordic Inc, “nRF52832 Bluetooth Low Energy and 2.4 GHz SoC,” [Online]. Avail-

able: http://infocenter.nordicsemi.com/pdf/nRF52832 PS v1.4.pdf, [Accessed: 25

April 2018].

[143] H. G. Lee and N. Chang, “Energy-aware memory allocation in heterogeneous non-

volatile memory systems,” in Low Power Electronics and Design, 2003. ISLPED ’03.

Proceedings of the 2003 International Symposium on, Aug 2003, pp. 420–423.

[144] J. W. King, “Cisco IP Video Surveillance Design Guide,” Cisco Press, 2009.

220 BIBLIOGRAPHY

[145] NBNCo, “NBN Media Release 2017,” [Online]. Available: http://

www.nbnco.com.au/corporate-information/media-centre/media-releases/

nbn-connected-Aussies-gobble-up-23-per-cent-more-data-per-year-than-the-average-home.

html, [Accessed: 15 May 2017].

[146] IHS Markit, “Top Video Surveillance Trends for 2017,” [Online]. Available: https://

cdn.ihs.com/www/pdf/TEC-Video-Surveillance-Trends.pdf, [Accessed: 12 Nov

2017].

[147] Ambarella, “S2Lm IP Camera Processor ,” [Online]. Available: https://www.

ambarella.com/uploads/docs/S2Lm-Product-Brief-Final.pdf, [Accessed: 25 Jan-

uary 2018].

[148] Power-Mate, “PM10AHDS Power Meter,” [Online]. Available: http://www.c-c-i.

com.au/products/power-meters/power-meters/PM10AHDS, [Accessed: 05 Aug

2017].

[149] Y. O. Sharrab and N. J. Sarhan, “Aggregate power consumption modeling of live

video streaming systems,” in Proceedings of the 4th ACM Multimedia Systems Confer-

ence. ACM, 2013, pp. 60–71.

[150] X. Lu, T. Fernaine, and Y. Wang, “Modelling power consumption of a H.263 video

encoder,” in Circuits and Systems, 2004. ISCAS ’04. Proceedings of the 2004 Interna-

tional Symposium on, vol. 2, May 2004, pp. II–77–80 Vol.2.

[151] L. A. Barroso and U. Holzle, “The Case for Energy-Proportional Computing,” Com-

puter, vol. 40, no. 12, pp. 33–37, Dec 2007.

[152] B. Frank, I. Poese, Y. Lin, G. Smaragdakis, A. Feldmann, B. Maggs, J. Rake, S. Uh-

lig, and R. Weber, “Pushing cdn-isp collaboration to the limit,” ACM SIGCOMM

Computer Communication Review, vol. 43, no. 3, pp. 34–44, 2013.

[153] W. Yoro, M. E. Tabach, T. Ennajjary, A. Gati, and T. Chahed, “Energy efficiency

of a network per service,” in 2017 15th International Symposium on Modeling and

Optimization in Mobile, Ad Hoc, and Wireless Networks (WiOpt), May 2017, pp. 1–5.

BIBLIOGRAPHY 221

[154] Tellabs, “1100 Series Optical Line Terminals.” [Online]. Available: http:

//www.tellabs.com/products/tellabs1100olt.shtml

[155] D. Schien, P. Shabajee, M. Yearworth, and C. Preist, “Modeling and Assessing

Variability in Energy Consumption During the Use Stage of Online Multimedia

Services,” Journal of Industrial Ecology, vol. 17, no. 6, pp. 800–813, 2013. [Online].

Available: http://dx.doi.org/10.1111/jiec.12065

[156] P. Bertoldi, M. Avegerinou, and L. Castellazzi, “Trends in data centre energy

consumption under the European Code of Conduct for Data Centre Energy

Efficiency,” European Commission - DG JRC, Publications Office of the

European Union, Luxembourg, 2017, JRC Technical Report, December 2017.

[Online]. Available: http://publications.jrc.ec.europa.eu/repository/bitstream/

JRC106039/ictcoc-ecbe-v6 feb 2017 final.pdf

[157] PATRIOT, “16GB LX Series microSDHC Card,” [Online]. Available:

https://cdn.shopify.com/s/files/1/2092/4879/files/PSF16GMCSHC10UK