A European telecom operator standardizes a three-tier carrier network on RLC Pro

This operator runs its network on commodity x86 infrastructure under an open, disaggregated architectural model, with carrier-grade SLA expectations and full compliance with GDPR, the EU NIS2 directive, and national cybersecurity authority requirements. Its engineering leadership identified Enterprise Linux as a foundational platform decision that needed a long-term partner aligned to telecom deployment cycles, not a vendor on a two to three year upstream cadence.

The procurement criteria were specific. The OS had to support a kernel version the team could certify once and pin, so its customizations for Open RAN DU workloads stayed valid without re-certification on every upstream point release. It had to scale across thousands of bare metal nodes, where every node runs the same image and behaves consistently under live traffic. It had to provide a support lifecycle that fits a multi-year network buildout. And it had to be Enterprise Linux compatible, so the network function vendors the operator had already certified would run without modification.

The operator evaluated the market and selected RLC Pro. The decision aligned the network’s platform layer with the company’s open source identity and with CIQ’s position as the founder and sponsor of Rocky Linux, the community distribution governed by the Rocky Enterprise Software Foundation.

The migration runs as a structured, multi-year program across all three tiers. At the edge, the clusters serving city and district sites run Rocky Linux 8.5 and 8.6 on the kernel profile the operator’s engineering team certified for Open RAN DU workloads. These clusters are moving to Rocky Linux 8.10 on the same certified configuration, with Rocky Linux 9.x on the forward roadmap.

In the central data center tier, new clusters deploy directly to RLC Pro. Legacy CentOS environments migrate on a sequential, server-by-server schedule built around the maintenance windows production telecom infrastructure requires. Through the transition, CIQ Bridge delivers backported fixes for Critical and Important CVEs across a curated set of priority packages to the legacy CentOS hosts that have not moved yet, so the unpatched window closes without re-platforming anything ahead of schedule.

CIQ Professional Services supports each phase with hardware validation, OS configuration review, and post-migration stabilization. The cadence and the sequence belong to the operator. CIQ provides the engineering depth that makes the program executable on the operator’s timeline.

The engagement has matured from baseline OS support into a working engineering relationship. CIQ kernel engineers take part in root-cause analysis on complex workloads at carrier scale, including OS-level investigation, driver compatibility review, and joint validation of network function stacks running on Rocky Linux.

That depth matters in a production telecom environment, where a standard support escalation model does not always match the operational tempo. The operator’s engineers work with CIQ engineering directly on issues that cross OS, kernel, and network function boundaries, and both teams have built the kind of familiarity that lets them move quickly when a complex investigation is required.

The same relationship supports the operator’s compliance posture. Proactive CVE and errata delivery, CIQ-signed packages, and a documented support lifecycle line up with what NIS2 expects around supply chain risk and platform maintenance, across every tier of the network.

The operator runs a three-tier carrier network on RLC Pro, with a structured migration program covering the remaining legacy footprint and a roadmap that extends through Rocky Linux 9.x. The platform decision aligns the network’s OS layer with the company’s identity as an open source telecom infrastructure provider, and the engineering partnership gives its teams direct access to the engineers who build and support the kernel it runs on.

Tier 1 and Tier 2 operators evaluating Open RAN face the same four requirements this operator solved: a kernel version they can certify once and pin, operational consistency at fleet scale, a support lifecycle that survives a multi-year buildout, and compatibility with the network function vendors they have already chosen. This deployment is a working reference for production-scale Open RAN on commercially supported Enterprise Linux.

See how a European telecom operator runs a three-tier Open RAN network on RLC Pro, and what it takes to certify a kernel once and run it unchanged across thousands of bare metal nodes.