12 Emergency alert

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

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

12.0 General

This clause describes the emergency alert procedures for on-network and off-network.

For on-network emergency alert, the procedures for originating and terminating MCPTT clients, participating MCPTT functions and controlling MCPTT function are specified in clause 12.1. MCPTT emergency call procedures that have emergency alerts as an optional capability shall be performed as defined in clause 10.1 for on-network group call and defined in clause 11.1 for on-network private call.

For off-network emergency alert, the procedures for each functional entity is specified in clause 12.2.

12.1 On-network emergency alert

12.1.1 Client procedures

12.1.1.1 Emergency alert origination

Upon receiving a request from the MCPTT user to send an MCPTT emergency alert to the indicated MCPTT group shall determine whether the group document contains a <list-service> element that contains a <preconfigured-group-use-only> element. If a <preconfigured-group-use-only> element exists and is set to the value "true", then the MCPTT client:

1) should indicate to the MCPTT user that alerts are not allowed on the indicated group; and

2) shall skip the remainder of this procedure.

If this is an authorised request for an MCPTT emergency alert as determined by clause 6.2.8.1.6, the MCPTT client shall generate a SIP MESSAGE request in accordance with 3GPP TS 24.229 [4] and IETF RFC 3428 [33] with the clarifications given below.

NOTE 1: This SIP MESSAGE request is assumed to be sent out-of-dialog.

The MCPTT client:

1) shall include the ICSI value "urn:urn-7:3gpp-service.ims.icsi.mcptt" (coded as specified in 3GPP TS 24.229 [4]), in a P-Preferred-Service header field according to IETF RFC 6050 [9] in the SIP MESSAGE request;

2) shall include an Accept-Contact header field with the g.3gpp.icsi-ref media feature tag containing the value of "urn:urn-7:3gpp-service.ims.icsi.mcptt" along with the "require" and "explicit" header field parameters according to IETF RFC 3841 [6];

3) may include a P-Preferred-Identity header field in the SIP MESSAGE request containing a public user identity as specified in 3GPP TS 24.229 [4];

4) shall include an application/vnd.3gpp.mcptt-info+xml MIME body as specified in clause F.1 with the <mcpttinfo> element containing the <mcptt-Params> element with:

a) the <mcptt-request-uri> element set to:

i) if the <EmergencyAlert> element of the MCPTT user profile exists, then:

A) if the <entry-info> attribute of the <entry> element of the <EmergencyAlert> element is set to the value ‘DedicatedGroup’, the value in the <uri-entry> element of the <entry> element of the <EmergencyAlert> element; and

B) if the <entry-info> attribute of the <entry> element of the <EmergencyAlert> element is set to the value ‘UseCurrentlySelectedGroup’ and there is no currently selected group, the value in the <uri-entry> element of the <entry> element of the <EmergencyAlert> element; and

ii) if the <EmergencyAlert> element of the MCPTT user profile does not exist, the group identity selected by the MCPTT user;

b) the <alert-ind> element set to a value of "true";

c) the <mcptt-client-id> element set to the MCPTT client ID of the originating MCPTT client;

d) if the MCPTT client needs to include an active functional alias in the SIP MESSAGE request, the <anyExt> element with the <functional-alias-URI> element set to the URI of the used functional alias; and

NOTE 2: The MCPTT client learns the functional aliases that are activated for an MCPTT ID from procedures specified in clause 9A.2.1.3.

e) if the MCPTT user has requested an application priority, the <anyExt> element with the <user-requested-priority> element set to the user provided value;

5) shall include in the SIP MESSAGE request the specific location information for MCPTT emergency alert as specified in clause 6.2.9.1;

6) shall set the MCPTT emergency state if not already set;

7) shall set the MCPTT emergency alert state to "MEA 2: emergency-alert-confirm-pending";

8) shall set the Request-URI to the public service identity identifying the participating MCPTT function serving the MCPTT user; and

9) shall send the SIP MESSAGE request according to rules and procedures of 3GPP TS 24.229 [4].

On receiving a SIP 2xx response to the SIP MESSAGE request, the MCPTT client shall set the MCPTT emergency alert state to "MEA 3: emergency-alert-initiated".

On receiving a SIP 4xx response a SIP 5xx response or a SIP 6xx response to the SIP MESSAGE request, the MCPTT client shall set the MCPTT emergency alert state to "MEA 1: no-alert".

NOTE 3: The MCPTT emergency state is left set in this case as the MCPTT user presumably is in the best position to determine whether or not they are in a life-threatening condition. The assumption is that the MCPTT user can clear the MCPTT emergency state manually if need be.

NOTE 4: Based on implementation the MCPTT client can subsequently automatically originate an MCPTT emergency group call as specified in clause 10.1.1.2.

12.1.1.2 Emergency alert cancellation

Upon receiving a request from the MCPTT user to send an MCPTT emergency alert cancellation to the indicated MCPTT group and this is an authorised request for an MCPTT emergency alert cancellation as determined by clause 6.2.8.1.6, the MCPTT client shall generate a SIP MESSAGE request in accordance with 3GPP TS 24.229 [4] and IETF RFC 3428 [33] with the clarifications given below.

NOTE 1: This SIP MESSAGE request is assumed to be sent out-of-dialog.

The MCPTT client:

3) may include a P-Preferred-Identity header field in the SIP MESSAGE request containing the public user identity of the originator as specified in 3GPP TS 24.229 [4];

4) shall include an application/vnd.3gpp.mcptt-info+xml MIME body as specified in clause F.1 with the <mcpttinfo> element containing the <mcptt-Params> element with:

a) the <mcptt-request-uri> element set to the MCPTT group identity;

b) the <alert-ind> element set to a value of "false";

c) the <mcptt-client-id> element set to the MCPTT client ID of the originating MCPTT client;

NOTE 1A: The MCPTT client learns the functional aliases that are activated for an MCPTT ID from procedures specified in clause 9A.2.1.3.

e) if the MCPTT user is cancelling an MCPTT emergency alert originated by another MCPTT user, include the <originated-by> element set to the MCPTT ID of the MCPTT user who originated the MCPTT emergency alert;

5) if the MCPTT user has additionally requested the cancellation of the in-progress emergency state of the MCPTT group and this is an authorised request for an in-progress emergency group state cancellation as determined by clause 6.2.8.1.7, shall include an <emergency-ind> element set to a value of "false" in the <mcpttinfo> element containing the <mcptt-Params> element;

6) shall set the Request-URI to the public service identity identifying the participating MCPTT function serving the MCPTT user;

7) if the generated SIP MESSAGE request does not contain an <originated-by> element in the application/vnd.3gpp.mcptt-info+xml MIME body, shall set the MCPTT emergency alert state to "MEA 4: Emergency-alert-cancel-pending"; and

8) shall send the SIP MESSAGE request according to rules and procedures of 3GPP TS 24.229 [4].

On receipt of a SIP MESSAGE request containing an application/vnd.3gpp.mcptt-info+xml MIME body with an <alert-ind-rcvd> element set to true and an <mcptt-client-id> matching the MCPTT client ID included in the sent SIP MESSAGE request:

1) if the <alert-ind> element is set to a value of "false" in the application/vnd.3gpp.mcptt-info+xml MIME body of the received SIP MESSAGE request and if the MCPTT emergency alert state is set to "MEA 4: Emergency-alert-cancel-pending" and the sent SIP MESSAGE request did not contain an <originated-by> element in the application/vnd.3gpp.mcptt-info+xml MIME body, shall:

a) set the MCPTT emergency alert state to "MEA 1: no-alert"; and

b) clear the MCPTT emergency state if not already cleared;

2) if the <alert-ind> element in the application/vnd.3gpp.mcptt-info+xml MIME body of the received SIP MESSAGE request is set to a value of "true" and if the MCPTT emergency alert state is set to "MEA 4: Emergency-alert-cancel-pending" and the sent SIP MESSAGE request did not contain an <originated-by> element in the application/vnd.3gpp.mcptt-info+xml MIME body, shall set the MCPTT emergency alert state to "MEA 3: emergency-alert-initiated"; and

NOTE 2: It would appear to be an unusual situation for the initiator of an MCPTT emergency alert to not be able to clear their own alert. Nevertheless, an MCPTT user can be configured to be authorised to initiate MCPTT emergency alerts but not have the authority to clear them. Hence, the case is covered here.

3) if an <emergency-ind> element is present in the application/vnd.3gpp.mcptt-info+xml MIME body of received SIP MESSAGE request is set to a value of "false" and the sent SIP MESSAGE request contains an <emergency-ind> element set to a value of "false":

a) shall set the MCPTT emergency group call state of the group to "MEGC 1: emergency-gc-capable"; and

b) shall set the MCPTT emergency group state of the group to "MEG 1: no-emergency".

NOTE 3: The case where an <emergency-ind> element is set to true is possible but not handled specifically above as it results in no state changes.

On receiving a SIP 4xx response, SIP 5xx response or SIP 6xx response to the sent SIP MESSAGE request:

1) if the received SIP 4xx response, SIP 5xx response or SIP 6xx response contains an application/vnd.3gpp.mcptt-info+xml MIME body as specified in clause F.1 with the <mcpttinfo> element containing the <mcptt-Params> element with the <alert-ind> element set to a value of "true", the sent SIP MESSAGE request did not contain an <originated-by> element in the application/vnd.3gpp.mcptt-info+xml MIME body and the MCPTT emergency alert state is set to "MEA 4: Emergency-alert-cancel-pending", shall set the MCPTT emergency alert state to "MEA 3: emergency-alert-initiated"; and

NOTE 4: In this case, an <emergency-ind> element would either not be present or would be set to true. In either case, no change in state would result. Hence, this case is not specified above.

2) if the received SIP 4xx response, SIP 5xx response or a SIP 6xx response to the SIP MESSAGE request does not contain an application/vnd.3gpp.mcptt-info+xml MIME body with an <alert-ind> element, the sent SIP MESSAGE request does not contain an <originated-by> element in the application/vnd.3gpp.mcptt-info+xml MIME body and the MCPTT emergency alert state is set to "MEA 4: Emergency-alert-cancel-pending", shall set the MCPTT emergency alert state to "MEA 3: emergency-alert-initiated".

12.1.1.3 MCPTT client receives an MCPTT emergency alert or call notification

Upon receipt of a "SIP MESSAGE request for emergency notification", the MCPTT client:

1) if the received SIP MESSAGE request contains an application/vnd.3gpp.mcptt-info+xml MIME body with the <alert-ind> element set to a value of "true", may display to the MCPTT user the functional alias of the originating MCPTT user, if provided, and should display to the MCPTT user an indication of the MCPTT emergency alert and associated information, including:

a) the MCPTT group identity contained in <mcptt-calling-group-id> element application/vnd.3gpp.mcptt-info+xml MIME body;

b) the originator of the MCPTT emergency alert contained in the <mcptt-calling-user-id> element of the application/vnd.3gpp.mcptt-info+xml MIME body; and

c) the mission critical organization of the MCPTT emergency alert originator contained in the <mc-org> element of the application/vnd.3gpp.mcptt-info+xml MIME body;

NOTE 1: This is the case of the MCPTT client receiving the notification of another MCPTT user’s emergency alert.

2) if the received SIP MESSAGE request contains an application/vnd.3gpp.mcptt-info+xml MIME body with the <alert-ind> element set to a value of "false":

a) should display to the MCPTT user an indication of the MCPTT emergency alert cancellation and associated information, including:

i) the MCPTT group identity contained in the <mcptt-calling-group-id> element application/vnd.3gpp.mcptt-info+xml MIME body;

ii) the originator of the MCPTT emergency alert contained in:

A) if present, the <originated-by> element of the application/vnd.3gpp.mcptt-info+xml MIME body; or

B) the <mcptt-calling-user-id> element of the application/vnd.3gpp.mcptt-info+xml MIME body; and

b) if the MCPTT ID contained in the <originated-by> element is the MCPTT ID of the receiving MCPTT user, shall set the MCPTT emergency alert state to "MEA 1: no-alert"; and

c) if the received SIP MESSAGE request contains an application/vnd.3gpp.mcptt-info+xml MIME body with the <emergency-ind> element is set to a value of "false":

i) shall set the MCPTT emergency group state to "MEG 1: no-emergency"; and

ii) shall set the MCPTT emergency group call state to "MEGC 1: emergency-gc-capable";

NOTE 2: This is the case of the MCPTT client receiving the notification of the cancellation by a third party of an MCPTT emergency alert. This can be the MCPTT emergency alert of another MCPTT user or the MCPTT emergency alert of the recipient, as determined by the contents of the <originated-by> element. Optionally, notification of the cancellation of the in-progress emergency state of the MCPTT group can be included.

3) if the received SIP MESSAGE request contains an application/vnd.3gpp.mcptt-info+xml MIME body with the <emergency-ind> element set to a value of "true":

a) should display to the MCPTT user an indication of the additional emergency MCPTT user participating in the MCPTT emergency group call including the following if not already displayed as part of step 1):

i) the MCPTT group identity contained in the <mcptt-calling-group-id> element application/vnd.3gpp.mcptt-info+xml MIME body; and

ii) the <mcptt-calling-user-id> element of the application/vnd.3gpp.mcptt-info+xml MIME body;

b) shall set the MCPTT emergency group state to "MEG 2: in-progress" if not already set to that value;

NOTE 3: This is the case of the MCPTT client receiving notification of an additional MCPTT user in an MCPTT emergency state (i.e., not the MCPTT user that originally triggered the in-progress emergency state of the group) joining the in-progress emergency group call or in the case of MCPTT client not participating in an in-progress emergency group call but affiliated to group to receive notification of an MCPTT users having MCPTT outstanding emergency call. An emergency alert indication, if included, is handled in step 1).

4) if the received SIP MESSAGE request contains an application/vnd.3gpp.mcptt-info+xml MIME body with the <emergency-ind> element set to a value of "false":

a) should display to the MCPTT user an indication of the cancellation of the in-progress emergency state of the MCPTT group call including the following if not already displayed as part of step 2):

i) the MCPTT group identity contained in the <mcptt-calling-group-id> element application/vnd.3gpp.mcptt-info+xml MIME body; and

ii) the <mcptt-calling-user-id> element of the application/vnd.3gpp.mcptt-info+xml MIME body;

b) shall set the MCPTT emergency group state to "MEG 1: no-emergency"; and

c) shall set the MCPTT emergency group call state to "MEGC 1: emergency-gc-capable";

NOTE 4: This is the case of the MCPTT client receiving the notification of the cancellation of the in-progress emergency state of the MCPTT group. In this case, the receiving MCPTT client is affiliated with the MCPTT group but not participating or participating in the session. An emergency alert cancellation, if included, is handled in step 2).

5) if the received SIP MESSAGE request contains an application/vnd.3gpp.mcptt-info+xml MIME body with the <imminentperil-ind> element set to a value of "true":

a) should display to the MCPTT user an indication of the MCPTT user participating in the MCPTT imminent peril group call including the following if not already displayed as part of step 1):

i) the MCPTT group identity contained in the <mcptt-calling-group-id> element application/vnd.3gpp.mcptt-info+xml MIME body; and

ii) the <mcptt-calling-user-id> element of the application/vnd.3gpp.mcptt-info+xml MIME body; and

b) shall set the MCPTT imminent peril group state to "MIG 2: in-progress" if not already set to that value;

NOTE 5: This is the case of the MCPTT client receiving notification of an additional MCPTT user initiating an imminent peril group call when there is already an in-progress imminent peril state in effect on the group.

6) if the received SIP MESSAGE request contains an application/vnd.3gpp.mcptt-info+xml MIME body with the <imminentperil-ind> element set to a value of "false":

a) should display to the MCPTT user an indication of the cancellation of the in-progress imminent peril state of the MCPTT group including the following if not already displayed as part of step 2):

i) the MCPTT group identity contained in the <mcptt-calling-group-id> element application/vnd.3gpp.mcptt-info+xml MIME body; and

ii) the <mcptt-calling-user-id> element of the application/vnd.3gpp.mcptt-info+xml MIME body;

b) shall set the MCPTT imminent peril group state to "MIG 1: no-imminent-peril"; and

c) shall set the MCPTT imminent peril group call state to "MIGC 1: imminent-peril-gc-capable";

NOTE 6: This is the case of the MCPTT client receiving notification of the cancellation of the in-progress imminent peril state of the group.

7) shall generate a SIP 200 (OK) response according to rules and procedures of 3GPP TS 24.229 [4]; and

8) shall send the SIP 200 (OK) response towards the MCPTT server according to rules and procedures of 3GPP TS 24.229 [4].

12.1.1.4 MCPTT client receives notification of entry into or exit from a group geographic area

Upon receipt of a "SIP MESSAGE request for notification of entry into or exit from a group geographic area", the MCPTT client;

1) shall send a SIP 200 (OK) to the participating MCPTT function that sent the SIP MESSAGE request; and

2) if the <group-geo-area-ind> element of the application/vnd.3gpp.mcptt-info+xml MIME body is:

a) set to "true":

i) may display to the MCPTT user an indication that a group geographic area has been entered; and

ii) shall execute the procedure in clause 9.2.1.2 to affiliate to the group indicated by the participating MCPTT function; or

b) set to "false":

i) may display to the MCPTT user an indication that a group geographic area has been exited; and

ii) shall execute the procedure in clause 9.2.1.2 to de-affiliate from the group indicated by the participating MCPTT function.

12.1.1.5 MCPTT group in-progress emergency group state cancel

Upon receiving a request from an MCPTT user to cancel the in-progress emergency condition on a prearranged MCPTT group on which there is no call ongoing, the MCPTT client shall generate a SIP MESSAGE request in accordance with 3GPP TS 24.229 [4] and IETF RFC 3428 [33] with the clarifications given below.

NOTE 1: This SIP MESSAGE request is assumed to be sent out-of-dialog.

The MCPTT client:

1) if the MCPTT user is not authorised to cancel the in-progress emergency group state of the MCPTT group as determined by the procedures of clause 6.2.8.1.7, the MCPTT client:

a) should indicate to the MCPTT user that they are not authorised to cancel the in-progress emergency group state of the MCPTT group; and

b) shall skip the remaining steps of the current clause;

2) shall include the ICSI value "urn:urn-7:3gpp-service.ims.icsi.mcptt" (coded as specified in 3GPP TS 24.229 [4]), in a P-Preferred-Service header field according to IETF RFC 6050 [9] in the SIP MESSAGE request;

3) shall include an Accept-Contact header field with the g.3gpp.icsi-ref media feature tag containing the value of "urn:urn-7:3gpp-service.ims.icsi.mcptt" along with the "require" and "explicit" header field parameters according to IETF RFC 3841 [6];

4) may include a P-Preferred-Identity header field in the SIP MESSAGE request containing the public user identity of the originator as specified in 3GPP TS 24.229 [4];

5) shall include an application/vnd.3gpp.mcptt-info+xml MIME body as specified in clause F.1 with the <mcpttinfo> element containing the <mcptt-Params> element with:

a) the <mcptt-request-uri> element set to the MCPTT group identity; and

b) the <emergency-ind> element set to a value of "false";

6) if the MCPTT user has additionally requested the cancellation of an MCPTT emergency alert originated by MCPTT user, shall include an <alert-ind> element set to a value of "false" in the <mcpttinfo> element containing the <mcptt-Params> element;

7) shall set the Request-URI to the public service identity identifying the participating MCPTT function serving the MCPTT user;

8) if the generated SIP MESSAGE request contain an <alert -ind> element in the application/vnd.3gpp.mcptt-info+xml MIME body, shall set the MCPTT emergency alert state to "MEA 4: Emergency-alert-cancel-pending"; and

9) shall send the SIP MESSAGE request according to rules and procedures of 3GPP TS 24.229 [4].

On receipt of a SIP MESSAGE request containing an application/vnd.3gpp.mcptt-info+xml MIME body with an <emergency-ind-rcvd> element set to a value of "true" and an <mcptt-client-id> matching the MCPTT client ID included in the sent SIP MESSAGE request:

1) if an <emergency-ind> element is present in the application/vnd.3gpp.mcptt-info+xml MIME body of received SIP MESSAGE request and is set to a value of "false":

a) shall set the MCPTT emergency group state of the group to "MEG 1: no-emergency".

NOTE 3: The case where an <emergency-ind> element is set to true is possible but not handled specifically above as it results in no state changes.

2) if the <alert-ind> element in the application/vnd.3gpp.mcptt-info+xml MIME body of the received SIP MESSAGE request is set to a value of "true" and if the MCPTT emergency alert state is set to "MEA 4: Emergency-alert-cancel-pending" and the sent SIP MESSAGE request contain an <alert-ind> element set to value "false" in the application/vnd.3gpp.mcptt-info+xml MIME body, shall set the MCPTT emergency alert state to "MEA 3: emergency-alert-initiated"; and

3) if the <alert-ind> element in the application/vnd.3gpp.mcptt-info+xml MIME body of the received SIP MESSAGE request is set to a value of "false" and if the MCPTT emergency alert state is set to "MEA 4: Emergency-alert-cancel-pending" and the sent SIP MESSAGE request contain an <alert-ind> element set to value "false" in the application/vnd.3gpp.mcptt-info+xml MIME body, shall:

a) set the MCPTT emergency alert state to "MEA 1: no-alert"; and

b) clear the MCPTT emergency state if not already cleared;

On receiving a SIP 4xx response, SIP 5xx response or SIP 6xx response to the sent SIP MESSAGE request:

1) if the received SIP 4xx response, SIP 5xx response or SIP 6xx response contains an application/vnd.3gpp.mcptt-info+xml MIME body as specified in clause F.1 with the <mcpttinfo> element containing the <mcptt-Params> element with the <alert-ind> element set to a value of "true" and the sent SIP MESSAGE request contain an <alert-ind> element set to value "false" in the application/vnd.3gpp.mcptt-info+xml MIME body and the MCPTT emergency alert state is set to "MEA 4: Emergency-alert-cancel-pending", shall set the MCPTT emergency alert state to "MEA 3: emergency-alert-initiated"; and

NOTE 4: In this case, <emergency-ind> element is set to true is possible but not handled specifically above as it results in no state changes.

12.1.1.6 MCPTT client receives notification of entry into or exit from an emergency alert area

Upon receipt of a "SIP MESSAGE request for notification of entry into or exit from an emergency alert area", the MCPTT client:

1) if the received SIP MESSAGE request contains an application/vnd.3gpp.mcptt-info+xml MIME body with the <emergency-alert-area-ind> element value:

a) set to "true":

i) may display to the MCPTT user an indication that MCPTT client has entered a pre-defined emergency alert area; and

ii) if the MCPTT user is not in emergency state, shall initiate the emergency alert origination procedure as specified in clause 12.1.1.1; or

b) set to "false":

i) may display to the MCPTT user an indication that MCPTT client has exited a pre-defined emergency alert area;

NOTE: In this case, the MCPTT emergency state remains set, as the MCPTT user is in the best position to determine whether or not they are in a life-threatening condition. The MCPTT user can clear the MCPTT emergency state manually, if needed.

2) shall generate a SIP 200 (OK) response according to rules and procedures of 3GPP TS 24.229 [4]; and

3) shall send the SIP 200 (OK) response towards the MCPTT server according to rules and procedures of 3GPP TS 24.229 [4].

12.1.2 Participating MCPTT function procedures

12.1.2.1 Receipt of a SIP MESSAGE request for emergency notification from the served MCPTT client

Upon receipt of a "SIP MESSAGE request for emergency notification for originating participating MCPTT function", the participating MCPTT function:

1) if unable to process the request due to a lack of resources or a risk of congestion exists, may reject the SIP MESSAGE request with a SIP 500 (Server Internal Error) response. The participating MCPTT function may include a Retry-After header field to the SIP 500 (Server Internal Error) response as specified in IETF RFC 3261 [24] and skip the rest of the steps;

NOTE 1: if the SIP MESSAGE request contains an emergency indication set to a value of "true" or an alert indication set to a value of "true", the participating MCPTT function can, according to local policy, choose to accept the request.

2) shall determine the MCPTT ID of the calling user from the public user identity in the P-Asserted-Identity header field of the SIP MESSAGE request;

NOTE 2: The MCPTT ID of the calling user is bound to the public user identity at the time of service authorisation, as documented in clause 7.3.

2a) if the participating MCPTT function cannot find a binding between the public user identity and an MCPTT ID or if the validity period of an existing binding has expired, then the participating MCPTT function shall reject the SIP MESSAGE request with a SIP 404 (Not Found) response with the warning text set to "141 user unknown to the participating function" in a Warning header field as specified in clause 4.4, and shall not continue with any of the remaining steps;

3) if the MCPTT user is not affiliated with the MCPTT group as determined by clause 9.2.2.2.11, shall perform the actions specified in clause 9.2.2.2.12 for implicit affiliation;

4) if the actions for implicit affiliation specified in step 3) above were performed but not successful in affiliating the MCPTT user due to the MCPTT user already having N2 simultaneous affiliations(specified in the <MaxAffiliationsN2> element of the <Common> element of the corresponding MCPTT user profile of the served MCPTT ID), shall reject the "SIP MESSAGE request for emergency notification for originating participating MCPTT function" with a SIP 486 (Busy Here) response with the warning text set to "102 too many simultaneous affiliations" in a Warning header field as specified in clause 4.4. and skip the rest of the steps.

NOTE 3: N2 is the total number of MCPTT groups that an MCPTT user can be affiliated to simultaneously as specified in 3GPP TS 23.379 [3].

NOTE 4: As this is a request for MCPTT emergency services, the participating MCPTT function can choose to accept the request.

5) shall determine the public service identity of the controlling MCPTT function associated with the group identity in the received SIP MESSAGE request;

NOTE 5: The public service identity can identify the controlling MCPTT function in the primary MCPTT system or in a partner MCPTT system.

NOTE 6: If the controlling MCPTT function is in a partner MCPTT system in a different trust domain, then the public service identity can identify the MCPTT gateway server that acts as an entry point in the partner MCPTT system from the primary MCPTT system.

NOTE 7: If the controlling MCPTT function is in a partner MCPTT system in a different trust domain, then the primary MCPTT system can route the SIP request through an MCPTT gateway server that acts as an exit point from the primary MCPTT system to the partner MCPTT system

NOTE 8: How the participating MCPTT function determines the public service identity of the controlling MCPTT function associated with the group identity or of the MCPTT gateway server in the partner MCPTT system is out of the scope of the present document.

NOTE 9: How the primary MCPTT system routes the SIP request through an exit MCPTT gateway server is out of the scope of the present document.

6) shall generate a SIP MESSAGE request in accordance with 3GPP TS 24.229 [4] and IETF RFC 3428 [33];

7) shall set the Request-URI of the outgoing SIP MESSAGE request to the public service identity of the controlling MCPTT function determined in step 5) above;

8) shall copy the contents of the application/vnd.3gpp. mcptt-info+xml MIME body in the received SIP MESSAGE request into an application/vnd.3gpp.mcptt-info+xml MIME body as specified in clause F.1 included in the outgoing SIP MESSAGE request;

8a) if the received SIP MESSAGE request contains a <functional-alias-URI> element of the application/vnd.3gpp.mcptt-info+xml MIME body, shall check the status of the functional alias for the MCPTT ID. If the functional alias status is activated, then the participating MCPTT function shall set the <functional-alias-URI> element of the application/vnd.3gpp.mcptt-info+xml MIME body in the outgoing SIP MESSAGE request to the received value, otherwise it shall not include a <functional-alias-URI> element;

9) shall set the <mcptt-calling-user-id> contained in <mcptt-Params> element of the application/vnd.3gpp.mcptt-info+xml MIME body to the MCPTT ID determined in step 2) above;

10) if the received SIP MESSAGE request contains an application/vnd.3gpp.mcptt-location-info+xml MIME body as specified in clause F.3 shall copy the contents of the application/vnd.3gpp.mcptt-location-info+xml MIME body in the received SIP MESSAGE request into an application/vnd.3gpp.mcptt-location-info+xml MIME body included in the outgoing SIP MESSAGE request;

11) shall set the P-Asserted-Identity in the outgoing SIP MESSAGE request to the public user identity in the P-Asserted-Identity header field contained in the received SIP MESSAGE request; and

12) shall send the SIP MESSAGE request as specified to 3GPP TS 24.229 [4].

Upon receipt of a SIP 2xx response in response to the SIP MESSAGE request sent in step 10):

1) shall generate a SIP 200 (OK) response as specified in 3GPP TS 24.229 [4] with the follow clarifications:

a) shall include the public user identity received in the P-Asserted-Identity header field of the incoming SIP 200 (OK) response into the P-Asserted-Identity header field of the outgoing SIP 200 (OK) response;

2) if the procedures of clause 9.2.2.2.12 for implicit affiliation were performed in the present clause, shall complete the implicit affiliation by performing the procedures of clause 9.2.2.2.13; and

3) shall send the SIP 200 (OK) response to the MCPTT client according to 3GPP TS 24.229 [4].

Upon receipt of a SIP 4xx, 5xx or 6xx response to the sent SIP MESSAGE request and if the implicit affiliation procedures of clause 9.2.2.2.12 were invoked in the present clause, the participating MCPTT function shall perform the procedures of clause 9.2.2.2.14.

12.1.2.2 Receipt of a SIP MESSAGE request for emergency notification for terminating MCPTT client

In the procedures in this clause:

1) emergency indication in an incoming SIP MESSAGE request refers to the <emergency-ind> element of the application/vnd.3gpp.mcptt-info+xml MIME body; and

2) alert indication in an incoming SIP MESSAGE request refers to the <alert-ind> element of the application/vnd.3gpp.mcptt-info+xml MIME body.

Upon receipt of a "SIP MESSAGE request for emergency notification for terminating participating MCPTT function", the participating MCPTT function:

NOTE 1: if the SIP MESSAGE request contains an emergency indication set to a value of "true" or an alert indication set to a value of "true", the participating MCPTT function can by means beyond the scope of this specification choose to accept the request.

2) shall use the MCPTT ID present in the <mcptt-request-uri> element of the application/vnd.3gpp.mcptt-info+xml MIME body of the incoming SIP MESSAGE request to retrieve the binding between the MCPTT ID and public user identity;

3) if the binding between the MCPTT ID and public user identity does not exist, then the participating MCPTT function shall reject the SIP MESSAGE request with a SIP 404 (Not Found) response. Otherwise, continue with the rest of the steps;

4) shall generate an outgoing SIP MESSAGE request as specified in clause 6.3.2.2.11; and

5) shall send the SIP MESSAGE request as specified in 3GPP TS 24.229 [4].

Upon receipt of SIP 2xx responses to the outgoing SIP MESSAGE requests, the participating MCPTT function shall follow the procedures specified in 3GPP TS 24.229 [4].

12.1.2.3 Receipt of a SIP MESSAGE request indicating successful delivery of emergency notification

Upon receipt of a SIP MESSAGE request routed to the terminating participating MCPTT function with the Request-URI set to the public service identity of the terminating participating MCPTT function and the SIP MESSAGE request contains an application/vnd.3gpp.mcptt-info+xml MIME body with an <alert-ind-rcvd> or <emergency-ind-rcvd> element present, the participating MCPTT function:

4) shall generate an outgoing SIP MESSAGE request in accordance with 3GPP TS 24.229 [4] and IETF RFC 3428 [33] and:

a) shall include in the SIP MESSAGE request all Accept-Contact header fields and all Reject-Contact header fields, with their feature tags and their corresponding values along with parameters according to rules and procedures of IETF RFC 3841 [6] that were received (if any) in the incoming SIP MESSAGE request;

b) shall set the Request-URI of the outgoing SIP MESSAGE request to the public user identity associated to the MCPTT ID of the MCPTT user that was in the Request-URI of the incoming SIP MESSAGE request;

c) shall copy the contents of the application/vnd.3gpp.mcptt-info+xml MIME body received in the incoming SIP MESSAGE request into an application/vnd.3gpp.mcptt-info+xml MIME body included in the outgoing SIP MESSAGE request; and

d) shall copy the contents of the P-Asserted-Identity header field of the incoming SIP MESSAGE request to the P-Asserted-Identity header field of the outgoing SIP MESSAGE request; and

5) shall send the SIP MESSAGE request as specified in 3GPP TS 24.229 [4].

Upon receipt of SIP 2xx responses to the outgoing SIP MESSAGE requests, the participating MCPTT function shall follow the procedures specified in 3GPP TS 24.229 [4].

12.1.3 Controlling MCPTT function procedures

12.1.3.1 Handling of a SIP MESSAGE request for emergency notification

Upon receipt of a "SIP MESSAGE request for emergency notification for controlling MCPTT function", the controlling MCPTT function:

1) if unable to process the request due to a lack of resources or a risk of congestion exists, may reject the SIP MESSAGE request with a SIP 500 (Server Internal Error) response. The controlling MCPTT function may include a Retry-After header field to the SIP 500 (Server Internal Error) response as specified in IETF RFC 3261 [24]. Otherwise, continue with the rest of the steps;

NOTE: If the SIP MESSAGE request contains an alert indication set to a value of "true", the controlling MCPTT function can, according to local policy, choose to accept the request.

2) shall reject the SIP request with a SIP 403 (Forbidden) response and not process the remaining steps if an Accept-Contact header field does not include the g.3gpp.icsi-ref media feature tag containing the value of "urn:urn-7:3gpp-service.ims.icsi.mcptt";

2A) if the group document contains a <list-service> element that contains a <preconfigured-group-use-only> element that is set to the value "true", shall shall reject the SIP request with a SIP 403 (Forbidden) response with the warning text set to "168 alert is not allowed on the preconfigured group" as specified in clause 4.4 "Warning header field" and skip the rest of the steps;

3) if the received SIP MESSAGE request contains an application/vnd.3gpp.mcptt-info+xml MIME body with the <alert-ind> element set to a value of "false", the <emergency-ind> element present or not and call is ongoing on associated group on which outstanding alert exists, shall perform the procedures specified in clause 12.1.3.2 and skip the rest of the steps;

3a) if the received SIP MESSAGE request contains an application/vnd.3gpp.mcptt-info+xml MIME body with the <emergency-ind> element set to a value of "false", the <alert-ind> element present or not and no call is ongoing on the group on which in-progress emergency state cancelation request is recieved, shall perform the procedures specified in clause 12.1.3.3 and skip the rest of the steps;

4) if the received SIP MESSAGE request contains an application/vnd.3gpp.mcptt-info+xml MIME body with the <alert-ind> element set to a value of "true":

a) if the received SIP MESSAGE request is an unauthorised request for an MCPTT emergency alert as specified in clause 6.3.3.1.13.1 shall reject the SIP MESSAGE request with a SIP 403 (Forbidden) response to the SIP MESSAGE request as specified in 3GPP TS 24.229 [4] with the following clarifications:

i) shall include in the SIP 403 (Forbidden) response an application/vnd.3gpp.mcptt-info+xml MIME body as specified in clause F.1 with the <mcpttinfo> element containing the <mcptt-Params> element with the <alert-ind> element set to a value of "false"; and

ii) shall send the SIP 403 (Forbidden) response as specified in 3GPP TS 24.229 [4] and skip the rest of the steps; and

b) if the received SIP MESSAGE request is an authorised request for an MCPTT emergency alert as specified in clause 6.3.3.1.13.1:

i) if the sending MCPTT user identified by the <mcptt-calling-user-id> element included in the application/vnd.3gpp.mcptt-info+xml MIME body is not affiliated with the MCPTT group identified by the <mcptt-request-uri> element of the MIME body as determined by the procedures of clause 6.3.6:

I) shall check if the MCPTT user is eligible to be implicitly affiliated with the MCPTT group as determined by clause 9.2.2.3.6;

II) if the MCPTT user is determined not to be eligible to be implicitly affiliated to the MCPTT group shall reject the SIP MESSAGE request with a SIP 403 (Forbidden) response with the warning text set to "120 user is not affiliated to this group" in a Warning header field as specified in clause 4.4 and skip the rest of the steps below; or

III) if the procedures of clause 9.2.2.3.6 determined the MCPTT user to be eligible to be implicitly affiliated to the MCPTT group shall, perform the implicit affiliation as specified in clause 9.2.2.3.7;

ii) for each of the other affiliated members of the group:

A) generate an outgoing SIP MESSAGE request notification of the MCPTT user’s emergency alert indication as specified in clause 6.3.3.1.11 with the clarifications of clause 6.3.3.1.12;

B) shall include in the application/vnd.3gpp.mcptt-info+xml MIME body with the <mcpttinfo> element containing the <mcptt-Params> element with the <mcptt-calling-user-id> element set to the value of the <mcptt-calling-user-id> element in the received SIP MESSAGE request; and

C) send the SIP MESSAGE request according to according to rules and procedures of 3GPP TS 24.229 [4];

iii) shall generate a SIP 200 (OK) response to the received SIP MESSAGE request as specified in 3GPP TS 24.229 [4] with the following clarifications:

A) shall cache the information that the MCPTT user has initiated an MCPTT emergency alert;

iv) shall send the SIP 200 (OK) response to the received SIP MESSAGE according to rules and procedures of 3GPP TS 24.229 [4].

v) shall generate a SIP MESSAGE request as described in clause 6.3.3.1.20 to indicate successful receipt of an emergency alert, and shall include in the application/vnd.3gpp.mcptt-info+xml MIME body:

A) the <alert-ind> element set to a value of "true";

B) the <alert-ind-rcvd> element set to a value of true; and

C) the <mcptt-client-id> element with the MCPTT client ID that was included in the incoming SIP MESSAGE request; and

vi) shall send the SIP MESSAGE request according to according to rules and procedures of 3GPP TS 24.229 [4].

Upon receipt of SIP 2xx responses to the outgoing SIP MESSAGE requests, the controlling MCPTT function shall follow the procedures specified in 3GPP TS 24.229 [4].

12.1.3.2 Handling of a SIP MESSAGE request for emergency alert cancellation

Upon receipt of a "SIP MESSAGE request for emergency notification for controlling MCPTT function" containing an application/vnd.3gpp.mcptt-info+xml MIME body with the <alert-ind> element set to a value of "false", the controlling MCPTT function:

1) if the received SIP MESSAGE request is an unauthorised request for an MCPTT emergency alert cancellation as specified in clause 6.3.3.1.13.1:

a) and if the received SIP MESSAGE request does not contain an <emergency-ind> element set to a value of "false" or is an unauthorised request for an MCPTT emergency call cancellation as specified in clause 6.3.3.1.13.4, shall reject the SIP MESSAGE request with a SIP 403 (Forbidden) response to the SIP MESSAGE request as specified in 3GPP TS 24.229 [4] with the following clarifications:

ii) if the received SIP MESSAGE request contains an <emergency-ind> element of the <mcpttinfo> element set to a value of "false" and if the in-progress emergency state of the group is set to a value of "true" and this is an unauthorised request for an MCPTT emergency call cancellation as determined in step i) above, shall include an <emergency-ind> element set to a value of "true" in the application/vnd.3gpp.mcptt-info+xml MIME body in the SIP 403 (Forbidden) response; and

iii) shall send the SIP 403 (Forbidden) response according to rules and procedures of 3GPP TS 24.229 [4] and skip the rest of the steps; and

b) and if the received SIP MESSAGE request contains an <emergency-ind> element set to a value of "false" and is an authorised request for an MCPTT emergency call cancellation as specified in clause 6.3.3.1.13.4 and the in-progress emergency state of the MCPTT group is set to a value of "true":

i) shall set the in-progress emergency state of the group to a value of "false";

ii) shall clear the cache of the MCPTT ID of the MCPTT user that triggered the setting of the in-progress emergency state of the MCPTT group to "true";

iii) shall generate SIP re-INVITE requests to the other affiliated and joined members of the MCPTT group as specified in clause 6.3.3.1.6. The MCPTT controlling function:

A) for each affiliated and joined member shall send the SIP re-INVITE request towards the MCPTT client as specified in 3GPP TS 24.229 [4]; and

B) Upon receiving a SIP 200 (OK) response to the SIP re-INVITE request the controlling MCPTT function shall interact with the media plane as specified in 3GPP TS 24.380 [5];

iv) for each of the affiliated but not joined members of the group shall:

A) generate a SIP MESSAGE request notification of the cancellation of the MCPTT user’s emergency call as specified in clause 6.3.3.1.11;

C) shall include an <emergency-ind> element set to a value of "false" in the application/vnd.3gpp.mcptt-info+xml MIME body in the outgoing SIP MESSAGE request;

v) shall generate a SIP 200 (OK) response to the received SIP MESSAGE request as specified in 3GPP TS 24.229 [4];

vi) shall send the SIP 200 (OK) response to the received SIP MESSAGE as specified in 3GPP TS 24.229 [4] and skip the rest of the steps;

vii) shall generate a SIP MESSAGE request as described in clause 6.3.3.1.20 to indicate successful receipt of the request for emergency alert cancellation

viii) shall include in the application/vnd.3gpp.mcptt-info+xml MIME body of the SIP MESSAGE request:

A) the <alert-ind> element set to a value of "true";

B) the <alert-ind-rcvd> element set to a value of true;

C) the <emergency-ind> element set to a value of "false"; and

D) the <mcptt-client-id> element with the MCPTT client ID that was included in the incoming SIP MESSAGE request; and

ix) shall send the SIP MESSAGE request according to according to rules and procedures of 3GPP TS 24.229 [4]; and

2) if the received SIP MESSAGE request is an authorised request for an MCPTT emergency alert cancellation as specified in clause 6.3.3.1.13.3:

a) if the received SIP MESSAGE request contains an <originated-by> element in the application/vnd.3gpp.mcptt-info+xml MIME body, shall clear the cache of the MCPTT ID of the MCPTT user identified by the <originated-by> element as having an outstanding MCPTT emergency alert;

b) if the received SIP MESSAGE request does not contain an <originated-by> element in the application/vnd.3gpp.mcptt-info+xml MIME body, clear the cache of the MCPTT ID of the sender of the SIP MESSAGE request as having an outstanding MCPTT emergency alert;

c) if the received SIP MESSAGE request does not contain an <emergency-ind> element set to a value of "false" or is an unauthorised request for an MCPTT emergency call cancellation as specified in clause 6.3.3.1.13.4, for each of the affiliated members of the group shall:

i) generate a SIP MESSAGE request notification of the cancellation of the MCPTT user’s emergency alert as specified in clause 6.3.3.1.11;

ii) shall include in the application/vnd.3gpp.mcptt-info+xml MIME body with the <mcpttinfo> element containing the <mcptt-Params> element with the <mcptt-calling-user-id> element set to the value of the <mcptt-calling-user-id> element in the received SIP MESSAGE request;

iii) if the received SIP MESSAGE request contains an <originated-by> element in the application/vnd.3gpp.mcptt-info+xml MIME body, copy the contents of the received <originated-by> element to an <originated-by> element in the application/vnd.3gpp.mcptt-info+xml MIME body in the outgoing SIP MESSAGE request;

iv) shall include an <alert-ind> element set to a value of "false" in the application/vnd.3gpp.mcptt-info+xml MIME body in the outgoing SIP MESSAGE request; and

v) send the SIP MESSAGE request as specified in 3GPP TS 24.229 [4];

d) if the received SIP MESSAGE request contains an <emergency-ind> element set to a value of "false" and is an authorised request for an MCPTT emergency call cancellation as specified in clause 6.3.3.1.13.4 and the in-progress emergency state of the MCPTT group is set to a value of "true":

i) shall set the in-progress emergency state of the group to a value of "false";

ii) cache the information that the MCPTT user has cancelled the outstanding in-progress emergency state of the group;

iii) shall generate SIP re-INVITES requests to the other affiliated and joined members of the MCPTT group as specified in clause 6.3.3.1.6. The MCPTT controlling function:

A) for each affiliated and joined member shall send the SIP re-INVITE request towards the MCPTT client as specified in 3GPP TS 24.229 [4]; and

B) Upon receiving a SIP 200 (OK) response to the SIP re-INVITE request the controlling MCPTT function shall interact with the media plane as specified in 3GPP TS 24.380 [5]; and

iv) for each of the affiliated but not joined members of the group shall:

A) generate a SIP MESSAGE request notification of the cancellation of the MCPTT user’s emergency call as specified in clause 6.3.3.1.11;

B) include in the application/vnd.3gpp.mcptt-info+xml MIME body with the <mcpttinfo> element containing the <mcptt-Params> element with the <mcptt-calling-user-id> element set to the value of the <mcptt-calling-user-id> element in the received SIP MESSAGE request;

C) if the received SIP MESSAGE request contains an <originated-by> element in the application/vnd.3gpp.mcptt-info+xml MIME body, copy the contents of the received <originated-by> element to an <originated-by> element in the application/vnd.3gpp.mcptt-info+xml MIME body in the outgoing SIP MESSAGE request;

D) include in the application/vnd.3gpp.mcptt-info+xml MIME body an <alert-ind> element set to a value of "false"; and

E) shall include an <emergency-ind> element set to a value of "false" in the application/vnd.3gpp.mcptt-info+xml MIME body in the outgoing SIP MESSAGE request;

e) shall generate a SIP 200 (OK) response to the received SIP MESSAGE request as specified in 3GPP TS 24.229 [4];

f) shall send the SIP 200 (OK) response to the received SIP MESSAGE as specified in 3GPP TS 24.229 [4].

g) shall generate a SIP MESSAGE request as described in clause 6.3.3.1.20 to indicate successful receipt of the request for emergency alert cancellation;

h) shall include in the application/vnd.3gpp.mcptt-info+xml MIME body, the <alert-ind> element set to a value of "false" and the <alert-ind-rcvd> set to "true";

i) shall populate the <mcptt-client-id> element with the MCPTT client ID that was included in the incoming SIP MESSAGE request;

j) if the received SIP MESSAGE request contains an <emergency-ind> element of the <mcpttinfo> element set to a value of "false":

i) if this is an authorised request for an MCPTT emergency call cancellation as specified in clause 6.3.3.1.13.4, shall include an <emergency-ind> element set to a value of "false" in the application/vnd.3gpp.mcptt-info+xml MIME body in the outgoing SIP MESSAGE request; and

ii) otherwise, if this is an unauthorised request for an MCPTT emergency call cancellation as specified in clause 6.3.3.1.13.4, and the in-progress emergency state of the group is set to a value of "true", shall include an <emergency-ind> element set to a value of "true" in the application/vnd.3gpp.mcptt-info+xml MIME body in the outgoing SIP MESSAGE request; and

k) shall send the SIP MESSAGE request according to according to the rules and procedures of 3GPP TS 24.229 [4].

Upon receipt of SIP 2xx responses to the outgoing SIP MESSAGE requests, the controlling MCPTT function shall follow the procedures specified in 3GPP TS 24.229 [4].

12.1.3.3 Handling of a SIP MESSAGE request for in-progress emergency group state cancellation

Upon receipt of a "SIP MESSAGE request for emergency notification for controlling MCPTT function" containing an application/vnd.3gpp.mcptt-info+xml MIME body with the <emergency-ind> element set to a value of "false" and no call is ongoing on the group on which in-progress emergency cancellation request is made, the controlling MCPTT function:

1) if the received SIP MESSAGE request is an unauthorised request for an MCPTT in-progress emergency group state cancellation as specified in clause 6.3.3.1.13.4:

a) and if the received SIP MESSAGE request does not contain an <alert-ind> element or is an unauthorised request for an MCPTT emergency alert cancellation as specified in clause 6.3.3.1.13.3, shall reject the SIP MESSAGE request with a SIP 403 (Forbidden) response to the SIP MESSAGE request as specified in 3GPP TS 24.229 [4] with the following clarifications:

ii) if the received SIP MESSAGE request contains an <alert-ind> element of the <mcpttinfo> element set to a value of "false" and this is an unauthorised request for an MCPTT emergency alert cancellation as determined in step a) above and the emergency state of the MCPTT user has outstanding emergency state, shall include an <alert-ind> element set to a value of "true" in the application/vnd.3gpp.mcptt-info+xml MIME body in the SIP 403 (Forbidden) response; and

iii) shall send the SIP 403 (Forbidden) response according to rules and procedures of 3GPP TS 24.229 [4] and skip the rest of the steps; and

b) and if the received SIP MESSAGE request contains an <alert-ind> element set to a value of "false" and is an authorised request for an MCPTT emergency alert cancellation as specified in clause 6.3.3.1.13.3 and the MCPTT user has outstanding emergency state:

i) shall clear the cache of the MCPTT ID of the MCPTT user that has the outstanding emergency alert state;

ii) for each of the affiliated members of the group shall:

A) generate a SIP MESSAGE request notification of the cancellation of the MCPTT user’s emergency alert as specified in clause 6.3.3.1.11;

C) shall include an <alert-ind> element set to a value of "false" in the application/vnd.3gpp.mcptt-info+xml MIME body in the outgoing SIP MESSAGE request;

D) send the SIP MESSAGE request according to according to rules and procedures of 3GPP TS 24.229 [4];

iii) shall generate a SIP 200 (OK) response to the received SIP MESSAGE request as specified in 3GPP TS 24.229 [4];

iv) shall send the SIP 200 (OK) response to the received SIP MESSAGE as specified in 3GPP TS 24.229 [4] and skip the rest of the steps;

v) shall generate a SIP MESSAGE request as described in clause 6.3.3.1.20 to indicate successful receipt of the request for emergency alert cancellation

vi) shall include in the application/vnd.3gpp.mcptt-info+xml MIME body of the SIP MESSAGE request:

A) the <emergency-ind> element set to a value of "true";

B) the <emergency-ind-rcvd> element set to a value of "true";

C) the <alert-ind> element set to a value of "false"; and

D) the <mcptt-client-id> element with the MCPTT client ID that was included in the incoming SIP MESSAGE request; and

vii) shall send the SIP MESSAGE request according to according to rules and procedures of 3GPP TS 24.229 [4]; and

2) if the received SIP MESSAGE request is an authorised request for an MCPTT in-progress emergency group state cancellation as specified in clause 6.3.3.1.13.4:

a) shall set the in-progress emergency state of the group to a value of "false";

b) cache the information that the MCPTT user has cancelled the outstanding in-progress emergency state of the group and clear the cache of the all MCPTT ID of the MCPTT users that triggered the setting of the in-progress emergency state of the MCPTT group to "true";

c) if the received SIP MESSAGE request contains an <alert-ind> element set to a value of "false" and is an authorised request for an MCPTT emergency alert cancellation as specified in clause 6.3.3.1.13.3 and the MCPTT user has outstanding emergency state, clear the cache of the MCPTT ID of the sender of the SIP MESSAGE request as having an outstanding MCPTT emergency alert;

d) for each of the affiliated members of the group shall:

i) generate a SIP MESSAGE request notification of the cancellation of the MCPTT user’s/group emergency state as specified in clause 6.3.3.1.11;

ii) shall include an <emergency-ind> element set to a value of "false" in the application/vnd.3gpp.mcptt-info+xml MIME body in the outgoing SIP MESSAGE request;

iii) shall include in the application/vnd.3gpp.mcptt-info+xml MIME body with the <mcpttinfo> element containing the <mcptt-Params> element with the <mcptt-calling-user-id> element set to the value of the <mcptt-calling-user-id> element in the received SIP MESSAGE request;

iv) if the received SIP MESSAGE request contains an <alert-ind> element of the <mcpttinfo> element set to a value of "false" and this is an authorised request for an MCPTT emergency alert cancellation as determined in step c) above, shall include an <alert-ind> element set to a value of "false" in the application/vnd.3gpp.mcptt-info+xml MIME body in the outgoing SIP MESSAGE request; and

v) send the SIP MESSAGE request according to according to rules and procedures of 3GPP TS 24.229 [4];

e) shall generate a SIP 200 (OK) response to the received SIP MESSAGE request as specified in 3GPP TS 24.229 [4];

f) shall send the SIP 200 (OK) response to the received SIP MESSAGE as specified in 3GPP TS 24.229 [4].

g) shall generate a SIP MESSAGE request as described in clause 6.3.3.1.20 to indicate successful receipt of the request for in-progress emergency group cancellation;

h) shall include in the application/vnd.3gpp.mcptt-info+xml MIME body, the <emergency-ind> element set to a value of "false" and the <emergency-ind-rcvd> set to "true";

i) shall populate the <mcptt-client-id> element with the MCPTT client ID that was included in the incoming SIP MESSAGE request;

j) if the received SIP MESSAGE request contains an <alert-ind> element of the <mcpttinfo> element set to a value of "false":

i) if this is an authorised request for an MCPTT emergency alert cancellation as specified in clause 6.3.3.1.13.3, shall include an <alert-ind> element set to a value of "false" in the application/vnd.3gpp.mcptt-info+xml MIME body in the outgoing SIP MESSAGE request; and

B) otherwise, if this is an unauthorised request for an MCPTT emergency alert cancellation as specified in clause 6.3.3.1.13.3, shall include an <alert-ind> element set to a value of "true" in the application/vnd.3gpp.mcptt-info+xml MIME body in the outgoing SIP MESSAGE request; and

k) shall send the SIP MESSAGE request according to according to the rules and procedures of 3GPP TS 24.229 [4].

Upon receipt of SIP 2xx responses to the outgoing SIP MESSAGE requests, the controlling MCPTT function shall follow the procedures specified in 3GPP TS 24.229 [4].

12.2 Off-network emergency alert

12.2.1 General

12.2.2 Basic state machine

12.2.2.1 General

12.2.2.2 Emergency alert state machine

The figure 12.2.2.2-1 gives an overview of the main states and transitions on the UE for emergency alert.

Each emergency alert state machine is per MCPTT group.

Figure 12.2.2.2-1: Emergency alert state machine

The following pieces of information are associated with the emergency alert state machine:

a) the stored emergency state of the MCPTT group; and

b) the stored organization name of the MCPPT client.

NOTE: The emergency alert state machine is referred by the MCPTT off-network group call and MCPTT off-network private call procedures.

12.2.2.3 Emergency alert states

12.2.2.3.1 E1: Not in emergency state

This state is the start state of this state machine.

The UE stays in this state while not in emergency state.

12.2.2.3.2 E2: Emergency state

This state exists for UE, when the UE has sent a GROUP EMERGENCY ALERT message.

12.2.3 Procedures

12.2.3.1 Originating user sending emergency alert

When in state "E1: Not in emergency state", upon receiving an indication from the MCPTT user to transmit an emergency alert for an MCPTT group ID, and the values of "/<x>/<x>/Common/MCPTTGroupCall/EmergencyAlert/Authorised" leaf node present in the user profile and "/<x>/<x>/Common/AllowedEmergencyAlert" present in group configuration as specified in 3GPP TS 24.483 [45] are set to "true", the MCPTT client:

1) shall set the stored emergency state as "true";

2) shall set the stored MCPTT group ID to the indicated MCPTT group ID;

3) shall generate a GROUP EMERGENCY ALERT message as specified in clause 15.1.16. In the GROUP EMERGENCY ALERT message, the MCPTT client:

a) shall set the MCPTT group ID IE to the stored MCPTT group ID;

b) shall set the Originating MCPTT user ID IE to own MCPTT user ID;

c) shall set the Organization name IE to own organization name; and

d) may set the User location IE with client’s current location, if requested;

4) shall send the GROUP EMERGENCY ALERT message as specified in clause 10.2.1.1.1;

5) shall start timer TFE2 (emergency alert retransmission); and

6) shall enter "E2: Emergency state" state.

12.2.3.2 Emergency alert retransmission

When in state "E2: Emergency state", upon expiry of timer TFE2 (emergency alert retransmission), the MCPTT client:

1) shall generate a GROUP EMERGENCY ALERT message as specified in clause 15.1.16. In the GROUP EMERGENCY ALERT message, the MCPTT client:

a) shall set the MCPTT group ID IE to the stored MCPTT group ID;

b) shall set the originating MCPTT user ID IE to own MCPTT user ID;

c) shall set the Organization name IE to own organization name; and

d) may set the Location IE with client’s current location, if requested; and

2) shall send the GROUP EMERGENCY ALERT message as specified in clause 10.2.1.1.1;

3) shall start the timer TFE2 (emergency alert retransmission); and

4) shall remain in the current state.

12.2.3.3 Terminating user receiving emergency alert

When in state "E1: Not in emergency state" or in "E2: Emergency state", upon receiving a GROUP EMERGENCY ALERT message with the Originating MCPTT user ID IE not stored in the list of users in emergency, the MCPTT client:

1) shall store the Originating MCPTT user ID IE and location IE in the list of users in emergency;

2) shall generate a GROUP EMERGENCY ALERT ACK message as specified in clause 15.1.17. In the GROUP EMERGENCY ALERT ACK message, the MCPTT client:

a) shall set the MCPTT group ID IE to the MCPTT group ID IE of the received GROUP EMERGENCY ALERT message;

b) shall set the Sending MCPTT user ID IE to own MCPTT user ID; and

c) shall set the Originating MCPTT user ID IE to the Originating MCPTT user ID IE of the received GROUP EMERGENCY ALERT message; and

3) shall send the GROUP EMERGENCY ALERT ACK message as specified in clause 10.2.1.1.1;

4) shall start timer TFE1 (emergency alert); and

5) shall remain in the current state.

NOTE: Each instance of timer TFE1 is per MCPTT user ID.

12.2.3.4 Terminating user receiving retransmitted emergency alert

When in state "E1: Not in emergency state" or in "E2: Emergency state", upon receiving a GROUP EMERGENCY ALERT message with the Originating MCPTT user ID IE stored in the list of users in emergency, the MCPTT client:

1) may update the stored location of the user with the received Location IE;

2) shall restart the associated timer TFE1 (emergency alert); and

3) shall remain in the current state.

12.2.3.5 Originating user cancels emergency alert

When in "E2: Emergency state", upon receiving an indication from the MCPTT user to cancel an emergency alert and the value of "/<x>/<x>/Common/MCPTTGroupCall/EmergencyAlert/Cancel" leaf node present in the user profile as specified in 3GPP TS 24.483 [45] set to "true", the MCPTT client:

1) shall set the stored emergency state as "false";

2) shall generate a GROUP EMERGENCY ALERT CANCEL message as specified in clause 15.1.18. In the GROUP EMERGENCY ALERT CANCEL message, the MCPTT client:

a) shall set the MCPTT group ID IE to the stored MCPTT group ID;

b) shall set the Originating MCPTT user ID IE to own MCPTT user ID; and

c) shall set the Sending MCPTT user ID IE to own MCPTT user ID;

3) shall send the GROUP EMERGENCY ALERT CANCEL message as specified in clause 10.2.1.1.1;

4) shall stop timer TFE2 (emergency alert retransmission); and

5) shall enter "E1: Not in emergency state" state.

12.2.3.6 Terminating user receives GROUP EMERGENCY ALERT CANCEL message

When in state "E1: Not in emergency state" or in "E2: Emergency state", upon receiving a GROUP EMERGENCY ALERT CANCEL message with the Originating MCPTT user ID IE stored in the list of users in emergency, the MCPTT client:

1) shall remove the MCPTT user ID and associated location information from the stored list of users in emergency;

2) shall generate a GROUP EMERGENCY ALERT CANCEL ACK message as specified in clause 15.1.19. In the GROUP EMERGENCY ALERT CANCEL ACK message, the MCPTT client:

a) shall set the MCPTT group ID IE to the MCPTT group ID IE of the received GROUP EMERGENCY ALERT CANCEL message; and

b) shall set the Sending MCPTT user ID IE to own MCPTT user ID; and

c) shall set the Originating MCPTT user ID IE to the Originating MCPTT user ID IE of the received GROUP EMERGENCY ALERT message;

3) shall send the GROUP EMERGENCY ALERT CANCEL ACK message as specified in clause 10.2.1.1.1;

4) shall stop the associated timer TFE1 (emergency alert); and5) shall remain in the current state.

12.2.3.7 Implicit emergency alert cancel

When in state "E1: Not in emergency state" or in "E2: Emergency state", upon expiry of timer TFE1 (emergency alert) associated with a stored MCPTT user ID, the MCPTT client:

1) shall remove the MCPTT user ID and associated location information from the stored list of users in emergency; and

2) shall remain in the current state.