6.2 Floor participant procedures

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

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

6.2.1 Floor participant procedures at MCPTT session initialization

Based on the negotiations during the call establishment specified in 3GPP TS 24.379 [2], a new instance of the ‘Floor participant state transition diagram for basic operation’, as specified in clause 6.2.4, shall be created for this call.

The SIP INVITE request sent by the application and signalling plane:

1. shall be regarded an implicit floor request when an implicit floor request is negotiated; and

2. shall not be regarded as an implicit floor request in case of a rejoin to an already on-going group call.

NOTE: The floor participant can negotiate the use of prioritization of the Floor Request message. In that case, the floor participant can request permission to send media at a priority level that is either the same as or lower than the highest priority that was permitted to the participant in the MCPTT call initialization. If a floor participant is authorized for pre-emptive priority in the MCPTT call it is good practise to always request permission to send RTP media packets at a priority level that is lower than pre-emptive priority unless the user explicitly requests to pre-empt the current RTP media packets’ sender. In any case pre-emptive priority will have no effect for audio cut-in floor control.

6.2.2 Floor participant procedures at MCPTT call release

The MCPTT call release (whether it is initiated by the floor participant or floor control server) is a two-step procedure.

Step 1 The floor participant stops sending floor control messages and the MCPTT client stops sending RTP media packets.

Step 2 When the application and signalling plane has determined that the MCPTT call is released, the corresponding instance of the ‘Floor participant state transition diagram for basic operation’ as specified in clause 6.2.4 is terminated and the floor participant releases all the used resources.

The user plane can initiate the release step 1, but the application and signalling plane always initiates the release step 2.

6.2.3 Floor participant procedures at MCPTT call modification

Adding or removing media streams during an MCPTT call does not influence the floor control procedures.

6.2.4 Floor participant state transition diagram for basic operation

6.2.4.1 General

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

Figure 6.2.4.1-1 shows the state diagram for ‘Floor participant state transition diagram for basic operation’.

Figure 6.2.4.1-1: Floor participant state transition diagram for basic operation.

State details are explained in the following clauses.

If an RTP media packet or a floor control message arrives in a state where there is no specific procedure specified for the RTP media packets or the received floor control message, the floor participant shall discard the floor control message or the RTP media packet and shall remain in the current state.

NOTE 1: A badly formatted RTP packet or floor control message received in any state is ignored by the floor participant and does not cause any change of the current state.

NOTE 2: The state transition diagram is the same for groups configured for audio cut-in floor control but the U: queued state should never be visited.

6.2.4.2 State: ‘Start-stop’

6.2.4.2.1 General

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

6.2.4.2.2 MCPTT call initiated, originating MCPTT user

When a call is initiated as described in 3GPP TS 24.379 [2], the floor participant:

1. shall create an instance of the ‘Floor participant state transition diagram for basic operation’;

2. if the originating floor participant receives a floor control message before it receives the SIP 200 (OK) response, shall store the floor control message;

NOTE: The originating floor participant might receive a floor control message before the SIP 200 (OK) response when initiating, joining or rejoining a call because of processing delays of the SIP 200 (OK) response in the SIP core.

3. if the established MCPTT call is a chat group call and the SIP INVITE request is not an implicit floor request, shall enter the ‘U: has no permission’ state; and

4. if for the established MCPTT call the SIP INVITE request is an implicit floor request:

a. shall start timer T101 (Floor Request) and initialise counter C101 (Floor Request) to 1;

b. shall enter the ‘U: pending Request’ state; and

c. if the floor participant has received and stored a floor control message before the reception of the SIP 200 (OK) response, shall act as if the floor control message was received in the ‘U: pending Request’ state after entering the ‘U: pending Request’ state.

When the floor participant is rejoining an ongoing MCPTT call as described in 3GPP TS 24.379 [2] the floor participant shall enter the ‘U: has no permission’ state.

6.2.4.2.3 MCPTT call established, terminating MCPTT user

When an MCPTT call is established, the terminating floor participant:

1. shall create an instance of a ‘Floor participant state transition diagram for basic operation’; and

2. shall enter the ‘U: has no permission’ state.

NOTE: From a floor participant perspective the MCPTT call is established when the application and signalling plane sends the SIP 200 (OK) response.

6.2.4.3 State: ‘U: has no permission’

6.2.4.3.1 General

The floor participant is in this state when the floor participant is not sending RTP media packets or is not waiting for a floor control message response.

In this state RTP media packets may be received and floor control messages can be received.

6.2.4.3.2 Receive Floor Idle message (R: Floor Idle)

Upon receiving a Floor Idle message, the participant:

1. if the first bit in the subtype of the Floor Idle message is set to ‘1’ (Acknowledgment is required) as described in clause 8.2.2, shall send a Floor Ack message. The Floor Ack message:

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

b. shall include the Source field set to ‘0’ (the floor participant is the source);

2. may provide floor idle notification to the user, if it has not already done so;

3. shall stop the optional timer T103 (End of RTP media), if it is running; and

4. shall remain in the ‘U: has no permission’ state.

6.2.4.3.3 Receive Floor Taken message (R: Floor Taken)

Upon receiving the Floor Taken message, the floor participant:

1. if the first bit in the subtype of the Floor Taken message is set to ‘1’ (Acknowledgment is required) as described in clause 8.2.2, shall send a Floor Ack message. The Floor Ack message:

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

b. shall include the Source field set to ‘0’ (the floor participant is the source);

2. may provide a floor taken notification to the user;

3. if the Floor Indicator field is included and the type of call bit is set, may provide a notification to the user indicating the type of call;

4. if the Floor Indicator field is included and the I-bit is set to ‘1’ (multi-talker), shall provide a notification to the user indicating the type of call and may provide a list of current talkers;

5. should start the optional timer T103 (End of RTP media) for the participant for which Floor Taken message was received; and

6. shall remain in the ‘U: has no permission’ state.

6.2.4.3.4 Receive RTP media packets (R: RTP media)

Upon receiving RTP media packets, the floor participant:

1. shall request the MCPTT client to start rendering the received RTP media packets;

2. should restart/start the optional timer T103 (End of RTP media); and

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

NOTE: RTP media packets can be received from multiple sources when dual floor control is applied by the floor control server (see clause 6.3.6) or when multi-talker control is applied by the floor control server. The MCPTT client can differentiate between the different sources using the SSRC in the received RTP media packets. How the media mixer in the MCPTT client mixes the different RTP media stream sources is out of scope of the present document.

6.2.4.3.5 Send Floor Request message (PTT button pressed)

Upon receiving an indication from the user to request permission to send media, the floor participant:

1. shall send the Floor Request message toward the floor control server; The Floor Request message:

a. if a different priority than the normal priority is required, shall include the Floor Priority field with the priority not higher than negotiated with the floor control server as specified in clause 14.3.3;

b. if the floor request is a broadcast group call, system call, emergency call or an imminent peril call, shall include a Floor Indicator field indicating the relevant call types; and

c. shall include the location of the user:

i. if the current location of the talker is not available or is not to be reported according to the MCPTT user profile, then include a Location field with the location type is set to ‘0’ (Not provided); or

ii. if the current location of the talker is available and may be reported according to the MCPTT user profile, then:

A) if geographical coordinates are to be used and the altitude is not available, include a Location field including Geographic coordinates Location Type as specified in table 8.2.3.21-3;

B) if geographical coordinates are to be used and the altitude is available, include a List of Locations field including a Geographic coordinates Location Type and an Altitude Location Type; and

C) if geographical coordinates are not to be used, inlcude a Location field with any other Location location type and location value are set as specified in table 8.2.3.21-3;

2. shall start timer T101 (Floor Request) and initialise counter C101 (Floor Request) to 1; and

3. shall enter the ‘U: pending Request’ state.

6.2.4.3.6 Timer T103 (End of RTP media) expired

On expiry of timer T103 (End of RTP media), the floor participant:

1. may provide a floor idle notification to the user; and

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

6.2.4.3.7 Receive Floor Release Multi Talker message (R: Floor Release Multi Talker)

Upon receiving the Floor Release Multi Talker message, the floor participant:

1. shall provide a notification to the user indicating that a participant has released the floor in a multi-talker group; and

2. shall remain in the ‘U: has no permission’ stated.

6.2.4.3.8 Send Unicast Media Stop Request message (S: Unicast Media Flow Control)

Upon receiving an indication from the user to request to stop unicast media, the floor participant:

1. shall send the Unicast Media Flow Control message toward the floor control server; In the Unicast Media Flow Control message:

a. shall set Media Flow Control Indicator field value to ‘0’ as specified in clause 8.2.3.26; and

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

6.2.4.3.9 Send Unicast Media Resume Request message (S: Unicast Media Flow Control)

Upon receiving an indication from the user to request to resume unicast media, the floor participant:

1. shall send the Unicast Media Flow Control message toward the floor control server; In the Unicast Media Flow Control message:

a. shall set Media Flow Control Indicator field value to ‘1’ as specified in clause 8.2.3.26; and

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

6.2.4.4 State: ‘U: pending Request’

6.2.4.4.1 General

The floor participant is in this state when the floor participant is waiting for response to a Floor Request message.

In this state the floor participant can receive RTP media packets and floor control messages.

Timer T101 (Floor Request) is running in this state.

Timer T103 (End of RTP media) can be running in this state but there is no action in this state if the timer expires. The timer is started as a preparation for the state change that occurs once a response to the Floor Request message is received.

6.2.4.4.2 Receive Floor Granted message (R: Floor Granted)

Upon receiving a Floor Granted message from the floor control server or a floor granted indication in a SIP 200 (OK) response in the application and signalling layer, the floor participant:

1. if the first bit in the subtype of the Floor Granted message is set to ‘1’ (Acknowledgment is required) as described in clause 8.2.2, shall send a Floor Ack message. The Floor Ack message:

a. shall include the Message Type field set to ‘1’ (Floor Granted);

b. shall include the Source field set to ‘0’ (the floor participant is the source); and

c. if the call is a remotely initiated ambient listening call and if the user’s MCPTT profile allows sending the user’s location, shall include the location as specified in clause 6.2.4.3.5. If sending the user’s location is not allowed, the location field may be included with the location type field set to ‘0’ (Not provided);

2. if the call is not an ambient listening call, shall provide floor granted notification to the user, if not already done;

NOTE: Providing the floor granted notification to the user prior to receiving the Floor Granted message is an implementation option.

3. if the Floor Indicator field is included and the type of call bit is set, may provide a notification to the user indicating the type of call;

4. if the G-bit in the Floor Indicator is set to ‘1’ (Dual floor) shall store an indication that the participant is overriding without revoke;

5. shall stop the optional timer T103 (End of RTP media), if running;

6. shall stop timer T101 (Floor Request); and

7. shall enter the ‘U: has permission’ state.

6.2.4.4.3 Void

6.2.4.4.4 Receive Floor Deny message (R: Floor Deny)

Upon receiving a Floor Deny message, the floor participant:

1. if the first bit in the subtype of the Floor Deny message is set to ‘1’ (Acknowledgment is required) as described in clause 8.2.2, shall send a Floor Ack message. The Floor Ack message:

a. shall include the Message Type field set to ‘3’ (Floor Deny); and

b. shall include the Source field set to ‘0’ (the floor participant is the source);

2. shall provide floor deny notification to the user;

3. may display the floor deny reason to the user using information in the Reject Cause field;

4. shall stop timer T101 (Floor Request); and

5. shall enter the ‘U: has no permission’ state.

6.2.4.4.5 Timer T101 (Floor request) expired

On expiry of timer T101 (Floor Request) less than the upper limit of counter C101 (Floor Request) times the timer is allowed to expire, the floor participant:

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

b. if the floor request is a broadcast group call, system call, emergency call or an imminent peril call, shall include a Floor Indicator field indicating the relevant call types; and

c. shall include the location of the user as specified in clause 6.2.4.3.5;

2. shall restart timer T101 (Floor request) and increment counter C101 (Floor Request) by 1; and

3. shall remain in the ‘U: pending Request’ state.

6.2.4.4.6 Timer T101 (Floor Request) expired N times

When timer T101 (Floor Request) expires by the upper limit of counter C101 (Floor Request), the floor participant:

1. shall provide a floor request timeout notification to the user; and

2. shall enter the ‘U: has no permission’ state.

6.2.4.4.7 Receive RTP media packets (R: RTP Media)

Upon receiving RTP media packets, the floor participant:

1. shall request the MCPTT client to start rendering the received RTP media packets;

2. should start the optional timer T103 (End of RTP media) for the floor participant form which RTP packets were received; and

3. shall remain in the ‘U: pending Request’ state.

6.2.4.4.8 Send Floor Release message (PTT button released)

Upon receiving an indication from the user to release permission to send media, the floor participant:

1. shall send a Floor Release message towards the floor control server;

a. void;

2. may include the first bit in the subtype of the Floor Release message set to ‘1’ (Acknowledgment is required) as described in clause 8.2.2;

NOTE: It is an implementation option to handle the receipt of the Floor Ack message and what action to take if the Floor Ack message is not received.

3. shall start timer T100 (Floor Release) and initialise counter C100 (Floor Release) to 1;

4. shall stop timer T101 (Floor Request); and

5. shall enter the ‘U: pending Release’ state.

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

Upon receiving a Floor Queue Position Info message, the floor participant:

1. if the first bit in the subtype of the Floor Queue Position Info message is set to ‘1’ (Acknowledgment is required) as described in clause 8.2.2, shall send a Floor Ack message. The Floor Ack message:

a. shall include the Message Type field set to ‘9’ (Floor Queue Position Info); and

b. shall include the Source field set to ‘0’ (the floor participant is the source);

2. shall provide floor request queued response notification to the MCPTT user;

3. may provide the queue position and priority to the MCPTT user;

3A. shall stop timer T101 (Floor Request); and

4. shall enter the ‘U: queued’ state.

NOTE: For groups configured for audio cut-in floor control the floor participant will never receive Floor Queue Position Info.

6.2.4.4.10 Receive Floor Release Multi Talker message (R: Floor Release Multi talker)

Upon receiving the Floor Release Multi Talker message, the floor participant:

1. shall provide a notification to the user indicating that a participant has released the floor in a multi-talker group; and

2. shall remain in the ‘U: pending Request’ state.

6.2.4.4.11 Receive Floor Taken message (R: Floor Taken)

Upon receiving a Floor Taken message, the floor participant:

1. if the first bit in the subtype of the Floor Taken message is set to ‘1’ (Acknowledgment is required) as described in clause 8.2.2, shall send a Floor Ack message. The Floor Ack message:

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

b. shall include the Source field set to ‘0’ (the floor participant is the source);

2. may provide floor taken notification to the user;

3. if the Floor Indicator field is included and the type of call bit is set, may provide a notification to the user indicating the type of call;

5. should start the optional timer T103 (End of RTP media) for each new talker as received in Floor Taken message;

6. if the identity of the floor participant is not included in the List of Granted Users, shall stop timer T100 (Floor Release); and

7. if:

a. the floor participant has requested the floor with pre-emptive floor priority; and

b. the Floor Taken message is received as a result of the floor being taken by another floor participant;

then remain in the ‘U: pending request state’;

otherwise,

a. shall stop timer T101 (Floor Request); and

b. shall enter the ‘U: has no permission’ state.

NOTE: When the floor participant has requested the floor with/wthout pre-emptive floor priority, there is a possibility that this floor participant can also receive a Floor Granted creating a dual floor or Multi-talker scenario (multi-talker configuration limit reached or within the limit).

6.2.4.5 State: ‘U: has permission’

6.2.4.5.1 General

The floor participant is in this state when the MCPTT client is permitted to send RTP media. In this state the floor participant can receive floor control messages.

In this state, the floor participant can release permission to send RTP media at any time, even before sending any media.

The MCPTT client could have already buffered media when it enters this state.

NOTE: If the floor participant was queued, the floor participant requests a confirmation from the MCPTT user before start sending media. If confirmed, the media sending starts otherwise the permission to send media is released.

6.2.4.5.2 Send RTP media packets (RTP media)

Upon receiving indication from the MCPTT client that encoded voice is received from the user or if encoded voice is already buffered the floor participant:

1. shall request the MCPTT client to start forward encoded voice to the MCPTT server; and

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

6.2.4.5.3 Send Floor Release message (PTT button released)

Upon receiving an indication from the user to release the permission to send RTP media, the floor participant:

1. shall send a Floor Release message towards the floor control server. The Floor Release message:

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

NOTE: It is an implementation option to handle the receipt of the Floor Ack message and what action to take if the Floor Ack message is not received.

b. void; and

c. if the Floor Granted message included the G-bit set to ‘1’ (Dual floor), shall include the Floor Indicator with the G-bit set to ‘1’ (Dual floor);

2. shall remove the indication that the participant is overriding without revoke if this indication is stored;

3. shall remove the indication that the participant is overridden without revoke if this indication is stored;

4. shall start timer T100 (Floor Release) and initialize counter C100 (Floor Release) to 1; and

5. shall enter the ‘U: pending Release’ state.

6.2.4.5.4 Receive Floor Revoke message (R: Floor Revoke)

Upon receiving a Floor Revoke message, the floor participant:

1. shall inform the user that the permission to send RTP media is being revoked;

2. may give information to the user about the reason for revoking the permission to send media;

3. shall request the media mixer in the MCPTT client discard any remaining buffered RTP media packets and to stop forwarding encoded voice to the MCPTT server;

4 if the G-bit in the Floor Indicator is set to ‘1’ (Dual floor):

a. shall send a Floor Release message. In the Floor Release message:

i. shall include the Floor Indicator with the G-bit set to ‘1’ (Dual floor); and

ii. may set the first bit in the subtype to ‘1’ (Acknowledgment is required) as described in clause 8.2.2;

5 if the G-bit in the Floor Indicator is set to ‘0’ (not Dual floor):

a. shall send a Floor Release message. In the Floor Release message:

i. shall include the Floor Indicator with the G-bit set to ‘0’ (not Dual floor); and

ii. may set the first bit in the subtype to ‘1’ (Acknowledgment is required) as described in clause 8.2.2;

NOTE: It is an implementation option to handle the receipt of the Floor Ack message and what action to take if the Floor Ack message is not received.

6. shall start timer T100 (Floor Release) and initialize counter C100 (Floor Release) to 1; and

7. shall enter the ‘U: pending Release’ state.

6.2.4.5.5 Receive Floor Granted message (R: Floor Granted)

Upon receiving a Floor Granted message from the floor control server, the floor participant:

1. if the first bit in the subtype of the Floor Granted message is set to ‘1’ (Acknowledgment is required) as described in clause 8.2.2, shall send a Floor Ack message. The Floor Ack message:

a. shall include the Message Type field set to ‘1’ (Floor Granted); and

b. shall include the Source field set to ‘0’ (the floor participant is the source); and

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

6.2.4.5.6 Receive RTP media packets (R: RTP Media)

Upon receiving RTP media packets the floor participant:

1. shall request the MCPTT client, based on configuration, either to continue rendering or stop the rendering and start storing the received RTP media packets if an indication is stored that the participant is overriding without revoke;

NOTE: The configuration whether to continue rendering or to start storing the incoming RTP media is out of the scope of the present document.

2. shall request the MCPTT client to render the received RTP media packets if an indication is stored that the participant is overridden without revoke; and

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

6.2.4.5.7 Receive Floor Idle message (R: Floor Idle)

Upon receiving a Floor Idle message from the floor control server, the floor participant:

1. if an indication that the participant is overriding without revoke is stored:

a. if the first bit in the subtype of the Floor Idle message is set to ‘1’ (Acknowledgment is required) as described in clause 8.2.2, shall send a Floor Ack message. The Floor Ack message:

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

ii. shall include the Source field set to ‘0’ (the floor participant is the source);

b. shall remove the indication that the participant is overriding without revoke; and

c. shall remain in the ‘U: has permission’ state; and

2. if the G-bit in the Floor Indicator is set to ‘1’ (Dual Floor) and an indication that the participant is overridden without revoke is stored:

a. if the first bit in the subtype of the Floor Idle message is set to ‘1’ (Acknowledgment is required) as described in clause 8.2.2, shall send a Floor Ack message. The Floor Ack message:

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

ii. shall include the Source field set to ‘0’ (the floor participant is the source);

b. shall remove the indication that the participant is overridden without revoke; and

c. shall remain in the ‘U: has permission’ state.

6.2.4.5.8 Receive Floor Taken message (R: Floor Taken)

Upon receiving a Floor Taken message:

1. if the G-bit in the Floor Indicator set to ‘1’ (Dual Floor) the floor participant:

a. shall inform the user that the call is overridden without revoke;

b. shall store an indication that the participant is overridden without revoke; and

c. shall remain in the ‘U: has permission’ state; and

2. if the I-bit in the Floor Indicator set to ‘1’ (Multi-talker) the floor participant:

a. may provide a floor taken notification to the user;

b. should start the optional timer T103 (End of RTP media) for the participant for which Floor Taken message was received;

c. shall provide a notification to the user indicating the type of call and may provide a list of current talkers; and

d. shall remain in the ‘U: has permission’ state.

6.2.4.5.9 Receive Floor Release Multi Talker message (R: Floor Release Multi talker)

Upon receiving the Floor Release Multi Talker message, the floor participant:

1. shall provide a notification to the user indicating that the participant has released the floor in a multi-talker group; and

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

6.2.4.6 State: ‘U: pending Release’

6.2.4.6.1 General

The floor participant is in this state when the floor participant is waiting for response to a Floor Release message.

In this state the floor participant can receive floor control messages and RTP media packets.

Timer T100 (Floor Release) is running in this state.

6.2.4.6.2 Timer T100 (Floor Release) expired

On expiry of timer T100 (Floor Release) less than the configurable number of the upper limit of counter C100 (Floor Release) times, the floor participant:

1. shall send a Floor Release message towards the floor control server;

2. may set the first bit in the subtype of the Floor Release message to ‘1’ (Acknowledgment is required) as described in clause 8.2.2;

NOTE: It is an implementation option to handle the receipt of the Floor Ack message and what action to take if the Floor Ack message is not received.

3. shall restart timer T100 (Floor Release) and increment counter C100 (Floor Release) by 1; and

4. shall remain in state ‘U: pending Release’.

6.2.4.6.3 Timer T100 (Floor release) expired N times

When timer T100 (Floor Release) expires by the upper limit of counter C100 (Floor Release) times, the floor participant:

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

6.2.4.6.4 Receive Floor Idle message (R: Floor Idle)

Upon receiving a Floor Idle message, the floor participant:

1. if the first bit in the subtype of the Floor Idle message to ‘1’ (Acknowledgment is required) as described in clause 8.2.2, shall send a Floor Ack message. The Floor Ack message:

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

b. shall include the Source field set to ‘0’ (the floor participant is the source);

2. may provide a floor idle notification to the MCPTT user;

3. if the Floor Indicator field is included and the type of call bit is set, may provide a notification to the user indicating the type of call;

4. shall stop timer T100 (Floor Release);

5. if the session is not a broadcast group call or if the A-bit in the Floor Indicator field is set to ‘1’ (Normal call), shall enter the ‘U: has no permission’ state; and

6. if the session was initiated as a broadcast group call:

a. shall indicate to the MCPTT client the media transmission is completed; and

b shall enter the ‘Releasing’ state.

6.2.4.6.5 Receive Floor Taken message (R: Floor Taken)

Upon receiving a Floor Taken message, the floor participant:

1. if the first bit in the subtype of the Floor Taken message is set to ‘1’ (Acknowledgment is required) as described in clause 8.2.2, shall send a Floor Ack message. The Floor Ack message:

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

b. shall include the Source field set to ‘0’ (the floor participant is the source);

2. may provide floor taken notification to the user;

3. if the Floor Indicator field is included and the type of call bit is set, may provide a notification to the user indicating the type of call;

5. should start the optional timer T103 (End of RTP media) for each new talker as received in Floor Taken message;

6. if the identity of the floor participant is not included in the List of Granted Users, shall stop timer T100 (Floor Release); and

7. shall enter the ‘U: has no permission’ state.

6.2.4.6.6 Receive RTP media packets (R: RTP Media)

Upon receiving an indication from the MCPTT client that RTP media packets are received, the floor participant:

1. shall request the MCPTT client to start rendering the RTP media packets;

2. should start the optional timer T103 (End of RTP media) for the participant from which the RTP packets were received;

3. void; and

4. shall remain in the ‘U: pending Release’ state.

6.2.4.6.7 Receive Floor Revoke message (R: Floor Revoke)

Upon receiving a Floor Revoke message, the floor participant:

1. may give information to the user that permission to send RTP media is being revoked;

2. may inform the user of the reason contained in the Floor Revoke message; and

3. shall remain in the ‘U: pending Release’ state.

6.2.4.6.8 Receive Floor Granted message (R: Floor Granted)

Upon receiving a Floor Granted message, the floor participant:

1. if the first bit in the subtype of the Floor Granted message is set to ‘1’ (Acknowledgment is required) as described in clause 8.2.2, shall send a Floor Ack message. The Floor Ack message:

a. shall include the Message Type field set to ‘1’ (Floor Granted); and

b. shall include the Source field set to ‘0’ (the floor participant is the source); and

2. shall remain in the ‘U: pending Release’ state.

6.2.4.6.9 Receive Floor Release Multi Talker message (R: Floor Release Multi talker)

Upon receiving the Floor Release Multi Talker message, the floor participant:

1. shall provide a notification to the user indicating that the participant has released the floor in a multi-talker group; and

2. if the message is due to the participant having released the floor shall enter ‘U: has no permission’, otherwise shall remain in the ‘U: pending Release’ state.

6.2.4.7 In any state

6.2.4.7.1 General

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

6.2.4.7.2 Receive MCPTT call release – step 1 (R: MCPTT call release – 1)

Upon receiving an MCPTT call release step 1 request from the application and signalling plane when the MCPTT call is going to be released or when the floor participant is leaving the MCPTT call, the floor participant:

1. shall stop sending floor control messages and stop all running timers;

2. shall request the MCPTT client to stop sending RTP media packets; and

3. shall enter the ‘Releasing’ state.

6.2.4.7.3 void

6.2.4.7.4 Send Queued Floor Requests message (S: Send Queued Floor Requests)

Upon receipt of a request from an MCPTT user to cancel the floor requests of other MCPTT users whose floor requests queued or a request from an MCPTT user to clear all the users floor requests queued by the floor control server for supporting queuing, if the group is not configured for audio cut-in floor control, the floor participant:

1. shall send the Queued Floor Requests message as described in clause 8.2.15 including a Queued Floor Requests Purpose field with the Queued Floor Requests Purpose value set to ‘0’ (Cancel Request) if:

a. the user provided a list of MCPTT users, then include the list of MCPTT users in the List of Queued Users field; or

b. the user did not provide a list of MCPTT users, then the List of Queued Users field is not included; (This is coding indicates that the user is requesting that all floor requests queued by the floor control server for supporting queuing);

2. shall start timer T134 (Queued Floor Requests); and

3. shall remain in the current state.NOTE: It is an implementation option to handle the receipt of the Floor Ack message and what action to take if the Floor Ack message is not received.

NOTE: It is an implementation option to handle the receipt of the Floor Ack message and what action to take if the Floor Ack message is not received.

If the group is configured for audio cut-in floor control, the floor participant shall indicate to the MCPTT user that request to cancel the queued floor requests not allowed on the group configured for audio cut-in floor control.

6.2.4.7.5 Timer T134 (Queued Floor Requests) expired

On expiry of timer T134 (Queued Floor Requests), the floor participant:

1. shall provide a Queued Floor Requests timeout to the MCPTT client, and

2. shall remain in the current state.

NOTE: It is an implementation option to handle the timer expiry event and what action to take.

6.2.4.7.6 Receive Queued Floor Requests message (R: Queued Floor Requests)

Upon receiving a Queued Floor Requests message, including a Queued Floor Requests Purpose field with the Queued Floor Requests Purpose value set to ‘1’ (Cancel Result), the floor participant:

1. if the first bit in the subtype of the Queued Floor Requests message is set to ‘1’ (Acknowledgment is required) as described in clause 8.2.2, shall send a Floor Ack message. The Floor Ack message:

a. shall include the Message Type field set to ’14’ (Queued Floor Requests); and

b. shall include the Source field set to ‘0’ (the floor participant is the source);

2. may provide the result of a message for cancellation of a queued floor request to the MCPTT user;

3. shall stop the timer T134 (Queued Floor Requests), if running; and

4. shall remain in the current state.

6.2.4.8 State: ‘Releasing’

6.2.4.8.1 General

The floor participant is in this state while waiting for the application and signalling plane to finalize the disconnection of an MCPTT call.

6.2.4.8.2 Receive MCPTT call release – step 2 (R: MCPTT call release – 2)

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

1. shall release all resources including any running timers associated with the MCPTT call; and

2. shall enter the ‘Start-stop’ state and terminate the current instance of the ‘Floor control state machine – basic’.

6.2.4.9 State: ‘U: queued’

6.2.4.9.1 General

The floor participant uses this state when a Floor Request message has been queued by the floor control server, and is awaiting the Floor Granted message.

In this state, the MCPTT client can receive RTP Media packets and the floor participant can send and receive floor control messages.

The timer T104 (Floor Queue Position Request) can be running in this state.

6.2.4.9.2 Receive RTP media packets (R: RTP media)

Upon receiving an indication from the media mixer in the MCPTT client that the media mixer is receiving RTP media packets, the floor participant:

1. shall request to the media mixer to start rendering received RTP media packets;

2. should restart timer T103 (End of RTP media) from which RTP packets were received; and

3. shall remain in the ‘U: queued’ state.

6.2.4.9.3 Receive Floor Taken message (R: Floor Taken)

Upon receiving a Floor Taken message, the floor participant:

1. may provide a floor taken notification to the MCPTT user;

2. if the first bit in the subtype of the Floor Taken message is set to ‘1’ (Acknowledgment is required) as described in clause 8.2.2, shall send a Floor Ack message. The Floor Ack message:

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

b. shall include the Source field set to ‘0’ (the floor participant is the source);

3. if the Floor Indicator field is included and the I-bit is set to ‘1’ (multi-talker), shall provide a notification to the user indicating the type of call and may provide a list of current talkers;

4. should start the optional timer T103 (End of RTP media); and

5. shall remain in the ‘U: queued’ state.

6.2.4.9.4 Receive Floor Granted message (R: Floor Granted)

Upon receiving a Floor Granted message, the floor participant:

1. if the first bit in the subtype of the Floor Granted message is set to ‘1’ (Acknowledgment is required) as described in clause 8.2.2, shall send a Floor Ack message. The Floor Ack message:

a. shall include the Message Type field set to ‘1’ (Floor Granted); and

b. shall include the Source field set to ‘0’ (the floor participant is the source);

2. shall provide a floor granted notification to the MCPTT user;

3. if the Floor Indicator field is included and the type of call bit is set, may provide a notification to the user indicating the type of call;

4. shall stop timer T104 (Floor Queue Position Request), if running;

5. shall start timer T132 (Queued granted user action);

6. shall stop the optional timer T103 (End of RTP media), if running, and if associated to a participant for whichthe previously received Floor Taken did not include a Floor Indicator field with the G-bit set to ‘1’ (Dual floor);

7. shall indicate the user that the floor is granted; and

8. shall remain in the ‘U: queued’ state.

6.2.4.9.5 Receive Floor Deny message (R: Floor Deny)

Upon receiving a Floor Deny message, the floor participant:

1. if the first bit in the subtype of the Floor Deny message is set to ‘1’ (Acknowledgment is required) as described in clause 8.2.2, shall send a Floor Ack message. The Floor Ack message:

a. shall include the Message Type field set to ‘3’ (Floor Deny); and

b. shall include the Source field set to ‘0’ (the floor participant is the source);

2. shall provide floor deny notification to the MCPTT user;

3. may display the deny reason to the user using information in the Reject Cause field;

4. shall stop timer T104 (Floor Queue Position Request), if running; and

5. shall enter the ‘U: has no permission’ state.

6.2.4.9.6 Send Floor Release message (PTT button released)

Upon receiving an indication from the MCPTT user to release the queued floor request, the floor participant:

1. shall send a Floor Release message: The Floor Release message:

a. void;

2. may set the first bit in the subtype of the Floor Release message to ‘1’ (Acknowledgment is required) as described in clause 8.2.2;

NOTE: It is an implementation option to handle the receipt of the Floor Ack message and what action to take if the Floor Ack message is not received.

3. shall start timer T100 (Floor Release) and initialise counter C100 (Floor Release) to 1;

4. shall stop timer T104 (Floor Queue Position Request), if running;

5. shall stop timer T132 (queued request granted user action); and

6. shall enter the ‘U: pending Release’ state.

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

Upon receiving a Floor Queue Position Info message, the floor participant:

a. shall include the Message Type field set to ‘9’ (Floor Queue Position Info); and

b. shall include the Source field set to ‘0’ (the floor participant is the source);

2. if the message indicates that the request has been queued or if a request for the queue position was sent, the floor participant:

a. may provide the queue position and priority (if available) to the MCPTT user;

3. shall stop the timer T104 (Floor Queue Position Request), if running; and

4. shall remain in the ‘U: queued’ state.

6.2.4.9.8 Receive Floor Idle message (R: Floor Idle)

Upon receiving a Floor Idle message, the floor participant:

1. if the first bit in the subtype of the Floor Idle message is set to ‘1’ (Acknowledgment is required) as described in clause 8.2.2, shall send a Floor Ack message. The Floor Ack message:

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

b. shall include the Source field set to ‘0’ (the floor participant is the source);

2. may provide a floor idle notification to the MCPTT user;

3. shall stop timer T104 (Floor Queue Position Request), if running; and

4. shall enter the ‘U: has no permission’ state.

6.2.4.9.9 Send Floor Queue Position Request message (S: Floor Queue Position Request)

Upon receipt of an indication from the MCPTT client to request the queue position and timer T132 is not running (i.e. a Floor Granted message has not been received), the floor participant:

1. shall send the Floor Queue Position Request message;

2. shall start timer T104 (Floor Queue Position Request) and initialize counter C104 (Floor Queue Position Request) to 1; and

3. shall remain in the ‘U: queued’ state.

6.2.4.9.10 Timer T104 (Floor Queue Position Request) expired

On expiry of timer T104 (Floor Queue Position Request) less than the upper limit of C104 (Floor Queue Position Request) times, the floor participant:

1. shall send a Floor Queue Position Request message towards the floor control server;

2. shall restart timer T104 (Floor Queue Position Request) and increment counter C104 (Floor Queue Position Request) by 1; and

3. shall remain in the ‘U: queued’ state.

6.2.4.9.11 Timer T104 (Floor Queue Position Request) expired N times

When timer T104 (Floor Queue Position Request) expires by the upper limit of counter C104 (Floor Queue Position Request) times, the floor participant:

1. shall provide a floor queued timeout to the MCPTT client;

2. may set the first bit in the subtype of the Floor Release message to ‘1’ (Acknowledgment is required) as described in clause 8.2.2;

3. shall send the Floor Release message;

NOTE: It is an implementation option to handle the receipt of the Floor Ack message and what action to take if the Floor Ack message is not received.

3a. shall start timer T100 (Floor Release) and initialise counter C100 (Floor Release) to 1; and

4. shall enter the ‘U: pending Release’ state.

6.2.4.9.12 User indication for accept of pending request

Upon receiving an indication from the user that the user wants to send media and the timer T132 (Queued granted user action) is running, the floor participant:

1. shall stop timer T132 (queued request granted user action); and

2. shall enter ‘U: has permission’ state.

6.2.4.9.13 Timer T132 (Queued granted user action) expires

Upon expiry of timer T132 (Queued granted user action) the floor participant:

1. shall send Floor Release message;

2. may indicate the user that the floor is no more available;

3. may set the first bit in the subtype of the Floor Release message to ‘1’ (Acknowledgment is required) as described in clause 8.2.2; and

NOTE: It is an implementation option to handle the receipt of the Floor Ack message and what action to take if the Floor Ack message is not received.

4. shall enter ‘U: has no permission’ state.

6.2.4.9.14 Receive Floor Release Multi Talker message (R: Floor Release Multi talker)

Upon receiving the Floor Release Multi Talker message, the floor participant:

1. shall provide a notification to the user indicating that a participant has released the floor in a multi-talker group; and

2. shall remain in the ‘U: queued’ state.

6.2.4.9.15 Receive Queued Floor Requests message (R: Queued Floor Requests)

Upon receiving a Queued Floor Requests message including a Queued Floor Requests Purpose field with the Queued Floor Requests Purpose value set to ‘2’ (Cancel Notification), the floor participant:

a. shall include the Message Type field set to ’14’ (Queued Floor Requests); and

b. shall include the Source field set to ‘0’ (the floor participant is the source);

2. shall provide a queued floor requests cancellation notification to the MCPTT user;

3. may display the requesting user for a cancellation of a queued floor request to the user using information in the Requested Party’s Identity field;

4. shall stop timer T104 (Floor Queue Position Request), if running; and

5. shall enter the ‘U: has no permission’ state.