Sovereign, Open, and Carrier-Grade: What SUSE Telco Cloud 3.6 Actually Delivers

Table of Contents

• Introduction
• What “Technology Preview” Actually Means
• MetalLB BGP Mode in SUSE Telco Cloud 3.6: Load Balancing That Talks to Your Network
• PTP (Precision Time Protocol) for 5G: The Problem No One Talks About Until a Cell Goes Dark
• Why Open Source Telco Infrastructure Is the Right Foundation for Sovereignty
• What SUSE Telco Cloud 3.6 Gives You End-to-End
• A Note on the VNF-to-CNF Transition
• The Practical Bottom Line
• How to follow from here
• Frequently Asked Questions

Introduction

There is a quiet reversal happening in telco infrastructure decisions.

For a few years, the direction was clear: move workloads to the public cloud, offload the infrastructure problem to a hyperscaler, and focus on running network functions. Then data residency got serious. Regulators started asking hard questions about where subscriber data lives. Operators running 5G core workloads on hyperscalers got a very uncomfortable answer.

Sovereign infrastructure is no longer a nice-to-have. For a growing number of Communication Service Providers (CSPs) in Europe, Asia, and the Middle East, it is the requirement. And “sovereign” in this context means one thing: you own the stack, it runs on your hardware, and no one else holds the keys.

The problem is that bare-metal Kubernetes for telco has always been a gap-riddled story. The platform exists. The components exist. But too many of them have been Technology Preview, community-supported, or simply not production-ready for carrier networks. SUSE Telco Cloud 3.6 closes two of the biggest gaps.

What this blog covers: – What MetalLB BGP mode is and why it matters for 5G network interfaces – What PTP (Precision Time Protocol) is and why it is required for TDD 5G cells – Why open source is the right foundation for sovereign telco infrastructure – What is new in SUSE Telco Cloud 3.6 and which features graduated to full support

What “Technology Preview” Actually Means

When a vendor ships a feature as Technology Preview, they are telling you something specific: it works, it is included, but it is not under the same support Service Level Agreement (SLA) as the rest of the product. You cannot run it in production and call your vendor if it breaks at 2am. For a CSP with a four-nines SLA, that is a hard no.

SUSE Telco Cloud 3.5 shipped two features in Technology Preview that telco engineers need:

• MetalLB Border Gateway Protocol (BGP) mode: BGP-based load balancing for bare-metal Kubernetes clusters
• PTP (Precision Time Protocol): IEEE 1588 timing for downstream deployments

In 3.6, both are fully supported. That is the headline. Let me explain why each one matters.

MetalLB BGP Mode in SUSE Telco Cloud 3.6: Load Balancing That Talks to Your Network

Standard Kubernetes load balancing assumes you are in a cloud. The cloud provider gives you a load balancer, assigns an external IP, and handles routing. On bare metal, there is no cloud provider. MetalLB fills that gap, it gives bare-metal clusters a way to expose services with real external IP addresses.

MetalLB has two modes. Layer 2 mode handles this with ARP (Address Resolution Protocol): one node announces ownership of the IP and all traffic flows through it. It works, but it is not how telco networks operate. You get a single point of failure on the announcing node, no real load distribution at the network level, and no integration with the routing fabric the operator already runs.

BGP mode is different. MetalLB peers directly with your routers via BGP, the same protocol that runs the internet and that every carrier network team knows. When a service needs an external IP, MetalLB advertises that route from multiple nodes simultaneously. Traffic load-balances at the router, not at a single Kubernetes node. If a node goes down, BGP withdraws the route automatically and traffic moves on.

For telco, this matters because your 5G interfaces are not arbitrary web traffic. The N2 interface between the gNB (5G base station) and the AMF (Access and Mobility Management Function), the N3 user-plane path between the gNB and the UPF (User Plane Function), the service endpoints for different network slices, all of these need stable, routable IP addresses that your transport network can reach and that fail over cleanly. BGP mode gives you that. Layer 2 mode does not.

Running MetalLB BGP in production, under full commercial support, also means you can use the same routing toolchain your network team already operates. No separate overlay, no proprietary load balancer, no cloud-provider dependency. The network is yours.

PTP (Precision Time Protocol) for 5G: The Problem No One Talks About Until a Cell Goes Dark

Precision Time Protocol is not glamorous. It is also not optional.

Time-Division Duplex (TDD) 5G networks require all cells to be synchronized to within microseconds of each other. If two adjacent cells transmit on different time slots simultaneously, they interfere with each other. The guard against that is phase synchronization, delivered via PTP (IEEE 1588). The target is under 3 microseconds of relative phase error between cells. At some site configurations, the requirement drops to 65 nanoseconds.

Without PTP, you cannot run TDD cells. Every mid-band 5G deployment, every C-band site, every mmWave small cell is TDD. That is nearly all of 5G.

What SUSE Telco Cloud 3.6 adds is full PTP support on downstream cluster deployments under standard commercial support. The typical architecture has a management cluster running centrally and downstream clusters at each edge site, each Radio Access Network (RAN) location, each hub. PTP now runs at those downstream sites with full SLA coverage. For operators deploying distributed RAN or Multi-Access Edge Computing (MEC) at scale, that is the difference between a pilot and a production deployment.

Key Insight: Software-only PTP cannot hit the nanosecond-range accuracy required for TDD 5G. Hardware timestamping is non-negotiable.

The implementation uses hardware timestamping at the Network Interface Card (NIC) level. Software-only PTP cannot hit the nanosecond-range accuracy that TDD requires. SUSE Telco Cloud 3.6 validates on Intel E830 NICs with hardware PTP support, aligning with the ITU-T G.8275.1 telecom profile that carriers specify.

Why Open Source Telco Infrastructure Is the Right Foundation for Sovereignty

MetalLB, K3s, RKE2, Rancher Fleet, Longhorn, NeuVector. Every infrastructure component in SUSE Telco Cloud is open source. That is not a coincidence and it is not just a cost argument.

When a CSP in Germany or Japan or Saudi Arabia is deciding whether to run sovereign 5G infrastructure, the open-source nature of the stack is part of the answer. The code is auditable. There are no proprietary APIs that lock you to a vendor. If SUSE stopped existing tomorrow, you would still have the upstream software, the community, and the freedom to run it, not to mention that all components are CNCF compatible. You own the stack in a way that you never could with other alternatives.

SUSE Telco Cloud is also a founding implementation of Project Sylva, the Linux Foundation Europe initiative that defines how cloud-native telco platforms should be built. Sylva exists specifically because European carriers wanted a community-governed reference architecture that did not belong to any single vendor. Deutsche Telekom, Orange, Telefónica, and Ericsson are all in the room. When SUSE ships a Sylva-compliant platform, that is a standard decision, not a marketing one.

What SUSE Telco Cloud 3.6 Gives You End-to-End

SUSE Telco Cloud 3.6 is the middle layer, it adds the full orchestration and lifecycle management layer for carrier-scale deployments. Here is the complete stack and where 3.6 advances each piece:

Layer	Component	3.6 Status
Multi-cluster management	Rancher Prime 2.14.1	Updated to latest version
Kubernetes (core/regional)	RKE2 1.35.3	Updated to latest version
Kubernetes (edge/RAN)	K3s 1.35.3	Updated to latest version
Load balancing	MetalLB 0.15.3 + BGP	Now fully supported
Timing	PTP (IEEE 1588 G.8275.1)	Now fully supported on downstream clusters
VNF/CNF coexistence	KubeVirt 1.7.0	Updated to latest version
Zero-trust security	SUSE Security 5.5.1	Updated to latest version
GitOps at scale	Fleet (in Rancher Prime)	Updated to latest version

The combination of BGP load balancing and PTP timing in the same fully-supported release is not incremental. These are the two capabilities that turn a well-built Kubernetes platform into something a network architect can actually commit to for RAN and 5G core.

A Note on the VNF-to-CNF Transition

Real-world 5G networks are rarely clean-slate environments. They are complex ecosystems where Virtual Network Functions (VNFs) and modern Cloud-Native Network Functions (CNFs) must coexist. We understand that this transition is a journey, not an overnight switch.

With KubeVirt 1.7.0 integrated into SUSE Telco Cloud 3.6, you can bridge this gap seamlessly. You gain the ability to run l virtual machines alongside containerized workloads on the same unified cluster. Most importantly, you manage both under a single pane of glass using Rancher Prime, leveraging your existing GitOps workflows to maintain operational consistency.

Sovereign infrastructure should empower your pace, not dictate it. By enabling this seamless coexistence, we give you the flexibility to modernize your infrastructure on your own terms, minimizing operational risk while protecting your existing technology investments.

The Practical Bottom Line

Carriers don’t move slowly because they lack options. They move slowly because the cost of a wrong decision at infrastructure level is enormous. A timing misconfiguration takes down TDD cells. A load balancer without proper failover drops 5G core traffic. A support gap at 2am becomes a front-page story.

3.6 is not a big-bang release. It is the release where two critical pieces moved from “you can run this” to “we’ve got you.” MetalLB BGP mode and PTP on downstream clusters are now in the same support tier as everything else in the stack. That reduces deployment risk, shortens the path from pilot to production, and cuts the cost of running a parallel proprietary solution. And that stack runs on your hardware, in your country, under your control, which means no hyperscaler bill, no data residency risk, and no vendor deciding your upgrade window.

If your team has been running these features in staging, waiting for that support commitment, 3.6 is your green light.

How to follow from here

1. Visit our Telco product page
2. Read this datasheet: Accelerate Telco Modernization
3. Access white paper: Defining the telco cloud for 5G networks

Frequently Asked Questions

What is SUSE Telco Cloud 3.6? SUSE Telco Cloud 3.6 is the telco-specific layer of the SUSE Edge platform, released on 27 May 2026. It adds carrier-grade networking, timing, and hardware acceleration on top of the SUSE Edge base. Key components include K3s 1.35.3, RKE2 1.35.3, Rancher Prime 2.14.1, MetalLB 0.15.3 with BGP fully supported, and PTP fully supported on downstream cluster deployments.

What is MetalLB BGP mode and why does it matter for telco? MetalLB is a load balancer for bare-metal Kubernetes clusters. In BGP (Border Gateway Protocol) mode, it peers directly with the carrier’s routers and advertises service IP addresses as BGP routes. This means 5G interfaces such as N2 (gNB to AMF) and N3 (gNB to UPF) get stable, routable IPs that fail over at the network level, not at a single Kubernetes node. In SUSE Telco Cloud 3.6, BGP mode graduated from Technology Preview to full commercial support.

What is PTP and why is it required for 5G? PTP (Precision Time Protocol, IEEE 1588) distributes time synchronization across a network to nanosecond-level accuracy. TDD 5G cells share the same frequency for uplink and downlink and must all switch direction at exactly the same moment. Without synchronization inside a 3-microsecond window, adjacent cells interfere with each other and service drops. PTP is not optional for any mid-band or mmWave 5G deployment. SUSE Telco Cloud 3.6 fully supports PTP on downstream cluster deployments, aligned with ITU-T G.8275.1.

Is SUSE Telco Cloud open source? Yes. Every infrastructure component fromK3s, RKE2, MetalLB, Rancher, Longhorn, NeuVector is open source. SUSE Telco Cloud provides a commercial implementation of Project Sylva, the Linux Foundation Europe open-source telco cloud framework. The code is auditable, the interfaces are community standards, and there are no proprietary APIs that create vendor lock-in.

What is sovereign telco infrastructure? Sovereign telco infrastructure means the operator owns and controls the full stack: the hardware, the OS, the Kubernetes distribution, and the data. Nothing runs on a third-party hyperscaler. Data stays in the operator’s country and jurisdiction. SUSE Telco Cloud supports this model by running entirely on operator-owned bare-metal, using open-source software governed by community standards rather than a single vendor.

What is new in SUSE Telco Cloud 3.6 compared to 3.5? The two biggest changes are MetalLB BGP mode and PTP support moving from Technology Preview to full commercial support. Additionally, 3.6 ships Kubernetes 1.35.3, Rancher Prime 2.14.1, KubeVirt 1.7.0, NeuVector 5.5.1, and adds support for single-stack IPv6 on downstream clusters.

What is Project Sylva? Project Sylva is a Linux Foundation Europe initiative that defines a community-governed reference architecture for cloud-native telco platforms. Its founding members include Deutsche Telekom, Orange, Telefónica, Ericsson, and SUSE. SUSE Telco Cloud is its commercial implementation.

SUSE Telco Cloud 3.6 and SUSE Telco Cloud 3.6 are available now. Release notes and full documentation: Release Notes – SUSE Telco Cloud 3.6

(Visited 1 times, 1 visits today)