Design and implementation firmware update over the air (fuota) technology in lora network graduation project of computer engineering technology

ABSTRACT This thesis proposes a model for Secure Firmware Update Over -the-Air FUOTA specifically designed for the collection of environmental parameters using LoRa Long Range technology

INTRODUCTION

PROBLEM STATEMENT

The Industrial Internet of Things (IIoT) is driving a surge in demand for wireless communication devices that leverage Low Power Wide Area Network (LPWAN) technology These devices play crucial roles in applications like smart homes, smart cities, and industrial automation Nonetheless, challenges arise in maintaining and updating their software, especially when physical access is limited or impractical.

LoRa (Long Range) is a leading LPWAN technology for IoT applications, known for its long-range communication, low power usage, and decent data rates However, its bandwidth limitations can pose challenges for effective Over-The-Air (OTA) firmware updates.

Security concerns in implementing OTA firmware updates in LoRa networks necessitate ensuring the integrity and authenticity of these updates This is vital to prevent unauthorized modifications or malicious code injections that could jeopardize IoT device security and the network as a whole To mitigate these risks, it is essential to employ secure methods, such as encrypting firmware and utilizing secure authentication protocols, to uphold the reliability and trustworthiness of the IoT ecosystem.

In this thesis, titled "Design and Implementation of Firmware Update Over-The-Air (FUOTA) Technology in LoRa Network", we aim to design a

The FUOTA architecture for IoT systems utilizing LoRa technology aims to enable gateways to efficiently collect data and streamline the firmware update process This research emphasizes the importance of security in LoRa communications, ensuring that firmware updates are secure and that data exchanged between nodes and the gateway is protected Ultimately, the objective is to tackle the challenges associated with secure and efficient firmware updates in IoT environments leveraging LoRa technology.

RESEARCH OBJECTIVES

This thesis aims to develop a secure and efficient Firmware Update Over -The- Air (FUOTA) model for environmental monitoring stations utilizing LoRa technology The model will focus on:

- Automating updates for MCU control applications and sensor monitoring software deployed on these stations

- Providing users with a user-friendly PC application for system management and information retrieval

- Implementing robust security measures to guarantee the integrity and confidentiality of firmware updates and data transmissions

- Developing an algorithm to handle potential data loss during the FUOTA process.

RESEARCH METHOD

In this thesis, two research methods are utilized:

RESEARCH SCOPE

- Researching relevant articles, documents, and datasheets concerning the technology under investigation Investigating communication methods, as well as read and write operations to registers, of integrated components

- Conducting an overview of the structure and components of LoRa networks, referencing documents related to LoRa networks

- Reviewing literature on encryption algorithms for security in LoRa networks

- Reviewing articles on the application and the architecture of FUOTA in LoRa networks

- Researching and designing hardware prototypes Reviewing documentation on the usage of UART, SPI, I2C protocols, and RTOS applications

- Developing software to facilitate firmware update and display sensor data on applications

- Developing Configuration Tools on PCs for secure firmware file uploading and encryption

- Implementing encryption algorithms to ensure secure firmware updates and data transfers.

RESEARCH LIMITATION

Due to time constraints, the project has several limitations:

- Basic of Configuration Tools: The tools used for configuring parameters for the gateway and uploading firmware are relatively basic

The project currently lacks the capability to simulate simultaneous updates across multiple nodes, which hinders effective testing of scalability and efficiency in real-world scenarios.

The current transmission range is limited to under 2 kilometers, which may restrict the system's coverage and effectiveness, particularly in larger deployments or expansive environments.

The system's inability to dynamically add or remove sensor nodes limits its scalability and flexibility, making it challenging to adapt to evolving requirements or environments.

- Suboptimal Hardware Design: The hardware design has not been optimized to suit various system configurations, potentially leading to inefficiencies or compatibility issues with different setups

- Non-Optimized Firmware Update Algorithm: The firmware update algorithm has not been fully optimized, which may result in suboptimal performance in terms of update speed, reliability, or resource utilization.

STRUCTURE OF THESIS

In this chapter, we introduce the problem statement, motivation, importance, objectives, research methodology, scope, content, and limitations.

THEORETICAL BACKGROUND

OVERVIEW OF LORA AND LORAWAN

LoRa, short for Long Range, is a data transmission technology that employs modulation techniques like FSK, GFSK, and OOK Originally developed by Cyleo, which was acquired by Semetech in 2012, LoRa utilizes spread-spectrum modulation and operates within the unlicensed radio spectrum.

The frequency bands of 169 MHz, 433 MHz, 868 MHz, and 915 MHz are license-free in various countries, offering advantages such as low cost, minimal energy consumption, and an impressive device lifespan of up to 10 years under optimal conditions.

In free space, LoRa technology can transmit signals up to 16 km with an unobstructed line of sight, such as in open fields or along riverbanks However, in urban settings with tall buildings, positioning LoRa stations at heights of 1.5 to 2 meters above ground can facilitate transmission distances of about 1 to 2 km.

LoRa finds wide-ranging applications, as any device requiring data transmission, exchange, or communication can leverage LoRa technology, provided there is an internet connection

LoRaWAN, developed by the LoRa Alliance, is a communication standard that utilizes LoRa technology to enhance Low Power Wide Area Network (LPWAN) standards This non-profit organization aims to facilitate the connection of millions of IoT devices across various applications, including Smart Cities and Smart Meters.

LoRaWAN is designed to support regional, national, and global networks, fulfilling Internet requirements for secure two-way communication, mobile services, and localization It facilitates seamless interaction between smart devices without the need for intricate local installations, providing users, developers, and IoT deployment enterprises with enhanced freedom and flexibility.

In a standard LoRaWAN network architecture, gateways act as transparent bridges, relaying messages between end devices and central network servers These gateways connect to the network server through standard IP connections, while end devices communicate wirelessly with one or multiple gateways The communication between end devices is bidirectional, enabling functionalities such as multicast software upgrades and the distribution of messages to minimize airtime.

Communication between end devices and gateways utilizes various frequency channels and data rates, with data rate selection optimizing both communication range and message duration The implementation of spread spectrum technology allows for simultaneous communication at different data rates without interference, effectively creating "virtual" channels and improving gateway functionality LoRaWAN supports data rates that range from 0.3 kbps to higher values, facilitating efficient data transmission.

50 kbps Network servers manage data rates and RF output for each end device through Adaptive Data Rate (ADR) programs, maximizing battery life and overall network capacity

Figure 2.1: Diagram of a LoRaWAN network architecture [3]

Figure 2.1 illustrates the overall architecture of LoRaWAN, detailing its various layers as follow:

End Nodes: Consist of one or multiple devices containing sensors They encode the collected data into packets and send them to the gateway

Gateways serve as intermediary devices that connect sensor nodes to the internet, efficiently receiving multiple packets from various sources Their primary function is to organize these incoming packets and transmit them to network servers for further processing.

Network servers act as central hubs that manage data packets within a system Given the presence of multiple gateways, they may encounter duplicate or delayed packets that are not synchronized To ensure data integrity, the network server collects all incoming packets, eliminates duplicates, and decodes them into the required user-friendly format.

Application Servers: this can be a website, a mobile app, or any other application where the data is used

LoRaWAN is a prominent technology in the Internet of Things (IoT) sector, utilized in countries like Japan, South Korea, the United States, and the United Kingdom By the end of 2017, around 500 towns and cities, including major French cities such as Paris, Marseille, and Lyon, were covered by this extensive IoT network Additionally, similar LoRaWAN networks are being established in Spain, Switzerland, and Belgium by various participating network providers.

2.1.3 Significance and Applications of LoRa

LoRa technology is widely applied across diverse sectors in the IoT landscape, serving various industries:

- Industrial Control: LoRa facilitates remote monitoring and control of industrial processes, boosting productivity

- Metering: LoRa enables remote utility metering, such as for electricity and water, streamlining management and billing processes

- Environment: LoRa is utilized for environmental monitoring, including assessing air and water quality, aiding in environmental management efforts

- Smart Cities: LoRa supports smart city initiatives by enabling applications like smart lighting and waste management, enhancing urban infrastructure

- Smart Agriculture: LoRa is deployed in agriculture for tasks like soil and crop monitoring, optimizing farming practices

- Supply Chain & Logistics: LoRa enables asset tracking and inventory management, providing real-time visibility throughout the logistics process

- Healthcare: LoRa facilitates remote patient monitoring and asset tracking in healthcare settings, improving patient care

- Home & Building Automation: LoRa supports home automation and security systems, enhancing energy efficiency and safety

By offering long range and low power consumption, LoRa proves itself adaptable and effective in diverse IoT sectors

The LoRa packet, as depicted in Figure 2.2, consists of several key components focused on the physical layer of the LoRa communication protocol These components include [4]:

The preamble is the first 8-byte sequence in a packet, essential for synchronizing the clocks of transmitting and receiving devices It employs a specific bit pattern that features consistent transitions between high and low signal levels.

- Header (Optional): While not strictly mandatory in LoRa, some implementations might utilize a header for additional information

- Coding Rate: Defines the symbol rate used for encoding the data

The payload is the essential component of a packet, responsible for transmitting the actual data from the LoRa device Its size is constrained by various factors, including the selected coding rate and bandwidth.

Cyclic Redundancy Check (CRC) is a 16-bit checksum added to the data payload for effective error detection The receiving system computes its own CRC from the incoming data and compares it to the transmitted CRC; any mismatch signifies potential data corruption that occurred during transmission.

LoRa technology operates efficiently by balancing three essential parameters: Spreading Factor (SF), Bandwidth (BW), and Coding Rate (CR) These elements interact to optimize the trade-off between communication range, data transmission speed, and reliability.

The Spreading Factor (SF) is a crucial parameter in LoRa technology, influencing the number of chirp signals used for data encoding in packets Higher SF values, typically between 6 and 12 for the SX1276 chipset, extend communication range at the cost of longer transmission times In contrast, lower SF values enable quicker data transmission but reduce the effective range.

SPI, I2C, UART PROTOCOL

The Serial Peripheral Interface (SPI) protocol, developed by Motorola in the mid-1980s, revolutionized data exchange between devices by offering high-speed communication capabilities, operating at frequencies from a few megahertz to tens of megahertz.

SPI's full-duplex, four-wire design is a significant advantage, allowing dedicated data lines for simultaneous sending and receiving This setup facilitates uninterrupted two-way communication, akin to a two-lane highway where data flows freely in both directions.

SPI operates on a master-slave architecture, where the master device, usually a microcontroller, directs the communication process Meanwhile, slave devices, such as sensors, LCD screens, or memory chips, remain idle until they receive commands from the master.

Some key players in SPI communication protocol:

The master serves as the central control unit, initiating and managing data transfer by generating the clock signal (SCLK) that synchronizes the process It dictates the timing for each data bit's transmission and reception, sending data through the MOSI line (Master Out, Slave In) and receiving data via the MISO line (Master In, Slave Out).

Slave devices in an SPI bus system play a crucial supporting role by following the master’s instructions Each slave is assigned a unique chip select line (SS), allowing the master to activate a specific slave for communication When the master asserts a slave's SS line by driving it low, the slave acknowledges the address and readies itself for data exchange Typically, slave devices transmit data via the MISO line and receive data through the MOSI line.

SPI's ease of use and fast performance have established it as a popular option in embedded system design, making it a valuable asset for diverse applications due to its efficient data transfer capabilities between multiple devices.

SPI, also known as Four-wire interface, utilizes a full-duplex serial transmission channel (with separate data lines for transmission and reception), allowing simultaneous bidirectional data transfer

SPI operates on a Master-Slave architecture, where a microcontroller serves as the Master to control communication with Slave devices like sensors and LCD screens The Master initiates communication by generating a clock signal (SCK) and selecting the appropriate Slave through the Slave Select (SS) line Data flows from the Master to the Slave via the MOSI (Master Out Slave In) line, while the MISO (Master In Slave Out) line facilitates data transmission from the Slave back to the Master This setup allows for full-duplex communication, enabling simultaneous data sending and receiving.

Figure 2.3: SPI protocol from master to slave [6]

The operation of SPI communication involves a defined sequence between a master device and a slave device

Initiation: The master device initiates communication by asserting the Slave

Select (SS) pin of the intended slave device low

In full-duplex communication, the master device can send data to the slave through the MOSI (Master Out, Slave In) line while simultaneously receiving data from the slave via the MISO (Master In, Slave Out) line This simultaneous data exchange allows for efficient and effective communication between the two devices.

Shift registers facilitate data transfer between the master and slave by utilizing 8-bit shift registers As the data is transmitted, it is sequentially pushed into the slave's shift register, one bit at a time.

- Clock: The Serial Clock (SCK) is used to synchronize data transmission

In SPI communication, data bits are transmitted or received on the rising or falling edge of the clock signal (SCK), determined by the configuration settings of CPOL and CPHA The master device generates this clock signal, ensuring synchronized data exchange between the connected devices.

- Termination: Once data transmission is complete, the master raises the SS line back to high This deselects the slave and signifies the end of the communication cycle

Figure 2.4: SPI timing diagram for case CPHA = 0 and CPHA = 1 [5]

SPI configuration has two main configurations, as illustrated in Figure 2 4:

CPOL (Clock Polarity): Determines the logic voltage level of the SCK signal when idle

• CPOL = 0: SCK is low when idle

• CPOL = 1: SCK is high when idle

CPHA (Clock Phase): Defines when data is sampled on the SCK edge

• CPHA = 0: Data is sampled in the middle of the SCK edge

• CPHA = 1: Data is sampled on the rising or falling SCK edge (depending on CPOL)

The combination of CPOL and CPHA results in four SPI modes: (0,0), (0,1), (1,0), and (1,1) Master and slave must use the same mode for successful communication

SPI communication finds applications in various domains, including:

- Connecting Sensors and Actuators to Microcontrollers: SPI is commonly used to connect sensors and actuators to microcontrollers in embedded systems

- Communicating with Memory Cards: SPI is employed to communicate with memory cards, such as SD cards and microSD cards

- LCD Display Control: SPI can control LCD displays

- Audio Codecs: SPI enables communication with audio codecs

The Inter-Integrated Circuit (I2C) protocol, developed by Philips Semiconductors in 1982, is a widely used serial communication method for connecting integrated circuits (ICs) over short distances Its popularity is attributed to its simplicity and versatility, making it an essential choice for various electronic applications.

Serial communication involves the transmission of data one bit at a time through a dedicated serial data line This method is structured around a master-slave configuration, where a single master device oversees the data flow and manages multiple slave devices within the network.

I2C utilizes only two wires for communication:

- Serial Data Line (SDA): Carries the data bits between devices

- Serial Clock Line (SCL): Synchronizes the data transfer, generated by the master device

Addressing: Each device on the I2C bus has a unique 7-bit address, enabling the master to identify the intended slave for communication

Byte-Oriented Data Transfer: Data is exchanged in byte-sized packets (8 bits)

Start and Stop Conditions: The master device initiates communication with a "Start" condition (SDA goes low while SCL is high) and terminates it with a

"Stop" condition (SDA goes high while SCL is high), clearly defining the data packet boundaries

In I2C communication, after a byte is received, the slave device can send an acknowledgment (ACK) by pulling the SDA line low during the ninth clock pulse, or a not acknowledge (NACK) by keeping the SDA high, indicating an error or inability to receive data I2C supports various modes, including standard mode at 100 kbps, fast mode at 400 kbps, fast mode plus at 1 MHz, high-speed mode at 3.4 Mbps, and ultra-fast mode at 5.0 Mbps, with the specific mode determined by the capabilities of the communicating devices.

Combined Read/Write Operations: I2C allows for combined read/write operations in a single transmission, improving efficiency for scenarios where data needs to be read and written sequentially

Microcontrollers and peripherals utilize the Universal Asynchronous Receiver/Transmitter (UART) protocol for efficient serial communication This popular method provides a straightforward and economical solution for data transmission over short distances, employing two dedicated lines: TX for transmitting data and RX for receiving it.

UART utilizes structured data frames to ensure reliable data transmission Each frame begins with a start bit, followed by data bits that carry the actual information, which can range from 5 to 8 bits An optional parity bit may be included for error detection, and the frame concludes with one or two stop bits to signify the end of the transmission.

UART typically operates in two modes:

- Asynchronous Mode: This is the go-to mode for UART communication

Each byte of data is encapsulated within a frame The frame starts with a

OTA PROGRAMMING

OTA (Over-the-Air) programming enables the wireless distribution of new code, including firmware, software, or configuration settings, to embedded devices (EDs) Unlike traditional updates that require physical connections, OTA updates are conducted wirelessly, offering convenience and efficiency These updates serve various purposes, such as fixing bugs, patching security vulnerabilities, or enhancing functionality This article emphasizes firmware updates, which facilitate more significant changes to an ED's behavior compared to mere configuration adjustments While firmware and software are often used interchangeably, firmware typically refers to lower-level code that operates independently of direct user interaction.

Over-the-Air (OTA) firmware updates simplify the updating process for STM32 devices by eliminating the need for specialized equipment like ST-LINK programmers This method allows for seamless updates without the hassle of physically connecting devices, making it especially beneficial for managing numerous devices spread across different locations As long as the updates are free of bugs, users can enjoy a transparent and efficient updating experience.

Remote Updates: For embedded devices located in difficult -to-access remote locations (often communicating via telecommunication channels), OTA allows leveraging the existing communication technology to conveniently upload new firmware

Faster Updates and Improved Security: OTA updates can be deployed quicker, minimizing the time devices operate with buggy or insecure firmware Enhancing user experience and reducing security risks

Over-the-Air (OTA) firmware updates provide a convenient way to update the software on embedded devices (EDs) without requiring physical access While these updates offer significant advantages, they also present challenges that must be addressed to ensure secure and successful firmware deployment on EDs.

A significant challenge in firmware rebuilding is memory management, as embedded devices (ED) require temporary storage to accommodate incoming data packets When large firmware files are transmitted in their entirety, the required storage space must match or exceed the firmware size For instance, microcontrollers such as the STM32F103C8T6, which have limited RAM (20 KB), face difficulties handling substantial firmware updates relative to their flash memory capacity (64-128 KB) This often leads to the necessity of integrating external memory, which can complicate the platform and increase energy consumption.

Successfully transferring new firmware to flash memory necessitates a thorough understanding of the microcontroller's memory architecture and peripherals, including crucial details like the memory's base address and page size This process often requires the use of low-level instructions, adding complexity to the task.

Beyond the limitations of the embedded device itself, OTA programming introduces challenges related to the communication medium and security

To ensure a functional embedded device (ED), maintaining a reliable communication channel during firmware updates is essential Issues such as corrupted data packets, power loss, or connection drops can result in incomplete or unusable firmware Implementing error detection and correction mechanisms, along with robust communication protocols, is vital for safeguarding data integrity throughout the transmission process.

- Security Threats: OTA updates introduce security vulnerabilities Here are three key aspects to ensure a secure update process:

- Data Privacy: Prevent unauthorized access to firmware data by encrypting packets However, the chosen encryption algorithm must be compatible with the ED's limited resources

- Data Integrity: Guarantee that the data hasn't been tampered with during transmission Implement data integrity checks (checksums or cryptographic hashing) to identify any alterations

- Firmware Authenticity: Verify the firmware originates from a trusted source and isn't malicious Utilize digital signatures from a trusted authority and secure update mechanisms to restrict updates to authorized sources

Power Consumption and Bandwidth Limitations:

Battery-powered End Devices, like solar-powered sensors, have limited energy resources Extensive communication during updates can drain the battery

Optimizing the update process and scheduling updates during periods of low power demand can help conserve battery life

Some communication technologies have bandwidth limitations Sending large firmware updates entirely can be time-consuming Techniques like compression and incremental updates transmitted in smaller chunks can address bandwidth constraints

End devices, particularly those powered by solar cells, face energy constraints that limit their operational capacity High energy consumption during firmware updates can lead to device shutdowns, posing significant risks during critical updates Additionally, communication technologies often have bandwidth regulations that restrict the feasibility of transmitting large firmware images, as the process would be excessively time-consuming Addressing these challenges is essential for optimal device performance.

The process of performing Over-The-Air (OTA) updates can vary depending on the specific constraints and requirements of different devices However, a generic solution typically involves the following steps:

To successfully manage the update process, it is crucial to verify that the device's memory can adequately store and handle the updates This includes checking for sufficient available storage space and ensuring compatibility with the new file format.

To ensure a smooth Over-The-Air (OTA) update process, it's essential to prepare the devices by allocating adequate energy and resources Implementing necessary security measures and authentication protocols is also crucial to maintain the integrity of the update process.

To begin the update process, ensure that all devices are prepared and then either trigger the update remotely or schedule it during off-peak hours to reduce disruption to regular operations.

Firmware transmission involves dividing firmware into data packets for over-the-air delivery to devices To guarantee reliable transmission, it is essential to implement error detection and correction methods, including checksums and forward error correction techniques.

Bootloader Analysis involves the examination of firmware packets by the device's bootloader, which validates and authenticates the new firmware to ensure its integrity If the firmware is successfully validated, it replaces the existing version However, if any errors occur during this analysis, the device reverts to the previous firmware to preserve system stability.

BOOTLOADER DESIGN

Boot-loaders vary in size and type, yet their fundamental operation remains consistent across systems Typically, these systems consist of three key components: branching code (green), application code (blue), and boot-loader code (red), as illustrated in Figure 2.5.

The Branching Code (Green) is a crucial component that decides whether to load the bootloader or the application code In simpler systems, it may involve checking the GPIO state to determine entry into bootloader mode Conversely, more advanced systems perform additional checks, such as verifying system integrity, before selecting the execution path Typically found within the bootloader, the branching code is essential for initiating the bootloader or transitioning to the application code.

Once the branching code confirms it is safe to proceed, the application code, highlighted in blue, is executed This code embodies the core functionalities and features of the system, enabling it to perform its intended tasks once fully initialized and operational.

The bootloader code is crucial for initializing essential functions during bootloader operation Upon loading into memory, it configures key peripherals, including the system clock, interrupt service routines, and communication interfaces like UART or SPI This initialization allows the bootloader to effectively communicate with external devices and accept commands for flashing instructions and executing other functions.

A bootloader is a specialized application that stands out from regular applications due to its unique capabilities It occupies the same flash memory space as the main application, enabling it to erase and program new applications Its main function is to initialize the processor and essential peripherals necessary for bootloading, thereby optimizing the available flash space for application code.

Bootloaders can be categorized into two behavioral models: automated and manual The automated model, exemplified by an SD card bootloader, autonomously detects and manages firmware updates within the system In contrast, the manual model relies on external instructions, usually from a PC-based application, to initiate the firmware flashing process This external source directs the bootloader through various states essential for successfully updating the system's firmware.

Bootloaders offer a range of commands that enhance their functionality, including basic operations like erasing and writing flash memory, as well as advanced tasks such as unlocking devices, managing EEPROM, verifying application integrity, and implementing security features While these commands expand the bootloader's capabilities, they may also require additional flash memory space.

The standard process for programming a device includes opening the compatible flashing tool, initiating the bootloader, erasing the flash memory, transmitting the binary file data to the bootloader, generating checksums, and ultimately exiting the bootloader to launch the application.

Software engineers developing bootloaders need specialized tools for monitoring and testing each step of the firmware flashing process, despite the final programming tool usually being automated.

An Interrupt Vector Table (IVT) is a critical list utilized by the processor to manage interruptions, which are requests for the CPU's attention from devices or software Essentially, it serves as a call list for the CPU, ensuring efficient handling of these interruptions.

Interrupts: These are signals from devices or software that need the CPU's attention There are different types of interrupts for different events

The Interrupt Vector Table (IVT) serves as a crucial directory for the CPU, storing the addresses of interrupt handlers that dictate where the CPU should direct its operations upon encountering specific interrupts This table ensures efficient processing by guiding the CPU to the appropriate instructions for each interrupt event.

An interrupt handler is a specialized function that manages specific interrupts by executing designated code when the CPU responds to an interrupt signal.

The specific implementation of IVTs can vary depending on the processor architecture

The Interrupt Vector Table (IVT) is generally found at a specific memory address, such as 0000:0000H in real mode on x86 processors Each entry within the IVT directs to its respective interrupt handler function.

When an interrupt occurs, the CPU temporarily halts its ongoing task to reference the Interrupt Vector Table (IVT), identifying the relevant interrupt handler before executing the corresponding code to manage the interrupt.

Figure 2.6: Vector table of Cortex-M3 Devices [10]

Figure 2.7: The minimal layout of the vector table in an STM32 MCU based on a Cortex-M3/4/7 core [12]

The vector table in STM32 microcontrollers is a memory array that organizes exception and interrupt handlers The first entry points to the Main Stack Pointer (MSP), usually located at the end of SRAM Following this, the table includes addresses for various exception and interrupt handlers Specifically, Cortex-M0/0+ microcontrollers feature 48 entries, while Cortex-M3/4/7 microcontrollers have 256 entries.

2.4.4 The Startup process of Arm MCU

SECURITY WITH ENCRYPTION

In practical applications, symmetric and asymmetric encryption are widely used in embedded systems

Symmetric encryption plays a crucial role in safeguarding sensitive data, including user information and sensor data Efficient algorithms such as AES, DES, and Blowfish are designed to provide robust protection with minimal latency, making them ideal for resource-constrained devices like microcontrollers and IoT sensors For instance, AES encryption is commonly utilized to secure data transmission in Zigbee networks within smart home systems.

Asymmetric encryption plays a vital role in securing key exchanges and authenticating identities, despite being slower than other methods Algorithms such as RSA and ECC are commonly used in embedded systems to facilitate secure communication between trusted devices For example, in remote firmware update systems, asymmetric encryption guarantees that only firmware from authorized manufacturers is installed, effectively preventing attacks from counterfeit firmware.

Combining asymmetric and symmetric encryption enhances security and performance, particularly in SSL/TLS protocols, where asymmetric encryption facilitates the exchange of symmetric keys This approach safeguards transmitted data with symmetric encryption, making it especially suitable for embedded systems that demand both robust security and efficient processing.

Thus, the use of symmetric and asymmetric encryption in embedded systems provides comprehensive protection for data and communications while ensuring the system's operational efficiency

Symmetric encryption typically uses shorter keys compared to asymmetric encryption, resulting in reduced memory and network bandwidth needed to transmit the keys

Symmetric encryption is highly resource-efficient, utilizing less memory and computational power than asymmetric encryption methods This efficiency makes symmetric encryption particularly well-suited for embedded applications that operate under resource constraints.

Symmetric encryption utilizes a single shared key for both the encryption and decryption of messages, ensuring that both the sender and receiver possess the same secret code In this process, plaintext messages are transformed into ciphertext using the shared key, and the ciphertext can be reverted to plaintext with the same key, highlighting the efficiency and simplicity of this encryption method.

2.5.2 Algorithm AES (Advance Encryption Standard)

The Advanced Encryption Standard (AES) is a robust block cipher algorithm adopted by the US government as its official cryptographic standard Similar to its predecessor, the Data Encryption Standard (DES), AES is intended for broad implementation and has been extensively researched After a comprehensive five-year standardization process, the National Institute of Standards and Technology (NIST) officially designated AES as a federal standard.

While its predecessor, Rijndael, could handle data and keys of various lengths, AES specifically operates on 128-bit data blocks and keys with lengths of 128,

The Rijndael key schedule in AES generates subkeys that are essential for each encryption round, with key lengths of either 192 or 256 bits, which must be multiples of 32 bits Each subkey consists of a four-byte column, and most operations within the AES algorithm take place in a finite field of bytes.

The algorithm begins by splitting a 128-bit input data block into 16 bytes, with each byte consisting of 8 bits These bytes are organized into a 4x4 matrix, referred to as the state matrix Throughout the encryption process, different operations are applied to this state matrix to ensure effective data protection.

Figure 2.9: The AES Algorithm Structure [13]

Figure 2.9 provides an overview of the encryption and decryption process of the AES symmetric key algorithm

The AES-128 encryption process transforms plaintext into ciphertext through a series of steps, beginning with the expansion of a 128-bit key into eleven 128-bit round keys via the Key Expansion routine These round keys are utilized in ten rounds of encryption to ensure data security.

In the initial stage of AES encryption, called the Add Round Key step, the plaintext is combined with the Cipher Key using XOR This is followed by nine additional rounds, each consisting of four unique byte-oriented transformations.

The SubBytes step utilizes a predefined substitution table, known as the S-box, to introduce confusion and obscure patterns in plain text By replacing each byte of data with another byte according to the S-box, this process effectively scrambles the data's structure, enhancing security.

The ShiftRows step enhances data diffusion within a block by shifting the rows of the data matrix by designated offsets This operation effectively distributes the influence of each byte across multiple rows, significantly complicating the process of deciphering the original plaintext.

The MixColumns step enhances data security by applying a linear transformation to each column of the data matrix, introducing a layer of confusion This mathematical operation effectively disrupts the relationships between adjacent bytes, further obfuscating the inherent structure of the data.

The Add Round Key step enhances encryption after each transformation round, except the final one, by applying a bitwise XOR operation with a unique round key This repeated use of round keys plays a crucial role in significantly fortifying the overall encryption process.

In the tenth and final round of the encryption process, the MixColumns step is intentionally omitted, distinguishing it from the previous rounds This critical omission allows the ciphertext to maintain its essential structure, facilitating successful decryption while preserving the overall security of the encryption method.

MICROCONTROLLER

The STM32F103C8T6 is a microcontroller from STMicroelectronics belonging to the STM32F1 series [16] STM32F103C8T6 is a versatile microcontroller suitable for a wide range of applications, including:

- Industrial Automation: Can be used in sensor data acquisition systems, motor control applications, and human-machine interfaces (HMIs)

- Consumer Electronics: Can be found in devices like remote controls, smart toys, and wearables

- Internet of Things (IoT): Can be used as the core of battery -powered sensor nodes for data collection and transmission in IoT applications

- Prototyping and Development: Due to its affordability and ease of use, it is a popular choice for prototyping and development of embedded systems Key Features:

- Operates in a voltage range of 2.0V to 3.6V

- 32-bit ARM Cortex-M3 Core: Delivers processing power for various embedded system applications

- 72 MHz Maximum Frequency: Offers a balance of performance and power consumption

- Up to 64KB-128KB Flash memory and 20KB SRAM provide storage for program code, data, and temporary data during program execution

- Analog-to-Digital Converters (ADCs): Convert analog sensor signals into digital values

- Timers: Generate timing signals and enable pulse width modulation (PWM) for controlling motors and LEDs

- Serial Communication Interfaces (UART, I2C, SPI): Facilitate communication with other devices like sensors, displays, and memory cards

Based on the pinout diagram in Figure 2.12, Table 2.2 will provide detailed descriptions of each pin of the STM32F103C8T6 MCU

Table 2.2: Table Pinout of STM32F103C8T6 [16]

Power VDD, VSS VDD (supply voltage) and VSS:

GND (ground) pins for powering the microcontroller

This pin can support read analog with 12-bit resolution

Input/Output Pins PA0 – PA15

Support total 37 pins for connect and control various components

TX1, RX1 TX2, RX2 TX3, RX3

Can Communication via UART protocal with supports of Request to Send (RTS) and Clear to Send (CTS) pins

All of pin input/output can trigger interrupts based on external events

Timers and PWM PA0 - PA3

Pins dedicated to timers for generating timing signals and

PWM (Pulse Width Modulation) output for controlling motors, LEDs, and other peripherals

Facilitate high-speed, full-duplex serial communication between the microcontroller and other SPI- compatible

JTAG/SWD Pins: PA13 – PA14

Used for debugging and programming the microcontroller using JTAG (Joint Test Action Group) or SWD (Serial Wire Debug) interfaces

The ESP32, developed by Espressif Systems, is an affordable series of low-power microcontrollers that feature integrated Wi-Fi and dual-mode Bluetooth Its rich functionality makes it a favored option for a wide range of Internet of Things (IoT) applications.

Based on the Figure 2.13, Hear is the main feature of ESP32 [18]:

- Microcontroller Unit (MCU): Employs a Tensilica Xtensa LX6 microprocessor, available in single-core or dual-core variants, or a single- core RISC-V microprocessor, offering processing power for running user applications

- Integrated Wi-Fi: Supports the 802.11 b/g/n Wi-Fi standards, enabling wireless communication with Wi-Fi networks

- Dual-Mode Bluetooth: Supports classic Bluetooth and Bluetooth Low Energy (BLE) for communication with various Bluetooth devices

- High-Performance Analog Peripherals: Includes Analog-to-Digital Converters (ADCs) for reading analog sensor data and Digital -to-Analog Converters (DACs) for generating analog signals

Digital peripherals offer a diverse array of interfaces, including GPIO (General Purpose Input/Output), SPI (Serial Peripheral Interface), I2C (Inter-Integrated Circuit), and PWM (Pulse Width Modulation), enabling seamless connectivity with a variety of external devices and sensors.

- Low-Power Consumption: Designed for low-power applications with features like sleep modes and power management units to extend battery life in battery-powered devices

- Security Features: Supports various security protocols like WPA2 for secure Wi-Fi communication and encryption capabilities for data protection

- Center frequency range of operating channel: 2412 ~ 2484 MHz

- CPU Core: ESP32-D0WD-V3 or ESP32-D0WDR2-V3 embedded, Xtensa dual-core 32-bit LX6 microprocessor, up to 240 MHz

- Storage: 448 KB ROM & 520 KB SRAM

- Support protocol: UART, SPI, SDIO, I2C, LED PWM, Motor PWM, I2S,

The Internet of Things (IoT) is widely utilized in numerous projects thanks to its wireless connectivity, robust processing capabilities, and energy efficiency Notable applications encompass smart home devices, wearable technology, sensor networks, and industrial automation solutions.

- Wearable Electronics: Suitable for wearables due to its compact size, low power consumption, and Bluetooth connectivity

- Robotics: Can be used in robots for Wi-Fi or Bluetooth communication, sensor data collection, and motor control

- Home Automation: Can be integrated into smart home systems for controlling lights, appliances, and other devices

Figure 2.14: RF SPI LoRa SX1278 433Mhz Ra-02 [19]

The RF SPI LoRa module, as illustrated in Figure 2.14, comprises 16 pins, with the Ra-02 module uniquely supporting interrupt pins This feature significantly optimizes packet reception, thereby improving the overall efficiency of the system.

The RA-02 module, developed by AI-Thinker, is a wireless communication device that leverages LoRa (Long Range) technology It features the Semtech SX1278 chip, enabling efficient long-range and low-power data transmission through a spread spectrum communication link.

The LoRa Ra-02 module is utilized in sensor nodes for efficient data collection and transmission to the gateway Operating in LoRaTM mode, the RA-02 can transmit a maximum payload of 255 bytes, enabling sensor nodes to send essential data such as sensor readings, timestamps, and identification information Depending on configuration factors like transmit power, antenna gain, and environmental conditions, it can achieve transmission distances ranging from 1Km to 5Km.

The Ra-02 modules, selected for this thesis, operate at a voltage threshold of 3.3V, as detailed in Table 2.3 This voltage range is ideal for power-efficient wireless transmission systems.

The AMS1117 is a widely used low-dropout (LDO) voltage regulator integrated circuit (IC) that is essential in many electronic applications It comes in several fixed output voltage options, including 1.5V, 1.8V, 2.5V, 3.3V, and 5V Additionally, the adjustable version, AMS1117-ADJ, enables users to customize the output voltage by utilizing external resistors.

The AMS1117 is capable of providing a maximum output current of 1A and can operate with an input voltage range of 4.75 V to 12 V It comes in a small SOT-223 surface-mount package

The AMS1117 integrated circuit features three essential pins: the IN pin for input voltage, the OUT pin for regulated output voltage, and the GND pin for ground connection, as illustrated in Figure 2.15 and detailed in the datasheet [20] Specifications for this IC are summarized in Table 2.4.

The OLED SSD1306 is a widely used display driver, particularly in embedded systems and IoT devices This organic light-emitting diode (OLED) display driver features an integrated controller designed for graphic display applications.

The OLED display, as shown in Figure 2.16, features four pins: SCK and SDA for I2C communication, VCC for power supply connection, and GND for grounding Detailed specifications for the SSD1306 OLED can be found in Table 2.5 below.

The Sensirion SHT3x series sensors are highly reliable and accurate digital devices for measuring humidity and temperature These sensors are versatile, making them suitable for various applications such as HVAC systems, consumer electronics, and environmental monitoring.

Based on the datasheet [22] of the SHT3x chip in Figure 2 17, we provide the table specification for the SHT31 sensor below:

Digital humidity and temperature sensor

DESIGN AND IMPLEMENTATION

SYSTEM REQUIREMENTS

This thesis outlines a robust system architecture for sensor nodes, emphasizing ease of updates and enhanced network reliability Key components and functionalities include:

- Application update: Develop a modular architecture for sensor node to facilitate easy updates Implement error handling mechanisms to handle failures during firmware updates gracefully

- Android mobile application: to display and monitor sensor data

- A configuration tool: allows developers to upload firmware, offering users a choice of different firmware versions Configure parameters for the LoRa module in Gateway

- Monitoring the firmware update process and ensuring security: including encryption and handling data loss during updates, ensures system stability

- Secure boot: The device only operates with the correct firmware update by checking CRC; it can back up the old firmware if the update fails

- Encryption update: Implements a system for encrypting and decrypting firmware Communication between the gateway and sensor nodes should be encrypted to safeguard against hackers

- Distance operation: The System can update sensor node within 500-1000 meters

Figure 3.1: Overall block FUOTA System Diagram

According to Figure 3.1, the system is structured is as follows :

- FUOTA Target: Collects data from environmental sensors and transfers it to Gateway via LoRa network

- FUOTA Telecom: A crucial component within the gateway responsible for WiFi access and communication with the database and cloud services

- FUOTA Master: Manages data transfer, facilitating the opening and closing of connections with Sensor Node

The Database Server, powered by Firebase, efficiently manages the storage of sensor values collected from sensor nodes via the gateway It also features dedicated fields for firmware information and leverages Firebase Storage for the secure storage of firmware files.

- Mobile App: The mobile application provides a user interface to monitor sensor data received from Sensor Nodes and executes update the software for the Sensor Node

- Tool UI: Used for uploading firmware files and allows developers to manage information about updated versions Additionally, it enables configuration of LoRa parameters during the update process.

HARDWARE

The Sensor Node efficiently collects temperature and humidity data, transmitting it via the LoRa Ra-02 module It features an OLED display to present the gathered information and system status The STM32 MCU manages the LoRa module, sensors, and display, ensuring application updates and security Notably, the STM32 MCU offers flexibility in implementing various security methods, enhancing the overall system integrity This configuration is illustrated in Figure 3.2.

The gateway serves as the central hub for receiving sensor data, managing updates, and uploading information to the server Ideal microcontrollers for this purpose include STM32 and ESP32, known for their processing power and support for various communication protocols, particularly the ESP32 To ensure efficient operation, the gateway utilizes distinct processor and telecommunication blocks.

- Manages two LoRa modules for updating and communicating with sensor nodes

- Handles security in the Gateway

- Controls the OLED display to show the update process and the status of the Gateway

- Manages all information from the Gateway

- Updates information in the database

Table 3.1: Voltage and current supply statistics for Sensor node

Device Quantity Voltage Current Power consumption

Based on the voltage and current data in Table 3.1, all ICs and sensors function within a voltage range of 3.3V to 5V Consequently, designing a power supply unit (PSU) using AMS1117 voltage regulator ICs to provide 3.3V and 5V outputs with a current capacity of 1A will adequately power the entire circuit.

Figure 3.4: Power supply Sensor Node schematic

The circuit features an STM32F103 microcontroller functioning at a voltage of 3.3V, and integrates several modules, including an OLED display and the LoRa Ra-02 module, while being designed to support multiple sensors.

The circuit features a 5.5mm DC jack input designed to accept a 12V power supply To facilitate battery charging, it utilizes two AMS1117 voltage regulators, as illustrated in Figure 3.4, with one regulator providing a stable 5V output and the other delivering 3.3V, ensuring proper voltage regulation for optimal performance.

Figure 3.5: Power Charge Pin block Sensor Node schematic

Using a charging IC such as the DW01A, alongside a protection IC, facilitates efficient battery charging and power management This combination optimizes battery usage as a backup power source, ensuring the device remains operational without external power As a result, the device can autonomously draw on stored battery energy when needed, maintaining functionality.

The STM32F103C8T6 processor block schematic incorporates an 8MHz high-frequency crystal oscillator alongside a 32.8760kHz low-frequency crystal oscillator To ensure stable current operation, the design features four bypass filter capacitors, as illustrated in Figure 3.6.

Figure 3.6: Processor block in Sensor Node schematic

Figure 3.7: LoRa block in Sensor Node schematic

The LoRa Ra-02 AI thinker module comes pre-packaged with the RF-1278 chip inside In the schematic shown in Figure 3 7, we have added 2 capacitors, a

104 and a 22u, to stabilize the current flow

Figure 3.8: Socket supporting I2C, OneWire, and ADC interfaces schematic

In Figure 3.8, with the aim of implementing FUOTA (Firmware Update Over- The-Air), we have decided to design a socket supporting I2C, OneWire, and ADC interfaces

Table 3.2: Voltage and current supply statistics for Gateway

Device Quantity Voltage Current Power consumption

The voltage and current data in Table 3.2 indicate that all ICs and modules function within a voltage range of 3.3V to 5V Consequently, designing a power supply unit (PSU) with AMS1117 voltage regulator ICs to provide 3.3V and 5V outputs at a current capacity of 1A will effectively power the entire circuit.

Figure 3.9: Power supply Gateway schematic

The gateway incorporates an ESP32 module for seamless internet connectivity, similar to the Node sensor As illustrated in Figure 3.9, it operates on a 3.3V power supply for both the Master and Telecom components To achieve stable voltage regulation, two AMS1117 ICs are utilized—one for 5V and another for 3.3V Additionally, 100uF filtering capacitors are integrated to enhance power stability and effectively filter out noise from the power supply.

Figure 3.10: LoRa block in Gateway schematic

The Gateway utilizes two LoRa modules for multi-channel communication, resembling the design of the Sensor Node, as shown in Figure 3.10 To improve stability, a 0-ohm resistor is incorporated into the DIO pin, which manages interrupt controls.

To enhance functionality, we incorporated a switch for independent power control of the ESP32 and added bypass capacitors to minimize power supply noise Furthermore, we extended the bus wires externally to improve communication with other peripherals.

Figure 3.12: 3D Layout of Sensor Node

Figure 3.12 illustrates the 3D layout of the Sensor Node through the Altium software

Figure 3.13 illustrates the 3D layout of the Gateway through the Altium software.

SOFTWARE DESIGN

To meet the specified requirements, the following features and functionalities should be implemented:

Firmware update software is essential for developers, offering tools that facilitate the uploading of firmware files and the configuration of update parameters These tools should feature an intuitive interface for easy selection and uploading of firmware files, along with customizable options for update settings, including frequency and encryption.

Introducing a user-friendly Android mobile application designed for seamless firmware updates, allowing users to easily select and install the appropriate firmware version from a range of available options This app streamlines the update process, enabling users to initiate updates with convenience and efficiency.

To ensure optimal performance, it is essential to implement a system that keeps Sensor Node information current This involves regularly updating sensor parameters, logging the timing of program updates, and maintaining a record of the current firmware version for each node.

To ensure the integrity and confidentiality of firmware updates, it is essential to incorporate robust security measures, including encryption Furthermore, implementing effective error-handling mechanisms can help address potential data loss or corruption that may occur during the update process.

Figure 3.14: Security Firmware Update Process

The firmware update process enhances security with two layers of protection, as illustrated in Figure 3.14 First, the firmware file is encrypted using AES-128-bit in CBC mode through a Python tool, with the encryption key securely stored in the gateway to ensure confidentiality After the telecom device (ESP32) downloads the encrypted firmware, it sends the file to the master for decryption.

After decryption by the master, the firmware is securely stored in internal flash memory The master then segments the firmware into 64-byte packets, adding essential metadata like packet type flags and the target node's address Each packet is encrypted with AES-128-bit in CTR mode before transmission via LoRa.

At the sensor node, encrypted packets are decrypted with the AES key in CTR mode The MCU verifies the integrity of the decrypted firmware before flashing it, ensuring a secure firmware update process This method safeguards against unauthorized access and tampering throughout the firmware's lifecycle.

FIRMWARE DESIGN

3.4.1 Overview of F/W Update Sample Application

Figure 3.15: Flash module organization of STM32F10x [19]

The STM32F10x series features a flash memory capacity of 128 KB, organized into 127 pages of 1 KB each To optimize usage, we have divided the flash memory into two banks: Bank 1 is designated for the active application, sized at 44 KB, while Bank 2 serves as a download slot, also measuring 44 KB.

KB will be allocated for the bootloader

Based on the flash memory described in Figure 3 15, we organize the flash memory sections as shown in Figure 3.16:

Figure 3.16: Map memory customize for OTA in STM32

This organization allows for efficient management and updating of the firmware, ensuring both integrity and reliability during the update proces s

Bootloader Region: Size 20 KB, this region stores the bootloader code responsible for handling firmware updates and booting the device

Bank 1 Region: Size 44 KB, this region contains the currently active application region 1, which is executed during normal operation of the device

Bank 2 Region: Size 44 KB, this region serves as a slot download It stores a copy of the new firmware version to check integrity and verify

Reserved Region: This region is reserved for future use or extensions It provides flexibility for potential future memory requirements

The Header Flag Status Region is essential for storing flags that indicate the status of various components, including firmware images and bootloader status This region acts as a control mechanism for the bootloader and firmware update processes, enabling the device to efficiently manage firmware updates It ensures that both active and backup firmware are securely stored in designated areas Furthermore, the bootloader leverages the header flag status region to monitor firmware image statuses and effectively manage the update process.

Figure 3.17: Overview of F/W Update Sample Application

To clearly illustrate the functionality and operation process of the bootloader program, Figure 3.17 will detail the steps involved when updating a new application on the flash memory partition

When the Firmware Update initiates, the Sensor Node receives an Over-The-Air (OTA) start signal from the Gateway, prompting it to reset and transition to the bootloader program to update the new application on Bank 1.

In the first stage, the bootloader will check the status flag in the header flag region to set the flag for preparing the update of the new application

When a fragment of the firmware of the new application is received from the Gateway, the bootloader will write it to Bank 2 (the slot used to store the new firmware)

Once all fragments of the new application are written to Bank 2, the bootloader program verifies the CRC of the stored image If the CRC check is successful, it proceeds to erase Bank 1 and writes the new application into that bank.

After the update is finished, the bootloader jumps to the application region (Bank 1) to activate the new firmware

Figure 3.18 illustrates the firmware (F/W) image as binary data organized into multiple image blocks Each block contains critical details, including the starting address for program code writing, the code size, and the actual code data This structured arrangement facilitates efficient storage and retrieval of program code during firmware updates.

ImageBlockNum 2 Total number of image block ImageVersion 2 Version of F/W image

ImageSize 4 Total size of F/W image Reserved 1 (Reserved to adjust alignment) Image Verify 4 ImageVerify is used to check F/W image validity

ImageBlockIndex 1 Index of image Block (=1) FlagImageFirmware 1 Flag to recognize this is the block of img F/W Flasing Code 64 Program code (64 byte)

Checksum Value 4 (Note) Checksum value of flashing code

ImageBlockIndex 1 Index of image Block (=1) FlagImageFirmware 1 Flag to recognize this is the block of Image F/W Flasing Code 64 Program code (0 - 64 byte)

Checksum Value 4 (see note above)

The firmware update application, commonly referred to as the bootloader, plays a crucial role in updating the main application by utilizing data from the image blocks contained within the firmware (F/W) image Each firmware file is segmented into multiple image blocks, as detailed in Table 3.3.

Each image block features an index field that denotes its sequence number, with each block being 64 bytes in size when flashed To maintain the integrity of the image block, a 4-byte CRC checksum is added to each block The final block may vary in size from 0 to 64 bytes, depending on the leftover size of the fragmented code.

Figure 3.19: Firmware Update using F/W Image

Figure 3.19 depicts the process of flashing code into designated memory addresses The flashing code is sequentially written to each fragment in the flash memory, ensuring that the firmware is properly partitioned and loaded into the correct memory segments for optimal execution.

Figure 3.20: Header Flag in Flash memory of Sensor Node

Following a successful update, the Header Flag area in Flash memory will accurately display key information fields Specific details stored at designated addresses and offsets are illustrated in Figure 3.20, which showcases the organization and content of the Header Flag area This ensures that all essential information related to the firmware update is correctly recorded and readily accessible.

- OTA Flag Status: Stored at address 0x0801FC00 with an offset 0

- Node Address (1): Stored at address 0x0801FC04 with an offset of 4

- Version (2): Stored at address 0x0801FC04 with an offset of 0

- Application Image Status (3): Stored at address 0x0801FC14 with an offset of 4

- Image Size (4): Stored at addresses 0x0801FC18 with an offset of 8

- CRC (5): Stored at addresses 0x0801FC1C with an offset of C

- Active Region Address (6): Stored at addresses 0x0801FC44 with an offset of 4

These offsets and addresses ensure that the critical fields such as node address, version, image status, size, and CRC are correctly located and can be verified post- update

This thesis explores the broadcast method for communication between the gateway and sensor nodes, as depicted in Figure 3.21, which details the request packets sent from the gateway to the sensor nodes and the structure of encapsulated image blocks for LoRa transmission This approach facilitates efficient and synchronized firmware updates across the entire network.

The "Request packet" is utilized for transmitting requests and receiving responses that convey information between the gateway and sensor node This packet features a payload data length of 16 bytes, which includes 12 bytes allocated for packet information, 2 bytes designated for the address, and 2 bytes reserved for control flags.

The "Fragment packet" is the second type of transmission utilized for sending segmented firmware data Each packet consists of 80 bytes of firmware data, accompanied by 2 bytes for the address, 2 bytes for the packet sequence number, and 1 byte that serves as a flag to indicate that it is a firmware packet.

Figure 3.22: Broadcast method update Broadcast Algorithm for Bitmap Construction:

The proposed broadcast algorithm for bitmap construction significantly decreases transmission and reception time compared to traditional unicast methods When an end device, such as a sensor node, receives a packet fragment of firmware, it marks the corresponding packet in a bitmap array Each element in this bitmap array consists of 8 bits, enabling the management of up to 8 packets efficiently.

- Sensor Node: Upon receiving a packet fragment, mark the corresponding bit in the bitmap array as 1 If a packet fragment is not received, the corresponding bit in the bitmap remains unmarked

To ensure all packet fragments are successfully transmitted, the gateway requests the sensor node to return a bitmap indicating any lost packets The gateway then decodes this bitmap and resends the necessary packet fragments This process of bitmap transmission and packet resending continues until the sensor node confirms that all fragments have been received.

The advantages of using bitmap transmission include significantly reduced transmission time, as the entire bitmap is sent instead of multiple individual packet fragments Additionally, reception time is minimized because the sensor node only needs to process the received bitmap, streamlining the handling of data and enhancing overall efficiency.

- Limitations: Bitmap size limitations, as the number of transmitted packets increases, the bitmap size also grows, potentially exceeding transmission limitations

In Figure 3.22, when the End Device( Sensor Node) receives packet fragment

1, the corresponding bit in the bitmap array is set to 1 Similarly, for packet fragment 0x023D, if the fragment is not received, the corresponding bit remains unmarked

GATEWAY LORA

3.5.1 State machine of The FUOTA Master

The proposed system utilizes a state machine on the STM32 microcontroller, serving as the Master, to facilitate a structured and reliable update process This method also enhances security through encryption, as illustrated in Figure 3.33.

In the IDLE state, the system resets all parameters and requests the gateway to rejoin the network, ensuring optimal operation with the latest firmware This state also readies the system for any upcoming update cycles, if necessary The state machine facilitates a structured and efficient workflow during the firmware update process.

- COLLECT DATA: The state focuses on receiving data from connected sensor nodes Upon successful reception, the system transitions to the START OTA state

To initiate the OTA process, a connection must be established with Telecom, allowing the Gateway to receive the OTA signal During this update, the Gateway requests essential firmware information and LoRa parameters to ensure a successful update.

- RECEIVE F/W: Triggered by an interrupt update OTA signal from the

ESP microcontroller, this state initiates the firmware update process Here, the system retrieves the firmware file from the Telecommunication Unit, responsible for managing network communication

- ENCRYPT: To ensure data integrity and security, the received firmware file is encrypted in this state Upon successful encryption, the system transitions to the Send Update state

In the SEND UPDATE phase, encrypted firmware packets are sent to connected sensor nodes Following the transmission of each packet, the system verifies if additional packets are available If there are more packets to send, the system reverts to the Encrypt state for further processing If no packets remain, it moves to the Update Done state.

The FINISH OTA state confirms the update process's completion by requesting the sensor node to send a bitmap that indicates which firmware sections have been updated If the bitmap is incomplete, indicating a failed update, the system will return to the Send Update state for a retry However, upon receiving a complete bitmap along with a "Response Update Success" message, the system transitions to the Idle state.

3.5.2 Flow chart of The FUOTA Master

Figure 3.34: The FUOTA Master Flowchart

The Master device is responsible for two key functions: acquiring data from sensor nodes and updating applications To effectively manage the complexity of these tasks, we have organized the process into distinct states, as shown in Figure 3.3 of the flowchart.

In the "Collect Data" phase, the Master sets a timer for 5-second intervals to ensure consistent data collection Once the gateway receives data from the sensor node, it enters the "Decrypt" phase to decode the packets After decryption, the gateway moves to the "Transmit Data" mode, relaying the data packets to the ESP for additional processing.

The firmware update process begins when the Master receives an Over-The-Air (OTA) request interrupt from the Telecom, prompting it to halt the timer and prioritize UART communication During this time, the Telecom transmits essential firmware information and configuration parameters, followed by the encrypted firmware file The Master decrypts each firmware packet and stores it in flash memory Once the transfer is complete, the Master sends an OTA request to the sensor node, establishing a successful connection to transmit the firmware packets Throughout this process, the Gateway periodically requests a bitmap from the Sensor Node until the firmware update is successfully completed, after which the OTA process concludes and the Master resets to its initial state.

3.5.3 Flow chart of The FUOTA Telecom

The FUOTA Telecom system, built on the ESP32 platform and utilizing FreeRTOS, effectively manages multiple concurrent tasks essential for the firmware update process of sensor nodes over the LoRa network As illustrated in Figure 3.35, the system comprises six distinct tasks, each playing a vital role in orchestrating the update process This section offers a comprehensive overview of these tasks and their interconnections through a flowchart.

Figure 3.35: Realtime Operating of The FUOTA Telecom Flowchart

- UART Transmission Task: This task is responsible for sending data through the UART interface It transmits commands and data to other devices as needed

- UART Reception Task: This task handles the incoming data through the

UART interface, ensuring all received data is processed and acted upon correctly

- Firebase Update Data Task: This task updates the Firebase Realtime

Database with the latest information from the system, including sensor data and status updates

- Firebase Stream Value Task: This task listens to the status of updates from Firebase Realtime Database It retrieves the latest information from the system

- Firmware Download Task: This task downloads the firmware file from

Firebase to the local device, ensuring the firmware is correctly downloaded and ready for installation

- Update State Task: This task manages the state of the firmware update process, including communicating with the master device and sending the firmware update data

Figure 3.36: Task Update State Flowchart

This thesis presents the Update State Task flowchart, illustrating the interaction between Telecom and the Master during the firmware update process When an update signal is received from the Firebase Realtime Database, the 'Update' state task in FUOTA Telecom is triggered, initiating the firmware download The firmware is divided into packets, which are sequentially transmitted to the Master via UART communication The Master acknowledges each packet and requests the next one until all packets are sent After the transmission, Telecom awaits the Master’s final response to determine the update's success Depending on this response, Telecom either confirms the successful update or reverts to the previous state if the update fails.

In this thesis, we present a user-friendly method for configuring Wi-Fi credentials on LoRa environmental monitoring gateways using an ESP32 Access Point (AP)

Figure 3.37: Connect Wi-Fi Flowchart

The ESP32 simplifies network setup by automatically creating an access point (AP) when disconnected from Wi-Fi, allowing users to easily input their network's SSID and password These credentials are securely stored, enabling the ESP32 to attempt a connection to the specified network Upon successful connection, the AP is disabled, and normal gateway operations resume If connection attempts fail, the web page displays error messages for troubleshooting, keeping the ESP32 in AP mode for retries This method enhances the deployment and maintenance of environmental monitoring gateways, offering flexibility and ensuring reliable configuration.

Figure 3.38: Website for configurating Wi-Fi 3.5.5 Estimate Time Update

This thesis examines the duration needed for Over-the-Air (OTA) updates by calculating the processing time for each data packet during transmission Furthermore, it estimates the download time for firmware updates provided through UART.

The time for Downloading Firmware via UART:

Estimate Time UART = (Size of firmware baudrate ) + Decrypt time + Flash Time (s) (3.1) The data rate for LoRa technology is calculated using the formula:

2 SF ) × 1000 (bps) (3.2) Where SF (Spreading Factor) ranges from 6 to 12, CR (Code Rate) ranges from

Bandwidth (BW) is quantified in kilohertz (kHz), with common values including 10.4, 15.6, 20.8, 31.25, 41.7, 62.5, 125, 250, and 500 kHz The data rate (Rb) is calculated by dividing the packet size (in bits) by the data rate required to transmit a specific packet size.

R b (s) (3.3) Base on formular 3.2 that we have the formula calculate for Total transmission time

Total Transmission Time = Packet size

To calculate the total Over-The-Air (OTA) update time, it's essential to factor in the LoRa packet transmission duration, the time required to read data from flash memory, and the encryption time for the packet The comprehensive formula for determining the total OTA update time encompasses these critical components.

Total OTA time = Estimate Time UART + Total Transmission time +

Flash read time + Encryption time(𝑠) (3.5)

ENCRYPT METHOD

Figure 3.39: Encryption File Firmware Flowchart

In line with the process described, Figure 3 39 incorporates a flowchart depicting the firmware encryption procedure

When a firmware file is selected by the user, it will be encrypted using an AES-

The Gateway utilizes a 128-bit key for AES encryption, processing the binary file in 16-byte blocks Each read operation retrieves 16 bytes, which are stored in a buffer and subsequently encrypted The encryption is finalized once all firmware bytes are encrypted For files that do not conform to a 16-byte multiple, padding bytes are added to the final block, ensuring it meets the 16-byte requirement for proper encryption and preserving the integrity of the encryption process.

Figure 3.40: Decryption File Firmware Flowchart

In alignment with the decryption procedure described, Figure 3 40 illustrates the process for decrypting the firmware file

The decryption of the firmware file received from Telecom involves utilizing the AES-128 bit key and IV stored on the Master The process reads and decrypts each 16-byte block of encrypted data from the file, subsequently writing the decrypted data back to flash memory This continues until the entire firmware file is successfully decrypted and stored Additionally, if the original encryption included padding for non-multiple of 16-byte blocks, the decryption process effectively removes this padding, ensuring the firmware is restored to its original state.

Figure 3.41: Comparison of Encrypted File with Original

As shown in figure 3.41, the original file "Firmware_original.bin" has a size of

The original file size of 34,456 bytes changes when encrypted with the AES-128 algorithm, which requires input data to be a multiple of 16 bytes (128 bits) since each AES encryption block is 16 bytes.

When the original file "Firmware_original.bin" is not a multiple of 16 bytes, the AES-128 algorithm adds padding bytes to the final block, ensuring that the block size is 16 bytes prior to encryption.

Specifically, with the original file size of 34456 bytes:

- Divide the original file size by 16 bytes to determine the number of blocks to be encrypted: 34464

16 = 2154 complete blocks with a remainder of 8 bytes

- To fully encrypt the last block, add 8 padding bytes to the remaining 8 bytes of data, forming a final 16-byte block

Therefore, after adding padding and encryption, the size of the encrypted file will be 34464 bytes

Figure 3.42: Encryption Payload Data Flowchart

In AES encryption's CTR (Counter) mode, each packet is encrypted using a unique incrementing counter IV (Initialization Vector), ensuring that identical plaintexts yield different ciphertexts This uniqueness is vital for safeguarding against packet replay and forgery attacks.

The encryption of payload data, as depicted in Figure 3.42, is a crucial step before encapsulating it into a packet for network transmission This process guarantees the security and integrity of the transmitted data.

TOOL CONFIGURATION

This thesis explores the use of Firebase Realtime Database Storage for storing firmware files and presents a Python tool designed to update configuration parameters in real-time By leveraging Firebase Realtime, we aim to provide immediate responsiveness for users requesting downloads.

The Firebase database will store essential information including LoRa configuration parameters (SF, BW, CR), update status flags for the FUOTA telecom unit (ESP32) to facilitate firmware downloads, and a URL for accessing the firmware file in the storage database It will also include the app version for showcasing the latest updates, the firmware file name, upload time, code size, and the node ID for identifying the target sensor node address for updates.

By leveraging Firebase Realtime Database Storage, we aim to facilitate efficient firmware management and ensure prompt updates to meet user demands

Figure 3.43: Firebase Realtime Database and Firebase Storage

3.7.2 User Interface of Tool (UI)

The configuration tool consists of three pages: Login page, Main page, and Upload Firmware page

In Figure 3.44, upon opening the program, users are required to login, and the login credentials are registered through Firebase authentication

Figure 3.45: The Upload Tab in Main Page

Upon successful login, users are directed to the Main page, which consists of three distinct tabs: Upload, History, and Author Info The Upload tab provides a user-friendly interface for managing serial communication during updates.

The History tab in the system interface offers a detailed record of firmware updates in an easily accessible JSON format Users can examine essential information about successfully uploaded files, such as file name, code size, and LoRa parameters including Spreading Factor (SF), Bandwidth (BW), and Coding Rate (CR) It also shows the corresponding application version for each firmware update, facilitating efficient tracking of update evolution and supporting informed decision-making for deployment, as illustrated in Figure 3.46.

Clicking the "Upload File" button on the Upload tab redirects users to the

The "Configurate FUOTA" page features two main tabs: "File Information," which allows users to set parameters like SF, BW, and CR while selecting the firmware file for updates, and "Version," dedicated to application management.

Figure 3.48: Page Manager Sensor ID

The "Device Manager" tab, illustrated in Figure 3.48, allows users to efficiently manage node address information by adding or removing details All modifications are securely stored in a JSON file, ensuring the integrity of the database.

To add sensor node information, users must select a firmware file by clicking the browse button, ensuring the file size is under 44KB This procedure is visually represented in Figure 3.49.

Figure 3.50: UI App FUOTA on Android Mobile

The Android app illustrated in Figure 3.50 serves two primary functions: it displays sensor data collected from nodes and allows users to easily update to the latest firmware version through the previously designed configuration tool This multifunctional application enhances user experience and improves system management efficiency by facilitating both monitoring and updating processes.

RESULT AND EVALUATION

HARDWARE

We developed three sensor nodes and a gateway circuit, with each sensor node featuring LoRa modules for extended communication range and sensors for environmental data collection The gateway circuit was engineered to oversee communication with the sensor nodes and streamline the firmware update process.

Figure 4.1: Hardware of Sensor Node

Figure 4.1 represents the finalized hardware configuration of the Sensor Node after completion

Figure 4.2 represents the finalized hardware configuration of the Gateway after completion.

UI OF SYSTEM

In a typical setup for a Sensor Node equipped with an OLED display and using a LoRa module for communication, the display will provide real-time feedback to the user

Figure 4.3: UI collect data Node Sensor

In Figure 4.3, the OLED display presents various information fields :

- Version Display: The application version is currently running on the Sensor Node

- Node ID: Unique identifier for the Sensor Node

- Temperature: Real-time temperature reading from the sensor

- Humidity: Real-time humidity reading from the sensor

Figure 4.4: UI OTA Node Sensor

In figure 4.4, when the Sensor Node receives an Over-The-Air (OTA) update signal from the Gateway, the following steps will be taken:

- Display Update Initiation: The screen will show a message "FUOTA INIT" to indicate that the update process is starting

- Preparation for Update: The Sensor Node will prepare to receive the new firmware, setting the necessary software configurations

- Switch to Bootloader: The Sensor Node will switch to the bootloader mode to begin the programming process

This upgrade focuses on creating a seamless and informative firmware update experience for both the gateway and sensor nodes The integration of an OLED display will offer users a visual interface, allowing them to stay informed about the update's progress and current status.

Figure 4.5: UI Firmware Update Process

Upon initiating the firmware update via the mobile application, the gateway begins downloading the firmware, with the OLED display providing a dynamic view of the download progress, including the percentage completed.

After the firmware download is complete, the gateway synchronizes the update parameters with the sensor nodes, while the OLED display shows the current packet being transmitted during this synchronization process.

The display of the currently transmitted packet helps identify potential communication issues during the update process

Upon successful completion of the firmware update, the OLED display prominently shows a notification including the node ID and the updated firmware version, providing clear confirmation of the successful update.

FUNCTIONAL CHARACTERIZATION

We conducted experiments to evaluate the essential functionalities during the Over-The-Air (OTA) process, focusing on the time required for encryption, decryption, and flashing These tests utilized the STM32F103C8T6 chip from STMicroelectronics.

- Logic Analyzer: Used to capture and analyze the timing of different signals

- STLinkV2: Used for programming and debugging the STM32 microcontroller

- Power Supply: The system operates at 3.3V

The experimental setup, depicted in Figure 4.6, features a centrally positioned gateway that guarantees a stable power supply It includes the configuration of communication parameters, the initiation of data collection, real-time monitoring of data transmission, and the implementation of experimental controls to ensure reliability.

Methodology: Each function's execution time is measured using GPIO pins

A GPIO pin is toggled at the start and end of each function to represent the duration of the function

- Encryption Time Measurement: A GPIO pin is set high at the beginning of the encryption function The pin is set low once the encryption is complete

- Decryption Time Measurement: Like encryption, a GPIO pin is toggled at the start and end of the decryption function

- Flashing Time Measurement: The GPIO pin is set high when the flashing process starts The pin is set low when the flashing process is complete

Figure 4.7: Decryption time with AES-CTR

Figure 4.8: Encryption time with AES-CTR

Figures 4.7 and 4.8, we observed that the average encryption and decryption times were nearly equivalent, at around 500 microseconds This fulfills the system's requirement for fast security

Figure 4.9: Timing Characterization for Advanced Encryption Standard

(AES -CBC) and flash read and writes with 64 bytes

In our analysis of decryption performance for 64-byte data blocks, we found that the decryption time was around 2.4 ms, with a flash memory write time of 1.88 ms.

Based on these measurements, we conclude that the current system's processes for decryption, encryption, and flashing operate within milliseconds and microseconds This performance is quite practical for IoT systems.

EVALUATE TIMING UPDATE

We assessed the update time for Sensor Nodes in our system by conducting experiments with different LoRa parameters, including bandwidth (BW), spreading factor (SF), and coding rate (CR) The system functions at a frequency of 433 MHz, which is compatible with the antenna utilized in this project.

In our experiments, we configured the bandwidth to 125 kHz and set the coding rate to 4/5, while varying the spreading factor to evaluate its effect on the update time of Sensor Nodes The firmware update size was 34 KB, and we disabled the gateway's data transmission requirement to concentrate solely on the firmware update process This methodology enabled us to accurately measure the update time across different parameter configurations.

Table 4.1: Firmware Update Time with SF for 34 KB Image

Figure 4.10: Firmware Update Time Chart with SF for 34 KB Image

In our study, we maintained a spreading factor (SF) of 7 and a coding rate (CR) of 4/5 while varying the bandwidth to investigate its effect on the system's update speed This approach enabled us to evaluate how different bandwidth settings influence the duration of firmware updates.

Table 4.2: Firmware Update Time with BW for 34 KB Image

Figure 4.11: Firmware Update Time Chart with BW for 34 KB Image

Based on the experimental results in Tables 4.1 and 4.2, we can draw several

FUOTA Processing Time conclusions regarding the impact of Spreading Factor (SF) and Bandwidth on the update process

As the Spreading Factor (SF) increases, the update time also rises, as demonstrated by our observations where SF12 led to a significant update time of 20 minutes This increase is primarily due to higher SF values resulting in larger packet payloads, which extend the processing time needed to transmit a single packet Consequently, while elevated SF values enhance communication range and reliability, they also lead to longer update times.

Increasing bandwidth significantly improves packet processing times, as demonstrated in Table 4.2, where higher bandwidth values are associated with faster packet transmission speeds By enhancing bandwidth, we can reduce overall update times, leading to a more efficient update process.

In our experiments conducted at a distance of 100 meters under optimal conditions with minimal obstructions, the packet loss percentage consistently remained below 2% This low rate of packet loss demonstrates the robustness of both the communication link and the system's reliability within this range and environmental setting.

The findings indicate that the Spreading Factor (SF) is inversely related to update speed, with higher SF values resulting in longer update times Conversely, increased bandwidth effectively reduces update times Thus, when designing an IoT system, it is essential to balance these factors to enhance both update speed and communication reliability according to the specific deployment scenario.

SYSTEM VERIFICATION

To validate the stability of the system and the functionality of the FUOTA (Firmware Update Over-The-Air) feature, three test cases were designed for the validation process

- LoRa Parameters default connection: SF12, Bandwidth 125 kHz

4.5.1 Test Case 1: Update for Sensor Node

Figure 4.12: Environment setup for testing update Sensor Node

In Test Case 1, we evaluated the system's stability during the update process by deploying three sensor nodes and one gateway, positioned as shown in Figure 4.12 The gateway was strategically located atop the VNVC vaccination center building, with sensor nodes set up at a distance of 500 meters from the gateway Each sensor node underwent individual updates, while key parameters were fine-tuned based on three crucial factors: Spreading Factor (SF), Bandwidth (BW), and Coding Rate (CR) The total area monitored in this test was approximately 1.67 km², as observed on Google Maps.

Figure 4.13: Node Sensor Update to Version 1.5

Figure 4.13 depicts the outcome after successfully updating to version 1.5

For accurate testing, the bandwidth and coding rate will be set at 125 Kbps and 4/8, while the spreading factor will be adjusted sequentially to 7, 9, and 12 The firmware download time from Firebase, approximately 1 minute across all scenarios, will be excluded from the recorded update process duration.

Table 4.3: Update Packet Statistics at SF = 7

Node - ID Packet Send Packet Lost Time Update Time Backup

Table 4.4: Update Packet Statistics at SF = 9

Node - ID Packet Send Packet Lost Time Update Time Backup

Table 4.5: Update Packet Statistics at SF = 12

Node - ID Packet Send Packet Lost Time Update Time Backup

The analysis of the statistical data from tables 4.3 to 4.5 reveals that increasing the spreading factor (SF) leads to a decrease in the total number of packets needed for updates, while simultaneously extending the processing time for each packet A lower SF, such as SF7, is ideal for shorter distances, resulting in a higher packet count but quicker processing times Conversely, higher SF values like SF9 and SF12 are more suitable for longer distances, yielding fewer packets but requiring longer processing times, ultimately enhancing signal strength and reliability over extended ranges.

4.5.2 Test Case 2: Sensor Node Update at Long Range

Figure 4.14: Setup update Test at 1.14km

In our long-distance update test, we positioned the Sensor Node and Gateway in a location characterized by minimal residential building density As illustrated in Figure 4.14, we successfully executed the update over a distance of 1.14 km, as verified using Google Maps.

In this testing session, we attempted updates using two parameters: SF7 and SF9, with a bandwidth of 125 kHz and a coding rate (CR) of 4/5 The application

Gateway update had a fixed code size of 34 KB

Table 4.6: Update Packet Statistics in Long-range Test

SF Packet Send Packet Lost Time update Time backup

However, our results in Table 4.6 indicated that with SF7, the Gateway and Sensor Node were unable to communicate with each other

Our findings indicate that updating nodes in residential areas is feasible within a distance of 1.14 km, with a packet loss rate of less than 5%, which confirms the system's reliability and stability.

Despite its advantages, there are limitations to consider, particularly the lengthy request time for synchronization between the gateway and the Sensor Node For instance, with SF9, the request time was noted to be around 10 seconds.

4.5.3 Test Case 3: Failure Scenarios During Firmware Updates

Figure 4.15: Header region flag status when failure update

This thesis presents a reliable mechanism to address OTA (Over-The-Air) firmware update failures resulting from unexpected power loss The process involves downloading firmware to a secondary memory bank during the OTA update.

2), while the primary memory bank (Bank 1) continues to run the current stable firmware This dual-bank approach ensures that the device can fall back to a

Corrupt Image Status known-good state in case of update failures

During an OTA update, a power loss can lead to the firmware in Bank 2 being marked as corrupt by setting a status flag at memory address 0x801FC30 (offset 4) to 0xFFFFFF4, indicating an interrupted download In contrast, the status flag for Bank 1, found at memory address 0x801FC10 (offset 4), remains active, preserving the last known good firmware.

After a power loss and device reboot, the bootloader checks the status flags of memory banks to decide which firmware to load If Bank 2 shows signs of corruption, the bootloader ignores it and loads the stable firmware from Bank 1, ensuring the Sensor Node resumes normal operation and maintains functionality despite the interruption.

Effective implementation requires meticulous management of status flags, enabling the bootloader to accurately interpret them for safe firmware execution This approach addresses power loss, ensuring reliable system operation and integrity under challenging conditions, ultimately strengthening the robustness of the OTA update process.

4.5.3.2 Faulty Image to Application Region

Figure 4.16: Header region valid format

In this test case, we simulate flashing new software over the existing application in bank 1, as depicted in Figure 4 17 The bootloader first verifies the

The bootloader checks the CRC of the header flag at address 0x801FC00 to detect potential corruption If a mismatch is found, it updates the application status in bank 1 and resets the update header flag to 0x00000000, preventing the system from booting into a corrupted application The bootloader then initiates the firmware update process, sourcing either a valid image from bank 2 or preparing for an OTA firmware reception Once valid firmware is verified, the bootloader updates the header flag with the correct CRC, enabling the system to boot into the new, reliable application.

Figure 4.17: Header flag region in case firmware invalid

CONCLUSION AND FUTURE DEVELOPMENT

CONCLUSION

This thesis explores the implementation of Firmware Update Over-The-Air (FUOTA) in LoRa networks, a technology that is rapidly gaining traction and development Our research has led to significant advancements and milestones in the adoption of FUOTA within these networks.

- Technical Skills: We familiarized ourselves with reading datasheets and programming on various platforms such as CUBEIDE, Android Studio, and Visual Studio

- Programming Languages: We applied multiple programming languages , including C++, C, Python, and Java

- Encryption Algorithms: We explored encryption algorithms like AES and implemented AES-CBC and AES-CTR in our system

- Database Management: We utilized Firebase for data storage and processing, leveraging its real-time capabilities

- Hardware Development: Designed and built three sensor nodes, developed one gateway to manage and communicate with the sensor nodes

- Software Testing: Conducted firmware updates sequentially on all three nodes within a total area of 1 square kilometer, specifically in a densely populated apartment complex, and performed updates over a 1km range

We developed a secure bootloader program that enhances the firmware update process by implementing encryption and security measures This program features mechanisms to detect software corruption during updates and ensures reliability by allowing a seamless rollback to the previous stable version if any corruption is identified.

To enhance security in data transmission over the LoRa network, a secured connection between the Gateway and Sensor Node is established using the AES-CTR (Advanced Encryption Standard in Counter Mode) algorithm This implementation safeguards firmware updates from unauthorized access and potential tampering, ensuring the integrity and confidentiality of the transmitted data.

The current limitation of 3.3V for sensors restricts compatibility with various components, making it essential to explore a wider voltage range Moreover, a detailed analysis of energy consumption during the update process is lacking, which could be crucial for optimizing energy efficiency Evaluating power usage during updates is vital for ensuring the system meets the demands of low-power IoT applications.

- Network Scalability: The inability to add new nodes limits the system's scalability Implementing support for adding new nodes is crucial

- Multi-Node Updates: The single-node update limitation hinders efficiency in larger networks Enabling simultaneous updates on multiple nodes is necessary

- Concurrent Operations: The lack of support for concurrent data collection and updates restricts continuous monitoring and updating capabilities in sensor nodes Implementing this functionality is essential

The system is inspired by LoRaWAN's features but has been simplified to align with the thesis's scope, ensuring essential functionalities are preserved while enabling a streamlined and manageable implementation.

In conclusion, although we have made notable advancements in creating a FUOTA system for LoRa networks, there are still key areas that need enhancement to improve the system's functionality, scalability, and overall user experience.

PROJECT IMPROVEMENT

- LoRaWAN Integration: Expand the project's reach by enabling compatibility with LoRaWAN networks This will allow deployment of existing LoRa infrastructure for wider adoption

- Enhanced Security and Activation: Implement Over-the-Air Activation (OTAA) for secure device registration Additionally, strengthen security protocols between applications and servers to guarantee reliable communication

- Multi-Device Updates: Develop a framework for efficient firmware updates across multiple devices simultaneously, improving scalability and streamlining the process

- Gateway Performance Optimization: Research and develop algorithms, such as load balancing and routing strategies, to optimize gateway performance and enhance overall network efficiency

- Multi-Channel Gateway Management: Implement a Real-Time Operating System (RTOS) on gateways to enable multi-channel operation This will improve resource utilization and lead to better overall performance

- Update Management and Estimation: Introduce features that estimate update needs and manage updates across the system This will provide greater control and monitoring capabilities

By focusing on these areas, the project aims to further enhance its functionality, compatibility, and performance, paving the way for broader adoption and deployment in real-world applications

[1] K E F Mekki, "Comparative study of LPWAN technologies for large -scale

IoT deployment," ICT Express, vol V, no 1, pp 1-7, March 2019

[2] Semtech, "What is LoRa," Semtech, [Online]

Available: https://www.semtech.com/lora/what-is-lora

[3] 3GLTEonfo, "LoRa Architecture," 3GLTEonfo, 2020 [Online] Available: https://www.3glteinfo.com/lora/lora-architecture

[4] Semtech Corporation, "SX1276/77/78/79 Datasheet," SX1278 Datasheet,

[5] Wikipedia, "Serial Peripheral Interface," Wikipedia, March 2021 [Online]

Available:https://en.wikipedia.org/wiki/Serial_Peripheral_Interface

[6] N Abbas, "UART vs I2C (vs SPI): Understanding the Differences," Naveed

Available:https://www.prodigytechno.com/spi-protocol

[7] E.P Mary Grace Legaspi, "I2C Communication Protocol: Understanding

I2C Primer, PMBus, and SMBus," Analog Dialogue, vol 55, no 4, pp 1-4,

[8] V Kanade, "What Is Universal Asynchronous Receiver-Transmitter

(UART)? Meaning, Working, Models, and Uses," Spiceworks, 22 March 2024.[Online].Available:https://www.spiceworks.com/tech/networking/arti cles/what-is-uart/ [Accessed 13 May 2024]

[9] J.Beningo, "The bootloader System", in Bootloader Design for

Microcontrollers in Embedded Systems, Beningo Engineering, 26 June

[10] ARM, "Cortex-M3 Technical Reference Manual," ARM, [Online]

Available:https://www.keil.com/dd/docs/datashts/arm/cortex_m3/r1p1/ddi 0337ecortexm3r1p1trm.pdf [Accessed 13 May 2024]

[11] Wikipedia, "Sysmmetric-key algorithm," Wikipedia, December 2015

[Online].Available:https://en.wikipedia.org/wiki/Symmetric -keyalgorithm [Accessed 13 May 2024]

[12] N Carmine, "Booting Process," in Mastering STM32, Italy, leanpub, 2022, pp 565-567

[13] K Sliman Arrag, "Design and Implementation A different Architectures of mixcolumn in FPGA," International Journal of VLSI Design and Comminication System, vol III, no 4, pp pp 3-5, 2015

[14] W Stallings, "Cryptography and Network Security: Principles and

Practices Fourth Edition," NJ, Prentice Hall, vol XVI, no 12, pp 100-125,

[15] M WiMAX, "Advanced Encryption Standard," Mobile WiMAX, 2011

Available:https://www.sciencedirect.com/topics/computer- science/advanced-encryption-standard [Accessed 13 May 2024]

[16] STMicroelectronis, "Datasheet stm32f103x," DS531 Datasheet, July 2007,

[17] Espressif Systems, "ESP32 Series Datasheet," ESP32 Datasheet, Feb 2007,

[18] GreeksForGeeks, "Firebase – Introduction," GreeksForGeeks, 15 July 2021

[Online] Available: https://www.geeksforgeeks.org/firebase-introduction/ [Accessed 15 May 2024]

[19] Ai-Thinker Technology, "Ra-01/Ra-02 LoRa Module User Manual," Ai-

Available: https://docs.ai-thinker.com/en/lora/man

[20] Advanced Monolithic Systems Ltd, "AMS1117 datasheet," AMS1117 datasheet

[21] Solomon SysTech, "SSD1306 Advance Information," Solomon SysTech,

[22] Sensirion, "Datasheet SHT3x-DIS," Datasheet SHT3x-DIS , November

[1] Schematic Diagram of the Sensor Node

[2] Schematic Diagram of the Gateway

[3] Source Code: https://github.com/sprchuoi111/FOTA_LORA