Content for TS 26.346 Word version: 19.1.0

0… 4… 5… 5.3… 6 7… 7.3… 8… 8A… 8B… 9… 9.4… 10… 11… 12… A B… C… D… G… H… J… K… L… M…

8B.1 Introduction 8B.2 Transport protocol 8B.3 Session description 8B.4 ROHC for transparent delivery method 8B.5 FEC
...

8B Transparent delivery method |R14| p. 107

8B.1 Introduction p. 107

The MBMS transparent delivery method shall be used by the BM-SC to transmit downstream service content received over xMB-U (TS 26.348) from the Content Provider when the Session Type property, as described in Table 5-2 of TS 26.348, 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. 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 per RFC 5795 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 clause 8B.4.

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

8B.2 Transport protocol p. 108

8B.2.1 General p. 108

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.

Copy of original 3GPP image for 3GPP TS 26.346, Fig. 8B-3: Transport framing protocol header/trailer

Figure 8B-3: Transport framing protocol header/trailer
(⇒ copy of original 3GPP image)

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.

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 p. 109

8B.3.1 Introduction p. 109

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 p. 109

8B.3.2.1 General p. 109

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 bit rate 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 p. 109

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:") RFC 4570 for both IPv4 and IPv6 sources, with the following exceptions:

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>.
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).
The * value shall be used for the <dest-address> subfield.

8B.3.2.3 Destination IP address and port number p. 110

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

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 p. 110

An MBMS transparent session start and end times shall be provided according to the SDP timing field ("t=") specified in RFC 4566.

8B.3.2.5 Mode of MBMS bearer per media p. 110

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

8B.3.2.6 MBMS Bearer information p. 110

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

8B.3.2.7 Bandwidth specification p. 110

The maximum bit rate required by a UDP flow may be specified using the "AS" bandwidth modifier specified in RFC 4566 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 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 p. 110

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 |R15| p. 110

8B.4.1 General p. 110

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 RFC 3095 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 p. 111

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

8B.4.3 ROHC operation p. 111

The BM-SC shall send IR type packets periodically.

8B.5 FEC |R15| p. 111

8B.5.1 General p. 111

If FEC protection is requested by the content provider, the BM-SC shall use the MBMS FEC scheme as specified in clause 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.