Underwater Network Management System in Internet of Underwater Things: Open Challenges, Beneﬁts, and Feasible Solution

: As oceans cover the majority of the earth’s surface, it becomes inevitable in extending the concepts of Internet of Things (IoT) to ocean bodies, thereby tiling the way for a new drift in the digital world, the Internet of Underwater Things (IoUT). The primary objective of IoUT is the creation of a network of several smart interconnected undersea things, to digitally link water bodies by using devices such as autonomous underwater vehicles. Since the traditional ideas of IoT cannot be merely expanded to underwater, due to the di ﬀ erence in environmental characteristics, this puts forward a variety of challenges for scientists to work with IoUT, and one such challenge is the network management with IoUT. This paper gives an overview on (1) underwater network management systems (U-NMS) using acoustic communication in IoUT; (2) the challenges and beneﬁts and use cases of U-NMS; (3) fault, conﬁguration, accounting, performance, security and constrained management (FCAPSC) functionalities of U-NMS and (4) a comparison between network management system in IoT and U-NMS system in IoUT. Additionally, this paper shows the prototype design and implementation setup of U-NMS in a laboratory environment, using lightweight machine to machine (LWM2M) and acoustic communication technology for IoUT. This paper will contribute much to the proﬁt of researchers and industry players in uncovering the critical areas of the Internet of Underwater Things.


Introduction
The existing Internet of Things (IoT) system is coped with various heterogeneous devices that are installed with hardware and software components [1][2][3][4]. Due to the continuous growth in the number and variety of network elements, the complexity of the network management activity has become progressively stronger. In such a case, the network management system (NMS) becomes mandatory to monitor and control the devices in a heterogeneous network [5]. Most of the relevant technologies of the network management system ought to have the following characteristics: (1) it should be automatic and frequently monitor the activities of the terrestrial area network; (2) it should rapidly notify the problems The IoT network management system plays a significant role in the industry. Many researchers in the past have discussed their numerous ideas for designing and developing the terrestrial NMS, such as network management platform, device management protocol, network management protocol, etc., [14] and other NMS systems adapted with terrestrial IoT are reviewed underneath.
The simple network management protocol (SNMP) [15][16][17] is used in the terrestrial area network, to identify and solve the bugs or errors of networks. SNMP was developed by the team Internet Engineering Task Force (IETF). Abstract syntax notation one (ASN.1) [18] is the language used for defining the management information base in the network management system. User Datagram Protocol (UDP) is the supporting protocol, and OpenNMS, OpenDayLight, and Zabbix are the management platforms used in SNMP. Network configuration protocol (NETCONF) [19] was developed primarily for network configuration, and the monitoring of the terrestrial network management system. Yet Another Next Generation (YANG) is the modeling language used in NETCONF and Extensible Markup Language (XML); JavaScript Object Notation (JSON) is the supporting language of NETCONF [20,21]. The common information management protocol (CMIP) [22,23] was developed by International Organization for Standardization (ISO), which is used for the The IoT network management system plays a significant role in the industry. Many researchers in the past have discussed their numerous ideas for designing and developing the terrestrial NMS, such as network management platform, device management protocol, network management protocol, etc., [14] and other NMS systems adapted with terrestrial IoT are reviewed underneath.
The simple network management protocol (SNMP) [15][16][17] is used in the terrestrial area network, to identify and solve the bugs or errors of networks. SNMP was developed by the team Internet Engineering Task Force (IETF). Abstract syntax notation one (ASN.1) [18] is the language used for defining the management information base in the network management system. User Datagram Protocol (UDP) is the supporting protocol, and OpenNMS, OpenDayLight, and Zabbix are the management platforms used in SNMP. Network configuration protocol (NETCONF) [19] was developed primarily for network configuration, and the monitoring of the terrestrial network management system. Yet Another Next Generation (YANG) is the modeling language used in NETCONF and Extensible Markup Language (XML); JavaScript Object Notation (JSON) is the supporting language of NETCONF [20,21]. The common information management protocol (CMIP) [22,23] was developed by International Organization for Standardization (ISO), which is used for the management of telecommunication networks. Guidelines for the Definition of Managed Objects (GDMO) is the modeling language used for defining the managed objects (MOs) in CMIP. Transmission Control Protocol (TCP)/User Datagram Protocol (UDP) are the supporting protocols of CMIP. The LoWPAN Network Management Protocol (LNMP) [24][25][26] management architecture is suitable for Internet Protocol (IPv6) and low-power wireless personal area networks. The LNMP used the adaptation layer protocol with SNMP for the management of network devices. Message translation is possible in LNMP. UDP is the supporting protocol, and OpenNMS is the management platform of LNMP. IETF developed the restful network configuration protocol (RESTCONF) [27,28]. RESTCONF is the extraction of NETCONF, by adding a simple interface for restful communication. YANG is the data modeling language used in RESTCONF. Open vSwitch Database (OVSDB) [29][30][31] was developed by IETF to operate in a software-defined network (SDN). It comprises the open database server (OVSDB) and an open virtualized switch (OVS) for fast-forwarding. OVSDV supports the easy creation of interfaces by the user.
Open Mobile Alliance Lightweight M2M (OMA-LwM2M), is utilized as the device management protocol in the M2M network environment [32][33][34]. XML, JSON is the language used for modeling and utilizes the CoAP methods like GET, PUT, POST, and DELETE for binding in OMA-LwM2M. OMA Device Management (OMA-DM) [35][36][37] functions are used to provide the communication between server and client in devices, via the device management tree. This is the finest solution for remotely managing connected devices. The XML format is used for communication. Constrained application protocol (CoAP) [38][39][40] was developed by IETF. CoAP was specially designed for constrained devices, which is used with lower-level protocols, but it is particularly adapted over UDP/Internet Protocol Version 6 (IPv6). Its focus is mainly on finding unreachable devices. universal resource identifier (URI) is the technique used to identify the resources. Datagram Transport Layer Security (DTLS) is the supporting protocol used for high-level security in CoAP. Things Management Protocol (TMP) [41] uses the operations get/set, like the SNMP operations, to allow the interface to transmit and communicate between the things and things to the application. Web Service Definition Language (WSDL) is the language used for supporting TMP. Web API is the supporting protocol of TMP. The characteristics comparison of network management and device management protocols in the terrestrial Internet of Things (IoT) environment are presented in Table 1.
For accessing the network traffic information, the multi router traffic grapher (MRTG) is widely used in the IoT based network [42]. In Reference [43], an NMS for the large scale area network (WSNMS) is proposed to manage more than 215 nodes. The experimental results show that the performance of WSNMS is high-level. In Reference [44], in order to make a reliable management system for telecommunication networks, the Japanese company extended the framework of the telecommunication management network (TMN), with high reliability and a good quality of service. In Reference [45], the TMN based network management system with Common Object Request Broker Architecture (CORBA) and the integration are made through SNMP/CMIP for gateway-based management. In Reference [46], the ad-hoc NMS is proposed, based on the new network management technique and an upgraded embedded ARM-Linux terminal. The experimental result proved that efficiency is improved for small scale networks. In Reference [47], an intelligent agent for the telecommunication management system is proposed, by reactivating the properties of agents. Additionally, the system-level diagnosis method is used to increase the reliability in the network.  However, owing to the lack of research in the area of the network management system (NMS) in IoUT [70], and the technical limitation in the IoUT environment such as connection, security management, localization, power management, memory management, low data rate, etc. are noted in [71]. The researchers focus did not touch the area of the network management system in IoUT. In the 21st century, the IoT based industries are likely to be increased [72]. Therefore, it is essential to develop the underwater network management system (U-NMS), to deliver quality services for IoUT use cases. The primary contribution of this paper can be summarized as follows: The rest of the paper is organized as follows. Section II addresses the conceptual architecture of However, owing to the lack of research in the area of the network management system (NMS) in IoUT [70], and the technical limitation in the IoUT environment such as connection, security management, localization, power management, memory management, low data rate, etc. are noted in [71]. The researchers focus did not touch the area of the network management system in IoUT. In the 21st century, the IoT based industries are likely to be increased [72]. Therefore, it is essential to develop the underwater network management system (U-NMS), to deliver quality services for IoUT use cases. The primary contribution of this paper can be summarized as follows: • Overview of U-NMS based on acoustic communication technology in IoUT.  The rest of the paper is organized as follows. Section 2 addresses the conceptual architecture of U-NMS, along with its open challenges, benefits, literature review, functions of U-NMS, and describes the comparison between NMS in IoT and U-NMS in IoUT. Section 3 describes the prototype design and implementation setup of U-NMS in a laboratory environment for IoUT. Section 4 concludes the paper, along with future work and direction.

Background
In this section, this paper provides an overview of U-NMS, along with an elaboration of the literature review, and discusses the different challenges, benefits, and functions of U-NMS system, along with the comparison between NMS and U-NMS.

•
Intelligence: This is concerned with merging algorithms, as well as computation, along with hardware plus software, which makes it smart enough to interact with various underwater and surface devices in an efficient manner. Multi-path effect: The internal stratification of the ocean causes multi-path effects such as distortion and severe frequency-dependent fades. A multi-path medium results in a temporal spread of the transmitted pulses, as well as time-variant propagation delays and attenuation factors. • Stratification effect: Localization is one of the essential tasks for underwater acoustic sensor networks (UASNs). The sound speed in water environments varies with depth; therefore, the sound waves do not propagate along a straight line. This phenomenon is described as the stratification effect.

•
Underwater noises: Various noises underwater, such as ship noise, bio noise, wind noise, rain noise, etc. can make considerable changes in data underwater data transferrer. • Heterogeneity: The major design requirements for IoUT include scalability, modularity, extensibility, and interoperability.
• Dynamic Changes: Various IoUT devices state alters dynamically according to the environment, and the system should catch up with these.
The conceptual U-NMS architecture in IoUT is the combination of different networks, such as terrestrial IoT networks and IoUT networks, as shown in Figure 3. Initially, the management station is set up in the terrestrial IoT networks, where the U-NMS can be installed. The terrestrial IoT networks are attached with components, such as management station, manager, database, etc., and devices such as base station (BS), surface gateway (S-GW), etc. which is used for monitoring the underwater networks via radio frequency (RF) and acoustic communication technologies. The IoUT network consists of intelligent underwater devices such as underwater-sensor node (UW-SNode), unmanned underwater vehicle (AUV), underwater-cluster head (UW-CH), etc. These are also installed with agent software, that is used for sensing, collecting and transferring data.  • S-GW: Surface gateway can be the moving gateway or fixed gateway, which is established with the Global Positioning System (GPS) to obtain their location and time for references. Especially, the task of S-GW is to provide self-localization and synchronization services to UUVs and AUVs [84][85][86]. • AUVs/UUVs: In U-NMS, the AUV or UUV acts as the "mobile nodes" in the underwater communication system, which provides the degree of spatial reuse mechanism for localization tasks in U-NMS. The locations of AUVs/UUVs can be estimated through direct interaction with the S-GW in the water body. The acoustic medium can be used for collecting and transferring data in U-NMS [84][85][86]. • UW-CH: In U-NMS, the UW-CH is used for collecting the network management information from UW-SNode and transferring those data to AUVs or UUVs via acoustic communication. • UW-SNode: In U-NMS, the UW-SNode is used for transferring the critical message of the UW-SNode itself to UW-CH or UUVs.

Literature Review on U-NMS
To date, the literature lacks comprehensive reviews and studies on the role that U-NMS plays in the context of IoUT. The existing literature review indicates the necessity of a network management system in IoUT [50]. In Reference [70], the high-level U-NMS architecture and topology discovery mechanism is proposed for integrating terrestrial management systems into an underwater constrained environment. The proposed architecture comprises numerous U-NMS components, such as manager, master-agent, sub-agent, management station, underwater SNMP (u-SNMP), manage objects, etc., for collecting and managing network information. It utilizes methods such as to Request, Response, and Trap to collect network management information in U-NMS, as displayed in Figure 4. • S-GW: Surface gateway can be the moving gateway or fixed gateway, which is established with the Global Positioning System (GPS) to obtain their location and time for references. Especially, the task of S-GW is to provide self-localization and synchronization services to UUVs and AUVs [84][85][86]. • AUVs/UUVs: In U-NMS, the AUV or UUV acts as the "mobile nodes" in the underwater communication system, which provides the degree of spatial reuse mechanism for localization tasks in U-NMS. The locations of AUVs/UUVs can be estimated through direct interaction with the S-GW in the water body. The acoustic medium can be used for collecting and transferring data in U-NMS [84][85][86]. • UW-CH: In U-NMS, the UW-CH is used for collecting the network management information from UW-SNode and transferring those data to AUVs or UUVs via acoustic communication. • UW-SNode: In U-NMS, the UW-SNode is used for transferring the critical message of the UW-SNode itself to UW-CH or UUVs.

Literature Review on U-NMS
To date, the literature lacks comprehensive reviews and studies on the role that U-NMS plays in the context of IoUT. The existing literature review indicates the necessity of a network management system in IoUT [50]. In Reference [70], the high-level U-NMS architecture and topology discovery mechanism is proposed for integrating terrestrial management systems into an underwater constrained Electronics 2020, 9, 1142 8 of 33 environment. The proposed architecture comprises numerous U-NMS components, such as manager, master-agent, sub-agent, management station, underwater SNMP (u-SNMP), manage objects, etc., for collecting and managing network information. It utilizes methods such as to Request, Response, and Trap to collect network management information in U-NMS, as displayed in Figure 4.   Based on the manager-agent concept in [89], the u-SNMP based network management is presented in Figure 6. In order to controll, as well as monitor, the underwater network, the u-SNMP manager makes an interface that co-operates with u-SNMP agent using u-SNMP. Based on the request from u-SNMP manager, the u-SNMP agent will send a response back. To represent the resources in the network, objects that act as data variables are used. These objects are collectively known as underwater management information base (u-MIB); this signifies features of the managed In Reference [87], a couple of studies discussed the lightweight network management system with a specific IoUT function. Additionally, the underwater network management system (U-NMS) for the constrained environment was proposed. This includes newly designed architecture, the never stop mechanism, the integration of the underwater management information base (u-MIB) [88], and u-SNMP as the network management protocol, by compressing legacy SNMPv2c, carried out by Hamdamboy Urnov et al., as shown in Figure 5.
Based on the manager-agent concept in [89], the u-SNMP based network management is presented in Figure 6. In order to controll, as well as monitor, the underwater network, the u-SNMP manager makes an interface that co-operates with u-SNMP agent using u-SNMP. Based on the request from u-SNMP manager, the u-SNMP agent will send a response back. To represent the resources in the network, objects that act as data variables are used. These objects are collectively known as underwater management information base (u-MIB); this signifies features of the managed device. Almost all the actions, such as monitoring, controlling, and configuring, can be remotely done using u-MIBs that comprise definitions of management information. The u-SNMP manager monitors and controls the functions of U-NMS, by carrying the value of u-MIB via underwater networks. It also helps in modifying the configuration settings, by altering the value of certain variables, or triggering a particular action that will take place at an agent side. The operations performed using u-SNMP are depicted in Table 2.

Operations Explanation Value of Bits
Get Request Read The Get Request and Get Response method is necessary to retrieve the underwater management information base (u-MIB) value from the master agent or sub-agent of U-NMS.   Based on the manager-agent concept in [89], the u-SNMP based network management is presented in Figure 6. In order to controll, as well as monitor, the underwater network, the u-SNMP manager makes an interface that co-operates with u-SNMP agent using u-SNMP. Based on the request from u-SNMP manager, the u-SNMP agent will send a response back. To represent the resources in the network, objects that act as data variables are used. These objects are collectively known as underwater management information base (u-MIB); this signifies features of the managed device. Almost all the actions, such as monitoring, controlling, and configuring, can be remotely done using u-MIBs that comprise definitions of management information. The u-SNMP manager monitors and controls the functions of U-NMS, by carrying the value of u-MIB via underwater networks. It also helps in modifying the configuration settings, by altering the value of certain variables, or triggering a particular action that will take place at an agent side. The operations performed using u-SNMP are depicted in Table 2.

00111
The lightweight underwater management information base (u-MIB) module is designed based The lightweight underwater management information base (u-MIB) module is designed based on legacy SNMP in U-NMS, as shown in Figure 7. The technical focus is to integrate the lightweight u-MIB to the manager and agent [90].
In Reference [91], the Never-stop mechanism is integrated into the constrained IoUT environment, which helps for the reliable communication in U-NMS. Figure 8 illustrates the operating of the Never-stop mechanism in U-NMS. Based on the environmental condition, bandwidth level, and device condition, the data value is dynamically measured in U-NMS. For example, the battery power level and memory space level of each device. If the data value ≥ 1 is YES (depends on the threshold value), then the process enables the Local Manager Module to perform the U-NMS functions using OID, object value, time, etc. In this case, the functional integration will perform the operation based on the request handler, and performs the response handler operation (Msg value, Req.ID, VarBind, etc.). After completing one cycle, the never-stop mechanism is used by the manager to request the MOs repetitively in U-NMS. In contrast, data value less than one (1) converting module starts to activate (SNMP to u-SNMP), and varBind can use OPC, ODC algorithms. In progress, the sub-agent will be active based on the request handler. Functional integration has two function modules, as the fault and the constrained. Finally, the response handler will activate and respond to the master agent. Indeed, more roles are activated based on the converting module.
Electronics 2020, 9, x FOR PEER REVIEW 12 of 33 (Msg value, Req.ID, VarBind, etc.). After completing one cycle, the never-stop mechanism is used by the manager to request the MOs repetitively in U-NMS. In contrast, data value less than one (1) converting module starts to activate (SNMP to u-SNMP), and varBind can use OPC, ODC algorithms. In progress, the sub-agent will be active based on the request handler. Functional integration has two function modules, as the fault and the constrained. Finally, the response handler will activate and respond to the master agent. Indeed, more roles are activated based on the converting module.   Electronics 2020, 9, x FOR PEER REVIEW 12 of 33 (Msg value, Req.ID, VarBind, etc.). After completing one cycle, the never-stop mechanism is used by the manager to request the MOs repetitively in U-NMS. In contrast, data value less than one (1) converting module starts to activate (SNMP to u-SNMP), and varBind can use OPC, ODC algorithms. In progress, the sub-agent will be active based on the request handler. Functional integration has two function modules, as the fault and the constrained. Finally, the response handler will activate and respond to the master agent. Indeed, more roles are activated based on the converting module.

Functions Supporting U-NMS
FCAPS, a framework created by ISO, distinguishes the working purposes of network management into five various levels, such as fault-management (F), the configuration level management (C), the accounting level management (A), the performance level management (P) and the security level management (S) [11]. An extension of FCAPS, FCAPSC, is proposed for network management with IoUT [89]. The detailed description of FCAPSC function, along with the research carried out so far in IoUT domain with respect to network management, is given in this section. The FCAPSC functions are detailed in Figure 9.
• Fault Management (F) techniques for IoUT: In this level, network problems are identified and corrected. Possible future issues are identified, and actions are taken to stop them from recurring or occurring. Moreover, with the help of this, the network remains operational, and downtime will be minimized.

•
Configuration Management (C) techniques for IoUT: In this level, network operation is observed and controlled. Programming and hardware changes, including new equipment addition and programs, the reform of existing systems, programs, and obsolete systems removal, are coordinated. In addition to this, equipment inventory and programs are retained and updated regularly.

•
Accounting Management (A) techniques for IoUT: This level, also known as the allocation level, is dedicated to optimally as well as fairly distribute resources among several network subscribers. This makes use of the systems available in an effective way, reducing the operation cost. This level also ensures that the users are appropriately billed.

•
Performance Management (P) techniques for IoUT: In this level, the management system collects network statistics and evaluates the system's performance under different underwater condition. • Security Management (S) techniques for IoUT: In this level, the network is secured against hackers, physical sabotage, unauthorized users, and electronic sabotage. The privacy of user information is preserved where it is warranted/necessary. Security systems also permit network administrators to resist what each authorized user can or cannot do to a system.

•
Constrained Management (C) techniques for IoUT: This management is divided into 2 modules: (1) constrained network management and (2) constrained device management. In constrained management techniques, several steps are used to monitor and collect information from a constrained environment, such as battery power, memory level, connection status, etc., as summarized below.

1.
Lightweight mechanism: This module required a lightweight mechanism of system integration. Especially, the sustainability of message transmission should be lightweight and reduce message transmissions.

2.
The u-MIB integration: This module acts as a management database, such as lightweight enterprise MIB.

3.
Network coverage: This module integrated several modules of the function based on underwater network coverage specifications.

4.
System durability: This module can capture system durability and network possibilities, less error handling, and long-period system disabilities. management (C), the accounting level management (A), the performance level management (P) and the security level management (S) [11]. An extension of FCAPS, FCAPSC, is proposed for network management with IoUT [89]. The detailed description of FCAPSC function, along with the research carried out so far in IoUT domain with respect to network management, is given in this section. The FCAPSC functions are detailed in Figure 9. • Fault Management (F) techniques for IoUT: In this level, network problems are identified and corrected. Possible future issues are identified, and actions are taken to stop them from recurring or occurring. Moreover, with the help of this, the network remains operational, and downtime will be minimized.

•
Configuration Management (C) techniques for IoUT: In this level, network operation is observed and controlled. Programming and hardware changes, including new equipment addition and programs, the reform of existing systems, programs, and obsolete systems removal, are coordinated. In addition to this, equipment inventory and programs are retained and updated regularly.

•
Accounting Management (A) techniques for IoUT: This level, also known as the allocation level, is dedicated to optimally as well as fairly distribute resources among several network subscribers. This makes use of the systems available in an effective way, reducing the operation cost. This level also ensures that the users are appropriately billed.

•
Performance Management (P) techniques for IoUT: In this level, the management system collects network statistics and evaluates the system's performance under different underwater condition. • Security Management (S) techniques for IoUT: In this level, the network is secured against hackers, physical sabotage, unauthorized users, and electronic sabotage. The privacy of user information is preserved where it is warranted/necessary. Security systems also permit network administrators to resist what each authorized user can or cannot do to a system.

•
Constrained Management (C) techniques for IoUT: This management is divided into 2 modules: (1) constrained network management and (2) constrained device management. In constrained management techniques, several steps are used to monitor and collect information from a constrained environment, such as battery power, memory level, connection status, etc., as summarized below.

Challenges and Benefits of U-NMS
As the environmental conditions of the terrestrial area network and underwater area network differ significantly, it poses numerous challenges if one tries to extend the traditional concepts of NMS to U-NMS simply. Some of the practical technical challenges are listed below: • Low data rates: Using low frequencies in underwater communication is the major cause of the low data rate. In addition, there are several problems inherent to medium like reflections, energy dispersion, refraction, etc., that significantly degrade the communication among devices [92]. • Localization in UWASN: Since radio frequency waves are highly attenuated, localization in underwater is highly challenging. Because of this, employing technology in devices such as GPS is not viable [93].

•
Topology control: It is used to improve the technologies in underwater communication such as localization, time synchronization, mobility management, data reduction, energy-efficient network operation, and routing. Therefore, the topology control mechanism faces a massive challenge in underwater communication [94].

•
Routing problem: The underwater communication generally relays on the acoustic and optical medium. This consumes a high battery for long-range acoustic communication and short-range optical communication. Therefore, for energy saving, it becomes a huge challenge to build energy-efficient routing protocols for underwater communication [95]. • Data collection: The data-gathering methods in UWSNs are considerably different than those in WSNs, due to high battery energy consumption, high propagation delay, and so on. Many of the proposed schemes still face difficulties in reliable data collection [96].

•
Learning mechanisms: Deep learning or machine learning mechanisms require a massive amount of data support. With the wireless communication technology, along with a huge amount of data, there is an inherent benefit of applying a deep learning mechanism. However, the broad application of deep learning mechanisms in wireless sensor networks is still not fully developed, particularly in underwater acoustic sensor networks [97]. Problem with network configuration: In the underwater network management system, when the network size increases, there is a difficulty to update the software inside the devices. This leads to errors in the network management system [50,70].

•
Problem with device security: In the underwater network management system, some attacks in devices can make the whole network collapse. So, the management system needs the security mechanism to prevent the attacks [50,70]. • Memory problem in IoUT devices: In the underwater network management system, the memory size is limited for all smart sensing devices. So, memory management is necessary for storing and retrieving information [50,70]. • Battery problem in IoUT devices: In the underwater network management system, load balancing is an essential part of smart sensing devices, since there is only limited power backup in underwater sensor nodes, and, a higher power has to be needed in the case of higher distance data transferring and complicated signal processing at the receiver. Therefore, high recharging cost is one of the major issues underwater [50,70].
To overcome the U-NMS challenges, such as battery problems, memory problems, bandwidth problems, etc., the underwater device management system and underwater network management system should be designed by considering various factors, as shown in Figure 10.

•
Underwater network monitoring and controlling, utilized for managing and controlling the underwater network-based functions, such as link quality, connectivity, network security, etc., in U-NMS.

•
Underwater device monitoring and controlling utilized for controlling the underwater device-based functions, such as device name, ID, etc., in U-NMS.

Comparison Between NMS and U-NMS
This subsection depicts the comparison between NMS and U-NMS: Table 3 describes the environment setup comparison between NMS and U-NMS, Table 4 describes the network management protocol comparison between NMS and U-NMS, and Table 5 describes the device management protocol comparison between NMS and U-NMS.

Proposed U-NMS System
This section presents a detailed description of the new prototype design for U-NMS, with general architecture, requirements supporting the proposed U-NSM, laboratory environmental test, and emulation results. Figure 11 shows the proposed U-NMS architecture based on LWM2M [32][33][34]. This architecture consists of four main components: U-NMS server (LWM2M-based server), U-NMS client (LWM2Mbased gateway, U-NMS application, and IoUT devices. A group of IoUT device sensors, which are connected to LWM2M-based gateway, provide underwater sensor services established on device information, such as device identity, device name, memory status, temperature level, battery level, etc. U-NMS client (LWM2M-based gateway) has dual characters: it controls underwater devices, and acts as the client to U-NMS server (LWM2M-based server). U-NMS server maintains a collection of

Comparison Between NMS and U-NMS
This subsection depicts the comparison between NMS and U-NMS: Table 3 describes the environment setup comparison between NMS and U-NMS, Table 4 describes the network management protocol comparison between NMS and U-NMS, and Table 5 describes the device management protocol comparison between NMS and U-NMS.

Proposed U-NMS System
This section presents a detailed description of the new prototype design for U-NMS, with general architecture, requirements supporting the proposed U-NSM, laboratory environmental test, and emulation results. Figure 11 shows the proposed U-NMS architecture based on LWM2M [32][33][34]. This architecture consists of four main components: U-NMS server (LWM2M-based server), U-NMS client (LWM2Mbased gateway, U-NMS application, and IoUT devices. A group of IoUT device sensors, which are connected to LWM2M-based gateway, provide underwater sensor services established on device information, such as device identity, device name, memory status, temperature level, battery level, etc. U-NMS client (LWM2M-based gateway) has dual characters: it controls underwater devices, and acts as the client to U-NMS server (LWM2M-based server). U-NMS server maintains a collection of managed objects from U-NMS client, performs management operations, and is stored inside the U-NMS server database (DB). U-NMS is the kind of application used in U-NMS server for the management of networks and devices underwater. The users can collect the network and device state information of IoUT devices. Table 6 shows the requirements supporting the design of U-NMS. Table 6. Requirements of proposed U-NMS.

Requirements of U-NMS Description
User

Requirements of U-NMS Description
User/Manager console It can be the user or machine that can control and manage all the operations of the manager via management station U-NMS Application use in the U-NMS server Network management station The placeholder for database management, user and manager To avoid the failure of IoUT devices, the resources such as power status, link status, memory status, etc. need to be checked frequently Timeliness Timeliness is used to check the service quality in U-NMS Network status monitoring To identify the connection between the devices in IoUT environment  Figure 12 illustrates the software block diagram of the LWM2M based gateway in U-NMS. This block diagram consists of three compartments: IoUT networks and devices, which is installed with subagent and provides the device resource information, such as device ID, device name, device battery, etc., or (R1, R2, R3) to the U-NMS client. The U-NMS client is installed with the master agent, which comprises the object manager and resource manager. The object manager is stored with existing objects, and has space for storing new objects using OIDs. The resource manager will collect the resources provided by IoUT devices and store them in the pool as R1, R2, R3, etc. The object manager assigns OIDs for the newly found resources in the pool and store as the new MOs in U-NMS client. The U-NMS server that is installed with the manager is used to collect or manage the MOs of U-NMS client, using GET/SET methods. Performance analysis In U-NMS, it is necessary to identify the performance of each IoUT device Device information collection It is necessary to collect the device information such as ID, name, address, etc Self-resource discovery Identify the resource availability of each IoUT device and notify that information to U-NMS server via U-NMS client Figure 12 illustrates the software block diagram of the LWM2M based gateway in U-NMS. This block diagram consists of three compartments: IoUT networks and devices, which is installed with subagent and provides the device resource information, such as device ID, device name, device battery, etc., or (R1, R2, R3) to the U-NMS client. The U-NMS client is installed with the master agent, which comprises the object manager and resource manager. The object manager is stored with existing objects, and has space for storing new objects using OIDs. The resource manager will collect the resources provided by IoUT devices and store them in the pool as R1, R2, R3, etc. The object manager assigns OIDs for the newly found resources in the pool and store as the new MOs in U-NMS client. The U-NMS server that is installed with the manager is used to collect or manage the MOs of U-NMS client, using GET/SET methods. Figure 13 shows the message sequence process of the LWM2M based gateway (U-NMS client). When it begins, the U-NMS client registers its existence and objects to U-NMS. Once the connection is established between U-NMS client and IoUT devices, the object manager in the U-NMS client will start the resource discovery process. In accordance with the results, the object manager dynamically creates OIDs for the newly discovered resources. A U-NMS server can retrieve information about created objects by searching for the objects in U-NMS client list. After creating OIDs for the new resources, the U-NMS server can GET/SET messages regarding specific resources of the managed objects. These messages will be mapped to the subsequent operation in the object manager. As a result, the U-NMS client obtains the most recent data generated by the IoUT devices. The received information is finally delivered to the U-NMS server.   Figure 13 shows the message sequence process of the LWM2M based gateway (U-NMS client). When it begins, the U-NMS client registers its existence and objects to U-NMS. Once the connection is established between U-NMS client and IoUT devices, the object manager in the U-NMS client will start the resource discovery process. In accordance with the results, the object manager dynamically creates OIDs for the newly discovered resources. A U-NMS server can retrieve information about created objects by searching for the objects in U-NMS client list. After creating OIDs for the new resources, the U-NMS server can GET/SET messages regarding specific resources of the managed objects. These messages will be mapped to the subsequent operation in the object manager. As a result, the U-NMS client obtains the most recent data generated by the IoUT devices. The received information is finally delivered to the U-NMS server. Electronics 2020, 9, x FOR PEER REVIEW 22 of 33 Figure 13. Sequence diagram for creating GET/SET operation in U-NMS.

Prototype Design and Managed Objects Defining
U-NMS prototype is designed with different components, such as U-NMS client, U-NMS server, manager, agent, underwater devices, etc. The components used for the design process are as follows: 1. U-NMS server: It consists of the manager program, which is used to manage the underwater networks and devices. For example, the operations such as GET/SET are used to get the information from U-NMS client in U-NMS. 2. U-NMS client: It consists of a master agent program, which is used to send notification messages when some critical event occurs, and process the response message based on the request from the U-NMS server. 3. Service Provider: In the proposed design, the LTE cat. M1 is the service provider that acts as the interface between user and surface-gateway to connect IoUT devices. 4. Surface gateway: In our approach, the surface gateway acts as the U-NMS client.
a. Device profile: It is the acoustic modem connected with acoustic transducer. b. MOs: The U-NMS client consists of a collection of managed objects (MOs). The managed objects can be accessed using the object identifier (OID).
5. Underwater devices: The underwater devices are installed with the master agent, which can send the current resource information to U-NMS client.

Prototype Design and Managed Objects Defining
U-NMS prototype is designed with different components, such as U-NMS client, U-NMS server, manager, agent, underwater devices, etc. The components used for the design process are as follows: 1.
U-NMS server: It consists of the manager program, which is used to manage the underwater networks and devices. For example, the operations such as GET/SET are used to get the information from U-NMS client in U-NMS. 2.
U-NMS client: It consists of a master agent program, which is used to send notification messages when some critical event occurs, and process the response message based on the request from the U-NMS server.

3.
Service Provider: In the proposed design, the LTE cat. M1 is the service provider that acts as the interface between user and surface-gateway to connect IoUT devices. 4.
Surface gateway: In our approach, the surface gateway acts as the U-NMS client.
a. Device profile: It is the acoustic modem connected with acoustic transducer. b.
MOs: The U-NMS client consists of a collection of managed objects (MOs). The managed objects can be accessed using the object identifier (OID).

5.
Underwater devices: The underwater devices are installed with the master agent, which can send the current resource information to U-NMS client. Figure 14 depicts the prototype design of U-NMS. The 'a' side of the figure consists of the 'manager' part that contains the U-NMS server, which is used to obtain the necessary information, or to update the information using the methods such as GET/SET in U-NMS, and the 'b' side of the figure consists of the 'master agent' part that contains LTE Cat.M1 modem emulator, which uses UDP based LwM2M (CoAP) for the communication between U-NMS server and U-NMS client.    Figure 15 shows the extended managed objects of U-NMS. In this paper, the MO structure is modified based on OMA-LwM2M. The newly defined underwater MO for U-NMS is Underwater network objects. These managed objects can be accessed using the address "Object ID/Object Instance ID/Resource ID/Resource Instance ID". The description of defined MOs is summarized as follows: • Network ID: Unique identity of underwater networks.

Testbed Description
In this section, we describe the U-NMS testbed in the laboratory environment. We start with the hardware parts used, and then describe the protocol stack used in the U-NMS.

Testbed Description
In this section, we describe the U-NMS testbed in the laboratory environment. We start with the hardware parts used, and then describe the protocol stack used in the U-NMS.

1.
Acoustic modem: The acoustic modem is designed with low power operation, which includes the MCU Cortex M3 processor, the operating frequency of 70 kHz, the maximum data rate of 200 bps, the maximum operational range of 50 m, and the dimension of radius 70 mm and height 40 mm. The serial peripheral interface (SPI) is used for the connection between the acoustic modem and the mainboard.

2.
The mainboard for U-NMS: STM32F103CB is utilized as the mainboard for U-NMS, which comprises of MCU Cortex M3 processor, installed with U-NMS module over the firmware, width, and height of 30 mm respectively and power consumption of 3.3 V and 5 V. The universal asynchronous receiver/transmitter (UART) interface is used for the communication between the mainboard and PC. 3.
Acoustic Transducer: The acoustic transducer supports the frequency range of 70 kHZ, with the input power of 190 watts, an operating depth of 1500 m, and uses the cable type of polyurethane 6 mm low noise coaxial.

4.
Water tank: The water tank is filled with water to create the underwater in lab environment, and the size is 75 cm × 75 cm × 100 cm-width, depth, and height, respectively.

5.
Manger/master agent: The PC is utilized for monitoring and controlling the operations of the U-NMS system. In this U-NMS system, the modem is connected to the serial port to GET-REQUEST, GET-RESPONSE, SET REQUEST, and, SET RESPONSE, from the manger and master agent. Figure 16 shows the laboratory environment test of U-NMS. The U-NMS server and U-NMS client are developed using the acoustic modem, and the acoustic transducer connected with it. The manager is used to send the request and, the master agent is used to send the response back to the U-NMS server. The experimental laboratory results are shown in sub-clause 3.5.
3. Acoustic Transducer: The acoustic transducer supports the frequency range of 70 kHZ, with the input power of 190 watts, an operating depth of 1500 m, and uses the cable type of polyurethane 6 mm low noise coaxial. 4. Water tank: The water tank is filled with water to create the underwater in lab environment, and the size is 75 cm × 75 cm × 100 cm-width, depth, and height, respectively. 5. Manger/master agent: The PC is utilized for monitoring and controlling the operations of the U-NMS system. In this U-NMS system, the modem is connected to the serial port to GET-REQUEST, GET-RESPONSE, SET REQUEST, and, SET RESPONSE, from the manger and master agent. Figure 16 shows the laboratory environment test of U-NMS. The U-NMS server and U-NMS client are developed using the acoustic modem, and the acoustic transducer connected with it. The manager is used to send the request and, the master agent is used to send the response back to the U-NMS server. The experimental laboratory results are shown in sub-clause 3.5.

Protocol Stack of U-NMS
The protocol stack of U-NMS is divided into two layers: (1) lower layer and (2) upper layer as shown in Figure 17. The lower layer is the combination of U-NMS physical layer and U-NMS data link layer, and the U-NMS application layer is partitioned under the upper layer of U-NMS.

1.
Application layer for U-NMS: The U-NMS application is installed inside the application layer of U-NMS. The U-NMS application module is employed here for the management of functions in U-NMS. The methods, such as GET REQUEST, GET RESPONSE, SET REQUEST, and SET RESPONSE, are used for transferring the U-NMS information.

2.
Data Link layer of U-NMS: The mainboard of U-NMS is connected to the U-NMS data link layer. The U-NMS module is installed in this layer for transferring the information base on the request. The functions such as data processing, error detection, and handling, data framing, schedule management, etc. are used in the data link layer of U-NMS.

3.
Physical layer of U-NMS: The functions, such as signal generation, binary transmission, acoustic medium for transmission, etc., are performed in the physical layer of U-NMS.
2. Data Link layer of U-NMS: The mainboard of U-NMS is connected to the U-NMS data link layer. The U-NMS module is installed in this layer for transferring the information base on the request. The functions such as data processing, error detection, and handling, data framing, schedule management, etc. are used in the data link layer of U-NMS. 3. Physical layer of U-NMS: The functions, such as signal generation, binary transmission, acoustic medium for transmission, etc., are performed in the physical layer of U-NMS.  Figure 18 shows the laboratory experimental setup of the underwater network management system for processing GET and SET U-MIB objects in U-NMS. It consists of two parts: (1) manager (U-NMS server) and (2) master agent (U-NMS client). The manager requests the managed objects of underwater devices, such as network ID, device ID, device name, etc. The master agent receives the request from the manager and sends the values back to the manager. The commands used for GET_REQUEST, GET_RESPONSE, SET_ REQUEST, and SET_RESPONSE are "91.92.11.XX.00", "91.92.12.XX.00", "91.92.13.XX.00", "91.92.14.XX.00", respectively, in U-NMS. Figure 19 shows the packet format of U-NMS with, 5 bytes for sending and receiving data. The packet format consists of a Source ID, Destination ID, Packet Type, Resource Type, and Resource Value. The description of the packet format is summarized below.

•
Source ID and Destination ID are used to identify the source and destination in U-NMS.   Figure 18 shows the laboratory experimental setup of the underwater network management system for processing GET and SET U-MIB objects in U-NMS. It consists of two parts: (1) manager (U-NMS server) and (2) master agent (U-NMS client). The manager requests the managed objects of underwater devices, such as network ID, device ID, device name, etc. The master agent receives the request from the manager and sends the values back to the manager. The commands used for GET_REQUEST, GET_RESPONSE, SET_ REQUEST, and SET_RESPONSE are "91.92.11.XX.00", "91.92.12.XX.00", "91.92.13.XX.00", "91.92.14.XX.00", respectively, in U-NMS. Figure 19 shows the packet format of U-NMS with, 5 bytes for sending and receiving data. The packet format consists of a Source ID, Destination ID, Packet Type, Resource Type, and Resource Value. The description of the packet format is summarized below.

•
Source ID and Destination ID are used to identify the source and destination in U-NMS.     Figure 20 shows how the GET_REQUEST and GET_RESPONSE method works on the manager side and master agent side in U-NMS. The 'a' side of the figure shows the working of the U-NMS server. For example, the manager sends the GET_REQUEST value as "92 26241/21" and receives the GET_RESPONSE value as "91 26241/21/51". Therefore, '51' is the MO value received from the U-NMS client. The 'b' side of the figure shows the working of the master agent. In this case, the master agent receives the GET_REQUEST message from the manager, and transmits the GET_RESPONSE value, including the requested object. Figure 21 shows the working SET_REQUEST and SET_RESPONSE methods in the manager and master agent sides of U-NMS. The existing value of "92/26241/21" was '51'. The SET_REQUEST method is used to change the value of MOs in U-NMS. The 'a' side of the figure shows the working of SET_REQUEST and SET_RESPONSE methods in the manager side. In this case, the manager sends the SET_REQUEST method for changing the MO value from "91 26241/21/51" to "91 26241/21/75", and received the SET_RESPONSE value successfully. The 'b' side of the figure shows the working of SET_REQUEST and SET_RESPONSE methods in the master agent side. In this case, the SET_REQUEST and SET_RESPONSE methods are received and transmitted successfully to the manager.   Figure 20 shows how the GET_REQUEST and GET_RESPONSE method works on the manager side and master agent side in U-NMS. The 'a' side of the figure shows the working of the U-NMS server. For example, the manager sends the GET_REQUEST value as "92 26241/21" and receives the GET_RESPONSE value as "91 26241/21/51". Therefore, '51' is the MO value received from the U-NMS client. The 'b' side of the figure shows the working of the master agent. In this case, the master agent receives the GET_REQUEST message from the manager, and transmits the GET_RESPONSE value, including the requested object. Figure 21 shows the working SET_REQUEST and SET_RESPONSE methods in the manager and master agent sides of U-NMS. The existing value of "92/26241/21" was '51'. The SET_REQUEST method is used to change the value of MOs in U-NMS. The 'a' side of the figure shows the working of SET_REQUEST and SET_RESPONSE methods in the manager side. In this case, the manager sends the SET_REQUEST method for changing the MO value from "91 26241/21/51" to "91 26241/21/75", and received the SET_RESPONSE value successfully. The 'b' side of the figure shows the working of SET_REQUEST and SET_RESPONSE methods in the master agent side. In this case, the SET_REQUEST and SET_RESPONSE methods are received and transmitted successfully to the manager.   Figure 21 shows the working SET_REQUEST and SET_RESPONSE methods in the manager and master agent sides of U-NMS. The existing value of "92/26241/21" was '51'. The SET_REQUEST method is used to change the value of MOs in U-NMS. The 'a' side of the figure shows the working of SET_REQUEST and SET_RESPONSE methods in the manager side. In this case, the manager sends the SET_REQUEST method for changing the MO value from "91 26241/21/51" to "91 26241/21/75", and received the SET_RESPONSE value successfully. The 'b' side of the figure shows the working of SET_REQUEST and SET_RESPONSE methods in the master agent side. In this case, the SET_REQUEST and SET_RESPONSE methods are received and transmitted successfully to the manager.

Conclusions and Future Direction
At present, the network management system (NMS) in IoT is one of the booming technologies used for the management of IoT devices in terrestrial IoT networks. The technologies applicable for the network management system in IoT, such as the network management protocol and device management protocols, cannot be applied in IoUT networks, due to various factors, such as the limitation of battery, memory, bandwidth, etc. Hence, it is essential to create a reliable NMS for IoUT. This paper describes the open challenges, benefits, and solutions for using a network management system, using acoustic communication technology in IoUT. Moreover, this paper provides various factors concerning U-NMS, such as (1) identify and outline open challenges in adopting NMS to U-NMS and illustrate the benefits of U-NMS; (2) comparative analysis of the network management and device management protocols of IoT along with the underwater network management system. Many researchers have proposed various ideas related to the network management system in IoT, such as network management protocol, device management protocol, etc. However, by studying the limitation underwater, the researchers find difficulties in applying the IoT network management system to underwater. So, the U-NMS in IoUT has a huge space in the emerging world. Therefore, the suggested prototype can be the basement for the developers in the underwater environment to develop the U-NMS. The current prototype is based on GET/SET methods, and only limited MOs are designed inside the U-MIB, such as network ID, device ID, network status, device resources, etc.
Currently, the proposed prototype is being tested in the laboratory environmental setup. In the future, the proposed prototype will be extended to the real field test in the sea environment, by employing different communication technologies in IoUT environment, such as acoustic, optical, and IR. Moreover, the management resources/managed object inside the U-MIB will be extended by adding more MOs. The method TRAP will be expanded in the future, to direct the notification message if any critical situation occurs in IoUT devices.