## 4 Performance Evaluation
### Simulation Results  
The SDSR of the proposed scheme and that of the MK-AG routing protocol (denoted AG) are compared in Figures 3 and 4. Two respective (_m,k_)-firm streams were considered for application. Figure 3 shows the results of (2,3) as a more strict requirement than (2,5) in Figure 4. For each application, we compare three different (_m,k_)-firm streams. In other words, for each (_m,k_)-firm stream, three respective streams are composed. For example, the (3,4)-firm session stream consists of the set of {(3,4),(6,8), (9,12)}. Following the same approach, all sessions of the (_m,k_)-firm streams are defined as the set of three (_m,k_)-firm streams according to Equations (1) and (2). Figures 3 and 4 show that the SDSR of the strict requirement is lower than that of the less strict requirement. The same pattern is observed for the session requirements. That is, the highest SDSR is obtained for (3,6) session traffic in the (2,5)-firm application. In addition, the SDSR of the proposed scheme is higher than that of the MK-AG routing protocol. In Figure 3, the difference between the two schemes is larger where a strict requirement is demanded. The main reason for this gap is the adaptive routing protocol. Even though MK-AG takes into account the speed for real-time delivery, the delivery ratio on the link, and the remaining energy, it occasionally happens that a different path is not selected according to the DBP value. This implies that a different path is not selected when the multi-criteria approach is followed. In addition, the selection of a different path by the static comparison matrix in the AHP is time consuming. On the other hand, the proposed scheme makes use of multiple path selection according to the DBP value. Thus, because path selection is accomplished whenever the DBP value becomes negative, higher SDSR is achieved. The other important factor that affects the performance of the application is to take \(DBP_{ObjID}\) in \(DBP_{ObjID}\). Because MK-AG only focuses on the session requirement, its compliance with the application requirements is less successful. However, the proposed scheme overcomes this problem by assigning a higher priority to \(DBP_{ObjID}\) in \(DBP_{ObjID}\) than \(DBP_{i}\) in \(S_{i}\) in Algorithm 1; hence, it promptly meets the requirement of the application according to \(DBP_{ObjID}\). In addition to using two schemes, adaptive traffic handling is performed according to the strict requirement. By using these diverse scenarios, we found that adaptive traffic handling was not invoked  
Figure 3: SDSR for (2,3)-firm application. in too many cases, as would be expected for the strict (_m,k_)-firm requirement. More specifically, the adaptive traffic handling algorithm was executed 25 times in the (5,6)-firm session in the (2,3)-firm application, whereas this was not observed to occur in the (3,6)-firm session in the (2,5)-firm application. Among the 25 executions, five requests to change the packet size were detected. On the other hand, because the MK-AG routing protocol does not include an algorithm to adjust the traffic, more packets would be able to miss the deadline even though the shortest path is established. The effect of the traffic-handling algorithm is highlighted when strict requirements are used. Usually control overhead may affect SDSR because high volume of control messages make network delay long. In the proposed scheme, control message includes RREQ and RREP during Path_Search_Probing(i,sink) procedure in Algorithm 1. Furthermore, a sink node periodically sends control message to a source node with \(DBP_{ObjID}\) and \(DBP_{i}\). The former has negative effect in SDSR because it is based on the broadcast. However, its impact to SDSR is not great because the path search procedure is performed at the initial stage. Furthermore, control message between sink and source node is transmitted in a unicast way. Thus, its impact to SDSR is also limited. Similarly, control overhead of MK-AG is limited to path search and periodical reporting.