# OPMSS: Optimal Producer Mobility Support Solution for Named Data Networking
## 5 Performance Evaluations
### Simulation Evaluation  
Simulations for OPMSS, Kite upload, and pull pattern are run for 100 s, under two scenarios with different infrastructural topology. The mobile producer is randomly moving within the bounds of the random walk mobility model for each simulation executed. In OPMSS, the restricted domain routers are placed at nodes 5, 6, 9, and 10. The consumer node is connected to node 15 for the 4 \(\times\) 4 grid topology and is connected to nodes 3 and 7 for the Abilene topology. For the Kite upload and pull pattern, the server or consumer node is connected to node 0 for the grid topology and to node 15 for the Abilene topology, while the RS node is connected to node 0 and node 1 for the grid topology and the Abilene topology, respectively. The simulation is conducted for different speeds of the mobile producer; the results are presented in Figure 6b. The results of handoff latency and data path stretching can be determined by observing the hop count distances between the consumer and the mobile producer. The average hop count result is obtained against the speed of mobile producer that is varied for the two scenarios. The results are plotted in a graph with average hop count on the \(y\)-axis against the speed of the mobile producer on the \(x\)-axis as presented in Figure 6a,b, respectively. The figures present the average hop count results that prove the solution to the path stretching problems of the Kite solution compared with the proposed OPMSS. \begin{table}
\begin{tabular}{c c c} \hline \hline
**Category** & **Parameters** & **Value** \\ \hline \multirow{4}{*}{Mobility} & Mobility model & Random waypoint mobility \\  & Mobility speed & 1–100 m/s \\  & Number of mobile nodes & 1–5 \\  & Network & 802.1 1n \\ \hline \multirow{4}{*}{NDN} & Forwarding strategy & BestRoute \\  & Cache replacement & LRU, 100 items on each node \\  & Cache size & 1000 objects \\  & Interest rate & 10/s \\  & Data packet size & 1024 bytes \\  & Interest packet size & 24 bytes \\  & Application & Consumer and producer \\ \hline \multirow{4}{*}{Topology} & Abilene & 1 Gbps link \\  & Grid 4 \(\times\) 4 & 1 Gbps link \\ \cline{1-1}  & Link delay & 10 ms \\ \hline \hline \end{tabular}
\end{table} 
Table 2: Simulation parameters and values. The results of the grid topology scenario show that when the speed of the mobile producer increases, the average hop count decreases for both OPMSS and the Kite pull pattern, while that of the Kite upload remains unstable. The overall average hop counts of OPMSS are 46% and 42% lower than those of the Kite solution, as shown in Figure 6b, and are 34% and 37% lower in Figure 7a for both the upload and pull pattern. The hop count in the Kite upload pattern is higher than in OPMSS and the Kite pull pattern; this is because in the Kite upload, the consumer must establish the trace from end to end, without a half-way trace due to the absence of an RS. OPMSS has a lower average hop count due to the advantage of \(M\)I packets being broadcast, which updates all the FIB tables of the intermediate routers and establishes an optimal route between the consumer and the mobile producer. The low average hop count proves that the proposed OPMSS has better handoff latency and solves the path stretching problem of the Kite solution for both the grid and Abilene topologies. The handoff signaling cost results for the two different scenarios are plotted on the graph; the \(y\)-axis represents the handoff signaling overhead cost, while the \(x\)-axis represents the speed of the mobile producer. Figures 7b and 8a present the average signaling overhead cost of OPMSS and the Kite solution for both the upload and the pull pattern. The results show that despite the broadcasting nature of OPMSS and the help of the domain restriction application, the outcome is encouraging. The Kite solution is considered very good in terms of having minimal handoff signaling overhead compared to the mapping-based approach and the control/data plane-based approach.