Multi-access edge computing, often referred to more simply as “edge computing” involves putting processing power, and storage closer to where data is created.
The European Telecommunications Standards Institute (ETSI) developed the multi-access edge computing (MEC) standard nearly 10 years ago. According to ETSI, MEC provides application developers and content providers with cloud-computing capabilities and an IT service environment at the edge of the network. Although MEC was originally developed as a cellular/mobile network standard (it used to be “mobile edge computing”), the acronym was changed to “multi-access” so as to include multiple access networks – not just the cellular radio access network (RAN) but other networks, as well (e.g., fiber, cable).
Here's what edge computing is, what it's used for – and, equally importantly, where it's not needed.
Benefits of MEC: Steadiness and Speed
At Enterprise Connect 2023 (EC23), Zeus Kerravala, Principal Analyst with ZK Research, moderated the session Cloud Communications 2026: Why Edge Computing is the Next Wave for Communications (CC26). “Edge comes in many flavors – 5G edge, IoT edge, telco edge, enterprise, campus and more,” Kerravala said. “The benefits include faster response time because you’re processing locally, improved reliability, security and compliance, improved performance from a reduction in latency and lower costs.”
Note that “locally” in "processing locally" does not necessarily mean on-premises (though it could) – and even if the MEC server is physically located at a site (e.g., stadium, hotel, etc.) it can still be within the carrier’s network. Typically, though, the MEC server is deployed within a site operated by the carrier (e.g., cell site, central office, data center, etc.).
Priti Vakil, Director, Workplace and Customer Experience at Verizon, who also spoke on that EC23 CC26 panel, said, “Cloud providers have embraced the ability to move their network edge closer to customers by building public/private MEC environments.”
Know Your Basic MEC Architecture
Take a look at Couchbase's handy graphic, which compares cloud computing with several possible types of edge computing. Note the WAN connection between the devices and the data center. That connection could be fiber, cable, (licensed) cellular, fixed wireless access, etc.
Source: Couchbase YouTube Video
The physical distance between edge and device is typically assumed to be less than the physical distance between device and a cloud data center…but proximity gets murky when hops, etc., are considered. When the WAN connection is severed, everything fails over to local processing until the connection is restored (which is why redundancy is usually part of any network architecture). Latency from device to edge is typically lower than from device to cloud, but this can vary.
Standard MEC Use Cases are Data-Centric
According to ETSI, MEC was developed to enable new vertical business segments and services for consumers and enterprise customers including vehicle to everything (V2X), video analytics, location services, Internet of Things (IoT), augmented reality, optimized local content distribution and data caching. It does this by creating that IT service environment within the network, as mentioned above. All these types of MEC-enabled applications have a common theme: they involve a lot of data storage, network throughput, low latency and processing power.
Here is Qualcomm's example of what that data storage/network throughput/ low latency trifecta could mean just for AR/VR headsets/glasses:
In the CC26 panel, Jarod Stokes, Senior Director, Research and Development with Lumen, said that “The edge allows you to move the workload close to the interactions you need processed – rendering, AI, etc.” Note that Lumen is a fiber network provider and that the “multi-access” part of MEC means that any type of access network is supported.
Leveraging MEC would be one way to enable the (ultralow) latency and very high throughput required by these “futuristic” AR/VR headsets/glasses, but the network connection would have to support those speeds and the capital expense associated with building out enough MEC sites could be prohibitive for general commercial use.
Where MEC Does Not Seem to Play a Role
The list of MEC applications that the technology/solution is suited for does not include multiple cloud-based communications technologies: unified communications as a solution (UCaaS), contact center as a service (CCaaS), communication platform as a service (CPAAS), video and collaboration services, etc. That’s probably because these services would not benefit from nor require, necessarily, the capabilities that MEC brings nor what it was designed for (V2X, IoT, AR/VR, etc.).
For example, a VoIP call on RingCentral’s platform requires 92 kilobits per second (Kbps) per call and has an upper limit on latency of approximately 150 ms. Also consider that VoIP’s been around for more than 25 years; it is a known quantity in terms of networking requirements and IT professional skillset.
With respect to video and collaboration tools – e.g., Microsoft Teams, Zoom, Cisco’s Webex – the throughput requirements range from 0.5 Mbps up/down for SD quality video to 3 Mbps up/down for HD quality video. (More detailed requirements are available here: Teams, Zoom, Webex.)
And regarding CCaaS, network requirements are not much more stringent. As one example, Cisco’s Webex Contact Center Agent Desktop User Guide cites minimum bandwidth requirements for the application: “A high-speed internet connection is required with a minimum recommended network bandwidth of 512 kbps (kilobits per second).”
As the Ookla data cited above showed, median throughput and latency in the U.S. for mobile and fixed broadband networks already provide capabilities sufficient to support these VoIP and video/collaboration requirements. There will be outlier regions – the Ookla data is for the median experience, after all – but the FCC’s twelfth Measuring Fixed Broadband report, released in January 2023, which found that the weighted average advertised download speed of the participating ISPs was 307.73 Mbps. The actual speeds experienced by the subscribers of most ISPs are close to or exceed the advertised speeds. There are still variations by location, time of day, etc., and “digital divide” challenges also persist in rural and other areas (see here for the FCC’s new national broadband map).
As the above examples illustrate, VoIP, video collaboration and even CCaaS applications do not require either “ultra low” latency or “ultra high” throughput as exemplified by the AR/VR requirements cited above. That type of use case – as well as V2X, some IoT, analytics, etc. – are likely to require either ultra low latency, ultra high throughput or some combination of both. Today’s commercial cellular and wired broadband networks cannot currently support either ultra low latency or ultra high throughput, nor are they (broadly speaking) architected for MEC.
There are, of course, many examples of very low latency and very high throughput networks in use all over the world (e.g., high-speed financial trading networks). But those networks are purpose built, rely on fiber and have many highly trained individuals supporting them. Which makes them expensive.
The point here is that those purpose-built networks, much less MEC, are not required for VoIP, video collaboration, CCaaS, UCaaS, etc.
Even today’s average computing devices, from smartphones to tablets to laptops, can likely handle the above network requirements. Obviously, device cost correlates to capabilities, so less expensive equipment (and/or older devices) might struggle with some of the above requirements, but they likely still support the minimum screen, camera, memory, processing power and network connectivity requirements.
There is also the more decentralized nature of MEC versus the centralized nature of cloud computing which is itself more conducive to how most people (employees, front-line workers, students, etc.) communicate and collaborate. Coordinating dozens, hundreds or thousands of edge sites would be equally as challenging as any network provider has in maintaining and running its networks. Although cloud computing diagrams typically show “the Internet” as a cloud between the premise and the data center, there is massive network complexity within that simple Internet graphic.
Most enterprises are already heavily invested in cloud-based solutions and/or considering ways to move to the cloud from their existing premises-based system. Those solutions may be generic software as a service (SaaS) and/or the more specific solutions discussed on this site – RingCentral, Webex, Zoom, Microsoft, etc., all boast multiple millions of multitenant and dedicated cloud-based seats.
Further, the market for UC/CC/CPaaS still has plenty of room to grow. During the Living in the MultiCaaS session at EC23, which NoJitter reported on, Brent Kelly with Omdia talked about the ongoing transition from on-premises PBX telephony seats (provided by established players like Avaya, NEC, Mitel, etc.) to cloud-based systems – the total addressable market is more than 447 million seats.
Remote Work Benefits from the Cloud – But Not From MEC
The pandemic-initiated shutdowns accelerated the need to support remote workers which helped to further cement reliance on cloud-based systems because those platforms provide multiple benefits – ease of deployment, management and support, scalability and agility, cost savings, etc. – particularly since employees were accessing their corporate data from wherever they lived.
Since it appears that the work-from-home (WFH) trend is here to stay, the UC/CC/CPaaS vendors have responded by leaning into the capabilities and scale provided by their cloud platforms. Throwing edge computing into the mix – assuming it made sense for communications/collaboration platforms – would be like adding speedbumps on a freeway.
As Kerravala said during the CC26 session, “The edge is optimized for real-time apps. It enables faster analytics and AI, better composability. But if you get more ‘things’ in more areas the edge adds complexity and creates new security challenges.”
So, if MEC doesn’t have a major role to play in UC and collaboration solutions, at least for the foreseeable future, then where does it fit?
Where MEC is a Good Fit: Some Examples from Verizon
At its kick-off 5G Innovation Session at Soldier Field in Chicago, IL, on April 17, 2023, Verizon demonstrated multiple “5G Edge” solutions which are powered, in part, by a partnership between Verizon and AWS that began in 2020 which, as of May 2022, allows Verizon offer 5G mobile edge computing via AWS Wavelength Zones in 19 U.S. locations.
According to Amazon, these zones are “AWS infrastructure deployments that embed AWS compute and storage services within telecommunications providers’ data centers at the edge of the 5G network, so application traffic can reach application servers running in Wavelength Zones without leaving the mobile providers’ network.”
This partnership demonstrates MEC with how it embeds the AWS IT service environment within Verizon’s network. Note that “the network” might sound like it’s monolithic, but Verizon’s edge in Chicago is different from Verizon’s edge in San Francisco; all edges are specific to their locations.
At Verizon’s 5G Innovation event, Jennifer Artley, senior vice president for 5G Acceleration at Verizon, described several opportunities for edge compute including ports, manufacturing and logistics (which includes warehouses and transportation).
Artley also cited venues – e.g., stadiums like Soldier Field, hotels, airports, conference centers, hospitals, etc. – as key areas for 5G innovation. Several of Verizon’s 5G MEC-powered solutions were highlighted at the event.
5G Edge Crowd Analytics combines light detection and ranging (lidar) with the MEC in Verizon’s network as well as movement tracking and analytics software via a partnership with Skyfii. The demo showed actual data from where the solution is currently deployed in Building 4 (the cafeteria) at Verizon’s headquarters in New Jersey – blue dots indicated where people were in (near) real-time. Each dot had fainter comet trails that showed their historical movement through the space.
Each lidar sensor covers about 150 feet in every direction and costs approximately $1,500 (note: coverage and price vary by sensor brand and SKU). Verizon said it cannot and does not correlate the individual to their device. The solution only maps individuals in the space and the AI software processing the data provided by the lidar can distinguish humans from other forms (chairs, tables, etc.). The solution will also update the map/schematic based on physical changes to the environment – e.g., someone moves a table in front of a door.
The result of these analytics is near real-time information on dwell and wait times, congestion, traffic flow, etc. throughout the venue. This information can be provided to guests via digital signage or via a mobile app (see the picture). In a stadium, guests could use this information to choose a less-crowded line or wait until the queue shortens.
No MEC in the Communications Stack
During the CC26 session, Stokes said that before businesses consider a MEC deployment they need to understand the “physics of latency, jitter, and speed along with data solvency and security implications. Are you producing enough data on the premise that it makes sense to push it to the edge and the intelligence you want to wrap around it. If you start with the data problem, you end up with a better solution.”
These Verizon examples illustrate how MEC can play a role across various stakeholders – the network owner (wired or wireless), the venue itself, businesses operating within the venue and end users. But in none of those uses cases does MEC currently play a role within the communications (e.g., UCaaS, CCaaS, CPaaS, collaboration) stack itself – the interactions between end users and businesses or among businesses themselves.
