# Content Management Based on Content Popularity Ranking in Information-Centric Networks
## 3 Content Management Based on Content Popularity Ranking
### Updating the Labels of the Tags
These forms of content are already near the end of their life and have less popularity. Therefore, removing all this content should not cause any disadvantages such as cache misses in the near future. After removing all of this content, if there is enough space for caching the new content \(i\), the server nodes cache the content and break out of Algorithm 5. However, it is most likely that there may be very few forms of content, and even none may exist. In that case, if there is not enough space for storing the new content \(i\), the algorithm goes to the 2 nd step. In this step, the content with the label _short_ for the _expected lifetime_ tag but also with the label _current_ for the _life duration_ tag are selected. Then, all the content \(z\) that has both these labels and with an individual content popularity ranking \(CPR_{z}\) below the popularity threshold \(P_{TH_{n}}\) of the node \(n\) are removed together. Similar to in the previous step, if the servers can cache the content \(i\) after removing this existing content, they break out of Algorithm 5; otherwise, the algorithm continues and goes to step 3. In the 3 rd step, there should be no content remaining with the label _short_ for the _expected lifetime_ tag, excluding the content which has the label _fresh_ for the _life duration_ tag. tag, and this should not be removed before the time \(t_{new}\) expires. Therefore, the content with the label _medium_ for the _expected lifetime_ tag and the label _current_ for the _life duration_ tag are selected in this step. It is ensured by Algorithm 3 during the updating procedure of these labels that the scenario where content has the label _medium_ for the _expected lifetime_ tag but the label _stale_ for the _life duration_ tag would never occur. Similar to the 2 nd step, the content with a higher \(CPR_{z}\) than \(P_{TH_{n}}\) is excluded in this 3 rd step as well. However, unlike the 2 nd step, in the 3 rd step, the matching content is sorted from lowest to highest according to the _content popularity ranking_, \(CPR_{z}\), and only the content with the lowest \(CPR_{z}\) is selected for the removal. Then, Algorithm 5 checks whether there is enough space for caching the new content \(i\) or not. If there is sufficient space, then it breaks out of the content removal algorithm. If there is not sufficient space, it repeats the 3 rd step of the procedures, and the next existing content \(z\) with the lowest \(CPR_{z}\) is removed. Therefore, in the 3 rd step, the Algorithm 5 removes the selected content one by one until there is enough space for caching the new content \(i\) or any existing content remains that matches the mentioned conditions, instead of removing all the matched content together. In most circumstances, the server nodes should have enough repository space after finishing the 3 rd step for caching the new content \(i\). Nevertheless, if there is still a lack of capacity even after completing these steps, it goes to the last and final step, step 4. In the 4 th step, all the remaining content \(z\) is sorted in terms of the content _popularity ranking_, \(CPR_{z}\), regardless of the labels of the tags. Also, one form of content \(z\) with the lowest \(CPR_{z}\) is removed from the storage of node \(n\). This process is repeated until there is adequate storage to cache the newly arrived content \(i\). After that, Algorithm 5 completes its execution procedure, and the new content \(i\) can be stored in the server node \(n\).