Novel Decentralized Coded Caching through Coded Prefetching

06/25/2018 ∙ by Yi-Peng Wei, et al. ∙ University of Maryland 0

We propose a new decentralized coded caching scheme for a two-phase caching network, where the data placed in user caches in the prefetching phase are random portions of a maximal distance separable (MDS) coded version of the original files. The proposed scheme achieves a better rate memory trade-off by utilizing the reconstruction property of MDS codes which reduces the number of transmissions that are useful only for a small subset of users in the delivery phase. Unlike the previously available coded prefetching schemes, the proposed scheme does not require to have more users than files. The proposed scheme can be viewed as a generalization of the original uncoded prefetching based decentralized coded caching scheme, and likewise, is applicable to various network topologies.

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

Consider a two-phase caching network consisting of one server with files connecting to users through an error-free shared link [1, 2]. Each user has a local cache memory which can store files. The two phases are the placement phase and the delivery phase. In the placement phase, when the network traffic load is low, each user can access the entire files in the server and fill their cache memories in advance. In the delivery phase, when the network traffic load is high, random out of users request a file from the server individually. The server delivers messages through the error-free shared link to the users. The request of each user is unknown a priori in the placement phase. Each user reconstructs the file they requested by using the messages sent from the server and the side information stored in their cache memory. The objective is to minimize the traffic load in the delivery phase due to the high traffic load then.

The two-phase caching network is first studied in [1], where by a proper assignment of the local cache memory content in the placement phase, coded-multicasting opportunities are created in the delivery phase, reducing the delivery rate. In [1], the number of users, , in the placement phase is equal to the number of users, , in the delivery phase, and therefore, the server can carefully coordinate each user’s local cache memory. This is referred to as centralized coded caching. In [2], a more general scenario is considered where the number of users, , in the placement phase is not the same as the number of users, , in the delivery phase. Since an arbitrary subset of users can make a request in the delivery phase and this number is unknown a priori in the placement phase, the server cannot carefully coordinate each user’s cache content as in [1]. In [2], an independent and identical random caching scheme is proposed, and is referred to as decentralized coded caching. Through the independent and identical random caching scheme in [2], coded-multicasting opportunities are still created in the delivery phase. Decentralized coded caching is widely applicable in other contexts, such as, online coded caching [3], where the cached content of users is updated during the delivery phase; and various network topologies such as hierarchical [4] and general [5] networks.

Both centralized coded caching in [1] and decentralized coded caching in [2] are uncoded prefetching schemes [6, 7], i.e., each user stores a subset of the bits of the original files. For centralized uncoded prefetching, with , [6] determines the exact rate memory trade-off for the worst-case file requests. For both centralized and decentralized uncoded prefetching, [7] determines the exact rate memory trade-off for arbitrary , and both for the worst-case and average file requests. For coded prefetching, the state of the art order optimality result is of factor as presented in [8].

For centralized setting, reference [1, Appendix] provides an example to show that coded prefetching outperforms uncoded prefetching. For the case of more users than files, i.e., , better coded caching schemes are provided in [9, 10, 11]. The coded caching scheme in [9] can only be applied to . The achievable rate memory pair in [9] is also achieved by a more general coded prefetching scheme given in [10], which is based on rank metric codes and MDS codes. In [11], a novel coded caching scheme is provided for . More detailed comparisons can be found in [12].

In this work, we propose a novel decentralized coded caching scheme based on coded prefetching111The coded prefetching schemes in [1, Appendix] and [9, 10, 11] perform coding over different files, i.e., what is prefetched is a mix of all files, while our coded prefetching here performs coding over the symbols in each file, i.e., what is prefetched is a mix of all symbols in individual files.. The proposed scheme first MDS codes each file in the server. Then, each user independently and randomly caches the MDS coded file as in [2]. By utilizing the reconstruction property of MDS codes, the proposed scheme reduces the transmission of the messages beneficial only to a small subset of users in the delivery phase. This yields an improved rate memory trade-off curve. Different from the existing coded prefetching schemes for centralized setting [9, 10, 11], the proposed scheme works for arbitrary and . In fact, for the decentralized setting, one cannot assume , as the number of users making requests in the delivery phase is uncertain. The proposed scheme can be viewed as a generalization of the original uncoded prefetching decentralized coded caching scheme in [2], and is likewise, applicable to online coded caching [3] and general network topologies [4, 5].

Ii System Model and Background

We consider a caching network consisting of one server and users. The server is connected to the users through an error-free shared link. The server has files denoted by . Each file is of size bits. Each user has a local cache memory of size bits for some real number . There are two phases in this network, a placement phase and a delivery phase. In the placement phase, the traffic load is low. User can access all the files and fill its cache memory . Therefore, , where . In the delivery phase, the traffic load is high. Random users out of total users request a file individually from the server (see Fig. 1). Let us denote each user’s request as

, and the request vector as

. The server outputs of size bits through the error-free shared link to the users, where refers to the load of the network in the delivery phase. A rate is said to be achievable if each user can decode the file by utilizing and . In this work, we study the worst-case normalized rate defined as

(1)

The objective is to minimize the rate in the delivery phase.

Fig. 1: Caching network.

In the placement phase, which files will be requested by the users in the delivery phase is unknown in advance, i.e., the cache memory is determined before knowing . Moreover, which users out of the users will make a request is also unknown a priori. Therefore, in the placement phase, the server fills the local cache memory of each user through a symmetric and random process. Next, we use an example to illustrate the decentralized coded caching algorithm in [2].

Example 1

Consider a two-phase caching network with , and users. We denote the two files as and . In the placement phase, each user has a space of bits in its cache to devote for each file. Therefore, each user independently and randomly chooses bits of each file to cache, and the memory size constraint is satisfied.

In the delivery phase, we consider the case with and . We partition each file as

(2)

where denotes the bits of file that are cached at the users in the set . To satisfy the request of each user, the server first sends out . Since is cached by the first user, the first users can obtain . Similarly, the second user obtains . Thus, a coded-multicasting opportunity is obtained even though the setting is decentralized. Next, the server sends out and . Combined with the local cache memory , the first user gets file . Similarly, the second user gets file .

The traffic load of the delivery phase is calculated using the law of the large numbers. For the file size large enough,

(3)
(4)
(5)
(6)

Therefore, the total number of transmitted bits is

(7)

and the normalized traffic load is . By inspecting all possible file requests, we note that the worst-case normalized rate is for the decentralized coded-caching algorithm in [2].

For uncoded prefetching, the exact rate memory trade-off for the decentralized setting is [7]

(8)

For uncoded prefetching, the exact rate memory trade-off for the centralized setting [7, Corollary 1] is

(9)

where , and . When , is equal to the lower convex envelope [7].

Iii Novel Decentralized Coded Caching

We start with a motivating example to illustrate the main idea of the proposed new decentralized coded caching scheme.

Example 2

Consider the same setting as in Example 1 with , , and . Note that in the delivery phase of Example 1, although is simultaneously useful for the two users, and are not. In this example, we try to lower the traffic load by reducing the messages useful only for one of the users through the assistance of MDS codes.

Consider a MDS code over222To apply MDS over , we consider the file size to be bits. Since , the cache size is of bits. When we compare with Example 1, we also consider the file size to be in Example 1. . We transform each file with bits into symbols over . Then, we encode each transformed file into an MDS coded file with size symbols. From the MDS property, arbitrary symbols reconstruct the whole file. In the placement phase, each user independently and randomly chooses symbols of each coded file to cache, and the memory size constraint is satisfied. Here, we denote the MDS coded files as and . As in Example 1, we partition each coded file as

(10)

By law of large numbers, for

large enough, we have

(11)
(12)
(13)
(14)

In the delivery phase, we again consider the case and . The server first sends out . Since the first user has in the local cache, the first user can get . Similarly, the second user gets . Since , each user till now has symbols of the file they requested. Therefore, the server only needs to send out symbols of and symbols of . In total, the normalized traffic load is , which is better than in Example 1.

We can further boost the performance by using a MDS code or a MDS code. Through a similar calculation, we can show that the normalized traffic loads are and , respectively, in these cases. For a general MDS code, the normalized traffic load is . As , , which is the normalized traffic load for centralized coded caching given in (9). We see in this example that, for this case, the performance of this system improves monotonically in , and as the performance of the decentralized system reaches the performance of the centralized system.

For some cases, the server does not need to send out .

Example 3

Consider the two-phase caching network with , and . Consider a MDS code over . Encode each file using this MDS into a file of size . In the placement phase, each user independently and randomly chooses symbols of each coded file to cache, and the memory size constraint is satisfied.

We partition each coded file as

(15)

For large enough, each subfile’s size is about

(16)
(17)
(18)
(19)

In the delivery phase, we consider the case , and . The server first sends out . Since the first user has in the local cache, can be decoded correctly. Similar argument holds for the other two users. Next, the server sends out , and . Since the first user has in the local cache, and can be obtained. Till now, the first user has every subfile of except . Therefore, the first user has symbols of coded file . This is sufficient to reconstruct the requested file. In fact, instead of sending out all the symbols of , and , the server only needs to send out symbols of each of them. In total, in the delivery phase, the server sends out symbols. The normalized rate is , which is lower than obtained from (8).

We also try a different MDS code for this system. For a MDS code, we calculate that the normalized traffic load as , which is lower than the normalized traffic load obtained through MDS code. We see in this example that the performance does not always have to improve with . In this example, performs better than .

We summarize the MDS coded prefetching based decentralized coded caching algorithm in Algorithm . We use to represent . Some remarks on Algorithm are as follows: In the placement phase, user caches symbols of each MDS coded file. In total, symbols are cached for each user; therefore, the memory size constraint is satisfied. Lines and determine a subset of the users called leaders as in [7, Section IV]. Lines to show that if none of the leaders is related to the transmission, then the server does not need to send out this message, which is originally proposed in [7, Section IV]. Line shows the coded multicasting message. Line accounts for at most how many symbols each user can get in iteration . Line guarantees that each user does not get more symbols than they need. For example, in Example 3, in iteration , each user can get symbols. However, only symbols are needed to reconstruct the file each user requested. Lines to show that each user only require symbols to reconstruct the file they requested. For example, in Example 3, the iteration stops at .

1:procedure Coded Prefetching() MDS
2:     for  do
3:         encode file into MDS coded file, , with coded symbols
4:     end for
5:     for ,  do
6:         user uniformly and randomly chooses a subset of symbols from each coded file, , to cache
7:         each user performs the prefetching independently
8:     end for
9:end procedure
10:
11:procedure Delivery()
12:      distinct elements in
13:      users request different files,
14:     
15:     for  do
16:         , for a
17:         
18:         
19:         for   do
20:              if   then
21:                  continue
22:              end if
23:              server sends symbols of
24:         end for
25:         if  then
26:              break
27:         end if
28:         
29:     end for
30:end procedure
Algorithm 1 MDS assisted decentralized coded caching

Different from the coded prefetching schemes for centralized setting [9, 10, 11], the proposed scheme works for arbitrary and . In fact, for decentralized setting, we cannot assume , since the number of users making request in the delivery phase varies. By letting in line of Algorithm , the proposed scheme reduces back to the original uncoded prefetching decentralized coded caching scheme in [2]. The proposed algorithm can also be applied to different network topologies as that in [2].

We conclude this section with the following theorem.

Theorem 1

Consider the decentralized two-phase caching network with files in the server, each user with local memory size that can store files, and users making a request in the delivery phase. For large enough file size , by applying a MDS code and using Algorithm , the following normalized rate is achievable,

(20)

where

(21)

and is defined through

(22)

such that

(23)

Proof:  is the accumulated number of symbols of the requested file by iteration starting from . In the placement phase, each user stores symbols of each file. Thus, we have the first term on the right hand side of (22). By law of large numbers, each encoded file segment is of size

(24)

where .

In the delivery phase, we first focus on the iterations of . For the iteration, the server transmits messages each with symbols, which accounts for the first term on the right hand side of (20). The user receives the broadcast message . Only the requested file segment, , is unknown to this user; therefore, correct decoding can be performed. After each iteration, each user gets symbols of the requested file; therefore, this accounts for the second term on the right hand side of (22).

In the last iteration, , each user accumulates more than enough number of symbols to reconstruct the requested file. (23) characterizes the last iteration. In the last iteration, the server only needs to transmits symbols of each broadcast message, since this is sufficient for each user to reconstruct the requested file. This gives the second term of the right hand side of (20).  

Iv Numerical Results

Iv-a Different Number of Users in the Delivery Phase

Consider the two-phase caching networks with , , and . To apply Algorithm , we consider and MDS codes and compare their performance with the uncoded prefetching scheme. In the delivery phase, we consider that the number of users making request ranges from to . Different from [9, 10, 11], this is the case of coded prefetching without the constraint of more users than files. We show the numerical results in Fig. 2, where we observe that longer MDS coded cases result in lower normalized rate. We also observe that the reduction in the transmission rate is more significant when the number of users making a request is larger.

Fig. 2: Rate versus number of users in the delivery phase for and .

Iv-B Rate Memory Trade-off

Fig. 3: Rate memory trade-off curve for and .

We consider the rate memory trade-off curve for the two-phase caching network with and . We show the numerical results in Fig. 3. Although MDS coded case achieves lower normalized rate, MDS coded case does not always achieve a lower rate. We observed a similar phenomenon in Example 3, where MDS coded case resulted in lower normalized rate than that of .

Fig. 4: Rate versus MDS code block length for , and .

Since and are fixed for the two-phase caching networks, we can use an expected number of users in the delivery phase to choose a proper MDS code parameter, , in advance. For example, following the same setting, for and , consider the case . We show in Fig. 4 that different coded MDS cases result in different normalized rates. We observe that longer MDS coded case does not necessarily result in lower normalized rate. From Fig. 4, we conclude that we should choose in Algorithm for this case. Note that for , Algorithm is the uncoded prefetching decentralized coded caching scheme in [2]; therefore, Algorithm

adds one more degree of freedom for us to lower the normalized rate.

V Conclusion

We proposed a new decentralized coded caching scheme based on MDS coded prefetching, and obtained improved rate memory trade-off results. The proposed scheme is a generalization to the original uncoded prefetching decentralized coded caching scheme, and adds one more degree of freedom to the original scheme, which is the MDS code rate, to optimize.

References