## 7 Mobility Framework  
To assess the impact of using a correct naming structure can have on network mobility, nnnSIM [27; 28; 29] an implementation of 3 NA, on top of the ns-3 network simulator framework [30] is leveraged. The mobility framework was taken from [28] with a few parameters updated. The scenario consists of a single Graph of a Network (GN). The scenario includes seven wireless access points (WAPs) in a regular hexagon pattern, connected in a hierarchical fashion as is shown in Figure 6. The WAPs are 215 m apart and utilize the default WiFi implementation in the ns-3 framework for version ns-3.29, where each WAP has its own SSID. ICN CRs are connected via wired connections. The scenario tests deterministic mobility which relates to fixed public transport systems, such as trains, trans and monorails, with producers and consumers riding inside these vehicles. In the scenario, there is only one consumer and one producer, mimicking public transport systems where users connect to in-vehicle access points. The vehicles themselves have only one network interface to attach to the network and do not have CSs. The scenario is simple, making it easily reproducible and verifiable. The simplification also permits the mobility framework to quickly determine if the advantages seen in the results for the single mobile consumer with a mobile push producer use case were directly caused by the modifications made to the network naming strategies. The main disadvantage of such a simple scenario is that it does not test for multiple vehicles accessing content. Note that 3 NA capabilities derived from using 3N names are only enabled when the consumer node uses these capabilities. The network nodes obtain 3N names from the central WAP. When the network utilizes 3 NA functions, all 3 NA related buffering of PDUs, particularly during node name changes, network enrollment, dis-enrollment and re-enrollment, are turned off to be able to compare forwarding strategies. When a consumer does not use 3 NA functionalities, the wired network nodes act as regular ICN CRs using SF as described in Section 3. Another important parameter is that the size of the CS is 10 million Parts or 10.24 GB. At the Interest PDU generation rate shown in Table 4, the producer would only generate 0.3125 GB of data during the simulation, ensuring that the network could always count on CRs to respond for data quickly if the information was available. We choose a simplified handover procedure for mobile nodes. When a node travels 100 m, it checks the RSSI signal strength of the neighboring WAPs. The nodes automatically migrate to the WAP with the best signal at that point in time. When using 3 NA, migration means executing signaling procedures before and after changing WAP. The whole handover process performs appropriately during the simulation. For these procedures, the network updates its data structures, particularly the NNPTs and the NNSTs [27]. Mobile nodes move in the simulation at constant velocity with speeds from 1.4 m/s to 14 m/s, increasing by intervals of 1.4 m/s. These speeds represent inter-city velocities from average human walking speed to slightly higher than the last mile average car driving speeds. These speeds were updated due to newer average speeds published in [31]. The nodes trace the perimeter of a regular 230 m sided hexagon as is shown in Figure 6. The mobile nodes never share the same SSID as they are always at opposite sides of the hexagon. The cyclical pattern of movement permits us to compare the impact of speed and constant SSID changes on the forwarding strategies. In 2016, the second largest data streaming rate for video on the Internet was 2500 kbit/s [32]. This value was updated from the original framework to reflect the increase of video bit rate since the framework was first published. A parameter that was made explicit was the number of Interest retransmission attempts. It became important to explicitly mention the upper limit, especially when considering the retrieval of more time sensitive information.