12 Dispositions and Notifications

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

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

12.1 General

The procedures in clause 12 describe:

– the on-network procedures for generating out-of-band dispositions for on-network SDS and on-network FD;

– the on-network procedures for generating network notifications for file distribution; and

– the off-network procedures for generating SDS dispositions.

The MCData client can send a disposition notification as a direct result of receiving an MCData message (e.g. delivery notification) or can send a disposition notification at a later time (e.g. read notification). In certain circumstances the delivery and read notification can be delivered in one notification message.

In-band dispositions are sent in the media plane as specified in 3GPP TS 24.582 [15].

12.2 On-network disposition notifications

12.2.1 MCData client procedures

12.2.1.1 MCData client sends a disposition notification message

The MCData client shall follow the procedures in this clause to:

– indicate to an MCData client that an SDS message was delivered, read or delivered and read when the originating client requested a delivery, read or delivery and read report;

– indicate to the participating MCData function serving the MCData user that an SDS message was undelivered. The participating MCData function can store the message for later re-delivery;

– indicate to an MCData client that a request for FD was accepted, deferred or rejected; or

– indicate to an MCData client that a file download has been completed;

Before sending a disposition notification the MCData client needs to determine:

– the group identity related to an SDS or FD message request received as part of a group communication. The MCData client determines the group identity from the contents of the <mcdata-calling-group-id> element contained in the application/vnd.3gpp.mcdata-info+xml MIME body of the incoming SDS or FD message request; and

– the MCData user targeted for the disposition notification. The MCData client determines the targetted MCData user from the contents of the <mcdata-calling-user-id> element contained in the application/vnd.3gpp.mcdata-info+xml MIME body of the incoming SDS or FD message request.

The MCData client shall generate a SIP MESSAGE request in accordance with 3GPP TS 24.229 [5] and IETF RFC 3428 [6] with the clarifications given below.

The MCData client:

1) shall build the SIP MESSAGE request as specified in clause 6.2.4.1;

2) shall follow the rules specified in clause 6.4 for the handling of MIME bodies in a SIP message when processing the remaining steps in this clause;

3) shall insert in the SIP MESSAGE request an application/resource-lists+xml MIME body containing the MCData ID of the targeted MCData user in the "uri" attribute of the <entry> element of the <list> element of the <resource-lists> element of the application/resource-lists+xml MIME body, according to rules and procedures of IETF RFC 5366 [18];

4) void;

5) if sending a disposition notification in response to an MCData group data request, shall include an <mcdata-calling-group-id> element set to the MCData group identity in the application/vnd.3gpp.mcdata-info+xml MIME body;

6) if requiring to send an SDS notification, shall generate an SDS NOTIFICATION message and include it in the SIP MESSAGE request as specified in clause 6.2.3.1;

7) if requiring to send an FD notification, shall generate an FD NOTIFICATION message and include it in the SIP MESSAGE request as specified in clause 6.2.3.2; and

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

12.2.1.2 MCData client receives a disposition notification message

Upon receipt of a:

"SIP MESSAGE request for SDS disposition notification for terminating MCData client"; or

"SIP MESSAGE request for FD disposition notification for terminating MCData client";

the MCData client:

1) shall decode the contents of the application/vnd.3gpp.mcdata-signalling MIME body; and

2) shall deliver the notification to the user or application.

12.2.2 Participating MCData function procedures

12.2.2.1 Participating MCData function receives disposition notification from a MCData user

Upon receipt of a:

– "SIP MESSAGE request for SDS disposition notification for MCData server"; or

– "SIP MESSAGE request for FD disposition notification for MCData server";

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 to the SIP 500 (Server Internal Error) response as specified in IETF RFC 3261 [4] and skip the rest of the steps;

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;

NOTE 1: 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 participating MCData function cannot find a binding between the public user identity and an MCData ID or if the validity period of an existing binding has expired, then the participating MCData 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.9, and shall not continue with any of the remaining steps;

4) void;

5) if the SIP MESSAGE is a "SIP MESSAGE request for SDS disposition notification for MCData server" containing an SDS disposition notification type set to a value of "UNDELIVERED", shall temporarily store the message for re-delivery, shall start timer TD1 (SDS re-delivery timer) with the timer value as specified in clause F.2.1, and shall not continue with the remaining steps;

NOTE 2: The participating MCData function attempts re-delivery of the SDS message after timer TD1 (SDS re-delivery timer) expiry.

6) if the SIP MESSAGE is a "SIP MESSAGE request for SDS disposition notification for MCData server " containing an SDS disposition notification type set to a value of "DELIVERED", "READ" or "DELIVERED AND READ" and the message was temporarily stored for re-delivery, shall delete the message from temporary store and shall stop TD1 (SDS re-delivery timer);

6a) if the SIP MESSAGE is a "SIP MESSAGE request for FD disposition notification for MCData server", and the FD disposition notification type IE is set as "FILE DOWNLOAD COMPLETED" as specified in clause 15.2.6 and target MCData user ID is not included as specified in the step 3) of clause 12.2.1.1, shall skip the rest of the steps of this clause after sending the response as follows:

a) shall generate a SIP 200 (OK) response as specified in 3GPP TS 24.229 [5];

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

c) shall clear the corresponding stored deferred group comunication;

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

8) shall set the Request-URI of the outgoing SIP MESSAGE request to the public service identity of the controlling MCData function;

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

NOTE 4: 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 5: 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 6: 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 7: How the local MCData system routes the SIP request through an exit MCData gateway server is out of the scope of the present document.

9) shall copy all MIME bodies included in the incoming SIP MESSAGE request to the outgoing SIP MESSAGE request;

10) if not already included as part of step 8) above, shall include an application/vnd.3gpp.mcdata-info+xml MIME body in the outgoing SIP MESSAGE request, containing an <mcdata-calling-user-id> element set to the MCData ID of the originating user;

11) if the SIP MESSAGE is a "SIP MESSAGE request for SDS disposition notification for MCData server ", shall include the ICSI value "urn:urn-7:3gpp-service.ims.icsi.mcdata.sds" (coded as specified in 3GPP TS 24.229 [5]), into the P-Asserted-Service header field of the outgoing SIP MESSAGE request;

12) if the SIP MESSAGE is a "SIP MESSAGE request for FD disposition notification for MCData server ", shall include the ICSI value "urn:urn-7:3gpp-service.ims.icsi.mcdata.fd" (coded as specified in 3GPP TS 24.229 [5]), into the P-Asserted-Service header field of the outgoing SIP MESSAGE request;

13) if the SIP MESSAGE is a "SIP MESSAGE request for FD disposition notification for MCData server", and the FD disposition notification type IE is set as "FILE DOWNLOAD REQUEST ACCEPTED" or "FILE DOWNLOAD REQUEST REJECTED"as specified in clause 15.2.6, shall remove the file from the stored file list;

14) 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

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

Upon receipt of a SIP 202 (Accepted) response in response to the above SIP MESSAGE request, the participating MCData function:

1) shall generate a SIP 202 (Accepted) response as specified in 3GPP TS 24.229 [5]; and

2) shall send the SIP 202 (Accepted) response to the MCData client according to 3GPP TS 24.229 [5].

Upon receipt of a SIP 200 (OK) response in response to the above SIP MESSAGE request, the participating MCData function:

1) shall generate a SIP 200 (OK) response as specified in 3GPP TS 24.229 [5]; and

2) 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 above SIP MESSAGE request, the participating MCData function:

1) shall generate a SIP response according to 3GPP TS 24.229 [5];

2) shall include Warning header field(s) that were received in the incoming SIP response; and

3) shall forward the SIP response to the MCData client according to 3GPP TS 24.229 [5].

12.2.2.2 Participating MCData function receives disposition notification from a Controlling MCData function

Upon receipt of a:

– "SIP MESSAGE request for SDS disposition notification for terminating MCData client"; or

– "SIP MESSAGE request for FD disposition notification for terminating MCData client";

the participating MCData function:

1) if unable to process the request due to a lack of resources or if a risk of congestion exists, may reject the SIP MESSAGE request with a SIP 500 (Server Internal Error) response , optionally containing a Retry-After header field as specified in IETF RFC 3261 [4] . In this case, the participati ng MCData function shall 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 the public user identity;

3) if the binding between the MCData ID and the 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 shall skip the rest of the steps;

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

5) if sending an SDS disposition notification, shall include the ICSI value "urn:urn-7:3gpp-service.ims.icsi.mcdata.sds" (coded as specified in 3GPP TS 24.229 [5]), into the P-Asserted-Service header field of the outgoing SIP MESSAGE request;

5) if sending an FD disposition notification, shall include the ICSI value "urn:urn-7:3gpp-service.ims.icsi.mcdata.fd" (coded as specified in 3GPP TS 24.229 [5]), into the P-Asserted-Service header field of the outgoing SIP MESSAGE request;

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

Upon receipt of a SIP 2xx, 4xx, 5xx or 6xx response to the outgoing SIP MESSAGE request, the participating MCData function shall forward the SIP response to the controlling MCData function.

12.2.2.3 Participating MCData function sends a disposition notification message

The participating MCData function shall follow the procedures in this clause to:

– indicate to an MCData client that a request for FD was accepted, deferred or rejected; or

– indicate to an MCData client that a file download has been completed.

Before sending a disposition notification the participating MCData function needs to determine:

– the group identity related to an FD message request received as part of a group communication. The participating MCData function determines the group identity from the contents of the <mcdata-calling-group-id> element contained in the application/vnd.3gpp.mcdata-info+xml MIME body of the incoming FD message request; and

– the MCData user targeted for the disposition notification. The participating MCData function determines the targetted MCData user from the contents of the <mcdata-calling-user-id> element contained in the application/vnd.3gpp.mcdata-info+xml MIME body of the incoming FD message request.

The participating MCData function shall generate a SIP MESSAGE request in accordance with 3GPP TS 24.229 [5] and IETF RFC 3428 [6] with the clarifications given below.

The participating MCData function:

1) shall build the SIP MESSAGE request as specified in clause 6.3.2.2;

2) shall follow the rules specified in clause 6.4 for the handling of MIME bodies in a SIP message when processing the remaining steps in this clause;

4) if sending a disposition notification in response to an MCData group data request, shall include an <mcdata-calling-group-id> element set to the MCData group identity in the application/vnd.3gpp.mcdata-info+xml MIME body;

5) shall include an application/vnd.3gpp.mcdata-info+xml MIME body in the outgoing SIP MESSAGE request, containing an <mcdata-calling-user-id> element set to the MCData ID of the associated disposition notification of the MCData user;

6) if requiring to send an FD notification, shall generate an FD NOTIFICATION message and include it in the SIP MESSAGE request as specified in clause 6.3.8.1; and

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

12.2.3 Controlling MCData function procedures

Upon receipt of a:

– "SIP MESSAGE request for SDS disposition notification for MCData server"; or

– "SIP MESSAGE request for FD disposition notification for MCData server";

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 to the SIP 500 (Server Internal Error) response as specified in IETF RFC 3261 [4]. Otherwise, continue with the rest of the steps;

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.sds" or "urn:urn-7:3gpp-service.ims.icsi.mcdata.fd";

3) if the incoming SIP MESSAGE request does not contain an application/resource-lists+xml MIME body or contains an application/resource-lists+xml MIME body with more than one <entry> element in the set of <list> elements in the <resource-lists> element, shall reject the SIP MESSAGE request with a SIP 403 (Forbidden) response including warning text set to "145 unable to determine called party" in a Warning header field as specified in clause 4.9, and shall not continue with the rest of the steps;

4) shall attempt to correlate the disposition notification to the original SDS or FD request using the values contained in the Conversation ID and Message ID of the SDS NOTIFICATION message or FD NOTIFICATION message contained in the application/vnd.3gpp.mcdata-signalling MIME body of the SIP MESSAGE;

5) if unable to correlate the disposition notification as determined by step 4), shall reject the SIP MESSAGE request with a SIP 403 (Forbidden) response including warning text set to "216 unable to correlate the disposition notification" in a Warning header field as specified in clause 4.9, and shall not continue with the rest of the steps;

6) if:

a) a "SIP MESSAGE request for FD disposition notification for MCData server" has been received;

b) the FD disposition notification type IE in the FD NOTIFICATION message is set to "FILE DOWNLOAD REQUEST REJECTED"; and

c) the SIP MESSAGE does not contain an application/vnd.3gpp.mcdata-info+xml MIME body with an <mcdata-calling-group-id> element, or the SIP MESSAGE contains an application/vnd.3gpp.mcdata-info+xml MIME body with an <mcdata-calling-group-id> element and all other FD disposition notifications have been received from the invited group members and were all set to "FILE DOWNLOAD REQUEST REJECTED";

then:

a) shall delete the file stored in the media storage function that is associated with the Conversation ID and Message ID that was included in the FD NOTIFICATION message if no other file availability timers are running for a file; and

b) shall stop the running timer TDC2 (file availability timer), which is associated to the Conversation ID, Message ID, Application ID (if associated), and Extended application ID (if associated) that is included in the FD NOTIFICATION message;

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

8) if sending an SDS disposition notification:

a) shall include an Accept-Contact header field containing the g.3gpp.mcdata.sds media feature tag along with the "require" and "explicit" header field parameters according to IETF RFC 3841 [8] in the outgoing SIP MESSAGE request; and

b) shall include an Accept-Contact header field with the media feature tag g.3gpp.icsi-ref with the value of "urn:urn-7:3gpp-service.ims.icsi.mcdata.sds" along with parameters "require" and "explicit" according to IETF RFC 3841 [8] ] in the outgoing SIP MESSAGE request;

9) if sending an FD disposition notification:

a) shall include an Accept-Contact header field containing the g.3gpp.mcdata.fd media feature tag along with the "require" and "explicit" header field parameters according to IETF RFC 3841 [8]; and

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

10) shall set the Request-URI to the public service identity of the terminating participating MCData function associated to the MCData user to be invited;

NOTE 1: The public service identity can identify the terminating participating MCData function in the local MCData system or in an interconnected MCData system.

NOTE 2: If the terminating participating 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 3: If the terminating participating 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 4: How the controlling MCData function determines the public service identity of the terminating participating 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 5: How the local MCData system routes the SIP request through an exit MCData gateway server is out of the scope of the present document.

11) if sending an SDS disposition notification, shall include a P-Asserted-Service header field with the value "urn:urn-7:3gpp-service.ims.icsi.mcdata.sds";

12) if sending an FD disposition notification, shall include a P-Asserted-Service header field with the value "urn:urn-7:3gpp-service.ims.icsi.mcdata.fd";

13) shall copy the public user identity of the calling MCData user from the P-Asserted-Identity header field of the incoming SIP MESSAGE request into the P-Asserted-Identity header field of the outgoing SIP MESSAGE request;

14) shall copy the MCData ID of the MCData user listed in the MIME resources body of the incoming SIP MESSAGE request, into the <mcdata-request-uri> element in the application/vnd.3gpp.mcdata-info+xml MIME body of the outgoing SIP MESSAGE request;

15) if the incoming SIP MESSAGE request contains an application/vnd.3gpp.mcdata-info+xml MIME body with an <mcdata-calling-group-id> element:

a) shall retrieve the group document for the MCData group id contained in the <mcdata-calling-group-id> element from the group management server, if not already cached, and identify the group members;

b) shall verify that the MCData ID contained in the <mcdata-calling-user-id> element matches to a group member. If there is no match, the controlling MCData function shall reject the SIP request with a SIP 403 (Forbidden) response including warning text set to "116 user is not part of the MCData group" in a Warning header field as specified in clause 4.9, and shall not continue with the rest of the steps;

c) if MCData disposition notifications need to be aggregated and an aggregated disposition notification has not yet been sent:

i) if timer TDC1 (disposition aggregation timer) is not running, shall start timer TDC1 (disposition aggregation timer) with the timer value as specified in clause F.2.2;

ii) shall copy the application/vnd.3gpp.mcdata-signalling MIME body in the received SIP MESSAGE request to the outgoing SIP MESSAGE request;

NOTE 6: If the aggregated MCData disposition notifications do not fit into one SIP MESSAGE request, then the controlling MCData function needs to generate a new SIP MESSAGE request for the remaining disposition notifications.

iii) on expiry of timer TDC1 (disposition aggregation timer) shall continue with step 16; and

iv) if all MCData disposition notifications have been received from all group members shall continue with step 16; and

d) if MCData disposition notifications do not need to be aggregated, shall copy the application/vnd.3gpp.mcdata-signalling MIME body in the received SIP MESSAGE request to the outgoing SIP MESSAGE request and shall continue with step 16;

16) if the incoming SIP MESSAGE request contains an application/vnd.3gpp.mcdata-info+xml MIME body without an <mcdata-calling-group-id> element shall copy the application/vnd.3gpp.mcdata-signalling MIME body in the received SIP MESSAGE request to the outgoing SIP MESSAGE request;

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

18) shall generate a SIP 202 (Accepted) response in response to the

– "SIP MESSAGE request for SDS disposition notification for MCData server"; or

– "SIP MESSAGE request for FD disposition notification for MCData server"; and

19) shall send the SIP 202 (Accepted) response towards the originating participating MCData function according to 3GPP TS 24.229 [5].

12.3 Off-network dispositions

12.3.1 General

12.3.2 Sending off-network SDS delivery notification

To send an off-network SDS delivery notification, the MCData client:

1) shall store "DELIVERED" as the disposition type;

2) shall generate a SDS OFF-NETWORK NOTIFICATION message as specified in clause 15.1.8. In the SDS OFF-NETWORK NOTIFICATION message, the MCData client:

a) shall set the Sender MCData user ID IE to its own MCData user ID as specified in clause 15.2.15;

b) shall set the Conversation ID IE as the stored conversation ID as specified in clause 15.2.9;

c) shall set the Message ID IE as the stored SDS message ID as specified in clause 15.2.10;

d) shall set the Date and time IE as the stored SDS notification time as specified in clause 15.2.8;

e) shall set the SDS disposition notification type IE to the stored disposition type as specified in clause 15.2.5; and

f) may set:

i) the Application ID IE to the stored SDS application ID as specified in clause 15.2.7; or

ii) the Extended application ID IE to the stored extended SDS application ID as specified in clause 15.2.24;

3) shall send the SDS OFF-NETWORK NOTIFICATION message to the stored notification target MCData user ID as specified in clause 9.3.1.1;

4) shall initialise the counter CFS2 (SDS notification retransmission) with the value set to 1; and

5) shall start timer TFS2 (SDS notification retransmission).

12.3.3 Sending off-network SDS read notification

Upon receiving a display indication for the payload to the user or processing of the payload by the target application, the MCData client:

1) shall store "READ" as the disposition type;

2) shall store the current UTC time as the stored SDS notification time;

3) shall generate SDS OFF-NETWORK NOTIFICATION message as specified in clause 15.1.8. In the SDS OFF-NETWORK NOTIFICATION message, the MCData client:

a) shall set the Sender MCData user ID IE to its own MCData user ID as specified in clause 15.2.15;

b) shall set the Conversation ID IE as the stored conversation ID as specified in clause 15.2.9;

c) shall set the Message ID IE as the stored SDS message ID as specified in clause 15.2.10;

d) shall set the Data and time IE as the SDS notification time as specified in clause 15.2.8;

e) shall set the SDS disposition notification type IE to the stored disposition type as specified in clause 15.2.5; and

f) may set:

i) the Application ID IE set to the stored SDS application ID as specified in clause 15.2.7; or

ii) the Extended application ID IE to the stored extended SDS application ID as specified in clause 15.2.24;

4) shall send the SDS OFF-NETWORK NOTIFICATION message to the stored sender MCData user ID as specified in clause 9.3.1.1;

5) shall initialise the counter CFS2 (SDS notification retransmission) with the value set to 1; and

6) shall start timer TFS2 (SDS notification retransmission).

12.3.4 Sending off-network SDS delivered and read notification

Upon receiving a display indication for the payload to the user or processing of the payload by the target application, the MCData client:

1) shall store "DELIVERED AND READ" as the disposition type and stop the timer TFS3 (display and read);

2) shall store the current UTC time as the stored SDS notification time;

3) shall generate SDS OFF-NETWORK NOTIFICATION message. In the SDS OFF-NETWORK NOTIFICATION message, the MCData client:

a) shall set the Sender MCData user ID IE to its own MCData user ID as specified in clause 15.2.15;

b) shall set the Conversation ID IE as the stored conversation ID as specified in clause 15.2.9;

c) shall set the Message ID IE as the stored SDS message ID as specified in clause 15.2.10;

d) shall set the Date and time IE as the SDS notification time as specified in clause 15.2.8;

e) shall set the SDS disposition notification type IE to the stored disposition type as specified in clause 15.2.5; and

f) may set:

i) the Application ID IE to the stored SDS application ID as specified in clause 15.2.7; or

ii) the Extended application ID IE to the stored extended SDS application ID as specified in clause 15.2.24;

4) shall send the SDS OFF-NETWORK NOTIFICATION message to the stored sender MCData user ID as specified in clause 9.3.1.1;

5) shall initialise the counter CFS2 (SDS notification retransmission) with the value set to 1; and

6) shall start timer TFS2 (SDS notification retransmission).

12.3.5 Off-network SDS notification retransmission

Upon expiry of timer TFS2 (SDS notification retransmission), the MCData client:

1) shall generate a SDS OFF-NETWORK NOTIFICATION message as specified in clause 15.1.8. In the SDS OFF-NETWORK NOTIFICATION message, the MCData client:

a) shall set the Sender MCData user ID IE to its own MCData user ID as specified in clause 15.2.15;

b) shall set the Conversation ID IE as the stored conversation ID as specified in clause 15.2.9;

c) shall set the Message ID IE as the stored SDS message ID as specified in clause 15.2.10;

d) shall set the Date and time IE as the stored SDS notification time as specified in clause 15.2.8;

e) shall set the SDS disposition type IE to the stored disposition type as specified in clause 15.2.5; and

f) may set:

i) the Application ID IE to the stored SDS application ID as specified in clause 15.2.7; or

ii) the Extended application ID IE to the stored extended SDS application ID as specified in clause 15.2.24;

2) shall send the SDS OFF-NETWORK NOTIFICATION message to the stored sender MCData user ID as specified in clause 9.3.1.1;

3) shall increment the counter CFS2 (SDS notification retransmission) by 1; and

4) shall start timer TFS2 (SDS notification retransmission) if the associated counter CFS2 (SDS notification retransmission) has not reached its upper limit.

12.4 Network-triggered notifications for FD

12.4.1 General

12.4.1.1 File availability expiry

When the controlling MCData function receives a "SIP MESSAGE request for FD using HTTP for controlling MCData function" (referred to as FD request), it starts a timer TDC2 (file availability timer). The timer value is derived from the "file availability" information contained in metadata in the FD request (if included) or by local policy. The timer running for the file is uniquely associated to the Conversation ID and Message ID in the FD request.

The controlling MCData function tracks which MCData client(s) have downloaded the file referenced by the file URL received in an FD request which is associated to a Conversation ID and Message ID. On expiry of timer TDC2 (file availability timer), the controlling MCData function sends a FD NETWORK NOTIFICATION message with a notification type set to "FILE EXPIRED UNAVAILABLE TO DOWNLOAD". The MCData client is notified that the file associated with the Conversation ID and Message ID is no longer available to download.

12.4.2 Controlling MCData function procedures

12.4.2.1 Generation of a SIP MESSAGE request for notification

This clause is referenced from other procedures and is not run standalone.

The controlling MCData function

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

2) shall include an Accept-Contact header field containing the g.3gpp.mcdata.fd media feature tag along with the "require" and "explicit" header field parameters according to IETF RFC 3841 [8] in the outgoing SIP MESSAGE request;

3) shall include an Accept-Contact header field with the media feature tag g.3gpp.icsi-ref with the value of "urn:urn-7:3gpp-service.ims.icsi.mcdata.fd" along with parameters "require" and "explicit" according to IETF RFC 3841 [8] in the outgoing SIP MESSAGE request;

4) shall follow the rules specified in clause 6.4 for the handling of MIME bodies in a SIP message when processing the remaining steps in this clause;

5) shall include in an application/vnd.3gpp.mcdata-info+xml MIME body of the outgoing SIP MESSAGE request:

– the <mcdata-request-uri> element set to the MCData ID of the MCData user; and

– the <request-type> element set to a value of "notify";

6) shall set the Request-URI to the public service identity of the terminating participating MCData function associated to the MCData user to be invited;

NOTE 1: The public service identity can identify the terminating participating MCData function in the local MCData system or in an interconnected MCData system.

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

7) shall include the public service identity of the controlling MCData function in the P-Asserted-Identity header field; and

8) shall include a P-Asserted-Service header field with the value "urn:urn-7:3gpp-service.ims.icsi.mcdata.fd".

12.4.2.2 Expiry of timer TDC2 (file availability timer)

When timer TDC2 (file availability timer) associated to a specific Conversation ID and Message ID expires, the controlling MCData function shall identify a target set of MCData client(s) as being:

– the MCData client that received a one-to-one file distribution using HTTP for the associated Conversation ID and Message ID, but has not yet downloaded the file; or

– each MCData client that received a group standalone file distribution using HTTP for the associated Conversation ID and Message ID, but have not yet downloaded the file;

On expiry of timer TDC2 (file availability timer), for each identified MCData client, the controlling MCData function:

NOTE: The file availability timer is associated to the Conversation ID and Message ID that was present in the initial FD request.

1) shall generate a SIP MESSAGE request as specified in clause 12.4.2.1;

2) shall include an FD NETWORK NOTIFICATION message in an application/vnd.3gpp.mcdata-signalling MIME body of the SIP MESSAGE request with:

a) the FD notification type IE as "FILE EXPIRED UNAVAILABLE TO DOWNLOAD" as specified in clause 15.2.6;

b) shall set the Date and time IE to the current time as specified in clause 15.2.8;

c) the Conversation ID IE set to a value identifying the conversation, as specified in clause 15.2.9;

d) the Message ID IE set to a value identifying the message as specified in clause 15.2.10;

e) if an Application ID was stored against the expired timer TDC2 (file availability timer), shall set the Application ID to the stored value as specified in clause 15.2.7;

f) if an Extended application ID was stored against the expired timer TDC2 (file availability timer), shall set the Extended application ID to the stored value as specified in clause 15.2.7; and

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

12.4.3 Participating MCData function procedures

The participating MCData function shall follow the procedures in clause 10.2.4.3.2.

12.4.4 MCData client terminating procedures

On receipt of a SIP MESSAGE request containing an application/vnd.3gpp.mcdata-signalling MIME body with a FD NETWORK NOTIFICATION message, the MCData client:

1) may reject the SIP MESSAGE request if there are not enough resources to handle the SIP MESSAGE request;

2) if the SIP MESSAGE request is rejected in step 1), shall respond towards the participating MCData function with a SIP 480 (Temporarily unavailable) response and skip the rest of the steps of this clause;

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

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

5) shall decode the contents of the FD NETWORK NOTIFICATION message contained in the application/vnd.3gpp.mcdata-signalling MIME body;

6) if the FD NETWORK NOTIFICATION message contains an Application ID or contains an Extended application ID, shall deliver the FD NETWORK NOTIFICATION message to the application; and

7) if the FD NETWORK NOTIFICATION message does not contain an Application ID and does not contain an Extended application ID, shall deliver the FD NETWORK NOTIFICATION message to the user.