If the media driven hype around 5G is anything to go by, it’s going to be a matter of time before we’ll be queuing up to have hair transplants performed by a remote surgeon (at least I will be anyway), or having pizza delivered by a 5G connected drone.
For those of us who’ve perhaps dug a little deeper into 5G, we know that although these headline-grabbing use cases MAY one day become a reality, there’s a number of technical hurdles which must be jumped before we get even close to reading the morning newspaper whilst the 5G connected car drives us to work…
Certainly, one of the key enablers for the next generation of 5G orientated services is MEC (Multi Access Edge Computing). As a one sentence description, you could say that MEC is a means by which you can provide compute/storage resources closer to the subscriber’s point of attachment to the network. So, in the case of 5G for example, it’s quite possible that the UPF (User Plane Function) is situated at the RAN site in order to provide access to MEC resources that are in close proximity to the subscriber. Ultimately, by doing this, the service provider can potentially reduce latency and avoid sending large amounts of traffic across the entire network.
In terms of use cases, AR (Augmented Reality) / VR (Virtual Reality) tends to be a well-used example due to the specific characteristics of AR/VR services. That is, to have a “strong” AR/VR experience, you typically need very low latency data delivery, coupled with significant volumes of data transfer (bearing in mind that maintaining low latency whilst also shifting large volumes of data is difficult to achieve). There are of course numerous other use cases for MEC, including UHD content caching, DNS caching, enhanced social media, smart infrastructure, IoT data aggregation – the list goes on. Ultimately, from the service provider’s perspective, these are all opportunities to monetize the 5G network in ways beyond billing subscribers for voice and data consumption.
So, how does MEC, which is standardized by ETSI, integrate with 5G, which is standardized by the 3GPP? Simply searching the 3GPP specifications for MEC won’t really provide a lot of answers. That said, this doesn’t mean that the 3GPP have not been thinking about support for Edge Computing in 5G. To the contrary, the 3GPP have introduced a significant number of enablers into the 5G System which, if deployed by the service provider, could directly support MEC applications. Figure 1 provides a summary of these techniques:
Figure 1 - Support for MEC in 5G
UPF Reselection – during PDU Session Establishment, the SMF (Session Management Function) will choose an appropriate UPF. During the lifetime of the PDU Session, the UPF may change based on the subscriber’s location. Therefore, if a local data network close to the subscriber is offering MEC services, the UPF can be reselected so that the user plane traffic is optimally routed.
Local Routing and Traffic Steering – based on techniques such as UL CL (Uplink Classifier) and IPv6 Multihoming, the device’s user plane traffic can be manipulated; some of the traffic can be filtered to be diverted to local MEC resources (termed “local access to the data network), whereas the remainder of the traffic can follow the regular path out to the Data Network.
Session and Service Continuity – when a PDU Session is established, it will be associated with one of three potential SSC Modes. These define IP address continuity for mobility scenarios and have a potentially significant impact on the mobility aspect of MEC applications.
AF Influenced Traffic Routing – by communicating with the PCF (Policy Control Function) either directly or via the NEF (Network Exposure Function), an MEC Application Function can influence how traffic is routed through the network e.g. the MEC AF can inform the 5G network that the subscriber has just launched a gaming app, with instructions for the 5G network to send gaming traffic to local MEC resources.
Network Capability Exposure – the PCF can exchange network capability information with the AF (Application Function) e.g. network events, provisioning, policy control, charging, analytics, either directly or via the NEF. This capability information could then influence the operation of MEC.
QoS and Charging – the PCF can provide QoS and Charging rules for PDU Sessions associated with MEC. This ensures the MEC related user plane traffic receives the correct QoS treatment and as such is then billed appropriately.
LADN (Local Area Data Network) – 5G supports LADN connectivity, which will be applicable to a specific geographical area. As such, the device must be in one of the collection of Tracking Areas that are serviced by the LADN to receive MEC based services which may be housed within the LADN.
Many of the techniques outlined here will require a complete 5G System, so there’s limited scope for deploying these solutions in today’s (mid 2019) largely Non-Standalone based 5G deployments. However, it’s imperative that service providers have MEC on their roadmap, since without it the next generation of 5G services that we’ve all been promised will potentially never materialize. My hair, at the very least, can’t wait much longer.
When this article was first published in mid-2019, we noted that most of the 5G enablers for MEC needed a complete 5G System, and that this limited what could be done in the largely Non-Standalone networks at the time. Seven years on, the picture has changed considerably, so here’s a look at what has happened since:
Figure 2 - 2026 MEC Update
Standalone 5G has Arrived (kind of)
Nearly 100 operators worldwide have now launched or soft-launched a 5G Standalone network. That means the techniques covered above are no longer theoretical. This includes UPF reselection, uplink classifiers, AF-influenced traffic routing and LADN. Non-Standalone still accounts for most 5G services globally, so edge capabilities remain uneven from one operator to the next.
3GPP Specifications
Back in 2019, we pointed out that searching the 3GPP specifications for “MEC” wouldn’t return much. That is no longer true as Release 17 introduced a dedicated application-layer architecture for edge computing, known as EDGEAPP (TS 23.558). It defines how a device discovers and connects to the most suitable edge application servers, using new functions such as the EES (Edge Enabler Server) and the ECS (Edge Configuration Server). Release 18 then extended this work, including better support for moving applications between edge sites as users move. ETSI MEC and the 3GPP have also worked to align their approaches, so the two standards now complement each other rather than run in parallel.
Network APIs
A newer development is the GMSA Open Gateway initiative and the CAMARA open-source API project. They both aim to give developers a common way to access network capabilities across operators, and edge discovery and interacting with the PCF (Policy Control Function) is a key part of that. Ultimately, this is the network capability exposure discussed within the original text packaged in a way that application developers can actually consume.
AI as a New Use Case
In 2019, AR/VR was the go-to example for MEC. Today, the conversation is dominated by AI inference at the edge of the network, meaning that we are running AI models close to the user or machine for real-time decisions. It’s increasingly linked to AI-RAN, where the same compute infrastructure at the network edge supports both the RAN and AI workloads. For example, T-Mobile, NVIDIA and Nokia have been piloting AI infrastructure at network sites to run vision AI and “physical” AI applications, such as robotics and smart city systems. If you’d like to know more, take a look at our blog, Understanding the Three Pillars of AI-RAN
If you require further training on 5G or MEC, why not explore our courses page or contact us directly.
If you would like to get a taste of our on-demand telecoms training, sign up to our 48-hour Free Trial. Gain access to our Learning Portal, 4 course modules and our learning tools NetX, NetXpert and NetXplore.
Blog reviewed and updated: October 2026