Coded caching [1, 2, 3, 4, 5, 6] is a technique that can reduce the communication load or latency in data distribution via proactively storing part of data to users’ caches during off-peak traffic periods and thus transmitting less amount of data to users during peak traffic periods. The transmissions typically consist of two phases: placement (or prefetching) phase and delivery (or transmission) phase. In the placement phase, uncoded [1, 7, 8] or coded [9, 10, 11, 5, 12, 13, 14] partial contents are placed into each user’s cache without knowing the future requests. According to whether the users’ caches are coordinated or not in the placement phase, coded caching can be divided into centralized  and decentralized  settings, where the latter adopts independent and identical random prefetching strategies across caches. Since all users’ cached contents are coordinately placed in a deterministic way by the server, centralized coded caching shows a lower delivery rate than that of decentralized coded caching. Existing placement strategies in the centralized settings are categorized as uncoded and coded prefetching, respectively. Under coded prefetching, the storage resources of the caching network can be more efficiently utilized. Although such higher storage efficiency may be obtained at the cost of delivery rate increment, coded prefetching can achieve an improved trade-off between the (worst) delivery rate and the cache memory size than uncoded prefetching when the cache size is relatively small[11, 15].
A number of the centralized coded caching algorithms with coded prefetching have been proposed. In particular,  first proposed a coded prefetching scheme using binary-addition (XOR) codes for the point that each cache size is the inverse of the number of the users , i.e., . Then  proposed a coded prefetching scheme using a combination of rank metric codes and maximum distance separable (MDS) codes for cache-size points at , , which locate in the regime when each cache size is not greater than the total source-file size, i.e., with denoting the total file number. Later  showed that such codes used in  can be simply replaced by the XOR codes. It is shown that the rate-memory pair of  can be viewed as a special case of , and according to  the scheme in  can outperform that in  within the small cache-size regime when the total cache size of the network is less than the total source-file size, i.e., , where  proposed an uncoded prefetching scheme for cache-size points at , over based on  and is shown to be optimal in the regime when . Since coded prefetching can achieve better performance in small cache-size regime,  proposed a coded prefetching scheme for a cache-size point at and  proposed a coded prefetching scheme for more cache-size points at over . It is shown that  can include coded prefetching [10, 11] at and uncoded prefetching  at as special cases, and can further improve coded prefetching performance over such small cache-size regime [11, 15]. However, all the aforementioned coded prefetching schemes are only applicable to the one-user-per-cache network, where each user can only make a single request. To the best of our knowledge, there are few works considering coded prefetching for multiple requests. Note that [16, 17] investigated single-layer coded caching with multiple requests and [18, 19] investigated hierarchical coded caching with multiple requests, all of which address uniform requests for uncoded prefetching. Moreover,  focused on centralized hierarchical uncoded prefetching that can degenerate into [16, 17] with the same delivery rate, while  focused on decentralized hierarchical uncoded prefetching.
In this paper, we focus on centralized coded prefetching with small sum-size caches for arbitrary multiple requests per user in the regime when the total cache size is not greater than the total source-file size of the server. Consider a caching network consisting of one server and several groups of users, where each group has a common shared fixed-size cache with the size homogeneously allocated over different groups and each user in a user-group can make arbitrary multiple requests for the files stored in the server. The caching model can degenerate into existing coded prefetching [10, 11, 14, 12, 5, 15] when each user-group consists of only one user and makes a single request, but more generally we can consider arbitrary multiple requests for each user. Our model is motivated by FemtoCaching networks [20, 21] and cache-enabled small-cell networks [9, 22], where a number of homogeneous cache-enabled small-cell base stations receive data from a controlling macro base station via a cellular downlink, and each small-cell base station serves a group of users through its own local high-rate downlink. As a prefetching scheme does not depend on the specific requests of users and our paper focuses on the same cache-size regime with that of , we cache coded contents based on the prefetching scheme given in , where each file is broken into multiple fragments and each cache stores multiple coded packets each formed by XORing fragments from different files. Then an efficient file delivery scheme with explicit constructions by the server to meet the multi-requests of all user-groups is proposed. The delivery scheme is more complete and general than that of  such that each user in a group can request arbitrary multiple files. Specifically, the stored coded packets of each cache are classified into four types based on the composition of the file fragments encoded. A delivery strategy is developed by separately delivering part of each packet type first and then combinatorially delivering the remaining different packet types in the last stage. After that, the rate as well as the worst rate of the proposed delivery scheme are analyzed since under our delivery scheme we can not only calculate the worst delivery rate as usually provided by [16, 17, 18, 19] but also calculate the actual delivery rate for each group of specific multiple requests. We show that our caching model and delivery scheme can incorporate  as a very special case, which includes some cases of the coded[10, 11] and uncoded  prefetching as mentioned above. Moreover, for the special case of uniform requests and uncoded prefetching, we make a comparison with existing schemes [16, 17] at the same cache size point, and show that our approach can achieve a lower delivery rate. Finally, the performance of the proposed delivery scheme is numerically evaluated.
The remainder of this paper is organized as follows. In Section II, the cache network model is given and the coded prefetching scheme is described. In Sections III, the delivery scheme is proposed. In Section IV, we provide the analyses on the delivery rate and worst delivery rate for the proposed delivery scheme. Numerical results are provided in Section V. Finally, Section VI concludes the paper.
Ii-a System Description
Consider a centralized cache network as shown in Fig. 1, which consists of one server and several groups of users each sharing a common equal-size cache. This network is characterized by parameters as follows:
The server has a database of unit-size files . Denote the file index set by .
There are groups of users connected to the server via a shared error-free link . Denote the user-group index set by . Each user-group requests files from the server with the assistance of its shared cache.
Let denote the sum of all user-groups’ distinct request numbers, which satisfies . Assume user-group has distinct requests denoted as , then we have and .
is a memory-size parameter, where is the size of each cache, and thus the cache size satisfies . Note that when we have uncoded prefetching and otherwise we have coded prefetching.
Ii-B Coded Prefetching Scheme
We adopt the coded prefetching scheme in  consisting of a cached content assignment step and an assigned content coding step, as follows:
Step 1: Split each file , , into non-overlapping fragments of equal size and then assign fragments to cache for any . Then cache is assigned with distinct fragments.
Step 2: Perform XOR among each combination of fragments each from a different file. For files, the number of such combinations is with the combination set defined as
and each file occurs in combinations with the combination set containing file defined as
Then we can index the fragments of assigned to cache as , . Thus the cached packets in cache are
As the size of each packet is , the cache size of each user-group is given by . We illustrate the coded prefetching through the following example.
Consider . The cache size is . Splitting each file into non-overlapping fragments and storing every fragments in cache , then the cached packets are shown in Table I.
|, ,||, ,||, ,|
|All cached packets|
Iii Proposed Delivery Scheme
Define () as the total number of distinct files requested by the users in the whole network and as the corresponding requested file index set. Thus given the requests , ,…, , we have . Define the requested fragments as the fragments from the files in , i.e., and the unrequested fragments as the fragments from any files in , , i.e., . Then our goal during the file delivery stage is to deliver the requested fragments to user-group . We classify the cached packets into four types according to the composition of the file fragments encoded, and devise the delivery strategy for the requested fragments in these packets according to the packet type.
Iii-a Type-I Cached Packets
A cached packet is Type-I if it is encoded from both requested and unrequested fragments, i.e.,
For each Type-I packet , the server directly transmits the requested fragments encoded in it, i.e.,
To illustrate this, we use an example based on the cached contents given in Table I by assuming , and . Then Type-I packets in the three caches are and , and the server just transmits and , . The delivery load is 6 fragments.
We now theoretically compute the delivery load according to Type-I packets. For any , all the fragments of assigned to cache are with the total number being and the number of the fragments such that being . Thus the number of the fragments such that is , which equals to the number of the assigned fragments of encoded into Type-I packets in cache . Since there are caches and distinct files requested by the users, the number of the transmitted fragments according to Type-I packets is given by
Iii-B Type-Ii Cached Packets
A cached packet is Type-II if it is encoded by requested fragments only, among which only one is requested by the user-group that caches it. Define the combination set of every requested fragments each from a different file from as
where . Then Type-II packets in cache can be characterized by
Suppose , then we call the fragment the local fragment since it may not need to be transmitted during the delivery. We first use the following example to illustrate Type-II packets and the delivery scheme according to them.
|Requested files||, ,||,||,|
|Cached Packets (Type-II)|
|Acquisition||, ,||,||, ,|
|, ,||,||, ,|
|, ,||,||, ,|
|Step 2||Transmissions||, ,|
Assume , where , , and . Then all Type-II packets in the three caches are given in the third row of Table II. Since each packet contains only one local fragment, the server first transmits the other fragment. Taking packet in cache 1 for example, the server transmits , then user-group 1 can obtain by XOR decoding and meanwhile other user-groups can obtain from the direct transmission of the server. Note that is also requested by user-group 3, whose cache also has local fragments from : and . To deliver these local fragments for the two user-groups, the server can then transmit a pairwise-coded packet encoded by XORing together with or . The rule to form pairwise-coded packets is that no local fragment is repeatedly XORed between any two caches. In our example we choose to transmit , and thus is a remaining unpaired fragment which will be delivered at the last stage. In such a way, the local fragments that can be pairwise-coded are delivered to multiple user-groups (see Step 2 in the table) and the untransmitted local fragments requested by multiple user-groups are shown in the last row.
Next, we present the general delivery scheme according to Type-II packets, which is divided into the following two steps:
Iii-B1 Step 1
Transmit fragments encoded in each packet except the local fragment , which are
Then user-group can obtain by XOR decoding since , and meanwhile other user-groups in can obtain their requested fragments given in (9) from the direct transmissions.
For any , the number of Type-II packets is and thus the number of transmissions is . Since the distinct request number of user-group is , the number of transmissions for user-group is . Then the delivery load for the user-groups is given by
Iii-B2 Step 2
Deliver the local fragments of for any that can be pairwise-encoded among the caches of , where denotes the set of user-groups requesting . Given any , the number of local fragments of in cache is . Define . Then cache has the minimum number of local fragments of , given by
Note that the local fragments of in different caches of may come from the packets with different file combinations, we denote them in cache by
where may hold. Take each local fragment of in cache as a reference fragment, and XOR it together with one local fragment of from any other cache to form pairwise-coded packets under the condition that no local fragment is repeatedly XORed with different reference fragments, given by
The above packets are transmitted and then user-group can obtain in them via XOR operations since it caches ; and any other user-group can obtain and in them via XOR operations since it caches . Thus for the transmissions of (13) for each reference fragment , every user-group of can obtain the local fragments of encoded in them, each from one cache of .
As there are local fragments of in cache , the number of transmitted packets for any is . Since there are requested files, the total number of transmitted packets is
Note that cache contains local fragments of , and of them have been pairwise-encoded and transmitted. After the transmissions of (13) for each , the number of remaining unpaired local fragments for all that are requested by multiple user-groups but untransmitted is
These remaining fragments will be delivered at the last stage, as will be discussed in Section III-E.
Iii-C Type-Iii Cached Packets
A cached packet is Type-III if it is encoded by requested fragments only, among which there are more than one local fragment. Such packet can be characterized by
where is defined in (7). We first use the following example to illustrate Type-III packets and the delivery scheme according to them.
|Requested files||, ,||, ,||, ,|
|Cached Packets (Type-III)|
|Step 1||Transmissions||, ,||, ,||, ,|