6.2.13 On-network / File Distribution (FD) / Accessing list of deferred data group communications / 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.13.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 FD message with a non-mandatory download and with a disposition of "FILE DOWNLOAD COMPLETE UPDATE" and the UE (MCDATA Client) is unaware of the URL of the Media Storage Function }

then { UE (MCDATA Client) sends a SIP MESSAGE to find the URL of the Media Storage Function and responds to a SIP MESSAGE that contains the URL of the Media Storage Function with a SIP 200 (OK) message }

}

(2)

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

ensure that {

when { the MCDATA User requests to send a Group Standalone FD message with a non-mandatory download and with a disposition of "FILE DOWNLOAD COMPLETE UPDATE" and the UE (MCDATA Client) is aware of the URL of the Media Storage Function }

then { UE (MCDATA Client) uploads the file to the Media Storage Function via an HTTP POST message and then sends the URL of the file location to the recipient via a SIP MESSAGE message }

}

(3)

with { UE (MCDATA Client) having sent the URL of the file location to the recipient }

ensure that {

when { UE (MCDATA Client) receives a FD notification via a SIP MESSAGE message }

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

}

(4)

with { UE (MCDATA Client) having received a notification that a sent message was deferred by the recipient }

ensure that {

when { MCData User requests to access the list of deferred group communication }

then { UE (MCDATA Client) sends a SIP MESSAGE message requesting to access the list of deferred communication and responds to a received SIP MESSAGE message with a SIP 200 (OK message and delivers the notification to the MCDATA User }

}

6.2.13.2 Conformance requirements

References: The conformance requirements covered in the current TC are specified in: TS 24.282, clauses 10.2.1.3.2, 10.2.2.1, 10.2.4.2.1, 12.2.1.2, 11.3.2.1, 11.3.2.2. 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.1.3.2]

To discover the absolute URI of the media storage function, the MCData client shall generate a SIP MESSAGE request towards the participating MCData function, in accordance with 3GPP TS 24.229 [5] and IETF RFC 3428 [6] with the clarifications given below.

The MCData client:

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

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

3) shall insert in the SIP MESSAGE request an application/vnd.3gpp.mcdata-info+xml MIME body with a <request-type> element containing the value "msf-disc-req";

4) if the upload of a file is for a group standalone FD request, shall include in an application/vnd.3gpp.mcdata-info+xml MIME body, the <mcdata-calling-group-id> element set to the required MCData group identity; and

NOTE 1: The absence of a group identity in the <mcdata-calling-group-id> element of the application/vnd.3gpp.mcdata-info+xml MIME body implies that the MCData client intends to upload a file for a one-to-one FD request. In this case, the participating MCData function identifies the MCData ID of the user from the binding between the public user identity and the MCData ID.

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

On receipt of a "SIP MESSAGE request for absolute URI discovery response", the MCData client:

1) shall store the absolute URI found in the <mcdata-controller-psi> element;

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

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

[TS 24.282, clause 10.2.2.1]

If the media storage client is not aware of the absolute URI of the media storage function, the media storage client shall request the MCData client to discover the absolute URI associated with the media storage function by following the procedures in subclause 10.2.1.3.

The media storage client shall send HTTP requests over a TLS connection as specified for the HTTP client in the UE in annex A of 3GPP TS 24.482 [24].

NOTE 1: The HTTP client encodes the MCData ID in the bearer access token of the Authorization header field of an HTTP request as specified in 3GPP TS 24.482 [24].

NOTE 2: The HTTP client always sends the HTTP requests to an HTTP proxy. Annex A of 3GPP TS 24.482 [24] indicates how the HTTP proxy forwards the HTTP request to the HTTP server.

To upload a file to media storage function, the media storage client:

1) shall generate an HTTP POST request as specified in IETF RFC 7230 [22] and IETF RFC 7231 [23];

2) shall set the Request-URI to the absolute URI identifying the resource on a media storage function;

3) shall set the Host header field to a hostname identifying the media storage function;

4) shall set the Content-Type header field to multipart/mixed and with a boundary delimiter parameter set to any chosen value;

5) if the file upload is for one-to-one file distribution, shall insert an application/vnd.3gpp.mcdata-info+xml MIME body with:

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

b) the <mcdata-calling-user-id> element set to the originating MCData ID;

6) if the file upload is for group file distribution, shall insert an application/vnd.3gpp.mcdata-info+xml MIME body with:

a) the <request-type> element set to a value of "group-fd";

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

c) the <mcdata-calling-user-id> element set to the originating MCData ID;

7) if end-to-end security is required for a one-to-one communication, the MCData client protects the binary data representing the file and prefixes the protected binary data with security parameters as described in 3GPP TS 33.180 [26];

8) if

i) end-to-end security is not required for a one-to-one communication, or

ii) the file upload is for group file distribution;

shall include the binary data representing the file with Content-Type field set to application/octet-stream and Content-Length field set to the file size; and

9) shall send the HTTP POST request towards the media storage function.

On receipt of a HTTP 201 Created containing a Location header field with a URL identifying the location of the resource where the file has been stored on the media storage function, then the media storage client shall store this information.

[TS 24.282, clause 10.2.4.2.1]

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

The MCData client:

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

2) if a one-to-one standalone FD message is to be sent shall insert in the SIP MESSAGE request:

a) an application/resource-lists+xml MIME body with the MCData ID of the target MCData user, according to rules and procedures of IETF RFC 4826 [9]; and

b) an application/vnd.3gpp.mcdata-info+xml MIME body with a <request-type> element set to a value of "one-to-one-fd";

…

4) shall generate a standalone FD message as specified in subclause 6.2.2.2; and

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

[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.282, clause 11.3.2.1]

Upon receiving a request from the MCData user to access the list of deferred data group communications, the MCData client:

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

2) shall generate DEFERRED DATA REQUEST message as specified in subclause 15.1.11.1;

3) shall include in the SIP request, the DEFERRED DATA GROUP COMM message in an application/vnd.3gpp.mcdata-signalling MIME body as specified in subclause E.1; and

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

[TS 24.282, clause 11.3.2.2]

Upon receipt of a "SIP MESSAGE response for the list of deferred group communications request", the MCData client:

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

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

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

a) if the application/vnd.3gpp.mcdata-signalling MIME body contains DEFERRED DATA RESPONSE message as specified in subclause 15.1.12:

i) for each payload, if payload type is set to "FILEURL", shall store the payload data; and

4) shall present to MCData user, the list of file URLs which were deferred.

6.2.13.3 Test description

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

– In the MCData Group Configuration document the <mcdata-on-network-max-data-size-auto-recv> shall be set to 0 to indicate non-mandatory download independent from the file size.

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

Table 6.2.13.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 group FD over HTTP for non-mandatory download and with disposition request "FILE DOWNLOAD COMPLETED UPDATE".

(NOTE 1, NOTE 2)

–

–

–

–

2

Check: Does the UE (MCData Client) perform the procedure for discovery of the absolute URI of the media storage function (one-to-one communication) specified in TS 36.579-1 [2] Table 5.3C.9.3-1 ?

–

–

1

P

3

Check: Does the UE (MCData Client) perform the procedure for FD file upload using HTTP specified in TS 36.579-1 [2] Table 5.3C.10.3-1?

–

–

2

P

3A

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

–

–

2

P

4-6

Void

–

–

–

–

7

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 an FD NOTIFICATION with disposition notification type "FILE DOWNLOAD DEFERRED" for the FD message sent at step 3?

–

–

4

P

8

Void

–

–

–

–

9

Check: Does the UE (MCDATA Client) deliver the notification that the remote Client has deferred the acceptance of the download?

(NOTE 1)

–

–

3

P

10

Make the MCData User request to access the list of deferred data group communication.

(NOTE 1)

–

–

–

–

11

Check: Does the UE (MCData Client) perform the procedure for MCX SIP MESSAGE Request – Accept CO specified in TS 36.579-1 [2] Table 5.3.30.3-1 to retrieve the list of deferred data group communication?

–

–

4

P

12-14

Void

–

–

–

–

15

Check: Does the UE (MCDATA Client) present the list of file URLs which were deferred to 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.13.3.3 Specific message contents

Table 6.2.13.3.3-1..6: Void

Table 6.2.13.3.3-7: HTTP POST (step 3, Table 6.2.13.3.2-1;
step 2, TS 36.579-1 [2] Table 5.3C.10.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.4.3-1 condition FD_HTTP

Information Element

Value/remark

Comment

Reference

Condition

Message-body

MIME body part

MCData-Info

MIME-part-body

MCData-Info as described in Table 6.2.1.3.3-8

Table 6.2.13.3.3-8: MCDATA-Info (Table 6.2.13.3.3-7)

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

Information Element

Value/remark

Comment

Reference

Condition

mcdata-info

mcdata-Params

request-type

"group-fd"

mcdata-request-uri

px_MCData_Group_A_ID

NOTE: the element is not encrypted

mcdata-calling-user-id

px_MCData_ID_User_A

NOTE: the element is not encrypted

Table 6.2.13.3.3-9: Void

Table 6.2.13.3.3-10: HTTP 201 Created (step 3, Table 6.2.13.3.2-1;
step 3, TS 36.579-1 [2] Table 5.3C.10.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.4.7-1, condition FD_HTTP

Table 6.2.13.3.3-11: SIP MESSAGE (step 3, Table 6.2.13.3.2-1;
step 3, TS 36.579-1 [2] Table 5.3C.10.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.7.1-1, condition MCDATA_FD, MCDATA_SIGNALLING

Information Element

Value/remark

Comment

Reference

Condition

Message-body

MIME body part

MCData-Info

MIME-part-body

MCData-Info as described in Table 6.2.13.3.3-12

MIME body part

MCData Data signalling message

MIME-part-body

MCData Protected Payload Message containing FD SIGNALLING PAYLOAD as described in Table 6.2.13.3.3-12A

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

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

Information Element

Value/remark

Comment

Reference

Condition

mcdata-info

mcdata-Params

request-type

"group-fd"

Table 6.2.13.3.3-12A: FD SIGNALLING PAYLOAD (Table 6.2.13.3.3-11)

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

Table 6.2.13.3.3-13: SIP MESSAGE (step 7, Table 6.2.13.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-Info

MIME-part-body

MCData-Info as described in Table 6.2.1.3.3-14

MIME body part

MCData Data signalling message

MIME-part-body

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

Table 6.2.13.3.3-14: MCDATA-Info (Table 6.2.13.3.3-13)

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.2.13.3.3-15: FD NOTIFICATION (Table 6.2.13.3.3-13)

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

Table 6.2.13.3.3-16: SIP MESSAGE (step 11, Table 6.2.13.3.2-1;
step 2, TS 36.579-1 [2] Table 5.3.30.3-1)

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

Information Element

Value/remark

Comment

Reference

Condition

Content-Type

media-type

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

Message-body

MCData Signalling message

MCData Protected Payload Message containing DEFERRED DATA REQUEST as described in Table 6.2.13.3.3-17

Table 6.2.13.3.3-17: DEFERRED DATA REQUEST (Table 6.2.13.3.3-16)

Derivation Path: TS 24.282 [87] clause 15.1.11

Information Element

Value/remark

Comment

Reference

Condition

Deferred data request message identity

‘00001011’B

Deferred List Access Request

TS 24.282 [87] clause 15.2.2

Table 6.2.13.3.3-18: SIP MESSAGE (step 11, Table 6.2.13.3.2-1;
step 4, TS 36.579-1 [2] Table 5.3.30.3-1)

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

Information Element

Value/remark

Comment

Reference

Condition

Content-Type

media-type

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

Message-body

MCData Signalling message

MCData Protected Payload Message containing DEFERRED DATA RESPONSE as described in Table 6.2.13.3.3-19

Table 6.2.13.3.3-19: DEFERRED DATA RESPONSE (Table 6.2.13.3.3-18)

Derivation Path: TS 24.282 [87] clause 15.1.12

Information Element

Value/remark

Comment

Reference

Condition

Deferred data response message identity

‘00001100’B

Deferred List Access Response

TS 24.282 [87] clause 15.2.2

Number of payloads

"1"

TS 24.282 [87] clause 15.2.12

Security parameters and Payload

Not present

Payload

TS 24.282 [87] clauses 11.3.3.2 and 15.2.13

Length of Payload contents

Length of the payload contents

Payload content type

“00000100”

FILEURL

Payload contents

same URI as assigned by the HTTP 201 (Created) at step 3