SBA Notification Routing Through SCPs With API Version Matching

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

Existing 3GPP eSBA systems face challenges in ensuring API version matching between NF Service Producers and Consumers for notifications, and in distinguishing notification requests from other service requests during indirect communication.

Innovation Solution

The introduction of the 3gpp-Sbi-Callback header is extended to include an 'apiversion' parameter for notification and callback requests, enabling the Service Communication Proxy (SCP) to select appropriate NF Service Consumers supporting the correct API version and differentiate between notification and other service requests.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If indirect communication is implemented in eSBA systems, then service requests can be routed through SCPs, but notification requests cannot be properly distinguished from other service requests

Engineering Contradiction:

Improveindirect communication supportVSAvoidnotification request identification

Core Design Contradiction:

Adaptability or versatilityVSLoss of information

Solution Approach 1:

The notification indicator is added to the service request message before it is forwarded by the SCP. This preliminary action ensures that the notification request is properly identified throughout the indirect communication path, allowing the SCP to distinguish it from other service requests and apply appropriate handling.

Inventive Principle:

Principle #10Preliminary action

Solution Approach 2:

The SCP acts as an intermediary that receives service requests, checks for the notification indicator, and forwards requests to appropriate NF service consumers. The SCP uses the notification indicator to determine whether to apply notification-specific security and authorization treatments versus standard service request handling.

Inventive Principle:

Principle #24Intermediary (Mediator)

2Reliability

If API version matching is required between NF Service Producers and Consumers, then compatibility is ensured, but the complexity of notification handling increases

Engineering Contradiction:

ImproveAPI version compatibilityVSAvoidnotification handling complexity

Core Design Contradiction:

ReliabilityVSDevice complexity

Solution Approach 1:

The API version information is included in the notification indicator or associated metadata before the service request is forwarded. This preliminary inclusion of version information allows NF service consumers to verify compatibility before processing, reducing the need for complex runtime version negotiation and matching mechanisms.

Inventive Principle:

Principle #10Preliminary action

Solution Approach 2:

The system implements feedback mechanisms where NF service consumers can indicate their supported API versions in response to service requests. This feedback allows the SCP and NF service producers to verify compatibility and route notifications appropriately, ensuring reliable version matching without excessive complexity.

Inventive Principle:

Principle #23Feedback

Data Source

PatentEP3863272B1Notifications sent with indirect communication in sba

Publication Date: 2025.08.27 NOKIA TECHNOLOGIES OY

Figure 1
Figure 2
Figure 3

AI summary

It is provided a method, comprising monitoring if a received request comprises a notification indication, wherein the notification indication indicates that the request is one of a callback request and a notification request; handling the request as a service request if the request does not comprise the notification indication; handling the request as a notification or callback request if the request comprises the notification indication, wherein the handling as a service request is different from the handling as a notification or callback request.