SATCOM offers numerous advantages over traditional point-to-point terrestrial communications with a wide geographical coverage being the most significant advantage. However, SATCOM’s potential for providing extensive coverage across global regions, the high cost of implementation and extended propagation delays pose significant hurdles to its deployment within the maritime sector [
1]. The maritime industry largely relies on SATCOM systems, which are expensive and have a low data rate [
42]. Frequent maritime activities, on the other hand, require high-speed and reliable data transmission in order to ensure smooth communication between vessels and the control center. Current maritime wireless communication systems, however, do not meet this demand. SDN and SDR have tremendous potential to revolutionize maritime communications. With the proper design, integration, and deployment of SDN-SDR-based wireless communications infrastructure with the existing SATCOM infrastructure, both network and physical layers’ complexities can be alleviated. Maritime communications can be better managed with planned deployment of software at these two layers to meet the demands and constraints of constantly changing on- and off-shore maritime communications environmental conditions and jurisdictional regulations.
5.3. Maritime communications security with SDN
An SDN-based framework can be used to mitigate attacks in an automated manner for improved resilience in the ship’s communication network [
66]. There are sensors and actuators attached to the different components of the ship that are responsible for controlling the bridge, the engine, and the propulsion. The sensors transmit the data related to these physical devices to the controller for analysis. The controller, known as the
Monitoring Controller, plays a crucial role in overseeing the operation of the ship’s components. It continuously monitors the data received from the sensors and analyzes it to ensure the proper functioning of the various ship components. Depending on the information obtained from the bridge devices, the Monitoring Controller issues commands to start or stop the propulsion control system and can even reroute the ship on a different route if necessary.
With the help of the Detection Engine, the Monitoring Controller can quickly identify any anomalies or deviations from normal behavior. The Detection Engine examines the network traffic within the ship’s communication network and detects suspicious or malicious activities by employing various techniques and underlying algorithms. It analyzes the network traffic patterns, protocols, and payload contents to identify potential threats or attacks. Once a suspicious activity is detected, the Detection Engine raises an alert and informs the Monitoring Controller about the potential security breach. Additionally, when the Detection Engine detects a fault or failure on the bridge device, it notifies the Mitigation Engine and the controller to divert the network traffic on a different route. The Mitigation Engine is responsible for initiating appropriate countermeasures to mitigate the impact of faults and/or failures. It collaborates with the controller to divert the network traffic onto a different route, ensuring that critical ship operations continue without disruption. By swiftly responding to faults or failures, the Mitigation Engine helps maintain the ship’s communication network’s reliability and availability. Together, the Monitoring Controller, Detection Engine, and Mitigation Engine form integral components of the SDN-based framework, working in tandem to safeguard the ship’s communication network against potential threats and ensure uninterrupted operation.
Figure 6 shows these components and the relations between them. Note that each of the three controllers within the controller layer, depicted in
Figure 5, can have the Detection Engine and the Mitigation Engine, for more robust overall security.
5.4. A Use Case
Merchants and cruise ships travel far and wide across the vast oceans between places. In the case of Navy vessels, they remain afloat for months at a time and may be required to anchor far offshore. In either case, the communications environment has physical and environmental challenges. More importantly, once away from the shore, the ships have no access to land-based high-bandwidth communications infrastructure. Furthermore, when ships want to pull up to ports in different parts of the world, they are often faced with differing communication standards. For example, countries may choose to operate wireless communications equipment across different spectrum allocations [
47]. With dedicated equipment operating on a specific carrier for a given bandwidth, there is no guarantee of compatibility with another system’s specifications.
While SATCOM is a viable solution in such scenarios, the cost can be prohibitive, and the latency and signal interference may not be acceptable for time-critical missions. Furthermore, the nature of the satellite constellation can introduce spatial or temporal communication gaps. For instance, a geosynchronous satellite in orbit about 35,000 km above the earth has a period of approximately 24 hours. This results in the perception to a user on the earth that the satellite stays relatively fixed at a given point in the sky. As a maritime vessel traverses east or west across the oceans, this point in the sky eventually will appear below the horizon, requiring the vessel to obtain coverage from an additional satellite to communicate.
Additionally, due to the curvature of the earth, geosynchronous satellite coverage above 70 degrees north latitude and below 70 degrees south latitude is greatly diminished [
67]. While these issues can be overcome with different solutions such as using a polar or highly elliptical orbit, they bring their own complications such as tracking and pointing requirements. In particular, Navy operations require connectivity among a diverse set of platforms, including submarines, surface ships, aircraft, and shore sites (see
Figure 2). The links among these platforms support a wide range of applications supporting strategic and tactical C4ISR functions. While high bandwidth communications are available on large ships, small ships do not have the ability to leverage this bandwidth by dynamically selecting the most capable link available [
68]. Consequently, ships do not efficiently utilize the available bandwidth within the strike group, limiting the ability for smaller ships to effectively gain access to services on the Global Information Grid (GIG) [
68]. SDN-SDR based unified communications infrastructure can be very useful for deployment with the Navy’s Carrier strike groups (CSGs)[1] composed of ships, submarines, aircraft, and personnel to support an extensive range of operations all of which primarily rely on SATCOMs. A typical CSG is shown in
Figure 7.
A more robust, low-cost, high-bandwidth, and low interference communication infrastructure should be considered to address the afore-explained situations, especially for Vessel-to-Vessel (V2V) and Vessel-to-Aircraft-Carrier (V2C) communications. With regards to a CSG, one possible solution is to fit the vessels in the CSG with an SDN-SDR based unified communications framework integrated with the existing SATCOM infrastructure. It is important to note that today’s satellites indeed leverage SDRs for more flexible and varied applications. In [
70], authors discuss how the SDR based AIS receiver has been integrated into the AAUSAT3 satellite. Authors note that due to its versatility, new detection algorithms can be easily deployed on an SDR based AIS receiver, and they easily adapt to the new AIS transmission channels. As previously mentioned, SDN and SDR provide great flexibility to the network and physical layer functionalities of the communications stack. Several other works, including [
71,
72,
73,
74,
75,
76], have evaluated the integration of SDR in numerous satellite-based applications.
With an SDN-SDR unified communications framework, the ship’s crew can prepare for changing RF requirements based on the geographical region and regulations ahead of time by keeping the SDR infrastructure ready with the requisite physical layer standards with simple software reconfiguration tasks. This will alleviate the burden of carrying several hardware components to meet the communications standards of different regions. In [
77], authors present CrossFlow, a principled approach for application development in SDR networks. CrossFlow provides a flexible and modular cross-layer architecture using the principles of SDR and a mechanism for centralized control using the principles of SDN. Through the convergence of SDN and SDR, CrossFlow works towards providing a target independent framework for application development in wireless radio networks.
Each vessel in the CSG has a SATCOM link for communication with other vessels and offshore-sites and more importantly for accessing the services on the GIG. It is important to note that small and medium sized ships within the CSG have limited SATCOM bandwidth, typically
Kbps, which prevents them from accessing large volumes of data. However, they can use the excess bandwidth of the
Mbps available to the larger ships within the strike group [
68].
Figure 8 depicts our proposed SDR-SDN driven communications between vessels for a representative CSG. Each vessel in the CSG – surface and underwater – is fitted with multiple SDRs and managed by an SDN Controller denoted as SDN-C. Note that the Carrier can have multiple controllers, i.e., SDN-Cs, along with one SDN Master Controller denoted as SDN-MC to manage the SDN-Cs. Each vessel in the CSG establishes and maintains an SDN-SDR driven communications link with the Aircraft-Carrier, i.e., V2C communication as previously noted. To maintain the V2C link, each vessel’s SDN-C communicates with the Carrier’s SDN-C using the SDN-SDR unified cross-layer network architecture.
With multiple SDRs, each vessel has the flexibility to dedicate specific SDRs for specific functions, such as AIS, secure COMMS, etc. While the hardware remains the same, the embedded software is adapted for each application. The carrier frequency, bandwidth, modulation, and other signal characteristics are specified to meet each communication system’s requirements. The use of the same hardware is an advantage in case of an SDR failure. Ready spares can be brought online, i.e., deployed, with the needed software functionality and replaced at sea. In a worst-case scenario, a working SDR for a lower priority system can replace a broken SDR in a critical system. Each Vessel in the CSG has its own SDN-C, which is responsible for managing a specific domain or segment of the network, ensuring optimal performance and handling local network events. But this teamwork does not stop within one ship, rather it extends to the Carrier itself and reaches out to other vessels in the CSG. The Carrier has its group of SDN-Cs, working together to make sure everything runs smoothly. In order to make sure everyone is in synchronization, that carrier has a special, global controller called the SDN Master Controller (SDN-MC). The SDN-MC oversees the entire CSG’d network infrastructure and acts as a central point of coordination for all vessels in the CSG. SDN-MC’s primary role includes global policy enforcement, network-wide optimization, and traffic engineering. It uses the insights provided by the SDN-C to make strategic decisions that promote efficient resource utilization, load balancing, and overall network resilience. Cooperation between the SDN-C and the SDN-MC is essential for ensuring seamless network operation. The SDN-C continuously provides real-time updates and status reports to the SDN-MC, enabling it to make informed decisions. The SDN-MC, in turn, communicates high-level policies and objectives to the SDN-Cs, ensuring that local decisions align with the global network goals. This collaborative approach allows for dynamic adaptation to changing network conditions, rapid fault detection and recovery, and efficient utilization of network resources.
The SDN-Cs on different vessels within the CSG can talk to each other by Vessel-to-Vessel (V2V) communication. The Carrier’s SDN-Cs stay in touch with the SDN-Cs on the other vessels using Vessel-to-Carrier (V2C) communication. This connection ensures that everyone is informed and ready to act, no matter where they are.
Figure 8 depicts this coordinated effort. This setup boosts the CSG’s ability to work as one unit, managing the network, adjusting communication on the fly, and adapting to new challenges in real time. Therefore, whether it’s ship-to-ship or ship-to-Carrier, this teamwork of SDN-Cs, guided by the SDN-MC, keeps the CSG connected and responsive, ready to tackle whatever the sea throws their way. In essence, this setup, i.e., the relationship between SDN-Cs and SDN-MC, optimizes network performance by combining the localized expertise of individual controllers with the overarching intelligence and strategic planning of the global controller, i.e., SDN-MC. In addition to the SDN-SDR driven V2V and V2C, each vessel in the CSG also maintains a SATCOM link for emergencies in the event SDN-SDR communication link goes down. Additionally, the Carrier maintains a high bandwidth SATCOM data-pipe to communicate with the GIG and other offshore sites. Having this high-bandwidth data-pipe also enables the Aircraft-Carrier to share its bandwidth with smaller ships in the CSG. In addition to maintaining a communications link with the Aircraft-Carrier, each vessel can also establish and maintain a V2V SDR-SDN communication link with nearby vessels.
5.5. Performance Improvement of SDN-SDR over SATCOM
The exact area occupied by a CSG can vary depending on numerous factors such as the number and type of ships in the group, the mission of the group, the conditions of the ocean, and the operational orders for spacing, among other things. The US Navy has conducted emergent technology experiments in its annual Trident Warrior exercises [
78]. In 2003, the Trident Warrior demonstrated the use of a line-of-sight (LOS) inter battle-group wireless network to improve both the availability and data rate of the three ships in the experiment compared to SATCOM only [
79]. With operations permitting LOS, operating frequencies from ship-to-ship can match the same frequencies used from ship-to-satellite and make use of the same amount of bandwidth
B as shown in the Shannon-Hartley formula,
where
C is the data rate in bits per second,
S is the received signal power, and
N is the received noise power. Among ships in the CSG, the distance will be much less (approximately 20 km) than the distance between the ships and the satellite (approximately 35,000 km), and that is an advantage in the V2V case due to
S reducing with the square of distance. In an AIS system, the satellite antenna gain is modeled at 6 dBi, whereas a shipboard dipole antenna may only have a gain of 2 dBi according to the ITU [
80]. However, the 4 dBi of advantage to the SATCOM system is erased by distance,
d in the Friis transmission equation,
where
is the transmitter power,
is the transmitter gain,
is the receiver gain, and
is the signal wavelength. The additive noise to the signal,
N is modeled as white Gaussian and is a function of noise temperature and bandwidth.
Based on Equations (
1) and (
2), the potential data rate with the same carrier frequency is much greater for a LOS V2V system compared to a SATCOM scenario due to the distances involved. However, if ships are operating beyond LOS, lower frequencies such as in the VHF to HF range need to be used. Since the maximum operating frequency is lower, the potential bandwidth will be likewise reduced. Additionally, when using an SDN-SDR unified framework, an additional processing delay will be incurred. Processing time in SDN refers to the time required for the SDN controller to manage and make decisions about network traffic and operations. This includes tasks such as analyzing incoming packets, determining routing or forwarding instructions, generating and updating flow rules, enforcing network policies, and responding to changes in network conditions. The processing time in an SDN is closely tied to the control plane activities managed by the controller. Depending on the complexity of the decision-making process and the load on the controller, this can introduce some delay. The control centralization, while beneficial, can introduce additional delays compared to traditional networks, where devices make decisions independently and in parallel.
There are two types of messages that need to be transmitted between the controller and switches in data planes: Packet-In (for packets that require controller decision) message and the FlowMod message (for defining new flow rules). When a packet arrives at a switch or router without a matching flow entry, it triggers a Packet-In message to be sent to the SDN controller. The processing time includes the time the controller takes to make decisions about how to handle the packet. The controller determines and generates flow rules (FlowMod messages) for switches to apply to incoming packets. This includes analyzing network conditions, policies, and the desired behavior.
It should be noted that even in SATCOM, which is the dominant mode of maritime communications, there is still a nodal delay,
. We can model
at the satellite as
where
is processing delay,
is queuing delay,
is transmission delay, and
is propagation delay. When SATCOM is used, we expect
to dominate in Equation (
3) the other component terms. It should be noted that not every node’s nodal delay components in every communication will be computationally significant, but it is important to treat them as non-trivial.
Let us consider the communication needs of Destroyer-1 (see
Figure 8), which is a smaller vessel in the CSG with limited bandwidth. With the proposed solution, Destroyer-1 can piggyback on the large bandwidth SATCOM data pipe of the Carrier. When Destroyer-1 needs access to information on the GIG or other on-shore sites, it will contact the Carrier with its request using the proposed SDN-SDR solution (see
Figure 8). If the requested information has previously been accessed by the Carrier, then it will be stored locally so that future requests from other vessels in the CSG, such as Destroyer-1, can be satisfied at a fraction of the cost. If, however, Destroyer-1’s requested information is not available locally on the Carrier, then the Carrier will request that information using a SATCOM data link which can support more throughput than the other ships’ links due to antenna size and gain advantages as seen in Equations (
1) and (
2). This alleviates the burden on Destroyer-1’s limited bandwidth SATCOM and potential long delays in accessing critical and time-sensitive information. In [
68], authors note that the typical SATCOM bandwidths found on small ships like a Destroyer range from
kbps, while large ships like the Carrier have the capacity for
Mbps. The cost of the extra-hop of communication from Destroyer-1 to the Carrier is insignificant compared to the cost that will be incurred - directly and indirectly - if Destroyer-1 were to make a direct SATCOM request.
The round trip propagation time when communicating to a km altitude geosynchronous satellite with a 25 degree slant angle is about 552 ms, i.e., ms. On the other hand, the line of sight communication for ships operating at a range of 25 km (i.e., Destroyer-1 to Carrier physical separation in this example) results in a round-trip propagation time of ms, i.e., ms. Assuming Destroyer-1 has a SATCOM bandwidth of 512kbps and Carrier has a SATCOM bandwidth of 2Mbps, assuming all the other nodal delay components are the same, the time to process the request for information made directly from Destroyer-1 will be 4x slower compared to a request made via the carrier. While this would add an additional hop with an added round-trip propagation of ms, the overall request would still be processed almost faster. Therefore, with the proposed solution, the additional communication hop between the Destroyer-1 and the Carrier is trivial compared to the overall round-trip propagation time. Finally, if the information requested by the Destroyer-1 has been saved locally on the carrier following a previous request, then the entire request can be satisfied without necessitating the use of SATCOM.