Universal Mobile Telecommunications System (UMTS); LTE; 5G; Telecommunication management; Generic Network Resource Model (NRM) Integration Reference Point (IRP); Solution Set (SS) definitions (3GPP TS 28.623 version 18.14.0 Release 18)
1Key Takeaways
This technical specification series defines a common Network Resource Model (NRM), also referred to as the Management Information Model (MIM), which includes definitions of Information Object Classes (IOCs) and Managed Object Classes (MOCs). This document specifies the solution set definition for the common NRM IRP. Th…
2Expert Interpretation
This article provides an in-depth analysis of the 3GPP TS 28.623 V18.14.0 standard, focusing on the solution set SS definition of the Integrated Reference Point (IRP) in the Common Network Resource Model (NRM). It covers two major technical implementation schemes: OpenAPI and YANG, analyzing their key roles in 5G, LTE, and UMTS network management, and providing implementation suggestions and standardization evolution paths.
Standard Overview and Technical Evolution Background
ETSI TS 128 623 V18.14.0 (2026-04) is a core component of the 3GPP Release 18 series of technical specifications, belonging to the telecommunications management standards family. This standard specifically defines the **Solution Set (SS) of the **General Network Resource Model (NRM) Integration Reference Point (IRP)**, providing a technical implementation framework for the unified management of multiple generations of mobile communication networks (UMTS, LTE, 5G). As a key part of the 28.62x series of standards, this specification, together with TS 28.621 (Requirements) and TS 28.622 (Information Services (IS),** constitutes a complete NRM IRP specification system.
From a technical evolution perspective, TS 28.623 has undergone a major transformation from the traditional IRP-based framework to a **Service-Oriented Management Architecture (SBMA)**.
Release 14 and earlier versions primarily served traditional IRP deployment scenarios, while Release 15 fully embraces a service-based architecture paradigm. This version (V18.14.0) is explicitly applicable to SBMA deployment scenarios defined by TS 28.533, marking 3GPP network management's formal entry into a new era of cloud-native and microservice-based architecture. This evolution not only reflects profound changes in network architecture but also embodies the inevitable trend of management interface standardization towards openness and API-based architecture. Core Architecture: Dual Technical Implementations of Solution Sets The core value of the TS 28.623 standard lies in defining two mainstream and complementary solution set technology implementations for general NRM IRP: the OpenAPI solution based on RESTful HTTP and the YANG solution based on NETCONF. This dual technical path design considers both the widespread adoption of modern Web service technologies and the continuity of traditional network device management protocols, providing flexible choices for different application scenarios and device types.
Detailed Explanation of the OpenAPI Solution Suite
The OpenAPI Solution Suite uses YAML format to define management interfaces and strictly follows the mapping rules defined in 3GPP TS 32.160. This solution transforms the Information Services (IS) model defined in TS 28.622 into the standard OpenAPI 3.0 specification, achieving a precise mapping from the NRM object model to the RESTful API.In-depth Analysis of the YANG Solution Set
The YANG solution set provides standardized data model definitions for network management based on the NETCONF protocol.
The standard lists 18 core YANG module files, covering comprehensive modeling from general type definitions to specific management functions:| YANG module categories | Core file examples | Main functions |
|---|---|---|
| Basic type module | _3gpp-common-yang-types.yang | Defines general data types such as DistinguishedName and AttributeValuePair |
| Core managed object module | _3gpp-common-managed-element.yang | Defines ManagedElement and its containment relationships |
| Management function module | _3gpp-common-trace.yang | Defines trace control related objects and attributes |
| Service Support Module | _3gpp-common-mnsregistry.yang | Supports MnS registration and discovery functions |
The standard particularly emphasizes the application of the YANG mounting mechanism, following the IETF RFC 8528 specification. When a ManagedElement object is contained under a SubNetwork or MeContext, the corresponding YANG module needs to be mounted at the specified mount point. This mechanism supports the dynamic expansion and flexible combination of network resource hierarchies, and is a key technical support for the management of new network architectures such as 5G network slicing.
Key Technical Features and Innovations
Standardized Application of Jex Expressions
A significant innovation in Release 18 is the introduction of JSON expression Jex as a standardized filtering and selection language. According to the TS 32.161 specification, Jex provides three configuration profiles:
- Basic Profile: Used for the dataNodeSelector property, supporting basic path selection and node location
- Advanced Profile: Extends the functionality of the basic profile, supporting more complex expressions
- Conditional Profile: Specifically used for the notificationFilter property, supporting Boolean conditional expressions
This standardized design replaces the traditional XPath 1.0, better adapting to the needs of JSON data format and modern API architecture.
For example, in the NtfSubscriptionControl object, the dataNodeSelector property uses Jex expressions to precisely specify the monitoring scope, while the notificationFilter property uses Jex conditional expressions to define notification filtering rules.Condition Monitoring and Automated Triggering Mechanism
The ConditionMonitor object defined in the standard represents a significant advancement in network management automation. Through Jex conditional expressions, ConditionMonitor can monitor changes in network status in real time and trigger corresponding management actions when specific conditions are met. The example in Appendix E.1 clearly demonstrates the application of this mechanism:
Application Case: When a specific network element (DN1) generates an alarm, a performance data collection task is automatically started. ConditionMonitor monitors alarm records in the AlarmList, and once an alarm with objectInstance "DN1" is detected, the conditional expression evaluates to true. The PerfMetricJob associated through the conditionMonitorRef property is then triggered, starting the collection of performance metrics for that network element.
This mechanism enables intelligent linkage between alarms and performance monitoring, greatly improving the automation level of network operation and maintenance.Standardized Mapping of Common Data Types
To ensure consistency between different technical implementations, the standard clearly specifies the mapping relationship between Stage-2 type names and YANG types in Table E.2.2-1.
This mapping takes into account existing definitions from external organizations (such as the IETF) and compatibility with existing YANG modules:| Stage-2 type name | YANG type | Definition source | Description |
|---|---|---|---|
| FullTime | yang:time-with-zone-offset | ietf-yang-types.yang | Full time with time zone offset |
| Float | Decimal64 | RFC 7950 | Decimal floating-point number |
| DnList | types3gpp:DistinguishedName | _3gpp-common-yang-types.yang | List of Distinguished Names |
| Uri | inet:uri | ietf-inet-types.yang | Uniform Resource Identifier |
Implementation Recommendations and Best Practices
MnS Producer Implementation Strategy
Based on standard-based implementation, MnS producers should follow these key principles:
- Schema Customization: Generate producer-specific OpenAPI or YANG definitions based on the actual supported NRM attributes, and remove all unsupported objects, attributes, and containment relationships.
- Explicit Root Object: Explicitly specify the supported root object classes (SubNetwork or ManagedElement), removing other options in the schema definition.
- Standardized Schema Access: Place producer-specific schemas under the `
/schemas` path for easy management consumer discovery and use. - YANG Module Discovery: List of YANG modules supported via the `ietf-yang-library` module (RFC 8525) or the `ietf-netconf-monitoring` module (RFC 6022).
Management Consumer Integration Guidelines
Management consumers should focus on the following during integration:
- Dynamic Schema Discovery: Obtain specific schema definitions from the MnS producer first, rather than relying on the standardized complete definition.
- Jex Expression Processing: Implement a Jex expression parsing and execution engine, supporting basic, advanced, and conditional profiles.
- Mount Awareness: Correctly handle module mount relationships in YANG-based interactions, and understand the different inclusion methods of ManagedElement under SubNetwork or MeContext
- Error Handling: Follow the error response codes defined in the standard, especially error scenarios related to Jex expressions
Multi-Technology Stack Collaborative Deployment
In a real network environment, the OpenAPI and YANG solution sets may coexist.
The following collaborative strategies are recommended:| Application Scenarios | Recommended Technical Solutions | Advantages | Precautions |
|---|---|---|---|
| Cloud-Native Network Function Management | OpenAPI (RESTful HTTP) | Naturally compatible with microservice architecture, easy to integrate with CI/CD toolchains | API version compatibility management needs to be ensured |
| Traditional Network Device Configuration | YANG (NETCONF) | Supports advanced functions such as transaction configuration and rollback, compatible with traditional network management systems | Compatibility issues arising from the evolution of the YANG model need to be addressed |
| Hybrid Network Environment | Dual-stack support | Maximized compatibility and flexibility | Two sets of interface implementations need to be maintained to ensure behavioral consistency |
Standard Evolution and Future Outlook
By analyzing the standard's change history (Appendix F), the technical evolution trajectory of TS 28.623 can be clearly seen:
- Release 16: Introduced JSON definition and YANG solution, starting to support new management functions
- Release 17: Enhanced support for MnS discovery, file management, management data collection, and other functions
- Release 18: Fully adopted Jex expressions, removed traditional CORBA and XML solutions, and strengthened support for advanced 5G functions
Looking to the future, with the deepening development of network automation and intelligence, TS The TS 28.623 standard is expected to continue evolving in the following directions: AI/ML Integration: Further enhancing support for the management of artificial intelligence and machine learning models. Intent-Driven Networking: Deepening the modeling and management capabilities of intent-driven network NRM. Edge Computing Management: Expanding the management interface for edge network resources and services. Security Enhancement: Strengthening security control and auditing capabilities for management interfaces. As a key component of the 3GPP network management standard system, the successful implementation of TS 28.623 will lay a solid technical foundation for the automated and intelligent management of networks in the 5G-A and 6G eras. Through standardized solution set definitions, network devices and management systems from different vendors and with different technical architectures can achieve efficient interoperability, driving the entire industry towards a more open and intelligent direction.