DOI:10.32604/cmc.2022.028619
| Computers, Materials & Continua DOI:10.32604/cmc.2022.028619 | |
| Article |
SAFT-VNDN: A Socially-Aware Forwarding Technique in Vehicular Named Data Detworking
1Laboratoire d’Informatique et de Mathématiques, Université Amar Telidji de Laghouat, Laghouat, Algeria
2Department of Computer and Electronics Systems Engineering, Hankuk University of Foreign Studies, Yongin-si, 17035, Gyeonggi-do, Korea
3School of Computer Science and Technology, Kean University, NJ, USA
*Corresponding Author: Daehan Kwak. Email: dkwak@kean.edu
Received: 14 February 2022; Accepted: 13 April 2022
Abstract: Vehicular Social Networks (VSNs) is the bridge of social networks and Vehicular Ad-Hoc Networks (VANETs). VSNs are promising as they allow the exchange of various types of contents in large-scale through Vehicle-to-Vehicle (V2V) and Vehicle-to-Infrastructure (V2I) communication protocols. Vehicular Named Data Networking (VNDN) is an auspicious communication paradigm for the challenging VSN environment since it can optimize content dissemination by decoupling contents from their physical locations. However, content dissemination and caching represent crucial challenges in VSNs due to short link lifetime and intermittent connectivity caused by vehicles’ high mobility. Our aim with this paper is to improve content delivery and cache hit ratio, as well as decrease the transmission delay between end-users. In this regard, we propose a novel hybrid VNDN-VSN forwarding technique based on social communities, which allows requester vehicles to easily find the most suitable forwarder or producer among the community members in their neighborhood area. Furthermore, we introduce an effective caching mechanism by dividing the content store into two parts, one for community private contents and the second one for public contents. Simulation results show that our proposed forwarding technique can achieve a favorable performance compared with traditional VNDN, in terms of data delivery ratio, average data delivery delay, and cache hit ratio.
Keywords: Vehicular Social Networks (VSNs); Vehicular Named Data Networking; forwarding technique; social communities
Vehicular Ad Hoc Network (VANET) has been envisioned as one of the most promising research areas in the last decade. It aims at improving drivers’ safety and creating a comfortable driving environment. Besides, it allows inter-personal communication and entertainment for drivers and passengers. VANET features three main communication models: (i) Vehicle-to-Vehicle (V2V), it enables vehicles to connect directly with each other. (ii) Vehicle-to-Infrastructure (V2I), in this model vehicles are allowed to exchange and store data in central or distributed infrastructures. (iii) In the Hybrid model, vehicles are enabled to connect with distant vehicles and infrastructure nodes using multi-hop communication scheme. Due to the advances in mobile industries and social media, VANETs know a new research direction giving birth to the first social characterized vehicular network, referred to as vehicular social network (VSN) [1–8]. The fundamental brick of VSN design is communication and content sharing, forwarding, and disseminating, which are directed by humans’ relationships, common interests, and mobility patterns under what we call a community.
However, current VSNs are based on the traditional host-centric TCP/IP architecture that requires connection establishment between communication end-points before starting the data retrieval process [9] Using such architecture may result in (i) increasing significantly end-to-end transmission delay and (ii) degrading dramatically the network performances. The latter can be enhanced if we can retrieve the required content from a geographically nearest node.
Another research direction that has attracted researchers’ and industries’ eyes is Named Data Networking (NDN) [10]. Unlike host-centric architecture, NDN is a promising Content Centric Network (CCN) [11,12]. architecture designed to enhance the data distribution in the network. Similar to CCN, NDN also presents an effective communication paradigm that puts content chunks at the center of its communication model. Hence, content retrieval and distribution processes are accomplished via name-based routing and forwarding. However, NDN incorporates several architecture modifications to improve the interest and data packet look-up time as well as to reduce the interest looping issue. The NDN mechanism can naturally support data multihoming and mobility of a large-scale network. As well as allowing applications to name content they want to fetch or provide [13]. Such a mechanism is also gaining momentum in vehicular networks as a shift communication paradigm from the classical TCP/IP end-to-end communication scheme.
Several studies have investigated NDN deployment in VANETs (VNDN) [14–17]. In the basic architecture, a consumer sends an interest packet to acquire the requested content after being advertised earlier by the producer. Then, each intermediate node can keep a copy of the data packet in their caches to satisfy future requests [18,19]. In this regard, Al-Qutwani et al. propose a forwarding technique called RAFS based on unicast paths [20], In [21], Xu et al. propose a new protocol called COMPASS based dynamic directional interfaces. However, the latter mechanisms suffer from link and interface failures, GeoZone is a naming and Forwarding Mechanism proposed in [22] and a vehicular backbone architecture based on cluster-chain [23] has been proposed to improve the performance of data dissemination in VNDN.
Despite the advantages of each solution, broadcast communication under high mobility conditions can result in serious packet flooding issues such as packet collisions and redundancy [24]. In addition, the unexpected changing topology may also lead to frequent disruptions of the data packet delivering and frequent data replacement in caches, which increases cache misses and consequently delay the data delivery [25,26]. Therefore, it is necessary to implement an efficient caching mechanism that selects and keeps the popular data in the Content Store as long as possible.
We aim to improve content delivery and cache hit ratio, as well as decrease the transmission delay between end-users. Hence, we propose in this paper a novel approach called “a Socially-Aware Forwarding Technique in Vehicular Named Data Networking” (SAFT-VNDN). In our proposal, we introduce the social community concept into VNDN. A social community in our work represents a group of vehicles (drivers or passengers) that share similar interests or visit the same destinations. For instance, football club fans, taxi drivers, travel clubs, cinema fan communities, etc., are interested in the same news and generally request the same data or videos. Thus, we have proposed:
1. An opportunistic caching scheme that divides the content store (CS) into two parts, one for community contents and the second one for general contents. Such a mechanism can optimize the data delivery and the cache-hit ratios.
2. A forwarding scheme that relies on selecting the most suitable forwarder from community memberships. This can reduce the interest packet broadcast problems while increasing the probability to find data among community members.
The remainder of the paper is organized as follows: Section 2 provides an overview of Vehicular Named Data Networking VNDN. Section 3 describes the network model and the details of our proposed SAFT-VNDN approach. In Section 4, we present the simulation setup and discuss the achieved performance. Finally, Section 5 concludes the paper.
2 Vehicular Named Data Networking
The deployment of NDN over VANET as an alternative to the traditional TCP/IP communication model has conceived a new hybrid network, which is called Vehicular Named Data Networking (VNDN) [14,15]. The substantial concept of VNDN is to benefit from the NDN prototype, which concentrates on delivering data regardless of its physical location.
• Consumer: it initiates the content fetching process by broadcasting an interest packet in the network.
• Producer: it makes content available in the network by generating and advertising them. It also replies by a data packet containing the requested content in response to a previously received Interest packet.
• Forwarder: it transmits (forwards) interest or data packet until they reach their final destination, either a producer or a consumer respectively.
• Data-mule: it carries contents previously received while moving without having network connectivity. This feature is allowed to VNDN vehicles thanks to its caching data structure referred to as Content Store (CS). Such a content store is used to save the received data packets to satisfy future requests.
As depicted in Fig. 1, each VNDN node has the following data structures.
• Pending Interest Table (PIT): PIT is indexed by content names extracted from the previously received interest packet but was not satisfied yet by the network. The PIT also records the incoming and outgoing interfaces for the pending Interests.
• Forwarding Information Base (FIB): This is similar to the classical TCP/IP routing table except that it is indexed by content hierarchical names rather than IP addresses.
• Content Store (CS): it is used to store the incoming data packets so that the subsequent requests can be accommodated.
Figure 1: VNDN forwarding model
Packet forwarding in VNDN can be divided into two phases based on the type of packet being forwarded (i) interest packet forwarding, and (ii) data packet retrieving [22]. The details of these two phases are as follows:
• Interest Packet Forwarding: To retrieve a specific content from the network, a VNDN node acts as follows:
– The consumer broadcasts an interest packet. (Vehicle A in Fig. 1.)
– Upon receiving the interest packet, an intermediate vehicle (e.g., vehicle D in Fig. 1) matches the name of the requested content to its CS to determine whether a fresh copy of the content object already exists or not. Hence, there are two cases:
a)If the desired content exists, the intermediate vehicle sends back a data packet towards the consumer.
b)It checks its PIT table for a possible entry. If there is a corresponding entry, it discards the interest packet immediately (because it has already forwarded the same interest packet). Otherwise, it adds a new entry in the PIT table and forwards the interest packet after performing a FIB lookup to find the most suitable next-hop.
• Data packet retrieving: Upon receiving a data packet, a vehicle first checks its PIT for a corresponding entry for the content name included in the data packet. If a name matches, it saves a copy in its local CS and forwards the packet immediately to all incoming interfaces aggregated in the matching PIT entry (vehicles C, D, E, F in figure Fig. 1). Otherwise, it discards the data packet as it is considered unsolicited.
3 SAFT-VNDN: A Socially Aware Forwarding Technique in Vehicular Named Data Networking VNDN
In this section, we present the details our proposed SAFT-VNDN, which is a novel hybrid VNDN-VSN forwarding technique. The key contribution of SAFT-VNDN is the solution it provides to improve content delivery and cache hit ratio while also reducing transmission delay between end-users. We believe that the establishment of social communities between vehicles in urban environments will increase the probability of finding the data, since vehicles with a common interest are supposed to meet more frequently as compared to vehicles with different interests. Hence, this will lead to reducing the number of hops. In another word, vehicles will be able to request contents and to find easily the most suitable forwarder or producer among the neighbor community members.
In our proposal, we consider a hybrid VNDN-VSN network where vehicles use IEEE 802.11p. We assume also that each requester node in the network can track the location of the original data producer thanks to the Grid Location Service (GLS) [27]. We also assume that communities are defined beforehand (community construction is discussed in the next section). Vehicles can join or leave communities based on their interests extracted from the VSN applications (user’s profile).
A community is defined as a group of individuals from all different backgrounds, who probably have never met yet, but who have similar lifestyles, share similar interests, or visit similar places. In line with Vehicular Social Networks (VSN), the notion of social community has been also extended to vehicular environments. In such communities, common interests, geographical location, and mobility patterns can hold vehicles, RSUs, drivers, passengers, and pedestrians’ smart devices together in the virtual community of vehicles [2–8]. Hence, social communities can be used to enhance data delivery thanks to the social behavior of nodes and social ties between them.
3.2.1 Construction of Social Communities
In our work, we suppose that all social communities are constructed beforehand by a trusted entity (i.e., certification authority CA). A CA is also responsible for (i) creating, (ii) certifying public keys as well as (iii) signing or validating anything that has a relation with the social communities (Fig. 2). Each social community must be identified by a hierarchical name conformed to NDN, and a set of keys that represents an authentic online identity for community members, so they can activate a secure session between them. To identify community members, we assume that each vehicle in the network is equipped with a specialized device, which interfaces with community cards. These cards are issued by the trusted entity discussed previously, which creates revolved accounts and binds them to a set of keys to use them as an authentic online identity for cardholder (i.e., community members). The community cards’ lifetime can be relatively short or long depending on the sensitivity level of the exchanged information in the community.
Figure 2: SAFT-VNDN forwarding model
3.2.2 Modeling of the Community Construction
Due to VNDN’s fundamental properties, global information about nodes is often impossible to gather in practice. There is also the phenomenon of overlapping communities, that is, some nodes are members of not only one but two communities. As a result, using a typical community recognition method to determine VNDN’s community is problematic. We employ a local community detection approach based on core nodes in this study. The algorithm’s steps are as follows:
Step 1: Determine the node’s center value.
The center value of node
Step 2: Identify the seed nodes.
Step 1 is used to determine the center value of all nodes, and the nodes with the highest center value are chosen as prospective seed nodes. We eliminate certain nodes according to the algorithm below to avoid the selected nodes being in the same community:
where
Step 3: Expand the community.
The fitness function of a given community S is defined as:
The total of the internal node degree in S is
The fitness function for S for a given node
where,
Step 4: Combine communities that are redundant.
The degree of overlap between communities is calculated as follows:
where,
The fifth and final step consists of: Continue using Steps 3 and 4 until all nodes have been assigned to the communities.
A vehicle can belong to different communities at the same time. Moreover, each community is ranked from one to four (one being the highest priority). This ranking mechanism can be done according to the vehicle’s interest in the content produced and shared by community members (the degree of interest can be extracted from the user’s profile). We suggest using a priority-based cache replacement technique to delete the oldest content when the reserved cache space of communities is full. This way we can release space for the incoming communities’ contents.
In order to leverage the NDN name-based routing principles, we extend its hierarchical naming scheme to efficiently address VSN applications, end-users of a particular VSN, and the contents produced by end-users. Fig. 3 shows the content names structure used in our approach and Tab. 1 describes each field.
Figure 3: Content name structure
3.3.2 Modified Cooperative Awareness Message (CAM) Structure
In ETSI architecture [28], Cooperative Awareness Message (CAM) are heartbeat messages diffused continuously to provide periodic status information to ITS stations located in the close vicinity (OBU and RSU). They are often transmitted using the Single-Hop Broadcast (SHB) protocol when a vehicle is in a safety-relevant situation. A CAM is composed of one common ITS PDU header and shall comprise several data containers (Fig. 4), either mandatory or optional, which together constitute a CAM. The common ITS PDU header includes the information of the protocol version, the message type, and the basic attributes of the transmitting ITS-S [28].
Figure 4: Modified structure of a CAM
A CAM may also include:
• Interest One basic container that provides basic ITS-S-related data.
• One high-frequency container that provides highly dynamic data of the ITS-S. i.e., vehicle movement status and basic vehicle sensor data.
• One low-frequency container that provides static and non highly dynamic data of the ITS-S.
• One or more vehicle container that provides information specific to the vehicle role of the sender ITS-S, like roadwork vehicle, emergency vehicle, public transport vehicle, etc.
To adapt CAM messages with community awareness, we attempt to define a new low-frequency LF container composed of the following two optional containers as in figure Fig. 4:
• Interest community list: provides the IDs of all the communities that the vehicle belongs to.
• Active communities: provides the current active community, in other words, the community that the vehicle is currently interested in its produced content.
Each receiver of the CAM message will extract its nearby vehicles memberships and store them in the neighbors’ table grouped by communities names to use them in the future forwarding processes (Tab. 2).
The design of the basic VNDN requires that each vehicle in the network hosts three main data structures FIB, PIT, and CS. In our approach, we retain the same PIT behavior as proposed in the original NDN. Same thing for FIB; however, we have decided to divide the CS into two equal parts: one-half for community contents and the other half for general data. Therefore, as illustrated in Fig. 5 we have added one new field in the CS “community” which refers to the name of the community that produces the stored content. The vehicle saves all the received data packets that correspond to PIT entries in its CS. It can save all the received community data packets even if there are no matching entries in the PIT. This solution can increase the probability of finding the data in the area.
Figure 5: New VSN node design
• Social contents accessibility: We have two categories of contents: (i) ‘Public contents’ accessible by all vehicles in the network and (ii) ‘Private contents’ accessible only by community members (encrypted contents). One vehicle can request any data content by indicating its name in the interest packet, but if the requested data is private, only community members (CM) can decrypt it using their community IDs. The other vehicles that are unable to decrypt the data can simply discard the data packet or ask to join the community.
• Interest and data packet forwarding process: Two different cases can be recognized in our proposed data retrieval approach since we have two categories of contents (i.e., public and private): (i) the first case is when the vehicle requests for general VSN contents, (ii) the second case is when the vehicle requests for VSN community contents.
3.3.4 Retrieving VSN General Contents
The forwarding action taken by the requester vehicle consists of generating an interest packet and then finding the most suitable forwarder following the same VNDN forwarding process as shown in Fig. 6. Before triggering the forwarding action, the requester vehicle creates a PIT entry for the interest packet and checks for a matching FIB entry. If there is a match, the outgoing-face will be used. Otherwise, it forwards the interest message to all neighboring vehicles in the transmission range. In the next step, after receiving the interest, each vehicle in the path towards the content producer who carries a fresh version of the fetched content in its CS, can play the role of data-mule [29], and send data packets back to the requester using the defer timer
Figure 6: Performed actions to retrieve general VSN contents
3.3.5 Retrieving VSN Community Contents
In the second case (see Fig. 7), the forwarding action taken by the requester vehicle is slightly different from the first case, since we have introduced the notion of communities. The requester vehicle generates an interest packet, then checks if there are any community members (CM) in the neighboring area. As mentioned above, each vehicle must build its neighbor table and store in it all the neighbor vehicles’ memberships to use them in the forwarding process. We summarize this operation as follows; the requester looks up all the neighbors’ active communities list in its own neighbor table to find if it has any vehicle that is a member of the requested community. If a CM vehicle is available, the interest packet is forwarded to that vehicle. In the case of many available CM, only the closer one toward the center of interest is selected. Each CM within the transmission range of the requester who carries a fresh version of the fetched content in its CS, can play a data-mule role, by sending a Data packet back to the requester using defer timer
Figure 7: Performed actions to retrieve VSN taxi community contents
We have proposed a distributed opportunistic caching model based on community concept. Under which each node makes its own decision according to its social memberships and its preferences to the distinct received contents. To do so, we have divided the CS into two parts, one for community contents and the second one for general contents. When the communities’ allocated cache space is full, a priority-based cache replacement approach is suggested to replace old contents. To accomplish this, we use
where data freshness is extracted from the data packet sent by the producer and community priority is defined following the requester profile. Using this equation, the data saved in the community cache with the smallest resident time will be replaced by the new incoming data. In addition, it allows saving the data of high priority communities in CS for a longer period when it is possible. Nevertheless, a vehicle can use only the data freshness period indicated in the data packet when it comes to general content storing. When the freshness period expires, the data will be immediately removed from CS.
In this section, simulation parameters, scenarios, and performance metrics are described. In addition, extensive experiments are conducted to evaluate the performance of our proposed approach SAFT-VNDN and compare it with the basic VNDN implementation. Finally, the obtained results are discussed.
Our purpose is to analyze and compare SAFT-VNDN’s performance in urban scenarios under different network densities. To accomplish this, our simulations were performed using a customized event-driven network simulator (Ns2.34). we have integrated the three main data structures of the NDN nodes (CS, PIT, FIB) into the local memory of the created Agents. Furthermore, to handle the processing of the exchanged packets in the network. We have implemented the interest and data packets forwarding functions. We consider that all vehicles are equipped with the IEEE 802.11p standard for V2V communication, and have a communication range of 300 meters. To demonstrate the feasibility of SAFT-VNDN we applied a Manhattan mobility model in a 1000 m grid with 5 × 5 urban roads. We varied the density of vehicles between 50 and 250 vehicles per simulation area, with a maximum speed up to 50 km/h. To investigate the vehicles’ social characteristics and properties, we set up the simulation to have three distinct communities. The membership density is respectively 60%, 50%, 35% of the global network density. In addition, we assigned three different contents to each of the created communities, each produced by three different community producers. All community members are capable of generating and receiving community interest/data packets based on their interests and their community memberships. Tab. 3 summarizes the main simulation parameters.
The activity of the community members that varies over time determines the frequency of interest packet generation. However, for general contents, we assigned four distinct producers to four different contents and allowed all network vehicles to request them based on their interests. For cache management, as we previously discussed, we divided the CS into two parts, 50% of the storage space for community contents and 50% for general contents as well. For the sake of simplicity, we did not use
Instead, we opted for the FIFO method for cache replacement. For the same reason, we did not consider the priority of communities. In addition, simulations are run 25 times to reach 90% confidence. Results are discussed in terms of the following criteria:
• Average data delivery delay: The average time between the times an interest packet is issued and a data packet is successfully delivered (including buffering, propagation, transmission, and retransmission delays).
• Data delivery ratio: the ratio of successfully delivered data packets to the total number of originally issued interest packets in a given period.
• Cache hit ratio: the ratio of cache hits to the sum between cache hits and cache misses.
Results in figure Fig. 8 describe the average number of CM per hops at different network densities. As it can be observed, the number of CMs increases as the number of hops increases, until it reaches a peak value at three hops. Then, it decreases after exceeding four hops.
Figure 8: Average number of CM per hops over the number of CM in the network
This experiment finding is important to correctly interpret the results illustrated in Fig. 9, which depicts the cache-hit ratio according to the network density. The SAFT-VNDN cache hit ratio is compared to VNDN’s. As can be seen, SAFT-VNDN cache hit varies from 65% to 80%, while VNDN cache hit varies from 50% to 70%. This result strongly implies that SAFT-VNDN achieves better performance than the native VNDN, and has a higher tendency to find data packets at less than three hops. Thanks to our proposed caching mechanism, that allows the replication of community contents in CM caches based on their interests and memberships. Respectively, obtained results in figure Fig. 10 show the cache hit of each community separately, as well as the cache hit of general contents. It is obvious that the three communities’ cache-hits are proportionally better than the general content cache hit. This result ties well with what we demonstrated in Fig. 9. However, when comparing the cache hit curves of the three communities between them, it must be pointed out that the first community, which represents 60% of the overall network density, provides the highest cache hit ratio. Whereas, the third community, which accounts for 35% of the total density, provides the lowest cache hit ratio compared to the other communities. This implies that the greater the density of CM, the more frequent to find the requested content in data mule caches. Nevertheless, we can notice that the performance of all communities degrades beyond 200 vehicles per simulation area which may be due to collisions.
Figure 9: Cache hit ratio per community in respect to the number of vehicles
Figure 10: Cache hit ratio per community in respect of the number of vehicles
Simulation results in Fig. 11 illustrate the average data delivery delay in respect of the number of vehicles. We can see that the two curves appear almost identical and decrease while varying the density of vehicles from 50 to 250. This result demonstrates that SAFT-VNDN is equal to or better than VNDN in terms of response time. However, it is worthy to note that under the unexpected changing topology of the VANET environment, it may be difficult to select appropriate community members to forward interest/data packets, which might lead to frequent data delivery interruptions. Furthermore, we believe that SAFT-VNDN dissemination scheme can reduce the response time as well as the network load in a relatively low-density environment. But in a high-density environment, collisions may occur, which may decrease the performance of our solution. Besides, we also simulated the case of conventional VANET where the requests should always reach the data provider and there is no means of retrieving it from intermediate nodes like in VNDN. To do so, we used GPSR routing protocol and randomly chose a data provider for every data request [29]. Obtained results clearly show that the semantics that comes with the NDN naming and caching, clearly reduce the data delivery delay compared to the conventional VANET scenario. Figure Fig. 12 shows the data delivery ratio (DDR) in respect of the number of vehicles. The values of VNDN data delivery ratio almost drop to 50% while SAFT-VNDN still provides high DDR values that range from 100% to 87%. This clearly gives better results than VNDN. Fig. 13, represents the DDR of each community, as well as the DDR general content. By comparing the results, we can see that the DDR of the first community increases proportionally from 87% to 100% with the density of vehicles.
Figure 11: Average data delivery delay in respect of the number of vehicles
Similar results were obtained with the second community that reached 100%. However, the DDR of the third community ranges from 61% to 100% because of the presence of collisions. While the DDR of general content drops to 60% because of the same reason. From these results, it is clear that our solution delivers significantly better performance than the native VNDN due to the selection of appropriate forwarders through their memberships, and the availability of CM data mules at less than three hops far from the requester as confirmed in Fig. 8.
Figure 12: Data delivery ratio in respect of the number of vehicles
Figure 13: Data delivery ratio per community in respect of the number of vehicles
In this paper, we investigated the issues related to content dissemination and caching in VSNs, by proposing a novel hybrid VNDN-VSN forwarding technique based on social communities. Our forwarding technique mainly takes advantage of VSN that emerges as an ideal network to serve vehicles with common interests and allow them to exchange numerous types of content on a large scale. In addition, the inheritance of VNDN paradigm can optimize content dissemination by focusing on delivering contents regardless of their IP addresses and making them independent of where they will be forwarded. Moreover, the deployment of in-network caching can be a quite helpful solution to overcome vehicles’ high mobility issues. The simulation results revealed that our forwarding technique could achieve a favorable performance compared with traditional VNDN. For future work, we plan to consider further social aspects considering also drivers’ profiles in Online Social Networks to predict their future interests and hence, better optimize the search/forward processes.
Funding Statement: The research was supported by the Office of Research and Sponsored Programs, Kean University.
Conflicts of Interest: The authors declare that they have no conflicts of interest to report regarding the present study.
1. I. M. Hassan and K. R. Hassan, “Vehicular social networks and vehicular ad-hoc networks, applications, modelling tools and challenges: A survey,” International Journal of Computer Applications, vol. 176, no. 25, pp. 32–38, 2020. [Google Scholar]
2. A. Rahim, X. Kong, F. Xia, Z. Ning, N. Ullah et al., “Vehicular social networks: A survey,” Pervasive and Mobile Computing, vol. 43, no. 1, pp. 96–113, 2018. [Google Scholar]
3. C. A. Kerrache, N. Lagraa, R. Hussain, S. H. Ahmed, A. Benslimane et al., “TACASHI: Trust-aware communication architecture for social internet of vehicles,” IEEE Internet of Things Journal, vol. 6, no. 4, pp. 5870–5877, 2018. [Google Scholar]
4. S. Smaldone, L. Han, P. Shankar and L. Iftode, “Roadspeak: Enabling voice chat on roadways using vehicular social networks,” in Proc. of the 1st Workshop on Social Network Systems, Glasgow Scotland, pp. 43–48, 2008. [Google Scholar]
5. D. Kwak, D. Kim, R. Liu, B. Nath and L. Iftode, “DoppelDriver: Counterfactual actual travel times for alternative routes,” in 2015 IEEE Int. Conf. on Pervasive Computing and Communications (PerCom), St. Louis, MO, USA, IEEE, pp. 178–185, 2015. [Google Scholar]
6. D. Kwak, R. Liu, D. Kim, B. Nath and L. Iftode, “Seeing is believing: Sharing real-time visual traffic information via vehicular clouds,” IEEE Access, vol. 4, pp. 3617–3631, 2016. [Google Scholar]
7. D. Kwak, D. Kim, R. Liu, L. Iftode and B. Nath, “Tweeting traffic image reports on the road,” in 6th Int. Conf. on Mobile Computing, Applications and Services (MobiCASE), Austin, TX, USA, pp. 40–48, 2014. [Google Scholar]
8. W. Sha, D. Kwak, B. Nath and L. Iftode, “Social vehicle navigation: Integrating shared driving experience into vehicle navigation,” in Proc. of the 14th Workshop on Mobile Computing Systems and Applications (HotMobile), Jekyll Island, Georgia, USA, pp. 1–6, 2013. [Google Scholar]
9. B. Zhang, R. Tian and C. Li, “Content dissemination and routing for vehicular social networks: A networking perspective,” IEEE Wireless Communications, vol. 27, no. 2, pp. 118–126, 2019. [Google Scholar]
10. M. Zhang, X. Wang, T. Liu, J. Zhu and Q. Wu, “AFSndn: A novel adaptive forwarding strategy in named data networking based on Q-learning,” Peer-to-Peer Networking and Applications, vol. 13, no. 4, pp. 1176–1184, 2020. [Google Scholar]
11. W. Sun, G. Z. Dai, X. R. Zhang, X. Z. He and X. Chen, “TBE-Net: A three-branch embedding network with part-aware ability and feature complementary learning for vehicle re-identification,” IEEE Transactions on Intelligent Transportation Systems, pp. 1–13, 2021. https://doi.org/10.1109/TITS.2021.3130403. [Google Scholar]
12. W. Sun, L. Dai, X. R. Zhang, P. S. Chang and X. Z. He, “RSOD: Real-time small object detection algorithm in UAV-based traffic monitoring,” Applied Intelligence, pp. 1–16, 2021. https://doi.org/10.1007/s10489-021-02893-3. [Google Scholar]
13. G. Grassi, D. Pesavento, G. Pau, R. Vuyyuru and R. Wakikawa, “VANET via named data networking,” in IEEE Conf. on Computer Communications Workshops (INFOCOM WKSHPS), Toronto, Canada, pp. 410–415, 2014. [Google Scholar]
14. K. Ahed, M. Benamar, A. A. Lahcen and R. El Ouazzani, “Forwarding strategies in vehicular named data networks: A survey,” Journal of King Saud University-Computer and Information Sciences, vol. 34, pp. 1819–1835, 2020. [Google Scholar]
15. H. Khelifi, S. Luo, B. Nour, H. Moungla, Y. Faheem et al., “Named data networking in vehicular ad hoc networks: State-of-the-art and challenges,” IEEE Communications Surveys & Tutorials, vol. 22, no. 1, pp. 320–351, 2019. [Google Scholar]
16. E. Barka, C. A. Kerrache, R. Hussain, N. Lagraa, A. Lakas et al., “A trusted lightweight communication strategy for flying named data networking,” Sensors, vol. 18, no. 8, pp. 2683, 2018. [Google Scholar]
17. F. Ahmad, C. A. Kerrache, F. Kurugollu and R. Hussain, “Realization of blockchain in named data networking-based internet-of-vehicles,” IT Professional, vol. 21, no. 4, pp. 41–47, 2019. [Google Scholar]
18. C. A. Kerrche, F. Ahmad, M. Elhoseny, A. Adnane, Z. Ahmad et al., “Internet of vehicles over named data networking: Current status and future challenges,” in Emerging Technologies for Connected Internet of Vehicles and Intelligent Transportation System Networks, New York, USA: Springer, pp. 83–99, 2020. [Google Scholar]
19. M. Amadeo, G. Ruggeri, C. Campolo and A. Molinaro, “Diversity-improved caching of popular transient contents in vehicular named data networking,” Computer Networks, vol. 184, pp. 107625, 2021. [Google Scholar]
20. M. Al-Qutwani, X. Wang and B. Yi, “Request/Advertise-based content forwarding in vehicular named data networking,” IEEE Access, vol. 9, pp. 226–236, 2020. [Google Scholar]
21. Y. Xu, S. Tong, T. Zhang, W. Sun, X. Hu et al., “Compass: Directing named data transmission in VANETs by dynamic directional interfaces,” IEEE Access, vol. 8, pp. 8418–8435, 2020. [Google Scholar]
22. A. A. Prates, I. V. Bastos and I. M. Moraes, “GeoZone: An interest-packet forwarding mechanism based on dissemination zone for content-centric vehicular networks,” Computers & Electrical Engineering, vol. 73, pp. 155–166, 2019. [Google Scholar]
23. X. Wang and Y. Li, “Vehicular named data networking framework,” IEEE Transactions on Intelligent Transportation Systems, vol. 21, no. 11, pp. 4705–4714, 2019. [Google Scholar]
24. H. Al-Omaisi, E. A. Sundararajan, R. Alsaqour, N. F. Abdullah and M. Abdelhaq, “A survey of data dissemination schemes in vehicular named data networking,” Vehicular Communications, vol. 30, pp. 100353, 2021. [Google Scholar]
25. C. Chen, C. Wang, T. Qiu, M. Atiquzzaman and D. O. Wu, “Caching in vehicular named data networking: Architecture, schemes and future directions,” IEEE Communications Surveys & Tutorials, vol. 22, no. 4, pp. 2378–2407, 2020. [Google Scholar]
26. J. Li, J. Jannotti, D. S. De Couto, D. R. Karger and R. Morris, “A scalable location service for geographic ad hoc routing,” in Proc. of the 6th Annual Int. Conf. on Mobile Computing and Networking, Boston, Massachusetts, USA, pp. 120–130, 2000. [Google Scholar]
27. ETSI-ITS, “ETSI EN 302 890-2 V2.1.1, Intelligent transport systems (ITS); Facilities layer function; Part 2: Position and time management (PoTi),” Technical report, Release 2 (2020-03). [Google Scholar]
28. D. O. Mau, Y. Zhang, T. Taleb and M. Chen, “Vehicular inter-networking via named data-an opnet simulation study,” in Int. Conf. on Testbeds and Research Infrastructures, Guangzhou, China, pp. 116–125, 2014. [Google Scholar]
29. A. Silva, K. N. Reza and A. Oliveira, “An adaptive GPSR routing protocol for VANETs,” in 15th Int. Symp. on Wireless Communication Systems (ISWCS), Lisbon, Portugal, pp. 1–6, 2018. [Google Scholar]
 | This work is licensed under a Creative Commons Attribution 4.0 International License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited. |