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:
MCPTT session is established between MCPTT clients (client A, client B and client C) and MCPTT server.
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
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.
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.
Floor control server sends a floor taken message to the other floor participant (floor participant B) including information about who is granted the floor.
Floor control server sends a floor taken message to the other floor participant (floor participant C) including information about who is granted the floor.
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.
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.
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:
The MCPTT group is configured to support multi-talker control and audio mixing by the network is applied.
MCPTT session is established between MCPTT clients (client A, client B and client C) and MCPTT server.
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
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.
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.
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
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.
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.
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.
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.
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
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.
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.
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:
The MCPTT group is configured to support multi-talker control.
MCPTT session is established between MCPTT clients (client A, client B and client C) and MCPTT server.
The maximum number of simultaneous talkers is set to 2.
The floor priority of floor participant A is higher than of floor participant B.
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
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.
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.
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.
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.
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.
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:
The MCPTT group is configured to support multi-talker control and audio mixing by the network is applied.
MCPTT session is established between MCPTT clients (client A, client B, and client C) and the MCPTT server.
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
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.
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
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.
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
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.
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.
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.
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.
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).
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
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.
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.
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:
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).
The group 1 is hosted by primary MCPTT system and group 2 and 3 are hosted by the partner MCPTT system.
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.
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
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).
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.
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.
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.
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.
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.
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.
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:
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).
The group 1 is hosted by primary MCPTT system and group 2 and 3 are hosted by the partner MCPTT system.
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.
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
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).
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.
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.
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.
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).
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
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.
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).
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.
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).
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.
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:
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.
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
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.
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:
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
The floor control is established between the floor participant and the floor control server.
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
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.