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

29.3803GPPMission Critical Push To Talk (MCPTT) media plane control interworking with Land Mobile Radio (LMR) systemsRelease 17Stage 3TS

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 in the IWF shall behave according to the state diagram in Figure 6.3.4.1-1 and state transitions specified in this clause. The present clause is applicable for floor control of groups homed in the IWF.

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 IWF floor control server:

1. shall discard the floor control message;

2. shall request the media distributor in the IWF 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 29.379 [26] and

1. if a confirmed indication is required and at least one invited media endpoint 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: An 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:

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, 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 IWF floor control server is in this state when no floor participant 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 IWF 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 media endpoint negotiated support of queueing floor requests as described in clause 14, and the IWF does not require queuing for its IWF floor participants, and the state machine specified in clause 6.3.6 does not exist, the floor control arbitration logic in the IWF 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 IWF floor control server:

a. shall send Floor Idle message to all MCPTT 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;

NOTE 1: How the IWF informs IWF media endpoints of the idle floor is out of scope of the present document.

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 IWF 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 IWF floor control server:

2. shall send Floor Idle message to all MCPTT 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;

NOTE 2: How the IWF informs IWF media endpoints of the idle floor is out of scope of the present document.

3. shall send Floor Taken message to MCPTT 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; and

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;

NOTE 3: How the IWF informs IWF media endpoints of the taken floor is out of scope of the present document.

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 an MCPTT floor participant that is permitted to make a floor request) the floor control arbitration logic in the IWF floor control server:

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

a. if there is only one media endpoint 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 IWF 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 media endpoint 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 MCPTT 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 IWF floor control server:

a. shall stop timer T4 (Inactivity);

b. shall stop timer T7 (Floor Idle);

c. if the floor is being granted to an MCPTT floor participant, and if a Track Info field is included in the Floor Request message, shall store the received Track Info field, and

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

6.3.4.3.3a IWF floor participant grant (I: IWF Floor Participant Grant)

To grant floor to an IWF floor participant, the floor control arbitration logic in the IWF floor control server:

1. shall stop timer T4 (Inactivity);

2. shall stop timer T7 (Floor Idle);

3. if the floor is being granted to an IWF floor participant,

a. shall generate and store an SSRC; otherwise

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

4. 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 IWF 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 MCPTT 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

NOTE: How the IWF informs IWF media endpoints of the idle floor is out of scope of the present document.

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 IWF 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 IWF floor control server:

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

2. if the floor request is rejected the IWF 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 IWF floor control server:

a. shall stop the timer T4 (Inactivity);

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

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

6.3.4.4 State: ‘G: Floor Taken’

6.3.4.4.1 General

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

Timer T1 (End of RTP media) is running when the floor control server is in this state.

Timer T2 (End talking) can be running when the IWF floor control server is in this state.

Timer T20 (Floor Granted) is running to guarantee reliable delivery of the Floor Granted message, if the granted floor request was queued.

6.3.4.4.2 Enter the ‘G: Floor Taken’ state

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

1. shall send a Floor Granted message to the MCPTT 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; and

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;

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 MCPTT floor participants. The Floor Taken message:

a. shall include the granted user’s MCPTT ID in the Granted Party’s Identity 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;

NOTE: How the IWF informs IWF media endpoints of the taken floor is out of scope of the present document.

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

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

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 IWF 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 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 media endpoints; and

4. shall enter the ‘G: Floor Idle’ state as specified in the clause 6.3.4.3.2;

6.3.4.4.4 Timer T2 (Stop talking) expired

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

1. shall stop timer T1 (End of RTP media) for the MCPTT 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 that RTP media packets are received from the MCPTT media endpoint, the floor control arbitration logic in the IWF floor control server:

1. shall start timer T2 (Stop talking) for the MCPTT media endpoint 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 forward the RTP media packets to media endpoints 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 or upon determining that a user homed in the IWF has released the floor, the floor control arbitration logic in the IWF floor control server:

1. shall request the media distributor 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; and

4. shall enter the ‘G: Floor Idle’ state as specified in the clause 6.3.4.3.2;

6.3.4.4.6a IWF floor participant release (I: IWF floor participant release)

Upon deciding to release the floor, the floor control arbitration logic in the IWF floor control server:

1. shall request the media distributor to stop forwarding RTP media packets; and

2. shall enter the ‘G: Floor Idle’ state as specified in the clause 6.3.4.3.2.

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

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

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, the floor control arbitration logic in the IWF 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;

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 MCPTT 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 MCPTT 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)

The multi-talker feature is not supported in this version of the present document.

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

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

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

a. shall include the value of timer T2 (Stop talking) running for this MCPTT 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; and2. 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 IWF 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 IWF floor control server:

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

6.3.4.4.11 MCPTT media endpoint release (R: client release)

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

1. shall enter the ‘G: Floor Idle’ state as specified in the clause 6.3.4.3.2.

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 IWF 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 MCPTT 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 MCPTT 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.5 State: ‘G: pending Floor Revoke’

6.3.4.5.1 General

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

Timer T3 (Stop talking grace) is running when the floor control arbitration logic in the IWF floor control server is in this state.

In this state, the IWF forwards RTP media packets to the MCPTT media endpoints 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 IWF floor control server:

1. shall send the Floor Revoke message to the MCPTT 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; and

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 that RTP media packets are received from the permitted floor participant the IWF 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 media endpoints 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 IWF floor control server:

1. shall request the media distributor 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 the active floor request queue is not empty the IWF floor control server shall enter the ‘G: Idle’ state as specified in the clause 6.3.4.3.2; and

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

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 IWF floor control server:

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

2. shall enter the ‘G: Idle’ state as specified in the clause 6.3.4.3.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 MCPTT floor participant for which a Floor Revoke message has been sent, the floor control arbitration logic in the IWF floor control server:

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

2. 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 MCPTT floor participant for which a Floor Revoke message has been sent, the floor control arbitration logic in the IWF floor control server:

1. shall stop forwarding related RTP media packets;

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

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

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 IWF floor control server when an MCPTT call is released.

Upon receiving an MCPTT call release step 1 request from the application and signalling plane or upon determining that a user homed in the IWF has released the call, the floor control arbitration logic in the IWF floor control server:

1. shall request the media distributor to stop sending RTP media packets to MCPTT media endpoints; 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 IWF floor control server:

1. shall perform the actions in clause 6.5.2.3; and

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 IWF 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 IWF 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 IWF 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 MCPTT 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

NOTE 1: How the IWF informs IWF media endpoints of the floor revoke is out of scope of the present document.

c. if the floor participant selected to be granted the floor is in 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

NOTE 2: How the IWF informs IWF media endpoints of the floor revoke is out of scope of the present document.

3. if no cached application/vnd.3gpp.mcptt-floor-request+xml MIME with the <floor-type> element set to "general" body 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.