Time Management in Wireless Sensor Networks for Industrial Process Control

Abstract

This paper addresses the critical challenge of time management in wireless sensor networks (WSNs) applied to industrial process control. Although wireless technologies have gained ground in industrial monitoring, their adoption in control applications remains limited due to concerns around reliability and timing accuracy. This study proposes a practical, low-cost solution based on commercial off-the-shelf (COTS) components, leveraging the IEEE 802.15.4-2020 standard in Time-Slotted Channel-Hopping (TSCH) mode. A custom time management algorithm is developed and implemented on STM32 microcontrollers paired with AT86RF212B transceivers. The proposed system ensures a sub-millisecond synchronization drift across nodes by dividing communication into a structured slot frame and implementing precise scheduling and enhanced beacon-based synchronization. Validation is performed through experimental setups monitored with logic analyzers, demonstrating a time drift consistently below 600 microseconds. The results confirm the feasibility of using synchronized wireless nodes for real-time industrial control tasks, suggesting that further improvements in hardware precision could enable even tighter synchronization and broader applicability in fast and critical processes.

1. Introduction

Wireless communication is one of the emerging technologies that have been aggressively adopted in the last decade, and which allows us to transfer huge amounts of data, faster and over much greater distances in real time. Almost every device on the market incorporates at least one piece of wireless technology, whether we are talking about Wi-Fi, Bluetooth, or others. Moreover, cost optimization and the emergence of new technologies meant the availability of smart and cheap devices known as the Internet of Things or the Industrial Internet of Things for industry. The industrial community has been more reluctant to adopt wireless technologies, especially in process control [1]. Wireless technology is seen as unstable and unpredictable for data transfers in an industrial process as it brings additional communication latencies [2]. In the past two decades, this has gone through a major change with the emergence of the IEEE 802.15.4 standard [3] and its amendments, that allow the secure and efficient transfer of data in an environment where this is highly critical, such as in an industrial environment [4]. This standard has led to the development of wireless communication protocols like ISA100 Wireless (mostly adopted in the USA) [5] and WirelessHART (mostly adopted in Europe) [6] which mainly allow the monitoring of industrial processes. Industrial process control, although mentioned in the technical specifications of these two protocols, refers to the transmission over wireless of the setpoint rather than the command. In Figure 1, we have explained the evolution of using wireless communication in process control starting from a classic control loop (a), current implementations described in recent papers (b), and our proposal (c).

Our proposal is not new, as there have been previous attempts to use wireless communication in process control by using those protocols designed to be used in industrial applications. In [7], the authors have used WirelessHART to transmit the feedback from the process to the controller and observed that the wireless device connected to the process sends this feedback randomly, causing system instability. They proposed using a Kalman filter to reduce noise and a stat estimator to estimate the process output when it is not available. By adding these improvements, the differences between a classic wired control loop and a wireless one are minor. A similar approach to what we propose has been described in [8], where the authors have used WirelessHART to transmit the command to the process and the feedback to the controller using wireless communication. In this study, the wireless node connected to the process sends the feedback to the controller once every 15 s, where the controller has a 1 s sampling time. The authors address two possible solutions to solve this problem: use the last received measurement in the control computation or employ a state estimator that calculates the measurement when it is not updated over the wireless network. The results show that the control system stabilizes at different setpoint values when the measurement is unavailable. Furthermore, the authors conclude that the WirelessHART protocol is not recommended for fast process control, as it has data transmission periods in the order of seconds. The use of state estimators and the last received command ensures system stability in situations where the measurement is not received and/or the wireless network is inactive. Our proposal is to include control loop capabilities directly into the underlying IEEE 802.15.4-2020 standard, as including this in the application layers of wireless protocols means additional processing overhead in the data frames. This will allow the control of fast processes over wireless, not just slow ones, as presented in the literature.

Two case studies immediately benefit from this new concept: an industrial process in which the controller and process are at a significant distance from each other, and inside a satellite where one of the methods of reducing production costs and sending it into space is to reduce the number of wires between the equipment. Replacing wired control with wireless is not an easy task, considering the industrial process requirements that need to be followed. One of the most important and critical of these requirements is the management of wireless network time, which is the focus of this article.

Wireless sensor networks (WSNs) have been extensively studied for industrial applications, with a growing focus on synchronization and energy efficiency. Ref. [9] provided early insights into the requirements for control-oriented WSNs, highlighting reliability and timing as key barriers to broader adoption. Recent surveys and implementations have reinforced these priorities. For instance, Aponte-Luis et al. [10] showed how IEEE 802.15.4 can support robust industrial monitoring, while Phan and Kim [11] proposed hybrid synchronization schemes scalable to large sensor fields. Moreover, Liu et al. [12] explored architectural trade-offs in synchronization algorithms, including distributed and hybrid approaches, which informed the design choices behind our low-drift, COTS-compatible system.

This article follows a more pragmatic and practical approach by using COTS components and development boards to simulate a time-synchronized control loop between two wireless nodes, with one being the controller and the other being the process. The starting point was the implementation of the IEEE 802.15.4-2020 standard in Time-Slotted Channel-Hopping (TSCH) mode which we slightly extended to allow the proper time management of the wireless control network. Promising results have been obtained that point out what is still needed to achieve better time management and allow control over wireless for even faster and more critical processes.

The remainder of this article is structured as follows: Section 2 describes the research starting points—the IEEE 802.15.4-2020 standard, the hardware setup, and the development environment. Section 3 presents the obtained results which include the development of a hardware abstraction later to separate the physical layer from the upper layer in the software implementation, the developed transceiver driver, the time management algorithm, and the testing and validation of our proposed solution. Section 4 discusses the results obtained compared to existing work and future improvements and Section 5 concludes this article with a brief conclusion and future work directions.

2. Materials and Methods

This section describes the hardware, software, and protocol-level elements used to implement and validate a custom time management algorithm for industrial wireless sensor networks (IWSNs). The system architecture is based on COTS STM32 microcontrollers from STMicroelectronics, Geneva, Switzerland and AT86RF212B transceivers from Microchip, Chandler, AZ, USA, configured to operate in IEEE 802.15.4 TSCH mode. A slot frame structure with 10-millisecond timeslots was designed, allowing synchronized communication between wireless nodes using enhanced beacon frames for time alignment. Hardware-level time tracking was implemented using external 32.768 kHz crystals with ±20-ppm tolerance. Development and debugging were conducted in STM32CubeIDE, using CMSIS-compliant C code and a custom hardware abstraction layer (HAL) for microcontroller and transceiver control. System validation was performed with a logic analyzer, the Saleae Logic 8 from Saleae, San Francisco, CA, USA, to measure synchronization drift, confirming sub-millisecond accuracy. The hardware components and the development boards were acquired from Farnell and shipped from within the EU. The logic analyzer was acquired directly from the manufacturer’s website and shipped from the US.

2.1. IEEE 802.15.4

The use of wireless communication in industrial process control is a novelty as most communication protocols in the industrial field are used only for process monitoring: reading the process parameters and sending them to a central unit for display and analysis. Both WirelessHART and ISA100 Wireless rely on time management for the proper operation of the wireless network. As they implement only the physical layer from the IEEE 802.15.4 standard and rely on proprietary implementations of the upper layers, they define their own time management algorithms. Having this in mind, we had to refer to IEEE 802.15.4 as a starting point in the definition and implementation of a simple and reliable time management algorithm.

Since its first release back in 2003, the IEEE 802.15.4 standard has been continuously amended, adding new modulations, operating frequencies, data rates, and application layer features. The standard defines multiple operating modes from which TSCH is the most appropriate for wireless process control as it implies accurate time synchronization between the wireless nodes associated to a network. The concept is simple: it divides time into a sequence of timeslots of fixed intervals that the nodes must follow. Each timeslot allows for one transmission—a command or data frame and one reception—an acknowledgement, sent and received by following strict timeslot templates. It is expected that the sequence of timeslots will repeat after a certain amount of time, allowing for the predictability of the wireless network behavior. This repeating sequence of timeslots is called a slot frame.

Our approach is to use the standard frames as they are defined by IEEE 802.15.4 (beacon, command, data, and acknowledgement) and make use of the available payload fields in the extended beacon and acknowledgement frames to send additional data between the nodes. TSCH will be used as the operating mode with a standard slot frame structure used for node management, but also for process control.

By examining the standard IEEE 802.15.4 frame structure for O-QPSK modulation, as illustrated in

Table 1. The default IEEE 802.15.4 frame structure and duration.

	Length (bytes)	Value	Duration (µs)
Preamble	4	0 × 00000000	128
Start Frame Delimiter (SFD)	1	0xA7	32
Physical Layer Header (PHR)	1	0x00 ÷ 0x7F	32
PHY Payload	127	various	32 ÷ 4064

alongside the airtime for each field, and data rate (250 kbps) intended for use, we have determined that a timeslot duration of 10 milliseconds will be appropriate as it allows us to send and then receive two frames that have the maximum allowable length of 127 bytes, which together with the Preamble, SFD, and PHR total up to a maximum of 4.256 milliseconds of airtime per frame. As the acknowledgement frame, which is sent as a reply to a command or data frame, usually has its length at much less than 127 bytes, the timeslot time of 10 milliseconds is more than enough to handle the communication between the two nodes.

To simplify the implementation of the algorithm, for testing and validation, we have decided to use the simplest network topology defined by IEEE 802.15.4, the star topology. In this topology, displayed below in Figure 2, the coordinator (C) is the central device and manages the wireless network, starting a network, responding to association requests from devices (D), and starting control loops. The network is designed in such a way that a control loop can be started between any two devices associated to the network. Proper time management is handled by the coordinator and time synchronization between the coordinator and the devices is needed to achieve this. Complex topologies like mesh would require an additional line of research to define a proper time management algorithm.

2.2. Hardware

We have selected several NUCLEO boards manufactured by STMicroelectronics (Geneva, Switzerland) built around the STM32L4 family of microcontrollers [13], and the ATZB-212B-XPRO extension board from Microchip (Chandler, United States), built around the AT86RF212B transceiver, to implement and validate time management in the wireless network. These components are well known for the abundance of features they provide alongside their ease of operation and low power consumption. The wireless node acting as the master clock or the time source is comprised of a pair of development boards: the NUCLEO-L432KC coupled to the ATZB-212B-XPRO, which runs the implementation of the physical and data link layers, and the NUCLEO-L476RG, which runs the application layer as defined by IEEE 802.15.4. The two wireless nodes, which will be part of the control loop, are comprised of the NUCLEO-L152RE development board coupled to an ATZB-212B-XPRO extension to maintain consistency. In terms of time keeping, the NUCLEO-L432KC features a 32,768 Hz crystal from NDK (Saitama, Japan), part no. NX3215SA-32.768K-STD-MUA-14, with a 20-ppm frequency tolerance, and the NUCLEO-L152RE features a 32,768 Hz crystal from Abracon (Austin, TX, USA), part no. ABS25-32.768KHZ-6-T, with the same 20-ppm frequency tolerance. Each development board is connected to the PC using USB cables that provide power to the board, and also a virtual serial (COM) port to log messages placed throughout the code, verify that it performs as expected, and signal the user when the application reaches a certain state.

A Logic 8 logic analyzer from Saleae (San Francisco, United States) [14] was used to monitor microcontroller pins used for debugging. We have used two pins on each board to generate a pulse when the group of timeslots starts and when a single timeslot starts. We could, therefore, measure the time drift between two wireless nodes.

2.3. Development Environment

All development has been carried out in C by using the default development environment from STMicroelectronics, the latest version of STM32CubeIDE [15], which at the time writing this article was 1.18.1. The projects were created as blanks to which we added the header and startup files for the microcontrollers provided by the manufacturer and which follow the Common Microcontroller Software Interface Standard (CMSIS) [16]. The code is stored in a private GitLab instance, serving as a version control system to keep track of all code changes. Live debugging has been completed using the development boards’ built-in ST-Link debuggers to validate the implementation.

3. Results

3.1. Hardware Abstraction Layer

Optimizing the code execution time and having consistency in this execution requires quick and easy access to the microcontroller’s registers. To do his, we have skipped using the open-source libraries available from the manufacturer (i.e., STM32Cube MCU Packages) and developed a hardware abstraction layer (HAL) to access the most common microcontroller modules like the clock system, the GPIOs, the timers, the communication interfaces, the flash, and ADCs and DACs. The HAL defines standard function headers with the implementation varying from one microcontroller to another and allows for easy code porting to another hardware platform if needed. The application layer calls these standard functions to configure and use the physical layer of the microcontroller.

The HAL uses the device descriptions to access the microcontroller registers that follow the Common Microcontroller Software Interface Standard (CMSIS) which is an Arm-maintained, vendor-independent software framework that standardizes how the code, tools, and device descriptions interact with Arm Cortex-based microcontrollers. The goal is to let the user focus on the application instead of relearning low-level details for every new microcontroller. Each module has its registered part of a structure, such as the one given below, for example, the GPIO module. CMSIS defines all microcontroller registers as volatile and uses the standard C99 data types for interoperability.

typedef struct
{
__IO uint32_t MODER;	/*!< GPIO port mode register,	Address offset: 0x00   */
__IO uint32_t OTYPER;	/*!< GPIO port output type register,	Address offset: 0x04   */
__IO uint32_t OSPEEDR;	/*!< GPIO port output speed register,	Address offset: 0x08   */
__IO uint32_t PUPDR;	/*!< GPIO port pull-up/pull-down register,	Address offset: 0x0C   */
__IO uint32_t IDR;	/*!< GPIO port input data register,	Address offset: 0x10   */
__IO uint32_t ODR;	/*!< GPIO port output data register,	Address offset: 0x14   */
__IO uint32_t BSRR;	/*!< GPIO port bit set/reset register,	Address offset: 0x18   */
__IO uint32_t LCKR;	/*!< GPIO port configuration lock register,	Address offset: 0x1C   */
__IO uint32_t AFR[2];	/*!< GPIO alternate function registers,	Address offset: 0x20-0x24 */
__IO uint32_t BRR;	/*!< GPIO Bit Reset register,	Address offset: 0x28   */
__IO uint32_t ASCR;	/*!< GPIO analog switch control register,	Address offset: 0x2C   */
} GPIO_TypeDef;

Each microcontroller module is then defined as a pointer to a structure that points to the module’s fixed RAM address, for example, the first GPIO module named GPIOA: #define GPIOA ((GPIO_TypeDef *) GPIOA_BASE), with GPIOA_BASE being defined as the base address for the module. Using this structure, we have defined functions to configure and access the functionality of each module. The example given below sets the state for a microcontroller pin, given as the function parameters (port and pin) controlled by a GPIO module and uses the same standard data types as the ones used by CMSIS. The code also follows the MISRA C [17] coding guidelines to make safety- and security-critical embedded software safe, secure, portable, and reliable, and is annotated according to Doxygen [18] which can be used to automatically generate code documentation.

/**************************************************************************************************

* @author    Andrei Rusu

* @brief    GPIO port/pin write

* @param[in] p_ucModule - the GPIO module (e.g., HAL_GPIO_0)

* @param[in] p_ucPin - the GPIO pin (e.g., HAL_GPIO_PIN_0)

* @param[in] p_ucState - the GPIO state (e.g., HAL_GPIO_LOW)

* @remarks

**************************************************************************************************/

void HAL_GPIO_Write(uint8_t p_ucModule, uint8_t p_ucPin, uint8_t p_ucState)

{

switch (p_ucState)

{

case HAL_GPIO_LOW:

{

g_apstHAL_GPIO[p_ucModule]->BSRR = (uint32_t) (1 << (p_ucPin) << 16);

break;

}

case HAL_GPIO_HIGH:

{

g_apstHAL_GPIO[p_ucModule]->BSRR = (uint32_t) (1 << p_ucPin);

break;

}

case HAL_GPIO_TOGGLE:

{

g_apstHAL_GPIO[p_ucModule]->ODR ^= (uint32_t) (1 << p_ucPin);

break;

}

case HAL_GPIO_PULSE:

{

g_apstHAL_GPIO[p_ucModule]->ODR ^= (uint32_t) (1 << p_ucPin);

g_apstHAL_GPIO[p_ucModule]->ODR ^= (uint32_t) (1 << p_ucPin);

break;

}

default: break;

}

}

CMSIS also uses a standard way to define the registered bits. This is also adopted in the device definition files available from the manufacturer. As an example, we have listed below a section of the bit definitions for the GPIO_MODER register.

/****************** Bits definition for GPIO_MODER register *****************/

#define GPIO_MODER_MODE0_Pos (0U)

#define GPIO_MODER_MODE0_Msk (0x3UL << GPIO_MODER_MODE0_Pos) /*!< 0x00000003 */

#define GPIO_MODER_MODE0 GPIO_MODER_MODE0_Msk

#define GPIO_MODER_MODE0_0 (0x1UL << GPIO_MODER_MODE0_Pos)    /*!< 0x00000001 */

#define GPIO_MODER_MODE0_1 (0x2UL << GPIO_MODER_MODE0_Pos)    /*!< 0x00000002 */

The HAL can be made available as source and header files or can be packed in a binary library for easy maintenance and to give the user access just to the header files to call the functions. As a library, it can be easily used in new projects simplifying the overall project structure. We have also defined an intermediate layer between the physical and application layers to configure the microcontroller modules and populate the module interrupt callback functions, which avoids adding application layer code in the HAL files. The code used to test the time management algorithm described in this paper alongside the HAL is available as an open source on Github [19].

3.2. Transceiver Driver

To maintain consistency throughout the software project in terms of register access, we have followed the CMSIS guidelines also for the transceiver driver. This meant putting in place the bit definitions for each transceiver register, like the ones available for the microcontroller. As an example, we have listed below a part of the bit definitions for the TRX_CTRL_0 register defining the clock rate for the CLKM pin.

/****************** Address definition for TRX_CTRL_0 register *******************/
#define TRX_CTRL_0 0x03
/****************** Bit definition for TRX_CTRL_0 register *******************/
#define TRX_CTRL_0_CLKM_CTRL_Pos	(0U)
#define TRX_CTRL_0_CLKM_CTRL_Msk	(0x7UL << TRX_CTRL_0_IRQ_POLARITY_Pos)
#define TRX_CTRL_0_CLKM_CTRL	TRX_CTRL_0_IRQ_POLARITY_Msk
#define TRX_CTRL_0_CLKM_CTRL_NO_CLOCK	(0x0UL << TRX_CTRL_0_IRQ_POLARITY_Pos)
#define TRX_CTRL_0_CLKM_CTRL_1MHz	(0x1UL << TRX_CTRL_0_IRQ_POLARITY_Pos)
#define TRX_CTRL_0_CLKM_CTRL_2MHz	(0x2UL << TRX_CTRL_0_IRQ_POLARITY_Pos)
#define TRX_CTRL_0_CLKM_CTRL_4MHz	(0x3UL << TRX_CTRL_0_IRQ_POLARITY_Pos)
#define TRX_CTRL_0_CLKM_CTRL_8MHz	(0x4UL << TRX_CTRL_0_IRQ_POLARITY_Pos)
#define TRX_CTRL_0_CLKM_CTRL_16MHz	(0x5UL << TRX_CTRL_0_IRQ_POLARITY_Pos)
#define TRX_CTRL_0_CLKM_CTRL_250kHz	(0x6UL << TRX_CTRL_0_IRQ_POLARITY_Pos)
#define TRX_CTRL_0_CLKM_CTRL_IEEE_802_15_4	(0x7UL << TRX_CTRL_0_IRQ_POLARITY_Pos)

Functions were then defined and implemented to access the transceiver’s features like reading and writing registers, reading frames from and writing frames to the internal FIFO, setting the transceiver in different states (idle, transmission, and reception) and using the internal AES module to encrypt data.

3.3. Division of Time

The overall aim of the time management algorithm is to achieve a sub-millisecond time drift between any two nodes associated to the wireless network. Why is this needed? If we look at a classic control loop, sending a delayed command will cause instability in the controlled process, especially in fast ones. Furthermore, keeping this time drift is in line with the timeslot template defined by IEEE 802.15.4 when using the TSCH operating mode. Considering the COTS development boards used in this experiment and the ±20-ppm frequency drift on-board crystals, we have fixed the slot frame at 6000 timeslots of 10 milliseconds each leading to a 1 min long slot frame. This will lead to a theoretical maximum time drift of less than 40-ppm × 6000 slots = 2.4 milliseconds per slot frame, assuming one oscillator drifts forward and the other backward. To achieve a sub-millisecond drift between any two nodes, we have concluded to divide the slot frame into groups of 50 timeslots, as shown in Figure 3.

The first timeslot in the group of 50, or timeslot 0 marked with A, is an advertisement timeslot. During this timeslot, the network coordinator (the clock source) sends a beacon frame over the wireless network to notify other wireless devices of the network’s presence. The beacon frame also includes information about the exact time when the coordinator transmitted the frame. Odd timeslots are control timeslots, marked with C, used in control loops to transmit data frames containing commands and process output measurements. Even timeslots are management timeslots, marked with M, used by the coordinator to pass settings to wireless devices, as well as by wireless devices to pass data to the coordinator. Shared timeslots, marked with S, are used by all wireless nodes participating in the network to transmit frames when they do not yet have assigned timeslots. These timeslots are used in procedures such as associating a wireless device with the network, where the last step is to allocate dedicated timeslots. The 25th timeslot in the group of 50 will always be the shared timeslot. In a slot frame, there are 120 advertisement timeslots, 2760 management timeslots, 3000 control timeslots, and 120 shared timeslots.

We have chosen to send an enhanced beacon frame, as defined by IEEE 802.15.4, during the advertisement timeslot as it allows the insertion of the user payload. This 5-byte payload contains information related to the current network coordinator time: the UTC time in seconds and the time fraction—the timeslot group number, from 0 to 119. As the enhanced beacon frame is being sent during the advertisement timeslot at the moment specified in the timeslot template, a device joining or joined to the network knows the precise absolute time at which the enhanced beacon frame was sent.

Any device sending frames over the wireless network will follow the TSCH CCA operating mode of IEEE 802.15.4-2020 combined with the proposed slotframe structure, as shown in Figure 4. An associated device will use its dedicated timeslots to communicate with the coordinator, while shared timeslots are used by non-associated devices during the association process.

3.4. Time Synchronization

The IEEE 802.15.4 standard defines a timing template (macTimeslotTemplate) that must be followed by every transmission and reception over wireless. Figure 5 illustrates a two-way communication between two wireless devices, the first being the initiator of the communication.

A timeslot is defined as the interval between T₀ and T₉, with a standard duration of 10 milliseconds. Assuming both devices are time-synchronized, according to the transmission template, the actual data frame transmission commences at T₂, which, as per the standard, is exactly 2120 microseconds from the start of the timeslot (T₂ − T₀). To ensure a correct reception, the second wireless device will enter the reception mode earlier, specifically at T₁, which is exactly 1020 microseconds from the beginning of the timeslot (T₁ − T₀). The device will then be in reception mode between T₁ and T₃, waiting for a transmission to begin. This interval is fixed at 2200 microseconds. If no transmission begins in this interval, the receiving device will enter the idle mode. T₄ signals the completion of the data frame’s transmission/reception if a transmission begins in the T₃ → T₁ interval. Subsequently, the receiving device will send an acknowledgment frame to the transmitting device exactly after T₆ − T₄, which is set at 1000 microseconds. The first device will enter the reception mode at T₅ and wait for the acknowledgment frame’s transmission until T₇. The end of the transmit/receive process for the acknowledgment frame and the conclusion of bidirectional communication are marked by T₈. Both devices have an additional T₉ → T₈ time until the end of the timeslot for processing and other operations, if needed.

Strict adherence to the transmission and reception pattern is essential for the proper functioning of the wireless network, particularly in the time synchronization between wireless nodes. Time synchronization occurs between the network coordinator, which acts as the time source, and each wireless node associated with the network. For this purpose, the enhanced beacon frame is used, which the coordinator transmits in the first timeslot of the group of 50 timeslots. Figure 6 illustrates a synchronization procedure between two wireless nodes, with the top one being the network coordinator and the bottom one being a wireless node that is associated with or joining the network.

At T₁, the wireless device enters the reception mode and awaits the transmission of the beacon data frame. At time T₂, in accordance with the timeslot template, the coordinator initiates the transmission of the enhanced beacon frame. By time T₃, the coordinator has completed the transmission and concurrently, the wireless device completes its reception of the frame. Subsequently, the device processes the frame by extracting time-related information from the enhanced beacon frame, including the slot frame, the time, and the specific fraction of time when the transmission started. At time T₄, the wireless device updates its timeslot and timeslot group timers. Consequently, at time T₅, the wireless device will generate an interruption to indicate the commencement of the next timeslot, thereby maintaining synchronization with the network coordinator.

Synchronization precision remains a key challenge in WSNs. Ref. [20] demonstrated how hardware-assisted timestamping and drift correction can enhance accuracy with inexpensive hardware. Similarly, the LPSS protocol [21] achieves energy-efficient scheduling and synchronization by minimizing communication overhead and allocating distinct sync slots to reference nodes. Unlike our proposal, it follows a layered mesh network topology in which the coordinator propagates the time to each layer via router nodes. In [22], they also proposed a lightweight approach (SA-MAC) based on the DW1000 transceiver from Decawave that uses UWB (ultra-wide-band) communication that reduces sync-related traffic. The DW1000 uses hardware-based timestamps and precise internal oscillators to send frames at specific times with utmost accuracy. Our work builds on these by integrating deterministic time division with beacon-based alignment, minimal protocol overhead, sub-GHz communication, and COTS components to achieve time drifts comparable to the ones obtained in [20] 0.6 milliseconds vs. 0.256 milliseconds.

3.5. Testing and Validation

The testing and validation of the time management has been carried out using four development boards from STMicroelectronics: (a) NUCLEO-L476RG implementing the network coordinator application layer, connected via UART to a NUCLEO-L432KC implementing the network coordinator data link and physical layer. The ATZB-212B-XPRO extension board featuring the AT86RF212B transceiver is connected to the NUCLEO-L432KC development board via an SPI interface and several pins used for interruption management, reset, and setting the transceiver in low-power mode. (b) Two NUCLEO-L152RE development boards paired to the same ATZB-212B-XPRO extension board, implementing the application, data link, and physical layers of the wireless nodes. The user starts the network by using an application running on a PC which sends commands to the NUCLEO-L476RG using UART. A diagram of the setup is featured in Figure 7 alongside the actual setup.

Two pins on each of the NUCLEO-L432KC boards part of the wireless nodes were used as debug pins to signal the user via pulses at the start of the group of timeslots and the start of each timeslot. The pins were then monitored using the logic analyzer to calculate the time drift between the two nodes. The user interface of the logic analyzer shown in Figure 8 displays four channels: Channel 0 monitors the start of each timeslot group and Channel 1 monitors the start of each timeslot for the first wireless node, with Channel 2 and Channel 3 carrying out the same for the second wireless node.

We have then measured the time drift between the nodes using pairs of markers attached to each two close pulses monitored by Channel 0 and Channel 1 for 1 min after the devices kept running for more than 1 h. The measurements are displayed in Figure 9 below, showing that the time drift is kept below 600 microseconds.

In comparison, we have stopped the advertisement frames sent by the network coordinator and recorded the time drift between the same two wireless nodes. Figure 10 shows how the time drift increases over time and surpasses the 1 millisecond threshold we initially set.

4. Discussion

Industrial control applications demand a blend of precision, low energy usage, and system simplicity. Ref. [23] emphasized that synchronization protocols must scale while remaining robust under real-world noise and traffic. Ref. [24] recently addressed these challenges through a mesh-star hybrid protocol that balances sync precision with a low traffic load. Meanwhile, ref. [25] showed that TDMA-based inter-cluster scheduling significantly reduces delay and jitter in large deployments. These insights support the rationale behind our design: a structured yet flexible timing model based on TSCH and beacon scheduling.

This paper details a simple time management algorithm that can easily be implemented for managing the time in a wireless network used for process control. This approach can be used to manage time on wireless nodes based on COTS modules and components, allowing also for a decent time synchronization and drift between them. This was achieved by optimizing the code execution time on the microcontrollers by defining and using a HAL that directly accesses the microcontroller registers. This also allows for a good and consistent estimation of the code execution time used later in establishing the timeslot time. As we used different microcontroller families (i.e., STM32L1 and STM32L4) which have many similarities but also differences, the HAL allowed us to easily move the code between one microcontroller to another with only minor changes. The same approach can be used if we would ever need to move the code to, for example, high-performance microcontroller families like the STM32F7.

Division of time has been performed considering the timeslot duration set to 10 milliseconds, which is enough time to send and receive two IEEE 802.15.4 frames with the maximum length of 127 bytes for O-QPSK modulation and a 250-kbps date rate. For future implementations using different modulations and/or faster data rates like, for example, UWB modulation that allows up to a 27 Mbps data rate, the timeslot duration can be decreased or increased as needed. Based on the 10-millisecond timeslot, we have defined a 6000-timeslot slot frame that repeats itself continuously. This was also chosen to limit the maximum time drift between any two wireless nodes using COTS components to below 1 millisecond. Using custom-made hardware with more precise oscillators will allow the decrease in the slot frame duration, resulting in faster node response times. Shorter slot frames also have a smaller footprint on the network coordinator internal memory. Custom hardware can have an impact on the number of timeslots in the timeslot groups, but also in the structure of these timeslot groups as beacon frames do not need to be sent so often. The proposed slot frame structure allows both the operation of control loops and sending of data like sensor data between wireless nodes. This slot frame structure can be adjusted according to the application needs.

Time synchronization, critical in process control applications, has been implemented based on a customized algorithm defined by IEEE 802.15.4. This algorithm uses the timeslot template to send frames at specific times within the timeslot, the timeslot group number, and the code execution time within the microcontroller needed to process an incoming frame. This simple approach led to reasonable results in terms of the time drift between nodes considering the hardware it is implemented on. Custom hardware with more precise oscillators can lead to even lower time drifts between nodes, requiring less frequent needs for time synchronization.

Security and robustness in synchronization have become increasingly relevant in industrial WSNs. Wang et al. [26] proposed a Sybil-resistant protocol that uses node identification and timestamp correlation to filter malicious messages. Ref. [12] introduced trust-based synchronization that leverages skew uniqueness to verify message authenticity. These protocols aim to ensure that synchronization sources are trustworthy, a consideration that could be integrated into our beacon validation process for enhanced reliability in hostile environments. Adaptive schemes such as MBATS [27] use mobile beacons to synchronize nodes in environments where fixed infrastructure is impractical or cost-prohibitive. Though well-suited for dynamic or mobile networks, such methods introduce complexities not aligned with our static, process-oriented deployment. However, the principle of dynamic sync intervals is relevant for optimizing future enhancements to our fixed-schedule design. While our approach focuses on static industrial deployments, existing research demonstrates value in scenario-specific designs. For example, MBATS adapts to changing sync requirements via mobile beacon mobility, while STSS [28] minimizes beacon collision in overlapping clusters. STOC [28] and related approaches manage the sync load but reduce the active slot time, affecting the throughput. Our use of grouped timeslots and enhanced beacons preserves bandwidth while ensuring tight synchronization, especially useful for control applications with feedback constraints. Liu et al. [29] point to a critical need for scalable protocols that maintain synchronization under variable topologies and high node counts. Our current design is optimized for small-to-medium industrial cells, but lays the groundwork for hierarchical coordination mechanisms needed in future large-scale systems.

5. Conclusions

This article has presented a complete, low-cost, and highly effective time management solution for wireless sensor networks (WSNs) deployed in industrial process control applications. Using COTS hardware and an implementation based on the IEEE 802.15.4-2020 standard operating in TSCH mode, the proposed approach has demonstrated that wireless control can indeed meet the strict timing constraints previously reserved for wired systems.

The core contribution lies in the design and validation of a lightweight time synchronization algorithm that utilizes structured timeslot grouping and enhanced beacon-based coordination to achieve sub-millisecond drift between wireless nodes. Through the careful division of communication tasks, strict adherence to timing templates, and precise scheduling within a 6000-timeslot slot frame, the system enables a reliable real-time data exchange in environments where timing predictability is crucial. Validation experiments, conducted using a logic analyzer and a testbed built on STM32 microcontrollers and AT86RF212B transceivers, confirmed consistent synchronization accuracy below 600 microseconds even after prolonged operation, demonstrating system robustness.

In addition to the timing algorithm itself, this paper introduces a modular software architecture built around a custom hardware abstraction layer (HAL) and a CMSIS-compliant transceiver driver. This framework not only improves the timing consistency and execution predictability, but also supports portability across multiple STM32 microcontroller families and even on those from other manufacturers, allowing developers to reuse core logic without rewriting low-level code. Such modularity opens the door to future enhancements, including porting the implementation to higher-performance platforms or integrating the solution into more complex industrial systems.

While the results are promising for simple star topologies, there remains significant potential for extension. Custom hardware with high-precision oscillators could improve synchronization and enable even shorter slot frames, enhancing responsiveness and efficiency. Future work will explore the following: (a) hierarchical synchronization structures or integration into mesh topologies to support larger-scale industrial WSNs; (b) validation in noisy industrial environments by using channel hopping to reduce possible interference from outside sources; and (c) node redundancy to increase the robustness of the wireless network in general and the control loops in particular.

Ultimately, this work contributes a reproducible and scalable foundation for transitioning from wireless monitoring to wireless control in industrial automation. By showing that time-sensitive feedback loops can be reliably closed over wireless links, it challenges the traditional reluctance toward wireless adoption in control loops and paves the way for more flexible and maintainable industrial communication architectures.