8B Transparent Delivery Method

26.3463GPPMultimedia Broadcast/Multicast Service (MBMS)Protocols and codecsRelease 17TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

8B.1 Introduction

The MBMS transparent delivery method shall be used by the BM-SC to transmit downstream service content received over xMB-U ([143]) from the Content Provider when the Session Type property, as described in table 5-2 of TS 26.348 [143], is set to Transport-Mode. The transparent delivery method delivers application data units as part of UDP or IP flows over an MBMS bearer to the UE. This delivery method complements the download delivery method and streaming delivery method and is particularly useful for multicast and broadcast of IP-based services for which the media codecs and application protocols are defined outside of this specification.

The BM-SC receives Application Data Units (ADUs) from the content provider, typically provided as UDP/IP packets and forwards them to the destination multicast IP address and port number. Both IPv4 and IPv6 may be used by the transparent delivery method.

Transparent delivery methods may be used within MBMS User Services, where the session description is delivered as a fragment of a User Service Description, or they may be used independently, where the content provider will announce the session via external means.

An MBMS transparent delivery session may be operated in a forward-only or in a proxy mode, as indicated in Table 5-3 of TS 26.348 [143]. In the forward-only mode, the transport protocol on top of IP is opaque to the MBMS system and the session announcement may be handled by the content provider itself. In the proxy mode, the UDP packet payload of the UDP streams is opaque to the MBMS session and an MBMS Client is expected to make the UDP Payloads available to an application, without further knowledge on the content.

In the proxy mode is used, the transport protocol and session description are described in clauses 8B.2 and 8B.3.

If requested by the content provider, the BM-SC shall apply ROHC [137] to compress the UDP/IP headers of the encapsulated source datagrams. Note that the MBMS Gateway might also apply ROHC on the resulting UDP flow, but that does not include the encapsulated UDP datagrams. ROHC is described in section 8B.4.

The content provider may also request the application of FEC over broadcast. FEC is described in section 8B.5.

8B.2 Transport protocol

8B.2.1 General

When the proxy mode is used, the transport protocol shall be UDP/IP.

The application layer protocol on top of UDP/IP is out of scope of this specification. However, examples for application layer protocols are RTP, packetized MPEG-2 TS or other UDP-based streams. Generally, a sequence of Application Data Units (ADUs), i.e. unit of source data provided as payload to the transport layer, can be delivered by this transport protocol. As an example, this framework can be applied to RTP flows as well.

ADUs may be encapsulated into frames by a transport framing protocol prior to transmission using the UDP protocol, in order to provide additional transport functionality.

A UE that does not understand the transport framing protocol shall discard the transport framing header or trailer, and recalculate the UDP checksum prior to forwarding ADU to the receiver. The usage of the transport framing protocol is signalled by the presence of the "mbms-framing" attribute in a media session of the SDP. If used, all datagrams of the UDP flow shall be framed using the same transport framing protocol.

If transport framing is used, the BM-SC shall encapsulate exactly one ADU in an IP/UDP multicast packet where the ADU carried as a UDP payload is appended or prepended by the transport framing trailer/header as shown in Figure 8B-3.

Note: The content provider shall be aware of the path MTU and shall not generate ADUs that do not fit into a single IP/UDP datagram.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IP Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| UDP Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| … |
| Transport Framing Protocol Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Transport Payload |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Transport Framing Protocol Trailer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 8B-3 Transport Framing Protocol Header/Trailer

The transport framing protocol trailer/header shall be of constant length for all packets of the same UDP flow. The length of the transport framing protocol trailer/header shall be signalled to the UE as part of the "mbms-framing" attribute of the session description of the transparent session.

Note: The current specification does not define a transport framing protocol. Instead, it defines the framework for this protocol to ensure backwards compatibility by future versions of the protocol.

If the transport framing protocol is used and the receiver does not recognize the version of the transport protocol, it shall discard the trailer/header. The sender shall ensure that simple discarding by a receiver that does not support the indicated version of the transport framing protocol does not impact the integrity and consistency of the payload.

The UDP checksum shall be recalculated after any transport framing is performed and also after that transport framing is terminated.

8B.3 Session Description

8B.3.1 Introduction

When the Proxy mode of the Transparent delivery method is used, the BM-SC shall act as the source for the multicast traffic. The SDP for the transparent delivery method shall be created by the BM-SC and may be shared as a fragment of the service announcement or sent to the content provider, if the latter selects to perform service announcement by itself.

8B.3.2 SDP Parameters

8B.3.2.1 General

The Session Description of an MBMS Transparent session includes the following parameters:

– The sender IP address

– Session timing information

– Mode of the MBMS bearer

– The TMGI of the MBMS Bearer

– The bitrate of the session

– For each UDP flow:

– The destination IP address and port number for each media line

– An indication of the usage of a transport framing protocol or not

– The protocol ID for each media session

– Any other parameters of the transported flow for each media

8B.3.2.2 Sender IP address

There shall be exactly one source IP address per media description within the SDP. The source IP address shall be defined according to the source-filter attribute ("a=source-filter:") [15] for both IPv4 and IPv6 sources, with the following exceptions:

1. exactly one source address may be specified by this attribute such that exclusive-mode shall not be used and inclusive-mode shall use exactly one source address in the <src-list>.

2. there shall be exactly one source-filter attribute per complete MBMS transparent session SDP description, and this shall be in the session part of the session description (i.e. not per media).

3. The * value shall be used for the <dest-address> subfield.

8B.3.2.3 Destination IP address and port number

The destination IP address shall be defined using the "connection data" field ("c=") of [14]. The destination port number shall be defined according to the <port> sub-field of the media announcement field ("m=") of [14].

In case multiple media sessions are present, all of them shall share the same destination multicast IP address. The "c=" parameter shall be a session level attribute.

8B.3.2.4 Session Timing Parameters

An MBMS transparent session start and end times shall be provided according to the SDP timing field ("t=") – [14].

8B.3.2.5 Mode of MBMS bearer per media

The MBMS bearer mode declaration attribute shall be used for MBMS transparent sessions, as defined in sub-clause 7.3.2.7.

8B.3.2.6 MBMS Bearer Information

The SDP shall contain exactly one MBMS bearer mode attribute (defined in section 7.3.2.7) at session level. It may contain an alternative TMGI attribute as defined in section 7.3.2.12.

8B.3.2.7 Bandwidth Specification

The maximum bit-rate required by a UDP flow may be specified using the "AS" bandwidth modifier [14] on media level. The Application Specific (AS) bandwidth for a transparent session shall be the largest sum of the sizes of all packets transmitted during any one second long period of the session, expressed as kilobits. The size of a packet shall include the complete packet, i.e. IP, UDP and FLUTE headers, and the data payload.

8B.3.2.8 Transport Framing Protocol

The "mbms-framing-header" or "mbm-framing-trailer" attributes, if present at the media level, indicate that MBMS transport framing protocol is used and provides a version number and length field for the transport framing header or trailer, respectively.

The ABNF sytax for the "mbms-framing-header" and the "mbms-framing-trailer" attributes is as follows:

mbms-framing=("a=mbms-framing-header" / "a=mbms-framing-trailer") ":" SP version SP length SP parameters
version = 1*2DIGIT
length = 1*2DIGIT
parameters = *(parameter [";"])
parameter = name "=" value
name = *(ALPHA / DIGIT / "|" / "-" / "_")
value = *(ALPHA / DIGIT / "|" / "-"/ "_")

8B.4 ROHC for Transparent Delivery Method

8B.4.1 General

If ROHC is used in a Transparent delivery session, then the following conditions shall apply:

– Only the U-mode shall be used throughout the lifetime of the session. Other modes shall not be used.

– A single ROHC channel per Transparent delivery session shall be used.

– Exactly one of the following alternatives as specified in [138] shall be used:

– the RTP/UDP/IP profile with identifier 0x0001,

– the UDP/IP profile with identifier 0x0002, or

– the uncompressed IP profile with identifier 0x0000.

– UDP flow encoded with profile 0x0001 or profile 0x0002 shall use different context IDs.

– A common context ID may be used for all flows encoded with profile 0x0000.

– The LARGE_CIDS flag may be set to true. LARGE_CIDS value can be derived from the value from the MAX_CID flag.

– ROHC segmentation shall not be used and the MRRU value shall be set to 0

8B.4.2 ROHC Negotiation

ROHC usage shall be indicated by the "a=3gpp-rohc:1" attribute in the session description.

8B.4.3 ROHC Operation

The BM-SC shall send IR type packets periodically.

8B.5 FEC

8B.5.1 General

If FEC protection is requested by the content provider, the BM-SC shall use the MBMS FEC scheme as specified by section 8.2.2. The FEC protection covers UDP payload and can be applied in both the forward only and the proxy modes of the Transparent delivery method.