Abstract
Keywords
Introduction
In recent years, underwater acoustic sensor networks (UASNs) have gained much attention of applications like marine data acquisition, environmental monitoring, underwater resource survey, earthquake and tsunami monitoring, auxiliary navigation, and underwater robots. 1 The big data refers to large-scale data sets, which can be extracted from the valuable information. The arrival of big data era has put forward new requirements for the development of UASNs. On one hand, the type of underwater application is becoming more and more abundant, resulting in a large number of non-linear data. On the other hand, the pursuit of high-performance communications has become a new trend in UASNs.
Generally speaking, UASNs are deployed in a shallow sea where the communication environment is variable, and sensors are placed in a redundant manner. Usually, the ultrasonic wave 2 is employed to communicate, and the bandwidth is 10–40 Hz. 3 Compared with the wireless sensor networks (WSNs), the data transmission delay is greater. The bit error rate (BER) is higher, and the nodes are very hard to be deployed.
The underwater communication system relies on the hardware infrastructure in common. The related protocol and application system will be solidified in the corresponding nodes before being deployed. Usually, UASNs are deployed into water through autonomous underwater vehicles (AUVs), wheels, or unmanned aircraft. Underwater node is powered by a battery, and it is hard to be salvaged and reconfigured once been deployed. As a result, a customized UASN is generally a disposable system which is designed for only one specific underwater application and strenuous to be used in another. In addition, underwater equipment (nodes) from unusual manufacturers varies, which makes them difficult to achieve communication. Acoustic networks of distinct manufacturers and technology are very poor in building interaction and flexibility temporarily.
Currently, UASNs which are deployed in the water are more expensive, compared to the WSNs deployed on the land. Considering the actual application needs, UASNs are typically deployed in a redundant manner. For example, one underwater application that lasts over a period of 3 months generally needs about 3000 nodes. While the service time is calculated 2–3 times of the actual service length in order to guarantee reliability and security of the business, more than 6000–9000 nodes should be deployed. In general, UASNs will still survive for now until completely abandoned, which is of enormous waste. Due to different data format, protocol, and service constraint of varied applications, it is difficult to be used for other services in the identical underwater area, which apparently causes problems with the repeatability of the deployment. It is a very acute problem to deploy various acoustic sensor networks within the duplicate water area, which not only leads to waste but also causes serious signal interference.
Software-defined network (SDN) is a novel technology recognized as the infrastructure of next-generation networks, for which is expected to improve management efficiency and interoperability of heterogeneous devices significantly, while reducing operating costs in the meantime. SDN is originated from the research project of Stanford University, and the concept was officially proposed in 2009 by Mckeown et al. 4 It implements the separation of the data plane from the control plane, builds programmable hardware infrastructure (such as OpenFlow 5 ) through an open standardized interface, and defines the behavior and operation of network devices by a controller. In SDN, administrators can dynamically configure the network through programming and facilitate the management.
SDN offers a modern solution for UASNs. With the generic protocol and service interface of OpenFlow, we implement the centralized management by setting the underwater node as a virtual switch and the surface sink node as a controller. The character of SDN realizes the undifferentiated service of UASNs. Based on virtualization, the system can be reused. The software platform of a controller achieves the manipulation of the underlying hardware and scheduling on demand, which solves the duplicate deployment of UASNs in the same underwater area and takes full advantage of the system. With the rapid development of technology, SDN will be a key solution to improve the security and robustness of UASNs.
The rest of the article is organized as follows. Section “Related work” introduces related work. Section “System architecture” describes the basic structure of SDN-based UASNs. Section “Design of the data plane” presents the design of the data plane in detail, section “Design of the control plane” elaborates the development of the control plane, and section “Conclusion” concludes this article.
Related work
SDN is a hot topic in which wired network and terrestrial wireless network 6 are the most intensive realm. 7 However, the UASN based on SDN is fairly rare. Although WSNs are different from UASNs in technology and application, it also provides important technical support for implementing SDN in UASNs.
L Bertaux et al. 8 propose a software-defined framework for WSNs and solve the key methodological problems for its core components. T Luo et al. 9 present software-defined frameworks for intelligent management of WSNs, where SDN controller is implemented as a base station. A De Gante et al. 10 list important transactions to be processed in the future, including distributed controllers, state synchronization, the applicability of OpenFlow, and the security of a central controller. Z-J Qin et al. 11 design a software-defined method for the Internet of Things (IOT), which aims to provide different task levels in heterogeneous environments for diverse tasks of IOT. CAL Valdivieso et al. 12 analyze the development trend of SDN in IOT, while Z-J Han and W-L Ren 13 propose an optimization scheme based on OpenFlow, where WSNs are divided into many clusters with head node (HN), and SDN controller is used to formulate the forwarding strategy and control each node.
However, scholars mostly concentrate on software-defined radio (SDR) technology applied in UASNs. 14 Most of the relevant studies focus on the development of physical layer, rather than involving the design of the programmable network layer, so it is impossible to take full advantage of SDN.
D Torres et al. 15 present a complete end-to-end network platform for UASNs, namely, Underwater Acoustic Networking plaTform (UANT). It is designed for field deployment and capable of rapid prototyping and testing of the physical layer and media access control (MAC) layer. A Linux-based application running on UANT is elucidated in D Torres et al, 15 which evaluates the channel assignment and time synchronization protocol on UANT simultaneously.
Taking the advantages and disadvantages of acoustic, optical, and radio communication into account for underwater acoustic communication, Y-P Cong et al. 16 design an adaptable framework of multi-mode UASNs and propose a solution of cross-layer versatile modulation and demodulation.
IF Akyildiz et al. 17 present an SDN-based UASN architecture called SoftWater. A hybrid communication technology combining ultrasonic, optical wave, and radio wave is offered. The article also proposes the essential method of designing underwater sensor networks based on SDN, which can provide the fundamental guarantee for subsequent research.
However, in actual underwater applications, these hybrid systems of ultrasonic, optical wave, and radio wave have great obstacles in implementation of node design and communication method. Despite the fact that ultrasonic has the defects of slow speed, high delay time, narrow bandwidth, and obvious multi-channel effect, it conversely occupies the dominance in underwater acoustic networks because of the long transmission distance and reliable performance.
In this article, we propose an SDN-based underwater acoustic network in big data, and build the data plane and control plane. Based on SDN, we expect to implement the reuse of the system flexibly and improve reliability without changing the original hardware facilities.
System architecture
Structure of underwater acoustic network
In this article, we design a novel architecture of UASNs based on SDN. Sink nodes are considered as SDN controllers, and underwater nodes for which OpenFlow-based virtual switch (OvS) is installed are processed as SDN switches. Figure 1 is the basic structure of the system.
Architecture of underwater acoustic networks.
In underwater acoustic networks, sensor nodes are randomly deployed in underwater environments via AUVs, robots, or unmanned aircraft. Nodes are equipped with anchors and positioning modules. According to the actual location information and the depth of the nodes in the water, all the nodes can adjust the depth in order to form three-dimensional (3D) sensing area. Sink nodes are fixed on the sea surface with buoys, base stations, and other facilities.
SDN architecture of UASNs in big data
It provides an open, programmable network architecture based on SDN that allows more flexibility in configuring, managing, and optimizing the underlying network devices and implements application innovation with a controlled network. In SDN, it decouples the traditional network architecture composing of tightly coupled devices into the data plane, control plane, and the application plane. The lowest layer is the data layer, followed by the control layer, and the top layer is the application layer. The structure of UASN is shown in Figure 2.
Structure of SDN-based underwater acoustic networks.
The data layer consists of subordinate nodes with OvS installed. In data layer, the underwater nodes communicate with each other in a multi-hop relay mode, then the convergence data flow will be transferred to sink nodes (controllers) hop-by-hop, which is called the data communication process. Due to the high-bandwidth and low-latency requirement, the data channel is intended to be in a multi-hop mode, and distance of each hop is limited to 100 m, which is controlled by the instruction of controllers.
The main task of the control layer is supposed to be responsible for the control and maintenance of the network, namely, the network infrastructure information can be obtained through the standardized southbound interface (the control and data plane interface). The heterogeneity of the automatic shielding equipment can also be achieved through the standard northbound interface (application programming interface (API)) to interact with the application layer.
Sink node acts as a controller in an SDN-based underwater acoustic network. It is responsible for receiving, processing, and forwarding the sensing data, realizing data aggregation, and completing the network management. Considering the communication distance of underwater application, we design distributed multi-controller (sink nodes) architecture. The communication between controllers and the underwater nodes takes one-hop style with the control channel, in order to achieve a unified scheduling and management. The control signal transmits (e.g. instruction issuing and protocol processing) between the controllers and the underwater nodes via the ultrasonic link. The control channel is achieved by the low-bandwidth, high-delay, long-distance ultrasonic link, and the communication distance is limited to 3 km.
In order to enhance the flexibility, we decouple the data communication from control communication. To prevent symbol interference, the control communication and data communication are designed with different signal frequencies. The frequencies of data communication and control communication are issued through SDN controller. Controllers are set on the sea surface, and they use radio wave to communicate with each other based on multi-hop mode.
In application layer, users can customize a variety of specific business software and develop management strategies according to the network views which are provided by controllers. The API of northbound interface and southbound interface is utilized to achieve the logical definition of network resources and services, so the flexible scheduling of network tasks can be achieved.
In order to realize the comprehensive application of UASNs, we build a multi-application fusion based on virtualization and develop a variety of application software for the actual business needs in the application layer.
The data layer and control layer are the cores of SDN. After the development of these two layers, based on virtualization, the application layer can be built conveniently.
Network function virtualization
Unlike traditional networks, network function virtualization (NFV) can be employed in UASNs based on SDN architecture. So, the business and protocols can be delivered through controllers in time, also a variety of underwater applications can be achieved, and it is contributed to virtualization, which enables soft isolation between these applications.
It refers to creating a reasonable substantiality with numerous physical entities or creating numerous logical entities with a physical substantiality 18 based on NFV. In this article, NFV includes both technical implications above at the same time. On one hand, virtual multiple input and multiple output (MIMO) nodes are constructed based on clustering and other techniques. Multi-clustered relay transmission is implemented, which realizes the process of creating a logical entity with multiple acoustic nodes. On the other hand, based on the technological characteristics of SDN, a variety of services can be realized flexibly, and virtualization and function multiplexing of nodes can be realized too. It greatly improves the performance of UASNs and expands the scope of business. According to the actual demand, by designing the protocol for the factual service requirements on the controller, the reconfiguration of the underwater nodes can be realized based on SDN adaptively, to support heterogeneous network service.
In this article, we divide the network infrastructure resources (such as bandwidth, RAM, and CPU) into a number of slices, each of which forms a virtual device. Then, multiple effective devices form a flexible virtual network, and each virtual network is assigned to a specific underwater application. In this way, it is possible to implement a variety of applications on a specified physical underwater system that dynamically share the same network infrastructure and do not interfere with the operation and performance of others.
According to SDN model, we design the data plane and control plane. The data plane mostly involves physical layer and MAC layer, and the control plane is constructed by OpenFlow. The flow table can be configured through the southbound API. Based on the flow table, we can build standardized applications and the security protocols.
Design of the data plane
The data plane is composed of sensor nodes deployed in the underwater. Considering the actual business requirements, we only build the SDN architecture with fixed nodes in this article.
Hardware of the underwater node
Traditional UASNs are only applied to the specified business and cannot be served for others. It is difficult to be re-salvaged after being deployed. In addition, due to the disposable waterproof battery for power supply, the energy of the network is extremely limited. When the power is depleted, the node will fail at all, which means the node cannot be used ever.
In the network planning, new requirements for the node designing are presented. In SDN architecture, the underwater nodes are designed to be OvS which can be configured through a controller and provide a variety of services by NFV. The construction of multi-application device interfaces is the key to designing underwater nodes.
We use Rico Board as the development board, which is a single-board microcomputer manufactured by Mill Co., Ltd., 19 and the core processor is AM437x. With the open-source radio package, we install a simplified Linux-based operating system and then deploy OvS to enable virtualization.
Usually, as nodes are deployed in underwater environments, sonar is used for communication. To implement SDN technology, two different frequencies of acoustic waves are designed, one for the data channel and another for the control channel. Underwater nodes can be automatically clustered after being deployed. Data aggregation based on clustering occurs, and the data flow detected by the actual node is transmitted to the controller using multi-hop mode, namely, the data communication. Underwater nodes communicate with controllers in their lifetime using one-hop mode, which is known as control communication. The control communication mainly involves the processes that controllers send issue control instruction to underwater nodes and the responses of underwater nodes and so on. The topology is a star structure for control communication. Radio wave is used for communication between controllers, and the information gathered from the underwater environment is transmitted to the corresponding management system. The communication between controllers is not discussed in this article. The relevant parameters of data communication and control communication are shown in Table 1.
Parameters of communication.
The relevant modules and functions of underwater nodes list as follows:
The system is equipped with power modules, using high-energy waterproof battery. The system is equipped with USB/RS-232-C and other related interfaces, through which we can connect to computer for configuration. At first, the underlying operating system (such as Linux) is installed, so that underwater nodes can implement a simple initialization configuration. Underwater nodes can communicate with the computer through these interfaces, and the associated data are exported.
Underwater nodes are equipped with Secure Digital (SD) or memory card, which will store sensed information, like compressed data, video, and images. The system should have certain capability of image processing, so we use a simple graphics processing unit (GPU) system. The system should also contain a sealed underwater camera interface, which can capture undersea video and graphics.
A sonar transceiver is fixed on the underwater node. The frequency is adjustable for data communication and control communication by a controller. So, the short-distance communication based on multi-hop relay (data communication) and long-range communication by one hop (control communication) can be achieved.
Underwater nodes reserve rich sensor interfaces, which can deploy pH sensor, pressure sensor, temperature sensor, salinity sensor, image sensor, and other devices.
Underwater nodes should set a drive motor and hinge (anchor chain), which link anchor for underwater positioning. These nodes are sealed and waterproof, which are equipped with an airbag and a chain under the anchor. Combining anchor with airbag, the preset positioning algorithm can be utilized to calculate the telescopic length of the chain. The drive motor is used to achieve the expansion and contraction of the hinges, so a 3D underwater monitoring area can be formed.
The basic structure of underwater nodes is shown in Figure 3.
The basic structure of the underwater node.
Design of physical layer
Design of OpenFlow switches
OpenFlow is the standard interface designed for SDN, which implements a separation of the control plane from the data plane. It consists of two parts: switch and controller. Switches interact with controllers through OpenFlow, and controllers manage the switches also through the OpenFlow protocol. Switches transmit packets according to the generated flow table, representing the data plane. Controllers set up data forwarding (DF) strategy according to the entire network view, which represents the control plane.
We configure OvS 20 on underwater nodes to construct the data plane. OvS is an open-source project led by Nicira to provide two-tier network access for virtual machines on the physical entities, through the virtual switch running on the practical platform. In OvS environment, the virtual switch is to ensure traffic transmission between virtual machines and the external network.
The interaction between switches and network controllers (POX) can realize the diversified business. Based on SDN, a variety of applications are deployed flexibly, reducing the complexity of management and maintenance. In order to realize NFV, an essential management system is developed, which can be called by the controller to realize the process of creating multiple virtual nodes based on OpenFlow. These virtual nodes are logically isolated, do not interfere with each other, and are used to perform different application requirements.
Realization of physical layer based on SDR
In this article, SDR is utilized to construct the physical layer based on SDN. Rico Board is rich in open-source radio packages and can easily achieve the function of physical layer. In SDR, it takes hardware as the basic platform for wireless communications and realizes the communication function through software as much as possible.
In the physical layer, SDR is used to achieve baseband processing such as modulation, demodulation, channel coding, source coding, and MIMO pre-coding. Based on the dynamic stack structure, physical layer is realized. The dynamic stack is the technical characteristic of SDR. We design a variety of modulation and encoding methods, which are encapsulated into distinct parts, stacked, and encapsulated into a SDR-based physical layer. In practical, the users call the SDR modules to meet unusual needs dynamically and flexibly.
As shown in Figure 4, the physical layer is designed for modulation and demodulation, channel coding, multiplexing, and cooperative communication. Comparing to the traditional physical structure, the complexity of SDR-based physical layer is lower, but the flexibility is higher. For example, physical layer applied to the low-speed underwater communication, and the high-speed communication can be constructed and encapsulated using SDR.
SDR technology.
Depending on the actual application requirements, the SDN architecture in this article, which combines the modulation and demodulation of radio frequency (RF) and sonar signals, can be realized by frequency-shift keying (FSK), quadrature amplitude modulation-16 (QAM-16), or orthogonal frequency-division multiplexing (OFDM). Channel coding can be realized by convolutional code, turbo code, low-density parity-check (LDPC) code, and so on, and multiplexing can be achieved by time-division multiple access (TDM), orthogonal wavelet-division multiplexing (OWDM), code-division multiple access (CDMA), 21 and other technologies. Cooperative communication is an optional module that can be implemented using multiple methods, such as MIMO and clustering relay. It is an important aspect of the UASNs based on SDN. At present, we are studying the performance of UASNs based on cooperative communication to construct virtual MIMO nodes.
Design of the MAC layer
In SDN architecture of UASNs, it mainly considers the addressing and clustering of underwater nodes for designing the MAC layer. According to the actual deployment, underwater communication systems are divided into planar structure, fixed-node 3D structure, and AUVs-assisted 3D structure. The planar structure comprises sensor nodes fixed or randomly deployed on the corresponding seabed. The fixed-node 3D structure consists of sensor nodes deployed with either anchor or buoys at distinctive depths under sea level. AUVs-aided 3D structures are realized by AUVs deployed at distinctive depths.
The hierarchical clustering techniques
Fixed-node UASNs are deployed in the water with a 3D structure, as shown in Figure 5. In this deployment mode, the system is divided into n layers. Sensor nodes of each layer form a cluster. The selection of HN is based on the position of nodes in the cluster. Horizontal sonar links are utilized to implement communication between clusters. Then, HN gathers the message from the other data nodes (DN) in the cluster and transmits data to the upper HN using the vertical sonar link.
Node-fixed 3D deployment.
As shown, Figure 6 is a 3D grid, which is divided into three layers and contains 27 clusters.
UASNs’ architecture for layered 3D networks.
The data transmission method in the clustering consists of three steps: configuration, data aggregation, and transmission. The configuration phase is to implement the selection of HN. During the data aggregation phase, all the nodes transmit the data to HN and then HN receives the aggregated data. In the data transmission phase, HNs send the aggregated data to sink nodes through the relay mode. During the configuration phase, the nodes with the largest memory and power in the clusters are elected as HN, and multiple nodes realize the reliability and load balance of UASNs. These nodes can communicate with other DNs in the cluster and achieve energy savings. As shown in Figure 7, it is a basic 3D grid structure; while clustering is implemented, we quantify the nodes in the entire 3D stereo space.
The structure of 3D grid.
As shown in Figure 7, a 3D mesh is cyclically selected from these nodes. Although more than one node can be elected as HN in a cluster, only one HN is elected at one time, and the others are set as DN, some being in the sleep mode, some in the wake mode. Elections are based primarily on the remaining memory and capacity of the participating nodes. In current actual deployment, we consider the fan-shaped model or star mode to form a regular data grid. This will be discussed in future research.
Node addressing techniques
The 3D model of UASNs with anchor for fixation is adopted in this article. The addressing method of nodes is numbered by their relative position in the system. The system is deployed in a dense manner. As described in the previous section, we know that underwater nodes are divided into two types, which are DN and HN. In this article, we adopt clustering method to aggregate information, and the aggregated data is transmitted to sink with multi-hop relay mode. The sink nodes are controllers of SDN.
The DN nodes and the HN nodes all use a 32-bit local address for intra-cluster communication. The address format is gridID.X.Y.Z, where gridID represents the node that belongs to the grid, <X, Y, Z> means the 3D spatial location of nodes in the grid, the location Z is mainly used to achieve intra-cluster communication. The range of intra-cluster communication address is (0.0.0.0–254.255.255.255), and addresses more than 255 are reserved, so the address format is set to 255.X.Y.Z.
The single controller mode is the foundation of the system. In order to simplify the performance analysis, we first consider the case of a single controller and multiple DN nodes. When deploying a practical underwater network, we need to consider parallel communication and cooperative processing between numerous controllers. Currently, it is another task we are working on.
Design of the control plane
Hardware design of the controller
The UASNs based on SDN are composed of the data plane and the control plane, and controllers are the main equipment of the control plane. In this article, controllers are fixed on the sea surface with buoys, base stations, or other facilities. We build a distributed network of multi-controllers (sink nodes) and monitor a wide range of underwater area through the cooperation communication. A logically centralized controller is implemented by multiple physically distributed controllers, which solve the problem of limited performance of a single controller and extend the monitoring range, while taking the advantage of centralized control.
With the synchronization mechanism, all controllers deployed on different buoy only need to share some vital local information but do not actively communicate with any remote controllers, in order to minimize the configuration time.
We use Jetson TK1 22 as the hardware platform of controllers. TK1 is a high-performance development kit designed for embedded systems. Through a complete set of tools, as well as providing support for additional peripherals and interfaces, TK1 is the ideal platform for developing high-performance SDN controller, for which POX is installed to implement the operation system.
Controllers of SDN are provided with buoys, the Global Positioning System (GPS) positioning modules, and the RF communication modules. The underwater sonar transmitting and receiving modules are installed in consideration of communication among controllers and the coast base stations. Controllers are also equipped with a solar panel that can steer to track the sunlight and implement power supplying. The aggregated data are stored in the SD card of large capacity space. Controllers can communicate with each other through RF, and underwater nodes communicate with controllers by the ultrasonic wave. Underwater nodes are utilized to form a 3D sensing area, which is connected with controllers on the water through positioning. The signals are transmitted to the corresponding sink nodes (controllers) through the relaying mode in a clustered way. Controllers receive the underwater sensing signals, carry on the logic summary, and then transmit the aggregated data to the coastal monitoring station. Based on virtualization, clustering, and multi-thread technology, the centralized management of the multi-controllers can be done, and the service performance of controllers can be improved. The basic structure of SDN controller is shown in Figure 8.
The basic structure of the controller.
The core modules of a controller
TK1 is the hardware platform of SDN controller. We install POX 23 on this platform and realize the controller. POX is from NOX, which is the first OpenFlow controller written in C++ and also provides an API for Python’s development. The underlying module is implemented by C++, the upper application can be written in C++ or Python, for which the central role is to provide a platform for rapid development of SDN.
According to the actual requirements, the device manager (DM) module, topology manager (TM) module, link-load monitoring module, DF module, and routing components are developed on POX. The correlation of the modules is shown in Figure 9.
Development modules and relationships.
DM module
DM module is a component in which controllers are utilized to record information of nodes. It mainly records the information which includes node number existing in the system, and the MAC address and Internet Protocol (IP) address of nodes, as well as the virtual network which these nodes belong to. By analyzing the information, DM can get the attachment point of nodes, which is a <node, port> pair, representing the node and the corresponding service port.
Data aggregation is realized by clustering, and we adopt the multi-hop relaying method to transmit the aggregated data to controllers. Different applications can be obtained by virtualization, and service association of the data plane is performed by constructing a number of attachment points. The control plane is used for transfer management message of one hop to the controller, which also occupies an attachment point. In order to simplify the management and control, we do not classify the attachment points on the data planes and the control planes. In the high-level application, the service port number of the data planes and the control plane is unified, and we utilize the given port number to divide the attachment points. Such a simple separation method simplifies node management, as shown in Table 2.
Port numbers of attachment point.
UASN: underwater acoustic sensor network; QoS: Quality of Service.
TM module
TM is the core module of controllers, which is in charge of maintaining the network topology. It includes how to build the clusters through the underwater acoustic connections among these switches (underwater nodes) and the establishment of the shortest path between switches and the broadcast tree of the network topology and so on.
TM is utilized to confirm the connection between switches. The OFPT_PACKET_OUT message is sent at regular intervals from TM to all switches in the network, which instructs switches to send the link layer discovery protocol (LLDP) message to controllers. When switches receive the OFPT_PACKET_OUT message, they will return it to controllers, and TM will be interested to hear the link entities that exist between switches.
To prevent broadcast storm, TM maintains a broadcast tree. When a controller receives a broadcast message, it polls TM, whether the access port is in the broadcast tree. If so, it instructs the switch to distribute the packet. Otherwise, it discards the packet. Therefore, broadcast packets in the network are forwarded along the broadcast tree only. If the controller receives unicast packets but cannot find a proper path, it will use the broadcast tree to forward the unicast packets.
Link-load monitoring module
Link-load monitoring module (LLM) is responsible for overseeing the load status of all node links of UASNs. LLM will periodically send requests to the switches and obtain information from the requests, then convert them into the network load information needed by the system. Taking distinctive needs of unusual underwater application into account, the monitoring period (MONITOR_INTERVAL) can be designed according to the actual service.
Initially, LLM sends an OFPT_STATS_REQUEST message to all nodes and instructs the underwater nodes to return the current statistic status. After sending the statistics requests to all the nodes, the module starts to wait for these nodes to reply. In order to prevent the problem of too long delay due to network congestion, LLM will only wait for a limited time (the waiting time designed in this article is 2 s).
If timeout is happened, LLM will stop waiting and go to the next round. If the module receives the reply message within the limited time, it will process the reply message, update the corresponding port traffic, and compare the traffic with the bandwidth of the existing link to obtain the throughput ratio, which is used to measure the degree of link congestion. If it does not exceed the restricted time, the module will still wait for the reply message or wait for the next monitoring round. The execution process of LLM is shown in Figure 10.
The flowchart of the execution of link-load monitoring.
DF module
The function of the DF module is tantamount to wait for a packet-in event passively. When the event occurs, it first checks the packet type. If the packet is a broadcast type, DF will check whether the underwater node is in the broadcast tree. If not, it will discard the packet. Otherwise, it sends OFPT_PACKET_OUT message, which means a packet-out event for the node, making it to broadcast the packet.
If the packet is no longer a broadcast type, the forwarding module will find the path assisted by the routing module. Later, it will send the OFPT_FLOW_MOD command to install the stream entry in the path. Then, the OFPT_PACKET_OUT message is utilized to send the packet. The operation flow of DF is shown in Figure 11.
The operating flowchart of the forwarding module.
The routing module
Routing module is responsible for path allocation. Through the information provided by DM, TM, LLM, and DF, the routing module can provide the best path for the packet.
When routing module receives the packet-in event, it will process the packet according to the packet type. If the packet is a broadcast type, the routing module will take advantage of the broadcast tree provided by the TM to broadcast the packet. If it is no longer a broadcast packet, the routing module uses its own routing mechanism to select and install the path, and send the packet. The process of routing module is shown in Figure 12.
The flowchart of the execution of the routing module.
In the data plane, we use hierarchical clustering method to develop the MAC layer. For this reason, we adopt the bionic algorithm to design the related SDN routing protocols in the control plane.
We use ant colony algorithm, genetic algorithm, simulated annealing algorithm, artificial bee colony algorithm, fish swarm algorithm, particle swarm optimization algorithm, geese optimization algorithm, and firefly algorithm, which is extremely active within the field of the bionic algorithm at present, to design the SDN-based routing algorithm of the water acoustic sensor network.
We compare the convergence, real-time performance of various algorithms and hope to be able to establish fast convergent SDN routing protocols for UASNs, which can converge multiple algorithms.
Conclusion
SDN offers a novel solution for UASNs. In this article, an SDN-based solution is proposed to build the architecture of UASNs in big data. The design procedure of the data plane and control plane is described in detail.
In the data plane, we use Rico Board as the development board and design the basic structure of the underwater node. We configure OvS on the node. In the physical layer, SDR is used to achieve baseband processing. We adopt the hierarchical clustering method and node addressing technique for realizing the MAC layer.
In the control plane, we use Jetson TK1 as the hardware platform of controllers and design the core modules of the controller which includes DM module, TM module, LLM, DF module, and the routing module.
Combined with the existing projects, we have completed the tasks of designing the data plane and the control plane. Through the study, we expect to improve the performance of UASNs based on SDN, improve the flexibility and expansibility of its application, and provide important theoretical and applied innovation for the high-performance UASNs.
For the present study, the experimental simulation platform of UASNs is relatively more, and the performance testing and simulation platform for both wired and wireless networks of SDN are also emerging. However, the UASNs based on SDN are still rare.
Currently, we are planning the corresponding management and control system of the application layer. The next step of our work is tantamount to carry out performance testing and experimental simulation platform for SDN-based underwater communication systems.