TAS

Telephony Application Server

Services →
Introduced in Rel-7 Also in: Services, User Equipment, Testing

TAS is the Telephony Application Server in the IMS that provides traditional telephony services like call forwarding and voicemail over IP networks, forming the core of VoLTE and IMS-based voice.

Category
Services
Introduced
Rel-7
Where
Core Network › 5G Core
Also touches
3 segments
Specifications
11 specs
TAS Description Purpose Detected Changes Specifications

Description

The Telephony Application Server (TAS) is a critical functional entity within the 3GPP IP Multimedia Subsystem (IMS) architecture, responsible for hosting and executing telephony service logic. It acts as an Application Server (AS) that interfaces with the IMS core—specifically the Serving-Call Session Control Function (S-CSCF) via the IMS Service Control (ISC) interface—to provide value-added telephony services. When a user initiates or receives a call session, the S-CSCF invokes the appropriate service logic on the TAS based on the user's initial Filter Criteria (iFC) defined in the Home Subscriber Server (HSS). The TAS then influences the call flow, applying features such as call forwarding, barring, voicemail, call waiting, or multi-party conferencing.

Architecturally, the TAS is a software-based server that implements the 3GPP-defined service logic for telephony applications. It communicates using SIP (Session Initiation Protocol) over the ISC interface. The TAS can manipulate SIP messages (INVITE, BYE, etc.), generate new SIP transactions, and interact with other network elements like Media Resource Functions (MRF) for playing announcements or managing conference bridges. In modern deployments, especially for VoLTE, the TAS is often implemented as a virtualized network function (VNF) running on cloud infrastructure, providing scalability and flexibility. It maintains service state information for active sessions and may interface with subscriber databases to retrieve user profiles and service settings.

The TAS's role is fundamental to enabling rich telephony services in an all-IP network. It separates service logic from the basic call control and transport functions of the IMS core, allowing operators to develop, deploy, and update services independently. For example, in a VoLTE call, the TAS can provide seamless number translation, implement business communication features, or integrate with web services for enriched calling. Its operation is specified across numerous 3GPP technical specifications covering IMS service requirements, architecture, and protocols.

Purpose & Motivation

The TAS was introduced with the IP Multimedia Subsystem (IMS) in 3GPP Release 5/6 to solve the challenge of delivering traditional circuit-switched telephony services over packet-switched IP networks. As mobile networks evolved towards all-IP architectures with LTE, there was a need to replace the legacy Mobile Switching Center (MSC) and its service logic with an IP-based equivalent. The TAS provides this functionality, enabling operators to offer familiar telephony features (like those defined in GSM) over IMS, thereby supporting Voice over LTE (VoLTE) and ensuring service continuity and feature parity with 2G/3G circuit-switched voice.

Its creation was motivated by the industry's move to converge fixed and mobile services onto a common IP core. The TAS allows for the centralized, efficient deployment of telephony applications that can serve both mobile and fixed-line subscribers. It addresses limitations of earlier approaches where telephony services were tightly coupled to specific switching hardware, making them costly and slow to update. By standardizing the TAS within IMS, 3GPP enabled a vibrant ecosystem of application servers, fostering innovation in telephony services while maintaining interoperability across different vendors' IMS cores and user equipment.

Detected Changes Across Releases

from 3GPP Change Requests

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

Studied in Rel-7, normative work from Rel-15.

Rel-15 1 change

In Release 15, the Telephony Application Server (TAS) function was enhanced to support new IMS applications, including a data channel application server for handling data channel traffic and a bootstrap data channel for transferring graphical user interfaces to the UE. Additionally, support for WebRTC was introduced, with mechanisms for WebRTC Web Server Function discovery to enable browser-based real-time communications within the IMS framework.

  • WebRTC Web Server Function discovery TS 23.228CR1173
Rel-17 1 change

In Release 17, the TAS function was enhanced with a specific verification procedure for when the TAS is OFF, as detailed in TR38.834. This procedure provides a defined mechanism for the network to confirm the operational state of the Telephony Application Server.

  • CR to TR38.834 on TAS OFF verification procedure TS 38.834CR0001
Rel-18 5 changes

In Release 18, the TAS function was enhanced to support new procedures for UE-centric Augmented Reality (AR) Telephony Communication and Data Channel (DC) applications. Key updates included the establishment of a bootstrap data channel to provide an application list based on UE DC capabilities and clarifications to the DC QoS handling within the application data channel setup procedures. These changes also involved updates to the binding information for the DC Application Server and its interactions with the DCSF.

  • Binding information of DC Application with DC - 23.228 TS 23.228CR1266
  • Supporting UE centric AR Telephony Communication TS 23.228CR1284
  • Provide application list based on UE DC capabilities TS 23.228CR1294
  • Update of Bootstrap and application data channel setup procedures TS 23.228CR1301
  • Clarification on DC QoS Handling in Application Data Channel Setup Procedures TS 23.228CR1391
Rel-19 7 changes

In Release 19, the TAS function was enhanced to support multiplexing multiple Data Channel (DC) applications over a single SCTP connection, improving transport efficiency. The release also introduced updates and corrections for DC application interworking via the Media Function (MF) and for the procedures involving the DC Application Proxy and Server. Furthermore, it specified the mechanism for correlating an application data channel with the bootstrap data channel used to deliver the application's graphical interface.

  • Support of multiplexing multiple DC applications over single SCTP connection TS 23.228CR1511
  • Updates to support multiplexing multiple DC applications over single SCTP connection TS 23.228CR1552
  • Service updates to support multiplexing multiple DC applications over single SCTP connection TS 23.228CR1586
  • Corrections to Signalling Procedure of Application Data Channel Interworking via MF TS 23.228CR1659
  • Add DC Application Server Description TS 23.228CR1682
  • Correction on the usage of DC Application Proxy TS 23.228CR1686

+ 1 more changes

Explore further

Broader topics and technologies where TAS plays a role.

Defining Specifications

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

SpecificationTitleRelease
TS 23.228 vj50 IMS Stage-2 Service Description Rel-19
TS 23.292 vj00 IMS Centralized Services (ICS) Architecture Rel-19
TS 23.719 ve00 Study on Service Domain Centralization (SeDoC) Rel-14
TS 23.845 va00 UDC Evolution Study Rel-10
TS 23.883 v900 IMS Centralized Services Supplementary Data Management Rel-9
TS 29.864 v801 Application Server Service Data Definition for IMS Telephony Rel-8
TR 29.935 vj00 HSS Reference Data Model for Ud Interface Rel-19
TS 38.161 vj10 NR UE TRP and TRS Requirements for FR1 Rel-19
TS 38.561 vj00 UE Conformance for TRP/TRS FR1 Rel-19
TR 38.834 vh20 NR FR1 TRP/TRS Test Methodology Rel-17
TS 38.870 vj20 Enhanced OTA Test Methods for NR FR1 TRP/TRS Rel-19