SCP Common Cache for Low-Latency NFProfile Discovery

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

The existing methods for NFProfile discovery and subscription by multiple SCP instances in a mobile core network result in network bandwidth overload, latency, and duplicative notifications, overloading the NRF and increasing critical signaling latency.

Innovation Solution

A network traffic management system configures a primary SCP to receive notifications from the NRF, store profiles in a common cache, and have other SCPs access these profiles, reducing the need for individual SCPs to communicate directly with the NRF, thereby optimizing discovery and subscription processes.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If every SCP instance independently communicates with the NRF for registration, discovery, and subscription, then each SCP can access network function profiles, but the NRF becomes overloaded and network bandwidth is consumed excessively

Engineering Contradiction:

Improveprofile access reliabilityVSAvoidNRF processing capacity

Core Design Contradiction:

ReliabilityVSProductivity

Solution Approach 1:

The patent introduces a master SCP as an intermediary between other SCP instances and the NRF. The master SCP receives notifications from the NRF and distributes them to other SCPs, eliminating the need for each SCP to independently communicate with the NRF. This reduces NRF overload while ensuring all SCPs receive necessary profile updates.

Inventive Principle:

Principle #24Intermediary (Mediator)

Solution Approach 2:

The patent merges the notification reception function for all SCPs into a single master SCP. Instead of multiple SCPs independently subscribing to NRF notifications, one master SCP consolidates this function and distributes information to others, reducing redundant communications and NRF load.

Inventive Principle:

Principle #5Merging (Combining)

2Loss of information

If multiple SCP instances independently subscribe to NRF notifications, then each SCP receives real-time updates, but network bandwidth is consumed excessively due to duplicative notifications

Engineering Contradiction:

Improvenotification delivery completenessVSAvoidnetwork bandwidth consumption

Core Design Contradiction:

Loss of informationVSLoss of energy

Solution Approach 1:

The patent merges notification reception into a single master SCP that receives all NRF notifications centrally. This eliminates duplicative notifications being sent to multiple SCPs independently, reducing network bandwidth consumption while ensuring all SCPs receive necessary updates through the master's distribution.

Inventive Principle:

Principle #5Merging (Combining)

Solution Approach 2:

The master SCP receives the original notification from the NRF and creates copies to distribute to other SCP instances. This single-source distribution mechanism ensures all SCPs receive updates without requiring multiple independent notification streams, conserving network bandwidth.

Inventive Principle:

Principle #26Copying

3Adaptability or versatility

If every SCP instance initiates service discovery with the NRF, then each SCP can discover available network functions, but the discovery process becomes duplicative and increases latency

Engineering Contradiction:

Improveservice discovery capabilityVSAvoiddiscovery latency

Core Design Contradiction:

Adaptability or versatilityVSLoss of time

Solution Approach 1:

The master SCP performs service discovery with the NRF in advance and maintains a local cache of discovered network function profiles. Other SCP instances can obtain profiles from this cache without initiating their own discovery processes, eliminating duplicative discovery attempts and reducing latency.

Inventive Principle:

Principle #10Preliminary action

Solution Approach 2:

The master SCP copies discovered network function profiles from the NRF to its local cache and makes them available to other SCP instances. This allows other SCPs to obtain profiles without performing their own discovery, reducing redundant communications and discovery latency.

Inventive Principle:

Principle #26Copying

4Reliability

If multiple SCP instances independently register with the NRF, then each SCP can be recognized in the network, but the registration process increases NRF overload

Engineering Contradiction:

ImproveSCP registration reliabilityVSAvoidNRF processing complexity

Core Design Contradiction:

ReliabilityVSDevice complexity

Solution Approach 1:

The patent merges the notification subscription function into a single master SCP that represents all SCP instances when communicating with the NRF. This consolidation reduces the number of independent registration and subscription operations, simplifying NRF processing while maintaining network awareness of all SCPs through the master's representation.

Inventive Principle:

Principle #5Merging (Combining)

Data Source

PatentUS12568150B1Methods for optimizing NFProfile discovery and subscriptions

Publication Date: 2026.03.03 F5 NETWORKS INC

AI summary

Methods, non-transitory computer readable media, network traffic management devices and network traffic management systems that provide protection of core networks are illustrated. With this technology, the method includes configuring a service communication proxy among a plurality of service communication proxies to receive a request from a network function. In some examples, the network function is one of the plurality of network functions. Next, the service communication proxy can be configured to determine whether a profile of the network function is stored in a common cache and, in response to determining the profile is in the common cache, retrieve the profile to respond to the request. Then, service communication proxy can be configured to select a destination NF based on based on the stored profile of the network function retrieved from the common cache.