Telecommunications networks are invariably built with Network Elements (NE) or nodes performing a myriad of networking functions. Those NEs are interwoven by a web of optical, wireless, or copper-based links, ensuring that data flows between them.
Each network element typically caters for several network functions. Some well-known NEs are for example a router, a base station, a CPE, a firewall, a load balancer, a security gateway, a Wi-Fi access point (Figure 1), a Home Location Register etc.
What is virtualization in a telco context?
Traditional network elements and telco networks are created using purpose-built, dedicated hardware with proprietary, vendor-specific firmware on top. Those traditional network appliances are also referred to as “monolithic”, denoting that the HW and SW (in fact FW) cannot be separated or disaggregated. More often than not, it is hard or even impossible to add entirely new network functions to a monolithic network element, significantly delaying and increasing the cost for the deployment of new services that depend on new network functions.
Network function virtualization (NFV) – or virtualization in short – comprises the decoupling or disaggregation of the hardware and the software of a network element. All the network functions are implemented entirely in software, and that software runs on any industry-standard generic COTS server or even on private or public cloud infrastructure. The software, which can be supplied by different vendors, just like the hardware, can be decomposed into building blocks that may connect, or chain together, to create and deliver bespoke communication services. This approach precludes any vendor lock-in, in both the HW and the SW domain.
The paradigm shift of implementing network functions entirely in software and decoupling that software from vendor-specific hardware ensures a flexible network architecture enabling fast and even dynamic service scaling and rapid new service rollouts whilst materially cutting TCO.
Virtualization is now!
Network infrastructure virtualization is swiftly advancing from the realm of promising concepts and the proverbial “drawing board” towards being a reality in production networks.
In a recent survey (March 2022) conducted by Light Reading, service providers and other players active in the telecommunications domain are already deeply imbued in the virtualization of their networking assets.
As can be inferred from Figure 3 above, about 50% of the respondents have virtualized at least parts of their networking infrastructure already. Another 20% believe that they will do so in the next 12 months, and about 1/3 do not have a concrete plan yet.
In terms of the next and perhaps ultimate level of virtualization – putting their network in a cloud – the same respondents appear to be less certain at this moment – Figure 4. About 50% are using or plan to use cloud-native network services, whereas the other half either doesn’t know or doesn’t believe that it fits their business.
Some of the benefits of network service or network function virtualization in the cloud are: easy and – if required even dynamic – capacity scaling, simple implementation of (geographical) redundancy and thus very high network availability and the possibility to apply continuous integration, continuous deployment (CI/CD). CI/CD could become a disruptor in the networking and telecommunications business, as it holds the promise of reducing (SW) maintenance cost by up to 90%, according to one MNO industry source.
Virtualization of a 5G network
Let’s consider a 5G (and 4G) network as an example for virtualization in a telecommunications network. The general notion behind telco virtualization is to apply the same concepts that hyperscalers have successfully applied to computation and storage, but now to networking. This virtualization approach aims to accelerate network innovation cycles while at the same time reducing Total Cost of Ownership.
As can be seen in Figure 5, the entire 5G core network plus the Control Plane, Subscriber Management, Automation and Orchestration and OSS/BSS network functions are well suited for virtualization, and even cloud-native (CN) virtualization.
The same applies to the 5G Centralized Unit (CU) function if located and centralized at a regional data centre or Multi-access Edge Computing layer. For a CU that is located closer to the user, at a central office for instance, virtualization is feasible as well, but not necessarily a cloud-native implementation of virtualization, as it would typically be located outside of a data centre and serve a comparably small area of the 5G network.
The only part of a 5G network that is not suited for any form of virtualization is the Radio Unit (RU). The RU is a network element located at the cell site, typically on a rooftop, a telecommunications tower or at the street level on a pole or wall. It is the RU that takes care of the radio-frequency air interface between the rest of the network and the User Equipment (UE).
Figure 6: another take on CSP and RAN/5G virtualization & routing.
Figure 6 above depicts part of a typical CSP fixed-mobile convergent network. It highlights the routing aspects of that network, showing where 6WIND’s virtualized network functions can be deployed, and the mode of that deployment.
At the far edge of the network, on the left in Figure 6, we’re squarely in the fixed (fibre, copper, GPON) and wireless access domain (dotted red box). Most deployments in this access part of the network will take place on a single instance of a COTS server. In some cases, the place of that COTS server is taken by a somewhat optimized and less generic white-box device.
A white box device can for instance be deployed to facilitate a very-low-cost universal CPE (uCPE) solution (6WIND’s vCPE). A very different kind of white box solution can be desirable to address the specialized requirements of a VNF uniting a 5G DU and Cell Site Router (6WIND’s vCSR) functions in a single virtualized network element. Such a 5G DU / CSR has to be capable of supporting features like frequency (Synchronous Ethernet) and phase synchronization (IEEE1588v2 Precision Time Protocol / Boundary Clock (BC)) plus for example accelerator cards for 5G forward error correction acceleration.
On the right-hand side in Figure 6, we can see virtualized routing functions that are typically located at the CSP provider edge network or in the core network. Those virtualized functions are amenable to deployment on a private or public cloud.
Virtualization in a telecommunications network is a means to an end: accelerating network innovation while at the same time paring down Total Cost of Ownership (TCO). Virtualized Network Functions are implemented entirely in software and deployed on general-purpose COTS servers, in public or private clouds as a Cloud Native VNF or CNF or in some instances on more specialized white box servers. We may conclude that network function virtualization of telecommunications networks is real and happening as we speak. We’re also witnessing a cautious cloud-native VNF uptake.
Most functions of a 5G network, or any telco network for that matter, can be virtualized, with the notable exception being the Radio Unit functions in the 5G RAN. Some parts of a 5G network can be deployed in a cloud-native environment, primarily the core network functions and other centralized functions. The Central Unit part of the 5G RAN can be deployed as a VNF, and in some instances also as a cloud-native function. The Distributed Unit part of the 5G RAN is amenable to VNF deployment, but not as a cloud-native function (it can still run as a lightweight CNF though!) because it’s located at the far edge of the network.
Virtualized routing can be deployed right across the network, stretching from the far edge to the core of the network. Most VNFs can be deployed on COTS servers and in public or private clouds. Some more specialized VNFs at the network far edge may still require deployment on more specialized white label servers, which represents a compromise between fully disaggregated HW and SW and a monolithic vendor-specific network functions.