4 General

24.3793GPPMission Critical Push To Talk (MCPTT) call controlProtocol specificationRelease 18TS

4.1 MCPTT overview

The MCPTT service supports communication between several users (i.e. group call), where each user has the ability to gain access to the permission to talk in an arbitrated manner. The MCPTT service also supports private calls between two users. Group calls and private calls can be provided on-network and off-network. In this release of the present document, support is only allowed for MCPTT speech communications.

The present document provides the call control protocol enhancements to support the MCPTT architectural procedures specified in 3GPP TS 23.379 [3].

For on-network calls, the present document makes use of the existing IMS procedures specified in 3GPP TS 24.229 [4], and provides new IMS application procedures specific for MCPTT. For on-network group calls, the procedures in the present document allow the use of unicast or multicast bearers. Multicast bearers are only supported in EPS.

The on-network procedures in this document allow an MCPTT user to:

– initiate a new MCPTT group call;

– join an MCPTT group call that has already been established; and

– leave an established MCPTT group call and then rejoin the same MCPTT group call if still established.

For off-network calls, the present document utilises the procedures for ProSe direct discovery for public safety; the procedures for one-to-one ProSe direct communication for Public Safety and the procedures for one-to-many ProSe direct communication for Public Safety, as specified in 3GPP TS 24.334 [28]. ProSe is only supported in EPS. The present document specifies the MCPTT Off-Network Protocol (MONP) and the MONP application procedures.

For on-network and off-network calls, the present document provides support for MCPTT emergency calls, MCPTT imminent-peril calls and MCPTT emergency alerts.

NOTE: MCPTT emergency calls do not utilise emergency bearers. Instead the EPS bearer priority of a normal bearer is adjusted.

The MCPTT procedures provided by the present document refer to:

– the floor-control procedures defined in 3GPP TS 24.380[5];

– the group management procedures defined in 3GPP TS 24.481 [31];

– the identity management procedures defined in 3GPP TS 24.482 [49];

– the security procedures defined in 3GPP TS 33.180 [78]; and

– the PS-PS access transfer procedures procedures defined in 3GPP TS 24.237 [58].

The MCPTT procedures provided by the present document access the configuration parameters provided by 3GPP TS 24.483 [45] and 3GPP TS 24.484 [50].

Codecs and media handling for MCPTT are specified in 3GPP TS 26.179 [69];

The following procedures are provided within this document:

– common procedures are specified in clause 6;

– procedures for registration in the IM CN subsystem and service authorisation are specified in clause 7;

– procedures for pre-established session establishment, modification and release are specified in clause 8;

– procedures for affiliation are specified in clause 9;

– procedures for management of functional alias in clause 9A;

– procedures for on-network and off-network group call are specified in clause 10;

– procedures for on-network and off-network private call are specified in clause 11;

– procedures for on-network and off-network emergency alert are specified in clause 12;

– location procedures are specified in clause 13;

– MBMS transmission usage procedures are specified in clause 14; and

– MCPTT service continuity procedures are specified in clause 14A.

The MCPTT UE primarily obtains access to the MCPTT service via E-UTRAN or NG-RAN, using the procedures defined in 3GPP TS 24.301 [70] and 3GPP TS 24.501 [87].

4.2 URI and address assignments

In order to support MCPTT, the following URI and address assignments are assumed:

1) the participating MCPTT function is configured to be reachable using:

a) public service identities identifying pre-established sessions on the MCPTT server serving the MCPTT user;

b) the MBMS public service identity of the participating MCPTT function; and

c) the public service identity of the participating MCPTT function serving the MCPTT user.

NOTE: For b) and c) above, the PSI values are configured with the same URI. However for the purpose of readability the names of the PSIs mentioned in b) and c) are used in the present document.

4.3 MCPTT speech

A session that contains MCPTT speech is either a full-duplex session or a half-duplex session with an SDP media component containing an audio media type with a codec suitable for conversational speech that exists between an MCPTT client and an MCPTT server.

If the MCPTT speech session is a half-duplex session, it additionally contains a media component that describes the characteristics of the media-floor control entity.

4.4 Warning Header Field

4.4.1 General

The MCPTT server can include a free text string in a SIP response to a SIP request. When the MCPTT server includes a text string in a response to a SIP INVITE request the text string is included in a Warning header field as specified in IETF RFC 3261 [24]. The MCPTT server includes the Warning code set to 399 (miscellaneous warning) and includes the host name set to the host name of the MCPTT server.

EXAMPLE: Warning: 399 "100 User not authorised to make group calls"

4.4.2 Warning texts

The text string included in a Warning header field consists of an explanatory text preceded by a 3-digit text code, according to the following format in Table 4.4.2-1.

Table 4.4.2-1 ABNF for the Warning text

warn-text =/ DQUOTE mcptt-warn-code SP mcptt-warn-text DQUOTE

mcptt-warn-code = DIGIT DIGIT DIGIT

mcptt-warn-text = *( qdtext | quoted-pair )

Table 4.4.2-2 defines the warning texts that are defined for the Warning header field when a Warning header field is included in a response to a SIP INVITE request as specified in clause 4.4.1.

Table 4.4.2-2: Warning texts defined for the Warning header field

Code		Explanatory text		Description
100		function not allowed due to <detailed reason>		The function is not allowed to this user. The <detailed reason> will be either "group definition", "access policy", "local policy", "user authorisation" or "pre-established session not supported", or can be a free text string.
101		service authorisation failed		The service authorisation of the MCPTT ID against the IMPU failed at the MCPTT server.
102		too many simultaneous affiliations		The MCPTT user already has N2 maximum number of simultaneous affiliations (see <MaxAffiliationsN2> element of user profile configuration document).
103		maximum simultaneous MCPTT group calls reached		The number of maximum simultaneous MCPTT group calls supported for the MCPTT user has been exceeded.
104		isfocus not assigned		A controlling MCPTT function has not been assigned to the MCPTT session.
105		subscription not allowed in a broadcast group call		Subscription to the conference event package rejected during a group call initiated as a broadcast group call.
106		user not authorised to join chat group		The MCPTT user is not authorised to join this chat group.
107		user not authorised to make private calls		The MCPTT user is not authorised to make private calls.
108		user not authorised to make chat group calls		The MCPTT user is not authorised to make chat group calls.
109		user not authorised to make prearranged group calls		The MCPTT user is not authorised to make group calls to a prearranged group.
110		user declined the call invitation		The MCPTT user declined to accept the call.
111		group call proceeded without all required group members		The required members of the group did not respond within the acknowledged call time, but the call still went ahead.
112		group call abandoned due to required group members not part of the group session		The group call was abandoned, as the required members of the group did not respond within the acknowledged call time.
113		group document does not exist		The group document requested from the group management server does not exist.
114		unable to retrieve group document		The group document exists on the group management server but the MCPTT server was unable to retrieve it.
115		group is disabled		The group has the <disabled> element set to "true" in the group management server.
116		user is not part of the MCPTT group		The group exists on the group management server but the requesting user is not part of this group.
117		the group identity indicated in the request is a prearranged group		The group id that is indicated in the request is for a prearranged group, but did not match the request from the MCPTT user.
118		the group identity indicated in the request is a chat group		The group id that is indicated in the request is for a chat group, but did not match the request from the MCPTT user.
119		user is not authorised to initiate the group call		The MCPTT user identified by the MCPTT ID is not authorised to initiate the group call.
120		user is not affiliated to this group		The MCPTT user is not affiliated to the group.
121		user is not authorised to join the group call		The MCPTT user identified by the MCPTT ID is not authorised to join the group call.
122		too many participants		The group call has reached its maximum number of participants.
123		MCPTT session already exists		Inform the MCPTT user that the group call is currently ongoing.
124		maximum number of private calls reached		The maximum number of private calls allowed at the MCPTT server for the MCPTT user has been reached.
125		user not authorised to make private call with automatic commencement		The MCPTT user is not authorised to make a private call with automatic commencement.
126		user not authorised to make private call with manual commencement		The MCPTT user is not authorised to make a private call with manual commencement.
127		user not authorised to be called in private call		The called MCPTT user is not allowed to be part of a private call.
128		isfocus already assigned		The MCPTT server owning an MCPTT group received a SIP INVITE request destined to the MCPTT group from another MCPTT server already assigned as the controlling MCPTT function and the MCPTT server owning the MCPTT group does not support mutual aid or supports trusted mutual aid but does not authorise trusted mutual aid.
136		authentication of the MIKEY-SAKKE I_MESSAGE failed		The MCPTT client’s application of the procedures of 3GPP TS 33.180 [78] to authenticate the received I_MESSAGE fails.
137		the indicated group call does not exist		The participating MCPTT function cannot find an ongoing group session associated with the received MCPTT session identity.
138		subscription of conference events not allowed		The controlling MCPTT function could not allow the MCPTT user to subscribe to the conference event package.
139		integrity protection check failed		The integrity protection of an XML MIME body failed.
140		unable to decrypt XML content		The XML content cannot be decrypted.
141		user unknown to the participating function		The participating function is unable to associate the public user identity with an MCPTT ID.
142		unable to determine the controlling function		The participating function is unable to determine the controlling function for the group call or private call.
143		not authorised to force auto answer		The calling user is not authorised to force auto answer on the called user.
144		user not authorised to call this particular user		The calling user is not authorised to call this particular called user.
145		unable to determine called party		The participating function was unable to determine the called party from the information received in the SIP request.
146		T-PF unable to determine the service settings for the called user		The service settings have not been uploaded by the terminating client to the terminating participating server.
147		user is authorized to initiate a temporary group call		The non-controlling MCPTT function has authorized a request from the controlling MCPTT function to authorize a user to initiate an temporary group session.
148		group is regrouped		The group hosted by a non-controlling function is part of a temporary group session as the result of the group regroup function.
149		SIP INFO request pending		The MCPTT client needs to wait for a SIP INFO request with specific content, before taking further action.
150		invalid combinations of data received in MIME body		The MCPTT client included invalid combinations of data in the SIP request.
151		user not authorised to make a private call call-back request		The MCPTT user is not authorised to make a private call call-back request.
152		user not authorised to make a private call call-back cancel request		The MCPTT user is not authorised to make a private call call-back cancel request.
153		user not authorised to call any of the users requested in the first-to-answer call		All users that were invited in the first-to-answer call cannot be involved in a private call with the inviting user.
154		user not authorised to make ambient listening call		The MCPTT user is not authorised to make an ambient listening call.
155		user not authorised to change user’s selected group		The MCPTT user is not authorised to change the selected group of the targeted user.
156		user not authorised to originate a first-to-answer call		The MCPTT user is not authorised to make a first-to-answer call.
157		user not authorised to request a remotely initiated group call		The MCPTT user is not authorised to request a remotely initiated group call.
158		user not authorised to request a remotely initiated private call		The MCPTT user is not authorised to request a remotely initiated private call.
159		user not authorised to be called by this originating user		The called user is not authorised to receive a call by this originating user.
160		user not authorised to request creation of a regroup		The user is not authorised to request creation of a regroup.
161		user not authorised to request removal of a regroup		The user is not authorised to request removal of a regroup.
162		group call abandoned due to required group members not affiliated		The group call was abandoned as the required number of affiliated group members is not met or some required members are not affiliated.
163		the group identity indicated in the request does not exist		The server determines that the group identity indicates a user or group regroup based on a preconfigured group that does not exist.
164		maximum number of service authorizations reached		The number of maximum simultaneous service authorizations for the MCPTT user has been reached.
165		group ID for regroup already in use		The group ID proposed by the client for the user/group regroup based on a preconfigured group is already in use.
166		constituent group is in an emergency call state		The proposed constituent group cannot be added to the temporary group because there is a call on the constituent group that is in an emergency state.
167		call is not allowed on the preconfigured group		Calls are not allowed on this group that is administratively designated for preconfigured group use only.
168		alert is not allowed on the preconfigured group		Alerts are not allowed on this group that is administratively designated for preconfigured group use only.
169		user is not authorised to remove regroup in an emergency state		The MCPTT user is not authorised to remove a regroup that is in an in-progress emergency state.
170		user not authorised to make a private call transfer request		The MCPTT user is not authorised to make a private call transfer request.
171		functional alias not allowed to call this particular functional alias		The calling user is not authorised to call this particular functional alias by using this activated functional alias
172		functional alias not allowed to be called from this functional alias		The called functional alias is not authorised to receive a call from the originating user using this particular Functional Alias
173		user not authorised to make a private call forwarding request		The MCPTT user is not authorized to use MCPTT private call forwarding
174		maximum number of allowed forwardings exceeded		The maximum number of allowed call forwardings has been exceeded
175		call is forwarded		The MCPTT private call that is requested to be established is released, and a new MCPTT private call is originated to the target of the call forwarding
176		user not authorized to request for binding/unbinding of a functional alias with the MCPTT group(s) for the MCPTT user		The function is not allowed to this user.
177		unable to determine target functional alias or group for creating/removing a binding information for the MCPTT user		The MCPTT server is unable to determine the targeted functional alias or group for creating/removing an binding information for the MCPTT user
178		MCPTT group binding already exists with other functional alias for the MCPTT user		The requested functional alias binding with MCPTT group already exist with other functional alias for the MCPTT user
179		service not authorized with the interconnected system		The MCPTT service is not authorized between the local and the interconnected system and is rejected in the local system
180		service not authorized by the interconnected system		The MCPTT service is not authorized between the local and the interconnected system and is rejected by the interconnected system
181		called user requires to use floor control		The called user has rejected the call request because floor control is required to be used.
182		called user requires to not use floor control		The called user has rejected the call request because floor control is required not to be used.
183		MCPTT codec required		The call requires an MCPTT defined codec to be used.
301-350				Value allocated for use in interworking (see NOTE)
NOTE: Usage of these values are described in 3GPP TS 29.379 [88]

4.5 MCPTT session identity

The MCPTT session identity is a SIP URI, which identifies the MCPTT session between:

– the MCPTT client and the participating MCPTT function;

– the participating MCPTT function and the controlling MCPTT function

– the controlling MCPTT function and the non-controlling MCPTT function; and

– the non-controlling MCPTT function and the participating MCPTT function.

The MCPTT session identity shall be a GRUU as defined in IETF RFC 5627 [72] assigned by the MCPTT server as per 3GPP TS 24.229 [4].

The MCPTT session identity identifies the MCPTT session in such a way that e.g.:

– the MCPTT user is able to subscribe to the participant information of the ongoing MCPTT session;

– the MCPTT user is able to rejoin an ongoing MCPTT session; and

– the IM CN subsystem is able to route an initial SIP request to the controlling MCPTT function.

The controlling MCPTT function allocates a unique MCPTT session identity hosted at the controlling MCPTT function for the MCPTT session at the time of session establishment.

The non-controlling MCPTT function allocates a unique MCPTT session identity hosted at the non-controlling MCPTT function for the MCPTT session at the time of session establishment.

When protection of sensitive application data is required by the MCPTT operator, the MCPTT session identity cannot contain identity information that is classed as sensitive such as the MCPTT ID or the MCPTT Group ID, as specified in clause 4.8.

The controlling MCPTT function and non-controlling MCPTT function send the MCPTT session identity towards the MCPTT client during MCPTT session establishment by including it in the Contact header field of the final SIP response to a session initiation request.

The participating MCPTT function allocates a unique MCPTT session identity hosted at the participating MCPTT function for the MCPTT session when it receives a MCPTT session identity in the Contact header field of a SIP request or a SIP response from the controlling MCPTT function or non-controlling MCPTT function and includes it in the Contact header field of the SIP request or SIP response sent towards the MCPTT client. The participating MCPTT function maintains a mapping of the MCPTT session identities it sends to the MCPTT client to the corresponding MCPTT session identities received from the controlling MCPTT function.

The MCPTT client can cache the MCPTT session identity until a time when it is no longer needed.

The MCPTT session identity is also used in floor control requests and responses as specified in 3GPP TS 24.380 [5].

4.6 MCPTT priority calls and alerts

4.6.1 MCPTT emergency group calls

MCPTT emergency group calls as defined by 3GPP TS 23.379 [3] are supported by the procedures in this specification. The following MCPTT emergency group call functionalities are described:

– MCPTT emergency group call origination;

– upgrade of an MCPTT group call to an MCPTT emergency group call; and

– in-progress group emergency cancel.

NOTE 1: In-progress group emergency cancel means the cancellation of the in-progress emergency state of the group, which is managed by the controlling MCPTT function.

The above functionalities are supported using both MCPTT prearranged group calls and MCPTT chat group calls.

Key aspects of MCPTT emergency group calls include:

– adjusted EPS bearer priority for all participants whether or not they themselves are in an emergency condition (i.e. have their MCPTT emergency state set). For unicast bearers this is achieved by using the Resource-Priority header field as specified in IETF RFC 4412 [29] with namespaces defined for use by MCPTT specified in IETF RFC 8101 [48], and for MBMS bearers this is achieved by having the participating MCPTT function adjust the ARP (priority, PVI, PCI) and executing the Modify MBMS Bearer Procedure per 3GPP TS 29.468 [42];

– pre-emptive floor control priority over MCPTT users in MCPTT emergency group calls who themselves do not have their MCPTT emergency state set;

– restoration of normal EPS bearer priority to the call participants when the in-progress emergency group state is cancelled;

– restoration of normal floor control priority participants when the in-progress emergency group state is cancelled;

– requires the MCPTT user to be authorised to either originate or cancel an MCPTT emergency group call;

– requests to originate MCPTT emergency group calls may also include an indication of an MCPTT emergency alert; and

– requests to cancel MCPTT emergency group calls may also include an indication of cancelling a previously issued MCPTT emergency alert.

There are a number of states that are key in managing these aspects of MCPTT emergency group calls, which include:

– MCPTT emergency state: as defined in 3GPP TS 22.179 [2] and 3GPP TS 23.379 [3], indicates that the MCPTT user is in a life-threatening situation. Managed by the MCPTT user of the device or an authorised MCPTT user. While the MCPTT emergency state is set on the client, all calls originated by the client will be MCPTT emergency calls, assuming the MCPTT user is authorised for MCPTT emergency calls on them.

– in-progress emergency group state: as defined in 3GPP TS 22.179 [2] and 3GPP TS 23.379 [3], indicates whether or not there is an MCPTT emergency group call ongoing on the specified group. This state is managed by the controlling MCPTT function. All group calls originated on this MCPTT group when in an in-progress emergency state are MCPTT emergency group calls until this state is cancelled, whether or not the originator is themselves in an MCPTT emergency state.

– MCPTT emergency group (MEG) state: this is an internal state managed by the MCPTT client which tracks the in-progress emergency state of the group as defined in 3GPP TS 22.179 [2] and 3GPP TS 23.379 [3] and managed by the controlling MCPTT function. Ideally, the MCPTT client would not need to track the in-progress emergency group state, but doing so enables the MCPTT client to request MCPTT emergency-level priority earlier than otherwise possible. For example, if the MCPTT user wishes to join an MCPTT emergency group call and is not in MCPTT emergency state itself, the MCPTT client should have emergency level priority. If it has knowledge of the in-progress emergency state of the group, it can request priority by including a Resource-Priority header field set to the MCPTT namespace specified in IETF RFC 8101 [48], and appropriate priority level in the SIP INVITE request (or SIP re-INVITE request).

– MCPTT emergency group call (MEGC) state: this is an internal state managed by the MCPTT client which in conjunction with the MCPTT emergency alert state aids in managing the MCPTT emergency state and related actions.

– MCPTT emergency alert (MEA) state: this is also an internal state of the MCPTT client which in conjunction with the MCPTT emergency group call state aids in managing the MCPTT emergency state and related actions.

NOTE 2: The above states and their transitions are described in Annex G.

4.6.2 MCPTT emergency private calls

MCPTT emergency private calls as defined by 3GPP TS 23.379 [3] are supported by the procedures in this specification. The following MCPTT emergency private call functionalities are specified in the present document:

– MCPTT emergency private call origination with optional MCPTT emergency alert initiation;

– upgrade of an MCPTT private call to an MCPTT emergency private; and

– cancellation of the MCPTT emergency private call priority.

Key aspects of MCPTT emergency private calls include:

– adjusted EPS bearer priority for both participants whether or not they are both in an emergency condition (i.e. both have their MCPTT emergency state set). This is achieved by using the Resource-Priority header field as specified in IETF RFC 4412 [29] with namespaces defined for use by MCPTT specified in IETF RFC 8101 [48];

– the initiator of the MCPTT emergency private call can override the other MCPTT user in the MCPTT emergency private call unless that user also has their MCPTT emergency state set;

– restoration of normal EPS bearer priority to the call according to system policy (e.g., configured time limit for the emergency priority of an MCPTT emergency private call or cancellation of the emergency condition of the private call);

– restoration of normal floor control priority participants when the emergency elevated priority is cancelled;

– requires the MCPTT user to be authorised to either originate or cancel an MCPTT emergency private call;

– requires the targeted MCPTT user to be authorised to receive an MCPTT emergency private call;

– requests to originate MCPTT emergency private calls may also include an indication of an MCPTT emergency alert; and

– the originator of the MCPTT emergency private call can request that the call use either manaual or automatic commencement mode.

There are a number of states that are key in managing these aspects of MCPTT emergency private calls, which include:

– MCPTT emergency state (MES): as defined in 3GPP TS 22.179 [2] and 3GPP TS 23.379 [3], indicates that the MCPTT user is in a life-threatening situation. Managed by the MCPTT user of the device or an authorised MCPTT user. While the MCPTT emergency state is set on the client, all MCPTT group and private calls originated by the client will be MCPTT emergency calls, assuming the MCPTT user is authorised for MCPTT emergency calls on them.

– MCPTT private emergency alert (MPEA) state: this is an internal state of the MCPTT client which in conjunction with the MCPTT emergency private call state aids in managing the MCPTT emergency state and related actions.

– MCPTT emergency private call (MEPC) state: this is an internal state managed by the MCPTT client which in conjunction with the MCPTT emergency alert state aids in managing the MCPTT emergency state and related actions.

– In-progress emergency private call (IPEPC) state: indicates whether or not there is an MCPTT emergency private call in-progress for the two participants. This state is managed by the controlling MCPTT function. All private calls originated between these two participants when in an in-progress emergency private call state are MCPTT emergency private calls until this state is cancelled, whether or not the originator is in an MCPTT emergency state.

– MCPTT emergency private priority (MEPP) state: this is an internal state managed by the MCPTT client which tracks the in-progress emergency private call state of the private call managed by the controlling MCPTT function. Ideally, the MCPTT client would not need to track the in-progress emergency private priority state, but doing so enables the MCPTT client to request MCPTT emergency-level priority earlier than otherwise possible. For example, if the MCPTT user wishes to join an MCPTT emergency private call and is not in the MCPTT emergency state, the MCPTT client should have emergency level priority. If it has knowledge of the in-progress emergency private priority state of the private call (i.e., the two participants), it can request priority by including a Resource-Priority header field set to the MCPTT namespace specified in IETF RFC 8101 [48], and appropriate priority level in the SIP INVITE request (or SIP re-INVITE request).

NOTE: The above states and their transitions are described in Annex G.

4.6.3 MCPTT emergency alerts

MCPTT emergency alerts as defined by 3GPP TS 23.379 [3] are supported by the procedures in this specification. The following MCPTT emergency group call functionalities are specified in the present document:

– MCPTT emergency alert origination; and

– MCPTT emergency alert cancellation.

MCPTT emergency alerts are supported procedurally by two general mechanisms. One mechanism is embedded within the MCPTT emergency call (both emergency private call and emergency group call using both prearranged and chat session models) signalling procedures documented in clause 10 and clause 11 of this specification. The other mechanism utilizes SIP MESSAGE requests and is documented in clause 12.

MCPTT emergency alerts can be initiated or cancelled as options in the following signalling procedures documented in clause 10 and clause 11:

– MCPTT emergency group call initiation;

– MCPTT group call upgraded to MCPTT emergency call;

– MCPTT emergency group call cancellation (i.e., in-progress emergency state of the group set to false);

– MCPTT emergency private call initiation; and

– MCPTT private call upgrade to MCPTT emergency private call.

MCPTT emergency alerts can also be initiated or cancelled as described in the procedures of clause 12 which include:

– MCPTT emergency alert initiation; and

– MCPTT emergency alert cancellation (with optional cancelling of the in-progress emergency state of a group).

When MCPTT emergency alerts are initiated as an option in initiating or upgrading to an MCPTT emergency group call or are initiated using SIP MESSAGE requests, they are targeted to an MCPTT group, and, if not already affiliated, will result in the initiator being implicitly affiliated to the MCPTT group. When initiated as an option in initiating or upgrading to an MCPTT emergency private call, an MCPTT emergency alert is targeted to an individual MCPTT user, not to an MCPTT group.

Key aspects of MCPTT emergency alerts include:

– MCPTT emergency (MES) state: the MCPTT client’s MCPTT emergency state as described in clause G.1 is set upon initiation of an MCPTT emergency alert. While the MCPTT emergency state is set, assuming the MCPTT user has the needed authorisations, if the user initiates a private call and is authorised to do so, the MCPTT private call will be an MCPTT emergency private call. Similarly, assuming the needed authorisations, any subsequent MCPTT group call initiated by an MCPTT user with the MCPTT emergency state set will be an MCPTT emergency group call.

– MCPTT emergency alert (MEA) state: the MCPTT client maintains the internal MCPTT emergency alert state (MEA) which aids in the management of the MCPTT emergency state as described in clause G.5.

– MCPTT private emergency alert (MPEA) state: the MCPTT client maintains the MCPTT private emergency alert state of an MCPTT emergency alert targeted to an MCPTT user which aids in the management of the MCPTT emergency state.

– In-progress emergency group (IPEG) state : MCPTT emergency alert initiation or cancellation in and of itself does not impact the in-progress emergency state of the targeted group, which is maintained by the controlling MCPTT function, nor does it impact the priority of the EPS bearers. However, in setting the MCPTT emergency state, assuming an MCPTT user is authorised to make MCPTT emergency calls on the targeted group, any subsequent MCPTT group call the MCPTT user initiates on the group will cause the in-progress emergency state of the group to be set as described in clause G.2 and will result in upgraded priority of the EPS bearers used in the MCPTT emergency call.

– Authorisations for emergency alerts: MCPTT users need to be authorised to initiate MCPTT emergency alerts and additionally need to be authorised to cancel MCPTT emergency alerts. The parameters related to these authorisations are specified in 3GPP TS 24.483 [45] and 3GPP TS 24.484 [50].

4.6.4 MCPTT imminent peril group call

MCPTT imminent peril group calls as defined by 3GPP TS 23.379 [3] are supported by the procedures in this specification. The following MCPTT imminent peril group calls functionalities are specified in the present document:

– MCPTT imminent peril group calls origination;

– upgrade of an MCPTT group call to an MCPTT imminent peril group call;

– upgrade from an MCPTT imminent peril group call to an MCPTT emergency group call; and

– cancellation of the in-progress imminent peril state of the group.

Key aspects of MCPTT imminent peril include:

– adjusted EPS bearer priority for all participants when the in-progress imminent peril state of the group is set whether or not they themselves initiated an imminent peril group call. For unicast bearers this is achieved by using the Resource-Priority header field as specified in IETF RFC 4412 [29] with namespaces defined for use by MCPTT specified in IETF RFC 8101 [48], and for MBMS bearers this is achieved by having the participating MCPTT function adjust the ARP (priority, PVI, PCI) and executing the Modify MBMS Bearer Procedure per 3GPP TS 29.468 [42];

– restoration of normal EPS bearer priority to the call when the in-progress imminent peril group state is cancelled; and

– requires the MCPTT user to be authorised to either originate or cancel an MCPTT imminent peril group call.

Relationship to other MCPTT priority group call types:

– A normal MCPTT group call can be upgraded to an MCPTT imminent peril group call;

– An MCPTT imminent peril group call can be upgraded to an MCPTT emergency group call;

– When either an MCPTT imminent peril group call or an MCPTT emergency group call (i.e., their respective "in-progress" states) the group call returns to the priority designated for normal group calls, i.e., their is no direct transition from an MCPTT emergency group call to an MCPTT imminent peril group call;

– MCPTT imminent peril functionality is only applicable to MCPTT group calls, not MCPTT private calls; and

– MCPTT imminent peril group calls have no associated alert capabilities such as the MCPTT emergency alert capability which is associated with MCPTT emergency group calls.

There are a number of states that are key in managing these aspects of MCPTT imminent peril group calls, which include:

– MCPTT imminent peril group (MIG) state: this is an internal state of the MCPTT client which in conjunction with the MCPTT imminent peril group call state aids the client in managing the use of the Resource-Priority header field and related actions.

– MCPTT imminent peril group call (MIGC) state: this is an internal state managed by the MCPTT client which in conjunction with the MCPTT imminent peril group state aids the client in managing the use of the Resource-Priority header field and related actions.

– In-progress imminent peril group (IPIG) state: this a state of the MCPTT group which is managed by the controlling MCPTT function. While an MCPTT group is in an in-progress imminent peril group state, all participants in group calls using this group will receive elevated priority.

The above states and their transitions are described in Annex G.

4.7 Communication security

4.7.1 Media security

If a mission critical organisation requires MCPTT users to communicate using end-to-end security, a security context needs to be established between the initiator of the call and the recipient(s) of the call, prior to the establishment of media, or floor control signalling. This provides assurance to MCPTT users that no unauthorised access to communications is taking place within the MCPTT network. An MCPTT key management server (KMS) manages the security domain. For any end-point to use or access end-to-end secure communications, it needs to be provisioned with keying material associated to its identity by the KMS as specified in 3GPP TS 33.180 [78].

For group calls, the security context is set up at the time of creation of the group or temporary group. The group management server creates group call keying material associated with the group and distributes it to all members of the group or temporary group, in advance of the initiation of a group call as specified in 3GPP TS 24.481 [31] and 3GPP TS 33.180 [78]. The establishment of a security context for group calls has no impact on this specification.

For private calls, the security context is initiated at call setup. An end-to-end security context is established that is unique to the pair of users involved in the call. The procedure involves transferral of an encapsulated private call key (PCK) and private call key id (PCK-ID) from the initiator to the terminator. The PCK is encrypted using the terminator’s MCPTT ID and domain-specific material provided from the terminating user’s KMS. The domain-specific key material of the terminator’s KMS is identified by a KMS URI stored in the terminating user profile. The domain-specific key material for all KMSs is downloaded in advance from the initiator’s home KMS as described in 3GPP TS 33.180 [78]. The PCK and PCK-ID are distributed within a MIKEY payload within the SDP offer of the private call request. This payload is called a MIKEY-SAKKE I_MESSAGE, as defined in IETF RFC 6509 [75], which ensures the confidentiality, integrity and authenticity of the payload. The encoding of the MIKEY payload in the SDP offer is described in IETF RFC 4567 [47] using an "a=key-mgmt" attribute. The payload is signed using a key associated to the identity of the initiating user. At the terminating side, the signature is validated. If valid, the UE extracts and decrypts the encapsulated PCK. The MCPTT UE also extracts the PCK-ID. This process is described in 3GPP TS 33.180 [78]. With the PCK successfully shared between the two MCPTT UEs, the UEs are able to use SRTP/SRTCP to create an end-to-end secure session.

For first-to-answer calls, the security context is initiated at call setup. An end-to-end security context is established that is unique to the pair of users involved in the call. The procedure involves transferral of an encapsulated private call key (PCK) and private call key id (PCK-ID) from the terminator to the initiator. The PCK is encrypted using the originator’s MCPTT ID and domain-specific material provided from the originating user’s KMS. The domain-specific key material of the originator’s KMS is identified by a KMS URI stored in the originator’s user profile. The domain-specific key material for all KMSs is downloaded in advance from the terminator’s home KMS as described in 3GPP TS 33.180 [78]. The PCK and PCK-ID are distributed within a MIKEY payload within the SDP answer of the first-to-answer call response. This payload is called a MIKEY-SAKKE I_MESSAGE, as defined in IETF RFC 6509 [75], which ensures the confidentiality, integrity and authenticity of the payload. The encoding of the MIKEY payload included in the SDP answer using an "a=key-mgmt" attribute is described in IETF RFC 4567 [47]. The payload is signed using a key associated to the identity of the terminating user. At the originating side, the signature is validated. If valid, the UE extracts and decrypts the encapsulated PCK. The MCPTT UE also extracts the PCK-ID. This process is described in 3GPP TS 33.180 [78]. With the PCK successfully shared between the two MCPTT UEs, the UEs are able to use SRTP/SRTCP to create an end-to-end secure session.

End-to-end security is independent of the transmission path and hence is applicable to both on and off-network communications. With a security context established, the group call key and private call key can be used to encrypt media between the end-points as described in 3GPP TS 24.380 [5] clause 13.

4.7.2 Signalling security

Signalling security is established between the participating MCPTT function and the MCPTT client. This allows the following signalling to be integrity and confidentiality protected through the communication path between them:

– Signalling plane control (unicast only): Sensitive application data (as described in clause 4.8)

– User plane control over unicast: Floor control messages

– User plane control over multicast: Floor control messages and MBMS subchannel control messages

NOTE 1: According to 3GPP TS 24.380 [5], currently the multicast floor control messages are Floor Idle and Floor Taken and the multicast MBMS subchannel control messages are Map Group To Bearer and Unmap Group To Bearer.

For unicast signalling between the participating MCPTT function and the MCPTT client, the signalling can be protected using the Client-Server Key (CSK), identified by a Client-Server Key Identifier (CSK-ID). The CSK and CSK-ID are initially uploaded from the MCPTT client to the MCPTT server within a MIKEY MIME payload within a SIP REGISTER message for service authorisation or a SIP PUBLISH message for service authorisation, as specified in clause 9.2.1.3 of 3GPP TS 33.180 [78]. The CSK is confidentiality and integrity protected to the public service identity identifying the participating MCPTT function serving the MCPTT user and signed by the MCPTT ID of the MCPTT user.

The CSK and CSK-ID can also be updated by the participating MCPTT function. The procedure involves the participating MCPTT function generating a new CSK and CSK-ID and distributing the new key to the MCPTT client using a CSK ‘key download’ SIP MESSAGE, as specified in clause 9.2.1.4 of 3GPP TS 33.180 [78]. The message contains a MIKEY MIME payload containing the CSK and CSK-ID. The CSK is confidentiality and integrity protected to the public service identity identifying the participating MCPTT function serving the MCPTT user and signed by the MCPTT ID of the MCPTT user. The client only uses a single CSK at any one time and discards the previously established CSK on receiving a new CSK.

In case of multicast, the protection of MBMS subchannel control messages on the general purpose MBMS subchannels can be done with MSCCKs (each identified by a corresponding MSCCK-ID), distributed during MBMS bearer announcement. Each general purpose MBMS subchannel is associated with an MSCCK and a corresponding MSCCK‑ID. There can be multiple general purpose MBMS subchannels deployed, each associated with its own MSCCK and corresponding MSCCK-ID. The (MSCCK-ID, MSCCK) pair is provided for each general purpose MBMS subchannel separately.

The protection of floor control messages sent over MBMS subchannels can be done with Multicast Signalling Keys (MuSiK), (each identified by a corresponding (MuSiK-ID)), distributed via MuSiK download messages. The MSCCK and MuSiKs can be distributed independently of each other and in any order and can also be used independently. Signalling supports initial keying, as well as repeated re-keying and un-keying for both MSCCK and MuSiKs.

NOTE 2: When an MCPTT client interworks with a participating MCPTT function compliant only to Release 13 of the present document, the floor control messages can be protected using the MKFC and MKFC-ID as specified in 3GPP TS 24.380 [5].

The MuSiK download message contains an embedded MIME payload which is the MIKEY payload containing the MuSiK and MuSiK-ID, as well as an embedded XML payload potentially containing an explicit list of MCPTT group ids to which the key applies. Both payloads are protected as described in 3GPP TS 33.180 [78], as they are transferred between the participating MCPTT function and the MCPTT client. Within the XML payload, the list of MCPTT group ids is protected as application sensitive data (see clause 4.8). Within the MIKEY payload, the MuSiK is encrypted using the MCPTT ID of the served MCPTT client. The payload is signed using a key associated to the identity of the participating MCPTT function. To distribute MuSiK, the participating MCPTT function uses the I_MESSAGE format from clause 5.2.4 of 3GPP TS 33.180 [78], which includes associated parameters. The participating function sets the Status associated parameter to values defined in clause E.6.9 of 3GPP TS 33.180 [78], namely "Not-revoked" when keying or rekeying and "Revoked" when unkeying, respectively. Upon receipt, the MCPTT client validates the signature and, if valid, the MCPTT client first examines the Status attribute and either marks the associated security functions as "not in use" or stores the MuSiK and the MuSiK-ID, and then replies with a success code; otherwise, the MCPTT client can reply with a failure code. if a success code is not received from the MCPTT client in response to the MuSiK download message , the participating MCPTT function starts using only unicast floor control signalling to the respective MCPTT client for the listed groups.

For MBMS subchannel control messages sent over the general purpose MBMS subchannel of an MBMS bearer, the MSCCK can be used. The security context is initiated when the MBMS bearer is announced to the MCPTT clients. The procedure involves the participating MCPTT function creating an MBMS subchannel control key (MSCCK) and a corresponding key identifier (MSCCK-ID) associated with the MBMS bearer when the MBMS bearer is activated, and then transferring the MSCCK and the MSCCK-ID associated with the MBMS bearer to served MCPTT clients using SIP signalling. The MSCCK is encrypted using the MCPTT ID of the served MCPTT client and domain-specific material provided from the KMS. The MSCCK and the MSCCK-ID associated with the MBMS bearer are distributed within a MIKEY payload within the SDP describing the general purpose MBMS subchannel of the MBMS bearer. This payload is called a MIKEY-SAKKE I_MESSAGE, as defined in IETF RFC 6509 [75], which ensures the confidentiality, integrity and authenticity of the payload. The encoding of the MIKEY payload in the SDP is described in IETF RFC 4567 [47] using an "a=key-mgmt" attribute. The payload is signed using a key associated to the identity of the participating MCPTT function. To distribute MSCCK, the participating MCPTT function uses the I_MESSAGE format from clause 5.2.4 of 3GPP TS 33.180 [78], which includes associated parameters. The participating function sets the Status associated parameter to values defined in clause E.6.9 of 3GPP TS 33.180 [78], namely "Not-revoked" when keying or rekeying and "Revoked" when unkeying, respectively. Upon receipt, the MCPTT client validates the signature and, if the signature is found valid and the I_MESSAGE contains a Status attribute, the MCPTT client first examines the Status attribute and either marks the associated security functions as "not in use" or extracts and stores the encapsulated MSCCK and the corresponding MSCCK-ID. The decrypted key is used as described in 3GPP TS 33.180 [78]. With the MSCCK successfully shared between the participating MCPTT function and the served UEs, the participating MCPTT function is able to securely send MBMS subchannel control messages to the MCPTT clients.

4.8 Protection of sensitive application data

In certain deployments, for example, in the case that the MCPTT operator uses the underlying SIP core infrastructure from the carrier operator, the MCPTT operator can prevent certain sensitive application data from being visible in the clear to the SIP layer. The following data are classed as sensitive application data:

– MCPTT ID;

– MCPTT group ID;

– user location information;

– emergency, alert and imminent-peril indicators;

– access token (containing the MCPTT ID);

– MCPTT client ID; and

– functional alias.

The above data is transported as XML content in SIP messages. in XML elements or XML attributes.

Data is transported in attributes in the following circumstances in the procedures in the present document:

– an MCPTT ID, an MCPTT Group ID, and an MCPTT client ID in an XML document published in SIP PUBLISH request for affiliation according to IETF RFC 3856 [51];

– an MCPTT ID or an MCPTT Group ID in XML document notified in a SIP NOTIFY request for affiliation according to IETF RFC 3856 [51];

– an MCPTT ID and functional alias in an XML document published in SIP PUBLISH request for functional alias management according to IETF RFC 3856 [51];

– an MCPTT ID and functional alias in an XML document notified in a SIP NOTIFY request for functional alias management according to IETF RFC 3856 [51];

– an MCPTT ID in application/resource-lists+xml document included in an SIP INVITE request setting up a private call according to IETF RFC 5366 [20];

– an MCPTT ID in application/resource-lists+xml document included in an SIP INVITE request setting up a group call to a temporary group involving a non-controlling function that works in "Trusted Mode" according to IETF RFC 5366 [20], whereby the participants are returned to the controlling function in a MIME body of a SIP 403 (Forbidden) with the P-Refused-URI-List header field according to IETF RFC 5318 [36];

– an MCPTT ID in XML document provided in SIP NOTIFY request of a conference event package according to IETF RFC 4575 [30]; and

– an MCPTT ID or MCPTT Group ID in a "uri" attribute of an <entry> element of a <list> element of the <resource-lists> element of the application/resource-lists+xml document according to IETF RFC 5366 [20], included in a SIP REFER request when using a pre-established session (the application/resource-lists+xml MIME body is pointed to by a Cid-URL as specified in IETF RFC 2392 [62] contained in the Refer-To header field of the SIP REFER request);

– an MCPTT ID in XML document provided in SIP INFO request according to IETF RFC 6086 [64], after receiving the SIP ACK for a SIP 200 (OK) with the Warning header field set with the Warning text "111 group call proceeded without all required group members".

3GPP TS 33.180 [78] describes a method to provide confidentiality protection of sensitive application data in elements by using XML encryption (i.e. xmlenc) and in attributes by using an attribute confidentiality protection scheme described in clause 6.6.2.3 of the present document. Integrity protection can also be provided by using XML signatures (i.e. xmlsig).

Protection of the data relies on a shared XML protection key (XPK) used to encrypt and sign data:

– between the MCPTT client and the MCPTT server, the XPK is a client-server key (CSK); and

– between MCPTT servers and between MCPTT domains, the XPK is a signalling protection key (SPK).

The CSK (XPK) and a key-id CSK-ID (XPK-ID) are generated from keying material provided by the key management server. Identity based public key encryption based on MIKEY-SAKKE is used to transport the CSK between SIP end-points. The encrypted CSK is transported from the MCPTT client to the MCPTT server when the MCPTT client performs service authorisation as described in clause 7 and is also used during service authorisation to protect the access token.

The SPK (XPK) and a key-id SPK-ID (XPK-ID) are directly provisioned in the MCPTT servers.

Configuration in the MCPTT client and MCPTT server is used to determine whether one or both of confidentiality protection and integrity protection are required.

The following four examples give a brief overview of the how confidentiality and integrity protection is applied to application data in this specification.

EXAMPLE 1: Pseudo code showing how confidentiality protection is represented in the procedures in the document for sensitive data sent by the originating client.

IF configuration is set for confidentiality protection of sensitive data

THEN

Encrypt data element using the CSK (XPK) by following TS 33.180;

Include in an <EncryptedData> element of the XML MIME body according to TS 33.180:

(1) the encryption method;

(2) the key-id (XPK-ID);

(3) the cipher data;

Encrypt URIs in attribute using the CSK (XPK) by following clause 6.6.2.3;

ELSE

include application data into XML MIME body in clear text;

ENDIF;

EXAMPLE 2: Pseudo code showing how integrity protection is represented in the procedures in the present document for data sent by the originating client.

IF configuration is set for integrity protection of application data

THEN

Use a method to hash the content as specified in TS 33.180;

Generate a signature for the hashed content using the CSK (XPK) as specified in TS 33.180;

Include within a <Signature> XML element of the XML MIME body according to TS 33.180:

(1) a cannonicalisation method to be applied to the signed information;

(2) the signature method used for generating the signature;

(3) a reference to the content to be signed;

(4) the hashing method used;

(5) the hashed content;

(6) the key-id (XPK-ID);

(7) the signature value;

ENDIF;

EXAMPLE 3: Pseudo code showing how confidentiality protection is represented in the procedures in the present document at the server side when receiving encrypted content.

IF configuration is set for confidentiality protection of sensitive data

THEN

Check that the XML content contains the <EncryptedData> element;

Check that the XML document contains a URI with the domain name for MCPTT confidentiality protection;

Return an error if the <EncryptedData> element or domain name for MCPTT confidentiality protection are not found;

Otherwise:

(1) obtain the CSK (XPK) using the CSK-ID (XPK-ID) in the received XML body;

(2) for encrypted data in elements, decrypt the data elements using the CSK as specified in TS 33.180 as required;

(3) for encrypted URIs in attributes, decrypt the URIs using the CSK as specified in clause 6.6.2.3;

ENDIF;

EXAMPLE 4: Pseudo code showing how integrity protection is represented in the procedures in the present document at the server side when receiving signed content.

IF configuration is set for integrity protection of application data

THEN

Check that the XML content contains the <Signature> element;

Return an error if the <Signature> element is not found;

Otherwise:

(1) obtain the CSK (XPK) using the CSK-ID (XPK-ID) in the received XML body;

(2) verify the signature of the content using the CSK;

Return an error if the validation of the signature fails;

IF validation of the signature passes

THEN

decrypt any data found in <EncryptedData> elements;

decrypt any encrypted URIs found in attributes;

ENDIF;

ENDIF;

The content can be re-encrypted and signed again using the SPK between MCPTT servers.

The following examples show the difference between normal and encrypted data content. In this example consider the MCPTT client initiating a prearranged group session.

EXAMPLE 5: application/vnd.3gpp.mcpttinfo+xml MIME body represented with data elements in the clear:

Content-Type: application/vnd.3gpp.mcptt-info+xml

<?xml version="1.0"?>

<mcpttinfo>

<mcptt-Params>

<session-type>prearranged</session-type>

<mcptt-request-uri type="Normal">

<mcpttURI>sip:group123@mcpttoperator1.com></mcpttURI>

</mcptt-request-uri>

</mcptt-Params>

</mcptt-info>

EXAMPLE 6: application/vnd.3gpp.mcpttinfo+xml MIME body represented with the <mcptt-request-uri> encrypted:

Content-Type: application/vnd.3gpp.mcptt-info+xml

<?xml version="1.0"?>

<mcpttinfo>

<mcptt-Params>

<session-type>prearranged</session-type>

<mcptt-request-uri type="Encrypted">

<EncryptedData xmlns=’http://www.w3.org/2001/04/xmlenc#’

Type=’http://www.w3.org/2001/04/xmlenc#Content’>

<EncryptionMethod Algorithm="http://www.w3.org/2009/xmlenc11#aes128-gcm"/>

<ds:KeyInfo>

<ds:KeyName>base64XpkId</KeyName>

</ds:KeyInfo>

<CipherData>

<CipherValue>A23B45C5657689090</CipherValue>

</CipherData>

</EncryptedData>

</mcptt-request-uri>

</mcptt-Params>

</mcptt-info>

EXAMPLE 7: application/pidf+xml MIME body represented with clear URIs in attributes:

Content-Type: application/pidf+xml

<?xml version="1.0" encoding="UTF-8"?>

<presence entity="sip:somebody@mcptt.org">

<tuple id="acD4rhU87bK">

<status>

<affiliation group="sip:thegroup@mcptt.org"/>

</status>

</tuple>

</presence>

EXAMPLE 8: application/pidf+xml MIME body represented with encrypted URIs in attributes:

Content-Type: application/pidf+xml

<?xml version="1.0" encoding="UTF-8"?>

<presence entity="sip:c4Hrt45XG8IohRFT67vfdr3V;iv=45RtfVgHY23k8Ihy;xpk-id=b7UJv9;alg=128-aes-gcm@mc1-encryption.3gppnetwork.org">

<tuple id="acD4rhU87bK">

<status>

<affiliation group="sip:98yudFG45tx_89TYGedb4ujF ;iv=FGD567kjhfH7d4-D;key-id=eV9kl7;alg=128-aes-gcm@mc1-encryption.3gppnetwork.org"/>

</status>

</tuple>

</presence>

4.9 Pre-established session

When establishing a pre-established session, the MCPTT client negotiates the media parameters, including establishing IP addresses and ports using interactive connectivity establishment (ICE) as specified in IETF RFC 8445 [891] and IETF RFC 8839 [90] with the participating MCPTT function, prior to using the pre-established session for establishing MCPTT calls with other MCPTT users. The procedures for establishing, modifying and releasing a pre-established session are defined in clause 8.

The pre-established session can later be used in MCPTT calls. This avoids the need to negotiate media parameters (including evaluating ICE candidates) and reserving bearer resources during the MCPTT call establishment that results in delayed MCPTT call establishment.

The use of pre-established session on the origination side is compatible with the use of on demand session on the termination side. The use of pre-established session on the termination side is compatible with the use of on demand session on the origination side.

The MCPTT client procedures for:

– leaving an MCPTT call using a pre-established session that was initiated by the MCPTT client are defined in clause 6.2.4.2;

– releasing a MCPTT call using a pre-established session that was initiated by the MCPTT client are defined in clause 6.2.5.2;

– establishing a pre-arranged group call using a pre-established session are defined in clause 10.1.1.2.2;

– rejoining a pre-arranged group call using a pre-established session are defined in clause 10.1.1.2.4.2;

– joining a chat MCPTT group call using a pre-established session are defined in clause 10.1.2.2.2;

– establishing a private call using a pre-established session are defined in clause 11.1.1.2.2; and

– releasing a private call using a pre-established session are defined in clause 11.1.3.1.2.

The participating MCPTT function procedures for:

– establishing a MCPTT session using automatic commencement mode are defined in clause 6.3.2.2.5.3;

– establishing a MCPTT session using manual commencement mode are defined in clause 6.3.2.2.6.3;

– releasing a MCPTT call using a pre-established session are defined in clause 6.3.2.2.8.2;

– establishing a pre-arranged group call using a pre-established session are defined in clause 10.1.1.3.1.2;

– releasing a pre-arranged group call using a pre-established session are defined in clause 10.1.1.3.3.2;

– rejoining a pre-arranged group call using a pre-established session are defined in clause 10.1.1.3.5.2;

– establishing a MCPTT group call using a pre-established session are defined in clause 10.1.2.3.2;

– originating a private call from a MCPTT client using a pre-established session are defined in clause 11.1.1.3.1.2;

– establishing a private call to a MCPTT client using a pre-established session are defined in clause 11.1.1.3.2;

– releasing a private call initiated by the served MCPTT client using a pre-established session are defined in clause 11.1.3.2.1.2; and

– releasing a private call initiated by the remote MCPTT client using a pre-established session are defined in clause 11.1.3.2.2.2.

4.10 MCPTT client ID

The MCPTT client assigns the MCPTT client ID when the MCPTT client is used for the first time. The MCPTT client generates the MCPTT client ID as specified in clause 4.2 of IETF RFC 4122 [67].

The MCPTT client preserves the MCPTT client ID:

– while the MCPTT client is SIP registered as specified in 3GPP TS 24.229 [4];

– while the MCPTT client is not SIP registered as specified in 3GPP TS 24.229 [4] and the UE serving the MCPTT client is switched on;

– while the UE serving the MCPTT client is switched off; and

– while the UE serving the MCPTT client is power-cycled.

NOTE: MCPTT client ID is not preserved when the UE is reset to factory settings.

4.11 Off-network MCPTT

Off-network services are available for the user if the value of "/<x>/<x>/OffNetwork/Authorised" leaf node present in user profile as specified in 3GPP TS 24.483 [45] is set to "true".

4.12 Broadcast Group Calls

A broadcast group call is a group call where the initiating MCPTT user expects no response from the other MCPTT users, so that when the user’s transmission is complete, so is the call. The functionality in the present release of the specification for broadcast group calls is not compliant to the requirements for user-broadcast group and group-broadcast group calls as specified in 3GPP TS 22.179 [2], 3GPP TS 22.280 [76] and 3GPP TS 23.379 [3]. In the present release of the specification, a broadcast group call can be initiated by an MCPTT user on any MCPTT group that the MCPTT user is part of.

NOTE 1: Configuration related to the authorisation to create a user-broadcast group or a group-broadcast exists in the user profile document as specified in 3GPP TS 24.484 [50], but is not used by any procedures in 3GPP TS 24.481 [31] in the current release, as the ability for an authorised user to create user-broadcast groups and group-broadcast groups is not provided in the current release.

NOTE 2: Configuration related to broadcast group hierarchies can be found in the group document as specified in 3GPP TS 24.481 [31] and in the service configuration document as specified in 3GPP TS 24.484 [50]. However, this configuration is not used by any procedures in 3GPP TS 24.380 [5] in the current release.