# A New Intra-Cluster Scheduling Scheme for Real-Time Flows in Wireless Sensor Networks
## 2 Proposed Scheme
### Procedure of the Proposed Scheme  
The proposed scheme schedules the flows from the source to destination node by using three scheduling algorithms, namely IntraSend, InterComm and IntraRecv. In the first scheduling algorithm, the flows are scheduled from a source node to the source cluster head. Cluster heads are scheduled from source to destination in the second scheduling algorithm. Finally, in the third scheduling algorithms, the flows are scheduled from destination cluster head to destination node. As shown in Figure 2, the proposed scheme first initializes the number of flows to each cluster head. Each cluster head knows about the number of incoming and outgoing flows in their cluster. After the initialization of IntraSend scheduling, if the cluster has only incoming flows then the IntraSend scheduling can schedule the flows both in IntraSend and IntraRecv time slots. The cluster can utilize IntraSend time slots and cannot utilize IntraRecv time slots in-case if the IntraSend scheduling have both incoming and outgoing flows. For the InterComm scheduling the flows will be schedule from the source cluster head to destination cluster head. As the cluster head has high transmission power, therefore, it can utilize the InterComm time slots and cannot utilize the IntraSend and IntraRecv time slots. Finally, after the initialization of IntraRecv scheduling if the cluster has outgoing flows then IntraRecv scheduling can utilize both the IntraSend and IntraRecv time slots. Similarly, if the cluster have both incoming and outgoing flows then the IntraRecv scheduling can utilize the IntraRecv time slots and cannot utilize the IntraSend time slots. We first schedule the flows from the source node to the destination node where each intra-cluster will have utilized only their respective time slots and cannot utilize each other empty time slots. The cluster \(H1\) will schedule the transmission \(a{\rightarrow}b\) and \(b{\rightarrow}H1\) of \(F1\) in the slot#1 and slot #5 respectively as shown in IntraSend Scheduling in Table 1. Transmission \(j{\rightarrow}c\) of \(F5\) cannot be scheduled in the slot #1 due to the interference with the transmission \(a{\rightarrow}b\) of high priority \(F1\). Therefore, the transmission \(j{\rightarrow}c\) will schedule in the next time slots of IntraSend time slot #5. For transmission \(c{\rightarrow}H1\) of \(F5\) as there is no interference with higher priority flow so it will be scheduled by \(H1\) in the slot #9. Next cluster \(H2\) will scheduled transmission \(i{\rightarrow}h\) of \(F2\), \(p{\rightarrow}H2\) of \(F3\) and \(e{\rightarrow}g\) of \(F4\) in the slot #1 due to no conflict with transmissions of high priority flows. Transmission \(h{\rightarrow}H2\) of \(F2\) will be scheduled in the slot #5 while transmission g\({\rightarrow}H2\) will be cannot be schedule in the time slot#5 due to interference with transmission h\({\rightarrow}H2\) of F2. Therefore, the transmission g\({\rightarrow}H2\) of F4 will be scheduled in the time slot #9. Next in the InterComm scheduling, the flows from F1 to F5 are scheduled from the source node to the destination node as shown in the following Table 2.  
Figure 2: Cluster-based real-time flows. The proposed IntraSend scheduling system for cluster \(H1\) is shown in Table 4. In Figure 2, cluster \(H1\) has only outgoing flows, therefore, the cluster could use both _NIS_ and _NIR_ time slots for the IntraSend Scheduling. \(F1\) is scheduled first from node \(a\) to \(H1\); thus \(F5\) is scheduled in \(H1\) cluster at time slot #1. Since the transmission _a_\(\rightarrow\)_b_ of \(F1\) and transmission _j_\(\rightarrow\)_c_ of \(F5\) are conflicting with each other, the transmission _a_\(\rightarrow\)_b_ of \(F1\) is therefore scheduled in slot#1 due to high priority. This is interesting, as there are only one incoming flow in cluster \(H1\).