-   the expected/predicted traffic at each of them and its characteristics;

-   the network connectivity.

Given the above, we have to dimension the network computational capabilities, i.e., to decide (i) where to place the MEC servers, and (ii) the capacity they should have.

We solve this problem accounting also for the specific applications we deal with, thus developing an [*application-aware deployment*]{}, accommodating the requirements of each application. Indeed, such requirements can be substantially different for different [*categories*]{} of applications. As an example, we might be willing to serve such (comparatively) delay-tolerant content as video-like and map-like traffic through a server located in the core network, while real-time services like mobile gaming will require their servers to be much closer to the end users, possibly at individual base stations. It is important to stress that, in pure NFV/MEC fashion, we allow the same servers to serve multiple applications concurrently, provided that the server capacity is not exceeded.

At last, note that our input data is represented by the traffic that is [*actually*]{} served by the base stations. Consistently with MEC design best practices [@mec-survey; @mec-ton], we do not need to explicitly account for access-network issues such as congestion and interference. Indeed, 