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.1.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.2.6 Floor request during speaking without queue  10.9.2.7 Override  10.9.2.8 Floor queue status 
...

 

10.9.2.6  Floor request during speaking without queue  p. 197

Figure 10.9.2.6-1 shows the high level procedure that the floor control is conducted when the MCPTT off-network session is already established among MCPTT floor participants. In the case, MCPTT clients do not support queue function. The current speaking MCPTT client acting as the floor arbitrator controls the floor request when receiving the floor request from other MCPTT clients. This procedure happens while voice media is transmitting. In the flow, MCPTT client 1 transmits the voice media to the MCPTT group and acts as the floor arbitrator.
Reproduction of 3GPP TS 23.379, Fig. 10.9.2.6-1: Floor request during speaking without queue
Figure 10.9.2.6-1: Floor request during speaking without queue
Up
Step 1.
MCPTT client 2 sends the floor request message to the MCPTT group.
Step 2.
MCPTT client 1 acting as the floor arbitrator rejects the floor request from MCPTT client 2 if no queue function is supported and sends the floor rejected message to the MCPTT group.
Step 3.
MCPTT client 1 sends the floor release message to the MCPTT group when releasing the floor, in order to indicate that MCPTT client 1 finishes to send the voice media and releases the floor.
When the floor release message is transmitted, there are no voice media in the MCPTT group until an MCPTT client requests the floor as described in subclause 10.9.2.3.
Up

10.9.2.7  Override  p. 198

Figure 10.9.2.7-1 shows the high level procedure that the floor control is conducted when the MCPTT off-network session is already established among MCPTT floor participants and while voice media is transmitting. When the currently speaking MCPTT floor participant receives the floor request message from another floor participant who is authorized to revoke the active transmission (e.g. higher hierarchy), the current speaking MCPTT floor participant immediately stops sending the audio media and then grants the permission to that authorized floor participant.
Pre-condition:
  • MCPTT client 1, who acts as the floor arbitrator, transmits the audio media to the MCPTT group.
Reproduction of 3GPP TS 23.379, Fig. 10.9.2.7-1: Floor request with override authorization
Figure 10.9.2.7-1: Floor request with override authorization
Up
Step 1.
MCPTT client 2 sends the floor request message with override criteria (e.g., priority level) to the MCPTT group.
Step 2.
MCPTT client 1 acting as the floor arbitrator determines if the floor is to be revoked based on override criteria. If this is the case, MCPTT client 1 revokes its right of the floor and stops sending the voice media immediately.
Step 3.
MCPTT client 1 sends the floor granted message to the MCPTT group. The floor granted message contains the MCPTT ID to be granted, the floor and the floor control queue (if supported). MCPTT client 1 may also include the maximum duration that MCPTT client 2 can transmit voice in the floor granted message.
MCPTT client 2 who has revoked the floor is the new floor arbitrator and transmits the audio media to the MCPTT group.
Up

10.9.2.8  Floor queue status  p. 199

Figure 10.9.2.8-1 shows the high level procedure that the floor control is conducted when the MCPTT off-network session is already established among MCPTT floor participants and while voice media is transmitting. If the floor control queueing is supported by the floor control mechanism, the current speaking MCPTT group member who is acting as the floor arbitrator collects the information about the queue status based on the received request(s) from the MCPTT group participant(s). The current speaker can then share information about the queue status of the MCPTT floor participant upon request.
Pre-condition:
  • MCPTT client 1, who acts as the floor arbitrator, transmits the audio media to the MCPTT group.
Reproduction of 3GPP TS 23.379, Fig. 10.9.2.8-1: Queue status request
Figure 10.9.2.8-1: Queue status request
Up
Step 1.
MCPTT client 2 sends the queue position request message targeted to MCPTT client 1 i.e. the floor arbitrator by broadcasting the message to the MCPTT group to get its queue status.
Step 2.
Since the queue function is assumed to be supported in this call flow, MCPTT client 1 i.e. the floor arbitrator processes the queue position request to find out the status of MCPTT client 1 in the queue.
Step 3.
MCPTT client 1 constructs the queue position info message containing the MCPTT client 2's queue status and sends it toward MCPTT client 2 by broadcasting the message to the MCPTT group.
MCPTT client1 continues being the floor arbitrator and transmits the audio media to the MCPTT group.
Up

Up   Top   ToC