# A New Resource Allocation Protocol for the Backhaul of Underwater Cellular Wireless Networks
## 3 Description of UBSI Resource Allocation Protocol
### Protocol Messages and Procedures
#### 3.2.3 Normal Operation Phase  
In the normal operation phase, a UBS sends as much uplink traffic to a UBSC as its backhaul capacity. And it also consistently updates its queue status including the queue length, the packet drop rate, and the resource utilization. A UBS requests an adjustment of its backhaul capacity to a UBSC for two cases: (1) resource under-utilization and (2) queue-overflow due to the lack of backhaul capacity.  
In the case of resource under-utilization (determined by the condition: \(\rho_{i}(n)<\rho_{LIM}\)) where \(\rho_{LIM}\) is the lower limit of resource utilization as a network parameter, a UBS returns a portion of its backhaul capacity to the UBSC. The effects of \(\rho_{LIM}\) on the performance are summarized as follows.  
* As \(\rho_{LIM}\) decreases, the frequency of backhaul capacity adjustment decreases since a UBS will have less probability of the event \(\rho_{i}(n)<\rho_{LIM}\). Thus, it is expected to improve energy efficiency and to have less message overhead, but to deteriorate overall resource utilization, throughput, and packet drop rate.
* As \(\rho_{LIM}\) increases, the frequency of backhaul capacity adjustment increases since a UBS will have higher probability of the event \(\rho_{i}(n)<\rho_{LIM}\). The performance pattern is expected to be opposite to when \(\rho_{LIM}\) decreases. This implies that a performance trade-off exists between these two situations.  
To manage resource under-utilization, a UBS sends an RAREQ message to the UBSC, as illustrated in Figure 4. When the UBSC receives the RAREQ message, it sends an RAACK message to the UBS. Then, the UBSC updates a traffic information table by including new traffic information of the UBS and calculates the backhaul capacity of the UBS as specified in Section 3.1.2. The return of backhaul capacity implies the rise of the reserved capacity of the UBSC, denoted by \(\mu_{e}(n)\), this can be used to help another UBS suffering from the shortage of backhaul capacity. The UBSC sends a RAIS message to the UBS and waits for a RAISACK message as shown in Figure 4.  
Figure 4: Under-utilization case of the normal operation phase. IP: initialization phase; RAREQ: Resource Reallocation Request; RAACK: Resource Reallocation Acknowledgement.  
In the case of queue-overflow (determined by the condition: \(P_{i}(n)>0\)), a UBS experiences the packet drop of input traffic due to the lack of backhaul capacity. In this case, the UBS sends an RAREQ message to the UBSC in order to request additional backhaul capacity, as illustrated in Figure 5.  
When the UBSC receives the RAREQ message, it sends an RAACK message to the UBS and calculates new backhaul capacity of the UBS as specified in Section 3.1.2. The UBSC also determines the required backhaul capacity and compares it to the reserved capacity of the UBSC, i.e., \(\mu_{e}(n)\). Here, the required backhaul capacity is expressed as \(\Delta\mu_{i}(n)=|\mu_{i}(n)-\mu_{i}(n-1)|\) where \(\mu_{i}(n)\) and \(\mu_{i}(n-1)\) are newly determined backhaul capacity and current backhaul capacity of the UBS, respectively. If the reserved capacity of the UBSC is greater than the required backhaul capacity, that is \(\mu_{e}(n)\geq\Delta\mu_{i}(n)\), the UBSC sends an RAIS message and remaining procedures are executed as shown in Figure 5. If the reserved capacity of the UBSC is insufficient to provide the required backhaul capacity, i.e., \(\mu_{e}(n)<\Delta\mu_{i}(n)\), the UBSC broadcasts an RIREQ message to all the UBSs and goes back to the initialization phase, as shown in Figure 6. The remaining procedures are the same as those in Section 3.2.2.  
Figure 5: Queue-overflow and sufficient reserved capacity of a UBSC case of the normal operation phase.  
Figure 6: Queue-overflow and insufficient reserved capacity of a UBSC case of the normal operation phase.