Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 23.379  Word version:  19.3.0

Top   Top   Up   Prev   Next

 

10.9.1.3.2  Floor overridep. 172
10.9.1.3.2.1  Floor override using floor revoked (also floor rejected) during an MCPTT sessionp. 172
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.
Reproduction of 3GPP TS 23.379, Fig. 10.9.1.3.2.1-1: Floor override using floor revoked (also floor rejected) during an MCPTT session
Up
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.
Up
10.9.1.3.2.2  Floor override without using floor revoked during an MCPTT sessionp. 173
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.
Reproduction of 3GPP TS 23.379, Fig. 10.9.1.3.2.2-1: Floor override (overridden continues to transmit) during an MCPTT session
Up
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.
Up
10.9.1.3.2.3  Floor override using floor revoked (also floor rejected) during an MCPTT session enhanced with multi-talker control p. 173
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.
Reproduction of 3GPP TS 23.379, Fig. 10.9.1.3.2.3-1: Floor override using floor revoked (also floor rejected) during an MCPTT session
Up
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.
Up
10.9.1.3.2.4  Floor release during an MCPTT session enhanced with multi-talker control p. 175
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.
Reproduction of 3GPP TS 23.379, Fig. 10.9.1.3.2.4-1: Floor release during an MCPTT session
Up
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.
Up

Up   Top   ToC