## 4 IoT-Enabled Traffic-Aware Telemedicine Architecture (ITTA)
### Wearable-Device-based Monitoring Algorithm for Edge Device (WDMA-Edge)
\begin{table}
\begin{tabular}{l c c c c c c c c} \hline \hline \multirow{2}{*}{**Timings**} & \multicolumn{2}{c}{**Vehicular Density**} & \multicolumn{2}{c}{**PR**} & \multicolumn{2}{c}{**Audio**} & \multicolumn{2}{c}{**ECG**} & \multicolumn{2}{c}{**Total**} \\ \hline  & & **Low** & **High** & **Low** & **High** & **Low** & **High** & **Low** & **High** \\ \hline Early & 104 & GPSR & Flooding (1 ms) & GPSR (1 ms) & Flooding (36 ms) & GPSR (1 ms) & Flooding (20 ms) & GPSR (1 ms) & Flooding (36 ms) \\ \hline Morning & 517 & GPSR & Flooding (1 ms) & GPSR (4653 ms) & GPSR (2 ms) & Flooding (8881 ms) & GPSR (1 ms) & Flooding (5209 ms) & GPSR (1 ms) & Flooding (4653 ms) \\ \hline Late & 368 & GPSR & Flooding (1 ms) & GPSR (1 ms) & Flooding (137 ms) & GPSR (1 ms) & Flooding (96 ms) & GPSR (1 ms) & Flooding (136 ms) \\ \hline Mid-day & 664 & GPSR & Flooding (15 ms) & GPSR (4632 ms) & GPSR (4 ms) & GPSR (8857 ms) & GPSR (13 ms) & Flooding (5206 ms) & GPSR (15 ms) & Flooding (4632 ms) \\ \hline Evening & 726 & GPSR & AODV (3 ms) & GPSR (343 ms) & GPSR (9 ms) & AODV (459 ms) & GPSR (5 ms) & AODV (5355 ms) & GPSR (3 ms) & AODV (343 ms) \\ \hline Late & 294 & AODV (16) & GPSR (7560 ms) & GPSR (1 ms) & Flooding (22 ms) & Flooding (12 ms) & GPSR (8252 ms) & GPSR (1 ms) & GPSR (8252 ms) \\ \hline Night & 144 & GPSR & Flooding (1 ms) & GPSR (65 ms) & GPSR (2 ms) & Flooding (66 ms) & GPSR (1 ms) & Flooding (46 ms) & GPSR (1 ms) & Flooding (65 ms) \\ \hline \hline \end{tabular}
\end{table} 
Table 8: Low and high delay based on data type and routing protocol in Scenario 1. Figure 6: Delay experienced by each data type in Scenario 1. **Scenario 2**: _Variability of delay with respect to different routing protocols and message types._

Here, GPSR provides a better performance compared to the other mechanisms. However, AODV's performance is also well within the limit required for maintaining acceptable QoS, except during early morning. During early morning, the delay increases to 2.2 s, which is more than twice the accepted limit. If the other times of the day are considered, then AODV is noticed to be a good performer. From the delay results, a pattern is observed in AODV, which corresponds with the vehicular density. It might seem that AODV fares well in conditions of higher density. Figure 8 shows the delay throughout the whole day in the case of Scenario 2 and Table 10 shows a detailed view of delay in this scenario. ECG shows a lower delay 66% of the time compared to PR and audio. #### 5.2.2 Summary of Performance Analysis of Healthcare VANET

Tables 7-10 show the time slot-based results recorded during the simulations. The PLR and delay observed during both scenarios are shown. As discussed earlier, AODV presents a much better PLR during Scenario 2, where additional nodes are present on the road in the form of stationary nodes. The presence of these stationary nodes handles the challenges due to insufficient density of vehicles in many areas. While this helps in improving the PLR, the delay is affected negatively. However, it may be noted that the delay when using AODV is well within the required QoS limit of 1 s (1000 ms), except during the early morning period. Some of our key observations related to PLR and delay in the two scenarios are as follows:

**Scenario 1 (V2V)**_PLR_: None of the routing mechanisms provide a satisfactory result. This may be attributed to the fact that the ambulance moves at a higher speed, and since vehicles move in both directions, a satisfactory route is not found by the ambulance every time. _Delay_: GPSR and AODV give a much better performance compared to flooding. In fact, the performance of GPSR is consistently very good, except during late evening. The delay faced by flooding is at least 50-60 times higher than GPSR throughout the day. AODV also shows around 10 times lower delay than flooding on average. Figure 8: Delay experienced by each data type in Scenario 2. Figure 7: Packet loss ratio (PLR) experienced by each data type in Scenario 2.