# A Novel Self-Forming Virtual Sub-Nets Based Cross-Layer MAC Protocol for Multihop Tactical Network
## 4 Working of Algorithm
There are cases in which many nodes are not involved in any transmission; they may run the control phase at frequency \(f_{0}\) parallel to the data transmissions. The proposed VSCL-MAC cross-layer design embraces distributed intelligent algorithms, where nodes can discover communication routes without any upper-layer protocol support and perform simultaneous multihop data transmissions in a multichannel environment. In tactical communication, radios have a limited amount of data; therefore, they consume fewer time slots in data transmission. ## 5 Finite State Machine for Control and Data Transmissions

We use a finite state machine (FSM) to implement and analyze the working of VSCL-MAC design. The proposed cross-layer MAC design describes the same set of states, events, conditions, and actions required to operate FSM. The control and data packet transmissions, transition details, and required actions are shown in Figure 16.

The FSM defines the interaction between all conceivable states, events, and actions for the transmit and receive path. The states of FSM have the following denotations. * IDLE: there is no control or data message to transmit. * LISTEN: neighbor SDR(s) overhear control messages. * WAIT REQ_ACK: TX SDR is waiting for the ACK of the REQ message it sent. * WAIT STATE: SDR is waiting for the control period to be over and starts data transmission upon timeout. * TRANSMIT DATA: the control period is over, and SDR sends data on the selected frequency and scheduled data slots. The events that take place in FSM have the following denotations:

* DATA_available: SDR has data to transmit, available in its queue. * REQ_received: SDR received a REQ message. * REQ_received (to relay): SDR received a REQ message that needs to be relayed. * REQ_ACK_received: the ACK of the sent REQ is received at SDR. * REQ_ACK_timeout: no ACK is received till the timeout. * Overheard_REQ, REQ_ACK, BRDSCT of neighbor(s): the neighbor(s) of SDR overheard control packets transmission. * CTRL_frames_completed: the transmission of all control frames is completed. * DATA_transmitted: SDR has transmitted the data message. Figure 15: Time slot and frequency distribution of sub-net’s transmissions. The FSM remains in an idle state until an event is raised to start the state transition process. Figure 16 illustrates that when an event DATA_available is set, Send_REQ action is performed that combines with the actions of sending NBR_MAP and TRANS_table. These actions are taken when the FSM goes from the IDLE state to WAIT REQ_ACK state. Next, FSM examines for either REQ_ACK_received or REQ_ACK_timeout event, and the transition depends on which event occurred. If an event REQ_ACK_timeout is perceived, then the FSM goes to the IDLE state, where it waits for data to be available and again sends the REQ message. After the REQ_ACK_received event, the actions Update_TRANS_table and Check_NBR MAP are executed, and FSM goes into the WAIT STATE. If an event CTRL_frames_completed that identifies the completion of control frames transmission has taken place, then Start_data_sending action is enabled and it triggers two more events Select_\(f_{h}\) and Schedule_data_slots to go into the TRANSMIT DATA state. When FSM executes the event DATA_transmitted, it transits to the IDLE state by performing actions Release_\(f_{h}\), data_slots and Clear_TRANS_table. It also deals with the event Overheared_REQ/REQ_ACK or BRDCST for those SDRs that are neighbors of the TX SDR and transit from IDLE to LISTEN state. At this state, the actions of Update_TRANS_table and Check_NBR MAP are performed. When an event of REQ_received occurs while being in the IDLE state, then the action of Send_REQ_ACK is executed along with Update_TRANS_table and Check_NBR_MAP actions. At this event, the FSM goes from an IDLE state to WAIT STATE. The rest of the state transition diagram can be inferred similarly.