## 5 Performance Evaluation
### Tuning of the Multihop P2 MP Settings
#### 5.1.2 Varying MAC-Level Settings at the eNB  
In the following, we assume that the target area is embedded in the message, and Trickle suppression is enabled.  
We first discuss the tradeoff involved in the choice of the MCS at the cell level. In Figure 15, the \(x\) axis reports the mean of the total number of RBs per broadcast, whereas the \(y\) axis shows the mean reception delay of UEs within the target radius. Resources are allocated via SRA, and the points represent the CQIs (which determine the MCS). As expected, the number of allocated RBs decrease with the CQI. In fact, higher CQIs correspond to more performing MCSs, hence to more bits per RB. A message transmission occupies 11 RBs with CQI 3, and one RB with CQI 15. However, using larger CQIs increases the number of hops, hence the latency. This is evident in the two segments 7-9 and 10-15, where the same number of RBs is used, but larger latencies are obtained, since the reception range is reduced. However, latency also increases with too small CQIs. As previously discussed in Section 3, the probability of correct reception decreases with the number of RBs employed, due to frequency-selective fading, all else being equal. The MCS corresponding to CQI 7 strikes a good tradeoff between latency and resource occupancy. While the absolute values in the graph are a function of the target radius, qualitatively similar results (although on different scales on both axes) are obtained when the radius is varied. From now on, CQI 7 is used in the simulations.  
We now evaluate the two resource allocation strategies. Figures 16 and 17 report the average and the 95 th percentile of the delay, for different target radiuses, achieved with SRA and ARS. We configured ARS with four different patterns, consisting of 20 RBs allocated at periods of 5, 10, 20 and 50 ms respectively. When the period is small enough (i.e., 10 ms or below), ARS is faster than SRA, since the time to the next transmission opportunity is smaller than the duration of a RAC handshake. This comes at the price of higher resource consumption: ARS consumes many more resources, which go unused when there is no traffic. For instance, with a period of 5 ms, one eNB must reserve 8% of its resources for P2 MP D2D broadcasts (still assuming a 10 MHz deployment). SRA, instead, only uses the RBs requested by the UEs, which are around 130 per broadcast over a 1000-m radius (involving 5 eNBs), also factoring in BSR transmissions, as shown in Figure 18. A back-of-the-envelope computation shows that, since UEs send one broadcast per second, then the resource occupancy of SRA is less than 130 RBs per second in the whole network, against 10 thousand for ARS at 5 ms.  
Figure 15: Average allocated RBs and average delay as a function of CQI (Channel Quality Indicator).  
Figure 16: SRA vs. ARS, average delay.  
Figure 17: SRA vs. ARS, 95 th percentile of delay.  
Figure 18: SRA, avg. allocated RBs per broadcast.  
Figure 19 reports the percentage of UEs that actually receive the message, which is close to 100% and fairly insensitive to the target radius. Note that the last result is partly due to the spatial reuse policy, which allows an eNB to schedule more than one D2D transmission on the same time/frequency resources.  
To put the above results into context, we observe that the average broadcast latency with SRA and a radius of 800 m is around 50 ms (see Figure 16), and the corresponding delivery ratio is above 99% (Figure 19). Compared to [25], which addresses broadcasts in an 802.11-based MANET in a somewhat similar scenario (although similarities between such different technologies as 802.11 and LTE are to be taken with a pinch of salt), we note that the latencies are similar, but our delivery ratio is remarkably higher (99% against 90-98%), despite the fact that LTE relies on much smaller UE D2D transmission radiuses (100-150 m against 500 m in [25]).  
From now on, we use SRA as the resource allocation scheme, since it achieves a good tradeoff between latency and resource consumption.