Cooperative Coding and Caching for Streaming Data in Multihop Wireless Networks

. This paper studies the distributed caching managements for the current ﬂourish of the streaming applications in multihop wireless networks. Many caching managements to date use randomized network coding approach, which provides an elegant solution for ubiquitous data accesses in such systems. However, the encoding, essentially a combination operation, makes the coded data di ﬃ cult to be changed. In particular, to accommodate new data, the system may have to ﬁrst decode all the combined data segments, remove some unimportant ones, and then reencode the data segments again. This procedure is clearly expensive for continuously evolving data storage. As such, we introduce a novel Cooperative Coding and Caching ( C 3 ) scheme, which allows decoding-free data removal through a triangle-like codeword organization. Its decoding performance is very close to the conventional network coding with only a sublinear overhead. Our scheme o ﬀ ers a promising solution to the caching management for streaming data.


Introduction
Multihop wireless networks as wideband Internet access solutions have been widely researched nowadays, and promote some real deployments for communities [1][2][3][4].Since then, the requirement for supporting streaming applications in such infrastructures becomes more and more imperative [5,6].Path caching is a common used technology in wired networks for delivering media streaming efficiently, which can reduce the client-perceived access delays as well as server/network loads [7].In the wireless paradigm, for the broadcast nature of wireless transmission, it is more direct and intuitive to cache streaming data on the way.Many works have been done to exploit the caching benefits in multihop wireless networks [8][9][10].
In the caching-enhanced multihop wireless networks, single wireless node usually has limited space for caching and can only save part of streaming data.It is common for a client to fetch data segments from multiple relay nodes.In this way, the caching-enhanced multihop wireless networks as a whole can be treated as distributed storage systems.However, previous works spend little attentions to the caching management, and data are unevenly distributed in the networks.Usually, a sophisticated caching searching algorithm is needed [10].Recently, network coding, in particular, random linear coding, has been suggested as an elegant solution for distributed storage managements [11][12][13].In a network-coding-based storage system, the original data segments (say N) are combined through linear operations with independent coefficient vectors.The combined data segments are of the same size as the original segments and are equivalent in decodability.Each relay node can therefore record a subset of the combined data segments, and a client is able to decode all the original data segments as long as N combined data segments are retrieved.
This combination process however makes the caching storage inflexible to change.More explicitly, since media data are usually coded as different important segments before transmission for providing scalable streaming abilities [14], if unimportant data segments are to be removed to accommodate new data, the system needs to first decode all the data segments, remove the unimportant ones, and then re-encode the data segments again.This operation is timeand resource consuming [15].Even worse, given that a node can only store a partial set of the data segments, it is generally impossible for each single node to carry out the decoding operation.
To effectively solve this problem, we introduce a novel Cooperative Coding and Caching (C 3 ) scheme.C 3 extends the conventional random network coding [16], and enables decoding-free data removal through a triangle-like codeword organization.Its decoding performance matches that of the conventional network coding with only a sublinear overhead.It also enables retrieval of only a subset of the data.As such, it offers a promising solution to the caching management of streaming data in multihop wireless networks.
In this paper, we present the theoretical foundations of C 3 and a set of general rules for applying C 3 in the caching management.We then demonstrate the actual benefits of C 3 for streaming applications in multihop wireless networks.Again, we show that, while conventional network coding is capable to achieve high throughput, it cannot easily manage streaming data.
The remainder of the paper is organized as follows.We first present the system model, and demonstrate the superiority and problems when directly applying network coding to the system in Section 2. In Section 3, we offer the theoretical foundations of cooperative coding and caching.We discuss the design issues of C 3 -based cache management in Section 4. Our preliminary simulation results are shown in Section 5.In Section 6, we discuss the related work.Finally, Section 7 concludes the paper and presents some future directions.

Model and Notation.
We now give the a formal description of the system.Our caching model is quite similar with the caching model of Ditto [9].The main difference is that we apply our novel coding schema to manage cached data.
We consider a multihop wireless network of N nodes, each with a buffer of size B. Assume that we only want to cache totally N data segments for one session for the limited caching space.In general, we have N > B, that is, no single node can store all the data of a session.A media server located in the Internet which can be accessed by the clients of the multihop wireless network through gateway (GW).Media files are split into equally sized data segments.When a media file is first requested, there is no information about the media file in the network before; then the request will be sent to the Internet media server directly.A second or later requests will benefit from previous transmissions through caching.Requesting for the same media file in a community is a quite common user behavior as suggested by recent progresses in the traffic analysis and social networks.Wireless node in the network will cache all successfully received data segments.
Data segment receiving can happen either when the node is on the routing path or when it is beside the path but can overhear the transmission.The system is continuously evolving with new streaming data coming and existing data being obsolete, though the total number of useful data segments is always N.
Since user requests are probably random from all parts of the wireless network, it is reasonable to assume that data segments are randomly distributed inside the network.We do not assume any indexing service (no matter centralized or distributed) in the network.For a client to retrieve the N data segments stored in the wireless network, it will simply broadcast the request to the nearest M neighbor nodes, which are not necessarily exactly nearest for performance tradeoff.It can be easily realized by sending out M requests and one request can be processed by only one node.Every node has a proxy module just like what they have in the study by Ditto.Every proxy can serve the data to its previous hop, either from its local cache or by requesting it from its nexthop proxy [9].Without loss of generality, we assume that each node will provide one data segment from its storage space.Clearly, to obtain all the N data segments, we must have M ≥ N, and even so, not all the data segments are necessarily obtained in such kind of retrieving scheme.Therefore, we define a success ratio, which serves as the major evaluation criterion in our study, as follows Definition 1 (success ratio).The success ratio is the probability that a data retrieval scheme successfully retrieves all the N data segments.The default settings of M and B are M = N and B = 1, which are their lower bounds for valid schemes.

Network-Coding-Based
Caching: Superiority and Problems.We now show that network coding, in particular, random linear coding, can significantly improve the success ratio over a codingless caching system.With random linear coding, all data segments are stored in a combined fashion.More specifically, assume that the original data segments are c j , j = 1, 2, . . ., N; a coded data segment f i (also referred to as a combined data segment) is generated as N−1 j=0 β j × c j , where β = (β 0 , β 1 , . . ., β N−1 ) is a coefficient vector, each item of which is randomly generated from a finite field F q .It is worth noting that the size of each f i remains equal to c j .We define the cardinality of f i to be the number of original data segments it contains, and the full cardinality of the system is the highest possible number, that is, N.
To obtain the N original data segments, one can simply collect any N combined data segments and then decode through solving a set of linear equations.Here, a necessary condition for successful decoding is that the coefficient vectors must be linearly independent.This is generally true if the coefficient is generated from a large enough field size q [12].As shown in [17], the probability of linear independency is over 99.6% for q = 2 8 , and this is almost independent of N. As such, for the network-coding-based data storage and collection scheme, the success ratio with M = N and B = 1 is close to 100%.
Besides the combined data segments, the coefficient vectors also have to be collected by the client for decoding.Such overheads, generally of a few bytes, are much lower than the data volume, and the benefit of network coding thus well dominates these costs.
Unfortunately, while in conventional network coding it is easy to combine new data segments to existing data segments and increase the cardinality, the reverse operation is very difficult.Specifically, to remove an original data segment, we have to first decode the combined data segments, remove the unnecessary original data segments, and then recombine the remaining data segments.This is time and resource consuming.Even worse, it is often impossible to perform these operations in a single node given that B < N, as decoding requires N combined data segments.
As such, for the streaming application in multihop wireless networks, caching storage systems are continuously evolving; if we keep unimportant or obsolete data segments in the system, then the clients have to download more and more unnecessary data segments to successfully decode the expected useful data segments.Eventually, the buffer will overflow, and the system simply crashes.This becomes a key deficiency for applying conventional network coding in continuous data management.A related problem is that network coding has no flexibility in retrieving partial data sets only, for example, a set of the most important m original data segments that comprise the most important frames of a media file, where m < N.

Cooperative Coding and Caching: Basic Idea
In this section, we show a new coding scheme that conveniently solves the problem of data removal, thus facilitating caching management for streaming data.Our coding scheme enables the combination of only part of the original data segments, and we refer to it as Cooperative Coding and Caching (C 3 ); compre for example Network Coding (NC) and no coding at all (Non-NC ).

Overview of Cooperative Coding and Caching
3.1.1.Code words.In C 3 , instead of having full cardinality only, the combined data segments may have different cardinalities, from 1 to N. In addition, for each original data segment c i , where i denotes the time sequence, there is a weight w i associated to this data.The definition of weight in our streaming application combines the time stamp of the data segment and its relative importance to the media playback performance.Figure 1 shows an example of our weight assignment schema for a video clip.In the figure, data segments are classified into I, P, B three categories, which correspond to the I-frame, P-frame, and B-frame of the video to be streamed.Generally speaking, I-frame is the most important data for video playback, then the Pframe, and then the B-frame.So, in a batch, data segments corresponding to the I-frame are assigned with the highest weights.It is worth noting that the weight assignment schema can be application specific, and our C 3 solution can be applied to all kinds of weight definitions which respect the following constraint.The only constraint is an operator , which should follow the following.(1) (Transitive) for any w i , w j , w k , if w i w j and w j w k , then w i w k ; and (2) for every w i , w j , either w i w j or w i ≺ w j .We have the following convention in this paper: w j w j if j > j and we say that the weight of c j is higher than c j if j > j , and c j is a more recent data segment than that c j if j > j .For simplicity, we will use only the subscript or superscript for a data segment if the context is clear.Thus, for a data segment with weight index i and time index j, we use c i .= c j to denote that they are the same data segment, that is, We omit β j in the following and use for ease of exposition.The coding base for N = 4 is illustrated in Figure 2. The storage for each node is Intuitively, each node stores a few combined data segments selected from the coding base B.
Notice that, if k denotes the cardinality of a combined data segment, then the cardinality of f k can be calculated by We may drop the superscript and use f i provided that k is clear in the context to represent the ith combined data segment in this node.
A salient feature of this triangle-like coding scheme is the decoding-free data removal; that is, to remove the current least important original data segment c 0 in the system, we can simply drop the combined data segments containing c 0 .Intuitively, c 0 is included in the combined data segments with the highest cardinality.The amount of these combined data segments consists of only a fraction of the combined data segments in the system and a removal of them will not adversely affect the success ratio of the system (recall that, with conventional network coding, all combined data segments have to be deleted in this case).Figure 3 illustrates a concrete example, where the new data segment c 4 is to replace data segment c 0 .To simplify our example, we assume that c 4 .= c 4 , that is, c 4 also has the highest weight.We see that, after data replacement, all f = [c 3 , c 2 , c 1 , c 0 ] are replaced by f = [c 4 ], and the cardinalities of other combined data segments increase by one.This data replacement operation is decoding free and the system remains stable.A general observation can be drawn as follows.
Observation 1.For original data segments c i and c j , where i > j (i.e., w i w j ), c i will be deleted no earlier than c j from the system.This is true irrespective to any data removing scheme.
Once we have data cached in the wireless subnet, two kinds of data request routing protocols can be applied depending on whether the data segments have been cached or not.First, when the requested segments can be retrieved inside the wireless network, then m data requests will be broadcasted to its neighbors.Every neighbor can only reply to one request, and has to decide whether to forward the request or just reply to it depending on its history record.Second, when the requested segments cannot be retrieved inside the wireless network, any unicast routing protocol in multihop wireless network can be used.We use the OSLR routing protocol in our model in this case.Though nodes on the route will cooperatively cache data segments when the traffic comes from outside of the wireless network, they will only respond to data requests on demand of the sink node.And packets will travel along the reverse route path of the request.

Distribution of Cardinality.
Cooperative coding and caching intrinsically manages the shape (i.e., cardinality) of the combined data segments.It is not difficult to see that, for a client retrieval, if the contacted nodes provide combined data segments with high cardinalities, then the success ratio will be higher.We summarize this in the following two observations.Observation 2. The success ratio is maximized if every node provides the client the combined data segment with the highest cardinality from its buffer.Observation 3. Consider time instances t 1 and t 2 .If at t 1 the probability for each node to provide high-cardinality data segments is greater than at t 2 , then success ratio for a data retrieval at t 1 is higher than that at t 2 .
Generally speaking, in each particular time instance, it is ideal for the system to have combined data segments of cardinalities as high as possible.In an extreme case, if all the combined data segments in the system have cardinality N, the success ratio is 100% but the system is essentially reduced (a) C 3 before using c 4 to replace c 0 (b) C 3 after using c 4 to replace c 0 Figure 3: Data cached in 6 wireless nodes (s 0 through s 5 ) each with two buffer units.We omit the coefficients for each combined data segment for ease of exposition; however, it should be known that f 0 ∈ s 0 is not the same as f 0 ∈ s 4 as they are coded with different coefficient vectors.(a) shows C 3 before insertion of c 4 , and (b) shows C 3 after the insertion of c 4 and removal of c 0 .After this data replacement operation, the system is fairly stable in terms of the cardinalities of the combined data segments.
to the case of conventional network coding.Once a new data segment arrives, all the combined data segments will have to be deleted to make room for the new segment.For subsequent client retrievals, no data segment but the newest one can be answered.
As said, client requests could come from any part of the wireless networks, so it is reasonable to assume that cached data are uniform distributed inside the network storage.We now consider the performance of C 3 with a uniform cardinality distribution throughout the lifetime of the system.This distribution does not favor data arrivals or client retrieval at any particular time, and can serve as a baseline for further application-specific optimizations. 3 .With the uniform distribution, we can focus on the success ratio of a single client data retrieval.Since the cardinality of each data segment is not necessarily N in C 3 , it is possible that the success ratio is less than 100%.Let B = 1 for each node and the success ratio for obtaining i data segments by collecting i data segments using C 3 be F(i).We quantify the success ratio in this scenario as follows.

Performance Analysis of C
Theorem 2. Define F(0) = 1, then the success ratio Proof.The basic idea of our proof is to find the sets of combined data segments that are decodable, referred to as valid sets.For example, a set of combined data segments with cardinality 1 through N are decodable, and the set of combined data segments with all cardinalities being 1 is not decodable.The success ratio is given by the number of valid sets over the total number of possible sets of combined data segments; the latter is N N .A valid set can be constructed as follows: pick N − i combined data segments of cardinality N and i combined data segments with cardinality less or equal to i.These i combined data segments should be a valid set (decode-able) in terms of i.For example, if N = 4, a valid set may consist of two combined data segments of cardinality 4 and two combined data segments with cardinality less than or equal to 2. The number of the latter is F(i)i i .Since the retrieval can be of any sequence,we need to fit all these combined data segments into N pickup sequences.For those N −i combined data segments with cardinality N, there are N N−i locations to fit in.Notice that we do not need to shuffle the i combined data segments with smaller cardinalities as F(i)i i has already contained all possible shuffles.Therefore, the total number of valid sets is , and the theorem follows.
We further derive an upper bound and lower bound for C 3 .Theorem 3. The upper and lower bounds of the success ratio are 1 − ((N − i)/N) N and N−1 i=0 ((N − i)/N), respectively.
Proof.The success ratio is upper bounded by successfully obtaining the combined data segments with the highest cardinality.This probability is 1/N due to the uniform distribution.The probability of not getting it in N picks is ((N − i)/N) N , giving an upper bound 1 − ((N − i)/N) N .The success ratio of getting a set of combined data segment with cardinality 1 through N is (1/N) N N!, which is equal to N−1 i=0 ((N − i)/N).This is clearly a lower bound.
For comparison, we also calculate the success ratio of Non-NC, as follows.
Observation 4. If the distribution of the data segments is uniform, the success ratio for obtaining all N data segments by randomly collecting N data segments (Non-NC) is A preliminary comparison of the success ratios can be found in Figure 4. Detailed comparisons as well as practical enhancements which substantially improve the success ratio will be presented in the following sections.
The probabilistic nature of success ratio only provides us a rough idea of how many combined data segments should be retrieved.If decoding cannot be carried out after retrieving a certain number of combined data segments, then the clients have to retrieve additional data segments.This may not be acceptable for delay-sensitive applications.An ideal case is thus to inform the client of exactly how many combined data segments should be retrieved so that they are guaranteed to decode out the necessary information.Before we give a concrete solution, we first illustrate the basic idea to achieve this.As shown in Observation 2, if each node sends a combined data segment with the highest cardinality in its buffer, the success ratio will be improved.In addition, if a node can always provide a combined data segment that has sufficiently high cardinality, then the success ratio will also be improved.We quantify these observations as follows.For each node, if it has a buffer size of √ N + 1, then it is able to store the data segments with cardinality starting from 1 to N + √ N, that is, the cardinality difference of f i and f i+1 is Proof.A rigorous proof can be found in [18].This theorem shows that the success ratio of C 3 is identical with NC, with only a sublinear sacrifice of buffer size and retrieval cost.Yet it achieves continuous data management.This theorem also gives us important information; that is, to improve the success ratio of C 3 , it is also important to have a balanced cardinality distribution within each single node, as each node is able to provide a combined data segment with fairly high cardinality at any time.

Maintaining Uniform Distribution of Cardinality.
We have shown the performance of C 3 under a uniform cardinality distribution.It remains to show how a uniform distribution can be achieved and maintained in this dynamically evolving system.
At first, we need to initial the caching system to have uniform distributed cardinality.And this can be done easily in a centralized way.For example, we take the gateway node as the initialization control node.If there are P nodes in the network willing to cache the application data, then each of them will provide its reserved capacity to the gateway.Say that if we have B * P units for caching, then the gateway will use a random generator to uniformly distribute cardinality vector to each node.And the overhead could be very low, since we only have to send P packets, each of which has the payload of B * log 2 N bits.The overhead can be further decreased, if we piggyback those cardinality initialization vectors to some real data packets.After initialization, we will apply a simple data replacement strategy to maintain this uniformity.
Assume that a new data segment c i .= c j is generated to replace c 0 .Our data replace procedure is as follows.(1) Remove 4) Send f i to the nodes which just removed f 0 .duplicate additional f i to send if there are more nodes with f 0 .And finally (5) delete unnecessary f i if there are fewer nodes with f 0 to send.Theorem 5.If the cardinality is uniformly distributed, then after the above data replacement procedure, the distribution of the cardinality remains uniform, and the number of combined data segments stored in each node remains unchanged.
Proof.The above procedure uses the new combined data segment to replace the deleted f 0 .Therefore, the set of nodes which removed f 0 was refilled by f i .The set of nodes which duplicated combined data segment f i either sent this data segment out or discarded it.Thus, the number of combined data segments stored in each node is unchanged.
If the distribution of the cardinality is uniform, then the probability that a combined data segment has cardinality k is 1/N for all k = 1 . . .N. After the data replacement with new data segment c i , the probability of a combined data segment having cardinality 1 < k < i remains unchanged.The probability of a combined data segment having cardinality i is the same as that having cardinality N before data replacement, which is 1/N.The probability of a combined data segment having cardinality i + k, 1 ≤ k ≤ N − i is the same as that having cardinality i + k + 1 before data replacement, which again is 1/N.Thus the distribution of cardinality remains uniform.
Depending on applications, one may choose other, maybe simpler, data replacement schemes to maintain the uniformity.For example, if the new data segment is always the one with the highest weight, then new data segment can Algorithm Data Replacement (c j ) c j : new data segment; estimate w(c j ); Algorithm 1: Pseudocode for data replacement.
automatically replace f 0 and no transmission is necessary (see the example in Figure 3).
We have yet to show how the uniform/balanced cardinality in each node can be maintained.In a naive case, the nodes just exchange the combined data segments with others to make their cardinality balanced.This introduces high transmission overhead.Although in some applications the paramount objective is high success ratio for each client access [13], we will show some optimization schemes to substantially reduce this overhead in the next section.

C 3 for Caching Management
We now detail the caching management through C 3 in multihop wireless networks.The management behavior mainly contains two operations: one is the data replacement, and the other is the data retrieval.

Data Replacement.
When a new data segment c j is successfully received by a node, the node will perform the data replacement algorithm, as shown in Algorithm 1.This algorithm maintains the uniform distribution of cardinality in the entire network while replacing the less important original data segment by new data segment c j if there is no available space.
As mentioned previously, we need to distribute some combined data segments to balance the distribution of cardinality in node level.Consider that we need a strictly balanced distribution; that is, the cardinality difference between two neighboring combined data segments f i and f i+1 is strictly √ N in a node.Since combining the new data segment will make some of the data segments have a difference of √ N + 1, a naive scheme will have to adjust the data segments in the entire system.This overhead is incurred each time a new data segment arrives.To avoid it, we propose the following alternative scheme.
In this new strategy, a valid cardinality difference of f i and f i+1 is not strictly √ N, but in between (1/2) √ N and 2 √ N. Therefore, to balance the cardinality distribution in each node, we only need to transmit data segments in two scenarios given as follows.(1) If the cardinality difference between two combined data segments is greater than 2 √ N, then the node just needs to obtain one combined data segment that can fit in the gap from other node.And (2) if the cardinality difference between two combined data segments is less than (1/2) √ N, then the node just need to send out the data segment of cardinality in the middle.Since the cardinality difference of the data segments is doubled, if each node has a buffer size of 2 √ N, it is easy to redefine the cardinality difference and still guarantee that the cardinality difference in each node is at most √ N using the new scheme.Formally speaking, we have the following.(2) Probabilistic Service.The client sends retrieval request message to m nodes.This request message includes the type of service (probabilistic service).The nodes queried will send back combined data segment with cardinality no less than m.While downloading the combined data segments, the client simultaneously performs decoding operations.If it cannot decode out the original data segments, it will send additional requests to other nodes for additional combined data segments.This will help with optimizing the cost if there is no stringent delay requirement.

Simulation Results
In this section, we present our preliminary simulation results for C 3 -based caching data management.We deploy 1000 static wireless nodes in the system.The default number of data segments to be cached for a source is N = 50 and the default buffer size B allocated for that source is 1.We examine other possible values in our simulation as well.The linear equations in network coding are solved using the Gaussian Elimination [19], and the coefficient field is q = 2 8 , which can be efficiently implemented in a 8-bit or more advanced microprocessor [20].To mitigate  randomness, each data point in a figure is an average of 1000 independent experiments.
Figure 5 shows the success ratio as a function of the number of data segments retrieved (N).Not surprisingly, the success ratio increases when N increases for both C 3 and Non-NC, but the improvement C 3 is more substantial.For example, if 100 data segments are to be retrieved, the success ratio is about 80% for C 3 ; for Non-NC, after retrieving 200 data segments, the success ratio is still 40% only.
In our next experiment, the client will first randomly retrieve 50 data segments, and if some original data segments are missing (for Non-NC) or the combined data segments cannot be decoded (for C 3 ), then the client will send additional requests one by one, until all the 50 data segments are obtained by successful decoding.The results are shown in Figure 6.It is clear that C 3 outperforms Non-NC for different  N's.It can be seen that the number of data segment collected is linear with respect to the number of required data (N), but the slope for C 3 is much smaller.As a result, when N is greater than 50, the cost with Non-NC is 3 to 4 times higher than that with C 3 .
We then increase the buffer size from B = 1 to 2 and 3 to investigate its impact.We require the nodes to provide the data segment of the highest cardinality for each client access.By carefully managing the buffer of each node, the cardinality of the combined data segments each node could provide is no less than N/2 and 2N/3 for B = 2 and B = 3, respectively.The results are shown in Figure 7, where a buffer size expansion from 1 to 2 has a noticeable improvement in success ratio, and a buffer of 3 segments delivers almost optimal performance.This is not surprising because there is a higher degree of freedom for storing and uploading data in a larger buffer space.Notice that, on the contrary, the performance of Non-NC will not improve with the buffer size expansion as the nodes are unaware of which original data segments other nodes will provide to the client.
We further explore the impact of the cardinality N. In Figure 8, we depict the decoding ratio for different number of original data segments (N = 20, 50, and 100).The x-axis denotes the ratio between the number of data collected and the cardinality, that is, λ = M/N.We can see from Figure 8 that their differences are insignificant, and generally reduced when M increases.Recall that the performance of Non-NC decreases sharply when N increases, while NC is marginally affected by N only.These simulation results thus reaffirm that C 3 inherits the good scalability of NC.

Related Work
Proxy caching for media streaming over wired networks has been exploited for a long history [7].Nowadays, as the rapid development of multihop wireless networks such as wireless mesh networks [1], proxy caching for media streaming in  multihop wireless networks has also been discussed [7,9,10].Different caching mechanisms have been proposed.However, previous works seldom pay attention to the caching data management.This paper takes advantages of coding to facilitate the caching management for streaming data in multihop wireless networks.
Network coding was first introduced in [21] to improve multicast throughput.To maximize the benefit of network coding, the linear codes should be constructed carefully such that the output at each destination is solvable.Randomized network coding was introduced in [16], which adopts randomly generated coefficient vectors, thus making the calculation of alphabet decentralized.
There are numerous recent studies applying conventional network coding and/or random linear coding in piratical systems.Examples include network diagnosis [13], router buffer management [22], energy improvement in wireless networks [23], data gossiping [24], as well as data dissemination in sensor networks [11] and in peer-to-peer networks [15].
For storage systems, various erasure codes have long been employed [25,26].Yet most of them require a central server for code block calculation; random linear coding is thus suggested for distributed storage [12].A careful comparison between no coding, erasure codes, and random linear codes can be found in [12] as well.
While many of the studies have faced the problem of continuous data management, for example, in [20,22,27], their common solution is to cut the data flow in generations, that is, time periods, and combine all the original data segments in one generation.The length of a generation depends on the application and the choice is often experience based.
Our study on cooperative coding and caching extends the network coding design from a different aspect, namely, decoding-free data removal.We solve this problem by a novel triangle-like coding method, which largely inherits the power of network coding, and yet well matches the demands from continuous data management.While the cardinalitymaximized combination process in network coding is the major source that improves its efficiency, our results show that the opposite direction, encoding only partial set of data segments, is worth consideration as well.Our initial study on C 3 with an application on data collection in sensor networks was presented in [17].This paper extends [17] in the following aspects.First, we introduce the weight factor for the original data segments.This offers great flexibility in managing nonhomogeneous data, and in particular, data in a time series as shown in this paper.Second, this paper offers a more in-depth discussion on the effect of the cardinality distribution, which is an important factor for the system to evolve efficiently and effectively.Finally, we apply the C 3 in the caching management of streaming data in multihop wireless networks.

Conclusion and Future Work
In this paper, we introduced a novel solution for caching management of streaming data in multihop wireless networks, Cooperative Coding and Caching (C 3 ), which effectively solves the problem of removing obsolete information in coded data segments.The problem is a major deficiency of the conventional network coding.We provided general design guidelines for C 3 and presented a theoretical analysis of its performance.We then addressed a series of practical issues for applying C 3 in the streaming applications under multihop wireless networks.
Our C 3 offers a new look into the random linear combination process in conventional network coding.In network coding research, it is known that the higher the cardinality is, the more the benefits one may expect.Therefore, many existing schemes have focused on achieving a full cardinality in data combination.For example, the proposals in [11,12,15,24] generally increase the cardinality by combining as much data as possible in intermediate nodes and then forward to others.Our work on cooperative coding and caching, however, shows that the opposite direction is worth consideration as well.
Nevertheless, there are still many unsolved issues for C 3 .Theoretically, we suspect whether the overhead of √ N reaches the potential limit of C 3 ?Practically, we need more measurement works to examine the performance of C 3 , such as estimating the expected delay and buffering time for node that is sending the request.At least, considering the recent flourish of data streaming in numerous fields, we believe that C 3 may be applied in many related applications beyond caching management for steaming in wireless networks.

Figure 1 :
Figure 1: Demo of weight assignment for streaming data starting from w x .

Figure 2 :
Figure 2: An example of C 3 for N = 4 and weight w 3 w 2 w 1 w 0 .The time index is not shown in this example.

C 3 Figure 4 :
Figure 4: Success ratio as a function of N (in default value M = N and B = 1).

√NTheorem 4 .
for all i ∈ [0, √ N].Notice that we have extended the maximum cardinality of the system to N + √ N. At anytime the node can provide a data segment with cardinality in [N, N + √ N].Consequently, if the client queries N + √ N nodes, and each node provides its combined data segment with cardinality no less than N, there will be N + √ N linear equations with the rank of the coefficient matrix being at least N and at most N + √ N. Thus, the system can guarantee a successful decoding of all N original data segments.Formally speaking, we have the following.The success ratio of C 3 with B = √ N + 1 and M = N + √ N is identical to the success ratio of NC with B = 1 and M = N, that is, 100%.

Corollary 6 .√ N and 2 √N
Given a buffer space 2 √ N, and the number of nodes contacted to be N + √ N, C 3 with the new caching scheme in each node still achieves the same success ratio.The gaps of (1/2) are not unique.They can be generalized to (1/k) √ N and k √ N or other numbers depending on the buffer size on each node.In a practical heterogenous system, if O( √ N) buffer size cannot be guaranteed, several nodes can collaborate as a cluster to form a combined buffer and provide data segments with reasonably high cardinality.

4. 2 .
Partial Data Retrieval.While we have focused on retrieving N data segments, our C 3 is indeed flexible in retrieving a subset of the segments and with different quality of services.Specifically, for a client that wants to retrieve the most important m data segments (m ≤ N), there are two possible services available.(1) Guaranteed Service.The client contacts m + √ m nodes and send a request message to each of them.This request message includes the type of the service (guaranteed service) and m.Each queried node will send back a data segment with the highest cardinality no greater than m + √ m.

Figure 5 :
Figure 5: Success ratio as a function of M for C 3 and Non-NC.

Figure 6 :
Figure 6: Number of combined data segment retrieved as a function of N.

Figure 7 :
Figure 7: Success ratio as a function of M with different buffer size.

Figure 8 :
Figure 8: Success ratio as a function of λ = M/N.