The Collision of Cloud and the Edge

By Josh Simer, Market Manager - Service Providers
 

As 5G deployments continue toward the goal of ubiquitous coverage, two apparently conflicting trends are developing: C-RAN and Edge Computing. C-RAN, or Centralized/Cloud Radio Access Network, is an architecture in which active equipment—most notably the BBU, or BaseBand Unit—gets moved away from the network edge and centralized or moved to “the cloud.” Edge computing is a trend by which more applications are hosted, and hence, more active equipment required—closer to the end user or closer to the network edge. To understand why these two apparently diametrically opposed trends are happening, we need to look at the drivers of each, and when we do, we’ll see there isn’t necessarily an inevitable “collision.” But Service Providers need to plan for each of these trends with a network that is expandable, flexible and accessible.

C-RAN

The rise of C-RAN architecture is based on the trend toward smaller cell sites and the fundamental physical and economic realities that creates. To provide more wireless bandwidth, and to use the new higher frequencies available for 5G, wireless operators need to plan for smaller cell site coverage areas. Hence, more cell sites in more places. As they move from fewer large, macro sites to orders of magnitude more small sites, it becomes harder and more expensive to find space for those sites. Accordingly, shrinking the amount of equipment at each site is critical. C-RAN helps accomplish this by centralizing some of that equipment, particularly the BBU. In addition, it is more expensive to emplace and maintain active equipment at multiple sites. It is much more economical to have centralized BBUs covering multiple small sites. Finally, centralizing these functions allows more economical use of capacity. Active equipment which covers only one cell site may be underutilized for large periods of time, whereas centralizing that equipment allows its capacity to be allocated among sites as needed. In a nutshell, these factors are very similar to those which drove the rise of “Cloud Computing,” when technologies like virtual servers made it more economical to concentrate compute power in a more central location. In the case of C-RAN, we are seeing these active equipment sites in locations like previously existing macro cell sites, powered street cabinets and in existing (but redesigned) central offices and head ends.
 

The seemingly opposed trend is Edge Computing, in which the active equipment which hosts applications and data gets moved closer to the network edge. 5G is also the underlying driver for this, albeit a different aspect of 5G. In this case, it is the Ultra Reliable, Low-Latency Communications (URLLC) promise of 5G: specifically, that it will enable applications which can count on 1 millisecond or less of “network-induced” latency. This is so rapid that even the limited speed of light becomes an issue. Light “only” travels 300 km or about 187 miles a millisecond in a vacuum and is slower in optical fiber and the atmosphere. There is simply no way for a signal to travel from a user to a single centralized global (or even continental/regional) datacenter in that time. For latency-sensitive communications, like remote surgeries or autonomous vehicles, we need to minimize the physical distance the signal must travel. This has driven the rise of “Edge Computing,” in which these latency-sensitive applications are hosted in smaller datacenters closer to the user.
 

At first glance, there seems to be a collision course here between C-RAN moving active equipment away from the Edge, and Edge Computing (or, the underlying URLLC imperative) moving it closer. But it is important to keep in mind that there are a few other variables in effect here.

 

First, the same fundamental reality that drives C-RAN and Cloud computing remains in effect. There are economic advantages to consolidating active equipment, especially servers and data storage devices. These devices need a temperature-controlled environment, and HVAC systems are more efficient at scale. It is also more efficient to centralize maintenance of these devices so technicians need to travel less. Physical security is easier to manage at fewer sites. These factors all push against moving lots of compute power out to street cabinets. Thus, an “Edge Datacenter” typically means a datacenter which covers all or a large part of a metropolitan area, or a redesigned Central Office/Head End. Both options retain certain advantages while keeping the physical distance down to a couple dozen miles, well within 1 millisecond.
 

Second, space and power considerations continue to have an impact. Space for street cabinets is limited and can be difficult to obtain. Even existing macro sites tend not to have a lot of space. By contrast, an Edge Datacenter which covers a section of a metropolitan area has more flexibility in location and can be built or repurposed as needed. Street cabinets with active equipment also require new power connections, which can be expensive. Concentrating equipment at a higher level makes it more economical to have not just one but multiple power connections for backup, along with more additional backup options such as generators.
 

Third, only certain applications will require the most extreme degree of URLLC. Latency of 1 millisecond or less is critical for certain things like autonomous vehicles—where you don’t want a delay in resolving a potential collision—and remote surgery, where you don’t want a delay causing an incision error. Applications like remote monitoring, gaming and video are not impacted by having an extra millisecond or two of network-induced latency. Furthermore, to address industrial and enterprise usage cases for 1 millisecond latency, it is often feasible to have equipment located at the customer, like a small headend within a highly automated factory. Thus, the economic drivers pushing compute further to the edge are only a subset of traffic.
 

The key to understanding what this means lies in that third factor—the applications which require 1 millisecond of latency. Many of these applications are not yet in use today, and the timing and way they develop is uncertain. There will also be applications enabled by URLLC which we have not yet imagined or considered. Today, there are relatively few arguments for pushing “edge computing” beyond a local/metropolitan data center or sometimes a CO/HE. What if this changes in the future? For example, what if autonomous vehicles require a network of equipment in powered street cabinets to function at scale? The answer, it turns out, is in building a network with the same characteristics we’ve discussed previously: Expandability, Flexibility, and Accessibility.  
 

In my next blog entry, I’ll discuss in more detail how these characteristics help build a network that will accommodate both these trends—however far they go and wherever they end up colliding.