4 General

24.3803GPPMission Critical Push To Talk (MCPTT) media plane controlProtocol specificationRelease 18TS

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

4.1 Overview

4.1.1 Floor Control

4.1.1.1 General

In a PTT group call after the call is setup, at a given time only a single group member is allowed to talk and all other affiliated group members listen to this talker. The control action for obtaining this mode of operation is known as floor control. The direct actors of floor control are the floor participants and the floor control server. A floor participant does the floor control related actions in the MCPTT client. The floor control server is the decision maker of the floor control. In on-network the floor control server is in the MCPTT server with the controlling role. In off-network no specific floor control server exists. The current talker plays the role of floor control server.

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

NOTE: End-user actions as operation of the PTT button illustrates functionality but no end-user actions are mandated by the present document.

4.1.1.2 On-network floor control

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

When all group members are silent, a group member can press the PTT button, meaning the request for permission to talk. The floor participant entity of this user reflects this request to the floor control server by sending a Floor Request message. If the floor control server decides to permit, it informs this permission for this request by sending a Floor Granted message to the requesting group member. The floor control server informs the initiation of the talk to the other group members by sending a Floor Taken message. Once the group member receives the permission, a permission indication (permission tone) is generated by the client to inform the user that they can talk. The media packets (encoded voice) are sent to the controlling MCPTT server and from there they are distributed to all listeners of this group. The release of the PTT button indicates the user’s intention to end talking. Once the PTT button is released, the floor participant sends a Floor Release message to the floor control server indicating that this user has finished talking. This cycle, starting from the Floor Granted message and ending with Floor Release message, is known as ‘talk burst’ or ‘media burst’.

In the beginning of a call the initial talk permission request can be implied by the SIP message which initiates the call as specified in 3GPP TS 24.379 [2] without any specific Floor Request message. For ambient listening, the implied talk permission request can be applied to the user on the originating side or to the user on the terminating side.

A group member can also request permission to talk by sending a Floor Request message during a talk burst. The floor control server can resolve this request in several ways.

1. If this request has higher priority than the ongoing talk burst, the floor control server revokes the current talk burst by sending a Floor Revoke message to the current talker. The current talker is interrupted and the current media burst is ended by the current floor participant by sending a Floor Release message. Then the floor control server sends a Floor Granted message to the revoking user and send Floor Taken message to other group members. Then a new media burst starts.

2. If this request does not have higher priority and floor request queueing is not used the floor control server rejects this request by sending a Floor Deny message to the requester. Then a reject indication (reject tone) is generated for the user. The ongoing talk burst continues.

3. If request queueing is used the floor control server sends Floor Queue Position Info message indicating that there is no permission but the request is queued for potential permission when the current talk burst ends. Then a "queued" indication is generated for the user. The ongoing talk burst continues.

In the case of an ambient listening call, the user initially granted the floor retains the floor for the duration of the call.

During a talk burst, a queued user can ask its position in the queue by sending a Floor Queue Position Request message. Then the floor control server provides the information by sending Floor Queue Position Info message. A queued user can also remove itself from the queue by sending a Floor Release message. This kind of message exchange during a talk burst does not affect the ongoing talk burst.

If request queueing is used, by the end of a talk burst, the floor control server gives the talk permission to the first pending request in the queue. For this, it sends the same messages as in the beginning of a talk burst; Floor Granted message to the permitted user and Floor Taken message to other group members. The permitted user is expected to press the PTT button after the permission tone within a well-defined short period of time. If PTT button is pressed the media burst continues normally until it is released. If not, the MCPTT client loses the talk permission.

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

A floor request with pre-emptive priority can be granted without revoking the current speaker. In this case media from both the overridden current talker and the overriding MCPTT user is distributed to selected participants at the same time. The list of participants that receive the overriding, overridden, or both transmissions is based on configuration.

Pre-emptive priority without revoking the current talker is not applicable if the group is configured for audio cut-in floor control.

If a group is configured as multi-talker group, floor request can be granted to a group member which is allowed to talk in this group without revoking the current talker, provided the number of simultaneous talkers is not greater than "maximum number of simultaneous talkers". If the upper limit is reached one of the talkers can be revoked or the current request can be denied based on relative priorities. If configured, when the floor request of an allowed user is not granted the participant requesting the floor may also be queued.

During silence (when no talk burst is ongoing), the floor control server can send Floor Idle message to all floor participants from time to time. The floor control server sends Floor Idle message in the beginning of silence.

Some of the floor 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 floor control

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

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

When a floor control server gives talk permission it sends a Floor Granted message. The information element which expresses the group member, to which this talk permission is given, implies to the other group members that the floor is taken. No other Floor Taken message is sent.

After silence, a floor participant asks for talk permission by sending a Floor Request message. After a well-defined waiting period, if no response is received, this floor participant sends a Floor Taken message indicating itself in the information element which expresses the group member to which this talk permission is given and continues the talk burst.

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

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

Audio cut-in floor control is not applicable for off-network.

4.1.1.4 Determine on-network effective priority

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

1. the floor priority, using the value of the Floor Priority field in the Floor Request message;

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

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

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

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

6. the effective priority of the floor 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 [12] or information stored in the controlling MCPTT function outside the scope of the present document.

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

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

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

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

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

4.1.1.5 Determine off-network effective priority

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

1. the floor priority, using the value of the Floor Priority field in the Floor Request message;

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

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

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

5. the effective priority of the floor 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 floor control participant can determine that a floor request is:

1. pre-emptive such that the current talker is revoked;

2. not pre-emptive and put in the floor request queue, if the value of "/<x>/<x>/OffNetwork/QueueUsage" leaf node present in the group configuration as specified in 3GPP TS 24.483 [4] 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 [4] is set to "false".

4.1.2 Pre-established session call control

4.1.2.1 General

An MCPTT client can pre-establish a session with the participating MCPTT function for potential use when a call is setup. The establishment, the modification and the release of a pre-established session are specified in 3GPP TS 24.379 [2].

NOTE: The establishment of a pre-established session, for potential use when a call is setup, depends on the policy chosen by the MCPTT service provider.

A pre-established session can be used when initiating a pre-arranged group call, a chat group call or a private call. Similarly, a pre-established session can be released for reuse after the termination of a pre-arranged group call, chat group call and private call.

The media plane control messages related to call setup over a pre-established session are sent over the channel used for media plane control. The media plane control messages related to the release of a call which was setup over a pre-established session, without terminating the pre-established session, are sent over the channel used for media plane control. The unicast channel for media plane control is over the MCPTT-4 reference point.

4.1.2.2 Call setup over pre-established session

For a pre-arranged group call, when the originator initiates the call setup indicating the use of a pre-established session using SIP messages as specified in 3GPP TS 24.379 [2], the participating MCPTT function (which serves the originating MCPTT client) sends to the originating MCPTT client a Connect message after the controlling MCPTT function accepts the initiation of this call. After the reception of this Connect message the originating MCPTT client sends an Acknowledgment message indicating that the connection is accepted or indicating that the connection is not accepted. If the connection is accepted by the originating MCPTT client, the floor control for this call continues as specified in clause 6.

For a pre-arranged group call if the controlling MCPTT function as triggered by an originating group member initiates a call as specified in 3GPP TS 24.379 [2], the participating MCPTT function which serves the terminating MCPTT client sends a Connect message to all affiliated MCPTT clients of this group. After the reception of the Connect message the terminating MCPTT client sends an Acknowledgment message indicating that the connection is accepted or indicating that the connection is not accepted. If the connection is accepted by the terminating MCPTT client, the floor control for this call continues as specified in clause 6.

NOTE: If a terminating client does not have an available pre-established session, the call setup proceeds as in on-demand call setup as specified in 3GPP TS 24.379 [2].

For a chat group call, a group member can use a pre-established session when joining the chat group using SIP messages as specified in 3GPP TS 24.379 [2]. For a group member that has already joined the chat group call, the floor control between the MCPTT client (floor participant) and the MCPTT server (floor control server) continues as specified in clause 6.

For a private call the procedures for the originator are the same as for the originator initiating a call for a pre-arranged call setup over a pre-established session, with the difference that the recipient of the call is a private user and not a pre-arranged group.

For a private call if the controlling MCPTT function as triggered by the originator initiates a call as specified in 3GPP TS 24.379 [2], the participating MCPTT function (which serves the terminating MCPTT client) sends a Connect message to the terminating MCPTT client served by the participating MCPTT function if this MCPTT client has an available pre-established session and the commencement mode is automatic. If the commencement mode is manual the terminating MCPTT client is invited using SIP procedures as specified in 3GPP TS 24.379 [2].

4.1.2.3 Release of a call which uses a pre-established session

When a call is released by the controlling MCPTT function (as specified in 3GPP TS 24.379 [2]), the participating MCPTT function sends a Disconnect message to all MCPTT clients which used a pre-established session for this call. Then the call is released (see also 3GPP TS 24.379 [2]) and the pre-established session can be used for another call.

When an MCPTT client leaves a call (as specified in 3GPP TS 24.379 [2]) which was setup over a pre-established session without releasing the pre-established session, this pre-established session can be used for another call.

A call setup over a pre-established session can also be released by using the specifications in 3GPP TS 24.379 [2] (without the use of Disconnect message). As a result the pre-established session, which has been used for this call, is also released.

4.1.3 MBMS subchannel control

4.1.3.1 General

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

The participating MCPTT 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 MCPTT clients in the MBMS service area of this MBMS bearer. This announcement enables the MCPTT 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 MCPTT 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 MCPTT 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 MCPTT 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 MCPTT user profile that is downloaded to the MCPTT UE.

4.1.3.2 Start of a conversation

When a conversation is started (by an originating MCPTT client of a group) the participating MCPTT 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 conversation is ongoing for improving the reception probability and to allow MCPTT clients arriving late to listen to the MBMS subchannel.

The same MBMS subchannel can be used for media and media control plane of an MCPTT group, subjected to the restrictions stated in IETF RFC 5761 [7].

4.1.3.3 During a conversation

If an MBMS subchannel exists, the participating MCPTT function forwards the media plane control messages, received from the controlling MCPTT function via MBMS subchannel for media plane control. Only floor control messages which are transmitted to more than one affiliated group member are forwarded to the MBMS bearer (e.g. the Floor Taken and Floor Idle messages). The floor control messages can be repeated a configurable number of times for improving the reception probability. The participating MCPTT function forwards the media packets, received from the controlling MCPTT function, via the MBMS subchannel for media.

Amongst all affiliated group members under this participating MCPTT function, the participating MCPTT function is informed or is enabled to deduce the group members which do not or cannot receive the MBMS subchannels. The participating MCPTT function forwards the media packets and the media plane control messages, received from the controlling MCPTT 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.3.4 Ending the conversation

The participating MCPTT function can de-allocate an MBMS subchannel after a configurable period of silence in the conversation 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 conversation of another group.

NOTE: The participating MCPTT function will activate MBMS bearers with general QoS characteristics suitable for MCPTT 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.3.5 Starting a call over unicast bearers

The participating MCPTT function can prior to starting a call over unicast bearers send an Application Paging message, using the MBMS subchannel, to the group intended for the conversation. The procedures to initiate the conversation over the unicast bearers then proceed as described in clause 10.

4.1.3.6 Moving a conversation to unicast bearers

The participating MCPTT function can move an ongoing conversation from an MBMS bearer to unicast bearers by first sending an Application Paging message using the MBMS subchannel, and then sending an Unmap Group To Bearer message. After the Unmap Group To Bearer message the conversation continues using the unicast bearers.

4.1.3.7 MBMS bearer announcement over an MBMS bearer

The participating MCPTT 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 MCPTT 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 MCPTT function

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

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

Figure 4.2.1-1: Internal structure of floor control in the controlling MCPTT function

All entities in the controlling MCPTT 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 MCPTT-3 is described in 3GPP TS 23.379 [5].

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

The floor control arbitration logic is performing the floor control. The floor control arbitration logic is controlled by a state machine described in clause 6.3.4. One state machine is needed per MCPTT call.

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

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

The media distributor is controlled by the floor control arbitration logic. The media distributor is out of scope of the present document. One media distributor is needed per MCPTT call.

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

1. The interface between the network media interface and the floor control interface towards the MCPTT client:

a. Indication that the network media interface has started to receive media packets from the associated MCPTT client or that media packets are no longer received from the associated MCPTT 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 floor control interface towards the MCPTT client and the floor control arbitration logic:

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

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

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

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

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

5. The interface between the floor control interface towards the MCPTT client and the floor request queue:

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

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

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

4.2.2 MCPTT client

According to 3GPP TS 23.379 [5] the MCPTT client is divided into a floor participant and a media mixer function. In the present document the internal structure of the MCPTT client is illustrated in figure 4.2.2-1.

NOTE: The real internal structure of the MCPTT 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 MCPTT client

All entities in the MCPTT 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 MCPTT-4, MCPTT-7, MCPTT-8 and MCPTT-9 are described in 3GPP TS 23.379 [5].

The floor participant receives and sends floor control and pre-established session 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 floor participant when RTP media packets are received and when RTP media packets are no longer received. The floor 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 floor control messages and MBMS subchannel control messages over the MBMS bearer. The MBMS interface forward received floor control messages to the floor participants.

The floor participant receives indication from the MCPTT client when the MCPTT user has pressed or released the PTT button. The MCPTT client can also provide notification towards the MCPTT user. Voice received from the MCPTT user is, on instruction from the floor participant, encoded by the media mixer and sent as RTP media packets over the unicast bearer.

4.2.3 Participating MCPTT function

4.2.3.1 General

The participating MCPTT function performs the participating role of an MCPTT server as defined in 3GPP TS 23.379 [5]. The participating MCPTT function uses media plane control (non-SIP) messages when taking part in the floor control procedures as specified in clause 6, call over pre-established session as specified in clause 9 and the use of MBMS Bearer procedures as specified in clause 10. In the sequel the term ‘controlling MCPTT function’ is used for the entity which performs the controlling role of an MCPTT server.

The following clauses describe the assumed internal structure of a participating MCPTT function and the role of the participating function in the floor control procedures, the call over pre-established session procedures and the use of MBMS Bearer procedures.

4.2.3.2 Internal structure of the participating MCPTT function

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

NOTE: The real internal structure of the participating MCPTT 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 MCPTT client

All entities in the participating MCPTT 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 MCPTT-3, MCPTT-4, MCPTT-7, MCPTT-8 and MCPTT-9 are described in 3GPP TS 23.379 [5].

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

The MBMS bearer management receives floor control message and RTP media packets from the media and floor control message distribution when floor control messages and RTP media packets are sent over an MBMS bearer. MBMS bearer management also generates MBMS subchannel control message. Floor 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 MCPTT function

4.2.3.3.1 For the floor control procedures

When a floor control message or a media packet is received from an MCPTT client, in the MCPTT-4 and MCPTT-7 reference points respectively, the participating MCPTT function forwards it to the controlling MCPTT function over MCPTT-3 reference point or to the application and signalling plane. When a floor control message or a media packet is received from the controlling MCPTT function, over MCPTT-3 reference point or the application and signalling plane, for MCPTT clients which do not use an MBMS subchannel, the participating MCPTT function forwards the floor control message to the MCPTT client over the MCPTT-4 and MCPTT-7 reference points respectively. For MCPTT clients which use an MBMS subchannel, for floor control messages directed to all of these MCPTT clients and for media packets, the participating MCPTT function forwards a single floor control message or a single media packet using the MBMS subchannel over MCPTT-9 and MCPTT-8 reference points respectively.

When MCPTT clients are listening to the MBMS subchannel multiple copies of the same media packet destined to each individual MCPTT client are sent by the controlling MCPTT function while the participating MCPTT function only forwards one single media packet over the MBMS bearer. Any optimizations for not sending the media packet from the controlling MCPTT function to all MCPTT clients are out of scope of the present document.

When MCPTT clients are listening to the MBMS subchannel multiple copies of the same Floor Idle message and Floor Taken message destined to each individual MCPTT client are sent by the controlling MCPTT function while the participating MCPTT function only forwards one single Floor Idle or Floor Taken message over the MBMS bearer. Any optimizations for not sending the Floor Idle or Floor Taken message from the controlling MCPTT function to all MCPTT clients are out of scope of the present document.

The participating MCPTT function specifications related to the floor control are specified in clause 6.4 for unicast media and media plane control delivery and in clause 10.3.3 for MBMS delivery.

4.2.3.3.2 For the call over pre-established session procedures

For a pre-established session between an MCPTT client and the participating MCPTT function, when a call is initiated over this pre-established session, the participating MCPTT function informs the originating MCPTT client the acceptance or rejection decision of the controlling MCPTT function by sending Connect or Disconnect messages respectively over MCPTT-4 reference point. When a call initiation is accepted by the controlling server and informed to the participating MCPTT function, the participating MCPTT function informs the terminating MCPTT client which has a pre-established session the initiation of this call, using Connect message over MCPTT-4 reference point.

When the controlling MCPTT function informs the participating MCPTT function that a call which is setup over a pre-established session is released (either over the MCPTT-3 reference point or from application and signalling plane), the participating MCPTT function informs the MCPTT client the release of this call using Disconnect message over MCPTT-4 reference point. By the end of the release of the call the pre-established session is reserved for possible future use.

When an Acknowledgment message is received, over the MCPTT-4 reference point, as result of a message informing the MCPTT client for the initiation, the rejection or the release related to a call conducted over a pre-established session, the participating MCPTT function communicates the positive or negative acknowledgment information towards the controlling MCPTT function according to the procedures in 3GPP TS 24.379 [2] (either over MCPTT-3 reference point or from application and signalling plane).

The participating MCPTT function specifications related to the call setup over pre-established session are in clause 9.3.

4.2.3.3.3 For the use of MBMS bearer procedures

In the initiation of a conversation, if the MBMS bearer management in the participating MCPTT function decides to use an MBMS subchannel for the media plane control messages and the media packets, the participating MCPTT function sends a Map Group To Bearer message over the MCPTT-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 subchannel using the general purpose MBMS subchannel already associated for the transmission of this information. In the termination of a conversation the participating MCPTT function sends an Unmap Group To Bearer message for terminating the association between the MBMS subchannel in use for this conversation and the group identity.

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

4.2.4 Non-controlling MCPTT function of an MCPTT group

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

NOTE: The real internal structure of the MCPTT 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 MCPTT function

All entities in the non-controlling MCPTT function of an MCPTT 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 floor participant interface receives and transmits the floor control messages from and to the MCPTT client via the participating MCPTT function or non-controlling MCPTT function. The procedures are controlled by a state machine described in clause 6.5.5. One state machine is needed for each MCPTT client participating in an MCPTT call. A non-controlling MCPTT function is seen by the floor participant interface as an MCPTT client.

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

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

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

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

a. Indication that the network media interface has started to receive media packets from the associated MCPTT client and requests from the floor 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 floor participant interface and the floor control server interface:

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

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

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

4. The interface between the floor 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 floor control protocol, the pre-established session call 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 [3]. The MCPTT 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 MCPTT client and the MCPTT 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>	"MCPTT"

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 MCPTT

a=fmtp:MCPTT mc_queueing;mc_priority=5;mc_granted