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 Generic Test Procedure for MCPTT Authorization/Configuration and Key Generation

5.3.2.1 Initial conditions

System Simulator:

– SS (MCPTT 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 MCPTT operation in the MCPTT configuration document).

Implementation Under Test (IUT):

– UE (MCPTT client)

– The MCPTT 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 MCPTT UE initial configuration management object (MO) and the default MCPTT 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_MCPTT_User_A_username, px_MCPTT_User_A_password as provided in TS 36.579-5 [5], Table 9.2-1: MCPTT 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: MCPTT user authentication

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

1

Void

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 (MCPTT 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 (MCPTT client) sends an OpenID Connect Authentication Request using HTTP GET.

–>

HTTP GET (Authorization)

P

3b1

The UE (MCPTT 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 (MCPTT 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 (MCPTT 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 (MCPTT 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 (MCPTT 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 (MCPTT 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 MCPTT 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 (MCPTT 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 MCPTT 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: MCPTT Initial UE Configuration Request

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

1

The UE (MCPTT 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: MCPTT 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 (MCPTT client) sends a SIP REGISTER request for service authorisation.

–>

SIP REGISTER

P

1a2

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

NOTE: The user is now authorized for MCPTT service.

<–

SIP 200 (OK)

1a3

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

–>

SIP PUBLISH

P

1a4

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

<–

SIP 200 (OK)

1b1

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

–>

SIP PUBLISH

P

1b2

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

NOTE: The user is now authorized for MCPTT 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 (MCPTT 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: MCPTT UE Configuration document, MCPTT User Profile Configuration Document, and the MCPTT 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 MCPTT 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 (MCPTT client) sends a SIP 200 (OK) message.

–>

SIP 200 (OK)

P

5

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

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

–>

HTTP GET

P

6

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

<–

HTTP 200 (OK)

7

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

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

–>

HTTP GET

P

8

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

NOTE: The MCPTT User Profile Configuration Document includes information on MCPTT groups including for which groups the MCPTT Client is a member. The MCPTT User Profile Configuration Document includes Group A as a group for which the MCPTT 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 (MCPTT client) sends an HTTP GET Request message to the SS that contains the access token and the XCAP-URI of the MCPTT Service Configuration Document.

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

–>

HTTP GET

P

10

The SS sends the HTTP 200 (OK) message including the MCPTT 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 (MCPTT 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 MCPTT 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 MCPTT Client will receive group information for Group A. The MCPTT 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 (MCPTT client) sends a SIP 200 (OK) message.

–>

SIP 200 (OK)

P

5

The UE (MCPTT 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 ‘MCPTT 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 MCPTT-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 (MCPTT client) sends a SIP 200 (OK) message.

–>

SIP 200 (OK)

NOTE 1: This completes MCPTT 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 (MCPTT 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 (MCPTT 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: VoidTable 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 Generic Test Procedure for MCVideo Authorization/Configuration and Key Generation

The same as the procedure described in 5.3.2 with the following exception(s):

– The term "MCPTT" is replaced with "MCVideo"

– FFS

5.3.2B Generic Test Procedure for MCData Authorization/Configuration and Key Generation

FFS

5.3.3 Generic Test Procedure for MCPTT pre-established session establishment CO

5.3.3.1 Initial conditions

System Simulator:

– SS (MCPTT 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 MCPTT operation in the MCPTT configuration document)

IUT:

– UE (MCPTT client)

– The UE has performed the Generic Test Procedure for MCPTT Authorization/Configuration and Key Generation as specified in clause 5.3.2 and thereby the MCPTT client is authorised for and able to use the MCPTT service including making group and private calls on- and off-network, and, the MCPTT user is registered for receiving MCPTT service through the MCPTT 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: MCPTT pre-established session establishment CO

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

1

Void

1A

E-UTRA/EPC signalling according to steps 2 – 8 of clause 5.4.13 ‘Generic Test Procedure for MCPTT radio bearer establishment for use of pre-established session’ takes place

2-7

Void

8

Check: Does the UE (MCPTT 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 (MCPTT server) responds with a SIP 200 (OK) message.

<–

SIP 200 (OK)

10A

Check: Does the UE (MCPTT 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”

Accept-Contact

RFC 3841 [29]

ac-value[1]

feature-param

"+g.3gpp.mcptt"

req-param

"require"

explicit-param

"explicit"

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, 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 Generic Test Procedure for MCVideo pre-established session establishment CO

The same as the procedure described in 5.3.3 with the following exception(s):

– The term "MCPTT" is replaced with "MCVideo"

5.3.4 Generic Test Procedure for MCPTT 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.

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: MCPTT 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 MCPTT call establishment described in clause 5.4.4 ‘Generic Test Procedure for MCPTT CT communication in E-UTRA’ take place.

2

The SS (MCPTT Server) sends a SIP INVITE requesting the establishment/modification of an MCPTT 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 (MCPTT client) sends SIP 100 (Trying)

–>

SIP 100 (Trying)

4

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

–>

SIP 200 (OK)

P

5

The SS (MCPTT 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:

Table 5.3.4.4-1: SIP 200 (OK) (step 4, Table 5.3.4.3-1)

Derivation Path: Table 5.5.2.17.1.1-1 with condition INVITE-RSP and MCPTT

5.3.5 Generic Test Procedure for MCPTT 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.

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: MCPTT CT group call establishment, manual commencement

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

EXCEPTION: Steps 1a1-1b1 describe 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 MCPTT call establishment described in clause 5.4.4 ‘Generic Test Procedure for MCPTT CT communication in E-UTRA’ take place.

1b1

IF in RRC_IDLE state having a pre-established session, the E-UTRA/EPC actions which are related to the MCPTT call establishment described in clause 5.4.13 Generic Test Procedure for MCPTT radio bearer establishment for use of pre-established session’ take place.

2

The SS (MCPTT Server) sends an initial SIP INVITE requesting the establishment of an MCPTT 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 (MCPTT 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 (MCPTT client) send SIP 183 (Session Progress) unreliably?

–>

SIP 183 (Session Progress)

P

5a2

The SS stops Timer_1.

5b1

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

–>

SIP 183 (Session Progress)

P

5b2

The SS stops Timer_1.

5b3

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

<–

PRACK

5b4

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

–>

SIP 200 (OK)

5c1

Check: Does Timer_1 expire?

P

5A

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

P

6

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

7

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

–>

SIP 200 (OK)

P

8

The SS (MCPTT 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: SIP INVITE (step 2, Table 5.3.5.3-1)

Derivation Path: Table 5.5.2.5.2-1 with condition MANUAL and GROUP-CALL and MCPTT

Table 5.3.5.4-1A: SIP 183 (Session Progress) (step 5a1, Table 5.3.5.3-1)

Derivation Path: Table 5.5.2.16.3.1-1 with condition MCPTT

Table 5.3.5.4-2: SIP 183 (Session Progress) (step 5b1, Table 5.3.5.3-1)

Derivation Path: Table 5.5.2.16.3.1-1 with condition 100rel and MCPTT

Table 5.3.5.4-3: SIP 200 (OK) (step 7, Table 5.3.5.3-1)

Derivation Path: Table 5.5.2.17.1.1-1 with condition INVITE-RSP and MCPTT

5.3.6 Generic Test Procedure for MCPTT 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.

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: MCPTT 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 MCPTT call establishment described in clause 5.4.4 ‘Generic Test Procedure for MCPTT CT communication in E-UTRA’ take place.

2

The SS (MCPTT Server) sends an initial SIP INVITE requesting the establishment of an MCPTT 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 (MCPTT 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 (MCPTT client) send a SIP 180 (Ringing) unreliably?

–>

SIP 180 (Ringing)

P

4b1

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

–>

SIP 180 (Ringing)

P

4b2

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

<–

PRACK

4b3

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

–>

SIP 200 (OK)

4A

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

P

5

Make UE (MCPTT User) accept the call

6

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

–>

SIP 200 (OK)

P

7

The SS (MCPTT 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 with the following clarifications:

Table 5.3.6.4-1: SIP INVITE (step 2, Table 5.3.6.3-1)

Derivation Path: Table 5.5.2.5.2-1 with condition MANUAL and PRIVATE-CALL and MCPTT

Table 5.3.6.4-1A: SIP 180 (Ringing) (step 4a1, Table 5.3.6.3-1)

Derivation Path: Table 5.5.2.16.2.1-1 with condition MCPTT

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 and MCPTT

Table 5.3.6.4-3: SIP 200 (OK) (step 6, Table 5.3.6.3-1)

Derivation Path: Table 5.5.2.17.1.1-1 with condition INVITE-RSP and MCPTT

5.3.7 Generic Test Procedure for MCPTT CO session establishment/modification without provisional responses other than 100 Trying

5.3.7.1 Initial conditions

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

5.3.7.2 Definition of system information messages

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

5.3.7.3 Procedure

Table 5.3.7.3-1: MCPTT CO 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 MCPTT call establishment described in clause 5.4.3 ‘Generic Test Procedure for MCPTT CO communication in E-UTRA’ take place.

2

Check: Does the UE (MCPTT Client) send a SIP INVITE requesting the establishment/modification of an MCPTT call?

–>

SIP INVITE

P

3

The SS sends SIP 100 Trying

<–

SIP 100 (Trying)

4

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

<–

SIP 200 (OK)

5

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

–>

SIP ACK

P

EXCEPTION: Steps 6a1 describes behaviour that depends on the test case requirements ; the "lower case letter" identifies a step sequence that takes place if the UE requests implicit floor control in step 2 (i.e. the "mc_implicit_request" fmtp attribute included in the SDP offer and the SS responded with the "mc_implicit_request" fmtp attribute included and the “mc_granted” fmtp attribute not present in the SDP answer (NOTE1)

6a1

The SS (MCPTT server) sends a Floor Granted message.

<–

Floor Granted

NOTE1: Possibilities in SDP-offer/answer depend on the test case requirements

a. UE sends SDP offer without implicit floor request

b. UE sends SDP offer with implicit floor request

i. SDP answer from SS contains “mc_implicit_request” and “mc_granted” (Floor is implicitly granted)

ii. SDP answer from SS contains “mc_implicit request” and but no “mc_granted” (Floor needs to be explicitly granted ar step 6a1)

iii. SDP answer from SS contains no “mc_implicit_request”and no “mc_granted” (the UE needs to explicitly request the floor)

5.3.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:

Table 5.3.7.4-1: SIP INVITE (step 2, Table 5.3.7.3-1)

Derivation Path: Table 5.5.2.5.2-1 with condition MCPTT

Table 5.3.7.4-2: SIP 200 (OK) (step 4, Table 5.3.7.3-1)

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

5.3.8 Generic Test Procedure for MCPTT CO private call establishment, manual commencement

5.3.8.1 Initial conditions

The same initial conditions apply as specified in clause 5.3.3.1.

5.3.8.2 Definition of system information messages

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

5.3.8.3 Procedure

Table 5.3.8.3-1: MCPTT CO 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 MCPTT call establishment described in clause 5.4.3 ‘Generic Test Procedure for MCPTT CO communication in E-UTRA’ take place.

2

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

–>

SIP INVITE

P

3

The SS sends SIP 100 Trying

<–

SIP 100 (Trying)

4

The SS (MCPTT server) responds with a SIP 180 (Ringing)

<–

SIP 180 (Ringing)

5

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

<–

SIP 200 (OK)

6

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

–>

SIP ACK

P

EXCEPTION: Steps 7a1 describes behaviour that depends on the test case requirements ; the "lower case letter" identifies a step sequence that takes place if the UE requests implicit floor control in step 2 (i.e. the "mc_implicit_request" fmtp attribute included in the SDP offer and the SS responded with the "mc_implicit_request" fmtp attribute included and the “mc_granted” fmtp attribute not present in the SDP answer (NOTE1)

7a1

The SS (MCPTT server) sends a Floor Granted message.

<–

Floor Granted

NOTE1: Possibilities in SDP-offer/answer depend on the test case requirements

a. UE sends SDP offer without implicit floor request

b. UE sends SDP offer with implicit floor request

i. SDP answer from SS contains “mc_implicit_request” and “mc_granted” (Floor is implicitly granted)

ii. SDP answer from SS contains “mc_implicit request” and but no “mc_granted” (Floor needs to be explicitly granted ar step 7a1)

iii. SDP answer from SS contains no “mc_implicit_request”and no “mc_granted” (the UE needs to explicitly request the floor)

5.3.8.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.8.4-1: SIP INVITE (step 2, Table 5.3.8.3-1)

Derivation Path: Table 5.5.2.5.2-1 with condition MANUAL and PRIVATE-CALL and MCPTT

Table 5.3.8.4-2: SIP 200 (OK) (step 5, Table 5.3.8.3-1)

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

5.3.9 Generic Test Procedure for MCPTT CO call establishment using a pre-established session

5.3.9.1 Initial conditions

As specified in the test case which calls the procedure.

5.3.9.2 Definition of system information messages

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

5.3.9.3 Procedure

Table 5.3.9.3-1: MCPTT CO call establishment using a pre-established session

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

2

Check: Does the UE (MCPTT Client) send a SIP REFER message to request the establishment of an MCPTT call using a pre-established session?

–>

SIP REFER

P

3

The SS (MCPTT Server) responds with a SIP 200 (OK) message indicating that the MCPTT call has been established

<–

SIP 200 (OK)

4

The SS sends a Connect message

<–

Connect

5

Check: Does the UE (MCPTT Client) send an Acknowledgement in response to the Connect message?

–>

Acknowledge

P

5.3.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:

none

5.3.10 Generic Test Procedure for MCPTT CO call release

5.3.10.1 Initial conditions

As specified in the test case which calls the procedure.

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: MCPTT CO call release

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

1

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

–>

SIP BYE

P

2

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

<–

SIP 200 (OK)

EXCEPTION: 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 Generic Test Procedure for MCPTT CO call release keeping the pre-established session

5.3.11.1 Initial conditions

As specified in the test case which calls the procedure.

5.3.11.2 Definition of system information messages

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

5.3.11.3 Procedure

Table 5.3.11.3-1: MCPTT CO call release keeping the pre-established session

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

1

Check: Does the UE (MCPTT Client) send a SIP REFER message with method “BYE” to release the MCPTT session and keep the pre-established session?

–>

SIP REFER

P

2

The SS (MCPTT Server) responds with a SIP 200 (OK)

<–

SIP 200 (OK)

EXCEPTION: The SS waits 2 seconds before the SS 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.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:.

Table 5.3.11.4-1: SIP REFER (step 1, Table 5.3.11.3-1)

Derivation Path: Table 5.5.2.12-1 with condition METHOD-BYE

5.3.12 Generic Test Procedure for MCPTT CT call release

5.3.12.1 Initial conditions

As specified in the test case which calls the procedure.

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: MCPTT CT call release

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

1

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

<–

SIP BYE

2

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

–>

SIP 200 (OK)

P

EXCEPTION: 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 Generic Test Procedure for MCPTT CT call release keeping the pre-established session

5.3.13.1 Initial conditions

As specified in the test case which calls the procedure.

5.3.13.2 Definition of system information messages

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

5.3.13.3 Procedure

Table 5.3.13.3-1: MCPTT CT call release keeping the pre-established session

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

1

SS (MCPTT Server) releases the call by sending a Disconnect message

<–

Disconnect

2

Check: Does the UE (MCPTT Client) send an Acknowledgement to accept the release of the call?

–>

Acknowledge

P

EXCEPTION: the SS waits 2 seconds before the SS 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.13.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.14 Generic Test Procedure for MCPTT CO session modification with implicit Floor Control

5.3.14.1 Initial conditions

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

5.3.14.2 Definition of system information messages

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

5.3.14.3 Procedure

Table 5.3.14.3-1: MCPTT CO session modification
with implicit Floor Control

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

1

Check: Does the UE (MCPTT Client) send a SIP INVITE requesting the establishment/modification of an MCPTT call?

–>

SIP re-INVITE

P

2

The SS sends SIP 100 Trying

<–

SIP 100 (Trying)

3

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

<–

SIP 200 (OK)

4

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

–>

SIP ACK

P

5

The SS (MCPTT Server) sends a Floor Granted message with an acknowledgement required.

<–

Floor Granted

6

Check: Does the UE (MCPTT Client) sends a Floor Ack message in response to the Floor Granted message?

–>

Floor Ack

P

5.3.14.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.14.4-1: SIP 200 (OK) (step 2, Table 5.3.14.3-1)

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

5.3.15 Generic Test Procedure for MCPTT CO session modification without implicit Floor Control

5.3.15.1 Initial conditions

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

5.3.15.2 Definition of system information messages

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

5.3.15.3 Procedure

Table 5.3.15.3-1: MCPTT CO session modification
without implicit Floor Control

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

1

Check: Does the UE (MCPTT Client) send a SIP INVITE requesting the establishment/modification of an MCPTT call?

–>

SIP re-INVITE

P

2

The SS sends SIP 100 Trying

<–

SIP 100 (Trying)

3

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

<–

SIP 200 (OK)

4

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

–>

SIP ACK

P

5

The SS (MCPTT Server) sends a Floor Idle message with no acknowledgement required.

<–

Floor Idle

5.3.15.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.15.4-1: SIP 200 (OK) (step 2, Table 5.3.15.3-1)

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

Information Element

Value/remark

Comment

Reference

Condition

Message-body

MIME body part

SDP message

RFC 4566

MIME-part-body

SDP message as described in Table 5.3.15.4-2

Table 5.3.15.4-2: SDP in SIP 200 (OK) (Table 5.3.15.4-1)

Derivation Path: Table 5.5.3.1.2-1 SDP Message from the SS for MCPTT

Information Element

Value/remark

Comment

Reference

Condition

Media description[2]

Media description for media control

media attribute

a= line

attribute = fmtp

fmtp

format specific parameters

mc_implicit_request

Not present

Parameter has no value

TS 24.380 [10]
cl. 12.1.2.3

5.3.16 Generic Test Procedure for MCPTT Floor Request – Floor Granted

5.3.16.1 Initial conditions

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

5.3.16.2 Definition of system information messages

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

5.3.16.3 Procedure

Table 5.3.16.3-1: MCPTT Floor Request – Floor Granted

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

1

Check: Does the UE (MCPTT Client) send a Floor Request message?

–>

Floor Request

P

2

The SS (MCPTT Server) sends a Floor Granted message with an acknowledgement required.

<–

Floor Granted

3

Check: Does the UE (MCPTT Client) send a Floor Ack message in response to the Floor Granted message?

–>

Floor Ack

P

4

Check: Does the UE (MCPTT Client) provide floor granted notification to the MCPTT User? (NOTE 1)

P

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

5.3.16.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.17 Generic Test Procedure for MCPTT Floor Request – Floor Queue Position Info

5.3.17.1 Initial conditions

As specified in the test case which calls the procedure.

5.3.17.2 Definition of system information messages

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

5.3.17.3 Procedure

Table 5.3.17.3-1: MCPTT Floor Request – Floor Queue Position Info

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

1

Check: Does the UE (MCPTT Client) send a Floor Request message?

–>

Floor Request

P

2

The SS (MCPTT Server) sends a Floor Queue Position Info message indicating that the Floor Request was queued message with no acknowledgement required.

<–

Floor Queue Position Info

5.3.17.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.18 Generic Test Procedure for MCPTT Queuing Position Request

5.3.18.1 Initial conditions

As specified in the test case which calls the procedure.

5.3.18.2 Definition of system information messages

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

5.3.18.3 Procedure

Table 5.3.18.3-1: MCPTT Queuing Position Request

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

1

Check: Does the UE (MCPTT Client) send a Floor Queue Position Request message?

–>

Floor Queue Position Request

P

2

The SS (MCPTT Server) responds with a Floor Queue Position Info message with no acknowledgement required.

<–

Floor Queue Position Info

5.3.18.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.19 Generic Test Procedure for MCPTT Floor Request – Floor Deny

5.3.19.1 Initial conditions

As specified in the test case which calls the procedure.

5.3.19.2 Definition of system information messages

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

5.3.19.3 Procedure

Table 5.3.19.3-1: MCPTT Floor Request – Floor Deny

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

1

Check: Does the UE (MCPTT Client) send a Floor Request message?

–>

Floor Request

P

2

The SS (MCPTT Server) sends a Floor Deny message with no acknowledgement required

<–

Floor Deny

3

Check: Does the UE (MCPTT Client) provide floor deny notification to the MCPTT User? (NOTE 1)

P

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

5.3.19.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.20 Generic Test Procedure for MCPTT Floor Release – Floor Idle

5.3.20.1 Initial conditions

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

5.3.20.2 Definition of system information messages

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

5.3.20.3 Procedure

Table 5.3.20.3-1: MCPTT Floor Release – Floor Idle

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

1

Check: Does the UE (MCPTT Client) send a Floor Release message?

–>

Floor Release

P

EXCEPTION: Step 2a1 describes behaviour that depends on the UE implementation; the "lower case letter" identifies a step sequence that take place if the UE requests an acknowledgement to the Floor Release message.

2a1

The SS (MCPTT Server) sends a Floor Ack message in response to the Floor Release message

<–

Floor Ack

3

The SS (MCPTT Server) sends a Floor Idle message with no acknowledgement required.

<–

Floor Idle

5.3.20.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.21 Generic Test Procedure for MCPTT Floor Release – Floor Taken

5.3.21.1 Initial conditions

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

5.3.21.2 Definition of system information messages

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

5.3.21.3 Procedure

Table 5.3.21.3-1: MCPTT Floor Release – Floor Taken

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

1

Check: Does the UE (MCPTT Client) send a Floor Release message?

–>

Floor Release

P

EXCEPTION: Step 2a1 describes behaviour that depends on the UE implementation; the "lower case letter" identifies a step sequence that take place if the UE requests an acknowledgement to the Floor Release message.

2a1

The SS (MCPTT Server) sends a Floor Ack message in response to the Floor Release message

<–

Floor Ack

3

The SS (MCPTT Server) sends a Floor Taken message with no acknowledgement required.

<–

Floor Taken

5.3.21.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.22 Generic Test Procedure for 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.

5.3.22.2 Definition of system information messages

5.3.22.3 Procedure

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

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

1

The SS (MCPTT 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 (MCPTT 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 (MCPTT server) sends the HTTP 200 (OK) message including the updated Group Document

<–

HTTP 200 (OK)

5

The SS (MCPTT 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 (MCPTT 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.1-3

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

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

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

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

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

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.

}

}

}

..}

}

5.3.23 Generic Test Procedure for MCPTT CT Call establishment automatic commencement using a pre-established session

5.3.23.1 Initial conditions

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

5.3.23.2 Definition of system information messages

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

5.3.23.3 Procedure

Table 5.3.23.3-1: MCPTT CT Call establishment automatic commencement using a pre-established session

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

1

E-UTRA/EPC signalling according to clause 5.4.13 ‘Generic Test Procedure for MCPTT radio bearer establishment for use of pre-established session’ takes place

2

SS initiates an on-demand pre-arranged group call with automatic commencement mode using a pre-established session by sending a Connect message

<–

Connect

3

Check: Does the UE (MCPTT client) send an Acknowledgement to accept the incoming pre-arranged group call using a pre-established session?

–>

Acknowledge

P

5.3.23.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.24 Generic Test Procedure for UE initiated MCPTT functional alias status determination and subscription

5.3.24.1 Initial conditions

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

5.3.24.2 Definition of system information messages

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

5.3.24.3 Procedure

Table 5.3.24.3-1: MCPTT functional alias status determination and subscription

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

1

Make the MCPTT User request to determine the current status of a functional alias and later notification of status changes of a functional alias.

(NOTE 1)

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

2a1

IF in RRC_IDLE state, the E-UTRA/EPC actions which are related to the MCPTT call establishment described in clause 5.4.3 ‘Generic Test Procedure for MCPTT CO communication in E-UTRA’ take place.

3

Check: Does the UE (MCPTT Client) send a SIP SUBSCRIBE requesting the status of any existing functional aliases?

–>

SIP SUBSCRIBE

P

4

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

<–

SIP 200 (OK)

5

The SS (MCPTT server) sends a SIP NOTIFY with functional alias information

<–

SIP NOTIFY

6

Check: Does the UE (MCPTT Client) send a SIP 200 (OK)?

–>

SIP 200 (OK)

P

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

(NOTE 2)

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

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

5.3.24.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.24.4-1: SIP SUBSCRIBE (step 3, Table 5.3.24.3-1)

Derivation Path: Table 5.5.2.14-1 with condition MCPTT

Information Element

Value/remark

Comment

Reference

Condition

Expires

value

"4294967295"

to receive the current status and later notification

TS 24.379 [9] clause 9A.2.1.3

Message-body

TS 24.379 [9] clause 9A.2.1.3

MIME body part

MCPTT Info

MIME-part-body

MCPTT-Info as described in Table 5.3.24.4-2

Table 5.3.24.4-2: MCPTT-Info in SIP SUBSCRIBE (Table 5.3.24.4-1)

Derivation Path: Table 5.5.3.2.1-1

Information Element

Value/remark

Comment

Reference

Condition

mcpttinfo

mcptt-Params

mcptt-request-uri

px_MCPTT_ID_User_A

TS 24.379 [9] clause 9A.2.1.3

Table 5.3.24.4-3: SIP 200 (OK) (step 4, Table 5.3.24.3-1)

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

Table 5.3.24.4-4: SIP NOTIFY (step 5, Table 5.3.24.3-1)

Derivation Path: Table 5.5.2.8-1 with condition PRESENCE-EVENT

Information Element

Value/remark

Comment

Reference

Condition

Message-body

MIME body part

PIDF

TS 24.379 [9] clause 9A.2.2.2.5

MIME-part-body

PIDF as described in Table 5.3.24.4-5

Table 5.3.24.4-5: PIDF in SIP NOTIFY (Table 5.3.24.4-4)

Derivation Path: Table 5.5.3.5.2-1 (NOTE 1)

NOTE 1: PIDF document contains tuple with empty <status> element (i.e. there are no <functionalAlias> entries at all) and not containing a <p-id-fa> element

5.3.25 Generic Test Procedure for UE initiated MCPTT functional alias status change

5.3.25.1 Initial conditions

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

5.3.25.2 Definition of system information messages

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

5.3.25.3 Procedure

Table 5.3.25.3-1: MCPTT functional alias status change

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

1

Make the MCPTT User request to change the status of a functional alias to "activated".

(NOTE 1)

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

2a1

IF in RRC_IDLE state, the E-UTRA/EPC actions which are related to the MCPTT call establishment described in clause 5.4.3 ‘Generic Test Procedure for MCPTT CO communication in E-UTRA’ take place.

3

Check: Does the UE (MCPTT Client) send a SIP PUBLISH requesting the status change of a functional alias?

–>

SIP PUBLISH

P

4

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

<–

SIP 200 (OK)

5

The SS (MCPTT server) sends a SIP NOTIFY with functional alias information

<–

SIP NOTIFY

6

Check: Does the UE (MCPTT Client) send a SIP 200 (OK)?

–>

SIP 200 (OK)

P

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

(NOTE 2)

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

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

5.3.25.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.25.4-1: SIP PUBLISH (step 3, Table 5.3.25.3-1)

Derivation Path: Table 5.5.2.11-1 with condition PRESENCE-EVENT

Information Element

Value/remark

Comment

Reference

Condition

Message-body

MIME body part

MCPTT Info

TS 24.379 [9] clause 9A.2.1.2

MIME-part-body

MCPTT-Info as described in Table 5.3.25.4-2

MIME body part

PIDF

TS 24.379 [9] clause 9A.2.1.2

MIME-part-body

PIDF as described in Table 5.3.25.4-3

Table 5.3.25.4-2: MCPTT-Info in SIP PUBLISH (Table 5.3.25.4-1)

Derivation Path: Table 5.5.3.2.1-1

Information Element

Value/remark

Comment

Reference

Condition

mcpttinfo

mcptt-Params

mcptt-request-uri

px_MCPTT_ID_User_A

TS 24.379 [9] clause 9A.2.1.2

Table 5.3.25.4-3: PIDF in SIP PUBLISH (Table 5.3.25.4-1)

Derivation Path: Table 5.5.3.5.1-1 with condition FUNCTIONAL_ALIAS_STATUS_CHANGE

Table 5.3.25.4-4: SIP 200 (OK) (step 4, Table 5.3.25.3-1)

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

Table 5.3.25.4-5: SIP NOTIFY (step 5, Table 5.3.25.3-1)

Derivation Path: Table 5.5.2.8-1 with condition PRESENCE-EVENT

Information Element

Value/remark

Comment

Reference

Condition

Message-body

MIME body part

PIDF

TS 24.379 [9] clause 9A.2.2.2.5

MIME-part-body

PIDF as described in Table 5.3.25.4-6

Table 5.3.25.4-6: PIDF in SIP NOTIFY (Table 5.3.25.4-5)

Derivation Path: Table 5.5.3.5.2-1 with condition FUNCTIONAL_ALIAS_ACTIVATED, NOTIFY_FOR_PUBLISH

5.3.26 Generic Test Procedure for MCPTT CO Group Creation

5.3.26.1 Initial conditions

As specified in the test case which calls the procedure.

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: MCPTT CO Group Creation procedure

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

1a1-1a2

Void

1

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

–>

HTTP PUT

P

2

The SS (MCPTT 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:

Table 5.3.26.4-1..2: Void

Table 5.3.26.4-3: HTTP PUT (Step 1, Table 5.3.26.3-1)

Derivation Path: Table 5.5.4.4-1, condition GROUPCREATE

Table 5.3.26.4-4..25: Void

5.3.27 Generic Test Procedure for MCPTT CO Temporary Group Creation

5.3.27.1 Initial conditions

As specified in the test case which calls the procedure.

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: MCPTT CO Temporary Group Creation procedure

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

1

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

–>

HTTP POST

P

2

The SS (MCPTT 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:

Table 5.3.27.4-1: HTTP POST (Step 1, Table 5.3.27.3-1)

Derivation Path: Table 5.5.4.3-1, condition TEMPGROUP

Table 5.3.27.4-2: HTTP 200 (OK) (Step 2, Table 5.3.27.3-1)

Derivation Path: Table 5.5.4.6-1, condition TEMPGROUP

5.3.28 Generic Test Procedure for MCPTT CO Temporary Group Tear Down

5.3.28.1 Initial conditions

As specified in the test case which calls the procedure.

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: MCPTT CO Temporary Group Creation procedure

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

1

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

–>

HTTP DELETE

P

2

The SS (MCPTT 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:

Table 5.3.28.4-1: HTTP DELETE (Step 1, Table 5.3.28.3-1)

Derivation Path: Table 5.5.4.5-1, condition TEMPGROUP

5.3.29 Generic Test Procedure for MCPTT 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.

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: MCPTT 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 MCPTT call establishment described in clause 5.4.3 ‘Generic Test Procedure for MCPTT CO communication in E-UTRA’ take place.

2

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

–>

SIP SUBSCRIBE

P

3

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

<–

SIP 200 (OK)

4

The SS (MCPTT Server) sends a SIP NOTIFY message

<–

SIP NOTIFY

5

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

–>

SIP 200 (OK)

EXCEPTION: SS (MCPTT 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