## 4 Proposed Routing Protocol
### Packet and Routing Table Structures  
The APC-EEDBR routing protocol defines six packet types: Data Packet, Beacon Packet, Acknowledgment (ACK) Packet, Void Notification Packet, Probe Packet, and Probe Reply Packet. Each serves a specific function during the lifecycle of the network. Beacon packets are used in the initialization phase for neighbor discovery and path setup; data and ACK packets ensure reliable data transmission; probe, probe reply, and void notification packets contribute to link assessment, relay selection, and route adjustment. The packets included various fields related to energy, depth, neighborhood, and link quality. The meaning of each field is shown in Table 1, and the composition of each packet type is summarized in Table 2.  
In the APC-EEDBR, packet structures are designed to suit the constraints of underwater sensor networks, including low bandwidth, high latency, and energy sensitivity, ensuring efficient communication with minimal overhead. Beacon packets periodically broadcast the node status to support neighbor maintenance and topology awareness. Data packets carry service content, along with routing and node information, for accurate forwarding. ACK packets confirm data reception, helping to avoid retransmissions and track energy use. The probe and probe reply packets obtain the real-time neighbor status to improve the path selection accuracy. Void notification packets report the forwarding failures and trigger route adjustments. Each packet type has a clear role in collectively supporting routing stability and adaptability. The routing and neighbor tables together serve as the decision-making core of the protocol. The routing table stores the paths to the destination nodes, while the neighbor table tracks information about the adjacent nodes. Their integration enables efficient and adaptive routing in dynamic underwater environments. The routing table (Table 3) maintains essential routing information to support energy-aware and stable path selections. It helps nodes evaluate candidate paths based on energy distribution, link reliability, and network load balance, thereby improving routing efficiency and extending the network lifetime. The neighbor table (Table 4) contains detailed information about each neighbor, which is essential for evaluating the relay suitability and communication quality. Both the routing and neighbor tables are updated in real time through periodic control packets or upon \begin{table}
\begin{tabular}{c c} \hline \hline
**Field Name** & **Description** \\ \hline Type & Packet type field to distinguish among beacon, data, ACK, etc. \\ SID (Source ID) & Unique identifier of the sending node \\ RID (Receiver ID) & Unique identifier of the receiving or target node \\ PN (Packet Number) & Packet number to identify a specific packet in a transmission \\ RE (Residual Energy) & Current residual energy of the node, used for energy-aware routing \\ DEP (Depth) & Node depth information for hierarchical determination and spatial localization \\ ND (Neighbor Density) & Number of neighboring nodes within the communication range \\ ARE (Average Residual Energy) & Average residual energy of neighboring nodes \\ LSF (Link Stability Factor) & Factor used to evaluate link reliability \\ PL (Power Level) & Power level used when transmitting data \\ Load & Actual payload field containing the data to be transmitted \\ \hline \hline \end{tabular} Note: These abbreviations (e.g., SID, RE, and LSF) are used throughout the packet formats in Table 2.  
\end{table} 
Table 1: Field names and their meanings. \begin{table}
\begin{tabular}{c c} \hline \hline
**Packet Type** & **Fields Included** \\ \hline Beacon Packet & Type, SID, RE, DEP, ND, ARE, LSF \\ Data Packet & Type, SID, RID, PN, RE, DEP, ND, ARE, LSF, PL, Load \\ ACK Packet & Type, SID, RID, PN, RE, DEP, ND, ARE, LSF, PL \\ Probe Packet & Type, SID, RE, DEP, ND, ARE, LSF \\ Probe Reply Packet & Type, SID, RE, DEP, ND, ARE, LSF \\ Void Notification Packet & Type, SID \\ \hline \hline \end{tabular}
\end{table}