EMMG MUX TCP-based protocol

 

First introduce some Parameter definitions:

bandwidth: this parameter indicates the requested bit rate or the allocated bit rate respectively. It is the responsibility of the EMMG/PDG to maintain the bit rate generated within the limits specified by the MUX when the bandwidth allocation method is used (optional). It should be noted that the EMMG/PDG will operate from 0 kbit/s to the negotiated rate. The EMMG/PDG will not exceed the

negotiated rate.

 

client_id: the client_id is a 32-bit identifier. It shall identify uniquely an EMMG/PDG across all the EMMGs/PDGs connected to a given MUX. To facilitate uniqueness of this value, the following rules apply:

• in the case of EMMs or other CA related data, the two first bytes of the client_id should be equal to the two bytes of the corresponding CA_system_id;

• in other cases a value allocated by DVB for this purpose should be used.

 

data_stream_id: this identifier uniquely identifies an EMM/private data stream within a channel.

data_channel_id: this identifier uniquely identifies an EMM/private data channel within a client_id.

 

data_id: the data_id is allocated by the CAS and uniquely identifies an EMM/private data stream of a client_id.

 When a new EMM/private data stream is created in a transport stream, a new data_id shall be assigned to it by the CAS, according to the operational context (EMM/private data stream creation or EMMG/PDG replacement). The value of the

data_id parameter remains unmodified as long as the EMM/private data stream exists. The combination {stream type + client_id + data_id} identifies uniquely this new EMM/private data stream in the whole system.

 

data_type: type of data carried in the datagram in the stream:

• 0x00: EMM;

• 0x01: private data;

• 0x02: DVB reserved (ECM);

• other values: DVB reserved.

 

datagram: this is the EMM/private data. The Datagram can be transferred in either section or TS packet format according to the value of section_TSpkt_flag.

 

section_TSpkt_flag: this parameter defines the format of the EMMs or of the private datagrams carried on this interface:

• 0x00: the EMMs or private datagrams are in MPEG-2 section format;

• 0x01: the EMMs or private datagrams are in MPEG-2 transport stream packet format; all TS packets shall be 188 byte long, any other payload length being considered as an error; it is the head-end's responsibility to fill

the PID field in TS packet header;

 

 

Then there are some Notes for EMMG <==> MUX TCP-based protocol

 

The EMMG is the client and the MUX is the server. The details of the protocol:

1.      Channel establishment

a)      Process:

                    i.              The EMMG sends a channel_setup message to the MUX.

                ii.              In case of success the MUX replies by sending back a channel_status message.

            iii.              In case of a rejection or a failure during channel setup the MUX replies with a channel_error message. This means that the channel has not been opened by the MUX and the EMMG/PDG shall close the TCP connection.

b)      Notes:

                    i.              The EMMG/PDG indicates at channel setup data object will be transferred as sections or as TS packets.

                ii.              The EMMs/private data shall be inserted in the transport stream in the same order as they are provided by the EMMG/PDG.

            iii.               

c)      Message

                    i.              Channel_setup message(0x0011): EMMG/PDG MUX

Parameter Number of instances in message

client_id         1   0x0001 4

data_channel_id   1   0x0003 2

section_TSpkt_flag 1 0x0002 1

 

                ii.              Channel_test message(0x0012): EMMG/PDG <==> MUX

Parameter Number of instances in message

client_id         1   0x0001 4

data_channel_id   1   0x0003 2

 

            iii.              Channel_status message(0x0013): EMMG/PDG <==> MUX

Parameter Number of instances in message

client_id         1   0x0001 4

data_channel_id   1   0x0003 2

section_TSpkt_flag   1   0x0002 1

notes:

All the parameters listed above are mandatory.

When the message is a response to a set-up, the values of the parameters are those requested by the EMMG/PDG and currently stored in the MUX. All these parameter values will be valid during the whole life time of the channel, for all the streams running on it.

When the message is a response to a test, the values of the parameters shall be those currently valid in the channel.

 

                iv.              Channel_close message(0x0014): EMMG/PDG => MUX

Channel closure can occur when the channel is no longer needed or in case of error (detected by EMMG/PDG or reported by MUX).

This is done by means of a channel_close message sent by the EMMG/PDG.

Subsequently, the connection shall be closed by both sides.

Parameter Number of instances in message

client_id         1   0x0001 4

data_channel_id   1   0x0003 2

only sent by the EMMG/PDG.

 

                    v.              Channel_error message(0x0015): EMMG/PDG <==> MUX

Parameter Number of instances in message

client_id         1   0x0001 4

data_channel_id   1   0x0003 2

error_status 1 to n   0x7000 2

error_information 0ton 0x7001   n

 

2.      Stream establishment

a)      Process:

                    i.              The EMMG/PDG sends a stream_setup message to the MUX.

                ii.              In case of success the MUX replies by sending back a stream_status message.

            iii.              In case of a rejection or a failure the MUX replies with a stream_error message.

b)      Message

                    i.              Stream_setup message(0x0111): EMMG/PDG => MUX

Parameter Number of instances in message

client_id         1   0x0001 4

data_channel_id   1   0x0003 2

data_stream_id       1   0x0004 2

data_id           1   0x0008 2

data_type         1   0x0007 1

 

                ii.              Stream_test message(0x0112): EMMG/PDG <=> MUX

Parameter Number of instances in message

client_id         1   0x0001 4

data_channel_id   1   0x0003 2

data_stream_id       1   0x0004 2

 

            iii.              Stream_status message(0x0113): EMMG/PDG <=> MUX

Parameter Number of instances in message

client_id         1   0x0001 4

data_channel_id   1   0x0003 2

data_stream_id       1   0x0004 2

data_id           1   0x0008 2

data_type         1   0x0007 1

The values of the parameters shall be those currently valid in the stream.

 

                iv.              Stream_close_request message(0x0114): EMMG/PDG ⇒ MUX

Parameter Number of instances in message

client_id         1   0x0001 4

data_channel_id   1   0x0003 2

data_stream_id       1   0x0004 2

Stream closure is always initiated by the EMMG/PDG.

This can occur when an EMM/private data stream is no longer needed.

 

                    v.              Stream_close_response message(0x0115): EMMG/PDG <== MUX

Parameter Number of instances in message

client_id         1   0x0001 4

data_channel_id   1   0x0003 2

data_stream_id       1   0x0004 2

The stream_close_response message is sent by the MUX.

 

                vi.              Stream_error message(0x0116): EMMG/PDG <=> MUX

Parameter Number of instances in message

client_id         1   0x0001 4

data_channel_id   1   0x0003 2

data_stream_id       1   0x0004 2

error_status 1 to n   0x7000 2

error_information 0ton 0x7001   n

 

A stream_error message is sent by the recipient of a stream_test message or by the MUX at any time to indicate that an unrecoverable stream level error occurred.

 

3.      Bandwidth allocation

a)      Notes:

                    i.              The interface allows bandwidth negotiation between the EMMG/PDG and the MUX. This is not mandatory.

b)      Process:

                    i.              EMMG/PDG will request the optimal bandwidth for that stream.

                ii.              The MUX will then respond with the bandwidth that has been allocated for that stream. The EMMG/PDG can, at a later time, request an adjustment in the bandwidth allocation. The MUX could also initiate an allocation change, without any request from the EMMG/PDG.

c)      Message

                    i.              Stream_BW_request message(0x0117): EMMG/PDG ⇒ MUX

Parameter Number of instances in message

client_id         1   0x0001 4

data_channel_id   1   0x0003 2

data_stream_id       1   0x0004 2

bandwidth         0to1   0x0006 2

The stream_BW_request message is sent by the EMMG/PDG and can be used in two

ways.

1, If the bandwidth parameter is present the message is a request for the indicated amount of bandwidth.

2, If the bandwidth parameter is not present the message is just a request for information about the currently allocated bandwidth.

The MUX shall always reply to this message with a stream_BW_allocation message.

                ii.              Stream_BW_allocation message(0x0118): EMMG/PDG <== MUX

Parameter Number of instances in message

client_id         1   0x0001 4

data_channel_id   1   0x0003 2

data_stream_id       1   0x0004 2

bandwidth         0to1   0x0006 2

The stream_BW_allocation message is used to inform the EMMG/PDG about the bandwidth allocated. This can be a response to a stream_BW_request message or as a notification of a change in bandwidth initiated by the MUX. The message is always sent by the MUX.

If the bandwidth parameter is not present it means that the allocated bandwidth is not known.(?? what to do then)

NOTE: The bandwidth allocation message may indicate a different bandwidth than was requested (this could be less).

 

            iii.              Data_provision message: EMMG/PDG ⇒ MUX

Parameter Number of instances in message

client_id         1   0x0001 4

data_channel_id   1   0x0003 2

data_stream_id       1   0x0004 2

data_id           1   0x0008 2

datagram          1to n 0x0005  User define

The data_provision message is used by the EMMG/PDG to send, on a given data_stream_id, the datagram (in the case of EMMG this is EMM data).

 

4.      Error process

a)      Error status

Only channel, stream and application level errors occur during the lifetime of a TCP connection.

There are two different error messages on that interface.

The channel_error message for channel wide errors;

the stream_error message for stream specific errors.

These messages are sent by the MUX to the EMMG/PDG. When the MUX reports an error to the EMMG/PDG, it is up to the EMMG/PDG to decide the most appropriate step to be taken.

However "unrecoverable error" explicitly means that the channel or stream (depending on the message used) has to be closed. Most error status listed in table 8 cannot occur in normal operation. They are mainly provided to facilitate the integration and debugging phase.

 

b)      Unexpected connection loss

Both EMMG/PDG and MUX shall be able to handle an unexpected communication loss (either on the connection, channel or stream level).

Each component, when suspecting a possible communication loss (e.g. a 10 second silent period), should check the communication status by sending a test message and expecting to receive a status message. If the status message is not received in a given time (implementation specific) the communication path should be re-established.

 

c)      Handling data inconsistencies

If the MUX detects an inconsistency it shall send an error message to the EMMG/PDG.

If the EMMG/PDG receives such a message or detects an inconsistency it should close the connection.

The EMMG/PDG (as the client) will then (re-) establish the connection, channel and (if applicable) streams.

NOTE: The occurrence of a user defined or unknown parameter_type or message_type shall not be considered as an inconsistency.

 

And finally the Summary:

When we implement the EMMG,

1.      Stream or channel over time needs to be checked for connection loss.

2.      only the client close channel.

3.      when error happens, send channel error message then close the channel directly, and the EMMG should reconnect to MUX.

4.      stream close is sent only when private message is not needed.

5.      the EMMG must be ready to handle the Stream_BW_allocation message at anytime, to redefine the sending speed of private data.

6.      when error happens, it’s up to EMMG to decide how to deal with the error.

7.      only MUX report error message.

8.      data inconsistencies happens, the EMMG close channel directly.