6.2.9 On-network / File Distribution (FD) / FD Using Media Plane / One-to-one Standalone FD / Client Originated (CO)

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

6.2.9.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 one-to-one standalone FD 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" from the SS (MCDATA server) }

then { UE (MCDATA Client) sends a blank MSRP SEND message to bind the MSRP connection and then sends the one-to-one standalone FD message via a MSRP SEND message }

}

(3)

with { UE (MCDATA Client) having sent a one-to-one standalone FD 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 FD message has been successfully transferred }

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

}

(4)

with { UE (MCDATA Client) having sent a one-to-one standalone FD message using the media plane with a disposition of "FILE DOWNLOAD COMPLETED UPDATE" }

ensure that {

when { UE (MCDATA Client receives a disposition response via a SIP MESSAGE message from the SS (MCDATA Server }

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.2.9.2 Conformance requirements

References: The conformance requirements covered in the current TC are specified in: TS 24.282, clauses 10.2.5.2.3, 6.2.2.3, 12.2.1.2, TS 24.582 clause 7.1.2.1. 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 10.2.5.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.fd media feature tag and the g.3gpp.icsi-ref media feature tag with the value of "urn:urn-7:3gpp-service.ims.icsi.mcdata.fd" 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.fd 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.fd" 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.fd" (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) shall generate and contain an application/vnd.3gpp.mcdata-signalling MIME body with the FD SIGNALLING PAYLOAD as described in subclause 6.2.2.3;

8) if a one-to-one file distribution is requested:

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

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-fd";

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

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) if a group file distribution is requested:

a) if the "/<x>/<x>/Common/MCData/AllowedFD" leaf node present in the group document of the requested MCData group, configured on the group management client as specified in 3GPP TS 24.483 [42] is set to "false", shall reject the request for FD and not continue with the rest of the steps in this subclause; and

b) shall contain in 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 "group-fd";

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

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

NOTE 1: The MCData client does not include the MCData ID of the originating MCData user in the body, as this will be inserted into the body of the SIP INVITE request that is sent from the originating participating MCData function.

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

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

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

13) 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 10.2.5.1.1..

[TS 24.282, clause 6.2.2.3]

In order to generate an FD message, the MCData client:

1) shall generate an FD SIGNALLING PAYLOAD message as specified in subclause 15.1.3; and

2) shall include in the SIP request, the FD SIGNALLING PAYLOAD message in an application/vnd.3gpp.mcdata-signalling MIME body as specified in subclause E.1.

When generating an FD SIGNALLING PAYLOAD message as specified in subclause 15.1.3, the MCData client:

1) shall set the Date and time IE to the current time as specified in subclause 15.2.8;

2) if the filestarts a new conversation, shall set the Conversation ID IE to a newly generated Conversation ID value as specified in subclause 15.2.9;

3) if the file continues an existing conversation, shall set the Conversation ID IE to the Conversation ID value of the existing conversation as specified in subclause 15.2.9;

4) shall set the Message ID IE to a newly generated Message ID value as specified in subclause 15.2.10;

5) if the files in reply to a previously received SDS message or file, shall include the InReplyTo message ID IE with the Message ID value in the previously received SDS message or file;

6) if the file is for user consumption, shall not include an Application ID IE as specified in subclause 15.2.7;

7) if the file is intended for an application on the terminating MCData client, shall include an Application ID IE with an Application ID value representing the intended application as specified in subclause 15.2.7;

NOTE: The value chosen for the Application ID value is decided by the mission critical organisation.

8) if a file download complete notification is required shall include a FD disposition request type IE set to "FILE DOWNLOAD COMPLETED UPDATE" as specified in subclause 15.2.4; and

9) shall include and set the Mandatory download IE to "MANDATORY DOWNLOAD" as described in subclause 15.2.16.

[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 7.1.2.1]

Upon receiving an indication to establish MSRP connection for file distribution 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 can send the file. To send the file, the MCData client:

1. shall generate MSRP SEND for file distribution request according to IETF RFC 4975 [11]. When generating an MSRP SEND, the MCData client:

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

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

c. shall set the body of the MSRP SEND request with MSRP payload. MSRP payload is set to the file or part of the file.

2. shall send the MSRP SEND request(s) on the established MSRP connection.

If MSRP chunking is used, the MCData client:

1. shall send further MSRP SEND requests containing the file 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 file could not be distributed; and

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

6.2.9.3 Test description

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

– Test File 1 for CO FD as specified in annex A.2.1 is available at the UE for upload.

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

Table 6.2.9.3.2-1: Main Behaviour

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

1

Make the MCDATA User request to send test file 1 for CO one-to-one FD over media plane with disposition notification type "FILE DOWNLOAD COMPLETED UPDATE".

(NOTE 1, NOTE 2)

–

–

–

–

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 FD message containing test file 1 for CO FD?

–

–

2

P

7A

Check: Is the content of the transferred file the same as specified in annex A.2.1?

–

–

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 FD message sent at step 7?

–

–

4

P

11

Void

–

–

–

–

12

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

(NOTE 1)

–

–

4

P

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

NOTE 2: Test file 1 for CO FD as specified in annex A.2.1.

6.2.9.3.3 Specific message contents

Table 6.2.9.3.3-1: SIP INVITE (step 2, Table 6.2.9.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_FD, MCD_1to1

Information Element

Value/remark

Comment

Reference

Condition

Message-body

MIME body part

SDP message

MIME-part-body

SDP message as described in Table 6.2.9.3.3-2

MIME body part

MCData-Info

MIME-part-body

MCData-Info described in Table 6.2.9.3.3-3

MIME body part

MCData Data signalling message

MIME-part-headers

MIME-Content-Type

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

MIME-part-body

MCData Protected Payload Message containing FD SIGNALLING PAYLOAD as described in Table 6.2.9.3.3-3A

Table 6.2.9.3.3-2: SDP for SIP INVITE (Table 6.2.9.3.3-1)

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

Table 6.2.9.3.3-3: MCDATA-Info (Table 6.2.9.3.3-1)

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

Information Element

Value/remark

Comment

Reference

Condition

mcdata-info

mcdata-Params

request-type

"one-to-one-fd"

Table 6.2.9.3.3-3A: FD SIGNALLING PAYLOAD (Table 6.2.9.3.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.3.8.5-1, condition FD_MSRP

Table 6.2.9.3.3-4: SIP 200 (OK) (step 2, Table 6.2.9.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.2.9.3.3-5

Table 6.2.9.3.3-5: SDP for SIP 200 (OK) (Table 6.2.9.3.3-4)

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

Table 6.2.9.3.3-6: MSRP SEND (step 7, Table 6.2.9.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

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

data

As specified in table 6.2.9.3.3-8

Table 6.2.9.3.3-7: Void

Table 6.2.9.3.3-8: MCData Protected Payload Message (Table 6.2.9.3.3-6)

Derivation Path: TS 36.579-1 [2], Table 5.5.3.10-1, condition PROTECTED_FILE, PCK

Table 6.2.9.3.3-9..10: Void

Table 6.2.9.3.3-11: SIP BYE (step 8, Table 6.2.9.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.2.9.3.3-12: Void

Table 6.2.9.3.3-13: SIP MESSAGE (step 10, Table 6.2.9.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_FD, MCDATA_SIGNALLING

Information Element

Value/remark

Comment

Reference

Condition

Message-body

MIME body part

MCData Data signalling message

MIME-part-body

MCData Protected Payload Message containing FD NOTIFICATION as described in Table 6.2.9.3.3-15

Table 6.2.9.3.3-14: Void

Table 6.2.9.3.3-15: FD NOTIFICATION (Table 6.2.9.3.3-13)

Derivation Path: TS 36.579-1 [2], Table 5.5.3.8.8-1, condition FD_COMPLETED

Table 6.2.9.3.3-16: Void