Enhancing IoT Connectivity and Services for Worldwide Ships through Multi-Region Fog Cloud Architecture Platforms

Abstract

As technologies such as eco-friendly ships, electric propulsion vessels, and multi-fuel propulsion systems advance, the scope of IoT applications in maritime fields is expanding, resulting in increased complexity in control factors. The gradual progression towards Maritime Autonomous Surface Ships (MASS) is further driving the evolution of ship-based IoT applications. These advancements underscore the necessity for a platform capable of ensuring reliable connectivity between ships and onshore. The limitations of the existing single cloud architecture become evident in this context. In response to these emerging challenges, this paper presents a cloud-based data platform structure anchored in the architecture of a multi-region fog cloud. Concurrently, we propose a strategic approach aimed at enhancing collision avoidance performance. This is achieved through the seamless sharing of navigation plan data among ships facilitated by the proposed platform structure. In regions densely populated with ships, there looms a potential for packet loss as data traffic sharing intensifies through the platform. To address this concern, we devised a traffic model based on the AIS data generation cycle and proposed an algorithm for subscription decision. Subsequently, we conducted comparative analyses of packet loss probabilities between the single cloud structure and the multi-region fog cloud structure. This was achieved through experimental packet loss data collected via the AWS cloud. Simulation results underscored a notable difference: with 100 subscribed ships, the packet loss probability in regions assuming a single cloud was about 28 times higher compared to the same region within the multi-region fog cloud structure. These simulations affirm the stable and effective implementation of the proposed collision avoidance performance enhancement method within the multi-region fog cloud structure. Furthermore, feasibility was corroborated through the successful implementation of the proposed platform via the AWS Cloud.

1. Introduction

The advancement of automation systems and the integration of IoT technology are ushering in a transformative era for maritime operations [1]. This paradigm shift has given rise to innovative ship operations, including smart ships, remote operating vessels, and digital twin ships [2,3]. Recognizing the potential of these technological strides, the International Maritime Organization (IMO) has actively engaged in discussions around the safe operation of Maritime Autonomous Surface Ships (MASS). These vessels are defined as capable of navigating surface waters with minimal or no human intervention and are categorized into four stages based on their degree of automation [4].

The increasing recognition of MASS underscores the need to address critical challenges surrounding data sharing, communication [5], and interoperability between ships and onshore operations [6]. Efficient data management, real-time monitoring, and informed decision-making are paramount for enhancing safety, operational efficiency, and performance in autonomous maritime environments [7].

To this end, a robust and versatile IoT-based cloud data platform that can interact with ship automation systems already in place on ships and develop new services is essential.

This paper presents a novel cloud-based horizontal data platform structure specifically tailored to support multiple services in the maritime field, utilizing IoT data collected from ships. The horizontal data platform enables multiple ships and services to operate organically on a single unified platform [8]. By leveraging a common ship data collection infrastructure, new services can be effortlessly integrated by adjusting relevant architectural elements within the horizontal slice.

Ships traverse the globe, and the companies overseeing these vessels are distributed worldwide. This extensive geographical distribution poses challenges in maintaining consistent service quality through a single cloud infrastructure. To address these challenges, this paper introduces a platform comprising multiple Fog Clouds and a single global Cloud Center. The innovative data collection and sharing infrastructure of this platform enable the Edge Server, responsible for collecting and managing ship data, to interact with the Fog Cloud in the region with the most optimal latency. Data gathered from the Fog Cloud is efficiently transferred and managed within the Cloud Center, providing a standardized data structure and interface that simplifies the development of new services. The overarching goal of this platform is to empower IoT systems aboard ships navigating the globe, allowing seamless data sharing, utilization for various services, and effective collaboration with onshore services.

Fog computing paradigms have gained significant popularity as effective ways to maximize the efficient utilization of resources offered by IoT devices. These paradigms not only extend the quality of service to the immediate vicinity of the user but also enable rapid processing within the dynamic IoT-cloud ecosystems [9]. Numerous studies in the maritime sector, including ships, are actively exploring the efficient collection of data through fog computing and optimizing functions through offloading [10,11].

In Section 3, we design a hierarchical platform structure, differentiating between onboard and onshore, and outline stakeholders and functional elements at each layer. We propose necessary components and relationships for Edge Server, Fog Cloud, and Cloud Center. The multi-region fog cloud structure offers advantages in connectivity, including latency and packet loss. We capitalize on these benefits to propose a data sharing method for collision avoidance.

In the context of autonomous ships, technology enabling collision avoidance and safe operation is paramount, considering ship safety. Prior research mainly focused on predicting and avoiding collisions based on the current navigation status of surrounding ships through complex sensing. However, this paper proposes a method to enhance collision avoidance performance by enabling ships to share not only their current navigation status but also their planned route and navigation status with surrounding vessels through a data platform. This method augments collision avoidance performance by sharing confirmed plan data, albeit introducing additional traffic for data sharing. While such data sharing is possible even in a single cloud structure, in areas densely populated with ships, packet loss may occur depending on the traffic due to the increased data receipt from nearby ships. To compare packet loss between a single cloud connected to a different region and a multi-region fog cloud structure attached to the same region, we created a traffic model based on the number of surrounding ships, employing a Poisson distribution through the reception period of AIS data. By comparing packet loss by region in conjunction with packet loss measurements according to AWS cloud traffic, the results demonstrate that with 100 nearby ships subscribing to data, when the regions differed, the packet loss was about 28 times higher than in the same region.

Section 4 proposes an architecture for the implementation of the aforementioned platform using AWS, a prominent public cloud provider. It includes tests designed to measure Round Trip Time (RTT) and Packet Loss Rate (PLR) across different regions, aiming to assess the extent and unique characteristics of network benefits achievable within the same region.

2. Related Work

Over the past decade, substantial research has been undertaken under the topics of “e-navigation” and “MASS,” focusing on automating ship operation and management. These research projects mainly use IoT technology in maritime fields, leading to significant advancements in Ship Operation Technology (OT) by merging it with Information Technology (IT). This fusion has given rise to the development of numerous automated systems with the explicit goal of minimizing the need for extensive human intervention.

One area of ongoing research focuses on collision avoidance measures for safe navigation [12]. This research is instrumental in preparing for the autonomous ship era, seeking to minimize human involvement in navigation processes. Additionally, studies are actively exploring ways to enhance existing functions or create novel services through the sharing and effective management of data, facilitated by communication between ships or ship-to-onshore interactions [6].

Furthermore, notable recent efforts have been dedicated to laying the groundwork for MASS. This involves the seamless integration of the ship’s automation system with onshore solutions, achieved through a cloud-based platform. This platform serves as a critical bridge, enabling efficient data exchange and collaborative interactions between ships and onshore entities, contributing to the realization of autonomous ship capabilities [10,11].

2.1. Ship Automation System

The ship’s automation system plays a crucial role in aiding users in making informed decisions by collecting and conveying operational data, while also integrating control components to ensure the ship adheres to these decisions. Figure 1 illustrates a comprehensive configuration consisting of two essential systems: The Integrated Navigation System (INS) for ship navigation and the Integrated Control and Monitoring System overseeing control of onboard facilities. Within the INS, critical unit systems like the Electronic Chart Display Information System (ECDIS), RADAR, Track Control System (TCS), Bridge Alarm Monitoring System (BAMS), and Autopilot work harmoniously, playing vital roles in planning and executing the ship’s route. The INS follows the IEC61924-2 standard, precisely defining its modular structure and performance criteria, ensuring the monitoring of connected sensor availability, effectiveness, and integrity [13].

While traditional INS systems mainly support human decision-making by visualizing data, ongoing research aims to minimize human intervention and empower the system to navigate autonomously by perceiving its surroundings. Studies focus on developing stable algorithms, guidance, and control mechanisms for collision avoidance, with the goal of significantly enhancing the system’s capability to effectively avert potential collisions [14,15].

The ship is outfitted with an Integrated Control and Monitoring System (ICMS), functioning as a decentralized control system overseeing the operation of machinery and electrical equipment. Figure 2 illustrates the system architecture of ICMS. The green section signifies the area where the controller manages each piece of equipment. Within the orange area is the Operator Work Station (OWS), offering a Human Machine Interface (HMI) for users to monitor or directly control the operational status. The rising demand for eco-friendly ships, such as LNG carriers, electric propulsion vessels, and Dual Fuel Engine ships, has introduced greater complexity and diversity of control factors within the ICMS. To address these advancements, dedicated research efforts are concentrated on creating an environment that supports the swift and secure development of sophisticated ships and control technologies, leveraging digital twin technology [16]. Furthermore, ongoing studies aim to integrate and optimize systems through virtual simulation environments [17]. However, to transform these research activities into tangible outcomes and effectively implement them on actual ships, the existence of a real-time data platform seamlessly connecting and managing ship data is imperative.

2.2. Generation and Propagation of Ship Navigation Data

The ship’s navigation-related sensor data is generated following the IEC61162-1 standard [18] in the case of serial communication and the IEC61162-450 standard [19] for Ethernet communication, which has been expanded to handle various types of data. The Automatic Identification System (AIS) extracts the data generated by these protocols and disseminates messages containing the location and voyage information of the ship to surrounding vessels over the Very High Frequency (VHF) frequency. The transmission period is shorter for faster vessels, ensuring neighboring ships can promptly and safely detect them.

The AIS data encompasses different categories based on message types [20]. Among these, the message types directly related to navigation status are 1, 2, and 3, allowing ships to gain insight into the current navigation status and the locations of surrounding vessels through the distribution of these messages. Additionally, AIS transmits the data it sends and receives to the INS network using a standard protocol based on IEC61162-1 [18], enabling navigation equipment to comprehend the surrounding context and display relevant data to users.

Numerous ongoing studies are actively striving to enhance the operational and management performance of ships through the effective utilization of AIS data. In [21], researchers integrated AIS data to cluster ship trajectories, suggesting its potential use in collision avoidance by predicting ship paths. In [22], a preprocessing technique was proposed to manage and analyze the substantial quantities of AIS data collected. This technique aimed to enhance data management performance and route monitoring capabilities. Recognizing the limitations imposed by the limited transmission distance of AIS data through VHF due to Earth’s curvature, research is underway to harness satellites for collecting and utilizing a broader spectrum of AIS data, as demonstrated in [23]. This study successfully tracked ships through coastal images and AIS data obtained from satellites, effectively detecting unauthorized ship access.

While AIS data provides substantial navigational information, it is confined to data pertinent to the current ship state due to bandwidth restrictions. As the deployment of Low Earth Orbit (LEO) satellites expands the communication connectivity of ships and the phased realization of MASS necessitates more advanced automation, a broader array of data delivery methods is imperative. This need arises to address the evolving requirements of maritime systems and unlock the potential benefits of advanced autonomous ship capabilities.

2.3. Ship Data Collection and Service

In conjunction with AIS data, a multitude of sensors embedded in engine systems, including the engines themselves, generate real-time data based on the ship’s operational status. Diverse research endeavors are actively contributing to the creation of a comprehensive platform capable of gathering such ship-related data and facilitating the expansion of data sharing and functionalities between ships and onshore systems.

In [24], the research centers on applying IoT technologies to unmanned ships, exploring intelligent recognition, sensor fusion, and communication. This work culminates in the proposal of an E-Navigation framework aimed at connecting ships with onshore systems. In [6], a Machine-Type Communication Framework is presented to enable efficient communication between peripheral ships and cloud systems, utilizing short-range and broadband connections. It aims to enhance MASS capabilities, promote interoperability, and facilitate seamless data exchange and collaboration in the maritime domain.

As the integration of IoT technology in ships advances, research has also delved into new services and service management. In addition to the earlier discussion on collision avoidance, there is a significant focus on creating optimal routes using weather forecast data to enhance operational performance in a safe and cost-effective manner [25]. In addition, there has been research aimed at creating an Operator Training Simulator (OTS) environment. This simulation setup onshore closely replicates the ship’s operating conditions [26]. The primary purpose of the OTS environment is to train both the crew and the ship’s system to collaborate effectively, eliminating the need to physically visit the site during the development stage of ship operation technology, which is becoming increasingly intricate. An investigation in [27] revealed that education through remote OTS environments contributes to enhanced navigation skills, especially as we move towards an era of training remote operators to handle actual MASS.

The expansion of technology and services in the maritime industry has led to a growing number of software applications that need to be managed. This increase in software complexity has posed challenges in management. In [28], a study was conducted to address this issue by efficiently allocating Software Quality Assurance (SQA) resources in ship operating environments. The focus was on predicting defects in newly developed software based on models trained using historical software defect data. As software becomes increasingly vital for ship operations, the importance and reliance on S/W quality management techniques have grown. This has created an essential research area dedicated to maintaining service quality within the unique context of the maritime environment.

Research was also conducted to build a cloud-based IoT service platform in conjunction with ship IoT devices [10,11,29]. Cloud platforms provide scalability, flexibility, security, and availability, which makes them well-suited for creating expansive IoT environments [30]. In [31], prominent cloud-based IoT platforms like AWS IoT, Azure IoT, Watson IoT, PTC ThingWorx, and Google IoT are identified. The study affirms that these public clouds provide essential functionalities for constructing extensive IoT environments. Among them, AWS IoT is the most widely used public cloud, boasting numerous references and ongoing research in designing and implementing structures tailored to specific applications and purposes [32,33].

2.4. Limitaions of Existing Research and Goals of This Paper

Large ships, vital for global trade, constantly traverse the seas, managed by shipping companies scattered worldwide. The burgeoning use of ship IoT devices presents a challenge for enhancing service quality related to these ships within the confines of the conventional single cloud architecture is a daunting task. Thus, leveraging the Fog computing paradigm becomes imperative. While there is ongoing research in applying Fog computing to the maritime sector, the integration with ship automation systems aboard these large vessels has been a relatively unexplored territory.

In this study, we propose a platform rooted in the multi-region Fog Cloud model, aiming to bolster onshore concurrency by establishing a seamless link with a ship’s onboard automation system.

Historically, research focused on collision avoidance predominantly involved predictive strategies based on current ship positions owing to the uncertainty in the trajectories of surrounding vessels [12,14,15]. Contrary to prior approaches, our proposed platform enables real-time data sharing among ships through the Fog Cloud within the same region. This facilitates the exchange of planned routes and navigational intentions, leading to significantly improved collision avoidance by confirming data against shared plans.

Even within a single cloud structure, data can be shared with nearby ships. However, in regions with high ship density, an escalation in communications with nearby ships may precipitate packet loss. To assess this, we develop mathematical models and conduct measurements to evaluate packet loss, comparing communication results assuming a single cloud with those assuming a multi-region fog cloud, considering cases implemented through AWS Cloud.

3. Design of Multi-Service Data Platform

To prepare for the upcoming era of MASS, the need for a versatile platform that can accommodate the distinct requirements of each service, while considering the unique movement characteristics of ships, becomes paramount. In this section, we introduce a cloud-based multi-service data platform that encompasses a multi-region Fog Cloud and elucidate the operational framework that enables the seamless functioning of diverse services, all built upon this unified platform. By leveraging this innovative approach, various services can be efficiently operated, capitalizing on the platform’s adaptability and scalability, thus paving the way for the realization of autonomous ship systems.

3.1. Cloud Data Platform

3.1.1. Structure Composed of Multi-Region Fog Cloud

Within cloud-based IoT services, the Fog Cloud emerges as a critical component, efficiently harnessing the resources of IoT devices while simultaneously enhancing service quality in close proximity to users [9]. The maritime sector’s increasing deployment of hundreds to thousands of sensors and actuators for automated ship navigation and engine control underscores the growing reliance on IoT technology [1]. The adoption of Fog Cloud in the maritime domain offers a promising solution, particularly as the number of ships equipped with numerous control elements continues to rise.

The proposed platform introduces a pivotal role for the Fog Cloud, facilitating seamless data exchange and real-time functional operations between connected ships and onshore facilities or other ships. This cohesive integration effectively establishes a dynamic network, empowering ships to communicate and collaborate effortlessly, even in real-time scenarios.

Figure 3 illustrates the platform topology built around the multi-region fog cloud. This setup comprises a cloud center primarily dedicated to data management and service development, along with a fog cloud optimized for service execution. This configuration facilitates the creation and implementation of diverse services tailored to the maritime environment. Given the worldwide movement of ships, establishing a seamless connection to a Fog Cloud that adapts based on their current location is of paramount importance. The Fog Cloud is meticulously designed to accommodate ship connections, initiating a secure Edge Secure Channel using pre-registered global device provisioning details for encrypted and protected communication with the vessels.

Clients seeking to build services based on data from ships within the same region, such as ports and logistics entities, can seamlessly develop these services through the Fog Cloud. Conversely, when a specific ship is designated for a particular service, such as in the case of a shipping company, the service can be constructed using cached data sourced from the Cloud Center. During this process, the Cloud Center’s data is restricted to services that tolerate relatively higher latencies, as it is collected from data processed through the Fog Cloud at the ship’s present location.

Clients can conveniently access the Fog Cloud’s Web Service via the Public Internet network, enabling them to utilize the services built in this manner. The Cloud Center plays a vital role in managing data collected from the Fog Cloud and oversees the distribution and operation of software and services on the ship’s Edge Server and Fog Cloud in each respective region. This functionality enables service developers to deploy and enhance new services efficiently by analyzing and utilizing the data available in the Cloud Center.

3.1.2. Functional Structure of Onboard and Onshore

The application of Fog cloud structure to IoT platforms, both onboard and onshore, is a subject of extensive study across various domains, taking into consideration factors such as cost, responsiveness, real-time capabilities, and scalability. In [9], a Fog computing framework was delineated into four layers. At the base of this framework lies the IoT Service layer comprising end devices and a data collection layer. The subsequent layer is the Fog layer, occupying the middle tier, followed by the Cloud layer at the top. In another study [34], a four-layer edge-fog-cloud structure was devised to alleviate the burgeoning load imposed by the increasing number of IoT devices and automation technology in the agricultural sector. The Edge Layer, incorporating the IoT layer and LAN connected through diverse IoT device communication methods, processes data at the foundation, while the Fog Layer, constituted by MAN, and the Cloud Layer, constituted by WAN (depending on the network location), reside at the apex. A similar structural model was applied to integrate Fog computing in the shipping and marine domain [10,11].

In this paper, the previously explored fog cloud structure has been adapted for the shipping field, where each layer has been divided into onboard and onshore components, clearly defining the primary service targets for each layer. Figure 4 conceptually illustrates the representative functions and interaction relationships for each tier of the platform. The Edge Server plays a crucial role in collecting data from the ship’s automation system, conducting Extract, Transform, Loading (ETL) processing, and providing services to sailors. Additionally, it manages connectivity to ensure consistent service quality as the ship moves around the world. Achieving this connectivity management entails establishing a unified entry point to the cloud, facilitating the identification of the nearest fog cloud, and entrusting the Edge Server with the task of sustaining the connection to the located fog cloud. The Fog Cloud is distributed with services that require high real-time responsiveness. In instances where services involve collision avoidance for autonomous operations or engine system control for ship safety, interaction with the ship’s Edge Server while operating on the Fog Cloud is necessary to avoid potential delay issues.

The Cloud Center is connected to the Fog Cloud in each region through the Virtual Cloud Network, serving as a repository for data collected from the Edge Server or generated during service operations. By pre-caching the data required to serve clients in the region, the Fog Cloud delivers high-quality services directly from the Cloud Center. Service developers and operators must carefully consider which components of the services they build will operate and interact with the Edge Server, Fog Cloud, or Cloud Center.

3.1.3. Platform Functional Element Structure Diagram

Figure 5 delineates the components and interconnections of the platform designed to construct services in collaboration with the ship’s automation systems, categorized by layer.

• Data Processing Layer: This layer primarily focuses on acquiring, storing, and managing data. The Edge Server serves the crucial function of translating ship-related data, adhering to the ship’s data model, into the platform’s data model. The data transformed in this manner is either distributed to onboard services or transmitted onshore. Onshore, the lifecycle of data is managed. Within the Fog Cloud, only essential data is managed, while the Cloud Center stores data as per the data retention policy for subsequent data analysis and restoration.
• Exchange Layer: This layer facilitates the exchange of data and functions among ships or between onboard/onshore components. The Edge Server maintains a persistent connection with the nearby fog cloud, and the fog cloud governs authentication and functional elements to ensure that provisioned devices sustain secure and stable services.
• Application Layer: Operating the application specific to the service target of each component, this layer manages scalability in accordance with the service scale and target. The Edge Server and Cloud Center possess static primary service scales and targets. Conversely, the Fog Cloud’s scale is variable, contingent on the user’s location and the ship’s mobility. To effectively respond to these fluctuations, Network Accelerator and Load Balancer prove instrumental.

In this structure, the time delay for processing and servicing data and requests received from the edge server onshore is expressed as follows.

$$L^{tot}=L_{T\left(i\right)}^{fog}+L_{P\left(i\right)}^{tot}+L_{Service\left(i\right)}^{fog}$$

(1)

• $L_{T\left(i\right)}^{fog}$: Latency experienced when Task i transmits data to the Fog Cloud, influenced by the size of the request packet.
• $L_{P\left(i\right)}^{tot}$: Total processing time required onshore for Task i.
• $L_{Service\left(i\right)}^{fog}$: Delay time involved in providing the service, utilizing the results of processing.

In the Fog Cloud structure, onshore processing occurs in parallel within both the Fog Cloud and the Cloud Center. As a result, $L_{P\left(i\right)}^{tot}$ is determined as follows.

$$L_{P\left(i\right)}^{tot}={\mathrm{m}\mathrm{a}\mathrm{x}(L}_{P\left(i\right)}^{fog},L_{P\left(i\right)}^{cloud})+L_{T\left(i\right)}^{onshore}$$

(2)

Given that ships traverse the globe and shipping companies, the end-users of the service, are distributed worldwide, the existing single cloud structure leads to varying $L_{T\left(i\right)}^{fog}$ and $L_{Service\left(i\right)}^{fog}$ based on the distance from the cloud location and the network status. This introduces significant variability into the fog delay. However, by employing the multi-region Fog Cloud structure, this delay time can be minimized and maintained at a constant level. Additionally, by operating in parallel with the Cloud Center depending on the task, the overall delay time can be significantly reduced.

3.2. Ship-to-Ship Navigation Data Exchange for Collision Avoidance

3.2.1. Leveraging the Platform for Navigation Data Exchange

Ships rely on AIS, a legal equipment, to receive diverse data from nearby vessels and disseminate their own data to the surrounding area. When a ship is operational, its navigation status information is included in position report messages and broadcasted to nearby ships or coastal base stations [20]. However, these navigation data have limited usability as they can only provide the current location and operational status.

To address these limitations, this paper proposes a novel method that utilizes AIS information to enhance ship operations and promote stability. The approach involves sharing not only the ship’s planned route but also relevant information about surrounding ships through a comprehensive platform.

In the context of AIS messages, the uniqueness of the MMSI (Maritime Mobile Service Identity) number cannot always be guaranteed since it is directly entered by users into the equipment. To address this, when a ship receives an AIS message, it can request the Ship Identification Number (SIN), which serves as a unique ID for subscription, from the Fog Cloud’s service using its MMSI and location information. To enable data sharing, the Edge Server extracts specific data, as outlined in

Table 1. List of data sharing topics for collision avoidance.

Data Type	Topic	Retain
Own ship AIS	ais/vdo/[SIN]/cab	Not retain
Other ship AIS	ais/vdi/[SIN]/cab	Not retain
Planned route under navigation	route/voyage/[SIN]/rtz	Retain

, from the Ship Automation System and publishes it to the Fog Cloud by Message Queuing Telemetry Transport (MQTT) during the ship’s operation.

Every vessel periodically publishes its AIS, surrounding AIS, and route plan information to the Fog Cloud. Subsequently, the SIN is requested and received from the Fog Cloud using the MMSI and position information of the surrounding waters that received the AIS. SIN serves as an ID identifying a ship on the platform, ensuring uniqueness and enabling subscription and receipt of data published by the ship using the SIN. Figure 6 provides a step-by-step illustration of the interaction between ships in this process.

SIN1 periodically publishes its information. As SIN1 enters the AIS reception range of SIN2, SIN2 can receive information from SIN1 through the Fog Cloud and utilize it for collision avoidance. Even when SIN1 is not within its AIS reception range, SIN3 can proactively obtain and utilize information about SIN1, which might be encountered in the future, through information on nearby vessels published by SIN2. SIN4, outside the AIS reception range of SIN2, unsubscribes from data topics to halt further data reception.

By enhancing connectivity through the Fog Cloud, the number of ships that can subscribe can be increased compared to the Single Cloud structure. However, excessive subscriptions can lead to packet loss and increased traffic, depending on wireless communication characteristics and cloud region conditions. Hence, it is imperative to strategically unsubscribe from ships outside the reception range and model the total number of subscribers capable of stable data reception when considering new subscriptions.

3.2.2. Subscription Control to Reduce Packet Loss

We introduced an approach to retrieve navigation data and planned routes from nearby vessels utilizing AIS transmitted via VHF through a designated platform. This data is instrumental in enhancing collision avoidance by providing insight into ships in non-line-of-sight (NLOS) based on their movements and planned routes—a level of detail often not accessible through AIS alone. However, this approach necessitates additional data traffic as exchanges with the platform occur via satellite communication. Particularly in regions with high ship density, simultaneous data reception could lead to packet loss contingent on platform and network performance, underscoring the need for selective subscription to ship data.

Algorithm 1 provides a comprehensive guide on effectively handling the overall count of subscribed ships by computing packet loss probability tied to ship density. The ability for ships to subscribe at a given $P_{loss}^{th}$ is fundamentally dictated by $P_{loss}$, an indicator of connection stability with the platform. In the traditional single cloud structure, $P_{loss}$ is typically high due to the often considerable distance from the ship to the connected cloud region. Conversely, in the proposed multi-region fog cloud structure, $P_{loss}$ can be mitigated by maintaining a more stable connectivity.

Algorithm 1: Subscription Decision Algorithm

Input:  Newly received AIS data ${AIS}_{new}$  Number of ships subscribed $N_{sub}$  Distribution of number of messages received $P_{msg}$  Loss probability distribution according to $P_{msg}{P}_{loss}$  Total loss probability at $N_{sub}$ $P_{loss}^{tot}\left(N_{sub}\right)$  Loss probability threshold $P_{loss}^{th}$ Onput:  Subscription decision result $R_{sub}$

1    Initialize $P_{loss}$ according to connected region and location  2    Extract MMSI and position from ${AIS}_{new}$  3    Request ${SIN}_{new}$ with MMSI and position  4    if ${SIN}_{new}$ is exist  5        Calculate $P_{msg}\left(N_{sub}+1\right)$  6        Calculate $P_{loss}^{tot}\left(N_{sub}+1\right)$ using $P_{msg}$ and $P_{loss}$  7        if $P_{loss}^{tot}$ < $P_{loss}^{th}$  8            $R_{sub}$ $\leftarrow “Subsribe”$  9            $N_{sub}$ $\leftarrow$ $N_{sub}$ + 1  10      else  11          $R_{sub}$ $\leftarrow “DonotSubscribe”$  12   else  13      $R_{sub}\leftarrow “DonotSubscribe”$  14   end if  15   return $R_{sub}$

If the ship possesses knowledge of $P_{msg}$, which represents the distribution of the number of messages to be received per unit time based on the number of nearby ships, as well as $P_{loss}$ in the current location and the connected region, these can be combined to derive the total packet loss probability $P_{loss}^{tot}$. In cases where packet loss occurs, it can trigger additional traffic for retransmission, potentially posing a safety hazard for navigation. Consequently, if the computed $P_{loss}^{tot}$, obtained by specifying the automatic probability limit $P_{loss}^{th}$, is lower than $P_{loss}^{th}$, subscription is advised. Conversely, if it surpasses this threshold, subscription is avoided to prevent potential complications.

Algorithm 2 outlines a procedure for efficiently managing the unsubscription of ships already subscribed, aiming to maintain an optimal count of subscription ships. The unsubscription decision is guided by two primary criteria: AIS reception timeout and the importance of the ship’s information. Firstly, concerning AIS reception timeout, monitoring ${RT}_{sub}$, which records the last AIS reception time for the subscribed vessel, is crucial. As ships are navigating, they transmit AIS signals at intervals of at least 3 min. If no reception is noted for a duration exceeding 3 min, it strongly suggests that the vessel has moved beyond AIS reception range, prompting an automatic unsubscription. Secondly, evaluating the significance of ship information involves a comprehensive assessment encompassing location, speed, and trajectory. In instances where Algorithm 1 has canceled the subscription decision for a particular ship, the importance levels are compared. Subsequently, ships with importance levels lower than the new ship among the existing subscribed vessels are identified for unsubscription, thus making room for the subscription of new ships.

By leveraging these dual criteria, Algorithm 2 effectively determines the vessel, $S_{unsub}$, to be unsubscribed from the subscription list, ensuring a streamlined and optimized subscription management process.

Algorithm 2: Unsubscription Decision Algorithm

Input:  Last AIS reception time for subscribed ships ${RT}_{sub}$  Dynamic information importance factor of subscription ships ${IF}_{sub}$  Algorithm 1 result for ${SIN}_{new}$ $R_{sub}$ Onput:  Unubscription decision ship $S_{unsub}$

1    for each time ${rt}_i$ in ${RT}_{sub}$ do  2        if ${rt}_i$ > 3 min.  3            $S_{unsub}$ $\leftarrow$ ${SIN}_i$  4        end if  5    end for  6    Update all ${IF}_{sub}$ according to current surroundings  7    if $R_{sub}$ = $DonotSubscribe”$  8    Calculate ${IF}_{new}$ of ${SIN}_{new}$  9        for each time ${if}_i$ in ${IF}_{sub}$ do  10          if ${if}_i$ < ${IF}_{new}$  11             $S_{unsub}$ $\leftarrow$ ${SIN}_i$  12          end if  13       end for  14  end if  15  return $S_{unsub}$

3.2.3. Modeling the Probability Distribution of AIS Reception Counts

The frequency of AIS data reception from neighboring vessels through the platform varies each second, contingent on ship speeds and route alterations. We employ the Poisson distribution to statistically model this variation, represented by the following equation.

$$P_{msg}=\mathrm{P}\left(N\left(t\right)=k\right)=\frac{e^{-\lambda \left(t\right)}{ · \lambda \left(t\right)}^k}{k!},\lambda \left(t\right)={\mathsf{\lambda }}_0 · D\left(t\right)$$

(3)

• $\mathrm{P}\left(N\left(t\right)=k\right)$: This represents the probability of receiving k AIS data pieces within the time t.
• $D\left(t\right)$: Denotes the count of ships nearby.
• ${\mathsf{\lambda }}_0$: Average rate of AIS data transmission per vessel.
• $\lambda \left(t\right)$: The rate of AIS data reception.
• $k$: The count of AIS data received during time t.

In

Table 2. AIS Class A shipborne mobile equipment reporting intervals.

Ship’s Dynamic Conditions	Nominal Reporting Interval
Ship at anchor or moored and not moving faster than 3 knots	3 min
Ship at anchor or moored and moving faster than 3 knots	10 s
Ship 0–14 knots	10 s
Ship 0–14 knots and changing course	3 1/3 s
Ship 14–23 knots	6 s
Ship 14–23 knots and changing course	2 s
Ship > 23 knots	2 s
Ship > 23 knots and changing course	2 s

, the AIS transmission cycle for a ship is outlined based on its operating state [35]. The average AIS reception rate ${\mathsf{\lambda }}_0$ from a single ship, considering the six operational states, can be calculated as follows using Equation (4):

$${\mathsf{\lambda }}_0=\frac{6}{10+3\frac{1}{3}+6+2+2+2}=0.2369$$

(4)

Consequently, the probability distribution for the number of AIS receptions (k) can be defined by Equation (5):

$$\mathrm{P}\left(N\left(t\right)=k\right)=\frac{e^{-\lambda \left(t\right)}{·\left(0.2369·D\left(t\right)\right)}^k}{k!}$$

(5)

This equation allows us to regulate the number of ships to subscribe to ensure that the message rate per second remains below a specific level, provided we have knowledge of the message communication rate per second at which packet loss is averted.

3.3. Scalability Strategies for the Platform

As the demand for diverse services surges within the maritime sector, the number of connected ships, data providers, and onshore platform service consumers will increase. The proposed platform is designed with inherent scalability features to effortlessly accommodate this rising demand through the following functions:

• Edge Server: The platform offers a standardized format for MQTT topics, value structures, and APIs, facilitating seamless integration with the ship’s automation system and IoT devices. As new IoT equipment or automation systems are integrated into the ship’s system, the data to be collected or linked can be added, edited, or deleted using a configuration function that can be customized to align with the standardized format.
• Fog Cloud: The ship’s edge server transmits the collected data, along with a ship number that serves as an index for the ship, to the Fog Cloud via MQTT communication. The MQTT structure follows this pattern: [function]/[object]/[SIN]/[data type]. This ship number-based indexing enables straightforward expansion when new ships are added, requiring only permission grants for the ship to an account or service.
• Cloud Center: Within the cloud center, functions are generated and distributed to the Edge Server or Fog Cloud. Given the uniformity of the standard format and APIs for data supply from the platform across all ships, services can be easily developed, provided access is granted.

These scalability strategies ensure the platform can seamlessly grow and adapt to accommodate an increasing number of ships, data providers, and evolving service requirements within the maritime domain.

4. Implementation and Test

This chapter unveils the outcomes derived from the development of a multi-region fog cloud platform architecture using AWS, specifically tailored for the ship multi-service concept introduced in Section 3. Furthermore, comprehensive network communication assessments are undertaken across global regions. These evaluations aim to gauge the advantages intrinsic to the proposed architecture in scenarios where data sources, exemplified by ships, exhibit worldwide mobility attributes, and customer bases are geographically dispersed.

4.1. Implementation with AWS Cloud Architecture

Figure 7 depicts a multi-region cloud architecture diagram established within the AWS cloud infrastructure. The strategic placement of the Cloud Center is advised in the region where the platform operator is active and engaged in service development. Fog Cloud distribution and construction offer benefits when strategically positioned in regions of concentrated ship activity or areas predominantly serviced by shipping companies and logistics ports.

Embedded within this construct is the AWS Global Accelerator [36], a networking service that orchestrates an efficient network, allowing patrons to connect with minimal latency when the Fog Cloud sprawls across regions such as Europe, the Americas, and Asia. This orchestration empowers users to promptly access Regional Data generated by the Fog Cloud within their own domain, enabling them to generate or validate OLTP system-related data arising from user analysis or specific requests.

Given the worldwide mobility of ships, their integration with the Fog Cloud necessitates connection to the nearest regional instance, expertly guided by Geo-location. AWS Route53 [37] serves as the common entry point, intelligently directing routing toward the nearest Fog Cloud to achieve optimal latency levels. By means of this routing mechanism, the ship’s Edge server effectively links with the Global Device Provisioned Fog Cloud, ushering in services encompassing data monitoring, route planning based on weather conditions, and seamless software updates.

In an intricate dance of data, information harvested from ships finds residence in both the Fog Cloud for localized service provisions and the Cloud Center for comprehensive data analysis and monitoring. This strategic storage approach ensures that the Fog Cloud primarily retains short-term data, importing and servicing data from the Cloud Center only when necessitated. This dynamic data management ensures an efficient utilization of resources.

The Cloud Center functions as a hub for platform developers and operators, primarily focused on service development and software maintenance. For services demanding substantial resources or data-centric operations, the Cloud Center serves as the nexus. Consequently, even the database of the OLAP system revolves around and is managed within the Cloud Center.

Developers can seamlessly utilize the DevOps environment integrated into the Cloud Center. This empowers them to manage source code configurations, develop software with builds, and efficiently deploy it to the testing environment following DevOps procedures. Upon successful testing, software distribution and management occur within the deployment environment of each Fog Cloud, encompassing both the ship’s Edge Server and the container service environment of the Fog Cloud.

4.2. Network Latency and Packet Loss Rate Test

In this chapter, we conducted tests to assess the potential improvement in network performance achievable through the utilization of a multi-region Fog Cloud. Specifically, we examined RTT-based Latency and Packet Loss Rate (PLR) by configuring tests in both the same region and different regions. The test setup is depicted in Figure 8. Considering the laptop as a representative vessel located in the Seoul region, we conducted the test by engaging in the publication and subscription of messages to the IoT Core, which functions as an MQTT Broker. This testing process was carried out across three distinct regions: Seoul, California, and Frankfurt.

Latency was gauged using the RTT between the transmission and reception of published and received packets. As the maximum message size supported by the IoT Core is 128 KBytes, the measurements were taken up to 120 KBytes, incrementing the payload by 20 Kbytes from the initial 20 KBytes. The publish/subscribe actions were executed with Quality of Service (QoS) set to 0, and this testing was performed 100 times for each payload size. Figure 9 graphically presents the outcomes of these tests in the form of a box plot.

Considering that the testing took place in Seoul, the RTT exhibited the following patterns across the three Fog Cloud regions: the lowest median RTT was observed in the Seoul Region, ranging from 0.072 to 0.175 s. The California Region followed with the highest median RTT, spanning 0.21 to 0.292 s, and the Frankfurt Region exhibited the highest with a range of 0.326 to 0.400 s. When comparing the RTT with that of the Seoul region based on different payload sizes, as depicted in Figure 10, it becomes evident that smaller payloads exhibit a more pronounced variance in RTT across regions. For a 20 KB payload, the RTT difference across regions ranged from two to five times, and for a 120 KB payload, the difference was around two times.

In our evaluation of latency using an open-source project tool called the Azure Speed Test Tool [38], designed to measure communication latency between various regions, we obtained the following latency measurements for the Seoul, California, and Frankfurt regions: 45 ms, 150 ms, and 193 ms, respectively. Figure 11 provides a clear comparison of the significantly higher latency in different regions of AWS and Azure compared to the Seoul region, which is within the same region. Notably, if both clouds are in different regions, latency increases by about four times or more.

Packet Loss Rate (PLR) was evaluated as the packet generation rate (PGR) increased for each payload size. The assessment was conducted utilizing QoS0 settings. After establishing a connection, 100 packets were published based on the designated PGR, and PLR was subsequently determined by the count of received packets during subscription. This procedure was repeated 10 times per payload and region.

Interestingly, across all regions and various PGRs, when the payload remained at 60 KB or below, the PLR consistently measured at 0. However, PLR started to manifest when the payload exceeded 80 KB. The outcomes are visually depicted in Figure 11. Notably, Frankfurt, which exhibited the highest network latency, initiated the generation of PLR at a PGR of 3 Hz, while California exhibited this occurrence at 5 Hz. In comparison, in the Seoul region, the PLR was observed from a PGR of 20 Hz.

The trends observed in Figure 12 reveal that PLR did not experience continuous escalation in tandem with the augmentation of PGR. Instead, it reached a point of convergence at a certain level. Upon closer examination of the sequence of lost packets, it was noted that the majority of losses transpired within the messages published before the 20th.

The test results have confirmed that for services necessitating a response time within the realm of several hundred milliseconds, optimal quality can only be sustained when the service operates within a cloud located in the same region. Furthermore, it has been observed that there is a potential for packet loss when reconnecting with the IoT Core in the cloud, particularly when the payload surpasses 60 KB and the Packet Generation Rate (PGR) is considered. Hence, for services that are particularly susceptible to packet loss, it is advisable to structure these services within the same region to mitigate the risk of packet loss. Alternatively, if there are no traffic restrictions, utilizing QoS1 can also be a suitable approach to ensure data integrity.

As the maritime industry incorporates more high-precision control components like LNG gas systems, electric propulsion, and generators, the demand for cloud-based services facilitating interaction with these elements is set to rise, especially with the progressive advancement of autonomous ships. Constructing a multi-region Fog Cloud-based platform presents a solution to ensure ships maintain the necessary connectivity for these services, even as they traverse the globe. The insights gleaned from the aforementioned tests will serve as valuable information to be taken into account when designing services within these platforms, considering potential constraints and optimizing performance.

4.3. Error Rate Variation Based on the Number of Subscribed Ships

In this study, we propose the utilization of ship data obtained through a platform for effective collision avoidance by recognizing nearby ships via AIS and subscribing to their data. However, maritime satellite communication involves costs correlated with traffic volume, and packet loss can potentially lead to safety incidents. Thus, it is crucial to maintain appropriate traffic levels to prevent packet loss. The comprehensive error probability, combining the error probability derived from the probability model introduced in Section 3.2.3 and the experimentally measured values detailed in Section 4.2, is defined as follows:

$$P\left(L\right)={\sum }_{k}P\left(L\right|K=k)·P(K=k)$$

(6)

• $P\left(L|K=k\right)$: Packet loss probability at message generation rate
• $P(K=k)$: Probability of generating k messages

Figure 13 illustrates the packet loss rate distribution measured by region based on the Poisson distribution and 80 KB payload when there are 10, 50, and 100 subscribed nearby ships. The number of packet losses increases with the number of packets per second, but then stabilizes at a certain number, causing the packet loss rate to decrease with k. Figure 14 depicts the calculation results of $P\left(L\right)$ for each region according to the number of ships using this data.

In other regions, when the number of ships is 50 or 100, the distribution of the number of packets k received overlaps with the section where packet loss occurs, resulting in a higher probability of packet loss than in the same region. In an environment with 100 ships, the packet loss rates in the California and Frankfurt regions were approximately 5 and 27 times higher, respectively, than in the same region. These findings affirm that by connecting to the cloud in the same region, the number of ships that can subscribe with a low packet loss rate can be significantly increased in areas with high ship density.

5. Conclusions and Future Work

Global trade heavily relies on large ships that navigate oceans, overseen by shipping companies spanning the globe. The ever-increasing adoption of ship IoT devices poses a significant challenge for improving service quality within the limitations of the traditional single cloud architecture. Hence, embracing the Fog computing paradigm becomes a necessity. While ongoing research endeavors explore the application of Fog computing in the maritime sector, the fusion with ship automation systems aboard these sizable vessels remains an underexplored frontier.

In alignment with these considerations, this paper introduces a data platform, intricately linked with ship automation systems. Taking into account the unique movement characteristics of ships, the design envisages the establishment of multiple Fog Clouds worldwide. Ships are envisioned to establish connections with the Fog Clouds in regions with minimal latency. This connection methodology proposes efficient sharing of planned voyage data among ships within the proposed platform structure. Current research on ship collision avoidance primarily hinges on enhancing performance through current navigation data. However, this paper posits the possibility of further improving collision avoidance performance by sharing planned data. Nevertheless, it is crucial to acknowledge that this data sharing amplifies traffic. In areas with dense ship concentrations, the traffic per unit time increases, consequently elevating the probability of packet loss.

To evaluate this packet loss probability, this paper models the number of received messages per unit time using a Poisson distribution based on the number of nearby subscribed ships. Additionally, by combining the packet loss rate measured through AWS Cloud and comparing the results with communication in other regions in the existing single cloud architecture and the same region in the proposed structure, this study sheds light on the outcomes when there are 100 ships. Notably, the probability of packet loss was approximately 28 times higher for communication within the other region than within the same region. This method of calculating packet loss probability offers a means to effectively manage the number of subscribing ships, mitigating the risk of packet loss through the subscription ship management approach proposed in this paper.

The implementation of the proposed platform structure and the assessment of multi-region cloud network advantages were facilitated through AWS Cloud. The design encompassed a comprehensive architecture implemented on AWS Cloud, featuring the IoT Core in regions such as Seoul, California, and Frankfurt for measuring RTT-based latency and PLR. The results indicate that RTT differences vary based on payload size, with Seoul consistently achieving the lowest values at 0.072 to 0.175 s. Packet loss predominantly emerged at the outset of the connection, manifesting around 10 to 20 Hz within the same region and 3 to 5 Hz in other regions.

Lastly, the practical verification of function development and distribution performance on the platform was demonstrated through the creation of a ship operation monitoring web service. Functions were innovatively developed and disseminated via binary serverless computing code and docker images, effectively showcasing ship-collected data through the Edge Server on the web interface.

In this study, we have laid a strong foundation for future research endeavors and potential advancements in the field of maritime IoT and cloud computing. Several promising avenues for future exploration have emerged from our findings:

• Collision Avoidance for Non-Information-Receiving Objects: Leveraging the Fog Cloud structure, we envisage enabling even objects that do not receive direct information to actively participate in collision avoidance by recognizing and responding to surrounding vessels. Our future research will delve into these methods and their performance to fortify the fog cloud structure in the maritime domain.
• Application of Fog Cloud Across Diverse Services: By harnessing the proposed Fog Cloud structure, our plan includes enhancing the performance of various applications in the maritime sector. These applications encompass weather-informed route optimization, Operation Train Simulator, carbon emission reduction, and more.
• Expanding Platform Scalability and Flexibility: As the number of ships, services, and data points grow, it is vital to ensure that the platform remains scalable and adaptable. Future research can focus on refining the platform’s architecture to accommodate an expanding userbase seamlessly.

In conclusion, our study provides a solid basis for future research to tackle these exciting challenges and explore innovative solutions that can reshape the maritime industry, making it safer, more efficient, and technologically advanced.