Data Handler Association Logic for Low-Latency 5G Monitoring
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
The existing 5G communication networks face inefficiencies in monitoring data handling, particularly for ultra-reliable low latency communication (URLLC) applications, as current monitoring services in the management plane cannot meet the latency requirements for data collection between control and user planes, leading to unnecessary signaling and data transfer.
Innovation Solution
A data handler is introduced to manage monitoring data across network entities by obtaining data requests, generating association information, and determining if data is already available, thereby reducing redundant data collection and transfer through efficient data handling and processing.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Device complexity
If monitoring data is collected through the Management Plane (MP) for Control Plane (CP) and User Plane (UP) functions, then centralized monitoring service is provided, but data collection latency increases and cannot meet URLLC requirements
Solution Approach 1:
The patent segments the monitoring service by introducing separate monitoring functions in the Control Plane (NWDAF) and User Plane (AF), rather than relying solely on centralized Management Plane monitoring. This segmentation allows CP/UP functions to collect monitoring data locally through direct interactions, reducing latency for time-critical applications like URLLC while maintaining centralized oversight where needed.
Solution Approach 2:
The patent adds a new dimension to the monitoring architecture by enabling monitoring services at multiple planes (MP, CP, and UP) simultaneously. This multi-dimensional approach allows the system to select the appropriate monitoring path based on latency requirements, with CP/UP monitoring for low-latency needs and MP monitoring for centralized management needs.
2Device complexity
If monitoring data is collected via Management Plane NFs, then centralized control is maintained, but signaling overhead and data transfer volume increase
Solution Approach 1:
The patent implements preliminary action by having CP/UP functions collect and process monitoring data locally before needing to report to management functions. The NWDAF in CP and AF in UP maintain local monitoring capabilities, pre-collecting data that would otherwise need to be transmitted through multiple MP NFs, thereby reducing signaling overhead and data traffic volume.
Solution Approach 2:
The patent extracts the monitoring data collection function from the Management Plane and places it directly in the Control and User Planes. This extraction eliminates unnecessary intermediate data transfers through MP NFs, reducing the overall volume of monitoring data traffic while maintaining the ability to provide monitoring services.
3Device complexity
If monitoring service is provided solely in Management Plane, then standard 3GPP architecture is maintained, but URLLC latency requirements cannot be satisfied
Solution Approach 1:
The patent introduces dynamics into the monitoring service deployment by allowing the system to adaptively select between MP-based and CP/UP-based monitoring paths depending on the service requirements. For URLLC applications with strict latency requirements, the system dynamically uses local CP/UP monitoring; for other applications, MP monitoring is sufficient. This dynamic approach ensures reliability for time-critical services while maintaining architectural flexibility.
Data Source
Figure 1
Figure 2
Figure 3A
AI summary
The disclosure relates to a data handler being configured to handle monitoring data among network entities, wherein the data handler is configured to: obtain a first data request from a first network entity, the first data request comprising a first data identifier, the first data identifier relating to monitoring data; obtain one or more second data identifier from one or more other network entities, wherein the one or more second data identifier is related to the monitoring data to be collected from one or more other network entities; generate association information based on the first data identifier and the one or more second data identifier; and determine, based on the association information, whether the monitoring data to be collected is already available at the data handler, or determine whether the monitoring data to be collected should be collected from the one or more other network entities by the data handler.