Caching Joint Shortcut Routing to Improve Quality of Service for Information-Centric Networking

Hundreds of thousands of ubiquitous sensing (US) devices have provided an enormous number of data for Information-Centric Networking (ICN), which is an emerging network architecture that has the potential to solve a great variety of issues faced by the traditional network. A Caching Joint Shortcut Routing (CJSR) scheme is proposed in this paper to improve the Quality of service (QoS) for ICN. The CJSR scheme mainly has two innovations which are different from other in-network caching schemes: (1) Two routing shortcuts are set up to reduce the length of routing paths. Because of some inconvenient transmission processes, the routing paths of previous schemes are prolonged, and users can only request data from Data Centers (DCs) until the data have been uploaded from Data Producers (DPs) to DCs. Hence, the first kind of shortcut is built from DPs to users directly. This shortcut could release the burden of whole network and reduce delay. Moreover, in the second shortcut routing method, a Content Router (CR) which could yield shorter length of uploading routing path from DPs to DCs is chosen, and then data packets are uploaded through this chosen CR. In this method, the uploading path shares some segments with the pre-caching path, thus the overall length of routing paths is reduced. (2) The second innovation of the CJSR scheme is that a cooperative pre-caching mechanism is proposed so that QoS could have a further increase. Besides being used in downloading routing, the pre-caching mechanism can also be used when data packets are uploaded towards DCs. Combining uploading and downloading pre-caching, the cooperative pre-caching mechanism exhibits high performance in different situations. Furthermore, to address the scarcity of storage size, an algorithm that could make use of storage from idle CRs is proposed. After comparing the proposed scheme with five existing schemes via simulations, experiments results reveal that the CJSR scheme could reduce the total number of processed interest packets by 54.8%, enhance the cache hits of each CR and reduce the number of total hop counts by 51.6% and cut down the length of routing path for users to obtain their interested data by 28.6–85.7% compared with the traditional NDN scheme. Moreover, the length of uploading routing path could be decreased by 8.3–33.3%.


Introduction
Rapid advances in the manufacture of sensing devices such as smartphones [1][2][3][4], iPad or other sensing nodes [5][6][7][8][9] have expanded the range of ubiquitous sensing applications in low-betweenness vertices is not efficiently used. Moreover, data replacement in high-betweenness vertices is frequent, which means popular data are also likely to be replaced very often.
Psaras and Chai et al. [55] proposed the Prob Cache scheme. In this scheme, after sending an interest packet, a probability value would be calculated using the storage capacity of a CR on the path that the interest packet had just travelled and the distance between this CR and users. Then, this number would be referred as a criterion on caching data packets. The Prob scheme is also used widely by later research. Overall, it is a scheme that, after evaluating the importance of each vertex, cache data according to the importance of vertices. This scheme reduces redundancy of data packets to some extent, improves efficiency on using storage capacity and ameliorate the network performance. However, popularity of data is not considered in this scheme, and all the data are treated equally. As a result, the popular contents are cached inefficiently.
Ming et al. [56] proposed the age of cache, which is calculated by using popularity of a content and the position of the vertex that stores this content. This work also combined age with other factors to enhance the performance of schemes that simply replace the old content with a new one. Cho et al. [57] proposed a collaborative WAVE scheme that based on the popularity of content packets, the number of cache on a content packet grows exponentially according to the number of request on this content. In addition, Zhang et al. [58] made a comparison on existing caching schemes, indicating that there was a lack of consideration on the distribution attributes of content requests in the design of those caching algorithms. They also gave an inspiration on possible future research directions.
Cache-based technologies is of great importance for NDN, however the development of network has risen new challenges for these technologies. In fact, existing caching schemes assume that data have always been uploaded to DCs by the time it is requested by a user, and the above-discussed schemes are all based on this assumption. However, such an assumption is only applicable for network ten years ago; the concept of = Cloud Computing has since been proposed. The core idea of the Cloud Computing is to deploy hardware resources that have powerful computation ability and high storage capacity in network center; it is similar to the structure of fat server that can undertake a large number of complicated computation and storage. On the other hand, a terminal is rather simple, which gets the result of computation after sending request to the cloud. In this way, the model of Cloud Computing hides the physical difference of devices and provide distributed services. Nevertheless, with the development of IoT, the number of devices that are connected to the Internet grows substantially [1,3,59]; the scale and range of producing data and sharing data also increase exponentially. Because all the data produced by numerous devices must be sent to network center (Cloud platforms or DCs) for computing and processing, the overall burden of the network center is significant, delay is high and QoS is poor. On the one hand, devices in the network center are overloaded and network is often congested. On the other hand, computation and storage resources of many devices on the edge are underused. Thus, computational frameworks such as Fog Computing and Edge Computing are proposed. Their main idea is to shift the work of computing from network center to edge to exploit the potential of computation and storage resources. Under that model, users' request would be satisfied in a local network. The congestion and latency caused by long-distance transmission between users and DCs could be decreased. However, the research of distributed network architectures is still in early stage of exploration.
Because the emerging network architectures are immature, the original network architecture is still widely used, but its caching mechanisms are inefficient. Specifically, those caching schemes are only applicable during routing between DCs and users. In other words, it could only solve partial problem of down data flow from network center to network edge. Performance of the process of uploading immense data from sensing devices to DCs has not been improved by past schemes, not to mention, more broadly, trying to optimize those processes together. Nowadays, main pressure on the network is caused by the up data flow, or the data flow from edge to edge, which has to be relayed by network center (for instance, a colossal number of data produced by instant messaging such as QQ and WeChat must be relayed by network center). In conclusion, the CJSR scheme in this paper could be a possible solution based on such a background; this scheme considers the attributes of present network and aims to solve the existing problems.

Network Model
As shown in Figure 1, the network model used in this paper is Sensor-Cloud Network (SCN), which is an emerging network model in ICN. In such a network, there are three major components: (1) Ubiquitous sensing devices. Broadly distributed sensing devices are producers of data. The information foundation of ICN is based on a colossal number of data collected and sensed by these devices and the number of these devices are numerous. Located on the network edge, they are important parts of the Internet of Things (IoT). These sensing devices are made up of mobile sensing devices such as portable devices (smartphones, iPad and cameras) and more powerful devices carried by vehicles, ships and unmanned aerial vehicles. There are also static sensing devices including surveillance cameras and industrial sensors. Data can be sensed in formats such as video, audio, image or text. For instance, emergency events or breaking news are usually collected by sensing devices of nearby people in forms of videos, audios and images. Following that, the collected content is uploaded to DCs for storage. Ubiquitous sensing devices are shown in the left part of Figure 1.
(2) Data Centers (DCs). DCs are similar to publishers in Named Data Networking (NDN), which provide all the requested data to users and have the most comprehensive storage of all kinds of data. Rather than focus on the transmission of stored video streaming similar to other research on NDN, the data of SCN in this paper have semi-real-time attribute. When an emergency event or breaking news happens, users want to obtain relevant videos, audios and images as soon as possible. Lagged data transmission would result in loss of interest; these data also become out-of-date as time goes by. For instance, during a traffic congestion, drivers in a congestion area send the current traffic situation to a DC, other users could get this information and use it to schedule their routes. If the obtained data are outdated, users (especially those who plan to drive towards this road) would make wrong decisions. One possible situation is that the outdated information may lead users to drive through a longer road because they thought the shorter road is congested. As a result, this longer road would cost more time and gasoline. Users could also be misled to a congested road by outdated information which reports that this road is unobstructed. Overall, this information would give users a poor QoS. Besides the example we give above, similar problems also happen on other applications and could cause users to make wrong decisions. In this paper, DCs are different from those in traditional ICN, in which it is assumed that all data have been uploaded whenever users request them. Traditionally, data are usually obtained by physical methods such as installing storage hardware (hard disks, CDs or tape recorders). Those data are mainly multi-media streaming with low real-time request. Thus, data producers in traditional ICN are usually omitted and only the interaction process between DCs (publishers) and users is considered. However, in this paper, we aim to improve performance on processing semi-real-time data, and have considered a situation that the requested data have not been uploaded completely. Besides stored videos used in traditional ICN, we focus on real-time videos collected from sensing devices around locations where breaking news occurred, and collected video streaming is often short (approximately lasts between a few seconds and ten minutes). Such real-time data would provide users better QoS if they could be delivered more swiftly; vice versa, outdated data have less value and QoS would be declined under their influence.
(3) Users. In this paper, users are equivalent to data requesters, such as drivers in the aforementioned example, or people who are interested in breaking news or a hot event. Due to the powerful functions of smartphones, more and more users obtain data through smartphones or iPad rather than personal computers. Thus, smartphones are not only producers (Data Producers of DCs) which sense and collect data, but also data consumers. It is also noticeable that users and DPs (sensing devices) are both located on the network edge. important parts of the Internet of Things (IoT). These sensing devices are made up of mobile sensing devices such as portable devices (smartphones, iPad and cameras) and more powerful devices carried by vehicles, ships and unmanned aerial vehicles. There are also static sensing devices including surveillance cameras and industrial sensors. Data can be sensed in formats such as video, audio, image or text. For instance, emergency events or breaking news are usually collected by sensing devices of nearby people in forms of videos, audios and images. Following that, the collected content is uploaded to DCs for storage. Ubiquitous sensing devices are shown in the left part of Figure 1. (2) Data Centers (DCs). DCs are similar to publishers in Named Data Networking (NDN), which provide all the requested data to users and have the most comprehensive storage of all kinds of data. Rather than focus on the transmission of stored video streaming similar to other research on NDN, the data of SCN in this paper have semi-real-time attribute. When an emergency event or breaking news happens, users want to obtain relevant videos, audios and images as soon as possible. Lagged data transmission would result in loss of interest; these data also become out-of-date as time goes by. For instance, during a traffic congestion, drivers in a congestion area send the current traffic situation to a DC, other users could get this information and use it to schedule their routes. If the obtained data are outdated, users (especially those who plan to drive towards this road) would make wrong decisions. One possible situation is that the outdated information may lead users to drive through a longer road because they thought the shorter road is congested. As a result, this longer road would cost more time and gasoline. Users could also be misled to a congested road by outdated information which reports that this road is unobstructed. Overall, this information would give users a poor QoS. Besides the example we give above, similar problems also happen on other applications and could cause users to make wrong decisions. In this paper, DCs are different from those in traditional ICN, in which it is assumed that all data have been uploaded whenever users request them. Traditionally, data are usually obtained by physical methods such as installing storage hardware (hard disks, CDs or tape recorders). Those data are mainly multi-media streaming with low real-time request. Thus, data producers in traditional ICN are usually omitted and only the interaction process between DCs (publishers) and users is considered. However, in this paper, we aim to improve performance on Besides the three components discussed above, the network model contains the following interaction processes: (1) Routing process of requesting data from DCs. Although users and DPs are both located on the network edge, prefixes of sensing devices are unknown to users, but prefixes of DCs are public to the whole network. Therefore, a user would firstly request data from DCs as they usually do in conventional SCN. This routing path is built between users and cloud; we refer to it as routing path of request. To build the first kind of shortcut that enables users to directly send requests to sensing devices rather than DCs, a DP's prefix would be recorded as soon as a DC receives uploaded data. Hence, with the prefix recorded, the DC could reply the information of the DP to the user if the requested data have not been uploaded yet. Then, the user could directly request data from the DP. Otherwise, the DC would send corresponding data to the user following the traditional procedures.
(2) Routing process of transmitting data from DCs to users. When DCs receive requests from users, they send corresponding data to users if the requested data are stored. This routing path is the transmission path of data between DCs and users, thus this path is referred as downloading routing path of data.
(3) Routing process of uploading data. While sensing devices are collecting data, they upload collected data to DCs at the same time without being requested by DCs. The data collection process in the network model which our work used is similar to crowdsourcing network or participatory network [14][15][16][17][18][19]. Therefore, data packets are uploaded without being requested by the cloud. The routing path in this process is referred to as the routing path of uploading data. This routing path is usually directly built among DCs and DPs. However, using two shortcut routing methods discussed in Section 4, this path would adjust itself to yield shorter overall routing paths.
Next, we give standardized definition of the network model shown in Figure 1. The network can be defined as an undirected graph G = (ξ, E), where ξ is a set of vertices or nodes representing content routers, data requesters (DRs), data producers (DPs) and the data centers (DCs). Usually, DRs, DPs and DCs are located on the terminal of a routing path while CRs are intermediary. E is the set of undirected edges modeling communication links between pairs of vertices.
(1) Suppose that ξ = {ξ i1 , ξ i2 , . . . , ξ in } is a set of intermediary content routers (CRs) on a routing path (start with a requester and end at a DC or a DP). The CRs can cache the data in their cache storage. A vertex ξ i has a limited cache storage capacity C ξ i , measured in bytes.
(2) Suppose that R = {r 1 , r 2 , . . . , r m } is the set of data requesters (DRs), i.e., users. The data requesters request data and if the data have been cached among CRs, the hop count for users to obtain these data would be reduced. Users could obtain data from a CR with these data cached, thus the QoS is ameliorated. Similar to a previous research [35], we assume that data requesters are connected to network through a single CR. We denote the vertex (CR) connected to requester r i as ξ r i . (3) Suppose that S = {p 1 , p 2 , . . . , p k } is the set of data producers (DPs). The data producers are sensing devices that sense and collect data. Sensing devices provide data to users or DCs through CRs. Different with other research, data can also be cached during the transmission from DPs to DRs in our work. We denote the vertex (CR) connected to data producer S i as ξ p i .
(4) Suppose that D = {D 1 , D 2 , . . . , D N } is the set of data centers (DCs). Data Centers have powerful storage and computation capacity and their addresses are public. Besides the data that have not been uploaded, they have stored all the data that may be requested by users. We denote the vertex (CR) connected to data center D i as ξ D i .
(5) Let S n = {S 1 , S 2 , . . . , S m , . . . , S n } be a set of data packets. For a requested chunk S m from S n , we define L as the fixed size of each data packet. A m ξ i,r j denotes the frequency of interest packets for S m at node ξ i ∈ V from user r j .
(6) Suppose that P = {P 1 , P 2 , . . . , P i , . . . , P M } is a set of routing path. P i = {ξ i1 , ξ i2 , . . . , ξ in }, in which ξ i1 is the first vertex on this routing path. There are a few possible scenarios: (a) When users start to request data through the uploading routing path, ξ i1 is a user (ξ r i ), while ξ in could be a CR, a DC or a DP, if the request is satisfied by a CR in the routing path, ξ in is that CR; if the request is satisfied by a DC, ξ in is that DC (ξ D i ); if the requested data have not been uploaded yet, users will request from a DP, in that case, ξ in is a DP (ξ p i ). To facilitate pre-caching, we make use of the transmission path of an interest packet from user to DCs or DPs, and we refer to this path as P cache . P cache = ξ i1 (ξ r i ), ξ i2 , . . . , ξ ij ξ p i or ξ D i . We discuss the details of its construction in Section 4.1. (b) During the transmission of data, ξ i1 could be a CR or a DC while ξ in is the user who issues this request (ξ r i ). (c) For the uploading routing path of data, ξ i1 is a DP, and ξ in could be a user, CR or DC. If ξ in is a user, it denotes that data are forwarded from a DP to a user; if ξ in is a CR, this routing path starts from a DP to a CR; and, if ξ in is a DC, it is a between a DP and a DC. Thus, the first and the last vertex on routing path P For the convenience of readers, Table 1 summarizes the notations used in this paper. The Interest frequency of I n on ξ ij from user r j

Problem Statement
The optimization objectives of the CJSR scheme are different from past schemes that merely focus on performing pre-caching from DCs to users. For those past schemes, their objective is to minimize the total number of hop counts for users to obtain data. This paper gives a more comprehensive consideration by taking into account of three interaction processes that we discuss in Section 3.1. Hence, the CJSR scheme is more practical for SCN. The optimization objectives in this paper include: (1) Minimization of the total hop counts for users to obtain data. Assume that the path for users to obtain data is the same as previous definitions: P = {P 1 , P 2 , . . . , P i , . . . , P M } and P i = {ξ i1 , ξ i2 , . . . , ξ in }. Then, the length of the ith routing path is denoted as H i = |P i |. The first objective in this paper is to minimize the hop counts that users obtain their interested data, as demonstrated by Equation (1).
(2) Minimization of delay. The optimization objective of past schemes is similar to Equation (1). Besides, we have more objectives in this paper. The delay refers to the whole time interval from when data are requested to when they are finally received by users, and reflects the timeliness for a user to receive data. Obviously, less delay would lead to better QoS. Assume the time that a data chunk C i,j is produced is G i,j , the time when it is received by user k is J k i,j . Thus, the delay of user k requests for Thus, the second optimization objective is Equation (2) min (3) Minimization of network burden. The burden of network could be measured by the number of packets forwarded by each CR. Reduce the burden is also one of the CJSR scheme's objectives. It is assumed that the number of packets forwarded by a CR ξ i is S i . The third optimization objective in this paper is Equation (3).
Obviously, the goal of the CJSR scheme is to minimize the total number of hops H, minimize delay Γ and minimize network burden O. A constraint for achieving these optimization goals is: The caching storage of a CR ξ i at some time (C ξ i ) cannot exceed its physical storage capacity C ξ i . The optimization goals in this paper can be summarized as follows.

The Design of Data Structures
In this section, we discuss data structures related to the CJSR scheme. Our scheme is an improvement based on previous in-network caching schemes and we aim to improve caching mechanisms and reduce the length of routing paths. Firstly, three classic data structures including the Content Store (CS), the Pending Interest Table (PIT) and the Forwarding Information Base (FIB) are used and the lookup procedures are depicted in Figure 2. Other data structures used in the CJSR scheme include: (1) interest packet, which is used by users to request data and to construct a fixed path to facilitate pre-caching; (2) data packet, the function of which is to carry data and relevant information about data (like its destination); (3) Extra Storage (ES), which is a table sharing a similar structure to the Content Store. The ES is used in Algorithm 3 for an idle CR to help store data packets. If the PathMark field of the data packet is identical to The CR's sequence number (Algorithm 1) Figure 2. Lookup procedures of the CJSR scheme.
(1) Interest packet format. The structure of an interest packet is demonstrated in Figure 3 (the tilde marks represent that the length of this field is variable). Besides Name and Nonce, Selectors are optional elements that further qualify Data that may match the Interest. They are used for discovering and selecting the data that match best to what the application wants, and this is the place where the PathMark element is added. The aim of adding this element is to record a series of CRs that this interest packet had travelled. Thus, in the CJSR scheme, with the added PathMark, a DC or a DP can construct a fixed path to facilitate pre-caching. The reason for constructing such a path is to providently assign data packets into CRs in a controllable way. Traditionally, data packets would be sent back through the transmission path of interest packets. Therefore, it is reasonable to use this path to assign the predicted data packets to conduct pre-caching. To enable DPs or DCs to construct this path after receiving an interest packet, CRs and users would add their sequence number to an interest packet when they forward it, so the is recorded in the Selecters field. (2) Data packet format. A data packet represents some arbitrary binary data held in the Content element together with its Name, some additional bits of information (MetaInfo), and a digital Signature of the other three elements. The Name is the first element since all NDN packet processing starts with the name. Signature is put at the end of the packet to ease the implementation because signature computation covers all the elements before it. To assign each data packet to its correct location in pre-caching, we add a PathMark field to data packets as it is shown in the white field of Figure 4. This field is used as the indication of a data packet's destination. Thus, would be added to the PathMark field of a produced data packet; when a CR receive a data packet, it checks whether the is same as its own sequence number and forwards this packet to next CR along the if the does not matched.  (1) Interest packet format. The structure of an interest packet is demonstrated in Figure 3 (the tilde marks represent that the length of this field is variable). Besides Name and Nonce, Selectors are optional elements that further qualify Data that may match the Interest. They are used for discovering and selecting the data that match best to what the application wants, and this is the place where the PathMark element is added. The aim of adding this element is to record a series of CRs that this interest packet had travelled. Thus, in the CJSR scheme, with the added PathMark, a DC or a DP can construct a fixed path to facilitate pre-caching. The reason for constructing such a path is to providently assign data packets into CRs in a controllable way. Traditionally, data packets would be sent back through the transmission path of interest packets. Therefore, it is reasonable to use this path to assign the predicted data packets to conduct pre-caching. To enable DPs or DCs to construct this path after receiving an interest packet, CRs and users would add their sequence number to an interest packet when they forward it, so the P cache is recorded in the Selecters field.
Forward the Interest to the outgoing face according to FIB If the PathMark field of the data packet is identical to The CR's sequence number (Algorithm 1) Figure 2. Lookup procedures of the CJSR scheme.
(1) Interest packet format. The structure of an interest packet is demonstrated in Figure 3 (the tilde marks represent that the length of this field is variable). Besides Name and Nonce, Selectors are optional elements that further qualify Data that may match the Interest. They are used for discovering and selecting the data that match best to what the application wants, and this is the place where the PathMark element is added. The aim of adding this element is to record a series of CRs that this interest packet had travelled. Thus, in the CJSR scheme, with the added PathMark, a DC or a DP can construct a fixed path to facilitate pre-caching. The reason for constructing such a path is to providently assign data packets into CRs in a controllable way. Traditionally, data packets would be sent back through the transmission path of interest packets. Therefore, it is reasonable to use this path to assign the predicted data packets to conduct pre-caching. To enable DPs or DCs to construct this path after receiving an interest packet, CRs and users would add their sequence number to an interest packet when they forward it, so the is recorded in the Selecters field. (2) Data packet format. A data packet represents some arbitrary binary data held in the Content element together with its Name, some additional bits of information (MetaInfo), and a digital Signature of the other three elements. The Name is the first element since all NDN packet processing starts with the name. Signature is put at the end of the packet to ease the implementation because signature computation covers all the elements before it. To assign each data packet to its correct location in pre-caching, we add a PathMark field to data packets as it is shown in the white field of Figure 4. This field is used as the indication of a data packet's destination. Thus, would be added to the PathMark field of a produced data packet; when a CR receive a data packet, it checks whether the is same as its own sequence number and forwards this packet to next CR along the if the does not matched.  (2) Data packet format. A data packet represents some arbitrary binary data held in the Content element together with its Name, some additional bits of information (MetaInfo), and a digital Signature of the other three elements. The Name is the first element since all NDN packet processing starts with the name. Signature is put at the end of the packet to ease the implementation because signature computation covers all the elements before it. To assign each data packet to its correct location in pre-caching, we add a PathMark field to data packets as it is shown in the white field of Figure 4. This field is used as the indication of a data packet's destination. Thus, P m would be added to the PathMark field of a produced data packet; when a CR receive a data packet, it checks whether the P m is same as its own sequence number and forwards this packet to next CR along the P cache if the P m does not matched.
(3) Extra Storage (ES). Figure 5b illustrates this data structure. To address the scarcity of storage space, we introduced the ES to use idle CRs. The structure and storage capacity of the ES and the CS is similar, each "extra chunks" is mapped to an "ename". When a CR on the P cache asks an idle CR to cache a data packet on its behalf, relevant information is stored in the "ename" and "extra chunks" entries of the ES for future reference. (3) Extra Storage (ES). Figure 5b illustrates this data structure. To address the scarcity of storage space, we introduced the ES to use idle CRs. The structure and storage capacity of the ES and the CS is similar, each "extra chunks" is mapped to an "ename". When a CR on the asks an idle CR to cache a data packet on its behalf, relevant information is stored in the "ename" and "extra chunks" entries of the ES for future reference.

CJSR Scheme
The CJSR scheme is composed of Algorithms 1 and 2. The former gives detailed procedures of pre-caching, which roughly contains two steps.
Step 1 describes how to process an interest packet and the assignment of data packets.
Step 2 is the transmission process of a data packet. Algorithm 2 is the overall algorithm of the CJSR scheme, and gives the pseudo-code of the whole process of the cooperative pre-caching, which consists of uploading pre-caching and downloading pre-caching. In Section 4.3, we discuss a further attempt to address the scarcity of storage capacity.
The CJSR scheme could cache semi-real-time data in CRs intelligently by using the cooperative pre-caching. Moreover, with two shortcut routing methods, the length of routing path for users to obtain data is noticeably decreased. In the CJSR scheme, DPs not only collect and provide data, but also assign data towards users proactively. During the whole process, if cooperative pre-caching is conducted successfully, users could fetch their interested data from nearby CRs rather than DCs. That is to say, interest packets could be handled by CRs that have the requested data cached, thus the burden of processing interest packets would be decreased. In addition, it is also unnecessary for data packets to travel through the whole when they are requested by users. Therefore, the burden of forwarding data packets would also be declined, due to the decline of hop counts between CRs with requested data cached and users; latency could have a noticeable drop. Thus, Equations (1)-(3) could be improved, which provides an empirical guarantee for better QoS.
As a significant component of the CJSR scheme, the pre-caching algorithm is discussed initially. First, a user sends an interest packet requesting for (e.g., a real-time video relevant to breaking news). As are being forwarded towards DCs or DPs (these two situations are discussed in the cooperative pre-caching of Algorithm 2), each CR adds its sequence number to the PathMark (3) Extra Storage (ES). Figure 5b illustrates this data structure. To address the scarcity of storage space, we introduced the ES to use idle CRs. The structure and storage capacity of the ES and the CS is similar, each "extra chunks" is mapped to an "ename". When a CR on the asks an idle CR to cache a data packet on its behalf, relevant information is stored in the "ename" and "extra chunks" entries of the ES for future reference.

CJSR Scheme
The CJSR scheme is composed of Algorithms 1 and 2. The former gives detailed procedures of pre-caching, which roughly contains two steps.
Step 1 describes how to process an interest packet and the assignment of data packets. Step 2 is the transmission process of a data packet. Algorithm 2 is the overall algorithm of the CJSR scheme, and gives the pseudo-code of the whole process of the cooperative pre-caching, which consists of uploading pre-caching and downloading pre-caching. In Section 4.3, we discuss a further attempt to address the scarcity of storage capacity.
The CJSR scheme could cache semi-real-time data in CRs intelligently by using the cooperative pre-caching. Moreover, with two shortcut routing methods, the length of routing path for users to obtain data is noticeably decreased. In the CJSR scheme, DPs not only collect and provide data, but also assign data towards users proactively. During the whole process, if cooperative pre-caching is conducted successfully, users could fetch their interested data from nearby CRs rather than DCs. That is to say, interest packets could be handled by CRs that have the requested data cached, thus the burden of processing interest packets would be decreased. In addition, it is also unnecessary for data packets to travel through the whole when they are requested by users. Therefore, the burden of forwarding data packets would also be declined, due to the decline of hop counts between CRs with requested data cached and users; latency could have a noticeable drop. Thus, Equations (1)-(3) could be improved, which provides an empirical guarantee for better QoS.
As a significant component of the CJSR scheme, the pre-caching algorithm is discussed initially. First, a user sends an interest packet requesting for (e.g., a real-time video relevant to breaking news). As are being forwarded towards DCs or DPs (these two situations are discussed in the cooperative pre-caching of Algorithm 2), each CR adds its sequence number to the PathMark

CJSR Scheme
The CJSR scheme is composed of Algorithms 1 and 2. The former gives detailed procedures of pre-caching, which roughly contains two steps.
Step 1 describes how to process an interest packet and the assignment of data packets. Step 2 is the transmission process of a data packet. Algorithm 2 is the overall algorithm of the CJSR scheme, and gives the pseudo-code of the whole process of the cooperative pre-caching, which consists of uploading pre-caching and downloading pre-caching. In Section 4.3, we discuss a further attempt to address the scarcity of storage capacity.
The CJSR scheme could cache semi-real-time data in CRs intelligently by using the cooperative pre-caching. Moreover, with two shortcut routing methods, the length of routing path for users to obtain data is noticeably decreased. In the CJSR scheme, DPs not only collect and provide data, but also assign data towards users proactively. During the whole process, if cooperative pre-caching is conducted successfully, users could fetch their interested data from nearby CRs rather than DCs. That is to say, interest packets could be handled by CRs that have the requested data cached, thus the burden of processing interest packets would be decreased. In addition, it is also unnecessary for data packets to travel through the whole P cache when they are requested by users. Therefore, the burden of forwarding data packets would also be declined, due to the decline of hop counts between CRs with requested data cached and users; latency could have a noticeable drop. Thus, Equations (1)-(3) could be improved, which provides an empirical guarantee for better QoS.
As a significant component of the CJSR scheme, the pre-caching algorithm is discussed initially. First, a user sends an interest packet I m requesting for S m (e.g., a real-time video relevant to breaking news). As I m are being forwarded towards DCs or DPs (these two situations are discussed in the cooperative pre-caching of Algorithm 2), each CR adds its sequence number to the PathMark of I m . Then, the P cache is constructed by the time this interest packet arrives at a DC or a DP. Because the same video streaming is successive, after requesting for S m , this user is highly likely to request the subsequent data of the same streaming. In addition, due to the extensive public concern for breaking news, other users also have high probability to request the same data. Therefore, after the formation of P cache , pre-caching is triggered and the rest of data stored in the DC or the following data collected by the DP would be assigned to CRs along the P cache providently. To assign unrequested data, the synthetic interest generator (discussed in NFD developer's guide) could be used to make entries in the PIT. In other words, from the CRs' point of view, the remaining data look like they have been requested. Thus, by the time those data packets arrive at vertices they are assigned to, they can be cached. Due to the limited storage size of each CR, each CR can only store a proportion of the data, thus the remaining data from S n = {S 1 , S 2 , . . . , S m , . . . , S n } are divided into a few arrays. The size of each array depends on the cache capacity of CRs (size of each array = C ξ i = d data packets). In the order from S m to S n , the remaining data are divided into (m − n)/d arrays. The first array which has the largest probability to be requested later is cached in the nearest CR (ξ r i ) next to a user (r i ). Following that, each of the remaining arrays is cached into each CR along the P cache . Hence, each round of pre-caching can assign d×N ξ data packets and the CJSR scheme is consisted of (m − n)/d × N ξ round(s) of pre-caching. It is noticeable that only the interest packet requesting for the first data of each round can trigger pre-caching (I m , I m+d×N ξ , I m+2×d×N ξ etc.), other interest packets would be processed by intermediary CRs rather than DPs or DCs if the pre-caching is conducted successfully. Nevertheless, an interest packet may not be satisfied by overlapped CRs (such situations are also considered in Scenario 2 and Scenario 4 of experiments); this interest has to be forwarded to the DP or the DC along the caching path and the data packet is sent back using LCE cache strategy. The specific algorithm of pre-caching is shown in Algorithm 1.

1:
Step 1: I m requesting for S m from S n = {S 1 , S 2 , . . . , S m , . . . , S n } is issued by a user 2: I m arrives at a DP or a DC 3: Construct the P cache = {ξ i1 , ξ i2 , . . . , ξ ij } from the PathMark element of I m 4: Compute the number of vertices in the P cache : N ξ 5: (n-m) packets are divided into (m-n)/d arrays, each of which contains d packets 6: For j = 1 to N ξ do 7: Prouced a data packet S k , add j to its PathMark fiekd indicating its desination 9: Forward S k to ξ ij 10: End For 11: End For 12: Step 2: The transmission of a data packet S k 13: For k = m to n 14: For j = N ξ to 1 15: S k arrives at ξ ij 16: If S k is found in the PIT of ξ ij 17: If the P m of S k is identical to ξ ij 's sequence number 18: Cache S k 19: Else 20: Forward S k to next vertex 21: End if 22: Else 23: Drop S k 24: End If 25: End For 26: End For Next, the CJSR algorithm is given below. Using the pre-caching discussed in Algorithm 1, the cooperative pre-caching is achieved by applying pre-caching in uploading and downloading process in two possible situations: (1) The requested data are stored in a DC. Then, the DC could perform downloading pre-caching between the user and itself. During this process, interest packets are forwarded using the prefix of the DC. Following that, the chunk is produced using DC's signature.
(2) The requested data have not been uploaded yet. In this case, the DC would respond the user's request with the location of the DP that is collecting the requested data. Once the user gets the address of that DP, the request can be forwarded to the DP directly, and then the DP could perform uploading pre-caching. The user would use the DP's prefix to request, while the produced data packets are signed by the DP. In other words, each chunk only has one name in these two situations, hence cooperative pre-caching is applicable for various situations. Another main idea of the CJSR scheme is the formation of shortcut. After acquiring the location of the DP, the user directly request data from the DP, since now the first kind of shortcut is constructed. In addition, the uploading process and pre-caching happens at the same time, and the uploading path of data packets would share some segments of P cache . Then, data packets would find a CR that could yield shorter overall routing path to form the second kind of shortcut. Firstly, prefixes from Data Centers are used if users request data from DCs. After the formation of the first shortcut, the prefix of the Data Producer is used and interest packets are sent to the DP. By combining the cooperative pre-caching and two shortcut routing methods, the burden of all devices (especially DCs and DPs) could be decreased significantly, cache hits would ascend and latency would drop. Algorithm 2 depicts the concrete process of the CJSR scheme.

Algorithm 2 Caching Joint Shortcut Routing
1: I m requesting for S m from S n = {S 1 , S 2 , . . . , S m , . . . , S n } is issued by a user 2: I m arrives at a vertex 3: If the pre-cached data in vertex ξ ij meets the demand after performing lookup on its Content Store 4: Forward S m to user 5: Else 6: Forward I k to next vertes 7: If I m arrives at a DC 8: If the requested data have not been uploaded 9: The DC responds the location of DP to the user 10: The user forwards i m towards the DP 11: The DP performs algorithm 1 between the DP and the user (uploading pre-caching) 12: Else 13: The DC performs algorithm 1 between the DC and the user (downloading pre-caching) 14: End If

15: End If
Next, the whole process of the CJSR scheme is illustrated using a concrete example along with a series of detailed figures. We make some modifications to the scenario we used in Figure 1 and use it as our example. It is assumed that there are one user (another user will join the network later), one Data Producer (DP), one Data Center (DC) and n CRs. When breaking news happens, a user issues an interest for a short video about this news and hopes to obtain the data with high QoS, a DP is collecting and sensing data relevant to the news, and a DC is waiting for the data to be uploaded. Moreover, we assume that the requested streaming contains 20 data packets, N ξ = 5, and the storage size of each CR is 4 data packets. At the beginning, the user is interested in S 1 and requests it. The forwarding of I 1 automatically find the shortest route to a DC. To focus on routing paths, we omit the links among CRs in the following graphs. Detailed procedure and ideas are: (1) Initial process of requesting data. In Figure 6, a DP is collecting data about that news, then uploads data to a DC according to its public prefix (Routing Path x in Figure 6). Then, the user requests S 1 . By that time, the user does not possess any information about where the data are produced, so the interest packet is sent to the DC (Routing Path y in Figure 6). Because the requested data S 1 have not been uploaded, the DC responds with the prefix of the DP that is collecting the requested data to the user (Routing Path z in Figure 6). As a result, uploading pre-caching of the cooperative pre-caching mechanism is going to be performed in this example.
(2) Re-direction of data request. After receiving the prefix information about the DP, the user starts to request data from the DP directly (Routing Path y in Figure 7).
(3) The formation of the first shortcut routing path. As it is shown in Figure 8, a transmission path between the DP and the user is built thus the user does not have to obtain data from the DC. In this case, the shortcut is also the P cache . The number of CRs (N ξ ) on the P cache is five. Because of the scarcity of storage size, S 1 to S 20 is divided into five arrays (as it is demonstrated in the left part of Figure 8), then the first round of pre-caching is conducted and five arrays are cached in five CRs along the P cache .
(4) Pre-caching on the uploading path of data. Routing Path y in Figures 9-13 demonstrates the whole procedure of uploading pre-caching. Because the subsequent part of the same streaming is likely to be request later, especially the first array. Besides S 1 , S 2 to S 4 are more likely to be requested later than other arrays. Hence, the first array is assigned to Vertex E. S 1 is sent to user as soon as S 1 is received so the first request of user is satisfied by that time and the following pre-caching are carried out. S 5 to S 8 are assigned to Vertex D, of which the hop counts to user is two. Similarly, S 9 to S 12 are cached in Vertex C, of which the hop counts to user is three; S 13 to S 16 are cached in Vertex B; and S 17 to S 20 are cached in Vertex A. The storage of each CR is shown in Figure 14.
(5) The formation of the second kind of shortcut. Initially, the data are uploaded as shown in Routing Path x of Figure 8. After the formation of the first kind of shortcut, data packets pass through the P cache while they are uploaded as it is depicted in Routing Path x of Figure 9, so that they are cached into CRs while they are uploading. During the conducting of pre-caching, the back proportion of the remaining data are assigned to the CRs that are far away from user. Data packets would adjust its shortcut to find a CR that could yield shorter overall routing path, then upload data through that chosen CR to the DC. Firstly, the chosen CR is Vertex D ( Figure 10). Then, the uploading path of data packets follows Routing Path x in Figure 11. Following that, the uploading path is shown as Routing Path x in Figure 12. Finally, data packets upload through Vertex A (Routing Path x in Figure 13).
(6) Request of cached data (the user's requests). Rather than forward each interest packet to DP in a time-consuming way, interest packets could be handled by CRs that have the requested data cached. (7) The participation of other users. There may be two possible situations after User 2 joins the network: (i) User 2 requests for different data. Such a scenario is demonstrated in Figures 15-17. Firstly, User 2 requests S k from the DC (Routing Path y in Figure 15). It is reasonable that User 2 may request the other relevant data of that breaking news (also have not been uploaded yet) from another DP. Since the requested data are different, two users would conduct the CJSR scheme separately. Because User 1 and User 2 are both located on the network edge, it is assumed that they are connected to Vertex E and Vertex F respectively. After requesting from the DC, User 2 gains the prefix information of DP 2 and sends request to it (a new caching path is established as shown in Caching Path y in Figure 16). After constructing this pre-caching path, the two users' pre-caching path overlap at Vertex C as demonstrated in Figure 17. When User 2 starts to request data, a new round of pre-caching is triggered, and all the data cached in the overlapped CR (Vertex C) would be replaced. This scenario is evaluated in Scenario 4 in Section 5. (ii) User 2 requests for data that has been uploaded. Figures 18  and 19 depict that User 2 s request are satisfied by the DC, although the requested data may still be held by a CR. Since the first interest packet of User 2 is forwarded to the DC, the pre-caching path is built between the DC and the User 2 and the downloading pre-caching is triggered. Following that, the DC would perform downloading pre-caching (similar procedures demonstrated in Figures 9-13 are omitted). been uploaded. Figures 18 and 19 depict that User 2′s request are satisfied by the DC, although the requested data may still be held by a CR. Since the first interest packet of User 2 is forwarded to the DC, the pre-caching path is built between the DC and the User 2 and the downloading pre-caching is triggered. Following that, the DC would perform downloading pre-caching (similar procedures demonstrated in Figures 9-13 are omitted).      been uploaded. Figures 18 and 19 depict that User 2′s request are satisfied by the DC, although the requested data may still be held by a CR. Since the first interest packet of User 2 is forwarded to the DC, the pre-caching path is built between the DC and the User 2 and the downloading pre-caching is triggered. Following that, the DC would perform downloading pre-caching (similar procedures demonstrated in Figures 9-13 (3) Sensing Devices

Data packets
Uploading path of data packets(Routing path ①)   been uploaded. Figures 18 and 19 depict that User 2′s request are satisfied by the DC, although the requested data may still be held by a CR. Since the first interest packet of User 2 is forwarded to the DC, the pre-caching path is built between the DC and the User 2 and the downloading pre-caching is triggered. Following that, the DC would perform downloading pre-caching (similar procedures demonstrated in Figures 9-13 (3) Sensing Devices

Data packets
Uploading path of data packets(Routing path ①)   Uploading path of data packets(Routing path ①)

User Sensing Devices
Content Router the pre-caching path Figure 11. Send the third array (k = 9, 10, 11, 12) to Vertex C. Uploading path of data packets(Routing path ①)

User Sensing Devices
Content Router the pre-caching path Figure 11. Send the third array (k = 9, 10, 11, 12) to Vertex C. Uploading path of data packets(Routing path ①)

Content Router
Content Router the pre-caching path Figure 14. The cache storage of each CR along the . Figure 14. The cache storage of each CR along the P cache .

Sensing Devices
Content Router the pre-caching path Figure 15. User 2 joins the network demanding different data. Pre-caching path of User 1 Figure 16. User 2 starts to request from the DP.  Pre-caching path of User 1 Figure 16. User 2 starts to request from the DP.  Pre-caching path of User 1 Figure 16. User 2 starts to request from the DP.

Sensing Devices
Pre-caching path of user 2 Pre-caching path of user 1 Content Router on the pre-caching path Figure 19. The formation of User 2′s .

Idle CRs Involved Pre-Caching (ICIP)
In Algorithm 1, data packets are assigned to CRs along the , which could be downloading routing paths from DCs to users or uploading routing paths from DPs to users. However, during the whole process of the CJSR scheme, only those CRs on those fixed paths are actively involved in precaching. To exploit the storage resource from underused idle CRs (we define a CR that is not on the as an idle CR) and help CRs on the caching path to cache the data that they cannot accommodate, Algorithm 3 is proposed. In this algorithm, Step 1 is about processing an interest packet. What is different from Algorithm 1 is that the frequency of an interest packet is recorded and used as the criteria in judging the importance of its corresponding data.
Step 2 describes the procedures of processing a data packet at each CR.
The main idea in Algorithm 3 is to address the scarce caching storage in an indirect method. In the first place, a standard should be made to judge the priority of a data packet. If the number of interest packets requesting for a data packet is high, these data are more popular, and may be related to a hot issue or breaking news. Therefore, each CR records a frequency of an interest packet ( , ) and uses it as the criterion. For a newly arrived data packet, comparisons of the Interest frequency are being made before asking help from an idle CR. If the Interest frequency of the incoming data are higher than that of one or more stored data packets, the least frequently used data packet is replaced by the new one. If all the Interest frequency of cached data packets are higher than that of the incoming data packet, which means that all of the stored data have high probability to be requested sooner, this CR will ask an adjacent idle CR to store that unaccommodated data. Here is the detailed process: after a period of pre-caching, the storage of each CR on the is full. When a new data packet arrives at , the , of each cached data packet is compared and the least frequent used

Sensing Devices
Pre-caching path of user 2 Pre-caching path of user 1 Content Router on the pre-caching path Figure 19. The formation of User 2′s .

Idle CRs Involved Pre-Caching (ICIP)
In Algorithm 1, data packets are assigned to CRs along the , which could be downloading routing paths from DCs to users or uploading routing paths from DPs to users. However, during the whole process of the CJSR scheme, only those CRs on those fixed paths are actively involved in precaching. To exploit the storage resource from underused idle CRs (we define a CR that is not on the as an idle CR) and help CRs on the caching path to cache the data that they cannot accommodate, Algorithm 3 is proposed. In this algorithm, Step 1 is about processing an interest packet. What is different from Algorithm 1 is that the frequency of an interest packet is recorded and used as the criteria in judging the importance of its corresponding data.
Step 2 describes the procedures of processing a data packet at each CR.
The main idea in Algorithm 3 is to address the scarce caching storage in an indirect method. In the first place, a standard should be made to judge the priority of a data packet. If the number of interest packets requesting for a data packet is high, these data are more popular, and may be related to a hot issue or breaking news. Therefore, each CR records a frequency of an interest packet ( , ) and uses it as the criterion. For a newly arrived data packet, comparisons of the Interest frequency are being made before asking help from an idle CR. If the Interest frequency of the incoming data are higher than that of one or more stored data packets, the least frequently used data packet is replaced by the new one. If all the Interest frequency of cached data packets are higher than that of the incoming data packet, which means that all of the stored data have high probability to be requested sooner, this CR will ask an adjacent idle CR to store that unaccommodated data. Here is the detailed process: after a period of pre-caching, the storage of each CR on the is full. When a new data packet arrives at , the , of each cached data packet is compared and the least frequent used

Idle CRs Involved Pre-Caching (ICIP)
In Algorithm 1, data packets are assigned to CRs along the P cache , which could be downloading routing paths from DCs to users or uploading routing paths from DPs to users. However, during the whole process of the CJSR scheme, only those CRs on those fixed paths are actively involved in pre-caching. To exploit the storage resource from underused idle CRs (we define a CR that is not on the P cache as an idle CR) and help CRs on the caching path to cache the data that they cannot accommodate, Algorithm 3 is proposed. In this algorithm, Step 1 is about processing an interest packet. What is different from Algorithm 1 is that the frequency of an interest packet is recorded and used as the criteria in judging the importance of its corresponding data.
Step 2 describes the procedures of processing a data packet at each CR.
The main idea in Algorithm 3 is to address the scarce caching storage in an indirect method. In the first place, a standard should be made to judge the priority of a data packet. If the number of interest packets requesting for a data packet is high, these data are more popular, and may be related to a hot issue or breaking news. Therefore, each CR records a frequency of an interest packet (A m ξ i, r j ) and uses it as the criterion. For a newly arrived data packet, comparisons of the Interest frequency are being made before asking help from an idle CR. If the Interest frequency of the incoming data are higher than that of one or more stored data packets, the least frequently used data packet is replaced by the new one. If all the Interest frequency of cached data packets are higher than that of the incoming data packet, which means that all of the stored data have high probability to be requested sooner, this CR will ask an adjacent idle CR to store that unaccommodated data. Here is the detailed process: after a period of pre-caching, the storage of each CR on the P cache is full. When a new data packet arrives at ξ ij , the A m ξ i, r j of each cached data packet is compared and the least frequent used data are replaced. If the A m ξ i, r j of cached data packets are all high, the newly arrived data packet is forwarded to an adjacent idle CR ξ idle , and store ename and extra chunks into the ES. When user requests that data, CRs would check the ES of their adjacent CRs if the data are not found after performing traditional lookup. Using the PathMark field of data packets, if a CR cannot accommodate a data packet, the original sequence number indicating its destination is modified into a special mark, then this data packet is broadcasted to neighbors. Because no CR along the caching path matches the PathMark field of the data packet, this data packet is immediately dropped and only an idle CR could cache it. The detailed process is shown in the following Algorithm 3.

Algorithm 3 Idle CRs Involved Provident Caching (ICIP)
1: I m requesting for S m from S n = {S 1 , S 2 , . . . , S m , . . . , S n } is synthesized by user r j 2: Step 1: I m arrives at ξ ij 3: A m ξ ij, r j ++ 4: If S m is found after performing lookup in the Content Store 5: Forward S m to r j 6: Else 7: Check ES 8: If found entry in ES 9: Forward S m to r j 10: Else forward I m to next vertex 11: If I m arrives at a DC or a DP 12: Perform algorithm 1 13: End If 14: End If 15: End If 16: Step 2: A data packet S k arrives at a CR ξ ij 17: If I k is found in the PIT of ξ ij 18: If the P m of S k is identical to ξ ij 's sequence number 19: If the left cache storage of ξ ij is enough 20: Cache the S k 21: Else 22: For each cached data packet S i in ξ ij 23: The procedure of Algorithm 3 is also illustrated using an example, in which the assumptions and parameters are same as they are in Section 4.1.
(1) Pre-caching process. After performing uploading pre-caching for a period, due to the limitation of caching storage (four data packets), storage capacity of each CR has been filled, as Figure 20 demonstrates.
(2) Replacement of a data packet. At some time while the DP is conducting pre-caching, the data packet S 21 is assigned to Vertex E (Routing Path y in Figure 21). Figure 22 demonstrates that, when S 21 arrives at Vertex E, the A 1 E,r j , A 2 E,r j , A 3 E,r j and A 4 E,r j are compared with A 21 E,r j , respectively. As illustrated in Figure 23, the result of comparisons is that A 1 E,r j < A 21 E,r j , then S 1 is substituted by S 21 . (3) Using storage capacity of an adjacent idle CR. If all the Interest frequency of cached data packets in Vertex E (A 1 E,r j , A 2 E,r j , A 3 E,r j and A 4 E,r j ) are bigger than A 21 E,r j , S 21 is forwarded to Vertex E (Routing Path y in Figure 24). When S 21 is requested, the Vertex F sends S 21 to the user according to the Extra Storage (Routing Path y in Figure 25). The procedure of Algorithm 3 is also illustrated using an example, in which the assumptions and parameters are same as they are in Section 4.1.
(1) Pre-caching process. After performing uploading pre-caching for a period, due to the limitation of caching storage (four data packets), storage capacity of each CR has been filled, as Figure  20 demonstrates.
(2) Replacement of a data packet. At some time while the DP is conducting pre-caching, the data packet is assigned to Vertex E (Routing Path ② in Figure 21). Figure 22 demonstrates that, when arrives at Vertex E, the , , , , , and , are compared with , , respectively. As illustrated in Figure 23, the result of comparisons is that , < , , then is substituted by .
(3) Using storage capacity of an adjacent idle CR. If all the Interest frequency of cached data packets in Vertex E ( , , , , , and , ) are bigger than , , is forwarded to Vertex E (Routing Path ② in Figure 24). When is requested, the Vertex F sends to the user according to the Extra Storage (Routing Path ② in Figure 25)     The procedure of Algorithm 3 is also illustrated using an example, in which the assumptions and parameters are same as they are in Section 4.1.
(1) Pre-caching process. After performing uploading pre-caching for a period, due to the limitation of caching storage (four data packets), storage capacity of each CR has been filled, as Figure  20 demonstrates.
(2) Replacement of a data packet. At some time while the DP is conducting pre-caching, the data packet is assigned to Vertex E (Routing Path ② in Figure 21). Figure 22 demonstrates that, when arrives at Vertex E, the , , , , , and , are compared with , , respectively. As illustrated in Figure 23, the result of comparisons is that , < , , then is substituted by .
(3) Using storage capacity of an adjacent idle CR. If all the Interest frequency of cached data packets in Vertex E ( , , , , , and , ) are bigger than , , is forwarded to Vertex E (Routing Path ② in Figure 24). When is requested, the Vertex F sends to the user according to the Extra Storage (Routing Path ② in Figure 25)    is forwarded to Vertex E.

The Experimental Results and Analysis
In this section, extensive experiments were conducted and the performance of the CJSR scheme is evaluated under three different metrics. We made comparisons among two proposed schemes and five existing schemes: (1) Traditional NDN; (2) No Cache; (3) Probability Cache; (4) LCD; and (5) MCD. In the traditional NDN scheme, data packets are cached into each CR they have been forwarded. In contrast, CRs in the No Cache scheme can only forward packets. As for the probability Cache scheme, a CR will cache a data packet based on a predefined probability; the probability parameter is set to 0.5 in our experiments. The LCD and the MCD scheme share a similar idea which is to cache the data packet in the next vertex of the vertex where a cache hit occurs. However, in the latter scheme, the hit data cached in the CR where the cache hit takes place is deleted. Initially, the total hop counts are compared and analyzed in Section 5.1, which denotes the number of total hop counts of all the requested data packets. This criterion reflects the latency and is of critical importance to meet real-time requirement of many applications. Next, the number of processed packets on each CR along the caching path is evaluated in Section 5.2. The processed interest packets and the processed data packets denote the number of forwarded interest packets and incoming data packets respectively. Finally, comparisons of cache hits are made in Section 5.3.
After analyzing the experiment results, we have concluded that for the optimization targets Equations (1)-(3), the proposed mechanism guaranteed high performance in terms of the amount of processed packets, cache hits and total hop counts. High performance of these metrics above would contribute to a high QoS for users.
To test the proposed CJSR scheme under various scenarios, a topology deployed with 88 Content Routers ( Figure 26) is produced for the experiments. The dotted lines denote that Users 2-12 are connected to different CRs in various scenarios. As shown in Figure 27, another larger topology (113 Content Routers) is generated for Scenario 6. Overall, to evaluate the uploading pre-caching of the CJSR scheme, all of the scenarios assume the following: (i) When users request data, their interested data have not been uploaded yet, so the first kind of shortcut is built between the DP and users; to focus on the routing between DPs and users, DCs are omitted in the topology. (ii) All the CRs are available and willing to cooperate. (iii) All users request successively and continuously.
Next, we discuss the design and configurations of the experiments. To test the network performance under various situations, six scenarios are designed. The detailed parameters and configurations can be found in Tables 2 and 3. Overall, the cache capacity is set to 250 so that each CR can accommodate 250 data packets, and the LRU replacement policy is used to replace old content in cache storage. In addition, each chunk has a Time-To-Live (TTL) to limit its lifespan if necessary. However, the configuration of TTL is highly application-dependent and the detailed evaluation on it

The Experimental Results and Analysis
In this section, extensive experiments were conducted and the performance of the CJSR scheme is evaluated under three different metrics. We made comparisons among two proposed schemes and five existing schemes: (1) Traditional NDN; (2) No Cache; (3) Probability Cache; (4) LCD; and (5) MCD. In the traditional NDN scheme, data packets are cached into each CR they have been forwarded. In contrast, CRs in the No Cache scheme can only forward packets. As for the probability Cache scheme, a CR will cache a data packet based on a predefined probability; the probability parameter is set to 0.5 in our experiments. The LCD and the MCD scheme share a similar idea which is to cache the data packet in the next vertex of the vertex where a cache hit occurs. However, in the latter scheme, the hit data cached in the CR where the cache hit takes place is deleted. Initially, the total hop counts are compared and analyzed in Section 5.1, which denotes the number of total hop counts of all the requested data packets. This criterion reflects the latency and is of critical importance to meet real-time requirement of many applications. Next, the number of processed packets on each CR along the caching path is evaluated in Section 5.2. The processed interest packets and the processed data packets denote the number of forwarded interest packets and incoming data packets respectively. Finally, comparisons of cache hits are made in Section 5.3.
After analyzing the experiment results, we have concluded that for the optimization targets Equations (1)-(3), the proposed mechanism guaranteed high performance in terms of the amount of processed packets, cache hits and total hop counts. High performance of these metrics above would contribute to a high QoS for users.
To test the proposed CJSR scheme under various scenarios, a topology deployed with 88 Content Routers ( Figure 26) is produced for the experiments. The dotted lines denote that Users 2-12 are connected to different CRs in various scenarios. As shown in Figure 27, another larger topology (113 Content Routers) is generated for Scenario 6. Overall, to evaluate the uploading pre-caching of the CJSR scheme, all of the scenarios assume the following: (i) When users request data, their interested data have not been uploaded yet, so the first kind of shortcut is built between the DP and users; to focus on the routing between DPs and users, DCs are omitted in the topology. (ii) All the CRs are available and willing to cooperate. (iii) All users request successively and continuously. is beyond the scope of this work. Hence, the TTL used in the experiments is set to be larger than 5 s (which is the time from a chunk is cached to it is replaced, so that each chunk remains stored in cache until it is replaced). The requested data contain 30,000 data packets, the interest frequency is 50 interests per second and simulation time is 10 min.   is beyond the scope of this work. Hence, the TTL used in the experiments is set to be larger than 5 s (which is the time from a chunk is cached to it is replaced, so that each chunk remains stored in cache until it is replaced). The requested data contain 30,000 data packets, the interest frequency is 50 interests per second and simulation time is 10 min.   Next, we discuss the design and configurations of the experiments. To test the network performance under various situations, six scenarios are designed. The detailed parameters and configurations can be found in Tables 2 and 3. Overall, the cache capacity is set to 250 so that each CR can accommodate 250 data packets, and the LRU replacement policy is used to replace old content in cache storage. In addition, each chunk has a Time-To-Live (TTL) to limit its lifespan if necessary. However, the configuration of TTL is highly application-dependent and the detailed evaluation on it is beyond the scope of this work. Hence, the TTL used in the experiments is set to be larger than 5 s (which is the time from a chunk is cached to it is replaced, so that each chunk remains stored in cache until it is replaced). The requested data contain 30,000 data packets, the interest frequency is 50 interests per second and simulation time is 10 min.  Scenario 1: In this scenario, one user is deployed. Experiment results reveal that most of interest packets are processed by intermediary CRs. However, the amount of processed data only had a slight decline because the assignments of data would produce some traffic. However, when more than one user request the same data, as in Scenario 3, the traffic of data packets would decline because data assignments only have to occur once, then only the transmission of data packets from CR holding the requested packets to users would produce some traffic. Scenario 2: User 1 and User 2 request same data from DP 1. User 2 starts to request one second later than User 1. Requesting later, User 2 can directly benefit from the cached data. In the beginning of the second round pre-caching, while User 2 requests S 3949 to S 3999 , those data packets have just been replaced by the assigned data from User 1 (S 4000 to S 4049 ) prior to User 2's request. Therefore, User 2 has to send I 3949 to I 3999 to the DP. Similarly, User 2 s requests have to be forwarded to the DP in the remaining rounds (the whole process consists of eight rounds of pre-caching). In contrast, however, the request of replaced data from User 2 (S 3949 to S 3999 , S 7949 to S 7999 etc.) from User 2 can be satisfied in the ICIP scheme due to the involvement of idle CRs. Because each user requests consecutive data, the interest frequency of data packets are same. As a result, when the assigned data from User 1 arrives at CR13, no replacement occurs and CR13 forwards newly arriving data packets (e.g., S 4000 to S 4049 ) to an idle CR. When User 2 requests S 3949 to S 3999 , his interest can still be satisfied. Nevertheless, if User 2 starts to request five seconds later, which is the time that cache replacements occur, User 2 cannot benefit from cached data at all. Scenario 3: Twelve users (Users 1-12) request same data from DP1. After the first user discovers data relevant to breaking news, same data may be requested by many users at the same time. This scenario depicts such a situation and Users 2-12 are started at the same time one second latter than User 1. In this scenario Caching Path 2 is choose to evaluate performance. Scenario 4: Two users request different data from two DPs. In this scenario, users conduct their own caching schemes separately. Nevertheless, when the CJSR and the ICIP schemes are applied, the caching paths of two users may overlap because the form of caching path is the travelled path of the interest that triggers the pre-caching. As shown in Figure 26, the two caching paths overlapped at CR 98; as a result, the overlapped CR has to undergo more traffic burden. The overlap would also have negative influence for the CJSR scheme. In each round of pre-caching, the data packets assigned to the CR 98 are replaced by each other, so that interest packets cannot be satisfied by CR 98; then they are forwarded to the DP; and LCE cache policy is used for the remaining data which could have been satisfied by the CR 98 if there were only one user. Following that, all the cached data of CRs along the caching path was replaced due to those requests. For instance, in the first round, S 0 to S 3499 from User 1 and User 2 are satisfied by assigned data. Next, I 3499 to I 3749 have to be sent to the DP, and all the cached data packets of CRs along the caching path are replaced by S 3499 to S 3749 because they are sent back using LCE policy. Then, the remaining requests of first round (I 3749 to I 3999 ) have to be sent to the DP. Therefore the overlapped CR has a negative impact on the CJSR scheme, however, the ICIP scheme is not influenced. Conversely, during the data assignments of the ICIP scheme, the conflicts of data replacement are solved by the involvement of an idle CR. Thus, both users enjoy assigned data throughout each entire round. Caching Path 2 is used to demonstrate results.
Scenario 5: User 1 and User 2 request same data from DP 1 while User 3 and User 4 are requesting same data from DP 2. User 1 as well as User 3 start to request at the same time, then User 2 and User 4 are started one second later. Similar to Scenario 4, the rest of interest packets are forwarded to the DP from the moment their interest packet arrives at CR 98. Scenario 6: To comprehensively test the proposed algorithms, another topology is used in this scenario as shown in Figure 27. In addition, there are six DPs producing various data for six users. While the CJSR scheme is conducted, six caching paths are built separately. Similar to Scenario 4, sometimes caching paths overlap and the CJSR scheme would not perform as good as it does in other scenarios due to the conflicts of data replacement. However, those conflicts have no impact on the ICIP scheme. Finally, Caching Paths 3, 4 and 6 are chosen to depict the experimental result because they represent different length and two of them contain CRs that shared by multiple caching paths.

Delay Analysis
As shown in the Figures 28-35, the given bar charts illustrate that the CJSR scheme reacts to user's request swiftly and the total hop counts of User 1 has reduced 51.6% compared with that of other schemes. According to Figures 29, 30 and 32, when there are more than one users, User 2 s total counts of the traditional NDN outperformed proposed schemes because User 2 s requests are satisfied by ξ r 1 (CR13) which has one hop count to the users. With lower total hop counts, high QoS could be guaranteed and the optimization objective of Equation (2) is achieved.
user's request swiftly and the total hop counts of User 1 has reduced 51.6% compared with that of other schemes. According to Figures 29,30 and 32,when there are more than one users, User 2′s total counts of the traditional NDN outperformed proposed schemes because User 2′s requests are satisfied by (CR13) which has one hop count to the users. With lower total hop counts, high QoS could be guaranteed and the optimization objective of Equation (2) is achieved.

Packets Processed Analysis
Figures 36-51 demonstrate the overall traffic of each scheme. The comparisons are made among the number of processed interest packets and data packets of CRs along the caching path. Generally, the traffic burden of the network saw a significant decline after conducting the CJSR scheme. The existing schemes have similar high amount of processed packets, every produced packet has to be processed if there is only one user, and this would inevitably result in high burden on each vertex. Conversely, the processed packets in the proposed schemes are considerably lower, only a small proportion of total produced packets have to be processed. As shown in Figures 36 and 44, the traffic of interest packets had a noticeable drop after conducting pre-caching. The ladder-shaped lines in Figure 36 clearly demonstrate that the vast majority of interest packets are processed by intermediary CRs. The chief reason is that in our schemes, the interest packets only need to flow to the CRs which have cached the requested data. As a result, the introduction of the CJSR scheme could reduce the number of processed interest and data packets on each vertex. Thereafter, the release of traffic burden leads to better User experience. It is also noticeable that the traditional NDN scheme and the Probability Cache scheme nearly perform as bad as No Cache scheme.
In conclusion, vertices that are closer to the user usually had been accessed more frequently in the CJSR scheme and the ICIP scheme, while the burden for the other three schemes is high and remain unchanged as the hop counts get larger. Seen together, the line charts reveal that, in our  Generally, the traffic burden of the network saw a significant decline after conducting the CJSR scheme. The existing schemes have similar high amount of processed packets, every produced packet has to be processed if there is only one user, and this would inevitably result in high burden on each vertex. Conversely, the processed packets in the proposed schemes are considerably lower, only a small proportion of total produced packets have to be processed. As shown in Figures 36 and 44, the traffic of interest packets had a noticeable drop after conducting pre-caching. The ladder-shaped lines in Figure 36 clearly demonstrate that the vast majority of interest packets are processed by intermediary CRs. The chief reason is that in our schemes, the interest packets only need to flow to the CRs which have cached the requested data. As a result, the introduction of the CJSR scheme could reduce the number of processed interest and data packets on each vertex. Thereafter, the release of traffic burden leads to better User experience. It is also noticeable that the traditional NDN scheme and the Probability Cache scheme nearly perform as bad as No Cache scheme.

Packets Processed Analysis
In conclusion, vertices that are closer to the user usually had been accessed more frequently in the CJSR scheme and the ICIP scheme, while the burden for the other three schemes is high and remain unchanged as the hop counts get larger. Seen together, the line charts reveal that, in our schemes, the burden of DP or DC was partially taken by CRs. As a result, the burden of dealing with endless packets are reduced and the users get better QoS. The reason is that, in the proposed schemes, interest packets only have to be forwarded to CRs with the corresponding data packets cached. On the contrary, the remaining schemes always have higher number of access because that interest packets have to be forwarded by each CR because data packets are not providently cached for user to fetch.                                            Figure 51. The number of processed data packets of each CR along Caching Path 6 in Scenario 6.

Cache Hits Analysis
Comparisons between our schemes and the existing caching strategies are depicted in Figures  52-59. Figure 52 demonstrates that proposed schemes' cache hits noticeably outnumber the remaining policies. As illustrated in Figures 53, 54 Figure 51. The number of processed data packets of each CR along Caching Path 6 in Scenario 6.

Cache Hits Analysis
Comparisons between our schemes and the existing caching strategies are depicted in Figures  52-59. Figure 52 demonstrates that proposed schemes' cache hits noticeably outnumber the remaining policies. As illustrated in Figures 53, 54

Cache Hits Analysis
Comparisons between our schemes and the existing caching strategies are depicted in Figures 52-59. Figure 52 demonstrates that proposed schemes' cache hits noticeably outnumber the remaining policies. As illustrated in Figures 53, 54 and 56, all the cache hits of the traditional NDN scheme occurred at ξ r 1 (CR 13) and all of cache hits of the LCD and MCD schemes took place at ξ p i (CR 108). Figures 57-59 also show that all the CRs along the P cache have high cache hits because latter requests from the same user could benefit from providently cached data. As for the other schemes which have no cache hits at all, each CR only forwards packets. Because data packets are cached to CRs near the users intelligently. Due the involvement of idle CR, the conflicts of data replacement are solved. Thus, cache hits occurred throughout each entire caching path in the ICIP scheme. On the contrary, the DP in the remaining schemes only start to generate data packets when an interest packet is received, then the DP forwards the requested data to users in a time-consuming way.
cached to CRs near the users intelligently. Due the involvement of idle CR, the conflicts of data replacement are solved. Thus, cache hits occurred throughout each entire caching path in the ICIP scheme. On the contrary, the DP in the remaining schemes only start to generate data packets when an interest packet is received, then the DP forwards the requested data to users in a time-consuming way.   replacement are solved. Thus, cache hits occurred throughout each entire caching path in the ICIP scheme. On the contrary, the DP in the remaining schemes only start to generate data packets when an interest packet is received, then the DP forwards the requested data to users in a time-consuming way.                 Figure 59. The number of cache hits on each CR along Caching Path 6 in Scenario 6.

Conclusions and Future Works
With rapid advances in the manufacturing of sensing devices, the number of data produced by ubiquitous sensing devices grows exponentially and causes heavy burden on the whole network. Aiming to minimize the hop counts for users to obtain data, reduce delay and release traffic burden, a CJSR scheme is proposed in this paper. The overall length of routing paths is reduced by using two shortcut routing methods. Furthermore, a cooperative pre-caching is proposed to decrease delay and traffic burden. One such scheme is also applicable to different situations. If the requested data have   Figure 59. The number of cache hits on each CR along Caching Path 6 in Scenario 6.

Conclusions and Future Works
With rapid advances in the manufacturing of sensing devices, the number of data produced by ubiquitous sensing devices grows exponentially and causes heavy burden on the whole network. Aiming to minimize the hop counts for users to obtain data, reduce delay and release traffic burden, a CJSR scheme is proposed in this paper. The overall length of routing paths is reduced by using two shortcut routing methods. Furthermore, a cooperative pre-caching is proposed to decrease delay and traffic burden. One such scheme is also applicable to different situations. If the requested data have not been uploaded, users would directly request from DPs and trigger uploading pre-caching. If the

Conclusions and Future Works
With rapid advances in the manufacturing of sensing devices, the number of data produced by ubiquitous sensing devices grows exponentially and causes heavy burden on the whole network. Aiming to minimize the hop counts for users to obtain data, reduce delay and release traffic burden, a CJSR scheme is proposed in this paper. The overall length of routing paths is reduced by using two shortcut routing methods. Furthermore, a cooperative pre-caching is proposed to decrease delay and traffic burden. One such scheme is also applicable to different situations. If the requested data have not been uploaded, users would directly request from DPs and trigger uploading pre-caching. If the data have already been uploaded, DCs would perform downloading pre-caching. The cooperative pre-caching would cache data providently into nearby CRs, thus users can directly fetch their interested data from CRs. Since the data can be found in intermediary CRs, the interest packets requesting for data are processed by CRs with the corresponding data cached. Therefore, compared with the traditional NDN scheme, the CJSR scheme could reduce the total number of processed interest packets by 54.8%, enhance the cache hits of each CR and reduce the number of total hop counts by 51.6%. As a result, the traffic burden of both data packets and interest packets is released and the QoS is ameliorated. Using the two methods of shortcut routing, the overall length of routing paths could be cut down by 28.6-85.7%. Moreover, the length of uploading routing path could be decreased by 8.3-33.3%.
With further research on relevant topics and underlying mechanisms involved in the CJSR scheme, namely, replacement approaches and data-freshness, the CJSR scheme could be partially improved. Possible future works include: (i) implementing and evaluating impacts of various replacement policies on the proposed schemes using similar measure as [60]; (ii) designing an adaptive mechanism that could adjust data packets' TTL under various circumstances; and (iii) generating experimental evidence of the impacts on the actions caused by modifying TLV values in messages and improving the statistical analysis under heavier traffic pressure.
Author Contributions: B.H. designed the algorithms and wrote part of the manuscript. A.L. conceived of the work, designed the algorithms, and wrote part of the manuscript. C.Z., N.X., Z.Z. and Z.C. commented on the paper.