10.9.1 Floor control for on-network MCPTT service

23.3793GPPFunctional architecture and information flows to support Mission Critical Push To Talk (MCPTT)Release 18Stage 2TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

10.9.1.1 General

The procedure is for providing a floor control to MCPTT UE in an on-network case and applies for both private call and group call. Floor control is performed by using floor control information flows between the floor participant and the floor control server.

10.9.1.2 Information flows for floor control for on-network

10.9.1.2.1 General

When the floor control server receives a floor request from the floor participant, it decides whether to give a grant or not based on, e.g., the session status (i.e., whether the grant is given to another user or not), user profile, priority. The result is informed to the requesting floor participant. When the floor participant receives a floor granted message, it can send voice media over the uplink bearer established beforehand. The floor revoked message can be used as part of override. The floor queue status request can be used to know current position in the queue for floor.

Some floor control information flows can also piggyback call control information flows to provide efficient call setup and clearing:

– Call setup request is optionally carried in floor request (uplink) or floor taken (downlink, can be broadcast); and

– Call release request is optionally carried in floor release (uplink) or floor idle (downlink, can be broadcast).

10.9.1.2.2 Floor request

Table 10.9.1.2.2-1 describes the information flow floor request, from the floor participant to the floor control server and from the floor control server to the floor control server, which is used to request the floor for media transfer. This information flow is sent in unicast to the floor control server.

Table 10.9.1.2.2-1: Floor request

Information element	Status	Description
MCPTT ID	M	Requester identity
Functional alias	O	Functional alias of the requester
Floor priority	M	Priority of the request
Source identifier	O	Identifies the communication, e.g. by identifying the media flow within a media multiplex, present only if media multiplexing
Location Information	O	Location information

10.9.1.2.3 Floor granted

Table 10.9.1.2.3-1 describes the information flow floor granted, from the floor control server to the floor participant and from the floor control server to the floor control server or MC gateway server, which is used to indicate that a request for floor is granted and media transfer is possible. This information flow is sent in unicast (to the granted floor participant).

Table 10.9.1.2.3-1: Floor granted

Information element	Status	Description
MCPTT ID	M	Granted party identity
Functional alias	O	Functional alias of the requester
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 if media multiplexing
Acknowledgement required	O	Indicates if acknowledgement from the floor participant is required

10.9.1.2.4 Floor rejected

Table 10.9.1.2.4-1 describes the information flow floor rejected, from the floor control server to the floor participant and from the floor control server to the floor control server or MC gateway server, which is used to indicate that a request for the floor is rejected. This information flow is sent in unicast (to the refused floor participant).

Table 10.9.1.2.4-1: Floor rejected

Information element	Status	Description
MCPTT ID (see NOTE)	O	Rejected party identity
Functional alias (see NOTE)	O	Functional alias of the requester
Source identifier	O	Identifies the communication, e.g. by identifying the media flow within a media multiplex, present only if media multiplexing
Rejection cause	O	Indicates the cause for floor rejection
Acknowledgement required	O	Indicates if acknowledgement from the floor participant is required
NOTE: MCPTT ID is present, and functional alias may be present, in messages between the floor control servers in different MCPTT systems, and between floor control server and MC gateway server.

10.9.1.2.5 Floor request cancel

Table 10.9.1.2.5-1 describes the information flow floor request cancel, from the floor participant to the floor control server, which is used to request cancelling the floor request from the floor request queue. This information flow is sent in unicast to the floor control server.

Table 10.9.1.2.5-1: Floor request cancel

Information element	Status	Description
MCPTT ID	M	Identity for the requester
Functional alias	O	Functional alias for the requester
List of MCPTT IDs (see NOTE)	O	Target identity (identities) whose floor request is to be cancelled
Source identifier	O	Identifies the communication, e.g. by identifying the media flow within a media multiplex, present only if media multiplexing
NOTE: If this information element is not present all the entries in the floor request queue are cancelled.

10.9.1.2.6 Floor request cancel response

Table 10.9.1.2.6-1 describes the information flow floor request cancel response, from the floor control server to the floor control participant and from the floor control server to the floor control server or MC gateway server, which is used to indicate the response for the floor request cancellation. This information flow is sent in unicast.

Table 10.9.1.2.6-1: Floor request cancel response

Information element	Status	Description
MCPTT ID	M	Identity of party that initiated the cancellation request
Functional alias	O	Functional alias of the requester
Source identifier	O	Identifies the communication, e.g. by identifying the media flow within a media multiplex, present only if media multiplexing
Acknowledgement required	O	Indicates if acknowledgement from the floor participant is required

10.9.1.2.7 Floor request cancel notify

Table 10.9.1.2.7-1 describes the information flow floor request cancel notify, from the floor control server to the floor control participant, which is used to indicate the floor request is cancelled by the administrator/floor control server. This information flow is sent in unicast or broadcast.

Table 10.9.1.2.7-1: Floor request cancel notify

Information element	Status	Description
MCPTT ID	M	Identity of the administrator
Functional alias	O	Functional alias of the administrator
Source identifier	O	Identifies the communication, e.g. by identifying the media flow within a media multiplex, present only if media multiplexing
Acknowledgement required	O	Indicates if acknowledgement from the floor participant is required

10.9.1.2.8 Floor idle

Table 10.9.1.2.8-1 describes the information flow floor idle, from the floor control server to the floor participant, which is used to indicate that a session is in idle status, i.e. the floor is not granted to any party. This information flows is sent in unicast or broadcast.

Table 10.9.1.2.8-1: Floor idle

Information element	Status	Description
Source identifier	O	Identifies the communication, e.g. by identifying the media flow within a media multiplex, present only if media multiplexing
Acknowledgement required	O	Indicates if acknowledgement from the floor participant is required

10.9.1.2.9 Floor release

Table 10.9.1.2.9-1 describes the information flow floor release, from the floor participant to the floor control server, which is used to indicate the media transfer is completed and floor is released. This information flow is sent in unicast to the floor control server.

Table 10.9.1.2.9-1: Floor release

Information element	Status	Description
MCPTT ID	M	Identity of party that initiated the cancellation request
Functional alias	O	Functional alias of the requester
Source identifier	O	Identifies the communication, e.g. by identifying the media flow within a media multiplex, present only if media multiplexing

10.9.1.2.9a Multi-talker floor release

Table 10.9.1.2.9a-1 describes the information elements of floor release for multi-talker control, from the floor control server to the floor participants, which is used to indicate the media transfer is completed and floor is released. This information flow is sent in unicast from the floor control server.

Table 10.9.1.2.9a-1: Multi-talker floor release

MCPTT ID (see NOTE)		M		Identity of participant releasing the floor
List of functional aliases (see NOTE)	O		Functional alias(es) of participant releasing the floor
Source identifier		O		Identifies the communication, e.g. by identifying the media flow within a media multiplex, present only if media multiplexing
NOTE: One or more functional aliases may be associated with the MCPTT ID.

10.9.1.2.10 Floor taken

Table 10.9.1.2.10-1 describes the information flow floor taken, from the floor control server to the floor participant, which is used to indicate the floor is granted to another MCPTT user. This information flows is sent in unicast or broadcast.

Table 10.9.1.2.10-1: Floor taken

Information element	Status	Description
MCPTT ID	M	Identity for the granted party
Functional alias	O	Functional alias for the granted party
Source identifier	O	Identifies the communication, e.g. by identifying the media flow within a media multiplex, present only if media multiplexing
Permission to request the floor	O	Indicates whether receiving parties are allowed to request the floor or not (e.g. broadcast call).
Acknowledgement required	O	Indicates if acknowledgement from the floor participant is required
Location Information	O	Location information

10.9.1.2.10a Multi-talker floor taken

Table 10.9.1.2.10a-1 describes the information elements of floor taken for multi-talker control, from the floor control server to the floor participant, which is used to indicate when the floor is simultaneously granted to multiple MCPTT users. The multi-talker floor taken is sent in unicast or broadcast.

Table 10.9.1.2.10a-1: Multi-talker floor taken

Information element	Status	Description
List of MCPTT IDs (see NOTE)	M	Identity (identities) of the granted participant(s)
List of functional aliases (see NOTE)	O	Functional alias(es) of the granted participant(s)
List of source identifiers (see NOTE)	O	Identifies the communication, e.g. by identifying the media flow within a media multiplex, present only if media multiplexing
Acknowledgement required	O	Indicates if acknowledgement from the floor participant is required
NOTE: One or more functional aliases and one source identifier may be associated with an MCPTT ID.

10.9.1.2.11 Floor revoked

Table 10.9.1.2.11-1 describes the information flow floor revoked, from the floor control server to the floor participant and from the floor control server to the floor control server or MC gateway server, which is used to indicate the floor is revoked from its current holder (the floor participant who was granted the floor). This information flows is sent in unicast (to the revoked floor participant).

Table 10.9.1.2.11-1: Floor revoked

Information element	Status	Description
MCPTT ID	M	Revoked party identity
Functional alias	O	Functional alias of the requester
Source identifier	O	Identifies the communication, e.g. by identifying the media flow within a media multiplex, present only if media multiplexing
Acknowledgement required	O	Indicates if acknowledgement from the floor participant is required

10.9.1.2.12 Floor acknowledgement

Table 10.9.1.2.12-1 describes the information flow floor acknowledgement, from the floor participant to the floor control server, which is used to provide an acknowledgement if the acknowledgement is required in the received floor control message.

NOTE: The floor acknowledgement flow can be sent by the floor participant after each floor control information flow that includes an indication that an acknowledgement is required. The procedures defined in subclauses 10.9.1.3 to 10.9.1.5 do not explicitly illustrates all scenarios when floor acknowledgement can be used.

Table 10.9.1.2.12-1: Floor acknowledgement

Information element	Status	Description
MCPTT ID	M	Identity of the sender.
Functional alias	O	Functional alias of the sender.

10.9.1.2.13 Queue position request

Table 10.9.1.2.13-1 describes the information flow queue position request, from the floor participant to the floor control server and from the floor control server to the floor control server or MC gateway server, which is used to request the position in the floor request queue. The MCPTT server and the MCPTT client support queuing of the floor control requests shall support this information flow. This information flow is sent in unicast to the floor control server.

Table 10.9.1.2.13-1: Queue position request

Information element	Status	Description
MCPTT ID	M	Identity of party whose floor position is requested
Functional alias	O	Functional alias of the requester
Source identifier	O	Identifies the communication, e.g. by identifying the media flow within a media multiplex, present only if media multiplexing

10.9.1.2.14 Queue position info

Table 10.9.1.2.14-1 describes the information flow queue position info, from the floor control server to the floor participant and from the floor control server to the floor control server or MC gateway server, which is used to indicate the floor request is queued and the queue position to the floor requesting UE and optionally to the authorized user. The MCPTT server and the MCPTT client support queuing of the floor control requests shall support this information flow. This information flow is sent in unicast (to the queued floor participant and optionally to the authorized user).

Table 10.9.1.2.14-1: Queue position info

Information element	Status	Description
MCPTT ID	M	Identity of party whose floor position is provided
Functional alias	O	Functional alias of the requester
Queue position info	M	Position of the queued floor request in the queue
Source identifier	O	Identifies the communication, e.g. by identifying the media flow within a media multiplex, present only if media multiplexing
Acknowledgement required	O	Indicates if acknowledgement from the floor participant is required

10.9.1.2.15 Unicast media stop request

Table 10.9.1.2.15-1 describes the information flow unicast media stop request from the floor participant to the floor control server, which is used by the floor participant to indicate that the unicast media flow of the designated communication does not need to be sent to the MCPTT client.

Table 10.9.1.2.15-1: Unicast media stop request

Information element	Status	Description
MCPTT ID	M	Identity of the requester
Functional alias	O	Functional alias for the requester
Source identifier	O	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

10.9.1.2.16 Unicast media resume request

Table 10.9.1.2.16-1 describes the information flow unicast media resume request from the floor participant to the floor control server, which is used by the floor participant to request that the unicast media flow of the designated communication is to be sent to the MCPTT client.

Table 10.9.1.2.16-1: Unicast media resume request

Information element	Status	Description
MCPTT ID	M	Identity of the requester
Functional alias	O	Functional alias of the requester
Source identifier	O	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

10.9.1.3 Floor control within one MCPTT system

10.9.1.3.1 Floor request, floor granted and floor taken during an MCPTT session

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.

Figure 10.9.1.3.1-1: Floor request, floor granted, floor taken during an MCPTT session

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.

2. Floor participant A wants to send voice media over the session.

3. Floor participant A sends a floor request message to floor control server which includes floor priority and other information as necessary.

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.

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.

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.

5c. Floor participant A sends a floor acknowledgement if indicated to do so by the floor granted message.

5d. Floor participant B sends a floor acknowledgement if indicated to do so by the floor taken message.

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.

5f. Floor participant C sends a floor acknowledgement if indicated to do so by the floor taken message.

6a. The floor granted shall cause the user of UE A where the floor participant A is located to be notified.

6b. The receipt of the floor taken may be used to inform the user of UE B where the floor participant B is located.

6c. The receipt of the floor taken may be used to inform the user of UE C where the floor participant C is located.

7. Floor participant A starts sending voice media over the session established beforehand.

NOTE 1: Voice media can continue to be sent while steps 8 through 11 occur.

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.

9. Floor participant B sends a floor request message.

10. Floor control server queues the request of floor participant B.

11a. Floor control server sends queue position info to floor participant B.

11b. Floor participant B sends a floor acknowledgement if indicated to do so by the queue position info message.

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.

13. Floor participant C sends a floor acknowledgement if indicated to do so by the queue position info message.

NOTE 2: If the floor participant user B’s queued floor request is rejected after de-queue from the floor control queue then the floor control server may send the queue position info to floor participant C who is an authorized user. The floor queue position info message should indicate that floor participant user B’s queued floor request is no longer queued.

10.9.1.3.1a Floor request, floor granted and multi-talker floor taken during an MCPTT session enhanced with multi-talker control

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.

Figure 10.9.1.3.1a-1: Floor request, floor granted and multi-talker floor taken during an MCPTT session

1. Floor participant B is talking and is sending the voice media.

2. Floor participant A wants to send voice media over the session.

3. Floor participant A sends a floor request message to the floor control server which includes the necessary information, e.g. floor priority.

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.

5a. Floor control server responds with a floor granted message to floor participant A.

5b. Floor control server sends a multi-talker floor taken message to floor participant B.

5c. Floor control server sends a multi-talker floor taken message to floor participant C.

5d. Floor control server may send a multi-talker floor taken message to floor participant A.

6a. The floor granted shall cause the user of UE A, where the floor participant A is located, to be notified.

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.

6c. The multi-talker floor taken shall inform the user of UE C floor participants list the floor are currently granted to.

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.

NOTE: Floor control is independent from whether audio mixing is performed by the MCPTT server or by the UE.

10.9.1.3.2 Floor override

10.9.1.3.2.1 Floor override using floor revoked (also floor rejected) during an MCPTT session

Figure 10.9.1.3.2.1-1 shows the high level procedure that the floor control is conducted for the MCPTT session already established between the floor participant (with floor granted to floor participant B) and the floor control server (with an override based on priority). Only two UEs involved in the session are shown for the simplicity.

Figure 10.9.1.3.2.1-1: Floor override using floor revoked (also floor rejected) during an MCPTT session

1. It is assumed that floor participant B has been given floor and is transmitting voice media.

2. Floor participant A having a priority which is relatively higher than that of floor participant B wants to send voice media over the session.

3. Floor participant A sends a floor request message to the floor control server.

4. The floor control server determines to accept the floor request from floor participant A based on arbitration result e.g., according to the priority information that is received in the floor request message. The floor control server sends a floor revoked message to floor participant B stopping the voice media transmission from floor participant B.

5. The user of floor participant B may be notified that the floor is revoked.

6. The Floor control server sends a floor granted message to floor participant A, while sending a floor taken message to floor participant B with information of who is granted the floor.

7. The user of floor participant A may be notified that he is granted the floor. Similarly, the user of floor participant B may be notified who is granted the floor.

8. Floor participant A starts sending voice media over the session established beforehand.

9. Now floor participant B may want the floor to start sending voice media.

10. Floor participant B sends a floor request message to floor control server which may include priority information.

11. Floor control server determines whether to accept the floor request from floor participant B based on arbitration result e.g., according to the priority information that is received in the floor request message.

12. The floor control server responds with a floor rejected message to floor participant B.

13. Floor participant B may be notified that he is rejected.

10.9.1.3.2.2 Floor override without using floor revoked during an MCPTT session

Figure 10.9.1.3.2.2-1 shows the high level procedure that the floor control is conducted for the MCPTT session already established between the floor participants (with floor granted to floor participant B) and the floor control server (with an override based on priority and configured to permit the transmission of the overridden floor participant B to continue). Only two UEs involved in the session are shown for the simplicity.

Pre-conditions

– The 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.

Figure 10.9.1.3.2.2-1: Floor override (overridden continues to transmit) during an MCPTT session

1. It is assumed that floor participant B has been given the floor and is transmitting voice media.

2. Floor participant A having a floor priority which is relatively higher than that of floor participant B wants to send voice media over the session.

3. Floor participant A sends a floor request message to the floor control server.

4. 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.

5a. Floor control server responds with a floor granted message to floor participant A.

5b. Floor control server sends a floor taken message to the other floor participants (including floor participant B). Floor participant B continues transmitting the (overridden) voice media transmission.

NOTE 1: All other floor participants (not shown) that are part of this group call receive a floor taken message, so that the other floor participants learn who the newly granted talker (overriding) is.

6a. The floor granted causes the user of floor participant A to be notified.

6b. The user of floor participant B is notified of the status that the floor is now taken by floor participant A.

7. Floor participant A (overriding) starts sending voice media over the session established beforehand.

NOTE 2: Floor participant B is still sending voice (overridden). The list of floor participants that receive the overriding, overridden, or both transmissions is based on configuration.

10.9.1.3.2.3 Floor override using floor revoked (also floor rejected) during an MCPTT session enhanced with multi-talker control

Figure 10.9.1.3.2.3-1 shows the high-level procedure that the floor control allows several participants to talk simultaneously in a MCPTT session already established between the floor participant (with floor granted to floor participant B) and the floor control server. Only two UEs involved in the session are shown for the simplicity.

Pre-conditions:

1. The MCPTT group is configured to support multi-talker control.

2. MCPTT session is established between MCPTT clients (client A, client B and client C) and MCPTT server.

3. The maximum number of simultaneous talkers is set to 2.

4. The floor priority of floor participant A is higher than of floor participant B.

5. The floor is granted to floor participant B and floor participant C.

Figure 10.9.1.3.2.3-1: Floor override using floor revoked (also floor rejected) during an MCPTT session

1. Floor participant B and floor participant C are sending voice media over the session established.

2. Floor participant A wants to send voice media over the session.

3. Floor participant A wants to talk (i.e. send voice media) over the session. Floor participant A sends a floor request message to the floor control server.

4. Based on an arbitration result (e.g. per the priority information that is received in the floor request message), the floor control server determines to accept the floor request from floor participant A. The maximum number of simultaneous talkers in the MCPTT group has been reached, the floor control server decides to apply the override mechanism.

5. The floor control server sends a floor revoked message to floor participant B stopping the voice media transmission of floor participant B.

6. The user of floor participant B may be notified that the floor is revoked.

7. The Floor control server sends a floor granted message to floor participant A, while sending a multi-talker floor taken message to floor participant B and floor participant C including the information to whom the floor has been granted.

8. The user of floor participant A may be notified that the floor has been granted to him. Similarly, the user of floor participant B and floor participant C may be notified to whom the floor has been granted.

9. Floor participant A starts sending voice media over the session established beforehand.

10. Now floor participant B may want the floor to start sending voice media.

11. Floor participant B sends a floor request message to floor control server that may include participant priority information.

12. Based on arbitration result, e.g. per the priority information that is received in the floor request message, and if the number of MCPTT Users has already reached the maximum number of simultaneous talkers in the group, the floor control server determines whether to accept or reject the floor request from floor participant B. Due to lower priority of participant B and the applicable limitation of simultaneous talkers, the floor control server rejects the floor request.

13. The floor control server responds with a floor rejected message to floor participant B.

14. Floor participant B may be notified about the floor rejection.

NOTE: Floor control procedure is independent from whether audio mixing is performed by the MCPTT server or by the UE.

10.9.1.3.2.4 Floor release during an MCPTT session enhanced with multi-talker control

Figure 10.9.1.3.2.4-1 shows the high-level procedure where the floor controller allows a participant to release the floor while other participants continue to talk simultaneously in a MCPTT session already established between the floor participants and the floor control server. Only 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 the MCPTT server.

3. Participants A, B, and C have the permission to talk to all other participants, and the floor is granted to floor participants A, B, and C.

Figure 10.9.1.3.2.4-1: Floor release during an MCPTT session

1. Floor participants A, B and C are sending voice media over the established session.

2. User A stops talking and wants to stop sending voice media over the session.

3. Floor participant A sends a floor release message to the floor control server.

4. The floor control server accepts the floor release from floor participant A and sends a multi-talker floor release message to floor participant B and floor participant C.

4a. The users of floor participant B and floor participant C may be notified that floor participant A has released the floor.

5. Floor participants B and C continue sending voice media over the established session.

NOTE: Floor control procedures are independent from whether audio mixing is performed by the MCPTT server or by the UE.

10.9.1.3.3 Queue position during an MCPTT session

Figure 10.9.1.3.3-1 shows the high level procedure that the floor control is conducted for the MCPTT session already established between MCPTT clients (with floor granted to floor participant B) and server (with an override based on priority at floor control server). Only two UEs involved in the session are shown for the simplicity.

Figure 10.9.1.3.3-1: Queue status during an MCPTT session

1. It is assumed that floor participant B has been given a floor granted and is transmitting voice media. There are several other floor participants (including floor participating A) requesting floor which get queued at the floor control server.

2. Floor participant A would like to know its current position in the floor request queue.

3. Floor participant A sends a queue position request message to the floor control server.

4. Floor control server determines the current queue position of floor participant A from the floor request queue.

5. Floor control server responds with the current position in queue position info message.

6. User at floor participant A is informed about the current queue position.

10.9.1.3.4 Floor request cancellation from the floor request queue

10.9.1.3.4.1 Floor request cancellation from the queue – MCPTT user initiated

Figure 10.9.1.3.4.1-1 illustrates the procedure for floor request cancellation from the floor queue initiated by the MCPTT user. The MCPTT user may be an authorized user who has rights to cancel the floor requests of other MCPTT users, whose floor requests are in floor control queue.

Pre-conditions:

– It is assumed that floor participant B has been granted the floor and is transmitting voice media. There are several other floor participants (including floor participant A and floor participant C) requesting the floor which have been queued at the floor control server.

Figure 10.9.1.3.4.1-1: Floor request cancellation from queue initiated by MCPTT user

1. The floor participant A wants to remove the floor request from the floor request queue. If floor participant A is an authorized MCPTT user with the rights to cancel another MCPTT user’s floor request, the authorized MCPTT user may request floor request cancellation for one or more floor participants, whose floor request needs to be removed from the floor queue.

2. The floor participant A sends a floor request cancel (initiating MCPTT ID) message to the floor control server. If the floor participant A wants to remove the floor request(s) of other participant(s), the target participant(s)’ MCPTT ID should be included in this message.

3. The floor control server shall check whether the requesting floor participant has authorization to cancel the floor request(s). If authorized, the floor request(s) will be removed from the floor request queue. When current transmission is completed, floor control server will process the floor request from the updated floor request queue.

4. If the floor request cancel in step 2 is sent by an authorized user (e.g., dispatcher) to cancel the floor request(s) of other participant(s) from the floor request queue, the floor request cancel notify message is sent to the floor participant whose floor request was cancelled from the floor queue. The floor request cancel notify message is also sent to the authorized user (not shown in figure) if the floor request cancel in step 2 is sent by the floor participant A is an initiating MCPTT user.

5. The floor control server provides a floor request cancel response to the floor participant A when the floor cancellation is completed. Optionally, the new queue position information may be notified to the floor participants whose floor requests are in the floor request queue (not shown in the figure).

10.9.1.3.4.2 Floor request cancellation from the queue – floor control server initiated

Figure 10.9.1.3.4.2-1 illustrates the procedure for floor request cancellation from the queue initiated by the floor control server. Only three UEs involved in the session are shown for the simplicity.

Pre-conditions:

– MCPTT session is established between MCPTT clients (client A, client B, client C and client D) and MCPTT server.

– It is assumed that floor participant B (not shown in figure) has been granted the floor and is transmitting voice media. There are several other floor participants (including floor participant A and participant C) requesting the floor which have been queued at the floor control server.

– The user at MCPTT client D 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.

Figure 10.9.1.3.4.2-1: Floor request cancellation from queue initiated by floor control server

1. The floor control server removes the floor request from the floor request queue based on policy. e.g., expiration of a timer. In the case when floor control server receives repeated floor requests from a floor participant while the floor is occupied, the new floor request is accepted and added into the floor queue and the existing/former floor request is removed from the floor queue or the new floor request is rejected and the existing/former floor request of this floor participant is retained in the floor request queue.

2. The floor control server sends a floor request cancel notify to the floor participant(s) whose floor request is removed from the floor request queue.

3. Optionally, the newly queue position information is notified to the other floor participants whose floor requests are queued.

4. If the floor request cancel in step 2 is sent by floor control server for the user whose floor request is in the floor request queue, the floor control server may send the floor cancel notify to the floor participant D who is an authorized user.

10.9.1.4 Floor control involving groups from multiple MCPTT systems

10.9.1.4.1 Partner MCPTT system routes all floor control messages to primary MCPTT system’s floor control server

The MCPTT users belonging to different groups in multiple MCPTT systems will participate in MCPTT media services (group communication, private calls, etc.) in scenarios like group hierarchies and temporary groups formed by group regroup. In this service delivery model involving multiple groups from different MCPTT systems, the floor control arbitration resides with the primary MCPTT system. This is determined in the group call setup stage. The MCPTT users of groups involved in the call session will transmit their floor control messages through the partner MCPTT systems to which they belong. In this scenario, the partner MCPTT systems request the floor control for its MCPTT user(s) from the floor control server of the primary MCPTT system. The protocol used for media plane signalling is non-SIP like RTCP.

Figure 10.9.1.4.1-1 describes the procedure for floor control involving groups from multiple MCPTT systems.

Pre-conditions:

1. The security aspects of sharing the user information between primary and partner MCPTT systems shall be governed as per the service provider agreement between them. In this case, we consider the partner MCPTT system does not share all information of their users’ to the primary MCPTT system (public information would still need to be shared).

2. The group 1 is hosted by primary MCPTT system and group 2 and 3 are hosted by the partner MCPTT system.

3. The floor participant 1 corresponds to the MCPTT user of group 1. The floor participant 2 corresponds to the MCPTT user of group 2. The floor participant 3 corresponds to the MCPTT user of group 3. The floor control server 1 belongs to primary MCPTT system. The floor control server 2 belongs to partner MCPTT system.

4. The floor control server 1 is the floor arbitrator of the MCPTT group call. The floor control server 2 routes all floor control messages to and from the floor participants 2 and 3 and then floor control server 1.

Figure 10.9.1.4.1-1: Floor control (partner MCPTT system forwarding) involving groups from multiple MCPTT systems

1. An MCPTT group call involving group1, group 2 and group 3 is setup and active.

2. The MCPTT users want to talk.

3. The floor participants initiate a floor request to the floor control server of their corresponding MCPTT systems. (The requests may or may not occur at the same time).

4. If only one floor request is received, or floor control server 2 handles the floor request sequentially, there is no arbitration performed and the corresponding floor request is forwarded to the floor control server 1. If the floor control server 2 receives multiple floor requests at the same time or during an interval, then it forwards the floor requests to the floor control server 1 (floor arbitrator for the MCPTT group call). As the floor participant information shall not be exposed, the floor priority related information or/and group information to be used by floor control server 1 should be included in the forwarded request.

5. The floor control server 1 performs floor arbitration for the MCPTT group call and determines the floor request to be accepted.

6. If the floor request from floor participant 2 of the partner MCPTT system is accepted, a floor granted is sent with permission to talk. The floor control messages from floor control server 1 are routed to floor participant 2 via the floor control server 2.

7. When the floor control server 2 (partner) receives the floor granted, the floor control server 2 sends a floor granted message on to floor participant 2.

8. The floor granted shall cause the user of the UE where the floor participant 2 is located to be notified.

9. The primary floor control server 1 may (9a.1) send a floor rejected message, or (9b.1) send a queue position info message for each non-granted received floor requests forwarded from the floor control server 2 (partner). When the floor control server 2 (partner) receives the floor rejected message, then the floor control server 2 (partner) (9a.2) sends a floor rejected message to the appropriate floor participant. When the floor control server 2 (partner) receives the queue position info, then the floor control server 2 (partner) (9b.2) sends a queue position info message to the appropriate floor participant.

10a.1 If floor control server 1 rejects the floor request from floor participant 1, then a floor reject message is sent.

10a.2 Upon this being received the user of the UE where floor participant 1 is located may be notified.

10b.1 If floor control server 1 supports floor queue, queue position info message is sent to the floor participant 1.

10b.2 Upon this being received the user of the UE where floor participant 1 is located may be notified.

NOTE 1: Steps 10a.1 through 10.b2 are optional as indicated by the dashed box enclosing them. However, if this box is implemented then either information flow 10a or 10b would occur.

NOTE 2: Optionally, the authorized user (e.g., dispatcher) receiving 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 is not shown here for the sake of brevity.

11. Since the floor is granted to floor participant 2 of the partner MCPTT system, then a floor taken is sent to all other floor participants ((11a) floor participant 1 and (11b.1) to floor control server 2 (partner) for forwarding to (11b.2) floor participant 3.

12. The receipt of the floor taken may be used to inform the users of the UEs where the floor participant entity 1 and floor participant 3 are located to be notified.

13. Upon successful floor granted, the group call media transmission occurs.

NOTE 3: The media flow between the media gateways of primary and partner MCPTT systems have not been depicted in the figure for clarity.

10.9.1.4.2 Partner MCPTT system performs filtering of floor control messages entering and leaving the partner MCPTT system

The MCPTT users belonging to different groups in multiple MCPTT systems will participate in MCPTT media services (group communication, private calls, etc.) in scenarios like group hierarchies and temporary groups formed by group regroup. In this service delivery model involving multiple groups from different MCPTT systems, the floor control arbitration resides with the primary MCPTT system. This is determined in the group call setup stage. The MCPTT users of groups involved in the call session will transmit their floor control messages through the partner MCPTT systems to which they belong. In this scenario, the partner MCPTT system filters its MCPTT users’ floor requests before communicating with the floor control server of the primary MCPTT system. The protocol used for media plane signalling is non-SIP like RTCP.

Figure 10.9.1.4.2-1 describes the procedure for floor control involving groups from multiple MCPTT systems.

Pre-conditions:

1. The security aspects of sharing the user information between primary and partner MCPTT systems shall be governed as per the service provider agreement between them. In this case, we consider the partner MCPTT system does not share all information of their users to the primary MCPTT system (public information would still need to be shared).

2. The group 1 is hosted by primary MCPTT system and group 2 and 3 are hosted by the partner MCPTT system.

4. The floor control server 1 is the floor arbitrator of the MCPTT group call. The floor control server 2 does floor control filtering with its floor participants 2 and 3 before communicating with the floor control server 1.

Figure 10.9.1.4.2-1: Floor control (filtering by partner MCPTT system) involving groups from multiple MCPTT systems

1. An MCPTT group call involving group 1, group 2 and group 3 is setup and active.

2. The MCPTT users want to talk

3. The floor participants initiate a floor request to the floor control server of their corresponding MCPTT systems. (The requests may or may not occur at the same time).

4. Floor control server 2 receives a floor request from floor participant 2 and from participant 3 at the same time or during an interval, then the floor control server 2 (partner) performs filtering of the floor requests received according to its local policy such as priority or order based on its own users, and forwards the selected floor request (floor participant 2) to the floor control server 1 (floor arbitrator for the MCPTT group call). As the floor participant information shall not be exposed, the priority related information or/and group information to be used by floor control server 1 should be included in the forwarded request.

5. The floor control server 2 (partner) may send a floor rejected towards the floor participant 3, since its floor request was not chosen to be forwarded on to the floor control server 1.

6. The user on the UE where the floor participant 3 is located may be notified of the rejection.

NOTE 1: Steps 5 and 6 can occur any time between step 4 and step 16.

7. The floor control server 2 (partner) forwards the floor request of floor participant 2 to the floor server 1.

8. The floor control server 1 performs floor arbitration for the MCPTT group call and determines the floor request to be accepted. The floor request message from floor participant 2 of the partner system is accepted by the floor control server 1 (arbitrator) and is determined that a floor granted is sent with permission to talk.

9. The floor granted message from floor control server 1 is routed to floor participant 2 via the floor control server 2 (partner).

10. Since floor participant 1 sent a floor request but was not granted,

10a.1 the primary floor control server may send a floor rejected message to floor participant 1.

10a.2 The user of the UE where the floor participant 1 is located may be notified of the rejection.

10b.1 if floor control server supports floor queuing, send a queue position info message to floor participant 1.

10b.2 The user of the UE where the floor participant 1 is located may be notified of the queue position.

NOTE 2: Steps 10a.1 through 10.b2 are optional as indicated by the dashed box enclosing them. However, if this box is implemented then either information flow 10a or 10b would occur.

NOTE 3: Optionally, the authorized user (e.g., dispatcher) receiving 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 is not shown here for the sake of brevity.

11. A floor taken message is sent to floor participant 1.

12. The user of the UE where the floor participant 1 is located may be notified.

NOTE 4: Step 10 through Step 12 can occur any time between step 8 and step 18.

13. Since the floor control server 2 (partner) filters floor requests, when the floor control server 2 (partner) receives the floor granted for floor participant 2 from floor control server 1, the floor control server 2 (partner) needs to use the information received to generate the floor taken which will be sent to all other floor participants (floor control participant 3).

14. The floor control server 2 (partner) sends a floor granted message to floor participant 2.

15. The user of the UE where the floor participant 2 is located is notified.

16. The floor control server 2 (partner) sends a floor taken message to all other floor participants (floor participant 3).

17. The user of the UE where the floor participant 1 is located may be notified.

18. Upon successful floor grant, the group call media transmission occurs.

NOTE 5: The media flow between the media gateways of primary and partner MCPTT systems have not been depicted in the figure for clarity.

10.9.1.5 Floor control for audio cut-in enabled group

Figure 10.9.1.5-1 shows the procedure for audio cut-in for the session already established between the floor participants from same MCPTT service provider. Floor participants may request the floor while Floor Participant B is transmitting voice media. Floor control server grants floor immediately to the floor request received.

Editor’s note: Configuration parameter for queue depth is FFS.

Pre-conditions:

– The floor control server has been configured to support audio cut-in.

– It is assumed that the floor has been granted to floor participant B and floor participant B is transmitting voice media. There are several other floor participants (including floor participant A).

Figure 10.9.1.5-1: Floor control for audio cut-in enabled group in single MCPTT system

1. Floor participant B has been given floor and is transmitting voice media.

2. Floor participant A wants to send voice media over the session.

3. Floor participant A sends a floor request message to the floor control server.

4. The floor control server applies the audio cut-in policy with floor queue disabled i.e., floor is immediately granted to the floor participant A, and revoked from floor participant B.

5. The floor control server sends a floor revoked message to floor participant B stopping the voice media transmission from floor participant B.

6. The user of floor participant B may be notified that the floor is revoked.

7. The Floor control server sends a floor granted message to floor participant A, and sends a floor taken message to floor participant B with information of who is granted the floor. The floor control server may limit the time a user talks (holds the floor).

8. The user of floor participant A may be notified that he is granted the floor. Similarly, the user of floor participant B may be notified who is granted the floor.

9. Floor participant A starts sending voice media over the session established.

10. Now floor participant B may want the floor to start sending voice media.

11. Floor participant B sends a floor request message to floor control server.

12. The floor control server applies the audio cut-in policy with floor queue disabled.

13. The floor control server sends a floor revoked message to floor participant A stopping the voice media transmission from floor participant A.

14. The user of floor participant A may be notified that the floor is revoked.

15. The Floor control server sends a floor granted message to floor participant B, and sends a floor taken message to floor participant A with information of who is granted the floor. The floor control server may limit the time a user talks (holds the floor).

16. The user of floor participant B may be notified that he is granted the floor. Similarly, the user of floor participant A may be notified who is granted the floor.

17. Floor participant B starts sending voice media over the session established.

10.9.1.6 Unicast media stop and resume requests

Figure 10.9.1.6-1 shows the procedure for a floor participant to indicate to the floor control server that the unicast media flow of an active MCPTT group call can be stopped.

Pre-condition:

1. An MCPTT session is established between MCPTT client A and MCPTT server for an MCPTT group call. Other participants to the call are not shown in the figure for simplicity.

2. The floor control is established between the floor participant and the floor control server.

Figure 10.9.1.6-1: Unicast media stop request during an MCPTT session

1. Another floor participant has requested and has been granted the floor. The floor control server sends a floor taken message to floor participant A. The floor taken message may include an identifier of the associated media flow.

2. Floor control server sends the voice media flow to floor participant A over unicast.

3. Floor participant A gets the information, e.g. from the user, that media for the call is not needed.

4. Floor participant A sends a unicast media stop request to floor control server, identifying the media flow to be stopped.

5. Floor control server stops sending that unicast media flow to floor participant A. Associated bearer resources may be de-allocated by the MCPTT server.

Figure 10.9.1.6-2 shows the procedure for a floor participant to request from the floor control server that the unicast media flow of an active MCPTT group call be restarted.

Pre-condition:

1. An MCPTT session is established between MCPTT client A and MCPTT server for an MCPTT group call. Other participants to the call are not shown in the figure for simplicity

2. The floor control is established between the floor participant and the floor control server.

3. Floor participant A has previously indicated to the floor control server that unicast media flow for that call should be stopped, using the procedure described in Figure 10.9.1.6-1.

Figure 10.9.1.6-2: Unicast media resume request during an MCPTT session

2. Floor participant A gets the information, e.g. from the user, that media for the call is needed again.

3. Floor participant A sends a unicast media resume request to floor control server, identifying the media flow to be re-started.

4. Floor control server starts sending that unicast media flow to floor participant A. This may need new bearer resources to be allocated.

NOTE 1: The identifier of the flow to be stopped or resumed is known by the floor participant from the floor control information flows associated with that MCPTT session.

NOTE 2: Stopping a media flow is not leaving the session and subsequent floor control messages will still be sent by the floor control server to the floor participant which has requested a unicast media stop.

NOTE 3: Both requests have no effect on a possible ongoing transmission of the media flow over MBMS. In particular, they are not interpreted by the MCPTT server as MBMS listening status reports.