traffic in content delivery networks exhibits strong temporal variability , resulting in congestion during peak hours and resource underutilization during off - peak hours .
it is therefore desirable to try to `` shift '' some of the traffic from peak to off - peak hours .
one approach to achieve this is to exploit idle network resources to duplicate some of the content in memories distributed across the network .
this duplication of content is called content placement or caching .
the duplicated content can then be used during peak hours to reduce network congestion .    from the above description
, it is apparent that the network operates in two different phases : a content placement phase and a content delivery phase . in the placement phase
, the network is not congested , and the system is constrained mainly by the size of the cache memories . in the delivery phase , the network is congested , and the system is constrained mainly by the rate required to serve the content requested by the users . the goal is thus to design the placement phase such that the rate in the delivery phase is minimized .
there are two fundamentally different approaches , based on two distinct understandings of the role of caching , for how the placement and the delivery phases are performed .
* _ providing content locally : _ in the first , conventional , caching approach , replication is used to make part of the requested content available close to the end users .
if a user finds part of a requested file in a close - by cache memory , that part can be served locally .
the central content server only sends the remaining file parts using simple orthogonal unicast transmissions . if more than one user requests the same file , then the server has the option to multicast a single stream to those users .
+ extensive research has been done on this conventional caching approach , mainly on how to exploit differing file popularities to maximize the caching gain  @xcite .
the gain of this approach is proportional to the fraction of the popular content that can be stored locally . as a result ,
this conventional caching approach is effective whenever the local cache memory is large enough to store a significant fraction of the total popular content . * _ creating simultaneous coded - multicasting opportunities : _ in this approach , which we recently proposed in  @xcite , content is placed in order to allow the central server to satisfy the requests of several users with _
different _ demands with a _
single _ multicast stream .
the multicast streams are generated by coding across the different files requested by the users .
each user exploits the content stored in the local cache memory to enable decoding of its requested file from these data streams . since the content placement is performed before the actual user demands are known , it has to be designed carefully such that these coded - multicasting opportunities are available simultaneously for all possible requests .
+ in  @xcite , we show that this simultaneous coded - multicasting gain can significantly reduce network congestion .
moreover , for many situations , this approach results in a much larger caching gain than the one obtained from the conventional caching approach discussed above . unlike the conventional approach ,
the simultaneous coded - multicast approach is effective whenever the aggregate _
global _ cache size ( i.e. , the cumulative cache available at all users ) is large enough compared to the total amount of popular content , even though there is no cooperation among the caches .    as mentioned above , the scheme proposed in  @xcite , relies on a carefully designed placement phase in order to create coded - multicasting opportunities among users with different demands .
a central server arranges the caches such that every subset of the cache memories shares a specific part of the content .
it is this carefully arranged overlap among the cache memories that guarantees the coded - multicasting opportunities simultaneously for all possible user demands .
while the assumption of a centrally coordinated placement phase was helpful to establish the new caching approach in  @xcite , it limits its applicability .
for example , the identity or even just the number of active users in the delivery phase may not be known several hours in advance during the placement phase . as another example , in some cases the placement phase could be performed in one network , say a wifi network , to reduce congestion in the delivery phase in another network , say a cellular network . in either case , coordination in the placement phase
may not be possible .
this raises the important question whether lack of coordination in the placement phase eliminates the significant rate reduction promised by the simultaneous coded - multicast approach proposed in  @xcite .
put differently , the question is if simultaneous coded - multicasting opportunities can still be created without a centrally coordinated placement phase .    in this paper
, we answer this question in the positive by developing a caching algorithm that creates simultaneous coded - multicasting opportunities without coordination in the placement phase .
more precisely , the proposed algorithm is able to operate in the placement phase with an unknown number of users situated in isolated networks and acting independently from each other .
thus , the placement phase of the proposed algorithm is _
decentralized_. in the delivery phase , some of these users are connected to a server through a shared bottleneck link . in this phase ,
the server is first informed about the set of active users , their cache contents , and their requests .
the proposed algorithm efficiently exploits the multicasting opportunities created during the placement phase in order to minimize the rate over the shared bottleneck link .
we show that our proposed decentralized algorithm can significantly improve upon the conventional uncoded scheme .
moreover , we show that the performance of the proposed decentralized coded caching scheme is close to the one of the centralized coded scheme of  @xcite .
users connected to a server storing @xmath0 files through a shared bottleneck link .
the horizontal axis is the size of the cache memory ( normalized by the file size ) at each user ; the vertical axis shows the peak rate ( again normalized by the file size ) over the shared link in the delivery phase .
the dashed green curve depicts the rate achieved by the conventional uncoded caching scheme advocated in the prior literature .
the solid black curve depicts the rate achieved by the decentralized coded caching scheme proposed in this paper .
the dashed blue curve depicts the rate achieved by the centralized coded caching algorithm from the recent paper  @xcite . ]
these two claims are illustrated in fig .
[ fig : intro ] for a system with @xmath1 users and @xmath0 pieces of content .
for example , when each user is able to cache @xmath2 of the files , the peak rate of the conventional uncoded scheme is equivalent to transmitting @xmath3 files . however , in the proposed decentralized coded scheme , the peak rate is equivalent to transmitting only about @xmath4 files . by comparing this to the performance of the centralized coded scheme
, we can see that the rate penalty for decentralization of the placement phase of the caching system is modest .
the remainder of this paper is organized as follows .
section  [ sec : problem ] formally introduces the problem setting .
section  [ sec : main_proposed ] presents the proposed algorithm . in section
[ sec : performance ] , the performance of the proposed algorithm is evaluated and compared with the uncoded and the centralized coded caching schemes . in section  [ sec : extensions ] , the results are extended to other topologies of practical interest .
section [ sec : discussions ] discusses various implications of the results .
to gain insight into how to optimally operate content - distribution systems , we introduce here a basic model for such systems capturing the fundamental challenges , tensions , and tradeoffs in the caching problem . for the sake of clarity , we initially study the problem under some simplifying assumptions , which will be relaxed later , as is discussed in detail in sections  [ sec : extensions ] and  [ sec : discussions ] .
we consider a content - distribution system consisting of a server connected through an error - free shared ( bottleneck ) link to @xmath5 users .
the server stores @xmath6 files each of size @xmath7 bits .
the users each have access to a cache able to store @xmath8 bits for @xmath9 $ ] .
this scenario is illustrated in fig .
[ fig : setting ] .     files of size @xmath7 bits each is connected through a shared link to @xmath5 users each with a cache of size @xmath8 bits . in the figure , @xmath10 and @xmath11 . ]
the system operates in two phases : a _ placement _ phase and a _ delivery _ phase .
the placement phase occurs when the network load is low . during this time
, the shared link can be utilized to fill the caches of the users .
the main constraint in this phase is the size of the cache memory at each user .
the delivery phase occurs after the placement phase when the network load is high . at this time
, each user requests one file from the server , which proceeds to transmit its response over the shared link . given the output of the shared link ( observed by all users ) and its cache content , each user should be able to recover its requested file .
the main constraint in this phase is the load of the shared link .
the objective is to minimize the worst - case ( over all possible requests ) rate of transmission over the shared link that is needed in the delivery phase .
we now formalize this problem description . in the placement phase , each user is able to fill its cache as an arbitrary function ( linear , nonlinear ,  ) of the @xmath6 files subject only to its memory constraint of @xmath8 bits .
we emphasize that the requests of the users are not known during the placement phase , and hence the caching function is not allowed to depend on them .    in the delivery phase ,
each of the @xmath5 users requests one of the @xmath6 files and communicates this request to the server .
let @xmath12 be the request of user @xmath13 .
the server replies to these requests by sending a message over the shared link , which is observed by all the @xmath5 users .
let @xmath14 be the number of bits in the message sent by the server .
we impose that each user is able to recover its requested file from the content of its cache and the message received over the shared link with probability arbitrary close to one for large enough file size @xmath7 .
denote by @xmath15 the worst - case normalized rate for a caching scheme .
our objective is to minimize @xmath16 in order to minimize the worst - case network load @xmath17 during the delivery phase .
clearly , @xmath16 is a function of the cache size @xmath8 . in order to emphasize this dependence
, we will usually write the rate as @xmath18 . the function @xmath18 expresses the _ memory - rate tradeoff _ of the content - distribution system .
the following example illustrates the definitions and notations and introduces the uncoded caching scheme advocated in most of the prior literature .
this uncoded caching scheme will be used as a benchmark throughout the paper .
[ eg : conventional ] consider the caching scenario with @xmath19 files and @xmath20 users each with a cache of size @xmath11 . in the uncoded caching scheme , each of the two files @xmath21 and @xmath22
are split into two parts of equal size , namely @xmath23 and @xmath24 . in the placement phase , both users cache @xmath25 , i.e. , the first part of each file . since each of these parts has size @xmath26 , this satisfies the memory constraint of @xmath27 bits .
consider now the delivery phase of the system .
assume that each user requests the same file @xmath21 , i.e. , @xmath28 .
the server responds by sending the file part @xmath29 . clearly , from their cache content and the message received over the shared link
, each user can recover the requested file @xmath23 .
the ( normalized ) rate in the delivery phase is @xmath30 .
assume instead that user one requests file @xmath21 and user two requests file @xmath22 , i.e. , @xmath31 and @xmath32 .
the server needs to transmit @xmath33 to satisfy these requests , resulting in a rate in the delivery phase of @xmath34 .
it is easy to see that this is the worst - case request , and hence @xmath35 for this scheme .    for general @xmath6 , @xmath5 , and @xmath36 , the uncoded scheme caches the first @xmath37 fraction of each of the @xmath6 files .
therefore , in the delivery phase , the server has to send the remaining @xmath38 fraction of the requested files .
the resulting rate in the delivery phase , denoted by @xmath39 for future reference , is @xmath40 for @xmath41 and @xmath11 , this yields @xmath42 , as before .
as we will see , this conventional caching scheme can be significantly improved upon . in particular , see example  [ eg : illustration ] in section  [ sec : main_proposed ] .
one important feature of the uncoded scheme introduced in example  [ eg : conventional ] is that it has a _
decentralized _ placement phase . by that
we mean that the cache of each user is filled independently of other users .
in particular , the placement operation of a given user neither depends on the identity nor the number of other users in the system . as a result , the users could , in fact , contact different servers at different times for the placement phase .
having a decentralized placement phase is thus an important robustness property for a caching system .
this is discussed further in sections  [ sec : main_proposed ] and [ sec : extensions ] .    as was mentioned earlier
, the system description introduced in this section makes certain simplifying assumptions .
in particular , we assume a system having a single shared broadcast link , with a cache at each user , and we focus on worst - case demands , with synchronized user requests in the delivery phase .
all these assumptions can be relaxed , as is discussed in sections  [ sec : extensions ] and [ sec : discussions ] .
we now present a new algorithm ( referred to as decentralized coded caching scheme in the following ) for the caching problem . in the statement of the algorithm
, we use the notation @xmath43 to denote the bits of the file @xmath44 requested by user @xmath45 cached exclusively at users in @xmath46 .
in other words , a bit of file @xmath44 is in @xmath43 if it is present in the cache of every user in @xmath46 and if it is absent from the cache of every user outside @xmath46 .
we also use the notation @xmath47
\defeq \{1,2,\dots , k\}$ ] and @xmath48 \defeq \{1,2,\dots , n\}$ ] .
the proposed algorithm consists of a placement procedure and two delivery procedures . in the placement phase
, we always use the same placement procedure . in the delivery phase ,
the server chooses the delivery procedure minimizing the resulting rate over the shared link .
user @xmath45 caches a random @xmath49-bit subset of file @xmath50 [ alg:1_cache ] [ alg:1_sloop ] [ alg:1_sloop ] server sends @xmath51 [ alg:1_send ] server sends enough random linear combinations of bits in file @xmath50 for all users requesting it to decode [ alg:1_send2 ]    [ rem : alg ] the @xmath52 operation in line  [ alg:1_send ] of algorithm  [ alg:1 ] represents the bit - wise xor operation .
all elements @xmath53 are assumed to be zero padded to the length of the longest element .
we illustrate the algorithm  [ alg:1 ] with a small example .
[ eg : illustration ] consider the caching problem with @xmath19 files @xmath21 and @xmath22 , and @xmath20 users each with a cache of size @xmath36 . in the placement phase of algorithm  [ alg:1
] , each user caches a subset of @xmath54 bits of each file independently at random . as a result , each bit of a file is cached by a specific user with probability @xmath55 .
let us focus on file @xmath21 .
the actions of the placement procedure effectively partition file @xmath21 into @xmath56 subfiles , @xmath57 where , for @xmath58 , @xmath59 denotes the bits of file @xmath21 that are stored in the cache memories of users in @xmath46 . as shorthand for @xmath60 .
similarly , we write @xmath61 for @xmath62 . ] for example , @xmath63 are the bits of @xmath21 available in the cache memories of users one and two , whereas @xmath64 are the bits of @xmath21 available exclusively in the cache memory of user one .    by the law of large numbers ,
@xmath65 with probability approaching one for large enough file size @xmath7 .
therefore , we have with high probability :    * @xmath66 is approximately @xmath67 .
* @xmath68 and @xmath69 are approximately @xmath70 .
* @xmath71 is approximately @xmath72 .
the same analysis holds for file @xmath22 .
we now consider the delivery phase in algorithm  [ alg:1 ] .
as we will see later ( see remark  [ rem : thm ] below ) , for the scenario at hand the first delivery procedure will be used .
assume that user one requests file @xmath21 and user two requests file @xmath22 .
the iteration in line  [ alg:1_sloop ] of algorithm  [ alg:1 ] starts with @xmath73 . by line  [ alg:1_sloop ]
, this implies that we consider the set @xmath74 .
observe that :    * the cache of user two contains @xmath75 , which is needed by user one .
hence , @xmath76 . * the cache of users one contains @xmath77 , which is needed by user two . hence , @xmath78 .    as a result , in line  [ alg:1_send ] of algorithm  [ alg:1 ] , the server transmits @xmath79 over the shared link .
user one can solve for @xmath75 from the received message @xmath79 and the cached subfile @xmath77 .
user two can solve for @xmath77 from the message @xmath79 and the cached subfile @xmath75 .
therefore , @xmath79 is simultaneously useful for @xmath73 users .
thus , even though the two users request different files , the server can successfully multicast useful information to both of them .
we note that the normalized ( by @xmath7 ) size of @xmath80 is @xmath70 .
the second iteration in line  [ alg:1_sloop ] is for @xmath81 . in this iteration
, the server simply sends @xmath82 and @xmath83 in line  [ alg:1_sloop ] .
each of these transmissions has normalized size @xmath67 .    from @xmath75
computed in iteration one , @xmath84 received in iteration two , and its cache content @xmath85 , user one can recover the requested file @xmath86 . similarly , user two can recover the requested file @xmath22 .
summing up the contributions for @xmath73 and @xmath81 , the aggregate size ( normalized by @xmath7 ) of the messages sent by the server is @xmath87 this can be rewritten as @xmath88 in particular , for @xmath11 , the rate of algorithm  [ alg:1 ] is @xmath89 .
this compares to a rate of @xmath42 achieved by the uncoded caching scheme described in example  [ eg : conventional ] in section  [ sec : problem ] . while the improvement in this scenario is relatively small , as we will see shortly , for larger values of @xmath6 and @xmath5 , this improvement over the uncoded scheme can be large .    [ rem : knownk ] the placement procedure of algorithm  [ alg:1 ] is _ decentralized _ , in the sense that the user s caches are filled independently of each other .
this implies that neither the identity nor even the number of users sharing the same bottleneck link during the delivery phase need to be known during the earlier placement phase .
this decentralization of the placement phase enables the content - distribution system to be much more flexible than a centralized placement phase .
this flexibility is essential .
for example , in wireline networks , some of the users may not request any file in the delivery phase . in wireless networks , users may move from one network or cell to another , and hence might not even be connected to the same server in the two phases . in either case , the result is that the precise number and identity of users in the delivery phase is unknown in the placement phase .
one of the salient features of the decentralized algorithm proposed in this paper is that it can easily deal with these situations .
this flexibility is also crucial to deal with asynchronous user requests , as is explained in detail in section  [ sec : extensions_synchronization ] .
it is also a key ingredient to extending the coded - caching approach to scenarios with nonuniform demands or with online cache updates , as is discussed further in section  [ sec : discussions ] and in the follow - up works @xcite and @xcite .
[ _ greedy coding strategy _ ] the first delivery procedure in algorithm  [ alg:1 ] follows a _ greedy _ strategy .
it first identifies and forms coded messages that are useful for all @xmath90 users . in the next iteration ,
it forms coded messages that are useful for a subset of @xmath91 users .
the iteration continues until it identifies messages that are useful for only @xmath81 user .
[ _ simplified decision rule _ ] [ remark : m ] algorithm  [ alg:1 ] provides two delivery procedures .
the general rule is to choose the procedure which minimizes the resulting rate over the shared link .
a simple alternative rule to decide between these two procedures is as follows : if @xmath92 , employ the first procedure ; otherwise , employ the second procedure .
the performance loss due to this simpler rule can be shown to be small . with some minor modifications . ]
we now analyze the performance of the proposed decentralized coded caching scheme given by algorithm  [ alg:1 ] .
section  [ sec : performance_rate ] provides an analytic expression for the rate of algorithm  [ alg:1 ] .
section  [ sec : performance_decentralized ] compares the proposed decentralized coded caching scheme with the decentralized uncoded caching scheme from example  [ eg : conventional ] ( the best previously known decentralized caching scheme ) .
section  [ sec : performance_centralized ] compares the proposed decentralized coded caching scheme with the optimal centralized caching scheme and the caching scheme from  @xcite ( the best known centralized caching scheme ) .
the performance of decentralized coded caching is analyzed in the next theorem , whose proof can be found in appendix  [ sec : proofs_achievable1 ] .
[ thm : achievable1 ] consider the caching problem with @xmath6 files each of size @xmath7 bits and with @xmath5 users each having access to a cache of size @xmath8 bits with @xmath93 $ ] .
algorithm  [ alg:1 ] is correct and , for @xmath7 large enough , achieves rate arbitrarily close to @xmath94    [ rem : thm ] we note that if @xmath95 or @xmath96 , then the minimum in @xmath97 is achieved by the first term so that @xmath98 this is the rate of the first delivery procedure in algorithm  [ alg:1 ] . since @xmath95 or @xmath99 is the regime of most interest , the majority of the discussion in the following focuses on this case .
[ rem : zero ] theorem  [ thm : achievable1 ] is only stated for @xmath100 . for @xmath101 algorithm  [ alg:1 ]
is easily seen to achieve a rate of @xmath102 we see that @xmath103 is the continuous extension of @xmath97 for @xmath104 . to simplify the exposition
, we will not treat the case @xmath101 separately in the following .
we point out that the rate @xmath97 of algorithm  [ alg:1 ] consists of three distinct factors .
the first factor is @xmath5 ; this is the rate without caching .
the second factor is @xmath105 ; this is a _ local _ caching gain that results from having part of the requested file already available in the local cache .
the third factor is a _
gain that arises from using the caches to create simultaneous coded - multicasting opportunities .
see example  [ eg : illustration ] in section  [ sec : main_proposed ] for an illustration of the operational meaning of these three factors .
it is instructive to examine the performance of the proposed decentralized coded caching scheme ( algorithm  [ alg:1 ] ) for large and small values of cache size @xmath36 . for simplicity , we focus here on the most relevant case @xmath106 , i.e. , the number of files is at least as large as the number of users , so that the rate @xmath97 of algorithm  [ alg:1 ] is given by remark  [ rem : thm ] .    as a baseline , we compare the result with the uncoded caching scheme , introduced in example  [ eg : conventional ] in section  [ sec : problem ] .
this is the best previously known algorithm with a decentralized placement phase . for @xmath95 ,
the uncoded scheme achieves the rate @xmath107 which is linear with slope of @xmath108 throughout the entire range of @xmath36 .      for small cache size @xmath109 $ ]
, the rate achieved by algorithm  [ alg:1 ] behaves approximately , and by analyzing the constant in the @xmath110 expression it can be shown that this is a good approximation in the regime @xmath109 $ ] .
] as @xmath111 in this regime , @xmath97 scales approximately linearly with the memory size @xmath36 with slope @xmath112 : increasing @xmath36 by one decreases the rate by approximately @xmath113 .
this is illustrated in fig .
[ fig : regimes ] .    comparing   and
, we have the following observations :    * _ order-@xmath5 improvement in slope : _ the slope of @xmath97 around @xmath101 is approximately @xmath114 times steeper than the slope of @xmath39 .
thus , the reduction in rate as a function of @xmath36 is approximately @xmath114 times faster for algorithm  [ alg:1 ] than for the uncoded scheme . in other words , for small @xmath36
the scheme proposed here makes approximately @xmath114 times better use of the cache resources : an improvement on the order of the number of users in the system .
this behavior is clearly visible in fig .
[ fig : intro ] in section  [ sec : intro ] .
* _ virtual shared cache : _ consider a hypothetical setting in which the @xmath5 cache memories are collocated and shared among all @xmath5 users . in this hypothetical system , arising from allowing complete cooperation among the @xmath5 users , it is easy to see that the optimal rate is @xmath115 . comparing this to
, we see that , up to a factor @xmath116 , the proposed decentralized coded caching scheme achieves the same order behavior .
therefore , this scheme is essentially able to create a single virtually shared cache , even though the caches are isolated without any cooperation between them .
on the other hand , for @xmath117 $ ] we can approximate , we have @xmath118 in the regime @xmath117 $ ] , and the pre - constant in the order notation converges to @xmath119 as @xmath120 . ] @xmath121 in this regime , the rate achieved by algorithm  [ alg:1 ] scales approximately inversely with the memory size : doubling @xmath36 approximately halves the rate .
this is again illustrated in fig .
[ fig : regimes ] .
comparing   and  , we have the following observation :    * _ order-@xmath5 improvement in rate : _ in this regime , the rate of the proposed decentralized coded scheme can be up to a factor @xmath5 smaller than the uncoded scheme : again an improvement on the order of the number of users in the system .
this behavior is again clearly visible in fig .
[ fig : intro ] in section  [ sec : intro ] .     achieved by algorithm  [ alg:1 ] for @xmath122 files and @xmath123 users ( see theorem  [ thm : achievable1 ] ) .
the function @xmath97 behaves approximately linearly for @xmath109 $ ] and behaves approximately as @xmath124 for @xmath117 $ ] ( both approximations are indicated by dotted curves ) . ]
we have compared the performance of the proposed decentralized coded caching scheme to the uncoded caching scheme , which is the best previously known _ decentralized _
algorithm for this setting .
we now compare the decentralized coded caching scheme to the rate achievable by _ centralized _ caching schemes .
we start with an information - theoretic lower bound on the rate of _ any _ centralized caching scheme .
we then consider the rate of the best known centralized caching scheme recently introduced in  @xcite .
[ thm : comparison_converse ] let @xmath97 be the rate of the decentralized coded caching scheme given in algorithm  [ alg:1 ] , and let @xmath125 be the rate of the optimal centralized caching scheme . for any number of files @xmath6 and number of users @xmath5 and for any @xmath9 $ ] , we have @xmath126    the proof of theorem  [ thm : comparison_converse ] , presented in appendix  [ sec : proofs_comparison_converse ] , uses an information - theoretic argument to lower bound the rate of the optimal scheme @xmath125 . as a result ,
theorem  [ thm : comparison_converse ] implies that _ no _ scheme ( centralized , decentralized , with linear caching , nonlinear caching ,  ) regardless of is computational complexity can improve by more than a constant factor upon the efficient decentralized caching scheme given by algorithm  [ alg:1 ] presented in this paper .
theorem  [ thm : comparison_converse ] implies that uncoded caching in the placement phase combined with linear greedy coding in the delivery phase is sufficient to achieve a rate within a constant factor of the optimum .
we now compare the rate @xmath97 of decentralized coded caching to the rate @xmath127 of the best known centralized coded caching scheme . in  (
* theorem  2 ) , @xmath127 is given by @xmath128 for @xmath129 , and the lower convex envelope of these points for all remaining values of @xmath9 $ ] .
[ fig : intro ] in section  [ sec : intro ] compares the performance @xmath127 of this centralized coded caching scheme to the performance @xmath97 of the decentralized coded caching scheme proposed here .
as can be seen from the figure , the centralized and decentralized caching algorithms are very close in performance .
thus , there is only a small price to be paid for decentralization .
indeed , we have the following corollary to theorem  [ thm : comparison_converse ] .
[ thm : comparison_centralized ] let @xmath97 be the rate of the decentralized coded caching scheme given in algorithm  [ alg:1 ] , and let @xmath127 be the rate of the centralized coded caching scheme from  @xcite . for any number of files
@xmath6 and number of users @xmath5 and for any @xmath9 $ ] , we have @xmath130    corollary  [ thm : comparison_centralized ] shows that the rate achieved by the decentralized coded caching scheme given by algorithm  [ alg:1 ] is at most a factor @xmath131 worse than the one of the best known centralized algorithm from @xcite .
this bound can be tightened numerically to @xmath132 for all values of @xmath5 , @xmath6 , and @xmath36 .
hence , the rate of the decentralized caching scheme proposed here is indeed quite close to the rate of the best known centralized caching scheme .
it is instructive to understand why the decentralized scheme performs close to the centralized one . in the centralized scheme
, content is placed in the placement phase such that in the delivery phase every message is useful for exactly @xmath133 users . in the decentralized scheme
, we can not control the placement phase as accurately .
however , perhaps surprisingly , the number of messages that are useful for about @xmath133 users is nevertheless the dominant term in the overall rate of the decentralized scheme .    more precisely , from the proof of theorem  [ thm : achievable1 ] in appendix
[ sec : proofs_achievable1 ] , we can write the rate @xmath97 of the decentralized coded scheme as a convex combination of the rate @xmath127 of the centralized coded scheme : @xmath134 with @xmath135 and @xmath136 . the dominant term in this sum is @xmath127 occurring at @xmath137 , as is illustrated in fig .
[ fig : concentration ] .
this observation explains why the centralized and the decentralized schemes have approximately the same rate .
in this section , we extend the results presented so far to some important cases arising in practical systems . in particular , we show how to handle networks with tree topologies in section  [ sec : extensions_tree ] , caches shared by several users in section  [ sec : extensions_shared ] , and users with asynchronous requests in section  [ sec : extensions_synchronization ] .
the basic problem setting considered so far considers users connected to the server through a single shared bottleneck link .
we showed that the rate of our proposed algorithm over the shared link is within a constant factor of the optimum . here
we extend this result to a more general network with tree structure ( see fig .
[ fig : tree ] ) .
files of size @xmath7 bits each is connected through a tree - structured network to @xmath5 users each with a cache of size @xmath8 bits .
internal nodes of the tree represent routers . in this figure , @xmath138 , and @xmath11 .
the proposed placement and delivery procedures together with a routing algorithm achieves the order - optimal rate over every link @xmath139 of the network . ]
consider a directed tree network , oriented from the root to the leaves .
the server is located at the root of the tree , and users with their caches are located at the leaves .
each internal node of the network represents a router .
the router decides what to transmit over each of its outgoing links as a function of what it received over its single incoming link from its parent .
we again assume that the system operates in two phases . in the placement phase , the caches are populated without knowledge of users future demands . in the delivery phase , the users reveal their requests , and the server has to satisfy these demands exploiting the cached content .    for this network ,
we propose the following caching and routing procedures . for the placement phase
, we use the same placement procedure as in algorithm  [ alg:1 ] .
for the delivery phase , we use the two delivery procedures detailed in algorithm  [ alg:1 ] , but with the simplified decision rule explained in remark  [ remark : m ] . in other words , if @xmath140 , the server creates coded packets according to the first delivery procedure .
if @xmath141 , it uses the second delivery procedure and the server creates linear combinations of the bits of each file without coding across different files .
it remains to describe the operations of the routers at the internal nodes of the tree .
each router operates according to the following simple rule .
the router at node @xmath142 forwards a coded message over link @xmath139 if and only if that coded message is directly useful to at least one of the descendant leaves of node @xmath143 . to be precise ,
let us assume that @xmath140 so that the server uses the first delivery procedure .
thus for each subset @xmath144 $ ] of users , the server creates the coded message @xmath51 .
this coded message is useful for all users in @xmath46 and is completely useless for the remaining users .
the router located at node @xmath142 forwards this coded message @xmath51 over the link @xmath139 , if at least one of the descendants of @xmath143 ( including @xmath143 itself if it is a leaf ) is in the set @xmath46 .
a similar routing procedure is used for @xmath141 .
the performance of this scheme is analyzed in appendix  [ sec : proofs_tree ] .
we show there that , for @xmath145 , the rate of this scheme over the link @xmath139 is equal to @xmath146 where @xmath147 is the number of descendant leaves of node @xmath143 . for @xmath148 ,
it is easy to see that the rate over the link @xmath139 is equal to @xmath149    the rate over every link in the tree network can be shown to be within a constant factor of optimal . to prove approximate optimality for edge @xmath139
, we consider the subtree rooted at @xmath143 together with @xmath142 and the edge @xmath139 .
we can then use the same bound used in theorem  [ thm : comparison_converse ] over this subtree , treating @xmath139 as the shared bottleneck link .
this result shows that , for tree - structured networks , caching and routing can be performed separately with at most a constant factor loss in performance compared to the optimal joint scheme .
this means that the proposed placement and delivery procedures are universal in the sense that they do not depend on the topology of the tree network connecting the server to the caches at the leaves .
[ eg : universal ] consider @xmath5 users connected to a server through @xmath5 orthogonal links ( i.e. , no shared links ) .
for this topology the optimal rate over each link can be achieved without coding .
however , it is easy to see that the proposed universal scheme achieves the same optimal rate .
thus , depending on the network topology , we may be able to develop simpler schemes , but the performance will be the same up to a constant factor as the proposed universal scheme .    [
sec : private ] consider the original scenario of users sharing a single bottleneck link . as an example , assume we have @xmath19 files and @xmath20 users as described in example  [ eg : illustration ] in section  [ sec : main_proposed ] .
observe that a user does not need all messages sent by the server over the shared link in order to recover its requested file .
for example , in order to recover file @xmath21 , user one only needs @xmath79 and @xmath84 .
thus , if a router is located right where the shared link splits into the two private links , it can forward only these two messages over the private link to user one . by the analysis in this section ,
the resulting normalized rate over the private link to user one is then @xmath150    we note that in the uncoded scheme the rate over each private link is also @xmath38 . hence , we see that by proper routing the rate over the private links for both the coded as well as the uncoded schemes are the same
. the reduction of rate over the shared link achieved by coding does therefore not result in an increase of rate over the private links .
this conclusion holds also for general values of @xmath6 , @xmath5 , and @xmath36 .
the problem setting considered throughout this paper assumes that each user has access to a private cache . in this example
, we evaluate the gain of shared caches .
this situation arises when the cache memory is located close to but not directly at the users .
we consider a system with @xmath5 users partitioned into subsets , where users within the same subset share a common cache ( see fig .  [
fig : shared ] ) . for simplicity , we assume that these subsets have equal size of @xmath151 users , where @xmath151 is a positive integer dividing @xmath5 .
we also assume that the number of files @xmath6 is greater than the number of caches @xmath152 . to keep the total amount of cache memory in the system constant , we assume that each of the shared caches has size @xmath153 bits
.     files of size @xmath7 bits each is connected through a shared link to @xmath5 users each with a cache of size @xmath8 bits .
users are partitioned into equal subsets each with @xmath151 users .
users in each subsets share their caches . in this figure , @xmath154 , @xmath155 , and @xmath156 . ]
we can operate this system as follows .
define @xmath152 super users , one for each subset of @xmath151 users .
run the placement procedure of algorithm  [ alg:1 ] for these @xmath152 users with cache size @xmath153 . in the delivery phase ,
treat the ( up to ) @xmath151 files requested by the users in the same subset as a single super file of size @xmath157 . applying theorem  [ thm : achievable1 ] to this setting yields an achievable rate of in theorem  [ thm : achievable1 ] by replacing @xmath36 by @xmath158 ( since each cache has now size @xmath153 instead of @xmath8 ) , replacing @xmath5 by @xmath152 ( since there are @xmath152 super users ) , and multiplying the result by an extra factor of @xmath151 ( since each super file is @xmath151 times the size of a normal file ) . ] @xmath159    let us again consider the regimes of small and large values of @xmath36 of @xmath160
. for @xmath109 $ ] , we have @xmath161 comparing this to the small-@xmath36 approximation   of @xmath97 ( for a system with private caches ) , we see that @xmath162 i.e. , there is only a small effect on the achievable rate from sharing a cache .
this should not come as a surprise , since we have already seen in section  [ sec : performance_decentralized ] that for small @xmath36 , @xmath97 behaves almost like a system in which all @xmath5 caches are combined . hence , there is no sizable gain to be achieved by having collaboration among caches in this regime .
consider then the regime @xmath163 . here
, we have @xmath164 and from   @xmath165 the difference between the two approximations is only in the second factor .
we recall that this second factor represents the caching gain due to making part of the files available locally .
quite naturally , this part of the caching gain improves through cache sharing , as a larger fraction of each file can be stored locally .      up to this point
, we have assumed that in the delivery phase all users reveal their requests simultaneously , i.e. , that the users are perfectly synchronized . in practice , however , users reveal their requests at different times . in this example , we show that the proposed algorithm can be modified to handle such asynchronous user requests .
we explain the main idea with an example .
consider a system with @xmath166 files @xmath167 , and @xmath168 users .
we split each file into @xmath169 consecutive segments , e.g. , @xmath170 and similarly for @xmath22 and @xmath171 . here
@xmath169 is a positive integer selected depending on the maximum tolerable delay , as will be explained later . to be specific ,
we choose @xmath172 in this example .     and
@xmath173 , respectively . ]    in the placement phase ,
we simply treat each segment as a file .
we apply the placement procedure of algorithm  [ alg:1 ] . for the delivery phase , consider an initial request @xmath174 from user one , say for file @xmath21 .
the server responds by starting delivery of the first segment @xmath175 of file @xmath21 .
meanwhile , assume that user two requests file @xmath176 , say @xmath22 , as shown in fig .
[ fig : segments ] .
the server puts the request of user two on hold , and completes the delivery of @xmath175 for user one .
it then starts to deliver the second segment @xmath177 of @xmath21 and the first segment @xmath178 of @xmath22 using the delivery procedure of algorithm  [ alg:1 ] for two users .
delivery of the next segments @xmath179 and @xmath180 is handled similarly .
assume that at this point user three requests file @xmath181 , say @xmath171 , as shown in fig .
[ fig : segments ] . after completing the current delivery phase
, the server reacts to this request by delivering @xmath182 , @xmath183 , and @xmath184 to users one , two , and three , respectively , using the delivery procedure of algorithm  [ alg:1 ] for three users .
the process continues in the same manner as depicted in fig .
[ fig : segments ] .
we note that users two and three experience delays of @xmath185 and @xmath173 as shown in the figure .
the maximum delay depends on the size of the segments .
therefore , segment size , or equivalently the value of @xmath169 , can be adjusted to ensure that this delay is tolerable .
we point out that the number of effective users in the system varies throughout the delivery phase . due to its decentralized nature
, the proposed caching algorithm is close to optimal for any value of users as discussed in remark  [ rem : knownk ] .
this is instrumental for the segmentation approach just discussed to be efficient .
caching random linear combinations of file segments is a popular prefetching scheme . in this example
, we argue that in some scenarios this form of caching can be quite inefficient .    to be precise ,
let us focus on a specific scenario with @xmath5 users and @xmath186 files , where each user has sufficient cache memory to store half of the files , i.e. @xmath187 . according to theorem  [ thm : achievable1 ] , algorithm  [ alg:1 ] achieves a rate of less than one , i.e. , @xmath188 .    on the other hand ,
the rate achieved by caching of random linear combinations can be shown to be at most @xmath189 , which is significantly larger than @xmath97 for large number of users @xmath5 .
indeed , assume that user one requests file @xmath21 . recall that each user has cached @xmath26 random linear combinations of file @xmath21 . with high probability
, these random linear combinations span a @xmath26-dimensional space at each user and the subspaces of different users do not overlap .
for example , consider users two and three . as a consequence of this lack of overlap , these two users do not have access to a shared part of the file @xmath21 .
this implies that , in the delivery phase , the server can not form a linear combination that is simultaneously useful for three users . in other words ,
the server can form messages that are at most useful simultaneously for up to two users .
a short calculation reveals that then the server has to send at least @xmath190 bits over the shared link .
this inefficiency of caching random linear combinations can be interpreted as follows .
the placement phase follows two contradicting objectives : the first objective is to spread the available content as much as possible over the different caches .
the second objective , is to ensure maximum overlap among different caches .
the system performance is optimized if the right balance between these two objectives is struck .
caching random linear combinations maximizes the spreading of content over the available caches , but provides minimal overlap among them . at the other extreme
, the conventional scheme maximizes the overlap , but provides only minimal spreading of the content . as a consequence
, both of these schemes can be highly suboptimal .
our problem formulation focuses on worst - case requests .
in some situation , this is the correct figure of merit .
for example , in a wireless scenario , whenever the delivery rate required for a request exceeds the available link bandwidth , the system will be in outage , degrading user experience .
in other situations , for example a wireline scenario , excess rates might only incur a small additional cost and hence might be acceptable . in such cases ,
the average rate is the right metric , especially when files have different popularities .
this is discussed further in  @xcite .      in practical scenarios ,
the set of popular files is time varying . to keep the caching algorithm efficient
, the cache contents have to be dynamically updated to track this variation .
a popular scheme to update the caches is to evict the last - recently used ( lru ) file from the caches and replace it with a newly requested one .
this lru eviction scheme is known to be approximately optimal for systems with a single cache  @xcite .
however , it is not efficient for networks with multiple caches as considered here .
this problem of online caching with several caches is investigated in  @xcite .
the decentralized algorithm  [ alg:1 ] presented in this paper turns out to be a crucial ingredient of the suggested online coded caching algorithm in  @xcite .
we first prove correctness . note
that , since there are a total of @xmath6 files , the operations in line  [ alg:1_cache ] of algorithm  [ alg:1 ] satisfies the memory constraint of @xmath8 bits at each user .
hence the placement phase of algorithm  [ alg:1 ] is correct
.    for the delivery phase , assume the server uses the first delivery procedure , and consider a bit in the file requested by user @xmath45 .
if this bit is already cached at user @xmath45 , it does not need to be sent by the server .
assume then that it is cached at some ( possibly empty ) set @xmath191 of users with @xmath192 .
consider the set @xmath193 in line  [ alg:1_sloop ] . by definition , the bit under consideration is contained in @xmath53 , and as a consequence , it is included in the sum sent by the server in line  [ alg:1_send ] . since @xmath194 for every other @xmath195 , user @xmath45 has access to all bits in @xmath196 from its own cache .
hence , user @xmath45 is able to recover the requested bit from this sum .
this shows that the first delivery procedure is correct .
the second delivery procedure is correct as well since the server sends in line  [ alg:1_send2 ] enough linear combinations of every file for all users to successfully decode .
this shows that the delivery phase of algorithm  [ alg:1 ] is correct .
it remains to compute the rate .
we start with the analysis of the second delivery procedure . if @xmath197 , then in the worst case there is at least one user requesting every file .
consider then all users requesting file @xmath50 .
recall that each user requesting this file already has @xmath198 of its bits cached locally by the operation of the placement phase .
an elementary analysis reveals that with high probability for @xmath7 large enough at most @xmath199 random linear combinations need to be sent in line  [ alg:1_send ] for all those users to be able to decode .
we will assume that the file size @xmath7 is large and ignore the @xmath200 term in the following .
since this needs to be done for all @xmath6 files , the normalized rate in the delivery phase is @xmath201    if @xmath202 , then there are at most @xmath5 different files that are requested
. the same analysis yields a normalized rate of @xmath203 thus , the second procedure has a normalized rate of @xmath204 for @xmath93 $ ] .
we continue with the analysis of the first delivery procedure .
consider a particular bit in one of the files , say file @xmath50 .
since the choice of subsets is uniform , by symmetry this bit has probability @xmath205\ ] ] of being in the cache of any fixed user .
consider now a fixed subset of @xmath206 out of the @xmath5 users .
the probability that this bit is cached at exactly those @xmath206 users is @xmath207 hence the expected number of bits of file @xmath50 that are cached at exactly those @xmath206 users is @xmath208 in particular , the expected size of @xmath53 with @xmath209 is @xmath210 moreover , for @xmath7 large enough the actual realization of the random number of bits in @xmath53 is in the interval @xmath211 with high probability . for ease of exposition , we will again ignore the @xmath200 term in the following .
consider a fixed value of @xmath212 in line  [ alg:1_sloop ] and a fixed subset @xmath46 of cardinality @xmath212 in line  [ alg:1_sloop ] . in line
[ alg:1_send ] , the server sends @xmath213 bits .
since there are @xmath214 subsets @xmath46 of cardinality @xmath212 , the loop starting in line  [ alg:1_sloop ] generates @xmath215 bits .
summing over all values of @xmath212 yields a total of @xmath216 bits being sent over the shared link . substituting the definition of @xmath217 yields a rate of the first delivery procedure of @xmath218 for @xmath93 $ ] .
since the server uses the better of the two delivery procedures , and   show that algorithm  [ alg:1 ] achieves a rate of @xmath219 using that @xmath220 this can be simplified to @xmath221 concluding the proof .
recall from theorem  [ thm : achievable1 ] that @xmath222 using that @xmath223 this can be upper bounded as @xmath224 for all @xmath93 $ ] .
moreover , we have from ( * ? ? ?
* theorem  2 ) @xmath225    we will treat the cases @xmath226 and @xmath227 separately . assume first that @xmath228 .
by  , @xmath229 and by   with @xmath81 , @xmath230 hence @xmath231 for @xmath228 .
assume in the following that @xmath227 .
we consider the cases @xmath232 , \\
( \max \{1 , n / k \ } , n/12 ] , \\
( n/12 , n ] ,      \end{cases}\ ] ] separately .
assume first that @xmath233 .
by  , @xmath234 on the other hand , by   with @xmath235 , @xmath236 where in @xmath237 we have used that @xmath238 and @xmath239 .
hence @xmath240 for @xmath241 and @xmath242 .
assume then that @xmath243 .
by  , @xmath244 on the other hand , by   with @xmath245 , @xmath246 where in @xmath237 we have used that @xmath247 and that @xmath248 .
hence @xmath249 for @xmath250 and @xmath251 .
finally , assume that @xmath252 .
by  , @xmath253 on the other hand , by   with @xmath81 , @xmath254 hence , @xmath255 for @xmath250 and @xmath252 .
combining  , , , and yields that @xmath256 for all @xmath6 , @xmath5 , and @xmath257 .
as is shown in appendix  [ sec : proofs_achievable1 ] , for @xmath7 large enough the actual realization of the random number of bits in @xmath53 is in the interval @xmath211 with high probability , and where @xmath217 .
as before , we will again ignore the @xmath200 term in the following .
recall that only a subset of coded messages generated in line  [ alg:1_sloop ] in algorithm  [ alg:1 ] pass through link @xmath139 , namely only those @xmath258 for which the subset @xmath46 has at least one element among leave descendants of node @xmath143 .
we split @xmath46 into @xmath259 and @xmath260 where @xmath259 is the subset of descendant leaves of node @xmath143 , and @xmath261 .
denote the cardinalities of @xmath259 and @xmath260 by @xmath262 and @xmath263 , respectively , so that @xmath264 . with this , only coded messages with @xmath265 are forwarded over link @xmath139 .
the number of bits sent over this link is then equal to @xmath266 substituting @xmath217 yields the desired result .