MTK

MBMS Traffic Key

Security →
Introduced in Rel-8 Also in: Services, Security

MTK is the cryptographic key used to encrypt broadcast and multicast traffic in MBMS systems, ensuring the confidentiality and integrity of content delivered to multiple users simultaneously.

Category
Security
Introduced
Rel-8
Where
Core Network › 5G Core
Also touches
2 segments
Specifications
7 specs
MTK Description Purpose Related Classification Detected Changes Specifications

Description

The MBMS Traffic Key (MTK) is a fundamental security component within the 3GPP Multimedia Broadcast Multicast Service (MBMS) architecture, specifically designed for securing point-to-multipoint content delivery. It functions as a symmetric encryption key, meaning the same key is used by the network to encrypt the broadcast traffic and by authorized user equipment (UE) to decrypt it. The MTK is applied at the application layer, typically within the MBMS User Service layer or the BM-SC (Broadcast Multicast Service Centre), to protect the actual media content such as video streams, file downloads, or data broadcasts. Its primary role is to ensure that only subscribers who are entitled to receive a specific MBMS service can access the content, thereby enforcing service-level confidentiality.

The generation, distribution, and management of the MTK are orchestrated by the MBMS security framework defined in 3GPP specifications. The key is generated by the BM-SC, which acts as the service and security anchor for MBMS. The MTK is not sent directly over the air to UEs in plaintext. Instead, it is securely delivered using a key hierarchy. The MTK itself is encrypted using another key, the MBMS Service Key (MSK), which is uniquely provisioned to each subscribing UE or group of UEs. This encrypted MTK, along with other service metadata, is distributed via the MBMS User Service Description (USD) or similar service announcement mechanisms. When a UE wishes to access an MBMS service, it uses its pre-provisioned MSK to decrypt the received MTK. Once decrypted, the UE stores the MTK locally and uses it to decrypt the incoming broadcast traffic for the duration of the key's validity or the service session.

The lifecycle of an MTK includes generation, activation, usage, and expiration or renewal. To maintain security, MTKs are typically changed periodically (e.g., per service session, per content item, or at timed intervals) to limit the impact of any potential key compromise. The specifications detail the procedures for key renewal, where a new MTK is generated and distributed, often before the old key expires, to allow for seamless service continuity. The entire process is designed to be scalable for mass delivery, as the same MTK can be used by millions of devices receiving the same broadcast, while the individual MSK provides personalized access control. The integrity of the key distribution messages is also protected, often through digital signatures from the BM-SC, to prevent tampering.

Within the broader MBMS architecture, the MTK works in conjunction with other keys like the MSK and the MUK (MBMS User Key). The BM-SC uses the Gi/Sgi-mb interface for service provisioning and the Gmb interface for signaling with the core network. The encrypted traffic flows from the BM-SC through the core network (e.g., via the MBMS Gateway) to the radio access network (e.g., eNBs or gNBs in LTE/5G) for broadcast over a Multicast-Broadcast Single Frequency Network (MBSFN) area. The UE's MBMS client, upon successful authentication and key derivation, accesses the MTK and configures its decryption engine to process the received broadcast packets. This mechanism is crucial for commercial services like mobile TV, public safety alerts, and software updates over-the-air, where content protection is a mandatory requirement.

Purpose & Motivation

The MBMS Traffic Key was introduced to address the critical need for securing broadcast and multicast content in cellular networks. Prior to MBMS, unicast delivery was secure but inefficient for popular content sent to many users, as it consumed excessive network resources. Simple broadcast without encryption, used in some early technologies, lacked any content protection, making it unsuitable for premium or private services. The MTK enables efficient, large-scale content delivery while introducing a robust security layer that was previously absent or inadequate in broadcast scenarios.

The creation of MTK was motivated by the commercial rollout of Multimedia Broadcast Multicast Service (MBMS), starting in 3GPP Release 6, which aimed to enable services like mobile television, group communications, and file distribution. Service providers and content owners required guarantees that only paying subscribers could access the broadcast streams, preventing revenue loss from piracy. Furthermore, for public safety and enterprise applications, ensuring that sensitive broadcast information (e.g., emergency alerts) is received only by authorized personnel is paramount. The MTK, as part of a standardized key management hierarchy, provided a scalable solution to these requirements.

It solves the problem of how to efficiently manage encryption keys for potentially millions of simultaneous receivers. Distributing unique keys to each device for the traffic itself would be impractical. The MTK's design as a common traffic key, protected by individually assigned service keys (MSKs), elegantly balances scalability with security. This approach limits the exposure of the critical MTK, as it is always transmitted in an encrypted form, and allows for periodic key updates to mitigate long-term key compromise risks. Its specification across multiple releases ensures backward compatibility and adaptation to evolving MBMS architectures, including enhancements for LTE Broadcast (eMBMS) and 5G Broadcast.

Classification

Part ofMBMS
Specific typesMRKMSCCK
Related approachesBM-SCMUK

Detected Changes Across Releases

from 3GPP Change Requests

Specific changes extracted from the „Change history“ tables of 3GPP specifications (14 CRs across 4 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 2 changes

In Release 15, the MTK (MBS Traffic Key) function was introduced as part of the new MBS (Multicast/Broadcast Service) architecture, which supports traffic segregation and the SAND (Service and Network Discovery) framework for MBMS. This key is used within the security context for MBS traffic delivery, which includes the new 5GC Shared MBS traffic delivery method for efficient distribution and the 5GC Individual MBS traffic delivery method for mobility support to non-supporting RAN nodes.

  • Support for SAND for MBMS TS 26.946CR0015
  • Support for Traffic Segregation TS 24.501CR0476
Rel-16 2 changes

In Release 16, the MTK function was enhanced as part of the new 5G Multicast/Broadcast Service (MBS) architecture. The specification introduced the MB-UPF (Multicast/Broadcast User Plane Function) and defined distinct traffic delivery methods, specifically the 5GC Shared MBS traffic delivery method and the 5GC Individual MBS traffic delivery method, which the MTK secures. Furthermore, the release specified the MB-SMF's role in controlling the MB-UPF for multicast data transport using these new delivery methods.

  • Missing XML Data Type for Attributes in MBMS USD TS 26.346CR0658
  • ATSSS Non-MPTCP traffic support TS 24.501CR1948
Rel-17 5 changes

In Release 17, clarifications were provided for the processing of the MBS Traffic Key (MTK) or MBS Service Key (MSK), as indicated by a dedicated Change Request. This work was part of broader enhancements for Multicast/Broadcast Service (MBS), which included clarifications on traffic handling in the MBSTF for interworking with E-UTRAN MBMS and refinements to traffic usage reporting and charging procedures.

  • Interworking with MBMS over E-UTRAN for broadcast service TS 23.247CR0008
  • clarification on PDR and FAR in A-UPF for MBS data traffic in individual delivery TS 23.247CR0068
  • Clarifications on traffic usage reporting and charging TS 23.247CR0117
  • Clarification on the traffic handling in MBSTF for interworking TS 23.247CR0129
  • CR on MTK or MSK processing TS 23.247CR0139
Rel-19 5 changes

In Release 19, the MTK (MBS Traffic Key) function was enhanced through the introduction of In-session Unicast Repair for MBMS Object Distribution, allowing for the repair of missing data within an ongoing session via unicast delivery. Furthermore, improvements were made to Time Synchronization for MBMS, ensuring more precise alignment of multicast/broadcast content delivery across the network. These updates complemented the existing 5GC Shared and Individual MBS traffic delivery methods, refining the reliability and synchronization of the MBS service.

  • Support of QoS differentiation of traffic for N3GPP device behind UE or 5G-RG TS 24.501CR6618
  • [AMD_PRO-MED] In-session Unicast Repair for MBMS Object Distribution TS 26.346CR0677
  • Improved Time Synchronization for MBMS TS 26.346CR0672
  • Determine which PDU session to use for non-3GPP device traffic TS 24.501CR7023
  • Clarifications on the QoS differentiation of traffic for non-3GPP device(s) TS 24.501CR7031

Explore further

Broader topics and technologies where MTK plays a role.

Defining Specifications

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

SpecificationTitleRelease
TS 23.247 vj30 5G Multicast/Broadcast Service Architecture Rel-19
TS 24.501 vj50 5G NAS Protocols Specification Rel-19
TS 26.346 vj20 MBMS User Services Media Codecs & Protocols Rel-19
TR 26.946 vj00 MBMS User Services Overview Rel-19
TS 31.102 vj40 USIM Application Specification Rel-19
TS 33.246 vj00 MBMS Security Specification Rel-19
TS 33.888 vc10 Security Study for Group Communication in LTE Rel-12