em architecture of which is specified in 3GPP TS 23.501. The assumption is to consider all logical functions (i.e. NFs and also AFs) as virtualized functions. The mapping of MEC entities into a 5G system is depicted in Figure 6.4.7. In particular: A MEC platform is implemented as a particular AF in 3GPP. The data plane in MEC architecture corresponds to a UPF in 3GPP. MEC applications are mapped to the local DN in 3GPP. Assuming such a system setup, one observes that the E2E 5G system performance depends not only on the performance of the RAN and core network system components, but also on the performance of the MEC functional entities, as well as the reference points interfacing Application Server CRAN/ MEC011 (VNF) (VNF) App Enablement (VNF) Local DN MEC platform VNF (3GPP AF) MEC Data Plane (3GPP UPF) Central 3GPP UPF MEC reference points 3GPP reference points Figure 6.4.7 3GPP-based 5G system architecture and example of the mapping of MEC entities to AF and UPF 5GC network elements. 6.4 Multi-Access Edge Computing these entities. As an example, the E2E latency, that is, the two-way delay between the UE and the MEC application, is composed of the Packet Delay Budget (PDB), defined in 5G as the E2E delay between the UE and UPF, with a confidence of 98% (3GPP TS 23.501), and the additional delay between the UPF and the local DN, where the MEC applications are located. This second latency component is not taken into account by 5G QoS Class Identifier (5QI) characteristics in 3GPP, although it is important for performance optimization, as it is tightly related to the instantiation of the MEC applications. As a consequence, since the user traffic termination point is at the MEC application (located in the DN), slicing-relevant per- formance metrics (such as PDB) are not sufficient to describe the overall E2E performance. MEC application instantiation and the related VM allocation should therefore be carefully designed, as per network slice requirements, to satisfy E2E latency requirements. Driven by the above consi