ETSI TR 103 565-1 V1.2.1 (2018-12)

TECHNICAL REPORT
TETRA and Critical Communications Evolution (TCCE);
Interworking between TETRA and 3GPP
mission critical services
Part 1: General considerations for interworking

2 ETSI TR 103 565-1 V1.2.1 (2018-12)

Reference
RTR/TCCE-04196
Keywords
mission critical communication, radio, TETRA,
V+D
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 TM
3GPP and LTE are trademarks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
oneM2M™ logo is a trademark of ETSI registered for the benefit of its Members and
of the oneM2M Partners. ®
GSM and the GSM logo are trademarks registered and owned by the GSM Association.
ETSI
3 ETSI TR 103 565-1 V1.2.1 (2018-12)
Contents
Intellectual Property Rights . 5
Foreword . 5
Modal verbs terminology . 5
Introduction . 5
1 Scope . 6
2 References . 6
2.1 Normative references . 6
2.2 Informative references . 6
3 Definition of terms and abbreviations . 7
3.1 Terms . 7
3.2 Abbreviations . 8
4 Service overview . 8
4.1 Services . 8
4.2 Interworking realization . 9
5 Considerations . 10
5.1 General . 10
5.2 Addressing . 10
5.2.1 TETRA and MCPTT addressing . 10
5.2.2 Interconnection and migration . 11
5.2.3 Identification of calling or talking party . 11
5.3 Speech group calls . 12
5.3.1 Group affiliation (group attachment) . 12
5.3.2 Controlling systems . 12
5.3.3 Group linking . 12
5.3.3.1 Overview . 12
5.3.3.2 Interworking function as proxy group member . 13
5.3.3.3 Interworking function as proxy TETRA SwMI/MCPTT server . 13
5.3.4 Single group across both systems . 14
5.3.5 Group patching . 15
5.3.6 Group regrouping . 15
5.3.7 Group call types . 16
5.3.8 Call queuing . 16
5.4 Individual calls . 17
5.5 Floor control . 17
5.6 Emergency calls and alerts . 17
5.7 Priorities . 17
5.8 Supplementary services . 18
5.8.1 General . 18
5.8.2 Call forwarding . 18
5.8.3 Late entry . 18
5.8.3.1 Late entry for clients within each system . 18
5.8.3.2 Late entry between systems. 18
5.8.4 DGNA . 19
5.8.4.1 User regrouping . 19
5.8.4.2 Group regrouping . 19
5.9 Short Data Service . 19
5.9.1 General . 19
5.9.2 Format conversion in the IWF of TETRA SDSs to MCData SDSs . 19
5.9.3 Format conversion in the IWF of MCData SDSs to TETRA SDSs . 20
5.9.4 Message references . 20
5.9.5 Delivery reports . 20
5.9.6 SDS length management by the IWF . 20
5.10 Status and alerts . 21
ETSI
4 ETSI TR 103 565-1 V1.2.1 (2018-12)
5.10.1 Status coding . 21
5.10.2 Emergency alert . 22
5.10.3 Callback request . 22
5.11 Speech coding . 22
5.12 Media encapsulation . 23
5.13 Security aspects . 23
5.13.1 Service authorization . 23
5.13.2 User authentication . 23
5.13.3 Interface authentication . 23
5.13.4 Media encryption and key management . 23
Annex A: Implications for MCPTT from interworking service . 25
A.1 General . 25
A.2 Interworking implications for MCPTT . 25
A.2.1 MCPTT group call models . 25
A.2.2 Talking party identity restriction . 25
A.2.3 Resource queuing . 25
A.2.4 SDS message rejection . 25
A.2.5 Codec configuration . 25
A.2.6 Private call keys . 26
A.2.7 Delivery of TETRA keys . 26
A.2.8 Late entry. 26
History . 27

ETSI
5 ETSI TR 103 565-1 V1.2.1 (2018-12)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables 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 1 of a multi-part deliverable covering interworking between TETRA and 3GPP mission
critical services, as identified below:
Part 1: "General considerations for interworking";
Part 2: "Security of interworking between TETRA and Broadband applications".
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
3GPP is standardizing a set of mission critical services as applications working over 3GPP LTE systems. These services
include speech PTT systems (MCPTT), data (MCData) and video (MCVideo) systems. Users have a need to interwork
between TETRA and 3GPP MC systems for a number of reasons which can include:
• Communication between different user groups who receive service from the different types of system.
• Use of both systems by the same set of users to allow selection of optimum radio coverage and services in any
situation.
• Migration from an existing TETRA system to a 3GPP MC system over a period of time, which may be long.
It is envisaged that an interworking function will be standardized as part of this work within ETSI TCCE to allow
communication between TETRA and 3GPP MC systems. The present document provides considerations for realizing
this interface.
ETSI
6 ETSI TR 103 565-1 V1.2.1 (2018-12)
1 Scope
The present document contains scenarios and considerations for an interworking function between TETRA and 3GPP
MC services.
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 EN 300 392-2: "Terrestrial Trunked Radio (TETRA); Voice plus Data (V+D); Part 2: Air
Interface (AI)".
NOTE: The latest version of either ETSI EN 300 392-2 or ETSI TS 100 392-2 applies.
[i.2] ETSI TR 102 022-2: "User Requirements Specification; Mission Critical Broadband
Communications; Part 2: Critical Communications Application".
[i.3] ETSI EN 300 392-1: "Terrestrial Trunked Radio (TETRA); Voice plus Data (V+D); Part 1:
General network design".
[i.4] Recommendation ITU-T E.218: "Management of the allocation of terrestrial trunk radio Mobile
Country Codes".
[i.5] IETF RFC 3986: "Uniform Resource Identifier (URI): Generic Syntax".
[i.6] ETSI EN 300 392-3 (all sub-parts): " Terrestrial Trunked Radio (TETRA); Voice plus Data
(V+D); Part 3: Interworking at the Inter-System Interface (ISI)".
NOTE: The referenced document has multiple parts; all parts are relevant.
[i.7] ETSI TS 123 280: "LTE; Common functional architecture to support mission critical services;
Stage 2 (3GPP TS 23.280)".
[i.8] ETSI TS 123 379: "LTE; Functional architecture and information flows to support Mission
Critical Push To Talk (MCPTT); Stage 2 (3GPP TS 23.379)".
[i.9] ETSI TS 123 281: "LTE; Functional architecture and information flows to support Mission
Critical Video (MCVideo); Stage 2 (3GPP TS 23.281)".
[i.10] ETSI TS 123 282: "LTE; Functional architecture and information flows to support Mission
Critical Data (MCData); Stage 2 (3GPP TS 23.282)".
[i.11] TETRA + Critical Communications Association: "TETRA Interoperability Profile (TIP);
Part 1: Core".
NOTE: Available at https://tandcca.com/interoperability/specifications-for-interoperability/.
ETSI
7 ETSI TR 103 565-1 V1.2.1 (2018-12)
[i.12] ETSI TS 126 201: "Digital cellular telecommunications system (Phase 2+) (GSM); Universal
Mobile Telecommunications System (UMTS); LTE; Speech codec speech processing functions;
Adaptive Multi-Rate - Wideband (AMR-WB) speech codec; Frame structure (3GPP TS 26.201)".
[i.13] IETF RFC 4867: "RTP Payload Format and File Storage Format for the Adaptive Multi-Rate
(AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs".
[i.14] ETSI TS 100 392-3-8: "Terrestrial Trunked Radio (TETRA); Voice plus Data (V+D);
Part 3: Interworking at the Inter-System Interface (ISI); Sub-part 8: Generic Speech Format
Implementation".
[i.15] ETSI EN 302 109: "Terrestrial Trunked Radio (TETRA); Security; Synchronization mechanism
for end-to-end encryption".
[i.16] 3GPP TR 23.781: "Study on migration and interconnection for mission critical services".
[i.17] 3GPP TR 23.782: "Study on mission critical communication interworking between LTE and
non-LTE systems".
[i.18] ETSI TS 124 379: "LTE; Mission Critical Push To Talk (MCPTT) call control; Protocol
specification (3GPP TS 24.379)".
3 Definition of terms and abbreviations
3.1 Terms
For the purposes of the present document, the terms given in ETSI EN 300 392-2 [i.1] and the following apply:
controlling system: system responsible for call control, policy enforcement, floor control management and media
distribution in a call
NOTE: A system may take either a controlling or a participating role in different circumstances.
group affiliation: mechanism by which a user's interest in one or more groups is determined
NOTE: Terminology used in 3GPP mission critical services; equivalent to TETRA group attachment.
group attachment: mechanism by which a user's interest in one or more groups is determined
NOTE: Terminology used in TETRA; equivalent to 3GPP group affiliation.
interconnection: means of communication between two systems whereby users obtaining service from one system can
communicate with users who are obtaining service from one or more other systems where the systems use similar
technologies
interworking: means of communication between two systems whereby users obtaining service from one system can
communicate with users who are obtaining service from one or more other systems where the systems use different
technologies
MCData: mission critical data service standardized in 3GPP
MCPTT: mission critical push to talk speech service standardized in 3GPP
MCVideo: mission critical video service standardized in 3GPP
migration: means for a user with a subscription to a first system to obtain service directly from a second system whilst
making use of the subscription to the first system
participating system: system responsible for call control, floor control management and media distribution on behalf
of its served users under the control of the controlling system
NOTE: A system may take either a controlling or a participating role in different circumstances.
ETSI
8 ETSI TR 103 565-1 V1.2.1 (2018-12)
3.2 Abbreviations
For the purposes of the present document, the following abbreviations apply:
rd
3GPP 3 Generation Partnership Project
ACELP Algebraic Code-Excited Linear Prediction
AMR-WB Adaptive Multi Rate - Wide Band
ASSI Alias Short Subscriber Identity
BS Base Station
codec coder-decoder
DGNA Dynamic Group Number Assignment
DTX Discontinuous Transmission
FFS For Further Study
GSSI Group Short Subscriber Identity
GTSI Group TETRA Subscriber Identity
ID IDentity
IP Internet Protocol
ISI Inter System Interface
ISSI Individual Short Subscriber Identity
ITSI Individual TETRA Subscriber Identity
IWF Inter Working Function
MC Mission Critical
MCC Mobile Country Code
MCPTT Mission Critical Push To Talk
MNC Mobile Network Code
MNI Mobile Network Identity
MS Mobile Station
PTT Push To Talk
QoS Quality of Service
RFC Request For Comment
RTP Real Time Protocol
SDS Short Data Service
SDS-TL Short Data Service - Transport Layer
SIP Session Initiation Protocol
SSI Short Subscriber Identity
SwMI Switching and Management Infrastructure
TCCA TETRA and Critical Communications Association
TETRA TErrestrial Trunked RAdio
TIP TETRA Interoperability Profile
TX Transmitter
URI Uniform Resource Identifier
4 Service overview
4.1 Services
User requirements are specified in ETSI TR 102 022-2 [i.2].
The following services are required to be carried across an interworking function between TETRA and 3GPP MC
services:
a) Individual call - duplex and semi duplex.
b) Group call.
c) Variants of these, such as emergency calls and broadcast calls.
d) Short Data Service.
e) Packet data service (see note).
ETSI
9 ETSI TR 103 565-1 V1.2.1 (2018-12)
Users will also require the following supplementary services to be supported:
a) Late entry on either system.
b) Talking party identity, carried between systems.
c) Calling party identity, carried between systems.
d) Restriction of calling and talking party identities carried between systems.
e) Group management on both systems.
f) Further supplementary services as required.
Additional service characteristics to be supported are:
a) Prioritization schemes allowing priority requests to be resolved between systems.
b) Pre-emption.
NOTE: Packet data service interworking is FFS, but may simply make use of IP routing techniques outside the
scope of this study.
Security services such as authentication, air interface encryption and end to end encryption need to be maintained
appropriately.
Note that the TETRA standard supports a wider range of functionality than the set that is required for interworking with
mission critical applications over broadband. Also, some aspects of services within the TETRA standard are not
commonly utilized within TETRA implementations, and are not specified for interoperability in the TCCA core TIP
[i.11] and accompanying specifications. Aspects of TETRA standard functionality that are not specified for
interoperability in [i.11] or not required for interworking in ETSI TR 102 022-2 [i.2] will not be discussed within the
present document. Additional functionality specified in the interoperability documentation following publication of the
present document may be reflected in future revisions of the present document.
4.2 Interworking realization
The concept of the interworking function can be as shown in figure 4.2-1.

Figure 4.2-1: Concept of the interworking function
The interworking function to be specified as a result of this study will take the TETRA Inter-System Interface, specified
in the ETSI EN 300 392-3 series of specifications [i.6] as a model of the functionality possible between TETRA
systems, and the MCPTT interworking interface, which is expected to be specified within 3GPP Release 15, as inputs.
The interface to the TETRA SwMI could make use of the TETRA ISI, or could be outside the scope of the
standardization process.
The present document is intended to lead to a Technical Specification which specifies the interaction between the
interface between a TETRA MS and a TETRA SwMI under the conditions of inter-system behaviour (shown as (1) in
figure 4.2-1), and the MC system interworking interface (shown as (2) in figure 4.2-1).
The TETRA Inter-System Interface is defined in ETSI EN 300 392-3 [i.6], and an MCPTT to MCPTT interface has
been studied in 3GPP TR 23.781 [i.16]. An MCPTT to non MCPTT interworking interface has been studied in 3GPP
TR 23.782 [i.17].
ETSI
10 ETSI TR 103 565-1 V1.2.1 (2018-12)
For the purposes of this study, the interface will be considered to be a single logical interface between each pair of one
MCPTT service and one TETRA SwMI. Any realization of multiple interfaces between a pair of systems e.g. for
resilience is FFS.
NOTE: Interface addressing is considered a lower layer function and is outside the scope of the present document.
5 Considerations
5.1 General
Considerations relating to TETRA - 3GPP MC service interworking are described in this clause.
5.2 Addressing
5.2.1 TETRA and MCPTT addressing
The TETRA standard identifies a subscriber by an Individual TETRA Subscriber Identity ITSI. This consists of a 24 bit
Mobile Network Identifier MNI (consisting of Mobile Country Code MCC and Mobile Network Code MNC), and an
Individual Short Subscriber Identity ISSI. The numbering scheme is described in ETSI EN 300 392-1 [i.3] and the
management of MCC and MNC is specified in Recommendation ITU-T E.218 [i.4].
3GPP MCPTT and MCData specify an MCPTT-ID and an MCData-ID which are a URIs; see ETSI TS 123 280 [i.7],
ETSI TS 123 379 [i.8] and ETSI TS 123 282 [i.10]. A URI is expected to be an alphanumeric string consisting of
individual user part and domain part. The MCPTT-ID and MCData-ID identify the system or systems within which the
MCPTT and MCData user subscriptions are located. There may be no limit on length, however IETF RFC 3986 [i.5]
recommends a maximum length of 255 characters. The 3GPP MC series of specifications also define an MCPTT Group
ID and an MCData Group ID, which are also URIs and which identify both the system and the MCPTT or MCData
server within the system where the group is defined. Additional services defined in ETSI TS 123 281 [i.9] and ETSI
TS 123 282 [i.10] define further service specific identities with the same structure; and the generic structure for MC
service identities from 3GPP Release 14 is defined in ETSI TS 123 280 [i.7].
TETRA is capable of carrying an external subscriber number field to convey an address that uses a numbering system
outside that of TETRA, however the limitations specified for this in ETSI EN 300 392-2 [i.1], clause 14.8.20, are that it
should have a maximum of 24 digits, where each digit is represented by a 4 bit number which can be numbers 0-9, '*',
'#' or '+'. A new external number field could conceivably be added to the TETRA standard, but the carriage of up to
255 characters, which could require 1 785 bits or 2 040 bits (if 7 or 8 bit alphabets were used) could prove problematic,
especially in the case of talking party identity. Somewhere around 8 full slots of information sent using the Basic Link
are unlikely to be sufficiently reliable, and could delay the start of a call by nearly half a second, hence this is unlikely
to be a valid solution.
Group identities have similar structures in each technology: a TETRA group is represented by a Group TETRA
Subscriber Identity, the GTSI, which is composed of the MNI and Group Short Subscriber Identity GSSI.
It is likely that an address book facility will be needed as part of the interface to allow an address in one system to be
represented as a different address in the other type of system in a way that is compatible with that system. This could
also act as a 'whitelist' if needed to gate which users are permitted to communicate on the other system. The address
book may only need to function in one direction if a URI is translated to a TETRA ITSI or GTSI, but the TETRA ITSI
or GTSI is provided in some form of URI on the MC system (e.g. as SSI@MNI such as 12345@67890). However, it
may also be more useful to show a name related to the ITSI or GTSI rather than numerical information on the MC
system. An address book translation of a URI representing an MCPTT user or MCPTT group to a TETRA ITSI or GTSI
could map the system identity part of the URI to a TETRA MNI, thus allowing different MCPTT systems to be
represented as different TETRA system MNIs to users within the TETRA system. As different MC service IDs may be
used for the same user when using different services on the 3GPP MC system, the address book in the interface may
need more than one service specific identity on the MCPTT side to map to a single ITSI on the TETRA side.
ETSI
11 ETSI TR 103 565-1 V1.2.1 (2018-12)
For example, a TETRA user making individual calls and sending SDS messages to a single ITSI which represents a
user on the MCPTT system may need that ITSI to be translated into an MCPTT-ID for the individual call, and to an
MCData ID for the SDS message.
NOTE: The functionality described within this clause is applicable to MCData as well as to MCPTT.
A single MCPTT or MCData user may also be active on multiple devices at the same time. He may have different
profiles active on different devices. However as these are still identified by the same MC service identities, the
interworking function may be able to forward calls or SDS messages to the MC system, and let the MC system decide
where and how to route the call or message.
More than one MCPTT or MCData user may be active on a single MC device at the same time. However, the
interworking function should only need to forward calls to the relevant MC service IDs, and let the MC system decide
on the final routing.
If a simple interworking system only required groups to be connected together and no individual services, the address
book may not need to list individual users provided talking party identity was not required across systems.
5.2.2 Interconnection and migration
A user may have a subscription to both a TETRA network and an MC service. However due to differences in the
naming and addressing, in security aspects and in service differences of the two technologies, a subscriber will not be
able to roam from one technology to the other using exactly the same subscription. Therefore, there is no requirement
for migration, and interconnection is the focus of the present document.
It is possible that an application will link a subscription on the TETRA network to a subscription on the MC service,
linking the two subscriptions to the same user. Such an application could provide some form of seamless connectivity,
attempting to complete calls to the user on whichever network he is receiving service, and possibly forwarding calls
between networks to complete such calls. It is FFS whether such functionality should be part of a later release of an
interworking function.
5.2.3 Identification of calling or talking party
It may be necessary to use an address book, as described in clause 5.2.1 above, to achieve the transmission of calling or
talking party across the interworking function if the identities used in one system cannot be conveyed in the other
system.
There will be situations where for reasons of confidentiality, the identity of a calling or talking party should be withheld
from called parties. The interface solution needs to take this into account and anonymize the talking party if necessary,
by indicating to the system of the called parties that the identity should be withheld. The TETRA ISI allows a parameter
to be associated with a call request to indicate whether the identity should be presented to called parties, or withheld.
NOTE 1: A similar parameter will be needed within an MCPTT or MCData system to indicate that a calling party
identity should be withheld, and the MCPTT server or MCData server will need to be able to withhold the
identity.
The restriction of talking party identity may not be needed within the system within which that user is receiving service
even if it is desired to anonymize the identity to users in the connected system.
NOTE 2: The controlling system has to trust the participating system not to falsify the identity of a user requesting
transmission in the non-anonymous case anyway. The controlling and participating systems are described
in clause 5.3.2.
ETSI
12 ETSI TR 103 565-1 V1.2.1 (2018-12)
5.3 Speech group calls
5.3.1 Group affiliation (group attachment)
As a pre-requisite to taking part in speech group calls, group affiliation (group attachment) is necessary to express an
interest in communications in that group. Any affiliations to a group in the participating system need to result in an
affiliation from the participating system to the controlling system. The controlling and participating system are
described in clause 5.3.2. The affiliation may be explicit or implicit. If explicit affiliation is used, at least one affiliation
is sent to the controlling system. If the controlling system requires knowledge of the identity of all affiliated group
members, then the affiliation and de-affiliation of each group member will need to be sent to the controlling system.
However if this is not needed, or if there are security constraints such as the participating system members wish to be
anonymous as far as the controlling system is concerned, then only the first affiliation to the group within the
participating system needs to cause an affiliation to the group to be sent from the participating system to the controlling
system, and similarly only the de-affiliation of the last group member needs to result in a disaffiliation be sent from the
participating to the controlling system.
If implicit affiliation is used between systems, or a single affiliation sent when the first group member joins the group in
the participating system, the controlling system may receive call set up signalling or floor control signalling from a
group member whose individual affiliation to the group is not known to the controlling system.
5.3.2 Controlling systems
In order to avoid conflicts in talking parties, one of the two systems will need to be assigned the controlling system for
the group. Requests for transmission from the non-controlling, i.e. participating system will be passed to the controlling
system, and the controlling system will decide to which party to grant transmission.
It should be possible to configure either the TETRA or the MCPTT system to be controlling system for any cross-
system group call. This should be configured on a group by group basis and not dynamically chosen.
NOTE: Any constraints which might prevent either TETRA or MCPTT from acting as controlling system are
FFS.
It is possible that the participating system may perform some local arbitration before forwarding a call request to the
controlling system, e.g. if two parties request transmission at the same time, the participating system may immediately
arbitrate and deny transmission to one party, only forwarding the call request of the successful party to the other system.
However, if the group supports queuing for transmission of other parties whilst one party is transmitting, then all call
requests should be sent to the controlling system so that it can build the queue appropriately.
If the nominated controlling system has no affiliated members, the nominated controlling system may still need to act as
controlling system, for example in case a group member affiliates to the group mid-way through a call.
5.3.3 Group linking
5.3.3.1 Overview
In an inter-system interoperability case within the same technology, for example TETRA - TETRA connection using
the ISI, group calls operating between systems can take place either by considering the group to be defined in one
system only, such that users affiliate/attach to the group directly in the home/controlling system of that group using the
ISI, or group linking can be used so that calls operating across systems can be realized by separate groups in each
system which are linked together, with one of the linked groups designated to be the 'master' or controlling part of
group. (Actually, it is the system hosting the controlling part of the group that is the controlling entity, but the linked
groups can be considered to have a master-slave relationship.)
Group linking could be a solution for TETRA - MCPTT interworking. Each terminal (TETRA MS or MCPTT client)
would affiliate to a group in their own system, where the group is linked to a group in the other system. There could be
different degrees of control and integration in such a solution.
The naming issues for groups may make a solution based on group linking simpler to achieve.
ETSI
13 ETSI TR 103 565-1 V1.2.1 (2018-12)
5.3.3.2 Interworking function as proxy group member
One method of linking TETRA and MCPTT groups would be for the TETRA Group Home SwMI to record the
MCPTT group as though it were the address of a single MS; i.e. as a single entry in its list of group members for a
particular TETRA group.
The interworking function could be always affiliated to the relevant group on each system, either by active affiliation
procedure or by configuration.
When the group home SWMI attempts to set up a group call to such a group, the setup will thus also be sent to the IWF.
The IWF will then use a translation table to convert the TETRA-compatible address into the MCPTT compatible group
address.
In the MCPTT group management server, the IWF is similarly recorded as a single member of the group, and call
setups from the MCPTT server will similarly include the IWF. The IWF will then translate from the MCPTT group
address to the matching TETRA group address.
When the call is set up on the MCPTT system, in order to identify the talking party in the call in the TETRA system, the
interworking function could use its address book to provide an associated ITSI for the MCPTT user (if an address
translation is provided for that user). Thus, the interworking function could provide a talking party identity for the
MCPTT user, provided the TETRA SwMI permitted the interworking function to provide talking party identities other
than the identity of the interworking function. The same process could work in reverse, with the interworking function
providing a translated MCPTT ID for a TETRA talking party.
If the interworking function acts as a true client, nomination of a controlling system and contention resolution in race
conditions could be an issue. However, if both systems permit either no talking party interruption, or any party to
interrupt any other regardless of any priority setting, and if the interworking function was configured to always give one
system priority over the other, the behaviour could remain predictable except in a race condition. To avoid race
conditions, one system would need to be given priority over the other, and the interworking function would need to
have permission to interrupt any other talking party within that system. This could imply that the interworking function
would need to have higher priorities than a dispatcher within the system.
In summary, the issues with race conditions and contention management are likely to make this an unsuitable solution.
5.3.3.3 Interworking function as proxy TETRA SwMI/MCPTT server
Another method would be for the interworking function to act as another TETRA SwMI, connected using an ISI which
employs group linking. The same situation would be the case on the MCPTT system, with the interworking function
acting as if it were another MCPTT system.
Using group linking behaviour, one of the two systems would be nominated to be the controlling system, which should
result in predictable behaviour in race conditions and pre-emption cases, as the interworking function would forward
any pre-emption requests to the controlling system.
There are three possibilities for affiliation where groups are linked by an interworking function that acts as a proxy
second SwMI/proxy second MCPTT system:
1) The interworking function is always affiliated to a group in both systems. In this case, the systems are always
linked in order to carry group calls across the interface whether there are users affiliated in both systems or
not. Individual affiliations from group members are not passed to the controlling system.

The system nominated to be the participating system would be expected to send call setup requests to the
controlling system even when the controlling system has no affiliated members.

The system nominated to be the controlling system would be expected to send call setup requests to the
participating s
...