T-EAS

Target Edge Application Server

Services →
Introduced in Rel-17

T-EAS is the Edge Application Server selected by the network to host a specific application instance and act as the traffic endpoint for a UE in Edge Computing scenarios.

Category
Services
Introduced
Rel-17
Where
Services
Specifications
3 specs
T-EAS Description Purpose Related Classification Detected Changes Specifications

Description

The Target Edge Application Server (T-EAS) is a functional entity defined within the 3GPP Edge Computing architecture (EDGE). It represents the specific Edge Application Server (EAS) instance that is designated to serve a User Equipment (UE) after a decision has been made to relocate, migrate, or initially assign an application session. The selection of the T-EAS is a key outcome of the EAS discovery and selection procedures orchestrated by the Edge Enabler Client (EEC) in the UE and the Edge Enabler Server (EES) in the network. When an application requires edge computing resources (like low latency or local data processing), the network assists the UE in finding a suitable EAS. The T-EAS is the final chosen destination.

The process involves several steps. The EEC, potentially triggered by an application request, contacts its associated EES. The EES, which has knowledge of available EAS instances and their capabilities (through registration with an Edge Configuration Server), performs EAS discovery. Based on factors like UE location, application requirements, EAS load, and network policies, the EES selects a candidate EAS and provides its information (including IP address or FQDN) to the EEC as the T-EAS. The UE then establishes a direct application-layer connection (e.g., TCP/IP) to this T-EAS. In scenarios of mobility or changing conditions, the application session may need to be transferred from a previous EAS (Source EAS) to a new T-EAS. This relocation procedure is managed by the network with the goal of maintaining session continuity.

The T-EAS hosts the actual application logic or data processing function. It is typically deployed at the network edge, close to the radio access network, to minimize latency. The role of the T-EAS is central to fulfilling the promises of edge computing: enabling ultra-reliable low-latency communications (URLLC), supporting computational offloading for IoT devices, and facilitating advanced services like augmented reality. The 3GPP specifications define protocols and APIs (e.g., in 23.558 and 29.558) for the discovery, selection, and relocation procedures that ultimately identify the T-EAS.

Purpose & Motivation

The T-EAS concept was created to formalize the endpoint selection in 3GPP's standardized Edge Computing framework. Prior to this standardization, deploying applications at the edge relied on proprietary or cloud-centric methods, lacking integration with mobile network control. This made dynamic, network-assisted selection of the optimal edge server based on real-time conditions (like UE mobility or network load) difficult. The EDGE work item aimed to integrate edge computing seamlessly into the 5G system.

T-EAS addresses the problem of how to dynamically and efficiently direct a UE's application traffic to the most suitable edge server instance. It provides a clear target for the network's selection algorithms, enabling optimized service delivery. This is critical for applications sensitive to latency or location, such as vehicle-to-everything (V2X) communication or industrial IoT control. By having a standardized 'target' entity, the procedures for session establishment, relocation, and termination can be uniformly managed, ensuring interoperability between UE, network functions, and edge application providers.

Classification

Part ofEAS
Related approachesEESECS

Release Timeline

Detected Changes Across Releases

from 3GPP Change Requests

Specific changes extracted from the „Change history“ tables of 3GPP specifications (5 CRs across 2 releases). Complements the general historical overview above with the evidence-based evolution of this function.

Rel-17 1 change

In Release 17, the T-EAS (Target Edge Application Server) function was enhanced to support service continuity through new procedures like "ACR monitoring" and "ACR facilitation" events, enabling the Edge Enabler Server (EES) to detect user plane path changes, discover T-EAS(s), and influence traffic routing. The specifications also introduced explicit support for T-EAS discovery initiated by the Client Application Server (CAS) and detailed the mechanisms for Application Context Transfer (ACT) from a Source EAS (S-EAS) to a T-EAS. Furthermore, corrections were made to the technical specifications for selected T-EAS declaration to ensure proper implementation.

  • Corrections for selected T-EAS declaration TS 23.558CR0095
Rel-18 4 changes

In Release 18, the T-EAS (Target Edge Application Server) function was enhanced to support its discovery with edge load performance information and to clarify the CAS (Central Application Server) endpoint's role in the T-EAS declaration. The specifications further refined the T-EAS discovery procedure, which is a key trigger for Application Context Relocation (ACR), and resolved editorial notes to improve clarity around this process. These updates provided a more defined framework for the "ACR facilitation" and "ACR monitoring" events, where the EES discovers and selects a T-EAS to enable service continuity.

  • Support Discover T-EAS with Edge load performance information TS 23.558CR0233
  • Resolving Editor's Note about T-EAS discovery TS 23.558CR0286
  • Resolve the EN on discover T-EAS TS 23.558CR0458
  • Clarify CAS endpoint in T-EAS declaration TS 23.558CR0498

Explore further

Broader topics and technologies where T-EAS plays a role.

Defining Specifications

3GPP specifications that define or reference T-EAS, with the latest known release. Sourced from the 3GPP document catalog — see methodology.

SpecificationTitleRelease
TS 23.558 vk00 Architecture for Edge Applications Rel-20
TS 29.558 vj40 Enabling Edge Applications Rel-19
TR 33.739 vi10 Study on security enhancement of support for Rel-18
Patrick Zandl

About the author: Patrick Zandl (b. 1974)

Telecommunications specialist, technology journalist (founder of the Mobil server), and developer who has been running since 2025 — the largest Czech-language resource on AI-assisted programming. Formerly Chief Wizard Architect at Prusa3D and head of development for Turris at CZ.NIC; currently a consultant and instructor on AI implementation in companies.