MCCH

MBMS point-to-multipoint Control Channel

Radio Access Network →
Introduced in Rel-6 Also in: User Equipment

MCCH is the logical channel in 3GPP networks that broadcasts MBMS control information, including the configuration and scheduling details for MTCH channels, to enable point-to-multipoint content delivery.

Category
Radio Access Network
Introduced
Rel-6
Where
Radio Access Network › NG-RAN (5G)
Also touches
1 segments
Specifications
28 specs
MCCH Description Purpose Related Classification Detected Changes Specifications

Description

The MBMS point-to-multipoint Control Channel (MCCH) is a downlink logical channel defined within the 3GPP radio access network architecture. It operates as a critical component of the MBMS framework, which is designed for efficient broadcast and multicast service delivery. As a logical channel, the MCCH is mapped onto transport channels and eventually physical channels for transmission over the air interface. Its primary function is to carry control plane information necessary for UEs to receive MBMS services on the Multicast Traffic Channel (MTCH). This information includes MBMS service announcements, session start notifications, and most importantly, the Radio Resource Control (RRC) configuration messages that specify how the associated MTCH is scheduled and transmitted. The MCCH is transmitted in a point-to-multipoint fashion within an MBMS Single Frequency Network (MBSFN) area, meaning a single transmission is received by all subscribed UEs within that geographic zone.

Architecturally, the MCCH is defined per MBSFN area. An MBSFN area is a collection of cells that are synchronized to transmit identical waveforms for MBMS content, creating a seamless broadcast region. Within each MBSFN area, there is one unique MCCH. The network uses System Information Blocks (SIBs), specifically SIB13 in LTE and SIB20 in NR, to inform UEs about the scheduling and configuration of the MCCH itself. This includes parameters like the modification period, repetition period, and subframe allocation. The UE, after acquiring this SIB, knows when and where to listen for the MCCH to obtain the necessary RRC configuration (an MBSFNAreaConfiguration message) for the MTCHs it is interested in.

The operation of the MCCH is characterized by its periodic and change-driven notification mechanism. It is transmitted at predefined intervals. To save UE battery, a change notification mechanism is employed. Short notifications are sent on a related physical channel (e.g., MICH in UMTS, PDCCH with G-RNTI/MCS-RNTI in LTE/NR) to alert UEs only when the MCCH information is about to change in the next modification period. If no notification is detected, the UE can assume the previous MCCH configuration remains valid and does not need to decode the MCCH repeatedly. The content on the MCCH includes a list of MBMS services (identified by Temporary Mobile Group Identities - TMGIs) active in the area and, for each, the associated logical channel configuration for the MTCH. This tells the UE the specific radio bearer configuration, scheduling, and MCS (Modulation and Coding Scheme) to use for decoding the multimedia content.

In the overall protocol stack, the MCCH exists at the RRC layer. The information is generated by the RRC entity in the base station (eNodeB/gNB) based on instructions from the core network's MBMS coordination entity (MCE). It is then passed down through the Packet Data Convergence Protocol (PDCP), Radio Link Control (RLC), and Medium Access Control (MAC) layers, where it is assigned specific transport and physical resources. Its role is foundational to MBMS because without the control information it provides, UEs would be unable to discover, synchronize with, and correctly decode the broadcast multimedia streams, rendering the point-to-multipoint service delivery impossible.

Purpose & Motivation

The MCCH was created to solve the fundamental control signaling challenge for broadcast/multicast services in cellular networks. Traditional unicast services use dedicated signaling channels per UE, which is massively inefficient for services delivering identical content to thousands of devices, such as mobile TV or live event streaming. Without a shared control channel, the network would need to send individual RRC configuration messages to each UE, consuming excessive downlink radio resources and core network signaling capacity.

The introduction of MBMS in 3GPP Release 6 necessitated a complementary control mechanism that matched the efficiency of the point-to-multipoint data channel (MTCH). The MCCH provides this by broadcasting control information once for all UEs in an area. This design is intrinsically linked to the concept of MBSFN operation, where multiple cells transmit in synchrony. The MCCH carries the unified configuration that allows all UEs to tune into this synchronized transmission correctly. Its purpose extends beyond mere efficiency; it enables service scalability, allowing an unlimited number of UEs to join a broadcast session without impacting the control channel load. It also facilitates essential MBMS functions like service announcement (telling UEs what broadcasts are available) and session control (signaling the start and stop of a broadcast stream).

Historically, before dedicated broadcast systems like MBMS, delivering popular content required massive unicast duplication, which could congest the network. The MCCH, as part of the MBMS architecture, provided the standardized, cellular-integrated control plane that made network-based broadcast a viable and efficient service for operators. It addressed the limitations of previous non-cellular broadcast technologies (like DVB-H) by enabling tight integration with cellular mobility management and bi-directional capabilities, using the MCCH as the one-way broadcast conduit for all necessary reception parameters.

Classification

Part ofMBSFN
Related approachesMTCHMCE

Release Timeline

Detected Changes Across Releases

from 3GPP Change Requests

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

Rel-17 1 change

In Release 17, a specific correction was made to the MBMS point-to-multipoint Control Channel (MCCH) function. This correction addressed the handling of the PLMN index within the MCCH when it is transmitted on a Secondary Cell (SCell). The change ensures accurate network identification information is provided in this specific configuration.

  • Correction for PLMN index in MCCH of SCell TS 38.331CR4161
Rel-18 2 changes

In Release 18, enhancements were made to the MCCH function to ensure reliable multicast reception for a UE after it reselects to a new cell. This involved specifying the necessary procedures for a device to successfully acquire the MCCH in the new cell. Additionally, editorial corrections were applied to the technical specification text concerning the multicast MCCH to improve clarity and accuracy.

  • Multicast reception after reselection to cell with MCCH TS 38.331CR5153
  • Rapporteur correction on multicast MCCH TS 38.331CR5190

Explore further

Broader topics and technologies where MCCH plays a role.

Defining Specifications

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

SpecificationTitleRelease
TR 21.905 vj00 3GPP Technical Terms and Definitions Rel-19
TS 23.468 vj00 Group Communication System Enablers for LTE Rel-19
TS 23.479 vj00 MBMS API for Mission Critical Services Rel-19
TS 23.792 vg00 MBMS API for Mission Critical Services Rel-16
TS 25.102 vj00 UTRA TDD RF Characteristics Rel-19
TS 25.301 vj00 UE-UTRAN Radio Interface Protocol Architecture Rel-19
TS 25.302 vj00 UTRA Physical Layer Services Rel-19
TS 25.304 vj00 UTRA Idle Mode Procedures Specification Rel-19
TS 25.321 vj00 MAC Protocol Specification for UTRAN Rel-19
TS 25.322 vj00 RLC Protocol Specification Rel-19
TS 25.331 vj00 UTRAN RRC Protocol Specification Rel-19
TS 25.346 vj00 MBMS in UTRA Technical Specification Rel-19
TS 25.401 vj00 UTRAN Overall Architecture Rel-19
TS 25.402 vj00 UTRAN Synchronisation Mechanisms Rel-19
TR 25.912 vj00 Evolved UTRA and UTRAN Technical Report Rel-19
TR 25.931 vj00 UTRAN Signalling Procedures Examples Rel-19
TS 36.300 vj00 E-UTRAN Radio Interface Protocol Architecture Overview Rel-19
TS 36.302 vj00 E-UTRA Physical Layer Services Rel-19
TS 36.304 vj00 UE Idle Mode Procedures in E-UTRA Rel-19
TS 36.322 vj00 E-UTRA Radio Link Control Protocol Specification Rel-19
TS 36.443 vj10 M2 Application Protocol (M2AP) for E-UTRAN Rel-19
TR 36.976 vj00 LTE-based 5G Terrestrial Broadcast Overview Rel-19
TS 38.300 vj00 NG-RAN Overall Description Rel-19
TS 38.304 vj00 UE RRC_IDLE and RRC_INACTIVE Procedures Rel-19
TS 38.321 vj00 NR MAC Protocol Specification Rel-19
TS 38.322 vj00 NR Radio Link Control (RLC) Protocol Rel-19
TS 38.331 vj00 NR Radio Resource Control (RRC) Protocol Specification Rel-19
TS 38.523 vj20 5G NR UE Conformance Testing: Idle/Inactive 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.