## 5 Experimental Results
### Tests in Ideal Static Scenarios
#### 5.3.2 Scenario 1  
This scenario presents the most intense level of channel access contention, since all the SUs are within the transmission range of the PU, as shown in Figure 9a. The linear spatial density, \(\rho_{s}\), is equal to \(0.05\) veh/m, and the total number of SUs is given by \(\rho_{s}z=3\) veh. In Figure 10, the experimental PMF of the number of rebroadcast _DATA_ messages at each SU is shown. As one can observe, the rebroadcasting probability of SUs is strictly correlated to their distances from the PU [see Equation (1)]. Fluctuations around average values of the rebroadcasting probability depend on errors in GPS localization. In Figure 11, the PMF of the hop reception index of _DATA_ messages at each SU is shown. In principle, all SUs should receive all messages directly from the PU, because they are within the transmission range of the latter. Nevertheless, even though some messages might be lost because of channel impairments, they can still be received, as information propagation is guaranteed by the rebroadcasting nature of the IF protocol. For this reason, we found that some _DATA_ messages are received with a hop index equal to \(2\). This proves that probabilistic rebroadcasting adds redundancy, which, in turn, increases the system reliability. Figure 10: Probability Mass Function (PMF) of rebroadcast _DATA_ messages in Scenario 1. Figure 9: Static X-NETAD application testbed: (**a**) Scenario 1, all Secondary Users (SUs) are located in the transmission range of the PU; (**b**) Scenario \(2\), each SU is at the edge of the transmission range of previous nodes. Despite this, there is a chance that a certain message may be lost. In Figure 12, the PMF of the number of missing chunks at a given node, before the first _REQUEST_ round, is shown. It can be pointed out that in this scenario, both \(\mathrm{SU}_{1}\) and \(\mathrm{SU}_{2}\) experience a small number of lost _DATA_ messages (smaller than the \(10\%\) of _DATA_ messages sent), while \(\mathrm{SU}_{3}\) experiences a higher loss ratio, due to the fact that its distance from PU is longer. Moreover, from Figure 12, one can see that \(\mathrm{SU}_{3}\) always misses at least one chunk, while \(\mathrm{SU}_{1}\) and \(\mathrm{SU}_{2}\) sometimes (with a probability higher than \(10\%\)) do not need to send any feedback message. At this point, it is worth investigating which nodes receive and satisfy the largest number of _REQUEST_ messages. For this purpose, in Figure 13, we show the total number of missing _DATA_ chunks requests, received by a given node, and the total number of _DATA_ messages replied by the node as a result of previous requests. According to these results, \(\mathrm{SU}_{1}\) and \(\mathrm{SU}_{2}\) receive the largest number of packet requests. However, the larger number of replies is given by \(\mathrm{PU}_{1}\), since it does not adopt a probabilistic broadcasting protocol (in fact, it satisfies the \(100\%\) of requests). SUs have a much lower satisfaction ratio, which reduces as the distance from the \(\mathrm{PU}_{1}\) rises: this is due to Equation (2) and because a node cannot satisfy a _REQUEST_ for a packet that has not yet been received. Figure 11: Hop index PMF for received _DATA_ messages in Scenario 1. Figure 12: PMF of missing _DATA_ chunks, before the first _REQUEST_ round in Scenario 1. Finally, in Figure 14, the PMF of the traffic updates reception time is shown. It can be observed that, on average, all nodes have a completion time (_i.e._, all the _DATA_ messages of a given archive are received) lying in the interval, [5, 6, 7] s: this means that only one _REQUEST_ message is sent back (we recall that \(W_{\rm req}=5\) s). The exception is represented by \(\rm SU_{3}\), which completes the reception of all _DATA_ messages in more than \(10\) s with a probability around \(0.18\). In order to have a better comprehension of this phenomenon, in Figure 15, the CDF of received _DATA_ messages is shown as a function of the number of _REQUEST_ messages.