My research focuses on a critical challenge in the intelligent transportation ecosystem: suggesting appropriate charging stations or fueling locations for hybrid electric vehicles while preserving user privacy. As a low-carbon and energy-efficient mode of transport, the hybrid electric vehicle combines the advantages of conventional internal combustion engines with electric drive technology. This architecture relieves the pressure on charging infrastructure, especially when dedicated charging stations are overloaded. However, a hybrid electric vehicle still requires occasional access to charging points and gasoline refueling stations. The problem is not simply to find any station, but to recommend a station that minimizes the user’s cost, reduces waiting time, and optimally utilizes idle infrastructure. In my work, I design and evaluate a vertical federated learning framework that enables station recommendation across multiple data owners without sharing raw sensitive data. The emphasis is on protecting user information, vehicle geographical location, and behavioral habits. My algorithm treats the hybrid electric vehicle, the charging station, and the gasoline station as distinct participants in a collaborative learning process. In this first-person narrative, I explain the architecture, the mathematical underpinnings, and the experimental results that demonstrate the efficiency of my approach.
Before diving into the details, I must stress the importance of privacy-aware recommendation. In the era of big data and ubiquitous connectivity, the user’s daily trajectory and energy consumption patterns reveal a great deal about their lifestyle. If a central server collects all vehicle and station data, risk of leakage increases. Government regulations such as the General Data Protection Regulation push system architects to design solutions that keep data on local devices. My framework follows this principle. Instead of transmitting raw records from cars and stations, only encrypted intermediate gradients are exchanged. This is achieved through a decentralized aggregation network built on blockchain technology. Moreover, the proposed method is tailored to recommendation in a dynamic environment where the number of vehicles and stations changes constantly. My design therefore emphasizes flexible scalability and resilience against a single point of failure. The distributed cloud nodes, which I call CloudletChain, store model parameters and coordinate federated training in a tamper-resistant manner. Each node must be authorized and recorded in a public ledger before entering the network. This prevents malicious participants from impersonating legitimate aggregators and stealing model information.
Let us examine a typical application scenario. A hybrid electric vehicle is driving in a city where there are several charging stations and gasoline stations. Some stations are idle, some are crowded, and each has a different price structure. For instance, the nearest charging station may have a long queue, while a farther gasoline station can refuel almost instantly. If the driver prioritizes time, the recommendation should suggest the gasoline station. If the driver cares about cost and has sufficient battery capacity, a cheap but slightly farther charging station could be better. My algorithm learns these preferences from historical service records. The data used for training includes charging transactions, gasoline refueling transactions, vehicle characteristics, and traffic context. The learning objective is to infer a function that maps the feature vector of a vehicle-station pair to an expected utility score. In this way, the recommendation service becomes personalized.
In my framework, I denote the set of participants by \( k \in \{1,2,\ldots,K\} \), where \( K=3 \) represents the three distinct entities: hybrid electric vehicles (HEVs), charging stations (CSs), and gas stations (GSs). I define the local dataset of participant \( k \) as \( D_k \), containing input-output pairs \( \{x_i, y_i\}_{i=1}^{D_k} \). The total amount of data is \( D = \sum_{k=1}^{K} D_k \). The objective is to learn a gradient parameter vector \( \Theta \in \mathbb{R}^d \) where \( d \) is the dimension of aggregated feature vectors across parties. In vertical federated learning, the feature spaces of participants are different but the sample IDs overlap. This is in contrast to horizontal federated learning where data partitions have different samples but same features. My setting fits the problem naturally: the same user (vehicle) appears in the records of the charging station and the gasoline station, but each party has different attributes. Each charging station stores the charger ID, energy consumption, start/end times, and associated price. The gasoline station stores the fuel pump ID, amount, price, and duration. The vehicle stores its location, speed, battery state, and fuel state. None of these parties can independently compute a reliable recommendation because each needs information from the other parties. Vertical federated learning allows all parties to cooperatively train a model without exposing their private attributes.
In the following I present several tables and formulas that summarize the feature representation and the mathematical formulation. The selected features are shown in Table 1. These features were chosen based on their direct influence on the user’s experience and the station utilization efficiency.
| Participant | Feature description |
|---|---|
| HEV \( d_{\text{hev}} \) | vehicle position, average speed, current weather conditions, surrounding infrastructure, traffic congestion level, battery capacity, charging station start/stop time, vehicle state (charging/refueling/driving) |
| CS \( d_{\text{cs}} \) | latitude and longitude of the charging pile, number of chargers, average charging capacity, average charging cost, additional parking fee, queuing time, charging start time, charging duration and end time |
| GS \( d_{\text{gs}} \) | latitude and longitude of the gas station, number of pumps, average fuel cost, average fuel volume, queuing time for refueling and refueling duration |
Table 1 illustrates that the vehicle, charging station, and gas station have overlapping but not identical feature sets. This is the fundamental motivation for using vertical federated learning. I use \( D_{\text{hev}} \), \( D_{\text{cs}} \), and \( D_{\text{gs}} \) to denote the local datasets for the three participants. I further denote the true labels associated with charging stations as \( y_i \) and with gasoline stations as \( z_i \). These labels are constructed from historical orders. When a request is sent to a station, the system checks the current availability and assigns a label equal to 0 (idle), 1 (charging), or 2 (refueling). Consequently, the output space is multi-class but ordinal in nature. My model predicts a utility score for each candidate and then recommends the top \( N \) station alternatives. The recommendation list is denoted by \( L_f \).
Let me formally define the model training objective. I use a linear model combined with a regularization term. More precisely, features are represented by vectors \( x_i^{\text{hev}} \), \( x_i^{\text{cs}} \), and \( x_i^{\text{gs}} \). Correspondingly, the parameter vectors \( \Theta_{\text{hev}} \), \( \Theta_{\text{cs}} \), and \( \Theta_{\text{gs}} \) are learned. The prediction for a sample \( i \) is given by the sum of the three local linear contributions:
\[
\hat{y}_i = \Theta_{\text{hev}}^T x_i^{\text{hev}} + \Theta_{\text{cs}}^T x_i^{\text{cs}} + \Theta_{\text{gs}}^T x_i^{\text{gs}} .
\]
For the station recommendation output, I also define a second objective involving \( z_i \), the gasoline station label. The total loss combines regression errors for both the charging station and the gasoline station. Let \( g(\Theta) = \frac{1}{2} \|\Theta\|^2 \) denote the squared \( L_2 \) norm used in the regularizer. I set the loss function as:
\[
\min_{\Theta_{\text{hev}}, \Theta_{\text{cs}}, \Theta_{\text{gs}}}
\sum_{i}
\left\| \Theta_{\text{hev}}^T x_i^{\text{hev}} + \Theta_{\text{cs}}^T x_i^{\text{cs}} – y_i \right\|^2
+
\left\| \Theta_{\text{hev}}^T x_i^{\text{hev}} + \Theta_{\text{gs}}^T x_i^{\text{gs}} – z_i \right\|^2
+
\lambda \left[ g(\Theta_{\text{hev}}) + g(\Theta_{\text{cs}}) + g(\Theta_{\text{gs}}) \right],
\]
where \( \lambda \in [0,1] \) controls the penalty strength. This is a simplified representation of the actual multi-output ridge regression used in my implementation. In order to maintain clarity, I use the following compact notation:
\[
u_i^{\text{hev}} = \Theta_{\text{hev}}^T x_i^{\text{hev}},\quad
u_i^{\text{cs}} = \Theta_{\text{cs}}^T x_i^{\text{cs}},\quad
u_i^{\text{gs}} = \Theta_{\text{gs}}^T x_i^{\text{gs}}.
\]
Then the encrypted loss can be written as:
\[
\mathcal{L} =
\sum_i \left\| u_i^{\text{hev}} + u_i^{\text{cs}} – y_i \right\|^2
+
\sum_i \left\| u_i^{\text{hev}} + u_i^{\text{gs}} – z_i \right\|^2
+
\lambda \left( g(\Theta_{\text{hev}}) + g(\Theta_{\text{cs}}) + g(\Theta_{\text{gs}}) \right).
\]
To ensure privacy, I use an additive homomorphic encryption scheme, denoted by the bracket operator \( [ \cdot ] \). The encrypted local components are computed separately. For example, when computing the loss associated with the charging station branch, I need to obtain values such as \( [ u_i^{\text{hev}} ] \), \( [ u_i^{\text{cs}} ] \), and \( [ y_i ] \) without revealing them in plaintext. Because homomorphic encryption supports addition and scalar multiplication, the aggregator can compute encrypted global loss values and encrypted gradients without inspecting any raw data.
The split of the loss function into local terms and pairwise interaction terms is essential for vertical federated learning. I decompose the loss as:
\[
\mathcal{L} = \mathcal{L}_{\text{hev}} + \mathcal{L}_{\text{cs}} + \mathcal{L}_{\text{gs}} + \mathcal{L}_{\text{hev-cs}} + \mathcal{L}_{\text{hev-gs}} + \mathcal{L}_{\text{cs-gs}}.
\]
Here, the individual components are:
\[
\mathcal{L}_{\text{hev}} = \sum_i (u_i^{\text{hev}})^2 + \lambda g(\Theta_{\text{hev}}),
\]
\[
\mathcal{L}_{\text{cs}} = \sum_i (u_i^{\text{cs}} – y_i)^2 + \lambda g(\Theta_{\text{cs}}),
\]
\[
\mathcal{L}_{\text{gs}} = \sum_i (u_i^{\text{gs}} – z_i)^2 + \lambda g(\Theta_{\text{gs}}),
\]
\[
\mathcal{L}_{\text{hev-cs}} = 2 \sum_i u_i^{\text{hev}} (u_i^{\text{cs}} – y_i),
\]
\[
\mathcal{L}_{\text{hev-gs}} = 2 \sum_i u_i^{\text{hev}} (u_i^{\text{gs}} – z_i),
\]
\[
\mathcal{L}_{\text{cs-gs}} = 2 \sum_i (u_i^{\text{cs}} – y_i)(u_i^{\text{gs}} – z_i).
\]
These terms correspond to the partial contributions that must be computed collaboratively. For instance, \( \mathcal{L}_{\text{hev-cs}} \) requires multiplication of a value held by the vehicle and a value held by the charging station. Direct multiplication of two encrypted values is not possible under additive homomorphic encryption. Therefore I use a secure multiparty computation protocol: the vehicle computes a masked encrypted value, the charging station decrypts only after the vehicle adds random noise, and the final result is re-encrypted and shared. This process preserves the confidentiality of both parties.
At this point I explain the proposed algorithm, named the Vertical Federated Station Recommendation (VFSR) algorithm. The execution is divided into two main phases: encrypted entity alignment and local model training. In the first phase, each participant computes a hash of its sample identifiers. The identifiers can be, for example, the transaction order ID from the user’s charger usage. Through a private set intersection protocol, the participants obtain an intersection \( I \) of common IDs without revealing non-overlapping IDs. This overlapping set defines the training samples that can be used jointly. In the second phase, the actual training begins. My implementation follows the following steps:
- Step 1: The cloud aggregator \( c_p \in C \) sends initialized parameter vectors \( \Theta_{\text{hev}} \), \( \Theta_{\text{cs}} \), and \( \Theta_{\text{gs}} \) to the three parties.
- Step 2: Each party computes intermediate local results, including temporary gradients and local loss components. These are encrypted and exchanged where necessary, so that all parties can contribute to the total gradient computation.
- Step 3: The three parties compute encrypted gradients and add additional masks. The charging station and gasoline station also compute encrypted losses and send the encrypted values to the aggregator \( c_p \).
- Step 4: The aggregator \( c_p \) aggregates the gradients, updates the global parameters, and returns the encrypted updated values to the participants. Each participant removes its own mask and updates its local model parameters.
- Step 5: After convergence, the model is used to generate the recommendation list. Each candidate station is scored based on state indicators. The list \( L_f \) is sorted in descending order and the top \( N \) suggestions are forwarded to the hybrid electric vehicle.
This iterative process continues until the training objective converges. The choice of the loss function does not have to be limited to ridge regression. I can extend the same framework to logistic regression, neural networks, or tree-based models as long as the forward and backward propagation can be decomposed among the feature partitions. But for the sake of demonstration, my experiments adopt a ridge-regression-like predictor with homomorphic encryption.
The communication between the participants and the aggregator is a critical bottleneck. In a traditional centralized architecture, a single cloud server receives all encrypted gradients and updates the model. This creates a single point of failure and may also cause high latency if the server is remote. My design instead uses a network of Cloudlet nodes, deployed in close geographic proximity to the vehicles. The cloudlets are connected by a blockchain. Each cloudlet maintains a copy of the global parameter vector and could act as an aggregator for a subset of users. One distinguishing feature of my design is a de-centralized aggregation mechanism: instead of relying on a single aggregator, the VFSR algorithm randomly elects a miner node among cloudlets to generate a block that records the detailed interactions. This method prevents malicious cloudlet replacement and increases robustness.
In Table 2, I present a summary of the simulation parameters and the default settings used in my experimental evaluation.
| Parameter | Value / description |
|---|---|
| Charging stations | 20 |
| Gas stations | 20 |
| Hybrid electric vehicles | 50 |
| Cloud nodes | 10 (tested 1-10) |
| Features per station | 10 to 12 categorical/continuous |
| Training iterations | 200 epochs with early stopping |
| Learning rate \( \eta \) | 0.01 |
| Regularization \( \lambda \) | 0.001 |
| Homomorphic encryption | Paillier 1024-bit key |
| Block generation interval | variable; depends on transaction pool |
The data set covers September through December 2023 for one city in China. I collected charging station information including station ID, historical vehicle visits, prices, and latitude/longitude. I also collected gas station information, including the number of pumps, average fuel cost, and location. For the hybrid electric vehicles, I generated 50 records based on real-world driving patterns, including battery capacity, remaining battery state of charge, charging duration, and arrival time. These records were fed into the model to train the recommendation algorithm.
Let me discuss the performance evaluation in detail. I compared my algorithm with two baseline recommendation methods: the real-time recommendation method and a charge scheduling heuristic. The baseline choices reflect state-of-the-art approaches used in previous research. I measured four primary metrics: the queuing probability, the total monetary cost for the user, the parking cost, the time utilization rate, and the hourly profit achieved by the station. The numerical results are summarized in Table 3.
| Algorithm | Queuing probability | Total cost (yuan) | Parking cost (yuan) | Time utilization rate | Hourly profit (yuan) |
|---|---|---|---|---|---|
| RT baseline | 0.122 | 25.231 | 3.579 | 0.148 | 7916 |
| EFT heuristic | 0 | 20.948 | 1.754 | 0.193 | 9021 |
| My VFSR algorithm | 0 | 19.426 | 0.126 | 0.202 | 9062 |
Table 3 reveals that my algorithm achieves zero queuing probability, identical to the EFT heuristic, while producing a slightly lower total cost and much lower parking cost. The time utilization rate rises to 0.202, which is higher than both of the baselines. The hourly revenue is also higher. The reason lies in the ability of my algorithm to proactively direct vehicles to stations that remain available for the predicted arrival time. The time difference between request submission and vehicle arrival is carefully modeled. If the system simply retrieves current station occupancy, a station might appear available at the moment of request but might become occupied a few minutes later. My model learns the historical occupation pattern and predicts the future availability at the estimated arrival time. This reduces congestion and avoids unnecessary waiting.
In terms of execution time, I investigated how the number of participants influences total runtime. Starting from 2 charging stations, 2 gas stations and 5 hybrid electric vehicles, I gradually increased the system size to 20 stations and 50 vehicles. The trend is presented in Table 4. The unit of measurement is seconds. This table reflects the fact that more participants generate more training samples and also more encrypted interactions. The system execution time grows almost linearly with the number of participants, which is favorable for scalability.
| Charging stations / Gas stations / Vehicles | Execution time (s) |
|---|---|
| 2 / 2 / 5 | 2.3 |
| 4 / 4 / 10 | 4.1 |
| 6 / 6 / 15 | 5.8 |
| 8 / 8 / 20 | 7.5 |
| 10 / 10 / 25 | 9.2 |
| 12 / 12 / 30 | 11.0 |
| 14 / 14 / 35 | 12.7 |
| 16 / 16 / 40 | 14.3 |
| 18 / 18 / 45 | 15.9 |
| 20 / 20 / 50 | 17.6 |
The table above demonstrates that although the computational cost rises monotonically with the number of electric vehicle stations, the growth rate remains moderate. The overhead of homomorphic encryption and secure communication is not negligible, but the linear scaling behavior means that adding more stations does not create an exponential explosion. For more realistic urban deployments with hundreds of stations, a hierarchical aggregation architecture may be necessary. My Cloudlet-based design inherently supports such hierarchy because each cloudlet can aggregate local data within a geographic zone, and only zonal intermediate parameters are exchanged globally.
I now turn to the waiting time analysis. For each vehicle \( j \), I measure the difference \( \rho_j = T_{\text{start},j} – T_{\text{arrival},j} \), where \( T_{\text{arrival},j} \) is the time when vehicle \( j \) arrives at the station and \( T_{\text{start},j} \) is the actual time when charging or refueling starts. The smaller \( \rho_j \), the more accurate the recommendation. For charging stations, the waiting time includes the period from arrival to plug-in plus any adjustment due to the recommended scheduling. Let me denote the historical average waiting time at a specific station as \( \tau_{\text{avg}} \). The estimated total charging waiting time is:
\[
T_1 = t_{\text{charging+waiting}} + t_{\text{arrival}}.
\]
For gas stations, refueling time is very short and can be ignored in many cases, but during peak hours there may still be a queue. Therefore I model the gas station waiting time as:
\[
T_2 = t_{\text{waiting}} + t_{\text{arrival}}.
\]
In a test set of 20 hybrid electric vehicles, I compared the waiting time suggested by the model versus the actual waiting time in a real environment without a recommendation. Table 5 summarizes the results for a subset of vehicles. The column \( \rho_{\text{recommended}} \) is the waiting time experienced by the driver who followed my recommendation, while \( \rho_{\text{naive}} \) is the average waiting time of all vehicles that chose arbitrarily based on proximity only.
| Vehicle ID | Recommended station type | \( \rho_{\text{recommended}} \) (min) | \( \rho_{\text{naive}} \) (min) |
|---|---|---|---|
| HEV1 | Charging station | 0.5 | 7.2 |
| HEV2 | Gas station | 0.0 | 3.4 |
| HEV3 | Charging station | 1.1 | 12.1 |
| HEV4 | Charging station | 0.3 | 5.8 |
| HEV5 | Gas station | 0.0 | 1.2 |
| HEV6 | Charging station | 2.0 | 9.6 |
| HEV7 | Gas station | 0.2 | 4.3 |
| HEV8 | Charging station | 0.8 | 6.7 |
The table shows that the recommended waiting time is consistently much lower than the naive choice. In particular, for vehicles that are recommended to a gas station, the waiting time is nearly zero, because the model selects periods when the gas station queue is minimal. For charging stations, the model tries to find a charger that will become available shortly after arrival. This is why HEV1 and HEV6 experience only a few minutes of wait. Such performance reduces the driver’s anxiety and contributes to broader adoption of electric mobility.
Communication delay is another important metric. In my measurement setup, communication delay refers to the time interval between the moment a hybrid electric vehicle submits a recommendation request and the moment it receives the final recommendation list \( L_f \). I tested several configurations of the Cloudlet network. The first configuration is the centralized architecture with no cloud nodes, where all parameters travel to a single remote server. The other configurations have 3, 5, 8, or 10 decentralized cloud nodes distributed over a city area. Table 6 reports the average communication delay over 20 vehicle requests for each configuration.
| Number of cloud nodes | Average delay (s) |
|---|---|
| Centralized (0) | 8.9 |
| 3 | 6.2 |
| 5 | 4.8 |
| 8 | 3.7 |
| 10 | 3.0 |
The results show that adding cloud nodes reduces communication delay by roughly 5.9 seconds from the centralized baseline to the 10-node network. There are several reasons for this improvement. First, a cloudlet is geographically closer to the driver, so the propagation time is shorter. Second, load is balanced across cloudlets; no single server has to serve all vehicles at once. Third, local aggregation can be performed inside the cloudlet without forwarding all individual gradients to a global server. The residual delay that cannot be reduced is caused by the homomorphic encryption operations and the secure aggregation steps. The latency values still fluctuate by roughly one second due to network congestion and block validation overhead, but for real-time recommendation purposes this is a promising result.
I also investigated the block mining time in the CloudletChain architecture. Because every newly added cloud node needs to be authorized via a transaction, a miner node has to validate the transaction and append a new block to the public ledger. The total time for this process grows with the number of blocks already in the chain. To capture the variability, I performed five independent mining iterations for each network size. Table 7 contains the minimum and maximum execution times observed when the number of cloud nodes varies from 3 to 10.
| Number of cloud nodes | Minimum block time (s) | Maximum block time (s) |
|---|---|---|
| 3 | 0.6 | 1.1 |
| 4 | 0.8 | 1.5 |
| 5 | 0.9 | 1.9 |
| 6 | 1.2 | 2.4 |
| 7 | 1.4 | 2.9 |
| 8 | 1.7 | 3.3 |
| 9 | 2.0 | 4.1 |
| 10 | 2.3 | 5.0 |
The table shows that the block time nearly doubles between the 3-node and 10-node networks. This is expected because the transaction pool becomes larger and the proof-of-work difficulty must be adjusted to reflect the increased network size. Yet even with 10 cloud nodes, the maximum authentication delay is about 5 seconds. Since new cloud nodes do not join very frequently, this delay does not directly affect the responsiveness of the recommendation. The blockchain layer is thus a practical security mechanism. It ensures that the aggregator nodes are trusted, and that no unauthorized cloudlet can impersonate a legitimate one and gain access to the encrypted model gradients.
In addition to the metrics already discussed, my proposed algorithm addresses the problem of imbalanced utilization among stations. Without recommendation, a newly opened charging station may remain idle for a long time, while a popular station near the city center is continuously crowded. In my experiments, I observed that the time utilization rate improves by about 36 percent compared to the baseline. This improvement is beneficial not only for the vehicle owner but also for the station operator. Higher utilization directly leads to more revenue per hour. At the same time, idle stations are brought into the recommendation list because they offer lower waiting times and sometimes lower prices. This matching is realized by feeding the station current load into the feature vector. The model learns to trade off distance, price, and waiting time according to the user’s preference discovered from past choices.
Let me now describe the security and privacy preservation mechanism in more depth. The concern in a federated learning system is that intermediate gradients might leak information about local data. For example, if a charging station sends its gradient vector without any protection, an attacker could reconstruct the average price of station transactions. To prevent this, I use homomorphic encryption in combination with gradient masking. Each participant adds a random mask \( m_k \) to its encrypted gradient. The masks are generated such that they cancel out when the aggregator sums all gradients. That is:
\[
\sum_{k=1}^{K} \tilde{g}_k = \sum_{k=1}^{K} (g_k + m_k) = \sum_{k=1}^{K} g_k,
\]
provided that \( \sum_{k} m_k = 0 \). The masks are generated through a secure random seed exchange. Thus, the aggregator receives only the sum, while individual gradients are never exposed in plaintext. The blockchain keeps an immutable record of every aggregation event, so that if a malicious participant tries to submit an inconsistent mask, the protocol can be audited after the training round.
The vertical federated learning model offers a significant advantage: the real labels \( y_i \) and \( z_i \) remain with the charging station and gas station respectively. The hybrid electric vehicle never receives raw labels of other stations. Instead, it obtains the encrypted residual values and removes its own mask iteratively. This means that even a compromised vehicle cannot infer the operational characteristics of the charging stations. The only information it sees is the final recommendation score, which is intended for the user.
My experimental environment was developed to closely match realistic conditions. I built a Python-based simulator which includes a network layer for Cloudlet communication and a simplified blockchain module. The simulator is not a full Ethereum implementation; rather, it captures the essential block management logic. The proof-of-work difficulty was set to a low level to allow fast experiments. The homomorphic encryption operations were performed using a standard Paillier library with a 1024-bit key. The training process ran for up to 200 epochs with a batch size of 16. The measured execution time includes the communication overhead but excludes the blockchain mining time except where explicitly specified. By separating the metrics, I could analyze each component in isolation.
One finding from the execution time analysis is that the computational overhead is dominated by the Paillier encryption and decryption operations. This is especially true when the number of features is large. To make the system more efficient, I adopted a technique called batch encryption: multiple feature values are packed into a single ciphertext using a vector encoding method. The Paillier plaintext space is large enough to accommodate multiple integers in one encryption if the bit lengths are chosen carefully. Table 8 presents the execution time per training epoch with and without using batch encryption. The values are reported for the full network of 20 charging stations, 20 gas stations and 50 vehicles.
| Scenario | Time per epoch (s) | Total for 200 epochs (min) |
|---|---|---|
| No batch encryption | 0.85 | 2.83 |
| With batch encryption | 0.52 | 1.73 |
The table shows that batch encryption reduces the training time by about 39 percent. This is a substantial improvement in the context of real-time recommendation, where the model may need to be re-trained periodically as new transaction data arrive. The convergence speed of the model also depends on the local learning rate. I set the learning rate \( \eta=0.01 \). In my experiments, the loss curve converged smoothly without oscillations after about 40 epoch, and the final loss value remained stable. The selected learning rate works well with the regularization parameter \( \lambda=0.001 \). If the data distribution shifts, e.g., when a new station is opened, the model requires a few additional epochs of fine-tuning. Because of the decentralized architecture, the new station can join the federated network by sending its gradient updates without sharing raw data. This makes the system extensible.
The scalability of my approach is further enhanced by using asynchronous updates. In a synchronous protocol, all participants must complete their local backpropagation before the aggregation round starts. This may lead to a bottleneck if one vehicle has a poor network connection. My design allows the cloudlet to perform partial aggregation as soon as most of the participants have responded. Let us denote the number of participants that replied on time by \( K_{\text{ready}} \). The aggregation rule becomes:
\[
\Theta^{(t+1)} = \Theta^{(t)} – \eta \cdot \frac{1}{K_{\text{ready}}} \sum_{k=1}^{K_{\text{ready}}} \tilde{g}_k^{(t)}.
\]
The participants that missed the deadline are allowed to upload their gradients in the next round. This asynchronous mechanism significantly improves the training throughput in real-world deployments. It also prevents a single slow or disconnected vehicle from halting the entire recommendation system.
In my opinion, the most important contribution of this paper is not merely the algorithm itself, but the combination of vertical federated learning and blockchain-based cloudlet coordination to solve a practical transportation recommendation problem. The electric vehicle ecosystem consists of many stakeholders: drivers, charging station owners, gas station owners, fleet managers, and electricity grid operators. Each of them has a strong incentive to protect its data. The government’s privacy laws make it impossible for a central platform to aggregate users’ locations and transactions without consent. Therefore, any future recommendation system for electric vehicles should be privacy-preserving by design. My work provides such a design and provides empirical evidence that it can achieve satisfactory performance in terms of recommendation accuracy, latency, and resource utilization.
I should also mention the limitations of the current work. First, the experiments rely on synthetic or semi-synthetic data because real-world access to the transaction logs of multiple station operators is difficult to obtain under privacy restrictions. I generated 50 vehicle records based on survey statistics, which is a small number compared to the scale of a true smart city. Second, I only considered a linear model. A more expressive deep neural network might improve the recommendation quality but would require more sophisticated secure computation. Third, the blockchain proof-of-work consumes additional time and energy. I have not evaluated the energy consumption. Some alternative consensus mechanisms, such as proof-of-stake, may be more suitable for time-sensitive applications. Still, my goal is to construct a benchmark architecture that can be improved incrementally.
In future work, I plan to extend this framework to public transportation systems, such as electric buses. For buses, the charging schedule is more predictable because the route is fixed and the dwell time at each stop is known. I can use my federated recommendation algorithm to allocate buses to charging stations during off-peak hours, minimizing passenger waiting time and maximizing operational profit. I also plan to investigate the interplay between privacy protection and recommendation quality. When more noise is added to the gradients to satisfy differential privacy, the model accuracy decreases. I need to find the optimal trade-off curve and incorporate fairness notions into the recommendation objective.
To summarize, this paper describes a station recommendation algorithm for hybrid electric vehicles based on vertical federated learning. The use of additive homomorphic encryption and the CloudletChain blockchain ensures that raw data never leaves the local participants. My experiments demonstrate that the algorithm is accurate, efficient, and robust. The system avoids single point failure, decreases communication latency, minimizes waiting time, and increases the utilization of both charging stations and gas stations. My approach is a step forward in the field of privacy-preserving electric vehicle navigation. I hope the insights gained from the model can be applied to a wider range of smart mobility services, including dynamic ride-sharing and eco-routing.
At last, let me put the results into perspective by relating to the original motivation. The transition to sustainable transportation depends on user acceptance. If drivers of electric and hybrid electric vehicles fear that their location and behavioral data are being tracked, they may avoid using intelligent recommendation services. My design eliminates this fear because all private data remains in the local client. The vehicle only receives the final station list. The experiments in this paper show that even with these strict privacy requirements, we can achieve good outcomes. I truly believe that the integration of federated learning, cloud-edge collaboration, and blockchain will pave the way for more secure and user-friendly electric mobility ecosystems. The algorithm I have developed can be directly implemented in a vehicular cloud, in an electric vehicle supply equipment management platform, or in a smartphone-based mobility app. Future research will continue to refine the encryption overhead and to evaluate the approach on larger real-world datasets with more diverse vehicle types and user preferences. The ultimate goal is a scalable, privacy-preserving, and economically viable solution for all kinds of electric vehicles.