Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 23.379  Word version:  19.4.0

Top   Top   Up   Prev   Next

 

10.9.1.4  Floor control with multiple floor control serversp. 182

10.9.1.4.1  Partner MCPTT system routes all floor control messages to primary MCPTT system's floor control serverp. 182
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.
Reproduction of 3GPP TS 23.379, Fig. 10.9.1.4.1-1: Floor control (partner MCPTT system forwarding) involving groups from multiple MCPTT systems
Up
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.
Up
10.9.1.4.2  Partner MCPTT system performs filtering of floor control messages entering and leaving the partner MCPTT systemp. 185
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.
Reproduction of 3GPP TS 23.379, Fig. 10.9.1.4.2-1: Floor control (filtering by partner MCPTT system) involving groups from multiple MCPTT systems
Up
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.
Up

10.9.1.5  Floor control for audio cut-in enabled groupp. 188

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).
Reproduction of 3GPP TS 23.379, Fig. 10.9.1.5-1: Floor control for audio cut-in enabled group in single MCPTT system
Up
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.
Up

10.9.1.6  Unicast media stop and resume requests |R15|p. 190

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.
Reproduction of 3GPP TS 23.379, Fig. 10.9.1.6-1: Unicast media stop request during an MCPTT session
Up
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.
Reproduction of 3GPP TS 23.379, Fig. 10.9.1.6-2: Unicast media resume request during an MCPTT session
Up
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.
Up

Up   Top   ToC