5G Deep Service Path Discovery with SDN and Kubernetes APIs

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

Current technologies face challenges in providing deep service path discovery for cloud native functions in 5G networks, particularly due to the dynamic nature of containerized network functions and the need for real-time visibility into service paths for troubleshooting and performance management.

Innovation Solution

The implementation of a software-defined networking (SDN) controller that integrates with the 5G network architecture, utilizing network repository function (NRF) data and Kubernetes APIs to discover and manage network functions, service paths, and containerized network functions, enabling deep service path discovery and real-time configuration management.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Measurement precision

If traditional network monitoring methods are used in 5G networks with containerized network functions, then the system architecture remains simple, but deep service path discovery and real-time visibility into service paths become impossible

Engineering Contradiction:

Improveservice path discovery capabilityVSAvoidsystem architecture complexity

Core Design Contradiction:

Measurement precisionVSDevice complexity

Solution Approach 1:

The patent introduces an SDN controller as an intermediary component that sits between the containerized network functions and the monitoring system. This controller provides northbound APIs for high-level service path discovery and southbound APIs for detailed container-level monitoring, enabling deep service path visibility without requiring direct integration with every network function container.

Inventive Principle:

Principle #24Intermediary (Mediator)

Solution Approach 2:

The monitoring system is segmented into multiple layers: the SDN controller handles overall service path discovery, while individual container agents handle specific container-level metrics. This segmentation allows the system to achieve deep monitoring capability by dividing the complex task across multiple specialized components rather than requiring a monolithic monitoring solution.

Inventive Principle:

Principle #1Segmentation

2Adaptability or versatility

If the system integrates with dynamic containerized network functions using Kubernetes APIs, then real-time service path discovery is enabled, but the complexity of managing dynamic configurations increases

Engineering Contradiction:

Improvedynamic service path discoveryVSAvoidconfiguration management complexity

Core Design Contradiction:

Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The system implements feedback mechanisms where the SDN controller continuously monitors service path changes through Kubernetes APIs and automatically updates its internal service path models. Container agents provide feedback on their status and configuration changes, enabling the system to adapt to dynamic containerized network functions without manual reconfiguration.

Inventive Principle:

Principle #23Feedback

Solution Approach 2:

The monitoring system performs self-service by automatically discovering new containers through Kubernetes events and dynamically adjusting its monitoring scope. When containers are created or destroyed, the system autonomously updates its service path discovery capabilities without requiring external intervention, reducing the operational complexity of managing dynamic configurations.

Inventive Principle:

Principle #25Self-service

3Reliability

If comprehensive monitoring of all containerized network functions is implemented, then troubleshooting capability is enhanced, but the amount of data to be processed and analyzed increases significantly

Engineering Contradiction:

Improvetroubleshooting capabilityVSAvoidmonitoring data volume

Core Design Contradiction:

ReliabilityVSQuantity of substance

Solution Approach 1:

The monitoring system applies local quality by having container agents collect and pre-process metrics locally at each container, filtering out irrelevant data before transmission to the central SDN controller. This approach maintains comprehensive monitoring capability while reducing the overall data volume by ensuring each component monitors only its relevant service path segments.

Inventive Principle:

Principle #3Local quality

Solution Approach 2:

The system extracts only the essential service path discovery data from the comprehensive container monitoring data stream. The SDN controller selectively collects high-level service path information from multiple container agents, separating the critical troubleshooting data from the voluminous operational metrics, thereby reducing analysis complexity while maintaining reliability.

Inventive Principle:

Principle #2Taking out (Extraction)

Data Source

PatentUS12349043B2Facilitation of deep service path discovery for 5G or other next generation network

Publication Date: 2025.07.01 AT&T INTELLECTUAL PROPERTY I L P

AI summary

A software defined network (SDN) can add network repository functions (NRF) into a configurations database to enable NF discovery. The SDN can subscribe to NRF notifications to receive new cloud native functions (CNF), registrations, or any other update to the CNF status in 5G system. In addition to listening to NRF notifications, the SDN can implement CNF pooling processes to periodically retrieve CNF from an NRF repository and stay in sync with 5G systems. Thus, a deep service path discovery can be developed from network service configurations and container call flows to enable an accurate alarm correlation and troubleshooting for the operations. This service path deep discovery can be designed and implemented as a standalone system or in an SDN framework with integration of a container management framework such as K8 kubernetes.