Telecom: Virtualizing Radio Access Networks (RAN) – Why and How?

Franz Kasparec – 05 Jan 2021

Only a few years after the telco NFV (Network Function Virtualization) revolution, a new trend in mobile digital communication has emerged: virtualization of the RAN (Radio Access Network). Dedicated telecom appliances in the "micro-datacenters" at the base of cellular radio towers are being replaced by industry-standard Intel servers, which run Kubernetes-based cloud-native network function software. Once again, IT meets telecom: Two worlds converge.

The new telco technology comes at precisely the right time for 5G roll-out. Why should mobile carriers adopt it, and what is a safe way to do it?

Business Drivers

For the highly distributed radio access networks of mobile carriers, vRAN is what classic NFV is for the core network. It improves agility – SW updates and extensions are cheaper and easier to accomplish than appliance swaps – and lowers total cost of ownership (TCO). Novel future features may be available in SW form only.

On top of this come additional value propositions:

• Transparency. Open-source SW can be easily scanned for security backdoors, appliances with proprietary firmware less so. Countries considering telecom infra-structure a critical asset of their national security will go for transparent SW, and avoid deploying appliances from overseas vendors suspected of a political agenda.
• Colocation. In near to mid future telecom carriers are likely to be expected to deliver value-add services (VAS) out of their radio-tower "micro-datacenters", addressing ultra-reliable low latency communication (URLLC) requirements as from connected autonomous vehicles (CAVs) or life-supporting medical equipment. 3GPP Release 15 specifies a 1ms latency target, a figure likely to be realistic only if radio towers become "Far Edge" locations of VAS delivery.
• Openness. Open RAN, specifically, promises standardized interfaces across all compo-nents, so multi-vendor deployments are supported and vendor lock-in is pre-vented.

vRAN can be utilized for 5G and LTE, and solutions for 3G and before have been announced by the leading SW vendors. By 2030 standardized Open RAN is expected to cover more than half of all RAN deployments and establish a market estimated between tens to above 100 billion US dollar.

Figure 1: Datacenter LAN and LTE+5G RAN network stacks – a comparison

The Development of vRAN

The RAN network stack has some similarity with LAN network stacks of IT datacenters, as Fig. 1 demonstrates. However, what is accomplished by the network drivers of a PC or server operating system, has in a RAN until recently been done by dedicated HW appliances – called base-band units (BBUs). Now the BBUs are being converted to pure SW – virtual machines and containers on industry-standard Intel server HW.

Traditionally, the BBU appliances have been housed in the "micro-datacenter" shed at the foot of or integrated in a radio tower. This is called a distributed RAN (dRAN – cf. Fig. 2).

Figure 2: The evolution of RAN

The idea came up to centralize the BBUs in a datacenter, and to connect only the distributed radio units (RUs) through a so-called front-haul network line. This – the emergence of the centralized RAN (cRAN) – was the birth hour of all virtualized RAN (vRAN), because the deployment of virtualized BBUs (vBBUs) on a datacenter NFVi pod would be an inviting by-product of centralization. However, the RUs and antennas must stay where they are, and the front-haul connection is very sensitive to bandwidth, latency and jitter effects, which limits the viability of the solution.

In technical terms, the functional split between the RU and the vBBU would be between the PHY and MAC layers in Fig. 1 – split option 6. Everything PHY and below is RU and antenna matter, everything MAC and above is vBBU responsibility.

Where an optical or copper cable front-haul is possible over short distance, cRAN solutions are a viable choice. That can be the case, for example, between a far edge datacenter and several cell sites surrounding it.

The break-through of vRAN came with the disaggregation of real-time functions – RLC and below in Fig. 1 – and computationally intensive non-real-time functions – PDCP and above. Fig. 3 explains the architecture. RLC and below functions (except RF) are combined in the distributed unit (DU or, when virtualized, vDU), whereas PDCP and above go into the central unit (CU or vCU). The mid-haul network connection – that is the name of the link connecting the DU and the CU – typically uses split option 2 (Fig. 1).

Of course it is possible to run the RU and the vDU in different locations, too, as in the dRAN approach. However, for the split 7.2 between the two – discussed farther down in this article – all the bandwidth, latency, and jitter challenges apply again.

Disaggregated vRAN can be of the modern Open RAN variant, striving at standardization of all the relevant network interfaces – the front-haul, the mid-haul, and the back-haul (between the vCU and the cell-site gateway router of the datacenter running the core network). The name O-RAN, specifically, stands for Open RAN from the O?RAN alliance, an association of vendors promoting Open RAN technology.

Needless to say that the DU, responsible for the real-time function in the RAN network stack, is a very sensitive component. It normally runs on an edge server in the vicinity of the radio tower.

It is common today to use split option 7.2 (Fig. 1 and 3) today for the front-haul; i.e. the lower part of the PHY layer would be handled by the radio unit (RU) and the upper part by the vDU. Interface specifications like Common Public Radio Interface (CPRI) and Ethernet CPRI (eCPRI) have emerged for this purpose.

Figure 3: Disaggregated RAN

In 5G it has become standard practice to employ eCPRI and to always virtualize the DU. Virtualization of the DU is almost always based on network function cloudi-fication (NFC) with Kubernetes. NFC can be considered the successor of NFV.

One of the best-known architectural blueprints for disaggregated and virtualized RAN is the FlexRAN architecture by Intel. FlexRAN stipulates an Intel FPGA accelerator card to offload computationally intensive signal processing workload occurring in the lower PHY layer. The typical HW platform for the vDU is a two-socket Intel server with one or two FPGA accelerator cards, running (ideally) a real-time core Linux kernel and bare-metal Kubernetes.

The Role of the Network Integrator

While the vision of Open RAN is intriguing, especially the vDU, its split 7.2 eCPRI connection to the RU, and its HW and bare-metal Kubernetes platform are ridden with pitfalls. Carriers wishing to deploy vRAN today have the choice between buying an off-the-shelf solution – which may be "Half-Open RAN" – and thereby risking vendor lock-in, or doing a lot of in-house convergence testing at their own expense.

Employing a system or network integrator knowledgeable in RAN technology is a smart third option. System integration costs are offset by the price advantages of adopting an open systems approach.

The author's employer, Atos S.E., has many years of experience in building IT cloud solutions, with both conventional hypervisors and with Kubernetes, and since 2016 has supported telecom customers in NFVi imple-mentation and virtual network function (VNF) deployment. Atos is also known for expertise in NFV management & orchestration (MANO) solutions, and operations support system (OSS) integration. Atos is also a vendor of high-end edge server and security HW.

The author is globally responsible for digital infrastructure and cybersecurity offerings of the TMT (Telecom, Media, Technologies) vertical industry organization of Atos.

A capable network integrator can be expected to support carriers with the following vRAN services:

• Assist with the development of a RAN modernization plan. Questions to be address include the size and distribution of existing radio towers, extension plans (e.g. campus micro-cell offerings), the accessibility of the tower sites, or the availability of edge datacenters nearby.
• Advise on technology and vendor selection. One important question when choosing an Open RAN product is how far back older mobile networks need to be supported: 5G and legacy LTE are implicit, but should 3G and/or 2G also be carried? In some geographies the life cycles of 3G and 2G are far from over, and compatibility vRAN solutions are entering the market.
• Design and build the infrastructure, from HW – hyperscale architectures for the vCU and other central network functions, edge servers with FPGA cards for the vDU – through operating platforms, typically a Kubernetes execution environment today.
• Execute lab tests and proofs of concept (POCs) for the complete vRAN system. Atos operates a telecom solutions lab in Grenoble, France, to do interoperability tests and custom solution development. On top of that many telecom customers wish to set up an on-premise reference POC before starting the roll-out of a RAN modernization program. Together with partners Atos can also deliver Labs as a Service (LaaS).
• Be prime contractor for the roll-out proper, and roll-out testing programs.
• Increasingly, decarbonization of the Radio Access Network plays a role. 5G is an energy saving technology, because advances in massive MIMO antennas and related technologies significantly reduce the broadcast energy needed to transmit a certain amount of information over a given distance – the "GByte per kJoule" parameter. Likewise, overall energy, asset and availability management of the (potentially solar-powered) cell sites is of increasing importance. Atos runs several projects to create a "digital twin" model of a carrier's network and to employ data analytics and AI to optimize asset management, maintenance, and energy usage.

Complex roll-our programs should by iterative, applying a PLAN-DO-CHECK-ACT Deming methodology (Fig. 4): Execution of an initial PLAN – the DOing, so to say – needs to be followed by a CHECK step, and by ACTing on the results of this check, i.e. by immediate implementation of necessary and viable improvements. Lessons learned in each iteration feed into the fine-tuned PLANning of the next phase of the program.

Figure 4: PLAN-DO-CHECK-ACT Deming Wheel. Diagram by Karn G. Bulsuk (https://www.bulsuk.com)

Open RAN is a new technology in motion, subject to rapid ongoing development. Expertise is hard to get and erodes quickly. Experience from past enterprise IT cloud and from core-network NFV projects is a key foundation to continually evaluate the status of technology, and to keep vRAN projects smooth and open to ongoing technological progress.

The Partner Ecosystem

Another important role of a successful network integrator is to "know who to speak to". As explained, the Open RAN product scene is rapidly evolving, and innovations enter the market fast.

In that situation, waiting for progress to slow down may be the wrong strategy. Cooperating with the leaders in critical component technologies and making sure there is an innovation roadmap is the way to go. (After all, an open technology roadmap is one of the reasons why many telcos shun vendors' proprietary solutions and prefer open systems.)

Figure 5: System integration partner ecosystem

A good system integrator will maintain close alliances with an ecosystem of technology leaders in two independent areas, to ensure continuous up-to-date technology readiness (cf. Fig. 5):

• Application-level partners, who offer vDU and vCU software (mostly Intel FlexRAN), and ensure eCPRI and split-7.2 compatibility with eligible radio units.
• Infrastructure-level partners, who offer suitable HW (servers, FPGA accelerators) and platforms (bare-metal Kubernetes, Kubernetes on OpenStack, and more). In Atos, that is complemented by the in-house BullSequana product line.

Such a dual, carefully maintained partner ecosystem, in combination with years of cloud and NFV integrator expertise, strongly contributes to de-risking the RAN modernization projects of a telecom operator wishing to be innovative and strictly vendor-independent.

franz@kasparec.net

?05-Jan-2021