Edge Server Selection Using Congestion State Feedback

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

The 3GPP EDGEAPP architecture lacks clear selection criteria for identifying suitable edge servers in an Edge Data Network, and there is ambiguity in the behavior of requesting entities when service provisioning or EAS discovery requests are rejected.

Innovation Solution

A server is configured to identify a second server in the edge data network based on selection criteria such as congestion state, and if the server cannot be identified, it sends a rejection message; the requesting entity performs a backoff before resending the request if the rejection indicates congestion.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If the server uses clear selection criteria to identify suitable edge servers, then the reliability of service provisioning is improved, but the device complexity increases

Engineering Contradiction:

Improvereliability of service provisioningVSAvoidcomplexity of server configuration

Core Design Contradiction:

ReliabilityVSDevice complexity

Solution Approach 1:

The patent introduces specific selection criteria parameters (congestion state, service area, capability matching) that transform the server identification process from ambiguous to systematic. By changing the decision parameters to include measurable attributes like congestion state indicators and service area definitions, the system achieves reliable server selection without requiring complex configuration logic.

Inventive Principle:

Principle #35Parameter changes

Solution Approach 2:

The patent implements feedback mechanisms where the server includes congestion state information in its responses, and the requesting entity uses this feedback to make informed selection decisions. This feedback loop enables reliable service provisioning by allowing requesting entities to adapt their behavior based on real-time server status information.

Inventive Principle:

Principle #23Feedback

2Productivity

If the requesting entity continuously retries requests upon rejection, then the productivity of service discovery is improved, but the loss of time increases due to unnecessary retries

Engineering Contradiction:

Improveproductivity of service discoveryVSAvoidtime spent on request retries

Core Design Contradiction:

ProductivityVSLoss of time

Solution Approach 1:

The patent uses feedback from rejection messages that include specific failure causes (e.g., server congestion, service area restrictions) to guide the requesting entity's retry behavior. Instead of blind retries, the system receives feedback about why a request was rejected and adjusts its strategy accordingly, reducing unnecessary time consumption.

Inventive Principle:

Principle #23Feedback

Solution Approach 2:

The patent makes the retry mechanism dynamic by allowing the requesting entity to adjust its behavior based on the type of rejection received. When congestion is indicated, the entity may delay retries; when service area restrictions are found, it may redirect to alternative servers. This dynamic approach optimizes productivity while minimizing time loss.

Inventive Principle:

Principle #15Dynamics

3Ease of operation

If the server provides detailed failure cause information in rejection messages, then the ease of operation for requesting entities is improved, but the loss of information increases due to more specific rejection handling requirements

Engineering Contradiction:

Improveease of request handlingVSAvoidinformation loss in rejection processing

Core Design Contradiction:

Ease of operationVSLoss of information

Solution Approach 1:

The patent implements feedback by having servers include detailed failure cause information in rejection messages. This feedback enables requesting entities to understand exactly why a request was rejected (congestion, service area, capability mismatch) and respond appropriately, significantly improving ease of operation while the structured feedback format actually reduces information loss by providing clear guidance.

Inventive Principle:

Principle #23Feedback

4Reliability

If the system implements backoff mechanisms for congestion handling, then the reliability of service provisioning is improved, but the duration of action increases due to additional waiting time

Engineering Contradiction:

Improvereliability of service provisioningVSAvoidduration of service discovery process

Core Design Contradiction:

ReliabilityVSDuration of action of moving object

Solution Approach 1:

The patent uses feedback from congestion indicators in server responses to trigger backoff mechanisms. When the server signals congestion, the requesting entity receives feedback that justifies waiting, thereby improving reliability. The backoff duration is optimized based on the feedback, balancing reliability improvement with acceptable process duration.

Inventive Principle:

Principle #23Feedback

Data Source

PatentUS20240107424A1Server, requesting entity, and methods therefor

Publication Date: 2024.03.28 NEC CORP

AI summary

In response to receiving from a requesting entity (2) a request for a connection to an entity providing a service in an edge data network (4), a first server (7) attempts to identify a second server (5) located in the edge data network (7) based on at least one selection criterion. The at least one selection criterion includes a congestion state of a server located within the edge data network (4). If the second server (5) is identified, the first server (7) sends information about the second server (5) to the requesting entity (2). If the second server (5) cannot be identified, the first server (7) sends to the requesting entity (2) a rejection message indicating that the second server (5) cannot be identified. This can contribute, for example, to providing a suitable selection criterion for identifying an edge server.