Overview of architecting 5G-based MEC solutions – Utilizing Public 5G Networks for Multi-Access Edge (MEC) Architectures
As you’ll recall from Chapter 2, Multi-Access Edge Computing (MEC) refers to architectures that exploit the opportunity presented by the convergence of two forces in 5G architecture. First is the prevalence of Network Functions Virtualization (NFV) on commodity server hardware. Second is the fact that the User Plane Function (UPF) is distributed at the edge of 5G networks – as opposed to the centralized Packet Gateway (PGW).
MEC use cases we’ll review include online gaming, Computer Vision (CV), robotics, vehicle-to-everything (V2X), and new techniques for video production at live events. For publicly accessible systems running on Mobile Network Operator (MNO) networks, we’ll focus on AWS Wavelength. For private MEC solutions, we will cover using AWS Outposts and AWS Private 5G in the US, and the Integrated Private Wireless program in other regions.
In this chapter, we’re going to cover the following main topics:
Overview of architecting 5G-based MEC solutions
Observability, security, and capacity of Wi-Fi versus 5G
Computer Vision
V2X
Software-defined video production
Overview of architecting 5G-based MEC solutions
Imagine you are an architect tasked with designing a city-wide public safety solution for a major metropolitan area. You need to install Point-Tilt-Zoom (PTZ) cameras in strategic locations around the city. They must be positioned in such a way as to be able to target and track individual vehicles, pedestrians, or even drones in response to inferences from an ML model running in the cloud. Each camera module is capable of streaming multiple types of high-definition (8K) video simultaneously over RTSP – including optical, infrared, and LiDAR. Separately, they each have a command-and-control (C2) channel that must always function:
Figure 10.1 – Ruggedized PTZ multispectral 5G-capable camera system
As you walk around the city, identifying the best places to mount these systems, you realize getting high-speed internet access to them is going to be a challenge. One might go on the same pole as a street lamp. The next might need to be mounted on the side of a building three stories up. Another may need to be placed on its own pole next to a construction site.
You begin figuring out how to accomplish this by contacting multiple local broadband providers and determining which ones can cover which camera location. Each provider offers different speeds, different SLAs, different costs, and different technologies. Some will run cables all the way to your camera. Others take one look at where you want the device and say, “sorry, we aren’t licensed to do this.” You realize this is going to take a long time, be expensive, complex to manage, and some locations simply won’t meet the SLAs needed for either the control channel uptime requirement of 99.99%, while others won’t be able to ensure the 200 Mbps required for all possible RTSP streams. Then, the project manager pokes their head in your office and says, “by the way, we need to add 50 mobile cameras that can be set up and torn down by the police within 30 minutes each.” This is a problem.
A scenario such as this is perfect for 5G. Recall from Chapter 2 the discussion about network slicing. A 5G provider could provision each camera such that it has a network slice for HTTPS traffic that is limited to 5 Mbps but has an availability SLA of 99.99%, while a second network slice supports 300 Mbps but has a lower availability SLA of 99%. All cameras would use the same technology and get the same SLA. Better still, they can be powered up and connected immediately:
Figure 10.2 – GPU-accelerated EC2 instances available in AWS Wavelength
Combine 5G network slicing with the g4dn.2xlarge EC2 instances available in that metropolitan area’s AWS Wavelength Zone, and you’ve got an MEC-based solution that puts the ML model very close – at latencies as low as 1 ms (depending upon the MNO and your network slicing config).