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

Detected Changes Across Releases

from 3GPP Change Requests

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

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

Rel-15 19 changes

In Release 15, the Cloud Application Server (CAS) function was newly introduced as part of the application layer architecture to support service continuity. The specification defines mechanisms for transferring an Application Context between an Edge Application Server (EAS) and a CAS, and introduces the CLOUD-1 interface for interaction between the CAS and the Cloud Enabler Server (CES).

  • Signalling for euCA (Enhancing LTE CA Utilization) TS 36.331CR3391
  • Additional capability signalling for 1024QAM support TS 36.306CR1709
  • Additional capability signalling for 1024QAM support TS 36.331CR4031
  • Alternative signalling option for SupportedBandListNR TS 36.306CR1665
  • Signalling of CRS IM and CCH-IM for UE cat 1bis and cat M2 TS 36.306CR1669
  • UE capability signalling for FD-MIMO processing capabilities for EN-DC TS 36.306CR1708

+ 13 more changes

Rel-16 3 changes

In Release 16, the new capabilities for the Cloud Application Server (CAS) function primarily focused on enabling service continuity procedures between edge and cloud applications. Specifically, the release introduced defined interfaces (ECI-1 and CLOUD-1) and procedures allowing the seamless transfer of an Application Context between an Edge Application Server (EAS) and a CAS, and vice-versa. Furthermore, the CAS gained the ability to interact with the Cloud Enabler Server (CES) for functions like network capability exposure and data session setup to support these continuity handovers.

  • Signalling UE capability Identity TS 36.300CR1294
  • Introduction of signalling for high-speed train scenarios TS 36.306CR1767
  • Introduction of signalling for high-speed train scenarios TS 36.331CR4326
Rel-17 2 changes

In Release 17, the CAS (Cloud Application Server) function was introduced as a new architectural component for service continuity, enabling a User Equipment's application context to be transferred to a cloud-based server when no suitable Edge Application Server (EAS) is available. The specification defines new interfaces for the CAS, including ECI-1 for communication with the Edge Enabler Server (EES) and CLOUD-1 for interaction with the Cloud Enabler Server (CES), to facilitate these handovers and support procedures like T-EAS discovery.

  • Ensuring consistent support of capability bits and associated NS-values in n77 in USA and Canada TS 36.306CR1859
  • Correction on SIB31 signalling only in NTN cell TS 36.331CR4972
Rel-18 18 changes

In Release 18, the CAS (Cloud Application Server) function was enhanced to support Application Context Relocation (ACR) procedures with EASs and EESs, including scenarios where the CAS, S-EES, or S-EAS decides to initiate the ACR. The release also formalized the CAS's role in service continuity for architectures with and without a Cloud Enabler Server (CES), defined cardinality rules for CAS deployment, and introduced the CLOUD-1 interface for CAS-CES interaction to facilitate data session setup and access to network capabilities like location information.

  • 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

+ 12 more changes

Rel-19 7 changes

In Release 19, the key enhancement for the CAS function was the introduction of CAS muting specifically for LTE-based 5G broadcast. Furthermore, the release formalized the CAS's consumption of EES services and resolved an editorial note (EN) related to CAS procedures.

  • 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