## 4 Multihop D2D Broadcasting
### Broadcast Management within the UE  
The two problems that UE applications should solve are: (i) how to identify the set of potential recipients; and (ii) when to relay D2D communications. The first problem boils down to identifying all the UEs running the same application in a certain geographical area. UEs running the same application can register to a reserved multicast IP address. This is relatively easy to do with IPv6 (Internet Protocol Version 6), where multicast address format is flexible. As far as defining the target area is concerned, we argue that the area depends on both the network scenario and the application: in a vehicular use case, for instance, vehicle collision alerts should reach vehicles in a radius of few hundred meters, whereas traffic notifications should probably travel larger distances, allowing drivers to route around congested areas. This means that the application message should contain enough information to allow a recipient UE to understand whether or not it should relay it. The information regarding the target area should then be embedded in the application-level message. A simple, but coarse, approach to do this is via a Time-to-live (TTL) field: the source UE sets the TTL in the application message to a desired maximum number of hops. Each relaying UE, then, decreases that field by one, and relays the message only if TTL > 0. While this is relatively simple and economical in space (an 8-bit field should be enough for must purposes), the downside is that the source UE can exert little control over the area covered by the broadcast, since the latter ends up depending on both radio parameters (such as the UEs' CQI and their transmission power) and network topology (i.e., the position and density of UEs). The latter, in turn, is unpredictable and changes over time, so that any default value runs the risk of  
Figure 3: System model. being too small or too high. The alternative is to code the target area within the message, by inserting the originating UE's coordinates and the boundaries of the target area. Geographic coordinates can be taken from GPS positioning, or from geolocation services co-located with the network (e.g., using MEC solutions [8]). Geographic coordinates can be represented by two 32-bit floating points, indicating latitude and longitude with enough precision. A simple way to constrain the target area is to encode a maximum target radius, thus making it circular. Assuming that the target radius is represented in meters, a 16-bit integer should be large enough for most purposes. Encoding originator's coordinates and target radius allows one to define with more precision the target area, which becomes independent of the UE's density and location. This comes at the cost of using more space in the message (10 bytes overall instead of one). Increasing the message size, in turn, entails consuming more network resources for transmission. Obviously, more advanced definitions of target areas can also be envisaged, at the cost of further increasing the message payload. With a geographical representation of the broadcast domain, receiving UEs can then check whether their own position falls within the target area before relaying the message. This can be done by using simple floating-point arithmetic, i.e., by computing the distance from the originator and checking whether it is smaller than the target radius included in the message. Given the coordinates of the two points A and B (specified in latitude \(\varphi\) and longitude \(\lambda\)), the Haversine formula [30] is used to compute the shortest distance over the earth's surface, which is:  
\[d=2r\sin^{-1}\left(\sqrt{\sin^{2}\left(\frac{\varphi_{B}-\varphi_{A}}{2} \right)+\cos(\varphi_{A})\cos(\varphi_{B})\sin^{2}\left(\frac{\lambda_{B}- \lambda_{A}}{2}\right)}\right) \tag{1}\]  
where \(r\) is the earth's radius.