Luận văn tốt nghiệp Kỹ thuật máy tính: Developing a LoRaWAN-based testbed for IoT applications

This thesis proposes, studies and examines an approach on Developing ALoRaWAN-based Testbed for IoT Applications, including hardware and softwarecomponents regarding LoRaWAN network arch

Faculty of Computer Science and Engineering

——————– * ———————

Thesis graduation

Developing A LoRaWAN-based Testbed

for IoT Applications

Committee : Computer Engineering

Supervisor : Dr Pham Hoang Anh

Reviewer : A/Prof Dr Pham Quoc Cuong

Students : Nguyen Duy Tinh - 1852797

Hồ Hoàng Thiên Long MSSV: 1852161 Ngành: Kỹ thuật Máy tính

Đoàn Anh Tiến MSSV: 1852789 Ngành: Kỹ thuật Máy tính

2 Đề tài: Developing A LoRaWAN-based Testbed for IoT Applications

3 Họ tên người hướng dẫn/phản biện: Phạm Quốc Cường

4 Tổng quát về bản thuyết minh:

- Số bản vẽ vẽ tay Số bản vẽ trên máy tính:

6 Những ưu điểm chính của LVTN:

- students almost fulfilled the basic requirements of the topic

- students wrote a good report, although there are some typos

- students published a paper at an international conference based on the results of the thesis

8 Đề nghị: Được bảo vệ  Bổ sung thêm để bảo vệ  Không được bảo vệ 

9 3 câu hỏi SV phải trả lời trước Hội đồng:

- It seems that the proposed system is an IoT-based air quality monitoring system instead

of a testbed as requirement Could you please explain this mismatch?

- How can a new IoT-based system be tested?

10 Đánh giá chung (bằng chữ: giỏi, khá, TB): Good Điểm: 9/10

Ký tên (ghi rõ họ tên)

We certify that we worked on the project and wrote this thesis entirely

on our own and that it has not been presented in whole or in part in any priorapplication for a degree Unless otherwise stated by reference or credit, the workpresented is entirely our own

Ho Hoang Thien Long, Nguyen Duy Tinh, Doan Anh Tien

This thesis has completely reached its result thanks to the continuous efforts

of the three members, the support and encouragement of our lecturers, friends andfamilies We would like to express our sincere attitude to those who have helped

us throughout the study, research and during working on the thesis

First and foremost, we would like to give our warmest thanks to our visor, Dr Pham Hoang Anh, who has always supported us with not only crucialequipment to carry on the thesis but also immense knowledge and guidance so wecould follow the right direction He continually motivated us and gave us a chance

super-to embrace a very interesting work which was composed from a lot of knowledgethat we have learnt in our university life He has always been a caring, patientteacher who supports us to adjust the work and this thesis throughout differentmodifications It was an honor for us to work with him and to gain experienceunder his supervision

Besides our supervisor, we would like to thank all councilors at the ThesisDefense date for their insightful comment and advice so we could refine our work

in a better way

We would also like to give our appreciation to all of the teachers in theFaculty of Computer Science and Engineering, in particular, and all of the teachers

at Ho Chi Minh City University of Technology in general, for their dedication

to teaching and assisting us in grasping the core knowledge and understandingthe role of an engineer We also want to thank all of our friends for guiding andassisting us during our times at the university

Finally, We would like to express our gratitude to our parents, who alwayscreate good conditions for our growth and encourage us when we have challenges

in both studies and life

Ho Hoang Thien Long, Nguyen Duy Tinh, Doan Anh Tien

This thesis proposes, studies and examines an approach on Developing ALoRaWAN-based Testbed for IoT Applications, including hardware and softwarecomponents regarding LoRaWAN network architecture specification, allowing end-users to be able to monitor, control and validate their LoRaWAN network andwide range of end-devices before any actual deployment in a flexible manner.Additionally, the proposed testbed employs an efficient and reliable mechanismfor status synchronization between a physical control device and a web-app-basedcontrol device to reduce the uplink packet loss rate as well as uplink frequencyfor saving power The experimental results show that the packet loss rate isproportional to the distance between the gateway and end-devices, and is affected

by building walls, obstacles, and hardware capabilities Moreover, leveraging anetwork server and MQTT broker with high availability and scalability enablesour proposed testbed to possibly accommodate up to 1000 users accessing the webapplication deployed on a VPS with a dual-core CPU and 2GB RAM withoutfailure

Parts of this thesis have been accepted and presented at an international

con-ference as follows: Hoang Thien Long Ho, Anh Tien Doan, Duy Tinh Nguyen, and

Hoang-Anh Pham, "A LoRaWAN based IoT Testbed for Performance Investigation,"

in Proceedings of 37th International Technical Conference on Circuits/Systems, Computers, and Communications (ITC-CSCC), July 2022 (https://www.itc-

cscc2022.org/)

Commitment 2

1.1 Purpose and Motivation 1

1.2 Scope and Objectives 3

1.3 Structure of Thesis 4

2 Background and Methodologies 5 2.1 Background 5

2.1.1 Challenges for contemporary agriculture 5

2.1.2 Related works 7

2.2 Fundamental methodologies 9

2.2.1 Overview of wireless network technologies 9

2.2.2 LoRa 10

2.2.2.1 LoRa Radio Modulation 10

2.2.2.2 Spreading Factor 11

2.2.3 LoRaWAN 11

2.2.3.1 General network architecture 11

2.2.3.2 Message types 13

2.2.3.3 Confirmed data message 13

2.2.3.4 End-device classes 14

2.2.3.5 Advantages and disadvantages 16

2.2.4 MQTT 18

2.2.5 Metadata and time-series data 22

2.2.6 Relational database in IoT application 23

2.2.7 RS-485 & Modbus RTU 25

2.2.7.1 RS-485 25

2.2.7.2 Modbus RTU 28

3 The proposed LoRaWAN-based Testbed 31 3.1 System architecture 31

3.1.1 Solution proposal structure 34

3.1.2 Hardware-dependent infrastructure 37

3.1.2.1 RS-485 - LoRa controller integration 37

3.1.3 Software-based infrastructure 43

3.1.3.1 Streaming Broker 43

3.1.3.2 Database 46

3.1.3.3 Web Server & Web Application 49

3.2.3 Scenario analysis 63

3.3 Performance criteria 66

3.3.1 Metric evaluators 68

4 Implementation 69 4.1 System architecture 69

4.1.1 End-device types 71

4.1.2 RS-485 - LoRa controller integration 72

4.1.2.1 Physical controller 72

4.1.2.2 RS-485 - LoRa converter 77

4.1.2.3 Slaves and other components 78

4.1.3 Network Server 80

4.1.4 Software-based infrastructure 82

4.1.4.1 Streaming Broker 82

4.1.4.2 Database Management System 83

4.1.4.3 Web Server & Web Application 85

4.1.4.4 Application Server access control 113

4.2 LoRaWAN control synchronization 115

5 Experiments 117 5.1 Aim 117

5.2 Experiment setup 117

5.2.1 LoRa/LoRaWAN coverage capability testing 117

5.2.2 Web Server load tolerance testing 119

5.3 Results 121

5.3.1 Indoor measurements 121

5.3.1.1 Uplink 121

5.3.1.2 Downlink 122

5.3.2 Outdoor measurements 125

5.3.2.1 Uplink 125

5.3.2.2 Downlink 127

5.3.3 Web Server 129

6 Conclusion 131 6.1 Evaluation 131

6.1.1 RS-485 - LoRa integration capability 132

6.1.2 Control synchronization capability 133

6.1.3 Web Server capability 133

6.1.4 User interface usability 133

6.1.5 Capability of validating various LoRaWAN deployments 134

6.2 Difficulties 135

6.2.1 Test Deployment in Urban Environment 135

1.1 Number of Internet of Things (IoT) connected devices worldwide

from 2019 to 2030 2

2.1 Unmodulated signal and modulate signal in time-frequency rela-tionship 10

2.2 Network stack of LoRaWAN [1] 11

2.3 A typical LoRaWAN Network Architecture 12

2.4 Class A operation 16

2.5 Class B operation 16

2.6 Class C operation 16

2.7 Advantages of a LoRaWAN network deployment [1] 17

2.8 Traditional client-server model 18

2.9 pub/sub model 18

2.10 MQTT on TCP/IP stack 19

2.11 MQTT connection establishment 19

2.12 MQTT topic structure 20

2.13 A complex topic organization represented as a tree 21

2.14 Modbus RTU and RS-485 representation on OSI stack 25

2.15 RS-485 interface 27

2.16 A differential signalling example 27

2.17 The data frame format used in Modbus RTU 28

2.18 The format of one transmitted byte 30

3.1 The proposed LoRaWAN-based Testbed overall architecture 31

3.2 Our solution proposal structure 34

3.3 The proposed RS-485 - LoRa integration system architecture 37

3.4 The proposed Physical controller firmware design 40

3.5 The proposed Physical controller hardware block diagram 40

3.6 The flowchart of sending 1 command running on each Master 41

3.7 Application topics hosted on the Streaming Broker 43

3.8 EER diagram for LoRaWAN-based Testbed Application 46

3.9 Web Application Sitemap 51

3.10 Authentication sequence diagram 52

3.11 CRUD sequence diagram 53

3.12 Sensor widget execution sequence 54

3.13 Controller widget execution sequence 55

3.14 Overall uplink testing phases 56

3.15 Overall downlink testing phases 56

3.16 The format and example of clientid 59

3.17 Two phases of the Access Control mechanism illustrated via se-quence diagrams 61

3.18 The state machine describes the behaviors of a virtual control device (switch or button) 63

3.19 Four possible scenarios for synchronizing the status of physical and virtual control devices 65

4.1 The schematic of the Central MCU board 73

4.8 three-phase process to read data from Slaves 78

4.9 Relay 4 channels RS-485/Modbus RTU developed and manufac-tured by Vietnic 79

4.10 Full topic tree representation of all topics provided by TTS 80

4.11 An example of 2 MQTT clients subscribing to the 2 downlink topics of the Network Server created by EMQ X 82

4.12 EMQ X Rule engine with uplink and downlink examples 83

4.13 Mapping model for Testbed Application 85

4.14 MVC model applied in Web Server 86

4.15 Authentication Pages Flow 92

4.16 Dashboard page UI 94

4.17 Dashboard dropdown and Add board action 95

4.18 Configure board and Delete board actions 95

4.19 Add widget action 96

4.20 Delete widget action 97

4.21 Card widget 98

4.22 Chart widget 99

4.23 Push Button Widget 99

4.24 Toggle Button Widget 100

4.25 Uplink testing metric evaluator 101

4.26 A phase diagram expresses the PLR computation of uplink testing 101 4.27 A phase diagram expresses the RSSI computation of uplink testing 102 4.28 Downlink testing metric evaluator 103

4.29 A phase diagram expresses the PLR computation of downlink testing103 4.30 A phase diagram expresses the RSSI computation of downlink testing104 4.31 A phase diagram expresses the RTT computation of downlink testing105 4.32 A phase diagram expresses the RESP computation of downlink testing 106

4.33 Device page UI 107

4.34 Add widget action 108

4.35 Add widget action 109

4.36 User page UI 110

4.37 Language conversion feature 111

4.38 Logout UI 112

4.39 An actual example of a control synchronization scenario from phys-ical device terminal view 116

4.40 An actual UI corresponding to each state of the virtual button 116

5.1 B4 building in indoor measurements 118

(a) B4 building in reality 118

(b) B4 building longitudinal cross-section 118

5.2 A4 building in reality 119

5.3 Indoor experimental results of uplink coverage in bar chart repre-sentation 121

5.4 Indoor experimental results of control synchronization in bar chart representation 123

5.5 Map of uplink measurements in outdoor environment 125

5.6 Outdoor experimental results of uplink coverage in chart represen-tation 126

5.7 Map of downlink measurements in outdoor environment 127

5.8 Outdoor experimental results of downlink coverage in chart repre-sentation 128

5.9 Stress test result on Login page with incremental virtual users 130 5.10 Stress test result on Application pages with incremental virtual users130

2.1 3 commonly-used wireless technologies 92.2 MAC message types used in LoRaWAN 1.0.x 132.3 Comparison among 3 devices classes A, B and C 16

3.1 Signal descriptions of Physical controller illustrated in Figure 3.5 40

3.2 Description of the topic levels in Figure 3.7 44

3.3 Description of an AC record 583.4 The AC records for any end-user that own the device dev_id 60

4.1 A list of device types and their sensing data 714.2 The commonly used command provided by device manufacturer 794.3 A list of RESTful APIs descriptions 874.4 A list of web API implementation complexity on Web Server side 884.5 A list of web API implementation complexity on Web Application side 904.6 Commonly used HTTP APIs on ACL operations provided by EMQ X1134.7 Control synchronization configuration 115

5.1 Load testing parameters 1205.2 Indoor experimental results of uplink coverage in table representation1215.3 Indoor experimental results of downlink process in table representa-tion (1) 1225.4 Indoor experimental results of downlink process in table representa-tion (2) 1235.5 Outdoor experimental results of uplink in table representation 126

5.6 Outdoor experimental results of control synchronization process intable representation (1) 1275.7 Outdoor experimental results of control synchronization process intable representation (2) 128

ACL Access Control List

CPU Central Processing Unit

CRC Cyclic Redundancy Check

CRUD Create Read Update Delete

CS Control Synchronization

CSS Chirp Spread Spectrum

DBMS DataBase Management System

GPS Global Positioning System

GPRS General Packet Radio Service

HMI Human-Machine Interface

IoT Internet of Things

LPWAN Low Power Wide Area Network

LSB Least Significant Bit

MAC Medium Access Control

MQTT Message Queuing Telemetry Transport MSB Most Significant Bit

OSI Open Systems Interconnection

OTAA Over-The-Air-Activation

PLC Programmable Logic Controller

PLR Packet Loss Rate

RAM Random Memory Access

RTU Remote Terminal Unit

UI User Interface

VPS Virtual Private Server

WUSN Wireless Underground Sensor Networks

1.1 Purpose and Motivation

In the XXI century, during the great development of the Fourth IndustrialRevolution, the demand for IoT solutions is calculated and forecast to growlinearly in terms of end-user spending This demand is described by the statistical

information in Figure 1.1, approximately 10 billions devices connected in 2021

and is predicted to be 23.5 billions in 2029 [2], which is more than doubled This

is happening not only in industry but also people’s day-to-day life With thesupport of IoT, we expect to collect a huge amount and diversity of data in thisdynamic world in order to serve the purpose of monitoring, analyzing, extractingthe most meaningful information, as well as improving the control of "things”.Moreover, for each type of demand, we need particular technologies as well asreasonable deployment schemes in order to form a core system architecture servingthat demand

So as to satisfy typical agricultural network’s requirements about hightransmission range, geography, low energy consumption and cost, there is awide range of research making use of conventional and widely-used wirelesstechnologies such as 3G, BLE, WiFi However, when deploying those technologies

in reality, frequency licenses are needed in terms of recurring fee, provider,etc and depending on areas along with policies, difficulties start to rise Forinstance, it is challenging to deploy at where 3G is not stable (e.g deep ruralareas), or monitoring area is above the transmission range (e.g large cropfields) of WiFi and BLE, which will need additional repeaters causing additionalcost On the other hand, another type of wireless technology called LPWAN isable to effectively serve those requirements, namely LoRaTM, SigFoxTM, NBIoTTM

Figure 1.1: Number of Internet of Things (IoT) connected devices worldwide from 2019

to 2030

Among those technologies, LoRaTM, a wireless modulation technology lies

on physical layer invented and commercialized by Semtech®is a potential solutionrespect to our research boundary because it works on the unlicensed frequency band

(referencing to National technical regulation on radio equipment in the LPWAN

operating in the 920MHz to 923MHz frequency band of Vietnamese Law adjusted

since 2020) which allows easier deployment and testing In addition to LoRa,LoRaWAN has its own protocol built on top of LoRa, allowing the communicationbetween LoRa end-devices, gateways and TCP/IP-based cloud servers

Even though LoRa and LoRaWAN have been studied in literature and

and controlling before any real deployment Additionally, we conducted manyexperiments to investigate the efficiency of the control synchronization to maintainthe same status on physical controllers and the Web Application when end-usersremotely interact with sensor nodes via the web interface or physical I/O (e.g.,buttons or switches) This also helps reduce the uplink frequency, which leads toredundancy avoiding and power saving.

Moreover, one common challenge related to IoT applications overall is theability of load-tolerance when there are a huge load of end-devices and end-usersdata transferred This thesis also presents various open-source IoT platforms used

in order to develop servers with a certain level of load-tolerance running on aminimal cost VPS

Our thesis scope is all about developing a LoRaWAN-based testbed ronment including such components: hardware-dependent infrastructure, networkserver, software-based infrastructure, in order to allowing bidirectional commu-nication between multiple end-users and multiple end-devices, aiming to enableflexibility for experimental monitoring and controlling before embedding into anyIoT applications, as well as intensively conducting many experiments to exploremore about the performance of LoRa, LoRaWAN with respect to a number ofmetrics

envi-Our thesis objectives are to conduct research about such IoT models usingdevices that support LoRa, LoRaWAN, allowing the development and integration ofvarious sensor networks; research about open-source IoT platforms so as to develop

a set of software providing back-end services and storage with the ability of tolerance; implement a web application for end-devices monitoring and controllingfor end-users aiming to flexibly test the proposed testbed model in terms of variousperformance metrics; implement a custom RS485 sensor network that can convertdata back and forth with LoRa to study the ability of LoRaWAN integration withanother network; besides, we carry out research about communication protocolsrespect to LoRaWAN specification in order to integrate and enhance the reliability

load-of data transfer between devices and end-users

1.3 Structure of Thesis

The remainder of the thesis is organized as follows In Chapter 2, firstly,

we will review about the overall background including challenges for contemporaryagriculture and related literature that we referred to a lot; secondly, a review of fun-damental methodologies, which consists of basic technological models and concepts,which of course include the core concept of LoRa, LoRaWAN architecture, that

were applied to our project are discussed In Chapter 3, the proposed

LoRaWAN-based testbed architecture and the analysis of the control synchronization method

and various performance criteria are deeply studied In Chapter 4, the actual implementation of the testbed architecture is described In Chapter 5, the results

of the various experiments are investigated to point out the capability of LoRa,LoRaWAN in some certain environments as well as the capability of load-tolerance

of our proposed web application Eventually, our accomplishments, difficulties so

far are evaluated, together with rooms for improvement are proposed in Chapter 6.

2.1 Background

2.1.1 Challenges for contemporary agriculture

By adopting IoT in the agricultural sector we get numerous benefits, butstill, there are challenges faced by IoT in agricultural sectors The biggest challengesfaced by IoT, according to Geeksforgeeks.org, in the agricultural sector are:

• Lack of Connectivity: The main issue which slows the ability of farmers toprofit from the latest technologies is connectivity BTRC has stated thatalthough there are more than ninety millions of Internet users, we do nothave exact reports of the usage of Internet of smart phones by farmers forthe purpose of agriculture These technologies are used by vast agriculturecompanies and are not widely famous with rural farmers

• Lack of Awareness: Most of the farmers are not aware of the implementation

of IoT in agriculture Major problem is that some of them are opposed to newideas and they do not want to adopt even if it provides numerous benefits

An American research report states that amidst 1600 farmers, only 68 percentare familiar with IoT These technologies will be more challenging in smallland holdings and crop diversity compared to large farms The best thingthat can be done to raise awareness of IoT’s impact is to demonstrate farmersthe use of IoT devices like drones, sensors and other technologies and theycould provide them ease at work and accompanied by real-world examples

• Lack of Infrastructure: Even if the farmers adopt IoT technology they won’t

be able to take advantage of this technology due to poor communication

infrastructure Farms are located in remote areas and are far from access tothe internet A farmer needs to have access to crop data reliably at any timefrom any location, so connection issues would cause an advanced monitoringsystem to be useless.

• High Cost: Equipment needed to implement IoT in agriculture is expensive.However sensors are the least expensive component, yet outfitting all of thefarmers’ fields to be with them would cost more than a thousand dollars.Automated machinery cost more than manually operated machinery as theyinclude cost for farm management software and cloud access to record data

In agronomical farms, the software and hardware expenses are soaring due

to exposure to the unsympathetic atmosphere such as cold, heat, water,storm, wind, sand and physical dents The consequent challenge will be toidentify the suitable business model Initiating IoT blindly will not providesuccess An IoT business model has to be an essential factor for an agro goalachievement To earn higher profits, it is significant for farmers to invest inthese technologies, however it would be difficult for them to make the initialinvestment to set up IoT technology at their farms

• Lack of Security: Devices should be secured against theft and wrong exploit asthe prospect of farming predictions is possible, product pricing and expensescould also be manipulated and they should be monitored Since IoT devicesinteract with older equipment they have access to the internet connection,there is no guarantee that they would be able to access drone mapping data

or sensor readouts by taking advantage of public connection An enormousamount of data is collected by IoT agricultural systems which is difficult toprotect Someone can have unauthorized access to an IoT provider’s databaseand could steal and manipulate the data

The establishment of digital technology in 2017 in the field of agricultural industrybrought forth more than seven hundred million dollars’ worth of investment in theAgro-Tech market This profit is double the amount of the cost of 2016 Conversely,

at-In [4], another system was proposed to provide a GPS localization system usingLoRaWAN technology and the bus tracking information, which used to be nonpub-lic in some of the existing work, all combined into a smart public transport systemwith the aid of an Android application This study concluded that a LoRa-basedGPS tracking system can be carried out in a real-life scenario LoRa used in Healthmonitoring also has been explored in [5] The authors in this study propose anew IoT-based system that collects health metrics via medical sensors throughthe means of LoRa, and establishes a dashboard for data visualization where thedoctor can monitor and examine the sensor values In the experiments, the group

estimated a large coverage area of approximately 33 km2 in rural areas using

common antennas with less than 3 dBi gain, and the power consumption of the

system is 10 times lower than that of GPRS-based transmission

Some research have been conducted surround the idea of developing a testbed

to open an easier way for LoRaWAN-based application testing, such as developing

a low-cost LoRaWAN testbed for IoT with a detailed description of implementationwith a variety of sensors, gateways, and intensively conduct experiments on differentenvironments with a number of performance metrics in [6] However, the proposaldoes not mention the design of a software-based infrastructure providing applicationand UI for end-users to interact with devices For that reason, we extend theresearch domain to the whole LoRaWAN system from sensor nodes to application

server as discussed in Section 3.1.

The network performance of LoRa-based systems is also an attractive topicwhich depicts the capability of LoRa-based systems and helps to decide whether toapply LoRa or not in certain environments or circumstances In order to evaluatethe output performance of a LoRaWAN-based system or any IoT system in general,one approach is to define performance metrics In [7], a group of authors discussand propose numerous quality and reliability metrics that are applicable to any

IoT system categorized into 3 groups: quality assessing metrics of an IoT system,effectiveness of the testing process metrics, and both Our thesis mainly refers

to the metrics in the first group, quality assessing metrics of an IoT system, toapply and conduct experiments on our LoRaWAN-based testbed, as discussed in

Section 3.3.

Some more research related to LoRaWAN performance experiments areintroduced as follows A group of researchers from the University of Pisa, Italy,conducted an evaluation of the network performance of a LoRa-based IoT systemfor crop protection against ungulates by setting up a LoRaWAN-based testbed

at three different vegetation sites [8] The experimental results indicated that thereliability, expressed by the ratio of successfully received packets over total sendingpackets, reaches 73% at maximum 512 meters line-of-sight, with some thickness ofthe vegetation In [9], the authors investigate how a LoRa signal may overcome thein-soil transmission loss that an ordinary WUSN network experienced due to thesoil layer and other natural obstacles The authors also design an Android basedsmartphone application (named LoRa Wizard) for the measurement process Theexperiments focus on the transmission performance involve the characteristics of aLoRa payload and use PSR as a key evaluation criterion The results showed thatthe PSRs of the tests conducted in a farmland is much higher than the PSRs of amunicipal garden, due to no obstructions and homogeneous loam Nevertheless,the experience also showed that when there is heavy rain, the farmland witnessed

a worse performance in terms of PSRs, which was caused by its drainage effect andstrong absorption effect on radio signal of water On the power usage domain, aninteresting comparison of LoRa and NB- IoT in terms of power consumption showed

that the average estimated transmission power of LoRa SF7 reached 453.5mW and NB-IoT reached 2.686W [10] Therefore, LoRa SF7 consumes far less power of

nearly 6 times than NB-IoT

2.2 Fundamental methodologies

2.2.1 Overview of wireless network technologies

Thanks to the influence of recent market trends and growth in demandhave brought IoT to the new level and generated new applications to the world.Due to the distinct properties of quantity, distribution of devices together withuncontrolled environments, a wireless technology is considered to be appropriate for

a certain IoT application when it meets specific requirements of transmission range,energy consumption and cost, etc In order to serve the varying application needs,there are various wireless technologies are invented with different characteristicscategorized into: Short-range wireless communication (e.g RFID, Wi-Fi, BLE),LPWAN (e.g LoRa, Sigfox, NB-IoT), Cellular (e.g 3G, 4G, 5G) as shown in

Table 2.1.

Table 2.1: 3 commonly-used wireless technologies

Type

Average Power Consumption (mW)

Average Data Rate (KB/s)

Average Range (m)

Cost

With respect to the scope of our research and the characteristics of ture monitoring application, there exists the need for long range communicationacross the wide plant field, it can be seen that LoRa is a good candidate for solvinglong range and low cost challenges According to experimental result of the 4 types

agricul-of wireless network shown in Table 2.1, LoRa transmission can reach up to 15 km

and the power consumption is around 20 mW in line-of-sight, ideal environment,

which account for the least power consumption and highest range among the 4

wireless technologies However, the data rate of LoRa is around 0.8 kB/s, which

is 64000 time smaller than that of 3G, 128000 times smaller than that of Wi-Fi.Thus, it is suitable for transferring small data size such as sensor data or controlmessages in near real-time, but not suitable for applications that need transferring

in a strict real-time constraint or transferring of large data size such as sounds,videos, images, etc On the other hand, Wi-Fi, 3G can serve those real-time needsbut there are trade offs of range, power consumption and cost

2.2.2 LoRa

According to documentation provided by Semtech[1] LoRa, an acronym for

Long Range, is a wireless technology which lies on physical layer regarding the network stack shown in Figure 2.2, enables long-range data links between a sender

and a receiver (or between senders and receivers) via electromagnetic fields A keycharacteristic of the LoRa besides long range is meeting low power requirements,which allows for the creation of battery-operated devices that can last for up to 10years

2.2.2.1 LoRa Radio Modulation

Modulation is the process describing how analog or digital information areencoded onto a carrier signal LoRa is a spread spectrum modulation schemebased on Chirp Spread Spectrum modulation (CSS) A chirp is a sine-wave signalwhose amplitude is constant and frequency increases over time, as shown in the

time-frequency graph Figure 2.1 In simple terms, we can imagine the "chirp"

sound from a bird singing whose tone increases from low to high over time If thefrequency changes from lowest to highest, it is called up-chirp and if the frequencychanges from highest to lowest, we call it down-chirp The speed of sweeping fromlowest to highest frequency is called chirp rate In digital modulation, each chirpcarries a certain value of bits

Figure 2.1: Unmodulated signal and modulate signal in time-frequency relationship

2.2.2.2 Spreading Factor

Spreading Factor (SF) drives the chirp rate, thus drives the data transmissionspeed The lower the SF, the faster the chirp rate leading to higher data transmissionspeed The SF is represented as an integer number range from 7 to 12, inclusively.For every increment of Spreading Factor, the chirp rate is cut in halve, therefore,the data transmission speed is cut in halve also

The higher in SF, the larger the processing gain, therefore, the chance oferrors is lower compared to the one of low SF, and thus travel a longer distance.For example, a signal modulated with the SF12 can travel a longer distance withless errors than a signal modulated with the SF7 Moreover, higher SF makesreceiver sensitivity higher Therefore, SF is set to be higher when the signal isweak, but with the tradeoff of data transmission speed SF plays an importantrole in the Adaptive Data Rate algorithm of LoRaWAN choosing the best signalconfiguration for end-devices to reduce power consumption, increase coverage, etc

2.2.3.1 General network architecture

According to the network stack of LoRaWAN provided by Semtech [1],developed by LoRa Alliance LoRaWAN works on media access control (MAC)layer defining devices classes, the structure of the data packet, different types

of commands, and network protocols built on top of LoRa Note that the maincommunication process is between end-devices and a network server relayed by one

or many gateways

Figure 2.2: Network stack of LoRaWAN [1]

LoRaWAN itself also defines the end to end data delivery solution as

illustrated in Figure 2.3.

Figure 2.3: A typical LoRaWAN Network Architecture

• End Nodes: predominantly various types of sensors and controllers

cate-gorized into 3 classes: A, B or C, that broadcast their sensor data to everyLoRaWAN gateways in its vicinity End nodes send data via LoRa

• Gateways: transform data packets in the form of uplink from LoRa signal

zone to other ethernet backhaul like Wi-Fi, 3G, etc then forward to thenetwork server, as well as received downlink commands from the networkserver, modulate the downlink and send back to appropriate end nodes

• Network server: lies on TCP/IP stack, manages the entire LoRaWAN

network, provides MAC layer management for end devices, filters duplicatedata packets and route uplinks message to application servers, or scheduledownlinks back to end-devices

• Application servers: where the user can process/view/analyze the data

depends on the application needs

To be more specific, at hardware side, both LoRa end node and gateway

• Uplink: When an end node transmits a data frame to the network server

relayed by one or many gateways

• Downlink: when the network server schedule a data frame, typically contains

commands, to the end node relay by a single gateway that is has the most

stable connection (based on RSSI, ADR, etc.) with the end node.

2.2.3.2 Message types

LoRaWAN message types are divided based on uplink and downlink tion, which means every uplink or downlink message has a certain message typeindicating certain functionality Those message types have a technical name, MAC

direc-message types which is injected into any sent direc-message frame Table 2.2 lists and

describes several MAC message types used in LoRaWAN version 1.0.x and theirbrief functionalities

Table 2.2: MAC message types used in LoRaWAN 1.0.x

the OTAA procedure

the OTAA procedureUnconfirmed Data Up uplink a data frame with

no confirmation message requiredUnconfirmed Data Down downlink a data frame with

no confirmation message requiredConfirmed Data Up uplink a data frame with

confirmation message requiredConfirmed Data Down downlink a data frame with

confirmation message required

Proprietary uplink/downlink Used to implement

non-standard message formats

2.2.3.3 Confirmed data message

According to LoRaWAN 1.0.3 Link Layer Specification, in order to enhancethe data transfer reliability, confirmed data message, including 2 message types

Confirmed Data Up and Confirmed Data Down described in Table 2.2, is used The

working mechanism of confirmed data message is the combination of 2 proceduresdescribed as follow:

• Acknowledgement procedure: It is expected that the receiver shall

respond with a data frame that has the acknowledgment bit set when receiving

a confirmed data message If the message is Confirmed Data Up, the networkserver shall send the acknowledgement back to the end-device scheduled inone of the receive windows after the uplink In contrast, if the message isConfirmed Data Down, the end-device shall send the acknowledgement back

to the network server at its own choice of time Acknowledgements are onlysent once and never retransmitted

• Retransmission procedure: It is expected that the sender shall retransmit

the previous unacknowledged confirmed data message with the same framecounter for a number of times If the end-device has reached the maximumnumber of retransmissions, it is up to the end-device to regain the connec-tivity by self-reconfiguring data rate and other network parameters, or dropthe uplink and move on If the network server has reached the maximumnumber of retransmissions, it is up to the network server to consider theend-device unreachable until it receives further messages from the end-device,

or retransmits, or drops the downlink and moves on

2.2.3.4 End-device classes

The LoRaWAN specification classified end-devices into 3 classes: Class A,class B and class C, whereas class B and class C are extensions of class A

• Class A operation is illustrated in Figure 2.4 Class A is the simplest

operation among 3 classes An end-device is able to send an uplink frame atany time, usually in a fixed interval The uplink takes some time to transmitfrom the end-device to the nearby gateways After the completion of theuplink transmission, the device opens 2 receive windows, RX1 and RX2,listening for a downlink from the network server Each receive window isopened after a specified delay after the end of the uplink, where RX2 delay

window The listening period for the ping receive window is called the pingslot The ping receive window is used to listen for a downlink from thenetwork server that will be sent at the scheduled time with the ping slot.The interval between 2 beacons is the beacon period Note that the beaconperiod is not necessary to be matched with the uplink interval Because ofadditional open receive windows, class B devices consume more power thanclass A devices.

• Class C operation is illustrated in Figure 2.6 Class C is an extension of

class A, which means it inherits operation of class A but extends the periods

of existing received windows continuously until the next uplink transmission.The delay of RX1 and RX2 is reduced to zero, the RX2 period is insertedinstead After the RX1 period, RX2 is extended to the next uplink Becausethere is no idle time slot for the end-devices to not uplink or not listen fordownlinks, class C devices consume more power than class B devices

Table 2.3 presents the 3 common differences among the 3 device classes A,

B and C Because the differences of how much time spent for receive windows, the

power consumption (P ) can be expressed via the comparison expression:

extend rx2 to the next uplink

Figure 2.6: Class C operation

Table 2.3: Comparison among 3 devices classes A, B and C

shown in Figure 2.7, as well as some limitations that we should be aware of.

Regarding the Long Battery Life feature, as far as battery life goes, theenergy required to transmit a data packet is quite minimal given that the datapackets are small and only transmitted a few times per hour Furthermore, most

of nowadays manufactured nodes are put into sleep mode waiting for the nexttransmission, allowing a device’s battery to last longer Beside Long Range, LongBattery Life and Low Cost, recent LoRa manufactured chips can communicate up

to 10000 other devices with 10 parallel demodulation channels and can process up

to millions of messages per station, which represents the High Capacity feature.Due to the fact that LoRa works on the free frequency plan, which is specified inVietnamese Laws, we can deploy anywhere without license Moreover, because ofwireless properties, indoor or outdoor deployment are possible Other features such

as basic network Security (encryption), OTA, are also specified clearly in LoRaSpecification and implemented in recent hardware

Nevertheless, regarding its nature characteristic of Low Data Rate, it is notsuitable for such applications that require transferring large data packets and thoserequire strict real-time constraints such as transferring images, video, sound, flightcontrol, etc LoRa can only uplink or downlink each message for every few secondsand this interval varies a lot due to network server scheduling schemes as well asthe surrounding environment

Figure 2.7: Advantages of a LoRaWAN network deployment [1]

2.2.4 MQTT

According to the MQTT 3.3.1 specification and OASIS standard [11], [12],MQTT is defined as a lightweight messaging protocol for IoT applications, whichfollows the client-server publish/subscribe messaging mechanism providing the ease

of use MQTT is ideal for fast and stable development of Machine to Machine(M2M) and IoT applications with a small code footprint and minimal networkbandwidth

To understand MQTT, we need to understand the publish/subscribe sub) mechanism Let’s consider the case when using the traditional client-servermodel for an example IoT application where many IoT devices act as servers todisplay their collected sensor data and end-users act as clients With the client-server model, the client communicates directly with the IoT devices (here’s theservers) It should be fine when there is one IoT device with a few connections fromclients, but when there are thousands of IoT devices and a client want to retrievedall information from those devices, the client needs to know the IP addresses anddifferent type of connections of thousands of IoT devices to be able to connect to,

(pub/-which create unnecessary complication, as shown in Figure 2.8.

To solve the issue, the pub/sub mechanism comes into play as an alternativeapproach to communicate among a number of devices It separates IoT devicesthat send messages (the publishers) and the clients that received those messages(the subscribers) The publishers and subscribers are connected via a centralserver called the broker that is responsible for filtering, categorizing messagesfrom publishers into topics and route them to appropriate subscribers as shown in

Figure 2.9.

client

client

server server broker

publisher publisher

subscriber subscriber pub

pub

sub sub sub

The above explanation of the pub/sub model works for MQTT and othermessage queuing systems However, one crucial difference between MQTT andother message queuing systems is that the MQTT broker does not store a queue ofmessages from the past, whereas other queuing systems do, such as Kafka Themessage is routed in real-time, therefore, when a subscriber has not yet joined theMQTT network, he will not receive those past messages in the future However,MQTT brokers do store each queue of past-unacknowledged messages as retainedmessages for each disconnected subscriber that still has the unexpired session stored

on the broker Therefore, later when he joins, he still gets all the retained messages,but when the session expires, the queue is destroyed and we will not receive thosemessages anymore

The MQTT protocol lies on the application layer above the TCP/IP stackfor both client and broker implementation

MQTT

TCP IP Network interface

Figure 2.10: MQTT on TCP/IP stack

Clients can connect with the broker directly, but not other clients Here isthe connection establishment between client and broker

broker

client

CONNECT

CONNACK

Figure 2.11: MQTT connection establishment

The client actively sends a CONNECT message to the broker to requestthe connection, the broker then responds with the CONNACK message, then theconnection is held persistently until the client disconnects

Clients cannot communicate with each other directly, but via topics held bythe broker Topics can be created on the fly by publishers

Topics representation as the UTF-8 string that are responsible for filteringand categorizing messages with the forward slash, consisting of 2 parts

• Topic level: a name indicating the root and the sub topics in the topic tree.

Each topic consists of one or more topic levels

• Topic separator: a forward slash to separate topic level.

farm/garden/temperature

topic level topiclevel separator

Figure 2.12: MQTT topic structure

In the example in Figure 2.12, the meaning can be interpreted as the topic holding

the value of temperature of a garden in the farm

However, when there is a complex topic organization that needs to berepresented in an understandable way, a topic tree is an efficient alternativerepresentation Refer to an example of a more complex topic organization shown

in Figure 2.13, with a tree representation, we can extract information that there

are not only a topic holding temperature of a garden in a farm, but also manytopics with different levels deep down presenting information of different areas onthe same farm, such as controlling a fan in a piggery, monitoring light of a daisyarea of garden2, rose area and daisy area are in the same garden, etc With a tree,

we can understand deeper about the structure of the topic organization

temperature humidity rose-area daisy-area

light

status control status control

status control pumper

status control

Figure 2.13: A complex topic organization represented as a tree

The publisher creates and publishes data to this topic, the subscribersubscribes to the topic to get temperature streams Many publishers can send data

to one topic and many subscribers than subscribe from one topic, which meansone data packet can be shared with many subscribers