NameCent: Name Centrality-Based Data Broadcast Mitigation in Vehicular Named Data Networks

Named Data Networking (NDN), an extension of the Content-centric network (CCN), is not an unfamiliar word. It is considered as one of the promising future network architecture. NDN focuses on naming the content regardless of end-to-end device addresses. NDN has been adopted for vehicular ad hoc networks (VANETs), and it has promising results. Though NDN has robust architecture, many challenges still exist, including consumer and producer mobility, naming, and Interest and data packet flooding. In vehicular NDN, the consumer vehicle broadcasts an Interest packet for the required content. The producer vehicle or an intermediate vehicle that contains the required content in its cache replies with the data packet after receiving the Interest packet. The data packet reaches the consumer vehicle via simple broadcasting. This data broadcast creates congestion in the network and needs to be mitigated. In this work, we coin a new term called name centrality, and using it along with received signal strength, we have proposed a novel scheme to control data broadcast storm in vehicular NDN. The scheme uses the mentioned two parameters to allow only a subset of potential forwarding vehicles to rebroadcast the data packet instead of all the vehicles which receive the data packets. This reduces the copies of data packets processed and propagated in the network and hence alleviates congestion. The scheme is evaluated through extensive simulation under different scenarios, and it outperforms the legacy schemes. The comparison has been made in terms of copies of total data packets processed, Interest satisfaction delay, and Interest satisfaction rate. Compared to other approaches, the proposed scheme reduced the average copies of data packets processed by 55% and 20% with varying Interest packet rates and 58% and 19% with varying vehicle speed.


I. INTRODUCTION
Vehicular ad hoc networks (VANETs) have been investigated for many years for different applications. VANETs will fuel the development and deployment of autonomous self-driving vehicles by providing them with a communication infrastructure and support from an Intelligent transportation system. Vehicular communication is a challenging class of mobile ad hoc networks (MANETs) due to the high-speed mobility of vehicles and short connection time [1]. The use of conventional WiFi standard IEEE 802.11 family for VANETs The associate editor coordinating the review of this manuscript and approving it for publication was Eyuphan Bulut .
gives rise to several problems due to its communication overhead [2]. Based on IEEE 802.11 standard, IEEE 802.11p was devised to facilitate vehicular communication. However, TCP/IP protocols do not suit well in vehicular communication due to their unique nature. Vehicles move at high speed, and many obstructions frequently occur that cause frequent connection loss [3]. Moreover, lack of infrastructure support for the global IP assignment is also a vital issue in deploying VANETs over IP [4]. For example, the vehicle moves at high speed, and if a vehicle moves from one subnet to another subnet, a new IP address must be assigned within the new subnet. This is because IP addresses bind together the identity of a host and its location [5]. For the smooth deployment of VANETs, a new communication paradigm must be investigated.
Information-centric Networking (ICN) is a proposed architecture for future Internet that focuses on name-based communication rather than host-based. Named data networking (NDN) is an instance of ICN that has gained much attention from the ICN community due to its simple and powerful communication model [6]. Communication in NDN revolves around the content. To retrieve content, the consumer needs to name the content instead of the host having the content as in IP networking. The Interest packet, which contains the name of the required content, is then routed in the network. Once the requested content is found, it is sent back toward the consumer on the reverse path followed by the Interest packet. NDN also supports in-network caching that caches data in the network caches and enables the network to provide the requested content with a minor delay. NDN maintains three data structures to support the forwarding of a packet, i.e., Pending Interest table (PIT), Content store (CS), and Forwarding Information Base (FIB) [7]. Content store is the in-network cache that stores contents according to a predefined policy. PIT keeps the record of outgoing Interests such as name and incoming interface. Once the requested content is received on a node, the PIT helps direct the data packet in the reverse direction of the Interest. FIB is similar to the traditional FIB in IP networking; however, in NDN, FIB stores name prefixes instead of IP addresses. FIB help in sending the Interest upstream towards the requested content.
Due to its simple and powerful communication model, NDN has recently been adapted for vehicular communication called Vehicular NDN (VNDN) [8]- [10]. In IP-based VANETs, each node is identified by a unique ID or an IP address that makes it accessible via this unique host ID. Moreover, to exchange sensitive information, the channel between the source and destination node must be secured. Since the connection is frequently disrupted due to mobility, the session establishment is a time-consuming process, especially in cases where the node ID changes after mobility. Therefore, mobility is a severe problem in traditional VANETs. NDN is free of these problems of IP networking. The merits of using NDN for vehicular communication are: • NDN does not require host IDs for communication. • NDN does not need an end-to-end session establishment.
• The channel security is not an issue. In NDN, the content itself is secured, not the channel.
• Since the node does not need host IDs for communication and session re-establishment, most of the mobility problems are relieved.
• Content in NDN is retrieved by its name regardless of its location.
Due to the merits of NDN, it can enhance network performance and simplify the deployment of VANETs [11]. In VNDN, due to the broadcast nature of the wireless medium, Interest packets are received by multiple nodes, which in turn insert PIT entry for the name mentioned in that Interest packet. The data packet containing the name and the actual content that was requested is then broadcasted to reach the consumer. The data will be processed and further rebroadcasted by all the nodes with the corresponding PIT entry for that named content, resulting in a data broadcast storm problem in VNDN. This data broadcast storm problem is a severe issue and creates congestion in the network by propagating multiple redundant copies of the heavy data packets, which also wastes bandwidth resources and causes packet drops and extra delays in retrieving the content. This problem could be more relevant in VANET's infotainment applications. To solve this problem, we proposed a name centrality and the signal strength-based algorithm called NameCent.
We originated the term ''name centrality'' after we found that the conventional node centrality is not efficient in finding a node that is more central in VNDN. Name centrality is a per prefix-based centrality of a node. This means that the number of Interests for the same content received by a node from distinct neighbors is the name centrality of the node for that name prefix. Name centrality is further explained in detail in section IV-A. In our proposed NameCent scheme, we use name centrality along with the received signal strength indicator to select a subset of potential forwarders that will further process the data packet. To implement this, we included an additional weight field in the Interest and data packets. The weight is calculated based on the mentioned two metrics, i.e., name centrality and received signal strength indicator. The weight value indicates the suitability of each potential forwarder, and based on it, only a subset of potential forwarders will process and forward the data packet, thus mitigating the total copies of the data packet processed and reducing the Interest satisfaction delay. The major contributions of this paper are as follows: • A new term called the name centrality in NDN has been originated that finds a vehicle that is more central than others in NDN-based vehicular ad hoc networks. This name centrality could prove very effective in designing routing and forwarding schemes in NDN-based networks.
• Using name centrality and the RSSI, we design an equation to calculate weights for each potential forwarder.
• We design the forwarding algorithms that efficiently forward data toward the consumer without causing congestion.
• Simulation in ndnSIM to verify the performance of our scheme compared to the relevant schemes.
The remainder of this paper is organized as follows. A brief description of the VNDN communication paradigm is given in section II. Section III briefs the background research efforts in VNDN to solve different research issues, including data broadcast storm mitigation problems. Section IV describes our proposed algorithms in detail, and the performance comparison is given in section V. Finally, we conclude this paper in section VI. VOLUME 9, 2021

II. VNDN IN A NUTSHELL
Many ICN architectures were proposed, including NDN, mobilityFirst, network of Information (NetInf), data-oriented network architecture (DONA), etc. [12]. All the proposed ICN architectures are working on the principles of name-based network layer communication instead of host-based communication supported by IP addresses. Among these architectures, NDN gained much attention from the research community.
NDN communication is based on named content and supports only pull-based communication. However, there is much literature that presents push-based communication support in NDN for vehicular and IoT applications [13], [14]. NDN forwarding is supported by three data structures, i.e., CS, PIT, and FIB. The VNDN is similar to the basic NDN except for minor changes in the VNDN forwarding plane, which has now been adopted in NDN too. In NDN, the CS lookup is the first step after the Interest packet receives [7]. However, CS lookup operation is expensive and causes delay. Therefore, in VNDN and now in NDN, too, PIT match operation occurs first and then CS lookup if no PIT entry matches.
In VNDN, when a node/vehicle requires content, it broadcasts an Interest packet containing the name of the required content. After the Interest is received by the neighboring node(s), perform the operations mentioned in figure 1. Interest packet carries a NONCE; this NONCE is checked against the dead nonce list (DNL). If a match is found, the Interest is considered a loop and discarded. If there is no match in DNL, the Interest is checked against PIT. If a PIT match is found, the Interest is considered looping Interest and gets dropped. If there is no entry in the PIT, a PIT entry for this Interest is created, and then CS lookup occurs. If data is found in the CS, it is broadcasted towards the consumer. If the CS lookup fails, the Interest is forwarded based on the longest prefix matching FIB entry. Likewise, when a data packet is received on an NDN-enabled node. PIT entry for that data packet is check-in the PIT table. If no match is found, the data is deemed unsolicited and discarded. If a match is found, the data is the first cache according to the caching policy and then forward it downstream.

III. BACKGROUND AND RELATED WORK A. DATA RETRIEVAL IN VNDN
Due to the advantages of NDN in the VANETs scenario, researchers have put effort into applying NDN in VANETs, and many problems have been identified, and efforts have been made to solve the problems [15]. NDN shows promising results in VNDN. However, VNDN is still in infancy, and it should be further researched to maturity. The authors in [10] developed a VNDN prototype and evaluated its performance for data acquisition, and showed the feasibility of NDN for VANETs. In [16], the authors proposed a VNDN framework to increase the data retrieval success rate. However, this work increased the cost of data retrieval by selecting an extra set of vehicles to participate in data retrieval. Authors in [17]  extended the Interest packet to acquire the data from different providers and to avoid flooding yet enhance the data retrieval rate. This scheme suggests significant changes to the basic NDN primitives. In [18], the authors use NDN for efficient data acquisition in vehicular communication; however, the author ignores the consumer mobility problem. Researchers have also focused on Interest broadcast control in VNDN, which in turn also control data broadcast storm. Authors in [19] proposed a scheme to control Interest broadcast storms in VNDN. In this work, every vehicle shares its recent satisfied Interests list with its neighbors, and this information is stored in the neighbor satisfied list, which is later used for the selection of forwarders for the Interest packet. However, the Interest flooding problem is not as severe as the data broadcast storm problem due to the small packet size of the Interest.

B. DATA BROADCAST STORM MITIGATION
Authors in [20], [21] first explored the data broadcast storm problem in VNDN and proposed a solution to mitigate it. They proposed a simple yet very effective solution to the problem. In their proposed ''CODIE'' and ''CONET'' scheme, they limit the data packet to traverse a number of hops equal to or few more than that of its corresponding Interest packet. This scheme significantly reduces the copies of data packets processed in the network. However, its efficiency drops when there are frequent mobility events in a dense network. In such scenario, the data might need to traverse more hops than the corresponding data packet to reach the consumer. Another work [22] proposed an extended CCN architecture to improve data access in a vehicular network. The work claims better results than [21]. However, the scheme used the in-network caching feature of NDN to provide critical data in a few hops, which in turn also decreases the Interest satisfaction delay and copies of data packets processed. In [23], neighbor distance, node density, and closeness are used to select the potential data forwarding nodes. However, to keep updated neighbor distance in the neighbor table in a high mobility scenario needs a very frequent exchange of neighbor information. How frequently this information must be exchanged has not been discussed in the paper. Moreover, the overhead caused by these exchanges has also been ignored. Authors in [24] also proposed a scheme to control data broadcasts storm in VNDN by proposing a naming scheme. The scheme is successful in mitigating the data broadcast storm by limiting it to the concern RSU range. However, this scheme first suggested a unique vehicle ID for each vehicle which itself is a problem that traditional VANETs are facing. Ensuring and assigning a unique ID is a complicated process. Moreover, if the data is required in the neighboring RSU's range, it will not be propagated there. The proposed NameCent mitigate the data broadcast storm without adding extra control overhead in the network. Moreover, it does not suggest major changes to the basic NDN primitives.

IV. PROPOSED SCHEME
In network analysis [25] and wireless sensor networks [26], the centrality of a node or finding a node that is more central than others has been a critical issue. Knowing node centrality helps in the dissemination of Data efficiently. However, after critical analysis of the Pending Interest Table (PIT) in NDN, we found that a high degree of node centrality may not be helpful in forwarding data towards the consumer in NDN, as discussed in the next section. To that end, we coin a new term called ''name centrality'' in NDN to select more robust node(s) to forward the data to the consumer. NDN is based on pull-based communication and only nodes which have PIT entry for a particular prefix process and forward the matching data packet upon reception. We argue that name centrality is a more accurate metric for the selection of forwarder nodes for the data.

A. NAME CENTRALITY
We define name centrality for ''prefix1'' of a node ''A'' in VNDN as ''the number of copies of a particular Interest packet for ''prefix1'' received by node ''A'' from distinct neighboring nodes.'' Imagine figure 2, where a vehicle ''X'' has five other vehicles in its wireless range and hence has a high degree of node centrality than node ''Y,'' which has only three nodes in its wireless range. On the contrary, the name centrality of node ''Y'' is two as it receives Interest packets for data ''z'' from two different neighbors, while the name centrality of a node ''X'' is one as it receives only one Interest for data ''z'' from only one of its neighbors. If both vehicles ''X'' and ''Y'' receive a data packet for data ''z'' at the same time, vehicle ''Y'' will be a more appropriate forwarder in this scenario based on name centrality. For a particular node ''A''; • Name centrality for a prefix is always less than or equal to its degree of node centrality.
• It has only one degree of node centrality at a particular time, but it may have many name centralities, one for each prefix.
• Node centrality is per node-based, while name centrality is per prefix-based.

B. RECEIVED SIGNAL STRENGTH INDICATOR
Received signal strength indicator (RSSI) is the estimated measure of power level that a wireless client device receives from an access point or another wireless client device. The level of RSSI indicates the lifetime and robustness of the connection between the two wireless devices. The high level of RSSI indicates that either the two wireless devices are physically near each other, or there are low path losses or no obstructions between the two devices, as shown in figure 3. Suppose that the name centrality for a particular prefix is the same for both v1 and v2 in figure 3. The weight calculated by v3 for v1 will be higher than v2, although the distance between v2 and v3 is less than the distance between v1 and v3.
The signals of v2 are obstructed by the trees and buildings and block the line of sight among the two vehicles. In the vehicular environment, a node receives Interest packets via multiple paths and from more than one neighbor with different RSSI levels based on the distance and path losses among the two devices. We use this RSSI level and name centrality to devise a mechanism for the selection of a more robust and reliable forwarder node. A detailed description of our scheme is explained below.

C. NAMECENT DESCRIPTION
In our proposed scheme, every Interest and data packets carry a weight value. Therefore, we included an additional weight field to both the Interest and Data packet format. After receiving an Interest packet, every node calculates its weight for that requested name based on (1). Before rebroadcasting the Interest packet, it put the weight value in the weight field.

VOLUME 9, 2021
This value is then later used to choose the forwarder(s) node for the corresponding data packet.
In (1), W in is the weight of forwarder i for prefix ../prefix/n. The RSSI Fin is received signal strength indicator of forwarder i for prefix ../prefix/n, and RSSI max is the maximum RSSI to normalize the term. NameCent Fin is name centrality of forwarder i for the requested name prefix n, and NameCent max is the maximum name centrality for normalization of the term. The highest RSSI and name centrality values recorded during the simulation were taken as RSSI max and NameCent max , respectively. α is weight factor in setting the influence of RSSI and name centrality on the calculated weight. Since the name centrality count (Ncc) value at the time when the Interest for the first chunk of data is forwarded by any node is 1, the 2 nd term in (1) becomes constant. Thus for the first Interest packet the equation becomes: For the following Interest packets, the Ncc would have been updated, the weight is calculated based on (1). Practically, the name centrality in (1) of forwarder i for prefix ../prefix/n is actually the name centrality for prefix ../prefix/n − 1, and the name centrality for prefix ../prefix/n − 1 is actually the name centrality for prefix ../prefix/n − 2 and so on. We have also included an additional data structure called centrality table (CT ) shown in Table 1. This table keeps the record including requested prefix, weight value received in the Interest (senders' weight or Pnw), current node weight (Cnw) calculated using (1) and name centrality count (Ncc). Each record has an expiry timer, after which the record is deleted from the CT. The expiry timer for the record entry in our simulation is 5 seconds. The expiry timer ensures avoiding memory overhead on a node due to CT. When an Interest is received, this Ncc value is incremented and then used in (1). Similarly when a data packet is received on a node, the node get the weight value (Cnw) from its CT and compares it with the weight value in data packet to decide whether this is appropriate forwarder or not. The algorithms below explain the proposed NameCent scheme in detail. Algorithm 1 shows step by step process when an Interest is received in VNDN. When the Interest is received, its nonce is checked in DNL for loop detection. If it matches, the Interest is discarded. The Interest is then checked in PIT, and if there is no PIT entry for the name, the prefix, weight, and Ncc is inserted into the CT . The weight value is copied from the Interest packet, which is the previous node weight (Pnw). In the next step, the Ncc is taken from the CT , and current node weight (Cnw) is calculated using (1) and inserted into the CT. If the name already exists in PIT, the Interest packet is redundant or looping Interest. It is dropped, but before Get Ncc from CT and calculate Cnw using (1) 6: Put Cnw in CT 7: if (Content Not in CS ) then 8: weight = Cnw 9: Forward Interest using FIB 10: else 11: Take average of all the Pnws for the prefix 12: Data packet weight field = average (pnw) 13: Send Data 14: end if 15: else 16: Increment Ncc value in CT 17: if (Name == prefix && weight >= pnw) then 18 Drop Interest 24: end if dropping it, the Ncc value is incremented, and if the weight in this Interest is higher than or equal to the existing weight values in the CT , the Pnw is updated as shown in steps 15 to 18 of algorithm 1. If the content is not found in the content store (CS) of the node, the Cnw is moved to the weight field of the Interest packet and broadcasted further. If the content is found in the content store, the average of all the Pnws under the current name prefix is taken, and the average is then copied to the weight field of the data packet and broadcasted.
Algorithm 2 shows how the data packet is processed in the proposed NameCent scheme in VNDN. When a data packet is received, and the face is not application face (current node is not the consumer), the Cnw is fetched from the CT and compared to the value in the weight field of the data packet, as shown in figure 4. If Cnw is greater than or equal to the weight value, this node is selected as the forwarder and will further forward the data packet using broadcast. Before broadcasting the data packet, its weight field is updated with an average of Pnws at the current node. The mechanism is also shown in figure 4, where node X, Y, and Z receives a data packet from the producer containing the weight value, which is the average of Pnws at the producer node as shown. Each node compares this weight value with its Cnw. Since node  X and Z's Cnw is greater than the weight value in the Data packet, they are selected as the next forwarders while node Y's Cnw is smaller than the weight; hence it will not process the data packet. Here it is to be noted that the NDN forwarding daemon (NFD) uses face abstraction, which abstracts a communication channel that NFD can use for packet forwarding. Forwarding daemon in NDN sends and receives Interest and Data packets through faces. When the NFD receives a packet from the application through an abstract face, it assigns a numeric ID to that face, and this face is defined as the application face. Although the proposed NameCent scheme outperforms the legacy schemes as discussed in the next section, there are some limitations too. VNDN currently does not support push-based communication; however, it is an important characteristic of VANETs, and researchers have made efforts to propose push-based communication solutions in VNDN. The proposed NameCent cannot be applied to control data broadcast in a push-based communication scenario in VNDN.

V. PERFORMANCE EVALUATIONS
We evaluated the performance of our proposed scheme and compared it to naive NDN and codie [20] through extensive simulations in ndnSIM [27], which is an ns-3 based NDN simulator. The evaluation metrics are: if (Cnw >= weight) then 6: Take average of all the Pnws for the prefix 7: Data packet weight field = average(pnws) CDPP is the total copies of the data packets processed in the network. A data packet is received, processed, and forwarded by many intermediate vehicles while moving from producer towards consumer due to the broadcast nature of the wireless medium. The purpose is to minimize this processing and forwarding of the data packet by each intermediate vehicle. ISR is the ratio of the Interest packets sent and the corresponding data packets received by the consumer. ISD is the end-to-end VOLUME 9, 2021 delay when an Interest packet leaves the consumer node and when the corresponding data packet receives. The goal was to minimize the copies of data packets processed and sent in the network, which in turn also reduced the Interest satisfaction delay without compromising much on the Interest satisfaction rate.

A. SIMULATION ENVIRONMENT
We simulated the vehicular environment in ndnSIM and implemented all the schemes. IEEE 802.11p was used as a single channel operation, which is standard for physical and Datalink layers in vehicular communication. For a more realistic vehicular mobility scenario, SUMO [28] was used to generate a three-lane one direction highway mobility scenario of 5 km. We ensure that the highway is densely populated to create a severe congestion scenario. We varied the vehicles' speed from 70 kmph to 110 kmph and the network size ranging from 50 nodes to 110 nodes. The transmission range of each node (vehicle) was 250m. In-network caching was completely disabled on all nodes to evaluate the full potential of our proposed scheme. If we enable in-network caching, there will be a high probability that the consumer can find the requested data with its immediate neighbor, and we would not be able to evaluate the full potential of the proposed schemes. We varied the number of Interests sent by each consumer vehicle from 1 to 7. Complete simulation parameters are summarized in Table 2 below.

B. RESULTS AND DISCUSSION
The results for total copies of data packets processed in the network have been taken against varying Interest 5(a), varying network size 5(b) with Interest frequency of 1 and 3 Interests per second per consumer vehicle and varying speed as shown in 5(c). As evident from figure 5, the total copies of data packets processed in our proposed scheme have been substantially reduced compared to codie and to a great extent compared to naive NDN. Precisely, the average copies of data packets processed have been reduced at an average of 55% compared to naive NDN and 20% compared to codie with varying Interest packets. Similarly, the copies of data packets with varying speed in the proposed scheme have been reduced by 58% compared to naive NDN and 19% compared to codie. A similar trend can be seen with varying network sizes. This performance has been achieved due to the vehicles' restricted data forwarding based on name centrality and received signal strength indicator. Since only a subset of nodes is allowed to rebroadcast the received data packet, a lesser number of data packets are processed by each node. Our name centrality-based scheme has achieved its target goal without compromising the Interest satisfaction rate, as shown in figure 6. This better performance of the NameCent compared to Codie is because in Codie, every vehicle that receives a data packet process and forwards it unless the data packet's hop count reaches a threshold based on the hop count of the corresponding Interest packet.
The ISR achieved in the proposed scheme is comparable to Codie and naive NDN. There is no considerable drop in ISR in the proposed scheme. The reason for low ISR at network size 50 in figure 6 (b) is due to the sparsely populated network, which causes packet drops hence reducing the ISR. From network size 60 to 110, there is a small variation in the ISR, and this variation is because of the congestion due to increased network density and uncertain vehicular environment. Moreover, our scheme uses less bandwidth and reduces congestion since only the most reliable and robust vehicles are selected as the potential forwarder nodes based on equation (1) above. The proposed scheme results in comparable ISR, mitigating the copies of data packets processed significantly. Interest satisfaction delay is also a critical performance metric in a vehicular environment.
Due to the highly dynamic nature of the vehicular environment and short-lasting connections due to mobility, low ISD is vital. The ISD becomes a critical parameter for vehicular safety applications as very low ISD is required for critical data retrieval. We have compared the Interest satisfaction delay achieved in the three schemes as shown in figure 7. The proposed scheme achieved lesser delay during content retrieval compared to Codie and naive NDN. The reason behind low ISD in the proposed scheme is the congestion alleviation that causes the packets to wait for less time in the in/out queue of the nodes brings about low ISD. Since Codie does not restrict the vehicles from processing the data packets unless it reaches a certain hop count, there is still congestion in the network region where the consumer and producer are communicating. This causes extra delay at the queue of the forwarding vehicles; hence the ISD in Codie is higher than the NameCent.

VI. CONCLUSION AND FUTURE WORK
In this paper, we have proposed NameCent scheme to control data packet broadcasts storm. Since the data packets in NDN are larger than Interest packets, broadcasting it over the wireless medium creates congestion and may choke the network in the worst cases. To solve this problem, we coined a new term, ''name centrality,'' and used it along with the received signal strength indicator to select only a subset of vehicles that will rebroadcast the data packets after receiving them from the neighbors. The name centrality translates to the vehicle's robustness as a potential forwarder for the data packet, whereas received signal strength indicator shows the link lifetime in a high mobility scenario. A combination of these two factors can choose the most appropriate and reliable vehicle as the forwarder. The simulation results show that our scheme achieves its goal by minimizing the total copies of data packets processed and lowering the Interest satisfaction delay without compromising on the Interest satisfaction ratio. In future work, we will further investigate the efficiency of name centrality in data dissemination in resource-constrained wireless sensor networks and IoT scenarios.