6 SDS media plane procedures

24.5823GPPMission Critical Data (MCData) media plane controlProtocol specificationRelease 17TS

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

6.1 MCData client procedures

6.1.1 Standalone SDS via media plane

6.1.1.1 General

In a standalone SDS via media plane, upon receiving an SDS request from the user or user application the originating MCData client establishes the media plane as specified in 3GPP TS 24.282 [8]. When the media plane is established a conversation ID is associated with this SDS message.

For the procedures in clause 6.1.1.2 it is assumed that it has been verified that:

1. if standalone one to one SDS using media plane is initiated:

a. the MCData client is allowed to transmit data;

b. the size of the SDS message is less than or equal to maximum amount of data that the MCData user can transmit in a single request during one-to-one communication; and

c. the size of the SDS message is less than or equal to maximum data size for SDS;

2. if standalone group SDS using media plane is initiated:

a. the MCData client is allowed to transmit data in this group;

b. the size of the SDS message is less than or equal to maximum amount of data that the MCData user can transmit in a single request during group communication;and

c. the size of the SDS message is less than or equal to maximum data size for SDS; and3. the size of the short data including the media plane information elements is larger than the allowed limits over MCData-SDS-1 interface using SIP reference points.

before the media plane establishment is initiated as specified in 3GPP TS 24.282[8]:

The procedures in clause 6.1.1.2 and clause 6.1.1.3 are applicable for one-to-one and group standalone SDS using media plane.

6.1.1.2 Procedures for the originating MCData client

6.1.1.2.1 Handling MSRP connection

Upon receiving an indication to establish MSRP connection for standalone SDS using media plane as the originating client, the MCData client:

1. shall act as an MSRP client according to IETF RFC 6135 [12];

2. shall act according to IETF RFC 6135 [12], as:

a. an "active" endpoint, if a=setup attribute in the received SDP answer is set to "passive"; and

b. an "passive" endpoint, if a=setup attribute in the received SDP answer is set to "active";

3. shall establish the MSRP connection according to the MSRP connection parameters in the SDP answer received in the SIP 200 (OK) response according to IETF RFC 4975 [11]; and

4. if acting as an "active" endpoint, shall send an empty MSRP SEND request to bind the MSRP connection to the MSRP session from the perspective of the passive endpoint according to the rules and procedures of IETF RFC 4975 [11] and IETF RFC 6135 [12].

On receiving MSRP 200 (OK) response to the first MSRP SEND request, the MCData client:

1. shall generate a SDS SIGNALLING PAYLOAD as specified in clause 6.1.1.2.2;

2. shall generate a SDS DATA PAYLOAD as specified in clause 6.1.1.2.3;

3. shall include the SDS SIGNALLING PAYLOAD and SDS DATA PAYLOAD in an MSRP SEND request as specified in clause 6.1.1.2.4; and

4. shall send the MSRP SEND request on the established MSRP connection.

If MSRP chunking is not used then on receipt of a 200 (OK) response, the MCData client shall terminate the SIP session as specified in 3GPP TS 24.282 [8].

If MSRP chunking is used, the MCData client:

1. shall send further MSRP SEND requests as necessary;

2. shall wait for a 200 (OK) response to each MSRP SEND request sent; and

3. on receipt of the last 200 (OK) response shall terminate the SIP session as specified in 3GPP TS 24.282 [8].

On receiving a non-200 MSRP response to the MSRP SEND request the MCData client shall handle the error as specified in IETF RFC 4975 [11]. To terminate the MSRP session, the MCData client:

1. if there are further MSRP chunks to send, shall abort transmission of these further MSRP chunks;

2. shall indicate to MCData user that the SDS message could not be sent; and

3. shall terminate the SIP session as specified in 3GPP TS 24.282 [8].

On receiving an indication to terminate the session from the signalling plane, the MCData client:

1. if there are further MSRP chunks to send, shall abort transmission of these further MSRP chunks and may indicate to MCData user that the SDS message could not be sent.

6.1.1.2.2 Generate signalling payload

In order to generate an SDS signalling payload, the MCData client:

1. shall generate an SDS SIGNALLING PAYLOAD message as specified in 3GPP TS 24.282 [8]; and

2. shall include the SDS SIGNALLING PAYLOAD message in an application/vnd.3gpp.mcdata-signalling MIME body as specified in 3GPP TS 24.282 [8]; and

When generating a an SDS SIGNALLING PAYLOAD message, the MCData client:

1. shall generate a SDS SIGNALLING PAYLOAD message as defined in 3GPP TS 24.282 [8]. In the SDS SIGNALLING PAYLOAD message, the MCData client:

a. may include and set the Disposition request type IE to:

i. "DELIVERY", if only delivery disposition is requested;

ii. "READ", if only read disposition is requested; or

iii. "DELIVERY AND READ", if both delivery and read dispositions are requested;

b. shall set Date and time IE to current UTC time;

c. shall set Conversation ID IE to a universally unique message ID generated as per IETF RFC 4122 [10];

d. shall set Message ID IE to a universally unique message ID generated as per IETF RFC 4122 [10];

e. if indicated that the SDS message is in reply to another SDS message then, shall include the Reply ID IE set to the message identifier of the indicated SDS message;

f. if indicated that the target recipient of the SDS message is an application then, shall set Application Identifier IE to the application identifier; and

g) shall set the Sender MCData user ID to its own MCData user ID as specified in clause 15.2.15 of 3GPP TS 24.282 [8].

6.1.1.2.3 Generate data payload

In order to generate SDS data payload, the MCData client:

1. shall generate a DATA PAYLOAD message as specified in 3GPP TS 24.282 [8]; and

2. shall include the DATA PAYLOAD message in an application/vnd.3gpp.mcdata-payload MIME body as specified in 3GPP TS 24.282 [8].

When generating a a DATA PAYLOAD message, the MCData client:

1. shall generate a SDS DATA PAYLOAD message as defined in 3GPP TS 24.282 [8]. In the SDS DATA PAYLOAD message, the MCData client:

a. shall set Number of payloads IE to the total number of payloads being sent; and

b. for each payload, shall include Payload IE. In the Payload IE:

i. shall set Payload content type to "TEXT", or "BINARY", or "HYPERLINKS", or "LOCATION" according to the payload type; and

ii. shall set Payload data IE to actual payload.

6.1.1.2.4 Generate MSRP SEND for SDS message

The MCData client shall take the procedures in clause 6.4.1 into consideration when generating MSRP SEND messages.

The MCData client shall generate MSRP SEND for SDS message requests according to IETF RFC 4975 [11].

When generating an MSRP SEND for SDS message request containing an SDS SIGNALLING PAYLOAD message and an SDS DATA PAYLOAD message, the MCData client

1. shall set To-Path header according to the MSRP URI(s) received in the answer SDP;

2. shall include two MIME bodies in accordance with clause 6.4.1 where:

a. in the first body the Content-Type header field is set to "application/vnd.3gpp.mcdata-signalling" and the generated SDS SIGNALLING PAYLOAD message is included; and

b. in the second body the Content-Type header field is set to "application/vnd.3gpp.mcdata-payload" and the generated SDS DATA PAYLOAD message is included.

When generating an MSRP SEND for SDS message request containing only an SDS DATA PAYLOAD message, the MCData client:

1. shall set To-Path header according to the MSRP URI(s) received in the answer SDP;

2. shall set the Content-Type as "application/vnd.3gpp.mcdata-payload"; and

3. shall set the body of the MSRP SEND request to the generated SDS DATA PAYLOAD message.

When generating an MSRP SEND for SDS message request containing only an SDS SIGNALLING PAYLOAD, the MCData client.

1. shall set To-Path header according to the MSRP URI(s) received in the answer SDP;

2. shall set the Content-Type as "application/vnd.3gpp.mcdata-signalling"; and

3. shall set the body of the MSRP SEND request to the generated SDS SIGNALLING PAYLOAD message.

6.1.1.3 Procedures for the terminating MCData client

6.1.1.3.1 Handling MSRP connection

Upon receiving an indication to establish MSRP connection for standalone SDS using media plane as the terminating client, the MCData client:

1. shall act as an MSRP client according to IETF RFC 6135 [12];

2. shall act either as an active endpoint or as an passive endpoint to open the transport connection, according to IETF RFC 6135 [12];

3. shall establish the MSRP connection according to the MSRP connection parameters in the SDP offer received in the SIP INVITE request according to IETF RFC 4975 [11];

Once the MSRP connection is established, the MCData client:

1. on receipt of an MSRP request in an MSRP session, shall follow the rules and procedures defined in IETF RFC 4975 [11] and in IETF RFC 6714 [13];

2. If an MSRP SEND request indicates the use of chunking, shall wait until all further MSRP SEND requests for the remaining chunks have been received and shall reassemble the entire set of MSRP requests into the MCData standalone message before delivering the content to the application; and

3. shall handle the received content as described in clause 6.1.1.3.2.

6.1.1.3.2 Handling received content and disposition requests

The MCData client:

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

2. shall decode the contents of the application/vnd.3gpp.mcdata-payload MIME body;

3. if the SDS SIGNALLING PAYLOAD message contains a new Conversation ID, shall instantiate a new conversation with the Message ID in the SDS SIGNALLING PAYLOAD identifying the first message in the conversation thread;

4. if the SDS SIGNALLING PAYLOAD message contains an existing Conversation ID and:

a. if the SDS SIGNALLING PAYLOAD message does not contain an InReplyTo Message ID, shall use the Message ID in the SDS SIGNALLING PAYLOAD to identify a new message in the existing conversation thread; and

b. if the SDS SIGNALLING PAYLOAD message contains an InReplyTo Message ID, shall associate the message to an existing message in the conversation thread as identified by the InReplyTo Message ID in the SDS SIGNALLING PAYLOAD and use the Message ID in the SDS SIGNALLING PAYLOAD to identify the new message;

5. shall identify the number of Payload IEs in the DATA PAYLOAD message from the Number of Payloads IE in the DATA PAYLOAD message;

6. if the SDS SIGNALLING PAYLOAD message does not contain an Application identifier IE:

a. shall determine that the payload contained in the DATA PAYLOAD message is for user consumption;

b. may notify the MCData user; and

c. shall render the contents of the Payload IE(s) to the MCData user;

7. if the SDS SIGNALLING PAYLOAD message contains an Application identifier IE:

a. shall determine that the payload contained in the DATA PAYLOAD message is not for user consumption;

b. shall not notify the MCData user;

c. if the Application identifier value is unknown, shall discard the SDS message; and

d. if the Application identifier value is known, shall deliver the contents of the Payload IE(s) to the identified application; and

8. if SDS Disposition request type IE is present in the SDS SIGNALLING PAYLOAD message received in clause 6.1.1.3.1 then, shall send a disposition notification as described in 3GPP TS 24.282 [8] clause 9.2.1.3.

6.1.2 Short data during an SDS session

6.1.2.1 General

In a SDS session, upon receiving an SDS request from the user or user application the originating MCData client establishes the media plane as specified in 3GPP TS 24.282 [8].

The procedure in clause 6.1.2.2 and clause 6.1.2.3 are applicable for one-to-one and group SDS session.

Any MCData user with appropriate permissions, originator of the SDS session or not, can send a SDS message during the SDS session.

A client which is not permitted to transmit data should not use the procedure in clause 6.1.2.2 and clause 6.1.2.3.

6.1.2.2 Procedures for the originating MCData client

6.1.2.2.1 Handling MSRP connection

Upon receiving an indication to establish MSRP connection for SDS session as the originating MCData client, the MCData client:

1. shall act as an MSRP client according to IETF RFC 6135 [12];

2. shall act according to IETF RFC 6135 [12], as:

a. an "active" endpoint, if a=setup attribute in the received SDP answer is set to "passive"; and

b. an "passive" endpoint, if a=setup attribute in the received SDP answer is set to "active";

3. shall establish the MSRP connection according to the MSRP connection parameters in the SDP answer received in the SIP 200 (OK) response according to IETF RFC 4975 [11];

Once the MSRP session is established, the MCData client:

1. on receipt of an MSRP request in the MSRP session, shall follow the rules and procedures defined in IETF RFC 4975 [11] and in IETF RFC 6714 [13];

2. If an MSRP SEND request indicates the use of chunking, shall wait until all further MSRP SEND requests for the remaining chunks have been received and shall reassemble the entire set of MSRP requests into the MCData SDS message before delivering the content to the application; and

3. shall handle the received content as described in clause 6.1.2.6.

On receiving MSRP 200 (OK) response to the first MSRP SEND request, the MCData client can generate and send an SDS message as specified in clause 6.1.2.4, or can generate and send an SDS disposition notification for a received SDS message as specified in clause 6.1.2.5, if requested.

Received content and disposition requests shall be handled as specified in clause 6.1.2.6.

6.1.2.2.2 Void

6.1.2.2.3 Void

6.1.2.2.4 Void

6.1.2.3 Procedures for the terminating MCData client

6.1.2.3.1 Handling MSRP connection

Upon receiving an indication to establish MSRP connection for SDS session as the terminating MCData client, the MCData client:

1. shall act as an MSRP client according to IETF RFC 6135 [12];

2. shall act either as an active endpoint or as an passive endpoint to open the transport connection, according to IETF RFC 6135 [12];

3. shall establish the MSRP connection according to the MSRP connection parameters in the SDP offer received in the SIP INVITE request according to IETF RFC 4975 [11];

Once the MSRP session is established, the MCData client:

1. on receipt of an MSRP request in the MSRP session, shall follow the rules and procedures defined in IETF RFC 4975 [11] and in IETF RFC 6714 [13];

2. If an MSRP SEND request indicates the use of chunking, shall wait until all further MSRP SEND requests for the remaining chunks have been received and shall reassemble the entire set of MSRP requests into the MCData SDS message before delivering the content to the application; and

3. shall handle the received content as described in clause 6.1.2.6.

On receiving MSRP 200 (OK) response to the first MSRP SEND request sent as "active" endpoint, or after sending MSRP 200 (OK) response to the first MSRP SEND request received as "passive" endpoint, the MCData client can generate and send an SDS message as specified in clause 6.1.2.4, or can generate and send an SDS disposition notification for a received SDS message as specified in clause 6.1.2.5, if requested.

Received content and disposition requests shall be handled as specified in clause 6.1.2.6.

6.1.2.3.2 Void

6.1.2.4 Sending SDS message

An MCData client is allowed to send a one-to-one SDS message only if:

1. the <allow-transmit-data> element of an <actions> element is present with a value "true" (see the MCData user profile document in 3GPP TS 24.484 [7]);

2. the size of the SDS message is less than or equal to the value of the <max-data-size-sds-bytes> element in the MCData service configuration document as specified in 3GPP TS 24.484 [7]; and

3. the size of the SDS message is less than or equal to the value of <MaxData1To1> element of the MCData user profile document (see the MCData user profile document in 3GPP TS 24.484 [7]).

An MCData client is allowed to send a group SDS message only if:

1. the <mcdata-allow-transmit-data-in-this-group> element of an <action> element is present with a value "true" as defined in the MCData group document for this MCData group as specified in 3GPP TS 24.481 [4];

2. the size of the SDS message is less than or equal to the value contained in the <mcdata-on-network-max-data-size-for-SDS> as defined in the MCData group document for this MCData group as specified in 3GPP TS 24.481 [4]; and

3. the size of the SDS message is less than or equal to the value contained in the <mcdata-max-data-in-single-request> element of the <entry> element of the MCData group document for this MCData group as specified in 3GPP TS 24.481 [4].

If the above-mentioned conditions satisfy, the MCData client:

1. shall generate an SDS SIGNALLING PAYLOAD as specified in clause 6.1.1.2.2;

2. shall generate an SDS DATA PAYLOAD as specified in clause 6.1.1.2.3;

3. shall include the SDS SIGNALLING PAYLOAD and SDS DATA PAYLOAD in an MSRP SEND request as specified in clause 6.1.1.2.4, with the following clarification:

a. shall set To-Path header according to the MSRP URI in the received SDP; and

4. shall send the MSRP SEND request on the established MSRP connection.

6.1.2.5 SDS Notification

6.1.2.5.1 Sending SDS Notification

To send an SDS disposition notification, the MCData client:

1. shall generate a SDS NOTIFICATION as specified in clause 6.1.2.5.2;

2. shall include the SDS NOTIFICATION in an MSRP SEND request as specified in clause 6.1.2.5.3, with the following clarification;

a. shall set To-Path header according to the MSRP URI in the received SDP; and

3. shall send the MSRP SEND request on the established MSRP connection.

If MSRP chunking is used, the MCData client:

1. shall send further MSRP SEND requests as necessary.

On receiving a non-200 MSRP response to the MSRP SEND request the MCData client shall handle the error as specified in IETF RFC 4975 [11]. To terminate the MSRP session, the MCData client:

1. if there are further MSRP chunks to send, shall abort transmission of these further MSRP chunks; and

2. shall indicate to MCData user that the SDS message or the SDS disposition notification could not be sent.

6.1.2.5.2 Generate SDS NOTIFICATION

In order to generate an SDS notification, the MCData client:

1. shall generate an SDS NOTIFICATION message as specified in 3GPP TS 24.282 [8]; and

2. shall include the SDS NOTIFICATION message in an application/vnd.3gpp.mcdata-signalling MIME body as specified in 3GPP TS 24.282 [8].

When generating an SDS NOTIFICATION message, the MCData client:

1. if sending a delivered notification, shall set the SDS disposition notification type IE as "DELIVERED";

2. if sending a read notification, shall set the SDS disposition notification type IE as "READ";

3. if sending a delivered and read notification, shall set the SDS disposition notification type IE as "DELIVERED AND READ";

4. if the SDS message could not be delivered to the user or application (e.g. due to lack of storage), shall set the SDS disposition notification type IE as "UNDELIVERED";

5. shall set the Date and time IE to the current time;

6. shall set the Conversation ID to the value of the Conversation ID that was received in the SDS message;

7. shall set the Message ID to the value of the Message ID that was received in the SDS message;

8. if the SDS message was destined for the user, shall not include an Application ID IE;

9. if the SDS message was destined for an application, shall include an Application ID IE set to the value of the Application ID that was included in the SDS message; and

10. shall set the Sender MCData user ID to its own MCData user ID as specified in clause 15.2.15 of 3GPP TS 24.282 [8].

6.1.2.5.3 Generate MSRP SEND for SDS disposition notification

The MCData client shall generate MSRP SEND requests for SDS disposition notification according to IETF RFC 4975 [11].

When generating an MSRP SEND request for SDS disposition notification containing an SDS NOTIFICATION message, the MCData client

1. shall set To-Path header according to the MSRP URI(s) received in the answer SDP;

2. shall set the content type as Content-Type = "application/vnd.3gpp.mcdata-signalling"; and

3. shall set the body of the MSRP SEND request to the generated SDS NOTIFICATION message.

6.1.2.6 Handling received content and disposition requests

Upon receiving an SDS message, the MCData client:

1. shall follow the procedure defined in clause 6.1.1.3.2, with the following clarification:

a. if SDS Disposition request type IE is present in the received SDS SIGNALLING PAYLOAD message then, shall send an SDS disposition notification as described in clause 6.1.2.5.

Upon receiving an SDS disposition notification, 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.

6.2 Participating MCData function procedures

6.2.1 Standalone SDS via media plane

6.2.1.1 General

For a standalone SDS via media plane, the media plane is established between the originating MCData client and the originating participating MCData function, the originating participating MCData function and the controlling MCData function, the controlling MCData function and the terminating participating MCData function(s) and each terminating participating MCData function and the terminating MCData client(s) as specified in 3GPP TS 24.282 [8].

The procedures in clause 6.2.1.4 and clause 6.2.1.5 are applicable for one-to-one and group standalone SDS using media plane.

6.2.1.2 Establishing MSRP session to receive standalone SDS message

To receive a SDS message over MSRP, the participating MCData function:

1. shall act according to IETF RFC 6135 [12], as:

a. an "passive" endpoint, if a=setup attribute in the sent SDP answer was set to "passive"; and

b. an "active" endpoint, if a=setup attribute in the sent SDP answer was set to "active"; and

2. shall establish an MSRP connection according to the MSRP connection parameters in the sent SDP answer response as described in IETF RFC 4976 [14].

6.2.1.3 Establish MSRP session to send standalone SDS message

To send a SDS message over MSRP, the participating MCData function:

1. shall act according to IETF RFC 6135 [12], as:

a. an "active" endpoint, if a=setup attribute in the received SDP answer is set to "passive"; and

b. an "passive" endpoint, if a=setup attribute in the received SDP answer is set to "active"; and

2. shall establish the MSRP connection according to the MSRP connection parameters in the received SDP answer response as described in IETF RFC 4976 [14].

6.2.1.4 Procedures for the originating participating MCData function

6.2.1.4.1 Establish MSRP session with the originating MCData client

The originating participating MCData function should establish the MSRP session with the originating MCData client as specified in clause 6.2.1.2.

6.2.1.4.2 Establish MSRP session with the controlling MCData function

The originating participating MCData function should establish the MSRP session with the controlling MCData function as specified in clause 6.2.1.3.

6.2.1.4.3 Handling of received MSRP messages

Upon receiving an MSRP SEND request from the originating MCData client, the originating participating MCData function:

1. if in a standalone one-to-one SDS using media plane, shall verify the SDS message size is less than or equal to <MacData1To1> element of the MCData user profile document for the originating MCData client (see the MCData user profile document in 3GPP TS 24.484 [7]);

2. if the verifications in 1 above fails, shall send the MSRP response with the error code 403 to the originating MCData client and shall not continue with the rest of the procedure;

3. if an MSRP connection is not established with the controlling MCData function then, shall establish the MSRP connection as specified in clause 6.2.1.4.2. Otherwise, shall use the existing MSRP connection; and

4. shall forward the received MSRP SEND request to the controlling MCData function according to the rules and procedures of IETF RFC 4975 [11].

Upon receiving an MSRP 200 (OK) response from the controlling MCData function, the participating MCData function shall forward the MSRP 200 (OK) response to the originating MCData client according to the rules and procedures of IETF RFC 4975 [11].

Upon receiving an error MSRP response from the controlling MCData function, the participating MCData function shall forward the error MSRP response to the originating MCData client according to the rules and procedures of IETF RFC 4975 [11].

6.2.1.5 Procedures for the terminating participating MCData function

6.2.1.5.1 Establish MSRP session with the controlling MCData function

The terminating participating MCData function should establish the MSRP session with the controlling MCData function as specified in clause 6.2.1.2.

6.2.1.5.2 Establish MSRP session with the terminating MCData client

The terminating participating MCData function should establish MSRP session to terminating MCData client as specified in clause 6.2.1.3.

6.2.1.5.3 Handling of received MSRP messages

Upon receiving an MSRP SEND request from the controlling MCData function, the terminating participating MCData function:

1. shall generate and send a MSRP 200 (OK) response for the received MSRP SEND request to the controlling MCData function, according to the rules and procedures of IETF RFC 4975 [11]; and

2. shall forward the received MSRP SEND request to the terminating MCData client according to the rules and procedures of IETF RFC 4975 [11].

Upon receiving an error MSRP response from the terminating MCData client, the participating MCData function shall forward the error MSRP response to the originating MCData client according to the rules and procedures of IETF RFC 4975 [11].

6.2.2 Short data during an SDS session

6.2.2.1 General

For a one-to-one or group SDS session, the media plane is established between the originating MCData client and the originating participating MCData function, the originating participating MCData function and the controlling MCData function, the controlling MCData function and the terminating participating MCData function(s) and each terminating participating MCData function and the terminating MCData client(s) as specified in 3GPP TS 24.282 [8]. The procedures in clause 6.2.2.4 and clause 6.2.2.5 are applicable for one-to-one and group SDS session.

6.2.2.2 Establishing MSRP session to receive SDS message

To receive a SDS message over MSRP, the participating MCData function:

1. shall act according to IETF RFC 6135 [12], as:

a. an "passive" endpoint, if a=setup attribute in the sent SDP answer was set to "passive"; and

b. an "active" endpoint, if a=setup attribute in the sent SDP answer was set to "active"; and

2. shall establish an MSRP connection according to the MSRP connection parameters in the sent SDP answer response as described in IETF RFC 4976 [14].

6.2.2.3 Establish MSRP session to send SDS message

To send a SDS message over MSRP, the participating MCData function:

1. shall act according to IETF RFC 6135 [12], as:

a. an "active" endpoint, if a=setup attribute in the received SDP answer is set to "passive"; and

b. an "passive" endpoint, if a=setup attribute in the received SDP answer is set to "active"; and

2. shall establish the MSRP connection according to the MSRP connection parameters in the received SDP answer response as described in IETF RFC 4976 [14].

6.2.2.4 Procedures for the originating participating MCData function

6.2.2.4.1 Establish MSRP session with the originating MCData client

The originating participating MCData function should establish the MSRP session with the originating MCData client as specified in clause 6.2.2.2.

6.2.2.4.2 Establish MSRP session with the controlling MCData function

The originating participating MCData function should establish the MSRP session with the controlling MCData function as specified in clause 6.2.2.3.

6.2.2.4.3 Handling of received MSRP messages

Upon receiving an MSRP SEND request from the originating MCData client, the originating participating MCData function:

1. if an MSRP connection is not established with the controlling MCData function then, shall establish the MSRP connection as specified in clause 6.2.2.4.2. Otherwise, shall use the existing MSRP connection; and

2. shall forward the received MSRP SEND request to the controlling MCData function according to the rules and procedures of IETF RFC 4975 [11].

6.2.2.5 Procedures for the terminating participating MCData function

6.2.2.5.1 Establish MSRP session with the controlling MCData function

The terminating participating MCData function should establish the MSRP session with the controlling MCData function as specified in clause 6.2.2.2.

6.2.2.5.2 Establish MSRP session with the terminating MCData client

The terminating participating MCData function should establish MSRP session to terminating MCData client as specified in clause 6.2.2.3.

6.2.2.5.3 Handling of received MSRP messages

Upon receiving an MSRP SEND request from the controlling MCData function, the terminating participating MCData function:

1. shall generate and send a MSRP 200 (OK) response for the received MSRP SEND request to the controlling MCData function, according to the rules and procedures of IETF RFC 4975 [11]; and

2. shall forward the received MSRP SEND request to the terminating MCData client according to the rules and procedures of IETF RFC 4975 [11].

6.3 Controlling MCData function procedures

6.3.1 Standalone SDS via media plane

6.3.1.1 General

The controlling MCData function plays a key role in anchoring the media between the originating MCData client and the terminating MCData client. Hence controlling MCData function maintains a MSRP session with all the active MCData clients.

The procedures in clause 6.3.1.2 and clause 6.3.1.3 are applicable for both, one-to-one and group standalone SDS using media plane.

6.3.1.2 Establishing MSRP session

6.3.1.2.1 MSRP session establishment with originating MCData client

To establish the MSRP connection with the originating MCData client, the controlling MCData function performs below procedures:

1. shall act as an MSRP client and establish TLS connection with the originating participating MCData function, if exists, otherwise the originating MCData client, according to the rules and procedures as described in IETF RFC 4975 [11];

2. shall act as an MSRP client to send MSRP SEND requests according to the rules and procedures described in IETF RFC 6135 [12];

3. shall act as an "passive" endpoint according to the rules and procedures described in IETF RFC 6135 [12];

4. shall establish the MSRP connection with originating MCData client, according to the rules and procedures described in IETF RFC 6135 [12]; and

5. as a passive endpoint, shall wait for MSRP SEND request on established MSRP connection, to bind the MSRP connection to the MSRP session according to the rules and procedures of IETF RFC 4975 [11] and IETF RFC 6135 [12].

6.3.1.2.2 MSRP session establishment with terminating MCData client

To establish the MSRP connection with the terminating MCData client, the controlling MCData function performs below procedures:

1. shall act as an MSRP client and establish TLS connection with the terminating participating MCData function, if exists, otherwise the terminating MCData client, according to the rules and procedures as described in IETF RFC 4975 [11];

2. shall act as an MSRP client to send MSRP SEND requests according to the rules and procedures described in IETF RFC 6135 [12];

3. shall act according to IETF RFC 6135 [12], as:

a. an "active" endpoint, if a=setup attribute in the received SDP answer is set to "passive"; and

b. an "passive" endpoint, if a=setup attribute in the received SDP answer is set to "active";

4. shall establish the MSRP connection with each terminating MCData client identified in the 3GPP TS 24.282 [8], according to the rules and procedures described in IETF RFC 6135 [12]; and

5. if acting as an "active" endpoint, shall send an empty MSRP SEND request on each established MSRP connection, to bind the MSRP connection to the MSRP session according to the rules and procedures of IETF RFC 4975 [11] and IETF RFC 6135 [12].

6.3.1.3 Handling of received MSRP messages

Upon receiving a MSRP SEND request from the originating participating MCData function, the controlling MCData function:

1. if in a standalone one-to-one SDS using media plane, shall verify the SDS message size is less than or equal to <max-data-size-sds-bytes> element in the MCData service configuration document as specified in 3GPP TS 24.484 [7];

2. if in a standalone group SDS using media plane shall verify:

a. the SDS message size is less than or equal to <mcdata-max-data-in-single-request> element of the MCData group document for the (see the MCData group document in 3GPP TS 24.481 [4]); and

b. the SDS message size is less than or equal to <mcdata-on-network-max-data-size-for-SDS> element of the MCData group document (see the MCData group document in 3GPP TS 24.481 [4]);

3. if the verifications in either 1 or 2 a or 2 b above fails, shall send the MSRP response with the error code 403 to the MCData client which sent the SDS message and shall not continue with the rest of the procedure;

4. shall generate and send a MSRP 200 (OK) response for the received MSRP SEND requests to the originating participating MCData function, according to the rules and procedures of IETF RFC 4975 [11]; and

5. shall forward the received MSRP SEND requests to each terminating MCData client with which a successful MSRP connection was established, according to the rules and procedures of IETF RFC 4975 [11]. Following clarifications apply to the generated MSRP SEND request:

a. shall modify the To-Path header according to the MSRP URI received in the answer SDP from the MCData client in accordance with rules and procedures of IETF RFC 4975 [11]; and

b. shall modify the From-Path header to the controlling MCData function’s own MSRP URI, according to the rules and procedures of IETF RFC 4975 [11].

6.3.2 Short data during SDS session

6.3.2.1 General

6.3.2.2 Establishing MSRP session

6.3.2.2.1 MSRP session establishment with originating MCData client

To establish the MSRP connection with the originating MCData client, the controlling MCData function performs below procedures:

2. shall act as an MSRP client to send MSRP SEND requests according to the rules and procedures described in IETF RFC 6135 [12];

3. shall act as an "passive" endpoint according to the rules and procedures described in IETF RFC 6135 [12];

4. shall establish the MSRP connection with originating MCData client, according to the rules and procedures described in IETF RFC 6135 [12]; and

5. acting as a "passive" endpoint, shall wait for MSRP SEND request on established MSRP connection, to bind the MSRP connection to the MSRP session according to the rules and procedures of IETF RFC 4975 [11] and IETF RFC 6135 [12].

6.3.2.2.2 MSRP session establishment with terminating MCData client

To establish the MSRP connection with the terminating MCData client, the controlling MCData function performs below procedures:

2. shall act as an MSRP client to send MSRP SEND requests according to the rules and procedures described in IETF RFC 6135 [12];

3. shall act according to IETF RFC 6135 [12], as:

a. an "active" endpoint, if a=setup attribute in the received SDP answer is set to "passive"; and

b. an "passive" endpoint, if a=setup attribute in the received SDP answer is set to "active";

4. shall establish the MSRP connection with each terminating MCData client identified in the 3GPP TS 24.282 [8], according to the rules and procedures described in IETF RFC 6135 [12]; and

6.3.2.3 Handling of received MSRP messages

Upon receiving a MSRP SEND request from the originating participating MCData function, the controlling MCData function:

1. shall generate and send a MSRP 200 (OK) response for the received MSRP SEND requests to the originating participating MCData function, according to the rules and procedures of IETF RFC 4975 [11]; and

2. shall forward the received MSRP SEND requests to each terminating MCData client with which a successful MSRP connection was established, according to the rules and procedures of IETF RFC 4975 [11]. Following clarifications apply to the generated MSRP SEND request:

a. shall modify the To-Path header according to the MSRP URI received in the answer SDP from the MCData client in accordance with rules and procedures of IETF RFC 4975 [11]; and

b. shall modify the From-Path header to the controlling MCData function’s own MSRP URI, according to the rules and procedures of IETF RFC 4975 [11].

6.4 General

6.4.1 Handling of MIME bodies in MSRP SEND messages

The MCData client and MCData server shall support several MIME bodies in MSRP SEND requests as specified in IETF RFC 4975 [11].

When the MCData client or the MCData server sends a MSRP SEND that contains more than one MIME body, the MCData client or the MCData server:

1) shall, as specified in IETF RFC 2046 [9], include one Content-Type header field with the value set to multipart/mixed and with a boundary delimiter parameter set to any chosen value;

2) for each MIME body:

a) shall insert the boundary delimiter;

b) shall insert the Content-Type header field with the MIME type of the MIME body; and

c) shall insert the content of the MIME body; and

3) shall insert a final boundary delimiter.

When the MCData client or the MCData server sends an MSRP SEND containing only one MIME body, the MCData client or the MCData server:

1) shall include a Content-Type header field set to the MIME type of the MIME body; and

2) shall insert the content of the MIME body.

6.5 SDS delivery using MBMS

6.5.1 General Description (non-normative)

The procedures for group SDS delivery using MBMS via the media plane can be seen as extensions of the procedures for group SDS session delivery using unicast. The procedures of the originating client, originating participating function and controling function are those used for unicast session delivery for group SDS. Only the terminating participating function and the terminating client are involved in MBMS delivery functionality for group SDS.

The procedures assume that consistent with 3GPP TS 24.282 [8], an SDS session has already been established and the originating and terminating MCData clients have already completed successfully the SDP offer/answer negotiation. It is further assumed that the terminating MCData participating function has already sent an MBMS bearer announcement message providing information about the MBMS bearer and subchannel intended for MBMS delivery and that the terminating MCData client has received and processed the MBMS bearer announcement message, as described in 3GPP TS 24.282 [8].

During the SDS session, the terminating MCData participating function intercepts MSRP SEND messages arriving from the originating side, and, after eliminating duplicates, encapsulates them unchanged as payload in (S)RTP/UDP/IP (see IETF RFC 3711 [17]) packets and transmits them on an MBMS bearer towards the terminating MCData client. Upon reception, the terminating MCData client decapsulates the payload and processes it as an MSRP SEND message within the SDS session, arriving from the originating side.

NOTE 1: Since MSRP chunking is supported for unicast delivery, it is also supported for MBMS delivery.

NOTE 2: If SRTP (see IETF RFC 3711 [17]), rather than RTP, is used to security protect packets sent on MBMS bearer, MuSiK (see 3GPP TS 24.482 [5] and 3GPP TS 33.180 [15]) may be employed to provide protection in addition to the security mechanisms that protect the unicast MSRP traffic.

NOTE 3: Whether unicast or MBMS delivery are used is up to the terminating participating function, which can use listening status reports from the MCData clients, the presence or absence of the DELIVERED disposition in SDS, as well as other information, to decide on an individual MCData client and SDS basis. At any time during a session, the terminating participating server can toggle between unicast and MBMS delivery.

6.5.2 Procedures for the terminating MCData client

6.5.2.1 Handling the MSRP connection

The terminating MCData client shall execute the procedure for MSRP connection establishment described in clause 6.1.2.3.1.

6.5.2.2 Receiving Map Group To Bearer and Unmap Group To Bearer

While MBMS delivery is expected, the terminating MCData client shall monitor the general purpose MBMS subchannel.

When receiving a Map Group To Bearer message over the general purpose MBMS subchannel, the MBMS interface in the MCData client:

1) shall associate the TMGI in the TMGI field, the MBMS subchannel for media with the MCData group identity in the MCData Group ID field; and

2) shall start or continue the procedure described in clause 6.5.2.3.

When receiving the Unmap Group To Bearer message referring to the current communication over a MBMS subchannel, the MBMS interface in the MCData client:

1) shall remove the association between the TMGI, the MBMS subchannel for media in the group session identified by the MCData Group ID field, if such an association exists; and

2) shall cease monitoring the associated MBMS bearer and subchannel for media and, if the SDS session is still ongoing, shall resume or continue SDS delivery via media plane over unicast.

6.5.2.3 Receiving media packets

The terminating MCData client shall:

1. while MBMS delivery is expected, the terminating MCData client shall monitor the MBMS bearer and subchannel indicated by the Map Group To Bearer message; and

2. for each received (S)RTP media packet, until a SIP BYE is received or until an implementation dependent timeout occurs:

a. decapsulate the payload out of the (S)RTP packet and, if SRTP rather than RTP is used (see IETF RFC 3711 [17]), decrypt and validate the payload;

b. if the media packet was received via an MBMS bearer with the TMGI associated to the group, accept the payload as correctly destined for the terminating MCData client, regardless of whether or not the To‑Path header of the MSRP SEND message in the payload matches the terminating MCData client’s MSRP URI (i.e. the MSRP URI provided in the answer SDP to the controlling function during the MSRP session establishment, in accordance with rules and procedures of IETF RFC 4975 [11]); and

c. process the payload as a received MSRP SEND message according to clause 6.1.2.3.1, in the context of the media flow formed by previously received MSRP SEND messages, whether delivered via unicast or via MBMS.

6.5.3 Procedures for the terminating MCData participating function

6.5.3.1 Establishing MSRP session

The terminating MCData participating function:

1. shall establish an MSRP session with the controlling MCData function according to clause 6.2.2.5.1; and

2. shall establish an MSRP session with the terminating MCData client according to clause 6.2.2.5.2.

6.5.3.2 Sending Map Group To Bearer and Unmap Group To Bearer

The terminating MCData participating function:

1. shall build a Map Group To Bearer message (see clause 11.2.4) to include:

a. the TMGI of the MBMS bearer to carry the traffic;

b. the identifier of the media stream; and

c. the MCData Group identifier field; and

2. shall send (repetitively, at short, implementation dependent time intervals) the Map Group To Bearer message over the general purpose MBMS subchannel.

When the session ends, the terminating MCData participating function shall build the corresponding Unmap Group To Bearer message (see clause 11.2.5) and shall send it over the general purpose MBMS subchannel.

6.5.3.3 Receiving media packets intended for a terminating MCData client

When receiving an MSRP SEND message that the terminating participating server considers qualified for MBMS delivery and is destined to one of the MCData clients listening to the MBMS subchannel, the participating MCData function:

NOTE 1: An MSRP SEND message that does not qualify for MBMS delivery or is not destined to an MCData client listening to the MBMS subchannel is handled as an MSRP SEND message to be delivered over unicast (see clause 6.2.1.5.3).

1. shall generate and send an MSRP 200 (OK) response for the received MSRP SEND message to the controlling MCData function, according to the rules and procedures of IETF RFC 4975 [11];

2. shall check if the media packet that encapsulates the MSRP SEND message is already sent over the MBMS subchannel or not;

3. if the media packet is already sent over the MBMS subchannel, shall discard the MSRP SEND message; and

4. otherwise:

a. shall build an (S)RTP/UDP/IP (see IETF RFC 3711 [17]) media packet with the IP address and UDP port number indicated in the sent Map Group To Bearer message and with the received MSRP SEND message as payload, security protected if SRTP is used, per IETF RFC 3711 [17] and 3GPP TS 33.180 [15]; and

b. shall transmit the built (S)RTP/UDP/IP packet on the MBMS bearer identified by the TMGI indicated in the sent Map Group To Bearer message.

NOTE 2: To save over-the air resources, the terminating MCData participating function releases or reduces the bandwidth of the unicast downlink bearers used for unicast SDS delivery. However, to enable the ability of rapid switching between unicast and MBMS delivery, the terminating MCData participating function can keep the unicast bearers intact.

Upon receiving error MSRP responses (see IETF RFC 4975 [11]) from the terminating MCData client, the terminating MCData participating function shall forward the error MSRP responses towards the originating MCData client.