Simulcast Stream

Description

A simulcast stream is the transport-level realization of a simulcast format. In a simulcast session, the sender transmits multiple RTP streams, each carrying a different encoded version of the same media content. Each of these streams is a simulcast stream. The stream is characterized by its own Synchronization Source (SSRC) identifier, its own RTP payload type (which maps to a specific simulcast format in SDP), and its own sequence number and timestamp space. This independence allows the receiver to process each stream separately and switch between them without affecting other streams.

The concept is defined in 3GPP TS 26.114 and TS 26.980, which specify the media handling for IMS multimedia telephony and WebRTC interworking. A simulcast stream is typically associated with a specific encoding quality, such as a low-resolution, medium-resolution, or high-resolution version. The sender may generate these streams using a single encoder capable of multiple outputs or multiple independent encoders. The streams are transmitted in parallel over the same or different transport flows, depending on network configuration.

In the protocol stack, each simulcast stream is an RTP session or part of a multi-stream RTP session. The RTP header includes the payload type, which identifies the simulcast format, and the SSRC, which identifies the stream. The receiver uses the SSRC to distinguish packets from different streams and the payload type to select the appropriate decoder. The SDP negotiation includes parameters for each stream, such as the 'a=simulcast' attribute (RFC 8853) that lists the desired streams and their directions. The 'a=rid' attribute (RFC 8851) may also be used to identify each stream with a unique identifier.

Key components of a simulcast stream include the encoder, the RTP packetizer, the transport bearer, and the receiver's depacketizer and decoder. The encoder produces the encoded frames for a specific format. The packetizer encapsulates the frames into RTP packets, setting the payload type and SSRC. The transport bearer, often a dedicated QoS flow in 5G or a dedicated bearer in LTE, carries the packets with appropriate priority. The receiver's depacketizer extracts the encoded frames and forwards them to the decoder for the selected stream. The receiver may implement stream switching logic to change the active stream based on feedback or local policy.

In terms of network architecture, simulcast streams are handled by the IMS core for signaling and by the access network for transport. Media servers, such as the Media Resource Function (MRF) in IMS or a WebRTC gateway, may terminate and forward simulcast streams. For example, in a conference, the server might receive multiple simulcast streams from a sender and selectively forward one stream to each receiver, based on their capabilities. This selective forwarding is a key advantage of simulcast, as it avoids transcoding and reduces server load.

The simulcast stream concept is also used in 5G MBS and in WebRTC-based services. In 5G MBS, simulcast may be used to deliver different quality versions to different user groups. In WebRTC, simulcast is widely used for video conferencing to adapt to heterogeneous endpoints. The 3GPP specifications ensure that these streams are interoperable with IETF standards, enabling seamless integration.

Overall, the simulcast stream is the fundamental unit of transport in a simulcast session, providing the flexibility and scalability needed for modern adaptive media services.

Purpose & Motivation

The simulcast stream concept exists to provide a concrete, transport-level mechanism for delivering multiple quality versions of the same media content. Before simulcast, adaptive streaming often relied on a single stream with scalable coding or on complex transcoding at intermediate nodes. Scalable coding had limited adoption and high complexity, while transcoding introduced latency, cost, and quality degradation. Simulcast streams solve these problems by sending independent, self-contained streams that can be selected by the receiver or an intermediate server without transcoding.

The primary motivation is to support heterogeneous receivers in a session. For example, in a multiparty video conference, participants may have different screen sizes, processing capabilities, and network bandwidths. A single high-quality stream would be wasteful for low-end devices, while a single low-quality stream would be unsatisfactory for high-end devices. By sending multiple simulcast streams, the sender can cater to all participants simultaneously. The receiver can choose the stream that best matches its capabilities and network conditions, and can switch dynamically as conditions change.

Another motivation is to enable efficient network utilization. Simulcast streams can be transmitted over the same bearer or over separate bearers with different QoS. The network can prioritize streams based on their importance or the receiver's subscription. In 5G, network slicing and QoS flows can be used to provide differentiated treatment to simulcast streams. This ensures that critical streams (e.g., the base layer) are delivered reliably, while enhancement streams may be delivered on a best-effort basis.

Historically, simulcast was first standardized in 3GPP Release 13, aligning with IETF work on simulcast in WebRTC (e.g., RFC 8853). Since then, it has been maintained and refined in subsequent releases, with improvements in codec support, signaling, and interworking. The concept has proven essential for WebRTC-IMS interworking, where WebRTC endpoints use simulcast and need to interoperate with IMS endpoints that may not support it. The 3GPP specifications define how to negotiate and transport simulcast streams in these scenarios.