## 2 Related Work
### Real-Time Protocols  
SPEED [5] is a well-known soft real-time unicast routing protocol that tries to probabilistically satisfy the real-time constraint in a hop-by-hop manner. It estimates the required transmission speed based on the desired time deadline and the end-to-end distance. Each intermediate forwarding node selects a next-hop node only among neighbors satisfying the required transmission speed. In other words, SPEED delivers a packet faster than the required transmission speed by forwarding the packet faster than the required transmission speed in every single hop. This concept is applicable in a wireless multi-hop network where the end-to-end delay is proportional to the physical distance the packet travels, unlike wired networks. Many studies propose variants of SPEED including FRUP and the proposed scheme in this work, FRBP. Multipath Multi-SPEED (MMSPEED) [7] is extended to provide a multipath and multilevel real-time routing protocol. Real-time Power-Aware Routing (RPAR) [8], Scalable Hierarchical Power Efficient Routing (SHPER) [9] and Power-Efficient Multimedia Routing (PEMuR) [10] raise the issue of energy efficiency with the real-time requirement in their respective fields. Fault-Tolerant SPEED (FT-SPEED) [11] deals with the void area problem of SPEED. In addition to unicast, Multicast Protocol for Real-time data Dissemination (MPRD) [12] proposes a real-time multicast protocol that constructs a novel multicast tree with the real-time constraint. Soft real-time protocols, however, cannot guarantee the consistent QoS related to the real-time requirement, but make their best effort. The consequent information of real-time delivery cannot be fed back to upstream nodes, and forwarding nodes discard packets when they do not find appropriate next-hop nodes. The firm-based Real-Time (FRT) model [13] has similar features to both hard and soft real-time model in that it allows for infrequently missed deadlines while the system can survive task failures so long as they are adequately spaced. In the FRT model, the concept of (\(m\), \(k\))-firm real time is well defined, that is at least \(m\) messages among any \(k\) consecutive messages have to meet their real-time constraint from a real-time data stream. Figure 1 shows an example of state transition for the (2, 3)-firm real-time requirement. Each state represents that recent \(k\) messages meet or miss the deadline. For example, M\(\mathrm{M}\mathrm{m}\) denotes the state where the most recent message missed its deadline and the two before it met their deadlines. With this state information, FRT mediates among multiple real-time streams. Each stream maintains the recent history, a state in Figure 1, and the system gives priorities to streams according to their states. If a stream is in a failing state (i.e., one of the shaded states in Figure 1), then a high priority is assigned to the stream. FRUP [6] applies the (\(m\), \(k\))-firm model to real-time multi-hop unicast. In other words, FRUP uses the (\(m\), \(k\))-firm requirement to provide a consistent guarantee of real-time data delivery in multi-hop networks, whereas FRT uses it to mediate among multiple real-time streams in single-hop networks. FRUP tries to satisfy their (\(m\), \(k\))-firm real-time requirement by adjusting the data path, which reselects forwarding nodes by using two state indicators, DBP and LSI. DBP is an integer value that denotes the state of current real-time performance. A positive DBP value stands for meeting the (\(m\), \(k\))-firm requirement, while a negative DBP means the real-time failure state. DBP is calculated by the destination and fed back to upstream nodes and the source. FRUP also proposes LSI, which is calculated by each forwarding node to indicate the local condition of transmission. With two indicators, DBP and LSI, FRUP can perform a prompt fault recovery mechanism working at each forwarding node. FRUP however cannot be simply applied to network broadcast.