# Flying Real-Time Network to Coordinate Disaster Relief Activities in Urban Areas +
## 5 Real-Time Analysis
### Computing the Scheduling Condition  
In this section we explain how to systematically implement the feasibility test for the proposed FRTN. In this scenario we must consider that the use of mules introduces a transportation delay. Moreover, a mule has to fly from one spot (e.g., the location of a SAR team) to the next one to deliver the received messages and also collect new messages from SAR teams. The time required for doing this operation is usually much higher than the time needed to transmit information using a Wi-Fi protocol.  
For the case of FRTNs, we have to extend the Chetto algorithm to include the maximum delay or worst-case transmission time associated to the stage. We are not analyzing the MAC protocol or routing at this time; rather, we focus on the maximum delay the message may suffer, and thus determine the feasibility of providing real-time message delivery in these networks. As previously mentioned, the message deadlines are modified backwards (beginning with the last stage), and the message release times are modified forwards (starting with the node originating the message).  
Next we present an example that illustrates how the real-time condition is computed. Let us suppose an FRTN deployed after a landslide in order to support communication among three SAR teams that conduct search-and-rescue activities coordinated by an IC. Each team has 10 members and one TWU that acts as gateway to the mule. The network is composed of a set of mules for providing connectivity among the teams and the IC. Each node of an SAR team generates a message report and sends it to the IC every five minutes. These messages are forwarded by the gateway to the mule as soon as possible. Let us assume that each message contains 250 KB (or 2 Mb) of data (e.g., voice messages or pictures), and the bandwidth of transmission link with the TWU is 1 Mbit/s. We assume the messages have a simultaneous release at instant zero. Considering this condition, each message requires 2 s to be transferred from the node to the TWU. With 10 nodes operating with a round robin scheme, the TWU receives all the messages within 20 s; in this case, \(r_{i0}=0\) for all \(m_{i}\). Thus, each message has two hops to reach the IC and an absolute deadline of 600 s.  
Let us suppose the flying time of the mules in the FRTN is 360 s. In the worst case, the flying mules require 60 s to deliver to the IC, the 30 messages collected from the TWU linked to the SAR teams. With these constraints, the available time for transmission is just 180 s. Applying Algorithms 2 and 3 to each message, we have 180 s for the last relative deadline and 160 s for the first one.  
Figure 10(a),b present the \(dbf\) in the TWU and the mules, respectively. In both cases, the load is quite light and more traffic is possible. Figure 10(c),d show the \(dbf\) in both hops when the number of messages being forwarded are tripled, and the results show that the system is still feasible and works within the proposed real-time parameters.  
The previous example represents a simple case with just a few elements in the network. When the FRTN becomes larger and the messages have to do several hops before reaching the destination, additional problems appear (e.g., message routing). These cases should be considered at the moment of doing the real-time analysis of the network.