## 4 Multihop D2D Broadcasting  
In the following, we consider an LTE-A system composed of several cells, where UEs are D2D-enabled. UEs run applications that may generate messages (e.g., vehicular collision alerts) destined to all other UEs running the same application, within an arbitrary target area. Our problem is to reach as many interested UEs in the target area as possible, using only P2 MP D2D transmissions, relayed by UEs themselves, using as few resources as possible. The system model is shown in Figure 3, where the shaded UE originates a message that has to be delivered to all the UEs within the circle. The solid arrows represent the first P2 MP D2D transmission, and the dashed ones represent transmissions relayed by UEs in the first-hop neighborhood of the originating UE. A UE that perceives collisions in the same time/frequency resources will still attempt to decode the message received with the strongest power, i.e., it will exploit the so-called capture effect, typical of wireless networks [26].  
In multihop D2D broadcast, the eNB does not participate in data plane transmissions, i.e., it does not send data packets. Data-plane transmissions are instead performed by the UEs themselves, on behalf of the applications running on them. However, the eNB still controls the resource allocation, hence can affect the performance of the broadcast. We only assume that the eNB allocates resources for generic D2D transmissions using standard-compliant means (to be discussed later in this section), unaware of the fact that multihop relaying is going on for D2D transmissions, or of specific application requirements (e.g., deadlines, target areas, etc.). In other words, we assume minimal, standard-compliant support from the infrastructure.  
Multihop D2D broadcasting requires that applications decide which UEs to target and how to relay messages, whereas the LTE-A network allocates resources for D2D transmissions to allow multihop relaying. This implicitly assumes a trusted environment, where UEs behave cooperatively. Security is notoriously difficult to enforce in broadcast networks, and we refer the interested reader to [27] for a discussion of security issues in D2D communications in particular. Regarding cooperation, UEs may be inclined to behave selfishly to save battery or to avoid increasing traffic volumes in pay-per-use plans. On one hand, suitable incentives and reputation-based schemes, such as those discussed in [28; 29], could mitigate the problem. On the other hand, MDB services are supposed to be used also by embedded applications (e.g., application software running on cars), which have access to an energy source (e.g., the vehicle's battery) and are not under the control of the end user (i.e., the car owner or pilot). In this last case, manufacturers would clearly benefit from coding cooperative behaviors in their embedded software. Hereafter, we assume that the UEs running MDB behave cooperatively. In Section 5 we evaluate the impact of selfish users on the performance.  
Hereafter, we first discuss how UE applications should be designed in order to support broadcasting effectively, and then move on to discussing resource allocation policies in the network.