## 4 Network Architecture
### A Novel Network Architecture  
To handle the inevitable handover during a long Hyperloop line, some improvements are proposed to boost the communication performance therein. As traveling across two adjacent edge clouds during a long-distance Hyperloop line, the inevitable cloud-to-cloud handover yields a certain resource migration cost. Hence, we aim to reduce the cost as much as possible by extending the CU-DU mapping relationship to a more flexible one. Generally, one edge cloud connects to several roadside AAUs + DUs through the F1 interface [39], whereas a single AAU + DU can only connect to one edge cloud, i.e., one-to-many mapping relationship [16]. Given the fact that it is economically expensive to establish a dedicated network to the Hyperloop, the communication system deployed along the Hyperloop line should also provide communication services to the nearby public cellular system or the nearby other railway lines to make full use of the equipment resources. In this regard, we upgrade the star architecture to a flexible mesh architecture. In other words, one AAU + DU can connect to more than one edge cloud in its neighbor, i.e., the many-to-many mapping relationship. Figure 6 shows the diagram of the proposed network architecture, where Figure 5(a) is a schema of the conventional one-to-many mapping relationship and Figure 5(b) presents the many-to-many mapping relationship. Compared to Figure 5(a), the many-to-many architecture enables a more flexible handover scheme. In addition, this flexible meshed architecture can yield a high safety robustness. For instance, if the link connecting cloud 1 to 3 suffers an interruption accidently, the Hyperloop can still maintain an uninterrupted connection via the link from cloud 1 to 2 and link from cloud 2 to 3. As the Hyperloop proceeds inside a cell, it will choose an edge cloud to communicate according to each cloud's real-time computational burden status as well as the topography structure. The burden status of the cloud center varies at different time even without the Hyperloop. However, compared to the ultra-high-speed of the Hyperloop, the burden status can be regarded as static within a short interval. During this interval, assume the Hyperloop travels across several cells involving \(N_{T}\) edge clouds. Consider the cloud-to-cloud handover, a weighted undirected graph can be established by abstracting the cells and edge clouds into vertex sets and abstracting the cloud-to-cloud links into edge sets. Figure 6: The diagram of the network architecture: (**a**) one-to-many; (**b**) many-to-many. As shown in Figure 6, the Hyperloop proceeds across from cell 1 to 4 successively, involving 4 nearby edge clouds, i.e., cloud 1 to 4. Figure 7 presents an abstract graph of this topographical relationship. The vertical direction means the successive passing cells along the Hyperloop line, whereas the horizontal direction denotes cloud centers. Those vertexes with deep color in one row refer to those edge clouds that are connected to the same cell. The numbers marked inside each vertex circle denote the currently available computational capability of the edge cloud. As the Hyperloop travels across two cells belonging to two different edge clouds, a group handover occurs with a resource migration cost (e.g., the drop rate, BER, throughput, etc.). The cost \(g_{cc^{\prime}}\) between edge cloud \(c\) and \(c^{\prime}\) can be calculated as  
\[g_{cc^{\prime}}=\left\{ \begin{array}{cc}0,&c=c^{\prime}\\ N_{a}D^{\prime}_{cc^{\prime}}/F^{\prime}_{cc^{\prime}},&c\to c^{\prime}\\ +\infty,&c\to c^{\prime}\end{array} \right.. \tag{6}\]  
In Equation (6), the first case indicates that no handover occurs within the same edge cloud, i.e., \(c=c^{\prime}\). The second case means that the cost is proportional to the active passenger number \(N_{a}\) as well as the normalized distance \(D^{\prime}_{cc^{\prime}}\) between these two clouds and inversely proportional to the normalized capacity of the clouds' link \(F^{\prime}_{cc^{\prime}}\).