11 Communication using MBMS

24.5823GPPMission Critical Data (MCData) media plane controlProtocol specificationRelease 17TS

11.1 Control messages sent over MBMS bearers

11.1.1 General

The control messages sent over MBMS bearers by MCData participating function and specified in the present document are based on the (S)RTCP Application Packets (SRTCP: APP), as defined in IETF RFC 3550 [16] and IETF RFC 3711 [17], but the control messages do not conform to the rules for compound RTCP packets or RTCP packet transmission.

Each MBMS control message is one (S)RTCP: APP packet. These RTCP: APP packets are not to be sent in compound RTCP packets, but more than one MBMS control message can be sent in a single IP packet.

11.1.2 SRTCP: APP format for control messages sent over MBMS bearers

The definition of the fields in the SRTCP APP packet is found in IETF RFC 3550 [16] and IETF RFC 3711 [17].

Table 11.1.2-1 shows the RTCP APP packet format used for control messages sent over MBMS bearers.

Table 11.1.2-1: MBMS control message format

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

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

|V=2|P| Subtype | PT=APP=204 | length |

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

| SSRC |

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

| name (ASCII) |

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

| application-dependent data |

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

| Secure RTCP message part |

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

P

The padding bit P is set to ‘0’.

Subtype:

The Subtype values in use by MCData are defined in table  11.2.2-1.

length

The length field in the RTCP header is the length of the packet in 32-bit words, not counting the first 32-bit word in which the length field resides.

NOTE: The length field can indicate message size longer than specified in this version of the protocol. This can be the case e.g. if message is of later version of this protocol.

SSRC

The content of this field is described for each MBMS control message separately.

Name

The 4-byte ASCII string in the RTCP header is used to define the set of MBMS control messages for MCData, to be unique with respect to other APP packets that may be sent over the MBMS bearer. For MCData, the name string is "MCDM" (Mission Critical Data over MBMS).

Application-dependent data

The application-dependent data contains zero or more application specific data fields. The format for these fields is described in clause 11.1.3.

This part is encrypted if SRTCP is used.

Secure RTCP message part

The content of the secure RTCP message part is the "tail" appended to the RTCP packet per IETF RFC 3711 [16].

11.1.3 Application specific data field

Each application specific data field is composed of:

1. a field ID which is one octet long;

2. a length value which is:

– one octet long, if the field ID is less than 192; and

– two octets long, if the field ID is equal to or greater than 192;

3. a field value. The length in octets of the field value is indicated in the length value; and

4. a padding. The padding is zero, one, two, or three octets long. The value of the padding octet(s) is set to zero by sender and ignored by receiver.

An application specific data field is always a multiple of 4 octets long.

Table 11.1.3-1 shows the application dependent data field structure when the field ID is less than 192. Table 11.1.3-2 shows the application dependent data field structure when the field ID is equal to or greater than 192.

Table 11.1.3.-1: Application specific data field structure when the field ID is less than 192

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

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

| Field ID | Length value | |

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

: < F i e l d v a l u e > :

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

Table 11.1.3.-2: Application specific data field structure when the field ID is equal to or greater than 192

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

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

| Field ID | Length value | |

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

: < F i e l d v a l u e > :

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

11.2 MBMS Subchannel Control

11.2.1 General

The MBMS subchannel control messages shall be coded as described in clause 11.1.2.

For the MBMS subchannel control protocol used for MCData the ASCII name string shall be: "MCDM".

The list of MBMS subchannel control messages can be found in the clause 11.2.2.

The MBMS subchannel control specific fields are specified in clause 11.2.3.

11.2.2 MBMS subchannel control messages

Table 11.2.2-1 provides a list of MBMS subchannel control protocol messages.

Table 11.2.2-1: MBMS subchannel control protocol messages

Message name

Subtype

Reference

Direction

Map Group To Bearer

00000

clause 11.2.4

Server 🡪 client

Unmap Group To Bearer

00001

clause 11.2.5

Server 🡪 client

Application Paging

00010

clause 11.2.6

Server 🡪 client

Bearer Announcement

00011

clause 11.2.7

Server 🡪 client

NOTE: The participating MCData function is the server and the MCData client is the client.

11.2.3 MBMS subchannel control specific fields

11.2.3.1 Introduction

This clause describes the MBMS subchannel control specific data fields.

The MBMS subchannel control specific data fields are contained in the application-dependent data of the MBMS subchannel control message. The MBMS subchannel control specific data fields follow the syntax specified in clause 11.1.3.

Table 11.2.3.1-1 lists the available fields including the assigned Field ID.

Table 11.2.3.1-1: MBMS subchannel control specific data fields

Field name

Field ID

Description

Decimal

Binary

MBMS Subchannel

000

00000000

Clause 11.2.3.3

TMGI

001

00000001

Clause 11.2.3.4.

MCData Group ID

002

00000010

Clause 11.2.3.2

Monitoring State

003

00000011

Subcaluse 11.2.3.5

11.2.3.2 MCData Group ID field

The MCData Group ID field contains a SIP URI identifying the MCData group to which the MBMS subchannel control messages applies.

Table 11.2.3.2-1 describes the coding of the MCData Group Identity field.

Table 11.2.3.2-1: MCData Group Identity field coding

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

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

|MCData Group |MCData Group |MCData Group Identity |

|Identity field |Identity field | |

|ID |length | |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ :

: (Padding) :

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

The <MCData Group Identity field ID> value is a binary value and shall be set according to table 11.2.3.1-1.

The <MCData Group Identity length> value is a binary value indicating the length in octets of the <MCData Group Identity> value item except padding.

<MCData Group Identity> value contains the MCData group identity as defined in 3GPP TS 24.282 [8] and is in URI format (ASCII string).

If the length of the <MCData Group Identity> value is not (2 + multiple of 4) bytes, the <MCData Group Identity> value shall be padded to (2 + multiple of 4) bytes. The value of the padding bytes should be set to zero. The padding bytes shall be ignored.

11.2.3.3 MBMS Subchannel field

The MBMS Subchannel field identifies the MBMS subchannel to use.

Table 11.2.3.3-1 describes the coding of the MBMS Subchannel field.

Table 11.2.3.3-1: MBMS Subchannel field coding

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

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

|MBMS Subchannel|MBMS Subchannel|Appl. |reser- |IP | spare |

|field ID value |length value |m-line |ved |Version| |

| | |Number | | | |

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

| Media Port Number |

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

: IP Address :

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

The <MBMS Subchannel field ID> value is a binary value and shall be set according to table 11.2.3.1-1.

The <MBMS Subchannel length> value is a binary value indicating the total length in octets of the <Appl. m-line Number> value, reserved, <IP Version> value, spare, <Media Port Number> value and <IP address> items.

The <Appl. m-line Number> value shall consist of 4 bit parameter giving the number of the "m=application" m-line in the SIP MESSAGE request announcing the MBMS bearer described in 3GPP TS 24.282 [8].

The "reserved" 4 bits shall be set to "0000".

The <IP version> value indicates the IP version:

‘0’ IP version 4

‘1’ IP version 6

All other values are reserved for future use.

The "spare" 4 bits shall be set to "0000".

The <Port Number> value is a 32-bit binary value giving the port to be used. The <Media Port Number> value is always present in the MBMS Subchannel field.

The <IP Address> value is:

1. a 32 bit binary value containing the IP v4 address if the <IP version> indicates that the <IP Address> value is a IP v4 Address; or

2. four 32-bit words that together forms a 128 bit binary value representing the IP v6 address, if the <IP version> indicates that the <IP Address> value is a IP v6 Address.

11.2.3.4 TMGI field

Table 11.2.3.4-1 describes the coding of the TMGI field.

Table 11.2.3.4-1: TMGI field coding

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

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

|TMGI |TMGI |TMGI |

|ID |length | |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ :

: (Padding) :

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

The <TMGI field ID> value is a binary value and shall be set according to table 11.2.3.1-1.

The <TMGI length> value is a binary value indicating the length in octets of the <TMGI> value item except padding.

The <TMGI> value is coded as described in 3GPP TS 24.008 [18] clause 10.5.6.13 excluding the Temporary Mobile Group Identity IEI and Length of Temporary Mobile Group Identity contents (octet 1 and octet 2 in 3GPP TS 24.008 [18] clause 10.5.6.13).

If the length of the <TMGI> value is not (2 + multiple of 4) bytes, the <TMGI> value shall be padded to (2 + multiple of 4) bytes. The value of the padding bytes should be set to zero. The padding bytes shall be ignored.

11.2.3.5 Monitoring state

Table 11.2.3.5-1 describes the coding of the Monitoring State field.

Table 11.2.3.5-1: Monitoring State field coding

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

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

|Monitoring |Monitoring |Monitoring |Spare |

|State ID |length=1 | State | |

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

The <Monitoring State ID> value is a binary value and shall be set according to table 11.2.3.1-1.

The <Monitoring State length> value is a binary value indicating the length in octets of the <Monitoring State> value item. The field is set to 1.

The <Monitoring State> value is a binary value where the following values are defined:

‘0’ Monitoring is inactive

‘1’ Monitoring is active

All other values are reserved for future use.

The "spare" bits are set to zero.

11.2.4 Map Group To Bearer message

The Map Group To Bearer message is sent by the participating function when the media associated with the group starts being transmitted on the MBMS bearer and, potentially, multiple times while the transmission is ongoing.

Table 11.2.4-1 shows the content of the Map Group To Bearer message.

Table 11.2.4-1: Map Group To Bearer message

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

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

|V=2|P| Subtype| PT=APP=204 | length |

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

| SSRC of participating MCData function |

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

| name=MCDM |

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

| MCData Group ID field |

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

| TMGI field |

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

| MBMS Subchannel field |

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

With the exception of the three first 32-bit words, the order of the fields are irrelevant.

Subtype:

The Subtype shall be set according to table 11.2.3.1-1.

length:

The length shall be set to the total number of 32-bit words in the message minus one.

SSRC:

The SSRC field shall carry the SSRC of the participating MCData function.

The SSRC field shall be coded as specified in IETF RFC 3550 [16].

MCData Group ID:

The MCData Group ID field is coded as described in clause 11.2.3.2.

TMGI:

The TMGI field is coded as described in clause 11.2.3.4.

MBMS Subchannel:

The MBMS Subchannel field is coded as described in clause 11.2.3.3.

11.2.5 Unmap Group To Bearer message

The Unmap Group To Bearer message is sent by the participating function when media associated with the group stops being sended on the bearer. The message may be repeated several times immediately after.

Table 11.2.5-1 shows the content of the Unmap Group To Bearer message.

Table 11.2.5-1: Unmap Group To Bearer message

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

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

|V=2|P| Subtype | PT=APP=204 | length |

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

| SSRC of participating MCData function |

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

| name=MCDM |

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

| MCData Group ID field |

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

| TMGI field |

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

| MBMS Subchannel field |

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

With the exception of the three first 32-bit words, the order of the fields are irrelevant. MCData Group ID field is mandatory. Including the TMGI field and the MBMS Subchannel field is optional, but if one of those fields is included the other one also needs to be included.

Subtype:

The Subtype shall be coded according to table 11.2.3.1-1.

length:

The length shall be set to the total number of 32-bit words in the message minus one.

SSRC:

The SSRC field shall carry the SSRC of the participating MCData function.

The SSRC field shall be coded as specified in IETF RFC 3550 [16].

MCData Group ID:

The MCData Group ID field is coded as described in clause 11.2.3.2.

TMGI:

The TMGI field is coded as described in clause 11.2.3.4.

MBMS Subchannel:

The MBMS Subchannel field is coded as described in clause 11.2.3.3.

11.2.6 Application Paging message

The Application Paging message is sent by the participating function when an existing media transmission is to be switched to unicast bearers or when a new media transmission is to be started on unicast bearers.

Table 11.2.6-1 shows the content of the Application Paging message.

Table 11.2.6-1: Application Paging message

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

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

|V=2|P| Subtype | PT=APP=204 | length |

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

| SSRC of participating MCData function |

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

| name=MCDM |

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

| MCData Group ID |

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

With the exception of the three first 32-bit words, the order of the fields is irrelevant.

Subtype:

The Subtype shall be coded according to table 11.2.2-1.

length:

The length shall be set to the total number of 32-bit words in the message minus one.

SSRC:

The SSRC field shall carry the SSRC of the participating MCData function.

The SSRC field shall be coded as specified in IETF RFC 3550 [16].

MCData Group ID:

The MCData Group ID field is coded as described in clause 11.2.3.2.

11.2.7 Bearer Announcement message

The Bearer Announcement message is sent by the participating function on an MBMS bearer for application control messages. It may be sent by the participating function in order to achieve a faster setup of the MBMS bearer.

Table 11.2.7-1 shows the content of the Bearer Announcement message.

Table 11.2.7-1: Bearer Announcement message

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

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

|V=2|P| Subtype | PT=APP=204 | length |

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

| name=MCDM |

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

| TMGI |

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

| Alternative TMGI fields |

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

| Monitoring State |

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

With the exception of the three first 32-bit words and the internal order of the TMGI field and the Alternative TMGI fields, the order of the fields is irrelevant.

Subtype:

The subtype shall be coded according to table 11.2.3.1-1.

length:

The length shall be set to the total number of 32-bit words in the message minus one.

TMGI:

The TMGI field is coded as described in clause 11.2.3.4. This field is mandatory.

Alternative TMGI:

Zero or more alternative TMGI fields are coded as described in clause 11.2.3.4. This field is coded immediately after the TMGI field.

Monitoring State:

The monitoring state field is coded as described in clause 11.2.3.5.

11.2.8 Handling of unknown messages and fields

When an RTCP APP message is received, the receiver shall:

1) ignore the whole message, if the combination of name and subtype is unknown;

2) ignore the whole message if it is too short or has errors in the mandatory fields;

3) ignore the unspecified fields in the message (e.g. specified in future version of the protocol); and

4) ignore the syntactically incorrect optional fields.