Ahmed Sherif1, Muhammad Ismail2, Marbin Pazos-Revilla1, Mohamed Mahmoud1, Kemal Akkaya3, Erchin Serpedin4, and Khalid Qaraqe2
1 Tennessee Technological University, Cookeville, TN, USA
2 Texas A&M University at Qatar, Doha, Qatar
3 Florida International University, Miami, FL, USA
4 Texas A&M University, College Station, USA
Smart grid is a progressive upgrade to the existing power grid. It consists of sophisticated systems of smart electronic devices, dispersed generators, and loads (Brusco et al., 2014) and can give two‐way power exchange among various components. Several functionalities of the smart grid require major dependence on an intelligent communication infrastructure. However, such a dependence makes the smart grid vulnerable to tremendous risks as well as hard challenges in protecting the smart grid from cyber‐security threats (Khurana et al., 2010). Compared with the existing communication networks such as the Internet, the smart grid communication systems have different objectives, architecture, and concerns about what need to be protected (Yan et al., 2012). For example, in the smart grid, we need to guarantee the real‐time performance and the features of the continuous operations. The smart grid is more concerned with the message delay than the data throughput due to the timing constraint of messages transmitted over the power networks. As a result, the existing security solutions for different communication networks cannot fit directly to the smart grid communication networks without filling the gaps where traditional communication network solutions do not work or apply. In the following, general security requirements for the smart grid are discussed. Then, we focus our attention on a specific functionality of the smart grid, discussing its security requirements, and presenting potential cyber‐security solutions.
The smart grid should meet rigorous security requirements such as availability, integrity, authentication, authorization, and non‐repudiability. Such requirements can be briefly summarized as follows:
Overall, specific smart grid functionalities require custom‐made cyber‐security mechanisms depending on the communication requirement of such a functionality. In what follows, we focus our attention on one functionality of the smart grid, namely charging coordination, and discuss one of its cyber‐security requirements.
As per NIST (National Institute of Standards and Technology, 2010), one of the principal goals of the smart grid is the diminishment of greenhouse gas emissions by integrating more renewable energy resources (Lukic et al., 2008) and electric vehicles (EVs). Recently energy storage units (ESUs) including home batteries and EVs have received broad consideration. TESLA company recently produced a home battery product (M57) that can charge when the electricity is cheap and power the home when electricity is expensive. Numerous automotive companies have already started producing EVs from their production lines (Nissan LEAF Electric Car).
These developments imply that the smart grid will have a large number of ESUs. However, the large‐scale, simultaneous charging of energy storage units (ESUs), including home batteries and EVs, will have a significant impact on the power grid, especially when the charging loads are not coordinated. This can raise technical issues including imbalance of charging demands and energy supply, more power losses, and larger voltage deviation (Sortomme et al., 2011; Hadley and Tsvetkova, 2009). These issues cannot be avoided by charging at off‐peak periods, e.g., late night, since this can make another peak that cannot be handled by the power distribution network. The most ideal approach to avoid this issue and fully utilize the accessible power is via charging coordination (Deilami et al., 2011; Clement et al., 2009). However, this needs reporting a few data, for example, whether an ESU needs to charge or not, time to complete charging (TCC), the battery state of charge (SoC), and so on. Unfortunately, this data can reveal private information about the owners of ESUs, such as the location of an EV and the activities of a house's residents (P. Akula, M. Mahmoud, K. Akkaya, and M. Song, 2015; NIST, 2010). For example, the charging demands sent from an EV can reveal whether the EV's owner is at home, to what extent he/she will stay, and to what extent he/she drives. Also, if a home battery is not charging for an extended period, this can reveal that the residents do not spend time in home because they are traveling, and charging more than the normal amount can reveal that residents host guests. While one can plan solutions for particularly securing the information exchange and concealing data from the included parties, this may unfavorably influence the performance of charging coordination plans. This is on the grounds that privacy preservation often targets to hide information; however, charging coordination needs sufficient information.
Due to technical limitations, not all ESUs can charge at the same time, so each ESU ought to send a charging request to an aggregator. The aggregator should not know whether an ESU needs to charge or not, its battery state of charge, and the needed time to finish charging to preserve privacy. The aggregator forwards the requests to a charging controller (CC) that needs sufficient data to run a charging coordination scheme without linking the requests to specific ESUs to preserve privacy. In this chapter, we present a privacy‐preserving power‐charging coordination scheme that operates in two phases (Mahmoud et al., 2016a). The first phase aims to submit anonymous and unlinkable data to the CC, and the CC computes the charging schedules in the second phase by running a modified algorithm for the knapsack problem. The proposed charging coordination algorithm is efficient and scalable as it exhibits polynomial time complexity. In the charging coordination scheme, we define a priority function to prioritize the ESUs' requests by calculating a priority index for each request. The target of the coordination scheme is to charge in every time slot a subgroup of ESUs that maximize the total priority indices and subsequently the number of charged ESUs without surpassing the power limit. In the first phase and in order to boost the level of privacy preservation, each ESU can add a random noise to its data, i.e., TCC and SoC, to prevent the CC from linking the requests coming from a specific ESU. As adding noise to the data may influence the performance of the charging coordination scheme, we will explore the impact of noise addition on performance and the gains in privacy by utilizing information‐theoretic metric referred to as entropy (Díaz et al., San Francisco, CA, USA, 2003).
The remainder of the chapter is organized as follows. Existing charging coordination and privacy preservation schemes are introduced in Section 21.2. The network and threat models and the privacy‐preserving charging coordination scheme are explained in Section 21.3. Privacy analysis and simulation results are are discussed in Section 21.4. Finally, a summary is presented in Section 21.5.
In (Ismail et al., 2015b), Ismail et al. explain that the negative impacts of vast simultaneous charging of EVs can be addressed by using optimal design of charging facilities and charging coordination of EVs. In terms of optimal design of charging facilities, Ismail et al. present a novel optimal planning algorithm for EV‐charging facilities in (Ismail et al., 2015a). The planning model developed in (Ismail et al., 2015a) accounts for the stochastic nature of the EV‐ charging requests and determines the optimal number of chargers to be deployed within a charging station along with the queuing size within the charging facility. The proposed scheme is tested in various real‐world scenarios, and the results show positive profit values when optimal planning parameters are adopted.
On the other hand, coordinated charging can prevent stressing the distribution system and avoid power outages in extreme cases (Verzijlbergh et al., 2012). The main parts of the smart‐charging coordination systems include data collection and optimization (Sundstrom and Binding, 2012). The first part is responsible for collecting the data relevant to the ESUs' charging requests such as TCC and battery SoC. Typically, this part is carried out via an aggregator, which collects the data from the ESUs and sends it to the operator, and then the aggregator sends the charging decisions coming from the operator back to the ESUs. The optimization unit can make optimal coordinated charging decisions that maintain service reliability, maximize the operator's profit, satisfy system constraints, and meet the customer demands. In general, the following approaches can be distinguished for EV charging:
Numerous privacy‐preservation schemes are proposed in the literature for different smart grid applications such as advanced metering infrastructure (AMI) (Tonyali et al., 2016; Beussink et al., 2014; H. Mohammed and Akkaya, 2016) and power injection (Akula et al., 2015; Mahmoud et al., 2016b). AMI is a communications network that enables two‐way communication between utilities and customers. Smart meters send fine‐grained power consumption data in real time, e.g., every few seconds. In (Tonyali et al., 2016; Beussink et al., 2014), the authors used a data obfuscation mechanism and proposed secure and efficient algorithms to distribute obfuscation values within an AMI network. They presented a protocol that utilizes LTE‐direct for exchanging of data among various gateways. An efficient privacy‐preserving data collection scheme for smart grid AMI networks is proposed in (H. Mohammed and Akkaya, 2016). By using a lightweight symmetric‐key‐cryptography and hashing operations, the proposed scheme can collect the consumption data while preserving the customer privacy. The authors use the asymmetric‐key‐cryptography operations for key management that is executed every long time. In (Akula et al., 2015), the authors proposed a privacy‐preserving scheme for power injection in the smart grid that is based on the idea of aggregation of sensitive information of the storage units' owners to prevent the utility from knowing individual's sensitive information. The proposed scheme can be used for the authentication of the storage units and the integrity of their data. Mahmoud et al. proposed a novel secure and privacy‐preserving power injection querying scheme over AMI and LTE cellular networks in (Mahmoud et al., 2016b). The proposed scheme is based on two aggregation techniques to hide the storage units' sensitive information. They also developed a bilinear pairing‐based technique to enable the utility company to ensure the integrity and authenticity of the aggregated bid without accessing the individual bids coming from the storage units. Additionally, numerous privacy‐preservation schemes are proposed in the literature for different applications such as VANETs (Rabieh et al., 2016, 2015a; Mahmoud et al., 2014; Rabieh et al., 2015c, b, d), LTE networks (Haddad et al., 2016, 2015), autonomous vehicles (AVs) (Sherif et al., 2016), and mobile social network (MSN) (Oriero et al., 2016). However, these schemes cannot be applied effectively and efficiently in the smart grid due to its unique problems and requirements.
As the renewable energy will play a vital role in the smart grid, the energy storage units can be used to store the excess power at the period of strong sun or wind and inject power to the grid during peak hours. The same thing can be applied to the EVs' batteries, which can be treated as storage units. The utility companies should communicate with the storage units' owners to coordinate such a charging action. However, this type of communication may reveal some sensitive information about the owners such as their location or amount of power injected. This information can be used by the utility or by other owners to misbehave and gain more benefits. Without preserving the privacy and hiding such information, the storage unit owners or the utility company may face financial losses. However, the existing research in charging coordination in the smart grid, e.g., (Ismail et al., 2015b; Wang et al., 2014, 2015, 2016; Bayram et al., 2014; Shaaban et al., 2014a,b; Ismail et al., 2015a) do not consider the privacy preservation concerns. In addition, the works on privacy preservation in the smart grid, e.g., (Tonyali et al., 2016; Beussink et al., 2014; H. Mohammed and Akkaya, 2016; Akula et al., 2015; Mahmoud et al., 2016b) do not investigate the impact of the proposed schemes on the charging coordination efficiency. This motivates our work to study the impact of privacy preservation on charging coordination efficiency.
As outlined in Figure 21.1, the considered network model has various numbers of communities and CCs. Every community is composed of several ESUs and one aggregator. The aggregator and the CC can communicate by means of LTE or 4G (Saputro et al., 2012). The connection between the ESUs and the aggregator is based on either Wi‐Fi or LTE. The CC cannot communicate directly with ESUs; however, this must be done via the aggregators. The ESUs send charging requests to the CC via the aggregators. The CC determines the appropriate charging schedules and sends them back to the ESUs. A community is associated with an electric bus with loading limit of KWh. The normal load (residential, commercial, and industrial) signified by is known to the CC. Henceforth, the accessible charging limit for ESU charging at a given time slot is given by . In the event that the aggregated power requests of the ESUs are less than , all ESUs can charge at the same time. Generally, the proposed privacy‐preserving charging coordination scheme is utilized to satisfy the charging requests while keeping the aggregate charging power at .
For the threat model, an honest‐but‐curious model is employed, which assumes that the attackers do not aim to disturb the proper operation of the scheme, yet they are just interested in gathering private information. The attackers can be the aggregator, the CC, ESUs, and eavesdroppers. They may passively snoop on the communications to learn sensitive information. The attackers should not learn whether an EV needs to charge or not or the charging request data such as TCC and SoC. The CC needs TCC and SoC to run the charging coordination scheme, yet the information should be anonymized to preserve privacy. The CC should not have the ability to link an ESU's requests for high privacy assurance.
As outlined in Figure 21.2, the proposed scheme has two stages. In the anonymous data submission phase, ESUs send charging requests without revealing private data. In the charging coordination phase, the submitted information is utilized to generate charging schedules. First, a priority index for each ESU is calculated, and then a modified knapsack problem (Kellerer et al. 2004) algorithm is run to choose the subset of ESUs that can maximize the summation of the priority indices of scheduled ESUs without surpassing the total power limit.
The packets exchanged in the anonymous data submission phase are shown in Figure 21.3. Our goal is to empower the CC to run a charging coordination scheme without revealing private information. Time is divided into a group of slots of equivalent duration that covers the 24 hours of the day, with . At the start of every time slot, each ESU in a group should send a charging request packet ( ) to the aggregator. At a given time slot, the set of ESUs with charging requests is given by . Each ESU shares a symmetric key with the aggregator using any existing key agreement and exchange scheme such as the Diffie‐Hellman (Diffie and Hellman, 1976). The charging request has the ESU's unique identity ( ), an encryption with a symmetric key shared with the aggregator , and its signature on the packet ( ), where ( ) is the TCC, ( ) is the battery SoC, is the amount of power the ESU needs to charge, is an encryption with the public key of the CC, is a one‐time symmetric key, and is an encryption with the symmetric key shared among and the aggregator. Only the CC can acquire and utilize it to encrypt the ESU's charging schedule. After receiving a charging request, the aggregator first verifies the signature to guarantee that the packet is sent from . Then, it decrypts the packet to acquire . Finally, the aggregator sends the charging requests ( ) alongside its signature to the CC.
The CC should not have the ability to link a charging request to an ESU from the identity sent in the packet. One way to do that is by utilizing pseudonyms rather than the real identities. Another approach is that the aggregator can utilize a secret and random permutation to shuffle the ESUs' identities and their charging requests such that the charging information of one ESU is mapped to the identity of another random ESU in the community, as demonstrated in Figure 21.4. The figure shows that the data of ESU is sent under the name of ESU , the data of ESU is sent under the name of ESU , etc. The proposed permutation is not static, yet for each time slot, it maps charging information to various ESUs' identities and stores a mapping table. This table will be utilized to map charging schedules to their ESUs' identities. The CC should not have the ability to link an ESU's requests in various time slots by linking the charging data, i.e., TCC and SoC.
The CC uses its private key to decrypt the charging requests coming from the aggregator and runs the charging coordination scheme. The CC determines the charging schedules , and signs and returns them back to the aggregator. As shown in Figure 21.3, a charging schedule has the permutated identity and the encryption of the schedule utilizing the one‐time key sent by the ESU ( ). The schedule either permits ESU to charge in the present time slot (when ) and indicates its charging rate , or it postpones its charging request to a future time slot ( ). It should be noted that , , and indicate a symmetric‐key encryption with the one‐time key sent in the charging request, a symmetric‐key encryption with the key shared between an ESU and the aggregator, and an encryption with the public key of the CC, respectively. Upon receiving , the aggregator utilizes its permutation mapping table to undo the permutation, as shown in Figure 21.4, and transmits the charging schedules to the ESUs, as represented in Figure 21.3.
In light of the above discussion, the CC needs to know the charging request's data (TCC and battery SoC) to run the charging coordination scheme; however, it is hard to link the request to a particular ESU. Nonetheless, the CC can attempt to utilize the charging request data to connect an ESU's requests over various time slots since it is normal that the TCC is diminishing after some time, and if an ESU does not charge in the present time slot, its TCC and SoC in a future time slot should be near the reported values in the present time slot. Linking an ESU's requests is problematic due to the fact that it can be utilized to distinguish the ESU; furthermore, an excessive amount of data will be uncovered if the CC could recognize the ESU.
In order to prevent leaking information, ESUs should add noise to the real data in its charging requests. By adding noise to both the TCC and the battery SoC, the ESU reports its TCC as: and battery SoC as: , where and are random noise. It should be noted that an ESU pays only for the charging power that is recorded by the smart meter. Moreover, not all the ESUs in a community need to add noise to their charging requests such as ESUs of public places, e.g., shopping malls and governmental and educational buildings. In these cases, users can hide their data in a big amount of requests coming from the same location, and the linkability of requests will be hard.
Noise should be added to the charging requests' data ( and ) to make it hard for the charging controller to link the requests of an ESU sent at various time slots. We utilize an information‐theoretic metric called entropy (Díaz et al., San Francisco, CA, USA, 2003) to quantitatively measure the privacy preservation level that can be gained by adding noise. The idea of entropy in information theory gives an estimation of the information contained in a distribution of probabilities (Cover and Thomas, 1991. ISBN 0‐471‐06259‐6.). In (Díaz et al., San Francisco, CA, USA, 2003), the authors propose an information‐theoretic model utilizing entropy to evaluate the level of anonymity given by anonymous communication schemes. The model can measure the level of information acquired by attackers about the probability that a message is sent by a specific user. The entropy ( ) of linking a charging request sent at time slot to one of requests sent at time slot is given in Equation 21.1, where is a discrete random variable with probability mass function of , where is the probability that request sent at time and request sent at time are sent from same ESU.
The CC utilizes and of the packets sent in two distinct time slots to specify for every request , where and is the number of requests received at time . The probability is higher as and of the two requests and are close. is given in Equation 21.2, where and are the SoC of the request of interest sent at time and the SoC of the request sent at time , and and are the TCC of the request sent at time and the TCC of the request sent at time , and .
It is obvious that the term increases as and are close. Likewise, the term increases as the TCC of the two requests are close. For two requests sent from the same ESU at times and , TCC at time should be one less than the TCC at time . To guarantee that this part always gives a value in the range [0,1], is normalized by .
The entropy can describe the uncertainly of the charging controller about linking various requests sent from the same ESUs. The maximum entropy (i.e., the highest anonymity level) can be achieved when the probabilities for follow a uniform distribution, i.e., all the requests have a similar probability to be linked to request . In this case, data privacy is completely ensured, and the charging controller cannot link a request to a certain ESU or even to a subset of ESUs. The maximum entropy ( ) is given in Equation 21.3.
Once the sensitive information is concealed by using the aforementioned approaches, we next investigate how to utilize the information of the charging requests to calculate the charging schedules at every time slot. Each community is associated with an electric bus with loading limit of . At a given time slot, the regular load capacity is given by . Thus, the accessible charging limit with respect to the ESUs at a given time slot is given by . Due to the limited capacity ( ), it is possible that not all ESUs with charging requests can charge at the present time slot. Rather, our scheme calculates a priority index for each ESU, and the ESUs with high priority will be charged at the present time slot to guarantee that , while other ESUs' charging requests can be postponed to future time slots. Two components play a vital role in determining the ESU's priority for charging at the present time slot, to be specific, the TCC and the battery SoC . In particular, an ESU with low and short should have higher charging priority than an ESU with high and/or potentially long . Subsequently, for each ESU , we specify a priority function that is given by Equation 21.4, where is a decreasing function of with a range of and for long TCC and equals 1 for short TCC, and SoC value ( with for a completely charged ESU.
The relative significance of and are given by using weights and , with . An ESU with low value and short will have a high priority value . Henceforth, the CC's goal is to schedule the ESUs with highest priority for charging in the present time slot and postpone the charging of ESUs with lower priorities to future time slots because of the limit capacity in the present time slot. The charging schedules indicate whether a given ESU will be charged in the present time slot ( ) and the charging amount ( ), where
The charging coordination problem formulated in 21.5 is a mixed integer program (MIP) as it includes a real variable and a binary variable , which makes it NP‐complete. For a large‐scale problem (i.e., a large community with numerous ESUs), it is difficult to solve 21.5 in real time. Rather than solving the MIP in 21.5, we reformulate the charging coordination problem using an integer program (IP) that is less complex than 21.5, and is given by
As indicated in 21.6, a scheduled ESU gets its charging demand ( ) in the present time slot. However, if the difference is greater than 0 yet less than of all unscheduled ESUs, inefficient resource utilization is expected, as compared to 21.5 which ensures full resource utilization. To overcome such a disadvantage, the rest of the capacity after ESUs' scheduling as indicated by 21.6, , is assigned to the ESU with highest priority among all unscheduled ESUs. Such an ESU, which has not fully charged at the present time slot, will hold up to the next slot and get whatever is left of its charging request . A major advantage of the formulation in 21.6 is that it can be mapped to a well‐known optimization known as the knapsack problem (Kellerer et al. 2004).
In the knapsack problem, there is a knapsack with limited capacity and a set of items each with a given value (priority) and weight. The goal is to select a subset of items to be packed in the knapsack, such that the overall value of the packed items is maximized while respecting the knapsack capacity limit. The charging coordination problem at every time slot can be described as a knapsack problem as follows. The ESUs are mapped to the items, the ESU priority resembles the item value, the ESU charging request is equivalent to the item weight, and th charging limit constraint represents the knapsack limit. We modified a greedy algorithm designed for solving the knapsack problem in polynomial time given in (Kellerer et al. 2004) to schedule ESU charging at each time slot. Hence, the charging coordination mechanism can be described using Algorithm 1, which is implemented at the CC.
Neither the aggregator nor eavesdroppers can learn whether an ESU needs to charge or not or the amount of energy it needs. This is because the charging requests and schedules are encrypted by the CC's public key and one‐time keys. Also, an ESU should send a charging request with zero charging demand when it does not need to charge.
In a case that an eavesdropper colludes with the CC, they cannot link the charging requests to the ESUs in light of the fact that they cannot link the public‐key encryption ( ) received by the CC to the symmetric‐key encryption ( ) sent by an ESU. They cannot likewise link a schedule to its ESU as the schedules are encrypted with the keys shared with aggregator. Without this encryption, an eavesdropper can get the schedule packet ( ) and the CC can decrypt the schedule and link it to .
In a case that an ESU sends the same charging request information in consecutive time slots, the ciphertexts do not look the same because is utilized for only one time. For a similar reason, the ciphertexts of same schedules ( ) look different.
The ESUs can guarantee that the schedules are sent from the CC as no entity can recover aside from the CC. The ESUs can likewise guarantee that the schedule packets are sent from the aggregator since it appends its signature. The aggregator can ensure that the charging requests are sent from the ESUs since they are signed.
The CC gets enough information to run the charging coordination scheme, and privacy can be safeguarded due to the fact that the CC cannot link the charging requests to the ESUs. The CC cannot utilize the charging requests' identities or symmetric keys to link the requests of an ESU over consecutive time slots. This is on account of the random and secret identity permutation that is utilized by the aggregator and the one‐time random key that is utilized as a part of each charging request. Furthermore, noise addition to the charging requests can make linking the requests of an ESU over consecutive time slots hard.
In addition to privacy preservation, the proposed scheme is robust against repudiation attacks. An aggregator can ensure that a particular ESU performs a specific transaction or requests a service using the ESU's signature sent in the charging request packet ( ). This signature is sent in the packet that contains the real identity of the ESU, and the aggregator has to verify the signature before forwarding the request to the CC to guarantee that the packet is sent from a legitimate ESU. No one other than the ESU can compute a valid signature because the private key needed to compute the signature is known only to the ESU. Furthermore, we can classify the compromised ESUs to two types, internal and external attackers. Our proposed scheme is protected against external attackers that aim to disrupt the proper operation of the charging coordination mechanism due to requesting each ESU to send a signature to the aggregator. For the internal attackers, if an attacker tries to send charging requests outside its community, the aggregator can detect the attack because it knows the identities of all ESUs in its community.
MATLAB is utilized to evaluate the performance of the proposed privacy‐preserving charging coordination scheme. We set the ESUs' battery capacity to 200 units of power, and the accessible charging limit per time slot ( ) is 1000 units of power. We ran the simulation for 30 time slots, i.e., the slot span . At first, the framework has 7 ESUs that need to charge, and the arrival of new charging requests in every time slot follows a Poisson distribution with an average of . The SoC of each ESU battery is a random number uniformly distributed in . Time to complete charging ( ) is a random number that follows a geometric distribution with an average of 4. The presented results are the average of 80 runs. For the priority function, is set as follows
To measure the performance, we use the following metrics:
We will utilize equations explained in section 21.3.2.1 to measure the privacy level achieved by the noise addition. We will compare the privacy‐aware charging coordination scheme with two benchmarks:
For and , we attempted every conceivable values, and the optimal values were observed to be 0.9 and 0.1, respectively, as they result in the largest number of served ESUs and the highest satisfaction index at various charging demand rates.
Figure 21.5 presents the average number of expired requests without full charge at various charging request rates ( ), and Figure 21.6 gives the average satisfaction index at various values of . The figures show the performance of the FCFS and our schemes without including noise and with adding random uniformly distributed noise to the SoC and TCC values up to 15% and 30%.
In the figures, we consider two situations where 100% and 30% of the ESUs add noise. The figures can show that our scheme has less number of expired requests before the full charge and can accomplish a higher satisfaction index unlike the FCFS. Furthermore, as increases, our scheme presents a significant performance improvement compared with the FCFS, which demonstrates that a charging coordination scheme is completely necessary when the charging demand is much larger than the charging limit ( ). In this situation, our scheme can exploit the accessible resources to serve more demands before they expire by organizing the requests and serving the high priority requests first. A degradation in the performance can be observed as the number of ESUs that add noise increases. This can be credited to the fact that as the CC gets inaccurate data, the charging coordination deviates from the ideal results.
Figures 21.7 and 21.8 present the average entropy versus the charging demand rate when adding up to 15% and 30% noise, respectively. To measure the average entropy, we utilized Equation (6) to calculate the entropy of every request at every time slot. Compared with the case that has no noise addition, it can be seen that the entropy value improves by adding noise. This shows that it is harder for the CC to link an ESU's requests since adding noise can decrease the probability of linking an ESU's request at time to the same ESU's request at time . The figures also demonstrate that the entropy value improves as the noise level increases.
The maximum entropy can be obtained when is the same for all requests. In this case, it is difficult to link requests. The figures demonstrate that the entropy achieved by adding noise is near the maximum entropy. Also, it can be seen that as increases, the difference in privacy level between the instances with and without noise addition reduces. This is because as the number of requests increases, several requests can present SoC and TCC values that are close to the request of interest, and thus it is harder to link requests. This demonstrates that including noise is more helpful at low charging request rates and as the request rate increases, as it gets harder to link the requests because of the vast space of various requests. The fewer the number of ESUs that add noise, the less the entropy, and hence more noise should be added to maintain high entropy. In all cases, the optimal and privacy‐aware sub‐optimal charging coordination schemes display better performance compared with the FCFS particularly for high charging request rates.
The outcomes additionally uncover an interesting result with respect to the trade‐offs between privacy preservation and the charging coordination performance. Adding noise to SoC and enhances privacy since it can make linking an ESU's requests by the CC hard as affirmed by the entropy measurements given in Figures 21.7 and 21.8. However, it somewhat degrades the charging coordination performance compared with the given results of no noise addition cases as demonstrated in Figures 21.5 and 21.6. The four figures demonstrate that the performance of the charging coordination degrades with more gains in the privacy as the noise level increases. It can be seen that the performance of our scheme is still much superior to the FCFS, and a large amount of noise may not be required in the event of extensive number of charging requests.
To investigate the impact of noise addition on the charging coordination performance, Figures 21.9 and 21.10 demonstrate the trade‐off between the satisfaction index and the average entropy versus the noise level at and 20, respectively. As shown in the figures, increasing the noise level can increase the entropy; however, it reduces the satisfaction index. Furthermore, for the same noise level, the entropy increases as increases. The figures outline the trade‐off between privacy preservation and charging coordination performance. Noisy data can enhance the entropy yet decreases charging coordination performance. This trade‐off is not noteworthy at large , i.e., our scheme can accomplish high privacy preservation with superior charging coordination performance at large .
In this chapter, we have presented a privacy‐preserving charging coordination approach that can hide sensitive information while achieving high charging coordination performance. Our goal is to maximize the number of served charging requests before they expire without revealing private information or exceeding the maximum charging capacity. Simulation results revealed that both the optimal charging coordination scheme and the privacy‐aware charging coordination scheme exhibit an enhanced performance compared with FCFS approach particularly at a large charging demand situation. Also, the privacy‐aware scheme offers an interesting trade‐off between the charging coordination performance and privacy preservation. Our analysis has demonstrated that our approach can preserve privacy, and noise addition is an effective method to prevent linking requests. This has been qualitatively measured using entropy.
Our proposed scheme is secure against the external attackers that aim to disrupt the proper operation of the charging coordination scheme. In addition, the proposed scheme can also detect the internal attackers who send fake charging requests outside their community. In future work, we will extend the proposed charging coordination mechanism to secure it against internal attacks launched by compromised ESUs inside the same community.
This publication was made possible by NPRP grant # NPRP 9‐055‐2‐022 from the Qatar National Research Fund (a member of Qatar Foundation). The statements made herein are solely the responsibility of the authors.
3.144.143.31