7 Off-network floor control

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

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

7.1 General

A floor control session may be initiated only if there is a successfully established off-network call.

In off-network, floor control is performed using floor control messages among the MCPTT clients without a centralized floor arbitrator. When off-network, if a floor control session is active, the floor arbitrator and the floor participant are co-located in the MCPTT client (see 3GPP TS 23.379 [5]). During a floor control session the MCPTT client currently speaking serves as the temporary floor arbitrator. All other MCPTT clients in the call play the role of floor participant. When the floor arbitrator grants the floor to another MCPTT client, that new MCPTT client, when starts to send media, becomes the new floor arbitrator and the former (the MCPTT client which granted the floor) becomes a floor participant.

The procedures in clause 7.2 are from the perspective of a single MCPTT client. No special message other than floor control messages and media is used for coordinating the floor arbitrator and floor participant status of the separate MCPTT clients participating in the off-network call.

The floor control messages are always sent to all the participants of the call. Therefore they can be monitored by any MCPTT client listening to the call.

In a floor control session queueing of floor requests may be supported.

It is assumed that the MCPTT user presses the PTT button for requesting talk permission and keeps it pressed until the request is resolved. If queueing of floor requests is not supported, this request is either granted or rejected or no answer is received. If the request is granted the user is notified with talk permission tone (or equivalent) and the user continues to press the PTT until the user finishes the talk burst. If the request is rejected or no answer is received the user is notified and releases the PTT button.

If queueing of floor requests is supported, the MCPTT user shall be notified when a floor request is queued and the MCPTT user shall release the PTT button. When, after queueing, the floor is granted to this user the MCPTT user shall be informed that the queued request is now granted. Then the MCPTT user should press the PTT button within a short duration. Otherwise, the grant is taken from this MCPTT user. An MCPTT user can appear in a queue only once. The floor request queue is transferred from the former to the new floor arbitrator.

After the initiation of a floor control session the MCPTT client behaves according to the state machine presented in clause 7.2.3. The state machine is designed such that in normal cases only one of the MCPTT clients, which participates in the call, acts as floor arbitrator and all others act as floor participants. However, there may be situations such that more than one MCPTT client are at an internal state causing them to act as floor arbitrator. A short sequence of floor control messages and RTP media packets are initiated to resolve these situations.

7.2 Floor participant procedures

7.2.1 Floor participant procedures at MCPTT session initialization

This clause applies when no active floor control session exists.

Before a floor control entity is initiated a state machine with a single state, named as ‘Start-stop’ state, shall exist. At ‘Start-stop’ state, when the MCPTT client receives a request of the MCPTT call control entity to initiate the floor control as originating client, then the MCPTT client shall initiate a floor control entity and the floor control entity shall enter into the ‘O: has permission’ state. Otherwise, if MCPTT client receives a request of the MCPTT call control entity to initiate the floor control as terminating client, then the MCPTT client shall initiate a floor control entity and the floor control entity for an MCPTT group call shall enter into the ‘O: silence’ state or for both MCPTT private call and MCPTT broadcast group call shall enter the ‘O: has no permission’ state.

Once the session is initiated, the initial floor control messages are sent according to the state machine presented in clause 7.2.3. Normally, once the session is started the originating MCPTT client has the floor implicitly. For an on-going off-network group call, if an MCPTT client joins later, then it starts the floor control session and takes the role of floor participant and enters ‘O: silence’ state.

7.2.1.2 Determine off-network floor priority

Upon receiving a Floor Request message, to determine the floor priority of the Floor Request message, the floor arbitrator:

1. shall check the presence of Floor Priority field in the received Floor Request message. If present, the floor arbitrator:

a. shall determine the floor priority of the Floor Request message by choosing the lowest value from the following inputs:

i. the value of the Floor Priority field in the received Floor Request message;

ii. the value of the "/<x>/<x>/Common/MCPTTGroupMemberList/<x>/UserPriority" leaf node of the sender of the Floor Request message, present in group configuration as specified in 3GPP TS 24.483 [4]; and

iii. the value of the "/<x>/OffNetwork/NumLevelHierarchy" leaf node present in service configuration as specified in 3GPP TS 24.483 [4]; and

2. if the Floor Priority field is not present in the Floor Request message, the floor arbitrator:

a. shall use the minimum value allowed for the Floor Priority as floor priority of the Floor Request message.

Once the floor priority of the Floor Request message is determined, to determine the effective priority of the Floor Request message, the floor arbitrator:

1. shall check the type of call indicated by the Floor Indicator field of the received Floor Request message and:

a. if the type of call indicated by the Floor Indicator field is Normal call:

i. if the current type of the call is normal, shall continue to check the next input parameter from step 2; and

ii if the current type of the call is emergency or imminent-peril and:

A. if the value of "/<x>/<x>/OffNetwork/QueueUsage" leaf node present in the group configuration as specified in 3GPP TS 24.483 [4] is set to "true", shall queue the floor request;

B. if the value of "/<x>/<x>/OffNetwork/QueueUsage" leaf node present in the group configuration as specified in 3GPP TS 24.483 [4] is set to "false", shall deny the floor request; and

C. shall skip step 2;

b. if the type of call indicated by the Floor Indicator field is Imminent peril call and:

i. if the current type of the call is normal, shall pre-empt the current talker, grant the floor request and skip step 2;

ii. if the current type of the call is imminent-peril, shall continue to check the next input parameter from step 2; and

iii. if the current type of the call is emergency and:

A. if the value of "/<x>/<x>/OffNetwork/QueueUsage" leaf node present in the group configuration as specified in 3GPP TS 24.483 [4] is set to "true", shall queue the floor request;

B. if the value of "/<x>/<x>/OffNetwork/QueueUsage" leaf node present in the group configuration as specified in 3GPP TS 24.483 [4] is set to "false", shall deny the floor request; and

C. shall skip step 2; and

c. if the type of the call indicated by the Floor Indicator field is Emergency call and:

i. if the current type of the call is normal or imminent-peril, shall pre-empt the current talker and grant the floor request; and

ii. if the current type of the call is emergency and:

A. if the value of "/<x>/<x>/OffNetwork/QueueUsage" leaf node present in the group configuration as specified in 3GPP TS 24.483 [4] is set to "true", shall queue the floor request;

B. if the value of "/<x>/<x>/OffNetwork/QueueUsage" leaf node present in the group configuration as specified in 3GPP TS 24.483 [4] is set to "false", shall deny the floor request; and

iii shall skip step 2; and

2. shall compare the determined floor priority of the received Floor Request message to the effective priority of the current talker (determined at the time of floor grant to the current talker) and:

a. if the effective priority of the current talker is equal to or higher than the determined floor priority of the Floor Request message and:

i. if the value of "/<x>/<x>/OffNetwork/QueueUsage" leaf node present in the group configuration as specified in 3GPP TS 24.483 [4] is set to "true", shall queue the floor request; and

ii. if the value of "/<x>/<x>/OffNetwork/QueueUsage" leaf node present in the group configuration as specified in 3GPP TS 24.483 [4] is set to "false", shall deny the floor request; and

b. if the determined floor priority of the Floor Request message is higher than that of the current talker, shall pre-empt the current talker and shall grant the floor request.

7.2.2 Floor participant procedures at MCPTT call release

This clause applies when an active floor control session exists.

When the off-network call is released the floor control session is terminated. The off-network floor control session can also be terminated when no media transmission or reception takes place during floor control session hold time, T230 (Inactivity). The termination of the floor control session as a result of the expiry of timer T230 (Inactivity) may terminate the call session.

7.2.3 Floor participant state diagram – basic operation

7.2.3.1 General

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

The received floor messages and the RTP media packets are inputs to the state machine according to their arrival order. They are not ignored unless otherwise stated.

The MCPTT client also provides input to the state machine as request to talk (press PTT button) or as end of talk (release PTT button).

Figure 7.2.3.1-1 show the ‘Floor participant state diagram – basic operation’.

Figure 7.2.3.1-1: ‘Floor participant state diagram – basic operation’

State details are explained in the following clauses.

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

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

7.2.3.2 State: ‘Start-stop’

7.2.3.2.1 General

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

7.2.3.2.2 MCPTT call established – originating MCPTT user

When an MCPTT call is established with session announcement including an explicit floor request, the originating floor participant:

1. shall create an instance of a floor participant state transition diagram for basic operation state machine;

2. shall send Floor Granted message towards other floor participants. The Floor Granted message:

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

b. shall include the MCPTT user’s own MCPTT ID in the User ID field; and

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

3. shall set the stored SSRC of the current florr arbitrator to its own SSRC; and

4. shall enter ‘O: has permission’ state.

7.2.3.2.3 MCPTT group call established – terminating MCPTT user

When an MCPTT call is established the terminating floor participant:

1. shall create an instance of a floor participant state transition diagram for basic operation state machine;

2. shall start timer T230 (Inactivity); and

3. shall enter ‘O: silence’ state.

7.2.3.2.4 MCPTT private call established – terminating MCPTT user

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

1. shall create an instance of a floor participant state transition diagram for basic operation state machine;

2. shall start timer T203(End of RTP media); and

3. shall enter ‘O: has no permission’ state.

7.2.3.2.5 Send Floor Request message (PTT button pressed)

If the floor participant receives an indication from the MCPTT user to send media, the floor participant:

1. shall create an instance of a floor participant state transition diagram for basic operation state machine;

2. shall send the Floor Request message to other floor participants. The Floor Request message:

a. if a different priority than the normal priority is required, shall include the Floor Priority field with the requested priority in the <Floor Priority> value;

b. shall include the MCPTT ID of the MCPTT user in the <User ID> value of the User ID field; and

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

3. shall initialize the counter C201 (Floor request) with value set to 1;

4. shall start the timer T201 (Floor request); and

5. shall enter ‘O: pending request’ state.

7.2.3.2.6 Receive Floor Taken message (R: Floor Taken)

When a Floor Taken message is received, the floor participant:

1. shall create an instance of a floor participant state transition diagram for basic operation state machine;

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

3. shall set the stored SSRC of the current floor arbitrator to the SSRC of granted floor participant field in the Floor Taken message;

4. shall start timer T203 (End of RTP media); and

5. shall enter ‘O: has no permission’ state.

7.2.3.2.7 Receive Floor Granted message (R: Floor Granted to other)

When a Floor Granted message is received and if the User ID in the Floor Granted message does not match its own User ID, the floor participant:

1. shall create an instance of a floor participant state transition diagram for basic operation state machine;

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

3. shall set the stored SSRC of the candidate floor arbitrator to the SSRC of user to whom the floor was granted in the Floor Granted message;

4. shall start timer T203 (End of RTP media); and

5. shall enter ‘O: has no permission’ state.

7.2.3.2.8 Receive RTP media (R: RTP media)

Upon receiving RTP media packets, the floor participant:

1. shall create an instance of a floor participant state transition diagram for basic operation state machine;

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

3. shall set the stored SSRC of the current floor arbitrator to the SSRC of RTP media packet;

4. shall restart timer T203 (End of RTP media);

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

6. shall enter ‘O: has no permission’ state.

7.2.3.2.9 MCPTT broadcast group call established – terminating MCPTT user

When an MCPTT broadcast group call is established the terminating floor participant:

1. shall create an instance of a floor participant state transition diagram for basic operation state machine;

2. shall start timer T203 (End of RTP media); and

3. shall enter ‘O: has no permission’ state.

NOTE: In MCPTT broadcast group call, only originating MCPTT user is allowed to request floor and transmit media. A Floor Request message is locally denied to terminating MCPTT user, if requested.

7.2.3.3 State: ‘O: silence’

7.2.3.3.1 General

When in this state the MCPTT client for the session is unaware of any MCPTT client acting as a floor arbitrator, has not itself initiated a floor control request and is not currently receiving RTP media packets.

Timer T230 (Inactivity) is running in this state.

7.2.3.3.2 Send Floor Request message (PTT button pressed)

If the floor participant receives an indication from the MCPTT user to send media, the floor participant:

1. shall send the Floor Request message to other floor participants. The Floor Request message:

a. if a priority different than the default floor priority is required, shall include the Floor Priority field with the requested priority in the <Floor Priority> element;

b. shall include the MCPTT ID of the MCPTT user in the <User ID> value of the User ID field; and

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

2. shall initialize the counter C201 (Floor request) with value set to 1;

3. shall stop timer T230 (Inactivity);

4. shall start timer T201 (Floor Request); and

5. shall enter ‘O: pending request’ state.

7.2.3.3.3 Receive RTP media (R: RTP media)

Upon receiving RTP media packets and if there is no stored SSRC of the current floor arbitrator, the floor participant:

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

2. shall stop timer T230 (Inactivity);

3. shall set the stored SSRC of the current floor arbitrator to the SSRC of RTP media packet;

4. shall restart (or start, if not running already) timer T203 (End of RTP media);

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

6. shall enter ‘O: has no permission’ state.

Otherwise, if SSRC of floor participant sending the media matches the stored SSRC of current floor arbitrator, the floor participant:

1. shall restart (or start, if not running already) timer T203 (End of RTP media);

2. shall stop timer T230 (Inactivity);

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

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

7.2.3.3.4 Receive Floor Granted message (R: Floor Granted to other)

When a Floor Granted message is received and if the User ID in the Floor Granted message does not match its own User ID, the floor participant:

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

2. if the Floor Indicator field is included and the B-bit is set to ‘1’ (Broadcast group call), shall provide a notification to the user indicating that this is a broadcast group call;

3. shall set the stored SSRC of the candidate floor arbitrator to the SSRC of user to whom the floor was granted in the Floor Granted message;

4. shall stop timer T230 (Inactivity);

5. shall start timer T203 (End of RTP media); and

6. shall enter ‘O: has no permission’ state.

7.2.3.3.5 Receive Floor Request message (R: Floor Request)

The transition is used in private call only. When a Floor Request message is received, the floor participant:

1. shall send a Floor Granted message toward the other floor participant. The Floor Granted message:

a. shall include the MCPTT ID of the Floor Request message received in User ID value of the User ID field;

b. shall include the SSRC of the Floor Request message received in the SSRC of floor control server field;

c. shall include the max duration as configured in the MCPTT client in the OffNetwork/MaxDuration parameter in the <Duration> value of the Duration field; and

d. shall include the priority of the Floor Request message received in the <Floor Priority> value of the Floor Priority field;

2. shall stop timer T230 (Inactivity);

3. shall start timer T205 (Floor Granted ); and

4. shall enter ‘O: pending granted’ state.

7.2.3.3.6 Receive Floor Taken message (R: Floor Taken)

When a Floor Taken message is received, the floor participant:

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

2. shall set the stored SSRC of the current floor arbitrator to the SSRC of granted floor participant field in the Floor Taken message;

3. shall stop timer T230 (Inactivity);

4. shall start timer T203 (End of RTP media); and

5. shall enter ‘O: has no permission’ state.

7.2.3.3.7 Timer T230 (Inactivity) expired

Upon expiry of timer T230 (Inactivity), the floor participant:

1. shall indicate to the call control that timer T230 (inactivity) has expired;

2. shall terminate the instance of floor participant state transition diagram; and

3. shall enter ‘Start-stop’ state.

7.2.3.4 State: ‘O: has no permission’

7.2.3.4.1 General

In this state the MCPTT client does not have permission to send media.

7.2.3.4.2 Sending Floor Request message (PTT button pressed)

If the floor participant receives an indication from the MCPTT user that the MCPTT user wants to send media, the floor participant:

1. shall send the Floor Request message to other clients. The Floor Request message:

a. if a priority different than the default floor priority is required, shall include the Floor Priority field with the requested priority in the <Floor Priority> element;

b. shall include the MCPTT ID of the MCPTT user in the User ID field; and

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

2. shall initialize the counter C201 (Floor request) with value set to 1;

3. shall start timer T201 (Floor Request); and

4. shall enter ‘O: pending request’ state.

7.2.3.4.3 Receive Floor Release message (R: Floor Release)

When a Floor Release message is received and if the SSRC in the Floor Release message matches with the stored SSRC of the current arbitrator or with the stored SSRC of the candidate arbitrator, the floor participant:

1. may provide floor idle notification to the MCPTT user.

2. shall request the MCPTT client to stop rendering received RTP media packets;

3. shall stop timer T203 (End of RTP media);

4. shall start timer T230 (Inactivity);

5. shall clear the stored SSRC of the candidate arbitrator;

6. shall clear the stored SSRC of the current floor arbitrator; and

7. shall enter ‘O: silence’ state;

7.2.3.4.4 Timer T203 (End of RTP media) expired

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

1. may provide floor idle notification to the MCPTT user.

2. shall request the MCPTT client to stop rendering received RTP media packets;

3. shall start timer T230 (Inactivity);

4. shall clear the stored SSRC of the current floor arbitrator; and

5. shall enter ‘O: silence’ state;

7.2.3.4.5 Receive Floor Granted message (R: Floor Granted to other)

When a Floor Granted message is received and if the <User ID> value in the User ID field does not match its own MCPTT ID and SSRC of floor participant sending the Floor Granted message matches the stored SSRC of current floor arbitrator, the floor participant:

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

2. shall restart timer T203 (End of RTP media);

3. shall set the stored SSRC of the candidate floor arbitrator to the SSRC of user to whom the floor was granted in the Floor Granted message;

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

5. if the Floor Indicator field is included with the B-bit set to ‘1’ (Broadcast group call), shall provide a notification to the user indicating that this is a broadcast group call; and

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

7.2.3.4.6 Receive RTP media (R: RTP media)

Upon receiving RTP media packets and if there is no stored SSRC of the current floor arbitrator, the floor participant:

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

2. shall set the stored SSRC of the current floor arbitrator to the SSRC of RTP media packet;

3. shall clear the stored SSRC of the candidate arbitrator, if any;

4. shall restart timer T203 (End of RTP media); and

5. shall remain in ‘O: has no permission’ state.

Otherwise, if SSRC of floor participant sending the media matches the stored SSRC of current arbitrator, the floor participant:

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

2. shall clear the stored SSRC of the candidate arbitrator, if any;

3. shall restart timer T203 (End of RTP media); and

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

Otherwise, if SSRC of floor participant sending the media packet matches with the stored SSRC of candidate arbitrator, the floor participant:

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

2. shall set the stored SSRC of the current arbitrator to the SSRC of RTP media packet;

3. shall clear the stored SSRC of the candidate arbitrator;

4. shall restart timer T203 (End of RTP media); and

5. shall remain in ‘O: has no permission’ state.

7.2.3.5 State: ‘O: has permission’

7.2.3.5.1 General

In this state the MCPTT client is acting as a floor control server (floor arbitrator) and has the permission to send media.

Timer T206 (Stop talking warning) and timer T207 (Stop Talking) are running in this state.

7.2.3.5.2 Send RTP Media packets (S: RTP Media)

Upon receiving encoded media from the user or if encoded media is already buffered the floor participant:

1. shall start timer T206 (Stop talking warning), if not running;

2. shall request the MCPTT client to start sending RTP media packets towards other MCPTT clients; and

3. shall remain in ‘O: has permission’ state.

7.2.3.5.3 Receive Floor Release message (R: Floor Release)

Upon receiving a Floor Release message and if the value of "/<x>/<x>/OffNetwork/QueueUsage" leaf node present in the group configuration as specified in 3GPP TS 24.483 [4] is set to "true", the floor participant:

1. shall remove the sender of the Floor Release message from the queue, if the <User ID> value in the floor release message matches the <User ID> value of the queued request; and

2. shall remain in ‘O: has permission’ state.

7.2.3.5.4 Receive Floor Request message (R: Floor Request)

Upon receiving a Floor Request message which is not pre-emptive as determined by clause 4.1.1.5, in a session where:

1. the value of "/<x>/<x>/OffNetwork/QueueUsage" leaf node present in the group configuration as specified in 3GPP TS 24.483 [4] is set to "false"; or

2. the value of "/<x>/<x>/OffNetwork/QueueUsage" leaf node present in the group configuration as specified in 3GPP TS 24.483 [4] is set to "true" but the F-bit in the Floor Indicator field is set to ‘0’ (i.e. indicating that queueing of floor requests is not supported) or the Floor Indicator field is not included in the Floor Request message;

then the floor participant:

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

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

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

c. shall include the User ID field received in the Floor Request message; and

2. shall remain in ‘O: has permission’ state.

Upon receiving a Floor Request message which is not pre-emptive as determined by clause 4.1.1.5, and the value of "/<x>/<x>/OffNetwork/QueueUsage" leaf node present in the group configuration as specified in 3GPP TS 24.483 [4] is set to "true" and the F-bit in the Floor Indicator field is set to ‘1’ (i.e. indicating that queueing of the floor requests is supported) in the Floor Request message, the floor participant:

1. if the Floor Request message is not already stored, then shall store the received Floor Request message;

2. if the pending request queue is not full, shall send the Floor Queue Position Info message. The Floor Queue Position Info message:

a. shall include in the User ID field the MCPTT ID of the floor participant sending the Floor Request message;

b. shall include the SSRC of the floor participant in the SSRC of queued floor participant field;

c. shall include the position in the floor request queue in the Queue Info field; and

d. shall include the floor priority in the Queue Info field;

3. if the pending request queue is full, shall send the Floor Deny message. The Floor Deny message:

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

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

c. shall include the User ID field received in the Floor Request message; and

4. shall remain in ‘O: has permission’ state.

7.2.3.5.5 Send Floor Release message (PTT button released with no pending request in queue)

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

1. shall stop timer T206 (Stop talking warning), if running;

2. shall stop timer T207 (Stop talking), if running;

3. shall send a Floor Release message towards other floor participants, if no queued requests exist: The Floor Release message:

a. shall include the MCPTT ID of the MCPTT user in the User ID field; and

b. if the session is not initiated as a broadcast group call with the B-bit set to ‘1’ (Broadcast group call), shall include a Floor Indicator field set to ‘0’ (normal call);

4. shall start timer T230 (Inactivity);

5. shall clear the stored SSRC of the current floor arbitrator; and

6. shall enter ‘O: silence’ state.

7.2.3.5.6 Send Floor Granted message (PTT button released with pending request(s) in queue)

When no more encoded media is received from the user and if at least one Floor Request message is stored (i.e. queueing mode is used in the session), the floor participant:

1. shall stop timer T206 (Stop talking warning), if running;

2. shall stop timer T207 (Stop talking), if running;

3. shall request the MCPTT client to stop sending RTP media packets towards other MCPTT clients;

4. shall send the Floor Granted message toward the other floor participants. The Floor Granted message:

a. shall include the MCPTT ID of the first floor participant in the queue in the User ID field;

b. shall include the SSRC of the first floor participant in the queue in the SSRC of the granted floor participant field;

c. shall remove the first floor participant from the queue;

d for the remaining floor participants in the queue:

i. shall include the MCPTT ID of the floor participant in the Queued User ID field;

ii. shall include the SSRC of the floor participant in the SSRC of queued floor participant field;

iii. shall include the queue position of the floor participant in the Queue Info field; and

iv. shall include the priority of the floor participant in the Queue Info field; and

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

5. shall set the stored SSRC of the current floor arbitrator to the SSRC of user to whom the floor was granted in the Floor Granted message;

6. shall start timer T205 (Floor Granted ) and shall initiate counter C205 (Floor Granted ) to 1; and

7 shall enter the ‘O: pending granted’ state.

7.2.3.5.7 Receive Floor Request message with pre-emption indication (R: Floor Request with pre-emption)

Upon receiving a Floor Request message which is pre-emptive as determined by clause 4.1.1.5, the floor participant:

1. shall stop timer T206 (Stop talking warning), if running;

2. shall stop timer T207 (Stop talking), if running;

3. shall request the MCPTT client to stop sending RTP media packets towards other MCPTT clients;

4. shall send a Floor Granted message towards the other floor participants. The Floor Granted message:

a. shall include the MCPTT ID of the Floor Request message received in the User ID field;

b. shall include the SSRC of floor participant sending the Floor Request message in the SSRC of floor control server field; and

c. if the value of "/<x>/<x>/OffNetwork/QueueUsage" leaf node present in the group configuration as specified in 3GPP TS 24.483 [4] is set to "true", for each floor participant in the queue:

i. shall include the MCPTT ID of the floor participant in the Queued User ID field;

ii. shall include the SSRC of the floor participant in the SSRC of queued floor participant field;

iii. shall include the queue position of the floor participant in the Queue Info field; and

iv. shall include the priority of the floor participant in the Queue Info field;

5. shall start timer T205 (Floor Granted) and shall initiate counter C205 (Floor Granted) to 1;

6. shall set the stored SSRC of the current floor arbitrator to the SSRC of the user to whom the floor was granted in the Floor Granted message; and

7. shall enter the ‘O: pending granted’ state.

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

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

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

a. shall include the floor participant’s own MCPTT ID in the User ID field;

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

c. shall include the value of the SSRC of floor participant requesting floor queue status info field from the received Floor Queue Position Request message in the SSRC of queued floor participant field; and

d. shall include the value of the User ID field from the received Floor Queue Position Request message in the Queued User ID field; and

2. remain in the ‘O: has permission’ state.

7.2.3.5.9 Transmission time limit warning (Timer T206 expires)

When timer T206 (Stop talking warning) expires, the floor participant:

1. may notify the MCPTT user that the transmission time limit is about to reach;

2. shall start timer T207 (Stop talking); and

3. shall remain in the current state.

7.2.3.5.10 Transmission time limit reached with pending request(s) in queue (Timer T207 expires)

When the timer T207 (Stop talking) expires and if at least one Floor Request message is stored (i.e. queueing mode is used in the session), the floor participant:

1. shall request the MCPTT client to stop sending RTP media packets towards other MCPTT clients;

2. shall send the Floor Granted message toward the other floor participants. The Floor Granted message:

a. shall include the MCPTT ID of the first floor participant in the queue in the User ID field;

b. shall include the SSRC of the first floor participant in the queue in the SSRC of the granted floor participant field;

c. shall remove the first floor participant from the queue;

d. for the remaining floor participants in the queue:

i. shall include the MCPTT ID of the floor participant in the Queued User ID field;

ii. shall include the SSRC of the floor participant in the SSRC of queued floor participant field;

iii. shall include the queue position of the floor participant in the Queue Info field; and

iv. shall include the priority of the floor participant in the Queue Info field; and

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

3. shall set the stored SSRC of the current floor arbitrator to the SSRC of user to whom the floor was granted in the Floor Granted message;

4. shall start timer T205 (Floor Granted ) and shall initiate counter C205 (Floor Granted ) to 1; and

5 shall enter the ‘O: pending granted’ state.

7.2.3.5.11 Transmission time limit reached with no pending request in queue (Timer T207 expires)

When timer T207 (Stop talking) expires with no pending requests in the queue or if the value of "/<x>/<x>/OffNetwork/QueueUsage" leaf node present in the group configuration as specified in 3GPP TS 24.483 [4] is set to "false", the floor participant:

1. shall send a Floor Release message towards other floor participants. The Floor Release message:

a. shall include the MCPTT ID of the MCPTT user in the User ID field; and

b. if the session is not initiated as a broadcast group call with the B-bit set to ‘1’ (Broadcast group call), shall include a Floor Indicator field set to ‘0’ (normal call);

2. shall start timer T230 (Inactivity);

3. shall clear the stored SSRC of the current floor arbitrator; and

4. shall enter ‘O: silence’ state.

7.2.3.6 State: ‘O: pending request’

7.2.3.6.1 General

In this state the MCPTT client is waiting for a response to a Floor request message.

In this state timer T201 (Floor Request) is running.

To resolve race condition between multiple simultaneous floor requests, the MCPTT client resets the counter associated with timer T201, if another floor request with higher priority or higher SSRC, in case the priority is same, is received.

7.2.3.6.2 Receive RTP media (R: RTP media)

Upon receiving RTP media packets and if there is no stored SSRC of the current floor arbitrator, the floor participant:

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

2. shall reset the value of the counter C201 (Floor Request) to 1;

3. shall set the stored SSRC of the current floor arbitrator to the SSRC of RTP media packet;

4. shall restart (or start, if not running already) timer T203 (End of RTP media); and

5. shall remain in ‘O: pending request’ state.

Otherwise, if SSRC of floor participant sending the media matches with the stored SSRC of current floor arbitrator, the floor participant:

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

2. shall reset the value of the counter C201 (Floor Request) to 1;

3. shall restart (or start, if not running already) timer T203 (End of RTP media); and

4. shall remain in ‘O: pending request’ state.

Otherwise, if SSRC of floor participant sending the media packet matches with the stored SSRC of candidate arbitrator, the floor participant:

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

2. shall reset the value of the counter C201 (Floor Request) to 1;

3. shall set the stored SSRC of the current arbitrator to the SSRC of RTP media packet;

4. shall clear the stored SSRC of the candidate arbitrator;

5. shall restart (or start, if not running already) timer T203 (End of RTP media); and

6. shall remain in ‘O: pending request’ state.

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

Upon receiving Floor Queue Position Info message, if the <User ID> value in the Queued User ID field matches its own MCPTT ID and the value in the SSRC of floor control server field as received in the Floor Queue Position Info message matches the stored SSRC of current floor arbitrator, the floor participant:

1. shall update the queue status;

2. may notify the MCPTT user about the queue position received in the <Queue position info> value in the Queue Info field;

3. shall stop timer T201 (Floor Request); and

4. shall enter ‘O: queued’ state.

Otherwise, if the <User ID> value in the Queued User ID field matches its own MCPTT ID and there is no stored SSRC of the current floor arbitrator, the floor participant:

1. shall update the queue status;

2. shall set the stored SSRC of the current floor arbitrator to the value in the SSRC of floor control server field as received in the Floor Queue Position Info message;

3. may notify the MCPTT user about the queue position received in the <Queue position info> value in the Queue Info field;

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

5. shall enter ‘O: queued’ state.

Otherwise, if the <User ID> value in the Queued User ID field matches its own MCPTT ID and the value in the SSRC of floor control server field as received in the Floor Queue Position Info message matches the stored SSRC of candidate arbitrator, the floor participant:

1. shall update the queue status;

2. shall set the stored SSRC of the current arbitrator to the value in the SSRC of the floor control server field as received in the Floor Queue Position Info message;

3. shall clear the stored SSRC of the candidate arbitrator;

4. may notify the MCPTT user about the queue position received in the <Queue position info> value in the Queue Info field;

5. shall stop timer T201 (Floor Request); and

6. shall enter ‘O: queued’ state.

7.2.3.6.4 Receive Floor Deny message (R: Floor Deny)

Upon receiving Floor Deny message, if the <User ID> value in the User ID field matches its own MCPTT ID and SSRC of floor participant sending the Floor Deny message matches the stored SSRC of current floor arbitrator, the floor participant:

1. shall stop the timer T201 (Floor Request);

2. shall provide floor deny notification to the user;

3. shall restart the timer T203 (End of RTP media);

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

5. shall enter ‘O: has no permission’ state.

Otherwise, if the <User ID> value in the User ID field matches its own MCPTT ID and there is no stored SSRC of the current floor arbitrator, the floor participant:

1. shall stop the timer T201 (Floor Request);

2. shall set the stored SSRC of the current floor arbitrator to the value in the SSRC of floor control server field as received in the Floor Deny message;

3. shall restart the timer T203 (End of RTP media);

4. shall provide floor deny notification to the user;

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

6. shall enter ‘O: has no permission’ state.

Otherwise, if the <User ID> value in the User ID field matches its own MCPTT ID and SSRC of floor participant sending the Floor Deny message matches the stored SSRC of candidate arbitrator, the floor participant:

1. shall stop the timer T201 (Floor Request);

2. shall set the stored SSRC of the current arbitrator to the SSRC of the floor control server as received in the Floor Deny message;

3. shall clear the stored SSRC of the candidate arbitrator;

4. shall restart the timer T203 (End of RTP media);

5. shall provide floor deny notification to the user;

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

7. shall enter ‘O: has no permission’ state.

7.2.3.6.5 Send Floor Release message (PTT button released)

When an indication from the MCPTT user to release the pending request for the floor is received, the floor participant:

1. shall send a Floor Release message towards other floor participants. The Floor Release message:

a. shall include the MCPTT ID of the MCPTT user in the <User ID> value of the User ID field; and

b. if the session is not initiated as a broadcast group call with the B-bit set to ‘1’ (Broadcast group call), shall include a Floor Indicator field set to ‘0’ (normal call);

2. shall stop the timer T201 (Floor Request);

3. shall stop timer T203 (End of RTP media), if running;

4. shall start the timer T230 (Inactivity);

5. shall clear the stored SSRC of the current floor arbitrator; and

6. shall enter ‘O: silence’ state.

7.2.3.6.6 Send Floor Taken message (Timer T201 expired N times)

When timer T201 (Floor Request) expires and counter C201 (Floor Request) reaches its upper limit, the floor participant:

1. shall send the Floor Taken message toward the other floor participants. The Floor Taken message:

a. shall include the floor participant’s own SSRC in the SSRC of the granted floor participant field;

b. shall include the floor participant’s own MCPTT ID in the User ID field; and

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

2. shall set the stored SSRC of the current floor arbitrator to its own SSRC;

3. shall stop timer T203 (End of RTP media), if running; and

4. shall enter ‘O: has permission’ state.

7.2.3.6.7 Receive Floor Granted message (R: Floor Granted to me)

Upon receiving Floor Granted message and if the <User ID> value in the User ID field matches its own MCPTT ID and SSRC of floor participant sending the Floor Granted message matches the stored SSRC of current floor arbitrator, the floor participant:

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

2. shall set the stored SSRC of the current floor arbitrator to its own SSRC;

3. shall stop timer T203 (End of RTP media), if running;

4. shall stop timer T201 (Floor Request);

5. may provide a floor granted notification to the MCPTT user;

6. if the Floor Indicator field is included and the B bit is set to ‘1’ (Broadcast group call), shall provide a notification to the user indicating the type of call; and

7. shall enter ‘O: has permission’ state.

Otherwise, if the <User ID> value in the User ID field matches its own MCPTT ID and there is no stored SSRC of the current floor arbitrator, the floor participant:

1. shall set the stored SSRC of the current floor arbitrator to its own SSRC;

2. shall stop timer T203 (End of RTP media);

3. shall stop timer T201 (Floor Request);

4. may provide a floor granted notification to the MCPTT user;

5. if the Floor Indicator field is included and the B bit is set to ‘1’ (Broadcast group call), shall provide a notification to the user indicating the type of call; and

6. shall enter ‘O: has permission’ state.

Otherwise, if the <User ID> value in the User ID field matches its own MCPTT ID and SSRC of floor participant sending the Floor Granted message matches the stored SSRC of candidate arbitrator, the floor participant:

1. shall set the stored SSRC of the current arbitrator to its own SSRC;

2. shall stop timer T203 (End of RTP media);

3. shall stop timer T201 (Floor Request);

4. may provide a floor granted notification to the MCPTT user;

5. shall clear the stored SSRC of the candidate arbitrator;

6. if the Floor Indicator field is included and the B bit is set to ‘1’ (Broadcast group call), shall provide a notification to the user indicating the type of call; and

7. shall enter ‘O: has permission’ state.

7.2.3.6.8 Receive Floor Granted message (R: Floor Granted to other)

Upon receiving a Floor Granted message and if the <User ID> value in the User ID field does not match its own MCPTT ID and SSRC of floor participant sending the Floor Granted message matches the stored SSRC of current arbitrator, the floor participant:

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

2. shall set the stored SSRC of the candidate arbitrator to the SSRC of user to whom the floor was granted in the Floor Granted message;

3. shall reset the counter C201 (Floor Request) associated with timer T201 (Floor Request) with the value set to 1;

4. shall restart timer T203 (End of RTP media);

5. shall restart timer T201 (Floor Request);

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

7. if the Floor Indicator field is included and the B bit is set to ‘1’ (Broadcast group call), shall provide a notification to the user indicating the type of call; and

8. shall remain in ‘O: pending request’ state.

Otherwise, if the <User ID> value in the User ID field does not match its own MCPTT ID and there is no stored SSRC of the current floor arbitrator, the floor participant:

1. shall set the stored SSRC of the candidate floor arbitrator to the SSRC of user to whom the floor was granted in the Floor Granted message;

2. shall reset the counter C201 (Floor Request) associated with timer T201 (Floor Request) with the value set to 1;

3. shall restart timer T203 (End of RTP media);

4. shall restart timer T201 (Floor Request);

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

6. if the Floor Indicator field is included and the B bit is set to ‘1’ (Broadcast group call), shall provide a notification to the user indicating the type of call; and

7. shall remain in ‘O: pending request’ state.

Otherwise, if the <User ID> value in the User ID field does not match its own MCPTT ID and SSRC of floor participant sending the Floor Granted message matches the stored SSRC of candidate arbitrator, the floor participant:

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

2. shall set the stored SSRC of the candidate arbitrator to the SSRC of user to whom the floor was granted in the Floor Granted message;

3. shall reset the counter C201 (Floor Request) associated with timer T201 (Floor Request) with the value set to 1;

4. shall restart timer T203 (End of RTP media);

5. shall restart timer T201 (Floor Request);

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

7. if the Floor Indicator field is included and the B bit is set to ‘1’ (Broadcast group call), shall provide a notification to the user indicating the type of call; and

8. shall remain in ‘O: pending request’ state.

7.2.3.6.9 Timer T201 (Floor Request) expired (Timer T201 expired)

On expiry of timer T201 (Floor Request) if the counter C201 (Floor Request) has not reached its upper limit, the floor participant:

1. shall send the Floor Request message to other floor participants. The Floor Request message:

a. if a priority different than the default floor priority is required, shall include the Floor Priority field with the requested priority in the <Floor Priority> element;

b. shall include the MCPTT ID of the own MCPTT user in the User ID field; and

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

2. shall restart the timer T201 (Floor Request) and increment counter C201 (Floor Request) by 1; and

3. shall remain in the ‘O: pending request’ state.

7.2.3.6.10 Receive Floor Request message (R: Floor request)

Upon receiving Floor Request message, if the priority of received request is higher than priority of the floor participant or if the SSRC of received request is higher, if the priority is same, the floor participant:

1. shall reset the value of the counter C201 (Floor Request) to 1;

2. shall re-start timer T201 (Floor Request); and

3. shall remain in ‘O: pending request’ state.

7.2.3.6.11 Receive Floor Taken message (R: Floor Taken)

Upon receiving a Floor Taken message, the floor participant:

1. shall set the stored SSRC of the current floor arbitrator to the SSRC of granted floor participant field the Floor Taken message;

2. shall reset the value of the counter C201 (Floor request) to 1;

3. shall restart timer T201 (Floor request); and

4. shall remain in ‘O: pending request’ state.

7.2.3.7 State: ‘O: pending granted’

7.2.3.7.1 General

In this state the MCPTT client is waiting for another client to take over the role of floor arbitrator.

The timer T205 (Floor Granted) is running in this state.

7.2.3.7.2 Receive RTP media (R: RTP Media)

Upon receiving the RTP media and the SSRC of RTP media packet matches with the stored SSRC of current floor arbitrator, the floor participant:

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

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

3. shall stop timer T233 (Pending user action), if running;

4. shall start timer T203 (End of RTP media); and

5. shall enter ‘O: has no permission’ state.

7.2.3.7.3 Timer T205 (Floor Granted) expired (timer T205 expired)

On expiry of timer T205 (Floor Granted) and counter C205 (Floor Granted) is less than the upper limit, the floor participant:

1. shall send again the Floor Granted message toward the other floor participants. For each participant in the queue the Floor Granted message:

a. shall include the MCPTT ID of the floor participant in the Queued User ID field;

b. shall include the SSRC of the floor participant in the SSRC of queued floor participant field;

c. shall include the queue position of the floor participant in the Queue Info field; and

d. shall include the priority of the floor participant in the Queue Info field;

2. shall restart timer T205 (Floor Granted) and shall increment counter C205 (Floor Granted) by 1; and

3. shall remain in ‘O: pending granted’ state.

7.2.3.7.4 Timer T205 (Floor Granted) expired N times with pending request(s) in the queue (Timer T205 expired N times AND pending request(s) in queue)

On the expiry of timer T205 (Floor Granted) for the configured upper limit of counter C205 (Floor Granted) with request pending in the queue, the floor participant:

1. shall reset the value of counter C205 (Floor Granted) to 1;

2. shall start the timer T233 (Pending user action); and

3. shall remain in ‘O: pending granted’ state.

7.2.3.7.5 Timer T205 (Floor Granted) expired N times with no pending request in the queue (Timer T205 expired N times AND no pending request in queue)

On the expiry of timer T205 (Floor Granted) for the configured upper limit of counter C205 (Floor Granted) with no request pending in the queue, the floor participant:

1. shall reset the value of counter C205 (Floor Granted) to 1;

2. shall start timer T230 (Inactivity);

3. shall clear the stored SSRC of the current floor arbitrator; and

4. shall enter ‘O: silence’ state.

7.2.3.7.6 Timer T233 (Pending user action) expires with no pending request in the queue (Timer T233 expired AND no pending request in queue)

On expiry of timer T233 (Pending user action) with no request pending in the queue, the floor participant:

1. shall send a Floor Release message towards other floor participants. The Floor Release message:

a. shall include the MCPTT ID of the MCPTT user in the User ID field;

2. shall start timer T230 (Inactivity);

3. shall clear the stored SSRC of the current floor arbitrator; and

4. shall enter ‘O: silence’ state.

7.2.3.7.7 Timer T233 (Pending user action) expires with pending request(s) in the queue (Timer T233 expired AND pending request(s) in queue)

On the expiry of timer T233 (Pending user action) with more request(s) pending in the queue, the floor participant:

1. shall send the Floor Granted message for the next pending request in the queue towards other floor participants. The Floor Granted message:

a. shall include the MCPTT ID of the first floor particant in the queue in the User ID field;

b. shall include the SSRC of the first floor participant in the queue in the SSRC of the granted floor participant field;

c. shall remove the first floor participant from the queue;

d. for the remaining floor participants in the queue:

i. shall include the MCPTT ID of the floor participant in the Queued User ID field;

ii. shall include the SSRC of the floor participant in the SSRC of queued floor participant field;

iii. shall include the queue position of floor participant in the Queue Info field;

iv. shall include the priority of the floor participant in the Queue Info field; and

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

2. shall set the stored SSRC of the current floor arbitrator to the SSRC of user to whom the floor was granted in the Floor Granted message;

3. shall start timer T205 (Floor Granted);

4. shall initialize the counter C205 (Floor Granted) with the value set to 1; and

5. shall remain in ‘O: pending granted’ state.

7.2.3.7.8 PTT button pressed

If the floor participant receives an indication from the MCPTT user to send media, the floor participant:

1. may notify the MCPTT user about rejection; and,

2. shall remain in ‘O: pending granted’ state.

7.2.3.7.9 Receive Floor Release message (R: Floor Release)

Upon receiving a Floor Release message, the floor participant:

1. shall remove the sender of the Floor Release message from the queue, if the User ID in the floor release message matches the queued request of User ID; and

2. shall remain in ‘O: pending granted’ state.

7.2.3.7.10 Receive Floor Request message (R: Floor Request)

When a Floor Request message is received, the floor participant:

1. if the SSRC in the received Floor Request message equals the stored SSRC of the current floor arbitrator,

a. shall send again the Floor Granted message toward the other floor participants. For each participant in the queue the Floor Granted message:

i. shall include the MCPTT ID of the floor participant in the Queued User ID field;

ii. shall include the SSRC of the floor participant in the SSRC of queued floor participant field;

iii. shall include the queue position of the floor participant in the Queue Info field; and

iv. shall include the priority of the floor participant in the Queue Info field; and

b. shall restart timer T205 (Floor Granted) and shall increment counter C205 (Floor Granted) by 1;

2. if the SSRC in the received Floor Request message does not equal the stored SSRC of the current floor arbitrator, shall send the Floor Deny message toward the other floor participant. The Floor Deny message:

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

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

c. shall include the User ID field received in the Floor Request message; and

3. shall remain in ‘O: pending granted’ state.

7.2.3.8 State: ‘O: queued’

7.2.3.8.1 General

In this state the MCPTT client is waiting for a response to a queued request.

7.2.3.8.2 Receive RTP media (R: RTP media)

Upon receiving RTP media packets and the SSRC of RTP media packet matches with the stored SSRC of current floor arbitrator, the floor participant:

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

2. shall restart timer T203 (End of RTP media); and

3. shall remain in ‘O: queued’ state.

Otherwise, if SSRC of floor participant sending the media packet matches with the stored SSRC of candidate arbitrator, the floor participant:

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

2. shall restart timer T203 (End of RTP media);

3. shall set the stored SSRC of the current arbitrator to the SSRC of RTP media packet;

4. shall clear the stored SSRC of the candidate arbitrator; and

5. shall remain in ‘O: queued’ state.

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

Upon receiving Floor Queue Position Info message, if the <User ID> value in the Queued User ID field matches its own MCPTT ID and SSRC of floor participant sending the Floor Queue Position Info message matches the stored SSRC of current floor arbitrator, the floor participant:

1. shall update the queue position;

2. shall notify the MCPTT user about the queue position received in the <Queue position info> value in the Queue Info field;

3. shall stop timer T204 (Floor Queue Position request); and

4. shall remain in ‘O: queued’ state.

Otherwise, if the <User ID> value in the User ID field matches its own MCPTT ID and SSRC of floor participant sending the Floor Queue Position Info message matches the stored SSRC of candidate arbitrator, the floor participant:

1. shall update the queue position;

2. shall set the stored SSRC of the current arbitrator to the SSRC of the floor control server as received in the Floor Queue Position Info message;

3. shall clear the stored SSRC of the candidate arbitrator;

4. shall notify the MCPTT user about the queue position received in the <Queue position info> value in the Queue Info field;

5. shall stop timer T204 (Floor Queue Position request); and

6. shall remain in ‘O: queued’ state.

7.2.3.8.4 Receive Floor Deny message (R: Floor Deny)

1. shall stop timer T204 (Floor Queue Position request), if running;

2. shall stop the timer T233 (Pending user action), if running;

3. shall provide floor deny notification to the user;

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

5. shall enter ‘O: has no permission’ state.

1. shall stop timer T204 (Floor Queue Position request), if running;

2. shall stop the timer T233 (Pending user action), if running;

3. shall set the stored SSRC of the current arbitrator to the SSRC of the floor control server as received in the Floor Deny message;

4. shall clear the stored SSRC of the candidate arbitrator;

5. shall provide floor deny notification to the user;

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

7. shall enter ‘O: has no permission’ state.

7.2.3.8.5 User indication for release of pending request

When an indication from the MCPTT user to release the queued request for the floor is received, the floor participant:

1. shall send a Floor Release message towards other floor participants. The Floor Release message:

a. shall include the MCPTT ID of the MCPTT user in the User ID field;

2. shall stop timer T204 (Floor Queue Position request), if running;

3. shall stop timer T233 (Pending user action), if running; and

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

7.2.3.8.6 Receive Floor Granted message (R: Floor Granted to me)

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

2. shall start timer T233(Pending user action), if not running already;

3. shall notify the MCPTT user about of the floor grant;

4. if the Floor Indicator field is included, and the B bit is set to ‘1’ (Broadcast group call), shall provide a notification to the user indicating the type of call; and

5. shall remain in ‘O: queued’ state.

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

2. shall start timer T233(Pending user action), if not running already;

3. shall notify the MCPTT user about of the floor grant;

4. shall set the stored SSRC of the current arbitrator to its own SSRC;

5. shall clear the stored SSRC of the candidate arbitrator;

6. if the Floor Indicator field is included, and the B bit is set to ‘1’ (Broadcast group call), shall provide a notification to the user indicating the type of call; and

7. shall remain in ‘O: queued’ state.

7.2.3.8.7 Timer T233 (Pending user action) expires

On expiry of timer T233 (Pending user action), the floor participant:

1. shall stop timer T204 (Floor Queue Position request), if running;

2. shall start timer T230 (Inactivity); and

3. shall enter ‘O: silence’ state.

7.2.3.8.8 User indication for accept of pending request

If the floor participant receives an indication from the user that the user wants to send media and the timer T233 (pending user action) is running, the floor participant:

1. shall stop timer T204 (Floor Queue Position request), if running;

2. shall stop the timer T233 (Pending user action);

3. shall set the stored SSRC of the current floor arbitrator to its own SSRC; and

4. shall enter ‘O: has permission’ state.

7.2.3.8.9 Receive Floor Granted message (R: Floor Granted to other)

Upon receiving Floor Granted message and if the <User ID> value in the User ID field does not match its own MCPTT ID and SSRC of floor participant sending the Floor Granted message matches the stored SSRC of current floor arbitrator, the floor participant:

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

2. shall restart timer T203 (End of RTP media);

3. shall set the stored SSRC of the candidate floor arbitrator to the SSRC of user to whom the floor was granted in the Floor Granted message; and

4. shall remain in ‘O: queued’ state.

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

2. shall restart timer T203 (End of RTP media);

3. shall set the stored SSRC of the candidate floor arbitrator to the SSRC of user to whom the floor was granted in the Floor Granted message; and

4. shall remain in ‘O: queued’ state.

7.2.3.8.10 Timer T203 (End of RTP media) expires

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

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

2. shall send the Floor Request message to other floor participants. The Floor Request message:

a. if a priority different than the default floor priority is required, shall include the Floor Priority field with the requested priority in the <Floor Priority> element;

b. shall include the MCPTT ID in the <User ID> value; and

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

3. shall stop timer T204 (Floor Queue Position request), if running;

4. shall initialize the counter C201 (Floor request) with value set to 1;

5. shall start timer T201 (Floor Request);

6. shall clear the stored SSRC of the current floor arbitrator; and

7. shall enter ‘O: pending request’ state.

7.2.3.8.11 Send Floor Queue Position Request message (R: Request queue position info)

Upon receipt of an indication from the MCPTT client to request the queue position information, the floor participant:

1. shall send the Floor Queue Position Request message; The Floor Queue Position Request message:

a. shall include the SSRC of sent Floor Request message in SSRC of floor participant field; and

b. shall include the own MCPTT User ID in User ID field;

2. shall initialize the counter C204 (Floor Queue Position request) with value set to 1;

3. shall start timer T204 (Floor Queue Position request); and

4. remain in the ‘O: queued’ state.

7.2.3.8.12 Timer T204 (Floor Queue Position request) expires

Upon expiry of timer T204 (Floor Queue Position request), the floor participant:

1. shall send the Floor Queue Position Request message; The Floor Queue Position Request message:

a. shall include the SSRC of sent Floor Request message in SSRC of floor participant field; and

b. shall include the own MCPTT User ID in User ID field;

2. shall increment the value of counter C204 (Floor Queue Position request) by 1;

3. shall start timer T204 (Floor Queue Position request); and

4. remain in the ‘O: queued’ state.

7.2.3.8.13 Timer T204 (Floor Queue Position request) expires N times

Upon expiry of timer T204 (Floor Queue Position request) when the value of the counter C204 (Floor Queue Position request) is equal to the value upper limit, the floor participant:

1. shall reset the counter C204 (Floor Queue Position request) with value set to 1;

2. shall start timer T230 (Inactivity);

3. shall clear the stored SSRC of the current floor arbitrator; and

4. shall enter ‘O: silence’ state.

7.2.3.9 In any state

7.2.3.9.1 General

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

7.2.3.9.2 Receive MCPTT call release (R: MCPTT call release)

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

1. shall stop sending floor control messages towards other floor participants;

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

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

4. shall terminate the instance of floor participant state transition diagram; and

5. shall enter ‘Start-stop’ state.