# Content Management Based on Content Popularity Ranking in Information-Centric Networks
## 3 Content Management Based on Content Popularity Ranking
### The CPR Mechanism
The servers can automatically categorize the available content in terms of the contenttypes and assign the appropriate label to each of the content types. The labels included within this tag are shown in (1). \[T(x)=\{video,audio,text\} \tag{1}\]  
We considered the _expected lifetime_ of the content to calculate the CPR, as it plays a vital role in deciding which content should be cached for a long time and which content may be erased when there is a lack of space. The _expected lifetime_ of content, expressed by \(E\), can be easily assigned when that content is generated, and over time it can be reevaluated based on the criterion given in Section 3.3. Typically, all content may be allocated a general lifetime duration by the server administrator based on the traffic load and the storage size of that server. However, some content may already be expected to become popular in the long run, such as new releases from already popular franchises, statistical articles related to hot topics at the current time, or long-lasting general guideline information on various issues. These forms of content need to be stored at the server repositories for as long time as possible because users may keep requesting these for some time. In contrast, some other content created to serve a specific purpose for a limited time, such as guidelines for online applications and daily news updates, may have a lower lifetime expectancy to start with. Therefore, we created four labels for the tag _expected lifetime_, which are _long_, _medium_, _short_, and _zero_. These labels specify how much more time the content is expected to be popular on the Internet. The label _medium_ indicates the assigned general lifetime for typical content within a server repository. The labels _long_ and _short_ mean a higher and lower _expected lifetime_ allocated explicitly to the content, although no content may be assigned any of these two labels at the beginning in a particular server repository as well. Besides, the label _medium_ of content may change to _long_ or _short_ over time based on the criterion explained in Section 3.3, as the popularity of the content may increase or decrease. Finally, the label _zero_ asserts that the content was not popular at all over some time, and it may be removed from the server repository immediately. This label is not assigned to any content initially; instead, it may be allocated later based on the condition given in Section 3.3. The labels of this tag are given in (2). \[E(x)=\{long,\ medium,\ short,\ zero\} \tag{2}\]  
Besides considering the remaining lifetime, the elapsed duration since certain content was published is also essential in deciding the potential popularity of that content, as even popular content loses its popularity over time and non-popular content fades away into oblivion. We argue that new content that has just become available on the Internet and stored at a server repository should be given some time before being considered for removal, even when there is a lack of space at that server repository. The rationale behind this is that the newly created content may soon become popular among the users if given time. Removing this content would mean regular cache misses, and frequent retrieval of the same content might be needed. Therefore, a _life duration_ tag was created that includes three labels that essentially indicate the age of the content and the popularity of that content. All the new content automatically gets the label _fresh_ and only this label from the _life duration_ tag is assigned to content at the beginning. The other two labels, _current_ and _stale_, are allocated to content over time after reevaluating the popularity of that content based on the criterion explained in Section 3.3. The _fresh_ content is not removed from the repository over an allocated time, the _stale_ content is predominantly selected for removal, and the _current_ content is also considered for removal when a lack of space in the repository persists.