# A New Resource Allocation Protocol for the Backhaul of Underwater Cellular Wireless Networks
###### Abstract
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 Initiative)\" 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.