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.
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.
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).
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.
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.
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.