Content for TS 23.180 Word version: 18.0.0
10.5.3 IOPS floor control (IP connectivity functionality)
10.5.3.1 General
10.5.3.2 Information flows
10.5.3.3 IOPS floor control during silence
...
...
10.5.3 IOPS floor control (IP connectivity functionality) p. 46
10.5.3.1 General p. 46
For MCPTT calls based on the IP connectivity functionality in the IOPS mode of operation, floor control is performed by using floor control messages among the MCPTT clients without a centralized MCPTT server. The MCPTT client can transmit voice packets over the IOPS MC connectivity function once it is granted the right to speak, either locally in the UE or by the reception of a floor granted message from another MCPTT client.
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 IOPS 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 IOPS group calls, has the floor control queue.
For IOPS group calls, the group session packets carrying the floor control messages can be transmitted by the IOPS MC connectivity function over MBMS transmissions and can be monitored by all the members from the target IOPS MCPTT group.
The following clauses specify the floor control procedures and information flows for IOPS private calls and IOPS group calls based on the IP connectivity functionality in the IOPS mode of operation.
10.5.3.2 Information flows p. 46
10.5.3.2.1 IOPS floor request p. 46
Table 10.5.3.2.1-1 describes the information flow for the IOPS floor request, from the floor participant to another floor participant, which is used to request the floor for media transfer. The packet(s) carrying the IOPS floor request are transmitted from the requesting MCPTT client to the IOPS MC connectivity function for distribution to the target MCPTT client.
| Information Element | Status | Description |
|---|---|---|
| IOPS MCPTT ID | M | Requester identity |
| Floor priority | M | Priority of the request |
10.5.3.2.2 IOPS floor taken p. 47
Table 10.5.3.2.2-1 describes the information flow for the IOPS floor taken, from the floor participant to the floor participant, which is used to indicate the floor is granted to an MCPTT user. The packet(s) carrying the IOPS floor taken are transmitted from the originating MCPTT client to the IOPS MC connectivity function for distribution to target MCPTT client.
| Information Element | Status | Description |
|---|---|---|
| IOPS MCPTT ID | M | Identity for the granted party |
| Acknowledgement required | O | Indicates if acknowledgement from the floor participant is required |
10.5.3.3 IOPS floor control during silence p. 47
If a floor arbitrator does not exist, Figure 10.5.3.3-1 shows the successful high level floor control procedure during periods when there is no detectable talker in an IOPS group call based on the IP connectivity functionality.
Pre-conditions:
- MCPTT user profile used for the IOPS mode of operation is pre-provisioned in the MCPTT UEs.
- MCPTT users have an active PDN connection to the IOPS MC connectivity function for the communication based on the IP connectivity functionality
- The IOPS MCPTT group ID and its associated IOPS group IP multicast address are pre-configured in the MCPTT clients (for the case of an IOPS group call)
- The IOPC MC connectivity function may have established an MBMS bearer and announced it to the MCPTT clients
- The MCPTT users are discovered by the IOPS MC connectivity function supporting the IP connectivity functionality.
- MCPTT clients has retrieved connectivity information from the target MCPTT user (for the case of an IOPS private call).
- An IOPS private call or IOPS group call based on the IP connectivity functionality has been established. No participant is currently talking (i.e. the floor is idle) and no floor arbitrator is identified.
Figure 10.5.3.3-1: Successful floor taken flow in an IOPS group call based on the IP connectivity functionality (no floor contention)
(⇒ copy of original 3GPP image)
(⇒ copy of original 3GPP image)
Step 1.
The MCPTT client 1 sends the IOPS floor request message to the target IOPS MCPTT group. The MCPTT client 1 transmits the group session packets carrying the IOPS floor request message to the IOPS MC connectivity function for distribution to the corresponding IOPS group IP multicast address.
Step 2.
The IOPS MC connectivity function determines that the received packets correspond to a group session targeting a specific IOPS MCPTT group. The IOPS MC connectivity function decides distributing the received group session packets to the target MCPTT clients over MBMS and/or unicast transmissions.
Step 3.
The IOPS MC connectivity function distributes the group session packets carrying the IOPS floor request to the MCPTT clients from the target IOPS MCPTT group.
Step 4.
The MCPTT client 1 does not detect any floor contention. Floor contention occurs when multiple floor requests may exist simultaneously.
Step 5.
The MCPTT client 1 sends the IOPS floor taken message to the IOPS MCPTT group. The MCPTT client 1 transmits the group session packets carrying the IOPS floor taken message to the IOPS MC connectivity function for distribution to the corresponding IOPS group IP multicast address.
Step 6.
The IOPS MC connectivity function determines that the received packets correspond to a group session targeting a specific IOPS MCPTT group. The IOPS MC connectivity function decides distributing the received group session packets to the target MCPTT clients over MBMS and/or unicast transmissions.
Step 7.
The IOPS MC connectivity function distributes the group session packets carrying the IOPS floor taken message to the MCPTT clients from the target IOPS MCPTT group.
Step 8.
The MC user at MCPTT client 1 gets a notification that the IOPS floor request was successful (the floor has been granted).
Step 9.
The MCPTT client 1 begins voice transmission with the target IOPS MCPTT group based on the IP connectivity functionality.
