Ahh, that age old question: where is the Edge, exactly?
Well, that depends on what it’s running.
Edge computing discussions tend to get hyperbolic quickly. It doesn’t take long for folks to start talking about futuristic apps demanding super-low latencies powered by thousands and thousands of edge sites.
Often lost in the edge computing conversation is how exactly demand will unfold and where edge locations are actually needed to meet incremental demand. Or what the network is capable of supporting now and where it must improve. We tend to talk deployment strategies before we truly consider edge app development timelines.
From Spirent’s perspective, the most ambitious edge requirements won’t materialize overnight. Rather, there will be a slow ramp-up that gradually sees edge sites moving closer to users as apps eventually require it.
There are parallels to how we saw online retail revolutionize shipping speeds – basically, low latency for home deliveries.
Amazon decided it would make 2-day shipping the gold standard and constructed a network of strategically located warehouses to support it. They exceeded consumer expectations until 1-day became the new competitive differentiator as more warehouses were placed closer to more customers. Eventually, demand for same-day delivery will be served as Amazon eyes traditional brick-and-mortar retail outlets right in its customers’ own neighborhoods.
Amazon introduced their 2-day delivery back in 2005. They provided a novel, wow-factor service and scaled with demand. To continue cutting delivery times and pushing the envelope with new delivery services, they ultimately moved closer and closer to the customer.
Edge adoption follows a similar path, albeit with much more compressed timelines. Still, all signs point to the most ambitious edge app requirements not materializing for at least the next few years.
Not all apps require a race to the lowest latency
Operators are busy sorting which next-gen apps can be deployed on their networks. Conversations around the possibilities that exist for machine-to-machine (M2M), enterprise Internet of Things (IoT), mobile cloud gaming, vehicle to everything (V2X), and more, are being balanced against what is actually in demand by customers.
In the meantime, a wide range of latency requirements are represented across the applications being discussed. Following is a summary of 5G latency requirements as outlined in 3GPP 5G R16.
Edge latency will not be one size fits all. A closer look reveals that the nearest-term use cases will not require the lowest latencies. This is an important consideration as the location of edge sites are planned. For instance, some apps will simply require infrastructure that’s already becoming available today, such as a connection to a 5G Standalone network. Others will need to be deployed at key network aggregation points to hit latency targets. The chart below from STL Partners describes the “level of edge” versus where different operators have so far announced they are testing or planned to deploy edge nodes.
Another consideration for edge location will be the mobility of users. An enterprise IoT app may generally require connectivity within a certain location whereas V2X will require coverage across many different locations. Networks will need to dynamically address this demand by spinning up the right compute resources nearest users.
Once again, we’re not talking about many thousands of edge sites at every tower, but rather strategically located deployments able to respond to real demand in the moment.
Smart edge strategies begin with benchmarking
Hitting required latency thresholds is just one part of the challenge. The other is doing it for a sustained period. In our testing, we’ve seen countless cases where a network was unable to maintain a certain latency threshold for an extended amount of time.
This wasn’t a concern with 4G apps like video that could simply buffer and adjust to a range of traffic flows. But it will matter for latency-sensitive applications, especially those that are mission-critical and essential to time-sensitive issues of safety, health, and wellbeing. Latency needs to be deterministic and consistent.
Hitting required latency thresholds is just one part of the challenge. The other is doing it for a sustained period.
But first thing’s first.
Operators must determine where to strategically place edge locations. That starts with understanding what speeds can be delivered today. We’ve been working with customers on this front, benchmarking performance across a wide range of locations, both urban and rural. This includes deployment options inside the network at peering points and network aggregation points, and outside the network at public cloud zones and regions, to determine suitability for meeting next-gen app latency requirements.
Determining specific locations and deployment options where performance can be consistently met or must be improved helps operators understand precisely how close to the customer edge locations need to be placed to meet expectations. We’re still a way off from a reality where we’ve got to sort thousands and thousands of edge sites. That said, ambitions are ripe and new entrants are looking to enter the market, such as utility providers whose infrastructure and real estate locations are well-positioned to bring 5G and edge hosting both closer to home and to remote rural locations.
In our next post, we’ll dive deeper into this subject, exploring how operators actually view and manage live edge performance in the operational network. This will include the role of live assurance in validating edge experiences, wherever they are.
To learn more, download our solution brief and visit our 5G Network Benchmarking page.