# Stochastic Model Driven Performance and Availability Planning for a Mobile Edge Computing System
## 5 Evaluation of MEC Availability
### Base Proposal--Architecture
#### 5.1.1 Base Proposal--SPN Model  
Figure 13 presents an SPN model for the MEC architecture with the following functions: (i) _Master Server_ is responsible for receiving requests from mobile devices and distributing them among slave server nodes; (ii) _Slave Server_ is responsible for processing the data received from the master server. The components in the model correspond to the same layers presented in Figure 12. Each component has its respective MTTF and MTTR. Both _master server_ and _slave server_ were modeled, taking into account the dependency between the components; that is when a component fails the immediate transitions will trigger the next dependent components to fail as well.  
The _NCT_ marking corresponds to the number of available containers. The _slave server_ will be working when it has _NCT_ tokens in the place CTS_U (active container). The evaluator can define in the metric (with such NCT mark) how many containers must be active for the system to be working. We consider that _slave server_ is not working when it has a token in one of the following locations: HWS_D (hardware down), OSS_D (operating system down), DDS_D (docker daemon down), CTS_D (container down). Changing between active and inactive state is caused by the following transitions: HWS_MTTF, OSS_MTTF, DDS_MTTF and CTS_MTTF--for time medium to failure--and HWS_MTR, OSS_MTTR, DDS_MTTR, and CTS_MTTR--for average time to repair.  
Figure 12: Layered architecture composed of two servers.  
The _Master Server_ will be running when it has tokens in the LBM_U location (load balancer active). We consider that _Master Server_ is not working when it has a token in one of the following locations: HWM_D (hardware down), OSM_D (operating system down), LBM_D (load balancer down). The change between the active and inactive state is caused by the transitions: HWM_MTTF, OSM_MTTF, and LBM_MTTF--for mean time to failure--and HWM_MTTR, OSM_MTTR, and LBM_MTTR--for mean time to repair.  
Two metrics were applied: availability and downtime. The availability equation represents the sum of probabilities of components in the upstate. P stands for probability, and # stands for the number of tokens in a given location. The downtime (D) can be obtained by \(D~{}=~{}(1-A)\times 8760\), where A represents the availability of the system, and 8760 represents the number of hours in the year. For the availability, the system is fully functional when all containers and the LB (load balancer) are both active. Therefore, the availability is calculated by: \(A~{}=~{}P\big{(}\{\#CTS\_U~{}=~{}NCT\}AND(\#LBM\_U>0)\big{)}\).  
Guard conditions ensure that transitions are only triggered when a specific condition is satisfied. The guard condition ensures that the model reflects the behaviors of the system in the real world. For example, the transition OSS_MTTR has the following guard condition: \(P\{\#HWS\_U>0\}\), meaning that to trigger the recovery transition from the operating system, the hardware (HW) must be active. Following this example, the transitions DDS_MTTR, CTS_MTTR, OSM_MTTR, and LBM_MTTR follow the same pattern and are only activated if their respective dependency components are active. See Table 5 for more details.