## 6 Performance Analysis
### Latency  
In order to demonstrate the advantage of fog computing, this section discusses the latency of LBS searching, and gives a comparison with cloud computing-based schemes, e.g., the schemes proposed in [18; 19]. In general, the service latency is a time interval from a user sending a request to receiving the feedback, which contains the online computing delay and communication delay. In our FGPQ scheme, since fog nodes are local, the communication delay between mobile users and fog nodes can be neglected, and thus the latency absolutely depends on the online computing time in fog nodes. As shown in Table 1, the online computing time of the fog node \(id_{j}\) is \(2f\cdot C_{p}\) seconds, that is, the latency of our FGPQ scheme is \(2f\cdot C_{p}\) seconds. Alternatively, if the cloud computing system is adopted, the latency depends on the online computing time in the cloud and the communication delay between users and the cloud. Specifically, in the EPLQ scheme [18], the online computing time in the cloud is \((\log k+f)\cdot N\cdot(C_{p}+C_{mt})\) seconds (See Table 1). In addition, based on Table 2, the communication overheads between each user and a fog node are \(128\cdot f+1024(N+1)\) bits. Therefore, if \(l\) mobile users send requests to the cloud at the same time, the total network traffic is about \((128\cdot f+1024(N+1))\cdot l\) bits. As analysed in [34], the communication delay for uploading 10 MB data takes about 28 s, thereby, the communication delay of the EPLQ scheme [18] is about \((128\cdot f+1024(N+1))\cdot l\div 8388608\) s (1 MB =8,388,608 bits). Finally, the latency of the EPLQ scheme [18] is about \(((\log k+f)\cdot N\cdot(C_{p}+C_{mt})\cdot N\cdot(C_{p}+C_{mt})\cdot N\cdot(C _{p}+C_{mt})\cdot N\cdot(C_{p}+C_{mt})\cdot N\cdot(C_{p}+C_{mt})\cdot N\cdot(C _{p}  
\(C_{mt})+(128\cdot f+1024(N+1))\cdot l\div 8388608\) s. Similarity, based on Tables 1 and 2, the latency of the EPQ scheme [19] is about \((2k\cdot C_{p}+5k\cdot C_{mt}+(128f+6464)l\div 8388608)\) s.  
Furthermore, we conduct the experiments with the pairing-based cryptograph library (PBC) [35] and the GNU multiple precision arithmetic library (GMP) [36] running on a 2.6 GHz-processor computer to study the latency. To this end, we set the security parameter \(|\kappa|=512\) bits. Furthermore, similar to [18], we set \(N=37\). With the exact operation costs, we depict the variation of computational costs in terms of the number of LBS items \(k\), the number of matched LBS items and the number of mobile uses \(l\) who request LBS searching at the same time, in Figure 2. From the figure, it is obvious that our FGPQ scheme largely reduces the latency compared to the EPLQ scheme [18] and EPQ scheme [19]. In particular, in Figure 1(a), our FGPQ scheme remains unchanged when \(k\) increases. This is because our FGPQ scheme takes advantage of a very efficient ASPE algorithm, and uses this algorithm to originally select \(f\) encrypted LBS items matched the spatial range. In addition, in practice, the number of LBS data stored in each fog node is far less than the total LBS data (i.e., \(k_{j}\ll k\)). Therefore, the latency of our FGPQ scheme only depends on the time verifying whether \(f\) LBS data satisfy the searching content, i.e., \(2f\) pairing operations. In Figure 1(c), our FGPQ scheme still remains unchanged when \(l\) increases. The main reason is that the communication delay between mobile users and local fog nodes can be neglected, and the computing operations for \(l\) users can be performed in parallel. According to Figure 1(b), the latency of these three schemes increase with \(f\) increasing, but our scheme increase significantly slower.  
From the above analyses, our FGPQ scheme is indeed efficient in terms of computational and communication overheads, and also low-latency in fog computing-enhanced system, which is suitable for the real-time LBS searching for mobile users.