6.2.10 On-network / File Distribution (FD) / FD Using Media Plane / One-to-one Standalone FD / Client Terminated (CT)

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

6.2.10.1 Test Purpose (TP)

(1)

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

ensure that {

when { the MCDATA User receives a SIP INVITE to initiate a standalone one-to-one FD message using the media plane }

then { UE (MCDATA Client) responds by sending a SIP 200 (OK) message }

}

(2)

with { UE (MCDATA Client) having responded to the SIP INVITE message that initiated a standalone one-to-one FD message using the media plane }

ensure that {

when { UE (MCDATA Client) receives an MSRP SEND message from the SS (MCDATA Server) }

then { UE (MCDATA Client) responds with an MSRP 200 (OK) message }

}

(3)

with { UE (MCDATA Client) having finished receiving the file from the SS (MCDATA server) }

ensure that {

when { UE (MCDATA Client) receives a SIP BYE message to release communications }

then { UE (MCDATA Client) responds with a SIP 200 (OK) message and then sends a "FILE DOWNLOAD COMPLETED" disposition via a SIP MESSAGE message }

}

6.2.10.2 Conformance requirements

References: The conformance requirements covered in the current TC are specified in: TS 24.282, clauses 10.2.5.2.4, 12.2.1.1, 6.2.3.2, TS 24.582 clauses 7.1.3.1, 7.1.3.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.5.2.4]

Upon receipt of an initial SIP INVITE request, the MCData client shall follow the procedures for termination of multimedia sessions in the IM CN subsystem as specified in 3GPP TS 24.229 [5] with the clarifications below.

The MCData client:

1) may reject the SIP INVITE request if either of the following conditions are met:

a) MCData client does not have enough resources to handle the call; or

b) any other reason outside the scope of this specification;

and skip the rest of the steps after step 2;

2) if the SIP INVITE request is rejected in step 1), shall respond toward participating MCData function either with appropriate reject code as specified in 3GPP TS 24.229 [5] and warning texts as specified in subclause 4.9 or with SIP 480 (Temporarily unavailable) response not including warning texts if the user is authorised to restrict the reason for failure and skip the rest of the steps of this subclause;

3) if the SDP offer of the SIP INVITE request contains an "a=key-mgmt" attribute field with a "mikey" attribute value containing a MIKEY-SAKKE I_MESSAGE:

a) shall extract the MCData ID of the originating MCData user from the initiator field (IDRi) of the I_MESSAGE as described in 3GPP TS 33.180 [26];

b) shall convert the MCData ID to a UID as described in 3GPP TS 33.180 [26];

c) shall use the UID to validate the signature of the MIKEY-SAKKE I_MESSAGE as described in 3GPP TS 33.180 [26];

d) if authentication verification of the MIKEY-SAKKE I_MESSAGE fails, shall reject the SIP INVITE request with a SIP 488 (Not Acceptable Here) response as specified in IETF RFC 4567 [45], and include warning text set to "136 authentication of the MIKEY-SAKKE I_MESSAGE failed" in a Warning header field as specified in subclause 4.9 and not continue with rest of the steps in this subclause; and

e) if the signature of the MIKEY-SAKKE I_MESSAGE was successfully validated:

i) shall extract and decrypt the encapsulated PCK using the terminating user’s (KMS provisioned) UID key as described in 3GPP TS 33.180 [26]; and

ii) shall extract the PCK-ID, from the payload as specified in 3GPP TS 33.180 [26];

NOTE: With the PCK successfully shared between the originating MCData client and the terminating MCData client, both clients are able to create an end-to-end secure session.

4) may display to the MCData user the MCData ID of the inviting MCData user;

5) may display to the MCData user the file meta-data of the incoming file as described by the SDP included in the received SIP INVITE request;

6) if the Mandatory indication IE of the FD SIGNALLING PAYLOAD contained in the application/vnd.3gpp.mcdata-signalling MIME body received in the SIP INVITE request is set to "MANDATORY", then:

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

ii) shall include the option tag "timer" in a Require header field of the SIP 200 (OK) response;

iii) shall include the Session-Expires header field in the SIP 200 (OK) response and start the SIP session timer according to IETF RFC 4028 [38]. The "refresher" parameter in the Session-Expires header field shall be set to "uas";

iv) shall include the g.3gpp.mcdata.fd media feature tag in the Contact header field of the SIP 200 (OK) response;

v) shall include the g.3gpp.icsi-ref media feature tag containing the value of "urn:urn-7:3gpp-service.ims.icsi.mcdata.fd" in the Contact header field of the SIP 200 (OK) response;

vi) shall include an SDP answer in the SIP 200 (OK) response to the SDP offer in the incoming SIP INVITE request according to 3GPP TS 24.229 [5] with the clarifications given in subclause 10.2.5.2.2; and

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

On receipt of an SIP ACK message to the sent SIP 200 (OK) message, the MCData client shall:

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

On receipt of an indication from the media plane of the successful download of the file and if the received FD SIGNALLING PAYLOAD message contained an FD disposition request type IE requesting a file download completed update indication, then, the MCData client:

1) shall follow the procedures described 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 controlling MCData function that sent the SDS or FD message request. The MCData client determines the controlling MCData function from the contents of the <mcdata-controller-psi> element contained in the application/vnd.3gpp.mcdata-info+xml MIME body of the incoming SDS or FD message request;

– 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.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/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) shall insert in the SIP MESSAGE request an application/vnd.3gpp.mcdata-info+xml MIME body with an <mcdata-controller-psi> element containing the PSI of the controlling MCData function;

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 6.2.3.2]

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

1) shall generate an FD NOTIFICATION message as specified in subclause 15.1.6; and

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

When generating an FD NOTIFICATION message as specified in subclause 15.1.6, the MCData client:

1) if sending a file download accept notification, shall set the FD disposition notification type IE as "FILE DOWNLOAD REQUEST ACCEPTED" as specified in subclause 15.2.6;

2) if sending a file download reject notification, shall set the FD disposition notification type IE as "FILE DOWNLOAD REQUEST REJECTED" as specified in subclause 15.2.6;

3) if sending a file download deferred notification, shall set the FD disposition notification type IE as "FILE DOWNLOAD REQUEST DEFERRED" as specified in subclause 15.2.6;

4) shall set the Conversation ID to the value of the Conversation ID that was received in the FD message as specified in subclause 15.2.9;

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

6) if sending a file download completed notification:

a) shall set the FD disposition notification type IE as "FILE DOWNLOAD COMPLETED" as specified in subclause 15.2.6;

b) shall set the Message ID to the value of the Message ID that was received in the FD message as specified in subclause 15.2.10;

c) if the FD message was destined for the user, shall not include an Application ID IE as specified in subclause 15.2.7; and

d) if the FD message was destined for an application, shall include an Application ID IE set to the value of the Application ID that was included in the FD message as specified in subclause 15.2.3.

[TS 24.582, clause 7.1.3.1]

Upon receiving an indication to establish MSRP connection for file distribution as the terminating client, the MCData client:

1. shall act as an MSRP client according to IETF RFC 6135 [12];

2. shall act either as an active endpoint or as an passive endpoint to open the transport connection, according to IETF RFC 6135 [12];

3. shall establish the MSRP connection according to the MSRP connection parameters in the SDP offer received in the SIP INVITE request according to IETF RFC 4975 [11];

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

Once the MSRP session is established, the MCData client:

1. on receipt of an MSRP request in the MSRP session, shall follow the rules and procedures defined in IETF RFC 4975 [11] and in IETF RFC 6714 [13];

2. If an MSRP SEND request indicates the use of chunking, shall wait until all further MSRP SEND requests for the remaining chunks have been received and shall reassemble the entire set of MSRP requests into the file before delivering the content to the application; and

3. shall handle the received content as described in subclause 7.1.3.2.

[TS 24.582, clause 7.1.3.2]

Upon receiving a file, the MCData client:

1. shall decode the contents of the application/vnd.3gpp.mcdata-file MIME body; and

2. once all the chunks of the file are successfully received, shall indicate to the signalling plane that the file download is completed.

6.2.10.3 Test description

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

Table 6.2.10.3.2-1: Main Behaviour

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

1

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

1,2

P

2-5

Void

6

Check: Does the UE (MCData Client) perform the procedure for CT MSRP message transfer specified in TS 36.579-1 [2] Table 5.3C.5.3-1 to receive an FD message containing test file 1?

(NOTE 2)

2

P

7

Void

8

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

3

P

9-10

Void

11

Check: Does the UE (MCData Client) perform the procedure for CO SDS or FD message transfer using signalling plane specified in TS 36.579-1 [2] Table 5.3C.1.3-1 to send a disposition notification for the file received at step 6?

2

P

12

Void

13

Check: Is the file downloaded at step 6 the test file 1 as specified in annex A.3.1?

(NOTE 1)

2

P

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.

6.2.10.3.3 Specific message contents

Table 6.2.10.3.3-1: SIP INVITE (step 1, Table 6.2.10.3.2-1;
step 2, TS 36.579-1 [2] Table 5.3C.3.3-1)

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

Information Element

Value/remark

Comment

Reference

Condition

Message-body

MIME body part

SDP message

MIME-part-body

As described in Table 6.2.10.3.3-2

MIME body part

MCData-Info

MIME-part-body

MCData-Info as described in Table 6.2.10.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.10.3.3-3A

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

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

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

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

Information Element

Value/remark

Comment

Reference

Condition

mcdata-info

mcdata-Params

request-type

"one-to-one-fd"

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

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

Table 6.2.10.3.3-4: SIP 200 (OK) (step 1, Table 6.2.10.3.2-1;
step 4, TS 36.579-1 [2] Table 5.3C.3.3-1)

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

Information Element

Value/remark

Comment

Reference

Condition

Content-Type

value

"application/sdp"

Message-body

SDP message

As described in Table 6.2.10.3.3-5

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

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

Table 6.2.10.3.3-6: MSRP SEND (step 6, Table 6.2.10.3.2-1;
step 1. TS 36.579-1 [2] Table 5.3C.5.3-1)

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

Information Element

Value/remark

Comment

Reference

Condition

Content-Type

media-type

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

data

As specified in table 6.2.10.3.3-8

Table 6.2.10.3.3-7: Void

Table 6.2.10.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-2, condition PROTECTED_FILE, PCK

Table 6.2.10.3.3-9: SIP BYE (step 8, Table 6.2.10.3.2-1;
step 1, TS 36.579-1 [2] Table 5.3C.7.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.2.2-1, condition MT_CALL

Information Element

Value/remark

Comment

Reference

Condition

Reason

reason-value

"SIP"

protocol-cause

"cause="200""

reason-text

"text="transmission succeeded""

Table 6.2.10.3.3-10: Void

Table 6.2.10.3.3-11: SIP MESSAGE (step 11, Table 6.2.2.3.2-1;
step 2, TS 36.579-1 [2] Table 5.3C.1.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

not present

MCData-Info

MIME body part

MCData Data signalling message

MIME-part-body

SDS NOTIFICATION as described in Table 6.2.10.3.3-12

Table 6.2.10.3.3-12: FD NOTIFICATION (Table 6.2.2.3.3-11)

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