## 5 Results and Discussion
To achieve the desired study goals, a number of experiments were conducted in a situation that bypassed the \(FN\) operations so that the \(\left(EN\right)_{z,\ z=z-1}\) were directly connected to the \(CS\). To perform this, careful checks on the performance latency and efficiency of the SAVP system were kept in mind. Figure 9 demonstrates the results that were  
Figure 8: AV access rates per session key: session key = 2 s; time period = 30 min. Figure 6: AV access rates per session key: key session = 2 s; time period = 10 min. Figure 7: AV access rates per session key: session key = 2 s; time period = 20 min. computed during the successful exchange of information from the \(\left(EN\right)_{z,\,z=-1}\) to the \(CS\) (for example, AV identification over the parking entrance without having enrollment in the \(FN\)). The selective measurements of Figure 9 show that the computed latency is almost twice the results computed in the edge-to-fog scenario. However, similar to other computed performances, the results of Figure 9 were also measured in the absence of any network obstacles or communication errors. In the SAVP system, each successful transaction (\(T\)) is recorded onto the blockchain, and the proof of transaction is performed over the neighboring fog nodes: \(\left(FN\right)_{t,\,t=t-1}\). Let us suppose that the parking stations, or \(\left(PS\right)_{n,n=n-1}\), are regulated under the control of the SAVP system so that the SAVP system becomes a collaborative decentralized platform, where fog-to-fog and cloud-to-cloud scenarios operate together to share various resources, as well as to keep copies of all the transactions that are performed as part of the SAVP system. To offer a reliable parking solution, there are always three main transactions: AV\(\left(T_{1}\right)\), AV\(\left(T_{2}\right)\), and AV\(\left(T_{3}\right)\), which are usually executed in a cascading manner: AV\(\left(T_{1}\right)\rightarrow\) AV\(\left(T_{2}\right)\rightarrow\) AV\(\left(T_{3}\right)\). AV\(\left(T_{1}\right)\) is performed upon entrance to the \(PS\) via the LIBC module, AV\(\left(T_{2}\right)\) is performed on the designated \(PL\), and AV\(\left(T_{3}\right)\) is fulfilled at the parking exit. These transactions are recorded first onto the \(FN\) or \(\left(FN\right)_{1}\) locally, and are then recorded onto other fog nodes, such as \(\left(FN\right)_{2},\,\left(FN\right)_{3}\), and so on, as the successful operations of the proof of transaction. By doing so, all fog nodes, or \(\left(FN\right)_{t,\,t=t-1}\), keep an updated record of each AV that requested parking in any parking stations, or \(\left(PS\right)_{n,n=n-1}\). Thus, the fog nodes are always updated with new information that may be carried on any fog node that is associated with a distinct cloud. Likewise, cloud servers obtain updated information via their associated fog nodes' time-to-time and can perform the validation or the proof of transaction through the confirmation that all the clouds have replicated data carried from their associated fog nodes. To minimize the storage space in an \(FN\), each transaction (\(T\)) that carries data (for example, some random bits) is first recorded onto the \(FN\) and is then transferred to the \(CS\) after a specific time session, whereas the hash (\(H\)) of each transaction (\(T\)), or \(H(T)\), is only chained and replicated to other neighbor fog nodes. In this way, an \(FN\) can minimize its storage. Table 1 depicts a number of successful transactions (\(T_{x}\)), where \(x\) is a fixed value that is recorded onto the fog nodes, and then onto cloud servers. Let us suppose that \(\left(FN\right)_{1}\) performed the transactions (\(T_{x}\)) so that successful \(T_{x}\approx 1\) are first recorded onto \(\left(FN\right)_{1}\), and then onto neighboring fog nodes (i.e., \(\left(FN\right)_{2},\,\left(FN\right)_{3},\,\ldots\,\,\left(FN\right)_{l-1}\)). This situation is similar to recording transactions (\(T_{x}\)) onto cloud servers.