# Privacy-Aware Access Protocols for MEC Applications in 5G +
## 3 Statement of the Problem
### Privacy Requirements
#### 3.3.2 Privacy Requirements for Dependent Parties  
When the parties are dependent, i.e., sharing information that is not strictly needed for providing the service, some of the privacy requirements may not be applicable. The parties may be dependent, for example, when they are parts of the same company. Next, we list the different combinations of dependent parties and analyze how these combinations affect the privacy requirements. Our model has three parties serving the user: MNO, MEC, and APPIFY. The number of dependency combinations between those three parties is five. (In general, when \(n\) parties serve the user, the number of dependency combinations equals the number of partitions of an \(n\)-element set, which is given by the Bell number \(B_{n}\)[49]). Table 1 shows, among other things, the applicability of the requirements in the five dependency combinations between MNO, MEC, and APPIFY. The cells with N/A represent the requirements that are not applicable, while the rest are applicable. Observe, first, that requirements R15-R20 are applicable in all combinations since the system should always be protected against outsiders. Second, all of the requirements, R1-R20, apply when MNO, MEC, and APPIFY are independent. This combination is represented in the column 'NONE' of Table 1. The applicability of the requirements in the other dependency combinations is discussed later in this section. Each of the three parties, MNO, MEC, and APPIFY, could also be dependent on outsiders. As described in Section 3.2, we have three types of outsiders: entities that are not visible in the system model, other subscribers of MNO, and other MEC applications. We do not consider dependencies with the first two types of outsiders any further. The reason is that they are potentially malicious, and collaborating with them would also make MNO, MEC, or APPIFY malicious. We do not include the third type of outsiders in Table 1 either, but we discuss dependencies with MEC applications other than APPIFY later in this section. Several users, several applications, or both, could collaborate between themselves in an onion-routing-like manner to improve privacy [28]. For example, [PERSON] wants to use APPIFY in MEC. In order to do this, [PERSON] sends a message to UE1, which belongs to another user; UE1 sends it to UE2, which belongs to a third user; UE2 sends it to APP1 in MEC; APP1 sends the message to APPIFY in MEC. By following this route, the parties in the middle and the outsiders cannot learn or understand that the original message is from [PERSON] and that it is intended for APPIFY in MEC. However, this kind of arrangement would make managing the system more complex and lead to less efficient protocols. Therefore, we assume that there is no systematic collaboration between different users or between different applications. Another example of collaboration is when an application coordinates its communication towards different users, including fabricated traffic. For example, when [PERSON] wants to initiate a connection with APPIFY in MEC, APPIFY initiates another connection with a similar traffic pattern with another user, e.g., [PERSON]. The APPIFY client in the UE of [PERSON] hides the dummy traffic from the end user. Outsiders and the parties between Alice and APPIFY would observe that both parties use APPIFY and have similar traffic patterns. Therefore, it would be hard for the other parties to understand which one of the users is really using the APPIFY in MEC. It should be noted that it is also possible that both users are intentionally using the application simultaneously. The downside of this kind of privacy protection measure is the doubling of the network traffic and energy consumption to provide the MEC application service to an individual user. Therefore, we assume that APPIFY is not coordinating actions between its sessions with different users. In summary, we assume that each session instance between Alice and APPIFY is run independently of any other session instances between any user and any MEC application.