6.5 Non-controlling MCPTT function of an MCPTT group

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

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

6.5.1 General

The floor control server interface in the non-controlling MCPTT function of an MCPTT group shall support the procedures in clauses 6.5.2, 6.5.3 and 6.5.4.

The floor participant interface in the non-controlling MCPTT function of an MCPTT group shall support the procedures in clause 6.5.5.

6.5.2 The MCPTT call initialization procedure in the non-controlling MCPTT function of an MCPTT group

6.5.2.1 General

The clause 6.5.2.2 describes the initial procedures when a new SIP session is establishing a group session.

The clause 6.5.2.3 describes the procedure for switching from a controlling MCPTT function mode to a non-controlling MCPTT function mode.

6.5.2.2 Initial procedures when a new SIP session is establishing a group session

When receiving an indication from the application and signalling plane that a group session is initiated, the floor control server interface:

1. shall initiate and store a message sequence number value with the value to be used in the Message Sequence Number field in the Floor Idle and Floor Taken messages;

2. shall for each MCPTT client in the MCPTT group controlled by the non-controlling MCPTT function that are participating in the session:

a. generate a random temporary identifier between ‘0’ and ‘4294967295’;

b. store an association between the generated temporary identifier and the floor participant interface;

c. store information about capabilities negotiated in the "mc_queueing" and "mc_priority" fmtp attributes as described in clause 14;

d. store information whether the MCPTT client requested privacy or not; and

e. initiate an instance of the ‘floor participant interface state transition’ state machine as specified in clause 6.5.5; and

3. shall perform the actions in the clause 6.5.4.

When receiving an indication from the application and signalling plane that an MCPTT client has accepted an invitation to the session, the floor participant interface shall perform the actions in clause 6.5.5.

6.5.2.3 Switching from a controlling MCPTT function mode to a non-controlling MCPTT function mode

6.5.2.3.1 Overview

The switching from working in a controlling MCPTT functional mode to a non-controlling MCPTT functional mode is a 2-step procedure.

Step 1 The controlling MCPTT function prepares for acting as a non-controlling MCPTT function. The step 1 procedure is specified in clause 6.5.2.3.2.

Before continuing with step 2 the application and signalling plane needs to receive a confirmation that the SIP session between the floor control server and the interface to the floor control server is established.

Step 2 The controlling MCPTT functions starts acting as a non-controlling MCPTT function. The step 2 procedure is specified in clause 6.5.2.3.3.

6.5.2.3.2 Preparing for the switch to non-controlling MCPTT function (Step 1)

When receiving a request from the application and signalling plane to prepare for merging with another group session, the floor control server:

1. if in the ‘G: taken’ state, shall provide information about current speaker to the signalling and application plane;

NOTE: The signalling and application plane will use the information about the current speaker to send a floor request in an SIP MESSAGE request as specified in 3GPP TS 24.379.

2. shall release the instant used for ‘general floor control operation’; and

3. shall for each MCPTT client in the MCPTT group controlled by the controlling MCPTT function and participating in the session:

a. generate a random temporary identifier between ‘0’ and ‘4294967295’;

b. store an association between the generated temporary identifier and the floor participant interface;

c. store information about capabilities negotiated in the "mc_queueing" and "mc_priority" fmtp attributes as specified in clause 14;

d. store information whether the MCPTT client requested privacy or not; and

e. initiate an instance of the ‘floor participant interface state transition’ state machine as specified in clause 6.3.5.8.3.

6.5.2.3.3 Start acting as a non-controlling MCPTT function (Step 2)

When receiving a request from the application and signalling plane to finalize the switch to non-controlling MCPTT function behaviour, the floor control server:

1. shall start acting as a floor control server interface;

2. if an active floor request queue exists, for each queued floor request in the active floor request queue:

NOTE: The active floor request queue was built up when the non-controlling MCPTT function was acting as a floor control server.

a. shall send a Floor Request message to the floor control server. The Floor Request:

i. shall include all fields included by the floor participant;

ii. if a Track Info field is included, shall include the temporary identifier at the end of the <Floor Participant Reference> value item; and

iii. if a Track Info field is not included, shall include a Track Info field populated as follows:

A. shall include the "mc_queueing" fmtp attribute value negotiated as specified in clause 14 in the <Queueing Capability> value;

B. shall include a <Participant Type> value based on the <participant-type> element specified in 3GPP TS 24.481 [12], if value in the <participant-type> element is available, otherwise set the <Participant Type> value to "unknown"; and

C. shall include the temporary identifier as the first <Floor Participant Reference> value;

3. if an active floor request queue exists, shall move the active floor request queue to a passive floor request queue; and

4. shall perform the actions in the clause 6.5.4.

When receiving an indication from the application and signalling plane that an MCPTT client has joined the session, the floor participant interface shall perform the actions in clause 6.5.5.

6.5.3 The MCPTT call release procedure in the non-controlling MCPTT function of an MCPTT group

When an MCPTT client leaves an MCPTT call and the MCPTT call remains ongoing with the other MCPTT clients, the non-controlling MCPTT function of an MCPTT group follows a two-step procedure:

Step 1 The floor participant interface stops sending floor control messages and RTP media packets to the MCPTT client leaving the MCPTT call and the floor participant interface discards floor control messages and RTP media packets received from the MCPTT client leaving the MCPTT call; and

Step 2 When the application and signalling plane has determined that the session with this floor participant has been released, the corresponding instance of the ‘floor participant interface state transition’ state machine is released.

When an MCPTT call is released, the floor control server interface follows a two-step procedure:

Step 1 The floor control server interface stops sending floor control messages and RTP media packets to MCPTT clients in the MCPTT call; and

Step 2 When the application and signalling plane has determined that the MCPTT call has been released, resources in the floor control server interface are released, along with all ‘floor participant interface state transition’ state machines.

The non-controlling MCPTT function of an MCPTT group can initiate an MCPTT call release depending on the release policy specified in 3GPP TS 24.379 [2].

6.5.4 Floor control server interface procedures

6.5.4.1 General

The floor control server interface is stateless with regards to the floor control message received and sent.

The following clauses specifies what the floor control server interface shall do when receiving a floor control message sent by the controlling MCPTT function or received at the floor participant interface and how the floor control server controls the media distribution function in the non-controlling MCPTT function.

6.5.4.2 Receiving a Floor Request message

Upon receiving a Floor Request message from one floor participant interface, the floor control server interface:

1. shall forward the Floor Request message to the controlling MCPTT function. The Floor Request message:

a. shall include all fields included by the floor participant;

b. if a Track Info field is included, shall include the temporary identifier at the end of the <Floor Participant Reference> value item; and

c. if a Track Info field is not included, shall include a Track Info field populated as follows:

i. shall include the "mc_queueing" fmtp attribute value negotiated as specified in clause 14 in the <Queueing Capability> value;

ii. shall include a <Participant Type> value based on the <participant-type> element specified in 3GPP TS 24.481 [12], if value in the <participant-type> element is available, otherwise set the <Participant Type> value to "unknown"; and

iii. shall include the temporary identifier as the first <Floor Participant Reference> value; and

2. if the value of the <Queueing Capability> in the Track Info is ‘1’ (the floor participant in the MCPTT client supports queueing), shall store the outgoing Floor Request message in the passive floor request queue.

6.5.4.3 Receive Floor Release message

Upon receiving a Floor Release message from one floor participant interface, the floor control server interface:

NOTE: A Floor Release message can be received from the permitted floor participant and from any participant that is queued in the floor control server.

1. shall forward a Floor Release message to the controlling MCPTT function. The Floor Release message:

a. shall include all fields included by the floor participant in the Floor Release message;

b. if a Track Info field is included, shall include the temporary identifier at the end of the <Floor Participant Reference> value item; and

c. if a Track Info field is not included, shall include a Track Info field as follows:

i. shall include the "mc_queueing" fmtp attribute value negotiated as specified in clause 14 in the <Queueing Capability> value; and

ii. shall include the temporary identifier as the first <Floor Participant Reference> value; and

2. if a Floor Request message received from this floor participant is in the passive floor request queue, shall remove the floor request from the passive floor request queue.

6.5.4.4 Receive Floor Queue Position Request message

Upon receiving a Floor Queue Position Request message from one floor participant interface, the floor control server interface:

1. shall forward the Floor Queue Position Request message to the controlling MCPTT function. The Floor Queue Position Request message:

a. shall include all fields included by the floor participant;

b. if a Track Info field is included, shall include the temporary identifier at the end of the <Floor Participant Reference> value item; and

c. if a Track Info field is not included, shall include a Track Info field as follows:

i. shall include the "mc_queueing" fmtp attribute value negotiated as specified in clause 14 in the <Queueing Capability> value; and

ii. shall include the temporary identifier as the first <Floor Participant Reference> value.

6.5.4.5 Receive Floor Ack message

Upon receiving a Floor Ack message from one floor participant interface the floor control server interface:

1. shall send the Floor Ack message towards the controlling MCPTT function. The Floor Ack message:

a. shall include all fields included by the floor participant in the Floor Ack message;

b. if Track Info field is included, shall include the temporary identifier at the end of the <Floor Participant Reference> value item; and

c. if a Track Info field is not included, shall include a Track Info field with temporary identifier as the first <Floor Participant Reference>.

6.5.4.6 Receive Floor Granted message

Upon receiving a Floor Granted message sent from the controlling MCPTT function, the floor control server interface:

1. shall send the Floor Granted to the floor participant interface identified by the <Participant Reference> value at the end of the Track Info field. The Floor Granted message:

a. shall include the fields as received with the following exceptions:

i. if the Track Info field only contains one <Participant Reference> value, shall remove the Track Info field from the outgoing Floor Granted message; and

ii. if the Track Info field contains more than one <Participant Reference> value, shall remove the last <Participant Reference> value from the Track Info field from the outgoing Floor Granted message; and

b if the Floor Indicator field is included in the Floor Granted message and the G-bit is set to ‘1’ (Dual floor), shall store the SSRC of granted floor participant and associate the stored value with dual floor;

2. if:

a. a SSRC of granted floor participant and associate the stored value with dual floor is not stored, shall send a Floor Taken message populated as specified in step d. below to all participant interfaces with the exception of the floor participant interface to which the Floor Granted message is sent;

b. a SSRC of granted floor participant associate with dual floor is stored and if the Floor Indicator field is not included in the Floor Granted message or if the Floor Indicator field is included in the Floor Granted message and the G-bit is set to ‘0’ (Not dual floor), shall send a Floor Taken message populated as specified in step d. below to all participant interfaces with the exception of:

i. the floor participant interface to which the Floor Granted message is sent; and

ii. the floor participants only listening to the overriding floor participant;

c. the Floor Indicator field is included in the Floor Granted message and the G-bit is set to ‘1’ (Dual floor):

i. shall send a Floor Taken message populated as specified in step d. below to floor participants that will listen to the RTP media from the overriding MCPTT client according to local policy;

NOTE 1: The MCPTT client overridden by the overriding MCPTT client is still sending voice (overridden). The list of floor participants that receive the overriding, overridden, or both transmissions is based on configuration.

d. The Floor Taken message:

i. shall include the granted MCPTT user’s MCPTT ID in the Granted Party’s Identity field and may include the functional alias of the granted MCPTT user in the Functional Alias field, if privacy is not requested by the granted floor participant when the MCPTT client was invited to the session;

NOTE 2: The privacy request was stored for each invited MCPTT client when the MCPTT client accepted the invitation as specified in clause 6.5.2.

ii. shall include in the Message Sequence Number field the local <Message Sequence Number> value increased with 1;

iii. shall include the Permission to Request Floor field to ‘0’, if the group call is a broadcast group call;

iv. may include the Permission to Request the Floor field set to ‘1’, if the group call is not a broadcast group call; and

v. shall set the first bit in the subtype of the Floor Taken message to ‘0’ (acknowledgement is not required); and

NOTE 3: A Floor Taken message sent to all participants does not require acknowledgement.

e. if the Floor Indicator field was included in the Floor Granted message, shall include the received Floor Indicator field; and

3. if the Floor Request message received from the floor participant is in the passive floor request queue, shall remove the floor request from the passive floor request queue; and

4 if the Floor Indicator field is included in the Floor Granted message and the G-bit is set to ‘1’ (Dual floor), shall send a Floor Idle message to those floor participants that will only listen to RTP media from the overriding MCPTT client. The Floor Idle message:

a. shall include the Floor Indicator field as received in the Floor Granted message with the G-bit set to ‘0’ (Not dual floor); and

b. shall include in the Message Sequence Number field the local <Message Sequence Number> value increased with 1.

6.5.4.7 Receive Floor Deny message

Upon receiving a Floor Deny message sent from the controlling MCPTT function, the floor control server interface:

1. shall use the <Participant Reference> value at the end of the Track Info field to identify the floor participant interface;

2. if:

a. the Track Info field only contains one <Participant Reference> value, shall remove the Track Info field from the outgoing Floor Granted message; and

b. if the Track Info field contains more than one <Participant Reference> value, shall remove the last <Participant Reference> value from the Track Info field;

3. shall forward the Floor Deny message to the floor participant interface; and

4. if the Floor Request message received from the floor participant is in the passive floor request queue, shall remove the floor request from the passive floor request queue.

6.5.4.8 Receive Floor Idle message

Upon receiving a Floor Idle message sent from the controlling MCPTT function, the floor control server interface:

NOTE 1: The Floor Idle message can be either destined to floor participants in all MCPTT clients or is sent to the floor participant in a specific MCPTT client. In the latter case the Floor Idle message contains the Track Info field.

1. if the Floor Idle message contains a Track Info field;

a. shall use the <Participant Reference> value at the end of the Track Info field to identify the floor participant interface;

b. if:

i. the Track Info field only contains one <Participant Reference> value:

A. shall remove the Track Info field from the outgoing Floor Idle message;

B. shall increase the stored message sequence number value with 1; and

C. shall include in the Message Sequence Number field the local <Message Sequence Number> value increased with 1; and

ii. if the Track Info field contains more than one <Participant Reference> value, shall remove the last <Participant Reference> value from the Track Info field; and

c. shall send the Floor Idle message to the floor participant interface;

2. if the Floor Idle message does not contain a Track Info field;

a. shall set the first bit in the subtype of the Floor Idle message to ‘0’ (acknowledgement is not required);

NOTE 2: A Floor Idle message sent to all participants does not require acknowledgement.

b if:

i. the Floor Indicator field is not included in the Floor Idle message or if the Floor Indicator field is included and the G-bit is set to ‘0’ (Not dual floor), shall send the Floor Idle message to all floor participant interfaces. The Floor Idle message:

A. shall include received fields; and

B. shall include in the Message Sequence Number field the local <Message Sequence Number> value increased with 1; and

ii. the Floor Indicator field is included in the Floor Idle message and the G-bit is set to ‘1’ (Dual floor),

A. shall send the Floor Idle message to floor participants listening to the overriding MCPTT client according to local policy. The Floor Idle message:

– shall include received fields; and

– shall include in the Message Sequence Number field the local <Message Sequence Number> value increased with 1; and

B. shall discard the stored SSRC of granted floor participant associated with a dual floor;

c. shall send a Floor Ack message towards the controlling MCPTT function if the first bit in the subtype of the received Floor Idle message is set to ‘1’ (acknowledgement is required) as specified in clause 8.2.2. The Floor Ack message:

i. shall include the Source field set to ‘3’ (the non-controlling MCPTT function is the source); and

ii. shall include the Message Type field set to ‘5’ (Floor Idle); and

3. shall empty the passive floor request queue.

6.5.4.9 Receive Floor Taken message

Upon receiving a Floor Taken message sent from the controlling MCPTT function, the floor control server interface:

NOTE 1: The Floor Taken message can be either destined to floor participants in all MCPTT clients or is sent to the floor participant in a specific MCPTT client. In the latter case the Floor Taken message contains the Track Info field.

1. if the Floor Taken message contains a Track Info field;

a. shall use the <Participant Reference> value at the end of the Track Info field to identify the floor participant interface;

b. if the Track Info field only contains one <Participant Reference> value:

A. shall remove the Track Info field from the outgoing Floor Taken message; and

B. shall include in the Message Sequence Number field the local <Message Sequence Number> value increased with 1;

c. if the Track Info field contains more than one <Participant Reference> value, shall remove the last <Participant Reference> value from the Track Info field; and

d. shall send the Floor Taken message to the floor participant interface;

2. if the Floor Taken message does not contain a Track Info field:

a. shall set the first bit in the subtype of the Floor Taken message to ‘0’ (acknowledgement is not required);

NOTE 2: A Floor Taken message sent to all participants does not require acknowledgement.

b. if the Floor Indicator field is included in the Floor Taken message and the G-bit is set to ‘1’ (Dual floor), shall store the SSRC of granted floor participant and associate the stored SSRC with dual floor;

c. if there is no stored SSRC of granted floor participant associated with a dual floor, shall send the Floor Taken message to all floor participant interfaces. The Floor Taken message:

i. shall include all received fields with the exception of the Message Sequence Number field;

ii. shall include in the Message Sequence Number field the local <Message Sequence Number> value increased with 1;

d. if there is a stored SSRC of granted floor participant associated with a dual floor:

i. if the Floor Indicator field is not included in the Floor Taken message or if the Floor Indicator field is included in the Floor Taken message and the G-bit is set to ‘0’ (Not dual floor), shall send the Floor Taken message to all floor participant interfaces with the exception of the floor participants only listening to RTP media from the overriding floor participant. The Floor Idle message:

A. shall include all received fields; and

B. shall include in the Message Sequence Number field the local <Message Sequence Number> value increased with 1; and

ii. if the Floor Indicator field is included in the Floor Taken message and the G-bit is set to ‘1’ (Dual floor):

A. shall send the Floor Taken message to all floor participants listening to the RTP media from the overriding MCPTT client according to local policy. The Floor Taken message:

– shall include all received fields; and

– shall include in the Message Sequence Number field the local <Message Sequence Number> value increased with 1; and

B. shall send a Floor Idle message to those floor participants that will only listen to RTP media from the overriding MCPTT client according to local policy. The Floor Idle message:

– shall include all received fields;

– shall include in the Message Sequence Number field the local <Message Sequence Number> value increased with 1; and

– shall update the received Floor Indicator field and set the G-bit to ‘0’ and;

e. shall send a Floor Ack message towards the controlling MCPTT function if the first bit in the subtype of the received Floor Taken message is set to ‘1’ (acknowledgement is required) as specified in clause 8.2.2. The Floor Ack message:

i. shall include the Source field set to ‘3’ (the non-controlling MCPTT function is the source); and

ii. shall include the Message Type field set to ‘2’ (Floor Taken);

6.5.4.10 Receive Floor Revoke message

Upon receiving a Floor Revoke message from the controlling MCPTT function, the floor control server interface:

1. shall use the <Participant Reference> value at the end of the Track Info field to identify the floor participant interface;

2. if:

a. the Track Info field only contains one <Participant Reference> value, shall remove the Track Info field from the outgoing Floor Revoke message; and

b. if the Track Info field contains more than one <Participant Reference> value, shall remove the last <Participant Reference> value from the Track Info field; and

3. shall forward the Floor Revoke message to the floor participant interface.

6.5.4.11 Receive Floor Queue Position Info message

Upon receiving a Floor Queue Position Info message from the controlling MCPTT function, the floor control server interface:

1. shall use the <Participant Reference> value at the end of the Track Info field to identify the floor participant interface;

2. if:

a. the Track Info field only contains one <Participant Reference> value, shall remove the Track Info field from the outgoing Floor Granted message; and

b. if the Track Info field contains more than one <Participant Reference> value, shall remove the last <Participant Reference> value from the Track Info field; and

3. shall forward the Floor Queue Position Info message to the floor participant interface.

6.5.4.12 Receive RTP media packets from controlling MCPTT function

Upon receiving an indication from the media distributor that RTP media packets are received from the controlling MCPTT function, the floor control server interface:

1. if a SSRC of granted floor participant associated with a dual floor is not stored shall request the network media distributor to forward received RTP media packets to all MCPTT clients in the session controlled by the non-controlling MCPTT function where the SSRC of the received RTP media packets are different to SSRC used by an MCPTT client;

NOTE: If one of the MCPTT client controlled by the non-controlling MCPTT function is granted the floor, media originated from that MCPTT client is not distributed back to the MCPTT client granted the floor.

2. if a SSRC of granted floor participant associated with a dual floor is stored and if the SSRC in the media packet is not the same as the stored SSRC, shall request the network media distributor to forward received RTP media packets to MCPTT clients controlled by the non-controlling MCPTT function:

i. where the SSRC of the received RTP media packets are different to SSRC used by the MCPTT client; and

ii. that are not only listening to the dual floor according to local policy; and

3. if a SSRC of granted floor participant associated with a dual floor is stored and if the SSRC in the media packet is the same as the stored SSRC, shall request the network media distributor to forward received RTP media packets to all MCPTT client:

i. where the SSRC of the received RTP media packets are different to SSRC used by the MCPTT client; and

ii. listening to the dual floor according to local policy.

6.5.4.13 Receive RTP media packets from an MCPTT client

Upon receiving an indication from the media distribution function that RTP media packets are received from one of the network media interfaces, the floor control server interface:

1. shall request the network media distributor to forward received RTP media packets towards the controlling MCPTT function.

NOTE: If RTP media packets are received from an MCPTT client not permitted to send media, the floor participant interface will send a Floor Revoke message to the floor participant of the misbehaving MCPTT client without involving the floor control server interface.

6.5.4.14 MCPTT session release step 1

Upon receiving an MCPTT call release step 1 request from the application and signalling plane e.g. when the session is going to be released, the floor control interface:

1. shall ignore floor control message from the floor control server;

2. shall request the media distributor to stop distributing RTP media packets to the network media interface of the MCPTT clients; and

3. shall ignore any floor control messages received from the floor participant interfaces.

6.5.4.15 MCPTT session release step 2

Upon receiving an MCPTT call release step 2 request from the application and signalling plane, the floor control server interface:

1. shall release all resources associated with this session.

6.5.4.16 Receiving a split instruction (R: Split)

Upon receiving an instruction from the application and signalling plane to split the ongoing group session, as specified in 3GPP TS 24.379 [2] in clause 10.1.1.5.2.4 for prearranged group call and in clause 10.1.2.5.1.4 for chat group call, the floor control server interface:

1. shall perform the actions in clause 6.3.2.3.

6.5.4.17 Receive Floor Release Multi Talker message

Upon receiving a Floor Release Multi Talker message sent from the controlling MCPTT function, the floor control server interface:

1. shall use the <Participant Reference> value at the end of the Track Info field to identify the floor participant interface;

2. if:

a. the Track Info field only contains one <Participant Reference> value, shall remove the Track Info field from the outgoing Floor Release Multi Talker message; and

b. the Track Info field contains more than one <Participant Reference> value, shall remove the last <Participant Reference> value from the Track Info field; and

3. shall forward the Floor Release Multi Talker message to the floor participant interface.

6.5.5 Floor participant interface procedures

6.5.5.1 General

The floor participant interface shall behave according to the state diagram and state transitions specified in this clause.

Figure 6.5.5.1-1 shows the general floor control operation states (P states) and the state transition diagram.

Figure 6.5.5.1-1: The ‘floor participant interface state transition’ state diagram

The floor participant interface shall keep one instance of the ‘floor participant interface state transition’ state machine per MCPTT client in a session.

The floor participant associated to the ‘floor participant interface state transition’ state machine is in the following clauses referred to as the associated floor participant.

If floor control messages or RTP media packets arrives in a state where there is no procedure specified in the following clauses the floor participant interface:

1. shall discard the floor control message;

2. shall request the network media interface to discard any received RTP media packet; and

3. shall remain in the current state.

State details are explained in the following clauses.

6.5.5.2 State: ‘Start-Stop’

6.5.5.2.1 General

When a new instance of the ‘Floor participant interface state transition’ state machine is initiated, before any floor control related input is applied, the state machine is in ‘Start-stop’ state. Similarly when the session is released the state machine shall return to the ‘Start-stop’ state.

6.5.5.2.2 Participant invited to session

When the floor participant interface receives an indication from the floor control server interface that an MCPTT client has accepted the invitation to a session (i.e. when the SIP 200 (OK) response to the initial SIP INVITE request is received as specified in 3GPP TS 24.379 [2]) , the floor participant interface:

1. shall enter the ‘P: has no permission’ state.

6.5.5.3 State: ‘P: has no permission’

6.5.5.3.1 General

The floor participant interface uses this state when the associated floor participant is not permitted to send media.

6.5.5.3.2 Receive Floor Idle message (R: Floor Idle)

When the floor participant interface receives a Floor Idle message from the floor control server interface, the floor participant interface:

1. shall send the Floor Idle message to the floor participant;

2. if the first bit in the subtype of the Floor Idle message is set to ‘1’ (acknowledgement is required) as specified in clause 8.2.2, shall store an indication that a Floor Ack message to a Floor Idle messages is expected; and

3. shall remain in the ‘P: has no permission’ state.

6.5.5.3.3 Receive Floor Taken message (R: Floor Taken)

When the floor participant interface receives a Floor Taken message from the floor control server interface, the floor participant interface:

1. shall send the Floor Taken message to the floor participant;

2. if the first bit in the subtype of the Floor Taken message is set to ‘1’ (acknowledgement is required) as specified in clause 8.2.2, shall store an indication that a Floor Ack message to a Floor Taken messages is expected; and

3. shall remain in the ‘P: has no permission’ state.

6.5.5.3.4 Receive Floor Request message (R: Floor Request)

When the floor participant interface receives a Floor Request message from the floor participant, the floor participant interface:

1. shall send the Floor Request message to the floor control server interface; and

2. shall remain in the ‘P: has no permission’ state.

6.5.5.3.5 Receive Floor Granted message (R: Floor Granted)

When the floor participant interface receives a Floor Granted message from the floor control server interface, the floor participant interface:

1. shall send the Floor Granted message to the floor participant;

2. if the first bit in the subtype of the Floor Granted message is set to ‘1’ (acknowledgement is required) as specified in clause 8.2.2, shall store an indication that a Floor Ack message to a Floor Granted messages is expected; and

3. shall enter the ‘P: has permission’ state.

6.5.5.3.6 Receive Floor Deny message (R: Floor Deny)

When the floor participant interface receives a Floor Deny message from the floor control server interface, the floor participant interface:

1. shall send the Floor Deny message to the floor participant;

2. if the first bit in the subtype of the Floor Deny message is set to ‘1’ (acknowledgement is required) as specified in clause 8.2.2, shall store an indication that a Floor Ack message to a Floor Deny messages is expected; and

3. shall remain in the ‘P: has no permission’ state.

6.5.5.3.7 Receive Floor Queue Position Info message (R: Floor Queue Position Info)

When the floor participant interface receives a Floor Queue Position Info message from the floor control server interface, the floor participant interface:

1. shall send the Floor Queue Position Info message to the floor participant;

2. if the first bit in the subtype of the Floor Queue Position Info message is set to ‘1’ (acknowledgement is required) as specified in clause 8.2.2, shall store an indication that a Floor Ack message to a Floor Queue Position Info messages is expected; and

3. shall remain in the ‘P: has no permission’ state.

6.5.5.3.8 Receive Floor Queue Position Request message (R: Floor Queue Position Request)

When the floor participant interface receives a Floor Queue Position Request message from the floor participant, the floor participant interface:

1. shall send the Floor Queue Position Request message to the floor control server interface; and

2. shall remain in the ‘P: has no permission’ state.

6.5.5.3.9 Receive RTP media packets (R: RTP media)

When the floor participant interface receives an indication from the network media interface that RTP media packets are received from the media distributor, the floor participant interface

1. shall instruct the network media interface to send the received RTP media packets towards the MCPTT client; and

2. shall remain in the ‘P: has no permission’ state.

When the floor participant interface receives an indication from the network media interface that RTP media packets are received from the MCPTT client, the floor participant interface

1. shall send a Floor Revoke message to the floor participant. The Floor Revoke message:

a. shall include the Reject Cause field with the <Reject Cause> value set to #3 (No permission to send a Media Burst);

2. shall store that a Floor Release message is expected from the floor participant; and

3. shall remain in the ‘P: has no permission’ state.

6.5.5.3.10 Receive Floor Release message (R: Floor Release)

When the floor participant interface receives a Floor Release message from the floor participant, the floor participant interface:

1. if a Floor Release message is not expected from the floor participant:

a. if the first bit in the subtype of the Floor Release message is set to ‘1’ (acknowledgement is required) as specified in clause 8.2.2, based on local policy:

i shall send a Floor Ack message to the floor participant and set the first bit in the subtype of the Floor Release message to ‘0’ (acknowledgement is not required) in the outgoing Floor Release message; or

ii. wait for the Floor Ack from the floor control server; and

b. shall forward the Floor Release message to the floor control server interface;

2. if a Floor Release message is expected from the floor participant:

a. if the first bit in the subtype of the Floor Release message is set to ‘1’ (acknowledgement is required) as specified in clause 8.2.2:

i. shall send a Floor Ack message to the floor participant; and

b. shall remove that a Floor Release message is expected from the floor participant; and

3. shall remain in the ‘P: has no permission’ state.

6.5.5.3.11 Receive split instruction (R: Split)

Upon receiving an instruction to split the ongoing MCPTT call, to the floor participant interface:

1. shall create a new instance of the ‘basic floor control operation towards the floor participant’ state machine;

2. shall move information associated with the instance used for ‘floor participant interface state transition’ to the ‘basic floor control operation towards the floor participant’ state machine;

NOTE: Which information that needs to be moved is an implementation option.

3. shall enter the ‘Start-stop’ state and terminate the ‘floor participant interface state transition’ state machine associated with this floor participant and this session;

4. if the state in ‘general floor control operation’ state machine is ‘G: Floor Idle’ state; shall enter the ‘U: not permitted and Floor Idle’ state as specified in clause 6.3.5.3.2; and

5. if the state in ‘general floor control operation’ state machine is ‘G: Floor Taken’ state; shall enter the ‘U: not permitted and Floor Taken’ state as specified in clause 6.3.5.4.2.

6.5.5.3.12 Receive Floor Release Multi Talker message

When the floor participant interface receives a Floor Release Multi Talker message from the floor control server interface, the floor participant interface:

1. shall send the Floor Release Multi Talker message to the floor participant; and

2. shall remain in the ‘P: has no permission’ state.

6.5.5.4 State: ‘P: has permission’

6.5.5.4.1 General

The floor participant interface uses this state when the floor participant has permission to send media

6.5.5.4.2 Receive RTP media packets

When the floor participant interface receives an indication from the network media interface that RTP media packets are received from the MCPTT client, the floor participant interface:

1. shall instruct the media interface to forward received RTP media packets towards the media distributor; and

2. shall remain in the ‘P: has permission’ state.

6.5.5.4.3 Receive Floor Release message

When the floor participant interface receives a Floor Release message from the floor participant, the floor participant interface:

1. shall send the Floor Release message to the floor control server interface; and

3. shall remain in the ‘P: has permission’ state.

6.5.5.4.4 Receive Floor Ack message

When the floor participant interface receives a Floor Ack message from the floor control server interface, the floor participant interface:

1. shall send the Floor Ack message to the floor participant; and

2. shall remain in the ‘P: has permission’ state.

6.5.5.4.5 Receive Floor Idle message

When the floor participant interface receives a Floor Idle message from the floor control server interface, the floor participant interface:

1. shall send the Floor Idle message to the floor participant;

2. if the first bit in the subtype of the Floor Idle message is set to ‘1’ (acknowledgement is required), shall store an indication that a Floor Ack message to a Floor Idle messages is expected; and

3. shall enter the ‘P: has no permission’ state.

6.5.5.4.6 Receive Floor Taken message

When the floor participant interface receives a Floor Taken message from the floor control server interface, the floor participant interface:

1. shall send the Floor Taken message to the floor participant;

2. if the first bit in the subtype of the Floor Taken message is set to ‘1’ (acknowledgement is required), shall store an indication that a Floor Ack message to a Floor Taken messages is expected; and

3. if the Floor Indicator field is included and the I-bit is set to ‘1’ (multi-talker) shall remain in the ‘P: has permission’ state, otherwise shall enter the ‘P: has no permission’ state.

6.5.5.4.7 Receive Floor Revoke message

When the floor participant interface receives a Floor Revoke message from the floor control server interface, the floor participant interface:

1. shall send the Floor Revoke message to the floor participant;

2. if the first bit in the subtype of the Floor Revoke message is set to ‘1’ (acknowledgement is required), shall store an indication that a Floor Ack message to a Floor Revoke messages is expected; and

3. shall remain in the ‘P: has permission’ state.

6.5.5.4.8 Receive split instruction (R: Split)

Upon receiving an instruction to split the ongoing MCPTT call, the floor participant interface:

1. shall create a new instance of the ‘basic floor control operation towards the floor participant’ state machine as specified in clause 6.3.5;

NOTE: Which information that needs to be moved is an implementation option.

3. shall enter the ‘Start-stop’ state and terminate the ‘floor participant interface state transition’ state machine associated with this floor participant and this session; and

4. shall enter the ‘U: permitted’ state as specified in clause 6.3.5.5.2.

6.5.5.4.9 Receive Floor Release Multi Talker message

When the floor participant interface receives a Floor Release Multi Talker message from the floor control server interface, the floor participant interface:

1. shall send the Floor Release Multi Talker message to the floor participant; and

2. shall remain in the ‘P: has permission’ state.

6.5.5.5 In any state

6.5.5.5.1 General

This clause describes the actions to be taken in all states defined for the ‘floor participant interface state transition’ diagram with the exception of the ‘Start-stop’ and ‘Releasing’ states.

6.5.5.5.2 Receive Floor Ack message (R: Floor Ack)

If a Floor Ack message is received from the floor participant, the floor participant interface:

1. if an indication exists that a Floor Ack message is expected for the message in the Message Type field;

a. shall forward the Floor Ack message to the floor control server interface; and

b. shall remove the indication that a Floor Ack message is expected for the message in the Message Type field; and

NOTE: It is an implementation option what action to take if an indication exists that a Floor Ack message is expected for the message in the Message Type field, but the Floor Ack message is not received

2. shall remain in the current state.

If a Floor Ack message is received from the floor control server interface, the floor participant interface:

1. shall send the Floor Ack message to the floor participant; and

2. shall remain in the current state.

6.5.5.5.3 MCPTT session release step 1 (MCPTT call release – 1)

Upon receiving an MCPTT call release step 1 request from the application and signalling plane e.g. when the session is going to be released or when the MCPTT client leaves the session, the floor participant interface:

1. shall stop sending floor control messages to the floor participant;

2. shall request the network media interface to stop sending RTP media packets towards to the MCPTT client;

3. shall ignore any floor control messages received from the floor participant;

4. shall request the network media interface to stop forwarding RTP media packets from the MCPTT client to the media distributor;

5. shall indicate to the floor control server interface that the MCPTT client has started to disconnect from the session; and

6. shall enter the ‘P: Releasing’ state.

6.5.5.6 State: ‘P: Releasing’

6.5.5.6.1 General

The floor participant interface uses this state while waiting for the application and signalling plane to finalize the release of the session or finalizing the removal of the MCPTT client from the session.

6.5.5.6.2 MCPTT session release step 2 (MCPTT call release – 2)

Upon receiving an MCPTT call release step 2 request from the application and signalling plane, the floor participant interface:

1. shall request the network media interface to release all resources associated with this MCPTT client for this MCPTT call; and

2. shall enter the ‘Start-stop’ state and terminate the ‘floor participant interface state transition’ state machine associated with this floor participant and this session.