16 Emergency Alert

24.2823GPPMission Critical Data (MCData) signalling controlProtocol specificationRelease 18TS

16.1 General

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

For on-network emergency alert, the procedures for originating and terminating MCData clients, participating MCData function and controlling MCData function are specified in clause 16.2.

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

16.2 On-network emergency alert

16.2.1 Client procedures

16.2.1.1 Emergency alert origination

Upon receiving a request from the MCData user to send an MCData emergency alert, the MCData client shall determine whether or not it is authorised to originate an emergency alert, by following the procedures in clause 6.2.8.1.6.

If the MCData emergency alert origination request is considered an unauthorised request for an MCData emergency alert, the MCData client shall indicate to the MCData user that an MCData emergency alert is not allowed on this group and shall terminate this procedure.

If the request was authorised, but the MCData user has not indicated the identity of the MCData group to receive the emergency alert, the MCData client shall use, in descending order of preference, one of the following: the value of the <uri-entry> element of the <entry> element of the <GroupEmergencyAlert> element of the <Common> element in the MCData user profile, if present; if not, the identity of the MCData group to which the most recent communication or affiliation request was made by the MCData client since last acquiring the MCData service. If an MCData group identity cannot be determined, the MCData client shall indicate the fact to the MCData user and shall terminate this procedure.

The MCData client shall generate a SIP MESSAGE as an out-of-dialog request, in accordance with 3GPP TS 24.229 [5] and IETF RFC 3428 [6], and:

1) shall include the ICSI value "urn:urn-7:3gpp-service.ims.icsi.mcdata" (coded as specified in 3GPP TS 24.229 [5]), in a P-Preferred-Service header field according to IETF RFC 6050 [7] 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.mcdata" along with the "require" and "explicit" header field parameters according to IETF RFC 3841 [8];

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 [5];

4) shall include an application/vnd.3gpp.mcdata-info+xml MIME body with the <mcdatainfo> element containing the <mcdata-Params> element (see clause D.1) with:

a) the <mcdata-request-uri> element set to the MCData group identity;

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

c) the <mcdata-client-id> element set to the MCData client ID of the originating MCData client; and

d) if the MCData client is aware of active functional aliases and if an active functional alias is to be included in the SIP MESSAGE request, the <anyExt> element of the <functional-alias-URI> element set to the URI of the used functional alias; and

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

5) shall include an application/vnd.3gpp.mcdata-location-info+xml MIME body with a <Report> element included in the <location-info> root element (see clause D.4);

6) shall include in the <Report> element the specific location information configured for the MCData emergency alert location trigger;

7) shall set the MCData emergency state if not already set;

8) shall set the MCData emergency alert state to "MDEA 2: emergency-alert-confirm-pending";

9) shall set the Request-URI to the public service identity identifying the participating MCData function serving the group identity; and

10) shall send the SIP MESSAGE request according to rules and procedures of 3GPP 24.229 [5];

On receiving a SIP 2xx response to the SIP MESSAGE request, the MCData client shall set the MCData emergency alert state to "MDEA 3: emergency-alert-initiated" and shall give the MCData user an indication of success.

On receiving a SIP 4xx response a SIP 5xx response or a SIP 6xx response to the SIP MESSAGE request, the MCData client shall set the MCData emergency alert state to "MDEA 1: no-alert" and shall indicate the failure to the MCData user.

NOTE: If no response is received after an implementation dependent amount of time or if there is an indication of communication failure, the MCData client can inform the user, and can clear the MCData emergency alert state or can retry sending the emergency alert to the MCData participating server. The MCData emergency state is left unchanged, as the MCData user presumably is in the best position to determine whether or not there still is an emergency situation and can use manual clearing, as necessary.

16.2.1.2 Emergency alert cancellation

Upon receiving a request from the MCData user to send an MCData emergency alert cancellation, the MCData client shall determine whether or not it is authorised to cancel an emergency alert, as follows:

1) if the MCData emergency cancellation request is for an MCData emergency alert originated by this MCData user, then the request shall be considered authorised if <allow-cancel-emergency-alert> element of the <actions> element of a <rule> element of the <ruleset> element of the MCData user profile document identified by the MCData ID and profile index associated with MCData user (see 3GPP TS 24.484 [12]) is present and is set to a value of "true"; or

2) if the MCData emergency cancellation request is for an MCData emergency alert originated by a different MCData user, then the request shall be considered authorised if <allow-cancel-emergency-alert-any-user> element of the <actions> element of a <rule> element of the <ruleset> element of the MCData user profile document identified by the MCData ID and profile index associated with MCData user (see 3GPP TS 24.484 [12]) is present and is set to a value of "true".

If the MCData emergency cancellation request is not considered authorised, the MCData client shall indicate this fact to the requesting MCData user and shall terminate this procedure.

If the authorised MCData emergency cancellation request is for an MCData emergency alert originated by this MCData user and if there are more than one outstanding emergency alerts from this MCData user and the MCData user has not indicated which one to cancel, the MCData client shall terminate this procedure after giving an indication of the condition to the MCData user.

The MCData client shall generate a SIP MESSAGE out-of dialog request in accordance with 3GPP TS 24.229 [5] and IETF RFC 3428 [6] and:

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

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.mcdata" along with the "require" and "explicit" header field parameters according to IETF RFC 3841 [8];

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

4) if the MCData emergency alert was originated by this MCData user, shall include an application/vnd.3gpp.mcdata-info+xml MIME body with the <mcdatainfo> element containing the <mcdata-Params> element (see clause D.1) with:

a) the <mcdata-request-uri> element set to the MCData group identity;

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

c) the <mcdata-client-id> element set to the MCData client ID of this MCData client; amd

d) if the MCData client is aware of active functional aliases and if an active functional alias is to be included in the SIP MESSAGE request, the <anyExt> element of the <functional-alias-URI> element set to the URI of the used functional alias;

5) if the MCData emergency alert was originated by a different MCData user, shall include an application/vnd.3gpp.mcdata-info+xml MIME body with the <mcdatainfo> element containing the <mcdata-Params> element (see clause D.1) with:

a) the <mcdata-request-uri> element set to the MCData group identity;

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

c) the <originated-by> element set to the MCData ID of the MCData user who originated the MCData emergency alert; and

d) if the MCData client is aware of active functional aliases, and an active functional alias is to be included in the SIP MESSAGE request, the <anyExt> element of the <functional-alias-URI> set to the URI of the used functional alias;

5A) if the MCData user has additionally requested the cancellation of the in-progress emergency state of the MCData 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 <mcdatainfo> element containing the <mcdata-Params> element;

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

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

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

On receipt of a SIP MESSAGE request containing an application/vnd.3gpp.mcdata-info+xml MIME body with an <alert-ind-rcvd> element set to "true" and an <mcdata-client-id> matching the MCData client ID included in the sent SIP MESSAGE request and if the sent SIP MESSAGE request did not contain an <originated-by> element in its application/vnd.3gpp.mcdata-info+xml MIME body, the MCData client shall:

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

a) set the MCData emergency alert state to "MDEA 1: no-alert"; and

b) clear the MCData emergency state if not already cleared; and

2) if the <alert-ind> element in the application/vnd.3gpp.mcdata-info+xml MIME body of the received SIP MESSAGE request is set to a value of "true" and if the MCData emergency alert state is set to "MDEA 4: emergency-alert-cancel-pending":

a) set the MCData emergency alert state to "MDEA 3: emergency-alert-initiated".

NOTE 1: It would appear to be an unusual situation for the initiator of an MCData emergency alert to not be able to clear their own alert. Nevertheless, an MCData user can be configured to be authorised to initiate MCData 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.mcdata-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 MCData emergency group communication state of the group to "MDEGC 1: emergency-gc-capable"; and

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

NOTE 2: 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 emergency alert cancellation request, if the sent SIP MESSAGE request did not contain an <originated-by> element in the application/vnd.3gpp.mcdata-info+xml MIME body and the MCData emergency alert state is set to "MDEA 4: emergency-alert-cancel-pending":

1) if the received SIP 4xx response, SIP 5xx response or SIP 6xx response does not contain an application/vnd.3gpp.mcdata-info+xml MIME body with the <mcdatainfo> element containing the <mcdata-Params> element containing the <alert-ind> element OR if it contains an application/vnd.3gpp.mcdata-info+xml MIME body with the <mcdatainfo> element containing the <mcdata-Params> element with the <alert-ind> element set to a value of "true" (see clause D.1), the MCData client shall set the MCData emergency alert state to "MDEA 3: emergency-alert-initiated".

16.2.1.3 MCData client receives an MCData emergency alert or communication notification

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ii) shall set the MCData emergency group communication state to "MDEGC 1: emergency-gc-capable";

NOTE 2: This is the case of the MCData client receiving the notification of the cancellation by a third party of an MCData emergency alert. This can be the MCData emergency alert of another MCData user or the MCData 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 MCData group can be included.

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

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

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

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

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

NOTE 3: This is the case of the MCData client receiving notification of an additional MCData user in an MCData emergency state (i.e., not the MCData user that originally triggered the in-progress emergency state of the group) joining the in-progress emergency group communication. An emergency alert indication, if included, is handled in step 1).

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

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

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

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

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

c) shall set the MCData emergency group communication state to "MDEGC 1: emergency-gc-capable";

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

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

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

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

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

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

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

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

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

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

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

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

c) shall set the MCData imminent peril group communication state to "MDIGC 1: imminent-peril-gc-capable";

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

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

6) shall send the SIP 200 (OK) response towards the MCData server according to rules and procedures of TS 24.229 [5].

16.2.1.4 MCData 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 MCData client:

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

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

a) set to "true":

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

ii) shall execute the procedure in clause 8.2.2 to affiliate to the group indicated by the participating MCData function; and

b) set to "false":

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

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

16.2.1.5 MCData 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 MCData client:

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

a) set to "true":

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

ii) if the MCData 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 MCData user an indication that MCData client has exited a pre-defined emergency alert area.

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

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

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

16.2.2 Participating MCData function procedures

16.2.2.1 Receipt of a SIP MESSAGE request for emergency notification from the served MCData client

Editor’s note: In the current release, support for emergency groups and emergency group communications may be absent, partial or limited, namely only provided to the extent of facilitating emergency alert functionality.

Upon receipt of a "SIP MESSAGE request for emergency notification for originating participating MCData function", the participating MCData 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 MCData function may include a Retry-After header field in the SIP 500 (Server Internal Error) response as specified in IETF RFC 3261 [4] 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 MCData function can, according to local policy, choose to accept the request.

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

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

3) if the MCData user is not affiliated with the MCData group as determined by clause 8.3.2.11, shall perform the actions specified in clause 8.3.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 MCData user due to the MCData user already having N2 simultaneous affiliations, shall reject the "SIP MESSAGE request for emergency notification for originating participating MCData 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.9 and skip the rest of the steps;

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

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

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

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

7) shall set the Request-URI of the outgoing SIP MESSAGE request to the public service identity of the controlling MCData function associated with the group identified by the <mcdata-request-uri> element contained in the <mcdatainfo> element containing the <mcdata-Params> element of the application/vnd.3gpp.mcdata-info+xml MIME body in the incoming SIP MESSAGE request;

NOTE 5: The public service identity can identify the controlling MCData function in the local MCData system or in an interconnected MCData system.

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

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

NOTE 8: How the participating MCData function determines the public service identity of the controlling MCData function serving the target MCData ID or of the MCData gateway server in the interconnected MCData system is out of the scope of the present document.

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

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

9) shall set the <mcdata-calling-user-id> element of the <mcdatainfo> element containing the <mcdata-Params> element to the MCData ID determined in step 2) above;

10) if the received SIP MESSAGE request contains an application/vnd.3gpp.mcdata-location-info+xml MIME body as specified in clause D.4, shall copy the contents of the application/vnd.3gpp.mcdata-location-info+xml MIME body in the received SIP MESSAGE request into an application/vnd.3gpp.mcdata-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;

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

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

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

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

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

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

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

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

16.2.2.2 Receipt of a SIP MESSAGE request for emergency notification for terminating MCData client

Editor’s note: In the current release, support for emergency groups and emergency group communications (in particular the use of the <emergency-ind> element) may be absent, partial or limited, namely only provided to the extent of facilitating emergency alert functionality.

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.mcdata-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.mcdata-info+xml MIME body.

Upon receipt of a "SIP MESSAGE requests for emergency notification for terminating participating MCData function", the participating MCData 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 MCData function may include a Retry-After header field in the SIP 500 (Server Internal Error) response as specified in IETF RFC 3261 [4] 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 MCData function can, by means beyond the scope of this specification, choose to accept the request.

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

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

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

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

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

16.2.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 MCData function with the Request-URI set to the public service identity of the terminating participating MCData function and the SIP MESSAGE request contains an application/vnd.3gpp.mcdata-info+xml MIME body with an <alert-ind-rcvd> element present, the participating MCData 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 MCData function may include a Retry-After header field in the SIP 500 (Server Internal Error) response as specified in IETF RFC 3261 [4] and skip the rest of the steps;

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

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

4) shall generate an outgoing SIP MESSAGE request in accordance with TS 24.229 [5] and IETF RFC 3428 [6] 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 [8] 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 MCData ID of the MCData user that was in the Request-URI of the incoming SIP MESSAGE request;

c) shall copy the contents of the application/vnd.3gpp.mcdata-info+xml MIME body received in the incoming SIP MESSAGE request into an application/vnd.3gpp.mcdata-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 [5].

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

16.2.3 Controlling MCData function procedures

16.2.3.1 Handling of a SIP MESSAGE request for emergency notification

Upon receipt of a "SIP MESSAGE request for emergency notification for controlling MCData function", the controlling MCData 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 MCData function may include a Retry-After header field in the SIP 500 (Server Internal Error) response as specified in IETF RFC 3261 [4] and skip the rest of the steps. 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 MCData 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.mcdata", "urn:urn-7:3gpp-service.ims.icsi.mcdata.sds" or "urn:urn-7:3gpp-service.ims.icsi.mcdata.fd";

3) if the received SIP MESSAGE request contains an application/vnd.3gpp.mcdata-info+xml MIME body with the <alert-ind> element set to a value of "false", shall perform the procedures specified in clause 16.2.3.2 and skip the rest of the steps; and

4) if the received SIP MESSAGE request contains an application/vnd.3gpp.mcdata-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 MCData emergency alert as specified in clause 6.3.7.2.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 [5] with the following clarifications:

i) shall include in the SIP 403 (Forbidden) response an application/vnd.3gpp.mcdata-info+xml MIME body as specified in clause D.1 with the <mcdatainfo> element containing the <mcdata-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 TS 24.229 [5] and skip the rest of the steps; and

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

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

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

II) if the MCData user is determined not to be eligible to be implicitly affiliated to the MCData 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.9 and skip the rest of the steps below; or

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

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

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

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

C) if the received SIP MESSAGE request contains an application/vnd.3gpp.mcdata-info+xml MIME body that contains a <functional-alias-URI> element shall set the <functional-alias-URI> element of the application/vnd.3gpp.mcdata-info+xml MIME body in the outgoing SIP MESSAGE request to the received value, otherwise shall not include a <functional-alias-URI> element; and

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

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

A) shall cache the information that the MCData user has initiated an MCData 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 [5];

v) shall generate a SIP MESSAGE request as described in clause 6.3.7.1.5 to indicate successful receipt of an emergency alert, and shall include in the application/vnd.3gpp.mcdata-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 <mcdata-client-id> element with the MCData client ID that was included in the incoming SIP MESSAGE request; and

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

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

16.2.3.2 Handling of a SIP MESSAGE request for emergency alert cancellation

Editor’s note: In the current release, support for emergency groups and emergency group communications (in particular the use of the <emergency-ind> element) may be absent, partial or limited, namely only provided to the extent of facilitating emergency alert functionality.

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

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

a) and if the received SIP MESSAGE request does not contain an <emergency-ind> element or is an unauthorised request for an MCData emergency communication cancellation as specified in clause 6.3.7.2.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 [5] with the following clarifications:

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

ii) if the received SIP MESSAGE request contains an <emergency-ind> element of the <mcdatainfo> 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 MCData emergency communication cancellation as determined in step i) above, shall include an <emergency-ind> element set to a value of "true" in the application/vnd.3gpp.mcdata-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 [5] and skip the rest of the steps; and

b) and if the received SIP MESSAGE request contains an <emergency-ind> element and is an authorised request for an MCData emergency communication cancellation as specified in clause 6.3.7.2.3 and the in‑progress emergency state of the MCData 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 MCData ID of the MCData user that triggered the setting of the in-progress emergency state of the MCData group;

iii) shall generate SIP re-INVITE requests to the other affiliated and joined members of the MCData group as specified in clause 6.3.7.1.1, and

A) for each affiliated and joined member shall send the SIP re-INVITE request towards the MCData client as specified in 3GPP TS 24.229 [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 MCData user’s emergency communication as specified in clause 6.3.7.1.2;

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

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

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

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

vi) shall send the SIP 200 (OK) response to the received SIP MESSAGE as specified in 3GPP TS 24.229 [5];

vii) shall generate a SIP MESSAGE request as described in clause 6.3.7.1.5 to indicate successful emergency communication cancellation;

viii) shall include in the application/vnd.3gpp.mcdata-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 <mcdata-client-id> element with the MCData client ID that was included in the incoming SIP MESSAGE request; and

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

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

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

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

c) if the received SIP MESSAGE request does not contain an <emergency-ind> element or is an unauthorised request for an MCData emergency communication cancellation as specified in slause 6.3.7.2.3, for each of the affiliated but not joined members of the group shall:

i) generate a "SIP MESSAGE request for emergency notification for terminating participating MCData function" to cancel the MCData user’s emergency alert as specified in clause 6.3.7.1.2;

ii) include in the application/vnd.3gpp.mcdata-info+xml MIME body with the <mcdatainfo> element containing the <mcdata-Params> element with the <mcdata-calling-user-id> element set to the value of the <mcdata-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.mcdata-info+xml MIME body, copy the contents of the received <originated-by> element to an <originated-by> element in the application/vnd.3gpp.mcdata-info+xml MIME body in the outgoing SIP MESSAGE request;

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

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

d) if the received SIP MESSAGE request contains an <emergency-ind> element and is an authorised request for an MCData emergency communication cancellation as specified in clause 6.3.7.2.3 and the in-progress emergency state of the MCData 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 cache the information that the MCData user has cancelled the outstanding in-progress emergency state of the group;

iii) shall generate SIP re-INVITE requests to the other affiliated and joined members of the MCData group as specified in clause 6.3.7.1.1, and

A) for each affiliated and joined member shall send the SIP re-INVITE request towards the MCData client as specified in 3GPP TS 24.229 [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 MCData user’s emergency communication as specified in clause 6.3.7.1.2;

B) include in the application/vnd.3gpp.mcdata-info+xml MIME body with the <mcdatainfo> element containing the <mcdata-Params> element with the <mcdata-calling-user-id> element set to the value of the <mcdata-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.mcdata-info+xml MIME body, copy the contents of the received <originated-by> element to an <originated-by> element in the application/vnd.3gpp.mcdata-info+xml MIME body in the outgoing SIP MESSAGE request;

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

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

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

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

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

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

h) shall include in the application/vnd.3gpp.mcdata-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 <mcdata-client-id> element with the MCData 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 <mcdatainfo> element set to a value of "false":

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

ii) otherwise, if this is an unauthorised request for an MCData emergency communication cancellation as specified in clause 6.3.7.2.3, 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.mcdata-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 TS 24.229 [5].

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

16.3 Off-network emergency alert

16.3.1 General

16.3.2 Basic state machine

16.3.2.1 General

16.3.2.2 Emergency alert state machine

The figure 16.3.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 MCData group.

Figure 16.3.2.2-1: Emergency alert state machine

The following piece of information is associated with the emergency alert state machine:

a) the stored emergency state of the MCData group.

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

16.3.2.3 Emergency alert states

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

16.3.2.3.2 E2: Emergency state

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

16.3.3 Procedures

16.3.3.1 Originating user sending emergency alert

When in state "E1: Not in emergency state", upon receiving an indication from the MCData user to transmit an emergency alert for an MCData group ID and the value of "/<x>/<x>/Common/AllowedActivateAlert" leaf node present in the user profile as specified in 3GPP TS 24.483 [42] is set to "true", the MCData client:

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

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

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

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

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

c) may 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 9.3.1.2;

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

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

16.3.3.2 Emergency alert retransmission

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

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

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

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

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

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

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

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

4) shall remain in the current state.

16.3.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 MCData user ID IE not stored in the list of users in emergency, the MCData client:

1) shall store the Originating MCData 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.15. In the GROUP EMERGENCY ALERT ACK message, the MCData client:

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

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

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

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

4) shall start timer TFE1 (Emergency Alert); and

5) shall remain in the current state.

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

Editor’s Note: [CR 0095, WI eMCData2] Use of timer TFE1 in case of several emergency alerts from multiple users is FFS.

16.3.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 MCData user ID IE stored in the list of users in emergency and Location IE different than the stored location of the user, the MCData 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.

16.3.3.5 Originating user cancels emergency alert

When in "E2: Emergency state", upon receiving an indication from the MCData user to cancel an emergency alert and the value of "/<x>/<x>/Common/AllowedCancelAlert" leaf node present in the user profile as specified in 3GPP TS 24.483 [42] is set to "true", the MCData 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.16. In the GROUP EMERGENCY ALERT CANCEL message, the MCData client:

a) shall set the MCData group ID IE to the stored MCData group ID; and

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

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

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

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

16.3.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 MCData user ID IE stored in the list of users in emergency, the MCData client:

1) shall remove the MCData 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.17. In the GROUP EMERGENCY ALERT CANCEL ACK message, the MCData client:

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

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

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

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

4) shall stop the associated timer TFE1 (Emergency Alert); and

5) shall remain in the current state.

16.3.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 MCData user ID, the MCData client:

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

2) shall remain in the current state.