PERCCOM Master Program
Master’s Thesis in
PERvasive Computing & COMmunications for sustainable development
Ngo Manh Khoi
SENSOR COMMUNICATION IN SMART CITIES AND REGIONS: AN EFFICIENT IOT-BASED REMOTE HEALTH
MONITORING SYSTEM
2015
Supervisors: Professor Christer Åhlund- (Luleå University of Technology) Dr. Karan Mitra- (Luleå University of Technology)
Dr. Saguna Saguna- (Luleå University of Technology) Examiners: Professor Eric Rondeau- (Universite de Lorraine)
Professor Jari Porras- (Lappeenranta University of Technology) Associate Professor Karl Andersson- (Luleå University of Technology)
ment.
This thesis has been accepted by partner institutions of the consortium (cf. UDL-DAJ, no1524, 2012 PERCCOM agreement).
Successful defense of this thesis is obligatory for graduation with the following national diplomas:
• Master in Complex Systems Engineering (University of Lorraine);
• Master of Science in Technology (Lappeenranta University of Technology);
• Degree of Master of Science (120 credits) - Major: Computer Science and Engi- neering, Specialisation: Pervasive Computing and Computers for sustainable de- velopment (Luleå University of Technology).
Luleå University of Technology
Department of Computer Science, Electrical and Space Engineering PERCCOM Master Program
Ngo Manh Khoi
Sensor communication in Smart cities and regions: An efficient IoT-based remote health monitoring system
Master’s Thesis in
PERvasive Computing & COMmunications for sustainable development
2015
92 pages, 53 figures, 27 tables, and 3 appendices.
Examiners: Professor Eric Rondeau- (Universite de Lorraine)
Professor Jari Porras- (Lappeenranta University of Technology) Associate Professor Karl Andersson- (Luleå University of Technology)
Keywords: Smart City, Sensor Communication, Internet of Things, Smart Region, Proto- col Communication, Experimentation, Prototype, Case study
Recent advances in Information and Communication Technology (ICT), especially those related to the Internet of Things (IoT), are facilitating smart regions. Among many ser- vices that a smart region can offer, remote health monitoring is a typical application of IoT paradigm. It offers the ability to continuously monitor and collect health-related data from a person, and transmit the data to a remote entity (for example, a healthcare service provider) for further processing and knowledge extraction. An IoT-based remote health monitoring system can be beneficial in rural areas belonging to the smart region where people have limited access to regular healthcare services. The same system can be benefi- cial in urban areas where hospitals can be overcrowded and where it may take substantial time to avail healthcare. However, this system may generate a large amount of data. In
requirements and the volume of generated data. The thesis studies a commercial product for remote health monitoring in Skellefteå, Sweden. Based on the results obtained via the commercial product, the thesis identified the key network-related requirements of a typical remote health monitoring system in terms of real-time event update, bandwidth requirements and data generation. Furthermore, the thesis has proposed an architecture called IReHMo - an IoT-based remote health monitoring architecture. This architecture allows users to incorporate several types of IoT devices to extend the sensing capabili- ties of the system. Using IReHMo, several IoT communication protocols such as HTTP, MQTT and CoAP has been evaluated and compared against each other. Results showed that CoAP is the most efficient protocol to transmit small size healthcare data to the re- mote servers. The combination of IReHMo and CoAP significantly reduced the required bandwidth as well as the volume of generated data (up to 56 percent) compared to the commercial product. Finally, the thesis conducted a scalability analysis, to determine the feasibility of deploying the combination of IReHMo and CoAP in large numbers in regions in north Sweden.
4
The work of this thesis has been carried out at Pervasive and Mobile Computing Research Group, Department of Computer Science, Electrical and Space Engineering, Lulea Uni- versity of Technology under supervision of Professor Christer Åhlund. This research was fully financially supported by Erasmus Mundus PERCCOM Master Program and the Eu- ropean Commission.
I wish to thank Professor Christer Åhlund, Dr. Karan Mitra and Dr. Saguna Saguna for their guidance and support throughout this work. Their supervision and expertise within the field has been an inspiration during this time and has made my work both enjoyable and stimulating. They have given me motivations, helps and suggestions for my thesis throughout my last semester in Skelleftea. This report is the result of a long process, with many tiring days, late nights working with sensors and codes, sleepless nights, joyful moments of getting good results, sadness when something went wrong suddenly. This thesis is dedicated to my dear supervisors.
I would like to thank Professor Eric Rondeau, Professor Jari Porras, Professor Olaf Droege- horn, Professor Karl Andersson and Professor Evgeny Osipov for their academic support for my whole PERCCOM program. They have given me solid knowledge, practical ex- perience in different fields of ICT as well as research work. The knowledge I got from my professors will be an important asset for my future career.
My parents and my fiancee, Bich Diep, are the ones I often talked to when I felt most tired or frustrated. They always encouraged me to go forward, relieved me of worries and sadness. Without them, it was impossible for me to finish this thesis work.
Skellefteå, May 15, 2015
Ngo Manh Khoi
CONTENTS
1 INTRODUCTION 13
1.1 Introduction . . . 13
1.2 Research challenge . . . 16
1.3 Thesis objective . . . 16
1.4 Research contribution . . . 17
1.5 Thesis outline . . . 17
2 BACKGROUND AND LITERATURE REVIEW 19 2.1 Smart cities and Internet of Things . . . 19
2.2 Network communication in Smart cities . . . 26
2.3 Networking protocols for Internet of Things in Smart city . . . 29
2.3.1 Hypertext Transfer Protocol . . . 29
2.3.2 Constrained Application Protocol . . . 32
2.3.3 Message Queue Telemetry Transport . . . 36
2.3.4 Comparison between protocols . . . 40
2.4 State of the art in home automation . . . 41
2.5 eHealth systems and architectures . . . 43
2.6 Chapter conclusion . . . 46
3 IoT-BASED SYSTEM FOR HOME AUTOMATION AND HEALTHCARE 47 3.1 The existing Telia eHealth system . . . 47
3.2 openHAB default implementation . . . 49
3.3 The proposed IoT-based remote health monitoring architecture . . . 49
3.4 Actual implementation . . . 52
3.5 Chapter Conclusion . . . 53
4 RESULTS 55 4.1 Telia eHealth installation at Luleå University of Technology . . . 55
4.1.1 Periodic traffic pattern . . . 55
4.1.2 Sensor data . . . 59
4.2 openHAB default implementation . . . 64
4.2.1 Periodic traffic pattern . . . 64
4.2.2 Sensor data . . . 65
4.3 CoAP-based IReHMo implementation . . . 66
4.3.1 Architecture of the implementation . . . 66
4.3.2 The measurement results . . . 68
4.4 HTTP-based IReHMo implementation . . . 70
4.4.1 Architecture of the implementation . . . 70
4.4.2 The measurement results . . . 71
4.5 Scalability analysis . . . 72
4.5.1 Bitrate of different events . . . 72
4.5.2 eHealth scenarios . . . 77
4.5.3 Experiments measuring the available upload and download band- width . . . 79
4.5.4 The scalability of the systems . . . 81
5 CONCLUSIONS AND FUTURE WORK 84 5.1 Conclusion . . . 84
5.2 Future work . . . 85
REFERENCES 87
APPENDICES
Appendix 1: openHAB installation in Windows Appendix 2: openHAB installation in Linux
List of Figures
1 The relation among people, technology, economy and healthcare. . . 15
2 General SmartSantander architecture. . . 21
3 The sensor board used in RESCATAME project [20]. . . 21
4 The solution diagram of RESCATAME [20]. . . 22
5 IoT infrastructure from three different viewpoints [21] . . . 23
6 HTTP stack . . . 29
7 HTTP session . . . 30
8 HTTP status code [40] . . . 31
9 CoAP stack. . . 32
10 CoAP messaging models[41]. . . 32
11 Two GET requests with piggybacked responses[41]. . . 33
12 A GET requests with a separate response[41]. . . 34
13 A requests and a response carried in NON messages[41]. . . 34
14 The format of a CoAP message[41]. . . 35
15 CoAP observe functionality[41]. . . 35
16 The general architecture of MQTT[45]. . . 36
17 MQTT QoS 0 - At most once[44]. . . 38
18 MQTT QoS 1 - At least once[44]. . . 38
19 MQTT QoS 2 - Exactly once[44]. . . 39
20 MQTT message format. . . 39
21 Components of home automation system. . . 41
22 Comparison between Zigbee and Z-wave. . . 43
23 eHealth architecture proposed in [49]. . . 44
24 The structure of the telemonitoring service in [49]. . . 46
25 The architecture of the Telia installation at LTU. . . 47
26 The architecture of the openHAB implementation. . . 49
27 The proposed architecture. . . 51
28 The encryption and decryption process. . . 53
29 IReHMo actual implementation. . . 53
30 Periodic traffic pattern 1. . . 56
31 Periodic traffic pattern 2. . . 56
32 Screenshot showing pattern 1 and 2 . . . 57
33 Periodic traffic pattern 3. . . 57
34 Periodic traffic pattern 4. . . 58
35 Periodic traffic pattern 5. . . 59
36 Periodic traffic pattern 6. . . 59
37 Packet exchange triggered by door opening event. . . 60
38 Packet exchange for the video stream. . . 63
39 The periodic message exchange between openHAB and monitoring com- puter. . . 65
40 The openHAB frame as displayed to the user. . . 66
41 Fragmentation due to big XML file size exceeding MTU. . . 67
42 The architecture of the CoAP-based IReHMo implementation. . . 67
43 Packet exchange for GET request in CON mode. . . 68
44 Packet exchange for GET request in NON mode. . . 68
45 Packet exchange for PUT request in CON mode. . . 69
46 Packet exchange for PUT request in NON mode. . . 69
47 Observe in CON mode. . . 69
48 Observe in NON mode. . . 70
49 The architecture of the HTTP-based IReHMo implementation. . . 71
50 The process of exchanging HTTP packets for getting a sensor reading. . 72
51 The details of exchanging HTTP packets for getting a sensor reading. . . 72
52 Comparison between bitrate of different events in the uplink. . . 76
53 Comparison between bitrate of different events in the downlink. . . 76
54 Comparison between total bitrate of different events. . . 77
55 The set up of the experiments. . . 80
56 Coverage map from Telia website. . . 82
List of Tables
1 Short explanation of HTTP methods [40]. . . 30
2 The structure of HTTP messages [40] . . . 31
3 Short explanation of CoAP methods [41]. . . 33
4 CoAP response codes [41]. . . 36
5 MQTT control packets [44]. . . 37
6 The set of devices. . . 48
7 Data generated from pattern 1 and 2. . . 56
8 Data generated from pattern 3. . . 57
9 Data generated from pattern 4. . . 58
10 Data generated from pattern 5 and 6. . . 60
11 Data generated from door opening event. . . 61
12 Data generated by a video frame. . . 64
13 Summary of data generated by sensor single events. . . 64
14 Data generated by openHAB periodic packet exchange. . . 65
15 Bitrate of the periodic traffic patterns in Telia installation. . . 73
16 Bitrate of sensor single events in Telia installation. . . 73
17 Bitrate of voice and video communication. . . 74
18 Bitrate to transmit a sensor value in CON mode. . . 74
19 Bitrate to transmit a sensor value in NON mode. . . 75
20 Bandwidth required to transmit a sensor value using HTTP. . . 75
21 Instantaneous bandwidth requirement of an openHAB frame. . . 75
22 The required bandwidth in the worst case of scenario 1,2 and 3 . . . 78
23 The required bandwidth in the worst case of scenario 1,2 and 3 when IReHMo and CoAP are used . . . 79
24 The saving of IReHMo and CoAP compared with Telia installation. . . . 79
25 The average available bandwidth. . . 80
26 Scalability analysis of the Telia installation. . . 83
27 Reduced bandwidth requirement by IReHMo and CoAP. . . 83
ABBREVIATIONS AND SYMBOLS
3G Third generation of mobile telecommunication technology 4G Fourth generation of mobile telecommunication technology
ACK Acknowledgement
ADSL Asymmetric digital subscriber line AMQP Advanced Message Queuing Protocol CoAP Constrained Application Protocol
CON Confirmable
EDGE Enhanced Data rates for GSM Evolution eNodeB E-UTRAN Node B
GPRS General packet radio service
GSM Global System for Mobile Communications HTML HyperText markup Language
HTTP Hypertext Transfer Protocol IaaS Infrastructure as a Service
ICT Information and communications technology IEEE Institute of Electrical and Electronics Engineers IoT Internet of Things
IP Internet Protocol
IPv4 Internet Protocol version 4 IPv6 Internet Protocol version 6
IReHMo IoT-based Remote Health Monitoring JSON JavaScript Object Notation
LTE Long-Term Evolution
LTU Luleå University of Technology
M2M Machine to Machine
MAC Media Access Control
MQTT Message Queue Telemetry Transport MTC Machine Type Communication NFC Near field communication
NON Non-confirmable
PaaS Platform as a Service
PB Petabyte
PERCCOM Pervasive Computing & Communication for sustainable development
PRACH Physical random access channel QoS Quality of Service
RAN Radio Access Network
RFID Radio-frequency identification
RST Reset
RTT Round-trip delay time SaaS Software as a Service SSL Secure Sockets layer
TCP Transmission Control Protocol UDP User Datagram Protocol
UE User Equipment
UMTS Universal Mobile Telecommunication System URI Uniform resource identifier
URL Uniform resource locator USB Universal Serial Bus
WiMAX Worldwide Interoperability for Microwave Access WLAN Wireless local Area Network
WSN Wireless Sensor Network xDSL Digital Subscriber Line XML Extensible Markup Language
1 INTRODUCTION
This chapter described the contexts that a remote health monitoring system fits in. They include the smart city paradigm and its crucial domains as well as the advances of modern ICT technologies. The chapter details the research challenge that the author faced, as well as the thesis objectives and contribution. The chapter concluded by pointing out the outline of the thesis.
1.1 Introduction
The world population is growing at a very fast pace. According to United States Census Bureau, the world population was at 7.243 billion people (as of 16 May 2015)1. According to an United Nations report, the world population will peak at 9.22 billion in 20752. In contrast, the resource are not unlimited, there are certain shortage of some of the most important natural resources worldwide such as fresh water, fossil fuel, natural gas, pre- cious metal. Furthermore, what makes the situation worse is the uneven distribution of the population, in fact more than 50 percent of the world population concentrates in cities and metropolitan areas. The difference in population density is thousand-fold. As a re- sult, there exist some megacities with population exceeding 10 million like Tokyo, Lagos, Shanghai and New York[1]. Undoubtedly, there are a number of problems associated with metropolitan areas like those, such as heavy pollution, congestion, inefficient use of energy and resources.
In order to cope with the situation, several initiatives have been made. Noticeably, the United Nations defined the term "Sustainable development" to make a reference model and guidance for all human activities on Earth. According to the United Nations World Commission on Environment and Development report in 1987 (Brundtland Report), sus- tainable development is defined as "development that meets the needs of the present with- out compromising the ability of future generations to meet their own needs"[2]. Since then, there were a lot of concepts and ideologies trying to materialize the idea of "sustain- able development" or "sustainability".
As a small part of the gigantic sustainable development framework, the Smart city and Smart region framework comes up at a time when scientists, government authorities and the public joined together to address the aforementioned problems. In many cases, the
1World Population clock - http://www.census.gov/popclock/
2The Outlook for Food Security, http://12.000.scripts.mit.edu/mission2014/the-outlook-for-food- security @MIT
term "Smart city" also covers Smart region [3, 4, 5]. Although there isn’t a single defini- tion, Smart city is usually about the use of information and communication technologies (ICT) to enhance performance and wellbeing of the people, to lower resource consump- tion of the whole city or region, and to interact more effectively and actively with the citizens.
Typically, the Smart city domain can be divided into several subdomains but not limited to smart economy, smart people, smart governance, smart mobility, smart environment and smart living [6]. In each domain, there are several properties that describe it in more details.
On the other hand, Internet of Things (IoT) is one of the most promising technologies in Information and Communication Technology (ICT) for the last decades. At the center of the IoT paradigm lies the idea of adding more identifying, sensing, computing and com- munication capabilities to physical devices that previously not designed for this purpose.
In this way, the enhancement allows devices to communicate with each other, as well as other services and systems, thus gaining new information and obtaining new functional- ities. The main hardware technology enablers of Internet of Things are Radio-frequency identification (RFID), Near field communication(NFC) and Sensor Networks; the soft- ware enablers of IoT are middleware and search/browsing [7]. What IoT really does is to transform data into information, knowledge and finally wisdom. As a result, humans can build a holistic view of the object of interest and act accordingly. Especially in the field of sustainability, IoT helps to collect different environmental parameters effortlessly, and eventually turns them into statistics, knowledge and actions. There is a long list of existing IoT applications, and the list is still going on. IoT is currently present in energy manage- ment, environmental management, healthcare, transport & traffic management, logistics, and inventory management. All applications of Internet of Things can be grouped into four main application domains: transportation & logistics, healthcare, smart environment (home, office, plant) and personal & social [8].
IoT is an important factor in the Big Data movement. Due to its extensive coverage of sensors and the demand to sense continuously, IoT is expected to generate data that is huge in terms of volume and velocity. The data velocity challenge poses a big load on data management technologies, since the data arrival rate can be millions of element per second. As a result of this, the next challenge coming from IoT is real-time data processing, since much of the value of IoT is the ability to respond to a trigger in real- time. The volume of data from IoT applications can be staggering. An example shows that a simple sensing and monitoring application containing 100 sensors collecting telemetry data might produce raw data of 4 PB per year3. Furthermore, the number of IoT devices
3The ’Internet of things’ will mean really, really big data -
is increasing rapidly. According to various reports, the estimated number of IoT devices is likely to increase from 4.9 billion in 2015 to between 25-50 billion by 2020 [9, 10, 11].
In another report, it is predicted that by 2019, there will be 780 million wearable devices and 2.2 billion smartphones [12].
Considering IoT as a technology platform and Smart city as a high-level society devel- opment paradigm, they converge in many areas, for example environmental monitoring, smart transportation, home automation & smart home, resource management, security and healthcare. Among them, healthcare emerges as the center of People, Technology and Economy triangle as depicted in figure 1. Furthermore, healthcare is an important benchmark in smart living, one of the six pivotal domains of the smart city framework.
Figure 1.The relation among people, technology, economy and healthcare.
Leveraging the latest innovations in science and technology, the healthcare system en- hances the well-being of a particular person as well as the population while at the same time reduces the burden on the state welfare system. The reason is that preventive health- care usually detects illness and anomalies much sooner than the time the problem actually occurs, and it is able to prevent injuries and sudden accidents. The installation cost of an IoT system is much smaller compared with the later expenses from medicine and hospital- ization. The following motivating scenario described the advantages of a modern remote healthcare monitoring system.
Helge and Kari Farsund, an elderly couple in Oslo (Norway), is using a remote healthcare monitoring system to fight against Mrs Farsund’s Alzheimer problem4. The system allows caregivers to know if a person is in the room or open a door, and sends alarms if the stove is on for too long or a person walks out in the middle of the night. The latter is of significant
http://www.infoworld.com/article/2611319/computer-hardware/the–internet-of-things–will-mean-really–
really-big-data.html
4Tomorrow’s cities: Sensor networks for the elderly @BBC - http://www.bbc.com/news/technology- 22984876
importance, since sub-zero winters in Oslo means some Alzhemer patients can freeze to death. Caregivers can communicate with Mr. and Mrs. Farsund through Skype on a wall- mounted screen. Moneywise, this IoT system brings a big saving for the government, who previously spent 1,000,000 NOK per year for a caregiver at patient’s house; now the system costs 15,000 NOK. Furthermore, in Europe and North America, elderly people tend to prefer staying in their own house rather than in hospital or elderly house; this fact is reflected in the demographic information of Västerbotten, a region in Northern Sweden.
With an aging population worldwide and an increasing demand in healthcare and early intervention, there is a high demand for such systems.
1.2 Research challenge
The communication network has to constantly cope with the exponential increase of de- vices and user demand. On the other hand, the network capacity is bounded by techno- logical limits and financial expenses. In many cases, the capacity of the communication network lags behind the demand from people and their devices. In the existing network infrastructure, the congestion is high in urban areas while the capacity is limited in rural areas. This poses big challenges for the wide deployment of eHealth services. In contrast, as more people are aware about preventive healthcare, the number of health monitoring applications and IoT devices will grow significantly. These devices will produce "Big data" that need to be transmitted, processed and analyzed in real time. Transmitting large quantities of healthcare data in real-time will pose new challenges and requirements on the communication network infrastructure, including bandwidth and delay. Furthermore, healthcare data consists of different types, such as simple data from the body (temper- ature, breath rate, glucose level) to complex data (Electrocardiography - ECG or EKG signal, Electroencephalography - EEG signal). Another classification of healthcare data is based on its timeliness, whether the data needs to be received instantly for diagnosis purposes or small delays are acceptable. The key research challenge addressed in this thesis is to efficiently transmit healthcare data within the limit of the existing network infrastructure, both in urban and rural areas.
1.3 Thesis objective
The thesis aims to understand the communication requirements of a remote health moni- toring system, specifically the bandwidth and the volume of generated data. Based on this
understanding, the thesis aims to propose an architecture that efficiently collect healthcare data, pre-process the data and transmit it to the servers for further processing. Moreover, IoT communication protocols should be evaluated and compared. Finally the most suit- able network communication protocol should be incorporated in the architecture.
1.4 Research contribution
This thesis studied the communication-related aspects of Internet of Things devices and systems in the context of eHealth for Smart regions, specifically to understand the band- width requirement and volume of data generated. Based on the performance of an existing commercial trial5, the thesis studied and identified its strengths and weaknesses in terms of networking aspects. As a next step, the thesis proposed an architecture that addressed the drawback of existing systems while maintaining their strengths. This proposed ar- chitecture allows users to bind together various types of home automation sensors and healthcare sensors for getting a comprehensive awareness of a person’s health. On top of the architecture, several communication protocols was deployed and compared, resulting in the suggestion of CoAP as a more efficient application protocol in the field of eHealth applications. The architecture suggested the usage of Raspberry Pi as an affordable home gateway for eHealth applications. Finally, the thesis studied the scalability of such archi- tecture in remote communities in Northern Sweden.
1.5 Thesis outline
This section gives an overview of the thesis structure and a brief introduction to each chapter.
• Chapter 2 - Background and literature review
Chapter two starts with presenting a literature study of Smart city paradigm, IoT infrastructure and network communications in Smart city. A reference IoT archi- tecture for Smart city is described in details. Various IoT application layer protocols are described and compared in the second part of chapter two. The last part of chap- ter two is about the state of the art in home automation.
5TeliaSonera ventures into eHealth - http://www.teliasonera.com/en/newsroom/news/2014/teliasonera- ventures-into-ehealth-/
• Chapter 3 - IoT-based system for home automation and health care
Chapter three describes the existing Telia eHealth system, the openHAB default im- plementation and the proposed architecture for remote health monitoring (IReHMo), as well as the actual implementation done at Luleå University of Technology.
• Chapter 4 - Results
Chapter four presents the results collected from studying the Telia eHealth sys- tem, the openHAB default configuration and the implementation of IReHMo using CoAP and HTTP. It highlights the better efficiency that the CoAP-based IReHMo implementation has achieved. The scalability analysis is included in the last part of the chapter, with results from experiments measuring the available bandwidth and the required bandwidth of different healthcare scenarios .
• Chapter 5 - Conclusion and future work
Chapter five concludes and discusses the results obtained during this Master thesis, and presents future work to further extend the proposed architecture.
2 BACKGROUND AND LITERATURE REVIEW
This chapter summarizes the literature work on Smart city and Internet of Things, includ- ing examples of Smart city implementations. In Section 2.1, the introduction of Smart city definitions is followed by the focus on the reference model of an IoT infrastructure in Smart city. Section 2.2 discusses different aspects of network communication. Section 2.3 describes the widely used protocols in the field of IoT communication, namely HTTP, CoAP and MQTT. Section 2.4 summarizes the state of the art in home automation. Sec- tion 2.5 provides the background of eHealth systems and architecture. Finally, section 2.6 concludes the chapter.
2.1 Smart cities and Internet of Things
Today, 50 percent of the world population live in cities and urban areas. It is predicted that the trend is continuing, resulting in 75 percent of the world population are urban citizens by 2050 [13]. There are several reasons for this, including better access to healthcare, entertainment, telecommunication and transportation. However, from the city authorities’
point of view, urbanization brings about new challenges and demands. City authorities are expected to manage a growing number of issues ranging from technical, social, physical to organizational issues caused by overcrowded population in a geographically limited area. Typical issues in a big urban area are traffic jam, environmental pollution (air, water, noise, light, radiation), high crime rate, inefficient use of energy and resources, waste disposal.
The "Smart city" term represents a set of initiatives, ideas and solutions that try to address the aforementioned issues and thus make urban areas more livable. A Smart city can be [14]:
• A city connecting the physical infrastructure, the ICT infrastructure, the social in- frastructure, and the business infrastructure to leverage the collective intelligence of the city [15].
• A city that invests in human and social capital and traditional and modern (ICT) communication infrastructure in order to sustain the economic growth and a high quality of life, with a wise management of natural resources, through participatory governance [16].
• A city whose community has learned to learn, adapt and innovate. People need to be able to use the technology in order to benefit from it [17].
• A city that reflects a particular idea of local community, one where city govern- ments, enterprises and residents use ICTs to reinvent and reinforce the commu- nity’s role in the new service economy, create jobs locally and improve the quality of community life [18].
More definitions can be found at [19]. Although scholars do not agree on a single def- inition of "Smart city", all the definitions center around the usage of ICT to evaluate, manage and make a better, more efficient use of resource. A typical Smart city deploy- ment usually includes sensors, actuators, communication platforms, data storage facilities and computing devices. For each components in that deployment, there are many solu- tions and alternatives. Sensors can be embedded sensors, dedicated sensors or citizens’
smartphones. Data storage can be cloud storage solutions or simple logfile in a server.
There is an endless list of Smart city deployments and prototypes; this chapter details some of the most prominent examples to show an overview of the actual implementation.
SmartSantander is a large-scale Smart city project involving various applications and ex- periments in four different locations (Guildford, Belgrade, Santander and Lubeck). In Guildford, the testbed contains 250 IoT experimentation nodes and 100 embedded gate- way nodes in a building belonging to University of Surrey in order to precisely monitor the energy consumption at each work desk and correlate the obtained information with other context information (ambient temperature, light intensity, user presence). In Lubeck, the testbed contains 162 sensor nodes of different types in order to gain knowledge on en- vironmental parameters and user activity6. In Santander, the testbed contains a great number of IoT devices collecting information on environment, parking availability, traf- fic intensity and managing parks and garden irrigation 7. Figure 2 describes the general architecture of the SmartSantander project.
6Testbeds - http://www.smartsantander.eu/wiki/index.php/Testbeds/
7Santander summary - http://www.smartsantander.eu/index.php/testbeds/item/132-santander-summary
Figure 2. General SmartSantander architecture.
RESCATAME stands for Pervasive Air-quality Sensors Network for an Environmental Friendly Urban Traffic Management, a project funded by European Union. The deploy- ment in Salamanca (Spain) aims to monitor the atmosphere quality through a pervasive air-quality sensors network and feed the gathered information to predicting models. 35 IoT devices (of type Waspmote) were spread in two locations inside Salamanca, each of them measures temperature, relative humidity, CO, NO2, O3, noise and particle level in the air [20]. Figure 3 depicts an IoT-based sensor board used in the RESCATAME project while figure 4 describes the solution diagram of the RESCATAME project.
Figure 3. The sensor board used in RESCATAME project [20].
Figure 4.The solution diagram of RESCATAME [20].
Scholars have been working on a reference model for Internet of Things implementations.
Jin et al.[21] proposed a framework for creating an Internet of Things implementation for Smart cities. According to that article, there are three main viewpoints that Internet of Things can help building a Smart city: network-centric IoT, Cloud-centric IoT and data- centric IoT. These viewpoints cover all different implementation of Smart city projects and act as a reference model for implementing Smart cities.
A) Network-centric IoT In a network-centric IoT, the implementation can be either Internet-based or Object-based. The Internet-based architecture will center around the Internet and uses Internet services as the main focus to transmit data. The object-based architecture will center on smart objects. Networking is the backbone of this network- centric IoT architecture.
Network-centric IoT architecture emphasizes on sensing paradigm, addressing scheme, connectivity model and quality of service (QoS) mechanism.
• Sensing paradigm: Nowadays, the most common sensing paradigms are RFID, wireless sensor network (WSN) and crowd sourcing. RFID uses tags to identify ob- jects and behaviors. The tags, upon receiving interrogation signal from the reader, send their ID back to the reader. RFID is suitable for transportation and access control applications in a smart city. WSN is the main representative of sensing paradigm, which includes collecting, processing, analyzing and transferring valu-
Figure 5.IoT infrastructure from three different viewpoints [21]
able information obtained from the surrounding environments. As science and tech- nology go forward, sensors nowadays are more compact, efficient and powerful, together with cheaper price to manufacture, WSN still plays a key role in sens- ing applications in smart cities. Crowd sourcing just emerged as the latest sensing paradigm, with the participation of user’s smartphones. Crowd sensing will offer new sensing capabilities at finer granularity in terms of time and space that was unavailable before. The future smartphones will incorporate more types of sensors, thus providing crowd sensing even more potentials and possibilities.
• Addressing scheme: Addressing scheme is about giving unique identification of objects. This allows the recognition and differentiation of all the devices and the ability to access and control them. The address space should be scalable so that it can cope with the increase in number of devices and networks without any degrades in network performance. To this date, IPv4 is a robust addressing scheme that is widely used in Internet. However, the address space will be depleted soon. IPv6 is a good replacement for its predecessor, with a significantly larger address space that guarantees a unique address for any devices on Earth. Furthermore, it offers in- teroperability across devices and communication technologies and at the same time simplicity that constrained devices can run IPv6 easily. Zigbee protocol offers an- other robust addressing scheme for IoT devices in network-centric IoT architecture.
Each Zigbee device has three different addresses: a permanent 64-bit MAC address, a 16-bit network address and a name for different purposes [22]. The 64-bit MAC address is unique for each Zigbee device, whereas the 16-bit network address is given by the Zigbee network coordinator or router. This addressing scheme well supports the complexity and routing requirement of Zigbee devices
• Connectivity model: The TCP/IP architecture formed the backbone of the Inter- net. Nowadays, WSN architecture takes advantages of the layered-architecture of TCP/IP to meet its own requirements, such as low-power operation, network scal- ability and constrained resources. In the original TCP/IP architecture, there were different networking layers, each layer uses the services provided by the lower layer and offer services to the upper layer. The layers were physical layer, MAC layer, network layer, transport layer and application layer. In WSN implementations, a similar architecture exists.
• Quality of Service (QoS) Mechanism: An IoT architecture is heterogeneous in terms of services, traffic and QoS requirement due to a variety of networking pro- tocol (wired and wireless) and sensor types. For example, in [23] the authors listed several IoT applications in the Padova Smart city Project together with their traffic and delay requirements, different network types and energy source. This exam- ple clearly shows the heterogeneity of an IoT architecture. In general, there are two categories of network traffic: throughput and delay tolerant elastic traffic and bandwidth and delay-sensitive inelastic traffic [21].
B) Cloud-centric IoT In order to combine IoT characteristics and Smart city applica- tions, as well as to exploit all the potentials of Cloud computing, the Cloud-centric IoT framework is proposed. In this framework, sensors attached to the network produce data which is stored in Cloud storage; software developers build software facilitating the framework, experts perform data mining and machine learning activities to transform raw data into knowledge and understanding. Cloud computing offers several services such as Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS) and Software- as-a-Service (Saas). Therefore, the data generated from sensors, software supporting the framework and algorithms used to process data will be hidden from the applications, which is visible to the public. A Cloud-centric IoT architecture will integrate all aspects of ubiquitous computing by offering scalable storage and computing resources.
C)Data-centric IoTIn this viewpoint, the focus is on data as there will be a vast amount
of data generated from IoT devices. Data-centric IoT highlights all aspect of the data flow, such as data collection, data processing, data storage and data visualization.
• Data Collection: As the first stage in the data flow, data collection has great impact on subsequent steps such as network communication, data storage, energy con- sumption as well as the design of the application. The data collection method can be continuous, random sampling or both of them while the infrastructure can be fixed or mobile platform. Traditional sensing paradigms have been implemented using RFID and WSN, meanwhile a novel sensing paradigm has emerged - partici- patory sensing. It leverages the vast number of sensor-rich, Internet-enabled smart- phones together with the mobility of the population to provide finer, more granular sensing capabilities that were unavailable before. Participatory sensing offers many advantages, among them zero investment on infrastructure and on-demand sensing.
However, it is an open question whether data from participatory sensing is accurate enough. One way to solve the problem is to increase the number of participants through incentives and rewards [24].
• Data processing and management: In this step, raw data is transformed into mean- ingful knowledge and information. This step typically involves preprocessing and event detection, the latter is done by detecting events from long multivariate time- series data. Algorithms are expected to be adaptable and robust, in order to match data from a large time and space spectrum. To understand the data further, com- plex computation techniques such as genetic algorithms, evolutionary algorithms and neural networks are recommended to transform raw data into knowledge. Data storage is of paramount importance, since history data should be stored and ana- lyzed continuously overtime.
• Data interpretation: The ultimate goal of the data-centric IoT architecture is to con- vert raw data from sensors into knowledge and wisdom. With modern technologies in hardware and software, it is possible to present the knowledge in intuitive, user- understandable ways. Latest screen technologies allow user to interact and navigate with data through touch screen [21]. 3-dimensional (3D) screens further the ability to represent data in a more meaningful way [25].
Furthermore, there is a strong relation between the three viewpoints. From the figure, each building block of a particular viewpoint can be interpreted as a building block or a group
of building blocks from another viewpoint. For example, addressing and QoS in Cloud- centric architecture belongs to both data collection and data processing in data-centric architecture, at the same time it is part of the MAC layer, network layer and transport layer in the communication stack of the network-centric architecture.
This reference model is reflected in other literature works. Zanella et al. [23] suggested a conceptual representation of an urban IoT architecture, with details of the protocol stack used at different components of the architecture. The architecture represents well the network-centric IoT viewpoint. Elmangoush et al. [26] presented a four-layer archi- tecture that includes Instrumented, Interconnected, Interoperated and Intelligent Smart city. This architecture reflects well the concept of Cloud-centric IoT viewpoint, where
"Instrumented" corresponds to "Sensing and connectivity", "Interconnected" corresponds to "Addressing and quality of service", "Interoperated" means Cloud computing (com- putation, analytics and storage), and finally "Intelligent" means different applications in Smart cities. In [27] the authors proposed a reference framework for mobile crowd sens- ing which clearly represented the data-centric IoT viewpoint. In that proposed framework, there are five distinct layers: crowd sensing, data transmission, data collection infrastruc- ture, crowd data processing and applications. The first three layers described how data collection is done. Crowd data processing is represented by the use of machine learning and logic-based inference techniques to convert raw data into knowledge and intelligence.
Finally, data visualization and user interface were mentioned as the main part of the ap- plications layer.
2.2 Network communication in Smart cities
In a typical smart city, it is a necessary condition to have an infrastructure of communica- tion networks. Nowadays, cities worldwide have various communication systems, rang- ing from legacy system such as GSM, GPRS, EDGE to modern, high capacity network such as UMTS, LTE and LTE-Advanced. Almost every household and public building have WiFi coverage. Many cities own a large-scale, city-wide WiFi coverage. For wired connections, there are solutions such as ADSL and fiber optics. All these aforementioned technologies form the heterogeneous access network. Initially, these technologies were designed to support human traffic, for instance voice traffic or web surfing. The char- acteristics and pattern of human data traffic is well studied and networks are optimized accordingly [28] [29].
With the emergence of IoT paradigm, the existing heterogeneous access networks have
to cope with Machine-to-machine (M2M) communication. M2M is about the data con- nection between a huge number of tiny, communication-enabled devices through wired or wireless network without any human monitoring or intervention. The utilization of M2M communication perfectly matches various scenarios in which sensors, IoT nodes, gate- ways, smartphones connect with each other. However, M2M communication has many unique characteristics that are different from those of human-to-human (H2H) traffic.
While M2M communication has requirements of low mobility, time controlled, time tol- erant, small data transmissions, infrequent transmission [30], human traffic has a complete set of requirements, typically smaller number of connections, high bandwidth, higher mo- bility. The task of combining both M2M communication and H2H traffic poses many challenges [31]. Usually the M2M communication affects the usual operation of a cell with human traffic negatively [32].
Sensors play a key role in the operation of a smart, modern city. It produces the input for the data flow in any smart city architecture, which includes data collection, data pro- cessing, data management and data interpretation [21]. To make sensors more suitable to various applications, their size have been reduced significantly. With a pool of tiny sensing devices, they will be spread into a vast geographical area, thus collecting more data and generating a better picture of the physical world. However, there are several drawbacks associated with the compactness of sensors. First of all, they are very limited in terms of battery. In some cases, the sensors are located at remote places, inaccessible to humans. Therefore, battery-limited devices have to be in sleep mode most of the times, and only transmit data when necessary. To send data to the sink, sensors need an access network. The access network stands between the sensors (or in general Machine Type Communication devices - MTC devices) and establish a link between these parties. This access network can be wired (cable, xDSL and optical) or wireless connection. The wire- less connection can be either capillary (for example WLAN, ZigBee and IEEE 802.15.4) or cellular (GPRS, UMTS, LTE, LTE-Advanced and WiMAX). Wireless connection is preferred over wired connection due to its ability to scale up, cheaper price and mobility.
The capillary wireless connection offers low power connection at a cheaper price com- pared to wired connection and the ability to scale up. However, its main disadvantages are low data rate, less security, interference and lack of universal infrastructure. On the contrary, the wireless cellular network technologies offer ubiquitous coverage, mobility, roaming as well as security/encryption, thus making them more suitable platforms for smart city applications.
As of today, LTE-Advanced is the latest cellular solution that is being deployed world- wide. It is a natural step to include M2M communication into LTE-Advanced, since this
technology offers ultra-high bandwidth and ultra-low latency (up to 4.9 ms), among other technological advantages[33]. In LTE-Advanced, there are 2 parts, the core network and the radio access network(RAN). The RAN is in charge of maintaining wireless communi- cation to user equipment (UEs) located in different geographical cells. These UEs include MTC devices, which have their unique M2M communication patterns. An UE initiates the random access (RA) process either when it is turned on or it is handed over from another eNodeB [34]. In case of MTC devices, most random access is caused when the device switches from sleeping state to active state, since the sensor’s locations are fixed - no need for handover. When a large number of MTC devices initiate the RA process, the physical random access channel (PRACH) is severely loaded[35]. The overloaded PRACH may cause unexpected delay, higher packet loss ratio, waste of radio resource, extra energy consumption and even service interruption [34]. Therefore, a major research challenge is to find an novel mechanism for overload control in M2M communication, both from the network point of view as well as the MTC device’s point of view. Hasan et al. [34] identified other key research challenges in M2M communication such as mode selection and quality of service (QoS), efficient group management and opportunistic RA (cognitive M2M).
With the abundance of smartphones, a new computing paradigm emerged in the recent years - participatory sensing applications. It has proved to be highly effective in various application domains such as urban planning, environment monitoring, public safety, in- frastructure management, and the list is still growing. The use of participatory sensing application is fueled by the new achievements in technology, namely the big variety of sensors embedded in current and future smartphones as well as the sky-rocketing com- puting power of these host devices, the possibilities of extending the functionalities of smartphones with other plug-in sensors. Another crucial factor that contributes greatly to the success of participatory sensing paradigm is the vast number of smartphone users, as well as their environmental awareness and the desire to move toward a smart, green and sustainable living environment. To date, there are many participatory sensing application in operation. eCAALYX helps improving the healthcare system in which the number of elderly people with chronic diseases is increasing[36]. Hasenfratz et al. [37] developed a portable app that uses smartphone in conjunction with external ozone sensor to measure pollution and monitor air quality in urban environment. D’Hondt et al. [38] mentioned four existing participatory noise mapping applications in their article. Undoubtedly, one of the main challenges is to efficiently transmit the data from sensors to the consumer via the existing infrastructure (WiFi, 3G, 4G). In the near future, a typical user will have a smartphone that host several participatory sensing applications, each and every sensor will constantly stream data to the remote server. Taking into account the population of a
city, the flow of collected data from participatory sensing application will be extremely large [39].
2.3 Networking protocols for Internet of Things in Smart city
This section briefly describes the most popular application protocols used in IoT com- munication, namely Hypertext Transfer Protocol, Constrained Application Protocol and Message Queue Telemetry Transport.
2.3.1 Hypertext Transfer Protocol
Hypertext Transfer Protocol (HTTP) [40] is a request-response protocol used in client- server computing model. HTTP establishes the connection between 2 entities, namely client (for example a web browser) and server (for example an application hosting a web- site).
HTTP is an application layer protocol within the framework of Internet Protocol Suite.
Its definition assumes an underlying and reliable transport layer protocol; as a result, Transmission Control Protocol (TCP) is often used with HTTP. In some rare cases, HTTP can use User Datagram Protocol (UDP) as transport layer protocol.
Figure 6.HTTP stack
HTTP resources are identified and located on the network by Uniform Resource Identifier (URI) or Uniform Resource Locator (URL). An example of URI can be the following:
http://en.wikipedia.org/wiki/Uniform_resource_identifier. HTTP uses HTTP session, a sequence of network request-response transactions.
Figure 7. HTTP session
The HTTP client initiates a request by establishing a TCP connection to a particular port on the server. An HTTP server listening on that port waits for the client’s request message.
Once receiving the request, the server responds by sending back a status line such as
"HTTP/1.1 200 OK" and a message body. In the current version, HTTP/1.1 reuses the TCP connection several times to send and receive multiple HTTP request/response instead of creating a new TCP connection for every single request/response pair
HTTP defines the following idempotent methods to specify the desired actions to be ex- ecuted on the resources: GET, HEAD, POST, PUT, DELETE, TRACE, OPTIONS and CONNECT, as described in details in table 1 .
Table 1.Short explanation of HTTP methods [40].
OPTIONS The OPTIONS method represents a request for information about the communica- tion options available on the request/response chain identified by the Request-URI.
GET The GET method means retrieve whatever information (in the form of an entity) is identified by the Request-URI.
HEAD The HEAD method is identical to GET except that the server MUST NOT return a message-body in the response.
POST
The POST method is used to request that the origin server accept the entity en- closed in the request as a new subordinate of the resource identified by the Request- URI in the Request-Line.
PUT The PUT method requests that the enclosed entity be stored under the supplied Request-URI.
DELETE The DELETE method requests that the origin server delete the resource identified by the Request-URI.
TRACE The TRACE method is used to invoke a remote, application-layer loop- back of the request message.
CONNECT This specification reserves the method name CONNECT for use with a proxy that can dynamically switch to being a tunnel (e.g. SSL tunneling).
The structure of the HTTP request message is detailed in the following table 2:
Table 2.The structure of HTTP messages [40]
HTTP request message HTTP response message
<request-line>
<general-headers>
<request-headers>
<entity-headers>
<empty-line>
/[<message-body>]
/[<message-trailers>]
<status-line>
<general-headers>
<response-headers>
<entity-headers>
<empty-line>
/[<message-body>]
/[<message-trailers>]
HTTP uses the following status code:
Figure 8.HTTP status code [40]
2.3.2 Constrained Application Protocol
Constrained Application Protocol (CoAP) [41] is a dedicated web transfer protocol for use with constrained nodes and constrained networks. CoAP is a request/response protocol used in client-server computing model, however the roles of client and server are usually interchangeable in M2M interactions.
CoAP is an application layer protocol built on top of a datagram-oriented transport proto- col such as UDP.
Figure 9. CoAP stack.
A client sends a CoAP request (similar to an HTTP request) to request an action (using a CoAP method code) on a resource (identified by a CoAP URI) on a CoAP server. Upon receiving a request, the server sends back a response with a response code; this response may include a resource representation. There are four types of CoAP messages: Con- firmable (CON), Non-confirmable (NON), Acknowledgement (ACK) and Reset (RST).
CoAP supports multicast IP destination addresses.
CoAP offers two messaging models for different QoS requirements: Reliable message transmission and unreliable message transmission, as described in the following figure 10.
Figure 10.CoAP messaging models[41].
CoAP defines the following methods: GET, PUT, DELETE and POST, as described in table 3.
Table 3.Short explanation of CoAP methods [41].
GET The GET method requests the proxy to return a representation of the HTTP resource identified by the request URI.
PUT The PUT method requests the proxy to update or create the HTTP re- source identified by the request URI with the enclosed representation.
DELETE The DELETE method requests the proxy to delete the HTTP resource identified by the request URI at the HTTP origin server.
POST The POST method requests the proxy to have the representation en- closed in the request be processed by the HTTP origin server.
Although running on top of UDP, CoAP still provides reliability by marking a message as Confirmable. From the sender’s side, a Confirmable message is retransmitted using a default timeout, and an exponential back-off is added between each retransmission, until the receiver sends an ACK with the same message ID (as 0x7d34 in the figure). If the receiver cannot process the CON message, it will reply with a RST message instead of an ACK. The response for a CON message, if immediately available, is piggybacked in an ACK message. The following figure 11 shows the two piggybacked responses of a basic GET request, one successful response and one Not Found response.
Figure 11.Two GET requests with piggybacked responses[41].
In case the server cannot respond to the request immediately, it responds with an empty ACK message to stop the client from retransmit the request. When the response is ready,
the server sends it in a new CON message (which requires the client to send an ACK in return). This is called "separate response". The following figure 12 shows a separate response for a GET request.
Figure 12.A GET requests with a separate response[41].
A message can be sent in unreliable mode; the message will be marked as NON (Non- confirmable). The receiver will not acknowledge the message transmission, but the NON message still contains a message ID for duplication detection (as 0x01a0 in the figure).
If the receiver cannot process the NON message, it may reply with a RST message. The response for a NON request is sent using a NON message, although the server can use a CON message. The following figure 13 shows a request and a reply in NON mode.
Figure 13.A requests and a response carried in NON messages[41].
CoAP messages are encoded in a simple binary format. As a result, the headed of the message is relatively small (4 bytes) compared to other protocols. CoAP imposes un upper
bound to the message size. The default upper bounds are 1152 bytes for the message size and 1024 bytes for the payload size. CoAP can carry various types of payload, such as Extensible Markup Language (XML) data, JavaScript Object Notation (JSON) or simple text. The message format is described in the following figure:
Figure 14.The format of a CoAP message[41].
CoAP identifies resources using URI, similar to those of HTTP. An example for CoAP URI can be: coap://vs0.inf.ethz.ch:5683/. One important feature of CoAP is its Observe functionality. CoAP pushes information from the server to the client in an asynchronous mode. Instead of a GET request which informs the client about the information of a particular resource at a time instance, the Observe mode allows the client to be an observer of this resource and to receive an asynchronous message every time the resource changes its state [42, 43]. The following figure 15 describes the CoAP observe process.
Figure 15.CoAP observe functionality[41].
CoAP uses the following response codes, as listed in table 4:
Table 4.CoAP response codes [41].
Success 2.xx Client Error 4.xx Server Error 5.xx 2.01 Created 4.00 Bad Request 5.00 Internal Server Error 2.02 Deleted 4.01 Unauthorized 5.01 Not Implemented
2.03 Valid 4.02 Bad Option 5.02 Bad Gateway
2.04 Changed 4.03 Forbidden 5.03 Service Unavailable
2.05 Content 4.04 Not Found 5.04 Gateway Timeout
4.05 Method Not Allowed 5.05 Proxying Not Supported 4.06 Not Acceptable
4.12 Precondition Failed 4.13 Request Entity Too large 4.15 Unsupported Content-Format
2.3.3 Message Queue Telemetry Transport
Message Queue Telemetry Transport (MQTT) [44] is a lightweight message protocol on top of the TCP/IP protocol; it is widely used in M2M communication for IoT devices. It features a lightweight header size of 2 bytes and reduced clients footprint. MQTT adopts the publish/subscribe model; the MQTT architecture includes the publishers, the brokers and the subscribers. The broker receives the subscription from the clients on the topics they are interested in, at the same time it receives message from publishers and forward them, clients (publishers and subscribers) subscribe/publish on topics.
Figure 16.The general architecture of MQTT[45].
MQTT uses the following control packets for its data transmission, as listed in table 5:
Table 5.MQTT control packets [44].
Control packet Short description CONNECT - Client requests
a connection to a Server
After a Network Connection is established by a Client to a Server, the first Packet sent from the Client to the Server MUST be a CONNECT Packet.
CONNACK - Acknowledge connection request
The CONNACK Packet is the packet sent by the Server in re- sponse to a CONNECT Packet received from a Client. The first packet sent from the Server to the Client MUST be a CONNACK Packet.
PUBLISH - Publish message A PUBLISH Control Packet is sent from a Client to a Server or from Server to a Client to transport an Application Message.
PUBACK - Publish acknowl- edgement
A PUBACK Packet is the response to a PUBLISH Packet with QoS level 1.
PUBREC - Publish received A PUBREC Packet is the response to a PUBLISH Packet with QoS 2. It is the second packet of the QoS 2 protocol exchange.
PUBREL - Publish release A PUBREL Packet is the response to a PUBREC Packet. It is the third packet of the QoS 2 protocol exchange.
PUBCOMP - Publish com- plete
The PUBCOMP Packet is the response to a PUBREL Packet. It is the fourth and final packet of the QoS 2 protocol exchange.
SUBSCRIBE - Subscribe to topics
The SUBSCRIBE Packet is sent from the Client to the Server to create one or more Subscriptions. Each Subscription registers a Client´s interest in one or more Topics.
SUBACK - Subscribe ac- knowledgement
A SUBACK Packet is sent by the Server to the Client to confirm receipt and processing of a SUBSCRIBE Packet.
UNSUBSCRIBE - Unsub- scribe from topics
An UNSUBSCRIBE Packet is sent by the Client to the Server, to unsubscribe from topics.
UNSUBACK - Unsubscribe acknowledgement
The UNSUBACK Packet is sent by the Server to the Client to confirm receipt of an UNSUBSCRIBE Packet.
PINGREQ - PING request
The PINGREQ Packet is sent from a Client to the Server. It can be used to indicate to the Server that the Client is alive in the absence of any other Control Packets being sent from the Client to the Server, request that the Server responds to confirm that it is alive, or exercise the network to indicate that the Network Connection is active.
PINGRESP - PING response A PINGRESP Packet is sent by the Server to the Client in re- sponse to a PINGREQ Packet. It indicates that the Server is alive.
DISCONNECT - Disconnect notification
The DISCONNECT Packet is the final Control Packet sent from the Client to the Server. It indicates that the Client is disconnect- ing cleanly.
MQTT employs three QoS schemes, namely QoS 0 - At most once (fire and forget), QoS 1 - At least once and QoS 2 - Exactly once.
Figure 17.MQTT QoS 0 - At most once[44].
In QoS 0 scheme (figure 17), the message is delivered according to the best efforts of the underlying network. No response is sent back by the receiver/subscriber and no retry is performed by the sender/publisher. The message arrives at the receiver/subscriber either once or not at all.
Figure 18.MQTT QoS 1 - At least once[44].
In QoS 1 scheme (figure 18), it ensures that the message will arrive at the receiver/subscriber at least once. A QoS 1 PUBLISH Packet has a Packet Identifier in its variable header and is acknowledged by a PUBACK Packet.
Figure 19.MQTT QoS 2 - Exactly once[44].
Figure 19 describes the highest QoS offered by MQTT, to be used when neither loss nor duplication of messages are acceptable. It comes at a price of higher overhead and traffic in the network.
MQTT is payload-agnostic; it supports any type of data (text, binary, JSON, XML, BSON). The format of a MQTT message is detailed in the following figure 20:
Figure 20.MQTT message format.
MQTT features Keep-Alive message, represented by PINGREQ and PINGRESP. The Keep-Alive timer specifies the maximum allowable time interval between client mes- sages. This timer is used by the broker to check the client’s connection status. After [1.5
* Keep-Alive time], the broker disconnects the client in question. A typical value for keepalive time interval is a couple of minutes.
2.3.4 Comparison between protocols
The comparison between these protocols has received attention in recent literature work.
Some of the above mentioned protocols share some similarities, such as the purpose of transmitting data, the adaptation for highly constrained network, compatibility with smartphones[46]. The behaviour of protocols on different platforms has been studied as well. CoAP, MQTT and HTTP have been compared against each other in terms of architecture, network performance, cost efficiency and energy consumption.
In [46], the authors performed a qualitative comparison between CoAP and MQTT. The results suggested that MQTT is a better candidate for applications requiring sophisti- cated functionalities such as different level of QoS, message persistence and will message.
MQTT outperforms CoAP in term of multicast security. However, quantitative analysis indicates that CoAP performs better than MQTT in terms of bandwidth requirement and round trip time (RTT). For reliability, it depends on the actual scenario; MQTT achieves better results in scenarios where message exchange happens very frequently, otherwise the difference is not much. The reason is that MQTT has more sophisticated reliability and congestion control. The ability of CoAP to fragment large messages makes it more efficient when transmitting large messages.
CoAP has been compared against HTTP in term of total cost of ownership (TCO) [47].
The comparison included each protocol’s technical parameters such as energy consump- tion and amount of data generated over an application’s life cycle. A deployment of 10,000 smart objects served as the testbed for comparison. The system performed the same tasks (sending the measurements of temperature, humidity, solar radiation, wind and precipitation and air quality to the remote server) using CoAP and HTTP.
According to the results, CoAP outperformed HTTP in terms of energy consumption.
For the energy analysis, the authors defined two methods of communication. Push mode means that the object served as a client, it sleeps most of the time in order to save energy.
When it is awake, it starts the communication session and transmits the sensed data. Pull mode means that the object served as a server, waiting for incoming request from a remote node and responding to the request with sensed information. In push mode, CoAP con- sumption rate is up to two times less than HTTP, while in pull mode, CoAP consumption rate is up to six times less compared with that of HTTP. In terms of data, the CoAP-based system generated 62 GB per month while HTTP-based system produced 434 GB.
In [45], the author gave a qualitative analysis on the competing IoT protocols (HTTP,
MQTT, CoAP, AMQP). The criteria used were architecture, security mechanism, QoS schemes and communication patterns. The conclusion was that each and every proto- col has its own strengths and drawbacks. It depends on the scenario and requirements to choose the most appropriate protocol. Furthermore, a complex system can incorpo- rate several protocols together. Finally, the author summarized the most common IoT communication patterns, namely telemetry, inquiries, commands and notifications.
2.4 State of the art in home automation
Home automation is about the automation of home appliances, house work or household activities. It may include, but not limit to, centralized control and management of de- vices and appliances in a house to enhance security, comfort, energy efficiency and safety.
Home automation offers convenience, energy management capability, remote monitoring
& control, accessibility and security to the users.
Figure 21.Components of home automation system.
To date, there are many existing home automation solutions in the market, which provided customers with the needed flexibility. Each solution is designed and optimized for its intended use case. For example, the Fibaro system8offers control of in-house sensors and actuating capabilities with the use of Z-wave sensors. Actuation is achieved by "rules" or user command from computer or smartphones. Control49offers another home automation system by connecting the home controller with sensors and actuators; the user just have to connect to the home controller to gain access to all connected devices in the house.
Savant10 offers a similar system of home automation, with control of lighting, climate,
8Fibaro system - http://www.fibaro.com/us/the-fibaro-system/home-center-2
9Control4 - http://www.control4.com/products/system-overview
10Savant - https://www.savant.com/truecontrol
security, media and energy consumption.
However, these systems’ usecases are defined by the manufacturer; there are limited pos- sibilities that systems can co-operate with each other, or the functionality can be extended significantly. In many cases, the system is a proprietary one, there is no chance of includ- ing hardware from other vendors. Otherwise, third-party hardware can be added to the home automation only if they share the same home automation protocol. Today, there are several competing home automation protocols [48], grouped as wireless (Zigbee, Z-wave, WiFi and Bluetooth), wired (X10, Universal Powerline Bus (UPB) and HomePlug ) and dual-band (Insteon, KNX).
• Zigbee is a wireless mesh network used for sensor communication based on IEEE 802.15.4 standard. In a Zigbee network, each device acts as a relay to forward information. The maximum theoretical network size for Zigbee is 256.
• X10 is a wired home automation protocol, using power lines to allow communica- tion between devices in a house. Since it is a primitive system, it can support about 16 commands.
• Insteon is a dual-band home automation technology that uses both wire and wireless connection. The wired connection using power lines serves as the back-up for the wireless connection. The wireless connection uses mesh network; each device is a relay to send and receive information. Insteon supports over 65,000 commands, it also offers limited compatibility with X10 devices. The maximum theoretical network size for Insteon is unlimited.
• UPB is a wired system using power lines to allow communication between devices.
It serves as the improvement of X10; offering faster command transmission and greater voltage loads.
• KNX is a home automation protocol that incorporates a wide array of physical com- munication media: Ethernet, power lines, twisted pair wiring, radio and infrared, with twisted pair wiring is the most common medium in KNX implementations.
• Z-wave is a very popular wireless standard in home automation, it uses mesh net- works to route information between devices. It offers complete compatibility among Z-wave devices. The maximum theoretical network size for Z-wave is 232.
