5.3 Generic test procedures for UE MCS operation

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

5.3.1 General

The purpose of the procedures specified in the following clauses is to facilitate test description by providing procedure sequences which can be referred from the relevant TCs specified e.g. in 3GPP TS 36.579-2 [2], 3GPP TS 36.579-3 [3], 3GPP TS 36.579-6 [84], 3GPP TS 36.579-7 [85].

The procedures specified are required to ensure that any MC service can take place or specific MC relevant pre-conditions are met before a test case can be executed.

5.3.2 MCX Authorization/Configuration and Key Generation

5.3.2.1 Initial conditions

Within the context of this procedure, MCX refers to MCPTT, MCVideo or MCData.System Simulator:

– SS (MCX 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 [6] clause 4.4. The simulated Cell 1 shall belong to PLMN1 (the PLMN specified for MCX operation in the MCX configuration document).

Implementation Under Test (IUT):

– UE (MCX client)

– The MCX Client has been provisioned with the Initial UE Configuration Data as specified in clause 5.5.8.1 allowing for the location of the configuration management server for configuration of the MCX UE initial configuration management object (MO) and the default MCX user profile configuration management object (MO).

– According to TS 33.180 [94] all HTTP connections are secured by TLS.
The HTTP-1 interface authentication between the HTTP client in the MC UE and the HTTP server endpoint (HTTP proxy, IdM server or KMS) shall be performed by one-way authentication of the HTTP server endpoint based on server certificate as described in TS 33.180 [94] clause 6.1.1.

– The UE User is provided with username/password for user authentication (px_MCX_User_A_username, px_MCX_User_A_password as provided in TS 36.579-5 [5], Table 9.2-1: MCX Client Common PIXIT)

– The test USIM set as defined in clause 5.5.10 is inserted.

The UE is attached to EPS services.

– The UE is provisioned with the names and values of the Transport Key (TrK) and the Integrity Key (InK), since the KMS shall encrypt the key material sent to the client with the TrK and sign the response with the TrK or the InK according to TS 33.180 [94].

5.3.2.2 Definition of system information messages

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

5.3.2.3 Procedures

Table 5.3.2.3-1: MCX user authentication

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

1-2

Void

EXCEPTION: Depending on the UE capabilities, the UE (MCX client) executes the sequence described in Table 5.3.2.3-1A

EXCEPTION: The messages below up to and including step 7 are transmitted over a secure TLS tunnel that has been established by the UE (MCX client) as specified by 3GPP TS 33.310 [70], to the authorisation endpoint of the IdM server as specified in 3GPP TS 33.180 [94] using the configured URL of the authorisation endpoint of the IdM server as specified in the "<x>/OnNetwork/AppServerInfo/IDMSAuthEndpoint" leaf node, Table 5.5.8.1-1.

EXCEPTION: Steps 3a1-3b1 describe behaviour that depends on UE implementation of the OpenID Connect protocol; the "lower case letter" identifies a step sequence that takes place when one or the other is the case.

3a1

The UE (MCX client) sends an OpenID Connect Authentication Request using HTTP GET.

–>

HTTP GET (Authorization)

P

3b1

The UE (MCX client) sends an OpenID Connect Authentication Request using HTTP POST.

–>

HTTP POST (Authorization)

P

4

The SS sends a HTTP 200 (OK) including the HTML form requesting username and password.

<–

HTTP 200 (OK)

5

Make the UE user provide user credentials: username and password (px_MCX_User_A_username, px_MCX_User_A_password).

NOTE 2

6

The UE (MCX client) sends an HTTP POST Request message to the SS containing user name and password.

–>

HTTP POST

P

7

The SS sends a HTTP 302 (Found) as the OpenID Connect Authentication Response containing an authorization code.

<–

HTTP 302 (Found)

8

Void

EXCEPTION: The messages in steps 9 to 10 are transmitted over a secure TLS tunnel that has been established by the UE (MCX client) as specified by 3GPP TS 33.310 [70] to the token endpoint of the IdM server as specified in 3GPP TS 33.180 [94] using the configured URL of the token endpoint of the IdM server as specified in the "/<x>/OnNetwork/AppServerInfo/IDMSTokenEndpoint" leaf node, Table 5.5.8.1-1.

9

The UE (MCX client) sends an HTTP POST Request message to the SS (OIDC Token Request message), passing the authorization code obtained in step 7.

–>

HTTP POST

P

10

The SS sends a HTTP 200 (OK) providing id_token, access_token and refresh token.

<–

HTTP 200 (OK)

EXCEPTION: The messages in steps 11 to 14 are transmitted over a secure TLS tunnel that has been established by the UE (MCX client) as specified by 3GPP TS 33.310 [70] to the HTTP Proxy as specified in 3GPP TS 33.180 [94] using the configured URL of the HTTP Proxy as specified in the "/<x>/OnNetwork/AppServerInfo/HTTPproxy" leaf node, Table 5.5.8.1-1.

11

The UE (MCX client) sends a HTTP POST message presenting the access token obtained in step 10 to the SS over HTTP for Key Management Initialisation.

NOTE: Step 11 is the start of the second stage which was started in Step 2. Steps 11 through 14 involve Key Management Authorization. The MCX Client/Key Management Client presents the access token to the Key Management Server. The end result is the user gets specific key material.

–>

HTTP POST

P

12

The SS replies to the UE with identity specific key information.

<–

HTTP 200 (OK)

13

The UE (MCX client) sends a HTTP POST message presenting an access token to the SS over HTTP for Key Material Request.

–>

HTTP POST

P

14

The SS replies to the UE with identity specific key information.

<–

HTTP 200 (OK)

15-32

Void

NOTE 1: Void.

NOTE 1A: Void.

NOTE 2: The UE is expected to prompt the MCX user for their username and password, or it may be stored on the UE. The provision of the username/password is expected to be done via a suitable implementation dependent MMI.

Table 5.3.2.3-1A: MCX Initial UE Configuration Request

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

1

The UE (MCX client) sends an HTTP GETrequestto retrieve the initial UE configuration from the Server

–>

HTTP GET (initial UE configuration)

P

2

The SS sends a HTTP 200 (OK) including the initial UE configuration document

<–

HTTP 200 (OK)

Table 5.3.2.3-2: MCX Service Authorization and Key Generation

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

EXCEPTION: In parallel to procedure of all steps below the behaviour of table 5.3.2.3-2A, the behaviour of table 5.3.2.3-2B and the behaviour of table 5.3.2.3-2C takes place.

EXCEPTION: Steps 1a1-1b2 describe behaviour that depends on UE implementation; the "lower case letter" identifies a step sequence that takes place when one or the other is the case.

NOTE: Step 1a1 is the start of the third stage which was started in Step 3 of table 5.3.2.3-1. Steps 1a1 and 1b1 involve User Service Authorization.

1a1

The UE (MCX client) sends a SIP REGISTER request for service authorisation.

–>

SIP REGISTER

P

1a2

The SS (MCX server) sends SIP 200 (OK).

NOTE: The user is now authorized for MCX service.

<–

SIP 200 (OK)

1a3

The UE (MCX client) sends a SIP PUBLISH request for update of PoC-settings (NOTE 1).

–>

SIP PUBLISH

P

1a4

The SS (MCX server) sends SIP 200 (OK).

<–

SIP 200 (OK)

1b1

The UE (MCX client) sends a SIP PUBLISH request for service authorisation and update of PoC-settings (NOTE 1).

–>

SIP PUBLISH

P

1b2

The SS (MCX server) sends SIP 200 (OK).

NOTE: The user is now authorized for MCX service.

<–

SIP 200 (OK)

NOTE 1: The PoC-settings document contains the user profile index of the selected user profile.
⇒ In general the UE sends the SIP PUBLISH request not before it has retrieved the user profile at step 8 in Table 5.3.2.3-2A.

Table 5.3.2.3-2A: Configuration management subscription and notification procedure

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

1

The UE (MCX client) sends a SIP SUBSCRIBE – subscription to multiple documents simultaneously – to the SS containing the access token and a resource list mime body containing a list of the following documents: MCX UE Configuration document, MCX User Profile Configuration Document, and the MCX Service configuration document. The base URI of each list entry is set to the CMS XCAP-ROOT-URI.

NOTE: Step 1 is the start of the fourth stage which was started in Step 3 of table 5.3.2.3-1. Steps 1 through 10 involve Configuration Management Authorization. The end result of the fourth stage is that the MCX Client receives 3 configuration documents: UE Configuration Document, User Profile Configuration Document, and the Service Configuration Document.

–>

SIP SUBSCRIBE

P

2

The SS sends a SIP 200 (OK) message.

<–

SIP 200 (OK)

3

The SS sends a SIP NOTIFY message to the UE that contains the XCAP-URI of the documents.

<–

SIP NOTIFY

EXCEPTION: The order of steps 4, 5, 7 and 9 depends on UE and SS implementation and is not checked by the implementation

4

The UE (MCX client) sends a SIP 200 (OK) message.

–>

SIP 200 (OK)

P

5

The UE (MCX client) sends an HTTP GET Request message to the SS that contains the access token and the XCAP-URI of the MCX UE Configuration Document.

NOTE: The MCX Client is requesting the MCX UE Configuration Document.

–>

HTTP GET

P

6

The SS sends the HTTP 200 (OK) message including the MCX UE Configuration Document.

<–

HTTP 200 (OK)

7

The UE (MCX client) sends an HTTP GET Request message to the SS that contains the access token and the XCAP-URI of the MCX User Profile Configuration Document.

NOTE: The MCX Client is requesting the MCX User Profile Configuration Document.

–>

HTTP GET

P

8

The SS sends the HTTP 200 (OK) message including the MCX User Profile Configuration Document.

NOTE: The MCX User Profile Configuration Document includes information on MCX groups including for which groups the MCX Client is a member. The MCX User Profile Configuration Document includes Group A as a group for which the MCX Client is a member and is implicitly affiliated. Group A is used as the default group for all test cases in TS 36.579-2 and TS 36.579-3.

<–

HTTP 200 (OK)

9

The UE (MCX client) sends an HTTP GET Request message to the SS that contains the access token and the XCAP-URI of the MCX Service Configuration Document.

NOTE: The MCX Client is requesting the MCX Service Configuration Document.

–>

HTTP GET

P

10

The SS sends the HTTP 200 (OK) message including the MCX Service Configuration Document.

<–

HTTP 200 (OK)

Table 5.3.2.3-2B: Group document subscription and notification procedure

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

1

The UE (MCX client) sends a SIP SUBSCRIBE to the SS, containing the access token and a resource list mime body and a list of the Groups to be obtained. The base URI of each list entry is set to the GMS XCAP-ROOT-URI, and the MCX group ID identifies a group document.

NOTE: Step 1 is the start of the fifth stage which was started in Step 2 of table 5.3.2.3-1. Steps 1 through 6 involve Group Management Authorization. The end result is the MCX Client will receive group information for Group A. The MCX Client will also get the Group Master Key (GMK) for the group which will be used to derive keys for the group. There will also be a Group User Key Identifier (GUK-ID), and a Group Master Key Identifier (GMK-ID). According TS 33.180 [94], clause 7.4.1, the GMK shall be used as the MIKEY Traffic Generating Key (TGK) and the GUK-ID shall be used as the MIKEY CSB ID. These shall be used to generate the SRTP Master Key and SRTP Master Salt as specified in IETF RFC 3830 [24].

–>

SIP SUBSCRIBE

P

2

The SS sends a SIP 200 (OK) message.

<–

SIP 200 (OK)

3

The SS sends a SIP NOTIFY message to the UE that contains the XCAP-URI of the Group documents.

<–

SIP NOTIFY

EXCEPTION: The order of steps 4 and 5 depends on UE and SS implementation and is not checked by the implementation

4

The UE (MCX client) sends a SIP 200 (OK) message.

–>

SIP 200 (OK)

P

5

The UE (MCX client) sends an HTTP GET Request message to the SS that contains the access token and the XCAP-URI of the Group Configuration document.

–>

HTTP GET

P

6

The SS sends the HTTP 200 (OK) message including the Group Document ‘MCX UE Configuration document’.

NOTE 1

<–

HTTP 200 (OK)

EXCEPTION: Steps 7a1-7a2 describe behaviour that depends on UE implementation; the "lower case letter" identifies a step sequence that takes place when one or the other is the case.

7a1

IF the Resource-Lists received from the UE at step 1 contains an entry referring to an MCX-GKTP document THEN the SS sends a SIP NOTIFY message to the UE containing the group key transport payloads (GKTP) document.

<–

SIP NOTIFY

7a2

The UE (MCX client) sends a SIP 200 (OK) message.

–>

SIP 200 (OK)

NOTE 1: This completes MCX service enabling on the UE.

Table 5.3.2.3-2C: Group communication key retrieval procedure

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

1

The SS starts timer Timer_1 = 5 seconds.

EXCEPTION: Steps 2a5-3a1 describe behaviour that depends on UE implementation; the "lower case letter" identifies a step sequence that takes place when one or the other is the case.

2a1

The UE (MCX client) sends a SIP SUBSCRIBE to the SS, creating a new dialog and containing the access token and a resource list mime body containing an entry to request group key transport payloads (GKTP) document.

–>

SIP SUBSCRIBE

P

2a2

The SS sends a SIP 200 (OK) message

<–

SIP 200 (OK)

2a3

The SS sends a SIP NOTIFY message to the UE containing the group key transport payloads (GKTP) document.

<–

SIP NOTIFY

2a4

The UE (MCX client) sends a SIP 200 (OK) message.

–>

SIP 200 (OK)

P

2a5

The SS stops Timer_1.

2b1

Timer_1 expires

NOTE: This key retrieval from the GMS is necessary for the MCX UE under test to enable ciphering exchanged media in group communications.

5.3.2.4 Specific message contents

Table 5.3.2.4-1: HTTP GET (Step 3a1, Table5.3.2.3-1 )

Derivation Path: Table 5.5.4.2-1, condition AUTH

Table 5.3.2.4-2: HTTP POST (Step 3b1, Table 5.3.2.3-1)

Derivation Path: Table 5.5.4.3-1, condition AUTH

Table 5.3.2.4-3: HTTP 200 (OK) (Step 4, Table 5.3.2.3-1)

Derivation Path: Table 5.5.4.6-1

Information Element

Value/remark

Comment

Reference

Condition

Content-Type

media-type

"text/html"

RFC 2854 [111]

Message-body

HTML form

<!DOCTYPE html>

<html>

<body>

<form action="/idms/userauth" method="post">

Username: <input type="text" name="user"><br>

Password: <input type="password" name="password"><button type="submit">Login</button>

</form>

</body>

</html>

"/idms/userauth" given by tsc_MCX_IdMS_userauth_UriPath is the URI to be used by the UE as request URI in the HTTP POST request for user authentication

HTML 4.01 Specification [105]

Table 5.3.2.4-4: HTTP POST (Step 6, Table 5.3.2.3-1)

Derivation Path: Table 5.5.4.3-1, condition USERAUTH

Table 5.3.2.4-5: HTTP 302 (Found) (Step 7, Table 5.3.2.3-1)

Derivation Path: Table 5.5.4.8-1, condition AUTH.

Table 5.3.2.4-6: HTTP POST (Step 9, Table 5.3.2.3-1)

Derivation Path: Table 5.5.4.3-1, condition TOKEN

Table 5.3.2.4-7: HTTP 200 (OK) (Step 10, Table 5.3.2.3-1)

Derivation Path: Table 5.5.4.6-1, condition TOKEN

Table 5.3.2.4-8: HTTP POST (Step 11, Table 5.3.2.3-1)

Derivation Path: Table 5.5.4.33-1, condition KMSINIT.

Table 5.3.2.4-9: HTTP 200 (OK) (Step 12, Table 5.3.2.3-1)

Derivation Path: Table 5.5.4.6-1, condition KMSINIT.

Table 5.3.2.4-10: HTTP POST (Step 13, Table 5.3.2.3-1)

Derivation Path: Table 5.5.4.3-1, condition KMSKEY.

Table 5.3.2.4-11: HTTP 200 (OK) (Step 14, Table 5.3.2.3-1)

Derivation Path: Table 5.5.4.6-1, condition KMSKEY.

Table 5.3.2.4-12: SIP REGISTER (Step 1a1, Table 5.3.2.3-2)

Derivation Path: Table 5.5.2.13-1, condition CONFIG

Table 5.3.2.4-13: SIP PUBLISH (Step 1b1, Table 5.3.2.3-2)

Derivation Path: Table 5.5.2.11-1, condition CONFIG

Table 5.3.2.4-13A: SIP PUBLISH (Step 1a3, Table 5.3.2.3-2)

Derivation Path: Table 5.5.2.11-1, condition POC-SETTINGS-EVENT

Table 5.3.2.4-14: SIP SUBSCRIBE (Step 1, Table 5.3.2.3-2A)

Derivation Path: Table 5.5.2.14-1, condition CONFIG

Table 5.3.2.4-15: SIP NOTIFY (Step 3, Table 5.3.2.3-2A)

Derivation Path: Table 5.5.2.8-1, condition CONFIG

Table 5.3.2.4-16: HTTP GET (Step 5, Table 5.3.2.3-2A)

Derivation Path: Table 5.5.4.2-1, condition UECONFIG.

Table 5.3.2.4-17: HTTP GET (Step 7, Table 5.3.2.3-2A)

Derivation Path: Table 5.5.4.2-1, condition UEUSERPROF.

Table 5.3.2.4-18: HTTP GET (Step 9, Table 5.3.2.3-2A)

Derivation Path: Table 5.5.4.2-1, condition UESERVCONFIG.

Table 5.3.2.4-19: HTTP 200 (OK) (Step 6, Table 5.3.2.3-2A)

Derivation Path: Table 5.5.4.6-1, condition UECONFIG.

Table 5.3.2.4-20: HTTP 200 (OK) (Step 8, Table 5.3.2.3-2A)

Derivation Path: Table 5.5.4.6-1, condition UEUSERPROF.

Table 5.3.2.4-21: HTTP 200 (OK) (Step 10, Table 5.3.2.3-2A)

Derivation Path: Table 5.5.4.6-1, condition UESERVCONFIG.

Table 5.3.2.4-22: SIP SUBSCRIBE (Step 1, Table 5.3.2.3-2B)

Derivation Path: Table 5.5.2.14-1, condition GROUPCONFIG

Table 5.3.2.4-22A: Void

Table 5.3.2.4-22B: SIP NOTIFY (Step 3, Table 5.3.2.3-2B)

Derivation Path: Table 5.5.2.8-1, condition GROUPCONFIG

Table 5.3.2.4-23: HTTP GET (Step 5, Table 5.3.2.3-2B)

Derivation Path: Table 5.5.4.2-1, condition GROUPCONFIG

Table 5.3.2.4-24: HTTP 200 (OK) (Step 6, Table 5.3.2.3-2B)

Derivation Path: Table 5.5.4.6-1, condition GROUPCONFIG.

Table 5.3.2.4-25: Void

Table 5.3.2.4-26: SIP 200 (OK) (Steps 1a2, 1a4, 1b2, Table 5.3.2.3-2, step 2, Table 5.3.2.3-2A, step 2, Table 5.3.2.3-2B)

Derivation Path: Table 5.5.2.17.1.2-1

Table 5.3.2.4-27: SIP 200 (OK) (Step 4, Table 5.3.2.3-2A, step 4, Table 5.3.2.3-2B)

Derivation Path: Table 5.5.2.17.1.1-1

Table 5.3.2.4-28: HTTP GET (Step 1, Table 5.3.2.3-1A)

Derivation Path: Table 5.5.4.2-1, condition UEINITIALCONFIG

Table 5.3.2.4-29: HTTP 200 (OK) (Step 2, Table 5.3.2.3-1A)

Derivation Path: Table 5.5.4.6-1, condition UEINITIALCONFIG

Table 5.3.2.4-30: SIP SUBSCRIBE (Step 1, Table 5.3.2.3-2C)

Derivation Path: Table 5.5.2.14-1, condition GROUPCONFIG

Message-body

MIME body part

Resource-lists

MIME-part-headers

Content-Type

"application/resource-lists+xml"

MIME-part-body

Resource-lists as described in Table 5.3.2.4-31

Table 5.3.2.4-31: Resource-Lists in SIP SUBSCRIBE (Table 5.3.2.4-30)

Derivation Path: Table 5.5.3.3.1-1 condition GROUPKEY

Table 5.3.2.4-32: SIP NOTIFY (Step 7a, Table 5.3.2.3-2B and Step 3, Table 5.3.2.3-2C)

Derivation Path: Table 5.5.2.14-1, condition GROUPCONFIG

Message-body

xcap-diff document

xcap-diff document as described in Table 5.3.2.4-33

Table 5.3.2.4-33: Xcap-Diff Document (Table 5.3.2.4-32)

Derivation Path: Table5.5.3.12-2, condition GROUPKEY

5.3.2A – 5.3.2B Void

5.3.3 MCX pre-established session establishment CO

5.3.3.1 Initial conditions

Within the context of this procedure, MCX refers to MCPTT, MCVideo or MCData.

System Simulator:

– SS (MCX 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 [6] clause 4.4. The simulated Cell 1 shall belong to PLMN1 (the PLMN specified for MCX operation in the MCX configuration document)

IUT:

– UE (MCX client)

– The UE has performed the procedure for MCX Authorization/Configuration and Key Generation as specified in clause 5.3.2 and thereby the MCX client is authorised for and able to use the MCX service including making group and private calls on- and off-network, and, the MCX user is registered for receiving MCX service through the MCX Client.

5.3.3.2 Definition of system information messages

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

5.3.3.3 Procedure

Table 5.3.3.3-1: MCX pre-established session establishment CO

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

1

Void

1A

EXCEPTION: The E-UTRA/EPC actions which are related to the MCX call establishment as described in clause 5.4.3 ‘Generic Test Procedure for MCX CO communication in E-UTRA’ take place.

2-7

Void

8

Check: Does the UE (MCX Client) send a SIP INVITE message in order to create a pre-established session?

–>

SIP INVITE

P

8A

The SS sends SIP 100 Trying

<–

SIP 100 Trying

9

Void

10

The SS (MCX server) responds with a SIP 200 (OK) message.

<–

SIP 200 (OK)

10A

Check: Does the UE (MCX Client) respond with a SIP ACK message?

–>

SIP ACK

P

11

Void

11A

The SS waits 2 seconds to ensure that lower layer signalling (TCP) is finished.

12

The SS transmits an RRCConnectionRelease message.

<–

RRC: RRCConnectionRelease

5.3.3.4 Specific message contents

Table 5.3.3.4-1: SIP INVITE (step 8, Table 5.3.3.3-1)

Derivation Path: Table 5.5.2.5.1-1

Information Element

Value/remark

Comment

Reference

Condition

Contact

RFC 3261 [22

RFC 3840 [33]

feature-param

"+g.3gpp.mcptt"

This media feature tag when used in a SIP request or a SIP response indicates that the function sending the SIP message supports Mission Critical Push To Talk (MCPTT) communication.

feature-param

"audio"

This feature tag indicates that the device supports audio as a streaming media type.

Accept

RFC 3261 [22]

media-range[1]

"application/sdp”

Answer-Mode

not present

Content-Type

media-type

"application/sdp"

Message-body

SDP Message

SDP message as described in Table 5.5.3.1.1-1 with conditions PRE_ESTABLISHED_SESSION, INITIAL_SDP_OFFER

Table 5.3.3.4-2: SIP 200 (OK) (step 10, Table 5.3.3.3-1)

Derivation Path: Table 5.5.2.17.1.2-1 with condition INVITE-RSP

Information Element

Value/remark

Comment

Reference

Condition

Contact

addr-spec

user-info and host

tsc_MCX_SessionID_B

The URI that identifies the pre-established session

5.3.3A Void

5.3.4 MCX CT session establishment/modification without provisional responses other than 100 Trying

5.3.4.1 Initial conditions

As specified in the test case which calls the procedure in its entirety or refers to parts of it.

Within the context of this procedure, MCX refers to MCPTT, MCVideo or MCData.

5.3.4.2 Definition of system information messages

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

5.3.4.3 Procedure

Table 5.3.4.3-1: MCX CT session establishment/modification without provisional responses other than 100 Trying

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 are related to the MCX call establishment as 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/modification of an MCX 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 SIP 100 (Trying)

–>

SIP 100 (Trying)

4

Check: Does the UE (MCX client) respond to the SIP INVITE with SIP 200 (OK)?

–>

SIP 200 (OK)

P

5

The SS (MCX server) sends a SIP ACK to acknowledge the session establishment/modification

<–

SIP ACK

5.3.4.4 Specific message contents

All message contents are as specified in clause 5.5 with the following clarifications:

none

Table 5.3.4.4-1: Void

5.3.5 MCX CT group call establishment, manual commencement

5.3.5.1 Initial conditions

As specified in the test case which calls the procedure in its entirety or refers to parts of it.

Within the context of this procedure, MCX refers to MCPTT, MCVideo or MCData.

5.3.5.2 Definition of system information messages

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

5.3.5.3 Procedure

Table 5.3.5.3-1: MCX CT group call establishment, manual commencement

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

EXCEPTION: Steps 1a1describes 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 are related to the MCX call establishment described in clause 5.4.4 ‘Generic Test Procedure for MCX CT communication in E-UTRA’ take place.

2

The SS (MCX Server) sends an initial SIP INVITE requesting the establishment of an MCX group 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 SIP 100 (Trying).

–>

SIP 100 (Trying)

4

The SS starts timer Timer_1 = 5 seconds.

EXCEPTION: Steps 5a1 to 5c1 describe behaviour that depends on the UE implementation; the "lower case letter" identifies a step sequence that may take place if the UE responds reliably or unreliably to a SIP INVITE with a SIP 183 (Session Progress)

5a1

Check: Does the UE (MCX client) send SIP 183 (Session Progress) unreliably?

–>

SIP 183 (Session Progress)

P

5a2

The SS stops Timer_1.

5b1

Check: Does the UE (MCX client) send SIP 183 (Session Progress) reliably?

–>

SIP 183 (Session Progress)

P

5b2

The SS stops Timer_1.

5b3

The SS (MCX Server) acknowledges the receipt of SIP 183 (Session Progress)

<–

PRACK

5b4

The UE (MCX Client) responds PRACK with SIP 200 (OK)

–>

SIP 200 (OK)

5c1

Check: Does Timer_1 expire?

P

5A

Check: Does the UE (MCX client) notify the User of the incoming call request? (NOTE 1)

P

6

Make UE (MCX User) accept the call (NOTE 1)

7

Check: Does the UE (MCX client) respond to the SIP INVITE with SIP 200 (OK)?

–>

SIP 200 (OK)

P

8

The SS (MCX server) sends a SIP ACK to acknowledge the session establishment

<–

SIP ACK

NOTE 1: This expected to be done via a suitable implementation dependent MMI.

5.3.5.4 Specific message contents

All message contents are as specified in clause 5.5 with condition GROUP-CALL where applicable and with the following clarifications:

Table 5.3.5.4-1 to 3: Void

5.3.6 MCX CT private call establishment, manual commencement

5.3.6.1 Initial conditions

The same initial conditions apply as specified in clause 5.3.3.1.

Within the context of this procedure, MCX refers to MCPTT or MCVideo

5.3.6.2 Definition of system information messages

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

5.3.6.3 Procedure

Table 5.3.6.3-1: MCX CT private call establishment, manual commencement

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 are related to the MCX call establishment described in clause 5.4.4 ‘Generic Test Procedure for MCX CT communication in E-UTRA’ take place.

2

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

<–

SIP INVITE

EXCEPTION: Step3a1 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 SIP 100 (Trying).

–>

SIP 100 (Trying)

EXCEPTION: Steps 4a1 to 4b3 describe behaviour that depends on the UE implementation; the "lower case letter" identifies a step sequence that takes place if the UE responds either unreliably or reliably to a SIP INVITE with a SIP 180 (Ringing)

4a1

Check: Does the UE (MCX client) send a SIP 180 (Ringing) unreliably?

–>

SIP 180 (Ringing)

P

4b1

Check: Does the UE (MCX client) send a SIP 180 (Ringing) reliably?

–>

SIP 180 (Ringing)

P

4b2

The SS (MCX Server) acknowledges the receipt of SIP 180 (Ringing)

<–

PRACK

4b3

The UE (MCX Client) responds PRACK with SIP 200 (OK)

–>

SIP 200 (OK)

4A

Check: Does the UE (MCX client) notify the User of the incoming call request? (NOTE 1)

P

5

Make UE (MCX User) accept the call

6

Check: Does the UE (MCX client) respond to the SIP INVITE with SIP 200 (OK)?

–>

SIP 200 (OK)

P

7

The SS (MCX server) sends a SIP ACK to acknowledge the session establishment

<–

SIP ACK

NOTE 1: This expected to be done via a suitable implementation dependent MMI.

5.3.6.4 Specific message contents

All message contents are as specified in clause 5.5 with condition PRIVATE-CALL where applicable and in the test case calling the procedure, with the following clarifications:

Table 5.3.6.4-1 to 1A: Void

Table 5.3.6.4-2: SIP 180 (Ringing) (step 4b1, Table 5.3.6.3-1)

Derivation Path: Table 5.5.2.16.2.1-1 with condition 100rel

Table 5.3.6.4-3: Void

5.3.7 to 5.3.9 Void

5.3.10 MCX CO call release

5.3.10.1 Initial conditions

As specified in the test case which calls the procedure.

Within the context of this procedure, MCX refers to MCPTT, MCVideo or MCData.

5.3.10.2 Definition of system information messages

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

5.3.10.3 Procedure

Table 5.3.10.3-1: MCX CO call release

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

1

Check: Does the UE (MCX Client) send a SIP BYE request to terminate the MCX session?

–>

SIP BYE

P

2

The SS (MCX Server) responds with a SIP 200 (OK) message?

<–

SIP 200 (OK)

3

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

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

5.3.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.3.11 Void

5.3.12 MCX CT call release

5.3.12.1 Initial conditions

As specified in the test case which calls the procedure.

Within the context of this procedure, MCX refers to MCPTT, MCVideo or MCData.

5.3.12.2 Definition of system information messages

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

5.3.12.3 Procedure

Table 5.3.12.3-1: MCX CT call release

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

1

The SS (MCX Server) sends a SIP BYE request to terminate the MCX session.

<–

SIP BYE

2

Check: Does the UE (MCX Client) respond with a SIP 200 (OK) message?

–>

SIP 200 (OK)

P

3

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

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

5.3.12.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.3.13 – 21 Void

5.3.22 MCX NW initiated notifications regarding temporary group creation or tear down

5.3.22.1 Initial conditions

As specified in the test case which calls the procedure in its entirety or refers to parts of it.

Within the context of this procedure, MCX refers to MCPTT, MCVideo or MCData.

5.3.22.2 Definition of system information messages

5.3.22.3 Procedure

Table 5.3.22.3-1: MCX NW initiated notifications regarding temporary group creation or tear down

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

1

The SS (MCX server) sends a SIP NOTIFY to the UE informing about change of group A’s configuration document.

<–

SIP NOTIFY

2

The UE sends a SIP 200 (OK) message to the SS.

–>

SIP 200 (OK)

2A-2F

Void

3

The UE (MCX client) sends an HTTP GET Request message to the SS that contains the access token and the XCAP-URI of the Group Configuration document.

–>

HTTP GET

4

The SS (MCX server) sends the HTTP 200 (OK) message including the updated Group Document

<–

HTTP 200 (OK)

5

The SS (MCX server) sends a SIP NOTIFY message to the UE containing the group key transport payloads (GKTP) document including the group keys.

<-

SIP NOTIFY

5a1-5a2

Void

6

The UE (MCX client) sends a SIP 200 (OK) message.

–>

SIP 200 (OK)

5.3.22.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.3.22.4-1: SIP NOTIFY (Step 1)

Derivation Path: Table 5.5.2.8-1, condition GROUPCONFIG

Information Element

Value/remark

Comment

Reference

Condition

Message-body

MIME body part

xcap-diff

MIME-part-body

Xcap-diff as described in Table 5.3.22.4-1A

Table 5.3.22.4-1A: Xcap-diff document in SIP NOTIFY (Table 5.3.22.4-1)

Derivation Path: Table 5.5.3.12-2, condition GROUPCONFIG

Table 5.3.22.4-2: SIP 200 (OK) (Steps 2, 6)

Derivation Path: Table 5.5.2.17.1.1-1

Table 5.3.22.4-2A..2G: Void

Table 5.3.22.4-3: HTTP GET (Step 3)

Derivation Path: Table 5.5.4.2-1, condition GROUPCONFIG

Table 5.3.22.4-4: HTTP 200 (OK) (Step 4)

Derivation Path: Table 5.5.4.6-1, condition GROUPCONFIG

Information Element

Value/remark

Comment

Reference

Condition

Message-body

group-configuration

As described in Table 5.3.22.4-5

Group Configuration document returned

Table 5.3.22.4-5: Group Configuration document (Table 5.3.22.4-4)

Derivation Path: Table 5.5.7.4-2

Information Element

Value/remark

Comment

Reference

Condition

list-service[1]

mcpttgi:on-network-regrouped

TS 24.481 [31] clause 7.2.4.2

TEMPGROUPCREATE

temporary-MCPTT-group-ID attribute

px_MCPTT_Group_T_ID

MCS temporary group identity

TS 24.481 [31] clause 7.2.4.2

MCPTT

px_MCVideo_Group_T_ID

MCVIDEO

px_MCData_Group_T_ID

MCDATA

temporary-MCPTT-group-requestor attribute

px_MCPTT_ID_User_B

Identity of the responsible for formatting the MCS temporary group.

TS 24.481 [31] clause 7.2.4.2

MCPTT

px_MCVideo_ID_User_B

MCVIDEO

px_MCData_ID_User_B

MCDATA

constituent-MCPTT-group-IDs

TS 24.481 [31] clause 7.2.4.2

constituent-MCPTT-group-ID[1]

px_MCPTT_Group_A_ID

MCS group ID of a constituent MCS group of the temporary MCS group

TS 24.481 [31] clause 7.2.4.2

MCPTT

px_MCVideo_Group_A_ID

MCVIDEO

px_MCData_Group_A_ID

MCDATA

constituent-MCPTT-group-ID[1]

px_MCPTT_Group_B_ID

MCS group ID of a constituent MCS group of the temporary MCS group

TS 24.481 [31] clause 7.2.4.2

MCPTT

px_MCVideo_Group_B_ID

MCVIDEO

px_MCData_Group_B_ID

MCDATA

protect-media

"true"

Indicates whether confidentiality and integrity of media is required on the MCPTT temporary group

TS 24.481 [31] clause 7.2.4.2

protect-floor-control-signalling

"true"

Indicates whether confidentiality and integrity of floor control signalling is required on the temporary MCPTT group

TS 24.481 [31] clause 7.2.4.2

Condition

Explanation

TEMPGROUPCREATE

Procedure is used for creation of a temporary group (but not for tear down)

Table 5.3.22.4-5A: Void

Table 5.3.22.4-6: SIP NOTIFY (Step 5)

Derivation Path: Table 5.5.2.14-1, condition GROUPCONFIG

Message-body

xcap-diff document

xcap-diff document as described in Table 5.3.22.4-7

Table 5.3.22.4-7: xcap-diff document for MCX group configuration (Table5.3.22.4-6)

Derivation Path: Table 5.5.3.12-2, condition GROUPKEY

Information Element

Value/remark

Comment

Reference

Condition

xcap-diff

encrypted according to NOTE 1 of Table 5.5.3.12-2

element[1]

sel attribute

Doc-Sel & "~~" & Node-Sel

Document and node selector for Group T according to NOTEs 2a, 2b and 3 of Table 5.5.3.12-2

GKTPs

group key transport payloads (GKTP) document as described in Table 5.3.22.4-8

Table 5.3.22.4-8: group key transport payloads (GKTP) document (Table 5.3.22.4-7)

Derivation Path: TS 24.481 [11] clause 7.7

Information Element

Value/remark

Comment

Reference

Condition

GKTPs

GMK-GKTPs

GKTP[1]

MIKEY message as used in group communication key retrieval procedure

MIKEY message containing the GMK for Group A

TS 33.180 [94]

id attribute

Same value as used in group communication key retrieval procedure

on-network-regrouped-GKTPs[1]

TEMPGROUPCREATE

temporary-MCPTT-group-ID attribute

px_MCPTT_Group_T_ID

MCPTT

px_MCVideo_Group_T_ID

MCVIDEO

px_MCData_Group_T_ID

MCDATA

GKTP[1]

MIKEY message as described in Table 5.3.22.4-9

MIKEY message containing the GMK for Group T

TS 33.180 [94]

id attribute

arbitrary value

unique charstring assigned by the SS

Condition

Explanation

TEMPGROUPCREATE

Procedure is used for creation of a temporary group (but not for tear down)

Table 5.3.22.4-9: MIKEY-SAKKE I_MESSAGE (GMK distribution by the SS) (Table 5.3.22.4-8)

Derivation Path: Table 5.5.9.1-3

Field

Value/remark

Comment

Condition

General Extension Payload {

Content {

Payload {

Data {

See TS 33.180 [94] clause E.6

Group IDs {

Number of Group IDs

‘1’

Group ID

px_MCPTT_Group_T_ID

The ID for the group associated with the key.

MCPTT

px_MCVideo_Group_T_ID

MCVIDEO

px_MCData_Group_T_ID

MCDATA

}

}

}

..}

}

5.3.23 – 25 Void

5.3.26 MCX CO Group Creation

5.3.26.1 Initial conditions

As specified in the test case which calls the procedure.

Within the context of this procedure, MCX refers to MCPTT, MCVideo or MCData.

5.3.26.2 Definition of system information messages

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

5.3.26.3 Procedure

Table 5.3.26.3-1: MCX CO Group Creation procedure

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

1a1-1a2

Void

1

Check: Does the UE (MCX Client) send a HTTP PUT to the SS to request for creation of the new group?

–>

HTTP PUT

P

2

The SS (MCX Server) sends a HTTP 201 (Created).

<–

HTTP 201 (Created)

3-5

Void

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

Table 5.3.26.4-1 to -5: Void

5.3.27 MCX CO Temporary Group Creation

5.3.27.1 Initial conditions

As specified in the test case which calls the procedure.

Within the context of this procedure, MCX refers to MCPTT, MCVideo or MCData.

5.3.27.2 Definition of system information messages

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

5.3.27.3 Procedure

Table 5.3.27.3-1: MCX CO Temporary Group Creation procedure

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

1

Check: Does the UE (MCX Client) send a HTTP POST to the SS to request for creation of a temporary group?

–>

HTTP POST

P

2

The SS (MCX Server) sends a HTTP 200 (OK) containing the GMOP group-regroup-creation-response.

<–

HTTP 200 (OK)

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

Table 5.3.27.4-1 to -2: Void

5.3.28 MCX CO Temporary Group Tear Down

5.3.28.1 Initial conditions

As specified in the test case which calls the procedure.

Within the context of this procedure, MCX refers to MCPTT, MCVideo or MCData.

5.3.28.2 Definition of system information messages

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

5.3.28.3 Procedure

Table 5.3.28.3-1: MCX CO Temporary Group Creation procedure

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

1

Check: Does the UE (MCX Client) send a HTTP DELETE to the SS to request for tear down of a temporary group?

–>

HTTP DELETE

P

2

The SS (MCX Server) sends a HTTP 200 (OK).

<–

HTTP 200 (OK)

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

Table 5.3.28.4-1: Void

5.3.29 MCX Subscription and Notification

5.3.29.1 Initial conditions

As specified in the test case which calls the procedure in its entirety or refers to parts of it.

Within the context of this procedure, MCX refers to MCPTT, MCVideo or MCData.

5.3.29.2 Definition of system information messages

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

5.3.29.3 Procedure

Table 5.3.29.3-1: MCX Subscription and Notification

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 are related to the MCX call establishment described in clause 5.4.3 ‘Generic Test Procedure for MCX CO communication in E-UTRA’ take place.

2

Check: Does the UE (MCX Client) send a SIP SUBSCRIBE message request?

–>

SIP SUBSCRIBE

P

3

The SS (MCX Server) responds to the SIP SUBSCRIBE message with a SIP 200 (OK) message.

<–

SIP 200 (OK)

4

The SS (MCX Server) sends a SIP NOTIFY message

<–

SIP NOTIFY

5

The UE (MCX Client) responds with a SIP 200 (OK) message.

–>

SIP 200 (OK)

6

SS (MCX Server) releases the E-UTRA connection.

5.3.29.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.3.30 MCX SIP MESSAGE Request – Accept CO

5.3.30.1 Initial conditions

As specified in the test case which calls the procedure.

Within the context of this procedure, MCX refers to MCPTT or MCVideo

5.3.30.2 Definition of system information messages

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

5.3.30.3 Procedure

Table 5.3.30.3-1: MCX SIP MESSAGE Request – Accept CO

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 are related to the MCX call establishment as described in clause 5.4.3 ‘Generic Test Procedure for MCX CO communication in E-UTRA’ take place.

2

Check: Does the UE (MCX Client) send a SIP MESSAGE message?

–>

SIP MESSAGE

P

3

The SS (MCX Server) responds with a SIP 200 (OK) message?

<–

SIP 200 (OK)

4

The SS (MCX server) sends SIP MESSAGE accepting the request.

<–

SIP MESSAGE

5

Check: Does the UE (MCX Client) respond with a SIP 200 (OK) message?

–>

SIP 200 (OK)

P

6

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

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

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

5.3.30.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.3.31 MCX SIP MESSAGE Request – Accept CT

5.3.31.1 Initial conditions

As specified in the test case which calls the procedure.

Within the context of this procedure, MCX refers to MCPTT or MCVideo

5.3.31.2 Definition of system information messages

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

5.3.31.3 Procedure

Table 5.3.31.3-1: MCX SIP MESSAGE Request – Accept CT

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 are related to the MCX call establishment as described in clause 5.4.3 ‘Generic Test Procedure for MCX CO communication in E-UTRA’ take place.

2

The SS (MCX server) sends SIP MESSAGE

<–

SIP MESSAGE

3

Check: Does the UE (MCX Client) respond with a SIP 200 (OK) message?

–>

SIP 200 (OK)

P

4

Check: Does the UE (MCX Client) send a SIP MESSAGE message?

–>

SIP MESSAGE

P

5

The SS (MCX Server) responds with a SIP 200 (OK) message?

<–

SIP 200 (OK)

6

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

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

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

5.3.31.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.3.32 MCX SIP MESSAGE CO

5.3.32.1 Initial conditions

As specified in the test case which calls the procedure.

Within the context of this procedure, MCX refers to MCPTT, MCVideo or MCData

5.3.32.2 Definition of system information messages

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

5.3.32.3 Procedure

Table 5.3.32.3-1: MCX SIP MESSAGE CO

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 are related to the MCX call establishment as described in clause 5.4.3 ‘Generic Test Procedure for MCX CO communication in E-UTRA’ take place.

2

Check: Does the UE (MCX Client) send a SIP MESSAGE message?

–>

SIP MESSAGE

P

3

The SS (MCX Server) responds with a SIP 200 (OK) message?

<–

SIP 200 (OK)

4

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

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

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

5.3.32.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.3.33 MCX SIP MESSAGE CT

5.3.33.1 Initial conditions

As specified in the test case which calls the procedure.

Within the context of this procedure, MCX refers to MCPTT, MCVideo or MCData

5.3.33.2 Definition of system information messages

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

5.3.33.3 Procedure

Table 5.3.33.3-1: MCX SIP MESSAGE CT

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 are related to the MCX call establishment as described in clause 5.4.4 ‘Generic Test Procedure for MCX CT communication in E-UTRA’ take place.

2

The SS (MCX server) sends SIP MESSAGE

<–

SIP MESSAGE

3

Check: Does the UE (MCX Client) respond with a SIP 200 (OK) message?

–>

SIP 200 (OK)

P

4

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

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

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

5.3.33.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.3.34 MCX Group Affiliation Status Change

5.3.34.1 Initial conditions

As specified in the test case which calls the procedure.

Within the context of this procedure, MCX refers to MCPTT, MCVideo or MCData

5.3.34.2 Definition of system information messages

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

5.3.34.3 Procedure

Table 5.3.34.3-1: MCX Group Affiliation Status Change

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 are related to the MCX call establishment as described in clause 5.4.4 ‘Generic Test Procedure for MCX CT communication in E-UTRA’ take place.

2

Check: Does the UE (MCX Client) send a SIP PUBLISH message?

–>

SIP PUBLISH

P

3

The SS responds to the SIP PUBLISH message with a SIP 200 (OK) message.

<–

SIP 200 (OK)

4

The SS sends a SIP NOTIFY message informing about the status change progress.

<–

SIP NOTIFY

5

The UE responds with a SIP 200 (OK)

–>

SIP 200 (OK)

6

The SS sends a SIP NOTIFY informing about the affiliation status of the user.

<–

SIP NOTIFY

7

The UE responds with a SIP 200 (OK)

–>

SIP 200 (OK)

8

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

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

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

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