Optimizing 5G N6 interface services with F5 and Red Hat

The telecommunications industry is at an inflection point. The choice of architectural framework by service providers will set the stage for the next 10 years. 5G networks were intentionally conceived as cloud-based—their use of a service-based architecture (SBA) combined with a cloud-native approach offers many advantages to service providers. Cloud-native network functions (CNFs) have become the main delivery mechanism of 5G network services.

SBA builds on Control and User Plane Separation (CUPS) concepts which enable service providers to decouple control and user plane functions that can be deployed as CNFs using containers and microservices. CNFs communicate with each other using a service-based interface (SBI). By integrating SBI into an orchestration system such as Kubernetes, CNFs provide scalability and performance benefits that were not possible in previous architectures.

This article focuses on the optimal solution for deploying CNFs required for the 5G N6 reference point, a network segment handling mobile device traffic to the internet. At N6 reference point, service providers can deliver value-added services such as firewall, carrier-grade NAT (CGNAT), deep packet inspection (DPI), policy control and traffic and content optimization.

Background

In the 5G network, the N6 interface (also called N6 reference point or N6 LAN) is the demarcation point for traffic between mobile devices and the internet. This demarcation in the 4G network is referred to as SGi interface or S/Gi LAN. The N6 interface not only carries data from User Plane Function (UPF ) to the internet, but also lets service providers offer various value-added services that differentiate service experience and monetize opportunities. These services include traffic management, firewall, network security, local DNS services, policy enforcement, carrier-grade NAT, video optimization and others.

At any given moment, millions of traffic flows need to be routed to the appropriate network function to meet policy enforcement or QoE (Quality of Experience) needs (e.g. http video traffic or TCP optimization and DPI). With the advent of 5G, traditional architectures are no longer suitable, because of the expectations of lower latency, higher throughput and having the capability to scale swiftly when demand requires it. Traditional service-chaining architectures increase the latency, defeating the 5G low-latency capabilities, and VMs have a large form factor which is not suitable for edge locations and don't scale swiftly because of their overhead. Moreover, 5G has embraced Kubernetes which greatly simplifies network functions for operators, reducing the cost of deploying and maintaining networks. In the past, service providers have relied on the best-of-breed solutions from different vendors of network functions.

Challenges

The exponential growth of end devices and data—for example, data collection and endpoint actions using IoT architectures—has accelerated the adoption of virtualization and containerization of network functions responsible for providing value-added services. The service providers also need to account for the varied needs of different 5G use cases. These can range from processing data at the edge of the network (edge computing) for lower latencies to dynamically scaling network functions in response to changing demand.

In addition to these, the service providers face several other challenges:

Increased latency of service chaining: One of the primary goals of 5G is to provide reduced and bound latency. The use of multiple user-plane network functions in a service chain might considerably increase processing time, defeating the primary goal of 5G.

Operational complexity: Mixing CNFs from various vendors adds CNF sprawl and operational complexity due to different tooling needed to manage these CNFs throughout their life cycle.

Consistency of the application platform: The service providers need the CNFs to be deployed across the network to where it makes most sense, whether different cloud providers, on-premise data centers, or edge locations. The application platform needs to provide a consistent experience across these different environments.

Proposed solution

F5 BIG-IP Next CNF solutions are a suite of Kubernetes-native 5G Network Functions, implemented as microservices, optimized for Red Hat OpenShift. Its functionalities come from a microservices re-architecture of the widely used F5 BIG-IP VNFs. This allows for a high performance, dependable product from the start.

The CNFs implemented by is solution are:

F5 Next Edge Firewall CNF is an IPv4/IPv6 firewall for protecting the 5G core networks from external threats, including DDoS flood protection and IPS protocol inspection.

F5 Next CGNAT CNF offers large scale NAT44 and NAT64 including Application level Gateway (ALG) support.

F5 Next DNS CNF provides a transparent DNS resolver and caching services. Other features are:

• Zero rating: It enables subscribers to bypass rate or quota limits for specific traffic. CNFs Zero-Rating solution accomplishes this by steering application traffic using split-view DNS.
• DNS64: It is a service that returns AAAA DNS records (IPv6) with synthetic IPv6 addresses for IPv4-only destinations which could not be reached otherwise from an IPv6-only network.

F5 Next Policy Enforcer CNF provides Traffic classification, steering and shaping, TCP and video optimization.

In this solution, Red Hat OpenShift lets service providers quickly develop and deploy containerized applications on a Kubernetes platform suitable for highly demanding network applications. 

The most relevant benefits from this solution are:

Deployment flexibility: Allows deployment from small clusters in the edge sites to large clusters in central data centers.

Thanks to being a true microservices architecture, these CNF solutions can be deployed from small clusters in edge sites while scaling to central offices. They share the same cloud-native engine (CNE) as F5 BIG-IP Next SPK introduced last year, and likewise make use of the widely trusted F5 BIG-IP’s Traffic Management Microkernel (TMM) data plane.

This data plane can scale from a tiny deployment to millions of subscribers:

• Dynamically scales horizontally from 1 to 32 pods
• Pods scale vertically from 1 to 16 cores

5G-ready performance: Allows for high per-core efficiency, reduces latency, and drastically cuts network requirements by eliminating or reducing the number of links needed when using service-chaining.

The data plane is consolidated for the multiple CNFs of the solution and features a zero-copy memory architecture resulting in a significant CPU usage reduction compared to other SGi-LAN / N6 LAN solution vendors. Traffic is processed in a single pass, creating a “single-hop” architecture that reduces the number of context switches. 

Conclusion

At 5G N6 reference point, service providers can deliver value-added services such as firewall, carrier-grade NAT (CGNAT), deep packet inspection (DPI) and policy control, along with traffic and content optimization. In this article we discussed the optimal solution for deploying CNFs at the N6 reference point. F5 BIG-IP Next CNF solutions provide Kubernetes-native 5G Network Functions, implemented as microservices, optimized for Red Hat OpenShift.

Try out F5 BIG-IP CNFs available in the Red Hat Ecosystem catalog. 

Check out Red Hat Portfolio Architecture Center for successful customer deployments for telecommunications, media and entertainment (TME) service providers.

Resources

• BIG-IP Next Cloud-Native Network Functions (CNFs)
• F5 BIG-IP Cloud-Native Network Function Solutions for Service Providers
• Cloud-Native Network Functions > Overview
• Telco 5G N6 LAN Consolidation with F5