A Secure Telemetry Transmission Architecture Independent of GSM: An Experimental LoRa-Based System on Raspberry Pi for IIoT Monitoring Tasks

Abstract

The growing demand for autonomous and energy-efficient telemetry systems in Industrial Internet of Things (IIoT) applications highlights the limitations of GSM-dependent infrastructure. This research proposes and validates a secure and infrastructure-independent telemetry transmission architecture based on Raspberry Pi and LoRa technology. The system integrates lightweight symmetric encryption (AES-128 with CRC-8) and local data processing, enabling long-range communication without reliance on cellular networks or cloud platforms. A fully functional prototype was developed and tested in real urban environments with high electromagnetic interference. The experimental evaluation was conducted over distances ranging from 10 to 1100 m, focusing on the Packet Delivery Ratio (PDR), Packet Error Rate (PER), and Packet Loss Rate (PLR). Results demonstrate reliable communication up to 200 m and high long-term stability, with a 24 h continuous transmission test achieving a PDR of 97.5%. These findings confirm the suitability of the proposed architecture for secure, autonomous IIoT deployments in infrastructure-limited and noisy environments.

1. Introduction

The Industrial Internet of Things (IIoT) places strict requirements on the autonomy, reliability, and energy efficiency of wireless data transmission systems [1]. These factors become especially critical in remote and hard-to-reach locations—such as mines, farms, power nodes, and industrial facilities—where GSM coverage is unstable or entirely unavailable, and traditional telecommunication infrastructure cannot be deployed [2,3]. In such environments, there is a growing demand for independent telemetry systems capable of functioning without reliance on mobile network operators or cloud-based platforms [4].

Among available solutions, Low Power Wide Area Network (LPWAN) technologies—particularly LoRa—stand out due to their long communication range, low power consumption, and resilience to radio interference [5,6]. When integrated with open-source platforms such as Raspberry Pi and Python 3.11, these technologies enable the development of flexible, reproducible, and cost-effective monitoring systems [7].

This article addresses the analysis of wireless technologies applicable in scenarios without GSM connectivity and presents the design and experimental validation of a secure telemetry transmission architecture based on Raspberry Pi and LoRa [8]. The primary objective is to evaluate the feasibility of such solutions for industrial monitoring in isolated or infrastructure-limited areas [9,10].

The key contributions of this work are as follows:

-

Architecture design and implementation: Development of a secure telemetry transmission system based on Raspberry Pi and LoRa, operating independently of GSM networks and centralized server infrastructure;

-

Lightweight security mechanisms: Integration of resource-efficient cryptographic protection (AES-128 with CRC-8), ensuring confidentiality and data integrity in constrained IIoT environments;

-

Experimental validation in real-world conditions: Field testing in urban environments with significant electromagnetic interference, with an evaluation of applied engineering metrics (PDR, PER, and PLR) across distances from 10 to 1100 m;

-

Reliability assessment: Long-term stability verification through a continuous 24 h experiment, confirming robustness against interference;

-

Outlook and future research directions: Critical discussion of current limitations and perspectives, including the adoption of authenticated encryption modes (AES-CCM/GCM), autonomous energy supply, and integration with SCADA/MQTT platforms.

2. Related Works

To this end, the research includes a comparative review of modern wireless technologies (LoRa, ZigBee, Mesh, NB-IoT, etc.), examining their performance in terms of energy efficiency, security, and compatibility with open hardware and software platforms [5,6,10]. The proposed architecture incorporates lightweight applied cryptography (AES-128 with CRC-8) to minimize computational overhead, while supporting local data processing for enhanced autonomy [4].

A distinctive feature of the proposed system is its independence from GSM and cloud infrastructure, combined with verified transmission reliability under conditions of urban radio interference [3]. The experiments involved the continuous transmission of structured telemetry packets over distances ranging from 10 to 1100 m, with the performance evaluated using PDR, PER, and PLR metrics. The results demonstrated a stable system operation at distances up to 200 m, while maintaining the required level of data integrity and security. Consequently, the proposed solution is well-suited for scenarios such as stationary emission source monitoring, edge analytics, SCADA systems, and other applications in environments lacking mobile network infrastructure.

Modern industrial facilities—particularly those located in remote, isolated, or underground environments such as mines, quarries, agricultural areas, offshore platforms, and solar power plants—increasingly require reliable and autonomous monitoring systems. A key limitation in establishing such systems is the inability to rely on traditional cellular communications (GSM) due to physical, geographical, economic, and technical constraints [1,2,3,4].

The primary challenges of using GSM in remote monitoring include unstable or entirely absent signals in underground or shielded environments, high energy consumption of equipment, dependence on operator infrastructure, and the associated financial costs [2,3,5,6,7]. In mining operations, for example, cellular signals fail to penetrate rock layers and are subject to severe distortion and attenuation [1,2].

As a result, there is a growing interest in wireless transmission technologies that operate independently of GSM infrastructure. Low Power Wide Area Network (LPWAN) solutions—such as LoRa, LoRaWAN, ZigBee, and Bluetooth Mesh—are of particular relevance [1,2,8,9]. These technologies provide extended transmission ranges (up to 10–20 km or more), high energy efficiency, the ability to establish autonomous networks, and significantly lower ownership costs compared to cellular alternatives [4,5,8].

LoRa and LoRaWAN are among the most extensively studied and widely implemented LPWAN solutions. Their use of the Chirp Spread Spectrum (CSS) modulation enables stable data transmission even in the absence of line-of-sight and under low signal-to-noise conditions, which is particularly important in underground and industrially saturated environments [2,3]. The star-of-stars network architecture, combined with the possibility of signal duplication across multiple gateways, further enhances system reliability [2]. These features make LoRaWAN highly suitable for applications such as equipment and environmental monitoring, as well as tracking the movement of personnel and assets [1,2,4,8].

For scenarios requiring local area networks with specialized topologies, the ZigBee protocol—based on the IEEE 802.15.4 standard—provides an alternative. It is distinguished by an ultra-low energy consumption and mesh architecture that ensures fault tolerance in the absence of a centralized control node. When combined with Wi-Fi, ZigBee gateways can be seamlessly integrated with cloud platforms for centralized management [8].

Another option is Bluetooth Mesh, which builds on Bluetooth Low Energy (BLE). Its advantages include scalability to tens of thousands of devices, a high fault tolerance achieved through flooding-based routing, and minimal energy consumption enabled by Low Power Nodes [9]. This technology is particularly promising for use in concrete structures, tunnels, and other infrastructure-constrained environments.

In practice, LPWAN-based systems are already successfully deployed across multiple industrial domains. For example, LoRa and Wi-Fi have been used in SCADA-based monitoring systems for remote solar farms and offshore platforms without GSM infrastructure, while visualization and management are performed via cloud services such as The Things Network, AWS, and Grafana [4,6,7]. In the energy and oil industries, LPWAN solutions are increasingly integrated with edge computing: data is processed locally on Raspberry Pi-based devices and transmitted to the network using lightweight protocols, such as MQTT, when needed [10].

Thus, the transition from GSM to LPWAN should not be viewed merely as the replacement of communication protocols but as a fundamental rethinking of industrial monitoring architectures. This shift emphasizes autonomy, energy efficiency, fault tolerance, and independence from external infrastructure—attributes that are particularly relevant within the frameworks of the Industrial Internet of Things (IIoT) and Industry 4.0 [3,5,10].

Modern industrial systems increasingly rely on wireless data transmission as the backbone for flexibility, scalability, and energy efficiency. Selecting the appropriate communication technology becomes critically important in remote facilities with limited infrastructure and strict autonomy requirements. Available solutions range from short-range protocols (ZigBee, BLE, and Wi-Fi) to cellular options (NB-IoT, LTE-M, and 5G) and LPWAN. However, this variety necessitates a careful engineering analysis tailored to real-world application conditions. Within this context, LoRaWAN emerges as a particularly balanced solution for monitoring, automation, and small-scale data transmission in resource-constrained environments [2,5,11,12].

Short-range protocols such as ZigBee, BLE, Wi-Fi, and UWB, although supported by mature standards and offering low power consumption, are limited in range (typically 100–250 m) and are vulnerable to radio interference, especially in metallic or electromagnetically noisy industrial settings [11,13,14,15]. ZigBee and BLE require repeaters and complex routing mechanisms when scaled, while Wi-Fi—despite its high throughput—demands a constant power supply and is characterized by high energy consumption, making it unsuitable for autonomous sensor nodes [2,15].

Cellular technologies such as NB-IoT and LTE-M provide wide coverage and reliable data transmission through licensed frequency bands and carrier-managed infrastructure. However, their applicability is constrained by several factors: dependence on stable GSM signals, recurring costs for subscriptions and modems, and an increased complexity in device configuration [5,11,16]. Emerging technologies such as 5G and RedCap offer a low latency and high throughput, yet in remote industrial environments, they are often excessive in terms of resource requirements and remain limited by insufficient signal penetration [17].

In contrast, LPWAN technologies—and particularly LoRaWAN—offer a more balanced, engineering-oriented solution. Operating in unlicensed frequency bands, LoRa does not require operator support and achieves transmission ranges of 15–40 km depending on deployment conditions [2,5,11]. Its Chirp Spread Spectrum (CSS) modulation ensures robust communication at low signal-to-noise ratios and under shielding conditions commonly found in mines, warehouses, and other isolated facilities [14].

LoRaWAN further benefits from its star topology, scalability, Adaptive Data Rate (ADR) mechanisms, and gateway redundancy, enabling the design of both lightweight single-layer networks and resilient multi-layer architectures [2,12]. Practical deployments confirm these advantages: case studies such as ArcelorMittal Vega and the Mipt mine monitoring system demonstrate that multiple base stations and controllers can provide reliable connectivity across extensive industrial sites, including underground areas [13,14].

Moreover, LoRaWAN can be seamlessly integrated into existing infrastructure (brownfield projects) without the need for new cabling and is capable of operating in a fully autonomous mode [16]. With device lifetimes exceeding 10 years on battery power and significantly lower deployment and maintenance costs compared to NB-IoT or LTE-M—especially in low sensor-density scenarios—LoRaWAN presents a cost-efficient and sustainable option for industrial monitoring [5].

Another important advantage of LoRaWAN is its built-in security: the protocol employs AES-128 encryption and supports isolated topologies that reduce potential attack vectors. Furthermore, the integration of edge computing within IIoT–LPWAN architectures enables local data processing, thereby decreasing dependence on cloud channels and enhancing the protection of critical information [3,16].

A system-level analysis of LoRaWAN applications confirms its high efficiency across multiple industrial domains:

-

Mining industry—monitoring environmental parameters, as well as tracking personnel and equipment [2,14];

-

Industrial facilities—predictive maintenance, asset health monitoring, and environmental control [11,16];

-

Agriculture and remote sites—irrigation management, resource accounting, and climate control in areas without GSM coverage [15];

-

Digital modeling—construction of reproducible scenarios within GeNESIS architectures [12].

Although LoRaWAN has inherent limitations in bandwidth and latency, it remains a technically, economically, and architecturally sound choice for distributed IIoT systems. The technology demonstrates a reliable performance in complex radio environments, provides energy efficiency, independence from external infrastructure, and ensures secure data transmission. These characteristics make LoRa particularly relevant in the context of Industry 4.0 and the emerging transition toward Industry 5.0, where autonomy, simplicity, and security are becoming key priorities [3,5,11,12,14,15,16].

To advance practical implementations, it is essential to examine the architectural features and application scenarios of these technologies. LoRa (long Range) and LoRaWAN (LoRa Wide Area Network), as core components of the LPWAN class, offer strong noise tolerance, energy efficiency, and flexibility of deployment under diverse infrastructure conditions [2,18].

Despite their close relationship, the two technologies fulfill distinct roles within the communication model. LoRa implements the physical and part of the data link layers of the OSI model using Chirp Spread Spectrum (CSS) modulation, which ensures signal stability under attenuation and multipath distortion. LoRaWAN, by contrast, provides the upper-layer protocol stack, handling routing, encryption, authentication, and overall network management [5,19].

From an architectural perspective, LoRa can be deployed in a point-to-point (P2P) configuration, suitable for small-scale autonomous solutions with line-of-sight connectivity between nodes [7,20]. However, for distributed systems that require centralized data aggregation and a higher reliability, a LoRaWAN architecture based on the “star-of-stars” topology is preferable. In this setup, data from end devices is transmitted to one or more gateways, which subsequently route the information to a central server [18,21].

LoRaWAN demonstrates a strong resilience in demanding scenarios—such as underground mines, agricultural areas, and energy systems—by supporting scalability, maintaining stable transmission under interference, and enabling the use of intermediate repeaters optimized for residual energy, signal strength, and node density [2,14,19,22].

In practice, LoRaWAN technologies are already deployed across multiple industries. In the energy sector, they are applied to monitor network parameters and renewable energy installations, as well as to integrate with industrial protocols and visualization platforms such as Grafana and Node-RED [22,23]. In environmental monitoring, LoRa ensures reliable communication in remote regions by transmitting data on the microclimate, air pollution, and humidity levels [5,21]. In agriculture, it supports precision farming, climate control, and autonomous sensor operation [2,5]. In industrial and underground facilities, LoRa is used for temperature and methane control, personnel tracking, and infrastructure monitoring, often employing multi-gateway architectures and TDOA-based localization algorithms [2,14].

Within the context of digital production systems (Industry 4.0), LoRa infrastructures integrate with platforms such as MQTT, Node-RED, and Apache Cassandra, enabling both real-time and offline data processing scenarios [18].

Nevertheless, several technical limitations must be considered when implementing LoRaWAN. First, some deployments lack robust cryptographic protection, which increases security vulnerabilities [2,7,18]. Second, real-world operating conditions—such as electromagnetic interference, humidity, and mechanical vibrations—often differ significantly from laboratory test environments, potentially reducing performance and reliability [14,22].

Additionally, the ALOHA-based MAC scheme underlying LoRaWAN imposes scalability constraints: as device density increases, the probability of collisions grows, thereby reducing transmission reliability [5,14]. Another limitation is the absence of a handover mechanism between gateways, which complicates deployment in dynamic environments with mobile equipment [14]. Moreover, many systems remain at the stage of bench modeling, without adequately accounting for the realities of multi-user industrial environments [7,22].

The choice between LoRa and LoRaWAN architectures should be task specific. A point-to-point (P2P) model is justified in small-scale, isolated solutions where infrastructure is minimal, and routing is unnecessary. In contrast, LoRaWAN is preferable in distributed systems that require centralized management, security, reliability, and scalability [20,21].

Overall, LoRa and LoRaWAN represent powerful tools for building flexible, cost-effective, and energy-efficient IIoT networks. However, their successful deployment requires not only an understanding of architectural features but also careful engineering adaptation to operating conditions, secure protocol implementation, and fault-tolerant design [5,7,23].

The comparative analysis of architectural approaches and application scenarios highlights the high adaptability of LoRa-based technologies to conditions with limited infrastructure. Nevertheless, in certain cases—particularly in isolated or critically autonomous systems—there is a need for alternative solutions that reduce the reliance on centralized logic and external communication channels.

In this context, the engineering combination of the Raspberry Pi single-board computer and LoRa technology as the physical communication layer is of special interest. This hybrid approach represents one of the most practical and energy-efficient solutions for monitoring in industrial, agricultural, and remote IIoT environments. Raspberry Pi provides local data processing, network control, and peripheral interaction without requiring server infrastructure, thereby enhancing autonomy and resilience [1,14,15,17,18,23,24,25,26,27].

The Raspberry Pi platform is well-suited for autonomous monitoring systems due to its open architecture, flexibility, support for diverse interfaces, and an active developer community. It can efficiently perform data collection, preprocessing, and local decision-making, while also functioning as a gateway or control node within SCADA and IIoT networks [14,18,23,24,25,26].

The LoRa technology ensures stable, noise-resistant communication even under conditions of strong electromagnetic interference or shielding. The use of the Chirp Spread Spectrum (CSS) modulation provides a high sensitivity (down to −150 dBm), making LoRa applicable in challenging environments, from underground mines to metal-walled industrial halls [1,14,23,27].

While LoRaWAN offers advantages in routing and device management, its full deployment in isolated scenarios is often redundant. For autonomous solutions, the architectural abandonment of LoRaWAN reduces computational and energy costs, simplifies implementation, and increases system autonomy [1,14,15,18,24,25,26,27]. Similarly, heavy-weight cryptographic protocols such as TLS are impractical in environments without permanent server connectivity. Instead, resource-efficient applied protection mechanisms are employed [14,15,17,24].

The engineering approach to security in the proposed system relies on a combination of lightweight cryptography and structural communication reliability:

-

Data integrity control via CRC, HMAC, and timestamp verification in LoRa packets [15,23,24];

-

Noise resilience through CSS spectral selectivity, adjustable power and frequency settings, and TDMA operation modes [17,25];

-

Channel loss compensation using MQTT with QoS buffering and retransmission [1,15,18];

-

Lightweight cryptographic primitives such as ChaCha20, Ascon, PCHC, AES-CCM, and static DH-based key exchange schemes [15,24,25];

-

Local data management and routing directly at the Raspberry Pi level, without reliance on external infrastructure [17,25,26].

Therefore, the system remains stable even when complex protocol stacks are abandoned, since security is ensured at the level of architectural and software solutions.

In practice, the Raspberry Pi + LoRa approach with local data processing has been proven effective for

-

Autonomous monitoring in the absence of Internet and server infrastructure;

-

Scalable deployments in agriculture, mining, and industrial control systems [1,15,26];

-

Secure industrial environments capable of detecting incidents and failures [27];

-

Experimental cobot networks and wireless TSN prototypes within the Industry 5.0 paradigm [17].

Integrating Raspberry Pi with LoRa, while avoiding the full implementation of LoRaWAN and TLS protocols, represents a balanced engineering solution for autonomous, reliable, and energy-efficient IIoT networks. The availability of inexpensive hardware, architectural flexibility, and local management capabilities make this approach particularly relevant under conditions of limited resources and high isolation. This expands the applicability of LoRa solutions beyond conventional use cases, enabling high adaptability to modern industrial realities [1,14,15,17,18,23,24,25,26,27].

At the same time, despite significant theoretical research and numerous conceptual proposals, there is still a clear shortage of applied solutions tested under conditions of real electromagnetic interference and infrastructural constraints [3,14,17,19,20,23,24,28,29,30]. The most acute engineering gap lies in the absence of secure, autonomous, and energy-efficient LoRa networks built on low-cost and versatile platforms such as Raspberry Pi. Although the potential of this platform for SCADA/IIoT architectures has been repeatedly emphasized, its use as the core of a fully independent LoRa infrastructure remains limited in both the number of implementations and the depth of experimental validation [14,19,24,28].

A significant part of current research remains focused on theoretical modeling and algorithmic simulations rather than real-world deployment. Studies often concentrate on cryptographic protocols, routing optimization (e.g., approaches based on the Transient Trigonometric Harris Hawks Optimizer), and network topology design, while overlooking practical constraints such as electromagnetic interference, unstable power supply, vibrations, and radio noise that critically affect communication quality in industrial and remote scenarios [14,17,19,30].

Another major limitation is the weak integration of applied engineering metrics. Key indicators such as the Packet Delivery Ratio (PDR), Packet Error Rate (PER), Packet Loss Probability (PLR), average energy consumption per byte, and connection recovery time are rarely addressed in a comprehensive manner. Instead, much of the focus remains on abstract measures such as the cryptographic strength or visualization tools, which reduces the reproducibility and practical applicability of the proposed architectures [3,20,24,28,30].

A further challenge lies in the predominance of cloud- and server-centric architectures. While suitable for urban networks, such designs are unsuitable in areas without stable connectivity, where autonomous routing, local data processing, and resilience against DoS, spoofing, and jamming attacks are critical [17,20,24,30].

Finally, despite the acknowledged strengths of LoRa in low-infrastructure and interference-prone environments, research attention remains disproportionately focused on Wi-Fi and Bluetooth. As a result, most LoRa-based systems are limited to laboratory prototypes and fail to demonstrate robustness in real-world urban, industrial, or rural deployments with high interference densities [3,19,20,28].

A comparative summary of the discussed wireless technologies in terms of communication range, energy efficiency, infrastructure requirements, and implementation feasibility is presented in

Table 1. Comparative characteristics of wireless communication technologies for autonomous industrial monitoring systems.

Parameter	Proposed System (LoRa + Raspberry Pi)	ZigBee	BLE Mesh	NB-IoT
Max range (urban environment)	Up to ~200 m (PDR > 90%), tested up to 1.1 km	10–30 m	30–50 m	1–10+ km
Resistance to radio interference	Confirmed in field tests; uses Chirp Spread Spectrum (CSS)	Sensitive to industrial interference	Performance degrades in reinforced environments	Stable due to licensed spectrum
Device energy consumption	~120 mA during transmission, varies by scenario	Typically <50 mA	10–20 mA average	100–300 mA during transmission
Autonomy/no GSM dependency	High; no GSM, cloud, or server infrastructure required	Moderate; mesh needs multiple nodes	Moderate; depends on node density	Low; requires SIM and network coverage
Local data processing supported	Fully supported on Raspberry Pi	Limited	Limited	Depends on device firmware
Security protocol used	AES-128 with CRC-8; optionally AES-CCM/GCM	Optional AES-128	Optional AES-128	LTE-grade SIM encryption and optional TLS
Infrastructure type	Independent (point-to-point or local), no operator dependency	Mesh; requires dense topology	Mesh; flooding-based routing	Operator-managed infrastructure
Deployment cost	Low; based on open-source hardware and software	Low	Low	Medium to high; requires modems and SIM plans
Hardware availability	Raspberry Pi with LoRa modules	Standardized and widely available	Standardized and widely available	Certification often required
Openness/reproducibility	Fully open-source and reproducible	Partially open source	Partially open source	Proprietary; limited reproducibility
Real-world testing	Validated in urban field tests (PDR, PER, PLR, noise, and vibration)	Mostly lab-level evaluations	Mostly lab-level evaluations	Field-tested but with commercial-grade devices
Server dependency	None	None, but repeaters/gateways often required	None, but needs routing nodes	Yes; server/cloud backend is mandatory

.

The summarized comparison further supports the rationale behind the proposed LoRa-based system architecture, which combines long-range, energy-efficient communication with practical feasibility in real-world IIoT scenarios.

Moreover, despite the rapid development of LoRa technologies and the widespread adoption of SCADA/IIoT architectures, a critical scientific and engineering gap remains: the absence of reproducible, secure, and fully autonomous communication systems implemented on open, accessible platforms and validated beyond laboratory conditions.

Addressing this gap is not limited to producing another prototype; it represents the creation of a methodological foundation for future research in sustainable communications, edge analytics, and resilient data transmission under conditions of limited infrastructure.

The experimental objective of this research is not merely to demonstrate system operability, but to comprehensively evaluate the applicability of an autonomous LoRa-based architecture under urban radio interference conditions. The evaluation includes applied engineering metrics and accounts for real-world constraints such as noise, vibrations, unstable power supply, and the absence of reliable communication channels. This approach makes it possible to both determine the practical limits of reliable transmission and establish a reproducible methodology for future industrial communication systems in critical infrastructure scenarios [3,14,17,19,20,23,24,28,29,30].

3. Materials and Methods

The development of such a system requires practical verification: it is necessary to implement a prototype of a secure and autonomous LoRa network based on Raspberry Pi, followed by testing in conditions of real radio noise and lack of server infrastructure. The experiment was conducted in an urban environment with a high density of buildings and many sources of electromagnetic interference, which allows us to consider the results obtained as the lower limit of efficiency. With a similar hardware configuration in an open area without interference, the communication quality is likely to be higher.

The purpose of the experiment was to evaluate the stability of LoRa communication using Raspberry Pi 4 and the LoRa module E22-900T22S (UART interface) when transmitting data over various distances. Attention was focused on three applied metrics: Packet Delivery Ratio (PDR), Packet Error Ratio (PER), and Packet Loss Ratio (PLR).

The peculiarity of the equipment used—the lack of access to RSSI/SNR—predetermined the focus on packet analysis at the application level: delivered, damaged, and lost.

Also, as part of the experiment, a secure transmission scheme using symmetric encryption (AES-128) and integrity control (CRC-8) was implemented, which made it possible to simulate the real operating conditions of secure telemetry systems.

The hardware and software tools used in the experiment are presented in

Table 2. Hardware and software components.

Name	Characteristic
Controller	Raspberry Pi 4 Model B (4 GB RAM)
LoRa module	E22-900T22S (based on the LLCC68 chip), UART interface, and frequency range 868–915 MHz
Antenna	Omnidirectional, gain 5 dBi
Operating system	Raspberry Pi OS
Programming language	Python
Libraries used	Pyserial, Pycryptodome (AES-128, PKCS7, and CRC8)

.

The LoRa module was connected to the Raspberry Pi via the UART interface. Data exchange is implemented using proprietary Python scripts, without the use of specialized LoRa libraries. The transfer included data encryption (AES-128), adding a checksum (CRC-8), and the logging of transmitted and received packets in CSV format.

The data was transmitted manually, and the reception was performed automatically. All data was linked to a unique launch and distance identifier and stored for later analysis.

The experiment was conducted in an urban environment with partial buildings to assess the stability of communication in conditions of interference and signal shielding. The methodology included the following steps:

1.

Device initialization:

-

The receiver was started using ‘autostart_receiver.py’;

-

The transmitter was started manually by the operator, indicating the launch number and distance (‘sender.py’).

2.

Selection of measurement points:

-

The following fixed distances were used: 10 m, 50 m, 200 m, 500 m, 800 m, and 1100 m;

-

The distances were specified using GPS, if necessary.

3.

Data transmission:

-

250 packets were transmitted at each distance;

-

The interval between sending packets was 3 s;

-

Each packet contained a structured telemetry unit: [packet_id, timestamp, temperature, pressure, humidity, density, concentration, run_number, distance_m].

4.

Reception and processing:

-

The script ‘autostart_receiver.py’ automatically decrypted, verified, and saved received packets;

-

Corrupted or incomplete messages were discarded based on the CRC check.

5.

Collection and analysis—all data was manually sorted, combined into a pivot table, and analyzed using three metrics: PDR, PER, and PLR.

The total time of one run at each distance was about 15 min (900 s), providing a sufficient sample size for a statistically significant analysis.

Parameters of the transmission used for the experiment are presented in

Table 3. Data transmission parameters.

Parameter	Value
Transmission frequency	868 MHz
Transmission power	22 dBm (maximum allowable)
Interface	UART
Package Size	32 bytes (before encryption)
Interval between packets	3 s
Band width (BW)	125 kHz
Spreading factor (SF)	10

.

The choice of parameters provided a balance between the range and reliability of communication. The use of SF = 10 and a bandwidth of 125 kHz increased the sensitivity of the receiver and increased the probability of successful reception over long distances.

Figure 1 shows the operation scheme of the developed experimental data transmission system implemented on two Raspberry Pi 4s with connected LoRa modules E22-900T22S via UART.

The transmitting side (sender) generates telemetry data, encrypts them using AES-128, adds a CRC8 checksum, saves the data to the log, and transmits it via the LoRa module.

The receiving side (receiver) receives LoRa packets, decrypts and verifies their integrity, and saves the results to ‘.csv’ and ‘.log’ files.

Additionally, a mechanism for uploading results to an external computer via Wi-Fi (SCP protocol) using the script ‘download_data.py’ is implemented, started by the operator.

Raspberry Pi was chosen for data collection and further transmission because the platform allows you to create solutions on an open platform and apply Kafka data transfer protocols. This approach allows the use of Master Nodes, thus creating a distributed measurement network with centralized collection in a server where data processing and analysis are performed.

To quantify the quality of communication, three key metrics were used in the experiment, reflecting various aspects of data transfer success, which are presented below.

Packet Delivery Ratio (PDR, %)—the success rate of package delivery, which characterizes the proportion of correctly received and integrity-checked messages out of the total number of transmitted ones.

$$PDR={\displaystyle \frac{True\_packets}{Total\_packets}}\cdot 100\%$$

(1)

True_packets—number of received data packets (TRUE); Total_packets—number of data packets sent.

Packet Error Ratio (PER, %)—transmission error rate, which reflects the proportion of packets that were received but failed the CRC checksum check.

$$PER={\displaystyle \frac{False\_packets}{Total\_packets}}\cdot 100\%$$

(2)

False_packets—number of packets that failed verification (FALSE).

Packet Loss Ratio (PLR, %)—Packet Loss Ratio, which reflects the proportion of packets that were not received at all.

$$PLR={\displaystyle \frac{None\_packets}{Total\_packets}}\cdot 100\%$$

(3)

None_packets—number of packets that did not arrive (NONE).

To assess the statistical reliability of the results, a confidence interval for PDR with a 95% reliability level was also calculated. A z-coefficient of 1.96 was used (according to the standard normal distribution).

Formulas:

-

Confidence Interval Half-Width (CIHW, %):

$$CIHW=z\cdot \sqrt{{\displaystyle \frac{PDR\cdot (100-DPR)}{Total\_packets}}}$$

(4)

where CIHW—confidence interval half-width [%]; z—confidence coefficient.

-

Limit of the Confidence Interval (LL, %):

$$LL=PDR-CIHW$$

(5)

-

Upper Limit of the Confidence Interval (UL, %):

$$UL=PDR+CIHW$$

(6)

Demonstrated ratios help to quantify the efficiency of the suggested system.

4. Results

In order to ensure data transmission over long distances, a Raspberry Pi-based system has been developed, which primarily uses this microcontroller to collect data. Another microcontroller performs the function of a Master Node and transmits data via Kafka to a decentralized server for encryption, key storage, and decryption. Moreover, the main difference from existing solutions is the presence of Interplanetary file systems IPFS in the measurement system (Figure 2).

First of all, data from emission sensors are processed on Raspberry Pi. The collected values are transferred to the Raspberry Pi device, which acts as a peripheral computing node. Before sending, the data is processed in a TEE, where metadata is added (device ID, time); signing data with a private key is stored in isolation inside the TEE.

After local preparation, the data is sent to Apache Kafka via Kafka Producer. Kafka acts as an intermediate delivery and routing system, ensuring that messages are published to a dedicated topic (raw sensor data). These messages are then processed by subscription by individual system components, each of which implements specific business logic.

Messages received by Kafka are read by the first consumer (Consumer 1), whose task it is to initiate the verification of the validity and relevance of the data. The consumer accesses the DAG-blockchain node, which verifies the format and digital signature of the message; evaluates the validity of the transaction (for example, whether there is a duplicate); and returns the validation result

If successful, the message is forwarded to the second topic (validated data). In case of an error, it is logged or sent to a separate channel (rejected data).

The next consumer is subscribed to the validated data stream. It serializes data in JSON format; saves them to IPFS; and receives a CID, the content identifier by which this data is available in the distributed storage network. The CID, as well as the original metadata (for example, sensor id, timestamp) are transferred to a new Kafka topic (ipfs cid data), from where they can be used for further registration.

The health check demonstrated that the error when transmitting data over the embedded system varied by about 0%. An analysis of up to 1000 packets showed that the main bottleneck lies in the sequential execution of the DAG workflow, which leads to delays of an average of ~5 s for recording transactions and ~20 ms for confirmation.

The developed system will allow you to securely transfer data with the ability to track corrupted data. However, due to the fact that the data transmission system is located in a remote location from the possible location of the antennas, it is necessary to conduct tests at several different points.

Table 4. Summary of data packet reception results: received successfully, received with errors, and lost.

Distance [m]	Number of Data Packets Sent	TRUE	FALSE	NONE
10	250	249	1	0
50	250	250	0	0
200	250	197	1	52
500	250	208	23	19
800	250	95	0	155
1100	250	2	0	248

presents experimental data collected during the transmission of 250 packets over various distances.

The values of the PDR, PER, and PLR coefficients, as well as confidence intervals for PDR, were calculated based on the primary data (

Table 5. Values of metrics.

Distance, m	PDR, %	Confidence Coefficient (z)	CIHW	LL	UL	PER, %	PLR, %
10	99.60	1.9600	0.7824	98.8176	100.3824	0.4	0
50	100.00	1.9600	0.0000	100.0000	100.0000	0	0
200	78.80	1.9600	5.0666	73.7334	83.8666	0.4	20.8
500	83.20	1.9600	4.6345	78.5655	87.8345	9.2	7.6
800	38.00	1.9600	6.0169	31.9831	44.0169	0	62
1100	0.80	1.9600	1.1043	−0.3043	1.9043	0	99.2

).

The dependance of the Packet Delivery Ratio vs. Distance Graph (Figure 3).

The graph shows a sharp decrease in communication reliability with increasing distance ( Figure 3):

-

At 10–50 m—the PDR is close to 100% with minimal error;

-

From 200 m, there is a decrease in PDR to ~79% and an expansion of the confidence interval;

-

At 1100 m, the coefficient is practically reset (~0.8%).

The PER reaches a maximum (9.2%) at a distance of 500 m, when most of the packets are still being received but with distortion. At short (<50 m) and very long (800 m) distances, the PER tends to zero at short distances due to stable transmission and at long distances because most packets do not reach at all (Figure 4) (and are counted in the PLR) (Figure 5).

The PLR reflects the critical deterioration of radio communications (Figure 5):

-

Up to 50 m, no packet loss was observed (PLR = 0%);

-

At 200 m, the first significant losses appear (20.8%);

-

At 800 m, the PLR reaches 62%, and at 1100 m, it rises to 99.2%.

The dependance of the True_packets, False_packets, and None_packets from distance is shown in (Figure 6).

The diagram allows you to visually estimate the share of successfully delivered packages (TRUE), corrupted (FALSE), and lost (NONE) at every distance.

The situation at 1100 m is especially significant: out of 250 packages, only 2 were delivered successfully, the remaining 248 were lost. The database is available on GitHub (version 3.17.4) (Supplementary Materials).

Reliable communication with PDR is about 90% maintained at distances up to 200 m. The occurrence of channel errors (PER) begins after 200 m and peaks at 500 m. Beyond 800 m, transmission becomes unstable and of little use: losses reach critical values. The results confirm that this configuration (Raspberry Pi 4 + E22-900T22S) provides reliable communication only over medium distances in an urban environment.

In an open radio channel, the transmission of telemetry information without proper protection creates risks of interception, forgery, or distortion of data. To increase confidentiality and ensure the integrity of messages, the experiment implemented an application scheme for secure data transmission, including encryption and error control.

The symmetric AES-128 algorithm was used with ECB (Electronic Codebook) mode and PKCS7 padding in this prototype implementation due to its simplicity and minimal computational overhead. However, we acknowledge that the ECB mode is not secure for production use, as it does not provide semantic security or resistance against pattern-based attacks. In future implementations, authenticated encryption modes such as AES-CCM or AES-GCM will be adopted to ensure confidentiality and integrity simultaneously. Reasons for Selection:

-

Support in the ‘pycryptodome’ library for Python 3.11;

-

Acceptable performance (single packet processing time ~3 ms on Raspberry Pi 4);

-

Compliance with modern safety requirements.

The object of encryption is the full payload data block, excluding control symbols and protocol wrappers.

To detect and discard corrupted messages, a CRC-8 checksum was applied to each packet before encryption. The CRC was checked after decryption on the receiver side. Only the messages that were successfully verified were saved to the log and participated in the analysis (

Table 6. Data transmission security parameters.

Parameter	Value
Encryption algorithm	AES-128
Mode	ECB
Key length	128 bit
Integrity control	CRC-8
Additional load	~+16 bytes to the packet size
Package processing time	~3 ms
Key storage method	Fixed key in the script with the option to modify it if necessary

).

The encryption key was set manually in the script and stored on both devices. To increase security, a key exchange mechanism can be implemented in the future, for example, using the Diffie–Hellman protocol with protection against man-in-the-middle (MITM) attacks.

While the current implementation demonstrates the feasibility of secure transmission in constrained environments, the cryptographic layer is simplified. Specifically, the use of AES-128 in ECB mode is not recommended for real-world applications due to its deterministic nature and vulnerability to ciphertext pattern analysis.

For real deployments, future versions of the system will implement

-

AES-CCM or ChaCha20-Poly1305 for authenticated encryption (AEAD);

-

Per-message IVs (initialization vectors) to prevent replay and pattern reuse;

-

Lightweight key exchange (e.g., X25519) or pre-shared key rotation schemes;

-

Integration of nonce/timestamp counters to protect against replay attacks;

-

Consideration of MITM/jamming resilience through packet-level metadata and randomized transmission delays.

To verify the stability and reliability of the proposed architecture in long-term operation, a 24 h experiment with continuous data transmission was conducted. During the test, the same hardware configuration was used (Raspberry Pi 4 + E22-900T22S), while the data was recorded using the same metrics—PDR, PER, and PLR. In total, the number of data packets sent was 2876, the number of received data packets (TRUE) was 2804, the number of packets that failed verification (FALSE) was 70, the number of packets that did not arrive (NONE) was 2, the PDR was 97.5%, the PER was 2.43%, and the PLR was 0.07%.

Figure 6 and Figure 7 show the corresponding diagrams: the absolute distribution of packets by status (TRUE, FALSE, and NONE) and the percentage of transmission metrics.

The diagram shows the final statistics of the 24 h experiment in which 2876 telemetry packets were transmitted. Of these, 2804 (over 97%) were successfully accepted and passed the Integrity Check (CRC). Only 70 packets (≈2.4%) were damaged during reception, and only 2 packets were not delivered at all, which indicates the high reliability of the radio channel even under prolonged load. Also, these data are indicated in the form of variables PDR, PER, PLR in Figure 8.

These results confirm the stable operation of the system and the effectiveness of the implemented protection scheme.

The diagram shows the key metrics that characterize the reliability of the system in a long-term test. The package delivery success rate (PDR) has reached an impressive 97.5%, which corresponds to the level of industrial systems. Transmission errors (PER) amounted to only 2.43%, and the level of total packet loss (PLR) turned out to be almost zero—0.07%. These values demonstrate that the proposed architecture remains stable during continuous operation, confirming its suitability for long-term autonomous monitoring. The database is available on GitHub (Supplementary Materials)

To evaluate energy efficiency, the current consumption was measured at different stages of device operation:

-

Rest (static standby): ~500 mA;

-

Packet transmission: +150 mA spike during packet formation and transmission;

-

Packet reception: +40–50 mA short term.

Decryption and storage: Additional CPU load accompanied by noticeable processing time (within the Python script autostart_receiver.py).

The obtained values confirm that the most energy-intensive phase is the preparation and sending of the packet, while receiving and decrypting is less energy-intensive but takes more time on the CPU.

This section may be divided by subheadings. It should provide a concise and precise description of the experimental results, their interpretation, as well as the experimental conclusions that can be drawn.

Summary of Results: The conducted experiments demonstrated that the proposed Raspberry Pi + LoRa telemetry architecture ensures stable wireless communication in an urban environment with significant interference. Data integrity was confirmed across distances up to 1100 m, with acceptable values of PDR, PER, and PLR. A continuous 24 h test validated the system’s reliability against noise and interruptions. These findings confirm the feasibility of deploying the architecture in isolated industrial and ecological monitoring scenarios where GSM connectivity is unavailable.

5. Discussion

In the scope of the research conducted for ecological monitoring, the transmission system should be suitable for long distances. Raspberry Pi demonstrated the capability to send and receive information from remote stationary emission sources. First of all, the application of the chosen controller is very suitable, as it is based on open-source architecture. The changes in software or hardware will be easier and faster than with the proprietary solution. Secondly, the application of Raspberry Pi allows for the application of blockchain technology for data encryption. Overall, the results demonstrated that applied applications in emission monitoring are possible with consideration of the distance of the sensors’ location.

The use of Raspberry Pi microprocessors to transmit data over a radio channel in remote and hard-to-reach places where there is no cellular connection is a promising area in the field of environmental monitoring. These devices have a number of advantages that make them ideal for such tasks.

Firstly, Raspberry Pi is compact and energy efficient, which allows them to be used in autonomous systems powered by batteries or solar panels. This is especially important in environments where access to external power sources is limited.

Secondly, Raspberry Pi has a wide range of features for integration with various sensors and devices, which allows you to create multifunctional monitoring systems. For example, they can be used to collect data on air quality, water, soil, noise level, temperature, and other environmental parameters.

Thirdly, Raspberry Pi supports various communication protocols, including radio channels, which provides flexibility in choosing the data transmission method. This is especially important for working in environments where cellular communication is unavailable.

However, using Raspberry Pi in such conditions also involves a number of challenges. One of the main ones is the need to ensure reliable and stable communication between devices. Radio channels can be subject to interference and signal attenuation, especially in conditions of difficult terrain or dense vegetation. Various methods can be used to solve this problem, such as choosing the optimal frequency range and using signal amplifiers and high-gain antennas.

In addition, data security issues must be taken into account when transmitting them over the radio channel. In conditions of remote monitoring, it is important to ensure protection against unauthorized access and the interception of information. This can be achieved by encrypting data and using reliable authentication protocols.

It is also worth noting that the development and implementation of such systems require careful planning and testing. It is necessary to take into account the specifics of the specific area, select suitable sensors and equipment, and perform regular checks and calibrations of the system.

In conclusion, the use of Raspberry Pi microprocessors for environmental monitoring in remote and hard-to-reach locations is a promising area. However, for the successful application of such systems, it is necessary to take into account a number of factors related to communication reliability, data security, and terrain features.

The conducted research has an applied focus and is focused on the verification of telemetric architecture in an urban radio environment with high noise. Despite the positive results and proven communication stability, the implemented system has a number of limitations that should be taken into account when scaling and adapting to other scenarios.

Key limitations include

-

Using one type of LoRa module (E22-900T22S with UART interface) that does not provide information about the channel layer parameters (RSSI, SNR);

-

The lack of testing under conditions of full energy autonomy, which is critical for isolated and field deployment scenarios;

-

Current cryptographic implementation (AES-ECB) is not suitable for production environments and will be replaced with authenticated encryption (e.g., AES-CCM) in future revisions;

-

The centralized nature of data storage, in which the loss of a recording device (for example, a laptop) leads to a complete loss of collected telemetry readings;

-

Limited communication length (up to 1100 m) without the use of intermediate nodes or repeaters, which reduces the scalability of the system in linear and distributed topologies.

In order to overcome these limitations in the further stages of work, the following is planned:

-

Conducting field tests in rural and industrial environments with less radio interference.

-

Although the current LoRa module (E22-900T22S) is based on the SX1276 chip, it operates via a UART interface and does not expose SPI-level access to registers such as RSSI and SNR. Communication with the manufacturer confirmed that the firmware does not allow bypassing these limitations. In future work, we plan to migrate to fully accessible SPI-based transceivers (e.g., raw SX1276 boards) that enable low-level signal quality monitoring. This will allow the system to implement in-band spectrum scanning and dynamic channel switching when signal degradation is detected, improving robustness in highly variable environments.

-

Implementation of self-powered systems (including those based on batteries and solar panels) and their testing in conditions of complete isolation from the external infrastructure.

-

Integration of the architecture with industrial SCADA platforms, edge analytics, and MQTT protocols to assess scalability and adaptability in real-world production scenarios.

-

Implementing an Adaptive Data Rate (ADR) algorithm that dynamically adjusts the spreading factor (SF 7–12) and bandwidth (125/250 kHz) based on real-time transmission quality metrics such as PDR and PER. This will allow the system to maximize range and robustness while minimizing airtime and energy consumption under varying interference conditions. Such adaptation is especially critical for deployments in heterogeneous environments and will improve communication efficiency without requiring hardware changes.

-

Integration of the DAG blockchain as the distributed secure storage of telemetry data with a subsequent fixation of transmitted readings; this approach allows for information immutability, fault tolerance in case of loss of a separate storage device, and independence from centralized servers, as shown in Figure 9.

-

Replacing the current AES-ECB cryptographic scheme with a modern authenticated encryption algorithm such as AES-GCM or ChaCha20-Poly1305. These algorithms provide both confidentiality and integrity, eliminate pattern leakage through per-message IVs or nonces, and offer protection against replay attacks. We also intend to implement a secure session key negotiation using ephemeral Diffie–Hellman (e.g., Curve25519) and periodic key rotation mechanisms, potentially integrated with the DAG-based blockchain layer to enhance long-term security and trust management in the system.

-

To overcome range limitations observed during field testing (e.g., increased packet loss at 1100 m), we plan to implement a lightweight multi-hop mesh protocol over raw LoRa. The mesh layer will support up to three hops using distance–vector routing principles, allowing nodes to relay messages when direct communication fails. To maintain energy efficiency, we intend to incorporate CAD-based (Channel Activity Detection) wake-up mechanisms that activate relay nodes only when necessary. This approach would enable scalable and low-power data delivery in extended and sparse topologies without the need for deploying additional fixed gateways.

-

Enhancing cryptographic resilience through the implementation of ephemeral key exchange mechanisms using Curve25519-based Diffie–Hellman over the air, allowing each telemetry session to operate under a unique encryption context. We also aim to explore the use of ARM TrustZone-based Trusted Execution Environments (TEE) on Raspberry Pi to securely store long-term cryptographic keys outside of the user space. Furthermore, we consider the integration of DAG-based blockchain infrastructure not only for storing telemetry data, but also as a decentralized mechanism for managing session key rotation. This combined approach is intended to prevent long-term key compromise and support scalable, autonomous deployments in untrusted environments.

-

In the current prototype, the LoRa module was intentionally kept in active mode to maintain timing accuracy and ensure the correct operation of the telemetry scripts. However, in future revisions, we plan to enable the module’s deep sleep mode (≤2 µA) during idle periods to significantly reduce power consumption. Alongside this, we intend to extend the packet transmission interval to 30 s, apply CBOR-based compression to minimize payload size, and integrate an MPPT (Maximum Power Point Tracking) solar charging system paired with a super-capacitor energy buffer. These measures will make the system suitable for fully off-grid and energy-autonomous deployments.

Recent advances in edge computing further highlight the relevance of the proposed architecture. LoRa technology has already demonstrated a strong potential in remote sensing and agriculture-oriented IoT scenarios, where coverage limitations and energy efficiency are decisive factors [31]. At the same time, Raspberry Pi has been actively used as a lightweight edge computing platform, enabling local data processing and reducing dependency on centralized cloud infrastructures [32]. Our findings on secure telemetry transmission complement these approaches by validating that even under high urban radio interference, Raspberry Pi and LoRa can provide reliable and autonomous communication. Moreover, the integration of such systems with advanced computation offloading and task scheduling mechanisms—such as priority-aware models based on deep reinforcement learning—can open promising directions for enhancing the scalability, security, and adaptability of IIoT monitoring solutions [33].

Based on the proposed architecture, it will be possible to transfer data with fast encryption and decryption. The system will allow the use of a distributed blockchain system, which will reduce the transaction transfer time, ensuring security during data transfer.

6. Conclusions

This research developed and experimentally validated a secure, autonomous telemetry transmission architecture based on Raspberry Pi and LoRa technology, designed for Industrial Internet of Things (IIoT) applications in environments lacking GSM or server infrastructure. The system employs lightweight AES-128 encryption (in ECB mode, with planned upgrades to AES-CCM) and CRC-8 integrity checking to ensure secure and reliable data transmission in open radio channels.

Field tests in an urban environment with high electromagnetic interference, as detailed in Section 3, demonstrated

-

High reliability at short distances, achieving a Packet Delivery Ratio (PDR) of 99.6% at 10–50 m (Table 5), suitable for compact industrial setups;

-

Acceptable performance up to 500 m, with a Packet Error Ratio (PER) of ≤9.2% and Packet Loss Ratio (PLR) of ≤20.8% (Table 5), confirming robustness in noisy conditions;

-

Critical performance degradation beyond 800 m, with PLR reaching 99.2% at 1100 m (Figure 5), indicating range limitations in urban settings.

A 24 h continuous operation test, presented in Figure 8, confirmed the system’s long-term stability, achieving a PDR of 97.5%, PER of 2.43%, and PLR of 0.07%. These metrics validate the architecture’s suitability for sustained IIoT monitoring tasks under real-world conditions.

Energy consumption measurements, detailed in Section 3, revealed the peak current draw during packet transmission (~650 mA), with a lower consumption during reception and decryption (~540–550 mA). This energy profile supports deployment in resource-constrained environments, such as battery-powered remote monitoring systems.

This work demonstrates the practical feasibility of an autonomous, secure, and energy-efficient LoRa-based telemetry system, validated through real-world testing. The architecture’s applicability is evidenced by its high reliability (PDR > 99% at short ranges), long-term stability (97.5% PDR over 24 h), and low power consumption, making it ideal for IIoT applications in remote or infrastructure-limited settings, such as emission monitoring, mining, and agriculture. The open-source design, leveraging Raspberry Pi’s flexibility, ensures reproducibility and scalability. Future enhancements will include adopting AES-CCM for enhanced security, integrating a DAG-based blockchain for distributed data storage (Figure 9), and conducting tests in rural environments to extend the communication range.