1. Introduction
In the domain of Marine Internet of Things (MIoT), there exists a backlog of technical solutions capable of expediting practical outcomes, particularly in the pursuit of establishing underwater hydroacoustic networks [
1].
Underwater systems that operate simultaneously, including autonomous and remotely operated underwater vehicles (AUV/ROV), underwater sensors, and buoys, necessitate continuous data exchange [
2,
3,
4,
5]. The same principle applies to devices functioning as a part of group, considering the changing network geometry resulting from changes in the relative positions of these devices [
6].
MIoT provides a range of wireless communication and networking choices. These options include acoustic, optical, radio frequency, and magnetic fusion communications for data transmission. Among these, acoustic communication is particularly well suited for the underwater environment due to its ability to transmit over long distances, ranging from several hundred meters to tens of kilometers [
1,
7,
8,
9]. However, it does come with several limitations, such as low bandwidth, high intensity, long-duration reverberation, relatively large Doppler spectrum expansion, etc. [
10,
11].
The process of addressing data transmission challenges via the hydroacoustic channel entails integrating hydroacoustic modems into the sensor modules of underwater devices [
12]. Typically, underwater acoustic modems are most effective when dealing with a limited number of asynchronously interacting data sources or recipients.
When multiple acoustic modems operate simultaneously within an overlapping area, collisions of data packets received from various sources can occur. These collisions result in the loss of some or all information. As the number of concurrently operating hydroacoustic modems increases, the stability of data transmission provided by physical layer algorithms diminishes, and the probability of collisions rises. Consequently, the effective operation of modems becomes compromised, and in some cases, even unfeasible.
In the context of airspace, numerous methods exist for routing and resolving data collisions [
13]. However, in hydroacoustics, these methods may not always be employed and are typically subjected to significant limitations.
To ensure effective operation in a hydroacoustic signal propagation environment and to minimize or eliminate collisions during data exchange and delivery between two modems that lack synchronous operation capability, as well as to reduce access time to the signal propagation environment, methods from the media access control layer that utilize data link layer protocols are necessary.
Typically, this problem is addressed by employing code division or frequency division across hydroacoustic channels, i.e., when modems operate at distinct frequencies, ensuring non-interference. This enables underwater network subscribers to communicate either in a “point-to-point” (P2P) format or in “multicast” mode, where each communication occurs independently. However, if network-wide transmission is required, this approach becomes unsuitable, as network transmission relies on “broadcast” messages and some network nodes, particularly data source and data sink, which can stay too far from each other, outside of their mutual audibility (operation ranges).
For transmitting data in a hydroacoustic network with constantly changing conditions of emission and reception of signals, specialized network protocols have recently been developed. These protocols can consider and utilize a dynamically varying number of network nodes situated in the region of mutual audibility or (due to the asymmetry of communication channel characteristics) one-way audibility. An essential focus in creating network communication techniques is the design of algorithms for forming the so-called ad hoc networks [
14,
15,
16].
To manage multiple devices within the same coverage area, specialized network layer protocols are essential. These protocols facilitate broadcasting across the underwater network, even between data source and data sink that are separated by large distances by the means of intermediate network nodes, so called relay nodes. Additionally, data link layer protocols handle collisions between data packets [
17,
18,
19,
20,
21,
22].
In practical applications, these protocols are typically integrated into the software development environment (framework) of specific user applications to address network communication issues. Such a framework is commonly referred to as a software framework, which enables users to modify the existing network algorithms within the framework and incorporate new network communication algorithms as needed.
The article outlines an approach of developing Marine Internet of Things (IoT) [
1] systems. This approach relies on leveraging the existing technical foundations in the domain of hydroacoustic modems and software frameworks. By doing so, it aims to enhance the functionality of these modems, effectively transforming them into network devices.
For underwater communication systems, there are currently four advanced software frameworks known for integrating heterogeneous communication devices and transforming them into network devices. These frameworks also allow the flexible integration of modems with various sensor devices, including actuators, drive mechanisms, manipulators, and sensor systems. The following software frameworks exist in the public domain and have the following names: (1) SUNSET (developed by Sapienza University, Italy) [
14], (2) DESERT (developed by the University of Padua, Italy) [
23], (3) UnetStack (developed by the National University of Singapore) [
5], and (4) EviNS (developed by Evologics, Germany) [
24].
The EviNS software [
24] URL:
https://github.com/okebkal/evins.git (accessed on 5 October 2022) framework is the least resource-intensive option. It offers users a broad spectrum of capabilities for integrating different software modules, peripherals, and systems. It can run in real time on a low-performance processor platform, including directly on the computing platform of a hydroacoustic modem or one of the integrated devices.
The EviNS (Evologics Intelligent Networking Software Framework) software framework [
24] is a compact open-source software developed in the Erlang programming language. One of its advantages is that a set of basic programs implementing access control protocols and routing protocols are already included in the framework.
As a part of the EviNS software framework development, two hydroacoustic modems were chosen for testing: the uWAVE, manufactured by the Underwater Communications and Navigation Laboratory in Russia, and the hydroacoustic S2C series modem, produced by Evologics, Germany.
To leverage the extensive capabilities of the EviNS software framework, user applications were designed in the form of environment access control layer protocols and network layer protocols. These applications were equipped to handle various roles, which, in turn, enabled the technical integration of modems from different manufacturers into the EviNS software framework. Specifically, a uWave modem command parser was developed to incorporate the uWave modem into the program framework. For the development of user software aimed at addressing network communication challenges in Marine Internet of Things (IoT) systems, the **EviNS software framework** is recommended as a versatile tool. It can be deployed either on a third-party computer or directly on the hydroacoustic modem computing platform. When executed, it seamlessly integrates with the standard hydroacoustic modem software, transforming the modest hydroacoustic modem from a basic simplex digital communication device into a fully functional network communication node.
This paper makes the following contributions:
A model for constructing hydroacoustic networks that allows taking into account potential implementations with modems from different manufacturers as nodes in this network.
Creation of a software platform for developing and configuring proprietary algorithms for transmitting data via a hydroacoustic communications channel, which enables the modification of the existing algorithms and the inclusion of new communication techniques to achieve optimal settings for information transfer underwater.
Presentation of a comparative evaluation of network performance with and without different protocols, allowing the assessment of data transfer rates and the probability of successful delivery.
The article is organized as follows.
Section 2 highlights the versatility of the software network add-in, demonstrating its ability to “unlink” from execution on specific hardware and software platforms of the hydroacoustic modem. It also explores the potential for modifying the existing protocols within the access control layer and data routing protocols.
Section 3 considers the concept of constructing the EviNS software framework.
Section 4 provides details on the implementation of network and link layer protocols, which enable data transmission even in conditions of relatively low network dynamics while minimizing energy consumption per unit of data delivered to the recipient. Finally,
Section 5 presents the findings from experimental studies, followed by a discussion of the results and conclusions.
2. Versatility of the Software Network Add-In of the Hydroacoustic Modem
From the deployment and usage perspective, the versatility of the EviNS software framework across various computational platforms is ensured by two factors. Firstly, the creation of the EviNS software framework in the Erlang programming language provides a foundation for its adaptability. Secondly, the ability for the cross-platform compilation of the software framework, written in Erlang, further enhances its versatility.
Ensuring these two conditions, after cross-platform compilation, for instance, on a desktop PC, the EviNS software framework can also be deployed on other platforms, particularly on embedded (low-power) computing platforms with relatively low performance.
A distinctive feature of EviNS is its utilization of the Erlang programming language for its development, characterized by a number of advantages such as built-in support for parallelism with distribution and duplication of computational processes, resulting in fault tolerance. Erlang applications have proven themselves in large telecommunication systems (distributed, reliable, soft real-time parallel systems). Another significant advantage of Erlang is its open-source nature URL:
http://www.erlang.org (accessed on 5 October 2022) and a large number of OTP (Open Telecom Platform) libraries, enabling a wide range of actions in telecommunication systems, from compiling ASN.1 applications (in a language describing the abstract syntax of data used in the OSI telecommunication architecture) to developing various user applications in Erlang and creating web servers. Moreover, OTP libraries are also accompanied by open-source code. Erlang/OTP has its own program execution environment, called the BEAM virtual machine. Using BEAM, Erlang source code can be compiled into bytecode, which is a set of instructions understood by both the compiler and the Erlang runtime environment. Compiled code managed by BEAM on one computing platform can then be executed on other computing platforms containing the same BEAM virtual machine. Thanks to this capability, applications written in Erlang can run on various computing platforms, providing high flexibility in using an application once written without the need for extensive code reworking for other computing platforms.
Furthermore, there is the possibility of cross-compiling an Erlang application for use even on platforms that are incapable of running an operating system. In such cases, the so-called “dockers” provided by the manufacturers of computing platforms are typically used. A docker can be deployed on any general-purpose computing machine (usually running on the Linux operating system) to simulate the computing environment of the target processor. By placing the BEAM virtual machine in a docker, it can facilitate the compilation of Erlang/OTP with subsequent transfer of the resulting code to the target processor for execution. Additionally, by creating user applications in the Erlang language and compiling these applications on a general-purpose computing machine using the BEAM virtual machine, the resulting BEAM files can also be transferred for execution on the target processor simply by copying them.
In preparing the materials for the current article, the advantages of the universality of the EviNS software framework were utilized. Specifically, after its cross-platform compilation on a desktop PC with OS Linux Debian and the Erlang virtual machine, the resulting set of compiled BEAM files was transferred to another computing platform where OS Linux Debian and the Erlang virtual machine were also installed. However, this computing platform was no longer a desktop PC but instead was a compact platform, the ODROID H2. In general, program execution can also be achieved on computing platforms such as System-on-Module (SoM) with integrated ARM processors, including the NVIDIA Jetson NX, Microchip Atmel, or Raspberry Pi.
From the perspective of user programs developed for the EviNS software framework, the universality of the software networking overlay of the modem was ensured by the inherent framework approach for constructing EviNS. In this approach, any program configuration consisted of two parts: the first, constant part, i.e., the framework itself, which remained unchanged from one configuration to another but contained slots where the second (variable) part could be placed, and interchangeable modules or extension points. With this approach, user programs created and compiled on a PC were simply added to the deployed EviNS framework on another computing platform by straightforwardly copying them as BEAM files.
Thus, user programs could be developed for the EviNS software framework, for example, on a desktop PC, and then simply copied for execution on another computing platform, such as a modem platform (with the EviNS framework already deployed on it), without the need to recompile the entire code on the new platform (i.e., both the framework code and the newly added module code).
Figure 1 illustrates the architecture of the EviNS software framework URL:
https://github.com/EvoLogics/evins/wiki (accessed on 5 October 2022), which (according to the framework construction concept) includes a set of independently operating processes, each defined as a finite state machine, with these finite state machines being controlled by external and internal events.
From the perspective of the interaction between the user application and the modem, the universality of the EviNS software framework is in the development of the network modem’s command interface as an open-ended list. This means that, in addition to the initial set of network-level commands provided by the framework developer, allowing the control of the modem, and a set of acknowledgments (which the modem returns to the user application to notify it of the details of command execution), users were also given the opportunity to develop their own additional commands and macros based on them, thus modifying/extending the functional capabilities laid down by the software framework developer.
Therefore, the EviNS software framework can be considered as a universal tool for users to develop their own applications, which can be executed on the computing platform of their choice from a wide range of models. Moreover, a significant convenience is the ability to focus solely on the “core work”, creating applications of practical interest, without being distracted by numerous peripheral tasks related to the specifics of the computing platform, or the need to link the developed application with a multitude of processes in the computing environment to ensure its functioning. This work is performed for the user by the constant part of the software framework.
In general, for the development of user applications (protocols of the data link and network layers), the EviNS software framework was considered universal in terms of the following:
Its deployment and usage on various computing platforms, particularly its capability for cross-platform compilation on a desktop PC (with OS Linux Debian and the Erlang virtual machine) followed by transfer to another computing platform (the experimental part was conducted on the Odroid H2 computing platform).
The framework approach for constructing EviNS, where the user application comprised two parts: a constant part, which the user did not modify (it facilitated interaction with the computing environment), and a variable part (it contained the user module and facilitated the operation of the application according to the user’s algorithm of practical interest).
The interaction between the user application and the modem, for example, where the set of commands of the data link and network layer protocols remained unchanged for modems from different manufacturers; the only thing that changed was the syntax analyzer of commands, adapting the command set of a modem from a specific manufacturer to the command set typical for the software framework.
Previously, there have been no instances found in the literature of using the EviNS software framework to integrate modems from third-party manufacturers into underwater networks (i.e., modems not being manufactured by Evologics company, Berlin, Germany).
Therefore, in this article, before discussing an example of using the EviNS software framework to develop a user application (a set of network layer protocols) for modems from a third-party manufacturer, it is advisable to examine the concept of constructing the EviNS software framework in more detail.
3. The Concept of Building the EviNS Software Framework
As mentioned earlier, the EviNS software framework is distributed under an open-source license, such as GPL/MIT. In this form, the EviNS software framework can be used in educational processes or in initial research in the development of the Internet of Things in the maritime domain. However, the software framework may also include numerous user libraries with closed-source code, thereby prohibiting the free distribution of a user’s (specialized) version of the software framework. This type of usage of EviNS is intended for developers of commercial software products, particularly in the creation of industrial products for the Internet of Things in the maritime domain. (According to the terms of the license, in this case, the developer of the commercial software product is obliged to pay a licensing fee to the developer of the open-source software framework.)
As depicted in
Figure 1, the EviNS software framework is based on the utilization of the Erlang virtual machine and comprises a set of independently operating agents. Furthermore, the implementation of the EviNS software framework adheres to the design principles of Erlang/OTP concerning the structure of code written in the Erlang language, as well as its processes, modules, and directories.
Figure 2 presents the fundamental concept of the EviNS software framework—a model of process structuring based on the interaction of work environments and supervisors URL:
https://github.com/EvoLogics/evins/wiki/arch (accessed on 5 October 2022). Work environments encompass working processes that perform useful computations, which may include agents, interface handlers, and configurators. Supervisors are processes responsible for monitoring the functioning of the work environment or the operation of other supervisors. A supervisor can restart processes within the work environment upon detecting faults in them.
As illustrated in
Figure 2, the finite state machine (FSM)—the top-level supervisor (abbreviated as FSM-TLS)—monitors the operation of the configuration FSM (FSM-SFC) and the agent supervisor FSM (FSM-AS) in the EviNS software framework. In the event of a failure in the FSM-SFC or one of the FSM-ASs, the top-level supervisor FSM-TLS restarts the corresponding process without affecting other running processes. Each FSM-AS is configured and launched by the FSM-SFC configurator. According to its configuration, each FSM-AS starts and oversees specific modules assigned to it, implementing the functionalities of the work environment FSM (FSM-WES), the roles of the work environment (RWE), and other FSMs, including those that are part of Erlang/OTP.
The general approach in implementing the EviNS software framework involves dividing the process code into a common part (functional modules) and a special part (callback modules).
The functionalities of the RWE ensure communication through interfaces supported by the software framework. The previously mentioned interface handlers are implementations of work environment roles. To implement new functionalities of work environment roles, assigning callbacks responsible for parsing raw data into user-defined data structures (tuples) and for reconstructing raw data from user tuples, initializing the callback, managing the callback configurator, and stopping the callback when the process is completed is necessary. The FSM-SFC can control multiple interface handlers according to the agents’ configurations.
Good examples of interface handlers are roles that perform functions of command syntax parsers for interfaces of modems from various companies (or command interface converters), or roles acting as syntax analyzers for the widely used NMEA interface.
The functionalities of the work environment FSM (WE-FSM) support agent initialization and the interaction of agents with interface handlers. The implementation of the WE-FSM must necessarily define callbacks responsible for creating processes and for agent initialization based on configurator data.
The functionalities of the finite state machine (FSM) ensure the operation of agents such as a user-defined FSM or an FSM with a stack. To define an agent, the FSM must be explicitly declared as a structure defining states and transitions to other states, equipped with a transition callback. Additionally, initialization and termination callbacks must be capable of returning initial and final events of the FSM, respectively. To handle events, a callback performing preliminary processing of incoming messages must be provided. Messages received from interface handlers or timers are converted into events of the specific FSM. For each state, a corresponding handler must be created, invoked upon each event occurrence. The implementation of a user-defined FSM must also include callbacks responsible for creating a process, initializing it, and terminating it.
Each agent is explicitly defined as an FSM or an FSM with a stack and is controlled by events generated externally by interface handlers or internally by event handlers or timers. It is important that all agents are isolated from each other to protect against failures—the failure of one agent should not affect the behavior of another agent functioning properly. For this purpose, the operation of each agent is isolated within its own work environment and is supervised by a supervisor.
Figure 2 demonstrates the interaction of a grouped set of work environments controlled by a supervisor. In the case of an error in the operation of one of the agents, the supervisor restarts its operation. The remaining agents continue executing their programs regardless of the failure of the “faulty” agent. Thanks to the isolated operation, errors in one or several agents do not affect the execution of the entire computational process. Each supervisor can be supervised by another supervisor. For greater resilience of the computational process, agents and supervisors can be duplicated.
Due to the fact that each agent is defined as a finite state machine or a finite state machine with a stack, it is a standalone software component that provides strictly defined functions and has a precisely defined interface specification for messaging. As mentioned earlier, agents can act, for example, as a protocol for network data exchange, solving computational tasks (including preprocessing sensor data), or act as an intermediate agent between external sensors and the communication modem to optimize data exchange over the communication channel.
Regarding the interaction between agents, they are interconnected with each other and with external processes through interface handlers, transforming raw data received from external interfaces into strictly defined messages, or vice versa, converting messages received from corresponding agents back into raw data. Interface handlers necessary for connecting to each agent are specified for each agent. Agents are independent of the message source.
Determining the message source is the task of the configurator, which allows linking all agents together and with external interfaces through interface handlers defined for the corresponding agents. The agent’s configuration can either be predefined in a configuration file or generated “on the fly” through interaction with the configuration agent observer.
Together with interface processors, the agent can be viewed as a virtual device connected via customizable physical or virtual interfaces to other components of the system.
As for the types of interface handlers, the EviNS framework utilizes four types of interfaces for different types of interactions among agents and external applications (
Figure 3) (URL:
https://github.com/EvoLogics/evins/wiki/arch (accessed on 5 October 2022)):
TCP Socket: this is the most common type of interface handler used for interaction between agents as well as between agents and external applications.
Erlang Port: this type of interface handler serves as the primary mechanism for communication with the external world and is exclusively used for interactions between agents and external applications.
Erlang Message Queue: this interface type enables direct message exchange between agents without the need for syntax parsing by interface handlers.
Cowboy HTTP Server: Cowboy is a lightweight, fast, and modular HTTP server written in Erlang. This interface type translates user actions in a web browser into messages delivered to agents via interface handlers and generates necessary notifications in response to user requests.
It is worth delving into this further. Currently, EviNS includes the AT Commands role, which serves as a syntax parser only for commands specific to Evologics modems. However, there are numerous modem manufacturers who do not have a direct means to utilize EviNS protocols for their own network communication tasks.
To address the integration of arbitrary modems with EviNS, two approaches can be taken. The first involves modifying the AT Commands role to enable the protocols of the data link and network layers to work with the commands of the chosen modem.
The second approach entails embedding additional roles into EviNS alongside the AT Commands role, providing the ability for the protocols of the data link and network layers to work with commands from third-party modems. This is illustrated in
Figure 4.
To connect any other modem to EviNS, the software framework must include an additional (newly developed) modification of the medium access control protocol, as well as an additional (newly developed) modification of the network protocol. In other words, as many modems need to be connected to EviNS, an equal number of modified or newly developed protocol pairs must be included in the software framework. For each modem, there will also be a need to develop a role responsible for parsing commands specific to that modem.
Due to the openness of the EviNS source code, all of this is achievable. However, implementing such changes would require significant modifications to the software framework. In many respects, altering a well-functioning software framework is undesirable.
Therefore, another approach could be considered, which involves not modifying the software framework but rather adding applications to it that are inherently capable of working with multiple modems (with different roles). This is illustrated in
Figure 5—in addition to or instead of the existing protocol, a protocol could be developed that works not only with the AT command role but also with roles of other commands.
This approach could significantly reduce the costs associated with expanding the capabilities of the software framework, particularly by enhancing its ability to create hydroacoustic networks based on modems from different manufacturers. In turn, this would contribute to broadening the scope of tasks related to the Internet of Things in the maritime domain.
As a part of the current project to expand the capabilities of the software framework, custom protocols for the medium access control and network layers have been developed. These protocols are capable of working with a variety of roles responsible for parsing commands from modems of different manufacturers, such as the uWave modem and the Evologics modem.
These roles enable the parsing of commands specific to the corresponding modem and convert them into the format of internal messages characteristic of EviNS applications. They also facilitate the reverse process, parsing commands from EviNS applications and converting them into the format of internal messages for the respective modem. For EviNS utilization, user application is created.
The EviNS framework source code resides on the GitHub web service, which hosts projects using the Git version control system. This platform provides extensive opportunities for the collaborative development of open-source IT projects. The link, URL:
https://github.com/okebkal/evins (accessed on 5 October 2022), provides access to the directory structure where the EviNS software framework is located. For instance, the/include directory contains macros that describe the structure of a finite state machine. The/src directory houses the source code for agents that have already been created. The examples catalog includes application samples that serve as templates, helping to lower the “entry threshold” for the practical use of the EviNS software framework.
To build the EviNS software framework on a Linux PC, the user can clone the EviNS project into a directory prepared for the clone via the terminal, in particular using the command git clone, URL:
https://github.com/okebkal/evins.git (accessed on 5 October 2022).
After cloning the EviNS project, you can install it using the make command from the terminal in the project’s root directory. During installation, the EviNS project also includes a list of dependencies, allowing you to install all the necessary libraries from GitHub. Once the EviNS software framework is installed, configuration is required before EviNS can be operational.
The implementation of initial network protocols can be considered as a component of the comprehensive EviNS software framework. This framework, in turn, has the potential to become a part of standard hydroacoustic modem software. Such implementation holds practical significance for establishing an underwater sensor network within Marine Internet of Things (MIoT) systems. Notably, several essential network layer protocols have already been incorporated into the EviNS software framework.
To reduce the occurrence of collisions (or even prevent them altogether), a specialized environment access control protocol variant called CSMA-Aloha has been incorporated into the EviNS software framework. Currently, this protocol is specifically designed for broadcast data packets. According to the protocol, each hydroacoustic modem “listens” to the hydroacoustic channel before transmitting its own data packet. It begins broadcasting only when there is no activity from other network participants. Each participant in the network receives information about when they can access the channel. This capability is achieved by including the protocol in each of the network nodes.
In addition to controlling access to the environment, network participants may also be interested in the location of the source or recipient of the data they plan to exchange during a data exchange session. When participants in the network are separated by a significant distance, the data sources may not have a direct connection to the data recipients. However, with sufficient connectivity within the hydroacoustic network, data transmission can occur through neighboring participants who are within a working distance from the desired data sources or recipients. These neighboring participants contribute to redirecting the data flow in the correct direction. To address this challenge, the EviNS software framework incorporates two specialized data routing protocols, i.e., static routing and avalanche routing, both of which control the number of transmitted packets.
According to the static routing protocol, each network participant is pre-assigned one of the two roles: either a relay or a passive participant. Upon receiving a data packet, the relay participant forwards it to the next address (also pre-assigned) of another relay participant, and this process continues until the data reaches its final recipient. While this protocol can be efficient in terms of energy consumption and data delivery time, it suffers from limited applicability due to the inability to alter the geometry of the hydroacoustic network after it has been deployed underwater.
The second protocol is designed for networks with rapidly changing geometries (such as those involving mobile participants like Autonomous Underwater Vehicles (AUVs)). While it may be redundant in terms of the amount of transmitted data within the network (and consequently, energy consumption), it reliably functions with any network dynamics. Under this protocol, each network participant determines the current data packet number that they have received. If a packet is not intended for them and is received for the first time, they redirect it to other network participants within their working range. This process continues until the package reaches its intended recipient.
The utilization of these protocols in practical scenarios was conducted as a part of a study in [
25]. This study investigated the performance characteristics of a digital hydroacoustic network built upon these protocols, as well as the advantages and disadvantages associated with their practical use. The findings revealed that the combination of properties inherent to these protocols confers an advantage to users in networks with dynamically changing geometry—such as acoustically interconnected cooperative or coordinated groups of fast-moving AUVs. Notably, these advantages encompass minimal transmission time and the highest probability of successful data delivery to the ultimate recipient within the network. However, it is essential to acknowledge that the specific energy consumption for transmitting a unit of information within such a network is relatively high (attributable to frequent data delivery route duplication). Consequently, the autonomous operational duration of such a network remains relatively short.
In the following section, the implementation of a number of network and link layer protocols that were developed and deployed by the authors within the EviNS software framework is presented. This implementation is capable of functioning in a dynamic network. However, in cases of rapid changes in network geometry, it may struggle to adapt to the evolving connections among its mobile participants. Under this protocol, network participants periodically search for and reassign data delivery routes (for relatively short periods). During data transmission, packets are only forwarded by those participants included in the updated route and designated as relay nodes. It is expected that the use of this protocol will result in relatively low levels of excess data transmission in the network (and consequently, lower energy consumption) compared to avalanche routing. However, this protocol is not intended for use in networks with rapidly changing geometries. In other words, the presented implementation of this network-level protocol strikes a compromise between network dynamics and energy efficiency and is limited to applications where such a compromise is acceptable.
A notable aspect of the current work involves creating user applications in the form of protocols for the environment’s access control layer and network layer. These protocols are designed to interact with different roles, enabling the technical capability to connect third-party modems to the EviNS software framework. Specifically, this includes Russian-made uWAVE modems. Importantly, this example highlights another advantage of utilizing a software framework for constructing hydroacoustic networks, i.e., the ability to leverage previously developed protocol stacks within the software framework to control hydroacoustic from various manufacturers, thereby significantly enhancing their functionalities.