6.3.4 Floor control server state transition diagram for general floor control operation

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

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

6.3.4.1 General

The floor control server arbitration logic in the floor control server shall behave according to the state diagram and state transitions specified in this clause.

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

Figure 6.3.4.1-1: Floor control server state transition diagram for ‘general floor control operation’

The floor control arbitration logic in the floor control server shall keep one instance of the ‘general floor control operation’ state machine per MCPTT call.

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 arbitration logic in the floor control server:

1. shall discard the floor control message;

2. shall request the media distributor 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.4.2 State: ‘Start-stop’

6.3.4.2.1 General

When a new instance of the ‘general floor control operation’ state machine 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 or the related MCPTT call is released.

6.3.4.2.2 MCPTT call initialization

When an MCPTT call is initiated as specified in 3GPP TS 24.379 [2] and

1. if a confirmed indication is required and at least one invited MCPTT client has accepted the invitation;

2. if a confirmed indication is not required; or

3. if the initialised MCPTT call is a temporary group session;

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

then the floor control arbitration logic in the floor control server:

1. shall create an instance of the ‘general floor control operation’ state machine;

2. shall wait for the ‘basic floor control operation towards the floor participant’ to be initialized before continuing the following steps;

3. when the ‘basic floor control operation towards the floor participant’ state machine is initialized and the initialised session is not a temporary group session:

a. if the "mc_granted" fmtp attribute is not negotiated as specified in clause 14 or this is an ambient listening call:

i. if the floor control server is granting an implicit floor request at MCPTT call establishment, shall act as if a Floor Request message was received and perform the actions specified in clause 6.3.4.3.3; or

ii. if the floor control server is not granting an implicit floor request at MCPTT call establishment, shall enter the’G: Floor Idle’ state as specified in clause 6.3.4.3.2; or

b. if the "mc_granted" fmtp attribute is negotiated as specified in clause 14 and this is not an ambient listening call, shall enter the ‘G: Floor Taken’ state as specified in clause 6.3.4.4.2; and

4. if the ‘basic floor control operation towards the floor participant’ state machine is initialized and the initialised session is a temporary group session, shall enter the ‘G: Initialising’ state as specified in the clause 6.3.4.8.1.

6.3.4.3 State: ‘G: Floor Idle’

6.3.4.3.1 General

The floor control arbitration logic in the floor control server is in this state when no MCPTT user currently has permission to send media.

Timer T4 (Inactivity) and timer T7 (Floor Idle) can be running when the floor control arbitration logic in the floor control server is in this state.

6.3.4.3.2 Enter the ‘G: Floor Idle’ state

When entering this state from any state except the ‘Start-stop’ state and if no MCPTT client negotiated support of queueing floor requests as described in clause 14, and the state machine specified in clause 6.3.6 does not exist, the floor control arbitration logic in the floor control server:

1. if there is a Track Info field associated with the floor control server state transition diagram for ‘general floor control operation’ stored, shall remove the Track Info field from the storage;

2. if the active floor request queue is empty the floor control server:

a. shall send Floor Idle message to all floor participants. The Floor Idle message:

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

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;

b. shall start timer T7 (Floor Idle) and initialise counter C7 (Floor Idle) to 1;

c. shall start timer T4 (Inactivity); and

d. shall set the general state to the ‘G: Floor Idle’ state; and

3. if the active floor request queue is not empty the floor control server:

a. shall select a queued floor request from the top of the active floor request queue;

b. shall remove that queued floor request from the active floor request queue;

c. if the queued floor request includes a Track Info field, shall store the Track Info field and associate it with the floor control server state transition diagram for ‘general floor control operation’; and

d. shall enter the ‘G: Floor Taken’ state as specified in the clause 6.3.4.4.2 with respect to that floor participant.

When entering this state from any state except the ‘Start-stop’ state and the state machine specified in clause 6.3.6 exists, the floor control arbitration logic in the floor control server:

2. shall send Floor Idle message to all floor participants which are configured to listen to the overridden participant. 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;

3. shall send Floor Taken message to floor participants which are configured to listen only to the overridden participant. The Floor Taken message:

a. if privacy is not requested, shall include the granted MCPTT user’s (overriding participant) MCPTT ID in the Granted Party’s Identity field;

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

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; and

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

4. shall set the general state to the ‘G: Floor Taken’ state; and

5. shall send the termination instruction to the ‘dual floor control operation’ state machine.

6.3.4.3.3 Receive Floor Request message (R: Floor Request)

Upon receiving a floor request message (from a floor participant that is permitted to make a floor request) the floor control arbitration logic in the floor control server:

1. shall reject the request if one of the following conditions is fulfilled:

a. if there is only one MCPTT client in the MCPTT call; and

b. <on-network-recvonly> element is present in the <entry> element as specified 3GPP TS 24.481 [12] for the associated floor participant;

2. if the floor request is rejected the floor control server:

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

i. shall include in the Reject Cause field the <Reject Cause> value:

A. cause #3 (Only one participant), if there is only one MCPTT client in the MCPTT call; or

B. cause #5 (Receive only), if the <on-network-recvonly> element is present in the <entry> element as specified in 3GPP TS 24.481 [12] for the associated floor participant;

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

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

b. shall remain in the ‘G: Floor Idle’ state; and

3. if the floor request is granted the floor control server:

a. shall stop timer T4 (Inactivity);

b. shall stop timer T7 (Floor Idle);

c. shall store the SSRC of floor participant granted the permission to send media until the floor is released associated to that floor request;

d. if a Track Info field is included in the Floor Request message, shall store the received Track Info field, and

e. shall enter the ‘G: Floor Taken’ state as specified in the clause 6.3.4.4.2.

6.3.4.3.4 Timer T7 (Floor Idle) expired

On expiry of timer T7 (Floor Idle) the floor control arbitration logic in the floor control server:

1. shall restart timer T7 (Floor Idle) and increment counter C7 (Floor Idle) by 1 if counter C7 (Floor Idle) has not reached its upper limit;

2. shall send a Floor Idle message to all floor participants in the MCPTT call if counter C7 (Floor Idle) has not reached its upper limit. The Floor Idle message:

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

3. shall remain in the ‘G: Floor Idle’ state.

6.3.4.3.5 Timer T4 (Inactivity) expired

On expiry of timer T4 (Inactivity) the floor control arbitration logic in the floor control server based on a configurable service provider policy either:

1. shall indicate to the application and signalling plane that timer T4 (Inactivity) has expired;

2. if the application and signalling planes initiates MCPTT call release, shall enter the ‘Releasing’ state; and

3. if the application and signalling planes do not initiate MCPTT call release:

a. should restart the T4 (Inactivity) timer; and

b. shall remain in the ‘G: Floor Idle’ state.

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

Upon receiving an implicit floor request due to an upgrade to an emergency group call or due to an upgrade to imminent peril call, the floor control arbitration logic in the floor control server:

1. shall reject the request if there is only one MCPTT client in the MCPTT call;

2. if the floor request is rejected the floor control server:

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

i. shall include in the Reject Cause field the <Reject Cause> value cause #3 (Only one participant); and

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; and

b. shall remain in the ‘G: Floor Idle’ state; and

3. if the floor request is granted the floor control server:

a. shall stop the timer T4 (Inactivity);

b. shall stop the timer T7 (Floor Idle);

c. shall store the SSRC of floor participant granted the permission to send media until the floor is released associated to that floor request; and

d. shall enter the ‘G: Floor Taken’ state as specified in the clause 6.3.4.4.2.

6.3.4.3.7 Receive a unicast media stop request (R: Unicast Media Flow Control)

Upon receiving a Unicast Media Flow Control message from a floor participant with Media Flow Control Indicator is set to ‘0’, the floor control arbitration logic in the floor control server:

1. may de-allocate associated bearer resources by the MCPTT server;

2. shall notify the media distributor to stop sending media to the MCPTT client; and

3. shall remain in the ‘G: Floor Idle’ state.

6.3.4.3.8 Receive a unicast media resume request (R: Unicast Media Flow Control)

Upon receiving a Unicast Media Flow Control message from a floor participant with Media Flow Control Indicator is set to ‘1’, the floor control arbitration logic in the floor control server:

1. may allocate new bearer resources;

2. shall notify the media distributor to start sending media to the MCPTT client; and

3. shall remain in the ‘G: Floor Idle’ state.

6.3.4.4 State: ‘G: Floor Taken’

6.3.4.4.1 General

The floor control arbitration logic in the floor control server uses this state when it has permitted one or more of the MCPTT clients in the MCPTT call to send media.

Timer T1 (End of RTP media) is running when the floor control server is in this state. If configured to support multi-talker floor control, one instance of timer T1 (End of RTP media) is running per talker that is granted the floor.

Timer T2 (End talking) can be running when the floor control server is in this state. If configured to support multi-talker floor control, one instance of timer T20 (Floor Granted) is running per talker that is granted the floor.

Timer T20 (Floor Granted) is running to guarantee reliable delivery of the Floor Granted message, if the granted floor request was queued. If configured to support multi-talker floor control, one instance of timer T20 (Floor Granted) is running per talker that is granted the floor.

If configured to support multi-talker, then the floor control arbitration logic maintains a list of MCPTT IDs of the currently granted talkers.

6.3.4.4.2 Enter the ‘G: Floor Taken’ state

When entering this state the floor control arbitration logic in the floor control server:

1. shall send a Floor Granted message to the floor participant to which the floor is granted. The Floor Granted message:

a. shall include the value of timer T2 (Stop talking)in the Duration field;

b. shall include the granted priority in the Floor priority field;

c. if a Track Info field associated with the floor control server state transition diagram for ‘general floor control operation’ is stored, shall include the stored Track Info field;

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

e. if the call is a remotely initiated ambient listening call, shall 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: If the call is an ambient listening call and the ambient listening call type is remote-initiated, then the floor participant to which the floor is granted is the terminating floor participant of the call. Otherwise the floor is granted to the participant which requested the floor.

2. shall start timer T20 (Floor Granted) if the floor request was queued for the participant to which the floor is granted and initialise the counter C20 (Floor Granted) to 1;

3. shall send Floor Taken message to all other floor participants. The Floor Taken message:

a. if the floor is currently granted only to one particpant:

i shall include the granted MCPTT user’s MCPTT ID in the Granted Party’s Identity field, if privacy is not requested;

ii. may include the functional alias of the granted MCPTT user in the Functional Alias field, if privacy is not requested; and

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

b. if multi-talker is supported and the floor is currently granted to multiple participants:

i. shall include the Floor Indicator field with the I-bit set to ‘1’ (Multi-talker);

ii. shall include the list of granted users in the multi-talker group in List of Granted Users field, including a new granted talker;

iii. shall include the list of SSRCs of granted floor participants;

iv) may include the list of functional aliases of the granted floor participants in the List of Functional Aliases field; and

v. shall include the List of Locations of granted floor participants;

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

d. if the session is a broadcast group call or an ambient listening call, shall include the Permission to Request the Floor field set to ‘0’;

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

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;

4. shall start timer T1 (End of RTP media) for the participant to which the floor is granted;

5. shall set the general state to ‘G: Floor Taken’ state; and

6. if configured to support multi-talker floor control the group is configured to shall add the MCPTT identity of the participant to which the floor is granted to the list of currently granted talkers.

6.3.4.4.3 Timer T1 (End of RTP media) expired

On expiry of timer T1 (End of RTP media), the floor control arbitration logic in the floor control server:

1. shall stop the timer T2 (Stop talking) for the participant to which the floor is granted; if running;

2. shall stop timer T20 (Granted re-send) for the participant to which the floor is granted, if running;

3. shall request the media distributor in the MCPTT server to stop distributing RTP media packets received from the participant for which T1 (End of RTP media) has expired (with the exception of RTP media packets already in the buffer (if RTP media buffering is ongoing)) to other MCPTT clients;

4. if mutli-talker floor control is not supported; shall enter the ‘G: Floor Idle’ state as specified in the clause 6.3.4.3.2; and

5. if multi-talker floor control is supported,

a. shall send a Floor Release Multi Talker message to all participants other than the one releasing floor. The Floor Release Multi Talker message:

i. shall include SSRC field set to the SSRC of the floor participant for which T1 expired; and

ii. shall include the User ID set to the MCPTT ID of the floor participant for which T1 expired; and

b. shall remove the participant for which timer T1 expired from the list of currently granted talkers, and:

i. if the list of currently granted talkers is empty, shall enter the ‘G: Floor Idle’ state as specified in the clause 6.3.4.3.2; and

ii. if the list of currently granted talkers is not empty shall stay in state the ‘G: Floor Taken’.

6.3.4.4.4 Timer T2 (Stop talking) expired

On expiry of timer T2 (Stop talking), the floor control arbitration logic in the floor control server:

1. shall stop timer T1 (End of RTP media) for the participant for which timer T2 has expired;

2. shall include the Reject Cause field with the <Reject Cause> value set to #2 (Media burst too long) in the Floor Revoke message sent in clause 6.3.4.5.2; and

3. shall enter the ‘G: pending Floor Revoke’ state as specified in the clause 6.3.4.5.2.

6.3.4.4.5 Receive RTP media packets (R: RTP media)

Upon receiving an indication from the media distributor in the MCPTT server that RTP media packets are received from the permitted MCPTT client, the floor control arbitration logic in the floor control server:

1. if the session is not an ambient listening call, shall start timer T2 (Stop talking) for the participant from which the RTP packet has been received, if not running;

2. shall restart timer T1 (End of RTP media) for the participant from which the RTP packet has been received;

3. shall stop timer T20 (Floor Granted) for the participant from which the RTP packet has been received, if running;

4. shall instruct the media distributor to forward the RTP media packets to MCPTT clients according to local policy; and

NOTE: If dual floor control is ongoing as described in clause 6.3.6, the list of floor participants that receive the overriding, overridden, or both transmissions is based on configuration.

5. shall remain in the ‘G: Floor Taken’ state.

6.3.4.4.6 Receive Floor Release message (R: Floor Release)

Upon receiving a Floor Release message the floor control arbitration logic in the floor control server:

1. shall request the media distributor in the MCPTT server to stop forwarding RTP media packets received from the participant that sent the Floor Release message;

2. shall stop timer T2 (Stop talking) for the participant that sent the Floor Release message, if running;

3. shall stop timer T20 (Granted re-send) for the participant that sent the Floor Release message, if running;

4. if mutli-talker floor control is not supported shall enter the ‘G: Floor Idle’ state as specified in the clause 6.3.4.3.2; and

5. if multi-talker floor control is supported, then:

a. shall send a Floor Release Multi Talker message. The Floor Release Multi Talker message:

i. shall include SSRC field set to the SSRC of the floor participant that has released the floor; and

ii. shall include the User ID set to the MCPTT ID of the floor participant releasing the floor;

b. shall remove the participant that sent the Floor Release message from the list of currently granted talkers; and

c. if the list of currently granted talkers is empty, shall enter the ‘G: Floor Idle’ state as specified in the clause 6.3.4.3.2; or if the list of currently granted talkers is not empty shall stay in state the ‘G: Floor Taken’.

6.3.4.4.7 Receive Floor Request message with pre-emptive priority (R: pre-emptive Floor Request)

NOTE 1: This procedure is also invoked from the clause 6.3.5.4.4.

If the group is not configured to support multi-talker feature control, on receipt of a floor request message with effective priority indicating pre-emptive priority, and if the effective priority of the floor participant with permission to send media is not the pre-emptive priority, or if the group is configured for audio cut-in, the floor control arbitration logic in the floor control server:

1. based on local policy, select one of the following options:

a. revoke the current speaker; or

b. allow media from both the current speaker and from the participant now requesting floor with a pre-emptive floor priority;

NOTE 2: If the group is configured for audio cut-in, media is allowed only for the participant now requesting the floor.

2. if revoking current speaker is selected:

a. shall stop timer T1 (End of RTP media), if running;

b. shall stop timer T20 (Floor Granted), if running;

c. shall include a Reject Cause field with the <Reject Cause> value set to #4 (Media Burst pre-empted) in the Floor Revoke message sent in clause 6.3.4.5.2;

d. shall enter the ‘G: pending Floor Revoke’ state as specified in the clause 6.3.4.5.2;

e. shall insert the floor participant into the active floor request queue to the position in front of all queued requests, if not inserted yet or update the position of the floor participant in the active floor request queue to the position in front of all other queued requests, if already inserted; and

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

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

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

3. if allow media from both the current speaker and from the participant now requesting floor with a pre-emptive priority is selected:

a. shall perform the actions specified in the clause 6.3.6.2.2

6.3.4.4.7a Receive Floor Request message multi-talker (R: multi-talker Floor Request)

On receipt of a floor request message and if the group is configured as multi-talker group the floor control arbitration logic in the floor control server:

1. shall select one of the following options:

a. if the maximum number of simultaneous talkers applicable for multi-talker control is reached and if the floor request message has effective priority indicating pre-emptive priority, determine from all participants having permission to send media, the one with the lowest priority and revoke the floor from the participant with the lowest priority; or

b. if the maximum number of simultaneous talkers applicable for multi-talker control is not reached, allow media from both the current speaker(s) and from the participant now requesting floor;

2. if revoking is selected:

a. shall stop timer T1 (End of RTP media) for the participant from which the floor is revoked, if running;

b. shall stop timer T20 (Floor Granted) for the participant from which the floor is revoked, if running;

c. shall include a Reject Cause field with the <Reject Cause> value set to #4 (Media Burst pre-empted) in the Floor Revoke message sent in clause 6.3.4.5.2;

d. shall enter the ‘G: pending Floor Revoke’ state as specified in the clause 6.3.4.5.2;

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

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

3. if allow media from both the current speaker(s) and from the participant now requesting floor is selected:

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

i. shall include the value of the T2 (Stop talking) timer in the Duration field;

ii. shall include the granted priority in the Floor priority field;

iii. if a Track Info field associated with the floor control server state transition diagram for ‘multe-talker floor control operation’ is stored, shall include the stored Track Info field;

iv. shall include the Floor Indicator field with the I-bit set to ‘1’ (Multi-talker); and

v. shall include the SSRC of granted floor participant;

b. shall add the MCPTT ID of the user to which the floor is granted to the list of currently granted talkers;

c. shall send a Floor Taken message to any non-controlling MCPTT functions involved and to floor participants controlled by the controlling MCPTT function that will listen to the RTP media from the multi-talker MCPTT client according to local policy. 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 associated functional alias in the Functional Alias field, if privacy is not requested;

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

iii. shall include the Floor Indicator field with the I-bit set to ‘1’ (Multi-talker);

iv. shall include the list of granted users in the multi-talker group in List of Granted Users field;

v. shall include the list of SSRCs of granted floor participants; and

vi) may include the list of functional aliases of the granted floor participants in the List of Functional Aliases field.

d. shall start the T1 (End of RTP media) timer for the particpant to which the floor is granted;

e. shall start timer T20 (Floor Granted) for the particpant to which the floor is granted, if the floor request was queued and initialise the counter C20 (Floor Granted) to 1;

f. shall stay in the state to ‘G: Floor Taken’ state.

6.3.4.4.8 Receive Floor request message from permitted floor participant (R: Floor Request)

Upon receiving a floor request message from the floor participant that has been granted permission to send media, the floor control arbitration logic in the floor control server:

1. shall send a Floor Granted message to the previously granted floor participant. The Floor Granted message:

a. shall include the value of timer T2 (Stop talking) running for this floor participant in the Duration field;

b. shall include the granted priority in the Floor priority field; and

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

2. shall remain in the ‘G: Floor Taken’ state.

6.3.4.4.9 Timer T20 (Floor Granted) expired

On expiry of timer T20 (Floor Granted), the floor control arbitration logic in the floor control server:

1. shall send a Floor Granted message to the granted floor participant if counter C20 (Floor Granted) has not reached its upper limit: The Floor Granted message:

a. shall include the value of timer T2 (Stop talking) in the Duration field;

b. shall include the granted priority in the Floor priority field; and

2. shall start timer T20 (Floor Granted) and increment counter C20 (Floor Granted) by 1 if counter C20 (Floor Granted) has not reached its upper limit; and

3. shall remain in the ‘G: Floor Taken’ state.

6.3.4.4.10 Timer T20 (Floor Granted) expired N times

When timer T20 (Floor Granted) expires and counter C20 (Floor Granted) reaches its upper limit, the floor control arbitration logic in the floor control server:

1. shall remain in the ‘G: Floor Taken’ state.

6.3.4.4.11 Permitted MCPTT client release (R: client release)

If the floor control server receives an indication from the floor control interface towards the MCPTT client that the MCPTT client has started to disconnect from the MCPTT call, the floor control arbitration logic in the floor control server:

1. if multi-talker floor control is not supported shall enter the ‘G: Floor Idle’ state as specified in the clause 6.3.4.3.2; and

2. if multi-talker floor control is supported,

a. shall send a Floor Release Multi Talker message. The Floor Release Multi Talker message:

i. shall include SSRC field set to the SSRC of the floor participant that has released the floor; and

ii. shall include the User ID set to the MCPTT ID of the floor participant releasing the floor; and

b. shall remove the participant which is disconnecting from the floor from the list of currently granted talkers, and:

i. if the list of currently granted talkers is empty, shall enter the ‘G: Floor Idle’ state as specified in the clause 6.3.4.3.2; and

ii. if the list of currently granted talkers is not empty shall stay in state the ‘G: Floor Taken’.

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

Upon receiving an implicit floor request due to an upgrade to an emergency group call or due to an upgrade to imminent peril call, the floor control arbitration logic in the floor control server:

1. shall stop timer T1 (End of RTP media), if running;

2. shall stop timer T20 (Floor Granted), if running;

3. shall set the Reject Cause field in the Floor Revoke message to #4 (Media Burst pre-empted);

4. shall enter the ‘G: pending Floor Revoke’ state as specified in the clause 6.3.4.5.2;

5. shall insert the floor participant into the active floor request queue to the position in front of all queued requests, if not inserted yet or update the position of the floor participant in the active floor request queue to the position in front of all other queued requests, if already inserted; and

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

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

6.3.4.4.13 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, the floor control arbitration logic in the floor control server:

1. if the active floor request queue is empty:

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 Queued Floor Requests Result Value set to ‘2’ (The floor request queue is already empty); and

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

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 ‘G: Floor Taken’ state; and

2. if the active floor request queue is not empty:

a. shall remove the queued floor requests of the users indicated in the List of Queued Userss field from the active floor request queue if the List of Queued Users field is present. Otherwise, shall remove all the queued floor requests from the active floor request queue;

b. shall send a Queued Floor Requests message, including a Queued Floor Requests Purpose field with the Queued Floor Requests Purpose value set to ‘2’ (Cancel Notification), to the associated floor participants whose floor requests have been removed from the queue and message is generated as described in the clause 8.2.15;

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

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 Queued Floor Requests Result Value set to:

A. ‘0’ (Successfully removed 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);

B. ‘3’ (The queued floor requests of all users specified in the List of Queued Users field in a message do not exist in the floor request queue);

C. ‘4’ (Unable to remove some of the queued floor requests of the users specified in the List of Queued Users field in a message);

D. ‘5’ (The queued floor requests of some of the users specified in the List of Queued Users field in a message do not exist in the floor request queue); or

E. ‘255’ (Unknown reason);

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

iv. if the List of Queued Users field was present in the received message, shall include into the List of Queued Users field the list of users whose queued floor requests were not possible to remove and their queued requests still exist in the active floor request queue; and

d. may send a Floor Queue Position Info message to the remaining users whose queued floor request position has changed in the active floor request queue, and if 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; and

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

e. shall remain in the ‘G: Floor Taken’ state.

6.3.4.4.14 Receive a unicast media stop request (R: Unicast Media Flow Control)

Upon receiving a Unicast Media Flow Control message from a floor participant with Media Flow Control Indicator is set to ‘0’, the floor control arbitration logic in the floor control server:

1. may de-allocate associated bearer resources by the MCPTT server;

2. shall notify the media distributor to stop sending media to the MCPTT client; and

3. shall remain in the ‘G: Floor Taken’ state.

6.3.4.4.15 Receive a unicast media resume request (R: Unicast Media Flow Control)

Upon receiving a Unicast Media Flow Control message from a floor participant with Media Flow Control Indicator is set to ‘1’, the floor control arbitration logic in the floor control server:

1. may allocate new bearer resources;

2. shall notify the media distributor to start sending media to the MCPTT client; and

3. shall remain in the ‘G: Floor Taken’ state.

6.3.4.5 State: ‘G: pending Floor Revoke’

6.3.4.5.1 General

The floor control arbitration logic in the floor control server uses this state after having sent a Floor Revoke message to the permitted floor participant.

Timer T3 (Stop talking grace) is running when the floor control arbitration logic in the floor control server is in this state. If the group is configured for audio cut-in floor control the value of timer T3 shall be considered to be zero.

In this state the MCPTT server forwards RTP media packets to the other floor participants in the MCPTT call.

6.3.4.5.2 Enter the ‘G: pending Floor Revoke’ state

When entering this state the floor control arbitration logic in the floor control server:

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

a. shall include the reason for sending the Floor Revoke message in the <Reject Cause> value in the Reject Cause field;

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

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

2. shall start timer T3 (Stop talking grace) for which a Floor Revoke message has been sent; and

3. shall set the general state to ‘G: pending Floor Revoke’.

6.3.4.5.3 Receive RTP media packets (R: RTP media)

Upon receiving an indication from the media distributor in the MCPTT server that RTP media packets are received from the permitted floor participant the floor control server:

1. shall restart timer T1 (End of RTP media);

NOTE 1: If the upper limit for timer T3 (Stop talking grace) is less than the upper limit of timer T1 (End of RTP media) then timer T1 (End of RTP media) will not expire.

2. shall instruct the media distributor to forward the RTP media packets to MCPTT clients according to local policy; and

NOTE 2: If dual floor control is ongoing as described in clause 6.3.6, the list of floor participants that receive the overriding, overridden, or both transmissions is based on configuration.

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

6.3.4.5.4 Receive Floor Release message (R: Floor Release)

Upon receiving a Floor Release message for which a Floor Revoke message has been sent, the floor control arbitration logic in the floor control server:

1. shall request the media distributor in the MCPTT server to stop forwarding RTP media packets;

2. shall stop timer T1 (End of RTP media) , if running;

3. shall stop timer T3 (Stop talking grace);

4. if multi-talker floor control is supported, shall remove the participant from the list of currently granted talkers;

5. if multi-talker floor control is supported, then:

a. shall send a Floor Release Multi Talker message. The Floor Release Multi Talker message:

i shall include SSRC field set to the SSRC of the floor participant that has released the floor; and

ii shall include the User ID set to the MCPTT ID of the floor participant releasing the floor; and

6. if the active floor request queue is not empty the floor control server shall enter the ‘G: Idle’ state as specified in the clause 6.3.4.3.2;

7. if the active floor request queue is empty and the list of currently granted talkers is empty the floor control server shall enter the ‘G: Idle’ state as specified in the clause 6.3.4.3.2; and

8. if the active floor request queue is empty and the list of currently granted talkers is not empty the floor control server shall enter the ‘G: Floor Taken’ state as specified in clause 6.3.4.4.2.

If configured to support multi-talker floor control and upon receiving a Floor Release message for which a Floor Revoke message has not been sent, the floor control arbitration logic in the floor control server:

1. shall request the media distributor in the MCPTT server to stop forwarding related RTP media packets;

2. shall stop timer T2 (Stop talking) for the participant that sent the Floor Release message, if running;

3. shall stop timer T20 (Granted re-send) for the participant that sent the Floor Release message, if running;

4. shall send a Floor Release Multi Talker message. The Floor Release Multi Talker message:

a shall include SSRC field set to the SSRC of the floor participant that has released the floor; and

b shall include the User ID set to the MCPTT ID of the floor participant releasing the floor;

5. shall remove the participant that has sent the Floor Release message from the list of currently granted talkers and:

a. if the list of currently granted talkers is empty, shall enter the ‘G: Floor Idle’ state as specified in the clause 6.3.4.3.2; and

b. if the list of currently granted talkers is not empty shall stay in state the ‘G: Floor Taken”.

6.3.4.5.5 Timer T3 (Stop talking grace) expired

On expiry of timer T3 (Stop talking grace) for which a Floor Revoke message has been sent, the floor control arbitration logic in the floor control server:

1. shall indicate to the interface towards the MCPTT client that the general state machine is now ‘G: Floor Idle’;

2. if multi-talker control is supported, shall remove the participant from the list of currently granted talkers;

3. shall send a Floor Release Multi Talker message. The Floor Release Multi Talker message:

a shall include SSRC field set to the SSRC of the floor participant for which T3 expired; and

b shall include the User ID set to the MCPTT ID for which T3 expired;

4. if the active floor request queue is not empty the floor control server shall enter the ‘G: Idle’ state as specified in the clause 6.3.4.3.2;

5. if the active floor request queue is empty and the list of currently granted talkers is empty the floor control server shall enter the ‘G: Idle’ state as specified in the clause 6.3.4.3.2; and

6. if the active floor request queue is empty and the list of currently granted talkers is not empty the floor control server shall enter the ‘G: Floor Taken’ state as specified in clause 6.3.4.4.2.

6.3.4.5.6 Timer T1 (End of RTP media) expired

On expiry of timer T1 (End of RTP media) assigned to the participant for which a Floor Revoke message has been sent, the floor control arbitration logic in the floor control server:

1. shall stop timer T3 (Stop talking grace);

2. if multi-talker feature is supported,

a shall remove the participant from the list of currently granted talkers;

b. shall send a Floor Release Multi Talker message. The Floor Release Multi Talker message:

i shall include SSRC field set to the SSRC of the floor participant for which timer T1 (End of RTP media) expired; and

ii shall include the User ID set to the MCPTT ID of the floor participant for which timer T1 (End of RTP media) expired; and

3. if the floor is now empty; shall enter the ‘G: Floor Idle’ state as specified in the clause 6.3.4.3.2.

On expiry of timer T1 (End of RTP media) assigned to a participant different than the participant for which a Floor Revoke message has been sent, the floor control arbitration logic in the floor control server:

1. shall request the media distributor in the MCPTT server to stop forwarding related RTP media packets;

2. shall stop timer T2 (Stop talking) for the participant for which timer T1 (End of RTP media) expired, if running;

3. shall stop timer T20 (Granted re-send) for the participant, if running;

4. shall send a Floor Release Multi Talker message. The Floor Release Multi Talker message:

a shall include SSRC field set to the SSRC of the floor participant for which T1 expired; and

b shall include the User ID set to the MCPTT ID for which T1 expired;

5. if multi-talker floor control is supported, shall remove the participant for which timer T1 (End of RTP media) expired from the list of currently granted talkers and shall stay in the ‘G: pending Floor Revoke’ state.

6.3.4.5.7 Receive Floor Queued Cancel Request message (R: Floor Queued Cancel Request)

(void)

6.3.4.5.8 Receive a unicast media stop request (R: Unicast Media Flow Control)

Upon receiving a Unicast Media Flow Control message from a floor participant with Media Flow Control Indicator is set to ‘0’, the floor control arbitration logic in the floor control server:

1. may de-allocate associated bearer resources by the MCPTT server;

2. shall notify the media distributor to stop sending media to the MCPTT client; and

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

6.3.4.5.9 Receive a unicast media resume request (R: Unicast Media Flow Control)

Upon receiving a Unicast Media Flow Control message from a floor participant with Media Flow Control Indicator is set to ‘1’, the floor control arbitration logic in the floor control server:

1. may allocate new bearer resources;

2. shall notify the media distributor to start sending media to the MCPTT client; and

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

6.3.4.6 In any state

6.3.4.6.1 General

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

6.3.4.6.2 Receive MCPTT call release – 1

This clause is used by the floor control arbitration logic in the floor control server when an MCPTT call is released.

Upon receiving an MCPTT call release step 1 request from the application and signalling plane the floor control arbitration logic in the floor control server:

1. shall request the media distributor in the MCPTT server to stop sending RTP media packets MCPTT clients; and

2. shall enter the ‘Releasing’ state.

6.3.4.6.3 Receive an instruction to merge group calls (R: Merge)

Upon receiving an instruction from the application and signalling plane to merge the ongoing group call with other group calls, the floor control server:

1. shall perform the actions in clause 6.5.2.3;

2. shall enter the ‘Start-stop’ state.

6.3.4.7 State: ‘Releasing’

6.3.4.7.1 General

The floor control arbitration logic in the floor control server uses this state while waiting for the application and signalling plane to finalize the disconnection of an MCPTT call.

6.3.4.7.2 Receive MCPTT call release – 2

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

1. shall release all resources reserved in the media plane including the instances used for the ‘Floor control server state transition diagram for general floor control operation’, and ‘Floor control server state transition diagram for basic floor control operation towards the floor participant’ state machines and any running timers associated with the state machines; and

2. shall enter the ‘Start-stop’ state.

6.3.4.8 State: ‘G: Floor Initialising’

6.3.4.8.1 General

The floor control arbitration logic in the floor control server uses this state while waiting for all invited constituent MCPTT groups to reply with a final SIP response.

There are no timers running in this state. The floor control arbitration logic is relying on SIP timers in the signalling and application plane.

6.3.4.8.2 Enter the ‘G: Initialising’ state

When entering this state the floor control arbitration logic:

1. shall set the general state to the ‘G: Initialising’ state.

6.3.4.8.3 Receiving a floor request from a constituent MCPTT group (R: mcptt-floor-request)

Upon receiving an indication from the application and signalling plane that a floor request is received from one of the invited constituent MCPTT groups in an application/vnd.3gpp.mcptt-floor-request+xml MIME body, the floor control arbitration logic:

1. shall cache the application/vnd.3gpp.mcptt-floor-request+xml MIME body; and

2. remain in the ‘G: Initialising’ state.

6.3.4.8.4 All final SIP responses received (R: final SIP responses)

Upon receiving an indication from the application and signalling plane that all invited constituent MCPTT groups have sent a final SIP response, the floor control arbitration logic:

1. if at least one application/vnd.3gpp.mcptt-floor-request+xml MIME body exists with the <floor-type> element set to "general":

a. shall select the floor participant with the highest priority as described in clause 4.1.1.4:

i. among the cached application/vnd.3gpp.mcptt-floor-request+xml MIME bodies with the <floor-type> element set to "general"; and

ii. the floor participant initialising the temporary group session as described in clause 4.1.1.4, if the floor participant initialising the temporary group session negotiated implicit floor request as specified in clause 14;

b. shall send a Floor Revoke message to all floor participants in the cached application/vnd.3gpp.mcptt-floor-request+xml MIME body with the <floor-type> element set to "general" that are not granted the permission to send media. The Floor Revoke message:

i. shall include the <Reject Cause> value set to ‘4’ (Media Burst pre-empted) in the Reject Cause field;

ii. shall include information taken from the <track-info> element in the cached application/vnd.3gpp.mcptt-floor-request+xml MIME body with the <floor-type> element set to "general" in the 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

c. if the floor participant selected to be granted the floor is one of invited constituent MCPTT groups:

i. shall convert the <track-info> element to a format of a Track Info field and cache the Track Info field associated with the floor control server state transition diagram for ‘general floor control operation’; and

ii. shall enter the ‘G: Taken’ state as specified in the clause 6.3.4.4.2 using the selected floor participant as the requesting floor participant;

2. if at least one application/vnd.3gpp.mcptt-floor-request+xml MIME body exists with the <floor-type> element set to "dual":

a. shall select the floor participant with the highest priority as described in clause 4.1.1.4 among the cached application/vnd.3gpp.mcptt-floor-request+xml MIME bodies with the <floor-type> element set to "dual"; and

b. shall send a Floor Revoke message to all floor participants in the cached application/vnd.3gpp.mcptt-floor-request+xml MIME body with the <floor-type> element set to "dual" that are not granted the permission to send media. The Floor Revoke message:

i. shall include the <Reject Cause> value set to ‘4’ (Media Burst pre-empted) in the Reject Cause field;

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

iv. shall convert the <track-info> element to a format of a Track Info field and cache the Track Info field associated with floor control server state transition diagram for ‘dual floor control operation’; and

v. shall enter the ‘D: Floor Taken’ state as specified in the clause 6.3.6.3.2 using the selected floor participant as the requesting floor participant; and

3. if no cached application/vnd.3gpp.mcptt-floor-request+xml MIME body with the <floor-type> element set to either "general" or "dual" exists:

a. if an implicit floor request is negotiated as described in clause 14 when the temporary group session was established, shall enter the ‘G: Taken’ state as specified in the clause 6.3.4.4.2; and

b. if an implicit floor request is not negotiated as described in clause 14 when the temporary group session was established, shall enter the ‘G: Idle’ state as specified in the clause 6.3.4.3.2.