Temporary Maximum Media Stream Bit Rate Notification

Description

The Temporary Maximum Media Stream Bit Rate Notification (TMMBN) is a specific RTCP packet format defined originally in IETF RFC 5104 and adopted and profiled by 3GPP for use in its multimedia services, such as the Multimedia Telephony Service for IMS (MTSI) and other conversational services. It functions as part of the Audio-Visual Profile with Feedback (AVPF), which extends RTCP to provide more timely feedback. The TMMBN packet is sent by a media receiver (or a middlebox like a Media Resource Function Processor (MRFP) acting as a receiver) to inform the media sender of a temporary upper limit on the bit rate it should use for a specific media stream, identified by its synchronization source (SSRC).

The structure of the TMMBN RTCP packet includes a header identifying it as a TMMBN (Packet Type=205, FMT=4), followed by the SSRC of the entity issuing the notification (the "notifying source"), and one or more TMMBN FCI (Feedback Control Information) blocks. Each FCI block contains the SSRC of the media source to which the limit applies and the Maximum Bit Rate (MBR) value, expressed in kilobits per second. This MBR represents a temporary constraint, often due to limitations at the receiver (e.g., decoder capability, processing load) or imposed by a network element managing congestion. Crucially, the TMMBN indicates a limit that the notifying source is currently enforcing or capable of handling, not merely a suggestion.

TMMBN operates in conjunction with other RTCP feedback messages, most notably the Temporary Maximum Media Stream Bit Rate Request (TMMBR). The typical workflow involves a receiver sending a TMMBR to request a sender to limit its bit rate. The sender, which may be receiving such requests from multiple receivers in a session, then assesses them and determines the most restrictive limit. It then responds with a TMMBN packet to notify all participants which limit it is currently adhering to and which entity (identified by SSRC) is the "owner" of that limiting constraint. This mechanism prevents multiple receivers from issuing conflicting requests and ensures all parties are aware of the active bit rate bound. In 3GPP systems, TMMBN/TMMBR are essential for dynamic bit rate adaptation in services like video telephony, enabling smooth operation under varying radio conditions, network congestion, or terminal capabilities, as detailed in specs like TS 26.114 (IMS-based media handling) and TS 29.333 (MRFP control).

Purpose & Motivation

TMMBN was developed to address the challenge of efficient and coordinated bit rate management in multiparty real-time multimedia sessions, particularly over bandwidth-variable and potentially congested networks like mobile radio access networks. Prior to standardized feedback mechanisms like AVPF, rate adaptation was less dynamic and often relied on simpler, less informed methods like observing packet loss, which is a reactive and often destructive signal. The need for a proactive, explicit control mechanism became critical with the rise of video telephony and other adaptive media services in 3G and later networks.

The creation of TMMBN, alongside TMMBR, solves the specific problem of multiple constraints in a session. In a conference call or a broadcast scenario, different receivers may have different capabilities (e.g., a smartphone vs. a desktop) or experience different network conditions. Without a notification mechanism, a media sender might be bombarded with conflicting TMMBR requests. TMMBN provides the necessary coordination: it allows the sender to acknowledge and publicize the currently applied limit, informing all participants. This prevents wasteful negotiation loops, reduces control traffic, and creates a shared understanding of the session's media constraints. Its adoption in 3GPP standards was motivated by the requirement for robust Quality of Service (QoS) and quality of experience (QoE) in IMS-based services, ensuring that media bit rates can be dynamically and efficiently tailored to the tightest bottleneck in the end-to-end path, whether at the receiver, in the network, or at a media processing node.