# T-Move: A Light-Weight Protocol for Improved QoS in Content-Centric Networks with Producer Mobility
## 5 Simulation Results  
To study the effect of T-Move in the CCN/NDN architecture, we simulated a network of nodes in ndnSIM, which is a popular simulator for information-centric networks. We used a random walk mobility model for the nodes in two sample network topologies--Topology 1 with a network of size 50 \(\times\) 50 m and Topology 2 with a 250 \(\times\) 250 m network. Nodes were distributed randomly in both networks. Interests are generated for 200 data objects, each of size 4 kB according to the Zipf distribution with a popularity exponent of 1.25, as suggested by [12]. Ten interests are generated per second. The interests can be for CBR (e.g., objects in a web page) or non-real-time multimedia (e.g., buffered video/audio) data. Three protocols were simulated (within a confidence interval of 95%)--T-Move, Vanilla NDN, and MAP-Me, which is also an anchorless producer mobility solution. Figures 5a shows the variation of the cache hit ratio as the number of nodes in the network changes for Topology 1, with a mobility rate of 1 m/s. Figure 5b shows the variation of the cache hit ratio as the number of nodes changes for Topology 2, with a mobility rate of 10 m/s. In both cases, the cache size was of 100 chunks, with a chunk size of 10 KB. When compared with plain NDN (Vanilla NDN), it can be seen that T-Move fares better for both topologies, especially for greater number of nodes. This is because a larger number of nodes increases the number of interests generated which in turn increases the probability of copies of data being cached. We did not consider MAP-Me when comparing the cache hit ratio, as it argues against in-network caching. (MAP-Me argues against in-network caching as this may lead to caching of unpopular content. Since T-Move ensures that only popular content is cached, in-network caching enhances the network performance instead of having a negative impact on it.) Figure 6a shows the variation of the average content retrieval time as mobility rate changes, for 50 nodes and a cache of 100 chunks with Topology 1. Figure 6b shows the variation of the average content retrieval time with mobility, for a larger network with 500 nodes and a cache of 100 chunks with  
Figure 5: (**a**) Effect of the Number of Nodes on the Cache Hit Ratio (Topology 1); (**b**) Effect of the Number of Nodes on the Cache Hit Ratio (Topology 2). Topology 2. For both topologies, the retrieval time for T-Move is lesser than that for Vanilla NDN and MAP-Me. This is because T-Move differs from Vanilla NDN and MAP-Me in two important ways:  
* it caches content based on trendiness and
* it updates FIB entries to point to the new content location or the location of a cached copy. To study the traffic in the network with T-Move, we considered Topology 1 with a fixed mobility rate of 1m/s and Topology 2 with a mobility rate of 10 m/s and calculated the average traffic in the network in a fixed simulation time and interest generation rate (10 interests/s). For both topologies, the cache size was 100 chunks, with 10 kB per chunk. Due to caching based on trendiness, T-Move results in lesser traffic (Figure 7) compared to Vanilla NDN or MAP-Me for both topologies. This is because with T-Move, data is cached close to where it might be used, in addition to mobility support with minimal FIB updates. This reduces the number of hops taken by interests and data objects to reach the (cached) data object or consumer, respectively. Though T-Move has more control message overhead (in terms of GETT and REPT messages), it performs better than Vanilla NDN or MAP-Me because of the above reason. It can also be noted that as the network size and mobility rate increases, T-move fares much better than Vanilla NDN or MAP-Me. Figure 6: (a) Effect of Mobility Rate on Content Retrieval Time (Topology 1); (b) Effect of Mobility Rate on Content Retrieval Time (Topology 2). Figure 7: Average traffic for Topologies 1 and 2.