8 Streaming delivery method

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

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

8.1 Introduction

The purpose of the MBMS streaming delivery method is to deliver continuous multimedia data (i.e. speech, audio and video) over an MBMS bearer. Using MBMS Streaming delivery on unicast is defined in clause 8.5. This delivery method complements the download delivery method which consists of the delivery of files. The streaming delivery method is particularly useful for multicast and broadcast of scheduled streaming content.

8.2 Transport protocol

RTP is the transport protocol for MBMS streaming delivery. RTP provides means for sending real-time or streaming data over UDP and is already used for the transport of PSS in 3GPP. RTP provides RTCP for feedback about the transmission quality. The transmission of RTCP packets in the downlink (sender reports) is allowed. In this version of the specification, RTCP RR shall be turned off by SDP RR bandwidth modifiers. Note that in the context of MBMS detection of link aliveness is not necessary.

8.2.1 RTP payload formats for media

The RTP payload formats and corresponding MIME types are closely aligned with those defined in PSS [47] . For RTP/UDP/IP transport of continuous media the following RTP payload formats shall be used:

– AMR narrow-band speech codec (see sub-clause 10.2) RTP payload format according to RFC 4867 [33]. A MBMS client is not required to support multi-channel sessions.

– AMR wideband speech codec (see sub-clause 10.2) RTP payload format according to RFC 4867 [33]. A MBMS client is not required to support multi-channel sessions.

– Extended AMR-WB codec (see sub-clause 10.3) RTP payload format according to [34].

– Enhanced aacPlus codec (see sub-clause 10.3) RTP payload format and MIME types according to RFC 3640 [41], namely the Low Bit-Rate AAC or the High Bit-Rate AAC modes.

– H.264 (AVC) video codec (see sub-clause 10.5) RTP payload format according to [35]. An MBMS client supporting H.264 (AVC) is required to support all three packetization modes: single NAL unit mode, non-interleaved mode and interleaved mode. For the interleaved packetization mode, an MBMS client shall support streams for which the value of the "sprop-deint-buf-req" MIME parameter is less than or equal to MaxCPB * 1000 / 8, inclusive, in which "MaxCPB" is the value for Video Coding Layer (VCL) parameters of the H.264 (AVC) profile and level in use, as specified in [43].

– H.265 (HEVC) [112] video codec (see clause 10.5) RTP payload format according to [113].

– Timed Text (see sub-clause 10.10) RTP payload format according to [93].

8.2.2 FEC mechanism for RTP

8.2.2.0 General

The "MBMS FEC scheme" is the fully-specified FEC scheme defined in [106], section 6 with ID 1.

The source flows for the MBMS FEC scheme are UDP flows including RTP, RTCP, SRTP and MIKEY packets. The payload of such UDP packets constitute an Application Data Unit (ADU) as defined in RFC6363 [107]. The source data flow with which the ADUs are associated is the UDP flow identity of the corresponding UDP flow.

A UE that supports MBMS User Services shall support a decoder for the "MBMS FEC scheme". The use of MBMS FEC by the sender is recommended, but it is permitted not to use it. In the case where the FEC is not used by the sender, the FEC Layer should not be used (i.e. RTP is mapped onto UDP directly).

The mechanism does not place any restrictions on the source data which can be protected together, except that the source data is carried over UDP. The data may be from several different UDP flows that are protected jointly.

A UE supporting the streaming delivery method shall support the packet format for FEC packets..

If any FEC source packets have been lost, but sufficient FEC source and FEC repair packets have been received, FEC decoding can be performed to recover the FEC source block. The original packets UDP payload and UDP flow identity can then be extracted from the source block and provided to the upper layer. If not enough FEC source and repair packets were received, only the original packets that were received as FEC source packets will be available. The rest of the original packets are lost.

If a UE that supports MBMS User Services receives a mathematically sufficient set of encoding symbols generated according to the encoder specification in RFC5053 [91], section 5.3, for reconstruction of a source block, then the decoder shall recover the entire source block. Note that the example decoder described in [91] clause 5.5 fulfils this requirement.

Note that the receiver must be able to buffer all the original packets and allow time for the FEC repair packets to arrive and FEC decoding to be performed before media playout begins. The min-buffer-time parameter specified in sub-clause 8.3.1.8 helps the receiver to determine a sufficient duration for initial start-up delay.

The protocol architecture is illustrated in figure 11.

Figure 11: FEC mechanism for the streaming delivery method interaction diagram

Figure 11 depicts how one or more out of several possible packet flows of different types (Audio, video, text RTP and RTCP flows, MIKEY flow) are sent to the FEC layer for protection. The source packets are modified to carry the FEC payload ID and a new flow with repair data is generated. The receiver takes the source and repair packets and buffers them to perform, if necessary, the FEC decoding. After appropriate buffering received and recovered source packets are forwarded to the higher layers. The arrows in the figure indicate distinct data flows.

8.2.2.1 Sending Terminal Operation (Informative)

It is assumed that the sender has constructed or received original data packets for the session. These may be RTP, RTCP, MIKEY or other UDP packets. The following procedures are based on the UDP payload and the identity of the UDP flow. The UDP payload constitutes and ADU according to RFC6363 [107] and the identity of the UDP flow is the integer identifier associated with the identifier of the ADU flow.

In order to FEC protect a sequence of original data packets, the sender constructs a source block as specified in RFC6681 [106], section 5 to which the FEC algorithm is to be applied, and includes the original source packet data within FEC source packets. The following operations describe a possible way to generate compliant FEC source packet and FEC repair packet streams:

1. Each original packet is placed in the source block. In doing so, the Source FEC Payload ID information to be included in the FEC payload ID of the FEC source packet can be determined. In the source block the identity of the packet’s flow is marked using the Flow ID. See RFC6681 [106], section 5 for details.

2. The FEC source packet is constructed according to sub-clause 8.2.2.4. The identity of the original flow is maintained by the source packet through the use of the destination UDP port number and destination IP address, which has been advertised (for example using SDP), as carrying FEC source packets generated from an original stream of a particular protocol (e.g. RTP, RTCP, SRTP, MIKEY etc.). See sub-clause 8.2.2.13.

3. The generated FEC source packet is sent using UDP.

When a source block is complete, the FEC encoder generates encoding symbols and places these symbols into FEC repair packets, to be conveyed to the receivers. These repair packets are sent using normal UDP procedures to a unique destination port to separate it from any of the source packet flows.

In particular cases it may be advantageous not to use FEC for some source blocks and to signal this to the receiver. In this case the sender may send one or more empty repair packets consisting exclusively of the Repair FEC Payload ID. This will be helpful in particular for selective FEC where some of the source blocks (e.g. consisting of reference video frames) are FEC protected while others (e.g. consisting exclusively of non-reference frames) will not be protected.

8.2.2.2 Receiving Terminal Operation (Informative)

The following describes a possible receiver algorithm, when receiving an FEC source or repair packet:

1. If a FEC source packet is received (as indicated by the UDP port on which it was received):

a. The original source packet is reconstructed by removing the Source FEC Payload ID. The resulting packet is buffered to allow time for the FEC repair.

b. The resulting packet is placed into the source block according to the information in the Source FEC Payload ID and the source block format described in [106], section 5. The UDP port the packet was received on is used to determine the Flow ID written into the source block.

2. If an FEC repair packet is received (as indicated by the UDP port), the contained encoding symbols are placed into an FEC encoding block according to the Repair FEC Payload ID. In case the received FEC repair packet is empty, there are no repair symbols to be placed in the FEC encoding block.

3. If at least one source packet is missing, then FEC decoding may be desirable. The FEC decoder determines if the encoding block constructed in steps 1 and 2 contains enough symbols from the source and repair packets for decoding and, if so, performs the decoding operation. If only empty FEC repair packets are received, the receiver may start immediately some procedures to conceal the effect of missing media data.

4. Any missing source packets that were reconstructed during the decoding operation are then buffered as normal received packets (see step 1a above).

Note that the above procedure may result in that not all original packets are recovered, and they must simply be marked as being lost.

Obviously, buffering and packet re-ordering are required to insert any reconstructed packets in the appropriate place in the packet sequence if that is necessary according to the used higher layer protocol (RTP, RTCP or MIKEY). To allow receivers to determine the minimal start-up buffering requirement for FEC decoding, the min-buffer-time parameter indicates a minimum initial buffering time that is sufficient regardless of the position of the stream in which the reception starts.

8.2.2.3 (Void)

8.2.2.4 Packet format for FEC source packets

The packet format for FEC source packets as defined in RFC6363 [107], section 5.3, shall be used to encapsulate an original UDP packet.

The destination IP address and UDP port shall be set as indicated in the session control signalling. This ensures that the receiver can determine which protocols and FEC Payload ID formats are used for this flow. The remaining fields in the IP and UDP headers shall be set according to their specifications.

The Source FEC Payload ID shall be constructed according to RFC 6681 [106], section 6.2.2.

The FEC Source packets over IP and UDP are indicated to be used for a flow by using one of the SDP protocol identifiers "UDP/MBMS-FEC/RTP/AVP", "UDP/MBMS-FEC/RTP/SAVP" depending on the upper layer protocol RTP/AVP or RTP/SAVP respectively. If MIKEY is FEC protected and encapsulated in source packets, then it is indicated in the security description using the fecProtection element and the destination IP address.

8.2.2.5 Packet Format for Repair packets

The packet format for FEC repair packets as defined in RFC6363 [107], section 5.4 shall be used for repair packets.

The UDP payload consists of the Repair FEC Payload ID, and zero, one or more repair symbols. The format of the Repair FEC payload ID is defined in clause [106], section 6.2.3.

The repair packet sent over IP and UDP is indicated in the SDP using the protocol identifier "UDP/MBMS-REPAIR".

8.2.2.6 Void

8.2.2.7 FEC block Construction algorithm and example (informative)

This section provides an example how to use the methods in RFC6363 [107] and RFC6681 [106] to generate a source block.

When the original UDP packet is placed into the source block, the value of the UDP flow identifier, F, followed by the value of the UDP payload length, L, are first written as a single byte and two-byte value in network byte order (i.e. with high order byte first) respectively into the first available bytes in the source block, followed by the UDP packet payload itself (i.e. not including the IP/UDP headers). Following this, if the next available byte is not the first byte of a new symbol, then padding bytes up to the next symbol boundary shall be included using the value 0 in each byte. As long as any source UDP packets remain to be placed, the procedure is repeated starting each UDP flow identifier at the start of the next encoding symbol.

An example of forming a source block is given in figure 14 below. In this example, three UDP packets of lengths 26, 52 and 103 bytes have been placed into a source block with symbol size T = 16 bytes. The first two packets are from UDP flow 0 and the third from UDP flow 1. Each entry in Figure 14 is a byte and the rows correspond to the source symbols and are numbered from 0 to 12. B_i,j denotes the (j+1)th byte of the (i+1)th UDP packet.

B0,0

B0,1

B0,2

B0,3

B0,4

B0,5

B0,6

B0,7

B0,8

B0,9

B0,10

B0,11

B0,12

B0,13

B0,14

B0,15

B0,16

B0,17

B0,18

B0,19

B0,20

B0,21

B0,22

B0,23

B0,24

B0,25

B1,0

B1,1

B1,2

B1,3

B1,4

B1,5

B1,6

B1,7

B1,8

B1,9

B1,10

B1,11

B1,12

B1,13

B1,14

B1,15

B1,16

B1,17

B1,18

B1,19

B1,20

B1,21

B1,22

B1,23

B1,24

B1,25

B1,26

B1,27

B1,28

B1,29

B1,30

B1,31

B1,32

B1,33

B1,34

B1,35

B1,36

B1,37

B1,38

B1,39

B1,40

B1,41

B1,42

B1,43

B1,44

B1,45

B1,46

B1,47

B1,48

B1,49

B1,50

B1,51

103

B2,0

B2,1

B2,2

B2,3

B2,4

B2,5

B2,6

B2,7

B2,8

B2,9

B2,10

B2,11

B2,12

B2,13

B2,14

B2,15

B2,16

B2,17

B2,18

B2,19

B2,20

B2,21

B2,22

B2,23

B2,24

B2,25

B2,26

B2,27

B2,28

B2,29

B2,30

B2,31

B2,32

B2,33

B2,34

B2,35

B2,36

B2,37

B2,38

B2,39

B2,40

B2,41

B2,42

B2,43

B2,44

B2,45

B2,46

B2,47

B2,48

B2,49

B2,50

B2,51

B2,52

B2,53

B2,54

B2,55

B2,56

B2,57

B2,58

B2,59

B2,60

B2,61

B2,62

B2,63

B2,64

B2,65

B2,66

B2,67

B2,68

B2,69

B2,70

B2,71

B2,72

B2,73

B2,74

B2,75

B2,76

B2,77

B2,78

B2,79

B2,80

B2,81

B2,82

B2,83

B2,84

B2,85

B2,86

B2,87

B2,88

B2,89

B2,90

B2,91

B2,92

B2,93

B2,94

B2,95

B2,96

B2,97

B2,98

B2,99

B2,100

B2,101

B2,102

Figure 14: Source block consisting of 3 source UDP packets of lengths 26, 52 and 103 bytes.

8.2.2.8 Void

8.2.2.9 Source FEC Payload ID

The Source FEC payload ID shall be the Source FEC Payload ID format A in section 6.2.2 of RFC6681 [106].

8.2.2.10 Repair FEC payload ID

The Repair FEC Payload ID shall be the Repair FEC Payload ID format A in section 6.2.3 of RFC6681 [106].

8.2.2.10a FEC Object Transmission information

The FEC Object Transmission information consists of:

– the maximum source block length, in symbols

– the symbol size, in bytes

The FEC Object Transmission information shall be the first four octets of the FEC Scheme Specific Information in section 6.2.1.2 of RFC6681 [106].

NOTE: This corresponds to Payload ID Format A in RFC6681 [106] as the last octet of FEC Scheme Specific Information is omitted.

The Source Block Length signalled within the Repair FEC Payload ID of any packet of a stream shall not exceed the Maximum Source Block Length signalled within the FEC Object Transmission Information for the stream.

The FEC Object Transmission Information shall be communicated as described in sub-clause 8.2.2.14. Note, the FEC Object Transmission Information is only communicated in SDP.

8.2.2.11 Hypothetical FEC Decoder

This clause specifies the hypothetical FEC decoder and its use to check packet stream and MBMS receiver conformance.

The hypothetical FEC decoder uses the packet stream, the transmission time of each packet, the initial buffering delay, and the SDP for the stream as inputs. The packet stream from the beginning of the FEC source block until the end of the stream shall comply with the hypothetical reference decoder as specified below when the initial buffer delay equals to the value of the min-buffer-time parameter.

The maximum hypothetical FEC decoding buffer size for MBMS streaming is 1 Mbytes. The default hypothetical FEC decoding buffer size is equal to 1 Mbytes.

For the packet stream, the buffer occupancy level of the hypothetical FEC decoding buffer shall not exceed the value of the buf-size parameter, when it is present in the SDP, or the default FEC decoding buffer size, when the buf-size parameter is not present in the SDP. The output of the hypothetical FEC decoder shall comply with the RTP payload and decoding specifications of the media format.

The hypothetical FEC decoder operates as follows:

1) The hypothetical FEC decoding buffer is initially empty.

2) Each FEC source packet and FEC repair packet, starting from the first packet in transmission order, is inserted into a FEC source block at its transmission time. The FEC source block generation is done as specified in [106], section 6.2.3. The FEC source block resides in the hypothetical FEC decoding buffer.

3) When both the last FEC source packet and the last FEC repair packet of an FEC source block are transmitted, any elements of the FEC source block that are not original UDP packets (e.g. FEC repair packets and potential padding bytes) are removed from the hypothetical FEC decoding buffer.

4) Original UDP packets are not removed from the hypothetical FEC decoding buffer before the signalled initial buffering delay has expired. Then, the first original UDP packet in sequence number order is output and removed from the hypothetical FEC decoding buffer immediately. Each succeeding original UDP packet is output and removed when the following conditions are true:

i. The following time (in seconds) since the removal of the previous packet has elapsed:

8 × (size of the previous original UDP packet including UDP/IP header in bytes) / (1 000 × (value of "b=AS" SDP attribute for the stream))

ii. All the packets in the same FEC source block as the original UDP packet have been transmitted.

An MBMS client shall be capable of receiving a packet stream that complies with the hypothetical FEC decoder. Furthermore, in the case of RTP packets, when an MBMS client complies with the requirements for the media decoding of the packet stream, it shall be able to de-packetize and decode the packet stream and output decoded data at the correct rate specified by the RTP timestamps of the received packet stream.

8.2.2.12 Void

8.2.2.13 Signalling

The signalling for streaming FEC consists of several components:

– If several user services are bundled together they are indicated as a sequence of services in the User Service Bundle Description. See sub-clause 11.2.

– A separate SDP describing the FEC repair stream and all the flow IDs referenced from the User Service Bundle Description. See sub-clauses 11.2 and 8.2.2.14.

– SDP protocol identifiers and attributes to indicate the usage of the source packet format, how the FEC payload ID is configured and other FEC parameters such as minimal buffering delay, for the RTP/RTCP streams. See sub-clause 8.2.2.13a.

– Security description extensions to indicate usage of FEC source packet format, and the FEC parameters. See sub-clauses 11.3 and 8.2.2.13a.

The user service description contains either a single service or several bundled services. All of the streaming delivery methods and security descriptions that are present within the bundleDescription element must be considered when configuring the FEC operations. This includes RTP, RTCP and MIKEY flows. A receiver intending to perform FEC decoding to cover for packet losses shall receive all the flows that are indicated to be sent as FEC source packets, even if the flows are in a service currently not played out. A receiver intending to use FEC shall also receive the FEC repair stream as described by the FEC Repair Stream Description. The delivery method’s session description, and the security description both carry the FEC source packet configuration information: FEC encoding ID, FEC instance ID, and FEC OTI information. The FEC repair packet stream is configured using the similar methods as for the source packets, with the addition of the Flow ID information and buffer delay parameter.

8.2.2.13a SDP for FEC source packet streams

To indicate the presence of the FEC layer between IP/UDP and, RTP or SRTP a SDP protocol identifier is used. Instead of the normal RTP/AVP and RTP/SAVP protocol identifiers, ‘UDP/MBMS-FEC/RTP/AVP’ and ‘UDP/MBMS-FEC/RTP/SAVP’ are defined respectively. Both these protocol identifiers shall use the FMT space rules that are used for RTP/AVP and RTP/SAVP respectively, i.e. payload types used in the RTP session is listed. The protocol identifiers are defined in Appendix C1.

The FEC parameters, FEC encoding ID, FEC instance ID and FEC-OTI-Extension information are signalled using the mechanism defined in sub-clause 8.3.1.8. The "a=FEC" SDP attribute shall be used to indicate the single definition that is used for each media component.

For MIKEY messages the Security Description is used to indicate when FEC source packet shall be used, see sub-clause 11.3. The FEC parameter used is also defined in the Security Description. As all MIKEY packets from all user services arrive on the same port, the receiver must use the destination address to separate FEC protected packets from not FEC protected packets. This requires that all MIKEY packets sent to a specific destination address are either FEC protected or not. Note that it is not possible to mix protected and non-protected packets within a single stream as there is no mechanism to determine whether they are protected or not.

8.2.2.14 SDP for FEC repair packet streams

The repair packet stream is indicated in SDP using a media block with the protocol identifier "UDP/MBMS-REPAIR". The media type shall be "application". The FEC parameters, FEC encoding ID, FEC instance ID, FEC-OTI-Extension information and repair parameters (min-buffer-time) are signalled using the mechanisms defined in sub-clause 8.3.1.9. Each media component shall reference only one FEC declaration.

The mapping of the FEC source block flow ID to the destination IP address and UDP port are done using the SDP attribute "a=mbms-flowid" defined in sub-clause 8.3.1.9.

Interleaving may be signaled using the "X-3gpp-FEC-Interleaving" attribute, which also gives the arrangement of the flows in the source block and by consequence their transmission order. The "X-3gpp-FEC-Interleaving" attribute is defined in sub-clause 8.3.1.11.

8.2.2.15 Signalling example for FEC

This sub-clause contains a complete signalling example for a MBMS multicast mode session using FEC with a Service description, a SDP for the streaming delivery method, a SDP for the FEC repair stream, and a security description.

The following is an example bundleDescription.

<?xml version="1.0" encoding="UTF-8"?>

<bundleDescription
xmlns="urn:3GPP:metadata:2005:MBMS:userServiceDescription"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xmlns:sv="urn:3gpp:metadata:2009:MBMS:schemaVersion"

xsi:schemaLocation="urn:3GPP:metadata:2005:MBMS:userServiceDescription USD-schema-main.xsd" fecDescriptionURI="http://www.example.com/3gpp/mbms/session1-fec.sdp">

<userServiceDescription

serviceId="urn:3gpp:0010120123hotdog">
<deliveryMethod
sessionDescriptionURI="http://www.example.com/3gpp/mbms/session1.sdp"

protectionDescriptionURI="http://www.example.com/3gpp/mbms/sec-descript">

<sv:delimiter>0</sv:delimiter>

</deliveryMethod>

<sv:delimiter>0</sv:delimiter>

</userServiceDescription>

<sv:schemaVersion>1</sv:schemaVersion>

</bundleDescription>

The security description has the URI: http://www.example.com/3gpp/mbms/sec-descript

<?xml version="1.0" encoding="UTF-8"?>

<securityDescription

xmlns="urn:3GPP:metadata:2005:MBMS:securityDescription"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="urn:3GPP:metadata:2005:MBMS:securityDescription security.xsd">

<keyManagement

offsetTime="5"

randomTimePeriod="10">

<serverURI>http://register.example.com/</serverURI>

<serverURI>http://register2.example.com/</serverURI>

</keyManagement>

<keyId>

<MSK>

<MSKID>aMoAAA==</MSKID>

</MSK>

</mediaFlow>

<MSK>

<MSKID>aMkAAA==</MSKID>

</MSK>

</mediaFlow>

</keyId>

<fecProtection

fecEncodingId="1"

fecOtiExtension="ACAEAA=="/>

</securityDescription>

An example of how the SDP http://www.example.com/3gpp/mbms/session1.sdp could look for a session containing two media streams that are FEC protected. In this example we have assumed an audiovisual stream, using 56 kbps for video and 12 kbps for audio. In addition another 300 bits/second of RTCP packets from the source is used for the each of the sessions. Hence, the total media session bandwidth is 56+12+0.3+0.3 = 68.6 kbps.

v=0
o=ghost 2890844526 2890842807 IN IP6 2001:210:1:2:240:96FF:FE25:8EC9
s=3GPP MBMS Streaming SDP Example
i=Example of MBMS streaming SDP file
u=http://www.infoserver.example.com/ae600
e=ghost@mailserver.example.com
c=IN IP6 FF1E:03AD::7F2E:172A:1E24
t=3034423619 3042462419

b=AS:62

b=TIAS: 60500

a=maxprate: 25

a=source-filter: incl IN IP6 * 2001:210:1:2:240:96FF:FE25:8EC9

a=FEC-declaration:0 encoding-id=1

m=video 4002 UDP/MBMS-FEC/RTP/AVP 96

b=TIAS:55000

b=RR:0

b=RS:300

a=rtpmap:96 H263-2000/90000
a=fmtp:96 profile=3;level=10
a=framesize:96 176-144

a=FEC:0

a=maxprate:15

m=audio 4004 UDP/MBMS-FEC/RTP/AVP 98

b=TIAS: 11500

b=RR:0

b=RS:300

a=rtpmap:98 AMR/8000

a=fmtp:98 octet-align=1

a=FEC:0

a=maxprate:10

The FEC stream used to protect the above RTP sessions and a MIKEY key stream has the below SDP (http://www.example.com/3gpp/mbms/session1-fec.sdp):

v=0
o=ghost 2890844526 2890842807 IN IP6 2001:210:1:2:240:96FF:FE25:8EC9
s=3GPP MBMS Streaming FEC SDP Example
i=Example of MBMS streaming SDP file
u=http://www.infoserver.example.com/ae600
e=ghost@mailserver.example.com
c=IN IP6 FF1E:03AD::7F2E:172A:1E24
t=3034423619 3042462419

b=AS:15

a=FEC-declaration:0 encoding-id=1

a=FEC-OTI-extension:0 ACAEAA==

a=mbms-repair: 0 min-buffer-time=2600

a=source-filter: incl IN IP6 * 2001:210:1:2:240:96FF:FE25:8EC9

m=application 4006 UDP/MBMS-REPAIR *

b=AS:15

a=FEC:0

a=mbms-flowid: 1=FF1E:03AD::7F2E:172A:1E24/4002, 2=FF1E:03AD::7F2E:172A:1E24/4003, 3=FF1E:03AD::7F2E:172A:1E24/4004, 4=FF1E:03AD::7F2E:172A:1E24/4005, 5=FF1E:03AD::7F2E:172A:1E24/2269

a=X-3gpp-FEC-Interleaving: 1="reverse", 2="ordered"

A more traditional FEC configuration is shown below. The audio and video media components use different FEC repair flows. The same principle can also be applied when bundling several user services together.

<?xml version="1.0" encoding="UTF-8"?>

<bundleDescription
xmlns="urn:3GPP:metadata:2005:MBMS:userServiceDescription"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xmlns:sv="urn:3gpp:metadata:2009:MBMS:schemaVersion"

xsi:schemaLocation="urn:3GPP:metadata:2005:MBMS:userServiceDescription USD-schema-main.xsd" fecDescriptionURI="http://www.example.com/3gpp/mbms/session2-fec.sdp">

<userServiceDescription

serviceId="urn:3gpp:0010120123hotdog">
<deliveryMethod
sessionDescriptionURI="http://www.example.com/3gpp/mbms/session2.sdp">

<sv:delimiter>0</sv:delimiter>

</deliveryMethod>

<sv:delimiter>0</sv:delimiter>

</userServiceDescription>

<sv:schemaVersion>1</sv:schemaVersion>

</bundleDescription>

The SDP file from above is modified to use two different FEC flows.

b=AS:62

b=TIAS: 60500

a=maxprate: 25

a=source-filter: incl IN IP6 * 2001:210:1:2:240:96FF:FE25:8EC9

m=video 4002 UDP/MBMS-FEC/RTP/AVP 96

b=TIAS:55000

b=RR:0

b=RS:300

a=FEC-declaration:0 encoding-id=1

a=rtpmap:96 H263-2000/90000
a=fmtp:96 profile=3;level=10
a=framesize:96 176-144

a=FEC:0

a=maxprate:15

m=audio 4004 UDP/MBMS-FEC/RTP/AVP 98

b=TIAS: 11500

b=RR:0

b=RS:300

a=FEC-declaration:1 encoding-id=1

a=rtpmap:98 AMR/8000

a=fmtp:98 octet-align=1

a=FEC:1

a=maxprate:10

The SDP file for the two FEC streams

b=AS:15

a=source-filter: incl IN IP6 * 2001:210:1:2:240:96FF:FE25:8EC9

m=application 4006 UDP/MBMS-REPAIR *

c=IN IP6 FF1E:03AD::7F2E:172A:1E24

b=AS:15

a=FEC-declaration:0 encoding-id=1

a=FEC-OTI-extension:0 ACAEAA==

a=mbms-repair: 0 min-buffer-time=2600

a=FEC:0

a=mbms-flowid: 1=FF1E:03AD::7F2E:172A:1E24/4002, 2=FF1E:03AD::7F2E:172A:1E24/4003

m=application 4008 UDP/MBMS-REPAIR *

c=IN IP6 FF1E:03AD::7F2E:172A:1E24

b=AS:15

a=FEC-declaration:1 encoding-id=1

a=FEC-OTI-extension:1 ACAEAA==

a=mbms-repair: 1 min-buffer-time=2600

a=FEC:1

a=mbms-flowid: 3=FF1E:03AD::7F2E:172A:1E24/4004, 4=FF1E:03AD::7F2E:172A:1E24/4005

8.2.3 General RTP Header Extension Mechanism

8.2.3.1 Introduction

The General RTP Header Extension Mechanism [92] is a general mechanism to use the header extension feature of RTP (the Real-Time Transport Protocol). The General RTP Header Extension Mechanism should be supported.

8.2.3.2 Timestamp Offset

Timestamp offsets for RTP may be transmitted using the general RTP header extension mechanism.

The variable timestamp extension element is 32 bits long. The first byte is the extension element header, i.e. the ID and len fields, as defined in [92]. The remaining 3 bytes are the timestamp-offset measured in the same frequency as the RTP timestamp.

Timestamp-offset: A 24 bit unsigned integer signalling the offset of the received packets of the same media in the tune-in FEC block. The timestamp offset indicates at most the difference between the RTP timestamp of the current packet and the highest RTP timestamp of packets of the same media stream that are transmitted in the current FEC source block.

Timestamp offset shall not be used if FEC protection and Interleaving are not being used.

The following example is a general RTP header extension block containing a single variable timestamp extension element.

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

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| 0xBEDE | length=1 |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| ID | len=2 | timestamp-offset |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The presence of variable timestamps is signaled in the SDP file using the header extension specification and the URI "http://www.3gpp.org/2008/TimestampOffset". The URI signals the possible presence of timestamp offsets with the given ID.

8.3 Session description

SDP is provided to the MBMS client via a discovery/announcement procedure to describe the MBMS streaming session. The SDP describes one or more RTP sessions part of the MBMS streaming session. The SDP shall be a correctly formed SDP according to [14].

8.3.1 SDP Parameters for MBMS streaming session

The semantics of a Session Description of an MBMS streaming session shall include the parameters:

– The sender IP address.

– The number of media in the session.

– The destination IP address and port number for each and all of the RTP sessions in the MBMS streaming session.

– The start time and end time of the session.

– The protocol ID (i.e. RTP/AVP).

– Media type(s) and fmt-list.

– Data rate using existing SDP bandwidth modifiers.

– Mode of MBMS bearer per media.

– FEC configuration and related parameters.

– Service-language(s) per media.

– QoE Metrics (defined in sub-clauses 8.3.2.1 and 8.4).

8.3.1.1 Sender IP address

There shall be exactly one IP source address per media description within the SDP. The IP source 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 streaming 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.

8.3.1.2 Destination IP address and port number for channels

Each RTP session part of a MBMS streaming session is defined by two parameters:

– IP destination address.

– Destination port number(s).

The IP destination address shall be defined according to 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]. Multiple ports using "/" notation shall not be used. The RTCP port, if used, shall be RTP port +1.

8.3.1.3 Media Description

The media description line shall be used as defined in [14] for RTP. The <media> part indicates the type of media, audio, video, or text. The usage of RTP and any applicable RTP profile shall be indicated by using the <proto> field of the ‘m-line’. The one or more payload types that are being used in this RTP session are enumerated in the <fmt> part. Each payload type is declared using the "a=rtpmap" attribute according to [14] and use the "a=fmtp" line when required to describe the payload format parameters.

8.3.1.4 Session Timing Parameters

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

8.3.1.5 Mode of MBMS bearer per media

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

8.3.1.6 Service-language(s) per media

The existing SDP attribute "a=lang" is used to label the language of any language-specific media. The values are taken from [73] which in turn takes language and (optionally) country tags from ISO 639 [74] and ISO 3166 [75] (e.g. "a=lang:EN-US"). These are the same tags used in the User Service Description XML.

8.3.1.7 Bandwidth specification

The bit-rate required by the MBMS streaming session and its media components shall be specified using both the "AS" bandwidth modifier and the "TIAS" bandwidth modifier combined with "a=maxprate" [38] on media level in the SDP. On session level the "TIAS" bandwidth modifier combined with "a=maxprate" may be used, where the session level expresses the aggregated peak bit-rate, which may be lower than the sum of the individual media streams.

The bandwidth required for RTCP is specified by the "RR" and "RS" bandwidth modifiers (3GPP TS 26.244 [32]) on media level for each RTP session. The "RR" modifier shall be included and set to 0 to specify that RTCP receiver reports are not used. The bandwidth used for RTCP sender reports shall be specified using the "RS" bandwidth modifier.

8.3.1.8 FEC Parameters

The FEC encoding ID and instance ID are provided using the "a=FEC-declaration" attribute defined in sub-clause 7.3.2.8. Any OTI information for that FEC encoding ID and instance ID is provided with below defined FEC OTI attribute.

The FEC OTI attribute must be immediately preceded by the "a=FEC-declaration" attribute (and so can be session-level and media-level). The fec-ref maps the oti-extension to the FEC-declaration OTI it extends. The purpose of the oti-extension is to define FEC code specific OTI required for RTP receiver FEC payload configuration; exact contents are FEC code specific and need to be specified by each FEC code using this attribute. The OTI for the MBMS FEC Scheme is defined in sub-clause 8.2.2.10a.

The syntax for the attributes in ABNF [23] is:

– sdp-fec-oti-extension-line = "a=FEC-OTI-extension:" fec-ref SP oti-extension CRLF

– fec-ref = 1*3DIGIT (the SDP-internal identifier for the associated FEC-declaration).

– oti-extension = base64

– base64 = *base64-unit [base64-pad]

– base64-unit = 4base64-char

– base64-pad = 2base64-char "==" / 3base64-char "="

– base64-char = ALPHA / DIGIT / "+" / "/"

To provide the FEC repair packets with additional, non FEC specific parameters, a session and media level SDP attribute is defined.

– sdp-fec-parameter-line = "a=mbms-repair: 0*1SP fec-ref SP parameter-list CRLF

– parameter-list = parameter-spec *(1*SP parameter-spec)

– parameter-spec = name "=" value;

– name = 1*(ALPHA / DIGIT / "-")

– value = 1*(safe) ; safe defined in [14]

Currently one FEC non code-specific parameter is defined:

min-buffer-time: This FEC buffering parameter specifies the minimum receiver buffer time (delay) needed to ensure that FEC repair has time to happen regardless of the FEC source block of the stream from which the reception starts. The value is in milliseconds and represents the wallclock time between the reception of the first FEC source or repair packet of a FEC source block, whichever is earlier in transmission order, and the wallclock time when media decoding can safely start.

The parameters name and value is defined in ABNF as follows:

Min-buffer-time-parameter-name = "min-buffer-time"

Min-buffer-time-parameter-value = 1*8DIGIT ;Wallclock time in milliseconds.

The FEC declaration and FEC OTI information utilized in a specific source or repair packet is indicated using the FEC-ref number in the a=fec lines as described in sub-clauses 8.2.2.12 and 8.2.2.13.

8.3.1.9 FEC Flow ID attribute

To indicate the mapping between destination IP address and UDP port number and FEC source block flow IDs, the "a=mbms-flowid" SDP attribute is defined. Each flowID that is used to construct a source block within the bundled sessions shall be included. It is a media level attribute that shall be present in any SDP media block using the "UDP/MBMS-REPAIR" protocol identifier.

The syntax for the attributes in ABNF [23] is:

Sdp-mbms-flowid-attr = "a=mbms-flowid:" *WSP flow-id-spec *("," *WSP flow-id-spec) CRLF

flow-id-spec = flowID "=" address-spec "/" port-spec

address-spec = IP4-multicast / IP6-multicast

IP4-multicast = m1 3*( "." decimal-uchar )

m1 = ("22" ("4"/"5"/"6"/"7"/"8"/"9")) / ("23" DIGIT ))

IP6-multicast = hexpart

hexpart = hexseq / hexseq "::" [ hexseq ] /

"::" [ hexseq ]

hexseq = hex4 *( ":" hex4)

hex4 = 1*4HEXDIG

port-spec = 1*5DIGIT

8.3.1.10 Buffer Requirement Signaling

Due to the variable bitrate nature of some media streams (especially video streams), initial buffering at the receiver becomes necessary to smooth out those variations. The initial buffering delay SHOULD be signaled to the receiver in the SDP using the following media level attribute:

– "a=X-initpredecbufperiod:<initial pre-decoder buffering period>"

For H.264 video streams, the "X-initpredecbufperiod" [47] indicates the nominal removal time of the first access unit from the coded picture buffer (CPB).

For H.265 (HEVC) video streams, the "X-initpredecbufperiod" [47] indicates the nominal removal time of the first decoding unit from the coded picture buffer (CPB).

Note that X-initpredecbufperiod is expressed as clock ticks of a 90-kHz clock. Hence, conversion may be required if the RTP timestamp clock frequency is not 90 kHz.

8.3.1.11 Interleaving Signaling

When interleaving is used in combination with FEC protection of an MBMS service, the BM-SC may indicate to receivers the order of transmission of the media units of a source block using the "X-3gpp-FEC-Interleaving" attribute. It also indicates whether intra-stream interleaving (described in section G.1) has been performed or not for each of the flows in the FEC source block.

The "X-3gpp-FEC-Interleaving" attribute is defined as follows:

– Interleaving="X-3gpp-FEC-Interleaving:" SP flow_interleaving *("," flow_interleaving) CRLF

– flow_interleaving=flowID "=" ["ordered" / "mixed" / "reverse"]

flowID is the indentification of the flow as described in section 8.3.1.9. The intra-stream interleaving modes may result in un-changed tranmission order ("Ordered"), a mixed transmission order ("Mixed"), or a reversed transmission order ("Reverse"). For a flow that is not listed in the X-3gpp-FEC-Interleaving attribute, the receiver should assume that no particular intra- or inter-stream interleaving has been performed. The transmission order does not preculde that some media units of a lower priority stream are interleaved with the media units of higher priority stream.

8.3.2 SDP Example for Streaming Session

Here is a full example of SDP description describing the media streams part of a MBMS streaming session:

v=0
o=ghost 2890844526 2890842807 IN IP4 192.168.10.10
s=3GPP MBMS Streaming SDP Example
i=Example of MBMS streaming SDP file
u=http://www.infoserver.example.com/ae600
e=ghost@mailserver.example.com
c=IN IP6 FF1E:03AD::7F2E:172A:1E24
t=3034423619 3042462419

b=AS:77

a=mbms-mode:broadcast 123869108302929 1

a=source-filter: incl IN IP6 * 2001:210:1:2:240:96FF:FE25:8EC9

m=video 4002 RTP/AVP 96

b=TIAS:62000

b=RR:0

b=RS:600

a=maxprate:17

a=rtpmap:96 H264/90000
a=fmtp:96 profile-level-id=42A01E; packetization-mode=1; sprop-parameter-sets=Z0IACpZTBYmI,aMljiA==
m=audio 4004 RTP/AVP 98

b=TIAS:15120

b=RR:0

b=RS:600

a=maxprate:10

a=rtpmap:98 AMR/8000

a=fmtp:98 octet-align=1

FEC is not used in that example. See clause 8.2.2.15 for an example with FEC.

8.3.2.1 SDP Description for QoE Metrics

Similar as in 3GPP TS 26.234 [47], an SDP attribute for QoE, which can be used either at session or media level, is defined below in [23] based on [14]:

– QoE-Metrics-line = "a" "=" "3GPP-QoE-Metrics:" att-measure-spec *("," att-measure-spec)) CRLF

– att-measure-spec = Metrics ";" Sending-rate [";" Measure-Range]
[";" Measure-Resolution] *([";" Parameter-Ext])

– Metrics = "metrics" "=" "{"Metrics-Name *("|" Metrics-Name) " }"

– Metrics-Name = 1*((0x21..0x2b) / (0x2d..0x3a) / (0x3c..0x7a) / 0x7e) ;VCHAR except ";", ",", "{" or "}"

– Sending-Rate = "rate" "=" 1*DIGIT / "End" / "Periodic"

– Measure-Resolution = "resolution" "=" 1*DIGIT ; in seconds

– Measure-Range = "range" ":" Ranges-Specifier

– Parameter-Ext = (1*DIGIT ["." 1*DIGIT]) / (1*((0x21..0x2b) / (0x2d..0x3a) / (0x3c..0x7a) / 0x7c / 0x7e))

– Ranges-Specifier = as defined in RFC 2326 [88].

An MBMS server uses this attribute to indicate that QoE metrics are supported and shall be used if also supported by the MBMS client. When present at session level, it shall only contain metrics that apply to the complete session. When present at media level, it shall only contain metrics that are applicable to individual media.

The "Metrics" field contains the list of names that describes the metrics/measurements that are required to be reported in a MBMS session (see sub-clause 8.4). The names that are not included in the "Metrics" field shall not be reported during the session. If a name included in any instances of "Metrics-Name" field is not recognized by the UE as a valid metric name as specified in Table 8.4.2, the UE shall ignore this QoE metric reporting, but still report QoE metrics corresponding to recognized metric names in the other "Metrics-Name" instances. A UE of the current release may receive an SDP containing unrecognized QoE metric names, if a network supporting a future release of the specification includes one or more new QoE metrics names in the SDP.

In this version of the specification, the "Sending-Rate" shall be set to the value "End", which indicates that only one report is sent at the end of the MBMS session, or to the value "Periodic", which indicates that reports are sent at periodic time interval, as defined in section 9.4.3. When there are multiple QoE-Metrics lines at the session and media levels, a single value shall be specified for ‘Sending-Rate’ across all those lines in the SDP. In other words, all QoE-Metrics lines will be set to either ‘End’ or ‘Periodic’.

The optional "Measure-Resolution" field, if used, shall define a time over which each metrics value is calculated. The "Measure-Resolution" field splits the session duration into a number of equally sized periods where each period is of the length specified by the "Measure-Resolution" field. The "Measure-Resolution" field is thus defining the time before the calculation of a QoE parameter starts over. If the "Measure-Resolution" field is not present the metrics resolution shall cover the period specified by the "Measure-Range" field. If the "Measure-Range" field is not present the metrics resolution shall be the whole session duration.

The "Measure-Resolution" field shall take only one value for all session level metrics and only one value for all metrics associated to one media. Note that "Measure-Resolution" shall be evaluated according to a real-time clock. This implies that the real-time interval between consecutive measurements is not affected by changes in playback rate, for instance due to buffering.

The optional "Measure-Range" field, if used, shall define the time range in the stream for which the QoE metrics will be reported. There shall be only one range per measurement specification. The range format shall be any of the formats allowed by the media. If the "Measure-Range" field is not present, the corresponding (media or session level) range attribute in SDP shall be used. If SDP information is not present, the metrics range shall be the whole session duration.

8.3.2.2 OMA-DM Configuration of QoE Metrics

As a supplement to QoE provisioning per session (as specified in 8.3.2.1), OMA-DM can be used to specify QoE configuration. If such QoE configuration has been specified, it should be used by the terminal for all subsequent MBMS streaming or download sessions. Note that the use of OMA-DM for configuring QoE reporting is applicable to either MBMS streaming or download sessions over which streaming services are delivered.

From the QoE reporting perspective, session-specific and OMA-DM provisioned QoE configuration shall be considered separate and independent processes. A UE shall consider both these types of reception reporting to be valid, if it receives QoE configuration parameters for both of them.

For OMA-DM QoE configuration the parameters are specified according to the following Managed Object (MO). Version numbering is included for possible extension of the MO.

The Management Object Identifier shall be: urn:oma:mo:ext-3gpp-mbmsqoe:1.0.

Protocol compatibility: The MO is compatible with OMA Device Management protocol specifications, version 1.2 and upwards, and is defined using the OMA DM Device Description Framework as described in the Enabler Release Definition OMA-ERELD _DM-V1_2 [94].

The following nodes and leaf objects shall be contained under the 3GPP_MBMSQOE node if an MBMS client supports the feature described in this clause (information of DDF for this MO is given in Annex H):

Node: /<X>

This interior node specifies the unique object id of a MBMS QoE metrics management object. The purpose of this interior node is to group together the parameters of a single object.

– Occurrence: ZeroOrOne

– Format: node

– Minimum Access Types: Get

The following interior nodes shall be contained if the MBMS client supports the "MBMS QoE metrics Management Object".

/<X>/Enabled

This leaf indicates if QoE reporting is requested by the provider.

– Occurrence: One

– Format: bool

– Minimum Access Types: Get

/<X>/APN

This leaf contains the Access Point Name that should be used for establishing the PDP context on which the QoE metric reports will be transmitted. This may be used to ensure that no costs are charged for QoE metrics reporting. If this leaf is not defined then any QoE reporting is done over the access point according to sub-clause 11.2.1.1.

– Occurrence: ZeroOrOne

– Format: chr

– Minimum Access Types: Get

– Values: the Access Point Name

/<X>/Format

This leaf specifies the format of the report and if compression (Gzip XML) is used.

– Occurrence: ZeroOrOne

– Format: chr

– Minimum Access Types: Get

– Values: "XML", "GZIPXML".

/<X>/Rules

This leaf provides in XML format the rules used to decide if and how the reports are sent to the QoE metrics report server. The leaf also provides the URIs of one or more servers which shall be the receiver of the QoE metrics report. In case of multiple servers, the MBMS client randomly selects one of the servers from the list, with uniform distribution.

The XML scheme is described in sub-clause 9.5.1 and an example XML code is shown in sub-clause 9.5.2. Only the postReceptionReport part needs to be specified. The use of OMA-DM based configuration of QoE reception reporting shall be independent of any such configuration specified by session-specific mechanisms such as SDP description or Associated Delivery Procedure Description. In other words, QoE reception reporting procedure by the UE as determined by parameters set by OMA-DM configuration shall occur independently and separately from its reporting procedure as determined by parameters set in the Associated Delivery Procedures Description or the SDP description, and vice versa.

– Occurrence: One

– Format: chr

– Minimum Access Types: Get

– Values: See clause Annex H.

/<X>/Ext

The Ext node is an interior node where the vendor specific information can be placed (vendor includes application vendor, device vendor etc.). Usually the vendor extension is identified by vendor specific name under the ext node. The tree structure under the vendor identified is not defined and can therefore include one or more un-standardized sub-trees.

– Occurrence: ZeroOrOne

– Format: node

– Minimum Access Types: Get

/<X>/Session

The Session node is the starting point of the session level QoE metrics definitions.

– Occurrence: ZeroOrOne

– Format: node

– Minimum Access Types: Get

/<X>/Session/Metrics

This leaf provides in textual format the QoE metrics that need to be reported, the measurement frequency, the reporting interval and the reporting range. The syntax and semantics of this leaf are defined in clause 8.3.2.1.

– Occurrence: ZeroOrOne

– Format: chr

– Minimum Access Types: Get

– Values: see clause 8.3.2.1.

/<X>/Session/Ext

The Ext node is an interior node where the vendor specific information can be placed (vendor meaning application vendor, device vendor etc.). Usually the vendor extension is identified by vendor specific name under the ext node. The tree structure under the vendor identified is not defined and can therefore include one or more un-standardized sub-trees.

– Occurrence: ZeroOrOne

– Format: node

– Minimum Access Types: Get

/<X>/Speech

The Speech node is the starting point of the speech/audio media level QoE metrics definitions.

– Occurrence: ZeroOrOne

– Format: node

– Minimum Access Types: Get

/<X>/Speech/Metrics

– Occurrence: ZeroOrOne

– Format: chr

– Minimum Access Types: Get

– Values: see clause 8.3.2.1.

/<X>/Speech/Ext

– Occurrence: ZeroOrOne

– Format: node

– Minimum Access Types: Get

/<X>/Video

The Video node is the starting point of the video media level QoE metrics definitions.

– Occurrence: ZeroOrOne

– Format: node

– Minimum Access Types: Get

/<X>/Video/Metrics

– Occurrence: ZeroOrOne

– Format: chr

– Access Types: Get

– Values: see clause 8.3.2.1.

/<X>/Video/Ext

The Ext is an interior node where the vendor specific information can be placed (vendor meaning application vendor, device vendor etc.). Usually the vendor extension is identified by vendor specific name under the Ext node. The tree structure under the vendor identified is not defined and can therefore include one or more un-standardized sub-trees.

– Occurrence: ZeroOrOne

– Format: node

– Minimum Access Types: Get

/<X>/Text

The Text node is the starting point of the timed-text media level QoE metrics definitions.

– Occurrence: ZeroOrOne

– Format: node

– Minimum Access Types: Get

– Values: see clause 8.3.2.1.

/<X>/Text/Metrics

– Occurrence: ZeroOrOne

– Format: chr

– Minimum Access Types: Get

– Values: see clause 8.3.2.1.

/<X>/Text/Ext

The Ext is an interior node where the vendor specific information can be placed (vendor meaning application vendor, device vendor etc.). Usually the vendor extension is identified by vendor specific name under the ext node. The tree structure under the vendor identified is not defined and can therefore include one or more un-standardized sub-trees.

– Occurrence: ZeroOrOne

– Format: node

– Minimum Access Types: Get

8.3.3 SDP Examples for Transparent Session

The following is a full example of SDP description an MBMS transparent session with 2 MPEG-2 TS:

v=0
o=ghost 2890844526 2890842807 IN IP4 192.168.10.10
s=3GPP MBMS Transport-only SDP Example
i=Example of MBMS transport-only SDP file
u=http://www.infoserver.example.com/ae600
e=ghost@mailserver.example.com
c=IN IP6 FF1E:03AD::7F2E:172A:1E24
t=3034423619 3042462419

b=AS:8000000

a=mbms-mode:broadcast 123869108302929 1

a=source-filter: incl IN IP6 * 2001:210:1:2:240:96FF:FE25:8EC9

m=video 4002 UDP/RTP/AVP 96

b=TIAS:4000000

a=mbms-framing-header:0 2

a=rtpmap:100 MP2T/90000

m=video 4002 RTP/AVP 98

b=TIAS:4000000

a=rtpmap:100 MP2T/90000

a=mbms-framing-trailer:0 2

8.4 Quality of Experience

8.4.1 General

The MBMS Quality of Experience (QoE) metrics feature is optional for both MBMS streaming server and MBMS client, and shall not disturb the MBMS service. An MBMS Server that supports the QoE metrics feature shall activate the gathering of client QoE metrics with SDP as described in sub-clauses 8.3.2.1 and 8.4.2 and via the reception reporting procedure as described in sub-clause 9.4. Alternatively QoE activation can be done with OMA-DM as described in sub-clause 8.3.2.2. An MBMS client supporting the feature shall perform the quality measurements in accordance to the measurement definitions, aggregate them into client QoE metrics and report the metrics to the specified server using the content reception reporting procedure. The way the QoE metrics are processed and made available is out of the scope of the present document.

8.4.2 QoE Metrics

An MBMS client should measure the metrics at the transport layer after FEC decoding (if FEC is used), but may also do it at the application layer for better accuracy.

The measurement period for the metrics is the whole streaming duration and the measurement resolution of each reported metrics value is defined by the "Measure-Resolution" field. The measurement period may be less than the session duration, because of late joiners or early leavers. The measurement period shall not include any voluntary event that impacts the actual play, such as pause, or any buffering or freezes/gaps caused by them.

The following metrics in Table 8.4.2 shall be derived by the MBMS client implementing QoE:

Table 8.4.2

QoE Metric	Streaming delivery method	Download delivery method	Metric type
Corruption duration metric	✓		Media
Rebuffering duration metric	✓		Session
Initial buffering duration metric	✓		Session
Successive loss of RTP packets	✓		Media
Frame rate deviation	✓		Media
Jitter duration	✓		Media
Content Access/Switch Time	✓		Session
Network Resource	✓	✓	Session
Average codec bitrate	✓		Media
Codec information	✓		Media
Loss of Objects1		✓	Session
Distribution of Symbol Count Underrun for Failed Blocks1		✓	Session

¹ These metrics are of interest mainly for sessions with a large number of object deliveries such as HTTP streaming sessions [98].

All media metrics are only applicable to at least one of audio, video, speech and timed text media types, and are not applicable to other media types such as synthetic audio, still images, bitmap graphics, vector graphics, and text.

8.4.2.1 Corruption duration metric

Corruption duration, M, is the time period from the NPT time of the last good frame before the corruption, (since the NPT time for the first corrupted frame cannot always be determined) or the start of the measurement period (whichever is later)to the NPT time of the first subsequent good frame or the end of the measurement period (whichever is sooner). A corrupted frame may either be an entirely lost frame, or a media frame that has quality degradation and the decoded frame is not the same as in error-free decoding. A good frame is a "completely received" frame X that, either:

– it is a refresh frame (does not reference any previously decoded frames AND where none of the subsequently decoded frames reference any frames decoded prior to X); or

– does not reference any previously decoded frames; or

– only references previously decoded "good frames".

"Completely received" means that all the bits are received and no bit error has occurred.

Corruption duration, M, in milliseconds can be calculated according to the derivation of good frames as below:

a) A good frame can be derived by the client using the codec layer, in which case the codec layer signals the decoding of a good frame to the client. A good frame could also be derived by error tracking methods, but decoding quality evaluation methods shall not be used. An error tracking method may derive that a frame is a good frame even when it references previously decoded corrupted frames, as long as all the referenced pixels for generating the prediction signal were correctly reconstructed when decoding the reference frames. A decoding quality evaluation method may derive that a frame is a good frame even one or more pixels of the frame have not been correctly reconstructed, as long as the decoding quality is considered by the method as acceptable. Such a frame is not a good frame according to the definition above, which shall be strictly followed.

b) In the absence of information from the codec layer, a good frame should be derived according to N, where N is optionally signalled from MBMS streaming server (via SDP) to the MBMS client and represents the maximum duration, in presentation time, between two subsequent refresh frames in milliseconds. After a corrupted frame, if all subsequent frames within N milliseconds in presentation time have been completely received, then the next frame is a good frame.

c) N is not signalled, then it defaults to ∞ (for video) or to one frame duration (for audio).

The optional parameter D is defined to indicate which of options a) and b) is in use. D is signalled from the client to the server. When D is equal to "a", option a) shall be in use, and the optional parameter T shall be present. When D is equal to "b", option b) shall be in use and the optional parameter T shall not be present.

The optional parameter N as defined in point b is used with the "Corruption_Duration" parameter. The optional parameter T is defined to indicate whether the client uses error tracking (when T is equal to "On") or not (when T is equal to "Off"). T is signalled from the client to the server.

The syntax for D, N to be included in the "att-measure-spec" (sub-clause 8.3.2.1) is as follows:

– D = "D" "=" "a" / "b"

– N = "N" "=" 1*DIGIT

In MBMS reception reporting will be done only once at the end of streaming, hence all the occurred corruption durations are summed up over each resolution period of the stream and stored in the vector TotalCorruptionDuration. The unit of this metrics is expressed in milliseconds. For each resolution duration the number of individual corruption events are summed up and stored in the vector NumberOfCorruptionEvents. These two vectors are reported by the MBMS client as part of the reception report (sub-clauses 9.4.6 and 9.5.3).

8.4.2.2 Rebuffering duration metric

Rebuffering is defined as any stall in playback time due to any involuntary event at the client side.

The syntax for the metric "Rebuffering_Duration" for the QoE-Feedback header is as defined in sub-clause 8.3.2.1.

Rebuffering starts at the NPT time of the last played frame before the occurrence of the rebuffering.

In MBMS reception reporting will be done only once at the end of streaming, hence all the occurred rebuffering durations are summed up over each resolution period of the stream and stored in the vector TotalRebufferingDuration. The unit of this metrics is expressed in seconds, and can be a fractional value. The number of individual rebuffering events for each resolution duration are summed up and stored in the vector NumberOfRebufferingEvents. These two vectors are reported by the MBMS client as part of the reception report (sub-clauses 9.4.6 and 9.5.3).

8.4.2.3 Initial buffering duration metric

Initial buffering duration is the time from receiving the first RTP packet until playing starts.

The syntax for the "Initial_Buffering_Duration" is as defined in sub-clause 8.3.2.1.

The metric value indicates the initial buffering duration where the unit of this metrics is expressed in seconds, and can be a fractional value. There can be only one measure and it can only take one value. "Initial_Buffering_Duration" is a session level parameter. This value is reported by the MBMS client as part of the reception report (sub-clauses 9.4.6 and 9.5.3).

8.4.2.4 Successive loss of RTP packets

The metric "Successive_Loss" indicates the number of RTP packets lost in succession (excluding FEC packets) per media channel.

The syntax for the metrics "Successive_Loss" is as defined in sub-clause 8.3.2.1.

In MBMS reception reporting will be done only once at the end of streaming, hence all the number of successively lost RTP packets are summed up over each resolution period of the stream and stored in the vector TotalNumberofSuccessivePacketLoss. The unit of this metric is expressed as an integer equal to or larger than 0. The number of individual successive packet loss events over each resolution duration are summed up and stored in the vector NumberOfSuccessiveLossEvents. The number of received packets is also summed up over each resolution duration and stored in the vector NumberOfReceivedPackets. These three vectors are reported by the MBMS client as part of the reception report (sub-clauses 9.4.6 and 9.5.3).

8.4.2.5 Frame rate deviation

Frame rate and frame rate deviation indicates the playback frame rate information. Frame rate deviation happens when the actual playback frame rate during a measurement period is deviated from a pre-defined value.

The actual playback frame rate is equal to the number of frames played during the resolution period divided by the time duration, in seconds, of the actual measurement. For the last measurement period in the session this time duration might be shorter than the configured measurement resolution (see 8.3.2.1 for the definition of the measurement resolution).

The parameter FR that denotes the pre-defined frame rate value is used with the "Framerate_Deviation" parameter in the "3GPP-QoE-Metrics" attribute. The value of FR shall be set by the server. The syntax for FR to be included in the "att-measure-spec" (sub-clause 8.3.2.1) is as follows:

– FR = "FR" "=" 1*DIGIT "." 1*DIGIT

The syntax for the metrics"Framerate" and "Framerate_Deviation" is defined in sub-clause 8.3.2.1

The metric "Framerate" indicates the actual playback frame rate. It is expressed in frames per second, and can be a fractional value..

For the Metrics-Name "Framerate_Deviation", the value field indicates the frame rate deviation value that is equal to the pre-defined frame rate minus the actual playback frame rate. This metric is expressed in frames per second, and can be a fractional value, and can be negative.

The frame rate and the frame rate deviations for each resolution period are stored in the vectors Framerate and FramerateDeviation and the vectors are reported by the MBMS client as part of the reception report (sub-clauses 9.4.6 and 9.5.3).

8.4.2.6 Jitter duration

Jitter happens when the absolute difference between the actual playback time and the expected playback time is larger than a pre-defined value, which is 100 milliseconds. The expected time of a frame is equal to the actual playback time of the last played frame plus the difference between the NPT time of the frame and the NPT time of the last played frame.

The syntax for the metric "Jitter_Duration" is defined in sub-clause 8.3.2.1.

In MBMS reception reporting will be done only once at the end of streaming, hence all the Jitter_Durations are summed up over each resolution duration and stored in the vector TotalJitterDuration. The unit of this metrics is expressed in seconds, and can be a fractional value. The number of individual events over the resolution duration are summed up and stored in the vector NumberOfJitterEvents. These two vectors are reported by the MBMS client as part of the reception report (sub-clauses 9.4.6 and 9.5.3).

8.4.2.7 Content Access/Switch Time

Content access/switch time is the time that elapses between the initiation of a content request/switch by the user and up to the time when the first packet of the content or media stream is received.

The syntax for the metric "Content_Access_Time" is defined in sub-clause 8.3.2.1.

The metric value indicates the content access/switch time and the unit of this metrics is expressed in seconds, and can be a fractional value. There can be only one measure and it can only take one value. "Content_Access_Time" is a session level parameter. This value is reported by the MBMS client as part of the reception report (sub-clauses 9.4.6 and 9.5.3).

8.4.2.8 Network Resource

The Network_Resource identifies the cell which has been used during each measurement resolution duration. There may be many measurement resolution durations in a reception report for a session, each of which identified with a cell identity in which the measurement was performed.

The syntax for the metric "Network_Resource" is as defined in sub-clause 8.3.2.1.

In GERAN and UTRAN, the cell is identified by the Cell Global Identity (as described in 3GPP TS 23.003 [77]), which is a concatenation of MCC, MNC, LAC and CI. It shall be coded as a text string as follows: Starting with the most significant bit, MCC (3 digits), MNC (2 or 3 digits depending on MCC value), LAC (4 hexadecimal digits) and CI (4 hexadecimal digits).

In E-UTRAN, the cell is identified by the E-UTRAN Cell Global Identification (ECGI) (as described in 3GPP TS 36.331 [97]) which is a concatenation of the PLMN Identifier (PLMN-Id) and the E-UTRAN Cell Identity (ECI). The PLMN identifier consists of MCC and MNC. It shall be coded as a text string as follows: starting with the most significant bit, MCC (3 digits), MNC (2 or 3 digits depending on MCC value) and ECI (7 hexadecimal digits). The reported ECGI shall be the identity of the MBMS cell [96], which could be the Primary Cell (PCell), the Secondary Cell (SCell), or the configurable SCell, if Carrier Aggregation [96] is employed in the E-UTRAN.

Only one cell shall be reported per measurement resolution duration, even if more than one cell has been used during a measurement resolution duration or if reception is done simultaneously from several cells.

The cells used for all the corresponding measurement durations are stored in the vector networkResourceCellId. If the cell identifier value in the vector for a resolution period is unchanged from the previous value, it is allowed to put the value "=" in the vector to indicate this. The vector is reported by the MBMS client as part of the reception report (sub-clauses 9.4.6 and 9.5.3).

8.4.2.9 Average codec bitrate

The average codec bitrate is the bitrate used for coding "active" media information during the measurement resolution period.

For audio media "active" information is defined by frames containing audio. If the audio codec uses silence frames (SID-frames), these frames are not counted as "active", and the SID-frames and the corresponding DTX time periods are excluded from the calculation. Thus for audio media the average codec bitrate can be calculated as the number of audio bits received for "active" frames , divided by the total time, in seconds, covered by these frames. The total time covered is calculated as the number of "active" frames times the length of each audio frame.

For non-audio media the average codec bitrate is the total number of media bits played out during the measurement resolution period, divided by the length of the playout period. The playout period length is normally equal to the length of the measurement resolution period, but if rebuffering occurs the playout period will be shorter (i.e. any rebuffering time shall be ignored when calculating the codec bitrate).

The syntax for the metric "Average_Codec_Bitrate" is defined in sub-clause 8.3.2.1.

The average codec bitrate value for each measurement resolution period shall be stored in the vector AverageCodecBitrate. The unit of this metrics is expressed in kbit/s and can be a fractional value. The vector is reported by the client as part of the reception report (sub-clauses 9.4.6 and 9.5.3).

8.4.2.10 Codec information

The codec information metrics contain details of the media codec used during the measurement resolution period. If the codec information is changed during the measurement resolution period, the codec information valid when each measurement resolution period ends shall be reported. The unit of this metric is a string value. No "white space" characters are allowed in the string values, and shall be removed if necessary.

For audio media the codec information contains the audio codec type, represented as in an SDP offer, for instance "AMR-WB/16000/1".

For video media, the codec information contains the video codec type, represented as in an SDP offer, for instance "H263-2000/90000". Furthermore, the video profile and level used, as well as the image size used shall be reported. For instance "profile=0;level=45" for the profile and level information and "176×144" for the image size. In some cases the profile and level is reported together, for instance "profile-level-id=42e00a". Note that the image size reported for each measurement resolution period shall be the one actually used, not the maximum size allowed by the SDP negotiation.

For timed text media, the codec information contains the text encoding, represented as in an SDP offer, for instance "3gpp-tt/1000".

The syntax for the metric "Codec_Info", "Codec_ProfileLevel" and "Codec_ImageSize" are defined in sub-clause 8.3.2.1.

The codec info, profile / level and codec image size value for each measurement resolution period shall be stored in the vectors CodecInfo, CodecProfileLevel and CodecImageSize respectively. If the metric values in these vectors for a measurement resolution period are unchanged from the previous values in the respective vector, it is allowed to put the value "=" in the vector to indicate this. The CodecInfo, CodecProfileLevel and CodecImageSize vectors are reported by the client as part of the reception report (sub-clauses 9.4.6 and 9.5.3).

8.4.2.11 Loss of Objects

The metric "Object_Loss" indicates the number of objects lost in a FLUTE session during a resolution period.

The syntax for the metric "Object_Loss" is as defined in sub-clause 8.3.2.1.

The number of lost objects are summed up over each resolution period of the session and stored in the vector numberOfLostObjects. The unit of this metric is expressed as an integer equal to or larger than 0. The number of received objects is also summed up over each resolution duration and stored in the vector NumberOfReceivedObjects. These two vectors are reported by the MBMS client as part of the reception report (sub-clauses 9.4.6 and 9.5.3).

8.4.2.12 Distribution of Symbol Count Underrun for Failed Blocks

The elements of the distribution of the metric "Distribution_of_Symbol_Count_Underrun" are calculated by subtracting the total number of source symbols, from the number of received symbols for a failed block in a failed object. The range of values of the distribution are limited to the range of interest through top and bottom range parameters. Values greater than the top of the range are reported as the maximum value. Values lower than the bottom of the range are reported as the minimum value.

Reported values may also be grouped in bins. The size of the bins used for collecting statistics are specified through a bin size parameter. The first bin starts at the bottom of the range. The last bin must include the top of the range. Collection bins are adjacent.

The range of file sizes considered for calculating the metric can also be restricted through optional minimum, and maximum file size parameters.

The distribution is reported per measurement duration as a string list of (bin lower bound, number of occurrences) pairs, with each pair corresponding to a single entry. The bin lower bound uniquely identifies a bin by providing the lowest value of the range of each bin. The bin lower bound, and number of occurrences are both integer values. When reporting the bin lower bound and number of occurrences pairs, the following string format shall be used: "(bin lower bound, number of occurrences)", where the parentheses represent the delimiter and the comma separates the bin lower bound (integer range of values) and number of occurrences (positive integer range of values).

When it contains entries for a single measurement duration, the vector SymbolCountUnderrun is a string vector where the entries are listed sequentially, without a space character between adjacent entries of the overall set. The set of entries is delimited by curly brackets: "{" at the beginning and "}" at the end. Bins with zero occurrences are omitted from the list. Values greater than the top of the range are reported within the bin containing the top of the range. Values lower than the bottom of the range are reported within the first bin containing the bottom of the range.

When SymbolCountUnderrun contains information for multiple measurement durations, it shall comprise a sequence of curly bracket delimited entries, with adjacent members of the sequence separated by one or more space characters. If the number of occurrences for all bins equals zero for a particular measurement duration within the SymbolCountUnderrun, the string "{}" shall be used to signal that event.

The following example shows a scenario whereby the reported distribution of the symbol count underrun comprises the entries of a single measurement duration, and for which bins -9, -4 and 0 have occurrences 2, 6 and 4, respectively. The vector SymbolCountUnderrun is given as:

SymbolCountUnderrun = "{(-9,2)(-4,6)(0,4)}"

The next example shows a scenario whereby the reported distribution comprises entries of multiple measurement durations. In the first measurement duration, bins -3, -2 and -1 have occurrences 1, 3 and 5, respectively, and there are no occurrences in the next two measurement durations. In this case, the vector SymbolCountUnderrun is given as:

SymbolCountUnderrun = "{(-3,1)(-2,3)(-1,5)} {} {}"

The top, bottom, and bin size of the distribution range are provided through the optional parameters T, B, and S respectively. The syntax for T, B, and S to be included in the "att-measure-spec" (sub-clause 8.3.2.1) is as follows:

– T = "T" "=" {+/-} 1*DIGIT

– B = "B" "=" {+/-} 1*DIGIT

– S = "S" "=" 1*DIGIT

The default value of the top of the range, in case the T parameter is omitted, is 0. The default value of the bottom of the range, in case the B parameter is omitted, is -10. The default value of the bin size is 1.

The minimum and maximum file sizes considered for calculating the metric are provided through the optional parameters Y and Z, respectively. The syntax for Y and Z to be included in the "att-measure-spec" (sub-clause 8.3.2.1) is as follows:

– Y= "Y" "=" 1*DIGIT

– Z = "Z" "=" 1*DIGIT

The default value of the minimum file size is 0, and the default value of the maximum file size is infinity.

8.4.3 Example metrics initiation with SDP

This following example shows the syntax of the SDP attribute for QoE metrics. The session level QoE metrics description (Initial buffering duration, rebufferings and network resource) are to be monitored with a measurement resolution of 20 seconds and reported at the end of the session. Also video specific description of metrics (corruptions) are to be monitored and reported at the end from the beginning of the stream until the time 40s. Finally, audio specific description of metrics (corruptions) is to be monitored with a measurement resolution of 10s and reported at the end of the stream.

SDP example:

v=0
o=- 3268077682 433392265 IN IP4 63.108.142.6
s=QoE Enabled Session Description Example
e=support@foo.com
c=IN IP4 0.0.0.0
t=0 0
a=range:npt=0-83.660000
a=3GPP-QoE-Metrics:metrics={Initial_Buffering_Duration|Rebuffering_Duration|

Network_Resource };rate=End;resolution=20
a=control:*
m=video 0 RTP/AVP 96
b=AS:28
a=3GPP-QoE-Metrics:metrics={Corruption_Duration };rate=End;range:npt=0-40
a=control:trackID=3
a=rtpmap:96 MP4V-ES/1000
a=range:npt=0-83.666000
a=fmtp:96profile-level-id=8;config=000001b008000001b50900012000
m=audio 0 RTP/AVP 98
b=AS:13
a=3GPP-QoE-Metrics:metrics={Corruption_Duration };rate=End;resolution=10
a=control:trackID=5
a=rtpmap:98 AMR/8000
a=range:npt=0-83.660000
a=fmtp:98 octet-align=1
a=maxptime:200

8.5 Using MBMS Streaming delivery on Unicast

If the MBMS UE supports MBMS streaming delivery on unicast, then MBMS Streaming shall perform the functions of a PSS client [47] to deliver content when MBMS Bearers are not usable or available and if an alternativeAccessDelivery element is available for the delivery method in the MBMS User Service Description. Note, if an alternativeAccessDelivery element is available, it is presumed that the same content is offered over both PSS and MBMS. If more than one unicastAccessURI element is available in the alternativeAccessDelivery element, then the UE shall randomly choose one URI to be used for unicast access to the service.

If the MBMS UE is receiving an MBMS Streaming User Service using MBMS delivery on Unicast in E-UTRAN, while not being in time-shifting mode, but is interested to receive the corresponding service via an MBMS Bearer instead, it shall handle counting requests as defined in TS 36.300 [96] and TS 36.331 [97].

MBMS and PSS define Quality of Experience (QoE) metrics features. The UE shall not mix MBMS and PSS QoE metrics gatherings and/or reports. QoE is negotiated, gathered and reported separately for PSS and MBMS.

The UE may compare the SSRC values of PSS and MBMS flows. If the UE detects that the same SSRC value is used for PSS and MBMS flows, then the UE should assume that the same wallclock time and same random RTP timestamp offset is used for the flows with the same SSRC value. This gives the UE an advantage for the synchronization onto the flows. The UE does not need to wait for new, flow specific RTCP packets.

The BM-SC and the PSS servers which provide for unicast access to the MBMS service shall be time synchronized. The PSS server and the UE should support UTC clock time format in the "Range" header field as defined in [88].

The UE may request a specific start time of the PSS session by indicating a UTC clock time in the "Range" header field of the PLAY request. The UTC clock time represents the requested streaming start point according to the timeline of the BM-SC. This time may be calculated using the NTP timestamp of the last received RTCP sender reports. Otherwise, the UE may either specify an NPT range using the "now" value as a start point of the PSS session or it may completely omit the Range header field.

If the PSS server does not support time shifting and the request contains a range indication (other than "now") then the PSS server shall reply with the actual range that will be played back. Examples of this are an NPT range header field using "now" or the selected start time in UTC clock time.

A unicastAccessURI element of an alternativeAccessDelivery element in the deliveryMethod element of the User Service Description may contain an RTSP URI or a reference to an PSS SDP file.