# A Novel Self-Forming Virtual Sub-Nets Based Cross-Layer MAC Protocol for Multihop Tactical Network
## 4 Working of Algorithm
Each SDR has the next-hop information for the transmission perceived from its NBR_table, as shown in Figure 8. In the control unit, all SDRs send control messages to exchange intended transmissions in their respective time slots, as shown in Figure 9. Suppose \(N_{1}\) has data for \(N_{7}\), sends REQ to its one-hop neighbor \(N_{3}\), and is overheard by all its neighbors. \(N_{1}\) knows the path (\(N_{1}  
_Corollary 01_: REQ packets contain the information of the source, destination, and next-hop nodes. The neighbors of SDR can extract the 1-hop transmission directly from fields (source\(\rightarrow\)next_hop). Hence, it is not shared in the TRANS_table field of the control message, i.e., \(N_{1}\) only shares 3\(\rightarrow\)7 in its REQ packet. The REQ packet receiver can add further path information itself, if available in its NBR_table, e.g., \(N_{3}\) adds 1\(\rightarrow\)3 from the REQ packet and 3\(\rightarrow\)7 from its NBR_table. This enables SDRs to send more intended transmissions as maximum transmissions shared in a control packet is equal to \(M\). In the next time slot, \(N_{2}\) sends the REQ message to \(N_{3}\) for \(N_{9}\) that is at 3-hop away. \(N_{2}\) has confirmed 2-hop path information (2\(\rightarrow\)3, 3\(\rightarrow\)1) in its NBR_table but does not know whether \(N_{1}\) is directly connected to \(N_{9}\) or not. Therefore, it only adds a 2-hop path in its TRANS_table and sends the REQ message to \(N_{3}\). All the neighbors of \(N_{2}\) update their TRANS_table as shown in Table 5. \(N_{3}\) receives the REQ, knows the path to reach at \(N_{9}\), and adds 1\(\rightarrow\)9 in its TRANS_table later shares it with its neighbors in the next control slot. The other neighbors add the same information as \(N_{2}\) as they do not have the transmission route in their NBR_table. In the third time slot, \(N_{3}\) has data for \(N_{2}\) and, at the same time, has two more transmissions to relay in its queue (3\(\rightarrow\)7 and 3\(\rightarrow\)1). In this condition, \(N_{3}\) sends a combined_REQ message with destinations and next-hops, as shown in Figure 11. This reduces the number of control packets; otherwise, every time, SDR consumes one slot for each REQ message. _Corollary 02_: The size of the combined_REQ packet is same as that of a REQ packet because the TRANS_table field can now hold \(M/2\) transmission entries. Therefore, it can send more than one REQ message in a single packet. _Corollary 03_: If an SDR does not have REQ or REQ to relay, then it can use the slot to send REQ ACK if it has already received the request for it. In another case, SDR has a relay REQ and REQ_  
and transmits other packets in the next control frame slot. In neither case, SDR sends a BRDCST packet to synchronize both tables with updated information. Similarly, \(N_{4}\) sends REQ to \(N_{5}\), which should be traversed from \(N_{6}\). \(N_{5}\) sends REQ to \(N_{6}\) and \(N_{6}\) relays the REQ of \(N_{4}\) to \(N_{5}\) in their time slots, whereas \(N_{7}\) has no REQ and sends REQ_ACK to \(N_{3}\), according to Corollary 03. The first control frame contains control transmissions of all SDRs, as shown in Table 6.  
The second control frame contains REQ (direct and relayed), REQ_ACK, combined_ACK, and BRDCST packets transmission. In the sixth slot of the frame, \(N_{6}\) sends combined_ACK for both REQ messages received from \(N_{4}\) and \(N_{5}\) previously, as shown in Table 7.  
The third and last control frame of discussed topology contains REQ_ACK of \(N_{1}\) and \(N_{3}\). In contrast, others transmit a BRDCST message to share those transmissions which were not sent previously, necessary to synchronize TRANS_table of all nodes, as shown in Table 8.  
After the transmission of all control frames, each SDR has all the intended transmissions in its TRANS_table, as shown in Table 9 (due to the size of TRANS_table, transmission with same receivers are combined and written in ascending order).