## 1 Introduction  
The diffusion of sensors and personal devices has recently made possible a range of networked applications that have geographical proximity as a key characteristic. Relevant examples abound: smart-city applications are often based on querying sensors deployed in a certain area (e.g., for temperature, air pollution, etc.) [1]. In vehicle-to-vehicle (V2V) communications, cars that sense anomalous conditions (e.g., a collision) should broadcast this information to their neighbors, to instruct their assisted-driving systems to activate safety maneuvers [2]. Likewise, coordinated robots or drones need to broadcast their position and status to their neighbors to coordinate swarming [3]. In all the above cases, the set of potentially interested recipients of a message generated by an application is defined according to geographical proximity to the originator: anyone close enough should pay attention to the message, where how close is close enough is actually determined by the application itself. For instance, still in the case of vehicular collision, it is foreseeable that only cars in a small radius from the collision point should activate their assisted-driving system and initiate safety maneuvers, whereas vehicle navigation systems in a much larger radius may benefit from knowing about the collision and start looking for alternative routes. In other words, the broadcast domain should be defined directly by the application. All the above applications need to rely on ubiquitous and reliable and secure connectivity, as well as mobility support. Another requirement of these applications is small latency, either because of a specific deadline, or because the performance of networked applications relying on these broadcast messages depends on how fast these propagate. In the last decade, researchers and manufacturers widely investigated the performance of 802.11p as a technology for vehicular mobile ad hoc networks. On one hand, the latter has proven to be very scalable and flexible, as it does not need any infrastructure to work. On the other hand, 802.11p has demonstrated to have limitations in providing bounded delay and QoS (Quality of Service) guarantees [4]. Recently, both researchers and automotive industries have begun to investigate using 4G cellular networks, such as LTE-A (Long-Term Evolution-Advanced) as an option for vehicular communications [5]. Research works have evaluated the performance of 4G for various vehicular applications, showing that it can be considered a viable alternative to 802.11p [6]. The above considerations also fall into the context of Vehicle-to-Everything (V2X) communications, where one endpoint of the communications is a vehicle, and the other one can be user cell phones, connected traffic lights, etc. Moreover, several of the above examples of applications are being mentioned as use-cases to generate requirements for the definition of the future 5G communications [7]. We are thus moving towards a context where cellular communications are expected to play a major role as a unifying technology for multiple services. The current LTE-Advanced standard, unfortunately, is ill equipped to support this type of applications. In fact, cellular communications normally have the eNodeB (eNB) as an endpoint of each layer-2 radio transmission. This requires the User Equipment (UE) application originating the message to always use the eNB as a relay in a two-hop path, even though the destination is a proximate UE. The eNB can relay the message using either multicast or unicast downlink transmissions. The multicast leverages the standard Multicast/Broadcast SubFrame Network, (MBSFN), which was designed for broadcast services like TV. MBSFN is inflexible for at least three reasons: first, multicast/broadcast subframes are alternative to unicast ones, and their definition must be configured semi-statically. Thus, defining MBSFN subframes implies eating into the capacity for downlink unicast transmissions, and reserving capacity for broadcast ones even when there is nothing to relay.