7.1.1 Off-network / Group Call / Floor Control / Upgrade to Emergency Call / Downgrade from Emergency / Upgrade to Imminent Peril / Downgrade from Imminent Peril / Release Call / Client Originated (CO)

36.579-23GPPMission Critical (MC) services over LTEPart 2: Mission Critical Push To Talk (MCPTT) User Equipment (UE) Protocol conformance specificationRelease 15TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

7.1.1.1 Test Purpose (TP)

(1)

with { UE (MCPTT Client) registered and authorised for MCPTT Service, including authorised to initiate/cancel group calls in off-network environment, and the UE (MCPTT Client) is in an off-network environment }

ensure that {

when { the MCPTT User requests the establishment of an MCPTT pre-arranged group call }

then { UE (MCPTT Client) requests a pre-arranged group call by sending a GROUP CALL PROBE message and, upon not receiving a response to the GROUP CALL PROBE, sends a GROUP CALL ANNOUNCEMENT message }

}

(2)

with { UE (MCPTT Client) having established an off-network MCPTT Pre-arranged Group Call }

ensure that {

when { the MCPTT User (MCPTT Client) engages in communication with the invited MCPTT User(s) }

then { UE (MCPTT Client) respects the floor control imposed by the floor control entity/arbitrator (Floor Request during a talk burst, Floor granting/release, Floor idle, Floor deny, Floor taken/revoked, Floor request queued and queue handling) }

}

(3)

with { UE (MCPTT Client) having established an off-network group call and the MCPTT User being authorised for initiating an MCPTT emergency group call }

ensure that {

when { the MCPTT User requests to upgrade the ongoing off-network MCPTT group call to an MCPTT emergency group call }

then { UE (MCPTT Client) sends a GROUP CALL ANNOUNCEMENT message and enters the T1: in-progress emergency group call state}

}

(4)

with { UE (MCPTT Client) having upgraded to an off-network emergency group call }

ensure that {

when { the MCPTT User (MCPTT Client) continues communication with the invited MCPTT User(s) }

then { UE (MCPTT Client) respects the floor control imposed by the floor control entity/arbitrator }

}

(5)

with { UE (MCPTT Client) having upgraded to an off-network emergency group call and the MCPTT User being authorised for cancelling an MCPTT emergency state }

ensure that {

when { the MCPTT User requests to cancel the ongoing MCPTT Emergency state }

then { UE (MCPTT Client) sends a GROUP CALL EMERGENCY END message and enters the T2: in-progress basic group call state }

}

(6)

with { UE (MCPTT Client) having established an off-network group call and the MCPTT User being authorised for initiating an MCPTT imminent peril group call }

ensure that {

when { the MCPTT User requests to upgrade the ongoing off-network MCPTT group call to an MCPTT imminent peril group call with floor control }

then { UE (MCPTT Client) sends a GROUP CALL ANNOUNCEMENT message and enters the T3: in-progress imminent peril group call state}

}

(7)

with { UE (MCPTT Client) having upgraded to an off-network imminent peril group call }

ensure that {

when { the MCPTT User (MCPTT Client) continues communication with the invited MCPTT User(s) }

then { UE (MCPTT Client) respects the floor control imposed by the floor control entity/arbitrator }

}

(8)

with { UE (MCPTT Client) having upgraded to an off-network imminent peril group call and the MCPTT User being authorised for cancelling an MCPTT imminent peril state }

ensure that {

when { the MCPTT User requests to cancel the ongoing MCPTT imminent peril state }

then { UE (MCPTT Client) sends a GROUP CALL IMMINENT PERIL END message and enters the T2: in-progress basic group call state }

}

7.1.1.2 Conformance requirements

References: The conformance requirements covered in the current TC are specified in: TS 24.379 clauses 10.2.2.4.2.1, 10.2.2.4.3.1, 10.2.3.4.2, 10.2.3.4.7.1, 10.2.3.4.8.1, 10.2.3.4.8.4, 10.2.2.4.5.1, 10.2.2.4.5.4, 10.2.3.4.10, TS 24.380 clauses 7.2.3.2.2, 7.2.3.5.5, 7.2.3.3.2, 7.2.3.6.7, 7.2.3.5.4, 7.2.3.5.8, 7.2.3.5.6, 7.2.3.7.3, 7.2.3.7.5, 7.2.3.3.4, 7.2.3.4.3, 7.2.3.3.6, 7.2.3.4.2, 7.2.3.6.4, 7.2.3.6.3, 7.2.3.8.11, 7.2.3.8.3, 7.2.3.8.6, 7.2.3.5.7, 7.2.3.6.9, 7.2.3.6.6. Unless otherwise stated these are Rel-13 requirements.

[TS 24.379, clause 10.2.2.4.2.1]

When in the "S1: start-stop" state, upon an indication from an MCPTT user to initiate a group call for an MCPTT group ID, the MCPTT client:

…

3) shall generate a GROUP CALL PROBE message as specified in subclause 15.1.2. In the GROUP CALL PROBE message, the MCPTT client:

a) shall set the MCPTT group ID IE to the stored MCPTT group ID of the call;

4) shall send the GROUP CALL PROBE message as specified in subclause 10.2.1.1.1;

5) shall start timer TFG3 (call probe retransmission);

6) shall start timer TFG1 (wait for call announcement); and

[TS 24.379, clause 10.2.2.4.3.1]

When in the "S2: waiting for call announcement" state, upon expiry of timer TFG1 (wait for call announcement), the MCPTT client:

1) shall stop timer TFG3 (call probe retransmission), if running;

…

7) shall generate a GROUP CALL ANNOUNCEMENT message as specified in subclause 15.1.3. In the GROUP CALL ANNOUNCEMENT message, the MCPTT client:

a) shall set the Call identifier IE to the stored call identifier of the call;

b) shall set the Call type IE to the stored current call type associated with the call type control state machine;

c) shall set the Refresh interval IE to the stored refresh interval of the call;

d) shall set the SDP IE to the stored SDP body of the call;

e) shall set the Originating MCPTT user ID IE to the stored originating MCPTT user ID of the call;

f) shall set the MCPTT group ID IE to the stored MCPTT group ID of the call;

g) shall set the Call start time IE to the stored call start time of the call;

h) shall set the Last call type change time IE to the stored last call type change time of the call associated with call type control state machine;

i) shall set the Last user to change call type IE to last user to change call type associated with call type control state machine; and

j) may include the Confirm mode indication IE;

8) shall send the GROUP CALL ANNOUNCEMENT message as specified in subclause 10.2.1.1.1;

9) shall establish a media session based on the stored SDP body of the call;

10) shall start floor control as originating floor participant as specified in subclause 7.2 in 3GPP TS 24.380 [5];

[TS 24.379, clause 10.2.3.4.2]

When in the "T0: waiting for the call to establish " state, upon an indication from an MCPTT user to initiate a group call probe for an MCPTT group, the MCPTT client:

1) if the stored emergency state associated with emergency alert state machine described in 12.2.2.2 is set to "true" and the value of "/<x>/<x>/Common/AllowedEmergencyCall" leaf node present in group configuration as specified in 3GPP TS 24.383 [45] is set to "true":

a) shall set the stored current call type to "EMERGENCY GROUP CALL"; and

b) shall set the stored current ProSe per-packet priority to value corresponding to MCPTT off-network emergency group call as described in 3GPP TS 24.383 [45];

2) if the stored emergency state associated with emergency alert state machine described in 12.2.2.2 is set to "false", and:

a) if the user initiates an MCPTT emergency call and the values of "/<x>/<x>/Common/MCPTTGroupCall/EmergencyCall/Enabled" leaf node present in the user profile and "/<x>/<x>/Common/AllowedEmergencyCall" leaf node present in group configuration as specified in 3GPP TS 24.383 [45] are set to "true":

i) shall set the stored current call type to "EMERGENCY GROUP CALL"; and

ii) shall set the stored current ProSe per-packet priority to value corresponding to MCPTT off-network emergency group call as described in 3GPP TS 24.383 [45];

b) if the user initiates an MCPTT imminent peril group call and the values of "/<x>/<x>/Common/MCPTTGroupCall/ImminentPerilCall/Authorised" leaf node present in the user profile "/<x>/<x>/Common/AllowedImminentPerilCall " leaf node present in group configuration as specified in 3GPP TS 24.383 [45] are set to "true":

i) shall set the stored current call type to "IMMINENT PERIL GROUP CALL"; and

ii) shall set the stored current ProSe per-packet priority to value corresponding to MCPTT off-network imminent peril group call as described in 3GPP TS 24.383 [45]; and

c) if the user initiates an MCPTT group call which is not an MCPTT emergency call and which is not an MCPTT imminent peril group call:

i) shall set the stored current call type to "BASIC GROUP CALL"; and

ii) shall set the stored current ProSe per-packet priority to value corresponding to MCPTT off-network basic group call as described in 3GPP TS 24.383 [45];

[TS 24.379, clause 10.2.3.4.7.1]

When in the "T2: in-progress basic group call" state, upon receiving an indication from the user to upgrade the call to "IMMINENT PERIL GROUP CALL" or "EMERGENCY GROUP CALL" or when in the "T3: in-progress imminent peril group call" state, upon receiving an indication from the user to upgrade the call to "EMERGENCY GROUP CALL", the MCPTT client:

1) if the user request is to upgrade the call to "EMERGENCY GROUP CALL" and the value of "/<x>/<x>/OffNetwork/EmergencyCallChange" leaf node present in the user profile as specified in 3GPP TS 24.383 [45] is set to "true":

a) shall set the stored current call type to "EMERGENCY GROUP CALL";

b) shall set the stored current ProSe per-packet priority to value corresponding to MCPTT off-network emergency group call as described in 3GPP TS 24.383 [45];

c) shall store the current UTC time as last call type change time of the call;

d) shall store own MCPTT user ID as last user to change call type of the call;

e) shall start timer TFG13 (implicit downgrade emergency) with value as specified in subclause 10.2.3.4.1.1;

f) shall stop timer TFG11 (emergency end retransmission), if running;

g) shall stop timer TFG14 (implicit downgrade imminent peril), if running; and

h) shall enter "T1: in-progress emergency group call" state;

2) if the user request is to upgrade the call to "IMMINENT PERIL GROUP CALL" and the value of "/<x>/<x>/OffNetwork/ ImminentPerilCallChange" leaf node present in the user profile as specified in 3GPP TS 24.383 [45] set to "true":

a) shall set the stored current call type to "IMMINENT PERIL GROUP CALL";

b) shall set the stored current ProSe per-packet priority to value corresponding to MCPTT off-network imminent peril group call as described in 3GPP TS 24.383 [45];

c) shall store the current UTC time as last call type change time of the call;

d) shall store own MCPTT user ID as last user to change call type of the call;

e) shall start timer TFG14 (implicit downgrade imminent peril) with value as specified in subclause 10.2.3.4.1.2;

f) shall stop timer TFG12 (imminent peril end retransmission), if running; and

g) shall enter "T3: in-progress imminent peril group call" state;

3) shall generate a GROUP CALL ANNOUNCEMENT message as specified in subclause 15.1.3. In the GROUP CALL ANNOUNCEMENT message, the MCPTT client:

a) shall set the Call identifier IE to the stored call identifier of the call associated with the basic call control state machine;

b) shall set the Call type IE to the stored current call type;

c) shall set the Refresh interval IE to the stored refresh interval of the call associated with the basic call control state machine;

d) shall set the SDP IE to the stored SDP body of the call associated with the basic call control state machine;

e) shall set the Originating MCPTT user ID IE to the stored originating MCPTT user ID of the call associated with the basic call control state machine;

f) shall set the MCPTT group ID IE to the stored MCPTT group ID of the call associated with the basic call control state machine;

g) shall set the call start time IE to the stored call start time of the call;

h) shall set the Last call type change time IE to the stored last call type change time of the call; and

i) shall set the Last user to change call type IE to the stored last user to change call type of the call; and

4) shall send the GROUP CALL ANNOUNCEMENT message as specified in subclause 10.2.1.1.1;

[TS 24.379, clause 10.2.3.4.8.1]

When in the "T1: in-progress emergency group call" state, upon receiving an indication from:

1) the MCPTT user who upgraded the MCPTT group call; or

2) an authorized MCPTT user with the value of "/<x>/<x>/Common/MCPTTGroupCall/EmergencyCall/CancelMCPTTGroup" leaf node present in the user profile as specified in 3GPP TS 24.383 [45] is set to "true",

to downgrade "EMERGENCY GROUP CALL", the MCPTT client:

…

5) shall generate a GROUP CALL EMERGENCY END message as specified in subclause 15.1.15. In the GROUP CALL EMERGENCY END message, the MCPTT client:

a) shall set the Call identifier IE to the stored call identifier of the call associated with the basic call control state machine;

b) shall set the Originating MCPTT user ID IE to the stored originating MCPTT user ID of the call associated with the basic call control state machine;

c) shall set the MCPTT group ID IE to the stored MCPTT group ID of the call associated with the basic call control state machine;

d) shall set the Last call type change time IE to the stored last call type change time of the call; and

e) shall set the Last user to change call type IE to the stored last user to change call type of the call;

6) shall send the GROUP CALL EMERGENCY END message as specified in subclause 10.2.1.1.1;

[TS 24.379, clause 10.2.3.4.8.4]

When in the "T3: in-progress imminent peril group call" state, upon receiving an indication from:

1) the MCPTT user who upgraded the call; or

2) an authorized with the value of "/<x>/<x>/Common/MCPTTGroupCall/ImminentPerilCall/Cancel" leaf node present in the user profile as specified in 3GPP TS 24.383 [45] is set to "true",

to downgrade "IMMINENT PERIL GROUP CALL", the MCPTT client:

…

5) shall generate a GROUP CALL IMMINENT PERIL END message as specified in subclause 15.1.14. In the GROUP CALL IMMINENT PERIL END message, the MCPTT client:

a) shall set the Call identifier IE to the stored call identifier of the call associated with the basic call control state machine;

b) shall set the Originating MCPTT user ID IE to the stored originating MCPTT user ID of the call associated with the basic call control state machine;

c) shall set the MCPTT group ID IE to the stored MCPTT group ID of the call associated with the basic call control state machine;

d) shall set the Last call type change time IE to the stored last call type change time of the call; and

e) shall set the Last user to change call type IE to the stored last user to change call type of the call;

6) shall send the GROUP CALL IMMINENT PERIL END message as specified in subclause 10.2.1.1.1;

[TS 24.379, clause 10.2.2.4.5.1]

When in the "S3: part of ongoing call" state, the "S5: pending user action with confirm indication" state, or the "S4: pending user action without confirm indication" state, upon an indication from the MCPTT user to release the group call, the MCPTT client:

1) shall release the media session, if established;

[TS 24.379, clause 10.2.2.4.5.4]

When in the "S6: ignoring incoming call announcements" state, upon expiration of timer TFG5 (not present incoming call announcements), the MCPTT client:

1) shall release the stored SDP body of the call;

2) shall release the stored call identifier of the call;

3) shall release the stored originating MCPTT user ID of the call;

4) shall release the stored refresh interval of the call;

5) shall release the stored MCPTT group ID of the call;

6) shall release the call start time of the call;

7) shall destroy the call type control state machine; and

8) shall enter the "S1: start-stop" state.

[TS 24.379, clause 10.2.3.4.10]

When in state T1: in-progress emergency group call" or "T2: in-progress basic group call" or "T3: in-progress imminent peril group call" or upon receiving an indication from MCPTT user to release the call, the MCPTT client:

1) shall release stored current call type;

2) shall release stored ProSe per-packet priority;

3) shall release Last call type change time;

4) shall release Last user to change call type; and

5) shall enter "T0: waiting for the call to establish" state.

[TS 24.380, clause 7.2.3.2.2]

When an MCPTT call is established with session announcement including an explicit floor request, the originating floor participant:

1. shall create an instance of a floor participant state transition diagram for basic operation state machine;

2. shall send Floor Granted message towards other floor participants. The Floor Granted message:

a. shall include the granted priority in the Floor priority field;

b. shall include the MCPTT user’s own MCPTT ID in the User ID field; and

c. if the floor request is a broadcast group call, system call, emergency call or an imminent peril call, shall include a Floor Indicator field indicating the relevant call types;

3. shall set the stored SSRC of the current floor arbitrator to its own SSRC; and

4. shall enter ‘O: has permission’ state.

[TS 24.380, clause 7.2.3.5.5]

Upon receiving an indication from the MCPTT user to release permission to send RTP media, the floor participant:

1. shall stop timer T206 (Stop talking warning), if running;

2. shall stop timer T207 (Stop talking), if running;

3. shall send a Floor Release message towards other floor participants, if no queued requests exist: The Floor Release message:

a. shall include the MCPTT ID of the MCPTT user in the User ID field; and

b. if the session is not initiated as a broadcast group call with the B-bit set to ‘1’ (Broadcast group call), shall include a Floor Indicator field set to ‘0’ (normal call);

4. shall start timer T230 (Inactivity);

5. shall clear the stored SSRC of the current arbitrator; and

6. shall enter ‘O: silence’ state.

[TS 24.380, clause 7.2.3.3.2]

If the floor participant receives an indication from the MCPTT user to send media, the floor participant:

1. shall send the Floor Request message to other floor participants. The Floor Request message:

a. if a priority different than the default floor priority is required, shall include the Floor Priority field with the requested priority in the <Floor Priority> element;

b. shall include the MCPTT ID of the MCPTT user in the <User ID> value of the User ID field; and

c. if the floor request is a broadcast group call, system call, emergency call or an imminent peril call, shall include a Floor Indicator field indicating the relevant call types;

2. shall initialize the counter C201 (Floor request) with value set to 1;

3. shall stop timer T230 (Inactivity);

4. shall start timer T201 (Floor Request); and

5. shall enter ‘O: pending request’ state.

[TS 24.380, clause 7.2.3.6.7]

Upon receiving Floor Granted message and if the <User ID> value in the User ID field matches its own MCPTT ID and SSRC of floor participant sending the Floor Granted message matches the stored SSRC of current arbitrator, the floor participant:

1. shall request the MCPTT client to stop rendering received RTP media packets;

2. shall set the stored SSRC of the current floor arbitrator to its own SSRC;

3. shall stop timer T203 (End of RTP media), if running;

4. shall stop timer T201 (Floor Request);

5. may provide a floor granted notification to the MCPTT user;

6. if the Floor Indicator field is included and the B bit is set to ‘1’ (Broadcast group call), shall provide a notification to the user indicating the type of call; and

7. shall enter ‘O: has permission’ state.

Otherwise, if the <User ID> value in the User ID field matches its own MCPTT ID and there is no stored SSRC of the current arbitrator, the floor participant:

1. shall set the stored SSRC of the current arbitrator to its own SSRC;

2. shall stop timer T203 (End of RTP media);

3. shall stop timer T201 (Floor Request);

4. may provide a floor granted notification to the MCPTT user;

5. if the Floor Indicator field is included and the B bit is set to ‘1’ (Broadcast group call), shall provide a notification to the user indicating the type of call; and

6. shall enter ‘O: has permission’ state.

Otherwise, if the <User ID> value in the User ID field matches its own MCPTT ID and SSRC of floor participant sending the Floor Granted message matches the stored SSRC of candidate arbitrator, the floor participant:

1. shall set the stored SSRC of the current arbitrator to its own SSRC;

2. shall stop timer T203 (End of RTP media);

3. shall stop timer T201 (Floor Request);

4. may provide a floor granted notification to the MCPTT user;

5. shall clear the stored SSRC of the candidate arbitrator;

6. if the Floor Indicator field is included and the B bit is set to ‘1’ (Broadcast group call), shall provide a notification to the user indicating the type of call; and

7. shall enter ‘O: has permission’ state.

[TS 24.380, clause 7.2.3.5.4]

Upon receiving a Floor Request message which is not pre-emptive as determined by subclause 4.1.1.5, in a session where:

1. the value of "/<x>/<x>/OffNetwork/QueueUsage" leaf node present in the group configuration as specified in 3GPP TS 24.383 [4] is set to "false"; or

2. the value of "/<x>/<x>/OffNetwork/QueueUsage" leaf node present in the group configuration as specified in 3GPP TS 24.383 [4] is set to "true" but the F-bit in the Floor Indicator field is set to ‘0’ (i.e. indicating that queuing of floor requests is not supported) or the Floor Indicator field is not included in the Floor Request message;

then the floor participant:

1. shall send the Floor Deny message. The Floor Deny message:

a. shall include in the Reject Cause field the <Reject Cause> value cause #1 (Another MCPTT client has permission);

b. may include in the Reject Cause field an additional text string explaining the reason for rejecting the floor request in the <Reject Phrase> value; and

c. shall include the User ID field received in the Floor Request message; and

2. shall remain in ‘O: has permission’ state.

Upon receiving a Floor Request message which is not pre-emptive as determined by subclause 4.1.1.5, and the value of "/<x>/<x>/OffNetwork/QueueUsage" leaf node present in the group configuration as specified in 3GPP TS 24.383 [4] is set to "true" and the F-bit in the Floor Indicator field is set to ‘1’ (i.e. indicating that queuing of the floor requests is supported) in the Floor Request message, the floor participant:

1. shall store the received Floor Request messages;

2. if the pending request queue is not full, shall send the Floor Queue Position Info message. The Floor Queue Position Info message:

a. shall include in the User ID field the MCPTT ID of the floor participant sending the Floor Request message;

b. shall include the SSRC of the floor participant in the SSRC of queued floor participant field;

c. shall include the position in the floor request queue in the Queue Info field; and

d. shall include the floor priority in the Queue Info field;

3. if the pending request queue is full, shall send the Floor Deny message. The Floor Deny message:

a. shall include in the Reject Cause field the <Reject Cause> value cause #7 (Queue full);

b. may include in the Reject Cause field an additional text string explaining the reason for rejecting the floor request in the <Reject Phrase> value; and

c. shall include the User ID field received in the Floor Request message; and

4. shall remain in ‘O: has permission’ state.

[TS 24.380, clause 7.2.3.5.8]

Upon receiving a Floor Queue Position Request message, the floor participant:

1. shall send the Floor Queue Position Info message. The Floor Queue Position Info message:

a. shall include the MCPTT ID of the queued floor participant in the Queued User ID field;

b. shall include the queue position and floor priority in the Queue Info field;

c. shall include the SSRC of floor participant sending Floor Queue Position Request message in SSRC of queue floor participant field; and

d. shall include the User ID of floor participant sending Floor Queue Position Request message in User ID field; and

2. remain in the ‘O: has permission’ state.

[TS 24.380, clause 7.2.3.5.6]

When no more encoded media is received from the user and if at least one Floor Request message is stored (i.e. queuing mode is used in the session), the floor participant:

1. shall stop timer T206 (Stop talking warning), if running;

2. shall stop timer T207 (Stop talking), if running;

3. shall request the MCPTT client to stop sending RTP media packets towards other MCPTT clients;

4. shall send the Floor Granted message toward the other floor participants. The Floor Granted message:

a. shall include the MCPTT ID of the first floor participant in the queue in the User ID field;

b. shall include the SSRC of the first floor participant in the queue in the SSRC of the granted floor participant field;

c. shall remove the first floor participant from the queue;

d for the remaining floor participants in the queue:

i. shall include the MCPTT ID of the floor participant in the Queued User ID field;

ii. shall include the SSRC of the floor participant in the SSRC of queued floor participant field;

iii. shall include the queue position of the floor participant in the Queue Info field; and

iv. shall include the priority of the floor participant in the Queue Info field; and

e. if the floor request is a broadcast group call, system call, emergency call or an imminent peril call, shall include a Floor Indicator field indicating the relevant call types;

5. shall set the stored SSRC of the current arbitrator to the SSRC of user to whom the floor was granted in the Floor Granted message;

6. shall start timer T205 (Floor Granted ) and shall initiate counter C205 (Floor Granted ) to 1; and

7 shall enter the ‘O: pending granted’ state.

[TS 24.380, clause 7.2.3.7.3]

On expiry of timer T205 (Floor Granted) and counter C205 (Floor Granted) is less than the upper limit, the floor participant:

1. shall send again the Floor Granted message toward the other floor participants. For each participant in the queue the Floor Granted message:

a. shall include the MCPTT ID of the floor participant in the Queued User ID field;

b. shall include the SSRC of the floor participant in the SSRC of queued floor participant field;

c. shall include the queue position of the floor participant in the Queue Info field; and

d. shall include the priority of the floor participant in the Queue Info field;

2. shall restart timer T205 (Floor Granted) and shall increment counter C205 (Floor Granted) by 1; and

3. shall remain in ‘O: pending granted’ state.

[TS 24.380, clause 7.2.3.7.5]

On the expiry of timer T205 (Floor Granted) for the configured upper limit of counter C205 (Floor Granted) with no request pending in the queue, the floor participant:

1. shall reset the value of counter C205 (Floor Granted) to 1;

2. shall start timer T230 (Inactivity);

3. shall clear the stored SSRC of the current arbitrator; and

4. shall enter ‘O: silence’ state.

[TS 24.380, clause 7.2.3.3.4]

When a Floor Granted message is received and if the User ID in the Floor Granted message does not match its own User ID, the floor participant:

1. may provide a floor taken notification to the MCPTT user;

2. if the Floor Indicator field is included and the B-bit is set to ‘1’ (Broadcast group call), shall provide a notification to the user indicating that this is a broadcast group call;

3. shall set the stored SSRC of the candidate arbitrator to the SSRC of user to whom the floor was granted in the Floor Granted message;

4. shall stop timer T230 (Inactivity);

5. shall start timer T203 (End of RTP media); and

6. shall enter ‘O: has no permission’ state.

[TS 24.380, clause 7.2.3.4.3]

When a Floor Release message is received and if the SSRC in the Floor Release message matches with the stored SSRC of the current arbitrator or with the stored SSRC of the candidate arbitrator, the floor participant:

1. may provide floor idle notification to the MCPTT user.

2. shall request the MCPTT client to stop rendering received RTP media packets;

3. shall stop timer T203 (End of RTP media);

4. shall start timer T230 (Inactivity);

5. shall clear the stored SSRC of the candidate arbitrator;

6. shall clear the stored SSRC of the current arbitrator; and

7. shall enter ‘O: silence’ state;

[TS 24.380, clause 7.2.3.3.6]

When a Floor Taken message is received, the floor participant:

1. may provide a floor taken notification to the MCPTT user;

2. shall set the stored SSRC of the current arbitrator to the SSRC of granted floor participant field in the Floor Taken message;

3. shall stop timer T230 (Inactivity);

4. shall start timer T203 (End of RTP media); and

5. shall enter ‘O: has no permission’ state.

[TS 24.380, clause 7.2.3.4.2]

If the floor participant receives an indication from the MCPTT user that the MCPTT user wants to send media, the floor participant:

1. shall send the Floor Request message to other clients. The Floor Request message:

a. if a priority different than the default floor priority is required, shall include the Floor Priority field with the requested priority in the <Floor Priority> element;

b. shall include the MCPTT ID of the MCPTT user in the User ID field; and

c. if the floor request is a broadcast group call, system call, emergency call or an imminent peril call, shall include a Floor Indicator field indicating the relevant call types;

2. shall initialize the counter C201 (Floor request) with value set to 1;

3. shall start timer T201 (Floor Request); and

4. shall enter ‘O: pending request’ state.

[TS 24.380, clause 7.2.3.6.4]

Upon receiving Floor Deny message, if the <User ID> value in the User ID field matches its own MCPTT ID and SSRC of floor participant sending the Floor Deny message matches the stored SSRC of current arbitrator, the floor participant:

1. shall stop the timer T201 (Floor Request);

2. shall provide floor deny notification to the user;

3. shall restart the timer T203 (End of RTP media);

4. may display the floor deny reason to the user using information in the Reject Cause field; and

5. shall enter ‘O: has no permission’ state.

Otherwise, if the <User ID> value in the User ID field matches its own MCPTT ID and there is no stored SSRC of the current arbitrator, the floor participant:

1. shall stop the timer T201 (Floor Request);

2. shall set the stored SSRC of the current arbitrator to the SSRC of the floor control server as received in the Floor Deny message;

3. shall restart the timer T203 (End of RTP media);

4. shall provide floor deny notification to the user;

5. may display the floor deny reason to the user using information in the Reject Cause field; and

6. shall enter ‘O: has no permission’ state.

Otherwise, if the <User ID> value in the User ID field matches its own MCPTT ID and SSRC of floor participant sending the Floor Deny message matches the stored SSRC of candidate arbitrator, the floor participant:

1. shall stop the timer T201 (Floor Request);

2. shall set the stored SSRC of the current arbitrator to the SSRC of the floor control server as received in the Floor Deny message;

3. shall clear the stored SSRC of the candidate arbitrator;

4. shall restart the timer T203 (End of RTP media);

5. shall provide floor deny notification to the user;

6. may display the floor deny reason to the user using information in the Reject Cause field; and

7. shall enter ‘O: has no permission’ state.

[TS 24.380, clause 7.2.3.6.3]

Upon receiving Floor Queue Position Info message, if the <User ID> value in the Queued User ID field matches its own MCPTT ID and the value in the SSRC of floor control server field as received in the Floor Queue Position Info message matches the stored SSRC of current arbitrator, the floor participant:

1. shall update the queue status;

2. may notify the MCPTT user about the queue position received in the <Queue position info> value in the Queue Info field;

3. shall stop timer T201 (Floor Request); and

4. shall enter ‘O: queued’ state.

Otherwise, if the <User ID> value in the Queued User ID field matches its own MCPTT ID and there is no stored SSRC of the current arbitrator, the floor participant:

1. shall update the queue status;

2. shall set the stored SSRC of the current arbitrator to the SSRC of the floor control server as received in the Floor Queue Position Info message;

3. may notify the MCPTT user about the queue position received in the <Queue position info> value in the Queue Info field;

4. shall stop timer T201 (Floor Request); and

5. shall enter ‘O: queued’ state.

Otherwise, if the <User ID> value in the Queued User ID field matches its own MCPTT ID and the value in the SSRC of floor control server field as received in the Floor Queue Position Info message matches the stored SSRC of candidate arbitrator, the floor participant:

1. shall update the queue status;

2. shall set the stored SSRC of the current arbitrator to the value in the SSRC of the floor control server field as received in the Floor Queue Position Info message;

3. shall clear the stored SSRC of the candidate arbitrator;

4. may notify the MCPTT user about the queue position received in the <Queue position info> value in the Queue Info field;

5. shall stop timer T201 (Floor Request); and

6. shall enter ‘O: queued’ state.

[TS 24.380, clause 7.2.3.8.11]

Upon receipt of an indication from the MCPTT client to request the queue position information, the floor participant:

1. shall send the Floor Queue Position Request message; The Floor Queue Position Request message:

a. shall include the SSRC of sent Floor Request message in SSRC of floor participant field; and

b. shall include the own MCPTT User ID in User ID field;

2. shall initialize the counter C204 (Floor Queue Position request) with value set to 1;

3. shall start timer T204 (Floor Queue Position request); and

4. remain in the ‘O: queued’ state.

[TS 24.380, clause 7.2.3.8.3]

Upon receiving Floor Queue Position Info message, if the <User ID> value in the User ID field matches its own MCPTT ID and SSRC of floor participant sending the Floor Queue Position Info message matches the stored SSRC of current arbitrator, the floor participant:

1. shall update the queue position;

2. shall notify the MCPTT user about the queue position received in the <Queue position info> value in the Queue Info field;

3. shall stop timer T204 (Floor Queue Position request); and

4. shall remain in ‘O: queued’ state.

Otherwise, if the <User ID> value in the User ID field matches its own MCPTT ID and SSRC of floor participant sending the Floor Queue Position Info message matches the stored SSRC of candidate arbitrator, the floor participant:

1. shall update the queue position;

2. shall set the stored SSRC of the current arbitrator to the SSRC of the floor control server as received in the Floor Queue Position Info message;

3. shall clear the stored SSRC of the candidate arbitrator;

4. shall notify the MCPTT user about the queue position received in the <Queue position info> value in the Queue Info field;

5. shall stop timer T204 (Floor Queue Position request); and

6. shall remain in ‘O: queued’ state.

[TS 24.380, clause 7.2.3.8.6]

1. shall request the MCPTT client to stop rendering received RTP media packets;

2. shall start timer T233(Pending user action), if not running already;

3. shall notify the MCPTT user about of the floor grant;

4. if the Floor Indicator field is included, and the B bit is set to ‘1’ (Broadcast group call), shall provide a notification to the user indicating the type of call; and

5. shall remain in ‘O: queued’ state.

1. shall request the MCPTT client to stop rendering received RTP media packets;

2. shall start timer T233(Pending user action), if not running already;

3. shall notify the MCPTT user about of the floor grant;

4. shall set the stored SSRC of the current arbitrator to its own SSRC;

5. shall clear the stored SSRC of the candidate arbitrator;

6. if the Floor Indicator field is included, and the B bit is set to ‘1’ (Broadcast group call), shall provide a notification to the user indicating the type of call; and

7. shall remain in ‘O: queued’ state.

[TS 24.380, clause 7.2.3.8.8]

If the floor participant receives an indication from the user that the user wants to send media and the timer T233 (pending user action) is running, the floor participant:

1. shall stop the timer T233 (Pending user action);

2. shall set the stored SSRC of the current floor arbitrator to its own SSRC; and

3. shall enter ‘O: has permission’ state.

[TS 24.380, clause 7.2.3.5.7]

Upon receiving a Floor Request message which is pre-emptive as determined by subclause 4.1.1.5, the floor participant:

1. shall stop timer T206 (Stop talking warning), if running;

2. shall stop timer T207 (Stop talking), if running;

3. shall request the MCPTT client to stop sending RTP media packets towards other MCPTT clients;

4. shall send a Floor Granted message towards the other floor participants. The Floor Granted message:

a. shall include the MCPTT ID of the Floor Request message received in the User ID field;

b. shall include the SSRC of floor participant sending the Floor Request message in the SSRC of floor control server field; and

c. if the value of "/<x>/<x>/OffNetwork/QueueUsage" leaf node present in the group configuration as specified in 3GPP TS 24.483 [4] is set to "true", for each floor participant in the queue:

i. shall include the MCPTT ID of the floor participant in the Queued User ID field;

ii. shall include the SSRC of the floor participant in the SSRC of queued floor participant field;

iii. shall include the queue position of the floor participant in the Queue Info field; and

iv. shall include the priority of the floor participant in the Queue Info field;

5. shall start timer T205 (Floor Granted) and shall initiate counter C205 (Floor Granted) to 1;

6. shall set the stored SSRC of the current floor arbitrator to the SSRC of the user to whom the floor was granted in the Floor Granted message; and

7. shall enter the ‘O: pending granted’ state.

[TS 24.380, clause 7.2.3.6.9]

On expiry of timer T201 (Floor Request) if the counter C201 (Floor Request) has not reached its upper limit, the floor participant:

1. shall send the Floor Request message to other floor participants. The Floor Request message:

a. if a priority different than the default floor priority is required, shall include the Floor Priority field with the requested priority in the <Floor Priority> element;

b. shall include the MCPTT ID of the own MCPTT user in the User ID field; and

c. if the floor request is a broadcast group call, system call, emergency call or an imminent peril call, shall include a Floor Indicator field indicating the relevant call types;

2. shall restart the timer T201 (Floor Request) and increment counter C201 (Floor Request) by 1; and

3. shall remain in the ‘O: pending request’ state.

[TS 24.380, clause 7.2.3.6.6]

When timer T201 (Floor Request) expires and counter C201 (Floor Request) reaches its upper limit, the floor participant:

1. shall send the Floor Taken message toward the other floor participants. The Floor Taken message:

a. shall include the floor participant’s own SSRC in the SSRC of the granted floor participant field;

b. shall include the floor participant’s own MCPTT ID in the User ID field; and

c. if the floor request is a broadcast group call, system call, emergency call or an imminent peril call, shall include a Floor Indicator field indicating the relevant call types;

2. shall set the stored SSRC of the current floor arbitrator to its own SSRC;

3. shall stop timer T203 (End of RTP media), if running; and

4. shall enter ‘O: has permission’ state.

7.1.1.3 Test description

7.1.1.3.1 Pre-test conditions

System Simulator:

– SS-UE1 (MCPTT client)

– For the underlying "transport bearer" over which the SS and the UE will communicate, the SS is behaving as SS-UE1 as defined in TS 36.508 [24], configured for and operating as ProSe Direct Communication transmitting and receiving device.

– GNSS simulator to simulate a location and provide a timing reference for the assistance of E-UTRAN off-network testing.

NOTE 1: For operation in off-network environment, it needs be ensured that after the UE is powered up it considers the Geographical area #1 that is simulated by the GNSS simulator as being one of the geographical areas set in the USIM for operation when UE is "not served by E-UTRAN".

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

NOTE 2: The SS operation as NW (MCPTT server) is needed only for the Preamble if the UE has to perform the Generic Test Procedure for MCPTT Authorization/Configuration and Key Generation as specified in TS 36.579-1 [2], subclause 5.3.2.

IUT:

– UE (MCPTT client)

– The test USIM set as defined in TS 36.579-1 [2], subclause 5.5.10 is inserted.

– For the underlying "transport bearer" over which the SS and the UE will communicate, the UE is behaving as a ProSe enabled UE as defined in TS 36.508 [24], configured for and operating as ProSe Direct Communication transmitting and receiving device.

Preamble:

— The UE has performed the Generic Test Procedure for MCPTT UE registration as specified in TS 36.579-1 [2], subclause 5.4.2.

– The MCPTT User performs the Generic Test Procedure for MCPTT Authorization/Configuration and Key Generation as specified in TS 36.579-1 [2], subclause 5.3.2.

– The GNSS simulator is configured to simulate a location in the centre of Geographical area #1 and provide a timing reference, as defined in TS 36.508 [24] Table 4.11.2-2 scenario #1.

– The UE is switched-off.

– UE States at the end of the preamble

– The UE is in state ‘switched-off’.

7.1.1.3.2 Test procedure sequence

Table 7.1.1.3.2-1: Main behaviour

St	Procedure	Message Sequence		TP	Verdict
		U – S	Message
1	Power up the UE	–	–	–	–
1A	Trigger the UE to reset UTC time and location. NOTE: The UTC time and location reset may be performed by MMI or AT command (+CUTCR).	–	–	–	–
2	Activate the MCPTT Client Application and register User A as the MCPTT User (TS 36.579-5 [5], px_MCPTT_User_A_username, px_MCPTT_User_A_password). (NOTE 1)	–	–	–	–
3	Make the UE (MCPTT Client) initiate an off-network basic group call (NOTE 1)	–	–	–	–
–	EXCEPTION: The E-UTRA/EPC actions which are related to the MCPTT off-network call establishment are described in TS 36.579-1 [2], subclause 5.4.11 ‘Generic Test Procedure for MCPTT CO communication over ProSe direct one-to-many communication out of E-UTRA coverage / Monitoring/Discoverer procedure for group member discovery / One-to-many communication’. The test sequence below shows only the MCPTT relevant messages exchanged.	–	–	–	–
4	Check: Does the UE (MCPTT client) send a GROUP CALL PROBE message to determine the current call status of the group? (NOTE 2)	–>	GROUP CALL PROBE	1	P
–	EXCEPTION: Step 5 is executed a total of 3 times
5	Check: At the expiration of timer TFG3 (call probe retransmission), does the UE (MCPTT Client) send a retransmission of the GROUP CALL PROBE sent in step 4?	–>	GROUP CALL PROBE	1	P
6	Check: At the expiration of timer TFG1 (wait for call announcement), and after receiving no response to the GROUP CALL PROBE, does the UE (MCPTT Client) send a GROUP CALL ANNOUNCEMENT message to initiate an off-network basic group call?	–>	GROUP CALL ANNOUNCEMENT	1	P
7	The SS-UE1 (MCPTT client) sends a GROUP CALL ACCEPT accepting the GROUP CALL ANNOUNCEMENT	<–	GROUP CALL ACCEPT	–	–
8	Check: Does the UE (MCPTT Client) send a Floor Granted message towards the other floor participants?	–>	Floor Granted	2	P
9	Make the UE (MCPTT User) release the floor (NOTE 1), (NOTE 3)	–	–	–	–
10	Check: Does the UE (MCPTT Client) send a Floor Release message to the other floor participants?	–>	Floor Release	2	P
11	Make the UE (MCPTT User) request the floor (NOTE 1), (NOTE 4)	–	–	–	–
12	Check: Does the UE (MCPTT Client) send a Floor Request message to the floor participants?	–>	Floor Request	2	P
13	The SS-UE1 (MCPTT client) sends a Floor Granted message granting the floor to the UE (MCPTT Client)	<–	Floor Granted	–	–
14	The SS-UE1 (MCPTT client), having the same priority as the UE (MCPTT Client), sends a Floor Request message to the UE (MCPTT Client) with the F bit in the Floor Indication field set to ‘0’ indicating that the requesting UE does not support queueing	<–	Floor Request	–	–
15	Check: Does the UE (MCPTT Client) send a Floor Deny message to the sender of the Floor Request message with the Reject Cause field set to #1 (Another MCPTT client has permission)?	–>	Floor Deny	2	P
16	The SS-UE1 (MCPTT client), having the same priority as the UE (MCPTT Client), sends a Floor Request message to the UE (MCPTT Client) with the F bit in the Floor Indication field set to ‘1’	<–	Floor Request	–	–
17	Check: Does the UE (MCPTT Client) add the requester to the queue and send a Floor Queue Position Info message to the sender of the Floor Request message?	–>	Floor Queue Position Info	2	P
18	The SS-UE1 (MCPTT client) sends a Floor Queue Position Request message to the UE (MCPTT Client)	<–	Floor Queue Position Request	–	–
19	Check: Does the UE (MCPTT Client) respond to the Floor Queue Position Request message with e a Floor Queue Position Info message?	–>	Floor Queue Position Info	2	P
20	Make the UE (MCPTT User) release the floor (NOTE 1), (NOTE 5)	–	–	–	–
21	Check: Does the UE (MCPTT Client) send a Floor Granted message to the floor participants indicating the queued participant now has the floor? (NOTE 6)	–>	Floor Granted	2	P
–	EXCEPTION: Step 22 is executed a total of 3 times	–	–	–	–
22	Check: Upon expiry of timer T205 (Floor Granted) and while counter C205 (Floor Granted) is less than its maximum value, does the UE (MCPTT Client) retransmit the Floor Granted message send in step 21?	–>	Floor Granted	2	P
23	Void	–	–	2	P
24	The SS-UE1 (MCPTT client) sends a Floor Taken message to the UE (MCPTT Client)	<–	Floor Taken	–	–
25	Make the UE (MCPTT User) request the floor (NOTE 1)	–	–	–	–
26	Check: Does the UE (MCPTT Client) send a Floor Request message to the floor participants?	–>	Floor Request	2	P
27	The SS-UE1 (MCPTT client) responds with a Floor Deny message	<–	Floor Deny	–	–
28	Make the UE (MCPTT User) request the floor (NOTE 1)	–	–	–	–
29	Check: Does the UE (MCPTT Client) send a Floor Request message to the floor participants?	–>	Floor Request	2	P
30	The SS-UE1 (MCPTT client) responds with a Floor Queue Position Info message and places the UE (MCPTT Client) in the queue	<–	Floor Queue Position Info	–	–
31	Make the UE (MCPTT User) request the queue position of the UE (MCPTT Client) (NOTE 1)	–	–	–	–
32	Check: Does the UE (MCPTT Client) send a Floor Queue Position Request message?	–>	Floor Queue Position Request	2	P
33	The SS-UE1 (MCPTT client) responds with a Floor Queue Position Info message	<–	Floor Queue Position Info	–	–
34	The SS-UE1 (MCPTT client) sends a Floor Granted message to the UE (MCPTT Client) granting the floor to the UE (MCPTT Client)	<–	Floor Granted	–	–
35	Check: Does the UE (MCPTT Client) notify the user (MCPTT User) of the floor grant? (NOTE 1)	–	–	2	P
36	Make the UE (MCPTT User) accept the floor grant (NOTE 1)	–	–	–	–
37	The SS-UE1 (MCPTT client), with a higher priority than the UE (MCPTT Client), sends a Floor Request message with preemption	<–	Floor Request	–	–
38	Check: Does the UE (MCPTT Client) respond by sending a Floor Granted message? (NOTE 6)	–>	Floor Granted	2	P
–	EXCEPTION: Step 39 is executed a total of 3 times	–	–	–	–
39	Check: Upon expiry of timer T205 (Floor Granted) and while counter C205 (Floor Granted) is less than its maximum value, does the UE (MCPTT Client) retransmit the Floor Granted message send in step 38?	–>	Floor Granted	2	P
40	Void	–	–	2	P
41	Make the UE (MCPTT User) request the floor (NOTE 1)	–	–	–	–
42	Check: Does the UE (MCPTT Client) send a Floor Request message to the floor participants? (NOTE 7)	–>	Floor Request	2	P
–	EXCEPTION: Step 43 is executed a total of 2 times	–	–	–	–
43	Check: Upon expiry of timer T201 (Floor Request) and while counter C201 (Floor Request) is less than its maximum value, does the UE (MCPTT Client) retransmit the Floor Request message send in step 42?	–>	Floor Request	2	P
44	Check: Upon expiry of timer T201 (Floor Request) and with counter C201 (Floor Request) equal to its maximum value, does the UE (MCPTT Client) send a Floor Taken message?	–>	Floor Taken	2	P
45	Make the UE (MCPTT User) release the floor (NOTE 1)	–	–	–	–
46	Check: Does the UE (MCPTT Client) send a Floor Release message to the other floor participants?	–>	Floor Release	2	P
47	Make the UE (MCPTT Client) upgrade the off-network group call to an emergency call (NOTE 1)	–	–	–	–
48	Check: Does the UE (MCPTT Client) send a GROUP CALL ANNOUNCEMENT to upgrade the call to an emergency call?	–>	GROUP CALL ANNOUNCEMENT	3	P
49	Check: Does the UE (MCPTT Client) send a Floor Granted message towards the other floor participants?	–>	Floor Granted	4	P
50	Make the UE (MCPTT User) release the floor (NOTE 1)	–	–	–	–
51	Check: Does the UE (MCPTT Client) send a Floor Release message to the other floor participants?	–>	Floor Release	4	P
52	Make the UE (MCPTT Client) downgrade the off-network group call from an emergency call (NOTE 1)	–	–	–	–
53	Check: Does the UE (MCPTT Client) send a GROUP CALL EMERGENCY END to downgrade the emergency call?	–>	GROUP CALL EMERGENCY END	5	P
54	Make the UE (MCPTT Client) upgrade the off-network group call to an imminent peril call (NOTE 1)
55	Check: Does the UE (MCPTT Client) send a GROUP CLL ANNOUNCEMENT to upgrade the call to an imminent peril call?	–>	GROUP CALL ANNOUNCEMENT	6	P
56	Check: Does the UE (MCPTT Client) send a Floor Granted message towards the other floor participants?	–>	Floor Granted	7	P
57	Make the UE (MCPTT User) release the floor (NOTE 1)	–	–	–	–
58	Check: Does the UE (MCPTT Client) send a Floor Release message to the other floor participants?	–>	Floor Release	7	P
59	Make the UE (MCPTT Client) downgrade the off-network group call from an imminent peril call (NOTE 1)	–	–	–	–
60	Check: Does the UE (MCPTT Client) send a GROUP CALL IMMINENT PERIL END to downgrade the imminent peril call?	–>	GROUP CALL IMMINENT PERIL END	8	P
61	Make the UE (MCPTT Client) release the group call (NOTE 1)	–	–	–	–
NOTE 1: This is expected to be done via a suitable implementation dependent MMI. NOTE 2: Timer TFG3 (call probe retransmission)=40ms as defined in TS 36.579-1 [2], Table 5.5.8.1-1 and TFG1 (wait for call announcement)=150ms as defined in TS 36.579-1 [2], Table 5.5.8.1-1 are started upon the sending of the GROUP CALL PROBE message NOTE 3: If the MCPTT User does not release the floor before timer T207 (Stop talking) expires, then the MCPTT Client will enter the ‘O: silence’ state per TS 24.380 [10] and the remaining steps will not be valid. Timer T206 (Stop talking warning) is started upon the sending of the Floor Granted message. Timer T207 (Stop talking) starts upon the expiration of Timer T206 (Stop talking warning). Timer T206 (Stop talking warning)=10s is set to TransmitTimeout=60s, as defined in TS 36.579-1 [2], Table 5.5.8.4-1, minus TransmissionWarning=50s, as defined in TS 36.579-1 [2], Table 5.5.8.4-1. Timer T207 (Stop talking)=50s is set to TransmissionWarning=50s, as defined in TS 36.579-1 [2], Table 5.5.8.4-1. If during test execution it is found that the specified timer(s) value(s) are not large enough, then new value(s) need to be specified. NOTE 4: If the MCPTT User does not perform an action before timer T230 (Inactivity) expires, then the MCPTT Client will enter the ‘O: ‘Start-stop” state per 24.380 [10] and the remaining steps will not be valid. Timer T230 (Inactivity) is started upon the sending of the Floor Release message. Timer T230 (Inactivity)=10s, as defined in TS 36.579-1 [2], Table 5.5.8.1-1. If during test execution it is found that the specified timer value is not large enough, then a new value needs to be specified. NOTE 5: If the MCPTT User does not release the floor before timer T207 (Stop talking) expires, then the MCPTT Client will enter the ‘O: silence’ state per 24.380 [10] and the remaining steps will not be valid. Timer T206 (Stop talking warning) is started upon the receiving of the Floor Granted message in step 13. Timer T207 (Stop talking) starts upon the expiration of Timer T206 (Stop talking warning). Timer T206 (Stop talking warning)=10s is set to TransmitTimeout=60s, as defined in TS 36.579-1 [2], Table 5.5.8.4-1, minus TransmissionWarning=50s, as defined in TS 36.579-1 [2], Table 5.5.8.4-1. Timer T207 (Stop talking)=50s is set to TransmissionWarning=50s, as defined in TS 36.579-1 [2], Table 5.5.8.4-1. If during test execution it is found that the specified timer(s) value(s) are not large enough, then new value(s) need to be specified. NOTE 6: Timer T205 (Floor Granted) and Counter C205 (Floor Granted) are started upon the sending of the Floor Granted message. Timer T205 (Floor Granted)=1s, as defined in TS 36.579-1 [2], Table 5.5.8.1-1. Counter C205 (Floor Granted) is set to 1 and the maximum value of C205 (Floor Granted)=4, as defined in TS 36.579-1 [2], Table 5.5.8.1-1. NOTE 7: Timer T201 (Floor Request) and Counter C201 (Floor Request) are started upon the sending of the Floor Request message. Timer T201 (Floor Request)=1s, as defined in TS 36.579-1 [2], Table 5.5.8.1-1. Counter 201 (Floor Request) is set to 1 and the maximum value of Counter C201 (Floor Request)=3, as defined in TS 36.579-1 [2], Table 5.5.8.1-1.

7.1.1.3.3 Specific message contents

Table 7.1.1.3.3-1: GROUP CALL ANNOUNCEMENT (step 48, Table 7.1.1.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.5.2.1-1
Information Element	Value/remark	Comment	Condition
Call type	"00000011"	Emergency group call

Table 7.1.1.3.3-2: GROUP CALL ANNOUNCEMENT (step 55, Table 7.1.1.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.5.2.1-1
Information Element	Value/remark	Comment	Condition
Call type	"00000100"	Imminent peril group call

Table 7.1.1.3.3-3: Floor Granted (step 8, Table 7.1.1.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.6.3-1 condition OFF-NETWORK
Information Element	Value/remark	Comment	Condition
Duration
Duration	any allowed value
Floor priority	"0"
Floor Indicator
Floor Indicator	"10000X0000000000"	bit A=1 (Normal call) bit F=X (Queueing supported) any value

Table 7.1.1.3.3-4: Floor Granted (steps 13, 34, Table 7.1.1.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.6.3-1 condition OFF-NETWORK
Information Element	Value/remark	Comment	Condition
Floor Indicator
Floor Indicator	‘1000010000000000’	bit A=1 (Normal call) bit F=1 (Queueing supported)

Table 7.1.1.3.3-5: Floor Granted (steps 21, 22, 38, 39, Table 7.1.1.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.6.3-1 condition OFF-NETWORK
Information Element	Value/remark	Comment	Condition
Duration
Duration	any allowed value	128 sec (an arbitrary value)
SSRC of granted floor participant	"10000000 11111111 00000000 10000000"	The SSRC of the floor participant being granted the floor, in this case the SSRC of MCPTT-client-B
User ID
User ID	Px_MCPTT_User_B_ID
Floor Indicator
Floor Indicator	"10000X0000000000"	bit A=1 (Normal call) bit F=X (Queueing supported) any value

Table 7.1.1.3.3-6: Floor Granted (step 49, Table 7.1.1.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.6.3-1 condition OFF-NETWORK
Information Element	Value/remark	Comment	Condition
Duration
Duration	any allowed value	128 sec (an arbitrary value)
Floor priority	"0"
Floor Indicator
Floor Indicator	‘00010X0000000000’	bit D=1 (Emergency call) bit F=X (Queueing supported) any value

Table 7.1.1.3.3-7: Floor Granted (step 56, Table 7.1.1.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.6.3-1 condition OFF-NETWORK
Information Element	Value/remark	Comment	Condition
Duration
Duration	any allowed value	128 sec (an arbitrary value)
Floor priority	"0"
Floor Indicator
Floor Indicator	‘00001X0000000000’	bit E=1 (Imminent Peril call) bit F=X (Queueing supported) any value

Table 7.1.1.3.3-8: Floor Release (steps 10, 46, Table 7.1.1.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.6.5-1 condition OFF-NETWORK
Information Element	Value/remark	Comment	Condition
Floor Indicator
Floor Indicator	"10000X0000000000"	bit A=1 (Normal call) bit F=X (Queueing supported) any value

Table 7.1.1.3.3-9: Floor Release (step 51, Table 7.1.1.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.6.5-1 condition OFF-NETWORK
Information Element	Value/remark	Comment	Condition
Floor Indicator
Floor Indicator	‘00010X0000000000’	bit D=1 (Emergency call) bit F=X (Queueing supported) any value

Table 7.1.1.3.3-10: Floor Release (step 58, Table 7.1.1.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.6.5-1 condition OFF-NETWORK
Information Element	Value/remark	Comment	Condition
Floor Indicator
Floor Indicator	‘00001X0000000000’	bit E=1 (Imminent Peril call) bit F=X (Queueing supported) any value

Table 7.1.1.3.3-11: Floor Request (steps 12, 26, 29, 42, 43, Table 7.1.1.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.6.2-1 condition OFF-NETWORK
Information Element	Value/remark	Comment	Condition
Floor Indicator
Floor Indicator	"10000X0000000000"	bit A=1 (Normal call) bit F=X (Queueing supported) any value

Table 7.1.1.3.3-12: Floor Request (step 14, Table 7.1.1.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.6.2-1 condition OFF-NETWORK
Information Element	Value/remark	Comment	Condition
User ID
User ID	Px_MCPTT_User_B_ID
Floor Indicator
Floor Indicator	"10000000000000000"	bit A=1 (Normal call) bit F=0 (Queueing not supported)

Table 7.1.1.3.3-13: Floor Request (step 16, Table 7.1.1.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.6.2-1 condition OFF-NETWORK
Information Element	Value/remark	Comment	Condition
User ID
User ID	Px_MCPTT_User_B_ID
Floor Indicator
Floor Indicator	"10000100000000000"	bit A=1 (Normal call) bit F=1 (Queueing supported)

Table 7.1.1.3.3-14: Floor Request (step 37, Table 7.1.1.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.6.2-1 condition OFF-NETWORK
Information Element	Value/remark	Comment	Condition
Floor Priority	"12"	Priority is higher than mcptt-client-A
User ID
User ID	Px_MCPTT_User_B_ID
Floor Indicator
Floor Indicator	"10000100000000000"	bit A=1 (Normal call) bit F=1 (Queueing supported)

Table 7.1.1.3.3-15: Floor Deny (step 15, Table 7.1.1.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.6.4-1 condition OFF-NETWORK
Information Element	Value/remark	Comment	Condition
Reject Cause
Reject Cause	any allowed value
Reject Phrase	not present or any allowed value
User ID
User ID	Px_MCPTT_User_B_ID
Floor Indicator
Floor Indicator	"10000X0000000000"	bit A=1 (Normal call) bit F=X (Queueing supported) any value

Table 7.1.1.3.3-16: Floor Deny (step 27, Table 7.1.1.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.6.4-1 condition OFF-NETWORK
Information Element	Value/remark	Comment	Condition
Floor Indicator
Floor Indicator	"10000100000000000"	bit A=1 (Normal call) bit F=1 (Queueing supported)

Table 7.1.1.3.3-17: Floor Queue Position Info (steps 17, 19, Table 7.1.1.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.6.10-1 condition OFF-NETWORK
Information Element	Value/remark	Comment	Condition
User ID
User ID	Px_MCPTT_User_A_ID
Queued User ID
Queued User ID	Px_MCPTT_User_B_ID
Queue Info
Queue Position Info	"1"
Queue Priority Level	any allowed value
Floor Indicator
Floor Indicator	"10000X0000000000"	bit A=1 (Normal call) bit F=X (Queueing supported) any value

Table 7.1.1.3.3-18: Floor Queue Position Info (steps 30, 33, Table 7.1.1.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.6.10-1 condition OFF-NETWORK
Information Element	Value/remark	Comment	Condition
User ID
User ID	Px_MCPTT_User_B_ID
Queued User ID
Queued User ID	Px_MCPTT_User_A_ID
Queue Info
Queue Position Info	"1"
Queue Priority Level	"0"
Floor Indicator
Floor Indicator	‘1000010000000000’	bit A=1 (Normal call) bit F=1 (Queueing supported)

Table 7.1.1.3.3-19: Floor Queue Position Request (step 18, Table 7.1.1.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.6.9-1 condition OFF-NETWORK
Information Element	Value/remark	Comment	Condition
User ID
User ID	Px_MCPTT_User_B_ID

Table 7.1.1.3.3-20: Floor Taken (step 24, Table 7.1.1.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.6.7-1 condition OFF-NETWORK
Information Element	Value/remark	Comment	Condition
User ID
User ID	Px_MCPTT_User_B_ID
Granted Party’s Identity
Granted Party’s Identity	Px_MCPTT_User_B_ID
Floor Indicator
Floor Indicator	‘1000010000000000’	bit A=1 (Normal call) bit F=1 (Queueing supported)

Table 7.1.1.3.3-21: Floor Taken (step 44, Table 7.1.1.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.6.7-1 condition OFF-NETWORK
Information Element	Value/remark	Comment	Condition
Granted Party’s Identity
Granted Party’s Identity	Px_MCPTT_User_A_ID
Floor Indicator
Floor Indicator	"10000X0000000000"	bit A=1 (Normal call) bit F=X (Queueing supported) any value
SSRC of granted floor participant	"10000000 11111111 00000000 00000001"