<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE article PUBLIC "-//NLM//DTD JATS (Z39.96) Journal Publishing DTD v1.1 20151215//EN" "http://jats.nlm.nih.gov/publishing/1.1/JATS-journalpublishing1.dtd">
<article xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" article-type="research-article" dtd-version="1.1">
<front>
<journal-meta>
<journal-id journal-id-type="pmc">CMC</journal-id>
<journal-id journal-id-type="nlm-ta">CMC</journal-id>
<journal-id journal-id-type="publisher-id">CMC</journal-id>
<journal-title-group>
<journal-title>Computers, Materials &#x0026; Continua</journal-title>
</journal-title-group>
<issn pub-type="epub">1546-2226</issn>
<issn pub-type="ppub">1546-2218</issn>
<publisher>
<publisher-name>Tech Science Press</publisher-name>
<publisher-loc>USA</publisher-loc>
</publisher>
</journal-meta>
<article-meta>
<article-id pub-id-type="publisher-id">28619</article-id>
<article-id pub-id-type="doi">10.32604/cmc.2022.028619</article-id>
<article-categories>
<subj-group subj-group-type="heading">
<subject>Article</subject>
</subj-group>
</article-categories>
<title-group>
<article-title>SAFT-VNDN: A Socially-Aware Forwarding Technique in Vehicular Named Data Networking</article-title>
<alt-title alt-title-type="left-running-head">SAFT-VNDN: A Socially-Aware Forwarding Technique in Vehicular Named Data Networking</alt-title>
<alt-title alt-title-type="right-running-head">SAFT-VNDN: A Socially-Aware Forwarding Technique in Vehicular Named Data Networking</alt-title>
</title-group>
<contrib-group content-type="authors">
<contrib id="author-1" contrib-type="author">
<name name-style="western"><surname>Boudelaa</surname><given-names>Amel</given-names></name>
<xref ref-type="aff" rid="aff-1">1</xref>
</contrib>
<contrib id="author-2" contrib-type="author">
<name name-style="western"><surname>Abdelhafidi</surname><given-names>Zohra</given-names></name>
<xref ref-type="aff" rid="aff-1">1</xref>
</contrib>
<contrib id="author-3" contrib-type="author">
<name name-style="western"><surname>Lagraa</surname><given-names>Nasreddine</given-names></name>
<xref ref-type="aff" rid="aff-1">1</xref>
</contrib>
<contrib id="author-4" contrib-type="author">
<name name-style="western"><surname>Kerrache</surname><given-names>Chaker Abdelaziz</given-names></name>
<xref ref-type="aff" rid="aff-1">1</xref>
</contrib>
<contrib id="author-5" contrib-type="author">
<name name-style="western"><surname>Bilal</surname><given-names>Muhammad</given-names></name>
<xref ref-type="aff" rid="aff-2">2</xref>
</contrib>
<contrib id="author-6" contrib-type="author" corresp="yes">
<name name-style="western"><surname>Kwak</surname><given-names>Daehan</given-names></name>
<xref ref-type="aff" rid="aff-3">3</xref><email>dkwak@kean.edu</email>
</contrib>
<contrib id="author-7" contrib-type="author">
<name name-style="western"><surname>Yagoubi</surname><given-names>Mohamed Bachir</given-names></name>
<xref ref-type="aff" rid="aff-1">1</xref>
</contrib>
<aff id="aff-1"><label>1</label><institution>Laboratoire d&#x2019;Informatique et de Math&#x00E9;matiques, Universit&#x00E9; Amar Telidji de Laghouat</institution>, <addr-line>Laghouat</addr-line>, <country>Algeria</country></aff>
<aff id="aff-2"><label>2</label><institution>Department of Computer and Electronics Systems Engineering, Hankuk University of Foreign Studies</institution>, <addr-line>Yongin-si, 17035, Gyeonggi-do, Korea</addr-line></aff>
<aff id="aff-3"><label>3</label><institution>School of Computer Science and Technology, Kean University</institution>, <addr-line>NJ</addr-line>, <country>USA</country></aff>
</contrib-group>
<author-notes>
<corresp id="cor1"><label>&#x002A;</label>Corresponding Author: Daehan Kwak. Email: <email>dkwak@kean.edu</email></corresp>
</author-notes>
<pub-date pub-type="epub" date-type="pub" iso-8601-date="2022-06-14"><day>14</day>
<month>06</month>
<year>2022</year></pub-date>
<volume>73</volume>
<issue>2</issue>
<fpage>2495</fpage>
<lpage>2512</lpage>
<history>
<date date-type="received">
<day>14</day>
<month>2</month>
<year>2022</year>
</date>
<date date-type="accepted">
<day>13</day>
<month>4</month>
<year>2022</year>
</date>
</history>
<permissions>
<copyright-statement>&#x00A9; 2022 Boudelaa et al.</copyright-statement>
<copyright-year>2022</copyright-year>
<copyright-holder>Boudelaa et al.</copyright-holder>
<license xlink:href="https://creativecommons.org/licenses/by/4.0/">
<license-p>This work is licensed under a <ext-link ext-link-type="uri" xlink:type="simple" xlink:href="https://creativecommons.org/licenses/by/4.0/">Creative Commons Attribution 4.0 International License</ext-link>, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.</license-p>
</license>
</permissions>
<self-uri content-type="pdf" xlink:href="TSP_CMC_28619.pdf"></self-uri>
<abstract>
<p>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&#x2019; 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.</p>
</abstract>
<kwd-group kwd-group-type="author">
<kwd>Vehicular Social Networks (VSNs)</kwd>
<kwd>Vehicular Named Data Networking</kwd>
<kwd>forwarding technique</kwd>
<kwd>social communities</kwd>
</kwd-group>
</article-meta>
</front>
<body>
<sec id="s1">
<label>1</label>
<title>Introduction</title>
<p>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&#x2019; 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) [<xref ref-type="bibr" rid="ref-1">1</xref>&#x2013;<xref ref-type="bibr" rid="ref-8">8</xref>]. The fundamental brick of VSN design is communication and content sharing, forwarding, and disseminating, which are directed by humans&#x2019; relationships, common interests, and mobility patterns under what we call a community.</p>
<p>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 [<xref ref-type="bibr" rid="ref-9">9</xref>] Using such architecture may result in <italic>(i)</italic> increasing significantly end-to-end transmission delay and <italic>(ii)</italic> degrading dramatically the network performances. The latter can be enhanced if we can retrieve the required content from a geographically nearest node.</p>
<p>Another research direction that has attracted researchers&#x2019; and industries&#x2019; eyes is Named Data Networking (NDN) [<xref ref-type="bibr" rid="ref-10">10</xref>]. Unlike host-centric architecture, NDN is a promising Content Centric Network (CCN) [<xref ref-type="bibr" rid="ref-11">11</xref>,<xref ref-type="bibr" rid="ref-12">12</xref>]. 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 [<xref ref-type="bibr" rid="ref-13">13</xref>]. 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.</p>
<p>Several studies have investigated NDN deployment in VANETs (VNDN) [<xref ref-type="bibr" rid="ref-14">14</xref>&#x2013;<xref ref-type="bibr" rid="ref-17">17</xref>]. 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 [<xref ref-type="bibr" rid="ref-18">18</xref>,<xref ref-type="bibr" rid="ref-19">19</xref>]. In this regard, Al-Qutwani et al. propose a forwarding technique called RAFS based on unicast paths [<xref ref-type="bibr" rid="ref-20">20</xref>], In [<xref ref-type="bibr" rid="ref-21">21</xref>], 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 [<xref ref-type="bibr" rid="ref-22">22</xref>] and a vehicular backbone architecture based on cluster-chain [<xref ref-type="bibr" rid="ref-23">23</xref>] has been proposed to improve the performance of data dissemination in VNDN.</p>
<p>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 [<xref ref-type="bibr" rid="ref-24">24</xref>]. 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 [<xref ref-type="bibr" rid="ref-25">25</xref>,<xref ref-type="bibr" rid="ref-26">26</xref>]. 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.</p>
<p>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 &#x201C;a Socially-Aware Forwarding Technique in Vehicular Named Data Networking&#x201D; (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:
<list list-type="order">
<list-item>
<p>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.</p></list-item>
<list-item>
<p>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.</p></list-item>
</list></p>
<p>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.</p>
</sec>
<sec id="s2">
<label>2</label>
<title>Vehicular Named Data Networking</title>
<p>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) [<xref ref-type="bibr" rid="ref-14">14</xref>,<xref ref-type="bibr" rid="ref-15">15</xref>]. The substantial concept of VNDN is to benefit from the NDN prototype, which concentrates on delivering data regardless of its physical location.
<list list-type="bullet">
<list-item>
<p>Consumer: it initiates the content fetching process by broadcasting an interest packet in the network.</p></list-item>
<list-item>
<p>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.</p></list-item>
<list-item>
<p>Forwarder: it transmits (forwards) interest or data packet until they reach their final destination, either a producer or a consumer respectively.</p></list-item>
<list-item>
<p>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.</p></list-item>
</list></p>
<sec id="s2_1">
<label>2.1</label>
<title>Data Structures</title>
<p>As depicted in <xref ref-type="fig" rid="fig-1">Fig. 1</xref>, each VNDN node has the following data structures.
<list list-type="bullet">
<list-item><p>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.</p></list-item>
<list-item><p>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.</p></list-item>
<list-item><p>Content Store (CS): it is used to store the incoming data packets so that the subsequent requests can be accommodated.</p></list-item>
</list></p>
<fig id="fig-1">
<label>Figure 1</label>
<caption>
<title>VNDN forwarding model</title>
</caption>
<graphic mimetype="image" mime-subtype="png" xlink:href="CMC_28619-fig-1.png"/>
</fig>
</sec>
<sec id="s2_2">
<label>2.2</label>
<title>Forwarding Phases</title>
<p>Packet forwarding in VNDN can be divided into two phases based on the type of packet being forwarded <italic>(i)</italic> interest packet forwarding, and <italic>(ii)</italic> data packet retrieving [<xref ref-type="bibr" rid="ref-22">22</xref>]. The details of these two phases are as follows:
<list list-type="bullet">
<list-item><p>Interest Packet Forwarding: To retrieve a specific content from the network, a VNDN node acts as follows:
<list list-type="simple">
<list-item><p>&#x2013; The consumer broadcasts an interest packet. (Vehicle A in <xref ref-type="fig" rid="fig-1">Fig. 1</xref>.)</p></list-item>
<list-item><p>&#x2013; Upon receiving the interest packet, an intermediate vehicle (e.g., vehicle D in <xref ref-type="fig" rid="fig-1">Fig. 1</xref>) 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:
<list list-type="alpha-lower">
<list-item><p>If the desired content exists, the intermediate vehicle sends back a data packet towards the consumer.</p></list-item>
<list-item><p>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.</p></list-item>
</list></p></list-item></list></p></list-item>
<list-item><p>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 <xref ref-type="fig" rid="fig-1">Fig. 1</xref>). Otherwise, it discards the data packet as it is considered unsolicited.</p></list-item>
</list></p>
</sec>
</sec>
<sec id="s3">
<label>3</label>
<title>SAFT-VNDN: A Socially Aware Forwarding Technique in Vehicular Named Data Networking VNDN</title>
<p>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.</p>
<sec id="s3_1">
<label>3.1</label>
<title>Assumptions</title>
<p>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) [<xref ref-type="bibr" rid="ref-27">27</xref>]. 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&#x2019;s profile).</p>
</sec>
<sec id="s3_2">
<label>3.2</label>
<title>Community Management</title>
<p>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&#x2019; smart devices together in the virtual community of vehicles [<xref ref-type="bibr" rid="ref-2">2</xref>&#x2013;<xref ref-type="bibr" rid="ref-8">8</xref>]. Hence, social communities can be used to enhance data delivery thanks to the social behavior of nodes and social ties between them.</p>
<sec id="s3_2_1">
<label>3.2.1</label>
<title>Construction of Social Communities</title>
<p>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 (<xref ref-type="fig" rid="fig-2">Fig. 2</xref>). 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&#x2019; lifetime can be relatively short or long depending on the sensitivity level of the exchanged information in the community.</p>
<fig id="fig-2">
<label>Figure 2</label>
<caption>
<title>SAFT-VNDN forwarding model</title>
</caption>
<graphic mimetype="image" mime-subtype="png" xlink:href="CMC_28619-fig-2.png"/>
</fig>
</sec>
<sec id="s3_2_2">
<label>3.2.2</label>
<title>Modeling of the Community Construction</title>
<p>Due to VNDN&#x2019;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&#x2019;s community is problematic. We employ a local community detection approach based on core nodes in this study. The algorithm&#x2019;s steps are as follows:</p>
<p>Step 1: Determine the node&#x2019;s center value.</p>
<p><disp-formula id="eqn-1"><label>(1)</label><mml:math id="mml-eqn-1" display="block"><mml:msub><mml:mi>&#x2201;</mml:mi><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:mi>c</mml:mi><mml:msubsup><mml:mo movablelimits="false">&#x2211;</mml:mo><mml:mrow><mml:mi>i</mml:mi><mml:mo>&#x2260;</mml:mo><mml:mi>j</mml:mi></mml:mrow><mml:mrow></mml:mrow></mml:msubsup><mml:msub><mml:mi>&#x2201;</mml:mi><mml:mrow><mml:mi>j</mml:mi></mml:mrow></mml:msub><mml:mfrac><mml:msub><mml:mi>w</mml:mi><mml:mrow><mml:mi>i</mml:mi><mml:mi>j</mml:mi></mml:mrow></mml:msub><mml:mrow><mml:munderover><mml:mo>&#x2211;</mml:mo><mml:mrow><mml:mi>k</mml:mi><mml:mo>&#x2208;</mml:mo><mml:mi>A</mml:mi><mml:mi>i</mml:mi><mml:mi>k</mml:mi></mml:mrow><mml:mrow></mml:mrow></mml:munderover><mml:msub><mml:mi>w</mml:mi><mml:mrow><mml:mi>i</mml:mi><mml:mi>k</mml:mi></mml:mrow></mml:msub></mml:mrow></mml:mfrac><mml:mo>+</mml:mo><mml:mfrac><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mn>1</mml:mn><mml:mo>&#x2212;</mml:mo><mml:mi>c</mml:mi><mml:mo stretchy="false">)</mml:mo><mml:msub><mml:mi>S</mml:mi><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msub></mml:mrow><mml:mi>N</mml:mi></mml:mfrac></mml:math></disp-formula></p>
<p>The center value of node <inline-formula id="ieqn-1"><mml:math id="mml-ieqn-1"><mml:msub><mml:mi>V</mml:mi><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msub></mml:math></inline-formula> is <inline-formula id="ieqn-2"><mml:math id="mml-ieqn-2"><mml:msub><mml:mi>C</mml:mi><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msub></mml:math></inline-formula>.The total number of nodes is N. The weight between nodes <inline-formula id="ieqn-3"><mml:math id="mml-ieqn-3"><mml:msub><mml:mi>V</mml:mi><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msub></mml:math></inline-formula> and <inline-formula id="ieqn-4"><mml:math id="mml-ieqn-4"><mml:msub><mml:mi>V</mml:mi><mml:mrow><mml:mi>j</mml:mi></mml:mrow></mml:msub></mml:math></inline-formula> is <inline-formula id="ieqn-5"><mml:math id="mml-ieqn-5"><mml:msub><mml:mi>w</mml:mi><mml:mrow><mml:mi>i</mml:mi><mml:mi>j</mml:mi></mml:mrow></mml:msub></mml:math></inline-formula>. C is a regulatory factor that is typically set to 0.85. The degree of node <inline-formula id="ieqn-6"><mml:math id="mml-ieqn-6"><mml:msub><mml:mi>V</mml:mi><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msub></mml:math></inline-formula> is <inline-formula id="ieqn-7"><mml:math id="mml-ieqn-7"><mml:msub><mml:mi>S</mml:mi><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msub></mml:math></inline-formula></p>
<p>Step 2: Identify the seed nodes.</p>
<p>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:</p>
<p><disp-formula id="eqn-2"><label>(2)</label><mml:math id="mml-eqn-2" display="block"><mml:mi>S</mml:mi><mml:mi>I</mml:mi><mml:msub><mml:mi>M</mml:mi><mml:mrow><mml:mi>i</mml:mi><mml:mo>,</mml:mo><mml:mi>j</mml:mi></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:mfrac><mml:mrow><mml:mo>|</mml:mo><mml:msub><mml:mi mathvariant="normal">&#x0393;</mml:mi><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msub><mml:mo>&#x2229;</mml:mo><mml:msub><mml:mi mathvariant="normal">&#x0393;</mml:mi><mml:mrow><mml:mi>j</mml:mi></mml:mrow></mml:msub><mml:mo>|</mml:mo></mml:mrow><mml:mrow><mml:msub><mml:mi mathvariant="normal">&#x0393;</mml:mi><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msub><mml:mo>&#x222A;</mml:mo><mml:msub><mml:mi mathvariant="normal">&#x0393;</mml:mi><mml:mrow><mml:mi>j</mml:mi></mml:mrow></mml:msub></mml:mrow></mml:mfrac><mml:mo>&#x003E;</mml:mo><mml:mi>&#x03B2;</mml:mi></mml:math></disp-formula>where <inline-formula id="ieqn-8"><mml:math id="mml-ieqn-8"><mml:mi>S</mml:mi><mml:mi>I</mml:mi><mml:msub><mml:mi>M</mml:mi><mml:mrow><mml:mi>i</mml:mi><mml:mo>,</mml:mo><mml:mi>j</mml:mi></mml:mrow></mml:msub></mml:math></inline-formula> denotes how similar nodes <inline-formula id="ieqn-9"><mml:math id="mml-ieqn-9"><mml:msub><mml:mi>V</mml:mi><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msub></mml:math></inline-formula> and <inline-formula id="ieqn-10"><mml:math id="mml-ieqn-10"><mml:msub><mml:mi>V</mml:mi><mml:mrow><mml:mi>j</mml:mi></mml:mrow></mml:msub></mml:math></inline-formula> are. The neighbor set of node <inline-formula id="ieqn-11"><mml:math id="mml-ieqn-11"><mml:msub><mml:mi>V</mml:mi><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msub></mml:math></inline-formula> is <inline-formula id="ieqn-12"><mml:math id="mml-ieqn-12"><mml:msub><mml:mi mathvariant="normal">&#x0393;</mml:mi><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msub></mml:math></inline-formula>. <inline-formula id="ieqn-13"><mml:math id="mml-ieqn-13"><mml:mrow><mml:mo>|</mml:mo><mml:msub><mml:mi mathvariant="normal">&#x0393;</mml:mi><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msub><mml:mo>&#x2229;</mml:mo><mml:msub><mml:mi mathvariant="normal">&#x0393;</mml:mi><mml:mrow><mml:mi>j</mml:mi></mml:mrow></mml:msub><mml:mo>|</mml:mo></mml:mrow></mml:math></inline-formula> is the number of common neighbors between nodes <inline-formula id="ieqn-14"><mml:math id="mml-ieqn-14"><mml:msub><mml:mi>V</mml:mi><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msub></mml:math></inline-formula> and <inline-formula id="ieqn-15"><mml:math id="mml-ieqn-15"><mml:msub><mml:mi>V</mml:mi><mml:mrow><mml:mi>j</mml:mi></mml:mrow></mml:msub></mml:math></inline-formula>. The threshold $beta$ is used to assess if two nodes are comparable.</p>
<p>Step 3: Expand the community.</p>
<p>The fitness function of a given community S is defined as:</p>
<p><disp-formula id="eqn-3"><label>(3)</label><mml:math id="mml-eqn-3" display="block"><mml:mi>f</mml:mi><mml:mrow><mml:mo>(</mml:mo><mml:mi>S</mml:mi><mml:mo>)</mml:mo></mml:mrow><mml:mo>=</mml:mo><mml:mfrac><mml:mrow><mml:msub><mml:mi>K</mml:mi><mml:mrow><mml:mi>i</mml:mi><mml:mi>n</mml:mi></mml:mrow></mml:msub><mml:mo stretchy="false">(</mml:mo><mml:mi>S</mml:mi><mml:mo stretchy="false">)</mml:mo></mml:mrow><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:msub><mml:mi>K</mml:mi><mml:mrow><mml:mi>i</mml:mi><mml:mi>n</mml:mi></mml:mrow></mml:msub></mml:mrow><mml:mrow><mml:mo>(</mml:mo><mml:mi>S</mml:mi><mml:mo>)</mml:mo></mml:mrow><mml:mo>+</mml:mo><mml:mrow><mml:msub><mml:mi>K</mml:mi><mml:mrow><mml:mi>o</mml:mi><mml:mi>u</mml:mi><mml:mi>t</mml:mi></mml:mrow></mml:msub></mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mi>S</mml:mi><mml:mo stretchy="false">)</mml:mo><mml:msup><mml:mo stretchy="false">)</mml:mo><mml:mrow><mml:mi>&#x03B1;</mml:mi></mml:mrow></mml:msup></mml:mrow></mml:mfrac></mml:math></disp-formula></p>
<p>The total of the internal node degree in S is <inline-formula id="ieqn-16"><mml:math id="mml-ieqn-16"><mml:msub><mml:mi>K</mml:mi><mml:mrow><mml:mi>i</mml:mi><mml:mi>n</mml:mi></mml:mrow></mml:msub><mml:mo stretchy="false">(</mml:mo><mml:mi>S</mml:mi><mml:mo stretchy="false">)</mml:mo></mml:math></inline-formula>. The total of the connections between S and other communities is <inline-formula id="ieqn-17"><mml:math id="mml-ieqn-17"><mml:msub><mml:mi>K</mml:mi><mml:mrow><mml:mi>o</mml:mi><mml:mi>u</mml:mi><mml:mi>t</mml:mi></mml:mrow></mml:msub><mml:mo stretchy="false">(</mml:mo><mml:mi>S</mml:mi><mml:mo stretchy="false">)</mml:mo></mml:math></inline-formula>. The parameter &#x003B1; can be used to adjust the size of communities.</p>
<p>The fitness function for S for a given node <inline-formula id="ieqn-18"><mml:math id="mml-ieqn-18"><mml:msub><mml:mi>V</mml:mi><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msub></mml:math></inline-formula> is defined as:</p>
<p><disp-formula id="eqn-4"><label>(4)</label><mml:math id="mml-eqn-4" display="block"><mml:mi>f</mml:mi><mml:mrow><mml:mo>(</mml:mo><mml:mi>i</mml:mi><mml:mo>)</mml:mo></mml:mrow><mml:mo>=</mml:mo><mml:mi>f</mml:mi><mml:mrow><mml:mo>(</mml:mo><mml:mi>S</mml:mi><mml:mo>+</mml:mo><mml:mi>i</mml:mi><mml:mo>)</mml:mo></mml:mrow><mml:mo>&#x2212;</mml:mo><mml:mi>f</mml:mi><mml:mrow><mml:mo>(</mml:mo><mml:mi>S</mml:mi><mml:mo>)</mml:mo></mml:mrow></mml:math></disp-formula>where, <inline-formula id="ieqn-19"><mml:math id="mml-ieqn-19"><mml:mi>S</mml:mi><mml:mo>+</mml:mo><mml:mi>i</mml:mi></mml:math></inline-formula> is a community after <inline-formula id="ieqn-20"><mml:math id="mml-ieqn-20"><mml:msub><mml:mi>V</mml:mi><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msub></mml:math></inline-formula> is added into S. If and only if <inline-formula id="ieqn-21"><mml:math id="mml-ieqn-21"><mml:mi>f</mml:mi><mml:mrow><mml:mo>(</mml:mo><mml:mi>i</mml:mi><mml:mo>)</mml:mo></mml:mrow></mml:math></inline-formula> &#x003E; 0, <inline-formula id="ieqn-22"><mml:math id="mml-ieqn-22"><mml:msub><mml:mi>V</mml:mi><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msub></mml:math></inline-formula> can be added into S.</p>
<p>Step 4: Combine communities that are redundant.</p>
<p>The degree of overlap between communities is calculated as follows:</p>
<p><disp-formula id="eqn-5"><label>(5)</label><mml:math id="mml-eqn-5" display="block"><mml:msub><mml:mi>O</mml:mi><mml:mrow><mml:mi>v</mml:mi></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:mfrac><mml:mrow><mml:mo>|</mml:mo><mml:msub><mml:mi>C</mml:mi><mml:mrow><mml:mn>1</mml:mn></mml:mrow></mml:msub><mml:mo>&#x2229;</mml:mo><mml:msub><mml:mi>C</mml:mi><mml:mrow><mml:mn>2</mml:mn></mml:mrow></mml:msub><mml:mo>|</mml:mo></mml:mrow><mml:mrow><mml:mo movablelimits="true" form="prefix">min</mml:mo><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mo>|</mml:mo><mml:msub><mml:mi>C</mml:mi><mml:mrow><mml:mn>1</mml:mn></mml:mrow></mml:msub><mml:mo>|</mml:mo></mml:mrow><mml:mo>,</mml:mo><mml:mrow><mml:mo>|</mml:mo><mml:msub><mml:mi>C</mml:mi><mml:mrow><mml:mn>2</mml:mn></mml:mrow></mml:msub><mml:mo>|</mml:mo></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:mfrac></mml:math></disp-formula>where, <inline-formula id="ieqn-23"><mml:math id="mml-ieqn-23"><mml:mrow><mml:mo>|</mml:mo><mml:msub><mml:mi>C</mml:mi><mml:mrow><mml:mn>1</mml:mn></mml:mrow></mml:msub><mml:mo>|</mml:mo></mml:mrow></mml:math></inline-formula> is the number of nodes in the community <inline-formula id="ieqn-24"><mml:math id="mml-ieqn-24"><mml:mrow><mml:mo>|</mml:mo><mml:msub><mml:mi>C</mml:mi><mml:mrow><mml:mn>1</mml:mn></mml:mrow></mml:msub><mml:mo>|</mml:mo></mml:mrow></mml:math></inline-formula>. <inline-formula id="ieqn-25"><mml:math id="mml-ieqn-25"><mml:mrow><mml:mo>|</mml:mo><mml:msub><mml:mi>C</mml:mi><mml:mrow><mml:mn>1</mml:mn></mml:mrow></mml:msub><mml:mo>&#x2229;</mml:mo><mml:msub><mml:mi>C</mml:mi><mml:mrow><mml:mn>2</mml:mn></mml:mrow></mml:msub><mml:mo>|</mml:mo></mml:mrow></mml:math></inline-formula> is the number of same nodes between <inline-formula id="ieqn-26"><mml:math id="mml-ieqn-26"><mml:msub><mml:mi>C</mml:mi><mml:mrow><mml:mn>1</mml:mn></mml:mrow></mml:msub></mml:math></inline-formula> and <inline-formula id="ieqn-27"><mml:math id="mml-ieqn-27"><mml:msub><mml:mi>C</mml:mi><mml:mrow><mml:mn>2</mml:mn></mml:mrow></mml:msub></mml:math></inline-formula>. If <inline-formula id="ieqn-28"><mml:math id="mml-ieqn-28"><mml:msub><mml:mi>O</mml:mi><mml:mrow><mml:mi>v</mml:mi></mml:mrow></mml:msub></mml:math></inline-formula> &#x003E; 0.75, the community <inline-formula id="ieqn-29"><mml:math id="mml-ieqn-29"><mml:msub><mml:mi>C</mml:mi><mml:mrow><mml:mn>1</mml:mn></mml:mrow></mml:msub></mml:math></inline-formula> and <inline-formula id="ieqn-30"><mml:math id="mml-ieqn-30"><mml:msub><mml:mi>C</mml:mi><mml:mrow><mml:mn>2</mml:mn></mml:mrow></mml:msub></mml:math></inline-formula> are combined.</p>
<p>The fifth and final step consists of: Continue using Steps 3 and 4 until all nodes have been assigned to the communities.</p>
</sec>
<sec id="s3_2_3">
<label>3.2.3</label>
<title>Community Priority</title>
<p>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&#x2019;s interest in the content produced and shared by community members (the degree of interest can be extracted from the user&#x2019;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&#x2019; contents.</p>
</sec>
</sec>
<sec id="s3_3">
<label>3.3</label>
<title>Forwarding Technique</title>
<sec id="s3_3_1">
<label>3.3.1</label>
<title>VSN Content Names</title>
<p>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. <xref ref-type="fig" rid="fig-3">Fig. 3</xref> shows the content names structure used in our approach and <xref ref-type="table" rid="table-1">Tab. 1</xref> describes each field.</p>
<fig id="fig-3">
<label>Figure 3</label>
<caption>
<title>Content name structure</title>
</caption>
<graphic mimetype="image" mime-subtype="png" xlink:href="CMC_28619-fig-3.png"/>
</fig>
<table-wrap id="table-1">
<label>Table 1</label>
<caption>
<title>Content name fields.</title>
</caption>
<table frame="hsides">
<colgroup>
<col align="left"/>
<col align="left"/>
</colgroup>
<thead>
<tr>
<th>Fields</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr>
<td>VSNapp</td>
<td>Denotes a specific VSN application.</td>
</tr>
<tr>
<td>UserID</td>
<td>Identifies an end-user in the VSN application.</td>
</tr>
<tr>
<td>CenterOFInterest</td>
<td>Refers to the coordinates of a specific zone called, zone of interest. It enables each vehicle requester to describe the zone that it expects to visit.</td>
</tr>
<tr>
<td>CommunityName</td>
<td>Determines the name of the community that produces the required content.</td>
</tr>
<tr>
<td>ContentHierarchical<break/>Name</td>
<td>Refers to the content produced by the end-user and its instances.</td>
</tr>
</tbody>
</table>
</table-wrap>
</sec>
<sec id="s3_3_2">
<label>3.3.2</label>
<title>Modified Cooperative Awareness Message (CAM) Structure</title>
<p>In ETSI architecture [<xref ref-type="bibr" rid="ref-28">28</xref>], 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 (<xref ref-type="fig" rid="fig-4">Fig. 4</xref>), 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 [<xref ref-type="bibr" rid="ref-28">28</xref>].</p>
<fig id="fig-4">
<label>Figure 4</label>
<caption>
<title>Modified structure of a CAM</title>
</caption>
<graphic mimetype="image" mime-subtype="png" xlink:href="CMC_28619-fig-4.png"/>
</fig>
<p>A CAM may also include:
<list list-type="bullet">
<list-item>
<p>Interest One basic container that provides basic ITS-S-related data.</p></list-item>
<list-item>
<p>One high-frequency container that provides highly dynamic data of the ITS-S. i.e., vehicle movement status and basic vehicle sensor data.</p></list-item>
<list-item>
<p>One low-frequency container that provides static and non highly dynamic data of the ITS-S.</p></list-item>
<list-item>
<p>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.</p></list-item>
</list></p>
<p>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 <xref ref-type="fig" rid="fig-4">Fig. 4</xref>:
<list list-type="bullet">
<list-item>
<p>Interest community list: provides the IDs of all the communities that the vehicle belongs to.</p></list-item>
<list-item>
<p>Active communities: provides the current active community, in other words, the community that the vehicle is currently interested in its produced content.</p></list-item>
</list></p>
<p>Each receiver of the CAM message will extract its nearby vehicles memberships and store them in the neighbors&#x2019; table grouped by communities names to use them in the future forwarding processes (<xref ref-type="table" rid="table-2">Tab. 2</xref>).</p>
<table-wrap id="table-2">
<label>Table 2</label>
<caption>
<title>Modified structure of a neighbor table.</title>
</caption>
<table frame="hsides">
<colgroup>
<col align="left"/>
<col align="left"/>
<col align="left"/>
<col align="left"/>
<col align="left"/>
</colgroup>
<thead>
<tr>
<th>Community name</th>
<th>Id</th>
<th>Position</th>
<th>Speed (Km/h)</th>
<th>direction</th>
</tr>
</thead>
<tbody>
<tr>
<td rowspan="3">Taxi community</td>
<td>Vehicle A</td>
<td>(0.568, 1.556)</td>
<td>66</td>
<td>East</td>
</tr>
<tr>
<td>Vehicle E</td>
<td>(0.695, 2.694)</td>
<td>80</td>
<td>East</td>
</tr>
<tr>
<td>Vehicle F</td>
<td>(3.452, 1.068)</td>
<td>75</td>
<td>West</td>
</tr>
<tr>
<td rowspan="2">Sport community</td>
<td>Vehicle B</td>
<td>(0.265, 0.9563)</td>
<td>50</td>
<td>East</td>
</tr>
<tr>
<td>Vehicle C</td>
<td>(1.268, 4.569)</td>
<td>75</td>
<td>West</td>
</tr>
</tbody>
</table>
</table-wrap>
</sec>
<sec id="s3_3_3">
<label>3.3.3</label>
<title>New VSN Node Design</title>
<p>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 <xref ref-type="fig" rid="fig-5">Fig. 5</xref> we have added one new field in the CS &#x201C;community&#x201D; 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.</p>
<fig id="fig-5">
<label>Figure 5</label>
<caption>
<title>New VSN node design</title>
</caption>
<graphic mimetype="image" mime-subtype="png" xlink:href="CMC_28619-fig-5.png"/>
</fig>
<p><list list-type="bullet">
<list-item>
<p>Social contents accessibility: We have two categories of contents: (i) &#x2018;Public contents&#x2019; accessible by all vehicles in the network and (ii) &#x2018;Private contents&#x2019; 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.</p></list-item>
<list-item>
<p>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.</p></list-item>
</list></p>
</sec>
<sec id="s3_3_4">
<label>3.3.4</label>
<title>Retrieving VSN General Contents</title>
<p>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 <xref ref-type="fig" rid="fig-6">Fig. 6</xref>. 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 [<xref ref-type="bibr" rid="ref-29">29</xref>], and send data packets back to the requester using the defer timer <inline-formula id="ieqn-31"><mml:math id="mml-ieqn-31"><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mrow><mml:mi mathvariant="italic">D</mml:mi><mml:mi mathvariant="italic">a</mml:mi><mml:mi mathvariant="italic">t</mml:mi><mml:mi mathvariant="italic">a</mml:mi><mml:mi mathvariant="italic">P</mml:mi><mml:mi mathvariant="italic">K</mml:mi></mml:mrow></mml:mrow></mml:msub></mml:math></inline-formula> to avoid collision. Upon receiving the data packet, all other nodes in the vicinity, stop the interest forwarding process. In another scenario, if there is no data-mule in the surrounding area, each interest receiver vehicle becomes a potential forwarder. However, in VNDN network, a vehicle may have many neighbors, and all of them could be potential forwarders. This could lead to a huge collision problem. Our solution for this problem is by deferring interest forwarding. Each forwarder generates a random defer timer <inline-formula id="ieqn-32"><mml:math id="mml-ieqn-32"><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mrow><mml:mi mathvariant="italic">I</mml:mi><mml:mi mathvariant="italic">n</mml:mi><mml:mi mathvariant="italic">t</mml:mi><mml:mi mathvariant="italic">P</mml:mi><mml:mi mathvariant="italic">K</mml:mi></mml:mrow></mml:mrow></mml:msub></mml:math></inline-formula> and listens to the channel. At the expiration of <inline-formula id="ieqn-33"><mml:math id="mml-ieqn-33"><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mrow><mml:mi mathvariant="italic">I</mml:mi><mml:mi mathvariant="italic">n</mml:mi><mml:mi mathvariant="italic">t</mml:mi><mml:mi mathvariant="italic">P</mml:mi><mml:mi mathvariant="italic">K</mml:mi></mml:mrow></mml:mrow></mml:msub></mml:math></inline-formula> if it overhears the same interest it cancels the forwarding process, otherwise, it pursues it.</p>
<fig id="fig-6">
<label>Figure 6</label>
<caption>
<title>Performed actions to retrieve general VSN contents</title>
</caption>
<graphic mimetype="image" mime-subtype="png" xlink:href="CMC_28619-fig-6.png"/>
</fig>
</sec>
<sec id="s3_3_5">
<label>3.3.5</label>
<title>Retrieving VSN Community Contents</title>
<p>In the second case (see <xref ref-type="fig" rid="fig-7">Fig. 7</xref>), 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&#x2019; memberships to use them in the forwarding process. We summarize this operation as follows; the requester looks up all the neighbors&#x2019; 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 <inline-formula id="ieqn-34"><mml:math id="mml-ieqn-34"><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mrow><mml:mi mathvariant="italic">D</mml:mi><mml:mi mathvariant="italic">a</mml:mi><mml:mi mathvariant="italic">t</mml:mi><mml:mi mathvariant="italic">a</mml:mi><mml:mi mathvariant="italic">P</mml:mi><mml:mi mathvariant="italic">K</mml:mi></mml:mrow></mml:mrow></mml:msub></mml:math></inline-formula>. If there is no CM holding fresh data in the requester&#x2019;s transmission range, each one of them becomes a potential forwarder and will forward the interest packet again using a random defer timer <inline-formula id="ieqn-35"><mml:math id="mml-ieqn-35"><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mrow><mml:mi mathvariant="italic">I</mml:mi><mml:mi mathvariant="italic">n</mml:mi><mml:mi mathvariant="italic">t</mml:mi><mml:mi mathvariant="italic">P</mml:mi><mml:mi mathvariant="italic">K</mml:mi></mml:mrow></mml:mrow></mml:msub></mml:math></inline-formula> then the same process described in the previous section will be repeated. In the case where there is no CM in the requester&#x2019;s transmission range, the requester can simply designate one vehicle to forward the interest packet, mostly the further vehicle, by calculating the distance to all the neighboring vehicles. When the network density is sparse, the forwarder vehicle can carry the interest packet for a while, and forward it later when it reaches a new area with a relatively high density, in such a way to best accomplish data dissemination and avoid any packet losses. In either situation, the procedure is repeated until a data packet is found or the interest packet lifetime expires. Note that the data packet follows always the same reverse path of the interest packet in both cases (i.e., general content and community content retrieval).</p>
<fig id="fig-7">
<label>Figure 7</label>
<caption>
<title>Performed actions to retrieve VSN taxi community contents</title>
</caption>
<graphic mimetype="image" mime-subtype="png" xlink:href="CMC_28619-fig-7.png"/>
</fig>
</sec>
</sec>
<sec id="s3_4">
<label>3.4</label>
<title>Cache Management</title>
<p>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&#x2019; allocated cache space is full, a priority-based cache replacement approach is suggested to replace old contents. To accomplish this, we use <inline-formula id="ieqn-36"><mml:math id="mml-ieqn-36"><mml:mi>C</mml:mi><mml:msub><mml:mi>S</mml:mi><mml:mrow><mml:mrow><mml:mi mathvariant="italic">r</mml:mi><mml:mi mathvariant="italic">e</mml:mi><mml:mi mathvariant="italic">s</mml:mi><mml:mi mathvariant="italic">i</mml:mi><mml:mi mathvariant="italic">d</mml:mi><mml:mi mathvariant="italic">e</mml:mi><mml:mi mathvariant="italic">n</mml:mi><mml:mi mathvariant="italic">t</mml:mi></mml:mrow><mml:mspace width="0.4em"/><mml:mi>t</mml:mi><mml:mi>i</mml:mi><mml:mi>m</mml:mi><mml:mi>e</mml:mi></mml:mrow></mml:msub></mml:math></inline-formula> to determine which old CS entries should be replaced. <xref ref-type="disp-formula" rid="eqn-6">Eq. (6)</xref> indicates how <inline-formula id="ieqn-37"><mml:math id="mml-ieqn-37"><mml:mi>C</mml:mi><mml:msub><mml:mi>S</mml:mi><mml:mrow><mml:mrow><mml:mi mathvariant="italic">r</mml:mi><mml:mi mathvariant="italic">e</mml:mi><mml:mi mathvariant="italic">s</mml:mi><mml:mi mathvariant="italic">i</mml:mi><mml:mi mathvariant="italic">d</mml:mi><mml:mi mathvariant="italic">e</mml:mi><mml:mi mathvariant="italic">n</mml:mi><mml:mi mathvariant="italic">t</mml:mi></mml:mrow><mml:mspace width="0.4em"/><mml:mi>t</mml:mi><mml:mi>i</mml:mi><mml:mi>m</mml:mi><mml:mi>e</mml:mi></mml:mrow></mml:msub></mml:math></inline-formula> is calculated:</p>
<p><disp-formula id="eqn-6"><label>(6)</label><mml:math id="mml-eqn-6" display="block"><mml:mi>C</mml:mi><mml:msub><mml:mi>S</mml:mi><mml:mrow><mml:mrow><mml:mi mathvariant="italic">r</mml:mi><mml:mi mathvariant="italic">e</mml:mi><mml:mi mathvariant="italic">s</mml:mi><mml:mi mathvariant="italic">i</mml:mi><mml:mi mathvariant="italic">d</mml:mi><mml:mi mathvariant="italic">e</mml:mi><mml:mi mathvariant="italic">n</mml:mi><mml:mi mathvariant="italic">t</mml:mi></mml:mrow><mml:mspace width="0.4em"/><mml:mi>t</mml:mi><mml:mi>i</mml:mi><mml:mi>m</mml:mi><mml:mi>e</mml:mi></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:mfrac><mml:mrow><mml:mi>D</mml:mi><mml:mi>a</mml:mi><mml:mi>t</mml:mi><mml:msub><mml:mi>a</mml:mi><mml:mrow><mml:mrow><mml:mi mathvariant="italic">f</mml:mi><mml:mi mathvariant="italic">r</mml:mi><mml:mi mathvariant="italic">e</mml:mi><mml:mi mathvariant="italic">s</mml:mi><mml:mi mathvariant="italic">h</mml:mi><mml:mi mathvariant="italic">e</mml:mi><mml:mi mathvariant="italic">n</mml:mi><mml:mi mathvariant="italic">e</mml:mi><mml:mi mathvariant="italic">s</mml:mi><mml:mi mathvariant="italic">s</mml:mi></mml:mrow></mml:mrow></mml:msub></mml:mrow><mml:msub><mml:mrow><mml:mi mathvariant="italic">C</mml:mi><mml:mi mathvariant="italic">o</mml:mi><mml:mi mathvariant="italic">m</mml:mi><mml:mi mathvariant="italic">m</mml:mi><mml:mi mathvariant="italic">u</mml:mi><mml:mi mathvariant="italic">n</mml:mi><mml:mi mathvariant="italic">i</mml:mi><mml:mi mathvariant="italic">t</mml:mi><mml:mi mathvariant="italic">y</mml:mi></mml:mrow><mml:mrow><mml:mrow><mml:mi mathvariant="italic">p</mml:mi><mml:mi mathvariant="italic">r</mml:mi><mml:mi mathvariant="italic">i</mml:mi><mml:mi mathvariant="italic">o</mml:mi><mml:mi mathvariant="italic">r</mml:mi><mml:mi mathvariant="italic">i</mml:mi><mml:mi mathvariant="italic">t</mml:mi><mml:mi mathvariant="italic">y</mml:mi></mml:mrow></mml:mrow></mml:msub></mml:mfrac></mml:math></disp-formula>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.</p>
</sec>
</sec>
<sec id="s4">
<label>4</label>
<title>Performance Evaluation</title>
<p>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.</p>
<sec id="s4_1">
<label>4.1</label>
<title>Simulation Setup</title>
<p>Our purpose is to analyze and compare SAFT-VNDN&#x2019;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 &#x00D7; 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&#x2019; 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. <xref ref-type="table" rid="table-3">Tab. 3</xref> summarizes the main simulation parameters.</p>
<table-wrap id="table-3">
<label>Table 3</label>
<caption>
<title>Simulation parameters.</title>
</caption>
<table frame="hsides">
<colgroup>
<col align="left"/>
<col align="left"/>
</colgroup>
<thead>
<tr>
<th>Parameter</th>
<th>Default value</th>
</tr>
</thead>
<tbody>
<tr>
<td>Density of vehicles</td>
<td>[50,250]</td>
</tr>
<tr>
<td>Simulated area</td>
<td>1 &#x00D7; 1 km</td>
</tr>
<tr>
<td>Vehicles&#x2019; maximum speed</td>
<td>70 (Km/h)</td>
</tr>
<tr>
<td>Number of content requester</td>
<td>[50,250]</td>
</tr>
<tr>
<td>Number of community content producer</td>
<td>9</td>
</tr>
<tr>
<td>Communication technology</td>
<td>IEEE 802.11p</td>
</tr>
<tr>
<td>Transmission range</td>
<td>300 m</td>
</tr>
</tbody>
</table>
</table-wrap>
<p>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 <inline-formula id="ieqn-38"><mml:math id="mml-ieqn-38"><mml:mi>C</mml:mi><mml:msub><mml:mi>S</mml:mi><mml:mrow><mml:mrow><mml:mi mathvariant="italic">r</mml:mi><mml:mi mathvariant="italic">e</mml:mi><mml:mi mathvariant="italic">s</mml:mi><mml:mi mathvariant="italic">i</mml:mi><mml:mi mathvariant="italic">d</mml:mi><mml:mi mathvariant="italic">e</mml:mi><mml:mi mathvariant="italic">n</mml:mi><mml:mi mathvariant="italic">t</mml:mi></mml:mrow><mml:mspace width="0.4em"/><mml:mi>t</mml:mi><mml:mi>i</mml:mi><mml:mi>m</mml:mi><mml:mi>e</mml:mi></mml:mrow></mml:msub></mml:math></inline-formula>.</p>
<p>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:
<list list-type="bullet">
<list-item>
<p>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).</p></list-item>
<list-item>
<p>Data delivery ratio: the ratio of successfully delivered data packets to the total number of originally issued interest packets in a given period.</p></list-item>
<list-item>
<p>Cache hit ratio: the ratio of cache hits to the sum between cache hits and cache misses.</p></list-item>
</list></p>
</sec>
<sec id="s4_2">
<label>4.2</label>
<title>Results Discussion</title>
<p>Results in figure <xref ref-type="fig" rid="fig-8">Fig. 8</xref> 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.</p>
<fig id="fig-8">
<label>Figure 8</label>
<caption>
<title>Average number of CM per hops over the number of CM in the network</title>
</caption>
<graphic mimetype="image" mime-subtype="png" xlink:href="CMC_28619-fig-8.png"/>
</fig>
<p>This experiment finding is important to correctly interpret the results illustrated in <xref ref-type="fig" rid="fig-9">Fig. 9</xref>, which depicts the cache-hit ratio according to the network density. The SAFT-VNDN cache hit ratio is compared to VNDN&#x2019;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 <xref ref-type="fig" rid="fig-10">Fig. 10</xref> show the cache hit of each community separately, as well as the cache hit of general contents. It is obvious that the three communities&#x2019; cache-hits are proportionally better than the general content cache hit. This result ties well with what we demonstrated in <xref ref-type="fig" rid="fig-9">Fig. 9</xref>. 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.</p>
<fig id="fig-9">
<label>Figure 9</label>
<caption>
<title>Cache hit ratio per community in respect to the number of vehicles</title>
</caption>
<graphic mimetype="image" mime-subtype="png" xlink:href="CMC_28619-fig-9.png"/>
</fig>
<fig id="fig-10">
<label>Figure 10</label>
<caption>
<title>Cache hit ratio per community in respect of the number of vehicles</title>
</caption>
<graphic mimetype="image" mime-subtype="png" xlink:href="CMC_28619-fig-10.png"/>
</fig>
<p>Simulation results in <xref ref-type="fig" rid="fig-11">Fig. 11</xref> 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 [<xref ref-type="bibr" rid="ref-29">29</xref>]. 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 <xref ref-type="fig" rid="fig-12">Fig. 12</xref> 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. <xref ref-type="fig" rid="fig-13">Fig. 13</xref>, 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.</p>
<fig id="fig-11">
<label>Figure 11</label>
<caption>
<title>Average data delivery delay in respect of the number of vehicles</title>
</caption>
<graphic mimetype="image" mime-subtype="png" xlink:href="CMC_28619-fig-11.png"/>
</fig>
<p>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 <xref ref-type="fig" rid="fig-8">Fig. 8</xref>.</p>
<fig id="fig-12">
<label>Figure 12</label>
<caption>
<title>Data delivery ratio in respect of the number of vehicles</title>
</caption>
<graphic mimetype="image" mime-subtype="png" xlink:href="CMC_28619-fig-12.png"/>
</fig>
<fig id="fig-13">
<label>Figure 13</label>
<caption>
<title>Data delivery ratio per community in respect of the number of vehicles</title>
</caption>
<graphic mimetype="image" mime-subtype="png" xlink:href="CMC_28619-fig-13.png"/>
</fig>
</sec>
</sec>
<sec id="s5">
<label>5</label>
<title>Conclusion and Future Work</title>
<p>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&#x2019; 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&#x2019; profiles in Online Social Networks to predict their future interests and hence, better optimize the search/forward processes.</p>
</sec>
</body>
<back>
<fn-group>
<fn fn-type="other"><p><bold>Funding Statement:</bold> The research was supported by the Office of Research and Sponsored Programs, Kean University.</p></fn>
<fn fn-type="conflict"><p><bold>Conflicts of Interest:</bold> The authors declare that they have no conflicts of interest to report regarding the present study.</p></fn>
</fn-group>
<ref-list content-type="authoryear">
<title>References</title>
<ref id="ref-1"><label>[1]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><given-names>I. M.</given-names> <surname>Hassan</surname></string-name> and <string-name><given-names>K. R.</given-names> <surname>Hassan</surname></string-name></person-group>, &#x201C;<article-title>Vehicular social networks and vehicular ad-hoc networks, applications, modelling tools and challenges: A survey</article-title>,&#x201D; <source>International Journal of Computer Applications</source>, vol. <volume>176</volume>, no. <issue>25</issue>, pp. <fpage>32</fpage>&#x2013;<lpage>38</lpage>, <year>2020</year>.</mixed-citation></ref>
<ref id="ref-2"><label>[2]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><given-names>A.</given-names> <surname>Rahim</surname></string-name>, <string-name><given-names>X.</given-names> <surname>Kong</surname></string-name>, <string-name><given-names>F.</given-names> <surname>Xia</surname></string-name>, <string-name><given-names>Z.</given-names> <surname>Ning</surname></string-name>, <string-name><given-names>N.</given-names> <surname>Ullah</surname></string-name> <etal>et al.</etal></person-group><italic>,</italic> &#x201C;<article-title>Vehicular social networks: A survey</article-title>,&#x201D; <source>Pervasive and Mobile Computing</source>, vol. <volume>43</volume>, no. <issue>1</issue>, pp. <fpage>96</fpage>&#x2013;<lpage>113</lpage>, <year>2018</year>.</mixed-citation></ref>
<ref id="ref-3"><label>[3]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><given-names>C. A.</given-names> <surname>Kerrache</surname></string-name>, <string-name><given-names>N.</given-names> <surname>Lagraa</surname></string-name>, <string-name><given-names>R.</given-names> <surname>Hussain</surname></string-name>, <string-name><given-names>S. H.</given-names> <surname>Ahmed</surname></string-name>, <string-name><given-names>A.</given-names> <surname>Benslimane</surname></string-name> <etal>et al.</etal></person-group><italic>,</italic> &#x201C;<article-title>TACASHI: Trust-aware communication architecture for social internet of vehicles</article-title>,&#x201D; <source>IEEE Internet of Things Journal</source>, vol. <volume>6</volume>, no. <issue>4</issue>, pp. <fpage>5870</fpage>&#x2013;<lpage>5877</lpage>, <year>2018</year>.</mixed-citation></ref>
<ref id="ref-4"><label>[4]</label><mixed-citation publication-type="conf-proc"><person-group person-group-type="author"><string-name><given-names>S.</given-names> <surname>Smaldone</surname></string-name>, <string-name><given-names>L.</given-names> <surname>Han</surname></string-name>, <string-name><given-names>P.</given-names> <surname>Shankar</surname></string-name> and <string-name><given-names>L.</given-names> <surname>Iftode</surname></string-name></person-group>, &#x201C;<article-title>Roadspeak: Enabling voice chat on roadways using vehicular social networks</article-title>,&#x201D; in <conf-name>Proc. of the 1st Workshop on Social Network Systems</conf-name>, <conf-loc>Glasgow Scotland</conf-loc>, pp. <fpage>43</fpage>&#x2013;<lpage>48</lpage>, <year>2008</year>. </mixed-citation></ref>
<ref id="ref-5"><label>[5]</label><mixed-citation publication-type="conf-proc"><person-group person-group-type="author"><string-name><given-names>D.</given-names> <surname>Kwak</surname></string-name>, <string-name><given-names>D.</given-names> <surname>Kim</surname></string-name>, <string-name><given-names>R.</given-names> <surname>Liu</surname></string-name>, <string-name><given-names>B.</given-names> <surname>Nath</surname></string-name> and <string-name><given-names>L.</given-names> <surname>Iftode</surname></string-name></person-group>, &#x201C;<article-title>DoppelDriver: Counterfactual actual travel times for alternative routes</article-title>,&#x201D; in <conf-name>2015 IEEE Int. Conf. on Pervasive Computing and Communications (PerCom)</conf-name>, <conf-loc>St. Louis, MO, USA</conf-loc>, <publisher-name>IEEE</publisher-name>, pp. <fpage>178</fpage>&#x2013;<lpage>185</lpage>, <year>2015</year>. </mixed-citation></ref>
<ref id="ref-6"><label>[6]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><given-names>D.</given-names> <surname>Kwak</surname></string-name>, <string-name><given-names>R.</given-names> <surname>Liu</surname></string-name>, <string-name><given-names>D.</given-names> <surname>Kim</surname></string-name>, <string-name><given-names>B.</given-names> <surname>Nath</surname></string-name> and <string-name><given-names>L.</given-names> <surname>Iftode</surname></string-name></person-group>, &#x201C;<article-title>Seeing is believing: Sharing real-time visual traffic information via vehicular clouds</article-title>,&#x201D; <source>IEEE Access</source>, vol. <volume>4</volume>, pp. <fpage>3617</fpage>&#x2013;<lpage>3631</lpage>, <year>2016</year>.</mixed-citation></ref>
<ref id="ref-7"><label>[7]</label><mixed-citation publication-type="conf-proc"><person-group person-group-type="author"><string-name><given-names>D.</given-names> <surname>Kwak</surname></string-name>, <string-name><given-names>D.</given-names> <surname>Kim</surname></string-name>, <string-name><given-names>R.</given-names> <surname>Liu</surname></string-name>, <string-name><given-names>L.</given-names> <surname>Iftode</surname></string-name> and <string-name><given-names>B.</given-names> <surname>Nath</surname></string-name></person-group>, &#x201C;<article-title>Tweeting traffic image reports on the road</article-title>,&#x201D; in <conf-name>6th Int. Conf. on Mobile Computing, Applications and Services (MobiCASE)</conf-name>, <conf-loc>Austin, TX, USA</conf-loc>, pp. <fpage>40</fpage>&#x2013;<lpage>48</lpage>, <year>2014</year>. </mixed-citation></ref>
<ref id="ref-8"><label>[8]</label><mixed-citation publication-type="conf-proc"><person-group person-group-type="author"><string-name><given-names>W.</given-names> <surname>Sha</surname></string-name>, <string-name><given-names>D.</given-names> <surname>Kwak</surname></string-name>, <string-name><given-names>B.</given-names> <surname>Nath</surname></string-name> and <string-name><given-names>L.</given-names> <surname>Iftode</surname></string-name></person-group>, &#x201C;<article-title>Social vehicle navigation: Integrating shared driving experience into vehicle navigation</article-title>,&#x201D; in <conf-name>Proc. of the 14th Workshop on Mobile Computing Systems and Applications (HotMobile)</conf-name>, <conf-loc>Jekyll Island, Georgia, USA</conf-loc>, pp. <fpage>1</fpage>&#x2013;<lpage>6</lpage>, <year>2013</year>. </mixed-citation></ref>
<ref id="ref-9"><label>[9]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><given-names>B.</given-names> <surname>Zhang</surname></string-name>, <string-name><given-names>R.</given-names> <surname>Tian</surname></string-name> and <string-name><given-names>C.</given-names> <surname>Li</surname></string-name></person-group>, &#x201C;<article-title>Content dissemination and routing for vehicular social networks: A networking perspective</article-title>,&#x201D; <source>IEEE Wireless Communications</source>, vol. <volume>27</volume>, no. <issue>2</issue>, pp. <fpage>118</fpage>&#x2013;<lpage>126</lpage>, <year>2019</year>.</mixed-citation></ref>
<ref id="ref-10"><label>[10]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><given-names>M.</given-names> <surname>Zhang</surname></string-name>, <string-name><given-names>X.</given-names> <surname>Wang</surname></string-name>, <string-name><given-names>T.</given-names> <surname>Liu</surname></string-name>, <string-name><given-names>J.</given-names> <surname>Zhu</surname></string-name> and <string-name><given-names>Q.</given-names> <surname>Wu</surname></string-name></person-group>, &#x201C;<article-title>AFSndn: A novel adaptive forwarding strategy in named data networking based on Q-learning</article-title>,&#x201D; <source>Peer-to-Peer Networking and Applications</source>, vol. <volume>13</volume>, no. <issue>4</issue>, pp. <fpage>1176</fpage>&#x2013;<lpage>1184</lpage>, <year>2020</year>.</mixed-citation></ref>
<ref id="ref-11"><label>[11]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><given-names>W.</given-names> <surname>Sun</surname></string-name>, <string-name><given-names>G. Z.</given-names> <surname>Dai</surname></string-name>, <string-name><given-names>X. R.</given-names> <surname>Zhang</surname></string-name>, <string-name><given-names>X. Z.</given-names> <surname>He</surname></string-name> and <string-name><given-names>X.</given-names> <surname>Chen</surname></string-name></person-group>, &#x201C;<article-title>TBE-Net: A three-branch embedding network with part-aware ability and feature complementary learning for vehicle re-identification</article-title>,&#x201D; <source>IEEE Transactions on Intelligent Transportation Systems</source>, pp. <fpage>1</fpage>&#x2013;<lpage>13</lpage>, <year>2021</year>. <uri xlink:href="https://doi.org/10.1109/TITS.2021.3130403">https://doi.org/10.1109/TITS.2021.3130403</uri>.</mixed-citation></ref>
<ref id="ref-12"><label>[12]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><given-names>W.</given-names> <surname>Sun</surname></string-name>, <string-name><given-names>L.</given-names> <surname>Dai</surname></string-name>, <string-name><given-names>X. R.</given-names> <surname>Zhang</surname></string-name>, <string-name><given-names>P. S.</given-names> <surname>Chang</surname></string-name> and <string-name><given-names>X. Z.</given-names> <surname>He</surname></string-name></person-group>, &#x201C;<article-title>RSOD: Real-time small object detection algorithm in UAV-based traffic monitoring</article-title>,&#x201D; <source>Applied Intelligence</source>, pp. <fpage>1</fpage>&#x2013;<lpage>16</lpage>, <year>2021</year>. <uri xlink:href="https://doi.org/10.1007/s10489-021-02893-3">https://doi.org/10.1007/s10489-021-02893-3</uri>.</mixed-citation></ref>
<ref id="ref-13"><label>[13]</label><mixed-citation publication-type="conf-proc"><person-group person-group-type="author"><string-name><given-names>G.</given-names> <surname>Grassi</surname></string-name>, <string-name><given-names>D.</given-names> <surname>Pesavento</surname></string-name>, <string-name><given-names>G.</given-names> <surname>Pau</surname></string-name>, <string-name><given-names>R.</given-names> <surname>Vuyyuru</surname></string-name> and <string-name><given-names>R.</given-names> <surname>Wakikawa</surname></string-name></person-group>, &#x201C;<article-title>VANET via named data networking</article-title>,&#x201D; in <conf-name>IEEE Conf. on Computer Communications Workshops (INFOCOM WKSHPS)</conf-name>, <conf-loc>Toronto, Canada</conf-loc>, pp. <fpage>410</fpage>&#x2013;<lpage>415</lpage>, <year>2014</year>. </mixed-citation></ref>
<ref id="ref-14"><label>[14]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><given-names>K.</given-names> <surname>Ahed</surname></string-name>, <string-name><given-names>M.</given-names> <surname>Benamar</surname></string-name>, <string-name><given-names>A. A.</given-names> <surname>Lahcen</surname></string-name> and <string-name><given-names>R. El</given-names> <surname>Ouazzani</surname></string-name></person-group>, &#x201C;<article-title>Forwarding strategies in vehicular named data networks: A survey</article-title>,&#x201D; <source>Journal of King Saud University-Computer and Information Sciences</source>, vol. <volume>34</volume>, pp. <fpage>1819</fpage>&#x2013;<lpage>1835</lpage>, <year>2020</year>.</mixed-citation></ref>
<ref id="ref-15"><label>[15]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><given-names>H.</given-names> <surname>Khelifi</surname></string-name>, <string-name><given-names>S.</given-names> <surname>Luo</surname></string-name>, <string-name><given-names>B.</given-names> <surname>Nour</surname></string-name>, <string-name><given-names>H.</given-names> <surname>Moungla</surname></string-name>, <string-name><given-names>Y.</given-names> <surname>Faheem</surname></string-name> <etal>et al.</etal></person-group><italic>,</italic> &#x201C;<article-title>Named data networking in vehicular ad hoc networks: State-of-the-art and challenges</article-title>,&#x201D; <source>IEEE Communications Surveys &#x0026; Tutorials</source>, vol. <volume>22</volume>, no. <issue>1</issue>, pp. <fpage>320</fpage>&#x2013;<lpage>351</lpage>, <year>2019</year>.</mixed-citation></ref>
<ref id="ref-16"><label>[16]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><given-names>E.</given-names> <surname>Barka</surname></string-name>, <string-name><given-names>C. A.</given-names> <surname>Kerrache</surname></string-name>, <string-name><given-names>R.</given-names> <surname>Hussain</surname></string-name>, <string-name><given-names>N.</given-names> <surname>Lagraa</surname></string-name>, <string-name><given-names>A.</given-names> <surname>Lakas</surname></string-name> <etal>et al.</etal></person-group><italic>,</italic> &#x201C;<article-title>A trusted lightweight communication strategy for flying named data networking</article-title>,&#x201D; <source>Sensors</source>, vol. <volume>18</volume>, no. <issue>8</issue>, pp. <fpage>2683</fpage>, <year>2018</year>.</mixed-citation></ref>
<ref id="ref-17"><label>[17]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><given-names>F.</given-names> <surname>Ahmad</surname></string-name>, <string-name><given-names>C. A.</given-names> <surname>Kerrache</surname></string-name>, <string-name><given-names>F.</given-names> <surname>Kurugollu</surname></string-name> and <string-name><given-names>R.</given-names> <surname>Hussain</surname></string-name></person-group>, &#x201C;<article-title>Realization of blockchain in named data networking-based internet-of-vehicles</article-title>,&#x201D; <source>IT Professional</source>, vol. <volume>21</volume>, no. <issue>4</issue>, pp. <fpage>41</fpage>&#x2013;<lpage>47</lpage>, <year>2019</year>.</mixed-citation></ref>
<ref id="ref-18"><label>[18]</label><mixed-citation publication-type="book"><person-group person-group-type="author"><string-name><given-names>C. A.</given-names> <surname>Kerrche</surname></string-name>, <string-name><given-names>F.</given-names> <surname>Ahmad</surname></string-name>, <string-name><given-names>M.</given-names> <surname>Elhoseny</surname></string-name>, <string-name><given-names>A.</given-names> <surname>Adnane</surname></string-name>, <string-name><given-names>Z.</given-names> <surname>Ahmad</surname></string-name> <etal>et al.</etal></person-group><italic>,</italic> &#x201C;<chapter-title>Internet of vehicles over named data networking: Current status and future challenges</chapter-title>,&#x201D; in <source>Emerging Technologies for Connected Internet of Vehicles and Intelligent Transportation System Networks</source>, <publisher-loc>New York, USA: Springer</publisher-loc>, pp. <fpage>83</fpage>&#x2013;<lpage>99</lpage>, <year>2020</year>.</mixed-citation></ref>
<ref id="ref-19"><label>[19]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><given-names>M.</given-names> <surname>Amadeo</surname></string-name>, <string-name><given-names>G.</given-names> <surname>Ruggeri</surname></string-name>, <string-name><given-names>C.</given-names> <surname>Campolo</surname></string-name> and <string-name><given-names>A.</given-names> <surname>Molinaro</surname></string-name></person-group>, &#x201C;<article-title>Diversity-improved caching of popular transient contents in vehicular named data networking</article-title>,&#x201D; <source>Computer Networks</source>, vol. <volume>184</volume>, pp. <fpage>107625</fpage>, <year>2021</year>.</mixed-citation></ref>
<ref id="ref-20"><label>[20]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><given-names>M.</given-names> <surname>Al-Qutwani</surname></string-name>, <string-name><given-names>X.</given-names> <surname>Wang</surname></string-name> and <string-name><given-names>B.</given-names> <surname>Yi</surname></string-name></person-group>, &#x201C;<article-title>Request/Advertise-based content forwarding in vehicular named data networking</article-title>,&#x201D; <source>IEEE Access</source>, vol. <volume>9</volume>, pp. <fpage>226</fpage>&#x2013;<lpage>236</lpage>, <year>2020</year>.</mixed-citation></ref>
<ref id="ref-21"><label>[21]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><given-names>Y.</given-names> <surname>Xu</surname></string-name>, <string-name><given-names>S.</given-names> <surname>Tong</surname></string-name>, <string-name><given-names>T.</given-names> <surname>Zhang</surname></string-name>, <string-name><given-names>W.</given-names> <surname>Sun</surname></string-name>, <string-name><given-names>X.</given-names> <surname>Hu</surname></string-name> <etal>et al.</etal></person-group><italic>,</italic> &#x201C;<article-title>Compass: Directing named data transmission in VANETs by dynamic directional interfaces</article-title>,&#x201D; <source>IEEE Access</source>, vol. <volume>8</volume>, pp. <fpage>8418</fpage>&#x2013;<lpage>8435</lpage>, <year>2020</year>.</mixed-citation></ref>
<ref id="ref-22"><label>[22]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><given-names>A. A.</given-names> <surname>Prates</surname></string-name>, <string-name><given-names>I. V.</given-names> <surname>Bastos</surname></string-name> and <string-name><given-names>I. M.</given-names> <surname>Moraes</surname></string-name></person-group>, &#x201C;<article-title>GeoZone: An interest-packet forwarding mechanism based on dissemination zone for content-centric vehicular networks</article-title>,&#x201D; <source>Computers &#x0026; Electrical Engineering</source>, vol. <volume>73</volume>, pp. <fpage>155</fpage>&#x2013;<lpage>166</lpage>, <year>2019</year>.</mixed-citation></ref>
<ref id="ref-23"><label>[23]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><given-names>X.</given-names> <surname>Wang</surname></string-name> and <string-name><given-names>Y.</given-names> <surname>Li</surname></string-name></person-group>, &#x201C;<article-title>Vehicular named data networking framework</article-title>,&#x201D; <source>IEEE Transactions on Intelligent Transportation Systems</source>, vol. <volume>21</volume>, no. <issue>11</issue>, pp. <fpage>4705</fpage>&#x2013;<lpage>4714</lpage>, <year>2019</year>.</mixed-citation></ref>
<ref id="ref-24"><label>[24]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><given-names>H.</given-names> <surname>Al-Omaisi</surname></string-name>, <string-name><given-names>E. A.</given-names> <surname>Sundararajan</surname></string-name>, <string-name><given-names>R.</given-names> <surname>Alsaqour</surname></string-name>, <string-name><given-names>N. F.</given-names> <surname>Abdullah</surname></string-name> and <string-name><given-names>M.</given-names> <surname>Abdelhaq</surname></string-name></person-group>, &#x201C;<article-title>A survey of data dissemination schemes in vehicular named data networking</article-title>,&#x201D; <source>Vehicular Communications</source>, vol. <volume>30</volume>, pp. <fpage>100353</fpage>, <year>2021</year>.</mixed-citation></ref>
<ref id="ref-25"><label>[25]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><given-names>C.</given-names> <surname>Chen</surname></string-name>, <string-name><given-names>C.</given-names> <surname>Wang</surname></string-name>, <string-name><given-names>T.</given-names> <surname>Qiu</surname></string-name>, <string-name><given-names>M.</given-names> <surname>Atiquzzaman</surname></string-name> and <string-name><given-names>D. O.</given-names> <surname>Wu</surname></string-name></person-group>, &#x201C;<article-title>Caching in vehicular named data networking: Architecture, schemes and future directions</article-title>,&#x201D; <source>IEEE Communications Surveys &#x0026; Tutorials</source>, vol. <volume>22</volume>, no. <issue>4</issue>, pp. <fpage>2378</fpage>&#x2013;<lpage>2407</lpage>, <year>2020</year>.</mixed-citation></ref>
<ref id="ref-26"><label>[26]</label><mixed-citation publication-type="conf-proc"><person-group person-group-type="author"><string-name><given-names>J.</given-names> <surname>Li</surname></string-name>, <string-name><given-names>J.</given-names> <surname>Jannotti</surname></string-name>, <string-name><given-names>D. S.</given-names> <surname>De Couto</surname></string-name>, <string-name><given-names>D. R.</given-names> <surname>Karger</surname></string-name> and <string-name><given-names>R.</given-names> <surname>Morris</surname></string-name></person-group>, &#x201C;<article-title>A scalable location service for geographic ad hoc routing</article-title>,&#x201D; in <conf-name>Proc. of the 6th Annual Int. Conf. on Mobile Computing and Networking</conf-name>, <conf-loc>Boston, Massachusetts, USA</conf-loc>, pp. <fpage>120</fpage>&#x2013;<lpage>130</lpage>, <year>2000</year>. </mixed-citation></ref>
<ref id="ref-27"><label>[27]</label><mixed-citation publication-type="other"><person-group person-group-type="author"><collab>ETSI-ITS</collab></person-group>, &#x201C;<article-title>ETSI EN 302 890-2 V2.1.1, Intelligent transport systems (ITS); Facilities layer function; Part 2: Position and time management (PoTi)</article-title>,&#x201D; <comment>Technical report, Release 2 (2020-03)</comment>.</mixed-citation></ref>
<ref id="ref-28"><label>[28]</label><mixed-citation publication-type="conf-proc"><person-group person-group-type="author"><string-name><given-names>D. O.</given-names> <surname>Mau</surname></string-name>, <string-name><given-names>Y.</given-names> <surname>Zhang</surname></string-name>, <string-name><given-names>T.</given-names> <surname>Taleb</surname></string-name> and <string-name><given-names>M.</given-names> <surname>Chen</surname></string-name></person-group>, &#x201C;<article-title>Vehicular inter-networking via named data-an opnet simulation study</article-title>,&#x201D; in <conf-name>Int. Conf. on Testbeds and Research Infrastructures</conf-name>, <conf-loc>Guangzhou, China</conf-loc>, pp. <fpage>116</fpage>&#x2013;<lpage>125</lpage>, <year>2014</year>. </mixed-citation></ref>
<ref id="ref-29"><label>[29]</label><mixed-citation publication-type="conf-proc"><person-group person-group-type="author"><string-name><given-names>A.</given-names> <surname>Silva</surname></string-name>, <string-name><given-names>K. N.</given-names> <surname>Reza</surname></string-name> and <string-name><given-names>A.</given-names> <surname>Oliveira</surname></string-name></person-group>, &#x201C;<article-title>An adaptive GPSR routing protocol for VANETs</article-title>,&#x201D; in <conf-name>15th Int. Symp. on Wireless Communication Systems (ISWCS)</conf-name>, <conf-loc>Lisbon, Portugal</conf-loc>, pp. <fpage>1</fpage>&#x2013;<lpage>6</lpage>, <year>2018</year>. </mixed-citation></ref>
</ref-list>
</back>
</article>
