Abstract
Multi-access edge computing (MEC) promises to deliver localized computing power and storage. Coupled with low-latency 5G radio access, this enables the creation of high added-value services for mobile users, such as in-vehicle infotainment or remote driving. The performance of these services as well as their scalability will however depend on how MEC will be deployed in 5G systems. This paper evaluates different MEC deployment options, coherent with the respective 5G migration phases, using an accurate and comprehensive end-to-end (E2E) system simulation model (exploiting Simu5G for radio access and Intel CoFluent for core network and MEC), taking into account user-related metrics, such as response time or MEC latency. Our results show that 4G radio access is going to be a bottleneck, preventing MEC services from scaling up. On the other hand, the introduction of 5G will allow a considerable higher penetration of MEC services.
Highlights
Edge computing has recently emerged as a promising evolution of cloud computing
This paper evaluates different Multi-access edge computing (MEC) deployment options, coherent with the respective 5G migration phases, using an accurate and comprehensive end-to-end (E2E) system simulation model, taking into account user-related metrics, such as response time or MEC latency
Our results show that 4G radio access is going to be a bottleneck, preventing MEC services from scaling up
Summary
Edge computing has recently emerged as a promising evolution of cloud computing. Its benefits include better scalability, especially when large amounts of data are involved (e.g., acquired from sensors), as well as lower latencies, which enable time-critical services, e.g., remote sensing and actuation or distributed gaming, and the preservation of privacy and context information (including that related to user location and access interface). Since 5G access is expected to dominate in the near future, there is a pressing need for a sound evaluation of MEC services and deployments in 5G networks Such an evaluation should factor in user-related performance metrics, related to both the computation and communication segments of a MEC service. The round-trip time experienced by a user for a request-response service will include both the communication latency, i.e., both access, core, and backhaul traversing up to a (possibly far away) MEC host, and to the computation time spent by the MEC app on the host itself, which in turn will depend on contention of shared computing resources (e.g., CPU, memory, storage). Nseertvwicoer.kNoeptewraotrokrsopsuepraetrovrissisnugpaenrvdisminagnaagnidngmaannaingsintagnacen oinf sataMnEceCosfyastMemECwislyl sbteemabwleitlol boeptaibmleizteo roepsotiumrcizeeurteilsiozuatricoenuetvileiznadtiyonnaemveicnadllyy,nea.mg.i,cbayllym, ieg.gra.,tibnygmanigdr/aotrinrgelaoncadt/ionrgreulsoecraatipnpgliucsaetiroanpspbliectawtieoenns MbeEtCweheonstMs, EfoCllhowositnsg, fcoollmowpuintagticoonmapnudtactoiomnmaunndiccaotmiomn urenqicuairtieomnernetqsu. irements
Sign-in/Register to view highlights & summary Sign-in/Register to access full text options 
Talk to us
Join us for a 30 min session where you can share your feedback and ask us any queries you have
Schedule a callDisclaimer: All third-party content on this website/platform is and will remain the property of their respective owners and is provided on "as is" basis without any warranties, express or implied. Use of third-party content does not indicate any affiliation, sponsorship with or endorsement by them. Any references to third-party content is to identify the corresponding services and shall be considered fair use under The CopyrightLaw.
