6 MCPTT Service requirements specific to on-network use

22.1793GPPMission Critical Push to Talk (MCPTT)Release 17Stage 1TS

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

6.1 General administrative – groups and users

[R-6.1-001] Void

[R-6.1-002] Void

[R-6.1-003] Void

[R-6.1-004] Void.

[R-6.1-005] Void.

[R-6.1-006] Void

[R-6.1-007] Void

6.2 MCPTT calls

6.2.1 Commencement modes for MCPTT Group calls

[R-6.2.1-001] The MCPTT Service shall be capable of allowing an MCPTT Group call setup request to proceed without prior acknowledgement by any MCPTT User of that MCPTT Group.

[R-6.2.1-001a] The MCPTT Service shall be capable of allowing an MCPTT Group Call setup request to proceed only if a minimum number of MCPTT Group Members are currently affiliated.

[R-6.2.1-001b] The MCPTT Service shall be capable of allowing an MCPTT Group Call setup request to proceed only if specific MCPTT Group Member(s) are currently affiliated.

[R-6.2.1-002] An MCPTT User currently affiliated to an MCPTT Group shall acknowledge receipt of an MCPTT Group call setup request, if requested to do so by the MCPTT Service.

[R-6.2.1-003] The MCPTT User’s acknowledgement may require direct interaction of the MCPTT UE with the human user, or may be automatically executed by the MCPTT UE, in accordance with policy established by an MCPTT Administrator.

[R-6.2.1-004] The MCPTT Service shall be capable of requiring that a minimum number of Affiliated MCPTT Group Members acknowledges receipt of the MCPTT Group call setup request before the audio transmission proceeds.

[R-6.2.1-005] The MCPTT Service shall be capable of requiring that specific MCPTT Users acknowledge receipt of the MCPTT Group call setup request before the audio transmission proceeds, regardless of the affiliation state of those users.

NOTE 1: In this case the MCPTT Service affiliates the specific MCPTT Users who are not currently affiliated to the target MCPTT Group and then returns them to their previous affiliation state when the transmission ends.

[R-6.2.1-006] The MCPTT Service shall be capable of requiring that all MCPTT Users that are both affiliated to the MCPTT Group and in a given geographical area acknowledge receipt of an MCPTT Group call setup request before the audio transmission proceeds.

[R-6.2.1-007] The MCPTT Service shall provide a mechanism for an MCPTT Administrator to determine the subset of Affiliated MCPTT Group Members that shall acknowledge receipt of the MCPTT Group call setup request before the audio transmission proceeds.

NOTE 2: In the following requirements, the term, "MCPTT Group Call setup request requires acknowledgement" is used when one or more of the acknowledgement conditions defined above (i.e., [R-6.2.1-004], [R-6.2.1-005], [R-6.2.1-006], and/or [R-6.2.1-007]) applies.

[R-6.2.1-008] If an MCPTT Group Call setup request requires acknowledgement from Affiliated MCPTT Group Members, and the required MCPTT Group Members do not acknowledge the call setup within a configured time (the "acknowledged call setup timeout"), the MCPTT Service may proceed with the call and then may notify the initiating MCPTT User that the acknowledgements did not include all required members.

[R-6.2.1-009] If an MCPTT Group Call setup request requires acknowledgement from Affiliated MCPTT Group Members, and the required MCPTT Group Members do not acknowledge the call setup within a configured time, the MCPTT Service may abandon the call and then may notify the initiating MCPTT User that the acknowledgements did not include all required members.

[R-6.2.1-010] If an MCPTT Group Call setup request requires acknowledgement from Affiliated MCPTT Group Members, the initiating MCPTT User shall at any time have the option of allowing the call to proceed regardless of the state of the acknowledgements (i.e., to "convert" the call to an unacknowledged call).

[R-6.2.1-010a] If an MCPTT Group Call setup request requires acknowledgement from Affiliated MCPTT Group Members, and the required MCPTT Group Members did not acknowledge the call setup within a configured time, the MCPPT Service shall be able to provide the list of MCPTT Group Members who did not acknowledge the call to the initiating MCPTT User.

[R-6.2.1-011] If an MCPTT Group Call setup request requires acknowledgement from Affiliated MCPTT Group Members, the acknowledged call setup timeout shall be established by an MCPTT Administrator.

[R-6.2.1-012] If an MCPTT Group Call setup request requires acknowledgement from Affiliated MCPTT Group Members, the behaviour in response to the expiration of the acknowledged call setup timeout shall be established by an MCPTT Administrator.

[R-6.2.1-013] If an MCPTT Group Call setup request requires acknowledgement from Affiliated MCPTT Group Members, the MCPTT Service shall support an indefinite (i.e., infinite) call setup timeout.

[R-6.2.1-014] If the MCPTT Service has knowledge that some affiliated members of a group can not be Participants in an unacknowledged MCPTT Group Call, the MCPTT Service shall provide an indication to the requester that the call is proceeding without all affiliated members, and shall provide the list of the missing members based on policy established by the MCPTT Administrator.

[R-6.2.1-015] If MCPTT User(s) are excluded from an MCPTT call as there is insufficient capacity to support their participation the MCPTT Service shall ensure that the MCPTT User(s) receive a notification that they have been excluded from the call for reasons of lack of capacity.

6.2.2 Queuing

[R-6.2.2-001] Void

[R-6.2.2-002] Void

[R-6.2.2-003] Void

[R-6.2.2-004] Void

[R-6.2.2-005] Void

[R-6.2.2-006] Void

6.2.3 Floor control

6.2.3.1 General aspects

[R-6.2.3.1-001] The Floor control functionality in an MCPTT Service shall determine at a point in time which Participant(s) are allowed to transmit to other Participant(s).

[R-6.2.3.1-002] Receiving Participant(s) shall receive audio from one transmitting Participant. The only exception is if an MCPTT Group is configured to allow simultaneous Transmitting MCPTT Group Members in override.

[R-6.2.3.1-003] The MCPTT Service shall provide a mechanism for the MCPTT Administrator to configure the number (maximum of N9) of simultaneous audios received by an MCPTT User in a single MCPTT Group.

6.2.3.2 Requesting permission to transmit

[R-6.2.3.2-001] An authorized Participant shall be able to request to transmit to an MCPTT Group or an individual Participant.

[R-6.2.3.2-002] At call setup the MCPTT Service shall provide a notification, for example audio and/or visual, to the MCPTT Group Member attempting to transmit that there are no other Group Members who have affiliated to the MCPTT Group.

[R-6.2.3.2-003] The Floor control functionality shall determine the transmitting Participant(s) when there are simultaneous requests for permission to transmit within the same call.

[R-6.2.3.2-004] Following an MCPTT Request for permission to transmit on the Selected MCPTT Group, the Affiliated MCPTT Group Member that made and was granted the request shall be given an indication of being allowed to transmit.

[R-6.2.3.2-005] Following an MCPTT Request for permission to transmit on the Selected MCPTT Group, an Affiliated MCPTT Group Member that made and was not granted the request shall be given an indication that permission to transmit was rejected or queued.

[R-6.2.3.2-006] The depth of the Floor control queue shall be configurable.

[R-6.2.3.2-007] Following an MCPTT Private Call (with Floor control) request for permission to transmit, the MCPTT User that is allowed to transmit shall be given an indication that the user is allowed to transmit to the targeted MCPTT User.

[R-6.2.3.2-008] Following an MCPTT Private Call (with Floor control) request for permission to transmit, an MCPTT User that is not allowed to transmit shall be given an indication that the permission to transmit was rejected or queued.

[R-6.2.3.2-009] The MCPTT Service shall provide an indication to receiving Participants that the transmitting Participant is starting to transmit.

[R-6.2.3.2-010] The MCPTT Service shall provide a mechanism for an MCPTT Participant to remove its MCPTT Request from the Floor control queue.

[R-6.2.3.2-011] The MCPTT Service shall provide a mechanism for removal (i.e., request accepted, request denied, or expiration of a timer) of an MCPTT Request from the Floor control queue.

[R-6.2.3.2-012] The MCPTT Service shall provide a mechanism for the MCPTT Administrator to configure the parameter(s) of the Floor control queue for an MCPTT Group (i.e., timer).

6.2.3.3 Override

6.2.3.3.1 General aspects

[R-6.2.3.3.1-001] The MCPTT Service shall enable MCPTT Administrators to create a priority hierarchy for determining what Participants, Participant types, and urgent transmission types shall be granted a request to override an active MCPTT transmission.

[R-6.2.3.3.1-002] The MCPTT Service shall enable an MCPTT Administrator to configure which MCPTT Group transmission a Participant(s) receives, overriding and/or overridden for cases where an authorized Participant overrides an MCPTT transmission.

[R-6.2.3.3.1-003] The MCPTT Service shall enable the MCPTT Administrator to configure the MCPTT Group to allow only the overriding Participant to transmit or to allow both the overriding and overridden Participant to transmit.

[R-6.2.3.3.1-004] The MCPTT Service shall provide a mechanism for an MCPTT Administrator to configure MCPTT Private Calls (with Floor control) to allow only the overriding Participant to transmit or to allow both the overriding and overridden Participant to transmit.

[R-6.2.3.3.1-005] The priority hierarchy used for granting a request to override an active MCPTT transmission shall contain at least four (4) levels.

[R-6.2.3.3.1-006] The transmitting Participant shall be determined by the relative Floor control priorities of the Participants and Call type based on priority (e.g MCPTT Emergency).

[R-6.2.3.3.1-007] The MCPTT Service shall provide a mechanism for Participants, to override an active MCPTT transmission of a transmitting Participant when the priority level of the overriding Participant or Call type based on priority (e.g MCPTT Emergency) are ranked higher than the priority level of the transmitting Participant or Call type based on priority.

[R-6.2.3.3.1-008] If an authorized Participant overrides an MCPTT transmission, the MCPTT Service shall provide a means of notifying the overridden Participant(s) that the transmission has been overridden.

6.2.3.3.2 Override – one transmitting Participant

[R-6.2.3.3.2-001] If the MCPTT Group has been configured to only allow the overriding transmitting Participant, the MCPTT Service shall revoke the transmit permission of the overridden transmitting Participant.

6.2.3.3.3 Override – simultaneously Transmitting MCPTT Group Members

[R-6.2.3.3.3-001] If the MCPTT Group has been configured to allow both overriding and overridden transmitting Participants, authorized receiving Participants shall be enabled to listen to both the overriding and overridden Participant transmissions, dependent on configuration.

[R-6.2.3.3.3-002] The MCPTT Service shall allow successive overrides of an MCPTT Group Call when the request to override is made by an MCPTT User having a higher Floor control priority than the currently transmitting Participants.

[R-6.2.3.3.3-003] In the case of successive overrides, the MCPTT Service shall enable only two transmissions, one overriding transmission, from the highest priority MCPTT User, and one overridden transmission, chosen from among the two overridden Participants based upon configured rule(s). (i.e., this could be based simply on priority of user, it could be based on a policy that an overridden MCPTT Emergency transmission shall remain as the overridden transmission or a rule could be established that the MCPTT system shall not allow two dispatchers to be both the overriding and overridden transmitters.).

6.2.3.4 Terminating permission to transmit

[R-6.2.3.4-001] The MCPTT Service shall enable an authorized MCPTT User to terminate the permission to transmit of a transmitting Participant at any time.

[R-6.2.3.4-002] A transmitting Participant shall be able to indicate to the MCPTT Service that the Participant no longer wants to transmit.

NOTE: In this case audio stops being transmitted to the receiver Participant(s) until an authorized Participant sends a subsequent request for permission to transmit.

[R-6.2.3.4-003] The MCPTT Service shall provide an indication to receiving Participants that the transmitting Participant has finished transmitting.

6.2.3.5 Transmit time limit

[R-6.2.3.5-001] The MCPTT Service shall enable an MCPTT Administrator to configure the limit for the length of time that a Participant transmits from a single request to transmit.

[R-6.2.3.5-002] The Floor control functionality shall have a configurable limit for the length of time that a Participant transmits from a single request to transmit.

[R-6.2.3.5-003] The Floor control functionality shall provide an indication to the transmitting Participant that the Participant is within a configurable amount of time before his transmit time limit is reached.

[R-6.2.3.5-004] The Floor control functionality shall provide an indication to the transmitting Participant that the Participant’s transmit time limit has been reached.

[R-6.2.3.5-005] The Floor control functionality shall remove the permission to transmit from the transmitting Participant when the Participant’s transmit time limit has been reached.

6.2.3.6 Audio cut-in on designated MCPTT Groups

6.2.3.6.1 Overview

The audio cut-in feature applies to specially designated MCPTT Groups and results in Floor control for that group allowing any participant within the MCPTT Group to interrupt any other participant. In particular the audio cut-in feature means that the last Participant to request the floor is assigned the floor immediately and there is only ever one talker on the call at a particular point in time. Audio cut-in is often used for teams escorting VIPs where timeliness is essential to allow teams to react as quickly as possible.

Other than the difference in floor control logic, the MCPTT Groups configured to support audio cut-in behave in the same way as other MCPTT Groups with group management, affiliation, selection of a group, requesting the floor, the notifications received related to Floor control etc working in the same way.

6.2.3.6.2 Requirements

[R-6.2.3.6.2-001] The MCPTT Group shall be configurable to allow audio cut-in.

NOTE 1: MCPTT Groups configured for audio cut-in behave in the same way as MCPTT Groups not configured for audio cut-in in all other respects other than the Floor control logic described in this sub-clause.

[R-6.2.3.6.2-002] When an MCPTT Group has been configured to support audio cut-in, the Floor control functionality shall give the floor to the MCPTT Group Member that has selected that MCPTT Group and made the most recent request to transmit in that MCPTT Group.

NOTE 2: Requests to transmit that are received simultaneously will be addressed by manufacturer implementation.

[R-6.2.3.6.2-003] When an MCPTT Group has been configured to support audio cut-in the Floor control functionality shall restrict the number of talkers in the group to one.

[R-6.2.3.6.2-004] When an MCPTT Group has been designated to support audio cut-in the MCPTT Group shall not support any form of floor control queuing and associated functionality.

[R-6.2.3.6.2-005] When the current talker is interrupted by a request to transmit on an MCPTT Group supporting audio cut-in, the talk request of the interrupted talker shall end.

NOTE 3: The interrupted talker must make a new request to transmit in order to transmit again.

[R-6.2.3.6.2-006] Void

[R-6.2.3.6.2-007] Void

6.2.3.6.3 Requesting permission to transmit

[R-6.2.3.6.3-001] An authorized Participant shall be able to request to transmit to an MCPTT Group configured to support audio cut-in.

[R-6.2.3.6.3-002] At call setup the MCPTT Service shall provide a notification, for example audio and/or visual, to the MCPTT Group Member attempting to transmit that there are no other Group Members who have affiliated to the MCPTT Group configured to support audio cut-in.

[R-6.2.3.6.3-003] Following an MCPTT Request for permission to transmit on the Selected MCPTT Group configured to support audio cut-in, the Affiliated MCPTT Group Member that made and was granted the request shall be given an indication of being allowed to transmit.

[R-6.2.3.6.3-004] The MCPTT Service shall provide an indication to receiving Participants that the transmitting Participant is starting to transmit on a group configured for audio cut-in.

6.2.3.6.4 Terminating permission to transmit

[R-6.2.3.6.4-001] The MCPTT Service shall enable an authorized MCPTT User to terminate the permission to transmit of a transmitting Participant at any time on a group configured for audio cut-in.

[R-6.2.3.6.4-002] A transmitting Participant shall be able to indicate to the MCPTT Service that the Participant no longer wants to transmit on a group configured for audio cut-in.

NOTE: In this case audio stops being transmitted to the receiver Participant(s) until an authorized Participant sends a subsequent request for permission to transmit.

[R-6.2.3.6.4-003] The MCPTT Service shall provide an indication to receiving Participants that the transmitting Participant has finished transmitting on a group configured for audio cut-in.

6.2.3.6.5 Transmit time limit

[R-6.2.3.6.5-001] The MCPTT Service shall enable an MCPTT Administrator to configure the limit for the length of time that a Participant transmits from a single request to transmit on a group configured for audio cut-in.

[R-6.2.3.6.5-002] The Floor control functionality for a group configured for audio cut-in shall have a configurable limit for the length of time that a Participant transmits from a single request to transmit.

[R-6.2.3.6.5-003] The Floor control functionality for a group configured for audio cut-in shall provide an indication to the transmitting Participant that the Participant is within a configurable amount of time before his transmit time limit is reached.

[R-6.2.3.6.5-004] The Floor control functionality for a group configured for audio cut-in shall provide an indication to the transmitting Participant that the Participant’s transmit time limit has been reached.

[R-6.2.3.6.5-005] The Floor control functionality for a group configured for audio cut-in shall remove the permission to transmit from the transmitting Participant when the Participant’s transmit time limit has been reached.

6.2.3.7 MCPTT Groups configured for multi-talker control

6.2.3.7.1 Overview

The multi-talker control applies to designated MCPTT Groups and results in allowing several Participants talking simultaneously within the MCPTT Group. For example, Multi-talker control is used by railway communication e.g. during shunting operation.

Except for Floor control as specified in clauses 6.2.3.1, 6.2.3.2, 6.2.3.3 and 6.2.3.6 all other requirements specified in 6.2.3 floor control are applicable to MCPTT Groups configured to support multi-talker control

When an MCPTT Group is configured for multi-talker control, the requirements listed below apply.

6.2.3.7.2 General aspects

[R-6.2.3.7.2-001] An MCPTT Group shall be configurable to allow multi-talker control.

[R-6.2.3.7.2-002] The MCPTT Service shall provide a mechanism for multiple MCPTT Users to talk simultaneously in an MCPTT Group configured for multi-talker control.

[R-6.2.3.7.2-003] The MCPTT Service shall determine which Participant(s) are allowed to transmit to all other Participant(s) in an MCPTT Group configured for multi-talker control.

[R-6.2.3.7.2-004] The MCPTT Service shall support all Participant(s) to receive audio from all other Participant(s) that are transmitting in an MCPTT Group configured for multi-talker control.

[R-6.2.3.7.2-005] The MCPTT Service shall provide a mechanism for the MCPTT Administrator to configure the maximum number of simultaneous talkers in an MCPTT Group configured for multi-talker control.

[R-6.2.3.7.2-006] The MCPTT Service shall allow an authorized MCPTT User to change the maximum number of simultaneous talkers at any time during a group call in an MCPTT Group configured for multi-talker control.

6.2.3.7.3 Requesting permission to transmit

[R-6.2.3.7.3-001] The MCPTT Service shall enable authorized Participants to request to transmit to an MCPTT Group configured for multi-talker control.

[R-6.2.3.7.3-002] At call setup the MCPTT Service shall provide a notification, for example audio and/or visual, to the MCPTT Group Member attempting to transmit that there are no other Group Members who have affiliated to the MCPTT Group configured for multi-talker control.

[R-6.2.3.7.3-003] The MCPTT Service shall determine the transmitting Participant(s) when there are simultaneous requests for permission to transmit within the same call for an MCPTT Group configured for multi-talker control.

[R-6.2.3.7.3-004] Following an MCPTT Request for permission to transmit on the Selected MCPTT Group configured for multi-talker control the MCPTT Service shall provide an Affiliated MCPTT Group Member that made and was granted the request an indication of being allowed to transmit.

6.2.3.7.4 Override

6.2.3.7.4.1 General aspects

[R-6.2.3.7.4.1-001] If the number of MCPTT Users requesting the permission to talk exceeds the maximum number of simultaneous talkers in an MCPTT Group configured for multi-talker control, the MCPTT Service shall apply the override mechanism.

[R-6.2.3.7.4.1-002] The MCPTT Service shall enable MCPTT Administrators to create a priority hierarchy for determining what Participants, Participant types, and urgent transmission types shall be granted a request to override an active MCPTT transmission on an MCPTT Group configured for multi-talker control.

[R-6.2.3.7.4.1-003] The priority hierarchy used for granting a request to override an active MCPTT transmission on a group configured for multi-talker control shall contain at least four (4) levels.

[R-6.2.3.7.4.1-004] The transmitting Participant onan MCPTT Group a group configured for multi-talker control shall be determined by the relative priorities of the Participants and Call type based on priority (e.g MCPTT Emergency).

[R-6.2.3.7.4.1-005] Transmission requests of Participants with insufficient relative priority shall be rejected.

[R-6.2.3.7.4.1-006] The MCPTT Service shall provide a mechanism for Participants, to override an active MCPTT transmission of a transmitting Participant when the priority level of the overriding Participant or Call type based on priority (e.g MCPTT Emergency) are ranked higher than the priority level of the transmitting Participant or Call type based on priority for an MCPTT Group configured for multi-talker control.

[R-6.2.3.7.4.1-007] If an authorized Participant overrides an MCPTT transmission, the MCPTT Service shall provide a means of notifying the overridden Participant(s) that the transmission has been overridden for an MCPTT Group configured for multi-talker control.

[R-6.2.3.7.4.1-008] The MCPTT Service shall revoke the transmit permission of the overridden transmitting Participant on an MCPTT Group configured for multi-talker control.

6.2.4 Call termination

[R-6.2.4-001] If a Participant of an MCPTT Group call is pre-empted, the MCPTT Service shall terminate the call or continue the call with an indication to the transmitting Participant that one or more receiving Participants was pre-empted.

[R-6.2.4-002] If MCPTT User(s) are pre-empted from an ongoing MCPTT call as there is insufficient capacity to support their ongoing participation, the MCPTT Service shall ensure that the MCPTT User(s) receive a notification that they have been removed from the call for reasons of lack of capacity.

[R-6.2.4-003] The MCPTT Service shall terminate a call after the Hang Time expires.

[R-6.2.4-004] Void.

[R-6.2.4-005] The MCPTT Service shall provide an indication to the Participants that the call is within a configurable amount of time before the call time limit is reached.

[R-6.2.4-006] The MCPTT Service shall release the call when the call time limit has been reached.

[R-6.2.4-007] The MCPTT Service shall provide an indication to the Participants that the call time limit has been reached.

[R-6.2.4-008] The MCPTT Service shall release an MCPTT Group call if any of the termination conditions are met (e.g., last Participant leaving, second last Participant leaving, initiator leaving) or the minimum number of Affiliated MCPTT Group Members are not present.

6.3 General requirements

[R-6.3-001] Void

[R-6.3-002] Void

[R-6.3-003] Void

[R-6.3-004] Void

6.4 General group call

6.4.1 General aspects

[R-6.4.1-001] Void

6.4.2 Group status/information

[R-6.4.2-001] Void

[R-6.4.2-002] Void

[R-6.4.2-003] Void

[R-6.4.2-004] Void

[R-6.4.2-005] Void

[R-6.4.2-006] Void

[R-6.4.2-007] Void

6.4.3 Identification

[R-6.4.3-001] Void

[R-6.4.3-002] Void

6.4.4 Membership/affiliation

[R-6.4.4-001] Void

[R-6.4.4-002] Void

6.4.5 Membership/affiliation list

[R-6.4.5-001] Void

[R-6.4.5-002] Void

[R-6.4.5-003] Void

[R-6.4.5-004] Void

[R-6.4.5-005] Void

[R-6.4.5-006] Void

[R-6.4.5-007] Void

[R-6.4.5-008] Void

6.4.6 Authorized user remotely changes another MCPTT User’s affiliated and/or Selected MCPTT Group(s)

6.4.6.1 Mandatory change

[R-6.4.6.1-001] Void

[R-6.4.6.1-002] Void

[R-6.4.6.1-003] Void

[R-6.4.6.1-004] Void

6.4.6.2 Negotiated change

[R-6.4.6.2-001] Void

[R-6.4.6.2-002] Void

[R-6.4.6.2-003] Void

[R-6.4.6.2-004] Void

[R-6.4.6.2-005] Void

[R-6.4.6.2-006] Void

6.4.7 Prioritization

[R-6.4.7-001] Void

[R-6.4.7-002] Void

[R-6.4.7-003] Void

[R-6.4.7-004] Void

6.4.8 Relay requirements

[R-6.4.8-001] Void

6.4.9 Administrative

[R-6.4.9-001] Void

[R-6.4.9-002] The MCPTT Service shall provide a mechanism for an MCPTT Administrator to set a predefined time period (Hang Time) without any traffic in MCPTT calls (with Floor control), after which the MCPTT calls shall terminate.

[R-6.4.9-003] Void

[R-6.4.9-004] Void

[R-6.4.9-005] Void

[R-6.4.9-006] Void

[R-6.4.9-007] Void

6.5 Broadcast group

6.5.1 General Broadcast Group Call

[R-6.5.1-001] Void

[R-6.5.1-002] Void

6.5.2 Group-Broadcast Group (e.g., announcement group)

[R-6.5.2-001] Void

6.5.3 User-Broadcast Group (e.g., System Call)

[R-6.5.3-001] Void

6.6 Dynamic group management (i.e., dynamic regrouping)

6.6.1 General dynamic regrouping

[R-6.6.1-001] Void

[R-6.6.1-002] Void

[R-6.6.1-003] Void

[R-6.6.1-004] Void

[R-6.6.1-005] Void

[R-6.6.1-006] Void

6.6.2 Group Regrouping

6.6.2.1 Service description

Group Regrouping enables dispatchers or any authorized user to temporarily combine MCPTT Groups. A dispatcher uses Group Regrouping for different reasons.

Due to an incident in an area it can be necessary to temporarily enable MCPTT Users from different MCPTT Groups to communicate to each other to coordinate. After the incident the dispatcher cancels the Group Regrouping and the MCPTT Users continue with their original configured MCPTT Groups.

During quiet periods control room managers can decide to combine MCPTT Groups and handle their operations and communications with one dispatcher. In the busier period the Group Regrouping is cancelled and the MCPTT Groups are handled by separate dispatchers.

6.6.2.2 Requirements

[R-6.6.2.2-001] Void

[R-6.6.2.2-002] Void

[R-6.6.2.2-003] Void

[R-6.6.2.2-004] Void

[R-6.6.2.2-005] Void

[R-6.6.2.2-006] Void

[R-6.6.2.2-007] Void

6.6.3 Temporary Group-Broadcast Group

[R-6.6.3-001] Void

[R-6.6.3-002] Void

6.6.4 User regrouping

6.6.4.1 Service description

In the operational MCPTT environment most tasks are covered by standard procedures and communication structures and MCPTT Users can easily access the MCPTT Groups to handle their tasks.

Exceptionally it could happen that there is an urgent need for a dedicated set of individual MCPTT Users to communicate in an MCPTT Group, but that this is not foreseen in the communication structure. This could be due to extreme conditions or due to a cooperation that is outside normal procedures.

User Regrouping enables dispatchers or authorized users to instantaneously provide a dedicated MCPTT Group to these MCPTT Users to enable the required communication. Depending on configuration the MCPTT Users could be automatically affiliated to this MCPTT Group. After the operation this MCPTT Group is removed by the dispatcher or authorized user.

6.6.4.2 Requirements

[R-6.6.4.2-001] Void

[R-6.6.4.2-002] Void

[R-6.6.4.2-003] Void

[R-6.6.4.2-004] Void

[R-6.6.4.2-005] Void

6.7 Private Call

6.7.0 Overview

Private Calls can use Floor control or not. Private Calls (without Floor control) are only supported on network, whereas Private Calls (with Floor control) are supported both on and off network. Private Calls (without Floor contol) are intended to have the same functionality as specified for Private Calls (with Floor control) in subclauses 5.6.2, 5.6.3, 5.6.4, 5.6.5. Comparable requirements are included in subclauses 6.7.1, 6.7.2, 6.7.4 and 6.7.5, with the exception of R-5.6.5-005, which is specific to Private Calls (with Floor control).

6.7.1 General requirements

[R-6.7.1-001] The on-network MCPTT Service shall support two types of Private Calls, one which uses Floor control and one which does not.

NOTE: An MCPTT Private Call (without Floor control) is effectively a full voice duplex call between two users.

[R-6.7.1-002] Void

[R-6.7.1-003] Void

[R-6.7.1-004] Void

[R-6.7.1-005] Void

[R-6.7.1-006] Void

[R-6.7.1-007] Void

[R-6.7.1-008] Void

[R-6.7.1-009] Void

[R-6.7.1-010] The MCPTT Service shall provide a mechanism by which specified Participants or Participant types (e.g., dispatch) have the ability to override an active PTT transmission of the other Participant in the Private Call.

[R-6.7.1-011] Void

[R-6.7.1-012] The MCPTT Service shall provide the status (e.g., ringing, accepted, rejected, active) of an MCPTT Private Call (without Floor control) to the relevant MCPTT User that is a Participant of the MCPTT Private Call (without Floor control).

[R-6.7.1-013] The MCPTT Service shall provide a mechanism for an authorized MCPTT User that is a called party in an MCPTT Private Call (without Floor control), to restrict providing the reason why an MCPTT Private Call (without Floor control) setup has failed to the calling MCPTT User.

[R-6.7.1-014] Void

6.7.2 Administrative

[R-6.7.2-001] Void

[R-6.7.2-002] Void

[R-6.7.2-003] Void

[R-6.7.2-004] Void

[R-6.7.2-005] Void

[R-6.7.2-006] Void

[R-6.7.2-007] Void

[R-6.7.2-008] Void

6.7.3 Prioritization

[R-6.7.3-001] Void

[R-6.7.3-002] Void

[R-6.7.3-003] Void

[R-6.7.3-004] Void

[R-6.7.3-005] Void

[R-6.7.3-006] Void

[R-6.7.3-007] Void

6.7.4 Private Call (without Floor control) commencement requirements

[R-6.7.4-001] The MCPTT Service shall support Call Commencement Modes for Private Calls (without Floor control), which determine the conditions under which Private Calls (without Floor control) are set up.

[R-6.7.4-002] The MCPTT Service shall provide a mechanism for an MCPTT User to cancel an MCPTT Private Call (without Floor control) prior to the call setup.

[R-6.7.4-003] The MCPTT Service shall provide a means by which an authorized MCPTT User initiates an MCPTT Private Call (without Floor control).

[R-6.7.4-004] Void

[R-6.7.4-005] The MCPTT Service shall provide a means by which an MCPTT User initiates a Manual Commencement Private Call (without Floor control) to any MCPTT User for which the MCPTT User is authorized.

[R-6.7.4-006] The MCPTT Service shall require that the called MCPTT User accepts a Manual Commencement Private Call (without Floor control) setup request before the call proceeds.

[R-6.7.4-007] The MCPTT Service shall provide a means for an MCPTT User to accept a Manual Commencement Private Call (without Floor control) request from another MCPTT User.

[R-6.7.4-008] Void

[R-6.7.4-009] The MCPTT UE shall support automatic commencement mode and manual commencement mode for Private Calls (without Floor control).

[R-6.7.4-010]The MCPTT Service shall provide a manual commencement mode countermand by which an authorized MCPTT User may request that the invited MCPTT UE answers automatically.

[R-6.7.4-011] Void

[R-6.7.4-012] The MCPTT Service shall require that the called MCPTT UE acknowledge receipt of an Automatic Commencement Private Call (without Floor control) setup request before the audio transmission proceeds.

[R-6.7.4-013] The MCPTT Service shall provide a first-to-answer commencement mode by allowing the originating user to indicate multiple potential target recipients for a Private Call (without Floor control) and shall ensure that the call is established only to the first answering user.

NOTE: Attention needs to be given to prevent undesired outcomes caused, for example, by automatic answer or divert to voicemail.

[R-6.7.4-014] When a receiving user answers a first-to-answer Private Call (without Floor control) the MCPTT Service shall remove all other receiving users from that call.

[R-6.7.4-015] The MCPTT Service shall provide a mechanism for an authorized MCPTT User to transfer an ongoing MCPTT Private Call (without Floor control) to another MCPTT user.

[R-6.7.4-016] The MCPTT Service shall provide a mechanism for an authorized MCPTT User to configure forwarding of incoming MCPTT Private Calls (without Floor control) to another MCPTT user in the following situations:

– Always

– If the MCPTT User is not reachable

– If the incoming private call is a call with manual commencement mode and the MCPTT User does not answer within a configured period

– Based on manual input of the MCPTT User

6.7.4a Private Call (with Floor control) commencement requirements

[R-6.7.4a-001] The MCPTT Service shall provide a first-to-answer commencement mode by allowing the originating user to indicate multiple potential target recipients for a Private Call (with Floor control) and shall ensure that the call is established only to the first answering user.

NOTE: Attention needs to be given to prevent undesired outcomes caused, for example, by automatic answer or divert to voicemail.

[R-6.7.4a-002] When a receiving user answers a first-to-answer Private Call (with Floor control) the MCPTT Service shall remove all other receiving users from that call.

6.7.5 Private Call (without Floor control) termination

[R-6.7.5-001] Void

[R-6.7.5-002] The MCPTT Service shall provide a means by which an authorized MCPTT User ignores a Manual Commencement Private Call (without Floor control) request from another MCPTT User.

NOTE: Ignoring a Manual Commencement Private Call (without Floor control) results in no indication of the reason for call failure being sent to the calling MCPTT User.

[R-6.7.5-003] Void

6.7.6 Call back request requirements

[R-6.7.6-001] The MCPTT Service shall provide a mechanism (i.e., MCPTT Private Call call back request) for the calling party of an MCPTT Private Call to request that the called party (at earliest convenience) place a call to the calling party.

[R-6.7.6-002] The MCPTT Service shall provide a mechanism for the calling party of an MCPTT Private Call to assign an urgency indication (i.e., low, normal, urgent) to any call back request.

[R-6.7.6-003] The MCPTT Service shall provide an MCPTT UE receiving an MCPTT Private Call call back request with an indication of the assigned call back urgency assigned by the calling party.

[R-6.7.6-004] The MCPTT Service shall provide a mechanism for an MCPTT User to cancel a call back request.

[R-6.7.6-005] The MCPTT Service shall provide an MCPTT UE receiving an MCPTT Private Call call back request with an indication of which MCPTT User called and when.

6.8 MCPTT priority requirements

6.8.1 General

[R-6.8.1-001] Void

[R-6.8.1-002] The MCPTT Service shall provide an access control mechanism to support multiple Access Priorities to prioritize MCPTT MO call initiation attempts, depending on their access priorities.

[R-6.8.1-003] Void

[R-6.8.1-004] Void

[R-6.8.1-005] Void

[R-6.8.1-006] Void

[R-6.8.1-007] Void

[R-6.8.1-008] Void

[R-6.8.1-009] Void

[R-6.8.1-010] Void

[R-6.8.1-011] Void

[R-6.8.1-012] Void

[R-6.8.1-013] Void

[R-6.8.1-014] Void

[R-6.8.1-015] Void

[R-6.8.1-016] Void

[R-6.8.1-017] Void

6.8.2 3GPP system access controls

[R-6.8.2-001] Void

6.8.3 3GPP system admission controls

[R-6.8.3-001] Void

6.8.4 3GPP system scheduling controls

[R-6.8.4-001] Void

6.8.5 UE access controls

[R-6.8.5-001] Void

6.8.6 Application layer priorities

6.8.6.1 Overview

Dispatchers from different critical communication organizations access the same networks and network resources. Depending on the event, the priority is given to an organization and/or a group rather than to another. For instance, in case of a fire priority is given to the fire brigades dealing with it, while in case of a criminal arrest priority is given to the police officers in charge of the arrest.

6.8.6.2 Requirements

[R-6.8.6.2-001] Void

[R-6.8.6.2-002] Void

[R-6.8.6.2-003] Void

[R-6.8.6.2-004] The MCPTT system may stop already established MCPTT calls with the capability to be pre-empted and a lower application layer priority to allow a new MCPTT call with pre-emption capability enabled for pre-emption to be established.

[R-6.8.6.2-005] Void

[R-6.8.6.2-006] Void

6.8.7 Call types based on priorities

6.8.7.1 MCPTT Emergency Group Call requirements

[R-6.8.7.1-001] Void

[R-6.8.7.1-002] Void

[R-6.8.7.1-003] Void

[R-6.8.7.1-004] Void

6.8.7.2 MCPTT Emergency Private Call (with Floor control) requirements

[R-6.8.7.2-001] The MCPTT Service shall ensure that MCPTT Emergency Private Calls (with Floor control) have the highest priority over all other MCPTT Private Calls.

[R-6.8.7.2-002] The MCPTT Service shall be capable of requesting increased priority for the Participants of an MCPTT Emergency Private Call.

[R-6.8.7.2-003] The MCPTT Service shall be capable of changing a Private Call (with Floor control) in progress to an MCPTT Emergency Private Call (with Floor control).

[R-6.8.7.2-004] MCPTT Emergency Private Calls (with Floor control), including their content and signalling, shall have pre-emptive priority over all other types of MCPTT calls, except System Calls, MCPTT Emergency Group Calls and other MCPTT Emergency Private Calls (with Floor control).

6.8.7.3 Imminent Peril group call requirements

[R-6.8.7.3-001] Void

[R-6.8.7.3-002] Void

[R-6.8.7.3-003] Void

6.8.7.4 MCPTT Emergency Alert

6.8.7.4.1 Requirements

[R-6.8.7.4.1-001] Void

[R-6.8.7.4.1-002] Void

[R-6.8.7.4.1-003] Void

[R-6.8.7.4.1-004] Void

[R-6.8.7.4.1-005] Void

[R-6.8.7.4.1-006] Void

6.8.7.4.2 MCPTT Emergency Alert cancellation requirements

[R-6.8.7.4.2-001] Void

[R-6.8.7.4.2-002] Void

6.9 IDs and aliases

[R-6.9-001] Void

[R-6.9-002] Void

[R-6.9-003] Void

[R-6.9-004] Void

6.10 User Profile management

[R-6.10-001] Void

[R-6.10-002] Void

[R-6.10-003] Void

[R-6.10-004] Void

6.11 Support for multiple devices

[R-6.11-001] Void

[R-6.11-002] Void

[R-6.11-003] Void

6.12 Location

[R-6.12-001] Void

[R-6.12-002] Void

[R-6.12-003] Void

[R-6.12-004] Void

[R-6.12-005] Void

[R-6.12-006] Void

[R-6.12-007] Void

6.13 Security

6.13.1 Overview

Security covers areas designed to protect the confidentiality, integrity, and availability of information that is processed, stored, and transmitted. The security requirements listed here cover the areas of cryptographic protocols, authentication, access control, and regulatory issues.

6.13.2 Cryptographic protocols

[R-6.13.2-001] Void

[R-6.13.2-002] Void

[R-6.13.2-003] Void

6.13.3 Authentication

[R-6.13.3-001] Void

6.13.4 Access control

[R-6.13.4-001] Void

[R-6.13.4-002] Void

[R-6.13.4-003] Void

[R-6.13.4-004] Void

[R-6.13.4-005] Void

[R-6.13.4-006] Void

[R-6.13.4-007] Void

[R-6.13.4-008] Void

[R-6.13.4-009] Void

[R-6.13.4-010] Void

6.13.5 Regulatory issues

[R-6.13.5-001] Void

6.14 Interactions for MCPTT Group Calls and MCPTT Private Calls

[R-6.14-001] Void

[R-6.14-002] Void

[R-6.14-003] The MCPTT Service shall only allow an MCPTT User to participate in one MCPTT Private Call (without Floor control) at a time.

6.15 Audio MCPTT call performance

6.15.1 General overview

Meeting the KPIs defined in the following subclauses is based on a number of factors, including the selection of appropriate protocols, minimizing messaging, the backhaul technology used, and appropriate configuration of the deployed network. The corresponding requirements are intended to convey the resulting KPIs when all of those factors are taken into account. For example, where there is significant backhaul delay, that delay is expected to be added to the KPIs.

6.15.2 General requirements

[R-6.15.2-001] The architecture and protocols providing the MCPTT Service shall be designed in a way to eventually allow a deployed network to meet the KPIs specified hereafter (subclause 6.15.3.2 and subclause 6.15.4.2).

6.15.3 MCPTT access time and mouth-to-ear latency

6.15.3.1 General overview

For MCPTT Users, one of the most important performance criteria is the MCPTT Access time (KPI 1). The MCPTT Access time is defined as the time between when an MCPTT User request to speak (normally by pressing the MCPTT control on the MCPTT UE) and when this user gets a signal to start speaking. This time does not include confirmations from receiving users.

The MCPTT Access time (KPI 1) does not include the time for an MCPTT User to affiliate to the group. This is a common scenario within public safety, meaning that affiliations to MCPTT Groups are long lived during several working hours. KPI 1 is applicable in both an MCPTT Group call setup request and subsequent MCPTT Requests that are part of the same call. KPI 1 for subsequent MCPTT Requests might take a slightly shorter time than the first MCPTT setup request of the same call due to its potential need of resource allocation in terms of bearer establishment. However from an end user perspective there is no need to differentiate required performance for an MCPPT Group call setup request and subsequent MCPTT Requests.

The End-to-end MCPTT Access time (KPI 2) is defined as the time between when an MCPTT User requests to speak (normally by pressing the MCPTT control on the MCPTT UE) and when this user gets a signal to start speaking, including MCPTT call establishment (if applicable) and possibly acknowledgement from first receiving user before voice can be transmitted. Group calls can be set up with or without acknowledgements from receiving users.

For MCPTT Private Calls (with Floor control), end-to-end MCPTT Access time (also KPI 2) is measured from the initiating client’s Private call request to reception of either a Private Call response for automatic commencement or the MCPTT ringing indication for manual commencement. End-to-end access time for both automatic and manual commencement private calls (KPI 2) is shown in Figure 6.15.3.1.1.

NOTE: The End-to-end MCPTT Access time (KPI 2) is not applicable for an MCPTT Group transmission call setup when no acknowledgement is requested from any Affiliated MCPTT Group Member.

The Mouth-to-ear latency (KPI 3) is the time between an utterance by the transmitting user, and the playback of the utterance at the receiving user’s speaker. Figure 6.15.3.1.1 illustrates the MCPTT Access time and Mouth-to-ear latency.

Figure 6.15.3.1.1: Illustration of MCPTT access time and mouth-to-ear latency

6.15.3.2 Requirements

[R-6.15.3.2-001] KPI 1, KPI 2, and KPI 3 should be measured where there is negligible backhaul delay.

[R-6.15.3.2-002] The MCPTT Service shall provide the MCPTT Access time and Mouth-to-ear latency specified in this subclause to all MCPTT Users related to an MCPTT call regardless of call type (e.g., group, Private Call), group size and/or user density.

NOTE: This ensures that all MCPTT Users experience the same performance regardless of whether the audio is transferred over unicast or multicast delivery.

[R-6.15.3.2-003] The MCPTT Service shall be capable of providing the performance specified herein for all Affiliated MCPTT Group Members in the Group Call when there is not a transcoder in the bearer path.

[R-6.15.3.2-004] The MCPTT Service shall be capable of providing the performance specified herein for all Participants in a Private Call when there is not a transcoder in the bearer path.

[R-6.15.3.2-005] The KPIs defined in this subclause shall apply in an 3GPP network under traffic load not exceeding 70% of each network nodes capacity.

[R-6.15.3.2-006] On networks with QOS services, the KPIs defined in this subclause shall apply when the total sector loading of the serving sector by MCPTT Users with equal or greater priority than the subject MCPTT User is less than 70%.

[R-6.15.3.2-007] The KPIs defined in this subclause shall apply to group calls when the transmitting MCPTT User is connected to the MCPTT Service and has selected an MCPTT Group.

[R-6.15.3.2-008] The KPIs defined in this subclause shall apply to group calls when the receiving MCPTT User is connected to the MCPTT Service and affiliated with the MCPTT Group.

[R-6.15.3.2-009] The KPIs defined in this subclause shall apply to Automatic Commencement Private Calls when both the transmitting and receiving MCPTT Users are connected to the MCPTT Service.

[R-6.15.3.2-010] Void

[R-6.15.3.2-011] When there are transcoding functions in the bearer path of the MCPTT Service, the performance provided by the MCPTT Service shall be no more than 40 ms greater than the performance specified herein when there are no transcoding functions in the bearer path.

[R-6.15.3.2-012] For group calls where no acknowledgement is requested from affiliated MCPTT group members, the MCPTT Service shall provide an MCPTT Access time (KPI 1) less than 300 ms for 95% of all MCPTT Request.

[R-6.15.3.2-012a] For group and private calls where the call is already established, the MCPTT Service shall provide an MCPTT Access time (KPI 1) less than 300 ms for 95% of all MCPTT PTT Requests.

[R-6.15.3.2-013] For MCPTT Emergency Group Calls and Imminent Peril Calls the MCPTT Service shall provide an MCPTT Access time (KPI 1) less than 300 ms for 99% of all MCPTT Requests.

[R-6.15.3.2-014] For group calls where automatic acknowledgement is requested from the UEs of the affiliated MCPTT group members, the MCPTT Service shall provide an End-to-end MCPTT Access time (KPI 2) less than 1000 ms for users under coverage of the same network.

[R-6.15.3.2-015] The MCPTT Service shall provide a Mouth-to-ear latency (KPI 3) that is less than 300 ms for 95% of all voice bursts.

[R-6.15.3.2-016] There shall be no (0 ms) initial lost audio at receiving user.

[R-6.15.3.2-017] There shall be no (0 ms) trailing lost audio at the end of the voice burst at receiving user. [R-6.15.3.2-018] The KPIs defined in this subclause shall apply to Manual Commencement Private Calls when both the transmitting and receiving MCPTT Users are connected to the MCPTT Service.

[R-6.15.3.2-019] The MCPTT Service shall provide private call End-to-end MCPTT Access time (KPI 2) equal to or less than 1000 ms for users under coverage of the same network when the MCPTT private call is setup in the Manual Commencement mode.

[R-6.15.3.2-020] The MCPTT Service shall provide private call End-to-end MCPTT Access time (KPI 2) equal to or less than 1000 ms for users under coverage of the same network when the MCPTT private call is setup in the Automatic Commencement mode.

6.15.4 Late call entry performance

6.15.4.1 General overview

An MCPTT User is able to join or leave already ongoing MCPTT Group calls. Late call entry is the activity when an Affiliated MCPTT Group Member joins an MCPTT Group call in which other Affiliated MCPTT Group Members are already active. The Late call entry time (KPI 4) is the time to enter an ongoing MCPTT Group call measured from the time that a user decides to monitor such an MCPTT Group Call, to the time when the MCPTT UE’s speaker starts to play the audio. The performance requirements for Late call entry time only applies to when there is ongoing voice transmitted at the time the MCPTT User joins the call.

In a Late call entry there might be an initial lost audio of the voice burst sent to the new Receiving MCPTT Group Member. Figure 6.15.4.1.1 illustrates the Late call entry time.

Figure 6.15.4.1.1: Illustration of Late call entry time

6.15.4.2 Requirements

[R-6.15.4.2-001] The KPIs in this subclause shall apply for terrestrial use only, and when users are under coverage of the same network.

NOTE: Terrestrial use refers to using terrestrial 3GPP access, e.g. not using satellite 3GPP access. It includes support of air-to-ground scenarios, such as communication with MCPTT users in helicopters, fixed wing aircraft or other crewed aerial vehicles.

[R-6.15.4.2-002] The KPIs defined in this subclause shall apply in an 3GPP network under traffic load not exceeding 70% of each network nodes capacity.

[R-6.15.4.2-002a] The KPIs defined in this subclause shall apply to MCPTT users who have affiliated or have been affiliated by the network and are now performing late call entry due to activity on the affiliated group.

NOTE: Cases of UE mobility, or loss of coverage and re-establishment, are not covered.

[R-6.15.4.2-003] The maximum Late call entry time (KPI 4^a) for calls without application layer encryption within one MCPTT system shall be less than 150 ms for 95% of all Late call entry requests.

[R-6.15.4.2-004] The maximum Late call entry time (KPI 4^b) for application layer encrypted calls within one MCPTT system should meet the requirements for KPI 4 for unencrypted calls.

[R-6.15.4.2-005] The maximum Late call entry time (KPI 4^b) for application layer encrypted calls within one MCPTT system shall be less than 350 ms for 95% of all Late Call Entries into encrypted calls.

[R-6.15.4.2-006] The Late call entry Time for encrypted calls interworking with other non-3GPP PTT systems should meet the requirements for KPI 4^b for application layer encrypted calls within one MCPTT system.

NOTE: Additional delay deriving from the non-3GPP PTT system is not included in this KPI.

[R-6.15.4.2-007] The additional Late call entry Time for an MCPTT UE late entering an application layer encrypted call interworking with other non-3GPP PTT systems shall not exceed the difference in the encrypted and unencrypted Late call entry Times for the interworking system.

6.15.5 Audio / voice quality

[R-6.15.5-001] The MCPTT UE shall support at least one mandatory 3GPP voice codec.

NOTE 1: The UE implementation could include other non-3GPP voice codecs, e.g., TETRA voice codecs, P25 voice codecs [4].

NOTE 2: Refer to [R-6.4.9-006], which enables an MCPTT Administrator to set the preferred voice codec for an MCPTT Group.

[R-6.15.5-002] When an MCPTT call is within one MCPTT system the average MOS-LQO shall be greater than or equal to 3.0 measured according to the ITU standard Perceptual Evaluation of Speech Quality (PESQ) as defined in P.862 [7] and P.862.1 [8].

[R-6.15.5-003] When an MCPTT call involves interworking with other non-3GPP PTT systems the average MOS-LQO shall be greater than or equal to 2.7 measured according to the ITU standard PESQ as defined in P.862 [7] and P.862.1 [8].

[R-6.15.5-004] When an MCPTT call is within one MCPTT system the average MOS-LQO shall be greater than or equal to 3.0 measured according to the ITU standard Perceptual Objective Listening Quality Assessment (POLQA) as defined in P.863 [9].

[R-6.15.5-005] When an MCPTT call involves interworking with other non-3GPP PTT systems the average MOS LQO shall be greater than or equal to 2.7 measured according to the ITU standard POLQA as defined in P.863 [9].

6.15.6 Radio Resource Efficiency Performance

[R-6.15.6-001] Void

[R-6.15.6-002] Void

6.16 Additional services for MCPTT calls

6.16.1 Discreet listening capabilities

[R-6.16.1-001] Void

6.16.2 Ambient listening

6.16.2.1 Overview of ambient listening

Ambient Listening is a feature that allows an authorized MCPTT User, typically a dispatcher, to cause an MCPTT UE to initiate a call which results in no indication on the MCPTT UE that it is transmitting. Ambient Listening can be initiated by an authorized MCPTT User who wants to be listened to by another remote authorized MCPTT User or can be initiated by a remote authorized MCPTT User who wants to listen to another MCPTT User. The purpose of this feature allows a dispatcher to listen to activities at the Location of the remote MCPTT UE to find out what is happening around that MCPTT UE without providing an indication to the MCPTT User or people around the user (whom the MCPTT User does not want to make aware of this action) that this is happening. This type of call is different from other types of call, as for Ambient Listening audio is only transmitted to one party in the call (i.e., a dispatcher or an authorized MCPTT User that is acting in a similar role to a dispatcher).

This is used for stolen MCPTT UEs, monitoring officers, officer safety and particular operations, where it is important that the MCPTT UE does not indicate what is happening.

6.16.2.2 Ambient listening requirements

6.16.2.2.1 General Ambient Listening requirements

[R-6.16.2.2.1-001] Void

[R-6.16.2.2.1-002] Void

[R-6.16.2.2.1-003] Void

[R-6.16.2.2.1-004] The MCPTT Service shall terminate Ambient Listening if the MCPTT User being listened to starts to transmit in an MCPTT Private Call or an MCPTT Group Call.

NOTE: An authorized MCPTT User could initiate Discreet Listening at this point if needed.

6.16.2.2.2 Remotely initiated Ambient Listening requirements

[R-6.16.2.2.2-001] Void

[R-6.16.2.2.2-002] Void

6.16.2.2.3 Locally initiated Ambient Listening requirements

[R-6.16.2.2.3-001] Void

[R-6.16.2.2.3-002] Void

6.16.3 Remotely initiated MCPTT call

6.16.3.1 Overview

A Remotely initiated MCPTT Call is a feature that allows an authorized user, typically a dispatcher, to cause a remote MCPTT UE to initiate a call by itself, without its user explicitly initiating the call by depressing the PTT switch. The purpose of this feature allows the dispatcher to listen to activities at the Location of the remote MCPTT UE to find out what is happening around that MCPTT UE. This feature is also known as "Remote Unit Monitoring" in P25 systems.

There are two typical use cases for this feature.

The first one is the case where a user could have been incapacitated. This could be both accidentally, say a traffic accident, or deliberately, for example a violent attack. In both cases it would be necessary to remotely open the microphone of the MCPTT UE in order to allow another user or a group of users to listen to what is happening to prepare assistance. The communication that is set up is either a Private Call or a Group Call, and the call could optionally be visible to the remote MCPTT UE’s user.

The second one is the case of a stolen MCPTT UE. Here it is just necessary to activate the radio so that a dispatcher can listen to any background noise or speech in order to make an analysis of the situation. In this situation, the initiation of the call from the remote MCPTT UE, typically a Private Call in that case, is not visible by that MCPTT UE’s user.

Other use cases, such as undercover operations, discreet surveillance of users or investigations, could exist depending on the missions of the critical communications users and on legislations.

The behaviour of the remotely initiated Call is not different from a normal call initiated by the local user. The same rules for resource allocation and interactions with other services apply, but the initiator of the feature can have the capability to request a pre-emptive or high priority for that Call to ensure it is set up even in case of resource congestion or to limit disturbance by other services.

6.16.3.2 Requirements

[R-6.16.3.2-001] Void

[R-6.16.3.2-002] Void

[R-6.16.3.2-003] Void

[R-6.16.3.2-004] Void

6.16.4 Recording and audit requirements

[R-6.16.4-001] Void

[R-6.16.4-002] Void

[R-6.16.4-003] Void

[R-6.16.4-004] Void

[R-6.16.4-005] Void

[R-6.16.4-006] Void

[R-6.16.4-007] Void

[R-6.16.4-008] Void

[R-6.16.4-009] Void

[R-6.16.4-010] Void

6.17 Interaction with telephony services

[R-6.17-001] Void

[R-6.17-002] The MCPTT Service shall provide a mechanism for an MCPTT Administrator to configure the interaction between telephony calls and MCPTT calls for an MCPTT User.

[R-6.17-003] Void

6.18 Interworking

6.18.1 Non-3GPP access

[R-6.18.1-001] Void

6.18.2 Interworking between MCPTT systems

[R-6.18.2-001] Void

[R-6.18.2-002] Void

[R-6.18.2-003] Void

[R-6.18.2-004] Void

[R-6.18.2-005] Void

[R-6.18.2-006] Void

[R-6.18.2-007] Void

6.18.3 Interworking with non-3GPP PTT systems

6.18.3.1 Overview

Mission critical users currently employ a wide range of narrowband mission critical Push To Talk services. Project 25 (governed by the TIA-102 standards) and TETRA (governed by ETSI standards) are digital public safety grade PTT systems. In addition, "legacy" or "conventional FM" systems are common throughout the world. These systems provide PTT and related services that are analogous to those provided by MCPTT, including group calls, Private Calls, broadcast calls, dynamic group management and other services.

The MCPTT Service is intended to interwork with these non-3GPP PTT systems.

6.18.3.2 Project 25

[R-6.18.3.2-001] The MCPTT Service shall enable interworking with non-3GPP PTT Systems that are compliant with the TIA-102 (P25) standards.

[R-6.18.3.2-002] Interworking between the MCPTT Service and P25 shall be capable of interworking with a multiplicity of independently administered Project 25 Radio Frequency Subsystems (RFSS).

[R-6.18.3.2-003] Interworking between the MCPTT Service and P25 shall support interoperable MCPTT Group Calls between MCPTT Users and P25 subscriber units and consoles.

[R-6.18.3.2-004] Interworking between the MCPTT Service and P25 shall support interoperable MCPTT Emergency Group Calls and P25 emergency calls.

[R-6.18.3.2-005] Interworking between the MCPTT Service and P25 shall support end-to-end encrypted MCPTT Group Calls between MCPTT Users and P25 subscriber units and consoles.

[R-6.18.3.2-006] Interworking between the MCPTT Service and P25 shall provide a means for an authorized user to initiate an override of a PTT Group call between MCPTT Users and P25 subscriber units and consoles.

[R-6.18.3.2-007] The MCPTT Service shall provide a mechanism for an MCPTT Administrator to authorize an MCPTT User to be able to initiate an override of a PTT Group call between MCPTT Users and P25 subscriber units and consoles.

[R-6.18.3.2-008] Interworking between the MCPTT Service and P25 shall provide a means for an authorized P25 subscriber units and consoles to initiate an override of a PTT Group call between MCPTT Users and P25 subscriber units and consoles.

[R-6.18.3.2-009] The MCPTT Service shall provide a mechanism for an MCPTT Administrator to authorize a P25 subscriber unit or P25 console to be able to initiate an override of a PTT Group call between MCPTT Users and P25 subscriber units and consoles.

[R-6.18.3.2-010] Interworking between the MCPTT Service and P25 shall support Group Regrouping that includes both MCPTT Groups and P25 groups.

[R-6.18.3.2-011] Interworking between the MCPTT Service and P25 shall support User Regrouping that includes both MCPTT Users and P25 subscriber units.

[R-6.18.3.2-012] Interworking between the MCPTT Service and P25 shall support interworking of Group-Broadcast Group Calls and P25 announcement group calls.

[R-6.18.3.2-013] Interworking between the MCPTT Service and P25 shall support interoperable User IDs and P25 subscriber IDs.

[R-6.18.3.2-014] Interworking between the MCPTT Service and P25 shall support interoperable PTT Private Calls (with Floor control) between an MCPTT User and a P25 subscriber unit or console.

[R-6.18.3.2-015] Interworking between the MCPTT Service and P25 shall provide a mechanism to reconcile the Private Call (with Floor control) commencement mode between an MCPTT User and a P25 subscriber unit or console.

[R-6.18.3.2-016] Interworking between the MCPTT Service and P25 shall support end-to-end encrypted PTT Private Calls (with Floor control) between an MCPTT User and a P25 subscriber unit or console.

[R-6.18.3.2-017] Interworking between the MCPTT Service and P25 shall support a means of reconciling codecs between interoperable calls.

[R-6.18.3.2-018] Interworking between the MCPTT Service and P25 shall support conveyance of Losing audio from P25 subscriber units and consoles to authorized MCPTT Users.

[R-6.18.3.2-019] The MCPTT Service shall provide a mechanism for an MCPTT Administrator to authorize MCPTT Users to be able to receive Losing audio from P25 subscribers units and consoles.

[R-6.18.3.2-020] For Private Calls (with Floor control) interworking between the MCPTT Service and non-3GPP PTT systems that do not support Private Call override (e.g., Project 25 Phase 1 systems), the Participant attempting to override shall be notified that the override can not be accomplished.

[R-6.18.3.2-021] For Private Call (with Floor control) interworking, between the MCPTT Service and non-3GPP PTT systems that do support Private Call override (e.g., Project 25 Phase 2 systems), the MCPTT Service shall provide a mechanism for Participants to override an active MCPTT transmission of a transmitting Participant when the priority level of the overriding Participant is ranked higher than the priority level of the transmitting Participant.

6.18.3.3 TETRA

[R-6.18.3.3-001] The MCPTT Service shall enable interworking with non-3GPP PTT Systems that are compliant with the ETSI TETRA standards.

[R-6.18.3.3-002] Interworking between the MCPTT Service and TETRA shall be capable of interworking with a multiplicity of independently administered TETRA systems (Switching and management Infrastructures).

[R-6.18.3.3-003] Interworking between the MCPTT Service and TETRA shall support interoperable MCPTT Group Calls between MCPTT Users and TETRA mobile stations and consoles.

[R-6.18.3.3-004] Interworking between the MCPTT Service and TETRA shall support interoperable MCPTT Emergency Group Calls and TETRA emergency calls.

[R-6.18.3.3-005] Interworking between the MCPTT Service and TETRA shall support end-to-end encrypted MCPTT Group Calls between MCPTT Users supporting the TETRA voice codec and end-to-end encryption and TETRA mobile stations and consoles.

[R-6.18.3.3-006] Interworking between the MCPTT Service and TETRA shall provide a means for an authorized user to initiate an override of a PTT Group call between MCPTT Users and TETRA mobile stations and consoles.

[R-6.18.3.3-007] Interworking between the MCPTT Service and TETRA shall provide a means for an authorized TETRA mobile station or console to initiate an override of a PTT Group call between MCPTT Users and TETRA mobile stations and consoles.

[R-6.18.3.3-008] Interworking between the MCPTT Service and TETRA shall support Group Regrouping that includes both MCPTT Groups and TETRA groups.

[R-6.18.3.3-009] Interworking between the MCPTT Service and TETRA shall support User Regrouping that includes both MCPTT Users and TETRA mobile stations.

[R-6.18.3.3-010] Interworking between the MCPTT Service and TETRA shall support interoperable User IDs and TETRA IDs.

[R-6.18.3.3-011] Interworking between the MCPTT Service and TETRA shall support interoperable PTT Private Calls between an MCPTT User and a TETRA mobile station or console.

[R-6.18.3.3-012] Interworking between the MCPTT Service and TETRA shall support end-to-end encrypted PTT Private Calls between an MCPTT User supporting TETRA codec and encryption and a TETRA mobile station or console.

[R-6.18.3.3-013] Interworking between the MCPTT Service and TETRA shall support a means of reconciling codecs between interoperable calls when not end-to-end encrypted.

[R-6.18.3.3-014] For Private Call (with Floor control) interworking, between the MCPTT Service and non-3GPP PTT systems that do support Private Call override, the MCPTT Service shall provide a mechanism for Participants to override an active MCPTT transmission of a transmitting Participant when the priority level of the overriding Participant is ranked higher than the priority level of the transmitting Participant.

6.18.3.4 Legacy land mobile radio

[R-6.18.3.4-001] The MCPTT Service shall enable interworking with legacy Land Mobile Radio systems that are compliant with the TIA-603-D [3] Standard.

[R-6.18.3.4-002] Interworking between the MCPTT Service and TIA-603 systems shall be capable of interworking with a multiplicity of independently administered systems based on the TIA-603-D [3] Standard.

[R-6.18.3.4-003] Interworking between the MCPTT Service and TIA-603 systems shall support interoperable PTT Group calls between MCPTT Users and TIA-603 subscriber units and consoles.

[R-6.18.3.4-004] Interworking between the MCPTT Service and TIA-603 systems shall provide a mechanism for an authorized MCPTT User to initiate an override within a PTT Group call that has both MCPTT Users and TIA 603 subscriber units and consoles.

[R-6.18.3.4-005] The MCPTT Service shall provide a mechanism for an MCPTT Administrator to authorize an MCPTT User to be able to initiate an override of a PTT Group call between MCPTT Users and TIA-603 subscriber units and consoles.

[R-6.18.3.4-006] Interworking between the MCPTT Service and TIA-603 systems shall provide a mechanism for an authorized TIA-603 subscriber unit or console to initiate an override within a PTT Group call that has both MCPTT Users and TIA 603 subscriber units and consoles.

[R-6.18.3.4-007] The MCPTT Service shall provide a mechanism for an MCPTT Administrator to authorize a TIA-603 subscriber unit or TIA-603 console to be able to initiate an override of a PTT Group call between MCPTT Users and TIA-603 subscriber units and consoles.

[R-6.18.3.4-008] Interworking between the MCPTT Service and TIA-603 systems shall support interoperable PTT Private Calls (with Floor control) between MCPTT Users and TIA-603 subscriber units or consoles.

[R-6.18.3.4-009] Interworking between the MCPTT Service and TIA-603 systems shall support a means of reconciling codecs between interoperable calls.

[R-6.18.3.4-010] Interworking between the MCPTT Service and TIA-603 systems shall support conveyance of Losing audio from TIA 603 subscribers units and consoles to suitably privileged MCPTT Users.

[R-6.18.3.4-011] The MCPTT Service shall provide a mechanism for an MCPTT Administrator to authorize MCPTT Users to be able to receive Losing audio from TIA-603 subscribers units and consoles.

6.18.3.5 Void

6.18.4 GSM-R

6.18.4.1 Overview

GSM-R, governed by 3GPP standards, is widely and globally used for rail communication. GSM-R offers capabilities analogous to those provided by MCPTT, including group calls, point-to point calls, broadcast calls, dynamic group management and the bearer service for train safety applications.

6.18.4.2 Requirements

[R-6.18.4.2-001] Void

[R-6.18.4.2-002] Void

[R-6.18.4.2-002a] Void

[R-6.18.4.2-002b] Void

[R-6.18.4.2-003] The MCPTT Service shall enable interworking between MCPTT Group Call and Advanced Speech Call Items used in GSM-R.

NOTE: The impact on GSM-R needs to be minimised.

[R-6.18.4.2-004] Interworking between the MCPTT Service and GSM-R shall support interoperable PTT Private Calls between an MCPTT User and a GSM-R mobile station or controller terminal.

[R-6.18.4.2-005] Interworking between the MCPTT Service and GSM-R voice services shall support a means of reconciling codecs.

6.19 MCPTT coverage extension using ProSe UE-to-Network Relays

[R-6.19-001] Void

[R-6.19-002] Void

[R-6.19-003] Void

[R-6.19-004] Void

[R-6.19-005] Void

[R-6.19-006] Void