A.4 Off-network floor control signalling flows

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

A.4.1 General

This clause provides the following message flow examples:

1. floor request when the floor is idle is shown in clause A.4.2.1;

2. floor request when floor is taken and queueing of floor requests is not applied is shown in clause A.4.2.2;

3. floor request when floor is taken and queueing of floor requests is applied is shown in clause A.4.2.3; and

4. pre-emptive floor request when floor is taken is shown in clause A.4.2.4.

A.4.2 Off-network floor control during an MCPTT group call

A.4.2.1 Floor request when the floor is idle

Figure A.4.2.1-1 illustrates a user’s floor request when the floor is idle i.e. there is no floor arbitrator.

Figure A.4.2.1-1: Floor request when the floor is idle

The user at MCPTT client A wants to talk and presses the push-to-talk button.

The steps of the flow are as follows:

1. The floor participant in the MCPTT client A sends a Floor Request message towards other MCPTT clients and starts timer T201 (Floor Request). MCPTT client A moves to ‘O: pending request’ state.

2. On expiry of T201 (Floor Request) MCPTT client A re-sends the Floor Request message and restarts timer T201 (Floor Request). This step has to be repeated for a pre-configured number of times (3 times in the example figure) before assuming that the floor is idle.

3. On the expiry of the last iteration of timer T201 (Floor Request), MCPTT client A sends a Floor Taken message towards other MCPTT client and assumes the role of floor arbitrator. MCPTT client A moves to ‘O: has permission state’.

4. On receiving Floor Taken message, all other MCPTT clients move to ‘O: has no permission state’.

A.4.2.2 Floor request when floor is taken and queueing of floor requests is not applied

Figure A.4.2.2-1 illustrates a user’s floor request when the floor is taken and queueing is not applied in the MCPTT call.

Figure A.4.2.2-1: Floor request when floor is taken when queueing is not applied

One of the users in the MCPTT call wants to speak and presses the push-to-talk when the floor is already taken by the MCPTT client B and queueing is not applied.

1. The floor participant in MCPTT client A sends the Floor Request message towards other MCPTT clients. The Floor participant enters the ‘O: pending request’ state.

2. On receiving Floor Request message, MCPTT client B sends a Floor Deny message with MCPTT client A’s ID towards all MCPTT clients.

3. On receiving Floor Deny message, MCPTT client A moves back to ‘O: has no permission’ state.

A.4.2.3 Floor request when floor is taken and queueing is applied

Figure A.4.2.3-1 illustrates a user’s floor request when the floor is taken and queueing is applied in the MCPTT call.

Figure A.4.2.3-1: Floor request when floor is taken and queueing applied

The users at MCPTT client A wants to speak and presses the PTT button when the floor is already taken by the MCPTT client B.

The steps of the flow are as follows:

1. The floor participant in the MCPTT client A sends the Floor Request message towards other MCPTT clients. MCPTT client A moves to ‘O: pending request’ state and starts timer T201 (Floor Request).

2. On expiry of timer T201 (Floor Request) MCPTT client A re-sends the Floor Request message and restarts timer T201 (Floor Request). This step has to be repeated for a pre-configured number of times before assuming that the floor is idle.

3. Receiving RTP media indicates that the floor is taken and a floor arbitrator is present. Sending multiple requests till a reply to the request is received helps reduce conflicts. Therefore, the counter associated to T201 (Floor Request) is reset every time RTP media is received.

4. On receiving Floor Queue Position Info message from the floor arbitrator, MCPTT client A stops timer T201 (Floor Request) and moves to ‘O: queued’ state. Any RTP media received in this state is rendered.

5. When the user at MCPTT client B indicates to terminate RTP media transmission, MCPTT client B sends Floor Granted message to the next (MCPTT client A) in queue. MCPTT client B start timer T205 (Floor Granted request) and moves to ‘O: pending grant’ state.

6. On receiving Floor Granted message, MCPTT client A starts timer T233 (pending user action) and waits for user to indicate start of RTP media transmission.

7. On expiry of timer T205 (Floor Granted) MCPTT client B re-sends the Floor Granted message and restarts timer T205 (Floor Granted). This step has to be repeated for a pre-configured number of times while no media is received from MCPTT client A.

8. Upon expiry of timer T205 (Floor Granted) for a preconfigured number of times, MCPTT client B starts timer T233 (pending user action), waiting for RTP media from MCPTT client A.

9. MCPTT client A stops timer T233 (pending user action) upon user action. MCPTT client A moves to ‘O: has permission’ state and starts transmission of RTP media as floor arbitrator.

10. On receiving RTP media from MCPTT client A, MCPTT client B stops timer T233 (pending user action) and moves to ‘O: has no permission’ state.

A.4.2.4 Pre-emptive floor request when floor is taken

Figure A.4.2.4-1 shows the message flow when a user requests floor with a pre-emptive priority when the floor is already taken.

Figure A.4.2.4-1: Pre-emptive Floor request

The user at MCPTT client A, with higher priority than the current floor arbitrator, wants to speak and presses the push-to-talk when the floor is taken by the MCPTT client B.

The steps of the flow are as follows:

1. The floor participant in the MCPTT client A sends the pre-emptive Floor Request message towards other MCPTT clients and starts timer T201 (Floor Request). MCPTT client A moves to ‘O: pending request’ state.

2. Upon receiving a higher priority floor request, MCPTT client B sends Floor Granted message and start timer T205 (Floor Granted request) . Any RTP media transmission is stopped and MCPTT client B moves to ‘O: pending grant’ state. User at MCPTT client B can be notified of the pre-emption and any RTP media transmission is stooped.

3. On expiry of timer T205 (Floor Granted) the MCPTT client B re-sends the Floor Granted message and restarts timer T205 (Floor Granted). This step has to be repeated for a pre-configured number of times, if no RTP media from MCPTT client A.

4. MCPTT client A moves to ‘O: has permission’ state and assumes the role of floor arbitrator upon receiving Floor Granted message.

5. On receiving RTP media from MCPTT client A, MCPTT client B stops timer T205 (Floor Granted) and moves to ‘O: has no permission’ state.