Load-Shared Event Notification Routing in 5G Core Networks
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current 3GPP Rel-16 eSBA specifications do not support sending event notifications to multiple active destinations, limiting load-sharing and load-balancing capabilities in 5G core networks, which can lead to inefficient resource management and increased load on specific consumer instances.
Innovation Solution
Incorporating new headers and flags in notification subscription messages, such as 'altActiveNotifIpv4Addrs' and 'loadsharing possible', to enable load-sharing of notifications across multiple notification identifiers, including primary and active alternative IP addresses or FQDNs, allowing notifications to be sent to less-loaded consumer instances or balanced across multiple consumers.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If event notifications are sent to a single destination according to current 3GPP Rel-16 eSBA specifications, then the notification system is simple to implement, but load-sharing and load-balancing capabilities are limited, leading to inefficient resource management and increased load on specific consumer instances
Solution Approach 1:
The notification destination is segmented into multiple consumer instances (primary and alternative) that can independently handle notifications. The system divides the single destination approach into multiple selectable destinations, allowing load to be distributed across segmented consumer instances based on their current load status
Solution Approach 2:
The notification routing is made dynamic by introducing alternative notification identifiers that can be selected based on real-time load conditions. Instead of a static single destination, the system dynamically chooses among multiple destinations (primary or alternative) depending on which consumer instance is less loaded at any given moment
2Productivity
If multiple notification identifiers are introduced for load-sharing, then resource management efficiency improves, but the notification subscription message structure becomes more complex requiring new headers and flags
Solution Approach 1:
The notification subscription message structure is enhanced with multi-functional headers and flags that serve multiple purposes. The alternative notification identifier header can carry both primary and alternative destinations, while the load-sharing flag enables or disables load-sharing behavior, making the message structure universally applicable to different notification scenarios
Solution Approach 2:
The system changes the parameters of the notification subscription message by introducing new headers (alternative notification identifier) and flags (load-sharing indicator). These parameter changes enable the message to carry additional information necessary for load-sharing while maintaining compatibility with existing notification mechanisms
3Reliability
If notifications are load-shared across multiple consumer instances, then system resilience and scalability improve, but the complexity of managing multiple notification identifiers and their associated routing increases
Solution Approach 1:
The system implements feedback mechanisms where consumer instances report their load status, and this feedback is used to dynamically determine which instance should receive the notification. The primary or alternative notification identifier is selected based on feedback about current load conditions, enabling intelligent routing that improves reliability while managing complexity through automated decision-making
Data Source
AI summary
Presented herein are techniques to facilitate that enable notifications to be sent to multiple consumers for Third Generation Partnership Project (3GPP) architectures. In one example, a method is provided that may include obtaining, at a first network entity, a notification subscription message from a second network entity, the notification subscription message comprising a plurality of notification identifiers associated with the second network entity for notifications that are to be communicated to the second network entity, wherein the plurality of notification identifiers are indicated, at least in part, in a header of the notification subscription message; and communicating one or more notifications to the second network entity, wherein the one or more notifications are load-shared among the plurality of notification identifiers associated with the second network entity.