Inter-eDU Communications via Service-Based Network APIs

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing wireless communications systems face challenges in facilitating inter-eDU communications due to the inherent inability to support direct interactions between evolved distributed units (eDUs) in complex and dynamic environments, which are crucial for seamless mobility, load balancing, and network optimization in 6G wireless networks.

Innovation Solution

Implementing a service-based interface (SBI) between eDUs and core network functions (CN NFs) deployed as 6G services, enabling direct or relayed inter-eDU communications through APIs such as API1 for registration, API2 for information exchange, and API3 for information exposure, allowing eDUs to interact directly or through 6G services as intermediaries.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Productivity

If direct inter-eDU communications are implemented, then mobility management and load balancing efficiency are improved, but system complexity and implementation overhead increase

Engineering Contradiction:
Improvemobility management efficiencyVSAvoidsystem complexity
Core Design Contradiction:
ProductivityVSDevice complexity

Solution Approach 1:

The patent introduces a service-based interface (SBI) as an intermediary layer between eDUs, enabling indirect communication through standardized APIs. This mediator approach allows eDUs to exchange information for mobility management and load balancing without requiring complex direct peer-to-peer communication protocols, thus improving efficiency while controlling system complexity.

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The patent implements a universal service-based interface that handles multiple functions including mobility management, load balancing, and information exchange between eDUs. This multi-functional interface reduces the need for separate communication channels for each function, improving overall productivity while reducing the cumulative system complexity that would result from multiple specialized interfaces.

Inventive Principle:
Principle #6Universality (Multi-functionality)

2Adaptability or versatility

If service-based interface with multiple APIs is implemented, then inter-eDU communication capability is improved, but implementation overhead and deployment complexity increase

Engineering Contradiction:
Improveinter-eDU communication capabilityVSAvoidimplementation overhead
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent segments the communication interface into distinct, standardized APIs (API1 for information exchange, API2 for service interaction, API3 for data access). This segmentation allows each API to handle specific communication tasks independently, improving adaptability and versatility of inter-eDU communication while making the overall system more manageable and reducing implementation overhead through modular design.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent employs parameter-based configuration for the service-based interface, allowing the system to adapt communication parameters (such as API selection, data formats, and interaction modes) based on specific deployment scenarios. This parameter flexibility enhances communication capability across diverse environments while reducing implementation overhead by avoiding the need for completely different interface designs for each scenario.

Inventive Principle:
Principle #35Parameter changes

3Speed

If eDUs exchange metrics directly, then communication efficiency is improved, but reliability and security in dynamic environments deteriorate

Engineering Contradiction:
Improvecommunication efficiencyVSAvoidcommunication reliability
Core Design Contradiction:
SpeedVSReliability

Solution Approach 1:

The patent introduces the service-based interface as a trusted intermediary that mediates metric exchange between eDUs. This intermediary layer maintains communication efficiency by providing direct API-based data transfer while simultaneously enhancing reliability through standardized protocols, authentication mechanisms, and error handling that are inherent to the service-based architecture.

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The patent implements feedback mechanisms within the service-based interface where communication status, error conditions, and metric validation results are continuously monitored and reported. This feedback system enhances reliability by enabling error detection, correction, and recovery while maintaining efficient communication through automated retry logic and validation processes that operate transparently within the API framework.

Inventive Principle:
Principle #23Feedback

Data Source

PatentUS20250284576A1Inter-peer apparatus communications using a central network entity
Publication Date: 2025.09.11 QUALCOMM INC
  • US20250284576A1 patent drawing
  • US20250284576A1 patent drawing
  • US20250284576A1 patent drawing

AI summary

Certain aspects of the present disclosure provide techniques for techniques for inter-evolved distributed unit (eDU) communications. A method generally includes communicating, by an apparatus with a network entity via a first type of application programming interface (API) at the network entity, to register the apparatus with the network entity; and exchanging metric(s) with peer apparatus(es) associated with the network entity based on: a first communication with the peer apparatus(es) via a second type of API and/or a third type of API exposed at the apparatus; a second communication with the one or more peer apparatuses via the second type of API and/or the third type of API at each of the peer apparatus(es); a third communication with the network entity via the second type of API at the network entity; and/or a fourth communication with the network entity via the third type of API exposed at the apparatus.