On the Fundamental Limits of Coded Caching Systems with Restricted Demand Types

06/30/2020 ∙ by Shuo Shao, et al. ∙ 0

Caching is a technique to reduce the communication load in peak hours by prefetching contents during off-peak hours. An information-theoretic framework for coded caching was introduced by Maddah-Ali and Niesen in a recent work, where it was shown that significant improvement can be obtained compared to uncoded caching. Considerable efforts have been devoted to identify the precise information-theoretic fundamental limits of the coded caching systems, however the difficulty of this task has also become clear. One of the reasons for this difficulty is that the original coded caching setting allows all possible multiple demand types during delivery, which in fact introduces tension in the coding strategy. In this paper, we seek to develop a better understanding of the fundamental limits of coded caching by investigating systems with certain demand type restrictions. We first consider the canonical three-user three-file system, and show that, contrary to popular beliefs, the worst demand type is not the one in which all three files are requested. Motivated by these findings, we focus on coded caching systems where every file must be requested by at least one user. A novel coding scheme is proposed, which can provide new operating points that are not covered by any previously known schemes.

READ FULL TEXT VIEW PDF
POST COMMENT

Comments

There are no comments yet.

Authors

page 1

page 2

page 3

page 4

This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

I Introduction

Caching is a technique to alleviate communication load during peak hours by prefetching certain contents to the memory of the end users during off-peak hours. Maddah-Ali and Niesen [1] proposed an information theoretic framework for caching systems, and showed that coded caching strategies can achieve significant improvement over uncoded caching strategies. The system in the proposed framework, which has files and users, operates in two phases: during the prefetching phase, each user fills the cache memory of size with information on the files, and during the delivery phase, the users first reveal their requests, then the central server broadcasts a message of size to all the users, and finally each user makes use of the received message together with the content in the cache memory to reconstruct the requested file.

The optimal tradeoff between and is of fundamental importance in this setting, the characterization of which has attracted significant research effort. Several inner bounds have been obtained using strategies based on either uncoded prefetching or coded prefetching [1, 2, 3, 4, 7, 6, 8, 9, 11, 5, 10], and various outer bounds have also been discovered [12, 13, 14, 15, 16]. When the prefetched contents are required to be uncoded fragments of the original files, the optimal tradeoff between and was fully characterized in [2]. However, it was also shown that in general, optimal tradeoff requires coded prefetching strategies [1, 6, 13]. The fundamental limit of coded caching systems still remains largely unknown in general.

In the prefetching phase, the users have no prior knowledge on the demands in the delivery phase, the collection of which is jointly referred to as the demand vector. As such, the prefetched contents need to be properly designed to accommodate all possible demand vectors. In a recent work

[12] (see also [13]

), the notion of demand type was introduced to classify the possible demand vectors, which led to simplifications in studying outer bounds of the coded caching systems. From this perspective, the original setting of

[1] in fact allows all possible demand types, and it appears that one reason for the afore-mentioned difficulty is the tension among the coding requirements to accommodate these different demand types. Therefore, a natural question is how different demand types impact the optimal tradeoff.

To develop a better understanding of this issue, in this work we consider caching systems with restricted demand types, where during the prefetching phase, the users and the server know a priori that the demand vector in the delivery phase must be from a certain class of demand types. Such systems clearly have a more relaxed coding requirement than the original setting due to the prior knowledge on the possible demands, however, it is still highly nontrivial since each demand type would allow a rich set of possible demand vectors. Because of the relaxed coding requirement, any scheme designed to accommodate all possible demand types is valid for a system with restricted demand types, however, outer bounds for a system allowing all possible demand types may not hold for a system with restricted demand types.

We begin our study by first collecting the best known inner bounds and outer bounds in the literature for the canonical system, some of which are from very recent developments [7, 8, 9, 10] in the area. This exercise reveals that although the setting where all files are requested by at least one user may pose a significant challenge for the optimal code design, a system where only such demand types are allowed can in fact achieve pairs that are strictly impossible for systems where certain other demand types are allowed. This is contrary to popular beliefs that such a demand type is the “worst case”, and also confirms the existence of a tension among the coding requirements for different demand types.

Given the observation above, we focus on one class of systems with restricted demand types, where it is known a prior that every file is requested by at least one user (implying that ). We propose a novel code construction which provides improved performance to the known memory-rate tradeoff in the literature for such systems. The proposed scheme can be viewed as a novel approach to utilize the interference alignment technique [17], where some prefetched and transmitted symbols are aligned together to cancel certain interfering signal, in order for the desired signals to be recovered. Moreover, a novel pairwise transformation is introduced in the construction, in order to more efficiently take advantage of such alignment opportunities. We note that the proposed construction generalizes the code recently proposed in [8], however, in contrast to the code specific designed for that yields a single pair in each case, our construction is for general where , and it provides multiple new operating points for each case.

Ii Caching Systems with Restricted Demand Types

In an coded caching system, there are

mutually independent uniformly distributed files

, each of bits. There are users, each with a cache memory of capacity bits; the set of all users is denoted as . In the prefetching phase, user- stores some content, denoted as , in the local cache memory. In the delivery phase, user-, , requests file , and the central server broadcasts a message of bits to every user, such that, together with the cached content, each user can decode the requested file. The optimal tradeoff between and is the fundamental mathematical object of interest in this problem.

The notion of demand type was first introduced in [12] (see also [13]), which is restated below.

Definition 1.

For a demand vector in an coded caching system, denote the number of users requesting file as , where . The demand type of the demand type of is the length- vector obtained by sorting the values in a decreasing order, which is denoted .

In this work, we consider caching systems with restricted demand types, i.e., it is known a priori that the demand vector must belong to a class of demand types. As a special case, if the class contains only one demand type, it will be referred to as a single demand type system. A second special case is when the class is restricted to be the demand types where all files are requested by at least one user, which is referred to as the fully demanded system. A third special case, where all possible demand vectors are allowed, is the original setting considered in [1], which will be referred to as the fully mixed demand type system.

As an example, consider an system. The demand vector belongs to the demand type . Moreover, the caching system for the single demand type only needs to accommodate the following demand vectors

Iii Mixed Demand Type and Single Demand Type Systems: The Case

In this section, we consider the canonical system, and collect the best known inner bounds and outer bounds in the literature for different caching systems depending on the imposed demand type restrictions. This exercise reveals several important insights and fundamental differences between systems with different demand type restrictions.


Fig. 1: Inner bounds and outer bounds for various systems.

Iii-a The Fully Mixed Demand Type System

The best known outer bound for this system can be found in [13], which are all the non-negative pairs of satisfying the constraints

The best known inner bound, on the other hand, is given by the lower convex hull of the points

where the second and third points are achieved by the scheme in [7], the fourth point is achieved by that in [10], while the others can be achieved by that in [1].

Iii-B Single Demand Type Systems

Next we provide the best known results for the three single demand type systems.

  1. For the system with the demand type , i.e., the same file is requested by all three users, the achievable region is all the non-negative such that

    (1)

    i.e., in this case, the inner bound and the outer bound match. The outer bound can be obtained by a simple cut-set argument [1], while the inner bound is trivial through a memory-sharing argument.

  2. For the system with the demand type , the achievable region is all the non-negative such that

    In this case, the corner points and can be achieved using the scheme in [1], and the points and are trivial. The outer bound was established in [13].

  3. For the system with the demand type , the best known outer bound is given in [13] as

    The best known inner bound is given by the lower convex hull of the points

    The second and third points are achieved by the scheme in [7], the point by that in [10], the point by that in [8], and the others by that in [1].

Iii-C Mixed Demand Types vs. Single Demand Type

By comparing the rate regions of different demand type systems in Fig.1, we make the following observations:

  1. The point , which is achievable for the system with the single demand type as shown in [8], is in fact not achievable for the demand type system, thus also not achievable for the fully mixed demand type system.

  2. Between mixed and single demand type systems, single demand type systems can indeed achieve lower rates than the fully mixed demand type system.

  3. Different single demand type systems provide different outer bounds for the fully mixed demand type system, with the one with fewer files demanded produce better bounds at high memory regimes, while those with more files being better at low memory regimes.

The first observation implies that the case when all files are requested is not necessarily the “worst case”, contrary to popular beliefs. Thus designing codes for this demand type alone is not sufficient to yield the optimal scheme for the fully mixed demand type systems. In fact, the optimal code design for fully demanded systems, though by itself already a challenging problem, can even be “simpler” than other cases. Motivated by the observations above and the code construction proposed in [8], which only provided a single operating point when , in the sequel we focus on fully demanded systems (implying that ), for general parameters.

Iv Main Results

Given a demand type which does not contain any zero elements, i.e., each file is being requested by at least one user, let be the number of ones in it, i.e., the number of files requested by only one user. The delivery rate compression saving factor, for , is defined as

(2)

where we have taken the convention that when . The delivery rate compression saving factor accounts for the rate reduction in the transmission rate when linear dependence may be found. Observe that when , and it generally increases when increases.

The performance of the proposed scheme is summarized in the following theorem.

Theorem 1.

For an fully demand caching system (implying ) where only a single demand type is allowed, the following memory-rate pairs are achievable:

(3)

for .

The proof of theorem is given in the next section. It will be clear from the proposed code construction that the restriction on the demand types simplifies the design of the prefetching. More precisely, it is effective to prefetch certain coded symbols involving all files, because any file will be requested eventually in such systems.

Since in the proposed code construction, the prefetching strategy does not depend on the particular demand type, but only requires that all files are requested during the delivery phase, we can state the following theorem.

Theorem 2.

For an fully demanded caching system (implying ), the following memory-rate pairs are achievable:

(4)

where the demand type is any that satisfies .

Proof.

We will need to find the largest rate in Theorem 1. The choice of that maximizes minimizes , which in turn minimizes , i.e., the number of files that are requested only by one user. If , we can set by choosing a demand type where every file is requested by at least two users. On the other hand, if , we minimize by choosing a demand type where files are requested by one user and the other files are requested by two users, i.e., . ∎

In an earlier version of this work [18], we proposed a construction for systems, for which Theorem 1 provides a natural generalization. For fully demanded systems, by setting , we recover the operating point given in [8]. In fact, our proposed construction in this work (sans the pairwise transformation) and that given in [18] essentially specialize to that in [8] by a proper relabeling of the file segments. On the other hand, setting gives the point in [6] (see also [4]). Operating points for other values of are previously unknown to be achievable.

The performance of the proposed construction is illustrated for and demand type in Fig. 2; the operating points , , and are previously unknown to be achievable in the existing literature.

Fig. 2: Inner bounds for and demand type .

V Coding Scheme for Fully Demanded Coded Caching Systems

The proposed code construction consists of multiple components which rely on each other to function as a whole. These components are: a novel file partition strategy, a prefetching strategy, a pairwise transformation, a delivery strategy, and a decoding strategy. The construction is parametrized by an integer , whose meaning will become clear in the sequel. Throughout the section, we use and as our running example, and will provide details for this example whenever possible.

V-a A Novel File Partition Strategy

Let be a positive integer in the set , and let be the cardinality of the set . In the proposed partition strategy, each file is partitioned into a total of segments, resulting in file segments denoted as , through three steps. In the first step, each file is partitioned into equal-sized sub-files, resulting in the corresponding subscript label and . In the second step, each such subfile is further partitioned into small subfiles of equal size, resulting in the corresponding subscript label . In the third step, each small subfile is finally partitioned into two equal-sized segments, which are called the “I channel” segment and “Q channel” segments, resulting in the superscript label .

Consider our running example and : here each file is partitioned into segments, which are listed in Table I.

[dir=SE]
, , , , ,
, , , , ,
, , , , ,
, , , , ,
, , , , ,
, , , , ,
, , , , ,
, , , , ,
, , , , ,
, , , , ,
, , , , ,
, , , , ,
, , , , ,
, , , , ,
, , , , ,
, , , , ,
, , , , ,
, , , , ,
TABLE I: File partition of in code caching system when

V-B Prefetching

In the prefetching phase, the I-channel and the Q-channel are prefetched in the same manner for each user , independent of each other; for conciseness, we will use to denote either or .

V-B1 Uncoded content

The uncoded segments are placed into the cache memory of user , for every , every such that , every , and every . A total of such segments are prefetched at user . For our running example and , the segments labeled red in Table I are directly placed in the cache of user- in the uncoded form.

V-B2 Coded content

The coded content prefetched by user can be conveniently viewed as the parities of a product code [20]: the segments with the same index (and the same channel) are placed in a matrix, where each row contains the segments of the same file index (i.e., the same index), and each column contains the segments of the same index. For our running example, this matrix is shown in Table V-B2 in blue for user-1, which correspond to the elements in Table I that are also labeled blue. The coded symbols are then prefetched using this matrix as follows.

 
 
  • Column parity checks: These coded symbols ’s are the parities for the column indexed by , i.e.,

    (5)

    for all possible set satisfying . Clearly, there are such symbols, where the factor is due to the dual channels.

  • Row parity checks: For the row corresponding to file index , there will be multiple row parities, and let us focus on one fixed , i.e., one row. For each where , a row parity is given by

    (6)

    Due to the inherent linear dependency in product codes, only some of these row parities need to prefetched. More precisely, let

    then the prefetched row parities are where and such that . It is clear that the total number of prefetched row parities is .

The column and row parities at user-1 in our running example are given in Table V-B2. The column parities are labeled purple, and the row parity bits are labeled brown, where is not prefetched (strikethrough in the table). Since in this case can only be the empty set, there is only one parity per row.

Collecting all the prefetched content, it is seen that the normalized cache size is

(7)

The linear dependence among the coded parities is made more precise in the following lemma.

Lemma 1.
Consider a fixed user and subset , where and , then for any ,
(8)
Moreover, we have
(9)

The proof of this lemma can be found in Appendix A. Essentially, this lemma states that all the row parities can be computed using only the prefetched parities. Consider again our running example. The parity can be computed according to (9) in Lemma 1 as

V-C Pairwise Transformation for Delivery

The I/Q channel structure provides an additional opportunity to utilize the prefetched information in the delivery phase. This is accomplished through a pairwise transformation, which we define next. The delivery process will go through all , and in the following we shall discuss a fixed . For a demand , we denote as the number of users requesting file . Correspondingly, denote the set of indices of these users as . For any , denote its complement set as

(10)

Among the users that request file , let the lowest indexed user be the leader in , denoted as . The transformed segment pair for is given by

(11)

where is given next. If , then define

(12)

On the other hand, if , define

(13)

In other words, when is odd, are identical to ; when is even, an invertible transformation is applied.

In our running example, when the demand vector is , consider the case , , and . Since and , the transformed segments are given as

by (12). Next consider another case where , , and . Since , , and the leader of is , we have . Hence, (13) gives

Table III shows all the transformed segments for .

2
3
4