Next Article in Journal
Rain Discrimination with Machine Learning Classifiers for Opportunistic Rain Detection System Using Satellite Micro-Wave Links
Next Article in Special Issue
A Multimodal IoT-Based Locomotion Classification System Using Features Engineering and Recursive Neural Network
Previous Article in Journal
A Novel Scalable Reconfiguration Model for the Postdisaster Network Connectivity of Resilient Power Distribution Systems
Previous Article in Special Issue
Robust Precoding for Multi-User Visible Light Communications with Quantized Channel Information
 
 
Font Type:
Arial Georgia Verdana
Font Size:
Aa Aa Aa
Line Spacing:
Column Width:
Background:
Article

Design and Experiment of Satellite-Terrestrial Integrated Gateway with Dynamic Traffic Steering Capabilities for Maritime Communication

1
Department of Computer Engineering, Graduate School of Gachon University, 1342 Seongnamdaero, Sujeong-gu, Seongnam 13120, Republic of Korea
2
SyncTechno Inc., Rm 914/918, 311 Gangnamdaero, Seocho-gu, Seoul 06628, Republic of Korea
*
Author to whom correspondence should be addressed.
Sensors 2023, 23(3), 1201; https://doi.org/10.3390/s23031201
Submission received: 14 December 2022 / Revised: 12 January 2023 / Accepted: 16 January 2023 / Published: 20 January 2023

Abstract

:
This study presents the architectural design and implementation of a multi-RAT gateway (MRGW) supporting dual satellite and terrestrial connectivity that enables moving maritime vessels, such as autonomous surface ships, to be connected to multiple radio access networks in the maritime communication environment. We developed an MRGW combining LTE and very-small-aperture terminal (VSAT) access networks to realize access traffic steering, switching, and splitting functionalities between them. In addition, we developed communication interfaces between the MRGW and end-devices connecting to their corresponding radio access networks, as well as between the MRGW and the digital bridge system of an autonomous surface ship, enabling the MRGW to collect wireless channel information from each RAT end-device and provide the collected data to the digital bridge system to determine the optimal navigation route for the autonomous surface ship. Experiments on the MRGW with LTE and VSAT end-devices are conducted at sea near Ulsan city and the Kumsan satellite service center in Korea. Through validation experiments on a real maritime communication testbed, we demonstrate the feasibility of future maritime communication technologies capable of providing the minimum performance necessary for autonomous surface ships or digitized aids to navigation (A to N) systems.

1. Introduction

Maritime communications using maritime frequency bands within the very high frequency (VHF) spectrum became the most widely-used communication system for vessels after Marconi’s success in transatlantic communications with a transmission distance of over 3000 km in 1901 [1]. Currently, commercial maritime communication uses cellular communication based on LTE or 5G technology for vessels along the coast, where vessels are within the coverage of the cellular network. This is also applicable to onboard communication on luxury cruise ships or state-of-the-art ships such as small-size electric ships or autonomous surface ships [2].
Traditional maritime communication technologies may coexist with state-of-the-art technologies under two conditions: the long life expectancy of ships, which is usually >20 or 30 years, and the difference in countrywide communication infrastructures, which requires ships to be equipped with multiple communication interfaces for access networks permitted by a country whose ships visit during their navigation [3,4,5]. In addition, the international maritime organization (IMO) has recently completed a regulatory scoping exercise on Maritime Autonomous Surface Ships (MASS) [6]. The International Association of Marine Aids to Navigation and Lighthouse Authorities (IALA) is developing guidelines for the future development of maritime radio communication, including IMT-2020, which is applicable to their digital transformation, such as autonomous surface ships [7,8]. Since the maritime sector was included in the standardization scope of 3rd Generation Partnership Project (3GPP) in December 2018, use cases and requirements related to the maritime sector have been considered in addition to other use cases and requirements from several vertical industries [9,10,11,12].
In such a maritime communication environment with heterogeneous communication technologies, the support of multiple radio access technologies (multi-RATs) is essential from the perspective of the upcoming digital transformation era in the maritime sector [13,14,15,16,17,18]. There are research works on the support of multi-RAT including LTE and Wi-Fi in terrestrial environments (e.g., in ultra-dense urban area, in smart cities, in vehicular or air-to-ground communications), but their outcomes were mainly based on the simulations and did not provide results based on the real experimental validation with the implemented equipment [19,20,21,22,23].
In this study, we design and implement a multi-RAT gateway (MRGW) with the capabilities of steering, switching, and splitting the access traffic, and provide experimental validation of the proposed MRGW prototype connected to LTE/VAT end-devices in the testbed of the Korean autonomous surface ship (KASS) at sea, near Ulsan city and the Kumsan satellite service center, Republic of Korea.
The key contributions of this study are summarized as follows:
  • This study contributes to the literature by proposing the design of an overall system model applicable for the maritime communication environment where an autonomous surface ship can exchange information with an on-land control center through an MRGW that enables intelligent routing among multi-RATs.
  • Another contribution is the proposition of a detailed design of an MRGW with several key features adopted from open-source software and newly developed to monitor the radio channel status of each RAT end-device.
  • Finally, this study demonstrates that the MRGW can enable the interworking between two heterogeneous RAT end-devices and support real-time video streaming through experiments on a real maritime testbed in three test scenarios.
This paper is organized as follows. Section 2 describe the related works and Section 3 introduces the overall multi-RAT supporting communication system model applicable to the maritime communication environment where autonomous surface ships exchange information with an on-land control center and neighboring ships or digital transform aids to navigation equipment using multi-RATs. Section 4 describes the design of the MRGW with an interface for each RAT end-device. Section 5 describes the system configurations for the field test environment and three test deployment scenarios, each of which comprises four or five steps for the experiment execution process. Section 6 analyzes the experimental outcome on the basis of test results. Finally, the conclusions and future research directions are discussed in Section 6.

2. Related Works

For the modernization of maritime communications, the transition to digital technologies has begun in the maritime sector and the existing systems are being enhanced and new technologies continue to emerge [4]. The VHF data exchange system (VDES) and Navigational Data (NAVDAT) were developed as maritime communication systems supporting the e-navigation concept and the modernization of the Global Maritime Distress and Safety System (GMDSS) [24,25,26].
The maritime autonomous surface ship (MASS) is also one of the main research streams for the digital transformation of the maritime sector [27,28,29] and there are ongoing works to enable advanced communication technologies including satellites, Unmanned Aerial Vehicles (UAVs), and IMT systems (e.g., 5G, 6G) with improved coverage and data rates to be applied for the MASS [30,31,32,33,34].
Satellite communication has been widely employed in the maritime sector because of the communication coverage and the accessible network infrastructure in the ocean, and traditionally provides limited applications due to the long propagation delay and affordable data rate. However, the recent technological advancement is ongoing for the integration of satellites into the 5G or 6G networks [35,36,37,38].
The support of the multi-RATs is one of the key requirements of several vertical industries, including the maritime sector, because of the heterogeneous networks. The multi-connectivity combining different access technologies (e.g., cellular, satellite, Wi-Fi) continue to be enhanced for seamless connection in diverse service scenarios over 5G or 6G systems [39,40,41,42].

3. System Model

Our system model for the maritime communication environment is depicted in Figure 1. It enables an autonomous surface ship to exchange the information with an on-land control center via external communication systems accessible from a ship near the shore or at sea.
A commercial satellite access network (e.g., very-small-aperture terminal (VSAT) system) and a cellular access network (e.g., LTE system) are assumed to be accessible by each subscribed RAT end-device connected to the MRGW. In addition, the digital twin bridge of the on-land control center communicates with the digital bridge of the autonomous surface ship through the commercial satellite or cellular access network. This communication channel can be established through public Internet or a closed network (e.g., 5G private network) if available commercially or proprietarily deployed near a shore or at port.
The MRGW handles the acquisition of wireless channel information from each RAT end-device and the periodic provision of that information to the digital bridge. It provides the digital bridge of the autonomous surface ship with information about the best RAT at the current location that an autonomous surface ship is navigating. The MRGW provides two types of interfaces:
  • An interface between the digital bridge and the MRGW to provide the wireless channel status measurement of each RAT end-device to the digital bridge, and to enable the MRGW to obtain the navigation information of the autonomous ship managed by the digital bridge;
  • An interface between the MRGW and each RAT end-device, which depends on the communication protocol supported by each RAT end-device.
As 5G-Advanced or 6G communication systems are expected to provide seamless connection anywhere (e.g., in either the maritime or terrestrial sector), with the support of multi-RATs, the current commercial communication networks will evolve accordingly [43,44,45]. Therefore, the MRGW is designed to be capable of providing interfaces to future RAT end-devices of evolved communication networks for its sustainability in the maritime communication environment where various types of ships exist (e.g., traditional ships with legacy radio communication systems such as VHF systems and autonomous surface ships with state-of-the-art radio communication systems such as 5G–Advanced or 6G system). The cyber security is assumed to be guaranteed by the firewall and VPN, etc., for the on-board communication as well as ship-to-shore communication.
This study focuses on the design of an MRGW supporting flexible and scalable interfaces with RAT end-devices using commercial communication networks (e.g., VSAT system or LTE system) and the public Internet.

4. Design of an MRGW

4.1. Functional Architecture

An MRGW architecture consisting of a hardware system, an operating system and the MRGW platform is functionally designed, as shown in Figure 2. The open source Unix-like operating system, known as FreeBSD, provides various networking features [46]. For instance, a routing table is dynamically configurable using the MRGW platform through the template of the routing configuration. The MRGW platform implemented on top of the open source software supports the provision of basic networking services and the addition of any user-defined functionality as a plugin.
To support multi-RATs, two functionalities are realized at the MRGW platform. The first functionality is the wireless channel monitoring, developed as a plugin added to the operating system, consisting of following functional components:
  • Status information collector of the wireless channel;
  • Status information controller;
  • Application programming interfaces (APIs) for interworking with third-party applications.
The second functionality is the routing functionality developed to support multi-RATs and the optimal routing selection among accessible RATs, consisting of the following functional components:
  • User interface APIs (UI APIs) for MRGW control;
  • Routing configuration controller.
In addition, a human machine interface (HMI) controller is developed for the display control in the MRGW hardware system. In addition, APIs for the interworking with third-party applications and UI APIs for MRGW control are developed, through which third-party applications (e.g., the user interface of the digital bridge of the autonomous surface ship) can control the MRGW to provide the wireless channel information of each RAT end-device and select the optimal RAT among the accessible RATs.

4.1.1. MRGW APIs

MRGW APIs provide programmable interfaces for accessing and controlling the MRGW to users and third-party applications. In addition to the various APIs provided by the open source software, the UI APIs for MRGW-control, based on the web interface and interworking APIs for external third-party applications, are provided. The overall API structure for the MRGW access and control is depicted in Figure 3 and is classified into two parts: APIs provided by the open source software and APIs developed as plugins.

4.1.2. Wireless Channel Monitoring Functionality

The wireless channel monitoring functionality is realized by two functional components; namely, the wireless channel status information collector and the status information controller in the MRGW platform, as depicted in Figure 2. Accordingly, the wireless channel status information is collected from each RAT end-device and the collected information is provided to other functional components, such as the routing configuration controller or a third-party application (e.g., digital bridge UI), as shown in Figure 2. The interfaces between the MRGW and each RAT end-device are illustrated in Figure 4. The representational state transfer (REST) API and simple network management protocol (SNMP) are used for exchanging the control data between the MRGW and an LTE end-device, as well as between the MRGW and a VSAT end-device, respectively.

4.1.3. Routing Functionality

The MRGW platform adopts routing functionalities supported by the FreeBSD operating system. In addition to those routing functionalities supported by the open source software, the routing configuration controller is implemented as a functional component with several features, such as traffic shaping and traffic steering operations, as shown in Figure 5, to manage user data traffic.
The routing configuration controller receives the wireless channel status information of each RAT and processes this information to select the optimal RAT in the maritime communication environment. The data analysis result provided by the routing configuration controller is delivered to the UI APIs for MRGW control. Furthermore, the basic routing functionality supported by the FreeBSD operating system can be controlled on the MRGW platform by updating the routing configuration information of the FreeBSD operating system through the routing configuration controller’s routing configuration template.

4.2. Environment for System Design Verification

The system design for the verification of the MRGW is depicted in Figure 6. The MRGW’s operation and performance are verified using the DX Ocean™, remote monitoring software, and packet capturing software.
To verify the MRGW’s operation and performance, a remote monitoring procedure is implemented using the DX Ocean ™, which enables the information collected from, or created by, the MRGW (e.g., wireless channel status information measured from each RAT end-device or MRGW status information) to be stored in the onboard system as well as a Cloud-based on-land data hub when the communication network is connected between an autonomous surface ship and on-land systems. According to the service flow for remote monitoring, shown in Figure 6, the operation and performance of the MRGW and each RAT end-device can be verified through the visualized data using the remote monitoring software.
To verify the data transmission and reception between the digital bridge of the autonomous surface ship and the digital twin bridge of the on-land control center, the packet capture software sniffs the data exchanged between the digital bridge of the autonomous surface ship and the digital twin bridge of the on-land control center. The packet capture software executes always-on sniffing packets which continuously forward to the DX Ocean™ (Cloud-based on-land data hub). In cases of the stored data being transmitted from the DX Ocean™ (onboard equipment), 30 s is configured as the period of the data transmission from the DX ocean™ (onboard equipment) to the DX ocean™ (Cloud-based on-land data hub). According to the service flow for data verification, shown in Figure 6, whether all of the packets are received is determined by comparing the number of transmitted packets and received (sniffed) packets, and it is also possible to determine whether the MRGW enables the data to be exchanged between the digital bridge and the digital twin bridge using the remote monitoring software, which compares the well-known training data sent from the digital bridge and the sniffed data received by the digital twin bridge for data verification.

5. Experimental Validation

5.1. Field Experiment Configuration

A field experiment was conducted to verify the operation and performance of the MRGW connected with an LTE end-device and an LTE device for testing in terms of traffic steering between different RATs in the testbed of the autonomous surface ship, known as KASS, plying along the navigation route next to the JangSaengPo port in Ulsan, Korea, as depicted in Figure 7.
Another field experiment was conducted to verify the operation and performance of the MRGW connected with a VSAT end-device and an LTE end-device in terms of the latency between the different RATs at the KTSAT Kumsan satellite service center in Kumsan, Republic of Korea, as shown in Figure 8 [47]. The VSAT end-device is connected to Republic of Koreasat–6, which is a geostationary satellite operated by KTSAT, with an orbit height of 35,786 km. There is a limitation on the available bandwidth (i.e., 1 Mbps) due to the high cost of the satellite service during the field experiment, so the main purpose of the field experiment is to check the operation of the MRGW and the latency of the satellite communication link.
For the field experiment, an LTE end-device developed using the LTE and Nvidia Jetson Nano modules is used to enable the MRGW to extract wireless channel status information (e.g., Reference Signal Received Power (RSRP) and Reference Signal Received Quality (RSRQ)) from the LTE end-device. Figure 9 shows the specification of the LTE module and the main board of the LTE end-device.

5.2. Test Scenarios and Experiment Outcome Analysis

Three system configurations are considered to test the operation and performance of the MRGW. For the experimental validation, the expected potential operation errors or the breakdown of the MRGW are considered when each experiment execution process for three test scenarios is developed to enable such errors to be identifiable during the experiment by several methods (e.g., testing tools with ping or iperf to identify a hardware malfunction or a configuration error, testing with the DX Ocean™ for the data integrity check). The overall system configuration and experiment outcome analysis for the three test scenarios are provided in following subsections.

5.2.1. Test Scenario 1 for Testing the Switchover Performance of MRGW

Test scenario 1 for testing the switchover performance of the MRGW is to determine whether the MRGW can switch from an active RAT end-device to another standby RAT end-device within 1 s once it detects that the active RAT end-device is disconnected.
The overall system configuration for test scenario 1, described in Figure 10, shows the allocated IP addresses used for the validation experiment. The data used for the test scenario are ICMP (Ping) messages generated at PC #1 every second and a public DNS address (i.e., Google public DNS: 8.8.8.8) used as the targeted IP address of the ICMP message.
The switchover performance of the MRGW is verified by performing the following experiment execution processes.
Step 1:
The active-standby mode, shown in Figure 5, is configured through the MRGW, and the two RAT end-devices connected to the MRGW are the LTE end-device (ISP#1) and LTE end-device for testing (ISP#2).
Step 2:
PC #1 executes the ping program to generate an ICMP message, which is sent to the public DNS address (8.8.8.8), and the information containing the start time of the transmission of the ICMP message is identified on the screen of PC #1 by the software that records the time when the ICMP messages are transmitted (Figure 11a).
Step 3:
The power of the LTE end-device (ISP#1) is turned off to create a field experimental environment, where the LTE end-device (ISP#1) is disconnected.
Step 4:
The start time of the transmission of the ICMP messages is recorded and identified on the screen of PC #1 once the connection is re-established through the LTE device for testing (ISP#2), instead of the inaccessible LTE end-device (ISP#1) (Figure 11b).
Step 5:
The time when the ‘GATEWAY ALARM’ is generated is recorded. This time is identified from the system/gateway/logfile of the user interface for MRGW control, shown in Figure 2 (192.168.1.1) (Figure 11c).
Figure 11. Experiment outcome of test scenario 1–(a) Screenshot related to Step 2 of the experimental execution process; (b) Screenshot related to Step 4 of the experimental execution process; (c) Time value identified from the configuration menu of the MRGW when ‘GATEWAY ALARM occurs because of the disconnection of LTE end-device (ISP#1).
Figure 11. Experiment outcome of test scenario 1–(a) Screenshot related to Step 2 of the experimental execution process; (b) Screenshot related to Step 4 of the experimental execution process; (c) Time value identified from the configuration menu of the MRGW when ‘GATEWAY ALARM occurs because of the disconnection of LTE end-device (ISP#1).
Sensors 23 01201 g011aSensors 23 01201 g011b
The outcome of the experiment to evaluate the switchover performance of MRGW is presented in Figure 11. The time is printed every time an ICMP message is sent, and Figure 11a shows the examples of the times (blue dotted lines) that were printed every time an ICMP message was sent via the LTE end-device (ISP#1). As soon as the ISP#1 (LTE) end device is disconnected, the MRGW conducts the switchover from the ISP#1 (LTE) end device to the LTE device for testing (ISP#2). Once the MRGW is connected with the LTE device for testing (ISP#2), the time for the successfully sent ICMP message starts to be printed and the first time of an ICMP message sent via the LTE device for testing (ISP#2) is 36 s 36 min 15 h on 29 August 2022, as shown in Figure 11b. The time at which the LTE end-device (ISP#1) is disconnected can be identified only from the user interface for the control of the MRGW by the unit of the second. The time of the disconnection from the LTE end-device (ISP#1) is 35 s 36 min 15 h on 29 August 2022, identified as 2022–08-29T15:36:35, from the user interface for the MRGW control, as shown in Figure 11c. As the MRGW lost the connection from the LTE end-device (ISP#1) at 35 s 36 min 15 h and the MRGW was again connected to the LTE device for testing (ISP#2) at 36 s 36 min 15 h, we verified that the MRGW successfully switched the connection from the LTE end-device (ISP#1) to the LTE device for testing (ISP#2) within 1 s.

5.2.2. Test Scenario 2 for Evaluating the Support for Real-Time Video Streaming Data Provided by MRGW Operation

Test scenario 2 for evaluating the support for the real-time video streaming data provided by the MRGW’s operation is to determine whether the MRGW can establish a connection with an accessible targeted RAT end-device and transmit and receive real-time video streams through the web-RTC server (Janus).
The overall system configuration for test scenario 2, illustrated in Figure 12, shows the allocated IP addresses used for the experimental validation. The Chrome browser is used to access the video room application of the Web-RTC server (Janus) at PC #1 with a camera, and PC #2 with a camera and real-time video streaming data produced from the camera are sent out and received by PC #1 and PC #2, respectively, via the Web-RTC server (Janus).
The MRGW’s operation for supporting real-time video streaming data is verified by performing the following experiment execution processes.
Step 1:
The active-standby mode, shown in Figure 5, is configured using the MRGW, and the two RAT end-devices connected to the MRGW are the LTE end-device (ISP#1) and the LTE device for testing (ISP#2) for the interworking test.
Step 2:
PC #1 accesses the Web-RTC server (Janus) through the Chrome browser and activates the camera and microphone to produce real-time video streaming.
Step 3:
PC #2 accesses the Web-RTC server (Janus) through the Chrome browser and activates the camera and microphone to produce real-time video streaming.
Step 4:
PC #1 and PC #2 determine whether the real-time video streaming produced from the activated camera and microphone is displayed through the video room of the Web-RTC server (Janus) with no service interruption.
The outcome of the experiment for evaluating the MRGW’s operation for supporting real-time video streaming data is depicted in Figure 13, which includes two video streaming images of the video room application of the Web-RTC server (Janus). The left image is captured from the camera of PC #1 and the right one is captured from the camera of PC #2. They are displayed from the video room of the Web-RTC server (Janus) at PC #1 because the MRGW successfully exchanges the video streaming data via the LTE end-device (ISP#1). Based on the experiment outcome, we verified that the MRGW successfully ensured that the real-time video streaming was provided through the Web-RTC server (Janus).

5.2.3. Test Scenario 3 for Evaluating the Operation of MRGW in Interworking with the DX Ocean™

Test scenario 3 for evaluating the operation of the MRGW in interworking with the DX Ocean™ is to determine whether the MRGW interworks with the DX Ocean™; the information collected by the DX Ocean™ (onboard equipment) deployed in the KASS is sent out and delivered to the DX Ocean™ (Cloud-based on-land data hub) through the MRGW and each RAT end-device.
The overall system configuration for test scenario 3, illustrated in Figure 14, shows the allocated IP addresses used for the experimental validation. The API related to the wireless channel status information collector, shown in Figure 2, is assumed to be identified and the DX Ocean™ software is installed and executed at PC #1.
The operation of the MRGW in interworking with the DX Ocean™ is verified by performing the following experiment execution processes.
Step 1:
The active-standby mode, shown in Figure 5, is configured using the MRGW, and the two RAT end-devices connected to the MRGW are the LTE end-device (ISP#1) and the LTE device for testing (ISP#2) for the interworking test.
Step 2:
The information related to the configuration of the MRGW is identified from the menu of the user interface for MRGW control, depicted in Figure 2.
Step 3:
The DX Ocean™ software at PC #1 stores the information collected from the API related to the wireless channel status information collector, shown in Figure 2, and the information regarding a ship’s location obtained from the positioning system deployed in the ship.
Step 4:
The information stored in the DX Ocean™ (onboard equipment) is transmitted to the DX Ocean™ (cloud-based on-land data hub) through the MRGW via either the LTE end-device (ISP#1), if accessible, or the LTE device for testing (ISP#2), if accessible.
The experiment outcome for test scenario 3 is shown in Figure 15. As shown in Figure 15a, the DX ocean™ shows the ship location based on the GPS information which the MRGW obtains from the LTE end-device (ISP#1) and subsequently sends it to the DX Ocean™ (onboard equipment). The DX Ocean™ (onboard equipment) sends the stored data out to the DX Ocean™ (cloud-based on-land data hub) every 30 s. The period of the data sent out from the DX Ocean™ (onboard equipment) to the DX Ocean™ (cloud-based on-land data hub) is configurable. Figure 15b is the sample of collected data related to the wireless channel status information from the MRGW. Based on the experiment outcome, we found that the information collected from the MRGW is successfully stored in the DX Ocean™ (onboard equipment and cloud-based on-land data hub).

5.3. Experimental Outcome of Wireless Performance

The wireless performance of the LTE end-device is shown in Figure 16. The real navigation route was revised compared to the planned navigation route because of the wave direction due to the worse weather condition at sea for the reduction in the safety risk during the testing. In terms of the RSRP, 68.86% of the total navigation route shows values ≥ –100 dBm. In terms of the downlink throughput, 92% of the total navigation route shows values ≥ 0.6 Mbps. In terms of the uplink throughput, 85% of the total navigation route shows values ≥ 1 Mbps. In terms of the latency, 98% of the total navigation route shows values ≤ 200 ms.
The wireless performance of the LTE end-device was inferior compared to that of the wireless performance of the LTE end-devices in urban areas. However, the performance may have been hampered by the operator policy in terms of the difference in network operation between urban and maritime/rural areas.
The round trip time measured from the VSAT end-device is shown in Figure 17. The worst case round trip time propagation delay of a GEO satellite with transparent payload is 541.46 ms [48], but the measured round trip time of the satellite was more than 610 ms during the testing at the KTSAT Kumsan satellite service center in Kumsan, Republic of Korea.
An additional experiment was performed using the fishing boat in front of the Jeongok Port at the west sea of Republic of Korea and the MRGW collected the wireless channel status information (i.e., RSRP, RSRQ, GPS information) measured from the LTE end-device. The wireless performance measured from the LTE end-device is shown in Figure 18. As shown in Figure 18a, the navigation route is identically selected for the shore-to-sea direction and the sea-to-shore direction to have the effect of the repeated experiments. The weather condition was good, and it was a sunny day, which means that waves did not cause any impact to degrade the wireless performance at sea. As shown in Figure 18b, two of the graphs (i.e., (1–1) and (2–1)) have a similar RSRP pattern and another two graphs (i.e., (1–2) and (2–2)) also have a similar RSRQ pattern. Based on the experiment outcome, we can assume that little change occurs to the wireless channel status in cases of a sunny day, which means that our experimental validation may be meaningful despite the limited number of the experiments.

6. Conclusions

Herein, we proposed a design for a novel MRGW and conducted corresponding experiments to verify the operation and performance of the MRGW based on three test scenarios with different system configurations. The experiment outcomes indicate that the MRGW has the capability of providing the seamless connection for an autonomous surface ship through multiple RAT end-devices in the maritime communication environment. Based on the MRGW’s capability, proven by the experimental validation in the real maritime communication environment, it is important to continue to enhance the MRGW to support new upcoming end-devices (e.g., 5G end-device supporting both cellular access and satellite access) based on more evolved RATs, such as 5G-Advanced and 6G. Our research is expected to be continuously carried out during the second step of the KASS project [49], from the year 2023 to the year 2025, to enhance the functions of the MRGW and address any abnormal potential errors by applying assurance framework, such as a FMECA (Failure modes, effects, and criticality analysis) mechanism, and performing more experimental validations for three years in the testbed of autonomous surface ships in Ulsan, Republic of Korea. IMT-based technologies continue to be evolved to support the requirements of the vertical industries, including the maritime sector. The service requirements related to the digital transformation of the maritime sector, including the autonomous surface ship, are important to be provided during the global standardization of 5G-Advanced and beyond in 3GPP. Subsequent future works, as well as the research outcome of this paper, are expected to be leveraged to identify the gap analysis of existing commercial communication technologies and develop maritime requirements that should be satisfied by 5G or 6G systems that are possible to be employed as the fundamental communication platform for the digitalization and mobilization of the maritime sector.
In the near future, an end-device with both satellite and cellular access (e.g., 5G or LTE) is expected to be launched in markets as a 5G satellite was first specified to be integrated into 5G systems in 3GPP specifications in March 2022. However, further research is needed to enhance the capabilities of the current 5G satellite, particularly in terms of support for low earth orbit satellites, which are always in motion, not stationary. New opportunities and challenges for improving the MRGW can be found in research areas related to the support of multiple radio accesses, including low earth orbit satellites integrated into the 5G system.
The digital bridge system controlling the navigation of an autonomous surface ship and its counterpart on-land control center are to be deployed and operated 24/7/365 in the near future and the quantity of data is expected to increase rapidly. The data generated for the experimental verification are not the same as the data expected to be generated during the real operation of the digital bridge of the autonomous surface ship and the on-land control center. Additional research on the enhancement of the MRGW needs to be conducted to address how to flexibly manage the uplink and downlink bandwidth because the bandwidth allocated for the uplink transmission is generally lower than that of the downlink transmission in commercial cellular networks.

Author Contributions

Concept design, H.K. and J.C.; formal analysis, H.K. and W.K.; investigation, H.K. and J.C.; writing–original draft preparation, H.K.; writing–review and editing, H.K. and W.K.; visualization, H.K.; supervision, W.K.; project administration, H.K. All authors have read and agreed to the published version of the manuscript.

Funding

This research was funded by the Ministry of Oceans and Fisheries (MOF, Republic of Korea) grant number 20200615.

Institutional Review Board Statement

Not applicable.

Informed Consent Statement

Not applicable.

Data Availability Statement

Not applicable.

Acknowledgments

This research was supported by the “Development of Autonomous Ship Technology (20200615)” funded by the Ministry of Oceans and Fisheries (MOF, Republic of Korea).

Conflicts of Interest

The authors declare no conflict of interest.

References

  1. Marconi, G. Radio telegraphy. J. Am. Inst. Electr. Eng. 1922, 41, 561–570. [Google Scholar] [CrossRef]
  2. Mashino, J.; Tateishi, K.; Muraoka, K.; Kurita, D.; Suyama, S.; Kishiyama, Y. Maritime 5G experiment in windsurfing World Cup by using 28 GHz band massive MIMO. In Proceedings of the IEEE International Symposium on Personal, Indoor and Mobile Radio Communications, Bologna, Italy, 9–12 September 2018; pp. 1134–1135. [Google Scholar]
  3. Modern Maritime Communications, ITU WRS 2016. Available online: https://www.itu.int/dms_pub/itu-r/md/15/wrs16/sp/R15-WRS16-SP-0026!!PDF-E.pdf (accessed on 1 December 2022).
  4. Modern Maritime Communications, ITUWRS 2020. Available online: https://www.itu.int/en/ITU-R/seminars/wrs/2020/Plenary%20Sessions%20%20Presentations/03.%20Terrestrial%20Services%20-%201%20to%203%20Dec%202020/WRS20%20Modern%20Maritime%20Communications.pdf (accessed on 1 December 2022).
  5. International Convention for the Safety of Life at Sea (SOLAS). 1974. Available online: http://www.imo.org/About/Conventions/ListOfConventions/Pages/International-Convention-for-the-Safety-of-Life-at-Sea-(SOLAS),-1974.aspx (accessed on 1 December 2022).
  6. IMO. Outcome of the Regulatory Scoping Exercise for the Use of Maritime Autonomous Surface Ships (MASS). IMO MSC#103. May 2021. Available online: https://wwwcdn.imo.org/localresources/en/MediaCentre/PressBriefings/Documents/MSC.1-Circ.1638%20-%20Outcome%20Of%20The%20Regulatory%20Scoping%20ExerciseFor%20The%20Use%20Of%20Maritime%20Autonomous%20Surface%20Ships...%20(Secretariat).pdf (accessed on 1 December 2022).
  7. IALA. Maritime Radio Communications Manual (MARCOM MANUAL). IALA ENAV30-5.1.2.5.1. September 2022. Available online: https://www.iala-aism.org (accessed on 1 December 2022).
  8. IALA. Guideline on Developments and Implications of Maritime Autonomous Surface Ships for Coastal Authorities. IALA ENAV30- MTF04-8.1. September 2022. Available online: https://nextcloud.iala-aism.org/index.php/apps/files/?dir=/Committees/ENAV/ENAV30/WG2/Task%204.1.1_4.1.2_4.2.1-MASS&fileid=189934. (accessed on 1 December 2022).
  9. 3GPP TR 22.819 Feasibility Study on Maritime Communication Services over 3GPP System; Stage 1. Available online: https://www.3gpp.org/ftp//Specs/archive/22_series/22.819/22819-g20.zip (accessed on 1 December 2022).
  10. 3GPP Release 16 TS 22.119 Maritime Communication Services over 3GPP System; Stage 1. Available online: https://www.3gpp.org/ftp/Specs/archive/22_series/22.119/22119-h00.zip (accessed on 1 December 2022).
  11. Maritime Requirements on 3GPP Rel-18 RAN Studies/Works Priorities, 3GPP Liaison Person for IALA, 3GPP MRP Mini Workshop 23 June 2021. Available online: https://global5g.org/sites/default/files/07%20-%20Hyounhee%20KOO.pdf (accessed on 1 December 2022).
  12. 3GPP SP-210601, Maritime Requirements for Release 18, 3GPP Liaison Person for IALA, 3GPP SA Rel-18 Workshop 9-10 September 2021. Available online: https://www.3gpp.org/ftp/tsg_sa/TSG_SA/Workshops/2021-09-09_Rel-18_Workshop/Docs/SP-210601.zip (accessed on 1 December 2022).
  13. Chen, W.; Li, C.; Yu, J.; Zhang, J.; Chang, F. A survey of maritime communications: From the wireless channel measurements and modeling perspective. Reg. Stud. Mar. Sci. 2021, 48, 102031. [Google Scholar] [CrossRef]
  14. Guan, S.; Wang, J.; Jiang, C.; Duan, R.; Ren, Y.; Quek, T.Q.S. MagicNet: The Maritime Giant Cellular Network. IEEE Commun. Mag. 2021, 59, 117–123. [Google Scholar] [CrossRef]
  15. Yang, T.; Wang, R.; Cui, Z.; Dong, J.; Xia, M. Multi-attribute selection of maritime heterogeneous networks based on sdn and fog computing architecture. In Proceedings of the 16th International Symposium on Modeling and Optimization in Mobile, Ad Hoc, and Wireless Networks (WiOpt), Shanghai, China, 7–11 May 2018. [Google Scholar]
  16. Yang, T.; Chen, J.; Zhang, N. AI-Empowered Maritime Internet of Things: A Parallel-Network-Driven Approach. IEEE Netw. 2020, 34, 54–59. [Google Scholar] [CrossRef]
  17. Yang, T.; Li, J.; Feng, H.; Cheng, N.; Guan, W. A Novel Transmission Scheduling Based on Deep Reinforcement Learning in Software-Defined Maritime Communication Networks. IEEE Trans. Cogn. Commun. Netw. 2019, 5, 1155–1166. [Google Scholar] [CrossRef]
  18. Liu, C.; Lin, E.; Cai, L.; Huang, G. The Challenges and Key Technologies of Wireless Transmission and Mobile Networking in Near Maritime Environment. IOP Conf. Ser. Mater. Sci. Eng. 2018, 382, 052028. [Google Scholar] [CrossRef] [Green Version]
  19. Galinina, O.; Pyattaev, A.; Andreev, S.; Dohler, M.; Koucheryavy, Y. 5G multi-RAT LTE-WiFi ultra-dense small cells: Performance dynamics, architecture, and trends. IEEE J. Sel. Areas Commun. 2015, 33, 1224–1240. [Google Scholar] [CrossRef]
  20. Sepulcre, M.; Gozalvez, J. Heterogeneous V2V communications in multi-link and multi-RAT vehicular networks. IEEE Trans. Mob. Comput. 2021, 20, 162–173. [Google Scholar] [CrossRef] [Green Version]
  21. Sanchez-Iborra, R.; Santa, J.; Gallego-Madrid, J.; Covaci, S.; Skarmeta, A. Empowering the internet of vehicles with multi-RAT 5G network slicing. Sensors 2019, 14, 3107. [Google Scholar] [CrossRef] [Green Version]
  22. Xu, Y.; Gui, G.; Gacanin, H.; Adachi, F. A survey on resource allocation for 5G heterogeneous networks: Current research, future trends, and challenges. IEEE Commun. Surv. Tutor. 2021, 23, 668–695. [Google Scholar] [CrossRef]
  23. Qiu, J.; Grace, D.; Ding, G.; Zakaria, M.D.; Wu, Q. Air-ground heterogeneous networks for 5G and beyond via integrating high and low altitude platforms. IEEE Wirel. Commun. 2019, 26, 140–148. [Google Scholar] [CrossRef] [Green Version]
  24. Lázaro, F.; Raulefs, R.; Wang, W.; Clazzer, F.; Plass, S. VHF data exchange system (VDES): An enabling technology for maritime communications. CEAS Space J. 2018, 11, 55–63. [Google Scholar] [CrossRef] [Green Version]
  25. Bauk, S. Advances in Marine Navigation and Safety of Sea Transportation; CRC Press: Boca Raton, FL, USA, 2019. [Google Scholar]
  26. Melnyk, O.; Onishchenko, O.; Vasalatii, N.; Varlan, T. Introduction of modern marine technologies in ship navigation process. Grail Sci. 2022. [Google Scholar] [CrossRef]
  27. Alsos, O.; Hodne, P.; Skåden, O.; Porathe, T. Maritime autonomous surface ships: Automation transparency for nearby vessels. J. Phys. 2022, 2311, 012027. [Google Scholar] [CrossRef]
  28. Zhang, X.; Wang, C.; Jiang, L.; An, L.; Yang, R. Collision-avoidance navigation systems for maritime autonomous surface ships: A state of the art survey. Ocean. Eng. 2021, 235, 109380. [Google Scholar] [CrossRef]
  29. Peng, Z.; Wang, J.; Wang, D.; Han, Q. An overview of recent advances in coordinated control of multiple autonomous surface vehicles. IEEE Trans. Ind. Inform. 2021, 17, 732–745. [Google Scholar] [CrossRef]
  30. Wei, T.; Feng, W.; Chen, Y.; Wang, C.-X.; Ge, N.; Lu, J. Hybrid satellite-terrestrial communication networks for the maritime internet of things: Key technologies, opportunities, and challenges. IEEE Internet Things J. 2021, 8, 8910–8934. [Google Scholar] [CrossRef]
  31. Wang, J.; Zeng, C.; Ding, C.; Zhang, H.; Lin, M.; Wang, J. Unmanned surface vessel assisted maritime wireless communication toward 6G: Opportunities and challenges. IEEE Wirel. Commun. 2022, 29, 72–79. [Google Scholar] [CrossRef]
  32. Nomikos, N.; Gkonis, P.; Bithas, P.; Trakadas, P. A survey on UAV-aided maritime communications: Deployment considerations, applications, and future challenges. IEEE Open J. Commun. Soc. 2023, 4, 56–78. [Google Scholar] [CrossRef]
  33. Zeng, C.; Wang, J.; Ding, C.; Lin, M.; Wang, J. MIMO unmanned surface vessels enabled maritime wireless network coexisting with satellite network: Beamforming and trajectory design. IEEE Trans. Commun. 2022, 71, 83–100. [Google Scholar] [CrossRef]
  34. Guo, H.; Zhou, X.; Liu, J.; Zhang, Y. Vehicular intelligence in 6G: Networking, communications, and computing. Veh. Commun. 2022, 33, 100399. [Google Scholar] [CrossRef]
  35. Azari, M.M.; Solanki, S.; Chatzinotas, S.; Kodheli, O.; Sallouha, H.; Colpaert, A.; Montoya, J.F.M.; Pollin, S.; Haqiqatnejad, A.; Mostaani, A.; et al. Evolution of Non-Terrestrial Networks From 5G to 6G: A Survey. IEEE Commun. Surv. Tutorials 2022, 24, 2633–2672. [Google Scholar] [CrossRef]
  36. Giordani, M.; Zorzi, M. Non-Terrestrial Networks in the 6G Era: Challenges and Opportunities. IEEE Netw. 2020, 35, 244–251. [Google Scholar] [CrossRef]
  37. Rinaldi, F.; Maattanen, H.-L.; Torsner, J.; Pizzi, S.; Andreev, S.; Iera, A.; Koucheryavy, Y.; Araniti, G. Non-Terrestrial Networks in 5G & Beyond: A Survey. IEEE Access 2020, 8, 165178–165200. [Google Scholar] [CrossRef]
  38. Volk, F.; Schlichter, T.; Kaltenberger, F.; Heyn, T.; Casati, G.; Schwarz, R.T.; Knopp, A. Field Trial of a 5G Non-Terrestrial Network Using OpenAirInterface. IEEE Open J. Veh. Technol. 2022, 3, 243–250. [Google Scholar] [CrossRef]
  39. Sylla, T.; Mendiboure, L.; Maaloul, S.; Aniss, H.; Chalouf, M.A.; Delbruel, S. Multi-Connectivity for 5G Networks and Beyond: A Survey. Sensors 2022, 22, 7591. [Google Scholar] [CrossRef] [PubMed]
  40. Abdalla, A.S.; Upadhyaya, P.S.; Shah, V.K.; Marojevic, V. Toward Next Generation Open Radio Access Networks: What O-RAN Can and Cannot Do! IEEE Netw. 2022, 36, 206–213. [Google Scholar] [CrossRef]
  41. Zhao, Z.; Du, Q.; Wang, D.; Tang, X.; Song, H. Overview of Prospects for Service-Aware Radio Access towards 6G Networks. Electronics 2022, 11, 1262. [Google Scholar] [CrossRef]
  42. Zarin, N.; Agarwal, A. Hybrid Radio Resource Management for Time-Varying 5G Heterogeneous Wireless Access Network. IEEE Trans. Cogn. Commun. Netw. 2021, 7, 594–608. [Google Scholar] [CrossRef]
  43. Zhang, Y.; Long, B. A review of 5G-Advanced service and system aspects standardization in 3GPP. In Proceedings of the IEEE/CIC Inter-national Conference on Communications in China (ICCC Workshops), Foshan, China, 11–13 August 2022. [Google Scholar]
  44. Chen, W.; Montojo, J.; Lee, J.; Shafi, M.; Kim, Y. The Standardization of 5G-Advanced in 3GPP. IEEE Commun. Mag. 2022, 60, 98–104. [Google Scholar] [CrossRef]
  45. Guidotti, A.; Coralli, A.; Schena, V.; Chuberre, N.; Jaafari, M.; Puttonen, J.; Cioni, S. The path to 5G-Advanced and 6G non-terrestrial network systems. In Proceedings of the 2022 11th Advanced Satellite Multimedia Systems Conference and the 17th Signal Pro-cessing for Space Communications Workshop (ASMS/SPSC), Graz, Austria, 6–8 September 2022. [Google Scholar]
  46. FreeBSD. Available online: https://www.freebsd.org (accessed on 1 December 2022).
  47. Kumsan Satellite Service Center. Available online: https://www.ktsat.com/content/view.do?cttNm=facilities&cttNo=011 (accessed on 1 December 2022).
  48. 3GPP TR 38.821 Solutions for NR to Support Non-Terrestrial Networks (NTN). Available online: https://www.3gpp.org/ftp/Specs/archive/38_series/38.821/38821-g10.zip (accessed on 1 December 2022).
  49. Korea Autonomous Surface Ship (KASS) Project. Available online: www.kassproject.org (accessed on 1 December 2022).
Figure 1. System Model.
Figure 1. System Model.
Sensors 23 01201 g001
Figure 2. MRGW functional architecture.
Figure 2. MRGW functional architecture.
Sensors 23 01201 g002
Figure 3. API structure for MRGW access and control.
Figure 3. API structure for MRGW access and control.
Sensors 23 01201 g003
Figure 4. Interfaces between the MRGW and each RAT end-device.
Figure 4. Interfaces between the MRGW and each RAT end-device.
Sensors 23 01201 g004
Figure 5. An example of traffic steering operation on Active Standby (a) Active access available; (b) Active access unavailable.
Figure 5. An example of traffic steering operation on Active Standby (a) Active access available; (b) Active access unavailable.
Sensors 23 01201 g005
Figure 6. System design for verifying the MRGW’s operation and performance.
Figure 6. System design for verifying the MRGW’s operation and performance.
Sensors 23 01201 g006
Figure 7. Experimental environment for testing MRGW and LTE end-device in the testbed of KASS at Jangsaengpo port in Ulsan, Republic of Korea.
Figure 7. Experimental environment for testing MRGW and LTE end-device in the testbed of KASS at Jangsaengpo port in Ulsan, Republic of Korea.
Sensors 23 01201 g007
Figure 8. Experimental environment of MRGW interworking between LTE end-device and VSAT end-device at the KTSAT Kumsan satellite service center, in Kumsan, Republic of Korea.
Figure 8. Experimental environment of MRGW interworking between LTE end-device and VSAT end-device at the KTSAT Kumsan satellite service center, in Kumsan, Republic of Korea.
Sensors 23 01201 g008
Figure 9. LTE end-device–(a) LTE module specification and the main board of LTE end-device; (b) Block-diagram of LTE end-device.
Figure 9. LTE end-device–(a) LTE module specification and the main board of LTE end-device; (b) Block-diagram of LTE end-device.
Sensors 23 01201 g009
Figure 10. System configuration for the test scenario 1 for evaluating the switchover performance of MRGW.
Figure 10. System configuration for the test scenario 1 for evaluating the switchover performance of MRGW.
Sensors 23 01201 g010
Figure 12. System configuration for test scenario 2 for evaluating the support for real-time video streaming data provided by the MRGW’s operation.
Figure 12. System configuration for test scenario 2 for evaluating the support for real-time video streaming data provided by the MRGW’s operation.
Sensors 23 01201 g012
Figure 13. Experiment outcome of test scenario 2 (Chrome browser screenshot of the video room through Web-RTC server (Janus)).
Figure 13. Experiment outcome of test scenario 2 (Chrome browser screenshot of the video room through Web-RTC server (Janus)).
Sensors 23 01201 g013
Figure 14. System configuration for test scenario 3 for evaluating the operation of MRGW in interworking with DX Ocean™.
Figure 14. System configuration for test scenario 3 for evaluating the operation of MRGW in interworking with DX Ocean™.
Sensors 23 01201 g014
Figure 15. Experiment outcome of test scenario 3 (a) DX Ocean™ software screenshot (b) Sample of ISP#1(LTE) wireless channel status information collected from the MRGW and stored at DX Ocean™ (onboard equipment and cloud-based on-land data hub).
Figure 15. Experiment outcome of test scenario 3 (a) DX Ocean™ software screenshot (b) Sample of ISP#1(LTE) wireless channel status information collected from the MRGW and stored at DX Ocean™ (onboard equipment and cloud-based on-land data hub).
Sensors 23 01201 g015
Figure 16. Experiment outcome of LTE end-device (a) navigation route in front of JangSaengPo port in Ulsan, Republic of Korea; (b) measured LTE performance.
Figure 16. Experiment outcome of LTE end-device (a) navigation route in front of JangSaengPo port in Ulsan, Republic of Korea; (b) measured LTE performance.
Sensors 23 01201 g016
Figure 17. Round trip time measured from VSAT end-device at KTSAT Kumsan satellite service center, in Kumsan, Republic of Korea.
Figure 17. Round trip time measured from VSAT end-device at KTSAT Kumsan satellite service center, in Kumsan, Republic of Korea.
Sensors 23 01201 g017
Figure 18. Experimental outcome of LTE end-device (a) navigation route in front Jeongok Port in Hwasung city, Republic of Korea; (b) measured LTE performance (RSRP, RSRQ).
Figure 18. Experimental outcome of LTE end-device (a) navigation route in front Jeongok Port in Hwasung city, Republic of Korea; (b) measured LTE performance (RSRP, RSRQ).
Sensors 23 01201 g018
Disclaimer/Publisher’s Note: The statements, opinions and data contained in all publications are solely those of the individual author(s) and contributor(s) and not of MDPI and/or the editor(s). MDPI and/or the editor(s) disclaim responsibility for any injury to people or property resulting from any ideas, methods, instructions or products referred to in the content.

Share and Cite

MDPI and ACS Style

Koo, H.; Chae, J.; Kim, W. Design and Experiment of Satellite-Terrestrial Integrated Gateway with Dynamic Traffic Steering Capabilities for Maritime Communication. Sensors 2023, 23, 1201. https://doi.org/10.3390/s23031201

AMA Style

Koo H, Chae J, Kim W. Design and Experiment of Satellite-Terrestrial Integrated Gateway with Dynamic Traffic Steering Capabilities for Maritime Communication. Sensors. 2023; 23(3):1201. https://doi.org/10.3390/s23031201

Chicago/Turabian Style

Koo, Hyounhee, Jungho Chae, and Wooseong Kim. 2023. "Design and Experiment of Satellite-Terrestrial Integrated Gateway with Dynamic Traffic Steering Capabilities for Maritime Communication" Sensors 23, no. 3: 1201. https://doi.org/10.3390/s23031201

Note that from the first issue of 2016, this journal uses article numbers instead of page numbers. See further details here.

Article Metrics

Back to TopTop