7.1.2 Off-network / Group Call / Floor Control / Upgrade to Emergency Call / Downgrade from Emergency / Upgrade to Imminent Peril / Downgrade from Imminent Peril / Release Call / Client Terminated (CT)

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.2.1 Test Purpose (TP)

(1)

with { UE (MCPTT Client) registered and authorised for MCPTT Service, including authorised to receive group calls in off-network environment, and the UE configured that user acknowledgement is not required, and the UE (MCPTT Client) is in an off-network environment }

ensure that {

when { UE (MCPTT Client) receives a GROUP CALL ANNOUNCEMENT message with Confirm mode indication present }

then { UE (MCPTT Client) enters the "S3: part of ongoing call" state and sends a GROUP CALL ACCEPT message}

}

(2)

with { UE (MCPTT Client) being in 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) being in an upgraded 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 }

}

(4)

with { UE (MCPTT Client) being in an upgraded 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 }

}

7.1.2.2 Conformance requirements

References: The conformance requirements covered in the current TC are specified in: TS 24.379 clauses 10.2.2.4.3.3, 10.2.3.4.5, 10.2.3.4.7.2, 10.2.3.4.8.3, 10.2.3.4.8.6, 10.2.2.4.5.4, TS 24.380 clauses 7.2.3.2.7, 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.3.3]

When in the "S1: start-stop" state, upon receiving a GROUP CALL ANNOUNCEMENT message with the MCPTT group ID IE not matching MCPTT group ID of the call stored for other state machines, the MCPTT client:

1) shall store the value of the SDP IE of the GROUP CALL ANNOUNCEMENT message as the SDP body of the call;

2) shall store the value of the Call identifier IE of the GROUP CALL ANNOUNCEMENT message as the call identifier of the call;

3) shall store the value of the Originating MCPTT user ID IE of the GROUP CALL ANNOUNCEMENT message as the originating MCPTT user ID of the call;

4) shall store the value of the Refresh interval IE of the GROUP CALL ANNOUNCEMENT message as the refresh interval of the call;

5) shall store the value of the MCPTT group ID IE of the GROUP CALL ANNOUNCEMENT message as the MCPTT group ID of the call;

6) shall store the value of the Call start time IE of the GROUP CALL ANNOUNCEMENT message as the call start time of the call;

7) shall create a call type control state machine as described in subclause 10.2.3.2;

…

9) if the terminating UE is configured that the terminating MCPTT user acknowledgement is not required upon a terminating call request reception:

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

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

c) if the GROUP CALL ANNOUNCEMENT message contains the Confirm mode indication IE:

i) shall generate a GROUP CALL ACCEPT message as specified in subclause 15.1.4. In the GROUP CALL ACCEPT message, the MCPTT client:

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

B) shall set the Sending MCPTT user ID IE to own MCPTT user id;

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

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

ii) shall send the GROUP CALL ACCEPT message as specified in subclause 10.2.1.1.1;

d) shall start timer TFG6 (max duration) with value as specified in subclause 10.2.2.4.1.2;

e) shall start timer TFG2 (call announcement) with value as specified in subclause 10.2.2.4.1.1.1; and

f) shall enter the "S3: part of ongoing call" state.

[TS 24.379, clause 10.2.3.4.5]

When in the "T0: waiting for the call to establish" state, upon receipt of a GROUP CALL ANNOUNCEMENT message by an idle MCPTT client when MCPTT user acknowledgement is not required, the MCPTT client:

1) shall set the stored last call type change time to the Last call type change time IE of the GROUP CALL ANNOUNCEMENT message;

2) shall set the last user to change call type to the Last user to change call type IE of the GROUP CALL ANNOUNCEMENT message;

3) if the Call type IE of the received GROUP CALL ANNOUNCEMENT message is set to "EMERGENCY GROUP CALL":

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 start timer TFG13 (implicit downgrade emergency) with value as specified in subclause 10.2.3.4.1.1; and

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

4) if the Call type IE of the received GROUP CALL ANNOUNCEMENT message is set to "IMMINENT PERIL GROUP CALL":

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 in3GPP TS 24.383 [45];

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

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

5) if the Call type IE of the received GROUP CALL ANNOUNCEMENT message is set to "BASIC GROUP CALL":

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

b) 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]; and

c) shall enter "T2: in-progress basic group call" state.

[TS 24.379, clause 10.2.3.4.7.2]

When in the "T1: in-progress emergency group call" state or "T2: in-progress basic group call" state or "T3: in-progress imminent peril group call" state, upon receiving a GROUP CALL ANNOUNCEMENT message with the MCPTT group ID IE matching with MCPTT group ID of the ongoing call and the Call Identifier IE being the same as the stored call identifier of the call, the MCPTT client:

1) if the stored last user to change call type of the call is same as the Last user to change call type IE of the GROUP CALL ANNOUNCEMENT message and the stored last call type change time is smaller than Last call type change time IE of the GROUP CALL ANNOUNCEMENT message:

a) shall set the stored last call type change time of the call to Last call type change time IE of the GROUP CALL ANNOUNCEMENT message;

b) if the Call type IE of the received GROUP CALL ANNOUNCEMENT message is set to "EMERGENCY GROUP CALL" and the stored call type is other than "EMERGENCY GROUP CALL":

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

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];

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

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

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

c) if the Call type IE of the received GROUP CALL ANNOUNCEMENT message is set to "IMMINENT PERIL GROUP CALL" and the stored call type is other than "IMMINENT PERIL GROUP CALL":

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

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];

iii) shall stop timer TFG13 (implicit downgrade emergency), if running;

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

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

d) if the Call type IE of the received GROUP CALL ANNOUNCEMENT message is set to "BASIC GROUP CALL" and the stored call type is other than "BASIC GROUP CALL":

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

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];

iii) shall stop timer TFG13 (implicit downgrade emergency), if running;

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

v) shall enter "T2: in-progress basic group call" state; and

2) if the stored last user to change call type of the call is different from the Last user to change call type IE of the GROUP CALL ANNOUNCEMENT message and:

a) if the stored call type is same as Call type IE in the received GROUP CALL ANNOUNCEMENT message and the stored last call type change time is smaller than Last call type change time IE of the GROUP CALL ANNOUNCEMENT message:

i) shall set the stored last call type change time of the call to Last call type change time IE of the GROUP CALL ANNOUNCEMENT message; and

ii) shall set the stored last user to change call type of the call to Last user to change call type IE of the GROUP CALL ANNOUNCEMENT message;

b) if the Call type IE of the received GROUP CALL ANNOUNCEMENT message is set to "EMERGENCY GROUP CALL" and the stored call type is other than "EMERGENCY GROUP CALL":

i) shall set the stored last call type change time of the call to Last call type change time IE of the GROUP CALL ANNOUNCEMENT message;

ii) shall set the stored last user to change call type of the call to Last user to change call type IE of the GROUP CALL ANNOUNCEMENT message;

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

iv) 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];

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

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

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

c) if the Call type IE of the received GROUP CALL ANNOUNCEMENT message is set to "IMMINENT PERIL GROUP CALL" and the stored call type is "BASIC GROUP CALL":

i) shall set the stored last call type change time of the call to Last call type change time IE of the GROUP CALL ANNOUNCEMENT message;

ii) shall set the stored last user to change call type of the call to Last user to change call type IE of the GROUP CALL ANNOUNCEMENT message;

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

iv) 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];

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

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

d) if the Call type IE of the received GROUP CALL ANNOUNCEMENT message is set to "BASIC GROUP CALL" and the stored call type is other than "BASIC GROUP CALL":

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

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.483 [45];

iii) shall stop timer TFG13 (implicit downgrade emergency), if running;

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

v) shall enter "T2: in-progress basic group call" state.

[TS 24.379, clause 10.2.3.4.8.3]

When in the "T1: in-progress emergency group call" state, upon receiving GROUP CALL EMERGENCY END message, the MCPTT client:

1) shall set the stored last call type change time to the Last call type change time IE of the received GROUP CALL EMERGENCY END message;

2) shall set the stored last user to change call type to the Last user to change call type IE of the received GROUP CALL EMERGENCY END message;

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

4) 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];

5) shall stop timer TFG13 (implicit downgrade emergency); and

6) shall enter the "T2: in-progress basic group call" state.

[TS 24.379, clause 10.2.3.4.8.6]

When in the "T3: in-progress imminent peril group call" state, upon receiving GROUP CALL IMMINENT PERIL END message, the MCPTT client:

1) shall set the stored last call type change time to the Last call type change time IE of the received GROUP CALL IMMINENT PERIL END message;

2) shall set the stored last user to change call type to the Last user to change call type IE of the received GROUP CALL IMMINENT PERIL END message;

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

4) 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];

5) shall stop timer TFG14 (implicit downgrade imminent peril); and

6) shall enter the "T2: in-progress basic group call" state.

[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 as specified in subclause 10.2.3.4.10 or 10.2.3.4.11; and

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

[TS 24.380, clause 7.2.3.2.7]

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. shall create an instance of a floor participant state transition diagram for basic operation state machine;

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

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 start timer T203 (End of RTP media); and

5. shall enter ‘O: has no 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.2.3 Test description

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

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.2.3.2 Test procedure sequence

Table 7.1.2.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)	–	–	–	–
–	EXCEPTION: The E-UTRA/EPC actions which are related to the MCPTT call establishment are described in TS 36.579-1 [2], subclause 5.4.10 ‘Generic Test Procedure for MCPTT CT communication over ProSe direct one-to-many communication out of E-UTRA coverage / Announcing/Discoveree procedure for group member discovery / One-to-many communication’. The test sequence below shows only the MCPTT relevant messages exchanged.	–	–	–	–
3	SS-UE1 (MCPTT client) sends a GROUP CALL ANNOUNCEMENT	<–	GROUP CALL ANNOUNCEMENT	–	–
4	Check: Does the UE (MCPTT Client) send a GROUP CALL ACCEPT message?	–>	GROUP CALL ACCEPT	1	P
5	SS-UE1 (MCPTT client) sends a Floor Granted message notifying the recipients that it now has the floor	<–	Floor Granted	–	–
6	Make the UE (MCPTT User) request the floor (NOTE 1), (NOTE 2)	–	–	–	–
7	Check: Does the UE (MCPTT Client) send a Floor Request message to the floor participants?	–>	Floor Request	2	P
8	The SS-UE1 (MCPTT client) sends a Floor Granted message granting the floor to the UE (MCPTT Client)	<–	Floor Granted	–	–
9	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’	<–	Floor Request	–	–
10	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
11	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	–	–
12	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
13	The SS-UE1 (MCPTT client) sends a Floor Queue Position Request message to the UE (MCPTT Client)	<–	Floor Queue Position Request	–	–
14	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
15	Make the UE (MCPTT User) release the floor.(NOTE 1)	–	–	–	–
16	Check: Does the UE (MCPTT Client) send a Floor Granted message to the floor participants indicating the queued participant now has the floor? (NOTE 4)	–>	Floor Granted	2	P
–	EXCEPTION: Step 17 is executed a total of 3 times	–	–	–	–
17	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 16?	–>	Floor Granted	2	P
18	Void	–	–	–	–
19	The SS-UE1 (MCPTT client) sends a Floor Taken message to the UE (MCPTT Client)	<–	Floor Taken	–	–
20	Make the UE (MCPTT User) request the floor (NOTE 1)	–	–	–	–
21	Check: Does the UE (MCPTT Client) send a Floor Request message to the floor participants?	–>	Floor Request	2	P
22	The SS-UE1 (MCPTT client) responds with a Floor Deny message	<–	Floor Deny	–	–
23	Make the UE (MCPTT User) request the floor (NOTE 1)	–	–	–	–
24	Check: Does the UE (MCPTT Client) send a Floor Request message to the floor participants?	–>	Floor Request	2	P
25	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	–	–
26	Make the UE (MCPTT User) request the queue position of the UE (MCPTT Client) (NOTE 1)	–	–	–	–
27	Check: Does the UE (MCPTT Client) send a Floor Queue Position Request message?	–>	Floor Queue Position Request	2	P
28	The SS-UE1 (MCPTT client) responds with a Floor Queue Position Info message	<–	Floor Queue Position Info	–	–
29	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	–	–
30	Check: Does the UE (MCPTT Client) notify the user (MCPTT User) of the floor grant? (NOTE 1)	–	–	2	P
31	Make the UE (MCPTT User) accept the floor grant (NOTE 1)	–	–	–	–
32	The SS-UE1 (MCPTT client), with a higher priority than the UE (MCPTT Client), sends a Floor Request message with preemption	<–	Floor Request	–	–
33	Check: Does the UE (MCPTT Client) respond by sending a Floor Granted message? (NOTE 4)	–>	Floor Granted	2	P
–	EXCEPTION: Step 34 is executed a total of 3 times	–	–	–	–
34	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 33?	–>	Floor Granted	2	P
35	Void	–	–	–	–
36	Make the UE (MCPTT User) request the floor (NOTE 1)	–	–	–	–
37	Check: Does the UE (MCPTT Client) send a Floor Request message to the floor participants? (NOTE 5)	–>	Floor Request	2	P
–	EXCEPTION: Step 38 is executed a total of 2 times	–	–	–	–
38	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 37?	–>	Floor Request	2	P
39	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
40	Make the UE (MCPTT User) release the floor (NOTE 1)	–	–	–	–
41	Check: Does the UE (MCPTT Client) send a Floor Release message to the other floor participants?	–>	Floor Release	2	P
42	The SS-UE1 (MCPTT client) sends a GROUP CALL ANNOUNCEMENT to upgrade the call to an emergency call	<–	GROUP CALL ANNOUNCEMENT	–	–
43	SS-UE1 (MCPTT client) sends a Floor Granted message notifying the recipients that it now has the floor	<–	Floor Granted	–	–
44	Void	–	–	3	P
45	Make the UE (MCPTT User) request the floor (NOTE 1)	–	–	–	–
46	Check: Does the UE (MCPTT Client) send a Floor Request message to the floor participants?	–>	Floor Request	3	P
47	The SS-UE1 (MCPTT client) responds with a Floor Deny message	<–	Floor Deny	–	–
48	SS-UE1 (MCPTT client) sends a Floor Release message	<–	Floor Release	–	–
49	The SS-UE1 (MCPTT client) sends a GROUP CALL EMERGENCY END to downgrade the emergency call	<–	GROUP CALL EMERGENCY END
50	Void	–	–	–	–
51	The SS-UE1 (MCPTT client) sends a GROUP CALL ANNOUNCEMENT to upgrade the call to an imminent peril call	<–	GROUP CALL ANNOUNCEMENT	–	–
52	SS-UE1 (MCPTT client) sends a Floor Granted message notifying the recipients that it now has the floor	<–	Floor Granted	–	–
53	Void	–	–	–	–
54	Make the UE (MCPTT User) request the floor (NOTE 1)	–	–	–	–
55	Check: Does the UE (MCPTT Client) send a Floor Request message to the floor participants?	–>	Floor Request	4	P
56	The SS-UE1 (MCPTT client) responds with a Floor Deny message	<–	Floor Deny	–	–
57	SS-UE1 (MCPTT client) sends a Floor Release message	<–	Floor Release	–	–
58	The SS-UE1 (MCPTT client) sends a GROUP CALL IMMINENT PERIL END to downgrade the imminent peril call	<–	GROUP CALL IMMINENT PERIL END
59	Void	–	–	8	P
60	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: If the user does not request the floor before timer T203 (End of RTP media) expires, then the MCPTT Client will enter ‘O: silence’ state per 24.380 [10] and the remaining steps will not be valid. Timer T203 (End of RTP media)=5s as defined in TS 36.579-1 [2], Table 5.5.8.1-1 and is started upon the reception of the Floor Granted message in step 5. 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 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 receiving of the Floor Granted message in step 8. 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: 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 5: 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.2.3.3 Specific message contents

Table 7.1.2.3.3-1: GROUP CALL ANNOUNCEMENT (step 42, Table 7.1.2.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.2.3.3-2: GROUP CALL ANNOUNCEMENT (step 51, Table 7.1.2.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.2.3.3-3: Floor Granted (step 5, Table 7.1.2.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"
User ID
User ID	Px_MCPTT_User_B_ID
Floor Indicator
Floor Indicator	"1000010000000000"	bit A=1 (Normal call) bit F=1 (Queueing supported)

Table 7.1.2.3.3-4: Floor Granted (steps 8, 29, Table 7.1.2.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.2.3.3-5: Floor Granted (steps 16, 17, 33, 34, Table 7.1.2.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)
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.2.3.3-6: Floor Granted (step 43, Table 7.1.2.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"
User ID
User ID	Px_MCPTT_User_B_ID
Floor Indicator
Floor Indicator	"0001010000000000"	bit D=1 (Emergency call) bit F=1 (Queueing supported)

Table 7.1.2.3.3-7: Floor Granted (step 52, Table 7.1.2.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"
User ID
User ID	Px_MCPTT_User_B_ID
Floor Indicator
Floor Indicator	"0000110000000000"	bit E=1 (Imminent Peril call) bit F=1 (Queueing supported)

Table 7.1.2.3.3-8: Floor Request (steps 7, 21, 37, 38, 46, 55, Table 7.1.2.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.2.3.3-9: Floor Request (step 9, Table 7.1.2.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.2.3.3-10: Floor Request (step 11, Table 7.1.2.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.2.3.3-11: Floor Request (step 32, Table 7.1.2.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.2.3.3-12: Floor Deny (step 10, Table 7.1.2.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.2.3.3-13: Floor Deny (step 22, Table 7.1.2.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
User ID
User ID	Px_MCPTT_User_A_ID
Floor Indicator
Floor Indicator	"10000100000000000"	bit A=1 (Normal call) bit F=1 (Queueing supported)

Table 7.1.2.3.3-14: Floor Deny (step 47, Table 7.1.2.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
User ID
User ID	Px_MCPTT_User_A_ID
Floor Indicator
Floor Indicator	"00010100000000000"	bit D=1 (Emergency call) bit F=1 (Queueing supported)

Table 7.1.2.3.3-15: Floor Deny (step 56, Table 7.1.2.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
User ID
User ID	Px_MCPTT_User_A_ID
Floor Indicator
Floor Indicator	"00001100000000000"	bit E=1 (Imminent Peril call) bit F=1 (Queueing supported)

Table 7.1.2.3.3-16: Floor Queue Position Info (steps 12, 14, Table 7.1.2.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.2.3.3-17: Floor Queue Position Info (steps 25, 28, Table 7.1.2.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
Floor Indicator
Floor Indicator	"1000010000000000"	bit A=1 (Normal call) bit F=1 (Queueing supported)

Table 7.1.2.3.3-18: Floor Queue Position Request (step 13, Table 7.1.2.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.2.3.3-19: Floor Taken (step 19, Table 7.1.2.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
Floor Indicator
Floor Indicator	"1000010000000000"	bit A=1 (Normal call) bit F=1 (Queueing supported)

Table 7.1.2.3.3-20: Floor Taken (step 39, Table 7.1.2.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

Table 7.1.2.3.3-21: Floor Release (step 41, Table 7.1.2.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.2.3.3-22: Floor Release (step 48, Table 7.1.2.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
User ID
User ID	Px_MCPTT_User_B_ID
Floor Indicator
Floor Indicator	"0001010000000000"	bit D=1 (Emergency call) bit F=1 (Queueing supported)

Table 7.1.2.3.3-23: Floor Release (step 57, Table 7.1.2.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
User ID
User ID	Px_MCPTT_User_B_ID
Floor Indicator
Floor Indicator	"0000110000000000"	bit E=1 (Imminent Peril call) bit F=1 (Queueing supported)