Edge Application Context Relocation with Centralized Scenario Selection
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing edge application context relocation (ACR) solutions in communication systems face inefficiencies due to multiple entities simultaneously initiating ACR scenarios, leading to unnecessary signaling and the need for a single entity to determine supported ACR scenarios.
Innovation Solution
An edge enabler server (EES) is configured to receive ACR status updates and select ACR scenarios when successful, reducing signaling by storing and managing supported ACR scenarios within the EEC context.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If multiple entities simultaneously initiate ACR scenarios, then ACR can be initiated from multiple perspectives, but unnecessary signaling is generated and system complexity increases
Solution Approach 1:
The EES acts as an intermediary between the EEC and EAS, centralizing the ACR scenario selection function. Instead of multiple entities independently initiating ACR scenarios, the EES receives the ACR status update and selectively determines which ACR scenarios to execute, thereby reducing redundant signaling while preserving initiation flexibility.
Solution Approach 2:
The EES is designed with multi-functionality, serving as both a context management entity and an ACR scenario decision-maker. This universal role allows it to coordinate ACR operations across different entities without requiring each entity to independently manage ACR scenario selection, thus reducing overall system complexity.
2Ease of operation
If ACR scenario selection is distributed across multiple entities, then each entity can independently optimize its local behavior, but the amount of signaling required for coordination increases
Solution Approach 1:
The EES serves as a central coordinator that receives ACR status updates and determines appropriate ACR scenarios. This intermediary approach allows local entities (EEC and EAS) to maintain their operational independence while minimizing coordination signaling, as the EES consolidates the decision-making process in one location.
Solution Approach 2:
The patent merges the ACR scenario selection function into the EES, combining multiple responsibilities (context management, ACR coordination, scenario selection) into a single entity. This consolidation reduces the signaling volume required for coordination compared to a distributed approach where each entity would need to exchange extensive information.
3Reliability
If ACR scenario selection is performed frequently, then service continuity can be better maintained, but the signaling overhead and processing load increase
Solution Approach 1:
The EES operates based on feedback from ACR status updates received from the EAS. Rather than continuously initiating ACR scenarios, the EES waits for status changes and then selectively determines appropriate scenarios, reducing unnecessary signaling while maintaining service continuity when actually needed.
Solution Approach 2:
The ACR scenario selection is triggered periodically or event-driven by ACR status updates rather than continuously. This periodic action approach allows the system to maintain service continuity by responding to actual status changes while avoiding the signaling overhead of continuous monitoring and selection.
Data Source
AI summary
Examples of the disclosure relate to application context relocation (ACR) for edge application data sessions in a communication system. One example method is applied to an edge enabler server (EES). The example method includes receiving an ACR status update from an edge application server (EAS), the ACR status update being associated with an edge application data session between an application client (AC) and the EAS. One or more ACR scenarios is selected for the edge application data session when the ACR status update indicates that the ACR is successful.