6.3.5 Floor control server state transition diagram for basic floor control operation towards the floor participant

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

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

6.3.5.1 General

The floor control interface towards the MCPTT client in the floor control server shall behave according to the state diagram and state transitions specified in this clause.

Figure 6.3.5.1-1 shows the states and state transitions for an associated floor participant in the floor control server.

Figure 6.3.5.1-1: Floor control server state transition diagram for basic floor control operation towards the floor participant

The floor control interface towards the MCPTT client in the floor control server shall create one instance of the ‘basic floor control operations’ state machine towards the MCPTT client for every floor participant served by the floor control server as follows:

1. For pre-arranged group call in case of an originating MCPTT call, the ‘basic floor control operation towards the floor participant’ state machine shall be created when the MCPTT server sends the SIP 200 (OK) response towards the originating MCPTT client.

2. For pre-arranged group call in case of a terminating MCPTT call, the ‘basic floor control operation towards the floor participant’ state machine shall be created when the floor control server receives the SIP 200 (OK) response.

3. For chat group call the ‘basic floor control operation state machine towards the floor participant’ shall be created when the MCPTT server sends the SIP 200 (OK) response to the received initial SIP INVITE request.

The floor participant associated to the ‘basic floor control operation towards the floor participant’ state machine is here referred to as the "associated floor participant".

The external inputs to the state machine are:

1. directives coming from the floor control arbitration logic;

2. floor control messages sent by the floor participants;

3. media; and

4. in certain cases, SIP messages used for call handling.

If floor control messages or RTP media packets arrives in a state where there is no procedure specified in the following clauses, the floor control interface towards the MCPTT client in the floor control server:

1. shall discard the floor control message;

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

3. shall remain in the current state.

State details are explained in the following clauses.

6.3.5.2 State: ‘Start-stop’

6.3.5.2.1 General

When a new instance of the ‘basic floor control operations towards the floor participant’ state machine is created, before any floor control related input is applied, the state machine is in the ‘Start-stop’ state. Similarly, when the call is released the state machine shall return to the Start-Stop state.

An association between the floor control server and a floor participant in the MCPTT client is created, when the state machine is created; and

1. in case of an originating MCPTT call, when the MCPTT server sends the SIP 200 (OK) response to the originating MCPTT client; and

2. in case of a terminating MCPTT call, when the floor control server receives the SIP 200 (OK) response sent from the terminating MCPTT client.

6.3.5.2.2 SIP Session initiated

When a SIP Session is established and if:

1. the session is not a temporary group call session;

2. the session is a temporary group call session and the associated floor participant is an invited MCPTT client (i.e. not a constituent MCPTT group); or

3. the session is not an ambient listening call;

then:

NOTE 1: A MCPTT group call is a temporary group session when the <on-network-temporary> element is present in the <list-service> element as specified in 3GPP TS 24.481 [12].

1. if an MCPTT client initiates an MCPTT call with an implicit floor request, and the MCPTT call does not exist yet, the floor control interface towards the MCPTT client in the floor control server:

a. shall initialize a general state machine as specified in clause 6.3.4.2.2; and

NOTE 2: In the clause 6.3.4.2.2 the ‘general floor control operation’ state machine will continue with the initialization of the ‘general floor control operation’ state machine.

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

2. if the associated MCPTT client rejoins an ongoing MCPTT call without an implicit floor request or initiates or joins a chat group call without an implicit floor request or attempts to initiate an already existing MCPTT call without an implicit floor request, and

a. if an MCPTT call already exists but no MCPTT client has the permission to send a media, the floor control interface towards the MCPTT client in the floor control server:

i. should send a Floor Idle message to the MCPTT client. The Floor Idle message:

A. shall include a Message Sequence Number field with a Message Sequence Number value increased with 1; and

B. if a group call is a broadcast group call, a system call, an emergency call, an imminent peril call, or a temporary group session, shall include the Floor Indicator field with appropriate indications; and

ii. shall enter the state ‘U: not permitted and Floor Idle’ as specified in the clause 6.3.5.5.2;

b. if an MCPTT call is initiated, the floor control interface towards the MCPTT client in the floor control server:

i. shall enter the state ‘U: not permitted and Floor Idle’ as specified in the clause 6.3.5.5.2; and

ii. shall initialize a general state machine as specified in clause 6.3.4.2.2; and

NOTE 3: In the clause 6.3.4.2.2 the general state machine will continue with the initialization of the general state machine.

c. if another MCPTT client has the permission to send a media, the floor control interface towards the MCPTT client in the floor control server:

i. should send a Floor Taken message to the MCPTT client. The Floor Taken message:

A. 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;

B. shall include a Message Sequence Number field with a <Message Sequence Number> value increased with 1;

C. if the session is a broadcast group call, shall include the Permission to Request the floor field set to ‘0’;

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

E. if a group call is a broadcast group call, a system call, an emergency call, an imminent peril call, or a temporary group session, shall include the Floor Indicator field with appropriate indications

ii. shall enter the ‘U: not permitted and Floor Taken’ state as specified in the clause 6.3.5.4.2;

3. if the associated floor participant attempts to initiate an already existing MCPTT call with an implicit floor request, and

a. if no MCPTT client has the permission to send media, the floor control interface towards the MCPTT client in the floor control server:

i. shall process the implicit floor request as if a Floor Request message was receive as specified in clause 6.3.4.3.3; and

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

b. if the MCPTT client negotiated support of queueing floor requests as specified in clause 14 and if another MCPTT client has the permission to send media, the floor control interface towards the MCPTT client in the floor control server:

i. shall set the priority level to the negotiated maximum priority level that the MCPTT client is permitted to request, except for pre-emptive priority, when high priority is used;

NOTE 4: The maximum floor priority the floor participant is permitted to request is negotiated in the "mc_priority" fmtp attribute as specified in clause 14.

NOTE 5: The initial implicit floor request will not result in pre-emption when an MCPTT client is joining an ongoing MCPTT call. If the MCPTT client wants to pre-empt the current MCPTT client that is sending media, an explicit floor request with pre-emptive floor priority is required.

ii. shall insert the MCPTT client into the active floor request queue to the position immediately following all queued floor requests with the same floor priority;

iii. shall send a Floor Queue Position Info message to the MCPTT client. The Floor Queue Position Info message:

A shall include the queue position and floor priority in the Queue Info field; and

iv. should send a Floor Queue Position Info message with the updated status to the MCPTT clients in the active floor request queue which negotiated queueing of floor requests as specified in clause 14, which have requested the queue status, whose queue position has been changed since the previous Floor Queue Position Info message and which is not the joining MCPTT client. The Floor Queue Position Info message:

A shall include the queue position and floor priority in the Queue Info field; and

v. shall enter the ‘U: not permitted and Floor Taken’ state as specified in the clause 6.3.5.4.2; and

c. if the MCPTT client did not negotiate queueing of floor requests and if another MCPTT client has the permission to send a media, the floor control interface towards the MCPTT client in the floor control server:

i. shall send a Floor Taken message to the MCPTT client. The Floor Taken message:

B. shall include a Message Sequence Number field with a Message Sequence Number value increased with 1;

C. if the session is a broadcast group call, shall include the Permission to Request the floor field set to ‘0’;

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

ii. shall enter the ‘U: not permitted and Floor Taken’ state as specified in the clause 6.3.5.4.2; and

4. if the MCPTT client is invited to the MCPTT call and

a. if another MCPTT client has permission to send a media, the floor control interface towards the MCPTT client in the floor control server:

i. should send a Floor Taken message to the MCPTT client. The Floor Taken message:

B. shall include a Message Sequence Number field with a Message Sequence Number value increased with 1;

C. if the session is a broadcast group call, shall include the Permission to Request the floor field set to ‘0’;

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

ii. shall enter the ‘U: not permitted and Floor Taken’ state as specified in the clause 6.3.5.4.2; and

b. if no other MCPTT client has the permission to send a media; the floor control interface towards the MCPTT client in the floor control server:

i. should send a Floor Idle message to the MCPTT client. The Floor Idle message:

A. shall include a Message Sequence Number field with a <Message Sequence Number> value increased with 1; and

ii. shall enter the ‘U: not permitted and Floor Idle’ state as specified in the clause 6.3.5.3.2.

When a SIP Session is established and if the session is a temporary group call session and,

1. if the associated floor participant is a constituent MCPTT group; or

2. if the associated floor participant is the initiator of the temporary group session;

then the floor control interface towards the MCPTT client:

1. shall initialize a general state machine as specified in clause 6.3.4.2.2, if not already initiated; and

2. shall enter the ‘U: not permitted and initiating’ state as specified in clause 6.3.5.10.2.

When a SIP Session is established and if the session is an ambient listening call session then the floor control interface towards the MCPTT client:

1. if the floor is granted to the associated floor participant

a. shall forward the "Floor Granted" message to the associated floor participant; and

b. shall enter the state ‘U: permitted’ as specified in the clause 6.3.5.5.2; and

2. if the floor is not granted to the associated floor participant

a. shall forward the "Floor Taken" message to the associated floor participant; and

b. shall enter the state ‘U: not permitted Floor Taken’ as specified in the clause 6.3.5.4.2.

6.3.5.3 State: ‘U: not permitted and Floor Idle’

6.3.5.3.1 General

The floor control interface towards the MCPTT client in the floor control server uses this state when the associated floor participant is not permitted to send media.

6.3.5.3.2 Enter state ‘U: not permitted and Floor Idle’

When entering this state the floor control interface towards the MCPTT client in the floor control server:

1. if a Track Info field is stored, shall remove the Track Info field from the storage; and

2. shall set the state for the associated floor participant to ‘U: not permitted and Floor Idle’.

6.3.5.3.3 Send Floor Taken message (S: Floor Taken)

When a Floor Taken message is received from the floor control server arbitration logic, the floor control interface towards the MCPTT client in the floor control server:

1. shall forward the Floor Taken message to the associated floor participant;

2. may set the first bit in the subtype of the Floor Taken 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.

3. shall enter the ‘U: not permitted and Floor Taken’ state as specified in the clause 6.3.5.4.2.

6.3.5.3.4 Receive Floor Request message (R: Floor Request)

Upon receiving a Floor Request message from the associated floor participant, the floor control interface towards the MCPTT client in the floor control server:

1. if the session is not a broadcast group call or if the session is a broadcast group call and the associated floor participant is the initiator of the broadcast group call, shall forward the Floor Request message to the floor control server arbitration logic;

NOTE 1 Initiating a broadcast group call is done in the application and signalling plane using SIP. Initiating or upgrading a call to an emergency call or an imminent peril call is done in the application and signalling plane using SIP.

2. if the session is a broadcast group call and the associated floor participant is not the initiator of the broadcast group call, shall send a Floor Deny message to the associated floor participant. The Floor Deny message:

a. shall include in the Reject Cause field the <Reject Cause> value cause #5 (Receive only);

b. may include in the Reject Cause field an additional text string explaining the reason for rejecting the floor request in the <Reject Phrase> value;

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

NOTE 2: 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.

d. if a group call is a broadcast group call, a system call, an emergency call, an imminent peril call, or a temporary group session, shall include the Floor Indicator field with appropriate indications; and

e. if the Floor Request message included a Track Info field, shall include the received Track Info field; and

3. shall remain in the ‘U: not permitted and Floor Idle’ state.

6.3.5.3.5 Send Floor Granted message (S: Floor Granted)

When a Floor Granted message is received from the floor control arbitration logic in the MCPTT server, the floor control interface towards the MCPTT client in the floor control server:

1. shall forward the Floor Granted messages to the associated floor participant;

2. may set the first bit in the subtype of the Floor Granted 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.

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

6.3.5.3.6 Send Floor Deny message (S: Floor Deny)

When a Floor Deny message is received from the floor control arbitration logic in the MCPTT server, the floor control interface towards the MCPTT client in the floor control server:

1. shall forward the Floor Deny messages to the associated floor participant;

2. may set the first bit in the subtype of the Floor Deny 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.

3. shall remain in the ‘U: not permitted and Floor Idle’ state.

6.3.5.3.7 Receive Floor Release message (R: Floor Release)

Upon receiving a Floor Release message from the associated floor participant, the floor control interface towards the MCPTT client in the floor control server:

1. if the first bit in the subtype of the Floor Release 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 ‘4’ (Floor Release);

b. shall include the Source field set to ‘2’ (the controlling MCPTT function is the source); and

c. if the Floor Release message included a Track Info field, shall include the received Track Info field;

2. shall send a Floor Idle message to the associated floor participant. The Floor Idle message:

a. shall include a Message Sequence Number field with a <Message Sequence Number> value increased with 1;

b. may set the first bit in the subtype of the Floor Idle 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.

c. if a group call is a broadcast group call, a system call, an emergency call, an imminent peril call, or a temporary group session, shall include the Floor Indicator field with appropriate indications;

3. if a Track Info field is included in the Floor Release message, shall use the topmost <Participant Reference> value and the SSRC in the received Floor Release message to check if the floor participant has a queued floor request;

4. if a no Track Info field is included in the Floor Release message, shall use the SSRC in the received Floor Release message to check if the floor participant has a queued floor request;

5 if the floor participant has a floor request in the queue, shall remove the queued floor request from the queue; and

6. shall remain in the state ‘U: not permitted and Floor Idle’ state.

6.3.5.3.8 Receive RTP media packets (R: media)

Upon receiving an indication from the network media interface that RTP media packets are received with payload from the associated floor participant and if Floor Release message was received in the previous ‘U: permitted’ state, the floor control interface towards the MCPTT client in the floor control server:

NOTE: Reception of unauthorized RTP media packets can only happen if the associated floor participant is in an MCPTT client. If the associated floor participant is a floor control server interface in a non-controlling MCPTT function of an MCPTT group, the unauthorized RTP media packets are handled in the non-controlling MCPTT function.

1. shall request the network media interface in the MCPTT server to not forward the received RTP media packets to the media distributor in the MCPTT server;

2. shall send a Floor Revoke message to the associated 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); and

b. if a group call is a broadcast group call, a system call, an emergency call, an imminent peril call, or a temporary group session, shall include the Floor Indicator field with appropriate indications; and

3. shall enter the ‘U: not permitted but sends media’ state as specified in the clause 6.3.5.7.2.

6.3.5.3.9 Receive an implicit floor request (R: Implicit floor request)

When an ongoing session is upgraded to an emergency group call and when the application and signalling plane indicates that a subsequent SDP offer included the "mc_implicit_request" fmtp attribute as described in clause 14, the floor control interface towards the MCPTT client in the floor control server:

1. shall indicate to the floor control server arbitration logic that an implicit floor request is received due to an upgrade to an emergency group call; and

2. shall remain in the ‘U: not permitted and Floor Idle’ state.

6.3.5.3.10 Send Floor Idle message (S: Floor Idle)

When receiving a Floor Idle message from the floor control server arbitration logic in the MCPTT server, the floor control interface towards the MCPTT client in the floor control server:

1. shall forward the Floor Idle message to the associated floor participant;

2. may set the first bit in the subtype of the Floor Idle 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.

3. shall remain in the ‘U: not permitted and Floor Idle’ state.

6.3.5.4 State ‘U: not permitted and Floor Taken’

6.3.5.4.1 General

The floor control interface towards the MCPTT client in the floor control server uses this state when another MCPTT client (i.e. not the associated floor participant) has been given permission to send media.

In this state RTP media packets received from the media distributor in the MCPTT server are forwarded to the associated floor participant by the network media interface in the MCPTT server.

6.3.5.4.2 Enter state ‘U: not permitted and Floor Taken’

When entering this state the floor control server:

1. if a Track Info field is stored, shall remove the Track Info field from the storage; and

2. shall set the state to ‘U: not permitted and Floor Taken’.

6.3.5.4.3 Send Floor Idle message (S: Floor Idle)

When receiving a Floor Idle message from the floor control server arbitration logic in the MCPTT server, the floor control interface towards the MCPTT client in the floor control server:

1. shall forward the Floor Idle message to the associated floor participant;

2. may set the first bit in the subtype of the Floor Idle 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. if an indication is stored that the participant is listening to media from two sources, i.e. dual floor control is applied,

a. shall remain in the ‘U: not permitted and Floor Taken’ state; and

b. shall remove the indication that a participant is listening to media from two sources; and

4. if an indication for dual floor control is not stored, shall enter the ‘U: not permitted and Floor Idle’ state as specified in the clause 6.3.5.3.2.

6.3.5.4.4 Receive Floor Request message (R: Floor Request)

Upon receiving a Floor Request message from the associated floor participant, if the group is configured for audio cut-in floor control, the floor control interface towards the MCPTT client in the floor control server:

1. shall forward the Floor Request message to the floor control server arbitration logic; and

2. shall remain in the ‘U: not permitted and Floor Taken’ state.

Upon receiving a Floor Request message from the associated floor participant, if the group is configured for multi-talker floor control, if the number of granted floor participants is below the configured maximum; and the MCPTT ID of the associated floor participants is in the list of allowed configured multi-talkers, the floor control interface towards the MCPTT client in the floor control server:

1. shall forward the Floor Request message to the floor control server arbitration logic; and

2. shall remain in the ‘U: not permitted and Floor Taken’ state.

If the group is not configured for multi-talker floor control, upon receiving a Floor Request message, without a Floor Indicator field or with the Floor Indicator field included where the D-bit (Emergency call) and the E-bit (Imminent peril call) are set to ‘0’, from the associated floor participant, and if the MCPTT client did not negotiate queueing of floor requests or did not include a priority in the "mc_priority" fmtp attribute as specified in clause 14, the floor control interface towards the MCPTT client in the floor control server:

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

a. shall include in the Reject Cause field the <Reject Cause> value cause #1 (Another MCPTT client has permission);

b. may include in the Reject Cause field an additional text string explaining the reason for rejecting the floor request in the <Reject Phrase> value;

c. if the Floor Request included a Track Info field, shall include the received Track Info field; and

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

NOTE 1: 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 remain in the ‘U: not permitted and Floor Taken’ state.

Upon receiving a Floor Request message from the associated floor participant and the session is a broadcast group call or an ambient listening call, the floor control interface towards the MCPTT client in the floor control server:

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

a. shall include in the Reject Cause field the <Reject Cause> value cause #5 (Receive only);

b. may include in the Reject Cause field an additional text string explaining the reason for rejecting the floor request in the <Reject Phrase> value;

d. if the Floor Request message included a Track Info field, shall include the received Track Info field;

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

NOTE 2: 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 remain in the ‘U: not permitted and Floor Taken’ state.

Upon receiving a Floor Request message from the associated floor participant and if the MCPTT client negotiated support of queueing of floor requests or included a floor priority in the "mc_priority" or both as described in specified in clause 14 and according to local policy, the floor control interface towards the MCPTT client in the floor control server:

NOTE 3: In case the group is configured for multi-talker floor control, then the following steps are only carried out in case the maximum number of allowed talkers is reached.

1. shall determine the effective priority level as described in clause 4.1.1.4 by using the following parameters:

a. the floor priority shall be:

i. the lower of the floor priority included in Floor Request message and the negotiated maximum floor priority that the MCPTT client is permitted to request, if the MCPTT client negotiated floor priority "mc_priority" and floor priority is included in the Floor Request message;

ii. the receive only floor priority, if the MCPTT client negotiated floor priority in the "mc_priority" fmtp attribute and if the negotiated maximum floor priority that the MCPTT client is permitted to request is "receive only";

iii. the default priority, if the MCPTT client negotiated floor priority in the "mc_priority" fmtp attribute, if the negotiated maximum floor priority that the MCPTT client is permitted to request is not receive only and if the floor priority is not included in the Floor Request message; and

iv. the default priority, if the MCPTT client did not negotiate floor priority in the "mc_priority" fmtp attribute; and

b. the type of the call shall be

i. if the Floor Indicator field is included in the message and the D-bit (Emergency call bit) is set to ‘1’, determined to be an emergency call;

ii. if the Floor Indicator field is included in the message and the E-bit (Imminent peril call) is set to ‘1’, determined to be an imminent peril call; and

iii. if the Floor Indicator field is not included in the message or the Floor Indicator field is included and neither the D-bit (Emergency call bit) nor the E-bit (Imminent peril call) is set to ‘1’, determined to be a normal call;

2. if the effective priority is "receive only", the floor control interface towards the MCPTT client in the floor control server:

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

i. shall include in the Reject Cause field the <Reject Cause> value cause #5 (Receive only);

ii. may include in the Reject Cause field an additional text string explaining the reason for rejecting the floor request in the <Reject Phrase> value;

iii. if the Floor Request included a Track Info field, shall include the received Track Info field; and

iv. if a group call is a broadcast group call, a system call, an emergency call, an imminent peril call, or a temporary group session, shall include the Floor Indicator field with appropriate indications; and

b. shall remain in the ‘U: not permitted and Floor Taken’ state;

3. if

a. a Track Info field is included in the Floor Request message, shall use the topmost <Participant Reference> value and the SSRC in the received Floor Request message to check if the floor participant has a queued floor request; or

b. a Track Info field is not included in the Floor Request message, shall use the SSRC in the received Floor Request message to check if the floor participant has a queued floor request;

4. if the floor participant already has a queued floor request with the same effective priority level, the floor control interface towards the MCPTT client in the floor control server:

a. shall send a Floor Queue Position Info message to the requesting MCPTT client, if the MCPTT client negotiated support of queueing of floor requests as specified in clause 14. The Floor Queue Position Info message:

i. shall include the queue position and floor priority in the Queue Info field;

ii. if the Floor Request included a Track Info field, shall include the received Track Info field; and

iii. if a group call is a broadcast group call, a system call, an emergency call, an imminent peril call, or a temporary group session, shall include the Floor Indicator field with appropriate indications; and

b. shall remain in the ‘U: not permitted and Floor Taken’ state

5. if the effective priority level is pre-emptive and there are no other pre-emptive requests in the active floor request queue and the effective priority level of the current MCPTT client with permission to send a media is not the pre-emptive priority, the floor control interface towards the MCPTT client in the floor control server:

a. shall forward the Floor Request message to the floor control server arbitration logic indicating that a Floor Request message with pre-emptive priority is received; and

b. shall remain in the ‘U: not permitted and Floor Taken’ state

NOTE 4: The Floor control server arbitration logic initiates revoking the permission to send media towards the current MCPTT client with the permission to send media as specified in the clause 6.3.4.4.7;

6. if the MCPTT client did not negotiate support of queueing of floor requests as specified in clause 14, the effective priority level is pre-emptive and either other pre-emptive request is queued or the effective priority level of the current MCPTT client with permission to send a media is the pre-emptive priority, the floor control interface towards the MCPTT client in the floor control server:

a. shall send a Floor Deny message to the associated floor participant. The Floor Deny message:

i. shall include in the Reject Cause field the <Reject Cause> value cause #1 (Another MCPTT client has permission);

ii. may include in the Reject Cause field an additional text string explaining the reason for rejecting the floor request in the <Reject Phrase> value;

iii. if the Floor Request included a Track Info field, shall include the received Track Info field; and

b. shall remain in the ‘U: not permitted and Floor Taken’ state;

7. if the MCPTT client did not negotiate "queueing" and the effective priority level is not pre-emptive, the floor control interface towards the MCPTT client in the floor control server:

a. shall send a Floor Deny message to the associated floor participant. The Floor Deny message:

i. shall include in the Reject Cause field the <Reject Cause> value cause #1 (Another MCPTT client has permission);

ii. may include in the Reject Cause field an additional text string explaining the reason for rejecting the floor request in the <Reject Phrase> value;

iii. if the Floor Request included a Track Info field, shall include the received Track Info field; and

b. shall remain in the ‘U: not permitted and Floor Taken’ state;

8. if the MCPTT client negotiated support of queueing of floor requests as specified in clause 14 and the effective priority level is not pre-emptive and the maximum queue length has not been reached, the floor control interface towards the MCPTT client in the floor control server:

a. shall insert the MCPTT client into the active floor request queue, if not inserted yet, or update the position of the MCPTT client in the active floor request queue, if already inserted, to the position immediately following all queued requests at the same effective priority level;

b. the floor control server shall send a Floor Queue Position Info message to the floor participant. The Floor Queue Position Info message:

i. shall include the queue position and floor priority in the Queue Info field;

ii. if the Floor Request included a Track Info field, shall include the received Track Info field; and

c. shall remain in the ‘U: not permitted and Floor Taken’ state; and

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

NOTE 5: 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.

9. if the MCPTT client negotiated support of queueing of floor requests as specified in clause 14 and the effective priority level is not pre-emptive and the maximum queue length has been reached, the floor control interface towards the MCPTT client in the floor control server:

a. shall send a Floor Deny message to the associated floor participant. The Floor Deny message:

i. shall include in the Reject Cause field the <Reject Cause> value cause #7 (Queue Full);

ii. may include in the Reject Cause field an additional text string explaining the reason for rejecting the floor request in the <Reject Phrase> value;

iii. if the Floor Request included a Track Info field, shall include the received Track Info field; and

iv. if the group call is a broadcast group call, a system call, an emergency call, an imminent peril call, or a temporary group session, shall include the Floor Indicator field with appropriate indications; and

b. shall remain in the ‘U: not permitted and Floor Taken’ state.

6.3.5.4.5 Receive Floor Release message (R: Floor Release)

Upon receiving a Floor Release message from the associated floor participant and if the MCPTT client did not negotiate support of queueing of floor requests or included a floor priority in the "mc_priority" fmtp attribute as specified in clause 14, the floor control interface towards the MCPTT client in the floor control server:

1. if the first bit in the subtype of the Floor Release 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 ‘4’ (Floor Release);

b. shall include the Source field set to ‘2’ (the controlling MCPTT function is the source); and

c. if the Floor Release message included a Track Info field, shall include the received Track Info field;

2. shall send a Floor Taken message to the associated floor participant. The Floor Taken message:

a. 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;

b. shall include a Message Sequence Number field with a <Message Sequence Number> value increased with 1;

c. shall include the Permission to Request the floor field set to ‘0’, if the floor participants are not allowed to request the floor;

d. if the Floor Release message included a Track Info field, shall include the received Track Info field;

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

NOTE 1: 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.

f. if a group call is a broadcast group call, a system call, an emergency call, an imminent peril call, or a temporary group session, shall include the Floor Indicator field with appropriate indications; and

3. shall remain in the ‘U: not permitted and Floor Taken’ state.

Upon receiving a Floor Release message from the associated floor participant and if the MCPTT client negotiated support of queueing of floor requests as specified in clause 14, the floor control interface towards the MCPTT client in the floor control server:

1. if the first bit in the subtype of the Floor Release 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 ‘4’ (Floor Release);

b. shall include the Source field set to ‘2’ (the controlling MCPTT function is the source); and

c. if the Floor Release message included a Track Info field, shall include the received Track Info field;

2. if

a. a Track Info field is included in the Floor Release message, shall use the topmost <Participant Reference> value and the SSRC in the received Floor Release message to check if the floor participant has a queued floor request; or

b. if a Track Info field is not included in the Floor Release message, shall use the SSRC in the received Floor Release message to check if the floor participant has a queued floor request;

3. shall remove the MCPTT client from the active floor request queue, if the MCPTT client was in the active floor request queue;

4. shall send a Floor Taken message to the associated floor participant. The Floor Taken message:

b. if the session is a broadcast group call, shall include the Permission to Request the floor field set to ‘0’;

c. if the session is not a broadcast group call, may include the Permission to Request the floor field set to ‘1’;

d. if a Track Info field is included in the Floor Release message, shall include the received Track Info field;

e. shall include a Message Sequence Number field with a <Message Sequence Number> value increased with 1; and

5. may set 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; and

NOTE 2: 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 remain in the ‘U: not permitted and Floor Taken’ state.

6.3.5.4.6 Receive RTP media packets (R: media)

Upon receiving an indication from the network media interface in the MCPTT server that RTP media packets with payload are received from the associated floor participant, the floor control interface towards the MCPTT client in the floor control server:

1. shall request the network media interface to not forward the RTP media packets to the media distributor in the MCPTT server;

2. shall send a Floor Revoke message to the associated 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); and

3. shall enter the ‘U: not permitted but sends media’ state as specified in the clause 6.3.5.7.2.

6.3.5.4.7 Send Floor Queue Position Info message (R: Floor Queue Position Request)

Upon receiving a Floor Queue Position Request message from the associated floor participant, the floor control interface towards the MCPTT client in the floor control server:

1. shall send the Floor Queue Position Info message. The Floor Queue Position Info message:

a. shall include the queue position and floor priority in the Queue Info field;

b. if a Track Info field is included in the Floor Queue Position Info message, shall include the received Track Info field;

c. may include the first bit in the subtype of the Floor Queue Position Info message set 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.

3. shall remain in the ‘U: not permitted and Floor Taken’ state.

6.3.5.4.8 Receive an implicit floor request (R: Implicit floor request)

When an ongoing session is upgraded to an emergency group call and when the application and signalling plane indicates that a subsequent SDP offer included the "mc_implicit_request" fmtp attribute as specified in clause 14, the floor control interface towards the MCPTT client in the floor control server:

1. shall indicate to the floor control server arbitration logic that an implicit floor request is received due to an upgrade to an emergency group call; and

2. shall remain in the ‘U: not permitted and Floor Taken’ state.

6.3.5.4.9 Send Floor Granted message (S: Floor Granted)

When a Floor Granted message is received from the floor control arbitration logic in the MCPTT server, the floor control interface towards the MCPTT client in the floor control server:

1. shall forward the Floor Granted messages to the associated floor participant;

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

NOTE 1: 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. 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; and

NOTE 2: The G-bit in the Floor Indicator is set to ‘1’ as specified in clause 6.3.6.3.2.

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

6.3.5.4.10 Send Floor Taken message (S: Floor Taken)

When a Floor Taken message is received from the floor control arbitration logic in the MCPTT server, if the G-bit in the Floor Indicator is set to ‘1’ (Dual floor) the floor control interface towards the MCPTT client in the floor control server:

1. shall forward the Floor Taken message to the associated floor participant;

2. may set the first bit in the subtype of the Floor Taken 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 store an indication that the participant is listening to media from two sources; and

4. shall remain in the ‘U: not permitted and Floor Taken’ state.

When a Floor Taken message is received from the floor control arbitration logic in the MCPTT server, if the I-bit in the Floor Indicator is set to ‘1’ (multi-talker) the floor control interface towards the MCPTT client in the floor control server:

1. shall forward the Floor Taken message to the associated floor participant;

2. shall store an indication that the participant is listening to media from more than one source; and

3. shall remain in the ‘U: not permitted and Floor Taken’ state.

6.3.5.4.11 Send Floor Release Multi Talker message (S: Floor Release Multi Talker)

When a Floor Release Multi Talker message is received from the floor control arbitration logic in the MCPTT server, the floor control interface towards the MCPTT client in the floor control server:

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

2. shall remain in the ‘U: not permitted and Floor Taken’ state.

6.3.5.4.12 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 ‘0’ (Cancel Request), from the associated floor participant:

1. if the MCPTT ID of the associated floor participant is an authorized user (e.g dispatcher) to cancel the queued floor requests of other MCPTT users (the list of users specified in a request or all the users), the floor control interface towards the MCPTT client in the floor control server:

a. shall forward the Queued Floor Requests message to the floor control server arbitration logic; and

b. shall remain in the ‘U: not permitted and Floor Taken’ state; and

2. if the MCPTT ID of the associated floor participant is not an authorized user (participant type is not dispatcher, dispatch supervisor or MC service administrator) to cancel the queued floor requests of other MCPTT users (the list of specified users in a request or all the users), the floor control interface towards the MCPTT client in the floor control server:

a. shall send a Queued Floor Requests message to the associated floor participant as described in clause 8.2.15. The Queued Floor Requests message:

i. shall include a Queued Floor Requests Purpose field with the Queued Floor Requests Purpose value set to ‘1’ (Cancel Result);

ii. shall include a Queued Floor Requests Result field with the Value set to ‘1’ (Not authorized to remove the queued floor requests of all users specified in the List of Queued Users field in a message or all the queued floor requests from the floor request queue); and

iii. if the Floor Request included a Track Info field, shall include the received Track Info field;

b. may set the first bit in the subtype of the Queued Floor Requests 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.

c. shall remain in the ‘U: not permitted and Floor Taken’ state.

6.3.5.4.13 Send Queued Floor Requests message (S: 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), from the floor control server arbitration logic in the MCPTT server, the floor control interface towards the MCPTT client in the floor control server:

1. shall forward the Queued Floor Requests message to the floor participant; and

2. shall remain in the ‘U: not permitted and Floor Taken’ state.

When a Queued Floor Requests message, including a Queued Floor Requests Purpose field with the Queued Floor Requests Purpose value set to ‘2’ (Cancel Notification), is received from the floor control arbitration logic in the MCPTT server, the floor control interface towards the MCPTT client in the floor control server:

1. shall forward the Queued Floor Requests message to the associated floor participant;

2. may set the first bit in the subtype of the Queued Floor Requests 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.

3. shall remain in the ‘U: not permitted and Floor Taken’ state.

6.3.5.4.14 Void

6.3.5.5 State: ‘U: permitted’

6.3.5.5.1 General

The floor control interface towards the MCPTT client in the floor control server uses this state when the associated floor participant has been given permission to send media.

6.3.5.5.2 Enter state ‘U: permitted’

When entering this state the floor control interface towards the MCPTT client in the floor control server:

1. shall set the state for the associated floor participant to ‘U: permitted’.

6.3.5.5.3 Receive Floor Release message (R: Floor Release)

Upon receiving a Floor Release message from the associated floor participant, the floor control interface towards the MCPTT client in the floor control server:

1. if the first bit in the subtype of the Floor Release 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 ‘4’ (Floor Release);

b. shall include the Source field set to ‘2’ (the controlling MCPTT function is the source); and

c. if the Floor Release message included a Track Info field, shall include the received Track Info field;

2. if an indication that the participant is overriding without revoke is stored,

a. shall forward the Floor Release message to the ‘dual floor control operation’ state machine of the floor control arbitration logic in the MCPTT server with the first bit in the subtype of the Floor Release message set to ‘0’ (Acknowledgment is not required), if not already set;

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

c. shall enter the ‘U: not permitted and Floor Taken’ state as specified in the clause 6.3.5.4.2;

3. if an indication that the participant is overridden without revoke is stored,

a. shall forward the Floor Release message to the general floor control operation state machine of the floor control arbitration logic in the MCPTT server with the first bit in the subtype of the Floor Release message set to ‘0’ (Acknowledgment is not required), if not already set;

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

c. shall enter the ‘U: not permitted and Floor Taken’ state as specified in the clause 6.3.5.4.2; and

4. if no indication is stored:

b. shall remain in the ‘U: permitted’ state.

6.3.5.5.4 Send Floor Idle message (S: Floor Idle)

Upon receiving the Floor Idle message from the floor control server arbitration logic in the MCPTT server, the floor control interface towards the MCPTT client in the floor control server:

1. 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. shall send Floor Idle message to the associated floor participant;

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

c. shall remain in ‘U: permitted state’;

2. if no indication is stored shall enter the ‘U: not permitted and Floor Idle’ state as specified in the clause 6.3.5.3.2; and

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

a. shall send Floor Idle message to the associated floor participant;

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

c. shall remain in ‘U: permitted state’.

6.3.5.5.5 Send Floor Revoke message (S: Floor Revoke)

When receiving the Floor Revoke message from the floor control server arbitration logic in the MCPTT server, the floor control interface towards the MCPTT client in the floor control server:

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

2. if the Floor Revoke message includes the Track Info field, shall store the Track Info field; and

3. shall enter the state ‘U pending Floor Revoke’ as specified in the clause 6.3.5.6.2.

6.3.5.5.6 Receive RTP media packets (R: media)

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

a. shall request the network media interface in the MCPTT server to forward RTP media packets to the media distributor in the MCPTT server; and

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

6.3.5.5.7 Receive Floor Request message (R: Floor Request)

Upon receiving a Floor Request message from the associated floor participant, the floor control interface towards the MCPTT client in the floor control server:

1. shall forward the Floor Request message to the floor control server arbitration logic in the MCPTT server; and

b. shall instruct the media distributor to act as in clause 6.3.4.4.5.

2. if an indication that the participant is overriding without revoke is stored,

a. shall request the network media interface in the MCPTT server to forward RTP media packets to the media distributor in the MCPTT server; and

b. shall instruct the media distributor to act as in clause 6.3.6.3.5; and

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

6.3.5.5.8 Send RTP Media (S: media)

When RTP packets are received from the media distributor, the floor control interface towards the MCPTT client in the floor control server:

1. shall forward the RTP packet to the associated floor participant if the indication that the participant is overridden without revoke is stored;

2. shall forward the RTP packet to the associated floor participant if the indication that the participant is overriding without revoke is stored; and

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

6.3.5.5.9 Send Floor Taken message (S: Floor Taken)

When receiving the Floor Taken message from the floor control server arbitration logic in the MCPTT server with the G-bit in the Floor Indicator set to ‘1’ (Dual Floor), the floor control interface towards the MCPTT client in the floor control server:

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

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

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

When receiving the Floor Taken message from the floor control server arbitration logic in the MCPTT server with the G-bit in the Floor Indicator set to ‘0’ (Not dual floor), the floor control interface towards the MCPTT client in the floor control server:

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

2. shall enter the ‘U: not permitted and Floor Taken’ state as specified in the clause 6.3.5.4.2.

When receiving the Floor Taken message from the floor control server arbitration logic in the MCPTT server with the I-bit in the Floor Indicator set to ‘1’ (multi-talker), the floor control interface towards the MCPTT client in the floor control server:

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

2. shall store an indication that the participant is listening to media from more than one source; and

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

6.3.5.5.10 Send Floor Release Multi Talker message (S: Floor Release Multi Talker)

When a Floor Release Multi Talker message is received from the floor control arbitration logic in the MCPTT server, the floor control interface towards the MCPTT client in the floor control server:

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

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

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

1. if the MCPTT ID of the associated floor participant is an authorized user (e.g dispatcher) to cancel the queued floor request of other MCPTT users (the list of specified users in a request or all the users), the floor control interface towards the MCPTT client in the floor control server:

a. shall forward the Queued Floor Requests message to the floor control server arbitration logic; and

b. shall remain in the ‘U: permitted’ state; and

2. if the MCPTT ID of the associated floor participant is not an authorized user (If participant type is not dispatcher, dispatch supervisor or MC service administrator) to cancel the queued floor request of other MCPTT users (the list of specified users in a request or all the users), the floor control interface towards the MCPTT client in the floor control server:

a. shall send a Queued Floor Requests message to the associated floor participant as described in clause 8.2.15. The Queued FloorRequests message:

i. shall include a Queued Floor Requests Purpose field with the Queued Floor Requests Purpose value set to ‘1’ (Cancel Result);

ii. shall include in the Queued Floor Requests Result Value set to ‘1’ (Not authorized to remove the queued floor requests of all users specified in the List of Queued Users field in a message or all the queued floor requests from the floor request queue); and

iii. if the Floor Request included a Track Info field, shall include the received Track Info field;

b. may set the first bit in the subtype of the Queued Floor Requests 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.

c. shall remain in the ‘U: permitted’ state.

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

1. shall forward the Queued Floor Requests message to the floor participant; and

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

When a Queued Floor Requests message including a Queued Floor Requests Purpose field with the Queued Floor Requests Purpose value set to ‘2’ (Cancel Notification), is received from the floor control arbitration logic in the MCPTT server, the floor control interface towards the MCPTT client in the floor control server:

1. shall forward the Queued Floor Requests message to the associated floor participant;

2. may set the first bit in the subtype of the Queued Floor Requests 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.

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

6.3.5.5.13 Void

6.3.5.6 State: ‘U: pending Floor Revoke’

6.3.5.6.1 General

The floor control interface towards the MCPTT client in the floor control server uses this state during the grace period after sending the Floor Revoke message.

In this state timer T8 (Floor Revoke) is running.

6.3.5.6.2 Enter state ‘U pending Floor Revoke’

When entering this state the floor control interface towards the MCPTT client in the floor control server:

1. shall start timer T8 (Floor Revoke); and

2. shall enter the state ‘U: pending Floor Revoke’.

6.3.5.6.3 Timer T8 (media Revoke) expired

On expiry of timer T8 (Floor Revoke) the floor control interface towards the MCPTT client in the floor control server:

1. shall retransmit the Floor Revoke message to the associated floor participant. The Floor Revoke message:

a. shall include the same Rejection Cause field and the same Floor Indicator field as in the previous sent Floor Revoke message;

2. shall start timer T8 (Floor Revoke); and

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

NOTE: The number of times the floor control server retransmits the Floor Revoke message and the action to take when the floor control server gives up is an implementation option. However, it is recommended that the MCPTT client is disconnected from the MCPTT call when the floor control server gives up.

6.3.5.6.4 Receive RTP media packets (R: media)

Upon receiving an RTP media packet with payload from the associated floor participant, the floor control interface towards the MCPTT client in the floor control server:

1. shall forward RTP media packets to the media distributor; and

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

6.3.5.6.5 Receive Floor Release message (R: Floor Release)

Upon receiving a Floor Release message from the associated floor participant, the floor control interface towards the MCPTT client in the floor control server:

1. if the first bit in the subtype of the Floor Release 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 ‘4’ (Floor Release);

b. shall include the Source field set to ‘2’ (the controlling MCPTT function is the source); and

c. if the Floor Release message included a Track Info field, shall include the received Track Info field;

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

a. if the state in the ‘general floor control operation’ state machine is ‘G: Taken’:

i. shall send a Floor Taken message to the associated floor participant. The Floor Taken message:

A. shall include the granted MCPTT user’s MCPTT ID in the Granted Party’s Identity field of the permitted MCPTT client and may include the functional alias of the granted MCPTT user in the Functional Alias field, if privacy is not requested;

C. if the Floor Release message included a Track Info field, shall include the received Track Info field; and

ii. shall enter the ‘U: not permitted and Floor Taken’ state as specified in the clause 6.3.5.4.2; and

b. if the state in the ‘general floor control operation’ state machine is ‘G: Idle’:

i. shall send a Floor Idle message to the associated floor participant;

ii. if a group call is a broadcast group call, a system call, an emergency call, an imminent peril call, or a temporary group session, shall include the Floor Indicator field with appropriate indications;

iii. if the Floor Release message included a Track Info field, shall include the received Track Info field; and

iv. shall enter the ‘U: not permitted and Floor Idle’ state as specified in the clause 6.3.5.3.2; and

3. if the G-bit in the Floor Indicator is set to ‘0’:

a. shall forward the Floor Release message to the floor control server arbitration logic; and

b. shall remain in the state ‘U: pending Floor Revoke’.

6.3.5.6.6 Send Floor Idle message (S: Floor Idle)

Upon receiving a Floor Idle message from the floor control server arbitration logic in the MCPTT server, the floor control interface towards the MCPTT client in the floor control server:

NOTE 1: The Floor Idle message is sent when timer T3 (Stop talking grace) expires and when timer T1 (End of RTP media) expires and when there are no queued floor requests.

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

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

NOTE 2: 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 enter the ‘U: not permitted and Floor Idle’ state as specified in the clause 6.3.5.3.2.

6.3.5.6.7 Send Floor Taken message (S: Floor Taken)

Upon receiving a Floor Taken message from the floor control server arbitration logic in the MCPTT server, the floor control interface towards the MCPTT client in the floor control server:

NOTE 1: The Floor Taken message is sent when timer T3 (Stop talking grace) expires or when timer T1 (End of RTP media) expires and if there are queued floor requests.

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

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

NOTE 2: 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 enter the ‘U: not permitted and Floor Taken’ state as specified in the clause 6.3.5.4.2.

6.3.5.6.8 Send Floor Release Multi Talker message (S: Floor Release Multi Talker)

When a Floor Release Multi Talker message is received from the floor control arbitration logic in the MCPTT server, the floor control interface towards the MCPTT client in the floor control server:

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

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

6.3.5.7 State ‘U: not permitted but sends media’

6.3.5.7.1 General

The floor control interface towards the MCPTT client in the floor control server uses this state when it receives RTP media packets from the MCPTT client and the MCPTT client is not permitted to send media.

Timer T8 (Floor Revoke) is running in this state.

6.3.5.7.2 Enter state ‘U: not permitted but sends media’

When entering this state the floor control interface towards the MCPTT client in the floor control server:

1. shall start timer T8 (Floor Revoke); and

2. shall enter the state ‘U: not permitted but sends media’.

In this state the floor control interface towards the MCPTT client in the floor control server:

1. shall not request the network media interface in the MCPTT server to forward RTP media packets from the MCPTT client to the media distributor in the MCPTT server.

6.3.5.7.3 Timer T8 (Floor Revoke) expired

On expiry of timer T8 (Floor Revoke), the floor control interface towards the MCPTT client in the floor control server:

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

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

c. if a Track Info field was included in the Floor Request message, shall include the stored Track Info field; and

2. shall restart timer T8 (Floor Revoke); and

3. shall remain in the ‘U: not permitted but sends media’ state.

NOTE: The number of times the floor control server retransmits the Floor Revoke message and the action to take when the floor control server gives up is an implementation option. However, the recommended action is that the MCPTT client is disconnected from the MCPTT call.

6.3.5.7.4 Receive Floor Release message (R: Floor Release)

Upon receiving a Floor Release message, the floor control interface towards the MCPTT client in the floor control server:

1. if the first bit in the subtype of the Floor Release 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 ‘4’ (Floor Release);

b. shall include the Source field set to ‘2’ (the controlling MCPTT function is the source); and

c. if the Floor Release message included a Track Info field, shall include the received Track Info field;

2. if the general state is ‘G: Floor Idle’, the floor control interface towards the MCPTT client in the floor control server:

a. shall send the Floor Idle message. The Floor Idle message:

i. shall include a Message Sequence Number field with a Message Sequence Number value increased with 1;

iii. if the Floor Release message included a Track Info field, shall include the received Track Info field; and

b. shall enter the ‘U: not permitted and Floor Idle’ state as specified in the clause 6.3.5.3.2; and

3. if the general state is ‘G: Floor Taken’, the floor control interface towards the MCPTT client in the floor control server:

a. shall send a Floor Taken message. 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;

ii. if the session is a broadcast group call, shall include the Permission to Request the floor field set to ‘0’;

iii. if the session is not a broadcast group call, may include the Permission to Request the floor field set to ‘1’;

iv. may include the first bit in the subtype of the Floor Taken 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.

v. if a group call is a broadcast group call, a system call, an emergency call, an imminent peril call, or a temporary group session, shall include the Floor Indicator field with appropriate indications; and

vi. if the Floor Release message included a Track Info field, shall include the received Track Info field; and

b. shall enter the ‘U: not permitted and Floor Taken’ state as specified in the clause 6.3.5.4.2.

6.3.5.7.5 Send Floor Taken message (S: Floor Taken)

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

2. shall store an indication that the participant is listening to media from more than one source; and

3. shall remain in the ‘U: not permitted but sends media’ state.

6.3.5.7.6 Send Floor Release Multi Talker message (S: Floor Release Multi Talker)

When a Floor Release Multi Talker message is received from the floor control arbitration logic in the MCPTT server, the floor control interface towards the MCPTT client in the floor control server:

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

2. shall remain in the ‘U: not permitted but sends media’ state.

6.3.5.8 In any state

6.3.5.8.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’ and ‘Releasing’ states.

6.3.5.8.2 Receive MCPTT call release – 1

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

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

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

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

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

5. shall indicate to the floor control server arbitration logic in the MCPTT server that the MCPTT client has started to disconnect from the MCPTT call; and

6. shall enter the ‘Releasing’ state.

6.3.5.8.3 Receiving a merging instruction (R: Merge)

Upon receipt of an instruction to merge with another group due to the group regrouping function, the floor control interface towards the MCPTT client:

1. shall create an instance of the ‘floor participant interface state transition’ as specified in clause 6.5.5;

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

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

3. shall enter the ‘Start-stop’ state and terminate the ‘basic floor control operation towards the floor participant” state machine associated with this floor participant and this MCPTT call;

4. if the state was ‘U: not permitted and Floor Idle’, ‘U: not permitted Floor Taken’, ‘U: pending Floor Revoke’, ‘U: not permitted and initiating’ or ‘U: not permitted but sends media’:

a. shall enter the ‘P: has no permission’ state as specified in clause 6.5.5; and

b. shall perform actions specified in clause 6.5.5.3; and

5. if the state was ‘U: permitted’:

a. shall enter the ‘P: has permission’ state; and

b. shall perform actions specified in clause 6.5.5.4.

6.3.5.9 State: ‘Releasing’

6.3.5.9.1 General

The floor control interface towards the MCPTT client in the floor control server uses this state while waiting for the application and signalling plane to finalize the release of the MCPTT call or finalizing the removal of the MCPTT client from the MCPTT call.

6.3.5.9.2 Receive MCPTT call release – 2

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

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 ‘basic floor control operation towards the floor participant” state machine associated with this floor participant and this MCPTT call.

6.3.5.10 State: ‘U: not permitted and initiating’

6.3.5.10.1 General

The floor control interface towards the MCPTT client uses this state when waiting for the floor control arbitration logic to finalize the initialisation of the state machine to be used for a temporary group session.

During this state Floor Request messages can be received from the non-controlling MCPTT function. Any Floor Request message received will be added to the queue according to the priority of the floor request determine as described in clause 4.1.1.4.

6.3.5.10.2 Enter the ‘U: not permitted and initiating’ state

The floor control interface towards the MCPTT client:

1. shall set the state for the associated floor participant to ‘U: not permitted and Initiating’.

6.3.5.10.3 Send Floor Taken message (S: Floor Taken)

When a Floor Taken message is received from the floor control arbitration logic in the MCPTT server, the floor control interface towards the MCPTT client:

1. shall forward the Floor Taken messages to the associated floor participant;

2. may set the first bit in the subtype of the Floor Taken 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.

3. shall enter the state ‘U: not permitted and Floor Taken’ as specified in clause 6.3.5.4.2.

6.3.5.10.4 Send Floor Idle message (S: Floor Idle)

When receiving a Floor Idle message from the floor control server arbitration logic in the MCPTT server, the floor control interface towards the MCPTT client:

1. shall forward the Floor Idle message to the associated floor participant;

2. may set the first bit in the subtype of the Floor Idle 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.

3. shall enter the ‘U: not permitted and Floor Idle’ state as specified in the clause 6.3.5.3.2.

6.3.5.10.5 Receive Floor Request message (R: Floor Request)

Upon receipt of a Floor Request message, the floor control interface towards the MCPTT client:

1. shall determine the effective priority level as described in clause 4.1.1.4;

2. shall put the Floor Request message in the active floor request queue according to the determined effective priority level;

3. if the <Queueing Capability> value in the Track Info field is set to ‘1’ (the floor participant in the MCPTT client supports queueing), shall send a Floor Queue Position Info message to the requesting non-Controlling MCPTT function, The Floor Queue Position Info message:

a. shall include the queue position and floor priority in the Queue Info field;

b. shall include the received Track Info field; and

4 if the <Queueing Capability> value in the Track Info field is set to ‘0’ (the floor participant in the MCPTT client does not support queueing), shall send the Floor Deny message. The floor Deny message:

NOTE: A Floor Request from a MCPTT client in a constituent group can be received without the queueuing capability if a floor participant in an ongoing constituent MCPTT group request floor while the floor was idle during the merging process.

a. shall include in the Reject Cause field the <Reject Cause> value cause ‘1’ (Another MCPTT client has permission);

b. shall include the received Track Info field; and

5. shall remain in the ‘U: not permitted and initiating’ state.

6.3.5.10.6 Send Floor Granted message (S: Floor Granted)

When a Floor Granted message is received from the floor control arbitration logic, the floor control interface towards the MCPTT client:

1. shall forward the Floor Granted messages to the associated floor participant;

2. may set the first bit in the subtype of the Floor Granted 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.

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

6.3.5.10.7 Receive a Floor Release message (S: Floor Release)

Upon receiving a Floor Release message from the associated floor participant, the floor control interface towards the MCPTT client:

1. if the first bit in the subtype of the Floor Release 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 ‘4’ (Floor Release);

b. shall include the Source field set to ‘2’ (the controlling MCPTT function is the source); and

c. if the Floor Release message included a Track Info field, shall include the received Track Info field;

2. shall use the topmost <Participant Reference> value and the SSRC in the Track Info field of the received Floor Release message to check if the floor participant has a queued floor request and if not, check if there is a floor request in one of the cached application/vnd.3gpp.mcptt-floor-request+xml MIME bodies;

3. shall remove the MCPTT client from the active floor request queue or the cached application/vnd.3gpp.mcptt-floor-request+xml MIME body, if the MCPTT client was in the active floor request queue or in the application/vnd.3gpp.mcptt-floor-request+xml MIME body; and

4. shall remain in the ‘U: not permitted and initiating’ state.

6.3.5.10.8 Send Floor Release Multi Talker message (S: Floor Release Multi Talker)

When a Floor Release Multi Talker message is received from the floor control arbitration logic in the MCPTT server, the floor control interface towards the MCPTT client in the floor control server:

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

2. shall remain in the ”U: not permitted and initiating’ state.