TETRA System Release 6.0 - 7.0: Technical Overview

Technical Overview
TETRA System Release 6.0 – 7.0

DN064483-17-1en
(TRASYSAPP00211) 03/2017
The content of this document and its appendices and any information provided (all together "document") is for information purposes
only and is subject to change without notice. The document only specifies the products and services identified in the document. The
document is confidential and contains legally privileged information.
The document is only intended for the use of the recipient and the customer whose representative the recipient is, and may only be used
for the purposes for which the document is submitted. The document or any part of it may not be reproduced, disclosed or transmitted
without the prior written permission of Airbus Defence and Space.
Airbus Defence and Space will reasonably ensure that the information provided in the document is free from material errors and
omissions. However, the suggestions, directions, comments and statements made in the document (e.g. regarding the compatibility,
performance and functionality of mentioned hardware and software) are not intended to be and cannot be considered as binding. The
customer assumes full responsibility for using the document or any part of it. All comments and feedback are welcomed by Airbus
Defence and Space and are used as part of the continuous development and improvement of Airbus Defence and Space’s products,
services and the document.
Airbus Defence and Space disclaim and exclude all representations, warranties and conditions whether express, implied or statutory,
including but not limited to the correctness, accuracy or reliability of the document, or otherwise relating to the document. Airbus Defence
and Space’ total liability for any errors in the document is limited to the documentary correction of errors. Airbus Defence and Space will
not be liable for any direct or indirect damages arising from the use of the document or otherwise relating to the document.
Airbus Defence and Space® is a registered trademark of Airbus Defence and Space. Other product names, trademarks or other
identifiers mentioned in the document may be trademarks of their respective companies and are mentioned for information purposes only.
Copyright © 2016–2017 Airbus DS SLC, all rights reserved.
DN064483-17-1en TETRA System Release 6.0 – 7.0
2/119 This document and its contents are the property of Airbus DS SLC and must not be copied or circulated without authorisation
Contents
1 About this document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2 TETRA - an open standard for digital trunked radio systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.1 The TETRA standard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2 Characteristics of Airbus DS TETRA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3 TETRA compared to analog PMR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3 TETRA network interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.1 TETRA open interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.1.1 Air interface (AI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.1.1.1 Radio carriers and channels. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.1.1.2 Random access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.1.1.3 Common control channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.1.1.4 Packet data channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.1.1.5 Traffic channels. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.1.2 Inter-system interface (ISI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2 System external interfaces and 3rd party interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2.1 PABX/PSTN interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2.2 Interfaces to conventional systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2.3 Interface to IP networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2.4 Tactilon® Agnet interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.2.5 Application programming interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.2.6 TETRA Voice Gateway interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.2.7 Audio interface for command and control system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.2.8 Billing centre interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.2.9 Packet data interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.2.10 Recording interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.2.11 TETRA terminal authentication key distribution interface . . . . . . . . . . . . . . . . . . . . . . . . 28
3.2.12 O&M interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.3 System internal interface transmission technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.3.1 NMS interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.3.2 IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.3.2.1 DXT interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.3.2.2 TB3 interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
TETRA System Release 6.0 – 7.0 DN064483-17-1en
This document and its contents are the property of Airbus DS SLC and must not be copied or circulated without authorisation. 3/119
3.3.2.3 DWSx interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.3.2.4 RCS 9500 interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.3.2.5 SIP trunk interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.3.2.6 TETRA Voice Gateway interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.3.2.7 G4WIF Gateway interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.3.3 E1 . . . . ......................... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.3.3.1 Frame structure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.3.3.2 Physical implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.3.3.3 E1 synchronisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4 TETRA features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.1 Voice communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.1.1 Group communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.1.1.1 Resource allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.1.1.2 Dispatcher's view of group communication . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.1.1.3 Radio user's view of group communication . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.1.1.4 Tactilon Agnet client user’s view of group communication. . . . . . . . . . . . . . . . . 40
4.1.1.5 Speech item management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.1.1.6 Management of groups and group memberships . . . . . . . . . . . . . . . . . . . . . . . 41
4.1.1.7 Broadcast groups and background groups . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.1.1.8 Cover groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.1.2 Individual communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.1.2.1 Duplex call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.1.2.2 Semi-duplex call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.1.2.3 Direct call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.1.2.4 Dispatcher call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.1.2.5 Calling line identification presentation and restriction . . . . . . . . . . . . . . . . . . . . 44
4.1.2.6 Offering an individual call to a subscriber already engaged in an individual
call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.1.3 Emergency communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.1.3.1 Radio-subscriber-initiated or Tactilon-Agnet-client-user-initiated emergency
calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.1.3.2 Dispatcher-initiated emergency call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.1.3.3 Emergency call priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.2 Data communication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.2.1 Status messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.2.2 Short data service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.2.3 IP packet data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.2.3.1 High-speed packet data service (TEDS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.3 Aliasing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.4 Priorities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.4.1 System priorities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.4.2 Organisation and service priorities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.4.3 Scanning priorities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.4.4 Pre-emptive priority. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.5 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.5.1 Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.5.2 Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.5.3 Jamming detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.5.4 Ambience listening . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.5.5 Enabling/disabling a radio terminal. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.5.6 Logging of management events. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.6 SIM support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.6.1 SIM benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.6.2 Terminal SIM-related requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.7 Enhanced TBS fallback. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.7.1 Group calls. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.7.2 Individual calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.7.3 Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.8 Direct mode communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.9 Air-to-ground communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.10 Energy Economy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.11 Periodic registration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.12 Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.13 Numbering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.14 Remote SW downloading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5 TETRA network elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

5.1 Digital exchange (DXT). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.1.1 Taira TETRA Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
5.1.2 DXTA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
5.1.3 DXT3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
5.1.4 DXT3c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
5.1.5 DXT3p . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
5.1.6 DXTip and DXTTip (DXT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
5.2 TETRA Base Station (TBS). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
5.2.1 TB3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
5.2.2 TB3S . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
5.2.3 TB3c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
5.2.4 TB3p . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
5.2.5 TB3hp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
5.3 Tactilon® Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
5.4 Radio Console System (RCS 9500). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
5.5 Dispatcher Workstation (DWS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
5.6 TETRA Connectivity Server (TCS). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
5.7 Configuration and Data Distribution server (CDD). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
5.8 Audit Trail Server (ATS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
5.9 Enhanced Packet Data Gateway (EPD-GW) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
5.10 TETRA Voice Gateway (TVG) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
5.11 G4WIF Gateway. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
5.12 Authentication and Authentication Key Distribution (AKD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
5.13 Network management system (NMS). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
5.13.1 Local network management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
5.13.2 Centralised network management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
6 TETRA network solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

6.1 One network - multiple user organisations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
6.1.1 Communication within one organisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
6.1.2 Communication between organisations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
6.2 Scalable network structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
6.2.1 Single-DXT network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
6.2.2 Multi-DXT network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
6.2.2.1 Physical DXT-DXT topologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
6.2.2.2 Logical DXT-DXT topologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
6.3 TETRA IP backbone. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
6.3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
6.3.2 Site connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
6.4 TETRA IP packet core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
6.4.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
6.4.2 TETRA IP packet data services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
6.4.3 IP Packet data service alternatives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
6.4.3.1 Basic IP packet data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
6.4.3.2 Enhanced IP packet data and the TEDS extension . . . . . . . . . . . . . . . . . . . . 104
7 TETRA radio terminals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

7.1 Handportables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
7.1.1 TH9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
7.1.2 TH1n . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
7.1.3 THR9i . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
7.1.4 THR9+ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
7.1.5 THR9 Ex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
7.1.6 THR880i . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
7.2 Pagers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
7.2.1 P8GR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
7.3 Mobiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
7.3.1 TGR990 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
7.3.2 TMR880i . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
7.4 Data terminals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
7.4.1 TDM880i . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
List of Tables.
Table 1 Core elements and additional elements and interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Table 2 Client-capacity figures for the DXT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Table 3 Airbus DS TETRA terminals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Table 4 Airbus DS TETRA handportables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Table 5 Airbus DS TETRA pagers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Table 6 Airbus DS TETRA mobiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Table 7 Airbus DS TETRA data terminals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
List of Figures.
Figure 1 TDMA and control frames in a multiframe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Figure 2 RCS 9500's interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Figure 3 Protocol stack options for the NetAct-DXT connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Figure 4 Protocol stacks for NetBoss XT for TETRA and TETRA Element Monitor . . . . . . . . . . . . . . 30
Figure 5 TBCi usage with IP connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Figure 6 Group communication dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Figure 7 Radio unit display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Figure 8 Direct mode communication with optional TMO/DMO Gateway. . . . . . . . . . . . . . . . . . . . . . 61
Figure 9 DMO Repeater . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Figure 10 Several organisations sharing one network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Figure 11 Multiple groups with a shared dispatcher (single organisation) . . . . . . . . . . . . . . . . . . . . . . 88
Figure 12 Multiple groups with common radio members and shared dispatchers (single
organisation) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Figure 13 Communication between organisations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Figure 14 Example of a small single-DXT TETRA network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Figure 15 Example of a larger, multi-DXT TETRA network. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Figure 16 Example of a hierarchical DXT-network topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Figure 17 Full mesh topology of a flat DXT network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Figure 18 Basic architecture of the IP network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Figure 19 TETRA packet data service for radio subscribers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Figure 20 IP network connectivity for TETRA applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Figure 21 Network elements used in the different TETRA IP Packet Core solutions . . . . . . . . . . . . . 101
Figure 22 Protocol architectures of the basic and enhanced IP packet data services . . . . . . . . . . . . . 102
Figure 23 Basic IP packet data flow before and after roaming from one DXT to another . . . . . . . . . . 103
Figure 24 Enhanced IP packet data flow before and after roaming from one DXT to another . . . . . . . 105
Figure 25 TH9 handportable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Figure 26 TH1n handportable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Figure 27 THR9i handportable. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Figure 28 THR9+ handportable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Figure 29 THR9 Ex handportable. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Figure 30 THR880i handportable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Figure 31 P8GR pager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Figure 32 TGR990 mobile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Figure 33 TMR880i mobile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Figure 34 TDM880i data terminal. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
DOCUMENT AMENDMENTS
VERSION DATE COMMENTS CHAPTER

UPDATED
17-1 03/2017 Added Taira TETRA Server. 5

Minor modifications Throughout
16-4 09/2016 Updated for G4WIF Gateway. 3.2.2
3.3.2.1
3.3.2.7
5.1.2
5.11
Minor modifications. Throughout
16-3 04/2016 Section Tactilon® Management updated. 5.3
16-2 02/2016 Minor modification related to the SIP gateway. 3.3.2.5
16-1 01/2016 Added information on the optional VMU extension in 3.2.4
the DXTA. 3.3.2.1
Added information on the possibility to connect DXTA to 3.3.2
other DXTs over E1 for inter-DXT speech lines. 3.3.3
5.1.2
6.2.2
16-0 11/2015 Information on DXTA has been added. Existing 1 , 3.2.1 , 3.2.2
information has been modified to take DXTA into , 3.2.6 , 3.2.10
account. 3.3.2 , 3.3.2.1 ,
3.3.2.2 , 3.3.2.5
, 3.3.3 , 4.1.3.2
, 4.2.3 , 4.2.3.1 ,
4.5.2 , 4.14 , 5 ,
5.1 , 5.1.2 , 5.2
, 5.4 , 6.2.2 , 6.3
, 6.3.2 , 6.4.3.1 ,
6.4.3.2
Information on the TETRA Voice Gateway has been 3.3.3.2 , 5.10
updated.
RCS 9500 interface has been added. 3.3.2.4
DXT3 Element Monitor's name has been changed to Throughout
TETRA Element Monitor.
15-1 09/2015 The name of the feature SDS-4 priority profiles has 4.2.2
been corrected.
GGSN has been removed. Throughout
References
1. Air Interface Encryption in the TETRA System (TRASYSAPP00001)
2. Audit Trail Server, Commissioning Manual (TRADXTAPP00003)
3. Audit Trail Server, Product Description (TRADXTAPP00183)
4. Audit Trail Server, User's Guide (TRADXTAPP00002)
5. Authentication in the TETRA System (TRASYSAPP00003)
6. CDD Server, Commissioning Manual (DN03533691)
7. CDD Server, Product Description (TRADXTAPP00182)
8. CDD Server, User's Guide (DN03533676)
9. Data Message Services, (DN00126503)
10. DWS Communication User's Guide (DN00132181)
11. DWS Management User's Guide (DN00132209)
12. DXT3TM and DXT3c Product Description (TRADXTAPP00028)
13. DXT3p Product Description (TRADXTAPP00080)
14. DXTA Product Description (TRADXTAPP00106)
15. End-to-end Encryption in the TETRA System (TRASYSAPP00002)
16. Guide to TETRA Documentation (DN00126445)
17. Introduction to Features (DN00126484)
18. IP Packet Data Service (TRASYSAPP00288)
19. Installing and Commissioning the TETRA Voice Gateway (TRATCSAPP00011)
20. Product Description for the TETRA Dispatcher Workstation (DWS) (DN05221844)
21. RCS Product Description (RC1/SYS/APP/00011)
22. Tactilon® Management Product Description (TRADWSAPP00013)
23. Tactilon® Agnet User Manual, TRASYSAPP00427
24. Tactilon® Agnet Release Note, TRASYSAPP00421
25. Tactilon® Agnet Solution Description, TRASYSAPP00419
26. Taira TETRA Server Product Description (TRADXTAPP00187)
27. TB3 Product Description (DN04102617)
28. TB3c Product Description (DN0531348)
29. TB3hp Product Description (TRATBSAPP00029)
30. TB3p Product Description (TRATBSAPP00022)
31. TB3S Product Description (TRATBSAPP00025)
32. TCS Product Description (DN0116031)
33. TETRA Enhanced Packet Data Gateway, Product Description (TRASYSAPP00126)
34. TETRA Voice Gateway, Product Description (TRATCSAPP00010)
35. Voice Communication (DN00126496)
1 About this document
This document provides an overview of the architecture, network elements, and capabilities of the
infrastructure of the Airbus DS TETRA System. It also describes system services and equipment which
are important from the point of view of end users.
The purpose of the document is to give an understanding of the structure, solutions, and operation of the
system infrastructure as a whole. It is intended as a general reference or tutorial document for technical staff
involved with planning, implementing, and maintaining the network infrastructure, but it can be read by anyone
who has at least basic knowledge of the TETRA standard, internet technology, and telecommunications
systems and technology in general.
Some of the features, functions, and equipment described in this document may not be available in all market
areas, or are separately priced commercial options. Please contact your local Airbus Defence and Space
representative for further information.
Note
TETRA IP transmission is supported from TETRA System Release 6.5 onwards.
We welcome any suggestions for further improvement of this document. Also, should you find any errors
or omissions in this document, please forward your comments to your local Airbus Defence and Space
representative or e-mail them to tetra.cudo@airbus.com.
How to use this document
The document is organised as follows:
Chapter 1 explains what the document is for and how it is organised.
Chapter 2 gives an overview of the TETRA standard, with emphasis on the Airbus Defence and Space's
TETRA solution.
Chapter 3 gives an overview of the interfaces used in the Airbus DS TETRA System.
Chapter 4 describes the basic communication services of the Airbus DS TETRA System, the priority scheme,
and some security features.
Chapter 5 gives an overview of the main network elements used in the Airbus DS TETRA System.
Chapter 6 describes the TETRA network solutions.
Chapter 7 gives an overview of the TETRA radio terminals offered by Airbus Defence and Space. Note,
however, that the radio terminals are not part of the Airbus DS TETRA System infrastructure.
The References section gives guidance to related documents. Abbreviations used in this document are
explained in the Glossary section. An Index is also provided at the end of the document.
PAGE INTENTIONALLY LEFT BLANK
2 TETRA - an open standard for digital trunked
radio systems
2.1 The TETRA standard

Terrestrial Trunked Radio (TETRA) is a set of open standards developed by the European Telecommunications
Standards Institute (ETSI). TETRA is the first truly open international standard for the digital professional
mobile radio environment. It specifies a set of open interfaces and services for mature professional mobile
radio systems.
A number of European authorities and leading radio terminal and system manufacturers worldwide
participated in the specification work. As a result, both the high-level demands of the authorities and the
possibilities offered by the latest technology have been successfully combined.
The European Union has reached an agreement to allocate the 380 - 400 MHz frequency band for public
safety and security (PSS) use. This use of a common standard and frequency band makes it possible for the
authorities in different countries to operate in one another's TETRA networks if this is required. The 410 -
430 MHz frequency has been allocated for use by the professional cellular sector. Other countries may use
different frequency bands; in Asia, for example, the 800 MHz band is used.
2.2 Characteristics of Airbus DS TETRA

The Airbus DS TETRA System is designed to meet two main objectives:
• Compliance with the TETRA standards for combined voice and data
• Ease of use and fulfilment of critical user requirements, which have been determined by carrying out
a comprehensive analysis of user operations.
The TETRA solutions offered by different manufacturers have different capabilities. The key strengths
of the Airbus DS TETRA solution are:
• Telecommunication-grade switching platform with an integrated core switch
The centralised, integrated core switching platform makes it easier to manage, maintain, and upgrade
the network. The duplicated switching units have a substantially longer life cycle, which cuts down
the long-term operating and maintenance costs. The operating system of the core switch has been
designed to handle high traffic loads and to enable the providing of uninterrupted service at all times.
• Reliable, fault-tolerant core network with an excellent radio coverage
The built-in redundancy of the Airbus DS TETRA solution provides an effective way to ensure that the
system has a reliable backup capability.
• Flexible network topologies
A layered network topology offered by the Airbus DS TETRA solution minimises the number of logical
connections and gateways needed for transmission, enabling faster signalling and call set-up times.
In addition, the base stations provide multiple transmission topologies, which offer a cost-effective
way to implement network connections.
• First class security and confidentiality
Encrypted communication combined with the authentication of the radio terminals provide security
and confidentiality at all levels of the network. The sophisticated priority, redundancy, and disaster
recovery features give very high availability for basic services and high priority users. The data integrity
mechanisms assure that the users can trust the data they see and use. Recording and logging
features are available to fulfil the non-repudiation requirement; past situations can be reconstructed
and analyzed afterwards, if needed.
• Seamless communication also in multi-switch networks
The quality of services is the same throughout the network, even in networks which consist of many
switches.
• TETRA Inter-System Interface (ISI)
The TETRA ISI enables the users the possibility to migrate, roam and register to another network,
which allows the conducting of cross-border operations and co-operation between different security
organisations while maintaining a high level of security at all times.
• Full Virtual Private Network (VPN)
The VPN concept enables the private and secure handling of confidential material in shared,
multi-agency networks. In practice, organisations can share the use of their network infrastructure
without compromising their privacy or security.
• High-speed packet data services (TEDS)
TETRA Enhanced Data Service (TEDS) provides high-speed IP packet data services by using
multi-slot operation. The same packet data channel resources can be shared by several users. The
higher speed of data enables, for example, more IP transmission capacity to be used for IP applications
and new applications.
• Efficient, centralised management of network elements
The centralised management of network elements enables, for example, remote operability which
reduces the number of site visits and further cuts down the operating costs.
The Airbus DS TETRA solution also offers several unique communication features, such as:
• Active scanning
Users cannot set their radio terminals to listen to any groups for which they are not authorised, which
allows both better security and better control of the field forces.
• Excellent radio coverage
The six-channel reception of the TB3 base stations enables an excellent radio coverage without blind
spots, thereby ensuring reliable and effective radio communications.
• Flexible emergency calls
The target of the emergency call is defined in the Airbus DS TETRA System, which allows the
organisation's emergency call target to be changed at any time without having to re-program the radio
terminals. The emergency call target can be defined for each subscriber, organisation, or on the
system level; the latter ones can also act as backup targets in case the call cannot be completed
to the first tried target.
• TETRA Services for Smart Devices
From TETRA System Release 7.0 onwards, it is possible to use a wireless IP device – that is, an
Android smart phone – to participate in communication in the TETRA system. The Tactilon® Agnet
solution enables seamless TETRA voice- and short data communication among wireless IP devices or
between wireless IP devices and TETRA radio terminals. Both the wireless IP devices and the TETRA
radio terminals can be handled by using the same dispatching and subscriber/group management
solution, which provides an excellent level of interoperability.
• Managed talk groups and group memberships
Every talk group in the system has a list of allowed members. Only users who are members of the
group can talk to or listen to the group.
In addition, the Airbus DS TETRA terminals can offer the benefit of synergy when used in an Airbus DS
TETRA network. For example, the Airbus DS TETRA radio terminals always register all selected and scanned
talk groups they are about to use. Because the Airbus DS TETRA system always knows this status, it is
possible to implement the communication plans needed by the user organisations.
2.3 TETRA compared to analog PMR

Digital PMR systems offer many functions and features that are not available in analog systems. For example,
integrated voice and data communication, and sharing of a single network by multiple user organisations.
Group communication in TETRA differs from traditional open-channel communication in the following ways:
• Communication is encrypted on the air interface.
• Creation of groups is not restricted by geographical area or the number of channels.
• Individual calls can be made between subscribers in the TETRA system and PABX/PSTN networks.
• Better suppression of background noise thanks to advanced digital voice coding.
• Better spectral efficiency thanks to time division multiplexing, which enables multiple channels per
carrier instead of the single channel in analog systems.
3 TETRA network interfaces
3.1 TETRA open interface
3.1.1 Air interface (AI)
The air interface (AI) provides the communication path between the TETRA network and the radio terminals
(RT). The AI complies with the ETSI 300392-2 TETRA air interface standard. This section covers only the
basics of the air interface as they pertain to the Airbus DS TETRA System.
3.1.1.1 Radio carriers and channels
The physical resource used to carry communication between the network and radio terminals is a slice of
the radio spectrum (the frequency band allotted to TETRA communication) which is divided up in frequency
and time. A pair of uplink and downlink frequencies is allocated for each carrier (frequency division), and
each carrier is time-divided into four radio channels.
A single TBS can have up to 8 carriers, one of which is designated as the main carrier. One channel timeslot
of the main carrier is designated as the main control channel (MCCH). The other slots (up to 3) of the main
carrier can be defined for load sharing purposes as secondary common control channels (common SCCH)
which offer a similar 1-slot wide common control channel functionality as the MCCH.
Carrier frequencies can be classified into two types: primary and secondary. If there are frequencies
which need to be 'downgraded' (for example, frequencies which cause interference or which are victims of
interference), they are ranked as secondary frequencies. TETRA is a trunked system, which means that
when a call is established on the air interface the traffic channel (that is, carrier + channel timeslot) for that
call is allocated from the pool of free channels available at that time (primary if available, secondary if not)
and the radio terminal instructed to switch to that traffic channel. Similarly, when a packet data transfer starts,
a packet data channel (PDCH), consisting of carrier + channel timeslot, is allocated for the duration of the
packet data transfer from the pool of free channels available at the time.
A TBS can also have TEDS carriers, each offering a 4-slot wide packet data channel using QAM modulation.
The QAM channel bandwith can be either 25 kHz or 50 kHz.
3.1.1.2 Random access
TETRA radio terminals use a random access protocol to access the base station. This means that there is a
common access resource that is shared by all RTs. When an RT wants to transmit a message, it requests
resources for the transmission. The random access protocol used in TETRA is the slotted Aloha protocol.
As the access resource is shared by all RTs, there may be more than one RT attempting to transmit a
message to the base station at the same time. When this happens the messages overlap causing a
collision on the air interface.
The Airbus DS TETRA System supports the use of the collision based random access feature to handle
congestion on MCCH or common SCCH, if available. It improves the random access throughput under heavy
load situations without slowing down access under light load.
3.1.1.3 Common control channel
One channel in every TBS is designated as the Main Control Channel (MCCH). In addition, there may be
one or more common SCCHs. The MCCH and common SCCH(s) carry system management messages;
the remaining channels can be used for voice traffic or packet data.
Signalling from the TBS to radio terminals (downlink)
The TBS uses the MCCH, or the SCCH if it is available, to send system control messages and call setup
signalling on the downlink. In addition, status and SDS messages are also sent on the control channel.
Downlink signalling carries the following information:
• Information on the serving and neighbouring cells used during cell selection or random access.
Information on the serving cell is provided in the Sync and Sysinfo messages, and information on the
neighbouring cells in the D-Nwrk Broadcast message.
• Information on the usage of the time slots for the uplink, either random access or the opportunity of
reserved access permission. The radio terminal may get permission to transmit in other slots than the
half-slot available through random access. The infrastructure tells when a radio terminal can send with
random access and when it cannot.
• Random access parameters (included in the Sysinfo message)
• Layer 2 (data link layer) and layer 3 (network layer) acknowledgments
• Status and SDS messages addressed to a group or an individual radio user
• Information on calls, including:
– Call setup phase messages
– Restoring messages after handover, using the U-Restore message
• Information on packet data, including:
– Paging the MS for packet data transfer
– Transfer request (directing the MS to the PDCH)
• Information on groups, including the following:
– Ongoing group calls in the serving cell, using the Late Entry D-Setup message if the group-specific
parameter late entry enabled allows it.
– Whether the radio subscriber is in the group area, using the D-Attach/Detach Group Identity
message.
– Group memberships when a dispatcher adds or removes radio users to or from a group, using the
DGNA-Assign or DGNA-Deassign messages.
Signalling from radio terminals to the TBS (uplink)
Uplink signalling on the control channel is sent using random or reserved access.
Uplink signalling contains the following:
• Registration messages, using the U-Location Update Demand message
• Information on calls, including:
– Call setup phase messages
– Restoring messages after handover, using the U-Restore message
• Information on packet data, including:
– Context set-up
– Context release
– Transfer request
• Status and SDS messages addressed to a group, an individual radio user or a DWS
• Information on groups, using the U-Attach / Detach Group Identity messages, including
– the selected group and
– the group memberships when a radio user activates or deactivates a group using the D-Attach
/ Detach messages.
3.1.1.4 Packet data channel
IP datagram transfer is done on the Assigned Secondary Control Channel (ASCCH), which is also called the
Packet Data Channel (PDCH). The network commands the terminal to the PDCH when the terminal sends or
receives IP packet data and back to the MCCH or common SCCH when the data transmission is over.
The system allocates phase-modulated (PM) channels for both IP Packet Data and voice calls from the same
pool. However, the maximum number of IP packet data channels (PM PDCH) can be defined using MML
parameters per a base station, that is, the system can be configured so that there are always some timeslots
available exclusively for speech channels on the TBS site.
When TEDS TTRXs have been configured to a TBS, they are always used as 4-slot wide QAM packet data
channels (QAM PDCHs). The QAM packet data channels are shared by several radio terminals having
packet data transfer ongoing.
3.1.1.5 Traffic channels
On the RT-TBS uplink and downlink, traffic channels are TDMA timeslots. When there are no ongoing calls,
channel timeslots 2, 3, and 4 of the main carrier and timeslots 1, 2, 3, and 4 of other carriers are unallocated.
When a call is set up, the selected channel becomes a traffic channel (TCH).
Speech is transmitted in the traffic channels. The TDMA has a multi-frame structure (see Figure 1 ) in which
frames 1 to 17 are reserved for speech or packet data and frame 18 is reserved for signalling. In between
speech items, frames 1 to 17 are also used for signalling.
Since the signalling capacity provided by traffic channels is very limited, the Airbus DS TETRA System does
not allow long SDS messages (user-defined data 2, 3, or 4) on the traffic channel downlink.
1 multiframe = 18 TDMA frames
1 2 3 4 5 17 18
control frame
1 2 3 4
1 TDMA frame = 4 timeslots = 4 channels (MCCH or TCH)

dn00122776x1x0xen
Figure 1 : TDMA and control frames in a multiframe
Signalling from TBSs to radio terminals (downlink)
On the downlink traffic channels, the signalling contains the following:

• Call information:
– information about the start, termination, or queuing of a speech item
– information about the termination of a call
– information on the ongoing group calls in this TBS, using the Late Entry D-Setup message if the
group-specific parameter priority scanning supported allows it
• Upcoming cell re-selection acknowledgments
• Status and short SDS messages (user-defined data 1) addressed to a group or an individual radio user
• Information on neighbouring cells used during cell selection. Information on the serving cell is provided
in the Sync and Sysinfo messages and information on the neighbouring cells in the D-Nwrk Broadcast
message.
Signalling from the radio terminals to the TBS (uplink)
The following signalling takes place on the uplink traffic channels:

• About the calls:
– speech item requests
– information about the termination of a speech item
– information about the termination of an individual call
• Message informing of upcoming cell reselection
• Cell reselection announcement when a radio user is engaged in a group- or individual call
3.1.2 Inter-system interface (ISI)
An Airbus DS TETRA network can be connected to several other TETRA networks via the E1-based
standardised inter-system interface (ISI). The ISI interface enables individual and group calls to be
established between the TETRA networks as well as SDS and status message sending between networks.
When a radio subscriber migrates to the foreign TETRA network the ISI connection enables to inform the
current location to the home network thus allowing the home network to approve or deny the migration. Home
network will forward the call setups and SDS/Status messages over ISI to the current location network
when the called party is migrated.
The inter-system interface uses PSS 1 signalling over an E1 line. On the physical level, an ISI interface
towards the other network is configured as ISDN PRA (30B+D) interfaces provided by ECE2-NT(C)
plug-in-units in DXT. One ECE2-NT plug-in contains two 2Mbit/s E1 connections. Each E1 interface provides
capacity for 30 x 64kbit/s B-channels and one 64 kbit/s D-channel (30B+D).
The interface towards the connected TETRA network may consists on several E1s. The connection from a
single DXT can contain several E1s to provide sufficient capacity. For redundancy purposes, the connection
can be defined also from several DXTs, which then offers also additional capacity.
For more information on the ISI, see the document Inter-System Interface Functionality (DN0626450).
3.2 System external interfaces and 3rd party interfaces

The Airbus DS TETRA System network supports the following types of external interfaces:
• Telephone-network (PABX/PSTN) interfaces
• Interfaces to conventional systems
• IP network interface
• Tactilon® Agnet interface
• Application programming interfaces (API)
• TETRA Voice Gateway interface
• Audio interface for command and control systems
• Billing centre interface
• Packet data interface
• Recording interface
• TETRA terminal authentication key distribution interface
• O&M interface
3.2.1 PABX/PSTN interfaces

The Airbus DS TETRA System supports individual and group voice calls between TETRA subscribers and
subscribers of the Public Switched Telephone Network (PSTN) and Private Automatic Branch Exchanges
(PABXs). A TETRA subscriber can make/receive calls to/from subscribers in the PSTN or PABX(s) via two
logical ports in the TETRA system: the PSTN Gateway and the PABX Gateway. Each gateway is associated
with one or more external-line interfaces via which the calls can be routed. Dialling of PSTN and PABX calls
is comparable with ordinary phone calls, but the speaking may differ because semi-duplex transmission may
be used in the Airbus DS TETRA System.
The DXT3, DXT3c, DXTip and DXTTip can be equipped with line interface units providing the following
types of PSTN/PABX interfaces:
• ISDN PRA (ETSI Euro ISDN 30B+D) interfaces are provided by DXT plug-in-units type ECE2-NT(C).
• Digital R2 interfaces are provided by DXT plug-in-units type FNIM ET.
The ECE2-NT(C) and FNIM ET are hardware-identical but have different software installed. They both
provide two interfaces and they share the same board slots in the DXT. The two FNIM ET interfaces can each
be independently configured as a digital R2 or digital G4WIF (Generic 4-Wire Interface).
Analog R2 can also be implemented using a digital R2 interface in connection with additional equipment
external to the DXT.
It is also possible to use Session Initiation Protocol (SIP) trunk interface for connecting PSTN and PABX
to the TETRA network through a SIP gateway. This feature is supported by DXTs that do not have the
ECE2-NT(C) / FNIM ET units described above. They support only individual PABX/PSTN calls over the SIP
trunk interface. If needed, an external SIP gateway device can also be used.
3.2.2 Interfaces to conventional systems
The Airbus DS TETRA System provides a digital generic 4-wire interface (G4WIF) for connecting external
analogue radio systems and analogue communication equipment to group communication of TETRA
networks. A G4WIF can be added to a group and participate in group communication.
The G4WIF interface provides connection to any external system that fulfills the electrical and operational
requirements set for the G4WIF interface. In addition, other systems with simple interfaces, such as air
and marine radio systems or command and control centres, can be attached to TETRA groups via the
G4WIF interface.
FNIM ET interface
With E1 connected DXTs, the digital G4WIFs can be implemented with the FNIM ET interface unit, if present
in the configuration. An analog G4WIF can be implemented with the help of additional equipment external
to the DXT.
G4WIF Gateway
With IP-only-connected DXTs that do not have FNIM ET interface units, the connection to conventional
systems is possible by using a G4WIF Gateway (G4WIF GW). The G4WIF GW converts IP transmission into
E1 and directs the traffic to an external system, and vice versa. Additionally, an E1 multiplexer can be used
between the G4WIF GW and the external system, if needed.
RCS 9500's Radio Gateway interface
The RCS 9500's Radio Gateway provides the interface between an external system and the RCS 9500's
IP network (LAN/WAN). Each Radio Gateway provides an interface for a single analog radio channel or a
Wireless TETRA radio.
During normal operation, the Radio Gateway must be connected to a LAN or WAN that supports TCP/IP
communication. The Radio Gateway is connected to the network using a standard Ethernet RJ45 connector
and a CAT 5 (or better) cable. The Radio Gateway can connect to any base station that accepts tone
control commands.
Figure 2 : RCS 9500's interfaces
For more information on RCS 9500, see chapter 5.4 .
For more information on the G4WIF interface, see Interfacing Conventional Radio Systems and Recording
Devices to the TETRA System, DN05103027.
3.2.3 Interface to IP networks

Radio terminals (RT) in an Airbus DS TETRA network can be granted access to services provided by external
IP networks such as the Internet, ISPs and corporate intranets by internetworking the Airbus DS TETRA
network IP backbone with these external networks. This is normally done via a VPN firewall/router located in
one of the IP backbone LAN segments. This arrangement is also used to enable third-party clients located in
external LANs to login to the TETRA system via a TCS and access its services.
Further information on external IP interfaces is given in Chapter 6.3 , Chapter 6.4 and Chapter 5.6 .
3.2.4 Tactilon® Agnet interface
Wireless IP devices can be used to participate in individual and group calls in an Airbus DS TETRA network
by using the Tactilon® Agnet solution, which is supported from TETRA System Release 7.0 onwards. The
Tactilon Agnet client accesses the TETRA network using a VPN client via a secure VPN tunnel, which
protects the Tactilon Agnet traffic by authenticating and encrypting the IP packets transferred between the
Agnet client and the DXT. The VPN gateway also verifies the VPN client’s authentication credentials.
The DXT functions as the server for the Agnet client users. The voice frame switching is performed by
the EsGate unit.
• In the DXTs containing TETRA Application Server Units (TAS), the TAS units provide the Tactilon
Agnet server signalling functionality.
• In the DXTs that do not support TAS units, the TGS unit functions as the signalling unit.
For more information, see the product description of the DXT type in question. Note, however, that DXT3p
does not support TAS functions.
The Tactilon Agnet interface is a SIP- and RTP-based interface, which supports TETRA services to the Agnet
clients. The RTP/UDP protocol is used for transporting the TETRA audio and the SIP protocol is used for
signalling.
3.2.5 Application programming interfaces

TCS API
The TCS API offers a comprehensive set of TETRA services to the application, including status and SDS
messaging, voice call, group management, and provisioning services. The customised applications can be
interconnected to the Airbus DS TETRA System by using one of the following:
• TCS API interface, which allows simultaneous access to TETRA services over IP by multiple
customised third party applications such as command and control systems (CCS).
• Web Services Interface (WSIf) provides a platform-independent application interface especiallly for
status and SDS message applications. The connection between the TCS and the application computer
is https over TCP/IP (SOAP).
Two options, TCS single-user and TCS multi-user, are provided for third parties to enable them to develop
customised client applications. With the TCS single user, only one client application at a time can access the
API services. The TCS multi-user is a scalable solution serving multiple client applications simultaneously.
TETRA voice for third-party client applications requiring it is transferred to/from the client applications via
E1-based interfaces in the DXT.
Tactilon API
The Tactilon API is a software component running in the Tactilon® Management server. It can be used by
third-party applications to access a subset of the functionality available through the Tactilon Management GUI.
Security
API connectivity runs on HTTPS. The entire underlying HTTP protocol is encrypted, including:
• username / password
• request URL (which API object was accessed); includes all query parameters and request/reply
headers and content.
On the server side the API could be implemented with existing Tactilon® Management HW configurations,
but expanding the capacity would require additional blades and network interfaces (similar to the existing
configuration, no special components required).
On the client side, the API client requires standard IT HW components only. SW toolkits are available as
open-source and commercial-vendor components.
RCS 9500 API
Support for third-party developed RCS 9500 clients (consoles) is provided through the RCS 9500 Application
Programming Interface (API).
The RCS 9500 provides applications, such as CAD systems or automatic vehicle location (AVL) applications,
with full access to the TETRA radio features via easy-to-use interfaces. For third-party system suppliers, a
software development kit (SDK) is available, which gives access to the RCS 9500 APIs. The RCS 9500 SDK
contains the RCS 9500 SDK Guide and the WSDL and XSD documents required by third-party developers to
build RCS 9500 clients to access analog radio, TETRA, and SAM interfaces.
The standard RCS 9500 Console's USB product activation key includes permission for up to nine additional
client applications to access the RCS 9500 API. A permission for varying numbers of additional client
applications to access the RCS 9500 API can also be included in the RCS 9500 Lite Console's USB product
activation key. These options can be used to permit third-party applications to use the RCS 9500 API in
order to communicate with the TETRA network.
3.2.6 TETRA Voice Gateway interface
The TETRA Voice Gateway's IP interface can be used for connecting voice applications. The supported
audio codecs are PCM, G.711 A-law and G.711 μ-law codecs; note, however, that one audio codec at a
time is supported by one TETRA Voice Gateway.
Both unicast and multicast addressing can be used between the TETRA Voice Gateway and the CCC
system or individual audio clients. However, IP network elements such as switches and routers need
to support IP multicast.
TETRA Voice Gateway is connected to a DXT over E1. However, from TETRA System Release 7.0 onwards,
TETRA Voice Gateway supports also connection to DXT over IP.
3.2.7 Audio interface for command and control system

The Airbus DS TETRA System provides different alternatives for customer-specific command and control
system (CCS) integration via TETRA Connectivity Server (TCS), including the use of the Xgear multi-interface
card. The audio interface for CCS can be implemented, for example, by using the ET audio interface for
providing the CCS with audio channels for group monitoring and voice communication and using the TCS API
for providing the CCS with access to the Airbus DS TETRA System. The E1-based ET audio interface can be
used in the DXTip, DXTTip, DXT3 and DXT3c exchanges.
For more information on the audio interface for CCS, see DXT ET Audio Interface for CCS Integration
(TRASYSAPP00006).
3.2.8 Billing centre interface

The charging data records are generated in the DXT. The charging files that contain the charging records are
transferred from the Statistical Unit (STU)/OMU disks to the billing centre by using the File Transfer Protocol
(FTP/SFTP) of the TCP/IP protocol stack. It is also possible to use the FTAM protocol over an OSI/LAN
connection. The billing centre acts as the initiator of the transfer process. For more information on the
interface, see Charging Services: DXT - Billing Centre Interface Description (DN00126566).
3.2.9 Packet data interface

In the Airbus DS TETRA System, the packet data interface can be implemented by using the Enhanced
Packet Data (EDP) Gateway. The interface between the EPD-GW, DXT, and Intra at the site where the
EPD-GW is located is implemented by using Ethernet connections. For more information, see Enhanced
Packet Data Gateway Commissioning Guide (TRASYSAPP00157).
3.2.10 Recording interface

The archive recording (AR) system can be connected to the Airbus DS TETRA network via remote-client
interfaces of that network. The recording system can be used to monitor and/or record voice calls in specific
TETRA groups, status and SDS messages addressed to specific TETRA groups, and also voice, status and
SDS calls made or received by specific individual TETRA subscribers.
The data interface is implemented as a client-server connection over TCP/IP between a multi-user TETRA
Connectivity Server (TCS) and the client application. The audio interfaces provided by the Airbus DS TETRA
system are based on the DXT ET audio interface for CCS integration feature of the Airbus DS TETRA
System. Alternatively, the audio interfaces can be provided via the TVG.
For more information, see Archive Recording Solution Guide (DN0624081).
3.2.11 TETRA terminal authentication key distribution interface

Authentication Key Management Server (AKES) functions as an interface for all incoming authentication data
coming from the network. It authenticates and forwards only data coming from authorised sources.
AKES receives the TETRA authentication data (REF-K-ITSI) from the K- and ITSI delivery points and stores it
into the Airbus DS TETRA System Transit Key Database (TKD).
3.2.12 O&M interface

The Operation and Maintenance (O&M) network is used for controlling one part of the network from
another part, transmitting information, transferring call detail records (CDR) for charging, and for network
time management. For example, in the Airbus DS TETRA System, the interface to NetAct for TETRA
is implemented via an O&M interface.
The O&M interface is implemented by using serial ports or IP connections.
3.3 System internal interface transmission technologies

Airbus DS TETRA System internal interfaces carry voice/data traffic between elements within the network.
They do not include the air interface or the interfaces to external systems such as the Internet, PABXs/PSTN,
conventional base stations, or a foreign network.
Almost every internal interface is based on one of the following transmission technologies:
• NMS interface
• IP
• E1
In addition, Airbus Defence and Space uses proprietary transmission solutions on some interfaces.
3.3.1 NMS interface

The data communication between the NetAct TETRA and the DXT can be implemented either by using OSI
over TCP/IP or OSI over IP.
The OSI over TCP/IP feature offers all the existing OSI services on top of TCP/IP protocols. In this case, all
the OSI data is transferred on top of TCP/IP, so there is no need for a separate OSI-capable router. Note that
the activating of the OSI over TCP/IP feature requires a SW licence.
The OSI over IP network connection is implemented by using an OSI-capable router in the DXT and NetAct
TETRA sites. In this case, the VT, Q3/CMIP and FTAM are layered on top of the OSI CLNS protocol (also
known as ’ISO IP’), which in turn is layered on Ethernet LAN protocols, as shown in Figure 8. The NetAct
TETRA can therefore be connected to a site LAN in the same way as any other network element.
OSI over TCP/IP
MML Alarms
NetAct VT CMIP FTAM
TCP/IP
Ethernet
OSI over IP
MML Alarms
VT CMIP FTAM
ISO IP
Ethernet
- VT is used for MML connections to DXT

DXT - Q3/CMIP is used for alarm collection
- FTAM is is used for alarm upload
Dn0613283x3x0xen
Figure 3 : Protocol stack options for the NetAct-DXT connection
The network management system (NMS) interface between DXT and NetBoss XT for TETRA or DXT and
TETRA Element Monitor (ElMo) is implemented using the TCP/IP protocols. The protocol stacks are
illustrated in Figure 4 .
NMS NetBoss XT for TETRA

MML Alarms
SSH FTP/SFTP
TCP/IP
Ethernet
DXT3 Element Monitor

MML Alarms
SSH
TCP/IP
Ethernet
DXT
- SSH is used for MML connections to DXT

- FTP/SFTP is used for alarm upload
Dn 132498 x1x0xen
Figure 4 : Protocol stacks for NetBoss XT for TETRA and TETRA Element Monitor
3.3.2 IP
From TETRA System Release 6.5 onwards it is possible to use IP transport connections for voice and
signalling between DXT and a wide range of network elements.
There can be both IP and E1 connected network elements in the same network. For the end user the type
of transmission is transparent.
3.3.2.1 DXT interface
The DXTs can have direct IP connectivity to a wide range of network elements, including TB3 base stations,
other DXTs, dispatching applications, Tactilon® Agnet clients, TETRA Voice Gateway, G4WIF Gateway, and
PSTN/PABX over the SIP trunk interface. This is enabled by the following functional units:
• EsGate for voice switching and transcoding
• TETRA Gateway Server (TGS) for managing the EsGate and for signalling with IP-connected network
elements.
• Common Channel Signalling Unit (CCSU), which increases the data transmission capacity (including
MTP signalling links) between DXT exchanges. Notice that CCSU may not be present in some DXT
types.
• TETRA Application Server (TAS) units for providing the Tactilon Agnet server functionality, if the
TETRA Services for Smart Devices are used. Notice that the TAS units are optional and may not be
available for some DXT types, in which case the TGS units can be used instead. For DXT3p the TAS
functionality is not supported.
The functional units are connected to the DXT LAN switches, which in turn are connected to other network
elements, site switches, routers and firewalls with at least 1 GbE connections.
3.3.2.2 TB3 interface
The TB3 base stations equipped with the base station controller TBCi can be configured for IP transmission
between the base station and DXT. The TBCi plug-in unit has two 100/1000 Mb/s Ethernet interfaces for
the TB3 IP connectivity.
Figure 5 : TBCi usage with IP connectivity
When TBCi is used for IP transmission, the FXC (or the older TRUA card) is no longer needed. The signalling
is transmitted using IP protocols (IP/SCTP) between DXT and TB3. The speech is transmitted using RTP
protocol over IP/UDP using predefined UDP ports. The Ethernet is connected into both TBCi cards, if TBC
redundancy is enabled. The active TBCi card handles all the traffic.
3.3.2.3 DWSx interface
IP is one transmission option for connecting the DWSx to the DXT. The IP connectivity for DWSx is supported
by DXT3p.
The DWSx uses the Ethernet interfaces of the workstation for the IP connection. Xgear16 is required for
providing the TETRA voice encoding and decoding functionality in the DWSx.
3.3.2.4 RCS 9500 interface
IP is one transmission option for connecting the RCS 9500 to the DXT. In such a case, the RCS 9500 is
connected directly to the DXT over an IP connection (without TETRA Voice Gateway).
The RCS 9500 uses the Ethernet interfaces of the console for the IP connection. Xgear16 is required for
providing the TETRA voice encoding and decoding functionality in the RCS 9500.
3.3.2.5 SIP trunk interface
With DXTs that are not equipped with Exchange Terminal (ET) units, it is possible to use Session Initiation
Protocol (SIP) trunk interface for connecting PSTN and PABX to the TETRA network. The SIP trunk interface
is based on SIP signaling and speech transport using RTP over IP.
3.3.2.6 TETRA Voice Gateway interface
From TETRA System Release 7.0 onwards TETRA Voice Gateway (TVG) supports direct IP connection
towards DXT. In such a case TVG is used for voice and TCS is used for signalling. For further information,
see Section 3.2.6 .
3.3.2.7 G4WIF Gateway interface
From TETRA System Release 7.0 onwards, DXTs can be connected to conventional systems by using a
G4WIF Gateway (G4WIF GW). The G4WIF GW converts IP-based traffic into E1 and directs the traffic to the
conventional systems, and vice versa.
The TETRA speech connection between DXT and G4WIF Gateway is based on RTP/UDP protocols over IP.
The signalling part between DXT and G4WIF GW is based on SCTP over IP.
The G4WIF GW based solution offers the same functions and services as the FNIM ET based G4WIF solution,
except the feature PSTN/PABX subscriber in a TETRA Talk Group, which is not supported by this solution.
3.3.3 E1
E1 transmission is always used on the following system-internal interfaces:
• DXT–TBS2
• DXTip–DXTip or DXTTip
It is also an alternative on the following interfaces:

• DXT3/DXT3c–TB3
• DXT3/DXT3c–DXT3/DXT3c
• DXT–DWSx/TCS Single-User
• DXT–AKDC Clear mode/Enhanced
• DXT–DWSx
• DXT–TETRA Voice Gateway
• DXT–Third-party client
Optionally, with some limitations, also IP-only-connected DXTs equipped with MGATE can be configured to
have E1 inter-DXT speech line connections.
3.3.3.1 Frame structure
Each E1 interface (also referred to as an E1 line, -highway or -trunk) implements an ITU-T G.703- and
G.704-compliant connection with a 32-timeslot frame structure; 31 of the timeslots are used to carry voice
and/or data. Each timeslot comprises 8 subslots (1 subslot = 1 bit), giving a subslot transmission rate of
8 kbps and a timeslot transmission rate of 64 kbps. The overall bit rate of a single E1 line is 2.048 Mbps.
The way in which the timeslots and the individual subslots within them are used to carry voice/data differs
for different interfaces.
3.3.3.2 Physical implementation
At the physical level, an E1 link between two network elements can be implemented in the following ways:
• By means of a fixed point-to-point cable connection (75 Ω coaxial or 120 Ω twisted pair)
• Via an external E1 transmission system
DXT interface
In the DXT3, the E1 interface is implemented with the ET16 plug-in unit, which is equipped with 16 E1
interfaces. The ET16 plug-in units have both coaxial and symmetrical cabling.
In the DXTip/DXTTip, the plug-in unit type used for the E1 interface is ET4E(-C). The ET4E(-C) is equipped
with four E1 interfaces accessible via front panel connectors.
A RoHS-compliant version of the older type of E1 interface unit (called the ET2E-T(C)B) is also supported.
The ET2E-T(C)B has two E1 interfaces.
The ET4E and ET2E-TB interfaces are 120 Ω balanced (twisted pair) connections; those of the ET4E-C and
ET2E-TCB are 75 Ω unbalanced (coaxial) connections.
TB3 interface
Each E1–connected TBS is equipped with an FXC plug-in unit providing four interfaces to a multidrop E1 line,
enabling implementation of line bypass, loop-through and branching configurations. The FXC is available in
two variants: one for 75 Ω unbalanced and the other 120 Ω balanced.
Note that the TB3p and TB3hp do not have a FXC plug-in unit. They also have only one E1 connection
available. Therefore, when the TB3p/TB3hp is integrated to the TETRA network by using an E1 connection,
they must be connected directly to a DXT or from the last base station in a chain of TB3 base stations.
DWSx interface
E1 is one transmission option for connecting the DWSx to the DXT.

The DWSx is always equipped with an Xgear card, which provides the E1 transmission interface.
Third-party clients
A third-party client application accesses the services of the Airbus DS TETRA system via an API running in a
TETRA Connectivity Server (TCS) or a TCS Single-user.
The TCS is a multi-user server running on a dedicated hardware platform. It implements a true client-server
architecture over IP. The TCS provides only a data interface to its clients. If a TCS Single-User requires an
audio interface too, this can be implemented over E1 as in the DWSx. Another alternative is to use the
ET Audio for CCS Integration feature.
The TCS Single-user is a server software product which can serve one client at a time and which is installed
on the same PC as the client application itself. It can be interfaced to a DXT over E1 in the same way
as a DWSx.
TETRA Voice Gateway interface
E1 is one transmission option for connecting TETRA Voice Gateway to the DXT.
The TETRA Voice Gateway is equipped with two Xgear16 cards, which provide the E1 transmission interface.
For information on this interface see Chapter 5.10 .
Other E1 interfaces (AKDC)
For information on the AKDC, see Chapter 5.12 .
3.3.3.3 E1 synchronisation
In order to ensure error-free E1 transmission and switching across the whole Airbus DS TETRA System
network, all E1 lines and interfaces must operate in a synchronous manner. This is achieved by synchronising
the clocks of individual elements to a master reference frequency in hierarchical order; this is known as
master-slave synchronisation. The master reference frequency is generated by a high-stability clock (or
clocks) called the master clock(s). The synchronisation signals are carried by the E1 lines and extracted
at the receiving end. The synchronisation scheme is drawn up at the network planning stage, and must
include any external system connected to the TETRA network. Typically, the external system will supply
the synchronisation reference, ie. the external system is the master and the TETRA system the slave.
This scheme defines the structure of the synchronisation hierarchy and takes into account ITU-T stability
requirements and transmission time delays introduced by the E1 circuits.
The DXT clock system can be used in a master-slave network hierarchy. It can also operate plesiochronously
in the event of loss of synchronisation information.
Under normal network conditions, synchronisation information is carried by selected E1 lines from upper to
lower hierarchical levels in accordance with the synchronisation scheme. The clock system selects as the
active synchronisation signal the highest-priority signal acceptable from a group of preselected digital paths.
The clock system is duplicated. If the E1 circuit, synchronisation signal or synchronisation unit fails,
controlled changeover to the backup system occurs seamlessly and automatically without disturbance to
traffic or signal quality.
The functions of the E1 interface unit in the DXT relating to synchronisation are frame alignment, jitter and
wander compensation and slip control together with associated frame buffering. The frame alignment and
cyclic redundancy check procedures are in accordance with ITU-T Recommendation Q.511.
The E1 interface unit is provided with a two-frame buffer, which is used both for jitter and wander
compensation in accordance with ITU-T Recommendation Q.554 and for controlled frame slip operation.
Frame slip is controlled by removing or repeating one complete frame when required. This does not cause
a loss of frame alignment. The frame slip control mechanism facilitates trouble-free interworking with
asynchronous nodes when required.
Distribution of the master reference
There are three ways in which the reference frequency can be distributed to the network:
• Via the E1 lines. The DXT allows up to four inputs.
• The DXT provides the master clock. It can provide a synchronisation signal for other equipment
according to ITU-T G.703, Section 10.
• From an external source via the DXT clock unit. The DXT allows up to two inputs.
A DXT can have several inputs in addition to its master clock. The operator can define a priority order for the
DXT clock and the other inputs. The DXT then selects the highest-priority signal that is acceptable as the
master synchronisation link. This means that the other inputs can take over in the event of a failure on the
main link. If there is a failure in the external source, the DXT master clock can be used.
The selection and order of the reference signals is configurable. The changeover functions are carefully
controlled and they cause no disturbance to traffic or signal quality.
4 TETRA features
The Airbus DS TETRA System provides a number of communication and security features for user
organisations and radio users.
This chapter introduces the communication and the security features as seen by the end users and
dispatchers. A more comprehensive introduction can be found in document Introduction to Features
(DN00126484).
The Airbus DS TETRA System provides an easy-to-use, secure and reliable communication environment for
radio users:
• Before allowing any communication, authentication can be required from the radio users and
dispatchers.
• Only authorised users and dispatchers can participate in group communication.
• Air interface encryption and end-to-end encryption enhance the confidentiality of communication.
• Users can select groups using descriptive names, there is no need to know the group numbers and
channel frequencies used.
• During an individual call, a radio user can move to another base station while retaining the ongoing call.
This is also true in the case of a group call, provided that the user stays within the group area.
• Users are informed for example of new, important group calls even if they are currently engaged in
another call or are using the packet data service.
Note
Depending on differences in radio terminal models and their configuration, your radio terminal may function
differently from the radio terminals described in this chapter.
4.1 Voice communication
4.1.1 Group communication

Group communication is a key service in a PMR system. In group communication, a large number of users
may be involved in communication at the same time.
In the Airbus DS TETRA System, a group may include permanent and visiting radio users, dispatchers, PSTN
and PABX users, Tactilon® Agnet client users, and other radio systems such as conventional PMR systems.
A single group can include several dispatchers. A group can also operate without dispatchers. The group
members, radio users, Tactilon Agnet client users, and dispatchers can belong to several organisations,
which enables flexible co-operation between user organisations. Furthermore, a dispatcher can combine
several groups to share communication.
4.1.1.1 Resource allocation
In the Airbus DS TETRA System, group communication makes use of pseudo open channel communication.
In traditional open channel communication, a channel is permanently reserved for the exclusive use of a
closed user group. With pseudo open channels, channel resources are allocated dynamically at the call
set-up phase (when a user requests a speech item by pressing the PTT button), and the calling party is
informed about current resource availability.
A group call can be either a shifting area group call or a fixed area group call:
• A shifting area group call conserves system resources because only the location areas (base stations)
in which there are group members present are involved in the call.
• A fixed area group call reserves a speech channel in every location area (base station) belonging to
the group area, regardless of whether there are any group members in that area or not when the
call is set up.
4.1.1.2 Dispatcher's view of group communication
Dispatchers experience group communicationin a similar way to traditional open channel communication.
They can listen to and participate in the communication of one or more groups at the same time. However,
the dispatchers must have communication rights for these groups. The Airbus DS TETRA System prevents
unauthorised users from listening to and participating in group communication.
In addition to traditional open channel communication, dispatchers can
• Receive information on the status and location of radio users.
• Act efficiently in special circumstances. For example, dispatchers can create new groups and define
who are the group members. The members can be multiple organisations which normally operate
separately. The dispatchers can also combine several groups into a temporary co-operation group to
handle unexpected situations.
• Add new members to existing groups or remove members from existing groups; the system can
immediately download the changes to the radio terminals.
• Quickly send an individual single speech item to several groups simultaneously.
• Change between group call- and semi-conference call modes.
The dispatcher's main interface to the system is a dispatcher workstation with audio facilities and a graphical
user interface. Figure 6 illustrates a DWS C/C&M group communication dialog.
Figure 6 : Group communication dialog
4.1.1.3 Radio user's view of group communication
Radio users experience group communication in a similar way to traditional open channel communication.
A radio user speaks in an active group by pressing the PTT button. The system ensures that only one
radio user can speak at a time. Pseudo open channels are used in group communication. Compared to
open channel communication, it is possible to define the members in group communication flexibly and
dynamically. Moreover, the Airbus DS TETRA System can control group memberships by allowing only
authorised radio users to participate in group communication.
Figure 7 illustrates the display of a radio unit which shows the name of the group and the party currently
speaking.
Figure 7 : Radio unit display
A radio user can be a member of several groups. From these groups the user may select one active
group, called the selected group, and/or a list of groups to be placed under scanning. The groups under
scanning can be allocated different scanning priorities by the radio user to ensure that the group with the
highest priority will be heard.
The group area determines the extent of availability of the service. The system tells the radio users whether
or communication in a group is possible, that is, whether or not they are within the group area. Emergency
situations are exceptions. An emergency group call can be made over the whole network area, the group
area does not limit service availability.
4.1.1.4 Tactilon Agnet client user’s view of group communication
Note
TETRA Services for Smart Devices is supported from TETRA System Release 7.0 onwards.
Tactilon Agnet client users experience group communication in a similar way as the TETRA1 radio
susbscribers RSs). A Agnet client user speaks in an active group by touching the PTT button and and holding
it down. The system ensures that only one member of the group can speak at a time. Before the Agnet client
user can participate in a call, it must register to the TETRA System and attach to the number of a TETRA
group. Only registered and authenticated Agnet client users can attach to a TETRA group.
The TETRA groups can consist of any combination of TETRA1 RSs, dispatcher workstations (DWS), and
Agnet client users. It is also possible to have a group consisting of TETRA1 radio subscribers, DWSs, Agnet
client users, and G4WIF-connected clients (that is, external systems such as PSTN and PABX). The Agnet
client users have the same communication rights as TETRA1 RSs and they are also handled in a similar
way in the dispatching communication and management applications.
If a new group call is being set up to a Tactilon Agnet client that is currently involved in a group call, the DXT
either places the Agnet client user’s call setup in a queue and sets up the call without the Agnet client user or
it pre-empts the ongoing call based on the Agnet client user’s call or group scanning priorities.
4.1.1.5 Speech item management
Radio users or Tactilon Agnet client user can request and, if necessary, queue for the speech item in a group
call. The system maintains a speech-item request queue for each group call and grants the speech items
according to the priority of speech item requests and the order in which they were placed in the queue.
4.1.1.6 Management of groups and group memberships
In the Airbus DS TETRA System, Tactilon® Management, dispatcher workstation (DWS) or third party
applications are used to manage the areas and attributes of groups. The same applications can also be
used for managing group memberships.
The Airbus DS TETRA System supports dynamic changes in group memberships. Authorised dispatchers
can add radio subscribers to a group, remove them or move them from one group to another. Changes are
automatically downloaded over the radio path to radio terminals. A workstation user may also include an
external radio system connected to the Airbus DS TETRA system in group communication.
Radio and Agnet client subscribers can also join a group by selecting it from the group phone book and
adding it to the list of selectable groups. However, the radio subscriber must have access rights for this
group. Unauthorised subscribers are prevented from joining groups and listening to group communication.
The groups the radio subscriber may join can be pre-programmed into the radio terminals or downloaded
over the radio path. Tactilon Agnet client users are always permanent members in a group.
4.1.1.7 Broadcast groups and background groups
Broadcast groups and background groups are primarily created for the purpose of making announcement-type
calls (rather than normal group communication). Announcement-type calls are basically one-way in
nature: the calling party presses PTT and talks and the called parties (that is, the members of the
broadcast/background group) listen.
When a call is made to a group whose mode is defined as broadcast / background, that call will automatically
be set up as a broadcast / background call.
All dispatchers have the right to make calls to broadcast- and background groups. In the case of radio
subscribers, the right to call these groups is subscriber-specific and is defined as a list of organisation blocks
(that is, the radio subscriber can only call a broadcast/background group if it belongs to an organisation
block on the list).
In a broadcast-group call, none of the members of the group (whether dispatcher, radio-subscriber-, Agnet
subscriber or G4WIF) can reply to the call (that is, they are prevented from obtaining the speech-item for
the whole duration of the call). This ensures that the calling party can transmit the announcement in
its entirety without interruption.
In a background-group call, any of the members of the group can reply to the call.
The other main differences between broadcast- and background groups are:
• There is no group download to radio terminals for background groups (there is for broadcast groups);
background group membership must therefore be pre-programmed into the terminals.
• The area type is always fixed for background groups; it can be set to fixed or shifting for broadcast
groups.
• The priority scanning level is Always scanned for background groups; for broadcast groups other
scanning levels (including no scanning) are also possible.
4.1.1.8 Cover groups
A cover group is a group which a radio subscriber can use to start a location-based group call. A
location-based group call is one which is set up only in the local group geographically nearest to the calling
terminal. This local group is selected by the system from a set of local groups pre-defined for the cover
group concerned.
The radio subscriber sees only the cover group, not the local groups behind it. From the radio subscriber's
perspective a cover group is like any other normal talk group. The only difference is that a cover-group call
is always set up locally, and only those members of the cover group that are within the local-group area
at the time can listen to or participate in the call.
Cover groups can be created and defined by authorised DWS Management (or third-party application) users.
Dispatcher's role in cover-group communication
It is not possible for a dispatcher to participate in or listen to calls in a cover group. Dispatchers can use only
local groups for communication (the dispatcher sees the local-group structure behind a cover group).
An authorised dispatcher is able to monitor a cover group for indication of call startup in any of its local
groups. The dispatcher can then select that local group for eg. audio monitoring. A dispatcher can also make
a call to a local group of a cover group (see the second use case below).
Use case: Metro system
All terminal-carrying metro staff, including those on the trains and those located at stations, are members of
the cover group and always use it for their group communication. If eg. a train driver starts a group call in the
cover group while his train is at or near a station, the call will be set up locally and only those subscribers
located within that station area will be able to listen or participate. At the same time, other subscribers can
use the same cover group to initiate local group calls at other locations across the metro system.
Use case: Site-wide calls (announcements)
A cover group can be used by radio subscribers to listen for site-wide calls (announcements). A site-wide call
is a call from an authorised dispatcher directly to a local group belonging to the cover group. The selected
local group determines the call target area (ie. site). Only the cover-group members located within the
target area will be able to hear the dispatcher's announcement. In the metro example above, a typical
site would be a station.
If different sections of eg. metro personnel belong to different cover groups, a dispatcher can combine
the cover groups' respective local groups at a particular station, say, in order to make an announcement
to all personnel at that station.
4.1.2 Individual communication
Individual calls enable private one-to-one conversations between:
• two radio subscribers or Tactilon Agnet client users
• a dispatcher and a radio subscriber or Tactilon Agnet client users
or:
• two dispatchers.
In addition, individual calls can be made between a user in the TETRA System and a PABX or PSTN
subscriber. It is also possible to make individual calls between radio subscribers or dispatchers in the Airbus
DS TETRA network and predefined other TETRA networks connected over the Inter-System Interface (ISI).
Subscriber-specific individual call rights can be defined for radio subscribers, Tactilon Agnet client users
and dispatchers. This is done separately for different types of individual calls within the network and
for PSTN/PABX calls.
In the Airbus DS TETRA System, the dispatcher can transfer an incoming individual call to another target
and, if needed, authorise the call. The dispatcher can also force an individual call release if it is imperative
that a radio user participating in an ongoing individual call is reached as soon as possible.
The Airbus DS TETRA System also supports the forwarding of the radio subscriber’s call to an MSISDN
number, which enables forwarding of a call to the called party's voice mail, for example. Call forwarding can
be set to occur always, when the called party does not reply, when the called party is busy (radio subscriber
only) or when the called party is not reachable.
Individual calls are typically telephony-style calls: the call must be answered and terminated by the
participants. The Airbus DS TETRA System also supports calls which are connected without any physical
action from the called subscriber (known as direct or express calls).
The Airbus DS TETRA System also supports offering of an individual call to a radio subscriber already
engaged in an individual call.
Telephony-style calls may be semi-duplex or duplex. Direct calls are always semi-duplex.
4.1.2.1 Duplex call
The Airbus DS TETRA System supports simultaneous two-way transmission (duplex) in individual calls
between TETRA radio subscribers / Tactilon Agnet client users and between TETRA radio subscribers /
Tactilon Agnet client users and a PABX/PSTN subscriber. Duplex calls are possible if the radio terminals
support the feature and if the subscriber has the right to make duplex calls.
4.1.2.2 Semi-duplex call
A semi-duplex call allows only one party to talk at a time. The request for a speech-item (request to talk) is
made by pressing the PTT button.
The Airbus DS TETRA System also supports calls in which one party is in semi-duplex mode and the other
party in duplex mode. This makes it possible for a TETRA subscriber who is not allowed to use duplex
communication to make/receive calls to/from the PSTN/PABX.
4.1.2.3 Direct call
The direct call is an Airbus DS TETRA System function which enables immediate speech communication
from one radio subscriber to another or from a dispatcher to a radio subscriber.
When radio users make a direct call, the calling party dials or selects a number in the radio unit, presses the
PTT button and starts to speak. If the called party has activated the loudspeaker, he/she will hear the speech
immediately, without any ringing tone or answer-keying. If the called party has not activated the loudspeaker,
the call changes to a normal hook on/off call. The system will automatically disconnect a direct call after a
selectable period of inactivity. The user can also disconnect the call by pressing the hook-on/off button.
4.1.2.4 Dispatcher call
The dispatcher call is one of the advanced features of the Airbus DS TETRA System. A dispatcher call is
an individual-call request made to a group number. The system forwards the individual-call request to all
dispatchers of the called group. When one of them answers, the call request is automatically withdrawn
from the other dispatchers and the call proceeds as an individual call between the calling party and the
answering dispatcher.
The Airbus DS TETRA System also supports location-based routing of dispatcher calls. If several groups
are on the same mission but located in different geographical areas, they can be joined using the group
overlay feature. When a radio user initiates a dispatcher call to a group overlay number, the call is forwarded
only to the dispatchers of the group in whose area the radio user is currently located. In a group overlay
situation, a radio user will thus always be connected through to the nearest dispatcher, irrespective of the
radio user's location.
4.1.2.5 Calling line identification presentation and restriction
With the Calling Line Identification Presentation (CLIP) feature, the phone number of the calling party is
shown to the called party. The calling party number is transmitted to the called party in individual calls inside
the Airbus DS TETRA System and between the Airbus DS TETRA System and the PSTN network.
An authorised dispatcher in the Airbus DS TETRA System can activate the Calling Line Identification
Restriction (CLIR) for a radio subscriber or another dispatcher, after which the number of the calling party will
not be shown to the called party. The Airbus DS TETRA System also supports CLIR override for authorised
dispatchers, which enables showing the calling party identification even if the calling party has CLIR turned on.
4.1.2.6 Offering an individual call to a subscriber already engaged in an individual call
This feature enables the Airbus DS TETRA System to offer an individual call to a radio subscriber who is
already engaged in another individual call.
Depending on the called terminal's configuration, the offered call can be accepted, rejected or ignored by the
called subscriber. If the called subscriber accepts the call, the existing individual call is terminated.
In addition to its primary function, this feature also allows the calling party to apply his/her pre-emptive priority
(if defined) in order to force acceptance of the offered call. For this to work, the called terminal must be
configured to accept the offered call unconditionally on the basis of the caller's pre-emptive priority.
Offering of an individual call can be allowed/disallowed by making the appropriate organisation-level
definitions for the calling and called subscribers. To allow call offering, the Call Offer functionality must be
enabled for the calling subscriber's organisation and the Call Wait functionality for the called subscriber's
organisation.
This feature requires support from the radio terminals.
4.1.3 Emergency communication
Emergency calls can be made by radio subscribers, Tactilon® Agnet client users, and dispatchers.
4.1.3.1 Radio-subscriber-initiated or Tactilon-Agnet-client-user-initiated emergency

calls
Radio subscribers usually start an emergency call by pressing the red emergency (EMRG) button on their
radio terminal. A pre-programmed radio terminal parameter named Emergency address determines how
the call is normally routed and handled in the network infrastructure.
Tactilon Agnet client users can make an emergency call by swiping the Android phone’s Main view the
Emergency button to the right and touching it. If the Tactilon Agnet client user has not yet enetered the
TETRA access code or the TETRA security code successfully before an emergency call must be initiated, the
emergency call function offered by the Android system must be used instead.
Emergency communication tailored to the needs of the user organisation
Emergency communication requirements may differ considerably from one organisation to another. The
Airbus DS TETRA System recognises this and provides you with the tools to configure quickly and easily
exactly the emergency-call scheme you need for your organisation and subscribers.
A radio terminal can be programmed to transmit an emergency call either directly to a specific target or to
a logical destination in the infrastructure called the Emergency target. In the latter case, the incoming call
is routed onwards to a final destination defined on a calling-subscriber-specific basis with the dispatching
management application (such as Tactilon® Management or DWS M). Use of the emergency target thus
provides a means of defining and changing emergency-call routing without having to change the radio
terminal’s settings.
Tactilon® Management and DWS M offer the following alternatives as a final destination for the
subscriber-specific or Agnet-client-specific emergency target:
• A user-definable TETRA network SSI (group, group overlay, selected group ident or individual
subscriber)
A call to a group overlay SSI is a location-based call. The call is set up in the local group (automatically
selected from the groups defined in the group overlay) geographically nearest to the calling terminal.
The selected group ident is a logical address which routes the call to the group currently selected by
the calling radio subscriber or Agnet client user.
• A user-definable external-network address
In this case the dispatcher or workstation user must define the gateway SSI to the external network as
well as the external number itself. For example, if the target is a subscriber in the PSTN, you must
specify the PSTN GW SSI for your network and the target's PSTN number.
If neither of the above primary-target alternatives is selected, or if call set-up to the primary target fails for
any reason, call routing defaults to the emergency address defined (with the dispatching management
application) for the calling subscriber's organisation as a whole. The dispatching management application
offers the following alternatives for the organisation-specific emergency target:
• A user-definable TETRA network SSI (group, group overlay, selected group ident or individual
subscriber)
• A user-definable external network- or MSISDN number
Default values for these target alternatives can be defined with MMLs.
It is also possible to configure the system to route an emergency call from a radio subscriber or a Agnet client
user to a cell-specific PSTN number (based on the calling radio terminal's location), for example the number
of the nearest police unit. The system provides 10 network-specific logical emergency numbers for this
purpose. These numbers are available for use by all radio subscribers, Agnet client users, and dispatchers in
the network. If call set-up from a radio terminal to one of these numbers fails, call routing defaults to the
subscriber-specific or Agnet-client-specific emergency target described above.
Effective handling of emergency situations
The dispatcher workstations bring emergency situations to the attention of the dispatcher immediately, thus
enabling a quick and effective response:
• Dispatchers can see which subscribers or Agnet client users are in an emergency situation.
• Dispatchers are able to manage situations involving several simultaneous emergency calls.
• Dispatchers can quickly combine up to eight groups from one or more organisations into a larger,
temporary group for the purpose of handling an unexpected incident.
4.1.3.2 Dispatcher-initiated emergency call
Basically, a dispatcher in the Airbus DS TETRA System can make an emergency call to any group- or
individual address for which he/she has organisation-block-based communication rights.
Making an emergency call with DWS or RCS 9500 is similar to making a normal call, except that the
dispatcher must first activate the emergency mode in the target-group/subscriber dialog.
Typically, a dispatcher would make an emergency call in the following circumstances:
• The dispatcher himself is in an emergency situation.
• The dispatcher is aware that another subscriber is in an emergency situation but unable to make
an emergency call herself.
• The dispatcher needs the pre-emptive rights conferred by an emergency call to make sure a call to a
target group will go through, whatever the traffic conditions.
There are some restrictions on DWS-initiated emergency calls:
• The emergency ident is not supported (this means the DWS, unlike a radio terminal, cannot send an
emergency call to the logical destination emergency target described in Section 4.1.3.1 ).
• Emergency calls from a dispatcher to a group overlay are not supported.
It is also possible to configure the system to route an emergency call from a dispatcher to a DXT-specific
(DWS-location-based) PSTN number, for example number of the nearest police unit. The system provides
10 network-specific emergency numbers for this purpose. These numbers are available for use by all radio
subscribers and dispatchers in the network.
4.1.3.3 Emergency call priority
Emergency calls have pre-emptive priority over normal calls. If there are no free channels, the system will
release resources from calls of lower priority. This ensures resource availability for emergency calls even
during periods of heavy traffic on the radio network.
4.2 Data communication

Data communication is an integral part of the communication facilities in the Airbus DS TETRA System
enabling efficient messaging. The Airbus DS TETRA System supports the following data services:
• Status messages
• Short data service (SDS) messages
• IP packet data (PD)
The Airbus DS TETRA System allows data messages to be sent and received even while a subscriber is
engaged in a voice call, provided the radio terminal supports this functionality.
For more information on data message services, refer to documents Data Message Services (DN00126503)
and IP Packet Data Service (TRASYSAPP00288).
4.2.1 Status messages

Status messages are numerical messages whose values are assigned specific meanings (for example At
station, On the way, At scene etc.) and which radio users and dispatchers can send and receive. Status
messages provide a fast, easy way of tracking a radio subscriber's situation with minimal loading of the radio
path. User organisations can define the meaning of several status messages themselves.
The Airbus DS TETRA System has an advanced internal status application that provides users with the
following status messages:
• Callback requests
• Emergency status messages
• Urgent requests
• Status indicators
• Group scanning on/off indications
The recipient of a status message can be either a group or an individual subscriber. If necessary, the right to
send and receive status messages can be restricted for each individual radio user and dispatcher.
4.2.2 Short data service

Short Data Service (SDS) messages can be sent from a radio terminal, dispatcher workstation or separate
data terminal to individual users or groups.
The Airbus DS TETRA System supports the following SDS message types:
• SDS1: 16 bits of user data, all values are free for application designers.
• SDS-4 messages carry user data of variable length. All messages carry a protocol identifier identifying
the application. Some of the protocols are defined in the TETRA standard and several protocols are
available for end-user applications.
• Concatenated SDS messages, which enable sending of text messages exceeding the standard length.
The DWS supports the receiving of concatenated SDS messages.
• SDS TL: messages of variable length. The format of user data is defined in the SDS TL specification.
The Airbus DS TETRA System supports all SDS-TL protocols. The Airbus DS TETRA terminals
support SDS-TL services for text messaging, AVL and WAP. The DWS Communication application
supports the text messaging service.
SDS messages can be used in various applications, such as Global Positioning System (GPS) data transfer
and Automatic Vehicle Location (AVL). It is possible to configure a separate AVL server to which all GPS,
simple GPS and LIP AVL messages are sent.
The TCS provides an API through which external applications are able to access the data message services
of the Airbus DS TETRA System. Typical applications are the collection of measurement data from data
terminals connected to radio terminals (telemetry) and connecting between TETRA and GSM short-message
services. An external SMS centre can also be used to store and forward SMS messages from cellular
networks to TETRA users, and vice versa.
SDS-4 priority profiles
This feature provides the following five priority profiles for sending SDS-4 messages:
• Normal
Default profile. Used for data messages with no special requirement regarding service level eg. text
messages between TETRA users.
• Important
Used in situations where the SDS delivery time to the recipient is critical and/or when the delivery is
ensured by several repeats.
• Paging
For high-priority paging messages.
• Repeating
For non-time-critical messages containing eg. location information.
• Dedicated
For data messages sent using a dedicated data channel.
The profiles which a particular client application is allowed to use are defined by an authorised WS user.
When a client application sends an SDS-4 message the message profile used is selected either by the
sending client itself or by using the SDS-4 protocol ID, which has a speciific profile defined. When a radio
terminal (application) sends a message, the sending profile is always based on the SDS-4 protocol ID.
When properly used, SDS-4 priority profiles enable reliable delivery and optimal use of network capacity. For
example, low-priority messages can be set up so as not to be sent when the air interface is heavily loaded
whereas high-priority messages can be set up so as to always pass lower priority messages in the queue.
4.2.3 IP packet data

Packet data transfer is useful for transmitting data in bursts or in bulk, where constant bandwidth is not
required. In the Airbus DS TETRA System, typical uses for the IP packet data service include
• Querying external databases (a vehicle register, for example)
• Monitoring and alarms (gas, water, air quality, train, and so on)
• Remote control
• Information broadcast
• Event creation and updates (status reports)
• High speed applications (with TEDS)
The packet data service offers IP datagram delivery and connectivity between a field PC connected to a
TETRA radio terminal and a host in a local area network (LAN). The packet data context is activated by the
radio terminal. The user can make and receive important calls while engaged in packet data service. The
packet data sending is suspended and may continue after the voice call has been terminated.
Users see an Airbus DS TETRA System equipped with IP packet data as an IP subnet that can be connected
to other IP subnets, for example, a corporate intranet or the Internet. Users can access subnets with their field
PCs or WAP/Java-enabled terminals and run the same TCP/IP applications they use on ordinary desktop PCs.
The Airbus DS TETRA System IP Packet Data Service is available in two versions: basic IP packet data
provides IP connections to any IP-connected data network and the enhanced version increases the scalability
and security of the IP Packet Data Service.
4.2.3.1 High-speed packet data service (TEDS)
The much faster data rates offered by TEDS make it possible to use a wider range of eg. web-based
applications such as video streaming and faster image transfer. The need for such applications is
demonstrated by the following examples:
• Vehicles can become mobile offices, able to handle functions such as reporting and command and
control.
• Medical measurement data and images can be sent from an ambulance to the hospital.
• Surveillance images can be activated by motion detectors and sent to command units.
4.3 Aliasing
Many of the radio terminals used in TETRA networks are carried and used by only one person, and the
terminal identity (ITSI) is associated with that person. This can be a problem in a situation where, for
example, you urgently need to contact the security guard currently on duty but don't know who it is. What you
really need is a single number for 'security guard' that will always put you through to the person currently in
that role. A common way of achieving this is to dedicate a radio terminal to the role concerned, in this case
'security guard', and pass the terminal from one person to the next as the duty shift changes.The drawback to
this is that it generally requires extra terminals, since person-specific terminals are often still needed. It may
also mean that the terminal user must juggle between two terminals for person- and role-specific calls. The
aliasing feature of the Airbus DS TETRA System offers a solution to this problem.
What is aliasing and how does it work?
An alias is a subscriber identity (ITSI) which can be used for a radio terminal registered in the network in
addition to the terminal's own ITSI. Voice calls and messages to the terminal can then be addressed to either
the alias or the terminal ITSI. A terminal can have a maximum of two aliases at the same time. With two
aliases assigned, a terminal can be reached on three different numbers.
An individual alias can only be assigned to one terminal at a time.
When a radio terminal originates a call, it is identified in the system as the calling- or talking party by its active
identity. For a terminal with no aliases, the active identity is the terminal identity. When a terminal has one or
two aliases assigned to it, the last-assigned alias is always the active identity.
Aliases are typically used to identify a specific role or task which is performed by different people at different
times (each person carrying his own radio terminal). When coming on-shift in that role or task, the terminal
user sends a request to the system for the required alias and, assuming that alias is not already in use by
another terminal, the system assigns it to the requesting terminal. When going off-shift, the terminal user
signals the system that it is relinquishing use of the alias, which then becomes available again for use
by other terminals.
An alias can also be used to provide a terminal with a personal identity eg. when using a communal radio
terminal. In this case, a person-specific alias would be assigned to a non-person-specific terminal.
When a terminal user sends a request for an alias, he/she may be asked to enter a PIN as verification
of the right to use that alias.
Terminal-user-initiated assignment/removal of an alias as described above requires support from the terminal.
In the case of terminals without this support, alias-assignment/removal can be done on behalf of the terminal
by an authorised dispatcher. This is possible because the alias-related definitions are all stored in the
system infrastructure, not in the terminal.
Alias identities are created and managed in the system using the DWS M (or equivalent third-party
application) in much the same way as normal radio-subscribers are. Alias identities are classed as a type
of radio subscriber by the system. They belong to an organisation block and have their own profiles and
MSISDN number allocations.
An alias identity can only be assigned to a terminal belonging to the same main organisation block.
Note
Alias identities cannot be assigned to groups or dispatcher workstations.
4.4 Priorities
The purpose of priorities is to ensure that important calls are always established, prioritise access to system
resources for certain subscribers/groups and to enable users to give their groups different priorities according
to their specific needs.
Priorities can be grouped into three areas:
• Priorities affecting resource reservation and allocation.
• Priorities affecting speech item allocation.
• Priorities affecting scanning.
4.4.1 System priorities

The Airbus DS TETRA System controls the use of system resources and speech item management and
allows allocation of different priorities to users for these purposes. A normal priority level in the range 1–20
(where 20 represents the highest priority) can be defined individually for each radio subscriber, dispatcher
and group. Dispatchers with administrative rights can set and change the normal priority level for subscribers,
groups or WS users using the DWS management application.
The normal priorities of subscribers and groups determine the queuing order for channel resources. The
priority value assigned to each subscriber determines the priority of individual calls made and received by that
subscriber (the higher of the calling- and called-party priorities is the one used for an individual call) and on
requests by that subscriber for the packet data service. The priority level of a group affects the priority of
calls in that group in relation to calls made in other groups. Requests for individual calls, group calls and
packet data all queue for the same channel resources.
Emergency calls, ambience listening calls and pre-emptive priority calls are all able to force the system to
release resources for their use if there are none available. In this case, resources are taken from other calls
in progress, beginning with the lowest-priority voice- or packet data call.
Note
Speech-item allocation to a participant in a group call is governed by a separate priority system from that
governing resource allocation. Individual radio subscribers and WS users can be assigned a speech-item
priority level in the range 1–20 with the DWS management application. This priority level determines who
gets the next speech item in a group call when several participants have requested it.
4.4.2 Organisation and service priorities

End-user organisations have different needs based on their operating environment and importance relative to
the other user organisations in the network. With organisation-specific service priorities, different priority
levels can be assigned to different call- and data services within each organisation. For example: in one
organisation the group call service might be given a higher priority than the packet data service, while in
another it might be the other way round. Each service can be allocated a priority level in the range 1–12
(where 12 represents the highest priority), defined at the main organisation level.
A priority level can be allocated for the following services:
• Group call
• Broadcast call
• Telephone-style call
• Direct call
• External-network call
• Packet data
• Individual emergency call (without pre-emption)
The priority level of a given service within a given organisation can be defined completely independently of the
priority levels for other services in the same organisation or the same/other services in other organisations.
However, by managing services and organisations together, it is possible to create a priority scheme based
purely on organisation or purely on service as follows:
• By allocating the same priority level to all services within the same organisation, but using a different
level for different organisations, you can prioritise service access on the basis of organisation only.
For example: organisation A would always have priority over organisation B, whichever services they
request, provided the service priority level defined for A's services is higher than that defined for B's.
• By allocating the same priority level to the same service across all organisations, but using a different
level for different services, you can prioritise service access on the basis of service only. For example:
any network subscriber requesting a group call would always have priority over a network subscriber
requesting an external-network call, regardless of which organisations they belong to, provided the
priority level defined for the group call service is higher than that defined for the external-network
call service.
Note
Organisation/service priority levels always take precedence over priority levels defined for individual radio
subscribers, groups and dispatchers.
4.4.3 Scanning priorities
Scanning priorities are used with the priority scanning feature. This feature must be supported by both the
radio terminals and the system. For radio users, priority scanning means that they can set different priorities
for the groups they are scanning. The Airbus DS TETRA System sends information on ongoing group calls to
the radio terminal, enabling the terminal to select the call with the highest scanning priority. This ensures
that a radio user automatically receives the voice traffic of higher-priority groups even if it is engaged in
group communication with a group of lower priority.
Scanning priorities are terminal-specific and are controlled by the terminal user, provided the radio terminal
has been granted the right for this. This allows individual terminal-users to set their own group-scanning
priorities.
4.4.4 Pre-emptive priority
In some situations it is necessary to guarantee priority access for certain users of the system. The network
operator can grant each customer organisation the right to use pre-emptive priority in such situations.
Pre-emptive priority ensures that authorised subscribers can always obtain resources for important calls when
the network is congested and that they are able to seize the speech item from the current speaker in a group
call (the pre-emptive speech item request requires a radio terminal which supports this function).
Pre-emptive priority is described briefly in this subsection. For further information, refer to documents
Introduction to Features (DN00126484) and Voice Communication (DN00126496).
Pre-emption of resources
A pre-emptive call set-up or packet data request is given priority over other requests on the air interface and
in inter-exchange speech line reservation. The needed resources are released from the current lowest priority
call or packet data service. However, emergency calls and ambience listening calls still have a higher priority
than pre-emptive requests and are not released with pre-emptive requests.
The right for pre-emption can be given to a radio subscriber, dispatcher or group.
Pre-emption of a speech item
A pre-emptive speech item makes it possible for the user to interrupt the current speaker in a semi-duplex
individual or group call.
The right to use pre-emption for a speech item can be granted separately for each individual radio subscriber
and dispatcher. Emergency speech items and pre-emptive dispatcher speech items have a higher priority
than radio-user pre-emptive speech items.
Pre-emptive-priority levels
A pre-emption priority level in the range 1–20 can be defined separately for each radio subscriber, group and
WS user which has been granted pre-emptive priority. Level 20 confers the highest priority. A pre-emptive
priority will always be able to pre-empt a normal priority, whatever their respective levels, and a higher
pre-emptive priority level will always be able pre-empt a lower one.
4.5 Security
4.5.1 Authentication
Radio unit authentication
The radio-unit authentication function enables the infrastructure to check that a radio unit is authorised to
operate in the system. It is also possible for the radio unit to make the authentication mutual in order to
check the validity of the base station. Authentication is carried out at registration then repeated at intervals,
depending on the operator's security policy.
The Airbus DS TETRA System supports the authentication procedure and provides the operator with the
tools for authentication-key management. The authentication procedure conforms to the SwMI authenticates
MS during registration according to ETSI EN 300 392-7 v2.1.1.
TETRA authentication is based on a secret authentication key that is specific to the radio unit and known only
to the radio unit and the SwMI. During an authentication exchange the SwMI challenges the radio unit to
demonstrate that it holds the correct authentication key without actually revealing the key itself. If the radio
unit's response is correct, the system allows the radio unit to register and operate in the system.
In its authentication response, the radio unit may also challenge the SwMI, thus making the authentication
mutual.
Mutual authentication
In mutual authentication the radio unit is able to authenticate the Switching and Management Infrastructure
(SwMI). This is used in terminal enable/disable, for example, when the radio unit will require authentication
from the SwMI before acknowledging the enable/disable command.
Note
The radio unit must support mutual-authentication signalling. According to the TETRA standard, at least
those radio units which support enable/disable commands over the air should support mutual authentication
signalling in a network using Class 3 encryption.
Workstation user authentication
During authentication, the DWS sends only the workstation username to a DXT database, where the
respective user name and password have been stored in encrypted format. The information is then
authenticated in both directions using random numbers and authentication keys.
Authentication to the network is implemented according to the standard ISO 11770-2 Key management -
Part 2: Mechanisms using symmetric techniques.
For further information on authentication, see the document Authentication in the TETRA System,
TRASYSAPP00003.
Workstation access control
The Airbus DS TETRA System provides an optional Smart Card concept for Windows workstation user
authentication. The Smart Card concept makes it possible to identify the DWS users in a reliable and secure
way before they even log on to the Airbus DS TETRA System.
When the Smart Card is used, breaking into the Windows workstation is significantly more difficult. User
identification is tied to the physical Smart Card and its secret PIN code. The Windows workstation username
and password are stored in the Smart Card. The Windows workstation can read the information from the
Smart Card only if the card is inserted into the reader and the user gives the correct PIN code. The access
rights of the user are managed via the operating system in the Windows workstation PC. The Smart Card
therefore ensures that only an authorised user can have access to the workstation.
In addition to inserting the personal Smart Card and entering the PIN code, the user must also enter an
individual username and password to log in to the Airbus DS TETRA System. Every username is granted a
specific set of access rights for the Airbus DS TETRA System services. Different dispatchers (workstation)
users may thus have different user profiles for the TETRA and dispatcher services even if they share the
same dispatcher workstation. The users’ access rights to the Airbus DS TETRA System are managed via the
Workstation User Management application by an authorised higher-level user. If the SafeGuard Advanced
Security Single Sign On software is used, the TETRA username and password can also be stored in the
Smart Card.
4.5.2 Encryption
Encryption increases the security of radio communication and its users. The Airbus DS TETRA System
supports both air interface encryption, where all information transferred on the radio path is encrypted, and
end-to-end encryption, where voice communication encrypted by TETRA terminals is securely transferred
through the network in encrypted form all the way to the end destination.
Air interface encryption
Air interface encryption (AIE) ciphers all communication transferred on the radio path, including data
messages, signalling, speech and user identities. Without encryption, information on the radio path could be
intercepted with a TETRA signal analyser.
Air interface encryption uses encryption keys and algorithms for ciphering information. In normal operation,
the Airbus DS TETRA air interface encryption supports security classes 1 (no encryption) and 3 (encryption
with dynamic cypher key (DCK)) of the TETRA security standard. The security classes can be preferred or
combined according to operator needs.
In TBS fallback operation (see Section 4.7 ), security class 2 (encryption with static cypher key (SCK)) is used.
Note
Air interface encryption requires terminals that support this feature. Terminals that do not support AIE can
be used in the Airbus DS TETRA System, but without encryption. For more information on air interface
encryption, see document Air Interface Encryption in the TETRA System (TRASYSAPP00001).
End-to-end encryption support
End-to-end encryption support means that voice communication encrypted by a radio terminal or a
dispatching application can be securely transferred in the encrypted format through the network all the way to
the end destination (radio terminal or dispatcher workstation), where it is decrypted. Radio terminals and
dispatching applications that support end-to-end encryption are required for this feature to work.
End-to-end encryption is a voice-specific addition to the overall security benefits offered by air-interface
encryption. The Airbus DS TETRA end-to-end encryption support follows the ETSI EN 302 109 standard and
recommendation TETRA MoU SFPG, Rec 02, End-to-end Encryption.
Encrypted individual calls to a clear-voice-only subscriber (radio subscriber, dispatching application user, or
PSTN/PABX subscriber) are not possible and are disconnected at call set-up if attempted. In group calls,
the dispatcher should ensure that there are no clear-voice terminals in an end-to-end encrypted group.
End-to-end encrypted groups must not have any G4WIF (Generic 4-wire Interface) members, as these
cannot decrypt encrypted calls.
End-to-end encryption is not a replacement for air interface encryption, and end-to-end encrypting terminals
should therefore always be used with air interface encryption. Without the use of air interface encryption,
important information might be picked up on the radio path. Note also that not all terminals in the system need
to support end-to-end encryption. This is a service typically used by only a small part of the total user base.
Clear-voice terminals can still be used for voice communication with other clear-voice terminals in the system.
For further information on encryption, see document End-to-end Encryption in the TETRA System
(TRASYSAPP00002).
4.5.3 Jamming detection

The jamming detection feature is intended to warn the network operator of accidental or intentional jamming
of the network radio-carrier frequencies. It generates an alarm if the uplink signal does not contain the proper
TETRA modulation, and cancels the alarm when the proper TETRA modulation returns. There are no
automatic counter-measures. It is for the network operator to decide the appropriate action, for example
changing the transceiver frequency.
4.5.4 Ambience listening

Ambience listening enables a dispatcher to listen to audio picked up by the microphone of an individual radio
terminal that is not currently engaged in voice communication or packet data transfer and to monitor status
and SDS messages sent by the terminal. The need for ambience listening might arise in hostage or 'officer
down' situations, or when terminals have been stolen or misplaced.
The Airbus DS TETRA System ambience listening feature is used in the following way:
1. When there is a need to find out what is happening in the vicinity of a stolen terminal for example, an
authorised dispatcher can activate an ambience listening session for that terminal.
2. If not engaged in any other service at that moment, the terminal responds by turning on its microphone
and transmitter. The activation of the ambience listening session is not indicated on the terminal's
user interface.
3. When an ambience listening session is active, all downlink information to the terminal is barred in order
to make the session last as long as possible. The ambience listening session is disconnected if the
terminal is switched off or if it is used for voice or IP traffic. However, status and SDS messages sent by
the terminal do not disconnect the session, so for example AVL messages, which enable tracking of a
moving vehicle, can still be received.
Note
Terminals to be monitored must support ambience listening. If they do not, an ambience listening session will
be interpreted in the terminal as a normal voice call. Also, to prevent outsiders from listening in on a session,
terminals should support air interface encryption. Airbus Defence and Space assumes no responsibility for
the use of ambience listening with non-interoperable terminals or terminals that do not support this feature.
For further information on ambience listening, see document Voice Communication (DN00126496).
4.5.5 Enabling/disabling a radio terminal

It may be necessary to prevent a radio terminal from accessing the network's services, for example, if the
terminal has been stolen or lost or during periodic maintenance. The disabling can be either temporary or
permanent, and it can be performed on the subscriber's Individual TETRA Subscriber Identity (ITSI), the
Terminal Equipment Identity (TEI) or both. A radio-subscriber-specific parameter determines whether a
terminal is informed over the air of its enabled/disabled status or not. Only emergency communication is
possible from a temporarily disabled terminal. A permanently disabled terminal cannot be used at all.
A dispatcher with appropriate management rights can set a subscriber's ITSI to a disabled state. The
dispatcher can see the enable/disable state of the TEI, but the TEIs can only be enabled/disabled with
MML commands by a network operator.
A radio terminal may be parametrised to authenticate the SwMI before acknowledging the enable/disable
command. See topic heading Mutual authentication in Section 4.5.1 .
4.5.6 Logging of management events

Logging of Management Events is an optional feature which gives an authorized user the ability to track
management changes (to subscribers, organizations, and groups) made in the system. Logs are generated
in the CDD and Tactilon® Management and can be archived and browsed with a network element called
the Audit Trail Server (ATS).
The log can also be seen as a security log because typically a management event changes old data or
creates new data in the system. It is beneficial to track these events so that the administrator of the system
can see the changes in the system and who has performed them.
In addition to the management events, certain other events are also logged. These include logon/logoff from
the workstation, failed WS user authentications and management of the log files.
4.6 SIM support

This feature provides support for the use of a detachable SIM-type hardware module (smartcard) in TETRA
terminals. The SIM holds the following radio-subscriber-specific data:
• Authentication key (K) and algorithm
• Subscriber identity (ITSI)
• Personal data such as a mnemonic and phone book etc.
The SIM makes it possible to separate the subscriber from the terminal, because the subscriber-specific
information is programmed into the SIM, not into the terminal hardware. Provisioning of a SIM is a similar
process to provisioning a terminal. From the network infrastructure's point of view, it is irrelevant whether
a subscriber's terminal is equipped with a SIM or not. SIM use brings a number of benefits for end users
and operators; these are outlined in Section 4.6.1 .
Section 4.6.2 briefly describes requirements on terminals using SIMs.
4.6.1 SIM benefits

Sharing the same terminal among multiple subscribers
The same terminal can be shared among multiple subscribers simply by changing the terminal's SIM. Each
subscriber's ITSI and the associated profile are tied to his/her SIM, and do not change when the SIM is
transferred from one terminal to another. The number of terminals required overall by an organisation
can often be reduced considerably by replacing personal terminals with a pool of common terminals with
the same support capabilities.
Easier to deal with a broken terminal
If a terminal is broken, the SIM can simply be transferred to another terminal, where it is immediately
operational. No provisioning or configuration of the new terminal needs to be done because all subscriber
information is in the SIM.
Easier to visit external TETRA networks
A SIM makes it easier for a subscriber to operate as a visitor in an external network eg. in a cross-border
operation. The subscriber only needs to take his/her SIM along and insert it in a terminal belonging to the
external network.
Separate disabling of terminal and subscriber
The use of a SIM makes it possible separately to disable a lost/stolen terminal on the basis of its TEI (requires
TEI-enquiry support in the terminal) and a lost/stolen SIM on the basis of its ITSI. The last subscriber to use
a specific terminal, or the last terminal used by a specific subscriber, can be found from the registration
CDR (Call Detail Record).
Reduced signalling load on the network
Storing personal data in a SIM decreases the need to transfer configuration data via the network, resulting in
a reduction in the network signalling load.
4.6.2 Terminal SIM-related requirements

The terminal must obviously provide the necessary hardware and software support for a SIM module. In
addition, it must support TEI enquires to make disabling of the terminal possible (air-interface encryption is
also a precondition, since TEI must not be transferred over the air in clear mode).
Pooled terminals all need to have the same support capabilities and configurations to ensure there are no
problems when transferring a SIM from one terminal to another.
If a terminal without a SIM needs to be operable in the network, it must be programmed with its own ITSI
(terminal identity) and authentication key (K) and provisioned. This is not required if the terminal is always
used with a SIM. Each SIM must also be programmed with its own ITSI and K and provisioned. When a SIM
is used in a terminal, the SIM ITSI and K override the terminal ITSI and K
4.7 Enhanced TBS fallback

The Enhanced TBS Fallback feature offers a means of providing secure group- and individual call functionality
to the radio terminals (RTs) remaining in a cell following loss of communication between the TBS concerned
and the DXT (for example due to transmission line- or DXT failure). When a TBS goes into fallback mode, it
broadcasts an indication of this to the RTs in the cell, which may then attempt to switch to a neighbouring
cell offering adequate coverage and network services, if there is one.
TBS-specific parameters control whether an individual TBS is allowed to operate in fallback mode and, if it is,
the timeout period (following loss of communication with the DXT) after which it begins to do so. A TBS which
is not allowed to operate in fallback mode will shut down if it loses communication with the DXT. A TBS will
exit the fallback mode when communication with the DXT is re-established.
Security in the fallback cell can be ensured by means of SCK encryption on the air interface and/or end-to-end
encryption (E2EE) between radio terminals.
Enhanced TBS fallback can also be used in standalone TBSs.
Note
Enhanced TBS fallback supports emergency calls and SDS/status messages.
4.7.1 Group calls

The primary fallback functionality offered by the feature is trunked group communication, in which group calls
between RTs in the cell are set up and released in the normal way using one of the TBS traffic channels
available at the time. However, to provide continuity with the TBS fallback implementation in earlier TETRA
System releases, the pre-definition of up to three fixed groups is also supported (an operator upgrading to
Release 5.5 or later may prefer this if radio subscribers are accustomed to using fixed groups in fallback
situations). Both fixed-group and trunked fallback communication can take place together under the same
TBS provided there are enough traffic channels to support the configuration required.
Calls in fixed groups are started automatically when the TBS enters fallback, and run for the whole duration of
the fallback period. The TBS begins generating late-entry setups for these calls when they start, and the
RTs can join them as they wish. The radio terminal's configuration determines whether it will automatically
join a fixed-group call or whether the user must select the call to join.
Trunked group calls are able to use any traffic channels available in the TBS. The maximum possible number
of simultaneous trunked group calls is thus equal to the total number of traffic channels in the TBS minus the
number of fixed groups, unless SCCH is used. The TBS sends late-entry setups for established group calls
on the MCCH, and calls are released on the basis of a predefined inactivity time (3 s). A radio subscriber
can start a group call in any group with a GSSI in the range defined for fallback groups. Any subscriber
can attach to any group.
The parameters for making fallback group- and encryption definitions are system parameters entered with
MML.
Default emergency group short subscriber identity (GSSI)
The parameters used to define one of the three possible fixed fallback groups can, alternatively, be used to
define a default trunked-mode emergency group address. This definition includes the maximum speech-item
duration and the maximum inactivity time.
Note that if the default GSSI is defined, only a maximum of two fixed groups is then possible.
The default emergency group should be defined as a background group in every terminal in the network.
Thus defined, this group is only in use in the fallback mode and not in normal mode.
4.7.2 Individual calls
A TBS operating in fallback mode supports trunked simplex individual direct- and hook calls between radio
subscribers in the cell concerned. The TBS will automatically change a duplex call setup to simplex, ensuring
that only a single traffic channel is taken up by each individual call.
No call owner is assigned, and the call can be disconnected by either party or by an inactivity timer. The
inactivity timeout is 3 s for an individual direct call (the same as for a group call) and 15 s for an individual
hook call.
An emergency individual call is automatically changed to a group emergency call to the default emergency
GSSI (see Section 4.7.1 ).
Resource queueing and pre-emption are applied in accordance with the TBS parameters and the
access-message (call setup request) priority.
Note
In TBS fallback, normal group calls pre-empt individual calls.
4.7.3 Encryption
Note
Only third-generation TBSs (TB3) support the use of air-interface encryption (AIE) in fallback mode;
second-generation TBSs do not.
Both second- and third-generation TBS's support end-to-end encryption (E2EE) in fallback mode.
A system parameter called Fallback security class governs encryption on the air interface. This parameter
can take one of the following values:
• 0 = Class 1 (no encryption)
• 1 = Class 2 (SCK encryption)
• 2 = Class 1 and Class 2
Note that AIE in fallback mode uses a static cypher key (SCK) instead of the dynamic cypher key (DCK)
used in networked TBS's.
For information on the delivery of the SCK from its point of origin into the Airbus DS TETRA System and
onwards to the TBS's, see document Air Interface Encryption in the TETRA System (TRASYSAPP00001).
If the fallback security class is set to Class 1 and Class 2, it is up to each radio terminal to decide whether it
registers for Class 1 or Class 2 operation.
For trunked groups, it is the terminal that decides whether AIE is used or not.
For fixed groups, the system parameters GSSI 01/02/03 Encryption specify the encryption
(none/SCK/E2EE/both).
4.8 Direct mode communication
In direct mode operation (DMO) radio units communicate directly with each other on radio frequencies
assigned specifically for DMO. DMO does not use any network resources. The coverage area is smaller
than in the case of network-mediated communication. A prerequisite for using DMO is that the radio units
used support the feature.
Direct mode is useful when radio users need to operate in locations beyond the reach of system coverage
(for example tunnels and other coverage blind spots) or when the radio users do not want to operate via
the network.
You can extend the operational range of direct mode communication by using the TGR990. The TGR990 can
operate as a TMO/DMO Gateway to connect radio units operating in TMO within the TETRA coverage and
those operating in DMO. The TMO/DMO Gateway is illustrated in Figure 8 .
DXT TB3
TB3
TB3
TB3
TB3
TB3
Gateway
Key:
= Trunking Mode
= Direct mode
= Transmission lines
= Radio path
Dn00122316x4x1xen
Figure 8 : Direct mode communication with optional TMO/DMO Gateway
It is also possible to improve the direct mode communication by using the TGR990 as a DMO Repeater. The
DMO Repeater can connect radio units that are both using DMO, for example in mountainous terrain.
The functionality of the DMO Repeater is illustrated in Figure 9
Repeater
dn101468x1x0xen
Figure 9 : DMO Repeater
4.9 Air-to-ground communication

Because radio signals from airborne terminals may propagate over great distances and perhaps cause
interference in other cells using the same frequency, it is beneficial to have separate base stations providing
'air cells' for airborne terminals. Air-cell coverage will generally be wider (frequently as wide as possible)
than that of normal ground cells.
Access to air cells is controlled by means of subscriber-specific subscriber classes. Airborne terminals belong
to a subscriber class of their own. This subscriber class treats the air cells as 'highly preferred', which means
that in practice a terminal located in an aircraft will roam from a ground cell to an air cell soon after takeoff, or
may have been using the air cell even while on the ground. Access to air cells is denied to ground users.
Special aircraft terminals are required for air cell use. It is beneficial if airborne terminals support the distance
reporting functionality in air-to-ground cells. This enables the network to order a radio terminal to stop using
the current cell and to roam to another when the terminal is too far away.
Note
The use of radio transmitters in aircraft must comply with national aviation regulations.
4.10 Energy Economy

In a PMR network, terminals usually listen to the control channel continuously, which reduces terminal
battery life. The Airbus DS TETRA System offers the option of increasing terminal standby time (battery life)
by specifying the frames during which terminals listen to the control channel. The use and level of energy
economy (EE) can be defined separately for each user group.
Energy economy can be applied to all radio terminals signalling in the Airbus DS TETRA System.
4.11 Periodic registration

Periodic registration can be used to supervise the existence of radio subscribers or terminals in the network
by forcing them to re-register with the network periodically. For example, tracking information can be updated
when a terminal breaks down or its battery runs out. After the periodic registration time has elapsed and no
registration has taken place, the terminal can be removed from its last location to an inactive state.
Periodic registration also caters for stationary terminals. The only way to check their status and update the
terminal's DCK is to have stationary terminals register with the base station (since the terminals do not
change location, cell reselection will never occur). Periodic registration forces a terminal to re-register
at predefined intervals.
4.12 Availability
The Airbus DS TETRA System, applications, and information resources are accessible when the user needs
them. The user requirements concerning the availability of the system may vary significantly depending on
the criticality of the communication in the system.
The main availability features in the Airbus DS TETRA System are:
• Hardware redundancy
• TBS fallback
• Transmission link monitoring and rerouting
• Direct Mode Operation (DMO)
• Priority access
• Service priorities
• Capacity guards
• Exclusive capacity for user groups
• Automatic checking of inactive radio terminals (Periodic registration).
The Airbus DS TETRA System has been designed and constructed with high serviceability in mind. A high
level of redundancy ensures that system functionality is available to users even in the toughest circumstances.
This is guaranteed with network elements” internal redundancy, flexible transmission solutions, and features
like TBS fallback, DXT fallback and redundant HLR.
In the Airbus DS TETRA System, the air interface is adjusted according to the signalling load. To improve the
probability of a terminal to get uplink service when the probability of congestion has increased, the system
automatically adjusts the length of the random access frame. The Airbus DS TETRA System also provides
exclusive access to emergency calls in the control channel signalling. Where there is no coverage at all,
Direct Mode Operation (DMO) enables voice communication between radio terminals locally without the
network's involvement.
Several priority access methods are implemented in the Airbus DS TETRA System to fulfill availability
requirements in a network shared by several organisations. In addition to prioritizing certain calls, it is
possible to prioritise the service that the system offers to an organization.
It is possible to set special capacity guards to monitor that the data applications do not overuse the services
or overload the downlink air interface or the external interfaces. The system can be set to monitor the control
channel uplink especially if the automatic vehicle/person location (AVL/APL) services are used extensively.
The system can automatically adjust the rate of location updates sent by the radio terminals, if necessary.
Therefore the network can be used to its full capacity without compromising availability.
The Airbus DS TETRA System can also offer an exclusive capacity for certain user groups: a base station can
be dedicated to serve this user group either permanently or temporarily. In other words, the user group has a
guaranteed use of the capacity offered by the base station, no matter how heavy the overall traffic in the area.
The Airbus DS TETRA System offers backward compatibility and capability to have two different software
releases in the network at the same time, without any shortage in network-wide services. Therefore, the
users' services are available normally during the upgrade procedure.
4.13 Numbering
The Airbus DS TETRA System offers numbering schemes that are easy to use and offer a variety of
benefits, such as short numbers and the ability to differentiate the identity of a radio terminal equipment and
the subscriber that is currently using it.
Mobile subscribers can have several numbers at once, known as virtual subscriber numbers. This makes it
possible to assign logical numbers to everyone in a particular task force or to everyone who is performing the
same function in an organization. This way numbers up to 5 in the same time, bound to a special task or
responsibility can be allocated to an individual’s terminal.
The standard way of numbering TETRA radio terminals is by associating the radio itself with a certain
subscriber number, that is, a 7-digit Individual TETRA Subscriber Identity (ITSI). This is practical if there is
a good numbering plan which is not likely to change soon. However, it may be impossible to predict any
long-term changes in the use of the network. Therefore, it is possible in an Airbus DS TETRA system to use a
more flexible numbering scheme, the so-called MS-ISDN numbering. In this numbering scheme, the radio
terminal’s identity is not linked to a subscriber number. Since each user can have several MSISDN numbers,
the feature is suitable for tactical and functional numbering. A person in charge behind the functional number
(for example, the chief officer) is changed according to the work shifts. It allows each user to use their own
terminal but the other users can still always use the same MSISDN number when calling to the chief officer.
By using MS-ISDN numbering, you can create a scheme that reflects the actual user organization. At the
same time, the actual physical radio terminal numbers can be assigned very efficiently. This means that
the process of taking new radio terminals into use, and also the process of adding new users, is simple,
straightforward, and very fast.
In the Airbus DS TETRA System, an authorized dispatcher can create short-number fleets for special
teams or other special groups within an organization. The users can then reach the others in the same
short-number fleet using a very short number (between one and six digits). The Fleet-Specific Short
Numbering (FSSN) allows changing the user number associated with a radio terminal, thereby making it
possible for several people to share the use of a single radio terminal in shifts. FSSNs can be easily changed
without re-programming the MSs.
FSSN is also used for creating Closed User Groups, which makes it possible to integrate both TETRA users
and organization PABX extensions to the same numbering range. In this way, a TETRA subscriber can
call to the PABX by using FSSN dialling.
In the Airbus DS TETRA network the access rights of each user are based on organizational groups or
domains. This has a benefit that changes in personnel or changes in the numbering scheme do not force
organizations to update all the user call rights. Access to public networks can also be enabled separately
for each user as appropriate.
4.14 Remote SW downloading
Remote software downloading enables you to achieve savings in the operating expenses as it allows you to
download and activate new SW packages to network elements remotely. The TBSs, DXTs, CDDs, TCSs, and
dispatching applications in the Airbus DS TETRA System can be upgraded remotely, which minimises the
amount of the time-consuming and expensive site visits. It also improves the quality of service by enabling
you to always install the latest SW version easily and cost-efficiently.
The remote SW downloading does not require any additional transmission arrangements; you can use the
existing transmission solution. The downloading is normally done by using a lower priority to ensure that
normal operation is not affected.
5 TETRA network elements
The network elements of the Airbus DS TETRA System have been designed to provide a reliable and
fast radio network. The network elements can be divided into core elements, which are mandatory in all
network implementations, and additional elements, which are optional or mandatory only in certain network
implementations.
The core network elements and the additional network elements and interfaces used in the Airbus DS TETRA
System are listed in table 1 . The main network elements are described in more detail in the following sections.
The use of the system date and time in the TETRA System is described in the document Time Management
in the TETRA System, DN0484132.
Table 1 : Core elements and additional elements and interfaces
Network element Description

Core network elements
DXT, access-level Taira TETRA Server, DXTA, DXT3™
™, DXT3c, DXT3p, and DXTip
TETRA base station TB3 and TBS
Dispatcher management Dispatching management application, such as Tactilon® Management or
application DWS M
Dispatcher communication Dispatching communication application, such as RCS 9500, DWS C or
application DWS C&M
Additional network elements and interfaces
DXT, transit-level DXTA, DXT3™
™ and DXTTip. Required to implement a hierarchical DXT
network.
IP backbone Mandatory in all multisite networks
CDD Configuration and Data Distribution Server, which provides network-wide
services related to data management (configuration) and data
distribution.
Mandatory in all multi-DXT networks
ATS Audit Trail Server, which is used for storing and post-processing
management event information logged on the CDD server
TCS Single-user Server software for providing a single third-party client with access to
network services
TCS Multi-user Multi-user server providing third-party clients with access to network
services
EPD-GW Enhanced Packet Data Gateway, which enables the implementation of
the IP Packet Data Enhanced Service
TVG TETRA Voice Gateway provides TETRA voice for end-user applications
Table 1: Core elements and additional elements and interfaces (cont'd.)
Network element Description

3rd party interface and PCM Used in connection with the TETRA Connectivity Server
codec interface
AKD Elements and tools for implementing the authentication key delivery
(AKD) system
NMS Network management system, such as NetBoss XT for TETRA
Digital R2 Interfaces to PSTNs/PABXs. Analog R2 interfaces can also be
implemented with the help of additional equipment.
Digital G4WIFs Generic 4-wire interfaces to external systems. Analog G4WIFs can also
be implemented with the help of additional equipment.
G4WIF GW G4WIF Gateway for allowing IP-only-connected DXTs to access
conventional G4WIF systems over E1.
SIP trunk Interface for facilitating IP based voice and signalling connection
between the TETRA system and PSTN/PABX. In case a direct
connection to PSTN/PABX is not possible, an external SIP gateway can
be used between DXT and PSTN/PABX.
ISDN PRA 30B+D Interfaces to PSTNs/PABXs
VPN/firewall router and DNS For linking the IP backbone to external IP networks such as ISPs,
service corporate intranets and the Internet
DNS service is required with the IP Packet Data Enhanced Service
5.1 Digital exchange (DXT)

The Airbus DS TETRA System family of digital exchanges consists of the Taira TETRA Server, DXTA,
DXT3™™, DXT3c, DXT3p, DXTip, and DXTTip. The central functions handled by the DXT are:
• Switching
• Call services
• Speech item allocation
• Database services
• Signalling services
• Trunking
• Resource management
• Numbering
• Charging services
• Statistics
• Data services
• IP packet data
• Authentication and encryption
• Handling interfaces to external systems such as PSTNs, PABXs, command-and-control centres,
non-TETRA systems (for example, conventional analog base stations), foreign TETRA SwMI etc. The
DXTA and DXT3p also handle the SIP trunk access to PSTN/PABX.
• E1 transmission (DXT3/DXT3c/DXTip/DXTTip)
• IP transmission (Taira/DXTA/DXT3/DXT3c/DXT3p)
The DXT's client-capacity figures — for both Airbus Defence and Space clients and third-party clients — are
presented in the following table.
Table 2 : Client-capacity figures for the DXT
DXT type Maximum number of clients

(total / with audio):
Taira TETRA Server
Without CDD 16 / 16
With CDD 64 / 64
DXTA (access layer) 2)
Without CDD 64 / 64
With CDD 256 / 256
DXTA (transit layer)2)
With CDD 1) 256 / 256
DXT3 (access layer)
Without CDD 64 / 64
With CDD 256 / 256
DXT3 (transit layer )
With CDD 1) 256 / 256
DXT3c (with or without integrated CDD)
Without CCSUs 8/8
With CCSUs 64 / 64
DXT3p
2 TCS servers with up to 10 clients or
10 single-user TCS servers.
Only EMT v2 is supported.
DXTip (access layer)
Without CDD 64 / 64
With CDD 256 / 128
DXTTip (transit layer)
With CDD 1) 256 / 128
1) Networks with a transit-layer switch always have a CDD.
2) One DXTA can handle simultaneously up to 3000 audio and event monitored groups divided among the clients.
5.1.1 Taira TETRA Server
Taira TETRA Server (Taira) is a network element that uses virtualisation platform on top of Linux operating
system for virtualising critical TETRA server functions such as those of digital exchange (DXT). The virtualised
DXT provides the same services as previously handled by access-layer DXTs: DXT3c and DXT3p. For fast
deployment and easy configuration, Taira features a graphical user interface (GUI).
Taira runs on x86 server(s) with MGATE32 and EsGates.
• Taira 310 provides an extremely concise TETRA server solution with one x86 server
• Taira 330 offers the high-availability solution with three x86 servers
Taira can be installed in a 19-inch rack. A DC distribution panel for -48VDC power feed is included in the
delivery.
Taira TETRA Server is available from TETRA System Release 7.0 onwards. The virtualised DXT in Taira
supports IP transmission. Optionally, also E1 connections for speech lines towards other DXTs can be
configured.
For a detailed description, see Taira TETRA Server Product Description, TRADXTAPP00187.
5.1.2 DXTA
The DXTA is a single-cabinet TETRA server, used as an access-layer and transit-layer switch in the Airbus
DS TETRA System. Built on the generic Advanced Telecommunications Computing Architecture (ATCA)
platform, it can be connected to a wide range of network elements such as:
• other DXTs
• TB3 base stations
• Airbus DS dispatching applications
• Tactilon® Management
• Tactilon® Agnet clients
• Communication and Data Distribution Server (CDD)
• Enhanced Packet Data Gateway (EPD-GW)
• TETRA Connectivity Server (TCS)
• Network Management System (NMS)
• PSTN/PABX through a SIP trunk interface
• Automatic Vehicle Location Server (AVL)
• TETRA Voice Gateway (TVG)
• G4WIF Gateway (G4WIF GW)
• third party clients
Compared to the older DXT3 models, the DXTA offers more performance and reliability. The larger size of
the cabinet leaves room for additional equipment, such as CDD, ATS, EPD-GW, TCS or L2/L3 switches.
All the internal functional units are duplicated for redundancy and resiliency. All field replaceable units, with
some exceptions, are hot-swappable. The DXTA also features virtualised computer units, which allows
using HW memory for optimised efficiency.
The DXTA supports IP transmission only. Optionally, the DXTA can also be configured to have E1 inter-DXT
speech line connections.
For a detailed description, see DXTA Product Description, TRADXTAPP00106.
5.1.3 DXT3
Note
The DXT3 supports both E1 and IP transmission.
The DXT3 is a single-cabinet digital exchange that serves as an access-layer and transit-layer switch in the
Airbus DS TETRA System. The DXT3 is used in the Airbus DS TETRA System as the switching element to
which base stations, other DXT exchanges, dispatching systems, network management centres, the CDD
Server and external network interfaces can be connected.
The DXT3 supports up to 320 radio carriers distributed among a maximum of 128 TETRA base stations.
In addition, the DXT3 contains a subscriber database holding all subscriber identification and call rights
data. The database also includes information related to organisations and groups. Radio subscriber and
workstation user data is entered using the DWS dispatcher/management applications or using a remote-client
application via the TETRA Connectivity Server Application Programming Interface (TCS API).
The DXT3 incorporates critical-element redundancy that enables automatic fault recovery.
The access-layer DXT3 switches speech and data between radio users and dispatchers. It also allocates
speech items in group communication and handles priorities.
The transit-layer DXT3 interconnects the access-layer DXT3 exchanges to a larger, hierarchical network. Via
the transit layer, voice and signalling links between different groups of access-layer DXTs can be established
in a straightforward and systematic way. The DXT3 offers 960 8-kbit speech channels for connecting to other
exchanges. TETRA base stations cannot be connected to the transit-layer DXT3.
If the TETRA Services for Smart Devices are used, the DXT3 functions as the Tactilon® Agnet server. In such
a case, the DXT3 must be equipped with the TAS unit(s).
The DXT3 supports both E1 and IP transmission.
For a detailed description, see DXT3™ and DXT3c Product Description, TRADXTAPP00028.
5.1.4 DXT3c
The DXT3c is a single-cabinet digital exchange for the Airbus DS TETRA System.
The DXT3c is an access-layer switch, which is intended to be used in small and medium sized networks. It is
particularly aimed for demanding networks which have a high traffic profile, such as airports, or in networks
where high reliability is required, such as the underground. Because of its compact size, the DXT3c can
also be installed into a vehicle.
The DXT3c offers the same functionalities as the DXT3 ─ such as TEDS ─ but it is smaller in size and has
less capacity. It has no PDCU or SIPU units. The DXT3c can be integrated into an existing DXT network; by
interconnecting the DXT3c with the DXT3, the network can be easily extended to a large network.
If the TETRA Services for Smart Devices are used, the DXT3c functions as the Tactilon® Agnet server. In
such a case, the DXT3c must be equipped with the TGS and EsGate units. It is not possible to add TETRA
Application Server (TAS) units to the DXT3c.
The DXT3c supports both E1 and IP transmission.
For a detailed description, see DXT3™ and DXT3c Product Description, TRADXTAPP00028.
5.1.5 DXT3p
The DXT3p is a portable access-layer switch for small IP networks and is supported from TETRA System
Release 6.5 onwards. It is an extremely concise TETRA switch that can be fitted in a small space and used
as a transportable exchange. The hardware duplication has been reduced to a minimum, so that the DXT3p
consists of the most essential units only: Operation and Maintenance Unit (OMU), TETRA Gateway Server
(TGS), ESB24-D LAN switch, Power and Connection Unit (POCO), and EsGate units.
The DXT3p can be embedded to a TB3S rack, installed to a standard 19-inch rack, or installed to a
transportable case. It can be connected to other IP-connected TETRA network elements, such as the
IP-connected TB3 base stations, dispatching applications (DWSx) and other DXT3 switches. The DXT3p
also includes a SIP trunk interface, which provides the option to connect DXT3p to PSTN/PABX through an
external SIP gateway.
The DXT3p supports only IP transmission.
For a detailed description, see DXT3p Product Description, TRADXTAPP00080.
5.1.6 DXTip and DXTTip (DXT)

DXTip
The DXTip is a single-cabinet digital exchange for the Airbus DS TETRA System. It serves as an access-layer
switch, which can be connected to base stations and other DXTs. The DXTip supports up to 320 radio carriers
in a maximum of 128 TETRA base stations. The communication and other functions provided by the DXTip
are basically the same as those of the DXT3, except that the DXTip does not support IP transmission for TB3
and inter-DXT voice and signalling. Only E1 transmission is supported.
DXTTip
The DXTTip is a two-cabinet transit switch, which is used as a hub to interconnect groups of access-layer
switches. The DXTTip provides the capacity and reliability for handling high traffic loads in the Airbus DS
TETRA System. The DXTTip is used in conjunction with DXTip exchanges to create larger, hierarchical
DXT networks.
The DXTTip provides 960 8-kbit speech channels for connecting to other exchanges. It cannot be connected
to TETRA base stations. The DXTTip does not support IP transmission for inter-DXT voice and signalling.
Only E1 transmission is supported.
For a detailed description of the DXTip and DXTTip, see the document DXTip and DXTTip Product
Description, DN0531796.
5.2 TETRA Base Station (TBS)

The TETRA Base Stations (TBS) and radio terminals provide wireless and mobile communication in the
Airbus DS TETRA System. The function of the TBS is to provide the air interface between the TETRA radio
terminals (RT) and the TETRA network. The signalling on the air interface is compliant with the TETRA air
interface (AI) standard (ETSI 300392-2) and supports multi-vendor RT interoperability. From the point of
view of the radio subscribers, the TBSs are transparent because the operating frequencies are automatically
selected by the radio terminals.
The TBS is a scalable base station solution. Depending on the base station model, the number of
antennas, carrier units, and power supplies can be optimised according to the needed traffic capacity. The
required radio coverage determines the number of base stations. Multiple TBSs can be installed at the
same site if more channels are required in the cell than can be supplied by a single TBS. The possibility
for remote management sessions and software updates facilitates controlled maintenance and eliminates
time-consuming visits to the TBS sites.
The TBS products currently offered are the TB3, TB3S, TB3c, TB3p and TB3hp, all of which are based
on the TB3 third-generation base station platform by Airbus Defence and Space. The TBSs come in a
family of frequency variants for use in different bands.
All of the above-mentioned TB3 variants support both E1 and IP transmission. They can be connected to the
DXT over E1 or IP connection, depending on the DXT type. Note that it is possible to use E1-connected
TBSs and IP-connected TB3s in parallel with the same DXT. However, one TBS can use only one connection
type at a time.
5.2.1 TB3
The TB3 offers advanced 6-way diversity combining, redundancy and best in class radio coverage. A single
TB3 base station consists of 1 or 2 cabinets, depending on the number of carriers. Single-cabinet base
stations accommodate up to 4 carriers (transceivers); two-cabinet base stations accommodate up to 8
carriers. A single carrier encodes 4 TETRA channels; 8 carriers gives the maximum capacity of 31 traffic
channels and one control channel per TBS.
For detailed information about the TB3, see the documents TB3 Product Description, DN04102617, and
TB3 Hardware Description, DN04161675.
5.2.2 TB3S
The TB3S is a modular base station, which offers a cost effective and compact solution for providing coverage
of any size of E1 or IP networks. The basic TB3S is housed in a single indoor cabinet and can be equipped
with 1-4 radio carriers. If the TB3S extension cabinet is used with the TB3S basic cabinet, it is possible to
extend the total number of radio carriers to a maximum of 8 carriers. Because the TB3S’s power supply unit
is integrated to the TTRX, it has more room for other equipment, including the possibility of housing IP
transmission equipment or the extremely small DXT3p exchange. The TB3S also offers space to integrate
upcoming wideband radio access equipment inside.
For detailed information about the TB3S, see the document TB3S Product Description, TRATBSAPP00025.
5.2.3 TB3c
The TB3c is a compact, transportable version of the TB3. It is housed in a single indoor cabinet and can
be equipped with 1 or 2 radio carriers (up to 8 channels). It is easy to install and requires less installation
space which facilitates site acquisition.
For detailed information about the TB3c, see the document TB3c Product Description, DN0531348.
5.2.4 TB3p
TB3p is a small, portable base station, which can be equipped with either 1 or 2 radio carriers. It has been
designed as a cost-effective solution to provide coverage for the indoor, stand-alone and deployable networks
and to fill the capacity gaps in the network on a need basis.
For detailed information about the TB3p, see the document TB3p Product Description, TRATBSAPP00022.
5.2.5 TB3hp
TB3hp is a high power variant of the TB3p base station; it has an RF power of 15W compared to the TB3p’s
4W. Like the TB3p, it can be equipped with either 1 or 2 radio carriers, and it has been designed as a
cost-effective solution to provide coverage for the indoor, stand-alone and deployable networks and to fill the
network’s capacity gaps in the network on a need basis. The TB3hp can also function as a TEDS hotspot.
For detailed information about the TB3hp, see the document TB3hp Product Description, TRATBSAPP00029.
5.3 Tactilon® Management

A typical TETRA network has thousands of radio subscribers and managing them individually is very
time-consuming. Tactilon® Management has been developed to bring a solution for this: an easy-to-use,
secure and flexible solution that reduces workload and cuts costs substantially. Instead of managing each
radio subscriber individually, Tactilon Management enables authorised users to manage radio subscriber
attributes as a whole, saving time and effort. Radio subscriber, smart card and terminal information can be
linked in Tactilon Management, which enables managing of different objects from one user interface and
storing data to a single (Tactilon Management) database. Tactilon Management’s import/export functionality
helps in transferring data to Tactilon Management from external systems. Tactilon Management can also be
connected to external systems so that data can be kept up-to-date automatically.
With Tactilon Management's system of profiles, different users can be given different communications
attributes depending on their scope of work. For example, an ambulance unit profile, a police car profile,
and a mobile border guard profile could each be defined once and then applied to any number of users as
appropriate. Numbering, talk groups, priorities, rights, and so on can all be managed this way.
Any changes to a profile in Tactilon Management will be automatically updated for all users of that profile.
Mass operations like this will simplify network administration and boost efficiency, which is particularly useful
when introducing a new set of users to a TETRA network, but it will also make it much simpler to manage
existing radio subscribers.
Tactilon Management also uses districts, which are collections of base stations and DXTs that can be used,
for example, as talk group area definitions. Tactilon Management users can define districts that can further
be assigned to talk groups. This will help Tactilon Management users in managing talk groups, as detailed
information of the network (exchange and location area) structure is not necessarily required.
Tactilon Management also improves security in shared TETRA networks as it allows administrators in one
user organisation to manage the attributes of their own radio subscribers without support from the network
operator and without giving them access to radio subscribers from other user organisations.
Users and administrators can access Tactilon Management by using a web browser (for example, Firefox,
Internet Explorer or Safari) via web protocols (HTTPS), without the need to install any special equipment or
software. The application itself is installed on a central server by the network operator which also simplifies
the update procedures.
Tactilon Management is connected to the TETRA System via the CDD's TCP/IP-based message interface.
There is no direct connection between the DXT and Tactilon Management. All radio subscriber management
configurations executed at Tactilon Management are first transferred to the CDD, after which the CDDs are
synchronised with each other before the CDD updates the data to the DXT.
An Airbus TETRA network can have either Tactilon Management or some other management solution over
TCS API (i.e., DWS M or 3rd party solution). Once Tactilon Management is chosen as a management
solution for a TETRA network, Tactilon Management must not coexist with DWS M or TCS API –based 3rd
party management solution in the TETRA network. Tactilon Management has a scalability for handling up to
3500 active Tactilon Management users and Tactilon Management Lite up to 35 users. Only one Tactilon
Management shall be implemented in an Airbus TETRA system.
For more information, see Tactilon® Management Product Description, TRADWSAPP00013.
5.4 Radio Console System (RCS 9500)

The Radio Console System (RCS 9500) is a mission-critical network-wide dispatch system designed to
streamline communications and expedite responses in public safety and security organisations, which need
fast and reliable communications in running their field operations. The RCS 9500 is an efficient solution,
which provides dispatchers with a quick and easy access to the TETRA communication features. For the
user organisation, the RCS 9500 offers the unique possibility of freely designing and customising the user
inferface to best serve their operating process. The drag-and-drop editing tools enable the creating of the
best possible environment for effective dispatching.
RCS 9500 is a Windows-based full IP dispatch solution, which uses Voice over IP (VoIP) technology and an
IP network to interconnect analog radios, digital trunked radios, telephones, system controllers, and operator
consoles. Because the RCS 9500 supports the use of both analog and digital elements, it also offers the
possibility of a smooth migration from the analog professional mobile radio (PMR) to the digital TETRA.
RCS 9500 supports all of the most desired TETRA communication features, such as status and text
messaging (including SDS and LIP messages), group calls, individual calls, unit tracking, and audio
monitoring. It also contains options to include interfaces to analogue radio networks, computer-aided
dispatch (CAD) and call-taking systems.
RCS 9500 network elements
RCS 9500 consists of the following network elements:
• RCS 9500 Console is a Windows-based dispatching application, which can be used to manage both
analog and digital communications. It manages all dispatching operations and controls all signalling
and audio interactions. The RCS 9500 Console is always connected to a RCS Controller and optionally
also to a SAM and/or Radio Gateway.
For information about the different types of RCS consoles, see section RCS versions.
• RCS Controller is a Windows-based server, which is used for configuring ang managing the RCS
network elements.
• Sound Arbitration Module (SAM) is an optional element, which provides connections for microphone,
loudspeakers, headsets, foot switch, recorders, and jackboxes.
• Radio Gateway is an optional element, which provides an interface for analog radios or Wireless
TETRA radios. Each Radio Gateway provides an interface for a single analog radio channel or
Wireless TETRA radio.
The RCS 9500 network elements are connected by using an IP network, which can be any kind of managed
QoS-enabled LAN or WAN network that supports IP and multicast addressing. If WAN is used, RCS
9500's components can be distributed over a WAN, which provides geographical diversity and enhances
the system's resiliency.
RCS 9500 versions
There are two versions of the RCS 9500 Console available: Standard and Lite Console. The standard RCS
9500 Console is a full-function console intended to be used with the SAM. It requires a workstation, LCD or
touch monitor, keyboard, mouse, a SAM box, two speakers (Select and Unselect), and two headset/handset
jackboxes. Optional choices include headset, handset, desktop microphone, footswitch, and one additional
monitor speaker.
The RCS 9500 Lite Console is intended to be used with USB headsets and accessories. It does not require
a SAM and therefore it can be used on a laptop computer equipped with a USB headset and speakers. Audio
peripherals with USB connectors are also available for use with the Lite Console.
Note that a USB product activation key (HASP) must be connected to each RCS 9500 Console before it
can be used. The product activation key for the standard RCS 9500 Console licenses all product features,
whereas the RCS 9500 Lite Console individually licenses group communications, individual communications,
short data service (SDS), and unit tracking.
In addition, RCS 9500 also supports a wireless solution, where the RCS 9500 connects to the TETRA system
via the air interface by using the Radio Gateway and TETRA radio terminal. RCS 9500 Wireless provides a
flexible graphical user interface for the functionality available through the radio terminal AT commands.
RCS 9500 in the TETRA network
The RCS 9500 Console has interfaces to the DXT, TCS, TVG, and NMS network elements in the Airbus DS
TETRA network. It is integrated to the Airbus DS TETRA System via the TCS API. TETRA audio is supported
with direct E1 or IP connection, in either clear or encrypted mode, or via the TVG. The health and status of
the RCS 9500 network elements is monitored by using a NMS.
The subscribers, talk groups and organisations are configured and managed in the TETRA network by using
Tactilon® Management or the DWS management (DWS M) application.
For more information on RCS 9500, see the document Radio Console System Product Description,
RC1/SYS/APP/00011.
5.5 Dispatcher Workstation (DWS)

The Dispatcher Workstations (DWS) are used for network-wide dispatching and the management of network
communications, subscribers, and talk groups in public safety and security organisations, which need
advanced tools to run their field operations efficiently. When a public safety or security related incident occurs,
the dispatchers assign tasks to individual units or groups of units, as well as create and manage these
groups; all this while following how the incident is developing and deciding what new resources are needed.
By using the DWS, the dispatcher can perform a wide range of radio network related communication and
management tasks via an easy-to-use graphical interface. The interface consists of a series of windows,
dialogues, and menus enabling the workstation user to perform operative and administrative tasks easily
and efficiently.
The DWS is connected to the TETRA System using either the IP-connected DWSip, the E1- or IP-connected
DWSx or the wireless DWSr. The DWSr can be used only for Management, whereas the DWSip and DWSx
can be used for either Communication or Management, or both. An overview of the Communication and
Management features is given in the following sections.
Note that in the Airbus DS TETRA System, the technical and operational management are separate functions.
The operational management, also known as dispatching, is a task needed by the end-user organisation
to perform their safety and security mission. The DWS is used to manage the operational, virtual private
networks (VPN). In contrast, the managing of the physical radio network is done by using the Network
Management System (NMS). For more information on the NMS, see chapter 5.13 .
With the DWS SW Remote Management feature, the latest DWS and TCS software can always be
downloaded and activated cost-effectively without visiting the actual site. Rapid deployment of new enhanced
DWS software versions ensures high availability and quality of service. If a problem situation occurs, the
problem solving process can be started quickly by printing log files from a remote office without the time delay
of going to the equipment site.
Communication features
The DWS Communication (DWS C) application is the dispatcher's basic interface to the TETRA System.
With the DWS C, you can get detailed information on individual radio users or an overall picture of your
organisation. The dispatcher system is scalable to radio networks of different sizes and its functionality can
be adjusted to meet different user needs. You can efficiently use it to:
• Receiving calls and callback requests
• Making individual calls
• Making calls to and receiving calls from PABX/PSTN and other external systems
• Handling emergency calls
• Communicating with one or several groups
• Sending and receiving status and short data messages
• Tracking subscribers
• Adding and removing radio users from groups
• Combining groups for unexpected communication needs.
Management features
The DWS Management (DWS M) application provides administrative facilities for managing subscribers,
groups, dispatchers and organisations in the Airbus DS TETRA System. It can be efficiently used for the
following management functions:
• Creating new groups and temporary groups
• Adding new radio users to the system or modifying communication rights and other attributes of the
existing radio users
• Managing groups, group areas, organisations, organisation parameters, workstations and client
applications.
When the DWSip is used for Management, it contains a connection management application where the
user can easily select which DXT/CDD is used for the management session. This is especially useful for
managing workstation users from a centralised location
For detailed information about the DWS, see the document Product Description of the TETRA Dispatcher
Workstation (DWS), DN05221844.
5.6 TETRA Connectivity Server (TCS)

The TETRA Connectivity Server (TCS) enables Airbus Defence and Space client applications and third party
client applications to gain access to the services of the Airbus DS TETRA System. It provides a high-level
application programming interface (TCS API) for accessing the speech and data services and operational
management and control functions of the Airbus DS TETRA System. With the TCS, user organisations can
integrate existing applications and systems – such as the command and control system (CCS) – into the
Airbus DS TETRA System and create customised applications for their specific needs. The customised
applicatons can include, for example, positioning or telemetric systems.
Through the TCS, authorised Airbus Defence and Space client applications and 3rd party client applications
can use, for example, the following Airbus DS TETRA System services network-wide:
• Controlling, monitoring and participating in TETRA voice calls
• Sending and receiving status and short data service (SDS) messages, callback requests and messages
based on any SDS-TL protocols
• Performing tasks related to data management of, for example, radio subscribers, groups, organisation
blocks or client applications
• Tracking changes in network data
The TCS is connected to the Airbus DS TETRA System either with an IP or E1 connection.
TCS solutions
The TCS Single-User provides access to the API services for one client application at a time, and is typically
installed on the same PC as the client application itself.
The TCS Multi-User provides simultaneous access to the API services for multiple client applications, and
is installed on a dedicated server PC. Alternatively, the TCS Multi-User can be run on a virtual server.
The TCS Multi-User implements a true client-server architecture. Airbus Defence and Space offers TCS
Multi-User capacity grades for 3, 8, 18 and 40 clients.
For more information on the TCS API, see chapter 3.2.5 .
For detailed information about the TCS, see the document TCS Product Description, DN0116031.
5.7 Configuration and Data Distribution server (CDD)

The Configuration and Data Distribution server (CDD) is a mandatory network element in all Airbus DS
TETRA System networks with more than one DXT. It can also be used in single-DXT networks, although
such networks normally have the DXT's integrated data distribution functionality in use and would not benefit
much from having a CDD.
The CDD provides a wide range of network-wide services relating to data management (configuration) and
distribution over IP networks. It supports the following TETRA System features and functions:
• HLR/VLR mechanism
• Management and distribution of radio subscriber data
• Management of network-wide groups and group areas
• Management of the membership of network-wide groups
The CDD collects all the data required by dispatching applications (clients) from the DXT(s) into its local
database and distributes this data over TCP/IP to wherever else in the Airbus DS TETRA System it is
required (clients and other CDDs). The CDD does not participate in time-critical services such as call setup
and control and does not collect Call Details Records (CDRs). The CDD handles only network management
events, which are not charged.
Each DXT can be served by one CDD only, but a single CDD can serve more than one DXT. Thanks to the
CDD, the DXT computer units and MTP signalling connections interlinking DXTs in a multi-DXT network
are freed for telephony use and are not loaded by data transmission to/from dispatching applications; this
enhances the scalability of the system.
The subscriber management product Tactilon® Management is connected to the CDD in the Airbus DS
TETRA System.
The following options are available for the CDD:
• Duplicated CDD
Consists of two concurrently running CDD servers (nodes), each of which contains a hot standby
database. Both of the server nodes as well as both of the databases are up and running concurrently.
The databases are configured as a hot standby pair, where one of the databases is defined as active
and the other one as the standby database. The two databases are kept synchronised at all times,
whereby a high level of reliability is achieved. The database uses local disks, so there is no need
for a separate storage unit.
The duplicated CDD is primarily intended for medium and large networks.
• Single node CDD
Offers the same functionalities and capacity as the duplicated CDD, but it consists of a single server
because it is intended to be used in small networks. It is possible to use several single node CDDs in a
network; the single node CDD can be duplicated by using two single node CDDs.
The single node CDD and duplicated CDD are compatible; it is possible to have, for example, a
configuration with one single node CDD and one duplicated CDD.
• Integrated data distribution
Can be used in single-DXT networks and does not require an external CDD server or CDD hardware.
In this solution, the CDD functionality that is integrated in the DXT is activated and used instead of a
CDD; the DXT then performs the CDD’s function of checking all rights concerning the management
operations initiated by the TCS client applications. Note, however, that there are limitations in using
some features, such as Combining of Groups and Periodic Recovery for Group Memberships.
For detailed information about the CDD server, see the document CDD Server, Product Description,
TRADXTAPP00182.
5.8 Audit Trail Server (ATS)

The Audit Trail Server (ATS) is an optional network element designed to be used in conjunction with the
Tactilon® Management and optional Logging of Management Events (LME) feature of the CDD, which
allows the authorised users to collect and track management events performed by workstation users. The
use of ATS requires that there is at least one Tactilon Management workstation or LME-activated CDD in
the network. The Audit Trail Server is not required and has no function in a network which has no Tactilon
Management workstations, CDDs and/or no LME.
The ATS automatically collects LME log files from the network at regular intervals (typically every day),
archives them (long-term storage) and at the same time places them in its database (short-term storage),
where they are held for a parameter-defined number of days and then deleted. While in the database, the log
records can be accessed from a standard web-based browser by organisation users.
The ATS provides sufficient disk space for storing approximately two years' worth of log files generated in a
typical network. Note, however, that this period represents the average and may be considerably shorter
or longer depending on the frequency and nature of management events in the network concerned. The
operator should, in any case, regularly transfer archived log files to permanent media such as CDs or DVDs.
Along with the second phase implementation of Logging of Management Events (LME2), it is also possible to
perform the LME configuration from ATS, that is, to define logging rules for the different organizations.
For detailed information about the Audit Trail Server, see the document Audit Trail Server, Product
Description, TRADXTAPP00183.
5.9 Enhanced Packet Data Gateway (EPD-GW)
The Enhanced Packet Data Gateway (EPD-GW) is one of the two main elements of the TETRA Packet
Core (TPC). The EPD-GW functions as the interface element between the Airbus DS TETRA System and
external IP networks.
EPD-GW provides a single gateway node for the TETRA packet data supporting terminal, when connecting
from any TBS/DXT in a TETRA network, and also roaming of the packet data connection (PDP context) from
one DXT to another. In single-DXT TETRA networks, the packet data connection to the external IP networks
can be done directly from the DXT without a separate gateway node, but in a multiregional/multi-DXT
network the EPD-GW provides this uniform way to connect to the external IP networks from a single TETRA
network access point.
EPD-GW also offers TETRA packet data accelerator service which accelerates and optimizes the TCP-based
TETRA packet data communication over low-speed connections, and thereby significantly increases the
perceived connection speed and usability experienced by the end-users.
EPD-GW offers the following benefits compared to the TETRA basic packet data:
• savings in MTP cost (No IP data load in the MTP links)
• easy mobile IP management
• easier handling of mobile IP policy between different user organizations
• lawful interception from single point
• interface for external DHCP server and external Radius server
• easier handling of disaster situations
• data accelerator possibility between a mobile and Tetra IP backbone
For detailed information about the the EPD-GW, see the document TETRA Enhanced Packet Data Gateway,
Product Description, TRASYSAPP00126.
5.10 TETRA Voice Gateway (TVG)

The TETRA Voice Gateway (TVG) provides an audio gateway between the TETRA Core network and voice
applications, such as Command and Control Systems (CCS), stand-alone dispatcher workstations, and/or
recording systems. The TETRA Voice Gateway provides TETRA voice services either over an E1 or over an
IP connection for voice applications and increases the PCM audio channel capacity available per DXT.
The TETRA Voice Gateway receives the audio streams from the DXT in TETRA-coded format (8 kbit/s) on an
optimised E1 connection or over an IP connection. The connection between a voice application and TETRA
Voice Gateway can be either E1 or IP.
In the case of clients with PCM coding, the TETRA Voice Gateway manages the audio encoding and
decoding from the TETRA coded format to the common PCM format (G.711) and vice versa. The TETRA
Voice Gateway is based on a commercial server platform. The TETRA Codec runs on the Xgear16 PCI
express card provided by Airbus Defence and Space.
The following use cases are typical for the TETRA Voice Gateway in the Airbus DS TETRA System:
• Individual voice applications connected to the TETRA Voice Gateway over an E1 or IP link
• Command and Control Center (CCC) connected to the TETRA Voice Gateway over an E1 or IP link
• Connectivity with a recording system over an IP or E1 link.
Together with the TCS Server, the TETRA Voice Gateway enables full IP connectivity for voice applications
as the TVG manages the audio communications and TCS handles the signalling part of the communications.
Therefore, the TETRA Voice Gateway provides possibility to cost efficient transmission of audio channels to
control room systems.
For a detailed description of the TETRA Voice Gateway, see the document TETRA Voice Gateway, Product
Description, TRATCSAPP00010.
5.11 G4WIF Gateway

From TETRA System Release 7.0 onwards, IP-only-connected DXTs, such as DXTA for example, can use
G4WIF Gateway (G4WIF GW) as a means to access conventional PMR systems (base stations, command
and control systems, or other radio systems). The G4WIF GW converts IP traffic from DXT into E1 and directs
the traffic to external G4WIF systems, and vice versa.
For a detailed description of the G4WIF GW, see the document G4WIF Gateway Product Description,
TRATCSAPP00040.
5.12 Authentication and Authentication Key Distribution (AKD)

The TETRA network has tens of thousands of subscribers; therefore manual distributing, handling, and
storing of authentication data must be avoided to minimise the costs and effect of human errors. The Airbus
DS TETRA Authentication Key Distribution (AKD) offers secure and flexible solutions for distributing the
secret authentication key (K data) used in terminal authentication and in air interface encryption to the Airbus
DS TETRA network. The authentication data is distributed securely from the K generating points to the radio
terminals and to the TETRA system, so that only the communicating parties know the authentication key.
For large networks, Airbus Defence and Space offers a fully automatic TCP/IP-based AKD solution. In
smaller networks the authentication data volume is significantly smaller and therefore a manual CD-ROM
-based AKD solution is more feasible. If you are using different vendors' terminals, there may be a need
for combining both CD-ROM and TCP/IP based authentication data distribution. In this kind of combined
systems, the data distributed over the TCP/IP network is always in encrypted format whereas the data
delivered on CD-ROMs can be in clear mode or in encrypted files.
The security in the data communication between the different AKD elements is based on strong encryption
methods. When encryption is used, the most critical and demanding task is likely to be the data encryption
key management. In Airbus Defence and Space's AKD, the authentication key management is based on
the Public Key Infrastructure (PKI) methods. The TETRA AKD elements are equipped with a smartcard
solution for workstation user authentication. The smartcard concept makes it possible to identify the AKD
users in secure way before they log on to the Airbus DS TETRA System. User identification is tied to the
physical smartcard and its secret PIN code.
The reliability of the system is particularly important with the fully automated AKD solution. This is achieved
by using reliable server HW with redundancy in the most critical components, for example, the redundant
power supplies, redundant hard disks, and redundant network interface cards. Cold standby products for
AKD are available for disaster recovery purposes.
The AKD solutions offer interoperable AKD interfaces for all TETRA terminal manufacturers for distributing
authentication data to the Airbus DS TETRA System. Multi-agency network AKD is an essential part of the
provisioning process of an authenticated terminal. The AKD supports both centralized and decentralized
provisioning models, and can therefore be customised to your needs. In the centralized model, one party
takes care of the distribution and programming of all terminals, while in the distributed model several end
user organizations are usually involved in the terminal provisioning.
All of the Airbus Defence and Space's AKD solutions and products are compliant with the TETRA MoU
security and interoperability requirements. The interoperable AKD interface also enables all TETRA terminal
manufacturers and TETRA system vendors to distribute authentication data to the Airbus DS TETRA System.
The following sections give an overview of the AKD elements.
Authentication Key Distribution Compact (AKDC)
The AKDC provides the functionality to deliver authentication data to the Airbus DS TETRA System's Transit
Key Database (TKD) and optionally to AKES / ACKS, if available.
When AKDC Clear or AKDC Enhanced is used, the AKDC is connected to the DXT. In both of these
options, the K-data is transferred manually by using a CD-ROM, which contains the data either in clear or
encrypted format.
When AKDC Enhanced Remote is used, the AKDC is connected to the AKES. The clear or encrypted
K-data can be transferred manually by using a CD-ROM or by transferring the encrypted K-data from the
K-delivery point over a TCP/IP network to the AKES.
Authentication Key Management Server (AKES)
The AKES application is automatic software for receiving and distributing the TETRA authentication data from
the K-delivery points to the TETRA System. It authenticates and forwards data received from authorised
sources before storing the data in the Transit Key Database (TKD).
The security in the data communication between the different AKD elements is based on strong encryption
methods. The AKES is typically used if several AKDC K-delivery points are needed or if the ACKS solution is
used.
Authentication Customer Key Server (ACKS)
The ACKS is an optional server application, which is used for preventing the loss of the authentication key
(K) data. The ACKS stores all the K-data into its secure local database. If a K is lost in a network – for
example, because of a human error or a natural disaster, such as fire or earthquake – the corresponding
radio terminal(s) must be sent to the factory where it will be reprogrammed and the K-delivery data will be
recovered from the ACKS to the network.
The ACKS can only be installed in the same AKD network as the AKES.
For detailed information about the AKD, see the document Authentication Key Distribution (AKD), Operational
Guide, dn03520498.
5.13 Network management system (NMS)
In the Airbus DS TETRA System, the managing of the physical radio network is done by using a Network
Management System (NMS). Network management consists of a number of activities that can be broadly
divided into technical management, which consists of tasks related to the implementation and functioning
of the network, and operative management, which consists of the planning and configuring services and
features.
The TETRA System offers a number of features and services for network management. Depending on the
size of the network and need for the management actions, management operations can be performed
locally in a DXT by using MML commands or – in the case of larger networks – utilising centralised
management provided by the network management systems NetAct™ TETRA and NetBoss XT® for TETRA.
The integrated network monitoring feature TETRA Element Monitor (ElMo) can be used to monitor small
networks of up to two DXTs.
5.13.1 Local network management

The DXT and TBS, which are the core components of the Airbus DS TETRA System, are mostly operated
by using MML commands via any of the DXTs in the network. The MML sessions can be divided into local
and remote sessions. By using a local MML session, you can connect directly to the DXT system you want
to use. For a remote MML session, you have to first establish a connection to the local DXT and then to
the DXT you want to use. Note that the Airbus DS TETRA System can be fully operated remotely by using
the the command lines. This can be useful especially as a predefined means of backup if, for example, a
disastrous event prevents the normal network operation.
Most of the other TETRA network elements can be managed locally by using either a web-based or a
command line configuration in the customised Webmin configuration interface.
5.13.2 Centralised network management

NetAct™ TETRA
NetAct™ TETRA forms a reliable tool for centralised management of medium- to large-sized TETRA
networks. Designed to optimise the quality of service and operations, the NetAct offers powerful functionality
and an easy-to-use graphical interface. For TETRA users, the result is enhanced network performance,
increased on-line reliability, and lower costs.
Using various monitoring tools, NetAct can detect and locate problems in real time. NetAct collects
the performance data from the TETRA network and stores it into its database for later offline analysis.
With NetAct, you can easily archive, browse, and download software builds for these network elements.
Downloading can be done simultaneously to several network elements by using scheduled launches.
The DXT software configuration as well as the radio network configuration can be visualised with NetAct
applications. The automatic and user-defined uploads give an up-to-date view of the network configuration.
By using Netact, you can also modify radio network parameters and download them to the TETRA network.
The data communication between the NetAct TETRA and the DXT can be implemented either by using OSI
over TCP/IP or OSI over IP. Physically, the NetAct can be connected directly to a DXT-site LAN or it can
be located outside the firewall in an external TCP/IP network. For more information on the NMS interface,
see chapter 3.3.1 .
For more information on NetAct TETRA, see the document Intoduction to Features, DN00126484.
NetBoss XT® for TETRA
NetBoss XT® for TETRA is a scalable network management system designed for the Airbus DS TETRA
System solution. It combines the selected network management functionality to build the most suitable
solution for different sizes of networks. NetBoss XT® for TETRA enables you to proactively manage
and maintain your entire network by using an easy-to-use Web-based graphical interface. It can be
used for handling alarms, configuring the network elements and checking, for example, the DXT
software configuration, as well as updating the network elements’ software, collecting DXT performance
measurements, and managing NMS users.
NetBoss XT® for TETRA is built using NetBoss XT core software, its applications and management agents
that provide the features and tools to integrate the network elements and create the views to the network.
It also has optional integration interfaces available, for example for advanced reporting, which is realised
using NetBoss Reporter. The main NetBoss XT system and NetBoss Reporter are accessed using standard
Internet browsers. A single relational database is used for storing the network data.
For more information, see the NetBoss XT® Product Description, TRASYSAPP00300, which is available in
the separate NetBoss XT® for TETRA Product Documentation set.
TETRA Element Monitor (ElMo)
The TETRA Element Monitor (ElMo) is an integrated network monitoring feature, which is particularly aimed
for smaller networks. ElMo has a Web-based user interface, where the status of the network elements is
displayed in both graphical and textual format. The main, topology view shows the overall alarm situation and
status of the network elements in the graphical format, with clear visualisations for different statuses. The
alarm details and event history can also be viewed in the textual format e.g. in the alarms and event log views.
The ElMo application also provides the DXT MML interface, which is used for configuring, monitoring and
maintaining the TETRA network elements. The operational management of radio subscribers, groups and
organisations is done by using the DWS Management (DWS M) application, which can be installed on
the same PC as ElMo.
For more information on ElMo, see the document TETRA ELEMENT MONITOR, Installation, Configuration
and User Instructions, TRADXTAPP00077.
6 TETRA network solutions
6.1 One network - multiple user organisations
Multiple user organisations can share the same Airbus DS TETRA System network. From each organisation's
point of view, it appears to be the sole user of the network. Radio users, groups, call rights and so on can be
controlled independently within each organisation.
This functionality offers a cost-efficient arrangement for network investment and helps to reduce the costs
of network operation and administration. Figure 10 illustrates the case where three organisations operate
in the same network. Both organisations have their own dispatchers.
DXT
TB3
TB3
Physical TB3 TB3
network
TB3
TB3
Organisation A Organisation C
Organisation B
Key:
= Transmission lines
= Radio path Dn00122219x5x0xe
Figure 10 : Several organisations sharing one network
6.1.1 Communication within one organisation

Each organisation can manage its own subscribers, groups, and dispatchers and grant rights to them as
required. For group communication, each organisation can have multiple groups each of which has several
dispatchers and hundreds of radio members. Figure 11 illustrates the case of an organisation with two groups
sharing the same dispatcher.
Organisation A
Patrol 121 Motorcycle 5
dn00122222x2x0xen
Figure 11 : Multiple groups with a shared dispatcher (single organisation)
Groups have a number of attributes, one of which is the group area. A group area can be defined as
the entire network area, the entire area covered by a specific DXT (or DXTs), or specific location areas
(base-station coverage areas) under specific DXTs.
The scope and type of one-to-one communication rights can be defined individually for each user.
Organisations use the services provided by the shared network according to their specific requirements:
• Users can be given different communication rights, including rights to individual communication and
participation in group communication (group membership).
• Users can have different priority levels for individual calls and data communication. Talk groups
belonging to organisations can have different priority levels. For more information, see 4.4.1 .
• Dispatchers can have different administrative and communication rights, including rights to
individual communication, participation in group communication and the control of radio users' group
memberships.
Users can also be divided into different subscriber classes, which makes it possible to permanently or
temporarily limit the use of certain cells (base stations) on the basis of class. For example, it may be necessary
to prevent the use of aircraft cells by ground users or to reserve cells for key user groups during incidents.
Communication within groups can include group and individual communication (dispatcher calls) and status
and SDS messages. Communication with external systems, such as conventional PMR systems, is also
possible.
A radio user or dispatcher can belong to multiple groups and a group can have multiple dispatchers. This is
illustrated in Figure 12 .
Organisation A
dn00122234x2x0xen
Figure 12 : Multiple groups with common radio members and shared dispatchers (single organisation)
6.1.2 Communication between organisations

The Airbus DS TETRA System allows communication between different organisations in a controlled way:
• Organisations can have common co-operation groups.
• Dispatchers can have rights to manage and communicate with subscribers in different organisations
(see Figure 13 ). Dispatchers can, for example, create a group that includes members from several
organisations.
• Dispatchers can efficiently respond to sudden communication needs by combining several groups from
different organisations into a temporary co-operation group.
• One-to-one communication can be allowed between subscribers of different organisations.
• Optional numbering schemes such as FSSN and MSISDN can be adopted. With FSSN, organisational
branches can build virtual user networks. MSISDN numbering can be used for efficient communication
between TETRA users and public networks such as GSM and PSTN.
• It is possible for an organisation to restrict its visibility towards other organisations in the network so that
dispatchers of other organisations are not able to see that organisation or access its organisation data.
• It is possible temporarily to pass management rights for a particular radio subscriber to another
(visiting) organisation block (OB).
Communication between organisations can also include individual calls and status- and SDS messages.
Figure 13 illustrates the case of two organisations with inter-communication needs.
Organisation A
Dispatcher of
Dispatcher who organisation A
has rights in
both organisations
Dispatcher of
Organisation B organisation B
dn00122246x2x0xen
Figure 13 : Communication between organisations
6.2 Scalable network structure

The radio network structure of the Airbus DS TETRA System meets the tough requirements on capacity,
availability, and call set-up speed. The time needed for call set-up is extremely short, making it possible, for
example, for a terminal user to start speaking immediately after pressing the push-to-talk (PTT) button.
The scalability of Airbus DS TETRA networks is based on the following features:
• The Airbus DS TETRA network can be built around a single digital exchange (DXT) or multiple,
networked DXTs. Small networks with less than 6 to 10 exchanges (depending on the DXT type) are
generally implemented with access-layer DXTs only; larger networks may also have one or more
transit-layer exchanges to implement a hierarchical DXT network.
• The number and location of the TETRA base stations is determined by the geographical radio
coverage required. The number of carrier units needed in a specific base station is determined by the
traffic-handling capacity which the base station is required to provide. A single base station can be
equipped with a maximum of 31 traffic channels (8 carrier units).
• The network dispatcher system may range from a single workstation to hundreds of workstations,
depending on the size of the network.
6.2.1 Single-DXT network

A minimum network configuration can be built around a single DXT and a single TBS. In practice, some
management and data distribution tools are also needed. Figure 14 shows an example of a small single-DXT
network implementation. In addition to the DXT and the TBS, this example network also contains one
dispatcher workstation (DWSx) which in this example is connected to the Airbus DS TETRA System using
an E1 connection.
DWS
PABX/PSTN
Analog systems
TB3
DXT3
TB3
TB3 TB3
TB3
IP TB3
E1
Dn0613268x4x0xen
Figure 14 : Example of a small single-DXT TETRA network
In single-DXT networks, technical network management can be handled with an MML-terminal connected to
a DXT either locally or remotely.
6.2.2 Multi-DXT network
A multi-DXT network is essentially a group of two or more single-DXT networks interlinked by an E1 and/or IP
transmission network and the IP backbone to form a larger, seamless network. Figure 15 shows an example
of a non-hierarchical multi-DXT network, where the DXTs are interconnected over IP and E1 connections to
provide resilient call routing and fast call set-up across the whole network. The example multi-DXT network
also has the following network elements:
• TETRA base stations (TB3 and TB3p)
• Dispatching application (RCS 9500, DWS or 3rd party client)
• Network Management System (NMS)
• Tactilon® Management
• Configuration and Data Distribution (CDD) server
• Automatic Vehicle Location (AVL) server
• TETRA Connectivity Server (TCS) for third-party clients (such as command-and-control centres and
archive recorder)
• TETRA Voice Gateway (TVG)
• Enhanced packet data gateway (EPD-GW)
• PSTN/PABX over SIP trunk interface
• Routers and firewalls
A multi-DXT network can also have, for example, the following functionalities:
• Interface over IP to an external billing system
• External interfaces to a PSTN, PABX and conventional (third-party) base station
• Inter-system interface (ISI) to foreign networks
• Secure interface to external IP networks.
Figure 15 : Example of a larger, multi-DXT TETRA network
Basically, there are two entities at each DXT site which must be linked to the corresponding entities at the
other DXT sites to form a multi-DXT network. These are the DXT and the site LAN, which are discussed in
more detail below.
Interconnecting the LAN sites
To interconnect the LAN sites, the individual DXT-site LANs are internetworked by means of a WAN, which
can be implemented with a number of alternative transmission technologies. Choice of the WAN solution will
be determined by factors such as cost constraints, required data throughput capacity, security issues, and so
on. An IP router (and possibly VPN/firewall) interfaces each LAN segment to the WAN.
Together, the LAN and WAN segments make up the network-wide IP backbone of the system, which enables
the efficient managing and distributing of various kinds of data throughout and beyond the network. The IP
backbone is described in more detail in chapter 6.3 .
Network management system
In small multi-DXT networks, technical network management can be handled with an MML-terminal
connected to a DXT either locally or remotely. In large networks, however, it is normally handled by using a
separate Network Management System (NMS), such as NetBoss XT® for TETRA.
For more information on NMS, see chapter 5.13 .
6.2.2.1 Physical DXT-DXT topologies
As far as physical DXT-DXT connection topologies are concerned, Airbus DS TETRA System networks can
be divided into two main types:
• Non-hierarchical or flat networks
• Hierarchical networks
Note
When talking about non-hierarchical and hierarchical network topologies in this document, we are referring
only to the network of E1 (2.048 Mbps PCM) or IP connections interlinking the DXTs in a multi-DXT network.
These terms are not used in any other context.
Non-hierarchical networks contain only access-layer switches. An example is shown in Figure 17 .
Hierarchical networks have access-layer switches, too, but they also incorporate one or more transit layers
implemented with transit switches (such as DXTA, DXT3™ or DXTTip). An example is shown in Figure 16 .
For the same number of DXTs, a hierarchical network is easier to dimension, configure and operate than a flat
network. However, if there is a lot of traffic between neighbouring access-layer DXTs, it might be advisable to
add direct interconnections between them as well.
There is typically one transit-level switch for each 6 to 10 access level exchanges in the network.
Access-layer switches (DXT)
DXT DXT
Transit layer
DXT DXT
Access-layer switches (DXT)
Dn0613377x4x0xen
Figure 16 : Example of a hierarchical DXT-network topology
DXT-DXT connections
The physical E1 or IP connections between any two DXTs can be direct cable connections, but in practice they
are more likely to be leased lines in a transmission network. The DXT-DXT E1 lines carry message transfer
part (MTP) signalling (that is, transferring of signalling messages required by all users and performing,
for example, error control and signalling security), voice channels and, optionally, O&M data. Up to 512
kbit/s-wide MTP links are supported. In IP transmission the MTP signalling and voice channels between
DXT switches is transferred in IP packets. The lines are not used for data distribution among dispatching
applications in the network; this is handled by the Configuration and Data Distribution server (CDD) instead.
Multi-DXT networks with more than 10 DXTs usually have one or more transit-layer switches in addition to the
access-layer switches. A transit switch functions as a hub for interconnecting different groups of access-layer
switches. Transit switches are used in large networks to implement a hierarchical network topology, which
has a transit layer via which voice/signalling links between different groups of access-layer DXTs can be
established in a straightforward and systematic way. Transit switches cannot be connected to base stations.
E1 transmission
Generally, all DXTs in a flat network are physically interconnected in a fully meshed E1 topology, as shown in
Figure 17 .
DXT
DXT DXT
Full-mesh -Connected
access -layer switches
DXT DXT
dn142766x1x0xen
Figure 17 : Full mesh topology of a flat DXT network
In a full mesh topology, every DXT is directly connected to every other. Fully meshed networks keep call
setup times short, but they are more costly to implement and operate and make less efficient use of the
available E1 capacity.
Groups of transit switches are typically fully meshed, in order to provide load sharing and redundancy. It is
also recommended that every access-layer DXT be connected to at least two transit DXTs for redundancy.
IP transmission
As an alternative to E1 transmission, the DXT can be connected to other DXTs over IP transmission.
For inter-DXT signalling, there can be both E1 and IP transport based signalling links within the same
network, but only either IP or E1 transport between two DXTs.
For an example of a DXT network architecture for IP transmission, see Figure 15 . In that example only
access-layer DXT switches are used.
For information on which DXT types support IP transmission, see Section 5.1 .
6.2.2.2 Logical DXT-DXT topologies
Logical topologies are created on top of the physical topology of the network. Logical topologies are defined
by means of configurable routing tables in the DXTs which specify the primary and secondary routes for voice
signals and different types of data/signalling between any given pair of DXTs. Logical topologies must be
defined for the following:
• E1 or IP speech circuits
• OB, OB parameter, client application ITSI and group GTSI provisioning
• Mobility management
• Call control signalling and data message services
• O&M network
6.3 TETRA IP backbone
6.3.1 Overview
The TETRA IP Backbone is a mandatory component in multisite Airbus DS TETRA System networks. Its
function is to provide reliable (redundant), scalable and secure IP connectivity for the system elements and
additional IP services such as domain name services, IP address allocation and screening of IP traffic.
The backbone architecture takes advantage of solutions used in mainstream GPRS/3G- and NMS DCN IP
backbone networks. It is highly flexible and strongly based on open standards and well-established IP
technology. Backbone implementations can be built using readily available off-the-shelf components from
reputable vendors.
The TETRA IP network consists of core, DXT, TBS, O&M and organisation sites. The TETRA IP sites
can be interconnected via the IP backbone. Each site should have a direct connection to IP backbone;
therefore, the IP backbone is the centre of the IP network. A physical network is composed of several sites,
which are connected to each other according to a certain hierarchy and topology. The basic architecture of
the IP backbone is shown in Figure 18 .
Figure 18 : Basic architecture of the IP network
The IP backbone can be implemented either as a one-site network or a multi-site network:
• In a one-site network, all network elements can be connected to one pair of site switches.
• In multi-site networks, it is mandatory to use a routing protocol in the IP backbone. The routing can be
either static or dynamic. Small multi-site networks can be connected to each other directly from site to
site and hence the site switches are serving as an IP backbone addition to the site IP connectivity.
Large multi-site networks can have separate routers for the IP backbone and the site switches are
connected directly to the edge routers.
External entities communicate with the TETRA system via the VPN/firewall router. External IP interfaces
are normally centralised to one of the DXT-sites.
In addition to the TETRA network elements, the following elements are also needed:
• DNS server, which provides a DNS service to the network elements in the IP Backbone. Airbus
Defence and Space offers an HP Unix server for use as a DNS server.
• NTP server, which is used for synchronising the clocks on the hosts connected to the network.
For information on the IP routers and site switches recommended by Airbus Defence and Space, see the
document TETRA Site IP Connectivity Guidelines, TRASYSAPP00192.
6.3.2 Site connectivity
Network elements in TETRA sites must be interconnected to the IP backbone using routing and switching
capable network elements, such as multilayer site switches. In the TETRA network elements, all essential IP
interfaces have two ethernet ports for redundancy. Hence, the site switches must support redundancy.
Transmissions of the network element interfaces are carried over Virtual LANs (VLAN) within sites. Each IP
interface has own VLAN to terminate the IP interface only for desired ports and computer units.
For more information, see the document TETRA Site IP Connectivity Guidelines, TRASYSAPP00192.
6.4 TETRA IP packet core
6.4.1 Overview
For the radio subscriber (RS), the use of the IP packet data service is evident in the mobile client's IP address
and IP route as well as in the radio terminals's connection to the IP network.
When the radio subscriber requests a mobile IP connection – also referred to as activating the packet
data context – the TETRA System allocates a mobile IP address to the mobile client. After the connection
has been established, the IP transmission and the forwarding of the IP packet data takes place between
the mobile client and the fixed IP networks. The mobile IP address is released either when the packet data
context is released by the user or when the relevant standby timer expires, as a result of which the system
releases the mobile IP address.
The mobile IP connection is illustrated in figure 19 .
Figure 19 : TETRA packet data service for radio subscribers
The TETRA Packet Data Service supports point-to-point IP data communication — that is, sending and
receiving of IP packets — between IP hosts. A mobile IP connection can be established only if it is originated
by the radio terminal (RT). With a PC connected as a mobile client, the RT can access the IP network and
use the same client applications they use on their desktop computer, for example the Internet.
To be able to transmit the IP packets from one host to another, the transmitting and receiving hosts must
each have a valid IP address. The mobile client can be allocated either a static IP address or a dynamic
IP address. If a static IP address is used, the RS will always receive the same IP address for the mobile
IP connection, whereas the environment which have a large number of hosts benefit from using dynamic
allocation for the mobile IP addresses. Regardless of which option is used, the allocated IP address remains
the same until the mobile IP connection ends; that is, the mobile IP address remains the same also if the RT
performs a handover or roams to another DXT area.
It is possible to participate in calls and send status/SDS messages when the packet data context is active.
6.4.2 TETRA IP packet data services

The TETRA IP packet data engine enables a mobile IP application to become a part of the IP network by
allocating a mobile IP address for the mobile client. It also acts as a packet data gateway between the RT and
the fixed IP network. The mobile IP application can send and receive IPv4 packets between the IP network
elements. In Figure 20 , the blue IP path illustrates a connection between two mobile clients, whereas the red
IP path shows the mobile clients' connection to the network.
Figure 20 : IP network connectivity for TETRA applications
The Airbus DS TETRA System supports two alternatives for the IP Packet Data Service: basic mode and
enhanced modes. The enhanced mode enables TETRA Enhanced Data Service (TEDS) for faster data rate
and higher data capacity. Figure 21 shows the network elements involved in the different IP Packet Data
Service solutions. Backbone elements, such as Dynamic Host Control Protocol (DHCP), can be implemented
additionally, if needed.
Figure 21 : Network elements used in the different TETRA IP Packet Core solutions
IP Packet Data modes on the TETRA Air Interface
In Airbus DS TETRA System, the IP packet data can be transferred on the air interface by using one of the
following alternatives:
• phase modulation on a dedicated single-slot PDCH
• Quadrature Amplitude Modulation (QAM) on a shared multi-slot PDCH
The PM PDCH supports slower transmission rates, whereas the QAM PDCH is intended for the high speed IP
packet data transfer rates required by TEDS. The QAM PDCH is the primary packet data channel for TEDS
users. The higher a QAM level (4-, 16- or 64-QAM) is used, the faster the data transfer rate is.
IP Packet Data Applications
In Airbus DS TETRA System, packet data is primarily used by mobile IP applications which are used for
data communication on the field. The data can support the control room personnel in making decisions or
client application users in receiving relevant information, such as the details of an accident or a car register
plate number to verify whether the vehicle is stolen.
The applications can be used in static positions or in moving vehicles for example for the following purposes:
• Transmission of monitoring, alarms, and control (gas, water, air quality, train)
• Traffic light and speeding control, based on vehicles which have passed a remote radar or camera that
has number plate recognition.
• Event creation and update on field (status report)
• Database queries, such as accident status request or register plate inquiry
• High speed applications (only with QAM PD)
For more information on the how to use the packet data applications, see the document Guide to TETRA
Packet Data Application, TRASYSAPP00287.
6.4.3 IP Packet data service alternatives

The Airbus DS TETRA System offers two alternatives for the IP Packet Data Service: Basic IP Packet Data
and Enhanced IP Packet Data. The enhanced mode enables TETRA Enhanced Data Service (TEDS) for
faster data rate and higher data capacity.
The supported IP protocol version is IP version 4 (IPv4). The protocol architecture of the basic and enhanced
IP packet data services in the TETRA System are summarised in figure 22 .
Figure 22 : Protocol architectures of the basic and enhanced IP packet data services
6.4.3.1 Basic IP packet data
The basic IP packet data service is primarily intended for small TETRA networks where MTP link transmission
is used. It has the following characteristics:
• Easy to activate in small networks
• Can be used without EPD-GW
• IP data load is in the MTP links
• Access Point Name (APN) based mobile IP address allocation is not supported
• High-speed with TEDS extension is not supported
The basic IP packet data provides the TETRA IP Packet Core entity in the DXT, which operates as a packet
data gateway between the IP network and the radio network. The TETRA IP Packet Core owns the mobile IP
address subnets which are allocated for the mobile IP equipment, such as the mobile clients. The external IP
networks provide the IP-based applications and services, which enable the operator to provide different kinds
of Internet and intranet access services for the mobile IP radio subscribers.
The basic IP packet data flow is shown in figure 23 . The IP transmission is done via the radio subscriber’s
DXT/HLR. If the end user roams to another DXT’s area, the uplink transmission may be sent directly to the IP
backbone in the DXT/VLR, but downlink transmission is routed via the DXT/HLR. If the DXT/VLR does not
have IP connectivity, also the uplink transmission is routed via the DXT/HLR.
Figure 23 : Basic IP packet data flow before and after roaming from one DXT to another
Each DXT has a unique mobile IP address range for allocating the mobile IP addresses and forwarding the
IP addresses in the IP network. In a large network, the network is divided into DXT IP subnets, which are
interconnected to the IP network. The network's IP backbone must be aware of which of the DXTs is the
packet data gateway that functions as the routing node for a specific mobile IP subnet. The IP transmission is
done via the radio subscriber's DXT/HLR.
The use of basic IP packet data is supported in DXTs and TB2 family of base stations. Depending on the DXT
mechanics type used, the packet data can be handled by CMM, PDCU or OMU. The differences between the
options are related to the maximum capacity, load sharing, and redundancy.
For further information about Basic IP Packet Data, see IP Packet Data Service, TRASYSAPP000288.
6.4.3.2 Enhanced IP packet data and the TEDS extension
The enhanced IP packet data service is a modern IP solution for transmitting and forwarding IP packets
between the RT and the fixed IP networks. It has the following benefits:
• Utilises the reliable standard building blocks and mechanics of the IP industry and GPRS main stream
• GPRS Tunnelling Protocol (GTP) supports roaming between DXTs. A tunnel moves from a DXT to
a DXT (both of which have Gn Interface) with the radio subscriber, which decreases the load of the
inter-DXT signalling links within the TETRA System.
• Savings in MTP cost (no IP data load in the MTP links)
• Easy mobile IP management use based on Access Point Name (APN)
• Easier handling of mobile IP policy between different user organizations
• Interface for external DHCP server
• Easier handling of disaster situations
If the TEDS extension is used, it will add the following benefit to the Enhanced IP Packet Data:
• Higher data rates enable the using of a wider range of data applications.
The enhanced IP packet data provides the TETRA IP Packet Core entity in the DXT along with the TETRA
Enhanced Packet Data Gateway (EPD-GW). The enhanced IP packet data service is connected to the IP
networks by using the EPD-GW, which functions as a packet data gateway between the IP network and the
radio network. The TETRA IP Packet Core owns the mobile IP address subnets which are allocated for the
mobile IP equipment, such as the mobile client. The external IP networks provide the IP-based applications
and services enabling the operator to provide different kinds of Internet and intranet access services for the
mobile IP radio subscribers.
The enhanced IP packet data flow is shown in figure 24 .
Figure 24 : Enhanced IP packet data flow before and after roaming from one DXT to another
The GPRS Tunnelling Protocol (GTP) is used on the Gn interface between the DXT and EPD-GW. It separates
the IP user plane from the network and follows the RT roaming in the TETRA network from one DXT to
another DXT, thereby handling the TETRA IP user-traffic transfer of a roaming RS. By using GTP tunnelling, a
high scalability is achieved in terms of the total number of roaming radio subscribers transferring data.
The Gi interface is used between the EPD-GW and external hosts. The IP traffic is transferred using any
protocol supported by the EPD-GW and the external host. Each EPD-GW has a unique mobile IP address
range for allocating the mobile IP addresses and forwarding the IP within the IP network. The IP backbone
must be aware of which EPD-GW functions as the routing node packet data gateway for the mobile IP subnet.
The IP transmission is done via the DXT in which the RS is registered.
The enhanced IP packet data with or without TEDS extension is supported by DXTs, the TB3 family of base
stations, and EPD-GW. Depending on the DXT mechanics type used, the packet data can be handled by
CMM, PDCU or OMU. The differences between the options are related to the maximum capacity, load
sharing, and redundancy.
For more information on the IP Packet Data Service, see the document IP Packet Data Service,
TRASYSAPP00288.
7 TETRA radio terminals
Airbus Defence and Space offers a range of advanced, high-quality TETRA radio terminals which are
ergonomically designed and easy to use. Airbus DS terminals are deployable in any network which complies
with the ETSI TETRA standard, but they can be used to their best advantage in networks based on Airbus
DS TETRA System. The synergy between the terminals and the network infrastructure enables the use of
functionality (for example, type 1 handover and implementation of the ETSI LIP-standard) which may not be
supported if the terminals and infrastructure are supplied by different vendors.
Note that if the TETRA Services for Smart Devices are used, it is also possible to use Airbus-defined smart
phone models in the TETRA System. The supported Android smart phone models and Android OS versions
are defined by Airbus Defence and Space. For more information, see the documents Tactilon® Agnet User
Manual, TRASYSAPP00427, and Tactilon® Agnet Release Note, TRASYSAPP00421.
This chapter gives basic information on the TETRA terminal models currently offered by Airbus Defence
and Space (listed in Table 3 ).
Table 3 : Airbus DS TETRA terminals
Handportables Pagers Mobiles Data terminals

TH9 P8GR TMR880i TDM880i
TH1n TGR990
THR9i
THR9+
THR9 Ex
THR880i
The available frequency bands for the Airbus DS TETRA terminals are listed in the following table.
TH9 TH1n THR9i THR9+ THR9 THR880i P8GR TMR880i TGR990 TDM880i
Ex
380-430 MHz X X X X X X X X X X
450-470 MHz X X X
806-825 – X X X
851-870 MHz
7.1 Handportables
The properties and technical specifications of the TETRA handportables that are currently offered by Airbus
Defence and Space are listed in Table 4 .
7.1.1 TH9
The TH9 is a robust, ruggedised TETRA radio, which offers
wider coverage, high output power, Bluetooth connectivity, and
location-based applications. The TH9’s excellent usability for
mission-critical voice and data makes it a powerful communication
tool for heavy-duty users, who require a rugged radio for
demanding operations.
The large colour display presents information in a clear visual
format, which makes it easy to see mission-critical data at a
glance. The new audio design offers clear sound and excellent
audibility for voice calls, even in noisy environments. The
user-friendly night vision mode optimizes the display for dark
conditions.
Figure 25 : TH9 handportable
7.1.2 TH1n
The TH1n TETRA radio from Airbus Defence and Space offers all
the best elements of a PMR handset in a slim design that makes
it easy to carry. Yet it still packs a full set of features, being robust
and delivering a loud and clear voice quality to satisfy even the
most demanding users.
TH1n is the first in a completely new class of pocket-sized TETRA
radios. Its classy, elegant design, featuring a metallic finish and
well-formed, rubber-coated sides, sets it apart from conventional
professional mobile radios. The large, bright colour display,
familiar from many other Airbus DS radio models, makes critical
information available in a clear, easy-to-read format.
Figure 26 : TH1n handportable
7.1.3 THR9i
The THR9i is a robust TETRA handportable radio for mission
critical voice and data communication. High performance,
advanced features (Life guard, 'Where are you?' GPS application)
as well as IP65 classification with protection against water shower,
dust and shocks makes THR9i an an advanced, versatile TETRA
handheld radio, for most demanding operational duties.
Its outstanding audio quality and the large colour display ensure
reliable delivery of mission critical information both in voice and
data. The enhanced Airbus DS style user interface with user
friendly menu and the unique voice feedback provide extra user
comfort. Configurable keys allow customisation of the radio for
each organisations' needs.
Figure 27 : THR9i handportable
7.1.4 THR9+
The THR9+ TETRA handportable meets the strictest requirements
of field workers. Instead of a full alphanumeric keypad the
radio has a clear and large simplified keypad that is optimised
for being used even when wearing gloves. It addresses the
specific requirements of users such as firemen working in harsh
conditions. With the four-way navigation keys, the user has direct
access to the radio menu and phone book. In addition, the two
freely programmable function keys and configurale Fast menu
provide quick access to most frequently used numbers. THR9+
has a specific night vision display colour scheme providing
enhanced visibility and user safety when working in the dark.
Figure 28 : THR9+
handportable
7.1.5 THR9 Ex
The robust and modern THR9 Ex TETRA handportable radio
combines high performance, IP65 classification and security in
mission-critical voice and data communication where intrinsically
safe products are needed. With ATEX and IEC-Ex certifications
(II 2D Ex ib IIIC T96°C Db IP6X) as well as IP65 classification for
both gas and dust, the THR9 Ex offers the best protection against
physical and environmental exposure in explosion prone areas
with the same performance and comfort than the THR9i. The
THR9 Ex also meets the needs of fire brigades for Ex-equipment
when working in hazardous circumstances.
Figure 29 : THR9 Ex
handportable
7.1.6 THR880i
The compact THR880i radio is is designed for easy and reliable
field communication. Its straightforward radio side features only
the necessary buttons for instant group communication. Voice
feedback guides and confirms communications, allowing users
to focus on their tasks. The other side of the radio features a full
keypad and a colour display for messaging, data applications and
viewing the radio menu. With its integrated GPS, the THR880i
radio provides essential location information for efficient tracking
and allocation of resources. The Java platform and XHTML
browser make the THR880i suitable for advanced applications:
for example, the user can easily retrieve information from
organisation's databases or fill in reports directly on the field. Figure 30 : THR880i
handportable
The following table gives an overview of the properties of the Airbus DS TETRA handportables.
Table 4 : Airbus DS TETRA handportables
TH9 TH1n THR9i THR9 + THR9 Ex THR880i

Weight (g) 1) 284 160 265 270 360 2) 247
Size (mm) 3) 133 x 58 x 31 116 x 55 x 19 133 x 58 x 31 133 x 58 x 31 133 x 58 x 40 147 x 57 x 35
Power class 3L (1,8 W) 3L (1,8 W) 4 (up to 1 W) 4 (up to 1 W) 4 (up to 1 W) 4 (up to 1 W)
Receiver class A A A A A A
IP class 65 65 65 65 65 55
Talk groups 3000 3000 3000 3000 3000 2000
DMO groups 1500 1500 1500 1500 1500 180
Integrated GPS yes yes yes yes yes yes
Where are you? yes yes yes yes yes no
Lifeguard yes yes yes yes yes no
Display revert yes yes yes yes yes no
180º
Display colours 262 144 262 144 262 144 262 144 262 144 65 536
Pixels 240 x 320 240 x 320 240 x 320 240 x 320 240 x 320 130 x 130
Battery (mAh) 1900/4600 1590/3180 1900/4600 1900/4600 1280/2000 1880/1400
Vibra alert yes yes yes yes yes no
1) Weight with standard battery
2) Weight with 2000 mAh battery
3) Length without antenna
7.2 Pagers
7.2.1 P8GR
The P8GR TETRA pager offers advanced solutions that make it
a valuable tool for both professionals and volunteers in public
safety organisations, rescue forces and relief organisations. The
P8GR can be used for:
• Alerting the on-duty personnel to respond to an incident.
• Passing critical information directly to the alerted personnel
• Managing resources during the emergency assignment. Figure 31 : P8GR pager
The P8GR combines good availability − even in areas where coverage is poor − with robust battery, all in
a compact format. P8GR enables secure two-way communication between the control centre and the
operational units. Via the availability status message, users can indicate their readiness to participate in
assignments, enabling a significantly improved resource management in cases of emergency.
The P8GR can be managed using the smart Taqto® terminal management tool which allows several radios
to be updated and re-configured simultaneously.
Table 5 : Airbus DS TETRA pagers
P8GR
Weigth (g) 145
Size (mm) 98 x 60 x 22
Power class 4
Receiver class A
DMO yes
Display colours High contrast monochrome
Battery (mAh)
Premium BLN-10, Li-ion 1590 mAh, up to 50 hours standby time
Heavy Duty BLN-11, Li-ion 3180 mAh, up to 100 hours standby time
USB Micro-USB connector for charging and data
Operating 20°C to +55 °C
temperature range
Dust and waterproof IP54
classification
Shock proof 1.5m free fall
7.3 Mobiles
The properties and technical specifications of the TETRA mobiles that are currently offered by Airbus
7.3.1 TGR990
TGR990 is an advanced and versatile TETRA mobile radio,
gateway and repeater. It is designed for reliable voice and data
communication in the demanding working environments of public
safety and emergency services. TGR990 can operate in three
modes: in addition to a normal TETRA radio, it can be used as
a gateway between Trunked Mode Operation (TMO) and Direct
Mode Operation (DMO) or as a DMO repeater for extended
coverage. User can easily change the mode by a one-touch
shortcut key.
Figure 32 : TGR990 mobile
7.3.2 TMR880i
The TMR880i (Figure 33 ) is a versatile mobile radio consisting of
a transceiver (radio) unit and a separate control unit optimised for
easy and reliable installation and use in a wide variety of vehicles.
The radio unit can be integrated into, and controlled by, an
external device or application. It provides a number of interfaces
for connecting to external accessories and equipment.
Figure 33 : TMR880i mobile
Table 6 : Airbus DS TETRA mobiles
TMR880i with TGR990 with

CUR-3 control unit control unit
Weight (g)
Radio unit 1004 1500
Control unit 240 250
Size (mm)
Radio unit 60 x 182 x 125 44 x 168 x 163
Control unit 72 x 190 x 36 65 x 190 x 30
Power class 3 (up to 5 W) 3 (up to 5 W)
Receiver class A A
IP class (control 55 54
unit)
Talk groups 2000 2048
DMO groups 180 1024
Integrated GPS yes yes
Where are you? no no
Lifeguard no no
Display colours 65 536 65 536
Pixels 130 x 130 212 x 140
DMO Repeater no yes
DMO Gateway no yes
7.4 Data terminals
The properties and technical specifications of the TETRA data terminals that are currently offered by Airbus
7.4.1 TDM880i
The TDM880i is dedicated to positioning, telemetry, remote control and data transfer applications, especially
in embedded solutions. It was designed to be integrated with a master device in applications such as
intelligent traffic systems, but it can also be used as a stand-alone device.
Figure 34 : TDM880i data terminal
Table 7 : Airbus DS TETRA data terminals
TDM880i
Frequency • 380–430 MHz
bands
Operating -20ºC to +55ºC
temperature
range
Weight 110 g
Dimensions 160 x 64 x 22 mm
Receiver A
class
Power class 3
IP class -
• Shocks and vibrations tested based on:
- ETSI EN 300 019-2-5 V3.0.0 (5M3),
Durability
installations only inside vehicles.
- ETSI EN 300 019-2-6 V2.1.2 (6M3)
Table 7: Airbus DS TETRA data terminals (cont'd.)
TDM880i
Security • Authentication
• Mutual authentication
• Air Interface Encryption (AIE) with
dynamic and static ciphering keys
(DCK/CCK) supporting TETRA encryption
algorithms TEA-1, TEA-2, TEA-3
Wireless data • TETRA IP packet data, single slot via
data cable
• AT command interface for applications
• Sending and receiving of group-addressed
SDS messages
• SDS sending on FACCH in an ongoing
group call
GPS • Integrated GPS receiver
Interfaces • I/O interface:
12 user configurable I/O lines, indicator
signals (Power on, In Service, GPS Fix,
Over Temperature), serial port (2.8V) with
AT commands and IP data, IGS with TTL
voltage level, 5V max 200mA DC output
• Low voltage level (2.8V) CPU interface:
Serial interface with AT commands and
IP data, IGS with low voltage level, 2.8V
power supply out, Indicator signals (Power
on, In Service, GPS Fix, Over Temperature)
• Power supply interface (10.6 - 16 VDC)
• TETRA antenna connector
• GPS antenna connector
Other • Advanced I/O-line functionality
features
Glossary
The meanings of the terms and acronyms used in this document are explained below.
For further information on TETRA definitions, terms and concepts and the meaning of all acronyms and
abbreviations used in Airbus DS TETRA System customer documentation, please see document Glossary
(DN00126469).
Term / acronym Meaning
ACKS Authentication Customer Key Server
AIE Air Interface Encryption
AKD Authentication Key Distribution
AKDC Authentication Key Distribution Compact
AKES Authentication Key Management Server
API Application Programming Interface
AVL Automatic Vehicle Location
CCS Command and Control System
CDD Configuration and Data Distribution server
CLIP Calling Line Identification Presentation
CLIR Calling Line Identification Restriction
DGNA Dynamic Group Number Assignment
DMO Direct-Mode Operation
DNS Domain Name System
DWS Dispatcher Workstation
DWS C DWS Communication
DWS C&M DWS Communication and Management
DWS M DWS Management
DWSip IP-Connected Dispatcher Workstation
DWSr DWS with wireless connectivity (via radio terminal)
DWSx DWS with E1 connectivity and support for E2EE
DXT Digital Exchange for TETRA (generic name for Airbus DS TETRA exchange
products)
DXT3TM Digital Exchange for TETRA, 3rd generation, access and transit type
DXT3c Compact access-layer DXT3
DXT3p Portable access-layer DXT3
DXTA DXTA Digital Exhange for TETRA, 4th generation
DXTip Access-layer DXT
DXTTip Transit DXT
E1 European PCM system that carries 32 channels in a 256-bit frame transmitted
at 2.048 Mbit/s basic multiplex rate
E2EE End-to-end Encryption
EPD-GW Enhanced Packet Data Gateway
ETSI European Telecommunications Standards Institute
FSSN Fleet Specific Short Number
FXC Flexible Cross Connect; TB3 E1-interface unit
G4WIF Generic 4-Wire Interface
G4WIF GW G4WIF Gateway
GC Group communication
GSM Global System for Mobile Communications
GPRS General Packet Radio Service
GPS Global Positioning System
GSSI Group short subscriber identity
GTSI Group TETRA Subscriber Identity
HLR Home Location Register
IP Internet Protocol
ISDN Integrated Services Digital Network
ISI Inter-System Interface
ITSI Individual TETRA Subscriber Identity
ITU-T ITU Telecommunication Standardization Sector
LAN Local Area Network
MGATE32 Switching unit (for hosting EsGates and providing voice switching interfaces)
MML Man-Machine Language
MS Mobile Subscriber
MSISDN Mobile Subscriber ISDN Number
MTP Message Transfer Part
NA4T NetAct for TETRA
O&M Operation and Maintenance
OB Organisation Block
PABX Private Automatic Branch Exchange
PC Personal Computer
PDCU Packet Data Communication Unit (DXT computer unit)
PMR Professional Mobile Radio
PRA Primary-Rate Access (ISDN)
PSS Public safety and security
PSTN Public Switched Telephone Network
PTT Push-To-Talk
QAM Quadrature Amplitude Modulation
R2 R2 signalling system
RCS 9500 Radio Console System
RCS 9500 console Dispatching applicaton which can be used to handle both analog and digital
communications.
REF Globally unique TETRA radio terminal identity
RT Radio Terminal
SAM Sound Arbitration Module
SDS Short Data Service
SDS-TL SDS Transport Layer
SIM Subscriber Identity Module
SIP Session Initiation Protocol
SIP trunk Interface in DXT for accessing PSTN/PABX
Taira Taira TETRA Server
TAS TETRA application server
TB3 Third-generation TETRA base station
Generic term used to refer to TB3 base station variants by Airbus Defence
and Space.
TB3c Compact version of TB3
TB3hp High power variant of the TB3p base station
TB3p Small, portable base station
TB3S TB3 Base Station with optimised cabinet mechanics
TBC TETRA Base Station Controller. Two product variants exist: TBCi and TBC-U
TBCi TETRA Base Station Controller HW
TBC-U TETRA Base Station Controller HW
TBS TETRA Base Station
Generic term used to refer to both 2nd- and 3rd-generation TETRA base stations
TCS TETRA Connectivity Server
TCS API TETRA Connectivity Server Application Programming Interface
TEDS TETRA Enhanced Data Service
TEI TETRA Equipment Identity
TETRA Terrestrial Trunked Radio
THR TETRA Handportable Radio
TMR TETRA Mobile Radio
TPC TETRA Packet Core
TTRX TETRA Transceiver
VLR Visitor Location Register
VMU Virtualisation Manager Unit in DXTA
VPN Virtual Private Network
WAN Wide Area Network
WAP Wireless Application Protocol

TETRA System Release 6.0 - 7.0: Technical Overview

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

TETRA System Release 6.0 - 7.0: Technical Overview

Uploaded by

Copyright:

Available Formats

Technical Overview

TETRA System Release 6.0 – 7.0

Copyright © 2016–2017 Airbus DS SLC, all rights reserved.

DN064483-17-1en TETRA System Release 6.0 – 7.0

1 About this document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2 TETRA - an open standard for digital trunked radio systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3 TETRA network interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

TETRA System Release 6.0 – 7.0 DN064483-17-1en

DN064483-17-1en TETRA System Release 6.0 – 7.0

5 TETRA network elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

TETRA System Release 6.0 – 7.0 DN064483-17-1en

6 TETRA network solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

7 TETRA radio terminals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

DN064483-17-1en TETRA System Release 6.0 – 7.0

TETRA System Release 6.0 – 7.0 DN064483-17-1en

DN064483-17-1en TETRA System Release 6.0 – 7.0

TETRA System Release 6.0 – 7.0 DN064483-17-1en

VERSION DATE COMMENTS CHAPTER

17-1 03/2017 Added Taira TETRA Server. 5

DN064483-17-1en TETRA System Release 6.0 – 7.0

TETRA System Release 6.0 – 7.0 DN064483-17-1en

32. TCS Product Description (DN0116031)

33. TETRA Enhanced Packet Data Gateway, Product Description (TRASYSAPP00126)

34. TETRA Voice Gateway, Product Description (TRATCSAPP00010)

35. Voice Communication (DN00126496)

DN064483-17-1en TETRA System Release 6.0 – 7.0

How to use this document

The document is organised as follows:

Chapter 1 explains what the document is for and how it is organised.

Chapter 6 describes the TETRA network solutions.

TETRA System Release 6.0 – 7.0 DN064483-17-1en

DN064483-17-1en TETRA System Release 6.0 – 7.0

2.1 The TETRA standard

2.2 Characteristics of Airbus DS TETRA

TETRA System Release 6.0 – 7.0 DN064483-17-1en

DN064483-17-1en TETRA System Release 6.0 – 7.0

• TETRA Services for Smart Devices

• Managed talk groups and group memberships

2.3 TETRA compared to analog PMR

• Communication is encrypted on the air interface.

• Creation of groups is not restricted by geographical area or the number of channels.

• Better suppression of background noise thanks to advanced digital voice coding.

TETRA System Release 6.0 – 7.0 DN064483-17-1en

DN064483-17-1en TETRA System Release 6.0 – 7.0

3.1.1 Air interface (AI)

3.1.1.1 Radio carriers and channels

3.1.1.2 Random access

TETRA System Release 6.0 – 7.0 DN064483-17-1en

3.1.1.3 Common control channel

Signalling from the TBS to radio terminals (downlink)

Signalling from radio terminals to the TBS (uplink)

DN064483-17-1en TETRA System Release 6.0 – 7.0

• Information on calls, including:

– Call setup phase messages

– Restoring messages after handover, using the U-Restore message

• Information on packet data, including:

• Layer 2 (data link layer) and layer 3 (network layer) acknowledgments

– the selected group and

3.1.1.4 Packet data channel

3.1.1.5 Traffic channels

TETRA System Release 6.0 – 7.0 DN064483-17-1en

1 TDMA frame = 4 timeslots = 4 channels (MCCH or TCH)

Figure 1 : TDMA and control frames in a multiframe