6.1.12 On-network / Short Data Service (SDS) / SDS Session / Group SDS Session / Client Terminated (CT)

36.579-73GPPMission Critical (MC) services over LTEPart 7: Mission Critical Data (MCData) User Equipment (UE) Protocol conformance specificationRelease 15TS

6.1.12.1 Test Purpose (TP)

(1)

with { UE (MCDATA Client) registered and authorised for MCDATA Service }

ensure that {

when { the MCDATA User receives a SIP INVITE to initiate a group SDS session using the media plane }

then { UE (MCDATA Client) responds by sending a SIP 200 (OK) message }

}

(2)

with { UE (MCDATA Client) having responded to the SIP INVITE message that initiated a group SDS session using the media plane }

ensure that {

when { UE (MCDATA Client) receives an MSRP SEND message }

then { UE (MCDATA Client) responds with a MSRP 200 (OK) message and if the MSRP SEND message is not blank, renders the contents of the Payload IE to the MCDATA User and sends a MSRP SEND message with a disposition notification of "DELIVERED" }

}

(3)

with { UE (MCDATA Client) being in a group SDS session initiated by the SS (MCDATA server) }

ensure that {

when { the MCDATA User requests to send a group SDS Session message with a disposition of "DELIVERY AND READ" }

then { UE (MCDATA Client) sends a group session SDS message via a MSRP SEND message with a disposition of "DELIVERY AND READ" }

}

(4)

with { UE (MCDATA Client) having sent a group SDS session message using the media plane with a disposition of "DELIVERY AND READ" }

ensure that {

when { UE (MCDATA Client) receives a disposition response via a MSRP SEND message }

then { UE (MCDATA Client) responds to the MSRP SEND message by sending a MSRP 200 (OK) message and delivers the notification to the MCDATA User }

}

(5)

with { UE (MCDATA Client) being in a group SDS session initiated by the SS (MCDATA Server) }

ensure that {

when { UE (MCDATA Client) receives a SIP BYE message }

then { UE (MCDATA Client) responds by sending a SIP 200 (OK) message }

}

6.1.12.2 Conformance requirements

References: The conformance requirements covered in the current TC are specified in: TS 24.282, clauses 9.2.4.2.4, 9.2.4.2.2, 13.2.2.2.2.2, TS 24.582 clauses 6.1.2.3.1, 6.1.2.3.1, 6.1.2.4, 6.1.2.5.1, 6.1.2.5.2, 6.1.2.5.3, 6.1.2.6. The following represents a copy/paste extraction of the requirements relevant to the test purpose; any references within the copy/paste text should be understood within the scope of the core spec they have been copied from. Unless otherwise stated, these are Rel-14 requirements.

[TS 24.282, clause 9.2.4.2.4]

Upon receipt of an initial SIP INVITE request, the MCData client shall follow the procedures for termination of multimedia sessions in the IM CN subsystem as specified in 3GPP TS 24.229 [5] with the clarifications below.

The MCData client:

1) may reject the SIP INVITE request if either of the following conditions are met:

a) MCData client does not have enough resources to handle the call; or

b) any other reason outside the scope of this specification;

and skip the rest of the steps after step 2;

2) if the SIP INVITE request is rejected in step 1), shall respond toward participating MCData function either with appropriate reject code as specified in 3GPP TS 24.229 [5] and warning texts as specified in subclause 4.9 or with SIP 480 (Temporarily unavailable) response not including warning texts if the user is authorised to restrict the reason for failure and skip the rest of the steps of this subclause;

3) if the SDP offer of the SIP INVITE request contains an "a=key-mgmt" attribute field with a "mikey" attribute value containing a MIKEY-SAKKE I_MESSAGE:

a) shall extract the MCData ID of the originating MCData user from the initiator field (IDRi) of the I_MESSAGE as described in 3GPP TS 33.180 [26];

b) shall convert the MCData ID to a UID as described in 3GPP TS 33.180 [26];

c) shall use the UID to validate the signature of the MIKEY-SAKKE I_MESSAGE as described in 3GPP TS 33.180 [26];

d) if authentication verification of the MIKEY-SAKKE I_MESSAGE fails, shall reject the SIP INVITE request with a SIP 488 (Not Acceptable Here) response as specified in IETF RFC 4567 [45], and include warning text set to "136 authentication of the MIKEY-SAKKE I_MESSAGE failed" in a Warning header field as specified in subclause 4.9 and not continue with rest of the steps in this subclause; and

e) if the signature of the MIKEY-SAKKE I_MESSAGE was successfully validated:

i) shall extract and decrypt the encapsulated PCK using the terminating user’s (KMS provisioned) UID key as described in 3GPP TS 33.180 [26]; and

ii) shall extract the PCK-ID, from the payload as specified in 3GPP TS 33.180 [26];

NOTE: With the PCK successfully shared between the originating MCData client and the terminating MCData client, both clients are able to create an end-to-end secure session.

4) may display to the MCData user the MCData ID of the inviting MCData user and the type of SDS request;

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

6) shall include the option tag "timer" in a Require header field of the SIP 200 (OK) response;

7) shall include the Session-Expires header field in the SIP 200 (OK) response and start the SIP session timer according to IETF RFC 4028 [38]. The "refresher" parameter in the Session-Expires header field shall be set to "uas";

8) shall include the g.3gpp.mcdata.sds media feature tag in the Contact header field of the SIP 200 (OK) response;

9) shall include the g.3gpp.icsi-ref media feature tag containing the value of "urn:urn-7:3gpp-service.ims.icsi.mcdata.sds" in the Contact header field of the SIP 200 (OK) response;

10) shall include an SDP answer in the SIP 200 (OK) response to the SDP offer in the incoming SIP INVITE request according to 3GPP TS 24.229 [5] with the clarifications given in subclause 9.2.4.2.2; and

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

On receipt of an SIP ACK message to the sent SIP 200 (OK) message, the MCData client shall:

1) shall interact with the media plane as specified in 3GPP TS 24.582 [15] subclause 6.1.2.3.

To send a disposition notification after the media plane is released, the MCData client:

1) shall follow the procedures described in subclause 12.2.1.1.

[TS 24.282, clause 9.2.4.2.2]

When the MCData client receives an initial SDP offer for an MCData SDS session, the MCData client shall process the SDP offer and shall compose an SDP answer according to 3GPP TS 24.229 [5] and IETF RFC 4975 [17].

When composing an SDP answer, the MCData client:

1) shall include an "m=message" media-level section for the accepted MCData media stream consisting of:

a) the port number;

b) a protocol field value of "TCP/MSRP" or "TCP/TLS/MSRP" for TLS according to the received SDP offer;

c) an "a=sendrecv" attribute;

d) an "a=path" attribute containing its own MSRP URI;

e) set the content type as a=accept-types: application/vnd.3gpp.mcdata-signalling application/vnd.3gpp.mcdata-payload; and

f) set the a=setup attribute according to IETF RFC 6135 [19].

[TS 24.282, clause 13.2.2.2.2.2]

Upon receiving a SIP BYE request, the MCData client:

1) shall send SIP 200 (OK) response towards MCData server according to 3GPP TS 24.229 [5]; and

2) shall release all media plane resources corresponding to the MCData communication being released.

NOTE: Partially received data can be stored and processed.

[TS 24.582, clause 6.1.2.3.1]

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

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

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 subclause 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 subclause 6.1.2.4, or can generate and send an SDS disposition notification for a received SDS message as specified in subclause 6.1.2.5, if requested.

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

[TS 24.582, clause 6.1.2.4]

An MCData client is allowed to send an 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 [11].

If the above mentioned conditions satisfy, the MCData client:

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

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

3. shall include the SDS SIGNALLING PAYLOAD and SDS DATA PAYLOAD in an MSRP SEND request as specified in subclause 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.

NOTE: MSRP chunking, if needed, may affect the number of "Content Type" lines in each MSRP SEND message conveying a chunk, as also specified in subclause 6.1.1.2.4.

[TS 24.582, clause 6.1.2.5.1]

To send an SDS disposition notification, the MCData client:

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

2. shall include the SDS NOTIFICATION in an MSRP SEND request as specified in subclause 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.

[TS 24.582, clause 6.1.2.5.2]

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; and

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.

[TS 24.582, clause 6.1.2.5.3]

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.

[TS 24.582, clause 6.1.2.6]

Upon receiving an SDS message, the MCData client:

1. shall follow the procedure defined in subclause 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 subclause 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.1.12.3 Test description

6.1.12.3.1 Pre-test conditions

System Simulator:

– SS (MCDATA Server)

– For the underlying "transport bearer" over which the SS and the UE will communicate Parameters are set to the default parameters for the basic E-UTRA Single cell network scenarios, as defined in TS 36.508 [24] clause 4.4. The simulated Cell 1 shall belong to PLMN1 (the PLMN specified for MCDATA operation in the MCDATA configuration document).

IUT:

– UE (MCDATA Client)

– The test USIM set as defined in TS 36.579-1 [2], subclause 5.5.10 is inserted.

Preamble:

– The UE has performed the Generic Test Procedure for MCDATA UE registration as specified in TS 36.579-1 [2], subclause 5.4.2B.

– The MCDATA User performs the Generic Test Procedure for MCDATA Authorization/Configuration and Key Generation as specified in TS 36.579-1 [2], subclause 5.3.2B.

– UE States at the end of the preamble

– The UE is in E-UTRA Registered, Idle Mode state.

– The MCDATA Client Application has been activated and User has registered-in as the MCDATA User with the Server as active user at the Client.

6.1.12.3.2 Test procedure sequence

Table 6.1.12.3.2-1: Main Behaviour

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

1

Check: Does the UE (MCData Client) perform the procedure for CT MCData Call Establishment specified in TS 36.579-1 [2] Table 5.3C.3.3-1?

1,2

P

2-5

Void

6

Check: Does the UE (MCData Client) perform the procedure for CT MSRP message transfer specified in TS 36.579-1 [2] Table 5.3C.5.3-1 to receive an SDS message with disposition notification type "DELIVERY"?

2

P

7

Void

8

Check: Does the UE (MCData Client) perform the procedure for CO MSRP message transfer specified in TS 36.579-1 [2] Table 5.3C.4.3-1 to send a disposition notification of "DELIVERY"?

2

P

9

Void

10

Check: Does the UE (MCDATA Client) render the contents of the Payload IE to the MCDATA User?

(NOTE 1)

2

P

11

Make the MCDATA User request to send a group session SDS message over the media plane with a disposition notification type of "DELIVERY AND READ".

(NOTE 1)

12

Check: Does the UE (MCData Client) perform the procedure for CO MSRP message transfer specified in TS 36.579-1 [2] Table 5.3C.4.3-1 to send an SDS message with disposition notification type "DELIVERY AND READ"?

3

P

13

Check: Does the UE (MCData Client) perform the procedure for CT MSRP message transfer specified in TS 36.579-1 [2] Table 5.3C.5.3-1 to receive the disposition notification for the SDS message sent at step 12?

4

P

14

Void

15

Check: Does the UE (MCDATA Client) deliver the notification to the MCData User?

(NOTE 1)

4

P

16

Check: Does the UE (MCData Client) perform the procedure for CT MCData call release specified in TS 36.579-1 [2] Table 5.3C.7.3-1?

5

P

17

The SS releases the RRC connection

NOTE 1: This is expected to be done via a suitable implementation dependent MMI.

6.1.12.3.3 Specific message contents

Table 6.1.12.3.3-1: SIP INVITE (step 1, Table 6.1.12.3.2-1;
step 2, TS 36.579-1 [2] Table 5.3C.3.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.5.2-1, condition MCDATA_SDS

Information Element

Value/remark

Comment

Reference

Condition

Message-body

MIME body part

SDP message

MIME-part-body

SDP message as described in Table 6.1.12.3.3-1A

MIME body part

MCData-Info

MIME-part-body

MCData-Info as described in Table 6.1.12.3.3-2

Table 6.1.12.3.3-1A: SDP for SIP INVITE (Table 6.1.12.3.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.3.1.2-3, condition MCDATA_SDS, SDP_OFFER, SDS_SESSION

Table 6.1.12.3.3-2: MCDATA-Info (Table 6.1.12.3.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.3.2.1-3, condition MCD_grp

Information Element

Value/remark

Comment

Reference

Condition

mcdata-info

mcdata-Params

request-type

"group-sds-session"

Table 6.1.12.3.3-3: SIP 200 (OK) (step 1, Table 6.1.12.3.2-1;
step 4, TS 36.579-1 [2] Table 5.3C.3.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.17.1.1-1, condition INVITE-RSP, MCDATA_SDS

Information Element

Value/remark

Comment

Reference

Condition

Content-Type

value

"application/sdp"

Message-body

SDP message

As described in Table 6.1.12.3.3-4

Table 6.1.12.3.3-4: SDP for SIP 200 (OK) (Table 6.1.12.3.3-3)

Derivation Path: TS 36.579-1 [2], Table 5.5.3.1.1-3, condition MCDATA_SDS, SDP_ANSWER, SDS_SESSION

Table 6.1.12.3.3-5: MSRP SEND (step 6, Table 6.1.12.3.2-1;
step 1. TS 36.579-1 [2] Table 5.3C.5.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.12.1.2-1

Information Element

Value/remark

Comment

Reference

Condition

Content-Type

media-type

"multipart/mixed"

data

Message as specified in table 6.1.12.3.3-5A

Table 6.1.12.3.3-5A: MIME Message (step 6, Table 6.1.12.3.2-1;
step 1, TS 36.579-1 [2] Table 5.3C.5.3-1)

Derivation Path: RFC 2046 [38]

Information Element

Value/remark

Comment

Reference

Condition

MIME body part

MCData Data signalling message

MIME-part-headers

Content-Type

"application/vnd.3gpp.mcdata-signalling"

MIME-part-body

MCData Protected Payload Message containing SDS SIGNALLING PAYLOAD as described in table 6.1.12.3.3-5B

MIME body part

MCData Data message

MIME-part-headers

Content-Type

"application/vnd.3gpp.mcdata-payload"

MIME-part-body

MCData Protected Payload Message containing DATA PAYLOAD as described in Table 6.1.12.3.3-6

Table 6.1.12.3.3-5B: SDS SIGNALLING PAYLOAD (Table 6.1.12.3.3-5A)

Derivation Path: TS 36.579-1 [2], Table 5.5.3.8.1-1, condition DELIVERED

Table 6.1.12.3.3-6: Data Payload (Table 6.1.12.3.3-5A)

Derivation Path: TS 36.579-1 [2], Table 5.5.3.9.1-2

Table 6.1.12.3.3-7: MSRP SEND (step 8, Table 6.1.12.3.2-1;
step 3, TS 36.579-1 [2] Table 5.3C.4.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.12.1-1

Information Element

Value/remark

Comment

Reference

Condition

Content-Type

media-type

"application/vnd.3gpp.mcdata-signalling"

data

MCData Protected Payload Message containing SDS NOTIFICATION as specified in table 6.1.12.3.3-8

Table 6.1.12.3.3-8: SDS NOTIFICATION (Table 6.1.12.3.3-7)

Derivation Path: TS 36.579-1 [2], Table 5.5.3.8.3-1, condition DELIVERED

Table 6.1.12.3.3-9: MSRP SEND (step 12, Table 6.1.12.3.2-1;
step 1. TS 36.579-1 [2] Table 5.3C.4.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.12.1-1

Information Element

Value/remark

Comment

Reference

Condition

Content-Type

media-type

"multipart/mixed"

data

Message or chunk of message as specified in table 6.1.12.3.3-9A

Table 6.1.12.3.3-9A: MIME Message (step 12, Table 6.1.12.3.2-1;
step 3, TS 36.579-1 [2] Table 5.3C.4.3-1)

Derivation Path: RFC 2046 [38]

Information Element

Value/remark

Comment

Reference

Condition

MIME body part

MCData Data signalling message

MIME-part-headers

Content-Type

"application/vnd.3gpp.mcdata-signalling"

MIME-part-body

MCData Protected Payload Message containing SDS SIGNALLING PAYLOAD as described in table 6.1.12.3.3-10

MIME body part

MCData Data message

MIME-part-headers

Content-Type

"application/vnd.3gpp.mcdata-payload"

MIME-part-body

MCData Protected Payload Message containing DATA PAYLOAD as described in Table 6.1.12.3.3-11

Table 6.1.12.3.3-10: SDS SIGNALLING PAYLOAD (Table 6.1.12.3.3-9A)

Derivation Path: TS 36.579-1 [2], Table 5.5.3.8.1-1, condition DELIVERED_READ

Table 6.1.12.3.3-11: Data Payload (Table 6.1.12.3.3-9A)

Derivation Path: TS 36.579-1 [2], Table 5.5.3.9.1-1

Table 6.1.12.3.3-12..13: Void

Table 6.1.12.3.3-14: MSRP SEND (step 13, Table 6.1.12.3.2-1;
step 1. TS 36.579-1 [2] Table 5.3C.5.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.12.1.2-1

Information Element

Value/remark

Comment

Reference

Condition

Content-Type

media-type

"application/vnd.3gpp.mcdata-signalling"

data

MCData Protected Payload Message containing SDS NOTIFICATION as specified in table 6.1.12.3.3-15

Table 6.1.12.3.3-15: SDS NOTIFICATION (Table 6.1.12.3.3-14)

Derivation Path: TS 36.579-1 [2], Table 5.5.3.8.4-1, condition DELIVERED_READ

Table 6.1.12.3.3-16: SIP BYE (step 16, Table 6.1.12.3.2-1;
step 1, TS 36.579-1 [2] Table 5.3C.7.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.2.2-1, condition MT_CALL

Table 6.1.12.3.3-17: Void