Floor control for interworking applies to both private call and group call.
Floor control involving a single MCPTT server is described in TS 23.379. Floor control involving multiple MCPTT servers is also described in TS 23.379 in that a primary MCPTT server is interconnected to a partner MCPTT server. Subclause 10.5.2 describes information flows for floor control between an MCPTT server and an IWF, and are based on those defined interconnection in TS 23.379. Subclause 10.5.3 describes aspects of floor control that apply to interworking groups and interworking private calls. Subclauses 10.5.4 / 10.5.6 and 10.5.5 / 10.5.7 describe general cases of floor control on an interworking group defined in the LMR system and in the MCPTT system respectively, where the partner system has been configured to apply/not apply local filtering of floor control requests before communicating with the primary system. Subclauses 10.5.9 and 10.5.10 describe general cases of floor control in a private call, where the controlling role is taken by the LMR system and the MCPTT system respectively.
The following sections describe information flows for interworking floor control.
In the following information flows the MCPTT ID and its associated functional alias represents the LMR user, the IWF, or the MCPTT user depending on the interworking methods being used and the message source/destination.
Table 10.5.2.2-1 describes the information flow IWF floor request, from the IWF to the MCPTT floor control server and from the MCPTT floor control server to the IWF, which is used to request the floor for media transfer.
Table 10.5.2.3-1 describes the information flow IWF floor granted, from the IWF to the MCPTT floor control server and from the MCPTT floor control server to the IWF, which is used to indicate that a request for floor is granted and media transfer is possible.
Table 10.5.2.4-1 describes the information flow IWF floor rejected, from the IWF to the MCPTT floor control server and from the MCPTT floor control server to the IWF, which is used to indicate that a request for the floor is rejected.
Table 10.5.2.5-1 describes the information flow IWF floor request cancel, from the IWF to the MCPTT floor control server and from the MCPTT floor control server to the IWF, which is used to request cancelling the floor request from the floor request queue.
Table 10.5.2.6-1 describes the information flow IWF floor request cancel response, from the IWF to the MCPTT floor control server and from the MCPTT floor control server to the IWF, which is used to indicate the response for the floor request cancellation.
Table 10.5.2.7-1 describes the information flow IWF floor request cancel notify, from the IWF to the MCPTT floor control server and from the MCPTT floor control server to the IWF, which is used to indicate the floor request is cancelled by the administrator/floor control server.
Table 10.5.2.8-1 describes the information flow IWF floor idle, from the IWF to the MCPTT floor control server and from the MCPTT floor control server to the IWF, which is used to indicate that a session is in idle status, i.e. the floor is not granted to any party.
Table 10.5.2.9-1 describes the information flow IWF floor release, from the IWF to the MCPTT floor control server and from the MCPTT floor control server to the IWF, which is used to indicate the media transfer is completed and the floor is released.
Table 10.5.2.10-1 describes the information flow IWF floor taken, from the IWF to the MCPTT floor control server and from the MCPTT floor control server to the IWF, which is used to indicate the floor is granted to another MCPTT user.
Table 10.5.2.11-1 describes the information flow IWF floor revoked, from the IWF to the MCPTT floor control server and from the MCPTT floor control server to the IWF, which is used to indicate the floor is revoked from its current holder (the floor participant who was granted the floor).
Table 10.5.2.12-1 describes the information flow IWF floor acknowledgement, from the IWF to the MCPTT floor control server and from the MCPTT floor control server to the IWF, which is used to provide an acknowledgement if the acknowledgement is required in the received floor control message.
Table 10.5.2.13-1 describes the information flow IWF queue position request, from the IWF to the MCPTT floor control server and from the MCPTT floor control server to the IWF, which is used to request the position in the floor request queue. The MCPTT server and the MCPTT client that support queuing of the floor control requests shall support this information flow.
Table 10.5.2.14-1 describes the information flow IWF queue position info, from the IWF to the MCPTT floor control server and from the MCPTT floor control server to the IWF, which is used to indicate the floor request is queued and the queue position to the floor requesting UE.
Table 10.5.2.15-1 describes the information flow IWF unicast media stop request, from the IWF to the MCPTT floor control server and from the MCPTT floor control server to the IWF, which is used to indicate that the unicast media flow of the designated communication does not need to be sent to the client indicated by the MCPTT ID.
Identifies the communication whose media flow is to be stopped, e.g. by identifying the media flow within a media multiplex, present only if media multiplexing
Table 10.5.2.16-1 describes the information flow IWF unicast media resume request, from the IWF to the MCPTT floor control server and from the MCPTT floor control server to the IWF, which is used by the floor control server to request that the unicast media flow of the designated communication is to be sent to the client indicated by the MCPTT ID.
Identifies the communication whose media flow is to be resumed, e.g. by identifying the media flow within a media multiplex, present only if media multiplexing
Table 10.5.2.17-1 describes the information flow IWF floor talker ID update, from the IWF to the MCPTT floor control server and from the MCPTT floor control server to the IWF, which is used to indicate that the talker ID has changed for the current MCPTT user granted the floor.
Subclause 10.9.1.4.1 of TS 23.379 describes floor control involving groups in multiple MCPTT systems where floor control arbitration resides with the primary MCPTT server and all floor control messages are routed to that primary MCPTT server. The group is homed on the primary MCPTT server.
An interworking group can be homed on the MCPTT server or on the LMR system. When the group is homed on the MCPTT server the floor control server is on this MCPTT server. When the group is homed on the LMR system the floor control server is represented by the IWF.
The primary MCPTT system of an MCPTT group is defined by configuration and identified by the MC service group ID.
Subclause 10.9.1.4.2 of TS 23.379 describes floor control involving groups in multiple MCPTT systems where the partner MCPTT system filters its MCPTT users' floor requests before communicating with the floor control server of the primary MCPTT system. When an MCPTT system is interworking with an IWF, depending on where the group is homed the MCPTT server, or the IWF can filter floor control requests in the same way as an interconnected MCPTT system.
In a private call, one of the IWF or MCPTT server acts as the controlling floor control server within the call, and manages arbitration of floor control requests received from both users in the call. The entity (MCPTT server or IWF) that does not fulfil the controlling role shall send all floor control requests from its served call participant to the controlling floor control server without filtering.
This procedure describes the case where a transmitting radio cannot be signalled that the floor has been taken or revoked. Within the context of interworking between MCPTT and LMR systems, this condition can occur due to both MCPTT and LMR users obtaining the floor simultaneously, or the floor granted to an LMR user is taken by an MCPTT user.
Figure 10.5.4-1 shows the high-level procedure where an MCPTT session is already established between the floor participants (with floor granted to an LMR user represented by the IWF) and the floor control server (with an override based on priority and configured to permit the transmission of overridden floor participant from the IWF). The group is defined in the MCPTT system and the MCPTT Server is the floor control server. Only two UEs involved in the session are shown for simplicity.
Pre-conditions:
The MCPTT 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.
An MCPTT session is established between an MCPTT client, the interworked system, and MCPTT server.
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.
Floor control server sends a floor taken message to the other floor participants (via the IWF). Floor participant B continues transmitting the (overridden) voice media transmission.
Figure 10.5.5-1 shows the procedure for floor control on an interworking group homed in the LMR system. Simultaneous floor requests are included to show various aspects of interworking floor control.
Pre-conditions:
The interworking group is homed in the LMR system.
The MCPTT server is configured to locally filter competing floor control requests before communicating with the IWF.
MCPTT client 1, MCPTT client 2, and LMR users (represented by the IWF) are affiliated to that group.
An interworking group call is ongoing involving MCPTT users and LMR users (represented by the IWF). The floor is currently idle.
The MCPTT floor control server determines to accept the floor request from MCPTT Client 1 based on local arbitration results (e.g., according to priority information versus the competing request from MCPTT client 2).
Since the group is homed in the LMR system the MCPTT floor control server forwards the floor request to the IWF for final floor control determination. The IWF performs floor arbitration in conjunction with the LMR system (not shown). The IWF determines that the floor can be granted to the MCPTT user.
Figure 10.5.6-1 shows the procedure for floor control on an interworking group homed in the MCPTT system, and the LMR system is configured for local floor control request filtering. Simultaneous floor requests are included to show various aspects of interworking floor control.
Pre-conditions:
The interworking group is homed in the MCPTT system.
The interworking group is previously defined on the group management server.
MCPTT client 1, MCPTT client 2, and LMR users (represented by the IWF) are affiliated to that group.
An interworking group call is ongoing involving MCPTT users and LMR users (represented by the IWF). The floor is currently idle.
The user of MCPTT Client 1 wants to send voice media over the session. At the same time a user in the LMR system (represented by the IWF) wants to also send voice media over the session.
Since the group is homed in the MCPTT system the MCPTT floor control server performs final floor control determination. In this case the MCPTT floor control server determines to accept the floor request from MCPTT Client 1 based on local policy and arbitration results (e.g., according to time of arrival of the request versus the competing request from the IWF).
Figure 10.5.7-1 shows the procedure for floor control on an interworking group defined in the LMR system where local filtering is not performed by the MCPTT server. Simultaneous floor requests are included to show various aspects of interworking floor control.
Pre-conditions:
The interworking group is defined in the LMR system.
The MCPTT system is configured to send competing floor control requests to the LMR system (represented by the IWF) for floor control arbitration.
MCPTT client 1, MCPTT client 2, and LMR users are affiliated to that group.
An interworking group call is ongoing involving MCPTT users and LMR users. The floor is currently idle.
Since the group is defined in the LMR system the MCPTT floor control server forwards these floor requests to the IWF for final floor control determination. The IWF performs floor arbitration in conjunction with the LMR system (not shown). The IWF determines that the floor can be granted to MCPTT client 1.
The IWF sends an IWF floor granted message for MCPTT client 1, an IWF floor rejected message for MCPTT client 2, and an IWF floor taken message for MCPTT client 2 to the MCPTT floor control server.
Figure 10.5.8-1 shows the procedure for floor control on an interworking group defined in the MCPTT system where local filtering is not performed by the LMR system. Simultaneous floor requests are included to show various aspects of interworking floor control.
Pre-conditions:
The interworking group is defined in the MCPTT system.
MCPTT client 1, MCPTT client 2, and LMR users are affiliated to that group.
The LMR system (represented by the IWF) is configured to send all competing floor control requests to the MCPTT system for floor control arbitration.
The IWF is not affiliating on behalf of LMR users. All LMR group affiliations are passed through the IWF to the MCPTT server.
An interworking group call is ongoing involving MCPTT users and LMR users. The floor is currently idle.
The user of MCPTT client 1 wants to send voice media over the session. At the same time multiple users in the LMR system (represented by the IWF) want to also send voice media over the session.
The IWF sends floor request messages to the MCPTT floor control server for each LMR user requesting the floor. In this case two LMR users are requesting the floor. These floor requests contain the MCPTT ID of the LMR user (converted by the IWF).
Since the group is defined in the MCPTT system the MCPTT floor control server performs final floor control determination. In this case the MCPTT floor control server determines to accept the floor request from MCPTT client 1 based on local policy and arbitration results (e.g., according to priority of the request versus the competing requests from the IWF).
The IWF is notified that its floor requests were rejected. The MCPTT floor control server sends an IWF floor rejected message to the IWF for each floor request.
The MCPTT floor control server sends floor taken messages to MCPTT client 2 and the IWF to inform them of who is granted the floor. In this case a floor taken message is sent to the IWF corresponding to each affiliated LMR user.
Figure 10.5.9-1 shows a procedure for a private call with floor control where the LMR system controls the floor. A request for transmission by the MCPTT user while the LMR user has the floor is rejected by the IWF, to show various aspects of interworking floor control.
Pre-conditions:
A private call has been set up between an LMR user and MCPTT client 1.
The LMR system is controlling the floor, via the IWF.
Figure 10.5.10-1 shows a procedure for a private call with floor control where the MCPTT system controls the floor. A request for transmission by the LMR user while the MCPTT user has the floor is accepted by the MCPTT server, to show various aspects of interworking floor control.
Pre-conditions:
A private call has been set up between the LMR user and MCPTT client 1.