A.3 On-network floor control signalling flows

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

A.3.1 General

The following clauses contain the following on-network example flows:

1. Floor request when the floor is idle in clause A.3.2;

2. Floor request when floor is taken and queueing is not applied in clause A.3.3;

3. Floor request when floor is taken and queueing is applied in clause A.3.4; and

4. Pre-emptive floor request when floor is taken in clause A.3.5.

A.3.2 Floor request when the floor is idle

Figure A.3.2-1 illustrates a case a user request floor and is granted the floor during an ongoing MCPTT call.

Figure A.3.2-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 to the floor control server.

2. When the floor control interface towards the MCPTT client A receives the Floor Request message in the ‘U: not permitted and Floor Idle’ state the Floor Request message is forwarded to the floor control arbitration logic.

3. When the floor control arbitration logic receives the Floor Request message in the ‘G: Idle’ state, the floor request is authorized. If the floor request is authorized, the floor control arbitration logic sends the Floor Granted message to the floor control interface towards the MCPTT client A and changes the state to ‘G: Floor Taken’.

4. The floor control interface towards the MCPTT client A forwards the Floor Granted message to the floor participant in the associated MCPTT client and changes the state to ‘U: permitted’.

5. The floor control arbitration logic sends a Floor Taken message to all other participants in the MCPTT call via the other floor control interfaces towards the MCPTT clients.

When the Floor Taken message is received by the other floor control interfaces towards the MCPTT clients the Floor Taken message is forwarded to the floor participant in the associated MCPTT client and the state is changed to the ‘U: not permitted and Floor Taken’ state.

6. On receipt of the Floor Granted message the floor participant in the associated MCPTT client provides a grant notification to the MCPTT user, changes the state to ‘U: has permission’ and the MCPTT client A starts to forward RTP media packets towards the MCPTT server.

7. The media distributor distributes the RTP media packets to all other MCPTT clients in the MCPTT call.

8. When the user at MCPTT client A stops talking and releases the push-to-talk button the floor participant in the MCPTT client A sends a Floor Release message to the floor control server and enter the ‘U: pending Release’ state.

9. When the floor control interface towards the MCPTT client A receives the Floor Release message the Floor Release message is forwarded to the floor control arbitration logic. The floor control interface towards the MCPTT client A allows the last RTP media packets to be forwarded to the media distributor in the MCPTT server.

10. When the last RTP media packet is forwarded to the media distributor in the MCPTT server the floor control interface towards the MCPTT client A sends the Floor Idle message to the floor participant in associated MCPTT client A and changes the state to ‘U: not permitted and Floor Idle’.

11. When the floor control arbitration logic receives the Floor Release message the last RTP media packets are allowed to be forwarded.

12. When the last RTP media packets are distributed by the media distributor the floor control arbitration logic sends a Floor Idle message to all participants in the MCPTT call with the exception of the MCPTT client that was permitted to send media and changes state to ‘G: Floor Idle’. The Floor Idle message is forwarded by the other floor control interface towards MCPTT clients. The state in the other floor control interface towards MCPTT clients is changed to ‘U: not permitted and Floor Idle’.

A.3.3 Floor request when floor is taken and queueing is not applied

Figure A.3.3-1 illustrates a case when a user requests the floor when the floor is taken and queueing is not applied in the MCPTT call.

Figure A.3.3-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 A.

1. The floor participant in one of the other MCPTT clients sends the Floor Request message towards the floor control server. The Floor participant enters the ‘U: pending Request’ state.

2. When one of the other floor control interface towards MCPTT clients receives a Floor Request message in the ‘U: not permitted and Floor Taken’ state and if:

– the floor request does not include higher priority than the current user permitted to talk requested; and

– when queueing of floor requests are not negotiated;

then the other floor control interface towards MCPTT clients send a Floor Deny message towards the floor participant in the associated MCPTT client.

When the floor participant in the associated MCPTT client receives the Floor Deny message, the floor participant provides a deny notification to the user. The Floor participant enters the ‘U: has no permission’ state.

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

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

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

The user at MCPTT client B wants to speak and presses the push-to-talk when the floor is already taken by the MCPTT client A.

The steps of the flow is as follows:

1. The floor participant in the MCPTT client B sends the Floor Request message towards the floor control server.

2. When the floor control interface towards the MCPTT client B receives a Floor Request message in the ‘U: not permitted and Floor Taken’ state and if:

a. the floor request does not include higher priority than the user already permitted to talk requested; and

b. when queueing of floor requests are negotiated as specified in clause 14;

then the floor control interface towards the MCPTT client B queues the Floor Request message and sends a Floor Queue Position Info message towards the floor participant in the MCPTT client B.

When the floor participant in MCPTT client B receives the Floor Queue Position Info message the floor participant provides a queueing indication to the user and enters the ‘U: queued’ state.

3. When the user at MCPTT client A stops talking and releases the push-to-talk button the floor participant in the MCPTT client A sends a Floor Release message to the floor control server and enters the ‘U: pending Release’ state.

4. When the floor control interface towards the MCPTT client A receives the Floor Release message the Floor Release message is forwarded to the floor control arbitration logic.

5. When the floor control arbitration logic receives the Floor Release message the last RTP media packets are allowed to be forwarded. When the last RTP media packets are distributed the floor control arbitration logic checks the active floor request queue. In this example there is one floor request in the queue and a Floor Granted message is sent towards the floor participant in the MCPTT client B.

6. The floor control interface towards MCPTT client B interface forwards the Floor Granted message to the floor participant in MCPTT client B and changes the state to ‘U: permitted’.

7. The floor control arbitration logic sends a Floor Taken message to all other participants in the MCPTT call via the other floor control interfaces towards MCPTT clients.

When the Floor Taken message is received by the other floor control interface towards MCPTT clients Floor Taken message is forwarded to the floor participants in the associated MCPTT client. The floor participant in the MCPTT client A changes the state to the ‘U: not permitted and Floor Taken’ state.

8. On receipt of the Floor Granted message the floor participant in MCPTT client B provides a grant notification to the MCPTT user, changes the state to ‘U: has permission’ and the MCPTT client A starts to forward RTP media packets towards the MCPTT server.

9. The media distributor distributes the RTP media packets to all other MCPTT clients in the MCPTT call.

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

Figure A.3.5-1 shows the message flow when a user with pre-emptive priority request floor when the floor is already taken by another user.

Figure A.3.5-1: Pre-emptive floor request when floor is taken

The user at MCPTT client B wants to interrupt the user at the MCPTT client presses the push-to-talk indicating a pre-emptive priority.

The steps of the flow are as follows:

1. The floor participant in the MCPTT client B sends the Floor Request message towards the floor control server. The message includes a pre-emptive priority.

2. When the floor control interface towards MCPTT client interface in the MCPTT server receives a Floor Request message in the ‘U: not permitted and Floor Taken’ state and since the Floor Request message includes a higher pre-emptive priority than the user that is already permitted to send media the floor control interface towards the MCPTT client sends the Floor Request message to the floor control server arbitration logic.

3. When the floor control server arbitration logic receives the Floor Request message with the high pre-emptive priority, the floor control server arbitration logic revokes the current talker’s permission to talk by sending a Floor Revoke message to the floor control interface towards the MCPTT client A.

4. The floor control interface towards MCPTT client A forwards the Floor Revoke message to the floor participant in MCPTT A.

5. When the floor participant in the MCPTT client A receives the Floor Revoke message, the floor participant provides a floor revoke indication to the MCPTT user, sends a Floor Release message and changes the state to ‘U: pending Release’.

6. When the floor control interface towards the MCPTT client A receives the Floor Release message, the Floor Release message is forwarded to the floor control server arbitration logic.

7. When the floor control arbitration logic receives the Floor Release message the last RTP media packets are allowed to be received. When the last RTP media packets are distributed the floor control arbitration logic sends a Floor Granted message towards the floor control interface towards the MCPTT client B.

8. The floor control interface towards MCPTT client receives the Floor Granted message the Floor Granted message is sent to the floor participant in MCPTT client B and changes the state to ‘U: permitted’.

9. The floor control arbitration logic sends a Floor Taken message to all other participants in the MCPTT call via the other floor control interfaces towards the MCPTT clients.

When the Floor Taken message is received by the other floor control interfaces to MCPTT clients the Floor Taken message is forwarded to the floor participant in the associated MCPTT client. The floor participant in the MCPTT client A changes the state to the ‘U: not permitted and Floor Taken’ state.

10. On receipt of the Floor Granted message the floor participant in MCPTT client B provides a grant notification to the MCPTT user, changes the state to ‘U: has permission’ and the MCPTT client A starts to forward RTP media packets towards the MCPTT server.

11. The media distributor in the MCPTT server distributes the RTP media packets to all other MCPTT clients in the MCPTT call.