Abstract
In this paper, we propose a novel contribution-aware neighbor-assist video delivery solution over mobile content-centric network (CNVD). CNVD allows the nodes to build and maintain neighbor relationship with other nodes to share cached video resources and achieve unicast-based video lookup. CNVD constructs an estimation model of contribution of neighbor nodes by investigation of lookup delay, number of cached videos, lookup success rate, and geographical distance. CNVD designs the estimation methods of interest level and lookup capacity of nodes for video content, which enables the nodes to decide whether to build neighbor relationship with other nodes. A maintenance method of neighbor relationship between nodes is proposed, which enables the nodes to update valid time of neighbor relationship in terms of contribution of neighbor nodes and decide whether to remove neighbor relationship in terms of the current valid time of neighbor relationship. Further, CNVD designs a contribution-based video lookup algorithm, which reduces lookup delay and improves lookup success rate. Extensive tests show how CNVD achieves much better performance results in comparison with other state-of-the-art solutions.
1. Introduction
The prominent advancement of bandwidth and networking technologies in wireless mobile networks greatly promotes development of mobile Internet applications, such as social, e-commerce, and multimedia [1]. The video streaming services rely on provision of rich visual content and convenience of access using mobile devices to become the most popular applications [2–5] (e.g., the mobile video users in China have been four hundred and forty million in 2016). The video services focus on user quality of experience (QoE) [6]. Rich visual content and convenient access for video services in wireless mobile networks attract large amount of users. The large-scale video access consumes massive network bandwidth and results in strong competition between users for the network bandwidth, which brings severely negative influence for startup delay of users. The dynamic and complex condition of video delivery in wireless heterogeneous networks increases the probability of video data loss, so that the distorted frames reduce user QoE. Obviously, the increase in upload bandwidth supply and video delivery performance is very important for improving user QoE. By the investigation of node mobility to address the problems of dynamic path of data transmission, the P2P/MP2P-based video systems make use of the resources of online video users to increase the efficiency and capacity of bandwidth supply in wireless mobile networks [7–10]. However, the limited resources of bandwidth, computation, storage, and energy of mobile devices result in the limited available resources in overlay networks, which difficultly meets the demand for increasing huge video traffic.
Content-centric networking (CCN), a brand-new framework, focuses content based on newly designed protocol stack instead of host and employs the all-to-cache method to achieve nearby content fetching [11], which reduces delay of content lookup and delivery. Figure 1 illustrates content delivery process in mobile content-centric networks (MCCNs). Each mobile node in MCCNs maintains the data structures: content store (CS), pending interest table (PIT), and forwarding information base (FIB) [12]. The mobile nodes send interest packets to their neighbor nodes in order to obtain the desired video data. If the neighbor nodes have cached the requested video data in CS, the data is directly returned to the request users to the request nodes. Otherwise, if the neighbor nodes do not cache the requested video data locally, the mobile nodes record the incoming interface of interest packets in PIT and broadcast to all neighbors; if the mobile nodes have recorded the information of interest packets, they discard the received interest packets. If the neighbor nodes firstly receive the interest packets, they forward the interest packets to the next-hop nodes; if the mobile nodes receive the same interest packets, they discard the received packets. When the interest packets are forwarded to the content providers which cache the requested video data, the providers return the video data along the reverse searching path. At the moment, the intermediate nodes (relay nodes) in the data reverse path can cache the returned data in order to have nearby access to the data in the future.
The all-to-cache, the traditional caching method in MCCNs, consumes large number of storage resources of nodes to support nearby content fetching in order to offload traffic in underlying network, which leads to huge waste of storage resources. The low capacities of storage, computation, and energy of mobile devices difficultly support the massive consumption. On the other hand, because the nodes are the content carriers, the content movement in geographic area with movement of carriers brings huge negative influence for content caching effectiveness. Moreover, the traditional broadcasting-based content lookup approach in MCCNs also wastes huge network bandwidth. The network congestion caused by large-scale request results in long startup delay. In order to address the problems that existed in traditional methods, some unicast-based content delivery solutions in MCCNs make use of the collected and maintained content information to achieve precise and economic content lookup. However, the nodes need to maintain large number of content carriers in order to fast search content providers. The larger the scale of maintained information is, the higher the probability of fast and successful lookup is. The maintenance of large-scale content information not only brings redundancy link between nodes, but also leads to the overload of mobile nodes due to low capacities. Otherwise, the small-scale maintenance reduces lookup hit rate, which also results in long startup delay. In order to ensure high QoE of users and reduce maintenance cost of nodes, a key issue is how to design the economic and efficient content delivery solutions.
In this paper, we propose a novel contribution-aware neighbor-assist video delivery solution over mobile content-centric networks (CNVD). CNVD allows the mobile nodes to build and maintain neighbor relationship with other mobile nodes to share cached videos and support unicast-based video lookup. In order to achieve economic maintenance for the video content in MCCNs to support efficient lookup and transmission of videos, CNVD designs an estimation method of contribution level of neighbor nodes by investigation for lookup success rate, number of cached videos, forwarding delay of interest packets and video data, and geographical distance of selected neighbor nodes in lookup and transmission paths. A maintenance strategy of neighbor nodes composed of construction and removal of neighbor relationship in terms of contribution levels of neighbor nodes is proposed, which reduces maintenance cost of neighbor nodes. Further, CNVD designs a contribution-based video lookup algorithm, which decreases the delay of lookup and transmission of videos by selection of appropriate next-hop nodes in terms of contribution levels of neighbor nodes. Simulation results show how CNVD achieves much better performance results in comparison with other state-of-the-art solutions.
2. Related Work
The content lookup in MCCNs [12, 13] mainly employs the broadcasting-based method. When the content requesters want to search content, they broadcast interest packets in the whole network. The mobile nodes which receive the interest packets of requesters become the relay nodes in the lookup path of content. If the relay nodes cannot store the requested content, they continue to broadcast the received interest packets to their neighbor nodes. The broadcasting-based method consumes large amount of network bandwidth, which increases risk of network congestion and wastes battery energy of mobile nodes. In order to reduce the cost of content lookup, Rehman et al. proposed a timer-based interest forwarding (REMIF) method [14]. After the relay nodes in the lookup path of content receive the interest packets, they monitor the channel state for a specific time. If the duplicated interest packets are received within the time window, the relay nodes discard the duplicated interest packets in terms of the recorded information in PIT. Otherwise, the relay nodes forward interest packets to other neighbor nodes. However, the time window results in the extra delivery latency, which is unsuitable for video streaming services. Yu et al. proposed a neighborhood-aware interest forwarding method (NAIF) [15], which forwards interest packets according to statistics information of interest forwarding. The relay nodes in the lookup path of content decide to broadcast or drop the received interest packets according to the forwarding rate. By the adaptive adjustment of forwarding rate, NAIF promotes efficiency of interest forwarding and reduces consumption of network bandwidth. However, NAIF does not consider selection of appropriate next-hop neighbor nodes. If the interest packets always are forwarded to the nodes which cache the requested content with high probability in the process of content routing, the interest packets quickly are satisfied, which reduces the content lookup delay. Otherwise, the interest packets still need to experience long-term forwarding, which increases the lookup delay and reduces user QoE. The performance of interest forwarding easily is influenced by the selection of neighbor nodes.
In order to further promote efficiency of interest forwarding, several content lookup methods employ unicast-based interest forwarding. Bian et al. proposed a geo-based forwarding strategy for NDN in VANETs environment [16]. The location position information of data source is added into data name in the process of naming data. By periodical exchange of location information among one-hop neighbor nodes, if the nodes receive interest packets, they select the forwarders with close geographical distance, which reduces delay of interest forwarding. Qian et al. proposed a probability-based adaptive forwarding scheme (PAF) based on the ant colony optimization (ACO) [17]. PAF makes use of the ACO to calculate the probability of next-hop relay nodes according to the performance measurement such as delay. The better the results of performance measurement are, the higher the selection probability of next-hop nodes is. The probability-based selection of next-hop nodes improves the delivery quality and balances the load of interest forwarding among nodes. The centrality-based data dissemination method is proposed in [18]. By investigation for social contact patterns and interests of mobile users to measure the social centrality of nodes, the nodes which receive interest packets makes use of unicast or multicast to forward the interest packets to next-hop nodes in terms of centrality values. The selected next-hop nodes have the high centrality value and have high probability of encountering nodes, which also achieves high performance of lookup and dissemination of data. In fact, the centrality-based method relies on a priori knowledge of centrality values of mobile nodes. The mobile nodes need to continuously calculate and exchange centrality values of other encountered nodes, which consumes large amount of resources of mobile nodes. Ahmed et al. proposed a unicast-based forwarder selection (RUFS) in order to address the problems caused by interest broadcast storm [19]. RUFS requires each vehicle node to share statistic information of satisfied interests with neighbor nodes. All neighbor nodes maintain local neighbors satisfied list (NSL) to store cached content information, which efficiently promotes content lookup performance by selection of optimal interest forwarder. However, the mobile nodes have the low capacities in the resources of energy, computation, storage, and bandwidth; they do not bear high-cost maintenance for large-scale items in NSL. Otherwise, the small-scale maintenance of cached content information increases the risk of content lookup failure. Obviously, the unicast-based methods promote content lookup performance and reduce the consumption of bandwidth in the process of interest forwarding; the key issue is how to balance content-aware cost and lookup performance for the content delivery in MCCNs.
3. Model of Contribution Capacity
3.1. Estimation of Contribution Capacity of Neighbor Nodes
For convenience, some notations which are used in current and following sections are defined in Notations. The maintenance of neighbor nodes supports forwarding messages to destination nodes, so the selection of relay nodes is very important for the forwarding performance. The efficient selection of neighbor nodes in MCCNs not only speeds up convergence process of video lookup, but also promotes lookup hit rate. CNVD requires each node to maintain serval logical neighbor nodes in order to support video lookup (these neighbor nodes are not always one-hop neighbors in geographic area). For instance, makes use of the mapping relationship between cached content and nodes to build and maintain a neighbor node list . When needs to watch video content, it sends an interest packet to an item in . shoulders the responsibility of lookup of requested content. checks local cached videos and searches video information carried by neighbor nodes of . If and ’s neighbor nodes do not have the requested video, selects a neighbor node as next-hop node to forward the interest packet. The neighbor node selection is very important for the video lookup performance. If the nodes cache large amount of videos in local buffer, the request for videos may be responded by them with high probability. If the nodes maintain large amount of neighbor nodes, they are aware of the information of videos cached in neighbor nodes, which increases the probability of successful response for the requested videos. In order to obtain high success rate and performance of content lookup, CNVD constructs an estimation model of contribution capacity of neighbor nodes to estimate the performance of content lookup of neighbor nodes.
The delay-sensitive video services have high requirement for the content delivery performance (lookup and transmission of content). The startup delay of video requesters is an important evaluation parameter for the quality of service (QoS) of video systems. The startup delay includes lookup and transmission delay of video data, which is the time span from sending interest packets to receiving video data of supporting video playback. The requesters always hope that the startup delay meets the requirement of the own QoE. Let denote the upper bound of startup delay of in terms of the requirement of ’s QoE ( is the maximum value of sustainable startup delay of ). is a neighbor node of . When receives video request of and helps search video provider, is defined as the generated startup delay in the process of lookup and transmission of video data. is the real startup delay of . If enables to be less than , considers that successfully helps search the requested video. continues to maintain the logical link between and . Otherwise, if receives the interest packet of and cannot make in [0, ], considers that the lookup task assigned by for is failure. needs to consider whether to remove the logical link between and . considers the logical link between and is valueless for the lookup failure, so that the maintenance of logical link between them wastes valuable resources of bandwidth, computation, and energy of . Therefore, we make use of and to calculate contribution value of a lookup task assigned by for according to the following equation:where is the category of requested video and , which points out the limited range for video lookup. is the contribution value of for the assigned lookup task corresponding to . denotes that current video lookup is successful for ; is the distance ratio between and where . The less the value of is, the higher the contribution value of is. Otherwise, denotes that current video lookup is failure for . The contribution value of is 0. For instance, sends an interest packet to the neighbor node for a video content at the time . When receives the requested data at the time , it calculates the real startup delay by and estimates contribution value of according to (1). In MCCNs, there are the two main influencing factors for the startup delay of video requesters: number of relay nodes in lookup path and delivery capacity of interest packets and video data of these relay nodes. The number of relay nodes determines the forwarding frequency of interest packets and video data. The more the number of relay nodes is, the longer the forwarding delay of interest packets and video data is, which results in long startup delay. The selection of relay nodes (neighbor nodes) is a key factor for reducing startup delay. If the neighbor nodes cache large amount of videos related to the requested videos, the demand of requesters is satisfied with high probability. Otherwise, if the neighbor nodes cache small amount of videos and these cached videos are not related to the requested videos, the interest packets still continue to be forwarded, which increases the lookup delay. On the other hand, because the relay nodes in the paths of lookup and transmission of video data are the logical neighbor nodes with each other, the geographical distance and communication quality between relay nodes are neglected. The long geographical distance between relay nodes may increase the delay of lookup and transmission of video data; the low communication quality between relay nodes (e.g., network congestion) not only results in the increase in delay of lookup and transmission of video data, but also causes the loss of interest packets and video data. In order to investigate the influence of supply and delivery capacity of neighbor nodes for the performance of lookup and delivery of video data, we add the two impact factors and for . and denote the weight values generated by capacity of video supply and delivery of neighbor nodes, respectively.
3.2. Estimation of Video Supply Capacity of Neighbor Nodes
The video supply capacity of neighbor nodes is very important for reducing the length of paths of video lookup and transmission in MCCNs. We firstly investigate lookup success rate (LSR) and number of cached videos (NCVs) to calculate the values of of neighbor nodes. The LSR reflects the resource supply capacity of neighbor nodes for the video requesters. If a neighbor node always meets the demand of requesters for the requested videos, has high video supply capacity to help fast search the requested videos, which reduces the lookup delay. There is a close relation between LSR and NCV. The number of cached videos maintained by includes local videos of and videos cached in neighbor nodes of . The more the number of maintained videos is, the higher the probability of request satisfied in the maintained videos is. The investigation of LSR reflects the video supply capacity of selected neighbor nodes. On the other hand, the NCV of and ’s neighbor nodes is the dynamic variation with the interest for the video content. The low capacity of storage, computation, bandwidth, and energy makes the mobile nodes only cache small amount of videos. In order to watch new videos, the mobile nodes need to remove the old videos and cache the new videos in local buffer with limited size. The investigation of NCV reflects the influence level of variation of video distribution maintained by for the video supply capacity of selected neighbor nodes. Therefore, we make use of LSR and NCV of all relay nodes in lookup paths to estimate supply capacity of selected neighbor nodes. The LSR of any neighbor node of for a video category can be obtained according to the following equation:where is ’s LSR for ’s request of videos in ; and denote successful and total lookup number, respectively. CNVD employs a provider-feedback-based lookup performance estimation method. Because the providers are the terminal point of lookup paths, they can collect the information of relay nodes in paths, such as LSR and number of cached videos. After the neighbor node of requester receives the interest packet, adds number of cached videos corresponding to and LSR of next-hop node selected by into the interest packet. also adds the above information into the interest packet. After the iteration, the provider adds the collected information of relay nodes and the number of cached videos into the returned data. After receives the data, it is aware of the supply capacity of relay nodes and provider. obtains two datasets and . and denote LSR and NCV of relay nodes and provider in the paths of lookup and transmission of video data, respectively. Because the grey relational coefficient (GRC) can measure the relation level of variation process of two curves [20], we make use of the GRC to estimate the relational level between and . The items in and are normalized according to the following equation:where denotes the attribution of estimation parameter such as LSR and NCV; is the value of estimation parameter; and are the upper and lower bound of values of estimation parameter (minimum and maximum values). The relational level between and can be calculated according to the following equation:where is the weight value of ; is the relational value between and , which denotes the relational level of two curves composed of items in and . The higher the is, the more similar the interests of relay nodes for cached videos in the lookup path are. For instance, the LSR and NCV of relay nodes keep the rise/fall trend, which means that the variation process of LSR and NCV meets the condition of rise/fall of LSR with increase/decrease of NCV. The relay nodes also have similar interests for the content related to . If the LSR of relay nodes keeps fall/rise trend with increase/decrease of NCV, the relay nodes do not have the common interests for the content in , which may increase the risk of lookup failure. We use to assign the value of ; namely, .
3.3. Estimation of Video Delivery Capacity of Neighbor Nodes
Except for the supply capacity of neighbor nodes, we also investigate the video delivery capacity of relay nodes in lookup and transmission paths to estimate relational level between geographical distance and forwarding delay between them. The forwarding delay reflects the delivery performance of interest packets and video data in lookup and transmission paths. The geographical distance and communication quality between relay nodes are the main influencing factors for the forwarding delay. The neighbor nodes form a logical lookup path, so the long geographical distance between logical relay nodes enables the interest packets or video data to experience many geographical relay nodes, which increases forwarding delay. Generally, the larger the geographical distance between logical relay nodes is, the longer the forwarding delay of interest packets and video data is [21–23]. Moreover, the low communication quality between relay nodes also increases the forwarding delay of interest packets and video data or causes loss of interest packets and video data, even if the two relay nodes have close geographical distance. The investigation of forwarding delay between logical relay nodes denotes the video delivery capacity of neighbor nodes. On the other hand, the geographical distance reflects the stability of mobility of relay nodes. The mobility makes the geographical distance continuously change, which influences the delay of lookup and transmission of video data. The investigation of geographical distance between logical relay nodes denotes the influence level of node mobility for the video delivery capacity of neighbor nodes. Similarly, all nodes (the requester , logical relay nodes, and the provider ) in the lookup and transmission paths add their timestamp of forwarding interest packets and geographical location into the interest packets. collects the information of timestamp and geographical location of all nodes. Let and denote the set of timestamp and geographical location, respectively, where and denote the abscissa and vertical coordinates of and is the timestamp of forwarding interest packet of . also adds and into the returned data. When receives the requested data from , it calculates the forwarding delay and geographical distance between nodes according to the following equation: where denotes the forwarding delay of interest packets between and ; denotes the geographical distance between and . and are converted to and ; namely, and . makes use of (3) to normalize items in and and further makes use of (4) to calculate relational level between forwarding delay and geographical distance between and . We use to assign the value of ; namely, . calculates and records the contribution of for the lookup of . The forwarding delay and geographical distance between relay nodes keep the same rise/fall trend, which means that the variation process of forwarding delay and geographical distance meets the condition of rise/fall of forwarding delay with increase/decrease of geographical distance. There is the good communication quality between relay nodes. If the forwarding delay between relay nodes keeps fall/rise trend with increase/decrease of geographical distance, there is the bad communication quality between relay nodes such as network congestion, which brings high risk of packet loss and long delay. The requesters should avoid the reusage of current lookup path for the subsequent video lookup.
4. CNVD Detailed Design
4.1. Construction of Neighbor Relationship
The nodes maintain the logical connections with their neighbor nodes in order to fast fetch desired video content. For instance, if the neighbor nodes of a node store large number of video resources, the videos requested by may be cached by the neighbor nodes. Obviously, the nodes tend to preferentially construct the neighbor relationship with the nodes cached large-scale resources. However, if a node caches large amount of video resources and is uninterested in the cached videos of , also does not meet the demand of . Otherwise, if is interested in large amount of videos cached by , preferentially constructs the neighbor relationship with . The large amount of cached videos and the similar interests enable the request of to be met by with high probability. sends an invitation message to where the message includes the information of videos cached in and ’s neighbor nodes; namely, . is a video list and includes the ID of videos corresponding to the video category . Because is aware of the information of videos stored in neighbor nodes by message exchange, the videos stored in neighbor nodes also are considered as the available resources of . If has the high interested degree (interest level) for videos cached in , the video request of is met by with high probability. estimates the interest level for the videos cached in according to the following equation:where is the number of video categories interested by ; is the set of videos uninterested by corresponding to the video category . returns the number of items in the difference set between and . returns the number of interested videos of . denotes that is interested in the videos cached by where is the threshold of interest level of . accepts the invitation of and constructs the neighbor relationship with . Otherwise, if denotes that is uninterested in the videos cached by , rejects the invitation of .
The scale of video resources cached in and ’s neighbor nodes is limited. If ’s interest for the video content is out of range of resources cached in and ’s neighbor nodes (the requested videos are not located in the set of videos cached in and ’s neighbor nodes), still needs to search the requested videos with the help of neighbor nodes. Except for the supply capacity of local resources, the resource lookup capacity of nodes also is an important factor for the construction of neighbor relationship. For instance, and ’s neighbor nodes only cache small amount of videos, but ’s neighbor nodes have strong lookup capacity (high contribution values for lookup tasks assigned by ). also may consider the construction of neighbor relationship with . Even if and ’s neighbor nodes do not provide one-hop and two-hop video access for , they may successfully search the videos requested by and enable the startup delay meet the demand of ’s QoE. also accepts the invitation of and constructs the neighbor relationship with . sends an invitation message to where the message includes the contribution values of all neighbor nodes of ; namely, . is the list of contribution values of neighbor nodes corresponding to the video category . estimates the lookup capacity of for the video category according to the following equation:where is the average contribution value of a neighbor node of corresponding to ; is the number of video lookup tasks assigned by for the requested videos in ; is the number of nodes which accept the lookup tasks assigned by for the videos in . If is interested in multiple video categories, it estimates the video lookup capacity of for multiple video categories according to the following equation: where is the weight value of the video category ; namely, there are different weigh values between video categories; is the number of video categories interested by . Let be the video lookup capacity of by making use of (8), where and are corresponding to the same video categories. If , constructs the neighbor relationship with . CNVD allows the nodes construct the neighbor relationship with other nodes according to the interest level for the cached videos and video lookup capacity with each other.
4.2. Removal of Neighbor Relationship
The nodes which build logical links not only need to consume bandwidth to maintain the state with each other, but also are responsible for the video lookup. If a neighbor node always requests to help search desired videos and does not provide satisfied lookup performance for , the logical link between and is insignificant and redundant for . In order to save the resources of bandwidth, computation, and energy, CNVD allows to remove the redundant logical link with (not all links always are maintained). In order to construct or keep the neighbor relationship with the nodes with strong lookup capacity and large amount of interested videos, the nodes need to store more videos and maintain the links with more nodes. The link removal is the punishment of node selfishness, but the video sharing performance in the whole network is not reduced by link removal.
The contribution of neighbor nodes is the important metric for the maintenance of logical links. The cached videos and maintained links of and neighbor nodes provide video supply service with each other. The contribution values reflect the video supply capacities of neighbor nodes. We define a time to denote valid period of link between and . or removes the link between them when the time span of link is greater than . For instance, if the contribution value of for is 0 ( does not require search videos or all video lookup of is fail), removes the link between and when the valid time of their link is greater than . If successfully searches the video requested by and has a corresponding contribution , the valid time of link between them is defined aswhere is the remaining time of link; is current valid time of link (neighbor relationship). Obviously, the higher the contribution of neighbor nodes is, the longer the valid time of link is. The maintenance method of neighbor relationship based on the valid time of link reduces the consumption of resources of bandwidth, computation, and energy and promotes the video sharing.
4.3. Neighbor Nodes Discovery and Video Lookup
Initially, all nodes do not construct the neighbor relationship with other nodes. The nodes send invitation messages to their one-hop nodes. Because the nodes do not have neighbor nodes, the video lookup capacity of inviters is 0. The one-hop nodes decide whether to accept the invitation by (6). Once the two nodes construct neighbor relationship, they maintain the logical link by periodical exchange of messages containing information of cached videos. If the link is overtime at a node side, the node removes current link.
On the other hand, if a node wants to watch a video , checks the local cached videos because it is aware of videos cached in all neighbor nodes by message exchange. If the requested video is cached in a neighbor node , makes use of the valid link to send the interest packet to . After checks local cached videos, directly returns the video data to . If the requested video is not cached in all neighbor nodes of , requests the help of neighbor nodes to search the requested video data. selects a neighbor node as the next-hop node where has the highest contribution value corresponding to among all neighbor nodes. After receives the interest packet, it check its videos and the videos cached in neighbor nodes. If and ’s neighbor nodes do not have the requested video, also selects a neighbor node as the next-hop node according to the contribution value of all neighbor nodes corresponding to . In order to avoid the loop circuit in the lookup process, the requesters and relay nodes add the information of their neighbor nodes into the interest packet. After iteration of the above process, if the content provider is found, the provider returns the video data to and updates the contribution of . Otherwise, if the interest packet is overtime, broadcasts the interest packet. The pseudocode of the process of video lookup is detailed in Algorithm 1. The number of relay nodes in lookup path and the number of their neighbor nodes determine the complexity of Algorithm 1. Therefore, the complexity of Algorithm 1 is .
| ||||||||||||||||||||||||||||||||||||||||||||||||
After the nodes successfully fetch the requested videos with the help of neighbor nodes (the lookup delay meets the requirement of QoE of requesters), they record the information of providers. If the nodes have sufficient resources of computation, bandwidth, and energy to maintain a new link, they send the invitation messages to the providers along the lookup path. The providers decide whether to accept the invitation according to the capacities of video supply and lookup of inviters. If the providers reject the invitation, the inviters remove the information of providers. The rejection of providers drives the inviters continuously to find more appropriate neighbor nodes.
5. Testing and Test Results Analysis
5.1. Testing Topology and Scenarios
We compare the performance of CNVD with RUFS which is a state-of-the-art unicast-based CCN forwarding strategy [19]. CNVD and RUFS were modeled and implemented in Network Simulator 3 (NS-3). The more the number of mobile nodes is, the more the scale of requested video data is, which brings severe network congestion. In order to reduce the influence of network congestion for the experiment effect, 200 mobile nodes are considered as vehicular nodes and are distributed in a 2000 × 2000 m2 square area which has five horizontal and five vertical streets with two lanes. The bandwidth of mobile nodes is 10 Mb/s. The mobility results in the variation of geographical distance between mobile nodes to influence the delay of lookup and transmission of video data. The random movement behaviors cannot reflect the real movement environment, so the movement behaviors of mobile nodes follow the Manhattan mobility model [24]. In order to simulate the real urban environment, the movement speed varies from 15 m/s to 20 m/s. 33 road side units (RSUs) are evenly deployed in the square area and provide initial video data for mobile nodes. The mobile nodes and RSU equip IEEE 802.11p WAVE network interface to support data transmission. The maximum transmission unit (MTU) of network is set to 1500 B. The size of content store (CS) in each node is 10000 MTU, which is almost equal to 5% of the total size of video content. The signal range of mobile nodes is set to 250 m. The simulation time is 1000 s.
We group 100 video files into 20 video categories where the length of each file is 100 s. Before the simulation, we created 200 playback logs to define playback behaviors of 200 mobile nodes. The 200 mobile nodes watch diverse video content according to the created 200 playback logs where the watched time is random. When the nodes have watched a video, they request new videos according to the playback logs. 200 mobile nodes join the video system following the Poisson distribution. In CNVD, the valid time of link between nodes is set to 20 s. The threshold of interest level of all nodes is set to 0.5 and the number of neighbor nodes maintained by each node is in the range . is set to 0.5. The values of corresponding to all video categories are 0.5. The upper bound of startup delay of all request nodes is set to 5 s.
5.2. Performance Evaluation
The performance of CNVD is compared with RUFS in terms of lookup latency, cache hit ratio, playback freeze frequency, and maintain overhead, respectively.
5.2.1. Lookup Latency
The lookup latency is defined as the time span between the time when the requester sends the interest packet and the time when the provider receives the interest packet.
We use mean values of all lookup latency during every 20 s as the average lookup latency. Figures 2 and 3 show the performance of lookup latency of CNVD and RUFS in terms of the variation in simulation time and number of mobile nodes. As Figure 2 shows, the blue curve corresponding to CNVD first experiences fast increase before = 200 s and decreases to the lowest point (2 s) at = 400 s. The lookup latency of CNVD fluctuates around 3 s and keeps relatively stable after = 600 s. The red curve corresponding to RUFS has a severe fluctuation before = 200 s, slightly increases from = 200 s to = 600 s, and maintains slight fluctuation after = 600 s. Obviously, the lookup latency of CNVD is lower than that of RUFS.
We use mean values of all lookup latency during every 20 nodes as the average lookup latency. Figure 3 shows the variation of lookup latency of two solutions CNVD and RUFS when the number of nodes increases from 20 to 200. The black bars corresponding to CNVD have slight rise from 20 to 140 after fast fall from 140 to 200 where the lookup latency of CNVD is between 2.5 s and 3 s. The red bars corresponding to the RUFS also have increase trend after fast decrease. The range of lookup latency of RUFS is . The lookup latency of RUFS is higher than those of CNVD.
Initially, the small amount of mobile nodes requests and caches video content. The RSUs provide the initial video resources for the request nodes, so that the lookup latency keeps low levels. With increasing number of request nodes, the increase in the scale of requested videos brings huge video traffic, which leads to the network congestion and causes the rise of lookup latency. When the nodes have watched all videos, they quit the system. The decreasing traffic relieves the congestion level and enables the lookup latency fall. In CNVD, the nodes build the neighbor relationship based on the capacity of video supply and lookup and maintain the neighbor relationship in terms of forwarding delay, geographical distance, lookup success rate, and number of cached videos. The neighbor nodes with strong capacity of video supply and delivery reduce the amount of interest forwarding and decrease lookup latency. The link removal mechanism drives the nodes to continuously find more appropriate neighbor nodes with similar interests and strong capacity of video supply and delivery, which promotes the lookup performance of neighbor nodes. Therefore, CNVD can enable the lookup latency to keep low level with slight jitter. In RUFS, the selection of relay nodes relies on the forwarding capacity of neighbor nodes. However, the forwarding capacity of neighbor nodes only investigates the opportunistic encounter with other nodes, which cannot guarantee the validation of content location information. Additionally, RUFS neglects mobility of mobile nodes, which also brings negative influence for video delivery performance; namely, the dynamic network topology caused by node mobility may result in frequent change of paths of packet forwarding, which increases the lookup latency. Although CNVD does not consider the mobility of mobile nodes, the nodes investigate the variation trend of geographical distance and transmission latency in the process of maintenance of neighbor nodes. Therefore, the lookup latency of CNVD is lower than that of RUFS.
5.2.2. Cache Hit Ratio (CHR)
The cache hit ratio is defined aswhere is the total number of interest packets received by nodes; is the number of requests satisfied by videos cached in nodes. The high CHR denotes the video providers can efficiently supply the cached videos to reduce the amount of unsuccessful lookup. Figures 4 and 5 illustrate the results of CHR of CNVD and RUFS in terms of the variation in simulation times and number of mobile nodes, respectively.
We use mean values of all CHR during every 20 s as the average CHR. As Figure 4 shows, the two curves experience similar rise trend from = 0 s to = 200 s. The blue curve corresponding to CNVD keeps rise from = 200 s to = 400 s, reaches the peak 0.36 at = 460 s, and has a fall with slight fluctuation from = 400 s to = 1000 s. The red curve corresponding to RUFS has the decrease trend with slight fluctuation from = 100 s to = 1000 s. The blue curve of CNVD is higher than that of RUFS.
We use mean values of all CHR during every 20 nodes as the average CHR. As Figure 5 shows, the black bars corresponding to CNVD have a fast rise trend with increasing number of mobile nodes where the increase rate is gradual from 100 to 200. The red bars corresponding to RUFS also show the rise trend, but the CHR results of RUFS always keep continuous jitter. The CHR of CNVD is almost 20% higher than that of RUFS.
Initially, the small number of mobile nodes joins the system and requests video content. The sent interest packets also are less. The RSUs provide the initial video data, so that the CHR values keep fast rise. The video content is fast disseminated to the whole network with the help of content caching. With the increase in the number of request members, the number of requested videos also fast increases. When the request nodes need to fetch videos from the network instead of RSUs, the CHR values decrease due to the unbalanced distribution of content. In CNVD, the nodes build the neighbor relationship based on the capacity of video supply and lookup. The similar interests between neighbor nodes ensure the neighbor nodes cache and request the similar videos. The neighbor nodes with large amount of cached videos can support the video request falling in the content cached in neighbor nodes with high probability. The investigation of lookup success rate and number of cached videos in the process of maintenance of neighbor nodes drives the nodes continuously to find more appropriate neighbor nodes with higher lookup success rate and larger number of cached videos, which further promotes the sharing performance between neighbor nodes and increases the CHR values. Therefore, CNVD can obtain high CHR. RUFS only collects the content location information by opportunistic encounter with other nodes and does not ensure the mobile nodes always obtain the location information of requested content. Additionally, the node mobility also leads to fast invalidation of collected information. Therefore, the CHR of RUFS fast decreases and keeps low levels after = 100 s.
5.2.3. Playback Freeze Frequency
The times of occurrence of playback freeze per second are used to denote the playback freeze frequency during the whole simulation time.
We use mean values of all playback freeze frequency during every 20 s as the average playback freeze frequency. Figure 6 shows the variation of playback freeze frequency of the two solutions with increasing simulation time. The curves of CNVD and RUFS experience fast rise with slight jitter from = 0 s to = 1000 s. The increment of RUFS’s results is higher than that of CNVD.
In RUFS, the nodes collect the location information of video content by making use of opportunistic message exchange. The node mobility speeds up the invalidation of collected information. Moreover, the nodes only collect information of cached content of adjacent nodes, so that the small-scale collection of content information increases the risk of lookup fail. Therefore, the playback freeze frequency of RUFS keeps fast rise during the whole simulation; namely, the QoE of nodes is relatively low. In CNVD, the nodes which build the neighbor relationship have strong capacity of video supply and lookup. Moreover, the nodes remove the logical link with neighbor nodes in terms of the contribution by the investigation for capacity of video supply and delivery of neighbor nodes, which promotes the sharing performance such as high lookup success rate and low lookup delay. Therefore, the playback freeze frequency of CNVD keeps low increment; namely, the nodes in CNVD can obtain high QoE.
5.2.4. Maintenance Overhead
The average bandwidth used to maintain node state and exchange content information every second is defined as the maintenance overhead.
Figure 7 shows the variation of maintenance overhead of the two solutions with the increase in the number of mobile nodes. The black and red bars of CNVD and RUFS keep fast rise trend with the growth of system scale. The black bars corresponding to CNVD keep lower increment than those of RUFS, even if the maintenance overhead of CNVD is higher than that of RUFS from 100 to 120.
In RUFS, the nodes maintain the information of recently satisfied interests of one-hop neighbor nodes. In order to ensure validity of exchanged information, there is the high-frequency exchange of messages between nodes. Therefore, RUFS has high maintenance overhead. In CNVD, the upper bound of number of neighbor nodes is 10. The small number of neighbor nodes does not bring high maintenance cost. Moreover, in order to further reduce the maintenance cost, the nodes remove the link with neighbor nodes in terms of the contribution. Because the nodes which keep long-term neighbor relationship have high lookup performance, the limited number of neighbor nodes does not bring more negative influence for the content lookup. Therefore, the maintenance overhead of CNVD is lower than that of RUFS.
6. Conclusion
In this paper, we propose a novel contribution-aware neighbor-assist video delivery solution over mobile content-centric network (CNVD). CNVD constructs the estimation model of contribution of neighbor nodes by investigation of lookup success rate, number of cached videos, forwarding delay, and geographical distance. In order to ensure the neighbor nodes have high capacity of video supply and lookup, before construction of neighbor relationship, the nodes estimate interest levels for cached content, measure the lookup performance, and further decide whether to build the neighbor relationship. In order to stimulate nodes to improve utilization rate of cached content and find more appropriate neighbor nodes with strong capacity of video supply and lookup, CNVD designs a removal method of neighbor relationship. The nodes which keep long-term neighbor relationship have strong capacity of video supply and lookup, which promotes video sharing performance and ensures QoE of the request nodes. CNVD designs a contribution-based video lookup algorithm, which achieves fast video lookup. The simulation results show how CNVD has lower lookup latency, high cache hit ratio, lower playback freeze frequency, and lower maintenance overhead than RUFS.
Notations
| : | Mobile node |
| : | Video category |
| : | Contribution of for video lookup of in |
| : | The real startup delay of |
| : | The lower bound of startup delay of ’s QoE requirement |
| : | Weight value of video supply capacity of |
| : | Weight value of video delivery capacity of |
| : | ’s lookup success rate for video request of |
| : | Number of videos cached by neighbor node of |
| : | Forwarding delay of interest packets or video data between and |
| : | Geographical distance between and |
| : | Video list including ID of videos in |
| : | A set of uninterested videos of for videos in |
| : | Threshold of interested degree of for video content |
| : | Set of contribution values of neighbor nodes of for videos in |
| : | Weight value of |
| : | Estimation value of lookup capacity of for request of videos in |
| : | Valid time of neighbor relationship between and . |
Competing Interests
The authors declare that there is no conflict of interests regarding the publication of this paper.
Acknowledgments
This work was supported in part by the National Natural Science Foundation of China (NSFC) under Grant nos. 61402303 and 61501216 and the Project of Beijing Municipal Commission of Education under Grant KM201510028016 and the Science and Technology Plan Projects (Openness and Cooperation) of Henan Province (152106000048).