Content for TS 23.379 Word version: 17.5.0
1…
4…
7…
7.4…
10…
10.5…
10.6…
10.6.2.2.18…
10.6.2.2.34…
10.6.2.3…
10.6.2.3.2…
10.6.2.4…
10.6.2.5…
10.6.2.6…
10.6.2.7…
10.6.2.9…
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.6…
10.9…
10.9.1.3…
10.9.2…
10.10…
10.14…
A…
A.4…
B…
10.9.2 Floor control for off-network MCPTT service
10.9.2.1 General
10.9.2.2 Information flows for floor control for off-network
10.9.2.3 Floor control during silence
10.9.2.4 Simultaneous floor requests
10.9.2.5 Floor request during speaking with queue
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 Floor control for off-network MCPTT service Word‑p. 197
10.9.2.1 General
The procedures defined in this subclause provide floor control to MCPTT UEs in off-network operation. The procedures apply to both private calls and group calls.
In off-network, floor control is performed by using floor control messages among the MCPTT clients without centralized MCPTT server. The MCPTT client can transmit voice packets once it is granted the right to speak, either locally in the UE or by reception of a floor granted message from another MCPTT client.
In off-network, the MCPTT client currently speaking performs the temporary floor arbitrator during speaking since there is no centralized MCPTT floor control server. The floor arbitrator controls the floor whether or not queue is supported, and when floor is requested with override. If queue is supported, the MCPTT client performing floor arbitrator grants the right to speak to the next speaker and transfers the floor arbitrator role after completing the voice transfer and releasing the floor. For group calls, the floor arbitrator also transfers the floor control queue when granting the floor. The next MCPTT client receiving the right to speak becomes the new floor arbitrator and, for group calls, has the floor control queue.
For group calls, the floor control message is delivered in multicast based communication and can be monitored by all the members within the MCPTT group.
The following information flows apply among MCPTT clients.
-
Floor request (from the floor participants to the floor arbitrator): used to request a floor for voice transfer.
-
Floor release (from the floor arbitrator to the floor participants): used to inform that the voice transfer is completed and the floor is released.
-
Floor granted (from the floor arbitrator to a floor participant): used to indicate that the request for floor is granted, that voice transfer is possible and the current queue list.
-
Queue position request (from the floor participant to the floor arbitrator): used to request the position in the floor request queue.
-
Queue position info (from the floor arbitrator to the floor participant): used to indicate the floor request is queued and the current queue status.
-
Floor rejected (from the floor arbitrator to the floor participant): used to indicate that a request for the floor is rejected.
-
Floor taken (from the floor arbitrator to the floor participant): used to indicate the floor is granted to another MCPTT user.
10.9.2.2 Information flows for floor control for off-network Word‑p. 198
10.9.2.2.1 General
For floor control for off-network, the information flows defined under subclause 10.9.1.2 apply unless it is explicitly defined under this subclause.
10.9.2.2.2 Floor granted
Table 10.9.2.2.2-1 describes the information flow floor granted, from the floor participant to the floor participant, which is used to indicate that a request for floor is granted and media transfer is possible.
Information Element
Status
Description
MCPTT ID M Requester identity Duration M The time for which the granted party is allowed to transmit Source identifier O Identifies the communication, e.g. by identifying the media flow within a media multiplex, present only in case of media multiplexing Acknowledgement required O Indicates if acknowledgement from the floor participant is required
10.9.2.3 Floor control during silence
10.9.2.3.1 Successful floor taken (No floor contention)
If a floor arbitrator still exists, the expected behaviour for floor requests during periods of silence is described in subclause 10.9.2.5 and subclause 10.9.2.6 (with the exception that no media was being generated prior to the floor request).
If a floor arbitrator does not exist, Figure 10.9.2.3.1-1 shows the successful high level floor control procedure during periods when there is no detectable talker.
Pre-conditions:
-
An off-network group call had been established and all MCPTT clients have the call parameters. No participant is currently talking and no floor arbitrator is identified.
(not reproduced yet)
Figure 10.9.2.3.1-1: Successful floor taken flow (No floor contention)
Step 1.
The MCPTT client 1 sends the floor request message to the MCPTT group.
Step 2.
The MCPTT client 1 does not detect any floor contention. Floor contention occurs when multiple floor requests may exist simultaneously.
Step 3.
The MCPTT client 1 sends the floor taken message to the MCPTT group.
Step 4.
The user gets a notification that the floor request was successful (the floor has been granted).
Step 5.
The MCPTT client 1 begins voice transmission.
10.9.2.4 Simultaneous floor requests Word‑p. 199
If a floor arbitrator does not exist, Figure 10.9.2.4.1-1 shows the expected behaviour in case of simultaneous floor requests are generated when there is no detectable talker.
Pre-conditions:
-
An off-network group call is established and all MCPTT clients have the call parameters. No participant is currently talking and no floor arbitrator is identified.
-
MCPTT client 1 has higher priority than MCPTT client 2.
(not reproduced yet)
Figure 10.9.2.4.1-1: Simultaneous floor requests
Step 1a.
The MCPTT client 1 sends the floor request message to the MCPTT group.
Step 1b.
The MCPTT client 2 sends the floor request message to the MCPTT group.
Step 2.
On receiving a floor request message, while waiting for a response to the sent floor request message, the MCPTT client compares its floor priority with the floor priority indicated in the received floor request message.
Step 3.
On determining that it has higher floor priority than the received floor request message(s), and no response to the sent floor request message is received, the MCPTT client 1 sends the floor taken message to the MCPTT group.
Step 4.
The user at MCPTT client 1 gets notification that the floor request was successful (the floor has been granted).
10.9.2.5 Floor request during speaking with queue Word‑p. 200
Figure 10.9.2.5-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. In the case, MCPTT clients should support queue function. The current speaking MCPTT client acting as the floor arbitrator put the floor request into the queue list 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.
(not reproduced yet)
Figure 10.9.2.5-1: Floor request during speaking with queue
Step 1.
MCPTT client 1 is transmitting voice media to the MCPTT group.
Step 2.
MCPTT client 2 sends the floor request message to the MCPTT group.
Step 3.
MCPTT client 1 acting as the floor arbitrator put the floor request of MCPTT client 2 into the queue list.
Step 4.
MCPTT client 1 sends the queue position info message with the queuing status regarding the floor request of MCPTT client 2 in order to inform the floor request is queued.
Step 5.
MCPTT client 1 sends the floor granted message to the MCPTT group when releasing the floor. The message contains the MCPTT ID to be granted to send the voice media, and queue list, if any. MCPTT client 1 may include the maximum duration that MCPTT client 2 transmits in the floor granted message.
Step 6.
MCPTT client 2 sends the voice media when receiving the floor granted message and being granted as next speaker in the floor granted message. In addition, MCPTT client 2 becomes the floor arbitrator.
10.9.2.6 Floor request during speaking without queue Word‑p. 201
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.
(not reproduced yet)
Figure 10.9.2.6-1: Floor request during speaking without queue
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.
10.9.2.7 Override Word‑p. 202
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.
(not reproduced yet)
Figure 10.9.2.7-1: Floor request with override authorization
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.
10.9.2.8 Floor queue status Word‑p. 203
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.
(not reproduced yet)
Figure 10.9.2.8-1: Queue status request
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.
10.9.2.1 General
The procedures defined in this subclause provide floor control to MCPTT UEs in off-network operation. The procedures apply to both private calls and group calls.
In off-network, floor control is performed by using floor control messages among the MCPTT clients without centralized MCPTT server. The MCPTT client can transmit voice packets once it is granted the right to speak, either locally in the UE or by reception of a floor granted message from another MCPTT client.
In off-network, the MCPTT client currently speaking performs the temporary floor arbitrator during speaking since there is no centralized MCPTT floor control server. The floor arbitrator controls the floor whether or not queue is supported, and when floor is requested with override. If queue is supported, the MCPTT client performing floor arbitrator grants the right to speak to the next speaker and transfers the floor arbitrator role after completing the voice transfer and releasing the floor. For group calls, the floor arbitrator also transfers the floor control queue when granting the floor. The next MCPTT client receiving the right to speak becomes the new floor arbitrator and, for group calls, has the floor control queue.
For group calls, the floor control message is delivered in multicast based communication and can be monitored by all the members within the MCPTT group.
The following information flows apply among MCPTT clients.
- Floor request (from the floor participants to the floor arbitrator): used to request a floor for voice transfer.
- Floor release (from the floor arbitrator to the floor participants): used to inform that the voice transfer is completed and the floor is released.
- Floor granted (from the floor arbitrator to a floor participant): used to indicate that the request for floor is granted, that voice transfer is possible and the current queue list.
- Queue position request (from the floor participant to the floor arbitrator): used to request the position in the floor request queue.
- Queue position info (from the floor arbitrator to the floor participant): used to indicate the floor request is queued and the current queue status.
- Floor rejected (from the floor arbitrator to the floor participant): used to indicate that a request for the floor is rejected.
- Floor taken (from the floor arbitrator to the floor participant): used to indicate the floor is granted to another MCPTT user.
10.9.2.2 Information flows for floor control for off-network Word‑p. 198
10.9.2.2.1 General
For floor control for off-network, the information flows defined under subclause 10.9.1.2 apply unless it is explicitly defined under this subclause.
10.9.2.2.2 Floor granted
Table 10.9.2.2.2-1 describes the information flow floor granted, from the floor participant to the floor participant, which is used to indicate that a request for floor is granted and media transfer is possible.
Information Element
Status
Description
MCPTT ID M Requester identity Duration M The time for which the granted party is allowed to transmit Source identifier O Identifies the communication, e.g. by identifying the media flow within a media multiplex, present only in case of media multiplexing Acknowledgement required O Indicates if acknowledgement from the floor participant is required
10.9.2.3 Floor control during silence
10.9.2.3.1 Successful floor taken (No floor contention)
If a floor arbitrator still exists, the expected behaviour for floor requests during periods of silence is described in subclause 10.9.2.5 and subclause 10.9.2.6 (with the exception that no media was being generated prior to the floor request).
If a floor arbitrator does not exist, Figure 10.9.2.3.1-1 shows the successful high level floor control procedure during periods when there is no detectable talker.
Pre-conditions:
-
An off-network group call had been established and all MCPTT clients have the call parameters. No participant is currently talking and no floor arbitrator is identified.
(not reproduced yet)
Figure 10.9.2.3.1-1: Successful floor taken flow (No floor contention)
Step 1.
The MCPTT client 1 sends the floor request message to the MCPTT group.
Step 2.
The MCPTT client 1 does not detect any floor contention. Floor contention occurs when multiple floor requests may exist simultaneously.
Step 3.
The MCPTT client 1 sends the floor taken message to the MCPTT group.
Step 4.
The user gets a notification that the floor request was successful (the floor has been granted).
Step 5.
The MCPTT client 1 begins voice transmission.
10.9.2.4 Simultaneous floor requests Word‑p. 199
If a floor arbitrator does not exist, Figure 10.9.2.4.1-1 shows the expected behaviour in case of simultaneous floor requests are generated when there is no detectable talker.
Pre-conditions:
-
An off-network group call is established and all MCPTT clients have the call parameters. No participant is currently talking and no floor arbitrator is identified.
-
MCPTT client 1 has higher priority than MCPTT client 2.
(not reproduced yet)
Figure 10.9.2.4.1-1: Simultaneous floor requests
Step 1a.
The MCPTT client 1 sends the floor request message to the MCPTT group.
Step 1b.
The MCPTT client 2 sends the floor request message to the MCPTT group.
Step 2.
On receiving a floor request message, while waiting for a response to the sent floor request message, the MCPTT client compares its floor priority with the floor priority indicated in the received floor request message.
Step 3.
On determining that it has higher floor priority than the received floor request message(s), and no response to the sent floor request message is received, the MCPTT client 1 sends the floor taken message to the MCPTT group.
Step 4.
The user at MCPTT client 1 gets notification that the floor request was successful (the floor has been granted).
10.9.2.5 Floor request during speaking with queue Word‑p. 200
Figure 10.9.2.5-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. In the case, MCPTT clients should support queue function. The current speaking MCPTT client acting as the floor arbitrator put the floor request into the queue list 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.
(not reproduced yet)
Figure 10.9.2.5-1: Floor request during speaking with queue
Step 1.
MCPTT client 1 is transmitting voice media to the MCPTT group.
Step 2.
MCPTT client 2 sends the floor request message to the MCPTT group.
Step 3.
MCPTT client 1 acting as the floor arbitrator put the floor request of MCPTT client 2 into the queue list.
Step 4.
MCPTT client 1 sends the queue position info message with the queuing status regarding the floor request of MCPTT client 2 in order to inform the floor request is queued.
Step 5.
MCPTT client 1 sends the floor granted message to the MCPTT group when releasing the floor. The message contains the MCPTT ID to be granted to send the voice media, and queue list, if any. MCPTT client 1 may include the maximum duration that MCPTT client 2 transmits in the floor granted message.
Step 6.
MCPTT client 2 sends the voice media when receiving the floor granted message and being granted as next speaker in the floor granted message. In addition, MCPTT client 2 becomes the floor arbitrator.
10.9.2.6 Floor request during speaking without queue Word‑p. 201
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.
(not reproduced yet)
Figure 10.9.2.6-1: Floor request during speaking without queue
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.
10.9.2.7 Override Word‑p. 202
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.
(not reproduced yet)
Figure 10.9.2.7-1: Floor request with override authorization
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.
10.9.2.8 Floor queue status Word‑p. 203
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.
(not reproduced yet)
Figure 10.9.2.8-1: Queue status request
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.
10.9.2.2.1 General
For floor control for off-network, the information flows defined under subclause 10.9.1.2 apply unless it is explicitly defined under this subclause.
10.9.2.2.2 Floor granted
Table 10.9.2.2.2-1 describes the information flow floor granted, from the floor participant to the floor participant, which is used to indicate that a request for floor is granted and media transfer is possible.
| Information Element | Status | Description |
|---|---|---|
| MCPTT ID | M | Requester identity |
| Duration | M | The time for which the granted party is allowed to transmit |
| Source identifier | O | Identifies the communication, e.g. by identifying the media flow within a media multiplex, present only in case of media multiplexing |
| Acknowledgement required | O | Indicates if acknowledgement from the floor participant is required |
10.9.2.3.1 Successful floor taken (No floor contention)
If a floor arbitrator still exists, the expected behaviour for floor requests during periods of silence is described in subclause 10.9.2.5 and subclause 10.9.2.6 (with the exception that no media was being generated prior to the floor request).
If a floor arbitrator does not exist, Figure 10.9.2.3.1-1 shows the successful high level floor control procedure during periods when there is no detectable talker.
Pre-conditions:
- An off-network group call had been established and all MCPTT clients have the call parameters. No participant is currently talking and no floor arbitrator is identified.
(not reproduced yet)
Figure 10.9.2.3.1-1: Successful floor taken flow (No floor contention)
Step 1.
The MCPTT client 1 sends the floor request message to the MCPTT group.
Step 2.
The MCPTT client 1 does not detect any floor contention. Floor contention occurs when multiple floor requests may exist simultaneously.
Step 3.
The MCPTT client 1 sends the floor taken message to the MCPTT group.
Step 4.
The user gets a notification that the floor request was successful (the floor has been granted).
Step 5.
The MCPTT client 1 begins voice transmission.
If a floor arbitrator does not exist, Figure 10.9.2.4.1-1 shows the expected behaviour in case of simultaneous floor requests are generated when there is no detectable talker.
Pre-conditions:
- An off-network group call is established and all MCPTT clients have the call parameters. No participant is currently talking and no floor arbitrator is identified.
- MCPTT client 1 has higher priority than MCPTT client 2.
(not reproduced yet)
Figure 10.9.2.4.1-1: Simultaneous floor requests
Step 1a.
The MCPTT client 1 sends the floor request message to the MCPTT group.
Step 1b.
The MCPTT client 2 sends the floor request message to the MCPTT group.
Step 2.
On receiving a floor request message, while waiting for a response to the sent floor request message, the MCPTT client compares its floor priority with the floor priority indicated in the received floor request message.
Step 3.
On determining that it has higher floor priority than the received floor request message(s), and no response to the sent floor request message is received, the MCPTT client 1 sends the floor taken message to the MCPTT group.
Step 4.
The user at MCPTT client 1 gets notification that the floor request was successful (the floor has been granted).
10.9.2.5 Floor request during speaking with queue Word‑p. 200
Figure 10.9.2.5-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. In the case, MCPTT clients should support queue function. The current speaking MCPTT client acting as the floor arbitrator put the floor request into the queue list 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.
(not reproduced yet)
Figure 10.9.2.5-1: Floor request during speaking with queue
Step 1.
MCPTT client 1 is transmitting voice media to the MCPTT group.
Step 2.
MCPTT client 2 sends the floor request message to the MCPTT group.
Step 3.
MCPTT client 1 acting as the floor arbitrator put the floor request of MCPTT client 2 into the queue list.
Step 4.
MCPTT client 1 sends the queue position info message with the queuing status regarding the floor request of MCPTT client 2 in order to inform the floor request is queued.
Step 5.
MCPTT client 1 sends the floor granted message to the MCPTT group when releasing the floor. The message contains the MCPTT ID to be granted to send the voice media, and queue list, if any. MCPTT client 1 may include the maximum duration that MCPTT client 2 transmits in the floor granted message.
Step 6.
MCPTT client 2 sends the voice media when receiving the floor granted message and being granted as next speaker in the floor granted message. In addition, MCPTT client 2 becomes the floor arbitrator.
10.9.2.6 Floor request during speaking without queue Word‑p. 201
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.
(not reproduced yet)
Figure 10.9.2.6-1: Floor request during speaking without queue
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.
10.9.2.7 Override Word‑p. 202
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.
(not reproduced yet)
Figure 10.9.2.7-1: Floor request with override authorization
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.
10.9.2.8 Floor queue status Word‑p. 203
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.
(not reproduced yet)
Figure 10.9.2.8-1: Queue status request
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.
Step 1.
MCPTT client 1 is transmitting voice media to the MCPTT group.
Step 2.
MCPTT client 2 sends the floor request message to the MCPTT group.
Step 3.
MCPTT client 1 acting as the floor arbitrator put the floor request of MCPTT client 2 into the queue list.
Step 4.
MCPTT client 1 sends the queue position info message with the queuing status regarding the floor request of MCPTT client 2 in order to inform the floor request is queued.
Step 5.
MCPTT client 1 sends the floor granted message to the MCPTT group when releasing the floor. The message contains the MCPTT ID to be granted to send the voice media, and queue list, if any. MCPTT client 1 may include the maximum duration that MCPTT client 2 transmits in the floor granted message.
Step 6.
MCPTT client 2 sends the voice media when receiving the floor granted message and being granted as next speaker in the floor granted message. In addition, MCPTT client 2 becomes the floor arbitrator.
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.
(not reproduced yet)
Figure 10.9.2.6-1: Floor request during speaking without queue
Step 1.
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.
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.
10.9.2.7 Override Word‑p. 202
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.
(not reproduced yet)
Figure 10.9.2.7-1: Floor request with override authorization
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.
10.9.2.8 Floor queue status Word‑p. 203
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.
(not reproduced yet)
Figure 10.9.2.8-1: Queue status request
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.
- MCPTT client 1, who acts as the floor arbitrator, transmits the audio media to the MCPTT group.
Step 1.
MCPTT client 2 who has revoked the floor is the new floor arbitrator and transmits the audio media to the MCPTT group.
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.
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.
(not reproduced yet)
Figure 10.9.2.8-1: Queue status request
Step 1.
MCPTT client1 continues being the floor arbitrator and transmits the audio media to the MCPTT group.
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.
