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
Release Timeline
Detected Changes Across Releases
from 3GPP Change RequestsSpecific 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.
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
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.
| Specification | Title | Release |
|---|---|---|
| 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 |