Home > Communication Service Provider Solutions > Enabling Telecom Transformation > RAN Pooling - The case for RAN pooling with Cloud/Virtualized RAN > OpEx TCO advantages of pooling
OpEx costs have a more pronounced impact on TCO since they are recurring.
C-RAN hardware upgrade costs would be lower compared to traditional D-RAN for the same reasons outlined above for hardware CapEx and installation costs.
Software upgrades would result in improved TCO for C-RAN with containerized NFs, since the containerized NFs can be unloaded, updated, reloaded, and restored to service using software API commands like other cloud-native software applications. This, combined with an automated Continuous Integration and Continuous Delivery (CI/CD) pipeline, greatly reduces engineering time and cost for software upgrades as compared to traditional integrated RAN monoliths. Cloud-native applications benefit from CI/CD, since it breaks the software development of complex systems into smaller, more manageable and loosely-coupled microservice components, which are integrated into the application with their own delivery pipelines. Software upgrade time and cost is reduced since individual containerized components (individual NFs, OAM components, and so on) can be upgraded as necessary through individual delivery pipelines. In contrast, even when changes occur in only a subsystem of the integrated traditional RAN system, the entire monolith must be rebuilt and redeployed.
Configuration wrapped with application in container images makes it easier and less costly, as compared to traditional D-RAN, to conduct consistent, automated configuration updates across all systems in a Centralized RAN pool. Using containers to deploy applications and services enables immutable infrastructure. When applications that are deployed as containers need updating, new container instances are spun up using the updated image. This is important for supporting complex network functions, as it simplifies the deployment by avoiding configuration drift. Containers also offer a simpler recovery mechanism that entails restoring an older container image [3], as compared to traditional D‑RAN software configuration changes, which involve a costly build, code, test, and restart of some or all systems. All of these factors reduce engineering hours, and hence support costs, for troubleshooting, remediation of problems for fault management, and ongoing performance tuning.
By virtue of the reduced server hardware and pooling of RAN NFs, C-RAN decreases energy consumption costs. BBU workloads can be shifted to other servers, and some servers can be switched off during low activity periods. RAN pooling also reduces cooling or air conditioning energy costs compared to traditional D-RAN. Compared with traditional RAN architecture, C-RAN can achieve 67–80% power savings (depending on the number of cells covered by one BBU), according to ZTE estimates [4]. This estimate is in line with China Mobile research claiming 71% power savings.
Cell site rental or lease costs are also lower for C-RAN than for traditional D-RAN, since C‑RAN has less physical BBU equipment to build and deploy at cell sites. Less equipment means reduced costs due to fewer truck rolls and cell site maintenance visits.