6.5 IWF performing the non-controlling role of an MCPTT group

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.5.4 Floor control server interface procedures

6.5.4.1 General

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

The following subclauses specify what the floor control server interface shall do when receiving a floor control message sent by the controlling MCPTT function or received at the floor participant interface or initiated internally for an IWF media endpoint and how the floor control server controls the media distribution function in the non-controlling MCPTT function.

Editor’s Note: Existing clauses 6.3.5 and 6.3.6 should be evaluated for updates now that we support regroup. Search for "non-controlling" in TS 24.380 and TS 29.380.

6.5.4.2 Receiving a Floor Request message

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

1. shall

a. forward the Floor Request message to the controlling MCPTT function if the controlling function is in the MCPTT system; or

b. forward to the floor control server in the IWF if the controlling function is in the IWF.

The Floor Request message:

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

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

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

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

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

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

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

6.5.4.2A IWF sends a Floor Request message

Upon deciding to request permission to send media when the controlling function is in the MCPTT system, the IWF:

1. shall send the Floor Request message toward the MCPTT floor control server in the MCPTT system. The Floor Request message:

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

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

6.5.4.3 Receive Floor Release message

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

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

1. shall forward a Floor Release message to the controlling MCPTT function if the controlling function is in the MCPTT system or to the floor control server state transition diagram for basic floor control operation towards the floor participant in the IWF if the controlling function is in the IWF. The Floor Release message:

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

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

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

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

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

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

6.5.4.3A IWF sends a Floor Release message

Upon deciding to release permission to send media when the controlling function is in the MCPTT system, the IWF floor participant:

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

a. if the session is a broadcast call and if the session was established as a normal call, shall include the Floor Indicator with the A-bit set to ‘1’ (Normal call);

2. may include the first bit in the subtype of the Floor Release message set to ‘1’ (Acknowledgment is required) as described in clause 8.3.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. if the Floor Granted message included the G-bit set to ‘1’ (Dual floor), shall include the Floor Indicator with the G-bit set to ‘1’ (Dual floor).

6.5.4.4 Receive Floor Queue Position Request message

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

1. shall forward the Floor Queue Position Request message to the controlling MCPTT function if the controlling function is in the MCPTT system or to the floor control server state transition diagram for basic floor control operation towards the floor participant in the IWF if the controlling function is in the IWF. The Floor Queue Position Request message:

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

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

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

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

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

6.5.4.4A IWF sends Floor Queue Position Request message

Upon deciding to request the queue position, when the controlling function is in the MCPTT system, the IWF:

1. shall send the Floor Ack message towards the floor control server in the MCPTT system. The Floor Ack message:

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

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

c. shall include a Track Info field as follows:

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

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

6.5.4.5 Receive Floor Ack message

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

1. shall send the Floor Ack message towards the controlling MCPTT function if the controlling function is in the MCPTT system or to the floor control server state transition diagram for basic floor control operation towards the floor participant in the IWF if the controlling function is in the IWF. The Floor Ack message:

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

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

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

6.5.4.5A IWF sends Floor Ack message

Upon deciding to send a Floor Ack message, when the controlling function is in the MCPTT system, the IWF:

1. shall send the Floor Ack message towards the floor control server in the MCPTT system. The Floor Ack message shall include a Track Info field as follows:

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

6.5.4.6 Receive Floor Granted message

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

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

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

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

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

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

2. if:

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

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

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

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

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

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

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

d. The Floor Taken message:

i. shall include the granted user’s MCPTT ID in the Granted Party’s Identity field if privacy is not requested by the granted floor participant when the floor participant was invited to the session;

NOTE 2: The privacy request was stored for each invited floor participant when the floor participant accepted the invitation as specified in subclause 6.5.2.

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

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

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

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

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

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

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

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

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

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

6.5.4.6A IWF grants floor

Upon deciding to grant floor, where the controlling function is in the IWF, the IWF floor control server interface:

Editor’s Note: Need to create a grant message for internally generated requests, need to also consider floor requests coming from IWF CF that originated in MCPTT, how do those make it here? Does IWF CF call this nCF?

Editor’s note: Need to add procedures for clauses 6.5.4.7 thru 6.5.4.16.

6.5.4.17 Receive Floor Release Multi Talker message

Upon receiving a Floor Release Multi Talker message sent from the controlling MCPTT function, the IWF floor control server interface shall ignore the Floor Release Multi Talker message.

NOTE: The multi-taker feature is not supported in the present document.

6.5.5 Floor participant interface procedures

6.5.5.1 General

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

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

Figure 6.5.5.1-1: The ‘floor participant interface toward the MCPTT client state transition’ state diagram

The floor participant interface toward the MCPTT client shall keep one instance of the ‘floor participant interface toward the MCPTT client state transition’ state machine per MCPTT client in a session. The interface and procedures toward IWF media endpoints are out of scope of the present document.

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

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

1. shall discard the floor control message;

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

3. shall remain in the current state.

State details are explained in the following clauses.

6.5.5.2 State: ‘Start-Stop’

6.5.5.2.1 General

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

6.5.5.2.2 Participant invited to session

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

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

6.5.5.3 State: ‘P: has no permission’

6.5.5.3.1 General

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

6.5.5.3.2 Receive Floor Idle message (R: Floor Idle)

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

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

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

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

6.5.5.3.3 Receive Floor Taken message (R: Floor Taken)

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

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

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

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

6.5.5.3.4 Receive Floor Request message (R: Floor Request)

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

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

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

6.5.5.3.5 Receive Floor Granted message (R: Floor Granted)

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

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

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

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

6.5.5.3.6 Receive Floor Deny message (R: Floor Deny)

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

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

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

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

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

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

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

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

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

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

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

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

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

6.5.5.3.9 Receive RTP media packets (R: RTP media)

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

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

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

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

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

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

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

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

6.5.5.3.10 Receive Floor Release message (R: Floor Release)

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

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

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

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

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

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

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

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

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

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

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

6.5.5.3.11 Receive split instruction (R: Split)

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

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

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

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

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

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

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

6.5.5.3.12 Receive Floor Release Multi Talker message (R: Floor Release Multi-talker)

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

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

NOTE: The multi-talker feature is not supported in the present document.

6.5.5.4 State: ‘P: has permission’

6.5.5.4.1 General

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

6.5.5.4.2 Receive RTP media packets

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

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

6.5.5.4.3 Receive Floor Release message (R: Floor Release)

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

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

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

6.5.5.4.4 Receive Floor Ack message (R: Floor Ack)

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

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

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

6.5.5.4.5 Receive Floor Idle message (R: Floor Idle)

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

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

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

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

6.5.5.4.6 Receive Floor Taken message (R: Floor Taken)

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

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

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

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

6.5.5.4.7 Receive Floor Revoke message (R: Floor Revoke)

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

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

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

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

6.5.5.4.8 Receive split instruction (R: Split)

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

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

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

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

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

6.5.5.4.9 Receive Floor Release Multi Talker message (R: Floor Release Multi-talker)

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

NOTE: The multi-talker feature is not supported in the present document.

6.5.5.5 In any state

6.5.5.5.1 General

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

6.5.5.5.2 Receive Floor Ack message (R: Floor Ack)

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

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

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

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

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

2. shall remain in the current state.

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

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

2. shall remain in the current state.

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

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

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

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

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

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

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

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

6.5.5.6 State: ‘P: Releasing’

6.5.5.6.1 General

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

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

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

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

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