Industry Voices—Chua: Tripping the light fantastic with AWS Wavelength on Verizon 5G

One of the areas of edge computing that has garnered much attention is the collaboration between the world's largest telcos and the hyperscale cloud providers. With the increasing shift to mobile-centric connectivity by both consumers and enterprise, the 5G mobile edge is rising in importance.

RELATED: AT&T and Google Cloud forge 5G edge compute partnership for enterprises

From Amazon Web Services (AWS) to Microsoft Azure to Google Cloud Platform (GCP), their tie-ups with carriers worldwide promise to bring together major powerhouses to address the next big thing in cloud computing and mobile 5G.

Hands-on with AWS Wavelength on Verizon

At AvidThink, we wanted to move from the theoretical to the practical. We put on our dancing shoes (coding gloves), and sambaed with AWS Wavelength on Verizon—the first joint telco-hyperscaler mobile edge cloud. What we learned was 5G mmWave throughput can be impressive, but coverage consistency needs improvement, and that latency reductions from mobile edge clouds varies by location. We also experienced first-hand the convenience of a hyperscale cloud-powered mobile edge presence.

We've detailed our journey and initial findings in a pair of research blogs on the AvidThink site: Part 1 and Part 2. This article summarizes results and observations based on our first look at this cutting-edge platform.

Quick background

AWS Wavelength on Verizon involves AWS placing multiple racks of computing and storage hardware within Verizon's mobile aggregation sites. These mobile switching offices/centers are where mobile traffic from nearby cell sites come together to be processed. By placing computing resources in these locations, AWS can offer application developers a cloud service platform (AWS Wavelength) that's topologically as close to mobile users as possible — we're discounting cell site edge locations since those aren't economically viable yet.

To date, AWS Wavelength has seven publicly accessible locations: San Francisco Bay Area, Boston, New York, Washington DC, Atlanta, Dallas, and Miami. AWS and Verizon have indicated they will roll out 10 sites in the U.S. by the end of 2020. And AWS plans on rolling out global sites with other partners: Vodafone, KDDI, SK Telecom shortly. Note that resources on AWS Wavelength cost about 20% more than similar resources in a standard AWS Elastic Compute Cloud (EC2).

In our first round of tests, we purchased a Verizon Samsung S20 5G UW (Ultra Wideband) phone and drove around San Jose looking for mmWave sites to execute our series of performance tests. In our second round of tests, Verizon kindly offered us remote access to its 5G UW test labs in San Francisco, Boston (Waltham), and NYC (Bedminster)—thank you, Verizon! We were able to control a variety of different phones from the comfort of our homes. Note: even though these phones were situated in Verizon's labs, they were connected to public cell sites.

AWS Wavelength testing results summary

Details of how we tested are in our blog posts. We used a combination of ICMP pings and the iperf3 tool as part of our tests. We generated traffic between our phone (the user equipment or UE) and Amazon EC2 servers in Wavelength Zones and the closest EC2 regions (Amazon's large cloud data centers).

A quick summary of the results is as follows:

• We achieved an impressive peak of 3Gbps download speeds in our UDP (user datagram protocol) testing, about 80-100 Mbps in upload speeds.

• For TCP tests, we saw between 1-2 Gbps of download and 80-100Mbps of upload speeds.

• ICMP ping round-trip times (RTT) averaged 25ms to 100+ms depending on source and destination.

One caveat—mobile operators apply traffic management to their traffic. ICMP packets may get less priority than HTTP/TCP connections or UDP traffic, so the absolute figures might be suspect. We believe relative comparisons should be fair.

Here's a sample of results from our tests. Check out the AvidThink blog posts for details and more results.

Table 1: Ping Times from Handset to Different Servers
Table 2: TCP Performance from Handset to Different Servers

 

 

Observations and learnings

• Location matters—In our initial round of tests, we benefited from having a Northern California EC2 region close to us; thus, the SF Wavelength site added little additional value. In the NYC and Boston tests, the difference in RTTs was more pronounced, with Wavelength sites reducing latency by 20% to 38% on average. In these locations, paying that extra 20% premium to reduce latency might be worthwhile. Since the vast majority of metro areas might not be close to an EC2 region, Wavelength instances can help with latency.

• Location doesn't matter—On the throughput front, we did not see differences in performance when transferring data to and from EC2 regions versus the Wavelength zone. Many mobile network operators already have good connectivity to major cloud platforms, explaining the lack of throughput differences.

• Topology and mobile architecture matters —Without visibility into Verizon's topology, it's not clear why the SF region has much higher latencies. It's possible that the 5G architecture might be standalone (SA) in one region and non-standalone (NSA) in another, or maybe it's a different networking setup. In any case, we would expect latencies to drop as SA rollouts continue, topologies get optimized, and new edge sites are deployed.

• 5G mmWave is impressive but finicky—Having experienced the technology, we're looking forward to the day where mmWave coverage provides us gigabit services in our favorite spots. However, we think that mid-band 5G with a couple of hundred Mbps that's more reliable and with broader coverage might be the middle path for now. Verizon is likely going to expand along this route, as will AT&T. T-Mobile has been pushing the low- to mid-band message, given their spectrum holdings. That makes the upcoming C-band auction in the US even more exciting.

• Differentiating network latency vs. throughput—Our testing experience indicates that it's possible to mistakenly attribute faster application performance to lower latency, when in fact, it's due to increased bandwidth. For example, AWS and Verizon's partners indicated faster streaming media start times and improved application performance. What they experienced could be due to running on Verizon 5G UW with Gbps throughput that transfers data faster, as opposed to a lower RTT.

• Cloud-powered edges are convenient—The ability to fire up servers in multiple Wavelength zones across the country or world with a few clicks of a mouse or runs of a script is a powerful concept. For edge services that are extensions of familiar cloud environments, the frictionless experience for developers is critical to edge adoption.

• Network SLAs tied to the cloud will be powerful —As 5G rollouts continue, we expect MNOs to eventually figure out how to expose SLA provisioning via APIs. At that point, app developers should not concern themselves with a hodgepodge collection of different APIs or offerings from other carriers. They can declare what SLAs their applications require, and the cloud provider should make it happen across every primary mobile carrier.

• The edge should not just be about latency —While our primary goal in this test did focus on latency (and throughput), the edge provides more than just lower latency. Being overly focused on latency detracts from other business benefits. If you want to learn more about our views on the edge, check out AvidThink's recent 2020 Edge and Beyond report.

• Quantifying ROI on the edge premium not possible yet—We're not sure how best to calculate the ROI of paying a 20% to 30% premium over regular cloud instances for an edge instance when there aren't hard SLAs as yet. We realize that the bulk of latency and performance guarantees will have to come from the carriers who own the last mile. At this point, it's unlikely the carriers who are experimenting with these services will provide any SLAs, but we anticipate this will come.

In the end, we believe that having a mobile edge offering is vital to innovation. Without experimenting and trying out new ideas, we can't discover the 5G killer apps. Mobile 4G LTE spawned innovations like Uber and Lyft, and the public edge cloud can do the same for a new generation of mobile applications. We believe it's a bold and early investment on both AWS and Verizon's part that may not yield returns for some time, but it's an important step forward.

Next steps for mobile edge testing

We're looking forward to continuing our testing in the different Wavelength Zones. There are potential changes to the methodology that may yield more accurate results, which we will be trying out. And we can't wait to see other mobile edge offerings from the other carriers (e.g., Microsoft Azure + AT&T, which is supposed to launch soon) and try them out to see how they compare. Bring it on!

Roy Chua is founder and principal at AvidThink, an independent research and advisory service formed in 2018 out of SDxCentral's research group. Prior to co-founding SDxCentral and running its research and product teams, Chua was a management consultant working with both Fortune 500 and startup technology companies on go-to-market and product consulting. As an early proponent of the software-defined infrastructure movement, Chua is a frequent speaker at technology events in the telco and cloud space and a regular contributor to major leading online publications. A graduate of UC Berkeley's electrical engineering and computer science program and MIT's Sloan School of Business, Chua has 20+ years of experience in telco and enterprise cloud computing, networking and security, including founding several Silicon Valley startups. He can be reached at [email protected]; follow him at @avidthink and @wireroy

Industry Voices are opinion columns written by outside contributors—often industry experts or analysts—who are invited to the conversation by FierceTelecom staff. They do not represent the opinions of FierceTelecom.