5.3C Generic test procedures for UE MCData operation

36.579-13GPPMission Critical (MC) services over LTEPart 1: Common test environmentRelease 15TS

5.3C.1 CO SDS or FD message transfer using signalling plane

5.3C.1.1 Initial conditions

As specified in the test case which calls the procedure.

5.3C.1.2 Definition of system information messages

The E-UTRA default system information messages as defined in TS 36.508 [6] are used.

5.3C.1.3 Procedure

Table 5.3C.1.3-1: CO SDS or FD message transfer using signalling plane

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

EXCEPTION: Step 1a1 describes behaviour that depends on the E-UTRA RRC state at the time the present procedure is called.

1a1

IF in RRC_IDLE state, the E-UTRA/EPC actions described in clause 5.4.3 ‘Generic Test Procedure for MCX CO communication in E-UTRA’ take place.

2

Check: Does the UE (MCData Client) send a SIP MESSAGE request?

–>

SIP MESSAGE

P

3

The SS (MCData server) sends a SIP 202 (Accepted) response

<–

SIP 202 (Accepted)

4

The SS waits 2 seconds before the SS deactivates the dedicated EPS bearer and releases the RRC connection (NOTE 1).

NOTE 1: The specified wait period of 2s shall ensure that lower layer signalling (TCP) is finished.

5.3C.1.4 Specific message contents

All message contents are as specified in clause 5.5 and in the test case calling the procedure, with the following clarifications:

none

5.3C.2 CO MCData Call Establishment

5.3C.2.1 Initial conditions

As specified in the test case which calls the procedure.

5.3C.2.2 Definition of system information messages

The E-UTRA default system information messages as defined in TS 36.508 [6] are used.

5.3C.2.3 Procedure

Table 5.3C.2.3-1: CO MCData Call Establishment

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

EXCEPTION: Step 1a1 describes behaviour that depends on the E-UTRA RRC state at the time the present procedure is called.

1a1

IF in RRC_IDLE state, the E-UTRA/EPC actions described in clause 5.4.3 ‘Generic Test Procedure for MCX CO communication in E-UTRA’ take place.

2

Check: Does the UE (MCData client) send a SIP INVITE requesting the establishment of an MCData call?

–>

SIP INVITE

P

3

The SS sends SIP 100 Trying

<–

SIP 100 (Trying)

4

The SS (MCData server) responds with a SIP 200 (OK)

<–

SIP 200 (OK)

5

Check: Does the UE (MCData client) send a SIP ACK to acknowledge the session establishment/modification?

–>

SIP ACK

P

6

The UE (MCData client) connects to the TCP server at the SS side to establish an MSRP connection (NOTE 1)

7

Check: Does the UE (MCData Client) send an empty MSRP SEND request to bind the TCP connection to the MSRP session?

–>

MSRP SEND

P

8

The SS (MCData Server) sends an MSRP 200 (OK) response.

<–

MSRP 200 (OK)

NOTE 1: According to TS 24.282 [87] clauses 9.2.3.4.2, 9.2.4.4.2 and 10.2.5.4.2 the SS sets the a=setup attribute set to "passive" (see table 5.5.3.1.2-3) ⇒ The UE’s MCData client has the role of the active endpoint

5.3C.2.4 Specific message contents

All message contents are as specified in clause 5.5 and in the test case calling the procedure, with the following clarifications:

Table 5.3C.2.4-1: MSRP SEND (Step 7, Table 5.3C.2.3-1)

Derivation Path: Table 5.5.12.1-1, condition EMPTY_SEND_REQ

5.3C.3 CT MCData Call Establishment

5.3C.3.1 Initial conditions

As specified in the test case which calls the procedure.

5.3C.3.2 Definition of system information messages

The E-UTRA default system information messages as defined in TS 36.508 [6] are used.

5.3C.3.3 Procedure

Table 5.3C.3.3-1: CT MCData Call Establishment

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

EXCEPTION: Step 1a1 describes behaviour that depends on the E-UTRA RRC state at the time the present procedure is called.

1a1

IF in RRC_IDLE state, the E-UTRA/EPC actions which described in clause 5.4.4 ‘Generic Test Procedure for MCX CT communication in E-UTRA’ take place.

2

The SS (MCX Server) sends a SIP INVITE requesting the establishment of an MCData call.

<–

SIP INVITE

EXCEPTION: Step 3a1 describes behaviour that depends on the UE implementation; the "lower case letter" identifies a step sequence that take place if the UE responds to a SIP INVITE with a SIP 100 (Trying)

3a1

The UE (MCX client) sends a SIP 100 (Trying)

–>

SIP 100 (Trying)

4

Check: Does the UE (MCX client) send a SIP 200 (OK)?

–>

SIP 200 (OK)

P

5

The SS (MCX server) sends a SIP ACK

<–

SIP ACK

EXCEPTION: Steps 6a1 – 6b3 describe behaviour that depends on which role of an endpoint the UE (MCData Client) has chosen in its SDP answer sent at step 4

6a1

IF the UE (MCData Client) acts as passive endpoint (NOTE 1) THEN the SS connects to the TCP server at the UE side to establish an MSRP connection

6a2

The SS sends an empty MSRP SEND request to bind the TCP connection to the MSRP session.

<–

MSRP SEND

6a3

Check: Does the UE (MCData Client) send an MSRP 200 (OK) response?

–>

MSRP 200 (OK)

P

6b1

ELSE (NOTE 2) the UE (MCData client) connects to the TCP server at the SS side to establish an MSRP connection

6b2

Check: Does the UE (MCData Client) send an empty MSRP SEND request to bind the TCP connection to the MSRP session?

–>

MSRP SEND

P

6b3

The SS (MCData Server) sends an MSRP 200 (OK) response.

<–

MSRP 200 (OK)

NOTE 1: The MCData Client indicates to act as passive endpoint by setting the a=setup attribute of the SDP answer at step 4 to "passive" (according to RFC 4145 [119])

NOTE 2: The MCData Client indicates to act as active endpoint by setting the a=setup attribute of the SDP answer at step 4 to "active" (according to RFC 4145 [119])

5.3C.3.4 Specific message contents

All message contents are as specified in clause 5.5 and in the test case calling the procedure, with the following clarifications:

Table 5.3C.3.4-1: MSRP SEND (Step 6a2, Table 5.3C.3.3-1)

Derivation Path: Table 5.5.12.2-1, condition EMPTY_SEND_REQ

Table 5.3C.3.4-2: MSRP SEND (Step 6b2, Table 5.3C.3.3-1)

Derivation Path: Table 5.5.12.1-1, condition EMPTY_SEND_REQ

5.3C.4 CO MSRP message transfer

5.3C.4.1 Initial conditions

As specified in the test case which calls the procedure.

5.3C.4.2 Definition of system information messages

The E-UTRA default system information messages as defined in TS 36.508 [6] are used.

5.3C.4.3 Procedure

Table 5.3C.4.3-1: CO MSRP message transfer

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

EXCEPTION: Steps 1-2 are repeated until the UE (MCData client) indicates the end of the message by setting the continuation-flag to "$" in the End-line of the MSRP SEND request at step 1

1

Check: Does the UE (MCData Client) send an MSRP SEND request?

–>

MSRP SEND

P

2

The SS (MCData Server) sends an MSRP 200 (OK) response.

<–

MSRP 200 (OK)

3

In case of chunking the SS reassembles the data contained in the bodies of the MSRP SEND requests (NOTE 1)

NOTE 1: In case of no chunking there is only one MSRP SEND request which contains the entire data.
In case of chunking there are more than one MSRP SEND requests containing the chunks of data and the content type shall be the same for all MSRP SEND requests.

5.3C.4.4 Specific message contents

All message contents are as specified in clause 5.5 and in the test case calling the procedure, with the following clarifications:

none

5.3C.5 CT MSRP message transfer

5.3C.5.1 Initial conditions

As specified in the test case which calls the procedure.

5.3C.5.2 Definition of system information messages

The E-UTRA default system information messages as defined in TS 36.508 [6] are used.

5.3C.5.3 Procedure

Table 5.3C.5.3-1: CT MSRP message transfer

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

1

The SS sends an MSRP SEND request containing the entire data (NOTE 1).

<–

MSRP SEND

2

Check: Does the UE (MCData Client) send an MSRP 200 (OK) response?

–>

MSRP 200 (OK)

P

NOTE 1: No chunking is applied in DL.

5.3C.5.4 Specific message contents

All message contents are as specified in clause 5.5 and in the test case calling the procedure, with the following clarifications:

none

5.3C.6 CO MCData call release

5.3C.6.1 Initial conditions

As specified in the test case which calls the procedure.

5.3C.6.2 Definition of system information messages

The E-UTRA default system information messages as defined in TS 36.508 [6] are used.

5.3C.6.3 Procedure

Table 5.3C.6.3-1: CO MCData call release

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

1

Check: Does the UE (MCData client) send a SIP BYE request to terminate the MCData communication?

–>

SIP BYE

P

2

The SS (MCData Server) sends a SIP 200 (OK) response.

<–

SIP 200 (OK)

EXCEPTION: Steps 3a1 – 3b1 describe behaviour that depends on the endpoint role the UE (MCData Client) has chosen at call establishment (NOTE 1)

3a1

IF the client is the active endpoint THEN the SS waits 3s for the client to close the MSRP TCP connection (NOTE 2)

3b1

ELSE the SS closes the MSRP TCP connection (NOTE 3)

4

The SS waits 2 seconds before it deactivates the dedicated EPS bearer (NOTE 4, 5).

NOTE 1: The endpoint role is negotiated in the SDP signalling at call establishment (table 5.3C.2.3-1 and 5.3C.3.3-1)

NOTE 2: After the wait period the SS may stop the MSRP TCP server independent from whether or not the UE has closed the connection.

NOTE 3: When the SS has the role of the active endpoint it means that the MCData client hosts the TCP server of the MSRP connection.

NOTE 4: The specified wait period of 2s shall ensure that lower layer signalling (TCP) is finished and any not allowed behaviour captured.

NOTE 5: The RRC connection is kept to allow subsequent signalling using the control plane as e.g. an SDS NOTIFICATION in case of Standalone SDS.

5.3C.6.4 Specific message contents

All message contents are as specified in clause 5.5 and in the test case calling the procedure, with the following clarifications:

none

5.3C.7 CT MCData call release

5.3C.7.1 Initial conditions

As specified in the test case which calls the procedure.

5.3C.7.2 Definition of system information messages

The E-UTRA default system information messages as defined in TS 36.508 [6] are used.

5.3C.7.3 Procedure

Table 5.3C.7.3-1: CT MCData call release

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

1

The SS (MCData server) sends a SIP BYE request to terminate the MCData communication.

<–

SIP BYE

2

Check: Does the UE (MCData client) send a SIP 200 (OK) response?

–>

SIP 200 (OK)

P

EXCEPTION: Steps 3a1 – 3b1 describe behaviour that depends on the endpoint role the UE (MCData Client) has chosen at call establishment (NOTE 1)

3a1

IF the client is the active endpoint THEN the SS waits 3s for the client to close the MSRP TCP connection (NOTE 2)

3b1

ELSE the SS closes the MSRP TCP connection (NOTE 3)

4

The SS waits 2 seconds before the SS deactivates the dedicated EPS bearer
(NOTE 4, 5).

NOTE 1: The endpoint role is negotiated in the SDP signalling at call establishment (table 5.3C.2.3-1 and 5.3C.3.3-1)

NOTE 2: After the wait period the SS may stop the MSRP TCP server independent from whether or not the UE has closed the connection..

NOTE 3: When the SS has the role of the active endpoint it means that the MCData client hosts the TCP server of the MSRP connection.

NOTE 4: The specified wait period of 2s shall ensure that lower layer signalling (TCP) is finished and any not allowed behaviour captured.

NOTE 5: The RRC connection is kept to allow subsequent signalling using the control plane as e.g. an SDS NOTIFICATION in case of Standalone SDS.

5.3C.7.4 Specific message contents

All message contents are as specified in clause 5.5 and in the test case calling the procedure, with the following clarifications:

none

5.3C.8 Discovery of the absolute URI of the media storage function (one-to-one communication)

5.3C.8.1 Initial conditions

As specified in the test case which calls the procedure.

5.3C.8.2 Definition of system information messages

The E-UTRA default system information messages as defined in TS 36.508 [6] are used.

5.3C.8.3 Procedure

Table 5.3C.8.3-1: Discovery of the absolute URI of the media storage function (one-to-one)

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

EXCEPTION: Step 1a1 describes behaviour that depends on the E-UTRA RRC state at the time the present procedure is called and on the UE implementation.

1a1

IF in RRC_IDLE state and pc_MCData_MSFDiscoverySignalling, the E-UTRA/EPC actions described in clause 5.4.3 ‘Generic Test Procedure for MCX CO communication in E-UTRA’ take place.

EXCEPTION: Steps 2a1 – 2b1 describe behaviour that depends on the UE implementation

2a1

IF pc_MCData_MSFDiscoverySignalling THEN
Check: Does the UE (MCData Client) send a SIP MESSAGE request to discover the absolute URI of the media storage function?

–>

SIP MESSAGE

P

2a2

The SS (MCData server) sends a SIP 200 (OK) response.

<–

SIP 200 (OK)

2a3

The SS (MCData server) sends a SIP MESSAGE request containing the absolute URI of the media storage function in the <mcdata-controller-psi> element of the mcdata-info.

<–

SIP MESSAGE

2a4

Check: Does the UE (MCData client) send a SIP 200 (OK) response?

–>

SIP 200 (OK)

P

2b1

ELSE the UE determines the value of the absolute URI associated with the media storage function of the MCData content server from the <MCDataContentServerURI> element of the MCData user profile document

5.3C.8.4 Specific message contents

All message contents are as specified in clause 5.5 and in the test case calling the procedure, with the following clarifications:

Table 5.3C.8.4-1: SIP MESSAGE from the UE (step 2a1, Table 5.3C.8.3-1)

Derivation Path: Table 5.5.2.7.1-1, condition MCDATA_FD

Information Element

Value/remark

Comment

Reference

Condition

Message-body

MIME body part

MCData-Info

MIME-part-body

MCData-Info as described in Table 5.3C.8.4-2

Table 5.3C.8.4-2: MCDATA-Info from the UE (Table 5.3C.8.4-1)

Derivation Path: Table 5.5.3.2.1-3

Information Element

Value/remark

Comment

Reference

Condition

mcdata-info

mcdata-Params

request-type

"msf-disc-req"

Table 5.3C.8.4-3: SIP MESSAGE from the SS (step 2a3, Table 5.3C.8.3-1)

Derivation Path: Table 5.5.2.7.2-1, condition MCDATA_FD

Information Element

Value/remark

Comment

Reference

Condition

Request-Line

Request-URI

tsc_MCData_PublicServiceId_A

According to TS 24.282 [87] clause 10.2.1.3.3 the participating function just forwards the SIP MESSAGE received from the controlling function to the client

Accept-Contact

ac-value[2]

not present

P-Asserted-Identity

name-addr

px_MCX_SIP_PublicUserId_A_1

Public user ID of the calling MCData user (TS 24.282 [87] clause 10.2.1.3.4)

Message-body

MIME body part

MCData-Info

MIME-part-body

MCData-Info as described in Table 5.3C.8.4-4

Table 5.3C.8.4-4: MCDATA-Info from the SS (Table 5.3C.8.4-3)

Derivation Path: Table 5.5.3.2.2-3

Information Element

Value/remark

Comment

Reference

Condition

mcdata-info

mcdata-Params

request-type

"msf-disc-res"

mcdata-request-uri

not present

mcdata-calling-user-id

not present

mcdata-controller-psi

Encrypted <mcdata-controller-psi> with mcdataURI set to tsc_MCData_MSF_URI

Encrypted according to Table 5.5.3.2.2-3A

5.3C.9 Discovery of the absolute URI of the media storage function (group communication)

5.3C.9.1 Initial conditions

Same as 5.3C.8.1.

5.3C.9.2 Definition of system information messages

Same as 5.3C.8.2.

5.3C.9.3 Procedure

Same as 5.3C.8.3.

5.3C.9.4 Specific message contents

All message contents are as specified in clause 5.5 and in the test case calling the procedure, with the following clarifications:

Table 5.3C.9.4-1: SIP MESSAGE from the UE (step 2a1, Table 5.3C.8.3-1)

Derivation Path: Table 5.5.2.7.1-1, condition MCDATA_FD

Information Element

Value/remark

Comment

Reference

Condition

Message-body

MIME body part

MCData-Info

MIME-part-body

MCData-Info as described in Table 5.3C.9.4-2

Table 5.3C.9.4-2: MCDATA-Info from the UE (Table 5.3C.9.4-1)

Derivation Path: Table 5.5.3.2.1-3

Information Element

Value/remark

Comment

Reference

Condition

mcdata-info

mcdata-Params

request-type

"msf-disc-req"

mcdata-calling-group-id

Encrypted <mcdata-calling-group-id> with mcdataURI set to px_MCData_Group_A_ID

Encrypted according to Table 5.5.3.2.1-3A

Table 5.3C.9.4-3: SIP MESSAGE from the SS (step 2a3, Table 5.3C.8.3-1)

Same as Table 5.3C.8.4-3

5.3C.10 FD file upload using HTTP

5.3C.10.1 Initial conditions

As specified in the test case which calls the procedure.

5.3C.10.2 Definition of system information messages

The E-UTRA default system information messages as defined in TS 36.508 [6] are used.

5.3C.10.3 Procedure

Table 5.3C.10.3-1: FD file upload using HTTP

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

EXCEPTION: Step 1a1 describes behaviour that depends on the E-UTRA RRC state at the time the present procedure is called.

1a1

IF in RRC_IDLE state, the E-UTRA/EPC actions described in clause 5.4.3 ‘Generic Test Procedure for MCX CO communication in E-UTRA’ take place.

2

Check: Does the UE (MCData client) send an HTTP POST request to upload a file to the media storage function?

–>

HTTP POST

P

3

The SS (MCData server) sends an HTPP 201 Created response containing a Location header field with a URL identifying the location of the resource where the file has been stored at the media storage function.

<–

HTTP 201 Created

4

Check: Does the UE (MCData client) send a SIP MESSAGE request containing an FD SIGNALLING PAYLOAD with Payload content type "FILEURL" and with the Payload data containing the URL of the file?

–>

SIP MESSAGE

P

5

The SS (MCData server) sends a SIP 202 (Accepted) response

<–

SIP 202 (Accepted)

6

The SS waits 2 seconds before the SS releases the RRC connection (NOTE 1).

NOTE 1: The specified wait period of 2s shall ensure that lower layer signalling (TCP) is finished.

5.3C.10.4 Specific message contents

All message contents are as specified in clause 5.5 and in the test case calling the procedure, with the following clarifications:

none

5.3C.11 FD file accept and download using HTTP

5.3C.11.1 Initial conditions

As specified in the test case which calls the procedure.

5.3C.11.2 Definition of system information messages

The E-UTRA default system information messages as defined in TS 36.508 [6] are used.

5.3C.11.3 Procedure

Table 5.3C.11.3-1: FD file accept and download using HTTP

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

EXCEPTION: Step 1a1 describes behaviour that depends on the E-UTRA RRC state at the time the present procedure is called.

1a1

IF in RRC_IDLE state, the E-UTRA/EPC actions described in clause 5.4.3 ‘Generic Test Procedure for MCX CO communication in E-UTRA’ take place.

2

Check: Does the UE (MCData client) send a SIP MESSAGE request containing an FD NOTIFICATION with FD disposition notification type "FILE DOWNLOAD REQUEST ACCEPTED"?

–>

SIP MESSAGE

P

3

The SS (MCData server) sends a SIP 202 (Accepted) response

<–

SIP 202 (Accepted)

4

Check: Does the UE (MCData client) send an HTTP GET request to download the file?

–>

HTTP GET

P

5

SS (MCData server) sends an HTTP 200 OK response containing the requested file.

<–

HTTP 200 OK

EXCEPTION: Steps 6a1 describes behaviour that depends on the test case requirements; the "lower case letter" identifies a step sequence that takes place when the SS has included a FD disposition request of "FILE DOWNLOAD COMPLETED UPDATE" in the FD SIGNALLING PAYLOAD

6a1

Check: Does the UE (MCData client) send a SIP MESSAGE request containing an FD NOTIFICATION with disposition notification type "FILE DOWNLOAD COMPLETED"?

–>

SIP MESSAGE

P

6a2

The SS (MCData server) sends a SIP 202 (Accepted) response

<–

SIP 202 (Accepted)

7

The SS waits 2 seconds before the SS releases the RRC connection (NOTE 1).

NOTE 1: The specified wait period of 2s shall ensure that lower layer signalling (TCP) is finished.

5.3C.11.4 Specific message contents

All message contents are as specified in clause 5.5 and in the test case calling the procedure, with the following clarifications:

none