The 4 Pillars of Service Edge Transformation

The choices you make now to evolve your edge networks will dictate the applications you can support and the ways you can build and differentiate your services.

June 6, 2019

4 Min Read
The 4 Pillars of Service Edge Transformation

With the emergence of 5G, analysts and enterprises are preparing for a new generation of dynamic, customized, and profitable business-to-business (B2B) services. However, work remains to be done before service provider networks can actually deliver them. The key challenge is a need for greater intelligence and computational capabilities at the service edge. In the 5G era, the service edge must evolve to enable new services and revenue models.

The choices you make now to evolve your edge networks will dictate the applications you can support and the ways you can build and differentiate your services. Regardless of the unique attributes of your market and strategy, however, the core pillars of successful edge transformation remain the same and need to occur.

1. Your applications and services should always be top of mind, and their requirements should dictate every edge decision you make.

Every decision about edge transformation should start with the service and what it requires. What will the network functions delivering this service look like? Will they be disaggregated, and how? Will the network components delivering the service be cloud-native? Hybrid? Most important, where will they be placed in the network? In reimagining the edge, consider the applications you’ll be running. Although use cases such as autonomous vehicles, ubiquitous AR/VR services, and online gaming are interesting to discuss, the industry will initially focus on foundational infrastructure use cases. Applications such as vRAN/cloud RAN, decomposed mobile packet core, CUPS-based BNG, vCMTS, Remote PHY, and GiLAN will create the baseline on which future applications will be built.

2. You will need to settle on a virtualization platform early on and decide what that looks like at different locations in the network.

Once you know what the service will be, you need to decide which virtualization platform will support it. What are the workload requirements? What is the consumption model? Virtual machines? Containers? Function-as-a-service? Will it be cloud-native? Are you implementing a model you’ll use for the foreseeable future? How will it evolve? Where does virtualization go in the network, and will the platform differ depending on where you are? Network functions virtualization (NFV) supporting OpenStack has transitioned through multiple incarnations. Recent successes have come from providing a common NFV Infrastructure (NFVI) layer upon which multiple VNFs from different vendors can be deployed with commonality at management/MANO layer. This current approach to virtualization tends to be highly centralized. It’s typically limited to a handful of central or regional data centers. Although NFV has been shown to deliver significant advantages in these environments, you can’t simply replicate the same approach in remote parts of the network and assume you’ll see the same results. Deciding how the virtualization platform will be distributed to support specific use cases is among the biggest questions the industry is working to answer.

3. You’ll need a next-generation network fabric to run services seamlessly across data centers, WAN, edge, and access.

The transformed service edge requires a new vision of a network fabric that connects myriad edge computing nodes such as COs, pre-aggregation, and regional data centers with centralized data centers. Indeed, as you shift towards a distributed edge computing model, the network fabric connecting these points becomes more critical to ensure the necessary latency and economics. To support new edge capabilities, compute capabilities that previously lived in centralized data centers will need to be distributed. The actual design of those network data centers will vary depending on their location in the network and the scale of VNF, services, and servers required.

4. As you distribute more functionality and capabilities out toward the edge, you will need to be able to automate this increasingly complex environment.

As you distribute more network functions and capabilities out towards the edge, it’s important to consider how you’ll automate this increasingly complex environment. How will you secure and assure services? And, increasingly, how will customers consume it? The transformed service edge will need to rein in the inherent complexity that comes with distributing capabilities like virtualization and multi-cloud out to more locations in the network. The only way it can exist in real-world service provider environments and be economical, is if you have as close as possible to a fully autonomous infrastructure. Service edge transformation therefore requires cross-domain orchestration. However, cross-domain orchestration doesn’t necessarily imply a single all-encompassing orchestration layer. You can still rely on separate controllers to orchestrate each individual domain. But in a reimagined edge, you will need the capability to seamlessly stitch these domain-specific controllers into a single solution that you can use to automate operations end to end. This process needs to happen in an open and standardized fashion that supports multi-vendor environments with physical and virtual network functions.

As the industry continues working to transform edge networks and services, we will continue to raise new questions. However, by focusing on these four pillars, you’ll be answering the most important ones first.

This content is sponsored by Cisco.

Subscribe and receive the latest news from the industry.
Join 62,000+ members. Yes it's completely free.

You May Also Like