Content for  TS 23.379  Word version:  17.5.0

10.9.1.3  Floor control within one MCPTT system  Word‑p. 176

10.9.1.3.1  Floor request, floor granted and floor taken during an MCPTT session

Figure 10.9.1.3.1-1 shows the high level procedure that the floor control is conducted for the MCPTT session already established between the floor participant and the floor control server. Only three UEs involved in the session are shown for the simplicity.

Pre-condition:

1. MCPTT session is established between MCPTT clients (client A, client B and client C) and MCPTT server.
2. The user at MCPTT client C is an authorized user (e.g., dispatcher) allowed to remove a floor request of other MCPTT users from the floor queue and can receive notifications about another user when their floor request is queued, when their queued floor request is rejected and when their queued floor request is removed from the queue.

(not reproduced yet)

Figure 10.9.1.3.1-1: Floor request, floor granted, floor taken during an MCPTT session

Step 1.

The floor control is established between the floor participants and floor control server. It is assumed that the floor is now in idle status.

Step 2.

Floor participant A wants to send voice media over the session.

Step 3.

Floor participant A sends a floor request message to floor control server which includes floor priority and other information as necessary.

Step 4.

Floor control server makes the determination on what action (grant, deny, or queue) to take on the request based on criteria (e.g., floor priority, participant type) and determines to accept the floor request from floor participant A. The floor control server may limit the time a user talks (hold the floor) as allowed by the configuration.

Step 5a.

Floor control server responds with a floor granted message to floor participant A including the maximum floor granted duration e.g., if no other floor participant has the permission for transmission.

Step 5b.

Floor control server sends a floor taken message to the other floor participant (floor participant B) including information about who is granted the floor.

Step 5c.

Floor participant A sends a floor acknowledgement if indicated to do so by the floor granted message.

Step 5d.

Floor participant B sends a floor acknowledgement if indicated to do so by the floor taken message.

Step 5e.

Floor control server sends a floor taken message to the other floor participant (floor participant C) including information about who is granted the floor.

Step 5f.

Floor participant C sends a floor acknowledgement if indicated to do so by the floor taken message.

Step 6a.

The floor granted shall cause the user of UE A where the floor participant A is located to be notified.

Step 6b.

The receipt of the floor taken may be used to inform the user of UE B where the floor participant B is located.

Step 6c.

The receipt of the floor taken may be used to inform the user of UE C where the floor participant C is located.

Step 7.

Floor participant A starts sending voice media over the session established beforehand.

Step 8.

Suppose there are one or more users requesting to talk at this time, the floor request(s) are queued as decided by floor control server e.g., based on floor priority.

Step 9.

Floor participant B sends a floor request message.

Step 10.

Floor control server queues the request of floor participant B.

Step 11a.

Floor control server sends queue position info to floor participant B.

Step 11b.

Floor participant B sends a floor acknowledgement if indicated to do so by the queue position info message.

Step 12.

Floor control server may send the queue position info to floor participant C who is an authorized user to indicate floor participant user B's floor request is queued.

Step 13.

Floor participant C sends a floor acknowledgement if indicated to do so by the queue position info message.

10.9.1.3.1a  Floor request, floor granted and multi-talker floor taken during an MCPTT session enhanced with multi-talker control |R15|  Word‑p. 177

Figure 10.9.1.3.1a-1 shows the high level procedure that allows several participants to talk simultaneously in a MCPTT session already established between the floor participant and the floor control server. Three UEs involved in the session are shown for simplicity.

Pre-conditions:

1. The MCPTT group is configured to support multi-talker control and audio mixing by the network is applied.
2. MCPTT session is established between MCPTT clients (client A, client B and client C) and MCPTT server.
3. Participants and A and B have the permission to talk to all other participants and the floor is granted to floor participant B.

(not reproduced yet)

Figure 10.9.1.3.1a-1: Floor request, floor granted and multi-talker floor taken during an MCPTT session

Step 1.

Floor participant B is talking and is sending the voice media.

Step 2.

Floor participant A wants to send voice media over the session.

Step 3.

Floor participant A sends a floor request message to the floor control server which includes the necessary information, e.g. floor priority.

Step 4.

Based on applicable criteria (e.g. floor priority, participant type, allowance to transmit, maximum number of simultaneous talkers) floor control server determines what action (grant, deny, or queue) shall be applied to the request. In this case, the floor request from floor participant A will be accepted. Simultaneous floor requests to transmit are handled in a sequential order. Based on the group configuration repository data, the floor control server may limit the time a floor participant is allowed to talk.

Step 5a.

Floor control server responds with a floor granted message to floor participant A.

Step 5b.

Floor control server sends a multi-talker floor taken message to floor participant B.

Step 5c.

Floor control server sends a multi-talker floor taken message to floor participant C.

Step 5d.

Floor control server may send a multi-talker floor taken message to floor participant A.

Step 6a.

The floor granted shall cause the user of UE A, where the floor participant A is located, to be notified.

Step 6b.

The multi-talker floor taken shall inform the user of UE B, that the floors are granted to other floor participants, but the floor is not revoked.

Step 6c.

The multi-talker floor taken shall inform the user of UE C floor participants list the floor are currently granted to.

Step 7.

Floor participant A starts sending voice media over the session established beforehand, i.e. participants A and B receive and transmit voice media; participant C only receives voice media.

10.9.1.3.2  Floor override  Word‑p. 179

10.9.1.3.2.1  Floor override using floor revoked (also floor rejected) during an MCPTT session

Figure 10.9.1.3.2.1-1 shows the high level procedure that the floor control is conducted for the MCPTT session already established between the floor participant (with floor granted to floor participant B) and the floor control server (with an override based on priority). Only two UEs involved in the session are shown for the simplicity.

(not reproduced yet)

Figure 10.9.1.3.2.1-1: Floor override using floor revoked (also floor rejected) during an MCPTT session

Step 1.

It is assumed that floor participant B has been given floor and is transmitting voice media.

Step 2.

Floor participant A having a priority which is relatively higher than that of floor participant B wants to send voice media over the session.

Step 3.

Floor participant A sends a floor request message to the floor control server.

Step 4.

The floor control server determines to accept the floor request from floor participant A based on arbitration result e.g., according to the priority information that is received in the floor request message. The floor control server sends a floor revoked message to floor participant B stopping the voice media transmission from floor participant B.

Step 5.

The user of floor participant B may be notified that the floor is revoked.

Step 6.

The Floor control server sends a floor granted message to floor participant A, while sending a floor taken message to floor participant B with information of who is granted the floor.

Step 7.

The user of floor participant A may be notified that he is granted the floor. Similarly, the user of floor participant B may be notified who is granted the floor.

Step 8.

Floor participant A starts sending voice media over the session established beforehand.

Step 9.

Now floor participant B may want the floor to start sending voice media.

Step 10.

Floor participant B sends a floor request message to floor control server which may include priority information.

Step 11.

Floor control server determines whether to accept the floor request from floor participant B based on arbitration result e.g., according to the priority information that is received in the floor request message.

Step 12.

The floor control server responds with a floor rejected message to floor participant B.

Step 13.

Floor participant B may be notified that he is rejected.

10.9.1.3.2.2  Floor override without using floor revoked during an MCPTT session  Word‑p. 180

Figure 10.9.1.3.2.2-1 shows the high level procedure that the floor control is conducted for the MCPTT session already established between the floor participants (with floor granted to floor participant B) and the floor control server (with an override based on priority and configured to permit the transmission of the overridden floor participant B to continue). Only two UEs involved in the session are shown for the simplicity.

Pre-conditions

• The floor control server has been configured to support override.
• The override supported in this case permits both the overridden floor participant and the overriding floor participant to be transmitting.

(not reproduced yet)

Figure 10.9.1.3.2.2-1: Floor override (overridden continues to transmit) during an MCPTT session

Step 1.

It is assumed that floor participant B has been given the floor and is transmitting voice media.

Step 2.

Floor participant A having a floor priority which is relatively higher than that of floor participant B wants to send voice media over the session.

Step 3.

Floor participant A sends a floor request message to the floor control server.

Step 4.

The floor control server determines to accept the floor request from floor participant A based on arbitration result e.g., according to the floor priority information that is received in the floor request message.

Step 5a.

Floor control server responds with a floor granted message to floor participant A.

Step 5b.

Floor control server sends a floor taken message to the other floor participants (including floor participant B). Floor participant B continues transmitting the (overridden) voice media transmission.

Step 6a.

The floor granted causes the user of floor participant A to be notified.

Step 6b.

The user of floor participant B is notified of the status that the floor is now taken by floor participant A.

Step 7.

Floor participant A (overriding) starts sending voice media over the session established beforehand.

10.9.1.3.2.3  Floor override using floor revoked (also floor rejected) during an MCPTT session enhanced with multi-talker control |R15|  Word‑p. 181

Figure 10.9.1.3.2.3-1 shows the high-level procedure that the floor control allows several participants to talk simultaneously in a MCPTT session already established between the floor participant (with floor granted to floor participant B) and the floor control server. Only two UEs involved in the session are shown for the simplicity.

Pre-conditions:

1. The MCPTT group is configured to support multi-talker control.
2. MCPTT session is established between MCPTT clients (client A, client B and client C) and MCPTT server.
3. The maximum number of simultaneous talkers is set to 2.
4. The floor priority of floor participant A is higher than of floor participant B.
5. The floor is granted to floor participant B and floor participant C.

(not reproduced yet)

Figure 10.9.1.3.2.3-1: Floor override using floor revoked (also floor rejected) during an MCPTT session

Step 1.

Floor participant B and floor participant C are sending voice media over the session established.

Step 2.

Floor participant A wants to send voice media over the session.

Step 3.

Floor participant A wants to talk (i.e. send voice media) over the session. Floor participant A sends a floor request message to the floor control server.

Step 4.

Based on an arbitration result (e.g. per the priority information that is received in the floor request message), the floor control server determines to accept the floor request from floor participant A. The maximum number of simultaneous talkers in the MCPTT group has been reached, the floor control server decides to apply the override mechanism.

Step 5.

The floor control server sends a floor revoked message to floor participant B stopping the voice media transmission of floor participant B.

Step 6.

The user of floor participant B may be notified that the floor is revoked.

Step 7.

The Floor control server sends a floor granted message to floor participant A, while sending a multi-talker floor taken message to floor participant B and floor participant C including the information to whom the floor has been granted.

Step 8.

The user of floor participant A may be notified that the floor has been granted to him. Similarly, the user of floor participant B and floor participant C may be notified to whom the floor has been granted.

Step 9.

Floor participant A starts sending voice media over the session established beforehand.

Step 10.

Now floor participant B may want the floor to start sending voice media.

Step 11.

Floor participant B sends a floor request message to floor control server that may include participant priority information.

Step 12.

Based on arbitration result, e.g. per the priority information that is received in the floor request message, and if the number of MCPTT Users has already reached the maximum number of simultaneous talkers in the group, the floor control server determines whether to accept or reject the floor request from floor participant B. Due to lower priority of participant B and the applicable limitation of simultaneous talkers, the floor control server rejects the floor request.

Step 13.

The floor control server responds with a floor rejected message to floor participant B.

Step 14.

Floor participant B may be notified about the floor rejection.

10.9.1.3.2.4  Floor release during an MCPTT session enhanced with multi-talker control |R15|  Word‑p. 183

Figure 10.9.1.3.2.4-1 shows the high-level procedure where the floor controller allows a participant to release the floor while other participants continue to talk simultaneously in a MCPTT session already established between the floor participants and the floor control server. Only three UEs involved in the session are shown for simplicity.

Pre-conditions:

1. The MCPTT group is configured to support multi-talker control and audio mixing by the network is applied.
2. MCPTT session is established between MCPTT clients (client A, client B, and client C) and the MCPTT server.
3. Participants A, B, and C have the permission to talk to all other participants, and the floor is granted to floor participants A, B, and C.

(not reproduced yet)

Figure 10.9.1.3.2.4-1: Floor release during an MCPTT session

Step 1.

Floor participants A, B and C are sending voice media over the established session.

Step 2.

User A stops talking and wants to stop sending voice media over the session.

Step 3.

Floor participant A sends a floor release message to the floor control server.

Step 4.

The floor control server accepts the floor release from floor participant A and sends a multi-talker floor release message to floor participant B and floor participant C.

Step 4a.

The users of floor participant B and floor participant C may be notified that floor participant A has released the floor.

Step 5.

Floor participants B and C continue sending voice media over the established session.

10.9.1.3.3  Queue position during an MCPTT session  Word‑p. 184

Figure 10.9.1.3.3-1 shows the high level procedure that the floor control is conducted for the MCPTT session already established between MCPTT clients (with floor granted to floor participant B) and server (with an override based on priority at floor control server). Only two UEs involved in the session are shown for the simplicity.

(not reproduced yet)

Figure 10.9.1.3.3-1: Queue status during an MCPTT session

Step 1.

It is assumed that floor participant B has been given a floor granted and is transmitting voice media. There are several other floor participants (including floor participating A) requesting floor which get queued at the floor control server.

Step 2.

Floor participant A would like to know its current position in the floor request queue.

Step 3.

Floor participant A sends a queue position request message to the floor control server.

Step 4.

Floor control server determines the current queue position of floor participant A from the floor request queue.

Step 5.

Floor control server responds with the current position in queue position info message.

Step 6.

User at floor participant A is informed about the current queue position.

10.9.1.3.4  Floor request cancellation from the floor request queue  Word‑p. 185

10.9.1.3.4.1  Floor request cancellation from the queue - MCPTT user initiated

Figure 10.9.1.3.4.1-1 illustrates the procedure for floor request cancellation from the floor queue initiated by the MCPTT user. The MCPTT user may be an authorized user who has rights to cancel the floor requests of other MCPTT users, whose floor requests are in floor control queue.

Pre-conditions:

• It is assumed that floor participant B has been granted the floor and is transmitting voice media. There are several other floor participants (including floor participant A and floor participant C) requesting the floor which have been queued at the floor control server.

(not reproduced yet)

Figure 10.9.1.3.4.1-1: Floor request cancellation from queue initiated by MCPTT user

Step 1.

The floor participant A wants to remove the floor request from the floor request queue. If floor participant A is an authorized MCPTT user with the rights to cancel another MCPTT user's floor request, the authorized MCPTT user may request floor request cancellation for one or more floor participants, whose floor request needs to be removed from the floor queue.

Step 2.

The floor participant A sends a floor request cancel (initiating MCPTT ID) message to the floor control server. If the floor participant A wants to remove the floor request(s) of other participant(s), the target participant(s)' MCPTT ID should be included in this message.

Step 3.

The floor control server shall check whether the requesting floor participant has authorization to cancel the floor request(s). If authorized, the floor request(s) will be removed from the floor request queue. When current transmission is completed, floor control server will process the floor request from the updated floor request queue.

Step 4.

If the floor request cancel in step 2 is sent by an authorized user (e.g., dispatcher) to cancel the floor request(s) of other participant(s) from the floor request queue, the floor request cancel notify message is sent to the floor participant whose floor request was cancelled from the floor queue. The floor request cancel notify message is also sent to the authorized user (not shown in figure) if the floor request cancel in step 2 is sent by the floor participant A is an initiating MCPTT user.

Step 5.

The floor control server provides a floor request cancel response to the floor participant A when the floor cancellation is completed. Optionally, the new queue position information may be notified to the floor participants whose floor requests are in the floor request queue (not shown in the figure).

10.9.1.3.4.2  Floor request cancellation from the queue - floor control server initiated  Word‑p. 186

Figure 10.9.1.3.4.2-1 illustrates the procedure for floor request cancellation from the queue initiated by the floor control server. Only three UEs involved in the session are shown for the simplicity.

Pre-conditions:

• MCPTT session is established between MCPTT clients (client A, client B, client C and client D) and MCPTT server.
• It is assumed that floor participant B (not shown in figure) has been granted the floor and is transmitting voice media. There are several other floor participants (including floor participant A and participant C) requesting the floor which have been queued at the floor control server.
• The user at MCPTT client D is an authorized user (e.g., dispatcher) allowed to remove a floor request of other MCPTT users from the floor queue and can receive notifications about another user when their floor request is queued, when their queued floor request is rejected and when their queued floor request is removed from the queue.

(not reproduced yet)

Figure 10.9.1.3.4.2-1: Floor request cancellation from queue initiated by floor control server

Step 1.

The floor control server removes the floor request from the floor request queue based on policy. e.g., expiration of a timer. In the case when floor control server receives repeated floor requests from a floor participant while the floor is occupied, the new floor request is accepted and added into the floor queue and the existing/former floor request is removed from the floor queue or the new floor request is rejected and the existing/former floor request of this floor participant is retained in the floor request queue.

Step 2.

The floor control server sends a floor request cancel notify to the floor participant(s) whose floor request is removed from the floor request queue.

Step 3.

Optionally, the newly queue position information is notified to the other floor participants whose floor requests are queued.

Step 4.

If the floor request cancel in step 2 is sent by floor control server for the user whose floor request is in the floor request queue, the floor control server may send the floor cancel notify to the floor participant D who is an authorized user.

10.9.1.4  Floor control involving groups from multiple MCPTT systems  Word‑p. 187

10.9.1.4.1  Partner MCPTT system routes all floor control messages to primary MCPTT system's floor control server

The MCPTT users belonging to different groups in multiple MCPTT systems will participate in MCPTT media services (group communication, private calls, etc.) in scenarios like group hierarchies and temporary groups formed by group regroup. In this service delivery model involving multiple groups from different MCPTT systems, the floor control arbitration resides with the primary MCPTT system. This is determined in the group call setup stage. The MCPTT users of groups involved in the call session will transmit their floor control messages through the partner MCPTT systems to which they belong. In this scenario, the partner MCPTT systems request the floor control for its MCPTT user(s) from the floor control server of the primary MCPTT system. The protocol used for media plane signalling is non-SIP like RTCP.

Figure 10.9.1.4.1-1 describes the procedure for floor control involving groups from multiple MCPTT systems.

Pre-conditions:

1. The security aspects of sharing the user information between primary and partner MCPTT systems shall be governed as per the service provider agreement between them. In this case, we consider the partner MCPTT system does not share all information of their users' to the primary MCPTT system (public information would still need to be shared).
2. The group 1 is hosted by primary MCPTT system and group 2 and 3 are hosted by the partner MCPTT system.
3. The floor participant 1 corresponds to the MCPTT user of group 1. The floor participant 2 corresponds to the MCPTT user of group 2. The floor participant 3 corresponds to the MCPTT user of group 3. The floor control server 1 belongs to primary MCPTT system. The floor control server 2 belongs to partner MCPTT system.
4. The floor control server 1 is the floor arbitrator of the MCPTT group call. The floor control server 2 routes all floor control messages to and from the floor participants 2 and 3 and then floor control server 1.

(not reproduced yet)

Figure 10.9.1.4.1-1: Floor control (partner MCPTT system forwarding) involving groups from multiple MCPTT systems

Step 1.

An MCPTT group call involving group1, group 2 and group 3 is setup and active.

Step 2.

The MCPTT users want to talk.

Step 3.

The floor participants initiate a floor request to the floor control server of their corresponding MCPTT systems. (The requests may or may not occur at the same time).

Step 4.

If only one floor request is received, or floor control server 2 handles the floor request sequentially, there is no arbitration performed and the corresponding floor request is forwarded to the floor control server 1. If the floor control server 2 receives multiple floor requests at the same time or during an interval, then it forwards the floor requests to the floor control server 1 (floor arbitrator for the MCPTT group call). As the floor participant information shall not be exposed, the floor priority related information or/and group information to be used by floor control server 1 should be included in the forwarded request.

Step 5.

The floor control server 1 performs floor arbitration for the MCPTT group call and determines the floor request to be accepted.

Step 6.

If the floor request from floor participant 2 of the partner MCPTT system is accepted, a floor granted is sent with permission to talk. The floor control messages from floor control server 1 are routed to floor participant 2 via the floor control server 2.

Step 7.

When the floor control server 2 (partner) receives the floor granted, the floor control server 2 sends a floor granted message on to floor participant 2.

Step 8.

The floor granted shall cause the user of the UE where the floor participant 2 is located to be notified.

Step 9.

The primary floor control server 1 may (9a.1) send a floor rejected message, or (9b.1) send a queue position info message for each non-granted received floor requests forwarded from the floor control server 2 (partner). When the floor control server 2 (partner) receives the floor rejected message, then the floor control server 2 (partner) (9a.2) sends a floor rejected message to the appropriate floor participant. When the floor control server 2 (partner) receives the queue position info, then the floor control server 2 (partner) (9b.2) sends a queue position info message to the appropriate floor participant.

Step 10a.1.

If floor control server 1 rejects the floor request from floor participant 1, then a floor reject message is sent.

Step 10a.2.

Upon this being received the user of the UE where floor participant 1 is located may be notified.

Step 10b.1.

If floor control server 1 supports floor queue, queue position info message is sent to the floor participant 1.

Step 10b.2.

Upon this being received the user of the UE where floor participant 1 is located may be notified.

Step 11.

Since the floor is granted to floor participant 2 of the partner MCPTT system, then a floor taken is sent to all other floor participants ((11a) floor participant 1 and (11b.1) to floor control server 2 (partner) for forwarding to (11b.2) floor participant 3.

Step 12.

The receipt of the floor taken may be used to inform the users of the UEs where the floor participant entity 1 and floor participant 3 are located to be notified.

Step 13.

Upon successful floor granted, the group call media transmission occurs.

10.9.1.4.2  Partner MCPTT system performs filtering of floor control messages entering and leaving the partner MCPTT system  Word‑p. 190

The MCPTT users belonging to different groups in multiple MCPTT systems will participate in MCPTT media services (group communication, private calls, etc.) in scenarios like group hierarchies and temporary groups formed by group regroup. In this service delivery model involving multiple groups from different MCPTT systems, the floor control arbitration resides with the primary MCPTT system. This is determined in the group call setup stage. The MCPTT users of groups involved in the call session will transmit their floor control messages through the partner MCPTT systems to which they belong. In this scenario, the partner MCPTT system filters its MCPTT users' floor requests before communicating with the floor control server of the primary MCPTT system. The protocol used for media plane signalling is non-SIP like RTCP.

Figure 10.9.1.4.2-1 describes the procedure for floor control involving groups from multiple MCPTT systems.

Pre-conditions:

1. The security aspects of sharing the user information between primary and partner MCPTT systems shall be governed as per the service provider agreement between them. In this case, we consider the partner MCPTT system does not share all information of their users to the primary MCPTT system (public information would still need to be shared).
2. The group 1 is hosted by primary MCPTT system and group 2 and 3 are hosted by the partner MCPTT system.
3. The floor participant 1 corresponds to the MCPTT user of group 1. The floor participant 2 corresponds to the MCPTT user of group 2. The floor participant 3 corresponds to the MCPTT user of group 3. The floor control server 1 belongs to primary MCPTT system. The floor control server 2 belongs to partner MCPTT system.
4. The floor control server 1 is the floor arbitrator of the MCPTT group call. The floor control server 2 does floor control filtering with its floor participants 2 and 3 before communicating with the floor control server 1.

(not reproduced yet)

Figure 10.9.1.4.2-1: Floor control (filtering by partner MCPTT system) involving groups from multiple MCPTT systems

Step 1.

An MCPTT group call involving group 1, group 2 and group 3 is setup and active.

Step 2.

The MCPTT users want to talk

Step 3.

The floor participants initiate a floor request to the floor control server of their corresponding MCPTT systems. (The requests may or may not occur at the same time).

Step 4.

Floor control server 2 receives a floor request from floor participant 2 and from participant 3 at the same time or during an interval, then the floor control server 2 (partner) performs filtering of the floor requests received according to its local policy such as priority or order based on its own users, and forwards the selected floor request (floor participant 2) to the floor control server 1 (floor arbitrator for the MCPTT group call). As the floor participant information shall not be exposed, the priority related information or/and group information to be used by floor control server 1 should be included in the forwarded request.

Step 5.

The floor control server 2 (partner) may send a floor rejected towards the floor participant 3, since its floor request was not chosen to be forwarded on to the floor control server 1.

Step 6.

The user on the UE where the floor participant 3 is located may be notified of the rejection.

Step 7.

The floor control server 2 (partner) forwards the floor request of floor participant 2 to the floor server 1.

Step 8.

The floor control server 1 performs floor arbitration for the MCPTT group call and determines the floor request to be accepted. The floor request message from floor participant 2 of the partner system is accepted by the floor control server 1 (arbitrator) and is determined that a floor granted is sent with permission to talk.

Step 9.

The floor granted message from floor control server 1 is routed to floor participant 2 via the floor control server 2 (partner).

Step 10.

Since floor participant 1 sent a floor request but was not granted,

Step 10a.1.

the primary floor control server may send a floor rejected message to floor participant 1.

Step 10a.2.

The user of the UE where the floor participant 1 is located may be notified of the rejection.

Step 10b.1.

if floor control server supports floor queuing, send a queue position info message to floor participant 1.

Step 10b.2.

The user of the UE where the floor participant 1 is located may be notified of the queue position.

Step 11.

A floor taken message is sent to floor participant 1.

Step 12.

The user of the UE where the floor participant 1 is located may be notified.

Step 13.

Since the floor control server 2 (partner) filters floor requests, when the floor control server 2 (partner) receives the floor granted for floor participant 2 from floor control server 1, the floor control server 2 (partner) needs to use the information received to generate the floor taken which will be sent to all other floor participants (floor control participant 3).

Step 14.

The floor control server 2 (partner) sends a floor granted message to floor participant 2.

Step 15.

The user of the UE where the floor participant 2 is located is notified.

Step 16.

The floor control server 2 (partner) sends a floor taken message to all other floor participants (floor participant 3).

Step 17.

The user of the UE where the floor participant 1 is located may be notified.

Step 18.

Upon successful floor grant, the group call media transmission occurs.

10.9.1.5  Floor control for audio cut-in enabled group  Word‑p. 193

Figure 10.9.1.5-1 shows the procedure for audio cut-in for the session already established between the floor participants from same MCPTT service provider. Floor participants may request the floor while Floor Participant B is transmitting voice media. Floor control server grants floor immediately to the floor request received.

Pre-conditions:

• The floor control server has been configured to support audio cut-in.
• It is assumed that the floor has been granted to floor participant B and floor participant B is transmitting voice media. There are several other floor participants (including floor participant A).

(not reproduced yet)

Figure 10.9.1.5-1: Floor control for audio cut-in enabled group in single MCPTT system

Step 1.

Floor participant B has been given floor and is transmitting voice media.

Step 2.

Floor participant A wants to send voice media over the session.

Step 3.

Floor participant A sends a floor request message to the floor control server.

Step 4.

The floor control server applies the audio cut-in policy with floor queue disabled i.e., floor is immediately granted to the floor participant A, and revoked from floor participant B.

Step 5.

The floor control server sends a floor revoked message to floor participant B stopping the voice media transmission from floor participant B.

Step 6.

The user of floor participant B may be notified that the floor is revoked.

Step 7.

The Floor control server sends a floor granted message to floor participant A, and sends a floor taken message to floor participant B with information of who is granted the floor. The floor control server may limit the time a user talks (holds the floor).

Step 8.

The user of floor participant A may be notified that he is granted the floor. Similarly, the user of floor participant B may be notified who is granted the floor.

Step 9.

Floor participant A starts sending voice media over the session established.

Step 10.

Now floor participant B may want the floor to start sending voice media.

Step 11.

Floor participant B sends a floor request message to floor control server.

Step 12.

The floor control server applies the audio cut-in policy with floor queue disabled.

Step 13.

The floor control server sends a floor revoked message to floor participant A stopping the voice media transmission from floor participant A.

Step 14.

The user of floor participant A may be notified that the floor is revoked.

Step 15.

The Floor control server sends a floor granted message to floor participant B, and sends a floor taken message to floor participant A with information of who is granted the floor. The floor control server may limit the time a user talks (holds the floor).

Step 16.

The user of floor participant B may be notified that he is granted the floor. Similarly, the user of floor participant A may be notified who is granted the floor.

Step 17.

Floor participant B starts sending voice media over the session established.

10.9.1.6  Unicast media stop and resume requests |R15|  Word‑p. 195

Figure 10.9.1.6-1 shows the procedure for a floor participant to indicate to the floor control server that the unicast media flow of an active MCPTT group call can be stopped.

Pre-condition:

1. An MCPTT session is established between MCPTT client A and MCPTT server for an MCPTT group call. Other participants to the call are not shown in the Figure for simplicity.
2. The floor control is established between the floor participant and the floor control server.

(not reproduced yet)

Figure 10.9.1.6-1: Unicast media stop request during an MCPTT session

Step 1.

Another floor participant has requested and has been granted the floor. The floor control server sends a floor taken message to floor participant A. The floor taken message may include an identifier of the associated media flow.

Step 2.

Floor control server sends the voice media flow to floor participant A over unicast.

Step 3.

Floor participant A gets the information, e.g. from the user, that media for the call is not needed.

Step 4.

Floor participant A sends a unicast media stop request to floor control server, identifying the media flow to be stopped.

Step 5.

Floor control server stops sending that unicast media flow to floor participant A. Associated bearer resources may be de-allocated by the MCPTT server.

Figure 10.9.1.6-2 shows the procedure for a floor participant to request from the floor control server that the unicast media flow of an active MCPTT group call be restarted.

Pre-condition:

1. An MCPTT session is established between MCPTT client A and MCPTT server for an MCPTT group call. Other participants to the call are not shown in the Figure for simplicity
2. The floor control is established between the floor participant and the floor control server.
3. Floor participant A has previously indicated to the floor control server that unicast media flow for that call should be stopped, using the procedure described in Figure 10.9.1.6-1.

(not reproduced yet)

Figure 10.9.1.6-2: Unicast media resume request during an MCPTT session

Step 1.

Another floor participant has requested and has been granted the floor. The floor control server sends a floor taken message to floor participant A. The floor taken message may include an identifier of the associated media flow.

Step 2.

Floor participant A gets the information, e.g. from the user, that media for the call is needed again.

Step 3.

Floor participant A sends a unicast media resume request to floor control server, identifying the media flow to be re-started.

Step 4.

Floor control server starts sending that unicast media flow to floor participant A. This may need new bearer resources to be allocated.