Kafka Header Schema Tags for Scalable PM/FM Data Decoding

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

In 5G Open-Radio Access Networks, the Northbound Management System faces challenges in decoding Performance Management (PM) and Fault Management (FM) data due to varying schema versions across different gNB Network Functions, requiring complex logic and multiple Kafka clusters, which is not scalable.

Innovation Solution

Implementing Kafka header-based schema version management by embedding Encoding Type or Schema Version Tags in the message header, allowing the Northbound Management System to decode data using corresponding decoders based on these tags, independent of gNB NF software versions.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If multiple Kafka clusters or topics are created to support different gNB NF software versions, then the Northbound Management System can decode PM and FM data from different versions, but the system complexity and infrastructure requirements increase significantly

Engineering Contradiction:

Improvesupport for multiple gNB NF software versionsVSAvoidKafka cluster and topic management complexity

Core Design Contradiction:

Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent introduces a schema version identifier as an intermediary element embedded in the Kafka message header. This identifier acts as a mediator that carries version information from the producer to the consumer, enabling the Northbound Management System to automatically select the appropriate decoder without requiring separate Kafka clusters. The schema version identifier bridges the gap between different software versions while maintaining a unified message broker infrastructure.

Inventive Principle:

Principle #24Intermediary (Mediator)

Solution Approach 2:

The patent makes the Kafka message header universal by including a schema version identifier that can represent multiple software versions within a single message structure. This allows a single Kafka cluster to handle messages from various gNB NF versions, eliminating the need for version-specific clusters while maintaining the ability to decode data from any supported version through the version identifier in the header.

Inventive Principle:

Principle #6Universality (Multi-functionality)

2Loss of information

If gNB NF software version mapping logic is implemented in the Northbound Management System, then schema version determination is possible, but the internal API complexity and inventory management burden increase

Engineering Contradiction:

Improveschema version identification accuracyVSAvoidinternal API and inventory management complexity

Core Design Contradiction:

Loss of informationVSDevice complexity

Solution Approach 1:

The patent implements self-service by embedding the schema version identifier directly in the Kafka message header at the source. Instead of requiring the Northbound Management System to query inventory databases or use complex mapping APIs to determine the schema version, the message itself carries the version information. This eliminates the need for external lookup mechanisms and reduces the complexity of inventory management while ensuring accurate schema version identification.

Inventive Principle:

Principle #25Self-service

3Reliability

If separate Kafka clusters are used for different PM/FM encoding types, then data from different encoding versions can be consumed appropriately, but the infrastructure cost and operational overhead increase

Engineering Contradiction:

Improvedata decoding reliabilityVSAvoidKafka cluster quantity

Core Design Contradiction:

ReliabilityVSQuantity of substance

Solution Approach 1:

The patent merges multiple version-specific Kafka clusters into a single unified cluster by introducing a schema version identifier in the message header. This allows all encoding types and versions to coexist in one cluster, with the version identifier enabling the consumer to route messages to the appropriate decoding logic. This consolidation reduces infrastructure costs and operational overhead while maintaining reliable decoding through version-aware message processing.

Inventive Principle:

Principle #5Merging (Combining)

Data Source

PatentUS20250370840A1Kafka header based schema management in encoding and decoding performance management (PM)/fault management (FM) data

Publication Date: 2025.12.04 RAKUTEN SYMPHONY INC

AI summary

A Kafka header based schema version management in encoding and decoding Performance Management (PM)/Fault Management (FM) data. A microservice prepares one or more Encoding Type or Schema Version Tags based on one or more Encoding Type or Schema Source Files used by the microservice. The microservice encodes data using the Schema Version identified by the one or more Encoding Type or Schema Version Tags to produce encoded data, embeds the one or more Encoding Type or Schema Version Tags in a Header of a Kafka Message, and embeds the encoded data in the Message Body of the Kafka Message. The Microservices then sends the Kafka Message to a Northbound Management System for decoding based on the one or more Encoding Type or Schema Version Tags in the Header of the Kafka Message.