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
Detected Changes Across Releases
from 3GPP Change RequestsSpecific changes extracted from the „Change history“ tables of 3GPP specifications (73 CRs across 5 releases). Complements the general historical overview above with the evidence-based evolution of this function.
Studied in Rel-2, normative work from Rel-15.
In Release 15, the MCCH function saw specific corrections and clarifications, primarily concerning the configuration of MBMS reference signals and subframe structures. This included a correction to the EUTRA-MBSFN-SubframeConfig and the introduction of reference signals for MBSFN transmissions with 1.25kHz and 7.5kHz sub-carrier spacing. These updates ensured accurate control channel signaling for point-to-multipoint services.
- Corrections to Unified Access Control TS 38.300CR0036
- Slice Aware Access Control TS 38.300CR0028
- Notification Control TS 38.300CR0108
- Logical channel restrictions clarifications and correction TS 38.300CR0110
- Correction for TCI state in ControlResourceSet TS 38.331CR0558
- Avoiding security risk for RLC UM bearers during termination point change TS 38.331CR0570
+ 11 more changes
In Release 16, the MCCH function was updated with corrections to the Announcement/Quota Period (AQP) for notification control. These changes provided clarifications and fixes to the procedures governing how MBMS service announcements and resource quotas are managed on the control channel. The release focused on ensuring reliable notification delivery without introducing new interfaces or capabilities.
- Mapping of Uplink Traffic to Backhaul RLC Channels TS 38.300CR0255
- CP length and reference signal for MBSFN with sub-carrier spacing of 0.375 kHz and 2.5 kHz TS 36.300CR1322
- Corrections on AQP for notification control TS 38.300CR0328
- Corrections of NR operating with shared spectrum channel access in 38.321 TS 38.321CR0726
- Corrections for NR operating with shared spectrum channel access TS 38.321CR0882
- MAC corrections for NR operating in shared spectrum channel access TS 38.321CR0966
+ 10 more changes
In Release 17, a specific correction was made to the MCCH function regarding the handling of PLMN information for secondary cells. The change addressed the "PLMN index in MCCH of SCell," ensuring accurate network identification signaling for multicast-broadcast services in carrier aggregation scenarios. This refinement provided clearer control plane procedures for UEs receiving MBMS control information on a secondary cell.
- CRS-IM default network configuration assumptions for MBSFN configuration in non-DSS scenario TS 38.331CR3497
- Corrections to control plane procedures for RedCap UEs TS 38.331CR3780
- Channel Access Control for msg1/msgA in FR2-2 TS 38.331CR3827
- Correction to RRC for 71 GHz on channel occupancy duration TS 38.331CR3968
- Correction to mtch-neighbourCell field description TS 38.331CR4015
- Control plane corrections for SDT TS 38.331CR4114
+ 6 more changes
In Release 18, the enhancement for the MCCH function specifically addressed ensuring continuous multicast reception for a User Equipment during cell reselection. The change clarified the procedure for a UE to acquire the MCCH and resume multicast services after reselecting to a new cell. This update provided necessary corrections to the RRC specifications to maintain service continuity.
- Introducing support for Network-Controlled Repeaters to 38.300 TS 38.300CR0685
- Introduction of support for Network Controlled Repeaters TS 38.321CR1554
- Introduction of Network Controlled Repeaters in RRC spec TS 38.331CR4162
- UE capability for Enhanced channel raster TS 38.331CR4445
- Introduction of new capability for intra-band EN-DC channel spacing [Intra-Band_EN-DC_Channelspacing] TS 38.331CR5013
- Clarification to Network-Controlled Repeaters Stage-2 description TS 38.300CR0808
+ 13 more changes
In Release 19, the MCCH function was updated with the introduction of control parameters for the on-demand posSIB request procedure, specifically for the OdPosSIB_Req. This enhancement allows user equipment to request specific positioning system information blocks via the MBMS control channel. No other changes to the MCCH were specified among the provided CR titles for this release.
- Introduction of control parameters for on-demand posSIB request [OdPosSIB_Req] TS 38.300CR1009
- Introduction of 7MHz channel bandwidth TS 38.331CR5308
- Introduction of control parameters for on-demand posSIB request [OdPosSIB_Req] TS 38.331CR5406
- Correction on the description of NG Control Plane TS 38.300CR1110
- Correction to UL Rate Control MAC CE TS 38.321CR2156
- Correction on PC5 Relay RLC channel configuration TS 38.331CR5510
+ 3 more changes
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.
| Specification | Title | Release |
|---|---|---|
| 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 |