CAS

Channel Associated Signalling

Protocol →
Introduced in Rel-8 Also in: Radio Access Network

CAS is a legacy telephony signalling method where control information travels within the same physical channel as the voice or data traffic.

Category
Protocol
Introduced
Rel-8
Where
Services › Codecs
Also touches
1 segments
Specifications
10 specs
CAS Description Purpose Related Classification Detected Changes Specifications

Description

Channel Associated Signalling (CAS) is a telecommunication signalling architecture in which the signalling information necessary for call setup, supervision, and teardown is transmitted within the same physical transmission channel (or a channel permanently associated with it) as the user voice or data traffic. In T1/E1 digital carrier systems, this is typically implemented by 'robbing' specific bits from the user data stream within each frame to carry the signalling state. For example, in the T1 24-channel PCM system using the Super Frame (SF) format, the least significant bit (the 8th bit) of the 6th and 12th frames of each 12-frame superframe is used for signalling for each channel. In the Extended Super Frame (ESF) format, bits are robbed from the 6th, 12th, 18th, and 24th frames.

The operation of CAS is inherently tied to the timeslot structure of the physical transmission medium. Each voice channel (e.g., a 64 kbps DS0 timeslot) has its own dedicated, in-band signalling path. The signalling information is simple, typically representing a small set of states such as idle, off-hook, on-hook, ringing, and wink. This information is transmitted repetitively, allowing the receiving equipment to constantly monitor the line state. Because the signalling is physically bonded to its traffic channel, establishing a call involves dedicating both the bearer path and its associated signalling capacity for the duration of the connection.

Key components in a CAS-based network include channel banks or multiplexers that perform the analog-to-digital conversion and insert/extract the robbed-bit signalling, and digital switches equipped with CAS trunk cards to interpret these signals. The protocol is simple and deterministic, with low overhead for a single channel, but it lacks the flexibility, speed, and rich feature set of common channel signalling. Its operation is transparent to the user data, though the bit-robbing technique technically reduces the voice channel's fidelity from 8-bit to 7.5-bit µ-law/A-law coding during signalling frames.

In the context of 3GPP specifications, CAS is primarily referenced for legacy interworking and migration scenarios. While 3GPP systems from GSM onwards have predominantly used Common Channel Signalling (e.g., SS7, SIGTRAN, Diameter) for core network functions, CAS interfaces may be relevant where the mobile network interconnects with traditional PSTN or legacy PBX systems. Specifications like TS 29.424 and TS 29.558 may reference CAS in the context of signalling interworking functions (IWF) that translate between ISDN User Part (ISUP) or other protocols and legacy CAS signalling to facilitate end-to-end call control across hybrid networks.

Purpose & Motivation

CAS was developed as a fundamental method for signalling in early digital telephone networks, most notably with the T1 (1.544 Mbps) and E1 (2.048 Mbps) carrier systems introduced in the 1960s and 1970s. Its primary purpose was to provide a straightforward, channel-by-channel mechanism for supervisory signalling (seizing, answering, disconnecting) and address signalling (dialed digits) without requiring a separate, complex signalling network. It solved the problem of efficiently integrating control functions into the nascent digital transmission infrastructure, replacing the separate DC signalling loops or single-frequency tones used in analog carrier systems.

The motivation for CAS was simplicity, direct association, and cost-effectiveness for point-to-point trunk connections. Since each voice channel carried its own control bits, there was no need for a sophisticated packet-switched signalling network or high-level protocol stacks. This made early digital switches and channel banks simpler to design and deploy. It was perfectly suited for the era of circuit-switched telephony, where a physical end-to-end connection was established and maintained, and the associated signalling could be easily 'stolen' from the already-synchronized digital bitstream.

However, CAS has significant limitations that motivated the industry-wide shift to Common Channel Signalling (CCS). Its in-band nature makes it susceptible to fraud (e.g., 'blue boxing') where tones can mimic signalling. It is inefficient for feature-rich services, as the signalling bandwidth is minimal and cannot easily carry additional information. Call setup is slower, as signalling can only be sent during specific robbed-bit frames. Most critically, the signalling path is only available when the traffic channel is established, preventing features like calling the line while it is busy. 3GPP's adoption of CCS-based architectures from its inception was a direct response to these limitations, enabling faster, more secure, and more intelligent network services.

Classification

Part ofSS7
Related approachesISUP

Release Timeline

Detected Changes Across Releases

from 3GPP Change Requests

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

Rel-18 14 changes

In Release 18, the CAS (Cloud Application Server) function was formally introduced to enable service continuity transitions between Edge Application Servers (EAS) and the cloud. The release specified new Application Context Relocation (ACR) procedures between EAS and CAS, which can be executed by the Source Edge Enabler Server (S-EES), the CAS itself, or via a Cloud Enabler Server (CES) in certain architectural configurations. It also defined the ECI-1 interface for CAS-EES interaction and allowed the EEC to subscribe to SEAL notifications and request a UE ID to facilitate future ACRs back to an EAS.

  • Architecture with CAS and CES TS 23.558CR0167
  • ACR procedure btw EAS and CAS TS 23.558CR0234
  • ACR with CAS - EEC executed ACR via S-EES TS 23.558CR0334
  • ACR with CAS - S-EAS decided ACR TS 23.558CR0337
  • ACR with CAS - S-EES executed ACR TS 23.558CR0338
  • CAS decided ACR scenario via old S-EES for CESless architecture TS 23.558CR0401

+ 8 more changes

Rel-19 7 changes

In Release 19, the new CAS (Cloud Application Server) functionality introduced the specific procedure for Application Context Relocation (ACR) to a CAS when no suitable Target EAS is discovered, enabling service continuity from the edge to the cloud. This includes defining the interactions where a CAS can act as a Source EAS and utilize interfaces like ECI-1 with an EES for T-EAS discovery to facilitate a future ACR back to an EAS. Furthermore, the release specified the support for CAS to consume Edge Enabler Services (EES) and detailed the cardinality rules for the CLOUD-1 interface between a CAS and a Cloud Enabler Server (CES).

  • Introducing CAS Muting [5GB_CASMuting] TS 36.300CR1436
  • Introduction of CAS muting in LTE-based 5G broadcast [5GB_CASMuting] TS 36.306CR1916
  • Introduction of CAS muting in LTE-based 5G broadcast [5GB_CASMuting] TS 36.331CR5139
  • Rapporteur correction on CAS muting for LTE based 5G broadcast [5GB_CASMuting] TS 36.331CR5162
  • Correction in S-EES executed ACR to CAS TS 23.558CR0554
  • CAS consumes EES services TS 23.558CR0581

+ 1 more changes

Explore further

Broader topics and technologies where CAS plays a role.

Defining Specifications

3GPP specifications that define or reference CAS, 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 23.700 vk00 XR Services Application Enablement Layer Rel-20
TR 26.917 vj00 TV Service Enhancements over 3GPP Rel-19
TR 26.938 vj00 DASH Deployment Guidelines for 3GPP Networks Rel-19
TS 29.424 v801 H.248 Profile for Trunking Media Gateways Rel-8
TS 29.558 vj40 Enabling Edge Applications Rel-19
TS 36.300 vj00 E-UTRAN Radio Interface Protocol Architecture Overview Rel-19
TS 36.306 vj00 E-UTRA UE Radio Access Capability Parameters Rel-19
TS 36.331 vj00 LTE RRC Protocol Specification Rel-19
TR 36.976 vj00 LTE-based 5G Terrestrial Broadcast Overview Rel-19
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.