4 General

24.5813GPPMission Critical Video (MCVideo) media plane controlProtocol specificationRelease 18TS

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

4.1 MCVideo media plane overview

4.1.1 Transmission Control

4.1.1.1 General

In a video group call after the call is setup, at a given time multiple group members (the allowed maximum simultaneous MCVideo transmitting group members is configured in the group configuration data) are allowed to transmit videos and all other affiliated group members are invited to accept the incoming videos. Each of the other affiliated group members has the option to accept or reject the incoming videos. After accepting the video, the affiliated group member can end the video being received at any time. . The control action for obtaining this mode of operation is known as transmission and reception control. The direct actors of transmission and reception control are the transmission participants and the transmission control server. A transmission participant does the transmission and reception control related actions in the MCVideo client. The transmission control server is the decision maker of the transmission and reception control. In on-network the transmission control server is in the MCVideo server with the controlling role. In off-network no specific transmission control server exists. The current video transmitter plays the role of transmission control server.

Transmission control actions in on-network are described in clause 4.1.1.2. The differences for off-network transmission control are described in clause 4.1.1.3.

NOTE: End-user actions as operation of the video transmit, video transmission end, video receive and video reception end button illustrates functionality but no end-user actions are mandated by the present document.

4.1.1.2 On-network transmission and reception control

At any point in time a group member can request permission to transmit.

When the allowed maximum simultaneous MCVideo transmitting group members is not reached, a group member can click the video transmission send button, meaning the request for permission to transmit. The transmission participant entity of this user reflects this request to the transmission control server by sending a Transmission Request message. If the transmission control server decides to permit, it informs this permission for this request by sending a Transmission Granted message to the requesting group member. The transmission control server informs the initiation of the transmission to the other group members by sending a Media Reception Notification message. Once the group member receives the permission, a permission indication (permission tone) is generated by the client to inform the user that the video starts being transmitted. The media packets (encoded audio stream and video stream) are sent to the controlling MCVideo server and from there they are distributed to all receivers of this group. The click on the video transmission end button indicates the user’s intention to end transmitting. Once the video transmission end button is clicked, the transmission participant sends a Transmission End Request message to the transmission control server indicating that this user has finished transmitting. This cycle, starting from the Transmission Granted message and ending with Transmission End Request message, is known as ‘video transmission’.

In the beginning of a call the initial transmit request can be implied by the SIP message which initiates the call as specified in 3GPP TS 24.281 [2] without any specific Transmission Request message.

A group member can also request permission to transmit media by sending a Transmission Request message when the allowed maximum simultaneous MCVideo transmitting group members is reached. The transmission control server can resolve this request in several ways.

1. If this request has higher priority than any one of the ongoing video transmissions, the transmission control server revokes the ongoing video transmission with lowest priority by sending a Transmission Revoke message to the video transmitter of the video transmission with lowest priority. The transmitter is interrupted and the current video transmission is ended by the current transmission participant by sending a Transmission End Request message. Then the transmission control server sends a Transmission Granted message to the revoking user and send Media Reception Notification message to other affiliated group members. Then a new video transmission starts.

2. If this request does not have higher priority and transmission request queueing is not used the transmission control server rejects this request by sending a Transmission Deny message to the requester. Then a reject indication (reject tone) is generated for the user. The ongoing video transmissions continue.

3. If request queueing is used the transmission control server sends Transmission Queue Position Info message indicating that there is no permission but the request is queued for potential permission when the current video transmissions end. Then a "queued" indication is generated for the user. The ongoing video transmissions continues.

When an affiliated group member receives the Media Reception Notification message, if the maximum number of simultaneous video streams that can be received is not reached, a warning indication (new video coming tone) is generated by the client to inform the user that a new video transmission is coming to be accepted. The click on the video receive button indicates the user accepts the video, the transmission participant entity of this user sends a Receive Media Request message to the transmission control server. If the transmission control server determines to accept the Receive Media Request, a Receive Media Response message is sent back to the requesting receiver. The click on the video reception end button indicates the receiver’s intention to end the video reception. Once the video reception end button is clicked, the transmission participant sends a Media Reception End Request message to the transmission control server indicating that this user does not want to receive the video transmission any more. Once receiving the Media Reception End Request message, the transmission control server interacts with media distribution function to stop sending the requesting video to the requesting receiver. If no one receives the video any more, the transmission control server can send Transmission End Request to the video transmitting user to end the video transmitting.

If maximum number of simultaneous video streams that can be received towards the affiliated group member is reached, the transmission participant can resolve this Media Reception Notification in several ways.

1. If this notification has higher priority than any one of the ongoing video receptions, the transmission participant ends the ongoing video reception with lowest priority by sending a Media Reception End Request message to the transmission control server indicating that this user does not want to receive the video transmission any more.. Then the transmission participant sends a Transmission Granted message to the revoking user and send Media Reception Notification message to other affiliated group members. Then the transmission participant sends a Receive Media Request to the transmission control server to receive the new video transmission. Then a new video reception starts.

2. If this notification does not have higher priority, a warning indication and a prompt (new video available but the maximum number of simultaneous video streams that can be received is reached) is generated by the client to inform the user that a new video transmission is available but the maximum number of simultaneous video streams that can be received is reached, and prompts the user to make a decision. If the user reject the new video transmission invitation, the ongoing video receptions continue and the video transmission is added to a recently invited group communications list locally for later reception. If the user end the other ongoing video reception to accept the new video transmission, then the transmission participant sends a Receive Media Request to the transmission control server to receive the new video transmission. Then a new video reception starts.

During the video transmissions, a queued user can ask its position in the queue by sending a Transmission Queue Position Request message. Then the transmission control server provides the information by sending Transmission Queue Position Info message. A queued user can also remove itself from the queue by sending a Transmission End Request message. This kind of message exchange during the video transmissions does not affect the ongoing video transmissions.

If request queueing is used, by the end of a video transmission, the transmission control server gives the transmit permission to the first pending request in the queue. For this, it sends the same messages as in the beginning of a video transmission; Transmission Granted message to the permitted user and Media Reception Notification message to other affiliated group members. The permitted user is expected to click the video transmission send button after the permission tone within a well-defined short period of time. If the permitted user does not click the video transmission send button, the MCVideo client loses the transmission permission.

If queueing is used the ordering in the queue is affected by the priority of the users in the queue.

A transmission request with pre-emptive priority can be granted with revoking the ongoing video transmitter with lowest priority.

During silence (when no video transmission is ongoing), the transmission control server can send Transmission Idle message to all transmission participants from time to time. The transmission control server sends Transmission Idle message in the beginning of silence.

Some of the transmission control messages can be repeated as specified in state machines specified in clause 6.

The call can be released after a long silence period.

4.1.1.3 Off-network transmission control

This clause describes the special features for off-network transmission control with respect to the on-network transmission control.

In off-network no specific transmission control server exists. All transmission control messages are sent to all group members.

When a transmission control server gives transmission permission it sends a Transmission Granted message. The information element which expresses the group member, to which this transmission permission is given, implies to the other group members that the transmission is taken. No other Media Reception Notification message is sent.

After silence, a transmission participant asks for transmission permission by sending a Transmission Request message. After a well-defined waiting period, if no response is received, this transmission participant sends a Media Reception Notification message indicating itself in the information element which expresses the group member to which this transmission permission is given and continues the video transmission.

In off-network, the Transmission Idle message is not used.

Some of the transmission control messages can be repeated as specified in the state machines specified in clause 7.

4.1.1.4 Determine on-network effective priority

The transmission control server can determine how to handle a received Transmission Request message using a number of input parameters. Examples of input parameters that the transmission control server can use are:

1. the transmission priority, using the value of the Transmission Priority field in the Transmission Request message;

2. the <user-priority> element as specified in 3GPP TS 24.481 [5];

3. the <num-levels-priority-hierarchy> element as specified in 3GPP TS 24.484 [7];

4. the participant type, using the <participant-type> element specified in 3GPP TS 24.481 [5] or, in case a non-controlling MCVideo function is attached to a group call, the <Participant Type> value in the Track Info field in the Transmission Request message;

5. the type of call indicated in the Transmission Indicator field;

6. the effective priority of the transmission participant with the permission to send media, and the current type of the call (e.g. normal, imminent-peril, emergency, broadcast); and

7. any other information in the group document specified in 3GPP TS 24.481 [5] or information stored in the controlling MCVideo function outside the scope of the present document.

Using a local policy and the above input parameters the transmission control server can determine that a transmission request is:

1. pre-emptive such that the current transmission is overridden;

2. pre-emptive such that the current transmission is revoked;

3. not pre-emptive and put in the transmission request queue, if queueing was negotiated; or

4. not-pre-emptive and rejected, if queueing was not negotiated.

The transmission participant can determine how to handle a received Media Reception Notification message using a number of input parameters. Examples of input parameters that the transmission participant can use are:

1. the transmission priority, using the value of the Transmission Priority field in the Transmission Request message;

2. the <user-priority> element as specified in 3GPP TS 24.481 [5];

3. the <num-levels-priority-hierarchy> element as specified in 3GPP TS 24.484 [7];

4. the participant type, using the <participant-type> element specified in 3GPP TS 24.481 [5];

5. the type of call indicated in the Transmission Indicator field;

6. the effective priority of the transmission participant with the permission to send media, and the current type of the call (e.g. normal, imminent-peril, emergency, broadcast); and

7. any other information in the group document specified in 3GPP TS 24.481 [5] or information stored in the controlling MCVideo function outside the scope of the present document.

4.1.1.5 Determine off-network effective priority

The transmission control participant can determine how to handle a received Transmission Request message using the following input parameters:

1. the transmission priority, using the value of the Transmission Priority field in the Transmission Request message;

2. the value of the "/<x>/<x>/Common/MCVideoGroupMemberList/<x>/UserPriority" leaf node of the sender of the Transmission Request message, present in group configuration as specified in 3GPP TS 24.483 [6];

3. the value of the "/<x>/OffNetwork/NumLevelHierarchy" leaf node present in service configuration as specified in 3GPP TS 24.483 [6];

4. the type of call indicated in the Transmission Indicator field; and

5. the effective priority of the transmission participant with the permission to send media, and the current type of the call (e.g. normal, imminent-peril, emergency).

Using the policy as described in clause 7.2.1.2, and the above input parameters the transmission control participant can determine that a transmission request is:

1. pre-emptive such that one of the on-going transmissions is revoked;

2. not pre-emptive and put in the transmission request queue, if the value of "/<x>/<x>/OffNetwork/QueueUsage" leaf node present in the group configuration as specified in 3GPP TS 24.483 [6] is set to "true"; or

3. not-pre-emptive and rejected, if the value of "/<x>/<x>/OffNetwork/QueueUsage" leaf node present in the group configuration as specified in 3GPP TS 24.483 [6] is set to "false".

4.1.2 MBMS subchannel control

4.1.2.1 General

The participating MCVideo function can use an MBMS bearer for the DL transmission of the media and the media control plane.

The participating MCVideo function decides to activate an MBMS bearer. After the activation of the MBMS bearer, as specified in 3GPP TS 29.468 [6], the TMGI of this MBMS bearer is announced to the MCVideo clients in the MBMS service area of this MBMS bearer. This announcement enables the MCPVideo client to listen (decode/demodulate) this MBMS bearer. The activation of an MBMS bearer and the announcement of the TMGI create a pool of MBMS subchannel resources without any association to a group or other purposes.

The criteria for a participating MCPVideo function to decide to activate and use an MBMS bearer is implementation dependent.

An MBMS bearer can be used for the DL transmission for more than one group. For this, additional parameters like destination UDP port are used for enabling the differentiation of messages and packets belonging to different groups over the same MBMS bearer by a receiving MCVideo client.

When a TMGI is announced a general purpose MBMS subchannel is created by defining an association between the identity of the general purpose MBMS subchannel (e.g. ‘general purpose’) and the TMGI (of the activated and announced MBMS bearer) together with the parameters (e.g. UDP port) differentiating this general purpose MBMS subchannel in this MBMS bearer. The parameters of this general purpose MBMS subchannel can be communicated to the MCVideo clients in the MBMS service area of this MBMS bearer using unicast over-the air transmission or can be pre-defined and stored in the MCVideo user profile that is downloaded to the MCVideo UE.

4.1.2.2 Start of a MCVideo transmission

When a MCVideo transmission starts, the participating MCVideo function can allocate an MBMS subchannel for this group by defining an association between this group (e.g. ‘group id’) and the TMGI (of the activated and announced MBMS bearer) with the parameters differentiating this MBMS subchannel in this MBMS bearer. The parameters of this MBMS subchannel are sent using the general purpose MBMS subchannel using the Map Group To Bearer message. The Map Group To Bearer message is repeated as long as the communication is ongoing for improving the reception probability and to allow MCVideo clients arriving late to listen to the MBMS subchannel.

The Map Group To Bearer provides the multicast IP destination address and the destination ports used to deliver the transmission control messages, the audio and video media packets, the FEC repair packets.

4.1.2.3 During a media transmission

If an MBMS subchannel exists, the participating MCVideo function forwards the media plane control messages, received from the controlling MCVideo function via MBMS subchannel for media plane control. Only transmission control messages which are transmitted to more than one affiliated group member are forwarded to the MBMS bearer (e.g. the Media transmission notification, Transmission Idle and Transmission end notify messages). Transmission control messages can be repeated as long as the transmission is on going for improving the reception probability. The participating MCVideo function forwards the media packets, received from the controlling MCVideo function, via the MBMS subchannel for media.

Amongst all affiliated group members under this participating MCVideo function, the participating MCVideo function is informed or is enabled to deduce the group members which do not or cannot receive the MBMS subchannels. The participating MCVideo function forwards the media packets and the media plane control messages, received from the controlling MCVideo function, to the group members which do not or cannot receive the MBMS subchannels, using unicast bearers allocated for media and media plane control respectively.

4.1.2.4 Ending the transmission

The participating MCVideo function can de-allocate an MBMS subchannel after a configurable period of silence in the transmission by removing the association to this group by sending the Unmap Group To Bearer message over this MBMS subchannel. The de-allocation of the MBMS subchannel frees the parameters used for differentiating this MBMS subchannel in this MBMS bearer. Therefore, the resources of a de-allocated MBMS subchannel can be reallocated for a transmission of another group.

NOTE: The participating MCVideo function will activate MBMS bearers with general QoS characteristics suitable for MCVideo service and will map MBMS subchannels for media or media plane control only to MBMS bearers that can provide the QoS required by media or media plane control.

4.1.2.5 MBMS bearer announcement over an MBMS bearer

The participating MCVideo function can activate an MBMS bearer that previously has been announced over a unicast bearer by sending an MBMS bearer announcement over an MBMS bearer. The MCVideo client acknowledges that it can listen to the MBMS bearer by sending a listening status report.

4.2 Internal structure of media plane control entities

4.2.1 Controlling MCVideo function

According to 3GPP TS 23.281 [5] the controlling MCVideo function is divided into a transmission control server and a media distribution function. In the present document the internal structure of the MCVideo server is illustrated in figure 4.2-1.

NOTE: The real internal structure of the MCVideo server is implementation specific but a possible internal structure is shown to illustrate the procedures.

Figure 4.2.1-1: Internal structure of transmission control in the controlling MCVideo function

All entities in the controlling MCVideo function are assumed to have a direct communication interface to the application and signalling plane. The interface to the application and signaling plane carries information about SIP session initialisation and SIP session release, SDP content, etc.

The reference point MCVideo-3 is described in 3GPP TS 23.281 [5].

The transmission and reception control interface towards the MCVideo client receives and transmits the transmission control and reception control messages from and to the MCVideo client via the participating MCVideo function. The procedures are controlled by the state machines described in clause 6.3.5 and clause 6.3.7. One transmission control state machine and one reception control state machine are needed for each MCVideo client participating in an MCVideo call.

The transmission and reception control arbitration logic is performing the transmission and reception control. The transmission and reception control arbitration logic is controlled by the state machines described in clause 6.3.4 and clause 6.3.5. One transmission control state machine and one reception control ared needed per MCVideo call.

The transmission request queue is accessible both by the transmission and reception control interface towards the MCVideo client for all MCVideo clients in the call and the transmission and reception control arbitration logic.

The network media interface is receiving and sending media from and to the associated MCVideo client via the participating MCVideo function. The network media interface is out of scope of the present document. One network media interface is needed for each MCVideo client participating in an MCVideo call.

The media distributor is controlled by the transmission and reception control arbitration logic. The media distributor is out of scope of the present document. One media distributor is needed per MCVideo call.

The internal interfaces are assumed to transport the following types of information.

1. The interface between the network media interface and the transmission and reception control interface towards the MCVideo client:

a. Indication that the network media interface has started to receive media packets from the associated MCVideo client or that media packets are no longer received from the associated MCVideo client.

NOTE: It is an implementation option whether an indication e.g. is sent for every received RTP media packet or only when the first packet is received and then when no more RTP packets are received.

2. The interface between the transmission and reception control interface towards the MCVideo client and the transmission and reception control arbitration logic:

a. Transmission control and reception control messages to and from the associated MCVideo client, requests to create or delete the state machine instance for the associated MCVideo client. The transmission control and reception control messages to the transmission and reception control arbitration logic are limited to transmission control and reception control messages that will change the state of the transmission.

3. The interface between the network media interface and the media distributor:

a. Media to and from associated MCVideo clients. This interface is out of scope of the present document.

4. The interface between the transmission and reception control arbitration logic and the media distributor:

a. Requests to start or stop distributing media to participants in the MCVideo call. Indication that the media distributor has started to receive media packets from the network media interface associated with the MCVideo client with the permission to send media or that media packets are no longer received from the network media interface from the associated MCVideo client.

5. The interface between the transmission and reception control interface towards the MCVideo client and the transmission request queue:

a. Requests to store received Transmission Request messages in the queue or requests to remove Transmission Request messages from the queue and the queue content for building the Transmission Queue Position Info message.

6. The interface between the transmission and reception control arbitration logic and the transmission request queue:

a. Requests to store received Transmission Request messages in the queue or requests to remove Transmission Request messages from the queue. Indications that the queue is modified.

4.2.2 MCVideo client

According to 3GPP TS 23.281 [11] the MCVideo client is divided into a transmission participant and a media mixer function. In the present document the internal structure of the MCVideo client is illustrated in figure 4.2.2-1.

NOTE: The real internal structure of the MCVideo client is implementation specific but a possible internal structure is shown to illustrate the logic and the procedures.

Figure 4.2.2-1: Internal structure of the MCVideo client

All entities in the MCVideo client have a direct communication interface to the application and signalling plane. The interface to the application and signaling plane carries information about SIP session initialisation and SIP session release, SDP content, etc.

The reference points MCVideo-4, MCVideo-6, MCVideo-7 and MCVideo-8 are described in 3GPP TS 23.281 [11].

The transmission participant receives and sends transmission and reception control message over the unicast bearer.

The media mixer receives and sends RTP media packets over the unicast bearer. The media mixer indicates to the transmission participant when RTP media packets are received and when RTP media packets are no longer received. The transmission participant instructs the media mixer on how to handle media received from the user or received from the network either over the unicast bearer or over the MBMS bearer.

The MBMS interface receives RTP media packets over the MBMS bearer. The RTP media packets are forwarded to the media mixer.

The MBMS interface receives transmission control messages and MBMS subchannel control messages over the MBMS bearer. The MBMS interface forward received transmission control messages to the transmission participants.

The RTP media video and audio streams of the transmission participant are uniquely identifed in the MCVideo call. The SSRC values are used for uniquely identifying both the RTP media video and audio streams (i.e. different SSRC values are used for each media video and audio streams) as described in IETF RFC 3550 [3].

The transmission participants are uniquely identified in the MCVideo call using SSRC value. This SSRC value is used by the transmission participants while sending and receiving of transmission and reception control messages for a MCVideo call. The SSRC used for the transmission and reception control messages are different from the SSRC used for the RTP media video and audio streams.

The transmission participant receives indication from the MCVideo client when the MCVideo user has click the video transmit, the video transmission end, and video receive or video reception end button. The MCVideo client can also provide notification towards the MCVideo user. Video received from the MCVideo user is, on instruction from the transmission participant, encoded by the media mixer and sent as RTP media packets over the unicast bearer.

4.2.3 Participating MCVideo function

4.2.3.1 General

The participating MCVideo function performs the participating role of an MCVideo server as defined in 3GPP TS 23.281 [11]. The participating MCVideo function uses media plane control (non-SIP) messages when taking part in the transmission control and reception control procedures as specified in clause 6 and the use of MBMS Bearer procedures as specified in clause 10. In the sequel the term ‘controlling MCVideo function’ is used for the entity which performs the controlling role of an MCVideo server.

The following clauses describe the assumed internal structure of a participating MCVideo function and the role of the participating function in the transmission control and reception control procedures and the use of MBMS Bearer procedures..

4.2.3.2 Internal structure of the participating MCVideo function

In the present document the internal structure of the participating MCVideo function is illustrated in figure 4.2.3.2-1.

NOTE: The real internal structure of the participating MCVideo function is implementation specific but a possible internal structure is shown to illustrate the logic and the procedures.

Figure 4.2.3.2-1: Internal structure of the participating MCVideo function

All entities in the participating MCVideo function have a direct communication interface to the application and signalling plane. The interface to the application and signalling plane carries information about SIP session initialisation and SIP session release, SDP content, etc.

The reference points MCVideo-3, MCVideo-4, MCVideo-7, MCVideo-8 and MCVideo-9 are described in 3GPP TS 23.281 [11].

The media and transmission control message distribution receives media control messages and RTP media packets to and from the MCVideo client and the controlling MCVideo function and the non-controlling MCVideo function. Media plane control messages and RTP packets are forwarded as received when unicast bearers are used. If MBMS bearers are used for transmission control messages, MBMS subchannel control messages and RTP media packets are sent to the MBMS bearer management.

The MBMS bearer management receives transmission control messages and RTP media packets from the media when transmission control messages and RTP media packets are sent over an MBMS bearer. MBMS bearer management also generates MBMS subchannel control message. Transmission control message, RTP media packets and MBMS subchannel control messages are sent to the GCS AS for distribution over an MBMS bearer. The GCS AS is outside the scope of the present specification.

4.2.3.3 The roles of the participating MCVideo function

4.2.3.3.1 For the transmission control procedures

When a transmission control or reception control message or a media packet is received from an MCVideo client, in the MCVideo-4 and MCVideo-7 reference points respectively, the participating MCVideo function forwards it to the controlling MCVideo function over MCVideo-3 reference point or to the application and signalling plane. When a transmission control message or a media packet is received from the controlling MCVideo function, over MCVideo-3 reference point or the application and signalling plane, for MCVideo clients which do not use an MBMS subchannel, the participating MCVideo function forwards the transmission control message to the MCVideo client over the MCVideo-4 and MCVideo-7 reference points respectively. For MCVidep clients which use an MBMS subchannel, for transmission control messages directed to all of these MCVideo clients and for media packets, the participating MCVideo function forwards a single transmission control message or a single media packet using the MBMS subchannel over MCVideo-9 and MCVideo-8 reference points respectively.When MCVideo clients are listening to the MBMS subchannel multiple copies of the same media packet destined to each individual MCVideo client are sent by the controlling MCVideo function while the participating MCVideo function only forwards one single media packet over the MBMS bearer. Any optimizations for not sending the media packet from the controlling MCVideo function to all MCVideo clients are out of scope of the present document.

The participating MCVideo function can decide to apply forward error correction to the media packets to protect them against loss, and reach the QoS target. The participating MCVideo function can apply forward error correction to the media packets before transmitting them over MBMS, or it can ask the BM-SC to apply forward error correction application as described in 3GPP TS 23.280 [12].

The participating MCVideo function specifications related to the transmission control and reception control are specified in clause 6.4 for unicast media and media plane control.

4.2.3.3.2 For the use of MBMS bearer procedures

In the initiation of a transmission, if the MBMS bearer management in the participating MCVideo function decides to use MBMS subchannels for the media plane control messages and the media packets, the participating MCVideo function sends a Map Group To Bearer message over the MCVideo-9 reference point, for indicating the association information between the group identity of this call and the TMGI of the MBMS bearer and additional parameters necessary for the identification of this MBMS subchannels using the general purpose MBMS subchannel already associated for the transmission of this information. In the termination of a transmission the participating MCVideo function sends an Unmap Group To Bearer message for terminating the association between the MBMS subchannels in use for this transmission and the group identity.

The participating MCVideo function specifications related to the declaration of the association between an MBMS bearer and related parameters and the MBMS subchannels for media and media plane control are specified in clause 10.3.2 and clause 10.3.4.

4.2.4 Non-controlling MCVideo function of an MCVideo group

According to 3GPP TS 24.281 [2] clause 5.3 the MCVideo server can act in a non-controlling MCVideo function of an MCVideo group role. In the present document the internal structure of the non-controlling MCVideo function of an MCVideo group is illustrated in figure 4.2.4-1.

NOTE: The real internal structure of the MCVideo server is implementation specific but a possible internal structure is shown to illustrate the logic and the procedures.

Figure 4.2.4-1: Internal structure of the non-controlling MCVideo function

All entities in the non-controlling MCVideo function of an MCVideo group are assumed to have a direct communication interface to the application and signalling plane. The interface to the application and signaling plane carries information about SIP session initialisation and SIP session release, SDP content, etc.

The transmission participant interface receives and transmits the transmission control messages from and to the MCVideo client via the participating MCVideo function or non-controlling MCVideo function. The procedures are controlled by a state machine described in clause 6.5.5. One state machine is needed for each MCVideo client participating in an MCVideo call. A non-controlling MCVideo function is seen by the transmission participant interface as an MCVideo client.

The transmission control server interface is distributing transmission control messages to and from the transmission control server in the controlling MCVideo function or non-controlling MCVideo function. The transmission control server interface procedures are described in clause 6.5.4. One transmission control server interface is needed per MCVideo call.

The network media interface is receiving and sending media from and to the associated MCVideo client via the participating MCVideo function or non-controlling MCVideo function. The network media interface is out of scope of the present document. One network media interface is needed for each MCVideo client participating in an MCVideo call. A non-controlling MCVideo function is seen by the network media interface as an MCVideo client.

The media distributor is controlled by the transmission control server interface. The media distributor is out of scope of the present document. One media distributor is needed per MCVideo call.

The internal interfaces are assumed to transport the following type of information.

1. The interface between the network media interface and the transmission participant interface:

a. Indication that the network media interface has started to receive media packets from the associated MCVideo client and requests from the transmission participant interface to forward received RTP packets towards the media distributor or to stop forward RTP media packets to the media distributor.

NOTE: It is an implementation option whether an indication e.g. is sent for every received RTP media packet or only when the first packet is received.

2. The interface between the transmission participant interface and the transmission control server interface:

a. Floor control messages to and from the associated transmission participant. The transmission control messages to the transmission control server interface are limited to transmission control messages that can result in an action towards the transmission control server.

3. The interface between the network media interface and the media distributor:

a. RTP media packets to and from associated MCVideo clients. This interface is out of scope of the present document.

4. The interface between the transmission control server interface and the media distributor:

4.3 The media plane control channel

4.3.1 General

The media plane control channel is used for transport of messages associated with the transmission control protocol, and the MBMS bearer management protocol, all specified in the present document.

4.3.2 Control channel realization

The media plane control channel is realized by sending RTCP APP packets on top of UDP/IP. RTCP APP packets are defined in IETF RFC 3550 [6]. The MCVideo specific coding of the RTCP APP packets is defined in clause 8 of the present document.

4.3.3 Establishing a media plane control channel

4.3.3.1 General

The MCVideo client and the MCVideo server use the SDP offer/answer mechanism in order to negotiate the establishment of the media plane control channel. The SDP offer/answer procedures for negotiating media plane control channel capabilities are specified in clause 14. The ABNF is defined in clause 12.

The media description ("m=" line) associated with the media plane control channel shall have the values as described in table 4.3.3.1-1.

Table 4.3.3.1-1: Media plane control channel media description

Media description element	Value
<media>	"application"
<port>	RTCP port
<proto>	"udp"
<fmt>	"MCVideo"

The port used for RTCP messages associated with the media plane control channel shall be different than ports used for RTCP messages associated with other "m=" lines (e.g. RTP) in the SDP.

NOTE 1: As RTCP is used to transport messages on the media plane control channel, the "m=" line port value indicates an RTCP port. This is different from cases where an "m=" line is associated with an RTP-based stream, and the "m=" line port value indicates an RTP port.

NOTE 2: In case the media plane control channel uses a different IP address than other media described in the SDP, a media plane control channel specific "c=" line also needs to be associated with the "m=" line associated with the media plane control channel.

The format of the optional SDP fmtp attribute, when associated with the media plane control channel, is described in clause 12.

The example below shows an SDP media description for a media plane control channel.

m=application 20032 udp MCVideo

a=fmtp:MCVideo mc_queueing;mc_priority=5;mc_reception_priority=5;mc_granted