HiveMQ on AWS Wavelength at the edge of the 5G Network

This blog post explores how MQTT communication with HiveMQ and AWS Wavelength opens up new possibilities for AWS cloud customers to create low latency applications at the edge of the 5G network. The collaboration of telecommunication providers with AWS is what makes these use cases feasible.

Introduction to HiveMQ on AWS Wavelength

Here at HiveMQ we have had the opportunity to test the installation of the HiveMQ MQTT broker in a Wavelength Zone within Germany. The test results show that impressively low latencies for mobile applications are possible. On average, the round-trip time required for exchanging messages between user’s mobile phones took less than 30 milliseconds. This level of performance brings new types of applications that rely on ultra-low latencies in the 5G network within reach.

Test case for V2X

HiveMQ offers the perfect MQTT communication solution for an interconnected world of humans and things. While IoT may be an abbreviation for Internet of Things, the benefit to humans stands front and center in all IoT use cases. V2X use cases are a good example. V2X or Vehicle to Everything encompasses vehicle communication with smart traffic lights, other vehicles, pedestrians, or cyclists. Hazard warnings, congestion information, routing improvements, cyclist and pedestrian crossing warnings are just a few examples of possible applications.

Solutions like these have the potential to make traffic in our cities a lot safer, especially for vulnerable participants. V2X applications can be used to build smart traffic management systems, lessen traffic congestion, and power a host of other innovative ideas that are just waiting to be implemented.

V2X solutions rely on a scalable and performant MQTT communication hub such as the HiveMQ Platform. It is essential that the hub can support both fan-in and fan-out scenarios. A traffic light publishing status messages that are consumed by many vehicles in its proximity illustrates a fan-out scenario. Thousands of vehicles publishing location messages to a central congestion monitor constitute a fan-in scenario.

At the moment, telecommunication providers are rapidly advancing 5G coverage in their cellular networks. 5G offers two important advantages over previous technologies, radically reduced latency and significantly more bandwidth for data transfer. These attributes open the door for new approaches to implement V2X use cases.

The importance of low latency

Traffic participants are connected via the 5G network. To reduce latencies, it makes sense to move applications such as the HiveMQ MQTT broker to the edge of the 5G network. Telecommunication providers operate data centers at the edge of the 5G network specifically for the purpose of Multi-Access Edge Computing (MEC). The data centers provide low latencies to traffic participants within their proximity, striving to achieve network round trip times of 10 milliseconds or fewer.

Collision detection use cases, for example, are extremely time-critical. A vehicle traveling at 60 km/h moves 16 cm in 10 milliseconds. Delayed messages can mean the difference between whether a collision occurs or not.

Three factors determine the overall latency: the network, the message handling of the MQTT communication platform, and the use-case-specific backend processing. For many V2X use cases, the goal is to achieve a combined latency below 50 milliseconds.

AWS Wavelength

AWS announced their new Wavelength offering in 2019 in cooperation with telecommunication providers such as Vodafone, Verizon, SKT, and others. Wavelength offers a standard set of AWS services for compute and storage on the edge of the 5G network. As of June 16, 2021, fourteen AWS Wavelength Zones are available: US (10), Europe (1), Japan (2), and Korea (1). More zones are planned in the near future.

Technical Aspects

Wavelength Zones are connected to and are accessed through a parent AWS region. For example, the AWS London region “eu-west-2” offers a Wavelength Zone in cooperation with Vodafone with the zone name “euw2-wl1-lon-wlz1” in London.

AWS Wavelength Zones can be used similar to standard AWS Availability Zones. For example, a Virtual Private Cloud (VPC) can include subnets from Availability Zones and Wavelength Zones providing a single network space across all zones.

Wavelength Zones connect to the AWS parent region via a Direct Connect Link. This connection allows access to standard AWS services in the parent region, such as databases or S3 object storage.

In order to connect 5G users, a telecommunication specific Carrier Gateway is associated with the Wavelength subnet. In addition, a public-ip address or CarrierIP is allocated and attached to the AWS EC2 instance. This allows Network traffic to route directly from 5G users to the EC2 instance that runs the HiveMQ broker.

HiveMQ on Wavelength

A few technical aspects need to be taken into account when you install a HiveMQ MQTT message broker in a Wavelength Zone:

EC2 instance types

As of June 16th, 2021, Wavelength Zones provide access to 4 different EC2 instance types:

HiveMQ can be installed on all of these instance types; however, “t3.medium” is not suitable for production loads since it does not meet HiveMQ’s minimum requirements for available CPUs. The instance type “g4dn.2xlarge” is optimized for GPU workloads such as machine learning.

The “t3.xlarge” or “r5.2xlarge” instance types can be used for MQTT message workloads and we are looking forward to seeing a larger list of available instance types in the future that offer even more choices for MQTT use cases.

Load balancing

Currently, AWS does not provide a load balancer resource in Wavelength Zones. In the meantime, HAProxy can be used to load balance MQTT client traffic to a cluster of HiveMQ nodes. In this case, the Carrier IP is allocated to the HAProxy instance.

Connectivity to AWS services in the parent region

The S3 Cluster Discovery Extension is often deployed on AWS to support clustering of HiveMQ nodes. Wavelength Zones can incur a slightly higher latency to reach the S3 service in the parent region. Depending on the setup, the Wavelength subnet may also need to have a network route established to reach the S3 service or other services in the parent region.

HiveMQ on Kubernetes

AWS offers Kubernetes as a Service (EKS) in the Wavelength Zone. HiveMQ can be easily installed on Kubernetes using the HiveMQ Kubernetes Operator and Helm charts. Keep in mind that the Kubernetes control plane remains in the AWS parent region and only Kubernetes worker nodes run in the Wavelength Zone.

Operational aspects

A HiveMQ cluster deployed in a Wavelength Zone connects devices within a geographic proximity to support low latencies for 5G users. Multiple HiveMQ clusters can be deployed in multiple Wavelength Zones and managed through one AWS parent region. The AWS Virginia region “us-east-1”, for example, connects 6 Wavelength Zones that span cities from Boston to Miami. Automation and continuous deployment for all these Wavelength Zones can be centrally managed through the single parent region, simplifying infrastructure and operations.

Monitoring with Prometheus or InfluxDB and Grafana can be located in the parent region as well. For operational teams, this centralization simplifies the installation of comprehensive monitoring dashboards and alerting solutions. Teams that currently operate in a cloud-native environment on AWS will find the adoption of Wavelength easy and familiar.

Summary

HiveMQ on the Edge can provide low latency MQTT communication to 5G users. This communication can support many V2X, Smart City, and other use cases. The installation of HiveMQ into a Wavelength Zone is straightforward. The only prerequisite is to opt-in to using Wavelength Zones through the parent region. Currently, Wavelength Zones are offered through “us-east-1”, “us-west-2” and “eu-west-2” as well as regions in Korea and Japan.