Tech-invite  3GPPspace  IETFspace
21  22  23  24  25  26  27  28  29  31  32  33  34  35  36  37  38  4‑5x

Content for  TS 23.379  Word version:  19.3.0

Top   Top   Up   Prev   Next
1…   7…   7.4…   10…   10.5…   10.6…   10.6.2.2.13…   10.6.2.2.24…   10.6.2.3…   10.6.2.3.1.2…   10.6.2.3.2…   10.6.2.4…   10.6.2.4.3…   10.6.2.5…   10.6.2.5.2.3…   10.6.2.6…   10.6.2.6.2…   10.6.2.7…   10.6.2.10…   10.6.3…   10.7…   10.7.2.2…   10.7.2.3…   10.7.3…   10.7.4…   10.7.5…   10.7.5.2.3a…   10.7.6…   10.7.6.2.3…   10.9…   10.9.1.3…   10.9.1.3.2…   10.9.1.3.3…   10.9.1.4…   10.9.1.5…   10.9.2…   10.9.2.6…   10.10…   10.12…   10.14…   10.15…   10.19…   10.19.2.11…   10.19.3…   10.19.3.1.4…   10.19.3.2…   10.19.3.2.4…   10.19.3.2.6…   A…   A.4…   B… 
10.9.1.3 Floor control with a single floor control server  10.9.1.3.1 Floor request, floor granted and floor taken during an MCPTT session  10.9.1.3.1a Floor request, floor granted and multi-talker floor taken during an MCPTT session enhanced with multi-talker control 
...

 

10.9.1.3  Floor control with a single floor control server  p. 168

10.9.1.3.1  Floor request, floor granted and floor taken during an MCPTT session  p. 168
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.
Reproduction of 3GPP TS 23.379, Fig. 10.9.1.3.1-1: Floor request, floor granted, floor taken during an MCPTT session
Figure 10.9.1.3.1-1: Floor request, floor granted, floor taken during an MCPTT session
Up
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.
Up
10.9.1.3.1a  Floor request, floor granted and multi-talker floor taken during an MCPTT session enhanced with multi-talker control |R15|  p. 170
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.
Reproduction of 3GPP TS 23.379, Fig. 10.9.1.3.1a-1: Floor request, floor granted and multi-talker floor taken during an MCPTT session
Figure 10.9.1.3.1a-1: Floor request, floor granted and multi-talker floor taken during an MCPTT session
Up
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.
Up

Up   Top   ToC