A Pre-Caching Strategy Based on the Content Relevance of Smart Device’s Request in Information-Centric IoT

In recent years, investigations on various forms of solution for Internet of Things (IoT) paradigm opens the new era of smart devices. The Information-Centric Internet of Things (IC-IoT) can apply the characteristics of content caching which is a typical feature of Information-Centric Networking. Therefore, designing an efficient caching strategy for IC-IoT is able to improve the efficiency of smart devices. In this paper, we propose a Pre-Caching Strategy based on the Relevance of smart device request Content, namely PCSRC. After the first request of content chunk at a smart device side, PCSRC pre-caches the rest of the content chunks. There are two types of cached content chunks, that is, actual requested content chunks and pre-caching content chunks. Actual requested content chunks are pushed forward hop-by-hop according to the trend of the local activity. The popular content will be gradually pushed to the edge of IC-IoT. Furthermore, a sojourn time of a cached content chunk is employed to save storage space. The simulation results show PCSRC can reach 42.7% on the cache hit ratio with the different storage sizes. For the average hop count, PCSRC can increase about 42.2% than that of ProbCache. And PCSRC can improve about 47.9% than that of CEE for the average hop count.


I. INTRODUCTION
With the rapid development of the Internet of Things (IoT), this paradigm opens a new era of smart devices and has become a comprehensive application of a new generation for information technology [1], [2]. On traditional networks, researchers have studied different research directions of the IoT, such as routing [3], buffering [4], privacy [5], computing offloading [6], perception and fusion [7], [8], identification [9], and optimization [10], etc., to improve the overall performance of the IoT. However, in the traditional network, it has a huge challenge due to the fundamental problems of the network architecture, for example, decoupling location and information and the node cannot caching content in-network [11]- [13]. Therefore, Information-Centric Networking (ICN) is proposed as one of the popular network architecture for The associate editor coordinating the review of this manuscript and approving it for publication was Nan Cheng. future Internet [14]. As the most promising future network architecture, ICN decouples information content from location, users can request through content names, and ICN also offers clear benefit that the network performance is improved by increasing the effect of the caching in-network [4], [15]. Information-Centric Internet of Things (IC-IoT) can apply the ICN's the characteristics of content caching to the IoT, which can reduce the energy loss and improve the performance of the network.
Due to the characteristics of IC-IoT caching content in-network, traditional caching algorithms for Web, CDN and P2P cannot be directly applied. In recent years, many researchers have studied and explored the cache in ICN and obtained many research achievements. However, there are still some issues with improving network performance by caching content. Currently, those issues can be attributed to the following two aspects, namely, selecting which content to cache or selecting which nodes to place the content. VOLUME 8, 2020 This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/ The classic design of caching strategy for ICN is Cache Everything Everywhere (CEE) [16]. However, because of blind cached contents, some cached contents tend to be homogeneous. When a user requests a content, most of the requests are still forwarded to the content server, which increases the request delay and wastes storage. In order to improve the efficiency of the caching system, the researchers have launched a series of works [17]- [19]. Zhang et al. [18] have taken the popularity of contents as a basis for content caching. However, the connection between content requests is not considered. Taking the content chunk as a starting point, a collaborative caching algorithm is proposed to reduce the request delay [19]. When a content is divided into chunks, the user will request subsequent content chunks after requesting a certain content chunk. The above work has verified that introducing the relevance of the requested content into the caching system will greatly help improve the performance of the network. Therefore, in IC-IoT, it is important to study a pre-caching strategy based on the content relevance of smart device requests to improve the performance of the network. Nevertheless, there are few studies on the combination of the content popularity and the relevance to content requests. In response to these deficiencies, PCSRC is proposed based on the relevance of smart device's requests. IC-IoT uses the characteristics of ICN, where the request and return of the content follows the same path. In IC-IoT, when a smart device initiates a request for a content chunk, PCSRC caches the subsequent content chunks that follow the content chunk of smart device's request and the smart device is the user. Therefore, there are two types of content in the network, which are the actual request content and the pre-caching content, respectively. In PCSRC, we set the router ID list field in an interest packet to obtain the request path. Then the pre-caching content is cached by the router's ID list of the interest packet. In order to fully exploit the cache space, we cache the content in the second half of the path. With the increase of the popularity of request contents, the popular contents are advanced to edge nodes. Furthermore, in order to save storage space, we employ the sojourn time for cached content.
The main contributions in this paper are as follows: (1) We introduce a pre-caching strategy which can precache the subsequent content chunks of a requested content. In PCSRC, cached content chunk will be pushed to the edge of IC-IoT hop-by-hop based on its local activity. Moreover, we employ sojourn time of content chunks to reduce the consumption of spaces. (2) We perform extensive evaluations to validate PCSRC in comparison to CEE and ProbCache [17], respectively. The simulation results show that PCSRC effectively reduces the number of hops and access delays. In addition, PCSRC achieves relatively high hit rate than other two strategies. The rest of this paper is organized as follows. In Section II, we give related works. In Section III, we propose a pre-caching strategy based on the relevance of requested content. In Section IV, we evaluate the proposed caching strategy. In Section V, we conclude this paper.

II. RELATED WORK
In IC-IoT, the ability of traditional network nodes for forwarding and routing to give the node cache of the ICN network. On the basis of traditional web caching [20] and proxy caching [21], an increasing number of cache strategies have been proposed in ICN to improve the efficiency of caching and the performance of the network.
ICN usually uses the CEE-based scheme to decide cache locations [16]. This scheme does not make any choice to cache location and content, so as to cache a lot of useless content, resulting in redundant content storage and difficulty to exert the purpose of cache adequately. Laoutaris et al. [20] proposed a cache scheme Leave Copy Down (LCD) to improve the utilization of cache space. When a request hits a cached content, it is cashed only at the next direct hop of the hit node to reduce the redundancy of the cached content. A scheme of Move Copy Down (MCD) is also proposed in [20]. Unlike LCD, when a cache hits, the content of the current node is deleted in addition to the content cached to the downstream node. The above methods are to reduce the redundancy of content by limiting the number of copies of the same content along the path. However, as networks become more and more complicated, the performance of LCD and MCD may significantly reduce. A cache mechanism based on probability is proposed in [17]. This cooperative network caching is based on the path lengths called ProbCache that approximates the capability of paths to implement the content caching. The caching strategy ProbCache can effectively reduce redundant data. Chai et al. [22] proposed a selective cache mechanism based on betweenness. They calculate the betweenness of nodes along the path, and then select the node with the largest betweenness as the content cache node to reduce the number of replacements and content redundancy. However, this scheme will result in frequent replacement of the cache on a few important nodes.
In the aspect of decisions with cache content, Wang et al. [23] proposed an alternative algorithm called LB (Least Benefit) that considers both content access frequency and cache distance benefit. In particular, the current gain is counted into the total gain for each cache hit. This algorithm considers the single cache gain and access frequency at the same time. Meanwhile, additional overhead is added due to the need to maintain the gain information. In [24], the optimal content distribution and storage capacity are considered based on the integer linear programming formulation. Mangili et al. [25] proposed a centralized strategy to combine storage available on wireless access points with lease the unused bandwidth. A cooperative caching strategy based on popularity rank of content is proposed in [26]. According to the number of requests, the number of cached data is gradually increased in a way of exponential growth. However, the scheme does not take into account the relevant requests of subsequent users, but only satisfied with the differentiated cache on spatial cache locations.
In the decision of cache location and cache content, Ming et al. [27] proposed an ideological strategy based on the lifecycle of the content. The content could be replaced only when the lifecycle times out. The lifetime of a content is determined by its storage location and popularity. That is, the closer a content is to the edge of the network, the higher its popularity is, and the longer it lifecycle is. The content package carries the lifecycle field which is adjusted by the router along the path to determine the lifecycle of the content. However, this scheme assumes that the popularity of content is known as a static parameter, which may not reflect the dynamic evolution characteristics of the content request and the parameter is difficult to pre-know. Ren et al. [28] proposed a cache strategy for maximum revenue. The strategy determines the specific cache location by calculating the revenue of the cached content on the request path. On the basis of this, Wu et al. [29] proposed a probability caching strategy based on maximizing cache revenue. Considering the popularity of the content and the cache placement revenue, it calculates the probability of the cached content on the node. Content with high probability and cache revenue will have a higher probability of being cached at the node to improve overall performance of the cache.
Most of the above schemes do not consider the correlation between the requests of user for the same content after the content is partitioned into chunks. In addition, the distribution function of popularity is predetermined in the design of the caching algorithm, which may not reflect the dynamic variability and the correlation characteristics of the request distribution. In order to solve the above limitations, we propose a pre-caching mechanism PCSRC, where each node cooperates with others to pre-cache the content which may be requested later to aovid congestion [30]. According to the local activity of the content chunk, it promotes the marginalization of the popular content.

III. A PRE-CACHING STRATEGY BASED ON THE RELEVANCE OF REQUESTED CONTENT
Our network model is defined as an undirected graph G(V, E), where V={v 1 , v 2 , . . . , v w } is a collection of router nodes. The subscript w denotes the number of network nodes.
| · | is the size of a content chunk.In this paper, the name of a content chunk is made up of the content name and the relative position of the content chunk. The name of a content chunk is the only credential which is used to distinguish from other chunks. Assume that there is enough available bandwidth to support forwarding content packets. The appropriate number of chunks for a content and the scalability of partitioning a content are not within the scope of this paper.

A. THE LOCAL ACTIVITY OF THE CONTENT CHUNK
In order to reflect the dynamic and limitation of content requests, the sliding window mechanism is adopted. This mechanism is dynamically calculated and updated the local activity of a content chunk, which considers both the hot degree of historical requests and the novelty of current requests.

Definition (Local Activity of a Content Chunk (LACC)):
We use t x+1 to denote the time which is the (x + 1)-th request for a content O k,i . The number of requests in the sliding window at the moment t x+1 is called the local activity of a content chunk, i.e., where parameter K is the size of the sliding window and the time window As shown in Figure 1, the dynamic update of LACC is driven by requests. The activity of a content is updated only when the current request arrives. Formula (2) does not take the novelty of content chunks into account. In other words, the frequency of request has different impacts on LACC in different time slot of sliding window. Therefore, we introduce the weight parameters γ , and then have where γ > 1. We infer from the formula (3) that the previous slot in the sliding window is less important to the LACC, while the newer slot has significant effects on LACC. This weight parameter reduces the impact of history requests to LACC. It not only ensures the content's history request information has impact on the current information but also meets VOLUME 8, 2020 the novelty of the content request, which reflects the current result of LACC more accurately.

B. IC-IoT PACKET STRUCTURE
In order to distinguish initiated packets by user from pre-cache packets, we refer to them as interest packets, precache interest packets, data packets and pre-cache data packets, respectively. The specific format of packet is shown in Figure 2. Pre-cache interest packets and pre-cache data packets are used to support operations of pre-caching. The subsequent content chunks are encapsulated in pre-cache data packets. For example, a user requests the content O k,i , afterwards the router nodes will cache the content chunks O k,i+1 . . . O k,n k . When a content chunk is first request, implies that the content chunk must be transferred from the the Content Source Server (CSS) to the user on request. However, the content chunk is close to the user with increasing request.The hop count and interest packet generation are reduced. So the network overhead is will also reduce. In order to distinguish pre-cache content chunks and request content chunks, we add the Packet Type field in the packet. The field can effectively control the invalid forwarding of the cache packet to reduce the work process of subsequent routers.
If there are no new interest packets arriving to a node, the node will delete the corresponding entry from it PIT quickly, so the pre-cache effect is not achieved. Therefore, we introduce synthetic interest generator [31] to generate precache interest packets. If a pre-cached content chunk has been placed on the path l io = (e i,i+1 , e i+1,i+2 , . . . ), the CSS will not receive the interest packet, and each router in the path will not repeatedly cache the pre-cache data packet. l io represents the path from edge router v i to CSS.
There are two problems when implementing above ideas: (1) how to perceive a path of interest packets passing in order that data packets or pre-cache data packets are cached on the path l io ; (2) the pre-cached or cached content chunks will occupy the storage space of CS. Hence how to reasonably set a sojourn time for content chunks in CS is a problem.

Algorithm 1 A Node Processes Data Stream Algorith
1: The node receive data packet; 2: if the item is not in the PIT then 3: if the packet type is data packet then 4: if CNI == 0 then 5: Calculate the sojourn time based on LACC; 6: Set the sojourn time in CS; 7: Set CNI = −1; 8: Forword the data packet; 9: else 10: if the value of CNI match the ID of itself then 11: Set the T basic ; 12: Forward the data packet; 13: else 14: Forward the data packet; 15: end if 16: end if 17: else 18: if the CNI match the ID of router then 19: Set the T tem ; 20: else 21: Forward the Pre-Cache data packet; 22: end if 23: end if 24: else 25: Drop the(Pre-Cache) data packet; 26:

end if
To solve the first problem, we add a Router ID List (RIL) field to interest packet. The RIL field represents a collection of ID of routers. Each router adds its ID into RIL when it forwards the interest packet toward the upstream node. In addition, we add a Cache Node Identifier (CNI) to the selector field. CNI was used to identify where a content chunk will be cached. The CNI field has two roles: (1) CS will cache (precache) the content to the corresponding router node, where CNI corresponds to the router ID on the path l io . We further illuminate the pre-cached strategy by using the Eq.(4) and Eq.(5). (2) the field is set to 0 or −1 by capturing the change of popularity when users request a content chunk. When the next hop node receives a packet, the volue of this field will be checked. If the value of CNI field is 0, the router will cache the content chunk. If the value of CNI field is −1, the node will forward the content chunk. In order to solve the second problem, we add the LACC field. LACC represents the local activity of the content chunk. It was used in the calculation of sojourn time and the downward movement of storage location.
The process that a node deals with a data stream is shown in Figure 3. When a router node v i receives a data packet and a pre-cache data packet about content chunks O k,i . . . O k,n k , it first checks its PIT. If there is no entry in the PIT, the node v i will discard the packet about content chunks O k,i . . . O k,n k . Otherwise, it first checks the value of the Packet Type field.  If the packet is a data packet and the value of the CNI field is 0, node v i will cache the content chunk and set its sojourn time based on LACC. If the value of CNI matches with the ID of node v i , v i will cache the content chunks O k,i . . . O k,n k , set the sojourn time T basic and forward the data packet. If the value of CNI does not match with the ID of node v i , it will forward the packet directly. If the packet is a pre-cache data packet and the ID of node v i matches with the value of CNI, it will cache the chunk and set its sojourn time T tem . Otherwise, it forwards the content chunk only. The algorithm is shown in Algorithm 1.
The process that a node deals with an interest packet is shown in Figure 4, where we assume that there is enough available bandwidth to support forwarding content packets. Packets generated in label 1 are interest packets, generated in label 2 are pre-cache interest packets. First, when a node receives an interest packet, it responds to the interest packet directly if the content exists in its CS, where the node will calculate A O k,i (t x+1 ) to decide the value of CNI. Second, if the content does not exist in its CS, the node will check whether there is a request record in its PIT. If the request record exists in PIT already, the request port will be added to the corresponding entry of its PIT. Otherwise, if there is a corresponding entry in its FIB, it will add the record of forwarding to its PIT, sent the synthetic interest of subsequent content chunks, and forward the content chunk to the next hop. If there is a corresponding entry in its FIB, the interest packet will be discarded directly. The process is shown in Algorithm 2.

C. A COOPERATIVE PRE-CACHING ALGORITHM
If a user wants to get complete information, a request for different chunks of the same content will be continuously issued after the content is divided into many content chunks. After a specific user requests a certain content O k,i , if the i-th chunk of the content O k,i was also pre-cached on the path l io , it will inevitably reduce the response time that the user requests the remaining content chunks and improve the possibility that the user obtains the required content chunk nearby. If a user sends an interest packet, the CSS will send subsequent content chunks to the user. When the router node receives a data packet or a pre-cache data packet, it will cache or precache the content chunk according to the RIL in the interest packet.   12: if the request exists in the PIT then 13: Add the request port; Drop the interest packet; 14: else 15: Search the FIB; Get the forwarding port and add entry in the PIT; 16: Forward the Pre-Cache interest packet; 17: end if 18: end if

1) THE STORAGE DECISIONS OF PRE-CACHING
CSS sends subsequent chunks of the content about user requests to the designated router node according to interest packets. We assume that the request content O k contains n k chunks, the current content chunk requested by a user is Q k,m , and the number of hops from the user to the CSS is h. Hence, the number of the subsequent content chunks of requested content is n k − m. For each router, the number of cached contents is f for the path l io , i.e., In order to make full use of edge nodes, the pre-cached content is placed in the half path of l io . The corresponding relationship between the storage of content and the node is designed as follows, where q represents the subscript of a router, that is, the content chunk O k,j is send to the node v q for caching; j represents the j-th content chunk of the content O k whose initial value is the subscript of the requested content chunk (j ≥ m). For example, a user requests a content chunk O k,m , and the initial value of j is set to m. The caching algorithm of PCSRC is shown in Algorithm 3.

2) THE PUSHING OF THE CACHE CONTENT
In PCSRC, the popular content chunks are pushed into the edge of the network based on the LACC. When a cached node receives an interest packet req Q k,i , it computes LACC of the content chunk Q k,i .
, it represents the popularity of content increases. The node v i sets the value of CNI in Algorithm 3 Pre-Caching Algorithm 1: get the path that the interest has been through l io , where v 1 is the closest to the consumer; 2: Interest req Q k,m for chunk Q k,m from users; 3: f ← 2(n k − m + 1)/h ; 4: j = m; 5: while j ≤ n k do 6: q ← h/2 + (j − k + 1)/f ; 7: send O k,j to v q ; 8: j++; 9: end while corresponding packet of req Q k,i to 0. When a downstream node v i−1 receives the packet, it will check CNI. If the value of CNI is 0, it represents that the content needs to be cached.
Then v i−1 will calculate the sojourn time based on LACC to move the content to the next-hop. Since v i−1 cached the content, v i will not receive the packet of content Q k,i . When the sojourn time expires, the content will be in the ''deletable'' state. Otherwise, v i−1 will set the CNI field to −1 after v i−1 caches the content, which prevents downstream nodes to store the content again. ( , it represents the popularity of content decreases. The node v i will adjusted the sojourn time of content chunks according to LACC, and then respond to downstream nodes by sending the packet to them. When downstream nodes receive the packet, they will check CNI to decide whether the content chunk needs to be cached. Because the value of CNI is −1, the node only needs to forward the content chunk. (3) When the node receives the pre-cache interest packet, it shows that the packet is a request of the content chunk generated by user association. CSS sends the pre-cache data packet of the remaining content chunk. After the router corresponding to the CNI receives the pre-cache packet, this node will extract the pre-cached content chunks and set the temporary sojourn time. The content will be stored in CS in order to facilitate the requests of subsequent content chunks of user.

3) THE CALCULATION OF SOJOURN TIME
According to the type of packet, we have to set the stay time in separate situations. For data packets requested by the user, we dynamically change the sojourn time according to the sliding window. For pre-cached content chunks, we set a temporary sojourn time to prevent the pre-cached content from taking up longer storage space.

a: THE SOJOURN TIME OF THE REQUEST CONTENT CHUNK
The value of sojourn time is dynamically calculated according to LACC. The larger the value of LACC is, the longer the sojourn time is. It aims to increase the sojourn time and the subsequent utilization of popular content chunks.
, the value of CNI field is set to 0, which indicates that the downstream node needs to cache the content chunk and calculate the sojourn time.
If a user requests a content chunk for the first time (LACC = 1), there is no any intermediate node with the cached content chunk. Hence the request is sent to CSS, and then CSS caches the content chunk according to the decision of the content chunk's storage. The sojourn time is set to the basic sojourn time T basic . After that, if a user requests this content chunk again, its sojourn time is updated dynamically according to LACC, i.e., where ST denotes the sojourn time. From the formula (6), the value of the sojourn time increases with the increasing of the value of LACC. It means that the greater the popularity is, the longer the sojourn time is.

b: THE PRE-CACHED SOJOURN TIME
Considering that a user may send a request for different content chunks of the same content within a short time, we propose a pre-caching strategy for content chunks to reduce the delay of requesting subsequent content chunks. We set PST = T tem for pre-cached content chunks to prevent them from taking up longer storage space of CS. The value of PST of a pre-cached content chunk is set by the average sending time slot of content requests, which has no relationship with the actual number of requests or the activity of content. That is to say, the value of PST of a pre-cached content chunk is set according to the interval of sequential requests. When a user requests sequential contents, PST updates dynamically according to LACC. If the pre-cached content is requested firstly, LACC is set to 1. According to the policy of storage time, PST (1) = T basic .

4) CACHE REPLACEMENT POLICY
When the storage space of a node is full, it needs to delete some cached content chunk to cache the latest content. For a pre-cache content chunk, if it is not requested by users for a period of time, it quickly becomes a deletable state. When a new content arrives, the content chunk in deletable state will be replaced first. If there is no any content chunk in deletable state, the new content will replace the content chunk with the minimum ST in the CS. Figure 5 shows a specific operation instance of PCSRC algorithm. Assume that CSS contains content chunks O k,1 ∼ O k, 5 . R 1 ∼ R 3 represent users. req O k,i represents the request that a user sends a request for content O k,i .

5) AN EXAMPLES FOR PCSRC
(1) A user sends an interest packet req O k,1 for the content chunk O k,1 . Since the content chunk is requested for the first time, it is not cached in the path. Hence, req O k,1 is sent to CSS and records the router ID along the path. When the CSS receives req O k,1 , it extracts the RIL which contains the ID of the node v 1 , v 2 , v 3 , v 4 . After that, the CSS will prepare for pre-caching. If we suppose a router can cache 3 content chunks at most, Q 1,1 ∼ Q 1,3 are cached in the node v 3 and Q 1,4 ∼ Q 1,5 are cached in the node v 4 . The node corresponding to this caching strategy will be gained by formula (4) (5). This strategy can uniformly cache O k,1 ∼ O k,5 on the second half of the path. When the node v 1 ∼ v 4 receives the data packet, it will check the CNI. If CNI matches oneself, the node will cache the content chunk. Hence, v 3 caches Q 1,1 ∼ Q 1,3 . v 4 caches Q 1,4 ∼ Q 1,5 . In addition, the node decides whether to forward the content to the next node depending on the Packet Type field. When the node v 3 receives the data packet with O k,1 , it will check the Packet Type field and the LACC to decide whether to forward and set the sojourn time. After that it sets the CNI field to −1, and forwards the data packet. When the node v 2 and v 1 receive the data packet, they will directly forward the packet if the CNI field is −1. This process is shown in Figure 5 (1).
(2) User R 2 sends interest packets 3 . When node v 1 receives an interest packet, it forwards the interest packet to the upstream node v 2 since it does not cache the content chunks 3 (1), v 3 sets CNI of the data packet to 0 to respond to the request. When node v 2 receives the data packet, it will check the CNI, calculate the ST , store the content in the CS, set CNI to −1, and forward the data packet. After a period of time, since the node v 3 has not received the request, the content chunks O k,1 ∼ O k,3 will be in deletable state. This process is shown in Figure 5 (2).
(3) In case of (2), suppose that the activity of O k,3 decreases in this request, namely A O k,3 (2) < A O k,3 (1). When the content chunks O k,1 and O k,2 in v 3 is expired, the data packet of O k,3 is not cached in the next hop. Moreover, the CNI of the packet of O k,3 is set to −1, and the ST of the packet is calculated based on the LACC. This process is shown in Figure 5 (3).

IV. PERFORMANCE EVALUATION A. SIMULATION ENVIRONMENT AND PARAMETER SET
We use the ndnSIM platform to verify the performance of our PCSRC with CEE [16] and ProbCache [17]. The experimental network has 31 routing nodes which contain 10000 contents as shown in Figure 6. Each content is divided into 10 chunks and each chunk is 10 Mbytes. The content request can come from leaf nodes only. The cache capacity of each node is 1000Mbytes. We suppose that the probability of requests obeys probability of Zip [32] and the arrival requests obey the parameters λ of Poisson process, where α = 0.8. We set the simulation time, transmission interval, and T basic to 100s, 100ms, and 10s [27], respectively. The sojourn time of temporary caching content chunks is set to two times of the VOLUME 8, 2020  content transmission interval. The sliding window is set to 3s and the chunks are multiplied by the first content chunk. We first introduce some performance parameters as follows.

1) CACHE HIT RATIO
Cache Hit Ratio (CHR) is the ratio of the response number of requests and the total number of requests in specific time. The calculation formula is defined as where resp represents the response number for the cached node, count represents the number of requests received by nodes. The value of CHR reflects the advantage of a caching scheme. The higher the CHR is, the greater the validity of a caching scheme is, and the less redundancy of content is.

2) AVERAGE REQUEST HOP
Average Request Hop (ARH) refers to the average number of routes transmitted when an interest packet hits the request content. The formula is defined as where g rep denotes the number of hops that an interest packet is responded, Fre represents the number of response that an interest packet is responded, REP denotes the set of user's request. The lower the value of ARH is, the less the hops of response are. This value reflects the impact of the cache mechanism on the bandwidth.

3) SERVER TRAFFIC RATIO
Server Traffic Ratio (STR) denotes the traffic ratio of the requests responded by CSS and the total requests, which is defined as where W rep shows the traffic which is generated by the request responded by CSS, Q rep represents the total traffic in the network. The higher the value of STR is, the lower the probability of requests responded in the cache path is. The higher the value of STR is, the bigger the value of hop of obtaining a content is, and the greater the overload is.

4) AVERAGE REQUEST DELAY
Average Request Delay (ARD) represents the average delay from sending interest packets to receiving response data packets.
B. SIMULATION RESULT 1) CACHE HIT RATIO Figure 7 shows the CHR of PCSRC under the weight parameter γ = {1, 5, 8, 20}. From Figure 7, the CHR is the highest with γ = 5, while it reaches to the rock-bottom with γ = 20. However, when γ = 1 or γ = 8, the CHR is relatively reduced. When the weight parameter γ is 20, it has the lowest CHR. When the weight parameter γ are set as 1, 5, 8 and 20, the corresponding average CHRs are 38%, 43%, 40% and 34%, respectively. This situation is mainly due to the influence of the value of γ . The value of γ not only takes account of the request in the history request window, but also takes account of the impact of the request in the current window. So PCSRC has higher cache hit rate. Of course, a reasonable parameter value has a great influence on improving the CHR.  Figure 8 shows the CHR of PCSRC in comparison with CEE and ProbCache, where the cache space of each router is set to 5%, 10%, 15% and 20%, respectively. From Figure 8, the CHR of PCSRC is higher than those of CEE and Prob-Cache. The CHRs of PCSRC, ProbCache and CEE reach 42.7%, 25.3% and 21.4% under different cache spaces, respectively. The CHR of PCSRC is more 43% and 50% than those of ProbCache and CEE, respectively. The reason is that PCSRC performs pre-caching of content so that users can obtain the content nearby. The CHR of CEE is relatively low due to its blind caching strategy.
2) AVERAGE REQUEST HOP Figure 9 shows the ARH in comparison with CEE and Prob-Cache by increasing cache capacity under γ = 5, α = 0.8.  From Figure 9, ARH of each strategy gradually decreases with the increase of cache capacity, since the requested content is gradually cached in routers. The ARH of CEE is about 3.9 which is the largest in the three schemes due to its strategy of caching everything everywhere. Since ProbCache stores content in a path based on a fixed probability (setting 0.7 in our simulation) without taking the correlation of requests into account, its ARH is about 3.5, which is a little better than that of CEE. Compared to the two schemes, the ARH of PCSRC can reach about 2.4, since PCSRC actively caches subsequent contents according to the request content, and the gradually pushes the popular content to the edge of the network. Figure 10 shows the ARH in comparison with CEE and ProbCache by increasing the parameter α. From Figure 10, the ARH of each scheme is decreasing with the α increasing. The average values of ARH of PCSRC, ProbCache and CEE are 2.82, 4.01 and 4.17, repectively. Specifically, the ARH of PCSRC is 1.42 hops lower than that of ProbCache and 1.6 hops lower than that of CEE. Figure 11 shows the STR in comparison with CEE and ProbCache by increasing the cache capacity. The STR of CEE is only 0.36 when the cache space is 20%, which does not improve significantly with increasing the cache capacity, since CEE makes the cached content to be homogeneous. The STR of ProbCache decreases to 0.26 when the cache   space is 20%. Compared with the other two schemes, the STR of PCSRC can reach 0.073 when the cache space is 20%. Moreover, the average STR s of CEE, ProbCache and PCSRC are 0.48, 0.41 and 0.18, respectively. Figure 12 and Figure 13 show the ARD in comparison with CEE and ProbCache under λ = 30 and λ = 40, respectively. From Figure 12 and Figure 13, three are larger time delays at the beginning of each scheme since routers do not cache any contents and the requests need to be forwarded to CSS. Routers will cache some contents for each scheme with time going, which will respond some requests and reduce the ADR of each scheme. The ARD of CEE is the largest due to its caching everything everywhere. The ARD of ProbCache is a little worse than that PCSRC since it caches the content on the path with a fixed probability. The ARD of PCSRC can get the best than those of CEE and ProbCache, because it pre-caches the subsequent chunks of current content.

V. CONCLUSION
As an important feature of IC-IoT, cache is an important means to improve the performance of smart devices in the network. In this paper, we focus on the caching strategy and proposed a Pre-Caching Strategy based on the Relevance of requested Content for Collaboration between nodes, called PCSRC. In PCSRC, the subsequent content chunks of a request are pre-cached based on the relevance of content. Furthermore, we set a sojourn time for each content chunk according to its popularity. On the one hand, PCSRC can push the popular content to the edge of the network efficiently. On the other, PCSRC reduces the hop count, which improves the user experience. We verify the validity of the method from four aspects: the first is cache hit ratio, and PCSRC can reach 42.7% with the different storage. This benefits largely from the per-caching of content so that users can obtain the content nearby; the second is the average hop count, and PCSRC can reach about 2.4, making for average hop count as high as 47.9% than CEE; the third is the STR. Compared with the other two schemes the STR of PCSRC can reach 0.073 when the cache space is same; the fourth is ARD. The ARD of PCSRC can get the best than CEE and Prob Cache under different parameters λ. The above simulation results show that the PCSRC outperform existing methods, for example, CEE and Prob Cache. In the future, we will further enhance our schemes for large data and emulate our schemes in the different network topology.
BOWEI HAO was born in Henan, China, in June 1995. He received the B.Eng. degree in the Internet of Things Engineering from the Henan University of Science and Technology, Henan, Luoyang, in July 2018, where he is currently pursuing the master's degree. His research interests include the future Internet and ICN networks.
RUILIN WANG was born in Henan, China, in June 1996. She received the bachelor's degree in software engineering from Luoyang Normal University, in 2019. She is currently pursuing the master's degree with the Henan University of Science and Technology. She is also studying computer science and technology. Her research direction is traffic scheduling for ICN.
YE WANG was born in Henan, China, in November 1994. She received the bachelor's degree in computer technology from the Henan University of Science and Technology, in 2019, where she is currently pursuing the master's degree in computer technology with the School of Information Engineering. Her research direction is artificial intelligence. VOLUME 8, 2020