RobUst Forwarder Selection in Vehicular Content-Centric Networks

1616

IEEE COMMUNICATIONS LETTERS, VOL. 19, NO. 9, SEPTEMBER 2015

RUFS: RobUst Forwarder Selection in Vehicular Content-Centric Networks Syed Hassan Ahmed, Safdar Hussain Bouk, and Dongkyun Kim

Abstract—Vehicular Content-Centric Network (VCCN) has emerged as a future network technology for vehicular networks, where the focus of communication is shifted from the host to information centric. However, VCCN faces several challenges, including interest/data packet(s) flooding, provider/consumer mobility, and so on. In this letter, we propose a scheme named RobUst Forwarder Selection (RUFS) to mitigate the interest broadcast storm. In RUFS, each vehicle shares its satisfied interest(s) statistics with neighbors. All neighbors store this information in their Neighbors Satisfied List (NSL), which helps to select the potential interest forwarder. Simulation results show that RUFS outperforms the recently proposed NAIF, DR based and basic interest forwarding in VCCN. Index Terms—VANETs, CCN, forwarder selection.

I. I NTRODUCTION

F

OR the past decades, Vehicular Ad hoc Networks (VANETs) have been rigorously investigated by researchers from industries and academia. However, for their successful market penetration, much effort is still required to deal with some typical issues in vehicular networks, which include, but not limited to dynamic topology due to fast and varying mobility, intermittent connectivity, temporal and spatial network density, etc. It is expected that future vehicles will be enable with various applications besides safety ones. For this purpose, a Dedicated Short Range Communications (DSRC) protocol for VANETs along with the Wireless Access in Vehicular Environments (WAVE) has been proposed, which supports data exchange without the TCP/IP overhead. In case of infotainment systems (i.e., non-safety applications), numerous TCP/IP protocols have been proposed to run on top of the DSRC / WAVE in VANETs. However, running IP over IEEE 802.11p brings several technical issues. To cope this, there is a rich literature in the context of ad-hoc networking over IP and various routing protocols have been proposed, however, a fundamental limitation in their deployment is the infrastructure support requirement for the purpose of global IP address allocations. Moreover, the dynamic vehicular environment also demands that routes to be recalculated and sessions to be re-established at higher frequency, which are also deemed infeasible. Recently, the researchers have employed the emerging CCN (Content Centric Network) concept for VANETs that is originally defined in the Future Internet [1]. CCN mainly alters the

Manuscript received March 18, 2015; accepted June 28, 2015. Date of publication July 1, 2015; date of current version September 4, 2015. This work was supported by Kyungpook National University Research Fund, 2015. The associate editor coordinating the review of this paper and approving it for publication was B. Bellalta. (Corresponding author: Dongkyun Kim.) The authors are with the School of Computer Science and Engineering, Kyungpook National University, Daegu 702-701, Korea (e-mail: hassan@ knu.ac.kr; [email protected]; [email protected]). Digital Object Identifier 10.1109/LCOMM.2015.2451647

communication archetype from the traditional host-based to the information centric. In existing wireless networks, each node in the network must be assigned a unique ID (e.g., IP address) so that the source node(s) use(s) this/these unique ID(s) to locate destination node(s) for data communications. On the contrary, CCN relies on simplicity to disseminate the contents between vehicles without taking IP-based information(s) into account. In CCN, the communication depends on the content “name” rather than the device’s “name”. In addition, CCN also enables multiple interfaces to be used, if available, for more reliable retrieval of the required content. Moreover, CCN supports many applications including audio/video communications, advertisements, subscriber/publisher support and so on. Similar to CCN, each node in Vehicular CCN (VCCN) also maintains three data structures: (i) a Content Store (CS) contains data/contents; (ii) a Routing Table, named Forward Information Base (FIB), manages the outgoing interface(s) to forward the Interests; (iii) a Pending Interest Table (PIT), keeps track of forwarded interest(s) so that a received content can be sent back to the consumer(s). In a simple VCCN environment, a vehicle Vi requests a content Ci by sending an interest packet in an epidemic manner. Every requesting vehicle is also known as “Consumer”. The interest packet includes name and related information of the content. Upon receiving an interest packet, the recipient vehicle Vr first checks if its CS has the content. If found, the content is sent back to the consumer. Otherwise, it searches the PIT for pending interest(s). If found, the current request is discarded. Otherwise, the new PIT entry is created and the interest is re-broadcasted. Finally, when an interest packet reaches any content provider, the provider transmits the data backwards using the same path that the interest packet traversed. Likewise traditional networks, a VCCN also faces several basic issues such as content naming, name resolution, transport issues, content caching, forwarder selection, congestion control, etc. The epidemic interest forwarding causes a broadcast storm and congestion. Recently, some efforts have been made to address the former issue in CCNs. For example, the transmission range of any mobile node is divided into four parts (i.e., quadrant), and the farthest node in each quadrant is selected as a forwarder of interest rebroadcasting [2]. Similarly, the eligibility of a forwarder is estimated based on its Data retrieval rate for a given content name and its distance to the consumer [3]. However, due to the dependency on ACK packet(s) from a forwarder or content provider, these schemes may lead to additional delay in retrieving the content(s). In this letter, we therefore propose a unique and RobUst Forwarder Selection (RUFS) scheme to mitigate the interest broadcast storm. The beauty of RUFS is the selection of only one immediate neighbor as a forwarder or relay for any interest without waiting for the ACK(s). For this purpose, RUFS

1558-2558 © 2015 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.

AHMED et al.: RUFS: ROBUST FORWARDER SELECTION IN VEHICULAR CONTENT-CENTRIC NETWORKS

1617

enables each vehicle to maintain a list of interests satisfied by its neighbors, called Neighbors Satisfied List (NSL1 ), and the list of interests satisfied by the vehicle itself, called Recent Satisfied List (RSL). To keep the NSL information updated, each vehicle periodically exchanges its RSL within its one-hop neighbors. These two tables enable Vi to rank one of its neighbors as the forwarder Vf and achieves the following objectives: (a) mitigation of the interest flooding by sending an interest packet only to Vf , (b) avoidance of unnecessary PIT entries in the network and (c) non-participation of the rest of neighboring vehicles in the interest forwarding and its related operations. Through simulations, we verify that our scheme minimizes the interest storm caused by the basic CCN and also overcomes the congestion and delay caused by additional ACK(s) and other assumptions of existing solutions. II. RUFS: ROB U ST F ORWARDER S ELECTION As mentioned before, in basic VCCN, every consumer vehicle epidemically forwards the interest packet. On the other hand, every receiving vehicle performs several operations on the interest packet(s) such as CS search, PIT search, FIB search and then scheduling interest rebroadcast in case of no content matched. Since these operations cause congestion, delay and data/interest duplication, they can be mitigated in part by controlling the interest flooding mechanism. For example, a vehicle Vi has m immediate neighbors2 and it may select the single vehicle as an interest forwarder on the basis of multiple criteria, rather than forcing all neighbors to rebroadcast the interest packets. To bring this solution in reality for VCCN, our RUFS is an initial attempt to rank the neighboring vehicles on the basis of relevant quality metrics. In RUFS, every vehicle is required to exchange its Recent Satisfied List3 (RSL) via a beacon message among its immediate neighbor(s) periodically. RSL includes a list of satisfied interests for contents C with additional information; time since the recent satisfaction of each content Ci ∈ C, the number of hops from where Ci was received, current velocity, and the Interest Satisfaction Rate (ISR). ISR of any vehicle can be calculated as: No. of Satisfied Contents ISR = No. of Requested Contents

(1)

In order to maintain RSL up-to-date, ISR is calculated both in case of interest received and interest satisfied. ISR value is high in case of dense RSL and vice versa. Upon receiving RSL, each vehicle updates its NSL table as shown in Fig. 1. NSL (Neighbor Satisfaction List) represents a list of contents satisfied by its neighbors. NSL consists vehicle id vi , for any required content (Ci ) with properties such as satisfaction time (p1 ), current velocity (p2 ), hop count (p3 ), and ISR (p4 ). There may be the case that a content Ci has been satisfied by one or more (m) neighboring vehicles such as C1 and C2 in the NSL 1 NSL is basically a replacement of FIB. 2 The nodes in the transmission range of a vehicle V . (See Fig. 1) i 3 RSL is exchanged among vehicles by using an extension header in a beacon

message.

Fig. 1. Structure of RSL and NSL in RUFS.

of Vi in Fig. 1, respectively. In the former, the only vehicle that satisfied the content will be selected as Vf . In the latter, the vehicle Vi outranks the potential forwarder Vf that has/is: • recently satisfied the interest Ci , • closer to the provider of content Ci (minimum number of hops), • minimum relevant velocity to ensure maximum connection time, and • higher ISR. In presence of these conflicting criteria with non-homogeneous scales, it is quite challenging to select the appropriate Vf . Therefore, we use the multi-criteria decision making method in [4] to outrank the Vf as follows: Step 1. The vehicle Vi organizes the neighboring vehicles’ information for Ci as:

v1 v2 X= . ..

⎡

p1

a(1,1) ⎢ a(2,1) ⎢ ⎢ .. ⎣ .

vm a(m,1)

p2

p3

p4

a(1,2) a(2,2) .. .

a(1,3) a(2,3) .. .

⎤ a(1,4) a(2,4) ⎥ ⎥ .. ⎥ , . ⎦

a(m,2)

a(m,3)

a(m,4) (2)

where ai,j is a neighboring vehicle i’s criterion pj . Step 2. The scales of pj are different and need to be normalized to a uniform scale as: ai,j ui,j =  , where i = 1..m, j = 1..4, (3) m 2 i=1 ai,j vi,j = wj ∗ ui,j , where i = 1..m, j = 1..4,

(4)

where wj is the preference value assigned to each property pj . For simplicity, wj is equally distributed to all criteria.

1618

IEEE COMMUNICATIONS LETTERS, VOL. 19, NO. 9, SEPTEMBER 2015

Step 3. For each pi , the positive I + and negative I − ideal solutions are: 

I + = v(1,j) , v(2,j), v(3,j) , . . . ., v(m,j) 

(5) = max v(i,j) for ∀ j ∈ n 

I − = v(1,j) , v(2,j), v(3,j) , . . . ., v(m,j)

 = min v(i,j) for ∀ j ∈ n (6) Step 4. For each criterion, every neighboring vehicle’s difference with the most ideal vehicle (Vi+ ) and the worst vehicle (Vi− ) is calculated by using eqs.(5) and (6) respectively:

 2

n  + Vi =  v(i,j) − Ij+ for i = 1..m, (7) j=1

Vi−



 2

n  = v(i,j) − Ij− for i = 1..m.

(8)

j=1

Step 5. Now, the neighboring vehicles in Ei are ranked using eqs.(7) and (8) as: Ei =

Vi−

Vi− + Vi+

where i = 1..m and 0 ≤ Ei ≤ 1 (9)

Finally, Vi selects the Vf that has max(Ei |i ∈ m) and forwards the interest packet for any content only to Vf by adding its ID in the packet header. Other receiving vehicles will discard the interest packet. Later on, Vf will also select the next hop by following the same procedure. Once the interest packet reaches the provider, the data will be sent back via the same route as described in [7]. However, there is a possibility that Vi may find no information for any content Ci in its NSL. In this case, only the relevant speed and ISR will be used to outrank the Vf among the current neighbors by following steps 1–5. Likewise, if any neighboring vehicle recently satisfied only few chunks4 of the required content. That information can also be stored in RSL and updated in NSL respectively (Fig. 1). In this case, if Vi is looking for some specific chunk, we just need to modify Step 1 where the required Ci will be updated with a ChunkID and the remaining Steps will be followed in a similar fashion for outranking the Vf among m neighbors. III. R ESULTS AND D ISCUSSION In order to evaluate our RUFS, the overall VCCN architecture was simulated in the Network Simulator (NS2), where additional attributes were added on top of the IEEE 802.11p. Those attributes include PIT, NSL, interest/data packet structures to support content retrieval. For more realistic data, we obtained the trace files of real time traffic of Carson, Los Angeles, USA using SUMO [5], where 20 to 50 vehicles were moving 4 In CCN, the larger contents are divided into small chunks with sequential ChunkID(s).

Fig. 2. Total Satisfied Interest Packets.

at the average speed of 55 mph. Here, it is worth mentioning that DSRC/WAVE enables a vehicle to achieve a transmission range of 100 to 500 meters, where a vehicle can reach from 10 to a few hundred other vehicles within its single hop distance depending on the network density. Similarly, the experimental results in [6] show that vehicles traveling at an average speed of 60 mph can exchange at least 10 beacons per second, with 3K bits in each message. Therefore, we set the inter-vehicle transmission range (Tr ) as 500 m. Also we believe that the size of RSL does not exceed 3K in 0.1 second, we therefore set the same frequency of RSL exchange i.e., 10 times/sec. Furthermore, we evenly distributed 1000 contents in the CS of each vehicle in such a fashion that initially there is only one provider for any specific content. Also, we assumed no caching policy at relay nodes. During simulations, any vehicle Vi before sending an interest packet, checks its CS and if content is already there, then it generates a different interest. Once it is guaranteed that the generated interest differs from the contents at the CS, then Vi transmits the interest and initializes the content retrieval process. In addition, we also enable all vehicles in the network to generate interest packets for random contents and also there is no fix time slot for generating any interest, thus, ensuring the real time scenario. The performance of RUFS was compared against the recently proposed NAIF [2], Data retrieval Rate (DR) Based forwarding [3] and also the basic interest flooding mechanism defined in CCN [7]. Simulation results were averaged from twenty independent 1000 s long runs. For comparisons, we introduced the following quality metrics: • • • •

FIP: the total number of Forwarded Interest Packets. SIP: the number of overall Satisfied Interest Packets. ISD: average Interest Satisfaction Delay. HCN: average Number of Hops for Content Retrieval.

Fig. 2 depicts the performance comparison in terms of SIP that RUFS achieved against NAIF, DR based forwarding and basic forwarding in CCN. NAIF divides the disk shape transmission area of each node with radius of Tr into four quadrants and selects a farthest node within each quadrant as a forwarder to disseminate interest with less number of forwarding hops. However, the farthest node(s) may have unstable and short-term link. Similarly, DR based scheme selects interest forwarder

AHMED et al.: RUFS: ROBUST FORWARDER SELECTION IN VEHICULAR CONTENT-CENTRIC NETWORKS

Fig. 3. Total Forwarded Interest Packets.

1619

Fig. 5. Average Hop Count for Content Retrieval.

Furthermore, it is also very important to evaluate the number of hops, used for the required content retrieval. In VCCNs, if the interest is satisfied by higher number of hops, we assume that the content provider is located far away resulting in disruptive retrieval. Thus, a less number of hops is desirable. It is evident from the Fig. 5 that RUFS outperforms NAIF, DR based and basic CCN forwarding by satisfying the required content from less number of hops. RUFS achieve this because it selects the most appropriate forwarder which was either a provider itself or close to the provider of the required content. IV. C ONCLUSION Fig. 4. Average Interest Satisfaction Delay.

using the data retrieval rate5 and distance of neighbors to the consumer. This selection fails when we have fast moving neighbors or stale data retrieval rate information. Contrary to these schemes, RUFS selects only a single forwarder among neighbors based on multiple criteria and satisfies almost the identical number of interests as compared to original CCN and six times and twice the number of satisfied interest compared to NAIF and DR based, respectively. Similarly, the main objective of RUFS is to alleviate the interest flooding and the minimum number of interest packets forwarded is the key to success. Fig. 3 shows that RUFS outperforms NAIF, DR based and basic CCN by forwarding 76%, 55% and 83% less number of interests, respectively. In addition, the dynamic mobility of vehicles does not make the inter-vehicle connection last long. Therefore, interest packets should be forwarded with minimum delay. Hence, ISD must also be analyzed in VCCNs. Note that the interest satisfaction delay is mainly caused by the interest broadcast storm that makes forwarding nodes to be bottle-necked and drop interest packets. Thus, Vi should rebroadcast the interest repetitively to retrieve the required content. However, RUFS mitigates this problem through our proactive approach. It allows Vi to select the top ranked vehicle as Vf for the required content before broadcasting any interest. This nature of RUFS alleviates 74%, 66% and 51% ISD against the NAIF, DR based and original CCN as shown in Fig. 4. 5 In case of RUFS, ISR replaces the term “data retrieval rate”.

In this letter, we mitigated the interest flooding problem caused by the epidemic nature of basic CCN in vehicular networks. In RUFS, we outrank only a single vehicle among all available immediate neighbors as a forwarder on the basis of multiple criteria. It allows each vehicle to exchange the list of satisfied interests by itself among neighbors along with its ISR and current speed. This enables each vehicle to maintain a record of interests satisfied by its neighbor(s) and thus able to rank the vehicles before forwarding any interest. Through simulations, we found that RUFS is capable of satisfying a similar number of interests with minimum delay and a least number of interest packets being flooded in the network as compared to basic CCN. Also, RUFS outperforms the recently proposed NAIF and DR Based schemes. R EFERENCES [1] D. Perino and M. Varvello, “A reality check for content centric networking,” in Proc. ACM SIGCOMM Workshop Inf. Centric Netw., 2011, pp. 44–49. [2] Y. Lu et al., “Energy-efficient content retrieval in mobile cloud,” in Proc. 2nd ACM SIGCOMM Workshop Mobile Cloud Comput., 2013, pp. 21–26. [3] Y.-T. Yu, R. B. Dilmaghani, S. Calo, M. Y. Sanadidi, and M. Gerla, “Interest propagation in named data manets,” in Proc. IEEE ICNC, 2013, pp. 1118–1122. [4] D. L. Olson, “Comparison of weights in TOPSIS models,” Math. Comput. Model., vol. 40, no. 7/8, pp. 721–727, Oct. 2004. [5] D. Krajzewicz, J. Erdmann, M. Behrisch, and L. Bieker, “Recent development and applications of SUMO-simulation of urban mobility,” Int. J. Adv. Syst. Meas., vol. 5, no. 3/4, pp. 128–138, 2012. [6] F. Ahmed-Zaid et al., “Vehicle safety communications-applications (VSC-A),” Nat. Highway Traffic Safety Admin. (NHTSA), Washington, DC, USA, Final Rep. DOT HS-811 492A, 2011. [7] M. Amadeo, C. Campolo, A. Molinaro, and G. Ruggeri, “Contentcentric wireless networking: A survey,” Comput. Netw., vol. 72, pp. 1–13, Oct. 2014.