5.3A Generic test procedures for UE MCPTT operation

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

5.3A.1 MCPTT CO session establishment/modification without provisional responses other than 100 Trying

5.3A.1.1 Initial conditions

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

5.3A.1.2 Definition of system information messages

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

5.3A.1.3 Procedure

Table 5.3A.1.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 MCX 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 at 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.3A.1.4 Specific message contents

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

Table 5.3A.1.4-1: SIP INVITE (step 2, Table 5.3A.1.3-1)

Derivation Path: Table 5.5.2.5.1-1 with condition MCPTT

Table 5.3A.1.4-2: SIP 200 (OK) (step 4, Table 5.3A.1.3-1)

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

5.3A.2 MCPTT CO private call establishment, manual commencement

5.3A.2.1 Initial conditions

The same initial conditions apply as specified in clause 5.3.3.1.

5.3A.2.2 Definition of system information messages

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

5.3A.2.3 Procedure

Table 5.3A.2.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 MCX 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 at 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.3A.2.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.3A.2.4-1: SIP INVITE (step 2, Table 5.3A.2.3-1)

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

Table 5.3A.2.4-2: SIP 200 (OK) (step 5, Table 5.3A.2.3-1)

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

5.3A.3 MCPTT CO call establishment using a pre-established session

5.3A.3.1 Initial conditions

As specified in the test case which calls the procedure.

5.3A.3.2 Definition of system information messages

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

5.3A.3.3 Procedure

Table 5.3A.3.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.3 ‘Generic Test Procedure for MCX CO 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.3A.3.4 Specific message contents

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

none

5.3A.4 MCPTT CO call release keeping the pre-established session

5.3A.4.1 Initial conditions

As specified in the test case which calls the procedure.

5.3A.4.2 Definition of system information messages

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

5.3A.4.3 Procedure

Table 5.3A.4.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)

3

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.3A.4.4 Specific message contents

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

Table 5.3A.4.4-1: SIP REFER (step 1, Table 5.3A.4.3-1)

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

Table 5.3A.4.4-2: SIP 200 (OK) (step 2, Table 5.3A.4.3-1)

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

5.3A.5 MCPTT CT call release keeping the pre-established session

5.3A.5.1 Initial conditions

As specified in the test case which calls the procedure.

5.3A.5.2 Definition of system information messages

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

5.3A.5.3 Procedure

Table 5.3A.5.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

3

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.3A.5.4 Specific message contents

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

Table 5.3A.5.4-1: Disconnect (step 1, Table 5.3A.5.3-1)

Derivation Path: Table 5.5.6.13-1 with condition ACK

5.3A.6 MCPTT CO session modification

5.3A.6.1 Initial conditions

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

5.3A.6.2 Definition of system information messages

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

5.3A.6.3 Procedure

Table 5.3A.6.3-1: MCPTT CO session modification

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

1

Check: Does the UE (MCPTT Client) send a SIP INVITE requesting the 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 modification?

–>

SIP ACK

P

EXCEPTION: Steps 5a1-5a2 describe behaviour that depends on whether the UE has implicitly requested a grant at step 1 which has not implicitly been granted at step 3 (NOTE 1)

5a1

IF the media description for media control in the 200 OK at step 3 contains fmtp parameter mc_implicit_request but no fmtp parameter mc_granted THEN the SS (MCPTT Server) sends a Floor Granted message with an acknowledgement required.

<–

Floor Granted

5a2

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

–>

Floor Ack

P

NOTE 1: An implicit floor control may be requested in case of upgrade to an emergency or imminent peril group call but not in case of a downgrade or any other re-INVITE

5.3A.6.4 Specific message contents

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

Table 5.3A.6.4-1: SIP 200 (OK) (step 3, Table 5.3A.6.3-1)

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

Table 5.3A.6.4-2: Floor Granted (step 5a1, Table 5.3A.6.3-1)

Derivation Path: Table 5.5.6.3-1 condition ACK

5.3A.7 Void

5.3A.8 MCPTT CT Call establishment automatic commencement using a pre-established session

5.3A.8.1 Initial conditions

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

5.3A.8.2 Definition of system information messages

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

5.3A.8.3 Procedure

Table 5.3A.8.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.4 ‘Generic Test Procedure for MCX CT communication in E-UTRA’ 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.3A.8.4 Specific message contents

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

none

5.3A.9 UE initiated MCPTT functional alias status determination and subscription

5.3A.9.1 Initial conditions

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

5.3A.9.2 Definition of system information messages

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

5.3A.9.3 Procedure

Table 5.3A.9.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 MCX 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

7

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.3A.9.4 Specific message contents

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

Table 5.3A.9.4-1: SIP SUBSCRIBE (step 3, Table 5.3A.9.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.3A.9.4-2

Table 5.3A.9.4-2: MCPTT-Info in SIP SUBSCRIBE (Table 5.3A.9.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.3A.9.4-3: SIP 200 (OK) (step 4, Table 5.3A.9.3-1)

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

Table 5.3A.9.4-4: SIP NOTIFY (step 5, Table 5.3A.9.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.3A.9.4-5

Table 5.3A.9.4-5: PIDF in SIP NOTIFY (Table 5.3A.9.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.3A.10 UE initiated MCPTT functional alias status change

5.3A.10.1 Initial conditions

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

5.3A.10.2 Definition of system information messages

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

5.3A.10.3 Procedure

Table 5.3A.10.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 MCX 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

7

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.3A.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:

Table 5.3A.10.4-1: SIP PUBLISH (step 3, Table 5.3A.10.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.3A.10.4-2

MIME body part

PIDF

TS 24.379 [9] clause 9A.2.1.2

MIME-part-body

PIDF as described in Table 5.3A.10.4-3

Table 5.3A.10.4-2: MCPTT-Info in SIP PUBLISH (Table 5.3A.10.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.3A.10.4-3: PIDF in SIP PUBLISH (Table 5.3A.10.4-1)

Derivation Path: Table 5.5.3.5.1-1 with condition FUNCTIONAL_ALIAS_STATUS_CHANGE

Table 5.3A.10.4-4: SIP 200 (OK) (step 4, Table 5.3A.10.3-1)

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

Table 5.3A.10.4-5: SIP NOTIFY (step 5, Table 5.3A.10.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.3A.10.4-6

Table 5.3A.10.4-6: PIDF in SIP NOTIFY (Table 5.3A.10.4-5)

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

5.3A.11 MCPTT Floor Request – Floor Granted

5.3A.11.1 Initial conditions

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

5.3A.11.2 Definition of system information messages

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

5.3A.11.3 Procedure

Table 5.3A.11.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.3A.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.3A.11.4-1: Floor Granted (Step 2, Table 5.3.16.3-1)

Derivation Path: Table 5.5.6.3-1 condition ACK

5.3A.12 MCPTT Floor Request – Floor Queue Position Info

5.3A.12.1 Initial conditions

As specified in the test case which calls the procedure.

5.3A.12.2 Definition of system information messages

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

5.3A.12.3 Procedure

Table 5.3A.12.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.3A.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.3A.13 MCPTT Queuing Position Request

5.3A.13.1 Initial conditions

As specified in the test case which calls the procedure.

5.3A.13.2 Definition of system information messages

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

5.3A.13.3 Procedure

Table 5.3A.13.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.3A.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.3A.14 MCPTT Floor Request – Floor Deny

5.3A.14.1 Initial conditions

As specified in the test case which calls the procedure.

5.3A.14.2 Definition of system information messages

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

5.3A.14.3 Procedure

Table 5.3A.14.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.3A.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:

none

5.3A.15 MCPTT Floor Release – Floor Idle

5.3A.15.1 Initial conditions

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

5.3A.15.2 Definition of system information messages

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

5.3A.15.3 Procedure

Table 5.3A.15.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.3A.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:

None

5.3A.16 MCPTT Floor Release – Floor Taken

5.3A.16.1 Initial conditions

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

5.3A.16.2 Definition of system information messages

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

5.3A.16.3 Procedure

Table 5.3A.16.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.3A.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