Default Notification Subscription With Service-Specific API Mapping

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

In 3GPP Service Based Architecture, default notification subscriptions lack effective API version control and feature negotiation between network function (NF) producers and consumers, particularly when notifications can be generated by multiple services with differing API versions, leading to unclear identification of supported versions and features.

Innovation Solution

Implement a method where network nodes register default notification subscriptions with service-specific information, including API versions and features, enabling precise matching and composition of notifications based on supported capabilities.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Ease of operation

If default notification subscription is used without explicit subscription creation, then subscription setup is simplified and automated, but API version control and feature negotiation become unclear and unreliable

Engineering Contradiction:
Improvesubscription setupVSAvoidAPI version control
Core Design Contradiction:
Ease of operationVSReliability

Solution Approach 1:

The NF consumer pre-registers its supported API versions and features in the NRF before receiving notifications. This preliminary registration enables the NF producer to automatically compose notifications with the correct API version and features without needing explicit subscription creation or real-time negotiation, thus maintaining reliability while simplifying operation.

Inventive Principle:
Principle #10Preliminary action

2Device complexity

If a single default notification subscription is used for multiple services, then subscription management is simplified, but it becomes unclear which API version and features should be used when multiple services generate the same notification type

Engineering Contradiction:
Improvesubscription managementVSAvoidservice-specific API version information
Core Design Contradiction:
Device complexityVSLoss of information

Solution Approach 1:

The patent segments the default notification subscription into service-specific information within the NF profile. Each service has its own supported API versions and features recorded separately in the NRF, allowing the NF producer to identify and use the correct version information for each service that generates notifications, while still maintaining a unified subscription mechanism.

Inventive Principle:
Principle #1Segmentation

Data Source

PatentUS20260039567A1Method and apparatus for default notification subscription
Publication Date: 2026.02.05 TELEFONAKTIEBOLAGET LM ERICSSON (PUBL)
  • US20260039567A1 patent drawing
  • US20260039567A1 patent drawing
  • US20260039567A1 patent drawing

AI summary

A network node operates by sending a register request comprising a network function profile of the first network node to an NRF. The network function profile of the first network node may comprise one or more default notification subscriptions for services for the first network node as NF service consumer. The one or more default notification subscriptions for the one or more services may comprise one default notification subscription used to receive notification for the services. The one default notification subscription may comprise a map of service specific information per service, indicating a mapping of a service name of the service to service specific information. The service specific information comprises at least one API version of the service supported by the first network node as NF service consumer, and at least one feature of the service supported by the first network node as NF service consumer.