## 5 Results and Discussion  
This study aimed to conduct a proof-of-concept implementation for a SAVP system to manage the parking services for AVs. For that, a SAVP system was designed and implemented in C#, the Azure cloud platform was used for the virtualization of the edge and fog nodes, and the Azure SQL database was used to manage and run the blockchain services on the cloud servers, as well as on the fog nodes. Due to resource constraints and service costs, blockchain platforms such as Ethereum or Hyperledger Fabric were not within the scope of this study. Overall, the results were simulated and conducted on a personal computer running with a 64-bit Windows 10 Professional operating system (OS) and installed with 16 GB of memory (RAM) (Intel(r) Core(tm) i7-8665U CPU @ 1.90 GHz 2.11 GHz). To compute the results, we limited the number of \(\left(EN\right)_{z,\ z=z-1}\) in the \(\left(PS\right)_{n,n=n-1}\), such that:  
\[\text{MLB}:\ \left\{\left(EN\right)_{1},\left(EN\right)_{2^{\prime}}, \left(EN\right)_{3}\right\}\in\left(FN\right)_{1}\in\left(CS\right)_{1};\]  
\[\text{ORP}:\ \left\{\left(EN\right)_{5^{\prime}},\left(EN\right)_{6^{\prime}}, \left(EN\right)_{7}\right\}\in\left(FN\right)_{2}\in\left(CS\right)_{2};\]  
\[\text{OPP}:\ \left\{\left(EN\right)_{9^{\prime}},\left(EN\right)_{10^{\prime}}, \left(EN\right)_{11}\right\}\in\left(FN\right)_{3}\in\left(CS\right)_{3}\]  
Each \(PS\) was installed with an intermedia \(FN\). In the same way, each \(FN\) was connected to a backend \(CS\) (a virtual server, in our case) to deploy the cloud services or operations closer to the \(\left(EN\right)_{z,\ z=z-1}\), and to share the carried information with the designated \(CS\). As mentioned, the SAVP system only offers parking services to registered AVs. For simplicity, let us suppose that an AV is from Tesla, which is a vehicular company that aims to start having functional AVs on the road for services such as self-driving taxis; therefore, the AV needs to register under the SAVP system to obtain the parking service of any PS, either indoors or outdoors, under the regulations of the SAVP system. To perform the AV authentication and verification as parts of the LIBC module, the given conditions, such as \(\text{FN}(K_{\text{ss}})=\text{AV}(K_{\text{ss}})\) and \(FN:\ H(ID)\)= \(AV:\ H(ID)\), need to be satisfied in Stages 1 and 2. To ensure privacy in each scenario, we assumed that each participating node had a unique anonymous identification to communicate in the SAVP system. Figures 6-8 illustrate a selective number of measurements that are computed in MLB, ORP, and OPP under the edge-to-fog scenario; a number of time experiments were performed to enable reliable access to AVs looking for parking. Figure 6 shows the results computed in 10 min; likewise, Figures 7 and 8 display the results that were measured in periods of 20 min and 30 min, respectively. Notably, the \(K_{\text{ss}}\) always expires within 2 s (maximum); thus, in order to measure a successful transaction (\(T\)), a transaction should be performed within 2 s. Therefore, from Figures 6-8, we believe that an AV that is being registered and obtaining access as per the satisfaction of authentication and verification at Stages 1 and 2 and/or as per the limits of the \(K_{\text{ss}}\) will be counted as an authorized AV to the SAVP system. In the case that an AV is not successful in authenticating its identity via the \(K_{\text{ss}}\) and verification through hash (\(H\)), the SAVP system will then deny access to that AV. However, each AV has three chances to prove its identity at the entrance of a \(PS\); otherwise, the \(K_{\text{ss}}\) will be invalid so that the AV will need to manage or request a new \(K_{\text{ss}}\) from the \(CS\), which was the only entity authorized to issue a new key in our case study. Thus, the \(CS\) is also responsible for performing the operations of a CA and KDC.