Communications systems and methods

Abstract

This invention relates to a modular sensing, communication, and analytics platform. The platform includes a modular device network having a communication module, a main module, and at least one modular device, where the communication module, the main module, and the at least one modular device use acoustic signals, visual signals, light signals, and / or radio frequency to establish a communication link between the communication module, the main module, and the at least one modular device.

Description

COMMUNICATIONS SYSTEMS AND METHODSCross-Reference to Related Applications

[0001] This application claims the priority benefit of U.S. Provisional Application No.63 / 656,465, filed June 5, 2024, which is incorporated by reference herein.Technical Field

[0002] This invention relates to a modular sensing, communication, and analytics platform.Background

[0003] Most commercial undersea modems are based on “black-box”, monolithic architectures where the majority of the networking functionalities are defined into, and are inseparable from, the hardware fabric. As a consequence, existing modems cannot implement arbitrary waveforms or keying schemes, algorithmically controlled waveforms able to adapt to the time-varying environment, or dynamic spectrum access allocation schemes to switch to different frequency channels. The modem is hardware-tuned to a fixed acoustic channel and cannot change frequency. Therefore, existing modems cannot react on a frequency- or waveform-diversity basis to interference, jamming, co-located transmissions, or mammal sounds; they cannot automatically modify waveform parameters at different layers of the protocol stack; or run inference algorithms that process in real-time digital IQ samples with new machine learning algorithms.Summary

[0004] In embodiments, the invention is directed to a modular sensing, communication, and analytics platform.

[0005] In embodiments, the invention is directed to a modular device network. The modular device network may include a communication module, a main module, and at least one modular device, where the communication module, the main module, and the at least one modular device use acoustic signals, visual signals, light signals, and / or radio frequency to establish a communication link between the communication module, the main module, and the at least one modular device to establish a modular communication network. In some embodiments, thecommunication module utilizes acoustic signals in the audible or ultrasonic spectrum to establish the communication link. In some embodiments, the communication link is capable of transmitting data through the interface between solids and liquids, solids and gases, and / or gases and liquids. In some embodiments, the communication link is capable of transmitting data through the interface between water and air.

[0006] In some embodiments, the at least one modular device comprises at least one underwater device configured to collect data and transmit said data to the main module via acoustic signals. In some embodiments, the data is audio data and / or visual data, such as images or videos.

[0007] In some embodiments, the main module comprises a processor. In some embodiments, the processor may be configured to receive data, process data, and / or transmit data. In other embodiments, the processor is configured to execute one or more algorithms that at least partially incorporate artificial intelligence. In further embodiments, the processor is configured to execute one or more algorithms for receiving, processing, and / or transmitting audio and / or visual information.

[0008] In some embodiments, the communication module and the main module are housed in a buoyant device configured for deployment in a body of water. In some embodiments, the buoyant device is self-operable. In some embodiments, the buoyant device comprises one or more operationally connected modules each being configured to execute a sensing, processing, or transmitting function.

[0009] In some embodiments, the at least one modular device is an aerial communication device, an aerial sensing device, an aerial recording device, an underwater communication device, an aerial sensing device, or an underwater recording device.

[0010] In some embodiments, the modular device network also includes an anti -jamming component configured to adjust a signal frequency to accommodate large volumes of data for processing and / or transmission. In some embodiments, the modular device network also includes a user interface dashboard. In some embodiments, the user interface dashboard is located at a remote location relative to the communication module and the main module, such that transmitted, via the communication module, from the main module to the user interface dashboard. In other embodiments, the user interface dashboard is located on the buoyant device.

[0011] In some embodiments, the main module comprises a modular software architecture configured to compartmentalize one or more processing functions of the main module.

[0012] In embodiments, the invention is directed to a buoyant device having a communication module and a main module, where the communication module and the main module are operationally connected with one or more modular devices and configured to communicate with said modular devices using acoustic signals, visual signals, light signals, and / or radio frequency. In some embodiments, the one or more modular devices include one or more underwater sensing and / or communication devices.

[0013] In embodiments, an underwater network system is provided. The underwater network system includes a plurality of underwater nodes, each node comprising an acoustic modem and multi-layer networking stack including physical, MAC, network, and transport layers and a routing protocol executing on each node, wherein the routing protocol is configured to encode link-layer and physical-layer performance metrics, including but not limited to link quality, signal-to-noise-ratio, throughput, acknowledgments, packet delivery ratios, and timing jitter, into a compressed routing header, update network-layer route tables based on cross-layer feedback from physical, MAC, and transport layers, including packet acknowledgment success, failure detection, and timing irregularities, and transmit link metrics within regular data traffic packets such that network maintenance, topology updates, and path quality monitoring occur without requiring dedicated control packet overhead. In some embodiments, each data packet carries a real-time accumulated transmission quality field that reflects current channel conditions and contributes to routing decision updates. In some embodiments, failure detection is performed using one of more of physical layer signal metrics, missed MAC-layer acknowledgments, duplicate or out-of-sequence packet reception at the transport layer, and timers configured to decay stale link quality entries. In some embodiments, the routing protocol is influenced by both proactive periodic messages and opportunistic telemetry embedded in transactional data traffic to reduce acoustic congestion and improve route responsiveness.

[0014] In embodiments, a communication header format for an underwater network is provided. The network may include a single-byte alias identifier for source and destination nodes for replacing IP and UDP address conventions, a hop tracking field, including a field for current node, previous node, and intended next node hop, an accumulated transmission quality byte updated with each node hop, and a fragmentation and reassembly field, including a field forsequence ID, last sequence, payload, and byte count, where the header enables routing, fragmentation, and reassembly in underwater networks without dependency on traditional network stack formats. In some embodiments, one or more node aliases are dynamically allocated and mapped to real-world identifiers using a distributed or gateway-coordinated aliasing mechanism that supports runtime entry and removal of nodes. In some embodiments, packet reassembly is performed in-network at each hop or only at the final destination, based on header-configured policies for efficiency or robustness.

[0015] In embodiments, a system for bridging terrestrial and underwater networks is provided. The system may include a gateway node configured to translate between internet protocol traffic and underwater mesh packets, a packetization engine that fragments large terrestrial packets and inserts compressed routing headers suitable for underwater channels, and a discovery mechanism wherein underwater nodes locate the gateway via flooded packets or periodic beacons. In some embodiments, a gateway selection and / or a route quality are updated periodically based on real-time packet loss, latency, and retransmission metrics derived from the system. In some embodiments, a fragmentation size and a packet spacing are dynamically adjusted based on real-time environmental factors including signal -to-noise ratio, Doppler spread, and historical link reliability.

[0016] In embodiments, a system for real-time underwater position monitoring and forwarding is provided. The system may include one or more acoustic mesh nodes equipped with localization sensors or GNSS-derived positional data, a lossy compression scheme that encodes spatial coordinates and velocity vectors into reduced-resolution payloads optimized for underwater bandwidth, and a routing mechanism that forwards compressed positional telemetry through the mesh to a topside or remote dashboard. In some embodiments, the dashboard reassembles compressed telemetry and renders a real-time network topology using timestamp correlation and hop-delayed propagation modeling. In some embodiments, a fallback routing path is automatically selected for positional telemetry when link reliability falls below a system- defined threshold.

[0017] In embodiments, a self-configuring underwater wireless communication system is provided. The system may include a floating base station comprising a software-defined acoustic modem and a multi-interface edge processing unit, one or more underwater nodes configured to wirelessly communicate with the base station using acoustic channels, and acentralized protocol executed by the base station, the protocol being configured to detect, associate, and de-associate underwater nodes, allocate communication resources using hybrid contention-based and reservation-based channel access, and coordinate access to multiple frequency channels including a dedicated control channel and dynamically assigned data channels. In some embodiments, the base station transmits at least two types of beacon messages to synchronize node behavior, allocate resources, and schedule uplink transmissions.

[0018] In embodiments, a modular buoy-based gateway for underwater to terrestrial communication is provided. The gateway may include a software-defined modem connected to an acoustic transducer for underwater communication, an edge computing unit connected to multiple terrestrial network interfaces including LTE, Wi-Fi, and satellite links, and a power management system. The power management system may include a solar-powered battery system, a maximum power point tracking module, and a microcontroller configured to selectively enable or disable subsystems based on remote commands or power levels. In some embodiments, the microcontroller controls relays and voltage regulators via commands received over a satellite network, enabling remote device activation, telemetry reporting, and diagnostic.

[0019] In embodiments, a centralized medium access control protocol for underwater acoustic communication is provided. The protocol may include a shared control channel used for node discovery, beaconing, and access requests, a plurality of orthogonal frequency channels used for dedicated data exchange, and a hybrid MAC scheme where contention is permitted on the control channel during association, and data transmission occurs through reserved frequency channels without collision. In some embodiments, the access point dynamically updates the assignment of frequency channels based on observed traffic, inactivity timeouts, or node disconnection events.

[0020] In embodiments, a real-time underwater network management dashboard is provided. The dashboard may include a network visualization engine configured to reconstruct and display underwater topology using data packets embedded with route traces and federated acknowledgments from multiple receivers, a routing engine configured to process overlay network data from edge nodes and gateways and dynamically generate updated paths across underwater and terrestrial segments, and a feedback mechanism that integrates acknowledgment data from distributed edge nodes to confirm packet delivery and update link metrics. In someembodiments, the federated acknowledgment mechanism aggregates delivery confirmations from multiple underwater nodes to improve reliability in non-reciprocal acoustic conditions.

[0021] In embodiments, a cross-platform dashboard interface for underwater network control is provided. The control may include a protobuf-based schema for defining and rendering heterogeneous asset types, including mobile, static, and virtual sensors, a dynamic mapping engine that overlays asset metadata and communication metrics on geospatial terrain, and a rendering engine operable across edge devices, cloud platforms, and underwater modems, enabling consistent asset control and monitoring across network layers. In some embodiments, the mapping engine dynamically updates asset visualizations using real-time telemetry and command responses from underwater nodes and gateways.

[0022] In embodiments, a software interface framework for underwater network control is provided. The control may include a gRPC-based API for issuing remote commands and receiving telemetry from underwater modems, a modular packet format abstraction based on Protobuf schemas for encoding network metrics, asset data, and control messages, and an integration with IP-bridging modules supporting real-time data compression and interface tunneling over kernel-managed network bridges.

[0023] In embodiments, a multi-domain communication buoy for underwater network interfacing is provided. The network interface may include a housing containing a software- defined acoustic modem for underwater communication, an edge computing unit integrated with terrestrial network interfaces including LTE, Wi-Fi, satellite (Starlink or Iridium), other RF services including but not limited to mesh networking interfaces and Ethernet, and a control system configured to route data between underwater assets and terrestrial / cloud networks using dynamic protocol bridging and IPv4 tunneling. In some embodiments, the control system selectively prioritizes interface use based on bandwidth availability, power status, or environmental condition metrics. In some embodiments, the edge computing unit is configured to execute artificial intelligence models locally, which includes storage and compute resources capable of running Al inference tasks, preloaded or remotely updated Al models for tasks including acoustic classification, anomaly detection, or environmental monitoring, and a telemetry pipeline to report ALgenerated insights over satellite or RF interfaces to a user- accessible dashboard.

[0024] In embodiments, an autonomous buoy power and control system is provided. The system may include a solar-rechargeable battery pack connected to a maximum power point tracking (MPPT) controller, a microcontroller configured to activate or deactivate subsystems via programmable relays, and a satellite-controlled interface enabling remote commands for telemetry polling and device switching. In some embodiments, the microcontroller logs solar charging, battery state, and load metrics, and transmits telemetry via Iridium short-burst messaging (SBM) or LTE channels to a cloud dashboard.Brief Description of the Drawings

[0025] Having thus described various embodiments of the present invention in general terms, reference will now be made to the accompanying drawings, which are not necessarily drawn to scale, and wherein:

[0026] FIG. l is a schematic diagram of a modular device network, according to one or more embodiments of the present disclosure.

[0027] FIG. 2 is a diagram of a hardware architecture for a processing module, according to one or more embodiments of the present disclosure.

[0028] FIG. 3 is a diagram of a GNU radio driver architecture, according to one or more embodiments of the present disclosure.

[0029] FIG. 4 is a diagram of software architecture for a processing module, according to one or more embodiments of the present disclosure.

[0030] FIG. 5 is a diagram of electrical architecture for a buoyant modular device, according to one or more embodiments of the present disclosure.

[0031] FIG. 6 is a diagram of an open interface architecture for a processing module, according to one or more embodiments of the present disclosure.

[0032] FIG. 7 is a diagram of a UV programable protocol stack having a docker container profile, according to one or more embodiments of the present disclosure.

[0033] FIG. 8 is a graph of the results of basic acquisition. The upper plot shows the input signal embedded in bandlimited AWGN at an input SNRi of +3 dB, while the lower plot shows the output of the basic acquisition process with an output SNRo of 25.2 db. The location of the peak identifies the start of the 32-chip acquisition waveform.

[0034] FIG. 9 is a graph of the performance of all (combined) enhancements for JANUS acquisition processing.

[0035] FIG. 10 is a graph of the results of adding spectral redundancy to a JANUS transmission. Circles represent original JANUS frequency locations, while the Xs mark the redundant locations.

[0036] FIG. 11 is a graph of the BER results (panel A), estimated velocity of the mobile modem (panel B), constellation without (panel C) and with (panel D) doppler compensation is shown.

[0037] FIG. 12 is a graph of the estimated velocity of the mobile node (panel A), estimated frequency shift for several subcarriers (panel B), and estimated doppler factor alongside with BER results with and without the doppler compensation (panel D) is shown.

[0038] FIG. 13 is a representative image of the control screen of the automated anti -jamming communication software.

[0039] FIG. 14 is a representative image from the Trident Spectre 2022 Exercise, Underwater Wireless Video Streaming.

[0040] FIG. 15 is a representative diagram of the required bytes necessary for HydroMesh operation.

[0041] FIG. 16 is a diagram of a node topology for a HydroMesh network.

[0042] FIG. 17 depicts propagation of Accumulating Transmission Quality of a byte transmitted within the HydroMesh network.

[0043] FIG. 18 is a diagram of a five-node network topology for a HydroMesh network.

[0044] FIG. 19 depicts an initial network topology displayed in the Hydronet Dashboard.

[0045] FIG. 20 illustrates a data transmission process, as displayed in the HydronetDashboard.

[0046] FIG. 21 illustrates a HydroFi system.

[0047] FIG. 22 illustrates a CB-450 Data Buoy.

[0048] FIG. 23 is a block diagram of the software architecture of the HydroBuoy.

[0049] FIG. 24 depicts the HydroBuoy control dashboard showing control options on the left side and close-up detailed view of the monitoring menu.

[0050] FIG. 25 illustrates frequency division into multiple channels, highlighting the shared control channel, and the data channels.

[0051] FIG. 26 is a MAC protocol flowchart for Access Point (AP) and node.

[0052] FIG. 27 illustrates a message sequence diagram illustrating the key protocol steps between access point and node, including beaconing, resource allocation, and data transmission.

[0053] FIG. 28 is a GNU Radio flowgraph of a HydroFi node.

[0054] FIG. 29 is a graph of measured harvested power over time.

[0055] FIG. 30 is a graph of power measurements (top) and calculated energy (bottom) during variable weather conditions.

[0056] FIG. 31 is a graph of power measurements (top) and corresponding accumulated energy metrics (bottom) during continuous operation of the fully integrated system.

[0057] FIG. 32 is a graph of the energy performance during Hydronet modem charging.

[0058] FIG. 33 is a diagram of the HydroBuoy network architecture and connection network.Detailed Description

[0059] Embodiments of the present invention now will be described more fully hereinafter with reference to the accompanying drawings, in which some, but not all, embodiments of the inventions are shown. Indeed, the invention may be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art. Like reference numbers refer to like elements throughout. The singular forms “a,” “an,” and “the” can refer to plural instances unless the context clearly dictates otherwise or unless explicitly stated.

[0060] A modular network for use in various underwater and terrestrial applications is described herein. This network may be capable of executing sensing, on-board Al-based inference processing, and other data processing functions. In this way, the network is capable of conducing acoustic, ultrasonic, optical, visible light, and / or radio frequency sensing and can be equipped with additional sensors to perform additional environmental sensing, including acidity, salinity, pressure, turbidity, oxygen, or other parameters.

[0061] In aspects, the modular network devices have the capability to embed edge computing and Al for conducting inference and decision making at multiple levels. This allows Al-driven adaptive modulation, autonomous network management, or onboard data analytics (e.g., prioritizing important data to send first). Such intelligence, combined with edge processing,allows nodes to make localized decisions — for example, filtering sensor data, predicting link quality, or re-routing packets in a changing undersea environment — without always relying on surface control. This also allows nodes to run Al networks that perform analytics, inference, and decision-making on the collected sensor data to perform sophisticated monitoring, sensing, detection, and classification operations on the device. This edge computing capability reduces latency, ensures rapid response times, and minimizes dependence on external infrastructure. This allows devices and networks of devices to perform detection, classification, tracking, and localization operations for marine mammals, crewed or uncrewed underwater vehicles, crewed and uncrewed surface vessels, and divers.

[0062] Central to the sensing, communication, and analytics platform disclosed herein is a wideband modular modem (WMM), the hardware architecture of which is illustrated in FIG. 2. The WMM contains four core modules: (i) a main module, (ii) a converter, (iii) a communication module, and (iv) a power and / or sensor module. These modules are connected through standard interfaces, which enable a rearrangeable and upgradable design, thus enabling hardware evolution and reconfiguration to support different desired functions.

[0063] The main module functions as the core computational engine of the modem, which hosts operations including baseband processing, real-time reconfiguration of the software protocol stack, and execution of ap-plications and local computations. Unlike traditional modems based on either DSPs or traditional CPUs, the WMM’s main module is based on a heterogeneous computational platform, System-On-Module (SoM), which incorporates a advanced processor. The SoM architecture of the module includes heterogeneous processing units to process diverse workloads, including an processing system(PS), a FPGA, a real-time processor unit, and a Graphics Processing Unit (GPU) in a single chip. It supports a rich set of I / O peripherals, including interfaces (such as Ethernet, USB, UART, CAN, EBI / EMI, I2C, MMC / SD / SDIO, and SPI), and GPIO pins to enable connectivity with virtually any sensors, data converters, and memories. Overall, it offers a rich set of features and

[0064] The main module incorporates an FPGA with programmable logic (PL) with look-uptables (LUTs), logic cells, and DSP slices and additional Block RAM capacity. It also hosts a processing system, which can be clocked up. Furthermore, it includes DDR4 DRAM in addition to a on-chip RAM. Lastly, the main module includes a real-time processor unit, with clock up, and a Graphics Processing Unit. Hence, it offers extensive processing capabilities to facilitate theimplementation of artificial intelligence and / or machine learning algorithms, UUV control and navigation logic, and advanced security and encryption algorithms, among others. Finally, the main model also supports a rich set of I / O peripherals, including interfaces (such as Ethernet, USB, UART, CAN, EBI / EMI, I2C, MMC / SD / SDIO, and SPI), and 180 GPIO pins to enable connectivity with virtually any sensors, data converters, and memories, as well as interfacing with UUV units.

[0065] The WMM’s converter module includes an analog-to-digital converter (ADC) and a digital-to-analog converter (DAC) to provide an interface between the analog and digital domains. The converter module is designed to offer a large dynamic range, limit noise bandwidth, and enable oversampling with the help of fast converters. On the receiver chain, it relies on an mutichannel ADC. On the transmitter chain, it incorporates a DAC. To avoid large noise bandwidth and aliasing of the high-frequency interference, the converter module includes an anti-aliasing fdter based on a differential amplifier with an integrated low-pass filter. The converter module also offers differential drive capability with limited frequency response (0 to 10 MHz) and is therefore able to suppress ringing artifacts and high-frequency noise components on the generated signals. Moreover, it offers onboard connectivity interfaces for the main module. Specifically, it incorporates gigabit Ethernet and USB connectors and their driver circuitry and a microSD card interface to ease software development. The converter module also includes programming, debugging, and monitoring ports such as JTAG, UART for the SoM and configuration interfaces for the power management unit. Moreover, it also offers various onboard monitoring sensors including temperature, humidity, and pressure sensors to be used for leak detection and system health monitoring. The converter module’s form factor is optimized to fit in small spaces.

[0066] The WMM is therefore able to operate acoustically over all frequencies spanning from 1 Hz to 10 MHz; as well as with visible light (blue and green) front-ends. There currently are three separate acoustic and / or ultrasonic communication modules, each covering a different portion of the frequency spectrum (1 Hz to 10 MHz) and a visible light communication module. The WMM may therefore be configured to host one or more communication modules in parallel. The low-frequency (up to 50kHz) and mid-frequency (50kHz to 250kHz) communication modules enable transmission ranges at tens of kbit / s data rates and hundreds of kbit / s over hundreds of meters, respectively. The high-frequency communication module (250 kHz to 10MHz) can be configured to provide Mbit / s over a few tens of meters. Finally, the visible light communication module will support reliable transmission at 10 Mbit / s data rates over 50 meters in water or through the water-air interface. The communication modules may be swapped without hardware modifications, or may be stacked in parallel for multi-modal operations.

[0067] The WMM relies on an open, modular, and reconfigurable software architecture. It incorporates a custom Linux distribution that provides the capability to (i) add / update functionalities at all layers of the protocol stack; (ii) operate at every layer of the protocol stack with an option to hide the implementation details of each layer; (iii) implement cross-layer algorithmic control strategies through a structured architecture; (iv) reprogram physical layer functionalities (i.e., modulation, power, as well as switching between different physical layer schemes altogether) running on a programmable logic in real time; (v) operate with pre-defined docker profiles implementing different full protocol stack designs; (vi) operate as a full-blown software-defined acoustic or optical platform; and (vii) natively support Internet-based applications and networking tools via a Linux OS. A Driver was integrated into the Linux distribution, which enables operating the modem as a full-blown Software-Defined “Radio” (in fact, acoustic or optical) platform offering fast adaptation.

[0068] In this way, the WMM may operate as a Full-Blown Software-Defined “Radio”, thanks to its Driver, as shown in FIG. 3. This driver offers support for data streaming operations through embedded buffers and have bindings for targeted applications such as GNU Radio and MATLAB. In addition to flow control support, time-sensitive signals sourced from PL related to MAC functions can be attached to the same driver. Furthermore, control channels for PL and hardware settings can be attached to the Driver, eliminating the need for low-level register access from the operating system. The Driver design also includes a kernel module enabling data transfer between DMA and subsystems. The module connects to a standard Linux DMA Engine interface to access, transmit, and receive DMA controllers in the PL, as shown in FIG. 3. Using the developed kernel module, it has been demonstrated that multiple channels can be reliably sampled at 10 M samples / s data rates simultaneously. This feature enables the capability to implement multiple receiver functionalities in software, including maximal-ratio combining (MRC), MIMO and receive beamforming, USBL, among others.

[0069] Docker containers have also been developed on the WMM’s software architecture. With this feature, the WMM can run an application in the user space as a software package in alightweight, standalone, executable package format. With these containers, information about software implementations, runtime, system tools, system libraries, and settings can be included in the WMM. In addition, multiple containers can co-exist and run on the same processor while sharing the OS kernel. Hence, isolated processes in user space can be run simultaneously. For instance, as shown in FIG. 4, the WMM can create a JANUS profde container, which implements the JANUS standard on its physical and MAC layers and different pre-selected protocols on its network, transport and application layers. JANUS is a robust signaling method for underwater communications.

[0070] As another example, leveraging the Driver, the WMM can house an SDR profde container, operating as a full-blown SDR platform using GNU Radio and “SDR-FPGA” PL design. Overall, the docker containers allow the WMM to operate with multiple pre-implemented profdes, provide turnkey templates for users, and enable seamless transition between different functionalities.

[0071] Having tamper-resistant hardware and software is also a vital aspect for a device such the WMM, which is intended to be deployed in remote locations with connectivity and limited oversight at most times. For this reason, tamper-resistant hardware selections have also been incorporated into the WMM’s design. First, built-in physical barriers including epoxy potting and coatings on the hardware components have been incorporated to avoid physical tampering and manipulations on the device hardware. Moreover, on the main module, SoM chips with internal encryption mechanisms are used. Once enabled, this native encryption mechanism encrypts the Programmable Logic bitstream and data with an AES key and consequently blocks any unauthorized users. On the software side, a secure booth mechanism has been implemented for the OS to ensure that only authorized and unaltered firmware or software is executed during system startup. This prevents unauthorized modifications to the software, thus guarding against tampering attempts. Additionally, internal encryption algorithms and access controls have been incorporated to prevent unauthorized access or tampering with stored information. To further complement these security measures, an automatic self-testing mechanism that performs comprehensive security testing is incorporated into the system, including vulnerability assessments and penetration testing, to identify and address any weaknesses or vulnerabilities in the system.

[0072] The WMM, as previously described, may be incorporated into a base station that combines the WMM with a modular buoy, where the base station may provide RF communication capabilities through WiFi, LTE, 5G, or satellite communication means. The base station therefore serves as a communication hub between static and mobile underwater nodes equipped with one or more WMMs, as shown in FIG. 1. Each underwater device connects with the base station, which processes and relays data to the appropriate receiving destination within the underwater network or within a terrestrial network through the base station’s RF communication capabilities.

[0073] The base station may have two main components: (i) a mechanical structure that provides the buoy with prolonged and secure flotation, which includes a casing that safeguards the buoy’s electronic systems, and (ii) an embedded electronic system that provides onshore users with connectivity and vital information regarding the buoy’s status and the operational conditions of any connected WMMs.

[0074] In embodiments, the buoy’s mechanical architecture is designed to maintain operational conditions under moderate to severe ocean and weather conditions over extended deployment periods. For example, the buoy may be designed to be (i) mechanically robust against waves and currents, (ii) water and moisture resistant in the presence of waves and precipitation, and (iii) UV and heat resistant to cope with extended hours of direct and indirect sun exposure. In some embodiments, the buoy may have an external circular structure that consists of two half circles that are securely mounted together to house the electronics. In some embodiments, the buoy has an outer diameter of between 0.5 m to 1 m, thereby ensuring optimal balance and weight distribution to prevent capsizing. Each layer incorporates four strategically positioned spokes that reinforce the connection between the larger outer circle and the section responsible for enclosing the electronics. One end of each spoke is welded to the outer circle, while the other end is attached to a structure for housing an adapter, the adapter being sized and shaped to accommodate enclosures and clamps for securing mechanical and electronic components to the buoy.

[0075] The electrical architecture of the buoy may be designed to provide direct remote access to the WMM, in addition to providing expandable computational and power resources. The electrical architecture may include four modules, as shown in FIG. 5, which include (i) a processing module, (ii) a RF module, (iii) a sensor module, and (iv) a power module. Theprocessing module provides the buoy with computational capabilities through an on-board processor, where operations such as sensor data collection and processing are performed. The processor also connects the RF module to connected underwater devices (i.e., nodes), which enables direct remote access to the deployed underwater device network.

[0076] In embodiments, the processing module may include additional components that provide the buoy with additional computational and storage resources. For example, a powerful Intel NUC processor (and, as needed, additional computational capabilities) may be implemented to provide the necessary resources and software framework to provide the necessary capabilities to run data analytics and control the base station, in addition to executing AI / ML algorithms for inference and control applications.

[0077] The RF module therefore enables the buoy to wirelessly connect and be controlled using standard RF technologies (e g., Starlink, WiFi, cellular networks, satellite networks). The RF module may also be equipped a long range, low power device which may serve as a wake-up radio. In this way, the low power device is always active and may turn on the high power components of the RF module as needed.

[0078] In some embodiments, the RF module may incorporate an iridium satellite transceiver module to extend the connectivity capabilities of the buoy.

[0079] The sensor module provides an interface for different sensors through standard digital interfaces, such as a serial peripheral interface (SPI), pulse- width modulation (PWM) interface, I2C interface, and serial interface. The sensor module may provide real-time information on the state of the buoy, such as the GPS position or ambient humidity, while also permitting seamless integration of new sensors.

[0080] The power module houses a central battery unit and a solar panel that together guarantee long periods of autonomy when the buoy is deployed. The module may also house a solar charge controller that prevents over-charging and over-discharging of the battery and voltage regulators, and electric switches that power the other components on and off while performing energy-saving when possible.

[0081] In embodiments, the buoy’s processing and software modules may access different applications and functionalities of the WMM(s) via a remote network using IP addresses and one or more RPC servers. Different RPC serves may be implemented to support various applications and functionalities of the buoy, including but not limited to data streaming, sensor data reading,configuring, and transferring or receiving large sets of data using the WMM as a network interface. The interface may be capable of handling multiple RPC servers that can handle different applications simultaneously on individual ports.

[0082] Each WMM may be integrated with a form-factor offering connectivity to bridge the buoy network with a master server over a secure connection. In this way, the real-time connectivity to underwater assets is consistently improved and may enable different applications and functionalities in view of the improved connectivity, including but not limited to video streaming from an underwater asset.

[0083] The buoy connectivity system may leverage time, frequency, and space diversity to offer efficient communication services to various underwater assets. The connectivity system will (i) guarantee efficient use of the available channel capacity despite the slow underwater acoustic signal propagation speed (i.e., 1500 m / s), (ii) minimize the amount of handshaking and control packets necessary to increase overall network throughput, (iii) obtain enhanced spectral efficiency by allowing multiple users to share the same frequency channel, (iv) guarantee minimal co-channel interference between different nodes to reduce interference and obtain better signal quality, (v) achieve improved energy efficiency by minimizing the overhead and focusing transmission energy to specific spatial regions, and (vi) provide seal ability to a growing number of devices in underwater networks without significantly impacting the system’s performance.

[0084] In embodiments, a link layer is provided which enables underwater network connectivity in a “plug-and-play” fashion. The link layer may specify both a medium access control (MAC) protocol, as well as the processing of the data and control frames with the goal of maximizing some predetermined metrics. At the link layer, the network may be logically organized in a centralized topology so that a central access point will coordinate access from multiple terminals and allocate resources. The network will have support for both fixed and mobile nodes. The presence of mobile nodes in the network, such as autonomous underwater vehicles (AUVs), or node simply moving because of the motion of the water, can rapidly change the topology, propagation delays, resource demand and their availability in the network. The central access point will therefore be tasked with specific access control functions, including the identification of new nodes requesting access to the network, and nodes departing from the network, calculation and reallocation of the available resources. Because wireless communications underwater may also be affected by issues such as packet collisions and the“hidden terminal” problem, protocols designed to specifically mitigate these inefficiencies may be implemented in the network, such that the access point is responsible for collision resolution and scheduling. In embodiments, an automated procedure will enable access points to recognize a node and add said node to the network, or remove the node when it is no longer connected, without the need for physical configurations or human intervention.

[0085] Propagation delay may also be a major cause of latency, especially in underwater acoustic networks where propagation of signals is six orders of magnitude slower that in air, which ultimately impacts transmission efficiency and makes traditional MAC protocols unsuitable for underwater applications. However, mobility and signal propagation may be improved by implementing a specialized structure of the superframe of the MAC protocol that may include a controller with access to additional information for new nodes, and by dynamically reserving time slots for incoming nodes and reassigning unused resources accordingly. This cross-layer protocol utilizes information on the topology and mobility of the underwater network to optimize access and allocate resources among the nodes, and this information may also be processed to extract speed, mobility patterns, and trajectory of mobile nodes to calculate the probability of collisions and put in place scheduling algorithms that reduce contentions, and consequently, energy consumption. The scheduling algorithms may also maximize channel utilization, assigning nodes to channels depending on propagation delay, speed, and traffic.

[0086] Energy saving and power management may also be critical, with three major causes of energy overconsumption being (i) collisions and consequent retransmissions, (ii) long idle listening due to slow signal propagation and overhearing of packets destined to other nodes, and (iii) overhead control messages needed in MAC protocols to coordinate the nodes. To address these challenges, a hybrid approach may be implemented that utilized both contention-based and reservation-based MAC protocols. A trade-off between overhead control messages, energy required for listening to the channel exchanging control messages, collision probability, will be estimated by the access point to determine which protocol to adopt in each specific situation. Each protocol will include a sleep mechanism, and in some cases a wake-up solution, for the nodes to reduce energy consumption. A contention-based MAC mechanism, such as slotted CSMA / CA, may be used in case of high mobility scenarios, since it is more scalable and robust to topology changes. Control messages including ready-to-send (RTS) and clear-to-send (CTS)will be adopted to reduce collisions depending on robustness, energy consumption, and latency requirements. A reservation-based protocol, like TDMA and FDMA, may be used to improve the throughput and reduce collisions in scenarios of heavy traffic and low mobility, because they require deterministic information on transmission delays and FDMA is less efficient in case of doppler created by moving nodes. The access point may automatically choose the approach that optimizes quality of service (QoS) metrics, such as throughput, reliability, delay, or other chosen metric, depending on the traffic load, number of active nodes, type of traffic, mobility, energy restrictions, and channel capacity. Besides time and frequency diversity, beamforming techniques will be used to create spatial diversity and transmit signals in the direction of specific nodes, limiting co-channel interference, while increasing the channel utilization efficiency.

[0087] Robustness will be guaranteed using one or more traditional link layer error detection and / or correction solutions. An automatic repeat request (ARQ), i.e., an error-control mechanism that utilizes acknowledgments (ACK), negative acknowledgments (NACK), and timeouts may also improve the reliability of data transmission over communication links. Redundancy in the form of forward error correction (FEC), error correcting codes, and checksums may also be adopted to improve robustness.

[0088] This hardware and software architecture may be used to implement various functional modules that can be deployed to achieve various navigational, sensing, and / or communication functionalities.

[0089] In embodiments, the base station may include an underwater navigation and positioning system. In addition to serving as a wireless underwater access point and a gateway between underwater and land networks, the base station may provide real-time navigation and location services for all static and mobile underwater nodes equipped with WMMs. This may be accomplished by incorporating an Ultra-Short-Baseline (USBL) method into the existing WMM Janus protocol. In embodiments, the waveform may consist of a series of 0-20 ms-long tonals, pseudo-randomly placed throughout a frequency band of under 50 kHz, centered at about 5-100 kHz. The initial portion of the waveform consists of a series of between 5 and 100 tonals (or “chips”) that are used for acquisition and alignment in time and frequency by the receiving modem.

[0090] The USBL unit may include a transducer array that incorporates a plurality of hydrophone transducer units. The array elements may be separated from each other with adistance larger than half the wavelength size of the smallest operating frequency (i.e., approximately 10 cm for 8 kHz operating frequency to obtain spatial diversity. In addition to the transducer placement and appropriate array configuration for achieving optimal signal reception and performing DOA estimation, selecting high-quality transducer / hydrophone units plays a vital role to enhance the accuracy and reliability of the system. To that end, a spherical, semilunar, disk, cylindrical, unidirectional, omnidirectional, or bidirectional (or a combination thereof) hydrophone may be used which offers a broadband receiving sensitivity in a relatively small form factor.

[0091] To obtain optimal navigation and positioning results with minimum measurement error from a USBL system, it is vital to also integrate a Motion Reference Unit (MRU). The MRU provides precise information on the motion and orientation of the vessel or platform that carries the USBL system, leveraging a combination of accelerometers, gyroscopes, and magnetometers to measure linear accelerations, angular rates, and magnetic field strength. To that end, an MRU may be integrated in a manner that compensates for the motion-induced errors when the base station experiences heavy movements. These motions can significantly impact the accuracy of the USBL measurements, especially when trying to precisely track underwater static or mobile nodes. Data may therefore be fed from the MRU unit into the USBL’s DOA estimation algorithm for the base station to accurately estimate the position of each underwater network node, mobile or static, even in dynamic marine environments. The MRU data may therefore to correct for base station’s motion, providing the necessary compensation to ensure precise positioning of the underwater wireless nodes.

[0092] In embodiments, the base station may include a module for visible light trans-mission through the water-air interface. The visible light communication module for the WMM may be connected to the system without any modifications of the main hardware modules. The visible light communication module may reliably achieve 1-20 Mbit / s links through the water-air interface. It is based on light emitting diodes (LED) driven by a single n-channel. MOSFET with common source topology with source degeneration are used as the transmitting source. This voltage controlled current source drives four LEDs that are connected in series. Such LEDs can emit red light, blue light, white light, tallow light, or any color or frequency (wavelength) type light in the visible spectrum. Thus, each LED outputs an average power of 1-10 W, with typicalradiant flux determined by the wavelength of the light of a power driving the visible light signal (100-200 mW).

[0093] On the receiver chain, photodiodes are used. The photodiodes have built-in transimpedance amplifiers, whose gains can be controlled digitally by the main module to obtain gain values between 0-10 dB. A photodiode was chosen because of its excellent responsiveness in the blue light range of 450-480 nm, as well as its wide transimpedance bandwidth of 400 MHz. In some embodiments, the visible light communication module is further optimized by increasing the number of LED units as well as their average output power level. The beam width of each LED unit may also be manipulated (i.e., between 120° to 15° for the current LED units) to achieve different overall beamwidth of the transmitter unit. This manipulation may be done either in a fixed fashion by integrating 35mm optics and / or reflectors, or in a dynamic way by leveraging voltage controlled diffusers. The WMM’s visible light front-end may therefore be able to trade beamwidth for range and signal intensity.

[0094] In embodiments, the WMM includes a modular software architecture to enable various functional capabilities including (i) adding and / or updating functionalities at all layers of the protocol stack, (ii) implementing algorithmic cross-layer control strategies through a structured architecture, (iii) reprograming and redefining the physical layer functionalities (i.e., modulation, coding, power, as well as switching between different physical layer schemes altogether) running on a programmable logic in real time, (iv) operating with pre-defined docker profiles implementing different full protocol stack designs, and / or (v) operating as a full-blown software-defined radio (SDR) platform. These capabilities enable real-time adaptation and waveform agility, which is critical to provide robust communication links with optimal performance, at all times, through the temporally and spatially varying air-water interface.

[0095] The air-water interface inherently experiences highly volatile channel conditions caused by water surface waves, turbidity, turbulence, background noise, among others, meaning that often the channel may be contested. Thus, the ability to seamlessly switch between different waveforms makes the system robust to environmentally and operationally imposed changes. A cognitive and adaptive communication system such as that described herein can take advantage of multiple waveforms and select — automatically or based on policy — the optimal waveform to cope with the current channel conditions and operational requirements. The WMM maytherefore offer the ability to incorporate further algorithmic developments to improve performance through software updates.

[0096] In some embodiments, a carrierless amplitude and phase modulation (CAP) based communication protocol may be implemented. CAP is a spectrally efficient multi-carrier modulation scheme, which may be configured to navigate the trade-off between spectral efficiency and BER performance by controlling parameters (including span, samples-per-symbol (SPS), and roll-off factor, among others). This trade-off enables implementation of algorithmically optimized communication links based on the channel conditions and operational requirements. CAP modulation may also be scaled into a multi -band CAP (m-CAP) scheme, which is established by summing multiple CAP waveforms with pulse-shaping filters at different center frequencies. The m-CAP may also provide an additional solution space which can provide tailored algorithmic solutions depending on need.

[0097] On the transmitter side, each incoming binary data bit is mapped onto M-QAM constellations. The in-phase and quadrature components are filtered with a root raised cosine (RRC) filter, which is multiplied with cosine and sine functions, respectively, for each component of this complex symbol. These filters form a Hilbert pair that is orthogonal with the same amplitude and a phase difference of 90°. After filtering, both components are summed, and a DC bias is added to the signal, which can then be transmitted using LEDs. The sum of these signals results in a real-valued waveform, which can be transmitted through appropriate DC bias via VLC front ends.

[0098] On the receiver side, upon receiving the intensity-modulated signal through the visible light channel, the real-valued signal is once again filtered. These two parts may then be superimposed to form the complex signal, which is then down sampled and decoded using the relevant M-QAM scheme. For the m-CAP, the same principle can be applied by only adjusting the center frequency of the filters and then superposing the resulting waveforms for each subband.

[0099] In some embodiments, all transmitter and receiver flowgraphs are implemented by defining new or customizing existing communication building blocks. This may be achieved by leveraging the GNU radio driver, which offers an extensive collection of available building blocks and ability to create new custom blocks easily for implementing customized communication schemes. This versatility enables the straightforward deployment and testing ofnovel communication protocol on the WMM. Algorithmic mechanisms may therefore be implemented to optimally select communication protocol parameters, leveraging the closed-form expression under different signal-to-noise ratio (SNR) conditions for the CAP modulation implementation. This closed-form expression thereby enables implementation of a parameter selection algorithm to maximize spectral efficiency at a given SNR value while satisfying a maximum acceptable bit error probability by selecting span, samples per symbol, roll-off factor, modulation order, and number of sub-bands.

[0100] The software and hardware architectures may also include features to facilitate integration of the WMM with underwater and airborne devices, such as unmanned underwater vehicles (UUV) and / or unmanned aerial vehicles (UAV).

[0101] In embodiments, the WMM may have a dual connection to the UUV’s main body. The dual connection may include a cable that draws power from the main battery, in addition to a data cable providing communication connectivity. The data cable may connect the standard Ethernet interface of the WMM to a companion computer. By utilizing a companion computer as a bridge between the on-shore hardware and the WMM, the tether cable establishes connectivity between the UUV, the WMM, and the ground station (i.e., on-shore hardware).

[0102] In embodiments, the WMM utilizes an open interface to connect the software architecture of the WMM with a UUV and / or a UAV, as shown in FIG. 6. The open interface may utilize an open source protocol buffer as a primary data structure and interfacing protocol for the WMM. In preferred embodiments, the protocol buffer is selected to include features such as language independence and cross-platform compatibility. The data structures may be serialized into specific files, which define the format for exchanging serialized data, including definitions for messages (representing objects in the application and defining data types for the exchange format) and services (which are callable functions that can be implemented either locally or remotely, utilizing message definitions as arguments and return types).

[0103] While protocol buffers facilitate efficient cross-platform data exchange, another software layer may be required to handle requests and connect services to user applications. Remote procedure call frameworks, which offer built-in support for the protocol buffers, may be implemented to this end. The remote procedure call framework implementation may provide automatic generation of servicer and stub functions for the server and client applications using the remote procedure call framework compiler. These functions act as intermediate layersbetween the user application and the network, which handle the conversion of incoming and outgoing data types, route requests, and responses to and from user functions.

[0104] The implementation of the aforementioned software systems may enable plug-and- play integration of UUV units with the WMM, which may empower the main computing boards of the UUV units to access the various applications and functionalities provided by the WMM over the network, utilizing the IP addresses and port numbers of the RPC Server.

[0105] In some embodiments, tailored RPC servers are implemented, these servers being capable of supporting a wide range of applications and functionalities, including, but not limited to, sensor data reading, configuration of parameters and designs at all layers of the protocol stack, and the transfer or reception of data using the WMM as a network interface. In some embodiments, multiple RPC servers designed for different applications may run simultaneously on the WMM, while each operating from distinct ports. This may in turn enable seamless interfacing with different applications on the WMM concurrently.

[0106] In embodiments, the WMM may also include hardware that provides a comprehensive range of standard analog and digital interfaces for seamless connectivity with UUV assets. Given its high-speed connectivity, it is often preferable to leverage the ethemet interface, which may be facilitated using two different approaches. In some embodiments, where the WMM is integrated as a standalone unit, the ethernet interface may be integrated through rugged cables and connectors which are specifically built for reliable underwater applications. In other embodiments, when integrating the WMM as a module within a UUV, standard ethernet twisted pair cables are utilized. In either embodiment, the WMM may be mechanically housed and attached within the UUV asset, ensuring a compact and efficient integration process.

[0107] In embodiments, UAVs may be integrated through use of a software development kit (SDK), which enables smooth communication with a flight controller using a set of application programming interfaces (APIs). As a result, the integration of the SDK provides real-time and agile updates to the UAV’s flight mission, allowing for swift and real-time adjustments to the flying mission by reading data from one or more sensors and setting specific GPS coordinates that the UAV needs to visit. This capability enhances the UAV’s flexibility and responsiveness during its operations.

[0108] In embodiments, a similar open source framework to that described with respect to UUV integration may be utilized for integrating a WMM with UAVs. A WMM may bephysically attached to a UAV using a gimbal stabilizer, which may prevent distortions and misalignment on the visible light communication (VLC) links caused by the UAV’s movements, while also providing the capability to mechanically manipulate the VLC beams generated by the WMM. The UAV and WMM may be physically connected with a twisted pair ethernet connection, similar to that used for UUV integration.

[0109] In embodiments, UUVs and UAVs may also be linked together. The WMM is uniquely capable of establishing a reliable, bidirectional communication link over the air-water interface using visible light modality, even under varying conditions.

[0110] In embodiments, multiple devices, including but not limited to one or more UUVs and / or UAVs, may be integrated with the WMM as a single input multiple output (SIMO) system. By leveraging spatial diversity created through distributed SIMO systems, the channel capacity and coverage area for mobile and / or fixed communication nodes may be increased, which is particularly advantageous in scenarios with high interference, fading, or blockage within the communication channel. That is, rather than relying on a single communication link, the collaborative operation of distributed SIMO systems can mitigate interruptions for mobile communication nodes and establish robust communication links. The SIMO system may be configured to allow for the reconfiguration and optimization of distributed modems in a cellular network such that, depending on the channel conditions, the plurality of WMMs may be instructed to perform different tasks or participate in the SIMO system to achieve improved communication links. Furthermore, the SIMO system improves scalability, such that SIMO systems offer the potential for enhanced communication reliability and performance by incorporating more receiving nodes into the system. This scalability ensures that the system can be adapted to varying requirements and provide optimal performance in different deployment scenarios.

[0111] In some embodiments, the WMM also includes a swarm control framework, which may enable control of mesh networks of heterogenous nodes (i.e., surface and underwater modules) in an automated and flexible fashion, where the nodes are provided in a distributed, interference-prone, non-stationary, and potentially adversarial environment. The swarm control network may provide a centralized control framework to define network control objectives through a high level API, and through this framework, the network operator may program theoverall network behavior without a prior knowledge of the network topology, UUV and / or UAV mobility patterns, or the details of the distributed control implementation.

[0112] In some embodiments, the swarm control may create a centralized representation of a control program, and then may automatically generate distributed control programs to be executed at each individual network node. Through distributed control actions, the swarm control may then implement self-organizing and coordinate UUV and / or UAV network control algorithms that dynamically adapt to location and network state changes, which ultimately guarantees reliable communication and connectivity with minimal human intervention. The swarm control may therefore provide a principled software-defined approach to jointly and seamlessly control networking and motion functionalities for UUV networks. More specifically, the swarm control may provide a unified abstraction of the networking and motion functionalities that enables the definition of complex network control problems.

[0113] In embodiments, the swarm control has two key components: a control framework interfacing the network operator at a centralized location, and an unmanned vehicle programmable protocol stack (UV PPS) executed at each UUV and / or UAV.

[0114] The control framework, or control interface, may be used to implement any interaction within the network operator (NO), which may often consist of a set of high-level APIs and / or protocol libraries. The control interface may provide the network operator with an abstraction of the UAV network hiding the low-layer network functionalities and details of the underlying network architecture, e.g., the number of UAVs as well as their computing capabilities and battery level. Through the control interface, the NO may express directives defining (i) the desired network behavior (e.g., maximize the network throughput, minimize network power consumption), (ii) which layers of the protocol stack to involve in the optimization process and which protocols to implement at each layer (e g., the NO might want to use a specific MAC protocol but it is willing to optimize motion, routing, and transmission power strategies), and (iii) node and layer specific constraints and QoS requirements (e.g., UUV maximum transmission power, depth, transmission rate, or a combination of them). Examples of high-level objectives include maximizing the end-to-end network throughput, prolonging network lifetime by minimizing energy consumption and covering a particular water space, among others.

[0115] In some embodiments, implementing a network control problem may be necessary for distributing control of a UUV and / or UAV network. Once the optimized problem has been defined (e.g., maximizing the overall network throughput), the swarm control may then convert the network operator directives and requirements into a set of mathematical expressions, which may then be rearranged in the form of a network control problem. The resulting network control problem therefore serves as a centralized representation of the high-level network behavior defined by the network operator through the control interface spanning both the networking (e.g., transmission power, routing policies, session rates) and the UUV and / or UAV control domains (e.g., mobility patterns, speed), involving multiple nodes and all layers of the protocol stack.

[0116] In some instances, solving the resulting network control problem may become challenging when a central controller lacks access to time-varying network state information, such as UUV and / or UAV locations, routing paths, and interference levels. In an infrastructureless scenario, the overhead and delay in retrieving this information may lead to inefficient and sub-optimal network solutions. Additionally, the cross-layer nature of the network control problem and the interdependencies among its variables, such as end-to-end session rate, link capacities, and UUV and / or UAV mobility, pose difficulties in computing desirable solutions in a distributed fashion. To that end, the swarm control may leverage decomposition theories to “loosen” the coupling among optimization variables and generate a separable-variables version of the network control problem to be decomposed. The outcome of this procedure is a set of independent sub-problems that can be solved at individual network nodes by exchanging local information with the neighboring UUVs and / or UAVs.

[0117] First, the swarm control may parse the objective function and the constraints of the constructed network control problem to detect the optimization variables and parameters involved in the optimization problem. In this way, the swarm control may assign variables to protocol layer functionalities to be optimized (e.g., transmission power, UUV location, routing tables), while network state parameters (e.g., channel gain coefficients, noise level) and variables excluded from the network control problem optimization are treated as constants.

[0118] The swarm control may then loosen the coupling between optimization variables of the network control problem. To that end, swarm control may generate a layered coupling graph summarizing which network nodes and network layers have control over which optimization variables. In this abstract representation, vertexes are optimization variables of the networkcontrol problem and are associated to a specific layer and a specific node (e.g., transmission power belongs to the physical layer of transmitters and relays), while edges are coupling relationships between variables of the problem. Through this abstract representation of the network control problem, the framework will be able to use various tools to relax the coupling among variables into cross-layer penalization terms. The decomposition process may also produce a separable-variable version of the network control problem that can be decomposed into independent sub-problems solved at individual UUVs and / or UAVs through distributed control actions.

[0119] Lastly, the swarm control may generate and distribute the numerical solution algorithm to each node. For each of the decomposed sub-problems, an algorithm (e.g., sequential quadratic programming) will be automatically generated to calculate the numerical solution associated with a given network control variable. Each algorithm will be then translated into an executable script where variables and parameters appear as keywords in text format. Nodes will employ the library to interpret keywords (e.g., whether a specific keyword is a variable to be optimized, a network parameter or a penalization term) and will replace them with real-time numerical values (if parameters) or computed numerical solutions (if optimization variables). The resulting scripts will be executed to compute optimized numerical solutions for the networking and guidance control functionalities.

[0120] In some embodiments, a UV programable protocol stack (UV PPS) may be implemented to fully realize the potential of the swarm control framework. The UV PPS may be installed with each individual UUV and / or UAV to solve the numerical solution algorithms received from the control framework in an automated and distributed fashion. To achieve this, docker containers, as previously described, may be utilized. More specifically, the UV PPS may be implemented as a container profile that can be installed on a WMM, which will leverage the open interface architecture of the WMM to send and / or receive control commands to and from the UUV and / or UAV units. To compute a desirable network operating point, each individual UUV node may execute the distributed optimization solution algorithms generated by the control framework with up-to-date and accurate network state information. The computed numerical solutions may then be implemented at the network protocol stack and the flight controller.

[0121] In some embodiments, the UV PPS may be organized in three tightly interacting planes: a decision plane, a register plane, and a data plane, as shown in FIG. 7.

[0122] Upon receiving the distributed numerical solution algorithms generated by the control framework (e.g., motion solution algorithm, transport rate solution algorithm), the UV PPS may run the algorithms in its decision plane. This plane will contain a Protocol Repository with the software implementations of different network protocols and motion, together with the mathematical solvers to run the dispatched scripts. The decision plane may run the distributed optimization algorithms in real-time based on up-to-date network state and motion information as input parameters (e.g., noise power, queue status, UUV locations). Such information will be retrieved from the register plane, which will be also employed to store the computed numerical solutions.

[0123] The data plane may be responsible for implementing the computed optimal solutions by reconfiguring the networking and control operating parameters. To facilitate this, the data plane may incorporate a fully programmable and reconfigurable protocol stack that spans across all networking and motion layers. This protocol stack will be serving as a foundation, providing the essential building blocks and primitives needed to prototype intricate cross-layer and crossdomain network protocols and motion strategies. By leveraging this programmability, the data plane may enable comprehensive control over network, sensing, and motion parameters at every layer of the protocol stack. The control interface between the protocol stack and the distributed solution algorithms may be defined so that (i) the solution algorithms can retrieve network state information from the data plane through the register plane (e.g., noise and interference power level, queue status, node location, among others), and use it as input parameters of the distributed optimization problems, and (ii) based on the optimized solutions, the UV PPS configures the networking and motion parameters of the adopted protocol stack in the data plane.

[0124] The register plane may act as a middleware allowing the decision plane to retrieve fresh network state information from the data plane, and may be responsible for making the computed optimal solutions available to the data plane through a set of dedicated look up tables (LUTs). Each protocol stack layer will have a dedicated network state LUT in the register plane, where all the layer-related network state parameters may be stored.EXAMPLES

[0125] It will be understood from the foregoing description that various modifications and changes may be made in the various embodiments of the present disclosure without departing from their true spirit. The description provided herein is for the purposes of illustration only andis not intended to be construed in a limiting sense. Thus, while the presently disclosed inventive concepts have been described herein in connection with certain embodiments so that aspects thereof may be more fully understood and appreciated, it is not intended that the presently disclosed inventive concepts be limited to these particular embodiments. On the contrary, it is intended that all alternatives, modifications, and equivalents are included within the scope of the presently disclosed inventive concepts as defined herein.

[0126] Thus, the examples described herein, which include particular embodiments, will serve to illustrate the practice of the presently disclosed inventive concepts, it being understood that the particulars are shown by way of example and for purposes of illustrative discussion of particular embodiments of the presently disclosed inventive concepts only and are presented in the cause of providing what is believed to be a useful and readily understood description of procedures as well as the principles and conceptual aspects of the inventive concepts. Changes may be made in the construction and formulation of the various components and compositions described herein, the methods described herein, or in the steps or the sequence of steps of the methods described herein without departing from the spirit and scope of the presently disclosed inventive concepts.Example 1. Development of the Hardware Architecture

[0127] A multi-scale simulator that evaluates waveforms and communication schemes at different levels was developed. These different levels include, but are not limited to, at the wave level by modeling acoustic propagation in selected reference scenarios, and at the bit level by simulating the waveforms / communication schemes. This simulator is capable of simulating Littoral and Deep-Sea Ocean Channels, simulating the Doppler effect caused by relative mobility between TX and RX (which is critical for UUV scenarios), surface waves, reflection from nearby structures and surface scattering, and emulating actual channel responses collected from experiments.Design and Testing of a Main Module

[0128] A main module based on a System-On-Module (SoM) was developed, incorporating an advanced processor chip. The new main module features 1-10 micro headers mating with the converter module that facilitates interface to the rest of the HydroNet WMM. It incorporates a programmable logic (PL) section, which has up to 1-100 look-up-tables (LUTs), 1-500 logic cells, and 1-1000 DSP slices in addition to a 1-10 Mb of total Block RAM capacity. The newmain module has a processing system, with a multicore processor, which can be clocked up to 1.5 GHz. It also includes DDR4 SDRAM in addition to an on-chip RAM. The new main module also includes a multicore real-time processor unit and a Graphics Processing Unit (GPU). Hence, it can offer additional processing capabilities to facilitate implementations of new features such as artificial intelligence and machine learning algorithms, UUV control and navigation logic, advanced security and encryption algorithms, and more. Finally, the new main module can support a large set of interfaces including but not limited to 50-500 GPIO pins for enabling connectivity with virtually any sensors, data converters, memories, and other systems. Overall, the new main module offers a rich set of features and immense processing capabilities relative to its small form factor.

[0129] Moreover, all the required hardware- software interfaces for the new main module have been developed and tested. More specifically, a board support package (BSP) was developed, which allows software developments to be abstracted from the hardware platform itself and accordingly enables the configuration of peripherals such as Ethernet, USB host, SD card controller. All interfaces have also been defined and tested, including USB 2.0 / 3.0 micro- AB connector, 10 / 100 / 1000 Mb / s RJ45 connector, microSD card connector, UART, 12 PL (programmable logic) headers, and 1 PS (processing system) header.Design Fabrication, and Testing of a Converter Module

[0130] In the design of the new converter module, dynamic range, limit noise bandwidth has been preserved, while enabling oversampling with the help of fast converters. To that end, on the receiver chain, analog-to-digital converter is used, a multi-channel ADC. On the transmit chain a DAC has been incorporated. The analog bandwidth of the selected ADC unit (0 - 315 MHz) is significantly larger than HydroNet WMM’s operational range (0 to 10 MHz) which makes the ADC unit susceptible to larger noise bandwidth and aliasing of the high-frequency interference (which could be typical in a digital circuit in such system). To address these issues, an antialiasing filter based on a differential amplifier with an integrated low-pass filter has been included. On the transmitter chain, the DAC unit requires a circuit that converts the current output to voltage. This circuit is designed to have differential drive capability with limited frequency response (0 to 10 MHz) and therefore suppress ringing artifacts and high-frequency noise components on the generated signals. Moreover, in this new converter module, onboard connectivity interfaces for the new main module are included. Specifically, gigabit Ethernet andUSB connectors and their driver circuitry and a microSD card interface are used to ease software development. Programming, debugging, and monitoring ports such as JTAG, UART for the SoM and configuration interfaces for the power management unit are also included.

[0131] The converter module also was designed to have various sensors on-board for monitoring purposes. Temperature, humidity, and pressure sensors are integrated to be used for leak detection and system health monitoring. All these sensors are attached to an I2C bus of the SoC processing system where Linux Kernel drivers have been developed for each of them. There is a secondary I2C bus on the module that is separated by a bus switch on the main module which is routed to communication modules through the board-to-board connector. This provides electrical isolation for the slave nodes on the converter module which may be used to adjust analog settings such as amplifier gain and filter response. Furthermore, in this new converter module design, a power section has been incorporated to address the sophisticated power requirements of the new main module. For instance, the ADC is tied to high performance input / output ports that require a lower voltage. These bundles of ports are called banks and currently, the converter module produces five different voltage rails and powers six different banks. To satisfy these requirements in a small board area, a power management unit integrated circuit is utilized. The selected IC can generate multiple voltage rails efficiently and it can be customized through a programming interface. Using this interface, it is possible to monitor power consumption, or turn off some of the rails for a system level low power mode. In addition to this unit, we have implemented a -5V regulator, which is required for the DAC, with a cascaded inverter and a low noise low drop out regulator.

[0132] The functionality of the converter design was also tested and verified, in order to further characterize its performance. Testing began from the JTAG interface, which is frequently used for FPGA development for debugging and programming purposes. A JTAG-HS3 cable was connected to the port on the converter module and verified that the FPGA development environment can detect the SoC. Moreover, we have programmed the FPGA was programed, and an integrated logic analyzer (ILA) was used over this interface. The SD Card interface was also tested, and functions properly with correct jumper settings on the main module. In this test, contents from a micro-SD card were able to load and boot into the operating system. An external UART- USB bridge was also tested to verify UART headers on the converter module. Boot messages were able to be printed, and interactions with ARM trusted firmware and U-Bootbootloader were possible over this interface. The interface is crucial for low (kernel / driver) level software development. The functionality of the Ethernet interface was verified by initiating a secure shell connection to the modem after the boot up sequence. The cooling fan and SOC temperature monitoring functions were also tested. The SoC temperature can be monitored using a platform cable. Moreover, the real time clock (RTC) of the main module was tested. The real time clock on the main module has a backup power source for timekeeping when the module is not powered on. This power rail is connected to a circuit on the converter module that uses an LR44 battery. To verify this circuit, the software clock was first programed using network time protocol (NTP) and committed the clock to the SoC RTC. The system was powered down, the battery was detached, and allowed to sit for one hour. At next boot sequence, the software clock was updated from the RTC, and the clock was correct.

[0133] Overall, the converter module’s form factor is optimized.Design, Fabrication, and Testing of Swappable / Stackable Communication Modules

[0134] Developing front ends and transducers that can operate over all frequencies spanning from 1 Hz to 10 MHz with the same efficiency is still an open problem. One of the main challenges is the lack of PAs and transducers that can operate in such a wide range of frequencies while preserving a flat response. To address this problem, multiple communication modules covering different portions of the acoustic and / or ultrasonic frequencies were built. Optical and visible light front ends were also built. Each of these communication modules are swappable or can be integrated as multiple front ends to operate simultaneously. In this way, the modem can support MIMO and multi-modal operations.Example 2: Development of the Software Architecture of the HydroNet WMMDesign of the HydroNet Software Architecture

[0135] A custom embedded system for the platform was developed, based on an Open embedded building framework. In this way, compatibility is maintained across current and new platforms while enabling the development of the HydroNet Driver.

[0136] As a part of this integration, two layers were developed: (i) a board support package (BSP) layer for SOM; and (ii) a core layer for operating system and software development. The first layer (BSP layer) allows software development efforts to be abstracted from the hardware platform. Therefore, the developed second layer (core layer) does not need to be device specific. Currently the BSP layer consists of Linux kernel configuration fragments for the MPSoCplatform and SoM board. The software stack requirements: platform management unit (PMU) firmware, trusted firmware (TF), first and second stage boot loaders are generated by this layer. In addition, support for new SoC components such as RPU and GPU are configured here and the controller for the on-board memory (eMMC) is enabled.

[0137] The software requirements for this platform are unique and cannot be met with existing operating systems targeted for embedded platforms or network devices. Therefore, a custom Linux distribution, “ HydroNet OS”, for HydroNet WMM is created in the core layer. HydroNet OS is branched from the OS developed for the current platform which has a set of development packages, network, and connectivity tool. Notable additions to the software packages are GNU Radio; driver packages and software tools for IIO and DMA; core X window system components to allow graphical interfaces over SSH connections. The HydroNet Kernel Module is also embedded into the HydroNet OS.Open Interface Integration into the HydroNet WMM's Software Architecture

[0138] Open source Google Protocol Buffers (protobuf) were used as the data structure and interfacing protocol of the HydroNet WMM, because of its unique features such as being language independent and cross-platform compatibility. The Google Protocol Buffers are implemented to serialize data structures into special fdes called proto files. The proto files are then compiled into the source code of the target language which typically consists of classes and objects with appropriate data types available in the particular language. The default protobuf compiler is protoc which supports code generation for C++, C#, Java, Javascript, Objective-C, PHP, Python, and Ruby. Open source protobuf compilers for other programming languages are also available. Currently, protoc version 3 is installed on the HydroNet OS. The compiled proto file acts as the protobuf API for the specific structure, and the user application imports this file. The code has the bindings to produce, consume, and modify messages which are invoked by the user application to serialize and de-serialize data. The proto file defines all the relevant data structures and services supported by the HydroNet WMM.

[0139] Protocol buffers provide a language-neutral way to encode data to be exchanged between different applications and platforms. The interface definitions are declared in proto files, which are then compiled into the source code of the target language. Proto files define the serialized exchange file format and include definitions for messages and services. Messages usually refer to objects in the application and define data types for the exchange format. Servicesare callable functions that may be implemented on a remote or local application, and they utilize message definitions as arguments and return types. The HydroNet WMM supports Protocol Buffers version 3, and the runtime library, along with the Python compiler, is verified on the platform. While Protocol Buffers efficient cross-platform data exchange, another software layer is needed as a network interface to handle requests and connect services to the user applications. To provide seamless system integration, a remote procedure call (RPC) framework is chosen to provide this functionality. gRPC implementation was selected, since it offers built-in support for Protocol Buffers. The framework provides servicer and stub functions automatically generated by the gRPC compiler for the server and client applications. These functions make up the intermediate layers between the user application and the network. Specifically, they convert incoming and outgoing data types and route requests and responses to and from user functions. The RPC server attaches to the Linux TCP / IP stack and listens to a designated port for requests. Host devices such as the UUV main computer can access the server application over the network using WMMs IP address and port number of the RPC application. Multiple hosts can access the WMM over the network. The RPC server is highly customizable with multi-language support. It can be tailored to serve a variety of applications, such as reading sensor data, modifying PL configuration, and transferring data to the modem. In addition, several RPC servers designed for different applications can also run simultaneously on the WMM if they use distinct ports.

[0140] The functionality of the designed open interface is verified with an example Python application that transfers sensor data. In this scenario, the client application, which is running on the UUV unit’s main computer, can select one of the sensors on the converter module and request a reading. WMM then receives the request, gRPC stub invokes the appropriate readout function for the selected sensor. In this example, sensor read functions were accessing sensors over the sysfs interface. The user function then creates a “SensorData” object and fills its fields with values. This object is then sent back to the client as the response to the query. Overall, the client application code consists of connection establishment routine and function calls to the custom functions running on the RPC server. Server RPC code implements connection handlers (multi -threaded) and custom functions that refer to protobuf object types for its inputs and outputs.HydroNet GNU Radio Exemplary Waveforms

[0141] A ZP-OFDM transmitter and receiver running on GNU Radio was implemented, demonstrating the capabilities of the HydroNet WMM software architecture in enabling streamlined implementation of a variety of communication schemes and protocols through open- source software tools. GNU Radio provides a plethora of signal processing blocks that are implemented in C++ or Python coding languages and that can be leveraged to rapidly implement a wide range of wireless communication schemes. All the ZP-OFDM transmitter and receiver functionalities in GNU Radio were implemented either by defining new or by customizing already available communication building blocks.

[0142] Zero-padding scheme is selected due to its energy efficiency instead of other alternatives such as cyclic prefixing. With the software-defined radio paradigm, the durations of these zero pads can be adjusted according to the severity of the multipath of the communication channel. While interference of the received echoes at the receiver side can be avoided with the drawback of redundant transmission time, this leads to a lower data rate. Thus, the optimum data rate can be adjusted according to the communication channel conditions, which aims to maintain successful communication links.

[0143] At the transmitter side each packet (frame) is constructed with chirp signals (LFM) both at the beginning and ending of each packet that is used for coarse synchronization and packet detection where doppler spread is significant. With these two chirp signals generated at baseband, coarse doppler correction algorithm can be used. First LFM signal is followed by a preamble based on a pseudorandom noise (PN) sequence that precedes each packet and is used for packet detection and coarse synchronization. Finally, N number of ZP-OFDM symbols are constructed with its corresponding data, pilot, and null subcarrier size, where data subcarriers are used to allocate modulated versions of information bits that are encoded with different modulation schemes. Pilot subcarriers are allocated to pilot symbols (symbols known to both the transmitter and the receiver) and are used for channel estimation and symbol-level (fine) synchronization. Pilot and null subcarriers are used for Doppler scale estimation. The signaling scheme introduces a guard interval between each OFDM symbol to avoid inter-symbolinterference (ISI).

[0144] At the receiver side, each packet is detected with the use of correlation estimator. By correlating incoming stream with the PN sequence preamble, packet detection can beaccomplished at very low SNR scenarios. After the detection of preamble, each packet is streamed in a synchronized manner through custom implemented packet synchronization block. Each synchronized packet is demuxed to separate LFM, PN and data symbols from the incoming stream so that each data symbol can be processed individually. Data symbols that are transformed into frequency domain with a FFT block are equalized for amplitude and phase correction with using known pilot subcarrier’s symbols. Equalized symbols are converted to a stream that only consists of information bits transmitted through data subcarriers. These in-phase and quadrature (IQ) bits are demodulated according to the transmitted modulation scheme. Finally, stream of information bits can be recorded or streamed according to the application.

[0145] Both transmitter and receiver flowgraphs are generated in a hierarchical block configuration. In this way, different signal sources or sinks can be easily implemented for different applications, such as data transfer, data recording / streaming or video streaming. Similarly, different encoders / decoders or doppler correction algorithm blocks can be connected to these hierarchical blocks that can generate baseband ZP-OFDM transmission signals and decode the received ZP-OFDM streams.Implementation of The JANUS Standard on the HydroNet WMM

[0146] The JANUS Standard was implemented on the HydroNet WMM. The standard JANUS waveform consists of a 32 chip acquisition sequence followed by 144 chips which constitute the modulated portion of the signal. Each chip is T = 6.25 ms in duration, a single chip is transmitted at each baud period, and the frequency location of each chip is defined by a pseudo-random draw from a (approximately) 5 kHz band. There are Nblock *2 frequency locations available, where the available bandwidth is divided into Nblock “blocks”, each of which consists of 2 slots. The choice of slot is dictated by the binary data drawn from the (0,1). Each block consumes 2 / T Hz of bandwidth. While the carrier frequency is selectable, the Standard is specified to be 11520 Hz. The baseband sample rate is suggested as 10240 (complex) samples / sec. The signal is designed such that the chip duration results in an integral number (64) of samples in each chip, and the signal bandwidth is also fully encompassed within a power of 2 FFT.

[0147] Within a realistic application, a signal could arrive at any time, or not at all. A processing and detection method which provides both minimal delay and precision alignment in time and range rate (We use the term “range rate” (rather than “Doppler”) is required to reflectthe broadband compression / dilation imposed on a waveform subject to relative speed). The filter is a close approximation to a tonal chip but provides a small leeway for frequency offset or shift. A “50% overlap and save” technique is utilized, whereby a section of incoming time series of duration 2T is extracted. These data are transformed to the frequency domain, where, as stated, the spectral location of every possible tonal is known a priority. The single frequency-domain filter is established at a fixed spectral location (typically the middle of the FFT), and the transformed data are repeatedly shifted in frequency so that potential tonals are multiplied with the matched filter. For each such shift, the results are inverse transformed to present a new time series of duration 2T. For each section of data, there will be 32 such time-series. Following the rules of the overlap and save algorithm, the second half of each of the 32-time series is discarded. For the basic acquisition process, these 32-time series are magnitude-squared, then temporally shifted according to the known delay associated with the frequency shift. These shifted data are (non-coherently) summed, and several algorithms are employed to determine if a valid acquisition has occurred. If not, then the next section of data, beginning at T seconds after the previous, are processed in the same way. The single time series resulting from each processed section is appended to the previous, resulting in one continuous power-domain time series, with no data lost in the process.

[0148] The JANUS implementation also includes three significant additions to the acquisition portion thereof. The first, which we will refer to as “basic acquisition” includes the filtering and non-coherent summation of the 32 acquisition tonals. It also includes running statistics of the background “noise” which is produced by the filtering process prior to the arrival of the signal. These statistics are used to set a detection threshold (in terms of numbers of standard deviations of the noise above the mean noise level). Because the overlap and save technique produces its output every T seconds, we will begin to see detectable peaks arising out of the noise (at high SNR) long before the full summation of all of the chips has occurred. Therefore, it is necessary to delay the detection until both the threshold has been exceeded and the full 32 chip waveform has been processed.

[0149] The second level of acquisition processing occurs following the declaration that a signal has been detected. Here the entire 180 seconds of waveform was captured, and both a vernier estimate of arrival time and range rate estimation were performed using banks ofcoherent matched filters. The entire waveform was then corrected for the compression / dilation estimated by this process.

[0150] In the third and final level of acquisition processing, compensation for multi-access and other forms of signal interference was provided, and for non-white background noise (especially impulsive noise).

[0151] Basic Acquisition. The heart of the algorithm is the filtering process and the shift- and-sum processes. FIG. 8 shows two plots. The upper plot shows a fully known signal embedded in bandlimited AWGN at an input SNRi of 3 dB. The lower plot shows the output of the basic acquisition process. A detection is made based on a peak exceeding the mean noise (output) by a prescribed number of standard deviations of the noise (output).

[0152] This specific threshold was constructed from Th = m+Ko, where m is the running noise mean, and o is the running standard deviation of the output of the magnitude-squared matched filter. If, for example, the desired detection threshold was specified as 16 dB, then K = 40.

[0153] Second Level Acquisition. There are three important additions to the basic process, which are (i) identifying and correcting for range rate, (ii) refining the signal arrival time, and (iii) estimating the channel impulse response (CIR).

[0154] In the first step, a portion of the received signal which contains the entire (180 ms) acquisition waveform is selected. This vector is then tested against a bank of RR-shifted matched filters to find the range rate (RR) hypothesis with the greatest peak power. To run this loop, a start range rate (RR) hypothesis and hypothesis increment (delr) both in knots, are selected. Now with an estimate of the RR, the received data is dilated / compressed to compensate for this estimate.

[0155] A single matched filter is then performed to extract the principal components of the CIR. The FH receiver is likely to fail if the CIR is greater than the chip duration (6.25 ms).

[0156] Third Level Acquisition. One of the potential causes of failure in the FH acquisition is the presence of interference in the band. This interference might take the form of impulsive noise, of slow but pronounced variations in background noise power, multi-access interference from other FH signals, or intentional jamming. Consider that the basic acquisition “merely” sums the power at the various frequencies as equal contributors to the acquisition. The modificationsin this section involve “normalizing” the received data so that, on average, the noise / interference output of the filters remains constant.

[0157] The performance of these additions is demonstrated in FIG. 9, where the top plot shows the received time series, with preceding interference, while the lower plot shows the results of all of levels 1 through 3 acquisitions.

[0158] Modulation and Demodulation. The original JANUS waveform was also modified to become more resilient against frequency-dependent fading. Specifically, spectral redundancy was introduced as redundant chips per baud period. At the receiver, the user may choose to average the spectral power at all frequencies or choose the maximum value. In a noise-limited environment, the former choice would be appropriate, but in a high SNR, severe multipath channel, it might be advisable to select the second option. As one example, for a simulation involving the CIR, without using redundancy, 57 channel symbol errors (out of 144) were encountered, but while using redundancy of 3 only 47 of such errors occurred. It is important to note that this waveform depicted in FIG. 10 is fully compatible with any other modem using the original JANUS standard.Development of Docker Containers

[0159] Docker containers on the HydroNet WMM’s software architecture were developed. With this feature, HydroNet WMMs can run an application in the user space as a software package in a lightweight and standalone, executable package format. With these containers, information about software implementations, runtime, system tools, system libraries, and settings can be included in the WMMs. In addition, multiple containers can co-exist and run on the same processor while sharing the OS kernel. Hence, isolated processes in user space can be run simultaneously.

[0160] The docker containers are essentially pre-implemented containers can run different protocol stacks, such as JANUS, ZP-OFDM, or function as full-blown software-defined radio. Each profile is interfaced with corresponding PL designs, providing turnkey templates for users. This feature enables a seamless transition between different functionalities to support the different concepts of operations (conops). As an example, switching of transmitting waveforms between two docker containers in real-time with HydroNet WMM is shown in FIG. 4. Software- defined radio profile transmits ZP-OFDM packets using GNU Radio, and transmitted signals canswitch to JANUS packets in real-time. Transmitted signals are observed and showcased with a real-time spectrogram.System Integration

[0161] Integration of the HydroNet WMM with the UUV unit. In this project, the HydroNet WMM was interfaced with a COTS ROV. First, balancing of the ROV is done with the payload of the attached HydroNet WMM. Careful buoyancy calculations are conducted in order to maintain efficient mobility of the ROV without any drag or floating issues. Then simultaneous powering of the modem and the ROV is maintained by individual powering circuitry.

[0162] Different interfaces are also tested for hardware and software connectivity. For the hardware side, connection of the circuitry is maintained through ethernet connection, which enables data, command, and control exchange between the modem and the ROV. Secondly, software integration and interfacing are utilized with the usage of protobuf. With this integration, detailed testing and optimization are done as part of the above.

[0163] Integration of the HydroNet WMM with Camera Unit and Video Streaming. The HydroNet WMM may be interfaced with a camera unit. This interface enables the HydroNet WMM to capture raw video data and encode to h.264 compression format. Encoding operation is implemented on the main module, which exploits the computational power of the HydroNet WMMs. For the software implementation of the encoding, GStreamer open-source tool is utilized. With GStreamer, required bit rate, resolution and frame rate can be adjusted according to the necessary communication parameters and data rate. Raw data received from the camera is captured with GStreamer. H.264 encoded video data is streamed to GNURadio with UDP. The unsigned binary data is then packetized with the implemented custom ZP-OFDM transmitter block, which then can be transmitted through underwater channel in acoustic domain. Then the received data is first depacketized and equalized with the implemented ZP-OFDM receiver in GNU Radio and then the demodulated binary data fed into GStreamer to playback the received video. This, data flow is tested over the cable to realize real-time video streaming from transmitter to receiver modem. Further underwater video streaming experiments are conducted leveraging the integrated camera unit as detailed above.Example 3. Test CasesReal-Time Doppler Effect Estimation and Compensation

[0164] A GNU Radio flowgraph that estimates and compensates the Doppler effect in realtime was designed and implemented. Simulations are conducted by inducing known Doppler shifts in the frequency domain, in a constant or varying setting. With this flowgraph, Doppler shift and factor are estimated by using LFM training symbols. Then the resampling and CFO correction on the received packet is conducted for compensation to improve the decoding performance.

[0165] The transmitter node is shifted towards and away from the static receiver node to generate the Doppler effect while communicating with the ZP-OFDM communication scheme, which is known to be not resilient against Doppler effect. With a known motion pattern, Doppler estimation can be observed in a more controlled manner. Thus, to observe the effect of the Doppler shift and investigate the most suitable waveform to compensate, different ZP-OFDM schemes are generated, transmitted, and recorded at the receiver, while shifting the transmitter modem towards and away from the receiver modem with a known motion pattern.

[0166] To test the Doppler estimation and compensation in real-world ocean data, a ZP- OFDM waveform with 8192 subcarriers allocated over 125 kHz bandwidth with differential BPSK signaling is used. With this waveform, resulting BER without and with Doppler compensation and in addition to Doppler, CFO compensation and turbo encoding are also shown in FIG. 11 panel A. Also, the estimated speed of the transmitter modem from the recorded signal at the receiver modem is shown in FIG. 11 panel B. Since the motion pattern is already known, according to the estimated values, we can correlate the motion pattern with the received packets. As a final indicator, constellation diagrams are plotted without and with the Doppler compensation in FIG. 11 panel C- panel D. As can be observed, the decision region for BPSK signaling is much more distinct and clearer with the Doppler estimation even before performing any equalization.

[0167] After the development and initial testing of the Doppler algorithm against Doppler shifts generated relatively controlled way by pulling a node at a certain trajectory, the algorithm is tested in a mobile setting. Specifically, in this new setting, all nodes are mobile (integrated over BlueROV2) and in-motion underwater, which generates complex and relatively random Doppler effects.

[0168] In these experiments, a ZP-OFDM communication scheme using a 125 kHz total operation bandwidth centered at 140 kHz with 8192 subcarriers allocating differential BPSK modulation, is used. With these parameters, each subcarrier has a bandwidth of 15.28 Hz. FIG. 12 panel A shows the relative velocity of the transmitter node’s movement, estimated through the developed Doppler algorithm. FIG. 12 panel B shows how this relative movement is generating larger frequency shifts for subcarriers centered around larger frequencies. For instance, it can be observed that the relative movement is generating up to 17 Hz (around 1 subcarrier bandwidth) frequency shifts for a subcarrier centered around 77.5 kHz, while it is imposing up to 40 Hz shifts (larger than 2 subcarrier bandwidths) for a subcarrier centered around 202.5 kHz. These results showcase that non- Doppler effect can be highly frequency dependent severe in mobile settings. Moreover, it can be also observed that these generated Doppler effect can violate orthogonality of a ZP-OFDM scheme heavily and introduce large Intercarrier-Interference (ICI) impairments. FIG. 12 panel C showcases how this imposed Doppler can deteriorate the performance if it is unaddressed. Specifically, BER results per packet can be observed with and without employing the developed Doppler compensation.GNU Radio & Real-Time Reconfiguration Capabilities (Full-Blown SDR Capabilities)

[0169] An adaptive, software-defined, easily reconfigurable transceiver is greatly desired due to the severe multipath channel fluctuations and the spatially and / or temporally varying bandwidth resources in underwater acoustic communications. Acoustic modems sold commercially have limited customizability options, and it is typically difficult and expensive to add functionality to proprietary systems. On the other hand, using a platform where most functionalities are managed by software enables quick and simple prototyping as well as the adoption of new designs where various parameters may be changed in real-time (e.g., modulation, carrier frequency, coding, as well as the entire communication protocol). As a result, the HydroNet WMM platform is adaptable in both (i) PHY parameter adaption, such as in an OFDM PHY layer, and (ii) smooth switching between other communication technologies, such as OFDM and DSSS. Such flexibility has advantages. Dynamic modulation and coding scheme adaption are made possible by the PHY parameters' real-time adaptivity, which enhances the system's overall performance in terms of data rate, BER, and other factors.

[0170] To implement these features and obtain a fully software-defined acoustic underwater modem, an open-source tool, GNU Radio, is used. With GNU Radio, several different physicallayers are implemented that can stream any data that is suitable for the desired application. Similarly, different signal processing operations are implemented to improve the signal decoding performance at the receiver chain, such as Doppler and CFO estimation / compensation, turbo encoder / decoder, etc. Besides signal processing capabilities, GNU Radio also enables real-time waveform adaptation either in a channel-aware manner, where an adaptation decision is made according to a computational result, or user-induced structure, where the user can change any parameter of the ongoing transmission or reception process. For the latter case, an XMLRPC server is implemented, which controls several features of the GNU Radio flowgraph remotely through an HTTP server in real-time. Thus, each HydroNet modem can be controlled remotely from any Internet-connected device securely.

[0171] The real-time spectrum agility of the HydroNet WMMs was demonstrated. Specifically, ZP-OFDM packets were transmitted from one HydroNet WMM leveraging a designed GNU Radio Flowgraph, and received and showcased spectrum with a second HydroNet WMM. Leveraging the described XMLRPC interface above, the center frequency of the transmitting HydroNet WMM was switched to use different portions of the underwater spectrum in real-time from an iPad’s generic internet browser accessing to the HTTP server. Transmitted ZP-OFDM were allocated at the different parts of the spectrum, with real-time commands from the HTTP server.Anti-Jamming Capabilities

[0172] As explained previously, a real-time adaptation of underwater wireless communication links is vital due to the unregulated communication spectrum and possible applications that require secrecy. In these experiments, a ZP-OFDM run-time parameter reconfiguration was tested under various conditions, such as interference or jamming, to show the performance benefits of reconfiguration, real-time adaptation, and physical layer agility of the HydroNet WMM. Under interference or jamming, a real-time adaptation of communication settings (such as the center frequency of the utilized communication bandwidth) can be changed to maintain successful communication without interruption with the help of the channel-aware adaptation capability maintained with GNU Radio functionality. As explained above, three modems are utilized to conduct these experiments where two modems communicating over a vertical channel utilize ZP-OFDM physical layer with 62.5 kHz bandwidth at -100kbps payloaddata rate, and a third modem that induces jamming signals with 30 kHz of bandwidth, to disrupt the communication link.

[0173] Channel-aware decision computations are made according to the received BER results. According to the output of the BER calculation, a feedback signal is transmitted from the receiver modem indicating the desired center frequency of the communication link. This feedback signal is generated with a highly reliable and robust physical layer, binary chirp spread signal (BCSS) scheme. After receiving the feedback signal, transmitter changes or maintains the center frequency that it is going to transmit.

[0174] When the jamming signal is within the communication link’s bandwidth, instantaneous BER performance degrades. The receiver node swiftly detects the jamming signal and reacts to it by reconfiguring its carrier frequency band to a different band from the original so that successful communication can still be maintained with minimum interruption, as shown in FIG. 13. Consequently, the transmitter / receiver pair avoids the jammer and continues to communicate at an optimal BER performance in an automated manner.Underwater Wireless Video Streaming

[0175] HydroNet WMMs are capable of high data rate, robust, software-defined capable modems. Thus, to showcase these features, underwater wireless video streaming is tested through an underwater channel. Two HydroNet modems are deployed in a different vertical and horizontal channel settings at the different deployment locations. In every experiment, at the transmitter side, camera was attached to the HydroNet, which acts as a static surveillance node. Raw video data was obtained through the camera and getting encoded in H.264 format with the desired bit rate that matches the actual data rate to be transmitted wirelessly underwater.Encoded data via GStreamer tool, was pipelined to GNU Radio flowgraph through TCP (or UDP depending on the application), which then packetized into ZP-OFDM physical layer to be transmitted underwater. At the receiver chain, packet detection was performed using a preamble followed by a non-uniform Doppler estimation and compensation process. Subsequently, uniform Doppler estimation and compensation and channel equalization was performed on each received ZP-OFDM packet. Equalized symbols then converted into information bits through a demodulation block, and consequently decoded with Turbo decoder. At the final step, decoded bits was sent to a GStreamer block to perform H264 decoding and visualize the video. Decodedvideo data can either be visualized at the control screen of the user or live streamed to any Internet-based streaming software or website (e.g., YouTube).

[0176] In the deployment setting, a HydroNet WMM deployed at the bottom of the ocean streamed video wirelessly to another HydroNet WMM which at the surface of the ocean. Both WMMs were connected to HydroNet Smart Surface Buoys, which incorporates LTE connectivity through water-proof molded cables. The streamed video was displayed both with local video player on a laptop and over YouTube. Both the local laptop and YouTube Server were connected to the surface modem through HydroNet’s Remote Server located at Bionet / Hydronet offices in Burlington, MA, through an LTE connection. For this demonstration, ZP-OFDM signaling is used with 310 kbps payload data rate. FIG. 14 shows snapshots from this demonstration. Particularly on the left, a video frame capture from the YouTube stream is showcased. Whereas on the right, a video frame showcasing real-time comparison between the reference video, which is streamed with a cable, and wirelessly streamed video. In summary, HydroNet WMMs could stream video wirelessly underwater at the reference video quality with only a few milliseconds of delay inherently posed due to the slow speed of sound underwater.Example 4. HydroMesh: Self-Healing Underwater Mesh NetworkingDesign, Development and Implementation Route Discovery Algorithms

[0177] Routing discovery algorithms were designed, developed, and implemented to support both static and mobile nodes. The developed algorithms play a major role in establishing and proactively maintaining underwater mesh networks by identifying and establishing optimal routes among network nodes. The aim was to develop and implement routing discovery protocols tailored to address the challenges of underwater acoustic channels and can be performed periodically without creating huge overhead to adapt to network changes, discover new paths, and ensure the seamless flow of data within the network.

[0178] The first focus was on optimizing the transport layer (i.e., UDP) header files to address the data rate limitations of underwater acoustic channels. The standard UDP headers are designed to be used in high-rate wireless RF and wired channels. While they can be leveraged in underwater domains, due to the limited spectrum resources and long propagation delays in underwater acoustic channels, for most case it can be prohibitively inefficient. For instance, a standard UDP packet utilizes 42 bytes: the UDP header is 8 bytes, the IPv4 header is 20 bytes, and the Ethernet II header is another 14 bytes. For physical layers utilized in the underwateracoustic channel, especially for those robust and long-distance physical layers, large packet sizes are often fairly hard to achieve without sacrificing data rate. Therefore, the header utilized must be simplified and compressed to maximize the ratio of data bytes to header bytes occupying the underwater channel. The HydroMesh uses a custom 10-byte header containing all information necessary for Data Link Layer, Network Layer, and Transport Layer transactions. The Source and Destination bytes can be thought of as a compression of a IPv4 Address and UDP Port combinations. When a new endpoint joins the network, it is given a single byte alias to correspond to a UDP Endpoint. This translation is maintained by the HydroMesh to ensure that endpoints can join the network during runtime. The Last Hop, Previous Last Hop, and Next Hop are utilized to ensure packets are reach the correct next neighbor. The Accumulated Transmission Quality is a byte used to propagate a path’s transmission quality to each node this packet reaches to maintain optimal routing decisions (discussed further in the following section). The Sequence Number, Last Sequence Number, and Bytes to Read are utilized for packet fragmentation and reassembly. The Transport Layer can be utilized in both a reliable and unreliable transmission mode without changing the header. By compressing the header, the ratio of header bytes to data bytes may be greatly increased, thereby increasing throughput.

[0179] HydroMesh, as shown in FIG. 15, is a proactive network layer where the network topology is actively maintained while the network is running. There are two core mechanisms on every HydroMesh node for determining the optimal route to a destination: a Neighbor Table and a Destination Table. The Neighbor Table keeps track of each node’s single-hop network neighbors. It is populated with Transmission Quality values, which is metric used for evaluating the link quality among network nodes. The Destination Table keeps track of each node’s ability to reach to a destination that can be multi-hops away. This table is also populated with Transmission Quality values; however, these instead register a metric that values end-to-end network path quality. FIG. 16 provides an example of the structure and functionality of these two tables.

[0180] There are three important aspects of HydroMesh used to update these tables. First, periodic control packets (called Originator Messages or OGMs) are flooded through the network. However, the packets were tailored to be generated less frequently with adaptive large periods (typically greater than 30 seconds) for limiting the overhead on resource-constrained underwater acoustic channels. These packets are leveraged for establishing and maintaining linkssupporting introduction of new network nodes, mobility and varying link conditions. These packets are also serving as heartbeats for network nodes. Second, a mechanism to monitor the network traffic and accordingly updating the neighbor table is established. By utilizing information gathered from the Data Link Layer and the Transport Layer, transmission quality to each neighbor can be actively maintained through data transmission transactions. Finally, a metric field called Accumulating Transmission Quality, as shown in FIG. 17, was introduced, to be included in every packet, measuring and storing the transmission quality in each propagation. This value corresponds to the estimated Transmission Quality back to the Source of the Packet through the Last Hop. At every hop in the network, this value is recorded in the Destination Table and updated with the current node’s transmission quality back to the last hop the packet took if this packet is destined to be forwarded or broadcast. This value is also deteriorated by a set value to ensure that longer paths have a bias / penalty against them compared to shorter paths.

[0181] HydroMesh utilizes the above systems to construct and maintain a routing topology throughout the runtime of the HydroMesh whether it is idle or transmitting data. Due to the flexibility of these core mechanisms, route adaptation is managed through the same systems used for route discovery.Design, Development and Implementation Adaptive Cross-Layer Routing Algorithms

[0182] HydroMesh is designed to proactively discover routes to construct its network topology. However, routes remain useful only if they are continuously updated and accurate. If a node fails, experiences noise, interference, or jamming, or moves out of range, HydroMesh must detect the issue and dynamically reroute as needed. This is achieved through HydroMesh’s crosslayer solution approach, which monitors quality metrics across the Data Link Layer, Network Layer, and Transport Layer to maintain optimal transmission quality. In other mesh network implementations, such as the open-source BATMAN protocol, large volumes of control packets are used to estimate transmission quality to a neighbor. It does this by tracking the ratio of transmitted packets to received echoes. While this approach provides a reliable estimation of link quality, generating the required number of packets in an underwater acoustic channel would be highly time-consuming. Therefore, alternative methods must be employed to build accurate link quality information efficiently.

[0183] HydroMesh employs a lightweight learning system that tracks various network events to update transmission quality to a destination. Instead of relying on control packets to countechoes, it leverages data link layer transactions to assess link quality. A received data link acknowledgment indicates a successful transmission to a neighbor, which is logged and increases the transmission quality score for that link. Conversely, a missed acknowledgment suggests that the transmission failed to reach its destination, resulting in a decrease in transmission quality. This mechanism also applies to the receiver: receiving duplicate data implies that its acknowledgment did not reach its destination, while receiving the next-in-sequence data confirms that the acknowledgment was successfully delivered. By coupling transmission quality scores with the status of the data transmission mechanism, HydroMesh effectively maintains link quality for each neighbor without introducing additional control packet overhead.

[0184] To further enhance network- wide route optimization, HydroMesh utilizes OGM packets to periodically update routes across the network. These OGM packets are broadcast throughout the HydroMesh network and contain an Accumulating Transmission Quality byte. As they propagate through the network, they inform each node of the transmission quality back to the source, ensuring that the best paths across the network remain up to date and optimized.

[0185] Finally, to ensure network stability and efficient routing, HydroMesh implements a timeout mechanism for classifying nodes as inactive. If a neighboring node has not been heard from in any form within a predefined timeout period, its transmission quality gradually decays to zero over a few seconds (minimum for transmission quality is nonzero). Given the way end-to- end transmission qualities are calculated, this results in an effective transmission quality of zero, preventing traffic from being routed through that node unless all alternative neighbors are also unavailable. If all potential routes become unavailable, the node enters a route- searching mode, continuously attempting to transmit until it detects a packet from a neighbor. Once a response is received, the link quality for that neighbor is restored to a predefined value, allowing it to be used for routing again. This mechanism ensures that traffic is dynamically rerouted around inactive nodes while enabling rapid recovery when connectivity is restored.

[0186] By integrating these mechanisms, HydroMesh achieves an opportunistic yet adaptive routing approach. Highly functional links are prioritized, while non-functional links are entirely avoided. A key advantage of this design is its flexibility — not only does it account for extreme cases where a node goes completely offline, but it also maintains links with high packet error rates as viable backup routes. This ensures redundancy in case the primary route fails. Additionally, if a link begins experiencing significant packet loss, the system can dynamicallyselect and prioritize an alternative route that offers a better transmission rate. Overall, the HydroMesh algorithm is designed to adapt to the volatility of the underwater communication channel, efficiently routing around poor-quality links and potentially inactive / unavailable nodes to maintain robust network performance.Extensive Field Testing and Demonstration of Self-Adaptive Mesh Network

[0187] The HydroMesh protocol, as described above, was extensively tested across multiple configurations.

[0188] For HydroMesh testing, five low-frequency modems were used, though the protocol itself is not restricted to any specific frequency band. To meet the exit criterion, the test topology needed to demonstrate both adaptive routing and the transmission range of the WMM device. Accordingly, a five-node topology was selected and configured as shown in FIG. 18.

[0189] Once the nodes were configured to support this topology, link testing commenced. Data transactions were sent from 192.168.2.21 through each of the three intermediate nodes, terminating at 192.168.2.24. A Layer 4 acknowledgment was then transmitted back to 192.168.2.21 in response. During testing, HydroMesh frequently selected 192.168.2.23 as the preferred relay, as it consistently provided the most reliable link back to 192.168.2.21.

[0190] Network Formation. Once the topology was confirmed to be functional for demonstrating route switching, adaptive testing began. The first demonstration showcases how the network topology is automatically constructed and displayed on the dashboard using the OGM packets mentioned earlier. When a node comes online, these packets propagate through the network, allowing each node to recognize and establish connectivity with its neighbors. If a node has a connection to the HydroNet Dashboard, it reports the received OGMs, enabling realtime visualization of the evolving network structure.

[0191] This mechanism ensures that the network topology dynamically updates as nodes join or leave the network, reflecting changes in connectivity and transmission quality. FIG. 19 illustrates the initial topology as displayed on the HydroNet Dashboard after all nodes have come online.

[0192] Route Discovery & Optimal Route Selection. Next, route discovery and optimal route selection were demonstrated using this topology. Data generated at 192.168.2.21 had the option of transmitting through any of the three intermediate WMM modems to reach 192.168.2.24. The selection process considered multiple factors, with a primary focus on prioritizing neighbors thathad recently communicated with the destination. In most cases, this resulted in transmissions being routed through 192.168.2.23, as it provided the most stable link. An interesting feature of the transmission quality system is its ability to support asymmetric routing, meaning the path taken for data transmission may differ from the return path for acknowledgments. However, in practice, a symmetric route was often used since the link was consistently maintained as active. Below is a data packet displayed on the dashboard, traveling from 192.168.2.21 to 192.168.2.24.

[0193] HydroMesh Adaptive Routing. Finally, the adaptive capabilities of HydroMesh were demonstrated in a dynamic scenario. After the system successfully selected and maintained an optimal path for a period of time, the relay node 192.168.2.26, which facilitated multi-hop routing between 192.168.2.21 and 192.168.2.24, was intentionally taken offline. Initially, HydroMesh continued attempting transmissions through the lost node. However, as transactions began to fail, the transmission quality score for that path rapidly declined. In response, HydroMesh dynamically explored alternative routes, ultimately identifying a new viable path. Once a more reliable route was established, it was prioritized over the previously active but now offline link.

[0194] The system also demonstrated its ability to handle asymmetric failures. The receiver monitored its acknowledgments, detecting failed transmissions based on the presence of duplicate data. When such failures were identified, Layer 4 acknowledgments were rerouted accordingly to maintain network functionality. FIG. 20 illustrates this process, showing how data transmissions were dynamically redirected through 192.168.2.25 after the link quality of 192.168.2.23 deteriorated due to the node going offline.

[0195] After the initial adaptation, further adjustments were made in real-time by periodically turning off the active node. HydroMesh continuously responded by dynamically rerouting traffic through alternative paths. This adaptive behavior was observed across all intermediate nodes, as reflected in the experimental link quality graph shown below, which illustrates the network’s responsiveness to changing link conditions.Example 5. HydroFi: An Underwater Plug-and-Play Self-Configuring Wi-FiDesign and Development of a HydroDi Base Station

[0196] HydroFi is HydroNet networking solution designed to function similarly to Wi-Fi but in underwater environments. At the core of this system is the HydroFi Base Station, illustrated in FIG. 21, which combines two primary components: a HydroNet Software-defined Modem andEdge Platform (SDM-EP) used as Access Point of the HydroFi network and a HydroBuoy. Together, they enable wireless data exchange between the water domain and above-surface networks using a range of traditional and cutting-edge RF communication technologies, including Wi-Fi, LTE, 5G, and satellite links.

[0197] HydroBuoy. A HydroFi base station that functions as a gateway and is built around a mechanical buoy structure integrated with custom electronics was designed and developed. The base station supports interfaces with the SDM-EP and terrestrial and space connectivity through Starlink, Iridium, LTE, and Wi-Fi. Power is supplied via a rechargeable 12 VDC battery pack, which can be recharged using onboard solar panels for extended autonomous operation. As for the buoy, a CB-450 Data Buoy was used, as shown in FIG. 22.

[0198] As illustrated in FIG. 23, the components of the HydroBuoy include a maximum power point tracking (MPPT) module, specifically the EPEVER MSC3210N, which maximizes the efficiency of solar energy conversion to charge the battery. This MPPT also features two controllable power outputs (Load 1 and Load 2), which are used to supply power to a Starlink Mini and a Protectli V1410 processing unit, respectively. The processing architecture consists of the Protectli V1410 — equipped with four Ethernet ports — and an Arduino Nano microcontroller.

[0199] Connectivity is provided through multiple interfaces, with a RockBLOCK Iridium Switch serving as the primary control interface for turning devices on or off allowing remote control and status monitoring of other components.

[0200] Additional connectivity options include LTE and Starlink, used for high-bandwidth communication and are both connected to the Protectli. A Poynting Puck-4 LTE / GPS combined antenna supports 5G and 4G LTE connectivity and provides positioning data.

[0201] The battery supplies power to the Iridium terminal, Arduino, and HydroNet modem via digitally controlled relays. The Iridium module is interfaced directly with the Arduino, while LTE and Starlink are connected to the Protectli. The Protectli is also physically wired to both the Arduino and the HydroNet modem, enabling internal coordination and control across the system.

[0202] The Protectli device packs up to 1 TB of onboard storage, expandable via SSDs, and offers versatile connectivity through Ethernet, USB, UART, and Serial interfaces.

[0203] To integrate and connect all the components of the HydroBuoy effectively, enabling coordinated operation and centralized control via the microcontroller, a custom printed circuit board (PCB) was designed and developed. This PCB serves as the central hub, managing powerdistribution, communication interfaces, and device control. Achieving the final design required multiple iterations to refine the layout, ensure signal integrity, and accommodate all necessary connections and functionalities.

[0204] HydroBuoy Assembly. The assembly process focused on integrating the mechanical and electronic components within the buoy structure in preparation for full system operation.

[0205] To simplify installation and ensure structural stability, the MPPT charge controller and the Protectli unit were first stacked and mounted onto a dedicated frame. Both the frame and an aluminum enclosure are secured to vertical rods fixed to the base of the internal buoy cavity.

[0206] Mechanical Assembly and Mounting Details. The internal cavity of the buoy is sealed with a custom end cap equipped with waterproof, marine-grade connectors that interface external devices, such as antennas, with the electronics housed inside. These connectors allow cables from external devices, such as antennas, to pass through the cap and connect to the internal electronics. The Iridium, LTE / GPS and Starlink antennas and the safety light are securely mounted using custom-made mechanical supports attached to the top of the solar panel structure, ensuring stable positioning and optimal signal reception.

[0207] Software and Dashboard Development. A custom software in C++ was developed for the onboard microcontroller to enable communication with other devices, including the MPPT controller, Iridium terminal, and Protectli unit. This software allows the microcontroller to control (turn on / off) these components and monitor key status metrics such as battery charge, solar power input, and load power consumption. The collected data can be transmitted back via the Iridium for remote monitoring and diagnostics.

[0208] A dedicated dashboard to monitor and control the HydroBuoy and its onboard components, as shown in FIG. 24, was also developed. The dashboard provides real-time status reports, including battery level, solar charging activity, and load power consumption. It also allows remote control (on / off switching) of individual devices, including: MPPT controller, solar panel, underwater modem and its charging circuit, Protectli, and Starlink.

[0209] This tool ensures that the end user can efficiently monitor power consumption and control each device, making it essential for both experimental evaluation and field deployment.Design, Development and Implementation of WiFi-like Centralized Underwater CrossLayer Algorithms

[0210] To support reliable and efficient data exchange among underwater assets, HydroFi leverages frequency diversity and advanced coordination strategies. A custom protocol was developed to: (i) ensure efficient utilization of the available channel capacity; (ii) reduce handshaking and control overhead to improve network throughput; (iii) enhance spectral efficiency by enabling multiple users to share the same frequency channel; and (iv) minimize cochannel interference to maintain signal quality across the network.

[0211] HydroFi Protocol Design. For the purposes of the HydroFi protocol, the network is logically organized in a centralized topology, so that a central Access Point can coordinate the accesses of multiple terminals and allocate resources. The central Access Point is tasked with specific access control functions, including the identification of new nodes requesting access to the network, and nodes departing from the network, calculation and reallocation of the available resources.

[0212] The protocol operates over a single frequency band divided into multiple channels (FIG. 25), one of which serves as a dedicated control channel for beaconing and node association.

[0213] A hybrid approach combining contention-based and reservation-based MAC protocols was adopted. Contention is used during the association phase because the control channel is shared, and collisions can occur. Once nodes are assigned dedicated frequency channels through reservation, collisions are avoided, as these channels are separated in frequency.

[0214] The protocol begins with a network initialization phase managed by the access point (AP), followed by a regular operational phase during which the AP exchanges data messages with the nodes. Nodes undergo an initial access phase to join the network, after which they enter a data transmission phase. The flowcharts of the AP and node protocol mechanisms are reported in FIG. 26 and described below. A message sequence diagram illustrating the packet exchanges between the AP and multiple nodes is presented in FIG. 27.

[0215] The HydroFi protocol was implemented in Python for both the access point and node sides. Communication with the physical layer, implemented in GNU Radio and based on BCSS modulation, was handled via UDP sockets.

[0216] The GNU Radio implementation of HydroFi node is shown in FIG. 28. The top part of the flowgraph handles reception, while the bottom part handles transmission. Multiplereceiver blocks are instantiated to allow listening on different channels simultaneously. The transmission frequency, instead, can be dynamically changed to switch between the control and data channels using the XML-RPC server function, therefore only one GNU Radio transmitter chain is needed. Extensive Field Testing and Demonstration of an Underwater Plug-and-Play SelfConfiguring Wi-Fi Base Station

[0217] Electrical and Power Measurements and Testing. Electrical measurements and tests were conducted, focusing on power consumption of each component and solar charging performance to verify correct operation and integration.

[0218] Table I presents the measured and calculated power consumption and supply values for the various components. Table II summarizes the resulting energy performance, including estimated battery charging and discharging durations under different load conditions.Table I: Power consumption and supply of different components.

[0219] Table II: Calculated energy performances based on measured power consumption and supply values.Min battery charging time j Max solar power (45 W) § 7.7 hr (Iridium fully charged, 1.12 W) iIridium and MPPT on [ 8.8 hr (Iridium charging. 5.4 W) i j Protectli off and modem| disconnected |Min battery’ charging time j Max solar power (45 W) 9.6 hr(devices on) Iridium and MPPT on |Protectli ON and modem |[ connected [Max battery charging time Min measured charging solar i Total solar power = 4.4 power (4.4 W) | 76.4 hrIridium and MPPT ON (2.4 W)Protectli OFF and modem § i disconnected §Expected system charging Expected solar power (20 W) [ 33 hr (Iridium fully cha duration with sunny days $ Iridium and MPPT on (2.4 W) |Protectli OFF and modem § j disconnected §

[0220] Next, the actual energy harvesting performance was assessed under real-world conditions. The buoy was placed outdoors, and the harvested solar power was measured across different weather conditions and times of day. FIG. 29 presents the harvested power measured as the power flowing into the battery over different hours of daylight during multiple sunny days.

[0221] The results indicate that, with no active loads powered on, on average, approximately100 Wh of energy was accumulated daily from 7:00 AM to 3:30 PM. This corresponds to about 30% of the total battery capacity (336 Wh). Thus, a full charge under similar sunny conditions would require approximately 28-30 hours of sunlight, or about three and a half days.

[0222] A load was then introduced by turning on the Protectli and measured the power again. This test was conducted on a day with variable weather conditions. The results, shown in FIG. 30 (top), exhibit noticeable power fluctuations due to changes in sunlight caused by passing clouds and snowfall. On average, the system delivered approximately 10 W of power to the load, which included the MPPT, Protectli, and energy losses due to conversion inefficiencies.

[0223] The accumulated and dissipated energy over time was also tracked, as shown in FIG. 30 (bottom). This includes harvested solar energy, energy supplied by the battery, and the battery's net energy balance (total energy stored in the battery at any given time).

[0224] A full-system test was conducted to assess energy harvesting and consumption in a realistic, continuous operation scenario. The system was fully integrated and operated without interruption. The test was structured in two phases. Phase 1 involved multiple days dedicated to charging the battery using solar energy. Phase 2 evaluated the energy consumption during the charging of the Hydronet modem connected to the buoy.

[0225] Power and energy metrics were continuously recorded. FIGS. 31-32 show the input power from solar, the power delivered to the battery and the load, and the corresponding accumulated energy throughout both phases.

[0226] During the modem charging phase, the MPPT supplied approximately 40 W to the Hydronet modem. With a measured charging efficiency above 90%, about 3.5 W were dissipated, resulting in an effective charging power of roughly 36.5 W.

[0227] Over a continuous charging period of two and a half hours, the system transferred a total of 91 Wh to the modem. This corresponds to approximately 27% of the buoy’s battery capacity (336 Wh) and about 20% of the modem’s battery capacity (466.2 Wh). An estimated 10 Wh were lost as power dissipation during this interval.

[0228] Given that the buoy battery holds roughly 75% of the modem’s full capacity, fully charging the modem requires more than 12 hours of sustained energy transfer. This necessitates multiple cycles of buoy battery charging to achieve a complete modem recharge.

[0229] Final Deployment and Functionality Tests. Following the power and energy evaluations, the final testing phase was conducted by deploying the HydroBuoy. This stage included testing the buoy's mechanical behavior, buoyancy, resistance to tipping, and stability. The water integrity of the enclosure was also verified by exposing it to different weather conditions, checking for any signs of leaks or moisture intrusion. In parallel, full system functionality was confirmed in real conditions, including end-to-end communication, remote monitoring, and device control using Iridium, LTE, and Starlink networks.

[0230] FIG. 33 illustrates the network architecture, showing the buoy connected to the remote user via the Iridium satellite network and LTE. These tests were performed repeatedly throughout the entire experimental campaign. Whenever a user needs to control or monitor a device, a message is sent from the dashboard to the Iridium terminal. The terminal first sends an acknowledgment (ACK), followed by the requested data, for instance a device state (on or off) or its voltage, current, and power.

[0231] Once the Protectli device is turned on, the user can establish a secure shell (SSH) connection through LTE or via Starlink.

[0232] During deployment, the correct operation of the HydroFi protocol was also verified. The network consisting of the AP connected to the HydroBuoy, and 4 Hydronet Modems deployed at different locations in the harbor. Each modem sent a request to join the network. The AP autonomously accepted the requests, assigned a dedicated channel to each node, and associated them to the HydroFi network. Once connected, the AP successfully received traffic from all four nodes simultaneously.

[0233] At the end of each transmission, the AP disconnected the corresponding node, released the occupied resources, and updated the active node list accordingly. This confirmed the autonomous, plug-and-play behavior of the underwater HydroFi communication system.

[0234] It is to be understood that the above-described modular communication network may include additional or alternative steps and aspects, based on the foregoing description relating to the various nodes / devices and tools described herein. Accordingly, as a result of the structure and functionality of the above described modular communication network, one skilled in the art would appreciate the different methods in which they may be utilized.

[0235] Many modifications and other embodiments of the present invention will come to mind to one skilled in the art to which the invention pertains upon having the benefit of the teachings presented herein through the foregoing descriptions and the associated drawings. Therefore, it is to be understood that the present invention is not to be limited to the specific embodiments disclosed and that the modifications and other embodiments are intended to be included within the scope of the appended claims. Although the specific terms are employed herein, they are used in a generic and descriptive sense only and not for the purpose of limitation.

Claims

ClaimsThat which is claimed is:

1. A modular device network comprising: a communication module; a main module; at least one modular device; wherein the communication module, the main module, and the at least one modular device use acoustic signals, visual signals, light signals, and / or radio frequency to establish a communication link between the communication module, the main module, and the at least one modular device to establish a modular communication network.

2. The modular device network of claim 1, wherein the communication module utilizes acoustic signals in the audible or ultrasonic spectrum to establish the communication link.

3. The modular device network of claim 1, wherein the communication link is capable of transmitting data through the interface between solids and liquids, solids and gases, and / or gases and liquids.

4. The modular device network of claim 3, wherein the communication link is capable of transmitting data through the interface between water and air.

5. The modular device network of claim 4, wherein the at least one modular device comprises at least one underwater device configured to collect data and transmit said data to the main module via acoustic signals.

6. The modular device network of claim 5, wherein the data is audio data and / or visual data, such as images or videos.

7. The modular device network of claim 1, wherein the main module comprises a processor.

8. The modular device network of claim 7, wherein the processor is configured to receive data, process data, and / or transmit data.

9. The modular device network of claim 7, wherein the processor is configured to execute one or more algorithms that at least partially incorporate artificial intelligence.

10. The modular device network of claim 7, wherein the processor is configured to execute one or more algorithms for receiving, processing, and / or transmitting audio and / or visual information.

11. The modular device network of claim 1, wherein the communication module and the main module are housed in a buoyant device configured for deployment in a body of water.

12. The modular device network of claim 11, wherein the buoyant device is self-operable.

13. The modular device network of claim 11, wherein the buoyant device comprises one or more operationally connected modules each being configured to execute a sensing, processing, or transmitting function.

14. The modular device network of claim 1, wherein the at least one modular device is an aerial communication device, an aerial sensing device, an aerial recording device, an underwater communication device, an aerial sensing device, or an underwater recording device.

15. The modular device network of claim 1, further comprising an anti-jamming component configured to adjust a signal frequency to accommodate large volumes of data for processing and / or transmission.

16. The modular device network of claim 1, further comprising a user interface dashboard.

17. The modular device network of claim 16, wherein the user interface dashboard is located at a remote location relative to the communication module and the main module, such that transmitted, via the communication module, from the main module to the user interface dashboard.

18. The modular device network of claim 16, wherein the user interface dashboard is located on the buoyant device.

19. The modular device network of claim 1, wherein the main module comprises a modular software architecture configured to compartmentalize one or more processing functions of the main module.

20. A buoyant device comprising: a communication module; and a main module, wherein the communication module and the main module are operationally connected with one or more modular devices and configured to communicate with said modular devices using acoustic signals, visual signals, light signals, and / or radio frequency.

21. The buoyant device of claim 20, wherein the one or more modular devices include one or more underwater sensing and / or communication devices.

22. An underwater network system comprising: a plurality of underwater nodes, each node comprising an acoustic modem and multi-layer networking stack including physical, MAC, network, and transport layers; and a routing protocol executing on each node, wherein the routing protocol is configured to:encode link-layer and physical-layer performance metrics, including but not limited to link quality, signal-to-noise-ratio, throughput, acknowledgments, packet delivery ratios, and timing jitter, into a compressed routing header; update network-layer route tables based on cross-layer feedback from physical, MAC, and transport layers, including packet acknowledgment success, failure detection, and timing irregularities; and transmit link metrics within regular data traffic packets such that network maintenance, topology updates, and path quality monitoring occur without requiring dedicated control packet overhead.

23. The underwater network system of claim 22, wherein each data packet carries a real-time accumulated transmission quality field that reflects current channel conditions and contributes to routing decision updates.

24. The underwater network system of claim 22, wherein failure detection is performed using one of more of physical layer signal metrics, missed MAC-layer acknowledgments, duplicate or out-of-sequence packet reception at the transport layer, and timers configured to decay stale link quality entries.25 The underwater network system of claim 22, wherein the routing protocol is influenced by both proactive periodic messages and opportunistic telemetry embedded in transactional data traffic to reduce acoustic congestion and improve route responsiveness.

26. A communication header format for an underwater network, the communication header format comprising: a single-byte alias identifier for source and destination nodes for replacing IP and UDP address conventions; a hop tracking field, including a field for current node, previous node, and intended next node hop; an accumulated transmission quality byte updated with each node hop; anda fragmentation and reassembly field, including a field for sequence ID, last sequence, payload, and byte count; wherein the header enables routing, fragmentation, and reassembly in underwater networks without dependency on traditional network stack formats.

27. The communication header format of claim 26, wherein one or more node aliases are dynamically allocated and mapped to real-world identifiers using a distributed or gateway-coordinated aliasing mechanism that supports runtime entry and removal of nodes.

28. The communication header format of claim 26, wherein packet reassembly is performed in-network at each hop or only at the final destination, based on header-configured policies for efficiency or robustness.

29. A system for bridging terrestrial and underwater networks, comprising: a gateway node configured to translate between internet protocol traffic and underwater mesh packets; a packetization engine that fragments large terrestrial packets and inserts compressed routing headers suitable for underwater channels; and a discovery mechanism wherein underwater nodes locate the gateway via flooded packets or periodic beacons.

30. The system of claim 29, wherein a gateway selection and / or a route quality are updated periodically based on real-time packet loss, latency, and retransmission metrics derived from the system.

31. The system of claim 29, wherein a fragmentation size and a packet spacing are dynamically adjusted based on real-time environmental factors including signal-to-noise ratio, Doppler spread, and historical link reliability.

32. A system for real-time underwater position monitoring and forwarding, comprising: one or more acoustic mesh nodes equipped with localization sensors or GNSS- derived positional data; a lossy compression scheme that encodes spatial coordinates and velocity vectors into reduced-resolution payloads optimized for underwater bandwidth; and a routing mechanism that forwards compressed positional telemetry through the mesh to a topside or remote dashboard.

33. The system of claim 32, wherein the dashboard reassembles compressed telemetry and renders a real-time network topology using timestamp correlation and hop-delayed propagation modeling.

34. The system of claim 32, wherein a fallback routing path is automatically selected for positional telemetry when link reliability falls below a system-defined threshold.

35. A self-configuring underwater wireless communication system comprising: a floating base station comprising a software-defined acoustic modem and a multi-interface edge processing unit; one or more underwater nodes configured to wirelessly communicate with the base station using acoustic channels; and a centralized protocol executed by the base station, the protocol configured to: detect, associate, and de-associate underwater nodes; allocate communication resources using hybrid contention-based and reservation-based channel access; and coordinate access to multiple frequency channels including a dedicated control channel and dynamically assigned data channels.

36. The self-configuring underwater wireless communication system of claim 34, wherein the base station transmits at least two types of beacon messages to synchronize node behavior, allocate resources, and schedule uplink transmissions.

37. A modular buoy-based gateway for underwater to terrestrial communication, comprising: a software-defined modem connected to an acoustic transducer for underwater communication; an edge computing unit connected to multiple terrestrial network interfaces including LTE, Wi-Fi, and satellite links; and a power management system comprising: a solar-powered battery system, a maximum power point tracking module, and a microcontroller configured to selectively enable or disable subsystems based on remote commands or power levels.

38. The system of claim 37, wherein the microcontroller controls relays and voltage regulators via commands received over a satellite network, enabling remote device activation, telemetry reporting, and diagnostic.

39. A centralized medium access control protocol for underwater acoustic communication, comprising: a shared control channel used for node discovery, beaconing, and access requests; a plurality of orthogonal frequency channels used for dedicated data exchange; and a hybrid MAC scheme wherein: contention is permitted on the control channel during association, and data transmission occurs through reserved frequency channels without collision.

40. The protocol of claim 39, wherein the access point dynamically updates the assignment of frequency channels based on observed traffic, inactivity timeouts, or node disconnection events.41 . A real-time underwater network management dashboard comprising: a network visualization engine configured to reconstruct and display underwater topology using data packets embedded with route traces and federated acknowledgments from multiple receivers; a routing engine configured to process overlay network data from edge nodes and gateways and dynamically generate updated paths across underwater and terrestrial segments; and a feedback mechanism that integrates acknowledgment data from distributed edge nodes to confirm packet delivery and update link metrics.

42. The system of claim 41, wherein the federated acknowledgment mechanism aggregates delivery confirmations from multiple underwater nodes to improve reliability in nonreciprocal acoustic conditions.

43. A cross-platform dashboard interface for underwater network control, comprising: a protobuf-based schema for defining and rendering heterogeneous asset types, including mobile, static, and virtual sensors; a dynamic mapping engine that overlays asset metadata and communication metrics on geospatial terrain; and a rendering engine operable across edge devices, cloud platforms, and underwater modems, enabling consistent asset control and monitoring across network layers.

44. The system of claim 43, wherein the mapping engine dynamically updates asset visualizations using real-time telemetry and command responses from underwater nodes and gateways.

45. A software interface framework for underwater network control, comprising: a gRPC-based API for issuing remote commands and receiving telemetry from underwater modems; a modular packet format abstraction based on Protobuf schemas for encoding network metrics, asset data, and control messages; andintegration with IP -bridging modules supporting real-time data compression and interface tunneling over kernel-managed network bridges.

46. A multi-domain communication buoy for underwater network interfacing, comprising: a housing containing a software-defined acoustic modem for underwater communication; an edge computing unit integrated with terrestrial network interfaces including LTE, Wi-Fi, satellite (Starlink or Iridium), other RF services including but not limited to mesh networking interfacesand Ethernet; and a control system configured to route data between underwater assets and terrestrial / cloud networks using dynamic protocol bridging and IPv4 tunneling.

47. The system of claim 46, wherein the control system selectively prioritizes interface use based on bandwidth availability, power status, or environmental condition metrics.

48. The system of claim 46, wherein the edge computing unit is configured to execute artificial intelligence models locally, comprising: storage and compute resources capable of running Al inference tasks, preloaded or remotely updated Al models for tasks including acoustic classification, anomaly detection, or environmental monitoring, and a telemetry pipeline to report Al-generated insights over satellite or RF interfaces to a user-accessible dashboard.

49. An autonomous buoy power and control system comprising: a solar-rechargeable battery pack connected to a maximum power point tracking (MPPT) controller; a microcontroller configured to activate or deactivate subsystems via programmable relays; and a satellite-controlled interface enabling remote commands for telemetry polling and device switching.

0. The system of claim 49, wherein the microcontroller logs solar charging, battery state, and load metrics, and transmits telemetry via Iridium short-burst messaging (SBM) or LTE channels to a cloud dashboard.

Images