## 4 System Model
In Figure 5, an \(FN\) is responsible for performing the security checks in order to permit an AV into parking, manage and store a massive number of transactions from the defined \(\left(EN\right)_{z,\ z=z-1}\), and record the transactions onto the blockchain. To limit the storage onto the ledger, we only recorded the hash (H) of each transaction (\(T\)) that was further chained after the successful validation through the proof of transaction. This means that each carried transaction (\(T\)) from each \(EN\) is stored in the local storage, and only the hash (H) of each \(T\) (H(T)) is recorded each time onto the blockchain ledger of an \(FN\). A transaction (\(T\)) could be of many types: an AV is authenticated, and is then authorized to enter a \(PS\), the AV uses a \(PL\), and finally, the AV exits the \(PS\); therefore, each operation performed (e.g., from parking entrance to exit) is considered a transaction (\(T\)). To carry out a transaction (\(T\)) at the \(PS\) entrance, each AV is identified via the active tag that is embedded within it, and to ensure privacy, each tag has a unique anonymous identification (\(ID\)), one-time usable session key (\(K_{ss}\)), encrypted ID (\(E(\left(ID\right)_{K_{ss}})\)), and a hash of \(IDs\) (\(H(ID)\)), such that \(\text{AV}\left\{\left(ID\right),K_{ss},\ E(\left(ID\right)_{K_{ss}}),H(ID \right)\ \right\}\); therefore, upon \(PS\) entrance, an AV transmits its \(ID,\ E(\left(ID\right)_{K_{ss}}\), and \(H(ID)\), which are considered the attributes of the AV, and an \(FN\) will verify the AV's attributes by employing the LIBC module to obtain access to the \(PS\). As the \(K_{ss}\) is of the symmetric type, in the first stage, the \(FN\) uses its \(K_{ss}\) (\(FN(K_{ss})\)), which is associated with an AV, to perform the decryption (\(D\)): \(FN(K_{ss}):\ D\left\{\ E(\left(ID\right)_{K_{ss}})\ \right\}\). Both the encryption (\(E\)) and decryption (\(D\)) operations use a unique session key (\(K_{ss}\)) so that, at this stage, the AV can be authenticated only if \(\text{AV}(K_{ss})=FN(K_{ss})\). In the second  
Figure 4: Node Configuration and Setup. stage, the integrity of the AV's ID is verified: the \(FN\) computes the hash (\(H\)) of the received AV's IDs (\(FN:\ H(ID)\)), and then compares the received hash (\(H\)) of the AV, such that \(FN:\ H(ID)\)= \(AV:\ H(ID)\). Thus, if both the hashes match, the \(FN\) can verify that the ID of the AV has not been altered. Upon successful decryption (\(D\)) and hash (\(H\)) verification, the AV will be allowed to access the \(PS\). Similarly, each \(FN\) keeps the information of that AV parking on a designated \(PL\), and finally, upon exit from the \(PS\). As per the requirements, there are four main communication scenarios that are employed to offer reliable two-way communication and manage the flow of information in the SAVP system: edge-to-fog, fog-to-cloud, fog-to-fog, and cloud-to-cloud. In the edge-to-fog scenario, the \((EN)_{z,\ z=z-1}\) read the information that can be further shared only with the designated \(FN\) in a \(PS\); therefore, the \((EN)_{z,\ z=z-1}\) are entirely dependent on \(FN\) instructions to execute the desired operations. In the fog-to-cloud scenario, the overall operations of a \(PS\) are locally managed and controlled by an \(FN\), which is an efficient intermediate node that runs the services of a \(CS\) to make the parking activities operational. Each \(FN\) in the \(PS\) was installed and configured in a way to manage the overall \(PS\) operations, without any limitations in terms of computing, storage, and power resources. However, in the long run, each \(FN\) is dependent on a \(CS\); for example, there is a massive amount of data that may be computed from the \((EN)_{z,\ z=z-1}\) and that further need to be stored as the permanent storage that is backend \(CS\) storage. Thus, after the passage of time, the computed and/or recorded data onto an \(FN\) will be transferred to the \(CS\).