## 3 Related Works
### Listen First Broadcast Later  
The Listen First Broadcast Later (LFBL) protocol [20] is classified as a content-oriented routing protocol, and there are several studies that mention it in the literature. This is the reason why we compared our mechanisms with LFBL and the default NDN in Section 5.  
With LFBL, routing decisions are made by the node that receives a packet and not by the node that sends the packet. Therefore, after receiving a packet, a node considered to be a potential router listens to the channel for a while to verify whether there are other nodes more suitable than the node itself to be the packet forwarder. During the listening time interval, if there is no better candidate to forward the packet, the node itself will forward the packet. This procedure is called the request phase.  
LFBL does not maintain a state of connections. Therefore, nodes that are in the path of an end-to-end flow evaluate whether they are capable of being forwarders based on their distances to the destination. This behavior removes the need for knowledge of network topology from LFBL. By using broadcast communications, nodes that are in the listening perimeter can decide if they can forward the packet. Hence, all the information related to routing is within the packet, as LFBL only employs broadcast communications for sending packets.  
The listening period is a key parameter of the LFBL protocol. Assuming that in a wireless mesh network there is more than one node transmitting its data, the listening time for a given node should be long enough to receive the neighbor packets and verify if it is a forwarder or not. The authors argue that this time serves primarily to give priority to communications and also to avoid collisions. Priorityrefers to giving shorter time to nodes which have already chosen candidates for forwarding the packets. In this way, nodes that have previously forwarded packets from a particular flow have priority over nodes that have not yet forwarded packets from this flow. The listening time is also used to reduce the collision because two forwarding nodes do not listen during the same period. By listening for a period, two nodes can consequently send the data precisely at the same time, as both act as if they are the best candidate to forward the packet. Therefore, the authors argue that using a random factor for the listening period considerably improves the protocol's performance.  
LFBL creates different flows between the source and the destination. These flows, after the initial request phase, are destination-oriented. Hence, for a densely populated network with a high degree of requests, these flows can create bottlenecks in the neighborhood of producers. We have also observed that if multiple content servers are in the network, the calculation of the producer distance becomes imprecise. This imprecision is because for different responses of different content servers, the intermediate nodes will assume their eligibility in a precise way that does not necessarily reflect the best routes.  
The description of the LFBL does not detail how caching is done. For the sake of fairness, we enabled the LFBL cache with the same size used by our mechanisms. LFBL also does not detail how long nodes have to wait during the request flooding phase. In our analysis, we observed that this time period severely impacts LFBL performance. For our simulations, we used 20 s as the waiting time.