Access Link Control Application Protocol

Description

The Access Link Control Application Protocol (ALCAP) is a critical signaling protocol within the 3GPP UMTS architecture, specifically designed for the control plane of the transport network layer. It operates over the Iub interface between the Radio Network Controller (RNC) and Node B (base station) and over the Iur interface between two RNCs. ALCAP's primary function is to dynamically establish, manage, modify, and release transport bearers for user plane data. These bearers are typically AAL2 (ATM Adaptation Layer 2) connections, which are well-suited for carrying delay-sensitive, variable bit rate traffic like voice and interactive video. ALCAP itself does not carry user data; instead, it works in conjunction with higher-layer control protocols like NBAP (Node B Application Part) and RNSAP (Radio Network Subsystem Application Part). When the RNC determines a need for a new radio access bearer (RAB), it uses NBAP/RNSAP to set up the radio resources and then triggers ALCAP to establish the corresponding AAL2 transport connection between the involved network nodes.

Architecturally, ALCAP is part of the Transport Network Control Plane (TNCP), which is separate from the Radio Network Control Plane (RNCP). This separation of control planes is a key design principle in UMTS. The RNCP (using NBAP, RNSAP) handles radio-specific signaling, while the TNCP (using ALCAP) handles the signaling required to manage the underlying transport network resources. ALCAP messages are carried over specific ATM Virtual Channel Connections (VCCs) designated for signaling. The protocol defines procedures for connection establishment (using ERQ - Establish Request and ECF - Establish Confirm messages), release (using REL - Release and RLC - Release Complete), and maintenance. It includes mechanisms for error handling, bearer identification, and quality of service parameter negotiation related to the AAL2 connection, such as peak cell rate and sustainable cell rate.

In operation, ALCAP provides a reliable, in-sequence delivery service for its signaling messages. It is a peer-to-peer protocol, meaning the RNC and the Node B (or two RNCs) communicate directly. A key component is the ALCAP protocol entity, which resides in both the controlling node (e.g., RNC) and the controlled node (e.g., Node B). This entity manages the local AAL2 switching resources and executes the signaling procedures. The protocol uses a unique Binding ID to associate an ALCAP-established transport bearer with a specific radio link or radio access bearer that was set up by the higher-layer NBAP or RNSAP procedures. This binding is crucial for ensuring that user plane data from a specific call is routed over the correct transport path. ALCAP's dynamic nature allows for efficient statistical multiplexing of multiple user connections over shared ATM resources, a significant improvement over static, pre-provisioned TDM links used in earlier GSM Abis interfaces.

Purpose & Motivation

ALCAP was created to address the fundamental shift in transport network requirements introduced by UMTS's WCDMA air interface and its support for diverse, bandwidth-on-demand services. In legacy GSM networks, the Abis interface between the BTS and BSC typically used static, circuit-switched TDM (E1/T1) lines. Each timeslot was permanently allocated, leading to inefficient resource utilization, especially for bursty data traffic. UMTS, designed from the outset to support multimedia services (voice, video, packet data) with variable and guaranteed bit rates, required a more flexible and efficient transport mechanism. The primary purpose of ALCAP is to enable the dynamic, on-demand setup and teardown of transport connections that match the instantaneous needs of user sessions, thereby optimizing the use of expensive backhaul network resources.

The protocol solves the problem of coupling radio resource management with transport resource management. Before ALCAP, these functions were often intertwined or required manual configuration. ALCAP introduces a clear separation between the Radio Network Control Plane (managing radio links) and the Transport Network Control Plane (managing AAL2 connections). This separation allows for independent evolution and scaling of the radio and transport networks. It also enables advanced features like soft handover, where a single user's data stream is split across multiple Node Bs; ALCAP can efficiently establish the multiple necessary AAL2 connections for the different legs of the handover. The motivation for using AAL2 as the bearer technology was its efficiency for low-bit-rate, delay-sensitive traffic, allowing multiple compressed voice calls to be multiplexed into a single ATM cell, reducing packetization delay and overhead compared to IP at the time.

Historically, ALCAP's development in Release 99 was a cornerstone of the UMTS terrestrial radio access network (UTRAN) architecture. It addressed the limitations of the static GSM Abis by providing a dynamic, QoS-aware transport layer that could keep pace with the rapid establishment and release of radio bearers required for packet-switched services and advanced mobility scenarios. While its relevance has diminished with the migration to all-IP transport (GTP-U over IP) in LTE and 5G, ALCAP represented a critical evolutionary step in making cellular network transport agile and service-aware.

Key Features

• Dynamic establishment and release of AAL2 transport bearers
• Separation of Transport Network Control Plane from Radio Network Control Plane
• Support for QoS parameter negotiation for AAL2 connections
• Binding mechanism to associate transport bearers with radio access bearers
• Operation over Iub and Iur interfaces in UTRAN
• Reliable, in-sequence delivery of signaling messages

Evolution Across Releases

Defining Specifications