Optimization design of railway logistics center layout based on mobile cloud edge computing

Uninstall process under cloud edge collaborative computing

The de-installation process under cloud-edge collaborative computing is shown in Fig. 2. There are mainly two kinds of computing unload technology: edge computing and cloud computing. The former is to offload computing tasks to a cloud server with powerful resources that allows the users’ tasks to be processed. The latter is to unload computing tasks to an IT service environment deployed at the network’s edge for input processing. Cloud computing is deployed centralized, and resources are concentrated in a large data center. However, resources are far from users, and the latency is long.

On the other hand, the deployment of edge computing is relatively dispersed and provides low-latency services closer to the end user. Still, the resources offered by edge computing are somewhat limited. The de-installation process based on cloud-edge collaborative computing mainly consists of four parts: application task segmentation, uninstallation decision, calculation execution, and results, as shown in Fig. 2.

Given various information transmission, train scheduling, status report, and other tasks of the intelligent railway logistics center, the task segmentation section divides the whole application into multiple calculation tasks. It executes different unloading decisions for each calculation task once. According to different types of people, the tasks can be divided into independent applications among the tasks and the people. The model of the railway logistics center is shown in Fig. 3. It includes seven steps, from data collection to decision execution.

Establishment of uninstall strategy problem

Firstly, establishing the state space, which reflects the information of computing resources in the cluster and the system’s current situation, is an essential basis for the decision-making behavior of the system. Therefore, the system defines the state space based on the occupied computing resources of each server in the cluster. The state space contains the occupied rack unit (RU) number of each server in the cluster. A key parameter event is also involved in the state space. The event represents the upcoming event closely related to the state transition process. The system needs to make decisions according to the events happening in the current state. To sum up, the state space defined by this system is: (1)${\displaystyle S=\left\{s|s=\left(k_1,k_2,\dots ,k_m,\dots ,k_L,e\right)\right\}.}$ Where k_m, m ∈ [1, L] represents the number of occupied RU of the server whose serial number is m in the cluster; M is the maximum number of RU owned by the server, and L is the size of the server cluster. This parameter is used to represent the usage of computing resources.

Event e is represented as: (2)${\displaystyle e\in \varepsilon =A_1,A_2,\dots ,A_i,D_1,D_2,\dots ,D_j,\dots ,D_L.}$ Where A_i, i ∈ [1, L] represents whether a service uninstallation request is generated in the service range of the server whose serial number is i in the cluster; D_j, j ∈ [1, L] represents that a calculation task is completed and a RU unit is released in server j with serial number. The combination of D_j and A_i forms event e.

As for the establishment of behavior space, when an event occurs, the system needs to make decisions behaviors according to the current state and events. All decision-making behaviors that can be taken in the system are included in the behavior space A: (3)${\displaystyle A=-1,0,1,2,\dots ,m,\dots ,L.}$ For a given time, the decision system can wear and love the behavior contained in the behavior space set A_s: (4)${\displaystyle A_s=\left\{\begin{array}{c}-1e\in D_1,D_2,\dots ,D_L\hfill \\ 0,1,2,\dots ,m,\dots ,Le\in A_1,A_2,\dots ,A_L\hfill \end{array}\right.}$ Where A_s =  − 1 indicates that a computing task is completed and the computing resource space is released successfully; A_s = m represents that the unloading request of the current incoming computing task is unloaded to the m server for processing. Due to the development of task decomposition technology, each incoming computing task can be regarded as a minimum computing task unit, so the system uniformly assigns a RU for processing; A_s = 0 indicating that the de-installation request of the current computing task is rejected

Double-layer unloading algorithm

According to the above modeling, different unloading decisions for each task will lead to different time costs for calculating the task. Meanwhile, only when the previous task is processed can the subsequent task continue to be executed. Therefore, the following task’s unloading time depends on the last task’s decision. Because the train keeps moving in the cloud-edge collaborative computing process, the different unloading time makes the distance between the train and the base station different when the data of subsequent tasks are uploaded or sent, which leads to different communication time costs. Therefore, when optimizing the total time cost of completing the application, the unloading decision of the previous task will inevitably affect the unloading decision of the subsequent task. This article designs a serial workflow unloading algorithm suitable for cloud-edge collaborative computing mode based on this.

The pseudo-code of the algorithm is shown in Algorithm 1. Since the first task (task 0) and the last task (task N +1) must be performed on the train, this article only needs to consider unloading decisions for tasks 1 through N. Task 1 has three computing strategies: computed by onboard devices, VEC servers, or cloud computing servers. Therefore, line 3 in Algorithm 1 calculates the cost required by these three calculation methods. Based on the known unloading decisions of the previous J-1 computing tasks, lines 4 to 8 of algorithms calculate the cost of computing task j in the vehicle device, VEC server, and cloud computing server, respectively. In line 5, when the onboard device calculates task j, the time cost required by task J-1 is calculated by the onboard device, VEC server, and cloud computing server, respectively. The unloading decision with less cost is reserved for the subsequent task decision. The same goes for lines 6 and 7. Line 6 calculates the time cost of task j calculated by the VEC server, task J-1 calculated by vehicle equipment, VEC server, and cloud computing server, respectively, and retains the unloading decision that can obtain less cost for the use of subsequent task decisions. Line 7 calculates the time cost required by task j. When the cloud computing server calculates task j, task j-1 is calculated by the VEC and cloud computing servers. This process also retains the unloading decision with less cost for the subsequent task decision. Lines 9-12 calculate the time cost of task N+1 calculated by the onboard device, VEC server, and cloud computing server, respectively, and take the little cost as the final total time cost of a completed application.

Parameter setting

This article selects three unloading strategies as the reference for performance evaluation: non-unloading strategy, that is, all tasks are executed on the vehicle-mounted equipment; Full edge server offload strategy, that is, all tasks are executed on the VEC server; and the all-cloud server uninstallation strategy. All tasks are performed on the cloud server. The settings of simulation parameters are shown in Table 1.

Total time cost comparison

The difference in the location of the small area where the data transmission starts in the training cell will lead to the difference in the communication distance between the base station and the train, affecting the cost of wireless transmission and the unloading decision. Therefore, this article calculates the total time cost required for the train to start its application in all small areas and takes the average of these results for subsequent performance analysis. The total time cost at different wired transmission rates is shown in Fig. 4.

Figure 5 shows the total application completion time under the different offloading strategies. The two-layer offloading algorithm always makes the total time cost of completing the application the lowest, which shows its better performance. When the bandwidth is small, due to the long communication time, the time cost saved by the substantial computing power of the VEC server and cloud computing server still can’t make up for the cost of communication time. Currently, the cloud server de-installation strategy takes the longest time. The non-de-installation and two-layer offloading strategies only need about 40% of the time cost compared with the server uninstallation strategy. In addition, the communication cost of unloading tasks decreases, and the time saved by the VEC server’s strong computing power can make up for the cost of certain communication time. Some tasks will be unloaded to the VEC server for computing. However, due to the limitation of the wired transmission rate, the task will not be continuously unloaded to the cloud computing services. When the bandwidth provided is sufficient, compared with the non-offload strategy, the full-edge server offload strategy and the two-tier offload algorithm strategy take the same time and save more time cost. Compared with the all-cloud server uninstallation strategy with the highest time cost, the proposed strategy saves about 23% of the time cost. However, the time cost of wired transmission is still the bottleneck of continued unloading to the cloud computing server, and the task will still not be unloaded to the cloud computing services.

Time cost analysis in a fixed small area

Figure 6 shows the first task to uninstall edge and cloud servers when the bandwidth changes from 2MHz to 6MHz in a small area. With the increased bandwidth, the tasks are not calculated locally but unloaded to the edge and cloud computing servers. The first unloading task tends to happen earlier. This means that the two-layer unloading algorithm strategy can unload more tasks to the edge and cloud.

Figure 7 depicts the percentage saved by the two-layer unloading algorithm strategy compared with other strategies when the bandwidth of the train changes from 2MHz to 6MHz in the fixed small area. The proposed algorithm can effectively save the total time to complete the application, whether the train is at the edge of the cell or the center of the cell within the bandwidth taken by the simulation. When the bandwidth is small, compared with the full-edge server offload strategy and the full-cloud server offload strategy, the offload strategy proposed in this article saves more time because the limited bandwidth and the cost of wireless transmission time are high, so the vehicle-mounted equipment will complete more calculations. When the bandwidth is considerable, compared with the full-edge server offload strategy and the full-cloud server offload strategy, the offload strategy proposed in this article saves less time. However, compared with the non-offload strategy, the cost of saved time increases.