Vendor Perspectives: Comparing RNC Designs from Ericsson, Nokia, Huawei, and ZTE

While the 3GPP standards define the functional roles of a Radio Network Controller (RNC), they leave wide latitude for implementation. Over the last two decades, major equipment vendors have delivered radically different RNC platforms, each with unique architectures, management interfaces, upgrade paths, and integration challenges.

For operators managing multivendor networks—or planning RNC retirement or virtualisation—understanding these differences is vital. Vendor design decisions affect everything from operational complexity to shutdown sequencing, staffing, and financial exposure.

This blog examines how Ericsson, Nokia, Huawei, and ZTE approached RNC development, and what operators need to know to navigate these platforms in 2025.

1. Ericsson RNC: A Modular, High-Resilience Design

Ericsson’s RNC platform was part of its RBS (Radio Base Station) portfolio and tightly integrated with its core network and transmission systems. Key features include:

Architecture Highlights

• Modular chassis-based design with distributed processing

• Separation of control and user planes

• High-availability architecture with 1+1 redundancy

• Support for multivendor Node Bs (under certain interoperability configurations)

Management and Operations

• Managed via OSS-RC (later ENM)

• Strong alignment with Ericsson’s IP transport layer tools

• Automation and scripting via Ericsson CLI and O&M frameworks

Strengths

• Highly scalable for large national deployments

• Well-documented migration paths to vRNC solutions

• Broad operator community for support and shared best practices

Challenges

• Complex integration with non-Ericsson Node Bs

• Licensing models tied closely to hardware slots and throughput tiers

• Hardware obsolescence in some RNC chassis generations

2. Nokia RNC: Compact, Efficient, and Standards-Driven

Nokia’s RNC design (including legacy Siemens networks later merged under Nokia) emphasised efficiency and standardisation. It offered:

Architecture Highlights

• Centralised processing in Flexi WCDMA and NetAct environments

• Integration-ready with Nokia’s Mobile Switching Center (MSC-S) and Packet Core

• Variants for macro and micro cell environments

Management and Operations

• Configuration and monitoring via NetAct OSS suite

• CLI tools aligned with wider Nokia core network stack

• Focus on network self-healing and real-time optimisation features

Strengths

• Strong WCDMA performance in dense urban deployments

• Efficient power and space footprint

• Well-aligned with Nokia’s multi-RAT roadmap (3G to LTE/5G)

Challenges

• Siemens-era platforms require different tooling and migration steps

• Limited flexibility in mixed vendor environments

• Complexity in matching NetAct versions across technologies

3. Huawei RNC: Highly Integrated, Feature-Rich, Vendor-Locked

Huawei’s RNCs were aggressively deployed across Asia, Africa, and Latin America, often bundled with its Node Bs and Core Network offerings. Huawei prioritised tight integration and proprietary enhancements.

Architecture Highlights

• Single-rack or blade-based RNC configurations

• Enhanced soft handover support and capacity optimisation

• Built-in features for self-optimising networks (SON)

Management and Operations

• Managed via Huawei U2000 or U2020 OSS platforms

• Deep integration with Huawei EPC, MSC, and transmission systems

• Web-based and CLI options for configuration

Strengths

• High traffic throughput and user density performance

• Lower hardware cost in large deployments

• Widely deployed in developing markets with full Huawei stacks

Challenges

• Vendor lock-in across hardware, software, and management layers

• Limited interoperability with other RNC or Node B vendors

• Regulatory scrutiny in some jurisdictions affecting long-term support

4. ZTE RNC: Pragmatic and Scalable in Cost-Sensitive Markets

ZTE positioned its RNC products as cost-effective alternatives with high scalability and straightforward deployment in emerging markets.

Architecture Highlights

• Modular slot-based architecture

• Optimised for rural and semi-urban coverage

• Hybrid software features supporting WCDMA and LTE fallback

Management and Operations

• Managed via ZSmart or NetNumen U31/N31 OSS systems

• XML-based configuration scripting

• Focus on batch operations and multi-node management

Strengths

• Price-performance ratio for mass rollout

• Quick install and commissioning cycle

• Compatible with low-cost Node B deployments

Challenges

• Limited vendor ecosystem and integration toolkits

• Less documentation in non-Chinese markets

• Perceived reliability gaps in high-density scenarios

Cross-Vendor Challenges in RNC Operations

1. Integration Across Node Bs

Multivendor networks often suffer from:

• Incomplete support for soft handovers

• Non-standard Iub interface implementations

• Diverging QoS management strategies

2. Management System Fragmentation

Operators managing RNCs from multiple vendors must:

• Operate multiple OSS platforms in parallel

• Train staff on different CLI syntaxes and fault models

• Reconcile conflicting performance KPIs

3. Virtualisation Readiness

Some vendors (notably Nokia and Ericsson) offer clear vRNC migration paths, while others require full reengineering or third-party wrappers to enable cloud deployment.

Best Practices for Operators in Multivendor RNC Environments

• Audit and inventory all live RNCs by vendor, version, and support status

• Use interoperability testing labs to verify cross-vendor handover and KPI alignment

• Consolidate OSS views via northbound API integration or umbrella management platforms

• Prioritise vendors offering active support for virtualisation or retirement

• Factor vendor exit risk into shutdown or migration strategies

Strategic Considerations for Leadership Teams

Boards and CTOs managing legacy estates should ask:

• Are we exposed to unsupported or end-of-life RNC platforms?

• Can we consolidate management across vendors to reduce complexity?

• What is our plan for vendor-driven vRNC migration?

• Are we managing cybersecurity uniformly across all RNC types?

• How do multivendor constraints affect our 3G sunset timelines?

These questions go beyond technology—they influence cost structure, staffing, regulatory engagement, and service continuity.

Conclusion: Know Your RNC Landscape Before You Act

While the functions of the RNC are defined by standards, the way each vendor implemented those functions varies considerably. From architecture to management systems, from lifecycle support to migration readiness, these differences can shape the success or failure of network transitions.

For operators planning to virtualise, consolidate, or retire their 3G assets, vendor-specific knowledge is power. The smart play is not just to count how many RNCs you have—but to know what kind, where, and how they’re woven into the fabric of your network.