Enabling Real-Time Remote Monitoring of Ships by Lossless Protocol Transformations

This paper uses data processing techniques to reduce the required transmission bandwidth in ship-to-shore communications. The proposed framework (ONline Efficient Sources Transmission Optimizer - ONESTO) leverages state-of-the-art technologies and novel algorithms to automatically optimize transmissions under structural (e.g., available bandwidth, fixed packet overhead) and user-defined (e.g., maximum latency) constraints. In addition, ONESTO authenticates and encrypts the communication between the ship and the shore via mainstream free and open-source software components. Initially, we present the abstract mathematical formulation of the problem, with its assumptions, goal function, constraints, and significant quantities. Then, we introduce the architecture of a system capable of continuously estimating the compressibility, processing and transmission time of streaming data. Such estimations allow ONESTO to calculate and apply optimal parameters for achieving the best compression ratio. Lastly, using a prototypical implementation, we evaluate the system performance with a Class B ship simulator on two realistic use cases. Our experiments show an excellent compression ratio with maritime protocols (more than 40:1) and a limited latency impact, demonstrating the approach’s viability.


I. INTRODUCTION
D IGITALIZATION of the industry is catching pace in the maritime sector, and modern ships play an essential role in this process. Nowadays, they embed digital enabling technologies and hardware components, e.g., sensors and actuators, increasing more and more their efficiency and safety. Also, new opportunities and challenges arise around the above technologies and the large amount of data they produce.
For example, data fusion and intelligent analytics enable the development of even more effective algorithms to boost the spread of semi-autonomous and autonomous vessels [1]. Another opportunity is feeding data into a digital model, namely a Digital Twin (DT), to mirror and predict the behaviors of a monitored ship [2]. Instead, a major challenge is providing the facilities to investigate such data to detect and prevent cyberattacks that the new digital assets might suffer from [3]. It is worth noting that all of the above cannot or can only be partially carried out onboard and require resources and personnel from dedicated shore side centers. In this regard, the maritime industry plans to use Remote Operation Centers (ROC) [4] for semi-autonomous and autonomous vessels. Such centers can also provide resources for implementing the functionalities of DTs [5] or host specialized Security Operation Centers (SOC) [6] for monitoring and reacting to cybersecurity threats.
In all these scenarios, the connectivity between ships and ROCs is vital and represents the most critical component. However, ship-to-shore communication is still an open issue today [7], [8], [9].
In particular, available technologies cannot yet fulfill the requirement of sufficient communication link capacity, enabling ROCs to receive enough data from a ship on the sea for the above-mentioned shore side operations. A common proposal relies on increasing the link capacity by leveraging multiple connection technologies [10], [11], [12] with a vertical handover mechanism [9], [13], but it can work only partially. Once the ship is out of sight of land, signals of faster connections fade, and the only way to connect is by satellite, i.e., a link with low bandwidth, high latency, and elevated costs.
Data compression has become a standard feature to improve transmission capacity in network environments with such features. Also, it is essential in ship-to-shore communications, but effectiveness may be low (or even counterproductive) if applied as is. Compression efficiency [14] tends to be specific to each application and requires a proper balance between improving the compression ratio with aggregated data and the computational latencies it introduces at both the transmitting and receiving sides. Nevertheless, ships are comparable to complex Information Technology (IT) infrastructures with Operational Technology (OT) systems [15] that can host any application. For this reason, compression efficiency requires to keep searching for a reasonable trade-off among the requirements of a plethora of heterogeneous data sources that transmit at a variable rate.
Lastly, ship-to-shore communication has also to deal with cybersecurity issues. In particular, a ship and ROC must communicate over insecure networks [16] without any malicious actor being able to eavesdrop or impersonate any of the parties.
Due to the complexities introduced above, we argue that an open research challenge is to build a ship-to-shore communication framework (SSCF) that may be at the same time: P-1 Self-adaptive. It adapts its processing in real-time to changes in specific transmitting and receiving conditions (see below). The aim is to ensure compression efficiency and the continuity of data reception at the shore side. P-2 Source agnostic. It works without any prior knowledge about data sources. P-3 Lossless. It ensures that the ROC receives a bitperfect representation of the data stream. For example, this feature is essential for SOC duties, like anomalies detection or forensic investigations. P-4 Secure. It can authenticate the ROC with the connected fleet (and vice-versa) and provide secure channels for data transmission. Moreover, we argue that the P-1 property of an SSCF -tailored for remote monitoring of ships-has to continuously and simultaneously deal with the conditions below.
C-1 End-to-End latency, i.e., given the requirements of the remote service type, e.g., ROC or SOC, it ensures that the shore side always receives within an upperbounded latency. C-2 Bandwidth usage, i.e., considering the coexistence with other ship facilities that use the connectivity, it spares as much headroom as possible on the shared communication channel. C-3 Source variability, i.e, it is able of multiplexing multiple heterogeneous onboard data sources, handling changes in their rate and contents induced by the distinct phases of navigation. In this paper, we present the design and implementation of a novel SSCF, namely ONline Efficient Sources Transmission Optimizer (ONESTO), which satisfies all previous requirements. In particular, the inspiring principle of ONESTO is combining an innovative self-adaptive algorithm with a stateof-the-art lossless compression algorithm and a lightweight, high-performance, and secure message-oriented middleware. We empirically evaluated ONESTO under ROC and SOC requirements, and with a bridge simulator providing the data sources of a realistic Integrated Navigation System (INS) [17]. This paper presents the following key contributions: • A self-adaptive algorithm designed to optimize data transmission efficiency and reliability, able to adapt to varying communication conditions without relying on specific data sources, specifically tailored for shipto-shore communications.
• A cutting-edge SSCF that seamlessly integrates state-ofthe-art technologies to achieve top-notch performance and enhance security. Mainly due to the compression ratio achieved (more than 40 to 1), we prove that a remote center can also monitor high-resolution radar data.
• An extensive assessment of the proposed methodologies using real-world case studies and data sources. Experimental results on maritime protocols demonstrate that ONESTO can effectively transmit crucial data to reconstruct the ship's situational awareness onshore, even under the most constrained bandwidth conditions and with a latency of no more than 7 seconds. We claim that the above capability is of great interest to the research community working on the design of onshore solutions to improve ships' safety and security.
Structure of the paper. The rest of the paper is organized as follows. In Section II, we review the related work. In Section III, we discuss the mathematical formulation of our self-adaptive algorithm. In Section IV, we introduce the architecture of the framework and evaluate its implementation in Section V. We conclude the paper in Section VI.

II. RELATED WORK
Our work aims to develop an SSCF for the remote monitoring of ships that meets P-1, P-2, P-3, and P-4 properties. Related work includes solutions that optimize data transmission in contexts with similar criticalities (e.g., lowbandwidth or high-latency links) or ship-to-shore network communications.
In Table I, we summarize features of considered literature works w.r.t. the four properties met by ONESTO. For each work, we use and to denote whether the property is satisfied or not, respectively. Moreover, we use to indicate that the property is only partially met. Partially fulfilling P-1 means that the proposal addresses some, but not all, of the conditions C-1, C-2, and C-3.
A research topic that is not specific to ship-to-shore communication but shares with us the general schema is adaptive compression. The most relevant works are from Wiseman et al. [18] and Krintz and Sucu [19].
The solution proposed in [18] relies on a fixed block size and hard-coded coefficients derived from a chosen dataset. ACE [19] similarly relies on a statically determined comparison between different compression algorithms, performed again on a generalist compression corpus. Using a predetermined dataset makes them partially satisfy P-2, and the precalculated parameters do not fit C-3. Lastly, they both work as exclusive transmitters, contrasting with our C-2.
Sun et al. [20] propose a real-time adaptive packet compression scheme improving bandwidth in scenarios with satellite networks. They use a fixed-size buffer that collects packets until it is full or a specific interval expires. Then, the buffer is compressed with a lossless algorithm before being sent. Since their adaptiveness does not consider our conditions, it does not represent an alternative SSCF to ONESTO.
Berni et al. [21] present a solution to support sea trials requiring a large shore-ship-shore data exchange. Unlike ONESTO, they increase bandwidth not by using compression but by aggregating multiple links, which is not always viable.
Their approach to adaptiveness uses Quality of Service (QoS) technology to allocate bandwidth for specific protocols while ensuring a portion remains for other resources, meeting condition C-2 but only partially P-1.
Yang et al. [22], Ifrim et al. [23], Ferreira and Martins [24], and Perera and Mo [25] share with ONESTO a similar context and objective in terms of maritime communication and the transmission of data from ships to shore. Proposal from [22] applies to video data and uses real-time genetic algorithms to implement a scheduler that optimizes the transmission considering the tardiness and weights of jobs. The one from [23] applies to Automatic Identification System (AIS) [26] data and reduces them in real-time by extracting and transmitting only the essential information from sentences. Ferreira and Martins [24] consider data from onboard sensors and, similarly to [23], propose an automated process that decides whether the collected data needs to be transmitted or not. Instead, Perera and Mo [25] propose a solution to reduce data transmitted through an autoencoder trained with a set of predefined data sources. None of the above works meet the required properties.
In summary, ONESTO offers a more robust self-adaptive solution by utilizing both compression to increase bandwidth and real-time tuning of algorithms to maintain transmission efficiency in changing conditions. Lastly, ONESTO is the only solution that (i) looks at the security issues of communication channels by supporting authentication and link encryption, (ii) provides multi-tenancy natively for fleet monitoring, and (iii) includes the Zstandard [27] compression algorithm.

III. MATHEMATICAL FORMULATION
In this section, we describe the mathematical formulation behind ONESTO.

A. Background
Onboard, multiple data sources transmit packets to the receiving end of the system. Each of these packets has length n p and is comprised of a sequence of bytes ⟨b 1 , .
As a result of P-2, we make no assumptions on the process originating b j s.
For the i-th data source, we model the arrival of such packets as a Poisson process with parameter λ i , and their size n p as a random variable sampled from a normal distribution with unknown mean µ i and variance σ 2 i . Those packets enter the system and are batched together in aggregations of size n i . Such aggregations are subsequently subject to a lossless compression operation. We model that operation as a pair of actions ⟨C c i , D⟩ with C being the compression action parameterized by its settings c i and D being the decompression action. We make the following three assumptions about such an operation: 1) M = D(C c i (M)) holds for any possible admissible input M and setting c i , i.e. that it is lossless. This assumption implies property P-3 by construction. 2) for the majority of inputs |M| > |C c i (M)| for an admissible input M and a proper compression setting c i , i.e. that it is size reducing.

3) the time taken for compressing a message M is greater
or equal that the time taken for decompressing it, i.e., that it is compression-heavy. If desired, any invertible transformation F can be used to define a derived compression operation in which the original compression actions are replaced by ⟨F(C C i ), D(F −1 )⟩. We leverage this property to meet P-4 by including an authenticated encryption function F e . Since the choice of an encryption algorithm directly influences the security profile, F e is parameterless, fixed, and not tied to the optimization process.
Then, the compressed result with a size overhead of O is sent on a channel having a head-of-line latency of T lat and an available bandwidth B. Lastly, the receiving side decompresses the aggregation and replays it at the original source rate.

B. Optimization Goal and Constraints
To meet P-1, the system must automatically and continuously comply with the set constraints and targets. For that purpose, the system reacts to the provided conditions by constantly solving a constrained optimization problem, updating the found solution as the underlying conditions or constraints change.
Equation 1 expresses the optimisation goal: finding for each transmitting source an aggregation batch size n i and compression parameters c i so that the ratio between the transmitted data size D t x i and the aggregated data size D pr oc i is minimized, i.e., maximizing the global compression ratio to achieve minimal bandwidth usage, as per C-2. Calculation of D t x i and D pr oc i will be explained in Section III-C.
In addition, we impose the set of constraints found in Equation 2: the size of transmitted data in any solution should be equal or smaller than the corresponding original data.
Finally, Equation 3 bounds any found solution to have finished processing (t pr oc i ), and sending (T lat + t t x i ) data before the next aggregation has been generated (t gen i ). Section III-D will explain the composition of t pr oc i , t t x i , and t gen i .
Until now, the presented equations concerned structural properties of the problem, i.e., necessary conditions for validating a given solution. Yet, the system might also need to meet other constraints given by the user in order to tailor the system operation to its own needs. In this work, we use a user constraint derived from C-1 and relevant to multiple use-cases: ensuring that the maximum end-to-end system traversal time T is kept below a chosen maximum latency L max (T ≤ L max ). Definition of T will be provided in Section III-D.
Choice of L max has the intuitive task of constraining the maximum admissible data delay, possibly by influencing the latency-compression ratio trade-off. For instance, a ROC might want to use a low maximum latency value (at most tens of seconds) to ensure near real-time observability. Instead, a SOC concerned with threat intelligence and forensic analysis can tolerate optimization solutions associated with higher delays, gaining a potentially higher compression ratio and the capability of receiving more data.
D pr oc i is obtained with Equation 4, i.e. by multiplying the number of packets n i belonging to an aggregation and the estimate of an individual packet size ν i .
In Equation 5 we obtain the compressed size as some unknown function h i of the original size, influenced by the number of elements being batched n i and the compression operation parameters c i .

D. Latency-Related Quantities
The system maximum end-to-end traversal time T is the maximum latency between a packet ingress into the system on the ship side and its egress on the shore side.
Equation 6 shows the calculation of the maximum latency figure T . Its components are as follows: • max i t gen i is the maximum time taken by a source for generating the packets belonging to an aggregation.
• max i t pr oc i is the maximum time taken to compress an aggregation.
• T lat is the head-of-line latency of the communication channel.
• i t t x i is the sum of utilization time of the communication channel.
• max i t r x i is the maximum time taken to decompress a received aggregation. We detail their computation below.
The time taken by a source for generating the n i packets for an aggregation t gen i can be calculated as consequence of the arrival rate λ i , as shown in Equation 7.
The duration of the compression operation t pr oc i is calculated in Equation 8 as some coefficient g i applied to original size D pr oc i (n i ), influenced by the number of elements being batched n i and the compression operation parameters c i .
The individual source utilization time of the channel t t x i is modeled in Equation 9 as the ratio between the transmitted size D t x i (n i , c i ) plus overhead O and the available bandwidth B. By utilizing the sum in Equation 6, we model the sources as sharing the channel via time-division.
The time taken for decompressing the aggregation in Equation 10 is calculated either as a coefficient v i of the transmitted size D t x i (n i , c i ) or as equal to t pr oc i . This latter equality stems from Assumption 3 made in III-A on the compression operation and allows to perform the calculation whenever v i is unknown.

E. Estimation of Properties
The previous calculations rely on perfect knowledge about the behavior of each source, i.e., their stochastic process parameters, and the chosen compression algorithm.
Such knowledge is not available in a practical case. To lift this assumption, each parameter appearing in the equations has to be replaced with its estimate, which is calculable. These estimates are also to be updated over time in response to C-3.
1) Arrival Rate λ i : As in [28], the Poisson arrival rate process parameter λ i can be estimated with its maximum likelihood estimator (MLE).λ The MLE, shown in Equation 11 is an efficient, unbiased estimator for λ i in which A is the sum of arrivals in the period and P is the length of the period.
For a given confidence 100(1 − α) the estimator upper and lower confidence bounds are given by Equation 12, where χ 2 q (ξ ) is the q-th quantile of the χ 2 distribution with ξ degrees of freedom. Such bounds indicate that the true value lies between them with 100(1 − α) confidence and can be used to bound the estimated value in calculations.
In order to overestimate t gen i , we use λ i L as λ.
2) Packet Size Estimate ν i : An estimation of the underlying normal distribution parameters (µ i , σ i ) is required to calculate the estimated packet size for a source ν i . Such parameters can be derived from n samples of individual packet size measurements As in [29], Equation 13 depicts the MLE for the meanμ. Equation 14 depicts the sample variance s 2 , an unbiased estimator of the underlying distribution parameter σ 2 .
Like in the previous case, confidence intervals of such quantities are of interest to bound the estimates. We calculate them as shown in [30].
In particular, Equation 15 shows the confidence intervals for the mean, where t p (ξ ) is the q-th quantile of the Student's t-distribution with ξ degrees of freedom.
Likewise, Equation 16 illustrates the confidence intervals for the variance.
In the following, we use ν i = µ U + 3σ U to overestimate the aggregated data size.
3) Compression Algorithm Coefficients g i , h i , v i : Excluding Assumption 3 made in Section III-A, which produces the inequality v i ≤ g i , no analytical derivation of these coefficients is possible without further assumptions on the used algorithm.
As a result, their values have to be extracted from a Look-Up Table (LUT).

IV. PROPOSED FRAMEWORK
This section describes the architecture of our framework. Figure 1 details the architecture of ONESTO. For the sake of presentation, the figure depicts a one-way message flow, i.e., the ship acting as the transmitter and the shore side as the receiver. Instead, the ship-to-shore transmission must be considered bidirectional, and the two communicating entities can simultaneously perform the transmitter and receiver functions. In such a one-way representation, data from monitored sources reach three tasks, i.e., Sampler, Estimator, and Compressor.

A. Overview
Sampler and Estimator continuously monitor the compression statistics and source properties, e.g., the data rate of each source. They generate outputs that, together with user constraints and decompression statistics coming from the shore side, represent the input of the Optimizer task.
Optimizer executes the self-adaptiveness algorithm and outputs the solution to the Compressor, i.e., the optimal parameters the task needs to use for aggregate and compress data. The self-adaptiveness algorithm uses a stateful approach and stores historical data in the Context database.
Optimizer creates aggregated packets consisting of aggregated and compressed data for each source that Transmitter transmits to the shore side.
Receiver at the shore side receives the aggregated packets that forward to the Replayer task.
Replayer retransmits data from the aggregated packets as if the original onboard sources had transmitted them.
Periodically, Optimizer can perform a benchmark request. Such a request is sent along with the aggregated packet to the Benchmarker task.
Benchmarker measures latencies due to the shore side procedures and sends the results via the decompression statistics. Such activity is an example of the shore side acting as the transmitter, as mentioned above.
Below, we detail each task at the ship and shore side.

B. Ship Side
The ship side of the architecture is where data gathering, compression, and transmission occur. We designed it as the cooperation of 5 types of modules, as described below.
1) Sampler: As mentioned in Section III-E.3, the selfadaptiveness algorithm requires values for g i and h i LUT. For each data source, Sampler continuously estimates these parameters by aggregatingn i packets. It applies to such an aggregation the compression operation parameterized byc i .n i andc i have been sampled randomly from the range of their admissible values.
In particular, sampling ofn i is performed on U 1,⌊λ i ·L max ⌋ where U L ,U indicates the uniform distribution with values ∈ [L , U ]. ⌊λ i · L max ⌋ is the number of elements generated by a given source across the entire latency budget.
2) Estimator: For each data source involved in the transmission, a dedicated Estimator estimates the arrival rate λ i and the packet size of messages as shown in Equations 11-16.
3) Optimizer: This component receives statistics from the Sampler and Benchmarker (see Section IV-C) and decides for every data source what is the best number of packets to aggregate and the best compression level to solve the problem described in Section III.
Solution of the problem amounts to periodically reevaluating the best n i s and c i s whenever any of these four events happen: (i) estimator changes its estimates for a source, (ii) the user constraints are updated, (iii) sampler has added a new data point, (iv) benchmarker has added a new data point.
The best solution will be the one satisfying every constraint and fitting as the argmin in Equation 1.
It is worth noting that situations may arise in which there are no admissible solutions, e.g., a user constraint cannot be met with the current structural properties. A "no solution found" exception is sent to the Compressor in this case. 4) Compressor: Parallel to the abovementioned components, Compressor receives packets. It applies to them the aggregation and compression operations, as indicated in the current solution by the Optimizer.
Additionally, it prefixes the sent data with the time taken by the source to generate the aggregationt gen i that will be used by the Replayer at shore.
If it receives an exception from Optimizer, ONESTO drops data transmission and triggers an alarm. It is up to administrators to decide how to handle this scenario. For example, they can relax user constraints to allow the Optimizer to find a solution. 5) Transmitter: As the last stage for the ship side of the architecture, the Transmitter sends the Compressor-generated packets to shore. This module is also responsible for providing the authentication of communicating entities and activating a secure channel for data transmission.

C. Shore Side
The framework at the shore side has two tasks: reconverting packets to their original form and participating in the optimization problem. The following components achieve these duties.
1) Receiver: This component acquires aggregated packets, distinguishing from which source they were generated, and feeds them to the Decompressor.
2) Decompressor: This component receives compressed batches of packets from a data source and decompresses them back to their original form, leaving them grouped.
3) Replayer: This component aims to divide the batches into single packets and transmit them so that the software listening locally can receive them. It must ensure that packets arrive in the same order and rate as they were originally sent. It performs such pacing by leveraging thet gen i value found in the batch.

4) Benchmarker:
It is analogous to the Sampler component for the shore side. It receives from the latter requests to calculate decompression performance on a given aggregation size and compression parameters. Thus, it can send back v i (n i , c i ) to Optimizer to more precisely estimate the values in Formula 10.

V. IMPLEMENTATION AND RESULTS
In this section, we describe our implementation of the architecture presented in Section IV. Then, we test the ONESTO tool on two realistic scenarios and discuss the results.

A. Implementation Details
Our Proof-of-Concept implementation consists of four ad-hoc programs and a Free and Open Source Software (FOSS) component: 1) A general purpose TCP/UDP receiver (one for each source) acquires data to transmit. 2) A monolithic process undertakes the roles of Estimator, Sampler, Optimizer, and Compressor modules. 3) A monolithic process undertakes the roles of Decompressor and Replayer. 4) A process carries out the function for the Benchmarker module. 5) A FOSS message broker provides data exchange between local modules and remote transmission by implementing the publish/subscribe paradigm [31] (pub/sub). In particular, the ship instance comprises items 1, 2, and 5, and the shore one comprises items 3, 4, and 5.
We wrote each of these ad-hoc programs in the Rust programming language (version 1.63) [32], totaling 1933 lines of non-library code.
For the Compressor module, we use Zstandard, a fast lossless compression algorithm with outstanding compression ratio [33]. In particular, we leverage its reference implementation (zstd [34], version 1.5.2), and we use the compression level as our compression operation parameter c i (see Section III-B) Concerning the communication between ship and shore, we selected NATS (version 2.8) [35], a multi-tenant messaging system based on pub/sub. In particular, modules subscribe and publish to topics of interest to interact with each other and transmit data. Each topic also distinguishes messages based on different properties, e.g., from which data source they are coming or whether they are in their original form, grouped, or compressed. We use a federation between NATS instances to handle data transmission. In detail, the shore side subscribes to the topics of interest for its activity (in our case, the ones containing the compressed data sources), and NATS transmits only them with exactly-once delivery.
The multi-tenancy support also enables multiple ship-side nodes to connect to the shore side and extends our architecture to a fleet monitoring solution.
Moreover, NATS provides internally mutual Transport Layer Security (TLS) [36] authentication and encryption. We leverage the above facility as our authenticated encryption function F e (see Section III-A) Lastly, using a common standard as pub/sub and such a configuration of topics ease the extension of ONESTO with new modules and functionalities. For example, we can add a module that filters source-specific data and further reduces bandwidth demand (implementing a solution as proposed in [23] and [24], see Section II). Briefly, integration involves subscribing the module to the data source topic and  publishing its output on a new one to distinguish the filtered source to be compressed and transmitted.S

B. Experimental Settings
Our test environment runs on Ubuntu GNU/Linux 22.04, installed on a Virtual Machine (VM) hosted by VMWare ESXi 7.0U3 and configured with 16 Intel Xeon Gold 6252N vCPUs at 2.3GHz and 64 GB of RAM. The above VM hosts the instances of ONESTO for the ship and shore entities.
We enabled TLS on the two federated instances of NATS. We used X.509 certificates [37] to identify and authenticate the two entities and ChaCha20 [38] as the encryption algorithm.
Simulation of the network link was performed by delaying packets before their arrival to the receiver component of ONESTO. Each transmitted packet was serialized inside of a FIFO queue and subsequently extracted after a time corresponding to the simulated round-trip latency T lat plus the transmission time t t x (see section III-D). Both T lat and the bandwidth B are perturbed in this link simulator by an additive Gaussian noise with a standard deviation corresponding to 10% of their value. The per-packet overhead O was instead set to 46 bytes, i.e., the size of a packet containing Ethernet, IPv4, and UDP headers.
We modeled the characteristics of satellite connectivity based on the datasheet of a leading provider [39] and by considering the worst conditions for geostationary configuration, i.e., a B between 1-100Mbps and a T lat of 160ms.
A commercial full bridge simulator [40] simulates the ship underway and provides data sources to be transmitted. Our installation provides the features of a Class B console simulator [41] and is depicted in Figure 4. In particular,  we consider as sources the data that are carried by two standard protocols running on INSs: NMEA 0183 [42] and ASTERIX CAT240 [43]. The first carries data from navigation sensors and equipment, and the latter carries data from radar antennas. These two feeds comprise most of the information used for navigation and allow the shore side to obtain situational awareness comparable with that on board.
Navigation is set in a scenario reproducing the Ligurian Sea and the Port of Genoa (Coordinates: 44 • 24 ′ 10 ′′ N, 8 • 55 ′ 0 ′′ E). In particular, we simulate a ship leaving the harbor, sailing in the open sea, and going back, switching communication links as it steps away from the shore. Such a switch changes the connectivity from ground-based wireless communication systems to satellite-based ones.
The same scenario is tested against the constraints of a ROC and SOC (see below). In both cases, the shore side receives data and transmits them back to two software reproducing a radar plan position indicator and an electronic chart display. We use RadarView-240 [44] (version 1.89.2, see Figure 5), a free ASTERIX CAT-240 viewer from Cambridge Pixel, and OpenCPN [45] (version 5.6.2, see Figure 6b), an open-source Chart Plotter Navigation software.
1) Baseline: Before assessing the properties of the framework, Table II presents the original data rates for each data source we considered.
A digital twin of a commercial antenna generates the radar image and related ASTERIX packets. Its features are 0.88 • of angular resolution, 4096 as the number of sweeps, 8 bits of resolution, 5.42m of range resolution, 4096 as the number of cells, and 24r pm as the rotation speed.
Due to the high resolution, the radar video traffic is much more bandwidth-intensive w.r.t. to the other data source. As summarized in the table, it requires more than 50 Mbps to be transmitted in the original form.

C. Real-Time Monitoring of a Ship Underway
In this scenario, a ROC wants to monitor the navigational situation of a ship by receiving INS data in real-time.   We decline the real-time monitoring by fixing a minimum precision, i.e., the maximum distance the ship can cover from the last received position. In particular, the maximum latency constraint L max can force the above precision by calculating it as a function of the required minimum value and the current ship's speed (Equation 17).
Moreover, we change this constraint when the ship is underway. We base on the available link capacity and leverage the self-adaptiveness capability to keep a lower but tolerable precision during limited bandwidth conditions. Table III summarizes how we set L max during the different phases of the scenario. Bandwidth B follows from the vertical handover mechanism. Figure 2 shows the simulation results. During the experiment, the bandwidth usage and the end-to-end latencies were kept under the preset limit values. Furthermore, the system achieved a compression ratio of more than 40 to 1, realizing significant bandwidth savings.
The radar display at the shore side (see Figure 5) plots data from the ASTERIX protocol with a period of 2.6s, confirming that the local transmission behaves like the originating antenna rotating at 24r pm. Lastly, the cartographic system at the shore side (see Figure 6) perfectly reproduces the entire ship's track and AIS targets compared with the remote site. Again, ONESTO transmits NMEA packets locally as if they came from the original sources.

D. Collecting Data to a Security Information and Event Management (SIEM) Tool
A SOC requires sending data from INS to a SIEM tool so that operators can make periodic queries and correlations to check for anomalies or conduct post-mortem analyses [46].
Such an activity places constraints on receiving at the shore side all the exchanged data to collect, regardless of the bandwidth capacity of the link. To this aim, we set the maximum latency to the interval between such periodic queries (30s). Moreover, fixing a maximum bandwidth constraint to 1Mbps allows us to leverage the self-adaptiveness property to ensure data transmission during the worst case of global satellite connectivity.
We depict the simulation results in Figure 4. The experiment confirms the results of the previous scenario. It is worth noting that latency is far below the set limit and never exceeds 7s.

E. Performance Figures
During the scenarios V-C and V-D, we measured the average CPU and memory usage for each system component. On the ship side, the CPU usage amounted to one maxed-out core for each source due to the sampler operations and 1.18 CPUs for the remaining estimation and compression steps. On the shore side, the benchmarker utilized 0.81 CPUs and 0.05 CPUs for the remaining decompression and replay.
For memory usage, the process undertaking the rofles of estimator, sampler, optimizer, and compressor consumed a stable 4314MiB. On the shore side, the benchmarker consumed 547MiB, and the receiver consumed 294MiB.
The message broker, acting as the transmitter and receiver components, consumed the same amount of resources on both sides, amounting to 0.21 CPU cores and 60MiB of memory.

F. Discussion
Following the results presented in the previous section, we draw the following considerations related to ONESTO.
As per P-1, it succeeded in continuously adapting its parameters so that the resulting bandwidth and C-1 end-to-end latency always remained under the given constraints. Still, thresholds were never exceeded as the maximum bandwidth and latency changed during execution. The system promptly reacted to these configuration changes with low transient times, even when faced with changes implied by C-3 in the maximum achievable compression ratio of the underlying sources. Then, the achieved size reduction was constantly maximized by the concerted operation of its components, automatically applying the best parameters for a given data source and condition, and minimizing bandwidth usage as per C-2. Observing the two presented scenarios, the one with the lax latency constraint presented more stable compression values, stemming from the system being able to explore a bigger admissible solution space.
Both experiments reveal a significant amount of high-frequency noise in the transmission flow. This results from the radar being the highest volume data source and including numerous high-entropy, i.e., badly compressible, areas, such as thermal noise, terrain scattering, and reflective parts of waves.
In general, considering the achieved compression ratio and results from the self-adaptive algorithm, we argue that ONESTO can support the simultaneous transmission of a more comprehensive set of data sources, e.g., control systems setpoints and measurements or application security logs.
These results were achieved with no specific fine-tuning of the system to any application protocol, thus meeting P-2.
Since ONESTO leverages invertible transformations for each step and transmits data with exactly-once delivery semantics, it complies with P-3 by construction.
Considering P-4, X.509 certificates provide strong authentication of the parties, and ChaCha20 is one of the most robust forms of encryption available. This setup effectively protects against eavesdropping and tampering attacks, where malicious actors attempt to alter or overhear the communication.
Performance figures indicate that the component with the highest resource usage is the sampler, whose impact could be reduced by throttling its operations.
Nevertheless, a coarser sampling might impair optimization effectiveness. If needed, this reduction could be tied to the availability of an admissible solution and proportional to the number of acquired samples.
The asymmetry in resource consumption between ship and shore facilitates the application of the system in many-to-one contexts, i.e., fleet monitoring solutions. Furthermore, our measurements experimentally verify that the algorithm we used fits with assumption 3 of the compression operation given in section III-A.

VI. CONCLUSION AND FUTURE WORK
In this paper, we presented a novel ship-to-shore communication framework leveraging state-of-the-art technologies for enabling a self-adaptive, source-agnostic, lossless, and secure data transmission of any onboard source. In our experiments, the system rapidly adapted to changes in user and environmental constraints, optimizing and securing data transmission.
The achieved bandwidth savings of more than 40 times and low latency figures suggest that frameworks such as ONESTO will be the enabling technology of upcoming ship-to-shore communication strategies.
Future developments will involve adaptations to the underlying mathematical model to new user constraints. For example, we can consider the inclusion of communication blackouts in the formulas, in-framework estimation for the bandwidth and head-of-line latency, and the inclusion of Quality-of-Service classes between data sources. Lastly, we want to evaluate its applicability in bidirectional use cases like unmanned vehicle remote control.