6.2.7 On-network / File Distribution (FD) / FD Using HTTP / Group Standalone FD / Mandatory Download / Without Disposition Request / 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.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 FD message with a mandatory download and without a disposition request 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 mandatory download and without a disposition request 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 }
}
6.2.7.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. 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.
6.2.7.3 Test description
6.2.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.
– 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.7.3.2 Test procedure sequence
Table 6.2.7.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 mandatory download and without a disposition request. (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 REQUEST ACCEPTED" for the FD message sent at step 3? |
– |
– |
3 |
P |
|
8 |
Void |
– |
– |
– |
– |
|
9 |
Check: Does the UE (MCDATA Client) deliver the notification that the remote Client has accepted the download? (NOTE 1) |
– |
– |
3 |
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.7.3.3 Specific message contents
Table 6.2.7.3.3-1..6: Void
Table 6.2.7.3.3-7: HTTP POST (step 3, Table 6.2.7.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.7.3.3-8 |
|||
Table 6.2.7.3.3-8: MCDATA-Info (Table 6.2.7.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.7.3.3-9: Void
Table 6.2.7.3.3-10: HTTP 201 Created (step 3, Table 6.2.7.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.7-1, condition FD_HTTP |
Table 6.2.7.3.3-11: SIP MESSAGE (step 3, Table 6.2.7.3.2-1;
step 4, 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.7.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.7.3.3-13 |
|||
Table 6.2.7.3.3-12: MCDATA-Info (Table 6.2.7.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.7.3.3-13: FD Signalling Payload (Table 6.2.5.3.3-12)
|
Derivation Path: TS 36.579-1 [2], Table 5.5.3.8.5-1, condition FD_HTTP |
||||
|
Information Element |
Value/remark |
Comment |
Reference |
Condition |
|
FD disposition request type |
Not present |
no disposition request |
||
|
Mandatory download |
‘0001’B |
MANDATORY DOWNLOAD |
TS 24.282 [31] clause 15.2.16 |
|
Table 6.2.7.3.3-14: SIP MESSAGE (step 7, Table 6.2.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_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-15 |
|||
|
MIME body part |
MCData Data signalling message |
|||
|
MIME-part-body |
MCData Protected Payload Message containing FD NOTIFICATION from the SS as described in Table 6.2.3.3.3-17 |
|||
Table 6.2.7.3.3-15: MCDATA-Info (Table 6.2.7.3.3-14)
|
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.7.3.3-16: FD NOTIFICATION (Table 6.2.7.3.3-14)
|
Derivation Path: TS 36.579-1 [2], Table 5.5.3.8.8-1, condition FD_ACCEPTED |