Network Management Challenges in the New World of Open RAN

### Overview Presented at the Open Networking and Edge Summit by David Kinsey (AT&T) and Ting Liu (Ericsson), this session examines the network management architecture established by the O-RAN Alliance. The talk focuses on the Service Management and Orchestration (SMO) framework, contrasting traditional physical RAN management with disaggregated, cloud-native Open RAN architectures. Both speakers examine the core operational and engineering hurdles of this transition: David Kinsey offers a mobile network operator's perspective on integration, data handling, and legacy support, while Ting Liu analyzes the challenges from an OSS vendor's perspective regarding multi-vendor software, diverse cloud footprints, and operator-specific environments.

### Key Topics - **Evolution from Legacy RAN to O-RAN**: Traditional RAN management relies on monolithic element management systems (EMS) and SON systems separated across near-real-time and non-real-time controls. O-RAN disaggregates physical elements into virtualized O-RU, O-DU, and O-CU components, decoupling management platforms (SMO and RIC) from applications (rApps and xApps). - **Standardized Interfaces**: Key open interfaces in the O-RAN management plane include O1 (RAN FCAPS), O2 (cloud orchestration and management), A1 (policy guidance and enrichment data to the Near-RT RIC), R1 (standard runtime API for rApps inside the Non-RT RIC), and the fronthaul M-plane (FCAPS management of O-RUs in hybrid mode). - **Standardization vs. Open Source Collaboration**: While O-RAN Alliance defines open interfaces from a bottom-up RAN perspective, open source communities such as ONAP and OSM address top-down end-to-end service orchestration, analytics, and service assurance, collaborating with the O-RAN Software Community (OSC).

### Technical Details - **Operator Architecture (AT&T Perspective)**: AT&T envisions the SMO in three layers: a network integration layer (interfacing with network and cloud via O1 and O2 for telemetry collection and conflict remediation), an application layer (hosting refactored EMS microservices and rApps), and a common integration/platform layer. This platform layer removes data ownership from siloed applications, enforcing ubiquitous, data-centric access while natively supporting AI/ML training, testing, and telemetry correlation. - **Operator Deployment Challenges**: Managing brownfield environments requires auto-discovering existing clouds, physical network functions (PNFs), and cloud-native network functions (CNFs)—a task complicated because CNF onboarding metadata is retained in the SMO rather than stored in the cloud. Accommodating legacy EMS capabilities that do not fit the R1 interface remains an ongoing interface gap under internal evaluation. - **OSS Vendor Architecture & CI/CD**: Vendors must decompose monolithic EMS and cSON tools into microservices, verify rApps via marketplaces against Non-RT RIC APIs, and deploy cloud-native orchestrators to manage life-cycle updates for both network functions and management apps across private clouds and hyperscalers. - **Deployment Topology Flexibility**: Depending on operator size, SMO deployment may range from single instances to multi-tier hierarchical models. In a three-tiered model, central nodes manage onboarding and end-to-end services, regional nodes handle distribution and regional analytics, and local nodes host Non-RT RICs with localized AI/ML training for low-latency control loops.

### Takeaways Successful adoption of Open RAN network management requires SMO implementations to balance strict standards compliance with deployment flexibility. For operators like AT&T, success hinges on extensibility via R1, unified data architectures, AI/ML enablement, and brownfield migration. For vendors like Ericsson, commercial viability depends on supporting multi-vendor rApps and network functions, multi-cloud compatibility, single-pane-of-glass user experiences for legacy adaptation, and flexible integration services tailored to existing operator BSS/OSS environments.