1 Introduction

Increasing demand for large-scale and effective distribution of duplicate content has given incentive to deploy new architectures for the future internet. Information centric network (ICN) is an architecture that is based on “named information” named as Named Data Object (NDO) or content such as web pages, videos, documents. The advantages of the information centric network (ICN) architecture are, storing data in the cache, creating multiple connections through content replication, and establishing an interactive model that splits transmitters and recipients to gain efficiency, reliability and security of content distribution.

One proposed architecture for this type of network is the content centric network (CCN) that is proposed by Van Jacobson [1, 2]. In the CCN, the network layer provides users with the content or some information about the content, or at least the name of the content, rather than providing a communication channel between the hosts. As a result, CCN architecture: (1) addresses the content; (2) routes the user requests; (3) provides information safety; (4) provides local storage capability in the network; and (5) provides a way to differ between different reception qualities of the different services [3]. The CCN also eliminates the need for registering IP address, when each endpoint moves [4].

Recent studies show that CCN can be a good alternative to the poorly performed host-based model in VANET, because it names data in addition to the host, separates data from an IP address, provides easy and effective storage in the network, matches the nature of applications etc. [5,6,7,8,9,10,11,12,13,14,15]. It is clear that deploying content-centric networks into vehicular networks needs elaboration, by considering scalability and mobility. The CCN also increases the speed of data retrieval with content response in different nodes, because there is no need to configure IP layer (that is hard to achieve in the VANET) and the cache on each node [5,6,7,8,9,10,11,12,13].

The CCN uses data-naming scheme for its addressing as described in [9, 16,17,18,19]. Having no need for an IP address is not unique to CCN and exist in WAVE short message protocol (WSMP) that can exchange data without TCP/IP overhead [20]. However, CCN has the advantage of dealing with the content that is self-identifying and self-authenticating and is more suitable for VANET highly dynamic environment. However, such content-centric vehicular network (CCVN) faces challenges such as optimum data-naming structure design method. The preliminary analysis of CCVN and its effectiveness is performed by [21].

There are also concerns about the request packet repetition rate and estimating retransmission rates that are critical in terms of congestion control and flow control in wireless environments. Another challenge is the compatibility with the existing wireless access points and devices. Finally, there are interest in the link and integration of content-centric networks into other systems such as cloud and social networks [7,8,9].

The CCN architecture is employed is many researches [6, 8, 9, 22,23,24,25] that reflects the growing capabilities of the CCN. For example, the DMND [22] (collecting Data from Mobiles using Named Data) collects data directly from vehicles by giving the dependent names of people on the data and separating it from communication channels. In addition, using the interest storage and broadcast capabilities via several base stations (BS), enables it to solve problems in high-speed mobility, as well as hiding occasional connections from the collection process in the application layer.

The content naming and routing are the main axis of the research challenges in CCN. In the article [16], a comparative research project has been done on the naming and routing mechanisms. Some articles [26, 27] have examined methods to improve routing algorithms. In [26] the weights in the routing table are managed to control overhead and the size of Forwarding Information Base (FIB) by introducing three components: neighbor discovery, discovery path, and making table. In [27] some routing algorithms are provided to reduce the congestion caused by the request packet flood with and without clustering and additional tables. Scalable opportunistic VANET content routing with encounter information (LER) [28] utilizes the last encounter information of each node to infer the locations of the content holder to avoid interest packet. A location-based packet-forwarding mechanism for vehicular named data networking (NDN), Navigo [29], tries to mitigate frequent connectivity disruptions and sudden network changes in a vehicle network. Navigo aims to fetch data from multiple potential carriers by binding their NDN data names to their locations and using an algorithm to rout interest packets along the shortest path using additional information such as road topology. Authors in [30] introduce a scalable proactive content discovery scheme, hierarchical bloom-filter routing (HBFR), to tackle mobility and large population in VANETs. In [19] scalability issues of the Forwarding Information Base (FIB) in CCN are addressed. The solution is to use both hierarchical names assigned by access providers and a novel alias name architecture. With the former, it allows the aggregation of entries in the routing tables of CCN content routers, while the latter reduces the processing load at those routers when replicas exist in different parts of the network.

The complex name structure in addition to the large size of the routing tables has made name searching speed a challenging issue in content-centric networks. Quick name search for content-centric networks has been examined in [31]. There are two other techniques to speed up the search [18]. The first technique involves a prefix name search in the forwarding list that is sorted by the prefix length, to make it adaptive and faster than linear search of the current CCNX protocol. Therefore, the search priority is dynamically adjusted by changing the forwarding tables. The second technique uses a hash table for data structure consisting of several small and distributed hash tables. Alternatively, the author in [17] uses a combined IP-CCN packet format, to benefit from the storage and unlimited name space. In [32] the content-centric network has been employed as an underlay, to support both TCP/IP and CCN protocols.

Some current research focus on reliability of emergency information including traffic status, vehicle sensory data, etc. in a non-host centric manner using ICN [33]. Reliability at the transport-level of a CCN-enabled VANET is improved by segmentation/reassembly procedure to manage retransmissions of lost content packets [34].

In [35], a controlled data packets propagation in vehicular named data networks (CONET) scheme is introduced to control the data flooding/broadcast storm of the conventional VNDN. A hop counter starts in interest message and upon receiving that interest by any potential provider the hop count is used as a time to live (TTL) value in the data messages to limit data flooding. Certainly, this method reduces the delay of data transfer by controlling the Interest and data packet distribution ranges. However, its efficiency is very low in cases that the provider and consumer nodes are far from each other.

2 Problem formulation

In this paper, VCCN architecture is extended to facilitate access to the critical data and overcome discontinues radio coverage. This extended architecture purely focused on vehicle-to-vehicle communication. In scattered vehicular networks, network coverage is discontinued and usual data propagation cannot guarantee data delivery. It is proposed to store data in the vehicle and deliver it to the next available vehicle at a later time to solve this problem. It is also proposed to only store critical data to reduce the required data storage infrastructure and network congestion. The critical data (such as accident, traffic, etc.) usually have small volume as compared with non-critical data. In contrast, non-critical data, such as multimedia are usually rooted out of the vehicular network and it is often accessed via the roadside units (RSUs).

The contagious data delivery mechanism, proposed in this research, provides many sources for the same data and can gradually spread the data over the entire network. Since critical data in most cases is locally applicable, it has been suggested that network vehicles store data within the range of a few hops from the data origin to limit data storage and unnecessary data spread. The main advantage of this architecture is data access time reduction and better coverage in low-density scattered vehicle scenarios. However, the proposal requires addition data storage, which brings hardware and software complexity and overhead for data transfer and signaling. To the best of our knowledge, bringing the data to the vicinity of the user to improve its availability and reduce delay in disperse vehicular ad hoc network is not addressed in the current literature. The system architecture and its operational phases will be described in the following.

3 ECCN system architecture

In conventional CCN, every time a node needs a data, it searches the network to discover the source by a flooding mechanism. In highly dynamic and disperse VANET environment, it is very likely to miss the source. In addition, the route may break due to movement of the vehicle during the long delay data transfer.

In the ECCN, we reverse the mechanism by broadcasting and caching the critical data in almost every node to bring the data in the vicinity of the requesting node to shorten the route, reduce delays and improve reliability in a high mobility environment. The caching may result in a large volume of data and high traffic load, and therefore, it is proposed to limit the data to only low volume critical data on the basis that only critical data have delayed QoS constraint. It is also proposed to localize data distribution to the neighborhood of the source node to further reduce the data volume and traffic. The neighborhood is defined by the range of data diffusion from the original source using a limiting hop number. The locality is based on the fact that every critical data such as an accident is of interest in a local area. To overcome discontinuity of vehicle nodes, the node that cannot find any neighboring node, will continue to broadcast (periodically) for a limited time in quest of a neighbor until it moves to the vicinity of other vehicles in the course of time.

Fig. 1
figure 1

An extended CCN architecture (ECCN)

Full size image

The ECCN has only a minor infrastructure difference with the conventional CCN by adding a neighbor content store (NCS) to keep critical data in addition to the existing content store (CS), as shown in Fig. 1. The proposed architecture is put into service in two phases: the preparation phase and the discovery phase.

4 Preparation phase

In the preparation phase, the critical data are gathered and stored in the NSC from the surrounding sources or relaying nodes. Therefore, the critical data are propagated to the environment either by radio propagation or by the physical movement of vehicles. This provides multiple sources for a single data, shortens the discovery route and makes a reliable link to access. The number of hops for data to spread is defined by the network requirement and the type of data that is to be defined in the future. That is kept in a field, called time to live (TTL).

Fig. 2
figure 2

Data caching and forwarding process in the preparation phase

Full size image

Intermediate nodes that receive this data, first seek the data name in their Pending Interest Table (PIT). PIT stores all the Interests that a router has forwarded but not satisfied yet. Each PIT entry records the data name carried in the interest, together with its incoming and outgoing interface(s). If the name is found, the data are removed from the sending cycle, because it has already been received. Otherwise, the data will be sent to NCS to be saved and forwarded to the environment while its TTL is decremented by one. Whenever the TTL reaches to zero, the process will stop. The data caching and forwarding process in the preparation phase are shown in Fig. 2.

5 Discovery phase

In the discovery phase, when a node receives interest packet, first searches the packet inside its own CS and NCS. If it is found in any of them, it returns the data to the consumer node; otherwise, the interest packet is put in the PIT. The PIT keeps the trace of the requesting node to return the data to it through the relevant face. However, if this node has received the interest packet for the first time, the interest and the relevant face of requesting node will be stored in PIT, and then the request will be put in the dispose of FIB to be forward to the other nodes through the relevant face. Otherwise, the interest packet will be deleted. The process of sending the interest to the provider and sending data to the consumer is given in Figs. 3 and 4 for the ECCN, respectively.

Fig. 3
figure 3

Process of sending the interest to the provider

Full size image
Fig. 4
figure 4

Process of sending data to the consumer

Full size image

A data field, called time to live (TTL), is used in the data packet to control the data emission flood in terms of the number of hops in the discovery phase. Also, the number of hops from the requesting node (h) is counted and saved in a field in the interest packet. In the CCN architecture, interest packet consists of various information fields such as name, selector, interfaces and etc. Figure 5 shows the operating phase of CCN architecture when an intermediate node receives the interest packet. The similar operation in the ECCN is shown in Fig. 6.

Fig. 5
figure 5

Basic architecture when an intermediate node receives the interest packet

Full size image

Now, as in the CCN architecture, if a node received the data packet, first searches the desired name in the PIT. If one or more dependencies found in PIT, then the data packet will be sent to the relevant face; otherwise data are deleted. When data found in a node, the aforementioned hop count in h field is added by one and moved to TTL of data packet to limit flooding and ensure the data packet is delivered to the original requesting node.

Fig. 6
figure 6

Proposed architecture when an intermediate node receives the interest packet

Full size image

The flowchart in Fig. 7 shows the process of returning data packets to the requesting node in the basic CCN architecture. If the provider node receives interest packet, the value of h will be transferred to the TTL field, and then, the data packet will be sent to the consumer. The TTL field plays a very important role in limiting the wrong release and even the extra release of the data packet. When an intermediate node receives a data packet, it will follow the flowchart of Fig. 8.

Fig. 7
figure 7

Process of returning data packets in the basic CCN architecture

Full size image
Fig. 8
figure 8

Process of returning data packets in the ECCN

Full size image
Table 1 Parameters related to urban scenario
Full size table
Fig. 9
figure 9

Number of replicas of the data packets generated for all three methods; a VS number of interests per vehicle (500 nodes and 40 km/h), b VS number of nodes (one interest and 40 km/h), c VS varying speed of vehicles (500 nodes and one interest)

Full size image
Fig. 10
figure 10

Average interest packet delay with the same condition; a VS number of interests per vehicle (900 nodes and 40 km/h), b VS number of nodes (one interest and 40 km/h), c VS varying speed of vehicles (one interest and 900 nodes)

Full size image

6 Simulation results

The performance of the ECCN is investigated by simulation using the Omnet++ network simulator. Some features such as the data and interest packets structure and CS, NCS, PIT and FIB have been added in the upper layers. To evaluate the performance, both urban and highway environment scenarios have been included. Usually, higher density and low-speed vehicles are considered for urban environment and low-density and high-speed vehicles are considered for the highway environment. Because of the data caching in ECCN, we expect that the ECCN outperform CCN in low-density urban and highway environment.

In a high-density urban scenario, as tabulated in Table 1, the network has between, 500–1200 nodes (vehicles). The parameter ranges are limited to enable to compare with the reference methods [35]. The following metrics are obtained for evaluation:

  1. (a)

    The number of the generated replica of the data packets from source node and the intermediate nodes to the requesting node.

  2. (b)

    The average delay of interest packets; which is the length of time for the successful data return.

The simulation results are obtained by averaging over 50 runs. To the best of our knowledge, two existing works: Basic [1] and the CONET [35] are the most comparable existing work of our proposed architecture and therefore they are selected as the benchmark for the performance comparisons. The other works were too distant to be compared. The CONET solely amended the basic architecture by adding a TTL inside the data packet to control the packet transmission. In Fig. 9 the number of replicas of the data packets generated for all three methods are shown versus number of interests from one to seven from randomly positioned nodes, the network size from 500 to 1200 nodes and speeds from 25 to 55 km/h.

Fig. 11
figure 11

Average interest packet delay with low-density urban scenario (one interest and 40 km/h)

Full size image
Table 2 Parameters related to highway scenario
Full size table
Fig. 12
figure 12

Number of replicas of the data packets generated for all three methods; a VS number of interests per vehicle (100 nodes and 75 km/h), b VS number of nodes (one interest and 75 km/h), c VS varying speed of vehicles (one interest and 100 nodes)

Full size image
Fig. 13
figure 13

Average interest packet delay with low-density highway scenario; a VS number of interests per vehicle (100 nodes and 75 km/h), b VS number of nodes (one interest and 75 km/h), c VS varying speed of vehicles (one interest and 100 nodes)

Full size image

In Fig. 10, the average interest packet delay with the same condition is shown in the diagram. As can be seen, the proposed architecture has better performance than the reference methods, that is mainly owing to the caching in NCS.

Now, consider a low-density urban that is 50–120 nodes on the network. Due to the low density and large distance between nodes, the reference methods are less effective than the ECCN architecture, as the average interest packet delay indicates in Fig. 11.

The next simulations consider low-density highway and the high-speed car scenario. The parameters of the highway scenario are given in Table 2.

In this scenario, the numbers of requesting nodes vary from one to seven with the constant number of nodes. As seen in Fig. 12, by increasing the number of interests from 1 to 7, the basic CCN replica data packet increases by threefold. In contrast, in the proposed ECCN architecture, the number of replicas of the data packets almost follow a constant trend (see Fig. 12a). Now, by keeping the number of requests (just one node), we increase the number of nodes in the network from 50 to 120. As seen in Fig. 12b the ECCN outperforms the basic CCN architecture in the number of replicated packets. The same results for variable speeds and a fixed number of nodes in the network are obtained as shown in Fig. 12c.

The results show that the proposed architecture has significant duplicate data packet reduction compared to the basic CCN and CONET. Finally, the result of a low-density highway scenario is shown in Fig. 13 and almost same advantages for our proposed ECCN are observed.

7 Conclusions and future work

Using content-centric networks in the vehicular environment (VCCN) can create new applications and enhance the system performance. The VCCN faces poor performance in low-density and high-mobility scenarios. This is particularly harmful for delay-sensitive critical data. To overcome this problem, a new architecture for the VCCN by adding an neighbor content store (NCS) to keep critical data is proposed. In the proposed architecture (ECCN), the critical data are distributed and cached in NCS over the source’s neighborhood nodes. The mechanism let to have quick and reliable access to the critical data. In addition, this mechanism lets data coverage extends beyond the radio coverage of the node by its physical movement in low-density scenarios. It is shown by simulation that ECCN can reduce unnecessary interest packet retransmission. Therefore, the number of requests that are being successfully responded will increase and duplicate packets and subsequent network traffic decreases in comparison with the conventional VCCN and CONET. In addition, ECCN reduces the average delay. Theoretical and numerical validation is subject of our future work.