## 3 Multimetric Map-Aware Routing Protocol (MMMR)
### Map-Aware Capability and Use of a Local Buffer  
An important issue that one should face in the design of a routing protocol for VANETs in urban scenarios is the presence of the buildings, trees and other obstacles usually found in cities. Greedy forwarding in GPSR is often restricted,because direct communication between nodes may not exist, due to an obstacle. We include a map-aware capability, which focuses on two important enhancements: (a) it takes into account the presence of buildings in the decision of the next forwarding node; and (b) it uses a local buffer to temporarily store packets when no forwarding node was found. The forwarding decision included in MMMR uses the same criteria as the original GPSR [6]. It consists in choosing the neighbor located nearest to a destination. Besides, our proposal tackles the important issue of deciding which neighbors are actually reachable. This feature is of paramount importance to determine if a neighbor in the list could be a good forwarding node. The accurate information about the current position of a neighbor has a strong impact on the routing performance, because knowing this information makes the node aware of which neighbors are reliable to act as the next forwarding nodes. At the same time, it avoids sending packets to an unreachable node, because it is, for instance, behind a building. This feature makes vehicles be map-aware, since they avoid sending packets to nodes behind the walls of the buildings in the city. The presence of obstacles, such as buildings, are tackled using vehicular location. If the straight line between the current vehicle position and the next vehicle position is blocked by any rectangular area representing a building, then that node behind a building cannot be chosen as the next forwarding node. Otherwise, packets sent to that node would be lost. Furthermore, an important drawback of GPSR is the implementation of _perimeter forwarding_, because it is not clear when the algorithm switches its mode to greedy forwarding again. The main problem of GPSR is the use of outdated information to select the next forwarding node. It is possible to find inconsistencies in the neighbor tables or in destination node's location set in the packet. The neighbor table problem is to select a node that is out of range, resulting in packet loss. This happen often because often, the nearest neighbor to the destination node is also the farthest neighbor. Due to destination node's location included in the packet, the header is never updated by any forwarding node; packets with high a delay will never arrive to the destination node and will get lost in a location where the destination is no longer. In addition, mobility can induce routing loops while using the _perimeter mode_[12]. To avoid these problems caused by perimeter forwarding, our proposal stores packets in a local buffer of the current relaying node when there is no neighbor that satisfies all the requirements needed to be a next forwarding node. If at least one of the two conditions (_i.e._, being actually a reachable neighbor and being closer than the current carrier node to the destination) required to be the next forwarding node is not satisfied, then packets are stored according to the FCFS (First-Come, First-Served) scheme in a local buffer instead of being discarded. If the buffer gets full, packets will be dropped. The nodes periodically look for a neighbor that can satisfy the requirements to be the next forwarding node. Every period of time (1 s), the node looks for a new node candidate. After previous simulations analysis, it was concluded that this period of time is frequent enough to detect quickly any topology change. If a candidate fulfills the requirements, the stored packets are forwarded to that node. In our case, the impact of out of order is not remarkable, due to the kind of services that we use, such as the report of accidents, traffic or environmental information obtained by the car sensors.