Public MEC – Utilizing Public 5G Networks for Multi-Access Edge (MEC) Architectures

The following diagram illustrates an AWS Wavelength Zone and customers in the surrounding metropolitan area using it. AWS Wavelength is a public MEC solution, meaning any customer off the street can buy a SIM card from Vodafone, Verizon, KDDI, Bell, SK, or BT as appropriate and start using an EC2 instance or ECS/EKS container in the associated AWS Wavelength Zone:

Figure 10.3 – MEC with AWS Wavelength

Customers use 5G to build systems for many different purposes within a given metropolitan area, while the compute infrastructure at the 5G edge is shared among them. The underlying resources (AWS Outposts and AWS Direct Connect) supporting the EC2 instances or ECS/EKS containers are managed by the MNO, which offers the 5G service itself, thus enabling optimizations such as network slicing that extend from the customer devices to the compute resources involved.

Multicarrier and non-5G interoperability

Everything we’ve covered so far has been in the context of public MEC on one carrier – but there’s no reason an application has to be limited to a single 5G network. Nor is there a law saying all users of a given application must connect to it over 5G at all. You could architect a globally distributed application that allows certain users to benefit from the high speed and low latency available to 5G devices in appropriate regions. At the same time, other users connect via whatever means they have available, accepting higher latency:

Figure 10.4 – Multi-carrier public MEC architecture with AWS Wavelength

The preceding diagram shows a simple example of this where we assume the application on user devices has permission to query the user’s location. The client’s first step is to ask AWS Cloud Map which carrier IP they should attempt to reach given their latitude and longitude. This will yield response times as low as a single millisecond – the most ideal case:

Figure 10.5 – Fallback paths for users not on supported MNO networks

The preceding diagram shows what happens for other users of the application. Clients on a 5G device with a GPS position that matches an AWS Wavelength Zone would first try the carrier IP handed to them by AWS Cloud Map. If they can’t reach it, that must mean they aren’t on the correct MNO’s network. In this case, the client would then fall back to the next best thing, which in this case is a public IP behind an internet gateway in a standard AWS Region. Clients who are not on 5G at all will route through whatever internet connection they have to the closest resource; in this case, an AWS Local Zone.

This architecture would result in a wide range of user experiences depending on the location and client technology. AWS has been helping architects of multiplayer online games address these challenges for years. Such disparities in player Round Trip Time (RTT) are only increasing with the introduction of 5G-capable gaming devices such as the Razer Edge 5G sold by Verizon:

Figure 10.6 – Razer Edge 5G gaming device sold by Verizon

AWS has solutions that allow game builders to accommodate this type of device into a globally accessible game in the cloud. Game designers can create a situation where users of devices such as this that have 1 ms RTT to the game server are not overly advantaged compared to users that have a 30 ms RTT via their home internet connection.

You can think of Amazon GameLift as an Auto-Scaling group (ASG) that is specifically designed for the protocols involved with multiplayer games that span multiple geographies. It will launch additional game servers where needed based on demand. It also has a feature called FlexMatch that will group players with similar characteristics (such as RTT/latency) to ensure a level playing field.

The following diagram shows an example of an architecture for an online game that integrates these concepts:

Figure 10.7 – Using Amazon GameLift FlexMatch to send players to the best game servers