Nowadays, the range of underwater applications is getting wider; those applications include not only underwater surveillance and enemy detection for tactical purpose, but also observation of underwater ecosystem, development of underwater natural resources, underwater plants construction, underwater robot manipulation, and Internet of underwater things (IoUT) for commercial purposes [1
]. In order to manage these applications and to obtain a huge volume of collected data, an underwater communication network is as necessary as a terrestrial communication network [4
]. In the view of accessibility, economic feasibility, network expandability, and applicability, it is preferable to build an underwater wireless network to an underwater wired network. Additionally, an acoustic frequency is mainly employed as a communication medium because acoustic signals support longer communication range and experience less signal attenuation than radio-frequency (RF) and optical signals in spite of its limited bandwidth (e.g., tens of kHz) and long propagation delay (
order higher than RF signals) [5
An underwater sensor network is a representative underwater wireless network, where multiple sensor nodes form a cluster. The data from a sensor node in one cluster is transmitted to that in another cluster by exchanging data between cluster heads. An underwater sensor network is advantageous due to its simplicity to build a network infrastructure, application versatility, and network expandability. However, this network type may suffer from severe latency, packet loss, and resource under-utilization induced by the bottleneck (e.g., due to heavily loaded traffic) occurred at a cluster head [7
]. Moreover, message overhead can increase due to transferring routing messages among cluster heads and frequent re-routing owing to the mobility of nodes [8
In order to reliably operate underwater applications and to overcome the weakness of an underwater sensor network, an underwater cellular wireless network (UCWN) was considered in the previous studies [8
]. In a UCWN, an underwater base station (UBS) located at the center of a cell controls underwater terminals (UTs) residing in its cell, which is very similar to a terrestrial cellular wireless network (TCWN) [10
]. In one underwater cell, a UBS collects data from all the UTs, and forwards the data to a UBS controller (UBSC) which is located on the water surface and controls multiple underwater base station (UBSs). A UBSC can be fixed (like a buoy) or mobile (like a command ship) dependent upon applications. The communication link between a UBS and a UBSC is important because it is responsible for exchanging both control signaling and data traffic. This link is very similar to the backhaul link between a base station and a base station controller in a TCWN. Thus, it can also be regarded as a backhaul link between a UBS and a UBSC. A UCWN can improve performance in terms of latency by avoiding multi-hop communications, thus enhancing network efficiency [11
]. Furthermore, a UCWN may increase the communication reliability in harsh underwater environments where frequent transmission failure due to high bit error rate (BER) occurs and network traffic is heavily loaded caused by the advance of underwater applications [11
Previously, several studies for a UCWN have been done since the introduction of the concept of a UCWN in literature [8
]. The studies to design the topology of a UCWN was done in [11
]; a cell radius, spatial frequency reuse pattern, the available number of UTs per cell, and the capacity per cell are mathematically derived by considering the given bandwidth and signal-to-interference ratio (SIR). A few guidelines targeted for planning a UCWN are also suggested via extensive simulation works. In [15
], a collision-free medium access control (MAC) protocol was proposed for a UCWN to completely avoid collisions among UTs located in a cell; a UBS sets UTs’ tier according to their distance from the UBS, and manages UTs’ transmission scheduling corresponding to the tier.
In addition, a resource allocation protocol, which determines the backhaul capacity of UBSs being applied to its backhaul link, was primarily proposed for a UCWN in [16
] by considering following remarkable differences between the backhaul link of a UCWN and that of a TCWN.
Traffic volume. The amount of the uplink traffic (i.e., from a base station to a base station controller) is much larger than that of the downlink traffic (i.e., from a base station controller to a base station) in a UCWN, which is completely contrary to a TCWN.
Performance. The transmission rate of a backhaul link of a UCWN is much lower than that of a TCWN. Besides, the latency of a backhaul link of a UCWN is much higher than that of a TCWN.
The differences mentioned above and asymmetrically increasing traffic of UBSs due to applying various underwater applications result in the traffic congestion in backhaul links of a UCWN. The protocol in [16
] helps a UCWN deal with this bottleneck occurred at the backhaul link; a UBSC adaptively allocates the backhaul capacity of a UBS being proportional to its input traffic (i.e., the data collected from UTs in its cell), and thus improves backhaul transmission efficiency and fairness. To do this, a UBSC allocates several time slots per frame to UBSs for their backhaul capacity based on time division multiple access (TDMA). Three input traffic values are considered: current traffic, accumulated mean traffic, and the maximum traffic. Also, two methods that a UBS sends its input traffic to a UBSC are employed according to whether the transmission period is fixed or not: fixed period and adaptive period. It was shown via simulations that sending accumulated mean traffic with adaptive period mostly guarantees the best performance [16
In spite of its novelty, the resource allocation technique described in [16
] still needs to be enhanced considering the following aspects.
The ability to manage drastic change of uplink traffic. As the protocol in [16
] was designed under the assumption that the UBSC capacity is enough to manage the input traffic from all the UBSs, it can be partially efficient when the uplink traffic of all the UBSs does not change quickly or does not show any bursty nature (which can be caused by mobile UTs such as autonomous underwater vehicles (AUVs)). However, in practice, it is possible that the uplink traffic of a UBS may abruptly increase due to burst traffic caused by mobile UTs or the rise of traffic gathered from (fixed) UTs in its cell. This can make a UBSC experience a shortage of backhaul capacity, and consequently it suffers from long latency and packet drops by queue-overflow. Thus, a more responsive resource reallocation reflecting traffic condition, that the uplink traffic of each UBS changes fast or the outbreak of burst uplink traffic occurs frequently, is strongly required.
The way to readjust the backhaul capacity of a UBS. In [16
], a UBSC collects traffic information from all the UBSs, calculates their backhaul capacity, and periodically reassigns their backhaul capacity by informing them of their new backhaul capacity. In other words, all the UBSs must communicate with a UBSC for the readjustment of their backhaul capacity at the same time. This is quite inefficient to the backhaul link of a UCWN suffering from both low transmission rate and high latency because the message overhead for reallocation of the backhaul capacity is quite large. Thus, considering low transmission rate and high latency of the backhaul links, a more efficient method to reassign the backhaul capacity of UBSs is necessary.
Interoperability. As there are diverse modulation and coding schemes (MCSs) and multiple access schemes such as FDMA (Frequency Division Multiple Access), TDMA, CDMA (Code Division Multiple Access), and OFDMA (Orthogonal Frequency Division Multiple Access) for different underwater communication links and ranges, a resource allocation protocol, which is interoperable with diverse MCSs and multiple access schemes, is required.
Hence, it is necessary to design a new resource allocation protocol for the backhaul of a UCWN which considers more realistic underwater communication environments.
In this paper, we propose a novel resource allocation protocol for a UCWN by considering the characteristics of an underwater backhaul link as stated above. It effectively determines the backhaul capacity of UBSs responding to both fast uplink traffic change and burst traffic cases with a much smaller amount of message overhead, which is required for the reallocation of the backhaul capacity. In our approach, all of the capacity of the UBSC is not assigned to all the UBSs at once, being proportional to their uplink traffic. Instead, the UBSC determines the backhaul capacity of all the UBSs considering the upper limit (or the pre-determined maximum capacity) as well as uplink traffic of each UBS. More specifically, the UBSC calculates the backhaul capacity of each UBS proportional to the amount of input traffic of the UBS. If the calculated backhaul capacity of a UBS is greater than pre-determined upper limit, then the backhaul capacity of the UBS is determined as the upper limit. Otherwise, the backhaul capacity of the UBS is determined as the calculated value. So, some portion of the total backhaul capacity will not be allocated to the UBSs, and it is reserved at the UBSC. This reserved backhaul capacity is used to provide additional backhaul capacity to the UBS which requests more backhaul capacity due to abrupt traffic increase from UTs or burst traffic from mobile UTs (such as AUVs). In general, a UBS requesting more backhaul capacity may have already experienced packet drops due to queue-overflow. On the other hand, when a UBS uses lower backhaul resource than its allocated backhaul capacity, it returns some portion of its capacity to the UBSC, which will be added to the reserved backhaul capacity of the UBSC. And the reserved capacity can be used to support any UBS requesting additional backhaul capacity later.
In the conventional resource allocation scheme in [16
], the UBSC always initiates the backhaul resource allocation and determines the backhaul capacity of each UBS. In this scheme, the UBSC must communicate with all the UBSs to collect information for the reallocation. On the contrary, in our scheme, a UBS can initiate backhaul resource reallocation. Therefore, we call it “UBSI (UBS Initiating)” resource allocation protocol. Moreover, the UBSC communicates with only one UBS for resource reallocation if the reserved backhaul capacity in the UBSC is larger than the requested backhaul capacity of the UBS. In other words, our approach has much less resource reallocations, wherein the UBSC communicates with all the UBSs, than the conventional approach. Thus, our approach is expected to reduce the message overhead for the resource reallocation, and can be efficient for underwater communication links with low data rate and high latency.
Besides, in terms of interoperability, our UBSI resource allocation protocol determines the backhaul capacity of a UBS as a ratio to total backhaul capacity, which is interoperable with any multiple access technique.
In order to analyze the performance of our new resource allocation protocol, we perform system level simulations (SLSs) under the environments consisting of one UBSC and multiple UBSs. We consider four performance measures: average packet drop rate, average resource utilization, average message overhead, and reserved backhaul capacity in the UBSC. In our SLSs, these four performance measures are investigated with respect to the average input traffic and the average burst traffic of UBSs by considering two scenarios:
Scenario 1: varying the upper limit (or maximum) of the backhaul capacity of a UBS,
Scenario 2: varying the lower limit of the resource utilization threshold where a UBS returns unused backhaul capacity when its current resource-utilization becomes less than this lower limit.
For each scenario, we provide a summary of our SLS results and analysis, and an operational guideline for the backhaul resource allocation in the UCWN using the proposed UBSI protocol.
The remaining part of this paper is organized as follows. In Section 2
, the structure of a considered UCWN is described. In Section 3
, a new resource allocation protocol is specified in detail, including its queue model, the way to determine the backhaul capacity of a UBS, and the corresponding protocol messages and procedures. In Section 4
, the performance is investigated via extensive system level simulations considering two scenarios. Finally, in Section 5
, we conclude this paper.