6.1.7 On-network / Short Data Service (SDS) / Standalone SDS Using Media Plane / Group Standalone SDS / Client Originated (CO)

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

6.1.7.1 Test Purpose (TP)

(1)

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

ensure that {

when { the MCDATA User requests to send a group standalone SDS message using the media plane}

then { UE (MCDATA Client) sends a request to establish an MSRP connection via a SIP INVITE message and then responds to the SIP 200 (OK) message with a SIP ACK message }

}

(2)

with { UE (MCDATA Client) having requested the establishment of a MSRP connection }

ensure that {

when { UE (MCDATA Client) receives a SIP 200 (OK) message with the a=setup attribute set to "passive" }

then { UE (MCDATA Client) sends a blank MSRP SEND message to bind the MSRP connection and then sends the group standalone SDS message via a MSRP SEND message with a disposition of "DELIVERY" }

}

(3)

with { UE (MCDATA Client) having sent a group standalone SDS message using the media plane }

ensure that {

when { UE (MCDATA Client) receives a MSRP 200 (OK) message in response to the last MSRP SEND message indicating that the standalone SDS message has been successfully transferred }

then { UE (MCDATA Client) sends a SIP BYE message }

}

(4)

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

ensure that {

when { UE (MCDATA Client) receives a disposition response via a SIP MESSAGE message }

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

}

6.1.7.2 Conformance requirements

References: The conformance requirements covered in the current TC are specified in: TS 24.282, clauses 9.2.3.2.3, 9.2.3.2.1, 13.2.2.2.2.1, 12.2.1.2, TS 24.582 clauses 6.1.1.2.1, 6.1.1.2.2, 6.1.1.2.3, 6.1.1.2.4. 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.3.2.3]

The MCData client shall generate a SIP INVITE request in accordance with 3GPP TS 24.229 [5] with the clarifications given below.

The MCData client:

1) shall include the g.3gpp.mcdata.sds media feature tag and the g.3gpp.icsi-ref media feature tag with the value of "urn:urn-7:3gpp-service.ims.icsi.mcdata.sds" in the Contact header field of the SIP INVITE request according to IETF RFC 3840 [16];

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

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

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

5) should include the "timer" option tag in the Supported header field;

6) should include the Session-Expires header field according to IETF RFC 4028 [38]. It is recommended that the "refresher" header field parameter is omitted. If included, the "refresher" header field parameter shall be set to "uac";

7) if a one-to-one standalone SDS message is to be sent:

a) shall insert in the SIP INVITE request a MIME resource-lists body with the MCData ID of the invited MCData user, according to rules and procedures of IETF RFC 5366 [18];

b) shall contain an application/vnd.3gpp.mcdata-info+xml MIME body with the <mcdatainfo> element containing the <mcdata-Params> element with:

i) the <request-type> element set to a value of "one-to-one-sds"; and

c) if an end-to-end security context needs to be established and the security context does not exist or if the existing security context has expired, then:

i) if necessary, shall instruct the key management client to request keying material from the key management server as described in 3GPP TS 33.180 [26];

ii) shall use the keying material to generate a PCK as described in 3GPP TS 33.180 [26];

iii) shall use the PCK to generate a PCK-ID with the four most significant bits set to "0001" to indicate that the purpose of the PCK is to protect one-to-one communications and with the remaining twenty eight bits being randomly generated as described in 3GPP TS 33.180 [26];

iv) shall encrypt the PCK to a UID associated to the MCData client using the MCData ID of the invited user and a time related parameter as described in 3GPP TS 33.180 [26];

v) shall generate a MIKEY-SAKKE I_MESSAGE using the encapsulated PCK and PCK-ID as specified in 3GPP TS 33.180 [26];

vi) shall add the MCData ID of the originating MCData to the initiator field (IDRi) of the I_MESSAGE as described in 3GPP TS 33.180 [26]; and

vii) shall sign the MIKEY-SAKKE I_MESSAGE using the originating MCData user’s signing key provided in the keying material together with a time related parameter, and add this to the MIKEY-SAKKE payload, as described in 3GPP TS 33.180 [26];

9) shall set the Request-URI of the SIP INVITE request to the public service identity identifying the participating MCData function serving the MCData user;

NOTE 2: The MCData client is configured with public service identity identifying the participating MCData function serving the MCData user.

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

11) shall include an SDP offer according to 3GPP TS 24.229 [5] with the clarifications given in subclause 9.2.3.2.1; and

12) shall send the SIP INVITE request towards the MCData server according to 3GPP TS 24.229 [5].

On receipt of a SIP 2xx response to the SIP INVITE request, the MCData client:

1) shall send a SIP ACK request as specified in 3GPP TS 24.229 [5];

2) shall start the SIP Session timer according to rules and procedures of IETF RFC 4028 [38]; and

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

On receipt of an indication from the media plane indicating that the standalone SDS message has been successfully transferred, the MCData client shall:

1) shall generate a SIP BYE request according to 3GPP TS 24.229 [5] with:

a) Reason code set to "SIP";

b) cause set to "200"; and

c) text set to "transmission succeeded";

2) shall set the Request-URI to the MCData session identity to release; and

3) shall send a SIP BYE request towards MCData server according to 3GPP TS 24.229 [5].

Upon receiving a SIP 200 (OK) response to the SIP BYE request, the MCData client shall interact with the media plane and indicate to terminate the session, as specified in 3GPP TS 24.582 [15].

[TS 24.282, clause 9.2.3.2.1]

When composing an SDP offer according to 3GPP TS 24.229 [5], IETF RFC 4975 [17], IETF RFC 6135 [19] and IETF RFC 6714 [20] the MCData client:

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

a) the IP address and the port number;

b) a protocol field value of "TCP/MSRP", or "TCP/TLS/MSRP" for TLS;

c) a format list field set to ‘*’;

d) an "a=sendonly" attribute;

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

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

g) set the a=setup attribute as "actpass"; and

2) if end-to-end security is required for a one-to-one communication and the security context does not exist or if the existing security context has expired, shall include the MIKEY-SAKKE I_MESSAGE in an "a=key-mgmt" attribute as a "mikey" attribute value in the SDP offer as specified in IETF RFC 4567 [45].

[TS 24.282, clause 13.2.2.2.2.1]

When the MCData client wants to release a MCData communication established over the media plane, the MCData client:

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

2) shall set the Request-URI to the MCData session identity to be released; and

3) shall send the SIP BYE request towards MCData server according to 3GPP TS 24.229 [5].

Upon receiving a SIP 200 (OK) response to the SIP BYE request, the MCData client shall release all media plane resources corresponding to the MCData communication being released.

[TS 24.282, clause 12.2.1.2]

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.

[TS 24.582, clause 6.1.1.2.1]

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

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.

[TS 24.582, clause 6.1.1.2.2]

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

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

[TS 24.582, clause 6.1.1.2.3]

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

[TS 24.582, clause 6.1.1.2.4]

The MCData client shall take the procedures in subclause 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 set the first content type as Content-Type = "application/vnd.3gpp.mcdata-signalling";

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

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

5. shall set the second 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 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.7.3 Test description

6.1.7.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 <max-payload-size-sds-cplane-bytes> element of the MCData Service Configuration document shall be set to 0 to force the MCData Client to send the data using the media plane.

– 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.7.3.2 Test procedure sequence

Table 6.1.7.3.2-1: Main Behaviour

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

1

Make the MCData User request to send a group standalone SDS message with disposition request "DELIVERY".

(NOTE 1)

2

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

1,2

P

3-6

Void

7

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"?

2

P

8

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

3

P

9

Void

10

Check: Does the UE (MCData Client) perform the procedure for MCX SIP MESSAGE CT specified in TS 36.579-1 [2] Table 5.3.33.3-1 to receive the disposition notification for the SDS message sent at step 7?

11

Void

12

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

(NOTE 1)

4

P

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

6.1.7.3.3 Specific message contents

Table 6.1.7.3.3-1: SIP INVITE (step 2, Table 6.1.7.3.2-1;
step 2, TS 36.579-1 [2] Table 5.3C.2.3-1)

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

Information Element

Value/remark

Comment

Reference

Condition

Message-body

MIME body part

SDP message

MIME-part-body

As described in Table 6.1.7.3.3-1A

MIME body part

MCData-Info

MIME-part-body

MCData-Info as described in Table 6.1.7.3.3-2

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

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

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

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

Table 6.1.7.3.3-3: SIP 200 (OK) (step 2, Table 6.1.7.3.2-1;
step 4, TS 36.579-1 [2] Table 5.3C.2.3-1)

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

Information Element

Value/remark

Comment

Reference

Condition

Message-body

SDP message

As described in Table 6.1.7.3.3-4

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

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

Table 6.1.7.3.3-5: MSRP SEND (step 7, Table 6.1.7.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.7.3.3-5A

Table 6.1.7.3.3-5A: MIME Message (step 7, Table 6.1.7.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.7.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.7.3.3-6

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

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

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

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

Table 6.1.7.3.3-7..8: Void

Table 6.1.7.3.3-9: SIP BYE (step 8, Table 6.1.7.3.2-1;
step 1, TS 36.579-1 [2] Table 5.3C.6.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.2.1-1, condition MO_CALL

Information Element

Value/remark

Comment

Reference

Condition

Reason

RFC 3326 [125]

reason-value

"SIP"

protocol-cause

"cause="200""

reason-text

"text="transmission succeeded""

Table 6.1.7.3.3-10: Void

Table 6.1.7.3.3-11: SIP MESSAGE (step 10, Table 6.1.7.3.2-1;
step 2, TS 36.579-1 [2] Table 5.3.33.3-1)

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

Information Element

Value/remark

Comment

Reference

Condition

Message-body

MIME body part

MCData-Info

MIME-part-body

As described in Table 6.1.7.3.3-12

MIME body part

MCData Data signalling message

MIME-part-body

MCData Protected Payload Message containing SDS NOTIFICATION as described in Table 6.1.7.3.3-13

Table 6.1.7.3.3-12: MCDATA-Info (Table 6.1.7.3.3-11)

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

Information Element

Value/remark

Comment

Reference

Condition

mcdata-info

mcdata-Params

mcdata-calling-group-id

Encrypted <mcdata-calling-group-id> with mcdataURI set to px_MCData_Group_A_ID

Encrypted according to TS 36.579-1 [2] Table 5.5.3.2.2-3A

Table 6.1.7.3.3-13: SDS NOTIFICATION (Table 6.1.7.3.3-11)

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

Table 6.1.7.3.3-14: Void