Republic of Iraq

Ministry of Higher Education and Scientific Research

Middle Technical University
Electrical Engineering Technical College

Design and Implementation of Scalable IoT Platform

for Environmental Pollution Monitoring System:
A Case Study of Iraq

A Thesis
Submitted to the Electrical Engineering College
in Partial Fulfillment of the Requirement for the Degree of Master
in Computer Engineering Technique.

By
Taha Essam Mahmood

Supervised by
Dr. Osama Abbas Hussein
Assist. Prof. Dr. Alaa Khamees K Al-azzawi

May 2021 Ramadhan 1442

Ramadhan 1442
42
‫نَـ ْرفَــ ُعَدرجَـاتٍَ َّمنَنَّشَـا ُءََۗ‬
‫(‪)76‬‬ ‫وف ْوقَك ُِّلَ ِّذيَ ِّع ْل ٍمَع ِّليـمََ‬

‫[ سورة يوسف ]‬
 Supervisor Certification

This is to certify that this thesis entitled Design and Implementation

of Scalable IoT Platform for Environmental Pollution Monitoring
System: A Case Study of Iraqَby Taha Essam Mahmood was prepared
under our supervision in partial fulfillment of the requirements for the degree
of Master in Computer Engineering Techniques.

Signature:
Name: Osama Abbas Hussein
Title: Dr.
Date:

Signature:
Name: Alaa khamees K Al-azzawi
Title: Assist. Prof. Dr.
Date:
 Linguist Certification
I certify that I have read this thesis entitled Design and Implementation
of Scalable IoT Platform for Environmental Pollution Monitoring
System: A Case Study of Iraq by Taha Essam Mahmood I examined the
language of the thesis and in my opinion, it is free of linguistic and
grammatical errors.

Signature:
Name: Raghad Hassan Hussein
ََ Title: Assist. Prof. Dr.

Date:

In view of the available recommendation, I forward this thesis for debate by

the examining committee.

Signature:
Name: Assist. Prof. Dr. Muhamed Ibrahim Shujaa
Head of Computer Engineering Techniques Department
Date:
 Examining Committee Certification

We are members of the examining committee certify that after reading this
thesis Design and Implementation of Scalable IoT Platform for
Environmental Pollution Monitoring System: A Case Study of Iraq and
examining the student Taha Essam Mahmood in its contents. In our opinion,
the thesis is adequate for the award of Degree of Master of Technical in
Computer Techniques Engineering.

Signature:
Title: Assist. Prof. Dr.
Name: Muhamed Ibrahim Shujaa
Date:
(Chairman)

Signature: Signature:
Title: Assist. Prof. Dr. Title: Dr.
Name: Ammar Ibrahim Majeed Name: Basman Monther Jawamer
Date: Date:
(Member) (Member)

Signature: Signature:
Title: Dr. Title: Assist. Prof. Dr.
Name: Osama Abbas Hussein Name: Alaa Khamees Khudair
Date: Date:
(Supervisor 1) (Supervisor 2)

Approval of the Electrical Engineering Technical Collage

Signature:
Name and Title: Prof. Dr. Adel Ahmed Obed
Dean of Electrical Engineering Technical Collage
Date:
 DEDICATION

I dedicated my dissertation work to .....

My father, my mother....

My wife, and my beloved doughter...

And to everyone who helped & encouraged me.

Taha E. Mahmood
 Acknowledgments

Always the greatest praise and thanks be to "Allah" Almighty. The blessings
of Allah upon us are countless. There are so many blessings of Allah that we can’t
even write them down. If we start writing them all, our life will come to an end,
but Allah’s grace will never finish. Allah said: “… And If you would count
the blessings of Allah you would not be able to count them …”
[Surah Ibrahim 14:34].

I would like to express my great respect & gratitude to my supervisors

Dr. Osama A. Hussein and Assist. Prof. Dr. Alaa Khamees K Al-azzawi
for their kindness and support throughout my postgraduate study.

I would like to express my sincere respect and gratitude to the Head of the
Computer Engineering Techniques Department (Assist. Prof. Dr. Muhamed
Ibrahim Shujaa) and to the Rapporteur of the Computer Engineering Techniques
Department (Prof. Dr. Mahmood Farhan Mosleh) for their kindness and support to
complete the requirements of presenting this thesis as soon as possible.

I would like to thank the faculty of the graduate studies department at the
Electrical Engineering Technical College for their assistance and support.

Finally, I would like to show my great appreciation to my family & friends for
their continuous encouragement.

II
 Abstract
Recently published researches confirmed the existence of widespread pollution
in the cities of Iraq, where many residents of these cities suffer from injuries directly
related to dangerous environmental pollutants. This is accompanied by the lack of
monitoring systems in place to detect air pollutants, for example: particulate matter,
sulfur dioxide, ground-level ozone, carbon monoxide, nitrogen dioxide, and
radioactive pollution. Thus, it required the use of systematic application solutions to
reduce the impact of these pollutants.
The thesis focused in-depth on studies and research that introduced many
innovations and design solutions related to real-time air pollution monitoring
systems, looking to obtain an integrated system design that is suitable and serviceable
in terms of comprehensive coverage of air pollutants and the general population
of Iraq.
Given the apparent deficiency in the backend design for this kind of system,
it was concluded that there is a need for an ideal integrated design pattern supported
by the most appropriate technologies with the least consumption of computing
resources, this represents the main contribution of this thesis that was focused on.
In practice, the proposed system receives the sensing nodes’ readings over the
Internet periodically, in turn analyzing and collecting it systematically, and storing it
in a special database. On the other hand, the system displays the results of analyzed
data (cities pollution levels) in real-time to the population through a special web
application, emphasizing the high pollution rates and the need to find the appropriate
solutions to them.
To emphasize, the JavaScript Object Notation (JSON) message format is used
in this thesis due to its ease of reading, parsing, and generation, along with the
Constrained Application Protocol (CoAP) of the lowest bandwidth and
communication overhead compared to MQTT protocol for exchanging data between
the distributed nodes (T-Call ESP32 modules) and the system's web application, as
well as for organizing and displaying the content of pollution sites on Google Maps.
In addition, a MongoDB is used as a database to store the large-scale system
data received from the sensing nodes due to its efficiency in managing JSON-
formatted documents with less query execution time compared to MySQL and
Cassandra databases, while the MySQL database is used to store and manage system
relational data represented by information of (supervisors, sensing locations,
departments, and notifications) due to its efficiency to manage such data. Finally, the
results showed that there is a clear reduction in data query execution time, bandwidth,
and consequently, a noticeable increase in the overall system performance efficiency.
III
 List of Contents

Page
Acknowledgments …………………………………………...………... I
Abstract ……………………………………………………..………… II
List of Contents …………………………………...…………………... III
List of Figures …………………...……………..……………………... VI
List of Tables ………………………………………..………....……... VIII
List of Abbreviations ……………………………………..…....……... IX
List of Symbols …………………………………………………..…… XI
CHAPTER ONE: Introduction
1.1 Overview ……………..………………………………..………….. 1
1.2 Literature Survey …….………………………………..………...… 1
1.3 Problem Statement …....……………………..……………………. 9
1.4 Thesis Objective ……….………………………………………..… 9
1.5 Thesis Contribution ……………………………………………….. 10
1.6 Organization of the Thesis …………………………………..……. 10
CHAPTER TWO: Theoretical Background
2.1 Introduction ………………………………………………...……... 12
2.2 Air Pollution …....………………..……………………………….. 12
2.2.1 Air Quality Standard ……………….……………..………… 12
2.2.2 Air Pollution Sensors ………..……………………..……..… 15
2.3 Radioactive Pollution ...………………….……....………..………. 18
2.3.1 Radioactive Thermometer ……….…………………..…….... 19
2.3.2 Radiation Detector .…………………………………..…....… 20
2.4 Transmission Unit …………………………………………...……. 20
2.5 JSON Message Format …………………...…………………….…. 22

IV
2.6 System Architecture ……….……………………………………… 23
2.7 IoT Messaging protocols ……………………….……………...….. 23
2.7.1 MQTT Protocol …………………...……………………..….. 24
2.7.2 CoAP Protocol …………………………………….………… 26
2.8 Databases ………………………………………………………...... 31
2.8.1 MySQL Database …………………………………………… 31
2.8.2 Cassandra Database ……………...……………………..…… 32
2.8.3 Mongo Database ……………………...…………………...… 33
2.9 Google Maps API …………………………………………………. 33
2.9.1 Loading the Maps API ……………………………………… 34
2.9.2 Adding a Marker …………………………………………..... 34
2.9.3 Adding an InfoWindow ……………………………………... 35
2.9.4 Adding Google Charts …………………………………….… 35
CHAPTER THREE: Proposed System
3.1 Introduction ……………………………………………………….. 38
3.2 Optimum Sensing Locations ………...…………………...……….. 38
3.3 System Design …………………………………………………….. 41
3.3.1 Sensing Unit Design ………………………………………… 41
3.3.2 Cloud Computing Design …………………………………… 44
3.3.3 Messages Format Design …………………………………… 46
3.3.3.1 Type-1 Message Format ……………………………. 46
3.3.3.2 Type-2 Message Format ……………………………. 47
3.3.4 Web-Application Design …..………………………………... 47
3.3.4.1 Administrator Dashboard Webpage ………….……... 47
3.3.4.2 Supervisors Control Panel Webpage ………………... 60
3.3.4.3 Main Webpage/Citizen Service Webpage ……...…… 61
3.4 Deployment Recommendations …………………………………... 62

V
CHAPTER FOUR: Results and Discussion
4.1 Introduction ……………………………………………………….. 64
4.2 System Messages ………………………………………………..… 64
4.2.1 Type-1 Message Format …...………………………………... 64
4.2.2 Type-2 Message Format ...…………………………………... 64
4.3 System Messaging Protocol ………………………………………. 65
4.3.1 MQTT Protocol ……………………………………………... 65
4.3.2 CoAP Protocol ………………………………………………. 65
4.4 System Database ….………………………………………………. 65
CHAPTER FIVE: Conclusions and Future Work
5.1 Conclusions ………………………..…………………………….... 72
5.2 Future Work ……………………..….……………………………... 73
References …………………………………………………... 75
Appendix ……………………………………...……….……. 81

VI
 List of Figures
Figur
Title Page
e

2.1 Circuit Diagram of the MICS-6814 Module…………………. 16

2.2 MICS-6814 Module (Front View) ………………………..…. 16
2.3 Front and Back View of The SDS011 Module …………….... 17
2.4 Front View of The 2SH12 Module ………………………….. 18
2.5 Front and Back View of The MQ-131 Module ………..…….. 18
2.6 DIY Radiation Detector ……………………………..………. 20
2.7 T-Call ESP32 Module Pin Diagram ………………………… 22
2.8 MQTT Architecture ………………….……………………… 25
2.9 Working of MQTT …………………………………………... 25
2.10 CoAP Layers ……………………………………………..….. 27
2.11 Reliable Message Transport …………………………………. 27
2.12 Unreliable Message Transport ………………………………. 28
2.13 The failure and successful response results of GET method ... 28
2.14 A Get request with a separate response ……………………… 29
2.15 Non confirmable request and response ……………………… 29
2.16 CoAP Message Format ……………………………………… 30
2.17 CoAP Model Architecture Overview ….…………………..… 30
2.18 Example of SQL Statements ………………………………… 32
2.19 Example of a JSON Message Format Stored in MongoDB….. 33
2.20 Google Map API Script ……………………………………… 34
2.21 Custom Marker Icons …...…………………………...………. 34
2.22 InfoWindow View ……..…...………………………………… 35
2.23 Chart ………..…...………..…………………………….…..… 36

VII
3.1 The Proposed System Pictorial Representation ….…...…….… 40
3.2 The Proposed Flowchart of the Sensing Module Software Design 42
3.3 Sensing Unit Diagram ………………………….…….…………. 43
3.4 System Cloud Computing Components Structure ……….…....… 45
3.5 Administrator Dashboard Webpage …………………………..… 48
3.6 Supervisor’s Management Webpage ………………………......... 48
3.7 Supervisor Add/Edit Webpage ……………………………….…. 49
3.8 Sensor Management Webpage ………………………………..… 50
3.9 Sensor Add/Edit Webpage …………………………………….... 50
3.10 Department Management Webpage ………………………….…. 51
3.11 Department Add/Edit Webpage ………………………………..... 52
3.12 Ads Bar Management Webpage ……………………………….... 53
3.13 Ads Add/Edit Webpage ……………………………………….… 53
3.14 Data Search Engine Webpage ……………………………….….. 54
3.15 Data Search Results Webpage ………………………………...… 55
3.16 Latitude and longitude Finder Webpage ………………………... 56
3.17 Flowchart of The Sensor-Checking Algorithm …………….…… 58
3.18 Sensors Checking Results Webpage ………………………......... 59
3.19 Supervisors Control Panel Webpage ……………………….…… 60
3.20 Citizens Service Webpage ……………………………………..... 62

VIII
 List of Tables
Table Title Page

2.1 AQI Scale ………………………………………………....... 13

2.2-A Breakpoints for AQI ……………………………………...... 13
2.2-B Breakpoints for AQI ……………………………………...... 14
2.3 Radiation Thermometer Scale ……………………………… 19
2.4 A Comparison between CoAP and MQTT Protocol ………. 31
4.1 Databases Performance Comparison …………..…………... 66

IX
 List of Abbreviations
Abbreviation Description
AJAX Asynchronous JavaScript And XML
AMQP Advanced Message Queuing Protocol
AP Access Point
API Application Programming Interface
APP Application
AQI Air Quality Index
AQMI Air Quality Monitoring Instrument
CDC Centers for Disease Control and Prevention
CO Carbon Monoxide
CoAP Constrained Application Protocol
CSS Cascading Style Sheets
DDS Data Distribution Service
DNA Deoxyribonucleic Acid
DNS Domain Name Service
DT Decision Tree
GIS Geographic Information Systems
GM Geiger–Müller
GPP Green Public Procurement
GPRS General Packet Radio Service
GSM Global System for Mobile Communications
HTML Hyper Text Markup Language
HTTP HyperText Transfer Protocol
IoT Internet of Things
JSON JavaScript Object Notation
LPWA Low-Power Wide-Area

X
 MCU Microcontroller
Mobile-DAQ Mobile Data-Acquisition Unit
MongoDB Mongo Database
MQTT Message Queuing Telemetry Transport
MSE Mean Square Error
MySQL My Structured Query Language
NO2 Nitrogen Dioxide
NoSQL Non Structured Query Language
O3 Ground-Level Ozone
PHP Personal Homepage (Hypertext Preprocessor)
PM Particulate Matter
RAM Random Access Memory
RD Radiation
RDBMS Relational Database Management System
SDR Software Defined Radio
SEMAR Smart Environment Monitoring & Analytic in Real-time
SMS Short Message Service
SO2 Sulfur Dioxide
SVM Supporting Vector Machines
TCP Transmission Control Protocol
UDP User Datagram Protocol
US EPA US Environmental Protection Agency
VaaMSN Vehicle as a Mobile Sensor Network
WMS Web Map Service
WSN Wireless Sensor Network
XML Extensible Markup Language
XMPP Extensible Messaging and Presence Protocol

XI
 List of Symbols
Symbol Description

μg/m3 Microgram Per Cubic Meter

Ppb Part-Per-Billion
Ppm Part-Per-Million
D Pollutant Concentration
DLow Pollutant Concentration Breakpoint ≤ D
DHigh Pollutant Concentration Breakpoint ≥ D
ILow Index Breakpoint Corresponding to DLow
Ihigh Index Breakpoint Corresponding to DHigh
mSv Millisievert

XII
Chapter One
[Introduction]
Chapter One Introduction

Chapter One
Introduction
1.1 Overview
The number of automobiles, buses, trucks, heavy construction
equipment, and local generators has increased greatly in Iraq since 2003.
In addition to the pollution resulting from dust storms, which constitute the
highest levels of pollution in the air and threaten the lives of many people due to
their negative effects on health and the country's economy [1 - 3]. As well as, the
remnants of wars that have caused high environmental problems, according to the
statistics of the effects of radioactive pollution on the lives of citizens resulting
from the destruction of the 14-Tammuz nuclear reactor in 1981, in addition, the
recent wars in Iraq (1991 to 2015) where sophisticated ammunition that contained
depleted uranium were used in combat. The usage of these weapons severely
impacted humans, animals, and the surrounding environment [4 - 7].َ
However, some researchers gave recommendations to design a map
showing all polluted areas in Iraq due to the increasing statistics of the population
affected by pollution symptoms [7].
Giving the severity of the topic, it is clear that Iraqi society truly needs a
real-timeَservice that helpsَmonitor and observe changes in the concentration of
environmental pollutants for all polluted areas. That is why this thesis delves into
the design of a scalable distributed system for such service.
1.2 Literature Survey
Several studies have been carried to design and implement outdoor
air pollution monitoring systems. A review of some of these is presented
in this section, with the hope of getting an idea about the design approach,
techniques, and system architecture that can be used to design an integrated
system as a service for monitoring air pollutants in real-time for Iraq.

1
Chapter One Introduction

1) In 2011, S. A. Mishra, D. S. Tijare, and G. M. Asutkar [8] presented a wireless

sensor network system for air quality monitoring in Nagpur, India. The system
is supported by the ability to measure (breathable suspended particles,
nitrogen oxides, and sulfur dioxide). The adopted WSN nodes consist of low-
power devices (processor, RAM or flash memory, radio frequency transmitter
and receiver, and some sensors). There are three major processes involved in
analyzing the performance of system WSN which are, creating a scenario
model, analysis, and simulating. All these procedures were done by the
Network Simulator.
2) In 2011, Y. J. Jung, et al. [9] provided a system architecture design that
consisted of four aspects (sensor network control server, geo-sensor network,
context-aware service, and air pollution monitoring system). The proposed
system monitors (temperature, illumination, dust, humidity, ultraviolet
radiation, carbon dioxide, wind speed, wind direction, air pressure, and
altitude). It used Sensor Model Language to describe the properties of sensors
such as identification, coordinates, constraints, documents, and measurements
in a standard XML schema.
3) In 2012, J. Ikram, et al. [10] presented a system design supported by a series
of electrochemical sensors (Temperature, Humidity, SO2, O3, and CO) to
measure the environment variables. The gathered data encapsulates into a
GSM text message and sends it to the server via the GSM modem. The
software design consists of the webserver supported by databases and Google
GIS. The software design has been divided into Communication API and the
web interface.
4) In 2013, D. Yaswanth, and S. Umar [11] offered a small-scale air pollution
monitoring system that includes two parts, a front-end automatic monitoring
system and a control center. The front end uses WSN, coupled with GSM
technology. This monitoring system can provide air pollution data and
meteorological parameters on a small time scale. Sensor nodes collect their

2
Chapter One Introduction

data and transmit it to the control center through SMS via GSM, where the
sensor data is stored in a database. Users can make inquiries about historical
data and the latest updated data through a webpage supported by the database.
5) In 2013, A. R. Kasar, D. S. Khemnar, and N. P. Tembhurnikar [12] have
developed a structure for identifying nodes and their interaction with an air
pollution monitoring system, the system design uses easy-to-use methods
such as tables and line graphs to visualize aggregate data from WSN as reports
on a daily or monthly basis as well as real reports - time notifications during
serious air pollution situations for use by authorities Competent. The proposed
hardware architecture design consists of an ATMEGA16 microcontroller
connected to SO2, CO2, and NO2 sensors, a GPS module, and a ZigBee
modem using an RS-232 interface.
6) In 2014, G. Swagarya, S. Kaijage, and R. S. Sinde [13] proposed an industrial
air quality monitoring system based on WSNs. This system uses the Global
System for Mobile Communications (GSM) and the Zigbee communication
protocol. The system consists of a set of sensors, a control center, and a
database in which sensor data can be stored for future plans and history. Each
sensor node consisted of an onboard GPS unit, a microcontroller, and sensors
to detect the O3, CO, and NO2. The node uses Bluetooth to send data to the
gateway in a car and store the data locally into memory when there is no Wi-
Fi hotspot to transmit the data to the server where the data would be processed
and published on the sensor Map portal.
7) In 2014, V. K. Ustad, A. S. Mali, and S. S. Kibile [14] proposed a system
consists of a Mobile Data-Acquisition Unit (Mobile-DAQ) and a fixed
Internet-Enabled Pollution Monitoring Server. The Mobile-DAQ unit
integrates a single-chip microcontroller, air quality sensors array, and GPS
Module. The Mobile-DAQ unit collects air pollutants levels (CO, NO2, and
SO2), and packs them in a frame with the GPS physical location, date, and
time. The frame is transmitted to the Pollution-Server via a Zigbee module.

3
Chapter One Introduction

The Central-Server uses Google Maps to show the location of the hardware
units. It can connect the database server to the Pollution- Server for storing
the concentration of the pollutants for further usage by various clients.
8) In 2015, F. Ye, X. Liu, and Y. Liu [15] proposed a design of the urban air
quality real-time forecast system is implemented based on the monitoring sites
and the Thiessen polygon. They proposed a three layered system architecture
including the data service layer, parsing and controlling layer, and
visualization layer. The proposed system was developed in Shanghai city.
They used AJAX technology to asynchronously read the air quality data and
send it in JSON format via HTTP. Each message format contains multiple
attributes (such as AQI, PM2.5, Station Code, Area Code, and Observation
Time, etc.). They used ArcGIS Thiessen Polygon tool to create Thiessen
polygons based on on-site location and Shanghai administrative boundaries.
At last, using ArcGIS Server, the Thiessen polygons will be published as
WMS for the visual representation layer.
9) In 2016, N. Kaur, et al. [16] proposed a new framework a WSN based on data
transmission and acquisition. The parameters selected for monitoring are
temperature, humidity, CO, CO2, smoke, alcohol. The reading of these
parameters is sent using Zigbee to a base station where they can be monitored.
The value of temperature and humidity are sent over Bluetooth technology
also so that every person within the range of the system can check it over their
laptops and smart mobile. CO is monitored with more precaution; a text
message is sent using a GSM unit to the base station whenever its
concentration exceeds a particular safe limit.
10) In 2016, K. Zheng, et al. [17] implemented an air pollution monitoring system
using Internet of Things platform technologies. With the help of the LPWA
network, air sensing data is collected over a large coverage area and
transferred to the IoT cloud in a timely manner. Gateway control points have
been developed to facilitate deployment and can operate all day with a solar

4
Chapter One Introduction

panel or battery. All AP functions are implemented on an SDR platform GPP

based. The sensed data of pollutants PM2.5, PM10 is stored in the database
and analyzed in the IoT cloud. The IoT cloud consists of three servers (Data
Processing Server, Storage Server, and HTTP Server). They provide a website
and a mobile application to show the air quality info. The homepage is
programmed using HTML, Java Script, and CSS.
11) In 2017, Y. Chen, J. Li, and C. Qi [18] designed and realized a mobile air
pollution tracker robot, which can be used to monitor air pollution in regular
management and industrial parks. The sensors are mainly divided into (1)
internal sensors, which are used to detect the robot's working parameters at
the accident scene and feedback to the control system and make the robot
operate orderly through reasonable arrangements according to the accident
scene. (2) External sensors, provide the original monitoring data of the
treatment system, such as temperature, wind direction, speed, oxygen content,
and concentrations of flammable or toxic gases.
12) In 2018, P. Partheeban, and B. Shanthini [19] designed and implemented an
Air Quality Monitoring Instrument-AQMI using a MCU (ARM7 CPU with
real-time embedded and emulation trace support), air pollution sensors (NO,
CO2, and CO), signal sensing conditioners, and a GPS. The AQMI collects
the air pollution data for the designated routes in Chennai city. The designed
instrument output is connected to a PC with a GSM unit to provide internet
connectivity. The sensing unit gathers air pollutants concentrations and
collects them in a frame with the GPS physical placement, date, and time. The
emerged frame is uploaded to the GSM-Modem via the RS232 serial interface
and sent to the Central-Server through a wireless network. Central-Server is
interfaced to the Google Maps to display the placement of the sensors.
13) In 2018, J. H. Jo, et al. [20] proposed an IOT based air pollution monitoring
system that used an Arduino MCU equipped with an MQ2 gas sensor and an
Esp8266 Wi-Fi module. The cost of implementing the proposed system is

5
Chapter One Introduction

relatively low, and thus the end product will be cheaper in turn. In the
proposed system, the MQ2 gas sensor detects gases like Butane, Methane,
LPG, Smoke, etc. The MCU reads the sensor data and sends it to the IoT cloud
using the Esp8266 Wi-Fi module. The data collected and analyzed are
processed in the IoT cloud. This system makes it easy for the general public
to purchase and install in their homes, workplaces, etc.
14) In 2018, T. S. Gunawan, et al. [21] presented a cost-effective and portable
system for measuring air pollutants using four sensors and an Arduino board.
The proposed device allows people to measure Air Pollutant Index form
anywhere. It is able to measure the particulate matter, CO, and O3 and convert
the readings into an Air Pollutant Index value. The proposed system was
tested by comparing the current Air Pollutant Index measured in Malaysia at
several sites to the Air Pollutant Index measured from this device. The
obtained results show the system metering reliable and effective.
15) In 2018, Y. Y. F. Panduman, et al. [22] proposed a system consisting of a
Vehicle as a Environment Monitoring and Analytic in Real time-SEMAR
cloud computing and a Smart Mobile Sensor Network-VaaMSN as advanced
computing. The VaaMSN is a package of GPS, 4G Wi-Fi modem, air
pollution sensors, and single-board computing. SEMAR cloud computing
includes a database for real-time monitoring, big data environment, and
analytics using Decision Tree (DT) algorithm and Supporting Vector
Machines (SVM). The system output form consists of a table, a graph
visualization, and maps. The evaluation obtained from the results of the
experiment showed that the accuracy of the two algorithms is more than 90%.
However, the SVM's Mean Square Error_MSE value is about 0.03076293,
but the DT algorithm has an MSE value 10 times smaller than the SVM
algorithm.
16) In 2019, S. Chowdhury, et al. [23] proposed a monitoring system that
embodies a device made of various gas sensors, a GSM module, a cloud

6
Chapter One Introduction

server, and a mobile application. In the implemented device, one can easily
access the data from the server and app to monitor the air pollution condition.
Also, it consists of an alert system to send notifications when the pollution
parameters exceed the standard limitation. The hardware section divided into
two subdivisions: (1) Data Acquisition Sensors of CO2, Ammonia, CH4, CO,
Humidity, temperature, and PM. and (2) Data Transmission: Wi-Fi/GPRS
module). They designed an Android application using java language to
display the collected data. The system server collects data from the GSM
module in JSON format. While the Android application extracts the data from
the JSON messages received and displays them.
17) In 2019, D. V. Mahammad [24] designed an air monitoring system with an
ESP8266 Wi-Fi module and an Optical Dust Sensor as host controller and
sensor respectively. The cloud platform blink application is used as a platform
to control many IoT boards like Arduino. The dust density in the air can be
monitored via a smartphone at any time and from anywhere. The system was
successfully constructed and tested.
18) In 2019, P. Purwanto, S. Suryono, and S. Sunarno [25] designed an air
pollution monitoring system using WSN that can be accessed via web and
smartphone. The development of WSN systems consists of two steps, the first
step being assembling sensor nodes and hosting a web server. The next step
is to test and calibrate the system. The experiment results show that the system
is able to detect various air pollution, such as nitrogen oxides, sulfur dioxide,
carbon dioxide, and other parameters such as humidity, temperature, and wind
speed.
19) In 2019, T. H. Nasution, M. A. Muchtar, and A. Simon [26] designed an Air
Quality Monitoring System for an Internet of Things platform to display air
quality levels in a region. The system will be monitored with sensors to see
levels of PM, O3, SO2, and CO. Read sensor data via Arduino MCU. The
data sent to the ThingSpeak Cloud using the Wi-Fi module for accessing the

7
Chapter One Introduction

ThingSpeak cloud service API. Monitoring results will be displayed via a

webpage provided by ThingSpeak that sends out every 1 minute. On the web
page, the data is presented in graphical form. The webpages can be accessed
from the Internet by accessing the monitoring channel.
20) In 2020, R. Bhambare, and S. Khairnar [27] proposed a solution to track air
and noise emission levels within industrial environments or to use a wireless
embedded computing device to create a limited area of interest. The proposed
model is adaptable and distributive to any infrastructural setting for the
necessity of continuous monitoring, regulating, and conduct analysis. It
consists of sensor modules, Arduino board, Thinkspeak, and MATLAB
software. The air pollution concentration is calculated by observing the
pollutants present in that area's air, such as temperature level, humidity level,
dust level, smoke level, CO level, etc. The proposed monitoring system based
on IoT to monitor and check the air quality level in specific areas.
21) In 2020, P. Shinde, et al. [28] developed an Arduino based air pollution
detector that combined a minimum-cost, small-sized sensor to an Arduino
MCU unit along with this they used machine learning. The advantage is that
all the data of a location will be available on an android application platform.
The proposed software on the android platform will be able to analyze and
collect data with high precision.
22) In 2021, Y. U. Tong, et al. [29] proposed a data service air quality detection
system based on a light scattering sensor, which can detect PM2.5, humidity,
and temperature, and upload data to the Internet of things platform for
historical data statistics and real-time analysis. The system collects three kinds
of sensor modules and sent their data through Wi-Fi to PC terminal or mobile
terminal equipment. Its historical data can be displayed and called for data
statistics through mobile phones. This study shows the improvement methods
and the detection characteristics of light scattering sensors.

8
Chapter One Introduction

1.3 Problem Statement

In general, the published work in the domain of environmental pollution
monitoring systems (design and implementation) focused too much on the sensor
part and failed to account for the backend-side of the system which is of uttermost
importance. After all, the large number of requests by the site-visitors or by the
sensing nodes will have Distributed Denial of Service attack (DDoS) like effect
which brings the service down rendering the whole work totally pointless,
as well as the absence of any of the following aspects that adds integration to
build such systems:
1) Support major pollutants related to air pollution and radioactive pollution
that have been discovered in Iraq.
2) Discuss best techniques that can be used in the infrastructure of such
systems, such as (messages format, messaging protocols, and databases, and
others).
3) Provide complete system analysis and design that show (cloud computing
design, back-end webpages design, database structure, messages format, and
others).
Thus these works cannot be considered as a reference on how to design and
create an integrated system that can be used in building large-scale deployments
in general and nation-wide oriented projects in specific.

1.4 Thesis Objective

The main objective of this thesis is to provide an ideal integrated design
pattern for building a wide-scale (nationwide) monitoring system for most of the
environmental pollutants that have been detected in Iraq. The thesis focuses on
the system backend design via choosing the most appropriate available
technologies of the least consuming of the system's computing resources.

9
Chapter One Introduction

1.5 Thesis Contribution

This Thesis gives a complete framework to design a backend architecture
for real-time environmental pollution monitoring systems with the most suitable
technologies of the least compute resources that helps other researchers to
imagine how to design such systems.

1.6 Organization of the Thesis

The thesis has organized as follows:

1- Chapter One explains the general overview related to environmental

pollution in Iraq, literature survey to samples of the previously designed and
implemented system models, the main goal of this thesis, thesis contribution,
and how this thesis has been organized.
2- Chapter Two provides theoretical background related to air pollutants, air
quality scale, sensors, JSON message, applications of IoT messaging
protocols, databases, and Google Maps API.
3- Chapter Three shows the proposed system model that includes sensor
distribution, hardware design, and software design.
4- Chapter Four contains the techniques and results that demonstrate the
proposed system efficiency.
5- Chapter Five includes conclusions and future works.

10
Chapter One Introduction

Summary of the chapter: Introduction

 Section 1.1 illustrates in a general way how the idea of designing a system for
"monitoring environmental pollution in Iraq" emerged.
 Section 1.2 provides a literature survey of some researches related to the
design and implementation of air pollution monitoring systems.
 Section 1.3 presents the problem that was focused on in building the proposed
system.
 Section 1.4 defines the main objectives of the thesis.
 Section 1.5 provides the main contribution of the thesis related to the system
backend design.
 Section 1.6 shows the organization of the thesis chapters.

11
Chapter Two
[Theoretical Background]
Chapter Two Theoretical Background

Chapter Two
Theoretical Background

2.1 Introduction
This chapter presents in general terms the proposed system from a
theoretical background in the context of analyzing air pollutants, how to calculate
the air quality index, system architecture(s), sensors, IoT message format, IoT
messaging protocols, databases, and how to design and display sensors view on
a Google maps API.

2.2 Air Pollution

Air pollution is a concern for society as it directly impacts the environment
and human health. With the increase in environmental pollution in the past few
years, respiratory diseases have become more prevalent with many deaths [30].

2.2.1 Air Quality Standard

The proposed system will adopt one of the most important standards
to calculate the Air Quality Index (AQI). Which has been used by the
US Environmental Protection Agency (EPA) to measure the risk levels of the
five air pollutants: Particulate Matter (10μg/2.5μg of solid or liquid particles),
Sulfur Dioxide (SO2), Ground-Level Ozone (O3), Carbon Monoxide (CO),
and Nitrogen Dioxide (NO2). AQI's benefit is to demonstrate the effect of air
pollutants concentration on human health, according to the six levels listed
in Table 2.1 [31].
Table 2.2 shows the classification of air pollutants concentration ranges
based on AQI risk levels according to US EPA standard [31].

12
Chapter Two Theoretical Background
Table 2.1. AQI Scale [31].
Health concern of
Meaning
AQI levels
Good
This level has no risk; this air quality level is perfect.
(0-50)
Moderate This level is acceptable; it may affect a small group of
(51-100) Unusually sensitive people to air pollutants.
Unhealthy for
The sensitive group of people may suffer negative
Sensitive Group
health effects. But people are not totally affected.
(101-150)
The population may begin suffering negative health
Unhealthy
effects; the sensitive groups of people may suffer more
(151-200)
serious health effects.
Very Unhealthy Health alert; the entire populationَ may suffer more
(201-300) serious health effects.
Hazardous Health warning of emergencies; the entire populationَis
(301-500) more likely to be affected.

Table 2.2-A Breakpoints for AQI [31].

AQI CO (ppm) O3 (ppb) O3 (ppb)
ILow - IHigh DLow- DHigh(Avg) DLow- DHigh(Avg) DLow- DHigh(Avg)
0 – 50 0.0-4.4 (8-hr) - 0-54 (8-hr)
51 – 100 4.5-9.4 (8-hr) - 55-70 (8-hr)
101 – 150 9.5-12.4 (8-hr) 125-164 (1-hr) 71-85 (8-hr)
151 – 200 12.5-15.4 (8-hr) 165-204 (1-hr) 86-105 (8-hr)
201 – 300 15.5-30.4 (8-hr) 205-404 (1-hr) 106-200 (8-hr)
30.5-40.4 (8-hr) 405-504 (1-hr) -
301 – 500
40.5-50.4 (8-hr) 505-604 (1-hr) -

13
 Chapter Two Theoretical Background

Table 2.2-B Breakpoints for AQI [31].

AQI PM10 (μg/m3) PM2.5 (μg/m3) NO2 (ppb) SO2 (ppb)
ILow - IHigh DLow- DHigh(Avg) DLow- DHigh(Avg) DLow- DHigh(Avg) DLow- DHigh(Avg)
0 – 50 0-54 (24-hr) 0.0-12.0 (24-hr) 0-53 (1-hr) 0-35 (1-hr)
51 – 100 55-154 (24-hr) 12.1-35.4 (24-hr) 54-100 (1-hr) 36-75 (1-hr)
101 – 150 155-254 (24-hr) 35.5-55.4 (24-hr) 101-360 (1-hr) 76-185 (1-hr)
151 – 200 255-354 (24-hr) 55.5-150.4 (24-hr) 361-649 (1-hr) 186-304 (1-hr)
201 – 300 355-424 (24-hr) 150.5-250.4 (24-hr) 650-1249 (1-hr) 305-604 (24-hr)
425-504 (24-hr) 250.5-350.4 (24-hr) 1250-1649 (1-hr) 605-804 (24-hr)
301 – 500
505-604 (24-hr) 350.5-500.4 (24-hr) 1650-2049 (1-hr) 805-1004 (24-hr)

To illustrate the cells of Table 2.2-B, the first cell information 0-54 (24hr)
represents the average concentration of Particulate Matter (PM10) measured over
24 hours period, which corresponds to the risk level (0-50) of the AQI.

The Air Quality Index (AQI) value is calculated based on Equation 2.1 [31].
𝐼𝐻𝑖𝑔ℎ −𝐼𝐿𝑜𝑤
𝐴𝑄𝐼 = (𝐷 − 𝐷𝐿𝑜𝑤 ) + 𝐼𝐿𝑜𝑤 (2.1)
𝐷𝐻𝑖𝑔ℎ −𝐷𝐿𝑜𝑤

Where:
ILow = index breakpoint corresponding to DLow,
IHigh = index breakpoint corresponding to DHigh,
D = pollutant concentration,
DLow = pollutant concentration breakpoint ≤ D,
DHigh = pollutant concentration breakpoint ≥ D
For example, suppose that a system recorded an average concentration of
1000 ppb for Nitrogen Dioxide (NO2) through one-hour sensor reading, the result
of AQI value can be calculated as follows [31]:
300 − 201
𝐴𝑄𝐼 = (1000 − 650) + 201
1249 − 650
= 258.85
This result value means that the air quality is in the "Very Unhealthy" level.

14
Chapter Two Theoretical Background

2.2.2 Air Pollution Sensors

There are different types of environmental pollution sensors, but due to the
scale of the system striking optimized dollar-per-sensor value is of uttermost
importance (to reduce the deployment and operation costs). Thus four of the low-
cost sensors with industry-accepted performance were chosen in the system
design to detect the five air pollutants (Particulate Matter, Sulfur Dioxide,
Ground-Level Ozone, Carbon Monoxide, and Nitrogen Dioxide), which are as
follows:

1) CO, NO2, & NH3 Sensor

MICS-6814 Module is used to detect the concentration of the two pollution
elements (Carbon Monoxide range: 1 - 1000 ppm, Nitrogen Dioxide range: 0.05
- 10 ppm, and Ammonia: 1 – 500 ppm). These kinds of pollutants are usually
emitted from automobile exhaust and agricultural/industrial odors [32].
The circuit diagram of this module is shown in Figure 2.1. In the proposed
system, only concentrations of pollutants (CO and NO2) would be collected by
this module as defined by the US Environmental Protection Agency standard.
Figure 2.2 shows the MICS-6814 Module (Front view).

15
Chapter Two Theoretical Background

Figure 2.1. Circuit Diagram of the MICS-6814 Module [32].

Figure 2.2. MICS-6814 Module (Front View).

16
Chapter Two Theoretical Background
2) PM Sensor
SDS011 Module is used to detect particulate matter concentration in both
types (PM10 and PM2.5 range: 0.0-999.9 μg/m3). The working principle of this
module is based on the laser scattering that occurs when particles enter the
detection area using a built-in fan. The scattered light is converted into electrical
signals and then amplified and processed to get the diameters and number of
detected particles. This module can be easily connected via the UART
communication protocol [33]. Figures 2.3 shows the front and back view of the
SDS011 Module.

Figure 2.3. Front and Back View of The SDS011 Module.

3) SO2 Sensor
2SH12 Module is used to detect the sulfur dioxide (SO2) gas concentration
range: 1 to 500 ppm [34]. Figure 2.4 shows the front view of the 2SH12 module.

17
Chapter Two Theoretical Background

Figure 2.4. Front View of The 2SH12 Module.

4) O3 Sensor
MQ-131 Module is used to detect the ozone gas concentration range: 10 –
1000 ppm [35]. Figure 2.3 shows the front and back view of the MQ-131 Module.

Figure 2.5. Front and Back View of The MQ-131 Module.

2.3 Radioactive Pollution

Another very dangerous pollutant is the ionizing radiation from natural or
unnatural sources that can cause severe deformities in people such as DNA
damage, sterility, cancer, and hypersensitivity, and so on, especially what
children and foetuses may suffer from due to their immature Immune systems
like birth defects and chronic diseases [36].

18
Chapter Two Theoretical Background
The study, which was adopted by the World Health Organization (WHO),
showed that exposure to a dose between (50mSv-100mSv or higher) can cause
cancer in humans (mostly in children and adolescents than adults) and may cause
damage to fetal brain. Exposure to a dose of (1000mSv or higher) may weaken
humans tissue and body functions causing severe effects such as hair loss, skin
redness, and syndrome acute radiation and radiation burns [37].

2.3.1 Radiation Thermometer

The proposed system in this thesis will adopt the radiation thermometer
levels used by the Centres for Disease Control & Prevention (CDC) due to its
precise detailَto expose the risks of ionizing radiation doses, as listed in Table 2.3.

Table 2.3. Radiation Thermometer Scale [38].

Radiation dose in
Alerts/Warnings
mSv

10000 This dose results in death by 100%.

4000 This dose could result in death by 50%.

This dose could cause acute radiation syndrome and getting

1000
cancer.

500 This does could cause damage to the blood cells.

If the expected radiation contamination becomes greater for

20 the coming year, recommend relocating people (above the
range of normal).

Naturally occurring/medical exposures (the range of

0 – 10
normal).

19
Chapter Two Theoretical Background

2.3.2 Radiation Detector

One of the most widely used instruments to detect ionizing radiations
(beta particles, alpha particles, and gamma rays) is the Geiger-Muller Counter.
The counter consists of a tube filled with an inert gas that becomes conductive of
electricity when affected by a high-energy particle. The ionization is amplified
inside the tube to produce an easily measurable pulse, which is fed into the
processing and display sections [39]. Figure 2.6 shows the radiation detection
Module used in this research.

Figure 2.6. Radiation Detector.

2.4 Transmission Unit

There are multiple types of transmitters supported by different
technologies used to send sensor readings to the IoT systems, to meet the
requirements of the proposed system for transmitting data via Wi-Fi and GPRS
technologies to the back-end system over the World Wide Web. The T-Call
ESP32 module will be used to do the mission.

T-Call ESP32 Module

It is a small-size wireless module used widely with IoT applications
supported by Wi-Fi, Bluetooth, and GPRS technologies for carrying data
to the endpoints. Figure 2.7 shows the pin diagram of this module [40].
Below are some important specifications of the T-Call ESP32 Module:

20
Chapter Two Theoretical Background
Hardware Specifications:
 Chipset: ESP32 240MHz single-/dual-core 32-bit Microprocessor.
 FLASH Memory: PSRAM 8MB /QSPI flash 4MB.
 SRAM: 520 KB.
 On-board clock: 40MHz crystal oscillator.
 Modular interface: LED PWM, TV PWM, UAR, SPI, SDIO, I2C, I2S,
IRGPIO, capacitor touch sensor, DACLNA pre-amplifier, ADC.
 SIM card: Supports Nano SIM card.

Power Supply Specification:

 Power Supply: USB 5V/1A.
 Battery: 3.7V lithium battery.
 Charging current: 500mA.

Wi-Fi Specification:
 Frequency range: 2.4GHz~2.5GHz.
 Communication distance: 300m.
 Protocol: 802.11 b/g/n -- speed up to150Mbps.

GSM/GPRS SIM800L Specification:

 Support global GSM network with 2G SIM.
 Quad-band: 850/900/1800/1900MHz.
 Send and receive SMS messages.
 Send and receive GPRS data (HTTP, TCP/IP, etc.).

Bluetooth Specification:
 Protocol: Bluetooth BLE standard and v4.2BR/EDR.
 Radio frequency: -97dBm sensitivity NZIF receiver Class-3, Class-2 &
Class-1 emitter AFH.

21
Chapter Two Theoretical Background
Software Specification:
 Wi-Fi Mode: Station/ SoftAP+Station/SoftAP/P2P
 Security mechanism: WPA2-Enterprise/WPA/WPS/WPA2.
 Networking protocol: TCP/UDP/MQTT/HTTP/FTP, IPv4/IPv6, SSL.
 OS: Free RTOS.

Figure 2.7. T-Call ESP32 Module Pin Diagram [40].

2.5 JSON Message Format

JSON (JavaScript Object Notation) is a message format for data exchange.
It is characterized by a lightweight format, ease of reading and writing to humans,
and easy for machines to generate and parse. It is completely language
independent but uses a form that is familiar to programmers. These properties
make JSON an ideal format language for messaging. JSON is structured into a
collection of Key/Value pairs or as a list of values like (array) [41]. An example
for the JSON message {"SensorID": 1557, "Location": "Baghdad",
["Temperature": 45, "Humidity": 16]}.

22
Chapter Two Theoretical Background

2.6 System Architecture

There are several architectural designs that researchers have proposed to
build such a system for real-time air pollution monitoring. Generally, this kind of
system relies on the Internet of Things (IoT) platform to meet the system
requirements for flexible, dense, and wide-scale deployment of low-cost sensors,
as well as managing system data and displaying it in real-time to the population.
The reason for choosing this platform is its efficiency in fulfilling the
requirements of the proposed system, as described in [42].

2.7 IoT Messaging Protocols

Messaging protocols convey the information from the sensors to the back-
end. With a large number of requests, the bandwidth situation becomes a huge
issue especially for the aggregation points where the data from the sensors is
fused together. Hence optimizing the backend design methodology starts from
the network layer via the messaging protocols.
In fact, there are many protocols used in IoT messaging applications such
as CoAP, MQTT, DDS, XMPP, AMQP, and HTTP, but it is very necessary to
know what the highest priority requirements for the system platform are, in order
to choose the most suitable protocol to work with. After reviewing the advantages
and disadvantages of these protocols as shown in [43][44], which generally
revolve around aspects (security, interoperability, service provision, scalability,
reliability, protocol & communication overhead, latency, resource requirement,
bandwidth consumption, and power consumption). The proposed sensors
distribution across cellphone networks, specifically in the tower sites, gave the
greatest attention to how to reduce the internet bandwidth consumption including
messaging protocol and communications overhead to reduce the cost and
complexity of the system design, while the other remaining required aspects are
a foregone conclusion as they are considered within the duties cellphone network.

23
Chapter Two Theoretical Background
Noting that the system air pollution data is considered non-confidential
information (it is publicly posted online).
Therefore, one of the following discovered messaging protocols of lower
overhead and bandwidth will be chosen in managing communications of the
proposed system.

2.7.1 MQTT Protocol

Message Queuing Telemetry Transport-MQTT is a simple lightweight
publish/subscribe broker-based messaging protocol suitable for the constrained
devices such as those used in the IoT network where small size message and low
bandwidth is required. MQTT Header size is 2 bytes. This protocol is based on
the TCP protocol to provide reliable data transmission [45].
MQTT Architecture: The MQTT architecture divided into two main
components as illustrated in Figure 2.8 [46]. The components are briefly
described below.
a) Client: It could be a Subscriber or Publisher and it always establishes the
network connection to the Broker (Server). It can do the following things [45]:
 Subscribe a topic to receive messages.
 Publish messages to the subscribed users.
 Unsubscribe a topic to stop receiving messages.
 Detach from the server (Broker).
b) Broker: It manages the distribution of information. It receives all messages
from the publisher, decides who is interested in it, and then transferring the
messages to all subscribers. It can do the following things [45]:
 Receives Subscriber/Publisher requests.
 Processes the requests like Subscribe and Unsubscribe from clients.
 Receives Published messages.
 After receiving publisher messages sends them to the interested clients.

24
Chapter Two Theoretical Background

Figure 2.8. MQTT Architecture [46].

Figure 2.9. Working of MQTT [46].

25
Chapter Two Theoretical Background

General concepts of MQTT protocol:

a) Quality of Service (QoS) levels: The MQTT protocol describes QoS in terms
of ensuring data distribution. Each sender can choose one of the following
QoS levels to describe the message delivery method [45]:
 At most once: the client sends the message only once to the broker and
there is no acknowledgment of delivery.
 At least once: the sender re-sends the message multiple times until it
receives an acknowledgment of delivery from the receiver.
 Exactly once: The sender and receiver check the connection between each
other to ensure that the message is received only once.
b) Retained messages: In MQTT, the published messages are retained in the
broker after publishing them to all available subscribers. At the point when
another client is gotten for the identical topic, then retained messages of this
topic are transferred to the new customer [45].
c) Clean sessions and reliable connections: The permanent clean session is
considered when a subscriber associates with the broker. In this task, the
successive messages which come out with the highest QoS level are reserved
for delivering when the association is resumed. Using this flag is optional [45].
d) Wills: A client can inform the server (broker) that it has a will (message) that
must be distributed to a particular topic in case of an unwanted detach. this
will is especially valuable in the system such as alarm or security settings
where managers are immediately notified just as a sensor has extinct
connection with the system [45].

2.7.2 CoAP Protocol

The Constrained Application Protocol-CoAP is a web messaging protocol
designed for constrained devices. It is characterized by simplicity and low
overhead, as well as its dependence on the UDP protocol qualifying it to be very
compatible with machine-to-machine and IoT networks. It is based on a

26
Chapter Two Theoretical Background
request/response model for exchanging messages. CoAP uses of GET, PUT,
POST, and DELETE methods similarly to HTTP. CoAP model employs the two
layers (request/response layer and message layer) as shown in Figure 2.10 [47].

Figure 2.10. CoAP Layers [47].

Messages Layer Model
CoAP supports four types of messages which are [47]:
 Confirmable Message: Requires acknowledgment message as a response.
 Non-confirmable Message: does not require an acknowledgment message.
 Acknowledgment Message: used as a response to confirm receipt of the
sent message.
 Reset Message: used as a response to inform that the sent message is
received but couldn't process it.
a) Reliable message transport: Reliability is achieved by making the message
a Confirmable Message (CON). A Confirmable message is retransmitted with
a default delay until the recipient sends an acknowledgment (ACK) with the
same message ID. Figure 2.11 shows an example of this process. When the
recipients are absolutely unable to process a Confirmable message, they
respond with a Reset Message (RST) instead of an ACK [47].

Figure 2.11. Reliable Message Transport [47].

27
Chapter Two Theoretical Background
b) Unreliable message transport: In the event that it does not require reliability
for a particular message it can be sent as a Non-confirmable Message (NON).
It is not acknowledged, but still has a message ID to detect duplicates, Figure
2.12 represents this process. When the recipient cannot process a Non-
confirmable message, it may reply with an RST message [47].

Figure 2.12. Unreliable Message Transport [47].

Requests/Responses Layer Model
a) Piggy-backed: It supports two types of requests Confirmable-CON or Non-
confirmable-NON message, if the client immediately available, the response
will be a Confirmable message in Acknowledgement (ACK) message. This
is called a piggybacked response (There is no need for a separate
acknowledgment), the client will resend the request if the ACK message of
the piggybacked response is lost. Figure 2.13 shows two examples for a basic
request with a piggybacked response [47].

Figure 2.13. The failure and successful response results of GET method [47].
b) Separate response: If the server is unable to immediately respond to a request
transmitted in a CON message, it responds with a blank ACK message so that

28
Chapter Two Theoretical Background
the client stops resending the request. If the response is ready, the server sends
it in a new CON message (that should be acknowledged by the client). This
process is called a "separate response", as shown in Figure 2.14 [47].

Figure 2.14. A Get request with a separate response [47].

c) Non confirmable request and response: If a request is sent in a NON-

message, then the response will be a NON-message, while the server might
instead send a CON-message. Figure 2.15 shows this type of exchange [47].

Figure 2.15. Non confirmable request and response [47].

29
Chapter Two Theoretical Background

CoAP Message Format

CoAP relies on an interchange of compact messages that are sent by default over
UDP (that is, each CoAP message occupies the data section of a single UDP
datagram). CoAP Message uses a simple binary format. The CoAP message
format starts with a fixed size 4 byte header followed by a variable-length Token
value that can range from 0 to 8 bytes in length. After that the Token value comes
a sequence of zero or more options in Type-Length-Value (TLV) format,
optionally followed by a payload [47].

Figure 2.16 CoAP Message Format [47].

Figure 2.17. CoAP Model Architecture Overview [48].

30
Chapter Two Theoretical Background

CoAP vs MQTT

BASIS OF COAP MQTT

Abbreviation Constrained Application Message Query Telemetry

Protocol Transport.
 Request-Response  Publish-Subscribe
model. model.
 One-to-one protocol  Many-to-many protocol
Communication for transferring info for passing info
between client and between multiple
server. clients through a central
(1-to-1 or multi-cast) broker.
Transport layer Runs on UDP Runs on TCP
protocol
Header size 4 bytes 2 bytes

Reliability 2 Levels 3 QoS Levels

mechanism
Security IPSEC or DTLS Not defined in the standard

Table 2.4. A Comparison between CoAP and MQTT Protocol

2.8 Databases
Databases represent the data-stores in the proposed system and are the most
expensive part in any backend system thus a major effort will be devoted towards
optimizing the database operations starting with the main challenge of using the
relational or non-relational approach. Then to decide among the many available
industry implementations like MySQL and the like.

2.8.1 MySQL Database

It is a relational database open-source management system that stores and
organizes the data into separate tables in which data may be related to each other.
It uses the Structured Query Language-SQL standard to access data and perform

31
Chapter Two Theoretical Background
such as INSERT, DELETE, UPDATE, or other activities on the database.
Figure 2.18 shows an example illustrating SQL Statements [49].

Figure 2.18. Example of SQL Statements [49].

2.8.2 Cassandra Database

Apache Cassandra is a NoSQL distributed and open source database. It
offers a partitioned wide-column storage model with eventually consistent
semantics. Cassandra is built for the goals (global availability at low latency, each
additional processor increases the throughput linearly, partitioned key-oriented
queries, flexible schema, online load balancing & cluster growth, full multi-
master database replication, and scaling out on commodity hardware). Cassandra
uses the Cassandra Query Language_CQL, SQL-like language, to update and
create database schema and access data [50].

32
Chapter Two Theoretical Background

2.8.3 Mongo Database

MongoDB is a non-relational database that stores data in a JSON-like
document format, with a flexible schema that can vary over time and can change
fields from document to document. The document form can be easily mapped to
any objects in your code. MongoDB is a distributed DB at its core, so horizontal
scaling, high availability, and geographic distribution are compact and easy to
use. MongoDB is a NoSQL DB that uses a special Query language. MongoDB
stores JSON messages in a binary representation called BSON (BinaryJSON).
Unlike most databases that store JSON messages as numbers and strings, the
BSON encoding extends the JSON representation to include additional types such
as int, date, long, decimal128, and floating-point. This makes it easy for apps
using MongoDB to perform sorting, data comparison, and reliably process.
MongoDB can automatically create a field by adding a 24 digit unique identifier
to each document. Figure 2.19 shows an example for a JSON document stored
in MongoDB [51].

Figure 2.19. Example of a JSON Message Format Stored in MongoDB [51].

2.9 Google Maps API

Actually, there are many map solutions, but the most popular one is Google
Maps API according to statistical reports. The Google Maps API allows you to
harness the power of Google Maps to use it in your web applications to display
your system data online directly in an efficient manner. In order to learn more
about what Maps API is and how to use it within web pages, below is an
explanation of the details that it may need in displaying Google Map [52].

33
Chapter Two Theoretical Background

2.9.1 Loading the Maps API

The Maps JavaScript API can be loaded using the script shown in Figure
2.20, by adding it inline in any HTML webpage script or by using a separate
JavaScript file [52].

Figure 2.20. Google Map API Script [52].

2.9.2 Adding a Marker
The marker is used to identify a location on the map. You can use the
default marker image or set a custom icon as needed. The markers are designed
to be interactive. For example, by adding a listener event, you can bring up an
info window to display any needed information, and it also allows users to move
any marker on the map via the drag feature. Typically, programmers only need to
set a small script when creating the markers on their webpage [52]. Figure 2.21َ
shows a sample of custom markers.

Figure 2.21. Custom Marker Icons.

34
Chapter Two Theoretical Background

2.9.3 Adding an InfoWindow

The InfoWindow is used as an optional feature to displays content (text or
images), and it is often connected to a marker that can be placed on the map
anywhere. The users can open an InfoWindow by clicking the marker or using
another event, and use the "Close" button on the InfoWindow, or use another
event to remove it from the map [52]. Figure 2.22 shows an InfoWindow format.

Figure 2.22. InfoWindow View.

2.9.4 Adding Google Charts

Google Inc. provides professional data visualization charts that can be
easily used on your websites. The most popular way to use these charts is to rely
on JavaScript language to include them on your webpages. These charts can be
displayed on computers, smartphones, and tablet devices. These charts are filled
with data directly or through databases as required [53]. Figure 2.23 shows a
sample chart, which can be displayed by using a simple script.

35
Chapter Two Theoretical Background

Figure 2.23. A Chart.

36
Chapter Two Theoretical Background

Summary of the chapter: Theoretical Background

 Section 2.1 introduces the aspects covered in this chapter.
 Section 2.2 presents, in general, the factor that affects the life of the society,
what is the standard that will be adopted to measure the air quality index in
the proposed system, and what are the sensors' specifications that will be used
in the proposed system.
 Section 2.3 explains what is the effect of radioactive pollution on the life of
the population, what is the standard of ionizing radiation measurement that
will be adopted in the proposed system, and the specifications of the radiation
detector that will be used in the proposed system.
 Section 2.4 describes which data transmission unit will be used to transmit
sensor data to the system application.
 Section 2.5 presents the message format that will be used in transmitting
sensor data to the back-end system.
 Section 2.6 presents the platform to be adopted in the proposed system
architecture.
 Section 2.7 shows the messaging protocols that will be tested in this thesis to
determine which of these are most appropriate in the proposed system design.
 Section 2.8 shows the databases that will be tested in this thesis to determine
which of these are most suitable in the proposed system design.
 Section 2.9 explains what Google Map API is and shows the related aspects
required to design the proposed system.

37
Chapter Three
[Proposed System]
Chapter Three Proposed System

Chapter Three
Proposed System

3.1 Introduction
In this chapter, the proposed system design has been presented
which consists of sensor distribution, sensing unit design, cloud computing
backend architecture, messages design, web application design, and deployment
recommendations.

3.2 Optimum Sensing Locations

Building an organized sensors network to monitor the environmental
pollution for all regions of Iraq from north to south is considered a very important
task to preserve the safety of the population from pollution risks. In addition, to
assisting the government in identifying environmental pollution sites in order to
apply the required prevention and treatment measures to these areas.
At this point, it is evident that such scale cannot be accommodated via
legacy infrastructure solutions, so the proposed system has been designed based
on the Internet of Things (IoT) network platform to provide connectivity between
sensors and the system's web application.
Since it is necessary to have a low-cost sensor distribution model, the
following heuristic to identify the best sites has been suggested:

 Heavily populated residential places.

 Polluted areas caused by wars and bombing with modern weapons.
 Along Iraq's borders with countries that possess nuclear reactors, to alert
local citizens when there is a radiation leak near borders.
 Industrial areas.

38
Chapter Three Proposed System
 Hospitals (where there are patients who are undergoing surgery or have
chronic diseases, also some hospitals may use some radioactive materials
in some types of treatments, and this also need to be monitored to be aware
of any radiation leakage cases).

It is preferable to directly distribute the above sensors in the areas

mentioned with cellphone network towers' locations directly, knowing that the
purpose of this is to provide internet service and places to put the sensors
throughout Iraq (With the exception of hospitals and radiation-contaminated sites
where sensors must be placed near these areas). The benefits behind this method
of distribution are to cover the critical places and to eliminate the following:

 The cost of installing and maintaining the sensors towers and their wireless
connections.
 The cost of network devices and equipment (including routers, switches,
wires, and other connectivity supplies).
 The cost of hardware and security software, which protect the network
from hacking and viruses, as it is a large network that requires a data center.
 The cost of network labor for connecting, monitoring and managing, as
well as the required software for that.
 The cost of network power supply with their spare devices such as;
generators, UPS to keep sensors running continually.

Figure 3.1. Shows the proposed pictorial map along with the system and
its sensor distribution.

39
Chapter Three Proposed System

Figure 3.1. The Proposed System Pictorial Representation.

40
Chapter Three Proposed System

3.3 System Design

The system comprises four main parts; the first part relates to designing
and programming of the air pollutants sensing unit, the second involving the
general design of the cloud computing infrastructure, the third shows the system
messages design and the last consist of designing and programming back-end
web-services interfaces.
3.3.1 Sensing Unit Design
The system-sensing unit consists of the following six devices:
 Geiger counter + GM tube detector module (Gamma, Beta Ray).
 MICS-6814 module. Carbon Monoxide (CO), Nitrogen Dioxide (NO2)
gas detection sensor.
 2SH12 module. Sulfur Dioxide (SO2) gas detection sensor.
 SDS011 module. Dust and smoke (PM10μg/m3, PM2.5μg/m3) detection sensor.
 MQ-131 module. Ozone (O3) gas detection sensor.
 T-Call ESP32 wireless module. This device converts the sensed data into
a JSON message format and sends it via Wi-Fi or GPRS to the system over
the Internet using the CoAP protocol. Wi-Fi technology is used in this
sensing unit when it is necessary to transfer the sensed data from anywhere
supported by the Internet service such as (Hospitals, Cellphone Towers, or
others) to the system cloud service, while GPRS technology is used to send
the sensed data from pollution sources such as (roads, or others)
specifically in radioactively contaminated areas where a direct and close
radiation detector is required.

The flowchart shown in Figure 3.2 illustrates the working steps of the
proposed sensing module software (for more detail about system messaging
design, see Section 3.3.3), while Figure 3.3 presents the component diagram of
the proposed sensing unit.

41
Chapter Three Proposed System

Figure 3.2. The Proposed Flowchart of The Sensing Module Software Design.

42
Chapter Three Proposed System

Figure 3.3. Sensing Unit Diagram.

43
Chapter Three Proposed System

3.3.2 Cloud Computing Design

The cloud computing platform has been proposed as an incubator
environment for the system servers that archive, process, analyze, and display the
collected sensors data as a real-time service to the society, due to its substantial
capabilities in data processing, unlimited storage, and having the necessary
security protection for the system. The proposed system design with the four main
servers is summarized in Figure 3.4.

 CoAP Server is responsible for exchanging messages between the sensing

units and the system's web application. This server receives data from
all sensors over the mobile network and transmits it to the MongoDB server
using a certain script written in JavaScript.

 Mongo Database Server is responsible for storing and managing received

messages of all distributed sensing units as well as for archiving the
calculated average concentration results of all pollutants and air quality
index values.

 Web Server is responsible for storing, managing, and displaying the

system application webpages that are supported by the public IP address,
Domain Name Service (DNS), and Google Maps API, to have a website
ready for the public.

 MySQL Database Server is responsible for storing and managing all

the relational system information related to users, departments, sensors,
and notifications (it stores all information that requires a relationship with
each other).

44
Chapter Three Proposed System

Figure 3.4. System Cloud Computing Components Structure.

Figure 3.4 illustrates the proposed system workflow that requires the
following action steps to fulfill its duty to display sensor readings on the Google
Map as a service to residents:

(1) Initially, the locations of the sensors (city, district, longitude and latitude)
must be entered in order to enable the system to display them on the Google Map.

(2) The CoAP server receives sensor readings in the form of JSON messages from
all sites every 7.5 minutes and every hour.

(3) The CoAP server uses an acknowledge message as a response to confirm

receipt of each received message.

45
Chapter Three Proposed System
(4),(5) The CoAP server instantly transfers each received JSON message to
Mongo database server using a specific script.

(6),(7) The web server prepares a JSON message hourly using the latest saved
data in the MySQL and Mongo databases to be ready to display all sensor
locations, pollutant concentrations, and AQIs at the request of the website visitor.

(8),(9) Finally, the website visitor is able to view the sites and data of all the
sensors on Google Map at any desired time.
3.3.3 Messages Format Design
The system messages are split into two JSON message formats that clients
(Wi-Fi/GPRS Modules) use to carry sensors data to the CoAP server which in
turn transfer these messages to the Mongo database server using a specific script,
the purpose of this partitioning is to give the system database the advantage of
horizontal sharding technique, which adds horizontal scalability and optimizes
the overall performance of system queries, the following shows more details
about these messages:
3.3.3.1 Type-1 Message Format
This type of message is sent every 7.5 minutes (8 messages per hour)
to the system and is approximately the size of 52 bytes, this size varies with the
number of digits of the sensing values or the number of pollutants carried by the
message as needed, this message format carries the sensing unit ID as well as the
concentration of pollutants (Sulfur Dioxide (SO2), Nitrogen Dioxide (NO2), and
ionizing radiation (RD)). The purpose of retransmitting this message in shorter
intervals than the Type 2 message was to allow for the most serious pollutant
concentration to be sent as quickly as possible to the system, as well as to take
advantage of the close timestamp in order to keep the sensors checked.
An example of what this message might look like is, {"ID":597,"NO2":
5.85493,"SO2":112.45158,"RD":2.0588}.

46
Chapter Three Proposed System
3.3.3.2 Type-2 Message Format
This type of message is sent every 1 hour to the system and is
approximately the size of 61 bytes, this size varies with the number of digits of
the sensing values or the number of pollutants carried by the message as needed,
this message format carries the sensing unit ID as well as the concentration of
pollutants (Carbon Monoxide (CO), Ground-Level Ozone (O3), Particulate
Matter (PM2.5µg), and Particulate Matter (PM10µg)).
An example of what this message might look like is, {"ID":106,"PM10":
620.8764,"PM2":749.8257,"CO":4.21,"O3":8.45}.
3.3.4 Web Application Design
To ensure the achievement of comprehensive access coverage to the
system application and all visitors and users of the World Wide Web for cities in
Iraq, the proposed system has been implemented to achieve this requirement.

The proposed system used HTML, CSS, PHP, and JavaScript

programming languages in addition to the “Bootstrap” library for easy display of
webpages on phones and smart tablets. The system has been designed with three
main webpages as follows, note that the Arabic language has been taken as the
primary language for the system's front-end interfaces in order to provide easy
interaction with supervisors and visitors.

3.3.4.1 Administrator Dashboard Webpage

The webpage layout shown in Figure 3.5 provides the following functions:
1) User (Admin/Supervisor) Management [Add/Delete/Modify/Activate]. It
includes three sub-webpages responsible for adding, modifying, and
displaying all the information required for managing system users such as
(username, password, email, job title, user registration status, registration
date, permission, avatar, and the department to which user belongs), as
shown in Figure 3.6 and Figure 3.7.

47
Chapter Three Proposed System

Figure 3.5. Administrator Dashboard Webpage.

Figure 3.6. User Management Webpage.

48
Chapter Three Proposed System

Figure 3.7. User Add/Edit Webpage.

2) Sensor Management [Add/Delete/Modify/Activate/Deactivate]. It includes

three sub-webpages responsible for adding, modifying, and displaying all
the information required for managing system sensors such as (sensor ID,
sensing unit description, latitude and longitude for the sensor location, city
and district of site, registration date, activation status, and the department to
which it belongs), as shown in Figure 3.8 and Figure 3.9.

49
Chapter Three Proposed System

Figure 3.8. Sensor Management Webpage.

Figure 3.9. Sensor Add/Edit Webpage.

50
Chapter Three Proposed System
3) Department Management [Add/Delete/Modify/Visibility]. It includes three
sub-webpages responsible for adding, modifying, and displaying all the
information required for managing system departments that used to
distribute the management responsibilities of each sensor site to the
system users according to the sensor location, as shown in Figure 3.10 and
Figure 3.11.

Figure 3.10. Department Management Webpage.

51
Chapter Three Proposed System

Figure 3.11. Department Add/Edit Webpage.

4) Sensors Monitoring Map. In this sub-webpage, the Google Maps API has
been used to display the average concentration of all pollutants and air
quality indexes for all sites and showing their risks to human health, it has
a similar design to the Citizen Service Webpage, that is shown in detail later.
5) Notifications Bar Management [Add/Delete/Modify/Activate]. It includes
three sub-webpages responsible for adding, modifying, and displaying all
the information required for managing system notifications such as
(notification text, posting date, publisher user, publisher department, and
activation status), as shown in Figure 3.12 and Figure 3.13.

52
Chapter Three Proposed System

Figure 3.12. Notifications Bar Management Webpage.

Figure 3.13. Notifications Add/Edit Webpage.

6) Data Search Engine. It includes two sub-webpages, one of which provides
a flexible search to get the concentrations of all pollutants and AQI values
for all available sensor sites in the system database, and another sub-
webpage to display the search results in form of a report to the system
admins or supervisors, as shown in Figure 3.14, Figure 3.15.

53
Chapter Three Proposed System

Figure 3.14. Data Search Engine Webpage.

54
Chapter Three Proposed System

Figure 3.15. Data Search Results Webpage.

55
Chapter Three Proposed System
7) Latitude and Longitude Finder. It has a sub-webpage used as a tool to
facilitate obtaining the latitude and longitude of any location on the Google
Map in order to determine the placement of the required new site, as shown
in Figure 3.16.

Figure 3.16. Latitude and Longitude Finder Webpage.

8) Showing the total number of visitors to the system’s websites, as shown on
the Administrator Dashboard Webpage.
9) Showing information of the seven last added users, sensors, and ads, as
shown on the Administrator Dashboard Webpage.
10) Sensors Inspection. A suitable algorithm has been designed for checking
work all system sensors, the working steps of the algorithm are shown in
detail in the flowchart diagram Figure 3.17. The system administrators or

56
Chapter Three Proposed System
supervisors can obtain the sensors inspection report at any time by running
the proposed algorithm script.

Sensors Inspection Algorithm

The working steps of the algorithm are listed below:

 Check the timestamp of the last received data for each site which
leads us to use the (Sdata7.5min collection) of Mongo database
because its data contains the closest period of received data (it Receives
data every 7.5 minutes from the sensors), if the timestamp does not
exist in the collection, that indicates the sensors' Wi-Fi device is
(OFF/Deactivated) or there may be a problem in the Internet network.
 If the timestamp is present, it allows finding the difference between the
timestamp and the time of the current date if the result value is greater
than 10 minutes. This indicates that the sensors' Wi-Fi device is
(OFF/Deactivated) or there may be a problem in the Internet network
and if the result is less than or equal to 10 minutes that means that the
Wi-Fi is active and it is possible to switch to the next stage of checking.
 The next checking stage takes place on each sensor of each site this
stage is done by checking the received value of each sensor from
(Sdata7.5min and Sdata1hour collection) if existed and is numeric, go
to the final checking, if the reading value of the sensor within the range
of the sensor's datasheet that indicates the sensor is active and has no
problem, otherwise there is a problem in this sensor and it may need to
be replaced.
 The last stage displays the results of the inspection algorithm as a
readable report in the form of a webpage familiar to system
administrators and supervisors as needed, as shown in Figure 3.18.

57
Chapter Three Proposed System

Figure 3.17. Flowchart of the Sensor-Checking Algorithm.

58
Chapter Three Proposed System

Figure 3.18. Sensors Checking Results Webpage.

59
Chapter Three Proposed System
3.3.4.2 Supervisors Control Panel Webpage
The webpage layout is shown in Figure 3.19. It provides some system
Administrator Dashboard Webpage features with permission restricted to the
logged-in supervisor's area sensors, as shown below:
 Notifications Bar Management [Add/Delete/Modify].
 Data Search Engine.
 Latitude and Longitude Finder.
 Sensors Inspection. Here the supervisors use the same algorithm proposed for
the administrator control panel to verify that the system sensors are working
properly.
 Sensors Management [Add/Delete/Modify].

Figure 3.19. Supervisors Control Panel Webpage.

60
Chapter Three Proposed System

3.3.4.3 Main Webpage/Citizen Service Webpage

The webpage layout is shown in Figure 3.20 and consists of:
 Sensors Monitoring Map, which displays average concentration and air
quality index value of all pollutants inside color-coded InfoWindow for all
distributed sensor sites using Google Maps API to inform system website
visitors by the risk levels of contaminated areas. The proposed system
automatically updates this webpage every hour with the latest data received
from the sensors.
 User Information Bar, through which the supervisor can log in, log out, or
access his personal profile.
 Manu Bar, through which the supervisor can access his Control Panel
Webpage.
 Notifications Bar, which shows the necessary instructions that help residents
maintain their health.
 Air Quality Index (AQI) Chart, which shows the AQI values of last month
for each distributed sensing site.

61
Chapter Three Proposed System

Figure 3.20. Citizens Service Webpage.

3.4 Deployment Recommendations
In order to roll the proposed system into the production stage, the following
requirements are to be met:
1) Sensing Unit:
a. Sensors (PM10, PM2.5, CO, O3, NO2, SO2, RD).
b. Data-transmission module (Wi-Fi/GPRS).
c. Internet connection.
2) CoAP Server with a public IP address (hardware sizing follows the number of
requests).
3) Web Server with a public IP address.
4) Domain name for the service.
5) Subscription for Google Maps API.
6) MySQL server (hardware sizing follows the number of requests).
7) MongoDB server (hardware sizing follows the number of requests).

62
Chapter Three Proposed System

Summary of the chapter: Proposed System

 Section 3.1 introduces the aspects covered in this chapter.
 Section 3.2 discusses the best sites for distributing the proposed system
sensors and why this choice is made.
 Section 3.3 provides details of the proposed system design consisting of
(sensing unit design, cloud computing design, messages format design, and
web application design).
 Section 3.4 lists the system requirements that it needs to enter the service.

63
Chapter Four
[Results & Discussion]
Chapter Four Results and Discussion

Chapter Four
Results and Discussion
4.1 Introduction
In this chapter, the obtained practical results of the tested techniques
(system messages, messaging protocols, and system databases) have been
presented, in order to clarify the efficiency of back-end system technologies that
have been selected based on the best results.

4.2 System Messages

After applying the proposed system messages with the target application, it has
been observed that they require the following:

4.2.1 Type-1 Message Format

 The execution time of insert 1000 messages in Mongo DB is 0.946 sec.
 One index for each message stored in Mongo DB.
 The total index size is 681.9 MB to save (70,080,000 messages) as one-year
estimated data in Mongo DB.
 The total document size is 6.9 GB to save (70,080,000 messages) as one-year
data estimated in Mongo DB.
4.2.2 Type-2 Message Format
 The execution time of insert 1000 messages in Mongo DB is 0.979 sec.
 One index for each message stored in Mongo DB.
 The total index size is 84.8 MB to save (8,760,000 messages) as one-year
estimated data in Mongo DB.
 The total document size is 952.4 MB to save (8,760,000 messages) as one-
year estimated data in Mongo DB.

64
Chapter Four Results and Discussion

4.3 System Messaging Protocol

In this proposed system, consideration has been given to choose the most
suitable protocol for exchanging sensor messages with the system web
application, after testing the most popular messaging protocols of the lowest
bandwidth and communication overhead, namely MQTT and CoAP. CoAP
protocol has been selected to perform system tasks due to the following results:
4.3.1 MQTT Protocol
 The total internet download bandwidth required for the system to receive
(1000 messages) of this type via the MQTT server is 569.34 KB/s including
MQTT overhead, TCP overhead, IP overhead, and messages topic, while each
message requires 583 bytes download bandwidth.
 The total internet upload bandwidth required for the system to receive (1000
messages) of this type via the MQTT server is 279.29 KB/s including MQTT
overhead, TCP overhead, and IP overhead, while each message requires 286
bytes upload bandwidth.
4.3.2 CoAP Protocol
 The total internet download bandwidth required for the system to receive
(1000 messages) is 136.72 KB/s including CoAP overhead, UDP overhead, IP
overhead, and messages URL, while each message requires 140 bytes
download bandwidth.
 The total internet upload bandwidth required for the system to Acknowledge
receive (1000 messages) is 44.92 KB/s, while each message requires 46 bytes
upload bandwidth.

4.4 System Database

The Mongo database is responsible for storing all messages sent by sensors
to the proposed system, this indicates it deals with system queries that carry out
a large number of reading and writing operations for a large number of messages
that directly and significantly affect system efficiency.

65
Chapter Four Results and Discussion
For this reason, this study takes care to choose the most appropriate
database for storing the system messages, by testing the system main scripts
with three main categories of open source databases that support JSON message
format (MySQL RDBMS, Cassandra NoSQL Column DB, and Mongo NoSQL
Document DB), as shown in Table 4.1. Note: All the tested databases were
indexed equally and loaded with one-year estimated data for fairness during
the comparison.
Table 4.1. Databases Performance Comparison.
(MySQL) (Cassandra) (MongoDB)
Script Description
Execution Time Execution time Execution time

Insert It is responsible for importing type-1 JSON 4.266 sec 1.924 sec 0.946 sec
type-1 message format which sends every 7.5
message minutes from all sensing units to the system
database.
This script has been tested to archive 1000
messages (1000 sites), each message
consists of reading data of three pollutants.
 Use JSON insert query to save this kind
of messages plus timestamp for each
message received.
Insert It is responsible for importing type-2 JSON 4.437 sec 2.269 sec 0.979 sec
type-2 message format which sends every 1 hour
message from all sensing units to the system
database.
This script has been tested to archive 1000
messages (1000 sites), each message
consists of reading data of four pollutants.
 Use JSON insert query to save this kind
of messages plus timestamp for each
message received.

66
 Chapter Four Results and Discussion
Hourly It is responsible for carrying out the 1.525 sec 1.430 sec 0.886 sec
Auto following actions every hour:
Running  Calculating the average concentration
and AQI values for all pollutants for all
sensor sites from which the data was
recently received (stored in the database).
 Archiving the calculated result in the
database server to be ready for bringing them
in case of need.
 Organizing and archiving the result values as
JSON format to provide a fast display for the
latest received sensors’ information on
Google Map.
This script has been tested for 18 sites (each
site consists of 7 sensors) with one-year of
estimated data.
 Use select query to fetch and extract a
number of the last keys' values of the two
received JSON messages from all sites.
 Use insert query to archive AQI and Avg.
of pollutants concentrations for all sites.
Sensors In this script, the system checks the working 280.22 sec 0.659 sec 0.303 sec
inspection of all transmitter units (Wi-Fi/GPRS
Module) based on the timestamp of the
latest received data, as well as verifying the
truth of the data received from all sensors,
and preparing a visual report for the system
administrators/supervisors when needed.
This script has been tested for 19 sites with
one-year of estimated data).
 Use select query to fetch and extract the
last keys' values of the two received JSON
messages from all sites.

67
Chapter Four Results and Discussion
Chart It is responsible for displaying the AQI 6.544 sec 23.216 sec 2.811 sec
values for any sensor for last month's
reading. This chart is available online and
allows all people to view it.
 Use count query to count AQI column/key
that includes 487787 values for a single
site.
 Use select query to fetch the last 720
values of AQI column/key using the count
result as an offset.
Search This script is available only to the system 4.943 sec 14.623sec 1.353 sec
administrators/supervisors to give all
information available about any sensor for
any chosen period.
This script has been tested to fetch 26288
docs/rows (Each doc/row contains all
pollutant concentrations and AQI for one
site).
 Use select query to fetch multiple-
column/key values, some of the selected
columns/keys restricted by a range of
values.

What was observed from the execution of the six main scripts shown above
of the proposed system, especially after testing the system with more than one
database, as shown in Table 4.1, that there is a significant impact of some queries
used in reading and writing data through which it was found that MongoDB
database preferred to the work, for the following reasons:
 Scripts 1, 2: These scripts show that MongoDB has better performance for
importing JSON messages into the system database because MongoDB
does not need to split the received messages into structured separate storage

68
Chapter Four Results and Discussion
units like tables and columns, it drops the message as a single piece due to
its native JSON data store.
 Scripts 3, 4: The select queries used in these scripts are very complex due
to their duties related to searching inside JSON messages which have
variable formats from site to site as needed, so these types of queries
require certain features to fetch the last stored messages that carry a
specific sensor ID and pollutant key which means that every query needs
(searching inside all stored messages to obtain values of the required keys,
and sorting all documents in descending order to get the last messages for
the specified keys, in addition to that these sorted messages need to be
limited to a number of messages). These queries got the best results with
MongoDB as shown in Table 4.1 because MongoDB works with simpler
data structures that make data retrieval tend to be faster in it especially for
large volumes of unstructured data such as JSON messages that the system
handles.
 Scripts 5: This script requires two queries one of which is to count all
archived AQI values of a specific sensor ID that are stored in the collection
or table depending on the database used, then use the count result in another
query as an offset to fetch the last 720 documents or rows to be displayed
on a chart. MongoDB gave a faster execution time to show this chart as
shown in Table 4.1 because MongoDB has a simple document-oriented
data structure that helps to do the duty of this operation in a very high-
speed manner.
 Script 6: This script relies on a flexible select query to fetch a set of
unorganized values as needed for multiple keys or columns (including
timestamps, averages of pollutants, and AQIs), and this query has been
greatly affected by the database indexing, so the tested databases have been
indexed fairly before testing them. As can be seen from Table 4.1,

69
Chapter Four Results and Discussion
MongoDB achieved a great result in performing this process compared to
other databases due to its flexibility and ease of navigation between the
multiple indexed objects in the same document, which showed better
results than moving between multiple indexed columns bound by a set of
values that required more complex tasks.

70
Chapter Four Results and Discussion

Summary of the chapter: Results and Discussion

 Section 4.1 introduces the aspects covered in this chapter.
 Section 4.2 presents the results obtained when loading the proposed system
with sensor readings messages.
 Section 4.3 describes why CoAP was chosen for managing the proposed
system communications.
 Section 4.4 describes why the Mongo database was chosen to store sensor
readings in the proposed system.

71
 Chapter Five
[Conclusions & Future Work]
Chapter Five Conclusions and Future Work

Chapter Five
Conclusions and Future Work
5.1 Conclusions
In this thesis, a guide is provided for selecting the most suitable
technologies that can be used to design and implement nation-wide integrated
system that meets the requirements of real-time environmental pollution
monitoring as a wide-scale community service. The following techniques have
been adopted to build this system due to the best cost and practical results
observed from testing and re-architecting the main system aspects:
 The system web application is to be built with standard web-technology
instead of using custom proprietary applications to save on the system costs
by using (web-sockets, HTML5, HTTP-servers, MySQL Database, and
Mongo Database).
 The JSON message format is to be used to exchange the data between the
sensors and the system web application, as well as displaying the results
on the Google map. It has been chosen due to its ease of reading, parsing,
and generation compared to other data-interchange formats.
 The CoAP messaging protocol has been chosen for the target system due
to its minimum overhead and bandwidth required for message exchanged
in comparison to the MQTT protocol. Thus, using a CoAP server instead
of an MQTT server (industry norm) reduced the download bandwidth by a
factor of 76% and the upload bandwidth by a factor of 84% when receiving
and sending system messages. It should be emphasized that a difference of
1KB is not of a big importance on the sensor side, but for the target scale,
the aggregation is the one that makes the difference. That 1KB/s quickly
escalates to 1GB/s with 1,000,000 reads and write operations. A finding

72
Chapter Five Conclusions and Future Work

that is often missed by the previous works as they emphasized totally on

the sensing part not accounting for its effects on the backend.
 Comparison of the current industry standard databases showed that for the
target use-case, Mongo database is the best choice for the system
architecture due to the excellent performance in writing and reading JSON
messages especially through the robust response to inserting, sorting, and
retrieving queries for the multi-key indexed data that the system scripts
handle which faced a slow response with other tested databases. MongoDB
gave a powerful schema-free architecture that made it well-suited for the
very high-speed and wide-scale logging, also caching, especially for the
changeable message formats that the system needs to deal with. This arises
for the cases of deleting or adding pollutants carried over the message
according to the area's requirement. In addition, the MySQL database has
been selected for storing the system relational data that needs security due
to its effective ability to manage such data. Thus it can be concluded that,
for such systems, a multitude of relational and NoSQL solutions is to be
used as best suits the target deployment and business case.

5.2 Future Work

 The Iraqi Ministry of Health and Environment can take advantage of this
system as a service to protect society and reduce health impacts related
to air pollutants.
 There are other aspects related to this proposed system that other
researchers can consider to make it more efficient and fully serviceable.
The suggestions work for future can summarize as the following:
1) Study and provide the necessary security for the system.
2) Develop the system's air quality analysis process through the artificial
intelligence aspect.

73
Chapter Five Conclusions and Future Work

Summary of the chapter: Conclusions and Future Work

 Section 5.1 presents the conclusions obtained through the proposed system
design related to (the system application interfaces, selection of the JSON
format for exchanging and displaying sensor data on the map, choosing a
CoAP protocol to manage the proposed system backend communications, and
choosing a Mongo database in storing and managing sensors data).
 Section 5.2 introduces who can benefit from the system's functionality and
what other aspects are required that make the system complete and
serviceable.

74
References
References

References
[1] M. T. Chaichan, H. A. Kazem, and T. A. Abed, “Traffic and outdoor air
pollution levels near highways in Baghdad, Iraq”, Environment, Development
and Sustainability, 20(2), 589-603, 2018.
[2] S. H. Shehabalden, and N. M. Azeez, “Air quality index over Basra province,
south of Iraq”, International Journal of Technical Research and Applications,
2017.
[3] D. Khoshnevisan, et al., “Environmental pollution in the common borders
between Iran and Iraq and the international governing documents”, EurAsian
Journal of BioSciences, 13(1), 541-548, 2019.
[4] N. A. Al-Ansari, S. Knutsson, and R. Pusch, “Environmental Implications of
Depleted Uranium in IRAQ and Principles of Isolating It,” Waste
Management, 367-376, 2014.
[5] S. A. Menkhi, F. H. Shanoon, and B. A. Almayahi, “Radiation pollution and
cancer risks in Sulaimaniyah and Ninawa Cities, Iraq”, Annual Research &
Review in Biology, 1-9, 2017.
[6] I. T. Al-Alawy, and O. A. Mzher, “Radiological characterization of the irt-
5000 (14-Tammuz) research nuclear reactor at Al-Tuwaitha nuclear center in
Iraq”, Environmental Earth Sciences, 1-9, 2019.
[7] F. H. Shanoon, et al., “Spatial and Temporal Variability of Environmental
Radioactivity in Basra and Baghdad Cities, Iraq”, Annual Research & Review
in Biology, 1-9, 2017.
[8] S. A. Mishra, D. S. Tijare, and G. M. Asutkar, "Design of energy aware air
pollution monitoring system using WSN", International Journal of Advances
in Engineering & Technology, 1(2),107, 2011.
[9] Y. J. Jung, et al., "Design of sensor data processing steps in an air pollution
monitoring system", Sensors, 11(12), 11235-11250, 2011.

75
References

[10] J. Ikram, et al., "View: implementing low cost air quality monitoring solution
for urban areas", Environmental Systems Research, 1(1), 1-8, 2012.
[11] D. Yaswanth, and S. Umar, "A Study on Pollution Monitoring system in
Wireless Sensor Networks", International Journal of Science, Engineering
and Computer Technology, 3(9), 324, 2013.
[12] A. R. Kasar, D. S. Khemnar, and N. P. Tembhurnikar, "WSN based air
pollution monitoring system", International Journal of Science and
Engineering Applications, 2(4), 55-59, 2013.
[13] G. Swagarya, S. Kaijage, and R. S. Sinde, "Air pollution monitoring system
based on wireless networks simulation", Innovative Systems Design and
Engineering, 5(8), 1727-2222, 2014.
[14] V. K. Ustad, A. S. Mali, and S. S. Kibile, "Zigbee based wireless air
pollution monitoring system using low cost and energy efficient
sensors", International Journal of Engineering Trends and Technology, 10(9),
456-460, 2014.
[15] F. Ye, X. Liu, and Y. Liu, "Design and Implementation of Real-Time
Forecasting System of Urban Air Quality Based on Observation Sites and
Thiessen Polygon", 2nd International Conference on Sensors, Instrument
and Information Technology, China, 2015.
[16] N. Kaur, et al. "Air quality monitoring system based on Arduino
microcontroller", International Journal of Innovative Research in Science,
Engineering and Technology, 5(6), 9635-9646, 2016.
[17] K. Zheng, et al., "Design and implementation of LPWA-based air quality
monitoring system", IEEE Access, 4, 3238-3245, 2016.
[18] Y. Chen, J. Li, and C. Qi, "Design and implementation air quality monitoring
robot", IOP Conference Series: Earth and Environmental Science, China,
Vol. 52, No. 1, p. 012089, 2017.

76
References

[19] P. Partheeban, and B. Shanthini, "Design and Implementation of Equipment

for Air Quality Information Management System", Journal of Advances in
Information Technology, Vol, 9(4), 2018.
[20] J. H. Jo, et al., "Implementation of IoT-Based Air Quality Monitoring
System for Investigating Particulate Matter (PM10) in Subway
Tunnels", International Journal of Environmental Research and Public
Health, 17(15), 5429, 2020.
[21] T. S. Gunawan, et al., "Design and implementation of portable outdoor air
quality measurement system using Arduino", International Journal of
Electrical and Computer Engineering, 8(1), 280, 2018.
[22] Y. Y. F. Panduman, et al., "Implementation of integration VaaMSN and
SEMAR for wide coverage air quality monitoring", TELKOMNIKA
(Telecommunication, Computing, Electronics and Control), 16(6), 2630-
2642, 2018.
[23] S. Chowdhury, et al., "Design and Implementation of an IoT Based Air
Pollution Detection and Monitoring System", 5th International Conference
on Advances in Electrical Engineering (ICAEE), Bangladesh, pp. 296-300,
2019.
[24] D. V. Mahammad, "Design and Implementation of IoT based Portable
Outdoor Dust Density Monitoring System", International Research Journal
of Engineering and Technology (IRJET), 2019.
[25] P. Purwanto, S. Suryono, and S. Sunarno, "Design of Air Quality Monitoring
System Based On Web Using Wireless Sensor Network", Journal of
Physics: IOP Conference Series, Indonesia, Vol. 1295, No. 1, p. 012043,
2019.
[26] T. H. Nasution, M. A. Muchtar, and A. Simon, "Designing an IoT-based air
quality monitoring system", IOP Conference Series: Materials Science and
Engineering, Indonesia, Vol. 648, No. 1, p. 012037, 2019.

77
References

[27] R. Bhambare, and S. Khairnar, "IOT BASED NOISE AND AIR QUALITY
MONITORING SYSTEM", International Research Journal of Engineering
and Technology (IRJET), 2020.
[28] P. Shinde, et al., "Android based Air Pollution Monitoring System", Mukt
Shabd Journal, 9(VI), 2020.
[29] Y. U. Tong, et al., "Design of air quality monitoring system based on light
scattering sensor", IOP Conference Series: Earth and Environmental
Science, China, Vol. 647, No. 1, p. 012196, 2021.
[30] A. Singh, H. Joshi, A. Srivastava, R. Kumar, and N. Hasteer, “An Analysis
of Polluted Air Consumption and Hazards on Human Health: A Study
Towards System Design”, 10th International Conference on Cloud
Computing, Data Science & Engineering (Confluence), India, pp. 532-539,
2020.
[31] D. A. Vallero, “Air pollution calculations: Quantifying pollutant formation,
transport, transformation, fate and risks”, Elsevier, 2019.
[32] SGX., “CO, NO2, NH3 Gas Sensor Datasheet”, [online] Available at:
<https://datasheetspdf.com/pdf/1350171/SGX/MiCS-6814/1> [Accessed 15
March 2021].
[33] ETC., “Particulate Matter (PM10, PM2.5) Sensor Datasheet”, [online]
Available at: <https://datasheetspdf.com/pdf/1226510/ETC/SDS011/1>
[Accessed 15 March 2021].
[34] Hanwei Electronics, “SO2 Gas Sensor Datasheet”, [online] Available at:
<https://datasheetspdf.com/pdf/904646/HANWEIELECTRONICS/MQ-
136/1> [Accessed 15 March 2021].
[35] ETC., “Ozone Gas Sensor Datasheet”, [online] Available at:
<https://datasheetspdf.com/pdf/770517/ETC/MQ-131/1> [Accessed 15
March 2021].

78
References

[36] R. Guleria, et al., “Harmful Effects of Ionizing Radiation”, International

Journal for Research in Applied Science and Engineering Technology,
7(12), 887-889, 2019.
[37] Who int., “Ionizing radiation, health effects and protective measures”,
[online] Available at: <https://www.who.int/news-room/fact-
sheets/detail/ionizing-radiation-health-effects-and-protective-measures>
[Accessed 11 February 2021].
[38] Cdc gov., “CDC Radiation Emergencies: Radiation Thermometer”,[online]
Available at:
<https://www.cdc.gov/nceh/radiation/emergencies/radiationthermometer.ht
m> [Accessed 11 February 2021].
[39] G. F. Knoll, “Radiation detection and measurement”, John Wiley & Sons,
2010.
[40] LILYGO®, “TTGO T-Call V1.4 ESP32 Wireless Module Specifications”,
[online] Available at:
<http://www.lilygo.cn/prod_view.aspx?TypeId=50044&Id=1127&FId=t3:
50044:3> [Accessed 30 April 2021].
[41] I. Ecma, “The JSON Data Interchange Syntax", Standard ECMA-404 2nd
2017, [online] Available at: <https://www.ecma-
international.org/publications-and-standards/standards/ecma-404/>
[Accessed 15 March 2021].
[42] Z. Idrees, Z. Zou, and L. Zheng, "Edge computing based IoT architecture
for low cost air pollution monitoring systems: a comprehensive system
analysis, design considerations & development", Sensors, 18(9), 3021,
2018.
[43] N. Naik, "Choice of effective messaging protocols for IoT systems: MQTT,
CoAP, AMQP and HTTP", IEEE international systems engineering
symposium (ISSE), Austria, pp. 1-7, 2017.

79
References

[44] E. Al-Masri, et al., "Investigating messaging protocols for the Internet of

Things (IoT)", IEEE Access, 8, 94880-94911, 2020.
[45] O. A. S. I. S. Standard, “MQTT Version 5.0”, Retrieved June, 2019.
[46] D. Soni, & A. Makwana, “A survey on mqtt: a protocol of internet of things
(iot)”, International Conference On Telecommunication, Power Analysis
And Computing Techniques (ICTPACT-2017)”, India, Vol. 20, 2017.
[47] Z. Shelby, K. Hartke, and C. Bormann. "The constrained application
protocol (CoAP)", CoAP RFC 7252 Standard 2014, [online] Available at:
<https://iottestware.readthedocs.io/en/master/coap_rfc.html> [Accessed 15
March 2021].
[48] M. A. Tariq, et al., "Enhancements and Challenges in CoAP—A
Survey", Sensors, 20(21), 6391, 2020.
[49] E. Vanier, B. Shah, & T. Malepati, “Advanced MySQL 8: Discover the full
potential of MySQL and ensure high performance of your database”, Packt
Publishing Ltd., 2019.
[50] Eben. Hewitt, “Cassandra: the definitive guide”, O'Reilly Media, Inc., 2010.
[51] K. Chodorow, “MongoDB: the definitive guide: powerful and scalable data
storage”, O'Reilly Media, Inc., 2013.
[52] G. Svennerberg, “Beginning Google Maps API 3”, Apress, 2010.
[53] Google Developers, “Charts: Google Developers”, [online] Available at:
<https://developers.google.com/chart> [Accessed 11 February 2021].

80
Appendix
Appendix

Appendix
List of Papers:
1) Taha E. Al-jarakh, Osama A. Hussein, Alaa K. Al-azzawi, and Mahmood F.
Mosleh, “Design and implementation of IoT based environment pollution
monitoring system: A case study of Iraq,” IOP Conference Series: Materials
Science and Engineering, Iraq, 2020. (Indexed by: Scopus).

81
Appendix

2) Taha E. Al-jarakh, Osama A. Hussein, Alaa K. Al-azzawi, and Mahmood F.

Mosleh, “Performance evaluation for related techniques of the proposed
environment pollution monitoring system for Iraq case study,” Journal of
Techniques, 2021.

82
 ‫الخالصة‬

‫مؤخرا وجود تلوث واسع النطاق في مدن العراق ‪ ،‬حيث يعاني العديد‬
‫ً‬ ‫أكدت األبحاث المنشورة‬
‫من سكان هذه المدن من إصابات مرتبطة بشكل مباشر بملوثات بيئية خطيرة ‪ ،‬مصاحبا ً ذلك عدم وجود‬
‫أنظمة مراقبة للكشف عن ملوثات الهواء ‪ ،‬على سبيل المثال‪ :‬الجسيمات المادية ‪ ،‬غاز ثنائي أوكسيد‬
‫الكبريت ‪ ،‬غاز االوزون ‪ ،‬غاز أحادي أوكسيد الكاربون ‪ ،‬غاز ثنائي أوكسيد النيتروجين ‪ ،‬باالضافة الى‬
‫التلوث االشعاعي ‪ ،‬هذا يتطلب استخدام حلول تطبيقية منظمة للحد من تأثير هذه الملوثات‪.‬‬
‫ركزت األطروحة بعمق على الدراسات والبحوث التي قدمت العديد من االبتكارات والحلول‬
‫التصميمة المتعلقة بأنظمة مراقبة تلوث الهواء ذات العرض الفوري للبيانات تطلعا ً للحصول على تصميم‬
‫نظام متكامل ومناسب وصالح للخدمة من حيث تغطية جميع ملوثات الهواء لعموم سكان العراق‪.‬‬
‫نظرا ً للنقص الواضح الحاصل في التصميم المعماري الخلفي لهذا النوع من االنظمة ‪،‬‬
‫تم التوصل إلى أن هناك حاجة إلى نمط تصميم متكامل ومثالي مدعوم بأنسب التقنيات ذات األقل استهالكا ً‬
‫لموارد الحوسبة ‪ ،‬وهذا يمثل المساهمة الرئيسية لهذه األطروحة التي تم التركيز عليها‪.‬‬
‫في الناحية العملية ‪ ،‬يستقبل النظام المقترح قراءات عقد االستشعار عبر شبكة االنترنت بشكل‬
‫دوري ليقوم بدوره بتحليلها وجمعها بشكل منظم وخزنها في قاعدة بيانات خاصة‪ .‬من ناحية أخرى ‪،‬‬
‫يعرض النظام نتائج البيانات التي تم تحليلها (مستويات التلوث في المدن) بشكل مباشر للسكان خالل تطبيق‬
‫ويب خاص‪ ،‬مؤكدا ً على معدالت التلوث المرتفعة وضرورة إيجاد الحلول المناسبة لها‪.‬‬
‫نظرا لسهولة قراءتها وتحليلها وتوليدها‬
‫تم استخدام صيغة الرسائل ‪ JSON‬في هذه األطروحة ً‬
‫جنبًا إلى جنب مع بروتوكول التراسل ‪ CoAP‬ذو االقل حمل وحزمة اتصال مقارنةً ببروتوكول‬
‫الـ ‪ MQTT‬لتبادل البيانات بين العقد الموزعة (وحدات ‪ )T-Call ESP32‬وتطبيق الويب الخاص بالنظام‬
‫وكذلك لتنظيم وعرض محتوى مواقع التلوث على خرائط ‪.Google‬‬
‫باإلضافة إلى ذلك ‪ ،‬يتم استخدام ‪ MongoDB‬كقاعدة بيانات لتخزين بيانات النظام ذات االعداد‬
‫نظرا لكفاءتها في إدارة المستندات الخاصة بصيغة الرسائل ‪JSON‬‬
‫الكبيرة الواردة من عقد االستشعار ً‬
‫بأقل وقت لتنفيذ االستعالم مقارنةً بقواعد البيانات ‪ MySQL‬و ‪ ،Cassandra‬بينما تم أستخدم قاعدة بيانات‬
‫‪ MySQL‬للتخزين وإدارة بيانات النظام العالئقية المتمثلة بمعلومات (المشرفين ‪ ،‬مواقع االستشعار ‪،‬‬
‫ضا واض ًحا‬
‫نظرا لكفاءتها في إدارة مثل هذه البيانات‪ .‬تظهر النتائج أن هناك انخفا ً‬
‫األقسام ‪ ،‬االشعارات) ً‬
‫في وقت تنفيذ االستعالم عن البيانات وعرض حزمة االنترنت المستهلكة ‪ ،‬وبالتالي زيادة ملحوظة في كفاءة‬
‫أداء النظام بشكل عام‪.‬‬
 ‫جمهوريةَالعراق َ‬
‫وزارة التعليم العالي والبحث العلمي‬
‫الجامعة التقنية الوسطى‬
‫الكلية التقنية الهندسية الكهربائية‬

‫تصـمـيـمَوتنـفـيـذَنظـامَ(إنتـرنتَاالشــيـاء)َقـابــلَللـتــوسعـــةَ‬
‫لرصـدَالـتلـوثَالـبيئيَالخـاصَبدراسـةَحـالـةَالـعراق‬

‫رســالــةَ‬
‫مقدمـةَالىَمجـلسَالـكليةَالـتقنيةَالهندسيـةَالكهربائيـةَكجـزءَمنَمتطلبـاتَ‬
‫الحـصولَعلىَشهـادةَالمـاجستيرَفيَهندسـةَتقـنياتَالـحاسوب‬

‫مقدمـةَمنَالطـالبَ‬
‫طـه عصـام محـمود نـجم‬

‫بأشــراف‬
‫الـدكـتـور أســامـة عــبـاس حــسـيـن‬
‫األستاذ المساعد الدكتور عـالء خميس خضير‬

‫رمضان ‪1442‬‬ ‫أيار ‪2021‬‬