Patent Publication Number: US-10784970-B2

Title: Method and apparatus for wireless communications

Description:
RELATED APPLICATION 
     This application claims the benefit of U.S. Provisional Application No. 62/411,185, filed on Oct. 21, 2016. The entire teachings of the above application are incorporated herein by reference. 
    
    
     GOVERNMENT SUPPORT 
     This invention was made with government support under Grant No. CNS-1503609 from The National Science Foundation. The government has certain rights in the invention. 
    
    
     BACKGROUND 
     Networking technology plays a useful role in many commercial, scientific, and consumer activities. Existing networking technology has an ability to transmit at high-date rates using a given communications protocol. 
     SUMMARY 
     Embodiments of the present disclosure enable a networking device to transmit data at a high data rate and simultaneously change communications protocols or communications methods in real-time to adjust for a transition or change in a communications medium through which communications data units traverse. 
     Embodiments of the present disclosure are described in the context of underwater acoustic communications for explanatory purposes only. A person of ordinary skill in the art would recognize that the embodiments of the present disclosure, and the solutions presented herein, may be applied to any type of networking technology or networking device. For example, embodiments of the present disclosure may be used in any type of communications networks involving radio-frequency (RF) transmissions, acoustic transmissions, optical transmissions, or any other type of transmissions known in the art. The improvements to networking technology through embodiments disclosed herein are, however, particularly useful in underwater acoustic networks for the reason explained below. Additionally, the term “acoustic” should be understood to be inclusive of all acoustic waveforms, including ultrasonic waveforms. 
     Current underwater acoustic wireless communications platforms (i.e., existing underwater networking devices) are based on inflexible hardware that can only support point-to-point, low-data rate, and delay-tolerant applications. Existing underwater networking devices were designed to provide low-rate connectivity over long ranges (i.e., in the order of at least 1 km). Since attenuation in underwater channels increases exponentially with frequency, most modems operate over relatively low frequency bands to achieve longer ranges. Existing underwater networking devices often provide waveforms that achieve data rates lower than 20 kbit/s with a link distance of 1 km over horizontal links. Advanced applications like video streaming are largely impossible with current technology. 
     To summarize, the vast majority of existing underwater networking devices suffer from the following limitations. 
     Low data rates. Because of the physics of underwater acoustic propagation, only acoustic waves at low frequencies (e.g., less than 30 kHz) can propagate over km-range distances. Therefore, existing underwater networking devices generate acoustic waves through low-frequency piezoelectric resonators, which are bulky and inevitably have limited bandwidth (i.e., in the order of a few kHz). However, when transmitting over shorter distances, as in many sensing and control applications of interest, it is useful to use wider bandwidths in the ultrasonic regime (e.g., up to 1-2 MHz) and generate wideband (multicarrier or impulsive) waveforms to communicate at higher data rates. However, distance-dependent optimizations of the waveform, which could enable data rates in the order of Mbit/s, are not possible with current underwater wireless technology. No existing underwater networking devices provide the flexibility to trade link distance for data rate. 
     Hardware-based, inflexible, and proprietary architectures. In existing underwater networking devices, the physical layer, including all waveform generation functionalities, is implemented in hardware and is proprietary. Higher layers are often not even defined. 
     Narrowband and bulky transducers. In existing underwater networking devices, bulk piezoelectric transducers are typically used to convert signals from the electrical to the acoustic domain. There are two main consequences. First, the achievable data rate is limited to a value equal to the product of the (small) bandwidth times the spectral efficiency achievable (i.e., a few kbit/s). Second, this lack of flexibility in the acoustic front end means that the networking device cannot implement dynamic spectrum access allocation schemes to switch to different frequency channels. This results in the networking device being hardware-tuned to a fixed acoustic channel and prevents a change frequency. Therefore, existing underwater networking devices lack the ability to react on a frequency-diversity or waveform-diversity basis to interference, jamming, or co-located transmissions. 
     Energy Inefficient. Existing systems are energy inefficient, and the deployment of underwater networks is limited by battery lifetime. As of today, battery replacement is a complex issue that requires physically recovering a deployed network node. 
     Embodiments of the present disclosure are directed to addressing the above-referenced issues. For example, at least one embodiment of the present disclosure includes a high data rate, software-defined, underwater, acoustic networking platform (i.e., networking node/device) based on a single board providing a gate-level digital hardware module (e.g., a Field Programmable Gate Array, programmable logic, etc.) for low-level processing functionalities and a general purpose processor (e.g., a central processing unit), with more memory and more powerful processing capabilities than a typical microcontroller. The combination of the processor and the gate-level digital hardware module offers hardware and software re-programmability. 
     According to at least one example embodiment, the present disclosure may be implemented in the form of a method or corresponding apparatus for receiving or transmitting network communications carried at acoustic wavelengths via an acoustic medium. The corresponding method or apparatus according to one embodiment of the present disclosure includes a communications module configured to receive or transmit network communications carried at acoustic wavelengths via an acoustic medium, each of the network communications being defined by a communications protocol among multiple communications protocols. 
     The example embodiment may further include a gate-level digital hardware module communicatively coupled to the communications module and defining therein logic blocks configured to perform respective primitive processing functions, sequences of the logic blocks being capable of processing data units in accordance with any of the multiple communications protocols on a data unit-by-data unit basis without reconfiguring. According to some embodiments, the gate-level digital hardware module may be configured to process a data unit in accordance with a first communications protocol by directing the data unit through a first sequence of logic blocks, and process a subsequent data unit in accordance with a second communications protocol by directing the subsequent data unit through a second sequence of logic blocks. 
     According to at least one other embodiment, the gate-level digital hardware module may include a router defined therein to direct each data unit through respective sequences of logic blocks. In some embodiments, each data unit includes a header specifying a sequence of logic blocks the respective data unit is to be directed along for processing in accordance with a corresponding communications protocol, and each logic block is configured to direct each data unit to a next logic block or to an output port according to the respective sequence specified in the header of the data unit. 
     Some embodiments of the present disclosure further comprise a processor communicatively coupled to the gate-level digital hardware module and configured to select a communications protocol from among the multiple communications protocols, and communicate application data and the selected communications protocol to the gate-level digital hardware module. In some embodiments, the gate-level digital hardware module is further configured to convert the application data into a data unit including a header specifying a sequence of logic blocks the data unit is to be directed along for processing according to the selected communications protocol. 
     According to some embodiments, the gate-level digital hardware module is further configured to receive a data unit from a transmitter device, and assign a header to the received data unit specifying a sequence of logic blocks the received data unit is to be directed along for processing according to a communications protocol. 
     According to some embodiments, the gate-level digital hardware module utilizes a multiplexing source and a multiplexing sink defined therein to direct each data unit through respective sequences of logic blocks. 
     In some embodiments, each sequence of logic blocks corresponds to a communications protocol, and different sequences of logic blocks correspond to different communications protocols. 
     Embodiments of the present disclosure can transmit and receive multiple communications protocols including, but not limited to, any of the following communications protocols: orthogonal frequency-division multiplexing, code-division multiple access, time-division multiple access, frequency-hopping spread spectrum, time-hopping spread spectrum, direct sequence spread spectrum, binary chirp spread-spectrum, and a chirp-based communications protocol. 
     Some embodiments of the present disclosure further include a sensor configured to sense an aspect of the acoustic medium, the processor being coupled to the sensor and further configured to notify another node to change the communications protocol to a next communications protocol more suitable for a sensed change in the acoustic medium. The processor may be further configured to change the configuration parameters as a function of sensed changes of the acoustic medium to enable the logic blocks to process data units of the next communications protocol. In some embodiments, the sensor may be a: temperature sensor, depth sensor, salinity sensor, motion sensor, video camera or other optical sensor, acoustic sensor, and attitude sensor, or combination thereof. 
     In some embodiments, the first communications protocol or the second communications protocol may be a chirp-based communications protocol based on transmitting chirp signals spread over a multidimensional domain spanning code, time, and frequency. In some embodiments, the chirp-based communications protocol may involve chirp-based acoustic pulses with ultrasonic spectral content following a frequency-hopping and time-hopping pattern with a superimposed spreading code. 
     According to some embodiments, the processor may execute software-defined functionalities and define reconfigurable high-level networking protocols (i.e., non-time critical Media Access Control (MAC) functionalities, network, application). In some embodiments, the gate-level digital hardware module controls the physical layer and time-critical MAC layer functionalities. In this way, processing-intensive physical layer functionalities are software-defined, but executed in hardware that can be reconfigured in real-time (using the registers or router of the gate-level digital hardware module, or through partial reconfiguration of the gate-level digital hardware module). Therefore, unlike purely software-defined implementations that introduce high processing latency, which, in turn, limit data rates and unlike pure hardware implementations that lack reconfiguration capabilities, embodiments of the present disclosure are able to provide the low latency and high-data-rate characteristics of hardware implementations, as well as the reconfiguration capabilities of software implementations. 
     Additionally, embodiments of the underwater networking platform may utilize novel acoustic transmission schemes for stealthy underwater communications discussed in detail below. These acoustic transmission schemes (i.e., communications protocols) include chirp-based LPD/LPI underwater acoustic communications with code-time-frequency multidimensional spreading based on transmitting chirp signals that are spread over a multidimensional domain spanning code, time, and frequency. This results in higher LPD/LPI performance compared to protocols that consider only a single dimension (i.e., code or frequency), and provides a hopping-coding pattern that is not easily recognizable or detectable. Moreover, chirp signals are ubiquitous in the underwater environment (e.g., dolphin clicks), and are not easy for an adversary to detect and associate the chirps with a communications system. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The foregoing will be apparent from the following more particular description of example embodiments, as illustrated in the accompanying drawings in which like reference characters refer to the same parts throughout the different views. The drawings are not necessarily to scale, emphasis instead being placed upon illustrating embodiments. 
         FIG. 1A  illustrates an example of an underwater acoustic wireless communications platform that is configured to change communications protocols in a seamless manner based on operating conditions. 
         FIG. 1B  illustrates the hardware architecture of an underwater acoustic wireless communications platform. 
         FIG. 2  illustrates an example software architecture for a processing and programmable logic module. 
         FIG. 3A  illustrates an example embodiment of the processing and programmable logic module implementing a Zero-Padded Orthogonal Frequency-Division-Multiplexing (ZP-OFDM) communications protocol. 
         FIG. 3B  illustrates a block diagram of the physical layer of a processing and programmable logic module implementing the ZP-OFDM communications protocol. 
         FIG. 4A-1  illustrates a block diagram of a processing and programmable module with a gate-level digital hardware module employing a design router block. 
         FIG. 4A-2  depicts example transmitter sequences and example receiver sequences. 
         FIG. 4B  illustrates a block diagram of a processing and programmable module with a gate-level digital hardware module employing a source, a sink, and interconnected logic blocks. 
         FIG. 4C  illustrates a block diagram of a processing and programmable module with a gate-level digital hardware module employing a multiplexing source and a multiplexing sink. 
         FIG. 5  depicts an example format of a data unit, according to some embodiments. 
         FIG. 6A  depicts an example Chirp-Based LPD/LPI communications protocol. 
         FIG. 6B  is a plot of an example channel function with severe multipath. 
         FIG. 6C  is a plot of bit rate error (BER) versus signal to noise ratio (SNR) values for different sets of frequency-hopping frame length, time-hopping frame length, and spreading code length (N f  , N h  , N s ). 
         FIG. 6D  is a spectrogram of an actual LPI/LPD waveform output. 
         FIG. 7  is a schematic of an example wireless energy transfer unit. 
         FIG. 8A  illustrates an example hybrid network topology with centralized and decentralized control. 
         FIG. 8B  illustrates an example application of a hybrid network enabling an underwater Wi-Fi network. 
         FIG. 9  is a block diagram of an example internal structure of a computer in which various embodiments of the present disclosure may be implemented. 
     
    
    
     DETAILED DESCRIPTION 
     A description of example embodiments follows. 
     Embodiments of the present disclosure include underwater wireless technology capable of short-range (i.e., up to 500 m), high-rate, wireless connectivity for unmanned vehicles, scuba divers, and other equipment in areas with underwater infrastructure (e.g., oil rigs) and/or base stations that act as gateway between radio frequency (RF) and acoustic domains. Accordingly, some embodiments are based on orthogonal frequency-division multiplexing (OFDM) schemes (discussed in detail below) and implement resource allocation schemes that assign dynamically time-frequency blocks to devices based on distance, channel, traffic, and other factors. 
       FIG. 1A  illustrates an example of an underwater acoustic wireless communications platform  100  changing communications protocols based on operating conditions. Underwater acoustic communications may be affected by operating conditions, such as distance, depth, temperature, salinity, noise and other traffic; and different communications protocols may be better suited for different operating conditions. Embodiments of the present disclosure enable the underwater acoustic wireless communications platform  100  and other devices or vehicles  101 ,  102  using underwater communications systems to reconfigure processing-intensive physical layer functionalities in hardware during runtime to adapt to changing operating conditions. This allows the underwater acoustic wireless communications platform  100  and other devices or vehicles  101 ,  102  to select a communications protocol to optimize acoustic communications in real-time, without sacrificing the processing speed of hardware-based architectures. 
     In  FIG. 1A , the underwater acoustic wireless communications platform  100  is depicted as communicating with an underwater device  101  under different operating conditions (i.e., operating conditions A and B). For example, the underwater acoustic wireless communications platform  100  may select a first communications protocol  103  to communicate data to the underwater device  101  based on operating conditions A. The selection of the first communications protocol  103  may be based on one or more of the operating conditions (e.g., distance A, depth A, temperature A, lack of other acoustic traffic, salinity level A, etc.). The selection of a communications protocol may be performed based on an algorithm or logic taking into account one or more operating conditions. In some embodiments, the selection may be performed by a general purpose processing unit or a gate-level digital hardware module. In some embodiments, the selection may be based on an input from an external source. 
     As the underwater device  101  moves to a new position, the operating conditions may change, prompting the underwater acoustic wireless communications platform  100  to select a second communications protocol  104  to communicate data to the underwater device  101  based on operating conditions B. Again, the selection of the second communications protocol  104  may be based on one or more of the operating conditions (e.g., distance B, depth B, temperature B, presence of other acoustic traffic (underwater device  102 ), salinity level B, etc.). 
     It should be understood that a command or handshaking may be employed by the platform  100  to cause the underwater device  101  to change its protocol. It should also be understood that the underwater device  101  may signal the platform  100  to change communications protocol. Because embodiments of the invention enable changing communications protocols on a data unit-by-data unit basis, as described in detail below, the change in communications protocol can be performed in real-time, thereby providing a seamless transition. 
     Further, embodiments of the present disclosure may alter parameters of the communications separate from the selection of a new communications protocol. For example, as the distance between the underwater acoustic wireless communications platform  100  and the underwater device  101  becomes smaller, the underwater acoustic wireless communications platform  100  may perform a distance-dependent optimization. One such distance-dependent optimization may be increasing the frequency of the acoustic waves as the underwater device  101  moves closer to the underwater acoustic wireless communications platform  100 . Longer distances require acoustic waves with low frequencies in order for the acoustic waves to propagate over the longer distances. However, when transmitting over shorter distances, it may be useful to use wider bandwidths in the ultrasonic regime and generate a wideband (multicarrier or impulsive) waveform, which, in turn, enables higher data rates. The runtime alteration of frequency allows the underwater acoustic wireless communications platform  100  to maximize the data rate based on distance to the underwater device  101 . 
     Existing hardware-based networking devices are inflexible, and not capable of switching communications protocols during runtime (i.e., in real-time) when operating conditions change. Purely software-defined networking devices may have the capability to change communications protocols during runtime, but do not possess the processing capabilities of hardware-based networking devices. Embodiments of the present disclosure, as described in detail below, provide the flexibility of software-defined networking devices with the processing capabilities of hardware-based networking devices.  FIG. 1B  illustrates the hardware architecture of an example underwater acoustic wireless communications platform  100  (i.e., a network node). According to some embodiments, the underwater acoustic wireless communications platform  100  may include one or more modules held in a pressure housing  150 . The example embodiment illustrated in  FIG. 1B  comprises four modules: a processing and programmable logic module  110 , a communications module  120 , a power module  130 , and a sensor module  140 . In some embodiments, the modules may have distinct, non-overlapping functionalities, and each module may be interfaced to the other modules through standard interfaces. This enables the modules to be swappable and upgradeable, and, in this way, the underwater acoustic wireless communications platform  100  can provide hardware evolution and reconfiguration to support the needs of different applications adequately. 
     According to some embodiments, the processing and programmable module  110  incorporates a general purpose processing unit  112  (e.g., CPU, or ARM processing system) and a gate-level digital hardware component  114  (e.g., a field programmable gate array (FPGA), programmable logic, etc.) on a single-board. The combination of the general purpose processing unit  112  and the gate-level digital hardware component  114  provides hardware and software re-programmability. 
     According to some embodiments, the general purpose processing unit  112  is the heart of the processing system and includes on-chip memory, external memory interfaces, and a rich set of peripheral connectivity interfaces. The architecture of the processing and programmable module  110  provides the combined benefits of (i) an microcontroller that can run an operating system and be programmed through high-level languages (e.g., C++, Python, etc.); and (ii) a gate-level digital hardware component  114  to enable hardware reconfiguration (offline or during runtime) in support of different physical layer protocols and other computationally-intensive data processing operations without sacrificing energy efficiency. The architecture of the processing and programmable module  110  also provides low latency, high throughput, and cache-coherent communications between the gate-level digital hardware component  114  and the processing unit  112 . In this way, processing-intensive functionalities can be software-defined while being executed in hardware (gate-level digital hardware component  114 ). This enables an underwater acoustic wireless communications platform  100  to run functionalities with low latency and still be able to perform reconfiguration in real-time (i.e., during runtime) through registers and partial reconfiguration of the gate-level digital hardware component  114 . 
     According to some embodiments, the general purpose processing unit  112  may include a set of I/O peripherals, including two I2C blocks that can operate both as master and slaves, and a plurality of general purpose input output (GPIO) pins to enable connectivity with virtually any sensors, data converters, and memories. In some embodiments, the general purpose processing unit  112  may be connected to the gate-level digital hardware component  114  through a multilayered advanced microcontroller bus architecture (AMBA) advanced eXtensible interface (AXI) interconnect, which enables multiple simultaneous and continuous data flows. 
     In some embodiments, the general purpose processing unit  112  executes software-defined functionalities to define reconfigurable high-level networking protocols (i.e., non-time critical MAC functionalities, network, and application). The general purpose processing unit  112  may also execute application-specific functionalities. In some embodiments, the gate-level digital hardware component  114  may execute physical layer and time-critical MAC layer functionalities. In this way, processing-intensive physical layer and time-critical MAC functionalities are software-defined, but executed in hardware that can be reconfigured in real-time (e.g., see  FIG. 4A ,  FIG. 4B ,  FIG. 4C  and each figure&#39;s accompanying description). 
     According to some embodiments, the gate-level digital hardware component  114  may include logic blocks configured to perform respective primitive processing functions. These logic blocks themselves may include reconfigurable hardware circuitry that can be individually reconfigured to perform different primitive processing functions. In other words, each logic block itself may be reconfigured to perform a different task (primitive processing function). However, a logic block itself cannot be reconfigured while the logic block is processing data. Reconfiguration of the logic block themselves require each logic block be taken offline to be reconfigured. Embodiments of the present disclosure avoid reconfiguring logic blocks to perform different tasks by directing data units to different logic blocks and/or a different order of logic blocks. 
     It should be noted that adjusting the parameters of a logic block does not necessarily require reconfiguring the logic to alter the task the logic block performs. According to some embodiments of the present disclosure, registers within the gate-level digital hardware component  114  may store and adjust logic block configuration parameters during runtime (in real-time) including parameters such as modulation, coding rate, guard time, subcarrier mapping, number of ZP-OFDM symbols in a data unit. The adjustment of parameters does not require reconfiguring logic blocks to perform different tasks. 
     In some embodiments, the gate-level digital hardware component  114  may process data by directing the data through a consecutive sequence of logic blocks (i.e., from one logic block to the next logic block), each logic block performing a primitive processing function, and the collective sequence of logic blocks performing a complex processing task. 
     Example logic blocks include Fast Fourier Transform (FFT), Inverse FFT (IFFT), FIR filter, Interleaver, De-Interleaver, Scrambler, De-Scrambler, Cyclic Redundancy Check, Convolution Encoder/Decoder, Cyclic Prefix, Carrier Frequency Offset Correction, Pulse Shaping, Forward Error Coding, Automatic Gain Control, and logic blocks that perform Symbol Mapping/Demapping (e.g., Binary Phase Shift Keying, Quadrature Phase Shift Keying, Quadrature Amplitude Modulation). 
     According to some embodiments, the gate-level digital hardware component  114  may change the hardware-level complex processing being performed on a data in real-time by changing the consecutive sequence of logic blocks the data is being directed through. This enables the gate-level digital hardware component  114  to change the processing being executed by its hardware during runtime (e.g., on a data unit-by-data unit basis) without requiring a reconfiguration of the logic blocks themselves. 
     For example, in some embodiments, the complex processing task performed by a collective sequence of logic blocks may be processing units of data (e.g., data frames, data packets, etc.) according to a communications protocol. By changing the collective sequence of logic blocks, the gate-level digital hardware component  114  may change the communications protocol for the subsequent units of data. Thus, this change in communications protocol can be performed on a data unit-by-data unit basis without requiring a reconfiguration of the logic blocks themselves. 
     According to some embodiments, the gate-level digital hardware component  114  may include up to 53,000 look-up-tables (LUTs), 85,000 logic cells, and 220 DSP slices in a chip scale package (17×17mm). The gate-level digital hardware component  114  may further include a set of digital signal processing (DSP) functional logic blocks, thereby enabling the general purpose processing unit  112  to off-load computationally expensive MCU operations to the gate-level digital hardware component  114 . 
     According to some embodiments, the communications module  120  enables acoustic wireless connectivity through data converters, power/low-noise amplifiers, and an acoustic transducer  129 . In some embodiments, the acoustic transducer  129  may be a receiver hydrophone with an operational frequency range from 1 Hz to 170 kHz. The transducer may have a flat receiving sensitivity of −211 [dB re 1V/μPa at 1 m] over the operational frequency range, and a maximum transmit sensitivity of 130 [dB re 1 μPa/V at 1 m] at 100 kHz. The transducer may produce a directivity pattern that is omnidirectional in the horizontal axis and 270° in the vertical axis. 
     According to some embodiments, the communications module  120  may include two transducers, each transducer operating on different parts of the acoustic spectrum. In addition to the transducer described above, the communications module  120  may include a second transducer with an operational frequency range from 10 kHz to 800 kHz. This transducer was selected to operate over portions of the spectrum that above transducer is not able to cover. The second optional transducer may have a receiving sensitivity of −228 [dB re 1V/μPa at 1 m] that is relatively flat over the operational frequency range and transmitting sensitivity of 138 [dB re 1 μPa/V at 1 m] at 700 kHz. Moreover, the second optional transducer may have omnidirectional horizontal and 60°-120° vertical directivity patterns. 
     In some embodiments, the communications module  120  includes a transmitter (Tx) chain  121  and a receiver (Rx) chain  122 . The Rx chain  122  may include a low-noise amplifier (LNA)  126  and an analog-to-digital converter (ADC)  124  to amplify and digital-convert received signals. The Tx chain  121  may include a digital-to-analog converter (DAC)  123  and a power amplifier (PA)  125  to analog-convert and amplify the digital waveforms before transmission. In some embodiments, the Tx chain  121  may also include a matching circuitry (MC)  127  to match the input impedance of the acoustic transducer  129  with the output impedance of the PA  125  to minimize the amount of signal that is reflecting back to the PA  125  and not transmitted. 
     According to some embodiments, the communications module  120  further includes an electronic switch  128  that enables the use of a single acoustic transducer  129  for both transmitting and receiving acoustic signals in a time-division fashion. 
     In some embodiments, the communications module can alternatively be a radio frequency (RF) communications module, or any other type of communications module (e.g., optical, etc.). Some embodiments of the underwater acoustic wireless communications platform  100  may include multiple different communications modules. For example, the underwater acoustic wireless communications platform  100  may include both a RF communications module and an acoustic communications module, enabling the underwater acoustic wireless communications platform  100  to function as a gateway between an underwater area network and RF network. 
     Referring back to  FIG. 1B , according to some embodiments, the power module  130  may include a central battery unit  132  that provides power to the underwater acoustic wireless communications platform  100 . In some embodiments, the power module  130  may further include one or more energy harvesting transducers  135  interfacing with a wireless energy transfer unit  137  that enables the central battery unit  132  to be recharged wirelessly through acoustic waves. 
     According to some embodiments, the sensor module  140  provides an interface for several different sensors through either standard analog interfaces, such as ADC, or digital interfaces, such as Serial Peripheral Interface (SPI). 
       FIG. 2  illustrates an example software architecture  200  for the processing and programmable logic module  110 , according to some embodiments. In some embodiments, the software architecture  200  may depend on the operating system (e.g., Linux) running on the general purpose processing unit  112  and communicating with the gate-level digital hardware component  114  using advanced eXtensible interface (AXI)  221 . In some embodiments, all physical layer  250  functionalities as well as the time-critical MAC functionalities may be implemented in the gate-level digital hardware component  114 , while non-time critical MAC, network, and application layer  210   a ,  210   b  functionalities may be executed on the general purpose processing unit  112 . 
     According to some embodiments, the software architecture  200  may include a physical layer  250  comprising logic blocks and libraries for processing data in accordance with different communications protocols and forward error correction (FEC) techniques. Specifically, the communications protocols may include a Zero-Padded Orthogonal Frequency-Division-Multiplexing (ZP-OFDM) protocol and a Binary Chirp Spread-Spectrum (B-CSS) protocol, and the error correction techniques may include Reed-Solomon (RS) codes and convolutional codes. 
     In some embodiments, the physical layer  250  includes logic blocks configured to perform respective primitive processing functions. For example, these primitive processing functions may include symbol mapping, Fast Fourier Transform (FFT), as well as filters to enable fast implementation and prototyping of new physical layer protocols. 
     According to some embodiments, the software architecture  200  may host a set of data-link layer libraries ( 220   a  and  220   b ) implementing different MAC protocols, network topology configurations, and physical layer adaptation mechanisms. The data link layer  220   a  of the general purpose processing unit  112  may implement the non-time critical MAC protocols, and the data-link layer  220   b  of the gate-level digital hardware component  114  may implement the time-critical MAC functionalities. 
     In some embodiments, the data link layer  220   a  may implement different MAC protocols, including Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA) and ALOHA, as well as a set of primitive functions, including retransmissions, timers, checksum-based error control, and idle listening, to enable the implementation of different MAC protocols (e.g., time-division multiple access (TDMA) based protocols such as slotted floor acquisition multiple access (FAMA)). 
     CSMA/CA is a medium access control (MAC) technique that depends on a carrier sensing mechanism for preventing collisions with on-going transmissions. Specifically, when a network node starts a data transmission, it first senses the medium for a certain amount of time (in the order of inter-frame space duration). When the network node senses the medium continuously idle, it starts the transmission process. However, CSMA/CA is known to be less effective because of the long propagation delays in the UW-A channel, but CSMA/CA can be a viable option for very short or short communication links. 
     ALOHA is a medium access control protocol based on random access. If a network node wants to transmit a packet, it accesses the medium without sensing. Each successful transmission is acknowledged by the receiver; otherwise, the transmitter node concludes that a collision has occurred. In this case, the transmitter waits for a random time interval (i.e., back off time) and retransmits the packet. Embodiments of the present disclosure offer the flexibility and real-time reconfiguration capability to switch between different protocols depending on the transmission scenario. This enables embodiments of the present disclosure to switch seamlessly between multiple MAC protocols on a data unit-by-data unit basis to maximize the attributes of the multiple MAC protocols. 
     In some embodiments, the data link layer  220   a  can support different network topology configurations. For example, the data link layer  220   a  of the software architecture  200  may support network nodes of underwater acoustic network (UAN) devices that can operate in networks with both centralized and decentralized control. In networks with centralized control, one network node is assigned to be the central (master) node, and the central node coordinates the rest of the network nodes. 
     According to some embodiments, the central node (e.g., the underwater acoustic wireless communications platform  100 ) may have higher computational and memory resources than the other network nodes (e.g., sensors equipped with a transmitter and/or a receiver). In some embodiments, the central node might also take the role of gateway between underwater acoustic and terrestrial networks, in which case the central node supports RF communications in addition to acoustic communications capability. For example, such a configuration can be used for UAN applications that require real-time and continuous monitoring, where the data collected in the network is sent to the central node. Subsequently, the central node transfers the collected data to a shore station or a database through its RF communications module. 
     In some embodiments, the data link layer  220   a  can also support network configurations with decentralized control, where each network node acts as a peer without the control of any central identity. Such configurations can be useful in UAN applications to reach higher ranges or save energy by exploiting multi-hop links. 
     Referring back to  FIG. 2 , according to some embodiments, the data link layer  220   a  may incorporate a physical layer adaptation mechanism that provides network nodes with the capability to adapt/change in real-time their respective physical layer scheme. For example, the physical layer adaptation mechanism enables network nodes to change the modulation, FEC coding rate, guard interval size, and symbol duration of their physical layer schemes. Further, according to some embodiments, the software architecture  200  can perform cross-layer adaptation that allows network layers  230  and data-link layers  220   a  and  220   b  to reconfigure physical layer  250  parameters. As a result, the software architecture  200  can define different decision methods to adapt its behavior based on the current channel requirements and different application needs. 
     According to some embodiments, the software architecture  200  includes a network layer  230  to support IPv4 and IPv6 protocols through an adaptation layer that provides IP header compression, IP packet fragmentation, and optimizes the traditional IPv4 and IPv6 headers for underwater acoustic channels to minimize the overall network delay and energy consumption. Additionally, because the network layer  230  of the software architecture  200  supports IPv4 and IPv6 protocols, network nodes in UANs incorporating the software architecture  200  are able to interoperate with traditional IP networks. For example, such interoperation is illustrated in  FIG. 8A  between underwater acoustic network  810  and terrestrial network  820  (which may be a traditional IP network). 
     Referring back to  FIG. 2 , according to some embodiments, the software architecture  200  includes an application layer  210   a  to support different operational needs. For example, the application layer  210   a  can configure network nodes to operate either as a sink node, which collects data from the network, as a source node, which sends its sensed data to another network node, or as a relay node that forwards collected data to another network node. In some embodiments, the application layer  210   a  includes video encoders and decoders for supporting real-time video transmission. Additionally, the application layer  210   a  may be implemented to port data to and from existing applications previously developed in the operating system&#39;s environment. 
     According to some embodiments, the software architecture  200  includes an application layer  210   b  to provide support for interfacing different sensor units ( 241  and  242 ), either through ADCs in the analog domain  244 , or through the digital domain  243  with standard serial communications protocols (e.g., SPI). 
     As stated above, according to some embodiments, the underwater acoustic wireless communications platform  100  may utilize the software architecture  200 .  FIG. 3A  illustrates an example embodiment of the processing and programmable logic module  110  implementing a Zero-Padded Orthogonal Frequency-Division-Multiplexing (ZP-OFDM) communications protocol. Similarly,  FIG. 3B  illustrates a block diagram of the physical layer  250  of the processing and programmable logic module  110  implementing a ZP-OFDM communications protocol. 
     According to some embodiments, the ZP-OFDM communications protocol defines a packet format where N OFDM symbols are preceded by a preamble packet that is used for packet detection and coarse time synchronization. In some embodiments, the ZP-OFDM communications protocol includes two types of preamble blocks, pseudo-noise (PN)-sequence blocks and chirp blocks. 
     According to some embodiments, the gate-level digital hardware component  114  instantiates ZP-OFDM transmitter logic blocks  310   a - h , ZP-OFDM receiver logic blocks  320   a - m , registers  330 , an AXI4-Lite interface  302 , and an AXI Direct Memory Access (DMA) interface  301  and  303 . DMA enables continuous data flow to the DAC  123  without the involvement of the processor processing unit  112 . In some embodiments, the gate-level digital hardware component  114  includes a plurality of logic blocks for one or more communications schemes, and among the plurality of logic blocks are the ZP-OFDM transmitter  310  logic blocks  310   a - h  and ZP-OFDM receiver  320  logic blocks  320   a - m . The gate-level digital hardware component  114  may include other logic blocks not needed to implement the ZP-OFDM communications protocol, but are available to the gate-level digital hardware component  114  if the communications protocol should be altered. 
     According to some embodiments, a sequence of logic blocks  310   a - h  corresponding to the ZP-OFDM transmitter  310  is depicted in  FIG. 3A  and  FIG. 3B . In some embodiments, the general purpose processing unit  112  sends data units (i.e., information bits or a sequence of information bits) to the input first in, first out (FIFO) logic block  310   a  of ZP-OFDM transmitter sequence  310  through AXI DMA interface  301 . In other embodiments, the data units may be received by the FIFO logic block  310   a  from another source or via another type of interface. The inputted data units may then be directed to the Forward-Error-Correction (FEC) encoder (i.e., convolutional encoder, turbo encoder, etc.) logic block  310   b  to be encoded. Next, the encoded data units are passed to the symbol mapping logic block  310   c , wherein the encoded data units are mapped into symbols according to a selected modulation scheme. 
     In some embodiments, the gate-level digital hardware component  114  may further include other FEC encoder logic blocks or symbol mapping logic blocks. The other FEC encoder logic blocks or symbol mapping logic blocks may differ in some respect, for example the other FEC encoder logic block may use a different coding scheme or the other symbol mapping block may have a different modulation scheme. By having access to multiple logic blocks that perform the same overall function, but perform that overall function differently, the gate-level digital hardware component  114  may change attributes of the ZP-OFDM transmitter by directing data units to the alternate logic blocks on a data unit-by-data unit basis. One of skill in the art would recognize that this flexibility and configurability could be applied to any type of logic block, performing any type of primitive processing functions. 
     Referring back to  FIG. 3A  and  FIG. 3B , according to some embodiments, the symbols generated from the encoded data units are directed to the OFDM subcarrier allocation logic block  310   d , where they are allocated to different subcarriers alongside with pilot and null subcarriers based on a predefined scheme to form the OFDM symbols. Next, the formed OFDM symbols are then directed to the inverse fast Fourier transform (IFFT) logic block  310   e  to be translated to the time-domain. The output of the IFFT logic block  310   e  is then directed to the zero-padding logic block  310   f  to generate ZP-OFDM symbols. The generated ZP-OFDM symbols are directed to the pseudo-noise (PN) sequence logic block  310   g  where they are translated into a packet format, which includes a preamble (PN sequence) and N ZP-OFDM symbols. Next, the generated packets are directed to an up mixer logic block  310   h , where they are up-converted to the pass-band frequency and sent to the DAC for being converted to the analog domain and transmitted. 
     A sequence of logic blocks  320   a - m  corresponding to the ZP-OFDM receiver  320  is depicted in  FIG. 3A  and  FIG. 3B , according to some embodiments. In some embodiments, the gate-level digital hardware component  114  may receive signals from the ADC. The received symbols may be first fed into a high-pass filter (HPF) logic block  320   a  to eliminate DC offset and out-of-band noise. Next, the filtered signals may be directed to a packet detector logic block  320   b  that performs an energy-level collection based method for packet detection. Next, the detected packets may be directed to a down-mixer logic block  320   c  to be down-converted into baseband signals. The baseband signals may then be directed to a low-pass filter (LPF) logic block  320   d  to eliminate higher frequency harmonics. The filtered baseband signals may then be directed to a synchronization logic block  320   e , where the correlation properties of the PN sequence in the transmitted packet are leveraged to obtain coarse time (packet) synchronization. Following the packet synchronization, each ZP-OFDM packet may be portioned into individual OFDM symbols by a block partition logic block  320   f.    
     According to some embodiments, the data is directed to a fast Fourier transform logic block  320   g  to translate the OFDM symbols into the frequency domain, and then each OFDM symbol is passed through a Doppler scale estimation logic block  320   h  and a channel estimation and equalization logic block  320   i  performing compensation based on pilot and null subcarriers, pilot-tone based channel estimation, and zero-forcing (ZF) channel equalization. Next, the data is directed to a symbol detection block  320   j . The detected symbols may be translated into bits and decoded by FEC decoder logic block  320   l . Finally, the decoded bits may be directed to the FIFO logic block  320   m  and sent to the general purpose processing unit  112  through an AXI DMA interface  303 . 
     According to some embodiments, the registers  330  of the gate-level digital hardware component  114  may be responsible for storing and reconfiguring the physical layer configuration parameters written by the general purpose processing unit  112  and sent to the registers  330  through the AXI4-Lite interface  302 . In some embodiments, the gate-level digital hardware component  114  may control and reconfigure the physical layer configuration parameters in real-time. For example, the physical layer configuration parameters may include modulation, coding rate, guard time, subcarrier mapping, number of ZP-OFDM symbols in a packet. 
     Some embodiments further include a register controller that delivers updated parameters stored in the registers to the corresponding logic blocks. The parameters may be updated as a result of a reconfiguration (adaptation) decision making that takes place either in the processing system or in the gate-level digital hardware module. In some embodiments, whenever the processing system or the gate-level digital hardware module updates any of the registers, the register controller is triggered to access the register content and deliver it to the corresponding logic block. 
       FIG. 4A-1  illustrates a block diagram of an example embodiment of the processing and programmable module  110 , with the gate-level digital hardware module  114  employing a design router block  460 . In some embodiments, the design router block  460  enables the seamless arrangement of the sequence of physical layer logic (processing) blocks in real-time. According to this embodiment, each logic block is connected to the design router  460  and assigned a unique ID. The design router  460  acts as a FIFO that carries data between logic blocks  411 - 417  according to processing maps that are used to define different physical layer schemes with different sequences of logic blocks  410   a  and  410   b . The processing maps are dictated to the design router  460  through the register controller  431 . Besides the logic blocks  411 - 417 , the design router  460  is connected to link layer (device driver)  290  processing blocks through AXI buses, to send/receive information to/from upper layers, and to the communications module to transmit/receive information to/from the physical world. 
     For example,  FIG. 4A-2  depicts an example transmitter sequence  410   a  and an example receiver sequence  410   b . In some embodiments, the transmitter sequence (Block  411 , Block  412 , Block  413 )  410   a  may correspond to the processing necessary to transmit a data unit  401   a  (or information bits) according to a particular communications protocol. According to some embodiments, the data unit  401   a  having a first format may be sent to the design router  460  to be processed in accordance with a first communications protocol by flowing through transmitter sequence  410   a , where the transmitter sequence  410   a  corresponds to the first communications protocol. The processed data unit  401   b  that results from the transmitter sequence  410   a  processing may be sent to a communications module to be transmitted using the first communications protocol. 
     Further, a data unit  402   b  may be received from the communications module having been transmitted from another source using the first communications protocol. Similarly, the data unit  402   b  may be sent to the design router  460  to be processed in accordance with the first communications protocol by flowing through receiver sequence  410   b . The processed data unit  402   a  that results from the receiver sequence  410   b  may now be in the first format and be sent to a general purpose processing unit (or another destination) for further processing. 
     According to some embodiments, the processing and programmable module  110  is able to switch the communications protocol by causing the design router to use a different transmitter sequence corresponding to a different communications protocol (e.g., a second communications protocol). This switch may be performed based on a change in operating conditions, wherein the second communications protocol is a better suited to the current operating conditions. As shown in  FIG. 4A-2 , the change in communications protocol can be performed on a data unit-by-data unit basis, because the logic blocks  411 - 417  are pre-existing and the order of the sequence is easily modified by directing the data unit through the logic blocks in a different order using the design router  460  as described above. 
     According to some embodiments, a subsequent data unit  403   a  having the first format may be sent to the design router  460  to be processed in accordance with the second communications protocol by flowing through transmitter sequence  410   c ; transmitter sequence  410   c  corresponding to the second communications protocol. The processed data unit  403   b  that results from the transmitter sequence  410   c  may be sent to the communications module to be transmitted using the second communications protocol. 
     Further, a data unit  404   b  may be received from the communications module having been transmitted from another source using the second communications protocol. Similarly, the data unit  404   b  may be sent to the design router  460  to be processed in accordance with the second communications protocol by flowing through receiver sequence  410   d . The processed data unit  404   a  that results from the receiver sequence  410   d  may now be in the first format and sent to the general purpose processing unit for further processing. 
       FIG. 4B  illustrates a block diagram of another example embodiment of the processing and programmable module  110  with a gate-level digital hardware module  114  employing a source  481 , a sink  482 , and interconnected logic blocks  411 - 417 . According to the example embodiment of  FIG. 4B , each of the logic blocks  411 - 417  is interconnected individually to each other logic block, and each logic block is assigned a unique ID. Further, each of the logic blocks is interconnected with the source block  481  and sink block  482 . This organization of interconnections enables the seamless arrangement of the sequence of physical layer logic (processing) blocks during runtime. 
     In some embodiments, each data unit includes a header specifying a sequence of logic blocks (e.g.,  410   e  or  410   f ) that the respective data unit is to be directed along for processing in accordance with a corresponding communications protocol, and wherein each logic block is configured to direct each data unit to a next logic block or to a sink block according to the respective sequence specified in the header of the data unit. The header in each data unit may be injected by a source block  481  through the register controller  431 . Besides injecting the header to each data unit, the source  481  and sink  482  blocks may be connected to the data link layer  220   a  through AXI buses, to send/receive information to/from upper layers, and to the communications module to transmit/receive information to/from the physical world. 
     For example,  FIG. 4B  depicts an example transmitter sequence  410   e  and an example receiver sequence  410   f . In some embodiments, the transmitter sequence  410   e  (Block  411 , Block  412 , Block  413 ) may correspond to the processing necessary to transmit a data unit (or information bits) using a particular communications protocol. The processing and programmable module  110  is able to switch the communications protocol by generating a header specifying a different transmitter sequence corresponding to a different communications scheme. This change in communications protocol can be performed on a data unit-by-data unit basis, because the logic blocks are pre-existing, and an order of the sequence is easily modified by directing the data unit through the logic blocks in a different order using the header as described above. This applies to the receiver sequence as well. 
       FIG. 4C  illustrates a block diagram of another example embodiment of the processing and programmable module  110  with the gate-level digital hardware module  114  employing a multiplexing sources  483 ,  485  and multiplexing sinks  484 ,  486 . According to this example embodiment, the logic blocks  411 - 425  may be connected to each other to form transmitter and receiver sequences  410   g - j  of different communications protocols. Each transmitter sequence  410   g ,  410   h  or receiver sequence  410   i ,  410   j  is preceded by a multiplexing source block  483 ,  485  and followed by a multiplexing sink block  484 ,  486 . In some embodiments, the multiplexing source blocks  483 ,  485  are used to direct each data unit to a transmitter sequence  410   g ,  410   h  or a receiver sequence  410   i ,  410   j  according to a selected communications protocol. In some embodiments, the selected communications protocols may be dictated to the multiplexing source blocks  483  through the register controller  431 . Similarly, the selected communications protocols may be dictated to the multiplexing sink blocks  486  through the register controller  431 , which enables each data unit to be carried to the link layer  290  through AXI buses, to send/receive information to/from upper layers, and to the communications module to transmit/receive information to/from the physical world. 
     For example,  FIG. 4C  depicts two example transmitter sequences  410   g ,  410   h  and two example receiver sequences  410   i ,  410   j . In some embodiments, the first transmitter sequence (Block  411 , Block  412 , Block  413 )  410   g  may correspond to the processing necessary to transmit a data unit (or information bits) using a first communications protocol, and the second transmitter sequence (Block  414 , Block  415 , Block  416 , Block  417 )  410   h  may correspond to the processing necessary to transmit a data unit (or information bits) using a second communications protocol. The processing and programmable module  110  is able to switch the communications protocol by causing the multiplexer source  483  to switch the transmitter sequence. This change in communications protocols can be performed on a data-unit by data unit basis, because the logic blocks are pre-existing and the order of the sequence is easily modified by directing the data unit through the logic blocks in a different order (sequence) as described above. This applies to the receiver sequences  410   i ,  410   j  as well. 
     The above embodiments have been described as implementing different communications protocols. More specifically, the communication protocols may include a Zero-Padded Orthogonal Frequency-Division-Multiplexing (ZP-OFDM) protocol and a Binary Chirp Spread-Spectrum (B-CSS) protocol, and the error correction techniques may include Reed-Solomon (RS) codes and Convolutional codes. 
     One of ordinary skill in the art would recognize that embodiments of the present disclosure may be configured to utilize any number of communications protocols. As stated and explained above, some embodiments may utilize a ZP-OFDM protocol. OFDM is a widely used communications protocol for under water acoustic (UW-A) systems, because of OFDM&#39;s robustness against frequency-selective channels with long delay spreads. Some embodiments of the underwater acoustic wireless communications platform  100  may adopt an OFDM protocol with zero-padding, where each OFDM symbol is followed by padded zeros. ZP-OFDM is more energy-efficient compared to its counterparts (e.g., cyclic-prefixing (CP)). According to some embodiments, the underwater acoustic wireless communications platform  100  may, in each OFDM symbol, accommodate KP pilot subcarriers to be used in the channel estimation and fine symbol synchronization. Embodiments may also include KN null subcarriers for Doppler estimation and KD data subcarriers, which are conventionally modulated with either M-Phase-Shift-Keying (PSK) or M-Quadrature-Amplitude-Modulation (QAM), for data transmission. 
     According to some embodiments, the underwater acoustic wireless communications platform  100  may utilize a data unit (e.g., packet) format  500 , as illustrated in  FIG. 5 . The data unit format depicted in  FIG. 5  includes N OFDM symbols  502  preceded with a preamble block  504  that provides packet detection and coarse symbol synchronization. In some embodiments, the underwater acoustic wireless communications platform  100  may provide an option to select the preamble block  504  to be either a pseudo noise (PN)-sequence or a chirp signal based on the network and application requirements. 
     Binary Chirp Spread-Spectrum (B-CSS) is another communications protocol that embodiments of the present disclosure may utilize. B-CSS is based on chirp signals that are well-known to be resilient against severe multipath and Doppler effects that are the main characteristics of an UW-A channel. B-CSS has been used in UW-A communications, and especially in links that require relatively low data rate but high reliability, such as feedback links. Furthermore, B-CSS is characterized by a very low complexity correlation-based receiver architecture that dramatically decreases the computational complexity. 
     According to some embodiments, the underwater acoustic wireless communications platform  100  may utilize a novel chirp-based LPD/LPI (Low Probability of Detection/Low Probability of Interception) underwater acoustic communications protocol with code-time-frequency multidimensional spreading. Many of the approaches designed to achieve efficient underwater communications at the physical layer of the communications protocol stack have mostly been focused on designing spectrally efficient yet robust modulation schemes and receivers to operate on the limited bandwidth available in the underwater acoustic channel. Yet, existing technology in this domain is for the most part based on transmitting well-recognized, easily detectable narrowband signals modulated over low-frequency carriers at high transmission powers, which ultimately limits the stealthiness of the communication scheme and LPD/LPI performance. 
     Typically, stealthy communications protocols adopt the approach of direct-sequence spread spectrum (DSSS) techniques with either coherent or non-coherent modulations. The main motive behind this approach is to take advantage of the processing gain that comes from spread-spectrum encoding, which enables communications to be carried out at relatively low signal levels and achieve high LPD/LPI performance. An alternative approach is to exploit frequency diversity instead of coding to achieve processing gain. While these protocols and technique may work for some applications, there is clearly significant room to improve the LPD/LPI performance of underwater communications protocols. 
     A novel communications protocol based on transmitting chirp signals that are further spread over a multidimensional domain spanning code, time, and frequency is described below. The following chirp-based LPD/LPI protocol is a robust LPD/LPI transmission scheme that uses chirp-based acoustic pulses with ultrasonic spectral content following a frequency-hopping pattern and time-hopping pattern together with a superimposed spreading code. The chirp-based LPD/LPI protocol is designed to enable higher LPD/LPI performance compared to state-of-the-art schemes that consider only a single dimension (i.e., code, time, or frequency) and provides a hopping-coding pattern that (i) is not easily recognizable or detectable by an adversary; and (ii) can be robustly detected in adverse channels by a friendly receiver that is aware of the frequency-time hopping pattern, and the spreading code being used. 
     Some embodiments of the chirp-based LPD/LPI protocol are based on the principle of transmitting a chirp signal with a frequency-hopping pattern and time-hopping pattern following pseudo-random sequences, and with a superimposed spreading code. Chirp-based transmission, frequency-hopping and time-hopping patterns, and spread-spectrum encoding enables a communications protocol with high LPI/LPD performance, receiver performance that is robust and resilient against severe channel effects (i.e., multi-path, scattering, and Doppler), and hardly identifiable characteristics that are not easily associated with the specific system employing them. 
     In general, chirp modulation or linear frequency modulation (LFM) was first used in in the 1960s. Since then, chirp signals have been used as a communication technology that can enable low data rate, robust, low-power (LPD/LPI) wireless communications on simple-design, low-cost transceivers in different applications including indoor wireless communications, multiuser applications, and WLAN/WPAN applications. 
     The characteristics of chirp transmissions appear to ideally address the requirements of an LPI/LPD protocol/scheme. First, their high processing gain (time-bandwidth product) and resilience against severe channel effects (e.g., multipath, scattering, Doppler effect, etc.) enables high LPD/LPI performance, because strong reception performance under low signal-to-noise (SNR) conditions reduces the need for high transmission power. Second, the wideband nature of chirp signals results in high LPD/LPI performance, because the low power spectral density reduces the probability of detection and intercepts. Third, chirp signals are ubiquitous in the underwater environment (e.g., dolphin clicks). Therefore, they cannot be easily associated with a specific communication system. Fourth, chirps can be easily generated with mostly digital processing, and the data rate can be flexibly traded for power spectral density and range. 
       FIG. 6A  depicts an example chirp-based LPD/LPI protocol having a combined frequency- and time-hopping strategy that defines a frequency spectrum B t  divided in N f  sub-bands of bandwidth B s  and a slotted time divided in chips of duration T c , with chips organized in frames of duration T f =N h ·T c  where N h  is the number of chips per frame. Specifically, the example chirp-based LPD/LPI protocol of  FIG. 6A  is an ongoing transmission using frequency hopping sequence FH={2,0,3}, time hopping sequence TH={2,3,3}, and BOK spreading codes SC={1, −1, −1}. 
     According to some embodiments, a network node may perform the chirp-based LPD/LPI protocol by transmitting one chirp signal in one chip per frame on one sub-band, and determining in which chip and sub-band to transmit based on a time hopping sequence (THS) and a frequency hopping sequence (FHS), respectively. Both time and frequency hopping sequences are based on pseudo-random sequences generated by seeding random number generators. In some embodiments, a channel coding scheme may be introduced to improve the receiver performance against channel non-idealities. According to some embodiments, each information bit may be represented with psuedo-orthogonal spreading codes because of (i) limited computational complexity, and (ii) inherent resilience to multipath channel effects. 
     A chirp signal is characterized by a time-varying instantaneous frequency, which changes in time from an initial value f 0  to a final value f 1 . In the time domain, the signal can be expressed as 
                     c   ⁡     (   t   )       =     {           A   ⁢           ⁢     cos   ⁡     (       2   ⁢   π   ⁢           ⁢     f   0     ⁢   t     +     πμ   ⁢           ⁢     t   2         )                 0   ≤   t   ≤   T     ,             0         otherwise   ,                     (   1   )               
where A is the amplitude of the chirp, f 0  is the initial chirp frequency,
 
             μ   =         f   1     -     f   0       T           
is the chirp frequency-variation rate, while T represents the chirp period. For the purposes of this disclosure, a chirp with parameter μ&gt;0 is an up-chirp; otherwise the chirp is a down-chirp. Up and down chirp signals are almost orthogonal to each other. The total bandwidth of the chirp signal can be obtained as B=f 1 −f 0 .
 
     The train of chirps may be modulated based on binary orthogonal keying (BOK) by leveraging the quasi-orthogonality of up and down-chirps by encoding a ‘1’ information symbol with an up-chirp and a ‘−1’ information symbol with a down-chirp. The signal s(t, i) generated by the system to convey the i th  symbol can be expressed based on (1) as 
                       t   ^     =     (     t   -       c   i     ⁢     T   c       -   iTf     )       ,           (   2   )                 s   ⁡     (     t   ,   i     )       =     {           cos   ⁡     (       2   ⁢   π   ⁢           ⁢     f   kt     ⁢     t   ^       +       (     1   -     d   i       )     ⁢   π   ⁢           ⁢     B   s     ⁢     t   ^       +       d   i     ⁢   πμ   ⁢           ⁢       t   ^     2         )               0   ≤     t   ^     ≤     T   c       ,             0       otherwise                   (   3   )               
where
 
               μ   =       B   s       T   c         ,         
{c i } is the time hopping sequence, with 0≤c i ≤N h −1, {k i } is the frequency hopping sequence, with 0≤k i ≤N f −1, {d i } is the information-bearing sequence, d i  ∈ {−1, 1}, and the amplitude of the chirp is assumed to be ‘1’ without loss of generality. The resulting data rate, in chirps per second, is expressed as
 
     
       
         
           
             
               
                 
                   
                     R 
                     ⁡ 
                     
                       ( 
                       
                         N 
                         h 
                       
                       ) 
                     
                   
                   = 
                   
                     
                       1 
                       
                         T 
                         f 
                       
                     
                     = 
                     
                       
                         1 
                         
                           
                             N 
                             h 
                           
                           ⁢ 
                           
                             T 
                             c 
                           
                         
                       
                       . 
                     
                   
                 
               
               
                 
                   ( 
                   4 
                   ) 
                 
               
             
           
         
       
     
     By regulating the FH frame length N f  and TH frame length N h , (i.e., the average inter-chirp time), a network node can adapt its transmission rate, processing gain, and as a consequence modify the average radiated power, and therefore the communication range of the system. 
     In some embodiments, at the receiver, frame synchronization and “time hopping” synchronization may be performed to properly decode the received signal. Frame synchronization may consist of finding the correct time alignment between the transmitter frame and the receiver frame. In some embodiments, this is achieved through an energy-collection approach. During the frame synchronization, the transmitter sends a-priori-known sequence, (i.e., a preamble). Specifically, a Doppler-sensitive sequence (i.e., m-sequence) may be used to leverage Doppler scale estimation. In some embodiments, after correlating the received signal and the preambles pre-scaled by different Doppler scaling factors, the receiver may identify both the starting point of the frame as the time instant and the estimated Doppler scale based on the largest correlation peak. 
     According to some embodiments, the next step may consist of finding the frequency-hopping and time-hopping sequences to hop chip-by-chip and correlate the received chirps. This is achieved by seeding the random generator with the same seed used by the transmitter, and therefore generating the same pseudo-random frequency-hopping and time-hopping sequences. Once both synchronization processes have been accomplished, the receiver decodes the received signal by “listening” in the time chips of interest and correlating the received chirp according to the modulation scheme in use. 
     A channel code can reduce the effect of channel non-idealities and accordingly increase the receiver performance. Various channel coding solutions have been proposed with different performance levels and computational complexity. Some embodiments of the chirp-based LPD/LPI protocol rely on pseudo-orthogonal spreading codes because of their limited computational complexity and inherent resilience to multipath. Each symbol (i.e., bit) is spread by multiplying it by a binary code before transmission. At the receiver side, with prior knowledge of the code used at the transmitter, the signal can be de-spread, and the original information recovered. 
     Some embodiments of the chirp-based LPD/LPI protocol utilize BOK-spreading modulation scheme. In BOK-spreading, an information bit is spread using BOK-modulated chips, consequently the pseudo-orthogonal spreading code can be defined as a pseudorandom code of N s , chips with a j  ∈ {−, 1}. With frequency- and time-hopping, (2) and (3) can be rewritten as
 
 {circumflex over (t)} =( t−c   j   T   c   −jT   f )   (5)
 
 s ( t, i )=Σ j=0   N     s     −1  cos(2π fk   j   {circumflex over (t)} +(1−( a   j   d   i ))π B   s   {circumflex over (t)} +( a   j   d   i )πμ {circumflex over (t)}   2 ), 0 ≤{circumflex over (t)}≤T   c    (6)
 
where chip information is carried in the quasi-orthogonality up-chirps and down-chirps.  FIG. 6A  shows an example of a combined frequency-hopping and time-hopping and BOK-spreading strategy. Since the spreading operation associates N s  chips to one information bit, the information rate will now be
 
                 R   ⁡     (       N   h     ,     N   s       )       =       1       N   s     ⁢     T   f         =     1       N   s     ⁢     N   h     ⁢     T   c             ,         
while the energy per bit is increased by a factor N s . Note that there is a tradeoff between robustness to noise and multipath (which increases with longer spreading codes), and energy consumption and information rate.
 
     In BOK-spreading, the receiver can use the spreading code employed at the transmitter to obtain the correlator template. As a result, it is important to observe that unlike BPSK-modulated chirp signals that need a coherent receiver with accurate channel knowledge for decoding, a simple non-coherent energy detector receiver is sufficient. The latter requires frame synchronization only, and its implementation complexity is significantly lower. 
     According to some embodiments, before processing, the signal-to-noise ratio (SNR) at the receiver can be expressed as 
                       SNR   int     =     Pg   η       ,           (   7   )               
where P is the average power per chirp signal emitted by the transmitter, g is the path gain between the transmitter and the receiver, and η is the noise energy. Chirp signals offer a processing gain proportional to the time-bandwidth product (TB), which enables higher signal-to-noise ratio (SNR) at the receiver after processing. Unlike narrowband pulses, T and B of chirp signals can be increased independently to reach higher processing gain, and accordingly higher receiver SNR. The processing gain can be expressed as
 
     
       
         
           
             
               
                 
                   PG 
                   = 
                   
                     
                       TB 
                       0.886 
                     
                     . 
                   
                 
               
               
                 
                   ( 
                   8 
                   ) 
                 
               
             
           
         
       
     
     In addition to the processing gain, the receiver has SNR gain that is introduced by the spreading code. As a result, the SNR for chirp transmission at the receiver after processing can be expressed as 
     
       
         
           
             
               
                 
                   
                     
                       SNR 
                       rec 
                     
                     ⁡ 
                     
                       ( 
                       
                         
                           N 
                           f 
                         
                         , 
                         
                           N 
                           h 
                         
                         , 
                         
                           N 
                           s 
                         
                       
                       ) 
                     
                   
                   = 
                   
                     
                       ( 
                       
                         
                           
                             T 
                             c 
                           
                           ⁢ 
                           
                             B 
                             s 
                           
                           ⁢ 
                           
                             N 
                             s 
                           
                           ⁢ 
                           
                             N 
                             h 
                           
                           ⁢ 
                           
                             N 
                             f 
                           
                         
                         0.886 
                       
                       ) 
                     
                     ⁢ 
                     
                       
                         SNR 
                         int 
                       
                       . 
                     
                   
                 
               
               
                 
                   ( 
                   9 
                   ) 
                 
               
             
           
         
       
     
     When considering a single user scenario, interference can be neglected. From (9), it can be observed that increasing (or decreasing) the spreading code N s , leads to an increase (decrease) in the receiver SNR. 
     An example embodiment of the chirp-based LPD/LPI protocol may define chirp signals that with duration of T c =1 ms and bandwidth B s =5 kHz, where the smallest frequency component f 0  is selected as 100 kHz. To illustrate this example embodiment, the channel function depicted in  FIG. 6B  is used. As it can be observed, the channel shows severe multipath, which illustrates the example embodiment under the most challenging conditions. 
       FIG. 6C  presents BER versus SNR values for different sets of frequency-hopping frame length, time-hopping frame length, and spreading code length (N f  , N h  , N s ), specifically (3, 3, 3) and (5, 5, 5). The bit-error-rate (BER) performance of the example embodiment for varying SNR values can be determined. The BER decreases as a function of the SNR and that by using larger frequency-hopping and time-hopping frame and spreading code lengths, the BER is further reduced. Further, it can be seen that even at very small SNR values, the example embodiment can still offer robust BER performance. As such, even if very small transmission power is used to significantly improve the LPD/LPI performance, network nodes utilizing the chirp-based LPD/LPI protocol can still obtain a robust communication link. 
       FIG. 6D  is an example spectrogram of an actual LPI/LPD waveform output of d i =1 using frequency-hopping sequence FH={11, 13, 18} with N f =30, time hopping sequence TH={2, 0, 2} with N h =3, and BOK spreading codes SC={−1, 1, −1} with N s =3. The waveform is preceded by a preamble structured as two simultaneous up-chirps in the first two lowest frequency bins at the first time-hopping slot and two simultaneous down-chirps in the first two lowest frequency bins at the last time-hopping slot. The first part of the preamble is used specifically for packet detection, while the second part is used solely for frame synchronization. Moreover, the combination of these two parts is exploited for Doppler scale estimation. This enables the successful transmission of over 100000 bits without having any errors with an average SNR of 19 dB. 
     One of ordinary skill in the art would recognize that embodiments of the present disclosure may be configured to utilize different types of forward error correction (FEC) codes. For example, the underwater acoustic wireless communications platform  100  may utilize Reed-Solomon (RS) codes or convolutional codes. 
     RS codes are linear block-type error-correction codes designed to correct potential errors caused by channel fluctuations and inter-symbol-interference. An RS encoder converts k information symbols into an n sized symbol block by adding t redundancy symbols. Correspondingly, an RS decoder obtains k information symbols from an n sized symbol block, while being able to correct up to t/2 of them. 
     Convolutional codes are error-correction codes that work with arbitrary sized symbol streams. They generate parity symbols by applying a sliding boolean polynomial function to data streams. Convolutional codes can be punctured with different puncturing schemes to decrease the coding overhead and correspondingly reach higher data rates. 
       FIG. 7  is a schematic of an example wireless energy transfer unit  137 , according to some embodiments. The wireless transfer unit  137  enables the use of acoustic waves to harvest energy and recharge battery units (e.g., central battery unit  132 ). The wireless energy transfer unit  137  may utilize contactless energy transfer (CET) or wireless power transmission (WPT) for transmitting energy or power wirelessly and accordingly avoiding direct wired connections. Example approaches include inductive and capacitive WPT, which are based on electromagnetic fields (EMFs), and optical coupling. 
     Acoustic energy transfer (AET) is an innovative methodology to transmit power remotely using acoustic waves. In contrast to electromagnetic waves, acoustic waves need a medium to propagate and consequently transfer energy. The physical characteristics of the propagation medium primarily impact the speed of the traveling wave and result in three loss effects: diffraction, attenuation and reflection. Nevertheless, the idea of exploiting ultrasounds as carriers of energy can be extended to underwater scenarios aiming to design a CET system immersed in water. A system for underwater WPT through acoustic waves consists of three key macro components, the transmitter, the propagation medium and the receiver. Different choices in the implementation of these components (including piezoelectric elements, circuitry details, choice of the operational frequency, among others) should be directed at maximizing the amount of energy transferred through water by minimizing these three types of losses. 
     According to the example wireless energy transfer unit  137 , as illustrated in  FIG. 7 , an energy harvesting transducer  135  is interfaced with a diode rectifier circuit  701  that converts the AC electrical voltage from the energy harvesting transducer  135  into a DC signal used to recharge a battery  132  or a super capacitor. 
       FIG. 8A  illustrates an example hybrid network  800  topology where both centralized and decentralized control are considered. According to this example network, the hybrid network  800  includes a centralized node  801  that coordinates with the network nodes  802   a - 802   d . In some embodiments, the centralized node  801  may support RF communications  805   a  and acoustic communications  805   b  and act as a gateway between an underwater acoustic network  810  and a terrestrial network  820 . Additionally, some embodiments of underwater acoustic networks  810  may include one or more network nodes  803   a  that act as a peer to another network node  802   d  to communicate data between the two nodes. 
       FIG. 8B  illustrates an example application of a hybrid network enabling an underwater Wi-Fi network  850 . The underwater Wi-Fi network  850  can provide short-range (e.g., up to 500 meters) high-rate wireless connectivity for unmanned vehicles  852   a - f , scuba divers, and other equipment in areas with underwater infrastructure (e.g., oil rigs) and/or base stations  851   a - b  that act as gateway between RF domain  855   a  and acoustic domain  855   b . The underwater Wi-Fi network  850  is designed to be a self-configuring technology that provides multiple users/devices support. Utilizing embodiments of the underwater acoustic wireless communications platform described above, the underwater Wi-Fi network  850  can support the high data rates that are required for streaming data from/to RF domain  855   a . The underwater Wi-Fi network  850  enables seamless mobility for underwater users/devices  852   a - f  with handoff support while switching base stations (cells)  855   b  and/or other network nodes. 
     The underwater Wi-Fi network may be implemented utilizing the embodiments of the underwater acoustic wireless communications platforms/network nodes. Such underwater acoustic wireless communications network nodes would operate with an OFDM scheme, and implement an optimized resource allocation scheme algorithm at the data link layer to assign dynamically time-frequency blocks to users/devices based on distance, channel, and traffic data. 
       FIG. 9  is a block diagram of the internal structure of a computer  950  in which various embodiments of the present disclosure may be implemented. For example, the general processing unit  112  may have an architecture similar to the structure of the computer  950 . The computer  950  contains a system bus  979 , where a bus is a set of hardware lines used for data transfer among the components of a computer or processing system. Bus  979  is essentially a shared conduit that connects different elements of a computer system (e.g., processor, disk storage, memory, input/output ports, network ports, etc.) that enables the transfer of information between the elements. Attached to system bus  979  is I/O device interface  982  for connecting various input and output devices (e.g., keyboard, mouse, displays, printers, speakers, etc.) to the computer  950 . Network interface  986  allows the computer  950  to connect to various other devices attached to a network. Memory  990  provides volatile storage for computer software instructions  992  and data  994  used to implement an embodiment of the present disclosure. Disk storage  995  provides non-volatile storage for computer software instructions  992  and data  994  used to implement an embodiment of the present disclosure. Central processor unit  984  is also attached to system bus  979  and provides for the execution of computer instructions. 
     In one embodiment, the processor routines  992  and data  994  are a computer program product (generally referenced  992 ), including a computer readable medium (e.g., a removable storage medium such as one or more DVD-ROM&#39;s, CD-ROM&#39;s, diskettes, tapes, etc.) that provides at least a portion of the software instructions for the invention system. Computer program product  992  can be installed by any suitable software installation procedure, as is well known in the art. 
     In another embodiment, at least a portion of the software instructions may also be downloaded over a cable, communication and/or wireless connection. 
     Further, embodiments of the present invention may be implemented in a variety of computer architectures. The computer of  FIG. 9  is for purposes of illustration and not limitation of embodiments of the present invention. 
     While example embodiments have been particularly shown and described, it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the scope encompassed by the appended claims. 
     It should be understood that the example embodiments described above may be implemented in many different ways. In some instances, the various methods and machines described herein may each be implemented by a physical, virtual or hybrid general purpose computer having a central processor, memory, disk or other mass storage, communication interface(s), input/output (I/O) device(s), and other peripherals. The general purpose computer is transformed into the machines that execute the methods described above, for example, by loading software instructions into a data processor, and then causing execution of the instructions to carry out the functions described, herein. 
     As is known in the art, such a computer may contain a system bus, where a bus is a set of hardware lines used for data transfer among the components of a computer or processing system. The bus or busses are essentially shared conduit(s) that connect different elements of the computer system, e.g., processor, disk storage, memory, input/output ports, network ports, etc., which enables the transfer of information between the elements. One or more central processor units are attached to the system bus and provide for the execution of computer instructions. Also attached to system bus are typically I/O device interfaces for connecting various input and output devices, e.g., keyboard, mouse, displays, printers, speakers, etc., to the computer. Network interface(s) allow the computer to connect to various other devices attached to a network. Memory provides volatile storage for computer software instructions and data used to implement an embodiment. Disk or other mass storage provides non-volatile storage for computer software instructions and data used to implement, for example, the various procedures described herein. 
     Embodiments may therefore typically be implemented in hardware, firmware, software, or any combination thereof. 
     In certain embodiments, the procedures, devices, and processes described herein constitute a computer program product, including a non-transitory computer-readable medium, e.g., a removable storage medium such as one or more DVD-ROM&#39;s, CD-ROM&#39;s, diskettes, tapes, etc., that provides at least a portion of the software instructions for the system. Such a computer program product can be installed by any suitable software installation procedure, as is well known in the art. In another embodiment, at least a portion of the software instructions may also be downloaded over a cable, communication and/or wireless connection. 
     Further, firmware, software, routines, or instructions may be described herein as performing certain actions and/or functions of the data processors. However, it should be appreciated that such descriptions contained herein are merely for convenience and that such actions in fact result from computing devices, processors, controllers, or other devices executing the firmware, software, routines, instructions, etc. 
     It also should be understood that the flow diagrams, block diagrams, and network diagrams may include more or fewer elements, be arranged differently, or be represented differently. But it further should be understood that certain implementations may dictate the block and network diagrams and the number of block and network diagrams illustrating the execution of the embodiments be implemented in a particular way. 
     Accordingly, further embodiments or aspects thereof may also be implemented in a variety of computer architectures, physical, virtual, cloud computers, and/or some combination thereof, and, thus, the data processors described herein are intended for purposes of illustration only and not as a limitation of the embodiments. 
     The teachings of all patents, published applications and references cited herein are incorporated by reference in their entirety. 
     While example embodiments have been particularly shown and described, it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the scope of the embodiments encompassed by the appended claims.