ETSI TR 102 022-2 V1.2.1 (2018-01)

TECHNICAL REPORT
User Requirements Specification;
Mission Critical Broadband Communications;
Part 2: Critical Communications Application

2 ETSI TR 102 022-2 V1.2.1 (2018-01)

Reference
RTR/TCCE-01204
Keywords
evolution, requirements, TETRA
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: +33 4 92 94 42 00  Fax: +33 4 93 65 47 16

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
The present document can be downloaded from:
http://www.etsi.org/standards-search
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the only prevailing document is the
print of the Portable Document Format (PDF) version kept on a specific network drive within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying
and microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.

© ETSI 2018.
All rights reserved.
TM TM TM
DECT , PLUGTESTS , UMTS and the ETSI logo are trademarks of ETSI registered for the benefit of its Members.
TM
3GPP and LTE™ are trademarks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
oneM2M logo is protected for the benefit of its Members.
GSM® and the GSM logo are trademarks registered and owned by the GSM Association.
ETSI
3 ETSI TR 102 022-2 V1.2.1 (2018-01)
Contents
Intellectual Property Rights . 5
Foreword . 5
Modal verbs terminology . 5
Introduction . 5
1 Scope . 7
2 References . 7
2.1 Normative references . 7
2.2 Informative references . 7
3 Definitions and abbreviations . 8
3.1 Definitions . 8
3.2 Abbreviations . 8
4 Critical Communications Application Requirements . 10
4.1 General . 10
4.1.0 Introduction. 10
4.1.1 Description of Interfaces in Figures 1 to 3 . 12
4.2 Group Addressed Services . 16
4.2.0 General . 16
4.2.1 Emergency communication . 18
4.2.2 Dispatcher Override . 19
4.2.3 Local Fall Back . 19
4.3 Priority and Pre-Emption Services . 20
4.4 Off Network Services . 21
4.4.0 General . 21
4.4.1 Public Safety Specific Requirements for Off Network Services . 21
4.4.2 Local network Extension . 22
4.5 Calling/Talking Party Identity Restriction . 23
4.6 Interoperability with Legacy Systems . 23
4.7 Support for White Boarding and other Multi-Media Operations. 24
4.8 Dispatching - a Video Case . 24
4.9 Video Briefing . 24
4.10 Net Preference . 24
4.11 Dual Watch . 24
5 Voice Requirements . 24
5.0 General . 24
5.1 Intelligibility in Noisy Environments . 25
5.2 Call Set up Time . 25
6 Security. 25
7 Priorities for Functionality . 25
8 Summary of Baseline TETRA and Tetrapol Services and Exceptions to their Transfer to
Broadband Requirements (adopted from TETRA04(13)000074r2-Use-of-TETRA-services) . 29
Annex A: Functionality Split Proposal for Group Addressed Calls from 3GPP (Preliminary
view) . 34
Annex B: Visualization of Relay Node Use . 36
Annex C: Possible Progression of Interoperability Requirement . 38
Annex D: Extract from 3GPP TS 22.278 V12.4.0 (2013-09) . 41
Annex E: Requirements from Project Broadmap. 44
ETSI
4 ETSI TR 102 022-2 V1.2.1 (2018-01)
History . 45

ETSI
5 ETSI TR 102 022-2 V1.2.1 (2018-01)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (https://ipr.etsi.org/).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
Foreword
This Technical Report (TR) has been produced by ETSI Technical Committee TETRA and Critical Communications
Evolution (TCCE).
The present document is part 2 of a multi-part deliverable covering the User Requirement Specification (URSs) Mission
Critical Broadband Communications, as identified below:
Part 1: "Mission Critical Broadband Communication Requirements";
Part 2: "Critical Communications Application".
Modal verbs terminology
In the present document "should", "should not", "may", "need not", "will", "will not", "can" and "cannot" are to be
interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.
Introduction
The Terms of Reference for TC TCCE approved at ETSI Board meeting #42, 2013 is to produce ETSI deliverables (and
maintenance thereafter) in accordance with the following requirements:
a) To identify requirements for mission and business critical broadband services that will enable an evolution of
digital narrowband PMR services to mobile broadband.
b) To identify and fill standardization gaps such as:
1) Architectural design of critical communications services to be delivered over mobile broadband systems.
2) The development of standards for secure services and interfaces into private and commercial broadband
systems.
3) Interconnection of external PMR interfaces to critical communications systems.
ETSI
6 ETSI TR 102 022-2 V1.2.1 (2018-01)
c) The provision and development of proportionate security measures for TETRA and mission critical
communications services.
d) The selection and development of suitable CODECs for audio and video services.
e) The evolution and enhancement of TETRA and critical communications services as required by the market
with the provision of new services, facilities and functionality made possible by new technology innovations
and standards.
f) To identify requirements for the further development of the TETRA standard.
g) The maintenance of the TETRA standard.
Technical Objective:
• The present document provides the User Requirement Specifications for the Critical Communications
Application that facilitates digital PMR services over LTE™.
• The URS is required by TC TCCE to guide the design of the critical communications application to facilitate
broadband voice and data communications for critical communications users.
ETSI
7 ETSI TR 102 022-2 V1.2.1 (2018-01)
1 Scope
The present document provides the User Requirement Specifications for the Critical Communications Application
needed to support Broadband Mission Critical Communications over IP communications networks such as LTE.
The present document describes the functionalities which are most needed by users and the requirements they make on
the technology. The present document is applicable to the specification of broadband mission critical communications
equipment.
The user requirements contained in the present document are described in non-technical terms and are based on
discussions in TC TCCE WG1, TC TCCE WG4, LEWP RCEG and TCCA's CCBG SA and UR Groups.
2 References
2.1 Normative references
Normative references are not applicable in the present document.
2.2 Informative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
[i.1] ETSI TS 122 468 (V12.1.0): "LTE; Group Communication System Enablers for LTE (GCSE-
LTE) (3GPP TS 22.468 version 12.1.0 Release 12)".
[i.2] ETSI TS 122 278 (V12.5.0): "Universal Mobile Telecommunications System (UMTS); LTE;
Service requirements for the Evolved Packet System (EPS) (3GPP TS 22.278 version 12.5.0
Release 12)".
[i.3] ETSI TR 102 022-1: "User Requirement Specification; Mission Critical Broadband
Communication Requirements".
[i.4] NPSTC Recommendations for Push To Talk over Long Term Evolution Requirements, Public
Safety Broadband. A NPSTC Public Safety Communications Report.
[i.5] ETSI EN 300 392-9: "Terrestrial Trunked Radio (TETRA); Voice plus Data (V+D); Part 9:
General requirements for supplementary services".
[i.6] ETSI EN 300 392-12 (sub-parts 1, 3, 7, 8, 10, 16 and 22) : "Terrestrial Trunked Radio (TETRA);
Voice plus Data (V+D); Part 12: Supplementary services stage 3".
[i.7] 3GPP TS 22.278 (V12.4.0): "Service requirements for the Evolved Packet System (EPS)".
[i.8] Proximity-based Off Network Public Safety Use Case S1-113165 to 3GPP TSG-SA WG1 from
NIST et al.
[i.9] Requirements associated with Public Safety Off Network Use Case S1-113165 to 3GPP TSG-SA
WG1 from NIST.
[i.10] Tetrapol Specifications PAS 0001-1-2 (V3.0.1): "Part 1: "General Network Design: Part 2: Voice
and Data Services in Network and Direct Mode".
ETSI
8 ETSI TR 102 022-2 V1.2.1 (2018-01)
[i.11] WG4 WI DTR/TCCE-04186: "TCCE Critical Communications Architecture Reference Model".
[i.12] ETSI EN 300 392-1 (V1.4.1): "Terrestrial Trunked Radio (TETRA); Voice plus Data (V+D);
Part 1: General network design".
[i.13] TETRA04(13)000074r2-Use-of-TETRA-services (Work in progress for ETSI TCCE04).
[i.14] "Finlands 5 Steps to Critical Broadband", Vinkvist, Pesonen and Peltola, Radio nResource
International Q4 2014.
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the following terms and definitions apply:
Base Station (BS): set of equipment on a single site (which may be more than just a radio function)
mission critical broadband communications: work programme within ETSI Technical Committee TETRA and
Critical Communications Evolution to facilitate and enhance the services and facilities of digital PMR such as TETRA
operating over LTE in order to meet new user requirements for data and voice
3.2 Abbreviations
For the purposes of the present document, the following abbreviations apply:
AL Ambience Listening
ASSI Alias Short Subscriber Identity
AVL Automatic Vehicle Location
BS Base Station
CA Conventional Access
CCA Critical Communications Application
CCBG Critical Communications Broadband Group
CCS Critical Communication System
CLIR Calling Line Identification Restriction
COMM Common
DA Direct Access
DGNA Dynamic Group Number Assignment
DISC DISCovery
NOTE: Not in the ETSI list.
DMO Direct Mode of Operation
DTMF Dual Tone Multi Frequency
EPC Evolved Packet Core
ETSI European Telecommunications Standards Institute
E-UTRAN Evolved Universal Terrestrial Radio Access Network
FFS For Further Study
GCSE Group Call Service Enablers
GPS Global Positioning System
GSCE Group Communication System Enablers
IP Internet Protocol
ISI Inter System Interface
KPI Key Performance Indicator
LEWP Law Enforcement Working Party
LMR Land Mobile Radio
LTE 3GPP Long Term Evolution (4G)
MC Mission Critical
MCPTT Mission Critical Press to Talk
ETSI
9 ETSI TR 102 022-2 V1.2.1 (2018-01)
ME Mobile Equipment
MM Mobility Management
MS Mobile Station
MU Mobile Unit comprising UE plus CCA
MVNO Mobile Virtual Network Operator
NIST National Institute of Standards and Technology (USA)
NPSTC National Public Safety Telecommunications Council (not in the ETSI list)
OPS Operations
PABX Private Automatic Branch eXchange
PMR Private Mobile Radio
PPDR Public Protection and Disaster Recovery
ProSe Proximity Services
PSTN Public Services Telephone Network
PTT Press to Talk
QoS Quality of Service
RCEG Radio Communications Experts Group, a working group of LEWP
RF Radio Frequency
SA System Architecture
NOTE: Technical Specification Group of 3GPP.
SDS Short Data Service
SDS-TL SDS-Transport Layer
SIM Subscriber Identity Module
SLA Service Level Agreement
TA Tracking Area
TCCA TETRA + Critical Communications Association
TCCE TETRA and Critical Communications Evolution
TL Transport Layer
TPI Talking Party Identity
TR Technical Report
UE User Equipment
UR User Requirements
URS User Requirement Specification
USIM Universal Subscriber Identity Module
UTRA Universal Terrestrial Radio Access
UTRAN Universal Terrestrial Radio Access Network
ETSI
10 ETSI TR 102 022-2 V1.2.1 (2018-01)
4 Critical Communications Application Requirements
4.1 General
4.1.0 Introduction
In order to ensure that IP communications networks such as LTE are able to meet the requirements of critical
communications some changes to the 3GPP™ standards are needed. The most critical have been proposed first and are
called Group Communication System Enablers (GCSE) [i.1] and Proximity Based Services (ProSE) [i.2]. These have
resulted in 3GPP Work Items for Release 12. There are likely to be further requirements. In order to benefit from the
market scale available for public LTE and the attendant benefits such as lower cost, open standards, supplier choice, fast
development of features and long term evolution of capability the changes proposed to date have been kept to a
minimum to improve the chances of them being implemented by manufacturers. This means that to deliver the full
mission critical/critical communications functionality there has to be a Critical Communications Application (CCA) that
sits above the LTE protocol. This application will need to provide the services required for critical communications
[i.3]. (One of these services is push or press to talk, and NPSTC have recommended requirements for Public Safety in
the US [i.4]. Outside of North America the PTT voice functionality of TETRA [i.5], [i.6], [i.12] and Tetrapol [i.10] is
taken as an assumed baseline on top of which further functionality appropriate to broadband is added. To avoid
describing all the many standards a summary of this functionality and the exceptions, that is baseline functionality not
needed in broadband are listed in clause 8). The application will need to have implementations in the infrastructure and
in terminals with a standardized interface between them so that different vendors can be used.
It is important that the standardization of the CCA should be rapid and co-ordinated to match planned releases of the
3GPP standard containing the appropriate enablers. A phased approach is considered but whilst most user groups want
to focus on data services there are some groups, for example in the UK working on their future mission critical
communications, who want to rapidly transition to voice services as well. This means that the first release of the CCA
has to support core voice and data requirements with extensions in functionality coming in later releases.
There are different needs for supporting migration away from legacy systems depending on the plans in the various user
groups for the rate of migration. Some users groups see little need to operate with legacy systems and others see a
sustained period of inter-working. The level of interoperability required also varies but there is clearly a need for the
first release of the CCA to support some interaction with legacy systems with fuller integration coming later for those
who wish to operate their legacy systems for voice and narrowband data for a longer period alongside broadband data or
voice and data systems. This is dealt with in more detail in clause 7.
Some thoughts have been given to the partition between functionality to be supported in 3GPP and that by the CCA
(annex A). This led to a model of the architecture for Mission Critical Broadband Communications from TCCA CCBG
WG SA that defined the requirements of the CCA. This model is being developed in TCCE WG4 [i.11] and a version of
this is shown below purely to illustrate the scope of the requirements to be addressed. This diagram will not be updated
in this URS.
ETSI
11 ETSI TR 102 022-2 V1.2.1 (2018-01)

Figure 1: CCS Reference Model
ETSI
12 ETSI TR 102 022-2 V1.2.1 (2018-01)

Figure 2: Proximity Services Reference Model

Figure 3:Terminal to Network Relay Reference Model
4.1.1 Description of Interfaces in Figures 1 to 3
Interface 1 LTE Core Network - UE
This interface is specified according to the network protocols of the underlying IP network. Where the underlying
network is LTE, it consists of the 3GPP specified standardized LTE UE to EPC interfaces.
ETSI
13 ETSI TR 102 022-2 V1.2.1 (2018-01)
Interface 2 Infra CCA - LTE Core Network
This interface is specified according to the network protocols of the underlying IP network.
Where that underlying network is an LTE EPC, it consists of existing Rx and SGi interfaces, plus the GC2 interface
developed in the GCSE-LTE work item from 3GPP Release 12, to allow use and control of LTE broadcast bearers.
Interface 3 LTE UE to Mobile CCA
This interface relies on the services available from the IP network terminal.
In an LTE environment, it utilizes the interfaces provided by the UE to any application and may evolve to include
developments related to GCSE-LTE work item from 3GPP Release 12.
This interface itself is not fully standardized since it is dependent on the terminal implementation and operating system.
Interface 4 Infra CCA to Mobile CCA
The objective of this interface is to allow interoperability between a CCA infrastructure and terminals from different
manufacturers.
This interface provides similar functionality to existing digital PMR Layer 3 Air Interface messages, supporting, but not
limited to, user registration, setup and control of individual and group communications, media transfer and management
and short data transport.
Interface 5 Infra CCA to Application
The objective of this interface is to allow easy integration of Applications in a CCA environment, and portability of
those applications to CCAs from different manufacturers.
This interface is made of two main components:
• A Call interface, to provide control of sessions (C-Plane) and of media transport (U-Plane) within a
communication. This interface may be similar to a Dispatch interface in existing PMR systems, extended to
Multimedia.
NOTE 1: A single communication session can be an organized set of one or more communications used to transport
the same information to or from one or several mobiles. Independent sessions implies that there can be
several separate communications taking place between different sets of parties which can be accessed
through this interface.
• A Routed Transport interface to transport and route data messages (e.g. signalling, geo-location information,
text messages) and data files (e.g. picture, map) between mobiles and applications.
Interface 6 Mobile CCA to Mobile Application
The objective of this interface is to allow easy integration of Mobile Applications in a CCA environment, and
portability of those applications between terminals from different manufacturers.
Interface 7 Application to Mobile Application
Some components of this interface may be defined by standards, for specific applications that require generic formats to
ensure interoperability between mobile applications and control room application for instance: geo-location, video
format, vocoder, etc.
Interface 8 Inter CCA
The objective of this interface is to allow interoperability and interworking between CCS.
This interface supports interconnection of communications between users operating on different CCS.
This interface should support mobility of users between different CCS.
ETSI
14 ETSI TR 102 022-2 V1.2.1 (2018-01)
Interface 8b CCA to Legacy PMR
The objective of this interface is to allow interworking between a CCS and existing legacy PMR systems such as
TETRA, TETRAPOL and P25.
This interface is intended to support interconnection of communications between users operating on a CCS and on a
legacy PMR system.
Interface 9 Core Network to Core Network
This interface is determined by the underlying core IP network. Where the underlying network is an LTE EPC, it makes
use of 3GPP standard interfaces.
This interface provides support and control of mobility and roaming of terminals between different core networks.
NOTE 2: Where the underlying core networks use different technologies, a standardized interface may not be
available.
Interface 10 Terminal to Terminal
This interface is determined by the terminal technology.
Where the terminals are LTE Ues, this interface will be a standard 3GPP interface, defined under the Proximity
Services (ProSe) work item in 3GPP Release 12.
This interface supports direct communications between terminals and also the terminal to Network Relay configuration.
Interface 11 Mobile CCA to Mobile CCA
The objective of this interface is to provide control of direct CCA Services between two or more terminals without any
infrastructure path. Where the terminals are LTE Ues, it relies on underlying services defined by 3GPP ProSe.
Interface 12 Infra CCA to Relay CCA
The objective of this interface is to support the specific configuration of a Terminal to Network Relay. This interface
can be considered to be a subset of the interface 4 Infra CCA to Mobile CCA.
Interface 13 Mobile CCA to Relay CCA
The objective of this interface is to support the specific configuration of a Terminal to Network Relay. This interface
can be considered to be a subset of the interface 11 Mobile CCA to Mobile CCA.
CCA Features
User Management
– on top of device mobility
–Single Sign On
Group Management
Communication Control
– Handling the communication tree (connecting different transport sessions if needed)
– Individual and Group
– Floor Control (or exclusive transmitter within one session)
– Supplementary services
Session Control
– Set up, Release, priorities,… (C-Plane) of transport sessions
– Individual, Group (U-Plane)
Signaling Transport
– to transport and route signaling messages between mobile and applications
– similar to Short Data or to Control Channel messages
– e.g. geo-location information, Status,…

Figure 4: Critical Communications Application Features
ETSI
15 ETSI TR 102 022-2 V1.2.1 (2018-01)
The CCA then is broadly being asked to:
For Systems:
• Interface to legacy systems (TETRA, P25, Tetrapol) to allow a degree of interoperability. Is it assumed 3GPP
will manage the fallback from 4G to allow interoperability on a best efforts basis with 3G.
• Interface to other CCAs in the same or other networks. The intent is that initial CCA core functionality will be
standardized and that further functionality will be defined for subsequent releases that will in part depend and
be aligned with supporting feature releases from 3GPP.
• Interface to other LTE systems to allow roaming. There are two types of roaming to be supported; where 'LTE
roaming' is utilized (i.e. the user device is provided with an IP link back to their serving CCA via the roaming
networks), and application level roaming where the MU registers onto a visited CCA and communicates with
users there (interface 8 on the architecture reference model).
• The system (including the CCA) should support an Inter System Interface (ISI) for roaming of home
subscribers to other neighbour networks. It supports full dynamic subscriber migration.
• Group handling.
• Call control.
• Manage Priorities.
• Interaction with other 3GPP services.
• Performance management.
For LTE:
• Interface to EPC to allow GCSE and other services to be managed.
For Applications:
• Allow portability of different suppliers applications on the CCA.
For Mobiles:
• Interface to mobile CCA to allow
• Control access
• Manage groups
• Establish sessions for group communication between mobiles
• Manage priorities
• Transport and route signalling messages between mobiles and applications
In order to detail these requirements of the CCA the features that it needs to support today or for the future are
described below.
ETSI
16 ETSI TR 102 022-2 V1.2.1 (2018-01)
4.2 Group Addressed Services
4.2.0 General
This is the classic public safety and PMR situation whereby one addresses many in a voice or data call and it has the
following detailed requirements:
• The group call application should be able to allow or bar MU access to each group.
• When the user selects a group, the MU should request access to the group and the MU should inform the user
whether access is granted or not. There is also a need for infrastructure directed attachment.
• There should be an indication to the user if they are the only one on the group [i.4]. This indication to be given
at call time rather than attachment time. If a dispatcher is a member of the group and on the call then the
indication does not need to be made.
• Recipients of the call should receive an indication of the identity of the talking party.
• Subject to configuration and PTT priorities of the Group members, the system should be able to permit or deny
a second party to interrupt the talking party. If interruption is successful, both original and new talking parties
should receive an indication of their new state.
• For North America there has to be the ability to listen to both overriding and overridden calls [i.4].
• Once the current talking party has ended the transmission, another member of the group may request to
transmit to the group. The delays associated with the changeover should be no greater than the delays
associated with the original call setup.
• An MU should be able to join a group whilst a call is ongoing.
• Depending on the system configuration, if resources are not enough for all group members to receive the call,
calls can either be:
- queued, and the call should be set up once resources are available; the requesting party should receive an
indication of both the initial queued condition, and the granting of transmit permission once resources are
available; or
- continued with parties whose serving cells have enough resources to support the call.
These are sometimes known as "all start" and "fast start" respectively. For fast start it should be clear to the
talking party that some group members will not hear.
• If a call can start without all available parties, then those parties should be added to the call as soon as
sufficient resources become available.
• An MU should support access to in excess of 5 000 groups. This can include groups that have been
dynamically downloaded over the air to reduce the number that have to be continually available on the
terminal. The system should be able to handle in excess of 500 000 groups.
• The system should be capable of managing different types of media for the same group with the same priority
level and same coverage (where coverage is all used cells with RF range).
• The system should be capable of managing independent floor controls for concurrent communications within a
given group for different types of media.
• For all calls including video briefing (one to a large group) the system should be capable of providing
information to a dispatcher on the participants of a group call.
• It should be possible to share video without forcing it to be taken by sending a message that video is available
and the user pulling it when they are ready. The intent of this is a "notify and pull" approach probably with a
time validity given with the message such as "take by(next hour) with today's date" or "(specified hour) next
day" etc. There is a possibility that an acknowledgement to the notification may be needed with a time to co-
ordinate a later group push to avoid lots of individual calls.
ETSI
17 ETSI TR 102 022-2 V1.2.1 (2018-01)
• A "push" service where the user elects to accept the video or not is also considered a (lower priority)
requirement. A group "push" service in general with no option to decline is a requirement.
• Two further elements are functional addressing, which is addressing roles rather than radios or aliases, and
location dependant addressing, where the address of the controller (dispatcher) changes as an MU moves
through the network.
The following requirements have implications for the 3GPP domain as well as the application domain:
• When an authorized user sets up a call to the group, he should receive an indication of success (or failure)
within 300 ms of the call setup, and recipients of the call should receive an indication of the start of the call
within 300 ms of the originator's call setup. For clarity the start of the call is measured from PTT press.
• Audio should be conveyed from the transmitting party to all recipients with minimal delay. There should be no
noticeable difference in audio delay experienced by recipients on the same cell.
• Resources should be allocated efficiently, such that many recipients may share the same resources for the call.
• A group can have any number of members from 2 up to the total number of users on a system. Within a cell
where there is a user who can use that group, the number of users can range from 1 up to the total number of
users on that cell.
• Groups can be carried on any number of cells from 1 up to the total number of cells on the system. The system
decides how many cells are needed based on the presence of users.
• There is a special requirement known as a "ringing group call" that is initiated in the field or by a dispatcher
where there is a need for the recipients to act in concert in an operation and so it is important to know who has
acknowledged the call and is going to participate. For this to work there has to be a fast acknowledgement
process and a listing displayed of all those who will participate. This need is further detailed in clause 4.2.1.
• The system should support mobility for MUs transmitting and receiving a group call. Transmitting Mus should
retain transmit permission after a mobility event. There should be minimal loss of audio, video or other data
due to the mobility event.
• Mobility events such as handovers between cells should meet the requirements above for MUs moving at
speeds between 0 - 300 km/hr, ideally 500 km/h.
• A cell or sector should be able to support a number of simultaneous group calls. By way of guidance most
needs could be met if this number was at least 36.
• Similarly a cell or sector should be able to support a large number of users participating in different group
calls. If at least 2 000 users could be supported it would meet anticipated requirements.
• The system needs to support the dynamic addition of groups to MUs over the air to allow groups to be
configured with appropriate talkgroups as they move location and/or attend incidents.
• It may occasionally happen during events or incidents that 500 users or more within a cell or sector may be
participating in the same group. When whatever the upper limit of the system is reached it is permissible to
reject the next user beyond the stated capacity. The user who has been rejected due to this should receive a
message stating "overload" or "congestion" as the reason for rejection. No ongoing call should be interrupted
due to the stated capacity being exceeded.
• The system should be capable of setting up several communication paths concurrently and independently for
the same set of devices. In general this will apply to different services but for the override situation where the
overridden voice call still needs to be heard as well this will apply to speech. There are other use cases such as
communications up and down organizations where concurrent speech calls are required.
• There is a need for groups to be managed dynamically over the air.
• The system should support patching to allow a call to be sent to more than one group.
ETSI
18 ETSI TR 102 022-2 V1.2.1 (2018-01)
4.2.1 Emergency communication
This is where in an emergency situation a user needs to send an emergency message for assistance. This is normally an
alarm which is a predefined change of status tagged with location but conceivably can be voice text or video. The
derived requirements are:
• The MU should send an Emergency Alarm with pre-emption when the Emergency Button (or similar feature
that is easy to locate even in the dark, single functioned and with positive tactile feedback) is pushed on an
MU. This emergency alarm should include user id and location.
• The System should route the Emergency Alarm to the Dispatchers associated with the Group of the MU in
Emergency and to the Dispatcher associated with the agency of the Unit in Emergency. This information is
part of the agency and group provisioning of the System.
• There are situations such as when emergency gateways or dispatchers who are connected via an MU are used
that individual rather that group calls are required.
• For rail use the system supports the Railway Emergency Call. This is a pre-emptive group call which is
initiated from a mobile and involves both the controller (dispatcher) and all relevant users in the local area of
the call originator.
• The Emergency alarm is normally followed by a Emergency call from the Unit in Emergency, giving details
about the actual emergency. For this call the System should apply an Emergency Priority which is the highest
priority for resource allocation and retention. Any communication with an Emergency Priority should pre-
empt resources from existing non-emergency communications if needed.
• There are various requirements regarding the termination of emergency calls. They include termination by the
dispatcher, termination by the end user or a pre-programmed time out. All of these should be supported
individually or in combination.
• The MU should support the Ambience Listening feature.
• There should be the facility to allow a professional user to create or share any type of emergency call with the
members of a Group including the dispatcher. The situation where the create capability might be needed is if
the user in an emergency cannot push the emergency button and another user initiates the call on that user's
behalf. The sharing could arise when another group or individual who could help need to be patched into the
call.
• Some group communications should be able, as they are established, to ring all their authorized MUs, even if
those MUs are already participating in another communication. Those MUs are so alerted that an emergency
communication is ongoing and that they are invited to participate.
Such "ringing group" communications:
- should have the same characteristics as any normal group communication (number of MUs or group of
Mus, number of supported eNodeB, etc.);
- should have a particular ringing tone (may be defined as a parameter);
- only ring at the establishment.
In case an MU is switched on after the ringing group call establishment, and if this ringing group
communication is always opened, the MU should be notified of the ringing group communication without
being ringed.
An MU should be able to accept or refuse to enter a ringing group call.
• For North America there is a need to recognize a second level of priority for Imminent Peril calls. (Situations
which are not yet an emergency but are at high risk of becoming so). Such calls can be pre-empted by an
emergency call. Specifically [i.4]:
- The PTT Service SHOULD support imminent peril calls.
- The PTT Service SHOULD ensure that emergency and imminent peril calls have the highest priority
over all other PTT Group transmissions.
ETSI
19 ETSI TR 102 022-2 V1.2.1 (2018-01)
- The PTT Service SHOULD provide a mechanism to ensure that emergency and imminent peril calls,
including their content and signalling, have pre-emptive priority over all other types of PTT Group
transmissions.
- The PTT Service SHOULD support emergency calls that persist until being acknowledged and
terminated based on criteria created by a Public Safety Entity Administrator.
4.2.2 Dispatcher Override
This is where a dispatcher decides to override communications to a group to share information. The derived
requirements are:
• The system should manage a priority level within a group associated with each member of the group for floor
control in an active communication.
• There should be four (4) different priority levels for floor control.
• The system should support a pre-emptive priority level within a group for floor control in an active
communication.
NOTE: Those priorities are only intended for floor control within a communication and are
...