6.2.8 On-network / File Distribution (FD) / FD Using HTTP / Group Standalone FD / Mandatory Download / Without Disposition Request / Client Terminated (CT)

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

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

6.2.8.1 Test Purpose (TP)

(1)

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

ensure that {

when { UE (MCDATA Client) receives a SIP MESSAGE message for a group standalone FD message with a mandatory download and without a disposition request }

then { UE (MCDATA Client) responds with a SIP 200 (OK) message and notifies the MCDATA User about the incoming FD request and that the file identified by file URL in the Payload data in the Payload IE will be downloaded automatically and generates an FD NOTIFICATION indicating acceptance of the FD request and attempts to download the file with an HTTP GET message }

}

(2)

with { UE (MCDATA Client) having started to download the file by sending an HTTP GET message }

ensure that {

when { UE (MCDATA Client) has successfully downloaded the file }

then { UE (MCDATA Client) notifies the MCDATA User that the file has successfully downloaded }

}

6.2.8.2 Conformance requirements

References: The conformance requirements covered in the current TC are specified in: TS 24.282, clauses 10.2.4.2.2, 10.2.1.2.3, 12.2.1.1, 10.2.3.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.4.2.2]

Upon receipt of a "SIP MESSAGE request for FD using HTTP for terminating MCData client", the MCData client:

1) may reject the SIP MESSAGE request if there are not enough resources to handle the SIP MESSAGE request;

2) if the SIP MESSAGE request is rejected in step 1), shall respond towards the participating MCData function with a SIP 480 (Temporarily unavailable) response and skip the rest of the steps of this subclause;

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

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

5) shall handle the received message as specified in subclause 10.2.1.2.

[TS 24.282, clause 10.2.1.2.3]

The MCData client:

1) if the FD SIGNALLING PAYLOAD message does not contain an Application ID IE:

a) shall determine that the payload contained in the Payload IE in the FD SIGNALLING PAYLOAD message is for user consumption;

b) shall notify the user about the incoming FD request; and

c) if the FD SIGNALLING PAYLOAD message contains a Metadata IE, shall deliver the contents of the Metadata IE to the user;

2) if the FD SIGNALLING PAYLOAD message contains an Application ID IE:

a) shall determine that the payload contained in the Payload IE in the FD SIGNALLING PAYLOAD message is not for user consumption;

b) if the Application ID value is unknown, shall discard the FD message and exit this subclause;

c) if the Application ID value is known, shall notify the application of the incoming FD request; and

NOTE 1: If FD request is addressed to a non-MCData application that is not running, the MCData client starts the local non-MCData application.

d) if the FD SIGNALLING PAYLOAD message contains a Metadata IE, shall deliver the contents of the Metadata IE to the application;

3) shall start a timer TDU2 (FD non-mandatory download timer) with the timer value as specified in subclause F.2.3;

4) shall wait for the user or application to request to download the file indicated by file URL in the Payload data in the Payload IE in the FD SIGNALLING PAYLOAD message;

5) if the user or application accepts or rejects or decides to defer the FD request, shall stop timer TDU2 (FD non-mandatory download timer);

6) if the user deferred the FD request while the timer TDU2 (FD non-mandatory download timer) was running, shall generate an FD NOTIFICATION indicating deferral of the FD request as specified in subclause 12.2.1.1;

NOTE 2: Once the timer TDU2 (FD non-mandatory download timer) has expired the FD request can only be accepted or rejected with an appropriate action by the MCData client.

NOTE 3: Once the timer TDU2 (FD non-mandatory download timer) has expired, no action is taken by the MCData client if the FD request is deferred.

7) if the user or application rejects the FD request, shall generate an FD NOTIFICATION indicating rejection of the FD request as specified in subclause 12.2.1.1 and shall exit this subclause; and

8) if the user accepts the FD request:

a) shall generate an FD NOTIFICATION indicating acceptance of the FD request as specified in subclause 12.2.1.1;

b) if the FD SIGNALLING PAYLOAD message contains a new Conversation ID, shall instantiate a new conversation with the Message ID in the FD SIGNALLING PAYLOAD identifying the first message in the conversation thread;

c) if the FD SIGNALLING PAYLOAD message contains an existing Conversation ID and:

i) if the FD SIGNALLING PAYLOAD message does not contain an InReplyTo message ID, shall use the Message ID in the FD SIGNALLING PAYLOAD to identify a new message in the existing conversation thread; and

ii) if the FD SIGNALLING PAYLOAD message contains an InReplyTo message ID, shall associate the message to an existing message in the conversation thread as identified by the InReplyTo message ID in the FD SIGNALLING PAYLOAD, and use the Message ID in the FD SIGNALLING PAYLOAD to identify the new message;

d) may store the Conversation ID, Message ID, InReplyTo message ID and Date and time in local storage;

e) shall attempt to download the file as identified by the file URL in the Payload IE in the FD SIGNALLING PAYLOAD message, as specified in subclause 10.2.3.1; and

f) if the received FD SIGNALLING PAYLOAD message contains an FD disposition request type IE requesting a file download completed update, then after the file download has been successfully downloaded, shall generate an FD NOTIFICATION by following the procedures in subclause 12.2.1.1.

[TS 24.282, clause 12.2.1.1]

The MCData client shall follow the procedures in this subclause to:

– indicate to an MCData client that an SDS message was delivered, read or delivered and read when the originating client requested a delivery, read or delivery and read report;

– indicate to the participating MCData function serving the MCData user that an SDS message was undelivered. The participating MCData function can store the message for later re-delivery;

– indicate to an MCData client that a request for FD was accepted, deferred or rejected; or

– indicate to an MCData client that a file download has been completed;

Before sending a disposition notification the MCData client needs to determine:

– the group identity related to an SDS or FD message request received as part of a group communication. The MCData client determines the group identity from the contents of the <mcdata-calling-group-id> element contained in the application/vnd.3gpp.mcdata-info+xml MIME body of the incoming SDS or FD message request; and

– the MCData user targeted for the disposition notification. The MCData client determines the targeted MCData user from the contents of the <mcdata-calling-user-id> element contained in the application/vnd.3gpp.mcdata-info+xml MIME body of the incoming SDS or FD message request.

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.8.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/resource-lists+xml MIME body containing the MCData ID of the targeted MCData user, according to rules and procedures of IETF RFC 5366 [18];

4) void;

5) if sending a disposition notification in response to an MCData group data request, shall include an <mcdata-calling-group-id> element set to the MCData group identity in the application/vnd.3gpp.mcdata-info+xml MIME body;

6) if requiring to send an SDS notification, shall generate an SDS NOTIFICATION message and include it in the SIP MESSAGE request as specified in subclause 6.2.3.1;

7) if requiring to send an FD notification, shall generate an FD NOTIFICATION message and include it in the SIP MESSAGE request as specified in subclause 6.2.3.2; and

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

[TS 24.282, clause 10.2.3.1]

The media storage client on the MCData 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 download a file from the media storage function on the controlling MCData function, the media storage client on the MCData client:

1) shall generate an HTTP GET request as specified in IETF RFC 7230 [22] and IETF RFC 7231 [23] with a Request-URI set to an absolute URI identifying the URL of the file being requested from the media storage function on the controlling MCData function; and

2) shall send the HTTP GET request towards the media storage function on the controlling MCData function.

On receipt of a HTTP 200 OK response containing the requested file, the MCData client shall notify the user or application that the file has been successfully downloaded.

6.2.8.3 Test description

6.2.8.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 files downloaded or received at previous test runs are deleted.

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

Table 6.2.8.3.2-1: Main Behaviour

St	Procedure	Message Sequence		TP	Verdict
		U – S	Message
1-1B	Check: Does the UE (MCData Client) perform steps 1a1-3 of the the procedure for MCX SIP MESSAGE CT specified in TS 36.579-1 [2] Table 5.3.33.3-1 to receive an FD message for group file distribution with disposition request type "FILE DOWNLOAD COMPLETED UPDATE" and Mandatory Download IE?	–	–	1	P
2-3	Void	–	–	–	–
4-4C	Check: Does the UE (MCData Client) perform steps 2-5 of the procedure for FD file accept and download using HTTP specified in TS 36.579-1 [2] Table 5.3C.11.3-1 to download test file 1? (NOTE 2)	–	–	1,2	P
5-7	Void	–	–	–	–
–	EXCEPTION: In parallel to the events described in step 8 and step 9 the events described in Table 6.2.8.3.2-2 take place.	–	–	–	–
8	Check: Has the UE (MCData Client) notified the MCData User of the incoming FD request and does the UE (MCData Client) notify the MCData User of the successful download of the file? (NOTE 1)	–	–	1,2	P
9	Check: Is the file downloaded at step 4C the test file 1 as specified in annex A.3.1? (NOTE 1)	–	–	2	P
10	The SS releases the RRC connection	–	–	–	–
NOTE 1: This is expected to be done via a suitable implementation dependent MMI. NOTE 2: Test file 1 for CT FD as specified in annex A.3.1.

Table 6.2.8.3.22-2: Parallel Behaviour

St	Procedure	Message Sequence		TP	Verdict
		U – S	Message
1	Check: Does the UE (MCData Client) send a SIP MESSAGE request for notification of file download completed in parallel to step 8 and step 9 of Table 6.2.8.3.22-1 or at least for 10s?	–>	SIP MESSAGE	–	F

6.2.8.3.3 Specific message contents

Table 6.2.8.3.3-1: SIP MESSAGE (step 1A, Table 6.2.8.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.8.3.3-2
MIME body part		MCData Data signalling message
MIME-part-body	MCData Protected Payload Message containing FD SIGNALLING PAYLOAD as described in Table 6.2.8.3.3-3

Table 6.2.8.3.3-2: MCData-Info (Table 6.2.8.3.3-1)

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.8.3.3-3: FD Signalling Payload (Table 6.2.6.3.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.3.8.6-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.8.3.3-4: Void

Table 6.2.8.3.3-5: SIP MESSAGE (step 4, Table 6.2.8.3.2-1;
step 2, TS 36.579-1 [2] Table 5.3C.11.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.7.1-1, condition MCDATA_FD, RESOURCE_LISTS, MCDATA_SIGNALLING
Information Element	Value/remark	Comment	Reference	Condition
Message-body
MIME body part		MCData-Info
MIME-part-headers	MCData-Info as described in Table 6.2.8.3.3-6
MIME body part		MCData Data signalling message
MIME-part-body	MCData Protected Payload Message containing FD NOTIFICATION as described in Table 6.2.8.3.3-7

Table 6.2.8.3.3-6: MCDATA-Info (Table 6.2.8.3.3-5)

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
mcdata-calling-group-id	Encrypted <mcdata-request-uri> with mcdataURI set to px_MCData_Group_A_ID	Encrypted according to TS 36.579-1 [2] Table 5.5.3.2.1-3A

Table 6.2.8.3.3-7: FD NOTIFICATION (Table 6.2.8.3.3-5)

Derivation Path: TS 36.579-1 [2], Table 5.5.3.8.7-1, condition FD_ACCEPTED

Table 6.2.8.3.3-8: HTTP GET (step 4, Table 6.2.8.3.2-1;
step 4, TS 36.579-1 [2] Table 5.3C.11.3-1)

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

Table 6.2.8.3.3-9: HTTP 200 (OK) (step 4, Table 6.2.8.3.2-1;
step 5, TS 36.579-1 [2] Table 5.3C.11.3-1)

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

Table 6.2.8.3.3-10: Void