5G NF API Version Selection via Bootstrapping

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

In 5G networks, NF service consumers face challenges in handling service requests due to non-backward-compatible (NBC) API versions among NF service producers, especially in indirect communication models like Model D, where the failure reason for error responses is not clear, hindering retry mechanisms.

Innovation Solution

The method involves a first NF node selecting an appropriate API version for a service request based on bootstrapping information obtained from a Network Repository Function (NRF), constructing the request with the selected API version, and transmitting it to a Service Communication Proxy (SCP). If an error response is received, the NF node can reselect a different API version and retry the request.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Ease of operation

If indirect communication with delegated discovery (Model D) is used, then NF service consumers can simplify their discovery process, but they lose visibility into failure reasons and cannot perform effective retry mechanisms

Engineering Contradiction:

Improvediscovery process simplicityVSAvoidservice request reliability

Core Design Contradiction:

Ease of operationVSReliability

Solution Approach 1:

The patent implements a feedback mechanism where the SCP includes error reason information in error responses to NF service consumers. When an NF service consumer receives an error response, the SCP provides visibility into the failure reason (such as API version compatibility issues), enabling the consumer to make informed retry decisions. This resolves the contradiction by maintaining the simplicity of Model D while adding the necessary feedback for reliability.

Inventive Principle:

Principle #23Feedback

Solution Approach 2:

The SCP acts as an intermediary between the NF service consumer and the NF service producer. It receives service requests from the consumer, performs discovery and selection of appropriate producers, and returns both success responses and detailed error information. This intermediary role allows the consumer to remain simple while the SCP handles the complexity of discovery and provides actionable error feedback.

Inventive Principle:

Principle #24Intermediary (Mediator)

2Measurement precision

If NF service consumers include specific API version in service requests, then they can target specific producer versions, but they risk request rejection if the producer does not support that version

Engineering Contradiction:

ImproveAPI version matching precisionVSAvoidservice request success rate

Core Design Contradiction:

Measurement precisionVSReliability

Solution Approach 1:

The patent applies preliminary action by having the NF service consumer obtain bootstrapping information from the NRF before making service requests. This bootstrapping information includes the current API version supported by the producer. The consumer uses this pre-acquired version information to construct requests with the correct API version, avoiding rejection while maintaining precise version matching.

Inventive Principle:

Principle #10Preliminary action

Solution Approach 2:

The SCP provides feedback about API version compatibility in error responses. When a request with an unsupported API version is made, the error response includes information about the actual version supported by the producer, allowing the consumer to adjust its version selection and retry the request successfully.

Inventive Principle:

Principle #23Feedback

3Adaptability or versatility

If NF service producers deploy multiple non-backward-compatible API versions, then they can support evolving service requirements, but NF service consumers cannot determine which version to use

Engineering Contradiction:

ImproveAPI version flexibilityVSAvoidversion selection simplicity

Core Design Contradiction:

Adaptability or versatilityVSEase of operation

Solution Approach 1:

The patent implements self-service by having the NF service consumer automatically obtain the correct API version information through bootstrapping with the NRF. The consumer does not need to manually determine which version to use; instead, it queries the NRF for the current supported version and uses that information automatically. This maintains ease of operation while supporting multiple producer versions.

Inventive Principle:

Principle #25Self-service

Solution Approach 2:

The bootstrapping mechanism serves multiple functions: it provides API version information, enables version-matched request construction, and supports retry logic when version mismatches occur. This universal approach handles all version-related operations through a single standardized process, maintaining simplicity while supporting version flexibility.

Inventive Principle:

Principle #6Universality (Multi-functionality)

Data Source

PatentUS20250193286A1Service request processing

Publication Date: 2025.06.12 TELEFONAKTIEBOLAGET LM ERICSSON (PUBL)

AI summary

The present disclosure provides methods for processing a service request in a network comprising a set of Network Function (NF) nodes, and corresponding NF nodes. The method performed at a first NF node comprises selecting (S710) an Application Program Interface (API) version for the service based on information on API versions for the service obtained by using a bootstrapping service and stored in the first NF node; constructing (S720) a request for the service using the selected API version; and transmitting (S730) the request to a Service Communication Proxy (SCP). The present disclosure further discloses corresponding methods performed at an SCP and a Network Repository Function (NRF). The present disclosure further provides a corresponding computer readable medium.