NRF Service Registration With Versioned Network Function Profiles

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

In 5G systems, the Network Repository Function (NRF) lacks the ability to identify specific UDR instances for service registration and discovery due to multiple UDRs handling different data sets, and there is no clear handling of service versions, vendor proprietary functionality, or service upgrades.

Innovation Solution

The NRF is enhanced to include vendor ID and service version information in the NF profile, allowing it to manage service versions, load balance, perform rollbacks, and notify consumers of new versions, while supporting vendor proprietary functionality.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Loss of information

If the NRF stores only basic service information without version details, then the service registration process is simple, but the system cannot identify specific UDR instances or handle service upgrades

Engineering Contradiction:
Improveservice version informationVSAvoidNRF profile structure
Core Design Contradiction:
Loss of informationVSDevice complexity

Solution Approach 1:

The patent implements a nested structure where the NF profile contains a nested service information structure, which in turn contains nested version information. This hierarchical nesting allows the NRF to store comprehensive service version details (service ID, version, vendor ID) without fundamentally changing the overall profile structure, thus resolving the contradiction between information completeness and structural simplicity.

Inventive Principle:
Principle #7Nested doll (Nesting)

Solution Approach 2:

The patent segments the NF profile into distinct components: basic service information, service version information, and vendor-specific information. This segmentation allows each component to be independently managed and accessed, enabling the system to retrieve specific version information without processing the entire profile, thereby balancing information retention with operational efficiency.

Inventive Principle:
Principle #1Segmentation

2Adaptability or versatility

If the NRF supports multiple service versions and vendor-specific functionality, then service flexibility increases, but service discovery and registration become more complex

Engineering Contradiction:
Improveservice version compatibilityVSAvoidservice management mechanism
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent applies local quality by making the version information and vendor-specific information optional and location-specific within the NF profile. Different NFs can choose to include or exclude version information based on their specific needs, allowing the system to maintain high adaptability for NFs that require it while keeping the management mechanism simple for those that don't, thus resolving the contradiction between versatility and complexity.

Inventive Principle:
Principle #3Local quality

3Reliability

If the NRF performs load balancing and rollback operations, then service reliability improves, but the service management overhead increases

Engineering Contradiction:
Improveservice continuityVSAvoidservice management functionality
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The patent implements preliminary action by pre-storing multiple service version information and their corresponding NF instances in the NF profile before any failure occurs. This allows the NRF to perform load balancing and rollback operations by simply selecting from pre-validated service versions, eliminating the need for complex real-time decision-making and reducing management overhead while maintaining high service reliability.

Inventive Principle:
Principle #10Preliminary action

Data Source

PatentEP4102931B1Service registration in a communications network
Publication Date: 2025.09.10 TELEFONAKTIEBOLAGET LM ERICSSON (PUBL)
  • EP4102931B1 patent drawingFigure 1~2
  • EP4102931B1 patent drawingFigure 3~4
  • EP4102931B1 patent drawingFigure 5~6

AI summary

In an example aspect, a method for service registration in a communications network is provided. The method comprises receiving a service registration request, the request identifying a network function to provide a service, a type of the service, and a version of the service, and storing information in a repository, the information identifying the network function, the type of the service and the version of the service.