A cyber-resilient and privacy-preserving session protocol for connected vehicles in software-defined edge infrastructure

Abstract

Connected and software-defined vehicles now rely on edge infrastructure for access, payment, and identity-linked services. Entry and exit at a parking facility are two of the most frequent points at which a vehicle transacts with that infrastructure, and each carries financial and privacy risk: a plate may be read incorrectly, a payment request may arrive twice, the cloud link may drop, and plate-payment records may stay linkable long after the vehicle has left. We describe a cyber-resilient session protocol built for software-defined vehicular edge infrastructure. The vehicle on-board unit exchanges entry, payment, exit, and closure messages with a roadside edge service over IEEE 802.11p. On the edge side, a short-lived pseudonymous token holds the session together; payment and exit invariants are enforced locally, state is cached while the cloud is unreachable, and injected low-confidence automated license-plate recognition (ALPR) events are routed to a review queue. We modeled the control logic in UPPAAL 5.0.0 as a single-session FogController paired with a receipt deadline observer. The verified properties cover duplicate payment exclusion, penalty exclusion after payment and during dispute, exit-induced session closure, synchronization consistency, deadlock freedom, eventual receipt completion, and absence of receipt deadline violations. A single 11,000-s SUMO/OMNeT++/Veins run then instantiated 200 vehicles across four controlled pre-transmission loss cohorts of 0%, 5%, 10%, and 20%. Of those, 159 sessions became active, 135 payment confirmations and 132 receipts arrived, and 74 sessions completed end to end. Mean application-level response times were roughly 50 ms for token, payment, duplicate payment, and exit responses, and 100 ms for receipts. Injected fault paths comprised 19 uncertain-ALPR events, 8 duplicate payment rejections, 10 fog-cloud outages with a configured 10-s recovery interval, and 5 exit mismatches with a configured 5-s review interval. The two evaluations give complementary formal safety and wireless execution evidence. They also show that one-shot messaging without retransmission limits both completion and token-revocation reliability under loss.

1 Introduction

In most smart-city work, parking is filed under services. For a connected or software-defined vehicle, it functions as a vehicle-to-infrastructure (V2I) transaction, one that repeats every time the driver arrives or leaves. The vehicle and the roadside infrastructure communicate with each other across many different parameters in one session, including time, location, access rights, payment, and identity evidence. The control path must respond quickly enough to raise a gate. It must remain consistent when the radio link or the cloud connection fails. It should also avoid building a durable record that ties a driver to a plate and a payment history. These three demands pull against one another.

Automated license-plate recognition (ALPR), occupancy sensing, mobile applications, and cloud payment services are already being used in smart parking systems. The failure modes at the transaction layer receive far less attention. A violation may be recorded when a plate reading is uncertain. A payment request sent twice can turn into a billing dispute. A session can get stuck halfway through if a payment or an exit response is lost. A plate that stays attached to a payment account creates a mobility-finance trail. These effects remain small in an isolated installation of camera and barrier. They grow once parking becomes a connected-vehicle service.

This problem is well addressed by software-defined vehicular networking and vehicular edge computing, as the session logic that must be quick can sit close to the vehicle and the access point. In our design, the vehicle on-board unit (OBU) requests a short-lived token and then exchanges session messages with the edge application located at the roadside. The edge holds the authoritative view of the active session. It verifies its invariants before committing to a payment or an exit decision; it maintains its records locally when the cloud is not available; and it forwards uncertain evidence to review.

The pattern generalizes beyond parking. Connected aerial vehicles, autonomous delivery drones, charging stations, and edge-managed vertiports must all address temporary authorization, local sensing, confirmation that a payment or service went through, and a safe method for handling evidence they cannot fully trust. For these reasons, we choose to use a ground-vehicle parking facility as a bounded case study. The pattern could be adapted to aerial vehicles, which we leave as future work and present here as such.

We make four contributions. The first is an SDV-to-edge session architecture in which the OBU and the roadside edge application exchange pseudonymous entry, payment, exit, and closure messages. The second is an ALPR uncertainty-aware decision policy that forwards injected low-confidence or inconsistent recognition events to entry or exit review, while the automatic penalty transition is blocked by a guard. Third, we verify a single-session control model in UPPAAL, introducing a dedicated observer for receipt deadlines, thereby explicitly stating the timing claim. Fourth, we run the request-response exchange over an actual IEEE 802.11p stack in SUMO/OMNeT++/Veins, across four cohorts of pre-transmission message loss and report the message delivery, response time, lifecycle progression, fault handling, and edge-cache estimates.

The remainder of this article is organized as follows. Section 2 reviews the work on smart parking, ALPR uncertainty, privacy, vehicular edge computing, and formal verification. Section 3 outlines the architecture, threat model, session protocol, UPPAAL model, and co-simulation setup. Section 4 summarizes the formal and communication results, Section 5 deals with the implications and trade-offs, Section 6 states the limitations and what we plan to do next, and Section 7 concludes the article.

2 Related work

2.1 Smart parking systems and operational limitations

Smart parking architectures encompass bay discovery, fee calculation, navigation, sensing, and integration with mobile services (Al Mamun et al., 2024; Elfaki et al., 2023; Singh and Parihar, 2024), while fog-supported designs reduce reliance on a remote cloud for access decisions that cannot wait (Afzal et al., 2025; Ala’anzy et al., 2025). The session itself is less examined. This collection of work is dominated by occupancy, recognition accuracy, and service automation (Pradhan et al., 2025), while explicit invariants for duplicate payment, receipt completion, dispute handling, outage recovery, and final closure are rarely stated.

A parking interaction is a stateful, financial, and access-control transaction. We are studying the protocol that runs at the edge. It separates routine pseudonymous control from long-term identity storage, and it allows a selected set of unsafe transitions to be checked formally. Occupancy sensing and payment application design are outside the scope of the work.

2.2 ALPR uncertainty, adversarial handling, and decision policy

Deep-learning detectors and OCR pipelines have improved ALPR performance (Meesad and Thumthong, 2025), and they now run on resource-constrained edge devices (Satya et al., 2025). Recognition stays fragile in the ways it has always been fragile: lighting, camera angle, dirt, occlusion, blur, reflective plates, and domain shift all degrade it. When the output of that pipeline is used to authorize a payment or open an exit gate, the confidence value attached to it should be handled as evidence and given proportionate weight.

Adversarial plate perturbations (Qian et al., 2019) strengthen the case for defensive decision logic. Our contribution at this layer is a protocol policy: events that are low-confidence, noisy, inconsistent, or otherwise suspicious are kept as evidence and passed to review. Building or benchmarking an ALPR model falls outside the present scope. In the experiment reported below, these events are injected deterministically, and we evaluate no image dataset and no recognition model.

2.3 Privacy and non-repudiation in parking transactions

A parking record ties together a user account, payment details, a place, and a time, and a run of them becomes a mobility-finance history. Dzurenda et al. (2022) approach this through privacy-preserving parking services designed against European data-protection requirements; blockchain-based schemes approach the topic from the perspective of auditability and integrity (Durairaj et al., 2025; Shahzad et al., 2022). FedVR360 (Khan et al., 2026) offers a considerably stronger privacy mechanism for vehicular edge learning, combining federated learning with Rényi differential privacy. Our problem is narrower than either. We are trying to reduce direct-identifier exposure while a transaction is live, using short-lived pseudonymous session identifiers.

Anonymity and unlinkability lie outside what the design proves. Under defined exception conditions, the cloud, or an authorized operator, can still tie a token back to a registered profile. Our privacy claim is correspondingly limited: pseudonymization reduces identity exposure and keeps routine edge control separate from long-term records. Differential privacy guarantees and ledger-based auditability are different claims.

2.4 SDV edge infrastructure

Software-defined vehicular networks bring programmable networking together with vehicular communication (Ben Jaballah et al., 2019), and vehicular edge computing moves selected control and computation close to the vehicles themselves (Lin et al., 2021). Our parking service follows that split: time-sensitive session state stays at the roadside edge, while registration, settlement, and long-term audit stay in the cloud.

Zhang et al. (2025) take up the trade-off between security and latency in the Internet of Vehicles (IoV), integrating blockchain with edge computing and then optimizing away the latency that consensus and encrypted processing introduce. Our design puts no blockchain transaction behind a gate event, relying on a local session table and a receipt record. Architectural complexity drops, as does the strength of the guarantee: we have no distributed-ledger consensus and no equivalent immutability.

2.5 Formal verification of IoT and vehicular edge protocols

A simulation covers the executions it happens to run. Establishing that no unsafe state is reachable calls for a different instrument. UPPAAL timed automata have been applied across a wide range of verification problems (Grobelna et al., 2025), including the formalization of access-control models for IoT environments (Krakallah and Nait-Bahloul, 2025). They fit this controller because the properties at stake (duplicate billing, penalty exclusion, receipt response, synchronization, exit closure, and freedom from deadlock) are all state and timing properties. The executable model abstracts away the internals of the ALPR, payment provider, cryptographic, cloud, and barrier components; that abstraction is deliberate.

We do not claim novelty for the individual components, nor for their combination alone. The specific contribution is that the uncertainty-aware ALPR policy and the payment and exit invariants are expressed as machine-checkable properties and discharged against a timed-automata model, and that the same protocol path is then executed over a wireless vehicle-edge link. Table 1 sets this against the closest existing protocols on primary focus, vehicle orientation, uncertainty, and privacy handling, and the formal or session-level guarantee each provides. UPPAAL and SUMO/Veins run independently, with no coupling at runtime. One explores every reachable state of a single parameterized session controller; the other runs message exchanges for many moving vehicles under a fixed radio configuration and controlled loss cohorts.

3 Materials and methods

3.1 Proposed infrastructure architecture

The system is a software-defined edge session protocol serving both registered and guest vehicles. A registered vehicle may keep a cloud profile and a payment account; a guest vehicle uses a temporary transaction path: a web link, a kiosk, a QR code, or a mobile application. Either way, the active session lives at the roadside edge service, which performs the decision checks locally.

Six functional layers make up the architecture: (1) the vehicle/SDV layer, holding the driver interface, the OBU, and the session application; (2) sensing and actuation (ALPR cameras, occupancy or gate sensors, and the physical barrier); (3) the V2I communication layer; (4) the edge/fog session service; (5) cloud registration and payment services; and (6) audit and dispute handling. Our final Veins implementation instantiates the vehicle application together with a single roadside unit (RSU) edge application, and passes entry, payment, exit, and closure messages between them through the IEEE 802.11p stack. Figure 1 shows the layered architecture, and Table 2 lists each component and its function.

FIGURE 1

Inside the edge application is a per-vehicle session table carrying token, active, paid, receipt, exit, outage, and mismatch state. From that table, the application issues a regular token or a temporary token where an uncertainty event has been injected; it turns down a second payment request once the session is marked paid; it schedules synchronization after a configured cloud outage; and it authorizes exit only when the local payment and receipt checks pass. Once the vehicle reaches SessionClosed, a best-effort closure notice goes back to ask for the token to be revoked.

3.2 Threat model, trust boundaries, and token lifecycle

We assume an adversary who can replay or duplicate application messages, drop or delay messages, present plate and token evidence that does not agree, obscure or perturb a plate, steal a session token, and cut fog-cloud connectivity. Under that assumption, the vehicle-to-RSU wireless channel and the cloud link are both untrusted transport domains. The formal and simulation models do assume the proper functioning of the FogController/RSU application, the local clock, session state storage, and the cryptographic primitives. A fully compromised OBU, RSU operating system, cloud administrator, payment provider, camera, or barrier controller is outside of the verified trust boundary.

Tokens are intended to be short-lived and bound to a particular session. The duplicate payment state is rejected at the edge, and once the session has closed locally, the vehicle sends a SessionCloseNotice for the RSU to mark the token revoked. The final experiment uses one-shot messages, with no acknowledgment and no retry, so even if the session is closed cleanly on the vehicle side, the RSU may still have a live token. This is explicitly described in the results.

3.3 Session tokenization and privacy model

An identifier for each parking interaction is used in place of the plate and the associated payment account in the routine edge key. The edge creates a short-lived token once detection and the uncertainty decision are complete. For a registered vehicle, the cloud could map the token to the long-term profile, and the token for a guest vehicle would simply identify the temporary transaction path.

While a session is active, its edge record carries the token, vehicle hint, payment state, receipt state, dispute state, synchronization state, and the lifecycle flags. The Veins implementation also stores the number of active sessions and a serialized-record byte estimate. That estimate is reproducible and measures representation size. The amount of C++ heap memory is not reported and is a separate quantity. The scheme reduces routine use of direct identifiers, and formal anonymity and unlinkability are distinct attributes that remain unproven.

3.4 ALPR reliability index and adversarial handling

For a plate recognition event, let Ri be a conceptual edge-side reliability score. It could rely on the confidence level of the ALPR model, the quality of the image, the agreement of the auxiliary gate sensors, and whether the reading is consistent with the current token and the direction of travel we would expect. In this experiment, images are not used to calculate Ri. Selected vehicle identifiers trigger low-confidence protocol events deterministically instead.

A simplified representation is

The suspicion term grows with evidence of obstruction, odd texture, sensor disagreement, or repeated recognition failure on the same vehicle. These are architectural requirements of a perception implementation that we have yet to build; nothing in this dataset-free experiment measures them.

Evidence that the policy deems reliable enough maps to TokenIssued or ExitVerified. Uncertain entry evidence is passed on to EntryDisputeReview and may come back as TemporaryTokenIssued, while uncertain exit evidence is passed on to ExitDisputeReview and then to ManualResolution. A penalty transition is never authorized when confidence is low.

The protocol then reacts defensively. Uncertain evidence is logged, irreversible financial or penalty action is not taken, and the review path is taken instead. Our claims involve the correctness of that route of decision making, not the accuracy or robustness of the underlying ALPR neural network.

3.5 Parking session state model

Every parking interaction is a finite-state session. The normal sequence runs Idle, EntryRequest, ALPRChecked, TokenIssued, SessionActive, ParkingStarted, PaymentConfirmed, ReceiptGenerated, ExitRequested, ExitVerified, and SessionClosed, followed by TokenRevoked once a closure notice reaches the RSU. VehicleDetected and PlateCaptured are conceptual sensing steps that Figure 2 shows collapsed into EntryRequest. Branching off the normal sequence are the exception pathways: LowConfidenceALPR, EntryDisputeReview, TemporaryTokenIssued, DuplicatePaymentIgnored, NetworkOutage, SyncPending, CloudSynchronized, ExitMismatch, ExitDisputeReview, ManualResolution, and the constrained penalty path through PenaltyEligible, PenaltyIssued, and SessionClosedWithPenalty. Figure 2 shows the session lifecycle, and Table 3 defines every state.

FIGURE 2

A handful of transitions are ruled out by construction. Neither a confirmed payment nor an active dispute can lead to a penalty. A duplicate request cannot push paidCount past one. An exit mismatch cannot complete the exit before dispute mode is entered. A verified exit clears the active-session flag. Receipt completion and synchronization carry liveness and consistency properties on top of these.

3.6 Formal verification with UPPAAL

We ran the formal verification in UPPAAL 5.0.0 (revision 714BA9DB36F49691) on Microsoft Windows 11 Home. The executable system includes two templates, FogController and ReceiptObserver, declared as “system FogController, ReceiptObserver.” FogController represents a single parameterized parking session and works on paidCount, paymentDone, receiptDone, waitingReceipt, rclk, lowALPR, disputeMode, penaltyDone, exitMismatchFlag, exitDone, sessionActive, networkDownFlag, syncPending, syncCompleted, and synced. ReceiptObserver maintains its own clock, obsClk, and synchronizes on paymentConfirmedEvt and receiptGeneratedEvt. Figure 3 shows the structure of the verified model.

FIGURE 3

When the payment is confirmed, the observer goes to Waiting. Transitions go to ReceiptObserved when either of the receipt-producing controller edges emits receiptGeneratedEvt, and they enter DeadlineMissed if obsClk passes five model time units. The queries we ask relate to safety, reachability, liveness, bounded response, synchronization, and deadlock. The model verifies the controller’s behavior with respect to abstract events. ALPR/OCR internals, token cryptography, payment provider correctness, the cloud implementation, camera hardware, and the physical barrier all lie outside it. In SUMO/Veins, the concurrency of multiple vehicles is handled, while UPPAAL instantiates a single session.

3.7 SUMO/Veins co-simulation setup

The co-simulation ran on OMNeT++ 6.3.0 with Veins 5.3.1 (Sommer et al., 2011), under WSL on a Windows 11 host. SUMO generated 200 vehicles, 50 parking bays, two entry gates, and two exit gates across an 11,000-s horizon, with a single RSU placed at (178, 67, 3) m. We fixed the IEEE 802.11p configuration at 20 mW transmit power, 6 Mbps bitrate, a −98 dBm noise floor, a −110 dBm minimum power level, a SimplePathlossModel with exponent 2.0, and a 5.890 GHz center frequency, with propagation delay enabled. Periodic beacons and vector recording were switched off. The OMNeT++ seed was 20260802; the SUMO launch seed was 0. Figure 4 shows the co-simulation setup.

FIGURE 4

Vehicle identifiers assigned each vehicle to one of four controlled, independent pre-transmission loss cohorts at 0%, 5%, 10%, and 20%. We applied the injection to smart parking requests and RSU responses before sendDown; anything left undropped went through the Veins IEEE 802.11p stack as normal. Separate CSV logs captured attempted messages, injected drops, packets handed to IEEE 802.11p, peer receptions, response round-trip time, lifecycle states, fault states, and cache snapshots. This is a single reproducible sensitivity run. Fading, C-V2X, high congestion, and multi-seed statistics lie beyond its design.

4 Results

4.1 UPPAAL verification outcomes

Every UPPAAL query in Table 4 came back satisfied. Duplicate charging is excluded by the invariant A[] paidCount <= ≤1. Penalty after a confirmed payment and penalty during review are excluded by A[] paymentDone imply !penaltyDone and A[] disputeMode imply !penaltyDone. Exit safety rests on three properties: A[] exitMismatchFlag imply disputeMode, A[] exitMismatchFlag imply !exitDone, and A[] exitDone imply !sessionActive.

Receipt liveness no longer rests on the clock constraint alone. The leads-to query paymentDone receiptDone was satisfied. Reachability queries confirmed that both ReceiptObserver.Waiting and ReceiptObserver.ReceiptObserved are executable, and A[] not ReceiptObserver.DeadlineMissed held. A[] waitingReceipt imply rclk <= 5 constrains the controller’s receipt-waiting clock, but we read it only as a state-clock constraint and nothing stronger.

The network properties A[] networkDownFlag imply !synced, A[] syncPending imply !synced, and A[] syncCompleted imply synced were all satisfied, as were reachability of FogController.CloudSynchronized and FogController.SessionClosed and global freedom from deadlock. All of this holds for the single-session timed-automata abstraction. None of it speaks to the internal correctness of the external sensing, payment, cryptographic, cloud, or actuation components.

4.2 Mobility and communication-aware simulation results

All 200 vehicle applications were initialized in the 11,000-s run. SUMO inserted all 200 vehicles and reported none still active after a simulation time of 9,896 s. Protocol-layer counts came out lower: 159 vehicles received a regular or temporary token and entered SessionActive, and 159 recorded ParkingStarted; 135 vehicles received PaymentConfirmed, and 132 received ReceiptGenerated; 74 vehicles received ExitVerified and reached local SessionClosed. One-shot message loss with no retransmission behind it accounts for the gap between physical trip completion and protocol completion because the mobility horizon itself was long enough. Table 5 reports the full configuration and the protocol outcomes.

Response-side end-to-end success fell from 95.58% in the 0% injected-loss cohort to 91.52%, 86.40%, and 75.25% in the 5%, 10%, and 20% cohorts, respectively. Completed sessions dropped alongside it: 27/50 (54%), 24/50 (48%), 16/50 (32%), and 7/50 (14%). Request-side end-to-end success stayed between 73.08% and 77.99%. Channel delivery, measured after excluding the deliberate drops, was not monotonic across cohorts because each cohort produced a different mix of entry, payment, exit, and closure opportunities: a message lost early stops the later stages from ever being attempted. Mean round-trip time came to roughly 0.05048 s for token, payment, duplicate payment, and exit responses, and 0.10048 s for receipts. Table 6 gives the per-cohort delivery and completion counts, and Table 7 gives the aggregate response times.

4.3 Fault and dispute behavior

The RSU logged 19 injected LowConfidenceALPR and EntryDisputeReview events, of which 17 temporary token responses were successfully transmitted to a vehicle. Eight duplicate payment rejections were received. Ten NetworkOutage events ran through SyncPending to CloudSynchronized once the configured 10-s recovery interval had elapsed, and five ExitMismatch events passed through ExitDisputeReview to ManualResolution after the configured 5-s review interval. Edge state peaked at 176 active sessions, with a peak serialized cache estimate of 6,118 bytes, or roughly 34.8 serialized bytes per active record. Closure notification performed poorly: although 74 vehicles reached local SessionClosed, only five SessionCloseNotice messages arrived at the RSU and produced TokenRevoked, which shows that best-effort notification does not survive loss. Figure 5 traces the lifecycle counts across the run.

FIGURE 5

The two tools supply different kinds of evidence. UPPAAL establishes the stated invariants and timing properties for the abstract single-session controller. The co-simulation shows that the matching request, response, uncertainty, outage, dispute, and duplicate payment paths execute over IEEE 802.11p. A simulation trace could still violate a formal property, and the co-simulation cannot rule that out. The two tools have no dynamic coupling.

5 Discussion

We have developed an edge-resident session protocol for connected vehicles. The OBU participates in negotiating the token, the RSU application holds the programmable session state, and the ALPR output enters the system as uncertain evidence bound by protocol constraints. Our previous evaluation focused only on events. The current implementation improves on it by pushing smart parking requests and responses through the Veins IEEE 802.11p stack.

The state at the edge provides continuity during short cloud outages: the session survived in simulation, and synchronization completed once the configured recovery interval had passed. The 0.05 s configuration for the RSU processing time, combined with the 0.10 s configuration for the receipt generation time, directly yields a small communication overhead on the successful response paths. These are simulation parameters plus wireless execution time. The numbers would differ for a deployed payment provider or cloud service.

The privacy contribution is selective pseudonymization. Routine edge decisions operate on a short-lived token and a minimal session record, while long-term registration and audit sit apart from the identifier used at the gate. FedVR360 has more formal privacy with differential privacy, and GDPR-oriented parking work reaches further into legal compliance than we do. The one quantity our design does report is the operational edge-state footprint, which is a peak serialized estimate of 6,118 bytes across 176 active sessions.

The loss cohorts reveal an engineering compromise. The safety checks may remain accurate while availability degrades underneath them. If a token, payment, receipt, exit, or closure message is lost, the session halts without causing duplicate billing or an unsafe formal transition. Safety holds even as the service becomes less useful. This effect is directly reflected in the token-revocation counts, and a broader RSU coverage, persistent revocation queues, or acknowledgments will be required before deployment. Our results establish the feasibility of the protocol path and locate its resilience gaps. The fixes above would be needed for production readiness.

6 Limitations and future work

Five limitations bound what we can claim. The UPPAAL model represents one parameterized session and abstracts the payment provider, the camera and OCR engine, the cryptographic token generator, the cloud implementation, the mobile application, and the barrier actuator. Low-confidence ALPR events are injected, with no real or benchmarked image dataset behind them. The communication evaluation is a single fixed-seed run with one RSU, a simple path-loss model, no periodic beacon load, and controlled pre-transmission message loss; fading, interference, congestion, C-V2X, and multi-seed comparisons are outside it. A SUMO route continues even when a protocol message is lost, so it does not model physical barrier enforcement. Pseudonymous tokens stay linkable by authorized cloud services, and we offer no anonymity or unlinkability proof.

Reliable messaging is the first thing to fix. The next implementation needs acknowledgment-based retransmission, idempotent request identifiers, timeout recovery, persistent token-revocation queues, and either multiple RSUs or direction-specific ones. Experiments after that should vary transmit power, path loss, fading, channel load, interference, vehicle density, and random seeds, and should set IEEE 802.11p against a suitable C-V2X model. Real memory use and real cryptographic processing cost should replace our serialized-record estimates.

On the perception side, the uncertainty-aware decision policy needs testing against real dirty plate, low light, occlusion, and adversarial-perturbation datasets, and review workload, false escalation, and decision delay all need measuring. Trusted execution environments are a plausible way to protect token generation and local state. The same formally constrained session pattern could later be adapted to aerial-vehicle landing, charging, or maintenance services, although that extension would need its own sensing, communication, and safety validation before it could be considered reliable.

7 Conclusion

This article set out a cyber-resilient, pseudonymization-based session protocol for connected vehicles operating in software-defined edge infrastructure. UPPAAL verification of the single-session FogController together with the ReceiptObserver satisfied the duplicate payment, penalty exclusion, exit closure, synchronization, receipt liveness, deadline, reachability, and deadlock properties. A SUMO/OMNeT++/Veins run then carried smart parking messages over IEEE 802.11p for 200 vehicles across four controlled loss cohorts, recording 159 active sessions, 135 payment confirmations, 132 receipts, and 74 complete local closures, with response times of roughly 50 ms for most responses and 100 ms for receipts. The uncertainty, duplicate payment, outage, and ExitMismatch paths all behaved as designed. The incomplete sessions and the five delivered revocation notices point to retransmission and reliable closure handling as the next requirements. The contribution is a formally constrained session-control design, with wireless execution demonstrated and with the privacy, AI, and communication claims bounded explicitly.

References

• 1

  AfzalI.ul AminN.AhmadZ.AlgarniA. (2025). A latency-aware and fault-tolerant framework for resource scheduling and data management in fog-enabled smart city transportation systems. Comput. Mater. and Continua82, 1377–1399. 10.32604/cmc.2024.057755

  • CrossRef
  • Google Scholar
  • View reference in article

• 2

  Al MamunA.HasibA.MussaA. S. M.HossenR.RahmanA. (2024). IoT-enabled smart car parking system through integrated sensors and Mobile applications. arXiv. 10.48550/arXiv.2412.10774

  • CrossRef
  • Google Scholar
  • View reference in article

• 3

  Ala’anzyM. A.AbilakimA.ZhanuzakR.LiL. (2025). Real time smart parking system based on IoT and fog computing evaluated through a practical case study. Sci. Rep.15, 33483. 10.1038/s41598-025-15507-6

  • Pubmed Abstract
  • CrossRef
  • Google Scholar
  • View reference in article

• 4

  Ben JaballahW.ContiM.LalC. (2019). A survey on software-defined VANETs: benefits, challenges, and future directions. arXiv. 10.48550/arXiv.1904.04577

  • CrossRef
  • Google Scholar
  • View reference in article

• 5

  DurairajA.BaskaranS.BaskaranA.JanakiramanR.BalachandranP. K.GundlaR.et al (2025). Efficiency of a smart parking system in privacy-preserving using multi transaction mode consortium blockchain. Sci. Rep.15, 42462. 10.1038/s41598-025-26482-3

  • Pubmed Abstract
  • CrossRef
  • Google Scholar
  • View reference in article

• 6

  DzurendaP.JacquesF.KnockaertM.LaurentM.MalinaL.MatuleviciusR.et al (2022). Privacy-preserving solution for vehicle parking services complying with EU legislation. PeerJ Comput. Sci.8, e1165. 10.7717/peerj-cs.1165

  • Pubmed Abstract
  • CrossRef
  • Google Scholar
  • View reference in article

• 7

  ElfakiA. O.MessoudiW.BushnagA.AbuzneidS.AlhmiedatT. (2023). A smart real-time parking control and monitoring system. Sensors23, 9741. 10.3390/s23249741

  • Pubmed Abstract
  • CrossRef
  • Google Scholar
  • View reference in article

• 8

  GrobelnaI.GajewskiK.KaratkevichA. (2025). A systematic review on the applications of UPPAAL. Sensors25, 3484. 10.3390/s25113484

  • Pubmed Abstract
  • CrossRef
  • Google Scholar
  • View reference in article

• 9

  KhanS.ZhangJ.Kumar SootharK.JiangW.NawazS.AurangzebK. (2026). FedVR360: Federated Learning Enabled privacy-preservation for VR 360° Video Streaming in Vehicular Edge Computing. Journal of King Saud University Computer and Information Sciences. 10.1007/s44443-026-00815-2

  • CrossRef
  • Google Scholar
  • View reference in article

• 10

  KrakallahM. W.Nait-BahloulS. (2025). Hybrid access control model for IoT environments: formalization and verification using timed automata. SN Comput. Sci.6, 214. 10.1007/s42979-025-03674-2

  • CrossRef
  • Google Scholar
  • View reference in article

• 11

  LinS.-C.ChenK.-C.KarimoddiniA. (2021). SD-VEC: software-defined vehicular edge computing with ultra-low latency. arXiv. 10.48550/arXiv.2103.14225

  • CrossRef
  • Google Scholar
  • View reference in article

• 12

  MeesadP.ThumthongW. (2025). Advanced deep learning techniques for automated license plate recognition. Sci. Rep.15, 24967. 10.1038/s41598-025-24967-9

  • Pubmed Abstract
  • CrossRef
  • Google Scholar
  • View reference in article

• 13

  PradhanG.PrustyM. R.NegiV. S.ChinaraS. (2025). Advanced IoT-integrated parking systems with automated license plate recognition and payment management. Sci. Rep.15, 2388. 10.1038/s41598-025-86441-w

  • Pubmed Abstract
  • CrossRef
  • Google Scholar
  • View reference in article

• 14

  QianY.MaD.WangB.PanJ.WangJ.ChenJ.et al (2019). Spot evasion attacks: adversarial examples for license plate recognition systems with convolutional neural networks. arXiv. 10.48550/arXiv.1911.00927

  • CrossRef
  • Google Scholar
  • View reference in article

• 15

  SatyaB.ManonggaD.AminuddinA. (2025). Optimized YOLOv8 for automatic license plate recognition on resource-constrained devices. Eng. Technol. and Appl. Sci. Res.15, 21976–21981. 10.48084/etasr.9983

  • CrossRef
  • Google Scholar
  • View reference in article

• 16

  ShahzadA.GherbiA.ZhangK. (2022). Enabling fog-blockchain computing for autonomous-vehicle-parking system: a solution to reinforce IoT-cloud platform for future smart parking. Sensors22, 4849. 10.3390/s22134849

  • Pubmed Abstract
  • CrossRef
  • Google Scholar
  • View reference in article

• 17

  SinghP.PariharS. (2024). Smart parking systems: a review of technologies and benefits. Int. J. Commun. Netw. Inf. Secur.16. 10.17762/ijcnis.v16i3.8120

  • CrossRef
  • Google Scholar
  • View reference in article

• 18

  SommerC.GermanR.DresslerF. (2011). Bidirectionally coupled network and road traffic simulation for improved IVC analysis. IEEE Trans. Mob. Comput.10, 3–15. 10.1109/TMC.2010.133

  • CrossRef
  • Google Scholar
  • View reference in article

• 19

  ZhangC.JiM.WuQ.FanP.FanQ. (2025). Optimizing system latency for blockchain-encrypted edge computing in Internet of vehicles. Comput. Mater. and Continua83, 3519–3536. 10.32604/cmc.2025.061292

  • CrossRef
  • Google Scholar
  • View reference in article