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. |
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 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 |
–> |
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