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.
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.
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).
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.
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.
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.
[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.
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.
The KPIs in this subclause shall apply for terrestrial use only, and when users are under coverage of the same network.
[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.
[R-6.15.4.2-003]
The maximum Late call entry time (KPI 4a) 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 4b) 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 4b) 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 4b for application layer encrypted calls within one MCPTT system.
[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.
The MCPTT UE shall support at least one mandatory 3GPP voice codec.
[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].
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.
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.
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.
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.
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.
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.
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.
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.
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.
The MCPTT Service shall enable interworking between MCPTT Group Call and Advanced Speech Call Items used in GSM-R.
[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.