10.6.2 On-network group call

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.6.2.1 General

This subclause contains procedures for group call across a single and multiple MCPTT servers, and associated functions such as emergency call, broadcast call and others.

Two variations of group call model are described in subclause 10.6.2.3, the pre-arranged group call and the chat group call. Each of the subsequent group call types in subclause 10.6.2.4 onwards are applicable to either call model.

10.6.2.2 Information flows for group call in on-network

10.6.2.2.1 MCPTT emergency group call request

Table 10.6.2.2.1-1 describes the information flow MCPTT emergency group call request from the MCPTT client to the MCPTT server, from the MCPTT server to the MCPTT server, and from the MCPTT server to the MCPTT client.

Table 10.6.2.2.1-1 MCPTT emergency group call request information elements

Information Element	Status	Description
MCPTT ID	M	The identity of the calling party
Functional alias	O	The functional alias of the calling party
MCPTT group ID	M	The MCPTT group ID on which the call is to be conducted
Emergency indicator	M	Indicates that the group call request is an MCPTT emergency call
Alert indicator	O	Indicates whether an emergency alert is to be sent
Implicit floor request (see NOTE)	O	Indicates that the originating client requests the floor.
Requested priority	O	Priority level requested for the call.
Location	O	Location of the calling party
NOTE: This element shall be included only when this information flow is from the client to the server or from the server to the server and the originating client requests the floor.

10.6.2.2.1a MCPTT emergency group call response

Table 10.6.2.2.1a-1 describes the information flow MCPTT emergency group call response from the MCPTT client to the MCPTT server, from the MCPTT server to the MCPTT server, and from the MCPTT server to the MCPTT client.

Table 10.6.2.2.1a-1 MCPTT emergency group call response information elements

Information Element	Status	Description
MCPTT ID	M	The identity of the calling party
MCPTT group ID	M	The MCPTT group ID on which the call is to be conducted
Result	M	Result of the MCPTT emergency group call request (success or failure)

10.6.2.2.2 MCPTT in-progress emergency group state cancel request

Table 10.6.2.2.2-1 describes the information flow MCPTT in-progress emergency group state cancel request from the MCPTT client to the MCPTT server, from the MCPTT server to the MCPTT server and from the MCPTT server to the MCPTT client.

NOTE: In Rel-14 and Rel-13 versions of this specification the name of this information flow is "MCPTT emergency group call cancel request".

Table 10.6.2.2.2-1: MCPTT in-progress emergency group state cancel request information elements

Information Element	Status	Description
MCPTT ID	M	The identity of the cancelling party
MCPTT group ID	M	The MCPTT group ID on which the MCPTT in-progress emergency state is to be cancelled.
Alert indicator	O	Indicates whether the emergency alert of the cancelling party is to be cancelled

10.6.2.2.2a MCPTT in-progress emergency group state cancel response

Table 10.6.2.2.2a-1 describes the information flow MCPTT in-progress emergency group state cancel response from the MCPTT server to the MCPTT client, from the MCPTT server to the MCPTT server and from the MCPTT client to the MCPTT server.

NOTE: In Rel-14 and Rel-13 versions of this specification the name of this information flow is "MCPTT emergency group call cancel response".

Table 10.6.2.2.2a-1: MCPTT in-progress emergency group state cancel response information elements

Information Element	Status	Description
MCPTT ID	M	The identity of the cancelling party
MCPTT group ID	M	The MCPTT group ID on which the MCPTT in-progress emergency in-progress is to be cancelled.
Result	M	Result of the MCPTT in-progress emergency group state cancel request (success or failure)

10.6.2.2.3 Void

10.6.2.2.3a Void

10.6.2.2.3b Void

10.6.2.2.4 Void

10.6.2.2.4a Void

10.6.2.2.5 MCPTT imminent peril group call request

Table 10.6.2.2.5-1 describes the information flow MCPTT imminent peril group call request from the MCPTT client to the MCPTT server, from the MCPTT server to the MCPTT server, and from the MCPTT server to the MCPTT client.

Table 10.6.2.2.5-1 MCPTT imminent peril group call request information elements

Information Element	Status	Description
MCPTT ID	M	The identity of the calling party
Functional alias	O	The functional alias of the calling party
MCPTT group ID	M	The MCPTT group ID on which the call is to be conducted
Imminent peril indicator	M	Indicates that the group call request is an imminent peril call
Implicit floor request (see NOTE)	O	Indicates that the originating client requests the floor
Requested priority	O	Priority level requested for the call.
Location	O	Location of the calling party
NOTE: This element shall be included only when this information flow is from the client to the server or from the server to the server and the originating client requests the floor.

10.6.2.2.5a MCPTT imminent peril group call response

Table 10.6.2.2.5a-1 describes the information flow MCPTT imminent peril group call response from the MCPTT client to the MCPTT server, from the MCPTT server to the MCPTT server, and from the MCPTT server to the MCPTT client.

Table 10.6.2.2.5a-1 MCPTT imminent peril group call response information elements

Information Element	Status	Description
MCPTT ID	M	The identity of the calling party
MCPTT group ID	M	The MCPTT group ID on which the call is to be conducted
Result	M	Result of the MCPTT imminent peril group call request (success or failure)

10.6.2.2.6 MCPTT in-progress imminent peril group state cancel request

Table 10.6.2.2.6-1 describes the information flow MCPTT in-progress imminent peril group state cancel request from the MCPTT client to the MCPTT server, from the MCPTT server to the MCPTT server, and from the MCPTT server to the MCPTT client.

NOTE: In Rel-14 and Rel-13 versions of this specification the name of this information flow is "MCPTT imminent peril group call cancel request".

Table 10.6.2.2.6-1 MCPTT in-progress imminent peril group state cancel request information elements

Information Element	Status	Description
MCPTT ID	M	The identity of the cancelling party
MCPTT group ID	M	The MCPTT group ID on which the imminent peril group state is to be cancelled

10.6.2.2.6a MCPTT in-progress imminent peril group state cancel response

Table 10.6.2.2.6a-1 describes the information flow MCPTT in-progress imminent peril group state cancel response from the MCPTT client to the MCPTT server, from the MCPTT server to the MCPTT server, and from the MCPTT server to the MCPTT client.

NOTE: In Rel-14 and Rel-13 versions of this specification the name of this information flow is "MCPTT imminent peril group call cancel response".

Table 10.6.2.2.6a-1 MCPTT in-progress imminent peril group state cancel response information elements

Information Element	Status	Description
MCPTT ID	M	The identity of the cancelling party
MCPTT group ID	M	The MCPTT group ID on which the imminent peril group state is to be cancelled
Result	M	Result of the MCPTT in-progress imminent peril group state cancel request (success or failure)

10.6.2.2.7 Group call request (MCPTT client – MCPTT server)

Table 10.6.2.2.7-1 describes the information flow group call request from the MCPTT client to the MCPTT server.

Table 10.6.2.2.7-1: Group call request information elements

Information Element	Status	Description
MCPTT ID	M	The MCPTT ID of the calling party
Functional alias	O	The functional alias of the calling party
MCPTT group ID	M	The MCPTT group ID of the group on which the call is requested
SDP offer	M	Media parameters of MCPTT clients
Implicit floor request	O	When originating client requests the floor, this element shall be included
Broadcast indicator	O	Indicates that the group call request is for a broadcast group call
Location information	O	Location of the calling party.
Requested priority	O	Application priority level requested for this call
Remotely initiated call request indicator	O	Indicates that the MCPTT group call request is a result of receiving of a remotely initiated call request and may be included only for remotely initiated call

10.6.2.2.8 Group call request (MCPTT server – MCPTT server)

Table 10.6.2.2.8-1 describes the information flow group call request between the MCPTT servers.

Table 10.6.2.2.8-1 Group call request information elements

Information Element	Status	Description
MCPTT ID	M	The MCPTT ID of the calling party
Functional alias	O	The functional alias of the calling party
MCPTT group ID	M	The MCPTT group ID of the group on which the call is initiated
SDP offer	M	Media parameters of MCPTT server
Broadcast indicator	O	Indicates that the group call request is for a broadcast group call
Implicit floor request (see NOTE)	O	Indicates that the originating client requests the floor.
Requested priority	O	Priority level requested for the call.
Location information	O	Location of the calling party
Remotely initiated call request indicator	O	Indicates that the MCPTT group call request is a result of receiving of a remotely initiated call request and may be included only for remotely initiated call
NOTE: This element shall be included only when the originating client requests the floor.

10.6.2.2.9 Group call request (MCPTT server – MCPTT client)

Table 10.6.2.2.9-1 describes the information flow group call request from the MCPTT server to the MCPTT client.

Table 10.6.2.2.9-1 Group call request information elements

Information Element	Status	Description
MCPTT ID	M	The MCPTT ID of the calling party
Functional alias	O	The functional alias of the calling party
MCPTT group ID	M	The MCPTT group ID of the group on which the call is initiated
SDP offer	M	Media parameters of MCPTT server
Broadcast indicator	O	Indicates that the group call request is for a broadcast group call
Remotely initiated call request indicator	O	Indicates that the MCPTT group call request is a result of receiving of a remotely initiated call request and may be included only for remotely initiated call

10.6.2.2.10 Group call response (MCPTT server – MCPTT client)

Table 10.6.2.2.10-1 describes the information flow group call response from the MCPTT server to the MCPTT client.

Table 10.6.2.2.10-1 Group call response information elements

Information Element	Status	Description
MCPTT ID	M	The MCPTT ID of the calling party
Functional alias	O	The functional alias of the calling party
MCPTT group ID	M	The MCPTT group ID of the group on which the call is requested
SDP answer	M	Media parameters selected
Result	M	Result of the group call request (success or failure)

10.6.2.2.11 Group call response (MCPTT server – MCPTT server)

Table 10.6.2.2.11-1 describes the information flow group call response between the MCPTT servers.

Table 10.6.2.2.11-1 Group call response information elements

Information Element	Status	Description
MCPTT ID	M	The MCPTT ID of the target MCPTT group member
Functional alias	O	The functional alias of the target MCPTT group member
MCPTT group ID	M	The MCPTT group ID of the group on which the call is requested
SDP answer	M	Media parameters selected
Result	M	Result of the group call request (success or failure)

10.6.2.2.12 Group call response (MCPTT client – MCPTT server)

Table 10.6.2.2.12-1 describes the information flow group call response from the MCPTT client to the MCPTT server.

Table 10.6.2.2.12-1 Group call response information elements

Information Element	Status	Description
MCPTT ID	M	The MCPTT ID of the target MCPTT group member
Functional alias	O	The functional alias of the target MCPTT group member
MCPTT group ID	M	The MCPTT group ID of the group on which the call is initiated
SDP answer	M	Media parameters selected
Result	M	Result of the group call request (success or failure)

10.6.2.2.13 Group call notify (MCPTT server – MCPTT client)

Table 10.6.2.2.13-1 describes the information flow group call notify from the MCPTT server to the MCPTT client.

Table 10.6.2.2.13-1 Group call notify information elements

Information Element	Status	Description
MCPTT ID	M	The MCPTT ID of the calling party
Functional alias	O	The functional alias of the calling party
MCPTT group ID	M	The MCPTT group ID of the group on which the call is requested
MCPTT ID list (see NOTE)	O	The list of the affiliated MCPTT group members who did not acknowledge the group call request
NOTE: Only applicable to acknowledged group calls.

10.6.2.2.14 Group call release request (MCPTT server – MCPTT client)

Table 10.6.2.2.14-1 describes the information flow group call release request from the MCPTT server to the MCPTT client.

Table 10.6.2.2.14-1 Group call release request information elements

Information Element	Status	Description
MCPTT ID	M	The MCPTT ID of the MCPTT group member
Functional alias	O	The functional alias of the MCPTT group member
MCPTT group ID	M	The MCPTT group ID of the group on which the call is released

10.6.2.2.14a Group call release request (MCPTT client – MCPTT server)

Table 10.6.2.2.14a-1 describes the information flow group call release request from the MCPTT client to the MCPTT server.

Table 10.6.2.2.14a-1 Group call release request information elements

Information Element	Status	Description
MCPTT ID	M	The MCPTT ID of the MCPTT group member
Functional alias	O	The functional alias of the MCPTT group member
MCPTT group ID	M	The MCPTT group ID of the group on which the call is released

10.6.2.2.15 Group call release request (MCPTT server – MCPTT server)

Table 10.6.2.2.15-1 describes the information flow group call release request between the MCPTT servers.

Table 10.6.2.2.15-1 Group call release request information elements

Information Element	Status	Description
MCPTT ID	M	The MCPTT ID of the MCPTT group member
Functional alias	O	The functional alias of the MCPTT group member
MCPTT group ID	M	The MCPTT group ID of the group on which the call is released

10.6.2.2.16 Group call release response (MCPTT client – MCPTT server)

Table 10.6.2.2.16-1 describes the information flow group call release response from the MCPTT client to the MCPTT server.

Table 10.6.2.2.16-1 Group call release response information elements

Information Element	Status	Description
MCPTT ID	M	The MCPTT ID of the MCPTT group member
Functional alias	O	The functional alias of the MCPTT group member
MCPTT group ID	M	The MCPTT group ID of the group on which the call is released

10.6.2.2.17 Group call release response (MCPTT server – MCPTT server)

Table 10.6.2.2.17-1 describes the information flow group call release response between the MCPTT servers.

Table 10.6.2.2.17-1 Group call release response information elements

Information Element	Status	Description
MCPTT ID	M	The MCPTT ID of the MCPTT group member
Functional alias	O	The functional alias of the MCPTT group member
MCPTT group ID	M	The MCPTT group ID of the group on which the call is released

10.6.2.2.18 Group call rejoin request (MCPTT client – MCPTT server)

Table 10.6.2.2.18-1 describes the information flow group call rejoin request from the MCPTT client to the MCPTT server.

Table 10.6.2.2.18-1 Group call rejoin request information elements

Information Element	Status	Description
MCPTT ID	M	The MCPTT ID of the re-joining MCPTT group member
Functional alias	O	The functional alias of the re-joining MCPTT group member
MCPTT group ID	M	The MCPTT group ID of the group on which the call is on-going
SDP offer	M	Media parameters of MCPTT client

10.6.2.2.19 Group call rejoin response (MCPTT server – MCPTT client)

Table 10.6.2.2.19-1 describes the information flow group call rejoin response from the MCPTT server to the MCPTT client.

Table 10.6.2.2.19-1 Group call rejoin response information elements

Information Element	Status	Description
MCPTT ID	M	The MCPTT ID of the MCPTT group member rejoining the group call
Functional alias	O	The functional alias of the MCPTT group member re-joining the group call
MCPTT group ID	M	The MCPTT group ID of the group on which the call is on-going
SDP answer	M	Media parameters selected
Emergency indicator	O	Indicates that the ongoing group call is an MCPTT emergency group call
Imminent peril indicator	O	Indicates that the ongoing group call is an MCPTT imminent peril group call

10.6.2.2.20 Group join request

Table 10.6.2.2.20-1 describes the information flow group join request from the MCPTT client to the MCPTT server and from the (MCPTT user’s primary) MCPTT server to the group host MCPTT server.

Table 10.6.2.2.20-1 Group join request information elements

Information Element	Status	Description
MCPTT ID	M	The MCPTT ID of the MCPTT group member joining the group communications for the group
Functional alias	O	The functional alias of the MCPTT group member joining the group communication for the group
MCPTT group ID	M	The MCPTT group ID of the group to which the group communication is requested
SDP offer	M	Media parameters of MCPTT client
Implicit floor request (see NOTE)	O	Indicates that the originating client requests the floor.
Requested priority	O	Application priority level requested for this call
NOTE: This element shall be included only when the originating client requests the floor.

10.6.2.2.21 Group join response

Table 10.6.2.2.21-1 describes the information flow group join response from the MCPTT server to the MCPTT client and from the group host MCPTT server to the (MCPTT user’s primary) MCPTT server.

Table 10.6.2.2.21-1 Group join response information elements

Information Element	Status	Description
MCPTT ID	M	The MCPTT ID of the MCPTT group member joining the group communications for the group
Functional alias	O	The functional alias of the MCPTT group member joining the group communication for the group
MCPTT group ID	M	The MCPTT group ID of the group to which the group communication is requested
SDP answer	M	Media parameters selected

10.6.2.2.22 Group call leave request (MCPTT server – MCPTT client)

Table 10.6.2.2.22-1 describes the information flow group call leave request from the MCPTT server to the MCPTT client.

Table 10.6.2.2.22-1 Group call leave request information elements

Information Element	Status	Description
MCPTT ID	M	The MCPTT ID of the MCPTT group member which has been de-affiliated
Functional alias	O	The functional alias of the MCPTT group member which has been de-affiliated
MCPTT group ID	M	The MCPTT group ID of the group on which the call is on-going

10.6.2.2.22a Group call leave request (MCPTT client – MCPTT server)

Table 10.6.2.2.22a-1 describes the information flow group call leave request from the MCPTT client to the MCPTT server.

Table 10.6.2.2.22a-1 Group call leave request information elements

Information Element	Status	Description
MCPTT ID	M	The MCPTT ID of the MCPTT group member leaving the group call
Functional alias	O	The functional alias of the MCPTT group member
MCPTT group ID	M	The MCPTT group ID of the group on which the call is on-going

10.6.2.2.23 Group call leave response (MCPTT client – MCPTT server)

Table 10.6.2.2.23-1 describes the information flow group call leave response from the MCPTT client to the MCPTT server.

Table 10.6.2.2.23-1 Group call leave response information elements

Information Element	Status	Description
MCPTT ID	M	The MCPTT ID of the MCPTT group member which has been de-affiliated
Functional alias	O	The functional alias of the MCPTT group member which has been de-affiliated
MCPTT group ID	M	The MCPTT group ID of the group on which the call is on-going

10.6.2.2.23a Group call leave response (MCPTT server – MCPTT client)

Table 10.6.2.2.23a-1 describes the information flow group call leave response from the MCPTT server to the MCPTT client.

Table 10.6.2.2.23a-1 Group call leave response information elements

Information Element	Status	Description
MCPTT ID	M	The MCPTT ID of the MCPTT group member leaving the group call
Functional alias	O	The functional alias of the MCPTT group member
MCPTT group ID	M	The MCPTT group ID of the group on which the call is on-going

10.6.2.2.24 Group interrogate request (MCPTT server – MCPTT server)

Table 10.6.2.2.24-1 describes the information flow group interrogate request between two MCPTT servers.

Table 10.6.2.2.24-1 Group interrogate request information elements

Information Element	Status	Description
MCPTT group ID	M	The MCPTT group ID of the group being interrogated

10.6.2.2.25 Group interrogate response (MCPTT server – MCPTT server)

Table 10.6.2.2.25-1 describes the information flow group interrogate response between two MCPTT servers.

Table 10.6.2.2.25-1 Group interrogate response information elements

Information Element	Status	Description
MCPTT group ID	M	The MCPTT group ID of the group being interrogated
MCPTT ID list	M	List of the MCPTT IDs for the MCPTT group members that are members of the MCPTT group ID

10.6.2.2.26 Group-broadcast group call request (MCPTT client – MCPTT server)

Table 10.6.2.2.26-1 describes the information flow group-broadcast group call request from the MCPTT client to the MCPTT server.

Table 10.6.2.2.26-1 Group-broadcast group call request information elements

Information Element	Status	Description
MCPTT ID	M	The MCPTT ID of the calling party
Functional alias	O	The functional alias of the calling party
MCPTT group ID	M	The MCPTT group ID of the group on which the call is requested
SDP offer	M	Media parameters of MCPTT clients
Implicit floor request	M	When originating client requests the floor, this element shall be included
Broadcast indicator	M	Indicates that the group call request is for a broadcast group call
Location information	O	Location of the calling party
Requested priority	O	Application priority level requested for this call

10.6.2.2.27 Group-broadcast group call request (MCPTT server – MCPTT client)

Table 10.6.2.2.27-1 describes the information flow group-broadcast group call request from the MCPTT server to the MCPTT client.

Table 10.6.2.2.27-1 Group-broadcast group call request information elements

Information Element	Status	Description
MCPTT ID	M	The MCPTT ID of the calling party
Functional alias	O	The functional alias of the calling party
MCPTT group ID	M	The MCPTT group ID of the group on which the call is requested
SDP offer	M	Media parameters of MCPTT clients
Broadcast indicator	M	Indicates that the group call request is for a broadcast group call

10.6.2.2.28 Group-broadcast group call response (MCPTT client – MCPTT server)

Table 10.6.2.2.28-1 describes the information flow group-broadcast group call response from the MCPTT client to the MCPTT server.

Table 10.6.2.2.28-1 Group-broadcast group call response information elements

Information Element	Status	Description
MCPTT ID	M	The MCPTT ID of the target MCPTT group member
Functional alias	O	The functional alias of the target MCPTT group member
MCPTT group ID	M	The MCPTT group ID of the group on which the call is initiated
SDP answer	M	Media parameters selected
Result	M	Result of the group-broadcast group call request (success or failure)

10.6.2.2.29 Group-broadcast group call response (MCPTT server – MCPTT client)

Table 10.6.2.2.29-1 describes the information flow group-broadcast group call response from the MCPTT server to the MCPTT client.

Table 10.6.2.2.29-1 Group-broadcast group call response information elements

Information Element	Status	Description
MCPTT ID	M	The MCPTT ID of the calling party
Functional alias	O	The functional alias of the calling party
MCPTT group ID	M	The MCPTT group ID of the group on which the call is requested
SDP answer	M	Media parameters selected
Result	M	Result of the group-broadcast group call request (success or failure)

10.6.2.2.30 Group-broadcast group call release request (MCPTT client – MCPTT server)

Table 10.6.2.2.30-1 describes the information flow group-broadcast group call release request from the MCPTT client to the MCPTT server.

Table 10.6.2.2.30-1 Group-broadcast group call release request information elements

Information Element	Status	Description
MCPTT ID	M	The MCPTT ID of the MCPTT group member
Functional alias	O	The functional alias of the MCPTT group member
MCPTT group ID	M	The MCPTT group ID of the group on which the call is released

10.6.2.2.31 Group-broadcast group call release request (MCPTT server – MCPTT client)

Table 10.6.2.2.31-1 describes the information flow group-broadcast group call release request from the MCPTT server to the MCPTT client.

Table 10.6.2.2.31-1 Group-broadcast group call release request information elements

Information Element	Status	Description
MCPTT ID	M	The MCPTT ID of the MCPTT group member
Functional alias	O	The functional alias of the MCPTT group member
MCPTT group ID	M	The MCPTT group ID of the group on which the call is released

10.6.2.2.32 Group-broadcast group call release response (MCPTT server – MCPTT client)

Table 10.6.2.2.32-1 describes the information flow group-broadcast group call release response from the MCPTT server to the MCPTT client.

Table 10.6.2.2.32-1 Group-broadcast group call release response information elements

Information Element	Status	Description
MCPTT ID	M	The MCPTT ID of the MCPTT group member
Functional alias	O	The functional alias of the MCPTT group member
MCPTT group ID	M	The MCPTT group ID of the group on which the call is released

10.6.2.2.33 Group-broadcast group call release response (MCPTT client – MCPTT server)

Table 10.6.2.2.33-1 describes the information flow group-broadcast group call release response from the MCPTT client to the MCPTT server.

Table 10.6.2.2.33-1 Group-broadcast group call release response information elements

Information Element	Status	Description
MCPTT ID	M	The MCPTT ID of the MCPTT group member
Functional alias	O	The functional alias of the MCPTT group member
MCPTT group ID	M	The MCPTT group ID of the group on which the call is released

10.6.2.2.34 Preconfigured regroup request (MCPTT client – MCPTT server)

Table 10.6.2.2.34-1 describes the information flow preconfigured regroup request from the MCPTT client to the MCPTT server.

Table 10.6.2.2.34-1 Preconfigured regroup request information elements

Information Element	Status	Description
MCPTT ID	M	The MCPTT ID of the requester
MCPTT group ID	M	MCPTT group ID of the regroup group
MCPTT group ID	M	MCPTT group ID of the MCPTT group from which configuration is to be taken
MCPTT group ID list	O (see NOTE)	List of MCPTT groups to be regrouped into the group regroup group
MCPTT user ID list	O (see NOTE)	List of MCPTT users to be regrouped into the user regroup group
Requested priority	O	Priority level requested for the call.
NOTE: One and only one of these shall be present.

10.6.2.2.35 Preconfigured regroup request (MCPTT server – MCPTT client)

Table 10.6.2.2.35-1 describes the information flow preconfigured regroup request from the MCPTT server to the MCPTT client.

Table 10.6.2.2.35-1 Preconfigured regroup request information elements

Information Element	Status	Description
MCPTT ID	M	The MCPTT ID of the target MCPTT group member
MCPTT group ID	M	MCPTT group ID of the regroup group
MCPTT group ID	M	MCPTT group ID of the MCPTT group from which configuration is to be taken
MCPTT group ID list	O (see NOTE)	List of MCPTT groups to be regrouped into the group regroup group
MCPTT user ID list	O (see NOTE)	List of MCPTT users to be regrouped into the user regroup group
NOTE: One and only one of these shall be present.

10.6.2.2.36 Preconfigured regroup request (MCPTT server – MCPTT server)

Table 10.6.2.2.36-1 describes the information flow preconfigured regroup request from the MCPTT server to the MCPTT server.

Table 10.6.2.2.36-1 Preconfigured regroup request information elements

Information Element	Status	Description
MCPTT ID	M	The MCPTT ID of the requester
MCPTT group ID	M	MCPTT group ID of the regroup group
MCPTT group ID	M	MCPTT group ID of the MCPTT group from which configuration is to be taken
MCPTT group ID list	O (see NOTE)	List of MCPTT groups to be regrouped into the group regroup group
MCPTT user ID list	O (see NOTE)	List of MCPTT users to be regrouped into the user regroup group
Requested priority	O	Priority level requested for the call.
NOTE: One and only one of these shall be present.

10.6.2.2.37 Preconfigured regroup response (MCPTT client – MCPTT server)

Table 10.6.2.2.37-1 describes the information flow preconfigured regroup response from the MCPTT client to the MCPTT server.

Table 10.6.2.2.37-1 Preconfigured regroup response information elements

Information Element	Status	Description
MCPTT ID	M	The MCPTT ID of the responding MCPTT client
MCPTT group ID	M	MCPTT group ID of the regroup group
Result	M	Result of the regrouping operation

10.6.2.2.38 Preconfigured regroup response (MCPTT server – MCPTT client)

Table 10.6.2.2.38-1 describes the information flow preconfigured regroup response from the MCPTT server to the MCPTT client.

Table 10.6.2.2.38-1 Preconfigured regroup response information elements

Information Element	Status	Description
MCPTT ID	M	The MCPTT ID of the requester of the regrouping operation
MCPTT group ID	M	MCPTT group ID of the regroup group
Result	M	Result of the regrouping operation

10.6.2.2.39 Preconfigured regroup response (MCPTT server – MCPTT server)

Table 10.6.2.2.39-1 describes the information flow preconfigured regroup response from the MCPTT server to the MCPTT server.

Table 10.6.2.2.39-1 Preconfigured regroup response information elements

Information Element	Status	Description
MCPTT ID	M	The MCPTT ID of the responding MCPTT client
MCPTT group ID	M	MCPTT group ID of the regroup group
Result	M	Result of the regrouping operation

10.6.2.2.40 Preconfigured regroup cancel request (MCPTT client – MCPTT server)

Table 10.6.2.2.40-1 describes the information flow preconfigured regroup cancel request from the MCPTT client to the MCPTT server.

Table 10.6.2.2.40-1 Preconfigured regroup cancel request information elements

Information Element	Status	Description
MCPTT ID	M	The MCPTT ID of the requester
MCPTT group ID	M	MCPTT group ID of the regroup group

10.6.2.2.41 Preconfigured regroup cancel request (MCPTT server – MCPTT client)

Table 10.6.2.2.41-1 describes the information flow preconfigured regroup cancel request from the MCPTT server to the MCPTT client.

Table 10.6.2.2.41-1 Preconfigured regroup cancel request information elements

Information Element	Status	Description
MCPTT ID	M	The MCPTT ID of the target MCPTT user or MCPTT group member
MCPTT group ID	M	MCPTT group ID of the regroup group

10.6.2.2.42 Preconfigured regroup cancel request (MCPTT server – MCPTT server)

Table 10.6.2.2.42-1 describes the information flow preconfigured regroup cancel request from the MCPTT server to the MCPTT server.

Table 10.6.2.2.42-1 Preconfigured regroup cancel request information elements

Information Element	Status	Description
MCPTT ID	M	The MCPTT ID of the requester
MCPTT group ID	M	MCPTT group ID of the regroup group

10.6.2.2.43 Preconfigured regroup cancel response (MCPTT client – MCPTT server)

Table 10.6.2.2.43-1 describes the information flow preconfigured regroup cancel response from the MCPTT client to the MCPTT server.

Table 10.6.2.2.43-1 Preconfigured regroup cancel response information elements

Information Element	Status	Description
MCPTT ID	M	The MCPTT ID of the responding MCPTT client
MCPTT group ID	M	MCPTT group ID of the regroup group
Result	M	Result of the regrouping operation

10.6.2.2.44 Preconfigured regroup cancel response (MCPTT server – MCPTT client)

Table 10.6.2.2.44-1 describes the information flow preconfigured regroup cancel response from the MCPTT server to the MCPTT client.

Table 10.6.2.2.44-1 Preconfigured regroup cancel response information elements

Information Element	Status	Description
MCPTT ID	M	The MCPTT ID of the requester of the regroup removal
MCPTT group ID	M	MCPTT group ID of the regroup group
Result	M	Result of the regrouping operation

10.6.2.2.45 Preconfigured regroup cancel response (MCPTT server – MCPTT server)

Table 10.6.2.2.45-1 describes the information flow preconfigured regroup cancel response from the MCPTT server to the MCPTT server.

Table 10.6.2.2.45-1 Preconfigured regroup cancel response information elements

Information Element	Status	Description
MCPTT ID	M	The MCPTT ID of the requester of the regroup removal
MCPTT group ID	M	MCPTT group ID of the regroup group
Result	M	Result of the regroup removal operation

10.6.2.2.46 Preconfigured regroup reject (MCPTT server – MCPTT client)

Table 10.6.2.2.46-1 describes the information flow preconfigured regroup reject from the MCPTT server to the MCPTT client.

Table 10.6.2.2.46-1 Preconfigured regroup reject information elements

Information Element	Status	Description
MCPTT ID	M	The MCPTT ID of the requester of the regrouping
MCPTT group ID	M	MCPTT group ID of the regroup group
Reject reason	M	Reason for rejecting the regrouping operation

10.6.2.2.47 Preconfigured regroup reject (MCPTT server – MCPTT server)

Table 10.6.2.2.47-1 describes the information flow preconfigured regroup reject from the MCPTT server to the MCPTT server.

Table 10.6.2.2.47-1 Preconfigured regroup reject information elements

Information Element	Status	Description
MCPTT group ID	M	MCPTT group ID of the regroup group
Reject reason	M	Reason for rejecting the regrouping operation

10.6.2.3 Group call within one MCPTT system

10.6.2.3.1 Group call models

10.6.2.3.1.1 Pre-arranged group call

10.6.2.3.1.1.1 General

A pre-arranged group call is initiated by one of the affiliated group members. The initiation of a pre-arranged group call results in all other affiliated group members being invited. Media plane resources are reserved (on-demand) or a pre-established session is associated during the group call setup procedure and released (if on-demand session) or de-associated (if pre-established session) when the call is released. SIP signalling is used to setup and release pre-arranged group calls.

10.6.2.3.1.1.2 Pre-arranged group call setup

The procedure focuses on the case where an MCPTT client is initiating an MCPTT group call with unicast signalling for communicating with the affiliated MCPTT members of that group.

Procedures in figure 10.6.2.3.1.1.2-1 are the signalling control plane procedures for the MCPTT client initiating establishment of an MCPTT group call with a pre-arranged group i.e., MCPTT users on client 1, client 2 and client 3 belong to the same group which is defined in the MCPTT group management server.

Pre-conditions:

1. A pre-arranged group is an MCPTT group that is pre-defined with MCPTT group ID and member list in the group management server. All members of the group belong to the same MCPTT system.

2. It is assumed that MCPTT users on MCPTT client 1, MCPTT client 2 and MCPTT client 3 are already registered for receiving MCPTT service and affiliated. Optionally, they may have an activated functional alias to be used during the group communication.

3. Optionally the MCPTT server has subscribed to the MCPTT functional alias controlling server within the MC system for functional alias activation/de-activation updates.

4. Optionally the MCPTT user on MCPTT client 1 has bound a functional alias to the MCPTT group ID (3GPP TS 23.280 [16]).

Figure 10.6.2.3.1.1.2-1: Pre-arranged group call setup

1. User at MCPTT client 1 would like to initiate an MCPTT group call with a selected group (identified by MCPTT group ID). The MC service user may select a functional alias.

NOTE 1: MCPTT client 1 need not be aware of the affiliation status of other MCPTT clients to the group while initiating the group call.

NOTE 2: The selected functional alias is not changed during the group call, i.e. a MCPTT client uses the same functional alias until the group call is released or the MCPTT client has left the group call.

2. MCPTT client 1 sends a group call request towards the MCPTT server via the SIP core, which hosts the group selected by the user and identified by MCPTT group ID. The group call request also contains the MCPTT group ID and an SDP offer containing the MCPTT client media parameters. If there is a floor request to transmit, then the group call request contains an indication of an implicit floor request. If the MC service user of MCPTT client 1 has selected a functional alias, then the group call request contains that functional alias. If the group call request contains an implicit floor request it may also include location information.

3. The MCPTT server checks whether the user of MCPTT client 1 is authorized to initiate a group call for the selected group. If authorized and the group call is ongoing for that MCPTT group ID, the MCPTT server adds the requesting MCPTT client 1 to the existing MCPTT group call and notifies the MCPTT client 1 that the MCPTT group call is already in progress. Otherwise, MCPTT server resolves the MCPTT group ID to determine the members of that group and their affiliation status, based on the information from the group management server. The MCPTT server evaluates the applicable group call start criteria defined for this group (e.g. minimum number of affiliated members, specific members affiliated) and determines whether the group call setup can proceed.

If the functional alias is provided only in the group call request, or via binding, the MCPTT server proceeds with the value that is provided. If the functional alias is provided in both the group call request and via binding, it is up to the MCPTT server implementation to determine a value for the functional alias to be used.

If present, the MCPTT server checks whether the provided functional alias is allowed to be used and has been activated for the user.

If location information was included in the group call request, the MCPTT server checks the privacy policy of the MCPTT user to decide if the location information of MCPTT client 1 can be provided to other users on the call (refer to Annex A.3 "Authorisation to provide location information to other MCPTT users on a call when talking").

NOTE 3: MCPTT server can have already retrieved the user/group configuration data and locally cached. If the user/group configuration data is not locally cached on the MCPTT server then MCPTT server requests the user/group configuration data from the MCPTT user database/group management server.

4. MCPTT server includes information that it communicates using MCPTT service, offers the same media parameters or a subset of the media parameters contained in the initial received request and sends the corresponding group call request via the SIP core towards the MCPTT clients of each of those affiliated group members. MCPTT users are notified about the incoming group call and the functional alias of the group call initiating user is displayed if present. The MCPTT server indicates whether acknowledgement is required for the call and the functional alias of the group call initiating MC service user may be displayed.

5. The receiving MCPTT clients accept the group call request, and a group call response is sent to the group host MCPTT server. This response may contain an acknowledgement. The conditions for sending acknowledgement may be based on configuration. The response may also contain a functional alias of the responding MC service user, which is verified (valid and activated for the user) by the MCPTT server.

6. MCPTT server sends the group call response including the selected media parameters to the MCPTT client 1 through the signalling path to inform about successful call establishment. The response may contain the functional alias, which may be displayed.

NOTE 4: Step 6 can occur at any time following step 4b, and prior to step 7 depending on the conditions to proceed with the call.

7. If the initiating MCPTT user requires the acknowledgement from affiliated MCPTT group members, and the required MCPTT group members do not acknowledge the call setup within a configured time (the "acknowledged call setup timeout"), then the MCPTT server may proceed with or abandon the call and then notify the initiating MCPTT user that the acknowledgements did not include all required members according to group policy from the group configuration. The MCPTT server may notify the initiating MCPTT user of all MCPTT group members who did not acknowledge the group call request within the configured time. This notification may be sent to the initiating MCPTT user by the MCPTT server more than once during the call when MCPTT users join or leave the MCPTT group call.

8. MCPTT client 1, client 2 and client 3 have successfully established media plane for communication. MCPTT floor participant 1, floor participant 2 and floor participant 3 exchange floor control information e.g., MCPTT client 1 receives the floor granted information over the established media plane assuming implicit floor control request from MCPTT client 1 while at the same time floor participants at other MCPTT client’s receive floor taken information. MCPTT client 1 indicates to the MCPTT user that the floor is available to send media, while the other MCPTT clients in the group call will be receiving that media. If audio cut-in policy is enabled for the MCPTT group, floor arbitration follows the logic defined in subclause 10.9.1.5.

NOTE 5: The clients use the same functional alias within floor control procedures as used during group call setup.

10.6.2.3.1.1.3 Release pre-arranged group call

The procedure focuses on the case where an MCPTT server initiates the termination of an ongoing MCPTT group call for all the participants of that group call, since at least one of the termination conditions are met e.g., due to hang time expiry, last participant leaving, second last participant leaving, initiator leaving, or minimum number of affiliated MCPTT group members are not present.

Procedures in figure 10.6.2.3.1.1.3-1 are the signalling control plane procedures for the MCPTT server initiating termination of an ongoing MCPTT group call.

Figure 10.6.2.3.1.1.3-1: Release pre-arranged group call

1. It is assumed that MCPTT users on MCPTT client 1, client 2 and client 3 are already part of the ongoing group call (e.g., as a result of pre-arranged group call setup).

2. MCPTT server would like to release the MCPTT group call which is ongoing e.g., due to hang time expiry, last participant leaving, second last participant leaving, initiator leaving, or minimum number of affiliated MCPTT group members are not present.

3. MCPTT server identifies the participants of the ongoing group call and generates group call release request to release ongoing session.

4. MCPTT server sends a group call release request via SIP core towards each participant of the ongoing group call.

5. MCPTT users are notified about the release of the group call.

6. MCPTT client(s) receiving group call release request, acknowledge towards the MCPTT server by sending a group call release response.

7. MCPTT client 1, client 2 and client 3 have successfully released the floor control and media plane resources associated with the group call that is terminated.

10.6.2.3.1.1.4 Late entry pre-arranged group call

Procedures in figure 10.6.2.3.1.1.4-1 are the signalling control plane procedures for the MCPTT server requesting a newly affiliated member or a member coming back from out of coverage to join an ongoing MCPTT group call.

NOTE: This procedure applies to all types of group call, including, for example, emergency call, imminent peril call and broadcast call.

Pre-condition:

1. MCPTT group is previously defined on the group management server with MCPTT users affiliated to that group. All members of the group belong to the same MCPTT system.

2. It is assumed that MCPTT users on MCPTT client 2 to MCPTT client n are on an ongoing call. Optionally, the MCPTT users may use activated functional aliases.

Figure 10.6.2.3.1.1.4-1: Late entry pre-arranged group call

1. MCPTT server determines that MCPTT client 1 which is newly affiliated or coming back from out of coverage has to be invited to join an ongoing group call (late entry).

2. MCPTT server generates group call request including the information such as MCPTT service identifier (possible for the SIP core to route the request to the MCPTT server), MCPTT group ID of the group invited to join, offer one or more media types and sends towards the MCPTT client 1 via SIP core.

3. MCPTT user at MCPTT client 1 is notified about the incoming group call.

4. Upon MCPTT user at MCPTT client 1 accepting the incoming group call request, MCPTT client 1 sends the group call response including the selected media types to the MCPTT server through the signalling path. If the incoming group call request is rejected by the MCPTT client 1, the MCPTT server should not resend the group call request. The group call response may also contain a functional alias of MCPTT client 1.

5. MCPTT client 1 is successfully added to the ongoing group call and MCPTT users at MCPTT client 1 to MCPTT client n may be notified about the MCPTT client 1 joining the group call and the functional alias of MCPTT client 1 may be displayed.

6. The floor taken with the information of the current talker is sent to MCPTT client1.

10.6.2.3.1.1.5 Rejoining call

Procedures in figure 10.6.2.3.1.1.5-1 are the signalling control plane procedures for the MCPTT client to rejoin an ongoing MCPTT group call (e.g. coming back from out of coverage).

Pre-conditions:

– It is assumed that MCPTT users on MCPTT client 2 to MCPTT client n are on an ongoing call. Optionally, the MCPTT users may use activated functional aliases.

Figure 10.6.2.3.1.1.5-1: Rejoin call

1. MCPTT client 1 has necessary information for rejoining an ongoing group call, then the MCPTT client 1 initiates group call rejoin request including the ongoing group call information. The group call rejoin request may contain a functional alias of MCPTT client 1 as selected by the MC service user.

2. MCPTT server checks whether the MCPTT client 1 can rejoin the ongoing call (e.g. based upon affiliation status) and checks the functional alias, if present.

3. MCPTT client 1 is informed that the group call rejoin is successful by sending a group call rejoin response. If the ongoing group call is emergency or imminent peril group call, the response shall contain emergency or imminent peril indicator.

4. MCPTT client 1 is successfully added to the ongoing group call and MCPTT users at MCPTT client 1 to MCPTT client n may be notified about the MCPTT client 1 joining the group call and the functional alias of MCPTT client 1 may be displayed.

5. The floor taken with the information of the current talker is sent to MCPTT client 1.

10.6.2.3.1.2 Chat group call

10.6.2.3.1.2.1 General

In a chat group (restricted) call model, the MCPTT user individually joins a group call without being invited. The establishment of a chat group (restricted) call does not result in other group members being invited.

Figure 10.6.2.3.1.2.2-1 describes the basic procedure for the MCPTT client initiating an MCPTT group call which uses the chat group (restricted) call model. Restricted means that only users that have been configured as members of the given group are allowed to join the group communications for the given group.

Chat group join mechanism:

– Each MCPTT client sends a group join request when the MCPTT user wants to participate in the group communication for the group. (This message does not impact the MCPTT user’s membership in the group; the MCPTT server will verify that the MCPTT user is an authorized member of the group.)

– The group join request may include a request to transmit. If the group join request includes a request to transmit it may also include location information. It is assumed that the group join request will be delivered from MCPTT client to MCPTT server using SIP.

– If location information was included in the group join request, the MCPTT server checks the privacy policy of the MCPTT user to decide if the location information of MCPTT client 1 can be provided to other users on the call (refer to Annex A.3 "Authorisation to provide location information to other MCPTT users on a call when talking").

– The group join request is used to indicate to the MCPTT server that the MCPTT user associated with the given MCPTT client wishes to participate i.e. begin to receive media from or send media to the group.

– The group join request shall cause the MCPTT server to generate an implicit affiliation for the MCPTT user to the group, if the user is not already affiliated to the group.

– The group join request contains the information needed to negotiate media parameters (on demand) or to associate a pre-established session between MCPTT server and MCPTT client for the group call. The group join request can take the form of a SIP invite.

– A selected functional alias is not changed by a MCPTT client during the whole participation within a chat group call, i.e. a MCPTT client uses the same functional alias selected when joining the chat group call until the chat group call is released or the MCPTT client leaves the chat group call.

Subsequent participation in a group call when the group is using the chat model:

– Once an MCPTT client successfully joins a group call which is using the chat model, the MCPTT client connects to the media plane for the call if the call is currently ongoing.

– If the MCPTT group call is not currently ongoing (i.e.: when MCPTT clients on the group call are not sending or receiving media, and the time out between floor control exchanges has expired) then the newly joined MCPTT client will only have pre-established its media parameters for the call.

– If the newly joined MCPTT user wishes to transmit media (start or re-start the call) to the other joined users of the group using the chat model, then the MCPTT client shall use a normal floor control procedure for requesting the floor.

– Since subsequent group call media transmissions are controlled using floor control signalling, additional SIP signalling messages may not be required for subsequent call stop and start.

– Each request to transmit from an MCPTT user could be viewed as a new instance of a group call for the given group when the floor idle timer expires and no media is present for an extended time.

– The MCPTT server may tear down the media plane between successive group calls using the chat model, or the MCPTT server may allow the media plane to remain up between successive group calls using the chat model depending on resources.

Leaving and releasing a chat group:

– When a user wants to leave a chat group call, the client shall send a group call leave request to the server and release the media plane.

– The server can release a chat group call by sending a group call release to all joined clients. A server initiated release also releases the media plane for all joined clients.

10.6.2.3.1.2.2 Chat group call setup

MCPTT client 1, client 2, and client 3 are served by the home MCPTT service provider in figure 10.6.2.3.1.2.2-1.

Pre-condition:

1. MCPTT user 2 and MCPTT user 3 have previously joined (affiliated) to the group. MCPTT client 1, client 2, and client 3 are registered and all users (MCPTT user 1, user 2, and user 3) have been authenticated and authorized to use the MCPTT service.

2. MCPTT client 1, MCPTT client 2 and MCPTT client 3 may have activated functional alias(es) configured to be used during the group call communication. No call is currently in progress for the group.

3. Optionally the MCPTT user on MCPTT client 1 has bound a functional alias to the MCPTT group ID (3GPP TS 23.280 [16]).

Figure 10.6.2.3.1.2.2-1: MCPTT chat group call

1. MCPTT user 1 indicates to join the group communication for the group. This may include a request to transmit.

1a. MCPTT client 1 sends a group join request with the MCPTT group ID of the desired group. It contains the MCPTT user’s MCPTT ID, the MCPTT client media parameters and optionally a functional alias. If there is a request to transmit, then the group joint request contains an indication of an implicit floor request. If the group join request includes an implicit floor request it may also include location information.

1b. The MCPTT server receives the group join request. MCPTT server generates an implicit affiliation (if the MCPTT user is not already affiliated to the group) and verifies that MCPTT user 1 is authorized to affiliate to the group by following the affiliation procedure (subclause 10.8.3 in 3GPP TS 23.280 [16]).

If present, the MCPTT server checks whether the provided functional alias is allowed to be used and has been activated for the user.

If location information was included in the group join request, the MCPTT server checks the privacy policy of the MCPTT user to decide if the location information of MCPTT client 1 can be provided to other users on the call (refer to Annex A.3 "Authorisation to provide location information to other MCPTT users on a call when talking").

1c. The MCPTT server replies with a group join response indicating the acceptance of the group join request and also returns the MCPTT server selected media parameters for the group call in the group join response.

2. If MCPTT user 1 requests to transmit, the MCPTT server establishes the media plane (if not already established) for the call. The associated floor participants for MCPTT client 1, client 2, and client 3 use the floor control procedure to initiate the call. E.g., the floor participant for MCPTT client 1 receives the MCPTT floor grant. The corresponding floor participants for MCPTT client 2 and MCPTT client 3 receive the MCPTT floor taken. If present, the functional alias of MCPTT client 1, MCPTT client 2 and MCPTT client 3 are displayed where appropriate.

3. Floor control will continue to be used by the floor participants associated with MCPTT client 1, MCPTT client 2 and MCPTT client 3 for the duration of the call. Media plane signalling using floor control will be used for subsequent calls for the group as long as one or more users are affiliated. If audio cut-in policy is enabled for the MCPTT group, floor arbitration follows the logic defined in subclause 10.9.1.5.

10.6.2.3.1.2.3 Release chat group call

The procedure describes the case where the MCPTT server releases an ongoing MCPTT group call for all the participants of that group call, since at least one of the conditions for release are met e.g. due to hang time expiry, last participant leaving, second last participant leaving, initiator leaving, or the number of affiliated MCPTT group members is below the minimum number permitted.

NOTE 1: The procedure for an MCPTT user leaving the group call is a different procedure.

Procedures in figure 10.6.2.3.1.2.3-1 are the procedures for the MCPTT server initiating the release of an ongoing MCPTT group call.

The following precondition applies:

– A group call is ongoing between MCPTT clients 1, 2 and 3

Figure 10.6.2.3.1.2.3-1: Release chat group call

1. MCPTT server would like to release the MCPTT group call which is ongoing e.g., due to hang time expiry, last participant leaving, second last participant leaving, initiator leaving, or minimum number of affiliated MCPTT group members are not present.

2. MCPTT server identifies the participants of the ongoing group call and generates group call release request to release the ongoing session.

3. MCPTT server sends a group call release request towards each participant of the ongoing group call.

NOTE 2: The group call release request can also be sent over SIP signalling on the signalling plane.

4. MCPTT users are notified about the release of the group call.

5. Optionally the MCPTT client(s) receiving group call release request, may send a group call release response to the MCPTT server.

NOTE 3: The MCPTT client can send group call release response when the group call release request is sent using a unicast bearer.

6. MCPTT client 1, client 2 and client 3 release the floor control and media plane resources associated with the group call that is released. Successful release of the group call does not affect the status of affiliation of any of the clients.

10.6.2.3.1.2.4 Late entry chat group call, newly joined group member

Procedures in figure 10.6.2.3.1.2.4-1 are those for a group member entering an ongoing MCPTT group call, i.e. performing a late entry.

Pre-conditions:

1. MCPTT user 2 and MCPTT user 3 have previously joined to the group. MCPTT client 1, client 2, and client 3 are registered and all users (MCPTT user 1, user 2, and user 3) have been authenticated and authorized to use the MCPTT service.

2. MCPTT client 1, MCPTT client 2 and MCPTT client 3 may have activated functional alias(es) configured to be used during the group call communication. MCPTT users using MCPTT client 2 and MCPTT client 3 are in an ongoing group call. MCPTT client 1 has not yet joined the group call. Optionally, the MCPTT users may use activated functional aliases.

3. MCPTT user 1 indicates to join the group communication for the group.

4. Optionally the MCPTT user on MCPTT client 1 has bound a functional alias to the MCPTT group ID (3GPP TS 23.280 [16]).

Figure 10.6.2.3.1.2.4-1: Late entry of a newly joined group member

1. MCPTT client 1 sends a group join request with the MCPTT group ID of the desired group. It contains the MCPTT user’s MCPTT ID, the MCPTT client media parameters and optionally a functional alias. If there is a request to transmit, then the group joint request contains an indication of an implicit floor request.

2. The MCPTT server receives the group join request. MCPTT server generates an implicit affiliation (if the MCPTT user is not already affiliated to the group) and verifies that MCPTT user 1 is authorized to affiliate to the group.

If present, the MCPTT server checks whether the provided functional alias is allowed to be used and has been activated for the user.

3. The MCPTT server replies with a group join response indicating the acceptance of the group join request.

4. Media plane between MCPTT client 1 and MCPTT server is established using media plane control signalling.

5. MCPTT users at MCPTT client 2 and MCPTT client 3 may be notified about the MCPTT client 1 joining the group call. The functional aliases of MCPTT client 1 is displayed, if present.

6. The MCPTT server sends a floor taken (for the current talker) to MCPTT client 1.

7. Floor control will continue to be used by the floor participants associated with MCPTT client 1, MCPTT client 2 and MCPTT client 3.

10.6.2.3.1.2.4a void

10.6.2.3.1.2.4b void

10.6.2.3.1.2.5 Late entry chat group call, MCPTT client coming back from out of coverage

Procedures in figure 10.6.2.3.1.2.5-1 are those for an MCPTT client coming back from out of coverage during an ongoing MCPTT group call.

Pre-conditions:

1. MCPTT client 1, MCPTT client 2 and MCPTT client 3 may have activated functional alias(es) configured to be used during the group call communication. MCPTT users using MCPTT client 1, MCPTT client 2 and MCPTT client 3 are in an ongoing group call when MCPTT client1 goes out of radio coverage.

2. MCPTT client1 returns from out of coverage while the group call is still ongoing.

Figure 10.6.2.3.1.2.5-1: Late entry of a MCPTT client returning from out of coverage

1. MCPTT client 1 or MCPTT server detects that MCPTT client 1 has returned from out of coverage.

NOTE 1: How the MCPTT client or MCPTT server detects that the client has returned from out of coverage is out of scope of the present document.

2. Media plane between MCPTT client 1 and MCPTT server is re-established using media plane control signalling.

NOTE 2: Depending on how long MCPTT client 1 was out of coverage, this step can include signalling from MCPTT client 1 to rejoin the chat group.

3. MCPTT server sends a floor taken (for the current talker) to MCPTT client 1.

4. MCPTT users at MCPTT client 2 and MCPTT client 3 may be notified about the MCPTT client 1 returning to the group call. The functional aliases of MCPTT client 1 is displayed, if present.

5. Floor control will continue to be used by the floor participants associated with MCPTT client 1, MCPTT client 2 and MCPTT client 3.

10.6.2.3.2 Exiting group call due to de-affiliation

Procedures in figure 10.6.2.3.2-1 are the signalling control plane procedures for the MCPTT server requesting a newly de-affiliated member to leave an ongoing MCPTT group call.

Pre-conditions:

1. MCPTT group is previously defined on the group management server with MCPTT users affiliated to that group. All members of the group belong to the same MCPTT system.

2. MCPTT users on MCPTT client 1 to MCPTT client n are on an ongoing call.

3. MCPTT client 1 has been de-affiliated from the MCPTT group.

Figure 10.6.2.3.2-1: Exiting MCPTT group call due to de-affiliation

1. MCPTT client 1 which has been de-affiliated is instructed to leave the ongoing group call.

2. MCPTT server sends a group call leave request to MCPTT client 1.

3. MCPTT user at MCPTT client 1 is notified about leaving the group call.

4. MCPTT client 1 sends the group call leave response and leaves the group call.

5. MCPTT client 1 is now removed from the ongoing group call and MCPTT users at MCPTT client 2 to MCPTT client n may be notified that MCPTT client 1 has left the group call.

10.6.2.3.3 MCPTT user leaving a group call

Procedures in figure 10.6.2.3.3-1 are the signalling control plane procedures for the MCPTT user leaving an ongoing MCPTT group call.

Pre-conditions:

1. MCPTT group is previously defined on the group management server with MCPTT users affiliated to that group. All members of the group belong to the same MC system.

2. MCPTT users on MCPTT client 1 to MCPTT client n are on an ongoing call.

3. MCPTT user 1 indicates to leave the group call.

Figure 10.6.2.3.3-1: MCPTT user leaving a group call

1. MCPTT client 1 sends a group call leave request to the MCPTT server.

2. MCPTT server sends a group call leave response to MCPTT client 1.

3. Release of floor control and media plane resources associated with the group call for MCPTT client 1.

NOTE 1: MCPTT server checks if group call termination conditions are met, e.g. hang time expiry, last participant leaving, second last participant leaving, initiator leaving, minimum number of affiliated MCPTT group members are not present. If at least one of the group call termination conditions is met, the MCPTT server releases the group call for all participants (see subclauses 10.6.2.3.1.1.3 Release pre-arranged group call and 10.6.2.3.1.2.3 Release chat group call).

4. MCPTT users at MCPTT client 2 to MCPTT client n may be notified that the MCPTT user of client 1 has left the group call. The functional alias of MCPTT client 1 is displayed, if present.

NOTE 2: The MCPTT server does not perform late entry for MCPTT users that have left the group call.

10.6.2.4 Group call involving groups from multiple MCPTT systems

10.6.2.4.1 Group call for non-broadcast temporary groups across multiple MCPTT systems

10.6.2.4.1.1 Group call setup

10.6.2.4.1.1.1 Group call setup procedure – originating side

Figure 10.6.2.4.1.1.1-1 illustrates the originating side group call involving groups from multiple MCPTT systems. It considers the scenario for group hierarchies and non-broadcast temporary groups formed by group regroup. The protocol followed may be SIP.

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 their users’ information to the primary MCPTT system.

2. The MCPTT user belongs to an MCPTT group hosted by the primary MCPTT system.

3. A non-broadcast temporary group is formed by authorized MCPTT user/dispatcher by the group regroup procedure (subclause 10.2.4.2 in 3GPP TS 23.280 [16]) and identified via a temporary MCPTT group ID.

4. The affiliated MCPTT group members of the constituent MCPTT groups have been implicitly affiliated to the temporary group.

5. The authorized MCPTT user/dispatcher created the temporary group on the MCPTT server of the primary MCPTT system.

6. The constituent groups of the temporary group may belong to MCPTT servers of the partner MCPTT systems.

Figure 10.6.2.4.1.1.1-1: Group call setup involving non-broadcast temporary groups from multiple MCPTT systems (originating)

1. The affiliated MCPTT user via MCPTT client initiates a group call with an MCPTT group ID. A group call request message with the MCPTT group ID is routed to the MCPTT server of the primary MCPTT system, which owns the group and is where the authorized MCPTT user/dispatcher created the temporary group. If the group call is for a temporary group formed by the group regroup procedure, the MCPTT group ID will be a temporary MCPTT group ID.

2. The MCPTT server of the primary MCPTT system gets the group information (either from group management server or itself) including the constituent MCPTT groups’ identities, accessible group members list of the constituent groups, and other related data.

3. The MCPTT server of the primary MCPTT system initiates directly a call request to the accessible group members using the detailed user information and/or location information. The group members upon receipt of the call request may accept or reject the call.

4. The MCPTT server of the primary MCPTT system may not have access to group members’ information of the constituent group belonging to the partner MCPTT system. For such group members, the MCPTT server of the primary MCPTT system initiates a group call request message to the MCPTT server of the partner MCPTT system with the target group’s MCPTT group ID information.

5. The MCPTT server of the partner MCPTT system further initiates a call request to the constituent group’s members as described in step 3.

6. The MCPTT server of the partner MCPTT system provides a group call response to the MCPTT server of the primary MCPTT system with success or failure result and/or detailed reason information if there is a failure.

7. The MCPTT server of the primary MCPTT system provides a group call response message to the MCPTT client of the affiliated MCPTT user upon receiving responses to the call requests sent to members of primary and partner MCPTT systems. The group call response message will consist of the success or failure result and/or detailed reason information if there is a failure.

NOTE: The group call response message is triggered depending on the conditions to proceed with the call.

8. Upon successful call setup completion a group call is established for the group members from constituent groups of multiple MCPTT servers.

10.6.2.4.1.1.2 Group call setup procedure – terminating side

The procedure in figure 10.6.2.4.1.1.2-1 illustrates the terminating side group call involving groups from multiple MCPTT systems. It considers the scenario for group hierarchies and non-broadcast temporary groups formed by group regroup. The protocol followed may be SIP.

Figure 10.6.2.4.1.1.2-1: Non-broadcast group call involving groups from multiple MCPTT systems (terminating)

1. The MCPTT server of the primary MCPTT system sends the group call request message to the MCPTT server(s) of the partner MCPTT system.

2. The MCPTT server of the partner MCPTT system determines whether to forward the group call request message to the MCPTT client(s) based on the user affiliation.

3. The MCPTT server of the partner MCPTT system forwards the group call request message to MCPTT client(s). The MCPTT server indicates whether acknowledgement is required for the call.

4. The MCPTT user is notified about the incoming MCPTT group call.

5. The receiving MCPTT client(s) accept the group call request and a group call response message is sent to the MCPTT server of the partner MCPTT system. This response may contain an acknowledgement. The conditions for sending acknowledgement may be based on configuration.

6. The MCPTT server of the partner MCPTT system forwards the group call response message to the MCPTT server of the primary MCPTT system (i.e. group hosting MCPTT server for the group call involving groups from multiple MCPTT systems).

10.6.2.4.1.2 Group call release

The procedure focuses on the case where the group host MCPTT server releases an ongoing MCPTT group call for all the participants of that group call involving groups from multiple MCPTT systems, since at least one of the release conditions are met e.g., due to hang time expiry, last participant leaving, second last participant leaving, initiator leaving, or minimum number of affiliated MCPTT group members are not present.

NOTE: The scenario of MCPTT user leaving the group call is not considered in this procedure.

Figure 10.6.2.4.1.2-1 illustrates the procedure for the MCPTT server releasing an ongoing MCPTT group call involving groups from multiple MCPTT systems.

Pre-conditions:

1. The MCPTT server of the primary MCPTT system is controlling the group call involving groups from multiple MCPTT systems.

2. The MCPTT client 1 belongs to group of the MCPTT server of the primary MCPTT system and the MCPTT client 2 and client 3 belong to the groups of the MCPTT server of the partner MCPTT system.

3. The MCPTT users on MCPTT client 1, client 2 and client 3 are already part of the ongoing group call (e.g., as a result of group call setup involving groups from multiple MCPTT systems).

Figure 10.6.2.4.1.2-1: Group call release involving groups from multiple MCPTT systems

1. The MCPTT server of primary MCPTT system would like to release the MCPTT group call which is ongoing e.g., due to hang timer expiry, last participant leaving, second last participant leaving, initiator leaving, or minimum number of affiliated MCPTT group members are not present.

2. The MCPTT server of the primary MCPTT system identifies the participants of the ongoing group call and generates group call release message to release ongoing session.

3. The MCPTT server of the primary MCPTT system initiates a group call release request message via SIP core towards each accessible participant of the ongoing group call (3a). The MCPTT server of the primary MCPTT system may not have access to group members’ information of the constituent group belonging to a partner MCPTT system. For such group members, the MCPTT server of the primary MCPTT system initiates a group call release request message (3b) to the MCPTT server(s) of the partner MCPTT system(s) with the target group’s MCPTT group ID information. The MCPTT server(s) of the partner MCPTT system(s) further initiate group call release request messages (3c-1, 3c-2) to its group’s users.

4. The MCPTT users are notified about the release of the group call.

5. The MCPTT client(s) receiving the group call release request messages provide group call release response to the MCPTT server of the primary MCPTT system. The MCPTT client(s) of the MCPTT users belonging to partner MCPTT system(s) route their responses via the MCPTT server(s) of the partner MCPTT system(s).

6. The MCPTT client 1, client 2 and client 3 have successfully released the floor control and media plane resources associated with the group call that is released.

10.6.2.4.2 Group call for non-broadcast temporary group formed by group regroup procedure involving multiple MCPTT systems via trusted mode

Figure 10.6.2.4.2-1 illustrates a group call involving a non-broadcast temporary group formed by group regroup from multiple MCPTT systems. The protocol followed may be SIP.

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 shares their users’ information to the primary MCPTT system.

2. The MCPTT user belongs to an MCPTT group hosted by the primary MCPTT system.

4. The MCPTT group members of the constituent MCPTT groups belonging to the temporary group are affiliated to participate in a group call for the temporary group.

5. The authorized MCPTT user/dispatcher created the temporary group on the MCPTT server of the primary MCPTT system.

6. The constituent groups of the temporary group may belong to MCPTT servers of the partner MCPTT systems.

Figure 10.6.2.4.2-1: Group call involving non-broadcast temporary group formed by group regroup from multiple MCPTT systems

1. The affiliated MCPTT user via MCPTT client initiates a group call with an MCPTT group ID. A group call request message with the MCPTT group ID is routed to the MCPTT server of the primary MCPTT system, which owns the temporary group formed by group regroup procedure, and is also where the authorized MCPTT user/dispatcher has created the temporary group. The MCPTT group ID will be a temporary MCPTT group ID.

3. The MCPTT server of the primary MCPTT system may interrogate the MCPTT server of the partner MCPTT system for the affiliated group 2 members.

4. The MCPTT server of the partner MCPTT system responds with a list of the affiliated group members of group 2.

NOTE 1: Steps 3 and 4 do not occur if the constituent groups’ information is available and up to date at primary MCPTT system due to the procedure for temporary group formation as defined in subclause 10.2.4.2 in 3GPP TS 23.280 [16].

5. The MCPTT server of the primary MCPTT system verifies the commencement policies of the temporary group, and initiates a call invitation or call notification to the affiliated members of groups 1 and 2.

6. The MCPTT server of the primary MCPTT system provides group call response message to the MCPTT UE of authorized MCPTT user/dispatcher upon receiving responses to the call invitations sent to members of primary and partner MCPTT systems. The group call response will consist of the success or failure result and/or detailed reason information if there is a failure.

7. Upon successful call setup completion, a group call is established for the group members belonging to constituent groups of multiple MCPTT systems.

NOTE 2: MCPTT clients are generally aware that their (constituent) groups have been regrouped (e.g., see subclause 10.1.5.3 in 3GPP TS 23.280 [16]); however, if not, the partner MCPTT server of the constituent group can also respond to a group call request with a redirection response, such as "moved temporarily" that includes the group URI of the temporary group formed by group regroup procedure.

10.6.2.4.3 Group call for an MCPTT group defined in the partner MCPTT system

10.6.2.4.3.1 Pre-arranged group call setup procedure – initiating side

Figure 10.6.2.4.3.1-1 illustrates the pre-arranged group call setup procedure for an MCPTT group defined in the partner MCPTT system.

Pre-conditions:

1. MCPTT group is defined on the group management server which is located in the partner MCPTT system with MCPTT users affiliated to that group.

2. The members of the MCPTT group defined in partner MCPTT system belong to different MCPTT systems.

Figure 10.6.2.4.3.1-1: Pre-arranged group call setup for an MCPTT group defined in partner MCPTT system (initiating)

2. The MCPTT server of the primary MCPTT system determines the group home MCPTT server where the MCPTT group is defined.

3. The MCPTT server of the primary MCPTT system forwards the group call request to the MCPTT server of the partner MCPTT system which owns the group and is where the authorized MCPTT user/dispatcher created the temporary group.

4. The MCPTT server of the partner MCPTT system checks whether the user of MCPTT client is authorized for initiating the group call for the selected group. If authorized, it resolves the MCPTT group ID to determine the members of that group and their affiliation status, based on the information from group management server.

5. The MCPTT server of the partner MCPTT system initiates a call request to the group’s affiliated members.

6. The MCPTT server of the partner MCPTT system provides a group call response message to the MCPTT server of the primary MCPTT system of the MCPTT client. The group call response message will consist of the success or failure result and/or detailed reason information if there is a failure.

7. The MCPTT server of the primary MCPTT system forwards the group call response message to the MCPTT client.

8 Upon successful call setup completion a group call is established for the group members.

10.6.2.4.3.2 Pre-arranged group call setup – terminating side

The procedure described in figure 10.6.2.4.3.2-1 is used for pre-arranged group call setup when acknowledgement is required from at least some of the call recipients.

Figure 10.6.2.4.3.2-1: Pre-arranged group call setup for an MCPTT group defined in partner MCPTT system (terminating)

1. MCPTT server of the partner MCPTT system sends the group call request message towards the MCPTT server of the primary MCPTT system of the MCPTT client.

2. The MCPTT server of the primary MCPTT system determines whether to forward the group call request message to the MCPTT client based on the user profile.

3. The MCPTT server of the primary MCPTT system forwards the group call request message to MCPTT client. The MCPTT server indicates whether acknowledgement is required for the call.

4. MCPTT user is notified about the incoming group call.

5. The receiving MCPTT client accepts the group call and a response message is sent to the MCPTT server of the primary MCPTT system. This response may contain an acknowledgement. The conditions for sending acknowledgement may be based on configuration.

6. The MCPTT server of the primary MCPTT system forwards the response message to the MCPTT server of the partner MCPTT system (i.e. group hosting MCPTT server).

10.6.2.4.3.3 Chat group call setup

Figure 10.6.2.4.3.3-1 illustrates the group call setup procedure for an MCPTT chat group defined in the partner MCPTT system.

Pre-conditions:

1. The MCPTT users of MCPTT clients 1, 2 and 3 are members of a chat group that is defined in the partner MCPTT system.

2. MCPTT user 2 and MCPTT user 3 have previously joined (affiliated) to the group. MCPTT client 1, client 2, and client 3 are registered and all users (MCPTT user 1, user 2, and user 3) have been authenticated and authorized to use the MCPTT service.

3. MCPTT client 1, MCPTT client 2 and MCPTT client 3 may have activated functional alias(es) configured to be used during the group call communication.

4. No call is currently in progress for the group.

5. Optionally the MCPTT user on MCPTT client 1 has bound a functional alias to the MCPTT group ID (3GPP TS 23.280 [16]).

Figure 10.6.2.4.3.3-1: Chat group call setup for an MCPTT group defined in partner MCPTT system

1. MCPTT client 1 sends a group join request with the MCPTT group ID of the desired group. If there is a request to transmit, then the group join request contains an indication of an implicit floor request.

2. The MCPTT server of the primary MCPTT system verifies that MCPTT user 1 is authorized to affiliate to the group by following the affiliation procedure (subclause 10.8.3.2 / 10.8.3.2a in 3GPP TS 23.280 [16]).The MCPTT server of the primary MCPTT system determines the group home MCPTT server where the MCPTT group is defined.

3. The MCPTT server of the primary MCPTT system forwards the group join request to the partner MCPTT server i.e. to the the group home MCPTT server.

4. The partner MCPTT server receives the group join request. The partner MCPTT server generates an implicit affiliation (if the MCPTT user 1 is not already affiliated to the group) and verifies that MCPTT user 1 is authorized to affiliate to the group by following the affiliation procedure (subclause 10.8.3 in 3GPP TS 23.280 [16]).

If present, the MCPTT server checks whether the provided functional alias is allowed to be used and has been activated for the user.

5. The MCPTT server of the partner MCPTT system replies with a group join response indicating the acceptance of the group join request and also including the MCPTT server selected media parameters for the group call.

6. The primary MCPTT server stores the affiliation status of the user for the requested MCPTT group.

7. The primary MCPTT server forwards the group join response to the MCPTT client.

8. The MCPTT user 1 requests to transmit, causing the media plane to be established (if not already established) for the call.

9. Floor control will continue to be used by the floor participants associated with MCPTT client 1, MCPTT client 2 and MCPTT client 3 for the duration of the call. Media plane signalling using floor control will be used for subsequent calls for the group as long as one or more users are affiliated.

10.6.2.4.4 Merging of groups involving multiple MCPTT systems

Figure 10.6.2.4.4-1 below illustrates the merging of MCPTT clients in a newly formed temporary group with active group calls.

Pre-conditions:

1. The temporary group consists of group 1, which is hosted by the primary MCPTT system, and group 2, which is hosted by the partner MCPTT system.

2. Both group 1 and group 2 have active calls.

3. The group management client of the authorized MCPTT user belongs to the primary MCPTT system.

Figure 10.6.2.4.4-1: Merging of groups involving multiple MCPTT systems

1. The temporary group formation – group regrouping involving multiple MCPTT systems, according to subclause 10.2.4.2 in 3GPP TS 23.280 [16], takes place.

2. The MCPTT client of the authorized MCPTT user requests group call merge operation to MCPTT server hosting group 1. The identities of the groups being combined are included in this message.

3. The MCPTT server (primary) responds with an OK response.

4. The MCPTT server (primary) sends a group combine request to the MCPTT server (partner) that is hosting group 2.

5. The MCPTT server (partner) responds with a list members of group 2 and an indication of which members are affiliated and which are active in the call.

6. The MCPTT server (primary) contacts the active members of group 2 inviting them to join the temporary group call.

7. The MCPTT server (partner) transfers group 2’s floor status data (including pending requests and queue positions) to the primary MCPTT server and combines this with the group 1’s floor status data in order to create the temporary group’s floor status data.

8. The MCPTT server (primary) performs floor control for the temporary group.

9. The MCPTT server (primary) notifies the MCPTT client of the authorised MCPTT user that the active calls have been merged.

NOTE: The MCPTT server in primary system revokes and queues floor given to one of the two talkers based on the arbitration result for the temporary group.

10.6.2.5 Broadcast group call

10.6.2.5.1 General

A broadcast group call is a special group call where the initiating MCPTT user expects no response from the other MCPTT users, so that when his transmission is complete, so is the call.

10.6.2.5.2 Common broadcast group call procedure

The group-broadcast group and the broadcast regrouped group are similar in structure (a collection of groups). Similarly the user-broadcast group and the pre-arranged group (a collection of users) are similar in structure. Only the call originator can transmit media during the broadcast group call and the broadcast group call is released when the transmission is complete, unless the call originator is overridden.

Figure 10.6.2.5.2-1 illustrates the common procedure for group-broadcast group call, user-broadcast group call, and broadcast regrouped group call.

Pre-conditions:

1. MCPTT client 1 and MCPTT client 2 are members of a group-broadcast group/user-broadcast group/broadcast regroup group.

2. Optionally, MCPTT client 1 may have an activated functional alias for the group communication.

3. The MCPTT server may have subscribed to the MCPTT functional alias controlling server within the MC system for functional alias activation/de-activation updates.

Figure 10.6.2.5.2-1: Broadcast group call

1. MCPTT user at MCPTT client 1 initiates the broadcast group call setup procedure with the indication of broadcast group call. The signalling procedure is identical to the group call setup as described in subclause 10.6.2 with the inclusion of the parameter for broadcast group call indicator. The MCPTT user at MCPTT client 1 may include a functional alias used for the broadcast group call and the MCPTT server checks whether the provided functional alias can be used and has been activated for the MCPTT user.

NOTE 1: Broadcast group call applies to both pre-arranged and chat group call model. In the chat group call model case, the broadcast group call setup procedure is done by floor control signalling.

2. MCPTT client 1 starts to transmit media.

NOTE 2: Only the call originating MCPTT user is allowed to transmit media on broadcast group call, unless overridden.

NOTE 3: A broadcast group call transmitted on a user-broadcast group has priority over group calls involving users within the user hierarchy. A broadcast group call transmitted on a group-broadcast group has priority over group calls on its subordinate groups.

3. If the media transmission from call originating MCPTT user is complete, the broadcast group call is released.

10.6.2.5.2.1 Group-broadcast group call procedure

The group-broadcast group is defined as a set of groups, not a set of MCPTT users. The group-broadcast group is also defined with a hierarchy. It is expected that the MCPTT user that originates the group-broadcast group call is the only one transmitting media during the group-broadcast group call and that the group-broadcast group call is terminated when the transmission is complete. However, if the override feature is enabled, then the call originator may be overridden.

Figure 10.6.2.5.2.1-1 illustrates the procedure for group-broadcast group call establishment.

Pre-conditions:

1. The group (e.g. A) to which MCPTT client 1 and MCPTT client 2 are members is a subordinate group of the group-broadcast group (i.e., the group-broadcast group was defined with group A as a subordinate group).

2. The group (e.g. A) currently has an on-going MCPTT group call that is not an MCPTT emergency group call.

3. The call initiator of the group-broadcast group is a member of another group (e.g., X, not group A) which is also a subordinate group of the group-broadcast group (i.e., the group-broadcast group was defined with group X as a subordinate group).

4. The group-broadcast group and its subordinated groups are defined in the same group management server and served by the same MCPTT server.

5. Optionally, MCPTT client 3 may have an activated functional alias for the group communication.

6. The MCPTT server may have subscribed to the MCPTT functional alias controlling server within the MC system for functional alias activation/de-activation updates.

Figure 10.6.2.5.2.1-1: Group-broadcast group call

1. MCPTT user at MCPTT client 3 initiates the group-broadcast group call setup procedure.

2. The MCPTT client 3 sends a group-broadcast group call request to the MCPTT server. The MCPTT user at MCPTT client 1 may include a functional alias used for the broadcast group call.

3. The MCPTT server checks whether the provided functional alias can be used and has been activated for the MCPTT user. The MCPTT server needs to resolve the group-broadcast group ID into its subordinate groups in order to contact the affiliated MCPTT users of those subordinate groups.

4. The MCPTT server then needs to consider any on-going group calls on those subordinate groups because this may affect the behaviour for what happens next. In this case a group call exists on a subordinate group. Thus, the MCPTT users involved in the group call on this subordinate group.

5. Optionally the on-going group call on a subordinate group may be terminated in which case the MCPTT client 1 and MCPTT client 2 need to be sent a Group call release request.

6. The MCPTT client 1 and MCPTT client 2 then notify their users of the group call release request.

7. The MCPTT client 1 and MCPTT client 2 respond to the group call release request by sending a group call release response.

8. A group-broadcast group call request is sent to both the MCPTT client 1 and the MCPTT client 2. The request may contain the functional alias of the calling party.

9. MCPTT client 1 and MCPTT client 2 notify their users of the incoming group-broadcast group call. The functional alias of the calling party, if available, is presented to the users.

10. MCPTT client 1 and MCPTT client 2 respond to the group-broadcast group call request by sending a group-broadcast group call response.

11. The MCPTT server responds to MCPTT client 3 (the call initiator) that the group-broadcast group call has been established by sending a group-broadcast group call response.

12. The MCPTT client 3 notifies its user that the user can begin transmitting using the group-broadcast group call resources.

Resources are now available for the transmission from MCPTT client 3 to MCPTT client 1 and MCPTT client 2. Once the user of MCPTT cleint 3 completes transmitting, the group-broadcast group call is releases as are the resources.

10.6.2.5.2.2 Group-broadcast group call procedure when a subordinate group has an on-going MCPTT emergency group call

The group-broadcast group is defined as a set of groups, not MCPTT users. The affiliated MCPTT group members of a subordinate group with an on-going MCPTT emergency group call are not interrupted by a group-broadcast group call.

Figure 10.6.2.5.2.2-1 illustrates the procedure for group-broadcast group call when a subordinate group has an on-going MCPTT emergency group call.

Pre-conditions:

1. MCPTT The group (e.g. A) to which MCPTT client 1 and MCPTT client 2 are members is a subordinate group of the group-broadcast group (i.e., the group-broadcast group was defined with group A as a subordinate group).

2. The group (e.g. A) currently has an on-going MCPTT emergency group call.

3. The call initiator (user of MCPTT client 3) of the group-broadcast group is a member of another group (e.g., X, not group A) which is also a subordinate group of the group-broadcast group (i.e., the group-broadcast group was defined with group X as a subordinate group).

Figure 10.6.2.5.2.2-1: Group-broadcast group call when an emergency group call is on-going in one of the subordinate groups

1. The MCPTT user at MCPTT client 3 initiates the group-broadcast group call setup procedure.

2. The MCPTT client 3 sends a group-broadcast group call request to the MCPTT server.

3. The MCPTT server needs to resolve the group-broadcast group ID into its subordinate groups in order to contact the affiliated MCPTT group members of those subordinate groups.

4. The MCPTT server then considers any on-going group calls on those subordinate groups (e.g. A) because this may effect the behaviour for what happens next. In this case an emergency group call exists on a subordinate group.

NOTE: Not shown – The group-broadcast group call request is sent to the MCPTT clients of the MCPTT users who are affiliated members of any other subordinate groups of the group-broadcast group being set up

5. The MCPTT server responds to the call initiator that the group-broadcast group call has been established.

6. The MCPTT client 3 notifies its user that the user can begin transmitting using the group-broadcast group call resources.

Resources are now available for the transmission from MCPTT client 3 to the MCPTT clients (not shown) of other subordinate groups (i.e., not A). Once the user of MCPTT cleint 3 completes transmitting, the group-broadcast group call is releases as are the resources.

10.6.2.5.2.3 Group-broadcast group call release procedure

When the call originator has completed transmitting, the group-broadcast group call is terminated and resources released.

Figure 10.6.2.5.2.3-1 illustrates the procedure for group-broadcast group call release.

Pre-conditions:

1. An on-going group-broadcast group call involving MCPTT client 1, MCPTT client 2, and MCPTT client 3 exists.

Figure 10.6.2.5.2.3-1: Group-broadcast group call transmission ended

1. MCPTT user on MCPTT client 3 finished transmitting.

2. A group-broadcast group call release request is sent to the MCPTT server of the group-broadcast group.

3. The MCPTT users of MCPTT client 1 and MCPTT client 2 of the group-broadcast group’s subordinate groups are sent a group-broadcast group call release request

4. MCPTT client 1 and MCPTT client 2 notify their users that the group-broadcast group call has ended.

5. MCPTT client 1 and MCPTT client 2 respond to confirm the release of the group-broadcast group call by sending a group-broadcast group call release response.

6. The MCPTT server sends a group-broadcast group call release response indicating to the initiator that the call is now terminated.

10.6.2.5.2.4 Server-initiated broadcast group call release procedure

In a broadcast group call, when the call originator has completed transmitting, the MCPTT client releases the floor. Upon receiving the floor release message the MCPTT server then determines if the broadcast call should be released.

Figure 10.6.2.5.2.4-1 illustrates the procedure for server-initiated broadcast group call release.

Pre-conditions:

1. An on-going broadcast group call involving MCPTT client 1, MCPTT client 2, and MCPTT client 3 exists.

2. MCPTT client 3 is transmitting.

Figure 10.6.2.5.2.4-1: Server-initiated broadcast group call release

1. MCPTT user on MCPTT client 3 finished transmitting.

2. MCPTT client 3 sends a Floor release message to the MCPTT server of the group.

3. The MCPTT Server determines that the group is a broadcast group and decides that the call should be released.

NOTE 1: Whether the MCPTT server uses the Broadcast indicator in the originating group call request message or uses the configured Group call hang timer to determine whether the call should be released is left to implementation.

4. The MCPTT server sends a Group call release request to MCPTT clients 1, 2, and 3.

5. MCPTT client 1 and MCPTT client 2 notify their users that the group call has ended.

6. MCPTT clients 1, 2, and 3 respond to confirm the release of the group call by sending a group call release response.

NOTE 2: If the group call release request is sent from the MCPTT server via MBMS, no response is expected from the MCPTT clients.

10.6.2.5.3 Void

10.6.2.5.4 Group call for broadcast temporary groups across multiple MCPTT systems

Figure 10.6.2.5.4-1 illustrates the procedure for broadcast temporary group calls across multiple MCPTT systems.

Pre-conditions:

2. A broadcast temporary group is formed on the MCPTT server of the primary MCPTT system by an authorized MCPTT user (e.g. dispatcher) by the group regroup procedure (subclause 10.2.4.2 in 3GPP TS 23.280 [16]) and identified via a temporary MCPTT group ID.

3. The affiliated MCPTT group members of the constituent MCPTT groups have been implicitly affiliated to the temporary group.

4. The MCPTT user of the MCPTT client is authorized to transmit on a broadcast temporary group.

5. One or more of the constituent groups of the temporary group may belong to MCPTT servers of partner MCPTT systems.

Figure 10.6.2.5.4-1: Group call involving a broadcast temporary group across multiple MCPTT systems

1. The MCPTT user via MCPTT client initiates a group call for a broadcast temporary group with an MCPTT group ID, temporary group indicator, and the broadcast indicator. A group call request message with the MCPTT group ID is routed to the MCPTT server of the primary MCPTT system, which owns the group and is where the authorized MCPTT user/dispatcher created the broadcast temporary group. The MCPTT group ID is a temporary MCPTT group ID.

2. The MCPTT server of the primary MCPTT system obtains the temporary group information (either from group management server or itself) including the constituent MCPTT groups’ identities, accessible group members list of the constituent groups, the broadcast group type, and other related data.

5. The MCPTT server of the partner MCPTT system further initiates a call request to the clients of the constituent group’s members as described in step 3.

NOTE 1: The group call response message is triggered depending on the conditions to proceed with the call.

8. Upon successful call setup completion a broadcast group call is established for the group members from constituent groups of multiple MCPTT servers. The call originating MCPTT user starts transmitting media to other group call participants. The media is also distributed to the partner MCPTT system.

NOTE 2: Only the call originating MCPTT user is allowed to transmit media on a broadcast temporary group call.

9. At the completion of the media transmission, the broadcast temporary group call is released.

10.6.2.6 Emergency and imminent peril procedures

10.6.2.6.1 MCPTT emergency group call

10.6.2.6.1.1 MCPTT emergency group call commencement

The procedure describes the case where an MCPTT client is initiating an MCPTT emergency group call with the affiliated MCPTT members of that MCPTT group. An MCPTT client in the MCPTT emergency state gains elevated access privilege for all of the MCPTT user’s mission critical applications. Initiating an MCPTT emergency group call puts the MCPTT group into the in-progress emergency state. While in the in-progress emergency state, all MCPTT group calls in the MCPTT group are processed as MCPTT emergency group calls by the MCPTT server until the in-progress emergency state of the MCPTT group is cancelled.

Figure 10.6.2.6.1.1-1 shows the procedures for the MCPTT client initiating establishment of an MCPTT emergency group call with an MCPTT group i.e., MCPTT users on MCPTT client 1, MCPTT client 2 and MCPTT client 3 belong to the same MCPTT group which is defined on MCPTT group management server.

NOTE 1: For simplicity, a single MCPTT server is shown in place of a user home MCPTT server and a group hosting MCPTT server.

Pre-conditions:

1. The MCPTT group is previously defined on the group management server with MCPTT client 2 and MCPTT client 3 affiliated to that MCPTT group.

2. All members of the MCPTT group belong to the same MCPTT system.

3. The initiating MCPTT client 1 has been provisioned with an MCPTT group that has been designated via provisioning as the MCPTT emergency group.

4. Optionally, MCPTT client 1 may use an activated functional alias for the group communication.

5. The MCPTT server may have subscribed to the MCPTT functional alias controlling server within the MC system for functional alias activation/de-activation updates.

NOTE 2: Alternatively, the client could have been provisioned for emergency behaviour on the selected group.

Figure 10.6.2.6.1.1-1: MCPTT emergency group call

1. The user at the MCPTT client 1 initiates an MCPTT emergency group call. MCPTT client 1 sets its MCPTT emergency state. The MCPTT user at MCPTT client 1 may select a functional alias used for the call. The MCPTT emergency state of MCPTT client 1 is retained until explicitly cancelled by the user of MCPTT client 1.

NOTE 3: While MCPTT client 1 is in the emergency state, all MCPTT group and private calls initiated by MCPTT client 1 are initiated as MCPTT emergency calls.

2. MCPTT client 1 sends an MCPTT emergency group call request towards the MCPTT server. The MCPTT server records the identity of the MCPTT user that initiated the MCPTT emergency group call until the MCPTT emergency state of the group is cancelled. Once an MCPTT emergency call has been initiated, the MCPTT group is considered to be in an in-progress emergency state until the emergency state of the group is cancelled. If configured to send an MCPTT emergency alert when initiating an MCPTT emergency group call, the request also contains an indication that an MCPTT emergency alert is to be initiated. The request may contain an indication of an implicit floor request.

NOTE 4: While the MCPTT group is in the in-progress emergency state, all MCPTT group calls within the group are processed as emergency group calls by the MCPTT server. MCPTT group members that are not in the emergency state do not indicate emergency in group call requests but set the requested priority of all group call requests to high priority.

3. The MCPTT server implicitly affiliates MCPTT client 1 to the emergency group if the client is not already affiliated.

4. MCPTT server checks whether the MCPTT user of MCPTT client 1 is authorized for initiation of MCPTT emergency calls on the indicated MCPTT group, and if authorized, it resolves the MCPTT group ID to determine the members of that MCPTT group and their affiliation status, based on the information from group management server. The MCPTT server checks whether the provided functional alias, if present, can be used and has been activated for the user.

5. The MCPTT server configures the priority of the underlying bearers for all participants in the MCPTT group.

NOTE 5: Successive calls during the MCPTT group’s in-progress emergency state will all receive the adjusted bearer priority.

6. MCPTT server sends the MCPTT emergency group call request towards the MCPTT clients of each of those affiliated MCPTT group members. The request contains an indication of the in-progress emergency. The request contains an indication of an MCPTT emergency alert if the request from the originator indicated MCPTT emergency alert.

7. MCPTT users are notified of the incoming MCPTT emergency group call. The functional alias of the group call initiating MCPTT user may be displayed.

8. The receiving MCPTT clients send the MCPTT emergency group call response to the MCPTT server to acknowledge the MCPTT emergency group call request. For a multicast call, these acknowledgements are not sent. The receiving MCPTT client check whether it is already involved in an MCPTT emergency group call when using this functional alias and whether the maximum number of parallel MCPTT emergency group calls when using this functional alias has been reached.

9. The MCPTT server sends the MCPTT emergency group call response to the MCPTT user 1 to inform the successful MCPTT emergency call establishment.

NOTE 6: Step 9 can occur at any time following step 5, and prior to step 10 depending on the conditions to proceed with the call.

MCPTT client 1, MCPTT client 2 and MCPTT client 3 have successfully established media plane for communication. MCPTT floor participant 1, floor participant 2 and floor participant 3 exchange floor control information e.g., MCPTT client 1 receives the floor granted information over the established media plane, while the other MCPTT client’s receive floor taken information. MCPTT client 1 indicates to the MCPTT user that the floor is available to send media, while the other MCPTT clients in the MCPTT emergency group call will be receiving that media. MCPTT client 1 can override other clients in the call except those that are also in the MCPTT emergency state.

10.6.2.6.1.2 MCPTT group call upgraded to an MCPTT emergency group call

The procedure focuses on the case where an authorized MCPTT user is upgrading an MCPTT group call to an MCPTT emergency group call while the MCPTT group call is already in progress.

Procedures in figure 10.6.2.6.1.2-1 are the signalling control plane procedures for the MCPTT client upgrading an MCPTT group call on an MCPTT group to an MCPTT emergency group call.

NOTE 1: For simplicity, a single MCPTT server is shown in place of a user home MCPTT server and a group hosting MCPTT server.

Pre-conditions:

1. The MCPTT group is previously defined on the group management server with MCPTT client 2 and MCPTT client 3 affiliated to that MCPTT group.

2. All members of the MCPTT group belong to the same MCPTT system.

3. An MCPTT group call is already in progress.

4. The initiating MCPTT client 1 has been configured to send an MCPTT emergency alert when upgrading an MCPTT emergency group call.

Figure 10.6.2.6.1.2-1: MCPTT group call upgraded to an MCPTT emergency group call

1. The MCPTT user at MCPTT client 1 initiates a group emergency. MCPTT client 1 sets its MCPTT emergency state. The MCPTT emergency state of MCPTT client 1 is retained until explicitly cancelled by the user of MCPTT client 1.

NOTE 2: While MCPTT client 1 is in the emergency state, all MCPTT group and private calls initiated by MCPTT client 1 are initiated as MCPTT emergency calls.

2. MCPTT client 1 requests the MCPTT server to upgrade the MCPTT group to an in-progress emergency state by sending an MCPTT emergency group call request. If configured to send an MCPTT alert when initiating an MCPTT emergency upgrade, the request also contains an indication that an MCPTT alert is to be initiated. The request may contain an indication of an implicit floor request.

NOTE 3: While the MCPTT group is in the in-progress emergency state, all MCPTT group calls within the group are processed as emergency group calls by the MCPTT server. MCPTT group members that are not in the emergency state do not indicate emergency in group call requests but set the requested priority of all group call requests to high priority.

3. The MCPTT server adjusts the priority of the underlying bearer for all or selected participants in the MCPTT group call that receive the communication over unicast.

NOTE 4: The determination of the selected participants whose bearers have to be upgraded is left to implementation.

4. MCPTT server sends the MCPTT emergency group call request towards the MCPTT clients of each of those affiliated MCPTT group members. The request contains an indication of an MCPTT emergency alert if the request from the originator indicated MCPTT emergency alert.

5. MCPTT users are notified of the in-progress emergency state of the MCPTT group.

6. The receiving MCPTT clients send the MCPTT emergency group call response to the MCPTT server to acknowledge the MCPTT group emergency request. For a multicast call, these acknowledgements are not sent.

7. The MCPTT server sends the MCPTT emergency group call response to the MCPTT user 1 to confirm the upgrade request.

NOTE 5: Step 7 can occur at any time following step 3, and prior to step 8 depending on the conditions to proceed with the call.

MCPTT client 1, MCPTT client 2 and MCPTT client 3 continue with the MCPTT group call, which has been transformed into an MCPTT emergency group call. MCPTT client 1 can override other clients in the call except those that are also in the MCPTT emergency state.

10.6.2.6.1.3 MCPTT in-progress emergency group state cancel

NOTE 1: In Rel-14 and Rel-13 versions of this specification the title of this subclause is "MCPTT emergency group call cancel".

The procedure describes the case where an MCPTT client cancels an MCPTT group’s in-progress emergency state. The emergency state of the group may alternatively be cancelled by the emergency alert cancellation procedure specified in 3GPP TS 23.280 [16], subclause 10.10.1.2.2.2.

Procedures in figure 10.6.2.6.1.3-1 are the signalling control plane procedures for the MCPTT client cancelling an in-progress emergency of a group.

NOTE 2: For simplicity, a single MCPTT server is shown in place of a user home MCPTT server and a group hosting MCPTT server.

NOTE 3: The end of the MCPTT emergency group call does not cancel the MCPTT group’s in-progress emergency state. It is explicitly cancelled by an authorized user using this procedure, or by the emergency alert cancellation procedure specified in 3GPP TS 23.280 [16], subclause 10.10.1.2.2.2.

Pre-conditions:

1. The MCPTT group is previously defined on the group management server with MCPTT client 2 and MCPTT client 3 affiliated to that MCPTT group.

2. All members of the MCPTT group belong to the same MCPTT system.

3. MCPTT group members have been notified about the in-progress emergency.

4. The MCPTT group is in the in-progress emergency state and has prioritized bearer support when a call is in progress.

5. MCPTT client 1 is authorized to cancel an in-progress emergency for the group.

Figure 10.6.2.6.1.3-1: MCPTT in-progress emergency group state cancel

1. The user at the MCPTT client 1 initiates an MCPTT in-progress emergency group state cancel.

NOTE 4: An authorized user (e.g. dispatcher, supervisor) can cancel either or both the in-progress emergency state of the group and the MC service emergency alert of another user. However, only the initiator of an MCPTT emergency alert can cancel the initiator’s local MCPTT emergency state. Determination of authorized users is implementation dependent.

2. MCPTT client 1 sends an MCPTT in-progress emergency group state cancel request to the MCPTT server.

NOTE 5: If an MCPTT emergency alert relating to MCPTT client 1 is in effect together with an MCPTT in-progress emergency group state on the MCPTT group, the MCPTT emergency alert of MCPTT client 1 can be cancelled at the same time. In that case, the MCPTT in-progress emergency group state cancel request carries an indication that the emergency alert of MCPTT client 1 is also being cancelled.

NOTE 6: If an MCPTT in-progress emergency group state cancel request is received by the MCPTT server while a group member that is in the emergency state is transmitting, the MCPTT in-progress emergency group state cancel request is rejected by the MCPTT server.

3. MCPTT server resolves the MCPTT group ID to determine the members of that MCPTT group and their affiliation status, based upon the information from group management server.

4. The MCPTT server verifies that the user of MCPTT client 1 is authorized to cancel the emergency state of this MCPTT group. The MCPTT server cancels/resets the in-progress emergency state of the MCPTT group.

5. If a call is currently in progress, the MCPTT server adjusts the priority of the underlying bearer; priority treatment is no longer required.

6. The MCPTT server sends an MCPTT in-progress emergency group state cancel request to the MCPTT group members.

7. MCPTT group members are notified of the MCPTT in-progress emergency group state cancel.

8. The receiving MCPTT clients send the MCPTT in-progress emergency group state cancel response to the MCPTT server to acknowledge the MCPTT in-progress emergency group state cancel. For a multicast call scenario, these acknowledgements are not sent.

9. The MCPTT server sends the MCPTT in-progress emergency group state cancel response to the MCPTT user 1 to confirm the MCPTT in-progress emergency group state cancel. If the MCPTT in-progress emergency group state cancel request (in step 2) contained the "Alert indicator" IE, the MCPTT client 1 resets its local emergency status.

NOTE 7: Step 9 can occur at any time following step 4, depending on the conditions to proceed with the call.

10.6.2.6.2 MCPTT imminent peril group call

10.6.2.6.2.1 MCPTT imminent peril group call commencement

The procedure focuses on the case where an authorized MCPTT user is initiating an imminent peril group call for communicating with the affiliated MCPTT members of that MCPTT group. This procedure will gain elevated access privilege for the MCPTT client if it is not already in that state. The access privilege for other applications will not necessarily be affected.

Procedures in figure 10.6.2.6.2.1-1 are the signalling control plane procedures for the MCPTT client initiating establishment of an imminent peril group call with an MCPTT group i.e., MCPTT users on MCPTT client 1, MCPTT client 2 and MCPTT client 3 belong to the same MCPTT group which is defined on MCPTT group management server.

Pre-conditions:

1. The MCPTT group is previously defined on the group management server with MCPTT client 2 and MCPTT client 3 affiliated to that MCPTT group.

2. All members of the MCPTT group belong to the same MCPTT system.

3. The initiating MCPTT client 1 has been provisioned with an MCPTT group that has been designated in the provisioning to be used for imminent peril communications.

NOTE 1: Alternatively, the client could have been provisioned for imminent peril behaviour on the selected group.

4. Optionally, MCPTT client 1 may use an activated functional alias for the group communication.

5. The MCPTT server may have subscribed to the MCPTT functional alias controlling server within the MC system for functional alias activation/de-activation updates.

Figure 10.6.2.6.2.1-1: MCPTT imminent peril group call

1. The user at the MCPTT client 1 initiates an imminent peril group call. The MCPTT user at MCPTT client 1 may select a functional alias used for the call.

2. MCPTT client 1 sends an MCPTT imminent peril group call request towards the MCPTT server. The request contains an indication of the in-progress imminent peril. The MCPTT server records the identity of the MCPTT user that initiated the imminent peril group call until the in-progress imminent peril state is cancelled. Once an imminent peril group call has been initiated, the MCPTT group is considered to be in an in-progress imminent peril state until cancelled. The request may contain an indication of an implicit floor request. If the group call request includes an implicit floor request it may also include location information.

3. The MCPTT server implicitly affiliates MCPTT client 1 to the imminent peril group if the client is not already affiliated.

4. MCPTT server checks whether the MCPTT user of MCPTT client 1 is authorized for initiation of imminent peril group calls on the indicated MCPTT group, and if authorized, it resolves the MCPTT group ID to determine the members of that MCPTT group and their affiliation status, based on the information from group management server. The MCPTT server checks whether the provided functional alias, if present, can be used and has been activated for the user.

5. The MCPTT server configures the priority of the underlying bearers for all participants in the MCPTT group.

NOTE 2: Successive calls during the in-progress imminent peril state will all receive the adjusted bearer priority.

6. MCPTT server sends the imminent peril group call request towards the MCPTT clients of each of those affiliated MCPTT group members. The request contains an indication of the in-progress imminent peril. If location information was included in the imminent peril group call request, the MCPTT server checks the privacy policy of the MCPTT user to decide if the location information of MCPTT client 1 can be provided to other users on the call (refer to Annex A.3 "Authorisation to provide location information to other MCPTT users on a call when talking").

7. MCPTT users are notified of the incoming imminent peril call. The functional alias of the group call initiating MCPTT user may be displayed.

8. The receiving MCPTT clients send the MCPTT imminent peril group call response to the MCPTT server to acknowledge the imminent peril call request. For a multicast call, these acknowledgements are not set.

9. The MCPTT server sends the MCPTT imminent peril group call response to the MCPTT user 1 to inform the successful imminent peril call establishment.

NOTE 3: Step 9 can occur at any time following step 5, and prior to step 10 depending on the conditions to proceed with the imminent peril call.

MCPTT client 1, MCPTT client 2 and MCPTT client 3 have successfully established media plane for communication. MCPTT floor participant 1, floor participant 2 and floor participant 3 exchange floor control information e.g., MCPTT client 1 receives the floor granted information over the established media plane, while the other MCPTT clients receive floor taken information. MCPTT client 1 indicates to the MCPTT user that the floor is available to send media, while the other MCPTT clients in the imminent peril call will be receiving that media.

10.6.2.6.2.2 Imminent peril group call upgrade

The procedure focuses on the case where an authorized MCPTT user is upgrading an MCPTT group call to an imminent peril group call while the MCPTT group call is already in progress.

Procedures in figure 10.6.2.6.2.2-1 are the signalling control plane procedures for the MCPTT client upgrading an MCPTT group call on an MCPTT group to an imminent peril group call.

Pre-conditions:

1. The MCPTT group is previously defined on the group management server with MCPTT client 1, MCPTT client 2 and MCPTT client 3 affiliated to that MCPTT group.

2. All members of the MCPTT group belong to the same MCPTT system.

3. An MCPTT group call is already in progress.

Figure 10.6.2.6.2.2-1: MCPTT group call upgrade to an imminent peril group call

1. The MCPTT user at MCPTT client 1 initiates an imminent peril call.

2. MCPTT client 1 requests the MCPTT server to upgrade the MCPTT group to an in-progress imminent peril state by sending an MCPTT imminent peril group call request. The request may contain an indication of an implicit floor request. If the imminent peril group call request includes an implicit floor request it may also include location information.

3. The MCPTT server adjusts the priority of the underlying bearer for all participants in the MCPTT group.

4. The MCPTT server sends the MCPTT imminent peril group call request towards the MCPTT clients of the affiliated MCPTT group members. If location information was included in the imminent peril group call request, the MCPTT server checks the privacy policy of the MCPTT user to decide if the location information of MCPTT client 1 can be provided to other users on the call (refer to Annex A.3 "Authorisation to provide location information to other MCPTT users on a call when talking").

5. MCPTT users are notified of the in-progress imminent peril state of the MCPTT group.

6. The receiving MCPTT clients send the MCPTT imminent peril group call response to the MCPTT server to acknowledge the MCPTT imminent peril group call request. For a multicast call, these acknowledgements are not set.

7. The MCPTT server sends the MCPTT imminent peril group call response to the MCPTT user 1 to confirm the upgrade request.

NOTE: Step 7 can occur at any time following step 4, and prior to step 8 depending on the conditions to proceed with the call.

MCPTT client 1, MCPTT client 2 and MCPTT client 3 continue with the MCPTT group call, which has been transformed into an imminent peril group call.

10.6.2.6.2.3 MCPTT in-progress imminent peril group state cancel

NOTE 1: In Rel-14 and Rel-13 versions of this specification the title of this subclause is "MCPTT imminent peril group call cancel".

The procedure focuses on the case where an authorized MCPTT user cancels an MCPTT group’s in-progress imminent peril state.

Procedures in figure 10.6.2.6.2.3-1 are the signalling control plane procedures for the MCPTT client cancelling an MCPTT group’s in-progress imminent peril state.

NOTE 2: The end of the imminent peril call does not cancel the MCPTT group’s in-progress imminent peril state. It is explicitly cancelled by an authorized user using this procedure.

Pre-conditions:

1. The MCPTT group is previously defined on the group management server with MCPTT client 1, MCPTT client 2 and MCPTT client 3 affiliated to that MCPTT group.

2. All members of the MCPTT group belong to the same MCPTT system.

3. The MCPTT group is in an in-progress imminent peril state and has prioritized bearer support.

4. MCPTT group members have been notified about the MCPTT group’s in-progress imminent peril state.

5. MCPTT client 1 previously initiated the in-progress imminent peril.

Figure 10.6.2.6.2.3-1: MCPTT in-progress imminent peril group state cancel

1. The user at the MCPTT client 1 initiates an in-progress imminent peril group state cancel.

2. MCPTT client 1 sends an MCPTT in-progress imminent peril group state cancel request to the MCPTT server.

3. The MCPTT server adjusts the priority of the underlying bearer; priority treatment is no longer required. The MCPTT server cancels/resets the in-progress imminent peril group state.

4. MCPTT server resolves the MCPTT group ID to determine the members of that MCPTT group and their affiliation status, based upon the information from group management server.

5. The MCPTT server sends an MCPTT imminent peril group state cancel request to the MCPTT group members.

6. MCPTT group members are notified of the in-progress imminent peril group state cancel.

7. The receiving MCPTT group members send the MCPTT in-progress imminent peril group state cancel response to the MCPTT server to acknowledge the MCPTT in-progress imminent peril group state cancel request. For a multicast scenario, these acknowledgements are not set.

8. The MCPTT server sends the MCPTT in-progress imminent peril group state cancel response to the MCPTT user 1 to confirm the MCPTT in-progress imminent peril group state cancel request.

NOTE 3: Step 8 can occur at any time following step 4, depending on the conditions to proceed with the call.

10.6.2.6.3 MCPTT emergency alert (on-network)

The MCPTT service shall support the procedures and related information flows as specified in subclauses 10.10.1 of 3GPP TS 23.280 [5] with the following clarifications:

– The MC service client is the MCPTT client;

– The MC service server is the MCPTT server;

– The MC service group ID is the MCPTT Group ID; and

– The MC service user profile index is the MCPTT user profile index.

10.6.2.7 Location of current talker

Figure 10.6.2.7-1 shows the high level procedure to for MCPTT service to provide the location information about the current talking user to all the receiving MCPTT users.

Precondition:

1. There is on-going group call involving MCPTT client 1 and MCPTT client 2.

2. MCPTT client 1 is the current talking user.

3. MCPTT server has obtained the location information of MCPTT client 1 according to subclause 10.9 in 3GPP TS 23.280 [16].

Figure 10.6.2.7-1: Providing location information of the current talker

1. MCPTT client 1 gets the floor to transmit voice media.

2. MCPTT server checks the privacy policy (authorisation to provide location information to other MCPTT users on a call when talking, as defined in Annex A.3) of the current talking MCPTT user to decide if the location information of MCPTT client 1 can be provided to other MCPTT users on the call. MCPTT server acquires the location of the current talker from the location management server as described in subclause 10.9.3.6 in 3GPP TS 23.280[16]. Optionally, the MCPTT server acquires the location of the current talker directly from the floor request received from MCPTT client 1 in step 1.

3. MCPTT server provides the location information of MCPTT client 1 to MCPTT client 2. Optionally, the location information may be provided in the floor taken message sent to MCPTT client 2 according to subclause 10.9.1.3.1.

10.6.2.8 Void

10.6.2.8.1 Void

10.6.2.8.2 Void

10.6.2.8.3 Void

10.6.2.9 Group regroup with preconfigured group

10.6.2.9.1 General

A group regroup may be achieved by regrouping MCPTT groups into a new MCPTT regroup group which uses the configuration of a separate preconfigured MCPTT group. The MCPTT regroup group configuration needs to be provided to the relevant MCPTT group members of the MCPTT groups that will be regrouped in advance of the regrouping operation.

NOTE 1: A preconfigured group which is intended only to provide configuration for the preconfigured regroup process is identified by a parameter in the group configuration described in 3GPP TS 23.280 [16].

NOTE 2: The configuration may alternatively be taken from any MCPTT group that has been configured in the user profile of all the relevant MCPTT users who will be regrouped.

NOTE 3: Regroup groups may be defined according to the organizational structure of a mission critical organization, or by some other means which allows the MCPTT client of an authorized user to be aware of an appropriate regroup group for sets of MCPTT groups that will be regrouped together.

The preconfigured MCPTT group that provides the configuration is not used as the MCPTT regroup group itself, it only provides configuration for one or more MCPTT regroup groups. The MCPTT group ID of the regroup group is provided by the authorized user when the preconfigured regrouping is carried out.

The MCPTT regroup group can be specified to be a broadcast or non-broadcast type according to the configuration of the MCPTT group whose configuration is specified by the regroup request. The broadcast type of regroup is used for one-way communication where only an authorized MCX user is allowed to transmit and all other regroup members are only allowed to receive the communication (e.g. a call from a dispatcher to all regroup members). The non-broadcast type is used for two-way communication where all regroup members can transmit and receive (i.e, the regroup group call behaves like a normal non-broadcast group call).

These procedures provide a regrouping service for MCPTT only and are independent of group regrouping procedures specified in 3GPP TS 23.280 [16]. If the MCPTT server has been notified by the group management server that one of the MCPTT groups that has been requested for regrouping by means of this procedure has already been regrouped by the group regrouping procedure specified in 3GPP TS 23.280 [16], the MCPTT server shall reject the request for regrouping described in the following procedure.

Editor’s note: These procedures provide a regrouping service for MCPTT only; any issues arising from conflicts with similar regrouping operations for MCVideo and MCData are FFS.

10.6.2.9.2 Regroup procedures in single MCPTT system

10.6.2.9.2.1 Regroup formation using preconfigured group in single MCPTT system

Figure 10.6.2.9.2.1-1 illustrates the procedure to initiate a group regroup procedure using a preconfigured MCPTT group. The procedure takes place prior to the establishment of a group call to the regroup group.

Pre-conditions:

– MCPTT client 2 is an affiliated member of MCPTT group 1 and MCPTT client 3 is an affiliated member of MCPTT group 2.

– The MCPTT group identity and group configuration for the regroup MCPTT group have been preconfigured in MCPTT clients 2 and 3, and MCPTT clients 2 and 3 have received the relevant security related information to allow them to communicate in the regroup MCPTT group.

– MCPTT client 1 is authorized to initiated a preconfigured regroup procedure.

– MCPTT client 1 is aware of a suitable preconfigured regroup group whose configuration has been preconfigured in the MCPTT UEs of the group members who will be regrouped.

– In order to be aware whether the group is regrouped, the MCPTT server is subscribed to the group configuration in GMS.

– The GMS has subscribed group dynamic data as specified in subclause 10.1.5.5.1 from the MCPTT server using the procedures defined in subclause 10.1.5.6 in TS 23.280 [16].

Figure 10.6.2.9.2.1-1: Regroup procedure using preconfigured group in single MCPTT system

1. The authorized user of MCPTT client 1 initiates the regroup procedure, specifying the list of MCPTT groups to be regrouped (MCPTT groups 1 and 2), the MCPTT group ID of the regroup group and the MCPTT group ID of the group from which configuration information for the regroup group is to be taken.

2. MCPTT client 1 sends the preconfigured regroup request to the MCPTT server.

3. The MCPTT server checks that MCPTT client 1 is authorized to initiate a preconfigured regroup procedure, and resolves the group identities of the MCPTT groups requested in step 1. The MCPTT server also checks which group members are affiliated to MCPTT groups 1 and 2. The MCPTT server may retrieve the configuration for the regroup group from the GMS if that configuration information is not already known to the MCPTT server. The MCPTT server also checks that none of the MCPTT groups that are requested for regrouping are already regrouped by any mechanism.

NOTE 1: This procedure does not require that that the authorized user of MCPTT client 1 is a group member of MCPTT groups 1 or 2, or that the authorized user of MCPTT client 1 is an affiliated group member of MCPTT groups 1 or 2.

NOTE 2: The list of groups included in the regroup is held in dynamic data in the MCPTT server, and is not used to update group configuration information in the group management server.

4. If the MCPTT server determines that any of the groups requested for regrouping, including the regroup group, have been regrouped by other group regrouping procedures, the MCPTT server then sends a preconfigured regroup reject back to MCPTT client 1 with a reject reason indicating that one of the groups has already been regrouped, and this procedure terminates.

5. If the preconfigured regroup request is not rejected, the MCPTT server sends the preconfigured regroup requests to MCPTT clients 2 and 3 in steps 5a and 5b respectively.

NOTE 3: Only group members that are affiliated to the MCPTT groups that are to be regrouped are sent a preconfigured regroup request.

6. MCPTT clients 2 and 3 notify their users of the regrouping in steps 6a and 6b respectively.

7. MCPTT clients 2 and 3 may send the preconfigured regroup response to the MCPTT server to acknowledge the regrouping action. These acknowledgements are not sent in response to a multicast transmission of the preconfigured regroup request.

8. The MCPTT server affiliates the regrouped MCPTT clients to the regroup group.

9. The MCPTT server sends a preconfigured regroup response to MCPTT client 1.

After the group regrouping procedure, the regrouping remains in effect until explicitly cancelled by the procedure in 10.6.2.9.2.2.

MCPTT client participation in the ongoing regroup persists until the MCPTT client is no longer affiliated to any of the regrouped groups (group 1 or 2 in this procedure).

MCPTT client affiliation to the regroup group may cease when the UE’s MCPTT service ceases, e.g. when the UE is powered down, or by performing a log-off operation.

Editor’s note: Data persistence in the MCPTT client following a user log-off or power down needs further study.

10.6.2.9.2.2 Regroup cancellation in single MCPTT system

Figure 10.6.2.9.2.2-1 illustrates the procedure to cancel a regrouping that uses a preconfigured MCPTT group.

Pre-conditions:

– MCPTT clients 2 and 3 have been regrouped into an MCPTT regroup group.

– MCPTT client 1 is authorized to cancel a regrouping that uses a preconfigured MCPTT group.

– The GMS has subscribed to group dynamic data as specified in subclause 10.1.5.5.1 from the MCPTT server using the procedures defined in subclause 10.1.5.6 in TS 23.280 [16].

Figure 10.6.2.9.2.2-1: Cancel preconfigured regroup procedure in single MCPTT system

1. The authorized user of MCPTT client 1 initiates the cancellation of the regrouping that uses a preconfigured MCPTT group.

2. MCPTT client 1 sends the preconfigured regroup cancel request to the MCPTT server, specifying the MCPTT group ID of the regroup group.

3. The MCPTT server checks that MCPTT client 1 is authorized to cancel a regrouping that uses a preconfigured group regroup procedure.

4. The MCPTT server sends the preconfigured regroup cancel requests to MCPTT clients 2 and 3 (steps 4a and 4b respectively).

5. MCPTT clients 2 and 3 notify their users of the cancellation of the group regrouping in steps 5a and 5b respectively.

6. MCPTT clients 2 and 3 may send the preconfigured regroup cancel response to the MCPTT server to acknowledge the cancellation of the regrouping function. These acknowledgements are not sent in response to a multicast transmission of the preconfigured regroup cancel request.

7. The MCPTT server de-affiliates MCPTT clients 2 and 3 from the MCPTT regroup group.

8. The MCPTT server sends a preconfigured regroup cancel response to MCPTT client 1.

10.6.2.9.3 Regroup procedures in multiple MCPTT systems

10.6.2.9.3.1 Regroup formation using preconfigured group in multiple MCPTT systems

Figure 10.6.2.9.3.1-1 illustrates the procedure to initiate a regroup procedure using a preconfigured MCPTT group, where at least one of the groups to be regrouped is configured in a partner MCPTT system. The primary MCPTT system where the preconfigured group regrouping is initiated does not need to be aware of the list of group members belonging to groups whose group home system is the partner MCPTT system. If the group management server in the primary MCPTT of the regroup group shares the necessary security related parameters together with the group configuration of the MCPTT regroup group with the group management server in the partner MCPTT system and the group management server in the partner MCPTT system distributes this configuration including those security parameters to its served MCPTT users according to the procedures in 3GPP TS 23.280 [16] subclause 10.2.7, the primary MCPTT system does not need to be aware of the list of group members of the preconfigured regroup group that are receiving service in the partner MCPTT system.

The procedure takes place prior to the establishment of a group call to the regroup group.

In this procedure, any gateway MC servers in the primary or partner MCPTT systems are not shown.

Pre-conditions:

– MCPTT client 1 is authorized to initiated a preconfigured regroup procedure, and is receiving MCPTT service in the primary MCPTT system of MCPTT client 1.

– MCPTT client 2 is an affiliated member of MCPTT group 1 where MCPTT group 1 is defined in the partner MCPTT system and MCPTT client 2 is receiving service in the partner MCPTT system of MCPTT client 1.

– The MCPTT group identity and group configuration for the regroup MCPTT group have been preconfigured in MCPTT client 2, and MCPTT client 2 has received the relevant security related information to allow communication in the regroup MCPTT group.

– In order to be aware whether the group is regrouped, the MCPTT server is subscribed to the group configuration in GMS.

– The GMS has subscribed group dynamic data as specified in subclause 10.1.5.5.1 from the MCPTT server within the same MCPTT system using the procedures defined in subclause 10.1.5.6 in TS 23.280 [16].

Figure 10.6.2.9.3.1-1: Regroup procedure using preconfigured group in multiple MCPTT systems

1. The authorized user of MCPTT client 1 initiates the regroup procedure, specifying the list of MCPTT groups to be regrouped including MCPTT group 1, the MCPTT group ID of the regroup group and the MCPTT group ID of the group from which configuration information for the regroup group is to be taken.

2. MCPTT client 1 sends the preconfigured regroup request to the MCPTT server.

3. The MCPTT server checks that MCPTT client 1 is authorized to initiate a preconfigured regroup procedure, and resolves the group identities of the MCPTT groups requested in step 1. The MCPTT server also checks which group members are affiliated to the requested MCPTT groups that are homed in the primary MCPTT system. The MCPTT server identifies any partner systems which are the group home systems for MCPTT groups identified in the list of groups to be regrouped. The MCPTT server may retrieve the configuration for the regroup group from the GMS if that configuration information is not already known to the MCPTT server.

NOTE 1: This procedure does not require that that the authorized user of MCPTT client 1 is a group member of the MCPTT groups listed in the regroup request, or that the authorized user of MCPTT client 1 is an affiliated group member of any of the listed MCPTT groups.

4. The MCPTT server sends the preconfigured regroup requests to the MCPTT server in the partner MCPTT system.

5. The partner MCPTT server checks the status of any MCPTT groups hosted by that partner MCPTT server, and identifies affiliated group members of any of the identified MCPTT groups (both MCPTT groups that are hosted in the primary MCPTT system and MCPTT groups that are hosted in the partner MCPTT system) that are receiving MCPTT service in the partner MCPTT system, which include MCPTT client 2.

6. The partner MCPTT server sends the preconfigured regroup request to MCPTT client 2.

NOTE 2: Only group members that are affiliated to the MCPTT groups that are to be regrouped are sent a preconfigured regroup request.

7. MCPTT client 2 notifies the user of the regrouping.

8. MCPTT client 2 may send the preconfigured regroup response to the partner MCPTT server to acknowledge the regrouping action. This acknowledgement is not sent in response to a multicast transmission of the preconfigured regroup request.

9. The partner MCPTT server affiliates the regrouped MCPTT client 2 to the regroup group.

10. The MCPTT server sends a preconfigured regroup response to the primary MCPTT server.

11. The primary MCPTT server sends the preconfigured regroup response to MCPTT client 1.

After the group regrouping procedure, the regrouping remains in effect until explicitly cancelled by the procedure in 10.6.2.9.3.2.

MCPTT client participation in the ongoing regroup persists until the MCPTT client is no longer affiliated to any of the regrouped groups (group 1 or 2 in this procedure).

MCPTT client affiliation to the regroup group may cease when the UE’s MCPTT service ceases, e.g. when the UE is powered down, or by performing a log-off operation.

Editor’s note: Data persistence in the MCPTT client following a user log-off or power down needs further study.

10.6.2.9.3.2 Regroup cancellation using preconfigured group in multiple MCPTT systems

Figure 10.6.2.9.3.2-1 illustrates the procedure to cancel a regrouping that uses a preconfigured MCPTT group where multiple MCPTT systems were involved in the regrouping.

Pre-conditions:

– MCPTT client 2 has been regrouped into an MCPTT regroup group, and is receiving MCPTT service in the partner MCPTT system of the regroup group.

– MCPTT client 1 is authorized to cancel a regrouping that uses a preconfigured MCPTT group, and is receiving MCPTT service in the primary MCPTT system of the regroup group.

– The GMS has subscribed to group dynamic data as specified in subclause 10.1.5.5.1 from the MCPTT server within the same MCPTT system using the procedures defined in subclause 10.1.5.6 in TS 23.280 [16].

Figure 10.6.2.9.3.2-1: Cancel preconfigured regroup procedure using preconfigured group in multiple MCPTT systems

1. The authorized user of MCPTT client 1 initiates the cancellation of the regrouping that uses a preconfigured MCPTT group.

2. MCPTT client 1 sends the preconfigured regroup cancel request to the MCPTT server, specifying the MCPTT group ID of the regroup group.

3. The MCPTT server checks that MCPTT client 1 is authorized to cancel a regrouping that uses a preconfigured group regroup procedure.

4. The primary MCPTT server sends the regroup cancel request to the partner MCPTT server.

5. The partner MCPTT server sends the preconfigured regroup cancel requests to MCPTT client 2.

6. MCPTT client 2 notifies the user of the cancellation of the group regrouping.

7. MCPTT client 2 may send the preconfigured regroup remove response to the partner MCPTT server to acknowledge the cancellation of the regrouping function. This acknowledgement is not sent in response to a multicast transmission of the preconfigured regroup cancel request.

8. The partner MCPTT server de-affiliates MCPTT client 2 from the MCPTT regroup group.

9. The partner MCPTT server sends the preconfigured regroup cancel response to the primary MCPTT server.

10. The primary MCPTT server sends a preconfigured regroup cancel response to MCPTT client 1.

10.6.2.9.3.3 Regroup rejection using preconfigured group in multiple MCPTT systems

Figure 10.6.2.9.3.3-1 illustrates the case where the procedure to initiate a regroup procedure with multiple MCPTT systems using a preconfigured MCPTT group described in subclause 10.6.2.9.3.1 commences, but where the request for the regroup is rejected by the partner MCPTT server, for example because one of the groups hosted by the partner MCPTT server is already regrouped by other group regrouping procedures.

In this procedure, any gateway MC servers in the primary or partner MCPTT systems are not shown.

Pre-conditions:

– MCPTT client 1 is authorized to initiated a preconfigured regroup procedure, and is receiving MCPTT service in the primary MCPTT system of MCPTT client 1.

Figure 10.6.2.9.3.3-1: Regroup rejection using preconfigured group in multiple MCPTT systems

2. MCPTT client 1 sends the preconfigured regroup request to the MCPTT server.

3. The MCPTT server checks that MCPTT client 1 is authorized to initiate a preconfigured regroup procedure, and resolves the group identities of the MCPTT groups requested in step 1. The MCPTT server also checks which group members are affiliated to the requested MCPTT groups that are homed in the primary MCPTT system. The MCPTT server identifies any partner systems which are the group home systems for MCPTT groups identified in the list of groups to be regrouped. The MCPTT server may retrieve the configuration for the regroup group from the GMS if that configuration information is not already known to the MCPTT server.

NOTE: This procedure does not require that that the authorized user of MCPTT client 1 is a group member of the MCPTT groups listed in the regroup request, or that the authorized user of MCPTT client 1 is an affiliated group member of any of the listed MCPTT groups.

4. The MCPTT server sends the preconfigured regroup requests to the MCPTT server in the partner MCPTT system.

5. The partner MCPTT server checks the status of any MCPTT groups hosted by that partner MCPTT server, and determines that one or more requested MCPTT groups has already been regrouped by another group regrouping procedure.

6. The partner MCPTT server sends a preconfigured regroup reject to the primary MCPTT server, indicating the reason for rejection.

7. The primary MCPTT server sends a preconfigured regroup reject to MCPTT client 1, indicating the reason for rejection.

10.6.2.9.4 Adding newly affiliated user to preconfigured group regroup

Figure 10.6.2.9.4-1 illustrates the procedure to add a newly affiliated user to an in-progress preconfigured MCPTT group regroup operation.

Pre-conditions:

– The MCPTT client is a member of a MCPTT group that is part of an in-progress preconfigured group regroup operation.

– The MCPTT group identity and group configuration for the regroup MCPTT group has been preconfigured in the MCPTT client, and the MCPTT client has received the relevant security related information to allow it to communicate in the regroup MCPTT group.

Figure 10.6.2.9.4-1: Procedure to add a newly affiliated user to a preconfigured regroup

1. The MCPTT client affiliates to an MCPTT group that is currently part of an in-progress preconfigured group regroup. The affiliation follows the procedure in clause 10.8.3.1 of TS 23.280 [16].

2. The MCPTT server retrieves the MCPTT group ID of the regroup group and the MCPTT group ID of the group from which configuration information for the regroup group is to be taken.

3. The MCPTT server sends the preconfigured regroup request to the MCPTT client.

4. The MCPTT client notifies the user of the regrouping.

5. The MCPTT client may send the preconfigured regroup response to the MCPTT server to acknowledge the regrouping action. These acknowledgements are not sent in response to a multicast transmission of the preconfigured regroup request.

6. The MCPTT server affiliates the regrouped MCPTT client to the regroup group.

Editor’s Note: It is FFS whether this procedure can be generalized to apply to both preconfigured and GMS-based group regrouping.

Editor’s Note: Affiliations of the MCPTT client to the pre-configured regroup group in the MCPTT server and coordination to the MC System is FFS.

10.6.2.9.5 Preconfigured regroup update procedures

10.6.2.9.5.1 MCPTT client PTTs on MCPTT group during an in-progress preconfigured group regroup

Figure 10.6.2.9.5.1-1 illustrates the procedure when a user attempts to setup an MCPTT group call on a group involved in an in-progress preconfigured MCPTT group regroup.

Pre-conditions:

– The MCPTT client is an affiliated member of MCPTT group A that is part of an in-progress preconfigured group regroup with MCPTT groups B and C.

– MCPTT group D is being used as the preconfigured regroup group.

– The MCPTT client has missed the preconfigured regroup request message (e.g. poor signalling conditions, race condition).

Figure 10.6.2.9.5.1-1: Procedure for MCPTT client PTTs on MCPTT group during an in-progress preconfigured group regroup

1. The MCPTT client attempts to start a call on MCPTT group A. The MCPTT client sends a group call request message to the MCPTT server containing MCPTT group A as the target group.

2. The MCPTT server checks to see whether MCPTT group A is currently part of a preconfigured group regroup. In this case the group is part of an active preconfigured group regroup.

3. The MCPTT server sends a group call response to the MCPTT client indicating that the call setup is denied because the group is part of an in-progress group regroup.

4. The MCPTT server sends the preconfigured regroup request to the MCPTT client containing MCPTT group D, the group ID of the preconfigured group.

NOTE 1: This message should be sent over unicast.

5. The MCPTT client notifies the user of the group call setup failure and of the regrouping procedure.

6. The MCPTT client sends the preconfigured regroup response to the MCPTT server to acknowledge the regrouping action.

7. The MCPTT server affiliates the regrouped MCPTT client to the regroup group.

NOTE 2: If there is a call currently in progress on the regroup group then this MCPTT client can be added to the call using the late entry procedure. If there is no call currently in progress, then the MCPTT user can retry the group call setup.

10.6.2.9.5.2 MCPTT client PTTs on preconfigured regroup group after group regroup has been cancelled

Figure 10.6.2.9.5.2-1 illustrates the procedure when a user attempts to setup a MCPTT group call on a preconfigured regroup group after the preconfigured MCPTT group regroup has been cancelled.

Pre-conditions:

– The MCPTT client is a member of MCPTT group A that was part of an in-progress preconfigured group regroup with MCPTT groups B and C that has been cancelled. MCPTT group D was used as the MCPTT regroup group.

– The MCPTT client has missed the preconfigured regroup cancel request message (e.g. poor signalling conditions, race condition).

Figure 10.6.2.9.5.2-1: Procedure for MCPTT client PTTs on regroup group after the group regroup is cancelled

1. The MCPTT client attempts to start a call on MCPTT group D, the MCPTT regroup group. The MCPTT client sends a group call request message to the MCPTT server containing MCPTT group D as the target group.

2. The MCPTT server checks to see whether MCPTT group D is currently being used as part of a preconfigured group regroup. In this case the preconfigured group regroup is no longer active.

NOTE 1: The regroup group D can be a group in the MCPTT client’s profile, and the MCPTT client can be a member of group D.

3. The MCPTT server sends a group call response to the MCPTT client indicating that the call setup is denied because the group regroup is no longer active.

NOTE 2: In the following, steps 4 and 6 are optional.

4. The MCPTT server sends the preconfigured regroup cancel request to the MCPTT client.

NOTE 3: This message should be sent over unicast.

5. The MCPTT client notifies the user of the group call setup failure and of the regrouping cancellation.

6. The MCPTT client sends the preconfigured regroup cancel response to the MCPTT server to acknowledge the regrouping cancellation.

NOTE 4: If there is a call currently in progress on MCPTT group A that was previously part of the group regroup then this MCPTT client can be added to the call using the late entry procedure. If there is no call currently in progress then the MCPTT user can retry the group call setup on MCPTT group A.

10.6.2.10 User regroup using group creation procedure

10.6.2.10.1 General

User regroup using the group creation procedure can be initiated by an authorized user creating a temporary group with a list of MCPTT users. The group ID for this temporary group can be provided at the time of group creation. The temporary group can be used by all MCPTT users in the list for two-way (non-broadcast) communication until deleted by an authorized user. Optionally, the group can be used for one-way (broadcast ) communication where the creator of the temporary group can make a broadcast group call, but the other MCPTT users can only listen to the group call and cannot respond.

10.6.2.10.2 Temporary group creation and broadcast group call by authorized user

Figure 10.6.2.10.2-1 below illustrates the temporary group creation, and optional broadcast call setup procedure and temporary group deletion initiated by an authorized user.

Pre-conditions:

1. The authorized user is aware of the MCPTT users who will be included in the temporary group.

Figure 10.6.2.10.2-1: User regroup using group creation procedure

1. The authorized user of MCPTT UE 1 makes use of the group management client of MCPTT UE 1 to create the temporary group according to the group creation procedure in 3GPP TS 23.280 [16] subclause 10.2.3. The configuration identifies the group as a temporary group. As part of this procedure, the MCPTT users are notified of their membership to the temporary group, and the MCPTT server is notified about the creation of the group and the list of group members.

The authorized user can create the group as a broadcast group by configuring it as a broadcast group.

NOTE 1: After step 1 the temporary group can be used by all members of the group for two-way (non-broadcast) communication until deleted by an authorized user.

NOTE 2: The following two steps are optional and can be used for broadcast communication where only the creator of the temporary group is allowed to transmit media on this temporary group.

2. The creator of the temporary group, the authorized user of MCPTT UE 1, initiates a broadcast group call according to the procedure described in subclause 10.6.2.5.2 of the present document. The authorized user of MCPTT UE 1 is implicitly affiliated to the temporary group. The receiving MCPTT clients of MCPTT UEs 2 and 3 are implicitly affiliated to the group and are notified of this affiliation during the call setup.

3. The authorized user of MCPTT UE 1 ends the use of the temporary group according to the procedure for group deletion described in 3GPP TS 23.280 [16].

10.6.2.10.3 Temporary group deletion by authorized user

If the authorized user wishes to end the use of the temporary group, the procedure for group deletion described in 3GPP TS 23.280 [16] is followed.

10.6.2.11 Broadcast group regroup call using preconfigured group

10.6.2.11.1 General

The temporary group created using a preconfigured group can be a broadcast group or a non-broadcast group. The broadcast regroup is used for one-way communication where only an authorized MCPTT user is allowed to transmit and all other regroup members are only allowed to receive the communication (e.g. a call from a dispatcher to all regroup members). The non-broadcast regroup is used for two-way communication where all regroup members can transmit and receive (i.e. the regroup group call behaves like a normal non-broadcast group call). The broadcast regroup satisfies the temporary group-broadcast group requirements defined in 3GPP TS 22.280 [2].

A broadcast group regroup call using preconfigured groups can be achieved by first regrouping MCPTT groups into an MCPTT regroup group, making the broadcast group call on the regroup group, and then cancelling the preconfigured group regroup.

10.6.2.11.2 Broadcast group regroup call procedure using preconfigured group in a single MCPTT system

The broadcast group regroup call procedure using preconfigured group allows an authorized MCPTT user to initiate a broadcast call to a set of MCPTT groups, which are regrouped only for the duration of the broadcast call. The regroup is cancelled at the end of the broadcast call to prevent users from talking back on the regroup group. This procedure requires that the authorized MCPTT user is a group member of at least one of the MCPTT groups included in the regroup operation.

Figure 10.6.2.11.2-1 illustrates the procedure to initiate a broadcast group regroup call using a preconfigured MCPTT group.

Pre-conditions:

– MCPTT clients 1, 2, and 3 are registered with the MCPTT service.

– The group configuration for the MCPTT regroup group have been preconfigured in MCPTT clients 1, 2, and 3, and MCPTT clients 1, 2 and 3 have received the relevant security related information to allow them to communicate in the regroup MCPTT group.

– MCPTT client 1 is authorized to initiate a group regroup using the preconfigured regroup procedure.

– MCPTT client 1 is aware of a suitable preconfigured group whose configuration has been preconfigured in the MC service UEs of the MCPTT users who will be regrouped.

– MCPTT client 1 is affiliated to group 1, MCPTT client 2 is affiliated to group 2, and MCPTT client 3 is affiliated to group 3. Group 4 is used as the regroup group.

Figure 10.6.2.11.2-1: Broadcast group regroup call using preconfigured group in a single MCPTT system

1. The authorized user of MCPTT client 1 initiates the group regroup formation procedure using preconfigured groups as specified in 10.6.2.9.2.1. MCPTT groups 1, 2, and 3 are regrouped into group 4.

2. The MCPTT user at MCPTT client 1 performs the broadcast group call procedure as specified in 10.6.2.5.2.

3. If the broadcast group call is made on the regroup group 4, the MCPTT client 1 initiates the preconfigured group regroup cancellation procedure as specified in 10.6.2.9.2.2.

10.6.2.12 User regroup with preconfigured group

10.6.2.12.1 General

A user regroup may be achieved by regrouping MCPTT users into a new regroup group which uses the configuration of a separate preconfigured MCPTT group. The MCPTT regroup group configuration needs to be provided to the relevant MCPTT users who will be regrouped in advance of the regrouping operation. User regroup with preconfigured group satisfies user regroup requirements in 3GPP TS 22.180 [17], particularly [R-6.6.4.2-003].

NOTE 2: The configuration may alternatively be taken from any MCPTT group that has been configured in the user profile of all of the relevant MCPTT users who will be regrouped.

Editor’s note: These procedures provide a regrouping service for MCPTT only; any issues arising from conflicts with similar regrouping operations for MCVideo and MCData are FFS.

10.6.2.12.2 User regroup procedures in a single MCPTT system

10.6.2.12.2.1 User regroup formation in a single MCPTT system

Figure 10.6.2.12.2.1-1 illustrates the procedure to initiate a user regroup procedure using a preconfigured MCPTT group. The procedure takes place prior to the establishment of a group call to the MCPTT regroup group.

Pre-conditions:

– MCPTT clients 2 and 3 are registered with the MCPTT service.

– An MCPTT group that will be used for configuration of the temporary user regroup group has been preconfigured in MCPTT clients 2 and 3, and MCPTT clients 2 and 3 have received the relevant security related information to allow them to communicate in the temporary user regroup group.

– MCPTT client 1 is authorized to initiated a user regroup using the preconfigured regroup procedure.

– MCPTT client 1 is aware of a suitable preconfigured group whose configuration has been preconfigured in the MC service UEs of the MCPTT users who will be regrouped.

Figure 10.6.2.12.2.1-1: User regroup procedure using preconfigured group in single MCPTT system

1. The authorized user of MCPTT client 1 initiates the user regroup procedure, specifying the list of MCPTT users to be regrouped (MCPTT clients 2 and 3), the MCPTT group ID of the regroup group, and the MCPTT group ID of the group from which configuration information for the regroup group is to be taken.

2. MCPTT client 1 sends the preconfigured regroup request to the MCPTT server. The request indicates the list of users to be included in the regroup operation.

3. The MCPTT server checks that MCPTT client 1 is authorized to initiate a preconfigured regroup procedure.

NOTE 1: MCPTT clients can be involved in multiple user and group regroups simultaneously.

4. The MCPTT server sends the preconfigured regroup requests to MCPTT clients 2 and 3 in steps 4a and 4b respectively.

NOTE 2: When using multicast, the MCPTT server can periodically rebroadcast the preconfigured regroup request.

5. MCPTT clients 2 and 3 notify their users of the regrouping in steps 5a and 5b respectively.

6. MCPTT clients 2 and 3 may send the preconfigured regroup response to the MCPTT server to acknowledge the regrouping action. These acknowledgements are not sent in response to a multicast transmission of the preconfigured regroup request.

7. The MCPTT server affiliates the regrouped MCPTT clients to the regroup group.

8. The MCPTT server sends a preconfigured regroup response to MCPTT client 1.

NOTE 3: After the user regrouping procedure, the regrouping remains in effect until explicitly cancelled by the procedure in 10.6.2.12.2.2.

10.6.2.12.2.2 User regroup cancellation in single MCPTT system

Figure 10.6.2.12.2.2-1 illustrates the procedure to cancel a user regrouping that uses a preconfigured MCPTT group.

Pre-conditions:

– MCPTT clients 2 and 3 have been regrouped into an MCPTT regroup group.

– MCPTT client 1 is authorized to cancel a user regrouping that uses a preconfigured MCPTT group.

Figure 10.6.2.12.2.2-1: Cancel preconfigured user regroup procedure in single MCPTT system

1. The authorized user of MCPTT client 1 initiates the cancellation of the user regrouping that uses a preconfigured MCPTT group.

2. MCPTT client 1 sends the preconfigured regroup cancel request to the MCPTT server, specifying the MCPTT group ID of the regroup group.

3. The MCPTT server checks that MCPTT client 1 is authorized to cancel a regrouping that uses a preconfigured user regroup procedure.

4. The MCPTT server sends the preconfigured regroup cancel requests to MCPTT clients 2 and 3 (steps 4a and 4b respectively).

5. MCPTT clients 2 and 3 notify their users of the cancellation of the user regrouping in steps 5a and 5b respectively.

7. The MCPTT server de-affiliates MCPTT clients 2 and 3 from the MCPTT regroup group.

8. The MCPTT server sends a preconfigured regroup cancel response to MCPTT client 1.