## 4 Multihop D2D Broadcasting
### Resource Allocation in the Network  
As discussed in Section 2, the eNB controls resource allocation, and may use either SRA or ARS. We now compare the two approaches, highlighting their pros and cons in the context of multihop relaying, also taking into account that multicell relaying may be required. As far as latency is concerned, using SRA requires each UE to undergo one RAC handshake per transmission. As shown in Figure 2a, this handshake takes a 10 ms delay in the best of cases, i.e., when the eNB issues grants immediately. If RAC collisions are experienced, or the eNB delays scheduling because the UL is congested, the per-hop delay may be even larger. On the other hand, with ASR, a UE can send a message as soon as a transmission opportunity becomes available, without the need of going through a RAC/BSR handshake. Thus, with ARS the maximum scheduling delay is given by the resource allocation period \(T\). Using ASR, especially with small periods, allows faster access to the medium. However, this entails allocating a large share of resources to P2 MP D2D transmissions statically, thus wasting resources when these are not required, and preventing standard UL communications to use them. Therefore, with ASR, latency is traded off for resource efficiency. The two allocation schemes differ greatly regarding collisions. When using SRA, the only possible collisions are those of simultaneous RAC requests at the eNB. However, these are quite unlikely. The LTE-A standard requires UEs to select a preamble among 64 possible choices. Simultaneous RAC requests with different preambles do not collide. Furthermore, when a RAC request is not answered by the eNB (either because of a RAC collision or because the eNB does not have resources to spare), the UE simply sends it again after a backoff time. Thus, RAC collisions do delay the broadcast process, but they also desynchronize relaying UEs, which is a positive side effect. With SRA, data transmission on the SL is instead interference-free, since the eNB generally grants SL resources to one transmitting UE at a time. The only exception to that rule is when the eNB exploits a frequency reuse scheme (such as the one in [32]), in which case faraway, non-interfering UEs may be granted the same RBs simultaneously. However, this happens exactly because the eNB knows that they will not interfere with each other. If, instead, ARS allocation is used, UEs claim RBs on the SL for their own transmission without a central scheduling and without their neighbors knowing, hence the intended receivers face unpredictable interference. The latter can be mitigated by having the UEs select at random which RBs to use, and by dedicating more resources to SL transmissions, which decreases the efficiency. Moreover, ARS allocation is periodic, hence it implicitly forces synchronization among groups of UEs: all UEs whose application requests a relay in the same ARS period will end up accessing the SL at the next ARS opportunity, hence increasing the likelihood of collisions. This would happen at each hop. Furthermore, since a sender does not know if collisions have occurred, the only possible countermeasure to increase the reliability of a transmission would be to retransmit the same message more than once. As already discussed, a target area may include more than one cell, as shown in Figure 6. This poses the problem of coordinated resource allocation among neighboring cells. In fact, if each cell allocates SL resources autonomously, cell-border UEs will be subject to interference from UL transmissions in the neighboring cells, hence they may be unable to receive P2 MP D2D transmissions. This problem is likely to affect more heavily dense networks [33], where cells are smaller. If the network uses ARS allocation, coordination is fairly easy to achieve: all it takes is that neighboring cells use the same allocation pattern. If, instead, SRA is used, resources are allocated on demand, hence the eNB must share information regarding their allocation using the X2 interface.