# Privacy-Aware Access Protocols for MEC Applications in 5G +
## 4 Results and Discussion
### Analysis  
Let us first compare our solution with onion routing. Our solution uses one of the principles of onion routing (OR) [28]: the communication channels between UE and MNO and between MNO and MEC can be viewed as the first and second intermediate hops of an OR path, respectively. On the other hand, an OR path typically includes three or more intermediate nodes that are randomly chosen from a group of onion routers. Our solution has two nonrandom intermediate nodes on the path between Alice and APPIFY: MNO and MEC. Better protection of user privacy, e.g., from colluding MNO and MEC, could be achieved by adding a third node to the path. However, this would also increase the delay in the communication, and the solution would be more complex.  
Different variants of the solution would result from choosing different protocols for outer and inner channels. In the variant presented here, DTLS/UDP and TLS/TCP are used for the outer and inner channels, respectively. [PERSON] et al. [54] show that it is feasible to run TCP on top of DTLS in transport between onion routers: each stream of data has its own TCP connection, but the TCP packets are sent over DTLS protocol, which protects the TCP headers. An advantage of choosing these widely used protocols over custom-made protocols is that the solution is easier to deploy. On the other hand, variants based on custom-made protocols could be more efficient than variants based on standard protocols.  
The deployed solution should include measures against denial of service (DoS) attacks. In order to overload the servers, an attacker could try to open many DTLS connections towards the MEC host or TLS connections to APPIFY. Several mechanisms for mitigating DoS attacks exist [55; 56; 57; 52; 53] but we do not discuss those further.  
Below, we analyze how the solution in Section 4.1 meets the privacy requirements defined in Section 3.3. We assume that MNO, MEC, and APPIFY are honest but curious throughout our analysis. We start in Section 4.2.1 with the case where all the parties are independent. Then we consider the dependent cases in Section 4.2.2. The summary of the relation between the privacy requirements and the solution is presented in Table 1. As explained in Section 3.3.2, this table shows which of the privacy requirements apply in different dependency cases: if it is written N/A in the cell, then the privacy requirement is not applicable; otherwise, the privacy requirement is applicable. Table 1 also shows how the solution in Section 4.1 fulfills the privacy requirements: a black circle means that the privacy requirement is fully met, an empty circle means that the privacy requirement is partially fulfilled, and a dash means that the privacy requirement is not fulfilled.  
We will see that most of the requirements can be fulfilled by using outer and inner channels. Improved results could be obtained by using more sophisticated mechanisms, e.g., atfully-fledged onion routing between the parties. However, as discussed earlier, more sophisticated mechanisms would increase the complexity and cost of the solution, which would decrease the possibility of deployment.