# Replicating File Segments between Multi-Cloud Nodes in a Smart City: A Machine Learning Approach
## 7 Simulation and Results  
In our simulation, we apply the proposed framework on the system shown in Figure 3 with the setup in Tables 1 and 2. We assume that we have three different files \(f_{1},f_{2},f_{3}\), where these files are divided into segments as follows:\(f_{1}\) is divided into two segments  
\[f_{1}=\{s_{11},s_{12}\}\]  
\(f_{2}\) is divided into three segments  
\[f_{2}=\{s_{21},s_{22},s_{23}\}\]  
\(f_{3}\) is divided into four segments  
\[f_{2}=\{s_{31},s_{32},s_{33},s_{34}\}\]  
Table 1 shows the allocation of different file segments in different clouds and edge servers. Segment \(s_{11}\in f_{1}\) is located in three different nodes, namely, \(c_{1},c_{2}\) and \(e_{7}\). File segment \(s_{12}\in f_{1}\) is located only in \(c_{1}\). File segments \(s_{21},s_{22}\in f_{2}\) are located only in \(c_{2}\) while file segment \(s_{23}\in f_{2}\) is located in both \(c_{2}\) and \(c_{4}\). File segment \(s_{31}\in f_{3}\) is located only in \(c_{3}\). File segment \(s_{32}\in f_{3}\) is located in both clouds \(c_{3}\) and \(c_{5}\). Last but not least, file segments \(s_{33},s_{34}\in f_{3}\) are both located in cloud \(c_{3}\). From the data given in Table 1, it is easy to conclude that \(f_{1}\) exists originally in \(c_{1}\) since replication does not delete original segments and since \(s_{12}\) exists only in \(c_{1}\). This means that \(s_{11}\) was replicated to both nodes \(e_{7}\) and \(c_{2}\). The same applies for \(f_{2}\). It is obvious that \(f_{2}\) was originally located in \(c_{2}\) and \(s_{23}\) was replicated in \(c_{4}\) since the whole file \(f_{2}=\{s_{21},s_{22},s_{23}\}\) exists in \(c_{2}\) and \(s_{23}\) is the only segment of file \(f_{2}\) that exists in \(c_{4}\) as seen in Table 1. Investigating \(f_{3}\), it is obvious that it originally existed in cloud \(c_{3}\) and then \(s_{32}\) was replicated to \(c_{5}\) since the whole file \(f_{3}=\{s_{31},s_{32},s_{33},s_{34}\}\) exists in \(c_{3}\) and \(s_{32}\) is the only segment of file \(f_{3}\) that exists in \(c_{5}\) as seen in Table 1. Table 2 shows the assumed file segment lengths, where file length is calculated as follows:  
\[\kappa(f_{i})=\Sigma_{j=1}^{n}\kappa(s_{ij}) \tag{52}\]  
This means that \(\kappa(f_{1})=\kappa(s_{11})+\kappa(s_{12})=100+150=250\), \(\kappa(f_{2})=\kappa(s_{21})+\kappa(s_{22})+\kappa(s_{23})=60+110+210=360\) and \(\kappa(f_{3})=\kappa(s_{31})+\kappa(s_{32})+\kappa(s_{33})+\kappa(s_{34})=50+20 +200+120=390\) where \(\kappa\) is the length in bits. Matrix \(\tau\) in Equation (53) shows the assumed communication delays in milliseconds. \(\tau\) is a square matrix that defines the communication delays between every two nodes. If the two nodes are not directly connected, the cost is \(\infty\) since it is a topology matrix and it recognises only the connectivity between different nodes whereas if it is directly connected,  
\begin{table}
\begin{tabular}{c c c c c c c c c c c c c c c c} \hline  & \(c_{1}\) & \(c_{2}\) & \(c_{3}\) & \(c_{4}\) & \(c_{5}\) & \(e_{1}\) & \(e_{2}\) & \(e_{3}\) & \(e_{4}\) & \(e_{5}\) & \(e_{6}\) & \(e_{7}\) & \(e_{8}\) & \(e_{9}\) \\ \hline \(s_{11}\) & ✓the delay is considered. Note that the diagonal of the matrix is 0 since there is no delay for any node to itself. \[\tau=