COMPASS: Directing Named Data Transmission in VANETs by Dynamic Directional Interfaces

Inefficient data transmission has been a development bottleneck of Vehicular Ad-hoc NETworks (VANETs), especially in urban areas. It has been proved that many complex IP-based solutions are difficult to be applied in the highly dynamic and link-interrupted vehicular environment. In recent years, Named Data Networking (NDN) has become the most popular realization of Information-Centric Networking (ICN) for future networks. Its characteristics of multi-source, multi-path and in-network caching are helpful for improving the data transmission in VANETs. However, the bottom layer of vehicles cannot provide multiple interfaces to different domains like the routers in wired networks. Thus interface-based forwarding degenerates into directionless broadcasting with low performance and high overhead. Against this problem, we propose COMPASS, a novel named data transmission protocol for VANETs. Firstly, a dynamic directional interface model is built as the cornerstone of our COMPASS. Secondly, the forwarding strategies are improved for rapid interest dissemination and named data retrieving. Besides, an interface remapping method and the update strategies of Forwarding Information Base (FIB) and Pending Interest Table (PIT) are designed to enhance the robustness in high-mobility environment. Finally, the performance of COMPASS is verified on ndnSIM. Compared with the other three state-of-the-art protocols, COMPASS obtains the highest interest satisfaction ratio and the shortest transmission delay in urban traffic scenarios with restricted communication and storage overhead.


I. INTRODUCTION
In recent decades, VANETs have been a research hotspot concerned by both academia and industry. With the distribution of Dedicated Short-Range Communications (DSRC) and the introduction of IEEE 802.11p (WAVE) [1], the safety applications such as collision avoidance and accident warning have been implemented by inter-vehicle broadcasting. However, as the upgrade of on-board applications, broadcasting is not a viable solution to provide high-quality data transmission for sharing traffic conditions, enhancing driving experiences and enriching on-line entertainments [2]. For VANETs, it is a great challenge to achieve efficient and reliable data The associate editor coordinating the review of this manuscript and approving it for publication was Omer Chughtai. transmission in the poor environment with highly dynamic topology and intermittent links.
Given the success of internet, a lot of research focuses on building an IP-based networking on the physical and link layers of WAVE so as to achieve addressing and routing among vehicles. Due to the host-centric nature of IP, many problems arise when it is implemented in VANETs such as address management, route discovery and session maintenance. Although some studies [3] attempt to fix IP by leveraging complex solutions, it is still difficult to achieve high performance in the vehicular environment. Therefore, it is more important for vehicles to retrieve data than maintain a multi-hop path to the data source.
Aiming at the problems of IP-based networks, ICN [4] is proposed as a new paradigm for future networks. Among its realization schemes, NDN [5] is the most popular one that identifies and transmits data by a pre-designed hierarchical name. NDN provides a multi-source, multi-path and in-network caching way for data retrieving which is ideal for handling the transport challenges of VANETs [6]. Some research works [6]- [8] have attempted to deploy NDN on VANETs and proposed the concept of Vehicular Named Data Networking (VNDN) [9]. Since NDN is originally designed for wired networks, it does not take into account the different access technologies of wireless networks. Consequently, the vehicle nodes cannot control the named data transmission by leveraging the underlying interfaces.
As shown in Figure 1, the NDN routers deployed in wired networks manage two data structures: FIB and PIT. Each FIB or PIT entry is bound to one or more interfaces. Before sending interest or named data, the routers query their FIB or PIT to determine the outgoing interfaces. In this way, the whole network is divided into several domains by each router, and named data is transmitted across domains through different interfaces. In VANETs, the vehicles are usually equipped with the same wireless communication devices. They cannot divide the network space by using only one interface. To achieve named data transmission, the vehicles have to broadcast at each hop [10]. To create extra interfaces for data transmission, some studies [11] suggest that the vehicles adopt multiple wireless communication technologies in bottom layer such as WAVE, 4G\LTE and WiMax. This approach increases the cost of car production but still cannot provide a clear network division due to the overlaps between coverages of different communication technologies.
Due to the lack of interface support from underlying layer, the vehicles' FIB and PIT are ineffective during named data transmission. If all the nodes disseminate interest and retrieve named data by unrestricted broadcast, it is likely to cause broadcast storm by flooding. So far, some methods [12]- [14] have been proposed to alleviate this problem such as adopting a delay-based distributed broadcast algorithm and selecting the optimal neighbor as the relay at next hop according to one or multiple attributes [15]- [18]. Although these efforts can mitigate broadcast storm by reducing network redundancy, they cannot achieve efficient named data transmission. Besides, other studies [19]- [21] attempt to direct interests to the potential providers or their surrounding areas. However, the idea that the consumers obtain the details of providers before sending interest is inconsistent with NDN's contentcentric nature and also unfeasible in actual traffic scenarios.
In summary, efficient data transmission in VNDN requires accurate control of interest and named data forwarding at each hop. It is critical to provide a valid solution for vehicles, which can successfully associate the virtual named data space with the actual network space by interfaces.
In this paper, we propose a novel named data transmission protocol for VNDN. Just as a compass helps the traveler make navigation, it controls the interest and named data forwardings at each hop by dynamic directional interfaces. That's why we name it as COMPASS. Compared with the previous works, COMPASS can achieve higher interest satisfaction ratio and shorter transmission delay with restricted communication and storage overhead. Its novelty can be summarized into the following three points.
• To provide effective interfaces for vehicles, we discuss the challenge of building interfaces in VNDN, analyze the defects of static division strategy when it is applied to urban traffic scenarios, and propose a dynamic directional interface model (DDIM) which can flexibly make division according to the driving direction and provide directional interfaces with high robustness.
• Based on DDIM, COMPASS is proposed as a novel transmission protocol for VNDN. In COMPASS, both the data structures and forwarding strategies are redesigned to achieve efficient interest dissemination and named data retrieving. Besides, an improved delaybased distributed broadcast algorithm which allows 0-delay forwarding at high-priority nodes is designed to speed up the entire transmission process.
• To deal with the high mobility of vehicular environment, an interface remapping method is put forward to maintain the validity of FIB and PIT entries after the driving directions of vehicles have changed. In addition, the update strategies of FIB and PIT are also improved so as to enhance the adaptability of vehicles in the highmobility traffic scenarios.
The rest of this paper is organized as follows. In section II, related work on named data transmission in VANETs and discussions about our motivation are presented. Through comprehensive analysis and comparison, our DDIM is proposed in section III as the foundation of COMPASS. Then, the data structures and forwarding strategies are redesigned in section IV. To support high mobility, an interface remapping method as well as the update strategies of FIB and PIT are introduced in section V. In section VI, our COMPASS is implemented on ndnSIM and compared with three state-ofthe-art protocols. Finally, the whole research work is concluded in section VII.

II. BACKGROUND AND MOTIVATION
The inability of underlying layer to provide valid interfaces is a great challenge in deploying the original NDN directly on vehicular networks. In real traffic scenarios, since vehicles are uniformly equipped with one type of wireless communication device, both interest and named data are sent or forwarded VOLUME 8, 2020 by broadcast. The transmission progress is achieved by unrestricted flooding, which is easy to cause broadcast storm. According to the pull-based mode of NDN, the named data is retrieved along the reverse path of interest. Hence, how to effectively control the interest propagation is a key issue in designing transmission protocol for VNDN. In recent years, some studies have focused on achieving efficient named data transmission by directing interest propagation. According to their forwarding principles, they can be divided into three categories: blind forwarding, neighbor-aware forwarding and destination-aware forwarding.

A. BLIND FORWARDING
Blind forwarding means that vehicles have no information before sending or forwarding interest. To avoid conflicts, the delay-based distributed broadcast is a commonly adopted interest suppression technology.
In [12], a uniform random value from the range of 0 to 2 milliseconds is set to the collision-avoidance timer at every node. In this way, even when the neighboring nodes receive an interest packet at the same time, they are likely to schedule the forwarding operations at different moments. A similar approach with a counter-based suppression technique is proposed in [13], where different defer timers are set for interest and data forwarding to prioritize data over interests. During the defer time a node overhears the channel. If the same interests or data are broadcast by other nodes for a number of times, the node will abort its suspended forwarding. However, the random approach is not an optimal solution for distributed broadcast. In consideration of the predicted link stability between neighboring vehicles, a defer timer function is designed in LISIC [14] to determine the forwarding priority of all the neighbors. Upon an interest reception, a vehicle first estimates its link stability with the sender or relay at last hop by their locations, velocities and directions, then sets a defer timer for current interest based on the predicted connectivity duration. A similar approach is also followed in MobiNDN [22]. During the interest dissemination, the calculation of defer time is coupled with the concept of sweet spot. The vehicle at a favorable position has a high priority of interest forwarding by setting a low delay value.
Although effectively alleviating conflicts among neighboring nodes, the delay-based distributed broadcast introduces an additional delay in the transmission process and cannot guarantee the coverage of every potential provider. Different from the above studies, interest flooding is allowed in CODIE [23] to speed up the searching for data sources, but a hop limit is carefully set for the progress of named data retrieving. In CODIE, the redundant copies of named data are discarded at the relays according to their hop limits. In this way, it alleviates the packet conflicts and reduces the transmission overhead. LAPEL [24] is an improved version of CODIE. Besides hop limit, an adaptive algorithm is designed to calculate the lifetime of PIT entries. For an interest, the relevant PIT entries at intermediate nodes along a transmission path are assigned with different lifetimes.
Since the intermediate nodes can detect packet loss and trigger a retransmission whenever its lifetime expires, the whole transmission process can be accelerated with less overhead than that in CODIE.

B. NEIGHBOR-AWARE FORWARDING
The idea of neighbor-aware forwarding is that vehicles can obtain the status information of neighbors by exchanging messages and select one or more candidates from the neighbor list as the relays at next hop when forwarding an interest.
In [25], the area around the interest sender (or forwarder) is divided into 4 quadrants. The farthest neighbor in each quadrant is selected as the relay node. To this purpose, two additional packets (ACK, CMD) are exchanged between the sender and its neighbors. In order to reduce the bandwidth usage induced by interest flooding, the NAIF [15] scheme decides the eligibility of a relay node based on its data retrieval rate for a given name prefix and its distance to the consumer. Similarly, the motion parameters of vehicles and link quality metrics are introduced in MUPF [17] which helps the interest relays in multiple unicast paths to select stable and reliable neighbors as next hops.
To mitigate the interest broadcast storm, a RobUst Forwarder Selection (RUFS) is proposed in [16]. In RUFS, each vehicle shares its satisfied interest(s) statistics with neighbors. All neighbors store this information in their neighbors satisfied lists and select the optimal neighbor as the interest forwarder by leveraging multi-criteria decision. For the same purpose as RUFS, a Distributed Interest Forwarder Selection (DIFS) scheme is proposed in [26]. Different from RUFS, the forwarding decision is made at the interest receiver. When the node at last hop sends an interest, its status information is piggybacked in the packet. After receiving this interest, the immediate neighbors rank themselves to be an eligible interest forwarder by using multiple attributes.

C. DESTINATION-AWARE FORWARDING
The studies on destination-aware forwarding can be divided into two categories. One is that the consumer has mastered the information of content providers. The other is that the consumer is not aware of any reachable provider but knows the area where the potential data source locates.
According to NDN, a large content should be split into multiple chunks for delivery. Thus, the consumer needs to continuously send a number of interests for those chunks. After successfully retrieving the first chunk, the consumer obtains the information of one or more providers, such as identifier, position, and expected hops. Therefore, the idea of specifying the preferred provider in the subsequent interests is proposed in E-CHANET [19] to deal with broadcast storm and reduce communication overhead. This idea is followed by [27] in which a location-based and information-centric (LoICen) architecture is built to improve the content procedure and mitigate the broadcast storm in VNDN. In LoICen, vehicles opportunistically obtain the location information of the potential providers that might have desired content in their cache. This location information is used whenever possible to improve content search by directing interest packets to the area where the content may be located. To suppress interest flooding, a content-centric framework named GeoZone is proposed in [21]. By leveraging a geo-referenced naming scheme, GeoZone builds a dissemination zone with the GPS coordinates of consumer and content provider.
It is an important assumption for the above works that the consumer should obtain the information of provider before sending interest. Although large content transmission is a suitable application scenario, the provider is unknown in most of applications. Additionally, it is challenging for provider maintenance in a highly dynamic environment. In [28], a naming scheme is designed to incorporate geolocation into names so that the problem of forwarding interest to a specified provider is transformed to directing it to the area where the probability of meeting the required data is maximized. Although the substitution of data spot for provider facilitates the interest propagation, it is only feasible for the applications coupled with geolocations. Aiming at steering interest towards where data resides, Navigo [20] maps data name to divided areas by introducing multiple geographic faces in the 2.5 layer and forwards interest along the shortest path. This is a complete solution for deploying NDN framework on vehicular networks, but it is not enough to locate the data source only by the self-learning of vehicles.

D. MOTIVATION
For the target of efficient named data transmission, it is necessary to direct interest packets to the potential content providers or their locations. However, the data-centric nature of VNDN makes it unreasonable for consumers to obtain the accurate information of providers before sending interests. Therefore, it is a great challenge for VNDN to resolve the contradiction between its data-centric nature and high transmission requirements.
Since the studies on blind forwarding and neighbor-aware forwarding attempt to search for the content across the entire network, they have to adopt the interest suppression technologies and choose the stable neighbors as next-hop relays for broadcast storm mitigation. The research works on destination-aware forwarding try to point the way for interest dissemination, but how to locate the data source is a knotty problem. Different from the previous work, a novel protocol named COMPASS is proposed for named data transmission in vehicular networks. In COMPASS, we build a dynamic directional interface model (DDIM) in NDN layer by analyzing the movement patterns of vehicles in urban traffic scenarios, design a novel distributed broadcast algorithm for interest dissemination and data retrieving on basis of DDIM, and finally improve the solutions of interface remapping and data structure management for high mobility support.

III. BUILDING INTERFACES FOR VEHICLES
For efficient data transmission in VNDN, how to provide effective interfaces for moving vehicles is the primary problem to be solved. In this section, the challenge of building interfaces in urban traffic environment is first summarized, then the static division strategy is deeply studied and proved not applicable to VNDN from both theoretical analysis and data statistics, and finally our Dynamic Directional Interface Model (DDIM) is introduced with its inherent advantages.

A. CHALLENGE OF BUILDING INTERFACES
Although there has been a number of communication technologies and protocols designed for VANETs in physical and link layers, it is unfeasible to forward data among those different interfaces due to incorrect domain division and high equipment cost. Therefore, we make a basic assumption that all the vehicles and infrastructure are equipped with one type of wireless communication device. On basis of it, we try to build multiple virtual interfaces in NDN layer instead of the hardware interfaces in underlying layers.
According to the research on Internet of Vehicles (IoV), it is common and effective to use the GPS information for data transmission improvement. Some previous studies have achieved directional flooding [29] and routing [30]- [32] by dividing the area around vehicle into several sections or quadrants. Inspired by those efforts, we propose the idea of building directional interfaces for every node in VNDN. By leveraging the geographic information provided by an onboard GPS device, a vehicle can divide its wireless coverage area into multiple directional interfaces. Every sector covered by the directional interface contains a number of neighbors. Through these interfaces, the vehicle can quickly classify its neighbors and easily specify its broadcast area. Since both interest and named data are forwarded according to the directional interfaces recorded in the FIB and PIT entries, maintaining the mapping relationships between neighbors and directional interfaces as long as possible is the key for vehicles to achieve efficient named data transmission in highmobility and link-intermittent vehicular environments.
In urban traffic scenarios, the mapping between neighbor and interface is easily broken due to many reasons which can be grouped into three categories. (1) The neighboring vehicle changes its motion state. For example, a neighbor makes a sudden turn at an intersection and quickly moves out of the directional interface which it belongs to before.
(2) The local vehicle changes its motion state. If a vehicle changes the driving direction dramatically, it will leave most of its neighbors. As a result, a large number of mappings become invalid. (3) The direction of current road changes. Due to the close angles between road direction and interface boundary, some neighboring vehicles may jump from one interface to another frequently during the driving process. As shown in Figure 2, car A and B are moving along a road. At first, B is located in the westbound interface of A. When the road turns north, although the relative position of two cars remains unchanged, B is relocated in the northbound interface of A. Additionally, in some complex scenarios, the mapping may be broken due to one reason or the combination of several ones mentioned above. In the scenario of Figure 3, two VOLUME 8, 2020  cars approach the intersection from the east, and B belongs to the westbound interface of A. For each car, there are four choices at the intersection: going straight, turning left, turning right and turning around. Thus, the mapping between B and A's westbound interface may fail due to A's driving direction change, B's driving direction change or both of them.
Based on the above analysis, how to improve the robustness to cope with complex urban traffic environment is a great challenge to build directional interfaces for moving vehicles. For designing an interface division scheme, three issues are affecting its robustness: (1) How to select the reference for interface division? (2) How to set the number of interfaces for vehicles? (3) How to provide the adaptability to the changes of scenarios?

B. STATIC INTERFACE DIVISION STRATEGY
Some previous works [29]- [32] on directional data transmission adopt the fixed interfaces provided by the static division strategy. In their designs, the map direction is set as a reference. Although the reference direction and the interface number vary among different schemes, all the interfaces are fixed after division. In Figures 2 and 3, car A adopts a classic Static Directional Interface Model (SDIM) in which four fixed interfaces are built respectively according to the geographic directions of north, west, south and east. The static interface division strategy is easy to implement on vehicles, but it has the following two defects when applied in an urban traffic environment.
First, a fixed interface may fail due to the change of road direction. In the example of Figure 2, car B will no longer belong to the westbound interface of A once the direction of road turns to northwest. To verify that this failure is common in urban traffic scenarios, we analyze the applicability of classic SDIM in three typical cities. In Figure 4, the road networks of three cities are drawn by OSMnx [33]. Beijing is a long-established imperial city where the roads are planned to follow the north-south and east-west directions. Thus, it provides a nearly perfect environment where the vehicles' fixed interfaces rarely fail due to the change of road direction. Wuhan is an inland shipping hub in central China. Its road planning refers to the flow direction of Yangtze River. Since there are a large number of roads whose direction angles are close to those of SDIM's interface boundaries, the failure of fixed interface will occur frequently. San Diego is an important port on the west coast of the United States. As shown in Figure 4c, there are also some roads along the coastline or connecting inland that will cause the fixed interfaces of SDIM to fail.
For further verification, we analyze the taxi GPS trajectory datasets from those three cities. The properties of datasets are detailed in Table 1. To obtain accurate results, we first preprocess the raw data by cleaning the dirty records caused by GPS coordinate drift, then find out the trips of each vehicle and divide them into cruises, finally make statistics based on the GPS records of vehicles in cruise state. Figure 5 shows the driving direction distributions of vehicles in the form of radar chart. In Beijing, vehicles head four directions of north, west, south and east in most cases, which is consistent with its road planning. In the other two cities, vehicles often travel along the roads whose direction angles are close to those of interface boundaries. As a result, the fixed interfaces will fail frequently in Wuhan and San Diego. The road planning determines the driving direction of vehicles running in cities. Although we can try to select the optimal reference direction and interface number for static division schemes, it is difficult to avoid the close angles between some roads and interface boundaries. Therefore, the failure of fixed interface caused by road direction change is an inherent defect of static division strategy.
Second, either the local vehicle or its neighbor changes motion state, it is difficult for static division schemes to maintain the validity of relevant mapping. In the example of Figure 3, both cars A and B have four choices at the intersection. To evaluate the adaptability of classic SDIM in this typical scenario, we illustrate 16 possible cases in Table 2. The horizontal headers list A's four choices, while the vertical headers show B's. As marked by the cross, the mapping between B and A's westbound interface will fail in most cases. B will stay in the original interface of A only if both of  them cross the intersection and move to the west. Therefore, the static division strategy cannot guarantee the robustness of fixed interface in the scenario of an intersection.
To prove that the scenario in Figure 3 is common in urban areas, we calculate all the turning angles of intersections in those three cities by leveraging google map and plot their distributions in Figure 6. The X -axis lists the serial number i of angle interval, and the Y -axis represents the ratio of samples belonging to the specified interval. In the statistics, the angle range of [0, π] is divided into 13 intervals. In Figure 6, the serial number i is mapped to the interval of [(i + 2)π/18 − π/36, (i + 2)π/18 + π/36) (i = 2, . . . , 12) except for the first and last cases. In particular, No. 1 corresponds to the interval of [0, 7π/36), and No. 13 corresponds to the interval of [29π/36, π). As shown in Figure 6, the turning angles of three cities are distributed normally with a common mean of 90 degrees. Although the sample ratios are different, all the values of No. 7 interval are above 65%. It means that the standard intersection scenario is common in urban areas.
In conclusion, the fixed interface provided by the static division strategy will frequently fail in urban traffic environment due to the changes of road direction and vehicles' motion state. Thus, it is not an optimal candidate to provide effective support for named data transmission in VNDN.

C. DYNAMIC DIRECTIONAL INTERFACE MODEL
Aiming at the defects of static division strategy, we propose a novel Dynamic Directional Interface Model (DDIM) based on the movement patterns of vehicles in urban areas. As shown in Figure 7, we set the vehicle's driving direction as a reference for interface division. In DDIM, the vehiclecentric area is divided into four parts. Each part is mapped to one directional interface. In Figure 7 Compared with the static division schemes, DDIM makes the following three improvements. First, the driving direction of local vehicle is set as a reference for interface division instead of the map direction. Although vehicles need to make division multiple times during driving process, DDIM can overcome the interface failure caused by the change of road direction. In the scenario described in Figure 2, no matter how the road direction changes, car B will always stay in A's F-INF by leveraging DDIM. Second, DDIM is more suitable for the intersection scenario than the static division schemes. Since DDIM provides four 90-degree interfaces, remapping operation can be adopted by vehicles to adjust the relationship between the neighbors and their directional interfaces after they have changed driving directions. Thus, an interface remapping method is designed to improve the performance of DDIM in urban traffic environment. More details will be introduced in subsection V-A. To verify the advantages of DDIM, we also evaluate its adaptability in the typical scenario of Figure 3. According to the 16 cases listed in Table 3, we found that if A and B make the same decision at an intersection, B will still stay in the F-INF of A. Besides, as long as B keeps moving in initial direction, even if A changes its driving direction, it will be able to relocate the interface which B belongs to. Thus, three cells in the first row are marked by the triangle symbol which means that the original relationship can be persisted through interface remapping. Finally, the directional interface provided by DDIM has a considerable lifetime during the trip of vehicle. We calculate the average cruise durations of three cities and their average proportion in trip time. As shown in Figure 8, all the average durations of cities are longer than 1 minute, and the value of Beijing even reaches 2 minutes. From the perspective of whole trip, all the average proportions of cruise durations in three cities are above 50%. Therefore, even without the remapping operation, DDIM can guarantee that VOLUME 8, 2020  Based on the above analysis, we adopt DDIM as the cornerstone of entire approach. In urban traffic scenarios, all the vehicles should build their DDIM by leveraging GPS service. Regardless of the communication technologies adopted by underlying layers, a vehicle only needs to select the directional interface for named data to indicate the transmission range at next hop.

IV. NAMED DATA TRANSMISSION BY DDIM
According to the analysis in subsection III-C, DDIM provides the virtual directional interfaces in NDN layer instead of the hardware interfaces in underlying layers. Based on it, we design a novel named data transmission protocol for VNDN and name it as COMPASS. Figure 9 shows the protocol stack of COMPASS and the simplified process of named data transmission. DDIM is built in the NDN layer of every node. It is the cornerstone of our entire approach. Consistent with the original NDN, there are 3 roles set in COMPASS: consumer, intermediate node and provider. The consumer sends an interest to request data. The intermediate node who does not have the matching data may forward this interest after receiving it. If the interest arrives at a provider, a named data packet will be generated and returned along the reverse path. Forwarded by the intermediate nodes, the named data finally arrives at its consumer.
By using the directional interfaces provided by DDIM, COMPASS optimizes the forwarding of interest and named data at each hop in order to (1) speed up the entire transmission process, (2) reduce the communication and caching overhead, and (3) improve the success rate of named data retrieval. In the following paragraphs, we first introduce our design of packet types and data structures, then elaborate a complete transmission progress including both interest forwarding and named data retrieving, and finally propose an improved delay-based distributed broadcasting algorithm.

A. PACKETS AND DATA STRUCTURES
Following the original NDN design, COMPASS uses only two types of packets, interest and data. As shown in Figure 10, both interest and data packets contain several new fields in addition to the basic settings. First, the V_ID is added for vehicle identification, and the POS and VEL are set to describe    the motion state of local vehicle. Second, the 4-bit D_INTs is designed to specify the directional interface of named data forwarding. In Figure 10   every available directional interface at next hop. During the process of distributed multi-hop broadcast, the node which is selected as PR can obtain the highest priority of forwarding current interest.
In COMPASS, all nodes still maintain the three basic data structures: CS, FIB and PIT. Since both the interest forwarding and named data retrieving are dependent on DDIM, we make several appropriate modifications to the FIB and PIT. The structure of FIB is shown in Figure 11. In every FIB entry, the Name and Timestamp are the reserved fields from the original NDN. The Name is used for identifying the data received before, while the Timestamp records the time when the current entry was created. Besides, the 4-bit D_INTs is also added in FIB entry to record the directional interfaces where the local node received the matching data. For every available interface labeled in D_INTs, a preferred relay (PR) is set to accelerate the interest forwarding. Since the vehicle may receive multiple copies of named data from different directions, one FIB entry could be marked by several directional interfaces as well as their PRs. In Figure 11, the Is_RMP is a boolean field which indicates the remapping operation of current entry. If the Is_RMP is true, it means the D_INTs field has been reset due to the change of driving direction. In section V-A, the details of interface remapping for the FIB and PIT management will be introduced.
Similar to the FIB, PIT contains the fields of Name, Timestamp, IS_RMP and D_INTs. The Name describes the data requirement of interest, and the Timestamp records the creation time of PIT entry. The 4-bit D_INTs is used to mark the directional interfaces where the local vehicle received the copies of current interest. The IS_RMP also indicates whether those directional interfaces have been remapped due to the driving direction change. Besides, the PEL is a reserved field of original NDN which shows the lifetime of current PIT entry. To mark whether the local node has forwarded the interest, the IS_FWD is added in every PIT entry. Therefore, VOLUME 8, 2020 although a vehicle should create one PIT entry whenever receiving a new interest, it only sets the value of IS_FWD after the interest has been successfully forwarded. Finally, the FIB_E_ID is added to record the FIB entry number which specifies the reference used for current interest forwarding. In this way, the vehicle can update its FIB entry whenever receiving the matching data.
On basis of the above design, we can select the directional interfaces for interest and named data packets by leveraging the field of D_INTs. Once receiving a packet, a vehicle should determine whether it belongs to the directional interface marked in D_INTs before any other operations. As shown in Figure 10, both the interest and named data packets contain the coordinates and speed vectors of their senders or forwarders at last hops. The vehicle can also obtain the sensing data about its motion state anytime. Assuming that all the data is represented according to the same geographical reference system, we propose an optimized method for interface determination by fast coordinate transformation.
Take the vehicles in Figure 13 for example. When car B receives a packet from car A, it should figure out which directional interface of A it belongs to. In the coordinate system OXY, the position of A is (x a , y a ), while the position of B is (x b , y b ). As shown in Figure 13, the speed of A is represented by the vector v a , and the X -axis and Y -axis components of v a are marked as u a and w a respectively. Obviously, if B makes interface determination for the received packet in the coordinate system of OXY, it will cost a complicated calculation. For optimization, we build a new coordinate system O X Y whose origin is located at A's position (x a , y a ). Besides, the driving direction of A is rotated clockwise by π/4 to set the positive direction of X -axis. In this way, the four quadrants of O X Y are consistent with the directional interfaces of A's DDIM. Consequently, our problem is transformed to recalculate the coordinates of B in O X Y and figure out the corresponding quadrant where it locates. Thus, the decision process consists of two steps. First, we calculate the rotation angle from OXY to O X Y . In Figure 13, it is labeled α. According to formula 1, α is equal to θ minus π/4, where θ is the angle between A's driving direction and the positive direction of X -axis. Second, we obtain the transformed coordinates (x b , y b ) of B by formula 2 and determine A's directional interface for B according to Table 4. (1)

B. NAMED DATA TRANSMISSION PROCESS
In the following paragraphs, we will introduce the details of transmission process from two aspects of interest forwarding and named data retrieving.  Figure 14 shows the interest processing flow at intermediate nodes. First of all, it needs to check its forwarding qualification according to DDIM. If the D_INTs field of interest is set, it extracts the motion state of the node at last hop, then determines whether it is within the specified interface by our method introduced in subsection IV-A. Therefore, only the intermediate node which belongs to the specified interface can serve as a relay for rebroadcasting the interest. Afterwards, the intermediate node continues to look up its PIT by name. If there is a matched entry, it indicates that the current node has received the interest before. Therefore, the intermediate node does not need to forward the interest again. In summary, only the intermediate node who is within the specified directional interface and has not received the same copy before can act as the relay of current interest.
Second, the relay needs to select the directional interface for interest forwarding by looking up its FIB. Similar to the consumer, the relay selects the optimal entry according to the LPM principle and timestamp. On basis of it, the relay updates the interest by resetting the D_INTs and PR_List fields. It is worth noting that the length of matching prefix indicates the relevance between the interest and the FIB entry. If the matching length of selected entry is not long enough, it is unreliable for the relay to direct the interest by the specified directional interfaces. To guarantee the coverage of interest dissemination, we require that a FIB entry can be selected as a reference only when the length of its matching prefix is longer than half the length of interest name. Therefore, if the relay can find the FIB entry satisfying above conditions, it is allowed to forward the interest to the specified interfaces. Otherwise, it rebroadcasts the interest in all directions.
Finally, every relay also needs to decide when to forward the interest. Aiming at the drawbacks of delay-based distributed broadcast, we put forward the idea of accelerating the interest dissemination by using the preferred relay (PR) of directional interface. On basis of DDIM, the vehicle is not only able to select the interfaces but also set the corresponding PRs before broadcasting interest. If the vehicle has successfully received named data from a neighbor before, it can set the neighbor as the PR of corresponding interface in FIB entry. Compared with other candidates, the PR is a verified relay which has provided high transmission performance. Thus, it should be given the highest priority of forwarding the current interest. According to the above analysis, we design an improved delay-based distributed broadcast method in which the historical transmission records in FIB are fully used to reduce the delay at every hop. Our method will be elaborated in subsection IV-C.
After the multi-hop broadcast, the interest finally arrives at the provider. The Nonce field is first read by the provider to determine whether it has received the interest before. If it has gotten and responded to the same request, this copy will be dropped. Otherwise, it will continue to find the matching data from CS, generate a named data packet, and send it to the incoming interface of interest.

2) NAMED DATA RETRIEVING
The retrieval of named data still leverages multi-hop broadcast. Once receiving a named data packet, the intermediate node needs to consider three problems. (1) Whether it is qualified to forward this named data packet? (2) Which directional interface does it select? (3) When does it forward the named data packet?
As shown in Figure 15, the intermediate node not only calculates whether it is within the specified interface but also looks up whether there is a matching entry in PIT. If both conditions are satisfied, it has the qualification to forward current named data packet. Then, the intermediate node sets the incoming interfaces of interest as the outgoing interfaces of named data packet according to the D_INTs of matching PIT entry. Finally, it forwards the named data by our improved delay-based distributed broadcast method. Although the above process is similar to interest forwarding, there are still two differences. First, the intermediate node selects the interfaces by looking up PIT instead of FIB. Second, since the incoming interfaces of interest are recorded in PIT entry without the relays at last hop, the PR_List field cannot be set in the named data packet. Instead, the IS_FWD is added as a new field of PIT entry to indicate whether the local node has actually forwarded the corresponding interest. According to the distributed broadcast method, the relay which has forwarded the interest is more eager to get the named data than the other intermediate nodes which have just created a PIT entry after receiving the interest. Therefore, the relay actually rebroadcasting the interest should have the highest priority of forwarding the matching data. In our improved delay-based distributed broadcast method, if the intermediate node finds the IS_FWD of matching PIT entry has been set, it will forward the named data immediately. Otherwise, it will wait for a while and then continue to make the forwarding decision.

C. DELAY-BASED DISTRIBUTED BROADCASTING
In COMPASS, both the interest and named data are forwarded according to our improved delay-based distributed broadcast algorithm. Compared with previous work, our algorithm not only follows the strategy of 'listen before talk' (LBT) to reduce the redundant copies but also adopts the 0-delay forwarding at the high-priority nodes to accelerate the transmission process.
In our broadcast algorithm, a function T is designed to calculate the delay t at the intermediate nodes before forwarding an interest or named data packet. As mentioned above, those intermediate nodes are divided into two categories as per their VOLUME 8, 2020 priorities. Since the high-priority nodes make forwarding immediately after receiving the qualified packets, the value of t is set to 0. For the low-priority nodes, they need to compete for the forwarding opportunity by setting different delays. Therefore, the value of t ranges from 0 to the maximum delay t max . Following the design idea of [19] and [24], we choose the Short Interframe Space (SIFS) of MAC layer protocol as the basic unit of delay measurement, and set the value of t max to 64 times SIFS. In function T , t is determined by two factors, d and t. d is the distance from the local node to the relay at last hop, and t indicates the duration while the value of d stays within the 1-hop communication range R. As d and t increase, the value of t should decrease gradually, and its decline rate should also slow down. In summary, the function T should satisfy the following four properties.
To meet the above properties, we design a 3-ary piecewise function T (h, d, t) for the delay calculation of interest and named data at intermediate nodes. In formula (4), as shown at the bottom of this page, h is a boolean variable. If the node has been selected as the PR of directional interface according to the field of interest or has forwarded the interest matching the current named data, h should be set true to indicate the highpriority node. In above two cases, the value of t is equal to 0. For the nodes with low priorities, T is defined as a rounded exponential function only related to d and t. In practice, d can be calculated on basis of vehicles' coordinates, while t can be calculated by formula (5), as shown at the bottom of this page. In (5), x and y respectively represent the distances on the X and Y axes, while V x and V y indicate the speed differences in the X -axis and Y -axis directions. The in (4) represents the floor function in mathematics. Thus, the value of t is equal to k × SIFS when h is false, and k is an integer between 1 and 64. Besides, both m and n are the parameters used to adjust the numerical distribution of t. According to our algorithm, if the local vehicle does not obtain the highest priority, the value of t should be not less than 1 SIFS. Considering that the effects of d and t on t are equivalent, we set the lower bounds of 32 · e − d m and 32 · e − t n to 0.5 in our simulations. Since delayed broadcasting only makes sense when d is within the 1-hop communication range R, m is calculated to ensure that the value of 32·e − d m is not less than 0.5 when t is equal to R. Similarly, t should not exceed the cruise duration of any vehicle. Thus, n is calculated to ensure that the value of 32 · e − t n is not less than 0.5 when t reaches 1 minute which is the average result of three cities in Figure 6a. As described in Algorithm 1, the whole process of our delay-based broadcast algorithm consists of three steps. First, the local vehicle checks whether it has the highest priority to forward the current packet. If the vehicle is the PR of directional interface specified in the interest or labeled as the actual interest forwarder in the matching PIT entry, the vehicle sets h to be true and broadcasts the packet immediately. Otherwise, it sets h to be false and performs the second step of delay estimation according to formula 4 and 5. Finally, the vehicle suspends the procedure according to the principle of LBT, and does not broadcast the packet until t times out.

V. MOBILITY SUPPORT
Although effectively reducing the redundancy of the whole network by introducing DDIM, COMPASS still faces many problems in high-mobility traffic scenarios. In addition to the common packet loss phenomenon, the failure of directional interface and the maintenance of FIB and PIT are two important issues worthy of discussion.

A. INTERFACE REMAPPING
In COMPASS, the interest and named data packets are forwarded respectively according to FIB and PIT. Since both of them are built on basis of DDIM, vehicles should adjust their interface divisions once the driving directions have changed. To maintain the effectiveness of interfaces, we propose an interface remapping method for moving vehicles.
Our remapping method aims to help the vehicle rebuild the relationship between the neighboring nodes and directional interfaces after the driving direction has changed dramatically. As shown in Figure 16, the steering angle θ is defined as the change degree in driving direction along the clockwise.  Based on the value of θ, the relationship between the directional interfaces before and after the driving direction change can be built in Table 5. All the cases can be grouped into the one-to-one and one-to-two mappings. First, if a vehicle makes a perfect right turn, U-turn and left turn, the value of θ will be exactly equal to π/2, π and 3π/2. At this time, the relationship between those interfaces is a standard oneto-one mapping. Second, if θ falls into the other intervals, the node which belongs to one interface before may appear in two adjacent interfaces. For example, both m and n are within Figure 16. After O turns θ degree to the right, node n remains within the F-INF but m belongs to the L-INF. Thus, there is a one-to-two mapping between the interfaces before and after the direction change.
To achieve efficient forwarding in highly dynamic scenarios, all the FIB and PIT entries should be updated after each remapping. Based on the value of θ, all the D-INTs fields of FIB and PIT entries need to reset according to Table 5. It is worth noting that the remapping operation usually introduces a new interface due to the one-to-two mapping. Therefore, each remapping operation is very likely to expand the forwarding area of packet. For a FIB or PIT entry, if it has experienced more than one remapping, all the four interfaces may be labeled in the D-INTs field. In this case, the forwarding by leveraging directional interface degenerates into the normal broadcasting. To avoid this problem, every entry in FIB and PIT is required to perform remapping only once. In COM-PASS, the IS_RMP field is added for marking remapping operation. In FIB management, if the IS_RMP has been set before, the entire entry will be removed in the next remapping operation because it will no longer serve as a valuable reference for interest forwarding. Differently in PIT management, the entry with marked IS_RMP is required to set all the bits of D-INTs so that the named data will be returned in all the possible directions.
In addition to how to make remapping, when to trigger remapping is another important issue. In urban traffic environment, the normal operations of vehicles in motion state can be divided into two categories. One makes a small change in the driving direction, such as changing lanes and overtaking vehicles. The other causes a large change which breaks the mapping between directional interfaces and neigboring vehicles, such as steering and turning around. Thus, a vehicle should accurately identify its operations before triggering interface remapping. By leveraging a large number of vehicle sensors, the on-board computer can acquire a variety of realtime data periodically, such as the state of steering wheel and four tires. Based on those sensing data, machine learning technology can be fully used to identify the operations which changes the driving direction dramatically. Since how to build a machine learning model is not the focus of this paper, we only provide an idea for future studies. In order to perform interface remapping in our simulation, we adopt a simplified method. Since more than 95% of the turning angles are above 60 degrees in Figure 6, we set it as the threshold for triggering the remapping operations at vehicles.

B. FIB AND PIT MANAGEMENT
Due to the high mobility of vehicles, the management of FIB and PIT is critical to ensure the efficient transmission of named data. In addition to performing interface remapping after the driving direction changes, COMPASS requires all the nodes to update their FIBs and PITs after receiving the interest and named data packets.
As mentioned in subsection IV-B1, a vehicle needs to adjust its PIT after receiving an interest. If there is no VOLUME 8, 2020 result found by the principle of exact matching (EM), a new PIT entry will be created, and the D-INTs field is also set according to the incoming interface of interest. Besides, the PEL field records the lifetime t L of current PIT entry. To ensure that the consumer can obtain the named data timely before it loses interest, the value of t L is determined by three parts in formula 6. T is the interest duration maintained by the consumer, t INT is the transmission time of interest from the consumer to the current node, and t DAT is the transmission time of named data. Assuming that t DAT is approximately equal to t INT , the value of t L can be estimated by T − 2 · t INT . In addition, if there is a matching PIT entry, the vehicle needs to check whether the incoming interface of current copy has been labeled in the D-INTs field. If this interface has not been included, the vehicle should reset the D-INTs field for the new interface. Otherwise, no modification is required. Finally, since the vehicle forwards the interest by referring to the matching FIB entry, the sequence number of reference FIB entry also needs to record in the FIB_E_ID field of PIT entry for subsequent updates.
After receiving the named data, the vehicle should adjust its PIT and FIB in turn. First, it looks for the matching PIT entry by name. If there is no result found, it indicates that the interest has not been received, or the matching entry has been removed due to timeout failure. Accordingly, the vehicle only needs to drop the named data packet. If a matching PIT entry is found, the named data should be forwarded to the incoming interfaces of matching interest. Second, the vehicle should also adjust the FIB by leveraging the named data. In this step, it needs not only to create an entry for the new data but also update the matching entry that already exists in FIB. The vehicle looks up the FIB by the principle of EM. If it has not obtained the named data before, a new entry is added in the FIB. Otherwise, the vehicle continues to check whether the incoming interface has been included in the D-INTs field of matching FIB entry. If the data copy comes from a new interface, the vehicle marks the corresponding bit of D-INTs field for the interface and records the last-hop relay as its PR.
In addition to creating or updating the matching FIB entry, the vehicle should also manage the reference FIB entry for the subsequent data transmission. By leveraging the FIB_E_ID field of PIT entry, the vehicle can easily find the reference FIB entry used for interest forwarding before. Similarly, the vehicle checks whether the incoming interface of named data has been included by the D-INTs field and whether the relay at last hop has been recorded as the PR. If both two conditions are satisfied, the reference FIB entry can be retained without any modification. If only the relay changes, the PR of corresponding interface should be replaced by the new relay. Otherwise, a new interface should be set in the D-INTs field with corresponding PR.
In order to update FIB continuously, we rewrite the removing rules of PIT entry. Different from the original NDN, the intermediate node is required to retain every PIT entry even after receiving and forwarding the matching data. According to the FIB_E_ID field, it can quickly locate the reference FIB entry. Only after the lifetime t L times out, this PIT entry can be removed. At this time, if the local node has not received the matching data from the interest outgoing interfaces, it will remove those interfaces from the reference FIB entry. Different from PIT, there is not a lifetime field designed for the FIB entry. Thus, a FIB entry is removed only in two cases. First, if the FIB entry has already performed interface remapping, it should be directly removed when the next remapping is triggered. Second, if all the outgoing interfaces are removed due to the transfer failure, the FIB entry will be no longer valuable consequently.

VI. SIMULATION
In this section, we first introduce the simulation settings and quality metrics, then verify that our DDIM is more suitable for urban traffic scenarios than the static directional interface model (SDIM) mentioned in subsection III-B, and finally compare COMPASS with three state-of-the-art protocols, original NDN [12], LAPEL [24] and Navigo [20].

A. SIMULATION SETUP
For realistic VNDN simulations, we adopt the network simulator ns-3 [37] with two critical modules, WAVE and ndnSIM [38]. WAVE is an overall system architecture for vehicular communications, which can implement the physical and link layers according to IEEE 802.11p [1] and provide the interface for the upper layer in protocol stack. ndnSIM is designed as a network-layer protocol model which can not only support all the functions of original NDN protocol but also run on top of any available MAC-layer protocol model. In our simulation, both modules are installed on all the nodes with default configuration parameters. Table 6 lists the main parameters of our simulation, which involve three aspects of physical layer, link layer and traffic scenario.
To evaluate the performance of protocols under different road planning, we generate two distinct traffic scenarios by leveraging MOVE [39] which is a visualization tool based on SUMO [40]. In Figure 17, both scenarios follow the Manhattan mobility model with an area of 4 × 4 km 2 , but their road plannings are quite different. The roads in Scenario 1 follow the north-south and east-west directions, while the roads in Scenario 2 are along the northeast-southwest and southeastnorthwest directions. For both scenarios, every road is set to a 4-lane dual carriageway, and all the intersections are equipped with traffic signals. For individual differences, we set 6 vehicle types including sedan, SUV, pickup, van, bus and truck. Each one has its own physical parameters such as size, acceleration, etc. Thus, vehicle mobility varies between different types. There are totally 400 vehicles with randomly assigned types and routes making up 16 traffic flows in our simulation scenarios. It is worth noting that all the vehicles are not only able to perform the basic operations of acceleration, deceleration and turning, but also follow the traffic rules, such as stop at red, move at green, and keep their speed within 60 km/h. Besides, 4 roadside units (RSU) are deployed at the T-intersections in Figure 17. In simulation, we randomly select the consumer from those vehicles and set it to publish the interests at a fixed frequency. The providers with different contents are placed at the RSUs to meet the interests of passing vehicles.
In order to evaluate the four VNDN transmission protocols comprehensively, we introduce five quality metrics, ISR, PS, TD, HPS, IST. Their definitions are described as follows.
• ISR is the average interest satisfaction ratio of all the consumers randomly selected in simulation.
• PS is the average PIT size of all the vehicle nodes participating in the named data transmissions.
• TD is the average transmission delay of all the successful named data transmissions. The delay is calculated as the round-trip time of disseminating interest and retrieving named data.
• HPS is the average hops of all the interests arriving at the providers.
• IST is the average interest sending times of all the transmissions including both successful and failed cases.

B. DDIM vs. SDIM
To verify the advantages of DDIM, we make performance comparison between two versions of COMPASS. One uses our DDIM and the other adopts the SDIM mentioned in subsection III-B. Although the area around each node is divided into 4 interfaces in both models, the essential difference between them is that SDIM fixes the interfaces in the direction of north, east, south and west, while DDIM adjusts the division whenever vehicles' driving direction changes. In COMPASS, we not only redesign the data structures, forwarding strategies and broadcast algorithm, but also propose the interface remapping method and other update strategies to support high-mobility traffic scenarios. All of these constitute our COMPASS. Thus, the legend of 'DDIM' in Figures 18 and 19 indicates that all the nodes adopt the complete COMPASS protocol. To make an objective comparison, we replace DDIM by SDIM in the protocol stack of all nodes. Besides, the data structures and forwarding strategies are preserved, but the interface remapping is not adopted because SDIM does not allow interface adjustment at all. Thus, the legend of 'SDIM' means that all the nodes perform COMPASS with above settings. Given the impact of path planning on protocol performance, we implement the comparative experiments respectively in the two scenarios described in Figure 17. Figures 18 and 19 respectively show the metrics of DDIM and SDIM in two scenarios. Since the directional interfaces provided by those two models are similar in Scenario 1, their performance is almost identical. First of all, as the interest frequency at the consumers increases, the ISRs of DDIM and SDIM gradually decline. As shown in Figure 18a, the ISRs of two models are maintained above 85% when the frequency is within 10 packets per second (pps). Once the frequency reaches 30 pps, the values drop to about 55%. In VNDN, high interest frequency introduces a mass of packets which intensify the competition of wireless channel and increase the probability of packet collision. Therefore, the decline of ISRs in Figure 18a is inevitable. Due to the packet loss caused by channel competition, both the TDs and ISTs of two models increase with the increment of interest frequency. In Figure 18b, it is clear that the values of TDs rise significantly once the frequency becomes higher than 15 pps. Second, as the interest frequency increases, all the nodes in the network receive more and more interests. Consequently, both DDIM and SDIM obtain a growth curve of PIT size in Figure 18c. Finally, since the network topology is fixed, the route of interest from the consumer to the data provider does not change as the frequency increases. This is confirmed by the results of HPS showed in Figure 18d.
In Scenario 2, the fixed interfaces provided by SDIM cannot properly match the road directions, while DDIM is able to adjust its interface division for named data transmission. As a result, DDIM is superior to SDIM in all metrics. First, although the ISRs decline with the increment of interest frequency, DDIM obtains higher values than SDIM in all cases. In Figure 19a, the curve of SDIM drops rapidly, but  DDIM obtains nearly the same performance as it performs in Scenario 1. Similarly, all the TDs of DDIM are less than those of SDIM in Figure 19b, and the ISTs of DDIM are also larger than those of SDIM in all cases. Second, due to the poor division of SDIM, a large number of available interests are determined to be invalid and discarded at the intermediate nodes. Therefore, all the PSs of SDIM are less than those of DDIM in Figure 19c. Finally, although the consumers can retrieve named data by SDIM, part of interests have to make a detour due to the failed mappings. Therefore, SDIM introduces extra hops throughout the whole transmission progress. The results in Figure 19d also confirm this.
Additionally, stability is also an important indicator to evaluate our models. In the two groups of comparative experiments, the consumers are randomly selected from 400 vehicle nodes to repeat the simulation 20 times. In consideration of the differences in the transmission performance between nodes, the numerical distribution of every metric is described in Figure 18 and 19. In Scenario 1, DDIM obtains nearly the same performance as SDIM, but it provides more stable named data transmission. In Scenario 2, DDIM is much better than SDIM in all the metrics as well as the stability. In conclusion, DDIM can provide strong support for named data transmission in vehicular environments.

C. PERFORMANCE COMPARISON
To verify the advantages of COMPASS, we compare it with the other three state-of-the-art protocols. First, the original NDN is set as the baseline scheme and labeled as O-NDN. In our experiments, all the details of O-NDN are implemented as described in [12], such as data structure and forwarding strategy. Second, two state-of-the-art VNDN protocols are selected for comparison. In Navigo [20], the consumer can locate the area where the data provider may appear potentially by leveraging geo-interfaces and plan the shortest path before sending its interests. In our experiments, it is assumed that the provider can be located successfully every time by Navigo, but it is impossible to achieve in practice. As introduced in section II, LAPEL [24] is an upgrade of CODIE [23], which not only limits the number of hops in the data retrieving process but also sets the lifetime of PIT entries dynamically. Since the four protocols are not affected by the road directions, the simulation with randomly selected consumers runs 20 times only in Scenario 1, and their results of ISR, TD, PS, HPS and IST are plotted in Figure 20. Figure 20a describes the ISRs of four protocols with the increment of interest frequency. First, except for 1 pps and 5 pps, COMPASS gets the highest values among all the protocols. For interest propagation, COMPASS limits the directions by leveraging DDIM, while O-NDN and LAPEL allow interest flooding in all directions. Therefore, COM-PASS cannot obtain as many opportunities as those two protocols to satisfy the interests, which fully explains its lower ISRs in the low frequencies. As the interest frequency increases, the number of packets throughout the network soars. As a result, the fierce competition of wireless channel leads to more and more serious packet loss. At this time, the unrestricted interest propagation becomes the Achilles heel of O-NDN and LAPEL, and their ISRs fall rapidly. Benefitting from DDIM, COMPASS can effectively alleviate packet loss and get the best results at the high frequencies.
Besides, due to the limited number of hops for named data retrieving process, the advantage of multipath transmission is weakened by LAPEL, especially in the highly competitive wireless channel. Once the transmission along a single path fails, the consumer may no longer be able to obtain the matching data. Therefore, LAPEL's ISR is even lower than O-NDN in Figure 20a. Navigo follows the multi-hop broadcasting method of O-NDN, but both the interest and named data must be transmitted along a planned path. As the packets generated by Navigo are much fewer than those by O-NDN and LAPEL, it gets the higher ISRs than these two protocols at high frequencies. However, Navigo spreads the interest in the preset direction, and it does not have multiple directional interfaces for selection in each hop. Therefore, it underperforms COMPASS in Figure 20a.
TD is another important indicator for performance evaluation. It is worth noting that in our simulations all the protocols adopt the same interest retransmission mechanism provided by ndnSIM. By default, the consumer is allowed to send the same interest 3 times. Whenever an interest times out, the consumer should resend it by setting a larger retransmission timeout (RTO) until the interest has been sent enough times. It is obvious that TD is positively related to IST. Figure 20b and 20c respectively show the TDs and ISTs of four protocols with respect to the interest frequency. Since COMPASS does not introduce as many transmission times as O-NDN and LAPEL, its TDs are lower than those two protocols. Affected by serious packet loss, the IST of O-NDN rises sharply as the interest frequency increases, and its TD also becomes intolerable rapidly. Similar to O-NDN, LAPEL does not alleviate the packet loss problem very well. Because of the limitation on transmission hops, it indeed costs fewer ISTs and less TDs than O-NDN when the interest frequency is below 15 pps. However, the defect of single data retrieving path makes its IST become larger than that of O-NDN once the interest frequency reaches 20 pps. Correspondingly, it also gets the highest TDs in the cases of 20 pps, 25 pps and 30 pps. Benefiting from the path planning for both interest and named data, Navigo effectively reduces the probability of packet collision. As a result, it performs better than O-NDN and LAPEL on IST and TD. Compared with COMPASS, Navigo obtains the lower TDs at low frequencies. However, flooding in a single path makes it more likely to lose packets than COMPASS once the interest frequency increases. In Figure 20c, the ISTs of Navigo are larger than those of COMPASS, and the gap increases with the frequency. As a result, more interest retransmissions make the TD of Navigo become higher than COMPASS from 15 pps. Figure 20d describes the PSs of four protocols as interest frequency increases. Benefiting from the path planning for both interest and named data, Navigo limits the packet number throughout the network and gets the smallest PS. Although quite different from Navigo, COMPASS is also able to limit the interest flooding and reduce the number of redundant packets. In Figure 20d, its results are only larger than Navigo. Conversely, due to the unrestricted broadcasting method, O-NDN gets the worst results. As shown in Figure 20d, its PS increases significantly with the increment of interest frequency. In LAPEL, a dynamic algorithm is designed for adjusting the PIT lifetime so as to remove the VOLUME 8, 2020 expired entries in time. Therefore, the PS of LAPEL is much smaller than O-NDN in all cases.
The HPSs of four protocols are described in Figure 20e. Since the planning path brings great benefits to Navigo, it obtains the fewest HPS at all frequencies. In our COM-PASS, the delay-based distributed broadcast algorithm tries to select the stable nodes which are far away from the local nodes. Therefore, its HPS is maintained within 10, only worse than Navigo. It should be noted that Figure 20e shows the hops of interest received by the providers rather than the hops of named data in the retrieving process. LAPEL indeed limits the hops of data transmission, but it makes the same interest flooding as O-NDN. Therefore, LAPEL does not perform much better than O-NDN on HPS in Figure 20e.

VII. CONCLUSION
In this paper, we present that the lack of valid underlying interface is a key reason resulting in inefficient named data transmission of VANETs. To deal with this problem, we propose a novel protocol and name it as COMPASS. Compared with previous work, the contribution of COMPASS can be summarized in three aspects. First, the vehicles' movement patterns in urban traffic scenarios are explored by analyzing three taxi GPS trajectory datasets, and a dynamic directional interface model (DDIM) is built in NDN layer that associates the virtual named data space with the actual network space. Second, the data structures and forwarding strategies are redesigned on basis of DDIM to specify the broadcasting area of interest and named data at each hop during transmission progress. Besides, an improved delay-based distributed broadcast algorithm is proposed to speed up the whole transmission by allowing high-priority relays to make 0-delay forwarding. Finally, to enhance the robustness of COMPASS in high-mobility environment, an interface remapping method is designed for updating the FIB and PIT entries after driving direction has changed, and the update strategies of FIB and PIT after receiving an interest or named data packet are also improved. To verify the advantages of COMPASS, we make comparison experiments on ndnSIM. The results show that (1) the DDIM adopted by COMPASS is more suitable than SDIM for complex urban traffic environment. (2) COMPASS outperforms the other three state-of-the-art protocols since it achieves high performance with low overhead. Therefore, COMPASS is a feasible solution for efficient named data transmission in VANETs.