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